May 20, 2008 @ 10:59 AM by nap · 0 comments
I’ve got my itinerary planned out for Railsconf. I’ll also be hitting up a couple other west coast cities before landing in Portland. First stop is SF to visit my friend Ankit on Friday. Then trekking up to Eugene on the Amtrak Coast Starlite (I love me my trains) late night Sunday to hang and brainstorm with our designer/big-thinker Ty for a few days. Then it’s off to Portland on Thursday.
If you’re in any one of those cities and want to grab a beer (or a smoothie), hit me up on Twitter. Hopefully I’ll see some of you at Railsconf.
Also, I’ll be giving a talk at NHRuby tonight (5/20) on Rack. If you’re in the area, stop by.
May 05, 2008 @ 09:12 AM by nap · 1 comment
Played around with Passenger (v1.0.4) a bit more last weekend. Deployed a Radiant instance with it for staging. Overall, quite happy. However, thought I’d take the opportunity to jot down a few observations:
First, Radiant, with a smattering of extensions, takes a while to start up on the vhost we’re playing around on (yes, need to pump up those specs before deploying anything real). Since Passenger cleans up idle Rails instances when they fall into disuse, this can mean a harsh initial request delay for infrequently accessed hosts.
Passenger has clearly targeted the shared host market, where hosts have a large memory footprint and a large number of applications. The same strategy doesn’t work quite as well for a small VPS memory footprint and a single application root, where it would make sense to keep an instance in memory at all times (and clean it up and respawn it, perhaps, on occasion if an idle timeout is reached).
The solution in this case is to increase the Rails pool idle timeout to something that matches your traffic profile (of course, the tradeoff there is with the growing memory footprint of long-running processes…). And while you’re at it, adjust the maximum number of spawned instances—it defaults to 20, which is great for a dedicated with 2GB but not so good if you’re running a single application on a 512MB VPS.
More information is available in the architectural overview and the excellent user guide that the Phusion guys have put together. The SpawnManager itself is written in Ruby, and has a set of RDocs that you might want to take a look at as well.
We initially had some process ownership issues, where the Rails production log wasn’t being written to. The Rails server instance is going to be running as whatever user owns config/environment.rb (unless you change this in the config), so make sure to chown/chmod appropriately.
Finally, the restart mechanism, although a bit odd, is pretty useful. If you touch a file called restart.txt in the #{RAILS_ROOT}/tmp directory, it’ll reload the application instance on the next request without having to explicitly restart apache. Here’s a Capistrano deploy:restart task for this:
namespace :deploy do
task :stop, :roles => [:app] do
puts "Use the deploy:restart task to restart the Rails application"
end
task :start, :roles => [:app] do
puts "Use the deploy:restart task to restart the Rails application"
end
task :restart, :roles => [:app] do
run "touch #{current_path}/tmp/restart.txt"
end
end
May 03, 2008 @ 10:44 AM by nap · 0 comments
The single hardest thing about writing a book, I’ve decided, isn’t the writing part. It certainly isn’t the technical part either. I don’t mean to downplay my own skills or those of any other technical author, but the truth is that you don’t have to be a guru to write a fantastic book (it does help, of course).
The key to writing good book material is being able to show people how to do things while keeping them entertained. That means coming up with examples that tread the line between being practical, being appropriately demonstrative, and being correct. Good examples are the hard part.
When developing an example, you’re trying to come up with something that has the following characteristics:
- It’s interesting. That is, it’s worth writing about in the first place. No one wants to read another blog post creation example (unless there’s something unusual about it). BORING.
- It represents best practices. You’re an author. You have to be right. Or at least able to competently defend your implementation choices, anyway.
- It illustrates those concepts that you’re trying to write about. This should be first point, rather than third. See what I mean?
- It minimizes focus on those elements that you are not writing about. That is to say, we shouldn’t spend a lot of time talking about fuzzy bears, even though there are many different types of fuzzy bears, six species of which are listed as vulnerable or endangered by the World Conservation Union (whose headquarters are in the scenic Lake Geneva area of Gland, Switzerland).
The last point is a tricky one, but it’s important. You have to cut corners when creating good examples—but not the important ones or the ones that would prevent it from representing best practices. If you’re trying to illustrate, for example, how to build a tag cloud, you don’t want to spend lots of time on the CSS for making it pretty. Leave that to the CSS books.
If your example involves video transcoding, and the point is to illustrate the use of a message queue, you’re going to be really tempted to spend an extra 2-3 pages on certain format discrepancies or operational edge cases but DON’T. It’s interesting, sure, but if it’s not central to what you’re currently trying to demonstrate (message queues). You must resist.
If your example is a simple web service for sharing geographic location data and you’re using a bunch of RESTful conventions, make sure to explain the basic concepts. But don’t write a dissertation on REST vs SOAP. And don’t worry about responding to formats that aren’t part of the main example.
Just because it’s how you’d do it in a real-life project doesn’t mean it’s how you’d write about it or explain it to others. Keep it simple, lively, and (as Gold Five so succinctly put it before crashing his X-Wing) stay on target.
