The two things to keep in mind when making an admin area are

1. you can create namespaces for routes to get the /admin URLs you’re looking for and
2. you can have controllers inherit from other descendants of ActionController

So to make an admin area, you’d want to have RESTful resources declared in a namespace (assumes Rails 3 routes):

The top set is the public ones and the bottom set gives you the admin routes like /admin/users/new and /admin/posts/1, etc. I’m also assuming you might want a “dashboard” so I’m setting up a route to the index method of an Admin::DashboardController

Then you create an admin base controller that descends from ApplicationController. Use it to hold your admin area layout and your authentication filters:

Now make a directory in app/controllers called “admin”. Make controllers in there as normal, but have them inherit from your base controller:

Make a corresponding directory in app/views for “admin” and you’re good to go — everything is namespaced out and views/controllers would behave like you think.

You can always run “rake routes” to see all the admin routes.

Now is a piece of software designed to do something as prosaic as dependency management going to get you hot and bothered all by itself? Probably not. It’s not going to be like when you discovered the beauty of Ruby’s iterators, or how to get the QBasic interpreter to give you the exploding banana game in MSDOS 5.x+.

But along those same lines, Bundler will help you reserve more of your mental compute cycles for things that matter and fill you with wonder, secure in the knowledge that you’ve chopped off a few big boulders from the pile of computational entropy constantly threatening to avalanche everyone in our industry into oblivion.

Examples:

Kids should come with “bundle install”.

Apps are complicated because you need all sorts of specific stuff to deal with them. That’s why Bundler was originally invented, obviously. But real-world scenarios are always valuable, and today I had to get a development version of the app I’m building for my main client running on the designer’s machine, and do it as fast as possible. While the designer is good w/ HTML/CSS, she doesn’t know thing one about Rails, rubygems, or the RVM-based sequestering of different Ruby versions, etc (another hymn another time for RVM). I got all that going for her, and then, with a mere two commands (one of which checked out the source code from the repo and therefore didn’t really even count), I bootstrapped the entire app at once, while surfing the web. “bundle install” for the win. That same process would’ve taken me (just for the app’s dependencies) about 45 minutes or so in previous incarnations of Rails. This way, it took less than three. And almost all of that was completely automated.

Specifying refs is a thing of beauty

Rails 3 rc1 came out a couple days ago. Like every other RoR cultist, I upgraded as soon as I heard. A bunch of crap promptly broke. Those wacky core team members! They love to make a boatload of commits on something and then call it a release candidate, just to keep us all sharp.

One of the things that broke was state_machine, which I rely on extensively in this the aforementioned app. So one upgrade from Rails 3b4 to Rails 3rc1 and I’m sitting there in a puddle of my own tears, with all my specs broken and no ability to run my seeds.rb file.

Thankfully, the gem maintainer rapidly came up with a patch. But he didn’t have a release ready yet. So what did I do? In the old days, I’d have to download his code at that Git reference and then put together a new gem on my own, keeping a vendored version that was seperate from the other versions of the gem I might’ve been using, etc etc. I’m sure there’s probably a better way to do it even under the old regime, but with Bundler, you simply pass in a reference to the commit where it’s been fixed!

So this

Becomes this:

That blew my mind even more than the dead-simple bootstrapping of my colleague’s development system. For working with libraries that are still in frequent development, and for fixing things like the myriad breakages that can occur when one version jumps up to be something else, this is a godsend.

So don’t bitch about Bundler, even if you’re tempted to in the beginning. Like everything else surrounding Ruby/Rails, it’s new and it takes some getting used to. But in the end, you’re likely to love it, and to wonder how you ever got along without it. Plus, this gives us yet another reason to laugh at Pythonistas, who still lack even a Rubygems equivalent.

But I have had time to be impressed, once again, at the awesome power of open source and the game-changing nature of Amazon Web Services.

Open Source — HTTPriot and delayed_job

Without going into too much detail, the iPhone app I’m working on (codenamed “Pedro”) records audio files and uploads them to a server. Naturally I’m using Rails for the backend, so I needed something to help me communicate easily with the server. After trying both an ASIHTTPrequest with TinyXML solution and Objective Resource, I eventually settled on HTTPriot. HTTPriot is a Goldilocks solution. ASI/Tiny are just too cumbersome since you end up having to write parsing methods yourself (and really, who the hell wants to do that when the entire point of structured serialization formats is that something should be able to turn them into native data structures (hashes/dictionaries) for you?), and ObjectiveResource seemed to do just a little too much and to rely on Objective-C categories a bit much for my comfort.

HTTPriot sits right between these solutions and is just right (had to complete the Goldilocks thought) for talking to REST services IMO. You serialize something out as an NSDictionary and POST or PUT it to the server, and you get back a response you can treat as a dictionary. GET requests are a one-liner (though to do it right you need a few methods so you can have a ViewController delegate handle the eventual response). The only drawback I’ve found so far to HTTPriot is that it requires you to cram all your processing logic for any given resource into a single method, as one and only one delegate method handles a successful server response. But that’s a small gripe. Using this excellent library, I was able to re-write the entire ASI/Tiny solution in a few hours. That’s versus a few days getting it set up in the first place. If you need to talk to a REST service with an iPhone, I highly recommend HTTPriot. As a bonus, the inimitable Geoffrey Grossenbach (@topfunky) uses it in one of Peepcode’s iPhone screencasts, enabling you to get both a step-by-step tutorial on creating a non-trivial working application with HTTPriot, and a good bit of explanation on how the library ought to be used.

When HTTPriot is done pushing an audio file to my app server, a Ruby library called delayed_job does the background processing required to send it to Amazon S3, where it will live and respond to GET requests via Amazon Cloudfront. delayed_job was created by the redoubtable Rubyists behind Shopify, the coolest turnkey e-commerce solution I’ve found so far. I’ve made a site or two for clients using Shopify, so I was excited to discover that they’d opened up the library they wrote to do background processing. delayed_job is a database-backed persistent job queue that runs in its own process and makes backgrounding a task dead simple. You can do all sorts of fancy things with prioritization and whatnot, but the thing that made me fall in love (even though my use cases eventually got a bit too complex to use it very much) is the fact that you can run any method with send_later — as in:

That one-liner will bop it into the queue, and delayed_job will handle it as it can. It’s really that easy. I’m using dj for sending emails and pushing binary files to Amazon, but I might start using it for other things as well. EngineYard (where we’re hosting this opus) supports it for production, and for development, you get a nice Rake task to help you manage it and keep an eye on the tasks as they happen.

The point of all this exposition is to say that I feel fortunate to have come up as a code dunce during a time in which open source software is mature enough to be able to provide even a relative n00b like me with documented, real-world-tested, helpful stuff that does exactly what I need it to — whether on the server side or on the client side. It’s worth mentioning as well that both of these things are arguably direct offshoots of the Rails community (delayed_job is in Ruby and was built to serve a Rails app, and HTTPriot was built with REST interactions in mind, which Rails has done a lot to help popularize), which continues to astound me in its breadth, creativity, and helpfulness.

AWS – cheaper than dirt, more valuable than gold

Have you ever seen anything as cheap as the stuff offered by Amazon Web Services? I don’t think I have. Or to put it more directly, AWS are the cheapest things I’ve ever seen someone try to put a price tag on:

- S3, Amazon’s storage service, charges $.015 per GB for the first 10 TB of transfer bandwidth you use in a month. And the prices go down from there. Get out your calculator and do the math to see how much data you have to be moving around before this starts to cost you more than you have in your change jar, and you’ll likely spend 20 minutes or so cackling to yourself about just how inexpensive mind-blowing web power is these days.

- Cloudfront, Amazon’s CDN charges $.01 for every 10,000 GET requests. Do the calculator thing on that one (realizing that it’s basically an add-on to the above), and you’ll be laughing even longer.

- We buy EC2, Amazon’s scalable-on-demand computing service, through a reseller (EngineYard) who really doesn’t add all that much to the $0.085/hour cost that Amazon themselves charge. EngineYard is able to offer hosting solutions optimized for Rails based on EC2, along with monitoring and Rails-oriented deployment and management tools, for so little extra on top of what Amazon themselves charge that for the first few weeks you’ll feel like you’re getting away with a crime.

Without the open source libraries I mentioned above, Pedro would take much, much longer to build and would be necessarily a bit less stable, simply because my team and I would be building everything from scratch. But without Amazon Web Services, there’s no way we could even entertain the notion of making this app. Pedro is a game: a funny, 99-cent App Store novelty that we hope will go viral and make us some cash. Apple gives us a great way to distribute the app, but without Amazon, we’d have show-stopping cost barriers to actually building a backend capable of meeting rapid, viral demand. A few years ago, just standing up unused production infrastructure to handle these use cases would’ve cost us thousands of dollars a month in rents, to say nothing of what it would cost in time and/or people-hours to have a qualified sysadmin lurking on our payroll. Now because of Amazon, those barriers are gone — replaced by a giggle-inducing cost structure for computing resources that back one of the most powerful retailer/supply chains on Earth.

With the preponderance of open source libraries and the rise of commoditized enterprise-scale computing, the utopia really is now — the only things holding anyone back are time, creativity, and will.

Speaking of which, I need to dive back down my code hole. See you in a month or so.

Say you start the debugger here:

Then you want to take a look at the “xml_obj” variable. If this were (for instance) Python’s pdb, we’d just type “xml_obj” and hit return and be done with it. Not so in ruby-debug:

This is because with default settings, the debugger needs a keyword (’p') to get it to actually evaluate your statement as Ruby and not a command to the debugger itself:

That gets really tedious, really fast. The debugger’s help function (’help p’) will helpfully tell you that this is because the “autoeval” option is not enabled. If you’re thick like me, you won’t see this and you’ll just continue doing “p <whatever>” until you get so frustrated you drop what you’re doing one day and go hunt down a fix.

Here is that fix from inside your code:

You can also do this inside the debugger:

Rails already does it via Rack middleware

You might be wondering why the debugging experience is different in Rails than in Ruby you’ve written elsewhere. I did too — remembering that this ‘p’ business isn’t necessary when I run the debugger as an option when I start up Mongrel in a Rails app. So I went digging for the code that Rails uses to set this stuff up. Those settings come from a piece of Rack middleware that lives in lib/rails/rack/debugger.rb. Here’s the class definition:

For more info on how Rails uses Rack, this is a pretty handy page from the Rails guides.

Some parts are kind of confusing, but it’s a testatment to how much code he posts that I didn’t even realize he was French until I sat down to write this post and read it more carefully — he communicated mostly in code.

He gives a good Rails application.js file for you to start out with — basically it provides a bunch of handles for things you want to remote w/ XHR. They use the new-ish jQuery method unbind to make sure that regular events on items designated as AJAX get overriden. Pretty slick and a good way to think of jQuery’s usage in an app context. So far, I hadn’t really used it for AJAX beyond a thing I wrote to enable cross-domain MX record validation.

Example: remote links

Rails provides the link_to_remote helper to let you create links that will trigger a GET over XHR. This application.js defines a jQuery function for that and then binds it to a certain class of links — “get”:

Which is then set with this:

Now any anchor with class “get” on it will result in a remote call to the URL in that anchor’s href. Combined with a respond_to block in your controller to handle Javascript and a Javascript template file, you can use links like this to (for instance) load ActiveRecord objects into a page using AJAX. Instead of “show.erb.html” your controller’s show method is handled by “show.js.erb”. This block in the show method of the controller ensures that it is activated correctly:

Because the call came in over XHR, the controller sees the format as being JS and responds with the instructions set in the block passed to format.js. Rendering without layout ensures that nothing but the rendered data plus the template is returned.

Notice that the AJAX call in the above snippet from application.js uses the “script” datatype. This specifies that the returned data should be evaluated as Javascript, which is what we want, because the returned data includes the jQuery-based instructions we have inside show.js.erb, and those need to get evaluated (not just displayed) in order for the page to look right.

An aside: One thing that this makes me think about a lot is how important visual design is when you’re developing an application. Your design has to correspond concretely to a DOM with all sorts of manipulative handles (ids and classes) and all sorts of custom functions built to do various things to/with them. You’d damn well better draw a decent picture of this and give the elements of it some good names that make sense. In fact, I think a lot of the true work in programming involves drawing pictures (I still model some embarrassingly simple relationships with pencil and paper), but that might just be the way that my brain works.

Anywho, I took the above application.js and used it as the basis for a conversion from RJS to jQuery in a Rails app I’m working on. I’ll probably end up adding quite a bit to his stuff as I go, but having this file around made starting the transition process a lot easier.

I expect to do some more posts on the conversion as I go, since I haven’t found a whole lot of stuff yet that’s oriented toward “strategies for using jQuery with Rails” and wasn’t written in 2007. RJS kept me from dealing w/ JS directly as a major component of my app, but those days are over now that I’m committed to unobtrusive JS via jQuery, and a more thought-out approach will be necessary.

Sound familiar?

I was in this boat until I found out about the profiling command:

The double “spec” here can be a bit confusing. The first is the command, and the second is the directory (RAILS_ROOT/spec) that you’re running it on. The -f is the format flag. You can see a list of all formats with:

Basically you’re just passing the “profile” argument to the formatting command. It gives you a readout of the 10 most time-intensive specs at the top and then a nicely verbose list of all pending and failed tests. Using this list, I was able to go straight to the most obnoxious offenders and eliminate the external dependencies (these specs happened to be fetching feeds) that were slowing my test suite down. In less than 15 minutes, I had chopped my execution time down to 10% of what it was before I started.

Huzzah!

• Everyone calls it autotest, but it’s actually ZenTest that you need to install. ZenTest is a larger testing package, of which autotest is merely one part.
• Autotest runs as a separate process (which you should background — the ‘&’ is your friend!) and watches your Rails dir after you have it turned on. This last bit took me some time to figure out, as the otherwise excellent RSpec Peepcode screencast completely glosses over this point. I kept waiting for the magic to happen when I hit “save” in TextMate, but I didn’t have the process running from the command line. Magic doesn’t work. I should stop expecting it to.
• Do yourself a favor and vastly simplify your autotest–>Growl connection by using Collin VanDyck’s GrowlGlue gem as the basis for your .autotest config file.

As of right now, I’m sitting here with just the basic GG config. I’m sure I’ll expand/customize tomorrow, but I’m just happy for now that I was able to get a working setup with just one line of code, as the normal way to get the connection going involves a decent amount of crap. After you get that going, GrowlGlue lets you set up all sorts of customization of the notifications — including custom messages, custom notification icons, and even speaking your test results through OS X’s built-in text-to-speech support — in nice, neat Ruby statements.

It’s nice to have something get in my face about my tests, and it’s also nice to have something that automatically makes you want to get your tests passing and running faster. Autotest provides you with the nagging voice that says “get your tests running right, holmes!” It’s good to strike this longstanding to-do off my list.

Late update: Turns out that running autotest in the background isn’t really ideal since you might sometimes want to cancel a running suite or check out the time elapsed since you started a given test set. What I’m looking for now is a way to see how long it takes any individual test to run so that I can find the offenders that are kicking up the aggregate time.