"Ruby on Rails" Posts
Posted in Keeping it Simple, Ruby on Rails | 1 comment 
CBQ
If you’re just getting started with testing (and general test-first or test-driven development) in your Ruby and Ruby on Rails applications, you have a couple of choices.
You can go with Ruby’s Unit::Test, built right in to Ruby, and built-in to Rails with unit, functional, and integration test suites setup for you.
Or, you could setup Rspec with Mocha, and implement a form of testing called Behavior Driven Development or BDD.
Both approaches serve the same goal: better, tested code, easier code to maintain, and in general, just better practices.
My advice is to start with unit tests, and then move to Rspec later.
Read more... 
Posted in Ruby on Rails, Speaking | 3 comments
CBQ
For those who missed my talk at the most excellent Acts As Conference put on by the good folks at Rails For All in Orlando, Florida—here’s the cheat sheet.
My talk was on the lessons learned from teaching the Ruby on Rails Bootcamp and various on-site Trainings over the past year and a half. Here are the 4 key things you need to do to be a successful trainer:
Define Your Purpose – Come up with a clear, specific, desired outcome. Are you attempting to teach the basics, or promote mastery? A quick how-to, or a detailed guide to a particular way of development? A clear purpose helps your audience hit the ground running. An unorganized braindump can leave your students frustrated when they go at it alone.
Know Your Audience – You’ve got to understand everything you can about your audience. This means not only their current level of knowledge, but their past experiences, and even their goals. Ask questions before and during your training to understand everything you can about them. This will help immensely with the next tip.
Give Relevant Examples – Cater your examples to the domain that your audience knows. If you are teaching a bunch of journalists, use concepts from the publishing world. Never use foo, bar, or any other made up word in any example. If you don’t know, guess, and if your audience corrects you on the concept, you now have attentive listeners, contributing to your solution!
Teach How to Learn – Show, don’t tell. Stress how to find out why something works the way it does. Give plenty of examples, and help your audience figure out concepts. Give them the resources to continue learning and to find out more. Show them how you figured it out, or where you went to learn.
I’m sure there are plenty more tips, but I’ve found these 4 to be extremely valuable to me in coming up with valuable lessons and ways of teaching. Thanks to everyone who came up to me afterward to ask questions and share feedback about teaching!
Posted in HowTo, Ruby on Rails | 1 comment
James
One of our current projects at Highgroove sends a lot of email to its users. It essentially walks them through a process and emails them at each step. All of those messages include URL's to visit the relevant page in the application for that step. Since we've emailed them the URL's we don't want them to have to login every time they click one.
To get around that I modified the application to accept URL's like the following:
http://domain.com/login/TOKEN/ANY/SITE/URL
These URL's log the user in using their security TOKEN and then redirect them to /ANY/SITE/URL. This setup allows me to easily forward a user to any URL on the site which is great when writing all of these emails.
The code is easy enough too. I imagine many of us have a sessions controller that looks something like:
class SessionController < ApplicationController
def create
if user = User.authenticate(params[:email], params[:pass])
# log user in...
else
# login error message...
end
end
# ...
end
First, I just added some support for the token based login with redirect to that:
class SessionController < ApplicationController
def create
if params[:token] and (user = User.find_by_token(params[:token]))
# log user in...
if params[:path].is_a? Array
redirect_to "/#{params[:path].join('/')}"
else
redirect_to home_path # or whatever default page you want
end
elsif user = User.authenticate(params[:email], params[:pass])
# log user in...
else
# login error message...
end
end
# ...
end
The magic redirect_to() call in that new code uses a not-often-seen feature of Rails's routing. You can specify that Rails collect any number of trailing URL bits into an Array much like Ruby can do for method parameters. Here's the route definition I am using to get users to the code above:
# a custom login route with forwarding
map.connect "login/:token/*path", :controller => "session",
:action => "create"
The *path is the magic slurping parameter syntax, again just like arguments to a Ruby method. Rails will collect each piece of the remaining URL into an Array called path, so just remember that you need to rejoin the elements to make them a real URL again.
Posted in Community, Ruby on Rails | no comments
CBQ
Recently I’ve been reading Obie Fernandez’s book, The Rails Way.
I made an appearance in one of the chapters, but the real credit goes to Obie for pulling together an exhaustive 850-page book.
It’s not for beginners, but if you’ve taken one of my Rails training classes, it’s a great reference book and next step.
Reviews of the Rails Way:
Posted in Community, Ruby on Rails, Speaking | no comments
CBQ
Just a quick note that I’ll be speaking on Lessons from the Trenches – Learning from the Rails Bootcamp at the regional Ruby on Rails Conference dubbed acts_as_conference (a play on the Rails way of introducing behavior through code) in Orlando, Florida, on Feb 8-9.
If you’re interested in how to effectively teach your friends, colleagues, bosses, and maybe even your mom about Ruby on Rails, registration is now open to the public. Looks to be a great conference line-up, with keynoters Obie Fernandez and Dan Benjamin, and plenty of great talks.
Posted in Keeping it Simple, Ruby on Rails | no comments
James
As technologists and especially programmers we are always expected to automate as much of any process as we can. In general, this is a good rule of thumb and I'm a big follower of that philosophy.
However, though it may be hard for us to admit, some problems are better solved with less technology. Let me give two examples I've run across recently.
First, let's talk about filtering spam. I'm sure this raise some eyebrows, but I believe spam filtering is a human's job. My reasoning is very simple: I have not yet seen a perfect spam filter, so it's a given that I will at least need to correct some automated guesses. Because of that, a recent project of mine has no automated filtering built-in. That's right, I'm doing it all by hand and I much prefer it to any other system I've tried.
My complaint here isn't against automated spam filtering. It you like the filters, by all means use them. However, think through your implementation very carefully.
My complaint is that most automated filters are built around the automated filter as the main focus and my corrections correcting it as a secondary concern. Even worse, some implementations don't really account for my need to make corrections at all. I'm glad we make things so easy on the computer, but that means we're inconveniencing me. That can't be right. If I must be involved anyway, I want my role to be as simple as possible.
When I designed my new spam filter, I started with that goal. The specific solution for it may be different for each of us: I want a page I can go straight to, check boxes for all messages, and a single button to classify them all at once; or I want to receive emails as they come in and I will reply to the spam messages to signal the software should eliminate them; or whatever. The point is that this is the right starting point. If you want to mix in some automatic filtering that's fine, but I found that just addressing this correctly in the first place reduced my spam stress enough.
Let's talk about another example. In one of the applications Highgroove is currently working on the "Create" step for a typical set of CRUD actions is a little tricky. You could design a system of forms around it and walk the user through the process, but it wouldn't be a great experience. It's just one of those edge cases where it's really hard for a computer to understand what is needed, but a human will get it in an instance and be able to provide just the right answer. Beyond that, the create operation will be super rare compared to everything else the application does.
How did we address this? With a good old fashioned phone call.
The user can go into the application and put in their create request, which includes their phone number and a good time to call them. With a quick call the human can ask all the right questions and build what they need while they have them on the phone. It's low hassle for all parties involved and gives the application that extra personal touch.
What will we do if the application grows so huge that this process becomes a bottleneck? Well, that's a problem we would just love to have! We bet we would be able to bring on another person to help with the extra load when we reach that point.
Don't let this post talk you out of writing any Rake tasks or other automations you truly need, but the next time you run into one of those problems the computer can't handle too well don't underestimate the power of a low tech answer. Perhaps the computer can help you do it better, instead of trying to do it for you.
Posted in Ruby on Rails, Business | no comments
Derek
Andre and I recently finished the initial launch of Placeshout’s Facebook application. There are several “getting started” tutorials available on building Facebook applications with Ruby on Rails, but there were quite a few issues we ran into that are beyond a “How To” blog entry.
If you are building your first Facebook application, expect very slow going at the start. I’d take your time estimate and double it. Here’s why:
- It takes some time to grasp Facebook in a multi-developer environment. You need to create separate Facebook applications with different names using different tunneling ports. You’ll also need to create several test accounts. Inevitably, I installed one application when I meant to install another. Getting our version control system setup for our development boxes and production system took some time.
- Understanding how Facebook handles sessions. We ran into several issues – knowing when to require an app install vs. a login, handling an app install redirect inside an iFrame application, etc.
- We ended up using a combination of Rails’ #respond_to and unique Facebook-only actions to handle requests. Many of our pages were quite different in Facebook, and trying to fit format-handling in the existing actions only made things more confusing.
- Testing was a pain. Because we integrated with Placeshout.com, we needed to integrate user accounts. Planning and testing integration steps took quite a bit of time. Facebook and rFacebook have some testing conventions, but that’s like saying that because the speedometer in my Ford Escape goes up to 120 MPH, it can go 120 MPH.
- The rFacebook gem and plugin were our weapons of choice. I don’t have any complaints. We modified several pieces of code to fit our application – including creating a user and installing the application, but that’s not out-of-the-ordinary. The rFacebook team has done a solid job in a short amount of time.
In the end, it felt a lot like traveling to a non-English speaking country – at the start it’s difficult to get basic things accomplished. Once you get in a groove though, you enjoy the scenery and forget that at one time, you didn’t throw up when drinking tap water.
Posted in HowTo, Ruby on Rails | no comments
Derek
Sometimes our Ruby on Rails apps work perfectly with test data, but when they go to production, errors creep in. Debugging errors on a production server is a pain and a bit dangerous.
Here’s what we do to quickly and safely debug issues on our production servers:
1. Add the following capistrano task to create an SQL dump of your data. If it’s a large database, it may be worthwhile to compress the SQL dump as well.
desc "Exports the production db to the home directory of user"
task :db_dump, :roles => [:app, :db] do
run("mysqldump -u #{database_username} --password=#{database_password} #{application}_production > production.sql")
end
2. Create the following rake tasks to grab database dump and import the data locally.
namespace :db do
desc 'Grab a dump of the production database on the server and places it in db/production.sql.'
task :get_production do
`cap db_dump`
`scp DEPLOY_USER@SERVER_NAME.slingshothosting.com:production.sql #{RAILS_ROOT}/db/production.sql`
end
desc 'Imports the database dump of file db/production.sql into development.'
task :import do
`mysql -u root app_name_development < db/production.sql`
end
desc 'Grabs a dump of the production database from the server and imports the data into the local development database.'
task :get_import => [ :get_production, :import ]
end
3. Install the Firefox plugin Server Switcher to make it easy to switch between the production and local server in your web browser.
4. Disable mail in your development box – it’s not a good feeling when you realize you’ve emailed several thousand users while testing out a newsletter script.
config.action_mailer.delivery_method = :test
Posted in Oklahoma, Presentations, Ruby on Rails | no comments
James
If you are just getting into Rails or still don’t get what all the fuss is about and you happen to be near Oklahoma, you may walk to catch my talk tomorrow night for Refresh OKC. The meeting starts at 6:30 PM in the Oklahoma City Public Library.
I’ve got a massive talk prepared covering as large a portion of Rails as I can possibly fit in given the time. I do include some cool topics like using the Rails console and even AJAX. I even sneak in a little magic.
Do drop by if you are in the neighborhood…
Posted in What We Wrote, Ruby on Rails | no comments
James
If all you Rails programmers love TextMate as much as I do, you will want to know that my TextMate book is now shipping. Amazon has it in stock already.
If you been a casual TextMate user until now, I promise this is the best excuse you’ve ever had to put an end to that. Allan Odgaard, the creator of TextMate, actually read through the book as I worked fixing my errors and adding a terrific collection of helpful tips. You just can’t beat having that kind of knowledge. That’s why I’ve already been using the book as my personal TextMate reference for months now.
Pick up a copy. You won’t regret it.
