Beautiful Pixel - Home

Timeless Reminders

2010-06-22T00:04:00Z

I haven’t posted in forever, but I have good news!

We just released an iPhone app side freelance project I have been poking for the last 9 months or so called Timeless Reminders

It allows you to create multimedia presentations of things that mean something to you, and then schedule that they be sent to yourself at scheduled times. It sounds odd, but it can be very powerful when you get a slideshow of your wife in the middle of the Wednesday afternoon doldrums at work. You should check it out. It’s FREE after all.

Fleximage News - gem, S3 and Heroku

2009-12-14T04:27:00Z

First of all, yes I am a douchebag for no posting anything in forever. Life has been busy, but I’m starting to recollect my voice, and we will see how it goes.

So, Fleximage! recently a few things have gone into the popular image plugin.

1. Ruby Gem

gem install fleximage

Currently just 1.0.0, but you no longer need to install fleximage as a plugin. It now works as a gem. Just install the gem and add a config.gem 'fleximage' to your app’s initialization and you have finer version control and an all around cleaner way to manage your fleximage installation.

2. Amazon S3

You can now use Amazon S3 as a store for your master images.

class Photo < ActiveRecord::Base
  acts_as_fleximage do
    s3_bucket 'mywebsite-com-user-uploads'
  end
end

# a new initializer
require 'aws/s3'
AWS::S3::Base.establish_connection!(
  :access_key_id     => 'my_s3_key_here',
  :secret_access_key => 'my_s3_secret_here'
)

Now new Photos will be uploaded to and read from your Amazon S3 account. This isn’t super fast, but with proper page caching it shouldn’t be a big problem. And there are some server configurations where file system storage is not possible, and database storage is impractical.

Which brings us to…

3. Heroku

The S3 support now allows fleximage to run on Heroku without database image storage. Use S3 for storing your images, and you are done!

What about cacheing? you ask. Well Heroku uses Cache-Control headers to auto cache your content. And fleximage will automatically render it’s images with a 24 hour cache header. So it should just work. Just note that it’s not simple to expire a cached image. So i usually construct my fleximage models so that the image on a particular model will never change. Meaning that if I want a new image, I probably just want to delete that model and upload a new image to a new one. or you can just wait a day for the new image to reappear.

I’ll be working on better solutions to Heroku caching when I can, but for now this should work well enough for most apps.

VOID update coming with new UI

2009-08-05T18:29:00Z

I don’t really know what I was think when I designed the flight UI for VOID. Someone once described it as “it likes a clown threw up on my iphone”. Awesome.

Well the good news is that there is an update coming out soon with something far less intrusive and much easier on the eyes. Stay tuned for that and more, soon.

Ruby Tricks you Probably knew but I didn't: Array#&

2009-07-31T23:23:00Z

I had to intersect 2 arrays today. Basically I had 2 arrays and wanted to only the objects that both arrays contain. Yeah, I could have done some select or reject loop, but I stumbled upon…

[:a, :b, :c, :d] & [:a, :c, :e]
#=> [:a, :c]

Who knew? I think I should really use operator overloading more often, and just so pleasing using an operator for an operation. Go figure.

Fleximage meets Aviary Phoenix

2009-05-01T23:18:00Z

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

What we're playing: The VOID

2009-04-02T17:26:00Z

Thanks Apple!

App store: Yes you could, but now you cant!

2009-03-14T16:58:00Z

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.

The VOID is imminently near

2009-03-12T05:48:00Z

Fleximage displays virtual images

2009-03-01T01:13:00Z

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:

# 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.

Costa Rica Zip Line

2009-01-26T04:30:00Z

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

VOID Teaser

2008-12-16T17:32:00Z

Coming soon to an iPhone near you…

First iPhone app

2008-09-09T16:44:00Z

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.

Why every community needs an API

2008-08-11T20:12:00Z

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

Pros:

Best UI and features

Cons:

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.

Pros:

36K!
Work safe!

Cons:

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?

Pros:

Makes Windows Mobile slightly less embarrassing to own

Cons:

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?

Pros:

Nothing to install
Works broadly on small screen sizes

Cons:

Less powerful UI and features than a native mobile app.

Objective-C Syntax

2008-07-21T02:23:00Z

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.

IE7 header issues

2008-07-20T19:36:00Z

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.


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:

Does this action respond to the image/gif format? nope.
How about the image/x-bitmap format? no.
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:


#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:

It sends different headers depending on how the page was loaded
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.