Basically I wanted to give the attending journalists and politicians an overview of what it means to develop a project based on OpenData or for that matter OpenGovernmentData. That getting Data for free does not mean the service has to be free too.
For those who have not been able to attend, or just want to glance through the talk again, @AdrianKuendig (working on the Windows Phone App for @trainshare) was kind enough to record it.
Since @AdrianKuendig, @visualcontext, @koma5 and I were not 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 is neither done nor available in the AppStore yet, we just wanted to give you a sneak peak of what is 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 do not hesitate.
Well that is 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.
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.
Here is some explanation on what I said during the talk for those who were not present. I am 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 is really in its early stage of development. Additionally I think it is rather dangerous to sell Meteor as a framework for beginners, since its magic bits hide a huge amount of logic a beginner normally does not need to use in order to build a hello world application. By embracing Meteor the novice programmer does not learn anything about those hidden areas which probably lead to unexpected results here and there. After all distributed systems are hard to build.
An example for such a use-case is the todos application which comes bundled with meteor. It is nicely done and quite easy to understand, but what happens for instance if 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, and a few seconds later from there you might be surprised to see that your original changes have been written over by the second user. With a traditional stack you would do some locking or at least insert versioned entries, but with MongoDB this is not supported by default. You would be able to implement versioning yourself 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 its initial appearance in April 2012, and I will be happy to give it another try once it has somewhat matured.
As for the @JSZurich event, thanks to @ikr for hosting us and @seldaek for organizing it.