GORUCO outdid itself this year. Always the annual networking and social high point of the NYC Ruby Community, this year’s talks and events exceeded my already high expectations. Here’s a recap of some of the goings on:

Friday night, we warmed up with the GORUCO pre-party here at Pivotal Labs. Those who braved the thunderstorms to get here that night were treated to piles of chicken wings, bartenders serving directly from the Pivotal beer fridge where we all usually just help ourselves, a full open bar and some delightful Ruby-flavored conversation. I spoke with someone who had come all the way from India just to come to GORUCO, as well some of the Hungry Academy folks, up here from D.C. as a prize for winning a contest. The lights were turned on by 11pm so we could all be in good form for the long Saturday ahead of us.

Dr. Nic ‘DrNic’ Williams started us off in the morning with a talk about deployment. A key theme that stuck in my mind was to consider how the tools we use affect our thinking. For example, that’s why we don’t build enterprise on-prem versions of our apps.

Matt Wynne was next with his talk on Hexagonal Rails. He guided the way towards breaking down large interconnected Rails apps into modular, easily testable, maintainable components, making many references to Ruby’s SmallTalk roots. Having recently worked on an app with a test suite that took over an hour to run, I clearly felt the pain he was describing and look forward to implementing his recommendations in upcoming projects.

Francis Hwang then took the stage to talk about our ‘Front-End Future’. Thick Clients using Backbone.js, Ember.js and the like are becoming increasingly pervasive, and for good reason: it can make apps so responsive to users that they don’t know they’re using software. He described when using thick clients would or would not make sense. After the talk, there were several good-natured jokes about how much Javascript was being discussed at a Ruby conference, but that was exactly Francis’s point: we can take the great values we’ve built as a Ruby community and continue to apply them even as we’re using Javascript-based tools more and more in our apps.

All that was much food for thought and conversations over lunch. BBQ meat, tortillas and chips, and guacamole were all piled high with the food we got from the aptly named Mexicue. The line snaked through several rooms but moved quick, and while waiting we had a good chat about TDD in startups.

After lunch and later on in the afternoon there were a series of Micro talks: 10-minute talks on Javascript packaging, MacRuby, API caching and high performance caching, and several other topics. I enjoyed the format; the bite-size talks were well-prepared and were just long enough to go into some depth.

Justin Leitgeb had the first full-length talk of the afternoon, all about sensible testing practices, and walked us through a good mnemonic acronym to keep in mind as we write our tests. What’s not to love about CUPID:
C: Consistent Distance (Integration? Don’t stub. Unit? Don’t integrate.)
U: Unstubbed. Don’t stub anything that isn’t yours
P: Pyramidal (the most unit tests at the bottom of the pyramid, some integrated subset tests in the middle, and just a few end to end tests at the top)
I: Idempotent (Always run specs with –random and kiss test pollution goodbye)
D: Distinct.
His talk had many quotable quotes. My favorite was: ‘In a project that I worked on, one single bug caused 124 tests to fail. I was so perplexed I didn’t know which bridge to jump from.’

David Chelimsky’s presentation reminded us that while DRY stands for Don’t Repeat Yourself, it really means ‘Don’t Repeat Yourself’ unless that doesn’t make sense. For example, if you reduce duplication but that creates a new dependency, that increases coupling of things that shouldn’t be coupled and reduces the quality of your code. He also showed a great example where a Rails route file was de-duplicated completely, leaving a completely unreadable mess of CONST1 + CONST2 + CONST3 code on every line.

Jim Weirich gave the last presentation of the day, opening our eyes to the power of what Rake can do for us. For example, Rake has a lot of native support centered around file lists. He showed an example where he kept a set of images in one directory and had Rake create thumbnails for those images in another directory. Rake notices when a file hasn’t changed, so running it a second time skips the thumbnails it’s already built.

Video of all the talks is available, and fellow Pivot Kris Hicks uploaded his photos of the conference. Check ‘em out!

Once the presentations were done, the GORUCO staff donned their sailor hats and we all headed over to Pier 40 to get on board our yacht cruise. Hungry devs and their significant others were talking about the best algorithm to most quickly make their way through the meat, salad, and pasta serving stations on the boat’s 3 floors. The 210′ vessel was brand new; the staff told us we were the first to spill our drinks on the carpet! The top-shelf open bar was well-provisioned and it’s not surprising that when the very eclectic soundtrack started playing Adele’s ‘Someone Like You’, a large group got an early start to the evening’s karaoke by screaming it at the top of their lungs. I saw the video, but it was deemed too hot for this blog post.

We had great conversations on that boat, technical and otherwise. I spent a bunch of time hanging out with a large group of dev leads from NYC’s hottest startups. One guy was telling me about a day-long pairing exercise that can expand our horizons. Can’t wait to try it!

The boat ride ended with a pass by the Statue of Liberty, directly below a huge fireworks display. The warm night and close view was perfection.

After we returned to Pier 40 and disembarked, many folks headed over to Karaoke Cave in the Village to sing until the wee hours. I couldn’t make it, but I heard that it was very fun and memorable. So much so that the people I spoke with couldn’t remember some of it! But apparently, Dr. Nic can really hold a tune.

Thanks again to the GORUCO organizers for putting together such a great event. Looking forward to next year!

It’s the first Wednesday of the month again, and that means it’s time for the Pivotal Labs/Outside.In monthly Ruby Happy Hour. It’s the first one since GoRuCo, so there’s even more to talk about than usual. (Thanks Josh, Francis, and everyone else who made this a great conference again this year.)

Where: Outside.in, 20 Jay St Suite 1019 (10th Fl), Brooklyn, NY
When: 7-9PM today, Wednesday June 3rd
Who: If you’re a developer who uses Ruby and would like to meet some other Ruby folks, toss around ideas, or just have a few beers, we welcome you with open arms!

There will be pizza, beer, and great discussions for everyone. More details on the Outside.In Blog, and please RSVP if you can, so we know how much pizza to get.

Yehuda’s GoRuCo talk was on the subject of Rails as a Ruby citizen – that while Rails was already a pretty good Ruby Citizen with 2.3, 3.0 is about making it a better citizen.

Who is the Rails Developer?

Many are building apps on top of Rails, not considering making an extension, just building on what’s available. Others are building extensions full-time. In the vast many are power users working on long-term projects, building apps primarily, but in the course of it making tweaks and extensions to Rails.

What Does it mean to be a Ruby Citizen?

Rails is built on many other Ruby libraries: Rack, Test::Unit, Erb (soon to be replaced with Erubis).

Other libraries use Rails as a library, e.g Spree, ActiveMerchant, Radiant, Sproutcore.

Also, Rails works with other libraries, and can be optionally used with them, for example as in the case of Haml.

Rack as an example of the benefits of Citizenry

Prior to Rack, frameworks would right special handlers for each of its interfaces, with all sorts of attendant inconsistencies. Rack, when introduced, seemed to solve this problem, and so was incorporated into Merb.

But Rack is actually much more than this. It enables you to write Middleware, which is components of code integrated to the generic Rack interface. This enables functionality to be consolidated into single-purpose middleware components, with all other components remaining ignorant of the others.

In Rails 2.3, they applied Rack to Rails, making each controller a middleware endpoint selected by the router, which was another middleware component.

But good Rack endpoints don’t do dispatching, they just pass-through one-to-one. So in 3.0, the router will point at a specific action.

Middleware

As with ruby libraries in general, Rails is a citizen in the Rack ecosystem, using Rack, working with other Middleware, and providing its own which is then used in other frameworks.

To this end, Rails 3.0 will split out things like rescuing, params parsing and session handling into middleware which is then usable downstream without pulling in all of Rails.

In Rails you can use middleware via “config.middleware.use Foo”

Integration Tests

By generalizing Rails via Rack, Rails is able to use generalized Integration testing by simply treating Integration test as a Server which issues commands to the Rails stack via the standard Rack interface. Already Rails 3.0 works with rack-test.

ORM Agnosticism

Why does ORM agnosticism matter? ActiveRecord is Ruby, DataMapper is Ruby, one should be able to just require the alternative and use the library.

But Rails has dependencies on the ORM, for example in the form_for helper, which works for a specific interface.

Merb 1.0 offered “Agnosticism” by offering 2 interfaces, one for ActiveRecord, one for DataMapper. If you wanted to work with merb, you had to offer one of those interfaces, as CouchDB did.

To provide a general solution, Rails needs to provide a standard abstract interface which anyone can implement in order to interface with Rails.

One can meet this interface by:

1. Complying, either with a direct interface on your object or a shim that provides the interface.
2. Proxy, which maps your object’s interface to the expected one.

Javascript

Rails remote_form_for looks pretty in the template, but generates a bunch of Prototype-specific javascript code. But Rails would like to provide better support for jRails, which implements the Rails javascript helpers in a jQuery equivalent.

The solution is to emit markup rather than javascript, which the respective javascript libraries then bind to, via event delegation.

Rails will ship with the prototype version of this, Yehuda is planning to write the jQuery equivalent, Mootools and others will provide their equivalents as well.

You’re also able to bind to this markup in Javascript as well, providing your own alternative to jQuery, Mootools, &c. bindings.

Filters

In Rails 2.3, simple actions would spend 20% of their time in filters. Filters are important in small applications which do a lot of traffic and performance-intensive apps.

Historically, parts of Rails filters (Before, After, Conditions) had been factored out into ActiveSupport, but Around filters and skipping were more difficult to filter out, and so hadn’t been. Rails 3.0 integrates all the rails filtering in a performant way.

In 2.3, Rails asks the filter a bunch of questions, even if it’s a simple filter, which you’d expect to be fast, then sends. This checking is runtime, when all the necessary information is available in advance.

Rails 3.0 uses metaprogramming to compile the various filters down into a single method which is simple and quick.

Abstract Controller

Action Mailer and Action Controller had diverged and require separate implementations on many fronts. The better way is to call use modules to attach functionality to either class, from a common base. It uses super to iterate over each modules implementation in order.

The result is a bunch of layers doing a single thing, taking and producing normalized data. You can remix and insert your own equivalents.

In Rails 3.0 one can set _action_view method with a renderer object which then implements alternatives to or extensions on the Rails action_view helpers.

FastController

Equivalent to ActionController, with expensive modules excluded, to which you can attach your own functionality.

On of Yehuda’s goals: “How easy would it be to implement Sinatra on top of Rails?”

Likewise, how can Rails be made such that it’s functionality is more available to other projects such as CloudKit.

Q & A

In Q & A, Yehuda notes that in Rails you can get away without knowing too much about inheritance and subclassing, while “more crazy” languages force you to know this. He hopes that Rails 3.0 will bring more awareness of this to Ruby.

Ben Stein of Mobile Commons is giving a talk on Cross-platform Mobile App development. They hadn’t done any client mobile work, but lately clients have been asking “what about iPhone?,” “what about Android?” and the like. Whether or not this question of navigating the mobile client world is important to you now, Ben predicts it will soon be, as that’s where we’re headed.

Thoughts and experiences from Mobile Commons’ first mobile client apps:

Why Mobile?

Mobile give you capabilities not available elsewhere:

• Location
• Accelerometer & Orientation
• Phone & Contacts
• Camera
• Sound & Vibrate

This is a big list – serious stuff.

Uncool things about mobile

• Unreliable network connectivity
• Java, Objective-C
• Memory Management

Options for mobile

• Maybe your Rails Web app is good enough
• A mobile-formatted version of the web site
• A client app

Mobile-formatted sites

• alternate stylesheets
• separate mobile subdomain
• WURFL

Mobile-formatted cons

• No cool mobile features
• No app store distribution
  ** have to bookmark, no $$

iui, iPhone, Rails

• iui & rails-iui: gives you stylesheet and typical iPhone ajaxy interaction
• acts_as_iphone_controller
• index.iphone.erb
• Mime::Type.register ‘text/html’, :iphone

Native Apps

• Rich User experience
• Cool device features
• App store distributions

Native Apps: Cons

• New technologies
• Different technologies
• Frameworks to learn

“There are only so many hours in the day to learn new technologies.”

Alternative Tech Stack

• Webkit rendering engine (HTML/CSS)
• Business logic in web application
• Javascript for mobile features
  (accelerometer, location, phone, &c.)
• HTML5 Client-Side Storage (SQLite + JS)

This Javascript interface to phone features potentially allows consistent behavior across many devices. And hybrid we apps can serve double-duty, doing work both on and offline.

HTML 5

• Proposed 6 years ago, working group started in 2007. Implementations emerging, particularly in Webkit, which is the common mobile renderer.

Features:

• Canvas
• Video Tag
• Geolocation
• Web Workers (i.e. Javascript Threads)
• Client-side Storage
• and more…

3 Types of Storage

• Structured Storage
• AppCache
• Client Database

sessionStorage and localStorage are shared Javascript Hashes available across all your pages.

HTML5: App Cache

Also defines a mechanism for enabling intelligent client-side caching.

HTML5: Databases

• Defines an interface for client-side databases
• Javascript & SQLite Implementations

Ben then demos a sticky-note app which works currently in Safari, and works with client-side persistent storage.

Security & Privacy

This makes cookie resurrection easy, so the designers include a same-domain policy in the spec, to reduce access.

GMail on the iPhone

Currently uses the app-cache and asynchronous updates to enable offline access.

PhoneGap

• Open-source Project by Nitobi
• Javascript library + native code
• Enables a common javascript interface to phone features

XUI Javascript Library

jQuery minus all the browser compatibility code, optimized for Webkit & Mobile phones.

HttpClient.app

Don’t use Curl to test these apps, use HttpClient, which deals with much of the basics, including authentication

Demo App

Mobile Commons has made an application for allowing individuals to receive messages including a link to immediately phone their representatives. This uses Mobile Commons’ legislative district database, and other phone features including location and client-side caching, accessed via Javascript.

The phone number is linked with the a ‘tel:// ‘ URI which then allows initiating a call from within the phone.

These projects can be built and managed out of eclipse for Android and XCode for iPhone.

Downsides

• Apps don’t quite feel native. A bit slower, not quite as polished.
• Not good for graphics, games, &c.
• App store policies? Reports that some apps have been rejected for using these frameworks.

What’s Next?

• HTML5 spec not yet finalized
• Tons of fun work to add HTML5 functionality to Rails

Q & A

What about Migrations?

There’s no easy answer, this is one of the reasons we switched to Web development, because we have more control and the easy ability to push updates. Client migration support is also theoretically possible, but has yet to be implemented.

Sandi Metz, a Dukie visiting from NC, will be talking about SOLID principles of software development:

• Single Responsibility
• Open Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion

All of Sandi’s code is available here.

Change

Fact: your application is going to change. How will your application handle that change?

Robert Martin says your app can behave a couple of different ways:

• Rigid: Making a change somewhere will break something somewhere else.
• Fragile: You can’t predict where that break will be.
• Immobile: It’s hard to change your code.
• Viscous: It’s easier to do the wrong thing than to fix things.

In the beginning, though, your app was perfect. “Dependencies are killing you!”

Design might save you.

The Design Stamina Hypothesis says that, after a certain point, you’ll have done better if you had designed first.

“Skip design, if you want your app to fail.”

To avoid dependencies, your design should be:

• Loosely coupled
• Highly cohesive
• Easily composable
• Context independent

Ignorable Rules

SOLID principles we can ignore in ruby:

• Interface Segregation

  Really only a problem for statically-typed, compiled languages. Because we’re in Ruby, we don’t have this problem! Win!

  “Dynamic languages obey this rule in the most extreme way possible: duck typing.”

• Liskov Substitution

  When you design, don’t break the contract of the superclass in the subclass.

Testing Interlude

Sandi draws her examples of applicatoin change from the source code at: http://skmetz.home.mindspring.com/img28.html.

Lesson #1: Resistance is a Resource.

• Don’t be attached to your first idea
• Embrace the friction
• Fix the problem

If testing seems hard, examine your design. Tests depend upon the design of the code. “TDD will punish you if you don’t understand design.”

During refactoring, ask yourself:

1. Is it DRY?
2. Does it have one responsibility?
3. Does everything in it change at the same time?
4. Does it depend on things that change less often than it does?

The answers should all be ‘yes’.

Important Rules

Sandi references her code to demonstrate when and how to mock and use dependency injection to achieve Single Responsibility, in which a class both downloads and acts upon the downloaded data.

She urges developers to do the simplest possible refactoring when extracting responsibilities from a class.

“Refactor, not because you know the abstraction, but because you want to find it.”

Sandi uses a very interesting example of building a Config class which behaves differently in different Rails environments. The first version had a lot of smell, and with a combination of hash parameters, YAML file, and metaprogamming, she demonstrates how to be open for extension, but closed for modification.

Sandi explains that paying attention to your classes’ dependencies is important. If a relatively static class is dependent on a class that changes more often, that’s a smell! Use dependency injection to avoid Dependency Inversion.

Summary

“TDD, BDD and DRY are all good, but they are not enough.”

“Design because you expect your app to succeed, and the future to come.”

Sandi recommends reading:

• http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
• http://www.mockobjects.com/book

Jake Howerton gave a GoRuCo talk about Rails Anti-Patterns, drawn from his years as a rails developer.

Over lunch with Jake, I’d wondered aloud “where are all the wide-eyed optimistic presentations?” and Jake starts by saying he’s sorry that this will not be one of those talks.

We’ve been programming in Rails for several years now, and now more than ever we’re left with the problem of how to deal with, maintain and correct projects which may be riddled with out-dated thinking, mistaken ideas and problematic implementations.

In other skilled enterprises there are core ideas which are repeated by for practice and for their general utility. In martial arts, these are called “katas,” in programming, we have “patterns.” Patterns are general, reusable solutions to common problems in software engineering, which are often arrived at through emergent design. Anti-patterns, likewise, emerge in the general work on a project, but their presence is harmful. They’re the mistakes we make again and again in our projects.

Jake then laid out a few patterns and anti-patterns for your consideration:

1. Know your APIs

Some of the most egregious anti-patterns come from simple ignorance about the APIs available, and the consequential re-implementation of basic Ruby or Rails functionality. The Rails and Ruby APIs are both well-documented and important to your work. There’s no excuse not to know them.

2. script/plugin and gem installitus

While we must install a plugin or gem to use it, often we move on without doing the important job of cleaning up after ourselves.

3. Style

• if not self.value.nil?

People litter ‘self’ all over the place. The only place you need self is on assignment. And all this could be replaced with the simple line:

if value

• @value = 600 if @value.nil?

@value ||= 600

• some_value == nil?

What does this even mean? ‘nil?’ is false unless inside NilClass

• IRB-driven Design

Occasionally we hack away in IRB and, once we get the results we’re looking for, drop the code into our app without a second thought. This can produce some very buggy, obtuse, far-from-minimal code. Once we discover a mechanism, better to revisit the problem and produce the code in a more stable context.

• !!value

Confusing. Not to be used outside of a predicate method.

4. Planning is Hard

Will you remember what your boss tells you to do a year ago? Will you unknowingly violate these past decisions and understandings? To avoid doing so it’s important to maintain active specs against your app.

Jake recommends Cucumber + Webrat for carrying this out.

5. How Bad Is It?

There’s a gem called metric_fu, a gem full of analytics. One in particular is known as Reek, which sniffs out code smells.

Run reek against your app, and it will find long methods, for example, and return all of the methods that are longer than 5 lines. And you can make your tests fail on the existence of these methods, to keep yourself and your team in check.

6. Orphans

Orphans are methods, models, views or controllers, or any other bit of functionality which is disconnected from the rest of your app. Like un-used plugins or gems, orphan code is noise which keeps your code from being easily maintainable.

7. (Dis)Organization

We can look to the more modular, merb-style project organization as a way of better structuring our projects. Likewise the Fat-model, Thin-controller design pattern helps us to create easily-testable, well-organized apps.

8. Testing!

• The valueless test

assert_equal 2, User.count

This test fixtures, and activerecord, and its very presence hinders us by interfering with our view of more meaningful tests.

• The slow test

Any slow test has a cost of both slowing the testing feedback loop and making it less likely that we’ll run the tests as often as we should.

• The coupled test

Coupled tests mean that a test depends on the side-effects of other tests, or on the effects of an outside service or application. Instead we can mock out the outside web service or operation

• Complex tests mean complex code

9. Make Decisions and Document Them

Discuss your code conventions and style with the team, settle on a set of best practices, and write them down. Store them in a style guide in the project root or document directory.

10. Continuous Integration

Jake recommends using Integrity Continuous Integration Server. Whether you use that or Cruise Control, or any other option, continuos integration insures your specs and tests are frequently and consistently run.

11. Build Artifacts

Generating and maintaining build artifacts, such as statistics reports from your reek run or performance tests can enable you to track your progress over time. In addition, you put minimal expectations on these

12. Reviews and Retrospectives

Taking time every few months to review your recent progress, and discuss problems and progress.

Q & A

Someone mentions a particularly egregious example of a test which deleted its own application code in the process of running.

Jake responds that in cases where tmp deletion and file generation, it may be appropriate to have a safe version of the test which runs locally, and a separate exhaustive test which runs in a sandbox staging environment. This allows you to exercise the more dangerous tests in a safe environment.

Yehuda mentions one way to do this is to mock in the safe version, and turn of that mock in the sandbox environment.

Egregious Code

Jake then shows a 45-line login method and points out how difficult it is to immediately grok. Newer-code built in the REST-ful style is much simpler to work with.

Conclusion

By discussing these approaches with old-hands and newbies alike, we can all improve the quality of our code, spend less time dealing with bugs or code comprehension, and more time building out the next great Rails projects.

Dan Yoder is the Director of Development at ATTi R&D, and will be talking about Waves, a Ruby architectural framework for developing RESTful apps.

A Brief History

Ruby web development came of age with MVC and Rails. Later, people who didn’t need a full MVC invented Sinatra and other frameworkes. Which brings us to today, and …

Waves Introduction

Waves can do simple apps in just a few lines of code. And by using “foundations”, developers can build more advanced apps with MVC-like functionality. You can build your own foundation for whatever web framework you envision (there are several for MVC and REST).

Waves supports rack::cache and JRuby. It’s Actually In Production(tm)!

Web as Services

As more rich browser apps use AJAX and COMET, server-side APIs are becoming more important. This is where REST shines.

“HTTP isn’t MVC, but our frameworks think in MVC.”

REST and ROA

“REST” shouldn’t be applied to things that are “REST-influenced” (just ask Roy). Dan likes to use “Resource-Oriented” for these situations.

HTTP-based ROA uses the existing infrastructure, and has proven scalability. HTTP defines a protocol for a distributed hash table:

• put(key, value)
• get(key)
• delete(key)

Q: “What about post?” A: “Post is for ‘everything else’.” Some things aren’t clearly RESTful, and post is the catch-all for other operations.

What’s in the hash? Resources, and keys are the URIs.

What’s the point? Platform-neutral distributed objects! RDF can be used to describe discoverable resources.

ROA in action: rss/atom. It’s one link to a resource describing your blog. “Boom! Podcasts for free.” Dan describes this as the law of “unintended consequences,” in a good way.

Edge caching is another big win for HTTP-based ROA.

How Does Waves Help?

Waves makes it easier to write resourceful applications like this today. New foundations will make it even easier going forward.

You can check out Waves at http://rubywaves.com, and on their Google Group.

Eleanor McHugh, a physicist by training, will be talking about how to make *nix systems work naturally within the Ruby environment.

The Unix Way

Eleanor actually hates Unix, but recognizes that it’s a very effective operating system for getting things done. It’s DRY: build little things, build them well, don’t build them twice. There’s a natural marriage between agile Ruby and the Unix philosophy.

Unix provides basic services which make it a very useful OS to “muck about with”:

• virtual memory
• process management
• hierarchical file system
• user permissions
• interprocess communication

Ruby provides some “really lovely” utilities:

• Kernel.system
• Kernel.spawn
• IO.popen
• Open3.popen3

However, if you’re doing a lot of IO, you end up doing a lot of select()s and keeping a lot of file descriptors open.

System Calls with Ruby DL

DL, which Ruby delivers out of the box, is a way to wrap a C library with a Ruby call. This is a nice way to access the underlying kernel system calls without relying on the Ruby IO implementations.

This is superior to Ruby’s syscall, in that you can actually get results back from the function call.

Using mmap allows you to do much faster memory reads, rather than do slower file reads.

Using kqueue/epoll/inotify allows you to build evented ruby (like EventMachine, but without EventMachine).

Using pipes allows you to build efficient IPC.

The drawback is that using DL means more verbose code, and more error prone code. (Pointer math FTL!) So, for things like sockets, use the Ruby API unless you specifically need kernel-level eventing.

Multicore

The lack of real thread support in Ruby can be addressed by using multiple processes, held together with IPC (sockets, pipes, memory mapped files). This is the traditional “Unix way” for handling multiple processes.

Gregory Brown is the creator of Ruport and Prawn, and the author of the upcoming Ruby Best Practices. He’ll be talking about the various-and-sundry Ruby implementations.

Moving to 1.9

On Ruby 1.8, strings are sequences of bytes. On Ruby 1.9, strings are proper characters (not bytes!). Even if your app only speaks “American”, you still need to be aware of this to handle data properly. Plus, some of the new syntax in 1.9 is not backwards compatible with 1.8.

Recommended steps for upgrading from 1.8 to 1.9:

1. make sure you have good test coverage!
2. make sure your test are checking the output (some end-result validation)
3. run on 1.9
4. hammer on your code until the tests pass
5. decide whether to continue to support 1.8

Prawn only officially supports 1.8.6 and 1.9.1 to make life easier, but if support more versions is necessary for your project, check out ZenTest’s multiruby features.

Greg recommends using conditional-execution blocks to make version-dependent code look nicer:

if RUBY_VERSION < "1.9"
 def ruby18
   yield
 end
else
 def ruby18
 end
end

Greg opines that moving to Ruby 1.9 is not a magic bullet, but has lots of advantages, so try it out!

Ruby 1.8.7

Ruby 1.8.6 is a workhorse (insert image of beat-up pickup truck). Ruby 1.9 is a Lamborghini (we think). “What the hell is 1.8.7?”

Answer: 1.8.7′s patch set is largely 1.9 backports. It’s a platypus!

However, this doesn’t mean that code written for 1.9 will magically work on 1.8.7. Or that code written for 1.8.7 will work on 1.8.6.

What should authors be doing? Should we release for 1.8.6 or 1.8.7? Greg recommends releasing for 1.9, especially if you’re writing a Ruby book (wink wink).

Peanut Gallery

Eric Hodel (maintainer of Rubygems), is planning on dropping 1.8.6 support within the next year, but continuing support for 1.8.7 and 1.9.

Writing Extensions

FFI (Foreign Function Interface) is supported “all over the place”, and is an alternative to writing a C extension. FFI works across implementations (JRuby, Rubinius, and MRI).

On Windows, Greg proclaims that JRuby is the easiest way to wrap a C library. “WTF?”

Oversimplified Explanations of Ruby Variations

According to Greg. (Not all of the nuance may be captured here, since Greg was moving pretty quickly. Blame me, not him.)

• 1.8.6 is ubiquitous, and may be slowing adoption of other, better interpreters.
• YARV (1.9) is faster than Matz’s implementation and is the only complete m17n implementation of Ruby.
• Ruby Enterprise has a great installer!
• JRuby is great and new, but requires C extensions to be rewritten
• Rubinius is what created the RubySpec project and FFI, and is very innovative.
• MacRuby is, um, Ruby for Macs.

Good morning! Today Ben Woosley and I will be live-blogging what’s going on during Goruco at Pace University.

You can check out some photos of the conference.