mike.mainguy

Git is Great! As a distributed source code tool, git is great. I love that when I'm on an airplane I can commit code without a wireless connection and have be able to unwind what I was doing. It was clearly designed with the "offline" model in mind. The idea I can create a quick branch, experiment, make massive sweeping changes, and just drop the whole thing if I realize it sucked...is AWERSOME! For a fact this puts it ahead of it's open source predecessors (namely...SVN, CVS, and RCS). But perhaps a victim of it's success What I observe, however, is that a lot of folks have taken up a development model where "everything is a branch" and we end up with roles like "pull request approval engineer" (not a real title, but if you end up doing that job, you'll know that your doing it). This problem happens when the number of public branches/forks reaches a count and complexity that far exceed any value they could have possibly served. ...

So borrowing an idea from the NCO Creed , I thought I do one for software developers: D iscipline will be my watchword, the software I create will never be perfect, but I will perform my job to the best of my abilities and remember that every letter I type should have purpose. E go is the enemy of good code, I will remember that "I am not my code" and never fail to admit mistakes and fix in in a humble manner. V alue is provided not through MORE code, but less. My software will be succinct. E nergy overshadows ability, I will bring my "A" game and not give up because it's "too hard". L ove for my users is always in my heart, they will break my code, I will fix it O penness wins over closedness, I will share my tips and secrets and together we'll all make the world a better place. P atience is paramount, sometimes the answer isn't the first, second, or fiftieth idea. E mpathy for the newbie and the uninformed wins, you never know when t...

A great many people are competent java developers, but have only a vague understanding of the difference between a "public static method", "public method", and the difference between a class and an object. As this was confusing to me at first, I thought I would give a quick overview. A class defines a template for what data and operations are available when you tell the JVM to create an object. So, for example: public class BlogPost { public String text = ""; public static BlogPost latest; public static BlogPost create(String input) { latest = new BlogPost(); latest.text = input; return latest; } public int getTextSize() { return text.length(); } } When you compile this class, it is creating a file that the java runtime can later use to enable programmers to load an object into memory that has a single attribute called "text" which is a reference to another o...

I don't consider myself a java expert by any measure, but there's a disturbing thing I've noticed. There are a LOT of people who claim to be "java developers", but they have zero clue what the "java collections framework" is. This post is designed for folks who keep getting stumped on interview questions or are mystified when someone starts talking about the difference between a Set and a List (for example). If you google "java collections framework for dummies" you'll find this link which has a more complete, if fairly dense explanation. I'm going to do you one better and give a rule of thumb that you can use without thinking about it. At it the root of things, a collection is something you can store other things inside. Just like in real life, a collection of marbles is just a "bunch" of marbles. The big difference in the collections framework is that the different implementations have different things they DO with t...

One trend I've noticed with git users is a habit to create a lot of branch and merge activity. The oft-repeated mantra is "branching is (easy/cheap/safe) in git so I do it a lot". When working on an agile project though, this behavior can cause serious problems. To illustrate the point, compare american football to soccer: American football has highly specialized players and positions as well as a variety of tightly choreographed set pieces. In contrast, soccer has a much lesser degree of specialization, and while there are some set pieces that are choreographed, the majority of the game is spent reacting to the situation as it evolves. Traditional development methodologies are like american football: They divide the work up among highly specialized players and then try to replay an intricate set of movements to make the play "work". Agile methodologies are more like soccer (or to a lesser degree rugby) in that the advantage doesn't come from follow...

I'm at a company that has a number of fairly high traffic web sites. Essentially, there is a holding company that does the "IT Stuff" and there are a number of brands that we support. Problem is, all these brands want the same sort of stuff, but just slightly differently. For example, they all want a store locater, they all want to search for things by categories and attributes, they all want a movie player, new/blog service... Historically, we'd get the request for a "rewrite" of a brand site. We'd spin up a project, start copy/pasting code from other sites and assemble a fresh new application from the pieces of the old ones. This is good, we're at least reusing some things instead of simply recoding everything from scratch.... but, it's also bad. Why? Because we're creating independent copies of code that does the exact same thing (see copy/paste coding ). Our previous solution to this problem was to not really update anything after...