Groovy’s Collection.minus(Collection)

If you’ve done much Groovy development, you’ve probably used all the handy helper methods that it provides to augment the core JRE classes.  Collections, in particular, have some really helpful additions in the form of operator extension.  For example, the minus operator works like this:

assert [1, "a", true, true, false, 5.3] - [true, 5.3] == [1, "a", false]

This is all sorts of handy, but I found an interesting bug in Groovy 1.8.4′s implementation.  Behind the scenes, it uses two different Comparators to do the equality checks needed to perform the subtraction.  However, the Comparators are a little off…

The first Comparator is actually just the DefaultTypeTransformation.compareTo method, and it gracefully handles non-Comparable, non-equal objects with the same hashCode.  It also handles nulls (which are always first), and a bunch of standard type conversions (e.g., char -> String when compared to a String).

The second Comparator, however, it less well behaved.  It’s called NumberAwareComparator, and delegates to DefaultTypeTransformation.compareTo first.  But if that fails, it falls back to a hashCode comparison, which creates a very interesting bug: if two non-equal objects have the same hashCode, NumberAwareComparator will return zero from it’s compareTo method, which will be interpreted as equality in a variety of contexts.

The workaround that I’ve found is to explicitly implement Comparable in the domain model at the appropriate level(s) so that you always have a mutually-comparable collection, and you can implement compareTo in a way consistent with equals.  Implementing Comparable like this will ensure that DefaultTypeTransformation.compareTo will successfully handle the comparison, thus preventing falling through to NumberAwareComparator.

Sometimes, it is the library.  : )

Domino Functions

At Gram and Gramp’s this weekend we played dominos, and the question came up of counting a set of dominos.  In particular, Gramps wanted to know how many dominos there were in a set with double twelves.

After we were done playing, we lined them all up in the “domino triangle” with and Emery and I figured it out.    The domino triangle is simply an arrangement of dominos with double zero in one corner, the zero-one next to it, followed by zero-two (etc.), and with the double one at the end, followed by the double two (etc.).  Here is a partial rendering of the triangle for our double nine set:

+-+   +-+         +-+
|0|   |0|         |0|
+-+   +-+   ...   +-+
|0|   |1|         |9|
+-+   +-+         +-+

+-+         +-+
|1|         |1|
+-+   ...   +-+
|1|         |9|
+-+         +-+

...

+-+
|9|
+-+
|9|
+-+

To start, let n equal the number of the largest double (twelve, if our case).  We’re looking for f(n), which is the number of dominos in a set with largest double n.  Simply counting the dominos in the triangle gives us a values for our function, but not the one we want:

  n  | f(n)
-----+-------
  0  |   1
  6  |  28
  9  |  55
 12  |  ??

Before dealing with f(n), let g(n) denote the number of doubles in the set.  A quick glance at the triangle will show that the formula for this function is

g(n)=n+1

because there is one double for each

[0, n] = \{x \in \mathbb{N} \,|\,0 \le x \le n\}

Now thinking back to the “domino triangle”, it’s easy to see that g(n) is both the width (base) and the height of the triangle.  If you recall from planar geometry, the area of a triangle is half it’s base times height:

\frac{base \times height}{2}

So a first guess at f(n) would be this:

f(n)=\frac{(g(n))^2}{2}

But that isn’t correct.  Thinking back to the domino triangle quickly shows why.  If you were to take two copies of the triangle to make a rectangle (the reason the triangle area formula works), you’d see that you’d have to offset them by one domino in one direction, so the rectangle is actually g(n) by g(n) + 1.  So the right formula is this:

f(n)=\frac{g(n)\,(g(n) + 1)}{2}

Simplifying by inlining the formula for g(n) yields:

f(n)=\frac{(n + 1)(n + 2)}{2}

This turns out to be the correct formula, and yields 91 when its argument is twelve.  Thus a set of double twelve dominos will have 91 dominos.

What was particularly striking as Emery and I worked through the formulas, is that Emery had more trouble with the larger multiplication (which he hasn’t done in school) than following the function notation, doing the step-wise evaluation of the functions, and even the function nesting.

Branching and Refactoring

Mark Mandel made an interesting post about branching strategies when you have both feature development and refactoring to perform together.  Specifically, he’s wondering how best to ensure you don’t orphan the refactoring if you abandon the feature, since the refactoring might be useful elsewhere.

I posted my comments, and you should too.  Effectively using your tools is vital to success in the software world, and no tool has more potential value (and potential pitfalls) than source control.

Everything you care about having around tomorrow should be stored in source control.  That obviously means your source code, but also includes your build/deploy scripts, editor/IDE config files, design documents, etc.

Hql For Groovier Hibernate

If you’ve done much with Groovy, you probably know about the slick Sql class that it provides for interfacing with a SQL datastore across JDBC. It’s not perfect, but it’s certainly easy.  I was working on a Hibernate project and wanted the same thing for my HQL queries, so I threw together a simple Hql class to provide the same sort of behaviour.

Like Sql, it can be parameterized with a connection source (a SessionFactory in this case) or a specific connection (a Session).  If given a SessionFactory, it’ll use getCurrentSession() to grab a Session when one is needed, which allows you to wire a single Hql instance up in your Spring config, supply it your SessionFactory, and then inject the Hql into all your persistence-aware beans and just use it.

It also provides a public getSession() method for returning the current session to those same beans, which means you can just inject the Hql instance and not have to also inject the SessionFactory instance if you’re feeling lazy (or doing some quick prototyping).  I will leave whether that’s an appropriate long-term approach for a different discussion.

Here she be:

import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;

/**
 * I aim to be sort of like Groovy's builtin Sql class, except for Hql
 * @author bboisvert@gmail.com
 *
 */
class Hql {

  private Session __sess
  private SessionFactory __sf

  def Hql(SessionFactory sf) {
    __sf = sf
  }

  def Hql(Session s) {
    __sess = s
  }

  SessionFactory getSessionFactory() {
    __sf
  }

  Session getSession() {
    __sess ?: __sf.currentSession
  }

  Object unique(String hql, List params=null) {
    new Statement(hql, params).query(session).uniqueResult()
  }

  Object unique(GString gstring) {
    new Statement(gstring).query(session).uniqueResult()
  }

  List list(String hql, List params=[], Integer firstResult=null, Integer maxResults=null) {
    new Statement(hql, params, firstResult, maxResults).query(session).list()
  }

  List list(GString gstring, Integer firstResult=null, Integer maxResults=null) {
    new Statement(gstring, firstResult, maxResults).query(session).list()
  }

  private class Statement {
    String hql
    List params
    Integer firstResult
    Integer maxResults

    def Statement(String hql, List params, Integer firstResult=null, Integer maxResults=null) {
      this.hql = hql
      this.params = params ?: []
      this.firstResult = firstResult
      this.maxResults = maxResults
    }

    def Statement(GString gstring, Integer firstResult=null, Integer maxResults=null) {
      def hql = new StringBuilder()
      def params = []
      def prefix
      gstring.strings.eachWithIndex { str, i ->
        if (i > 0) {
          def v = gstring.getValue(i - 1)
          if (v != null) {
            hql.append(prefix).append("?")
            params += v
          } else {
            if (prefix.trim().endsWith('=')) {
              prefix = prefix.replaceFirst(/=(\s*)$/, ' is$1')
            }
            hql.append(prefix).append("null")
          }
        }
        prefix = str
      }
      hql.append(gstring.strings.last())
      hql = hql.toString()
      this.hql = hql
      this.params = params
      this.firstResult = firstResult
      this.maxResults = maxResults
    }

    Query query(Session sess) {
      def q = sess.createQuery(hql)
      params.eachWithIndex { o, i ->
        q.setParameter(i, o)
      }
      if (firstResult != null) {
        q.firstResult = firstResult
      }
      if (maxResults != null) {
        q.maxResults = maxResults
      }
      q
    }
  }
}

I am a Programmer Luddite

Several years ago I decided that I didn’t want to use the ‘barneyb.com‘ domain for my personal blog anymore.  I’m not sure what the catalyst was, or even whether there was a catalyst, but I do know that there were two primary factors at play.  Those factors have remained constant (if not increasing in relevance) over the intervening years, and I am now happy to say I have a new blog here at programmerluddite.com.  And yes, ludditeprogrammer.com will also work for those of you who, like me, can never get the words in the right order.

The first factor was the morass that barneyb.com had become.  It has housed between seven and twelve WordPress blogs, several large-scape web apps, a pile of little utilities and demo apps for various purposes, all of my self-contained open source projects, and eight years worth of blog posts.  The domain has lived on an old Dell laptop, an old workstation in my basement, a massively shared PHP host, a dedicated server, and now on EC2.  This has yielded a URL structure which is somewhat convoluted and an Apache HTTPD configuration which was even more insane.

The second factor was that the history of BarneyBlog (my blog at barneyb.com) indicated a trajectory which didn’t really match real life.  I don’t think it accurately reflects the developer that I am, let alone the person I am.  Which isn’t to say that it doesn’t represent reality, of course.  At the micro level, each individual post is a valid glimpse into my world, but the whole doesn’t seem to match up at the macro level.

The net of it was that I wanted a new projection of myself onto the web.

About the same time I realized just how little affinity I have for technology in general.  Technology is a tool, and while it can be a useful tool, no tool can hope to exist for it’s own sake.  Tools “buy” their existence through utility; non-useful tools aren’t tools, they’re just stuff.  A huge swath of technology falls into this latter category, and I seem to be fairly unique amongst my peers in judging such tech purely on utility.  The “luddite” moniker is not a perfect fit, but it certainly conjures up the appropriate imagery.

The other half of the name was somewhat more difficult to pin down.  I’ve spent a lot of time over the past five or seven years thinking about what label best describes what I do in my chosen career.  None of them seem to match up perfectly.  I’ve adopted the term “software craftsman”, but calling this site “software craftsman luddite” seemed rather pretentious.  “Programmer”, I think, indicates a similar love of the act of programming.  I.e., the love of programming itself, not the creation of software (which necessarily has an external purpose).  Yes, I appreciate the irony.

I write code to fulfill needs.  I create tools, some for me and some for others.  But my love of software development is selfish.  Meeting people’s needs with software is pleasing; crafting beautiful software is satisfying.  I solve problems with technology.  I eschew technology for it’s own sake.  I am a programmer luddite.