How I won the ESRI DevSummit 100 lines of JavaScript competition

29 Mar 2013

First I'd like to emphasise that this is a blog post on how and not why. The why comes down to the judges. So, thanks Judges! Secondly I'd like to thank Rob Dunfey for the idea and for providing additional motivation - I'll dig deeper into this later. Finally: what am I going to cover? As the title suggests, I want to cover the how.

What that means is:

  1. The Idea
  2. Solving a Real Problem
  3. The Motivation
  4. A Developer's Toolbox?
  5. My Developer's Toolbox - How the Realtime Collaborative Mapping app was built
  6. What has been achieved?
  7. Where next?

The Idea

Rob's Brain
Rob's Brain

I've been friends with Rob Dunfey ever since I worked at ESRI back in 2005. When I worked there my job title became "GIS Consultant" but if I'm honest I was really only ever a Web Developer (that's not a bad thing). Since then we've worked on a couple of projects together - Rob now works as a Geo-Information Consultant at Shell and I'm a "Developer Evangelist" at Pusher. I'm following my passion for Realtime Web Technologies and web development, and Rob is following his passion for GIS.

However, we do infrequently work on projects together and, to be honest, it's sometimes quite difficult to get Rob to slow down with his ideas about using GIS to solve real problems. One of the things he also sees is the opportunity to use web technologies to solve those problems.

So, two weeks ago Rob got in touch with me - not to discuss his impending wedding on Monday - but to tell me about the 100 Lines or Less ArcGIS JavaScript Code Challenge!

Solving Real Problem

Rob said:

Frequently we encounter a business problem that requires a solution enabling multiple colleagues capture information on a map at the same time, in a dynamic fashion. One such use case may be a workshop event, where you want to capture locations favoured by attendees - you could try that at the Palm Springs dev summit, if you ask attendees to mark up a map with their home location, all done real time, allowing the conversation to develop around the map edits - real time.

If you've seen the README for my Realtime Collaborative Mapping entry you'll notice that the introductory paragraph is almost identical to this.

The ability to collaboratively edit a map in realtime had clearly been identified as something that people really want - and need - to do: A problem that needed to be solved.

Could this be done in 100 lines of JavaScript or less? Yes.

The Motivation


To succeed at something it's important to be motivated. I'd like to think that in this case the motivation behind the Realtime Collaborative Mapping application really helped ensure that the result was successful.

If you combine my knowledge of realtime web technologies with Rob's knowledge of GIS then the most obvious use case is a realtime collaborative mapping application. So, we've been discussing this idea for quite some time. This competition was the perfect platform to get Rob off my back prove that the idea we've been bouncing around for months could be achieved.

And not only could it be achieved it could be done in 100 lines of JavaScript or less.

Finally, I've been working with realtime web technologies for over 10 years now and I saw this as a great opportunity to demonstrate the power of realtime web technologies. And to demonstrate that using realtime web technologies is really easy.

A Developer's Toolbox?

Developer's Toolbox

The role of a developer has changed quite a bit since I graduated with a Software Engineering degree in 2001. Up until I joined Pusher my role was primarily a Software Engineer attempting to follow what the industry defined as "best practice"; first documentation through to development (the waterfall model), then an increased focus on testing, which continued with the introduction of agile in the form of Extreme Programming (XP), SCRUM, Kanban etc.

The reason that things changed when I joined Pusher wasn't because the development team don't follow those best practices (or their own incarnation of them) - they do. It's because I started to attend hackathons where the focus is creating something functional - ideally with a wow factor - within a short space of time.

The teams that tend to win such events aren't necessarily the best software engineers, but are those that have a developer toolbox that they can look through when they are trying to solve a problem.

A knowledge of a programming language isn't simply an understanding of syntax and structure; it also covers a knowledge of the libraries and extensions that are available as part of the technology runtime. A developer toolbox goes beyond an understanding of a development runtime. It extends to:

  1. Productivity tools: Development environments (editors, IDEs, OS tooling, testing, profiling, debugging and hardware)
  2. Application runtimes and frameworks: for web development where you probably (see point 4) need a web server and a database this is important. Your developer toolbox should contain these already setup up and ready to go. Or provide ways of quickly doing so.
  3. 3rd party libraries: if a problem has already been solved by a library then use it
  4. A knowledge of APIs and hosted services: By knowing what APIs and hosted services are available you can quickly uses these tools to achieve things that would otherwise take you hours to weeks to achieve.

Hosted services - which offer APIs - actually combine productivity tools, application runtimes & frameworks and the functionality offered by 3rd party libraries. This makes them amazingly powerful and, I'd argue, are becoming the most important tools in a developer toolbox.

My Developer Toolbox - How the Realtime Collaborative Mapping app was built

Realtime Global Collaboration

For the Realtime Collaborative Mapping application I used the following tools from my developer toolbox:

Note: Why didn't I use Pusher? Since I work for Pusher I use the Pusher API all the time. I saw this as an opportunity to use another API that I knew about but hadn't had a chance to really dig into. I also saw the application I was building as needing realtime data synchronisation with persistence which we (Pusher) don't presently offer - our focus is realtime messaging with integration into existing web stacks. This would have been achievable with Pusher but I would have needed a few more lines of JavaScript code to do so.

I chose these tools because the application was to be built using front-end web technologies with a heavy focus on JavaScript.

ArcGIS API for JavaScript

My usage of the ArcGIS API for JavaScript was really simple:

Angular JS

The routing part was really simple. I needed:

  • a landing page where users could enter an existing webmap ID, or choose from some pre-selected ones.
  • a map view which would have the webmap ID in the URL for easy sharing, show the selected webmap and let a user draw graphics on the map

Angular JS also provides a mechanism for exposing properties which offer two-way data binding. I used this to expose:


My use of Firebase goes to show just how easy it is to add realtime functionality to web applications using a realtime web hosted service. I used Firebase to persist and share the graphics data between all users who were viewing the same map.

  • Connect to Firebase and identify where the data for my app is to be stored within my "collaborative mapping" Firebase app. I appended a webmap ID so that all data associated with a given map would be shared. I could have appended another unique ID so that groups could share privately
  • I bound to child_added and child_removed events so the app knew when a new graphic had been added or an existing one removed
  • I used Firebase as a model for the graphics on my map. What this meant is whenever a new graphic was added I simply added it to Firebase and the added code was called. The really clever bit is that the code was not only called within the app of the user who added the graphic but also within the app for all other users who were view the same map.
  • When a user clicked the Clear All button I prompted the user for confirmation and then removed the webmap node from Firebase. In a real app I'd use Firebase security to restrict who was allowed to execute such a function.

I've supplied quite a bit of detail here. But this all actually only equates to the code using the Firebase object 5 times. Wow! 5 lines of code to convert a web application into a realtime collaborative web app - realtime web technology really is powerful!

What has been achieved?

Ok, I've won the competition - which is awesome! Thanks, ESRI. What I'm also hoping has been achieved is that by creating the application and writing this is blog post I've demonstrated:

  1. The power of realtime web technologies - with 5 lines of code I've made an application support multiple simultaneous users and collaborative. This means that anybody in the world with a web browser and an Internet connection can collaborate on a map with anybody else.
  2. How using a hosted service + API to add amazing functionality in fraction of the time and effort it would take to write this all myself.
  3. The importance of a having a well equipped Developer Toolbox - I hope this has got you thinking about what's in your Developer Toolbox. I'm sure the ESRI DevSummit has given you more tools to add to your toolbox arsenal, and it's important that you continue to improve what's in there by attending events, reading up on technology and trying things yourself (maybe at hackdays).
  4. Finally - something I'm really excited about - is how it's now easier than ever to use a fusion of technologies to create very powerful applications on the web. The Google Maps API launched in 2005 (whilst I was at ESRI) and if the ArcGIS API for JavaScript had been about who knows what I'd be doing now. I'm not a GIS developer, but I understand the power of GIS so I can't wait to see GIS appear in more applications. See TweetMap and ViziCities as some exciting examples.

Where next?

I'd really like some feedback on the application. I'd also like people to fork the application and go beyond the 100 lines of JavaScript (it is a bit messy) and change it into a real application - it does have real potential.

I also need to look into how I'm going to get to Palm Springs for the ESRI International Developer Summit in 2014. Maybe I could propose a talk about how I built the Realtime Collaborative Mapping application and get some costs covered?

Hopefully I'll see you at the ESRI Developer Summit in 2014!