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:
- The Idea
- Solving a Real Problem
- The Motivation
- A Developer's Toolbox?
- My Developer's Toolbox - How the Realtime Collaborative Mapping app was built
- What has been achieved?
- Where next?
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.
Solving Real Problem
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.
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.
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.
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?
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:
- Productivity tools: Development environments (editors, IDEs, OS tooling, testing, profiling, debugging and hardware)
- 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.
- 3rd party libraries: if a problem has already been solved by a library then use it
- 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
For the Realtime Collaborative Mapping application I used the following tools from my developer toolbox:
- Firebase for realtime synchronisation of data (graphics) between users.
- Create a map using a webmap ID
- Add a drawing toolbar to the map
- Add a graphic too the map when the user draws one and remove a graphic when required too
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:
- The share URL
- An encoded version of the share URL
- The type of drawing that the user had selected in the toolbar view.
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_removedevents 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:
- 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.
- 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.
- 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).
— Esri DevSummit (@EsriDevSummit) March 28, 2013
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!