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.
by james
Published January 03, 2008 tagged with:
Open Source
I had an unusual Christmas Eve. While my wife was entertaining the family, I was in my office programming until nearly midnight. (Have I mentioned how much I adore my wife?!)
What had me so tied down at such an odd hour? One of the open source libraries Highgroove maintains: FasterCSV.
The Ruby core team gave me the nod to replace the standard CSV library with FasterCSV just before the Ruby 1.9.0 release. While a little more warning would have been nice, I was happy to do it.
I think it’s important to discuss why Highgroove, not just allows, but actually prefers that I spend some of my time maintaining our open source libraries, like FasterCSV.
The reason we created the library is nice and simple: we needed it. We import or export spreadsheet data at some point for most of our applications. We work with large data sets and we needed that to be fast. We also frequently use headers in the CSV files to map directly to database fields so a broader feature set to support such things was important to us.
Now we could have built it and just used it internally, but we decided to share. Did we do it because we are just really nice guys? Not really. (We are though, of course!) We did it because we wanted it to be great.
There are many subtle variations and edge cases for CSV. We debugged the library the best we could, but we’re human and we missed things. That meant our library would have trouble with some inputs. We (hopefully) would have noticed those eventually, but we’re just one set of users and by releasing it on the world we multiplied the user base by thousands. Needless to say early users found problems for us much faster than we could have alone. Better than that, they sometimes even fixed them for us! Even when they don’t, they usually send in an example that leads us straight to the problem which is almost as helpful.
That’s not all. Remember all of those features I told you we love? I wish I could brag and tell you I invented all of them, but some of my favorite features in FasterCSV were sent in by the users. I got the ball rolling with what I could see us needing, but the users ran with the ideas and made my library better than I knew it could be.
Highgroove isn’t losing hours on me applying a few patches here and there. They are gaining the help of many extra employees. We love that.
To top it all off, Matz gives us the ultimate Christmas present. By blessing our work, he saves us the trouble of even installing it for new projects. Very soon we will be able to count on our code being available in all modern Ruby installs. That’s just one less thing we need to worry about.
With open source everybody wins.
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.
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!
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…
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!
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.
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.
→ Read More
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…
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.
→ Read More
I’ll be fair with you and tell you right out that I am biased in this matter, but I still have to say:
GO BUY THE RUBY COOKBOOK RIGHT NOW!!!
Yes, I wrote six of the bazillion recipies in the book (on DRb and Rinda), but I do not make money when they sell copies, so you can trust what I am saying here.
Basically we are talking about nearly 1,000 pages of EVERYTHING on Ruby. I don’t care who you are or what you do with Ruby these guys wrote something about your problems. How cool is that?
These recipes are just loaded with code, tips, links to related resources, etc. They even manage to be funny in places. (You will laugh at the dinosaur ad.)
Why are you still reading this?! Get up. Go outside. Hail a cab. Get yourself to a bookstore and pick this up! GO!
(If you have back problems you shoudn’t be carrying books this big, trust me. Instead you can grab the PDF version O’Reilly just made available.)
by james
Published July 08, 2006 tagged with:
Community
About half of the geeks of the world prefer newsgroups for communication and the other half swears by mailing lists. (A tiny percentage prefer web forum or pigeon, but clearly these people suffer from insanity.) The Ruby community has long had both: the comp.lang.ruby newsgroup and the Ruby-Talk mailing list.
In 2001, a band of clever adventurers and Rubyists united the two communities with heroic feats of hacking. A “gateway” script was installed that dutifully ferried all messages from one group to the other and visa versa. This was a blessing, because both sides now shared the collective Ruby knowledge. A golden age began.
Unfortunately, a few months back, the evil server hosting monster struck and slew the gateway with a single stoke! (In all fairness, the hosting provided to the gateway over the last five years was more than generous, but that just doesn’t make for as good a story and I’m telling this one!) The golden age ended, the community shattered into two halves…
At HighGroove, we couldn’t stand for that.
Knowing the peril involved, I enlisted the help of the brave HighGroove SysWizard Charles and we went in search of a gateway in need of rescue. It was a long journey and we suffered a minor defeat along the way, but good always triumphs over evil and we cannot be stopped easily!
I’m happy to bring the good news to all the peoples of the Ruby kingdom: the gateway has been resurrected. The golden age has come again.
Please join me thanking all those patrons who sponsored our quest:
- Dave Thomas, First Knight of Ruby, penned the original gateway code and it only needed minor updates even a squire like me could figure out to restore it to its former glory.
- Dennis Oelkers, former Guardian of the Gateway, helped us locate the script-in-distress and taught us much about the care and feeding of such a creature.
- Fred Senault, James’s new best friend by sworn oath, generously gave the gateway the life giving kiss: a newsgroup account.
- The afore mentioned SysWizard Charles, who can quite literally conjure servers to host gateways with the snap of his fingers. His powers are beyond compare.
Thanks to these brave men, the knowledge is again shared by all! Use it wisely my fellow adventurers…
I'll be giving a Rails presentation to OK.rb this coming Tuesday (June 13th). Anyone in the OKC area is more than welcome to attend.
My talk will be a tour of some live production code HighGroove has generated for clients. I'll cover sections of interest from three different applications. This should be a good chance for us to explore how Rails applications come together.
For more in formation visit OK.rb's meeting schedule or email me with your questions.