• Read more about One Time, At RailsCamp

Last month Intridea sponsored RailsCamp New England - a Rails retreat in the western mountains of Maine. Adam and I attended the event for the second time (this was the fourth U.S. Rails Camp, and the second one in Maine) along with 38 other Ruby and Rails developers. On a rainy Friday evening we all settled in the cozy Maine house for a long weekend of geekery.

Ben Askins started the RailsCamp movement in Australia in 2007 and with the help of Pat Allan's enthusiasm, RailsCamp took off! In 2009 Pat and Brian Cardarella worked together to bring the tradition to the New England area. In the last five years RailsCamps have been organized throughout much of Europe, the UK, Australia and the eastern side of the U.S.

The spirit of RailsCamp is simple - bring Rails devs to the backcountry, isolate them in a house for a long weekend, and watch what happens. There is a local network for sharing resources, and a local server with a mirror of RubyGems. If the idea of limited access to the internet and modern amenities causes you alarm, do not fear - it's not a Luddite conversion retreat. Though the setup seems primitive it is actually quite intimate and inspiring. The isolation removes most non-programming-related distractions, and the relaxed environment is conducive to epically long hack sessions. So what does happen when you throw 40 programmers in a house together without internet?

We hack. We collaborate on projects. We share information and tools. We get feedback on our code. The veterans share the experience they've gained from decades of programming. The shy ones hack in quiet corners and observe and absorb the information that's being shared. We share meals, enjoy evening beverages together, fight for our lives in fireside games of Werewolf, swim under a sea of stars in a cool lake, and flex our gamer cred in fast-paced rounds of Urban Terror.

This year we even produced something other than code! Pascal Rettig brought along a Thing-O-Matic, a personal fabrication machine, which we used to make 3D plastic RailsCamp logos. As we all geeked out over this I marveled at how the reaction to creating a tangible item was as thrilling for us as creating applications. I thought more deeply about the similarities between manufacturing and programming, so look for that post in the near future!

As the Rails community continues to expand and evolve rapidly, its conferences have become increasingly monolithic. While the larger conferences still have a tremendous amount of value, it's nice to have events like RailsCamp, where there still exists a profound intimacy among coders. For a passionate Rubyist it doesn't get much better than a laptop, a local gem repository, good food, games, and a cabin in the woods with a group of other passionate Rubyists. It's the stuff geek summers are made of. You can view additional photos on our Flickr page!

• Read more about The Asset Pipeline and Rails 3.1's Post-Modern (Post-Apocalyptic?) Present

My Twitter stream is abuzz today with the release of Rails 3.1. (You can view the Rails 3.1 Release Notes here). But of course, as the Rails community is comprised of an alarming level of passionate developers, a few diva-style outbursts are in the forecast. Though most of the responses are celebratory there are pockets of people reacting as though they are 5 years old and being forced to eat lima beans by their mothers. But unlike your mother, the Rails Core team isn't forcing you to eat anything. In fact, those who oppose the addition of CoffeeScript and SCSS can circumvent the changes in one step.

Most of the outcry was unleashed when DHH announced in April that CoffeeScript and SCSS would ship with Rails 3.1. CoffeeScript is a whitespace sensitive and expressive language that generates readable JavaScript code. SCSS is the new Sass syntax, and is an extension of CSS3. People have had some time to adjust to the idea since the announcement was made, but that hasn't stopped a vocal few from throwing a temper tantrum about it today. People can argue about its inclusion in Rails 3.1 for the next year (and they will) but what really matters is that the Rails contributors continue to identify and implement libraries and tools that advance Rails and make it more accessible.

Rails 3.1.0 introduces many changes, most of them widely anticipated by the community. The addition of jQuery was one of them and replaces Prototype as the default JavaScript library. jQuery was a crowd favorite since Prototype was more verbose and required the developer to keep track of more variable types. jQuery is more concise and most of its users boast a faster and more pleasant development experience. The addition of CoffeeScript and SCSS though, was not so widely celebrated.

Brent Collier, one of our Senior Engineers was put off by the growing negativity about the Rails 3.1 changes in his Twitter stream:

I don't understand the people complaining about the asset pipeline in Rails 3.1. I mean, if you don't like Sass/CoffeeScript, that's fine. You can still write normal CSS/JS. The only difference is that it goes in app/assets instead of public. It doesn't require devs to do anything different, other than putting files in a different directory. Yeah, 3.1 includes sass-rails and coffee-rails by default. If that ruins your day, you've got bigger problems."

Michael Bleigh feels that in debating CoffeeScript and SCSS in Rails 3.1 we're forgetting the important truth, which is that the asset pipeline is simply amazing:

Forget the drama about SCSS and CoffeeScript, the real story here is that Javascript and CSS are now first-class citizens in a Rails application. The ability to seamlessly integrate asset files from gems is going to change everything about how we build Rails applications.

Before the asset pipeline was announced, I was getting worried about the future of Rails. I saw that the future was to have much richer client-side language support, and Rails didn't necessarily do much to make that easier. Now I can't imagine using anything but Rails for a modern web app. As far as I'm concerned what Rails has done with the pipeline is a huge and important step towards keeping Rails on top for years to come.

Not liking SASS and Coffeescript just seems so pale in comparison to the awesome of first-class assets that I don't even know what to say.

Fortunately, despite some pockets of angry tweets, most people are expressing their gratitude to the Rails 3 team for their hard work. You can follow the stream of Rails 3.1 related tweets here.

Although we tend to be overly opinionated about our methodologies and tools, we're also adept at putting aside our differences in the spirit of ushering in intelligent progress. Today we're #rubythankful to the dedication of the Rails contributors who have worked diligently to make Rails the competitive framework that it is today. As Ruby and Rails devs our programming livelihood depends on Rails' ability to stay competitive and relevant in today's world. So we're offering a big thank you to those who have helped to support the language, the framework, the assets, and the community.

Maggie, our QA Manager recalls a chant her Mom would lead at the lunch table in her daycare when the kids turned up their noses at the food:

"YOU GET WHAT YOU GET AND YOU DON'T PITCH A FIT!"

All together now...

• Read more about Intridea Supports Mobile Development Education At Mobile UX Camp

This year we're proud to be a Platinum Sponsor of Mobile UX Camp DC, a mobile technology themed BarCamp. The event is supported by other leading technology companies and will be attended by mobile application developers, content writers and marketers, and others that want to gain an understanding of entrepreneurship and innovation in the mobile space.

Intridea has been developing elegant mobile solutions for high-profile companies like Mashable, Oracle and Mitsubishi for the last several years. We work closely with clients to create meaningful, intuitive, and seamless experiences for their mobile users. We have gained insight and experience into the cutthroat world of mobile development. That's why our UX/UI and Mobile Engineering teams will be at Mobile UX Camp this year to participate in the event and share their experience.

Mobile UX Camp is sold out, but you can still sponsor the event (or get added to the waitlist). If you're already attending the event, be sure to swing by the Intridea Room to say hello throughout the day. You won't want to miss our 45 minute presentation starting at 3:00pm:

You got Mobile in My Desktop: How Mobile Devices are Changing our Interactions With the Web

Modern mobile devices (smartphones and tablets of course) have been teaching users new ways of interacting with data. For the first time since the introduction of the point and click interface 30 years ago, users are interacting with a computer in a brand new way. The mouse is becoming an artifact, and so its usage patterns are going the way of the dodo and the light pen. Hear about how the computer in your pocket is informing the computer on your desk, and why the days of designing for one or the other are rapidly coming to a close.

From our open source development, speaking at conferences, teaching classes, and sponsoring local and national user groups and tech conferences, we are always looking for ways to support the community that we live, work and play in. We're excited to be at Mobile UX Camp this year to interact with the mobile community as they explore new ways to push the mobile space forward.

• Read more about Hire a Guard for Your Project

Of all of the new tools that I've picked up using for development in the past six months, there is one that has come to stand above the others for its nearly universal utility. That tool is Guard.

Guard is a RubyGem but don't let that fool you into thinking it's only useful for Ruby projects. Guard is essentially an autotest for everything. It provides a general purpose set of tools for watching when files are changed in your project and taking action based on it. You can use it to do just about anything, but common uses will include:

• Re-running automated tests after a file changes.
• Automatically compiling scripts or assets for a project (e.g. minification).
• Installing new dependencies that may be added to the project.

With a little creativity and a slight bit of Ruby coding, though, you can make your entire project's workflow run smoother and faster. It's like having a telepathic robot buddy who just goes around doing whatever you were about to do next without having to be told (except the first time).

Getting Started With Guard

Guard requires a basic Ruby setup. Once you have Ruby and RubyGems installed, simply run:

gem install guard 

This will get you started. If you want to make it easier for others to run your guards as well, you should also install Bundler to encapsulate the different guard gems you'll be using:

gem install bundler 

Once you have these installed, in the root of your project run:

guard init 

This will initialize a Guardfile in the project root that will be telling Guard what to do going forward. From here, you will want to install some of the Guard extension gems that let you quickly create automation for your project. Some of my favorites:

• guard-rspec: Automatically run RSpec tests based on easy-to-customize patterns. I use this on almost every Ruby project these days.
• guard-coffeescript: Compile Coffeescript into Javascript lickety-split. Even though Coffeescript has its own automatic build command with the -w option, I prefer Guard because it lets you define the configuration once and, in addition, run a single process for all of your project's automation.
• guard-process: This is the guard for anything they haven't made a guard for yet. Using this you can quickly and easily run shell commands as soon as files change, giving you the ability to do almost anything.
• guard-sass: Never write vanilla CSS again. Using Guard SASS you can automatically compile SASS giving you the full power of mixins, variables, and more for all your styles.

There's a full list of guards that include all kinds of magic (there's even guard-livereload that can automatically refresh your browser whenever you make a change to a project), and it's dead simple to create new Guard libraries if what you want isn't available (or you can just use guard-process).

Standing Guard

For any of the Guard gems you install, you can add them to your Guardfile by running:

guard init guardname 

Where guardname might be rspec or coffeescript, etc. That will fill your Guardfile with a basic implementation of the given guard and is usually enough for you to tweak the settings to your liking without further documentation.

There's a great example of using Guard for a big Rails project, but I'm not just using it for Ruby. I've used Guard on jQuery plugins, Node.js projects, even static websites that I've been building (more on that a little later).

To make it easier for others to jump into your project with Guard, it also helps to use Bundler to maintain a Gemfile that points to the various guards you're using for the specific project. Just run bundle init to get Bundler up and running then edit the file to look something like this:

source 'http://rubygems.org'  gem 'guard' gem 'guard-coffeescript' gem 'guard-process' 

Then run bundle install. Once your gems are installed and you've set up your Guardfile, just run:

bundle exec guard 

Guard will start up right away and your project now has some smooth automation action. Guard will even reload itself if you modify the Guardfile, so feel free to tweak as you go!

Guard in the Real World

I'm going to post just a couple examples of Guardfiles I've been using in my projects recently to give you an idea of its versatility.

Guarding a jQuery Plugin

Here's the Guardfile for Sketch.js, a jQuery plugin that I just released:

# Automatically build the source Coffeescript into the lib directory guard 'coffeescript', :input => 'src', :output => 'lib', :bare => true # Also automatically build the test Coffeescripts guard 'coffeescript', :input => 'test', :output => 'test', :bare => true  # Run Docco  guard 'process', :name => 'Docco', :command => 'docco src/sketch.coffee' do   watch %r{src/.+.coffee} end  # Copy the newly created lib file for minification. guard 'process', :name => 'Copy to min', :command => 'cp lib/sketch.js lib/sketch.min.js' do   watch %r{lib/sketch.js} end  # Use uglify.js to minify the Javascript for maximum smallness guard 'uglify', :destination_file => "lib/sketch.min.js" do   watch (%r{lib/sketch.min.js}) end 

This enabled my workflow to be instantaneous: I could immediately look at my work whether it was in my examples, my tests, or my documentation. Everything was immediately built and I never had to slow myself down with run and refresh cycles.

Guarding a Node.js Project

I've probably only scratched the surface here, but a simple Node.js project that I'm currently working on has this for a Guardfile:

guard 'coffeescript', :input => 'src', :output => '.', :bare => true  guard 'process', :name => 'NPM', :command => 'npm install' do   watch %r{package.json} end 

Notice that using guard-process I'm automatically installing new dependencies that may arise when the package.json file is altered.

Guarding a Static Website

I've come to really appreciate both Coffeescript and SASS as worthwhile abstractions, so even if I'm building something that's vanilla HTML I might have a Guardfile like this:

guard 'sass', :input => 'sass', :output => 'css' guard 'coffeescript', :input => 'coffeescripts', :output => 'javascripts' 

These are all basic examples, but that (to me) is the point: Guard is so simple to use and basic that you can drop it in every project you build. I've yet to run into something that I don't want to use Guard on.

Tip of the Iceberg

I've been expanding my usage of Guard into, well, everything that I'm working on. Thus far it's included Ruby, Javascript, and static HTML projects, but if I move on to other things Guard will be coming with me. For instance, I'd love to build a Guard to automatically recompile and run an Android application whenever the XML views change. The possibilities are limitless.

If you're not using Guard, give it a try on one of your current projects. I think you'll quickly find immense satisfaction in being able to simply cd into the project directory, run guard, and know that you are completely ready to roll. I'd like to see a Guardfile in every open source project I fork, every client project I clone...Guard is so useful that I simply want to be using it all the time. And that is the mark of a great tool.

• Read more about Intridea Places Among The 500 Fastest Growing Companies In America

Four years ago, what started as a team of three people with a conviction to create an agile, modern web development company has evolved into one the largest and most successful Rails development shops in the country. Today we are a strong team comprised of nearly 50 developers, project managers, QA engineers, and innovators. Making the Inc. 500 list is an honor; it is satisfying to rank as one of the fastest growing companies in America!

Inc. lists us at #335 in the top 500 list, and places us at #33 for our industry and location. This means that we are the 33rd fastest growing privately-held software company in the United States! See our full Inc 500 profile here.

Inc. 500

What does it mean to be an Inc. 500 company? Jane Berentson, Editor for Inc. Magazine explains:

“The list debuted in 1981 as a ranking of the 100 fastest-growing private companies in the U.S. The following year, it expanded to the Inc. 500 and, in 2007, we inaugurated the Inc. 5000. Through each evolution, Inc. has sought to recognize and to celebrate the creativity, dedication, and hard work that entrepreneurs put into building their companies.”

Many of America’s most iconic companies have graced the Inc 500 list including Microsoft, Oracle, Zappos, Patagonia, E*Trade, Intuit and many others. We are honored to share Inc 500 status with such an elite group of successful companies that went on to revolutionize their own industries. See our statistics from Inc. 500 below:

Thanking the Academy

We are thankful to our talented and fiercely dedicated team, the hundreds of clients whom we have created lasting relationships with, and the Ruby and Rails communities. Despite the relative infancy of the language and framework, the demand for Rails development has been extraordinarily high. As a result, we have been able to thrive even in a declining economy.

The Rails ecosystem is made up of hearty and enterprising engineers who are continually creating open source plugins and gems, documentation, and patches, ensuring that we can all have a future working with the language that is beloved to us. The community is a beautiful reflection of our collective desires to pioneer the web application development landscape. If you look at the advancements that have been made in just a few short years, you’d think that Rails developers don’t sleep. In fact, we’re not sure they do.

What’s Next?

Our path to growth, though rewarding and thrilling, has not been effortless. In four years we’ve worked day and night to stay on top of things and to breathe life into our vision. It’s nice to be one of the 500 fastest growing companies in America, but it doesn’t change anything for us – every day we each still sit down and write the best code we can, deliver the most elegant solutions to our clients, learn everything we can in the process, and give back to the community that we are a part of. So what is next? More satisfied clients, well-implemented web solutions, happy engineers, and more open source contributions. Our work is fun and rewarding, and that’s what it’s really all about.

• Read more about Sketch.js: HTML5 Canvas Sketchpads for Whyday

Last Friday I decided to celebrate _whyday by taking a departure from my normal open source path and writing some Javascript (well, technically Coffeescript). So today we're announcing Sketch.js, a simple jQuery library to enable HTML5 Canvas "sketchpads" for any web application.

Quick and Easy Doodling

Sketch.js allows you to initialize a canvas element as a sketchpad as well as draw with different colors, stroke sizes, and tools (currently only a marker and an eraser). These tools can be accessed programatically or using special links with data attributes. Here's a basic example:

<canvas id='mysketch' width='400' height='300'></canvas>  <script type='text/javascript'>   $('#mysketch').sketch(); </script> 

That's all there is to it! The canvas will now be drawable by your users and, thanks to a relatively straightforward API, you can customize it to your heart's content.

The HTML5 Canvas element is extremely powerful but it can be a bit daunting to get started. I took this as an opportuntiy both to learn it some myself and to provide a drop-in tool for others. Hopefully you find it useful!

Learning on Whyday

I set out on Whyday with the intent of learning a few new tricks. Here's some new things I tried out:

1. Sketch.js is coded in Coffeescript. I had used Coffeescript before but never its class system or more advanced features. I like it!
2. It's documented using Docco which has been one of the most straightforward and pleasant documentation experiences I've ever had. It also, as an annotated source engine, encourages clean source code.
3. I set up an awesome instant build environment that uses Guard to compile Coffeescript, generate docs with Docco, and minify the JS into a build directory. The workflow worked really well.
4. I tried to do a very little bit of unit testing using QUnit, which was my first major foray into Javascript testing. Unfortunately, with how much I was learning about Canvas at the same time, I didn't keep at the testing as much as I would have liked.

All in all it was a great chance to sharpen my skills on something that I hadn't had a ton of experience with. You can see the docs (and live examples) on its GitHub pages or visit the code on GitHub. Enjoy!

• Read more about What's Wrong With Patents? It's Obvious.

Patents are in the news in the tech circle more and more these days. As trolls lurk under bridges and the portfolio cold war gets hotter and hotter, everyone is talking about the fact that something is wrong. What exactly that something is, however, is up for debate. Should the patent system be abolished? What about just software patents? Is the term too long? I don't know, maybe. But one of the primary issues, from my view as a web startup developer, is that what's obvious isn't really so obvious anymore.

Patents were established as part of a way to codify the Constitution's Copyright Clause attempting to promote science and the "useful arts." They grant a limited term of exclusivity for inventors in exchange for publishing the means to reproduce the invention. In theory, this is a win-win: the inventor gets to make money off of their invention and the public gets to know how it's made. Other individuals or companies can even license the right to reproduce the invention before the patent has expired so it may reach even more people than it would otherwise.

I'm not going to get into arguments about whether or not the patent system as a whole encourages innovation in modern times. However, one of the requirements of getting a patent is that it not be obvious to "a person having ordinary skill in the art." I believe that this requirement is no longer adequately strict for patent issuance due to three fundamental differences between the establishment of the system and today's field of "inventors": population, communication, and specialization.

Matters of Population

There are more than 300 million people in America, more than 100 times as many as when the country was founded. That means that for any given "art" there's a great number more people in any particular field than there used to be. So how does this affect obviousness?

If eight people out of ten couldn't figure out how to do something, maybe it's reasonable to let the one out of two that figured it out first get a patent on it. That incentivizes the two that can figure it out to figure it out because there's a real chance that they'll break ground first and make some money off of it.

So let's increase the field's population a bit. Now let's apply the same ratio to an invention but there's 1,000 people in the field. That means that 800 out of 1000 would find it non-obvious, but 200 out of 1000 would. A person of "ordinary skill in the art" still would allow the patent to be issued, but now we're talking about 200 separate people who would find it obvious. This isn't inherently a problem if all inventions existed in a vacuum, but most often patented ideas (especially in software) represent only part of a larger vision or system. That means that because one out of 200 people happened to register for a patent first, their larger system is in the clear while 199 others that could be solving totally different problems but using the same invention as a part of their larger vision are now in jeopardy of owing licensing fees or being barred from pursuing matters entirely.

In modern America any given field will have tens of thousands of people all working, collaborating, and inventing. To posit that the standard by which exclusive, multi-year rights to something should be given to something that's non-obvious to the average person doesn't ring true. It should be something unique and groundbreaking enough to be non-obvious to the vast majority of people in the field. To merit exclusivity, it should be something so beneficial that the inventor would fight tooth and nail to keep it secret were the advantages of patents unavailable. Instead, hundreds of patents are issued for mundane, completely foreseeable advancements in the art. Just because something is non-obvious to most people doesn't make it a breakthrough invention.

Proliferances of Communication

Can you even imagine how things must have worked back in the late 18th century? What would it have been like to be a scientist, a researcher, an inventor? Compared to the always-on global communications networks that researchers, engineers and inventors have today it's an entirely different world. Lots has been written about how the world is "shrinking" as both travel and communication between disparate places becomes easier and easier, and the same goes for the inventive communities who are churning out patents.

This readily available communication has the effect of making all participants in a field effectively smarter than they would be otherwise: if I don't know how to do something, I can just Google it and now I do. This has implications again for the consideration of the "obviousness" of patents. Are many of the things patented today non-obvious to a person of average skill in the art with access to the internet? I'm not so sure.

Especially Specialized

Over the course of our society's development we have gone from an agrarian society to an industrial one and now to an informational one. The level of specialization found in the modern creative force makes it pretty difficult to tell exactly who should be considered a person with "average skill in the art." As a disclaimer, I'm not actually sure how the courts currently make such decisions, but it surely is a more complicated question than it used to be. Where do we draw lines of separation for the "arts"?

Is the peer group for a new mobile device patent other mobile device engineers? Is it other device engineers? All electrical engineers? I'm not honestly sure how you would draw that distinction and where you draw the line will drastically effect the determination of average skill in the art.

Abandoning IP

So what is to be done about the patent problem? Well, my guess is that the growing tsunami of patent litigation is going to lead to some kind of change in the law. The current situation is pretty untenable, and I think it's only going to become more so. Something big will break loose in the next few years and I think the landscape is going to change dramatically.

There are multiple fronts on which the current patent system seems to be at odds with proper innovation, and one of the biggest problems in my eyes is that it is only larger, heavily established and heavily funded companies that are even trying to get patents. You don't see garage startups wasting their time trying to eke out software patents: they're too busy building. It's not until a company is big enough that it can afford to split its focus and hire patent attorneys and do what is necessary to start "protecting" its IP. That bothers me, because it's propping up a system of innovation where only the big established players have a chance to exclusivity on their "inventions," and in my mind those are the people who need protection the least.

Technology moves orders of magnitude faster than it did in "the old days" and I'm not even sure where patents fit anymore. 18 years is several lifetimes by current standards of advancement, and to lock up a technology for that long is equivalent to locking it up for the entire span of its usefulness.

Coming from an open source software advocacy background, patents seem like a greedy, antiquated version of what thousands do every day for free: sharing their technology with the world for the benefit of everyone (the creator included). In a world where everything can change in a matter of months, I think it's time to stop worrying about protecting IP and time to focus solely on creating things of lasting value. Don't keep your competitors from using your innovations, just make newer and better innovations that outpace them.

• Read more about Google +1 Omnigraffle Stencil

Chris Tate, our senior User Interface Designer, recently created an Omnigraffle stencil of the Google +1 button. We figured we would make it available for anyone else that might need it!

You can download the file here. Happy designing!

• Read more about Ruby Thankful

A lot has been made in the talkosphere recently about the brewing "multi-Ruby version manager" war, namely RVM vs newcomer rbenv. I'm not here to discuss the relative merits of either software solution, mostly because I take things pretty simple and straightforward in command-line world and I've never run into problems with RVM. What I do think this little fracas displays, though, is a common thread in the Ruby community of having big, blown-up controversies when new things come along. In some ways, I think that such drama is one of the unique features of the Ruby community that make it so vibrant. It's also a feature of the community that can lead to community casualties.

RVM vs. rbenv, Test::Unit vs. RSpec, HAML vs. ERB, Rails vs. Merb, Coffeescript vs. Javascript, Mongrel vs. Thin vs. Passenger vs. Unicorn, Cucumber vs. Steak, and the list goes on. It seems like the Ruby community has a habit of drawing battle lines every month or so. Why do these "fights" come up so frequently in our community? More importantly, what do they mean for the overall health of the community?

Today we're launching a little site called RubyThankful. It's barebones at the moment and open source, but what it represents is hopefully a way to find some positivity in the Ruby community.

Background: Passionate Programmers

I would argue that controversy breaks out on a regular basis in the Ruby community because, more than any other community in which I've participated, Rubyists are singularly driven to use not just good-enough tools but ideal tools. Ruby is a community of chaotic reinvention, a community that will jump off a cliff just to try out a new brand of parachute. It's that passion that draws me to the community, that makes me feel like the things that I do matter. It's also that passion that can cut to the bone.

People are inevitably going to form opinions about what they think is the best in a field of competing libraries/tools/products. This competition in the commercial marketplace is what drives high quality and low prices, and in the open source world it's what drives reinvention and continual progress. If a library isn't pushing its users forward, those users can and will seek out a different library that better meets their needs. This is natural and generally beneficial.

What isn't maybe so beneficial is the "what have you done for me lately" attitude that can come with our pursuit of the perfect development process. It's altogether too easy to write about reasons why "Y is better than X" while forgetting about the fact that before that, X was so much better than nothing at all.

Casualties of Harsh Reality

As I began to write this post I saw Steve Klabnik's We Forget That Open Source is Made of People. It'll be hard not to re-iterate many of his well-reasoned thoughts here, so I want to give him credit for making a point that needs to be made. I was also amazed to come against this controversy just one day after I wrote a post that included the sentence "Harsh words can sometimes be enough to completely dissolve the creator's interest in continuing the project." We've lost amazing members of this community because rather than respecting their contributions we tear them down when something marginally better comes along. This is the dark side of passion.

I like some tools better than others. I've even written blog posts debating the merits of one approach over another and declaring one superior for my purposes. I've been guilty of jumping onto new technologies and giving nary a thought to the old way of doing things. I don't think it's possible to stop this community from being obsessed with the new and different, and I don't think that's what needs to happen. What needs to happen is that our community needs to get better at raising our voice in something other than protest. We need to temper our enthusiasm for the new enough to at least be civil to the hard-working people who created the tools we used until oh-so-recently.

I'm as guilty as anyone of this. Short of trying to say "thanks" in person to the creators and maintainers of the tools I use every day when I see them at conferences, I don't take much time to thank people for the amazing things they've done to make this community what it is. This all sounds sappy and somewhat inefficient, but I think it's a vital piece of maintaining a healthy community.

Ruby Thankful

I almost wrote this just as a blog post to say "hey, let's be more positive and thankful." I was just about to post it when I realized I could do at least a little bit more than that. So I built an almost-nothing-to-it site that can serve as a public forum for the Ruby community's gratitude for those who work hard to make it what it is. Just tweet something with the #rubythankful hashtag and it'll get picked up. Maybe it's someone you're thanking for a library, or their blog post or tutorial that helped you out, maybe it's something else. If you're thankful for the Ruby community and the members of it, let's put some voice out there!

This community has given me a lot in the last four years, and I've done my best to give back. But I haven't always been thankful enough to the individuals who create the things that I use every day. Hopefully RubyThankful is a small way to encourage that to change.

• Read more about Startups: Winning With Rails Shops

In previous posts in this series we talked about how outsourcing your development needs to a Rails shop can make more sense than hiring an internal development team. In this post, we are focusing on startups specifically, and how they are in a unique position to benefit from relying on a Rails shop to build their web applications.

Startups have distinctively different needs from established companies when it comes to launching a product. A startup is trying to penetrate the market as a new player, without a preceding reputation and without any history of success. Additionally, your startup needs to prove its ability to compete quickly after launch, in order to appease those that have gone out on a limb to invest time and money into your product. The startup world is cutthroat and austere – there is little room for mistakes and stagnation.

In a recent Fast Company post on “Ten Tips to a Successful Startup”, getting to market fast was listed as one of the top 3 tips and is one of the “lean startup principles” from famed startup advisor, Eric Ries. When you’re trying to launch your product, you need a team of expert developers to get your there faster.

Don’t Go To Market Alone

By hiring an experienced Rails shop to handle the development work, your startup can leverage these advantages:

• Lower risk – Whenever you contract with a consultancy you are entering in a lower risk situation than hiring your own employees. With a Rails shop you will enter in a mutually beneficial contract and statement of work.
• Assembled Team – Assembling a team of developers, project managers and designers takes time. Especially in the Rails world in which the demand for Rails developers is high, but the supply continues to be low. But it’s easy to find a reputable and quality Rails shop, and they will have a team ready to start on your project right away!
• Control costs – When you work with a Rails shop you have a clear understanding (through your statement of work) of how much the project will cost. This makes it easier for your startup to budget for development work.
• Scheduled Deliverables – Since you’ll be working with a veteran team of developers, you can expect to know when each milestone of the project will be delivered. This helps you plan launch dates and milestones with your investors.
• Proven track record – Hiring individual in-house developers can be tricky, and you never know what you’re really getting or how well your assembled team will work together. With a Rails shop you can be assured that the teams already know how to work together and deliver successful projects on time. Rails shops work diligently to meet deadlines and keep their clients happy, because their good reputation is so vital to their existence.
• Extra Promotion – When you use a Rails shop, you can often expect the benefit of having some free promotion. Rails shops care about their clients’ success, and thus will usually take steps to promote them through word of mouth, social media, blogging, and other avenues. And when you’re new to a market, you can never have too much promotion!

Success Stories

At Intridea we have years of experience working with startups. In one particular case we were approached by Visual CV, a startup that wanted to revolutionize the online resume market. We quickly assembled the ideal team of developers, designers and project managers for their project. In their case it was critical to get something to their users as soon as possible, so we sat down with them to determine which features were necessary for a minimum viable product. Once we understood their vision and their specific needs we went back to our offices and within just two weeks we had a working prototype that was polished enough to deliver to their users. Then we stayed on board to deliver more complete iterations of the product and to help them hire and transition an internal team of developers to carry on future development.

When EarthAid approached us to architect a complete solution to help people track and lower their energy costs and consumption costs, we knew we would need to work quickly and intelligently in order to help them launch their product in a new market. In addition to the design and development process, our architects made sure they built a system that would scale with the EarthAid's needs as their user base grew over time. We were able to get them to market quickly and efficiently. Shortly thereafter, they attracted venture funding and today EarthAid is a thriving business.

Where Are The Good Programmers?

One of the toughest challenges for any entrepreneur is hiring good programmers to execute on their vision. If you’re not already a programmer, knowing how to identify good programmers can be nearly impossible. In this situation it makes more sense to consult with an experienced Rails shop for your development needs. A Rails shop will already have assembled a good team of programmers, designers and project managers.

If you’re running a startup, you won’t likely have time to worry about all the details of putting a team together. When you hire an internal team you need to set aside a lot of time for things like:

• Finding good programmers (and making sure they are actually well qualified)
• Making sure the team you hired is working well together
• Paperwork - setting up your new employees takes a lot of effort. You'll probably want to provide them with benefits, possible relocation if you couldn't find all the talent you needed locally, and make sure they're adjusting well to their new full-time position.

All of that takes time and distracts you from your more time-sensitive business objectives. When you hire a Rails shop to handle your development, you bypass the complications of hiring an internal team and allows you to focus on your business strategy, your market, your customers, and all the mission-critical aspects of launching a venture. Once you've launched your product and penetrated the market, the Rails shop can often help you hire your own internal team and help them learn the codebase, ensuring a smooth transition.

Why Rails?

If you aren’t already familiar with the benefits of using Rails to build your web applications, check back next week! In the next post in this series we’ll be talking about why Rails is a smart choice for development when you need to get your product to market! Follow us on Twitter or subscribe to our RSS feed to get updates on future posts.

About Intridea

We create custom web and mobile solutions for businesses large and small across a range of industries – from Healthcare, Government, IT, Education, Arts, Real Estate, Insurance and more. Our team of designers, architects and developers can work with you every step of the way to bring your vision to life on the web. Contact us today to find out more!