HyperDrive: Update #1

Through my work on SidelineStats & G2TX I gained some basic android development experience. I’ve decided to make a start on the HyperDrive project by focusing on the server side code first.

As aforementioned I will be developing the server using Java and the Spring framework. I spent a very brief period of time working on a spring project at Guidewire but I barely scratched the surface. I’ve decided to learn the framework from scratch from a Udemy course.

So far in the course I’ve covered:

  • Getting started with Spring (Hello World).
  • Basic bean configuration.
  • Autowiring

I’ve started a very basic project to follow along with the Udemy course to learn the fundamentals. The code can be found over on my github page. Its been brought to my attention that xml configuration is the old way of doing things. Once I get through all the course material I will start looking into java based configuration.

To get a better idea of what rest services I will need to expose I’ve started working on a list of all the desired functionality of the website, I aim to have this completed by next week.

The week I also plan on putting quite a bit of time into writing the functional specification for the project.


Here is some of the articles I’ve read this week to help with the design of the api:


Introducing: HyperDrive

A big focus for me this year academically is my final year project. Here’s a brief rundown of the idea, how I came up with it and the technologies I will be using.


In September I finished a six month internship with Guidewire Software. Guidewire is a market leader in software for the insurance sector. During the internship I worked on an experimental project called the ‘Google For Guidewire Telematics Experiment’. The aim of the project was to develop an android application that would communication via bluetooth with a cars onboard computer via OBD2 adaptor, and send data about the trip to the cloud. This data would then be sent to PolicyCenter (a core product from Guidewire’s insurance suite used to issue insurance policies) where it would be fed into the rating engine and the premium would be adjusted accordingly.

Working on this project made me curious about how similar technologies could be used in a consumer context as opposed to an enterprise context. I spent weeks trying to come up with a creative and novel way to use driving data to provide end users with a new exciting experience.


My idea is to build an application that uses an android phones / tables built in GPS and accelerometer functionality to record data about a car journey. This data is then sent to the cloud. The user can then go to the web interface using a browser and log into their account. On their account they can see a list of all the journeys they have made. The user can see exactly the route they took overlaid on to google maps. The user will have the option to annotate these points with information relevant to there journey, if they passed some interesting land mark etc..

Beside each journey the user will have an option to view a hyper-lapse (exposure technique in time-lapse photography, in which the position of the camera is being changed between each exposure in order to create a tracking shot in time-lapse sequences) style sequence of their journey. This hyper-lapse uses google street view combined with the geolocation data to build up the video. In addition to the video the user will be presented with some basic metrics for each journey as well as some average metrics for the whole account. If time permits I would also like to use the Instagram developers API to gather a stream of photos taken along the route to make the experience feel more interactive and engaging.

The user will then be able to generate a public link to view this journey or share it publicly to their profile. The site will also have a secondary function. Without registering for an account users will be able to type in a start and a finish address and have a hyper-lapse video of a route between the two points generated. 


Since the functionality of this application is somewhat novel I do not expect its user base to use it on a daily basis. It is target towards holiday makers and else anyone who will be making long journeys that they don’t make regularly. The project is being built primarily as a holiday journey log and route preview tool, where key locations can easily be marked up on the users map with added notes. These journeys can then be shared with family and friends. The google street view generated video can give people an idea of the scenery and sights along the way.

Languages:                                                                         Tools:

Java                                                                                       Spring MVC 

JavaScript                                                                            Android SDK

HTML                                                                                   Angular.js

CSS                                                                                        ApacheTomcat

SQL                                                                                       Bootstrap

G2TX Project Update: Basic Web Interface Prototype

In the last two weeks I’ve made quite some progress with the G2TX project in work.

The project lead Luca Debiasi gave me a very basic brief and then left me largely to my own devices. I was given access to the cloud endpoint API and asked to build an web interface for displaying the data that was being stored there.

I decided to use angular.js to retrieve the data from the API as well as to add dynamic  functionality to the html.

As I had very little experience with the angular framework I took a couple of days to teach myself, using the CodeSchool ‘Shaping Up With Angular.js’ course as my main resource.

I used bootstrap to add basic styling to the HTML elements. I took inspiration for the layout of the UI from a DCU students final year project. You can check out his work here.

After two weeks hard work this is what I’ve come up with, below is the initial screen presented to the user upon loading the page.


I ran into a bit of an issue a couple of days into the development due largely to my design.

Every time the page was refreshed a function is called to initialize the google map. This piece of code was also calling the function to retrieve all data from the API. Which meant that every time the page was loaded a request was being sent off. Since I had spent a lot of time fiddling around with some UI components I had inadvertently sent a huge amount of traffic to the server.

Unknowns to me at the time Luca was also testing the android component of the project abroad and between the two of us we went over googles API request quota. This resulted in me wasting a couple of hours trying to troubleshoot my angular code to find out why I was getting a 503 Response.

To get around this I redesigned my code to initialize the map with no data when the page is loaded. Then when the user clicks the ‘Get tracks’ button a function is called to request the data from the API and then plot the points onto the map.

Here’s a screenshot of the latest version of the project.



At the moment all data is being requested from the server. Next on my to do list is to take the values from the form and build a custom query to retrieve specific data.

I demo’d the prototype in its current state to the accelerators development team at Guidewire. I received good feedback and a lot of interested in the project.

I plan to add more advanced search options to retrieve data with finer granularity.

If you’ve any questions about this project don’t hesitate to get in touch.

Getting started with Google Maps JavaScript API

This week as part of my work on the G2TX project i’ll be working on a Proof of Concept (PoC)  web application to map the events collected from the android application to an easily accessible web interface. This application will be linked from (if not embedded in) PolicyCenter.

To get things off the ground I started off by reading though the comprehensive documentation for the Google Maps JavaScript API.

mapscreenshotI created a basic project taking a few data points stored in an array and added them as markers onto the map. The resulting page looked like this:

The source code for the project can be found over on my GitHub account.


Joining Guidewires European Development Center

On the 23rd of March I joined Guidewire as a software development intern.

Up till now i’ve been working in the GSC (Guidewire Services Center) as a remote consultant specializing in Policy Center (one of Guidewires core products) on a project for Direct Line Group.

first day of work

This week I joined the EDC (European Development Center) in Guidewire.
I started a new project working with Luca Debiasi a senior developer.

The project G2TX (Google for Guidewire Telematics Experiment) is an experimental project from the Guidewire labs.

Project Description:

“The Guidewire Telematic Experiment tries to offer a platform to keep in real-time sync Policy Center / Claim Center with the coverable assets using the Google Cloud and Android services. An Android application acts as gateway between the monitored coverable (vehicle, building, drones) and the Google Cloud services. The Guidewire platform uses the data persisted in the Google’s cloud to quote premium in Policy Center, to validate terms are respected and to open a claim when accidents happen. “

Desired endpoint:

  • The Android application collects data from the vehicle via OBDII protocol wrapped by Bluetooth.
  • The application collects user’s data via NFC protocol from driver’s documents.
  • The Android application shows the map of movements and relevant events of the driver / vehicle.
  • The Android application transmit data to the Google Datastore Cloud service.

What I’ve been doing so far:

This week i’m pretty much getting to know the basics of android development as well as working with the Google Cloud Platform.


Two of the resources I’ve found very beneficial are:

  • This Udemy course on Android development.
  • This tutorial which covers the basics of Gradle as well as Google App Engine & Cloud Endpoints.

Final Touch Up Before Submission

Today was spend doing some final touch ups on both the client and server side of the applications before we submitted the code to our supervisor.

Conor thoroughly tested all functionality of the server side and gave me his opinions on any little improvements that could be made at the last minute.

I did the same for the android app. There wasn’t a whole lot that needed to be done just some slight improvements in aesthetics as well as implementing an undo button incase data was entered incorrectly.

Full Communication Between Client & Server

We now have full communication working between the client and the server.

Conor has added a button to the action bar in the app. When this button is clicked it prompts the user to log in with their S.L.S. registered email and password. Once the user is logged in there is a new option on the screen to push data to the cloud. The user just enters their unique match identifier that they are given when creating the match online.

Again we used http post here to send the data. We originally tried to send json formatted data but ran into a few issue doing this, because of the tight time constraints on the project we settled to send strings of data that could then be parsed to ints.

Once the data is received by the   server it is stored in the match data table. The unique match identifier is used to link the match data table with the matches table. The matches table is where information about such as the opponent, date and team is stored, where as the match data table just has the metrics and scores.

Below are images that will give you and idea of the table structures:

Screen Shot 2015-03-19 at 19.59.38 Screen Shot 2015-03-19 at 19.59.33

Considerable Progress

We made a considerable amount of progress in the last week.

I have a basic admin dashboard up and running. I used a bootstrap template that I found here to get thing off the ground. This template includes a really flexible javascript graphing library morris.js.

There was a little bit of work involved in learning how it worked but I found the documentation to be very comprehensive and easy to follow.

Below are two images from the past match analytics view in the dashboard:

Screen Shot 2015-03-19 at 19.50.49

Screen Shot 2015-03-19 at 19.51.03

We also got the first bit of communication between the server side and the android app working. The user is now able to log into the app with their email and password that they created during registration.

On the android app we used http post to send the email and password to a php script which checks the email and a md5 hash of the password against the information in the database.

We’re aware that this isn’t necessarily the most secure way to handle login and we will work on a more secure way if time permits.

Met With Supervisor

We met with Mark again.  This time we had a basic prototype to show him. Conor had the basic functionality of the android app working. Which had counters for each player on the field and buttons to switch between metrics.

I was able to show him the login / registration system and we discussed my provisional plans for the dashboard once users had logged in.
Discussed adding more functionality with a focus on providing the user with a logged in mode and and scaled down not logged in mode.
Set up a meeting for the following week.

Progress with Server Side

While working on our communications module (CA360) we made some good progress with the app. While Conor worked on the XML file which outlined the layout I got to work on the log in / registration system.

I found a html template log in form that I was able to customise to our needs using bootstrap. The user is only presented with two initial options these are to either login or to register.

Screen Shot 2015-03-19 at 19.29.34


When designing the registration system I wanted to verify that the email users were signing up with was valid. In order to do this I implemented a simple check. When the user registers the form data is stored in a temp_users table in the database. Along with the form data a unique (md5 hash) value is associated with the user. An email is sent to the user with a link that contains this unique value. When the user clicks on the link a php script will take the data out of the temporary users table and store it in the users table, thus completing registration and verifying the email is in use.