A A C I O T
A B I L T Y
A B J M O Qu
A C D E M P
A C E L R S
A D E N V Z
A H M O R S
B F I O R X
D E N O S W
D K N O T U
E E F H I Y
E G I N T V
E G K L U Y
E H I N P S
E L P S T U
G I L R U W

A A A F R S
A A E E E E
A A F I R S
A D E N N N
A E E E E M
A E E G M U
A E G M N N
A F I R S Y
B J K Qu X Z
C C E N S T
C E I I L T
C E I L P T
C E I P S T
D D H N O T
D H H L O R
D H L N O R
D H L N O R
E I I I T T
E M O T T T
E N S S S U
F I P R S Y
G O R R V W
I P R R R Y
N O O T U W
O O O T T U

Usage

Here is a simple CFML function which accepts a board definition and returns an array representing a "roll" of the grid:

<cffunction name="roll" output="false" returntype="array">

   <cfargument name="board" type="string" required="true" />
   <cfset var result = [] />
   <cfloop list="#board#" index="die" delimiters="#chr(10)#">

      <cfset die = listToArray(die, ' ') />
      <cfset arrayAppend(result, die[randRange(1, arrayLen(die))]) />
   </cfloop>
   <cfset createObject('java', 'java.util.Collections').shuffle(result) />
   <cfreturn result />
</cffunction>

And the result of executing it on the original board:

[N, T, W, A, B, Qu, B, D, L, M, D, H, D, L, G, V]

Here's a Groovy Closure which does the same thing:

{
   it = it.tokenize('\n')
      .collect{ it.tokenize(' ') }
      .collect{ it[new Random().nextInt(it.size)] }
   Collections.shuffle(it) // icky!
   it
}

And the result of executing it on the big board:

[N, E, G, N, N, C, S, A, F, E, U, N, H, I, P, H, C, T, T, O, I, O, Qu, T, T]

NB: The source for this post can be found at http://www.barneyb.com/boggle/.  Any updates I may have will go there.

Gravity, however, is kind of nasty to work with (from a computational perspective), particularly in a game situation (where you want realism, but not so real the game play sucks).  Fortunately, it's also exactly the kind of thing that I enjoy wasting my free time playing with.  So I threw together a simple model in Groovy, including a little type system and DSL to help keep my numbers straight.

So now when I divide a Force by a Mass, I'll get an Acceleration back.  Or if I multiply an Acceleration by a Time, I'll get a Velocity.  This was a huge win.  In the world of paper calculations, you don't do just arithmetic, you do unit algebra as well, which helps you ensure your answer makes sense (e.g., if you solve for velocity and get units of "meters per kilogram second", you screwed up somewhere).  But with a computer you don't have units, so I employed a simple type system to afford the same check I'd usually get from unit algebra.  And Groovy makes it remarkably easy to create both an expressive type system and a simple syntax (via operator overloading).

Then I hacked up Processing ever so slightly so I could implement a PApplet in Groovy and avoid the compilation step, and built a simple viewer for the model.  Emphasis on "simple".  Here's a capture with three bodies:

The bodies' sizes represent their relative mass, the green lines represent gravitation between them, the red lines are the velocity vector (per body), and the pink lines are acceleration (also per body).  Here's a few seconds later in the same simulation:

Now, because the bodies are far closer, the forces between them are much greater, which is going to result in a couple fairly impressive slingshots in a moment.  They've also picked up a fair amount of speed, though their active acceleration has surpassed their velocities (i.e., slingshots are imminent).  Here's after the slingshots have happened:

After the two larger bodies slingshotted around each other, the two smaller bodies did the same thing, resulting in a rapidly expanding model.  As you can see the forces are falling away, though the smallest and largest bodies will soon meet up and cross paths.  The velocity of the little one is high enough that the big one can't slow it down enough to do more than deflect it upward a bit.

Processing again completely delivered on it's promise of providing a remarkably simple way to sketch out visual stuff.  Simple event handling, simple setup, a simple draw loop, and solid primitives.  I need to do a little mucking about, but adding 3D support (which the model handles, but the viewer doesn't) will be similarly trivial: flip the "use 3D" bit, and add 'z' coordinates from the model in the various calls.  Very nice, especially when coupled with the Groovy syntax and capabilities.

An interesting project, though we'll see how generally useful.  Code, of course, is available from SVN.  It's a single Eclipse project, including Groovy, Processing, the hacked PApplet (from Processing), the model and the viewer applet.  Check it out and run driver.groovy to see it in action.  While running SPACE will pause/unpause the action, though there is currently no way to rewind/reset the simulation.  If you don't want to check out the project, you can browse it directly.  The interesting bits are in the /src/com/barneyb/gravity/ package.

createObject("java", "coldfusion.server.ServiceFactory")
  .dataSourceService.getDatasource("myDSN")

Unfortunately, this doesn't work on Railo, because the result isn't actually a javax.sql.DataSource, it just looks like one (see RAILO-43).  To put that another way, it's duck typed.

Fortunately, Groovy's "fake" interfaces make beating the typechecks fairly trivial (if kind of ugly):

  def rds = variables.my.datasource
  variables.my.datasource = {
    rds.getConnection()
  } as javax.sql.DataSource

The CFSET gets the "datasource" as normal, and then the little Groovy scriptlet simply wraps it with a closure and tells it to pretend to be a javax.sql.DataSource. The game Escape from Tarkov has one important feature: after your death in a RAID, you lose your equipment. To prevent the loss of important equipment in the game, there are special sites with eft roubles you can always get top equipment and kill all pepegas squad. The items you store from needmana will not disappear. There are three types of containers in total. Alpha, Beta, and Gamma. These containers differ in their size. Usually, these containers should store the most important equipment-maps, ammunition, keys, and so on.  In this case we're assuming that the only method on DataSource that will be invoked is getConnection(), which is the usual case.  If you need to support other methods you'd need to go the Map-as-interface route.

Now we can use variables.my.datasource as a javax.sql.DataSource.  Yay!  Unfortunately, you have to use this sort of snippet everywhere you need a DataSource in your Railo apps, but hopefully that'll get fixed.

For more info on Groovy interfaces, the docs are at http://groovy.codehaus.org/Groovy+way+to+implement+interfaces.

Using multiple languages has a bit of a learning curve but it pays off, and more quickly than you think.  Language selection and design is a vital aspect to being a successful developer, both for individual projects and as part of your continuing career.

I'll probably give the presentation again on CFMeetup at some point this year, and maybe at a user group or two, so if you missed it all is not lost.  Unfortunately (or fortunately), cf.objective() is so content-rich that it's hard to get to every session you want, so if you missed it you can probably get a second chance.

As of today I am officially declaring CFGroovy 1 abandonware.

I still use CFGroovy 1 on a couple personal projects and at Mentor (where I work) we run our entire service tier on CFGroovy 1.  So it is by no means unsuitable for production deployment, but no new development should take place on it.  It does not run on CF9 without modifying your CF9 installation, and the same will be true of Railo when it supports Hibernate as well.  So you should assume that if you're upgrading a CFGroovy 1 application from CF7/8 to CF9, part of the upgrade process will be converting to CF9 ORM.  This is not nearly as difficult as you would expect – Groovy beans directly translate to persistent CFCs and your Groovy business logic can be encapsulated with CFGroovy 2 scriptlets.  Existing scriptlets (and non-persistent helper classes) should transfer without any modification.  The only exception is that CFGroovy 2 does not provide the concept of a Groovy classpath, but that's typically only required for entities.

CFGroovy 2 is not affected by this; it is alive and well and will continue to be supported, developed, and widely used for a long time.  As well as being all kinds of useful, it is a crucial part of upgrading CFGroovy 1 applications.

From this point on the term "CFGroovy" will refer specifically to what has until now been called CFGroovy 2.  The Hibernate integration is the only reason anyone should be using CFGroovy 1 as CFGroovy is superior in every way when you're only looking for scriptlet support.  It provides not only a richer environmental binding, it also supports arbitrary JSR-223 languages, will transparently bootstrap Groovy (via JavaLoader) if it's not on your classpath, provides hooks for CFML ORM (CFML, not just CF9) integration, and works in a significantly more streamlined and efficient fashion.

A pointing pair is easier to see than a pointing triple, but necessitates making the definition slightly tighter: if a block contains only two potential cells for a given number and they're in the same row or column, then that number cannot exist in any other block's cells of the same row or column.

Of course, if you crank it down one more step (to a "pointing single"), you have the definition of a known cell (either a given or one already solved for).  But enough prose, on to the code:

boolean play(Board board) {
  def madePlay = false
  board.blocks.each { b ->
    (1..9).each { n ->
      def cells = b.findAll {
        it.hasMark(n)
      }
      if (cells.size() >= 2) {
        if (cells*.col.unique().size() == 1) {
          // all in one col
          cells[0].col.each {
            if (it.block != b) { // different block
              madePlay = it.removeMark(n, this) || madePlay
            }
          }
        }
        if (cells*.row.unique().size() == 1) {
          // all in one row
          cells[0].row.each {
            if (it.block != b) { // different block
              madePlay = it.removeMark(n, this) || madePlay
            }
          }
        }
      }
    }
  }
  madePlay
}

This is the longest strategy so far, but it's pretty straightforward.  For each block, consider each number.  Find all the candidate cells, and if there are two or more, see if they're all in a single column.  If so, loop over the column and remove the number from each cell not in the current block.  Then do the same check for rows.

Using Groovy's getAt (bracket) notation, I could have wrapped the col and row checks into a single loop to reduce some duplication, but I haven't here.  You'll see that technique in some of the later strategies, however.

Finally, you'll notice that the whole board is iterated over and potentially many plays are made before the method returns.  As such, using each iterators wasn't a big deal.  This is probably somewhat wasteful, because a pointing pair can potentially do a lot of elimination (and therefore falling back to the GameRulesStrategy would be useful), but I haven't done it here.

The raw source (including the test cases) is available at PointingPairStrategy.groovy, should you be interested.

class HiddenSingleStrategy implements Strategy {

  static getTests() {
    [
      new Test(
        '0' * 9 + '000200000' + '0' * 9 + '000060000' + '0' * 9 + '000080000' + '0' * 9 * 2 + '000002000',
        {
          def cell = it.getCell(5, 5)
          cell.isKnown() && cell.value == 2
        }
      )
    ]
  }

  boolean play(Board board) {
    for (h in board.houses) {
      for (n in 1..9) {
        def cells = h.findAll {
          ! it.isKnown() && it.hasMark(n)
        }
        if (cells.size() == 1) {
          // we found a hidden single
          cells[0].setValue(n, this)
          return true
        }
      }
    }
    false
  }

}

As you can see, the test is a little different than for GameRulesStrategy.  Before I just supplied a board and a successful test was when the board is solved.  In this case I'm just checking for if cell (5, 5) is known and it's value is 2 (no need to solve the whole board).

The strategy itself is pretty simple: for every house, for every number, see if any cell is the ONLY cell in the house that can contain the number, and if so, set that cell to that number.  Once we find a cell to set, the method exits (returning true) and does not continue the search.  This is the reason for the 'for' loops instead of the Groovy 'each' iterator.  This lets GameRulesStrategy "clean up" the board before continuing the search.  In this case it's probably not a big deal, but with the more complex strategies this is an essential optimization.

class GameRulesStrategy implements Strategy {

  static getTests() {
    [
      new Test(
        '900637100030001000107520300004810500019000820006059400002048705000200080001793006'
      )
    ]
  }

  boolean play(Board board) {
    def madePlay = false
    board.cells.findAll {
      it.isKnown()
    }.each { c ->
      c.houses.flatten().findAll {
        it != c && ! it.isKnown()
      }.each {
        madePlay = it.removeMark(c.value, this) || madePlay
      }
    }
    madePlay
  }

}

As with all strategies, it starts with test cases that exercise the strategy: in this case a single board that can be solved by application of the rules alone.  That board spec, just for reference, describes this board:

+-------+-------+-------+
| 9     | 6 3 7 | 1     |
|   3   |     1 |       |
| 1   7 | 5 2   | 3     |
+-------+-------+-------+
|     4 | 8 1   | 5     |
|   1 9 |       | 8 2   |
|     6 |   5 9 | 4     |
+-------+-------+-------+
|     2 |   4 8 | 7   5 |
|       | 2     |   8   |
|     1 | 7 9 3 |     6 |
+-------+-------+-------+

There are three things a strategy can do when asked to play: remove a mark from a cell, set a cell's value, or nothing.  It's up to the strategy to determine if doing several of them at once is appropriate or not.  And keep in mind that a cell with only one mark remaining is implicitly set to that value, so removing a mark can actually set a cell's value behind the scenes.

For GameRulesStrategy, we're only concerned with removing marks from cells, and we can do many of them in a single pass without stepping on our own toes.  We start by asking the board for all the cells, and then grabbing only the known ones.  Then we iterate over those cells, and for each one get the cell's houses (the row, column, and block the cell is in), flatten them into a single collection, and find all the other cells that aren't know.  Finally we iterate over those cells and remove the mark from each of them, keeping track of whether it actually did anything in the 'madePlay' variable.

If you're interested, this same algorithm can be implemented with for..in loops, instead of .each { } constructs, which is a technique I've used in later strategies where the closures get "in the way" of returning from the method early.  Here's the loop based implementation (minus the tests):

class GameRulesStrategy implements Strategy {

  boolean play(Board board) {
    def madePlay = false
    for (c in board.cells.findAll {
      it.isKnown()
    }) {
      for (it in c.houses.flatten().findAll {
        it != c && ! it.isKnown()
      }) {
        madePlay = it.removeMark(c.value, this) || madePlay
      }
    }
    madePlay
  }

}

If you're wondering, the loop performs marginally faster (<1%) than the iterator, but I find it to be a bit less readable, so I generally prefer the iterator approach.  If performance is paramount, Groovy is probably the wrong choice – it's forte is concise, readable code (and therefore development throughput) not CPU throughput.  People are more expensive than machines in most cases, and certainly this one.

This is a really simple strategy, but there are plenty more complicated ones to come, so stay tuned.