Avdi Grim has begun a thought-provoking series surrounding the idea of sustainable software development – specifically targeting Ruby as an example.

With some of the recent discussion surrounding “monkey patching” in Ruby, I think that the timing seems about right, for some serious thought to be given about the long-term effects of maintaining Ruby-based code-bases, should prolific “monkey patching” continue to be used haphazardly by many of the libraries, plugins, gems and other code that makes (sometimes critical?) modifications to the underlying core language classes.

Nick Sieger has crafted a thoughtful response to Avdi, which includes the quote:

[Monkey patching is] still a basic part of the Ruby programming culture, like it or not.

While Nick is totally correct, and Ruby does give you the power to shoot, maim and otherwise pillage and murder yourself in a bazillion different ways – that doesn’t take away the fact that it is still an incredibly powerful, elegant and syntactically beautiful programming language.

At the risk of sounding like a trite broken record (for the 485,000 time), I think that once again it boils down to using and choosing the right tools for the job. If the consequences of Ruby’s dynamism (among whatever other consequences) outweigh the positive benefits that a Ruby solution provides – then choose a different tool.

You can complain about the verbosity of a language like Java all you want (heck, I know I do at times), but I come back to Java sometimes after working with Ruby for a few months, and I’m all of a sudden thankful for strict, static typing, always knowing what I’m gonna get.

What continues to irk me are the folks who seem completely hell-bent that their way is the only One True Way™.

I was in a job interview the other day (company name shall be kept confidential) at a place that does extensive software development in many languages including Java, C, C++, Perl and PHP (at the very least). Near the end of the interview, we were discussing different languages, and I mentioned how sometimes I really enjoy the dynamic typing facet of Ruby, as opposed to the statically typed facet of Java. At this statement, one of the interviewers piped up to tell me that the fact that I enjoyed dynamic typing at times was “the most brain-dead thing” he’d ever heard anyone say.

It seems so strange to me, to be on the receiving end of an insult like that, coming from a company that performs extensive development in PHP (which is not only dynamically typed, but also weakly typed, as opposed to Ruby which is strictly typed).

At any rate, all of that comes to some sort of summary that everyone should already know by now:

1. there is no silver bullet
2. think before you choose your tool/language/whatever
3. don’t hate the unknown simply because it’s unknown
4. don’t call someone brain-dead if they sometimes enjoy a programming language that is dynamically typed, it hurts their feelings
5. read Avdi’s series on sustainable development in Ruby.

A couple weeks ago I ran into some horrible issues with Oracle and activerecord-jdbc. Inserts were failing with an “invalid column index” error.

It turns out this was reported as JRUBY-2018 and resolved, but there wasn’t a release of activerecord-jdbc that contained the fix.

Being impatient like I am, I grabbed the head from svn and built it myself. So if you ever find you need to build yourself an activerecord-jdbc gem from subversion, here you go:

First make sure you have hoe installed.

jruby -S gem install hoe

Grab the source from svn.

svn co http://jruby-extras.rubyforge.org/svn/trunk/activerecord-jdbc

Build the .gem

jruby -S rake package

Install the generated .gem file.

jruby -S gem install activerecord-jdbc-adapter-[version].gem

MAKE SURE YOU UNINSTALL YOUR PREVIOUS VERSION

The chances that you’ll have to do this are very slim. Nick Sieger is usually super-on-top of making sure things are up and working the way they should be, but just in case.

In the process of setting up my new dev machine, I decided I was going to try using MacPorts to install all of the dev-type-software instead of installing into /usr/local.

James Duncan Davidson has a great overview article (that needs no further explaining from myself), titled Sandboxing Rails With MacPorts. Another similar article can be found here.

My problem is that I work on a lot of projects that use ImageMagick / RMagick, and that’s not discussed here.

No worries, I’ll install ‘em and give it a go:

sudo port intall ImageMagick
sudo gem install rmagick

CRAP! I don’t know what happens for you, but ImageMagick installs perfectly for me, and then RMagick craps out and dies something like this:

/opt/local/lib/ruby/gems/1.8/gems/rmagick-1.15.9/./lib/rvg/misc.rb:321:in `get_type_metrics': 
unable to read font `(null)' (Magick::ImageMagickError)
 from /opt/local/lib/ruby/gems/1.8/gems/rmagick-1.15.9/./lib/rvg/misc.rb:321:in `render'
 from /opt/local/lib/ruby/gems/1.8/gems/rmagick-1.15.9/./lib/rvg/misc.rb:696:in `text'

Now, for the solution I am going to give all credit to Jakob Skjerning, because I found the solution on his site after doing some Googling.

Do this instead:

sudo port install ImageMagick
sudo port install rb-rmagick

Done. Works. Thank goodness.

A few days ago I ran a sudo gem update and unwittingly got a Capistrano 2.0.0 upgrade that broke my ability to deploy a bunch of existing Rails apps.

cap deploy
the task `deploy' does not exist

Hmm. That sucks. Nick to the rescue. Here’s the culprit:

gem list | egrep -v "^( |$)" 
...
...
capistrano (2.0.0, 1.4.1, 1.4.0)
...
...

Needed to uninstall all the Capistrano gem versions, and install the last working one (apparently 2.0.0 is not backwards compatible with 1.4.1 – which I didn’t know until today).

Here we go:

sudo gem uninstall capistrano -v 2.0.0
sudo gem uninstall capistrano -v 1.4.1
sudo gem uninstall capistrano -v 1.4.0

Say Yes when it asks you to uninstall the cap and capify binaries.

Now let’s install 1.4.1 again:

sudo gem install capistrano -v 1.4.1

Yay! It works! Time to fix those deploy scripts… when I have time.

I wrote this article for IBM developerWorks a while back, but never ended up blogging about it. So at any rate, here it is: Ruby on Rails and XML – for better or for worse.

Nick is here visiting from Texas, and we took the opportunity to head off to a Singapore.rb meeting last Thursday with facilities for the meetup graciously provided by the NLB. Ivan the librarian has posted a blog entry about his experience at the meetup, and seems enthusiastic in how the library might help to support the community. If you’re in Singapore and have any interest in Ruby or Rails at all, it’s time to get involved in the community – this is a great place to learn, ask questions and hang out with some really smart folks. Join the google group, or come hang out on IRC (Freenode) at #singapore.rb, I’m always so lonely by myself.

I’ve been really busy, so it’s taken some sweet time, but at long last I’ve been able to upgrade to SimpleLog 2.0 which Garrett Murray managed to push out the door. I redid all the colors, background, some of the fonts and the overall width of the content in my ongoing mantra to ‘mess with CSS’ more. The latest version also offers content and comment feeds, among other things, like a prettier admin interface.

DreamHost is continuing to aggravate me in new and special ways, none the least of which was deploying the new version of this site. I’ve got some space over at SliceHost that Nick has so nicely set up for us, but alas, I haven’t had the time or energy to get things moved over there yet.

I suppose deploying the new site isn’t a bad way to spend the afternoon after sampling a few pints with James at Pump Room Asia.

I’ve been meaning to comment as well about the relatively new and beautiful support for Ruby / Rails in both IntelliJ IDEA (screencasts here and here) and NetBeans (screencasts here and here, but I haven’t had time. It’ll have to wait for another day.

Don’t get me wrong, I love TextMate, but it ain’t no IDE.

If we ever meet, I will buy you a beer, or wine, or whatever you want.

You are forever in my gratitude for how much time you save me thanks to this and this.

For the uninformed: If you need to install Ruby/Rails/Mongrel/RMagick/etc. on Mac OS X, and you don’t want to have to figure it out yourself, or think, then follow the above links.

Coding in Ruby is like using a Mac. If you’re not used to it, you spend quite some time looking for an obtuse way to do something, only to come to a “one line of code” solution about 2 hours later.

For me, I wanted to deserialize a YAML serialized ActiveRecord::Base subclass. Looking at the YAMLrdoc, it appeared that I could register a custom type via YAML::add_domain_type – but I wanted to Google around a bit just to see if anyone had already solved this <ahem>YAML deserialization problem</ahem>, to find me some sample code.

I learned nothing via Google, so I turned to the handy rails console (may it live forever) for a quick test, and I ended up with something like this:

monkey:~/Work/[client]/trunk daniel$ ruby script/console
Loading development_daniel environment.
>> 
>> class BlaTest    
>>   attr_accessor :bla
>> end
=> nil
>> b = BlaTest.new
=> #<BlaTest:0x3718164>
>> b.bla = "Yay Test" 
=> "Yay Test" 
>> c = YAML::load( b.to_yaml )
=> #<BlaTest:0x37138bc @bla="Yay Test">
>> c.class
=> BlaTest
>> c.bla
=> "Yay Test" 

So basically, we’ve created a new class with a single property, instantiated an instance of the class, set the property, and then we’ve called YAML::load for the YAML representation of our created instance. The result of YAML::load we’ve assigned to c.

To my surprise (astonishment?), I didn’t even need to register my custom type at all. As you can see, the resulting instance c is of type BlaClass with the appropriate value for the bla property.

One line of code. Beautiful.

My favorite podcast, hands down, is the JavaPosse. There’s nothing quite like sitting back with a cup of coffee and listening to Dick, Carl, Tor and Joe yammer about Java (and/or technology in general) – especially if they’ve been drinking.

A few months ago they launched a Google group in which I am an avid lurker, and very occasional poster. One of the more recent threads was surrounding third-party iPhone application development. I think that the winning comment in this thread was this one:

The simple question here is therefore “Is this phone of any further interest to the Java community/Java Posse?”.

He might as well have said:

If it’s in the world, and it has nothing to do with Java, we shouldn’t discuss it or have any interest, and said object might as well be used as toilet paper. If it’s not Java, it can kiss my bleeeeep.

Forget the fact that it’s a phone – and I could care less if it had anything to do with Java whatsoever. I don’t care if I can write or run 3rd party apps on my phone, or my iPod. I want a phone so I can (go figure) phone people. Of course, all the other iPhone stuff is awesome as well (calendaring, sms, voice mail, iPod, photos, videos, etc.). Why, for the love of all things good, would a community write off said device claiming it no longer deserves “any further interest [from] the Java community” – because it doesn’t have Java on it? Maybe the Java community should stop having interest in hard disks, or RAM, or digital cameras, or iPods for that matter – simply because they don’t allow for third party Java application development on them. I’m making a pact right now. I’m not going to purchase another stick of RAM until I can plug it into a USB port on my laptop, and write a third-party Java app for it that makes it light up, or sing, or something.

Unfortunately, this is the collective wisdom that (stereotypically speaking) the Java community now tends to bring to the table. Let us look at a fictitious (but not fictitious at the same time) example:

Jim: Hey there, have you played with Ruby at all?
Greg: Are you crazy, that stupid thing?
Jim: It’s got some really powerful syntax, and I can’t believe how fast you can prototype apps in it.
Greg: Nothing more than a stupid toy language.
Jim: Have you used it? Have you seen how powerful some of the APIs are?
Greg: No. I’m a Java developer.
Jim: Why don’t you just take a look, see what you think?
Greg: No. If it’s not Java, it’s stupid and useless.

Right. Thanks.

I found this new (to me) Ruby tidbit in a comment on a two year old blog post here.

Basically, in Ruby, you can initialize a new Hash so that any time you reference a given value, keyed by a given key, if that value is previously nil, it assigns a default value.

In “gooder” English, it basically just lets you assign a “default” value for items in a Hash.

Why is this useful? Well, let’s say for example that you are iterating over some array, building up a hash as you go. Maybe the key you are using for the hash is derived from a certain property of each of the objects in your array.

Concrete Example (Java)

We have an ArrayList of Product objects. Product has a “getCategory()” method, and we want to build up a HashMap whereby the key is the product category, and the value is an ArrayList of all Products that fall into a given category.

Map<String,List<Product>> map = new HashMap<String, List<Product>>();
for (Product product : products){
  if ( map.get( product.getCategory() ) == null ){
    map.put( product.getCategory(), new ArrayList<Product>() );
  }
  map.get( product.getCategory() ).add( product );
}

I still can’t get over how downright ugly Java code looks now if you want to get it to compile without warnings, thanks to generics. Just. Yuck.

Concrete Example (Ruby)

We have an Array of Product objects. Product has an attr_accessor for category. We want to build up a Hash object in the same manner as we did for the Java example above.

map = Hash.new { |h,k| h[k] = [] }
products.each { |product| map[product.category] << product }

You’ll note that I don’t have to do any check for null (or nil) because the initializer passed to Hash basically says “Any time someone grabs something from the hash, if it’s null, initialize it with a new Array”.

As odd as it sounds, when you’re playing bachelor for the weekend while your wifey is chillaxing in Indonesia, you find a lot of strange things to do to amuse yourself.

I’ve talked before about a neat little piece that someone discovered over on the Strongspace forums about getting Subversion repositories working over there. I’ve been using this method a lot lately, and typing all the commands gets tedious. The long and the short of it is that you need to create the repository locally first, and then copy it up to your Strongspace account before you can do the checkout over svn+ssh.

As I was writing this little piece, I figured I might as well also say something about how I really love the Vibrant Ink TextMate theme that I originally discovered while reading Chu Yeow’s blog

Quite nice I think. And droplets you ask? Well, I was going through the NLMA (Neat Little Mac Apps podcast) history – and came across Photodrop – which looks incredibly useful. That triggered in my brain some memory that Transmit was actually supposed to do droplets in the latest version, and sure enough it does. So now I have a nice little Transmit droplet that lets me upload files (like this ruby app and the image above) with simple drag and drop onto this droplet mini-app thinger.

As for this ruby Strongspace Subversion app, you can grab it here

Usage is dead easy:

ruby svn.rb [strongspace_username] [repository_name]

You’ll be prompted with your password a couple times. Make sure you’re aware of what this app actually does before you run it – or you could find yourself short some files!

1. Create a new repository in your current working directory with the name [repository_name] provided as a parameter to the app
2. Copy the created repository to your Strongspace account
3. rm -Rf the local repository it just created
4. Checkout the new repository via svn+ssh.

Charles Oliver Nutter (AKA “one of the JRuby guys” if you listen to the JavaPosse podcast) put up a post that has me salivating about the deployment of Rails apps on Java app servers that will be a part of our inevitable future.

Currently, my biggest gripe about Rails is deployment. To put it bluntly, Lighttpd is unstable, and Mongrel has a few weird quirks, FastCGI is dated, buggy and well, not very fast.

So at any rate, the very idea of deploying a Rails app on a “real” application server is very cool.

About a week ago I received an email from PayPal which contained the first donation I’ve ever received for JarIndexer. I immediately sent a thank you note to the donator, and received this response:

I really support people like you who share tools and things like that for the rest of us, especially when it removes pain. So, thanks for JarIndexer. It saved me so much time and it was very easy to use. So, keep up the good work.

That means a lot. JarIndexer is a super simple program, gets about 30-50 downloads a month, and was very easy to write, but I’m extremely pleased that it has been of use to someone, and managed to relieve a bit of pain.

I suppose this provides me an opportunity to say my thinks as well, to the open source community in general – and to all the folks out there who provide great software that make our lives easier as developers. I suppose I could specifically mention people like James Duncan Davidson (ANT), Rod Johnson (Spring), Gavin King (Hibernate), Yukihiro Matsumoto (Ruby), David Heinemeier Hansson (Rails), Thomas Fuchs (Scriptaculous) and Sam Stephenson (Prototype). In my day-to-day coding life, when thinking of people who freely give their software to the community – these guys have made me the happiest I’ve been in years.

Next task on my list looks like a fun one, integrating payment into a custom e-comm site using Active Merchant.

Documentation seems severely lacking, which could be to the simple looking usage scheme. I might try to write some docs as I go, and if I do, I’ll post them somewhere or consider contributing them.

So far I managed to dig up how to install it – the easiest way seems to be as a plugin – from within your rails app:

ruby script/plugin install \
svn://vault.jadedpixel.com/active_merchant/trunk/active_merchant

It is quite possible that Kathy Sierra writes what is the best blog on the Internet. The relentless shift from developer-focus to user-focus is something that is becoming more important pretty much on an hourly basis.

One thing that really got me thinking about this was the recent video of 37 Signals (Jason and David) that’s been making the rounds, you know, the Mac one.

Albeit the video is a bit on the glam side (maybe I’m only saying that because I don’t have their stunning good looks?). At any rate, one of the things that David says in the video is:

“We’re trying to affect both our peers in the industry and also customers out there, just raise their level of expectation…”

This seems to go along with the whole theme of Creating Passionate Users – but why I bring it up here is for the following reason (Warning: Gross Stereotype Ahead):

People who write apps in Ruby on Rails care about user experience. People who write Java apps don’t give a rip.
-me

(Ok – I’ll make an exception for JIRA). I can feel the flames flying this way already, but this has been more often than not what I have observed in the past year or so. It’s not that Rails provides some sort of Magickal Code that isn’t possible to provide in a Java-based application – it’s that Rails makes it easy for the developer to integrate those features. I mean, forgive me if you like Java Server Faces – but the last time I looked at that code – I ended up in a psychiatric ward for a month before deciding that I’ll just stick with JSP, thanks.

After our Singapore Ruby meetup a couple weeks back, I was chilling with Herry and Choon Keat over a bite to eat – and the primary things that we seemed to be constantly coming back to when discussing Java vs. Ruby were along the lines of:

1. It makes us more productive
2. The code is cleaner, smaller, simpler, less bloated
3. It’s easy to create rich, responsive and enjoyable user experiences
4. We are a lot happier when we’re coding in Ruby.

Don’t get me wrong, I’m not saying that Ruby is now the de facto standard language and “you will be assimilated” all borg-style, I’m just saying that if it’s a feasible language to use for a given project, and Java is equally feasible – I’ll take Ruby in a heartbeat.

It’s about time that the end-users of software start raising their expectations, and time for developers to deliver software to their end-users that doesn’t suck. And one of the major driving forces of this in the past 12 months has been Ruby on Rails, along with some great JavaScript libraries like Prototype and Script.aculo.us. So thanks, guys.

At long last, after sucking most of my previous site content and blog entries from TextPattern, I’ve manage to finally deploy the new site to TextDrive now powered by SimpleLog and RoR.

I’ve previously found the documentation at TextDrive severely lacking, especially in the area of Rails application deployments, however this time around, I was pleasantly surprised by a series of articles that were a great help (along with scripts and config files) for deploying your Rails apps on Lighttpd.

Several other Rails folk I’ve spoken to have expressed concern over Lighttpd’s stability, many of whom have switched to Mongrel. I’m hoping that I don’t run into any stability issues.

Previously, I also had a nice site up for JarIndexer and XafeNotes, but alas, that is no more. I can’t bother to manage a separate site, so they’ve been included in this site for now. JarIndexer is still available for download, as it seems to be somewhat widely used, but I’ve temporarily yanked XafeNotes, as I have some intention of making it free (as in beer), and need to pull out the licensing stuff from the code base. Who knows when that will happen.

About three weeks ago, I started doing some work for Orangepath, a Texas-based company, that I’m hoping will turn into a great long-term relationship. It’s a breath of fresh air to find a company built on morally upstanding principals. I’ve actually had a ton of stuff to blog and yammer about these past weeks, but my time has been spent trying to get this site up and running, instead of writing content to bore people to death. I’ll apologize in advance if there seem to be more entries than usual in the coming days.

I seem to change this site more often than actors in Hollywood change spouses. I’m also a horrible criminal in that I’m really lazy at properly setting up 301 permanent redirects when I move my site to a new layout, new blog software, new framework, or what have you (but I’m working on it, I promise!).

Lately I have found that TextPattern feels so bloated to me, and I don’t have the time or patience to figure out the stupid syntax for all it’s templates, forms, and other goop.

Nick pointed me in the direction of SimpleLog – and I totally loved it. It’s, well, simple. And it’s Ruby, easy to customize and, well, simple.

So here we are – an attempt at once again swapping a back-end in the hopes that “this time” I’ll be less fickle than in the past, but I’m not making any guarantees.

I’ve been enjoying doing this for the sake of examining syntactical differences and standard API differences between Java and Ruby.

Let’s say that we have an object, call it Department. One of the methods in Department is an accessor to retrieve a department id.

Now let us say that we would like to iterate through an array of Department objects and build up a String along the way (we’ll call the String ‘out’), creating a comma-separated list of ID’s (this is a real-world problem, something that you probably have done a ton of times in one form or another).

In Java, I would probably do something like this:

  Department[] deptArray = //Create an array with departments
  StringBuffer out = new StringBuffer();
  //Yes, I know I could use the 'new' for loop, but I need an index
  for ( int index = 0; index < deptArray.length; index++ ){
    Department d = deptArray[index];
    out.append( d.getId() );
    if ( index != deptArray.length - 1 ){
      out.append( "," );
    }
  }

Of course, you might write a nice utility class, that can take an arbitrary array of some type of object, and you could pass into your utility method the name of the method you wish to execute on whatever the instance type your array contains, and you could end up with a method definition something like this:

  public static String getDelimitedStringFromObjArray( 
    String methodName, String delimiter, Object[] objs );

But really, that’s not the point. The point is: “How much code does it take me to do Task N using the bare bones APIs provided to me by the language.”

In Ruby:

  dept_array = //Create an array with departments
  out = dept_array.collect! {|department| department.id }.join(',')

I’ve never even looked at JRuby. Ever.

So I started to look at it yesterday, after I read somewhere that Spring 2.0 is going to have some built-in dynamic language support. Now, don’t get me wrong, I really like Spring. Six months ago you couldn’t catch me saying enough good things about Spring and how wonderful IoC / dependency injection makes life. But I want to say for the record, that whoever thought it was a “good idea” to allow people to embed JRuby / Groovy code in Bean Definition Files (see here) should probably be kicked in the teeth. And if that’s how I feel about it, then I don’t even want to know what Allen Holub would have to say.

Mind you, he probably doesn’t like Spring at all anyways, since it’s all based on XML configuration – but you have to draw the line somewhere.

Friends don’t let friends start embedding chunks of code from random languages into XML files.

I’ve jumped back into Ruby codin’ lately for a few personal projects and prototypes that I’ve been working on, and I just find, more and more – that one of the reasons why I love Ruby so much is that it really seems to have the developer in mind. Java seems very disinterested in the developer, and interested in, well, verbosity?

For example, I ran into a very simple situation where I have a Map (call it what you will, HashMap, Hashtable, Hash, whatever) that I needed to reverse – or invert. In essence, what I needed was a new Map whereby the keys became the values and the values became the keys.

Now, in Java (assuming I have the privilege of Java 5), I would do something like this:

    HashMap inverse = new HashMap();
    for ( Map.Entry me : existingMap.keySet() ){
         inverse.put( me.getValue(), me.getKey() );
    }

If I did not have the privilege of Java 5, it would look something like this:

    HashMap inverse = new HashMap();
    for ( Iterator i = existingMap.keySet().iterator(); i.hasNext(); ){
        Map.Entry me = (Map.Entry) i.next();
        inverse.put( me.getValue(), me.getKey() );
    }

Let us contrast this with Ruby:

    inverse = existingMap.invert

Now, excuse me while I got make a fresh cup of coffee with all the time I just saved.