Hudson

Good Continuous Integration tool. Nice charts, easy to use, fairly flexible out of the box.   A _lot_ less setup work than CruiseControl.  And the plugin system is well done, and pretty nifty.

Struts2

An incoherent mess.  Documentation is spotty, uses a lot of contrived toy examples that blow up on anything more complex than hello world.  Documentation is also simply wrong in some cases (for example, the ‘var’ attribute on the iterator tag is not valid according to the TLD).  Namespaces are nice in theory, but frustrating in practice.   I can’t get the wildcard action management to work reliably, although this may just be pilot error.

Good things: 

The integration with Spring is nice, and I haven’t seen a web framework yet that is more friendly to unit testing.  When it works properly, the wildcarding is very nice.   The Action.execute() model is useful, and easy in concept.

Let’s say you’re using Hudson as your build/Continuous Integration tool. And let’s assume you have some jobs running inside Hudson that you want to keep running, even if the build machine blows up. You probably want to maintain:

• Hudson itself
• All the plugins
• The overall configuration
• The per-job configuration

Naturally, then, your thoughts should turn to “How do I put the Hudson configuration into source control?” Here’s what you do:

1. Make sure your builds are configured and working to your satisfaction, in a directory that I will from now on refer to as HUDSON_HOME.
2. Copy the entire HUDSON_HOME directory tree to a temporary location called “versioned_build”
   1. In the versioned_build directory, you’ll find the jobs directory, and under that, a directory for each job.
   2. Inside each job directory, you’ll find configuration .xml files and other miscellaneous files, and you’ll find two subdirectories:
      • workspace
      • builds
   3. Empty those two subdirectories of all files, but do not delete the subdirectories.
      
3. Repeat this “clean out” process for each job.
4. import the entire “versioned_build” directory tree into source management.

Now, you have your Hudson configuration in source control. You can start it up, and assuming HUDSON_HOME is set right (see below), you should see your dashboard, and your jobs listed, and properly configured.

Issues

• You may have to manually kick off your jobs to “prime the pump”
• Your build number will not start at 0 unless you do not archive the nextBuildNumber file
• Your HUDSON_HOME environment variable may be incorrect for your machine (see below)

HUDSON_HOME Portability

For ease of checkout and maintenance, I like the following directory setup:

$HUDSON_HOME/

• hudson/
  • hudson.war
• jobs/
  • Your Hudson Jobs Here
• plugins/
  • Your Hudson Plugins Here

Using this configuration, you can create a file in $HUDSON_HOME called, say, hudson.sh, which would look a little something like this:

---

#!/bin/sh

export HUDSON_HOME=.

export CVS_RSH=/usr/bin/ssh

java -jar hudson/hudson.war

---

Using this structure, and that hudson.sh script (I presume you can do something similar in Windows) gives you the following benefits:

1. Your entire Hudson system, including the Hudson war file and the launcher script are all maintained as part of the repository.
2. You don’t have to set HUDSON_HOME whenever you check the system out of source control – it’s already set by default to the current directory. As long as you run hudson.sh in its own directory, you’ll get the correct value for HUDSON_HOME

Learn from my mistakes!

• Unless you absolutely must, don’t tell Hudson where to find Ant or the JDK. If they’re on your path, Hudson will find them on its own. If you set them for your build machine, chances are that on the checkout machine they won’t be in exactly the same place

A commenter on a blog I read said the old chestnut:  “for the 1,257th time, someone name something new and revolutionary that’s come out of open source. Th incentive that drives creativity isn’t there. Real artists see no virtue in being starving artists.”

So I thought I would compile a list of great software projects that were built in an open-source way – i.e. not for profit, and with source that was freely shared with others.

This is just a tentative list – I’m sure there are mistakes, and please feel free to correct in the comments.  Also, if you can think of other revolutionary software, please add it.

1. Rails – combining the various aspects of web development into a seamless package was certainly revolutionary (to me).  And it was open source from the beginning.  Don’t like Rails?  Django was built the same way.
2. emacs – certainly open source, and was the first text editor that I know of that incorporated a programming language as part of its core functionality.
3. Internet News – the servers and readers were all oen source – this was the first “Internet-scale” forum
4. DNS – created by a scientist, specced via RFC and deployed freely.
5. Wiki – the original WikiWikiWeb from Ward Cunningham wasn’t open source, but it was shared and available, and he (as far as I can tell) took no compensation for it
6. IRC – was it open source?
7. Sendmail – was it revolutionary?
8. Jabber?

I look forward to your suggestions.

The Audacity port for MacOs X is kinda sparse on details of how to install and use it.

1) You need to copy the entire contents of the .DMG file to your hard drive, and run the app by launching it from that directory (i.e. don’t drag the executable from the DMG into your Applications directory)

2) The LAME Mp3 encoder that you download is named quite differently – it’s called libmp3lame.so , which is different from what the Audacity website says, and different from what the Audacity program says it needs (libmp3lame.dylib). Simple fix: copy libmp3lame.so from the zip file, put it somewhere on your machine, and then rename it to libmp3lame.dylib

This headline blew me away:

11 Reasons to give Microsoft Vista a chance

Think about that for a second.  When have people ever had to attempt to justify or cajole people into trying a new Microsoft OS?    And then there’s Office 07. It’s even worse – people aren’t even trying to justify why you should “give it a chance”.  As far as I can tell, Office 2007 is DOA, in terms of excitement, buzz or anything.
First – kudos to Microsoft on Windows XP and Office 2003.  Clearly, those are two very effective and well done systems if people don’t feel any need to upgrade.

Second – what does this mean?  It seems quite ominous, in relative terms.  There’s no doubt that they’ll continue to make plenty of money, but it could be that the upgrade cycle is going to slow down considerably.  We shall see.