It’s been a while since I’ve posted to this blog, so I thought it was time for an update.

Anyone who has been involved in a startup knows how all-consuming that can be. We also have a blog over at BuildingWebApps.com, and I’ve been writing a bit both for that blog and for the core of the site. But most of what has been consuming my time is crafting a business around the technology we’ve been developing.

Christopher Haupt and I founded Collective Knowledge Works, Inc. last fall, and our first venture was to launch BuildingWebApps, a resource site for Ruby on Rails developers. We also started the Learning Rails free online course, which began with podcasts and has evolved into a series of screencasts, in which we build a Rails application step by step. It’s been tremendously popular, with several thousand people following the course. It’s a lot of fun teaching this way, and seeing how much value people get from it.

We considered building a business around serving the web application developer community, but we’ve decided to keep this as a side project, rather than the core of our business, because we want to build something that we believe we can scale into a more significant company.

In thinking about the application we built to create the BuildingWebApps site, we realized that it has a much broader potential use: building a resource site on any topic. We think of it as the next generation beyond blogs and content management systems. We’ll offer this as a hosted service, enabling anyone to build a site like BuildingWebApps, on any topic.

The next question was which customers to focus on. We found that, as a horizontal technology platform, it was hard to explain to people, and hard to come up with a focused marketing strategy. Some customer groups we looked at include:

• Infopreneurs: people building web-based information businesses
• Passionates: individuals or organizations who are passionate about a topic and want a platform for communicating their knowledge and engaging the community
• Businesses: businesses for which educating their customers and prospects is important

After lots of analysis, we’ve decided to focus our initial product on the last of these categories: in particular, on small businesses. There’s a lot of customer pain here that we can address, and a lot of value that we can provide. Most small business sites are awful, if the business has a site at all. The model of going to a local web developer and building a site from scratch is expensive and painful, and almost always results in a largely static site with no community features.

We’re going to provide a platform to make it easy for small businesses to create powerful sites that engage their customer community and become valued information resources that attract new customers. There’s lots of pieces of this that go beyond what we’ve done at BuildingWebApps, and which we’re not quite ready to talk about.

We may also have versions of the platform for the other two customer categories, and they may be the source of significant long-term growth, but they won’t be our initial focus.

We’ve raised a little more angel financing to take this to the next level, and we’ll be launching the product in the fall. There’s a teaser at the embryonic Collective Knowledge Works site. If you’d like to be notified when we have the private beta ready, please enter your email address there.

It’s been a fascinating process getting to this point. It’s been a year and a half since I left Adobe and gave myself the flexibility to pursue various interests and see what bubbles up. A lot of threads have come together now, and I’m really excited about where we’re heading.

The RailsQuickStart seminar that my colleague Christopher Haupt and I will be presenting in San Francisco next week is filling up fast, so if you’ve been thinking of attending, now is the time to sign up. The seminar is February 20 and 21 at Fort Mason in San Francisco.

We have a packed two days planned, divided into lecture sections in which we’ll explain how Rails works, live coding sections in which we’ll build a complete application step-by-step, and lab sections in which attendees will extend the sample application. Everyone will also get a one-month hosting account, courtesy of Joyent, and before they leave the seminar their app will deployed. We’re including customized Capistrano scripts and and a subversion setup.

If you’ve been wanting to learn Ruby on Rails, or if you’ve been playing with it but have struggled to climb the learning curve, this is your chance to move into high gear.

After several months of development, we have finally taken the wraps off the BuildingWebApps site!

Note: I won’t be publishing any more Ruby on Rails or web development articles on this blog. This will be more of a personal blog, with everything related to web technology going on the new site. To continue receiving the Rails articles that I and my colleagues will be writing (and we have plans for lots more articles than I’ve been able to publish here), please subscribe to the BuildingWebApps articles feed.

You can also subscribe to the BuildingWebApps blog, where I’ll be writing about the process of building the site and the business.

State of the site

BuildingWebApps.com is still very much a work in progress, but we’ve gone ahead and opened it up so we can get feedback. Please take a look and let me know what you think.

We worked with Josh Woodlander and Ethan Allen at Raspberry Media on the visual and interaction design, and I think they did a fantastic job. It was a joy to work with people who have such a strong sense of graphic design and who think deeply about the challenges of effectively presenting lots of information. And Ethan is a wizard at making all the browsers behave reasonably. (Any oddities you see are probably the result of my modifications.) If you’re looking for a team to take on a significant web design project, I highly recommend them.

My goal is to build this site into a valuable resource for the Ruby on Rails community, and for people who want to learn Ruby on Rails. Over time, we’ll increase our coverage of other web-related technology as well.

The site includes both original articles and an annotated, organized set of links to hundreds of other resources around the web. We’re in the early phases of building up the content, so I realize that it will seem a little thin in places (and if you’ve read the Rails-related articles on this blog, some of it will seem very familiar). But there’s lots of great stuff to come.

I’m really interested in feedback on the usability of the site. You can also submit suggestions on the site to help us build up the content.

How is this a business?

In case you’re curious about the business model: we plan to make all the core content free indefinitely. At some point, we’ll add some premium content that will require membership or a one-time payment. We’ll probably have advertising. And we’re offering seminars.

Longer term, we believe that the application we’re building to power this site will be applicable to many other knowledge domains and communities. Blogs and wikis are all the rage, but they both have huge limitations that we believe our platform will overcome.

Don’t forget to change channels

Once again, please note that I won’t be publishing any more Ruby on Rails or web development articles on this blog. I will continue this blog to write about a variety of topics beyond web development, so please keep your subscription here if you’re interested in my random thoughts. But if you subscribed to this blog primarily for web development information, it’s time to move on:

• To continue receiving the web development articles that I and my colleagues will be writing, subscribe to the BuildingWebApps articles feed.

• To read about the evolving business of which BuildingWebApps is a part, subscribe to the BuildingWebApps blog.

Thanks!

A little more than a year ago, there really was only one Rails book: Agile Web Development with Rails, by Dave Thomas, David Heinemeier Hansson, and friends. Since then, about a dozen Rails books have come out. None of them, however, has replaced this seminal book as the best general resource for Rails developers.

This is not to say that there have not been some excellent books. Some do a better job at providing a gentle entry for beginners, others focus on specific areas, and many provide interesting example applications. But they are mostly tutorials, rather than references.

The Rails Way changes this. It is a better Rails reference than the Agile book, both because it provides more depth and because it is current with Rails 2.0. For the first time, there is a second book that is indispensable for any serious Rails developer.

The Rails Way is not a good book for someone new to Rails; there is no introductory overview, no Ruby tutorial, and no sample application. But as a reference, it is unmatched. It is very readable, despite being a reference work, because author Obie Fernandez has insights to share in almost every section. In skimming through the book, I found details in almost every section that I never quite understood before, which the books explains with sparkling clarity.

Even though it is intended primarily as a reference, The Rails Way is an outstanding tutorial for anyone who understands the basics of Rails and wants to dig deeper (and has a few days to spend reading). In this regard, it is true to its namesake book, Hal Fulton’s The Ruby Way, which holds a similar place in the Ruby world.

The Rails Way’s coverage is both deeper and broader than any other Rails book, in covering the Rails framework and associated plugins, tools, and attitudes. It weighs in at 850 pages, about 10% longer than the Agile book—and a third of the Agile book is the tutorial introduction and sample application.

If you’re working with Rails on anything but the most casual basis, you shouldn’t work without this book nearby.

During the dozen or so years I ran the Microprocessor Forum conference, I presented hundreds of seminars on microprocessors and PC technology. I enjoy teaching, and I’ve missed this aspect of that business.

Since I’ve been working with Ruby on Rails, I’ve been thinking about how it could be made easier for people to learn. I believe there are vast numbers of web designers and developers who would find Rails a very useful tool, and who could improve their productivity—and their satisfaction with what they’re producing and the process of producing it.

One thing led to another, and on February 20 and 21, my colleague Christopher Haupt and I will be presenting our first Ruby on Rails QuickStart seminar in San Francisco.

We’ve designed the seminar for web designers and developers with only minimal programming experience. We’re providing a pre-built site, which we’ll walk through during the seminar, that attendees can use as the basis of their own sites. We’re also very close to a deal with a hosting provider to offer free hosting for a month, so we can help attendees get their sites deployed before the seminar is over. We’ll provide each attendee with the NetBeans IDE, deployment scripts, and everything else they need to immediately build and deploy Ruby on Rails web sites.

I’m really looking forward to the seminar and hope some of my readers can join me there.

The early registration price of $695 is good until December 20. There’s details at the BuildingWebApps.com site.

Today I began my podcasting career with the publication of the first episode of Learning Rails. It’s been a lot of fun pulling this together—and a lot more work than I anticipated. I’m looking forward to recording future episodes when I’m not learning the audio software and assembling the web pages and the RSS feed infrastructure at the same time.

If you have any interest in learning more about Ruby on Rails, check out the first episode: Why You Should Learn Ruby on Rails. I’d really appreciate any feedback, which you can leave as a comment on this post. And if you like the podcast, please give it a Digg, post a link on your favorite social bookmarking site, or mention it in your blog.

I wrote a post about my goals for the podcast and some of the tools I used over on the BuildingWebApps blog.

A few weeks ago I attended the Advanced Rails Studio, taught by Mike Clark and Chad Fowler. (Dave Thomas would normally be there as well, but he broke his arm and was unable to attend.) Mike and Chad are deeply knowledgeable and are natural teachers, making for an enjoyable and productive three days. I highly recommend this course to anyone who has been building Rails sites for a little while and wants to take their skills to the next level. It will be offered again in spring 2008; you can sign up on their site to be notified.

Inevitably, some of the material was review of things I already knew, but there were still plenty of things I didn’t know, or didn’t understand well, before the seminar. Perhaps the most valuable part was getting opinions and perspective from experienced Rails developers—not just the instructors, but other attendees as well.

Here’s a random selection of tips I wrote in my notes. These are probably not all intelligible from these brief descriptions, but they provide a flavor of the kinds of information I gleaned.

• Use a “test rig” file to generate standard CRUD tests.
• Use helper methods in tests and in views to keep your code at a consistent level of abstraction.
• Consider test/spec, which provides a BDD (behavior-driven development) layer on top of test/unit. Mike and Chad prefer this to rspec.
• Consider using simple Ruby hashes instead of fixtures. Mike has abandoned fixtures almost entirely.
• If you’re using the default resource scaffold, which allows xml access to models, override to_xml in the model so you can use the :except option to keep sensitive fields from getting included.
• Don’t bother with small RJS files; just put the RJS code in the controller.
• All the respond_to code and XML handling in the scaffold resource controller is not necessarily a good thing. Mike doesn’t use respond_to unless he knows he’ll be providing API access. It adds noise to your code, can be a security hole, and just isn’t needed if you aren’t supporting an API.
• If you accept credit cards, be sure not to store them in your database. VISA’s rules are hard to comply with, and penalties for non-conformance are high. Use a solution that allows you to immediately pass the credit card to the gateway, or even better, post the form with the credit card info directly to the gateway. Braintree Payment Solutions allows you to do recurring payments without storing credit cards by returning a token that you can use for future charges.
• make_resourceful plugin automates creation of CRUD actions for a resource.
• In most cases, has_many :through is a better solution than has_and_belongs_to_many. One time the habtm approach makes sense is for tagging.
• You can define methods on an association proxy. In the model, e.g., has_many :visits do <define custom find here> end.
• ferret is a port of the lucene search engine, whereas solr uses the original Java source, so it is more current—but it does require that you run a Java app server for the engine.
• If almost all of a page can be cached, but a little part like the login name cannot, cache the entire page and then use JavaScript to replace that section of the page after it loads.
• Disable sessions for controllers or actions within a controller where they aren’t needed.
• To decode the contents of a session: Marshal.load(File.read(“tmp/sessions/filename”)).
• use pp (pretty print) to print out an object in more readable form (much nicer than p(object) or object.inspect).
• simply_helpful is rolled into Rails 2.0. The plugin is now in the legacy folder. If you use this in your 1.2.x apps they’ll have a smooth path to 2.0.

And there’s more, but that gives you the idea…

I’ll be writing up many of these items in detail for www.BuildingWebApps.com once we get that launched.

For the past several months, the majority of my time has gone into a web application for a startup called Accreditation Helper. The marketing site went live today, and next week the product will be shown publicly for the first time at the Medtrade show in Orlando.

This web app forms the heart of the business for Accreditation Helper, which assists Home Medical Equipment companies …

See the full article on my Topaz Web Solutions LCC blog.

I’ve continue to use NetBeans for my Rails development work, and while I’m still generally happy with it, I’ve found the daily builds since the M10 milestone release to be problematic. Most serious for me were frequent Java exceptions occurring when doing the simplest of editing in RHTML files. In many builds, this bug rendered the editor virtually unusable. Many weeks went by with no improvement in this. I ended up reverting to the M10 release and deciding to ignore the daily builds.

A few days ago, Sun released the NetBeans 6 Beta 1 version, and these problems have significantly improved. One nice improvement is that there is now a Ruby-specific version that is only 19M, vs. 172M for the full package, and it also starts much more quickly.

As I write this post, however, I’m waiting to see if NetBeans comes back to life after freezing in an RHTML edit session. The Windows Task Manager shows java.exe sitting at 50% CPU for 10 minutes, NetBeans is completely unresponsive, and I’m about to give up and kill the application. This sort of thing is to be expected in beta software, but make no mistake, this is not production quality code.

I encountered one other very frustrating problem that has a simple solution. The current release of the JDK, 1.6 update 2, has a very serious bug on Windows XP that causes it to be extremely slow opening files in many situations. I found that File > Open in NetBeans hung for literally 5-10 minutes, and then suddenly would come back to life as if nothing was wrong.

It turns out that the solution is to simply uninstall update 2. JDK 1.6 update 1 does not have this problem. And disable the automatic Java updates, so you don’t get Update 2 foisted upon you.

I find it hard to understand why Sun has let this problem go uncorrected, and why there is no conspicuous mention of it anywhere in Sun’s documentation for the release. A little searching of the Java bug lists reveals that JFileChooser has been, in one user’s words, “an open wound” since at least 2004. The problems in 1.6 u2 first started in 1.4, or earlier; got better in 1.6 u1; and go worse again in 1.6 u2. (See, for example, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050516.)

One gets the feeling that Sun just doesn’t care about Windows, which may be true, but is a very shortsighted viewpoint if they care about widespread use of applications like NetBeans. (And I believe any Java Windows app would be similarly affected.)

There’s a lot to like in NetBeans, and I’m keeping my fingers crossed that when the production release comes later this year, the quality will be a lot better.

When I started this blog almost a year ago, I really wasn’t sure what I’d be writing about. As it happened, it ended up being much more technical than I had envisioned, and focusing a great deal on building and deploying Ruby on Rails applications.

I haven’t written nearly as much as I would like about Rails, in part because this blog felt like not quite the right place for it—I want something with a richer information architecture.

In the past year, I’ve collected a huge list of links to useful blogs, valuable references, ebooks, mailing lists, conferences, and other resources. There’s a tremendous amount of information available on the web, and it’s hard to imagine learning all this technology without the web as a resource. But this information is widely scattered, and while a google search will sometimes lead you quickly to the best resource to answer a given question, often it takes quite a bit of sleuthing. Rails itself makes it relatively easy to build an application to organize and present all this information—a curious sort of virtuous circle.

In the past few months, I’ve been working with my colleague Chris Haupt on just such an application: BuildingWebApps.com. The BuildingWebApps.com main site is currently in a limited private beta, but you can visit the site now and sign up to receive an invitation when we’re ready to accept more beta users.

We’ve begun a BuildingWebApps Blog, which explains a little more about what we’re doing, and will chronicle the development of the site. If you’re interested in Ruby on Rails or web applications in general, please visit the new blog and sign up for its feed.

With all the “how to build an application in Rails” books that have come out this year, do we need more? Yes!

RailsSpace is a well-written, insightful introduction to Rails that uses the creation of a simple social networking application to tell the story. It’s not a reference book, and it may move too quickly for absolute beginners. But for more experienced readers who are new to Rails, or for Rails developers with some experience who are looking to learn a few new tricks and pick up some best practices, this is a great book. The step-by-step creation of the social network application (and thankfully not another shopping cart) provides a cohesive structure and creates natural opportunities to introduce a wide variety of topics.

Author Michael Hartl was previously a physics instructor at Caltech, and his teaching experience shows. The book progresses naturally, explaining just enough as it goes along to keep the reader oriented without too many diversions. This is a real challenge in an introductory Rails book, since there’s a lot of pieces you need to understand to some degree before it all makes sense. Coauthor Aurelius Prochazka is a very experienced web developer, and this too shows through. The book is full of insights and best practices that make it more than just an introductory text, and also make it an enjoyable read.

Although the book only scratches the surface of many advanced Rails topics and doesn’t go too far into Rest or Ajax, it covers well a number of topics that are often neglected in introductory books. Testing is addressed nicely; the book doesn’t use a test-driven development (TDD) approach, which interferes with learning the basics of Rails, but it does show how to test each feature after it is built. It also has a good section on searching, covering both the use of Ferret and the creation of searches using multiple, specific model fields.

There’s a companion web site, built using the code from the book, at which you can browse the source code. You can also download a sample chapter, RESTful Blogs.

Experienced Rails developers may want to wait for two very promising books due out later this year: Mike Clark and Chad Fowler’s Advanced Rails Recipes, and Obie Fernandez’s The Rails Way.

When I started developing Rails applications last fall, I looked at various Windows editors and IDEs and ended up going with RadRails. I was reasonably happy with it, but development stalled, and then it got picked up by Aptana. This seemed like a good move, since it gave the IDE a funded development organization and good HTML, CSS, and JavaScript support.

Aptana has been hard at work on the IDE, and it has been advancing pretty rapidly. They added support for Adobe AIR (aka Apollo) and for Apple’s iPhone as soon as those products were shipped, and the Ruby and Rails support has been moving forward.

I found the most recent release quite buggy, however. This is not entirely surprising, for software that is still beta and is evolving rapidly, but it was enough to make me look around at alternatives. I’d heard good things about NetBeans, Sun’s open-source IDE, but hadn’t wanted to take the time to switch tools. With the current state of the Aptana code, however, my willingness to switch increased dramatically, and a new milestone release of NetBeans made it look even better.

NetBeans vs. Aptana/RadRails

So this morning I downloaded NetBeans. It took me about two hours to download it, figure out how to use all the core Rails features, and get a few projects imported into it from my Subversion repository.

By the end of those two hours, I knew I’d be unlikely to use Aptana again. NetBeans just feels more capable and more polished, and while I found a couple bugs (using the latest beta release), it was much more stable than the current Aptana release. By mid-day I felt at least as productive in NetBeans as I ever was in RadRails.

I’m sure I never found many of the features in the Aptana IDE, and switching to a new IDE gave me the impetus to spend some more time learning to use it more effectively (and the documentation was very helpful). I’m not going to give a blow-by-blow comparison, but I feel very confident in saying that you owe it to yourself to check NetBeans out.

Some of the features I immediately appreciated were the code hinting, ability to split the editor window into multiple panes either horizontally or vertically, better UI for accessing generators and Rake tasks, highlighting of the begin and end of Ruby methods, blocks, and HTML statements, and marking of where in each file code has been deleted and inserted.

Installing NetBeans

To install NetBeans:

• First you need to install the Java Development Kit (unless you already have the JDK installed).
• Then download the latest build of NetBeans, which as I write this is Version 6.0, Milestone 10.

You need the full 172-Mbyte version to get the Ruby support, and to get all the Rails features, you need this early release of Version 6.0, not the stable 5.5 version. The final 6.0 release won’t happen until late this year, but from my one day’s use of it it seems pretty stable.

The installers are self-explanatory, and you don’t have to do anything special to get it running. Support for Ruby, Rails, and Subversion is built in. Once you’ve imported a Rails project, right-click on the project to run it (it starts a Mongrel server) and access Rake tasks from the context menu.

By default, NetBeans uses JRuby, rather than the standard Ruby interpreter. JRuby executes Ruby code on the Java virtual machine, which has huge advantages if you’re integrating with Java code. I’m not, and I figured I didn’t need one more variable to deal with, so I chose the configuration option to use the standard Ruby interpreter (which is painless).

NetBeans Resources

There’s lots of information on the web about setting up NetBeans milestone 9 and earlier for Rails development. Ignore them! It’s a lot simpler now, because Milestone 10 has it all built in.

Here’s a few places to look to get started with NetBeans Rails development:

• Detailed (but slightly dated) comparison of RadRails and NetBeans
• Tor Norby’s Blog. Tor is one of the NetBeans developers working on Rails features, and he has a lot of great posts about its features on his blog.
• DevX article on Ruby development with NetBeans
• Creating a Ruby Weblog in 10 Minutes. A quick tutorial on building a Rails application with NetBeans.
• Putting Flickr on Rails. Another quick example of building a simple Rails application with NetBeans.
• Screencast movie of Putting Flickr on Rails
• NetBeans Ruby Editing. Shows how source-code-completion and other features work.
• Visual Web Designer. A NetBeans add-on that provides a GUI web page design environment. I haven’t had a chance to explore this yet and don’t know if it would be useful in a Rails context.

I find it amazing that products of the richness of Aptana and NetBeans are free. They’re easily as deep and sophisticated as most of Adobe’s $500+ products, for example, and they’re evolving a lot more quickly. If there was a group motivated to make this kind of investment in a Photoshop alternative, it would be big trouble for Adobe… but luckily for Adobe, there’s not. At least those of us building web applications can enjoy this embarrassment of riches.

(Update: I’ve rewritten this article because of a problem with the approach proposed in the initial version, as explained below.)

In any application in which a user enters an email address, there is the very real possibility that the user will make a typo and your application will end up with an invalid address. You can have them enter it twice, but this seems clunky. And you can, of course, send an email with an activation link, which provides the only true validation, but there’s no need to bother sending the email if you know the address is no good. Furthermore, once you’re past the page where the user enters their email address, you’ve missed your chance to tell them there’s something wrong and they should correct it.

So you really should do what you can to validate the address when the user enters it. I recently made a simple addition to my applications that helps a lot: verify that the domain name is valid.

It’s surprisingly easy to do—especially with a little help from Peter Cooper’s excellent Beginning Ruby, which has a very useful chapter on network programming. The following code is adapted from his examples:

require 'resolv'
def validate_email_domain(email)
      domain = email.match(/\@(.+)/)[1]
      Resolv::DNS.open do |dns|
          @mx = dns.getresources(domain, Resolv::DNS::Resource::IN::MX)
      end
      @mx.size > 0 ? true : false
end

This example makes use of the Ruby standard library “resolv”, so you need to require it first.

The first step is to separate the domain name from the rest of the email address. The regular expression captures the part of the string that follows the @ symbol.

Then the code creates a new DNS resolver object and queries the resolver for an MX (mail exchanger) resource at the specified domain. This returns an array, which will be empty if there is no MX record for the domain.

(Note: In a previous version of this article, I used Resolv.getaddress to see if there is a DNS entry for the domain, instead of checking for an MX record. This approach works most of the time, but it rejects any domain for which there is no A record. If a domain is used only for email and not for a web server, there might not be an A record. Also, some domains have an A record only for www.domain.com, which will also fail the simple getaddress test.)

You can use something like the following in the validate method within the appropriate model:

unless email.blank?
    unless email =~ /^[a-zA-Z][\w\.-]*[a-zA-Z0-9]@[a-zA-Z0-9][\w\.-]*[a-zA-Z0-9]\.[a-zA-Z][a-zA-Z\.]*[a-zA-Z]$/
        errors.add(:email, "Your email address does not appear to be valid")
    else
        errors.add(:email, "Your email domain name appears to be incorrect") unless validate_email_domain(email)
    end
end

I first check to make sure the email address is not blank, because that’s detected by a simple validates_presence_of :email statement that produces a different error message.

Then I make sure that the email address is at least syntactically reasonable, with a rather ugly regular expression, before bothering to check the DNS.

An even better approach would be to use an observer to validate the address with an Ajax call before the user submits the form.

It is possible to take this a step further by sending the SMTP server referenced in the MX record a “RCPT TO:” command. In theory, this would check that the user name is valid as well as the domain name. This takes additional time, however, and I’ve read that the response from mail servers is often not reliable. If anyone has tried this, I’d appreciate any feedback on how well it worked.

Earlier this year, O’Reilly’s Rob Orsini and Keith Fahlgren founded the North Bay Ruby Users Group. The group has had several meetings, but the turnout has been small. Faced with lackluster attendance and a plethora of other demands on their time, Rob and Keith decided to pull the plug.

I’ve agreed to take over the shepherding of this group so we can take another shot at giving it life. With the luxury of not having a real job, I’m able to devote a little more time to it than they were able to, and with the steadily increasing interest in Ruby on Rails I think we’ll be able to build a vibrant group. We’re the only Ruby users group between San Francisco and who knows where to the north—perhaps the only group for Sonoma, Marin, Napa, and Mendocino counties!

The group meets at 7 pm on the Third Thursday at O’Reilly headquarters in Sebastopol. We welcome everyone who is using Ruby, or Ruby on Rails, or is just interested in either, to join us. We’ll order in pizza when everyone arrives. So please join us on June 21, and we’ll figure out how to celebrate Ruby, Rails, the North Bay, and the summer solstice all at the same time.

I’ve built an embryonic new web site for the group (content to come soon…). I’ve also set up a Meetup group to help publicize and coordinate the meetings; that’s the place to go to RSVP. And, finally, there’s a Google group for discussions.

Another Option: North Bay Internet Society

I’m also still organizing the thriving North Bay Internet Society, which meets on the second Thursday of each month at various restaurants. This group uses a private Yahoo group; if you’re interested, send an email to northbayinternet-subscribe (at) yahoogroups.com telling me a little about yourself and your interests. This group is focused on Internet-related ideas and entrepreneurship, rather than hard-core technology.

This site uses Rick Olsen’s open-source Mephisto blog engine. Like all Rails applications, it needs to stay resident in RAM on the server. If you want to host multiple blogs, you can simply have multiple copies of Mephisto, but with this approach the amount of server memory needed grows with each new blog.

Fortunately, Mephisto can be set up in a multi-site mode, in which one Mephisto installation can host any number of blogs. This is an “experimental” feature, because there is no admin interface to support it, and you need to set up some directories manually, add sites using the Rails console, and add rewrite rules to your web server configuration.

I took me a while to understand how it all works and get everything set up properly. In this article, I’ll walk you through how it works and what my implementation looks like, in the hope that this tutorial may help others facing the same task. (Also check out the Hosting Multiple Sites page on the Mephisto wiki.)

How Multi-Site Works

In the multi-site mode, Mephisto looks at the host name (domain name) provided by the server and uses this name to change the routing. For the most part, this happens internally to the application.

There are three places, however, where it is exposed to the file system: assets, cache, and themes. Assets are files that you’ve uploaded, such as images, that are part of your articles. The cache is a set of html files for previously accessed pages, which eliminates the need for Rails to run at all when accessing a page that has already been viewed (and has not changed since). Themes are the liquid templates and CSS files that control the appearance of the site. All three of these need to be made domain-specific for multi-site mode to work.

Mephisto creates a subdirectory for each domain within the public/assets and public/cache directories. So if you have two blogs, blog-one.com and blog-two.com, you’ll have a structure like this:

• public
• assets
• blog-one.com
• blog-two.com
• cache
• blog-one.com
• blog-two.com

Mephisto will create these automatically, so you may not need to be concerned with them, other than ensuring that the web server is configured with the appropriate rewrite rules (described later). If you are moving a regular Mephisto installation to one site in a multi-site version, as I was, then you’ll need to move the contents of your public/assets directory into the appropriate public/assets/sitename.com directory.

The other set of files that must be unique for each site is the theme. The themes directory for a single-site installation includes a directory named site-1, which includes all the template and CSS files. In a multi-site installation, you simply add additional directories with the theme files, named site-2, site-3, etc. Unlike the assets and cache directories, these are named according to the database ID in the sites table, rather than by the domain name. Mephisto doesn’t set these up for you, so you need to create the required directories and copy in the files for the desired theme.

Setting up Multi-site Mephisto

With that background behind us, here’s the steps to set up a Mephisto installation for multi-site operation.

1. Do a basic Mephisto install. (See the Mephisto site for details.)
2. Edit environment.rb and uncomment the line
   Site.multi_sites_enabled = true
3. Start a Rails console, being sure to set it for production mode, assuming that’s what you’re running in. (Open a shell window at the root of the app, and type ruby script/console production.)
4. In the console, enter the following command to create each site:
   s = Site.create(:host => "domainname.com", :title => "Site Title Goes Here")
   Of course, you need to substitute your domain name for domainname.com and put in the site title (you can also change the site title when you get into the site’s admin pages).
5. Take a look at the sites table in the database to confirm that the sites are as you expect, and to confirm the database ID of each.
6. In the themes directory, copy the site-1 directory to a new directory for each site, named site-2, site-3, etc. The numbers must match the database IDs in the site table.
7. In your Apache configuration, assuming you’re using a virtual host, add a ServerAlias directive, in the VirtualHost section, for each domain name, so the application will respond to all the domain names.
8. Set up the rewrite rules, as described in the following section.
9. Start (or restart) the web server (e.g., Apache) and the application server (e.g., Mongrel Cluster)

Now you should be able to access the admin page for each site by simply browsing to domainname.com/admin to set up your sections, choose a new template if desired, edit the template, and so forth. Everything for each site should be independent.

If you ran Mephisto in single-site mode before setting up multi-site, then you’ll have some .html files in the public folder. Delete them all, or you’ll get unexpected (cached) results.

Configuring the Web Server

For requests that are processed by Mephisto, the application takes care of detecting the host name and accessing the appropriate site. Static files are served directly by the web server (e.g. Apache), however, so Mephisto can’t take care of mapping those requests to the appropriate directories for each site.

So, in addition to the setup of Mephisto itself, you need to add rewrite rules for your web server that, on each request, insert the domain name into file paths for asset, cache, and theme file requests. Just how this is done depends on what web and application server you’re using. I’ll explain the rules I’m using with Apache 2.2 and Mongel Cluster. These rules could go in an .htaccess file in Mephisto’s public directory; in my case, they’re in the httpd.conf file, since my configuration allows me to change the base configuration, which is more efficient than using .htaccess.

Several different sets of rewrite rules have been published in various blogs, groups, and wikis; what follows is derived from postings by dusty and seth to the Mephisto Google group. (If you’re not using Apache, you’ll need rules appropriate for your server; the Hosting Multiple Sites page on the Mephisto wiki has examples for Lighttpd and nginx.)

If you’re not familiar with Apache rewrite rules, the Apache site has a nice introduction. In essence, each rewrite rule uses a regular expression to translate the URL. If preceded by one or more rewrite condition statements, as in the examples below, the rewrite rule is only invoked if all the conditions are true.

Note that each of these rewrite rules has the L option applied, so if the rule is matched, none of the later rules are invoked.

The first rewrite rule inserts the domain name into URLs that begin with /assets. It first checks to see if the file exists, which may not be strictly necessary; if the file doesn’t exist, you’re going to get an error either way.

RewriteCond %{REQUEST_URI} ^/assets/.*$
RewriteCond %{DOCUMENT_ROOT}/assets/%{HTTP_HOST}/$1 -f
RewriteRule ^/assets/(.*)$ /assets/%{HTTP_HOST}/$1 [QSA,L]

The next rule rewrites the base URL to the index.rhtml file in the appropriate cache directory, if that file exists.

RewriteCond %{REQUEST_URI} ^/$
RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}/index.html -f
RewriteRule ^/(.*)$ /cache/%{HTTP_HOST}/index.html [QSA,L]

Now we need to check for any URL with a string after the domain name that doesn’t include a period. This means it is a Rails URL, and not one for a static file. In this case, we want to check to see if there is a corresponding .html file in the appropriate cache, and if so, rewrite it to a URL that includes /cache/domainname/ and appends .html.

RewriteCond %{REQUEST_URI} ^/[^.]+$
RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}%{REQUEST_FILENAME}.html -f
RewriteRule ^/(.*)$ /cache/%{HTTP_HOST}%{REQUEST_FILENAME}.html [QSA,L]

For static files that may be in the cache, we do a similar rewrite but without appending .html. This rule applies only to URL strings that include a period, indicating a static file (ending is something like .css or .jpg).

RewriteCond %{REQUEST_URI} ^/.+$
RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}%{REQUEST_FILENAME} -f
RewriteRule ^/(.*)$ /cache/%{HTTP_HOST}%{REQUEST_FILENAME} [QSA,L]

And finally, anything that wasn’t matched by any of the above rules is simply sent to Rails. In my case, this means invoking Mongrel Cluster, and the cluster is named blogs_cluster.

RewriteRule ^/(.*)$ balancer://blogs_cluster%{REQUEST_FILENAME} [P,QSA,L] 

Don’t forget to restart Apache after making any configuration changes.

If all goes well, you’ll now have a Mephisto installation capable or running many sites. If you have lots of sites, or any of them gets high traffic, you may want to have more than the basic two Mongrels, but for a few low-traffic blogs, two should be fine.

There’s a lot of information about Ruby on Rails scattered around the net, but it is indeed scattered. SoftwareDeveloper.com has published a useful set of links in an article titled 74 Quality Ruby on Rails Resources. It’s far from comprehensive, but it’s a pretty good start.

There’s a new Ruby book out that just may be the best resource for anyone getting started with Ruby, or who has been using Rails for a little while and feels they need stronger Ruby skills (which, I suspect, describes a great number of Rails programmers, myself included).

Beginning Ruby is, despite its title, not just a beginner’s book. It does start at the beginning, and it is written without assuming a lot of background, but it is not a simplified, dumbed-down treatment. I found it to be very easy to read, and it follows a natural progression from language basics through a variety of advanced topics.

The author, Peter Cooper, is a very experienced Ruby programmer, and his insights shine throughout the book. Among many other things, he’s the creator of Feed Digest, Ruby Inside, and code snippets, which he sold to DZone. He was recently interviewed for the Rails Podcast.

In addition to an exposition of the language that builds nicely over the course of the book, there’s chapters on the Ruby ecosystem, how to design an application, and network programming. There’s also a chapter that covers many of the useful libraries and gems.

There is one chapter that summarizes Rails, but this is definitely a Ruby book, not a Rails book.

Any Ruby book will inevitably be compared to Dave Thomas’ Programming Ruby (commonly known as “the Pickaxe” for the image on its cover), which has been the standard reference for the language since its debut and won’t lose its spot as a reference work. I found Beginning Ruby to be easier to absorb, however, and I thought the examples were especially clear and useful. If you’re already deep into Ruby, you probably don’t need Beginning Ruby. But if you’re relatively early in the curve, I highly recommend this book.

Update: some more presentations have been added to the conference site, most notably DHH’s keynote, titled “A peak at Rails 2.0”. (I’m not sure if he intended this as a pun or if he really means “peek”, not “peak”.)

I’ve just returned from a weekend in Portland at RailsConf. It was an impressive crowd—1600 people, triple the size of last year’s conference.

I found the conference uneven, as most are. There were occasional great talks, a few awful talks, and lots inbetween. The technical level also varied wildly, from introductory to the truly obscure. (I wasn’t able to make the first day of the conference, because of a big school event my daughter was in—kids come first. Some of the highlights were clearly on that first day: DHH’s keynote, and Ze Frank’s talk.)

My favorite talk, in part because it was at the right level for me in and in part because they were well prepared and presented well, was The Rails Way keynote by Rails core team members Michael Koziarsky and Jamis Buck. Their site is a great resource as well, showing how to refactor and rethink your code to make it better.

Some bloggers who took much better notes than I did:

• Daniel Wanja
• Nick Sieger
• John Nunemaker

Presentation Slides

The O’Reilly conference wiki has links to many of the presentations. I hope more appear there soon. Here’s some especially valuable ones that are online now:

• Harnessing Capistrano
• Rails Routing Roundup
• When V is for Vexing (DRYing up your Views)
• Building and Working with Static Sites in Rails
• Xen and the Art of Rails Deployment

For a visual take on the event, there’s lots of photos on flickr. For the best shots of the presenters, check out James Duncan Davidson’s wonderful photography.

IDEs Galore

There was a small exhibit area, with hosting services and IDEs in abundance. Despite an ongoing “real men use TextMate and the console” attitude among many of the Rails faithful, there’s tremendous effort being put into Rails IDEs, and there’s an abundance of alternatives:

• Aptana, which is integrating RadRails
• Sun’s Netbeans, which came from the Java world but now supports Ruby and Rails
• Borland’s CodeGear, which now has a Ruby on Rails beta version
• ActiveState’s Komodo

All are available for download in at least a beta state. Aptana and Netbeans are open source, while CodeGear and Komodo are commercial products.

I’ve moved from RadRails to Aptana and am reasonably happy with it. Each of the others has some nice advantages, but for now I’d rather spend my time writing code and doing business investigations than changing tools.

Incredible Momentum and Brainpower

If it wasn’t already abundantly clear, this event left me with little doubt that there is tremendous momentum behind Rails, and an amazing number of really smart people working very hard to keep making it better and better. There’s almost 9,000 people subscribed to the rubyonrails-talk list, which gets hundreds of postings a day. And this is a friendly, welcoming community with a heart and a sense of humor.

All in all, it leaves me more convinced than ever that this is the platform to ride.

Six months into my exploration of Ruby and Rails and the opportunities it represents, I’ve settled into a niche of building web applications that enable small and medium service businesses to better communicate with their customers.

Today, very few small service businesses have web sites that do much for them. Typically, if the business has any web site at all, it is mostly brochure ware, with a contact form as the limit of its interactivity. Yet almost every such business has interactions with its customers that could be facilitated by a customized web application.

For example, health care practitioners must deal with requests for appointments, referrals, records, and prescription refills. The office staff then needs an effective workflow to process these requests.

Accounting, financial services, and design firms have other needs; they typically have confidential documents they need to provide to their clients, and they need data from their clients. A web application can provide a much superior and more secure alternative to email.

There are countless other examples of businesses that could significantly improve their interactions with clients and customers via the web. But the vast majority of them have found it too intimidating and too expensive to implement the web solutions that they need.

I’ve found that my experience running small businesses makes it easy for me to understand the needs of these kinds of businesses and craft solutions that work for them. The Ruby on Rails platform dramatically reduces the time, and therefore the cost, to build these systems. And since I’ve now built several such applications, I have a set of building blocks to draw from that further streamlines the process.

In time, I expect to offer off-the-shelf hosted solutions for certain types of businesses, but for now I’m finding that each business has different needs. The best approach, for now, seems to be building a custom solution using building blocks that I’ve already created, plus new ones as needed for a particular business’ needs.

If you know of a business in need of such an application, please send the my way: ms (at) mslater.com, or 707.829.6447.

The challenges in scaling Rails applications for high-traffic sites are the subject of much debate and discussion. Too often, the people doing the debating really don’t have experience in trying to do so, which, in my mind, makes their conclusions questionable.

If you’d like to get some real insight into these issues from people with deep experience, check out the Ruby on Rails: To Scale or Not To Scale event in San Francisco next Tuesday. There’s an impressive lineup of speakers, including:

• Jeremy LaTrasse from Twitter, which encountered, and overcome, some significant scaling challenges
• Ian McFarland from Pivotal Labs, a contract development shop with deep experience in both Java and Rails
• Jason Hoffman from Joyent, which has perhaps more Rails hosting experience than any other company
• Bryan Cantrill, a Distinguished Engineer at Sun Microsystems

Tickets are $15 and include an open bar, which is quite a deal. The meeting starts at 6:30 at the City Club in downtown San Francisco. There’s a limited number of tickets available, so if you want to go you probably can’t wait until the last minute to sign up.

This is, incidentally, the inaugural event of GeekSessions, a new series of monthly meetings on web technology organized by Christian Perry, who also organizes the SF Beta events, and Shon Burton.

One of my sites was rebooted by the hosting company this weekend. The external monitor (site24×7) dutifully reported that it went down, and then that it was back up. Seeing that it had come back up, I relaxed.

However, in checking the logs last evening, I found that there were 503 errors occurring, and upon checking, some key site pages were down!

Why did my external monitor not detect this? I had it checking for keywords that were coming from the database, or so I thought.

It was a simple oversight. The page I was checking was cached! So although it appeared that the monitor was getting a page from Rails, I was really just getting a cached page from Apache, and Mongrel was dead.

Moral of the story: make sure your external monitors are not only checking for data that comes from the database, but also that they are hitting pages that are not cached.

One of the things that created a lot of early attention for Rails was the scaffolding, which makes it possible to create an instant admin interface for your database tables. While the built-in scaffolding was interesting two years ago, it clearly has received no attention from the core team, which doesn’t use it. It is really pretty horrible; for example:

• The standard CSS is really, really ugly
• It deals with only one table at a time and ignores associations
• It is hard to customize; generally, you end up just stripping it out and replacing it
• It doesn’t use any AJAX

There have been various attempts to build a better solution; the two best-known are Streamlined and Ajax Scaffold. The latter evolved into ActiveScaffold, which yesterday reached a big milestone: version 1.0 was released. I haven’t yet had a chance to deeply evaluate the two against each other, but one thing is clear: there’s no longer any reason to use the standard scaffolding.

Unlike many Rails plugins, ActiveScaffold actually has extensive documentation. I’m looking forward to being able to actually use scaffolding for admin functions now instead of having to build them from scratch. It’s great to be using a framework with such an active developer community that dives in and solves problems such as this one. And, of course, it’s all open source.

Web applications often need to send email to users for various reasons: forgotten passwords, reminders, announcements, and so forth. It’s easy enough to send mail with Rails—to get started, see How to Send Emails with Action Mailer.

I recently found, however, that mail from my applications was getting delivered to most, but not all, users. My two big problems were AOL users and companies that use a mail-filtering service called RedCondor.

Here’s the things I found to check. The lack of a reverse DNS entry turned out to be the source of my problems, but all of these items are important to check.

Reverse DNS

It’s important to make sure that your domain has a reverse DNS entry. This allows anyone to look up your domain name given your IP address. Some ISP, notably AOL, will not accept mail that comes from an IP address that lacks a reverse DNS entry.

To check the reverse DNS settings for your server, use a reverse DNS lookup tool, such as

• remote.12dt.com
• dnsstuff.com
• zoneedit.com

If the IP address of your mail server doesn’t have a reverse DNS entry, you’ll need to ask your hosting provider to register it. (Unlike the regular forward DNS settings, you can’t change the reverse DNS because the hosting company, not you, owns the IP address.)

The AOL Postmaster web site provides additional information about AOL’s mail delivery requirements, as well as a tool for checking the reverse DNS as seen by AOL.

SPF Records

You should also ensure that your regular (forward) DNS settings include a SPF (Sender Policy Framework) record. The SPF record is a text string that you add to your DNS settings to specify from what servers mail from your domain may be sent. This allows mail recipients to confirm that mail claiming to be from you really came from your mail server.

Open SPF’s SPF Setup Wizard will create your SPF string based on information you enter. You then need to add that string to the DNS for your domain as a TXT record.

Put a Valid Email in the Return Address Header

Make sure your email is sent with a valid reply address. You want to be sure that you’re getting bounce messages, and some mail systems check for a valid reply address before delivering the mail.

Avoid Text That Triggers Spam Filters

Assuming your mail passes all the formatting and DNS tests, it can still be blocked as spam by filters at the ISP or in the recipient’s mail client. So you need to be careful that your messages don’t look like spam. Avoid terms like “Free”, excessive use of exclamation points, and names of drugs for erectile dysfunction. (I don’t know what you do if you have a legitimate email you want to send about Viagra.)

Reconsider HTML Email

If you’re sending text-only mail or can live without the graphics, send plain text mail. Plain text mail is less likely to be interpreted as spam.

If you do everything else right, though, HTML mail does seem to get delivered. Be sure your HTML is valid, since some mail systems will reject invalid HTML as likely spam.

Check Your Mail Server Log

Just in case something is going wrong that you didn’t anticipate, check your mail server log periodically to make sure there aren’t any errors occurring. If you use a utility such as Logwatch that emails you the interesting bits of all the system logs once a day, it’s easy to stay on top of any problems.

Whitelists

Email deliverability is a surprisingly rich and complex topic. If you want the best possible deliverability, you need to deal with whitelists maintained by various ISP and mail providers, such as Gmail, AOL, and MSN Hotmail. There’s also companies that monitor email deliverability. For a small site, however, this effort is prohibitive and shouldn’t be necessary.

If you’re sending high-volume email newsletters, you’re almost surely better off using an established service, such as AWeber, Vertical Response, or Campaign Monitor, where there are people whose full-time job is ensuring that the mail gets delivered.

Other Resources

• How Geeks can Increase E-Mail Delivery
• How HTML Code Affects E-Mail Deliverability
• Email Deliverability Tips

What’s Been Your Experience?

If you’ve found other issues that are important to address to make sure mail generated by your web site gets delivered, please post a comment.

When I’m writing content for the web, I hate dealing with HTML coding. HTML is rather verbose as a markup language, and having to include closing tags is messy and error-prone.

We’re all pretty much stuck with delivering HTML code from our web sites, but that doesn’t mean we have to write in it. There’s any number of markup approaches that are superior to HTML when it comes to content creation, and which can be used as source code from which to create HTML. Two that are widely used are Textile and Markdown.

Textile was originally developed by Dean Allen for the TextPattern content management system and is now widely used in wikis and blogs. Markdown, created by John Gruber and Aaron Swartz, is an alternative that is conceptually similar but with a different syntax. The blog engine this blog uses, Mephisto, provides a choice of Textile or Markdown (or HTML) for posts and comments.

In this article, I’ll show the basics of Textile markup and how easy it is to use it in Rails applications.

What is Textile?

Textile strives to make text markup as clean and simple as possible. You don’t have to put <p> in front of each paragraph; bare text is automatically surrounded by <p> and </p> tags. To make a first-level heading, just start the line with h1. . For example:

h1. This is a heading and will be wrapped in <h1> and </h1> tags

This is a text paragraph and will be wrapped in <p> and </p> tags.

This is another paragraph.

And I bet you can guess how to make a second-level heading, or a third-level heading.

You never need to use close tags; a pair of carriage returns automatically triggers the appropriate end tag. Quotes are automatically converted to open and close quotes; hyphens are converted to n-dashes (if there is a space on either side); and double hyphens are converted to m-dashes.

To make text bold, surround it with asterisks; to make it italic, with underscores:

*This text will render in bold*
_This text will render in italic*
_*This text will render in bold italic*_

To add a link to a piece of text, surround the text in quotes, and follow it by a colon and the URL:

"text to be linked":http://thisistheurl.com

To include an image, type its URL surrounded by exclamation points:

!http://domain.com/path/to/image.jpg!

To create a bullet list, start each line with an asterisk and a space, like this:

* First item
* Second item
* Third item

Want a nested bullet list? Just indent the asterisk by three spaces.

There’s more, but this should give you a feel for it. You can also use any HTML you want for things that Textile doesn’t cover—HTML code is simply passed through. For more details, see the Textile Reference. You can try out Textile online at the Textile home page.

Implementing Textile

There are Textile implementations for various environments. In my case, using Ruby on Rails, Textile is implemented by whytheluckystiff ’s RedCloth gem. (The current implementation does have some flaws, and a much-enhanced version called Super RedCloth is in development.) To install, just enter the following in the console:

gem install RedCloth

With RedCloth installed, you create a new RedCloth object and pass some Textile-marked-up text to it:

textile_styled_text ="h1. This is an example of a heading in Textile" 
textile_object = RedCloth.new(textile_styled_text)

Then, when you want to render this as HTML, you simply use:

html = textile_object.to_html

Making Textile Even Easier

That’s pretty easy, but you can make it even easier. There’s a Rails helper “textilize,” but thanks to the acts_as_textiled plug from Chris Wanstrath, it’s even easier than that. Install this plugin:

ruby script/plugin install
 svn://errtheblog.com/svn/plugins/acts_as_textiled

And then all you have to do is declare a model attribute as Textile-formatted in your model class:

acts_as_textiled  :field_name

That’s it—everything just works! (Remember, though, that you need to restart the server for the model change to take effect.) Textile marked up text is stored in the database. Form fields automatically show unrendered textile. But any other use of the model attribute automatically delivers the rendered HTML instead of the Textile source.

Markup without Coding

You can also simplify the entry of Textile markup by using the textile_editor_helper from Dave Olsen and Chris Scharf. This plug-in renders a set of icons for the common markup tasks in your form view, just above the text entry area:

When you click an icon, JavaScript code inserts the appropriate markup into your text.

To use this, first install the plugin:

ruby script/plugin install
 http://svn.webtest.wvu.edu/repos/rails/plugins/textile_editor_helper

rake textile_editor_helper:install

And then replace the text_area tag in the form in which the user enters the Textile-formatted text with textile_editor:

<%= textile_editor 'object', 'field' -%>

textile_editor takes all the same options as text_area.

and at the end of the form add:

<%= textile_editor_initialize -%>

Finally, if you don’t already include prototype.js, you’ll need to add that to your layout:

<%= javascript_include_tag 'prototype.js' %>

Presto! Now you have a row of icons above the text area so your users don’t have to remember any markup at all. They’ll still see the markup in the text area (this is not a wysiwyg editor), which will help them learn the markup code.

During development, Rails deployment is simple—at least, once you have the development or staging server and your Capistrano scripts all configured. I have been using a single RailsMachine VPS served as the production server for two apps and the staging server for two others.

Before taking the medical site live, I wanted to have a more robust infrastructure in place, including separate staging and production servers. Even though the traffic level for this site will be very low by consumer site standards, it needs to have high uptime.

High Availability, High Complexity

Ideally, I’d have it running on a fully redundant cluster, with multiple front-end web and application servers and a clustered database server. This is a big investment, however, and is hard to justify for a small user base. The entry level for this kind of solution seems to be something like two “slices” from EngineYard, for about $600 a month (and really you need to add another $300/month so you have a slice for staging).

I considered implementing dual VPS servers, with DRBD and Heartbeat (two open-source high-availability software packages for Linux), so there would always be a hot backup ready in case the main server had a problem. At our current small scale, however, I concluded that this added too much complexity and not enough benefit.

The Simple Path to Increased Reliability

Instead, I’m taking a path recommended by Bradley Taylor at RailsMachine:

• Put each major application on its own VPS, so it isn’t affected by side effects from other applications.

• Use automated monitoring so I’ll know if memory usage starts creeping up, or a process dies, and can take immediate (and generally automated) action.

The “Resource Pool” Pricing Model

RailsMachine’s unusual pricing model is a good fit for this multiple-VPS approach. You pay for the resource pool you need: RAM, disk space, and bandwidth. The entry level is 256M RAM, 10G disk, and 100 GBytes/month, for $75/month. You can step up to 1G RAM and 25G disk for $200/month total; for another $50/month, you can have 2G RAM. (The RAM seems expensive, relative to RAM chip prices, because it is really being used as the proxy for the fraction of the machine you’re getting.)

You can then spread that resource pool among multiple servers for a small increase in cost. For another $10/month, you can spread your resource pool across two or three servers. If you get a bigger pool, you can spread it across up to 5 servers for $25/month extra or 10 servers for $50/month extra. So you could have 10 separate virtual servers, each with enough resources to run an app with a handful of mongrels, for around $350/month total.

Three Servers and Counting

We’re now running on three VPS servers at RailsMachine: one for staging (with multiple applications), one for our medical practice application, and another for this blog and some other small applications. The virtual servers are on different physical machines, so there’s some redundancy. I can, if necessary, press the staging server into duty as an emergency replacement for the production server.

So far, it seems like a good arrangement. Have you tried anything similar? Or something superior? I’ll be following this piece with a series of “lessons learned”. If you have some to share as well, please add a comment.

This week we went live with a medical office application (built in Rails) that I’ve been working on for a few months. It is focused on patient communications (not records) and is designed to replace lots of phone-message interactions that leave patients and staff frustrated.

The site handles requests for appointments, referrals, prescription refills, and records transfers, as well as payments. We are providing this as a hosted solution, initially for medical practices but quickly expanding to address other service businesses.

The live site is www.doyleparkfamilymedicine.com. Feel free to browse, but don’t fill in a request form unless you’re a patient there!

There’s a sizable admin site that is not, of course, publicly visible. This is where the staff processes the requests that patients submit on the site. It tracks the history of each request and sorts them into queues for the appropriate staff person.

If you know a service business that is interested in having a site like this, with a much smaller up-front cost than has previously been possible, please send them my way.

Capistrano is a wonderful tool for deploying Ruby on Rails (and other) applications. But having to enter your password over and over again for each step in a deployment gets old quickly.

In a previous article, I described how to set up SSH keys so you don’t have to enter your password for most operations. However, after the Capistrano deploy process does most of its work, it uses a sudo command to restart the application, and this requires you to type in your password. As a result, “cap deploy” is not a true “type the command and walk away” deployment process, even with SSH keys set up. You have to wait until the process is nearly done, so you can enter the password to restart the server.

A simple improvement is to enter:

cap deploy -p - 

The “-p” option tells Capistrano you want to provide a password, and the following hyphen tells it to prompt you for the password (which is more secure than entering the password on the command line). This way you can enter the password right at the start of the deployment process, and then it will complete without intervention.

I wanted to pass the name of a class to a web page, and then on that page I wanted to create an instance of that class. I can’t pass the class itself, since URL parameters are simply strings. So there must be a way to create the class given its name as a string, right?

I didn’t finding it browsing my books or using Google (because I couldn’t find quite the right thing to search for), but of course Dave Thomas knew the answer immediately.

Like most things in programming, and in Ruby in particular, it’s simple once you know how to do it:

Module.const_get('classname')

delivers the class object, so

Module.const_get('classname').new

creates a new instance of the class.

const_get produces the value of a constant, and because classes in Ruby are constants, the value of the name of a class is the class itself. (But you all knew this, right?)

If you want to render something using a helper inside a controller, render it using the inline option:

render :inline => "<%= any_ERb_here %>" 

For example, suppose you want to examine the contents of an object. You can do this easily in a view, if the object is accessible there, using the debug helper, which converts any object to YAML:

<%= debug object_to_be_examined %>

But because debug is a view helper, you can’t normally use it in a controller. You can, of course, pass the object as an instance variable and put a debug statement in a view, but sometimes it is more convenient to just insert this in your controller:

render :inline => "<%= debug object_to_be_examined %>" 

This works even if there is no view file at all that corresponds to the action in which you place this. If there is a render or redirect statement later in the action, however, you need to add “and return” after the inline render statement, or you’ll get an error message telling you that there can only be one render or redirect in an action.

Suppose you have a method in a controller that you want to use in a view. If you try to just invoke it as a helper, you’ll get a method not found error, because controller methods are out of scope for views.

You can, however, make any method available as a helper by simply declaring it as such in the controller:

helper_method :some_method_name, :another_method_name

The method must be in the same controller as the one that invoked the view.

One of the things that Ruby’s advocates find wonderful, and others often find scary, is its dynamic nature. You don’t declare the types of variables, and you can change them at will. Classes (even the base classes) are always open and new methods can be easily added, or existing ones overridden.

You can certainly get yourself into trouble by misusing these capabilities, but they eliminate a lot of unnecessary coding and increase the flexibility of your code. Ruby doesn’t protect you against yourself; it gives you the power and trusts that you’ll use it wisely. Java, at the other extreme, makes you go through hoops to protect you from yourself. Dave Thomas calls Java “the blunt scissors of programming languages.”

I am no expert on programming languages, I’ve never programmed in Java, and I’m uninterested in religious debates. But I do enjoy Ruby, and I have a lot of respect for the numerous programmers who say it has made them more productive—and that the fears that people coming from more structured languages have just aren’t justified. In reality, they say, things like mistakenly using a variable as the wrong type just don’t happen often, and protecting yourself from this isn’t worth all the declarations and rigidity that strict typing imposes.

If you haven’t used Ruby, you should take a look. ruby-lang.org is a great place to start.

If you’re a Java programmer, check out Bruce Tate’s From Java to Ruby.

Irrelevant side-note: If you google for “ruby benefits,” the top result is for a ruby gemstone necklace claimed to “correct any mental distortions regarding the meaning of love, particularly divine love. It also clarifies communication among your mind, memory, emotions, and body regarding divine love and its expression.” I guess they invested more in SEO than did ruby-lang.org.

I spent the earlier part of this week at Pragmatic’s Rails Studio, an intensive three-day Ruby on Rails training. This one was in Seattle; they are offered periodically at various locations around the country. (There’s not another one announced yet, but they’ll be posting a new schedule shortly; check their web site.)

Overall, I found this to be very worthwhile. It would have been a lot more valuable, however, if I could have gone a couple months ago, as I’ve spent the past two months building a couple small Rails sites, figuring things out as I went along. So a lot of it was review for me—something like 80% of the first day, 60% of the second day, and 50% of the third day. Nevertheless, it was very helpful in filling some gaps in my knowledge. I picked up quite a few tips, and perhaps most important, it gave me confidence that I’m on the right track and moving along pretty well. The presentations went well beyond the facts to explain the best way to approach things, why certain things in Rails work the way they do, and other useful bits of perspective that come from long experience.

World-Class Instruction

The instructors are Dave Thomas, the primary author of Agile Web Development with Rails and the proprietor of the Pragmatic Programmers publishing house, and Mike Clark, also an author and an active developer, and the head of Pragmatic Studio, a separate training company that shares part of the brand with Dave’s company. Both are outstanding instructors with deep expertise in the subjects covered. Chad Fowler was also there helping out, and he surely knows as much about Ruby as anyone in the U.S.

Dave Thomas

Mike Clark

The format of the Studio is an hour or two of lecture, followed by half an hour or so of programming on your own (you need to bring your own laptop). It’s an effective format, since you really don’t know if you understand something until you try to do it. Mike and Dave alternate speaking, providing different perspectives and variety in style.

The attendees were surprisingly diverse. There was certainly a local Seattle-area contingent, but there were also some who had traveled a long way. I went out to dinner one night and in our group there was one person from Alaska, one from Paris, and one from Mexico City. Some of the attendees were building Rails sites for their days jobs, while many were working in other technologies and seeking to move into Rails, either with their current employer, on their own, or with a new employer TBD.

Is This the Right Seminar for You?

If you’re looking for a jump-start in Rails development and are just getting started, I highly recommend the Rails Studio. If you’ve already done some Rails development, though, it’s a tougher call.

If you’re comfortable with the basics of the MVC separation, using migrations, creating and using associations, performing validation, and using views and layouts, this seminar will be mostly review. It covers the basics of AJAX with RJS templates and simple Scriptaculous effects, but nothing complex. One part that was most useful to me was the coverage of unit, functional, and integration tests, although the depth of coverage here too was necessarily limited.

If this Studio sounds like it would be mostly review for you, consider the Advanced Rails Studio (next offered in April in Dallas).

I’ll be adding a series of posts during the next couple days about some of the things I learned at the Studio.

When I deployed my first Rails site (other than this blog), I installed the exception notification plugin so I’d get an email if a user provoked a bug I hadn’t found. It’s a piece of cake to install:

1. Install the plugin

ruby script/plugin install exception_notification

2. Include the plugin in your ApplicationController (in the application.rb file)

include ExceptionNotifiable

3. Add one line to your environment.rb file to specify where to send the email

ExceptionNotifier.exception_recipients = %w(person1@domain.com person2@domain.com)

4. Make sure you have ActionMailer configured (to use either sendmail or STMP), which you’ll already have done if your app sends email for any purpose.

To test it, I added an action in my main controller that was guaranteed to create an exception, and it worked like a charm.

What’s this? Errors already?

A few minutes later, I checked my inbox and found a dozen error emails from the site! After a brief moment of panic, I realized that all were coming from search engine spiders, and that the URLs were all invalid. I had replaced an old, crufty, static HTML site, and the spiders were rechecking pages they had indexed in the past.

So the next question was what to do with the old URLs. I could remap each URL to the most appropriate page on the new site, but the old site got little traffic and there wasn’t a clear mapping between the two sets of pages, so it hardly seemed worth it. I decided to map index.html to the new home page, since many people might have bookmarked that page, and it was clear what it should map to. As for everything else, I wanted a way to tell the spiders to stop trying to index them, and to tell anyone who accessed them that this was no longer a valid URL and they should explore the new site.

The heart of the fix is to add a few lines to routes.rb. Fortunately, the old site design had put all the HTML pages except for the index page into a directory called html. There were also some PDF files, conveniently in a directory named web_pdfs.

Here’s the routes, which I added at the end just before the default route:

map.connect '/index.html', :controller => 'page', :action => 'home'
map.connect '/html/*any', :controller => 'page', :action => 'oldpage'
map.connect '/web_pdfs/*any', :controller => 'page', :action => 'oldpage'

I have a controller called page_controller that manages the public parts of the site. The first route simply maps index.html to the home page action.

The second route maps any URL in the html directory to a new page, which I called simply “oldpage”. The oldpage.rhtml file simply has some text telling the visitor that this page no longer exists, and gives them some suggestions for exploring the new site.

The “*any” in the route definition absorbs whatever comes after ”/html/”. With this technique, I don’t have to worry about whether there might be subdirectories within html, or what the file name extensions might be.

The final piece was to tell the spiders not to bother with these pages any more. I didn’t want to use a redirect, because the page to which I wanted to redirect the user wasn’t the new permanent page, but rather one that explained that the site had been changed. I decided to set the HTTP header to the “gone” status code (410). This just takes one line in the page controller oldpage action:

def oldpage
  render :template => 'page/oldpage', :status => :gone
end

I’m assuming the spiders will stop spidering these old pages, but since index.html will still lead to the new home page without any error code, they will find all the new pages from there.

So far, no more exception emails from the server. Time will tell how quickly the search engines update their indexes.

If anyone has any suggestions for superior solutions, please leave a comment.

My first built-from-scratch Ruby on Rails site is now live: www.newhorizonschool.info. This site is for New Horizon School and Learning Center, a wonderful small school that my son attends. They’re great folks, and they’ve made a big difference in our lives, so I was pleased to be able to help them out and build this site for them. And along the way, I learned a lot about building sites in Rails.

This is a pretty simple site, with mostly static content. Unlike your stereotypical Rails site, this is not a “Web 2.0” creation but just an old fashioned small business site. Nevertheless, I found the Rails environment to be very nice as a templating engine, and it made it easy to implement the small bits of database capability that are there:

• The Resources page is built from a database, so the staff can easily add links, categories, or descriptions through a web-based interface.

• The Alumni form adds records to a database. The staff will be able to download this to integrate into their Filemaker database.

• Contact messages are stored in a database, as well as being sent as emails to the administrator, so they are logged and can be reviewed by other folks.

• All the static text on the site is stored in a database, so the school’s staff can edit any of the text through a web interface. I considered using an existing content management system, but my needs were simple, and by building it from scratch I learned more and was able to make it do exactly what I wanted. The text is all stored in Textile. I hope to polish this up and release it as a plugin at some point.

Over time, I’ll be extending the site with some more sophisticated capabilities.

The banner was created by fellow parent Mario Zelaya. It sure adds a lot to the overall feeling of the site, especially compared to the solid-color box I had there!

I’d love to hear any feedback you have on the site. And if you want to help a great cause, just visit the Giving page and click on one of those Donate buttons at the bottom…

Since I wrote my piece on Ruby on Rails books, three more books have come out. Here’s my initial take on them.

The Rails Cookbook, by Rob Orsini, is a great collection of simple recipes for getting things done with Ruby on Rails. It starts off with the basics, including getting Rails installed on various platforms, and setting up your development environment. Then there’s sections on Active Record, Action Controller, and Action View, each of which starts with simple recipes for the basics (like defining your tables with migrations and using the Rails console) and moves on to more advanced topics (such as modeling a threaded forum with acts_as_nested_set). The book has been fully updated for Rails 1.2.

Following this core material, there’s sections on:

• RESTful development
• Rails application testing
• JavaScript and Ajax
• Action Mailer
• Debugging
• Security
• Performance
• Hosting and deployment
• Plugins
• Graphics

Each of the recipes is short—typically just a page or two. You won’t find in-depth tutorials here. But you will find clear, simple explanations of how to accomplish a wide variety of common tasks with Rails. The book covers not just the core rails application material, but also how to use additional tools and plugins (such as Httperf for performance measurement, memcached for improving access times, and Firefox extensions for debugging).

This is a great book to have by your side after you’ve been through one or two of the core books and are building your first real application. More experienced developers will know much of the material in this book, but they’ll also find it valuable when looking for a quick start using a feature they haven’t tackled yet.

While the Rails Cookbook is extremely broad and necessarily somewhat shallow, Ajax on Rails by Scott Raymond is narrow and deep. This book doesn’t try to cover Rails basics but focuses on using Ajax to create smoother user experiences for Rails applications. The first half of the book is a tutorial that starts with an explanation of what Ajax is, how it works under the covers, and how it is integrated into Rails. It then introduces the Prototype and script.aculo.us libraries and the use of RJS templates. Following this are sections on Ajax usability, testing and debugging, security, and performance.

The second half of the book provides a complete reference to the Prototype and script.aculo.us libraries and three example applications: a review quiz, a photo gallery, and a workgroup collaboration application. These complete examples (which you can download here) are very helpful to see how all the pieces come together to create a real application.

This is a book to get after you’ve been through a couple of the other books, built an application or two, and want to dive more deeply into using Ajax in your application.

Rails Solutions, subtitled Ruby on Rails Made Easy, lives up to its subtitle. Written by Justin Williams, this is an introductory book aimed at web designers, not experienced developers. If you have a software development background, you can skip this book. But if you’re a web designer who maybe has done a little PHP and wants to quickly understand what Rails is all about, this book is a good start.

This book is a much shorter, and easier, read than the classic introductory book, Agile Web Development with Rails, or the excellent Ruby for Rails it won’t take you nearly as far, but it is a quicker and gentler introduction. You’ll learn enough to build a simple Rails application, and then you can move on to the other books to deepen your knowledge.

The main competitor to this book is Beginning Ruby on Rails. That book provides somewhat more tutorial content about programming concepts, and therefore doesn’t move you quite as quickly through building an application.

Today marks a milestone for the Ruby on Rails community: version 1.2 (actually 1.2.1) has been released. For many months, developers who can get away with it have been using the “edge” version because of all the features that have been added since the release of 1.1.6, the last “stable” version, last August (and 1.1.6 had mostly minor changes from 1.1, which came out last March). Now that 1.2 is out, everyone has a stable version with the new features and gains some isolation from the daily evolution of the framework. For people running production sites, it no doubt feels a lot more comfortable being able to move to a new official release than using edge, so the new features are now much more usable for them.

It’s interesting to note how long a time “since last March” seems in the Rails world. In the shrink-wrapped software world, it wouldn’t even be nearly time for a new release, and little or nothing would be known about what was going to change.

For a good rundown of the key new features, see DHH’s blog post. For some more details on specific new features, see:

• New in Active Record
• New in Action Pack
• New in Active Support

RESTful Goodness

Support for RESTful routing is one of the central features of Rails 1.2. In essence, this comes down to two things:

1. Using the HTTP “verbs” of GET, POST, PUT, and DELETE to enable a single URL to perform multiple functions
2. Using the Rails “respond_to” method to enable a single action to respond to requests for HTML, JavaScript, XML, RSS, and so forth

If you’re wondering what the point of all this is, I highly recommend watching DHH’s keynote from the mid-2006 RailsConf. You can view the video at ScribeMedia, though the video is really only useful for the audio, since it doesn’t show the slides. To follow the talk, you need to be looking at the slides, which you can get here. The slides really need the audio to go along with them, so I’d suggest looking at the slides while listening to the audio from the video.

For a detailed example of implementing RESTful routes, you can buy Geoffrey Grosenbach’s PeepCode Screencast for a mere $9. It’s well worthwhile if you want a nitty-gritty example, though I found DHH’s talk better for appreciating the “why” of all this. Geoffrey also offers a free cheat sheet.

If you just want to peruse the code for a complete RESTful example, check out the RESTful Product Tracker code from Zack Chandler.

For a more general description of what REST is about (with a bit of a Java slant), see REST in Plain English.

Books Covering Rails 1.2

Many of the current Rails books were written for 1.1.6, but the second edition of Agile Web Development with Rails is fully 1.2-compliant. (If you’ve been getting by with the first edition, it’s time to upgrade.) Also just out is Rob Orsini’s Rails Cookbook, which Rob held up for a few weeks so he could update it for 1.2.

Prototype 1.5

Along with Rails 1.2, version 1.5 of the Prototype Javascript framework (which is included in Rails 1.2) was released, along with a new web site and better documentation to support it.

When I started working with Ruby on Rails a few months ago, being something of a book addict, I collected all the related books I could find. I even read substantial parts of many of them.

Here’s a quick rundown of the current landscape as I see it. Please post a comment to add your thoughts about any of these books.

There are several more books due in the first quarter of 2007, which I list at the end.

Agile Web Development with Rails, now in a brand-new second edition, is the essential book. After walking through basic Rails concepts and installation, the first third of the book describes a simple online store application (Depot). The discussion moves forward in logical steps and is a great introduction to Rails—as long as you’re already comfortable with Ruby basics. There’s a short intro to Ruby as an appendix, but if you’re new to Ruby, I recommend at least one Ruby book as a companion to this one.

This is the only major book available as I write this that is aligned with Rails 1.2, and it reflects recent changes in the preferred ways of doing things in Rails (such as RESTful routes).

The second section (the largest chunk of this book) is a systematic description of the Rails Framework. While the application-building walkthrough from the first part of the book is a great way to get a sense of how Rails applications are built, the second section provides a more thorough introduction and a much more useful reference. The book wraps up with a valuable section on securing and deploying applications.

In addition to being available as a bound book through all the usual places, you can buy it as a PDF download (or a download-plus-bound-book) from the publisher.

Ruby for Rails also walks through building an example Rails application, in this case an online music store. Unlike AWDWR, it starts with a great introduction to Ruby that explores the stylistic aspects as well as the mechanics. It doesn’t have the depth of material on Rails that AWDWR does, but it has a lot of very helpful material on Ruby that’s missing in the other book. And because it focuses on Ruby as used in Rails applications, I found it more helpful that the usual Ruby references (listed later in this article).

Once you have Rails basics down and are looking to do more, Rails Recipes provides a few dozen quick explanations of how to accomplish specific tasks, from “in-place editing” to “creating dynamic test fixtures”. Not a beginner book, but great for developers seeking quick solutions to more advanced problems.

Beginning Ruby on Rails E-Commerce is a useful, but misnamed, book. The example application that this book explores is indeed an e-commerce application (“the Emporium”), but what makes the book unique is its use of test-driven development (TDD). If you’re new to Rails, I recommend reading AWDWR first (since the TDD material adds yet another thing to grasp as you’re coming up to speed), and then following up with this book to explore TDD application development.

The slim Ruby on Rails: Up and Running is a very quick tour of building a photo sharing site. It’s a little steep as an introduction if you’re new to Rails but could be a quick start if you’re an experienced web developer and know some Ruby.

Beginning Ruby on Rails is the gentlest of the Rails books, assuming no programming knowledge and walking through Ruby and Rails in slow, well-explained steps. It could be a good first book if you find the top two books on this list to be tough going. But if you have some programming experience, you can skip this book. It describes the simplest ways to do things in Rails, not the best practices, so consider it as a first step only.

Ruby Books

These books are not Rails-focused, but to use Rails well you need a good grounding in the Ruby language. If your focus is on Rails, I’d recommend Ruby for Rails (listed above) first.

Programming Ruby, often called “The Pickaxe Book” because of the image on the cover, is the most widely used reference on the Ruby language. If you want a non-Rails-oriented introduction to Ruby, this is the book to start with.

The Ruby Way is a more advanced book than Programming Ruby and is a good follow-on if you want to learn more about the Ruby way of doing things after reading that book. The second edition was published in late 2006, so it is quite up-to-date.

The Ruby Cookbook follows in the mold of O’Reilly’s other cookbooks, providing quick solutions to common problems. Once you’re familiar with Ruby basics and want specifics on how to perform a wide variety of tasks, this book is a great resource.

But wait! There’s more!

Several Rails-related topics have been covered in e-books, which usually cost around $10 are are the length of a couple of typical book chapters:

• Rubyisms in Rails

• Rails Plugins: Extending Rails Beyond the Core

• Mongrel: Serving, Deploying, and Extending Your Ruby Applications

• Capistrano and the Rails Application Lifecycle

• RJS Templates for Rails

• Web Services on Rails

More to Come

And, of course, there’s lots more books in the pipeline:

Many English words have taken on new meanings in the digital world, often as product names. Since Google bases its search rank not on usage in traditional texts but only on usage on the web, it isn’t surprising that new meanings arrive much more quickly on Google than in dictionaries. Another interesting facet is the ads that appear, which of course typically reflect commercial interests. Here’s a few examples that I found amusing:

• Textile. Now this is a word that has been around a long time and is extremely widely used in commerce. Yet the first three results in Google refer to the somewhat obscure markup language. Over in the right column (the ads), of course, it is all about fabric.

• Mephisto. If you’re into great, though expensive, walking shoes, you probably know of the 40-year old, world-renowned Mephisto Shoes, and indeed shoe ads fill the right column. Mephisto Shoes does manage to keep first place in the Google search results. But right at number two is the site for the Mephisto blogging engine, the equally excellent (but much newer and less well known) blogging engine that this site runs on. Mephisto in the context of Mephistopheles, one of the chief demons of Christian mythology, doesn’t make the first page of results, other than in the context of the early 1980s movie of that name.

• Rails. Now here is a generic word with widespread usage and multiple meanings. Not too long ago the vast majority of associations would have had to do with railroad tracks. But 9 of the 10 results on Google’s first page refer to the three-year-old Ruby on Rails web framework (even when searching on the single word Rails). The ads are dominated by machine parts and bewildering ads like eBay’s “Rails: Whatever you’re looking for get it on eBay.”

• Mongrel. Surely there must be a million web pages about mongrel dogs. But result number one in Google’s list is the leading server for Ruby on Rails sites.

• Apple. Not until halfway down the second page of results do you get to anything about fruit. The savior is a page from Wikipedia, which I find is commonly the first site to appear in search results that reflects the more traditional meanings of a repurposed word. And no matter how many pages of listings you view, you won’t find any advertisements for fruit; no doubt this keyword has been bid far out of range for people selling things to eat.

I’ve succeeded in moving the blog over to Rails Machine. So far, it seems to be working great, with much faster page loads. I was seeing very erratic performance at Rails Playground, and it was down for more than 8 hours two nights ago. (Of course, it is one tenth the price of Rails Machine, so I wouldn’t expect the same level of performance.)

I’ve also upgraded to Mephisto 0.7.3.

This was my first experience deploying with Capistrano, and it took me a while to get everything right. All the automation Capistrano provides, especially with the railsmachine gem, is great—but for someone relatively new to the Rails world, it also adds another layer of stuff to figure out, and it obscures some of the details of what’s going on (which is a good thing when it all works, and not such a good thing when something goes wrong).

Last week I spent three days at the Rails Edge conference. This was a great event for learning about the latest developments in Ruby on Rails and meeting with some of the leading folks from that community.

This three-day event was produced by Pragmatic Studio, which is sort of a sister company to Pragmatic Bookshelf that publishes several of the key Rails books. The lead presenters at the conference were Dave Thomas, coauthor of Agile Web Development with Rails as well as Programming Ruby, and Mike Clark, who is the producer of the event, an active Rails developer, coauthor of Agile Web Development with Rails, and author of Pragmatic Project Automation and other Java books. Other presenters included:

• Chad Fowler, author of Rails Recipies, coauthor of Programming Ruby, cofounder of Ruby Central
• James Duncan Davidson, perhaps best known as the author of Tomcat and an expert on deploying Rails apps
• Justin Gehtland and Stuart Halloway of Relevance LLC, consultants who have been very active in the Rails community and have a lot of experience deploying enterprise applications
• Marcel Molina, Jr. from 37Signals, who is part of the Rails core team
• Bruce Williams, a designer/developer working on a very large Rails application
• Jim Weirich, author of the Rake utility and an expert in Ruby programming

If the people in this room couldn’t answer your questions on Ruby on Rails, you’d be hard pressed to find someone who could. With the unusual format of single-track, one-hour presentations separated by half-hour breaks, there was plenty of time to talk with the speakers and the roughly 100 participants. Some of the talks were entirely understandable by relative newbies such as myself, while others were clearly aimed at folks with substantial experience building Rails applications and programming in Ruby.

This event was a striking contrast to the previous week’s Web 2.0 Summit. This was obviously a much smaller and much more technical event, but what struck me was the center of interest: the Web 2.0 Summit was about, first and foremost, money, whereas the Rails Edge event was about ideas and craftsmanship. Both were interesting, but they’re about as different as two events could be.

In talking with folks in the evening and during the breaks; many of them seemed to fall into one of two camps:

• People actively developing with Rails as a corporate employee or as a consultant
• People who are using Java at their day job and building a web app with Rails at night, hoping to get to the point where they can quit their day job

More than once, speakers and participants pointed out that building a web application in Java as a spare-time activity wasn’t very likely; the fact that Rails makes it so much easier, and more fun, is encouraging and enabling a lot of niche applications to be built, often as hobbies that might someday create meaningful revenue. While the folks at the Web 2.0 Summit were more likely to be involved with heavily funded, well-staffed efforts going after big wins, the Rails Edge revealed a variety of small, enthusiast-created apps with more modest ambitions (like ShowerinaBox). I’d bet this latter source could be just as important to the future of the Web as the big efforts.

If you missed this event and wish that you hadn’t, there’s another chance: it will be repeated in Reston, VA on January 25-27. You can register here.

If you’re early in your Rails learning, then I’d recommend the Rails Studio instead; I’m planning to attend this on February 12-14 in Bellevue, Washington. It’s also being offered in January in Minneapolis.