Archives - Apr 2010

Everyone says they have a REST (or RESTful or REST-like) API. Twitter does, Facebook does, as does Twilio and Gowalla and even Google. However, by the actual, original definition, none of them are truly RESTful. But that’s OK, because your API shouldn’t be either.

The Common Definition

The misconception lies in the fact that, as tends to happen, the popular definition of a technical term has come to mean something entirely different from its original meaning. To most people, being RESTful means a few things:

1. Well-defined URIs that “represent” some kind of resource, such as “/posts” on a blog representing the blog posts.
2. HTTP methods being used as verbs to perform actions on that resource (i.e. GET for read operations and POST for write operations).
3. The ability to access multiple format representations of the same data (i.e. both a JSON and an XML representation of a blog post).

There are some other parts of the common vocabulary of REST (for example, for some developers being RESTful would also imply a URI hierarchy such that /posts/{uniqueid} would be seen to be a member of the /posts collection), but these are what most people think of when they hear “RESTful web service.” So how is this different from the “actual” definition of REST?

Diverging From Canon

By the common definition of REST, a service defines a set of resources and actions that can be accessed via URI endpoints. However, the “true” definition of REST demands that resources be self-describing, providing all of the control context in-band of the provided representation. No out-of-band knowledge should, therefore, be required beyond understanding a media type that the resource can provide. From there, it should be possible to follow relations provided in “hypertext” context of the representation to “transfer state”, follow relations, or perform any necessary actions.

Another common divergence comes through the practice of using HTTP POST (or PUT) bodies with key-value pairs to create and update documents. In a canonically RESTful service clients should be posting an actual representation of the document in an accepted media type that is then parsed and translated by the service provider to create or update the resource.

Still more divergence comes in the common practice of denoting collections and elements. A truly RESTful web service has no concept of a “collection” of resources. There are only resources. As such, the proper way to implement a collection would be to define a separate resource that represents a collection of other resources.

Is anything truly RESTful?

Pretty much everyone who claims to have a REST API, in fact, does not. The closest I’ve found is the Sun Cloud API which actually defines a number of custom media types for resources and is discoverable based on a single known end-point. Everyone else, thanks for playing.

There is, however, one public and extremely widely used system that is entirely RESTful. It’s called the world wide web. Yes, as you’re browsing the internet you’re engaging in a REST service by the true definition of the name. Does your browser (the client) know whether it’s displaying a banking website or a casual game? Nope, it just utilizes standard media types (HTML, CSS, Javascript) to compose and represent the data. You don’t have to know the specific URL you’re looking for on a website so long as you know the “starting place” (usually the domain name) and can navigate there.

So REST by its original definition is far from useless. In fact, it’s an ingenious and flexible way to allow for the consumption and traversal of network-available information. What it’s not, however, is a very good roadmap toward building APIs for web applications.

Real REST is too hard.

Truly RESTful services simply require too much work to be practical for most applications. Too much work from the provider in defining and supporting custom media types with complex modeled relationships transmitted in-band. Too much work for clients and library authors to perform complex aggregation and re-formulation of data to make it conform to the real REST style. Real REST is great for generic, broad-encompassing multi-provider architectures that need the flexibility and discoverability it provides. For most application developers it’s simply overkill and a real implementation headache.

There’s nothing wrong with the common definition of REST. It’s leaps and bounds better than some of the methods that came before it and pretty much everyone is already on board and familiar with how it works. It’s a pragmatic solution that really works pretty well for everyone. As they say, if it ain’t broke, don’t fix it.

What’s in a name?

The only problem is that now we have lots of things that we’re calling REST that aren’t. Roy T. Fielding, primary architect of HTTP 1.1 and the author of the dissertation that originally defines REST, hasn’t always been happy with people calling things REST that aren’t. And maybe he has a point: these services certainly aren’t REST by his definition and because of the wide propagation of this incorrect definition of REST most people now don’t really understand the true definition. In fact, I don’t claim to have a great understanding of REST as Dr. Fielding defines it.

The problem is that the ship has sailed, and whether it’s true or not, REST now also means any simple, URL-accessible resource-based service. Perception is reality, and perception has changed about the definition of REST and RESTful. While the true definition is interesting for academic purposes and certainly lies behind the technologies upon which we build every day, it simply doesn’t have a whole lot of use to web application developers. The fact that (nearly) zero services exist that implement true REST for their API serves as testament to that.

What can we learn from REST?

Just because we don’t use true REST doesn’t mean there aren’t a few things we can learn from it. There are a few aspects that I’d love to see come into favor in the common definition. The idea of clients needing to know a few media types instead of specific protocols for each service is one that breaks down in practice for APIs due to the overwhelming number of web services with different needs in terms of domain-specific resource definition. However, wouldn’t it be great if there were an accepted application/x-person+json format that provided a standardized batch of user information (such as name, e-mail address, location, profile image URL) that you could request from Facebook, Twitter, Google or any OpenID provider and expect conforming data? Just because there are lots of domain-specific resources doesn’t mean that it isn’t worthwhile to try to come up with some standards for common information.

REST-like discoverability could also be a boon for some services. What if Twitter provided something like this along with a tweet’s JSON?

{
  "actions": {
    "Retweet" : { "method":"POST", url:"/1/statuses/retweet/12345.json" },
    "Delete" : { "method":"DELETE", url:"/1/statuses/destroy/12345.json" },
    "Report Spam" : { "method":"POST", url:"/1/statuses/retweet/12345.json", params:{"id":12345} }
  }
}

So while REST as originally intended may not be a great fit for web applications, there are still patterns and practices to be gleaned from a better understanding of how such a service could work. For web applications, the case may be that REST is dead, long live REST!

There have been tons of comparisons between Ruby and other languages (mostly Python) ranging from the technical to the epically titled. I’ve always felt that both languages are nice, but feel much more at home with the expressive, readable Ruby syntax. And don’t get me wrong, I love Ruby for all kinds of language reasons. Re-openable classes, blocks and the general meta-programming DNA of Ruby make it just wonderfully powerful and useful for me as a developer. However, when I think about it the language is really only half the story when it comes to why I love being a Ruby developer.

Whether it’s inherent in the makeup of the language and those to whom it appeals or the “buck the mainstream” attitude of Rails’s opinionated-ness, Rubyists tend to take to new things like fish to water. An outsider may look at the insane progression of testing frameworks and other different-ways-to-do-the-same-thing and think it’s a kind of madness, sickness, or chaos. Well, I suppose it is. However, living inside the Ruby hurricane has helped me to grow as a developer more than I could possibly have imagined in the few years I’ve been doing it full time. Thanks to Ruby, I was on board with these technologies months or even years before I feel I otherwise would have been (just a few examples):

• Test-Driven Development: Already a mainstay in the Ruby community when I joined it, TDD has seen some pretty rapid expansion into other languages and communities. I’m not saying Ruby was the first or only, but it was certainly an early and strong TDD community.
• Distributed Version Control: GitHub is the future not only of project version control but of open-source collaboration. SourceForge by comparison seems like a lumbering dinosaur. Fork, fix, push.
• NoSQL: I was playing with CouchDB about a year ago, not realizing that soon it would be a player in the biggest developer flamewar since Vim vs. Emacs.

I’m not trying to say that X language doesn’t promote innovation or adoption of new ideas or Y has an inferior community. This isn’t a comparison post. I just know that when it comes to new technologies, most Rubyists I know are already jumping out of the plane while still trying to figure out how the parachute works. That sounds like an insult, but I think it’s amazing. We have a community of people so excited about technology that they literally can’t wait to build on it or for it, and share it with others. The huge proliferation of regional Ruby conferences speaks to this: we’re a group of people so intensely interested in learning about what’s new that we can’t manage holding just a few mainstream conferences each year.

For me, being a part of the Ruby community feels like getting a sneak peek at where software development is going six months to two years from now. That’s not to say it’s all rainbows and daisies…the constantly changing landscape requires a real passionate dedication to keep up or you’ll quickly fall behind, and not all technologies are meant to immediately be deployed to massive-scale production environments (restraint is a skill a good Rubyist must learn and exercise on a regular basis). But I love Ruby because I feel confident that I will be made aware of trends in software development long before I would otherwise be expected to understand them.

It’s fun to live in the future.

I recently had to integrate Akamai HTTP Downloads to a Rails project. The goal is to take advantage Akamai’s large global network of edge servers to serve large file downloads over HTTP to client browsers. These edge servers are distributed and optimized to cache and serve static contents to customers. They also decrease the load on the application servers. Since these large files (i.e. apps, games, tarballs, …etc.) remain static most of the time (except when there are new releases), it would be wasteful to transmit them using the application server’s bandwidth, which is better used to transmit dynamic content that can’t be cached.

First, you need to set up your Akamai configurations at Akamai EdgeControl HTTP Downloads Configurations, and download the URL-based token generator? and put them in RAILS_ROOT/lib. I will show how to use both the Perl and C versions.

To allow easier configuration, I set up a config/akamai.yml file that looks like:

production:
  protocol: http://
  domain: cdn.example.com
  keyname: __gda__
  window: 28800
  salt: secret
  tokenizer: perl
  extensions:
    - .zip
    - .exe
    - .msi
    - .dmg
    - .gz
    - .7z

Akamai only requires a token for files that have these extensions. For images and videos, you do not need to generate a token. The akamaized method first checks the file’s extension to determine if a token needs to be generated. If it does, the method calls the token generator to get a filename with the token appended. Finally, the complete Akamai URL is built with protocol, domain, and the new filename.

def akamaized(filename)
  extension = filename[filename.rindex(/\..*$/)..-1]
  if AKAMAI['extensions'].include?(extension)
    extension_fix = "?ext=#{extension}"
    filename_with_extension_fix = "#{filename}#{extension_fix}"
    filename_with_token = `#{AKAMAI['tokenizer']} -I '#{RAILS_ROOT}/lib/UrlAuthPerl-1.1.1' '#{RAILS_ROOT}/lib/UrlAuthPerl-1.1.1/akam-edge-auth-url.pl' '#{filename_with_extension_fix}' #{AKAMAI['keyname']} #{AKAMAI['window']} #{AKAMAI['salt']}`
    akamai_filename = "#{AKAMAI['protocol']}#{AKAMAI['domain']}#{filename_with_token}"
  else
    akamai_filename = "#{AKAMAI['protocol']}#{AKAMAI['domain']}#{filename}"
  end
end

Depending on how you manage file assets in your Rails application, you may choose how to use akamaized. For example, if you use attachment_fu for file uploads, you may want to override attachment_fu’s public_filename method and enable it only for production so that your developers can still call public_filename to take advantage of Akamai HTTP Downloads. It will be transparent to them.

I showed the Perl version first because both Mac and Linux have the standard Perl interpreter installed and it is more cross-platform-friendly. If you want to use the C version if that’s a bit faster, you would have in your config/akamai.yml:

  tokenizer: lib/URLAuthC-1.1.3/genURL

and your akamaized method:

    filename_with_token = `cd #{RAILS_ROOT}/#{AKAMAI['tokenizer'][0..AKAMAI['tokenizer'].rindex('/')]} ; .#{AKAMAI['tokenizer'][AKAMAI['tokenizer'].rindex('/')..-1]} -u '#{filename_with_extension_fix}' -p #{AKAMAI['keyname']} -w #{AKAMAI['window']} -s #{AKAMAI['salt']}`

This sums up how you can take advantage of Akamai HTTP Downloads to serve large static files faster to your users and decrease the load on your application server. In my next post, I will show how to use Akamai’s Content Control Utility API to purge cached content on the Akamai edge servers, so that you can make new releases of your apps, games, tarballs, …etc. readily available to your users.

Facebook recently announced their intentions to become the center of the universe for online identity and social connections. While the new functionality of the Facebook Open Graph is exciting and represents a real glimpse into the interconnected semantic web, it has also sparked numerous concerns about placing so much power into the hands of a single company. As it turns out, not everyone on earth is content with having their Facebook profile be the only representation of their identity on the web. To those sweating over the level of control and power this gives Facebook, I say:

Yes, if Facebook perpetually controlled identity and semantic “Liking” that would be very bad for the web as a community. And it seems like it will be difficult to overcome the hurdle of that damn “Like” button on every page on the internet, right? I mean, sites aren’t going to want a NASCAR array of “Like” buttons cluttering up the place. How can anyone be expected to compete with Facebook’s 400 million user promise?

Terraforming the Web

We should really all be thanking Facebook for what they’re doing. They’re essentially the first colonization spaceship sent out to the world wide web, a rough-and-tumble wild west crew that gets to make their own rules because they’re doing the pioneering. And while their approach may smack of self-interest, you have to realize it could have been so much worse.

The acquisition of FriendFeed seems to be the best thing that could possibly have happened to Facebook, because rather than the openness of FriendFeed being subsumed by the closed past of Facebook, the FriendFeed team seems to have done the impossible: they’ve convinced Facebook to participate in the broader conversation about open standards (even if tentatively).

The result of Facebook’s Open Graph push will basically terraform the web, reshaping it into something new where semantic applications can thrive. Of course Facebook is doing this all for their own benefit…why shouldn’t they? But they’re also doing it in such a way that they simply will not have control of it forever. So how can this shake out for the best? How can an open protocol with a proprietary “Like” button become the open, semantic web that many dream of? Simple. Browsers.

Firefox and Chrome are the Key

Ultimately the interaction with the semantic web doesn’t belong on the website to begin with. That’s Web 2.0 thinking. What we’re going to see in the next months and years is a move of semantic activity and identity being handled in the browser, either explicitly by the vendor or through extensions on their platform. Mozilla is already experimenting with this, and I would bet Google has some ideas of their own along the same lines.

So while Facebook may get to own the “Like” button on the page, once every browser comes with a “Like” button that connects to any number of services according to an open protocol, once I can log into a site using identity stored in my browser and skip the Facebook authorization dance, the semantic web will be realized in full. And the great thing is, everyone will have all of the data they need to build such services thanks to the aggressive partnerships pursued by Facebook.

In essence, everything that Facebook announced at F8 ultimately belongs in the browser, not through a single connection to a proprietary service. And the great thing is that not only is that the better solution for proponents of the open web, but it’s also even easier than Facebook for users of the browsers that eventually gain these features. Facebook has always won the war for identity based on convenience, but nothing is more convenient than the tools built in to my browser of choice.

So thanks, Facebook, for launching the private beta of the semantic web. I can’t wait to see what happens when it goes public.

This week on the Intridea Insider, meet Maggie Lubberts, QA Manager at Intridea. Her favorite color in kindergarten was "clear", her brother is a cage fighter, she majored in English, and she actually likes living in Kansas! This might be one of our most interesting Insider editions yet!

Maggie studied English in college and although she loves writing and reading (sci-fi and fantasy, mostly), what she loved most about English was editing: "I wanted to be an editor, because I love taking what other people have already made and then making it better." She says that her love for editing combined with her perfectionism is "great for this kind of job. Not many people would spend 5 minutes ticketing a slight misalignment of a button if it's off by 3 pixels. Who's gonna notice that? ME!"

After finishing college, Maggie began working at T-Mobile, in a tech and customer support role. She worked there until last summer when Michael Bleigh, referred her to Intridea for a QA position. "Michael knew how much I was on the computer, hacking my iphone, and basically self educating to make my stuff better. He heard that Intridea was looking for a QA person, and he connected the dots." Now Maggie has her "dream job" and she's always pinching herself to confirm the reality of it all.

Maggie already had the right personality and talent for QA, and she was able to quickly teach herself the tools for the job. Now she has a really solid process established.

Here is her basic QA bug ticketing process, in her words:

• I take a screenshot of the problem with Skitch.
• I mark it up with giant arrows in obnoxious colors as a form of stress relief, and so that the dev trying to fix the problem will be able to easily tell what they're fixing.
• Then I create a ticket, and come up with a name for it; I include the URL and embedded screenshot along with a description and then set any indicators like which browser and operating system I am using.
• The devs come behind me and fix the errors and then mark them as "resolved" in our system.
• Finally, I go back after they've released the new code and "verify and close" those tickets to make sure the problem was really fixed.

Maggie uses Unfuddle for ticketing (and sometimes Pivotal Tracker, depending on the project). She also uses an app called Test Run, as a focused tool for test case management. She often finds herself reading two of her favorite QA blogs for support and insight, Testingreflections.com and QAInsight.net. She has been doing long-term QA work on Present.ly and a large gaming site. Recently, she has been working on HowAboutWe, a fresh dating site for one of our clients. Maggie is also in charge of support for a number of our internal products, and uses Zendesk for the majority of her communication with users requesting help.

Before my interview with Maggie, I sent out an update to the team in Present.ly, asking people what they wanted to know about her. Joe Grossberg wanted to know about one of the craziest QA experiences that she's had. Maggie shared a story about button confusion: "Once, a dev had forgotten to change the text for a button: it should have said 'disable', but instead it said 'DESTROY!' (not my emphasis). I had a customer write in concerned (really concerned) about what would happen if she were to click the "destroy" button."

Joe also wanted to know what it was like for Maggie to work "that remotely"; he was no doubt referring to her location out in Kansas. So I talked to Maggie a lot about Kansas and why she loves it there. She describes Douglas County as "the liberal mecca for Kansas" and she spoke about the cohesive community in her town of Lawrence (home of the Kansas University Jayhawks). She lives across the street from a farmer's market and says that the people in her town make it a point to contribute to the community by eating local, volunteering, and supporting each other's businesses. "When I moved to Lawrence I saw what a town could be if people supported local businesses. All I knew from the town I grew up in was Walmart and Target, Hummers and chain food. Only the 'poor people' did garage sales, and no one knows their neighbors. Every cool person in Kansas lives here. Appreciating my blessings aplenty and giving back has been easy here because there are plenty of opportunities to do good."

I know that you're thinking that Lawrence, Kansas couldn't sound any cooler, but wait for it: during our interview, Maggie was missing the Adult Swim block party in her neighborhood. "Apparently you can win inflatable meatwads. INFLATABLE MEATWADS!!" Maggie didn't win an inflatable meatwad, but she was able to go join the party after our interview.

She isn't lonely in Kansas. Maggie lives with her partner, Stephy and their three dogs. They have a garden and love to cook together. Her family also lives there, and she visits them often. She loves playing with her nieces and nephews, and prides herself on being "Cool Aunt Maggie". She thrives on social interaction, so she depends heavily on our Present.ly app to feel "connected" to the other Intrideans. She admits that "it's hard not being able to see the people I work with, but luckily our company built an awesome tool that helps! With Present.ly I'm able to get the "water cooler" talk that you get in an office, and I can get to know the people I work with daily, even if it isn't face to face."

In high school and in college she was involved in extra-curricular programs like debate, forensics and Mock Trial Competitive Speaking. "It was fun being around a bunch of like-minded people with awesome interests on a day-to-day basis". Her grandma was once the English teacher and debate coach at the high school she attended, so she was able to learn debate and English skills early on. "When I was little my favorite game was the "National Geographic Game", where I'd read out loud to my grandma from the National Geographic until I found a word I couldn't pronounce or define and then I'd have to figure it out. It sounds lame, but it was so much fun for me because I loved learning."

And she still does love learning. The successful transition from her tech support job at T-Mobile to a QA position at Intridea is proof of that. She worked diligently to learn the skills and tools necessary to be great at what she does. She loves the challenge of hunting down bugs, and nothing is worse to her than when someone comes in behind her and finds something that she missed. But the fact is that Maggie is so good at what she does, that she was recently promoted to QA Manager. Thinking back to her earlier years when she dreamt of being an editor, I can see how she does so well in QA. In her own words, "I think of it like editing; behind every amazing author is a great copy editor." And behind every great dev, there is a great QA engineer. Fortunately, we have Maggie!

This post is part of a weekly series, called "Intridea Insider"

While I’d been tracking with great interest the progress of OAuth 2.0, Facebook lit off the powderkeg yesterday by announcing that their entire API was moving to the protocol (as well as to RESTful JSON). As a developer who had been constantly confounded by the relentlessly hostile environment that Facebook seemed to present to developers, yesterday was a sudden and welcome about-face. The acquisition of FriendFeed, it seems, gave Facebook the talent they needed to do it right this time.

But anyway, on to the news! We have just released a gem for OAuth 2.0 to work with the new Facebook API. You can get it right now:

gem install oauth2

We wanted to get this into the hands of developers ASAP so for now the functionality is pretty much limited to the “web server” type of authentication (the protocol includes many different strategies, all of which will be implemented on the gem over time) and has been tested to work with Facebook’s new API.

So how do you use it? Here is an example Sinatra application containing all of the code necessary to authenticate and then perform requests against the Facebook API.

require 'rubygems'
require 'sinatra'
require 'oauth2'
require 'json'

def client
  OAuth2::Client.new('api_key', 'api_secret', :site => 'https://graph.facebook.com')
end

get '/auth/facebook' do
  redirect client.web_server.authorize_url(
    :redirect_uri => redirect_uri, 
    :scope => 'email,offline_access'
  )
end

get '/auth/facebook/callback' do
  access_token = client.web_server.get_access_token(params[:code], :redirect_uri => redirect_uri)
  user = JSON.parse(access_token.get('/me'))

  user.inspect
end

def redirect_uri
  uri = URI.parse(request.url)
  uri.path = '/auth/facebook/callback'
  uri.query = nil
  uri.to_s
end

So now you’re ready to get started with the new Facebook API! This is still an early release, but I’ll be working on it a lot in the coming months, partially as preparation for my talk at RailsConf in which I’ll be delving into the OAuth 2.0 specification and what it means for Rails developers in-depth. The code is, of course, available on GitHub where you can report any problems you run into. Enjoy!

Update: Those who aren’t terribly familiar with the protocol may wonder why OAuth 2.0 isn’t just rolled into support of the OAuth gem (or why I didn’t fork it and do it that way). Honestly, I would have liked to, but OAuth 2.0 is an almost entirely different beast than 1.0a and they share so little functionality that it would basically be two projects living under the same gem name. So that’s why!

Rack is the common Ruby web infrastructure powering just about every framework known to Ruby-kind (Rails, Sinatra and many more). Rack Middleware are a way to implement a pipelined development process for web applications. They can do anything from managing user sessions to caching, authentication, or just about anything else. But one thing that confused me for a long time: what’s the difference between a Rack application and Rack middleware? Both are ostensibly the same, something that responds to #call(env), so how are they different? Unlike Rack applications, Rack middleware have knowledge of other Rack applications. Let’s take a look at what this means with a few simple examples.

The simplest Rack application (in class instead of lambda form) would be something like this:

class RackApp
  def call(env)
    [200, {'Content-Type' => 'text/plain'}, ["Hello world!"]]
  end
end

Note that because the method required by the Rack specification is call and (by no coincidence) this is how you execute Procs and lambdas in Ruby, the same thing can be written like so:

lambda{|env| [200, {'Content-Type' => 'text/plain'}, ["Hello world!"]]}

This hello world app would simply output “Hello world!” from any URL on the server that was running it. While this is obviously simple, you can build entire powerful frameworks around it so long as in the end a request boils down to a status, some headers, and a response body. But what if we want to filter the request? What if we want to add some headers before the main application gets it, or perhaps translate the response into pig latin after the fact? We have no way to say “before this” or “after that” in a Rack application. Enter middleware:

class RackMiddleware
  def initialize(app)
    @app = app
  end
  
  def call(env)
    # Make the app always think the URL is /pwned
    env['PATH_INFO'] = '/pwned'
    @app.call(env)
  end
end

See the difference? It’s simple: a Rack middleware has an initializer that takes another Rack application. This way, it can perform actions before, after, or around the Rack application because it has access to it during the call-time. That’s why this works in a config.ru file:

run lambda{|env| [200, {'Content-Type' => 'text/plain'}, ["Hello world!"]]}

But this does not:

use lambda{|env| [200, {'Content-Type' => 'text/plain'}, ["Hello world!"]]}

Because the ‘use’ keyword indicates a Middleware that should be instantiated at call-time with the arguments provided and then called, while ‘run’ simply calls an already existing instance of a Rack application.

This is something that can be quite confusing, especially if you’re new to the Rack protocol, so hopefully this clears it up a bit!

Sometimes you want to write a batch of utility methods that can be accessed from a module for example Utility.parse_something(string) or any number of useful little tools for your application. Here’s a very clean-looking way to achieve it:

module Utilities
  extend self

  def parse_something(string)
    # do stuff here
  end

  def other_utility_method(number, string)
    # do some more stuff
  end
end

By placing "extend self" at the top of the module, you are telling it to include all of the methods defined on your module as class methods on…your module. Which means that you can now access them like other class methods! While there are other ways to do this, I think this is a very semantically clean way that gets it done quite nicely.

Update: And this is exactly why I post these Quick Tips, because sometimes there’s another solution that I hadn’t heard of! Using Ruby’s module_function you can achieve the same effect:

module Utilities
  module_function
  
  def parse_something(string)
    # do stuff here
  end

  def other_utility_method(number, string)
    # do some more stuff
  end
end

The module_function method either takes multiple symbols as arguments for the methods to turn into module methods or, if invoked without arguments, will cause all subsequent methods to be defined as module functions. You can read the Ruby documentation about it here. Ultimately I’m not sure which I’d go with, as module_function is pretty esoteric (I’ve never come across it in code that I’ve read), but so is extend self. It’s your call, developers!

This week on the Intridea Insider, meet Brendan Lim, our Director of Mobile Development.

If you're a member of the Ruby on Rails or Mobile Development communities, chances are you've heard of Brendan Lim. He started his career off with a bang after creating Yappd (a Twitter clone with pictures) in 2007 with Brent Collier. Soon after Yappd was acquired by his former employer, Kajeet, Brendan met with Dave Naffis, Senior Partner at Intridea, and began working with the Intridea team after his obligations to Kajeet had been fulfilled.

His last two years at Intridea have not been quiet. He started by helping out with client projects, but his talent for coming up with and creating applications was quickly noticed. Brendan always has fresh ideas and can quickly transform those ideas into working applications. His first endeavor in mobile development with Intridea was to create a mobile version of Present.ly, our microblogging application. Since then he has created several mobile applications, including three apps to help you find the best Curry (iCurry), Pho (iPho) and Sushi (SushiMe) food anywhere using your iPhone.

Brendan's Car Finder app, which makes brilliant use of augmented reality, garnered attention from sources like Wired, boingboing, and Cult of Mac. Time recently mentioned Car Finder in their "10 Tech Trends for 2010" article. And most recently, Brendan created Grub.it, an application to help users find top-notch dishes at their local restaurants, with fellow Intridean, Pradeep Elankumaran.

I asked Brendan how he comes up with product ideas and how those ideas evolve into applications: "Almost every idea I've come up with has been a result of needing a solution to a problem that wasn't already solved, or because I thought I could accomplish something better. For example, the idea for Grub.it surfaced because we wished we could find the best hidden meals in every town. And we came up with Yappd because we wished Twitter had better photo integration at the time." He credits his girlfriend, Edel, with supporting his new app ideas and acting as the first beta tester for most of his applications.

Brendan has been building quality applications at Intridea for the past couple of years, but he has always been gifted with ingenuity. As a young teenager he was heavy into gaming; after his brother introduced him to HTML and web design he created video game review sites like, N64Xtreme and VGamers.com. "I would contact the PR departments of video game publishers and ask to review upcoming titles. I remember for the Nintendo 64, I bought one game and ended up with 50."

Most high school gamers have only dreamt of being able to review games in order to support their gaming hobby. But then Brendan took it about ten steps further when he met some of the people from Gamers.com and was offered a job managing video game pages for several platforms.

Along with his many computer-related hobbies, Brendan was also into video production as a teenager. As a freshman in college, Lexus paid him to make a video of their driving school. You can see some of his recent videos on Vimeo, including this one called Insomnia. He is also a talented photographer, which is a hobby that started with an interest in automotive photography and has now lead to landscape, city, creative, and portrait photography.

Although Brendan was a typical "geek", only several of his close friends were privy to his computer-related hobbies. I asked him why his geekery wasn't made public, and he explained, "I wrestled and played a little football in high school. I'd hang out with my friends for a bit but as soon as I came home I would just stay on my computer. It was where I was most comfortable".

Brendan entered Auburn University in Alabama as a pre-med student, but quickly realized that it wasn't for him. The school had just received funding from the owner of Verizon to start a software engineering program with a focus on wireless technology. The Wireless Software Engineering program was a perfect fit for him, considering his computer background and his love for collecting tiny, unlocked cell phones from overseas.

While Brendan was studying full-time at Auburn University he also had a lot of jobs. "I spent more time working and doing projects than I did studying. I liked teaching myself how to learn new languages by making things on the side." He loved creating solutions to problems even back then: "I created a Rails app for school called Notefad that allowed my friend and I to share and edit notes during class. I'd be terrified to look at the code now, but it was fun and actually helped us out."

But he didn't just create apps to meet his needs as a student; in fact, he built several applications with his friend while he was in college: "We started Freebielance, which was similar to eLance. We also did CheckoutSource which we were developing as a payment gateway. That didn't work out too well. We built it all out, applied for a merchant account, and then realized we couldn't afford it!"

Now, as the Director of Mobile Development, Brendan gets the opportunity to come up with lots of product ideas and to work on apps for several different platforms. Although Brendan started using Rails while he worked at Kajeet with Brent, he now finds himself using a lot of Objective-C, which he claims to love; "I'm actually a big fan of Obj-C. Although, for our client work we're using Appcelerator's Titanium platform. It allows us to develop iPhone and Android apps (fully native) using their JavaScript API. It definitely helps save time by letting us get apps out quicker for multiple platforms using a single code base."

Brendan has an intensity and energy about him that you can see in his work. He gets fired up about an idea and he executes on it flawlessly and without fuss. And when he's not coding like a ninja, or shooting video, or taking pictures, or relaxing in his new condo, then he's probably out giving presentations. "In the past month I did a talk at RubyConf India about MacRuby. I also did a talk at the MobileX Conference in Nashville on Building Native Apps with Titanium and gave the closing keynote. I'll be going to the MobileX Conference in Lexington this week and will be doing the same Titanium talk, an Introduction to Palm webOS talk, and the closing keynote again."

Of course, Brendan loves his mobile devices just about as much as he loves developing for them. I had to ask him what his favorite apps were for the iPhone and his new iPad. His list of favorites goes on endlessly, but he especially loves Keynote, "because I can work on my presentations from the iPad and actually show off my presentations on it. I actually had to do a whole talk using my iPad today at the Atlanta Mobile Devs Meetup because I couldn't find the projector!" He also really likes the Epicurious app, which aids him in his effort to cook more at home. The Eyewitness app is another one of his favorites, along with Netflix, Air Video, and Things.

Brendan recently purchased his first piece of real estate, a condo in the middle of Atlanta, which he shares with Edel. He set down roots in Georgia to be close to his family in Alabama. Although he has spent most of his life living in Alabama and Georgia, he did spend some time living in Indonesia and Hawaii as a young child.

Brendan is young but has already come across great professional success. He gets to wake up everyday in the city that he loves, and walk over to his desk in his loft to start work for the day. His ingenuity, raw talent and work ethic have brought him to where he is today: from a gamer hiding his geekery from his high school wrestling friends, to an accomplished Director of Mobile Development with Intridea. And we're lucky that Brendan loves us as much as we love him: "I love it at Intridea. I love the people I work with. It's like a family here."

This post is part of a weekly series, called "Intridea Insider"

Ruby Midwest is an upcoming two-day, single track regional Ruby conference taking place in Kansas City on July 16 and 17. Today they announced their speaker list (including our own Michael Bleigh, a Kansas City native) and we’re happy to blog about our involvement with the conference. Intridea is sponsoring OMGWTFBBQ, a dinner at the conference hotel with Kansas City barbecue open to all attendees after the first day of the conference.

Catering will be provided by Fiorella’s Jack Stack Barbecue (it’s delicious, trust us). So if you’re heading to the conference (with keynotes by Yehuda Katz of Engine Yard and Chris Wanstrath of GitHub) and you want to take a few hours, enjoy the best food Kansas City has to offer and socialize with your fellow Midwest Rubyists, RSVP for OMGWTFBBQ today!

More details will be announced as the conference draws near, but we’re looking forward to helping make Ruby Midwest’s first year a runaway success as a regional conference. See you in Kansas City!

Here is a quick tip for users who like the idea of using SASS-powered stylesheets, but may not want to bother setting up a development framework to do so.

A Really Quick Intro to SASS

If you’re not familiar, SASS (“semantically awesome stylesheets”) builds off your existing CSS knowledge, but tosses some dynamic spice into the mix. The result leaves you with increased power and flexibility as a coder/designer. An example of SASS in action looks as follows (compared to the equivalent CSS):

Note: refer to the post comments (below) for community feedback regarding recent updates to SASS syntax – some of the above code may be deprecated.

The result is code that is easier to read, takes up less space, and supports the very helpful nesting of styling rules. Another tremendously useful feature is the ability to use variables throughout all of your stylesheets — something that becomes invaluable when working on larger websites or applications. SASS also supports mixins, operations, and beyond — learn more at the SASS website, or by reading Michael Bleigh’s excellent SASS intro.

SASS with static websites, you say?

Until somewhat recently, I’d only used SASS when jumping in to help with design work on pre-existing, larger Rails applications. This works great, as the markup is already in place and changes are easy to make. My SASS experience in this regard has been a good one.

When coding a new, larger site from scratch, however, I’ve never found a satisfying approach to use SASS from square one. I’ve dabbled with a few different SASS-compatible static website frameworks (Middleman, StaticMatic, etc) — but never felt comfortable enough with these to full integrate them into the beginning of my HTML/CSS coding process. As such, my preference has remained: build the layout in static HTML, and when fully coded & styled, integrate into the Rails app. Sadly, SASS fell by the wayside too often with this approach.

But finally, thanks to the latest beta versions of the HAML/SASS gem, an accessible solution lies in wait. This setup will auto-compile your SASS into CSS whenever changes are made. Best of all, no additional framework setup or files are needed… just what I’ve been looking for. Make it happen as follows:

1. Install the latest HAML/SASS gem

When I discovered this technique, the latest gem was installed as follows:

gem install haml-edge

However, in the meantime there have been beta releases of SASS 3.0, which should achieve the same ends. install this gem as follows:

gem install haml --pre

If you’re curious if anything more recent has been released, check out the HAML/SASS blog.

2. Setup your local project directory

Do this however you like: I usually start with an index.html and fresh directories for stylesheets, images, and javascript. Populate with any templates/frameworks you may have, as desired. Just make sure you have a directory for you SASS files in place. Here is an absolute bare-bones version to show how this technique applies:

3. Summon the sass --watch kraken

Finally, from the command line, run this line to make the magic happen:

sass --watch path_to_sass:path_to_css

The path before the colon is wherever your SASS files are located… the path after the colon is where you want the CSS to be generated. Of course, your HTML should reference the location of the CSS files. Keep in mind: when styling this way, any changes you make to a CSS file will be lost if/when the SASS file is changed (the overwrite is automatic).

Also note that you will need to run this step each time you want to enable auto-compiling SASS. It will run in the background, and instantly take action if a SASS file has been changed:

And that’s it. Whenever you make changes to any SASS files in the directory you specified, the corresponding CSS files will be automatically updated (and created, if necessary). This lets you benefit from the dynamic nature of SASS without requiring any framework setup.

If you’ve begun to use CSS3 experimental features in your sites lately such as box-shadow, border-radius or text-shadow, you know how much pain it can take away from the design process. Unfortunately, lots of people are still using Internet Explorer and can’t see all these pretty additions you’ve added.

I thought it would be useful to have a simple way to run a sanity check on my design to make sure it wasn’t going to look awful or unreadable once all of the CSS3 goodies were taken away. With that in mind, I created a bookmarklet that will toggle the display of all of that modern goodness.

Just drag this link: Toggle CSS3 into your bookmark toolbar. Then, by clicking it, you can turn off (and back on) the most common CSS3 improvements. Once installed, if you visit a page such as CSS3.info and click the bookmarklet, you should see the CSS3 effects toggle off.

Note that this is a simple, none-too-bright bookmarklet and only removes the obvious traces of CSS3. It doesn’t inspect your CSS for non-supported color values (like RGBA) or deal with many of the more advanced features of CSS3. In fact, all it does is eradicate these styles:

• border-radius
• box-shadow
• text-shadow
• border-image
• background-origin
• background-clip

However, it’s still a useful tool if you’re designing for the future with an eye for the past. Enjoy!

This week on the Intridea Insider, meet Brent Collier, Senior Engineer at Intridea and unofficial Apple spokesperson.

Brent's Mom always worked in IT, so he had the advantage of being raised around computers from an early age. He grew up playing video games like RC ProAM and Gran Turismo. But his engineering skills were first born and cultivated through building with Legos, long before he ever touched a computer or gaming console. Like many software engineers he had a curiosity for understanding the mechanics of how things worked from a very young age. "I've always been into building and taking things apart. I like to know how stuff works."

Although Brent later enjoyed tinkering with hardware as a teenager, he entered VCU in Richmond, VA with the intention of studying art. "I did lots of drawing and a little sculpture as a kid but I quickly realized that there was no money in art and then moved to Mechanical Engineering." Mechanical Engineering was a natural choice for Brent since it coincided with his interest in building and fixing things. Eventually his passion for software development surfaced and he switched to Computer Science. He explains that although he had fun working with computer hardware, "I didn't really get into software as much until I was in college. I just didn't realize how much information about it was so readily available until then."

Armed with a CS degree from VCU, he went out into the world and claimed a Java job with a consulting company in Richmond. He wasn't in love with the client-focused world of consulting, so when a friend nudged him to interview with Kajeet, a mobile start-up in Bethesda, he jumped on the opportunity.

At Kajeet, Brent met Brendan Lim (Check back next week for an Insider post on Brendan). "We quickly became really good friends, and we used to sit around thinking up start-up ideas. Twitter was just starting to pick up in 2007 and it always annoyed me that you couldn't seamlessly upload pictures, so we ran with the idea and created Yappd. That was the application that got me started with Ruby and Ruby on Rails." So Brent and Brendan poured their energy and free time into building Yappd, a Twitter clone with pictures.

Yappd had incredible potential and quickly got press from sources like TechCrunch, Mashable and PCMagazine.com. Brent was thrilled about the possibilities for Yappd, but it was quickly acquired by his employer.

Brent started at Intridea with Brendan several months after Yappd was acquired. He was hooked on Ruby and didn't want to continue working in Java. He says that, "Java just felt crusty and gross" after working with Rails.

Since starting at Intridea, Brent and his wife Amy (whom he met while bartending at Bennigan's) moved from his home state in Virginia to the Raleigh/Durham area in North Carolina. They wanted to raise their two boys, Cameron and Dillan, in a safe and family-oriented location. He enjoys the lack of traffic congestion in Raleigh/Durham compared to the DC/MD/VA areas, along with the lower cost of living and the nicer people.

In the last year at Intridea Brent has worked on a multitude of projects, but his favorite was Earthaid, a home utilities monitoring service. "They monitor your usage and suggest ways to lower your energy consumption. It was a quick, somewhat small project, and we had a dedicated, full-time designer which makes any project better!"

When Brent isn't working on a development project or playing with his kids, or being a ninja with Brendan, he tinkers a bit with Obj-C and mobile development. He has done a little work on some Titanium projects and is looking forward to more. He proudly admits to having a love affair with Apple (which coincidentally began around the same time he switched from Java to Ruby), and wants to develop apps for Apple devices like the iPad.

I asked Brent if he has a favorite Mac app, and although he insisted that he loves all Mac apps, I did get him to suggest CloudApp: "One of my most recent favorites is called CloudApp; you just choose a file and drag it to the menubar then you get a link automatically copied to your clipboard. It's super useful and I probably use it ten times a day!" He advocates that CloudApp is much quicker than Skitch if you don't need to annotate.

Like many of Intridea's engineers, Brent gets to work from home. He prefers to work at his kitchen table with the house windows wide open and sunlight pouring in. He codes to trance or garage rock for inspiration and attributes AWDWR and The Pragmatic Programmer as the books that motivated him to be a great programmer. He is another example of how a childhood filled with Legos, video games and nurtured curiosity can result in future adult awesomeness.

This post is part of a weekly series, called "Intridea Insider"

The iPad has arrived, so let the design fun commence! Featured here is an iPad wallpaper template in Photoshop (PSD) format (download), allowing you to easily create & test your new background creations with minimal layer nightmares.

The PSD is setup to let you view a single wallpaper layer (or layer group) in several common scenarios:

As you can see, you'll need to take into account how the app icons, bottom dock, and lock screen UI will interplay with your wallpaper – while also throwing the orientation variable into the mix (horizontal or vertical). Before we dive in, here is a crash course on how iPad wallpapers work. Quite simply:

The coolest thing about this PSD template is that you can view a single wallpaper layer in four different iPad viewing scenarios – all with absolute minimum in layer visibility headaches. How it works:

First, open the attached Photoshop template and paste/insert your 1024x1024 wallpaper image into the "Wallpapers" layer folder. Ensure your image is perfectly aligned within the template guides. Note: you'll want to hide the "iPad" layer group so it doesn't get in the way.

Once your image is in place, make the "iPad" layer group visible again. Enable visibility in either the horizontal or vertical layer sub-group, and then make visible either the lock screen or home screen layer -- all of the above to suit your desire.

Voila! An iPad of your desired viewing scenario will be overlayed on top of your wallpaper. Next, you can simply hide/show layers within the "iPad" group to see how your wallpaper looks in different situations. You'll never need to move your wallpaper layer.

With any hope, this template will be of great service to you. Download the PSD here.

Finally, I must give acknowledgements to teehan+lax for their excellent iPad GUI PSD, which was a helpful resource. DigitalCitizen.ca also has a helpful article I used to learn up on the subject. Check out both of these sites if you want to read more. Otherwise, go forth and design!

Intridea founded and sponsors the DC Ruby Users Group, which has been a great success. Our monthly meetings average around 30 attendees, but some have had twice as many.

While I would not be so bold as to claim I've found the secret to successfully organizing and running a local Ruby Users Group, there are some things I believe have contributed greatly to our group's success:

1. Be welcoming and inclusive. It's a stereotype, but not one without some truth to it: a lot of techies tend to be introverted. At every meeting, I make it a point to ask who is at their first DCRUG event and welcome them. Furthermore, as responsibility-juggling allows, I also try to greet attendees at the door and introduce myself. Invariably, some folks will sit quietly, keep to themselves, and leave after the lectures — but I hope they leave with a desire to attend again, perhaps even as a presenter.
2. Appeal to multiple levels of skill and experience. At recent meetings, a show of hands has indicated that about half the attendees are not experienced Rubyists, and are looking for a chance to learn introductory concepts. An advanced topic would be overwhelming. At the same time, our core group of Rubyists want to learn more about these advanced concepts. Our solution: make sure that each meeting has at least one talk that appeals to newbies (e.g. "Intro to Rails models") and one that will interest experienced Ruby developers (e.g. "Background Jobs with Resque").
3. Cover a variety of subjects. Our talks on cutting-edge technologies like MongoDB and XMPP have been great, but not every talk needs to be software-related, or even technical. Two of our most popular presentations have been regarding legal issues that affect software companies and tips on how to give great presentations.
4. Meet on a consistent basis. We hold our meetings on the second Thursday of every month (except when a record-setting blizzard makes travel impossible). This makes planning simpler and the predictable timing helps attendees leave room in their busy schedules.
5. Don't "reinvent the wheel": use Meetup.com . Initially, we used a homebrewed system for scheduling DCRUG meetings, but then realized it would be more efficient to leverage the work Meetup has already done. They are completely focused on making it easy to organize gatherings and we've been quite happy with the service.
6. Publicize through various channels. Don't wait for them to come to you! Meetup now has a nice feature that lets attendees cross-post their RSVP to Facebook and/or Twitter. Additionally, DCRUG has its own Twitter account and we cross-promote to other groups nearby, such as the ones in Northern Virginia and Baltimore.
7. Make yourself a checklist Seriously, even for an informal meeting, there are so many moving parts — lining up speakers, coordinating with the hosts, ordering food, publicizing the event, thanking the appropriate people, etc. — that you'll invariably forget something. I create a bulleted list in Google Docs and, after each meeting, simply make a copy of that document for the next DCRUG, editing as appropriate.
8. Location, location, location! We have been fortunate enough to have StreamSage allow us use of their sizeable and Metro-accessible space, for free. This, alas, is easier said than done, but not impossible. It is crucially important that you find a meeting space that is conveniently-located for your attendees, or they will be far less likely to attend.
9. Follow up each meeting with a get-together Ruby user groups provide not just an educational opportunity, but a social one as well. After every meeting, we head to Post Pub, a bar located a block away. Many folks go with soda as their drink of choice, but this isn't about getting a buzz. Rather, it's a chance for attendees — presenters and audiences — to socialize in an informal environment and talk anything, Ruby-related or otherwise, with their peers.
10. Free pizza and soda! It may sound silly, but is surprisingly effective. Our meetings start at 7pm, which means many attendees come straight from work and are hungry. Prior to the first presentation, the boxes of piping-hot Domino's pizza and cold soda at the back of the room serve as a place for attendees to congregate and chat, instead of just sitting in their chairs, waiting for the meeting to begin.

For those of you looking to start a local Ruby Users Group, I hope this helps you kick it off successfully. For folks who are looking to improve an existing one, I hope you find this helpful. And I hope everyone will come by and check out a meeting of the DC Ruby Users Group.

RubyNation has been a leading event in the Washington DC and NoVA Ruby community for the last two years. This year, Intridea is proud to be a Gold Sponsor of the sold-out event.

Prominent and influential Rubyists such as Jim Wierich, Dave Thomas, and Gregg Pollack are on the speaker lineup, as well as Intridea's own Michael Bleigh and Jeremy McAnally. Michael will be giving a talk on persistence options for web applications, "Persistence Smoothie: Blending SQL and NoSQL in Ruby Applications". Jeremy will be talking about Rails 3 in his presentation, "Rails 3: Living in the Future".

We are excited to be a part of this annual event that promotes Ruby and encourages collaboration within the Ruby and Ruby on Rails community in the DC area and beyond.

We are very excited to announce the “Intridea Insider”, a new blog series that will profile a new Intridean every week. Check in every Thursday morning to get a detailed interview with a team member, and discover everything from their favorite gems and productivity apps to their favorite coffee spots and blogs. 

This week’s featured Intridean is Joe Grossberg: 

Like many geeks, Joe grew up liking dinosaurs and computers. It wasn’t until he met the web in 1994 though, that he had a real reason to favor one over the other. His love affair with the web started with a very simple menu option: View > Source. Being able to not only visit a website, but also see how it was put together and then tinker with it was a powerful opportunity. For Joe, this plus the combination of HTML being pretty simple to learn meant that, “Wouldn’t it be cool if I could ...” was replaced by “Look at all the cool stuff I can do ...”

Unlike many formally educated CS students who find themselves in software development positions, Joe took a roundabout path to his Senior Engineering position at Intridea. Joe was interested in programming since dabbling in LOGO and BASIC as a kid, but he studied Anthropology and Journalism in college, and after graduation he worked at an Advertising & PR firm. His software engineering future was instantiated in 1999 when he was able to transition to the New Media department at the firm to build websites. From there, Joe encountered endless opportunities to learn and use other technologies like CSS, JS, ColdFusion, Perl, PHP, ASP, JSP, Python, and of course, Ruby and Ruby on Rails. Before joining the Intridea team, Joe was working on one of the largest Rails applications to date, at Revolution Health in DC. 

When asked if he ever feels he is at a disadvantage to formally educated web development professionals, he answers, “Well it's a question I've been asked before, and I say no, for two reasons:

• I work with high-level languages and almost never find myself saying, ‘I wish I could do this in C’.

• In my 11 years of experience, I’ve seen very little correlation between the education level and quality of a coder.

Being self-taught requires motivation, discipline and a love of learning and Joe certainly has all three. He reads all the time and has used bloggers as “substitute mentors” throughout the years. He looked to blogs like Joel on Software, “when it was still good” he says. “They gave me insight into what much more experienced and practiced developers were doing.” Nowadays he enjoys reading blogs like A Fresh Cup, because it gives him quick access to good information: “Mike Gunderloy does such a great job of tracking down and compiling links to cool stuff out there, saving me the trouble of doing so.” 

As far as development tools are concerned, Joe is an emacs user through and through. Being able to learn all the emacs tricks from a senior developer he used to work with prompted him to adopt this as his editor of choice early on. “I’m old school,” Joe admits after explaining why he stuck with emacs even while many of his peers were swooning over TextMate. “Any editor being proprietary and tied to a single OS was a non-starter for me. And I figure emacs was here before I started programming; it'll be here after I retire.” 

Joe spends a lot of time in script/console and cites the under-appreciated Wirble as a favorite gem. His .irbrc, along with other configuration files, are available on github. “One thing I like about hacking is the ability to customize the environment to meet my own needs.”

When I asked Joe what he loves most about Ruby, he began talking about the Ruby “ecosystem.” We talked about the passion for quality code that so many Rubyists seem to share and how that creates a unique ecosystem. “Ruby seems to have a greatly disproportionate number of people who really do 'give a shit'; their opinions can and do clash, but they have them and they care about them.” Joe identifies “The Pragmatic Programmer” as the book that inspired him to approach writing software as a craft. He says it gave him the realization “that it’s worth being great at software development, that things like quality matter, and that it’s worth investing in learning.” 

Joe cites the DCRUG, an event he helps to organize, as an example of how diverse and remarkable the Ruby community is; “People come from everywhere to do presentations. They care so much about what they’re working on that they will travel to another city just to share it with other geeks.” 

While Joe Grossberg sounds a lot like the quintessential Rubyist, there are some things you might be surprised to know. For example, Joe is not a testing fanatic. While he sees lots of value in testing, especially on large-scale projects with a multitude of developers, he says it’s all about the end-user. “Let’s be honest; it’s not like software was all broken and unusable before the testing/TDD/BDD meme became big.” He reasons that while testing “increases quality in multiple ways, the difference between 99% test coverage and 100% coverage is probably not what’s going to make-or-break your application.” He believes that tests are most valuable, however, when you’re working on someone else’s code; tests provide a safety net and “make legacy code less dastardly.” 

Another interesting trait that distinguishes Joe from most programmers is that he is not a caffeine junkie! Instead of reaching for coffee when he gets tired and hits a lull he changes focus by going to the gym, reading blogs, or opening a book. In fact, the gym has played a big part in changing Joe’s life in the last couple of years. He has shed almost 90 lbs by diligently working out, cooking healthy meals at home (his site is the #1 result in Google if you search “how to make curry”) and getting fitness advice from sources like his favorite fitness blog, Mark’s Daily Apple.

Most Intrideans work from their home offices and are spread out across the country. But Joe lives in DC and actually prefers to work in our office. He likes having the ergonomic chair and a real desk setup with wireless keyboard and mouse, without the distractions of a coffee shop and the clean separation between work and home. He enjoys a casual, five block walk to the Intridea office; as he walks by the gridlocked traffic each day, he is reminded of how grateful he is that he’s been able to “opt out of that life.” Joe wants to work in the office, so he does. “But I also realize that’s not for everybody”, he explains. “To me, that’s one of the best parts of working at Intridea -- the flexibility. None of this 'one size fits all' nonsense like ‘everybody pair programs all the time’.”

Joe is an insanely talented developer as a result of his determination and love of learning. At Intridea, we are pretty happy that he chose computers over dinosaurs.

When Joe is not working at the Intridea office in DC, he spends time with his wife, Salem, whom he speaks of with the highest regard. “She’s my favorite person in the history of the world. She’s brilliantly smart and she loves learning.” Joe and Salem met on the internet and were the JDate Success Story of the month recently. They also have two adorable cats, Miju and Peeps.