has_many :thoughts

It’s not often I link to Microsoft but they have an insightful blog post over on the MIX Blog. Molly Holzschlag discusses the business benefits of Web Standards.

For several years, we’ve been pushing standards-compliant sites to our clients and we receive very little resistance. Many of our customers just roll with whatever recommendations we provide, especially for new sites.

But when clients have an existing site, and we try to sell them on converting it into nicely formatted, semantic XHTML and CSS, it can be a challenge. We’ve found it helpful to document clearly for them the additional cost they will incur by having our developers wade through crufty nested tables and horrendous cross-browser compatibility. When laid out in dollars and cents, the decision becomes easier.

I made this last night and early this morning in about an hour and a half:

http://radioplaying.com/

I’ve been listening to Philadelphia’s Radio 104.5 of late. And since I can never remember song titles, I thought it was nice that they have a page on their web site that lists the last 10 songs played. Unfortunately, it’s not very mobile-friendly. So when I’m stuck in traffic, and want to check what just played, I can use this little site.

All it does is scrape their site with Net/HTTP and Hpricot and outputs the results in an extremely bare-bones version.

Andy likes it, too, and wants to add more stations so who knows what will become of this little app. But, for now, it’s a handy tool I’ll use myself.

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…

So should we start planting those seeds now or what?

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.

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.

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…