RemVee.blog

I’ve added some convenience methods to access GPS because people really seem to want it. Is should be fully backward compatible with earlier versions;

EXIFR::JPEG.new('enkhuizen.jpg').gps.latitude  # => 52.7197888888889
EXIFR::JPEG.new('enkhuizen.jpg').gps.longitude # => 5.28397777777778

Enjoy!

Just released EXIF Reader 1.0.6 Ruby gem. This is a bugfix release for issue 20. The TIFF decoder now reads as many frames as possible instead of throwing an exception when hitting a bad frame.

When streaming audio or video or serving largish files over HTTP you’ll eventually want to provide seeking resp. continue download capabilities to your application. I’ve cooked up some ring middleware to respond to partial content requests and mangle your application responses accordingly. It works well with the commonly used ring.middleware.file wrapper but do read the fine print.

Et voilá: ring-partial-content

I’ve always liked HTTP authentication (like basic and digest) over login pages because they look so.. technically savvy. Finally somebody who bothered to read an RFC to implement it and make me feel warm and welcome like peers do.

Okay, I must admit, it takes a customer just a couple of moments to request a logout button, which is a real pain to implement, if possible at all. And I wouldn’t want to login on something I care about from a public computer either. But it is very nice for web services!

Anyway here’s my implementation as ring middleware: ring-basic-authentication

Today I released version 1.0.2 of EXIF Reader to fix a Ruby 1.8.6 incompatibility. Thanks to Jasper Haggenburg, Patrick Crowley, Jeffrey Warren and Ian Leitch for finding, analyzing and fixing this problem.

After 4 years EXIF Reader finally reaches it’s first major-version-day. It has been pretty stable for a while now and the API didn’t change in any painful way since the first release.

So here it is: version 1.0.0.

  gem install exifr

Enjoy!

Thanks to Makoto Kishimoto, Mark Lundquist, Victor Bogado, Forian Munz and other people I forgot to record in the CHANGELOG for sending me patches and test images.

Ongeduldig heb ik met de Android emulator zitten spelen. M’n dev phone is onderweg en ik kan natuurlijk niet wachten tot ik ermee aan de slag kan.

Aardig aan het Android platform is dat het gebruik maakt van Java. Wat is jammer aan Android is dat het geen gebruik maakt van een JVM maar van de Dalvik VM. Klinkt rampzalig maar valt erg mee, Android blijkt een heel groot deel van het Java Standard Edition class libraries te implementeren. Dat stemt hoopvol en geeft het gevoel dat, in theorie, alle andere JVM talen (zoals Groovy, JRuby, Kawa en Clojure) ook te gebruiken zijn op z’n Android telefoon.

Natuurlijk is het allemaal maar theorie en in wat voor bizarre wereld zouden we leven als dat ook echt zou kunnen?! :) Toch maakte Per Bothner me nieuwsgierig met zijn AndroidHelloScheme post en ben ik aan de slag gegaan om ook een Clojure variant te maken.

Laatst werd me gevraagd wat mooier of beter is:

obj.getItem('Status')
obj.getItem('Status') == 'Completed'

of

obj.getStatus()
obj.isStatusCompleted()

Het laatste voorbeeld is beter omdat het minder foutgevoelig is; een tiepfoutje in het eerste geval kan heel lang blijven sluimeren terwijl in de tweede versie de foutmeldingen meteen om je oren vliegen. Daarbij vind ik de tweede variant ook beter leesbaar.

De degene die de vraag stelde, gaf me schoorvoetend gelijk. Maar zou dit niet betekenen dat hij deze methoden voor alle 10 statussen uit zou moeten schrijven en is dat dan niet ook weer foutgevoelig? Voorzichtig vroeg ik om welke taal het eigenlijk ging; “JavaScript”. Maar natuurlijk hoef je dat niet helemaal zelf uit te schrijven! JavaScript is, net als Ruby, Lisp en vele andere, een moderne taal en stelt je in staat te meta-programmeren, ofwel programma’s zichzelf te laten schrijven.

Dus geen gedonder met een preprocessor en/of rare annotaties meteen aan de slag met de programmeertaal waar je toch al mee bezig was!