Hacking with Ember.js

Yesterday I went along to the London Ember.js User Group hack day, it was great fun and good to see a helpful community already developing around the project.

The idea was that we would group up and mix the more experienced Ember’ists with beginners, although with Ember being such a new framework that is changing quite rapidly there probably isn’t such a thing as an Ember expert. There were two themes that we were encouraged to build our hacks around: something that connected users to one another and anything that could be considered a game.

The Meetup was hosted by Enthuse.me who have built their product using Ember and are also sponsoring the Meetup group. The agenda for the day was pretty straight forward, get into groups, decide what you want to build (using Ember of course) and present back to everyone at the end of the day.

I had already been playing around with a simple chat application that used WebSockets and found a group that was thinking about doing something similar.

We spent the first few minutes discussing what our app should do and sketching out a rough wireframe. Soon we had a pretty good idea of what we wanted to build – a chat app that displayed messages on a map, rather than just a traditional list, plus everyone knows that a good hack always somehow involves Google Maps.

Enter Ember

In our team only myself and another person had laptops and we were both just beginning with Ember so our first few hours were spent going over the basics. Because Ember focusses heavily on convention over configuration a lot of things happen ‘magically’ without you having to call lots of methods explicitly. Previously I’ve used Backbone which is almost the opposite, requiring that you tell it exactly what you want to do.

The magic Ember does is smart and makes sense when you understand it’s conventions, but coming to it as beginners we found ourselves spending a lot of time inserting breakpoints to debug our app and to find out exactly what was happening as our code executed.

Previously I found Ember quite frustrating to work with, mainly due to the lacking documentation coupled with a rapidly changing API. It seems that I wasn’t the only one struggling to get to grips with it but the Ember team have acknowledged this and over the last couple of months the documentation has really come along and there are some good tutorials available.

The Hack day

As this was my first hack day I wasn’t really sure what to expect. In the end we didn’t manage to finish our app in time, for which there were some contributing factors, but we did at least have something to present at the end, even if it wasn’t feature complete. I really enjoyed the experience and found it a great way to learn something new.

There were a few things that didn’t work out in our group, but they were good things to learn from:

  • Architect then build. We had a good idea of what we wanted to do and even sketched out a basic wireframe. But later on I felt that maybe we’d jumped in too soon, with too broad an idea, as we ended up having to pause and think out what we were doing.
  • Hack things quickly. We probably spent too much time thinking about and implementing things the proper way, rather than hacking them together quickly and there was precious little time.
  • Don’t block. Even though there were only two of us working on the app, we ended up blocking the progress of one another as we waited for the other to implement functionality. Or having to resolve merge conflicts as we were working over the same lines of code.

In the end I think we probably bit off a bit more than we could chew, given that we were two beginners with very limited time to build something quite complicated.

Time’s up

When the time was up we had accomplished quite a lot, but sadly not enough to be considered for the hack day prizes.

In the end ours worked as follows: you load up the app and you are prompted to enter a username and grant access to your device’s geolocation, as you do each of these things it broadcasts that data over a WebSocket so each connected client can see a realtime list of connected users and their location on the map. Unfortunately we ran out of time just as we were implementing the functionality for users to send messages, but with a bit more time we probably could of nailed it. I’m proud of what we did manage though and intend to finish the app off, probably over the next few weekends. The code is up on GitHub and is of course very hacky and un-polished.

The hacks that the other teams built were really impressive:

  • iSpy – An IRL game in which participants volunteer themselves as “spies” and let “controllers” direct their motions. Think murder-mystery party meets speed dating, but real time and city wide, then colour in the rest yourself.
  • HatChat – A fun chat app that makes you pick an avatar instead of an alias.
  • An app that grabbed data from the Meetup API and displayed it on a map, with a nifty search bar that filtered out results by keyword.

Overall I’m much happier with Ember than I was previously. It’s got great promise and I really hope it can follow through. The documentation has improved considerably in a short time. There’s Ember 101, which has got easy to follow tutorials, that are short and best of all, include full working code examples. Thanks to the hack day now I know there’s a great community out there as well.


Ember & Ember Data

Playing around with Ember this weekend I had a very frustrating time getting it working. Whilst the documentation isn’t bad per se, it is completely devoid of working examples, instead it only has snippets of app and template code.

Since it’s such a new framework there have been significant changes in the last year meaning any tutorials you might find online, even from a few months ago, are out of date and may include no longer functional or no longer recommended practices.

I did manage to find one good screencast by Toran Billups, as I followed along with the tutorial with my own code and got to the point where I needed to define my Model I found that Ember handles this with Ember Data. This isn’t currently part of Ember’s core and isn’t available for download, instead you have to clone the repo and build it using Bundler.

At this point I almost gave up.

For some reason, possibly related the version of Ruby installed on my machine, it simply refused to compile and not being a Ruby guy I didn’t really fancy spending the rest of my evening tracing obscure debug messages in a language I didn’t really understand.

After some food and some thinking I came back to the problem. Rather than trying to compile it myself I figured that someone else must of done this already. Googling around I found a few versions, one of them even on the project’s GitHub download page, but none at the latest version. I went back to Billups’ screencast to just watch the rest without following along when I spotted a link to his GitHub repo of the project.

‘Aha! that should have the code I need’ or so I thought. GitHub was having a ‘Major service outage‘. Great. Fortunately the outage wasn’t so major that I wasn’t able to download the zipped version and extract the elusive library inside. At this point, if it had been a game, it would of been a little bit like this.

Now I can understand that the Ember folks make you jump through the compile hoop because things aren’t stable yet and they don’t want loads of bug tickets for things they already know are broken. But raising the bar too high doesn’t help either, it’s much more helpful to newcomers to have a simple working demo and up to date documentation than a suite of unit tests. I understand that Ember is still new, it’s not even 1.0 yet, but a little help for us newbs would go a long way towards building a stronger community around the project.

It’s worth saying that after all that when I finally got my basic little app working, it worked great and I’m looking forward to doing more with Ember in the future.

Tl;dr: Open source projects: always be newb friendly. You can download Ember-data.js here.

Little Lightbox_me quirk

Using the excellent Lightbox_me jQuery plugin the other day I came across an interesting quirk. When you lightbox an element, Lightbox_me moves that element in the DOM to a container it creates to lightbox it, but when you close the lightbox it doesn’t put it back where it found it.

The Problem

In my case I was using jQuery’s find function to look inside the clicked element’s parent to find the element I wanted to lightbox. This was because I had multiple elements on a page I wanted to lightbox, so I started with something like this:

$('.button').click( function(){

Which worked fine when you clicked on the button the first time, but if you closed the lightbox and clicked the same button again, nothing happened.

The Solution

After prodding about for a while I noticed that Lightbox_me was moving the .lightbox element from the .container element, sticking it in another div hidden at the bottom of the DOM, and crucially, leaving it there after the lightbox was closed.

Obviously this meant when the jQuery looked for the element in the parent a second time, it wasn’t there. So the solution was to change the markup so the trigger had a rel attribute that matched the targets ID, meaning it could be found wherever it was in the DOM.


<div class="container">
	<a rel="my-lightbox" class="button" href="#">More info</a>
	<div id="my-lightbox" class="lightbox" style="display: none">
		Lightbox content


$('.button').click( function(){

My thanks to Justin Perry for helping me troubleshoot this issue.

1kB JavaScript = 1ms parse time

Optimising some JavaScript today (exciting, I know) and going through the Google Page Speed documentation I came across this little snippet:

In our own tests conducted in early 2011, we found that on modern mobile devices, each additional kilobyte of JavaScript adds about 1ms of parse time to the overall page load time. So 100kB of JavaScript included in the initial page load would add 100ms of load time for your users. Because JavaScript must be parsed on every visit to a page, this added load time will be part of every page load, whether loaded from the network, via the browser cache, or in HTML5 offline mode.

— Optimize for mobile: Defer parsing of JavaScript – Google Page Speed