Introduction / Overview\ SwitchPipe is a proof of concept "Web application server" developed in Ruby. More accurately, it's a Web application process manager and request dispatcher / proxy. Backend HTTP-speaking applications (Web applications) do not run directly within SwitchPipe, but are loaded into their own processes making SwitchPipe language and framework agnostic.\ SwitchPipe takes control of, and manages, the backend application processes, including loading and proxying to multiple instances of each application in a round-robin style configuration. As an administrator, you can define the maximum number of backend processes to run for each app, along with other settings so that you do not exceeded preferred resource limits. SwitchPipe quickly removes processes that "break" or otherwise outlive their welcome. For example, you can let SwitchPipe kill any backend processes that have not been accessed for, say, 20 seconds. This makes hosting many multiple Rails applications, for example, a quick and non-memory demanding process, ideal for shared hosting environments.\ ...\ SwitchPipe's goal is to be:I haven't spent much time with SwitchPipe yet, but if it lives up to Peter's claims this will dramatically simplify hosting Rails/Django/Camping/whatever applications.\ What's interesting to note is that this originated with Peter's [widely read article](http://www.rubyinside.com/no-true-mod_ruby-is-damaging-rubys-viability-on-the-web-693.html) on why such a thing was needed. Unlike a lot of other people who have complained loudly about the state of Rails on shared hosting environments, Peter put his time and talents towards creating a solution which he then released within 3 weeks. This is definitely something we need more of.\ So what are your thoughts? Is this the solution we've been waiting for?
* super easy to configure
* the easiest way to deploy multiple HTTP-talking backend applications
* painless in terms of management; no hand-holding of different applications is needed
* a permanent daemon that can handle configuration changes in backend apps “on the fly”
* a reliable solution on Linux and OS/X (and anything POSIX compatible, ideally)
Initial performance numbers would seem to indicate that Ruby 1.9 (due by Christmas) will be lots faster.
If you spend a lot of time in IRB (most of us probably do), it’s worth taking the time to learn how to customize it. This is a good start.
Nice clean library to generate fake data. The home page says it’s a port of Perl’s Data::Faker library, which I’d never even heard of.
A plugin to do OpenID authentication in Rails, in a RESTful way.
Ok, this is a bonus link. Not at all Rails related, but relevent to you if you’re reading this. Rands nails the Nerd. I mean, really nails it.
A new book from O’Reilly on troubleshooting Ruby (and Rails) apps. From the overview:
This short cut introduces key system diagnostic tools to Ruby developers creating and deploying web applications. When programmers develop a Ruby application they commonly experience complex problems which require some understanding of the underlying operating system to be solved. Difficult to diagnose, these problems can make the difference between a project’s failure or success. This short cut demonstrates how to leverage system tools available on Mac OS X, Linux, Solaris, BSD or any other Unix flavor. You will learn how to leverage the raw power of tools such as lsof, strace or gdb to resolve problems that are difficult to diagnose with the standard Ruby development tools. You will also find concrete examples that illustrate how these tools solve real-life problems in Ruby development. This expertise will prove especially relevant during the deployment phase of your application. In this way, should your production Mongrel cluster freeze and stop serving HTTP requests, it will not take you 2 days to figure out why!
A nice, if a bit short, article on some of the changes that are coming in Rails 2.0. This is focused on what you will need to change in your application.
This is a beginner tutorial, specific to using Netbeans 6.0. I’ve not played much with the Rails support in Netbeans, but it looks impressive so far.
Jeremy Kemper recently committed a request profiler to Rails. It lets you make a request to a URL repeatedly, and then see an HTML or text report of where your code is spending it’s time. This looks very handy.
A walkthrough of building an app with Rails, which includes feature definition, using Piston to manage plugins, and Restful Authentication. Nice.
The Halloween Edition
One of the first tutorials I’ve seen that focuses on Rails 2.0.
This would seem to make deploying a Rails app on Amazon’s EC2 very simple:
EC2 on Rails is an Ubuntu Linux server image for Amazon’s EC2 hosting service that’s ready to run a standard Ruby on Rails application with little or no customization. It’s a Ruby on Rails virtual appliance. If you have an EC2 account and a public keypair you’re five minutes away from deploying your Rails app.
A collection of Rails links
I’ve only skimmed over the new features in the upcoming 2.0 release of Rails, but this looks like one of the nicest features. This is a good explanation of how it works and why it’s useful.
A bugfix release of Mongrel is out. Looks like 1.1 is due soon, and it looks interesting:
“Mongrel 1.1 is coming real soon now with JRuby support and a few other things.”
Being a bit of an Emacs junky, I’m not sure how I missed this. Looks mature, and very functional, and almost TextMate-like. The link has a nice flash video of Emacs on Rails in action.
Sitepoint’s book “Build Your Own Ruby on Rails Web Applications” is now free, at least for the next month. I’ve only skimmed it, but it looks like a decent introduction, and the price is certainly right.
Update: I somehow managed to misspell Relevance’s name. Fixed.
I’m missing RailsConf this year (I have no excuse, I live two hours away). I’m living vicariously through the other attendees though, keeping an eye on the blog posts.
One announcement that I just caught was that Relevance has announced Streamlined, which is a framework on top of the Rails framework. Some of the interesting features include (pulled from Justing Gehtland’s post):
- Generator for churning out the initial views and configuration
- A declarative DSL for managing views, including relationship management, field selection, etc.
- Full Ajax-enabled management views with sorting, paging and live search (with configurable field-inclusion)
- An extensible component system for representing relationships at runtime * REST-ful web service layer around all models
- Auto user-management and inclusion of declarative role-based authorization
It looks like this gives you a really good jumpstart on building data driven applications (as if Rails wasn’t enough of a jumpstart). The management views in particular sound nice (Django has this already, really the only thing Django has over Rails as far as I can tell).
They’re planning on realeasing this at OSCON in July. I’m looking forward to it.
A few links that caught my eye today:
- Nice article if you’re a DB2 user and want to know what the fuss is about. Written by Edd Dumbill.
Sapphire in Steel: The Little Book of Ruby - Nice introduction to Ruby with plenty of code samples, in PDF form.
Ruby Cookbook - The Perl Cookbook, ported to Ruby.
- Now you can find out what all of those neat settings in config/environments/* are.
It’s interesting that both frameworks were extracted from large development projects in roughly the same time period, although Rails has been publicly available for longer, and has more mindshare at the moment.
I’m happy with Rails, but I wonder whether I would have bothered with it if Django had been available when I started looking at Rails. The thing that kept me away from Rails for a long time was that I didn’t know Ruby. I was (and still am) well-versed in Python. I still prefer the cleaner syntax of Python over Ruby, although the latter does have some features that I find compelling.
I wonder about the impact of one aspect of Django though: the fact that the model generates your databas schema, instead of the developer generating the model from the schema (which is the Rails model). I suspect most DBA’s would go into convulsions at the very thought of this. I can certainly see how it would ease moving from database to database.