July 15, 2008 at 1:00 pm (Uncategorized)

When I was a boy, I read fantastic science fiction stories, in which the heroes possessed amazing devices.  Some of these devices would allow the heroes access to the full range of human knowledge, at little more than a thought.  Some would grant the heroes instant communication with anyone or everyone.  Some would offer the heroes entertainments, with all of the books, music, or movies every created available whenever the heroes wanted.

Now that I actually carry around anywhere between three and six of these devices on a regular basis, I mostly spend my time annoyed at battery lifetime.


Permalink Leave a Comment

Interesting new build tool: Gradle

July 8, 2008 at 7:55 pm (Coding, Java)

Panning the whirling RSS feeds for nuggets of gold, I came across something I had almost given up on finding:  a build tool that I could imagine giving up Ant for.  Now I’m an Ant fan from way back, having used it In Anger as far back as 1999.  I’ve heard the pitches for Maven, and have been sympathetic, but never made the jump.   It always seemed like something that was good in theory, but which scared me in practice.  The mixed praises and pans that Maven earned from the Massed Mind of the web seemed to cement that opinion, and in spite of some extremely trusted colleagues backing it, I never managed to pull the trigger.    At this point, I’m not sure I will, now that I’ve stumbled across Gradle

Gradle, as the name might suggest, is a Groovy-based tool, defining a simple but powerful DSL (domain specific language) for builds.  Now that doesn’t sound like much.  Every build system has defined a small DSL, going all the way back to the chthonian depths of Make.  But Gradle doesn’t just define a DSL, it defines a Groovy DSL.  That makes all the difference.

For those who haven’t encountered them, it’s tough to describe just how mind-alteringly cool Groovy DSLs are.  Using some very clever punning around its closure syntax, Groovy allows you to build domain specific languages which can be embedded in otherwise vanilla Groovy code, and which can in turn have Groovy fragments embedded in them.  This is incredibly powerful, allowing exactly the sort of promiscuous mixing of declarative and procedural code that a full-featured build system needs.  Groovy DSLs are all, as a mere fact of their existence, Turing complete and able to call upon the full majesty of the Java ecosystem.  They also, again as the merest side-effect of how they are constructed, are able to embed arbitrary DSL code-generation functionality within them, making every Groovy DSL trivially field-extensible.  None of that costs anything to the DSL user, and hardly anything to the DSL creator.  It just works.  Groovy itself is a very nice scripting language, and well worth learning.  Groovy DSLs have potential to be a disruptive technology, blurring the code/data distinction in some extremely powerful ways. (Now if only someone could figure out a good way of documenting them.)

Leveraging the extreme wicked coolness of Groovy DSLs, Gradle fixes the biggest gaps with Ant…

  • Extremely full-featured, declarative dependency structure: Dependencies are declaratively specified as part of the project DSL, and fetched using Ivy as the engine.  Works with Ivy or Maven repositories, simple checked-in lib directories, and a bunch of other repository structures.
  • High-quality and simple multi-module project support:  Project modularization is declaratively specified via the project DSL.  Sub-projects can optionally have their own Gradle build files which inherit in interesting ways from the parent project, but they mostly don’t need to.
  • Configuration via convention: Like Maven, lovingly chosen defaults, cleanly overridable.  Unlike Maven, the conventions are defined via plugins.  The core system knows nothing of them, buying you a degree of independence from build system changes.
  • Familiar, Turing-complete, non-XML script definitions.  Scripts are written in Groovy, with all the power that implies.  Ant tasks are available via Groovy’s built-in (and desperately cool) AntBuilder.
  • Highly extensible and abstractable.  Ant’s extension capabilities ranged from sucktastic in the initial release (no extension other than painfully written and atrociously deployed Java tasks), to merely half-assed by 1.6 (horrid and non-standard macros that were only marginally better than cut-and-paste).   Extension in Gradle is via defining methods and classes in Groovy, which looks just like Java but shorter.  You can either define them inline, or put them in libraries, your call.

…while keeping Ant’s biggest strengths

  • Humility.  Ant always understood that a competent build master will end up automating more sorts of things than the developers of Ant had ever thought of.  Just yesterday I had to automate six different quite complex processes for creating test Derby databases for my Day Job project.  Ant made that easy, in spite it being well outside the conventional concept of “build”.  Creating new sorts of functionality is an in-line activity in Gradle, as it is in Ant.  Creating inline tasks is actually easier in Gradle than in Ant, as they can be written in Groovy, rather than in Ant’s exceedingly weak XML-based scripting language. Maven, OTOH, mostly requires plugins to be created and deployed if you ever wish to do a task no-one else has contemplated, raising the cost of quick scripting greatly.
  • Minimal buy-in.  Ant never required that you change your code structure before you started using it.  The build was subservient to the code, rather than vice versa.  This made it very easy to get Ant working without annoying team-mates who (lamentably) couldn’t care less about the build.   The thing the Maven folk never seemed to realize is that just about every project that converted to Ant early on did so by stealth.  It’s sad that this made a big difference, but such is the way of this fallen world.
  • Platform independence.  It’s Groovy, which is to say it’s the JVM.  Move a build script from my fuel-injected dual-overhead-cam cherry-red MacBook Pro to whatever damn $3.62 Linux partition that Ops rented from some retired Mah Jhong hustler in a back alley of Shenzhen, and it All Still Works.  That probably doesn’t mean much to you whippersnappers, but to us oldsters who lost hours tracking down places where Make didn’t like some damn backslash, it’s worth mentioning.

Put together, that positions Gradle nicely as “a better Ant”, which is something that Maven, for all of it’s strengths, simply can’t be described as.  With Ant development seemingly moribund after 1.7, there’s a lot of potential in being “a better Ant”.  It’s still early days (they are calling the current release 0.2), but I’m definitely putting Gradle on my “technologies to watch” list.

Permalink 4 Comments

When to bet against a software technology

July 7, 2008 at 8:25 am (Career)

No matter how cool it may seem, bet against any software technology…

  • whose only selling point is a 2-4x improvement in speed/cost/quality of a common activity.  2-4x sounds great, but it’s surprisingly not enough to get people to jump.  At current rates of progress, many will figure that they can safely skip over a 3x improvement this year in favor of a probable 10x improvement a couple years down the road
  • that locks you to any particular vendor, with the (admittedly unfortunate) exception of Microsoft.
  • that makes it more difficult to trace errors in software.
  • that requires a greater than $10000US up-front investment by a business to try it out on a live sample project.  These can work, but only at the cost of a lot of career-dulling meetings.
  • that requires valuable business data to be hosted external to the organization.  Because at the end of the day, men with long titles and fancy suits will simply say no.
  • that enhances the power of the Operations group at the expense of Development or Marketing.  There are very few wins to be gained with technologies that favor cost centers over profit centers.
  • makes it harder to reason about the performance characteristics of software (I’m looking at you, AOP).
  • that can only be configured via a graphical user interface
  • that can only be configured using a small, application-specific, visual programming language (bet heavily against these).
  • that claims to decrease the amount of skill necessary to develop software.  These rarely work, and then only in small, discrete niches.  If you manage to find one that works, all you’ve bought yourself is a low-skilled job in a small niche
  • whose only selling point is that it decreases the number of keystrokes required to develop software.  There is at present no keystroke shortage, so optimizing based on keystrokes doesn’t buy you much.  Too often tool vendors aim for clarity and maintainability and only achieve tersesness.
  • which claims to make software development a branch of applied mathematics.  These can actually work, and be really quite beautiful, without being any sort of win.  Good software developers require moderately rare talents and long and expensive training.  Good applied mathematicians require extremely rare talents and even longer and more expensive training.  Do the math: don’t do the math.

Feel free to list your own rules in the comments

Permalink Leave a Comment

When to bet on a software technology

July 7, 2008 at 8:24 am (Career)

If you choose the path of a software developer, your career will consist of a long series of bets on technologies.  More specifically, bets on which software technologies are going to be important six-to-eighteen months from now.    Early in your career, your bets will consist of choosing where to spend your professional development time learning prospective technologies.  Later, your bets will include requests to be placed on “strategic” projects, trying out technologies in small settings before green-lighting their deployment cross-enterprise.  At senior level, you’ll bet by recommending for or against technologies.  Those are the big bets.  If your career is going well, you should be expecting to make one or another of these bets no less than six times per year.

If you bet right, the career benefits are swift and clear, as you get to be the “go-to guy” on the hot new technologies.  Make a run of bad bets, and you could easily find your career stalling, the projects you get are less and less interesting and important.

(Of course, you can choose to avoid all of this chaos, and not make any bets.  In that case, you can skip the professional development time, and only pick up technologies as you are requested to do so.  If this appeals to you, you might consider an exciting career in HVAC or long-haul trucking.  Software development will only hold tears for you.)

Now if I knew any hard-and-fast rules for betting on technologies, I’d be retired on long green earned as a VC, rather than coding in the trenches.  Nevertheless, here’s a few rules of thumb I’ve painfully acquired over the years, that might help if you are looking to become that “go-to guy”.

Bet on any software technology…

  • that offers a 10x improvement in speed/cost/quality for a common activity.  10x is about where people actually get excited about moving to a new technology.  10x improvements also generate a lot of work, as supporting and connecting systems can be profitably extended to optimize for the new capabilities.
  • that opens up new business models.  This is a big one, and why anyone serious about software should be looking into technologies like Amazon EC2 and Google AppEngine.
  • that allows software to be deployed on previously unavailable platforms
  • that connects promiscuously and multifariously with third-party software
  • that increases the clarity and maintainability of shipped code
  • that allows for better management and monitoring of software components
  • that allows interesting new properties of software to be automatically checked.
  • that allows new functionality to be shipped as component libraries.  For all that they feel like crusty old technology, libraries are just about the only workable form of software reuse we know.
  • that increases the returns to software development skill.  An old example would be refactoring IDEs: they make skilled developers more productive, and don’t help unskilled developers much at all.

Next post will be on when to bet against a software technology.  Feel free to add any rules you know of in the comments.

Permalink Leave a Comment

Shockingly powerful Spring 2.5 multiple auto-wiring feature

July 2, 2008 at 10:05 pm (Uncategorized) ()

One functionality that I always felt was missing from Spring 2.0 and earlier was the ability to easily quantify over the components in your application.  For instance, I often want some piece of code to have knowledge of every servlet in my application, or every repository, e.g. to monitor them for component management purposes.  This could be hacked in earlier versions of Spring, but only at the cost of making some of your components dependent on the Spring container, or by using some fairly hairy aspect-oriented trickery.  In Spring 2.5, quantification over components becomes much easier, using the new @Autowired annotation, applied to Collection or array-typed setters.

Here, have some example code:

public interface Rule{…}

public class Rule1 implements Rule {



public class Rule2 implements Rule {


public class RuleEngine {
private Set<Rule> rules;

public void setRules(Set<Rule> rules) {
this.rules = rules;

In this case, Rule1 and Rule2 are some random rules, and are instantiated automatically via Spring 2.5’s component package-scanning functionality.  RuleEngine is also instantiated by package-scanning, and then injected with the set of all Rule components that are in the application context.  At injection time, ruleEngine.setRules() gets called with a Set containing Rule1 and Rule2, which it can then use for whatever nefarious rule-engine purposes it may require.  Note that there are no references to Rule1 or Rule2 anywhere in either the Java code or the Spring configuration.  It’s tough to get much more loosely-coupled than that.

To add a new rule, just create a new class which fulfills the Rule interface, is annotated as a  @Component, and lives in a package that Spring has been instructed to scan for components. The new rule class need not even be shipped in the same jar as the the RuleEngine component or Spring configuration file.  Anywhere in the classpath is fine.   This is weaker than the hot-swapping functionality provided by various application servers and OSGi containers, but does at least allow for separate builds of core components and the “plug-in” components which get automatically injected into them.

Spring 2.5 offers several possibilites for tweaking this plugin behaviour, such as only injecting some annotated subset of your plugin classes.  For instance, here’s a rule engine that only knows about those rules marked as “High Security”

public class HighSecurityRuleEngine {
private Set<Rule> rules;

public void setRules(@HighSecurity Set<Rule> rules) {
this.rules = rules;

where @HighSecurity is an annotation declared as

public @interface HighSecurity {}

But frankly, that’s just gravy.  Just being able to quantify over components using collection-based auto-wiring and interface filtering is more than adequate for my uses.

Permalink Leave a Comment