Comatose CMS for Ruby on Rails

Anyone who has built a Rails app and wanted to use a CMS just for the static portions of the site knows that there is no easy solution, especially when the CMS and Rails app need to share things like user logins. This issue is well-described by Aaron Longwell in his June ‘09 blog post, The Ruby on Rails CMS Dilemma.

I started playing with different Ruby on Rails CMS offerings to learn more and try to come up with some new approaches. One really interesting little project popped up called Comatose CMS, initially developed by cartoonist/programmer Matt McCray. Comatose has a couple of sweet features I feel like every CMS should have:

• Comatose runs as a loosely-coupled plugin to your Rails app (as opposed to being the base upon which you need to layer your app). If you want Comatose to generate a page, you just route the request to Comatose with some entries in your routes.rb file. If you want your app to handle the request, route it normally. Simple!

• Comatose pages can be rendered inline similar to Rails partials. Imagine you have an entire app already built and you need a quick way to allow someone to edit specific chunks of content without moving entire pages into your CMS. Comatose inline rendering could have you there literally in minutes.

• Comatose can use the same layouts as your regular app.

• Comatose uses a simple callback pattern to use your app’s authentication and access control as its own. You can configure Comatose to mix-in any modules it needs (like the restful-authentication lib), then set up callback procs to control access to both the generated pages and the back-end editing interface.

I guess the main drawback to Comatose is that the original author has not worked on it recently and the two or three other committers have not made any changes in nearly a year. It does work with the latest Rails 2.x though. With more activity you might see better documentation, more examples and design patterns, maybe a few new features. Also, with a project this inactive, one worries that there are security flaws, performance issues, or other difficulties yet to be discovered. Unless I find another CMS with similar features, I’m thinking of giving it a go in a real project and seeing what I run into.

 

Here are a few Comatose CMS tips:

 

By arranging your routes in different ways, you can have Comatose handle everything, only specific pages, or any page not otherwise explicitly routed. I prefer that last style — just use resource maps and named routes for everything in your app, remove the default :controller/:action/:id routes, and add something like map.comatose_root "" at the end. For example:

map.resources :users
map.resource :profile
map.comatose_admin
map.comatose_root '', :layout => 'application'

A request for anything except /users or /profile will fall through to the CMS. If the CMS cannot find the request page it will render it’s own “404 not found” page (which you define by creating a page called “404″ at the top level of your page heirarchy).

 

---

 

Comatose routes can be used like named routes in the app. For example, one might link to an /about page with comatose_root_path(:about). Sub-pages in the heirarchy can be accessed one of two ways, with an array of strings or symbols, or a string argument to the helper: comatose_root_path([:legal, :privacy]), or comatose_root_path('legal/privacy').

 

---

 

If you don’t like the look of comatose_root_path(:about) and comatose_root_url(:about) as helpers, you can make a shorter route such as:

map.static ':page', :controller => 'comatose', :action => 'show'

Then use static_path(:about) and static_url(:about) instead. The only drawback to this approach is that sub-pages will end up with ‘%2F’ (the entity for ‘/’) in your browser’s address bar.

To cause errors to be generated instead of 404 pages (maybe useful for debugging during development?) you could limit the possible values for :page as follows:

map.static ':page', :controller => 'comatose', :action => 'show', :page => /about|help|contact|legal\/privacy|legal\/terms/

 

---

 

For Comatose to use your app’s layouts, any helpers or modules used by the layout need to be included in the Comatose controller since it doesn’t inherit ApplicationController. This is easily configured in environment.rb:

Comatose.configure do |config|
config.helpers << :layout_helper    # my layout helpers
config.includes << :current_user  # my module that includes a current_user method

 

---

 

Finally, here’s some code for a layout that provides an “Edit this page” link for anyone who is logged in as an administrator:

<% if current_user && current_user.is_admin? && @page && @page.is_a?(Comatose::PageWrapper) %>
<%= link_to("Edit this page", "/comatose_admin/edit/#{@page['id']}") %>
<% end %>

Notice that @page is defined in the layout when Comatose is handling a page. It contains all sorts of useful information to take advantage of in your layout.

Climate scientists their own worst enemies

Just read this article in the Washington Post: Whose war on science? by Michael Gerson, 12/11/2009. I was all set to get ticked off by another anti-science article but after carefully parsing what he was saying, I think Gerson has made a very valid point. The recent flap over the hacked emails of climate scientists has done more to hurt their cause than the climate change skeptics they oppose.

What I wish I had seen more of in the article is consideration of how these scientists ended up where they are. These are people who truly believe that the earth is in the process of being catastrophically changed and that it may already be too late to reverse the damage; is it really surprising that they would call people who are still questioning the science and delaying progress “idiots”? I think we can spot them a few political maneuvers and fudged figures, but that doesn’t change the fact that they have hurt their own cause by blending science with the world of politics and public opinion.

media obsession

The online news has been reporting frenetically on what Sarah Palin is up to every day. I noticed a bunch of headlines trumpeting that “hundreds of people show up for Palin book signing in Ohio”. Wow, hundreds? Really? The last time J.K. Rowling did a book reading it had to be held in a sports arena… I guess that puts things in a little perspective. The public doesn’t really care that much, but the media is obsessed with polarizing figures. I guess suggesting that Sarah Palin is about to take over the universe gets people to read articles more than coverage of the umpteenth hour of boring health care debate that could save our country from financial ruin.

free subversion hosting

I have been trying out different Subversion hosting services lately, including ProjectLocker, Unfuddle, and XP-Dev. Here’s a quick critique.

ProjectLocker

ProjectLocker offers the most service for each price level by a wide margin. Even free accounts include 500 gigs, 5 users, unlimited repositories, unlimited bandwidth, and SSL access. Extremely generous compared to their competition. To some extent they are just a thin wrapper on top of Subversion, Git, and Trac but I consider that a good thing–I don’t really need my fancy XP/Agile tracking and collaboration tools on the same web site as my source control–I have things like PivotalTracker and Rally for that. Their site looks slightly clunky and old-school (like a pre-Web 2.0 site that got a quickie Arial Rounded makeover) but it works well and gets the job done.

My only gripe with ProjectLocker is the frequency and duration of their scheduled maintenance outages. Your mileage may vary, but I’ve only been using them about three months and already had my repositories offline for extended periods twice–they just finished a 42-hour scheduled maintenance (which is why I’m wasting time blogging instead of working), and about a month ago they did an 18-hour maintenance. I have no idea what they could be doing in all that time–in 42 hours you could build new servers from the ground up starting with nothing but a credit card, a TigerDirect catalog, and FedEx. If I had a $30/month account with them, this would be a real deal-breaker. As a free user I have to admit I’m getting an amazingly sweet deal though.

XP-Dev

I don’t have a lot of experience using XP-Dev. I started a project there and five minutes later there appeared to be an unplanned outage and I couldn’t get to my repository. To their credit, it was fixed minutes after I informed them but my partner on that project decided to move the repo to another provider rather than risk any more downtime. XP-Dev has a pretty slick site with nice, simple tools. Subversion, Trac, nice integration features (Basecamp, FogBugz, Lighthouse, Twitter, etc.), collaboration tools (wiki, blogs, forums), and some basic XP/Agile project support–I guess the project tracking and collaboration are useful if you are doing them both on the site and already spending time there–might as well get it all done in one place. Feature-rich and reasonable pricing structures. I get the distinct impression XP-Dev is a tiny 1- or 2-person organization, which isn’t necessarily bad, but isn’t very comforting either. Despite this, I hope to try them out again soon and see how their reliability fares, at least anecdotally.

Unfuddle

Unfuddle is the third Subversion hosting service I have tried recently. So far so good in terms of reliability. Their pricing scheme seem a little stingy on the disk space side — free accounts get 200MB of space and only 1 project, and $99/month gets you only 10GB of space and 50 projects. Of course, very few people using a hosted solution actually need more than 10 gigs and 50 projects, but I wouldn’t describe it as “enterprise” space. The site is slick and pleasant to use. I haven’t had the chance to try out the site tools much yet–they have some relatively simple milestone-based project tracking, messages and “notebooks”, and a nice dashboard feature that lets you know various things that are going on with the project.

Conclusion?

The problem with the value-added features of all of these sites is that they don’t seem robust enough to convert me from just opening a browser tab to a more fully-featured alternatives. For example, I’m really liking PivotalTracker for project tracking — full-featured Agile support with a super-slick, interactive interface that keeps things simple and saves time.

I don’t have a clear winner yet, but I have definitely concluded that reliability and uptime (whether scheduled or unscheduled) are the most important features–everything else is pointless if I’m trying to get work done and can’t get into my repository.

Real Americans, real funny

A couple of young liberal guys ask basic, non-leading political questions at a Sarah Palin book signing in Ohio, and respondents are their own worst enemies. Funny as all get-out.

To be fair, I suspect if you did the same thing at some liberal event you would get similar results, except maybe not with quite as much blatant racism.

 

workaround for “Malformed version number string mswin32″

People are reporting the error “Malformed version number string mswin32″ when unpacking or using unpacked Ruby gems in their Rails project. I ended up figuring this out because I ran into it while trying to unpack the sqlite3-ruby gem and couldn’t Google any fixes.

Here’s the quick workaround (hack):

1. Look at your unpacked gems in vendor/gems and find any directories ending in “-x86-mswin32″. Change the directory name by removing “-x86-mswin32″.

2. Inside that same directory, there should be a file name “.specification”. Open that file with your text editor, find the line “platform: x86-win32″ and simply remove the “x86-win32″ so it just says “platform: “.

3. Your project should now load. But read on…

When gems are unpacked, they are placed in vendor/gems with directory names that include the gem name and version separated by dashes. e.g.: mechanize-0.9.3. As unpacked gems are loaded, Rails uses these directory names to get the version number of the gem. Comments in the Rails code lead me to believe that this is legacy support for older gems that preceded the use of .specification files. (I’m using Rails 2.3.4, the specific code is [rubydir]\lib\ruby\gems\1.8\gems\rails-2.3.4\lib\rails\vendor_gem_source_index.rb, lines 103 – 106, method version_for_dir).

When the gem is platform-specific, however, then the directory name is supposed to contain the platform name separated by a dash (per the GEM::Specification class). Since the gem loading code is looking for a version number at the end of the directory name and is instead finding a platform name, this results in the error “Malformed version number string mswin32″. (It should say “malformed version string x86-mswin32″ but since this particular platform name contains a dash, which is the delimiter, it only picks up the last bit.)

This seems to be a Rails bug since different parts of the code are expecting different things at the end of the directory name, not to mention that gem names and platforms both commonly contain dashes which are the delimiter the code is using to find the version number.

After figuring this out I realized this begs the question: why am I unpacking a platform-specific gem when I develop on Windows and deploy to Linux? D’oh! So here’s the real tip — don’t unpack platform-specific gems kids. And remember to use hand sanitizer this Winter.

Hosting your app on GoDaddy from the site root

A quick tip for those who are hosting a Rails app (or any app really) on GoDaddy or other shared hosting sites where the app ends up being hosted from a subdirectory, e.g. http://www.mysite.com/my_app/ instead of just http://www.mysite.com.

If you only have one application and want it to be hosted from your root URL, edit your top-level .htaccess file (where you see default GoDaddy files like welcome.html and missing.html) and add something like the following:

# EDIT: added first line so GoDaddy web stats won't break!
# if the requested URL doesn't start with /stats/ or /my_app/
# then add /my_app/ to the beginning
RewriteCond %{REQUEST_URI} !^/stats/.*
RewriteCond %{REQUEST_URI} !^/my_app/.*
RewriteRule ^(.*)$ /my_app/$1


If you are using Rails, you can now get rid of the relative_url_root configuration (usually in environment.rb or production.rb), so links will be generated like /images/mypic.jpg instead of /my_app/images/mypic.jpg (although both should work fine).

This probably works on other Apache-based shared hosting providers as well. I haven’t road-tested this solution completely but it’s very basic Apache stuff so there shouldn’t be any problems.

EDIT: Here’s an even better tip for those who are thinking of hosting a Rails app on GoDaddy shared hosting… don’t do it! Unless you just need a cheap site for sharing prototypes. You can get decent VPS hosting for $15/month these days–there’s no reason to have a slow site running on outdated Apache & FastCGI versions that mysteriously crashes about one out of ten page views just to save $7 a month. In GoDaddy’s defense, shared hosting is a fail concept of bygone days now that VPS technology has become so widespread and inexpensive–there’s nothing particularly wrong with their service that a few version updates wouldnt fix.

Facebooker doesn’t play nice with relative_url_root

If you are using the Facebooker plugin to host your Facebook app with Ruby on Rails, be aware that it modifies ActionController::Base.relative_url_root and will break Rails sites that are not hosted at the root URL of their domain (e.g., http://www.mysite.com/my_rails_app).

It’s more than likely I’m just not configuring the plugin correctly and need to go back over the docs and tutorials but it seems a little weird that this plugin just arbitrarily overrides relative_url_root. Maybe the designers were thinking you wouldn’t typically host your Facebook app and your normal web site from the same application.

Once I figure out the workaround or what I’m doing wrong, I will post the answer here (unless someone beats me to it, I dare ya!) but in the meantime I just wanted to send out that warning so others won’t have to waste several hours figuring out modifying the relative_url_root seemed to be doing nothing.

 

In praise of Slicehost

I’ve been using Slicehost for some personal projects and prototype sites for about a year and, at the risk of sounding like I’m getting paid to pimp their service–which I absolutely am not, I gotta say I just love ‘em! I just moved a major web site from a 2GB dedicated server to a 512MB virtual slice (and it’s handling requests even faster than before after porting from Apache to Nginx + Phusion Passenger).

What’s so good about Slicehost?

• Sign up for a server, put in a credit card, you can be logging in with SSH and setting things up literally within a few minutes. Server provisioning is completely automatic, fast, and you can choose from a wide variety of Linux distros.

• $20/month for an entry-level slice with 256MB memory, suitable for running most small web sites. Not the cheapest, but for what you get it’s quite a bargain.

• Their servers have generally been rock-solid for me, and the one time they weren’t (I believe the server my slice was on had a drive controller meltdown) I was only down a few hours, was kept up-to-date on their progress via email, and was given a free month to make up for it. The only other downtime has been for short overnight maintenance periods and I’ve given notice far in advance via email.

• Slicehost management tools are a delight to use. Simple, logical, functional. I upgraded a slice from their 256MB entry-level to a 512MB setup: it was completely automatic, my server was only down for about 2 minutes, and it worked like a charm. I wanted my site’s reverse DNS to reflect my domain name instead of Slicehost’s–it was just a few clicks away.

• Slicehost’s community site has some of the best articles available on setting up Ruby on Rails & Django servers. I’ve actually used their articles when setting things up on other people’s servers. Sometimes the articles on a software package are even better than the help from the package’s own help pages.

• Active community and great attitudes. These folks really mean it when they say built by developers, for developers, despite being bought out by hosting heavyweight Rackspace. I love their SLA:

Most hosting SLA agreements are just plain silly. They promise things like 99.9% uptime, but downtime excludes: scheduled maintenance, network outages, hardware failures and software trouble. Well what exactly is left to cause downtime? Here’s our SLA: we’ll do our best to keep your machines running smoothly for as long as possible and get them up ASAP should something go wrong.

• Need more? Private IPs for slice-to-slice networking, referral bonuses, API access to management tools, free DNS hosting, and bandwidth pooling across slices.

One minor con is that they don’t have configurable hardware firewalls or custom hardware options. My $100 dedicated server at Hostway came with a hardware firewall that gave me an extra level of comfort. With everyone moving to cloud services these days, I guess only old-timers like me still think a hardware firewall or load-balancer might be useful.

Convert Windows/DOS line breaks to Unix/Linux

Here’s a quick tip for converting a text file with Windows-style line breaks to Linux-style breaks.

I had a few Windows text files that needed converting so I Googled for a quick answer. The first bunch of results suggested things like downloading freeware programs or using Linux text editors to open and re-save the file. I figured there has to be a much more Unix-style, drama-free way to accomplish a trivial task such as removing a few excess ASCII 13 characters. Well here it is:

sed 's/[[:cntrl:]]$//' mywindowsfile.txt > mylinuxfile.txt

In English, replace any control character (carraige return is ASCII 13, also known as Ctrl-M) that is the last character in a line with an empty string. Technically the carraige return is the second-to-last character but the terminating linefeed is not considered part of the line itself.