(I’m not quite sure where to put the link to the GitHub repository, so let’s just put it up here and be done with it, shall we?)
So I recently (as in, just now) finished up a small side project that was requested by a company I applied for a job with. They basically wanted me to program a simple templating engine, sort of like Handlebars.js, that could inject JSON data into a template and spit out the result. They said that I could use any programming language I liked, but, judging from the instructions, they seemed to want some sort of console application. While I suppose I could have done it with Node.js or — better yet — Python, I thought this might be a good opportunity to reacquaint myself with Java and Maven after several months away from both.
While I don’t see this task as being significant enough to merit its own page under the Projects tab, I did find it on the whole to be a very useful exercise. It made me really sit back and think about how to organize tasks that one usually takes for granted in most scripting languages. For instance, when writing the class that reads and stores the template file, I initially just planned to have a single Boolean (isInEachBlock, I think) outside of a loop to flag whether or not the current chunk being processed should be added to the root template object or to a subsidiary object representing the last-found for-each block. Then I wound up wondering: so what happens if I have a for-each loop nested inside of another for-each? Or three nested for-each loops, or so on? I had to reconsider my entire approach. In the end, I wrote a manager class to handle the whole issue — EachTokenFactory, for the curious — which could theoretically take up to thousands upon thousands of nested loops. (The exact number depends on the computer/virtual machine running the application. On my basic-model Mac laptop, that number appears to be 2,147,483,647. More nested for-each loops than a user could ever want, in other words.)
Otherwise, I don’t have much else to say by way of a post-mortem. The application spits out more whitespace than I personally would like in the HTML — but that’s the way that the sample output that the company gave me looked, and I wanted to try to match that in case they ran a diff. I suppose if I really wanted to go all out, I could have tried to figure out a way to increase the templating language’s capabilities — put in conditional statements, for instance — but that probably would have been overkill.
Could I ever see myself writing a templating app like this for production use? Eh. I doubt it. For one thing, I’m sure there must be bajillions of open-source programs out there that accomplish the same task. For another, I doubt something like this would perform very well under real-world conditions. Unless you found a way to combine it with caching or bytecode compiling — the way that a certain proprietary Disney templating language I used at ESPN does — chances are that those hard-disk reads would be murder on the servers. (Or at least that’s my impression.) Besides, when push comes to shove, you’re still throwing together resources at runtime. At that point, as far as I’m concerned, you might as well just use PHP and get the extra capabilities.
But, hey, like I said, it was a useful exercise and a nice little something to add to my GitHub code samples. If nothing else, it reminded me of a basic fact that I still find fascinating about computers and programming: that all of our accomplishments in information technology — the Internet, Wikipedia, Facebook, mobile apps, everything — basically boil down to machines whispering strings of words to each other across the continents. (Well, okay, technically, strings of numbers, since computers express everything in binary — but still. It all just comes down to Strings, doesn’t it? Find the right words, and you can change the world.)
