Robby on Rails: Category Ruby

Ruby 1.8.7 on MacPorts causing some problems

Robby Russell — Fri, 20 Jun 2008 16:11:00 -0500

It appears that MacPorts has upgraded to Ruby 1.8.7, which is good news if you’re running Rails 2.1… but if you have an older Rails application… it’s not going to work too well.

In order to get Ruby 1.8.6 installed with the latest MacPorts, you’ll need to do the following.


  $ mkdir /Users/Shared/dports


$ svn checkout -r 36429 \ 
    http://svn.macports.org/repository/macports/trunk/dports/lang/ruby/ \ 
    /Users/Shared/dports/lang/ruby/

Then you’ll need to modify your macports to use this new local source. You’ll need to edit /opt/local/etc/macports/sources.conf and add the following line above the existing rsync record.

file:///Users/Shared/dports and create that directory

Next, you’ll want to index this new local source with the following command:

portindex /Users/Shared/dports

After that, you can do the following.

sudo port uninstall rb-rubygems ruby

sudo port clean rb-rubygems ruby

sudo rm -r /opt/local/lib/ruby/gems/1.8/doc/rubygems-1.1.1/

sudo port deactivate autoconf

sudo port install ruby rb-rubygems

..and hopefully you’ll have Ruby 1.8.6 installed and be able to retain the rubygems you installed already.

I am forking Rails

Robby Russell — Wed, 02 Apr 2008 15:01:00 -0500

...well, creating a fork on GitHub. ;-)

Uploaded with plasq’s Skitch!

It appears that Rails is moving from Subversion to Git!

Courtenay posted this a little while ago.


git clone git://github.com/rails/rails.git

Check it out the Ruby on Rails project on GitHub.

Start working on your next patch with git…


git clone git://github.com/rails/rails.git
cd rails
git br -a
git br my_patch
git co my_patch

This is cool news. :-)

Tip: Link to Unimplemented

Robby Russell — Thu, 27 Mar 2008 06:10:00 -0500

Throughout our design and development process, we’re working around areas of the site that are not yet implemented but we also want to be able to allow our clients to demo their application. In an effort to manage their expectations, we need to be careful about what we link to. If a page/widget isn’t ready to be demo’d yet, we should avoid providing pathways to get interact with or navigate there. However, when we’re implementing HTML/CSS for pages, it’s sometimes makes sense to not hide certain things on the screen.

For example, let’s suppose that you’re working on the primary navigation of an application. You know what the other sections are going to be, but you’ve only implemented a few of them so far. Your HTML/CSS person is working on the design for the navigation and wants to have them be proper links… even to pages that don’t yet exist.

One option, which is quite common, is to provide a link with href="#". This works to some extent, but when people click on things, they naturally expect something to happen in response.

This approach doesn’t mesh well with our team as we don’t really want to field any questions like, “the navigation links are all broken. Nothing happens!”

So, a pattern that we’ve been using for a while is to trigger a javascript alert for every link within an implemented area that is linking to something that isn’t yet implemented.

Let’s take a really basic javascript function like:


# public/javascripts/application.js
function unimplemented() {
  alert("NOTICE\n\nThis feature is not implemented yet. Please check back again soon!");
}

This allows us to do the following:


  <a href="javascript:unimplemented();">link text</a>

When someone clicks the link, they’ll see a typical javascript alert message. This informs our clients/beta testers that we’re paying attention to what works and what doesn’t.

Uploaded with plasq’s Skitch!

Let’s take it a step further and push this into a view helper.


# app/helpers/application_helper.rb
def link_to_unimplemented( link_text, *args )
  link_to_function( link_text, 'unimplemented()', *args)
end

Now, we’re able to use link_to_unimplemented and pass any arguments that you’d pass to the default link_to view helper.


<%= link_to_unimplemented( 'link text', { :class => 'link_class_name' } ) -%>

Now our web designers can go about their work and use this helper as necessary.

An nice benefit for doing this is that we have a pattern that we follow so that we can rely upon to make sure that we don’t forget anything. This is the equivalent of adding @TODO@s throughout our code base.

If we search through app/views for ‘link_to_unimplemented’ we should be able to prevent missing any broken links. In the next screenshot, I’m using grep with colorized matches.

Uploaded with plasq’s Skitch!

As you can see, we have something left to implement in that area of the application. :-)

This has been one of those lightweight patterns that we’ve been able to adopt and it’s definitely helped manage the expectations of our clients throughout our development process.

I’d love to hear your thoughts on this. How does your team handle things like this?

Managing Required Gems on Rails Projects

Robby Russell — Wed, 26 Mar 2008 22:27:00 -0500

We’re starting a new project and I’m finding myself adding things to the code base that we’ve done in the past… hence the last few posts. As we’re doing this, I’d like to highlight some of the little things that we do on each project to maintain some consistency and in that process reach out to the community for alternative approaches.

I’m intrigued by the vendor everything concept, but we haven’t yet adopted this on any of our projects (yet).

What we have been doing is to maintain a REQUIRED_GEMS file in the root directory of our Rails application.

For example:


$ cat REQUIRED_GEMS

actionmailer
actionpack
actionwebservice
activerecord
activesupport
cgi_multipart_eof_fix
daemons
fastercsv
fastthread
feedtools
gem_plugin
image_science
mongrel
mongrel_cluster
mysql
rails
rake
RedCloth
Ruby-MemCache
soap4r
uuidtools

Everybody on the team (designers/developers) knows to look here to make sure they have everything installed when beginning to work on the application.

This has worked fairly well from project to project but since we’re starting a new project, I’m curious if anybody has some better ways to approach this. Should we look more seriously at the vendor everything approach or are there any alternative approaches?

Managing SEO-friendly HTML Titles with Rails

Robby Russell — Wed, 26 Mar 2008 16:41:00 -0500

I’ve seen this come up a few times in the #rubyonrails IRC channel and figured that I’d post a quick entry for future reference.

Problem: HTML titles

You want to have a clean way to manage the titles on your HTML pages.


  <html>
    <head>
      <title>Robby on Rails &mdash; Article Title Goes Here</title>
    </head>
    <body>
      ...

Possible Solution(s):

Since the <title> tag is usually declared in your layout, you need to be able to dynamically update this information from almost every action in your application.

Here are a few ways that I’ve seen this handled.

Use a instance variable, which would have a default value and you could override it in any controller action
Use the content_for method to manage it.

Let’s take a few minutes to look at these two approaches.

Instance Variable

With the instance variable, you might end up with something like:


  # app/views/layouts/application.html.erb
  <title>Robby on Rails &mdash; <%= @html_title || 'Default text here...' -%></title>

Then in a controller action…


  # app/controllers/articles_controller.rb
  def show
    # ...
    @html_title = @article.title
  end

So, that’s one way to handle it and is probably a more common way.

The `content_for` helper method approach

This solution is very similar (and underneath uses an instance variable).

We’ll use the content_for and a little yield action.


  # app/views/layouts/application.html.erb
  <title>Robby on Rails <%= (html_title = yield :html_title) ? html_title : '&mdash; Default text here...' %></title>

Then we’ll create a helper method.


  # app/helpers/application_helper.rb
  def set_html_title(str="")
    unless str.blank?
      content_for :html_title do
       "&mdash; #{str} " 
      end
    end
  end

Now, instead of defining the HTML <title> value in the controllers, we’ll just toss this into our html.erb files as necessary.


  <% set_html_title(@article.name) -%>
  ... rest of view

..and that’s pretty much it.

Which is the better solution?

This is where we’ll not find a lot of consensus amongst people. I’m a fan of the content_for-based approach and defining the title in views rather than in controller actions. I’m an advocate of skinny controllers and while I’m not a big fan of messy views, I believe that there is less overhead in managing this within the View-world.

I’d love to hear your thoughts on this. Perhaps you have a more eloquent for managing things like this? Do share. :-)

Things (in the Rails world) You Don't Yet Understand

Robby Russell — Tue, 25 Mar 2008 10:12:00 -0500

This is inspired by a recent post by Seth Godin titled, Things you don’t understand, where he shared a list of things that he probably could understand if he put your mind to it, but doesn’t. I decided to post a list of five (5) things in response within the context of Ruby/Rails.

I’m really interested in various things but am really unable to prioritize them high enough to spend the time to understand them.

RSpec User Stories
Using Selenium with RSpec
JQuery (Graeme speaks highly of it)
JSSpec (BDD for Javascript)
Using the Google Charts API with Rails

What about you? What’s your list of things that you’d like to understand more about?

DRY(a): Year After Year

Robby Russell — Mon, 24 Mar 2008 22:05:00 -0500

I’m guilty of it. Many of you are likely guilty of it… and I know that several customers of our Rails Code Audit and Review service are guilty of it.

How many times have you realized (after a few months has passed) that your Copyright date/year on your web site was no longer current?

How many of you had the same problem last year? The year before?

Let me share some advice with you all… DRY (a)!

Don’t Repeat Yourself (again)!

This is really a simple problem to fix but when we’re busy tackling bigger problems… little things like this slip by. Don’t worry, you’re not the only one who was reminded by a colleague three months into the year that you forgot to update this.

On client projects, we have a handful of helpers that we drop into the application. We’re starting to extract more of these into plugins and will be releasing those as time permits. It just happened that I found myself looking at yet-another Rails code base this afternoon that was showing 2007 in the footer. An easily forgivable offense.. but if you’re going to go in there and change it (again), take a moment to do the right thing. ;-)

Our solution at Planet Argon on client projects is to create a basic view helper that renders the current year. This allows us to do the following.


  <div id="footer">
    &copy; Copyright <%= current_year -%>. All Rights Reserved.
  </div>

The helper code looks like:


  # add to application_helper.rb
  module ApplicationHelper
    def current_year
      Time.now.strftime('%Y')
    end
  end

Voila. Not rocket science.. is it?

Guess what? I’m getting really tired of adding this to every Rails project that I touch. So, I bottled this little gem into a new Rails plugin that we’ll just add to future projects.

Introducing Year after Year

This is really the smallest plugin that I could put together (and it includes specs!)

What does it provide you?

YearAfterYear will provide you a helper that will render the current year (dynamically)! That’s right… just add the plugin to your Rails application and you too can enjoy New Years 2009 without having to have a deployment ready with a one line change from 2008 to 2009!

To use.. add the following to any view from within Ruby on Rails.


  <%= current_year -%>

Installation

As I’m using git, you’ll need to grab this and put it into vendor/plugins. That’s it!

You can grab it on GitHub!

http://github.com/robbyrussell/year_after_year/
Bugs / Feature Requests here

Happy New Years (8+ months early)!

Just a friendly reminder to not forget the small stuff… because your visitors will notice! ;-)

Updates…

I got a few requests for this to also provide a range of years for people who like to do: 2005-2007. So this is now provided as well.

year_range(start_year)

Example:


  <%= year_range(2005) %> # => 2005-2008

Deploying Rails with an interactive Capistrano recipe to your Boxcar

Robby Russell — Thu, 28 Feb 2008 16:27:00 -0600

I wanted to share something that I’ve been meaning to share on here.

When we began planning Rails Boxcar, we really want to reduce the amount of work that it took to setup and deploy a VPS for a Rails application. During this period, we began to look at the deployment process itself and began working on an interactive tool for developers for setting up their deployment environment on their Boxcar instances. So, we worked with few customers to develop an interactive Capistrano recipe.

The Goal? Spend less time configuring the server or editing recipe files.

During the initial setup, we can have the customer provide a few details from the safety of their Rails application directory by answering the following.

What database server will you be using? (PostgreSQL or MySQL)
What port does your database run on? (if different than the default for your db server)
What is your database username?
What is your database user’s password?
What port will your mongrel cluster start with?
How many mongrel servers should your cluster run?

Great… setup the server and let’s deploy!

Uploaded with plasq’s Skitch!

Feel free to snag our interactive Capistrano2 recipe.

We’re trying to take the pain out of deploying your Ruby on Rails applications with Boxcar.

On a side note, we’re in the process of expanding our team and recently hired Alex Malinovich. Do stay tuned as we’ll be posting important announcements about changes to our Rails hosting services in the next few weeks. (grin)

Installing Ruby on Rails and PostgreSQL on OS X, Third Edition

Robby Russell — Tue, 22 Jan 2008 11:55:00 -0600

Over the past few years, I’ve helped you walk through the process of getting Ruby on Rails up and running on Mac OS X. The last version has been getting a lot of comments related to issues with the new Apple Leopard, so I’m going this post will expand on previous installation guides with what’s working for me as of January 2008.

The following guide is how our development team at Planet Argon prefers to setup our development workstations

During this installation, we’ll have what we feel is the optimal development stack for building Ruby on Rails applications with our favorite database server, PostgreSQL.

Ready? Let’s get started…

Phase One

During this initial phase, we’re going to install the underlying dependencies that we’ll be building off of.

XCode 3.0

The first thing that you’ll need to install to get far with this process is XCode tools, which is distributed by Apple. You can find this on the DVD that your Leopard installer is on. You can also download the latest version from Apple’s developer site.

http://developer.apple.com/tools/download/

The current version (3.0) is 1.1 GB.. so the download time will vary depending on your connection speed. I would encourage you to drink some tea and/or read a book

Once you finish the installation, you can move forward. The rest of these installation will not work until XCode is installed. :-)

MacPorts

In this next step, we’ll install MacPorts (formerly known as DarwinPorts). The MacPorts web site describes itself as, “an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the Mac OS X operating system.”

This tool is about to become one of the most important tools on your operating system as it’ll be used time and time again to maintain your libraries and many of the Unix tools that you’ll be using. If you’re from the Linux or BSD world, you are likely familiar with similar tools… such as: apt-get, port, and yum.

First, you’ll want to download MacPorts and install the “dmg” disk file for Leopard at the following link.

http://www.macports.org/install.php

Once downloaded, you’ll want to run the installer and install it on your workstation.

Work you way through the installer until successfully installed.

Once this finishes, you can open up your favorite terminal application and run the following to test that it installed properly.

In my case, I’m now using Terminal.app.

Issue the command: /opt/local/bin/port version

If it responds with a version number like mine did in the screenshot above, we’re moving along nicely.

Environment Paths

When we install MacPorts, the command to install/update ports installed to /opt/local/bin. We had to provide the entire path as this isn’t currently showing up in the default $PATH on Leopard. Let’s quickly remedy this by modifying the file /etc/profile.

If you have Textmate installed, you can run the following from your terminal: mate /etc/profile

Add the following line to the bottom of /etc/profile.

export PATH=/opt/local/bin:/opt/local/sbin:$PATH

You can use your favorite editor to update this file. Once you save it, you’ll want to restart your terminal application (or open a new tab) to create a new session. When your new terminal opens, run the following to verify that port is showing up in your $PATH.

which port

You should see /opt/local/bin/port show up as the result of this command.

Great, let’s continue to move forward.

Hiding Apple’s Ruby, Gems, and Rails

Before we install Ruby from MacPorts, we’ll go ahead and hide Apple’s Ruby installations.


    :~ robbyrussell$ sudo su -
    Password:
    :~ root# mv /usr/bin/ruby /usr/bin/ruby.orig
    :~ root# mv /usr/bin/gem /usr/bin/gem.orig
    :~ root# mv /usr/bin/rails /usr/bin/rails.orig
    :~ root# logout

If you ever decide to remove MacPorts, you can just rename ruby.orig back to ruby and you’re back where you started… and the same for the others listed.

Phase Two

During this next phase, we’re going to install Ruby and Ruby on Rails.

Installing Ruby via MacPorts

Now that we have MacPorts up and running, we’re going to use it for the first time. We’ll start by using it to install Ruby and the Rubygems package.

$ sudo port install ruby rb-rubygems

Okay, this will take a little while. I’d suggest that you step out to get some fresh air.

How was it outside? What’s the weather like there today? It’s currently 2:30am PST so it’s dark and an 28F outside so I didn’t stay outside very long.

If you’re still waiting for it to install, perhaps you could watch the following video. I might encourage you to check out more of Jam, which was recommended a few years ago to me by James Adam at Canada on Rails.

Be warned… it’s a strange show, but I find strange things like this funny. :-)

If you prefer something a bit more lighthearted…

Okay… when Ruby finishes installing, you’ll want to test that you can run it.

$ ruby -v

Great, let’s move forward!

Installing Ruby on Rails via RubyGems

We’re now going to install the libraries that make up Ruby on Rails via RubyGems.

$ sudo gem install --include-dependencies rails

This will install the following gems.

rails-2.0.2
rake-0.8.1
activesupport-2.0.2
activerecord-2.0.2
actionpack-2.0.2
actionmailer-2.0.2
activeresource-2.0.2

Excellent, let’s move forward…

If you haven’t already purchased it, I recommend that you take a look at The Rails Way (Addison-Wesley Professional Ruby Series) by Obie Fernandez.

Installing Mongrel via RubyGems

Let’s now install Mongrel, which is an excellent Ruby-based web server for Ruby on Rails applications. We use it in development and production at Planet Argon and it’s also what we recommend to our hosting customers.

$ sudo gem install --include-dependencies mongrel mongrel_cluster

Note: Be sure to select the proper platform for mongrel. (hint: OS X is NOT mswin32)

My terminal output:


Select which gem to install for your platform (i686-darwin9.1.0)
 1. mongrel 1.1.3 (java)
 2. mongrel 1.1.3 (i386-mswin32)
 3. mongrel 1.1.3 (ruby)
 4. mongrel 1.1.2 (ruby)
 5. mongrel 1.1.2 (mswin32)
 6. mongrel 1.1.2 (java)
 7. Skip this gem
 8. Cancel installation
> 3
Select which gem to install for your platform (i686-darwin9.1.0)
 1. fastthread 1.0.1 (mswin32)
 2. fastthread 1.0.1 (ruby)
 3. Skip this gem
 4. Cancel installation
> 2
Building native extensions.  This could take a while...
Building native extensions.  This could take a while...
Successfully installed mongrel-1.1.3
Successfully installed gem_plugin-0.2.3
Successfully installed daemons-1.0.9
Successfully installed fastthread-1.0.1
Successfully installed cgi_multipart_eof_fix-2.5.0
Installing ri documentation for mongrel-1.1.3...
Installing ri documentation for gem_plugin-0.2.3...
Installing ri documentation for daemons-1.0.9...
Installing ri documentation for fastthread-1.0.1...

No definition for dummy_dump

No definition for dummy_dump

No definition for rb_queue_marshal_load

No definition for rb_queue_marshal_dump
Installing ri documentation for cgi_multipart_eof_fix-2.5.0...
Installing RDoc documentation for mongrel-1.1.3...
Installing RDoc documentation for gem_plugin-0.2.3...
Installing RDoc documentation for daemons-1.0.9...
Installing RDoc documentation for fastthread-1.0.1...

No definition for dummy_dump

No definition for dummy_dump

No definition for rb_queue_marshal_load

No definition for rb_queue_marshal_dump
Installing RDoc documentation for cgi_multipart_eof_fix-2.5.0...
Successfully installed mongrel_cluster-1.0.5

Great, you have almost all of the essentials.. except a database.

Phase Three

In this phase, we’re going to get our database server, PostgreSQL, installed and the libraries that Ruby needs to communicate with it.

Installing PosgreSQL with MacPorts

At Planet Argon, we design and develop our applications on top of PostgreSQL. I’ve been advocating the adoption of this awesome open source database in the Rails community for quite some time now.

The current version available of PostgreSQL via MacPorts is 8.3, which is what we’ll now install with the port command.

$ sudo port install postgresql83 postgresql83-server

This will download and install the necessary libraries to run PostgreSQL server and the client utilities.

Configuring PostgreSQL

When PostgreSQL is finished installing, it’ll tell you to run the following commands to create a new database instance.


 sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb
 sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb
 sudo su postgres -c '/opt/local/lib/postgresql83/bin/initdb -D /opt/local/var/db/postgresql83/defaultdb'

Adding PostgreSQL to launchd

If you’d like to have PostgreSQL automatically startup after a system restart, you can load it into launchd, which comes with OS X. By running the following command, PostgreSQL will startup automatically on the next system restart.

sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist

Adding PostgreSQL to your $PATH

For some reason, the MacPort for PostgreSQL doesn’t get the programs in your path automatically, so we’ll it now.

mate /etc/profile

Modify the PATH that we changed earlier to include /opt/local/lib/postgresql83/bin@.

export PATH=/opt/local/bin:/opt/local/sbin:/opt/local/lib/postgresql83/bin:$PATH

Save the file and then open a new terminal. To test this, you should get the following output when you run which psql.


  $ which psql
  /opt/local/lib/postgresql83/bin/psql

Creating a new PostgreSQL user

When I’m working on Rails applications in my development environment, I really don’t want to have to specify a username and password in every config/database.yml file for each of our ongoing client projects. When PostgreSQL was installed, it created a superuser named postgres, which is great, but I’d like one that matches my system username, so that I’m not prompted at all for a username or password to connect to PostgreSQL.

To do this, we’ll use the createuser command, which comes with PostgreSQL. As you can see, I’m creating a new user with superuser privileges (and will hopefully be the last time I have to do a -U postgres).


  $ createuser --superuser robbyrussell -U postgres
  CREATE ROLE

Let’s take a quick moment to test this out.


  # create a new database
  $ createdb my_test_db
  CREATE DATABASE

  # drop the database
  $ dropdb my_test_db
  DROP DATABASE

Great, everything looks good here.

We now have a running installation of PostgreSQL with a new user account. All we need to do now is install the appropriate RubyGem to allow our Ruby applications to connect to it.

Installing PostgreSQL Libraries for Ruby

You can install postgres gem by running the following command.

$  sudo gem install --include-dependencies postgres

Great. We’ve now built a professional development environment for working with Ruby on Rails. Can you feel the excitement? :-)

Closing Thoughts

Like the previous versions, I hope that a few people find this useful. I didn’t have to make a lot of changes from the second edition, but there were enough to warrant a new post. I’ve been setting up my workstation like this for about three years now and I’m looking forward to seeing how a fresh install on Leopard works out for me.

If you have any problems, feel free to ask a question in the comments below.

ShortURL 0.8.4 released and gets a new mainainer... me!

Robby Russell — Sun, 06 Jan 2008 18:49:00 -0600

Earlier today, Vincent Foley was kind enough to hand over maitenance of the the ShortURL project on RubyForge to me. He first released it back in 2005, which I blogged about as RubyURL was the first shortening service that it supported (and is the default). Unfortunately, the release of RubyURL 2.0 broke backwards compatibility and Vincent wasn’t maintaining it anymore. So, earlier, I decided to patch this and got a new version released that now works with the current RubyURL site.

While working on the code, I decided to extend the compatible services to include moourl and urlTea.

These updates are available in ShortURL version 0.8.4.

Install the ShortURL gem

Installation is a snap… (like 99.7% of rubygems…)


  ~ > sudo gem install shorturl                                                                                                                                                                                                           Password:

  Successfully installed shorturl-0.8.4
  1 gem installed
  Installing ri documentation for shorturl-0.8.4...
  Installing RDoc documentation for shorturl-0.8.4.

Using ShortURL

The ShortURL gem provides the ShortURL library, which you can use from any Ruby application.

Using the ShortURL library


  ~ > irb                                                                                                                                                                                                                           
  irb(main):001:0> require 'rubygems'
  => true
  irb(main):002:0> require 'shorturl'
  => true
  irb(main):003:0> ShortURL.shorten( 'http://www.istwitterdown.com' )
  => "http://rubyurl.com/P9w"

As you can see…it’s really straight forward.

Let’s try it with a few other services.


irb(main):004:0> ShortURL.shorten( 'http://www.istwitterdown.com', :moourl )
=> "http://moourl.com/fvoky" 
irb(main):005:0> ShortURL.shorten( 'http://www.istwitterdown.com', :tinyurl )
=> "http://tinyurl.com/2t3qmh"

Using the shorturl command-line tool

Many people don’t know that ShortURL provides a command-line tool, which you can use after installing the gem.


  ~ > shorturl http://istwitterdown.com                                                                                                                                                                                               
  http://rubyurl.com/Lwk

If you’d like to see more services provided than the ones listed here, please submit feature requests and/or patches on the rubyforge project.

http://rubyforge.org/projects/shorturl/

ShortURL Documentation

To see the latest documentation for the project, please visit:

http://rubyforge.org/projects/shorturl/

My favorite part about this? My rbot plugin for RubyURL works again!

Uploaded with plasq’s Skitch!

Happy URL-shortening!

PGCon 2008 - Call for Papers

Robby Russell — Fri, 28 Dec 2007 10:58:00 -0600

Are you using PostgreSQL (the world’s most awesome open-source database server) with Ruby on Rails? Do you have any interesting experiences that you might want to share with an audience? Well, you might consider submitting a talk proposal for PGCon 2008, which is taking place in Ottawa, Canada.

Details follow…

PGCon 2008

PGCon 2008 will be held 22-23 May 2008, in Ottawa at the University of Ottawa. It will be preceded by two days of tutorials on 20-21 May 2008.

We are now requesting proposals for presentations.

If you are doing something interesting with PostgreSQL, please submit a proposal. You might be one of the backend hackers or work on a PostgreSQL related project and want to share your know-how with others. You might be developing an interesting system using PostgreSQL as the foundation. Perhaps you migrated from another database to PostgreSQL and would like to share details. These, and other stories are welcome. Both users and developers are encouraged to share their experiences.

Here are a few ideas to jump start your proposal process:

novel, unique or complex ways in which PostgreSQL are used
migration of production systems to PostgreSQL
data warehousing with PostgreSQL
tuning PostgreSQL for different work loads
replicating data on top of PostgreSQL

Both users and developers are encouraged to share their experiences.

The schedule is:

19 Dec 2007 Proposal acceptance begins
19 Jan 2008 Proposal acceptance ends
19 Feb 2008 Confirmation of accepted proposals
19 Apr 2008 Final papers/slides must arrive no later than this date

Instructions for submitting a proposal to PGCon 2008 are available from: http://www.pgcon.org/2008/submissions.php

This

Get to Know a Gem: Rak

Robby Russell — Tue, 11 Dec 2007 11:10:00 -0600

A few months ago, I posted about an article that showed you how to colorize your grep search results. Since then, I’ve heard people talking about ack, which describes itself as…

“a tool like grep, aimed at programmers with large trees of heterogeneous source code.”

It’s written in Perl, which is fine and dandy… but before I installed it, I heard that there was a Ruby version named rak, which describes itself as…

“a grep replacement in pure Ruby. It accepts Ruby syntax regular expressions and automatically recurses directories, skipping .svn/, .cvs/, pkg/ and more things you don’t care about. “

Sounds great. Let’s see what this thing can do.

Installing rak

Daniel Lucraft, the author of rak, was kind enough to package it up as a Rubygem. So, all we have to do is install it via gem install rak.


   > sudo gem install rak                                                                                                                                                                                                     
  Password:
  Bulk updating Gem source index for: http://gems.rubyforge.org
  Successfully installed rak-0.8.0
  Installing ri documentation for rak-0.8.0...
  Installing RDoc documentation for rak-0.8.0...
  ~ >

Great, let’s move on.

Using rak

Now that it’s installed, we can use Rak by typing rak from the command line. You’d typically want to run this from within the root of your application.

For example, basic usage would look like the following.

$ rak search-pattern

In my first test, I ran rak README.

Immediately, I see a greater advantage to rak over using grep and that’s because it’s giving me line numbers for free, which takes remembering a few extra options with grep.

Like grep, we can specify a specific path to search with. For example, we use a view helper named link_to_unimplemented to help us track actions that aren’t implemented yet. Looking at a current project, I can run rak link_to_unimplemented app/views and produce the following results.

I’m going to keep playing with it, but wanted to help get the word out. If you have any tips on using it, please share them in the comments. :-)

Master/Slave Databases with Ruby on Rails

Robby Russell — Thu, 15 Nov 2007 16:02:00 -0600

Not terribly long ago, I announced Active Delegate, which was a really lightweight plugin that I developed to allow models to talk to multiple databases for specific methods. The plugin worked great for really simple situations, like individual models.. but when it came time to test with associations it fell apart. I haven’t had a chance to work on any updates and knew that it was going to take more work to get it going.

Earlier this week, we helped one of our bigger clients launch their new web site¹. For the deployment, we needed to send all writes to a master database and a reads to slaves (initial deployment is talking to almost 10 slaves spread around the globe!). We needed something to get integrated quickly and decided to ditch Active Delegate for the time being and began looking at the following options.

I spoke with Rick Olson² and he pointed me to a new plugin that he hasn’t really released yet. So, I’m going to do him a favor and announce it for him. Of course… I got his permission first… ;-)

Announcing Masochism!

Masochism³ is a new plugin for Ruby on Rails that allows you to delegate all writes to a master database and reads to a slave database. The configuration process is just a few lines in your environment file and the plugin takes care of the rest.

Installing Masochism

With piston, you can import Masochism with:


  $ cd vendor/plugins
  $ piston import http://ar-code.svn.engineyard.com/plugins/masochism/

To learn more about piston, read Every Second Counts with a Piston in your trunk

You can also install it with the old-fashioned way:


  $ ./script/plugin install -x http://ar-code.svn.engineyard.com/plugins/masochism/

Configuring Masochism

The first thing that you’ll need to do is add another database connection in config/database.yml for master_database. By default, Masochism expects you to have a production database, which will be the read-only/slave database. The master_database will be the connection details for your (you guessed it…) master database.


# config/database.yml  
production:
  database: masochism_slave_database
  adapter: postgresql
  host: slavedb1.hostname.tld
  ...

master_database:
  database: masochism_master_database
  adapter: postgresql
  host: masterdb.hostname.tld
  ...

The idea here is that replication will be handled elsewhere and your application can reap the benefits of talking to the slave database for all of it’s read-only operations and let the master database(s) spend their time writing data.

The next step is to set this up in your environment file. In our scenario, this was config/environments/production.rb.



# Add this to config/environments/production.rb
config.after_initialize do 
  ActiveReload::ConnectionProxy.setup!    
end

Voila, you should be good to go now. As I mentioned, we’ve only been using this for this past week and we’ve had to address a few problems that the initial version of the plugin didn’t address. One of our developers, Andy Delcambre, just posted an article to show how we had a problem with using ActiveRecord observers and masochism, which we’re sending over a patch for now.

As we continue to monitor how this solution works, we’ll report any findings on our blog. In the meantime, I’d be interested in knowing what you’re using to solve this problem. :-)

¹ Contiki, a cool travel company we’re working with

² Rick just moved to Portland… welcome to stump town!

³ The Masochism plugin README

Using MacPorts Ruby and Rails after Upgrading to OS X Leopard

Robby Russell — Sat, 27 Oct 2007 05:43:00 -0500

If you previously followed my article, Installing Ruby on Rails and PostgreSQL on OS X, second edition and are now upgrading to OS X Leopard, you’ll want to make a few adjustments to your setup.

First of all, it’s great that Apple has decided to provide Ruby on Rails out of the box.


~ > gem list rails                                                                                                                                                                   
  *** LOCAL GEMS ***

  rails (1.2.3)
      Web-application framework with template engine, control-flow layer,
      and ORM.

How many gems does it come with?


~ > gem list|grep '^[a-z]'|wc -l                                                                                                                                                     
      29

It’s really great that Apple shipped Leopard pre-installed with 29 gems, especially if you don’t have your entire Rails stack setup already. In my case and for those that have followed my installation process, you don’t need to switch over to this new development stack (yet). I have a lot of time invested in my fully-functionaly MacPorts installation process (PostgreSQL, MySQL, RMagick, Subversion, Git, etc. Since this all working fine on my machine, I’m not ready to make the switch to Apple’s installation.

Don’t Fix it… if it’s not broken!

So, the the first thing that I did was modify my PATH environment variable, which has /usr/bin as the first path that it’ll look at when you try to run commands like ruby, mongrel_rails, gem, etc. You’ll want to modify this and prepend /opt/local/bin: to the front of PATH in your shell configuration. If you’re using bash, this would be… ~/.bashrc. If you’re using zshell like me, ~/.zshrc.

Now, when you start a new Terminal and run gem list, you’ll see all of the gems that you already have installed.


~ > gem list rails                                                                                                                                   < new-host

*** LOCAL GEMS ***

rails (1.2.5, 1.2.4, 1.2.3, 1.1.6)
    Web-application framework with template engine, control-flow layer,
    and ORM.

Back to my happy gems…


~ > gem list|grep '^[a-z]'|wc -l                                                                                                                                                              < new-host
      72

Great! Now I can get back to work and spend time playing with the new features in Finder, Mail.app, and iChat instead of installing all of the software dependencies that our development projects have. :-)

Chad Fowler's Dirty Little Secret?

Robby Russell — Sat, 06 Oct 2007 15:00:00 -0500

I saw this photo of the Microsoft team from 1978 on Anselm’s flickr and thought, “Hmm, that looks like Chad Fowler!”

Could this be Chad Fowler’s dirty little secret?..

Happy Saturday!

Multiple Database Connections in Ruby on Rails

Robby Russell — Fri, 05 Oct 2007 17:54:00 -0500

We have a client that already has some database replication going on in their deployment and needed to have most of their Ruby on Rails application pull from slave servers, but the few writes would go to the master, which would then end up in their slaves.

So, I was able to quickly extend ActiveRecord with just two methods to achieve this. Anyhow, earlier today, someone in #caboose asked if there was any solutions to this and it prompted me to finally package this up into a quick and dirty Rails plugin.

Introducing… Active Delegate!

To install, do the following:


cd vendor/plugins;
piston import http://svn.planetargon.org/rails/plugins/active_delegate

Next, you’ll need to create another database entry in your database.yml.


login: &login
  adapter: postgresql
  host: localhost
  port: 5432

development:
  database: rubyurl_development
  <<: *login

test:
  database: rubyurl_test
  <<: *login

production:
  database: rubyurl_servant
  <<: *login

# NOTICE THE NEXT ENTRY/KEY
master_database:
  database: rubyurl_master
  <<: *login

At this point, your Rails application won’t talk to the master_database, because nothing is being told to connect to it. So, the current solution with Active Delegate is to create an ActiveRecord model that will act as a connection handler.


  # app/models/master_database.rb
  class MasterDatabase < ActiveRecord::Base
    handles_connection_for :master_database # <-- this matches the key from our database.yml
  end

Now, in the model(s) that we’ll want to have talk to this database, we’ll do add the following.


  # app/models/animal.rb
  class Animal < ActiveRecord::Base
     delegates_connection_to :master_database, :on => [:create, :save, :destroy]
  end

Now, when your application performs a create, save, or destroy, it’ll talk to the master database and your find calls will retrieve data from your servant database.

It’s late on a Friday afternoon and I felt compelled to toss this up for everyone. I think that this could be improved quite a bit, but it’s working great for the original problem that needed to be solved.

If you have feedback and/or bugs, please send us tickets.

PLANET ARGON is seeking fresh talent... could it be you?

Robby Russell — Thu, 04 Oct 2007 10:10:00 -0500

My blog has been fairly quiet lately because our team has been busy helping push a few big client projects out the door. We’ll be posting announcements about those launches on the PLANET ARGON Blog soon, so stay-tuned there!

We’ve been growing the design-side of our team lately, but we’re also still seeking some more Rails-talent in Portland, OR. If you’re in Portland or interested in moving here¹, you should introduce yourself to our team. We’re looking for people to work on-site in Portland, so any remote candidates will be turned away… we’re moving into a shiny and new office space in downtown and are looking for another developer to join our Design and Development team.

you’ll fit in really well if you’re into outdoor activities… ;-)

We’re seeking mid-level Ruby on Rails developers that can pick things up quickly. Having some experience with RSpec will go along way with us. Ideal candidates would have great communication skills and be able to work in a fast-paced environment that places a huge emphasis on collaboration between designers and developers (let’s not forget to mention our clients). Bring what you already know and learn the rest with us.

While everyone might have Wii’s in the office, we’ve taken it to the next level with Speed Stacking! :-p

To apply, send an email to af22+8509@c1.catchthebest.com,

Side note: We’re giving Catch the Best a whirl to review job candidates. If you’re hiring people, you might consider giving it a try.

¹ Everybody is moving to Portland… ;-)

Edge Rails Documentation: Revisited

Robby Russell — Wed, 26 Sep 2007 08:34:00 -0500

This question, “where can I find documentation for Edge Rails?” still comes up quite often on mailing lists, IRC, and other places. I just wanted to point out a few resources for you.

In March 2006, our team announced that we’d be updating a RDOC site a few times a day as the Rails project gets commits.

You can still access the PLANET ARGON Edge Rails documentation here:

http://edgedocs.planetargon.org

Caboose also has some Edge Rails documentation here:

http://caboo.se/doc.html

If you’re aware of any other online resources for Edge Rails documentation, please let me know.

Rails Business: "Weekly" Review #4

Robby Russell — Tue, 25 Sep 2007 08:59:00 -0500

As I mentioned in my last review, I wouldn’t be updating on a weekly basis, which is a shame because there are so many fascinating discussions going on that might benefit you if you’re running a business that uses and/or relies on the Ruby on Rails framework. I’d like to highlight some of the discussions that have been taking place over the past month or so.

First off… wow! As of this morning, there are 650 members!

Some Recent Discussions

Obtaining Ruby Gigs

Johan Pretorius started a discussion with the following…

“I’ve been lurking on the group for a while now, the time has come to participate … What strategy would you recommend for somebody that wants to break into the Ruby (on Rails) market?”

On a related topic, Jose Hurtado started a discussion asking for tips on how to get a reputation in the Ruby on Rails community for you business.

Some of the responses included:

Start a portfolio
Contribute to Open Source projects
Contribute to Rails through Documentation
Subcontract through well-known developers
Start a blog
Write a book

Read the entire thread and please share any other ideas that you have on this topic with Johan, Jose, and rest of the list. :-)

Taking a full-time job, what about your freelance clients?

Oren writes, “I got a full-time job offer as employee (and not on as a contractor). My current client might need some help on the weekends in the next month, so I might still do contract work. Can I keep my corporation (corp S) while working full time?”

Read the responses

Reality Check!

Starting your own business might sound like an amazing thing to do, but it often comes with a lot of consequences and struggles, which I’m definitely not been immune to.

Michael M. writes, ”...added to having to create a company, perform customer support, continue to grow the features, marketing, and the loads of other things I haven’t thought of yet…is there any hope that one person can pull this off while still working at my current job ( with hopes of going it alone when I’m sure it can fly ), and giving time to my family, with very little up front costs. I’ve been reading quite a bit about bootstrapping lately, but to really make the time has been very difficult.”

There were several thoughtful responses where well-known members of the Ruby on Rails community, such as Joe O’Brien Ben Curtis shared through personal experiences.

Joe O’Brien wrote, “I wanted to mainly chime in on the family part. Something that has taken a year for me to figure out how to balance. I would not have been able to do any of it, had it not been for my wife’s full support. I have three kids, all of whom I love spending time with, so figuring out a way to balance it all has been very tricky. Up front though, my wife and I knew this would not be your typical job. It helped that I used to travel and now do not, but it has still been an adjustment.”

If you’ve been running your own Rails business, please consider responding to this thread and sharing your experience.

Join the Community

As mentioned, this is just a small sample of some of the great discussions taking place on the Rails Business mailing list. If you’re an aspiring Rails freelancer or business owner, be sure to join the community and share your experiences and learn from other members of the community that are willing to share theirs.

As always, have fun!

Rails Development Performance Tip - dev_mode_performance_fixes

Robby Russell — Tue, 28 Aug 2007 21:57:00 -0500

When you’re running a Rails application in development mode, you might notice that it takes a little longer for requests to get processed and this is somewhat intentional as the framework is was designed to allow you to run the application and make live changes to it. This way you can do some basic functional tests from your web browser, work on HTML/CSS changes, or anything else that might need to be done in development mode.

Anyhow, this can be slow from time to time and if you’ve done much Ajax work, you might be familiar with how slow this can feel when performing some basic tasks. Well, thanks to Josh Goebel, we can speed up things with a new plugin he just released.

To install via piston:

cd vendor/plugins; piston import http://svn.techno-weenie.net/projects/plugins/dev_mode_performance_fixes/

To install via script/plugin:

./script/plugin install http://svn.techno-weenie.net/projects/plugins/dev_mode_performance_fixes/

Josh has posted some benchmarks and in my totally basic tests… shows about four times (4x) speed improvement for reqs/sec!

How does it work? From what I can tell, it works somewhat like autotest, in that keeps things cached and when it sees files modified, it re-caches the changes. He’s made it so that the stack doesn’t need to reload for each request, which is quite slow.

Since it’s development-mode only, I’d encourage you to install it and give it a whirl.

Have Fun!

Subscribe to Basecamp RSS Feeds in Google Reader

Robby Russell — Fri, 17 Aug 2007 15:42:00 -0500

Yesterday afternoon, we were helping our newest employee, Paige Saez, get setup with new accounts across all of our applications. She uses Google Reader and couldn’t understand why her Basecamp RSS wasn’t working in it. We explained that Google doesn’t provide any way to subscribe to authenticated feeds (yet)... so it wasn’t something she could do. (I still use NetNewsWire because of this problem…)

During the discussion, I said that it probably wouldn’t take much effort to build a proxy for an authenticated feed… and Andy said he’d give it a shot.

10 minutes later… he had an initial version of a RSS proxy application, written in Ruby.

15 minutes after that, we had it up and running on a private server for all of us at PLANET ARGON to begin using.

...and here is the proof!

Wee! Authenticated Basecamp RSS feeds in Google reader. It even works with the openid authentication.

You can grab the code from Andy’s blog post and finally make the switch off of desktop RSS readers to Google Reader, because you know you want to. ;-)

Thanks Andy!

RubyURL: new design and code base

Robby Russell — Wed, 08 Aug 2007 08:58:00 -0500

Yesterday evening, I deployed the new version of RubyURL. This was a collaborative effort between Chris Griffin and I, which we’re happy to finally push live.

There are a few things that we’re going to push out in near future, such as an API and a new RubyGem.

Chris volunteered to work on the new design and I did most of the programming in Ruby on Rails. When we worked on this, we really wanted to keep the process as simple as possible, despite some of the problems that the site has been having.

In the end, we have a Rails application that is only 85 lines of code and has a 1:2.3 code-to-spec ratio. I wanted to keep it under 100 lines of code. This means that there is some breathing room for further development.

We also tried out a beta account that I was given for RoundHaus for Subversion hosting. We had a really good experience using their service and were impressed by the plethora of useful features that came with the repository, such as continuous integration, rcov/code coverage stats, and twitter integration!.

If you find a bug, be sure to submit a ticket on the RubyURL bug tracker.

On a side note, we deployed this on a brand new Rails Boxcar, our new hosting solution that will be launched in the very near future. ;-)

Spec Your Views

Robby Russell — Thu, 02 Aug 2007 02:00:00 -0500

I meant to work on this post… oh about 7 months ago.

Way back in January (7 months ago), Jamis Buck posted an article titled, Testing your views, which gave a few tips on using Test::Unit to, as the title suggests, test your views.

While, I’m not going to rewrite everything that Jamis wrote, I’d like to show you how to test these views with RSpec. (you might take a moment to quickly read his post…)

In this example, I’m going to show you how we’re able to write specs for the following RHTML, which you’ll notice matches the code that he wrote tests for.


  <% if @user.administrator? %>
    Hi <%= @user.name %>! You appear to be an administrator.
    <%= link_to "Click here", admin_url, :id => "admin_link" %>
    to see the admin stuff!
  <% end %>

Jamis writes, “The only really significant thing you ought to be testing here is that the admin link only shows up for administrators. “

So, let’s do just that, but with RSpec.

I’m not sure how Jamis is handling his view tests, but we’re going to approach our view specs, much like we approach our controller specs, with the use of mocks and stubs, because we really don’t need to spec any of our models at this level in the application.

Tip: Write specifications for your models… in your model specs not in your controller or view specs.

The first thing that we’re going to do is setup a custom spec helper, because for something like an mocked user, will probably get reused in other areas of the user interface. Spec helpers are essentially modules that you can include in your RSpec descriptions (the block that starts with describe) and reuse.

In this spec helper, I’m going to include two methods, to mock the User model and stub out any of the methods that are necessary for spec’n this view.


module MockUserHelper
  def mock_normal_user
    user = mock(User)
    user.stub!(:administrator?).and_return(false)   # <--- NOT an admin
    user.stub!(:name).and_return('David Chelimsky')
    return user
  end

  def mock_admin_user
    user = mock(User)
    user.stub!(:administrator?).and_return(true)    # <--- IS an admin
    user.stub!(:name).and_return('Aslak Hellesoy')
    return user
  end
end

In the mock_normal_user method, we’re constructing a mock object and stubbing out the methods that we see are being called in the RHTML code. In mock_admin_user, we’re basically doing the same thing, but just stubbing the administrator? method to return true for this mock user.

By stubbing these methods, we’ll be able to send a non-ActiveRecord object to the view and have it render without knowing the difference. For example, the if @user.administrator? condition will return true or false, depending on how we stubbed it.

For more information on mocks and stubs, read here.

Now that we have our spec helper, let’s go ahead and dive into a few specifications for the view.


describe "index page" do
  include MockUserHelper

  it "should render an admin link for an admin user" do
    assigns[:user] = mock_admin_user
    render 'index'
    response.should have_tag('a#admin_link')
  end

  it "should not render an admin link for a normal, non-admin user" do
    assigns[:user] = mock_normal_user
    render 'index'
    response.should_not have_tag('a#admin_link')
  end
end

Please note: This code example is only longer than the one shown by Jamis because he didn’t include how he setup all his user sessions/objects. ;-)

When these specs are run, we can see the following results.

Pretty output courtesy of RSpec + TextMate bundle

Great, we’ve been able to write specifications for our Rails views without a lot of pain. Stay tuned for more posts on this topic as I continue writing about how Designers and Developers can work together, in harmony. (see my last post on this topic)

For more information on adopting RSpec, please visit the RSpec project homepage.

YSlow and Rails performance: Getting UJS and AssetPackager to play nice

Robby Russell — Fri, 27 Jul 2007 13:40:00 -0500

Yesterday, I started to dig deeper into YSlow and decided to pick an application that we recently launched for a client. The performance grade that I saw at first was an F, which wasn’t surprising to me because we knew that there was going to be some fine tuning in the near future.

There is a lot of JavaScript in this application and we have several files to break up stuff to make it more maintainable. However, in production, we really don’t need to send the client (browser) 19 different JS files. We’ve been using mod_deflate to compress these files, but it doesn’t solve the problem of having several connections opening to download all the necessary JavaScript. The same is true for our CSS files.

At RailsConf, DHH announced that an upcoming version of Rails would bundle all the stylesheet and javascript files into one file and compress it. We’re running on 1.2.x for this application and decided to look at the AssetPackager plugin as a good solution to this problem.

I installed the plugin via piston and ran the following task, which is provided by AssetPackager.

rake asset:packager:create_yml

This went ahead and created config/assets_packager.yml. I then went ahead and updated our capistrano configuration to call the rake task after updating the code on the server when deploying.


desc "all of our other tasks/commands to run after updating the code" 
task :after_update_code do
  #
  # all of our other tasks/commands
  #
  run "cd #{release_path} && rake RAILS_ENV=production asset:packager:build_all" 
end

The first thing that I noticed was that the yml file that gets generated will not make any assumption as to what order the javascript libraries should be loaded. So, immediately, line 1 of our compressed javascript file was causing an error as the code was trying to reference a library that hadn’t been defined yet (showed up later in the file). So, when you do this, you’ll need to organize the yml file to load things in order that they are needed. This was also a good opportunity for us to say, “oh, we’re not using that one anymore. Let’s remove it.”


--- 
javascripts: 
- base: 
  - prototype  
  - effects
  - scriptaculous
  - controls
  - dragdrop
  - application
  - slider
  - pngfix
  - nav
  - lowpro
  - lightbox
  - folder
  - builder

Great, so we re-dployed and everything at first glance seemed fine… or so we thought!

We used the unobtrusive javascript plugin for this project and it seems that we couldn’t just compress every single file. Each page has a behaviors javascript file and since everything was being compressed into one file (and cached), RJS calls quickly broke throughout the site. OH NO!

So, I opted to merge all of the other javascript files and use the standard way of including unobtrusive javascript in the application layout.


<%= javascript_include_merged :base %>
<%= javascript_include_tag :unobtrusive %>

We also removed lowpro from the list of javascript files to compress since the ujs plugin is currently including this when we call <%= javascript_include_tag :unobtrusive %>. I plan to look into modifying this so we it’ll only include the page-specific behaviors and not load the lowpro javascript file (so we can compress that as well).

Once this was re-deployed, we saw that the RJS issues were resolved and everything felt to be loading quicker. But, let’s look at YSlow again for step 1 in improving the performance of the application.

side note: the following grading was also after making some other adjustments that were suggested by YSlow, which I’ll discuss in another blog post soon.

So, where we once had a grade F, we now have an D… which is due to the client having us add several (four) external javascript files for mint, google analytics, etc. We’re only loading 3 javascript files for the application, when we were originally loading many more.

Obviously, there is some more tuning to be done, but we went from a grading of 43 to 74 in about three hours of time spent reading the YSlow documentation, adding asset_packager, and making various tweaks to our web servers (as suggested by YSlow).

Until next time…

Every Second Counts with a Piston in your Trunk

Robby on Rails: Category Ruby

Ruby 1.8.7 on MacPorts causing some problems

I am forking Rails

Tip: Link to Unimplemented

Related Posts

Managing Required Gems on Rails Projects

Managing SEO-friendly HTML Titles with Rails

Problem: HTML titles

Instance Variable

The content_for helper method approach

Which is the better solution?

Things (in the Rails world) You Don't Yet Understand

DRY(a): Year After Year

Introducing Year after Year

Installation

Updates…

Deploying Rails with an interactive Capistrano recipe to your Boxcar

Installing Ruby on Rails and PostgreSQL on OS X, Third Edition

Phase One

XCode 3.0

MacPorts

Environment Paths

Hiding Apple’s Ruby, Gems, and Rails

Phase Two

Installing Ruby via MacPorts

Installing Ruby on Rails via RubyGems

Installing Mongrel via RubyGems

Phase Three

Installing PosgreSQL with MacPorts

Configuring PostgreSQL

Adding PostgreSQL to launchd

Adding PostgreSQL to your $PATH

Creating a new PostgreSQL user

Installing PostgreSQL Libraries for Ruby

Closing Thoughts

ShortURL 0.8.4 released and gets a new mainainer... me!

Install the ShortURL gem

Using ShortURL

Using the ShortURL library

Using the shorturl command-line tool

ShortURL Documentation

PGCon 2008 - Call for Papers

PGCon 2008

Get to Know a Gem: Rak

Installing rak

Using rak

Master/Slave Databases with Ruby on Rails

Announcing Masochism!

Installing Masochism

Configuring Masochism

Using MacPorts Ruby and Rails after Upgrading to OS X Leopard

Don’t Fix it… if it’s not broken!

Chad Fowler's Dirty Little Secret?

Multiple Database Connections in Ruby on Rails

PLANET ARGON is seeking fresh talent... could it be you?

Edge Rails Documentation: Revisited

Rails Business: "Weekly" Review #4

Some Recent Discussions

Obtaining Ruby Gigs

Taking a full-time job, what about your freelance clients?

Reality Check!

Join the Community

Rails Development Performance Tip - dev_mode_performance_fixes

Subscribe to Basecamp RSS Feeds in Google Reader

RubyURL: new design and code base

Spec Your Views

YSlow and Rails performance: Getting UJS and AssetPackager to play nice

The `content_for` helper method approach