Today I am sharing the beginning of a new software service, Dropstream. Dropstream is a unique service that provides an integration hub between eCommerce platforms and fulfillment centers, allowing retailers to spend less time processing orders and more time growing their business.

Now, the niche that Dropstream targets may seem like a radical deviation from some of the other products I’ve marketed and in the past, and you’re right, it is very different. But the one thing all of my other products have in common is that they started to scratch my own itch, and Dropstream is no different.

Lately, I’ve been less interested in exercising my technical skills to build new products and more interested in online marketing, which I admit, I struggle. A few failed negotiations later, I happened across a niche eCommerce website for sale. Running an eCommerce store was something I never considered, however, it came across as the perfect opportunity to gain valuable knowledge in online marketing. As I researched the details of operating an eCommerce store I began to see a potential problem that could be solved through automation.

Many fulfillment centers that eCommerce Retailers work with typically process orders and track inventory in one of several ways: E-mail, FTP Upload (CSV, XML files), and Webservice API. With the abundance of eCommerce platforms, the responsibility is on the retailer to provide an integration with their platform. Those without a technical background wishing to automate these back-office tasks have two options: continue to process tasks manually, or outsource integration development.

Dropstream provides a third option, enabling retailers to better manager their time operating their store. Visit Dropstream’s blog for the latest insights in eCommerce and Dropstream progress.

On any project of significant size, there are a few constants, one of them is technical debt. Those problems with your code base that irritate you, but never seem to get fixed. This could be poor architectural decisions, messy code, or the lack of automated tests.

To put your team in a better position to tackle technical debt, there is only one thing that you need to do. Plan.

Smart Sprint Planning

Typically during sprint planning, the scrum master will take a tally of each team members availability during the the sprint. This number will be the teams total capacity for the sprint. Then teams begin to load stories from the backlog to fill their capacity. This is where the trouble begins.

Many teams will over-commit the amount of work that can be done during a given sprint. Committing 100% of their capacity to completing new features. Meaning if you have estimated your team has 100 hours of working hours available during a sprint, the team commits to completing very close to 100 hours of work during the sprint, neglecting to plan for the unexpected.

Like death and taxes, you can always expect new features to produce new bugs. Failing to plan for the fix/test cycle can cripple a teams velocity. So not only are you pressed for time fixing new bugs, there is really no time for addressing technical debt. So how exactly do you plan for fixing technical debt? This ends up being a two step process.

Planing for Technical Debt

Just like any other new feature to be built, technical debt must be estimated, broken down into discrete tasks, included in the backlog and prioritized. The next step is critical, during your regular sprint planning meeting, it is important that your team does not over-commit.

I would highly recommend committing only to a percentage of your total capacity for a sprint, so for example 80%. Continuing from the previous example, a team with a total sprint capacity of 100 hours would leave the team an extra 20 hours to fix bugs directly related to tasks from that sprint and address any technical debt.

The break down could be like this: 100% (Team capacity in hours) = 80% (New Features) + 10% (Task Bugs) + 10% (Technical debt). The important point here is to play an active role in reducing the amount of technical debt for your project in every sprint. Depending on your projects needs and team dynamic, it is a good idea to experiment a bit with these numbers to see what works best.

Conclusion

By leaving your team room to work within a sprint, you are able to be flexible, adjusting for user stories that may run longer, or shorter in a sprint, but also address those code stinks that you’ve been itching to git rid of. How does your team address technical debt in your projects?

V1MantisBT 1.2 is now available to download.

What’s changed:

• Support for Mantis-to-VersionOne project Mapping. You can now configure which VersionOne project your Mantis Issues are imported to.
• Easy installation with a new Windows installer.
• V1MantisBT has moved to a paid model, with two different feature editions.

Update Instructions:

1. Download the latest version here.
2. Back up any existing configuration file.
3. Run the downloaded file.
4. Replace existing configuration file, or create a new one.

Now you are done and ready to get back to building great software.

Automated testing is a good software engineering principle regardless of which development management process being used, Scrum, TDD, XP, etc. You know all about the benefits of unit-testing. It will reduce the number of defects, catch bugs earlier, unicorns will manifest themselves and bring you a beer. Great! But how do you start?

There are various opinions on how to test your Data Access Layer (DAL). Some would argue that it makes sense to write tests that run against an actual database. Others will argue that DAL tests should be mocked. While, I’ve talked previously about techniques for unit-testing, advocating, pleading, begging for the usage of mocked dependencies (using a mocking framework). When it comes to testing the DAL, this is where I make an exception to that guidance.

Don’t get me wrong, the database is a dependency on the DAL, but the trade offs between mocking the database versus having a separate test database is a more efficient use of development effort. Grated, using a mock framework in place of a database dependency will allow you to run your tests quickly, and all those great things that come with pure unit-tests. But the DAL is special, it is like an ice berg, its runtime logic is only partially contained within its code. (Hint: The other portion is contained in the database)

It does not matter if you are using a the latest-and-greatest wiz-bang ORM, stored procedures, or dynamic SQL, your database will always contain some logic that needs to be tested. Which is why am a supporter of integration testing your Data Access Layer, and not unit-testing. There are many issues that can be uncovered by integration testing your DAL. Including, but not limited to, typographical errors, foreign-key violations, and plain old incorrect SQL.

As an aside, having database integration tests are a great way to performance tune your data schema and SQL.

Builder Pattern

So how exactly do we go about creating integration tests for our Data Access Layer. Well, this is a little tricky, since rarely will you have one domain object that does not have a dependency on another. So creating Create, Read, Update, Delete (CRUD) integration tests can quickly get out of hand and result in lots of duplicated code across tests.

This is where the Builder pattern will help. The Builder design pattern is similar to the Factory pattern, in that  both patterns abstract away the instantiation of an object, however the builder pattern has a few more features that suite it well for creating integration tests.

The purpose of the Builder pattern create a flexible interface by which a developer can create a dataset that can be used to test the CRUD operations of a Data Access component. Lets take a look at an example:

        public override Person Build()
        {
            return Builder.CreateNew()
                .And(x => x.OrganizationId = organization.OrganizationId)
                .And(x => x.Name = GetRandom.Phrase(10))
                .And(x => x.StartDT = startDate)
                .Build();
        }

The example PersonBuilder class has two main functions, Build and Save. The build function simply creates an instance of a person with all reasonable defaults initialized. In this example, the Name, StartDT and OrganizationId. I am also using a framework called NBuilder to do the actual instantiation of the Person object. NBuilder provides some very handy features for rapid object generation.

        public override Person Save()
        {
            Person person = Build();
 
            new PersonDA().Insert(person);
 
            return person;
        }

The Save function is a little trickier, since this is where the instance of a person is actually persisted to the database. This is where you must be aware of your particular database constraints. In our example, the Person Table has a relationship with the Organization Table, so we must save the Organization to the database before we can save the Person. This is the responsibility of the caller, the integration test.

        public PersonBuilder WithStartDate(DateTime startDate)
        {
            this.startDate = startDate;
            return this;
        }
 
        public PersonBuilder WithOrganization(Organization organization)
        {
            this.organization = organization;
            return this;
        }

There are two other methods that should be highlighted, WithStartDate, and WithOrganization. These methods allow a developer to override the default values of the OrganizationId and StartDT property on the Person instance. Providing these methods allows a developer to craft a dataset to fits the need of a particular test. For example, asserting the cardinality between an Organization and Person, or testing specific query logic that may filter records.

In practice, these extra methods are not needed for every single property of a class, you will have to use your best judgement to determine when they are needed under a particular unit testing scenario. When going through this process, a Domain Specific Language (DSL) is being created, that will allow other developers to quickly ramp up to using a set of builder classes to create complex integration tests.

One last thing about this examples DSL methods you may have noticed, the return type is this. Returning the current builder instance creates a fluent interface for the DSL. Making possible method calls like this:

var personBuilder = new PersonBuilder();
personBuilder
    .WithStartDate(DateTime.Now.AddDays(3))
    .WithOrganization(organization)
    .Save()

The full source for the PersonBuilder class is available here.

Conclusion

Using the Builder Design Pattern has numerous advantages, and its my perfered method of creating an easy to use framework when testings Data Access Components. How do you test your Data Access Layer?

I often find myself debating the performance implications of various algorithms and alternate implementations. The only way to know for sure is to test the theory. Here is a quick and dirty way to benchmark the execution time of any method.

public static TimeSpan Time(Action action)
{
    Stopwatch stopwatch = Stopwatch.StartNew();
    action();
    stopwatch.Stop();
    return stopwatch.Elapsed;
}

An example usage:

TimeSpan time = Time(TestedMethod);
Console.WriteLine(String.Format("TestMethod executed in [{0}] ms",
                                                  time.TotalMilliseconds));

VurtleOne is now compatible with VisualSVN‘s Visual Studio Subversion plug-in! Now you can enjoy the same VurtleOne integration within Visual Studio. See our VurtleOne product page for more information on the features of VurtleOne.

See our downloads page for the latest version of VurtleOne.

Writing a commit messages is like telling a joke without a punchline. While writing these messages may be tedious at times, I’ve found their presence invaluable over the years.

Having worked with source control management system, you may be intimately familiar with the commit dialog. That annoying dialog that has an endless craving for prose. Usually a commit message is encourage, but not required. However, I’ve seen some team environments where a minimum character length was enforced by the source control management system!

As developers, the decisions to enforce such policies are usually out of our control, but honestly, this is one policy I can support. At first glance, it would seem like writing detailed commit messages is just another one those administrative tasks with no tangible benefits.

I’ve found the that detailed commit messages have saved me countless hours over the years when the need to hunt down changes in the version control history. Common source control client tools like TortoiseSVN, Git, Perforce, and TFS include features to browse changeset history, which will contain the comments written by another developer.

Browsing version control history (with detailed changset descriptions) it becomes very easy to understand the holistic reasoning behind code changes in a way that in-line commenting can not provide. Often times when a bug is reported, being able to isolate an issue to a changeset, a set of modified files, will dramatically reduce the time it takes to find, test and implement a fix.

As a project grows and becomes more complex, as does the time it takes for new developers to learn their way through the labyrinth of the code-base. Having the ability for new developers to learn by example based on changeset revisions is a boon for all involved.

When it comes times to release your software, you generally want to communicate to your customers what features and fixes are in the latest version. Having details commit messages, is a great starting place for creating release notes for the marketing department.

Depending on your development environment, there are many tools that exist to help automate the task of creating commit messages based on an item of work that may exist in an external project management application. A few of these tools which integrate with TortoiseSVN can be found on their issue tracker integrations page.

Full disclosure: Falconer Development makes an issue tracker plugin for TortoiseSVN and VersionOne called VurtleOne.

Creating unit-tests is a development task that should be implemented with flexibility and maintainability in mind. This means designing your unit-tests to be atomic, isolated, and fast. Here are a few tips to be aware of when writing unit-tests.

Mock Dependencies

At some point a class or method under test will require some functionality defined outside of its scope. In typical web application, this could an architectural boundary like the database layer, or service layer.

In these scenarios, the focus should be to isolate the code being tested from its dependency. A way to accomplish this is to use a mock, or fake implementation of the dependency. This allows the unit-test to run in memory and the mocked implementation can also be manipulated to force edge cases to be tested.

When implementing a unit-test with a mocked dependency it is best to use one of the many available mocking frameworks. Most offer an intuitive API and and a robust feature set, and are freely available.

Thoroughly Test Your Code

The goal of for any suite of unit-tests is to have 100% code coverage. In reality, this can be a challenge for many different reasons. However, with mocked dependencies, only the most extreme cases would prevent you from hitting the coveted 100% mark for a given unit of code.

However, there can be situations where the time it takes to properly write a test for a section of code far out weights its functional value, and time to manually test. In these scenarios I find it acceptable to make a note, and skip the test.

In practice, some may be tempted to take the idea complete code coverage to the extreme and change the visibility of functions for the sake of testing. DO NOT DO THIS! Non-public methods should not be directly invoked by a unit-test. This violates encapsulation principles of object-oriented programming.

Instead, in-directly test the private method by invoking a public method which then makes use of the private method.

Manage Risk

When working on greenfield development projects, its best to have unit-test created along side your application code. Many agile methodologies, like TDD, XP, and SCRUM take this approach. But not all developers are fortunate enough to work new projects, many time the code base has existed for years.

Coming into an existing code base, it is best to implement unit-test in small increments. When bugs are reported in the code base, write a test that reproduces the problem before implementing the fix. This way, if the bug comes back, it will be caught by the test.

No matter the methodology being used, developing a suite of unit-test is key to a projects long-term success. Today’s customers are becoming less tolerant of bugs, and with the availability of mature testing tools, there really is no excuse for not being able to produce high quality software. As software developers, it is our responsibility to write code that works, unit-testing is a means to that end.

After changing the trace level, you will see a more detailed output in the Debugger Output Window. Above is is a screenshot of the how to enable the proper settings.

Source Article: Visual Studio 2010 WPF Trace Settings Default Is Incorrect

Find more useful Visual Studio help in the Tips and Tricks section.