Intridea - Company Blog

Hashie: The Hash Toolkit

2009-11-12T09:13:00-05:00

One of my earliest gems was Mash, a useful tool for creating mocking objects as a Hash. One of the most common problems people had with Mash was a simple one: it conflicted with another class of the same name in extlib! To address this problem as well as give the project some room to grow, Mash is now part of a new toolkit called Hashie. Hashie is available now via Gemcutter and the source, as always, is available on GitHub. To install:

gem install hashie

Hello, Hashie

Hashie is, right now, simply the former Mash code along with a new extended Hash called a Dash. A Dash is a “discrete hash” that has pre-defined properties. It can be used as a dead-simple data object when even something like DataMapper is too heavy, but a Struct is too light (Dash gives you the ability to set per-property defaults as well as initialize from an attributes Hash). For example:

class Person < Hashie::Dash
  property :name
  property :email
  property :occupation, :default => 'Rubyist'
end

p = Person.new
p.name # => nil
p.occupation # => 'Rubyist'
p.email = 'abc@def.com'
p.email # => 'abc@def.com'
p['awesome'] # => NoMethodError

p = Person.new(:name => "Awesome Guy")
p.name # => "Awesome Guy" 
p.occupation # => "Rubyist"

The other advantage Hashie has over Mash is that it’s built from the ground up to avoid conflicts. Instead of adding stringify_keys methods to the Hash class, it’s instead added to a Hashie::Hash subclass. You can, however, get Hashie’s few Hash extensions in the Hash class by including the HashExtensions:

Hash.send :include, Hashie::HashExtensions

Hopefully the move will make it easier for everyone to use it in their projects without fear of running into conflicts, and hopefully you’ll also find the Dash useful. Over time the functionality of Hashie may grow to encompass additional simple and useful extensions of Hash. So install Hashie, your friendly neighborhood Hash toolkit, today!

Car Finder Becomes a Hit Application for iPhone

2009-11-11T16:02:00-05:00

We released Car Finder just over a week ago and the amount of attention we’ve received is much more than we could have ever anticipated. For those of you who don’t know, Car Finder is an iPhone application that utilizes augmented reality to help you find where you parked your car.

Note: Car Finder developer Brendan Lim and his brother (with the dollar) sold separately

Throughout this whole process we’ve noticed that the Twitter mentions that came after these news articles proved to play a huge part in Car Finder’s success. Below are a list of a few articles that covered the release of Car Finder.

Wired UK
Save face with the Car Finder augmented reality app

The Unofficial Apple Weblog
Use Augmented Reality to Find Your Car

Autoblog
Latest auto iPhone app: Augmented reality parked car finder

Holy Kaw!
Can’t find your car? There’s an app for that. – Holy Kaw!

Cult of Mac
Car Finder iPhone App Uses Augmented Reality To Find Your Wheels

Boing Boing
Car Finder app for iPhone

Car Finder is available now on the App Store for $0.99. Intridea offers services for application development on all major mobile platforms, which include iPhone, Android, BlackBerry, and Palm webOS. If you need help with your mobile application feel free to contact us for a quote.

Quick Tip: Readable Conditional Validations in Rails

2009-11-03T08:57:00-05:00

This is something that many may already use as a best practice, but if not it’s something simple and convenient to add to your repertoire. Sometimes you may have a model that requires additional information if a certain condition is met. For example, I may require a user to add more information about themselves if they wish to be listed publicly, whereas I would not if they do not wish to be listed. By combining ActiveSupport’s Object#with_options and ActiveRecord’s conditional validations, we can implement this behavior in a straightforward and readable manner (assuming here that there is a boolean field called “listed” in the database that is exposed as a checkbox or similar to the user):

class User < ActiveRecord::Base
  # Our standard validations
  validates_presence_of :login
  validates_uniqueness_of :login

  # Validations for listed users
  with_options :if => :listed? do |l|
    l.validates_presence_of :email
    l.validates_length_of :description, :minimum => 100
  end
end

It’s a simple technique that piggybacks off of Rails’s automatic construction of existence query methods (in this case, listed?) for fields in the database combined with the mapping power of with_options and standard conditional validations.

Use Augmented Reality to Find Your Vehicle With Car Finder for iPhone

2009-11-02T16:47:00-05:00

If you’ve ever parked your vehicle in a large parking lot you’ve realized that it would be great to have something help you memorize where your car was. Intridea’s latest iPhone application, Car Finder, helps you do just that. Unlike the cookie-cutter car finding applications in the App Store, Car Finder helps you find your car using augmented reality.

Using the camera, A-GPS and the compass built into the iPhone 3GS, Car Finder allows you to find your car by positioning an overlay on top of a live view of what’s in front of you. Also, when you mark your car Car Finder allows you to set a note for your parking spot. This is particularly useful if you know what section you’re parked in or if the GPS is spotty in the location that your car is currently parked in.

Presently Adds SharePoint Integration

2009-10-29T17:47:00-04:00

We’re always looking for ways to make it easier to integrate Presently into your day-to-day workflow. Today, we’re happy to announce something that will make it much easier for businesses using Microsoft’s SharePoint to integrate Presently. Starting today businesses can use the Presently SharePoint Web Part.

The Presently Web Part will allow you to view and post updates to your company’s Presently account from directly inside your Microsoft SharePoint portal. For more information on the installation and usage of the Web Part, you can visit the SharePoint application page.

We have also released the source code to the web part, it’s available on GitHub. Please feel free to contact support with any additional questions.

Find Great Sushi Anywhere with SushiMe on iPhone

2009-10-29T13:58:00-04:00

Adding to Intridea’s collection of great food finding applications for the iPhone, like iPho and iCurry, comes SushiMe. SushiMe allows you to find great sushi restaurants around you using your current location or any location that you specify. You can sort through a list of restaurants by their rating (provided by Yelp) or by their distance. With SushiMe you can also view a map of all of the restaurants around you and even call them directly from your iPhone to make reservations.

SushiMe is a free application and is available right now in the App Store. Intridea offers services for application development on all major mobile platforms, which include iPhone, Android, BlackBerry, and Palm webOS. If you need help with your mobile application feel free to contact us for a quote.

Present.ly Updates iPhone App With Camera and Attachment Integration

2009-10-08T12:02:00-04:00

Present.ly, our enterprise microblogging platform, which is used daily by many large corporations and government organizations, offers native versions of the application on all major mobile platforms. Today, Apple has approved the latest version of Present.ly for iPhone.

Included in this latest version is an updated user interface. The new user interface ditches the previous dark theme and replaces it with a look that is more familiar to iPhone users and is easier on the eyes. Uploaded attachments can be viewed directly from the phone. Updates with one or more attached files are indicated by a small paperclip icon within your feed.

In addition to attaching files, photos from your photo library or the iPhone camera can be added to your updates—a highly anticipated feature. This version of the app provides a more robust user experience by enabling many of the most useful features of the web client. Present.ly is a free application available in the App Store. To get Present.ly for your iPhone click on the link below.

Intridea Kicks off Mobile Development Services With Two Free iPhone Apps for Foodies

2009-10-01T17:41:00-04:00

Sometimes you just want an application that gets something done quick and gets it done right -- especially if your stomach's calling. That's why we've decided to create iPho and iCurry for the iPhone.

iPho will help you find the best phở around you using your current location or any address you use using the built-in search. iCurry does the same but allows you to search through the best Indian food around.

Both of these applications will show you a list of restaurants sorted by their average rating or their distance relative to you or the address you search from. You can also drill down into each restaurant so that you can get their address, get directions, give them a call, and even see if they are open. There's even a map view which overlays all of the restaurants around you. Ratings and listings are provided using the Yelp API. Both iCurry and iPho are free applications and are available now on the App Store.

Along with the announcement of these two great applications, we at Intridea are kicking off our mobile development services for our clients. We are offering services for application development on all major mobile platforms, which include iPhone, Android, BlackBerry, and Palm webOS. We've built a great team of talented mobile developers that can help bring your product or service to the mobile market. Expect to see more mobile related announcements soon.

Need help with your mobile app? Contact us for a quote.

Download iPho

Download iCurry

TweetStream: Ruby Access to the Twitter Streaming API

2009-09-22T17:02:00-04:00

Twitter’s Streaming API is one of the most exciting developments in the Twitter API in some time. It gives you the ability to create a long-standing connection to Twitter that receives “push” updates when new tweets matching certain criteria arrive, obviating the need to constantly poll for updates. TweetStream is a Ruby library to access the new API.

Installation

Installation of TweetStream is simple, it’s available as a gem on GitHub and Gemcutter.org. To install it from GitHub:

gem sources -a http://gems.github.com
gem install intridea-tweetstream

To install it from Gemcutter:

gem sources -a http://gemcutter.org
gem install tweetstream

Usage

TweetStream creates a long-standing HTTP connection to Twitter, so unlike other Twitter libraries you don’t simply run it once and deal with the results. Instead, you provide a block that will be yielded to with each new status that arrives. The most basic example is:

require 'rubygems'
require 'tweetstream'

TweetStream::Client.new('user','pass').sample do |status|
  puts "[#{status.user.screen_name}] #{status.text}" 
end

This will provide you with a small sample snapshot of all of the updates being posted to Twitter at this moment and print them to the screen. There are also methods available to track single-word keywords as well as the updates of a specified list of user ids (integers, not screen names). You can do that like so:

# Track the terms 'keyword1' and 'keyword2'
TweetStream::Client.new('user','pass').track('keyword1', 'keyword2') do |status|
  puts "[#{status.user.screen_name}] #{status.text}" 
end

# Track users with IDs 123 and 456
TweetStream::Client.new('user','pass').follow(123, 456) do |status|
  puts "[#{status.user.screen_name}] #{status.text}" 
end

Handling Deletion/Limit Notices (Updated in 0.1.4)

Sometimes the Streaming API will send messages other than statuses. Specifically, it does so when a status is deleted or rate limitations have caused some tweets not to appear in the stream. To handle these, you can use the on_delete and on_limit methods. Example:

TweetStream::Client.new('user','pass').on_delete{ |status_id, user_id|
  Tweet.delete(status_id)
}.on_limit { |skip_count|
  # do something
}.track('intridea') do |status|
  # do something with the status like normal
end

Daemonization

One of the most useful features of TweetStream is its built-in daemonization functionality. This allows you to create scripts that run in the background of your machine rather than taking up an active process. To create a daemon script, you simply use TweetStream::Daemon instead of TweetStream::Client. Here’s an example:

require 'rubygems'
require 'tweetstream'

# The third argument is an optional process name.
TweetStream::Daemon.new('user','pass','tracker').track('keyword1','keyword2') do |status|
  # Do something like dump the status to ActiveRecord
  # or anything else you want.
end

If you were to place the above code in a file called tracker.rb you could then run ruby tracker.rb to see a list of daemonization commands such as start, stop, or run.

TweetStream is a simple wrapper on the Streaming API, but with built-in daemonization provides powerfully flexible means of accessing the Twitter Streaming API using familiar Ruby tools. More complete code documentation is available at rdoc.info.

Update: I overlooked the deletion and rate limit notices when I wrote the initial version of the gem. As of version 0.1.4 these are handled properly.

CouchDB-Lucene, CouchDBX, and CouchRest

2009-09-21T02:59:00-04:00

I’ve been playing a lot with CouchDB lately and if you’re on OS X there’s really no easier way to do so than by using CouchDBX, a self-contained application that includes CouchDB, Erlang, and all of the dependencies you need to run Couch.

However, recently I wanted to try the power and functionality of couchdb-lucene for full-text indexing of a CouchDB application on which I was working. It wasn’t immediately obvious to me how to make that happen, so I thought I’d share how I got it working for those who might want to do the same. For the record, I am using the following versions of things:

Mac OS X 10.6 (Snow Leopard)
CouchDBX 0.9.1 R13B pl2
CouchDB Lucene v0.4

Unpacking CouchDB Lucene

You will need to place CouchDB Lucene in a convenient location, but first you’ll need to unpack the gZip file. Note that, at least for me, the default Mac unarchiver did not provide a suitable .jar file. Instead, follow the README instructions and extract it using the following command:

unpack200 couchdb-lucene-0.4-jar-with-dependencies.jar.gz couchdb-lucene-0.4-jar-with-dependencies.jar

It doesn’t particularly matter where you put it (I put mine in /usr/local/etc) so long as you remember the location.

Editing the CouchDBX .ini File

Next you will need to edit the CouchDBX local.ini file to add the external for full-text indexing. To access the file, right-click CouchDBX and select “Show Package Contents” then navigate to Contents/Resources/couchdbx-core/couchdb/etc/couchdb/local.ini and open it up in your favorite text editor. You will need to add the following lines to this file, taking note to change the directory to match where you stored your Lucene .jar file.

[couchdb]
os_process_timeout=60000 ; increase the timeout from 5 seconds.

[external]
fti=/usr/bin/java -server -Xmx1g -jar /path/to/couchdb-lucene-0.4-jar-with-dependencies.jar -search

[update_notification]
indexer=/usr/bin/java -server -Xmx1g -jar  /path/to/couchdb-lucene-0.4-jar-with-dependencies.jar -index

[httpd_db_handlers]
_fti = {couch_httpd_external, handle_external_req, <<"fti">>}

All right, that’s all the setup you need to be running CouchDB Lucene! Now you can start up CouchDBX and set up your first search indexes.

Creating a Full-Text Index View

To create a full-text index view, you simply need to add a “fulltext” field to one of your design documents. The URL structure for accessing CouchDB Lucene searches is as follows:

http://localhost:5984/database_name/_fti/design_doc_name/index_name?q=your+query+here

Where database_name is any database you have on your system, design_doc_name is any design document in your database, and index_name is a fulltext index you defined. For instance, if I had a CouchRest generated design doc for a bunch of music, I might have a design document that looks something like this:

{
  "_id":"_design/Song",
  "_rev":"af12a4b12af1b24afbf244f1",
  "fulltext":{
    "my_search":{
      "index":"function(doc) { if (!doc['couchrest-type'] == 'Song') return null; var ret = new Document(); ret.add(doc.title); ret.add(doc.artist); return ret; }" 
    }
  }
}

I would then be able to access the search results with this URL:

http://localhost:5984/myapp/_fti/Song/my_search?q=Ben+Folds

Awesome! We now have full-text indexing up and running on CouchDBX!

Bonus: CouchRest Lucene

I use CouchRest extensively in my Ruby CouchDB projects, and I wanted to be able to integrate the new Lucene searches easily. I found this post that added a bit of functionality, but I wanted to be able to integrate with ExtendedDocument (and the snippet was also slightly outdated), so I’ve updated it. Just add this sometime after you include CouchRest:

class CouchRest::Database
  def search(design, index, query, options={})
    CouchRest.get CouchRest.paramify_url("#{@root}/_fti/#{design}/#{index}", options.merge(:q => query))
  end
end

class CouchRest::ExtendedDocument
  def self.search(index, query, options={})
    options[:include_docs] = true
    ret = self.database.search(self.to_s, index, query, options)
    ret['rows'].collect!{|r| self.new(r['doc'])}
    ret
  end
end

What this snippet does is allows you to perform searches on a database directly or by calling a search method on an extended document. Let’s look at a couple examples to see how it would work:

@db = CouchRest.database!("http://localhost:5984/myapp")

@db.search('Song','my_search', 'Ben Folds', :include_docs => true)

# The following is equivalent to the above, but will automatically
# include the docs and cast the result rows into ExtendedDocuments
Song.search('my_search', 'Ben Folds')

Now that we have this set up, we’re ready to go forth and build full-text search into our CouchDB apps. I hope this is helpful to some who have become somewhat familiar with CouchDB but are looking to push it a little further and try out some of the more advanced usages of CouchDB in their applications.

Good Idea, Bad Idea: Thingivore's Rails Rumble Post-Mortem

2009-08-24T12:52:00-04:00

The time has come and gone: the 2009 Rails Rumble is over (from a code perspective, anyway). This year myself and the other members of my team (Brent Collier, Dave Naffis, and Ping Yu) put together Thingivore, a place to show off your collection of movies, games, and books online. As one might expect from a 48-hour marathon application development experience, it was a mixed bag of elation, frustration, fist-pumping and head-hanging as the hours drew to a close. I wanted to take some time to document some of my “lessons learned” so to speak for future Rumblers and app developers in general.

Good Idea: Have a Server Configuration Guru

While the Rumble is primarily a coding contest, it’s important to note that someone on your team needs to be able to get that Linode server up and running. By having someone who can configure centos servers in their sleep on your team, you don’t have to sweat bullets at the prospect of “just getting it running.” In fact, Dave Naffis (Intridea co-founder and Rails deployment genius) came in and 45 minutes later said “OK, just hit cap deploy deploy:migrate” whenever you want to update the server. This is including setting up DNS for thingivore.com, getting Ruby, Rails, Apache, Passenger, MySQL, and CouchDB all running and probably all other manner of dark magic I can’t comprehend.

Maybe it’s because I’m not a server configuration guy, but that’s exactly the point: I didn’t have to worry about it and could focus on the design and development instead of worrying about whether or not we were going to get it running on the competition machines.

Bad Idea: “Let’s Try Something New!”

For some crazy reason, I decided that I wanted to use the Rumble as a way to experiment with new technologies (primarily CouchDB). Do not do this. The Rumble is a time to take the skills you know like the back of your hand and apply them with laser-beam focus to build something awesome and complete in 48 hours. While I’m happy with our product, there are reams of features that were cut while I scrambled to understand some of the complexities of complex sorts and other issues with CouchRest and CouchDB.

Of course, it was also fun to learn a new technology and use it in a “trial by fire” circumstance, but ultimately if you want to build something that can win the competition it’s probably better to stick to your guns.

Good Idea: As Many Plugins As You Can Actually Use

Ruby and Rails provide some of the most powerful collections of reliable code that you could hope for. We were originally planning to go 100% with CouchDB for the project, but when it became apparent that we would have to roll our own OpenID authentication we decided to slap MySQL in as well (only for user models) so that we could make use of AuthLogic and its OpenID extension. This saved us who-knows-how-many hours of work.

We also used some powerful Javascript libraries to achieve some impressive visual effects quickly and without too much pain. When planning your app, think about what technologies you’re using and make sure that there is sufficient library support to get you where you need to be in 48 hours.

Bad Idea: Plans Are For Sissies

This one is somewhat obvious, but it’s a good idea to have a strong game plan heading into something as time-limited as the Rumble. It was unavoidable in our case as I was on my honeymoon in Paris until (literally) the day before the competition, but planning in advance would have meant that every team member was utilized every moment they were available instead of spending time figuring out who should be doing what.

That being said, I think there is also value in not planning too much. During the competition there will be times when you see things that work and you need to let the application grow organically instead of mechanistically sticking to your original gameplan.

Good Idea: Hang Out In IRC

The #railsrumble IRC channel was a good place to be throughout the competition. You get direct access to a couple hundred other competitors as well as the organizers of the competition. If GitHub goes down, if there’s confusion about the rules, you’ll get your answers in a couple minutes.

It’s also just fun to feel the energy of the competition and everything from “Got it deployed!” to “so much left to do and so little time zomg”. I wasn’t able to physically be in the same area as any Rumblers, but I still had a great time and lots of comraderie on the IRC channel.

Bad Idea: Last-Minute Anything

You will have things to do until the last minute. Do not do them. You will have features you want to implement in the last 2 hours. Do not implement them. You will want to tweak the style, tweak a view, tweak something that seems important (but isn’t app-crashing) in the last 20 minutes. Do not do it. Last-minute changes that aren’t to address specific, serious bugs are a terrible idea when you won’t have a chance to fix new problems you introduce.

Next year I am going to try to force myself to spend the last 2-3 hours of the competition doing nothing but finding showstoppers on the production site and fixing only those things. Our OpenID flow was damaged in the last hour of the competition (for registration, not login) and we didn’t catch it until after pencils down. Never again!

Best Idea: Compete in the Rumble!

All in all, you can’t go wrong joining in the Rails Rumble. While your family and non-developer friends probably won’t quite understand what’s wrong with you (“You work 40 hours, over a weekend, and don’t get paid?”) you will have a blast and will learn a lot about how to build things inside a pressure cooker. I know that I plan to be back for next year’s Rumble, and my thanks go out to my team and everyone who made it possible!

Update: I forgot one more bad idea because I didn’t realize it until later…Bad Idea: Forget to Add Google Analytics to Your Site. You know that you will be curious about your visitors as the judging spins up, but if you forget to add analytics (as I did) you won’t have much information at your disposal!

iPhone Hack Day at Viget Labs

2009-08-14T10:00:00-04:00

I recently spent a day hanging out with a few of the guys at Viget Labs hacking on the iPhone. Ben Scofield, the Technology Director at Viget Labs, was leading an iPhone development primer for a few of Viget's finest, and they were nice enough to let a handful of "outsiders" join the fun.

My iPhone development experience at that point was very minimal. I had done a few online tutorials and walk-throughs, but nowhere near enough to really understand what I was doing. On top of that, my Objective-C knowledge was pretty much non-existant. Fortunately, none of this was a problem.

We spent the first half of the day going over the basics. Ben walked us through Xcode and Interface Builder, and we talked about basic project layout, the different types of iPhone apps (list, view, and navigation-based, etc).

We then broke off into small groups, pairs mostly, to do a little hacking. David Eisinger and myself put our heads together on something amazing. The Text-EmBIGiner, we called it (or something like that). Picture this, a text field, a button, and a label. You enter your text, hit the buttom, and BAM -- the label is updated with your text. It was amazing. We thought so at least. Many high-fives were had.

Lunch was provided in the form of Amante Pizza. Thanks Viget!

In the afternoon we moved on to talk about ways of making iPhone development less painful. In other words, removing the Objective-C. We briefly talked about Rhomobile, an open source framwork for building cross-platform mobile apps.

The remainder of the day was spent talking about and playing with two other frameworks, Appcelerator's Titanium and the open source PhoneGap. Both frameworks allow you to build your app using primarily HTML and javascript, but they still give you access to the iPhone native controls and features. They were very cool and I could definitely see myself playing with these more in the future.

Overall it was a really fun day, and I'm looking forward to putting my new knowledge to good use.

Thanks again Viget!

Looking Back at iPhoneDevCamp 3 at Yahoo!

2009-08-13T17:12:00-04:00

Our Director of Research & Development, Pradeep Elankumaran, and I attended iPhoneDevCamp 3 during the first week of this month. For those of you who haven't heard of iPhoneDevCamp, it is supposed to be setup as an "unconference", sort of a "Barcamp" type of an event, featuring content from the attendees and dedicated time for hacking on your own applications. Last year's iPhoneDevCamp was hosted by Adobe Systems in San Francisco. This year's iPhoneDevCamp was kindly hosted by the good guys at Yahoo! in Sunnyvale, California.

Yahoo! has an amazing campus that was more than capable of hosting the large amount of iPhone developers there for the event. There were also many "satellite" events going on in different cities around the world at the same time. One really interesting feature that they had at the event was a live stream of presenters of developers hacking away that could be viewed on any iPhone thanks to the new HTTP live streaming available in OS 3.0.

The event kicked off on the first day with a mixer, which allowed everybody to walk around and introduce themselves to other developers and vendors that were at the event. Chi-Hua Chien gave the keynote and talked about the general growth of mobile and the Kleiner Perkins iFund. After his keynote was another chance to meet others, followed by a musical performance by BT. Pradeep and I "accidentally" had a chance to walk on stage and check out BT setting up his equipment.

The rest of the event on the following two days consisted of teams hacking on different iPhone applications, which could be entered in to win a bunch of prizes for many different categories. Other keynotes from these days were by Andrew Stone of Twittelator fame and Steve Demeter, developer of Trism. There were also various talks held within different classrooms. Of those in attendance, the majority were experienced iPhone developers, but many others were not. People who didn't have any Objective-C experience helped out web interfaces, graphics, etc. I'm pretty comfortable with Objective-C but Pradeep hasn't had much experience with it at the time. For our project, which we weren't planning on submitting at the end of the event, Pradeep worked on the Rails back end and I worked on the iPhone interface.

There were some really interesting applications that won awards at the event. Some of those that stood out to us were AR Kit (Best iPhone Open Source App), Nurse Brain (Highest Potential Startup Idea), and iSign (Best iPhone App for Accessibility). AR Kit is an open source augmented reality UI library for displaying location based data in spherical coordinate systems mirroring UI Kit on the phone. Nurse Brain allows nurses to hand-off important data about patients during shift change. iSign opens up people accessibility on the iPhone by introducing a gesture based sign language. There were many other great applications that received awards. You can see the complete list of the winners here.

We had a great time at iPhoneDevCamp 3 and hope that we can have the chance to participate again next year. Thanks again to everyone who organized the great event, BT for performing (and not getting your security to throw us off stage), and Yahoo! for allowing the event to be hosted at a great campus. Hopefully, we'll soon be able to reveal what we were working on at the event!

Rails Underground Recap

2009-08-03T18:26:00-04:00

I finally had the time to write up a recap of Rails Underground in London, even though it’s a little overdue. I’ve really come to enjoy smaller regional conferences. Since it’s such a smaller crowd than larger conferences, you get to meet and spend more time with the same people—getting to know them better and pick each other’s brain. Rails Underground was great because of this reason, but not this reason alone.

I was attending Rails Underground to give my talk on Mobilizing Your Rails Application. The point of my talk was to get developers more focused on the mobile web and other mobile technologies and explain how to use certain plugins and gems to accomplish this. I believe my talk went well judging from the response afterwards—and since it was recorded, you’ll be able to judge it yourself as well. If you’re interested, feel free to view the slides here. I’ll be adding a link to the video of the talk as soon as it’s posted.

The conference was spread into two separate tracks for two full days. When I gave my talk, I was up against Pat Allen’s talk about the Community, which was another great talk also being presented at the same time in a different room. I enjoyed all of the talks that I attended but some of the talks that stood out to me were James Wilk’s talk on Cucumber, Pat Allan’s talk on Thinking Sphinx, Dr. Nic’s talk on Blue Ridge, and Jim Weirich’s talk on the Grand Unified Theory of Software. One talk that was extremely creative and entertaining was Paul Campbell’s talk, An Agile Workflow with Rails, which ended up being a hand-drawn story presentation. There were also keynotes on each day of the event. The opening keynote was delivered by Fred George and by Yehuda Katz on the last day.

There’s no doubt that the first Rails Underground was a success. Everybody that I talked to had a great time and learned a great deal of information. I met some new friends, learned some new things, had a great time and would love to attend again next year.

Built For Speed: Prevent Amazon CloudFront From Serving Stale Assets

2009-07-08T18:25:00-04:00

In the last Built For Speed post, I demonstrated how you can use the Amazon CloudFront Content Delivery Network (CDN) for images on your site. However, ideally we should be using CloudFront for all static assets, not just images.

Before we jump into that, though, let’s do a quick review of how CloudFront works. Like all CDNs, CloudFront consists of a number of edge servers all around the world, each of which has a connection back to a central asset server. When CloudFront receives a request for an asset, it calculates which edge server is geographically closest to the request location. For example, a user in England may request the asset ‘dog.jpg’. CloudFront will route that request to the London server, which will check if it has a cached version of ‘dog.jpg’. If it does, the edge server will return that cached version. If not, it will retrieve the image from the central asset, cache it locally and return it to the user. All subsequent requests in England for ‘dog.jpg’ will get the cached version on the London edge server. This approach minimizes network latency.

There is one big gotcha with this approach: If the ‘dog.jpg’ image changes from a poodle to a beagle, but keeps the same name, the edge server will keep serving the poodle image (assuming the expires headers are set far in the future as they should be). The edge server will not pick up the latest asset unless the name of the asset changes.

Okay, with that background out of the way, let’s take a look at how we can get our CSS and JavaScripts served through CloudFront. The approach I’ve taken is to create an initializer file that sets a REVISION constant. This could easily be created as part of a deployment process, copying the latest Git or Subversion revision into the initializer file, but for now I just created it manually. We’ll append the REVISION constant to the names of your packaged CSS and JavaScripts, so that on each deploy, the files have a different name, thereby preventing CloudFront from serving stale assets.

I have also moved the S3 configuration parsing out of the Post model and into another initializer, which sets the S3_CONFIG hash constant. In addition, I added the bucket name to my amazon_s3.yml config file. (Remember, if you have any questions, you can always refer to the source code.)

# /config/initializers/s3_config.rb
S3_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/amazon_s3.yml")[RAILS_ENV]

See below for the Rake task I wrote to copy the packaged files to S3. Note that this should be run after you run the ‘rake assets:packager:build_all’ task from AssetPackager (see the first Built For Speed post).

require 'right_aws'

namespace :s3 do
  namespace :assets do
    desc "Upload static assets to S3" 
    task :upload => :environment do
      s3 = RightAws::S3.new(
        S3_CONFIG['access_key_id'], 
        S3_CONFIG['secret_access_key']
      )
      bucket = s3.bucket(S3_CONFIG['bucket'], true, 'public-read')

      files = Dir.glob(File.join(RAILS_ROOT, "public/**/*_packaged.{css,js}"))

      files.each do |file|
        filekey = file.gsub(/.*public\//, "").gsub(/_packaged/, "_packaged_#{REVISION}")
        key = bucket.key(filekey)
        begin
          File.open(file) do |f|
            key.data = f
            key.put(nil, 'public-read', {'Expires' => 1.year.from_now})
          end
        rescue RightAws::AwsError => e
          puts "Couldn't save #{key}" 
          puts e.message
          puts e.backtrace.join("\n")
        end
      end
    end
  end
end

Again, ideally this should be part of the deployment process – first, run the AssetPackager task to create the packaged asssets, then run the S3 upload task to store them on S3. Notice that I’m appending the REVISION string to the end of file names for each of the packaged CSS and JavaScript files before uploading to S3. Also notice that I’m setting the Expires header to one year from now.

Hmm, we may have a couple problems here. First, by default, Rails expects CSS and JavaScript files to be in their proper places in the /public directory at the root of the application. That’s easily fixed by adding the following line to the bottom of /config/environments/production.rb:

ActionController::Base.asset_host = Proc.new { CLOUDFRONT_DISTRIBUTION }

The second problem is that the helpers provided by the AssetPackager plugin (‘stylesheet_link_merged’ and ‘javascript_include_merged’) don’t know that you’ve added a revision number to the end of the filenames. Not to worry – we just need to update a couple lines in /vendor/plugins/asset_packager/lib/synthesis/asset_package.rb. Update the ‘current_file’ method to look like this:

def current_file
  build unless package_exists?

  path = @target_dir.gsub(/^(.+)$/, '\1/')
  name = "#{path}#{@target}_packaged" 
  name += "_#{REVISION}" if defined? REVISION
end

Try making those updates, then running ‘rake s3:assets:upload RAILS_ENV=production” (remember we’re running in production mode for all the Built For Speed examples). After restarting your application, inspect the source and you should see that your stylesheets and scripts are being served by CloudFront, with the revision number at the end of the file names.

Now let’s return to our images. After the last post, we already have them delivered by CloudFront. The problem is, if you decide to update your image, Paperclip will give it the same style names as before (‘original’, ‘large’, ‘medium’, ‘thumb’). Uh-oh. Because the files have the same names, the CloudFront edge servers won’t update from the central asset server to use the latest image, and your users will continue to see the stale, old image.

Go ahead and give it a try by updating an image for an existing post. Whoops! The old image is still displayed.

Here’s how we solve that problem. First of all, let’s update the Post model to use the new S3_CONFIG constant. While we’re at it, let’s add a timestamp to our image path so that each time you update the image, it will have a different name.

# in /app/models/post.rb
has_attached_file :image, 
                :styles => {:large => "500x500", :medium => "250x250", :thumb => "100x100"}, 
                :storage => 's3', 
                :s3_credentials => S3_CONFIG, 
                :bucket => S3_CONFIG['bucket'], 
                :path => ":class/:id/:style_:timestamp.:extension"

One small issue: For some reason the Paperclip plugin uses a string representation for its ‘timestamp’ method, so you end up with values like “2009-06-26 15:25:44 UTC”. This isn’t very practical for timestamping file names, so I’ve changed it:

# /vendor/plugins/paperclip/lib/paperclip/interpolations.rb
def timestamp attachment, style
  attachment.instance_read(:updated_at).to_i
end

With that change, now each time we store an attached image, it will have a timestamp affixed to the end of the filename. Thus, the CloudFront edge server will go back to the central asset server and retrieve the new image rather than serving up the old image. Don’t worry – for each subsequent request, you’ll get the benefit of having the new image on the edge server.

Restart your application, and try updating an image again. This time around, you’ll see the image is updated correctly.

That wraps it up for our CloudFront review. Now go forth and speed up your sites!

Update

I realized I promised in my last post to show you how to make YSlow recognize that you were now using a CDN. Here’s what you do:

Go to “about:config” in Firefox
Right-click on the page, and select “New” > “String”
Enter “extensions.yslow.cdnHostnames” as the preference name
Enter “cloudfront.net” as your CDN host name
Restart Firefox and run YSlow on your application again – you should now see that you get an “A” for using a CDN

RESOURCES

Built For Speed source code

Built For Speed: Using Amazon CloudFront To Serve Assets

2009-07-06T18:00:00-04:00

This is the second in a series of posts on improving your site’s performance with the help of the YSlow Firefox plugin. In the last Built for Speed post, we took a look at YSlow’s most important factor in page speed – the number of HTTP requests. We demonstrated using the AssetPackager plugin to help reduce both the number of HTTP requests and the size of your CSS and JavaScript files. The source for the Built for Speed application is available on Github.

This week, we’ll learn how to use a Content Delivery Network (CDN) to help users see our static content faster. Granted, this may be overkill for a lot of sites, but I think it’s worth the time to see how it’s done. There are a lot of CDNs out there, but I’ve decided to use Amazon’s CloudFront because it’s relatively cheap and easy to set up (not to mention it integrates seamlessly with S3). Before you get much further, you’ll want to set up an account with S3 and CloudFront.

First, let’s install the Paperclip plugin so we can upload an image to go with our post.

  script/plugin install git://github.com/thoughtbot/paperclip.git

Next, we need to add the Paperclip fields to the Post model:

  script/generate migration AddPaperclipColumnsToPost

  # in the newly-created migration
  def self.up
    add_column(:posts, :image_file_name, :string)
    add_column(:posts, :image_content_type, :string)
    add_column(:posts, :image_file_size, :integer)
    add_column(:posts, :image_updated_at, :datetime)
  end

  def self.down
    remove_column(:posts, :image_file_name)
    remove_column(:posts, :image_content_type)
    remove_column(:posts, :image_file_size)
    remove_column(:posts, :image_updated_at)
  end

We also need to make the Paperclip declaration in the Post model:

  class Post < ActiveRecord::Base
    has_attached_file :image, :styles => {:large => "500x500", :medium => "250x250", :thumb => "100x100"}
  end

And finally we make the updates to the views. First change the new and edit views, adding the file_field for the attachment and making sure the form is set to accept multipart data (see the source on Github if you have questions). Then update your show view to display the image:

  <%= image_tag @post.image.url(:large) %>

Now let’s take a look at our application in Firefox. Remember, we’re running it in production mode to see the benefits of the AssetPackager plugin among other things. Create a new post with the image attachment of your choice.

One gotcha – if you are running your application using Passenger, you may see an error something like this when you try to create a Paperclip attachment:

  Image /tmp/passenger.621/var/stream.818.0 is not recognized by the 'identify' command.

In order to avoid this, create a file in /config/initializers to tell Paperclip where to find ImageMagick. I installed ImageMagick using MacPorts, so my file looks like:

  Paperclip.options[:command_path] = "/opt/local/bin"

Okay, now that we have a new post with an image, browse to the post detail page, open up the YSlow interface, click “Run Test” and take a look at the second grade, “Use a Content Delivery Network (CDN)”.

Uploaded with plasq’s Skitch!

Ugh, we got a “D”. Okay, let’s see how we can implement Amazon CloudFront to make that grade an “A”.

Let’s start by telling Paperclip to use S3 for our image storage. Go ahead and create a configuration file called amazon_s3.yml. Obviously, you’ll need to replace the values here with your own keys:

  # config/amazon_s3.yml
  development:
    access_key_id: 123...
    secret_access_key: 123...
  test:
    access_key_id: abc...
    secret_access_key: abc...
  production:
    access_key_id: 456...
    secret_access_key: 456...

Paperclip depends on the ‘right_aws’ gem for its S3 storage, so make sure you add that to your config.gem list in /config/environment.rb and install it with:

  rake gems:install

Next, update the Post model so it will use the new S3 configuration:

  class Post < ActiveRecord::Base
    has_attached_file :image, 
                    :styles => {:large => "500x500", :medium => "250x250", :thumb => "100x100"}, 
                    :storage => 's3', 
                    :s3_credentials => YAML.load_file("#{RAILS_ROOT}/config/amazon_s3.yml")[RAILS_ENV], 
                    :bucket => "built-for-speed", 
                    :path => ":class/:id/:style.:extension" 
  end

Now restart your application and create a new post with an image. When you get to the post detail page, check out the source and you should see that your image is being served from your S3 bucket. That’s great, but what we really want to do is serve the image from the CloudFront CDN. The easiest way to do this is to install the S3 Firefox Organizer plugin). Once you enter your credentials, you should see your newly-created ‘built-for-speed’ bucket. Right-click on the bucket name and click “Manage Distributions”, then optionally add a comment and click “Create Distribution” (we’ll skip the CNAME option for now).

Uploaded with plasq’s Skitch!

This will generate a new resource URL for you to use in your application so you can take advantage of CloudFront. Now we have to go back and tell our application to use this resource URL:

  # /config/initializers/cloudfront.rb
  # 
  # Note that your CloudFront resource URL will be different
  CLOUDFRONT_DISTRIBUTION = "http://d2qd39qqjqb9uw.cloudfront.net"

  # in /app/models/post.rb
  def cloudfront_url( variant = nil )
    image.url(variant).gsub( "http://s3.amazonaws.com/built-for-speed", CLOUDFRONT_DISTRIBUTION )
  end

  # in /app/views/posts/show.html.erb
  <%= image_tag @post.cloudfront_url(:large) %>

Restart the application and go back to the post detail page. Inspect the source and you’ll see that your image is now being served from CloudFront.

Okay, I think that’s enough for today. In the next post, I’ll show you how to avoid CloudFront serving stale assets and how to make YSlow recognize that you are now using a CDN. Please leave any questions or comments below.

CREDITS/RESOURCES:

Sketchnotes from the UIE Roadshow

2009-07-01T09:20:00-04:00

I recently had the pleasure of attending the User Interface Engineering Roadshow in Washington, DC. The day was chock-full of insight and wisdom from usability guru Jared Spool, founder of UIE.com. In taking notes during the workshop, I decided to take my first official shot at sketchnoting. The results are as follows:

Overall, I found this experience to be wholly satisfying. Putting key ideas into sketches required an interesting use of my attention span: in addition to listening intently to the ideas being communicated, I was simultaneously forced to employ creative sketching solutions that would properly embody the most important parts of the talks.

Upon returning home from the Roadshow, I was quite surprised to find these sketches spanning 5 full pages of my notebook. Upon scanning the notes and adding a bit of chronological organization, I’m left with a sort of visual map of the workshop (as I experienced it). I hope these notes might be of interest to others who attended.

As for adventures in sketchnoting? I look forward to continued exploration when the proper circumstances arise in the future.

Built For Speed: Using the AssetPackager Plugin

2009-06-26T14:42:00-04:00

Inspired by the recent launch of code.google.com/speed, I decided to sit down and see how I could apply their guidelines. This is the first in a series of posts on improving front-end performance for your Rails applications.

First of all, we need to create our sample application. Recently, I’ve been using Beet, a gem for generating Ruby projects, but you can create your local version however works for you. Using Beet, the following command tells the Rails generator to use MySQL, remove unused files (public/index.html, etc.) and initialize a Git repository:

  beet -g built_for_speed -r="rails/db/mysql, rails/clean_files, rails/git"

Next, let’s create a Post resource:

  script/generate scaffold Post title:string body:text

Make sure your databases are created, and run the migrations. Note that for the purposes of this tutorial, I’m running the application in production mode (to better see the speed benefits), using Passenger on my MacBook Pro. By the way, I highly recommend the Fingertips Passenger preference pane for managing your sites locally.

  RAILS_ENV=production rake db:migrate

Now let’s add the Blueprint CSS framework. Download the latest version from blueprintcss.org and unpack it somewhere. Blueprint provides you with compressed versions of the CSS files, but humor me and add the uncompressed versions. From the unpacked directory, copy all the CSS files from /blueprint/src/ into /public/stylesheets/blueprint/ in your application.

Before we start up the application, let’s add the CSS files as well as the default JavaScript files to the head of our posts layout (/app/views/layout/posts.html.erb). The head of your layout file should look something like this (note that I added my own base.css file):

  <head>
    ...
    <%= stylesheet_link_tag 'blueprint/reset', :media => 'projection, screen' %>
    <%= stylesheet_link_tag 'blueprint/typography', :media => 'projection, screen' %>
    <%= stylesheet_link_tag 'blueprint/forms', :media => 'projection, screen' %>
    <%= stylesheet_link_tag 'blueprint/grid', :media => 'projection, screen' %>
    <%= stylesheet_link_tag 'blueprint/print', :media => 'print' %>
    <!--[if lt IE 8]>
        <%= stylesheet_link_tag 'blueprint/ie', :media => "screen, projection" %>
    <![endif]-->
    <%= stylesheet_link_tag 'base', :media => 'projection, screen' %>
    <%= javascript_include_tag :defaults %>
  </head>

Okay, now let’s fire up the application. I’ll be using Firefox so we can profile the application using YSlow. Go ahead and create your first post. Once you’re looking at the ‘show’ page, let’s open up Firebug and click on the “YSlow” tab. On the YSlow screen, click the “Run Test” button to get your page grade.

Uploaded with plasq’s Skitch!

Bummer, we got an overall D – not so good. Let’s take a look at what’s going on. YSlow grades are listed in order of importance, so let’s check out the first section: “Make fewer HTTP requests”. Looks like we got a C in that area. What can we do to improve our grade? YSlow gives us some tips: “combine multiple scripts into one script, combine multiple CSS files into one style sheet”. Before we get back to the application, take a look at the “Components” tab in the YSlow dialog.

Uploaded with plasq’s Skitch!

Hmm, five JavaScript files for a total of 234.3K and six CSS files for a total of 18K. We definitely need to work on that.

In order to compress JavaScript and CSS files in my applications, I use Scott Becker’s AssetPackager plugin. Go ahead and install it:

  script/plugin install git://github.com/sbecker/asset_packager.git

The first step after installation is to create the configuration file for AssetPackager:

  $ rake asset:packager:create_yml

You should see a message to reorder the files under ‘base’, so let’s go ahead and do that. Open up the newly-created /config/asset_packages.yml file. You’ll notice that there are two top-level entries – one for ‘javascripts’ and one for ‘stylesheets’. AssetPackager should have correctly generated the required files for the ‘javascripts’ section, but we’ll need to add the Blueprint files. Your completed asset_packages.yml file should look something like this (again, I added a base.css file):

    --- 
    javascripts: 
    - base: 
      - prototype
      - effects
      - dragdrop
      - controls
      - application
    stylesheets: 
    - base:
      - blueprint/reset
      - blueprint/typography
      - blueprint/forms
      - blueprint/grid 
      - base
    - print:
      - blueprint/print
    - ie:
      - blueprint/ie

Now that the config file is set up, you can go ahead and generate the combined, minified JavaScript and CSS files:

  rake asset:packager:build_all

This command will output a “[name]_packaged” file for each entry under both ‘javascripts’ and ‘stylesheets’. Now we have to tell our application to use those compressed files. Go back to your posts.html.erb layout and change the head to look like this:

  <head>
    ...
    <%= stylesheet_link_merged :base, :media => "screen, projection" %>
    <%= stylesheet_link_merged :print, :media => "print" %>
    <!--[if lt IE 8]>
    <%= stylesheet_link_merged :ie, :media => "screen, projection" %>
    <![endif]-->
    <%= javascript_include_merged :defaults %>
  </head>

Okay, now it’s time to see the fruits of our labors. Restart the application in the Passenger preference pane, and reload the post page in Firefox. Now let’s run YSlow again. This time, you should see output like this:

Uploaded with plasq’s Skitch!

Alright! We’ve improved our grade up to an overall B, with an A for “Make fewer HTTP requests”. Let’s take a look at the ‘Components’ tab.

Uploaded with plasq’s Skitch!

Thanks to AssetPackager, we’re down to one JavaScript file for a total of 171.7K and two CSS files for a total of 12.6K. Now there’s eight fewer components, and we’re saving 68K of bandwidth on each request. Nice work!

The source code for this sample application can be found at: github.com/dramsay/built_for_speed

Check back for more performance tips in the future.

Quick Tip: Railsy Array Checks in jQuery

2009-06-19T21:11:00-04:00

I love the any? and empty? convenience methods that Rails and Ruby provide, they make conditional statements much easier to read. I also really dislike the default method of checking this behavior in jQuery:

if ($('some.element').length > 0) {
  // ...do something
}

Well, luckily jQuery is ridiculously easy to extend, so why not just mix that functionality in with a couple of quick shot plugin methods? Just add this javascript sometime after you include jQuery:

jQuery.fn.any = function() {
  return (this.length > 0);
}

jQuery.fn.none = function() {
  return (this.length == 0);
}

That’s all you have to do! Now we can make the same call as before, but it looks a little cleaner:

if ($('some.element').any()) {
  // do something more readably...
}

UPDATE: Apologies, I added in the empty bit as a last-second update to the post and forgot to check and realize that empty() is part of jQuery core. Updated the name to none instead.

Intridea's Hackon in Portland, Maine

2009-06-12T13:01:00-04:00

I’m pleased to announce Intridea’s Hackon, a 3-day co-working and unconference event we’ve organized at the Portland Harbor Hotel in Portland, Maine June 18-20th.

Thursday and Friday (17/18th) will be for informal hacking, coworking, and discussion and as we attempt to backfill interesting talks for Saturday (20th).

The Hackon is intended to bring local software craftsman together to work on projects, exchange ideas, hack on open source, or just get some work done. There will be wifi, projection, food, and valet parking at the hotel.

And because we love developers and the community so much, we are hosting this event for FREE! Yes. Free. If you want to attend we only ask that you RSVP ahead of time so we can ensure that enough food, space, and power available.

Thank you to MERUG, NHRUG, and #Progmatica for their support and their assistance in spreading the word!

Please head over to intridea.com/hackon for details, rsvp, and talk submission.