I recently worked in a Rails project with Peter (@sporkd). The project is intended to be used as a sub-site, and should be served under sub-URI. After google, we ended up by setting config.assets.prefix and wrapped all routes in scope. The solution is simple and worked well. But soon, some weird bugs were found, and Peter was successfully isolated the problem to session (see demo sporkd/asset_prefix_test).

For Rails developers, Backbone + Rails + CoffeeScript is a perfect combination, server side MVC experience can be easily carried over to the Client side

This weekend we had Intrideans at four different events we sponsored from DC to Germany, talking about user experience, design, Ruby on Rails, and tablets. Here's a quick rundown of our experience at the events.

MoDevTablet

The first event kicked off early Friday morning. We partnered with GoMoDev to support their MoDevTablet event, and Jurgen, our Managing Director of UX, Christine Nakatani, our Director of Business Development, and Maggie, one of our superbly talented Project Managers spent the day talking with tablet developers and designers.

The Rails community has had its share of misogynistic controversy over the last several years. Dominated by male programmers (recent statistics suggest 94% of employed Rails programmers are male), the inroads to professional Rails development for females are not exactly accessible or welcoming.

Of course, it's not just the Rails community that lacks representation from women. When only 18% of the Computer Science undergraduate degree recipients in 2010 were female () it's obvious there is a lack of female participation in the entire field of programming.

Don't cry. We've all been there too. Regression issues in the presentation layer make the entire team go crazy. Why can't we have a methodical way of testing the UI to ensure once designs are styled as views, they stay the way that they were created?

Rails views are typically rendered after some controller action is executed. But the code that powers Rails controllers is flexible and extensible enough to create custom rendering objects that can reuse views and helpers, but live outside of web request processing. In this post, I'll cover what a Rails controller is and what it's composed of. I'll also go over how to extend it to create your own custom renderers, and show an example of how you can render views in your background jobs and push the results to your frontend.

Twitter popularized the term "firehose API", to mean a realtime stream of data sent through a persistent connection. But even if you're not a realtime service, streaming APIs are great for pushing data from the backend to clients. They reduce resource usage because the server can decide when it's a good time to send a incremental chunk of data. They can also improve the responsiveness of your user experience. The same HTTP API can be reused to power multiple different apps. For example, you could write your web frontend with a Javascript frameworks like Backbone.js, but reuse the same API to power a native iOS application. Follow the jump to read about how streaming APIs work, and how you can write one with Rack::Stream.

When you use Rails built-in helpers for page, action, and fragment caching, the cached data is stored into an instance of ActiveSupport::Cache::Store. But while the interface for using the cache stores are the same, each cache store implementation has different performance characteristics and are suited for different jobs. In this post, I'll cover what cache stores are available with Rails by default, how to tune them, and how to write your own custom cache store.

What do you get when you discover you setup a route incorrectly ages ago? Why, a redirect of course! And a blog post with some handy redirect code that you might find useful one day!

For prototyping a new webapp, I like to get an HTML prototype on screen as fast as possible. There are a number of ways to achieve this, ranging from the heavyweight Rails, to the lightweight Sinatra. But even a barebones Sinatra app requires you to specify routes and layouts. When I'm focused on sketching out the markup structure and design, what I'm looking for is less distractions from setup. Theoretically, one could prototype everything with raw static HTML, but most designs usually share layouts and snippets that would be a pain to copy and paste between different files. Writing raw CSS is also possible, but once you've gotten a taste of Sass and Compass extensions, why would you want to? In this post I'll outline my bottoms up approach to getting a site design bootstrapped. I'll also cover how to get these prototypes up in a public area for feedback, and how these prototypes can be used as scaffolding alongside your development.

Unit tests should pass when run in random order. But for an existing legacy project, certain tests might depend on the execution order. One test might run perfectly fine by itself, but fail miserably when run after another test. Rather than running different combinations manually, RSpec 2.8 has the option to run specs in random order with the --order random flag. But even with this, it can be hard to determine which specific test is causing the dependency. For example:

Metro areas generally have really active user groups where Rails_Awesome_Lord presents regularly, famous hackers drop in to give presentations, and the Rails Elite throw smashing parties and drinkups after each meeting. But not all developers live in (or near) metro areas and can partake in such festivities. If you're among the rural band of outlaw programmers, this post is for you.

Rails. No, really.

The future of web and mobile design is in Rails, Sinatra, Django, and other RESTful web frameworks that can be used to leverage design power across multiple platforms, making it easier and faster (translate: more economical) to design for web, mobile and desktop.

Our UI/UX team was stationed up in NYC for the Future of Web Design conference last week and we were able to chat with some really awesome folks who had innovative and inspiring ideas about web design.

Intridea Partner and open source crusader, Michael Bleigh, will be back in his hometown of Kansas City this week, presenting "Rails is the new Rails" at Ruby Midwest.

The sweeping changes brought on by Rails 3 and 3.1 haven’t just made our existing development patterns easier, they have opened up the ability for us to build new patterns that accomplish more in a more beautiful and efficient way. In this session you will see how thinking about new features in a different light can lead to real innovation for your development practices. Examples include baking routing constraints into your models, application composition with Rack, truly modular design with the asset pipeline, and more.

In a community where best practices are always being redefined, black magic practices aren't hard to come by. For our first discussion on controversial Rails practices we're focusing on default_scope.

Default Scopes, (Briefly) Explained

A default scope is a Rails method provided by ActiveRecord which allows you to specify conditions for all the finders associated with a particular model. It is commonly used to specify ordering directly in your ActiveRecord model.

Sounds like a fairly good tool, but don't be fooled. Popular opinion dictates that default_scope is at the very least a chaotic good tool, bordering cunningly on the edge of the black magic stratosphere.

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.

With the release of Rails 3.1.0 last night most Rails devs were rejoicing. (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, most of us could predict a few diva-style outbursts about the new changes this morning.

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 this new blog series, Why Your Company Needs a Rails Development Shop, we’ll discuss why it makes sense to turn to a reputable Rails development company for web application development. In a new market saturated with Ruby and Ruby on Rails buzz, it can be hard to determine who the experts are and where to find them. We hope this series unveils some of those challenges and how using a Rails development shop can alleviate some of the headaches in making decisions about development.

In this first article of the series we’ll focus on the current climate of the Rails job market and how it complicates the process of finding and securing talented developers.

First, A Brief History

Since its release in 2005, Ruby on Rails has forged an incredible legacy for itself. Rails has been widely adopted as an ideal framework for creating web applications by companies large and small, and has been supported by a uniquely driven development community. Apple’s announcement that Ruby on Rails would ship with OSX v10.5 in 2006 helped to solidify the future of Rails in the business world.

Thanks to those early adopters and evangelists, Rails is now a legitimate and successful framework that is being put to use by some of the most prestigious and highly-trafficked web sites around the world, including Scribd, Groupon, Twitter, Amazon, NASA and more.

Last week, I packed my bags and headed for Norfolk, VA to speak at the Mid-Atlantic Developers Expo. I've spent the better part of the past year traveling the country, speaking about Geospatial Programming using Ruby and Rails. As a long-time lover of maps, the topic has been a joy to introduce to the community of Ruby developers, at both small regional conferences like MagicRuby or MountainRuby, and at major national conferences like RubyConf 2010 and RailsConf 2011.

In April, I announced GemNotifier, a new Intridea SparkTime project. GemNotifier is a web app I created to send notifications to users when the gems they subscribe to are updated.

Today, I'm excited to announce that we are open sourcing GemNotifier. At Intridea, we have a long history of support for open source development, and we make every effort to open source tools and projects that can be of use to the greater development community.

There's been a lot of controversy surrounding the changes to Rails 3.1. It started with an epic GitHub commit thread and the discussion exploded again in the past few days after What the Hell is Hapenning to Rails and Yehuda's response thereto. I'm going to address the issue from a perspective that honestly hadn't even occurred to me until I just said it while in a conversation with some Kansas City Ruby folks after the last meetup: "What if Rails isn't for beginners anymore?"

One of the first things that anyone has to do in an application is assign instance variables in controllers for use in views, etc. This pattern, while dead simple, has a number of possible implementations that each have their aesthetic benefits and drawbacks. At RailsConf I had the opportunity to hash this out with none other than DHH and David Chelimsky, so I thought it might be a good opportunity to represent the different sides in a post.

It's been close to a year since Rails 3 came out and I've had the pleasure of working on several Rails 3 projects since its release. Some existing gems became irrelevant with the release of Rails 3, while others lived. Additionally, we've seen many new gems come to life. I'd like to share a stack of gems that I've been using this year. Hopefully they will give people a bit of help while developing a new Rails 3 app.

Most of these gems have good documentation on their project wiki (every great gem should be well documented, right?), so I won't go into great detail about the mechanics. Instead, my aim is to introduce you to some of the gems I find most useful and separate them into meaningful categories, as a sort of reference guide.

Today I'm introducing GemNotifier.org, a web app I built to deliver timely notifications about your favorite gem updates. It's a SparkTime project at Intridea and it's something I've been working on for the last month.

RailsWizard v3 brings unprecedented ease to the rapid generation of new Rails applications via its unique template builder system.

I'm pleased to announce Profanity Filter for Rails. This gem filters undesirable words from text and displays a friendly version. Filtering is non-destructive by default but has the option of replacing the original text. It's based on a dictionary that is customizable so you can add additional words as needed.

When you're building a web application, there's always the question of how to handle the site-wide administration. You probably have a small list of people at your company that should be able to access it. If you're like Intridea, you also use Google Apps to handle e-mail etc. Using OmniAuth it is trivially simple to set up a simple "admin login system" for your Rails 3 app. Here's how to do it.

Rails adds a pretty cool Object#try method. From Rails doc:

try(method, *args, &block)

This Invokes the method identified by the symbol method, passing it any arguments and/or the block specified, just like the regular Ruby Object#send does.

Unlike that method however, a NoMethodError exception will not be raised and nil will be returned instead, if the receiving object is a nil object or NilClass.

We chose to use Present.ly as our communication tool during the Rumble. Present.ly is a private micro blogging system. It uses XMPP like most IM services use, so it's instant. But unlike IM, the messages are well organized thanks to the way it uses threading to display message replies. Plus, there are no messy chat logs to sift through! We use Present.ly at Intridea every day as our main tool for collaboration and communication across projects, so we were already comfortable with the application and knew how well it would support our unique needs as a distributed Rumble team.

Learn all about the tech behind tldr.it, Intridea's Jeremy McAnally's application in the running in the Rails Rumble.

This weekend was the fourth annual Rails Rumble event; a software contest among Rails developers, in which smalls teams of coders bring an app to life in just 48 hours. In the week following the Rumble, the apps are judged by an expert panel of judges, winners are selected, and honor is won.

Intridea is no stranger to the Rumble. We've sponsored the event for the last three years, and we've had teams participating since the event was jump-started in 2007. Intrideans have created some interesting applications, like Run1Mile, Lyricist, Love+Loathe, Thingivore, Celebrity Passage, and Smacksale - a deal aggregator that's still collecting data and publishing the hottest sales, even today!

In a staging or production environment this involves modifying the DNS and adding a wildcard entry that points all hosts to the primary domain specified. To develop and test the subdomain aspect of a web application like this, most of the time developers just edit their hosts file locally and add an entry that piggybacks on the localhost entry. This post shows you how to do it dynamically using the DNS server BIND locally on OS X so you never have to mess with your pesky hosts file again!

I recently had to look over some code that was returning inconsistent results. I was able to fix the code with a few minor changes, but it was still very hard to follow. Take a look:

Michael Arrington announced OpenSocial on TechCrunch two days before its official release. Prior to that, there were whispers everywhere about Google’s new social platform, but not many seemed to know what exactly was about to go down. Needless to say, this is good buzz. Two days before ‘launch’ the overwhelming mood among web developers, especially us who dwell in the realms of social networking, was one of intense (even feverish at some points) anticipation. What unfolded over the next few days, combined with what we observed of Facebook’s API venture, provides us a set of best practices that we can apply to an API release.

On a recent project when I was using the BetterNestedSet plugin to manage a large hierarchal set of data, I encountered a problem that required me to find all of the items in a nested set that had children and those that didn't. In nested set terms I wanted: all 'parent' nodes and all 'leaf' nodes that exist within the 'tree'.

If you want to do this through the current BetterNestedSet interface you might be tempted to do something like this: