One of the most important things in managing your project is to have a clear vision on what is it you want to deliver. Of course we all want to deliver maximum features with very low defect ratios, within 6 months time frame. I have news for you this is usually not possible. Those are interdependent and usually investing in one of the constraints costs you neglecting another. You will be making priority decisions throughout the project, so why not to get clear on what are them at the beginning. That would also give your team a clarity on what is important to the project and how to act when they would have to make priority decision themselves. So keep everybody in sync by providing priorities in advance.

As it always come to comparing two (sometimes more) project characteristics when you are supposed to make a decision I would recommend to write down an order of priority list which has the most important characteristic on top and then descend to less important characteristics.

So for example if you are targeting visionaries with new innovative project you know that you have to generate a specific minimal features set, release it as soon as possible, and think about quality later. You can reflect it in your list. That means that if your defect levels are high but you still don't have complete feature set you will devote your time to implementing features and not improving quality. Second important thing is to define what are the must-haves from the list - things which have to be accomplished for the project to be successful.

Now, make sure you are on the same page with your sponsors and potential customers as otherwise you are heading for disaster. You must be sure that list reflects priorities of people who fund the project. Talk to the sponsors and get them to choose what's the most important by simply asking them. If they don't want to choose as they want 'perfect quality, full feature set, 6 months, 4 people team' ask questions which will mimic decision you will have to make: "let's say it's a month and we still don't have full feature set and quality is low, shall we focus on quality or on features? Or maybe delay the release?". Do whatever you can to get it out from your sponsor. If you can't make the decision yourself (in advance) and get sponsor to agree, sign off on it. Without that project will be dead on arrival - overconstrained projects rarely are harder to deliver they usually are impossible to deliver. Unless you are Chuck Norris of course.

Today I have been looking at how you can use IronRuby to communicate with the various REST API’s floating around the web. Most of the services, such as flickr or twitter, allow you to select the format of the response.  While JSON (JavaScript Object Notation) seems to be the most common format, I decided to start with Xml, simply because I know how to parse xml.

Initially, I wanted to use a Ruby library to parse the xml, however I found REXML which comes with Ruby is not yet supported by IronRuby. As such, I had to take a different approach. I decided to use the System.Xml namespace as my base, and then create a wrapper and monkey patch the CLR objects to produce a cleaner more flexible API.

When creating the wrapper, the first task is to define all of the required references.  Generally with IronRuby, if you want to do .Net interop you will need to reference mscorlib and System.  In this case, I’ve also referenced the System.Xml assembly. The include comment is similar to a using directive in C#, within Ruby include allows you to do ‘Mixins’ and allows the functionality to be accessible from the current module, as if they was combined – a very powerful technique. In this case, it allows us to access CLR objects without needing to specify the namespace.

require 'mscorlib'
require 'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
include System
require 'System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
include System::Xml

The first task is to create a new Ruby class. This class has an initialize method which will take in raw xml as a string.  Under the covers, it creates an instance of System.Xml.XmlDocument and loads the xml.

class Document
  def initialize(xml)
    @document = XmlDocument.new
    @document.load_xml xml
  end
end

Once we have created the document, we need a way to access the xml elements. Within C#, you would use the SelectNodes method, which returns a XmlNodeList, you would then iterate this collection to access the XmlNodes and as such your data. Well, life in IronRuby is a little different. I found that when iterating over the XmlNodeList, I was getting XmlElement objects, each of the nodes. I also wanted to provide a more ‘ruby-like’ way to access the elements.

The method I created has two arguments, one is the xpath query, the second being a Block, a piece of code which I want to be executed for each element. Within my code, I can iterate over all the elements, passing control back to the block with the element as a parameter for processing.

def elements(xpath, &b)
  ele = @document.select_nodes xpath
  ele.each do |e|
    b.call e
  end
end

Within the block, I can place the code required to process that section of the XML. However, I still need a way to access the data of the elements.  Because the above code will return XmlElement objects, I wanted to monkey patch the class to include a few custom methods. This is amazingly simple within IronRuby, you define a class with the same name and define your additional methods.

class XmlElement
  def get(name)
    select_single_node name
  end
  def to_s
    inner_text.to_s
  end
end

I also include an additional method called node() which is the same as above, but allows me to return sub-elements from an XmlElement object.

Finally, I saved this in a file called xml.rb. The filename is used by consumers within the require statement.

With this in place, I can use the wrapper to process xml.

# Include the wrapper
require 'xml'

# Create the document
@document = Document.new('<root><name><first>Jim</first><dob><year>1933</year><month>12</month></dob></name><name><first>Bob</first><last>Smith</last></name></root>')

# Access root/name elements
@document.elements('root/name') do |e|
   # Output the contents of the element named first
   puts e.get('first')
   # Access the element named dob, then output the value of year.
   e.node('dob') {|y| puts y.get('year')}
end

When I execute this block of code, Jim, 1933, Bob is printed to the console.

>ir processXml.rb
Jim 
1933
Bob

While the wrapper isn’t very advanced, it’s a very quick and easy way to start working with xml from IronRuby.

A big thank you to Ivan Porto Carrero who pointed me in the correct direction of how to accept blocks within methods, before I had to do this:

@document.elements('x').collect {|e| puts e.get('first')}

Not much difference, but enough to make a impact.

Feel free to download the wrapper and the sample.  For future reference, I've uploaded the code to the MSDN Code Gallery, which I will update if I release a new version.

Technorati Tags: IronRuby

• a little madness » Continuous Integration Myth: Large Teams Only I think a 1-man team could benefit from CI - because it's not all about the code … (tags: ci)
• Thor - alternative to Rake for Ruby scripting This is like Christmas. Work in the City, come back to startups and find a stocking full of new toys … (tags: deployment ruby)
• Kohsuke Kawaguchi's Blog: Building a custom OpenSolaris LiveCD It's Buildix for OpenSolaris and Hudson! (tags: hudson ci)
• Wifi rabbit notifier plugin for Hudson - eric.lemerdy The rabbits will become self-aware one day. They'll just angrily flap their ears, though. (tags: ci hudson)

Post originally published at: The Build Doctor under a Creative Commons License. Some Rights Reserved.

links for 2009-01-06

Related posts:

1. links for 2008-12-30 London OpenSolaris User Group at OpenSolaris.org Open Solaris could...
2. links for 2008-12-24 collect {thoughts}: Mashup your RSS Feeds with ruby +...
3. links for 2009-01-04 The Technical Blog of Paul Miles: How to Take...

I stumbled across a presentation by Luke Francl called: Testing is Overrated. He could have called it: "programmer testing is overrated" but that doesn't have as much zing to it.

His slides display a refreshing reminder to look for balance in your testing techniques and coverage models. What is especially refreshing is that this is coming from a programmer who is studying testing effectiveness seriously.

Look through the slides and his handout. They provide a nice minimal, complementary and diverse set of testing ideas that when used together can be incredibly powerful.

(If you don't feel like clicking the links, he recommends a combination of the following: programmer unit testing, skilled manual testing, usability testing, and code reviews.)

James is one of the best-known skilled testers in the world - and he can explain his ideas well. Those three things are key:

1) He's made an effort to heard above the din ("well known"). That means he is involved in the community. Unless a tester is involved in the community - they may be doing great work and have great ideas, but others won't get benefit from that experience.

2) He's skilled. I think that one goes without saying. Un-skilled people that are well-known waste your time at best, and can lead you toward bad testing at worst.

3) He can explain his ideas. It has been my experience that whenever you try to say anything above the fray, it will be very easy to have your idea mis-understood, mis-applied, and attacked. You've got to be able to defend what you stand for, fight for it, articulate it well, and deal with attacks with grace and aplomb.

In our little world of testing, James is one to learn from. Now watch the video!



If you want more, I'd suggest his blog or the book Lessons Learned in Software Testing, which James co-authored with Cem Kaner and Brett "The Guy with the Cowboy Hat" Pettichord.

I've got a black-belt thinking analysis problem I am working on. It is non-trivial; your expected involvement would be on the order of 1.5 hours. At this point, /I/ am not 100% certain that /I/ have confidence in my own answer to the challenge.

If you are interested, drop me an email: matt.heusser@gmail.com

Happy New Year everyone!

It seems that everyone I've been speaking with over the past week or so is really glad we have 2008 behind us. I am, too, but I'm not very sure 2009 will be better (at least in terms of the economy). I hope it is better, but I like to keep my expectations in line. We have pretty big challenges as a country and world.

I try to avoid making New Year resolutions because they are so easily forgotten. Instead, I try to focus on goals. One year, I made a list "10 things I want to remember" for the coming year. That was interesting to bring to mind throughout the year the important things.

I have some pretty major goals this year:

• Finish three books I have in progress
• Get about six more e-learning courses produced and out on the website.
• Develop some test strategies and content for cloud computing (Thanks, Mike for that suggestion).
• Contact at least two people in my network each day, just to stay in touch (so don't be surprised if you get a call from me).
• Complete my advanced level test certification (one part down - two to go!)
  
• Actually publish my newsletter every month this year!
• I'm also working on this major project to document all of the processes used in my office - all the way from accounting to website maintenance.

Then, there are my personal goals: books I want to read, people I want to develop deeper relationships with, a better use of my time, and then the big one: to organize my office!

I also have this car restoration project (a 1949 Plymouth) I would like to finish while my dad is still alive to see it and ride in it.

One more thing - My goal is to journal each day. I have been hit and miss, but at least have been doing it for a few years. Back in November while in London I was able to stop by Harrods and get their 2009 Diary, which I find perfect for journaling. Plus, it's expensive enough to give me the incentive to actually use it.

I learned a great tip on this from my mentor, Jim Rohn. Mr. Rohn says that it's good to have a notebook with loose leaf pages for all my projects. Each project gets a tab. Throughout the year I will make notes about how each project is going. On the journals, the one time I spoke face to face with Mr. Rohn he told me that if I stay consistent, one day I'll have an entire shelf of journals to document for my kids and grandkids my ideas, experiences, pictures and thoughts. Today, I look at my shelf and I have about ten of those books. My goal is one book per year.

I hope this prompts you to make a short list of things you would like to do, be, or experience this year. It's easy to dismiss goals, like resolutions. But they really do propel us forward and give a chance to review at the end of the year the progress we have made. For me, if it's not a goal I probably will get distracted and not do it.

Your goals might be:

• To learn a new skill
• To visit a new place
• To make a new friend
• To be better at what you do

Just remember, it's not the economy that determines our success or failure - it's your outlook, faith and philosophy. There are always people that do well in bad times as well as good.

I hope you comment on this post and share some of your goals and thoughts about the New Year!

In the last week of November, Dave de Florinier and I did a talk on Asynchronous .NET architectures and NServiceBus. The sound of the recording was not that good so some readers asked for a transcript. The following is a transcript of my introduction to the talk, encouraging developers to investigate messaging architectures for mid-size and smaller projects. I’ll try to get the rest of the talk published here soon as well.

Today, we use web and web-related services for content distribution, for remoting, for application partitioning and distribution. It seems that HTTP calls have become a default way to think about distributed systems. HTTP and Web services definitely have a lot to offer, but they are not the only way to do things and there are definitely cases where web is not the right choice. HTTP calls are synchronous, stateless (although there is a state simulation with cookie-based sessions) and generally not that reliable. They are also often one-way, which means that any kind of continuous notification always comes down to polling. When you need asynchronous actions, proper state and reliability or event driven behaviour, Web is not the right choice. Unfortunately, lots of people just stick with web services and hack on, trying to fit a square peg in a round hole. In cases such as these, a different distribution paradigm can save us quite a lot of time and effort both in development and later in maintenance. One of those different paradigms is messaging.

I’m not sure why, but I got the impression that lots of people think that messaging is only for huge systems in investment banks, not something that a small or a mid-size project should consider at all. This is false and now I’ll try to convince you.

In a nutshell, messaging allows us to reliably break up a single process into several parts which can then be executed asynchronously. They can be executed with different threads, or even on different machines. The parts communicate by sending each other messages. The messaging framework guarantees that messages get delivered to the right recipient and wake up the appropriate thread when a message arrives.

Fire and Forget

Messaging is a great solution when you want to ensure that something gets done, but you don’t really care about the results and you don’t want to wait for it to finish. This kind of behaviour can often be found when the last part of a process requires talking to an external system or some sort of batch processing.

For example, after a user registers on the web site we want to send him a confirmation e-mail, but there is not much point in waiting for the e-mail to be sent to continue the work. We can send the e-mail synchronously from the web page, but that means blocking up the web server request (and a thread on the server and the user looking at the page and any other resources that the page holds such as a database connection) while the e-mail is sent through an external server. Another solution is to split this process into two parts. The actual registration is really important to finish while the user is there so that he can correct any problems, so that gets done synchronously. Instead of actually sending the e-mail, the web page can just enqueue an e-mail request in a form of a message and then finish working. This releases the database connections, threads and other server resources and returns the page to the user faster. The messaging framework then delivers this request to a dedicated e-mail sender which can dispatch the e-mail in the background. In addition to making the system more responsive, this approach also makes it more resilient. If the e-mail server is temporarily down or there is a DNS problem, the primary process will not be affected and the background process can retry after a while. If the background process is processor or resource intensive, this approach enables us to scale it better because we can have several workers waiting to handle requests from the primary part of the process. If the secondary part of the process is time-consuming, this approach enables the user to go offline knowing that the work will actually be done, and done only once. Remember messaging every time you create a page that contains something like “do not close this window, click on back or reload the page until you see a confirmation”. Messaging also makes the whole thing easier to test because we can check the contents of the message request from a unit test, without actually sending the e-mail. I wrote about this in a bit more detail earlier in How to test e-mail notifications properly.

In any case, fire and forget is incredibly easy to implement with messaging and really hard to (properly) do it with a synchronous stateless unreliable platform such as web.

Just leave it there when you’re done

Another very interesting case is when there is a resource intensive or a time consuming operation that we want to execute and we care about the results, such as generating a long report or processing transactions with external payment providers. Messaging can also help a lot with this case. Instead of a single web request that consumes resources during the whole process, we can split it into the initial part that has to be done synchronously (collecting the report criteria or storing transaction information), assign an ID to that task and then break into two branches. The actual work gets done in the background, decoupled with messaging. For example, a background process picks up the report request and assembles it, saving a PDF to a predefined location on the disk. The second branch is executed by the browser, periodically checking with the server whether the work is done by passing the request ID. When the request is finally done, the client can ask for the results. The web server resources are released straight after the initial part, so that other users can utilise the server and we get better responsiveness and better resource usage. Again, this approach enables us to scale the system better - we can have many workers on many different machines building reports or processing transactions to help the system to scale, or we can limit the number of workers and ensure that scarse resources such as database connections or payment gateway links are available to a much larger number of web servers. I wrote about this earlier in Lazy Web Sites Run Faster.

Share the load

This brings me to the third really useful situation when messaging should be considered. Whenever lots of different agents can request some work to be done, consider messaging as a way to decouple requesters and workers. Web services allow us to scale processing using simple HTTP load balancing, but this gets quite tedious to set up when the number of participants in the process grows. The requester must know how to call the worker and who the worker is. A messaging solution might help to divide and conquer, isolating parts of the system so that they don’t really care about each other. It also makes the system easier to scale and extend. The agents can just publish requests to a message queue, not caring about who and where will actually process them. A number of different processes, running on different machines, can pick up requests and service them, pushing the results back to the message queue. The results might be delivered back to the original requester or picked up by another worker to continue or complete the job.

Thinking about processing in this way allows us to scale the system at runtime much easier (just start up more workers that listen on the queue), extend the system easier (have specialised workers to process particular types of messages) or make the system more flexible (start up workers overnight to pick up low-priority tasks). All these changes can be done in runtime, without touching the code at all.

The key to efficient asynchronous architectures

I hope that, by this point, I’ve at least tickled your imagination and possibly convinced you that messaging can help you do your job easier in some cases. The key to actually getting this done is having an efficient messaging framework in between, that coordinates processing and guarantees that messages actually get delivered. This framework is there to do the heavy lifting and our code should just be concerned with sending or picking up the messages and acting on them.

Maybe people are afraid of messaging because it is typically mentioned in the context of expensive application servers or service bus products, but there are some really lightweight and free (opensource) solutions for messaging as well. So you don’t have to pay a lot of money or hire expensive consultants to benefit from messaging. One such framework for .NET is NServiceBus, which utilises Microsoft’s MSMQ queues, makes MSMQ programming dead easy and implements several really useful communication patterns for you out of the box. For Java, there is the Apache ActiveMQ, which is really straightforward to set up and even supports Ajax and Flash clients almost out of the box. Apache Camel implements various enterprise integration patterns out of the box with ActiveMQ.

Image credits:
Luisem, Penelope Berger,
Library of Congres, Dani Simmonds

A few months ago, I enlisted my 11 year old son to help me with some work around the house. After a short while, he was doing something other than what I had asked him to do.

I told him, "You're not helping me."

"But I am helping you.", he replied.

"No you're not."

"I'm helping you. I'm helping you.", he shot back. He was frustrated. He really thought he was helping me; and I was putting down his work. I was frustrated too. From my view, his helping was creating more work for me. I did not feel helped.

Then it hit me. I've heard this argument before -- from software testers.

I've seen testers, and test managers, attempt to justify their work by telling team members and stakeholders "I'm helping you. I'm helping you." We QA and tester people develop metrics and reports to help us demonstrate how helpful we are. We talk about our quality assurance and testing processes. We talk about all the test cases we develop and execute. We like to show off our test automation that spits out impressive color-coded results.

However, we still encounter unhappy team members and stakeholders. We develop adversarial relationships with developers. We have to explain ourselves to project leads that question the value of our testing. We hear people tell us we're not helping and we keep saying "I'm helping you. I'm helping you."

Maybe, just like my son, we're not giving our stakeholders what they need. Maybe we aren't really helping. So instead of shooting back the "I'm helping you." line, we can stop and listen. Find out what our stakeholders want from us. Listen and ask clarifying questions to better understand how we can help.

I'm not advocating that we just give in and do whatever we're asked without defending our positions. However, we can be willing to adjust our positions to better serve our stakeholders. (Joining an overly optimistic rush to release poor quality software usually doesn't serve them.) If there is disagreement, work to resolve it. Sometimes we may need to educate others on our areas of expertise. Yet we testers also need to respect others' roles and expertise. Listen and learn.

So, the next time you feel like screaming "I'm helping you. I'm helping you.", try to better understand how you can help before turning up your defenses.

Serve your stakeholders.

Ben Simo
QuestioningSoftware.com

The Domain-Driven Design book (or, the Blue Bible), is chock-full of patterns.  Software patterns, team patterns, integration patterns and so on.  As a consequence, many readers might assume that DDD requires these patterns, that you must apply these patterns, and not following these patterns means that you’re doing DDD.

But DDD is an architectural style, not a blueprint for building applications nor a pattern cookbook.  Because DDD is an architectural style, we can’t make any of the following assumptions when applying DDD:

• Implementing certain patterns implies we’re applying DDD
• Applying DDD means we implement certain patterns

One question Rob Conery asked me during a conversation on DDD was, “How do I recognize an application built with DDD?”  We’ve already noted that you can’t look towards a set of patterns, so how do we recognize one?  A DDD application is one whose design is driven by the domain, hence “Domain-Driven Design”.

If I look at a clean domain model, well-factored with explicit responsibilities, I as a lay person could make no judgment on whether the application followed DDD or not.  If however, I talked to the domain experts, learned about their domain, learned how the domain knowledge was distilled, I would then go back and look at the application to find if it models the domain.  If the development team calls a concept an “OrderForm” and the domain experts call the concept a “ShoppingCart”, then immediately we see an impedance mismatch.  The team is not sharing the same model language with the domain experts, losing the benefits of a Ubiquitous Language.  They are likely not following DDD.

Another tactic to recognizing DDD is have both the domain experts and team explain the domain.  Counting the number of clarifications and special cases, “well, except, but” and “we” versus “they” provides a good indication that the domain experts and team are not on the same page.

The patterns laid out in the DDD book are a guide to help achieve the true goal of DDD: a shared model expressed as software.  Concepts like Entities, Repositories and others are in place to reinforce the architectural style of DDD by defining explicit responsibilities of recurring patterns.  Like other pattern languages, the DDD book creates a common Ubiquitous Language for practitioners of DDD, both lowering the barrier to entry and creating a basis for comparing notes between disparate teams and developer communities.

DDD is certainly easier to implement with the patterns described in the DDD book, but they are not required.  We can use the Active Record pattern and follow DDD.  We can use the Entity Framework or LINQ to SQL and follow DDD.  We can use hand-rolled ADO.NET, constrained to a 5-year-old legacy application, and follow DDD.  We can eschew Services for eventing, and follow DDD.

DDD is an architectural style that encourages model-driven design and a domain-driven model.  Following this style is following DDD, and merely implementing patterns only indicates that we can implement patterns.

Previous Posts:
Part 0 of 4: Introduction
Part 1 of 4: Testing the Service
Part 2 of 4: Testing the Client
Part 3 of 4: Testing the Asynchronous Client

Functional Testing the WCF Application

In functional testing, the goal is to test as much of the application that you can to determine that it does what you want from a functional perspective.  It differs greatly from unit testing in that a unit test is only concerned with an individual class.  Functional tests are concerned with testing the interactions of the objects in the system from the user input to the user output.

I thought it would be easiest to draw out what the data mining application is doing in terms of data flow.  This particular application is a data mining application which queries a service to pull out data that the user wants.  In this case, the question that the user wants answered is "What recipes exist in the database that include a given ingredient?"  The data flow goes like this:

The user types an ingredient into the console.  The console launches our application and calls "Main" with the arguments that include the ingredient in question.  The "Main" routine creates an IngredientFinder object which requests a list of all recipes known to the service.  It does this by asking the service proxy which uses WCF to ask the actual RecipeService, which may exist anywhere on the planet.  The actual RecipeService asks the Business Objects which in turn queries the database for all known recipes.  The database returns the results to the Business Objects which in turn returns the results to the RecipeService.  Those results travel through the WCF infrastructure back to the service proxy in the client.  The IngredientFinder filters the recipes for the requested ingredient and returns the results to the "Main" method which then writes the results back to the console for the user to read.

From a testing perspective, the only code we are responsible for in this system is Main, IngredientFinder, RecipeService and Business Objects.  The user and console are completely external to our application.  The service proxy is auto-generated by Visual Studio and the WCF framework is part of the .NET framework.  We do not need to test these parts.  Finally, the database is also a Microsoft product (SQL Server) and we can trust that it works correctly as well.  We need to eliminate all components in this system that we do not control, thus focus on testing the code in which we do control.

Eliminating the User and Console

Traditionally our "Main" method would instantiate our IngredientFinder (see part 1) with the service proxy, get the result and write it out to the console:

static void Main(string[] args)
{
    var finder = new IngredientFinder(new RecipeBoxServiceClient());

    foreach (RecipeData recipe in finder.GetRecipes(args[0]))
        Console.WriteLine(recipe.Title);

    Console.ReadKey();
}

The problem with this is that Console is a static class and cannot be replaced as-is.  Instead, we need to extract this as an interface and pass the interface in:

public interface IConsoleOutput
{
    void WriteLine(string line);
    ConsoleKeyInfo ReadKey();
}

private class ConsoleOutput : IConsoleOutput
{
    public void WriteLine(string line) { Console.WriteLine(line); }
    public ConsoleKeyInfo ReadKey() { return Console.ReadKey(); }
}

By doing this, we can now replace the Console.WriteLine static method with a spy in our test (later).  We will create a new static method named Execute which passes in the IConsoleOutput and IRecipeBoxService interfaces. Our new "Main" routine will look like this:

static void Main(string[] args)
{
    Execute(new ConsoleOutput(), new RecipeBoxServiceClient(), args);
}

public static void Execute(IConsoleOutput console, IRecipeBoxService service, string[] args)
{
    var finder = new IngredientFinder(service);

    foreach (RecipeData recipe in finder.GetRecipes(args[0]))
        console.WriteLine(recipe.Title);

    console.ReadKey();
}

Eliminating the WCF Infrastructure

Now that the user and console have been abstracted out, we can start thinking about testing the Execute method.  The problem we have now is that IRecipeBoxService is an automatically generated interface within the client's namespace.  We have an implementation of this interface in the service, but it is defined in the service's namespace.  The two interfaces are not compatible.  We want to eliminate the need for WCF, so we cannot use the generated proxy class.  What we need here is a bridge class:

public class ServiceWrapper : DataMining.RecipeBoxService.IRecipeBoxService
{
    private readonly Services.IRecipeBoxService _source;

    public ServiceWrapper(Services.IRecipeBoxService source)
    {
        _source = source;
    }

    private static ToType TranslateData<FromType, ToType>(FromType source) where ToType : class
    {
        var serverSerializer = new DataContractSerializer(typeof(FromType));
        var clientSerializer = new DataContractSerializer(typeof(ToType));

        using (var stream = new MemoryStream())
        {
            serverSerializer.WriteObject(stream, source);
            stream.Flush();
            stream.Position = 0;

            return clientSerializer.ReadObject(stream) as ToType;
        }
    }

    public DataMining.RecipeBoxService.RecipeData[] AllRecipes()
    {
        var result = new List<DataMining.RecipeBoxService.RecipeData>();
        foreach (var data in _source.AllRecipes())
            result.Add(TranslateData<Services.DataContracts.RecipeData, DataMining.RecipeBoxService.RecipeData>(data));
        return result.ToArray();
    }

    ...
}

This class bridges the client interface over to the service interface.  WCF interfaces are made up of Service Contracts and Data Contracts.  The Service Contract is the functional interface where the Data Contract defines what the data looks like.  The WCF framework uses the System.Runtime.Serialization.DataContractSerializer to transfer the data in plain-text.  In this ServiceWrapper class, the TranslateData function uses the DataContractSerializer to serialize the data to and from the client and service data types.  This class is the glue that replaces WCF from the testing process.  In a sense, this class is a very simple implementation of the WCF concepts.

Putting it all Together

The only piece of functionality still out of our control is the database.  I am going to replace the SQL Server with a temporal, in-memory database for testing.  This post will not go into the details, but my previous post on Blah Blah Blah talks about how to do this.  Now, our diagram looks shows a system where every piece of code is in our control:

Writing our Functional Tests

The only code we still need before we start writing functional tests is the ConsoleOutputSpy.  It captures the output in a list of strings that we can verify against.

public class ConsoleOutputSpy : Program.IConsoleOutput
{
    public List<string> Output { get; private set; }
    
    public ConsoleOutputSpy()          { Output = new List<string>(); }
    public void WriteLine(string line) { Output.Add(line); }
    public ConsoleKeyInfo ReadKey()    { return new ConsoleKeyInfo(); }
}

Now that we have our console output spy, we can look at our test SetUp:

private ConsoleOutputSpy _consoleOutput;
private DataMining.RecipeBoxService.IRecipeBoxService _service;

[SetUp]
public void SetUp()
{
    _service = new ServiceWrapper(new RecipeBoxService(new MockBackEndConfiguration()));
    _consoleOutput = new ConsoleOutputSpy();
}

Finally, we can write our tests.  This test will populate the mock database with four ingredients and three recipes.  Only two of the recipes include the "Cheese" ingredient, so we can test that our data miner will return only those two recipes that contain "Cheese":

[Test]
public void SimpleTest()
{
    AddIngredients("Macaroni", "Cheese", "Bread", "Peanut Butter");
    AddRecipeToDatabase("Mac & Cheese", "Macaroni", "Cheese");
    AddRecipeToDatabase("Grilled Cheese", "Bread", "Cheese");
    AddRecipeToDatabase("Peanut Butter Sandwich", "Bread", "Peanut Butter");

    Program.Execute(_consoleOutput, _service, new [] {"Cheese"});

    Assert.That(_consoleOutput.Output.Count, Is.EqualTo(2));
    Assert.That(_consoleOutput.Output[0], Is.EqualTo("Mac & Cheese"));
    Assert.That(_consoleOutput.Output[1], Is.EqualTo("Grilled Cheese"));
}

Conclusion

This concludes my four-part series on testing WCF applications.  I have covered unit testing the service, unit testing the client, unit testing an asynchronous client and finally, functional testing the entire application. 

It is important for me to note that these techniques have served me very well in the real-world.  I have a Silverlight application which communicates asynchronously with a back-end WCF service.  These techniques have allowed us to write tests that cover our application from all aspects.  The tests we have in place run extremely quickly and are robust because they do not rely on any services running on a separate machine.

I’ve been thinking a lot around community building, marketing and branding over the last year, primarily around AST but also around work and testing at large. Two links crossed my path today which follow that thread of thought nicely.

1. The Brand You is Dead. Long Live The Brand You Build. - a personal brand was one that provided value pretty much sums up the article. I’ve been working on my own brand for a while now, and according to the article I seem to be doing it the right way. Organizations need to do think along the same lines: Of course the very best of breed, the Seth Godins and Chris Brogans have created very strong personal brands by creating real value for thousands of people every day. Their personal brands are focused on helping others, not on promoting themselves. Not everything needs to be directly tied to revenue; good will in the community context isn’t a balance sheet item but directly affects it. Brand management is important! If you don’t manage it yourself, someone else will for you which is less than ideal.
2. Rails Activists - Mike Gunderloy announced today he is one of the four Rails Activists which is what the Rails community is calling their community based PR team. One of their missions according to Mike is We also intend for the communication to flow in as many directions as possible - one of our roles is to serve as ombudsmen for the Rails community. If for any reason you’re feeling frustrated in an attempt to talk to the core team (though personally, I’ve found them very approachable), do get in touch to see if we can help.. Is there someone / team in your group / company / project that fills this role? Why isn’t it you?

As usual, another podcast, another book being flogged. But that’s alright since this authors chosen are usually pretty interesting. This is the case in the interview with Dr. Gary Small who is doing research on people’s brain using FMRI.

I’m not sure why I’m picking up stuff about how the brain works recently, but here are my notes from this one.

• When we are confronted with a new task, we don’t know how to do something so our brains try different techniques to do it. After you have done it your brain activity will be more uniform. And after proficiency is achieved, your brain will reduce activity which would imply efficiency.
• Synapse Pruning - Early during the development neurons make many synapses, later the number declines, reaching the level of adulthood. The process is called activity dependent synapse elimination, when active synapses are reinforced and inactive ones are eliminated. Number of synapses can change even in the adult animals, making conditions for synaptic plasticity. - Citizendium
• In teenagers, complex reasoning, planning and empathy portions of the brain (frontal lobe) are undeveloped
• milenisation - neurons fire faster; happens in older brains (Google completely failed this search)
• The cost of technology? A lack of people interaction skills; conversation, non-verbal communication, etc.
• Dr. Small did a presentation at Google
• Continuous Partial Attention
• Stress releases cortisol, cortisol shrinks the hippocampus, which lead to temporary short-term memory loss — which is why you make your testing checklists ahead of time
• Taking breaks helps your brain work better. Better away from computer but if need be make the activity different than that you are breaking from.
• Surgeons who play video games make less errors

• Puppet SVN Deploy definition | Carl's Rantings This could be big. DLS to abstract deploying software from subversion. Once it does tags, I'll be very interested. via @littleidea (tags: deployment)

Post originally published at: The Build Doctor under a Creative Commons License. Some Rights Reserved.

links for 2009-01-05

Related posts:

1. New Year Site Admin Happy new year! I have done some long-overdue admin work...
2. links for 2009-01-02 Local Continuous Integration with Integrity | Morethanseven Lightweight CI...
3. links for 2009-01-04 The Technical Blog of Paul Miles: How to Take...

Second to last in the talk was Team City, presented by Yegor Yarko of JetBrains.

They’ve done a very good job of the tool and used their position as developers of IntelliJ and Resharper to promote this product very cleverly: so I don’t think I need to do much introduction to the tool. Here’s the notes I managed to scratch down:

• Free for 20 developers and 20 projects
• Enterprise license $3000, more build agents (you get 2 or 3 free) are $300 each
• Configuration is via xml file or web app
• Build agents are secured: you have to grant them access
• Unique feature: Gives failed test feedback before build finishes.
• Unique feature: IDE plugins (IntelliJ, Eclipse, Visual Studio)
• Unique feature: auto commit (it runs your tedious build and then commits to your repo - while you dine)
• It has static code analysis features
• It is very developer friendly
• Unique feature: stop a build [though I think others can do that]
• Very good .NET support
• They might open source some of the plugins

Yegor also did a great job photographing the conference. Link

Post originally published at: The Build Doctor under a Creative Commons License. Some Rights Reserved.

Continuous Integration Cage Fight: Team City

Related posts:

1. Continuous Integration just got interesting I used to describe CI as “cron with style”. I...
2. New, shiny Rake support in Team City You couldn’t pay me to run CruiseControl.rb now. Oh wait....
3. Eras of Continuous Integration (image taken from debaird’s photostream) November 3, 2008: updated...

Over Christmas I moved my blog over to OrcsWeb. I had been meaning to move hosting provider for a while, however just never got around to it. However, in order to make the move as transparent as possible, I needed to create a subdomain of benhall.me.uk.  By default, OrcsWeb does not offer support for subdomains, you can map additional domains onto the account as long as you stay within your account limits, but you can only have one site (In terms of IIS).

However, hats off to the webteam (especially Desirée) at Orcsweb for helping me setup my subdomain, they pointed me towards the direction of ISAPI Rewrite v3 which is setup and ready to go for each site they host. Yesterday, Steve Andrews tweeted about how to do this, so I decided to share the config.

With V3 of ISAPI rewrite, you simply create a file called ‘.htaccess’ in the root of your IIS site. This contains all of your ‘rules’ about how to handle requests.

This is the .htaccess file for my website.

RewriteEngine on

#Redirect rss.xml to feedburner
RewriteCond %{HTTP:Host} blog.benhall.me.uk$
RewriteRule ^(.*)rss\.xml$ http://feeds.feedburner.com/BenHall [R=301,NC]

#Fix missing trailing slash char on folders
RewriteRule ^([^.?]+[^.?/])$ $1/ [R,L]

# this rule directs blog.benhall.me.uk to Sites/blog.benhall.me.uk
RewriteCond %{HTTP:Host} ^(?:blog\.)?benhall\.me\.uk$
RewriteRule ^(.*)$ Sites/blog\.benhall\.me\.uk/$1

The most important section is the last block, this defines that if the request has the HTTP Host address as Blog.BenHall.me.uk, then rewrite the request to return the content from /Sites/blog.benhall.me.uk/ adding additional paths onto the end if required instead.

Now, when you visit blog.benhall.me.uk/index.html, the file is actually returned from /Sites/blog.benhall.me.uk/index.html.

However, for a long time I had a problem in getting this to work as I expected. Because I wanted a seamless experience, I didn’t want /Sites/blog… appearing in the browser’s address bar. It turns out the problem was that in the rule, I was including the full absolute path to the resource, instead of the relative path. By having the IP in the Rule (RewriteRule ^(.*)$ http://0.0.0.0/Sites/blog\.benhall\.me\.uk/$1 ), it was causing a 301 redirect to occur which was being detected by the browser. By having the rule as relative, it would happen under the covers – without the user ever being aware of the change.

Technorati Tags: OrcsWeb, ISAPI Rewrite

Happy New Year! It's time to try something new!

I've decided to try a little experiment and split my blog, based on my interests. Creative Chaos will remain an exploration of dynamics in development, with a focus on testing and systems thing.

My new blog, The Craft Of Software will be about how we approach our work - how we learn, how we improve, how we demonstrate expertise and mastery in all technical disciplines - Development, Project Management, and Testing. Crafting Software will probably have a little bit more of an agile and development feel.

You can pick which one to read, based on your interests, or hopefully, read both. :-)

In the paper this morning was an article on Elevator Pitches by Rick Spence. Do you have one for yourself (for use in interviews)? Can you create one for that bug you really, really think should be fixed? Why your team should try using Tool X or Process Tweak Y?

For those to lazy to read the actual article, here are the important parts

• People are so bad at working a room that anyone who even tries to do it well will stand out like a pro
• The first rule of networking is to express what you do clearly and concisely
• Introductory line that encapsulates what you do and what benefits you create for your customers –in 15 seconds or less
• Fill-in-the-blank formula is easy to remember: We do XXX for YYYY so they can ZZZZZ (X being what you do; Y being your target customer; and Z being the value you create for clients)
• If they do say those three magic words “tell me more,” stick with your customer-first focus
• Learn as much as you can about the people you’re with before you begin to talk
• The more you know about them, the better you can shape your pitch

(update: I added some updates about more reasons for the settlements as well as more about the size of israel, and a note about the british rule (with some images))

Apologies to the regular readers of this blog.

This is a political post, which I don’t usually do. I live in Israel. I love the fact that technology brings people together, and I have several online friends from countries considered enemies of or hostile to israel (syria, iran, lebanon).

With the recent conflicts between Israel and Palestinians in Gaza, You’ve  probably seen this map being thrown around in various forums.

It depicts what seems to be a loss of land that was previously Palestinian. It looks pretty horrible without context, I know.As an israeli and as someone who really dislikes dis-information, I though I’d give my point of view, based on what the real facts .

I’m writing this so that I can point my friends and those who ask to a place where there is more context and info about this map, and why, even though it may be georgraphically correct, it is a distortion of reality to take it out of context.

A good source of history information about the conflict

a site doesn’t take sides, that has a more or less accurate information about the dispute can be found here.

 

OK, let’s talk about the maps from left to right (chronological order):

Map 1: 1946

The map is NOT graphically correct. Several things are not accurate. First – the british had ruled israel. this was not arab land or jewish land. jews and arabs were living in british occupation. Another thing that needs to be said is that the bottom half of the map was unpopulated – it is a desert part in israel, and even today, it has less than 10% of the population living there because of the conditions. so it should not be green or white.  it was largely empty.

The arab population in israel was larger than the jewish population, and they were both growing at a large rate.There was a large influx of jews coming in(most of whom were fleeing the increasing persecution in Europe). There was lots of killing and massacres against the jews until the UN decided to partition the land (as seen on map 2).

Map 2:

The UN decided what the division would be(israel got most of the uninhebited, desert part). arabs got the right part, and lots of the top and parts of the left. For context – the right side of the map borders with Jordan, which means the UN declared the green right part to actually be jordanian terrotory. the top part id bordering with syria and lebanon. the bottom part borders with egypt.

map 3:

The important thing to remember here is that the arabs did not accept the UN decision and instead began to wage war against the israelis (who wanted to accept it). During this war the israelies had won, and had pushed the arabs back into what is now seen in map 3 (second from the right). Remember, this was war and the green zones were attaching the white ones. so green was smaller at the end of the war.

in essence, map 2 never came into existence. except in the minds of the UN.

that’s how it roughly stayed until 67.

map 4:

so how did we get from map 3 to map 4?

in 67, Egypt decided to declare war on Israel (the bottom gray in the map is the start of egypt. They essentially closed all the bottom part of israel and parts which are not seen on this map.

Jordan and Syria (to the right and to the top of israel) quickly joined in the war, and israel was now attacked from 3 sides. yes. that includes in inner green part that was actually attacking israel from almost within it.

Israel gained victory in that war, pushing back jordan, syria and egypt into what will now look closer to map no. 4 (most right).

the settlement problem

After Israel had won, it could have chosen to do many things – for example negotiate with jordan and leave the places won over to something like the 67’ border.  But it chose, for mostly security, ideological and religious reasons, to stay in those territories and start building settlements there. it built roads that divided the occupied land and basically did lots of things which today there is nothing really good to say about them (and is slowly trying to turn back the wheel on some of them). Still, the security aspect is the one that is the most relevant today. It keeps the other side farther away. if they were closer, their missiles could have easily hit 60% of israel, instead of 30% right now.

A hole we can’t get out of

a lot of what people have a problem with today is the fact that israel as a country supported and still supports parts of the settlements, which are not legal by international law. the reasons, again, are security,ideological and religion (promised land etc..). there is a great divide among the israeli people whether this should continue or not but the situation has now become too problematic to easily solve. Many also believe that the settlements are a security measure that helps to keep the missile attacks farther away from the cities.

for example, Israel had actually gotten fully out of part of the territories (gaza for example), but got back missilies and rockets (which is why we see the Israel coming back in – to stop this). there were many negotiations and many agreements that were broken or followed by both on a single side of the conflict, and many believe that there is no one to talk to on the other side.

many in israel believe that two states are the end result any way, (something like the 67 borders) but want to make sure that the other state will not try to destroy israel (as it had promised to do, with the backing of iran and syria) many times. a state next to you has to recognize that you have a right to exist, and not try to burn you.

Why we are in gaza now

Israel is in gaza now for the simple reason of stopping the rockets and achieving a ceasefire that will last for a long time. it has started with a 6 month quiet period in which over 400 rockets were fired on israel from gaza with no retaliation.

there is no denying that the human situation in gaza sucks. Israel tries to aid in allowing food shipments, money and international aid through passages, but at the end of the day, right now, it is trying to defend itself. nothing more, and nothing less. with force, yes. because nothing else before that has worked.

The size of israel

Israel is Tiny. Seriously. Much smaller than California, Norway or Argentina (see more places to compare). I can take my car and drive from north to south in about 6-8 hours of non stop driving. Compare israel to the size of its surrounding countries and you begin to see what “small and surrounded with enemies” feels like. Jews have literally nowhere else to go. Arabs have lots and lots. yet they insist that Israel be destroyed.  And Israel still has to defend itself from many threats all around. and now, also from within.

 

There is a lot of mis and dis information running around the web right now. I hope that the facts can help sort things out. I hope that I had done justice to the facts.

Before writing this, I did some fact checking with a well known middle-east researcher before publishing this, and will update this post on problems or important comments.

Windows is a multiprogramming OS, which means that it manages and selects among multiple programs that can all be active in various stages of execution at the same time. The displaceable unit in...

Visit LoadRunnerTnT for full links and contents!!