A few months ago, I read a blog post by the Flickr developers on how they built an internal tool called a “feature flipper”. A feature flipper lets a site admin deploy/rollback features from a simple dashboard with a single click. Think of being able to add an on/off switch to any piece of code in your application.
This has two main benefits:
1) no more merging branches
2) more control of user experience.
While some people may enjoy merging branches (and going to the dentist), I’d rather avoid it. A good feature flipping system can also help you be more agile: if your application takes X minutes to deploy, you save X minutes each time you deploy or rollback a new feature. Control of features moves from Git (or Mercurial or whatever) to the application itself. (This also has some disadvantages–they’re listed in the Flickr post).
The Flickr post described how they used PHP to build a feature flipper. In this post, I’m going to show you how to implement a basic feature flipper for Ruby on Rails.
Continue Reading »
Searchlogic is a Rails plugin that adds useful named scopes to all of your models.
I had a little trouble building a search form for a datetime attribute. After reading a blog called Craic Computing Tips and the Issues section on Searchlogic’s Github page, I arrived at this simple solution:
I recently asked a question on Stackoverflow about when it’s best to use a case statement versus using a Hash in Ruby. I got a few answers including a really good specific answer. But another more general answer really struck me, so I’m sharing it here.
Igor Krivokon wrote:
In general, “better” in programming means different things. For example better program
- is easier to understand, i.e. expresses the intent better
- is easier to maintain. For example, less lines of code, less error-prone, etc.
- has better performance, in terms of execution time
- has better performance, in terms of memory usage
etc.
Since we are talking about Ruby, the performance is typically of a lesser concern. If you really need performance, you might consider another programming language. So, I would look at criteria (1) and (2) first. The better looking Ruby code usually represents a “better” program. Which code looks better? Which expresses the intent better? Which would be easier to modify if you add/remove logic? It depends on your problem, and it’s a matter of taste, to certain degree.
To me, in your short example, the hash solution is better. The case solution provides more flexibility, which you don’t need in this case (but might need in other cases).
Igor’s answer really helped me prioritize competing needs and easily got my upvote. If you find his answer helpful, I’d suggest you do the same.
I’ve been working on an admin panel for a certain Rails app. One of the most common tasks to writing an admin panel is to generate a table where each column is a different attribute for your model. This is easy to do, but very tedious.
To simplify the task, I looked at metaprogramming. Metaprogramming with Ruby/Rails is very slick. I could generate a table for an arbitrary ActiveRecord starting with this code:
After a few basic iterations, I found that dynamically calling methods is 1) not reliable and 2) inhibits customization. So I found middle ground.
Continue Reading »
CATA (Centre Area Transportation Authority) recently released a free iPhone app for tracking their buses in real time. Although I don’t own an iPhone, based off the few times I’ve seen my friends use the app, I’ll say that CATA did an excellent job with it.
The iPhone app wasn’t CATA’s first foray into real-time bus tracking. About a year ago, CATA released a live Google map of their bus routes. While useful when you’re a near a computer, my biggest gripe was that the map wouldn’t load on most (if any) phones.
So one weekend last Spring I built Catafind.
It’s not as flashy or polished as the iPhone app, but it works on virtually any phone with Internet access.
Eager loading in ActiveRecord is a great feature. It prevents what’s called the “n+1″ problem. From the docs (emphasis mine):
Eager loading is a way to find objects of a certain class and a number of named associations. This is one of the easiest ways of to prevent the dreaded 1+N problem in which fetching 100 posts that each need to display their author triggers 101 database queries. Through the use of eager loading, the 101 queries can be reduced to 2.
The docs then give this example:
Continue Reading »
