Geofencing Blog For App Developers

Plot visits Xebicon 2013

Last Tuesday the 4th of June on a beautiful summer day, the Plot development team visited Xebicon 2013. We really wanted to visit New York - ScalaDays being there - but since that wasn't in the budget we went for the next best thing: Groenekan - that's near Utrecht folks!


Plot at Xebicon 2013 Plot at Xebicon 2013

On arrival everything turned out to be neatly organised by Xebia, who hosted this event for the second time. Name tags and writing gear were made available to us and there was an Agile clinic where experts, dressed up as medical doctors, offered advise on this popular software development methodology. Since there were many talks in parallel we split the team up, commando style, to get the most out of our visit.

Keynote by Marc Sluszny

First up was the keynote talk by Marc Sluszny. An individual that I had frankly never heard of before but apparently did some pretty neat stuff during the course of his life. His presentation started with a superhero style compilation video of all the adventures he had embarked on, including but not limited to speedboats, sharks, airplanes, skydiving and helicopters. Since he was a professional tennis player from a young age he was been formed by the competitive culture and attributed that to him having been so focussed on winning that the only time he could enjoy his victory was when he could shake his opponent's hand after having won the finals. Having come to the conclusion that he really didn't like what he was doing anymore he decided to quit professional tennis.

Putting to practice his motto - "It's not how good you are. It's how good you want to be" - he embarked on one adventure after another, starting with swimming across the English Channel, and ranging from Skydiving to coaching the Belgian Bobsled team, reminiscent of Cool Runnings. He also talked about coming to grips with his fear of his parachute not opening when skydiving, even after more than 50 jumps under his belt.

Apparently his next big project is going to be to dive to the bottom of the "Blue Hole" in the Bahamas, which is - with its 202 metres (663 ft) - the deepest of its kind with entrance below sea level. He noted the need of different oxygen mixtures as well as long decompression times amongst the biggest challenges of this endeavor.

Being asked what he wouldn't do, he named passing up an opportunity to row across the Atlantic with a single partner so don't even bother to ask him. However, since he named the prospect of being cooped up with a single human being as the main reason for declining, you might still ask him if you are planning to row a cruise ship.

All in all the speech was well delivered and fun to listen to. Too bad that the sound suffered from intermittent failure due to connectivity issues and there was no wired fallback microphone.

Clean code in Android apps by Barend Garvelink and Ronald Warners

These two guys gave an in depth presentation on the experience they gained writing the new ING mobile app for the Android platform. The talk turned out to be more narrowly scoped than the title suggests. Their main focus was UI development and working around its shortcomings on Android.

The first problem they identified was type safety when using Intents which are really key/value pairs. They explained that the best way to handle this was to create a static factory method for an Intent on the receiving Activity. This is arguably more safe than using plain strings and a more concise solution than defining the key as a static string definition.

After this they jumped into a more complex problem: clean separation of concerns between Adapters (controllers in MVC speak) and Views. They worked us through a naive implementation with the View leaking into the Adapter and way too many dependencies to the ViewHolder pattern advised by Google, which reduces the number of dependencies but does little to separate the View from the Adapter. The final example they themselves came up with cleanly separates the two and - although it is more complex - boasts a much cleaner dependency graph. They assembled a nifty little GitHub project to fully illustrate this on three branches. Fork it while it lasts!

During this subject a hint was dropped that the poorly documented Spannable and Spanned interfaces are great ways to deal with scaling text in Android TextView components.

Lastly they covered reusability of UI fragments in layouts for multiple screensizes making clever use of dimensions and styles. Unfortunately this isn't covered in the GitHub project as the examples they gave would have given some much needed guidance to an Android UI rookie like me.

Great tale from the trenches with nicely applicable techniques. Too bad we don't do Android UI.

Is Java 8 a Scala killer by Urs Peters

This was a talk I went to for the inverse reasons it was probably meant for. Most of the audience were doing Java in their day job while I am doing Scala. Nonetheless, since I knew next to nothing about the allegedly upcoming Java 8 release I was hoping to learn more about it.

To be honest, Urs's love for Scala was leaking from the seams in this talk. I guess the chosen avatars on the opening slide for Java and Scala being PacMan and Superman respectively said it all. This is not to say that he hadn't done his homework. He presented a clear and factual comparison between the two even though his personal preference was clear from the get go.

Instead of repeating his presentation I will give you an article he co-authored that scores top points on Google searches for "java 8 vs scala" anyways.

One thing I found very interesting was that he second guessed Oracle's decision to use virtual extension methods vs. Scalas implicit conversions which come at no runtime performance cost at all and would solve the same compatibility issues adding monadic constructs.

A few questions I had that weren't covered in both languages I have attempted to answer myself:

Multiline lambda expressions

According to JSR-335 part B, block lambda bodies as opposed to single statement bodies are enclosed by curly brackets. This is identical to Scala. The difference is that in Java only single statement bodies are allowed to omit the return statement where in Scala this is also allowed in multi statement bodies as per usual.

The big difference lies in the interpretation of the return statement. In Java the return statement is scoped to the lambda expression. Omitting it is just a shortcut in single statement bodies. In Scala a return statement has a different meaning and is scoped to the first non anonymous function surrounding said return statement. This is an arguably less functional design dicision than the guys at Oracle made! But it can be very useful if you are willing to embrace the mixed functional/imperative paradigm. Let's look at an example:

def test: List[Int] = {
  val initial = List(1, 2, 3) { (int: Int) =>
    if (int == 2) return List(99) // Always triggered so result is List(99)
    else int * 99

As you can see the return statement matches the type of the function and as you can guess it will evaluate the first two elements of the List but always return a List containing the single element 99 to the outer function due to the presense of an integer value of 2. Java would interpret this return statement as any other and have it scoped to the lambda function causing a compilation error due to returning a List<Int> where an Int would be expected.

The following example illustrates what would happen when the return statement is never hit - note the list definition not containing 2:

def test: List[Int] = {
  val initial = List(1, 3, 4) { (int: Int) =>
    if (int == 2) return List(99) // Never triggered so result is List(99, 297, 396)
    else int * 99

Large-scale single-page web application development experiences by Freek Wielstra and Vincent Lussenburg

If this talk can be blamed for anything it's its long title and the fact that only half of it was about single-page web apps. Not to say that it was a bad talk - I gained various insights into things I think will enrich my professional life - but honestly the first part of the talk was about the project at large and a summary of the back-end product usage decisions made to get it to work.

This presentation can be summarised as a true show and tell. The latter part about front end development dealt with the design decisions that were taken. Little comparison was made to alternative techniques other than JQuery in this part of the talk. The base line was that the following worked for them creating a RIA:

  • Backbone.js
  • JsHint
  • Jasmine
  • HandleBars on top of Mustache

That's not to say these were bad choices - obviously they managed to create a web application with it that they were willing to talk about if not demonstrate - but it showed very little depth.

Final keynote by Dan North

This is where the fun began! Dan North, who hails from London, reminded me, in his presentation style, of Stephen Merchant's voice over for Wheatley in the last installement of the Portal game by Valve Corporation, but without the constant whingeing.

His presentation style was brilliant and very entertaining by instead of being this serious drilled self-conscious keynote speaker he had all these little outbursts that made him funny as well as a fellow human being. In his endeavor to connect to developers in their own domain, as he told me himself after the talk, he succeeded admirably. Not so much by the clever analogues but mainly by his tone of voice and metre.

What stuck as especially inspiring was his talk about the division between formal and informal structures within companies and the need for automation to take these valuable informal structures into account instead of crippling them. The main informal structures are architectural - you talk to someone in accounting directly instead of asking your boss for permission to call her - as well as routinely - "Dave, I know I am late but could you please approve this purchase today?".

Modelling these types of interactions is an obvious challenge and, shunning megalomanic solutions, Dan is a proponent of delivering narrow domain tools to the whole workforce. Since I can't come up with any sane concrete examples of that and the thought of supplying an assortment of Python scripts cross company fills my belly with dread I'll have to ask him about his intentions on that one later!

Thanks for reading and hope to see you back here soon!


Subscribe to Email Updates