Android Wear Hackathon


Well a great weekend just passed with our team coming first place at the GDG – Boston Android Wear Hackathon!

The event kicked off on Friday evening with people presenting ideas and forming teams. Our team brainstormed some ideas and pulled in one of the google guys to throw some of them against him. We ended up with the decision to go with something to do with gestures, and we wanted the gestures to control our laptops. We decided to aim to have an application controlling our presentation!

By the end of the night we had the watch reporting the accelerometers and gyroscope coordinates and we had figured out a method to pass the events from the watch to the mac.

Saturday comes along and we kick off with a team breakfast at The Friendly Toast, got to love those Green Eggs and Ham! Plans and more coding happens until the Google offices opened at 9:30am.

Peter and I worked on the watch and figuring out the gestures, and what values to trigger each gesture on. We incorporated voice control – you say “presentation” to kick off your Power Point, “video” kicked off the video player etc. Dermot worked on a listener to detect the events and the corresponding scripts on the laptop to pass the instructions on!

We got everything done and thankfully we were one of the first to present – all developers present voted on everyone else.

So up we go and present away, people are really into the presentation and then we wrap it up. We got an immediate question about our demo of the app and it went down really well that people hadn’t even realized we were controlling the presentation with the app!

We designed the app to recognize gestures in two separate stages. When the first gesture  is recognized, when the accelerometer’s coordinates pass a predefined threshold, the watch vibrates to alert the presenter that a gesture has started.

At this point the gesture must be completed within 1 second for the action to fire. If the presenter completes the gesture the watch vibrates again, otherwise the presenter can resume with any other gesture safe that they would not inadvertently change the slide.

We looked into other applications that could be integrated – pausing and playing videos, raising and lowering volume etc. We need to look into pairing the watch directly to the pc/laptop rather than having it pass the logs to the machine. Lots of possibilities!

Turned out there were some pretty serious prizes also!


  • Samsung Galaxy Note 4 (giant phone!)
  • Samsung Galaxy Gear S (smart watch)
  • Samsung Gear VR (Virtual Reality Headset!)


Looking forward to getting hands on the VR headset and cranking out some more apps!

Git Watch – Use Cases – Part 2

Continuing on from part 1,  where I began to discuss the aim of Git Watch and developed the user persona, now I need to dig into those four user stories to define use cases. From these I’ll generate requirements.

Git Watch


  Event Name   Input
 User subscribes to GitHub repo.
  • Use provides GitHub repo
 Change to the GitHub repo.
  • Author commits change to repo
  • Issue opened
  • Pull requests
  • Comments
 Phone is prompted to update.
  • GSM notification

Each event is a separate use case, with each use case breaking down into one or more processes.


Business Use Case 1

 Business Event Name  User subscribes to GitHub repo
 Business Use Case Name  User adds GitHub repo
 Trigger  User provides GitHub repo URL
 Preconditions  None
 Interested Stakeholders  None
 Active Stakeholders  User, GitHub


1. Check if GitHub repo already subscribed by another user
A1.1 Validate the GitHub repo exists
EA1.1 GItHub repo is not valid
EA1.1 Alert user that the GitHub repo url is invalid
A1.2. Watch the GitHub repo
2. Add the repo to the user’s subscription list
3. Tell the user the repo has been added


A GitHub repo is being watched and the repo is part of the user’s subscription.

Git Watch – UX – Part 1

Well with an upcoming Google Wearable Hackathon, best build a few apps in advance!

An important part of a hackathon is having a team and breaking up the work for individuals to work on. This means you need to keep on top of checkins and be ready to modify code to integrate with the latest changes.

So the first app I am tackling will aim to do that – notify the user of checkins to a repo.


Developer Persona

Name: Tom Collins

Gender: Male

Age: 26

Education Level: BSc

Tag Line: “Come on you boys in Green!”


Domain Knowledge

Tom has been used source control for his programs ever since he was introduced to it in college for projects. In college and on his personal time we would be the only contributor to his SCM repo. He understands the basic terminology and commands. Within work he has learnt the basics of needing to checkin frequently and update to get work his team have checked in.

Pet Peeve

Tom hates it when you checkin code that breaks the build!

Other People Say

“Tom is eager to learn, so you can throw a problem at him and see if he sinks or swims.”

Personal Essay

Tom graduated with a degree in computer science from BU and went on to get hired by a local startup company, TBone. Tom’s work was initially overseen by the lead developer, Chris. Chris would sit Tom down on a Monday and go over what was required for the week. They would discuss some potential solutions at a high level so that Chris was happy Tom was going down the right path. After that Chris would checkin with Tom for a brief status check at the start of each day, otherwise it was up to Tom to seek out Chris if guidance was needed.

Tom found the challenge fun and enjoyed the responsibility of having so much left up to himself. He would code up his fix, validate the build on his machine before checking it in to the repository and monitoring the build. Other members of the team would leave comments on Tom’s code that he prioritized to resolve. Initially Tom only read other people’s code that was checked in, and as his experience of the environment grew he also began to comment.

Finally Tom moved on from TBone to IM Central, a larger company with a more formal development environment.Tom was part of a specific team that managed server configuration. A lot of time was spent developing and testing scripts that other teams would interact with when deployed to the servers. Changes to the scripts would be rolled out across the company’s server farm, so testing was a high priority.

User Stories

Merg Business!

If someone has checked in a file I’m working on, let me know so that I’m not caught with a massive merge conflict to resolve later when I go to checkin.

Warn me of a new checkin!

I’ve been waiting on a colleague to check in their code change for the last hour. I don’t want to keep pinging them to find out why they still haven’t checked it in and are holding me up!

Whos checking in?

With two junior developers that I have to oversee, I need to be on the ball when they make a checkin to catch any issue first.

Big change.. little change…

I’m not that bothered about checkin’s unless there is a huge change.


With Android Wear, there are two parts – the smart watch and the phone it is synced to. So the plan is to separate these out, quick bits of information will be displayed on the watch and more information and configuration on the phone!

Phone App


Might as well integrate with Google+ rather than having to deal with managing a login process.

GitWatch - Phone App - LoginActivity


Main Screen

Let the user see the latest changes for any repo that they are following. They have the ability to add another repo and change any app setting from here also.

GitWatch - Phone App - MainActivity


Repo Info

Given a commit, we want to provide as much info as possible about it. They can also delete the repo from here.To get even more information, the user can open the change log from GitHub with the default browser on the phone.

GitWatch - Phone App - ChangeActivity


Add Repo

The basic information required to add a repo! What aspects of the repo do they want to track etc.

GitWatch - Phone App - AddActivity

Smart Watch


Alert the user to a checkin of a repo that they are following. Lets give them basic info to see if they even care so we tell them who (committed the change), what (repo), and when.

GitWatch - Watch App - NotificationActivity



Still with the watch, the user wants a bit more information before deciding if they want to take any action.

GitWatch - Watch App - CommitActivity


Finally, if the user wants more information, lets not have them go to the phone app to identify the change and pull up the change log – just launch the browser and send them to the change log from the watch.

GitWatch - Watch App - DisplayActivity

Autonomous Cars

Autonomous cars are a combination of highly advanced sensors and an operating system designed to handle a large level of data input, the ability to fully process it, and execute the correct actions to be taken. The combination of these technologies is broken into five categories of autonomy as defined by the NHTSA. These run from L0, where the driver has complete control over the car, up to L4, a fully self driving car that requires no driver input.

When manufacturers developed cruise control, a system that monitors and automatically adjusts the throttle position, they had achieved a level of L1 autonomy. With the introduction of Lane Keeping technology, utilizing radar systems to detect lane markings and applying a counter-steering force when crossed, the simultaneous use of both of these technologies raises the level to L2 autonomy.

A number of manufacturers are currently working on implementing L3 autonomous cars, which involves the car maintaining all safety-critical functions requiring limited driver intervention. This requires a system to control and adjust the throttle and the steering shaft based on analyzing the environment while utilizing a location and mapping service to arrive at a destination.

Overlapping sensors are required to capture all the environment data. Sensors need to detect environment changes up to 250 or more meters away and with finer detail at fewer than 80 meters.  Different technologies are being assessed and each manufacturer is using a combination of very accurate LiDAR systems, multiple ultrasound radars, lasers, and cameras.  Each sensor system has a specific range of tasks that they excel at, from processing camera images to detect traffic signs to LiDAR systems generating a 3D environment.

All this data requires a powerful computer to process it. NVIDIA has announced their Tegra K1 processor will be used in Audi’s autonomous car, a 192-core GPU similar to processors used in super computers. Each manufacturer is also utilizing different operating systems customized for autonomous driving (see chart below).

Autonomous cars are predicted to reduce 90% of traffic accidents, improve fuel efficiency, reduce pollution, and provide mobility to non-drivers. Enterprises that currently provide transportation and related services must be prepared to pivot, i.e. taxies services, freight trucks, and delivery services. Other enterprises must be prepared to take advantage of utilizing fully automated transportation services and the technology that comprises them.

Future infrastructure must be carefully planned out to prevent it becoming obsolete and incompatible with new traffic systems. Car designs will be changing as drivers no longer are required to maintain vigilance on road, allowing the creation of mobile office spaces. Consumer hardware and software should begin investigating designs now to position themselves to become a technology leader within the developing space.

Manufacture Model Software Provider OS
Mercedes-Benz S 500 Nokia Xubuntu
Toyota Prius Google Ubuntu
Renault Next Two Google Android
Nissan Leaf Microsoft Windows Embedded Automotive
Company Role Contact
BMW Project Manager Dr. Werner Huber
Google Google Fellow Sebastian Thrun
Audi Project Manager Dr. Bjorn Giesler
General Motors Innovation Program Manager Jeremy Salinger