Where the hacky things are- NYC BigApps

I signed up attend the NYC BigApps Hackathon with the honest intention of not writing a single line of code. I was there to represent RecordSetter as an API provider, and I figured I’d take a back seat, live tweet/blog the event and take some photos (I brought my SLR and everything!). Things didn’t really work out that way.

I was already restless by the end of Friday evening- CartoDB’s Javier Torre and I had sat in with the team that would become NYC Hood to hear their ideas and watch them trash out a weekend plan on their whiteboard. I didn’t like being on the outside- I thought back to the other hackathon events I’ve attendedand how enjoyable the whole process is. The initial process of throwing ideas against the wall and seeing what sticks. Working out what you’re even going to be able to achieve by the end of the event. The inevitable crunch on Sunday afternoon when you realise you were wrong about how much you could achieve. The exhilaration of finally showing off your creation to your peers. But anyway; I wasn’t doing a hack.

The API presentations came and went on Saturday morning. I exchanged hellos with NY City’s Andrew Nickle and I mentioned my frustration at not being one of the hackers we were watching. “Well, you could always submit a hack as long as you don’t use your own API”. Hmm. I had some time to kill, so I started browsing through the datasets available and toyed around with a few ideas. Before I knew it I had half of an app.

That half an app became NYC Taxi Tracker. It’s a mobile app that tracks your taxi ride and allows you to rate your driver. It then compares the route you took with the route a route planner chooses- the idea being that the app can aggregate which drivers are taking their customers the long way to earn more cash. I got some invaluable feedback in the presentation Q&A (including a brief discussion with Carole Post about how that info could be provided back to the city), and I’m proud to say that it won both third prize, and a Hacker’s Choice award.

It was a great event- my thanks go out to everyone involved in organising it. Especially whoever was in charge of the amazing (and never-ending) food and drink we had over the weekend. There were some other fantastic hacks put together- the aforementioned NYC Hood team turned in a site that parses your Foursquare history and recommends your perfect neighbourhood. An FDNY employee (how great is that?) presented a system for better fire inspections. First prize (and our shared Hacker’s Choice award) went to Eric Rafaloff for his awesome concept “Can I Park Here?”. He also kept a live blog throughout the event.

The BigApps hackathon was just the start of the BigApps program. The main competition ends in January and has some phenomenal prizes, including induction into the TechStars program to launch your app as a full-blown business. I have the skeleton of an app and some early stage idea validation- it seems stupid for me to not participate. But I haven’t planned anything- I still need to work out exactly what the final app will do, how it’ll work and what it’ll look like. Having been inspired by Eric’s live blogging, I’m going to try to keep an account of this process as I go through it, and hopefully I’ll have something to show for it by January.

Also, a new name. “NYC Taxi Tracker” doesn’t really cut it, does it?

Better base64 uri detection with Modernizr

A few weeks ago I was pointed in the direction of the Modernizr project. It’s great- you can detect what next-generation HTML5 features a user’s browser is capable of, and adapt your JS+CSS accordingly.

But it was missing a test. For a file uploader I’m working on right now (more about that in the future) I need to be able to know if a browser is capable of taking a Base 64 encoded string as an image source. Firefox can. Chrome can. Opera can. Internet Explorer can… version 8 and upwards. Oh, and version 8 can only handle images of 32KB or less.

There is a script in the Modernizr github source that detects base 64 data URI ability, but it doesn’t check for file size. The easiest way to do that would be to embed a 32KB string in the JS file, but no. That would be awful (though gzipping would probably do wonders). I set about finding another way.

My first thought was to make a pattern that was repeatable within the base 64 string, so that we could re-assemble it in JS. I created a tiny PNG file, and added a text chunk using PNGCrush… but turns out that the text chunks can only be 2048 characters long. I tried adding a description using XMP but I struggled to find any kind of application that would allow me to embed 32KB of ‘aaaaaaaa’.

Then I realised that it could be lot simpler than I was making it- just add a ton of line breaks to the base 64 string. It works a treat- IE8 errors, IE9 and the rest pass:


(function(){

  var datauri = new Image();


  datauri.onerror = function() {
      Modernizr.addTest('datauri', function () { return false; });
  };  
  datauri.onload = function() {
      Modernizr.addTest('datauri', function () { return (datauri.width == 1 && datauri.height == 1); });
  };


  var base64str = "R0lGODlhAQABAIAAAAAAAP///ywAAAAAAQABAAACAUwAOw=="

  while (base64str.length < 33000) {
    base64str = "\r\n" + base64str;
  }

  datauri.src= "data:image/gif;base64," + base64str;

  

})();

Ta-da! Works a charm.

webpy on Google App Engine- making that template problem a little easier to deal with

So, Google App Engine fascinates me a bit- shove some code on there, and let Google worry about the scaling, the CDN, the data storage… it’s tempting. So I figured I’d take it for a test drive. While looking around for a framework, I discovered webpy. It’s simple, lightweight, fast… it does everything I need.

But, disaster. It turns out that GAE has disabled certain Python libraries for security reasons- including one that webpy uses to compile templates. So you can’t actually look at any pages. Woops. Luckily, the guys at webpy have an answer- precompile the views every time you change them. Sure, it works. But… urgh. Every time I save the file? There has to be a better way. 

Luckily there is- on OS X at least (I’m sure every other OS has something similar, but this is my story, damnit). The lifesaving tool is launchd- it allows you to monitor the file system for changes, and execute code accordingly. All you need to do is save the following as ~/Library/LaunchAgents/com.webpy.templateupdate:

<?xml version=”1.0” encoding=”UTF-8”?>

<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>

<plist version=”1.0”>

<dict>

<key>KeepAlive</key>

<false/>

<key>Label</key>

<string>com.webpy.templateupdate</string>

<key>OnDemand</key>

<true/>

<key>Program</key>

<string>/usr/bin/python</string>

<key>ProgramArguments</key>

<array>

<string>/usr/bin/python</string>

<string>/<path to site>/web/template.py</string>

<string>—compile</string>

<string>/<path to site>/templates</string>

</array>

<key>QueueDirectories</key>

<array/>

<key>WatchPaths</key>

<array>

<string>/<path to site>/templates</string>

</array>

</dict>

</plist>

Then execute the following in Terminal:

launchctl load ~/Library/LaunchAgents/com.webpy.templateupdate.plist

At this point you might need to log out and log back in again, but once you do you’ve got instant recompilation whenever you make a change. Score.

Top