In my previous post, I made it sound like the Rails installation was painless, and it was apart from one point. When starting ‘rails server’, it complained that it couldn’t find sqlite3-ruby. I would have expected this to be installed as part of the rails gem, but it’s a simple installation anyway:

gem install sqlite3-ruby

However, when attempting to start the server again, I received the following message dialog.

---------------------------
ruby.exe - System Error
---------------------------
The program can't start because sqlite3.dll is missing from your computer. Try reinstalling the program to fix this problem.
---------------------------
OK  
---------------------------

With the stacktrace of:

C:/Ruby192/lib/ruby/gems/1.9.1/gems/sqlite3-ruby-1.3.1-x86-mingw32/lib/sqlite3.rb:6:in `require': no such file to load -
- sqlite3/sqlite3_native (LoadError)
        from C:/Ruby192/lib/ruby/gems/1.9.1/gems/sqlite3-ruby-1.3.1-x86-mingw32/lib/sqlite3.rb:6:in `rescue in <top (req
uired)>'
        from C:/Ruby192/lib/ruby/gems/1.9.1/gems/sqlite3-ruby-1.3.1-x86-mingw32/lib/sqlite3.rb:2:in `<top (required)>'
        from C:/Ruby192/lib/ruby/gems/1.9.1/gems/bundler-1.0.0/lib/bundler/runtime.rb:64:in `require'
        from C:/Ruby192/lib/ruby/gems/1.9.1/gems/bundler-1.0.0/lib/bundler/runtime.rb:64:in `block (2 levels) in require
'

To solve the problem (and considering this is only my local dev machine) I downloaded sqlite3.dll from http://www.sqlite.org/sqlitedll-3_7_2.zip. I then copied the two files into C:\Windows\System32. 

I could then happily execute rails server. Admitted, not the best way but it was the quickest :)

Labels: RubyOnRails

As you may have heard, Rails 3.0 final and Ruby 1.9.2 have been released. These have got a large number of features, with both representing the next stage of Ruby development.

While Rails 3.0 won’t cause too many problems, it does require Ruby 1.8.7 or higher. As Ruby has grown, multiple versions have been released which can live happily side-by-side. Sadly, command lines don’t make it easy to specify which version you want to execute.

For example, I have two versions of MSBuild on my machine with my command prompt being aware of both:

>where msbuild
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe

However, by default, it will execute the one it finds first when scanning the directories set in the PATH:

>msbuild
Microsoft (R) Build Engine Version 4.0.30319.1

The same is true with Ruby. Yet, this is complicated by the fact that there are multiple different executables (gem, rake, cucumber, spec, rails etc) together with different gems depending on the core Ruby version - 1.8 and 1.9 will have different gems installed even on the same machine. 

To help manage this, the Ruby Version Manager (RVM) was created. “RVM is a command line tool which allows us to easily install, manage and work with multiple ruby environments from interpreters to sets of gems”

Sadly, RVM doesn’t work on Windows. Thankfully, Pik does - “Pik is a tool to manage multiple versions of ruby on Windows”.

This means we can do the following:

>ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]

>pik switch 192

>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

Below is how I installed Pik, along with Ruby 1.9.2 and Rails 3.0 to start the next part of my Ruby development journey.

Installing Pik

My machine already has Ruby 1.8.6 (ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]) installed which means I can install pik via RubyGems. If you don’t already have Ruby, the README file on GitHub has a section called “Install pik using the installer“ which I recommend you follow.

gem install pik

After downloading the gem, you need to install pik into a directory on your machine. This can be anywhere, apart from where you already have Ruby installed (C:\ruby\bin).

>mkdir C:\pik

You need to include the directory used above in your %PATH% environment variable before the location of any existing Ruby installation. I put it at the start.

When installing, simply specify the directory you picked.

>pik_install C:\pik
Thank you for using pik.

After which, you will have three files in the folder. This is everything required for pik.

29/08/2010  17:08               119 pik.bat
29/08/2010  17:08               145 pik.ps1
29/08/2010  17:08           694,272 pik_runner.exe

Using Pik

I can now start working with Pik. Executing the pik command will locate all existing Ruby installations and configure itself.

>pik
** Adding:  186: ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]
Located at:  C:\Ruby\bin
Usage: pik command [options]

Executing pik list outputs all the ruby installations it knows about. 

>pik list
* 186: ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]

As Rails 3.0 requires 1.8.7 or higher, let’s install the latest version of Ruby.

>pik install ruby
** Downloading:  http://rubyforge.org/frs/download.php/71175/ruby-1.9.2dev-preview3-i386-mingw32-1.7z
   to:  C:\Users\Ben Hall\.pik\downloads\ruby-1.9.2dev-preview3-i386-mingw32-1.7z

Sadly, this still tried to install a dev preview, even with the latest version released. Luckily, it can be installed manually.

Manually installing Ruby 1.9.2

By default, installing Ruby on Windows can be somewhat difficult. Thankfully, a 1.9.2 one click installer has been released which you can download here - rubyinstaller-1.9.2-p0.exe

After clicking next a few times, I installed Ruby into C:\Ruby192.

I then need to tell pik about my installation by pointing it at the bin directory. That’s it.

>pik add C:\Ruby192\bin
** Adding:  192: ruby 1.9.2p0 (2010-08-18) [i386-mingw32]
Located at:  C:\Ruby192\bin

If you list pik, then you can see all the different versions installed:

>pik list
* 186: ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]
  192: ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

You can then switch to the particular version you want, for example originally I was running 1.8.6.

>ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]

But I can then switch to 1.9.2 with a simple command.

>pik switch 192

>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

Installing Rails 3.0

That’s the hard bit done. I didn’t have install pik but during the transition between 1.8.6 and 1.9.2 I *think* this will be invaluable. With 1.9.2 now configured and set as my current pik environment I can just install rails.

>gem install rails

Yep, that’s it. 

Rails 3.0 Hello World!!

To create a new rails app, let’s just execute the command:

>rails new HelloWorld3 

Followed by:

>rails server
=> Booting WEBrick
=> Rails 3.0.0 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2010-08-29 18:01:27] INFO  WEBrick 1.3.1
[2010-08-29 18:01:27] INFO  ruby 1.9.2 (2010-08-18) [i386-mingw32]
[2010-08-29 18:01:27] INFO  WEBrick::HTTPServer#start: pid=7472 port=3000

I now have our Rails 3.0 application running on top of Ruby 1.9.2 on Windows.

If I ever need to go back to Rails 2.3.5, I just type the following:

>pik default

>rails -v
Rails 2.3.5

Labels: Pik, Ruby, RubyOnRails

This morning I was attempting to install the latest version of Cucumber, however I recieved an error saying gherkin (the language parser of the tests) was not installed.

C:\>gem install cucumber --no-ri --no-rdoc
ERROR:  Error installing cucumber:
        cucumber requires gherkin (~> 2.1.4, runtime)

Generally, gems install all of the dependencies so I found this a little bit strange. Naturally, I manually install it.

C:\>gem install gherkin --no-ri --no-rdoc
Successfully installed gherkin-2.2.0-x86-mswin32
1 gem installed

Sadly, this still didn’t work. The reason was it needs 2.1.4 installed, not the 2.2 version.

Executing the following allowed me to install Cucumber as normal

gem install gherkin --version 2.1.4 --no-ri --no-rdoc

Labels: cucumber, Ruby, Testing, TestingASPnet

Labels: IronRuby, NDC2010, QCon, Testing, TestingASPnet

Frequently when reviewing code I see one of my pet hates appear and that’s a direct dependency on the ConfigurationManager.  The ConfigurationManager provides a way to access values in the Web\App.config. Yet, like any dependency, they generally bite you at some point – generally when you attempt to write the test.

Let’s imagine that our web.config has a value like below:

EnableNewsletterSignup = “false”

This value defines if we should hit the live web service. During development\systest we don’t want this to happen, however we do in UAT and Live. As a result, our code will generally look like this:

public bool Signup(string email)
{
    if (!Boolean.Parse(ConfigurationManager.AppSettings["EnableNewsletterSignup"]))
        return false;

    return true; // technically this would go off to an external web service
}

Simple, yet with multiple problems

Firstly, we have a magic string value which relates to the key in the config. If we wanted to change this value we would have to perform an error-prone Search\Replace. Secondly, we have to manually parse the string value to a boolean – again, this is error prone as we’ll need to protect against bad data. This additional logic hides the true intent of what the method is meant to be doing which increases complexity. To make matters worse, we have a major problem when it comes to testability.

The configuration manager will automatically detect the config file based on the executing assembly, this means that your test assembly’s App.config needs to match your implementation’s (web.)config with all the values pre-configured for testing purposes. Having pre-configured values offers you very limited flexibility and in the example above we would be unable to test both paths (without our tests changing the value directly)? If we had multiple possible paths, this would cause us a very real problem.

This week I came across the issue were I required an AppSetting value. Not wanting to face the issues above I looked for help.

Thankfully, help’s available

The Castle Dictionary Adapter removes these problem for us. Given an interface and a dictionary of values, the adapter will create an object with all the properties populated for us. Our interface will match the settings in our config file.

public interface IApplicationConfiguration
{
    bool EnableNewsletterSignup { get; set; }
}

The same implementation mentioned before becomes this, with a dependency on the above interface instead of the concrete ConfigurationManager. Notice our ‘if’ statement now uses a strongly typed property without all the noise associated.

class NewsletterSignupService
{
    private readonly IApplicationConfiguration _configuration;

    public NewsletterSignupService(IApplicationConfiguration configuration)
    {
        _configuration = configuration;
    }

    public bool Signup(string email)
    {
        if (!_configuration.EnableNewsletterSignup)
            return false;

        return true; // technically this would go off to an external web service
    }
}

Testing!

The real advantage arrives when you look at the problem from the testing point of view. Because it’s an interface, we can use Rhino.Mocks to produce a stub, allowing us to test using any possible value.

var stubConfig = MockRepository.GenerateStub<IApplicationConfiguration>();
stubConfig.EnableNewsletterSignup = true;

We also no-longer need to maintain the App.Config as everything is driven by stub config objects, making life easier all round.

The next level comes when you use it with an IoC framework such as Castle Windsor. When an object defines a dependency on IApplicationConfiguration, they will be provided with an object created via the DictionaryAdapterFactory with the values coming from our actual AppSettings.

WindsorContainer container = new WindsorContainer();
container.AddFacility<Castle.Facilities.FactorySupport.FactorySupportFacility>();

container.Register(
    Component.For<IApplicationConfiguration>().UsingFactoryMethod(
        () => new DictionaryAdapterFactory().GetAdapter<IApplicationConfiguration>(ConfigurationManager.AppSettings)));

As a result of implementing the adapter together with it’s use in Windsor we have more control, less complexity and a more maintainable solution going forward.

But it’s not only for AppSettings, the Castle Dictionary Adapter works on a number of different directories and collections meaning you no longer need to index into them using strings. If you want to know more, then CastleCasts has a great screencast on this at http://castlecasts.com/Episodes/3/Show/dictionary-adapter

In order to implement this in your own codebase, Castle Dictionary Adapter is currently a separate single assembly with no external dependencies that you can download from http://www.castleproject.org/castle/download.html

Going forward, it will be part of Castle Windsor 2.5 with some interesting improvement as discussed at http://devlicio.us/blogs/krzysztof_kozmic/archive/2010/07/05/castle-windsor-2-5-the-final-countdown-beta-1-released-and-core-dynamicproxy-dicitionary-adapter.aspx

The code for the above example is available at http://gist.github.com/486603

Labels: Castle, TDD, Testing

Last week I had the amazing honour of presenting at QCon London 2010 on Testing ASP.net using Ruby. QCon was an amazing conference with some truly amazing speakers, and I did feel a little out of place :-)

Nonetheless, it was a great experience. A huge thank you to Josh Graham from HashRocket who organised the track and invited me to speak!

For those who are interested, my slides are below. Within the next six months the video should be online too.

Labels: IronRuby, QCon, Testing, TestingASPnet

I've recently had a number of discussions with various different people around consistency.

There a few really good reasons why you should be consistent in your development approach. Being able to pick-up a code-base and understand where the tests are, where external libs are stored\reference and how to build and run are fundamental when you work on more than one project. In a similar way, being consistent with setting, both application and keyboard (ReSharper) can increase productivity when working with a team as it makes it easier to share the code and pair at different machines. Having a standard and a foundation gives you the base to improve and learn from. Toyota have said “standardized tasks are the foundation for continuous improvement and employee empowerment” Wikipedia.

However, this brings about another problem. If you are continuously improving, what happens to consistency?

Many moons ago, we were all writing our data access logic using Ado.net and code-generated ORMs. Thankfully today we have NHIbernate. We have taken a standard, improved and progressed beyond it to create a new standard. This is why consistency is overrated. If we were consistent, we would had kept making the same mistakes for the sake of being consistent. The same can be said for unit testing frameworks, languages and even project structures\coding style.

However, in software many people forget the improve and progress part once a standard has been set.  We sacrifice improved productivity and adding value to the business to maintain the status quo. How many developers would push the use of frameworks like OpenRasta instead of just going with ASP.Net MVC because they did ASP.net webforms before - even when OpenRasta provides a much better solution to their problem. Or use WCF because “we are a Microsoft shop”, hence must be consistent and use the Microsoft stack.

Get a grip.

Forget consistency. Instead, focus on what makes you productive, what provides value and what makes doing your job easier. If there is a better way, do it and break free from the status quo.

Labels: Development

A while ago I was on my way to see family members. Due to working all the time, I was unfamiliar with the route so I used my GPS. During the journey I had a brainwave, a good GPS system is like a good software development team.

Imagine the roles involved in a car journey. We have the nice GPS lady, the one who knows the final result and the most effective way to get there. We have the passengers who do the work together with the backseat drivers who think they know better than everyone else involved and will take you in a different direction.

This is very similar to the structure of most project teams. Everyone knows the final destination, and some might even know how to get most\part of the way there however we have project managers guiding us along the way, step by step, even if sometimes they are just background noise telling you what you already know. We have developers\testers taking the information from the project manager and applying it using their own skills. The GPS doesn’t drive the car in the same way project managers don’t write code. Finally, we have the members of the team who always seem to know better - these are either visionaries or bad apples.

As you are driving, when you are coming up to a change in direction the GPS will tell you just enough information to put you in the best position to act when the additional information is relevant instead of overloading you with unnecessary and confusing the problem right at the beginning. As the steps are broken down and told as required, if you go wrong then the GPS can adjust itself and guide you back. These could be consideration iterations.

What if the journey wasn’t broken down into steps? You would know the end route, however you wouldn't know the quickest, or even how, to get there. Instead you would be flooded with information as soon as you enter in the car. You will be told every turn taken, every lane change. During the journey, you will attempt to remember everything, as a result relying on other indicators such as traditional sign posts. The problem is that you can easily miss a critical step and take a wrong turn. Without someone guiding you, you could be going in the wrong direction for a long period of time. This is the equivalent of a waterfall project and we all know how they end. GPS systems take an agile approach to car journeys.

But I only have a cheap GPS systems. The good (ie expensive) GPS systems respond to the environment around them.  They can sense (be alerted) to traffic ahead and as a result take a different route to ensure you get to your end goal in the most effective way. This is why you pay twice as much, as when problems occur, they can help instead of just sending you down the same old path.

I think this is the same as a good project manager. If they can see the problems coming, then they can guide the team without the team ever knowing or being distributed. This allows the team to stay focused and motivated while the project manager does the hard work of ensuring any problems don't affect the project. This is a powerful and extremely useful position and person to have. This is when both GPS systems and project managers justify their cost.

But what if you crash? Well your project just got canned and no matter how good your GPS\pm is they can't help.

Interesting what comes into your mind during a car journey.

Labels: Random

When creating test names, I use a BDD style naming convention to describe the behaviour being tested. As such, I like the naming to be in a particular, consistent style. For example:

However, as you can see Resharper is saying there is a problem because of the way the method has been named. Ideally, Resharper should allow this naming convention. With Resharper 5 (maybe in 4.5 too), you can change the setting to match how you want your naming to be.

Simply by hitting alt+enter you have some options related to Inconsistent naming.

In the settings dialog, you can set the name style. In my name, First_upper is how I like my tests to be named.

Resharper will now accept the naming. As a bonus, if the name happened to be Something_Like_This() then it would detect and provide an option to convert the naming to Something_like_this() keeping your test naming consistent which improves readability. Very cool!

However, the problem now is that ReSharper complaints on production code. For example:

Luckily, you can define two possible naming conventions as I’ve done below.

Labels: ReSharper

This week Google was kind enough to invite me to "Google Apps Premier Edition". This is the email:

I would love to use the premier edition as the free version is amazing! Sadly, the invitation was only for the 30 day free trail. After gaining my interest, Google then went and lost my interest while also making me disappointed. Not the ideal way to make your users feel.

When sending over promotional emails, take into account how the user will feel and their thought process when reading your email.

Labels: Bad Software

Yesterday was the excellent DDD8. Thank you to all who attended. I gave a grok talk and a full presentation. The grok talk was on Albacore,  while the full presentation on Testing ASP.net Web Applications using Ruby. The slides are below. If you have any questions\feedback then do please let me know.

Don’t forget, if you are interested in learning more about Testing ASP.net then my book has recently been released.

Download demo from http://github.com/BenHall/Kona/zipball/DDD8

Labels: DDD, DDD8, TestingASPnet

I have spoken to a number of people who have been put-off by installing Git as it seems difficult. To prove that it’s not, I decided to put together a very quick screencast to highlight the main points. As I wanted it to be quick and to the point I decided not to add voice-over and instead use call-outs where required.

If you want to know more, then I really recommend you check out TekPub as they have done a great series on how to take full advantage of Git.

Labels: Git

When using IronRuby to test C# applications we are still faced with similar issues as with C# – the different is how we can handle them. For example, to stub the HttpRequestBase in C#, we could use Rhino Mocks as follows.

var stubbedHttpRequest = MockRepository.GenerateStub<HttpRequestBase>().Stub(x=>x.ApplicationPath).Return(“~/test”);

I do really like this syntax and think it works for C#.  However, if we are looking to use Ruby and a dynamic language we have the potential to be more inventive.

IronRuby has an excellent framework called Caricature which allows you to fake CLR objects. For example, here we are stubbing the HttpRequestBase from MVC.

require 'caricature'
include Caricature
stubHttpRequest = isolate System::Web::HttpRequestBase     
stubHttpRequest.when_receiving(:application_path).return("~/test")    
stubHttpRequest 

However, this got me thinking. With Ruby being dynamic, how could we take advantage when defining fakes? For example, what about the following syntax:

stubHttpRequest = stub 'System::Web::HttpRequestBase
                          .ApplicationPath.returns("~/test") &&
                          .FilePath.returns("")'

This would stub two properties, ApplicationPath and FilePath to return “~/test” and an empty string respectively. If we wanted to handle method calls and arguments, we could have the following:

stubHttpRequest = stub 'System::Web::HttpRequestBase
                          .SomeMethodCall("WithArgument").returns(SomeObject.new) && 
                          .SomeOtherMethod(*).returns(-1)'

Here we stub two methods, one stubs with a particular argument (must be the string “WithArgument”) while the other matches on any argument.

My aim is to reduce the ceremony associated with the act of stubbing and instead focus on the true intent of the defined behaviour.

Note: Imagine the ‘refactoring’ problem has been solved, and changing the method names would also update the tests.

If we look at other languages, for example Javascript’s jqMock and Ruby’s NotAMock are using a similar syntax to C#.

var alertMock = new jqMock.Mock(window, "alert");
alertMock.modify().args("hello world new!").returnValue();

I think it is time to start looking beyond the existing syntax and reveal our true intent. What do you think?

Labels: Ruby, Testing

This week I went over to CodeMash, an amazing community and cross-language conference in the US. I had some amazing conversations, meet some amazing people and gave a session on Testing ASP.net using Ruby.

I would like to say thank you to everyone who attended and the organisers for giving me the opportunity to speak. If you have any questions\comments, then please give me a shout, Twitter is the best way.

The code I used during the demo can be found on GitHub - http://github.com/BenHall/Kona 

I created a tag so you can download the zip of the code, now and in the future without being affected by other changes - http://github.com/BenHall/Kona/zipball/CodeMash_2010. In future I plan to keep working on this code as a sample so you might want to keep an eye on the repository. 

Also, if you would like to know more about Testing ASP.net web applications, then I recommend you take a look at the book I co-authored, check out http://www.testingaspnet.com

Labels: BDD, book, IronRuby, TestingASPnet

RSpec, IronRuby and RubyMine is an amazing combination. Here is a screenshot of an example I’m currently working on…

All I do is execute the Rake command below, which exists in my rakefile.rb. Rubymine does the rest! Very cool.

desc "Run all examples"
Spec::Rake::SpecTask.new('examples') do |t|
  t.spec_files = FileList['examples/**/*.rb']
end

Labels: IronRuby, Jetbrains, Ruby

After downloading IronRuby and JRuby to do some hacking over the Christmas period, I wanted to add them to my PATH variable on OSX. In Windows, this is fairly easy to find but is hidden a few dialogs down.

In OSX, you need to edit the .bash_login file in your user directory. A simple nano ~/.bash_login will allow you to edit the file (replacing nano is your own favourite editor).

To add IronRuby to your path add:

export PATH=/Users/Ben/Library/ironruby-0.9.3/bin:$PATH

Import points:
1) The path to your IronRuby bin folder.
2) Ensure you add the existing $PATH to the end
3) Export the result to the current PATH variable. Note, this is case sensitive.

To add jRuby you do it in a very similar fashion. However, because of priorities and how jRuby works, unless you want jRuby to be the default, add it to the end of the path export

export PATH=/Users/Ben/Library/ironruby-0.9.3/bin:$PATH:/Users/Ben/Library/jruby-1.4.0/bin

You should now be able to see all your ruby interpreters.

As I had some free time on my hands today I decided to create a new project called Lonestar. For those of you who are interested, here is the first (working) screenshot. Can anyone guess what it is?

For those of you who are following me on twitter then you will know I’ve been mentioning Meerkatalyst for a while – all will become clear soon. For now, keep an eye on my blog, the Meerkatalyst website and twitter feeds (@ben_hall and @meerkatalyst) for more exciting news on Lonestar and other projects!

Labels: lonestar, meerkatalyst