There are a couple of reasons that you may want to do this. One is to be master of your universe. I really like this and will be moving Clubrs to use that.

You may also find a gem that your web host doesn’t have installed. You can ask them to install it, and they might, but you can also use it without their intervention. Here’s all you have to do:

1. Install the Gem on your own system
2. Open a command window in [RAILS_HOME]/vendor
3. Type ‘gem unpack gem_name’ to expand the gem

4. UPDATE: Use the path to the lib folder in your require, e.g.:

   require ‘units/lib/units’

That’s it. Now your app will have access to the gem as normal. Also, if there’s an installed version of the gem, your app will use your expanded gem rather than the installed gem.

The Rails team put in a nice, related feature with the 1.0 release candidates. There’s a Rake target to ‘freeze’ rails to a particular version:

rake freeze_rails

That will give you all the core Rails gems unpacked to

vendor/rails

To reverse you can use

rake unfreeze_rails

Which simply deletes the /vender/rails directory.

So the Google Web Accelerator is back and twice as lethal as before….

More interesting for most applications, especially those already requiring Javascript to do Ajax, is the addition of :post => true to link_to.
This will add a onclick attribute on the ahref, which generates a
dynamic, invisible form that again turns the GET into a POST.

How Rails is prepared for GWA II: Vengeance (Loud Thinking)

It’s nice to use a framework that handles the issue at all, let alone with a couple of elegant solutions. If you have any links (href=) in your app that alter the state of your database (deletes, especially) be sure to read up on this.

Rails makes doing the right things easy and the wrong things a bit more difficult. One of those right things is testing, and the Rails 1.0 release candidate has a new set of defaults and a couple new goodies to help your tests go faster. And when tests go faster, they tend to get run more often.

Mike Clark’s Weblog

If you have any tests that are failing after upgrading, this may be why. It’s a nice article covering not only what has changed, but why.

I’m trying the new browser, Flock, with a built-in blogger. To set it up for typo, follow their instructions to add a blog. (Tools -> Options -> Blogging) I found that I had to enter a URL that failed (try the rss feed of your blog). When Flock complains, click Cancel. Then you get to the screen where you can enter your info (I couldn’t figure out how to get there more easily):

XML-RPC API: Moveable Type
Blog ID: Whatever you want to call it
Access Point: http://yourdomain.com/backend/xmlrpc

That should get you started. Then click the feather icon in the toolbar of Flock to get the window. It looks pretty promising (I had to post this to try it out). Click the ‘TOPBAR’ button to get a list of your posts. There’s a sort of well that says ‘Drag stuff here to blog it!’. I need to try that next…

To download Flock, you need to go here:

Log in here:
http://www.flock.com/developer/download/preview/
  username: caveat
  password: emptor

This is a great broadcast from the Burton Group. The interviewer, Richard Monson-Haefel, quoted below, is the author of several excellent books on Java, including Enterprise JavaBeans.

The teleconference begins with an overview, first of Ruby, then Rails. Here’s the snippet I just loved:

(Ruby is) generally what I would consider to be a step up in the evolution of programming languages. Compared to Java and C# in terms of the capabilities and the level of abstraction it provides you.

It’s been a great 3 days here at RubyConf. I’m a little wiped out, but here are a variety of notes, mainly on the Rails end of things.

There’s been a ton of info on Ruby, from the arcane to the really, really arcane. The conference is more than twice as big as last year, which seems to be largely due to RoR. There were many of us who hadn’t attended before and were there this year as a result of using Rails. There was mention in DHH’s morning talk of a possible RailsConf, but that sounds pretty speculative at this point. There was also some talk about having a Rails track at RubyConf and so not breaking it off.

The Rails core team has been working all weekend on the last touches for a 1.0 RC. Below are the notes on what’s new. The release may have a number like 14.0 or 13.2 or such so that RubyGems will pick up the change for the final 1.0 release. The main area they need to work on for final release is the database connectors for closed source databases.

Here are some misc. notes from this afternoon’s talk by DHH on Rails 1.0.

1. db/schema.rb
Can round trip
dbschemadump
dbschemaimport
to maintain database. Use along with migrations. If you don’t use constraints (indexes are supported) can manage a ‘very agile database’ this way.

2. Rails::Initializer
Mainly will help to update your app to new versions of Rails. Will no longer have to run ‘rails’ against your application. Substantial changes to environment.rb and others.

3. Better FCGI spinner, spawner, reaper – also better fcgi_handler (same as noted in my fastcgi guide). The bad news: ‘dynamically allocated FastCGI Processes are Evil’. – David Heinemeier Hansson when I asked about them. That’s what DreamHost uses, along with many other shared web hosts. So it doesn’t look good for FastCGI without some workarounds.

What was suggested as the best solution for shared hosts was using TextDrive’s setup. They use a proxy http server to forward requests to the user’s own instance of http server which then has its own processes and can manage them with the spawner/reaper tools. Maybe we can get DreamHost to look into the setup involved.

4. SwitchTower automated deployments to clusters including restarting processes as needed. Can even deploy into production ‘in prime time if your code is solid’. Won’t disrupt in-progress requests.

5. Plugins Use directory under /vendor: /vendor/plugins/acts_as_taggable/lib

• the lib directory will be added to the path, so in models can easily access the plugin
• if you use an ‘init.rb’ (at same level as /lib dir) that will get run at startup time – so you could extend activerecord, for example
• should be simple – use a components for more involved needs

6) Prototype 1.5, Script.aculo.us 1.5

• Some new stuff: count iterators (example was to show unread threads in an rss reader). New slider.

7) Speed

• about 2x speed over 0.13.1 - without changing app
• more with changes to ruby/application: can change garbage collector, etc – diminishing returns, unlikely to be needed by most

Binding gems and edge You can bind your rails app to the rails gems you have installed. They will be expanded into /vendor for you. This only binds the Rails gems – if you use others you’ll need to tend to those yourself.

This is particularly useful on shared hosting accounts where they may change the version of some gem that breaks your app.

rake freeze_gems
rake unfreeze_gems

Unfreeze simply removes the directory from under /vendor and your back on the local gems. Very handy.

9) Per Action Session Management Can turn off sessions on a per action basis.

session :off, :only => :feed

Would turn off sessions for the feed action. This was big for basecamp/backpack to reduce sessions that were getting spawned for feed aggregators that were hitting every 15 minutes. There are switches besides ‘:off’ and there are a number of other options, e.g. only for web services.

Another very cool Rails addition from Jamis Buck and the 37signals gang.

http://jamis.jamisbuck.org/articles/2005/10/11/plugging-into-rails

This looks like a really slick way to handle code modules without users having to do any config to use your module. Just bundle it up and drop it in (edge rails’ new) vendor/plugins directory and off you go.

My background is as a web developer and I’ve used most every technology out there. (Really: PHP and Perl, sure, Cold Fusion is ok, but I built quite a large (long gone) community in it’s more obscure cousin Lasso. I always liked WebSiphon quite a bit. If you like pain, give IBM’s Net.Data a go. It certainly wins for nastiest scripting language as a big corporate attempt to glom something together to wire DB2 to the web.)

But now I’m coming to Ruby and Rails from Java, which I’ve used since about 2000. I took a few courses, read a few books and really threw myself into it. I thought when I started that it would be the one I could hang my hat on. OOP looked like the way to go, having gone through a whole lot of huge, contorted code bases.

That’s why I’m a little surprised that one of the most enjoyable and surprising things I’m learning these days is… Object Oriented Programming.

It seems that as you go down the J2EE highway, you find yourself using more and more patterns and creating more and more objects that delegate to other objects. The concept of data + methods is just ripped to hell. We hardly have more than an ejbcreate method on any of our entity beans. And we have thousands of entity beans.

It was in this context that I wrote this post, which said, in part:

Model: only persistence and associations

I got some feedback on the bleak outlook such a decision would have on design. I thought about it and realized that really what I want is a much more robust domain model. Objects that can do things, objects that are not persisted, objects with collaborations. It was such a relief. It may still be that I use mixins to solve the customization for clients issue, but likely they will be mixed in to the model somewhere.

I now move forward by extracting anything from my controllers that could live in the model. I’m doing some CRC cards to find the gaps in my model and flesh it out a bit.

It may be 2000 all over again (when Java looked so promising) but Ruby and Rails sure seems to be a good fit, at least to me. I get a really nice language with just enough of what I need to create full featured web apps without getting to the point of complexity where everything needs to be factored out to flatness.