Development Blog: Viget Labs

Ben Scofield, Technology Director, February 17, 2010 0

I figured it would be best to start the tour of Rails 3 generators with those that are most commonly used. Assuming I'm representative of most Rails developers, that would include the following: migrations, models, controllers, and resources. (If your favorite isn't in the list, don't worry! I'll be covering the rest of them soon enough.)

Continue reading "Rails 3 Generators: The Old Faithful"

Clinton R. Nixon, Development Director, February 12, 2010 12

I love using Git, but when my repositories turn into a tangle of merge commits, I start to get a little frustrated. Here’s my solution. Go into your repo’s .git/config file and make sure it has something like the following:

[branch "master"]
  remote = origin
  merge = refs/heads/master
  rebase = true

Now, when you run git pull, it’ll rebase your local commits on top of the newly pulled-down commits instead of trying to merge them. Even better, try putting this in your global ~/.gitconfig file:

[branch]  
  autosetuprebase = always

With this change, all tracked branches from then on will be set up to rebase instead of merge.

Ben Scofield, Technology Director, February 11, 2010 3

Like a lot of people, I've been watching the Rails 3 development process, but I hadn't turned any focused attention on it until the beta release last week. I've been playing with it a little, and one of the first things that struck me were the changes to the way generators work. Unsurprisingly, given the extensive changes made throughout the framework, generators look a lot different now, so I thought it might be useful to explore the new status quo in a series of blog posts.

Continue reading "Rails 3 Generators: An Introduction"

Matt Swasey, Web Developer, January 15, 2010 2

One of the coolest aspects of named_scopes in ActiveRecord is their ability to chain together. One can chain a number of named_scopes onto each other, and the result is a single SQL query. Using this feature, I've come up with an easy way to do some simple searching.

To begin I'll create a search form with fields for searching on 'Artist' and 'Song title.'

<div>
  <% form_tag search_songs_path, :method => :get do %>
  <p>
    <%= label_tag "Artist" %><br/>
    <%= text_field_tag "search[by_artist]", params[:search].try(:[], :by_artist) %>
  </p>

  <p>
    <%= label_tag "Song title" %><br/>
    <%= text_field_tag "search[by_name]", params[:search].try(:[], :by_name) %>
  </p>

  <p>
    <%= submit_tag "Search" %>
  </p>
  <% end %>
</div>

This form will submit it's elements as GET parameters to a search action. This is a custom action, so we need to define it in our routes file:

map.resources :songs, :collection => {:search => :get}

And in app/controllers/songs_controller.rb

....
def search
  @songs = Song.search(params[:search])
  render :index
end
....

The search action will call Song.search, and pass the param values attached to :search.

Implementing the Search

We need a class method in our Song model that will find records based on our params. What I want is to turn this:

{:by_name => "Twist and Shout", :by_artist => "The Beatles"}

Into this:

Song.by_name("Twist and Shout").by_artist("The Beatles")

Here's what I came up with:

def self.search(params)
  params.keys.inject(scoped({})) do |found, k|
    params[k].blank? ? found : found.send(:"#{k}", params[k])
  end
end

And a named_scope for every key:

named_scope :by_artist, lambda {|name| {:conditions => {:artist => name}}}
named_scope :by_name, lambda {|name| {:conditions => {:name => name}}}

Let's step through what's happening in Song.search:

1. Param's keys are iterated over, setting the initial value for inject to an anonymous scope.
2. Iterating over the key names, we return the current collection 'found' if the current key has no value.
3. If the key does have a value, the key name is called on the collection with it's corresponding value as the arguments. Since 'found' is always a scope, we can do this as many times as needed, creating our scope chain.

Conclusion

If I had to preform searching of a more complex nature, I might choose an library like ThinkingSphinx. If you want something quick, simple, and relativly flexible, I think this approach is worth a try.

Ben Scofield, Technology Director, December 23, 2009 4

I am, to put it mildly, not a fan of the typical New Year’s resolution. Generally, it’s much too vague, it runs over much too long a time scale, and it’s not supported by appropriate subgoals (monthly, weekly, and daily). In effect, they’re feel-good affirmations, but they’ve got no teeth.

I’m always optimistic about well-structured and supported resolutions, however, and the start of a new year is the second-best time to launch them (the best time, of course, is today). Think of these as overarching priorities that can help guide your shorter-term planning efforts throughout the year to come; as you sit down at the beginning of every month, week, and day, these resolutions provide a framework to fit projects and tasks into.

So, without further ado, here are some suggested New Year’s resolutions for developers:

Have a new year

The "years of experience" requirement that so many HR departments rely on is bunk; we’ve all met developers who’ve been working continuously for a decade, but they’ve not grown at all. In effect, they’ve repeated the same year (or month, even) of experience over and over. Make a commitment that this year will be different!

Learn a new technology

The technical world presents boundless opportunities to learn, from new languages (as the Prags suggest), to new frameworks and applications. My personal pick for the most exciting area of development at the moment is the alternative database (e.g., NoSQL) scene, but there are changes afoot everywhere.

Practice your craft

The best way to improve at something is to practice deliberately – work at a task specifically designed to help you improve, pay careful attention to your results, and modify your performance appropriately when repeating the task. Note that this isn’t the same as, say, starting a side-project to learn a new web framework. If your goal is something other than pure practice, then you won’t actually be practicing.

Contribute to the community

There’s always a problem out there to be tackled, so start a new open-source project or contribute to one that already exists.

Test your JavaScript

OK, this one’s a bit more specific than the others, but let’s face it: most people don’t test their JavaScript. There’s been a surge of development in testing tools over the past year, so isn’t it about time you took a look at some of them?

Happy New Year!