Joshua Rogers

Assuming you read the last post, you should have a basic understanding of projects, targets and tasks. In this post, some different tasks, and try to make a slightly more practical ant script. Suppose our build requires a little bit more complexity than displaying "Hello World." In this case, it has to meet the following requirements:

1. The file HelloWorld.java must be compiled
2. HelloWorld.class should include debug symbols.
3. HelloWorld.class must be zipped

Let's start by creating a basic project skeleton. For right now, we'll only include one target: "build". Remember to save your project in "build.xml".

<project name="HelloBuilder" default="build">
  <target name="build">
  </target>
</project>

At this point, you've doubtlessly realized that unless we learn new tasks, we will be doomed to writing useless ant scripts forever...

To me, some of the most fascinating problems are the ones that are only visible in hindsight. The angled measuring cup might be the best example of this. With a standard measuring cup, you have to bend over or lift the cup to see how much of a substance you've measured. On the other hand, the angled measuring cup can be read while standing upright. Yet when asked, most people didn't realize the problem with a normal measuring cup until after having seen the one from Oxo.

In much the same way, we ran across a "hindsight problem" at work: every week one guy had to take an hour or two out of his schedule in order to produce an new build for people to test. At the time it seemed perfectly acceptable. Then came the automated build. Now, in hindsight, it's obvious that we allowed several man weeks of a good engineer's time to go to a complete waste. Not only that, but we wasted the time of several testers in the process as well. The same exact set of instructions could be (and were) used to make every build. No part of the build process required any decision that couldn't be scripted to work faster and more consistently.

In order to once and for all save man-kind from this time-sink (or at least a smaller sub-set of humanity), I'll be doing several posts of the process of creating an build script. Though I'm starting with the basics now, by the end of the series I'll probably spend a little time focusing on how to build Flex and .NET projects without having to require any (expensive) human interaction. Before we dive into code, you'll need to install a Java runtime and Apache Ant. Once you've done that, we'll be ready to start.¹

For anyone that might want to use the theme from this site, I've just posted it to Drupal.org.  It can be found here: http://drupal.org/project/cmyk. As always, this theme is released under the GPL v. 2.0 or later.

My wife and I are paying off student loans. Obviously we didn't just take on debt because we wanted to. Going into college, she wanted to be a teacher and I wanted to be a software engineer. The only practical way for either of us to get the job that we wanted was for us to get the required degrees. That meant student loans. However, we took them on with the belief that they would be an investment that would pay for themselves in time. And, in this case, they have already started. Now, as quickly as we can, we're paying the loans off. The important parts of this otherwise boring story are as follows: the only reason we took on debt was that is was unavoidable if we were to get to our goal of future jobs, and that at the first available moment we started lowering risk by paying off our debt as quickly as possible.

Boring story aside, for any kind of software project, there will be technical debt. Whether the source of the debt is pressure to finish a project, shifting requirements, or just simply a lack of past experience to draw upon, every project will incur technical debt. Unfortunately, without a billing statement coming at the start of each month, the nagging of engineers can be, and usually is, heard by non-engineers as "engineers just love to rewrite things that already work." The problem is that there are severe consequences for carrying technical debt...

A few weeks ago, a few of us from work went to GiveCamp.  Hampton Road Studios used footage from the weekend to make a promo trailer.  The weekend was awesome.  Take a look at the embedded promo trailer, or visit givecamp.org to learn more.

I usually listen to Pandora at work. I'd rather listen to my personal library, but Pandora makes for a good second place. There's no question that it beats trying to store / sync untold gigabytes worth of audio on my work computer. Still, sometimes Pandora just doesn't cut it: especially when I want to hear a certain song. So, I decided to use lunch to figure out how to get my music collection into iTunes at work.