It’s been quite a while since #MakeOpenData took place, the event where trainshare transformed from being purely an idea to something more tangible.

Since @AdrianKuendig, @visualcontext, @koma5 and i weren’t able to deliver a running prototype until the end of the event, we continued working on the App as well as the API whenever we had some spare time. While it’s neither done nor available in the AppStore yet, we just wanted to give you a sneak peak of what’s to come.

As you can see, from the video above, there are still things need to be figured out or refined. While we might think of some ourselves, we always welcome your suggestions, so don’t hesitate.

Well that’s it for this time around, thanks to my trainshare team members, the awesome guys behind #MakeOpenData who made this event possible, journalists and bloggers who wrote articles like this, this and this. You rock!

For the april event of @JSZurich, @streunerlein and i had the honor of talking about socket.io and the new kid on the block, meteor. As you can see the slides and recordings are embedded below. Enjoy. As for the recordings, sorry it’s raw, MTS is not the friendliest format.

Socket.io

Abstract - It’s a Javascript wrapper library written for Node.js which makes the usage of websockets a lot easier. It also takes care of supporting older browsers with multiple fallbacks. By using socket.io, creating “realtime” applications is a matter of minutes.

Meteor

Abstract - Meteor is an opinionated toolset of common Node.js npm packets and some custom code. Among many things it enforces the use of Fibers, Socket.io and MongoDB both on the server aswell as on the client side.

Some explanation regarding what i said during the talk for those who weren’t present. I’m well aware that i did not sell Meteor as the next big project that everyone has to pick up. The reason is simply that it’s really early in it’s development process. Additionally i think it’s highly dangerous to sell Meteor as something for beginners, since it’s magic bits hide a huge amount of logic a beginner normally doesn’t need to use in order to build a hello world application. By embracing Meteor the novice programmer isn’t learning about those hidden areas which probably lead to unexpected results here and there. After all distributed systems are hard.

An example for such a use-case is the todos application which comes bundled with meteor. It’s nicely done and quite easy to understand, but what happens if let’s say 2 users, with a high latency connection to the server, update the same entry at about the same time? Your changes will be reflected immediately on your machine, with the syncing following a few seconds later, a few seconds later from there you’ll might be surprised that your original changes have been overwritten by the second user. With a traditional stack you’d do some locking or at least insert versioned entries, however with MongoDB this is not supported by default. You’d be able to implement versioning youself by using timestamps and inserts for every update but why the additional overhead?

Just to state it again, the words above do reflect my personal experience when playing with Meteor 2 weeks after it’s initial appearance in April 2012, i’m happy to give it another try once it’s some more mature.

As for the @JSZurich event, thanks to @ikr for hosting us and @seldaek for organizing it.

Sharing a train, something the swiss twitter community did for years via the hashtag #trainsharing should now be brought to the masses with a dedicated app.

My goal is to realize the backend as well as various mobile clients with the help of other hackers during the make.opendata.ch hackathon to show off what can be done by leveraging publicly accessible data. And just for the fun of jumping on the buzzword bandwagon, it’ll be SoLoMo (social-local-mobile) ;-).

What led to the idea

Day in and day out i’m commuting back and forth from where i live to Zürich. In order not to see those hours spent commuting as wasted time, you’ll have to spend it wisely which often times means doing some kind of work. As a programmer that’s cake ;-). However there are times you just want to talk to someone remotely familiar. You could obviously do some kind of creepy stalking and wait outside the train until the very last minute before departure to see if you see someone familiar. Chances are you’ll either find no one or they actually want/have to do work instead of chit-chat with you. So status quo sucks, right? Well could we improve it?

The idea

Obviously yes. Let’s create a mobile app that allows to checkin to a train and then find conversation-partner-matches via Twitter, Facebook and maybe even Foursquare.

The User Interface

When starting the app for the first time you’re using one of those buttons on the login screen to connect to your favourite network and start using the TrainsharingApp.

As a next window you’re seeing the home screen on which you can enter your commuting route. This will make a call to sbb.ch to get the timetable and save it locally for later reuse. If you’ve already used this route there’s a quick dial button to select your route and then select the departure time on the following view.

As soon as you’ve chosen a time, you’re automatically checked in to that train-route which will trigger a push notification to users on the same train or users which will share part of your route and with whom you are friends on one of the social networks offered at login. After sending those notifications to friends or receiving one you’re able to initiate a Meetup by selecting their name, selecting optional information and tipping the “Meetup” button.

The Technical Implementation

As for the backend, there exists an already scraped static dataset of train lines with their according numbers, eg. S8 18898 and each route (Station to Station, see below). All in all about 230’000 routes which will reside inside a MySQL DB. In case you want to play around with the dataset, here’s a routes table dump.

	id	linename	dep_station	dep_time	arr_station	arr_time
	1	S2725920	Waldshut	06:24	Koblenz	06:29
	2	S2725920	Koblenz	06:44	Klingnau	06:47

For matching friends there’ll be some kind of NoSQL DB instance since MySQL isn’t that good at it without creating a lot of table and row overhead. Still needs to be figured out, suggestions are welcome.

Additionally there’ll be a join table (routes_users, see below) for matching the routes with users. Since the routes_users table can fill up quite fast and past data doesn’t need to be held warm, it’ll be pushed to S3 for later analysis and then cleared every 24 hours.

	id	routes_id	users_id	start_time
	1	423	234412345	12:03
	2	5122	967512345	14:34

So much for the storage part, now over to the API. There will be three endpoints at least, /login, /checkin and /read.

/login will be used to send the social network authentication tokens over to the server to allow us to do the bandwith heavy parts. The request should be one of type POST with the credentials in it’s body. Which will give a trainsharingID back as a response. This trainsharingID will then be stored on the client device and used for every single request as a querystring.

	Key	Value
	network	facebook, twitter or foursquare
	token	network_token
	token_secret	network_token_secret

/checkin is, as the name suggests, the endpoint for when a user wants to check in to a train ride. For clarification, a train ride consists of multiple routes (Station-to-Station) and may also involve switching trains. Requests to /checkin should also be of type POST with the trainsharingID in the URL as follows /checkin?trainsharingID=your_trainsharing_id. As for the POST body, it’s the information getting delivered when clicking on the details section for the specific connection timetable on sbb.ch.

	Key	Value		Key	Value
	dep_st-1	Siebnen-Wangen		dep_st-2	Pfäffikon SZ
	dep_t-1	06:03		dep_t-2	06:19
	arr_st-1	Pfäffikon SZ		arr_st-2	Zürich HB
	arr_t-1	06:13		arr_t-2	06:48
	train_id-1	S2 18220		train_id-2	IR 1754

/read will be the only endpoint accessible via a GET request, though it still needs the trainsharingID in the querystring. /read is for manually asking if new overlaps have been found since checking in. The goal however should be that this endpoint is only used for development and new overlaps are sent to the user via PUSH notifications in a production setup.

Enough with the server stuff, what happens on the mobile? -Well, upon first launch of the app the user signs in with one of those social networks which will create an OAuth token and an OAuth token secret which will be sent to the /login endpoint mentioned above. The trainsharingID in the response then gets stored persistently in the application storage.

Next up is the home screen where the user can enter departure and arrival destination to look for available trains. This will trigger a POST request to sbb.ch from the phone, parsing the response and showing the available options to the user. If a user selects a specific time another GET request will be fired to fetch the details information for that connection whose response get’s parsed and sent to the /checkin endpoint.

If matches already exists the response to the /checkin POST request will contain users from various networks who are matching the friends criteria. In case none exist yet the response will be empty. In both cases the user will be notified via PUSH if additional matches are made later on.

Both a proper UI and API endpoints for the meetup functionality still need to be figured out. Maybe it even makes more sense to use their native networks eg. Facebook or Twitter for messaging instead of building yet another Whatsapp clone.

Well, that’s all there is to say about the TrainsharingApp at the moment. Have i missed something? Or do you have a specific suggestion what needs to be changed, added or removed?

In case you are interested in creating a native mobile client besides the one for WindowsPhone, which is already being covered by Adrian, let me know either via twitter or the comments below so I can get in touch with you. The same goes for designers too.

Go is new programming language and sort of a mixture of C, Python, Oberon and other languages. It’s trying to solve many problems where other languages are failing when deployed on enourmous scale, eg. like on Googles infrastructure.

Below are the recordings of last weeks joint event by the IT geeks Zurich and GTUG Zurich. At this event Luuk van Dijk a staff software engineer at Google who’s currently working on the Go compiler and Johan Euphrosine a Developer Programs Engineer working on App Engine gave some insights on how Go can be leveraged and what it does internally to do so.

Also many thanks to the organizer Muharem Hrnjadovic for making this second amazing IT geeks event possible.

And without further ado, enjoy the talks below and excuse the Pizza distribution dilemma we luckily had to deal with.

OpenData, BigData, Infographics, Visualizations and Data journalism are all buzz words and movements which started to get quite some traction lately.

While there are lively ecosystems of blogs around niche topics like visualizations, processing or data journalism there’s not enough interdisciplinary communication going on in my opinion.

Well, how about creating it by interviewing those experts, give them some airtime and maybe even connect previously unknown scientists, journalists, hackers, politicians and ideators to each other.

Since i’m still playing with the idea there’s nothing fixed just yet. Language might be english or german depending on who’s in front of the camera. Also if you’re interested in being a host or you’re having a name suggestion let me know.

Would you listen to or watch it?