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.
-
What?
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
- Google Maps - When data is uploaded from a GPS device it is first sent to the Google Static Maps API to create the static images for the GPS tracks seen on the home page. When you click through on one of the static images to get to the dynamic full page maps, the mapping uses the Google Maps JavaScript API
- MySql - The database is MySQL which is great for my needs
- ElasticSearch - The textual search functionality is provided by ElasticSearch (which is itself layered on top of Lucene) with this Scala application using the play2-elasticsearch plugin on top of ElasticSearch
- The Joda-Time framework - The Joda-Time framework makes up for the deficiencies in Java's date/time libraries and the nscala-time component helps it's use from Scala
- SecureSocial - The application uses the SecureSocial Play extension 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:
- Google Maps JavaScript API - The Google Maps API provides the mapping functionality that is central to the TheGpsBlog application.
- 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 a bit of a revelation. I knew that my JQuery / callback based code in the previous version of the application was getting a little icky. The use of Backbone on the "Single Page App" that is the Stats Page of this application showed how far client side JS libraries have moved on in the last few years. Client side templating uses underscore.js.
- The Angular framework - While Backbone was a revelation when I first looked at it, 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. For something that uses a bit more Angular functionality, 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 JQuery framework - The JQuery framework is still great
- 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.
- X-editable - the X-editable JavaScript library provides the rather nice in-place editing for those with admin access
- mb.extruder - mb.extruder provides the "fly out tabs" that can be seen on the detailed maps page
- vAccordion - vAccordion provides the Angular based multiply nested JavaScript "accordions" on the Photo Galleries page
- Image upload - Sebastian Tschan's JQuery file upload and image gallery utilities (based on JQuery and Bootstrap) fitted really nicely with this project
- last.fm data - last.fm app Just for a bit of fun, music "Scrobbled" to last.fm is displayed here. The source code is available on my GitHub repository
On the non-functional side:
- Google PageSpeed - The Google PageSpeed Module provides the server side automatic optimisations to try to minimise the delays in downloading the HTML, CSS, JS and images to the browser.
- New Relic - The free New Relic service provides the application availability monitoring and alerting.
- Linode Longview - The Linode Longview service provides the application performance monitoring and alerting.
- CloudFlare - The free CloudFlare service complements PageSpeed for web page performance and provides CDN and some DDOS services. It also provides the browser visible HTTPS.
- LetEncrypt - The free LetsEncypt Certificate Authority provides the HTTPS certificate that ensures that traffic between CloudFlare and the host Virtual Private Server is encrypted
On the documentation side:
- Swagger - The Swagger / Open API
tool set provides the YAML editor and the UI framework that displays the documentation for many of the GPS Blog APIs.
The Swagger UI framework also dynamically creates forms for exercising the APIs.
The GPS Blog API documentation and the Swagger dynamically created test forms can be accessed here. There is also support for exercising the APIs using Postman (with the Swagger definitions imported as a Postman collection).
If you think I've used your framework in the application and not listed it please do let me know here
- 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.
-
Why?
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. See the previous FAQ entries for more details.
-
Who?
Answer: Built by Aidan Whiteley (who has an unmaintained web site here) along with Scooby.
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! -
Scala?
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.
-
APIs?
Answer: Much of the GPS Blog is implemented as APIs that are called from JavaScript on the client side. The read-only subset of these APIs are documented and can be exercised here.
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.
-
Browsers?
Answer: For a while I tried to keep this application accessible from browsers as old as IE8. However, a couple of external depdendencies that do not support IE8 (the Navionics charts and CloudFlare / LetEncrypt SNI based HTTPS certificates on IE8/XP) means that I have given up on older browsers.
So it is IE10+ and recent versions of Chrome, Firefox, Opera and Safari now. The site should work well with mobile browsers and tablets but it is only tested on an Android phone.
-
Music?
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.