Generating and parsing data URI's in Ruby

I'm fond of data-URI's (MDN Link). 12 years ago I reappropriated a tool that stored a webpage with its related resources in a Microsoft specific format and rewrote it into something that would store it in normal HTML where the related resources were encoded in data URI's. Recently the topic came up again at a project I was working in, where microservices are still a thing. And while discussing it with colleagues it seemed as if knowledge about this quite useful URI-scheme wasn't on top of everyone else's mind. Instead, the original idea was, we could upload the resource to S3, pass the link, download the resource from S3 at the receiving end, and then have some policy that takes care of deleting it… nah…

data-URI: The basics

This is the most simple data-URI:

data:,Hello%2C%20World%21

You [can open it in your browser](dat…

How to REST?

Today I tried to explain REST (as in REpresentational State Transfer, not near sleep) to a manager and why some of the services deployed at the organization he was working for wasn't REST. While there isn't a formalized spec, there is a dissertation by the Roy Fielding, who came up with the REST-principles as a set of principles that guided him while shaping the HTTP 1.1 standard which only recently got a successor with version 2.0… REST is a set of principles/guidelines that are very stable & predictable. It is also very simple, and theirin lies both its strength, and the sometimes too loose application of its principles.

Apparently many developers didn't get 'the web' (HTTP) right, hence REST was developed as a basic set of principles to explain how HTTP is supposed to work. This is a list of my favourite parts, also based on some secondary resources.

Some key concepts.

REST is about …

PHP revisited

I've been able to stay away from PHP-based projects for quite some time. Until recently. I needed a small API. The idea was that the API would be transferred to a relatively old server that had been running stable for years and the client didn't want to risk installing additional script interpreters on it. It might even have been my own suggestion, it would be a really small API, requiring no special changes on an already operational 24x7 managed server. On top of it I'd write a modern style front-end, running entirely in the browser.

Of course the API that was intended to be simple got a bit more complex. I wanted the API to output clean JSON messages, which required some data mangling, as data was stored in CSV's, TSV's, and misused XML-files or only accessible through crappy soapy API's. So what does present-day (well, the Red Hat PHP version I was able to use is still in 5.x-series) PHP look like? TL;DR: sometimes it was definitely ugly, but at I can happily live with the cod…

Oktober 2010, denken over de toekomst

Mobile app development wordt steeds gemakkelijker met frameworks zoals Joapp, welke ik deze maand kon toevoegen aan het rijtje toe kon voegen als jQuery Mobile , jQTouch, PhoneGap en meer…  Hoe of wat mobile app development is iets dat bij The Bean Machine ondermeer onderdeel uit maakte van de discussie hoe we ons nu beter kunnen onderscheiden. Voordeel van deze frameworks is dat mobile apps in ieder geval niet beperkt worden tot slechts 1 platform, iets waar Jeffery Zelfman deze maand zeer terecht voor waarschuwde. Maar toch, mobile app development, misschien alweer een beetje laat?Misschien is een verstandige nieuwe weg om in te slaan te focussen op data management en aggregatie. Zie bijvoorbeeld hoe TripAdvisor een applicatie bouwde op basis van Facebook’s Cities I've Visited applicatie. In plaats van zelf steden aan te bevelen op basis van zelf verzamelde data wordt bij TripAdivsors Trip Friends gebruik gemaakt van een koppeling met Facebook. Apart toch eigenlijk, dat zel…