June 21, 2011: In Brightest Day

I’d like to pretend there was some thread connecting these things, but you and I both know there just isn’t…

1. Actual News: Cucumber 1.0

Starting with something approaching a real news story, Cucumber 1.0 was released today. According to that post from Aslak Hellesøy, the project has had nearly 750,000 downloads. Oh, and there’s a native JavaScript port in progress. I didn’t know that.

Anyway, Cucumber 1.0 adds Rake 1.9.2 support. Recent changes you may not know about include a -l and --lines command line switch as in RSpec’s and a new transform syntax that allows you to factor out duplicated parts of step definitions. Haven’t seen official docs on this, but it looks like it allows you to capture bits of step definition and run a block against it. The code example within the Cucumber tests looks like this:

Transform(/a Person aged (\d+)/) do |age|
 Person.new(age.to_i)

end

Given /^(a Person aged \d+) with blonde hair$/ do |person|
puts “#{person} and I have blonde hair”
end

In other words, the snippet a Person aged \d+ is captured and transformed and the result of that transform block is what is passed to the step definition block.

Interesting. I wonder if people will use it?

2. The End of the World As We Know It

This post from the Armed and Dangerous blog tries to imagine a world without the web. The general idea is that if Congress had understood what DARPA was up to in the early 80′s, then funding would have been cut, and TCP/IP would not have been developed and popularized.

It’s an interesting argument, and as much as I’d like to believe it’s to dark, the examples of the cable and cell phone industries are eloquent. (I’ll grant that the author is probably trying to make a libertarian point I wouldn’t agree with in general…)

3. Books: Fuzzy Nation

Continuing playing catch-up with brief book reviews, Fuzzy Nation by John Scalzi. Fuzzy Nation is something odd — a genuine remake of a beloved SF classic (well, beloved by some, I’ve never read it), namely Little Fuzzy by H. Beam Piper. Scalzi has taken the basic elements — a guy who encounters small, sentient aliens who are, wait for it, Fuzzy — and wound his own story around them.

Fuzzy Nation is pretty much purely entertaining, fun, well structured, fast paced. It’s not as much interested in the existential questions around alien intelligence as the practical question of protecting them from a corporation that wants to strip-mine their planet. (Subtle, it’s not.) It’s one of those books that isn’t interested in re-defining the genre as much as telling a good story inside the existing boundaries.

4. Moving Beyond Thin Controllers To The Downright Emaciated

Gary Bernhardt over at the Destroy All Software blog posts some suggestions about using routing or routing-like structures to effectively remove controllers from the system. The theory is that if controllers just exist to dispatch to a specific method someplace else in the system, and Rails manages all the other connections, then why not route directly to that method with some declarative or rules-based logic to handle things like security logic, exceptional conditions, or other high-level logic.

It’s interesting, and probably could be built within Rails 3. I suspect most systems aren’t pure enough in the controllers to take advantage of it, which I guess is the point, and I wonder if the gain is worth breaking the default linkage between URL and controller/action pairs, but I’d be curious to try it.

5. In Brightest Day, In Blackest Night

Finally, I haven’t seen the Green Lantern movie yet, but I’ve been telling anybody who will listen that I’ve been waiting 30 years to be disappointed by it. Thanks to io9 for reminding me why be recapping an awesomely over-the-top Green Lantern comic from 1980 that I owned, loved, and could still quote alongside the recap. Watch GL stagger through the Arctic wilderness without his ring set upon by polar bears and wolves.

Filed under: Alternate History, Books, Comics, Cucumber, Rails 3

What’s Up With All These Changes in Rails?

Yesterday, there was a blog post entitled “What the Hell is Happening to Rails” that stayed at the number one spot on Hacker News for quite a while. The post and many (but not most) the comments on the post reflect deep-seated concern about the recent direction of Rails. Others have addressed the core question about change in the framework, but I’d like to address questions about specific changes that came up in the post and comments.

The intent of this post is not to nitpick the specific arguments that were made, or to address the larger question of how much change is appropriate in the framework, but rather to provide some background on some of the changes that have been made since Rails 2.3 and to explain why we made them.

Block Helpers

I too get a feeling of “change for the sake of change” from Rails at times. That’s obviously not something they’re doing, as all the changes have some motivation, but at times it feels a bit like churn.
At one point in time, you did forms like <%= form …. and then they switched to <% form …. do and now they’ve switched back to <%= form … do again.
Also, the upgrade to Rails 3 is not an easy one. Yeah, you get some nice stuff, but because it’s so painful, it’s not happening for a lot of people, which is causing more problems.

Prior to Rails 3.0, Rails never used <= form_for because it was technically very difficult to make it work. I wrote a post about it in Summer 2009 that walked through the technical problems. The short version is that every ERB template is compiled into a Ruby method, and reliably converting &lt%= with blocks proved to be extremely complicated.

However, knowing when to use <% and when to use <= caused major issues for new developers, and it was a major 3.0 priority to make this work. In addition, because of the backwards compatibility issue, we went to extreme Ruby-exploiting lengths to enable deprecation warnings about the change, so that we could fix the issue for new apps, but also not break old apps.

The night José and I figured out how to do this (the Engine Yard party at Mountain West RubyConf 2009), we were pretty close to coming to the conclusion that it couldn’t be done short of using a full language parser in ERB, which should give you some sense of how vexing a problem it was for us.

Performance

The general disregard for improving performance, inherited from Ruby, is also something endemic from a while back.

Yes, there have been some performance regressions in Rails 3.0. However, the idea that the Rails core team doesn’t care about performance, and neither does the Ruby team doesn’t pass the smell test.

Aaron Patterson, the newest core team member, worked full time for almost a year to get the new ActiveRecord backend into decent performance shape. Totally new code often comes with some performance regressions, and the changes to ActiveRecord were important and a long-time coming. Many of us didn’t see the magnitude of the initial problem until it was too late for 3.0, but we take the problem extremely seriously.

Ruby core (“MRI”) itself has sunk an enormous amount of time into performance improvements in Ruby 1.9, going so far as to completely rewrite the core VM from scratch. This resulted in significant performance improvements, and the Ruby team continues to work on improvements to performance and to core systems like the garbage collector.

The Ruby C API poses some long-term problems for the upper-bound of Ruby performance improvements, but the JRuby and Rubinius projects are showing how you can use Ruby C extensions inside a state-of-the-art virtual machine. Indeed, the JRuby and Rubinius projects show that the Ruby community both cares about, and is willing to invest significant energy into improving the performance of Ruby.

Heroku and the Asset Pipeline

The assets pipeline feels horrible, it’s really slow. I upgraded to Rails 3.1rc, realized it fights with Heroku unless upgrading to the Cedar stack

The problem with Heroku is that the default Gemfile that comes with Rails 3.1 currently requires a JavaScript runtime to boot, even in production. This is clearly wrong and will be fixed posthaste. Requiring Rails apps to have node or a compiled v8 in production is an unacceptable burden.

On the flip side, the execjs gem, which manages compiling CoffeeScript (and more importantly minifying your JavaScript), is actually a pretty smart piece of work. It turns out that both Mac OSX and Windows ship with usable JavaScript binaries, so in development, most Rails users will already have a JavaScript library ready to use.

It’s worth noting that a JavaScript engine is needed to run “uglify.js”, the most popular and most effective JavaScript minifier. It is best practice to minify your JavaScript before deployment, so you can feel free to format and comment your code as you like without effecting the payload. You can learn more about minification in this excellent post by Steve Souders from a few years back. Rails adding minification by default is an unambiguous improvement in the workflow of Rails applications, because it makes it easy (almost invisible) to do something that everyone should be doing, but which has previously been something of a pain.

Again, making node a dependency in production is clearly wrong, and will be removed before the final release.

Change for Change’s Sake

The problem with Rails is not the pace of change so much as the wild changes of direction it takes, sometimes introducing serious performance degradations into official releases. Sometimes it’s hard to see a guiding core philosophy other than the fact they want to be on the shiny edge

When Rails shipped, it came with a number of defaults:

  • ActiveRecord
  • Test::Unit
  • ERB
  • Prototype

Since 2004, alternatives to all of those options have been created, and in many cases (Rspec, jQuery, Haml) have become somewhat popular. Rails 3.0 made no changes to the defaults, despite much clamoring for a change from Prototype to jQuery. Rails 3.1 changed to jQuery only when it became overwhelmingly clear that jQuery was the de facto standard on the web.

As someone who has sat in on many discussions about changing defaults, I can tell you that defaults in Rails are not changed lightly, and certainly not “to be on the shiny edge.” In fact, I think that Rails is more conservative than most would expect in changing defaults.

Right, but the problem is that there doesn’t seem to be a ‘right’ way, That’s the problem.

We were all prototype a few years ago, now it jquery … we (well I) hadn’t heard of coffeescript till a few months ago and now its a default option in rails, The way we were constructing ActiveRecord finders had been set all through Rails 2, now we’ve changed it, the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.

I like change, I like staying on the cutting edge of web technologies, but I don’t want to learn something, only to discard it and re-do it completely to bring it up to date with a new way of doing things all the time.

First, jQuery has become the de facto standard on the web. As I said earlier, Rails resisted making this change in 3.0, despite a lot of popular demand, and the change to jQuery is actually an example of the stability of Rails’ default choices over time, rather than the opposite.

Changes to gem handling evolved as the Rails community evolved to use gems more. In Rails 1, all extensions were implemented as plugins that got pulled out of svn and dumped into your project. This didn’t allow for versioning or dependencies, so Rails 2 introduced first-class support for Rails plugins as gems.

During the Rails 2 series, Rails added a dependency on Rack, which caused serious problems when Rails was used with other gems that rely on Rack, due to the way that raw Rubygems handles dependency activation. Because Rails 3 uses gem dependencies more extensively, we spent a year building bundler, which adds per-application dependency resolution to Rubygems. This was simply the natural evolution of the way that Rails has used dependencies over time.

The addition of CoffeeScript is interesting, because it’s a pretty young technology, but it’s also not really different from shipping a new template handler. When you create a new Rails app, the JavaScript file is a regular JS file, and the asset compilation and dependency support does not require CoffeeScript. Shipping CoffeeScript is basically like shipping Builder: should you want it, it’s there for you. Since we want to support minification out of the box anyway, CoffeeScript doesn’t add any new requirements. And since it’s just there in the default Gemfile, as opposed to included in Rails proper like Builder, turning it off (if you really want to) is as simple as removing a line in your Gemfile. Nothing scary here.

ActiveRecord Changes

The way we were constructing ActiveRecord finders had been set all through Rails 2, now we’ve changed it

The Rails core team does seem to treat the project as if it’s a personal playground

One of the biggest problems with ActiveRecord was the way it internally used Strings to represent queries. This meant that changes to queries often required gsubing String to make simple changes. Internally, it was a mess, and it expressed itself in the public API in how conditions were generated, and more importantly how named scopes were created.

One goal of the improvements in Rails 3 was to get rid of the ad-hoc query generation in Rails 2 and replace it with something better. ActiveRelation, this library, was literally multiple years in the making, and a large amount of the energy in the Rails 3.0 process was spent on integrating ActiveRelation.

From a user-facing perspective, we wanted to unify all of the different ways that queries were made. This means that scopes, class methods, and one-time-use queries all use the same API. As in the <= case, a significant amount of effort was spent on backwards compatibility with Rails 2.3. In fact, we decided to hold onto support for the old API as least as long as Rails 3.2, in order to soften the community transition to the new API.

In general, we were quite careful about backwards compatibility in Rails 3.0, and while a project as complex as Rails was not going to be perfect in this regard, characterizing the way we handled this as “irresponsible” or “playground” disregards the tremendous amount of work and gymnastics that the core team and community contributors put into supporting Rails 2.3 APIs across the entire codebase when changes were made.

Bundler: As Simple as What You Did Before

One thing we hear a lot by people who start to use bundler is that the workflow is more complicated than it used to be when they first start. Here’s one (anonymized) example: “Trying out Bundler to package my gems. Still of the opinion its over-complicating a relatively simple concept, I just want to install gems.”

Bundler has a lot of advanced features, and it’s definitely possible to model fairly complex workflows. However, we designed the simple case to be extremely simple, and to usually be even less work than what you did before. The problem often comes when trying to handle a slightly off-the-path problem, and using a much more complex solution than you need to. This can make *everything* much more complicated than it needs to be.

In this post, I’ll walk through the bundler happy path, and show some design decisions we made to keep things moving as smoothly as before, but with far fewer snags and problems than the approach you were using before. I should be clear that there are probably bugs in some cases when using a number of advanced features together, and we should fix those bugs. However, they don’t reflect core design decisions of bundler.

In the Beginning

When you create a Rails application for the first time, the Rails installer creates a Gemfile for you. You’ll note that you don’t actually have to run bundle install before starting the Rails server.

$ gem install rails
Successfully installed activesupport-3.0.0
Successfully installed builder-2.1.2
Successfully installed i18n-0.4.1
Successfully installed activemodel-3.0.0
Successfully installed rack-1.2.1
Successfully installed rack-test-0.5.6
Successfully installed rack-mount-0.6.13
Successfully installed tzinfo-0.3.23
Successfully installed abstract-1.0.0
Successfully installed erubis-2.6.6
Successfully installed actionpack-3.0.0
Successfully installed arel-1.0.1
Successfully installed activerecord-3.0.0
Successfully installed activeresource-3.0.0
Successfully installed mime-types-1.16
Successfully installed polyglot-0.3.1
Successfully installed treetop-1.4.8
Successfully installed mail-2.2.6.1
Successfully installed actionmailer-3.0.0
Successfully installed thor-0.14.2
Successfully installed railties-3.0.0
Successfully installed rails-3.0.0
22 gems installed
$ rails s
=> Booting WEBrick
=> Rails 3.0.0 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2010-09-30 12:25:51] INFO  WEBrick 1.3.1
[2010-09-30 12:25:51] INFO  ruby 1.9.2 (2010-08-18) [x86_64-darwin10.4.0]
[2010-09-30 12:25:51] INFO  WEBrick::HTTPServer#start: pid=26380 port=3000

If you take a look at your directory, you’ll see that Bundler noticed that you didn’t yet have a Gemfile.lock, saw that you had all the gems that you needed already in your system, and created a Gemfile.lock for you. If you didn’t have a necessary gem, the Rails server would error out. For instance, if you were missing Erubis, you’d get Could not find RubyGem erubis (~> 2.6.6). In this case, you’d run bundle install to install the gems.

As you can see, while bundler is providing some added features for you. If you take your application to a new development or production machine with the Gemfile.lock, you will always use exactly the same gems. Additionally, bundler will resolve all your dependencies at once, completely eliminating the problem exemplified by this thread on the Rails core mailing list. But you didn’t have to run bundle install or any bundle command unless you were missing some needed gems. This makes the core experience of bundler the same as “I just want to install gems”, while adding some new benefits.

Adding Gems

When you add a gem that is already installed on your system, you just add it to the Gemfile and start the server. Bundler will automatically pick it up and add it to the Gemfile.lock. Here again, you don’t need to run bundle install. To install the gem you added, you can run bundle install or you can even just use gem install to install the missing gems.

Once again, while bundler is handling a lot for you behind the scenes (ensuring compatibility of gems, tracking dependencies across machines), if you have all the gems that you need (and specified in your Gemfile) already installed on your system, no additional commands are required. If you don’t, a simple bundle install will get you up to date.

Deployment

After developing your application, you will probably need to deploy it. With bundler, if you are deploying your application with capistrano, you just add require "bundler/capistrano" to your deploy.rb. This will automatically install the gems in your Gemfile, using deployment-friendly settings. That’s it!

Before bundler, you had two options:

  • Most commonly, “make sure that all the gems I need are on the remote system”. This could involve including the gem install in the capistrano task, or even sshing into the remote system to install the needed gems. This solution would work, but would often leave no trail about what exactly happened. This was especially problematic for applications with a lot of dependencies, or applications with sporadic maintenance
  • Using the GemInstaller gem, which allowed you to list the gems you were using, and then ran gem install on each of the gems. Heroku used a similar approach, with a .gems manifest. While this solved the problem of top-level dependencies, it did not lock in dependencies of dependencies. This caused extremely common problems with rack and activesupport, and a long tail of other issues. One particularly egregious example is DreamHost, which directs users to use a brittle patch to Rails

In both of these cases, there was no guarantee that the gems you were using in development (including dependencies of dependencies like Rack and Active Support) remained the same after a deploy. One recent example that I saw was that carrierwave added an updated dependency on the newest activesupport, which depends on Ruby 1.8.7. Without making any change to his .gems manifest, Heroku failed to deploy his application on their Ruby 1.8.6 stack.

With bundler, this sort of problem can never happen, because you’re always running exactly the same versions of third-party code in production as you are in development and staging. This should increase your confidence in deployments, especially when you come back to an application months after it was originally developed.

Tweaked Gems

Some times, you will need to make small changes to one of your dependencies, and deploy your application with those changes. Of course, in some cases you can make the tweaks via monkey-patching, but in other cases, the only real solution is to change the gem itself.

With bundler, you can simply fork the gem on Github, make your changes, and change the gem line in your Gemfile to include a reference to the git repository, like this:

# change this
gem "devise"
 
# to this
gem "devise", :git => "git://github.com/plataformatec/devise.git"

This behaves exactly the same as a gem version, but uses your tweaks from Github. It participates in dependency resolution just like a regular gem, and can be installed with bundle install just like a regular gem. Once you’ve added a git repository, you run bundle install to install it (since the normal gem command can’t install git repositories).

You can use :branch, :tag, or :ref flags to specify a particular branch, tag or revision. By default, :git gems use the master branch. If you use master or a :branch, you can update the gem by running bundle update gem_name. This will check out the latest revision of the branch in question.

Conclusion

Using bundler for the sorts of things that you would have handled manually before should be easier than before. Bundler will handle almost all of the automatable record-keeping for you. While doing so, it offers the incredible guarantee that you will always run the same versions of third-party code.

There are a lot of advanced features of Bundler, and you can learn a lot more about them at the bundler web site.

Aug 30, 2010: Rails 3 has landed

Top Story

As you probably know, both Rails 3 and Bundler went final over the weekend. The Rails 3 release notes are up, as well as extensive coverage on the Rails Guides page. I’ll also mention Jeremy McAnally’s Rails 3 Upgrade handbookhttp, and Gregg Pollack’s list of great Rails 3 documentation sources. And, just for the hell of it, here’s the post I wrote back when Rails 3 was first announced. Somehow, this is not the first Google result for the phrase “Merby Overlords”

In other news

I do mean to write about Obtiva’s Master Class with Alistair Cockburn, but that’s going to take way more concentration than I can muster this morning. For the moment, it’s enough to say that it was fun, interesting, and enlightening.

In honor, this link that Alistair tweeted over the weekend, the Half-Arsed Agile Manifesto. Anybody who doesn’t recognize themselves in that a little bit has never actually tried Agile.

Link Out

By the way, I loved doing the post based on search engine entries into the site… you’ll see that again, as it was relatively easy, kind of funny, and marginally useful, and that’s pretty much what I aspire to.

If you’re into programming abstractions and/or you want to learn about Lisp, Magnus Holm has an introduction to S-Expressions for Rubyists.

And if you are into crazy Ruby metaprogramming, Lance Pollard has a long look at instance_eval. It’s nice to see a metaprogramming example that’s actually motivated from a use case.

Highly prolific conference blogger Jake Scruggs was at RubyKaigi this week, here’s day one of his report. Day two. Day three.

Filed under: Obtiva, Rails 3, Ruby

Rails Has Great Documentation

To this day I still hear people complain that Rails has poor documentation. From where I’m sitting this seems far from the truth. Let me lay out the evidence piece by piece:


RailsTutorial.org

To learn Rails from scratch Michael Hartl recently finished his book Ruby on Rails Tutorial: Learn Rails by Example. The book teaches Rails 3 from the ground up and it’s available for FREE online. If you’d rather have a PDF or a book you can grab that as well (and he’s even working on some screencasts).

The source for the finalized book will be pushed to GitHub and released under a Creative Commons License shortly after Rails 3 is done. If you’d like to help translate the book to your language of choice, feel free to contact Michael and he’ll get in touch when it’s time to make it happen.

Rails Guides

If you’re not a Rails newbie don’t forget about the Rails Guides, which have been updated for Rails 3.

Rails API Docs

There are two main websites I use to do API lookups. The first is Rails Searchable API Doc, which has online and offline searchable documentation. The second is APIdock which is online only, but has the ability to comment and easily compare different versions of documentation.

Rails 3 Free Screencasts

If you’re more of a visual learner (like me) then there are plenty of free screencasts to teach you about Rails 3. About 2 months ago I produced the Rails 3 Screencasts, which will get you started.

Ryan Bates has also produced an incredible amount of Rails 3 screencasts over on Railscasts.com. Ryan has been producing Railscasts for over 3 1/2 years, isn’t that crazy?

There’s also a few good free screencasts over on Teach me to Code by Charles Max Wood.

Keeping on the Edge

If you find yourself wondering how to keep up with all of the newest features / libraries for Rails 3, both the Ruby5 Podcast and the Ruby Show are going strong. Don’t listen to audio? It doesn’t matter, just subscribe to the Ruby5 RSS feed and get links with descriptions to all the newest libraries, tutorials, and more. You might also want to checkout Peter Cooper’s new Ruby Weekly, a Ruby email newsletter.

Need to upgrade a big app to Rails 3?

Jeremy McAnally’s Rails 3 Upgrade Handbook PDF is just $12. There’s also a few paid screencasts for the upgrade over on Thinkcode.tv and BDDCasts.

Need a Book?

There’s a bunch of books that will be coming out after the release, most of which you can start reading now. The Rails 3 Way by Obie Fernandez, Rails 3 In Action by Ryan Bigg and Yehuda Katz, Beginning Rails by Cloves Carneiro Jr and Rida Al Barazi, and of course the Agile Web Development with Rails:fourth edition by Sam Ruby, Dave Thomas, and David Heinemeier Hansson.

In conclusion

No more complaining about lack of good documentation! Seriously. If you want even more Rails 3 content, check out the blog post by Kevin Faustino on 34 Ruby on Rails 3 resources to get you started.

August 16, 2010: I Still Like Boring Software Development

Book Status

Beta 6 is out and available for sale here. The major addition is the new Shoulda chapter. It’s also available from Amazon. Note that the ship date for the print book seems to have moved to November.

Next up is the RSpec chapter, which will probably be Beta 7 sometime in the next week to ten days. After that, most likely a new chapter on test performance / performance testing. I also need to figure out what to do with an existing short bit on Autotest that doesn’t seem to fit anywhere. After that, we’ll see where we are in time and length.

The Boring Software Manifesto

It was fun to see my old Boring Software Manifesto linked at the bottom of this PragMag article on Software Manifestoes. I should revisit the Boring Manifesto, I think.

Links

If you are like me, then you are paying attention to Rails 3 but haven’t done any significant production projects yet. You may have seen odd references to a snowman. Sam Ruby presents a brief but clear explanation of why Frosty is now a part of Rails URLs.

One of my favorite Mac programs is Scrivener, and I wish that my writing projects lent themselves to using it more often. In this great post, Scrivener developer Keith Blount explains all the features that won’t be in Scrivener 2.0. One feature that will, though, is Dropbox integration, so that a Scrivener project can be worked remotely via, say, Droptext on an iPad.

Chronic is one of my favorite Ruby gems — it leads to a great client demo when you type “a week from next tuesday” into a calendar text box. Aaron Sumner has an overview of using Chronic and Chronic Duration for date and time parsing.

Ezra Zygmuntowicz is leaving Engine Yard after four years, and takes a blog-posts worth of time to reminsce.

Finally, Greg Moreno has been updating a Rails project to Rails 3, and documenting the process. Part 1. Part 2. Part 3.

Filed under: Boring Software, Chronic, Engine Yard, Rails 3, Scrivener, Snowman

Threads (in Ruby): Enough Already

For a while now, the Ruby community has become enamored in the latest new hotness, evented programming and Node.js. It’s gone so far that I’ve heard a number of prominent Rubyists saying that JavaScript and Node.js are the only sane way to handle a number of concurrent users.

I should start by saying that I personally love writing evented JavaScript in the browser, and have been giving talks (for years) about using evented JavaScript to sanely organize client-side code. I think that for the browser environment, events are where it’s at. Further, I don’t have any major problem with Node.js or other ways of writing server-side evented code. For instance, if I needed to write a chat server, I would almost certainly write it using Node.js or EventMachine.

However, I’m pretty tired of hearing that threads (and especially Ruby threads) are completely useless, and if you don’t use evented code, you may as well be using a single process per concurrent user. To be fair, this has somewhat been the party line of the Rails team years ago, but Rails has been threadsafe since Rails 2.2, and Rails users have been taking advantage of it for some time.

Before I start, I should be clear that this post is talking about requests that spent a non-tiny amount of their time utilizing the CPU (normal web requests), even if they do spend a fair amount of time in blocking operations (disk IO, database). I am decidedly not talking about situations, like chat servers where requests sit idle for huge amounts of time with tiny amounts of intermittent CPU usage.

Threads and IO Blocking

I’ve heard a common misperception that Ruby inherently “blocks” when doing disk IO or making database queries. In reality, Ruby switches to another thread whenever it needs to block for IO. In other words, if a thread needs to wait, but isn’t using any CPU, Ruby’s built-in methods allow another waiting thread to use the CPU while the original thread waits.

If every one of your web requests uses the CPU for 30% of the time, and waits for IO for the rest of the time, you should be able to serve three requests in parallel, coming close to maxing out your CPU.

Here’s a couple of diagrams. The first shows how people imagine requests work in Ruby, even in threadsafe mode. The second is how an optimal Ruby environment will actually operate. This example is extremely simplified, showing only a few parts of the request, and assuming equal time spent in areas that are not necessarily equal.


Untitled.001.png


Untitled.002.png


I should be clear that Ruby 1.8 spends too much time context-switching between its green threads. However, if you’re not switching between threads extremely often, even Ruby 1.8′s overhead will amount to a small fraction of the total time needed to serve a request. A lot of the threading benchmarks you’ll see are testing pathological cases involve huge amounts of threads, not very similar to the profile of a web server.

(if you’re thinking that there are caveats to my “optimal Ruby environment”, keep reading)

“Threads are just HARD”

Another common gripe that pushes people to evented programming is that working with threads is just too hard. Working hard to avoid sharing state and using locks where necessary is just too tricky for the average web developer, the argument goes.

I agree with this argument in the general case. Web development, on the other hand, has an extremely clean concurrency primitive: the request. In a threadsafe Rails application, the framework manages threads and uses an environment hash (one per request) to store state. When you work inside a Rails controller, you’re working inside an object that is inherently unshared. When you instantiate a new instance of an ActiveRecord model inside the controller, it is rooted to that controller, and is therefore not used between live threads.

It is, of course, possible to use global state, but the vast majority of normal, day-to-day Rails programming (and for that matter, programming in any web framework in any language with a request model) is inherently threadsafe. This means that Ruby will transparently handle switching back and forth between active requests when you do something blocking (file, database, or memcache access, for instance), and you don’t need to personally manage the problems the arise when doing concurrent programming.

This is significantly less true about applications, like chat servers, that keep open a huge number of requests. In those cases, a lot of the application logic happens outside the individual request, so you need to personally manage shared state.

Historical Ruby Issues

What I’ve been talking about so far is how stock Ruby ought to operate. Unfortunately, a group of things have historically conspired to make Ruby’s concurrency story look much worse than it actually ought to be.

Most obviously, early versions of Rails were not threadsafe. As a result, all Rails users were operating with a mutex around the entire request, forcing Rails to behave like the first “Imagined” diagram above. Annoyingly, Mongrel, the most common Ruby web server for a few years, hardcoded this mutex into its Rails handler. As a result, if you spun up Rails in “threadsafe” mode a year ago using Mongrel, you would have gotten exactly zero concurrency. Also, even in threadsafe mode (when not using the built-in Rails support) Mongrel spins up a new thread for every request, not exactly optimal.

Second, the most common database driver, mysql is a very poorly behaved C extension. While built-in I/O (file or pipe access) correctly alerts Ruby to switch to another thread when it hits a blocking region, other C extensions don’t always do so. For safety, Ruby does not allow a context switch while in C code unless the C code explicitly tells the VM that it’s ok to do so.

All of the Data Objects drivers, which we built for DataMapper, correctly cause a context switch when entering a blocking area of their C code. The mysqlplus gem, released in March 2009, was designed to be a drop-in replacement for the mysql gem, but fix this problem. The new mysql2 gem, written by Brian Lopez, is a drop-in replacement for the old gem, also correctly handles encodings in Ruby 1.9, and is the new default MySQL driver in Rails.

Because Rails shipped with the (broken) mysql gem by default, even people running on working web servers (i.e. not mongrel) in threadsafe mode would have seen a large amount of their potential concurrency eaten away because their database driver wasn’t alerting Ruby that concurrent operation was possible. With mysql2 as the default, people should see real gains on threadsafe Rails applications.

A lot of people talk about the GIL (global interpreter lock) in Ruby 1.9 as a death knell for concurrency. For the uninitiated, the GIL disallows multiple CPU cores from running Ruby code simultaneously. That does mean that you’ll need one Ruby process (or thereabouts) per CPU core, but it also means that if your multithreaded code is running correctly, you should need only one process per CPU core. I’ve heard tales of six or more processes per core. Since it’s possible to fully utilize a CPU with a single process (even in Ruby 1.8), these applications could get a 4-6x improvement in RAM usage (depending on context-switching overhead) by switching to threadsafe mode and using modern drivers for blocking operations.

JRuby, Ruby 1.9 and Rubinius, and the Future

Finally, JRuby already runs without a global interpreter lock, allowing your code to run in true parallel, and to fully utilize all available CPUs with a single JRuby process. A future version of Rubinius will likely ship without a GIL (the work has already begun), also opening the door to utilizing all CPUs with a single Ruby process.

And all modern Ruby VMs that run Rails (Ruby 1.9′s YARV, Rubinius, and JRuby) use native threads, eliminating the annoying tax that you need to pay for using threads in Ruby 1.8. Again, though, since that tax is small relative to the time for your requests, you’d likely see a non-trivial improvement in latency in applications that spend time in the database layer.

To be honest, a big part of the reason for the poor practical concurrency story in Ruby has been that the Rails project didn’t take it seriously, which it difficult to get traction for efforts to fix a part of the problem (like the mysql driver).

We took concurrency very seriously in the Merb project, leading to the development of proper database drivers for DataMapper (Merb’s ORM), and a top-to-bottom understanding of parts of the stack that could run in parallel (even on Ruby 1.8), but which weren’t. Rails 3 doesn’t bring anything new to the threadsafety of Rails itself (Rails 2.3 was threadsafe too), but by making the mysql2 driver the default, we have eliminated a large barrier to Rails applications performing well in threadsafe mode without any additional research.

UPDATE: It’s worth pointing to Charlie Nutter’s 2008 threadsafety post, where he talked about how he expected threadsafe Rails would impact the landscape. Unfortunately, the blocking MySQL driver held back some of the promise of the improvement for the vast majority of Rails users.

August 3, 2010: The Most Efficient Cargo Cult Money Can Buy

Book Status

Spent yesterday’s book time rearranging the Shoulda chapter so as to be more focused on the general ideas than the specific Shoulda interpretation. Today’s job is making sure it all still flows.

Links

So I have something like a half-dozen half-finished blog posts. Until the day some of those become fully finished, here’s a few links.

Simone Carletti has list of practices to follow in your Rails 2.3 app to make it more compatible for an eventual upgrade to Rails 3. I literally just used this article yesterday, building a new Rails 2.3 app with Bundler, rails_xss, and a couple of other nifty things.

Yes, that’s why I tweeted yesterday about the awesomeness of RVM. It was the first time I needed to keep Rails 3 and Rails 2 on my system, so the first time I created a project specific gemset — you can find some articles with instructions in previous link posts. Easy to create, easy to share, easy to set up everybody’s development environment.

This list from Istvan Hoka of Mac OS X tools for Ruby development is a little quirky, but a good overview of what’s available.

I really want to start using Passenger 3. A couple of days ago the Passenger team released another preview post with more cool features. They deliberately bury the lede, though, as they close the post with a strong hint that some of the features will be held for a premium for-pay version. More power to them, I say — free plus paid extras sounds like a good model for them.

Following up on the gems he released a few days ago, James Golick describes his rollout tool for conditionally adding new features. It uses Redis to determine user status for the purposes of conditionally executing code.

I thought about this tweet from Yehuda Katz for a while:


Am I crazy, or is it too easy to cargo-cult crazy practices from StackOverflow, resulting in compounded problems and error reports?

I see where he’s getting this, but I’m not sure that Stack Overflow is all that qualitatively different than picking up advice on the internet in general. It’s just a more efficient way to cargo cult, which would make a great slogan.

Filed under: Passenger, Rails 3, rvm, Yehuda

July 27, 2010: No Rails Release Shall Escape My Sight

Book Status

Beta 5 should be out today, with the legacy and the Rails 3. Next up are the Shoulda and RSpec chapters, starting with figuring out how to handle the changes in Shoulda since I last wrote the chapter.

Rails

I’m sure all of you within the interest circle of this blog already know that Rails 3.0 RC 1 was released yesterday. Part of me wants to say “finally”, but that really isn’t fair. Doesn’t look like there are dramatic changes from Beta 4, but check out the release notes.

And another thing

So Larry Doyle, author of the Go Mutants! book that I reviewed yesterday, re-tweeted me this morning, which I suppose means he read the review. That kind of thing always surprises me more than it should, given how often I Google my own name…

Links

Okay, nobody else is going to care, but here is Ryan Reynolds from ComicCon reciting the Green Lantern Oath for a small fan during the panel discussion of the upcoming movie. Green Lantern was, somehow, my favorite character when I was a kid, and it’s great to see Reynolds do the line without a hint of ironic winking.

37Signals posts some information on their production database setup. This kind of thing is incredibly useful, but for obvious reasons kind of hard to come by. So, thanks.

Thoughtbot announced the release of Flutie, which is a “not CSS framework” distributed as a Rails engine. It seems like a set of intelligent CSS defaults that can be used to make something look good by a non CSS-guru developer, but which still allows a CSS expert to use a site layout framework on top. Looks helpful.

This is a couple of months old from Takaaki Kato, but it’s a nice series of TextMate tips for Rails developers. I’d add that I’ve always had trouble with ProjectPlus — it’s always had performance problems for me. A very handy set of tips, though.

Filed under: 37signals, CSS, Geek Out, Rails 3

What’s New in Bundler 1.0.0.rc.1

Taking into consideration the huge amount of feedback we received during the Bundler 0.9 series, we streamlined Bundler 1.0 significantly, and made it fit user expectations better.

Whether you have used bundler before or not, the easiest way to get up to speed is to read the following notes and go to http://gembundler.com/v1.0 for more in-depth information.

(note that gembundler.com is still being updated for the 1.0 changes, and should be ready for the final release).

Starting a new project with bundler

When you generate a new Rails application, Rails will create a Gemfile for you, which has everything needed to boot your application.

Otherwise, you can use bundle init to create a stub Gemfile, ready to go.

First, run bundle install to make sure that you have all the needed dependencies. If you already do, this process will happen instantaneously.

Bundler will automatically create a file called Gemfile.lock. This file is a snapshot of your application’s dependencies at that time.

You SHOULD check both files into version control. This will ensure that all team members (as well as your production server) are working with identical dependencies.

Checking out an existing project using bundler

After checking out an existing project using bundler, check to make sure that the Gemfile.lock snapshot is checked in. If it is not, you may end up using different dependencies than the person who last used and tested the project.

Next, run bundle install. This command will check whether you already have all the required dependencies in your system. If you do not, it will fetch the dependencies and install them.

Updating dependencies

If you modify the dependencies in your Gemfile, first try to run bundle install, as usual. Bundler will attempt to update only the gems you have modified, leaving the rest of the snapshot intact.

This may not be possible, if the changes conflict with other gems in the snapshot (or their dependencies). If this happens, Bundler will instruct you to run bundle update. This will re-resolve all dependencies from scratch.

The bundle update command will update the versions of all gems in your Gemfile, while bundle install will only update the gems that have changed since the last bundle install.

After modifying dependencies, make sure to check in your Gemfile and Gemfile.lock into version control.

By default, gems are installed to your system

If you follow the instructions above, Bundler will install the gems into the same place as gem install.

If necessary, Bundler will prompt you for your sudo password.

You can see the location of a particular gem with bundle show [GEM_NAME]. You can open it in your default editor with bundle open [GEM_NAME].

Bundler will still isolate your application from other gems. Installing your gems into a shared location allows multiple projects to avoid downloading the same gem over and over.

You might want to install your bundled gems to a different location, such as a directory in the application itself. This will ensure that each application has its own copies of the gems, and provides an extra level of isolation.

To do this, run the install command with bundle install /path/to/location. You can use a relative path as well: bundle install vendor.

In RC1, this command will use gems from the system, if they are already there (it only affects new gems). To ensure that all of your gems are located in the path you specified, run bundle install path --disable-shared-gems.

In Bundler 1.0 final, bundle install path will default to --disable-shared-gems.

Deployment

When deploying, we strongly recommend that you isolate your gems into a local path (using bundle install path --disable-shared-gems). The final version of bundler will come with a --production flag, encapsulating all of the best deployment practices.

For now, please follow the following recommendations (described using Capistrano concepts):

  • Make sure to always check in a Gemfile.lock that is up to date. This means that after modifying your Gemfile, you should ALWAYS run bundle install.
  • Symlink the vendor/bundle directory into the application’s shared location (symlink release_path/current/vendor/bundle to release_path/shared/bundled_gems)
  • Install your bundle by running bundle install vendor/bundle --disable-shared-gems

June 30, 2010: The Triumphant Return of the Monster Link Post

The end of the repair story

At the end, a very positive experience with Apple support. The repair was free, done when they said it would be done, and all told, I spent less than fifteen minutes in the store between both halves of the visit. Plus, they replaced the top part of my pre-unibody MacBook, which was worn down and discolored from my gunky hands, almost as though they didn’t want an ugly Mac in the field.

Book Status

With the laptop back, I’m back to work, last night going back over the Style chapter. I think now the plan is to do a slightly smaller next beta that would get out next week, just the Coverage and Style chapters, with the next batch, probably the Legacy and redo of the startup example coming shortly on its heels.

Also, the book has somewhat quietly shown up on Amazon and, I presume, other online outlets.

Of course, the beta is still available at PragProg.

Links

Many, many links, as I catch up on an entire week’s worth.

Thoughtbot announces that factory_girl is now split into a separate Rails 3 gem, in much the same way that Cucumber and RSpec are.

Also in Thoughtbot-land, the should_change command has been deprecated from Shoulda.

Jeremy McAnnaly announces the 2010 Ruby Hoedown, after some rescheduling due to the Nashville flooding. Again, it’s the low, low, price of free. I’m hoping to break my 0-for-2010 streak on conference proposals with my submission.

Everyday Rails has a good post about getting Rails 3 and RVM working together.

I haven’t watched this video yet, but a little Don Norman is a good thing, right? (via Joel Spolsky)

Test Inline is a Ruby library from Eric Anderson to put tests in the Ruby source file. Eric freely admits that this is an experiment, which is good because my experience with this kind of tool (Python doctests) is that it gets messy pretty quickly.

Ever think that Lemmings would make a great iPhone game? Me too. Also, the people who have the rights to the code. Coming soon.

I love Steve Martin. He’s posted the rider for his tours. A sample: “BUFFET … Six-packs of any canned beverage for Steve to compare his abs to.”

I’ve been waiting for this: Lifehacker posts some Handbrake presets for iPad and iPhone 4. Seem decent, but a bigger file size than what I had been doing.

Please don’t do this. It’s a bad idea and will make your code harder for other Ruby developers to maintain.

Two from David Chelimsky: Having a topic branch when contributing to git projects, and a change in how views are handled in controller tests in RSpec 2.

I really need to watch this presentation from RailsConf on Beautiful Markup by John Athayde.

Speaking of RailsConf, here’s a retrospective from John Trupiano of the BohConf “unconference” that happened alongside.

Dan Ingalls was one of the people behind Smalltalk 80, here’s an interview with him.

Over at Teach Me To Code, a screencast about setting up a Rails project and writing the first Cucumber feature.

Still in Cucumber, Michael Orr shows how you can use an instance variable to track objects in a Cucumber test. I do this a lot, myself, although I’m not completely convinced that you get a cleaner test suite at the end.

Rands has a great post about his writing process. I love that everybody does this a little differently, although calling what I do a “process” is probably a little much.

Paolo Perrota, author of Metaprogramming Ruby, has a nice note about how great the Ruby community is.

UxMyths seems like a useful site to browse.

Speaking about great writing, I loved, loved the opening of this article by Adam Keys about why he always comes back to TextMate. Also some good comments. I hadn’t thought of the issue exactly this way, but it makes perfect sense.

The Time of Day gem lets you treat ActiveRecord time columns without their date information for certain kinds of comparisons.

Finally

I think I mentioned that I did a talk at Refresh Chicago last week. It was fun, but we think turnout was down due to the tornado warning over Chicago that night — it’s possible the sirens acted as a deterrent. Well, video of that is not up, but here’s a video of the storm that night, featuring lightning striking three Chicago skyscrapers at the same time.

Filed under: Cucumber, Don Norman, iPhone, Rails 3, Ruby, rvm, Shoulda, Steve Martin, UXD, writing

June 21, 2010: Double Double Splat Splat

Link post today. Turns out I built up more links than I thought.

Book Status

Somehow I wound up writing and editing the Rcov chapter, which, among other things, is the first time I’ve had to wrestle with RSpec 2 vs. RSpec 1 behavior, when writing about how RSpec and Rcov get along. Now I need to figure out how to write about that more coherently. Actually, I need to decide if I’m going to acknowledge RSpec 1 at all.

The book is still on sale, of course. I’ve gotten nice feedback so far, but not much of it, I’d love to hear from you. And if you like the book, and wanted to tell your friends, or the Internet at large, that’d be great, tool. (Oh, look, I’m turning into that guy…)

Links

Rebecca Murphey has written “JQuery Fundamentals” a new Creative Commons book on JQuery. Looks useful, though I’d also love it if an epub version was made available. I bet I’ll be referring here a bunch, though.

Looks like there will be a JavaScript native implementation of LessCS. Interesting. I’m still wondering how the Less/Sass thing plays out.

The previous two links are via Larkware’s Daily Shots.

Here’s a big chunk of code from Brian Cardarella that allows you to do user-selected subdomains using the Rails 3 router.

Via Everyday Rails, here’s http://www.youvegotrails.com/, which generates a Rails template for you, after you select some parameters. Pretty neat. I’d imagine it’ll grow more parameters over time.

I think the lesson of this article by Patrick McKenzie about human names is that no matter how far you go in creating a database schema, there’s always somebody who will go farther.

The Phusion team continues to tease about the impending awesomeness of Passenger 3.

Thoughtbot, in the person of Nick Quarantino, has a crazy detailed post on using Hudson for continuous integration with RVM. I’m going to go out on a limb and say this could be made easier.

I don’t read the Japanese, but supposedly Matz is blogging about possible Ruby 2.0 features. If I’m interpreting this correctly, it looks like Python-style double-splats are in play, which I’d like. (“Python Style Double Splats” is the name of my new Eric Idle cover band. Sorry.)

Filed under: Database, Hudson, JQuery, Less, Matz, Passenger, Rails, Rails 3, rvm

June 14, 2010, Practice makes less imperfect

Still catching up on links. The PeepOpen review has morphed into a larger IDE/TextMate piece, hoping to finish that today.

Book Status

Still working on the renovated Style chapter, which will probably combine the chapters that are in the current Table of Contents as “Testing Style and Structure”, “Fix Slow Tests”, “Rcov”, and “Help! My Test Is Failing”. The chapter on Legacy testing will remain a separate chapter — I get asked about how to test legacy projects all the time.

What happens at that point kind of depends where we are on page count — there are two chapters left that are basically unwritten (Selenium, performance testing), and two chapters that are written but need to be brought up to date (Shoulda, RSpec). Probably more information on this line later this week.

Today In Links

Liked this article from Naresh Jain about deliberately practicing TDD on sample problems to get better. Not sure if I’ve mentioned it here, but Project Euler is a great source of sample problems if you are mathematically inclined.

I suppose it was inevitable that somebody would write about Steve Jobs’ presentation style in the wake of the network issues during the iPhone keynote last week. Still, good advice, even if they handwave over the most useful helpful bit — “an adoring crowd”.

Yehuda posted a short gist about implementing the “acts_as” pattern more simply then is usually done.

Thoughtbot posted a list of the Rails 3 compatibility status of all their open projects. Yay! Most relevant for my immediate purposes, Shoulda has a new release with Rails 3 support and “some dramatic changes”. Though I couldn’t quite see from the history what they meant. More details coming.

In other Rails 3 news, Jhimy Villar has a workaround for a Rails 3 issue affecting Authlogic. I’m seriously considering moving the Rails Test Prescription examples to Devise on the grounds that a) it’s already Rails 3 compatible, b) it seems to have fewer setup steps and c) it seems to stay out of the way a bit more, which is a big plus for my purpose.

Did not mention this last week, but RubyConf X will be Nov 11 – 13 in New Orleans. Never made it to a RubyConf.

Zed Shaw has announced the Mongrel2 project, which is a complete redesign of Mongrel. Not much there yet, but watch this space.

Finally

In an interview with Think Geek (via GeekDad), Jonathan Coulton says that the new album he’s been teasing for a bit will be produced by John Flansburgh of They Might Be Giants. That should be fun.

Filed under: Authlogic, Coulton, Mongrel, Rails 3, Shoulda, Steve Jobs, testing, Yehuda

June 10, 2010: RailsConf-a-palooza

Sorry for the involuntary day off yesterday. Lot of links, I’ll try and be brief.

RailsConf and Related

DHH’s Tuesday keynote is up. Presumably this is different from last year’s keynote about Rails 3. The other keynotes will probably become available in the next few days.

David announced Rails 3 beta 4 at his keynote. It looks like we’ll be getting a release candidate in another couple of days.

The Ruby Hero awards were given. Weirdly, I can only see the list via people who tweeted about it — there doesn’t seem to be an official list up yet. Winners are José Valim, Nick Quaranto, Xavier Noria, Aaron Patterson, Wayne Seguin, and Gregory Brown. Congrats to all.

Most speaker slides will be available at the RailsConf site.

Gregg Pollack has a screen cast series called Dive Into Rails 3. Which, if past performance is any indicator, will be very useful.

Online recaps include: JetBrains and Jake Scruggs.

Says here that DHH “was dismissive of an analyst report that did not reflect kindly on Rails”. Ooh — how’d I miss this. It’s a survey from April that places Rails 11th out of 12 web frameworks in developer satisfaction. (Beating out Spring, with .NET on top). That seems… unlikely based on my experience. But hey, what do I know, I can’t charge $600 for my reports.

And A Bunch of Other Stuff

Bowline is a new library for cross-platform desktop apps using Ruby.

Apple’s official Safari Extension page isn’t up yet, in the meantime, there’s http://safariextensions.tumblr.com/.

Send Keys is a Capybara extension that lets you send keystrokes to the web page under test.

Filed under: Capybara, Rails 3, RailsConf, Safari

June 7, 2010: Lot of Conferences Week Begins

Today is the RailsConf tutorial day, with the conference proper starting tomorrow. I was less disappointed than I thought I would be when my talks were not accepted, but I’m more disappointed than I thought I would be not to be going. Have fun, everybody.

On the other side of the country, today is the Apple WWDC keynote, which I’m sure I’ll join the rest of the internet in obsessing over.

Book Status

Over the weekend, worked on the style chapter of the book, largely trying to incorporate the ideas from the Chicago Ruby talk, and also combining some of the short chapters. Need to find out if I have a page limit.

Lots Of Links

Plasma Rails is a new Rails RDoc presentation site that claims to update Rails 3 docs nightly. It’s got a very TextMate-ish dark theme.

The Everyday Rails site has a quick rundown of three Rails Authentication methods, Restful Authentication, Authlogic, and Devise. Devise looks nice, and I’m considering moving the Rails Test Prescription examples to it since it seems to be an easier setup than Authlogic and also Rails 3 compatible.

Not to be outdone, I Suck At Ruby mentions a feature of the the Ruby TextMate bundle that validates Ruby code on save.

Josh Owens at RailsFreak has a suitably quick post with thoughts on how to do a quick launch of a web application.

DHH himself has released Tolk, which is a Rails engine providing a web interface to support translators entering text and converting it to the Rails YAML locale files. I think this was extracted from the recent Basecamp multiple language release, looks like it’d be useful.

Ars Technica named the winners of their design awards. I concur on two of the three apps that I use (Tweetie — please finish the Mac version 2.0 — and Dropbox), I like 1Password, but wouldn’t consider the app itself to have a particularly great design. Don’t use the others, although Soulver is pretty cool.

Finally, In Self Promotion

This has been around for a while, I think, but it just passed back in front of my eyes. Antonio Cangiano has a list of recommended Ruby books, and a separate list of Rails books.

Somewhat flattered to have my Wrox book, Professional Ruby on Rails, be included. There are parts of that book that I think are really great. And parts of it that were obsolete almost the moment it was printed (for instance the entire chapter on using Subversion with Rails…). Anyway, thanks!

Filed under: Authentication, i18n, Mac, Rails 3, self promotion

June 4 2010: Okay, here’s a link post

Quick links post:

Gregory Brown is looking for comments and donations for a proposal for a Ruby Mendicant University, basically a rolling online Ruby course.

Charles Nutter is interviewed by InfoQ on the state of JRuby.

Yehuda Katz has a long post on various kinds of extensions in Rails 3 — gems, plugins, generators. This one I need to look at in some detail.

The new RubyMine 2.5 beta integrates with Pivotal Tracker. Looks like you can tell RubyMine what story you are working on and it will tag your source control comments. Cool.

Book Status

Working on the style/quality chapters, integrating material from the ChicagoRuby talk. Probably not a beta next week, but maybe the week after.

Filed under: JRuby, Rails 3, Ruby, RubyMine, Yehuda

June 2, 2010: How To Test Good

Yesterday…

Gave my talk at Chicago Ruby. The video is already online — yay Chicago Ruby team. I was pleased with it, actually, I did pretty much what I hoped to do, except that I thought the repetition joke would get a bigger laugh.

In other news

Yehuda Katz posted slides on another Rails 3 talk: dashing to the finish.

Speaking of people on stage, Steve Jobs was interviewed on stage at the D conference yesterday. Among other, more important things, Jobs admitted that the initial iPhone-ish prototype was tablet sized.

Saw this on Twitter just now, and it looks nice — a node based console app for speaking HTTP. Looks like that’d be handy in almost any web development toolkit.

David Turnbull has a new Tumblelog called I Suck At Ruby, looks like he’s got some useful short bits and good advice for sucking less. I’ve also got Everyday Rails, by Aaron Sumner (Tip to everybody: make your actual name more prominent on your blog…) Both of which remind me that it’s time I put more original content here…

Filed under: Apple, Chicago Ruby, Me talking, node, Rails 3, Yehuda

May 28, 2010: Friday Friday Friday

Short today, but preparing some longer, more rant-y bits for the future…

Book status

Not much forward motion for the next few days, as I have a lot of other stuff to do, including preparing for Chicago Ruby on June 1 and doing a bit of touch-up on Obtiva’s 4-Day Ruby on Rails/TDD boot camp. All fun, but time consuming.

Some Links

A quick tutorial by Peter Cooper on setting up JQuery in Rails 3.

This isn’t the first time I’ve seen something like this, but this article by Alan Skorkin on Ruby Procs and Lambdas is well done and it’s worth refreshing from time to time.

We always say that Ruby methods can’t have spaces in them, but technically that’s a lie, as shown in Joon You’s screencast.

Rails Dispatch this week is by José Valim. It’s kind of rambling, but a very interesting look at plugins that mess with Rails 3 features like Responders and Generator.

Filed under: Chicago Ruby, JQuery, Metaprogramming, Obtiva, Plugins, Rails, Rails 3, Ruby

May 21, 2010: Meetings

Book Status

Committed what I hope will be the Beta 3 version of the Cucumber chapter. Most of the changes were in the various conclusions. When I originally wrote the chapter, Cucumber was still quite new, and I had kind of a ragged set of thoughts about how it should be used. Since then, I’ve used it more, and more importantly, there’s been a lot more community discussion about how Cucumber is best used, so I needed and was able to tighten up that part a bit.

Meetings, I’ve Got Meetings

If you are in the Chicago area, you might want to check out some group meetings.

The brand new ChicagoDB user group will have its first meeting Monday June 21 at Obtiva World HQ in Chicago. RSVP if you plan on coming.

Also, the Chicago Ruby meeting on June 1, now has a more detailed description of the schedule.

And then

A couple of links on setup:

This week in RailsDispatch, upgrading from Rails 2 to Rails 3.

Rogelio Samour has posted a set of steps that Hashrocket currently uses to create their standard Ruby setup for Snow Leopard machines. Looks nice.

Finally

A few weeks ago I linked to a This American Life story about the NUMMI auto plant that recently closed after a long time being the flagship GM plant for running based on Toyota/Lean principles. Interesting follow up yesterday: the plant will be part of Toyota’s investment in Tesla, and will be used to build Tesla’s cars.

Filed under: Chicago Ruby, ChicagoDB, Cucumber, Rails 3, Snow Leopard

May 14: Moving To Beta 3

Top Story

Just a quick update here.

Cucumber chapter newest draft is complete, and I’m hoping it will be beta 3 early next week. Not sure what to do next, I need to look around and see what’s relatively stable with respect to Rails 3.

The book is still on sale. Tell all your friends.

And then

Rails Dispatch this week is about the new routing in Rails 3.

Yehuda Katz has a really nice article on workflow with git.

A brief rant on Ruby 1.9 and encodings.

Finally

The excellent Dive Into HTML 5 book/site has a quick reference on how to detect all kinds of HTML 5 related browser behavior. I’m pretty sure I’ll be coming back to this page again.

Filed under: Cucumber, Git, HTML5, Rails 3, RailsRx, Yehuda