Introduction to WCF

This blog shows how to create a Visual Studio 2010 C# console application that hosts a Windows Communication Foundation (WCF) service exposing string manipulation methods.

The purpose of WCF is to simplify the communication of distributed applications on Windows. Because WCF uses RESTful communication and implements SOAP it can therefore operate with multiple platforms.

Creating the service

In Visual Studio 2010:
File > New > Console Application > Name: Service

Open the project’s properties and change the namespace to: Glyde.ServiceModel.Examples
Change the Program.cs namespace to use the Glyde.ServiceModel.Examples namespace.

Add System.ServiceModel.dll to the project.
Create a new public interface: IStringManipulator.cs, this will expose methods to add two strings together, replace part of a string and remove a substring.

Add a reference to System.ServiceModel in the interface.

Add a service contract to the interface:

[ServiceContract(Namespace = http://Glyde.ServiceModel.Examples)]

And add [OperationContract] to the exposed methods:

[OperationContract]
string Add(string s1, string s2);
[OperationContract]
string Delete(string s1, string s2);
[OperationContract]
string Replace(string s1, string s2, string s3);

Next we create a WCF service contract.

Create a StringManipulatorService class to implement the interface methods.

public string Add(string s1, string s2)
{
return s1 + s2;
}

public string Delete(string s1, string s2)
{
return s1.Replace(s2, string.Empty);
}

public string Replace(string s1, string s2, string s3)
{
return s1.Replace(s2, s3);
}

In the Program.cs create a URI object to serve as the base address – this will be used by the client to call the service:

Uri baseAddress = new Uri("http://localhost:8000/GlydeServiceModelExamples/Service");

Create a service host for the StringManipulatorService

ServiceHost selfHost = new ServiceHost(typeof(StringManipulatorService), baseAddress);

Add a service end point

selfHost.AddServiceEndpoint(
typeof(IStringManipulator),
new WSHttpBinding(),
"StringManipulatorService");

Enable the metadata exchange, for HTTP:

ServiceMetadataBehavior smb = new ServiceMetadataBehavior(); smb.HttpGetEnabled = true;
selfHost.Description.Behaviors.Add(smb);

Start the service
selfHost.Open();
Add a
Console.ReadLine();
…to keep the service running.
Call close to stop the service from running:
selfHost.Close();

Create a WCF client

Create a console application called Client, implement this in a separate application so the service and client can be run from a separate debug solutions – this will help your understanding and allow you to debug both.

Add System.ServiceModel.dll to the project and add the reference to Program.cs

How to use the service utility to create the client proxy

Switch back to the service solution and start the console application by F5

Start the Visual Studio command promptNavigate to the client projectRun the ServiceModel

Metadata Utility Tool to create the client code and configuration file (generated proxy):

svcutil.exe /language:cs /out:generatedProxy.cs /config:app.config http://localhost:8000/GlydeServiceModelExamples/Service

This will generate the files in the client project folder:
generatedProxy
app.config

Add these to the client project by using ‘Add existing item’.

Remember, if you modify or add new methods in the service, the client proxy will have to be recreated.

The app.config specifies the location of the service, the binding and contract interface.
Call the service via the proxy

Create an endpoint address and a WCF instance client in the Program.cs.

StringManipulatorClient client = new StringManipulatorClient();

By adding the app.config and generatedProxy.cs the StringManipulatorClient is automatically available in the project.

Don’t forget to add System.ServiceModel to the project and add a reference in the Program.cs file.

Make a call to the client:

string value1 = "Hello Hannah, ";
string value2 = "how are you today";
string result = client.Add(value1, value2);
Console.WriteLine("Add({0},{1}) = {2}", value1, value2, result);

value1 = result;
value2 = "Hannah";
string value3 = "Emma";
result = client.Replace(value1, value2, value3);
Console.WriteLine("Replace({0},{1}) = {2}", value1, value2, result);

value1 = result;value2 = ", how are you today";
result = client.Delete(value1, value2);
Console.WriteLine("Delete({0},{1}) = {2}", value1, value2, result);

Close the client after use:

client.Close();

So that’s it, I hope I have wept your appetite to learn more about WCF – As ever I have uploaded my source to GitHub click here to get the source from my introduction to WCF.

Agile Software Development

What does it mean to be Agile?

There are a number of strategies and working practices available for Agile software development, I have included the process that works for me; this is based on my real life experiences working with stakeholders (more about these in a moment), developers and testers.

Scrum

What is Scrum? During a project the customers can change their minds about what they want and need (also called churn) these challenges cannot be addressed in a planned manner. Scrum uses a pragmatic approach, in most instances these problems cannot be fully understood therefore a focus on capitalising on the team's ability to delivery quickly and respond to emerging requirements.

Daily Scrum

A stand up meeting called a Daily Scrum takes place at precisely the same time every day - 10 am is a good time as the team members have had the time to know what they are doing by this point. If your team is distributed then use a video conferencing tool (e.g. Skype).

There are three roles in a Daily Scrum:

On the officials in the 2007 Tech-Texas game in Austin:

"It's a little like breakfast; you eat ham and eggs. As coaches and players, we're like the ham. You see, the chicken's involved but the pig's committed. We're like the pig, they're like the chicken. They're involved, but everything we have rides on this."

Pigs

The developers and testers play the part of Pigs, they have no longer than one minute to describe what they did since the last Daily Scrum, what they are doing today and what blockers they think they may have to do today's tasks.

If anyone has an questions or comments they should take place outside of the Daily Scrum.

Chickens

The stakeholders (customers) play the role of chickens - they can listen but not speak. If they have any questions they should go through the Scrum Master outside of the Daily Scrum meeting.

Scrum Master

The senior member of the software team usual a Team Leader will take the role of Scrum Master, they ensure the Daily Scrum starts on time and that everyone takes turns to speak. The Scrum Master can also be a Pig.

Sprint

Sprints are a part of the Scrum methodology.

Sprint planning meeting

A sprint cycle lasts for two weeks.

Select the work to be done

User Stories

The Scrum Master meets with all the Stakeholders in a single meeting to gather the user stories.

In order to process the user stories quickly cards should be used to write a short sentence that describes the functionality in the form:

As a [role] I want [requirement] so that [business need].

The Stakeholder writes the card and passes it back to the Scrum Master, only one card is completed at a time after being discussed with the other Stakeholders.

The number of User Stories gathered in the Sprint Planning Meeting will vary depending on the size of the team for a small team of four developers, ten User Stories would be a fair number.

Each User Story will have a number of scenarios written on the back; these will form the tests.

Story Points and Planning Poker

After the User Stories are gathered the Software Developers and Testers go through each User Story and assign it a number of Story Points.

The highest number is the most complex and time consuming, the lowest is the simplest and shortest: 0,1,2,3,5,8,13,20,100. 100 alerts you to the fact that you have an Epic Story which should be split in to multiple stories.

A game of Planner Poker should be played, this can be done with Planning Poker cards or if your team are distributed - this can be done over an IM - The Scrum Master asks everyone to get their numbers ready and all hit Enter at the same time.

The Scrum Master records the Story Points against each User Story, no more than 5 minutes should be spent on each User Story.

Prioritisation

The User Stories with Story Points should be reported to the Stakeholders in person, they then order the cards by relative priority.

Tasks and durations

The Scrum Master asks each of the Developers if they have any holiday booked for the next two weeks, this is subtracted from the number of hours in the Sprint.

A Sprint is always two weeks long, due to outside forces, answering emails, meetings, urgent issues (real life) I allow for six hours per day on a Sprint. So if a Developer is in then they are available for sixty hours for the two weeks. I recommend using Pair Programming so this will be the hours shared between your developers (i.e. sixty hours for two Developers).

Get the Developers and Testers together, take each User Story ordered by highest priority first, split in to Tasks i.e. Analysis, Design, Database schema changes, Development, Testing, Deployment. Speak directly to the individuals most likely to implement the User Story (Developers and Testers should work on a single User Story rather than a single Task), ask them to say how long they think the Tasks will take. The other Developers and Testers can verify this.

Create a table in a spreadsheet with sixty at the top and subtract the hours for each User Story from the Developers available hours, eventually this will get to less than zero, all User Stories in positive numbers will be what the team can commit to.

The Scrum Master meets with the Stakeholders and provides them with the list of User Stories that can be committed to in the two week Sprint.

Story board

A Story board is created for each Sprint, User Stories have a state during the Sprint:

Backlog > In progress > Code ready for review > Code reviewed > QA Ready > [QA Passed][QA Failed] > Deployed

There is another state called Waste, this is used for any duplicate or erroneous User Stories.

The Developers are encouraged to move their User Story to the next Sprint, this should be viewable by the Stakeholders, web based story boards are available this is useful for distributed teams.

Sprint review meeting

Once the two week Sprint is completed, the Developers and Testers meet with the Stakeholders to review the work that was completed and not completed. A demonstration of the completed work is shown to the Stakeholders. There should be a four hour limit to this meeting.

Any User Stories not completed in the Sprint go in to the Sprint Backlog.

Velocity

The number of Story Points completed in the Sprint gets recorded against the User Story, this becomes the velocity of the team.

After three Sprints the velocity will start to even out and give the Stakeholders an idea of the amount of work that can be done in a Sprint.

Charts

There are two charts I have found useful, the first is a Daily Burndown Chart, this is where the number of hours the Developers spent on the Sprint each day is recorded against the number of available hours.

The second is the Release Burndown Chart, this shows the estimated number of Story Points in the Sprint against the actual Story Points completed, this chart can be extended to also include the velocity.

Sprint retrospective

This meeting is attended by the Developers and Testers, all team members reflect on the past Sprint, make continuous process improvements , what went well and what can be improved, there should be a three hour limit to this meeting.

Extreme Programming (XP)

There are a number of XP elements, the one I find most useful is Pair programming. Software developers sit at a single Development workstation they take it in turns to be at the keyboard - known as the Driver, as a Developer types they describe what they are doing to the Observer. The Observer reviews the code as it is being typed, therefore code reviews do not need to be done after a task is completed and the quality of the code is far superior than if done on their own.

One common issue is one of swapping, if this does not feel natural then switching every thirty minutes is a good compromise. Other benefits include a lack of fatigue, knowledge sharing, a boost in morale, not skipping unit tests. New Developers can pick up the workings of the team quickly and people are less likely to interrupt a pair of programmers.

Other distractions can be email, one solution to this is to have a separate PC that individuals can use to read their email.

Summary

By employing these Agile Software Development methods my team are able to work in a more efficient way, there is little or no context switching between tasks, the quality of work has improved and the implementation matches the requirements closely. The Stakeholders feel engaged with the development process and see results more frequently than through the waterfall model.

Introduction to Ruby on Rails

Introduction

I am a .NET developer and have been programming ASP.NET in C# for a number of years, I have been hearing some pretty wonderful stuff about Ruby on Rails and wanted to see for myself. This post is about my discovery of this framework from the unknown to creating an ecommerce site from scratch.

Environment

IDE: NetBeans IDE 6.8

Ruby Platform: Build-in JRuby 1.4.0

Server: GlassFish v3 Domain

Database: MySQL

Application

The application is simple and one that followers of this blog will recognise. It is a simple eCommerce shop with the data structured in to Products, Categories and Basket.

The purpose is to show how quickly an application in Rails can be created and takes you through the steps to set this up.

Prerequisite

You will have loaded in the Ruby and Rails plugin for NetBeans

Create the Project

In the NetBean IDE select File > New Project

Give your project a name e.g. ‘RailsShop’

See the environment section above for other settings.

Unselect ‘Add Rake Targets to Support App Server Development’

Database Configuration: Specify Database Information Directly

Database adapter: mysql (jdbc)

Database name: RailsShop_development (it will also create ‘_test’; ‘_production’

User name: localhost

Password xxxxxx

Install rails: 2.3.4

Create and set up the database

Right click on the project in the Project window > Run/Debug Rake Task> db:create

Add the tables

Right click on the project > Generate

Generator: model

Arguments: category name:string

Arguments: product category_id: integer name:string price:decimal url:string

Arguments: basket product_id: count:integer

Note that the model is created in the Models folder – this does not define the fields in the model, these are specified in the Database migrations folder. The database will not be updated until the database migration has been called.

The convention is to use the foreign key to be the model_id.

Primary key ids are created automatically as are time stamps.

Define the association between the models

A basket has products, edit the \models\basket.rb to:

class Basket < ActiveRecord::Base
 belongs_to :product
end

and so on with the rest of the models

class Category < ActiveRecord::Base
 has_many :products
end

class Product < ActiveRecord::Base
 belongs_to :category
 has_many :baskets
end

Update the database

Right click on the project > Migrate Database > To Current Version

If you get an error like this:

The driver encountered an error: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Unknown database 'railsshop_development'

rake aborted!

The db:create failed silently in which case you will need to create the database manually – I did this in mySQL Workbench – this is a known issue and is discussed in the Knowledge base.

You should be able to update the database to the current version.

If for any reason you need to reset the database to its empty state run:

Right click on the project > Migrate Database > To Version 0 - Clear

Adding sample data

Right click on lib\tasks

Create db_load_dev_data.rake (using Other\Empty file) – these isn’t support for the .rake extension by default.

namespace :db_load_dev_data do
 desc "This loads the development data."
 task :seed => :environment do
   require 'active_record/fixtures'
   Dir.glob(RAILS_ROOT + '/db/fixtures/*.yml').each do file
     base_name = File.basename(file, '.*')
     #say "Loading #{base_name}..."
     Fixtures.create_fixtures('db/fixtures', base_name)
   end
 end
 desc "This drops the db, builds the db, and seeds the data."
 task :reseed => [:environment, 'db:reset', 'db:seed']
end

The code reads the yml files and loads the data in the database:

Create a new fixtures folder under the \db\ folder and create a file for each table i.e. products.yml.

Note: in Files view \db\ equates to Database Migrations in the Projects view.

Right click on the project > Run/Debug Rake task… > [refresh tasks] > db_load_dev_data: seed

It is important to specify the id of using test data – this allows for the foreign keys to be specified otherwise the id will automatically generated.

Here is an example with two products:

Concorde Bikes PDM Team Replica Road Bike:

category_id: 1

name: "Concorde Bikes PDM Team Replica Road Bike"

price: 699.99

url: "concorde-bike-pdm-ind.jpg"

Kestrel Talon Tri 105 2010:

category_id: 1

name: "Kestrel Talon Tri 105 2010"

price: 147.99

url: "kestral-talon-tri-ind.jpg"

To remove the sample data right click on the application > Run/Debug Rake Task… > db_load_dev_data:reseed

Routes

To utilise shorthand like:

<%= link_to category.name, category%>

Ensure you have entries in the \Configuration\routes.rb:

map.resources :category
map.resources :product
map.resources :basket

More on this later.

Create the controllers

The scaffold generation will create controller methods for CRUD application, as we are displaying the site in read only we will not create with a scaffold.

Note, do not delete the application_controller.

RailsShop > Generate > controller > Category. Views: index, show

This creates:

\Controllers\category_controller

\Views\category\index.html.erb

\Views\category\show.html.erb

Edit the controller index – this is used to display all the categories

def index
 @categories = Category.all

 respond_to do format
   format.html # index.html.erb
   format.xml  { render :xml => @categories }
 end
end

Show is used when a single category is selected:

def show
 @category = Category.find(params[:id])
 respond_to do format
   format.html # show.html.erb
   format.xml  { render :xml => @category }
 end
end

We also need to create a controller for product and basket.

Product views: show

Basket views: index, update, delete, add_to_basket

Partial Views

As we want to show the categories, products and basket summary on the same page we need to use partial views.

In rails the partial views need to be located in the same folder as the containing page.

So for our example the Category show view is set out as:

\Views\category\_basket_list.html.erb

\Views\category\_category_list.html.erb

\Views\category\_product_list.html.erb

\Views\category\show.html.erb

As you can see the convention in rails is to name partial views with an underscore prefix.

These are included in the show.html.erb as:

<%= render :partial=>"category_list", :locals=>{:categories=>Category.find(:all)} %>
<%= render :partial=>"product_list", :locals=>{:products=>@category.products} %>
<%= render :partial=>"basket_list", :locals=>{:baskets=>Basket.find(:all)} %>

The Category.find(all) does not call the controller but gets the list of categories and sets the partial’s categories variable with the result of the find call.

The product_list is interesting to us, and really sets out as a great example of Rails at work making our lives easier:

The show.html.erb has a variable @category, if we refer back to the model definition, Category ‘has_many :products’ and this along with the fact that the database definition defines that Product has a category_id we can access the list of products from the @category variable and pass it to the partial as a products variable.

Partials can also be accessed if they are not in the same folder – the same partials are included in the \Views\product\show.html.erb like this:

<%= render :partial=>"category/basket_list", :locals=>{:baskets=>Basket.find(:all)} %>

Link to

Rails provides a nice short hand to call controllers from views to call an action the first I touched on earlier:

In the \Views\category\show.html.erb we set the products local variable in the _product_list.html.erb this is then used in a ‘for loop’ like this:

<% products.each do product %>
<div>
<%= link_to product.name, product%>
</div>
<% end %>

So the product is the instance of each iteration of the loop, so in the link_to what actually renders is: http://localhost:8080/RailsShop/product/2107859366, this will automatically call the product_controller show action passing the 2107859366 as a parameter id which is accessed like so:

def show
 @product = Product.find(params[:id])
 respond_to do format
   format.html # show.html.erb
   format.xml  { render :xml => @product}
 end
end

In certain cases we need to explicitly identify the controller, action and parameter we are passing, this can be seen when adding a product to the basket:

\Views\product\show.html.erb

We have access to the local variable @product the id of which is used as a parameter to the basket which is called:

<%= link_to 'Add to basket', :controller => "basket", :action => "add_to_basket", :id => @product.id%>

If we take a look at the ‘add_to_basket’ action:

def add_to_basket
 #how many of this product is in the basket?
 @product_id = params[:id]
 @basket = Basket.find_by_product_id(@product_id)

 if !@basket.nil?
   @count = @basket.count + 1
   @basket.update_attribute(:count, @count)
 else
   @basket = Basket.new
   @basket.product_id = @product_id
   @basket.count = 1
   @basket.save
 end

 redirect_to :controller => 'category', :action => 'index'

end

The code above takes the id parameter, uses it to find the basket, if the basket does not exist a new one is created with a single product otherwise the current number of products is obtained, incremented and stored in the data layer using the update_attribute method.

Another call on the basket allows us to remove the product, this is done by:

def delete
 @basket = Basket.find(params[:id])
 @basket.destroy
 redirect_to :action => 'index'
end

If we compare the last two controller actions we can see the redirect can be both explicit in describing the controller and implicit in that the index will call the Basket for the Basket delete action.

Submitting data in a form

We need to be able to modify the quantity of products in the basket, so how does it plumb together?

We call the basket index from an edit button on the _basket_list.html.erb:

<%= link_to 'Edit basket', :controller => "basket", :action => "index" %>

This calls the basket_controller index action:

def index
 @baskets = Basket.all

 respond_to do format
   format.html # index.html.erb
   format.xml  { render :xml => @baskets }
 end
end

This renders the \Views\basket\index.html.erb

<% @baskets.each do basket %>
  <% form_for(basket) do f %>
    <tr>
    <td class ="productname"><%= basket.product.name %></td>
    <td><%= basket.product.price %></td>
    <td><%= f.text_field :count, :class => "qty" %></td>
    <td><%= basket.product.price * basket.count %></td>
    <td><%= f.hidden_field :id %></td>
    <td><%= f.submit 'Update', :class => "updatebutton" %></td>

Note the hidden id field and form placement within the ‘for loop’, the submit button will call the basket_controller update method, more on the class settings in the style section later:

def update
 @basket = Basket.find(params[:id])
 @basket.update_attributes(params[:basket])
 redirect_to :action => 'index'
end

And then re show the basket with the new line totals.

Making it look good

Layout

To maintain consistency across the site we need to create a page template. We do this by creating a new erb in \app\views\layouts\ - as ever the naming conversion is important here. We can either create one for the site named ‘application.html.erb’ or for each controller i.e. ‘category.html.erb’ the <%= yield %>is used on the page to donate the location to load the views.

Style

We set up styling in a CSS file in \public\stylesheets\default.css – this is referred to in the layout page as:

<%= stylesheet_link_tag 'default.css' %>

If we want to style the delete link in the basket and add a confirmation question we do the following:

<%= link_to 'x', {:controller => "basket", :action => "delete", :id => basket.id}, :class => "delete", :confirm => "Are you sure?"%>

Note the curly parenthesis; without it the class and confirm will be added to the link URL.

Images

Load images on the page using the image_tag, this automatically looks up images in the \public\images folder in the web application.

<%= image_tag(@product.url) %>

Run the application

I want the first page to load with the categories displayed; this is done by adding the following to \Configuration\routes.rb:

map.root :controller => "category"

To run the application from NetBeans:

Right click on the Project > Run

http://localhost:8080/RailsShop/category/

Conclusion

Firstly the structure is all about creating a real world environment the segregation between Development, Test and Production make sense.

When changes are made to the database it is easy to rollback changes and recreates the tables using the rake tasks.

The fields are not specified in the models only in the database migrations, this allows for encapsulation in code from the data layer.

I like the convention over configuration methodology; this has saved time creating rules for each instance.

So in summary then I like rails, it has a very structured approach to development and database schema changes as you can see things can be developed quickly without code bloat using the DRY methods.

I have uploaded the code to GitHub.