Posts

The difference between urgency and importance

Are you constantly besieged with emergencies and don't know how to dig yourself out? If so, I'll give you some insight as to how bring some sanity to your situation OR allow you to make a determination that your situation is in need of change. I'm borrowing some time management ideas from here as well as inspiration from a co-worker. First, some clarification: Importance refers to how much something will help you attain your personal or professional goals. So, for example, if you want to become a great guitar player, it would be important to acquire a guitar. It's very important to take an evaluation of all the tasks, commitments, and issues you are dealing with and determine how important they are. In the link above, it is a binary determination, something is either important... or it is not important. The simplicity of this formula has a certain appeal and to start with, I'd highly recommend it. An important additional note about importance is to use...

Deciding on NOSQL vs RDMS

Anybody not living in a cave knows that NOSQL is a current hot topic amount technology solutions. One sadly missing piece is some sort of guide on how to determine if NOSQL or a more traditional RDBMS is a better solution. To start with, I'll say you should assume that an RDBMS is probably the safest bet. Almost anything you can do with a document store can be done with an RDBMS, with the exception that it may not scale and/or perform as well as NOSQL solution. The big advantages of RDBMS solutions is that they have an enormous ecosystem of tools, documentation, and skilled administrators. Given the above, why would anyone ever even look at a NOSQL solution? Here are a couple indicators that a NOSQL solution might be a better fit for your problem: #1 You are storing simple key/value pairs. If your RDBMS "solution" ends up being a single table with a couple key fields and a CLOB with XML in it... you're probably using the wrong tool for the job. #2 You a...

Technology decision matrix (Using Ubuntu, Redhat & Suse as examples)

Technology decisions are difficult and it often seems that architects and developers resort to throwing darts to determin which solution they should use for many problems. A tool I like to use to help figure out the best solution is a simplified decision matrix . When used fairly, this simple tool enables us to quickly and visually determine which solution is best given our success measures. As an example, lets pretend we're going to pick a server platform. In this, effort, we have some specific things we care about: security updates - Does the solution have automatic and timely notification of security issues and an automated way to patch the server. modern versions of applications supported - as a criteria, which version of ngnix does the package support In the interest of simplicity, we're going to assume that other essential factors such as cost, compatibility with specific software and other issues have already been applied. We then take this information, select ...

Hey GOF, It's not a good metaphor unless you can drop it on your foot

I read a recent article about the importance of writing physically . Fundamentally, the author says that "writing physically" means writing about things you can drop on your foot. This means a lot to me because when trying to write software, I'm constantly translating ideas into mental pictures of physical things. To this end, I think the Gang of Four have done a disservice to the software industry by pushing design patterns that have no representation in the real world. Worse than this, pushing UML as a way to represent and communicate software design leads to situations where everybody THINKS they agree, but they in fact all are thinking about completely different things. As a specific and very simple example, lets look at the Command pattern. Reading the explanation is very dense and rife with jargon that is specific to the particulars of Object Oriented programming languages. For folks who need to read the explanation, who typically are new to OO programmin...

Coaching a winning team

As the spring soccer season is winding down, I'm reminded of a saying that I heard the AYSO national director of coaching say. I was at a conference and a roomful of hopeful coaches were quizzing him on what they could do to be more effective coaches. A variety of people proposed things they did to win more soccer games and his response was: "If you want to win soccer games, go find the better players". This was meant to be a rebuke in this context, but I wholeheartedly agree with the assertion. A coach or strategy CAN influence the game and when two teams are equally matched with talent, they can make the difference in the outcome. However, regardless of what the herd of ego-centric coaches might try to tell you, good coaching does nothing but unlock potential that already exists within the team members. Effective coaches are not the ones are making things happen, they are the ones that make sure the right team is available to make things happen. They also make ...

The Joystick Soccer Coach

I am a passionate soccer player and youth coach. One thing I find difficult to resist, but even more difficult to accept when I see other coaches doing it is the notion of being a joystick coach . In the beginning of my coaching career, it was hammered into my head that soccer is a "players game" and to develop players, a big part of coach's job is to give them freedom to make mistakes, present opportunities to learn from them, and challenge them to make good decisions on their own. I get IMMENSELY frustrated when I'm coaching a U6 team and my opposition has TWO coaches on the field active giving instructions to the kids. While these teams are often much more effective at scoring goals, it really makes player development difficult because the other team has a pair of 30 something men explaining how to take advantage of the situation to score more goals. Coaches, limit your instructions on the field, else you'll end up with robots who will likely be ambivale...

The ruby and java fightclub

As a person who has one foot firmly in java and another in ruby, I'm often in a situation where I try to have an objective conversation about the advantages and disadvantages between the the two. Unfortunately, both of these camps are not very objective about themselves and each other. Ruby guys seem to think that ruby is all sunshine and lollipops and java is spawn of satan and visa versa. Find any java developer who knows nothing about ruby (or ruby on rails) and strike up a conversation about the advantages and disadvantages between the two. If they in any way care about programming, you will typically end up with a seriously heated discussion about: Performance, Scalability, Compiler Safety, Support, Maintainability, other stuff. On the other side of the equation, I'm a bit at a loss because I've never met a ruby developer who didn't previously work as a java (or C) developer. Typically a new convert from java/whatever has all the zeal of a new religious co...