Not much of an invitation – Thanks Google

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

2010-02-06_1621.png

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.

DDD8: Albacore and Testing ASP.net Web Applications using Ruby

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 questionsfeedback 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.

cover[1]

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

Quick screencast: Installing Git

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.

Time for a new stubbing and mocking syntax?

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().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?

Testing ASP.net using Ruby – CodeMash session

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 questionscomments, 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

RSpec, IronRuby and RubyMine

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

Rubymine_tests_passing

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

Adding IronRuby and JRuby to your OSX path

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.

Ruby_OSX.png

A sneak peek at Meerkatalyst.Lonestar

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?

Meerkatalyst.Lonestar Hello World Screenshot

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!

This is why I hate regions

I just loaded up a default from Microsoft built into the Visual Studio 2010 extensibility and was greeted with this:

image

If someone could tell me what this region is actually adding to the code-base then I would love to know! Personally, it’s just a pointless layer of abstraction.

If your interested in what is happening within the region, well it gets worse. This is the code:

image

Instantly, I notice the following problems:

1) The comment to code ratio is very high. This makes seeing the code harder.

2) The attribute to code ratio is very high. This makes seeing the code harder, however it does have some useful information.

3) The class name is not at all related to the file name. This can cause real confusion when attempting to navigate and understand a code-base. Please, don’t do it.

What would happen if we wrote code like this:

image

The true intent of the code is now very clear without having to read anything! Stop hiding code and just show us the true aim.

Ideally I would also want to remove editorAdornmentLayer however MEF uses this, as such I need to leave it.