« March 2006 | Main | May 2006 »
A few weeks back, Eric Knapp posted a long message which I feel nicely sums up the difference Rails makes. It isn’t an issue of Rails being substantially different to the alternatives. It’s more that the lowered barriers to entry enable a broader base of people to benefit.
Anyway, with Eric’s permission, here’s the body of his post. It was titled
This past Friday I had a meeting with a client who is the director of educational research and IT at a medium sized public school district. I’m sure that you are all aware that school districts are under intense pressure to cut their budgets and expenses. My client can no longer replace any IT employee when someone leaves. They are down to one network administrator (!) and two programmers. Their programmers are just maintaining an old legacy system and really don’t do any new development anymore. New development is done by student interns from my Java program at my college. My students really struggle with all kinds of limits that are set by the district’s policies, procedures, and equipment.
My client has also been struggling with how to move to the future. He is under lots of pressure to cut even more deeply. There are those within the district who want to end all development of new things and only use off-the-shelf applications, as-is, with no customization.
My client is not an IT person and he knows nothing about programming. But, he is a very smart man and is very perceptive. My meeting started with an overview of his current development efforts with my students. Then I started sharing rails with him. I like rails and I tend to be enthusiastic. About ten minutes into my presentation he interrupted me and said, "So, this could save my IT department, couldn’t it?"
I was really taken off guard by this! I simply answered, "Yes." He took over our meeting and started talking about all the things that he and his people would like to do, but just can’t afford. He talked about all the ideas that are shared with him by his staff and teachers that also are just too expensive. My interns have started to help him and we have worked very hard at trying to bring Java to his department. But, they are just too slow, everything takes too long to be viable anymore. I believe that we are now going to give up on Java.
We now have scheduled a kick-off meeting for maybe bringing Ruby on Rails to this school district. Later he told me that this has given him a little bit of hope. I might be able to have good geek fun while helping children at the same time.
This is exciting stuff! Rails appears to have reached some sort of critical mass of productivity where ideas that live in the hearts and minds of most people have a chance of getting out and onto the screen. I’m starting to ask students and friends what those ideas are. I am getting really interesting answers.
I hope I’m not making too much of this, there is still lots of work to be done and we will have to get grants to do it. But, there are possibilities now where there weren’t any. There is a little bit of hope. Sounds good to me. Many thanks to the rails community and to this group for helping me get to this point.
Unfortunately, it came out E Pluribus Anum.
Which may well be the official motto for the wisdom of crowds…
One attempted fix, however, seems to have backfired. Many folks who aren’t developers use the Typo blog, normally hosted on an ISP such as Textdrive or Dreamhost. When those ISPs upgraded to 1.1, a change in the way Rails handles loading its environment broke Typo, and all the blogs stopped working. In a well intentioned (if somewhat hasty) reponse, Rails was modified in 1.1.1 to record its version when you first create an application. It then uses RubyGems to ensure that the application continues to use that version of Rails. Of course this only applies to new applications, so it doesn’t fix the Typo issue, but longer term it will allow applications to continue to run when new releases introduce incompatibilities.
However, this change has brought with it an unfortunate side effect. Now, when you run script/generate for controllers, and models, you’ll see a warning:
./script/../config/../config/environment.rb:8: warning: already
initialized constant RAILS_GEM_VERSION
This is apparently benign, so the advice from Rails core is to live with it until 1.1.2.
Mike Clark and James Duncan Davidson will we running a studio dedicated to putting Rails applications into production. There’s a clear need for this—there are many, many options when it comes to deploying a Rails applications, and the landscape changes constantly. Mike and JDD are experts at this: they’ve deployed both large and small Rails applications. In fact, I trusted them so much that they’re managing the deployment of the next big Pragmatic Programmer site.
These studios tend to sell out: the Portland Rails Studio filled up last week, the Boston studio is well on its way, and since Mike announced the Production Studio on Sunday he’s been flooded with e-mail. If you’re looking for the best advice on how to get your Rails application into production, I’d get on the list now.
And if you’re looking for advanced Rails training, well… we may have an announcement for you shortly.
