I’ve been working on an iPhone application for the community of Shacknews.com. It’s an app that allows access to the comments areas that are attached to the news stories. Simple enough, but I ran into the problem in that the site had no API.

I started to examine the tools I had in the iPhone frameworks to parse html content. It quickly became a chore. Hpricot has spoiled me. So I did what any Rails developer would do: I wrote a small Rails webservice to scrape the HTML, and return organized semantic XML. This stuff was much easier to parse on the iPhone.

I told the community of my progress on the iPhone app, and they were excited. As a minor aside, I also informed them that the API was open for whatever anyone else wanted to do with it.

This is when something magical happened. I didn’t think much would come from the API, other than me being able to use it for the iPhone app. But almost overnight, there were a multiple projects being cooked up by some tech savvy members. Very quickly they began to release their work. Suddenly it felt like a mini renaissance as the community interaction began to spread like a virus into new domains. Suddenly, you can post from the beach with ease, or report the score of a sports game to your buddies from your seat in the bleachers. Or you can post from work via a command line terminal that doesn’t look like your wasting time posting about video games as your boss walks by.

When you have an API, you give the community a way to improve your offering for you. And the best thing is, people do it for FREE, because they want to. You can pay some developer to make an iPhone app for you, or you can have an API and let someone else decide to do it for free. Overall, community participation is up, because people can do it easier, and in more situations. As a result, you get more traffic, and more importantly, more user activity in your site.

There are lots of smart people out there. Give them the chance to make cool stuff for you, and if they are passionate about your site, they will. And you will reap the benefits.

After a week or so of the API being available, this is list of ways you can now participate in the community beyond a computer based web browser.

(List compiled by a community member)

LatestChatty.app

• Best UI and features

• iPhone only

LatestChatty Command Line App

For Windows 3.11 and later, a command line interface. This is probably the most impressive, to be honest.

• 36K!
• Work safe!

• Code will probably make your head hurt when he releases it
• Probably not going to display images any time soon

LatestChatty for Windows Mobile

Why does the iPhone get to have all the mobile fun?

• Makes Windows Mobile slightly less embarrassing to own

• Fairly feature light at this point – color-coding of tagged posts would be nice
• Navigation is not the best

2 mobile optimized web apps for mobile browsers

Why does the iPhone get to have all the mobile fun?

• Nothing to install
• Works broadly on small screen sizes

• Less powerful UI and features than a native mobile app.

I’m still trying to learn Objective-C and Cocoa here, and coming from Ruby, its an interesting experience.

Method calling Syntax

I simultaneously love and hate the method calling syntax. Take this for example:

[UIColor colorWithRed:1.0 green:1.0 blue:1.0];

This create an instance of the UIColor class with red green and blue values as specified, in this case white. I do like that the parameters are labeled, and I like that better than simply passing in a list of anonymous argument that most languages give you.

But what I don’t like is the method name being forced to mingle with the arguments. Semantically, red, green, and blue are all equal things. However I am forced to prepend the declaration of the red value with this colorWith prefix. The named parameters actually are the method name. According to the langauge internals, the name of this method is:

colorWithRed:green:blue:

Here’s how I might do the same thing in ruby:

UIColor.new(1.0, 1.0, 1.0)

Although, this requires some formal knowledge that the order of arguments is red, then green, then blue. But I can easily remember this since its a basic language feature.

Usually I don’t mind long method names, but when handling things as simple as initialization, it seems like I should have to look up the syntax. Long ruby method names aren’t too much of a problem, because they only have one part. Objective-C methods tend to be more verbose, and its hard to know where the arguments go and what type the arguments are supposed to be.

The result is that I can’t possibly imagine writing Objective-C without a code completing IDE. I have written huge amounts of ruby in Textmate, and really don’t miss code completion much. Maybe I just have to get used to the IDE mindset.

Objects and non-Objects

Ruby has spoiled me. Everything is an object in ruby. A string, a number, a chunk of code, everything. Even a class is an instance of the class Class.

In Objective-C the story is different. An object is an instance of a class that inherits from the NSObject class. Basically this means that the only things that are objects are things that are provided by Cocoa. Other things that are provided by the underlying C, like floats, strings and whatnot are not objects. Although, to be fair, Cocoa provides object based wrappers for most of the C non object primitives, but its not always worth the overhead to use them for simple stuff.

This makes the syntax a bit of a mess. The bracket method calling syntax only works on objects, because a non object (I dont even know what to call it) cant have methods at all. And then you have calls to C functions like:

UIGetCurrentGraphicsContext()

Which doesn’t even use the bracket syntax at all. I’m sure I will get used to all this, but I can’t help but feel this language would be a lot more fun if everything was an object. I think most people go from something like C to ruby, but I am going the other way around, and it’s odd. We’ll see where this goes.

I got to deploy a new build to TheWineSpies.com this weekend, which among many other things, upgraded the app to rails 2.1. This process had me refactoring the admin to be RESTfull-er, and incorporating the latest version of Fleximage. I thought everything was dandy.

The Problem

My client was doing some testing on this code with IE7, their browser of choice. But something odd was happening. They would click a link triggering a resources show action, and instead of a html page about that resource, they would just get the image. At first I was stumped. I never thought cross browser issues could change server behavior. Firefox got a page of HTML and IE7 got an image. And I confirmed that the server was actually sending different content to the different browsers. The truly bizarre part, was that after clicking a link to this page, you could refresh and get the content you were expecting.

What the hell?

The Code

The Wine Spies uses Fleximage enahnced models across a few different resources, but here is a simple action that was causing me grief.

1
2
3
4
5
6
7
8
9
10

def show
  @product = Product.find(params[:id])
  
  respond_to do |format|
    format.html
    format.jpg  { render :template => '/some/path/small.flexi' }
    format.xml  { render :xml => @product.to_xml }
  end
end

This is pretty straightforward.

• If html is requested, render the default template
• If jpg is requested, render some .flexi template
• If xml is requested, dump the object to xml and send it out

But still, IE7 on a url of /products/123 would trigger the jpg format renderer. Somehow rails was thinking that IE7 wanted a jpeg image instead of HTML. Where other browser were making rails think they want HTML unless overridden by a format extension on the url.

Tracking down the cause

I began to think back to the DHH keynote “World of Resources” and some of the early stuff that was forming around rails, and luckily, I remembered something important. I tend to use this format pattern a lot, and I usually trigger it by url extensions like /products/123.jpg or /products/123.xml. But rails looks at something else too.

Your browser, or any HTTP client, sends along a header named HTTP_ACCEPT with any request. I decided to add some debug code to my action to see what was in this header:

raise request.headers['HTTP_ACCEPT']

In Firefox 3, the result was (minor edit for simplicity):

text/html,application/xhtml+xml,application/xml,*/*

This is a comma separated list of MIME types. The purpose of this header is to let to receiver know what kind of data the client wants, or what it will “accept”. It’s a prioritized list where the first items are wanted more then the items at the end of the list. Firefox is saying “Please give me html. If you don’t have that give me xhtml. But I guess xml would be ok too if that’s all you got. You got none of those? Well give me whatever you got then, I don’t care.”

Ok what does IE7 send?

image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/ag-plugin, */*

Until I refreshed the page, instead of clicking a link to this page, and got:

*/*

What the hell?

IE7 doesn’t say it wants HTML at all! It says it would rather have a gif, bitmap, jpg, flash, or even a plugin, rather than any other MIME type, including html. Rails gets this header, and sees that is no explicit format on the URL, so it goes down the list:

1. Does this action respond to the image/gif format? nope.
2. How about the image/x-bitmap format? no.
3. Maybe the image/jpeg format? Oh look at that yes it does!

The item that would have matched the html renderer */* is too far down the list, and we don’t get to it before a suitable responder is found.

Since IE7 sends a different HTTP_ACCEPT of */* on a refresh, it is declaring it has no preferred format at all. Rails then renders the default: html.

The Solution

After trying many ways to capture the damn header, override it somehow, shoving some Mime::Type object into request.format, and other failed solutions, here is what I finally ended up with:

1
2
3
4
5
6
7

#application.rb

before_filter :set_default_format
def set_default_format
  params[:format] ||= 'html'
end

This basically tells rails to ignore the HTTP_ACCEPT header. If a format is not explicitly declared on the URL, then force it to be HTML. It’s as if every html page on the site has a .html appended to the URL.

And finally salvation from that circle of hell.

Conclusions

What makes a good HTTP_ACCEPT header? I think Firefox has it right. Being a web browser, its main job is to display HTML, with embedded media. So it should want HTML more than anything since the images are just there in support of the html (mostly anyway).

IE7 makes 2 mistakes:

1. It sends different headers depending on how the page was loaded
2. It states that is prefers images over HTML

HTTP headers are a powerful tool. They can make interfacing with web applications and API’s much cleaner. But as we depend on them increasingly, we need have a level of trust with the clients that people use to connect. IE7 said it wanted one thing, and I forced to create a hack in order to tell IE7 “No, you don’t really want that. You really want something else.” And that makes me sad.

I thought clients who don’t know what they want are pain, but now browsers have the same problem. IE7 is a huge improvement over IE6, however it obviously still has its issues for web developers. The simple fact is that both versions of this browser have cost me way too much time, and that means it cost me money. The number of hours I have spent troubleshooting issues like this, as well as CSS and javascript issues, is way more than I want to admit to.

And that makes cranky. So tell your parents, “Save a web developer. Switch to Firefox.” Then maybe the world will be a better place.

I have just commited a documentation patch to Rails which adds instructions on how to use ActiveResource::HttpMock to test your ActiveResource models. But the really cool thing is how easy it was to do.

If you ever have been frustrated because something wasnt documented clearly, or documented at all in the case of ActiveResource::HttpMock, I really encourage you to fix up that part of the rails documentation and commit a patch. The steps are simple:

1. Read the docrails conventions wiki page
2. Send lifo:”http://github.com/lifo” a message asking for commit access to the docrails project on GitHub. You may want to include a brief description of what you intend to fix, just so he knows your cool.
3. git clone the docrails project, and write some documentation.
4. rake rdoc and review that the new documentation looks great when converted to HTML.
5. git commit and git push, and you are now a rails contributor!

A useful tool in this endeavor was rstakeout. It’s a script by Geoffrey Grossenbach that allows to run a command everytime a set of watched files changed. You can use it to run tests, compile HAML or SASS outside of rails, or generate the documentation when you save.

Copy this script to somewhere in your PATH and make sure its executable. Remove the .rb extension so it can be called like any other command line program. Now when working on the documentation:

1. cd into the rails component you are writing documentation for.
2. rstakeout "rake rdoc" lib/**/* This will watch all files in all directories directly under lib for changes. This is a typical glob format and you can use as many globs as you like if you want it to watch lots of files.

Now everytime you switch over the your browser, the newly generated docs will be up to date and waiting for you to preview them after a simple refresh. Sure does save you some time.

Over the past few years I have known Test Driven Development was the way to go, but my execution of that has been far from consistent.

Sometimes I think my project is too small to worry about it. But projects always get bigger than you think they will. A small bit of code with no tests isn’t really a big deal. But there is a certain project complexity threshold, where you can no longer keep the entire codebase in your head, when tests become an absolute necessity. As large bits of code become connected in an increasing number of ways, you need tests to ensure that unexpected things don’t break. And writing tests first ensure allows you to focus on just what your implementing without getting lost in the large and complicated guts of your app. The trouble is that when you start a project you don’t always know if it will reach that threshold.

Sometimes I think that I can just write tests later. After following this pattern many times, I can assure you, it is at least twice as slow as writing tests first, and your test coverage is far worse. The problem is that you have to root through your code and figure out what to test and how to test it. Coverage suffers because you are sure to miss branches of code, partly because you simply missed them, and partly because you are tired of writing tests. It just feels tedious to tread on through, writing code hours that adds no functionality to your application. It’s not fun.

Writing the tests first does a few things to make life easier:

1. Write a small test, write a bit of code, is a cycle that remains fresh and fun because you are not stuck writing only tests for hours on end.
2. Only writing code if you have a failing test keeps you focused. Its easy to get side tracked, fixing this and that, introducing more code changes before you are done with the current task. Focusing on smaller goals helps you code faster because there are less variables to think about all at once.
3. Implement features with almost no manual testing. With a tool like autotest its easy to add features or fix bugs without ever leaving your code editor. When all tests pass, you know you did it. One cursory manual test to confirm, is a lot faster than manually testing the features everytime you make a minor code change.
4. There is something very satisfying about seeing that “0 failures, 0 errors” after 45 minutes of hacking. It’s a carrot, and you just want to keep chasing it. When you get it, you just write another carrot to chase. It’s an addictive cycle.
5. The ruby community will like you more. All the cool kids do it.

None of this is novel or new for those who practice this. It’s simply my own journey to the TDD religion. To be honest I am just really tired of writing tests after a large body of code has been written. It’s a painful and tedious process.

• Checkout this is awesome presentation from RailsEnvy.com’s Greg Polluck

@blog_post.gsub!(/test/, "spec")

RSpec, test/unit, test/spec, in the end I don’t think it matters. Use the test suite that is the most comfortable for you. The fact that you practice TDD is far more important than the tool you use to do it. So use the tool that makes you want to do it.

I’m not going back to my lazy old ways, I’ve finally learned my lesson.

When you write your plugins the right way, Rails just works in nice ways for you. madrobby (a.k.a. Thomas Fuchs, as made famous by script.aculo.us javascript awesomeness), provided a useful tip in the Fleximage wiki on GitHub.

If you have some quick and small templates for a simple resize operation, you can do a render :inline in order to create a template on the fly for quick and easy rendering of a small template. Try this in your controller:

1
2
3
4

def thumb
  @photo = Photo.find(params[:id])
  render :inline => "@photo.operate {|p| p.resize '100x100'}", :type => :flexi
end

I have never used an inline template before, but I can definitely see how that could be handy. Although, to be honest, I feel like this is very much view logic and would like to see this in a view file in all but the absolute simplest cases.

Thanks for the tip Thomas!

Thanks to some loud complaining from the community (including myself), GitHub will soon support OpenID.

Awesome.

If you’re thinking about whether or not to support OpenID in your new Rails app, consider this tweet from DHH

Around 30K accounts on 37s apps are using OpenID. That’s a nice chunk!

Even if that just a few percent of the whole, 30K is a huge amount of users. And if these people are like me, OpenID support makes me much more likely to create an account somewhere. If a see a site that looks kinda cool, but I need to login to start using it, and it has a 5-10 field registration form, I usually skip it. Now if I see the same site with OpenID support, I simply enter OpenID and bypass the extended registration fields making me far more likely to signup and try it out.

If you want a chunk of that 30K, maybe you should add OpenID to your authentication as well.

While I’m on the subject, 37 signals does a cool thing if you log into their apps with OpenID. I currently have account at 3 different basecamps. I have my own basecamp, a basecamp for my primary day job, and a basecamp with another project I am helping out on. Since I login with OpenID on all three, they give me a little drop down near the top that lets me switch between basecamps. Remember that basecamp account are unique per basecamp instance. So the only way it can link my account together like that is to use my OpenID.

• Why can’t you provide this by looking for the same username? Well, since your account is specific to a basecamp instance, you can’t always have the same username in multiple basecamps.
• Why can’t you use an email, that’s globally unique right? Indeed, but I use more than 1 email address. While each email is unique, I dont have just one that means “me”. Plus in order to verify the email you have to do a messy email validation step, that noone likes doing.
• OpenID is globally unique no matter what. People usually have just one that they use. And verification is done by an identity broker rather than an email.

It all adds up to a big frickin’ win to me. This has bigger implications for me, though. What if you logged into a site, and simply by creating an account it could go out and get publicly available information about you and mash it up. Say, your favorite bands from Last.FM, the latest comments on your blog, your most recent twitter tweet. And it would be able to do all this with zero configuration because the OpenID you used on this site is the same that you used on other sites. Single Sign On is a big deal, but this is the real reason OpenID is awesome to me.

The past web was founded on the principal of anonymity, but the future of the web is grounded in absolute identity.

According to AgileWebDevelopment.com Fleximage is in the first 15 “top rated” rails plugins on their site. Currently it sits at 5/5 with 71 votes. Not bad at all!

If you use it, and like it, go give it a thumbs up.

So I know you guys are out there. If you are using the plugin on a production site, go ahead and add yourself to the Who uses Fleximage Wiki page over on Github. I would love to see what you creative have done with dynamic images.

There was a minor annoyance with all version of Fleximage up to this point. If you upload an image to a model, and validation fails for whatever reason, then you would have to find the image on your disk again, re-upload the image again, before you resubmit the form. Wouldn’t it be nice of the file stayed uploaded, even if the record isnt ready to be saved yet? How about getting a preview of the uploaded image too?

It’s all possible with the latest version of Fleximage up on GitHub. Checkout this GitHub wiki page for details.

Since GitHub makes open source so easy I opened up my old Settings plugin after almost a year and put it up with a few improvements.

Most importantly, I got the tests working. I also created a less ugly way of defining defaults:

1
2
3
4
5
6

Settings.defaults[:foo] = 'bar'
# or
Settings.defaults = {
  :foo => 'bar',
  :baz => 'faz',
}.with_indifferent_access

Check out the updated version of GitHub

I usually don’t blog about stuff that everyone else is obviously blogging about already. But I am making an exception, just this once, because I am excited about GitHub.

GitHub is a social source control platform based on Git. Git is a whole different animal than SVN. Git has no concept of source and checked out copy. You can commit locally, you can easily branch and merge, you can push some branches to some central repos, and keep other to yourself for now, its amazingly dynamic. But I’m not here to talk about Git so much.

The first part that makes GitHub cool is the social thing. It’s been really hard for me to get into social networks. I try every once and a while and find it hard to convince my peers to join me on said network. I can upload a widget, or have a friends list, but I never seem to find any functionality that keeps me using the network for any length of time. GitHub is finally a social network I can get into. You don’t have “friends”, you have contibutors, watchers and forkers. You can add people to your project as contributors, people can simply keep an eye on your project by watching it, or they can fork your code to make their own modifications in their own sandbox. It’s completely addicting to see how many “Watchers” I have today. As of this writing the Fleximage watcher page lists 9 watchers. Not bad for less than 1 week in the wild.

Now, lets say someone wants to add some useful functionality to Fleximage. They can fork my code, without my permission, and work on their useful feature. They then let me know saying “I did some cool stuff, check it out”. I can clone their working repo, test it out, and integrate the diff with my code with just a few commands. Even if someone forks my code in order to overlay a monkey watermark on every image, that’s still fine. They can keep their forked little sandbox for themselves or whoever else wants to use it and I never have to pull in their changes at all.

The second part that is awesome is what this does for open source. The pricing model really encourages open source. Open source hosting is free. Private repositories cost money. Let that sink in a minute. This means that its easier and cheaper to release your project open source than not to. Previously, to open source a project you needed server side repository hosting, need a website for your project, in order to get those free you needed the convoluted rubyforge interface or ad laden source forge. This made it more time consuming and costly than a private codebase. So the “default” mode for most apps was private, because it was easier.

What GitHub did, was to make open source easier and cheaper than closed source. So going forward my apps will be, by default, open source. Thats a big deal. Now the little nuggets that I write every now and again will be opensourced on GitHub. Some of them may turn out to be nothing. But other may get forked by someone far smarter than me, enhanced, and eventually turned into something totally cool. Such scenarios never would be possible if there wasn’t an easy and free open source hosting platform like GitHub.

GitHub, you guys rock. The worldwide open source community has been greatly enhanced by the presence of GitHub. Give it some time and I think GitHub will be the defacto open source standard.

Hey look, I’m a Ruby expert

Not sure how I stack up with people that wrote Ruby books… Had I realized that I was going to be quoted in such a manner, perhaps I would have answered with slightly more verbosity. Live and learn.

You ever make something, and then look back a few years later and say “What the hell was I thinking”? This happened to me recently. Fleximage has been quite a useful plugin for me, but under the hood it was a mess; the API was cumbersome, and mixing in all the image transformations as direct model methods was code smell.

This release represents the 3rd complete rewrite of this code base. The first effort was SuperImage. It worked, but it happened almost entirely in the controller and made more interesting effects harder. The first Fleximage was next introducing more tranformations and .flexi views and a good effort to making it more MVC friendly.

Get Fleximage v2 here

So I now present, Fleximage v2. The output is very similar, but the API and internals are completely different. Here’s some highlights.

• Creation date based master image storage to prevent OS imposed directory limits. i.e. /path/to/images/2008/02/06/999.jpg
• Rails 2 formatted resource route friendly
• Magic columns to capture filename and image size
• Image transformation methods are not injected into your model or controller at all.
• Image operations now happen via Operator class that refactor each transformation into their own encapsulated class.
• Easily output JPG, PNG, or GIF based on request format.
• Simple acts_as_* style model activation rather than using a cumbersome inheritance method
• Side by side file upload or URL fields for easy uploading.
• Uploading will only ever replace you image file if the uploaded file actually has content, removing the need for “if file.size > 0” nonsense in your controller.
• Rake tasks to convert from master image directory styles, as well as master image formats (jpg => png for instance)

And it’s all hosted on GitHib. It’s new, it’s awesome, and has extensive documentation in the attached Wiki.

Lastly, if you are using Fleximage in an existing production site, please add it on the WhoUsesFleximage page. I know you’re out there.

A friend asked me to donate a tiny google maps application to a non-profit cause. The Hillcrest Development Watch monitor housing and construction in their area and they wanted an easier way to do it than emailing a spreadsheet around. Now, being a Rails programmer, of course I wanted to deal with this in Rails. Sadly Rails is a pain to host right?

Wrong. Enter Heroku. Their fantastic setup is free (for now). They create a git repository for your app when you create your app. Then you simply suck down that git, commit to it and push it back. Their server software automatically updates your working code and reboots your app to the latest code, simply by pushing your commits to the server. It is the least painful rails deployment process I have ever used. In fact, I would go so far as to call it pleasurable, which is a big deal to say about rails deployment.

Check out Hillcrest Development Watch

The site itself is a simple single resource web app. It tracks properties, their addresses and development states. For a supre small app like this, Heroku even provides access to its user login system. It lets you use the user logged into heroku.com as a user in your app. So if your needs are simple, you can have a user authentication system, and have your app not care about registration, authentication, or user management. This app simply show some admin function if the user is authorized to edit this heroku app. This wouldn’t stand up to the needs of anything more complex, but it saved a huge bundle of time for this project.

In case this lengthy prose didn’t convey my point:

Heroku is Aweome!