I was recently reading Martin Fowler's Refactoring. While I was reading Introduce Local Extension (p. 164) all I could think of was how simple it is to implement in Ruby.
As Fowler says in the motivation section writers of classes and libraries are not omniscient. Inevitably some class that you're using will be missing some feature you want. Using Introduce Local Extension you can add that additional functionality when you need it.
In a statically typed language, like Java, this refactoring would involve creating either a wrapping class or a descendent of the original class. In Ruby we will accomplish the same thing using a mixin.
There are a decent number of books out there on Ruby. In my mind I consider Chapter 11 of The Ruby Way, 2nd Edition the most important chapter you can read. Here's why.
Mastery in Ruby involves moving past regular programming and embracing the dynamic features of the language. The dynamic nature of Ruby goes far beyond dynamic typing. Frequently programmers coming to Ruby from languages like Java, C++/C#, PHP, VB.Net, and other statically and dynamically typed languages think that dynamic typing is the extent of what is dynamic about Ruby[1]. Chapter 11 of The Ruby Way will greatly disabuse them of this notion and put them on the pathway to Ruby mastery.
After reading The power of JRuby and the discussion that ensued I was inspired to write about why I chose Ruby and particularly JRuby as my company's primary development platform.
I didn't write this post as a knock on Groovy. If it wasn't for Groovy I doubt I'd be working in Ruby today. For me Groovy was my "gate-way drug" into the dynamic language realm. My reason for this post is to explain why someone might want to use Ruby on the JVM over Groovy.
After working with Groovy for quite a while I started dabbling in Ruby. At first I really didn't get it. Then I watched a presentation by Dave Thomas and the lights went on. A world of possibilities opened up for me, and they were easily in reach.
I'm in the process of porting an application from Java/Groovy to Ruby on Rails. All of our times are stored in the database in local time. So, I needed ActiveRecord to store a time without converting it to UTC, which 2.2 does by default. (I'm not sure when UTC became the standard though, could have been before 2.2.)
After some Googling and asking on IRC it was suggested I try:
config.active_record.default_timezone = :local
This sets the ActiveRecord::Base.default_timezone class attribute. Unfortunately that didn't seem to have the desired effect. Dates were still stored in UTC but when retrieved via accessors they were converted to local time. Not what I wanted.
Sometimes I'm embarrassed for my nation. I'm not an Obama supporter, for policy reasons, but this type of blind ignorance is frightening: Misconceptions of Obama fuel Republican campaign - 13 Oct 08. Unfortunately this blind ignorance and prejudice has provided fuel to stoke the fires of yet more prejudice, that between the Muslim world and the United States.
I'm a Republican. I have been my whole life. But my fellow Republicans need to get over it. Barack Obama is probably going to be our next president. We as Americans need to make peace with that collective national decision.
When running Ruby on Rails in a war using the GoldSpike servlets and context-param jruby.standalone is set to true you will need to use the jruby-complete jar file. Rails requires Gems in order to boot strap. I found that using the jruby jar file caused Rails to fail in initializer.rb when it tried to require 'logger' which is included in the ActiveSupport gem.
Also be sure to copy your required gems into WEB-INF/gems.
[EDIT: Better yet use ruby gem install --install-dir WEB-INF/gems. ]
This past weekend was an emotional roller coaster. It all started with a post on Twitter from Veronica:
I was checking my Twitter feed on my iPhone just before going to bed Friday night, after a long day of work and family. I read that tweet, followed the link, read the blog post about Wyatt's fight for life, put the phone on my night stand haunted. I couldn't get it out of my head. I couldn't pick up my phone and continue my life as I had before reading that tweet. I'm a new father, and I could only imagine being in the same situation and crying out for help. Echoing in my head was:
Sylva looked at my blog and pointed out I haven't posted in about two months. Since getting on Twitter and really starting to use it my blogging has evaporated. I didn't blog a lot before Twitter, but since Twitter I almost never blog.
So, what is it about Twitter that is so compelling for me? It's short. Posting is fast with Twhirl. I think well in short bursts. I don't feel compelled to develop a deeply thought out, well composed and edited blog post. In the past I've spent hours and hours writing blog posts on technical subjects. It takes a lot of time to get them right. Twitter is just so immediate.
Monday afternoon Ezra Isaac entered the world. My lovely wife Sylva did an amazing job. Ezra was born at home. Truly an amazing experience.



It's taken me years, but I finally got over import java.util.*;. First, I don't use an IDE. I know an IDE could manage my imports, but I'm not an IDE guy. So, for years I've managed my imports manually, or given up and done import java.util.* and felt guilty about it. Well, I'm over that, and I can give Groovy the credit. By default Groovy imports java.util.*. I've been using Groovy every day now for about a year and a half and the house is still standing, our code compiles, we haven't had name conflicts. Things work, and it's a lot easier.
I used to worry about name clashes and compilation speed, and other shiboleths spoken of around coder camp fires and in hushed tones. After all everyone "knows" that the * should be avoided. Well, I'm over it, import java.util.* is just fine with me. Now when I start a Java source file I almost always just add java.util.*.