Beautiful Pixel

Aviary has been some cool stuff lately. Recently they offered up an API that allows external images to be edited, and pushed back to the server they came from. I thought that it would be awesome if Fleximage made this easy, so here you go.

It’s fairly simple and only involves three lines of code added to your app, and I think it’s pretty badass. I’ve created a page all about how to take advantage of this new feature in the github wiki.

Aviary Phoenix integration guide

Thanks Apple!

I’ve spent the past 6 months working on an iPhone game. In January I released a lite version of the game, to be followed by the full game a bit later on. Then I update the Lite version to fix bugs and add a feature or two. No problems, no rejections.

Lite version: http://void.beautifulpixel.com/app_store/lite

So I finally finish full game 1.0 and submit to Apple. I’m thinking it should pass approval fine since the Lite version was approved without an issue and the full game is just like the Lite version except bigger.

This morning I get my rejection email. The issue they cite is improper use of a built in control that goes against the HIG (Human Interface Guidelines). That specific thing has some validity, and that is not what I am about to complain about. The problem here is that my app got rejected based on an unchanged feature that was once approved. Timelines, sale dates, and review line ups, they all now need to be pushed back, mostly because Apple didn’t do a thorough enough job the first time.

I don’t think it’s fair to developers for Apple to reject an update based on an issue that exists is previously approved builds of that application. This is actually the second time this has happened. I have a free social app for a small community that had an update rejected because it did not have a graceful failure if there was no internet connection. But this was update 1.4, and that part of the app had not changed since 1.0 launch.

My point, Apple, if you insist on enforcing this level quality control over your apps, then you really need to be thorough and consistent. As an iPhone developer, it just feels like I am trying to hit a moving target. Except it takes a week for my arrow to get from my bow to where I think the target might have been a week ago.

App store submissions are like a box of chocolates: You never know what you’re gonna get.

In the past, Fleximage has been constrained to rendering uploaded images from uploaded sources. Resize, crop, apply effects, and send out to the client. Well what if you want to render an image, but the model data you want to render is not really image based? Introducing Fleximage::Blank.

Lets say you have a Comment model. A Comment belongs_to a User. For whatever reason, you need an image that represents any comment. This image might looks like this:

A template like this might create this image:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# app/views/comments/show.png.flexi
Fleximage::Blank.new('400x150')).operate do |image|
  # Start with a chat bubble image as the background
  image.image_overlay('public/images/comment_bubble.png')

  # Assuming that the user model acts_as_fleximage, this will draw the users image.
  image.image_overlay(@comment.user.file_path,
    :size => '50x50',
    :alignment => :top_left,
    :offset => '10x10'
  )

  # Add the author name text
  image.text(@comment.author,
    :alignment => :top_left,
    :offset => '10x10',
    :color => 'black',
    :font_size => 24,
    :shadow => {
      :blur => 1,
      :opacity => 0.5,
    }
  )

  # Add the comment body text
  image.text(@comment.body, 
    :alignment => :top_left,
    :offset => '10x90',
    :color => color(128, 128, 128),
    :font_size => 14
  )
end

Note that the Comment does not need a call to acts_as_fleximage. The Comment model itself has no image data in itself, but now it has an easy way to create an image based view of itself.

Checkout the wiki entry on GitHub for more info.

This is turning out to be one hell of a vacation.

Coming soon to an iPhone near you…

I created my first iPhone application recently. It’s been an interesting road.

It’s a small app for browsing the chat threads of a specific community, Shacknews.com, which is a gaming news site with a following of interesting people that like to play games.

Memory management, and cryptic stack traces continue to be the biggest issues for me in this whole Objective-C venture. That, and the app store approval process is incredibly frustrating. Updates seem to be taking AT LEAST a week to be approved, which really sucks when you need to fix a critical bug. And recently, I got denied because a new feature in the update didn’t work. Turns out, this was because of a temporary failure in the website that feature connects to that happened to coincide with when they were doing the testing. That was all fixed pretty quickly, but my app is still rejected, and I imagine it will take at least a week for them to respond to my email.

Come on Apple, I know you can do better than this.

iTunes App Store Link

Next up, I’m gonna try to learn some OpenGL and see if I can muster some cool game or something.

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.