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