mike.mainguy

A question came up at work today that I've had to stop and remind myself numerous times and I'm sure other people have to think about on occasion. When merging changes from a branch back to an origin, should I pull them from branch into origin or push them from branch to origin. The difference in CVS would be... do I check out the origin and merge the deltas of the branch into working copy or check out the branch and somehow push those changes onto the trunk. In short, always pull changes into a clean local copy that represents where the destination of the merge should be . It really doesn't matter which Revision Control System you use, this will almost always be the safest way to merge (assuming it supports a local copy). I say this for one very important reason, you MUST be able to resolve conflicts before committing changes to the central repository, pushing doesn't necessarily allow you to do that unless the tools supports something like Multi Version Concu...

Hello, my name is Mike and I'm a Morning Person. During a brief stop at the gas station this morning, I said hello to another guy entering the gas station as I was leaving. Not sure what he was doing up at that hour, but the serene look on his face was a perfect reflection of how I was feeling. As a person who routinely wakes up at 4-4:30 am, I love the morning. Don't get me long, I like to sleep... and need about 8 hours to feel rested, but I would rather go to bed early to not miss the morning than stay up late and sleep in until until 8:00am. On my drive to the train station, I started to explore what I liked and a variety of memories sprang to mind: As a young child, waking up 30 minutes early with my brother to get dressed, then get back into bed so that when Mom and Dad came to wake us up, we were already prepared (occasionally sneaking out to get breakfast too). Relishing the look of surprise when they realized we were ready to go. Waking up as a teenager, m...

As a longtime Outlook user, I've had the exciting experience of learning how to use Lotus Notes. When first starting to use it I was shocked at how "clunky" the user interface seemed, but wrote it off as my long familiarity with outlook. Recently, however, I started to realize that I was being too generous. Notes is full of user experience bad enough that I feel I need to point a couple out lest any young engineers try to design user interfaces based on them. These things are actually a combination of how Notes works as well as pretty poor administration of the tool. There are some settings which, when you log out of a tool, your personal preferences are reset, but others where they are saved. As two quick examples, I give you the following: Yes,No,Cancel By default, when sending email, Notes prompts with the following dialog: By itself, it is not a HUGE problem, we're not only giving you the option to save or not save in "sent items", but ...

As an older school client/server developer, I've used by VB and Delphi for a few projects in the past. Having seen both tools, they have a difference of approach that I think is significant. The VB model is "90% of what you want to do is easy and the remaining 10% is impossible" whereas the Delphi model is "80% of what you want to do is easy and the remaining 20% is more difficult". In the VB model, because it was such a closed ecosystem, when I couldn't do something, I'd have to go buy components from a third party or write a C library. There were multiple times when using VB I needed to write a special component in C or Delphi because VB just couldn't handle it. In addition, I was often forced to purchase third party components because nothing was available in the open source space. In the Delphi model, with it's richer open source ecosystem, when I couldn't do something, I'd first look and see if there was an open source compo...

As a developer who works extensively both ruby and java, I'm amazed at the turmoil in the ruby/rails space relative to java.  In the last few years, ruby and rails have had numerous massively headache inspiring incompatible changes that cause developers who used to know what they're doing to realize they're doing it the "old fashioned" way. A particularly entertaining example from recent history is the handling of scopes in active record.  Not only has this changed from Rails 2.x to Rails 3.0, it's getting further changed in Rails 3.1 (in an incompatible way). I will agree that these are good changes, but they are certainly an effect of not spending time to think things through the first time and cause problems for newbies and old hats alike. Compared with java  based projects (anyone still remember moving from hibernate 2.x to hibernate 3.0?) this rate of change is mind numbing and can be pretty frustrating. But, compared with the amount of innovation...

Arriving at every event too early, is a waste of time. If it normally takes 15 minutes to drive somewhere, some people will leave 30-45 minutes early. As another example, I meet people who arrive at the train station for 15-20 minutes before the train arrives almost every day for no good apparent reason. My personal opinion on this is that showing up at the appointed time is optimal. Doing simple math can show that showing up early devalues your time. For this simple example, let's suppose I get paid $10 per hour to do a job. If I agree to work 1 hour per day at this rate, but I show up at work 15 minutes early every day, my hourly rate just dropped from $10/hr to $8/hr. My agreement with my boss was to work 5 hours and receive $50 dollars, this amounts to an hourly rate of $10 per hour. What I actually DID, however, was donate an extra 1.25 hours (15 minutes per day over 5 days). I will point out that the word "unnecessarily" is key because depending on t...

I've often been around (or in the middle) of debates about how message oriented middleware is more scaleable than web services. The problem with this debate is that it is a false dichotomy. There is no reason you cannot do asynchronous http services where the response is simply "Yep, I got it". In practice, these services are just as scaleable and flexible as their queue based brothers and typically are not nearly as complex. Some of the reason this propaganda gets started is that non-technical folks need to be told a reason why a particular technology is more appropriate. Folks will often use "hot button" phrases like "it's more scaleable" instead of trying to actually explain in nitty gritty detail what the real reason is. Additionally, making asynchronous web services is truly a bit more challenging. The APIs for JMS foster the notion that the message is transmitted and immediately returns. HTTP libraries typically espouse the idea ...

I've worked in a variety of companies and I notice an interesting phenomena -- It seems that the capabilities of individual programmers in companies are inversely purportional to the size on the company. Tech startups with 3 folks always seem to have superstars, even though it's a huge drain on their budget, but IT shops with 1000 people seem to always have 10 people who seem to be doing everything. The irony in this situation is that a startup has the least amount of money to spend on programmers, but requires hiring only the best and needs to spend a disproportionate amount on payroll. On the other hand, a company flush with cash that could easily hire only the best and brightest, inevitably hires "everybody else". This means that particularly large shops end up with a handful of superstars (just by sheer luck of the draw) who do the majority of the work (and then burnout and leave) and a bunch of "also ran" folks who are really just padding their re...

After reading Give it five minutes I saw an interesting pattern. Of the folks I know, the good/great programmers are all pretty aggressive. In addition they are also pretty controlling. Moreover, when reading the comments to this blog post, I was struck by the number of folks who could identify with the "hothead". As a person who historically fit in to that personality type, I wonder why this is. It seems to me that the reason has to do with the way people interact with computers when programming. The very idea of being 'in charge' of the computer and making it do anything you want would seem to appeal to this sort of personality. In addition, the current market and the rate of change handsomely rewards people who aggressively pursue this end. Very successful programmers are the ones who can do this most effectively. The obvious downside is that this creates a situation where negative behaviour (in human interaction) is actually rewarded. Without conscio...