Filed under: Design, Developer, Internet, Windows, Macintosh, Linux, Web services, Open Source, Unix
Maypole: Agile web development for the rest of us
by Jay Savage Feb 14th 2007
If you've been anywhere except under a rock for the last 18 months or so, you're probably sick to death of the phrase "Web 2.0," and for many people, Web 2.0 has become almost synonymous with Ruby on Rails. Ruby on Rails, though, has some major drawbacks for the average web designer. Ruby, while gaining steam, is still not as popular as more established programming languages. There aren't as many programmers who know it as there are who know, say, Perl, Java, ASP or PHP. So developing RoR applications means investing time and money in training yourself or your team in a new language. That may be a minor hurdle, but Rails offers more serious barriers to adoption. First, it expects to run its own webserver, which will conflict with your main webserver listening on port 80. It can be made to use an existing Apache or IIS server, but the configuration is not simple. Even when running on an existing server, it expects to run as a separate application in a mod_ruby environment. While that makes RoR applications very efficient (like mod_perl applications before them), it also means that using Ruby on Rails requires control over you servers. That's great if you manage your own hardware and internet connection, but most people don't. The majority of websites, even those owned by medium to large-sized businesses, are hosted with web hosting companies where individual users don't have dedicated equipment or access to server configurations. Even at my workplace, where we do most things in house, my department web space is just a small part of a server infrastructure maintained by a completely different network and server administration department. Adding my Rails applications to the forward-facing servers isn't in the cards.
Enter Maypole.
Maypole is a rapid web application development framework written in Perl by Simon Cozens and maintained by Aaron James Trevena and others. It will run anywhere there is Perl, which is most of the world's webservers, and provides a powerful environment for "agile web development," including database abstraction and the powerful and popular Template::Toolkit templating system. Best of all, it is platform agnostic. It can run under either mod_perl or as CGI, an will check for itself to see which environment it is running in. That means You can start using it today on your Dreamhost (in fact, I have a Maypole application running on one right now) account, and pick it up tomorrow and move it someplace else without hassle.
The Maypole site has some good introductions and links to some great articles, as well as the Maypole Perl module itself. As with any Perl project, though, the best way to get it is to install it directly from CPAN and read the perldocs.
Reader Comments (Page 1 of 1)
james said 8:08PM on 2-14-2007
Jay Savage you moron, if you are going to spread FUD you should at least employ facts. It looks like your critical analysis of Rails dates back to 2005. Nobody uses mod_ruby. Rails doesn't require it's own server, but the best approach to scaling Rails is to deploy it behind a front end server as that gives you load balancing, the ability to serve static content fast and you can add more back end servers as needed. That is not a complex environment. Apache 2.2 and nginx can do that out of the box and otherwise you just add pound or another load balancer. Nobody in their right minds would deploy Rails (anything) on IIS. Please do more than cursory research if you are going to knock something.
Reply
DrWatson said 7:46AM on 2-15-2007
You are not trying to say that learning Perl is easier to a PHP or Java (or C#, or VB) developer, are you?
Choosing the platform for your application should not be based on what your hosting service provides, unless you're just trying out some language. The reality is that you have to choose a viable technology and then choose the hosting service that can deliver it. Hosting is so frivolous these days, if you want to use RoR, just shop for another hoster and move along.
Reply
daggerquill said 9:28AM on 2-15-2007
No, Perl probably isn't easier for a Java programmer. For other languages, I'd say it's a tossup. But that's not really the point.
Agile web development doesn't have to mean Rails. There are other alternatives, and I've pointed out one of them.
I've also pointed out some of the reasons why I think, if you're looking at trying something new, you might want to consider all your options instead of simply following the hype.
And if you're an experienced Rails developer, you should go back and see what the default installation looks like, as well as the popular tools like locamotive. Rails can run anywhere, it's true, with a lot of tweaking, but your comments are way off base. Every tutorial starts out with three assumptions: 1) you're going to run a test server using the built-in httpd (or lighttpd) on a local host; 2) you're going to try to manage three separate databases in various stages of development, and 3) you're going to run your application as a stand alone application, not CGI. Configuring your environment differently is not straightforward, even though the assumptions are only valid for a small subset of development environments.
"Just shop for another host" is fine if you're an amateur programmer putting up a photo gallery, or even a small, flexible company.
In the environment most of the world operates in, though, the infrastructure decisions are not made by the people writing the code. We have to adpt to the environment, not the other way around.
But again, that's not really the point. The point is that there are options.
Reply
Garth said 11:42AM on 2-15-2007
I was a huge fan of Ruby on Rails, but I had a hard time getting into it. My background was originally in PHP and I had a hard time distinguishing the Ruby from the Rails as I was learning. I later found CakePHP ( http://www.cakephp.org ). I am sure it is a lot like Maypole, but it is PHP based, and getting a life of its own now. I would recommend it as I prefer PHP to other server side languages.
Reply
Garth said 11:56AM on 2-15-2007
I prefer CakePHP - similar but PHP based.
Reply
Garth Braithwaite said 11:58AM on 2-15-2007
Sorry if you are interested in the looking at CakePHP you can find it at http://cakephp.org . There is also a IRC channel on freenode #cakephp. Pretty tight community and lots of support when needed.
Reply
Ian said 3:50AM on 2-16-2007
"Rails offers more serious barriers to adoption. First, it expects to run its own webserver, which will conflict with your main webserver listening on port 80. It can be made to use an existing Apache or IIS server, but the configuration is not simple. Even when running on an existing server, it expects to run as a separate application in a mod_ruby environment."
Actually this isn't correct. By default Rails has always run its own server on port 3000, which has not conflicted with port 80. It can be set to use port 80 if you so wish, but the Rails built-in web host (webrick) is only intended for development purposes.
On a deployed "production" site, you've also got it very wrong. Rails does not run within a mod_ruby environment. The typical way of deploying Rails applications is to use the Mongrel server (mongrel.rubyforge.org) via the mongrel_cluster package. This configures a user-controlled number of 'mongrel' servers that listen on a series of ports bound to the loopback address (e.g. 127.0.0.1:8000-8004 for 4 nodes). These speak the HTTP protocol allowing them to be very simply proxied by an Apache server using the "Proxy balancer" feature of the mod_proxy module built into Apache 2.
Yes, Rails used to be very tricky to configure with all number of deployment options, such as Apache+mod_ruby, lighttpd, fastcgi and so on, but with Mongrel the situation is much, much simpler.
In other words, to run Rails, all you need is an Apache 2 server with the Ruby 1.8.5 interpreter on it and the Mongrel Gems, and access to setting up a mod_proxy load balancer as a virtual host on port 80 (one config file). All other Ruby Gems including Rails itself can be bundled within your application distribution (within vendor/) and then updating your site is a simple 'cap deploy' from your development box using the Capistrano system for Rails. Automatic checkout of your latest tested code from your code repository, direct upload to the site, automatic server restart and the potential to rollback over the last 5 to 15 versions of the site are all done with one command. Simple. You can even deploy to new load balancing clusters with a simple one-shot command that even reconfigures Apache for you.
As for not having a dedicated server, or at least a virtual server, these days the prices are so low that it does not make sense to use a shared server appliance. If you shop around it's very easy to find a large number of hosting providers that give you full access to configuring the server properly. After all, if you're using Rails (pretty bleeding edge tech anyway) you should have the technical know-how to deploy it.
I suggest you take another look at Rails as you seem to be a bit out of touch with the current state of affairs.
Reply
Jay Savage said 1:24PM on 2-16-2007
Ian,
You're right about mongrel, but it's hardly a typical situation for most people. Notice I don't say most Rails developers, I say most people. For the average Webmaster, setting up a mod_ruby app is unlikely. setting up mogrel servers running isn't even a possibility.
And as for capistrano...it's great. If you are the server admin as well as the webmaster. But a script that updates your Apache configs doesn't do you any good if you don't manage your Apache configs.
You lost 99.99% of people who might be interested in trying out rails at "access to setting up a mod_proxy load balancer as a virtual host."
You shouldn't have to have the thechnical know-how to configure a server to deploy an application. More importantly, as i said in the post, in most corporate environments, the people who would be working on the Ruby app don't have the access. It's a policy issue, not a technical issue. And dedicated hosting really isn't cost effective for many people. No matter how cheap it is, shared hardware will always be cheaper. and if it meets most of your needs other than RoR support....
I'm not knocking RoR, here. I have several RoR applications running on local servers behind or corporate firewall.
But it's not the only game in town, and there are some valid reasons to look elsewhere.
Reply
Ram said 1:03PM on 2-28-2007
the Rails quote "favouring Conention over configuration" applies only as long as you are developing the app not when it comes to deploying it. i built a CakePHP app and all i had to do to run it on my production server was to upload it through FTP, where as i could never get my rails app running due to many reasons
the more conditions you have for it to work, the lesser the adoption
earlier there were very few or no rails like frameworks but it has changed now
Reply