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.

So if you followed the docs and didn't test in the wild, code built atop the 2010-10-01 API will not page correctly.  In addition to clarifying the specifics of the problem, AWS indicated the API docs for the 2010-10-01 version had been updated as well, but I pulled them down this morning and they still list initial caps on the parameter names.

In any case, lowercase names for parameters are the way to go, regardless of which version of the API you're using.

If you're building a web app, you're necessarily trying to serve all your customers with a single interface, but you can still give them a familiar user experience with a minimum of fuss.  Not only can you, but you should.  The best part is that you can do much of it purely with CSS and JS, without having to touch your serverside at all.

Here's a jQuery snippet that deals with the button order problem:

jQuery(function() {
  var c = jQuery(".osx input[type=submit]").parent()
  c.css("text-align", "right")
    .children().each(function() {
      c.prepend(" ").prepend(jQuery(this).remove())
  })
})

As you can see I simply grab any element directly containing a submit button, invert the order of it's children, and right align them.  Note the ".osx" in there – that's really important.  Somewhere else (maybe JS, maybe serverside, whatever) the OS of the user will be checked and the "osx" class will be added to the HTML element if appropriate, allowing me to target only OSX visitors with custom stuff.  You could just as easily do it in the other direction (emit HTML w/ OSX ordering and flip it around to Windows ordering).

Here's some CSS to style buttons a little differently:

.osx input[type=submit] {
  border: 1px solid #2b269a;
  background-image: url(osx-button-bg.png);
  border-radius: 6px;
  font-family: Verdana;
}

These are trivial examples, but they illustrates just how simple it is to help make your users feel more at home.  Foisting an inconsistent user experience on your application's users does them a disservice.  People are unfortunately used to having to think extra hard when they cross over into a browser, but there's no reason to make them pay that price.

There are now two more parameters to the listObjects method on the CFC:

• startAfter[""] – The object key to start the listing after (corresponding to the 'marker' parameter in the raw S3 API), defaulting to the empty string (which is before the first object key).
• maxResults[1000] – The number of results to return (corresponding to the 'max-keys' parameter in the raw S3 API), defaulting to 1000.

This is a simple, but rather atypical way to do paging, so a brief bit of psuedo-code is in order:

s3 = new S3("MY_AWS_KEY", "MY_AWS_SECRET");
pageSize = 10;
items1To10 = s3.listObjects('s3.test.com', '', '/', '', pageSize);
items11To20 = s3.listObjects('s3.test.com', '', '/',
  items1To10.objectKey[items1To10.recordCount], pageSize);

As you can see, the second page of results is retrieved by passing the last object key from the first page as the 'startAfter' parameter.  Note that S3 always returns object keys in alphabetical order, so all paging operations are using that ordering.

In addition to these two new parameters to listObjects, both listObjects and listBuckets now return extended metadata including both the standard fields (executionTime, cached, recordCount, and columnList) and extra S3-specific metadata.  In particular, listObjects returns an 'isTruncated' field indicating whether the listing was truncated (meaning there are more keys to retrieve).  Very helpful in determining whether you need to look for another page of records.

Some psuedocode for this might look like this:

s3 = new S3("MY_AWS_KEY", "MY_AWS_SECRET");
pageSize = 10;
items1To10 = s3.listObjects('s3.test.com', '', '/', '', pageSize);
if (items1To10.getMetadata().getExtendedMetadata().isTruncated) {
  // ... fetch next page ...
}

Just for reference, the extended metadata is what is returned when you use the 'result' attribute on a normal CFQUERY tag.  That same data is available from the query result (what you pass to the 'name' attribute of CFQUERY) via the syntax above.  So you can always get the SQL, execution time, cache status, etc from any query result, even if you don't have a reference to the 'result' attribute's variable.  Forgive the confusing nomenclature, the attribute names are really screwed up, so here's some psuedocode that will hopefully illustrate:

<cfquery name="myQuery" result="myMetadata">
  select ...
  from ...
</cfquery>
md = myQuery.getMetadata().getExtendedMetadata();
assert md.sql EQ myMetadata.sql;
assert md.executionTime EQ myMetadata.executionTime;
assert md.equals(myMetadata);

This is handy for query results which are returned from CFC methods, for example, where you can't use the 'result' attribute.

Development of these new features was sponsored by Gaurav Malik and CSSTC.

All kinds of neat, you might say.

One of the other reports that you can access if you're logged in (the report above was made publicly available) is called a hiatus reports, which instead of reporting on the events themselves, reports on the length of the hiatuses between events.  For example, I aim to have  a benadryl every 8 hours or so, so monitoring my hiatuses is more useful than the actual data points themselves.  However, the raw hiatuses aren't terribly interesting as the number of events goes up — you want stats on them (average, median, deviation, etc.) so I added that this evening.

And then Kim (aka Dr. Repp, microbiologist and bio-statistician) wanted quartiles as well as median.

Quartiles are kind of a pain.  It's not obvious how exactly they are computed.  Median is easy, just line up your points in ascending order and take either the middle one (if there is one), or average the middle two (if there isn't).  Quartiles are not the same algorithm applied to the 25% and 75% points (the 50% quartile is the median, of course).  Rather, they are the medians of the two halves of the data on either side of the median.  In particular, the median value (is there is one) is not part of either half; it's the pivot.  Think quicksort.

An example will make this more clear.  Consider this set of values (already sorted):

[1, 2, 3, 4, 5, 6, 7, 8, 9]

The median is obviously five, which leaves four points on either side of it which will be used to compute the quartiles.  So the 25% quartile is the median of this subset:

[1, 2, 3, 4]

The 75% quartile is the median of this subset:

[6, 7, 8, 9]

Note that five isn't in either one.  These subsets yield medians of 2.5 and 7.5, which correspond to the 25% and 75% quartile values.

Now consider this set of values (also already sorted):

[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Here the median in 5.5 (the average of 5 and 6), and as that isn't an actual value in the set, the entire set will be represented in the two quartile subsets:

[1, 2, 3, 4, 5]
[6, 7, 8, 9, 10]

This yields quartiles of 3 and 8.

Not a difficult  algorithm, but a bit tricky since you don't actually figure out the quartiles directly on the data, you have to compute the median, split the data, and then figure out the quartiles from the subsets.

The JRE provides TimerTask, but it's a huge pain in the ass to use with CFML because the Java-to-CFML bridges are laughably weak. OpenSymphony has Quartz (which is awesome), but being Java, it suffers the same problem. Yes, even with the bennies CFGroovy offers in the Java space.

CFSCHEDULE is lame, especially on ColdFusion with it's 61 second frequency limit. Even with an optimal implementation the entire mechanism is flawed because it's a) stuck with equal iteration periods, and b) can only invoke URLs. Every distinct task requires punching a hole in your URL security, making a UI-layer facade for the task, etc.

The Java mechinisms are much better because they stay in-JVM (i.e., don't go through HTTP), but the statelessness of CFCProxy is a huge burden. You can't access already-instantiated CFCs, which means you end up writing a massive pile of custom facade/proxy code to interface with your already-running business model.

The natural solution, of course, is implementing cron in CFML. It allows you to pay either the HTTP or CFCProxy cost exactly once, as well as have cron's incredibly flexible scheduling format. This fact, in it's various manifestations, drives me to drink rather ridiculous amounts.

The flip side, of course, is the dynamic reloading nature that CFML servers offer. I simply cannot understand why other JVM frameworks have not copied this feature. The complete avoidance of all the JVM restarts and classloading hell is a benefit worth enormous sacrifice. Which, I suppose, is why I write CFML both for my salary and for personal projects.

Am I the only one who thinks this is a problem? With both CFML and other JVM frameworks.

Yay for Trans-Siberian Orchestra and Mannheim Steamroller – two notable exceptions.   For the rest of you:  slow down.  Creating music is a gift.  Enjoy it.  We will too.