I wanted to publically thank everyone for helping me get Oh My Zsh out there and continue to improve it. Many of us spend a lot of time in our terminals throughout the day and I firmly believe that having a well-working shell is nearly as important as having a well-working texteditor.

While Oh My Zsh isn’t a large project, it is my attempt to share what I’ve learned about using zsh with others… but honestly, my goal is to learn from you. I don’t have a lot of time to really dive into the deepend of the zsh-pool so am relying on others to share their tricks, hacks, functions, themes, etc. So, I thought that if I created a basic framework with outlined some conventions so that others could contribute, that perhaps I’d end up with a kickass shell.

So far… Oh My Zsh has been forked on github 25 times and is being watched by over 100 people.

Last week, I pushed out an update that introduces an auto-update feature. I’m quite keen of desktop applications that can auto-update themselves, so our initial version of this feature will ask you no more than once a week if you want to check for updates. This means that as we continue to extend and improve Oh My Zsh, you can keep up-to-date.

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

It’s the beginning of a new month… are you still using Bash? Perhaps you’re using your own zsh configuration but want to see what else zsh can offer you? I invite you to install Oh My Zsh today. :-)

Just run this in your terminal and you’ll get setup. Don’t worry… you won’t lose your existing configuration. :-)

wget http://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh

For more infromation, visit http://github.com/robbyrussell/oh-my-zsh/

Yesterday, the Rails team released 2.3.4, which includes standardized way for loading seed data into your application so that you didn’t have to clutter your database migrations.

I noticed a few comments on some blogs where people were asking how to use this new feature, so here is a quick runthrough a few ways that you can use it.

Populating Seed Data Approaches

The db/seeds.rb file is your playground. We’ve been evolving our seed file on a new project and it’s been great at allowing us to populate a really large data. Here are a few approaches that we’ve taken to diversify our data so that when we’re working on UI, we can have some diversified content.

Basic example

Any code that add to db/seeds.rb is going to executed when you run rake db:seed. You can do something as simple as:

1. db/seeds.rb

Article.create(:title => ‘My article title’, :body => ‘Lorem ipsum dolor sit amet, consectetur adipisicing elit’)\

Just create database records like you would in your Rails application or in script/console. Simple enough, right? Let’s play with a few other approaches that we’ve begun to use.

Use the names of real people

We’re using the Octopi gem to connect to github, collect all the names of people that follow me there, and using their names to seed our development database.

\@robby_on_github = Octopi::User.find(‘robbyrussell’)

1. add a bunch of semi-real users
   \@robby_on_github.followers.each do |follower|
   github_person = Octopi::User.find(follower)
   next if github_person.name.nil?

# split their name in half… good enough (like the goonies)
first_name = github_person.name.split(‘ ‘)[0]
last_name = github_person.name.split(‘ ‘)[1]
new_person = Person.create(:first_name => first_name, :last_name => last_name, :email => Faker::Internet.email,
:password => ‘secret’, :password_confirmation => ‘secret’,
:github_username => follower, :website_url => github_person.blog)
# …
end\

We do this with a few sources (twitter, github, etc..) to pull in the names of real people. If you want to be part of my seed data, you might consider following me on Github. ;-)

Use Faker for Fake data

You may have noticed in the previous code sample, that I used Faker in that code. We are using this a bunch in our seed data file. With Faker, you can generate a ton of fake data really easy.

person.links.create(:title => Faker::Lorem.words(rand(7)+1).join(’ ‘).capitalize,{lang=”ruby”}
:url => “http://#{Faker::Internet.domain_name}/”,{lang=”ruby”}
:description => Faker::Lorem.sentences(rand(4)+1).join(’ ’)){lang=”ruby”}\

We might toss something like that into a method so that we can do the following:

\@people = Person.find(:all)

500.times do
generate_link_for(@people.sort_by{rand}[0])
end\

…and we’ll get 500 links added randomly across all of the people we added to our system. You can get fairly creative here.

For example, we might even wanted random amounts of comments added to our links.

def generate_link_for(person)
link = person.links.create(:title => Faker::Lorem.words(rand(7)+1).join(‘ ‘).capitalize,
:url => “http://#{Faker::Internet.domain_name}/”,
:description => Faker::Lorem.sentences(rand(4)+1).join(‘ ‘))

# let’s randomly add some comments…
if link.valid?
rand(5).times do
link.comments.create(:person_id => \@people.sort_by{rand}[0].id,
:body => Faker::Lorem.paragraph(rand(3)+1))
end
end
end\

It’s not beautiful, but it gets the job done. It makes navigating around the application really easy so that we aren’t having to constantly input new data all the time. As mentioned, it really helps when we’re working on the UI.

Your ideas?

We’re trying a handful of various approaches to seed our database. If you have some fun ways of populating your development database with data, we’d love to hear about it.

I just pushed a small change to Oh My Zsh, which gives it rudimentary support for themes. What I’m hoping to do is collect prompts from tons of people and make it simple for others to find a PROMPT that works well for them.

::: thumbnail :::

As of right now, there are only three for you to choose from. So, please head over to github, fork Oh My Zsh, add your theme, and send a pull request. :-)

::: thumbnail :::

Once I get it merged in, we’ll get a screenshot of it added to the Oh My Zsh wiki. (see themes)

I know that many of you have some really sweet prompts configured as I got a lot of response with my post, Show me your and I’ll show you mine (terminal prompts with git branches).

Inspired by some recent posts from Tom on zsh, I decided that I’d do my part to help people give it a whirl. I’ve been using zsh for a few years now and haven’t found myself missing bash.

If you’re interested in taking a few minutes to give zsh a while, you’re in luck. I recently reorganized all of my zsh config into a package and tossed it on github to share. My goal was to create a reusable tool that would allow people to get up and running quickly with some of the fun configuration that I’ve come to rely on on a daily basis.

For example:

• Auto-complete rake and capistrano tasks
• Git branch names when you’re in a git project directory structure
• Tons of color highlighting (grep, git, etc.)
• Sexy prompts.. (so say me)
• much much more…

I invite you to give Oh My Zsh a whirl, which should take you less than a minute. Just follow the instructions.

Also, Oh My Zsh is Snow Leopard compatible. ;-)

_why,

If you’re out there and come across this… know that one of my fondest memories on the internet was with you. Hoodink.d was one of the greatest things on the internet four years ago and I suspect that a very tiny fraction of the Ruby community has even heard of it.

{width=”421” height=”199”}

Fortunately for me, I have a copy of the hoodwink git repository and was able to get it running tonight in hopes that I might find you lurking in the mousehole. I’m convinced that you are in a parallel internetverse. Perhaps you might send me an invite.

{width=”465” height=”500”}

I miss hoodwink… and if you stay missing, I’ll just miss hoodwink more.

In the meantime, I wonder how hard it’ll be to get hoodwink to run on rack.

{width=”500” height=”368”}

Wink you on the other side,
Robby

s. you can find me in my own mousehole… should you want to send me an invite and/or feed me cheese.

Related Posts

• Thank you hoodwink.d

Now that the cat is out of the bag, I can share some recent news with you. Earlier today, we announced that Blue Box Group had acquired Rails Boxcar, our kickass deployment solution for Ruby on Rails applications.

Our team has been offering hosting services for over six years. When I made the decision to start providing Rails hosting over four years ago, it was something that I thought the community needed to validate that Ruby on Rails was a viable solution for building web applications. At the time, there was only one or two companies offering pre-configured solutions. The good ole days. :-)

Over the course of the past 4+ years, we’ve helped deploy and host well over a thousand web applications built with Ruby on Rails. Perhaps we even hosted your site at one point or another. We definitely had a lot of fun and learned a lot from our experience.

Fast-forward four years, the community now has several great solutions and options for hosting their Ruby on Rails
applications. Knowing this, we began to look over the plethora of services that we offer and felt that we had been spreading ourselves too thinly. We were faced with the big question of: Should we focus our energy on trying to innovate in this competitive space or should we find a community-respected vendor to pass the torch to?

Rails Boxcar is a product that we are extremely proud of and believe the acquisition by Blue Box Group will be great for our existing customers. The acquisition is going to benefit our customers as they’ll be able to interface with a team with more resources. A team that also aims to innovate in this space and believes that Rails Boxcar will help them do that.

As a byproduct of this deal, our team has an opportunity to focus our collective energy on designing and developing web applications, which has also been a central part of what we do for as long as we’ve been in business. We plan to speed up our efforts on a handful web-based products that we’ve been internally developing and hope to release in the near future.

I had the pleasure of getting to talk thoroughly with the team at Blue Box Group and really feel like they’ll be able to focus their energy on maintaining and innovating within the Ruby on Rails hosting world.. definitely more than we could over the coming years. In the end, the acquisition is going to benefit our customers the most as they’ll be able to interface with a larger team that is innovating in this space.

If you’re interested in learning more about the acquisition, please read the press release.

From our perspective, this is a win-win-win situation for everyone involved. Expect to see some more news from us in the near future… and if you’re looking for a design and development team, don’t hesitate to get in touch with us.

Hello from London!

Am currently enjoying the talks at Rails Underground 2009 in London and had the pleasure to be one of the first speakers at the conference. My talk covered a collection of what our team considers best practices. Best practices that aid in the successful launch of a web application and covered a few Rails-specific topics as well.

I’ll be sharing some posts in the coming week(s) that’ll expand on some of these topics as promised to the audience.

::: {#__ss_1770095 style=”width:425px;text-align:left”} Launching Ruby on Rails projects: A checklist{style=”font:14px Helvetica,Arial,Sans-serif;display:block;margin:12px 0 3px 0;text-decoration:underline;”}

::: {style=”font-size:11px;font-family:tahoma,arial;height:26px;padding-top:2px;”} View more documents{style=”text-decoration:underline;”} from Robby Russell{style=”text-decoration:underline;”}. ::: :::

Since I covered a wide range of topics, I decided to share my slides online. They won’t provide as much context (as I’m not speaking as you’ll look at them), but they might hint at some of the topics that I covered. There was a guy video taping the talks… so I assume that a video of my talk will be posted online in the near future.

Until then… here are the slides

On one of our larger client projects (approx. 160 models and growing…) we have a specific model that we refer to quite a bit throughout our code. This model contains less than 10 records, but each of them sits on top of an insanely large and complex set of data. Each record refers to a each of their regions that our client does business in.

For example… we have, Australia, United Kingdom, Canada, United States, and so forth. Each of these regional divisions has their own company code, which are barely distinguishable from the next. They make sense to our client, but when we’re not interacting with those codes on a regular basis, we have to look constantly look them up again to make sure we’re dealing with the right record.

I wanted to share something that we did to make this easier for our team to work around these codes, which we should have thought of long ago.

Let’s take the following mode, Division. We only have about 10 records in our database, but have conditional code throughout the site that are dependent upon which divisions specific actions are being triggered within. Each division has various business logic that we have to maintain.

Prior to our change, we’d come across a lot of code like:

1. For all divisions except Canada, invoices are sent via email
2. In Canada, invoices are sent via XML to a 3rd-party service

def process_invoices_for(division)
  if division.code == 'XIUHR12'
    # trigger method to send invoices to 3rd party service
    # ...
  else
    # batch up invoices and send via email
    # ...
  end
end
```bash
An alternative that we'd also find ourselves using was.
```ruby
if division.name == 'Canada'
```ruby
Hell, I think I've even seen `if division.id == 2` somewhere in the code
before. To be fair to ourselves, we did inherit this project a few years
ago. ;-)

Throughout the code base, you'll find business rules like this. Our
developers all agreed that this was far from friendly and/or efficient
and worst of all, it was extremely error-prone. There have been a few
incidents where we read the code wrong and/or got them confused with one
another. We were lacking a convention that we could all begin to rely on
and use.

So, we decided to implement the following change.

### Model Constants

You might already use constants in your Ruby on Rails application. It's
not uncommon to add a few into `config/environment.rb` and call it a
day, but you might also consider scoping them within your models. (makes
it much easier for you to maintain them as well)

In our scenario, we decided to add the following constants to our
`division` model.
```ruby
class Division < ActiveRecord::Base
  AFRICA = self.find_by_code('XYU238')
  ASIA = self.find_by_code('XIUHR73')
  AUSTRALIA = self.find_by_code('XIUHR152')
  CANADA = self.find_by_code('XIUHR12')
  USA = self.find_by_code('XIUHR389')
  # etc..
end
```ruby
What this will do is load up ech of these constants with the
corresponding object. It's basically the equivallent of us doing:
```ruby
if division == Division.find_by_code('XIUHR389')
```text
But, with this approach, we can stop worrying about their codes and use
the division names that we're talking about with our clients. Our client
usually approaches us with, "In Australia, we need to do X,Y,Z
differently than we do in the other divisions due to new government
regulations."
```ruby
if division == Division::CANADA
  # ...
end

case division
when Division::AFRICA
  #
when Division::AUSTRALIA
  # ...
end

We are finding this to be much easier to read and maintain. When we’re dealing with a lot of complex business logic in the application, little changes like this can make a big difference.

If you have any alternative solutions, we’d love to hear them. Until then, we’ve been quite pleased with this approach. Perhaps you’ll find some value in it as well.

I’m working on my presentation for Rails Underground and was hoping to solicit a few tips from other people in the industry.

Have you launched a Ruby on Rails application recently? Are there some things that you wish you had known beforehand?

Mind sharing? You can email me with your story at <robby+launchstory@planetargon.com>. I’ll let you know if your tip gets used in the presentation and please indicate if you’d be okay with me posting your tip in a future blog post.

Earlier today, a friend working on a project asked me how we approached routes on our website. If you take a quick peak at our website, you’ll see that we have URLs like so:

• http://planetargon.com/
• http://planetargon.com/who-we-are
• http://planetargon.com/who-we-are/robby-russell

I couldn’t remember where I came across this before and wasn’t quickly finding it in the Ruby on Rails API, so decided that I’d do a quick write up on it.

When we launched our new site a few months ago, we were working off an existing code base. We have a model named, TeamMember and a corresponding controller. When we decided to come up with new conventions for our URL structure, we opted to ditch the normal Rails conventions and go our own route. What we weren’t sure about was how to alias resources in our routes nicely. After some digging around, we came across the :as option.

So, our route was:

map.resources :team_members{lang=”ruby”}\

Which provided us with:

• /team_members
• /team_members/robby-russell

We simply added :as => 'who-we-are' to our route:

map.resources :team_members, :as => ‘who-we-are’{lang=”ruby”}\

…and we got exactly what we were looking for in our URLs.

```
* /who-we-are
* /who-we-are/gary-blessington
```

If you look at our site, you’ll notice that we did this in a few areas of our application so that we could define our own URL structure that was more friendly for visitors and search engines.

Anyhow, just a quick tip for those who want to change up their URLs with Ruby on Rails.

s., if you know where I can find this documented, let me know so that I can provide a URL in this post for others. :-)

Saw this tweet the other day…

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

So, I have to ask. How many toilets (buckets) do you maintain? How many of them still have projects/tasks in them? Why haven’t you flushed your toilets yet?

It’s time to find my passport again…

{width=”500” height=”375”}

I’ve been invited to speak at Rails Underground, which is being held in London, UK from July 24-25th.

My talk, which is tentatively titled, “Launching Ruby on Rails projects, a checklist”, will expand on several ideas that came out a previous article on the topic. Additionally, I plan to share some of the lessons that we’ve learned at Planet Argon as we’ve launched projects over last several years.

If you’re able to make it, I encourage you to register for the event before it’s too late. Take a quick peak at the list of speakers. I’m grateful to the event organizers for the invite and look forward to seeing/meeting all of the attendees!

Also, for those of you in the London area. If you’re seeking a design and development team that specializes in Ruby on Rails and want to schedule a meeting with me while I’m visiting, don’t hesitate to get in touch with us. I’m planning on staying a few days extra around the conference dates to visit some of our existing clients and would be happy to meet you.