Monthly Archives: May 2012

Don’t Call Yourself A Programmer, And Other Career Advice

Came across this blog post by Patrick McKenzie, which I found pretty interesting especially the “other career advice” bit. He makes a lot of good points, although some of them are slightly cynical.

Some of the points I found most interesting, summarised:

  • The only real goals of writing software are increasing business revenue, and decreasing costs.
  • You’re better off working on software that does the former, for various reasons.
  • If you’re talented, the software stack you use doesn’t matter that much when it comes to getting employment.
  • Job benefits like free coffee cost almost nothing and are no excuse for less compensation.
  • Modesty will get you nowhere. Good communication skills and confidence will.
  • What gets you jobs is giving the perception that you can create value.
  • Social grooming affects us all. People back poor ideas of people they like over good ones from people they don’t like. People like people who they think are like them.

Ant build.properties hierarchies

It’s easy for build.properties files to get out of hand when multiple projects, developers, hosts and environments are involved.

It’s pretty common to use a hierarchy of build.properties files to try and minimise duplication and keep things tidy, as described by Gene Goitmer in his blog post.

In short, this takes advantage of the fact that Ant properties cannot be overridden once set.  By importing more specific (e.g. per user) properties files first, their values will remain even if the same property exists in more general (e.g. per environment) properties files.

I find that if our product involves multiple modules/projects, duplication can be avoided by having two such hierarchies – one common one, and another for each project. The common one is imported first, and contains properties such as the location of your local Apache Ivy cache.

Gene has a useful addition to my usual process, which is to have a file called “local.build.properties” for setting properties such as passwords that we want to avoid checking in. Adding it to svn:ignore ensures that it won’t be checked in accidentally.

Antipattern

I think that care needs to be taken with the use of overrides, particularly when using property values to detokenize configuration files. In those cases, I’ve seen setups in the past where the main properties file (“build.properties”, which is imported last) contains many properties that aren’t common for all environments, and require them to be overridden for all other environments.

I don’t think that this is a good idea, as it in effect will default any properties that you’ve forgotten to set correctly for a particular other environment. Worst case example, you could end up using the prod database with your dev build.

By not doing this, you’ll notice immediately if you’ve forgotten to set a property as your build will fail. Or if you’re using them for detokenizing some configuration files, you’ll also notice immediately when your post-detokenizing checks finds tokens in your detokenized files.

Hello, world

So I’ve finally got around to starting my own blog. I’ve been putting it off for a while now for many reasons that I’ve now realised don’t matter. I hope that by doing it I can support my own development and that of others.

My work and interest is mainly web application development, which I’ve been doing for a few years now. This is what I’ll mainly be blogging about, plus some of the non-technical topics such as development practice and project management.

I’m not an expert at anything, but my goal is to always improve. So if I say something that doesn’t seem right for example, please do comment and let me know your thoughts.