As I was importing it, there was a page where I needed to provide a password that the CA had given me. On the same page there is an option to “Enable strong private key protection”. It was followed by the sentence “You will be prompted every time the private key is used by an application if you enable this option”. Since I favored security over convenience, I happily selected this option and provided my new password. Just in case I needed to move to another computer, I also marked the key as being exportable.

After time had past on the project, the discussion of automated functional tests with Selenium came up. I thought, thats OK: I remembered that there is an option for IE to remember my password when I’m prompted to give IE permission to use my private key. I selected this option the next time I was prompted by IE for my password. What I found out when stopping and starting a new IE process was that IE ignores the fact that I told it to remember my password. To make matters worse, since I no longer had my password that the CA gave me, I could not re-import the original certificate.

Just when I thought I was out of options, inspiration kicked in and I performed the following steps to make it so that I no longer had to provide my password whenever IE wanted to use my private key:

1. Go to the Personal Certificate tab (see above)
2. Select the certificate that you wish to remove the password from
3. Click “Export”
4. Click “Next”
5. Select “Yes, export the private key”
6. Unselect “Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above)
7. Select “Include all certificates in the certification path if possible”
8. You may either select “Delete the private key if the export is successful” or remove the certificate manually after the export
9. Provide your Password and Confirm your password
10. Specify a file name (something that you will remember with the PFX extension)
11. Click “Next”
12. Click “Finish”
13. Click “Import”
14. Click “Next”
15. Browse for your exported certificate
16. Click “Next”
17. Provide your password as before
18. Mark this key as exportable
19. Click “Next”
20. Place all certificates in the following store: Personal
21. Click “Next”
22. Click “Finish”

What saved me here was that since I chose to make the certificate exportable when I did the original import, I could perform the preceding steps. If I did not do this and since I forgot the password for my original PFX file, then my only option would have been to contact the CA to issue me another certificate.

Now that this is done, I can start up my automated regression functional test suite and not have to be bothered to provide my password every time IE runs a test.

Apparently this year’s MinneBar was the 2nd largest BarCamp in history with almost 400 registered people. From what I was told, the largest BarCamp was in Bangalore with over 500 attendees.

Some of the presentations which I seen parts of were:

1. A Highly Kinetic Semi Dangerous Exposition – Bill Gurstelle
2. Ruby on Rails Q&A – David Heinemeier Hansson
3. Introduction to Natural Language Processing – Frank Schilder & Gary Berosik
4. JRuby 0.99 Q&A – Charles Nutter and Thomas Enebo.
5. Functional Languages and Agile Development – Robert Fischer

In the morning I gave a presentation with Ben Edwards from Refactr entitled Selling Agile to the Enterprise. We had pretty good attendance with people spilling out into the hallway. The presentation can be found here.

(Ripped from the README.txt)

Antomology, besides being a word play on Entomology, is an Ant analysis tool suite. The current suite offering is:

StatisticsListener – an Ant BuildListener which can be used to gather statistics while an Ant build is executed. Statistics on the targets and tasks executed are written to the console after the build completes. Some of the statistics captured are:

1. the number of times a target / task is called
2. the average processing time spent on a target / task
3. the total processing time spent on a target / task
4. the total processing time spent on a target / task expressed as a percentage

The tool isn’t too amazing and the current suite offering is meager, but it served its purpose well on a past project that I was on. I was hoping to take it to the next level by providing support for historical graphing and analysis, but I have not been able to find the time to do it (as of yet).

The Continuous Integration solution at Codehaus isn’t publishing the Antomology jar yet, but the code in the Subversion repository is more current (and tested).

The technologies reviewed were Continuous Builder, Cerberus, CruiseControl, and CruiseControl.rb. I also compiled and presented a comparison matrix much like Aslak Hellesoy has done on the DamageControl web site.

All the artifacts that I used for the demo can be found on the Docs page.

When writing or updating a post in WordPress, there is a box on the right hand side of the screen entitled Discussion with an item for allowing pings. The solution was simple enough: All I needed to do was update each page, uncheck Allow Pings, save and delete any lingering ping comments. Simple enough. Somewhere along deleting the ping comments in my early morning haze, I accidentally deleted one of my blog entries!

I was able to verify that I did this by navigating to the user facing page to be greeted by a “Page Not Found” error. Fantastic! Unfortunately, I was quick to find out that WordPress does not have an undelete option for posts and since I visited the user facing page, I no long had my blog entry in my local cache. After hitting up some of the big name search engines to find a cached copy without success, I needed to figure out a better way of recreating my blog entry without having to do it from scratch.

After much cursing took place, I decided to make another go of playing with the cache. The following is the technique I came up with using just the browser I was blogging in:

1. Put the browser in “Work Offline” mode – usually found under the first couple drop-down menus in your browser
2. Navigate to the page that was being edited by looking at the browser history
3. Breathe a sigh of relief when you see your blog entry in the post textarea
4. Copy and paste your “post” to somewhere safe
5. Create a new post and paste in your recovered post

WordPress seems to manage their pages for post edits by using the following URL syntax:

http://your-blog.wordpress.com/wp-admin/post.php?

                  action=edit&post=post-id

In order to figure out your post id, you can always go to the “Manage – Post” section in your blog administration console and see the post ids for the posts that you still have. Using this information you can make an educated guess what the post id is for the post you deleted.

The drawback in using this approach is that your subscribers will end up with multiple entries in their feed of the same title. A small price to pay I figure…

In order to do Test Driven Development (TDD), we need to become intimately familiar with assertions. In my last blog entry, we started to look at the assert method. Lets consider the contract of this method:

assert(boolean, message=nil)
– Asserts that boolean is not false or nil.

When testing this method I’m making the conscious decision not to test assert using the other methods that Test::Unit::Assertions offers. Although it’ll make things more difficult at first, it will force us to learn aspects of the Ruby language that we would not be able to see if we used one “assert” to test another “assert”.

So what should we test first? Well, lets try the happy path first: Let’s test to make sure assert does not fail if boolean is not false or nil.

require 'test/unit'

class AssertionsTest < Test::Unit::TestCase

  def test_assert_boolean_is_not_false_or_nil
    assert true
    assert(true)
    assert true, 'A message you will not see'
    assert true, "A message you will not see"
    assert true, nil
    assert true, ''
    assert true, ""
    assert true, String.new
    assert true, :something
    assert 'bogus'
  end
end

TDD in a pairing fashion is usually best experienced as the test was typed so that the reviewer can ask questions in real-time. In order to “simulate” this approach, the following bullets describe the thought process I took in order to write this test.

1. I need to create a test which asserts that the boolean is not false or nil
   Lets call it test_assert_boolean_is_not_false_or_nil

2. I would like to assert boolean which confirms my understanding of how to call methods in Ruby
   Lets call assert with and without ()’s

3. I would like to assert boolean-message which confirms my understanding of how strings work in Ruby
   Lets call assert with a message that is a string with single and double quotes, nil, empty quotes, String.new, and a symbol

4. I would like to assert boolean for a non-boolean, non-nil object
   Lets call assert with a “boolean” that is a string

Now when I run my test I see that it passes. If the Test::Unit::Assertions module did not exist and my goal was to develop assert using TDD, then my test would fail and I would proceed to implement the assert method. Once done, I would then re-run my test to ensure I implemented the method as per spec. If my test failed, I would go back to the assert method, fix it, and then re-run my test until it passes.

Since we’re testing the behavior of assert, we can now move on to the unhappy path test. Specifically, we are now going to write a test to ensure that an exception is raised when boolean is false or nil.

The easiest way to test this would have been to use the assert_block method, but since we are trying to learn Ruby we’ll pretend that it doesn’t exist and we will write our own.

  ASSERTION_FAILED = Test::Unit::AssertionFailedError

  def test_assert_boolean_is_false_or_nil
    my_assert_exception_raised(ASSERTION_FAILED) { assert false }
    my_assert_exception_raised(ASSERTION_FAILED) { assert nil }
  end

  def my_assert_exception_raised expected
    begin
      yield
      exceptionNotRaised = true
    rescue => exception
      my_assert_type_of expected, exception
    end
    if exceptionNotRaised
      raise Test::Unit::AssertionFailedError.new( expected +
                " should have been raised.")
    end
  end

  def my_assert_type_of expectedClass, actualInstance
    my_assert_not_nil actualInstance
    my_assert_classes_are_equal nil, nil
    my_assert_classes_are_equal actualInstance.class, actualInstance.class
    my_assert_classes_are_equal expectedClass, expectedClass
    my_assert_classes_are_equal expectedClass, actualInstance.class
  end

  def my_assert_not_nil instance
    assert instance
    assert !instance.nil?
    assert instance != nil
  end

  def my_assert_classes_are_equal clazz1, clazz2
    assert clazz1 == clazz2
    assert clazz1.eql?(clazz2)
    assert clazz1.equal?(clazz2)
  end

To distinguish Test::Unit::Assertions assertions from our custom assertion, I have prefixed our custom assertion with my_. As before, the following is the thought process taken:

1. I need to create a test which asserts that the boolean is false or nil
   Let’s call it test_assert_boolean_is_false_or_nil

2. I would like to make sure an exception is thrown when asserting false
   Since we can reuse this for the assert nil case, let’s create a method which we can pass a block into it. A block is a “nameless function” or just a list of instructions you want to execute.

3. I would like to capture an expected raised exception when my block is executed
   Since yield “yields” to the passed in block, lets wrap the yield with begin..rescue..end syntax. Next, we’ll verify that the class of the exception raised is the one that we expected.

4. I would like to raise an exception if assert does not raise its own
   For simplicity, lets add a flag to indicate if assert raised an exception. If not, our if block will raise its own.

In order to shorten this blog entry, I’ll let you take a look at the implementation for my_assert_type_of on your own. The code here is another example of proving out what we know of the Ruby language. Specifically, this code tests the behavior of:

• nil checking an instance
• nil class equality
• non-nil class equality

I’m starting to take a serious look at Ruby, and like many people who are new to a programming language, it’s difficult to know where to start. Sure I have the “pickaxe” book in hand and my bookmarks are overflowing with Ruby links, but where ever and however I start I would like to be able to see immediate results and I would like to prove to myself that I’m understanding the syntax.

How about testing what I already know? Well, right now I don’t know too much. However, that should make things easier since it will prevent me from wanting to take on too much at once and keeping myself focused on small obtainable goals.

Since I come from the Test Driven Development (TDD) camp, testing is pretty second nature and it is very comforting for me to keep on doing it. Perhaps the question I should be asking is: Where should one start when learning Ruby using TDD?

Since Ruby already has a unit testing framework, the first place we should look is the Test::Unit module. Hmm.. looks like there is a TestCase class. In the past when I developed Java applications, I’ve used JUnit extensively so this seems familiar to me. Okay, but what are we going to test first? Well, when you are writing a test you typically need to make an assertion. Right, where is that kept?

After digging around in the ruby docs online, we see that the Test::Unit::Assertions class contains the assertions used by Test::Unit:TestCase. Scanning down the document, the first public instance method we encountered is assert. Well, golly gee whiz. If we were pairing with Donald Rumsfeld then he would tell us to be vigilant and go after that method because its a known-unknown.

Alright, lets start by creating an AssertionsTest class which will test the assert behavior.

require 'test/unit'

class AssertionsTest < Test::Unit::TestCase

  def test_should_do_something_with_assert
    # method to be revisited . . .
  end

end

This seems to be a good breaking point. My goal is to treat this as a running example while I’m learning the finer aspects of Ruby. Hopefully readers like yourself will find this to be a useful and educational experience.

However, what if I wanted to practice my Kung Fu skills? Sure the Nintendo Wii comes with a “nunchuk” controller, but over time I’m sure the muscles in my legs will begin to atrophy if I don’t get the stimulating workout that I need. Well, wait no longer. Check out this technology coming out of the far east country of… Finland.

When I visited my future in-laws for the first time out in western Pennsylvania, I was asked if I wanted to eat some “buckeyes”. Knowing that my wife’s family are avid deer hunters, I assumed that they were being literal. Since I love food and embrace every opportunity to try food which is different, I was really looking forward to the experience. In my defense, before this moment I have visited quite of few exotic countries and enjoyed much stranger food. Still, I was looking forward to trying some fine Appalachia eats.

Imagine my disappointment and shock when I bit into a chocolate covered peanut butter ball when I was expecting something more spongy and less sweet. Embracing my many years of consulting skills, I was able to recover quickly and I thanked them for the tasty treat. Needless to say, I dared not mention or explain my confusion since I would have only embarrassed myself and possibly jeopardize my engagement. Still I couldn’t understand why on earth people would make candy and named after discarded animal parts.

Later on during the same trip we went to visit my finance’s grandfather in eastern Ohio and I saw some unusual brown balls by the back steps piled up – similar to a tasty treat I tried earlier. I asked my finance what they were and she told me that they were “buckeyes”. In my experience, whenever you are in an unfamiliar situation, it is best to identify the familiar. Falling back on what I already knew, that my in-laws were deer hunters, I started picturing my finance’s 92 year old grandfather sitting on the back porch gutting deer (or at least employing someone to) and discarding the buck eyes in a pile. It may have been best to ask for clarification, but I still had my dark secret from my previous “buckeye” episode.

Finally, on a different occasion I was watching an Ohio State football game on TV. In addition to seeing a good team play, what really stood out for me was that the Buckeye football players had stickers on their helmets while the other team did not. I was still pretty new to this American college football thing and my vision is poor, so I tried to make out what it was (I should have used Google).

I never took a botany course in school, but take a guess which plant I thought I saw:

Well, I must say that my view of the Midwest totally changed once I had that revelation. Instead of picturing the Midwest or Ohio as a closed region bound by rigid traditional values, I started to think of it more as a highly liberal region quietly residing within conservative America. That’s right Pacific Northwest states: You have nothing on Ohio state! Hey, if one of the best and most visible college football teams in the United States could wear “those” stickers on their helmets and still have the acceptance of the fans and Ohio residents then Ohio has to be a super liberal state… My, and so many stickers too!

Anyhow, since that time I have fallen in love with Wikipedia and was able to use it dispel my faulty knowledge. What I ended up finding is that Ohio Buckeye is a tree, the sticker is of the Ohio Buckeye tree leaves, a Buckeye is a nut from the Ohio Buckeye, and Buckeyes are also chocolate covered peanut butter balls.

As I write this, it looks like the Buckeyes have no hope for recovery against the Gators. Better luck next year! Don’t eat too many “buckeyes” in the off-season!

• The Princess – people who put their jackets and / or their tiny bags in the overhead bin instead of holding onto their jacket and putting their bags under the seat in front of them. Oddly enough, most of these offenders are middle-age business men who carry man-purses around.
• The Lazy Sherpa – people who sit in the back and decide to put their roller bags up by the bulkhead. Although these offenders won’t have to carry their already over packed bag as far, it forces people near to front to check their baggage OR they will need to go further back and tick off those people seated there.
• My new best friend – perpetrators are usually old, lonely, or just nervous of flying. They like to tell you everything about themselves, even if you don’t ask. Sometimes they will continue to talk to you even when your eyes are closed and you’re sleeping.
• THIS IS MY INSIDE VOICE! – no matter where you are on the plane, there is no escaping this individual. This pattern can occur simultaneously with the “My new best friend” pattern.
• The Brewery/Distillery – the nervous flier who decide to self-medicate themselves with booze before and during the flight. Usually stinks of booze for the entire flight. Bonus points if the Brewery / Distillery has spittle / barf on their face / shirt / slacks.
• The Seat Cowboy – people who bounce around in their seat and mercilessly try to force their seat back further than the seat is manufactured to do… or until my knees break.
• The Uni-bomber – this offender usually works alone or with a can of beans before hand. Many people are affected when his / her bomb goes off, but no one knows who did it. The phrase “silent but deadly” is truly applicable in this instance.
• Sausage in a Bun – usually comprises of one larger individual in the middle seat or two on the outside seats.
• Seat Squatter – when you arrive at your seat, there is already someone there and they try to sell you on taking their less pleasant seat. Sometimes they will continue to hum and ha until you have to physically give them the boot.
• Au Natural – lucky are you when you sit next to a naturalist who refuses to wear deodorant because of their inorganic elements.
• Mosquito Fogger – individuals whose sense of smell has become worse over the years and so they have to apply their fragrances using a mosquito fogger so they and everyone on the plane can smell it.
• New Age Wacko Parent – parents who let their children have the rule of the aircraft i.e. the kids are allowed treat their seats like jungle gyms or trampolines. These parents also let their child scream and cry since the child is “only trying to express him / her self”.
• I have no bladder control, but I want the window seat – if you know that you have problems with your bladder / bowels, please choose a seat near the lavatory and in the aisle
• I don’t like being bothered, but I want the aisle seat – by electing to take an aisle seat, you need to have some expectations that people in your row will need to get up
• My legs are short, but I want the bulkhead or emergency exit row – save these seats for people who get bloody knees from sitting behind you
• I sit in an aisle/window seat and I want both armrests – you already have one personal armrest. Think of the poor schmuck who is stuck in the middle!
• No, I will not switch (equivalent) seats so you can sit with your wife – I really don’t know what to say about this one. If you recognize yourself as being an offender then you deserve to be beaten.
• I like my space and I want to pay for economy – if you really do have space issues then fork the cash out for first class seats… if you choose not to then “just suck it up princess”.