Twitter bootstrap rails updated to bootstrap v2.2.2

Just a quick one: I’ve updated twitter bootstrap rails to bootstrap v2.2.2 which includes a fix (among others) to address the issues with iOS devices and button group drop-downs.

Go forth!

Cucumber, webrat and mechanize

There have been a few questions over on the webrat lists with regard to setting up a working environment for testing externally hosted web applications. This is actually a lot easier than perhaps what might be expected. I put together a quick sample over on github:

http://github.com/benlovell/webrat-mech/tree/master

With one caveat that this only works for static content as javascript will not be interpreted by mechanize. I will put a selenium based sample up shortly to counter this.

Advertisement

Sinatra: Matching routes with or without trailing slashes

I felt compelled to post this as it took me more than a few minutes to figure this one out. Sinatra treats URLs with/without trailing slashes differently unless you append “/?” to the end of your route like so:

get "/test/?" do
    'in test'
end

The route specified above will match both “/test” and “/test/”.

Windows 7 on the unibody MacBook Pro via bootcamp redux

If you follow me on twitter you would know I recently upgraded my Windows development environment from the first beta installation of Windows 7 x86 to the latest available build. This time round I’ve gone for the 64bit edition to make use of the 6GB of RAM I have installed in the beast.

I have to admit I’ve never performed an upgraded installation of an operating system before as I much prefer starting from scratch. So as you can imagine I was more than curious to see how this would pan out. Especially since the machine is pretty critical to my work — in the .net world at least. Well I’m pleased to say the whole experience went by completely without incident. The process took around one hour in total which included the OS install and the migration of all my applications, settings and the rest of the gumph.

I tend to spend more time in OSX lately since I’ve been working with Ruby a lot more recently but I will say this: Windows 7 is becoming a pleasure to use with each new build. For beta software it is rock solid and the MacBook Pro is very well supported driver-wise. The fact I rely on it daily for work is testament to that. A good acid test for me is seeing which OS I boot into for my day-to-day web browsing, tweeting and like… It almost pains me to admit that this has been Windows 7 more than OSX lately. However despite the wait, we’ll see if the balance is restored when Snow Leopard arrives.

Windows 7 on the new Aluminium MacBook via Boot Camp

I’ve spent a lazy Sunday afternoon installing the latest Windows 7 beta on my MacBook via BootCamp and everything has gone swimmingly.

To install I had to:

1. Burn the ISO. I chose the 32 bit edition.
2. Run the boot camp assistant on OSX to partition the drive. I created a 45GB partition for my initial experiments.
3. Reboot the machine with the installation DVD in place.

Pretty simple. After the installation had done it’s thing, Windows started up in a pretty skanky looking desktop. This was cured pretty easily by running the boot camp setup from the OSX installation DVD. This installs the necessary drivers for the iSight, system devices, track pad and your other Mac hardware. A quick reboot and I was back in business and sporting transparent windows and a screen resolution greater than a pocket calculator.

I couldn’t get the Apple wireless keyboard and mouse to pair up over bluetooth but I’m certain a fix for this isn’t too far away.

One small hiccup I did solve was with connecting the 24” LED cinema display. After extending my desktop onto the display I noticed the brightness of the external display was very low compared to the MacBook’s display. This was solved by running the boot camp control panel and altering the brightness from there.

Windows 7 absolutely screams on this machine in boot camp as I expected. I’m still installing Vs2008 and the rest of the .net tools so I’ll report back once I get going.

Growl notifications with autotest made easy

Setting up a new project to use growl notification via autotest can be a bit tricky. There is a fantastic gem called growl-glue that can simplify the whole procedure. Simply:

[sudo] gem install growl-glue

Then add the following lines to your .autotest file:

require 'growl_glue'
GrowlGlue::Autotest.initialize

initialize will accept a block containing a stack of different configuration options. Take a look at what is possible here.

MacWorld 09 Keynote 5PM (gmt)

OK so only a couple hours until the MacWorld 09 keynote kicks off. I’ll be following it at macrumorslive.com and on twitter via macrumors.

I’m hoping to see a new mac-mini which will supplant the Apple TV I have sitting in my front room. Other notable rumours:

• MacBook Pro 17″ refresh. Should be moving to unibody design, possibly announcements of quad-core.
• Some kind of merger between Apple TV software and the new mac-mini. Hoping for this one.
• LED Cinema Displays replacing the existing cinema displays.
• Larger form-factor iPod Touch like device. Would be ultra-cool but unlikely in my opinion.
• Refreshes across the MacPro and iMac lines. Potentially quad-core in the iMacs.
• Mini DisplayPort added across the board.

Excited yet?

Windows Server 2008: Live writer and messenger installers

At last! With the latest RC of the Windows Live tools you can now successfully install them on the Server edition OS’s. Go and grab them here.

How would you like to be in charge of the legacy systems?

Dilbert

🙂

The hiatus is officially over

I’m back and badder than ever. This time with even more poorly punctuated ramblings. So what have I been up to I hear you all (not) asking?

• Working on a couple of small ruby on rails gigs.
• Adding features to my very own top-secret sideline gig (hush hush!)
• Some .net bits with the Castle framework but of course.
• Helping a friend with a hosting startup. Purchasing and configuring various doses of servers, firewalls, switches, DNS, reverse proxies… I’ve certainly learnt a lot the last few months.

Not to mention I have a few interesting happenings coming down the pipeline so do stay tuned!

Incremental development with Monorail: Part Seven

Since our last installment I slipped in a ninja-edit to one of the configuration files. This was to ensure that our sole service was marked as transient rather than the default Windsor lifestyle of singleton. This was pointed out to me by an eagle-eyed commenter and was an oversight on my part. So we’re now at rev10 and ready to roll once again!

In our last post we tidied up a few bits and improved our code-base rather than actually adding features as such. This time we’re going to move down into the persistence and start to drive out this notional layer.

We’re going to handle data access using the repository pattern. The repositories will work on our ActiveRecord entities ensuring they’re persisted to our database. We will introduce a new interaction between our service BlogPostService and the newly introduced repository interface IBlogPostRepository. Let’s get on and write a test:

The test above is fairly self-explanatory. We’ve introduced the IBlogPostRepository and we’re passing it into our BlogPostService which should then call the Save method passing our mapped post. We need to get rid of the red code and get the test passing, so first we must create our new interface, and then modify the service constructor:

We need to modify our other tests that construct the BlogPostService as they’re still assuming only a single argument constructor exists. As we have some duplication going on we’ll push this construction up into our setup code:

We should be able to run our tests in this fixture now:

As expected, since our BlogPostService doesn’t actually do much with our repository yet, we need to do some pretty minor tweaking to pass this test:

Let’s try again now:

  Cool, let us try and run the whole suite including our integration type tests:

The integration tests are failing as we’ve yet to map the new dependency in our Windsor configuration. We can specify this now:

We still have failing integration tests though, so we need to add the BlogPostRepository specified in our configuration:

As you can see it doesn’t do much, but we just want our tests passing at this stage. Let’s run the whole suite of tests now:

Great, we have a working product once more. I’m going to finish here, as ever, the latest changes have been committed:

http://code.google.com/p/mr-blogengine/

Next time we’ll make our new repository more useful and finally hit the database!

Incremental development with Monorail: Part Six

We finished up in part five with a full suite of passing tests and our BlogPostService is slowly taking shape now. The next few posts will introduce persistence and validation but before we get started on these features, we have a little housekeeping to perform on our existing code.

First step is to build the Castle trunk and update our references to the latest versions. Secondly, we’ll incorporate a few changes suggested by Hammett.

After building and replacing our references with the latest Castle build I’ll run the tests as a sanity check before we proceed:

With that out of the way our first code change will ensure we play nicely with HTTP. It is considered good practice to ensure requests which update or create resources is carried out via POST – so we can modify our only PostController.Save action to ensure this is so but before we do this we’ll write a test:

Running our test produces the following:

We’ll modify our Save action now to ensure we only accept the POST verb:

We have added the AccessibleThrough attribute and explicitly specified that our action must only allow the POST verb. We’ll run our test again and make sure everything is working as expected:

The next step is to modify our add.vm view to use the helper methods to generate our form tags. We’ve done that and once again we’ll run our tests:

I’m noticing a little duplication creeping in to our integration tests that should be removed. Also, until now we’ve had to assume that a web server is running on a specific port on our development machine in order to run the integration tests. Through a little tweaking we can spin-up a temporary server in our test fixture setup code and host our test code there instead.

First we add the WebDev.WebHost.dll to our lib project directory and ensure we’re referencing this from the testing project. The next step is to create an app.config file in the testing project so we can configure where and from which port our testing server should be hosting from:

  Now we add some setup code for the fixture:

We’ll also make sure we bring the server down when we’re finished:

Now ensure the VS web server is not running on the same port, then we can run our tests and make sure our latest changes work out:

Now, since we specify the web root and port through configuration, we should also use these configurable values to determine the URLs in our tests:

You can see our tests now call BuildTestUrl to determine the full URL where we’re hosting the development server. Neat. I’m sure when we add further integration fixtures we’ll extract class this, but for now we have a nice working set of tests and should remember the principle of YAGNI!

I’m going to cut this installment short here. In the next post we’ll get back into the swing of it and continue implementing features.

As ever, the latest code has been checked in and is available here:

http://code.google.com/p/mr-blogengine/

MVC Storefront

Rob Conery has been posting a series of screencasts featuring the development of an ASP.NET MVC based product catalogue. This is being carried out in a “TDD” like fashion. The interesting difference between his posts and mine (apart from the obvious fact that I’m lazy and haven’t screencasted… yet) is that he starts from the bottom of the stack and works upwards towards the UI where as I do the opposite.

Its interesting contrasting the two approaches not to mention the differences between the ASP.NET MVC framework and Castle Monorail way of getting things done.

Incremental development with Monorail: Part Five

Welcome back. In this post I’ll be getting our tests passing again and cleaning things up a little. We left off with a failing integration test:

I suspect this is due to the IBlogPostMapper dependency we introduced to our BlogPostService not being handled by the container. If we run in the browser we can confirm this is in fact true:

As we’ve yet to implement our IBlogPostMapper we must go ahead and do this before we can add the container configuration to pass our integration test. Lets bust out a test and get things rolling:

We have a few blanks to fill in in order to get this to compile and run:

1. Make the DTO’s properties virtual so we can mock them. This is in preference to extracting an interface.
2. Implement IBlogPostMapper.
3. Add the necessary properties to the IBlogPost interface.

Lets go ahead and do this now:

IBlogPostMapper minimal implementation:

 

The necessary modifications to IBlogPost:

Now we can compile and run our test:

Our BlogPostMapper implementation is throwing an exception so lets go back and take another step to try and pass our test:

BlogPost:

I’m pretty certain we’ve done enough to pass our test now. Lets have a go:

OK now lets focus on the full suite:

Our integration test is still bombing but as we’ve got a mapper now, we can go ahead and wire up our Windsor configuration and get things moving again:

We’ve added another configuration file: mapper.config and referenced this from the web.config. We shouldn’t need to do any more than this so lets run our full test suite:

Our full suite is passing now. Not bad for 5 minutes work! As usual the latest changes are checked in to the Google code project hosted here.

Now we have a full passing suite, in our next edition I’ll be moving down into the persistence and also incorporating a few modifications from Hammett. Stay tuned!

Incremental development with Monorail: Part Four

We finished up in the last instalment by moving down a layer into our newly introduced BlogPostService. Our tests are passing yet our application is still pretty lacking in the actual functionality department. To move things on a stage further we need to:

1. Map from the AddPostRequestDto to our actual BlogPost aggregate root.
2. Validate the BlogPost.
3. Persist our new BlogPost.

We need to write another test to flesh out the interaction between our service and something that can map from the DTO to our BlogPost:

We’re now expecting the BlogPostService to accept the mapper in its constructor, and defining an interaction between the service and the mapper. Before we can get this to compile we need to make a few more changes to our test fixture:

We’ve modified an existing test to allow for our new dependency and performed some setup tasks. We’ve introduced the IBlogPostMapper and IBlogPost interfaces by way of our test. Running the test causes the compiler to choke so lets go ahead and implement what we need to pass the tests:

Lets go ahead and run our BlogPostServiceFixture tests:

Righteo, that went well. For the sake of completeness lets run our full test suite:

The integration test is failing as we’ve yet to wire up the BlogPostService dependencies in the container. Before we can do this we need to drive out the interfaces we’ve introduced. We’ll do that in the next post.