Jim Lindley Notes

Rails 2.1 is almost here, and there are two great resources for learning about it:

Ryan Daigle’s ‘What’s New In Edge Rails’, and Rails contrubutor Chu Yeow’s series: ‘Living on the Edge of Rails’.

Lots of fun stuff for this point release!

And if so, can you help me kick some tires? I've done some work on adding features to the Accessible Form Builder plugin to help use Blueprint grid css classes. It was extracted partially from work done on a a Rails project for Academic Management, my awesome employer.

Accessible Form Builder on GitHub.

I'll be fixing up a few last minute issues with it over the weekend, but it should be fairly beta-ishly usable in it's current state, and I'll publish a tutorial/guide shortly.

This is what it gets you (screenshot):

From this sort of markup (screenshot, sorry - code sample are with the plugin on GitHub):

Let me know: good or wack? What's missing? I'll be at Mountain West Ruby Conf and Rails Conf, say hello if you see me or if you find this plugin useful.

My email address is jim@jimlindley.com for any questions or comments.

The canonical git-svn workflow that I’ve seen goes like this:

git svn clone <svn_repo>
git checkout -b <work_branch>
    ...hack...hack...
git commit -a
git checkout master
git svn rebase
git merge <work_branch>  #NOTE: no need for --squash anymore
git svn dcommit -e  # -e will let you enter a commit message for SVN

I’ve had more luck with the following workflow, when integrating changes via SVN from other team members:

# initial setup
git svn clone <svn_repo>

# 99% of daily workflow
git checkout -b <work_branch>
    ...hack...hack...
git commit -a

# switch back to master, then rebase against
# any revisions in the svn repo
git checkout master
git svn rebase

# now that master is current with svn,
# sync working branch to local master
git checkout <work_branch> # These two are the added steps
git rebase master          # which help prevent conflicts

# final upstream commit after rebasing
git checkout master
git svn rebase # one last check for new svn check ins
git merge <work_branch>
git svn dcommit -e

The extra rebase step seems to do a better job of integrating your patches into the tree. Merge should do the same thing, if I’m reading the man pages right, but splitting the steps is more idiot proof (me-proof) this way.

It also keeps the master local branch from getting messy dealing with conflicts. Instead conflict is kept in the side working branch.

Apple has just released a development version of MacRuby, Ruby 1.9 built on top of Objective-C. This is very interesting, and is only the second ever Apple language that will have Cocoa support built in from the ground up.

Also, it includes keyword argument support, something missing from current Ruby implementations. It will be interesting to see if this is the first alternate Ruby implementation that will truly fork from the C-based Ruby language. I really hope that it doesn’t end up becoming so.

I’d recommend modifying the Apple installation instructions (adding a directory in your home folder, and then just editing the configure line), like so:

mkdir -p ~/macruby
./configure --enable-shared \
            --prefix=/Users/[username]/macruby \
            --program-prefix=mac

That way ‘ruby’ still points to the current production quality Ruby 1.8.6 installed with Leopard, no gem folders are stepped on, and you can access MacRuby via ‘macruby’, ‘macirb’, etc, if you add the macruby’s bin folder to your path.

I’ve been out sick this week, please forgive me if I’ve been out of touch. Hoping to catch up next week, but if you called or emailed in the last couple weeks please try again next week.

[UPDATE: I’ve been terribly sick the last week so this series is delayed a bit, sorry!]

In January I’ll be running a series of posts – one each weekday – highlighting a new feature or change in Ruby 1.9, which had a developer release on Christmas Day. While Ruby 1.9 should not yet be used in production, it is now the perfect time to install it alongside 1.8 and get your hands dirty.

Getting Ruby 1.9

On a Linux/Unix/Mac installation should be straightforward if you are used to compiling packages.

Download:

mkdir ~/src
cd ~/src  
wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-0.tar.gz
# or curl -O ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-0.tar.gz
tar xzvf ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-0.tar.gz

Install:

cd ruby1.9.0-0
autoconf
./configure --prefix=/usr/local --program-suffix=19
make
sudo make install

Now in addition to ruby, irb, and ri you should have available to you ruby19, irb19, and ri19.

Start up irb19 and check the ruby version:

jlindley$ irb19
>> RUBY_VERSION
=> "1.9.0"

Don’t expect to be able to run Rails and all your usual programs as normal, there is still a lot of work going on updating Rails and other gems to be 1.9 compatible. This release breaks some old things, but going forward 2.0 and further should all be compatible with 1.9. This is the painful release.

So, install 1.9 and check back on January 1st for the first entry in this series. In the meantime, a summary of changes in 1.9 can (sometimes) be found at Eigenclass.org.

Series Index

This section will be updated with links as the month progresses, but an outline of topics is:

Week 1

• Jan 1 – Deprecations and Porting Concerns
• Jan 2 – RubyGems
• Jan 3 – Rake

[UPDATE: I’ve been terribly sick the last week so this series is delayed a bit, sorry!]

If you’ve got Ruby 1.9 installed, you’ve also got the RubyGems package management system installed. It’s been moved into the core distribution, with an eye towards repackaging the standard libraries as gems (but still included by default) to allow for a more manageable development process.

Gems aren’t loaded and don’t take up memory until you require them. You no longer need to require gem itself before asking to load a gem.

>> VERSION
=> "1.8.6"
>> require 'rake'
  LoadError: no such file to load -- rake
>> require 'rubygems'
=> true
>> require 'rake'
=> true

But now with 1.9:

>> RUBY_VERSION
=> "1.9.0"
>> require 'rake'
=> true

Most gems are not updated yet for 1.9 compatibility, check before using any. Gems now are supposed to include a Ruby compatibility identifier. If you come across a gem without one it’s pretty safe to say that it won’t work on 1.9.

This list is not exhaustive, but does cover the issues I’ve had in a first pass at porting my code to 1.9. For instructions on installing Ruby 1.9, please see the introduction to this series of posts. As a reminder, do not use 1.9 for production systems yet.

Ennumerable#zip

Ruby 1.8 allowed padding of zipped lists with nil, and returned the result as a new array:

>> VERSION
=> "1.8.6"
>> [1,2,3].zip(['a','b'])
=> [[1, "a"], [2, "b"], [3, nil]]

In 1.9 zip returns an enumberable object and does not pad short collections. It will blow up once you run out of matching items:

>> RUBY_VERSION
=> "1.9.0"
>> [1,2,3].zip(['a','b'])
=> #<Enumerable::Enumerator:0x3b48e0>
>> e = [1,2,3].zip(['a','b'])
=> #<Enumerable::Enumerator:0x3b01c8>
>> e.next
=> [1, "a"]
>> e.next
=> [2, "b"]
>> e.next
StopIteration: iteration reached at end
    from (irb):5:in `next'

Use Hash#key instead of Hash#index:

>> my_list = {:foo => "bar"}
=> {:foo=>"bar"}
>> my_list.index("bar")
(irb):18: warning: Hash#index is deprecated; use Hash#key
=> :foo
>> my_list.key("bar")
=> :foo

File.exists?(filename) is dead. Use File.exist?(filename) – singular – instead.

Base64 is gone.

>> require "base64"
LoadError: no such file to load -- base64
    from (irb):16:in `require'

No keyed array literals using commas:

>> VERSION
=> "1.8.6"
>> {1,2}
=> {1=>2}

>> RUBY_VERSION
=> "1.9.0"
>> {1,2}
SyntaxError: (irb):10: syntax error, unexpected ',', expecting tASSOC

String#[] returns a character, not a character number.

>> VERSION
=> "1.8.6"
>> "abcde"[0]
=> 97

>> RUBY_VERSION
=> "1.9.0"
>> "abcde"[0]
=> "a"

And finally, VERSION is removed in favor of RUBY_VERSION.

>> VERSION
NameError: uninitialized constant VERSION
  from (irb):1
  ...
  from /usr/local/bin/irb19:13:in `<main>'
>> RUBY_VERSION
=> "1.9.0"

If you do any layout or design work, and are self-taught (like too many of us web developers), you owe it to yourself to check out this book. Read on to find out why.

The Elements of Typographic Style

This book is full of practical tips on making it easier for users, I mean readers, to peruse your site. I’ll give a few examples, but even more then the tips, understanding why words are put down to page and screen as they are is a subject deeper then I’d ever thought. The author makes a point that the more limited your choices, the more important the choices that remain are. In an environment like the web, with its handful of fonts and poor resolution, the remaining elements of typography under your control become all the more important. If you don’t get the spacing and layout right, and handled with care, you’ve blown past the only control you ever have.

I’ll give a few examples, from just the first couple chapters (the book goes into much greater detail and into many other subjects):

Headings: A simple thing, but the book suggests only increasing one variable when making headings, or levels of headings. So if your text is 14px, either increase the size for the heading, to say 18px, or make the type bold but the same size. And each level of additional headings gets the same treatment. No need to jump from 12px plain to 24px bold underlined italic in one go.

Color: not like orange or blue, but instead how dark a gray the text appears, if you average the black and white together. The thicker, more condensed and less space between letters and lines, the darker the color. Keeping on eye on this helps to make the page seemed balanced. If your main text and your sidebar appear similar in color, despite being different sizes and styled differently, then the page will seem in harmony.

Leading/line-height/x-height/etc: A very thorough coverage of spacing of elements. Many of these CSS properties I’d tweak to try to intuitively find something that looked good, but now I know the traditional proportions and methods for choosing them consciously. I see a great reduction in trial and error already.

The only bad thing about reading this book is that I want to redo the typography on half the sites I’ve ever put together, including this one. It’s like suddenly becoming a carpenter and seeing how unlevel that porch is that never used to bother you.

If you are in Upstate NY, consider checking out the WNY Ruby User Group. Our next meeting is going to be held on January 7th.

Ruby Rags, themed t-shirts. I bought this one:

The videos of the Ruby Conf 2007 sessions are up, come of the best to check out are:

• Evan Phoenix on Rubinius
• Eric Hodel on Maximizing Productivity
• Aaron Bedra on ‘Sploiting with Ruby

Unfortunately, only part of the most memorable session at Ruby Conf 2007 - Hurting Code for Fun and Profit by Ryan Davis - was recorded.

Just saw it was tagged in the Rails dev subversion repository. Long time coming but definitely worth it, I’ve been running on edge for 6 months now and Rails 1.2 is hard to go back to when I need to work on older projects.

Official announcement and an overview of changes.

Rails 2.0 Installation

The actual release version is 2.0.1, 2.0.0 had a small issue. EDIT 12/16: the latest version is now 2.0.2. To install it as a gem:

sudo gem install rails

Or inside an existing Rails project:

rake rails:freeze:edge TAG=rel_2-0-2

rake rails:update

Online Resources:

• Rails change log (will be slow today, it’s on the main dev site)
• New Feature Overview
• Free screen casts on Rails 2.0
• Ryan Daigle’s edge Rails posts
• Rails 2.0 PDF ($9)
• Foxy Fixtures (managing inter-related fixtures just got easier)
• Handling deprecations when upgrading to Rails 2.0
• Prototype 1.6C Changes
• Scriptaculous 1.8 Changes

Books with Rails 2 content:

• Prototype and Scriptaculous book ($20 pdf)
• Advanced Rails Recipes ($20 pdf)

It looks like we are a week away from the actual 2.0 release, you can check out the preview release by pulling from the gem from the Rails dev server, or freezing to edge in your project like so:

rake rails:freeze:edge TAG=rel_2-0-0_RC2

Remember, upgrade to the latest version of 1.2.x (1.2.6 at the moment), and check for any deprecation warnings before trying to run 2.0, unless you’ve been running on edge lately.

This release candidate contains many bug fixes but minimal new features over the last release candidate.

Ruby on Rails Security has a great article on cookie-based session storage. This is the default for Rails 2.0, and if you generate a new Rails app it will create a very long random string to use for hashing the cookie to prevent tampering. This seems to be fairly secure, although it’s always safest to switch to a server based session storage mechanism.

If you are converting your pre-2.0 app to use cookie based sessions, you must be careful to pick a very good secret for the hashing function. And ‘good’ means computer generated, very long, very random, and no dictionary words. Rails will now prevent you from using a secret less then 30 characters long.

If you are only storing a minimal amount of information in the session (such as a user id and flash message), cookie session store is an awesome win. Otherwise, you’re probably using it wrong: no sensitive information should be placed in session, and if you need to expire sessions, you must place an expiration time in the session and check that per request and decide if you’ll accept it still.

UPDATE: More info on cooke session store security.