Vanguard Coder

Simple Life of a Keen Developer

Singleton Gymnastics

leave a comment

As books on C#5.0 (using .Net 4.5 framework) are being released, I remember during the pre-.Net 4.0 dates the awesome amounts of gymnastics that were done around the simplest design pattern – the Singleton.
Some involved double checking (in and outside the lock), setting up Memory Barriers. Most of this discussion can be read here. Finally System.Lazy came about and the rest was history.

I wonder wonder what’ll the most popular feature in that C#5.0 uses with .Net 4.5


public sealed class IrritatingConstructor
{
    private static readonly Lazy<IrritatingConstructor> lazy =
        new Lazy<IrritatingConstructor>(() => new IrritatingConstructor());

    public static IrritatingConstructor Instance
    {
        get
        {
            return lazy.Value;
        }
    }

    private IrritatingConstructor()
    {
    }
}

Written by zkashan

July 3rd, 2012 at 7:50 pm

Posted in Uncategorized

Visual Studios Unit Test MsTests OutOfMemoryException

leave a comment

With time in some code bases containing a mixture of old code over a decade may end up with a lot of files and thousands of unit tests. The project may not have been refactored and a lot of technical debt has built up. Visual Studio may start of complain and give Out Of Memory Exception and not run your unit tests. A quick fix is to add a registry entry as pointed out here.

Add the following entry: HKLM\Software\Microsoft\VisualStudio\9.0\EnterpriseTools\QualityTools\EnableCMI = 0 (DWORD)

This will turn off auto discovery of unit tests, so compiling after changing unit test names or added new tests will be required.

Not a perfect fix, but something to keep you going for longer when you don’t have any other option.

 

 

Written by zkashan

July 1st, 2012 at 6:53 am

Posted in Uncategorized

Saving the pennies, spending the pounds (or dollars)

leave a comment

I came across a post about pennies in the process which reminded me of some of the high-ceremony estimation sessions that I’ve been to that seem to run days, and not everyone is utilized, and some in which I had to come up with estimation on my own with some consultation with other people in development.

Canada is planning to get rid of pennies. I went to Lebanon recently, where there is no concept of pennies. A few other countries are going down that route as well – primarily due to inflation where the purchasing power has been eroded, and to manage them becomes expensive.

Having read a brochure by GreySpark, it reminds me of the the process drag created which elongate the project such as filling out forms at the end of the different stages (which no one reads, and is only there due to the process), not considering non-functional requirements, or working on slow-dated machines, and large solutions with many projects which cause development time and the learning curve to increase. Using tools such as Resharper save a lot of  typing time, makes running tests quicker (compared to what Visual Studios provides for MSTests). Avoiding creating custom frameworks, or solving small problems which have already been solved is also useful (e.g. ConcurrentDictionary in C# for storing values with its AddOrUpdate method, System.Lazy for singletons, an using (P)LINQ rather than writing loops are .Net 4.0 code specific examples).

 

Written by zkashan

June 5th, 2012 at 6:26 pm

Office Tours – Development Environment (the physical one)

leave a comment

Looking for a job is always an interesting experience. You learn and talk about your skills, how the experiences relate to what the company has been doing, and how you can help the company achieve its goals.

For those that are wondering why I have the brackets – There is the technology stack such as here is the other one. The physicial one Zsolt and Martin Fowler such as U-Pod arrangement in lieu to Central.

However, when interviewing, ALWAYS see where the developers are seated, the layout as mentioned above. It is easy to get too much into the process – phone interview, coding challenge, meeting colleagues and managers in meeting rooms, however, in one of the places I went to it seemed rather different and congested. Asking to see where the BA, PM, Business and Developers sit (an office tour basically). The developers were all in a windowless basement which seemed like a converted wine cellar with dull yellow lights that may have been white at some point, and grey concrete floor. On the other hand, I also interviewed at some hedge funds based in building that might have some long history with amazing chandeliers and “expensive” portraits – something out of a mystery movie. Interviews are always interesting!

Written by zkashan

June 3rd, 2012 at 10:07 pm

Posted in Career,Interview

How to Pass Coding Challenge Exercise

leave a comment

Most interviews follow the process of:

  • CV Review
  • Phone Interview
  • Code Challenge
  • In-Person Interview
  • Management/HR Interview.

Passing the code challenge is the easiest part which many developers seem to fall down on. Unfortunately, they take 4-8 hours to do depending on the level of Unit tests you do. This requires a lot of investment in time and effort.

The quickest way to pass is:

1. Use a factory to create different objects (Vehicles, vouchers, etc..)

2. Inject the Algorithm which does the calculation

3. In testing, use mock objects for this algorithm

4. Create a readme about your thoughts, and what could be improved in the code. This is beneficial as the code will be reviewed by someone whose opinion will sway based on the readme.

And that’s it. You’ve demonstrated use of patterns, unit testing and mocking, and will make it to the next round.

Written by zkashan

June 1st, 2012 at 9:15 pm

Posted in Design

Tagged with

Agile Projects:Scope & Estimation

one comment

In Agile developments, the scope line of burn-down charts should never go up unless it is a planned (removing other similarly estimated stories, or adding more resources to the team) addition of requirements to the project. If there are estimates that are bad:

1) If the wider project is believed to have incorrect estimates, then, the entire work should be re-planned, otherwise there is a huge delivery risk, i.e. The entire team having to consistently throughout the project work long hours (developer productivity is limited to a few hours a day and it is unlikely 10 hours of pair programming could work), or having unachievable velocity requirements. However, this is a benefit as this is determine within the first 2-3 iterations (hopefully they’re 2 weeks).

2) Scope line should be progressing by increasing the estimates of the stories that have lower estimates (if some estimates were wrong), but at the same time removing “Would haves” or “Could Haves”

3) It should be looked at on what was missed (e.g. consistently leaving out acceptance test scripts) for the stories to be estimated or a ‘Safety Check’ (used in retrospectives)  to allow the facilitator to check if the developers will be open and honest about estimates.

 

Written by zkashan

May 26th, 2012 at 10:15 pm

Posted in Project management

Smelly IFs

leave a comment

In my years of experience, the most common repeat offender I’ve seen is the excessive use of IF Statements. As a result. I’ve joined the Anti-IF Campaign.

It results in code that is hard to change, maintains, and does not use composition, inheritance, or design patterns to write meaningful code. It is just a code that runs. I’ve spent hours trying to find out bugs in if statements written in butterfly form (nesting going 3-5 levels deep). Try adding a feature to an If statement at the 3rd level which goes down 5 levels. This won’t give you much confidence that it won’t have unintended side effects.

There are some examples in which it may be hard to get rid of such as Mark Needam pointed out unless some overkill solution is applied (Attributes, Validation blocks), but the other common offenders can be removed.

Scenario #1

if ( expression == true)
{
    return true;
}
else
{
    return false;
}

This could be shortened to:

return expression;
Scenario #2

if ( expression = somestring)
{
    return processA;
}
else
{
    return processB;
}

This could be shortened to (VB, or use ?: in C#)

DirectCast(IIF(expression=something), processA, ProcessB), returntype)

The disadvantages is both – processA and ProcessB will be evaluated, possibly making the process inefficient. In 2008, If method was introduced, and direct casting is not necessary. So this can be changed to:

if (expression == something), processA, ProcessB)

Scenario #3

Avoid If at the start of a method and end if near the end. If should not span the whole method.

Scenario #4

If you have nested if’s, see if there are better alternatives. This makes maintenance and manageability of the code difficult. Excessive if’s points towards procedural code, thus should be limited (but not necessarily entirely avoided).

Scenario #5

public void MethodA() {
    if (condition1) // note first line is an if
    {
        50 lines, nesting goes down to three level
    }
else if (condition2)
    {
       similar issue as above
    }
else if (condition3)
    {
        similar issue as above
    }
}

This is probably bad design, and could be replaced by various patterns to make life easier.



Written by zkashan

May 21st, 2012 at 8:48 pm

Posted in Uncategorized

.Net going dynamic

leave a comment

I had a conversation recently, which was more of a lead-up.

It began with when was ‘var’ introduced (.Net 3.0) and why (Linq).

Thus, what about dynamic (.Net 4.0) and why?

The why is interesting. “To be a fake dynamically-typed language like Ruby”, or a more honest answer – to avoid the pain when integrating with IronRuby where before 4.0, reflection had to be used to call on its members. Now with help from the DLR (Dynamic Language Runtime) pain resolved…. I wonder if there will be anything interesting in .Net 4.5

Written by zkashan

May 20th, 2012 at 5:05 pm

Posted in .Net 4.0

The Anemic Design lives

leave a comment

I was practicing a design problem on applying different types of gift and item-category vouchers to a shopping basket with some edge scenarios. The problem shouted out Visitor Design Pattern, which would’ve been a fantastic solution. However, there is a certain level of influence you have depending on recent experience. The key problem stood out was that the voucher should tell the shopping basket how much discount it can give based on its contents.  Separating algorithms out into separate classes could lead to Anemic classes that hold information rather than serve any functionality.

As a result I read up someone’s twitter comments:

“When adding new methods to existing classes ask out loud “Is this appropriate?””

“Make abstractions at the last possible moment & only if they exist in the business, just because concepts seem similar doesn’t mean they are” (I used abstract voucher to derive concrete vouchers)

“Favour explicit code and more concrete classes over awkward abstractions and the quest for a DRY codebase ”

At the end, architecture could be anything, the key thing is to improve with refactoring and new functionality being added in.

Written by zkashan

May 18th, 2012 at 9:43 pm

Posted in Uncategorized

Tagged with ,

Test Drive .NET Development with FitNesse

leave a comment

Test Drive .NET Development with FitNesse by Gojko Adzic

Reading through this book, I made it a point to put ear marks on pages that I think we can use to improve our tests in FA (and potentially Trumps). As I read through a lot of pages near the middle of the became ear marked. This includes suggestion that quick-fit tests should be run seprately (which can be done in the existing environment as FA tests were refactored 2 iterations ago, and thus reduce our waiting time from 6+15 minutes to just 7 minutes) as well as making them more customer centric and readable rather than be developer oriented. This ranged from page formatting to using Do Fixtures. Some idea from this book will be implemented in the next release of my project.

This is one of the books that I would like to keep close and refer to to remind myself to use better ways of writing  Fit tests and to use this framework to its full potential as well as keep things simpler.

Written by zkashan

May 28th, 2009 at 8:13 am

Posted in Uncategorized