December 23, 2010

Installing Ruby Gems When On A Domain (Errno::ENOENT)

 

As someone who is new to Ruby I really love the idea of installing what you need for the language through gems. However, when I am at work I am on my company’s domain and when I try to install a gem I get the following error:

ERROR:  While executing gem ... (Errno::ENOENT)   
    No such file or directory - H:\

After searching for a solution to this problem, I believe I have found one.

The problem stems from the fact that logging into my domain at work changes my  %HOMEDRIVE% and %HOMEPATH% environment variables to my networked H:\ drive. To solve this problem you need to change your gem.bat.

The gem.bat file is located in your RubyFolder\bin folder. I would suggest that you first make a copy of the original before any tweaking of this file. What you are going to do is modify this file so that it changes the %HOMEDRIVE% and %HOMEPATH% before it tries to install the gem and then, when it is done, change those environment variables back to the original values. Below is an example of what you want this file to look like when you are done.

@ECHO OFF
SET _HOMEDRIVE=%HOMEDRIVE%
SET _HOMEPATH=%HOMEPATH%
SET HOMEDRIVE=C:
SET HOMEPATH=/Ruby192
IF NOT "%~f0" == "~f0" GOTO :WinNT
@"ruby.exe" "C:/Ruby192/bin/gem" %1 %2 %3 %4 %5 %6 %7 %8 %9
GOTO :EOF
:WinNT
@"ruby.exe" "%~dpn0" %*
SET HOMEDRIVE=%_HOMEDRIVE%
SET HOMEPATH=%_HOMEPATH%

In the above example, Ruby192 is where Ruby is installed.

So if you are stuck behind on a domain and cannot install a much needed Ruby gem, this solution will get you back in business in no time.

I cannot take credit for this solution so here are some places where I found this solution

December 6, 2010

Intro to Scrum Part 3: Raiders of the Lost Scrum Artifacts

 

In part 1 of my introduction to scrum series, I talked about the difference between plan driven and value driven. In part 2 of the series I talked about the scrum team. In the last installment of this series, I want to talk about the artifacts of the scrum process.

This is not a complete list, but the following artifacts are the main ones:

  • Product Backlog
  • Acceptance Criteria

Product Backlog

The product backlog is a list of all the work (or story cards) that the team must work on. This is essentially a list of needs/wants for the product that are constantly prioritized. This is the list of solutions that customers, sales, etc. want in the product. Each story card in the backlog is expressed in a way so that it provides an increment of value to the customer. To provide that increment of value to the customer, the story should be a vertical slice through the product.

Each story should fit under the acronym INVEST.

INVEST stands for:

  • Independent – The user story should be self contained, in a way that there is no inherent dependency on another story.
  • Negotiable – User stories, up until they are a part of a sprint, can always be changed and rewritten.
  • Valuable – A user story must deliver value to the end user.
  • Estimable – You must always be able to estimate the size of a user story.
  • Sized appropriately – User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
  • Testable – The user story or its related description must provide the necessary information to make test development possible.

Backlog Sizing

Sizing the backlog is a measure of pace at which the scrum team can deliver the items in the product backlog. People are not good at estimating work. We all know how terrible we are at accurately estimating how long something will take us to complete. People may not be good at estimating, but we are great at comparing items. For example, we can look at two recipes and tell which one is more complicated to do without having to be professional chefs. Sizing the backlog is all about deciding the complexity and amount of work, not how long it will take us to do the work. What you must realize is that sizing is not equal to estimating.

Some may ask, how will I know how long something will take. Well, you can derive how long something will take to complete after something has been estimated.

To better explain this I want to talk about a dirt pile.

Say you went to Lowes, and bought a truck load of top soil for a garden you are creating in the back yard of your house. You wake up the next morning and see that they delivered the top soil, however, instead of putting the dirt in the back yard, they dump it at the end of your driveway. Now, you need to get the dirt to the backyard and you go out and call three contractors to come and give you estimates on moving the dirt pile to the back yard.

The first contractor comes out and looks over the dirt pile, looks in the back yard, and tells you it will take him a day to do the job. He explains that he has old rusty wheel barrels and a scrawny kid to help him so it will take him all day to do it.

The second contractor comes out and looks over the dirt pile, looks the back yard, and tells you it will take him a half day to do the job. He explains that he just recently purchased new wheel barrels that are not rusted out and the local high school varsity football team is working for him that weekend. With all the muscle and new wheel barrels it will only take him a half day.

The third contractor comes out and looks over the dirt pile, looks in the back yard, and tells you it will take him 1 hour to do the job. He explains that he owns a bobcat and with the heavy machinery he will have it done in no time flat.

What you see in this story are three people with three different estimates, but what did not change in all of this? The size of the dirt pile. No matter who was doing it, the dirt pile never changed, even though the time estimates did.

Acceptance Criteria

Acceptance Criteria is essentially a clarification of the story. Acceptance criteria gives the developer a set of markers the must be completed before the story can be considered done. With this in place, a developer has a great starting point in which to write automated tests or even use test-driven development (TDD). In this way, the developer is creating something that the customer needs/wants with the understanding of how the customer will use it.

Another benefit from acceptance criteria is when the feature cannot be completed in an iteration, the team can use the acceptance criteria as a tool to see where the team could split the feature between multiple iterations.

Conclusion

This is just a brief overview of some of the major artifacts of a scrum process. Here are some links if you want more information about these artifacts.

November 1, 2010

Removing Static Method Dependency via Adapters

There may come a time when you need to use static method calls in a method that you are creating or modifying. That is not a bad thing, per se, but the problem will arise once you try to unit test that method.

The idea behind a unit test is to test only the functionality in the method. To truly test only the functionality in the method however, you need to remove all of the outside dependencies. When you are testing a method that has a static method call, you can’t remove that dependency because there is no way to stub or mock a static method call. There is a work around for this dilemma that will allow you to mock out the static method call and truly unit test your method.

An adapter class is a class that allows you to wrap an instance class around the static class. The adapter class is just a pass through to the static class method, but once you have the adapter class, that class can implement an interface that you could mock out when unit testing.

Below, I will show you the original method with the static call and a step by step process to remove that dependency from your test.

Original method with static call

public bool LoadDB()
{
    bool result = true;
            
    // static method call
    result = pdDataBase.SetupDatabase();
            
    if (result && !_adapter.RefDataLoaded)
    {
        // static method call
        pdDataBase.LoadRefData();
    }

    return result;
}

What you see is a method that when we write the unit tests for we will be unable to remove the highlighted dependency. Using the adapter class process, we can remove these dependencies.

First thing is to create an adapter class for the static class that contains the method you need to remove. The adapter class is named the same as the static class, except has “Adapter” tacked on the end. You can give the class a name like  “StaticClassNameAdapter.vb”.

Inside that class file create an interface called “IStaticClassNameAdapter”. You could also create a separate interface class file as well. This interface is how you will communicate with the adapter class and by proxy to the static class. By communicating through the interface, you have the ability to mock out that interface so that you can return a known object when unit testing. Done this way, you will have a known object without having to touch web services, databases, etc.

public interface IpdDatabaseAdapter
{
     bool SetupDatabase();
     void LoadRefData();
}

public class pdDatabaseAdapter : PigskinDraftRepository.Adapters.IpdDatabaseAdapter
{
     public bool SetupDatabase()
     {
         return pdDataBase.SetupDatabase();
     }

     public void LoadRefData()
     {
         pdDataBase.LoadRefData();
     }
}

The interface will contain a method definition that mirrors the static method call. When the adapter class implements the interface, that method can call the static method. This seems like a lot of work to handle a static method, but this can give you a lot of flexibility moving forward as well as a way to test methods now.

Once we have the adapter class and the interface, you will make two changes to the class that contains the method that originally called the static method.

Add a new parameter to the constructor of the class that is of type of the interface you created for the adapter.

private IpdDatabaseAdapter _adapter;

public MainPresenter(IpdDatabaseAdapter adapter)
{
   _adapter = adapter;  
}

Change the method call to call the adapter instead of the static class method.

public bool LoadDB()
{
     bool result = true;
     result = _adapter.SetupDatabase();

     if (result && !_adapter.RefDataLoaded)
     {
         _adapter.LoadRefData();
     }

     return result;
}

Using adapter interfaces and classes around static method does not change the underlying functionality of the method. All this does is gives us the ability to remove a dependency from the method when we want to unit test that method.

What are some other options to remove static method call dependencies from methods for unit testing purposes?

Here are some additional links if you want further research:

www.javaranch.com/journal/200709/dependency-injection-unit-testing.html

googletesting.blogspot.com/2008/12/static-methods-are-death-to-testability.html

elegantcode.com/2008/01/05/adapt-those-static-methods/

October 4, 2010

Intro to Scrum Part 2: There is no “I” in “Scrum Team”

 

In part 1 of my introduction to scrum series, I gave an overview of scrum and in particular the difference between plan driven and value driven. In the next installment of this series, I want to talk a little bit about one of the key pieces to scrum, the scrum team.

The scrum team is the heart of it all. The success of a scrum implementation lives and dies with them.

Components of a Scrum Team

A scrum team is made up of three different and equally important parts:

  1. Scrum Master
  2. Product Owner
  3. Team

Scrum Master

The scrum master is responsible for ensuring that the scrum process is understood and followed. Think of the scrum master as the coach of a football team. He has a system that he wants to implement and its his job to make sure the team buys into the system and works within the system to achieve success on a project. A scrum master facilitates the meetings that the team have as well as remove any blockages that the team may have in the course of the doing their work.

Product Owner

A product owner is responsible for maximizing the value of the work that the team produces. Think of the product owner as a scout for the football team. They are the ones that go out and see what the customer wants and needs and prioritizes those items so that the team is working on the highest customer value items at any one time. A product owner manages the product backlog as well as being a point of contact for the team on any customer related questions.

Team

A team is responsible for doing the work. They are the players of the football team. They work moving the ball (work item) down the field (iteration) and scoring the touchdowns (done done) to win the game (iteration completion). The team is usually made up of the developers and QA.

All three parts work together to accomplish success in each iteration. The scrum master geared more towards looking after the team’s interests and the product owner geared towards looking after the customer’s interests. These two roles free up the team to actually just sit back and create the application that is needed and wanted by the customer.

Characteristics of a Scrum Team 

The key characteristic of a scrum team is the fact that the are a self-organizing unit. They decide what they can commit to each iteration. The team decides what they need to be successful for the project. This level of autonomy was unheard of in a water fall method.

A scrum team is designed to optimize flexibility and productivity. They should know all aspects of an application to varying degrees and be small enough to change direction each iteration, as needed, to satisfy the customer and succeed in the project. They are cross functional in that as a whole the team should know all aspects of the application. Each individual on the team is not an expert at everything in the application, but they are a generalist in everything.

Conclusion

This was a brief overview of a scrum team. If you wish to know more about the different parts that make up scrum, check out the links below:

http://en.wikipedia.org/wiki/Scrum_(development)

http://www.scrumalliance.org/pages/what_is_scrum

http://epf.eclipse.org/wikis/scrum/Scrum/roles/scrum_team_8D8F2B3.html

http://www.infoq.com/articles/building-an-agile-team

In the next article in this series, I will talk about the artifacts of the scrum process.

September 21, 2010

Intro to Scrum Part 1 : Where the Value is Mightier than the Plan

 

The old way of doing software development just did not work. Projects failed left and right and customers began to believe that developers could not produce the solutions that the developers said they could produce. Something needed to change.

Scrum was one of many answers to the problem. Under the umbrella of agile, scrum focuses on small teams and small time blocks for implementation. In the first part of this series of blog posts, I want to show the differences between the old way of doing things, and the new way, scrum.

Plan Driven vs. Value Driven

Waterfall method (Plan Driven)

The waterfall method (also know as the Plan Driven Method) was the only way to do software development for the longest times but it was not the best way. Using this method meant dealing with high risk and the likelihood of failure. The reason why it was this was way was because of the fact that everything was done up front. Everything that the customer wanted or needed was supposed to be laid out at the beginning and the customer never changed their mind. This led to problems becoming hidden until towards the end of a project because not everything the customer wanted or needed was laid out. Scope creep is rampant because what the customer wanted was always changing. We as developers did not know what the customer wanted and neither did the customers.

What plan driven does is create a list of features that the development team needs to provide to the customer in the given timeframe.

When companies were behind on a project, like they usually were, they would just throw bodies at the projects. Their thinking behind this was that the more people that are on the project the faster it will get done. That rarely happened. Most of the time the project would remain behind schedule and companies trying to get the project completed on time tended to cut scope, cut out testing, or both.

Scrum Method (Value Driven)

Scrum (also known as the Value Driven Method) is a dramatic change over the waterfall method. Instead of trying to gather all requirements, do all the designs, and then code the application, scrum looks at doing iterative, incremental development. Small time blocks where the team can work on a solution for the customer. You can look at each iteration as a mini waterfall in that the team will everything you would do in a waterfall method, except do it at a smaller scale. This is done against small features that solve a problem for the customer, not the whole application. The goal of these iterations is to deliver an increment of the final product that is potentially releasable.

This approach makes problems visible sooner. However, contrary to popular belief, scrum does not fix the problem. It shows you the mud but won’t clean it up.

In scrum, you are not just creating features for sales and marketing teams to show customers, you are creating solutions for the customer. The way this is done is by prioritizing the items that need to be completed based on customer value. Only the things that the customer deems most important are worked on in any given iteration. If the customer does not want something then it is not worth the developer’s time to work on it. Finally, scrum is all about small; small teams, small features, and small iterations.

Fixed vs. Variable

In plan driven, your scope is usually fixed with your resources and time being variable. In this method, your scope dictates your resources and time. Since you cannot change your scope your only how is true try to throw bodies and technology at the project and hope for the best. Usually to varying degrees of success.

In value driven, your resources and time are fixed. You know the size of your teams and you know how roughly how many customer items they can complete in an iteration based on previous iterations. Scope becomes the variable in this equation. Here your resources and time dictate you scope. Since you are able to potentially release workable and valuable software to a customer at the end of each iterations, scope creep becomes near impossible. This is because as new features are presented to the team, they are prioritized. After this prioritization, the “must haves” are at the top with the “would like to haves” at the bottom. Over committing the team goes away.

ValuePlanPic 

Conclusion

This was a brief introduction on the differences between the waterfall method and scrum. In the next article in this series, I will talk about a component of the scrum process, the scrum teams.

September 5, 2010

How to install and run NUnit in .Net

Being new to the agile world, all of these new tools can be overwhelming. One of the first things you may want to do as an developer is write a test. As developers, we are curious about how good our code is, but how do you write a test? What tools do you use in the .Net environment? By the end of this tutorial, I will show you how to install, setup, and use NUnit to write your very first test. Once you learn how to write these tests, you will realize just how easy it is to test your code.

Prerequisites:

In order to follow along in this tutorial, you will need the following
  • Visual C# 2010 Express (any version Visual Studio 2010 should do)
  • NUnit (Please note that in order to get the NUnit client to run, you need to have .Net Framework 2.0 installed. It won’t matter if you are using a different version of the framework for your development.)

NUnit Installation:

To install NUnit click on the “.msi” file from the download page, link above, and double click the file and open the file once it’s been downloaded. The “Complete” setup type will be fine. Everything else is pretty much your standard installation. Once the installation is complete, the necessary DLLs will be on your computer and you will be ready to incorporate them into your test project.

Writing NUnit Tests:

Writing a test with NUnit is fairly straight forward. Lets start with the following method called “AddTwoNumbers”.
namespace NUnitTutorial
{
   public class MathObject
   {
      public int AddTwoNumbers(int num1, int num2)
      {
         int result = num1 + num2;
         return result;
      }
   }
}
What you can see is that the method simply adds two numbers together and returns the result. Lets write an NUnit test to make sure this method is returning what we expect. We need to do the following to write a test:
  1. Add a new class library project to your solution. This new project should have the following naming conventions “ProjectUnderTest_Test” where “ProjectUnderTest” is the name of the project that contains the methods you are writing the tests against. image This project will contain all of your tests. Above you will notice that I have a project called “NUnitTutorial” that contains the “AddTwoNumbers” method and a project called “NUnitTutorial_Tests” that will contain the unit tests for that method.
  2. Next add the following DLL to the test project “nunit.framework” image
  3. Write our test.
To write the test we first need to add a using for the project under test (NUnitTutorial) as well as the NUnit framework (NUnit.Framework).
using NUnit.Framework;
using NUnitTutorial;
Now lets add our test to the MathObject_Tests.cs file. We first need to let NUnit know that this class contains tests that need to be ran. To do this we mark the class with the following attribute “[TestFixture]”.
using NUnit.Framework;
using NUnitTutorial;

namespace NUnitTutorial_Tests
{
     [TestFixture]
     public class MathObject_Tests
     {
     }
}
Now, lets add the test method “AddTwoNumbers_returns_3_when_given_1_and_2”. (I always like to name my test methods this way so that I know what method they are testing as well as what the expected inputs and outputs are.) Once we add this method we need to add the attribute “[Test]” to it so that NUnit knows that this is a test to be ran. Note, that all test methods should be void methods, not return anything.
using NUnit.Framework;
using NUnitTutorial;

namespace NUnitTutorial_Tests
{
  [TestFixture]
  public class MathObject_Tests
  {
       [Test]
       public void AddTwoNumbers_returns_3_when_given_1_and_2()
       {            
       } 
  }
}
All that’s left is to call the method with our two inputs and assert that the result from the method is what we expect.
using NUnit.Framework;
using NUnitTutorial;

namespace NUnitTutorial_Tests
{
  [TestFixture]
  public class MathObject_Tests
  {
    [Test]
    public void AddTwoNumbers_returns_3_when_given_1_and_2()
    {
       MathObject mObject = new MathObject();
       int calculatedResult = mObject.AddTwoNumbers(1, 2);
       int exptResult = 3;
       Assert.AreEqual(exptResult, calculatedResult);
    }
  }
}
The above test simply calls the “AddTwoNumbers” method, giving it a 1 and a 2 and asserts that the result from the method is what we are expecting, which is a 3. Now, that we finished writing the test, we need to run it. Build your solution and generate those DLLs.

Running NUnit:

Start up the NUnit client by going to Program Files –> NUnit x.x.x –> NUnit. Once it is up and running, click on File->Open Project and navigate to where the DLLs generated from the test project are located. You want to load the test project DLL into NUnit. image Once the DLL is loaded, it will show you the tests that are in that DLL. image From here all you need to do is click the “Run” button and NUnit will run your tests and output the results. image As you can see, our test passed. Now what would have happen if the test had failed? Let’s find out. Lets change our expected result to be 4 and see what happens. image There you go all the information you need to get NUnit installed and on your way to creating tests and rock solid code.

August 31, 2010

Introduction

Hello welcome to my new blog. I hope to share with you some of the things that I am going through in using Agile methodologies and practices in a .Net world.

Stay Tuned.