a little madness

A man needs a little madness, or else he never dares cut the rope and be free -Nikos Kazantzakis

Zutubi

Archive for November, 2006

Get More Out Of Your Continuous Integration Server With Personal Builds

The headline new feature in Pulse 1.2 is personal builds. A personal build is a build of the current state of your working copy on the Pulse server. This allows you to test your changes before you commit them to version control. The most obvious advantage of this is that you don’t have to taint your shared source base with untested code to get a CI build. You test first, then commit when you are happy. However, there are also some less obvious advantages:

  • Multiplatform testing: Pulse supports distributing a build across multiple agents in parallel. This allows you to easily test on multiple platforms. Couple this with personal builds, and you can easily test code on platforms other than your preferred development platform while you develop. No need to struggle with slow builds over a networked file system, or to manually move the code about to test.
  • More efficient resource usage: you can submit a personal build to your Pulse build farm and still have your development machine free for other tasks. You can also make use of free developer machines as Pulse agents, but that is for another post :).
  • Full reporting: just like every other build, Pulse extracts and reports interesting information for personal builds via a rich web interface. This beats digging through hundreds of lines of build logs and scratching up test reports to find the relevant info. Pulse can also be configured to send you notifications when personal builds complete, just like a CI build. You can even customise both the information Pulse extracts from the logs and the format of the notification messages.
  • Build history: Pulse will remember your recent personal builds (as many as you choose) and keep the results available for browsing. This makes it possible to refer back to an earlier issue without scrolling frantically in your console buffer (if you’re lucky enough to have the output at all!).

Personal builds are just one way in which we are making Pulse do more than your regular continuous integration server. From the start, we have seen Pulse as not just a server that sits on the sideline, but as a tool that you can leverage during every day development. This is why we have a strong focus on the developer in Pulse: every developer has their own account with a configurable dashboard and very flexible notification settings. Adding personal builds to the mix expands on what you can do with Pulse as you develop, and it is just one of a suite of tools we have or plan to add to Pulse in the near future.

Anyhow, I hope I’ve piqued your interest in the idea. If so, check out the Early Access Page for Pulse 1.2, and enjoy!

Article: Automated Releases

In this article, we look into automating the release process. We begin by reviewing the benefits of automated releases. We then take a look at common steps involved in the automation process, and some of the challenges they may present.

Read the full article at zutubi.com.

Pulse 1.2 M2

Pulse 1.2 M2 has been released! This is the second milestone in the 1.2 series. New features include:

  • Project groups: manage projects by organising them into groups.
  • Change Viewers: an easier, more powerful way to link changelists and files to external viewers such as Fisheye.
  • Commit message transformers: powerful tools for transforming commit messages, for linking to external tools or highlighting details.
  • Improved remote API: new functions for managing projects, users and agents.
  • Bootstrap improvements: realtime output and the ability to cancel during bootstrapping.
  • All-in-one packaging: download agent and tools packages from your Pulse server.
  • Simpler tools configuration: configure the personal build client without editing any files.

See the early access page for M2 packages and full details.

Java 1.6: Finally Integrating With The Underlying Platform?

We all know the Java promise, Write Once Run Anywhere. And we all know some things are too good to be true. On the one hand, there are those features that don’t quite work the same on different platforms. That’s just a fact of life in portable programming, which I can deal with. On the other hand, there is the lowest common denominator syndrome. Important features that are only available on some platforms are non-existent in the Java APIs. The excuse for the absence of such APIs is, of course, that they can’t be implemented on all platforms. This I can’t stand1. I don’t expect every platform-specific API to be exposed, but some are just too important to ignore. Unfortunately for Java programmers, Sun has managed to ignore several for quite some time, for example:

  • Unix style file permissions: applications that work with Files (yes, there are a few of them) often need access to the read/write/execute permissions. I have seen (and written) plenty of ugly workarounds to use the stat/chmod commands to achieve the desired result. A request for this functionality can be found in the bug database from as early as 1997. Sure, the permission systems are different on other platforms (notably Windows), but you can cover a huge percentage of use cases with a small amount of work. Finally, in Mustang, we have the ability to get and set the permissions.
  • Free disk space: those applications working with the file system may also want to make sure they don’t fill it. It is a lot easier to prevent disk exhaustion than to recover from it. Looking back, poor Java developers have been hoping for this ability since 1997. Finally, Mustang delivers.
  • Masked command line input: the primitive Java APIs for command line interaction make it near impossible to create a usable command line interface. An example of something simple which you cannot do without crazy workarounds is prompt for masked input, e.g. to get a password. yep, you guessed it, there is a request from way back in 1997. Finally, in Mustang, we have the new java.io.Console class that provides a readPassword method.
  • System tray icons: many applications that wish to integrate with popular desktops on both Windows and Unix need the ability to use the system tray. It’s an expected part of the user’s desktop experience. The earliest request I found for this one is from 2000. The nice part is the Mustang support grew from an external project, so in this case the users were a bit more empowered.

It’s quite sad that Java developers have had to wait a decade for such commonly-required and relatively simple APIs. No wonder Java has had trouble getting a foothold on the desktop when it has been so difficult to make an application that integrates well with the underlying platform. I just hope the arrival of this new functionality in Mustang is a sign of a new attitude towards such features. No more hiding behind the platform independence argument, time to just get on and give people the tools they need to get the job done.


1: It’s worth noting that this sort of attitude is not restricted to the Java community. I can’t count the number of times that I have seen people in the C++ community reject ideas for additions to the standard library because “C++ runs on platforms that don’t even have a file system”. Who cares when 90% of C++ code runs on systems that could use this functionality!


Interested in automated builds? Pulse 1.2 is now in Early Access Release. Check it out!