So Why Do We Need Microformats?
Thats the question I used to get frequently while exploring and adding extra mark-up to some clients pages. The idea that the web is only useful to humans, and not machines, is dead. Mozilla Ubiquity is only showing you a brief look into the future, of how are kids will be surfing the web of data with ease…
Ubiquity for Firefox from Aza Raskin on Vimeo.
So should we start planting those seeds now or what?
The HTTP Pattern
I just got finished reading an article over at Ajaxian (great blog) about The Ajax Head Pattern; Unobtrusive Rails App. And had a few comments of my own.
While working at Kinetic, especially on our home brew stuff, I’ve made it a point to engineer our applications using what I call “The HTTP Pattern”.
Sound silly? It is meant to be, because HTTP serves us all we need for a great majority of the problem solving we do for our client’s systems.
Unobtrusive Javascript, Graceful Degrading, the separation of Presentation, Behavior and Structure, Microformats… all are just the basis of the W3C’s web.
Yet they serve us a model for keeping things simple and layering on additional tweaks and user interface enhancements. While giving us an architectural “golden path” to compliance for varying user agents.
That’s why I’ve adopted so much of their nuances into the systems I architect.
”...and what about Rails?”
REST with Rails (and more so Merb) takes us back down to HTTP, and allows us to utilize the loving goodness we have all veered away from (as an industry). REST has given us a wonderful platform to base our problem solving skills on top of. By utilizing the HTTP protocol, W3C standards and a bag full of common web usage gained from user experiences.
“Give us some examples”
Want to update your clients on various responses to requests they are sending? Of course we should be using “HEAD” and our HTTP status codes.
Want to persist a products hidden boolean value in the database when your clients click a check box? Of course we should degrade that back to a simple web form for users without XHR.
How about re-calculating a shopping cart in the navigation bar when a user chooses to purchase something? Request cart data as JSON from your back-end server and update your cart views on the return solely on the client-side (DON’T send view partial back to the client, ick!). If not present a simple web form and POST this data back.
All of these things are cheap, because thats the way they should work.
“Its always the simplest things”
Thinking simpler is what all of these patterns are based off of. Its the right time to be thinking about how you can utilize the web properly, before we add yet another layer on top of it.
Attributr background style
I love incremental improvement.
New in Attributr—you can now choose the background style for your attribution overlay. The original black/white on transparent is still there but I’ve added white on black and black on white options for photos where that is more appropriate.
There are several more ideas I want to flesh out such as:
- Returning other sizes besides the default Flickr Medium.
- Being able to position the attribution in someplace other than the bottom right.
- Choosing different font styles. For some reason, the Coolvetica font I’m using looks a lot jankier when rendered on the servers than when it’s rendered from my local copy running on OS X.
- Providing a list of more comprehensive attribution of all the photos you request so that a “credits” page can be pasted into your presentation, website, blog, whatever.
A "Squash" WorkFlow in Git 2
By using Git, our workflows and environments are becoming much cleaner, there’s no denying that. I just wanted to post a quick note on how “squashing”, and more specifically interactive Git rebase, can extend that as well.
If your using Git you can squash tiny commits into a “lump sum” commit. This way you have the benefit of smaller commits while releasing only the real meat of changes your working on.
Its a tad dangerous messing with rebase, since it rewrites history, so try to learn how to do it on a separate test branch.
Personally, I’m trying to work this into my workflow by switching back to my master branch, merging down tiny changes from the other “working” branch, squashing them together, then pushing up (or others pulling down) or switching back to continue working/create a new branch for new functionality… whatever….
Plenty of people have blogged about this, so I’m not going to demonstrate how to do it, but here’s a link for learning more about it…
git awsome-ness [git rebase—interactive]
As usual, check the Git rebase manual page for more info…
My first Sinatra app
While playing with Sinatra a bunch as part of the prep for my Philly on Rails talk, I came up with a few ideas for microapps that I thought would be perfect for Sinatra.
The first of these I call Attributr. It’s a very simple app that accepts the URL of a Flickr photo and returns that photo with proper attribution overlayed in the lower right corner. I often use photos from Flickr that are Creative Commons licensed. And I’ve often thought it would be handy to get the image with attribution right from Flickr so it’s ready to just drag into my presentation or whatever.
I used GraphicsMagick to add the text. In the past, I’ve used ImageMagick for such things, but I heard GM was easier to get installed. Indeed, it was pretty simple. On Ubuntu, it’s as easy as apt-get.
This is running on our newest production server under Passenger. I couldn’t believe how easy Rack and Passenger together make deploying tiny apps like this a breeze.
I’d love some feedback on Attributr if you ever have occasion to use it.
