Codebrain Blog

What Time Is It?

stucam — Wed, 29 Feb 2012 14:18:00 +0000

Time is an interesting concept, perhaps even something we take for granted in our universe! Leap years and daylight savings are just two human-imposed time counting quirks that crop up now and then, and can cause all manner of problems with poorly designed systems.

var oldDate = Convert.ToDateTime(DateTime.Now.Day + "/" + DateTime.Now.Month + "/" + (DateTime.Now.Year - this.TimeAtAddress));

The above code will work absolutely fine, until you hit a leap year, like today. The code is then at risk of failing if TimeAtAddress is not divisible by 4, in the process littering your error logs with random failures and likely impacting your business in some negative way.

When dealing with DateTime objects ALWAYS use the built in modifiers, for example .AddYears() and .AddMonths(). It'll save you the heartache of having to fix simple date bugs.

When developing applications it's always worth considering how you handle your representation of time, and often it's worth introducing a time abstraction simply to buy you flexibility around testing.

I've used classes such as the one below to push the calculation of the current date into an abstraction that allows you to override the calculation should you need to.

public static class DateHelper
{
    public static Func DateTimeGenerator = () => DateTime.Now;

    public static DateTime Now()
    {
        return DateTimeGenerator();
    }
}

Usage:

var now = DateHelper.Now(); // will get the current date

DateHelper.DateTimeGenerator = () => DateTime.Now.AddDays(5);
var nowPlus5Days = DateHelper.Now(); // will be the current date time plus 5 days

This becomes particularly useful in scenarios where you'd like to setup some test data for something that happened in the past, in order to validate something that occurs in the future. With some clever use of IDisposable it's possible to construct setups for tests such as:

[Test]
public void A_test(){

	// we are at current time.
	
	using (var _ = DateTime.ShiftDays(-30))
	{
		// we are now 30 days ago.
	}
	
	// we are at current time.
}

If you are feeling really fancy you could start nesting the using() statements and skip back and forth through time as you see fit.

C# Content Spinning Algorithm

stucam — Sun, 14 Aug 2011 13:00:00 +0000

There is a well known technique within black-hat SEO called content spinning. Content spinning involves writing an article using a specific syntax which allows a text processor to generate random variations. These variations can then be used for multiple purposes without fear of being labelled as duplicate content.

I was searching for a C# algorithm which I could re-purpose into a nAnt script, but a few searches on the internet gave no results. I found a python version which seemed good enough, so I rewrote it for C#.

public static class Spinner
{
    private readonly static Random Randomizer = new Random();

    public static string Spin(string content)
    {
        const char OPEN_BRACE = '{';
        const char CLOSE_BRACE = '}';
        const char DELIMITER = '|';

        var start = content.IndexOf(OPEN_BRACE);
        var end = content.IndexOf(CLOSE_BRACE);

        if (start == -1 && end == -1 || start == -1 || end < start)
        {
            return content;
        }

        if (end == -1)
        {
            throw new ArgumentException("Unbalanced brace.");
        }

        var substring = content.Substring(start + 1, content.Length - (start + 1));
        var rest = Spin(substring);
        end = rest.IndexOf(CLOSE_BRACE);

        if (end == -1)
        {
            throw new ArgumentException("Unbalanced brace.");
        }

        var splits = rest.Substring(0, end).Split(DELIMITER);
        var item = splits[Randomizer.Next(0, splits.Length)];
        return content.Substring(0, start) + item + Spin(rest.Substring(end + 1, rest.Length - (end + 1)));
    }
}

Usage:

Spinner.Spin("{Hi|Hello|Good morning}, my name is {Matt|Bob} and I {certainly |might |should |}have {something {important|special} to {say|eat|share}|a favorite {toy|book|poem|song}}.");

New start up launched

stucam — Tue, 25 Jan 2011 07:30:00 +0000

So, this is the first update on this blog for quite a while and you are about to find out why it's been so quiet around here.

I have been very busy working on a new start up with my business partner, Valere Speranza. If you have ever founded a start up you can appreciate just how much time they consume - all of it. It gives me great pleasure to announce Lead Magpie!

Check out the site at http://www.leadmagpie.com to learn more.

CQRS

stucam — Sat, 04 Sep 2010 15:30:00 +0000

There seems to be a lot of noise around CQRS and DDDD these days:

Mark Nijhof has uploaded a DDDD sample using a CQRS approach
Greg Young has put up a simplest possible CQRS implementation on GitHub.
NCQRS - a framework for enabling development of CQRS-based architectures is gaining some momentum. The getting started screencast was great.

Thycotic Alpha-End Competition Entry

stucam — Sat, 14 Aug 2010 11:00:00 +0000

Thycotic have put up a Code Challenge.

Below is my heavily LINQ-oriented solution:

public interface IConverter
{
    string Convert(int number);
    int Convert(string number);
    string ConvertUsing(IConverter convertor, string number);
}

public abstract class ConverterBase : IConverter
{
    protected abstract string Chars { get; }

    public string Convert(int number)
    {
        return this.Encode(number)
                   .Aggregate(string.Empty, (s, c) => s + c);
    }

    public int Convert(string number)
    {
        return number.Reverse()
                     .Select((c, i) => Chars.IndexOf(c) * (int)Math.Pow(this.Chars.Length, i))
                     .Sum();
    }

    public string ConvertUsing(IConverter convertor, string number)
    {
        return convertor.Convert(this.Convert(number));
    }

    private IEnumerable<char> Encode(int number)
    {
        var remainder = number % this.Chars.Length;
        if (number - remainder > 0)
        {
            foreach (var power in this.Encode((number - remainder) / this.Chars.Length))
            {
                yield return power;
            }
        }
        yield return this.Chars[remainder];
    }
}

public class Converter : ConverterBase
{
    protected override string Chars
    {
        get
        {
            return "0123456789xyz";
        }
    }
}

public class HexConverter : ConverterBase
{
    protected override string Chars
    {
        get
        {
            return "0123456789abcdef";
        }
    }
}

public class BinaryConverter : ConverterBase
{
    protected override string Chars
    {
        get
        {
            return "01";
        }
    }
}

public class OctalConverter : ConverterBase
{
    protected override string Chars
    {
        get
        {
            return "01234567";
        }
    }
}

Note: The code doesn't handle negative inputs or exceptions.

Death March

stucam — Tue, 15 Jun 2010 18:00:00 +0000

Death March - Edward Yourdon

Customer's requirements are captured in written form
Requirements are transformed into further written documentation
Timescales are predicted using guesswork and multiplication
Invariably this process always results in a bid for work
Cost is calcuated as a function of timescales and resources
The statement of work is drawn up to include as many get-out-of-jail-free loopholes as possible
The schedule is unveiled, all hail the schedule
Developer units are hired to work to the schedule
Requirements and specifications are buried in word documents and spreadsheets
Key knowledge held by people who are disconnected from development
Distributed teams make communication difficult
Development derives additional requirements during the solution process
Customer changes requirements
Cycles of rework begin
Plan starts to slip
Management become unhappy
Pressure begins to mount and quality begins to suffer
Developers suggest solutions, but these are stifled or trivialised
Retrospectives are conducted behind closed doors
A new schedule is drawn up, goto 7.
Morale plummets
Self-preservation begins to take over
The development team starts to dissolve

I wonder what the outcome will be?

Eric Evans DDD Presentation

stucam — Sat, 12 Jun 2010 20:00:00 +0000

Another fantastic presentation from Eric Evans which resonates strongly with me:

http://domaindrivendesign.org/node/198

During the presentation he talks about documenting the process he has been using over the last 6 years. You can download a copy of the draft write-up too.

http://domainlanguage.com/processdraft/

Is this the possible start of a new book?

The Others

stucam — Tue, 25 May 2010 20:00:00 +0000

During my 8 or so years contracting I've been fortunate enough to work with a variety of different companies, from the cautious and slow-moving banks through to dynamic and fast-paced digital agencies.

Throughout my journey I've been lucky to meet and work with some truly brilliant people, great designers, developers and managers. I've also come across my fair share of 'others':

The others aren't interested in learning.
The others carry grandiose titles like 'Senior Software Architect' simply for being in the company for 10+ years.
The others repeat the same mistakes over and over again.
The others use seniority to quash innovation and perceived threats from the lower ranks.
The others view new ideas and technologies with scepticism.
The others view the 'hired help' with suspicion and contempt.
The others treat their job as entitlement.
The others clock-in and clock-out.
The others play political games to compensate for poor performance.

I'm sure you know who the others are in your workplace.

The message for this blog post is to encourage you to be the best you can be; don't settle for being an 'other'.

Personal and professional development is the only true job security in this ever-changing world.

Kanban Experiment

stucam — Sat, 27 Feb 2010 16:00:00 +0000

Problem

What do you do when your development process is in pieces, hundreds of defects are being raised against your code, ad-hoc work requests are piling up, the developers are groaning 'if we only had the time to make these improvements life would be easier' whilst the fixed deadline is looming.

If you find yourself in this situation the simplest and easiest thing to do is walk out the door.

It may be that the project you are working on is so fundamentally broken that even the most talented development team in the world still has no chance of succeeding. Hundreds of decisions are made during the project inception stage and each one can affect the overall chances of success. By the time the developers arrive the problems have solidified, and given their nature (financial, contractual, resourcing, managerial) the developers are, for political reasons or otherwise, unable to tackle them. Another death march begins.

Adding developers to a project with fixed deadlines, fixed deliverables in a fixed price contract rarely produces good software and in the worst case can leave the company responsible for delivery in ruins, perhaps even bankrupt.

I've been contracting long enough to realise that the majority of the problems I face as a software developer are not software development related, but both project management and business related. I'm not saying that all companies are like this, but that some companies are more deadly than others.

Acceptance

If you find yourself on a challenged project and are courageous enough to go the extra mile you can try and introduce some order onto the chaos, patching up the major holes as best you can. A do-it-or-die attitude is required because you'll probably ruffle somebody's feathers in the process.

Given the above situation, I decided go back first principles and implement a Kanban system with the help of my team, in the face of some serious project challenges.

Solution

First, you'll need a large wall space, some marker pens, coloured tape, sticky dots and post-its. If walls with whiteboards are in short supply then the back of some borrowed cupboards will suffice.

We loaded the Kanban with our backlog, giving each type of work a different coloured post-it:

Use Case

A large chunk of work which needs to be broken down into smaller tasks. Many tasks go together to form a complete Use Case.

Task

A task for a particular Use Case of sufficient size to be estimated and worked on by a developer(s).

Improvement

Improvements are internally generated within the development team. An example may be a largish refactoring opportunity, automated process or tools upgrade. The point here is that time spent on an improvement will increase the flow of other post-its across the board.

Defect

Raised by the test team on the current release of code. These defects are raised and entered through an external system, the post-its are placed on the Kanban to track the work in progress.

Ad-hoc

Externally generated work, perhaps as a result of a customer demonstration.

Problem

Can be placed on any other post-it to denote that there is an outstanding issue, complete with a description of the problem.

As well as colour coding each card contained the following information:

Date the post-it arrived on the board.
A description of the work item.
Priority denoted with a coloured sticky dot, for defects this dot represented severity.
Initials of the current owner.
Time spent on the work item. We would dot all items that were in progress every half day.
Optional. Date the post-it needs to be completed by.
Optional. Identifier from the external system, e.g. Defect Id.

The team were educated on the system in under half a day and by week 4 our Kanban had grown to incorporate another cupboard and many more modifications:

We cleared the finished section of the board (far right) every week. The board above is telling us that we spent a lot of our time addressing failure demand in the form of defects. The concern here is that the actual estimated and paid for work is represented by the pink post-its on the far left and they didn't move for over a month!

Retrospective

The Good

The teams focus was aligned to completing work.
Encourages the team to recognise, record and make improvements.
Anybody can write up a post-it and add to the backlog, I'd often say "don't tell me, tell the board".
Single visualisation of the work backlog, work in progress and work completed.
See different types of work at a glance.
The team has autonomy over pulling new work, creating a sense of ownership which is lost when work is assigned.
Managers can prioritise work in the backlog.
Colourful and tactile, giving a sense of fun to the project.
Flexible and adoptable. We altered the board as our understanding improved.
Simple and cheap. The total cost of implementation was less than £30.
Easy to gather metrics about how much work the team can get done.
The simplicity of the solution promotes the idea that it is easy to change and customise.

The Bad

Doesn't work with distributed development teams for obvious reasons.
It's simplicity can be interpreted as amateurish which results in the idea being written off.
Easy to forget to mark post-its with key information, particularly dates and owner information.
Can be difficult to find a particular post-it, the problem somewhat compounded by using identifiers from external tools.
No backup, although conversely it's less likely to crash and lose your data!

The Impact

The board showed us that there was more work that needed doing than was planned or imagined.
The previous development approach had led to a lot of defects.
Developers can self-organise and work honestly if they are given the chance.
The role of management is to remove problems (purple post-its) and to optimise the system to improve the flow of work through it.

The Kanban board provided us with a greater level of insight into what was happening on our project. The visualisation of work enabled us to make better decisions about how to utilise our time. By recognising that we have a finite number of resources and a large amount of work, we can make team decisions about how best to proceed.

In some ways the Kanban board affirmed what we already knew, that our project was seriously challenged, but it also gave us a framework to work within. Understanding and learning about your situation is simply the first step in escaping it, without walking through the door!

Google Android Built Using Waterfall?

stucam — Wed, 17 Feb 2010 19:15:00 +0000

Contrary to what the predictive text suggests, the Scrum teams I have worked in have always been rather pleasant!