Tuesday, February 03, 2009

CruiseControl & SMS

I persuaded my team to use CruiseControl about a month ago. After I got it set up, and a hundred or so successful builds, they wondered if it did anything. The unit tests I had written or adapted from the legacy code were all hapily passing. And then someone forgot to check in a file. The publishers did their job, my teammates wanted them to stop. After we found the mistake and notified the developer, who resolved the problem, all was quiet. That initial event allowed me to show a teammate how to find in the modification log who the last developer to check-in was. The second time the build broke, I was out. He was able to politely remind the developer that they forgot a file (we haven't broadcasted that we are using CruiseControl yet, and so the publishers do not notify the developers for me).
For my second act, I installed and integrated Checkstyle with the build loop. The Sun config file that comes with the Checkstyle distribution resulted in over 2 million errors with our code base; and the log file was over two gigabytes. It also took 16 minutes to execute. I created a new config file, using only the nine hard rules from our coding standard and applied that to only a dozen or so of our source files. The result was still 11,000+ errors. A quick look showed me that most were the use of tab characters and I made quick work of those with VIM, fixing any resulting alignment problems. The final tally: 830 Checkstyle violations. Now we're getting somewhere.
Feeling pretty comfortable with CruiseControl's operation, I decided to tinker. I wanted to get SMS notification of build failures. After some internet searches I found that there is an email address that corresponds to your phone's SMS inbox. It turns out to be a great solution since it requires no extra work in CruiseControl. And the iPhone will allow me to use the link to view the build status. All I have to do now is throttle the messages since it is unlikely I will be able to address a build failure within an hour when I am out of the office.

Monday, November 24, 2008

A potential for involvement

I was reading a article in the NY Times about food and it came to me: Can I volunteer at a local school preparing and cooking healthy lunches? That'd cover a bunch of things I think are important: health, local agriculture, community involvement and education. I have the experience, I can probably manage the time. Imagine if I could replace chicken nuggets with fresh accorn squash... Could I put a hairnet on a sixth grader and have them wash vegetables? 

Wednesday, October 15, 2008

Netbeans and its infernal build.xml files

My appreciation of vim has basically led me to using NetBeans. And because I have very little knowledge about its internals or methods, I am a slave to the silly build files it creates to make the menu items usable. It's not that I cannot create or edit a build file for my projects, indeed they have their own build files which tend to follow a very strict init-clean-compile-test-dist template for targets, but I knew not how to make NetBeans happy with them.
Curious, I looked into the generated build files and realized all I had to do was import the NetBeans generated build file: <import file="nbproject/build-impl.xml">. Now my build file has all the targets the IDE wanted and all the ones I wanted (very important for those build files that pre-date me or the IDE). The result is a happy IDE and a (mostly) unpolluted build file.
I guess the IDE is only integrated for the environment the developers envisioned. 

Friday, August 15, 2008

CruiseControl and JUnit

I've been hooking up my software packages to CruiseControl to facilitate our automated builds. A synopsis of what CruiseControl is:
CruiseControl is a framework for a continuous build process. It includes, but is not limited to, plugins for email notification, Ant, and various source control tools. A web interface is provided to view the details of the current and previous builds.
The builds are currently being executed three times daily via cron job; which is good, better than nothing, but lacks sophistication. CruiseControl can detect when to build by seeing check ins. And I can configure it to flame someone if they break the build.
Well the initial configuration was fairly easy. But I had some tests failing. Turns out some tests use relative paths to some resources. Since CruiseControl is invoking the builds from its directory, these tests err. The resolution was fairly simple: I had to add the dir attribute to the JUnit tasks.
So now I have automated, continuous, intelligent builds with tests. The next step is to setup the artifact publishers so someone can download the latest build from the dashboard. And then to add those flame emails to let people know they broke the build...

Monday, August 11, 2008

More than bullet-points

I took the initiative to plan a presentation to deliver to my co-workers, to illustrate how Solaris packages work and how we (I) use them here to manage our software. The concept is simple, the details many and the man pages are explicit; however I wanted to really drive home a point about these, so like a good Windows using worker-bee, I got busy with PowerPoint.
Now if there's one thing I dislike, it's a 'presentation' where someone puts up a slide show (usually 20 slides long...) and then reads to me bullet-point after bullet-point, until I and everyone else in the room has fallen asleep. I'd rather go to church. And since I like to take my own advice, I often use diagrams, pictures, a few sentences and when all else fails, no more than three bullet-points to convey an idea.
So far, diagrams have been a huge success. If I manage to do it right (and that, my friends, involves a lot of head scratching, some tests and some creativity), the material almost speaks for itself. And people don't completely ignore it.
So, back to packages. How do I present a handful of command-line applications? And then it struck me: I have just installed VMWare, I can get a Solaris 10 x86 disk and I can do it. I will present the material; not a slide-show. So after an hour of Solaris 10 happily installing in the background, I have what I consider the presentation: the actual subject.

Wednesday, August 06, 2008

Testing with Zones

About a year ago I pleaded for a dedicated testing machine; and I got it. These days there is enough demand to use the machine that it has become almost impractical for me to do so. Recently however the machine was loaded with Solaris 10. I had learned previously that Solaris 10 brought with it the notion of zones: essentially a virtual machine. And yesterday I had the epiphany that I could resolve my resource contention; by simply creating a zone for my testing needs (and eventually a zone for any new needs).
I began today attempting to get into the zone I made. It seems the zones are so isolated from the global zone that they inherit no notion of the users who work in the global zone. Nor can I see the file system for the package files I want to test. After setting up a network interface and FTPing in the files, I got to test my packages, in isolation of the other activity on the machine. The other users were oblivious. Another great feature of zones is that I can create a baseline environment at any time by cloning one clean zone. So now I have tests that are independent and repeatable. Now to got them automated...

Tuesday, August 05, 2008

Getting Focused

I've recently had a number of un-fun (e.g. documentation, project estimates) things to do at work. I always find that having to do these tasks results in a significant amount of procrastination; I'd rather be coding. And the realization I've had is that my procrastination is preventing me from getting back to what I like. While I know to break down my coding tasks into small, easily completed bits, I have failed to do so for my other work. And now I have resolved to change this.
Using my favorite task tool, I have begun breaking down these documentation tasks into one-hour segments. Having completed one, I get the satisfaction of crossing it off the list, the knowledge that I have accomplished something (because running code is more gratifying than a few paragraphs) and the benefit of being closer to what I want to be doing. Or if I so desire, I context-switch to something more appealing for an hour.
It's only been a day, so far so good. I suppose it will take me the standard 4 weeks to make it a consistent habit. I already feel better about the day. I also have a clearer picture about tomorrow.

Oh and Jeff Atwood has beaten me to the punch it seems. At least in granularity.