fidzu : Ruby

There are an incredible amount of Ruby & Rails conferences coming up in the next 6 months. See below to find one in your neck of the woods.

March 11-12 - MountainWest RubyConf in Salt Lake City, UT, USA

Cost: 100 USD

March 12-15 - Rails Camp New England in West Greenwich, RI, USA

Cost: 150 USD

March 20-21 - RubyConf India in Bangalore, India

Cost: 1000 INR

March 26-27 - Scottish Ruby Conference in Edinburgh, Scotland

Cost: 195 GBP

April 9-10 - Ruby Nation in Reston, VA, US

Cost: 259 USD

April 16-19 - RailsCamp Canberra in Canberra Australia

Cost: 210 AUD

April 17 - Great Lakes Ruby Bash in Lansing, MI, USA

Cost: ?

April 25 - RubyConf Taiwan in Taipei, Taiwan

Cost: 400 TWD

April 30 - ArrrrCamp #3 in Ghent, Belgium

Cost: Free

May 6-7 - Red Dirt RubyConf in Oklahoma City, OK, USA

Cost: ?

May 7 - Frozen Rails in Helsinki, Finland

Cost: 99 EUR

May 21-23 - Nordic Ruby in Gothenburg, Sweden

Cost: ?

May 22 - GoRuCo in New York, NY

Cost: ?

May 29-30 - Euruko in Krakow, Poland

Cost: ?

May 31-June 2 - RailsWayCon in Berlin, Germany

Cost: 699 EUR

June 7-10 - RailsConf in Baltimore, MD, USA

Cost: $695

August 26-28 - Lone Star Ruby Conference in Austin, TX, USA

Cost: ?

August 27-29 - Ruby Kaigi in Tsukuba, Ibaraki, Japan

Cost: ?

---

If I missed any (or have any information wrong) feel free to leave a comment and I'll add it to the post. FYI, I'm purposely only showing conferences in the next 6 months. I'll do another post in 6 months to show additional ones.

22 Feb 2010 6:09pm GMT

One of the best things about Rails is that it's under constant development. With the Live Edition of Learning Rails, the book will be able to track that progress and give beginners better access to the latest and greatest Rails has to offer.

17 Feb 2010 11:10pm GMT

Get 97 short and extremely useful tips from some of the most experienced and respected practitioners in the industry, including Uncle Bob Martin, Scott Meyers, Dan North, Linda Rising, Udi Dahan, Neal Ford, and many more. They encourage you to stretch yourself by learning new languages, looking at problems in new ways, following specific practices, taking responsibility for your work, and becoming as good at the entire craft of programming as you possibly can.

15 Feb 2010 1:31am GMT

The Live Edition of Learning Rails starts with an update of the book from Rails 2.1.1 to Rails 2.3.5. Code that changed over the past year or so has been cleaned up, as have errata that shouldn't have been there in the first place.

O'Reilly Live Edition books give you access to updates to topics in between editions of a book.

14 Feb 2010 1:36pm GMT

Get 97 short and extremely useful tips from some of the most experienced and respected practitioners in the industry, including Uncle Bob Martin, Scott Meyers, Dan North, Linda Rising, Udi Dahan, Neal Ford, and many more. They encourage you to stretch yourself by learning new languages, looking at problems in new ways, following specific practices, taking responsibility for your work, and becoming as good at the entire craft of programming as you possibly can.

14 Feb 2010 1:35pm GMT

Please give a warm welcome to José Valim and Carl Lerche as they both join the Rails core team. Both guys have been key contributors to the Rails 3 development and both have made it into the top 10 of all-time Rails contributors. It's an honor to have them on the team!

13 Feb 2010 1:39am GMT

Some of the biggest changes in Rails 3 involve how Rails expects plugins to behave.

Dependencies

If your plugin has dependencies, make it a gem and have your users install it using the Gemfile. This will ensure that Bundler properly calculates the dependencies alongside any other dependencies the user's app has.

If You Override Something, Require It

If you need to override ActionController, ActiveRecord or other Rails frameworks, require them first, then override. Instead of assuming that Rails will require your gem plugin at a "correct" time, assume that the user will require your plugin extremely early.

This gives you the opportunity to hook in earlier to the initialization process, but it also means that you should explicitly require the dependencies you need.

# in your_lib.rb

require "active_record" 
require "your_lib/extensions" 

ActiveRecord::Base.class_eval { include YourLib::Extensions }

Use a Railtie, But Only if You Need To

Even though you can expect your gem to load very early, you might still need to hook into a later part of the initialization process. If you do, inherit from Rails::Railties. Inside of a Railtie, you can declare a block that Rails should run when it runs Rakefiles, specify initialization blocks, add a subscriber to the notification system, and specify generators to load.

class TestingFu < Rails::Railtie
  # This creates a config.my_plugin in the user's Application
  railtie_name :testing_fu

  rake_task do
    load "testing_fu/tasks.rake" 
  end

  # specify the default generators for test frameworks
  config.generators.test_framework :testing_fu

  # you can also specify :before or :after to ensure that
  # your initializer block runs before or after another
  # initializer block
  initializer :setup_my_plugin do |app|
    # in here, I have access to the user's application,
    # which gives me access to app.config
  end
end

Make sure to require any railties that you intend to extend. For instance, if you want to run an initializer before one defined in ActionController, require "action_controller/railtie"

That said, don't use a Railtie if your code does not need to hook into any part of the Rails lifecycle. When possible, simply create a standard Ruby library, requiring the parts of Rails you need to override.

Engines

Engines in plugins (vendor/plugins) work as they did in Rails 2. In a gem, you'll need to provide a Rails::Engine subclass:

# lib/my_engine.rb
module MyEngine
  class Engine < ::Rails::Engine
    engine_name :my_engine
  end
end

Place your app directory next to the lib directory and Rails will pick it up. You can read the documentation for Railte, Engine, Plugin and Application, all in just one place, here: https://gist.github.com/af7e572c2dc973add221

Start a Conversation at railsplugins.org

In order to make this process easier, Engine Yard has put together railsplugins.org. If you're a plugin author, please submit your plugins to that site. You can tell users whether or not you expect your plugins to work on Rails 3, whether or not your users can run them in threadsafe mode, and whether they run on JRuby.

Once you've put a plugin up there, users can say that they either agree that your plugin runs or disagree, with a comment about what is broken. You can reply to any such comments, and the user can change his mind if he just made a mistake. When you submit a new version, the site creates a whole new page, so comments about things not working on a previous version don't clutter up the current version (users can still get at the old versions if they wish).

If we do this right, the Rails community will have a strong sense of what works on Rails 3 and what doesn't. Have at it!

11 Feb 2010 2:31pm GMT

As a Ruby programmer, you already know how much fun it is. Now see how to unleash its power, digging under the surface and exploring the language's most advanced features: a collection of techniques and tricks known as metaprogramming. Once the domain of expert Rubyists, metaprogramming is now accessible to programmers of all levels--from beginner to expert. Metaprogramming Ruby explains metaprogramming concepts in a down-to-earth style and arms you with a practical toolbox that will help you write great Ruby code.

10 Feb 2010 8:36pm GMT

After years of resisting phone ownership followed by a few years of owning a 2003-era Nokia dumbphone, I finally decided to make the jump when the Nexus One was announced. I've got a strong distaste for systems that place arbitrary restrictions on their users, and while the Android OS itself doesn't have any, many Android phones before the Nexus One have had the carriers interfere with the user's control over their phone, though not to the same offensive degree as Apple. The Nexus One is sold directly through Google without giving the carriers a chance to sully it.

Daily Usage

The screen is just brilliant, and the 800x480 resolution means everything is sharp. The OS is very smooth and responsive. Having spent so long on a system where the keyboard is king and the mouse is only used in exceptional cases, switching to the inverse situation on the phone is a bit odd, but not as disorienting as you'd expect. Like any handheld keyboard, the Nexus's is bad for writing anything longer than a tweet, but it's certainly no worse than the hardware keyboard on the old Zaurus I toy around with occasionally. The built-in apps work great, and if you take the plunge to fully switch to GMail, it pretty much makes syncing your mailbox a solved problem.

There are a few nit picks like the color balance being a bit off on the camera, the way the face buttons don't trigger unless you push the upper half, and the fact that the built-in jabber client only supports a single account. But these are all pretty minor or easy to work around. The only thing that really bugs me about it is the fact that there's no ZeroConf implementation yet for the platform. But there are people working on this, so it's just a matter of time.

Oh, and using it to Talk?

It turns out you can also use the Nexus One to interface with the global legacy telephone system and make calls on that. Supposedly it has a very nice dual-mic noise suppression system for when you do this, but I've only made a handful of test calls so far. I got a data-only plan for half of what the regular voice+data plans go for and had planned to use Sipdroid to make VoIP calls with it, but then I realized I just don't make voice calls any more. So while there's a barely-noticeable delay with SIP calls over the 3G network, it really doesn't bother me. I also have used the Wired Tether app to hook up my laptop on the go and can confirm that calls via Skype sound fine too. So it's nice that T-Mobile isn't blocking that on a network level. They do seem to be the least-user-hostile of all the US carriers.

Hacking It

Of course once you get past the formalities, the question that matters to a hacker is how it feels to hack. I've only really gotten started with this, but my initial report is fairly positive. The official toolsets are either Eclipse or Ant, neither of which give me warm fuzzies, but luckily you can use Ant out of the box without getting exposed to the XML-editing ickiness.

Getting programs onto the device is pretty simple. Once your source is ready, you run ant debug, which produces a .apk package. You can use the adb (android debugger) program to load it up over USB, but since I keep leaving my USB cable various places, I prefer just scping it to my server and pointing my device's browser directly at the .apk. You can also use this to install dev builds of various apps before they have been uploaded to the Market.

The API seems pretty sane. A lot of thought has gone into the notion of supporting a single front-and-center application while allowing others to run in the background without impacting battery life and performance too severely. I've played a bit with the graphics tools, and they remind me a fair bit of Processing, which is a good thing. I haven't done much intricate UI work with a lot of buttons or menus, but that kind of stuff can be tedious even in the nicest environments.

Language of Choice

Since the Android VM is based on the JVM, there's a whole host of languages that can run on it. Unfortunately, Dalvik is no Hotspot-it currently lacks JIT, and the GC is merely serviceable rather than astoundingly good like Hotspot's. The lack of a good GC makes using persistent data structures a real drag since they generate a lot of ephemeral garbage, so Clojure is not a good choice. The lack of JIT coupled with CPUs that are comparatively low-powered means that while JRuby runs, it's not altogether pleasant, especially considering the blitz with which regular apps perform. I've been told there is some low-hanging fruit for improving performance on Android, so this is likely to improve to a degree. Rhino, Python, Lua, Scala, and others work, (including, I'm told, even some legacy languages like Java, if you can imagine that) but I decided to try the less-traveled route with something called Duby.

Duby is a language created by Charles Nutter, the head of the JRuby project. JRuby is an amazing feat in part because Ruby's object model is vastly different from what's natively available on the Java platform. By an astounding effort they've managed to put together a first-class Ruby implementation, but it does beg the question: what would a modern language look like that went with the grain of its host instead of violently against it? Duby is an attempt to answer that question.

The syntax of Duby is nearly identical to that of Ruby; it only adds type declarations to method definitions. Yes, that means it's statically-typed. While it has type inference, it's not Hindley-Milner-style, it's closer to Scala's. Locals get their types inferred, it's only arguments in method definitions that need hints. So far I keep forgetting this nearly every time I write a new method since it looks so close to Ruby otherwise, but I'm sure I'll get the hang of it. Closures are implemented, so you can iterate over collections with blocks. Duby is also unique in that it literally has no runtime- its literals translate directly to ArrayLists and HashMaps, so once you've compiled, the code is more or less identical to what the Java compiler would have output.

Progress

So far I've only put together a couple toy apps: Hello World, and a graphics demo with a bouncing ball. Unfortunately, Duby is a very immature language, and it shows. Starting out I had to go to Charlie at nearly every turn with stack traces. Half the time it would be my fault, and half the time it would be something as-yet-unsupported by the compiler. But so far he's been able to turn around and bring in all the features I need, which has been quite amazing. I'm hoping to get a chance to dive into the compiler source myself and get to the point where I can add features I need with minimal guidance.

Adapting the build process to Duby was surprisingly easy. You redeclare the compile task to call the Duby compiler instead of javac, tell it to output its bytecode in the right directory, and the rest of it just falls into place.

My next plans are to add more interactivity to my graphics demo; I'd like to play with creating objects and applying motion rules to them; I hope to come up with something my two-year-old would get a kick out of. So far it's been a lot of fun and a great way to explore the capabilities of this remarkable device.

07 Feb 2010 9:35pm GMT

First, some quick background. C is a very simple programming language and doesn't have exceptions - problems are indicated with return codes, which you're supposed to check but always forget about it, resulting in all sorts of problems. C++ tried to retrofit exceptions on top of that, and it was a spectacular failure due to bad interactions between exceptions and manual memory management, but let's skip that.

Shell doesn't have exceptions either, but almost all problems result in some error message being printed to stderr, so at least you know that something went wrong.


Perl is trying to be higher level but is modeled after C and shell, so while it sort of support exceptions for some high level packages, almost all of its basic OS-interacting functions like open will fail quietly and you need to manually check their return codes - at least it's easier than C, and ... or die "Cheeseburger acquisition failed: $!"; usually suffices.

Ruby mostly copies Perl when it comes to OS interaction, but fixes this particular problem - OS interaction always raises an exception when something goes wrong. Or does it?

system()

There is one really infuriating exception, where not only Perl error handling is worse than both C and shell, Ruby copies this design failure straight from it, and it's not even fixed in Ruby 1.9 yet!

C function system is fairly straightforward - it executes whatever string you pass to it in shell. So if there's an error and let's say the command fail doesn't exist - int main(){ system("fail"); return 0; } results in "sh: fail: command not found" printed on stderr, or somesuch depending on your variant of Unix. Just like shell would do it, and what would be sane.

Both Perl and Ruby copy this function - except they do it wrong! system funciton is not terribly efficient - it first spawns shell process, which only then executes the relevant command. So some smarty pants decided to optimize it a bit - if the string passed to Perl/Ruby system looks straightforward enough, Perl/Ruby will execute it directly (split on spaces, fork, pass to exec) without spawing the shell process.

And in this micro-shell implementation inside system they both just forgot to check for error conditions altogether. system "fail >/dev/null" (in either of these languages) looks "non-trivial", so it spawns shell process, and results in sh: fail: command not found. But system "fail" - as it's so simple - goes straight to the optimized micro-shell, and fail silently. No exception, no stderr warning, no error code, nothing.

Well yes, you could check process return code - but process return code is non-zero not only on errors, but as a generic way for Unix processes to communicate - for example diff will return non-zero if files differ, which is in no way an error condition.

The fix

The optimization should be either fixed or turned off. As a trivial workaround - because the triviality check verifies that string contains none of *?{}[]<>()~&| \ $;'`" or newline, prepending "" in front of the first non-empty character passed system() seems to work well enough. "" evaluates to an empty string in shell.

$ ruby -e 'system "\"\"fail"'
sh: fail: command not found

$ ruby1.9 -e 'system "\"\"fail"'
sh: fail: command not found
$ perl -e 'system "\"\"fail"'
sh: fail: command not found

But seriously, please fix this, okay? Even Python gets it right already.

05 Feb 2010 10:45pm GMT

Capistrano lets you enumerate your Rails application's dependencies so you can check them at deploy time. Mislav Marohnić did a good description of it a while back; here are some example depend entries:

depend :remote, :gem, "tzinfo", ">=0.3.3"
depend :local, :command, "svn"
depend :remote, :directory, "/u/depot/files"

The problem with depend :remote, :gem, though, is that it duplicates the config.gem entries that you already have in config/environment.rb. It'd be much nicer if you could just reuse those.

So, here's some code that you can paste in your deploy.rb to do just that:

# Add dependencies on gems listed in config/environment.rb
class Collecter
 attr_accessor :dependencies
 def initialize
  @dependencies = {}
  File.read(File.join("config", "environment.rb")).split("\n").select {|line| line.match(/^(\s)*config.gem/) }.each do |line|
   self.instance_eval(line)
  end
 end
 def gem(name, args)
  @dependencies[name] = args
  args[:version] = ">=0.0.1" unless args.include?(:version)
 end
 def config
  self
 end
end
Collecter.new.dependencies.each do |name, args|
 depend :remote, :gem, name, args[:version]
end
after "deploy:setup", "deploy:check

This parses your config/environment.rb, extracts the config.gem calls, and evaluates them in the context of an object that gathers up the dependency arguments. Then it declares an after hook for deploy:setup that runs deploy:check, so when you set up the application on a new server it'll ensure that the right stuff is in place.

Here's a sample run from my military reading list app:

$ cap deploy:setup
 * executing `deploy:setup'
 * executing "mkdir -p /var/www/militaryprofessionalreadinglists.com/"
[blah blah blah]
 command finished
 triggering after callbacks for `deploy:setup'
 * executing `deploy:check'
 * executing "test -d /var/www/militaryprofessionalreadinglists.com/releases"
 servers: ["militaryprofessionalreadinglists.com"]
 [militaryprofessionalreadinglists.com] executing command
 command finished
[blah blah blah]
 * executing "gem specification --version '>=0.0.1' mislav-will_paginate 2>&1 | awk 'BEGIN { s = 0 } /^name:/ { s = 1; exit }; END { if(s == 0) exit 1 }'"
 servers: ["militaryprofessionalreadinglists.com"]
 [militaryprofessionalreadinglists.com] executing command
 command finished
You appear to have all necessary dependencies installed

Good times. The nice thing here is that the developer only has to list the dependencies in one place, and the hook ensures that failures are loudly proclaimed during initial setup.

I'm not sure how to integrate this into Capistrano itself; if Lee Hambley or one of the other Capistrano gurus sees this perhaps they can weigh in... thanks!

05 Feb 2010 5:00pm GMT

You thought we were never going to get to this day, didn't you? Ye of little faith. Because here is the first real, public release of Rails 3.0 in the form of a beta package that we've toiled long and hard over.

It's surely not perfect yet, but we were out of blockers on the list, so here we go. Please give it a run around the block, try to update some old applications, try to start some new ones, and report back all the issues you find.

I'm really proud of this moment, actually. We've had more than 250 people help with the release and we've been through almost 4,000 commits since 2.3 to get here. Yet still the new version feels lighter, more agile, and easier to understand. It's a great day to be a Rails developer.

There's plenty to get excited about here. A few of the headliner features are:

• Brand new router with an emphasis on RESTful declarations
• New Action Mailer API modelled after Action Controller (now without the agonizing pain of sending multipart messages!)
• New Active Record chainable query language built on top of relational algebra
• Unobtrusive JavaScript helpers with drivers for Prototype, jQuery, and more coming (end of inline JS)
• Explicit dependency management with Bundler

But please take a look at the full release notes and enjoy the latest!

To install:

gem install tzinfo builder memcache-client rack rack-test rack-mount erubis mail text-format thor bundler i18n
gem install rails --pre

Notes: The first line is required because RubyGems currently can't mix prerelease and regular release gems (someone please fix that!).

05 Feb 2010 3:42am GMT

This is the fourth (and final) article in a series titled "There is no magic, there is only awesome." The first article introduced the four cardinal rules of awesomeness, the second was about knowing thy tools, and the third encouraged you to know thy languages .

First off, I apologize for dragging this out. It's really become a weight on my shoulders. I've been fretting and fretting about writing the last two or three posts in this series, and I just couldn't find the inspiration to make them come out like I wanted…and they've been holding up other posts I've been wanting to write.

So I'm going to cheat. You're going to get a braindump, more or less, of the last two rules of awesomeness. Yes, I am entirely cognizant of the irony here. Nonetheless, here goes.

Rule #3: Know thy libraries!

If you want to be awesome, know your dependencies. At the very least, understand what each plugin, library, and technique you use, does. If called on to explain why you are using a particular design pattern, could you justify it? If someone asked you to compare plugin X and plugin Y, could you explain what their different strengths and weaknesses are? If you discover a particular library behaving erratically, would you be able to dig into the library's guts to tell the author roughly where the problem is? Or would you be one of those who has to tug on the author's sleeve and say, metaphorically, "it hurts when I do this"?

By libraries, I mean (essentially) any bit of code that you depend on, that has a life of its own outside your application. I'm including design patterns in this, although they aren't really code, but they do represent a "library" of possibly ways to architect code. Basically, if you're using someone else's code, algorithms, or techniques, know why you're using them. Make sure you can answer the four questions:

1. What does this do best?
2. What does this do worst?
3. Why should I use this in particular?
4. When was the last time I learned something new about this?

Rule #4: Know thy communities!

The last rule says that if you want to be awesome, you can't do it in a vacuum. By writing code, you automatically join an ecosystem, whether it be a network of coworkers who will help you write, debug, deploy, and maintain that code, or a community of hobbyists who might wish to use your code in applications of their own (or who are writing code that you want to use). Even if all you do is pop up out of your cave long enough to toss some code into the public domain, you're still contributing to a community, and if you're using other people's code, then you're a consumer as well.

Don't be blind to those communities. Stop for a minute and think about the communities you belong to, whether explicitly (where you're a card-carrying, due-paying member) or implicitly (where you're passively consuming someone else's code), or somewhere in-between.

Why is this important? Mostly because communities are resources. Each community will be good for different kinds of help, collaboration, or criticism, and if you want to make the most of those resources (which, if you're really awesome, you will), you need to know where each shines. Again, apply the four questions. What does this community do best? What is it worst at? Why should I participate in this particular community, over all the possible alternatives? And when was the last time I learned from this community?

That last is important, and surprisingly deep. If you are no longer learning from a community, what are you still doing there? Some of you are no doubt saying "but, but, but" and eagerly pointing out that maybe someone is part of a community so that they can lift others up, but note: if you're doing that right, you're still learning from those you teach. You learn new ways that your craft can be confusing to people. You learn new ways of looking at things that you've been taking from granted. You learn new ways to rephrase concepts that have grown stale in your own mind. It keeps you fresh. If you're doing it wrong, though, then the only reason you remain in a community that teaches you nothing is complacency. And complacency is on the opposite end of the excellence spectrum from awesomeness.

Words of caution

So, those are the four rules. There is one overriding caveat to all of this, though, and that is: use moderation. You're not going to master all of this in a day. Or even a week, or month, or year. I don't know anyone that is perfect at all four things (though I know many who are much, much better than I am). To sound all zen and mysterious: awesomeness is a journey, not a destination. Enjoy the trip, appreciate the view, but don't overdo it.

When you overdo it, you risk burning out. I've been riding that line for a couple years now, which was frightening. When writing code is your bread and butter, paying the bills and putting food on the table for you and your family, it is scary to contemplate "what do I do when I suddenly don't want to do what I've been doing". This is a big reason why I had to let go of Capistrano and other projects, and why I've discovered other hobbies (like woodcarving, string figuring, and cooking) that do not involve computers. I'm trying to find the middle ground, so that I can recapture the joy of writing code.

So: be awesome. But only in moderation.

31 Jan 2010 11:42pm GMT

Anyone who follows my exploits will have noticed I'm a tireless proponent of ELPA, the Emacs Lisp Package Archive. As a maintainer of several Elisp libraries, ELPA makes my life easier by helping me sidestep the boring problems of distribution and installation. You may not know that package.el, the software behind ELPA, has been submitted for inclusion in the next version of Emacs. I've taken up the task of getting it ready.

Including something like package.el into Emacs is a big job, and it's something that can only happen gradually. Emacs comes with a number of applications such as Org Mode and Gnus that are developed externally to Emacs and merged periodically into the main Emacs source tree. If they were to be redone as packages they could still be distributed with Emacs builds but kept out of the source tree. They could also be upgraded and installed/removed independently of Emacs' historically long release cycles.

If you've submitted packages to ELPA before, you know it's a process that could use some streamlining. Currently it's all done by email, and packages must be manually uploaded by a single maintainer before they appear to users. This has long been the biggest shortcoming of ELPA. I've written some additions (package-maint.el) that allow you to automate the maintenance of a package source. Basically you provide it with a list of git URLs, and it will check out each tagged version and create a package from it. Of course, that wouldn't be useful without giving clients the ability to get packages from multiple sources at once, which I also added to package.el.

If you maintain any Emacs packages of your own, please try out my changes to package.el. If you use any of my packages, try upgrading and adding my package source to your list.

(add-to-list 'package-archives
             '("technomancy" . "http://repo.technomancy.us/emacs/") t)

That way you'll get access to my updates as soon as they're tagged rather than waiting for them to be manually uploaded, though currently the latest versions of all my packages are in ELPA. Next steps are closer integration with Emacs in order to have packages installable on a system-wide level as well as a per-user level, prerelease version number support, and extraction of some built-in Emacs libraries as packages. Suggestions, bug reports, and patches welcome!

31 Jan 2010 6:10pm GMT

Rails 3 is taking its final shape, so there's no better time to take a close look at the work that's been done in the past year. Join us for a series of talks on everything you'll need to get started with it - from creating a new application, to upgrading from Rails 2, to the foundation that makes it all possible. Attendance is limited, so register now!

30 Jan 2010 1:12am GMT

I got a note from a community member about an annoying problem that a few people have run into when installing activerecord-jdbc-adapter (AR-JDBC) into a C Ruby implementation:

NameError: uninitialized constant
ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::PGconn

Turns out it's pretty easy to momentarily forget to use jruby -S gem or jgem and just gem install activerecord-jdbc-adapter and suddenly your pg Postgres gems are not working properly. I thought it was worth documenting here in case others run into this problem.

I apologize for the clash. I had to provide a stub pg.rb in AR-JDBC inside of JRuby so that I could get active_record/connection_adapters/postgresql_adapter.rb to load with a database adapter type of postgresql. Because of load path order issues, I couldn't get AR-JDBC's code to load before ActiveRecord's. At the time I was thinking this wouldn't be a problem because the pg library won't work on JRuby anyway, right? Wrong.

I can think of a couple options going forward:

1. Submit a patch to ActiveRecord so that active_record/connection_adapters/postgresql_adapter.rb can load without requiring pg up front and then AR-JDBC won't have to stub it out.
2. Display a big fat warning message when AR-JDBC is installed into anything other than JRuby.

Any other thoughts?

28 Jan 2010 3:16pm GMT