Occasionally asked questions
Here are a few answers to questions that almost no-one has asked me about this application. Mostly it is a place to record my appreciation of the various open source frameworks that have made this application quick and fun to build.
Answer: This application has been put together using some great open source software libraries.
On the server side:
- The Scala language - I've been using Java for umpteen years (and C++ before that). So it has been really fun to do some development in a different language - Scala - that blends
Functional Programming concepts alongside the more traditional Object Orientated.
Actually - I still really like Java but a change is as good as a rest.
- The Play framework - The Play framework is a new(ish) framework for server side web application development. I'd previously used the 1.x Java version. This application is developed with the 2.x Scala version
- MySql - The database is MySQL which is great for my needs
- Silhouette - The application uses the Silhouette library for authentication against social networking sites such as Google and Facebook
- Geodesy - the application uses Mike Gavaghan's implementation of Vincenty's algorithms to calculate distances and bearings between latitude/longitude pairs. The application is "hard wired" to the WGS84 datum.
- Google Protocol Buffers - using Google Protocol Buffers helps to keep the data size of the large number of GPS track points under control.
- Photo geo-location - because I don't have any new "toys" to play with (i.e. devices that geo-tag where where pictures are taken), the method of placing photos onto GPS tracks is a little low tech! The Etadator Xtractor by Drew Noakes is used to extract Exif data from uploaded photos including the date/time the photo was taken. If my camera's time is out, that'll explain why the pictures appear at the wrong places on the GPS track!
On the server side - the Java bit...
Because I needed some "hands on" experience with Mongo and its current Java driver, the Find functionality was "bolted on" and implemented with:
- MongoDB - Data from the main relational database is synced into a MongoDB replica set and queried from Java using the Java driver. As this is a GPS tracking application, there is a lot of use of the GeoSpatial query operators and GeoJSON.
- Spring Boot - As a long time user of the Spring framework, any Java work always starts with the
Spring Boot framework these days.
It is just so quick and easy to get a working app up and running with Spring Boot.
This time, for a change, Spring JPA Repository functionality was used for the relational data access. No code, no SQL - it just takes as while, as an infrequent ORM user, to get the JPA annotations all correct!
On the client side:
- Navionics Web API - The Navionics Web API
provides the marine chart overlays that are combined with Google Maps for activities that took place on the water.
Both this and the underlying Google Maps API are great, great free (at low volumes) APIs - thanks!
- Google Elevation API - Google's Elevation API is used on the client side to provide an alternate view on the ups and downs of activities. This option is provided as at least one of the GPS devices we use isn't always that good at recording accurate elevation data. Note that only Cycling and Dog Walk activities show elevation data - there isn't much point for sailing and canoe activities on the estuary and sea!
- Google Geocoding API - Google's Geocoding API is used to as part of the solution on the Find page.
- The Backbone framework - The Backbone framework was used on the "Single Page App" that is the Stats Page of this application. Client side templating used underscore.js.
- The Angular framework - While Backbone was a revelation after being used to working with JQuery, industry momentum moved towards the Angular.js framework (before getting bored and heading off to React ). The Contact page has a "toe in the water" doing some basic validations using Angular and the Photos page makes more extensive use. More recently, I've started using React more than any other client side framework. For an example, have a look at the Music FAQ (but this really doesn't have much to do with the GPS Blog)
- The Require.js framework - The Require.js enabled modular code while allowing performant production code. r.js is being used for the minification / merging which is fine but has some problems when trying to load some files from CDNs while still having dependent, shimmed modules in the merged file...
- The Owl slider - The Owl Carousel is the image slider on the front page of the web site. It's a great framework and allows for Ajax based data retrieval
- The DataTables plugin - The Datatables plugin provides the tabular UI/functionality on the search results page
- The UI framework - The UI framework is the only paid-for framework in this application.
About a tenner buys the Crisp cool framework
which is based on Bootstrap.
The Cool-Crisp uses a whole bunch of open source / 3rd party frameworks which are detailed at here and which include the FancyBox responsive lightbox used with the image gallery in this site's page footer.
- The TagCanvas framework - The TagCanvas framework is the HTML5 canvas framework that provides the application's tag cloud UI
- Flot - the Flot JQuery based graphing solution provides the client side graphs.
- mb.extruder - mb.extruder provides the "fly out tabs" that can be seen on the detailed maps page
- Image upload - Sebastian Tschan's JQuery file upload and image gallery utilities (based on JQuery and Bootstrap) fitted really nicely with this project
- The Scala language - I've been using Java for umpteen years (and C++ before that). So it has been really fun to do some development in a different language - Scala - that blends Functional Programming concepts alongside the more traditional Object Orientated.
Answer: This application was being built for a couple of reasons
- To hold GPS tracks
- I have a Garmin Montana 600 that I use for sailing trips. Liz has a Garmin Edge 500 that is used for bike rides and sometimes taken on dog walks. Seeing a record of where we have been is sometimes interesting in a kind of techie way! Being able to hang photos off the associated GPS track is also a nice way to view them later.
- To try out new software
- I needed a project to try out some of the newer software frameworks that looked interesting (or at least were fairly new when this project was started way back when!). See the previous FAQ entries for more details.
Answer:Built by Aidan Whiteley along with Scooby hound.
In fact, Scooby wrote very little of the actual code but has knockout suggestions for the content for the "Dog Walks" activities shown on this web site!
Answer: The first version of this application was built using Java on the server side. The current version has been implemented in Scala.
I'd been looking for a project to practice some Scala development but completion of the Cousera Principles of Reactive Programming course was enough to prompt me to re-write the previous version of this application in Scala.
If you are interested in Scala I can also highly recommened the Cousera Functional Programming Principles in Scala course which I believe has now had over 100,000 people enrolled.
In fact, I think that one of the best things about Scala is that its popularity may well have been a contributing factor in getting significant support for functional programming idioms in Java 8.
The Swagger / Open API toolset has been used to document these APIs in YAML format and the Swagger UI tool provides dynamic forms to exercise the APIs as well as the textual documentation. Additionally the Swagger configuration has been imported into a Postman "collection" to allow the APIs to be exercised from within Postman.
Answer: Something recent please!.
Answer: I'm glad you asked. The music that we've been listening to while on the activities collected on TheGpsBlog or while coding TheGpsBlog are shown here.