As part of the development of a strategy to consolidate a number of online accounts as well a series of planned enhancements, I have recently migrated this site to a dedicated server, provided as a Joyent Accelerator. The shared hosting provided by Joyent has been great. However, the time has come to upgrade. I think that I have everything working now, but if you come across something that looks funky, please drop me a note.

What does this mean to you? For now, nothing really, except page loads should be a hell of a lot faster. :)

There has been a performance issue that has been well documented when using Builder::XMLMarkup. Over the course of time, I’d noticed that my rails app has gotten slower and slower building XML as more data ended up in the database. On my development environment, it would take approximately 15 seconds to render the xml generated by this controller.

As it turns out, the pure ruby implementation of String#to_xs is pretty slow. Thankfully, there is a C extension which you can install to alleviate this. Installing fast_xs is as easy as:

superbia:~ matt$: sudo gem install fast_xs

If you’re using Rails 2.0, you’re done. If you’re using Rails 1.2.x, we’ll do some monkey patching to make this essentially a drop-in fix. We’ll utilize the same techniques that are used to address the issue in Rails 2.0. Essentially, we want to extend String to take advantage of the fast_xs method if it is available. To do this, open $(RAILS)/config/environment.rb and add the following lines to the bottom.

begin
  require 'fast_xs'
 
  class String
    alias_method :original_xs, :to_xs if method_defined?(:to_xs)
    alias_method :to_xs, :fast_xs
  end
rescue LoadError
  #fast_xs extension unavailable
end
 

Again, this is exactly how Rails 2.0 takes care of it for you. By the way, this one single change dropped my render time from roughly 15 seconds to just under 3 seconds. If you’re building a lot of XML with Builder::XMLMarkup, you need to take a look at this.

After Robert Martin’s Clean Code talk at SDWest this year, I had the good fortune of meeting Gregg Pollack. If you don’t happen to know Gregg, he represents Ruby on Rails in these PC vs Mac spinoffs. The videos are a little old, but if you haven’t seen them yet, they’re good for a laugh.

Ruby on Rails vs Java

Ruby on Rails vs PHP

Ruby on Rails vs PHP (Organization)

Ruby on Rails vs PHP (Changing Databases)

It was great to talk to Gregg about Rails and some of the things going on in the community. He mentioned his podcast (RailsEnvy.com) to me. He and Jason Seifer saw a need for a podcast dedicated solely to relaying news about the Rails community. I’ve subscribed and caught up on some of the past episodes. They’re very well done, have a tremendous amount of content and just the right amount of humor to keep them fun. Each session now ends with a segment called “Living on the Edge”, which is dedicated to understanding what happened with Edge Rails over the course of the past week. Edge Rails is the trunk version of Ruby on Rails for those unfamiliar.

If you’re doing Rails development, you really owe it to yourself to subscribe to this podcast and feed, so that you can stay in touch with what’s happening in the community. Thanks for getting this out there Gregg.

One of my main likes of the Ruby language is that it very clearly allows you to express programmer intent. I don’t want to get into the argument of whether or not Ruby is more beautiful than another language. Suffice it to say that it is just as easy to create ugly code in Ruby as it is in any other language. However, the tendency is towards very clearly expressing intent. This is what constitutes beautiful code to me.

For example: I would much prefer to read this code

def main
	20.times { puts "Hello, world!" }
end
 

In my opinion, it is very clear what this code does. Contrast that with the following c# code:

public static void Main(string[] args)
{
	for (int i = 0; i < 20; i++) {
		Console.WriteLine("Hello, world!");
	}
}
 

Not only is the latter more verbose, it also puts the responsibility of the iteration into the hands of the client.

C# 3.0 introduced the concept of extension methods which promise to allow you to create more expressive code and abstract away some client complexities. To test how this might work, I set out to create a C# version of the Ruby code above. This is what I came up with:

class Program
{
	static void Main(string[] args)
	{
		20.times(delegate { Console.WriteLine("Hello, world!"); });
	}
 
	static class Extensions
	{
		public static void times(this int number, Action a)
		{
			for (int i = 0; i < number; i++)
			{
				a();
			}
		}
	}
}
 

Much to my surprise, this not only compiled, but actually worked. Also, I got intellisense after the . on 20. These techniques really give C# developers the power to express the intent of their programs. Isnt this what beautiful code is really all about?

A few days ago, when I saw Google Calendar Sync announced on the Google blog, I became very excited. Surely, I thought that this would be the calendar synchronization solution that I had been hoping for for some time. I have found it very difficult to keep my work and personal calendars organized and Google Calendar Sync promised all of my calendars in a central location.

For those unfamiliar, Google Calendar Sync syncs an Outlook calendar with a Google calendar. However, unbeknownst to me at the time, there is a major shortcoming in this. I was noticing that the majority of my Outlook meetings were not being transferred to my Google calendar. I browsed the newsgroups and finally came on this FAQ entry:

To sync all events between Microsoft Outlook and Google Calendar, the email address associated with Google Calendar needs to match the email address associated with Microsoft Outlook. To sync all events between Microsoft Outlook and Google Calendar, the email address associated with Google Calendar needs to match the email address associated with Microsoft Outlook.

This would lead me to believe that I could do this by creating *ANOTHER* Google account… I already have two, I do not want another. I hope that Google decides to remove this severe limitation, but if not, so it goes… the search continues.

After having upgraded to Leopard 10.5.2 and enabling IMAP support through Mail.app, I have had a problem with a new label being consistently generated on my gmail account. No matter how many times I deleted it from gmail, Mail.app would happily recreate it every time I launched it.

Tonight, I was able to figure out how to make this go away. I dont know if it is because of the order of steps that I followed. This worked for me; your mileage may vary.

• Open Mail.app and visit your account preferences (CMD-,) and select the Mailbox Behaviors tab for your gmail account.
• Uncheck the field that says ‘Store notes in Inbox’
• Quit Mail.app. Don’t use the red Close button, but quit completely with CMD-Q.
• Go to gmail.com and delete the Apple Mail To Do label from the Settings | Labels tab.
• Restart Mail.app and refresh gmail to notice that the pesky label is no longer there.

I hope that this helps other people that want to get rid of this pesky label as well. Enjoy.

I’ve been absorbed in some of the testing sessions, specifically RSpec, while down here at SDWest. What has become crystal clear to me over the past few days is that simply writing unit tests is not good enough. Even with the best of intentions things come up. Schedules get crunched and tests won’t get written. They might get picked up later, but chances are that they usually wont. The only way to ensure that the tests are written is to absolutely write the test before writing the production code.

The most prevalent argument that I hear about not writing code test first is that IntelliSense is not present because the class or method does not exist. With the tools available in IDEs and plugins today, this should not be an issue. All the Java IDEs support a “generate method” or “generate class” function. VS2005 supports this with the Resharper add-in which every developer should have in their toolbox. VS2008 also supports the class/method generation out of the box. What the lack of IntelliSense gives the developer is really one of the best things about writing code test first: the ability to think about how the behavior should be expressed in code. Let me state that again. Rather than retrofitting tests around existing code and testing state on what was written, the developer can spend time describing in advance what the code should look like.

A state-based test, which is a result of test-later development, is very brittle. This leads to another objection commonly heard about writing code test first: when the developer refactors the code, all the unit tests have to change. This is correct when the tests are testing state instead of interactions. However, when approaching the problem with the idea of behavior, rather than testing, this problem seems to go away. Some unit tests may still be modified, but it should not be nearly as prevalent as when testing solely on state. I’ll have more an state-based versus interaction based testing in a future post.

Writing the unit test before writing the code also helps evolve a simpler design. When creating a failing test and writing the simplest code that makes that test pass, the result is the simplest code possible to perform the intentions of the code. Additionally, YAGNI (You Aint Gonna Need It) is something that needs to be considered strongly. Writing a specification for code prior to writing the code itself will help make sure that the minimal amount of production code is written.

If it is known that a strategy pattern, for example, is needed, should it be put in at that time? NO! The pattern should be introduced as a result of refactoring to make another test pass. It may be five minutes from now, and that’s ok. It’s really not wasted effort because of the tight nature of the red/green/refactor loop. These iterations should last anywhere between 30 seconds to 2 minutes. Anything longer and too much code is being written between green lights. Unless done properly, there is a good chance that tests become out of sync with the code quickly. There is a very strong discipline and effort level required to create code test-first. This is effort that will yield dividends in the future, when the code does not have to be rewritten because of excess cruft.

A major benefit of writing the code test first is that the developer knows… I mean, really KNOWS, that every piece of code is covered by tests. So, when the developer wants to go in and refactor (or even try a different algorithm), it can be done with confidence that nothing has been broken. As discussed previously, I had learned about RSpec earlier this week and could not wait to try my hand at writing some tests with it after the session was over. I wrote some specifications for a bubble sort algorithm and then code to make those specifications pass. Since C# is the language that pays my bills, my Ruby bubble sort algorithm looked strikingly similar to what I might have written had I written it with C#. However, since I had a battery of unit tests available, I was easily able to try some different things with the production code to make it more Ruby-esque. I was able to do all of this and run my tests afterwards to ensure that everything still functioned as I had intended.

By the way, the code went from this:

class BubbleSorter
  def sort(array)
    size = array.length
    for i in 0..size
      for k in 0..size - i - 2
        if array[k+1] < array[k]
          t = array[k+1]
          array[k+1] = array[k]
          array[k] = t
        end
      end
    end
    array
  end
end

to this:

class BubbleSorter
  def sort(array)
    array.each_index do |i|
      array.each_index do |k|
        array[i], array[k] = array[k], array[i] if array[i] < array[k]
      end
    end
    array
  end
end

Peace of mind lets a developer really take some risks. The code I originally had worked, however, I was not content with it. It did not feel like it embodied the expressiveness of Ruby at all. With the tests in place, I was able to experiment a bit and ultimately come up with much nicer code because of it.

So, as I said… Writing unit tests is good. However, until the tests precede the code, it’s just not good enough. For the best longevity of your code, you must be writing your code test first.

For some time, I’ve wanted to learn more about RSpec and how it can be used to express desired behavior in your story tests as well as your unit tests. At the SDWest conference today, I took a session presented by Dave Astels which started with a high-level overview of RSpec. As Dave was really one of the instigators of RSpec, I really felt like I was getting it from the source.

Something that struck me about this session is that it seems that developers should be spending much more time writing tests around interactions and behaviors than tests around expectations and state. Tests that simply assert on a return value seem to be very brittle and do little to express the intent of the code that is under test. However, writing tests to specify the desired behavior of the code seems to have much more benefit, since the developer focuses on the result of the behavior instead of the implementation. Rather than focusing on on testing your code to make sure that it functions correctly, this is much more about defining what it means for your code to function correctly. As Robert Martin puts it, “Specification, not Verification”.

I had a side conversation with Dave about his thoughts on how IronRuby might support the RSpec framework for testing C# code. He mentioned that a stated goal for the IronRuby project was to run Ruby on Rails, and he felt that if that goal was met, then RSpec should certainly run on it. As it turns out, the IronRuby folks have already done some significant work to make this happen, but they are not quite there yet. I can only say that this is one project I’ll be keeping a careful eye on. Being able to describe my C# code using the elegance of Ruby would be simply amazing.

Ruby code (especially an RSpec example) is just dead sexy to read. I mean, is there *any* doubt as to what the following code is testing:

describe "A bowling game"
	before(:each) do
		@game = BowlingGame.new
	end
 
	it "should score 300 on a perfect game" do
		12.times { @game.roll(10) }
		@game.score.should == 300
	end
end
 

By the way, the above is a snippet of my implementation of Robert Martin’s Bowling Kata. I was excited enough by the RSpec discussion to try implementing this on my own. Very nice framework. Very nice.

I arrived yesterday in Santa Clara for the SDWest conference. This being my first time to the Silicon Valley, it came as quite a big deal to drive down Great American Parkway, past the McAfee campus, past the Yahoo campus, past Netgear and WebEx. A lot of big names in the tech industry make their home here.

My awe of the Silicon Valley is not really the point of this post. What really struck me was how generally anti-social geeks are. At the lunch today at the conference, they had a hall for of tables, 8 chairs per table. Not sure why, but I would have expected people to sit together and get to know each other a little more. Maybe talk about what they’re working on.

Call me completely surprised to see virtually every table in the hall had one, maybe two, people sitting at it. What is it about out personalities that makes us so afraid to talk to other people, especially people that are really interested in the same things that we are?

Leopard’s new backup system has made it virtually inexcusable for users to not have automated backup systems in place for their Mac. It can not get any easier to do this: plug in a USB/Firewire drive and slide the switch to On in Time Machine.

I’ve been using this since Leopard came out and I love having the extra piece of mind. One part of this nagged at me a little bit, which was that my virtual machines were being backed up each time they were modified. As you can imagine, this eats up a lot of disk space. The data that I am interested in having backed up from the virtual machine already gets synced up via Parallel’s Shared Folders, so it gets picked up by Time Machine.

Finding out how to exclude my VMs turned out to be a little more complicated than I would have expected. For whatever reason, I missed the options button on the Time Machine preferences window. Click options and then add in folders which will be excluded from the Time Machine backup. I store all of my VMs in one folder, so I just added it to the list. Disk usage has gone down considerably, now that Time Machine isnt copying over multi-gig files every hour.