Crouching Duck Hidden Egg

Build Tools

rwstang — Sun, 28 Jun 2009 13:40:39 +0000

For .NET there is CruiseControl.NET (http://cruisecontrol.sourceforge.net/) and NAnt (http://nant.sourceforge.net/). For Java there is Bamboo
(http://www.atlassian.com/software/bamboo/) and Maven (http://maven.apache.org/). Those are the ones that I’ve used before but there are many others out there that can do the job, especially for Java. There are plenty of options for Java such as Hudson, Ant, CruiseControl, Continuum, etc. We’re using Bamboo because we use Jira (Issue Tracking) and Crucible (Code Review), which have integration options with Bamboo.

Automated build systems such as CruiseControl.NET and Bamboo are only part of the puzzle. NAnt scripts are responsible for project specific build and deployment actions. In the case of CruiseControl, it can detect changes to the source code and run NAnt scripts to perform whatever it is the build master wants, as long as NAnt is capable of it. NAnt is capable of executing other programs and tools as part of it’s task. The point I’m trying to make here is that your NAnt/Ant scripts would be where you will spend most of your time as the Continuous Integration system such as CruiseControl.NET is there for the same reason for every project. So if you want to get your head around the what and how of continuous integration, look into NAnt/Ant.

The above seems like I’ve just thrown around names of tools that you could have googled but it is really there to set the context for the upcoming posts. The next post will be about continuous integration in general. It will be theory with contextual examples based on the mentioned tools.

Role and Challenges

rwstang — Sat, 27 Jun 2009 16:23:51 +0000

I’ve only had some short and broken experiences as the role of build master and only in the .NET world. Despite that, I’ve got some insight and understanding on the role of a build master and their responsibilities. The role and responsibilities of a build master varies from company to company and from team to team because there are many challenges that build masters may face and these challenges are sometimes the responsibilities of others. For example, some build masters in a company who has an IT Infrastructure team won’t have to deal with setting up servers, networks and system environmental configurations.

My roles have varied from only having to setup CruiseControl.NET (http://confluence.public.thoughtworks.org/display/CCNET) and write project specific NAnt (http://nant.sourceforge.net/) scripts to having to set up an operating system, configurate the OS, source control and databases required for a project. The experience over the last couple of years has given me enough .NET build skills to trudge through my tasks. This blog is for me to share my experiences as a build master who’s constantly running into issues, roadblocks and learning. Hopefully I’ll have the motivation to keep this blog rolling.

Back to the topic. The role of a build master is primarily to provide an automated environment for project work. There are some blatently obvious things that can be automated in the software development cycle, especially when it comes to projects involving more than one developer. In a TDD project, Compile, Test, Report and Deploy are some of the things that needs to happen all the time. Since these tasks are done frequently, it makes sense to automate them. When developers check-in a piece of work into their source repository (I’ve used SourceSafe and SVN), it’s possible to automatically pick up the newest version of the code, compile it, run all tests available on the project, run all sorts of reports against the project and deploy the project to a server, where it can be further tested in a running environment. The role of the build master is to make the automation possible in a way such that developers don’t need to do anything beyond checking in their work to their source control. This could mean the build master needs to setup a build server, set up source control, build tools, understand the project and write build scripts for the project.

To me, a build master shouldn’t have to setup the network, routes and server permissions but I’ve had to do it before, just to get the job done. The challenges of setting up a network is unpredictable as servers can be distributed between onsite and in remote data centers. Router access is not always available, server root access is not always available, etc. Build scripts and server setups vary from project to project and different deployment strategies for the same project requires different build scripts yet again. In summary, there are many uncertainties when it comes to being a build master and your job becomes even harder when there are so many moving parts that can break the work that you’ve set up.

In summary, build master can be a fustrating, stressful and challenging role but if it’s done right, I’ve heard that you can sit back and read the news while your build scripts do the work day after day. I haven’t yet been able to sit back as a build master yet and I don’t see how I’ll ever be able to…

Upcoming posts will include tips, tutorials and my experiences with how to deal with specific issues.

Chrome RSS Support

rwstang — Tue, 23 Jun 2009 15:04:11 +0000

I’ve been using Chrome for the past month and have turned it into my default browser for the 3 computers that I use for the last two weeks and only now have I noticed that there is no RSS support. It can render the xml and such forth but it doesn’t work like the one that I’m used to in Firefox, where the subscribed feeds will show up and auto-update.

Initially I thought I was just stupid and had to turn it on somewhere but after some quick googling, I found http://code.google.com/p/chromium/issues/detail?id=84#c83 (Chrome issue). The functionality is in the works. So stay tuned to the logged issue for further progression with the much needed functionality.

Stressed?

rwstang — Thu, 18 Jun 2009 14:06:14 +0000

I have confirmed a way to destress that works for me. I like driving and I like the songs that I like. I found reason to zoom around the highway in the last few nights and realised that the music and driving combo really works. Works especially well for me when I changed the cd back to my older ones and sing to it. Brings back the good times. If driving and music is your thing, do it:)

I don't know what to call it…

rwstang — Thu, 18 Jun 2009 12:47:52 +0000

Ignorance? Lacking understanding? Not caring? or simply having a laugh? I don’t know. What I’m talking about is when a new team takes over the work of another team. Part of the new team whines, bitches and laughs at the work that has landed on their plate. The focus is always on the seemingly stupid and inefficient ways of how the work was done. Yes, in most of the cases, the work is poorly designed, poorly implemented to the point where the original intention of the author could not be deciphered by reading the code. The reactions are usually valid and it gets even funnier when the new team speculates the reasons for the poor work. Ever been there?

Fortunately/unfortunately, I am a member of this new team and a member of the previous team who did the ‘crap’ work.

It’s so easy to be critical and harsh about old work, especially if you now have to fix the mess and the original author isn’t around to explain. But now that I have been on both sides of the equation, I know why certain things were done in such a way, I know the circumstances that the team worked under and I have context on alot of the code’s inefficiencies. I don’t whine and bitch about the poor quality because I know. The situation is very similar to the champion of sports tournament criticising the runner up from the previous year of the same comp. It’s poor sportsmenship to begin with and it’s just all trash talk from the current champions, both of which I don’t like.

I guess the point I’m trying to get across is if you’re ever passed over work before your time and you realise how poorly the work has been done, suck it in and do your job. Especially if it was a big piece of work, show some respect. You wouldn’t bitch and whine at your own work 3 years down the track when you revisit it and realise how much of an idiot you were back then right? You’d get your head down and fix it. Do it.

Cater For The Ignorant – For All Our Sakes

rwstang — Sun, 07 Jun 2009 13:33:53 +0000

The context of this post is that a design of a data transfer object (dto) was tied down in the form of a map and it was meant to handle generics. The assumption at the time of the design was that the dto would be small in size so the performance hit to cater for generics would be minimal. The code for managing the dto was written and tested correctly and the work was marked complete.

A year down the track the performance of the system is unacceptable to the point of breaking timeout thresholds. After some high level diagnosis with a profiler, it was observed that the dto has grown to a size enough to affect the performance of the system. The dto was also thrown through more ‘pipes’ in the system, further amplifying the effects of the bloated dto.

I can’t think of many ways to address this problem to avoid it again in the future. Have constraints of the use of a design in writing? Have constraints programatically applied in the system for the design in question? Having performance threshold tests will only deal with the result, not the underlying problem, which is developers misusing/misunderstanding existing code implementations. Only designing for all cases all the time is also not always feasible and it’s even harder when generics are involved. All I can truly rely on is programatically constraining the use of designs… suggestions welcome.

The message here is that when designing an implementation of anything, we need to cater for the misuse of it. Document disclaimers, use programatic checks, etc to avoid the design being used in the wrong way. Otherwise you’ll be stuck with a situation where you have this shared resource used throughout a system, affecting many modules, that needs to be refactored, which could spawn more work…

Not catering for the ingorant is easy to say but it could be worthwhile dealing with the potential problem if you consider the poor buggers who may have to deal with the problem.

Team Leading with Unit Tests

rwstang — Wed, 20 May 2009 14:51:27 +0000

Using unit tests is one of those things many developers would have come across as part of their QA or TDD approach to projects. Unit tests can contribute to specifying requirements for code and can be used for regression testing.

The team that I am working with came up with a way to use unit tests that I’ve never contemplated before and that is to use unit tests for prioritising work for developers in your team. We had issues with developers not focusing their efforts on high priorities (or they’ve had the priorities wrong) so to counter this issue, a few of us thought about distributing unit tests in the order that we want the work done in. The unit tests (if written well) will communicate the requirements definitively and the units tests will fulfill there usual expected duties for QA. Sounds like win for our issue.

We haven’t gone ahead with the plan yet and I’m sure we aren’t the first ones to come up with this idea so if you’ve used this idea before, write back. Or if you’ve solved the same issue with other methods (short of firing the developer) drop a comment also. For all others, it’s just food for thought.

About Time…

rwstang — Sat, 16 May 2009 18:07:44 +0000

The first post for the site should have been published months ago but I haven’t found the time to post anything when there was something to post about. When I had time to post, there was no longer anything worth posting.

The reason behind that is the posts intended for this site is meant to be technical and when I do come across something worth posting, it usually means I’m working very hard and hence have no time to post it. Once the work is done, it doesn’t seem like it’s worth posting anymore. Stupid~

Why is it now that I have time to post? It’s 4am here and I can’t sleep.