airasoul

Soothe a soul

2012-01-26T22:00:00.005Z

Solidifying ASP.Net MVC with a single action per controller

2012-01-07T00:04:00.004Z

rza - a razor sharp folder structure for ASP.Net MVC

I recently watched Uncle Bobs skillsmatter cast on web architecture; interesting stuff.

This got me thinking about web architectures and how ASP.Net MVC applications of course suffer from the same issues Bob outlined with his rails application.

When looking at a web application code base all you see is web stuff; controllers/models/views nothing to do with the domain; you could not when looking at the root level of the codebase identify what the application did.

Well; I have recently been playing around with the idea of using a single action per controller in order to

- solidfy my controllers; MVCs noted SRP/OCP issues
- reduce the number of contributors injected into a class
- clean up specifications; in order to avoid stubbing out unused contributors

I have also been toying with the idea of changing my MVC folder structure in order to:

- group contributors/classes for a feature into a single folder structure
- include within that folder structure the specifications

So this is the folder structure I have come up with which solves the above; as you can see the specifications are included in their relevant place within the code base.

This is achieved very simply by extending the razor view engine in order to shift the folder structure around; check it out:

So; yeah; we are able to get a pretty good idea as to what this application does simply by looking in the features folder.

I have converted a blank ASP.Net MVC solution into this new folder structure; you can grab this on GitHub.

Experimentations in concurrency & asynchronicity with Node.js and chums - Part 2

2011-12-07T07:47:00.003Z

Core to node.js is the concept of events/event emitters. In order for a module to emit and respond to events; all it need do is simply inherit from the events module. In order to do this we require the 'events' and 'util' modules and use the util.inherits function to inherit from the event module.

The bhikkhu module below exposes one function 'meditate'; the function emits a '.breath' event every 3 seconds. It gets the type of breath from a 'takeBreath()' function; which returns either 'in' or 'out'.

Gist 1, module bhikkhu emitting breathe events

In order for our bhikkhu to respond to the '.breath' event; we simply subscribe to the event using the '.on' function.

A call to 'meditate()' will start the bhikkhu breathing. The text 'bhikkhu observes in/out breathe' is written to the console every 3 seconds until we stop our bhikkhu from meditating.

Gist 2, meditating bhikkhu

So why is all this important; well events and events emitters help to facilitate non-blocking IO in Node.js. Imagine for example the 'takeBreath()' function took an eternity; well; having this wrapped up in an event you can subscribe to allows the functionality to be placed on to the event queue as a callback; this stops the event loop from blocking.

Experimentations in concurrency & asynchronicity with Node.js and chums - Part 1

2011-08-04T14:10:00.038+01:00

An introduction

Node.js is a server side technology that provides an event-driven, non-blocking framework for building highly scalable; real time; network-based applications. The main goal of Node.js is to simplify the development of building such non trivial applications. Node.js is based on Google Chrome‘s V8 engine; node.js applications are written in javascript.

Node.js is not an attempt to put javascript on the server-side; javascript is effectively used as a high level DSL Ryan Dahl; the inventor of Node.js; reasons for choosing javascript are:

its event-driven; and event-driven applications are easy to scale (explained later)
every web developer on the planet has used it; I think!
javascript up until now has no concept of IO.

Node Concepts

Event-driven
Node.js applications are effectively (slight over-simplification) a series of anonymous or named functions which are executed not in any specific order but based on events happening either on the client or server. An important concept in Node.js is the event loop; Node.js programs are executed sequentially; but callbacks/requests are placed in an event queue; the Node event loop executes the events in the queue sequentially. When all events have been executed; Node will exit the event loop and then wait for more events to be added to the queue.

Event loop example
The below example is a simple node program which demonstrates the event loop.

The first statement is a timeout which takes as input an anonymous function; this is the first event added to the event queue; and will be executed after 2 seconds; this is also the last statement to be executed
The second statement is a call to nextTick; which takes as input an anonymous function; this will be executed on the next tick of the event loop. When all events/requests have been executed for the current event loop; this function will be the first executed on the next execution of the event loop.
The third statement is a call to nextTick; this function will be the second executed on the next execution of the event loop.
Finally a call to console.log; which simply prints to the console. This is not added to the event queue

Threading
Node.js makes use of a single thread; this is important; Node does not spawn new threads as per the normal concurrency model other languages and frameworks adopt in order to scale; Node side-steps the concurrency issue by exploiting javascript's ability to create, pass and asynchronously execute simple callback functions.

Node.js achieves scalability by ensuring all IO bound calls are executed in a non blocking way; i.e. by executing the IO operation asynchronously; passing a callback to the IO bound operation; the callback is executed on completion of the IO operation.

Blocking IO
Consider the following Node.js application which reads a file. When the readFileSync call is executed the application waits for a response; the thread on which that call was made will now sit and wait for a response. This thread could be doing useful work; possibly responding to new requests; it cannot; this is commonly refered to as 'blocking IO'.

Example of blocking IO

Non Blocking IO
Consider the same application using evented Node.js. When the readFile call is executed a callback method is passed with it; the thread will not wait for the file to be read; it will pick up the next event in the queue; when the call is complete the callback function is called; and the processing for the request continues; this is commonly refered to as 'non blocking IO'.

Example of non blocking IO

So why Node.js

Node.js makes an excellent fit for applications that have long running IO connections. Consider applications like Comet and HTML5 WebSockets; these make use of a lot of open connections; so a thread per connection does not scale. This is where node jumps to our rescue; with its single threaded; event-based model.

Node.js on windows; without Cygwin :)

2011-07-19T17:17:00.001+01:00

http://nodejs.org/#download

Cucumber on Windows

2011-07-19T08:29:00.002+01:00

I have spent the last few months learning Cucumber, Capybara and Ruby in order to automate my acceptance tests. I have previously used SpecFlow which is a great tool; but I wanted to see if the grass was any greener on the other side.

Below are a few tips to get anyone interested in doing the same up and running; I have included my gem listing with version numbers to assist. I conclude with a summary of things to consider when using Cucumber for .NET acceptance testing.

Install Ruby 1.8.7

In order to run Cucumber on Windows install ruby using the RubyInstaller.

Visit: http://rubyinstaller.org/downloads/
Install ruby 1.8.7; do not download and install version 1.9.2; cucumber does-knee like 1.9.2
When installing ruby select the option to “Add Ruby executables to your PATH”.
In order to verify a correct installation open a command prompt and type
ruby –v
you should see a response back stating the version number .

Install DevKit

Visit: http://rubyinstaller.org/downloads/
Download and then extract DevKit to a folder somwhere on your drive (not important where)
Open a command window; navigate to the extracted folder and at the command prompt run the following commands

ruby dk.rb init
ruby dk.rb install

Install Ansicon for Cucumber coloured output

Visit: http://adoxa.110mb.com/ansicon
Download and extract ANSICON 1.40
Open a command prompt and navigate to the extracted folder; then navigate to the folder matching your machine x86/x64
At the command prompt run ansicon.exe -i

Install Cucumber version=0.10.6

At the command prompt run the following commands
gem install cucumber --version=0.10.6

Install Rake

At the command prompt run the following command
gem install rake --version=0.9.2

Install Capybara

At the command prompt run the following command
gem install capybara --version=0.4.0

Install RSpec

At the command prompt run the following command
gem install rspec --version=2.6.0

Verify

At the command prompt run the following command
gem list

You should now have a gem list resembling the list below; if you are missing a few dont panic simply follow the same process and install each gem.

If you have gems with higher version numbers than what I have displayed here; simply perform the following:

Uninstall Gem

At the command prompt run the following command
gem uninstall --version=#gem version number#

For your consideration

Here are a few things you should consider with a Cucumber/Ruby based approach to acceptance testing for .NET web applications when not using the DLR.

Step Definition Styles; From the RSpec Book

In order to test interactions with a web based system we have three styles of step definition.

Automated Browser: Access the entire Rails MVC stack in a real
web browser by driving interactions with the Webrat API and its
support for piggybacking on Selenium. This style is fully integrated
but is the slowest to run and can be challenging to maintain.
Simulated Browser: Access the entire MVC stack using Webrat,
a DSL for interacting with web applications. This style provides a
reliable level of integration while remaining fast enough for general
use, but it doesn’t exercise JavaScript.
Direct Model Access: Access ActiveRecord models directly, bypass-
ing routing, controllers, and views. This is the fastest but least
integrated style.

Unfortunately using Cucumber/Ruby you are unable to do DMA; for obvious reasons; the code base under test is in C# not Ruby. This is an issue when the number of tests grows quite large and performance/speed of execution becomes an issue; we ideally would like to use DMA as its faster to execute.

Test data

For the same reasons test data is an issue. There are a few approaches to getting test data into acceptance tests:

Write automated tests which add data to the database via an administration tool; embedding the test data into automated cucumber stories
Running database scripts to populate the database
Adding data to the database or to an in-memory database directly via code; DMA

The first two options have issues; automating the process of adding data via an admin tool is powerful; you can perform clean-up and it can be automated; but is obviously slow. Running scripts is error prone; and difficult to clean up; leaving us DMA which is both simple and can be automated as a series of step definitions.

Cucumber on the DLR would obviously resolve these issues; so if you are able to get the DLR onto your stack I would absolutely go with that option.

Gem List
archive-tar-minitar (0.5.2)
builder (3.0.0)
capybara (0.4.0)
celerity (0.8.9)
childprocess (0.1.7)
columnize (0.3.3)
configuration (1.2.0)
cucumber (0.10.6)
culerity (0.2.15)
diff-lcs (1.1.2)
ffi (0.6.3 x86-mingw32)
gherkin (2.4.0 x86-mingw32)
json (1.5.2, 1.4.6)
json_pure (1.5.2)
launchy (0.4.0)
linecache (0.45)
mime-types (1.16)
nokogiri (1.4.4.1 x86-mingw32)
rack (1.3.0)
rack-test (0.6.0)
rake (0.9.2)
relish (0.4.0)
require_relative (1.0.1)
rest-client (1.6.3)
rspec (2.6.0)
rspec-core (2.6.4)
rspec-expectations (2.6.0)
rspec-mocks (2.6.0)
ruby-debug-base (0.10.5.jb2 mswin32)
ruby-debug-ide (0.4.17.beta3)
rubyzip (0.9.4)
selenium-webdriver (0.1.2)
term-ansicolor (1.0.5)
xpath (0.1.4)

git push appharbor who the master

2011-06-22T20:49:00.017+01:00

A bold statement ;)

AppHarbor is a cloud based hosting platform for .net applications not to dissimilar to Herouku; the Ruby on Rails based hosting platform. What interests me about AppHarbor is its integration with Git and its simple deployment process; oh and prices currently start at free :).

Features

Push and deploy new builds in seconds
Git-enabled continuous development environment
Run specifications before release; currently only supports NUnit
SQL Server/MySQL database hosting
Single click rollback via web based administration tool
Manage certificates, hostnames from web based administration tool
Can scale

Setup

AppHarbor setup and code deployment is pretty straightforward; information on how to do this can be found here.

Below is a list of issues I had during setup/deployment because I was to lazy to read the documentation properly;

Ensure you have setup ssh
Name your solution file appharbor; (annoying)
Initialise your Git repository where the solution file for your project lives; (you only want to deploy the source code; not everything else associated with your project
Ensure all your views have the their properties set correctly (this was required for my views as they are Spark Views; not sure if this is the case for all view engines)

Build Action = Content
Copy to Output Directory = Copy always

Final thoughts

AppHarbor; works well; the deployment process is seamless; rolling back a release is also simple. There are a few issues I would like to see resolved before I would consider paying for such a service:

~~No support for object databases.~~
Unable to run MSpec specifications
Your solution file has to be named appharbor; why; if I decide to use AppHarbor again for another project I will have multiple solutions with the same name
Better documentation; specifically info on how to push a subset of my codebase to AppHarbor from GitHub
No support for database migrations; currently a manual process
Restore of database and import of data into the AppHarbor database is painful

Luckily most of these features are quite high on the AppHarbor community driven TODO list; and will hopefully be resolved.

The Oneness of ju.ju.

2011-05-27T11:54:00.024+01:00

Introduction

Continuous testing is a TDD process whereby tests/specifications are automated to run when changes to files are observed on a project under development. This allows the developer to focus on developing software by minimising context switching providing a rapid feedback loop.

ju.ju. is a continuous testing tool with a difference; it will work with any combination of build, specification, notification tools. ju.ju. simply watches a directory for file changes; when a change is observed; an event is fired which calls a batch file. The batch file can perform a build, run specifications and notify you of build/specification run state.

How you build, run specifications or send notifications for your project is of no concern to ju.ju.. You could be using Rake; PSake; Fake; MSpec, Nunit, Xunit; Growl or Snarl or some other known; or yet to be created tool; it makes no difference.

Benefits over similar tools

Configure multiple projects using different build/specification tools;

Configure your unit level specifications to use MSpec and your integration tests to use NUnit.
Useful when migrating from one specification tool to another

Easily switch between different projects; for applications spanning multiple projects
Simple to use Gui allows you to configure file types to watch and exclude projects sub folders whilst developing your application

Go Git it:

https://github.com/AndrewKeig/ju.ju.

Here is a dummy project to test it with
https://github.com/AndrewKeig/SpaceJungle

ju.ju. Installation

Unzip this project to a drive near you. Place the contents of ju.ju.\release into c:\juju\. This folder should contain the following files;

juju.gui.exe.config

The file juju.gui.exe.config has a key in it which can be configured; although will work as is; this key is the location of the ju.ju. projects folder.

juju.projects

ju.ju. uses a JSON based configuration file to represent a ju.ju. project; all project files are located in this folder. A ju.ju. file has the following key/values which require configuration:

Id, project identifier

Name, the name of the project;

Description, a description of the project

DirectoriesToExclude, a comma seperated list of directories inside the folder being watched which will not be watched

DirectoryToWatch, the path to your projects solution

BatchFile, the batch file called by ju.ju. when a file change has been observed

InternalBufferSize, the internal buffer size for a process; can require a large value to enable ju.ju. to detect changes in a large file base; see FileSystemWatcher

FileTypesToWatch, the file types ju.ju. will watch; a comma seperated list of file extensions

Delay, is the delay in seconds between responding to a file save; a single file save generally results in multiple events firing; so the aim is to try and avoid responding to all and treat them as one; see FileSystemWatcher

juju.runners

This folder contains batch files which projects can be configured to use. These batch files are executed when a file change has been observed.

Below is an example batch file; this file has been configured to build, run specifications and perform notification. The below batch file takes three arguments:

The build file
The specification/test runner file
The project name

Example build file

Below is an example build file; which uses MSBuild:

Example specification/test runner file

Below is an example specificaiton file; which uses MSpec:

juju.notifiers

Below is an example notification file; which uses Growl

ju.ju. does not require you use a notifier; but if you would like notification; install Growl.

http://www.growlforwindows.com/gfw/

Working with ju.ju.

Firing up juju.gui.exe opens up the following two windows:

ju.ju. main window

This window allows you to configure and protect your projects. There are two sections; the left side is a ju.ju. config file editor; the details of the file have already been outlined in section above headed juju.projects; the right side allows you to select a project in order to edit it or protect it.

ju.ju. output window

This window displays the output of the batch file which is executed when a file change has been observed.

Editing a ju.ju. config file

Select a project on the right hand side; then click edit to make changes to a ju.ju. config file; click save to persist these.

Protecting a project

Select a project on the right hand side; then click protect to start protecting a project.

Output window displaying build and specification run.

Growl notifying user of changes

Future Improvements

UI enhancements

Directories to exclude should be changed to a multi select listbox; containing all directories under the directory being watched.
File types to watch; should be changed to a multi select listbox of file extensions
Allow user to add a new config file

Performance Improvements

Intelligent specification runs; ju.ju. runs all specifications for a file change

only run the specifications in the specification file changed
only run the relevant specifications for the subject under specification

Behaviour Driven Development with MSpec, SpecFlow, and Friends - Iteration 1

2011-04-20T17:03:00.007+01:00

In this series

In our previous post we decided to select the simplest slice of functionality from our list of stories.

In order to get us started I have done the following:

Created an empty ASP.Net MVC 3 solution
Created an empty class project - Specifications
Created an empty class project - Stories
Added the following packages to the relevant project:

Added a Specflow and Selenium base class for our SpecFlow feature files
Bootstrapped StructureMap for DI via the new DependencyResolver
Setup Spark View Engine
Setup Selenium server and Firefox plugin
Setup source control with Git

Our design for devtracks is below; this design has been split up into various Spark View Engine partials; and a page.

Creating a SpecFlow feature: Navigate to Homepage

Copy the above feature/scenario into a SpecFlow feature file; the scenarios in this feature file are acceptance tests; each Given/When/Then step within a scenario should map to a method. Start the Selenium web server; and then run your favourite test runner against this feature file.

Your test runner should report that the tests have been ignored; and will generate some SpecFlow skeleton code; a method for each Given/When/Then step.

Missing steps when running the Navigate to Homepage feature

Grab and edit this generated code and paste it into a new class file.

Edited SpecFlow skeleton code

Now run your favourite test runner against this feature file; the test runner will now declare the tests ignored; the tests have been skipped because the steps have not been implemented; they are set to pending.

Pending steps when running the Navigate to Homepage feature

Driving out the unit level code using MSpec

We now have a running ASP.Net MVC site with a single spark view. the view contains our new design. We have created a SpecFlow feature file; all steps are set to pending. We now need to get the first SpecFlow step passing. In order to do this we will need to implement some code.

SessionController specification using MSpec

If you run these specifications through; they will all be ignored and require implementation.

Lets complete the specification.

Lets create a new ASP.Net MVC SessionController.

Now re-run the specifications to watch them pass.

If we open our site in a browser; open the Selenium IDE Firefox plugin and perform the following:

1. Click the logo
2. Mouseover the logo and right click
3. Select VerifyText img[@alt='devtracks']

Fill in the details with the following:

Now re-run the acceptance tests and watch those pass.

Feature Complete!

Here's a series of screencasts for this feature; warts and all:

MongoDB is web scale

2011-04-01T14:48:00.004+01:00

Programmer Personality

2011-03-31T01:27:00.002+01:00

Will introduce this as part of my interview process..

via Sebastian Hermida

Behaviour Driven Development with MSpec, SpecFlow, and Friends - Iteration 0

2011-03-29T16:44:00.010+01:00

In this series

Introducing devtracks

devtracks aims to deliver software development videos focusing mainly on the open source .net space. The videos are a combination of software development presentations and tutorials which are already freely available but scattered around the net on various sites. devtracks aims to bring much of this content under one site.

Ubiquitous language

"With a UBIQUITOUS LANGUAGE, the model is not a design artifact. It becomes integral to everything the developers and domain experts do to together. The LANGUAGE carries knowledge in a dynamic form. Discussion in the LANGUAGE brings to life the meaning behind the diagram and code."
Eric Evans

Lets define our ubiquitous language for devtracks; devtracks will use the language of software development conferences:

A software development conference has:

Session - a single presentation/tutorial
Track - a topic/category relating to software development; contains multiple sessions
Speaker - delivers a session

Stories

Lets start our story creation process by defining the stories and their conditions of acceptance.

When writing your conditions of acceptance; ensure you limit the number of domains in a single scenario in order to avoid writing brittle tests.

Read this article by Dan North: Whose domain is it anyway?

Where to start? A Walking Skeleton

Over the years I have seen a few different approaches to getting a project up and running. I have recently settled on the idea of a 'Walking Skeleton'.

"A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function."
Alistair Cockburn

The idea of a walking skeleton is to select the simplest story available and implement this from the 'outside-in' using BDD. Our simplest story is: 'Navigate to Homepage'. We will drive out this feature putting in place various bits and pieces as we go:

Create an ASP.Net MVC 3 empty solution
Setup folder structures/projects if required
Tool selection; see list below; NuGet has made this rather simple:

Specflow and Selenium infrastructure
Bootstrap StructureMap
Setup StructureMap registry
Source control setup with Git

What comes first BDD or DDD? Well; if you are a single developer or a pair; this is not an issue; with a very simple domain model use BDD to drive out the domain; its probable you will not need a domain model; some simple DTOs/Information Holders will suffice. If you are more than a single pair? with a complex domain model; you run the danger of duplicating effort when driving out the domain model; so keeping things as agile as possible; consider the following:

Some minimal up-front design; drive out the model on paper first
Schedule the execution of stories so that you minimise duplication of effort
Introduce dependencies on a story that will drive out an aggregate root

Iteration 1

Lets Begin!

specification.patterns

2011-03-26T08:08:00.059Z

Introduction

specification.patterns is a small C# framework which helps developers focus on design rather than testing when specifying the subject under specification (SUS) and its messages/communication between its immediate collaborators.

This framework draws on the following:

Responsibility Driven Development
XUnit Patterns
Domain Driven Design
Behaviour Driven Development

Git it here

https://github.com/AndrewKeig/specification.patterns

Problem

Behaviour Driven Development at the unit level has solved the problem of documenting an objects behaviour; but we are still partially focused on testing when it comes to writing specifications.

The context contains the following important but generally overlooked elements that document quite a lot about the design of the object/system being written; these elements include:

the subject under specification

its direct inputs
its direct output

the subjects collaborators

expectations set on collaborator
indirect inputs to collaborator
indirect output from collaborator

Inputs & Outputs

"A running Object-Oriented (OO) program is a web of objects that collaborate by sending messages to each other."
{sfreeman, npryce, tmackinnon, jwalnes}

When we build the subject under specification we refer to it’s inputs/outputs in a test-centric way; we use words like expected output and actual output; this is the language of test after development.

The messages passed between objects are critical to good OOD. It is important to distinguish between the types of communication (messages) that are passed between objects.

Collaborators

"Mock Objects is misnamed. It is really a technique for identifying types in a system based on the roles that objects play."
{sfreeman, npryce, tmackinnon, jwalnes}

Mocking collaborators for a subject under specification is a design activity; you are discovering other roles and collaborators; 'Interface Discovery' whilst designing/developing a feature. To 'mock’ is the language of test after development.

We care about the relationship between objects when we are designing software so it makes sense that within our specifications we make it clear to the reader of a specification what contributors are important to a given behaviour specified and what are simply dummy objects.

TDD/BDD is a design activity?

Would it not be useful to use the language of design when designing the subject under specification and the communication between collaborators. Here are a few languages we could use:

Responsibility Driven Development
- Roles
  - Information Holder
  - Structurer
  - Coordinator
  - Controller
  - Interfacer
  - Service Provider
- Responsibilities
- Collaborators

Domain Driven Design
- Aggregates
- Entities
- Value Objects
- Services
- Repositories

xunit patterns
- Indirect Inputs (input for a contributor)
- Indirect Output (output of a contributor)
- Direct Inputs (input for a subject under specification)
- Direct Output (output of a subject under specification)

Breaking flow

When we use the builder pattern for creating inputs/outputs; creating these builders breaks flow.

Many developers prefer to use hard coded mocks over a mocking framework. Why side track yourself whilst designing an object with building a fake version of an object you are not currently designing?. If you are designing an object and you feel a given piece of behaviour should be delegated to another object simply acknowledge its existence; move on; and design the object you are actually working on.

Introducing

specification.patterns is a framework for designing the subject under specification (SUS) and the communication between collaborators. It provides the following features:

Focus on the design aspect of TDD/BDD
Introduces the language of OOD into your specification process
Plug-able roles/stereotypes based on various OOD/Specification methodologies
Clearly define the relationships between SUS and its collaborators
A generic message builder; helps maintain flow and enforces some basic DDD conventions
Automock trivial collaborators
Improves upon the specification as documentation concept
Improve readability at the context level
Assist those new to TDD/BDD interaction based testing
Reduces the noise in your specification context

Example using MSpec:

How it works

The specification.patterns framework wraps the Moq framework and exposes the Subject on a base class. With this we can do the following:

Create specific types of message for collaborating objects using a generic builder

Define a relationship with the Subject and a collaborator that plays a roll in this specification

Set a message expectation for a collaborator

Run the specification

Verify that a message expectation was executed

Extending specification.patterns

The language of design is constantly changing so the language elements (object builder) of specification.patterns is plugable to allow extension. This is achieved by simply extending the base class StereoType and implementing from the interfaces below which define what the class can do:

IHaveDependency
IHaveBehaviour
IHaveProperties

Warning - work in progress

Version 0.1 of this project is very much alpha code; it works; I think; sort off :) Basically I am throwing this out there to see if anyone sees any value in this and would like to contribute. Feel free to tell me its bollocks; my wife already did; but balancing that my 3 year old son got really excited and ripped out two of the keys on my laptop; it a’l come out in the wash..

References

Mock Roles, not Objects

Growing Object-Oriented Software, Guided by Tests

Object Design: Roles, Responsibilities and Collaborations

xUnit Test Patterns: Refactoring Test Code

Domain-driven Design: Tackling Complexity in the Heart of Software

Mock Roles not Object States

Node.Js with Socket.IO & CouchDB

2011-03-04T16:37:00.020Z

This is a first attempt at doing something that appears useful with Node.Js.

Introduction

nosoco is a real-time football score video printer which pushes changes made in a CouchDB database to a web client via Node.Js/Socket.IO.

Git that shit!

Git me here
git@github.com:AndrewKeig/nosoco.git

Setup nosoco;

Node.Js
If you want some info on how to install Node.js ->
node.js Installation on a new Ubuntu installation

CouchDB
If you want some info on how to install CouchDb ->
CouchDB installation on a new Ubuntu installation

Socket.IO
Socket.IO aims to make realtime apps possible in every browser and mobile device, blurring the differences between the different transport mechanisms. Socket.IO uses feature detection to decide if the connection will be established with WebSocket, AJAX long polling, etc based on browser capability.

In order to setup Socket.IO simply clone the git:

git clone git://github.com/LearnBoost/Socket.IO-node.git socket.io --recursive

This application requires a CouchDB database; as defined in couchdb.json with the following fields:

Hows it work

Changes made to the CouchDB database are picked up on the couchdb _changes stream; the node clip below attaches an Node event listener to the CouchDB change stream.

The node server will respond to this change event. The steam only contains the ids of the items that have changed so we have to go back to the database to get the data. We then construct a json doc and push these to the client.

On the client side we have some javascript which responds to the change data stream; the socket connects to the node server and responds to events via the on method.

Run it

Run the node server with the following command:

sudo node server.js

Now visit your browser;

http://127.0.0.1:8080/Client.html

In order to change the scores simply update the 'team_1_score' field using Futon or curl to push changes to the client...

CouchDB installation on a new Ubuntu installation

2011-03-01T10:57:00.021Z

The below outlines the steps taken to install CouchDB on a new Ubuntu installation.

Install CouchDB:
sudo aptitude install couchdb

Make sure CouchDB installation completed successfully; open a terminal and enter:
curl http://127.0.0.1:5984/

You should receieve JSON formatted welcome message:
{"couchdb":"Welcome","version":"0.10.0"}

CouchDB comes with a built-in web-based administration interface called Futon; visit this site:
http://127.0.0.1:5984/_utils/

The right side navigation has a tools section; click the 'Test Suite' link and run the tests to confirm all components were installed successfully.

We done.

node.js Installation on a new Ubuntu installation

2011-03-01T10:39:00.013Z

The below outlines the steps taken to install node.js on a new Ubuntu installation.

Install various libraries: including git:

sudo apt-get install g++ curl libssl-dev apache2-utils git-core

Now download node.js using git:

git clone git://github.com/joyent/node.git

We are ready to install node.js; type the following:

cd node
./configure
make
sudo make install

Create a file called helloworld.js; stick the following into it:

gedit helloworld.js

var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/');

To run the hello world server:

node helloworld.js

In a browser visit:

http://127.0.0.1:8124/

To install NPM:

curl http://npmjs.org/install.sh | sudo sh

Behaviour Driven Development with MSpec, SpecFlow, and Friends

2011-02-05T15:32:00.008Z

In this series

"Behaviour Driven Development is a 2nd generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, Agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters."
Dan North

Introduction

This is the first in a series of posts; where I implement a small web application using Behaviour Driven Development focusing on not just a specific tool; but more importantly outside-in development as a software methodology.

The title of this series of posts has been adapted ~~stolen~~ from the excellent book with a very similar name :) Behaviour Driven Development with RSpec, Cucumber, and Friends; go and buy this great book; when you’re done reading this.

My main aims for this project are:

to drive the development process from the outside in
to document the systems behaviour; so that stakeholders at various levels can understand it
to increase flow and reduce noise during the specification process.

Behaviour driven development - an outside-in software development methodology

"Behaviour driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria."
Dan North

Most projects fail due to poor or a lack of communication at some level; Behaviour Driven Development aims to bridge these communication gaps by:

using a ubiquitous shared/common language allowing stakeholders to communicate intelligently about the domain
driving out the real value in building a given feature
acceptance criteria for a scenario written in the Given/When/Then grammar as a definition of done
executable scenario and examples act as a living document of how the system works
obtaining feedback early on in the development process; showcase features developed during a given iteration

Outside-in methodologies promote development according to stakeholder requirements in order to reduce the chance of building software that won’t be used. It improves stakeholder communication and helps developers write the minimum amount of code in order to complete a story.

Behaviour driven development for scenarios

"BDD tools come in two flavours - the "unit testing" flavour (such as NSpec and RSpec) and the higher level acceptance testing flavour such as Cucumber, JBehave or other clones of these tools. Cucumber's main goal is to involve more people and roles in acceptance testing and requirements, and make it an enjoyable (addictive) experience."
Aslak Hellesøy

At the scenario level our reasons for doing behaviour driven development are different to that at the unit level; we want to bridge the communications gap between all stake holders. We agree on a ubiquitous language and a definition of done. We write our scenarios/conditions of acceptance in conjunction with stakeholders in English. We use a tool which allows us to execute a stories scenarios/conditions of acceptance as a series of tests. A stories scenarios gives the developer a clearly defined start and end point as to where to start the development process and what is considered done for a given scenario.

I will use SpecFlow to write stories/scenarios.

Behaviour driven development for unit level specifications

"You write a specification that nails down a small aspect of behaviour in a concise, unambiguous, and executable form. It's that simple. Does that mean you write tests? No. It means you write specifications of what your code will have to do. It means you specify the behaviour of your code ahead of time."
Dave Astels

BDD at the unit level is basically about reaffirming good TDD practices; many people often refer to BDD at this level as ‘TDD done well’. TDD is not really about testing at all; its a design process; wherby the developer specifies the behaviour to be written.

At the unit level I am not concerned with writing specification in plain English; the issue is not really about communication with stakeholders outside of the development team; the reasons for doing BDD at this level are different to that at the acceptance specification level.

"While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails."
Dan North

We want to move away from the idea that we are testing the system; we are in fact documenting the system being developed by using examples; specification by example. The verification and test coverage aspects are mearly side effects of this specification process; once we have completed this specification process we will be able to verify the systems behaviour and have test coverage.

I will use MSpec to write unit level specifications

Outside-in software development cycle

The below diagram outlines the behaviour driven/outside-in approach to software development:

Iteration 0

I will discuss the requirements for this project and start defining stories and their scenarios/conditions of acceptance.