Archive for the ‘web’ category

Diving further into Clojure

As I mentioned earlier I decided to start playing around with Clojure on my Windows box. This was an excellent way to get a quick introduction to the language, although there were aspects of the Windows platform that made going any further than toying around somewhat pointless. Although, this could simply be my bias towards Unix style systems.

When I decided to set up clojure on my Ubuntu installation, it felt like there was a huge wall in my way that made absolutely no sense. This was really because I had made a few mistakes when installing my editor of choice (emacs) from apt. That being, I had installed various emacs plugins such as swank and slime which caused some really frustrating problems to arise when running swank-clojure. I found in the end, the easiest thing to do is get a full install of emacs going, without any extra bells and whistles; that’s what the ELPA is for, and it does a damn good job at it.

Once my emacs was back to a good state, I was able to get the clojure-jack-in function to work the way I was expecting it to. Finally I was able to get hacking! On the windows box, I was (and still am) doing a text adventure game from the Land of Lisp book. I’ve found this to be an excellent way of stepping into the language, especially since the book assumes you are using common lisp. This has lead to a fair amount of research into finding out clojure equivalents to CL macros. Meanwhile, on my Ubuntu machine I’m working on a project that I’m hoping will make one part of my life a bit easier.

I’ve found that when it comes to doing tasks, such as groceries, it can often be a pain. My partner and I use our phones for entering our grocery list and each time it’s excruciating. These keyboards are annoying to use, our Nexus ones have those poorly placed heat sensitive buttons that your thumbs always manage to hit, and the program we are using doesn’t learn very well. So I’ve decided that the first step in making this better would be to have an application that makes at least entering the data easier. I’ve decided that I’m going to implement this tool using Clojure, because I’ve found I’m loving the way you do things in the language (it feels more mathematical). I also feel that since I’m extremely green with the language that I’ll be required to keep things simple (I still cannot get [& args] working for whatever reason!).

In an attempt to keep things simple, I’m avoiding the database… well that’s a lie. I’m avoiding the Relational database. I’ve always found that when I use a tool like Rails I tend to over-complicate my models for whatever stupid reason and it just leads to me abandoning the project.  I’m also interested in playing with document stores (in my case MongoDB) since I love to use hashes/JSON.  It just so happens that there is a library called congomongo which is pretty easy to setup and start playing with MongoDB. Once I’m done getting this part of the application working, my next plan is to play with the Noir microframework (similar to Sinatra or Flask) to implement my web app.  If I decide to continue working on this, it probably won’t scale all that well, but at least it’s simple enough to not overwhelm me at first.

Getting Scalded by CoffeeScript

As part of my day job at Shopify I’ve been implementing a new front end using the language CoffeeScript. Originally, the front-end was regular JavaScript, but since Rails 3.1 will be supporting CS we might as well start using it.

As a whole, the language isn’t that bad. I do appreciate many of the helpers it provides for enumerating hashes and arrays, and bindings (aka fat arrow) are awesome. It’s made writing some complex client code that relys on context far easier, especially since the new features like .bind aren’t available on most (if any) mobile devices (although this is easily fixed with something like 5 lines of code).

My main complaints about CS are with some of the edge cases it has. For example, I needed to have a bound anonymous function within a setTimeout. In JS I would typically perform something similar to:

  // May be a little bit off here, but I think that's how to do ECMA5 binds
  function(){ this.doSomething(); }.bind(this),

The above is fairly straight forward, and the language doing anything I’d consider unexpected. Though if we were to do the same thing in CS, I’d expect it to be something like this:

setTimeout( => @doSomething(), 150)

This actually doesn’t work, the coffee compiler will complain. It’s somewhat understandable, there some weird stuff going on here and it’s difficult to parse. A solution I often used was this:

setTimeout( (=> @doSomething()), 150)

Now I have all these extra brackets that I shouldn’t need, and it’s frustrating because I’m trying to use th language the way it seems to have been designed. Now this had been bothering me for some time now, and decided to twitter rage/complain about it. This did get some attention from someone who runs the CS twitter account who gave me some suggestions. Those of which I found to be somewhat hacks, or wouldn’t work in my case.

One solution was to have (in my case) the fetch method bound to the products instead of having a fat arrow function declaration. Now, since the actual model that products Points to is a Spine model, I really don’t feel like going in and hacking something (that already works the way I want/expect) for such a minor (but annoying) problem with CS. Another solution was to essentially create a function that is in essence setTimeout but reversed, so it’s something like:

delay = (delay, function) ->
  setTimeout(function, delay)

Which I’m also not super keen on, once again it’s going through a bunch of extra steps to fix an inherent problem with the language itself. Now I often do mix up the arguments used in setTimeout, and I would love to see that get fixed/added in the future.

I mentioned the problem I was having to one of our awesome (and way smarter than me) interns about it and he actually came up with an almost perfect solution.

setTimeout( =>

Aside from that preceding comma and needing to remember to un-indent, it’s not a big deal and I like that I’m not having to go in and hack apart Javascript to fix minor issues.

Although I do seem to be a bit bitter about my experience with CoffeeScript, I do have to say that I like what the language is bringing to the table, I just hope it gets some improvements for CS 2.0 or something. Perhaps having some kind of explicit scope declaration (like begin end or curly brackets), would help out a fair amount. Though, I think I can keep dreaming for having curly brackets, there seems to be some kind of aversion towards them.

PhoneGap isn’t PhoneGap isn’t PhoneGap

I recently discovered that although PhoneGap is pretty awesome, there are some things you should know before you go out and try to get it working on your melange of devices.

phonegap.js isn’t all that you expect it to be. That is to say, phonegap.js for an iPhone isn’t the same phonegap.js that is used on Android. So, if you are going to be dropping phonegap onto a bunch of different devices while testing, be sure that you are using the proper javascript file. Otherwise you will be stuck scratching your head wondering why the camera works on platform X but not platform Y.

They are hoping to get that taken care of in the future, but for the time being you’ll have to be sure that you are using the proper file.

STO on the Go is Live

Earlier last week I was trying to view the bus schedule from my device. Unfortunately, I have a T-Mobile Nexus one on a Rogers network; so EDGE speeds only. The website for the buses I take is pretty much image driven, so pages take forever to load. And even when things do load, sometimes opening up the links doesn’t work (don’t even try on a BlackBerry!).

I’d had enough of it and figured I would look into getting a mobile web version that would be extremely light that provides all the functionality you would need to find out what are the timings for the bus route you want. Now, the application does still have some bugs in it which mainly have to do with my poor AJAX and jQuery skills but it does do the job.

You can access the site by visiting I’ve tested it on the iPhone, Android and Blackberry and it works pretty well. There are some issues with the clicking of stops on a BlackBerry, but there is a fix which is achieved by moving your cursor to the top of the screen then mousing over each item. When you get the ][ symbol click and you should be brought to the bus listing for that stop.

If I have some time over the next few weeks I’ll work on it some more to style it a bit so it will actually look good on a mobile device as well as increase the hit zones for everything to make the interface easier to interact with. I also intend on plugging into it to provide a native Android application that will allow you to cache everything on disk in order to reduce network usage. Maybe even allow configuration of caching based on what kind of connection you are on.

If you’ve given it a shot, please leave me your comments about how the experience was as well as what kind of device you were using.


Since the STO has recently changed their travel planner, it is unfortunate that the changes have effected the STO on the Go site. Because of how the new planner works, it will not be worth the effort to try and fix which is rather unfortunate since the new site is very unfriendly towards mobile devices.