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.

The post Auto-Login for Any URL in Rails appeared first on Big Nerd Ranch.

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.

The post When not to use technology appeared first on Big Nerd Ranch.

I’ll be representing Highgroove at the Lone Star Rubyconf this weekend. I’ll give two talks, one for the charity event the night before and another at the main conference.

At the charity event I’m going to go over Ruby’s block syntax. I’ll cover what blocks are, how they are used, and give a lot of great examples. This is a good talk to sit in on if you’re new to Ruby and it’s even for a good cause.

For the conference I’m going to talk about heroes and super powers. I’m sure I’ll manage to sneak a little Ruby in there too, for those that enjoy that. This talk takes an in depth look at glue code and Ruby’s features supporting such. It’ll be fun stuff that doesn’t get talked about enough.

If you are attending the conference, do flag me down and say hello. I’m always interested in meeting fellow Rubyists.

Hope to see you there!

The post Talking in Texas appeared first on Big Nerd Ranch.

If you are following the Capistrano preview releases, you may have noticed a new dependency. Capistrano now depends on HighLine, an open source input library by yours truly.

The reason for the switch is that Capistrano needed a reliable way to grab passwords in a cross-platform way. That turns out to be a lot harder than you might guess. On Unix, termios can make short work of such challenges, but that’s an extra C extension install and it doesn’t work on Windows.

HighLine combines the knowledge of several platform gurus to use the right solutions in the right place. Even with all that knowledge as an advantage Capistrano’s maintainer, Jamis Buck, still had concerns. termios can’t be made a HighLine dependency, since we want to stay cross-platform and when defaulting to stty HighLine was a little flaky for the way Capistrano users might need it. Jamis and I discussed these concerns and HighLine was patched with better support for Capistrano’s needs. Jamis later added the dependency and HighLine benefited from another round of expert knowledge.

It still impresses me how much we can accomplish with the super friendly open source model of development. Thanks for the input Jamis!

The post Capistrano Takes the HighLine, I Mean Road appeared first on Big Nerd Ranch.

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…

The post The Dime Tour of Rails appeared first on Big Nerd Ranch.

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.

The post The TextMate Book is Shipping appeared first on Big Nerd Ranch.

I just finshed fixing file uploads in a HighGroove application to work with any size file. I uploaded a 14 byte file to make sure I had things right. This has a few gotchas in Rails, so I thought I would share the recipe for success.

Before we start, I should mention that it’s not Rails’s fault this is tricky. The CGI library Rails relies on has quirky behavior: it returns different kinds of objects for some file uploads. The main issue is that files under 20 KB in size are passed to your code in a StringIO, while the bigger stuff comes in a Tempfile. The StringIO object is modified to support methods like #original_filename that you are likely to need, but it’s still easy to make a mistake so your application fails to work with the little files. This post is about how to avoid those mistakes.

First, I had to change the code we used to check if we had received a file upload. The old code was:

    def file_provided?     not [String, StringIO].include? @file.class   end

This code had probably just been copied from some early work we did, before we understood the rules. We saw that sometimes we would get a String or StringIO, but we just supported files bigger than 20 KB back then (Tempfile).

The trick to fixing this is to know what Rails can pass you. There are five options:

• A String file name (useless). This happens when you make my famous dumb mistake and forget to set the form as multipart.

• An empty String. Same mistake, no file selected by the user.

• A StringIO containing all the file data. User uploaded a file smaller than 20 KB.

• An empty StringIO. User forgot to upload file.

• A Tempfile containing all the file data. User uploaded a file at least 20 KB in size.

Once you know those, the solution is easy. We want a StringIO or Tempfile (the Strings are errors) and we need to make sure there is at least some content. Both StringIO and Tempfile support #size and if it walks like a duck and talks like a duck, it must be a duck:

    def file_provided?     [StringIO, Tempfile].include?(@file.class) and @file.size.nonzero?   end

The other issue in our old code was when we actually saved the file data. This is why we only supported Tempfile originally. The old code was:

    def save_file     FileUtils.cp(@file.path, path) if @file   end

This just copies the Tempfile to a permanent location specified by our #path method (not shown). The problem is that I’m now allowing StringIO objects through and they won’t be on the disk to be copied.

The easy fix is to use the fact that both StringIO and Tempfile support a #read method:

    def save_file     File.open(path, "wb") { |disk_file| disk_file << @file.read } if @file   end

Don’t do that though!

If someone uploads a 90 MB PowerPoint presentation it must be loaded into a Ruby String (where it will be much bigger) and dumped back. Yuck.

Because of this, we want to avoid Duck Typing this time and resort to type checking:

    def save_file     if @file.is_a? Tempfile       FileUtils.cp(@file.path, path)     elsif @file.is_a? StringIO       File.open(path, "wb") { |disk_file| disk_file << @file.read }     end   end

This uses our old system for Tempfile objects so we don’t need to slurp massive data amounts. When we get a StringIO though, we just write the data out ourselves. It’s already in memory and we know it’s small anyway so there’s nothing to worry about in this case.

That’s it folks. Uploads for all sizes.

The post Mini File Uploads appeared first on Big Nerd Ranch.

Just wanted to make sure Highgroove customers and fans are the first to know, my new book is official:

James’s Book on TextMate

If you’re living under a rock, TextMate is the wildly popular text editor for Mac OS X shown off in most Rails screencasts.
It even won the covetted Apple Design Award for Best Developer Tool just a few weeks back.

I’ve been heavily involved with TextMate development for some time now and am excited about the opportunity to show you how to really get the most out of it. The book will cover beginning to advanced editing techniques, built-in automations and how to create your own, even how to teach TextMate new languages. I promise, there’s something for everyone in here.

Some time ago I read a “10 Best Things You Can Do as a Programmer” list and one of the points on that list was: Learn one text editor very well and use it for everything you can. I believe that’s great advice and TextMate was my pick. I’m now ready to pass that knowledge on to all of you!

You’ll be seeing even more news about this book very soon now. (Weeks, not months!) Stay tuned…

The post Look What’s Coming… appeared first on Big Nerd Ranch.

Just wanted to make sure Highgroove customers and fans are the first to know, my new book is official:

James’s Book on TextMate

If you’re living under a rock, TextMate is the wildly popular text editor for Mac OS X shown off in most Rails screencasts.
It even won the covetted Apple Design Award for Best Developer Tool just a few weeks back.

I’ve been heavily involved with TextMate development for some time now and am excited about the opportunity to show you how to really get the most out of it. The book will cover beginning to advanced editing techniques, built-in automations and how to create your own, even how to teach TextMate new languages. I promise, there’s something for everyone in here.

Some time ago I read a “10 Best Things You Can Do as a Programmer” list and one of the points on that list was: Learn one text editor very well and use it for everything you can. I believe that’s great advice and TextMate was my pick. I’m now ready to pass that knowledge on to all of you!

You’ll be seeing even more news about this book very soon now. (Weeks, not months!) Stay tuned…

The post Look What's Coming… appeared first on Big Nerd Ranch.

There are countless links out there that will bury you in suggestions for how to write Rails code, so I’m going to take the road less travelled and give you three non-code tips that I think are really important.

h3. Learn Some Ruby

I know this one is dangerously close to being a code tip, but I really mean this in the general sense.

Many programmers come to Rails directly, without prior knowledge of Ruby. That’s terrific! We don’t care how you get here, we’re just thrilled you found your way.

However, a lot of people don’t go much farther than that with Ruby itself. You can write a fair bit of Rails code without getting deep into the underlying language, but you really don’t know what you are missing.

I’m being 100% honest when I tell you that I’ve seen all of these things in Rails code:

1. Constructs that could be 30 lines shorter with trivial use of a block or a method_missing() definition.

2. Complicated buffering layers wrapped around services Ruby is already buffering.

3. Painful recreations of libraries that ship with Ruby.

4. Code that used each() when map() or inject() would have been a much better fit.

A little knowledge really goes a long way here. You will be surprised how much easier you fly through tasks and you will find endless fun in shrinking your application’s code base dramatically with the timely use of some Rubyism.

Luckily, if you are in this category of Ruby users, an excellent book was recently published just for you. Run, don’t walk, to purchase a copy of Ruby for Rails. I promise you won’t regret it!

Remember the YAGNI Principle

Luckily, Rails programmers seem to have a lot of great habits! Unit testing and agile development are very popular in Rails circles. DRY is a popular slogan for Rails programming too. I couldn’t be happier.

Since I probably don’t need to tell you to read up on those, I’ll pick a different good habit to promote: remember the YAGNI principle.

We all do this. I know I’m guilty, but I’m really trying to get better about keeping this in mind when I work.

I’ve worked on Rails applications where multiple features were explained to me as, “We’re going to need this down the road, so make sure you build this part carefully…” Red flag! That’s a no-no.

The problem is that you are guessing here. You are guessing that you may need this feature someday; you are guessing that you know how it will have to work; etc. Any one of these guesses could be wrong. In fact, it’s a very, very safe bet one is, just based on the law of averages.

When any one of them is wrong, you blew it. You complicated the current development, possibly even pushing aside needed or nice-to-have features, and you will still need to redevelop this code when the real requirements show up. You paid for this code a minimum of two times. That’s not a good trade.

Besides, you’re agile so you will have no trouble adding the feature when the time comes, right?

Get Involved!

I know this one is going to sound almost silly, but take it on faith if you must: join a Ruby/Rails community today!

I’ve learned a crazy amount of programming from books and classes, but I’ve learned at least twice that knowledge from interacting with other programmers, scout’s honor.

Whether you are teaching, learning, goofing off, or just spending time with your peers, it’s hard to avoid picking up the nuggets of wisdom from others. You will be amazed what even the beginners have to teach you with their fresh perspective.

Find an established group and attend their meetings. Budget time and money for conferences. Start a local user’s group if you have to. (You’ll learn at least as much that way!)

You share a common interest with a large body of people. Seek them out.

The post Three Non-Code Rails Tips appeared first on Big Nerd Ranch.