Hackathon 2: Deutsche Bahn


Event organization: C, Food: D-, Swag: F, Technical Ease of Use: D, Usefulness In The Real World: F

The Long Story

This is the retrospective on the Deutsche Bahn hackathon I attended in early May. It was also the first one I attended where the prizes were so tiny, and the goals so relatively preordained, as to be a complete waste of my time.

Here was the challenge: Deutsche Bahn would export a bunch of their operations data into CSV, SQlite, and other formats. Participants would take that data and attempt to utilize it in some way to help Deutsche Bahn’s bottom line. The winner would receive a “prize” of being allowed to present / pitch the results of their hack to people at Deutsche Bahn. Wow. You don’t say? In this case, the benefits accrued only to Deutsche Bahn. There were no real intermediate prizes, no smart watches, or doodads of little intrinsic value but plenty of hype value. This was not a hackathon where the benefits of spending 24 hours hacking on someone’s code or API would lead to some better outcome for the participant, not even indirectly.

Continue reading Hackathon 2: Deutsche Bahn


If ever there was a good reason for physical, spinning hard disks to die, it would be this:

Continue reading iowait

Raspberry Pi Notes

Serial Port Setup

Edit inittab to not comment out the console getty:

#Spawn a getty on Raspberry Pi serial line
T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

And edit /boot/cmdline to have:


instead of


WiFi Setup

sudo vi /etc/wpa_supplicant/wpa_supplicant.conf


    ssid="wifi identifier"
    psk="wifi password"


sudo ifdown wlan0
sudo ifup wlan0

Analog to Digital Conversion

Wait, WTF? The Raspberry Pi has digital GPIO, but no Analog A/D on board? Boo on that. I guess it’s back to the Edison, for which I have an A/D converter on the Arduino shield.

Android Wear Tests

So there’s a hackathon going on over the next 48 hours, revolving around wearable tech and how it can be used to further certain corporate goals. I’m poking around with an Android Wear device, the Moto 360, to see how it stacks up. There’s currently someone sitting across the room from me futzing with a Google Glass headset (looks kind of stupid).

A few first impressions:

  • The device itself is pretty slow.
  • The initial pairing can fail frustratingly, because Android seems to have problems when you don’t reboot after turning Bluetooth on, even on a Nexus phone. Also, if you accidentally pair the watch using the normal Bluetooth device selector, then the Google Wear app will fail to pair with it, and fail to realize that you’ve already paired.
  • There’s a weird Bluetooth wireless debugging mode, that still requires you to plug your phone into a USB port then Bluetooth pair the Wear device to the phone.
  • The edit, compile, debug cycle is incredibly slow; pressing run in Android Studio leads to a delay time of up to a minute or more waiting for the app to make it to the watch (so the only way to really do this is using an accelerated virtual device, on x86).
  • Android Studio has gotten a lot better since the betas I tried. (The fun part is when you hear someone sitting across the room at the hackathon complaining about how much it crashes, as if he would like to return to the world of Eclipse? Reminds me of Louie CK’s rant about everything being awesome and nobody being happy.
  • Initial Gradle builds are still really slow, though. It’s totally killing my processor.


  • The Salesforce Android SDK is not published to Maven Central, instead being distributed using npm (the Node package manager) and/or needs to be built from github sources. This makes zero sense. The SDK should be a versioned, precompiled, signed binary JAR file checked into Maven, and easily importable into any sensible Java IDE.
  • I’m noticing myself checking my wrist a lot more. When washing the dishes, the notification was forwarded to the watch, which was actually kind of convenient, I must say.

Continue reading Android Wear Tests