Translations for Angular

I've been working a lot recently with Angular.JS, and building apps that will (eventually) need to be translated to different languages. Despite the fact that Angular is reputed to be the "Kitchen Sink" of Single Page App frameworks it doesn't actually include any out of the box support for translation. Fortunately, it was easy to cobble together one in a very simple fashion.

The practice of translation is basically mapping one string onto another. JavaScript provides a very simple has mapping structure that works very well for this kind of work, and Angular allows us to turn those maps easily into "Constants" that are available throughout the app. I put constants in quotes, because they're not really constants, since JavaScript doesn't support constants in most browsers, but Angular approxmiates constants pretty well.

Here's an example of the string mapping that I set up:

(function(angular) {
    "use strict";

    var ENGLISH = {
        // Simple Translations
        "Toggle Errors": "Toggle Errors",

        // Longer messages
        "validation-error": "An error occured validating your document.",
        "validation-success": "Your document was successfully validated."


Obviously this table is just a short sample of my translations, but it can be expanded easily.

Now how would you use this translation system? There are two different ways I can think of to do this in angular: Directives and Filters. Directives provide a lot of power for interacting with the DOM. You can apply a Directive to an HTML element, either as an attribute, class, or a separate element itself. Filters on the other hand, are simply functions that accept one or more inputs and return a string. A filter sounds like it'll work fantastically well for translation, so I whipped up this quick filter:

(function(angular) {
    "use strict";

    TranslateFilter.$inject = ['language'];

    function TranslateFilter(language) {
        return function(input) {
            var translation;
            if( input in language ) {
                translation = language[input];
            } else {
                translation = input;
            return translation;

        .filter("translate", TranslateFilter);

This filter will accept a string, look for it in the translation table, and if it finds it, translate it. If it can't find the string in the translation table, it will return the string unchanged. This prevents mysterious errors where the string isn't in your translation file.

Now, in any views/tempaltes rendered by Angular, you can get a translated string simply by applying the filter to any english text that you are inserting into the document:

<div ng-show="vm.showErrors">
    <div ng-if="vm.error">{{ "validation-error" | translate }}</div>
    <div ng-if="!vm.error">{{ "validation-success" | translate }}</div>
<button ng-click="vm.showErrors = !vm.showErrors">{{ "Toggle Errors" | translate }}</button>

I quickly realized I'd also need a string templating service to handle more complex error messages which require substitutions and string formatting, which I might go into more in a future post, leveraging the $interpolate service in angular.

Of course, a few days after I implemented this, I found out about angular-translate from a dev on a different team. Fortunately, it looks like angular-translate is a simple drop-in replacement for the translation stuff I built.

Starting Grails

I'm delving into learning Grails, in my continual effort to pick up fringe languages and frameworks while avoiding the popular ones.

Grails is a framework for web development loosely modeled off of the Rails framework for Ruby. Instead of using a scripting language like Ruby however, Grails is built on top of Groovy, a JVM-based compiled language with a lot of syntactic sugar that allows it to behave very similarly to a dynamic scripted language like Ruby or Python. Beyond that, it's also got a lot of the python/post-java stylistic options such as optional semicolon, list comprehension, etc. that developers are growing to love.

So, with that in mind, I fired up my Ubuntu 14.04 dev box, and started fiddling around with Grails. Groovy is a JVM language, so the first step was installing a JVM. I actually pulled down the Sun Java 8 JVM, figuring why start with an old version. Then I started reading around. The first tool that I happened on that seems invaluable is The Groovy enVironment Manager, or GVM for short. It does what rvm does for Ruby, or what pyenv does for python: It allows you to set up your user environment with a version of groovy and grails separate and independent of what your OS packages might install. For Mac users, that's probably not a huge deal if you're using homebrew or macports, since those tend to keep up to date packages, but Ubuntu, RedHat, and others tend to lag a bit behind on development tools. For example, the current version of Groovy is 2.3.0, but Ubuntu 14.04 has Groovy 2.0.0 in it's repos. Further, even if you've got the most recent version in your OS repos, and you're working with anyone else, or on a brown-field project, you almost certainly won't want to be using the newest version. So, GVM allows you to download and install any version of Groovy up through the current version, as well as different releases of Grails, and a couple other key dependencies and add-ons.

So, with GVM solidly in place, I pulled down Groovy 2.3, Grails 2.3.8, and started trying to build a simple hello world app:

$ grails create-app hello
| Created Grails Application at /home/greylurk/hello
$ cd hello
$ grails create-controller hello
&lt; Massive java stack dump &gt;

Well, damn. It turns out that Java 8 is actually not compatible with Groovy/Grails right now. I expect that to be resolved reasonably soon, but for now, Java 8 is a no go.

Ok. So, now after downgrading my java to Java 7, Let's give that another try:

$ grails create-app hello
| Created Grails Application at /home/greylurk/hello
$ cd hello
$ grails create-controller hello
| Compiling 10 source files
| Compiling 141 source files
| Created file grails-app/controllers/hello/HelloController.groovy
| Created file grails-app/views/hello
| Created file test/unit/hello/HelloControllerSpec.groovy
$ grails run-app
| Server running. Browse to http://localhost:8080/hello

And so, a quick browse to http://localhost:8080/hello shows a welcome page! Let's call that a victory for now.

Perl CPAN: Too much fail for one computer!

Failed Test                       Stat Wstat Total Fail  Failed  List of Failed
t/anon.t                             2   512    ??   ??       %  ??
t/attribute_issues.t                 2   512     6   10 166.67%  2-6
t/autoclean.t                        2   512    ??   ??       %  ??
t/basic.t                          255 65280    ??   ??       %  ??
t/clean.t                            2   512    ??   ??       %  ??
t/import.t                           2   512     1    2 200.00%  1
t/inner_keywords.t                   2   512     6   12 200.00%  1-6

How on earth did t/import.t fail 200% of it's tests?

Scala for the Impatient

I spent a few hours this weekend digging through the first 4 chapters of Scala for the Impatient from Typesafe. I had heard a lot about Scala from various folks around the functional programming and Java communities, usually in the same sorts of conversations as Haskell and F#. I decided it was time to go take a browse through the language and see what it's about.

On first glance, Scala is in that same family of "Post-Java" languages as Groovy, Python, Ruby, etc. with lots of syntactic sugar that makes it fun to work in. It doesn't require semi-colons. It doesn't require parenthesis on function calls in certain cases. It's statically typed, but the compiler guesses your types for you in most cases, so you don't have to worry about it unless you're doing something tricky. This is refreshing coming from Java, C#, or even ColdFusion where the compiler requires a pretty rigid syntax before it lets your code pass.

Another area where Scala really shines is in processing collections. Arrays, Lists, and Hash Maps are all very nice to write for. This is again something that is shared with Groovy, Python, Ruby, and the rest of the "Post Java" languages. For example, in Java if you want to copy only the odd numbers in an array into a second array, you have to do something along these lines:

int[] a = {1,2,3,4,5,6,7,8};
int[] b = new int[4]; // How do I know there are 4?  I just do...
int counter = 0;
for( int i : a ) {
  if( i % 2 == 0 ) { 
    b[counter++] = i;

Or something like that. In Scala, the whole thing becomes a lot shorter, more concise and readable (once you know the Scala syntax of course).

val a = Array(1,2,3,4,5,6,7,8)
val b = for( i <- a if (i%2=1) ) yield i

Or maybe

val a = Array(1,2,3,4,5,6,7,8)
val b = a.filter(i=>i%2=1)

I'm a little worried that Scala suffers from the problem that Perl sometimes has: You can do the same thing so many different ways that it's possible to "outsmart yourself" and end up with code that's effectively write-only. It takes more effort to mentally parse what's going on in this code than it does to write it.

Of course, the ability to manipulate collections in interesting ways is great, but the Google Guava library, as well as the Apache commons address that pretty well too. It's not clear (from the first few chapters) that Scala's collection processing capabilities are ultimately that compelling, but there are several chapters left to go.

Quick "Shuffle" algorithm in JavaScript

I came up with a quick "shuffling" algorithm for JavaScript for a project I'm working on, and I'm just saving it here for future reference in case I need it again. Feel free to copy it if you need one too.

shuffle = function( list ) {
  var result = [];
  while( list.length &gt; 0 ) {
    var i = Math.floor( list.length * Math.random() );
    result.push( list.splice( i, 1 ) );
  return result;

Google h.264 conspiracy theory

This is entirely too complex and convoluted to be rational, but try this thought experiment on for size:  How can Google break into the tablet market where Apple is already an undisputed leader?

Google sees that Apple and Microsoft are pushing for h.264 HTML5 support in the browser, but also sees that they can't muster a full 50% market share of the web between Internet Explorer and Safari. Firefox holds a plurality, with a bit of Opera which refuse to use the h.264. Chrome has become a wildcard. If Chrome supports h.264, Firefox will either lose market share and be replaced by standards compliant IE9 or Chrome or adopt h.264. Either way Flash video will probably decline, and eventually die, replaced by standard h.264 video on HTML5.

On the other hand, if Google rejects h.264, they know that Apple will be unlikely to support WebM from their competitor, nor will Microsoft. This pits the popular browsers (with >50% market share) against the corporate ideologs of Microsoft and Apple. This is a battle that could rage for years to come. Meanwhile, people around the world still want their Mean Kitty videos.  Enter Adobe Flash.

Flash runs fine on Google android, and as a plugin to all desktop browsers including Safari, and is mature, well supported and well understood.  Now, if companies have two options for broadcasting internet video; A mature, well understood and nearly universal Flash solution, or a volatile and codec muddled HTML5 solution.  Which are they more likely to support?  Sure, the big ones will support both, but the "long tail" small companies are likely to choose Flash.  That would make their video unavailable to Apple iOS users, but given the choice of supporting 95% easily (everyone but iOS) or 45% (iOS, Safari and IE9) of web users, most of them are going to go with Flash.

So, because Google chooses not to support h.264, the HTML5 video wars continue to rage, and Flash continues to dominate Video streaming on the web.  Apple, which doesn't support Flash and never will, has to keep encouraging companies to support h.264 HTML5 in order to keep sales of their devices high, but realistically that's a losing battle when h.264 HTML5 automatically excludes the majority of web users.  So Apple loses, while Google's core business is unaffected, and some of their side business (Android Tablets) picks up.

As I said, this is pretty obviously a conspiracy theory, and is to convoluted and has too much reliance on Apple's bullheadedness to actually make sense, but I would guess that the scenarios outlined above crossed at least one Google exec's mind when deciding what Codec(s) to support in Chrome.

A far more likely scenario is that Apple and Microsoft will include a WebM codec in their browsers, and at worst this will set ubiquitous HTML5 video back a few months, as video chipsets implement WebM on chip, and ship those video cards.

Comma Separated results, without a Cursor

I've been writing T-SQL for years, and I've often found a case where I want to collapse a rowset containing a single column into a comma separated list. I've taken a few swags at it over the years, usually involving using a cursor and an accumulator string. Mostly though, I've just passed the whole rowset up the toolchain to my middleware, and dealt with it at the ColdFusion level. However, today I found a case where that just wasn't an option, so I started digging a bit more, and found a great solution at Here's the basics of their approach:

Say you have user, and a pile of associated permissions, like so:

  userId int autoincrement not null primary key
  username varchar(100), 

CREATE TABLE UserPermission( 
  userID int not null,
  permissionID int not null

Now say you want to get a comma separated list of permissions for a given user. You might think of using a cursor, or some other obscure method, but there's an easy way:

DECLARE @UserPermissionList varchar(MAX)

SELECT @UserPermissions = COALESCE( @UserPermissions +',', '' ) + CAST( PermissionID as Varchar(12) )
FROM UserPermission
WHERE UserID = @UserID

SELECT User.*, @userPermissionList as PermissionList
FROM User 
WHERE UserID = @userID

Voila, you've got a comma separated list of permissions, without using a cursor. For those of you in the NoSQL crowd, you'll note that really the COALESCE here is functioning very similarly to a "reduce" function from a map/reduce algorithm. This approach could therefore open up some other interesting avenues for design.

I still wish there was a "JOIN()" aggregate function, but until that happens, we're not totally paralyzed.

Setting an initial selection in a Flex ComboBox

There's other (possibly more elegant) solutions out there on the web, but I came up with this today when faced with trying to set the initial "selectedIndex" of a ComboBox whose contents are populated dynamically.  Unlike HTML, it's not as simple as just marking one of the "options" as selected, but fortunately, it's not a lot harder.

private function locateLabel( source : ArrayCollection, label : String )
    for( var i=0; i&lt;source.length; i++ )
      if(source[i].label == label ) return i;
    return 0;
<mx:ComboBox dataProvider="{model.stateList}" selectedIndex="{locateLabel(model.stateList,model.address.state)}" />

This method triggers binding whenever model.stateList or model.address.state changes, and updates the combo-box position accordingly. To me this is a bit cleaner than sub-classing the ComboBox, which was the primary other method that I saw recommended, but I welcome other suggestions, if there's an even easier method I've missed.

Developing AIR applications on Ubuntu Part 1

I've recently been looking at developing a cross-platform application on my Linux system for eventual use on Windows and Macintosh.  AIR became an obvious choice, because it's solid on Windows and Macintosh, and supports Linux pretty well as well. I'm still in the midst of development, but I thought I'd post some of my original thoughts on JS/HTML AIR development on Linux.

After deciding to develop on Linux, and on AIR, the first point that came up was whether to develop in HTML/JS or to use Flex.  Unfortunately, Adobe has made the decision not to support Flex Builder 3 fully on Linux, and the prospects for Flash Builder 4 don't look good either, so the main reason to use Flex over HTML/JavaScript (namely, a kick ass development environment) isn't really there in Linux.  I did check out the Flex SDK version 3 and 4 using Ant (and I'll post some thoughts on that later) but overall, without Flex Builder, Flex Development on Linux is just less appealing.   Given that there's some really good tooling out there in Linux for building HTML/JavaScript applications, I've decided to use that for my current project.

The first step to developing an AIR application is of course to download the AIR SDK from Adobe.  This is available as a download for Linux.  Extracting files from a tarball is probably pretty familiar to Linux users, but in case you aren't familiar with it, I'll give a short instruction set here.

  • Download the file to your home directory (/home/)
  • Unzip the directory to your temp directory (mkdir /tmp/air/; cd /tmp/air; tar xvjf /home//AdobeAIRSDK.tbz2)
  • Copy the AIR SDK to the "/opt" directory. (sudo mkdir /opt/air-sdk; sudo cp -r /tmp/air /opt/air-sdk/1.5.2)
  • Create a symbolic link to the "current" AIR SDK (sudo ln -s /opt/air-sdk/1.5.2 /opt/air/current)
  • Create a script to add the environment variables.

    export PATH=/opt/air-sdk/1.5.2/bin:$PATH
  • Setup your environment for your main username.  Basically, add to the end of your .profile file "source /opt/air-sdk/current/"

At this point, you should verify (by opening a command window and typing "source ~/.profile") that your profile is working.  If it's not, fix it and try again.  Once you've got it working, log all the way out of your linux account, and log back in again.  This should make sure that any terminals you launch will have access to the AIR tools (ADL and ADT).


ADL is the primary debugging tool that you'll use when developing an AIR application.  adl is a Java program, and takes as an argument the Application descriptor XML for an AIR application.


ADT is the primary packaging and package signing tool that you will use when "compiling" and "distributing" your AIR application.  The adt tool uses the same application xml descriptor as adl, and requires an SSL certificate.  You may generate your own "Self Signed" certificate, but it will be less trusted than a real SSL certificate. Finally, when packaging an application using adt you MUST be connected to the internet.  ADT verifies the current date with several known timeservers to validate that the certificate is current and not expired.  If you are not connected to the internet, ADT WILL fail.

Next time I will get into a description of my project structure, and how to work with the HTML and JavaScript files that make up the AIR application.

ColdFusion Builder - First Glance

Yesterday Morning, ColdFusion Builder (formerly known as Bolt) was released on Adobe Labs After a day of fiddling around with it, here are my initial impressions:


There are three versions listed on Adobe Labs: Macintosh, Windows 32 bit and Windows 64 bit.  Currently there are no Linux versions available, and from comments on the forums, there is no plan to release a Linux version at launch.  This is very irksome, since about 20-30% of the developers I know use Linux as their primary development platform, especially with the news about CF9's full support of Ubuntu.  Mark Mandel has managed to put together a tutorial on how to install ColdFusion Builder on Linux, so really it looks like Adobe just isn't willing to hire someone to maintain and Q.A. a linux release.


Installation comes in two forks, similar to the Flex Builder.  There is a stand-alone version, which installs a new Eclipse 3.4.2 instance, along with the ColdFusion Builder plugin.  The standalone also appears to contain some bits and peieces of Aptana, such as the HTML, CSS, and JavaScript editors, as well as Aptana's FTP support.   There is also a "plugin version" which only works with 3.4.2, not version 3.5, or 3.4.1.  This means that realistically, you probably aren't going to be able to use the plugin version if you've got an existing Eclipse install, unless your install is almost bleeding edge, but not quite.

First Impressions

As we've come to expect from Adobe, the visual experience booting up and running CFBuilder is very good.  Visually, the application looks very nice.  RDS support is basically required to use ColdFusion builder, so anyone who isn't doing local development will pretty much have to beg, borrow or steal an RDS password for a shared development server. Based on the server admins I've worked with, if you or your group don't maintain your own ColdFusion development server, you're best off switching to Local Development. It's just the only way.

The Snippet support is almost identical to what many of us CFEclipse users have come to expect over the years, right down to the $${variable} substituion.  Unfortunately, while the snippets are stored in an XML format, it doesn't appear to be the same schema as the CFEclipse snippets.  It's likely a simple .xsl transform could turn all of your existing CFEclipse snippets into ColdFusion Bulder snippets though.

One very nice feature of the ColdFusion development perspective is the "TailView" component, which allows you to watch your log files for new entries.   This is a capability that Linux and Unix users have been very familiar with for years, but which is astoundingly hard to find on the Windows platform.  Integrating it into the IDE is a very nice touch, and allows you to use for debugging very easily.

Speaking of debugging, the stepwise debugger plugin from ColdFusion 8 is included in the install.  I haven't used the debugger in ColdFusion 8 extensively, but it appears to be integrated seamlessly with the CFML editor view, so that you can set break points.  I'm not sure whether thats an improvement over the CF8 debugger, but it's certainly very nice.  One caveat, you must make sure that Line Debugging is enabled in your ColdFusion Administrator.  Of course it requires RDS, but it's definitely worthwhile.  Additionally, the ability to watch expressions and see variable values is really nice, and the handling of CFCs, structures and arrays works very well.  I'm most impressed with the debugging features.

The "Outline" view in ColdFusion Builder is another feature that CFEclipse users will be familiar with.  Unfortunately, the ColdFusion builder team didn't choose to include the (in my mind) more useful "Object View" which shows which methods and parameters are available in CFCs.

The code assist does a moderately good job of finding variable names to offer up as code completion when typing.  Unfortunately, it only appears to interrogate the current file looking for variables.  It would be nice if (like the Eclipse PHP Development Environment) it searched the library and execution paths to find which classes and variables were defined, and give you code assist for all variables and methods.  However, given the highly dynamic nature of ColdFusion and CFCs, it's understandable that this is a huge challenge, and hasn't been implemented.  It would be a clear advantage though, if the team were to implement it.

The "extensions" are kind of nice, but I don't see them having a large impact on my day to day coding.  They seem to be a great way to stand up a new application in a short time, allowing you to build large ammounts of code quickly, but for the more common "Brown Field" work that makes up 80-90% of my work days, its probably not going to be of much use.


The Good - Debugging is amazing.  Really good job here. I know some folks will really like the Word Wrapping, which has been a notable hole in the Eclipse platform for a very long time.  The Aptana integration makes editing JavaScript and CSS along with your ColdFusion code very nice and easy to do.  Youv'e got a good start with the code assistance, and I'm looking forward to what will happen in future versions.  Hopefully there will be some even better things to come.

Low Hanging Fruit - The ability to import a CFEclipse Snippet library or connect to a SnipEx server would be nice.  Implementing the CFEclipse "Methods" style view should be pretty easy, and it's much more useful than the outline view when working with CFCs.

A bit of a pain - Basically requiring RDS support is a thorn in the side of lots of developers in corporate environments.  Corporate server admins read the CF documents that say that "RDS is a security hole in a production server" and think that means that they shouldn't let developers have access to it.  It's a long, hard battle that nobody really wants to fight.  Some bits, like the "Service Browser" offer up entirely unhelpful messages such as "Unable to get meta data for cfc." without any explaination of what could be done to fix it.  Likewise, I got "Unable to fetch server mappings. Reason :null" in my console on startup... What does that mean?  Nobody seems to know.  Fortunately, most of these errors are in places that don't affect the core usability of the system, but hopefully they'll be cleaned up a bit before the final release.

The Bad - The lack of Linux support is really a deal breaker for me.  I do about 50% of my development on Windows, and 50% on Linux.  If I have to choose between using ColdFusion Builder 1/2 the time, and CFEclipse 1/2 the time, or just using CFEclipse full time, I'll probably go with the CFEclipse option.  The lack of support for Eclipse 3.5 puts this solidly behind the curve when it comes to Eclipse plugins.  This is more of a problem with the Eclipse platform, since each yearly release changes so much that every plugin has to be completely rewritten in many cases, but it would be nice if Adobe were to release a plugin that actually works with the newest stable Eclipse version, instead of constantly trailing one release.  Further, because of its narrow focused Eclipse version, even running ColdFusion Builder and Flash Builder in the same eclipse instance may be a challenge.  A little more version compatibility would be nice.