Prototype's Array.any/all with jQuery

I needed to convert a couple Array.any() and Array.all() calls (from Prototype) to jQuery syntax. Since jQuery doesn't extend the built-in objects with nice functionality like this, you have to fake it. Here's what I came up with. Old version ('images' is an array):

images.all(function(o){return o.status == "ready";})

and the new version:

jQuery.inArray(false,
  jQuery.map(images, function(o){return o.status == "ready";})
) < 0

Array.any()'s equivalent is the reverse:

jQuery.inArray(true,
  jQuery.map(images, function(o){return o.status == "ready";})
) >= 0

Might have to rip the Enumerable and Array extensions out of Prototype for standalone use as well.

Use ColdFusion? Use Java.

If you use ColdFusion (or another Java-based CFML runtime), you should be using Java. There's a reason that CF uses Java under the hood: Java is incredibly powerful. Yes the interface to Java from the CF level is cumbersome and creating hybrid CF/Java applications pretty much costs you CF's RAD capabilities, but there are some real gems in the Java libraries.

On CF-Talk today, someone asked about reversing an array. There's not a built-in function for doing that, but if you remember that CF arrays are just Java Lists (java.util.Vector, specifically), you can suddenly leverage the full Java Collections framework. In this case, the solution was simple:

createObject("java", "java.util.Collections").reverse(myArray);

Want get unique values from an array? Not a difficult problem, but how about this:

myArray = createObject("java", "java.util.ArrayList").init(
  createObject("java", "java.util.HashSet").init(myArray)
);

Want them sorted? Here you go:

createObject("java", "java.util.Collections").sort(myArray);

Yes, there is an arraySort() CF built-in, but it only sorts text and numbers. So if you want to sort an array of Dates, you're stuck. Collections.sort, on the other hand, will happily sort the dates.

This only breaks the surface of what you can do with Java. Obviously you can't leverage this if you have to support non-Java CFML runtimes, but if you developing for a Java runtime (or runtimes), you owe it to yourself to learn a little bit about the Java tooling available to you.  I've blogged about a couple other Java tricks (fast directory filename listings and string builder tricks) in addition to myriad Java libraries that can be leveraged (Batik, Weka, Ant, etc.)

Here's an complete example of the above tricks:

a = [1, 2, 3, 4, 5, 1, 2, 3, 4, 5];
// reverse it
createObject("java", "java.util.Collections").reverse(a);
writeOutput(a.toString()); // [5, 4, 3, 2, 1, 5, 4, 3, 2, 1]

// sort it
createObject("java", "java.util.Collections").sort(a);
writeOutput(a.toString()); // [1, 1, 2, 2, 3, 3, 4, 4, 5, 5]

// pull unique elements
a = createObject("java", "java.util.ArrayList").init(
  createObject("java", "java.util.HashSet").init(a)
);
writeOutput(a.toString()); // [3, 2, 1, 5, 4]

// unique elements in sorted order
createObject("java", "java.util.Collections").sort(a);
writeOutput(a.toString()); // [1, 2, 3, 4, 5]

Prototype and jQuery

Since I discovered it a few years ago, I've been a big Prototype fan.  It's simple, and gets the job done with a minimum of fuss.  It's not without warts, of course.  I still occasionally forget to put 'new' in front of Ajax.Request, and some of the Ruby-like methods share their lineage's arcane naming.  When it was new, it was the best thing around, and while it now has competitors, it's certainly not lagging behind.

At work, however, jQuery has been adopted as the standard (and I've no power to change it).  The lack of the $() function is annoying; several times I've debated adding this function (or one of various similar ones) to our library:

function $(id) {
  return jQuery("#" + id)[0];
}

I haven't, of course, as it's not the jQuery way.  jQuery also lacks any sort of class assistance, so we still use the Prototype class framework for our class-based JS.  That seems to work fairly well, except for the fact that we have to use two frameworks where one could suffice.

jQuery is not without it's benefits, of course.  The plugin architecture is a nice aspect that Prototype didn't really offer an equivalent of.  It means the core stays lighter (good), but if you want additional functionality you're stuck managing files from a bunch of different projects (annoying).  Event handling is a bit more straightforward, in some ways.  "Magically" acting on collections of elements with a single call (i.e. no .each(function(o){…}) garbage) definitely makes for more readable code as well.

Because of this shift at work, I've been porting some of my personal apps over to jQuery as well.  I've actually been using a couple jQuery plugins (both self-written and external) for specific tasks for a while now, but not the core framework.  What I've found, however, is that jQuery can be prone to slow code.  To avoid a huge amount of extra work on the part of the JS interpreter, using temporary variables for jQuery objects is essential.  If you do strictly id-based queries, the degradation isn't huge, but if you do CSS-based queries, it can be significant.  With Prototype's focus on id-based queries (at least until $$() came about in 1.5), that was less of an issue.

This need to query a minimum number of times can provide a fair amount of complexity when you have more than a handful of closures hanging about and/or a dynamic DOM.  You end up doing a lot of state management work because you're, in effect, caching DOM lookups and have to ensure you never have stale cache.

Other than that issue and the lack of an equivalent to document.viewport, porting has been relatively painless.  Still very id heavy, so not leveraging jQuery as much as could be, but most of what I'm doing wouldn't benefit from other selectors.

Which one is better?  Hard to say.  jQuery seems to make you work harder to type less code, while Prototype seems to cost you a few more characters for a bit less density.  With the exception of Prototype's class support, their feature sets are fairly equivalent, especially with jQuery UI now available to "compete" with Scriptaculous.  For the moment, I'm choosing to use jQuery on new stuff, but wishing for Prototype every few minutes.  Until I come up against some sort of significant wall, it'll probably stay that way, just to stick with the same tooling professionally and personally.  And over time it'll probably get better as the Prototype-ness fades from apps.

IndentXml CF UDF

I had a need to fix indentation of some XML today, and a quick Googling didn't turn up much help. So I wrote a little UDF that will take an XML string and return it with all the tags nicely indented:

<cffunction name="indentXml" output="false" returntype="string">
  <cfargument name="xml" type="string" required="true" />
  <cfargument name="indent" type="string" default="  "
    hint="The string to use for indenting (default is two spaces)." />
  <cfset var lines = "" />
  <cfset var depth = "" />
  <cfset var line = "" />
  <cfset var isCDATAStart = "" />
  <cfset var isCDATAEnd = "" />
  <cfset var isEndTag = "" />
  <cfset var isSelfClose = "" />
  <cfset xml = trim(REReplace(xml, "(^|>)\s*(<|$)", "\1#chr(10)#\2", "all")) />
  <cfset lines = listToArray(xml, chr(10)) />
  <cfset depth = 0 />
  <cfloop from="1" to="#arrayLen(lines)#" index="i">
    <cfset line = trim(lines[i]) />
    <cfset isCDATAStart = left(line, 9) EQ "<![CDATA[" />
    <cfset isCDATAEnd = right(line, 3) EQ "]]>" />
    <cfif NOT isCDATAStart AND NOT isCDATAEnd AND left(line, 1) EQ "<" AND right(line, 1) EQ ">">
      <cfset isEndTag = left(line, 2) EQ "</" />
      <cfset isSelfClose = right(line, 2) EQ "/>" />
      <cfif isEndTag>
        <!— use max for safety against multi-line open tags —>
        <cfset depth = max(0, depth - 1) />
      </cfif>
      <cfset lines[i] = repeatString(indent, depth) & line />
      <cfif NOT isEndTag AND NOT isSelfClose>
        <cfset depth = depth + 1 />
      </cfif>
    <cfelseif isCDATAStart>
      <!—
      we don't indent CDATA ends, because that would change the
      content of the CDATA, which isn't desirable
      —>
      <cfset lines[i] = repeatString(indent, depth) & line />
    </cfif>
  </cfloop>
  <cfreturn arrayToList(lines, chr(10)) />
</cffunction>

There's nothing XML-ish about the implementation, as you can see, so you can happily feed non-XML tag based markup, as long as it uses '<' and '>' as tag delimiters in the XML fashion. Just don't expect to get good formatting if you don't have tags that follow the XML spec (e.g. CFELSE).  Also, it doesn't account for open tags (or closing tags) that are split across multiple lines. That wasn't a case I cared about, and I don't know that you can solve it correctly without actually parsing at least CDATA blocks out of the XML.

FlexChart Updates

The past month or so has seen quite a few improvements and bug fixes to FlexChart, though I haven't blogged about any of them.  Most notably, there was a weird NPE that manifested itself when loading a Pie chart via FlashVars.  For some unknown reason, Flex/Flash didn't give any indication the error was occurring, it just silently terminated the active call stack and continued on it's merry way.  This left the app in a quasi-broken state that would prevent certain future calls from working, but allowing others to execute without issue.  I still have no explanation as to why the error silently terminated, but I've since seen the same behaviour inside FDS, so it's not charting specific.

The ability to style charts has been extended a bit, though it's still not as highly polished as I could wish.  For example, supplying a stroke weight for a line series causes the stroke color to default to black, instead of the automatically assigned color (orange, green, blue, …).  In the reverse case, if you supply custom colors on a Pie chart, they render correctly, but the legend (if one is used) uses the default colors (orange, green, blue, …).  Gradient fills are now available as well.

I've also improved handling of empty charts.  The stock custom tag requires a descriptor, but if you don't have data at page render time, you usually end up providing "<chart />" as the descriptor.  The engine now detects this case (whether on the initial load or later passed in), and is a bit more intelligent about ensuring it clears it's stage.  Previously you could end up with an empty CartesianChart in some cases.

Finally, I made a number of improvements to performance and handling of data values.  This was mostly accomplished by explicitly converting the XML nodes into real objects for the chart to render, rather than using the XML directly.  There were some implicit type conversions that didn't happen consistently out of XML nodes, but work fine out of generic objects.

New SSL Certificate

I installed a new "real" SSL certificate today, instead of the self-signed ones I've been using for the past few years.  It's the cheap model, but it's recognized by both IE and Firefox, which is an improvement.  Unfortunately, Eclipse doesn't recognize the CA, so you still get prompts there if you connect to my SVN.

Data Mining With Weka

I've a large application that has a as a major component rank-based prioritization of assets. Users rank the assets on a one-to-five scale, and then that rank data is used to select other assets of interest for the user. If you've seen Amazon's "Recommended for you" or Netflix's recommended titles, you get the general idea.

The app was originally built back in 2004, and used a complex (and cumbersome, and slow) metadata-based algorithm. Each asset has a set of metadata facets specified. At prioritization time, an overall rank is computed for each facet for the given user, based on the rank of assets with the different facets. Unranked assets that have the high-ranked facets and not the low-ranked facets are given a high prioritization. If you've used Pandora, it's the same general idea, though I used far fewer facets. Overall, this algorithm worked quite well. I've tuned it over the years, but it's architecturally unchanged from the initial version.

However, this approach has one huge problem (aside from the complexity): it requires metadata. That metadata has to be populated by someone, and it's a thankless job. I tried a few different ways to make it easier for users to contribute, but never really hit on anything that worked well, so I ended up spending a bit of time every once and a while tagging stuff. As the asset and user counts increase, the workload only goes up, so not a scalable solution.

Which brings me to the topic of the post: data mining with Weka.

Data mining is basically digging through a crapton of low-level data to find higher-level information. Weka is a piece of software, written in Java, that provides an array of machine learning tools, many of which can be used for data mining.

In my particular case, I wanted to remove the metadata dependency of the prioritization algorithm, and rely strictly on rank data. It took a while to really wrap my head around what I wanted to do and what the data path actually looked like, but once I figured it out it was incredibly simple to implement.

In a nutshell, I create a relation (i.e. table, spreadsheet, grid) with rows representing assets and columns representing user. The intersection of each row/column (i.e. a cell) is the rank from that user for that asset. Obviously not every user has ranked every asset, but Weka happily deals with missing data (expressed as a question mark). Here's a partial data set (12 each of assets and users), in Weka's ARFF format:

@relation 'asset-ranks'
@attribute assetId string
@attribute u2 numeric
@attribute u5 numeric
@attribute u6 numeric
@attribute u7 numeric
@attribute u8 numeric
@attribute u9 numeric
@attribute u10 numeric
@attribute u12 numeric
@attribute u13 numeric
@attribute u18 numeric
@attribute u20 numeric
@attribute u21 numeric
@data
48,1,?,?,2,?,?,?,?,?,?,?,?
50,?,?,?,3,?,?,?,2,?,?,?,?
52,1,3,4,2,?,?,4,?,?,?,?,?
70,4,3,5,5,?,2,3,3,1,4,?,?
73,2,3,1,5,?,2,?,5,1,5,?,?
91,3,?,5,2,?,?,?,?,?,?,?,?
165,1,2,4,5,1,?,?,3,1,4,1,?
196,4,2,4,3,5,3,?,?,?,?,?,?
234,3,5,4,2,4,4,4,4,3,5,?,5
235,?,5,5,1,?,2,?,?,?,?,?,?
259,?,?,5,4,?,?,?,?,1,?,?,?
261,3,4,5,4,5,4,?,3,?,?,?,?

Running that through Weka's clustering engine breaks all the assets into clusters averaging 50 assets (my choice) in size, and appends a cluster identifier to each row in the data file. Here's command line I use:

java -classpath weka.jar \
  weka.filters.unsupervised.attribute.AddCluster \
  -i $srcFile \ # the data above
  -I 1 \
  -W "weka.clusterers.SimpleKMeans -N $clusterCount" \ # ceil(rows / 50)
  >& $destFile # the data above, with a 'cluster' attribute added

The clusters represent groups of assets that the ranks indicate are related. The assumption is that for a given users, all assets in a given cluster will be ranked similarly, and the data bears that out. How exactly Weka is doing that, I'm not sure - voodoo may be at play.

Anyway, I read the result into the database, setting up asset-cluster relationships, and then can prioritize the clusters based on their average rank by each user. Unranked assets from the highest-priority cluster should be the assets the user is most interested in.

This approach is not only much simpler, it's enormously faster, and it uses someone else's code (which is always a good thing). However, it's not without a significant problem of it's own: it can only prioritize ranked assets. I've addressed this by randomly mixing in an occasional random unranked asset to seed the pool. Time will tell if that approach works well or not; it's hard to estimate without any data.

With my trials, the two algorithms generally gave similar results. Not identical, of course, but similar. What's interesting is that the old algorithm computes an estimated rank for each unranked asset, while the latter just finds a collection of similar assets that the user indicated an interest in (via ranking some members of the collection). I'll probably look at some predictive stuff to add on top of the clustering to do actual per-asset rank predictions, but for now, it seems unneeded.

I'll be using Weka on some other projects, no question there. Like so much else, the hard part is figuring out how to express the question you want answered. Not technically so much as conceptually. Once you have that, implementation is straightforward.

I Sense AdSense

After the merciless hounding of Joshua, along with some of my own curiosity, I added AdSense ads to my blog this weekend.  My plan is to leave them there until the end of May, and then remove them.  I can't imagine there's even close to sufficient potential income to justify the ugly factor, but perhaps I'll be pleasantly surprised.  Not holding my breath.

The Best of the Best

Eight and a half years ago, I posted the 26th best mid-season time for the NCAA men's 200 Freestyle.  That was as close as I ever got to being the best of the best.  I figure that's pretty good; roughly the 99.999997th percentile of college-age men.  Three and a half weeks later, I quit competitive swimming for Heather and a life of code, never to return.

I've never come close to that level of proficiency since.  Being there again is something I long for perhaps more than anything else.  Utter competence - no question of success or failure, just how grand the success will be.  No worry about the task at hand, complete trust in yourself and the ability to enjoy every moment in all it's glory.  "Poetry in motion" is cliche to the nines ; ), but it's exactly what it is.

It being Thursday night, Heather's off at choir, the kids are in bed, and I'm tired for beating my head against problem after problem (usually clients who can't make up their mind) at work.  So here I am dumping my mind into a blog post that few will read and fewer will really understand, listening to a song stream from YouTube.  Jesu Joy of Man's Desiring is a most beautiful song, and Celtic Woman's rendition from the Helix really brought back that feeling of perfection.  From 1:00 through 1:25 (particularly at 1:10 and 1:25), effortless perfection and enjoying every minute.  The rest of the song is beautiful, but pales by comparison.

Get Your ColdSpring (et al)!

For those of you not in the know, ColdSpring is a port of the Spring framework (for Java) to ColdFusion.  It provides an Inversion of Control (IoC) framework and an Aspect Oriented Programming (AOP) container for CFCs.  If you used stateful CFCs, you should be using ColdSpring.  Period.

But that's not why I'm writing.

I am absolutely flabbergasted by the growth surrounding ColdSpring (and really, CF in general).  Five years ago the thought of debating the intricacies of IoC and metadata introspection in the CF community would have been a joke.  And yet today that conversation happened on the ColdSpring mailing list.  Look back 10 years, and the closest thing to a framework was a pair of custom tags and some lose conventions for structuring apps (i.e. Fusebox 2).

Beyond ColdSpring, the "big 3″ UI-layer frameworks (Fusebox, Mach-II, Model-Glue) are in wide use, undergoing active development, and growing strong and active user bases.  At least two major ORM solutions (Reactor and Transfer) are proliferating.  We've got a community built IDE (CFEclipse) that blows the pants of any other available tool, commercial or otherwise.

So if you're a CF user, go buy yourself a beer.