Jan 27 2010

Who you gonna call?

Category: Just for funJoeGeeky @ 22:37

I don't know how I always find these kind of people, but I am glad they exist... Spend any amount of time with someone who enjoys doing this sort of thing and then re-enter the real world and life just seems boring by comparison. I think we need more of them. 

Tags:

Jan 25 2010

SCRUM-tastic Tuesday - Your time is up!

Category: Intellectual PursuitsJoeGeeky @ 19:09

As I mentioned as part of the lead-in article SCRUM-tastic Tuesday, Scrum tries to address a number of time-management dynamics that can lead teams to lose focus. This is generally referred to as time-boxing, and has only a few basic rules.

  • All meetings have a fixed length
  • Attendance is enforced
  • Start exactly on time, whether or not everyone is present
  • End exactly on time, whether or not everyone is done talking
  • Stick to the Agenda
  • No Agenda means no meeting

These concepts are pretty simple and are geared towards ensuring everyone gets the most out of each meeting and that meetings do not get side-tracked or devolve into complaint sessions (except for the Retrospective meeting). While Scrum prescribes a number of meetings throughout the Sprint life-cycle, the most well know is probably the Daily Scrum meeting. When we apply the rules it may look something like this...

  • The meeting will last precisely 15 minutes
  • The meeting will start precisely at 10:00 am
  • Each pig will address the following three questions in 60 seconds or less
    • What did you do yesterday?
    • What will you do today?
    • What impediments do you have?
  • Any remaining time will be open for questions from the chickens or general team discussions

Believe it or not this meeting is very effective and is geared towards keeping the larger team informed of where everyone is and who may need help. Given the short amount of time in this meeting, momentum and adherence to the rules is very important. Here is a quick tip to keep this moving and make sure everyone learns to keep to the important details.

Go out and buy yourself a digital timer. For each pig, set the timer to 60 seconds or so and let the pig answer the daily questions. When the time expires, interrupt the speaker, reset the timer, and move on to the next pig. Continue this until you reach the end, or until the meeting time has expired. This may seem a bit harsh and at times it may even seem rude, but once you go through this a few times people will tend to stick to what is important. Before you know it, your Daily Scrum meeting will be running like a well oiled machine.

As it turns out, I do have a preference on timer selection. Again, it may seem silly, but I recommend you choose a timer that can easily be heard by everyone even when you are setting the time. I can't really explain it, but there seems to be something about hearing the time being set, starting, and ending that reassures people they are getting a fair slice of time. Here is one that we use...

If you feel you need something a bit nerdier, you could also get one of a number of free IPhone apps that do the same thing.

Tags:

Jan 21 2010

What kind of Response is that?

Category: Intellectual Pursuits | Rabbit TrailsJoeGeeky @ 22:14

During my time developing Business-to-Business (B2B) technologies, I saw and continue to see what I feel is a ridiculous pattern of behavior. In this community many systems communicate by POSTing content between systems. As you might expect, there are a number of things that can go wrong so inevitably a system responding to a request will have to send an HTTP Status Code to indicate success, failure, etc. All too often these systems recognize/send only two HTTP Status Codes, namely 200 (success) or 500 (failure). Unfortunately they are usually implemented incorrectly which leads to no end of useless, duplicative, redundant, and inevitably failed communications. Lets walk through a simple scenario to demonstrate exactly what happens.

  • Requesting system sends a request with incorrect content
  • Receiving system recognizes invalid content and sends a 500 (e.g. Internal Server Error) to indicate failure  

If you define the status codes simply as 200 (success) and 500 (failure) this may seem reasonable, but as usual, the devil's in the details. 200 equaling success is generally not in dispute, but lets take a closer look at the definition for 500.

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request.
- Hypertext Transfer Protocol -- HTTP/1.1 [RFC2616] (http://tools.ietf.org/html/rfc2616#section-10.5)

Note the statement "it has erred". Any system that is compliant with the HTTP standard would read this and think the target system had a problem and retry the same request again immediately, or at a later date. The problem is, the sender is the problem in this scenario... They can resubmit all they like and the result should always be the same. Here is where you start becoming your own worst enemy. Many organizations will create cases around failures like these and follow up, triage, or otherwise investigate because in B2B you never like saying no to any request.

The sad part is; at least in my experience; they end up contacting the requester and telling them to fix their content and not fixing their own system. In a manner of speaking, generating responses that lead to an unnecessary increase in work-load is like defecating in your own mouth. Sure... it's survivable, but no matter how you look at it, it will never taste right. Increased traffic, wasted bandwidth, redundant case load, customer (e.g. requester) frustration, the list goes on. In this case, a better response would be to use the 400 series message.

The 4xx class of status code is intended for cases in which the client seems to have erred.
- Hypertext Transfer Protocol -- HTTP/1.1 [RFC2616] (http://tools.ietf.org/html/rfc2616#section-10.4)

Again... note the statement "client seems to have erred". This would be a more appropriate response to our scenario, a response of 400 would be enough to tell a standards compliant system that the request was not valid and NOT to try again until the request is corrected. Oddly enough, many B2B standards provision for codes beyond 200 and 500 but for some reason they don't seem to follow their own advise. Another common misuse of the 500 code is to send it when a user fails to authenticate or fails to have the authorization level (e.g. permission, right, or role) to perform a given action. In this case, a response of 401 (e.g. Unauthorized) is more appropriate.

For those of you who are thinking this is completely obvious and you would "never" do something so silly, chances are you have already done it and didn't even realize it. Consider the following code:

Response.Redirect(http://www.smelser.net/blog/default.aspx);
 

On the surface this may look pretty straight-forward. What you may not realize is that under the covers this sends the browser an HTTP Status Code of 307 (e.g. Temporary Redirect). If you have done your research on how web-crawlers work (Internet or Intranet) this kind of response can lead to pages not being indexed. Assuming you actually want to be found, this could be a problem. In my experience, people who use this call rarely mean it to represent a "temporary" redirect, so a more appropriate response would be 301 (e.g. Moved Permanently). As a side note, Microsoft will make this more obvious as part of ASP.NET 4.0 and MVC 2.0 by providing the Response.RedirectPermanent and Response,RedirectToRoutePermanent. In this mean time you can just make your own by writing an Extension Method for the HttpResponse class. 

Here is another missed opportunity for those of you who use durable (or reliable) services such as message queues. If you are sure you will never lose a request, and you actually experience a "real" 500 condition (e.g. your service fails), you can respond with a status code of 202 (e.g. Accepted). This tells the requester that you got the request, although you cannot provide a complete answer with respect to its success. If your system (or protocol) has a mechanism to check the status of requests this is ideal because you can process the requests once your system comes back online and they can check for final acceptance at a later date. This can also be useful when you need to take a system offline for maintenance or upgrades.

Consider services that are load balanced. If a slow response is worse than a failed response; due to SLA's, customer experience, or whatever; you may want to have your server/application send a signal that tells your load balancer to send a request to another available server. For many load balancing products this can be as simple as sending a response code of 503 (e.g. Service Unavailable). Again, this could be useful when performing upgrades or maintenance.

So what does this all mean? Take a closer look at the standard codes and do your best to align to the them. It may be a little additional development, but in the end it will save you a lot of time and money. For a summary of the basic status codes, take a look at http://en.wikipedia.org/wiki/List_of_HTTP_status_codes.

Tags:

Jan 18 2010

SCRUM-tastic Tuesday

Category: Intellectual PursuitsJoeGeeky @ 22:59

Over the years I have worked with a lot of software engineering processes and; generally speaking; I like them all. Here are a few well known processes I have worked with:

In my experience no one process is "best", although any one can be better than the next for any number of reasons. Just like your trousers, you have to the buy-in to the correct size, style, colour, level of affordability, etc... and as your size changes or styles change you may have to buy a new; and different; version. To use more practical terms here are a few things that may drive your choice:

  • The type of development being undertaken (Ex. Web Sites, Monolithic clients, Enterprise Services)
  • Team(s) structure and experience (Ex. Developers, Testers, Designers, Architects)
  • Degree of fidelity in engineering artifacts or required artifact deliverables
  • Organizational process maturity

For the past several years I have been working in the SCRUM process and have really come to appreciate what it has to offer. Things like focus on responsibility, team momentum, time-boxing activities, and more. While each of the aforementioned processes address these in one form or another, none seem to do it like SCRUM.

From my perspective, its genius lies in its simplicity. If you do a little reading it won't take long to realize the process focuses on simply bringing the right people together at regular intervals to ensure everyone is moving with a common vision, and that real (tangible) progress is being achieved. Lets look at just a few aspects to the process:

Artifacts

SCRUM doesn't really define at what fidelity any one work product should achieve such as  requirements, design, storyboards, etc... It simply structures a conversation between those that define requirements/expectations/vision and those that need to understand it well enough to implement solutions. If you want to use an SRS, BRD, User Story, Storyboard, or even a yellow sticky on a wall, the choice is yours. Compare this to approaches like CMM/CMMI which strive to produce more high-fidelity artifacts, sometimes to the point where the artifacts become the product. In their defense, higher degrees of fidelity are needed for some projects especially when human safety is concerned.

Roles

SCRUM defines very broad roles such as Product Owners and The Team and leaves the rest for you to define. Product Owners define what's needed, and the relative priority to meet business demands, while The Team are those that provide solutions for business needs. Compared to the aforementioned processes this is very straight-forward, and provides any organization the flexibility to fill these two groups in a manner that best suites their needs.

Time-boxing

Sometimes it is amazing just how much time can be spent (or wasted) in meetings and while in a meeting you cannot possibly be working towards the creation of a product. SCRUM tries to balance the need to communicate on a regular basis, the need to keep momentum by not spending all your time in meetings, and to set a real deadline with a product commitment. My favorite bit is the notion that you can't keep changing requirements daily, rather, you set a target based on what you know now and let The Team get there. Once there, reassess and go again. For those of you who are Agile aficionados you recognize the Iteration.

It doesn't stop here. Do some reading and you will see similar themes in other areas. With all that said, I do not intend to completely regurgitate the details of this or any process, but I have decided to do a series of SCRUM-focused blog Posts to identify some really simple practices that just might make things more successful for your SCRUM team or teams that are just getting started with the process. Check back next SCRUM-tastic Tuesday.

Tags:

Jan 16 2010

Exceptional Threading

Category: Rabbit Trails | Tips and TricksJoeGeeky @ 21:27

When multi-threading applications it can be easy to lose the plot from time to time. Sometimes it can take all your energy just to remember what is running when, how to sync, lock, join, etc... Often, exception handling takes a back seat or can lose consideration with respect to where exceptions should; or will; be communicated and how they may be handled. Even if you assume you are the greatest developer who ever lived, exceptions are inevitable, and when they occur in a multi-threaded application the root cause can be very hard to isolate. In fact, depending on the type of feature being executed on a thread you may have silent failures leading to no end of rabbit-trails as dependent behaviors and/or components exhibit who knows what.

With that in mind, there are a number of patterns that can keep you out of trouble; or at least; help you isolate problems when trouble strikes. Lets tackle one of the most commonly used threading patterns first, the QueueUserWorkItem.

ThreadPool.QueueUserWorkItem(DoSomethingFeature, null);

This is something I see a lot of and unfortunately it can lead to disappointment. Any unhandled exceptions that occur in the aforementioned DoSomethingFeature() method will reach the AppDomain and will crash your application. There are; at least; two patterns we can employ to deal with this kind of problem. The first pattern focuses on catching exceptions. Thanks to lambda support, we can easily wrap our feature methods with some basic try {} catch {} blocks.

ThreadPool.QueueUserWorkItem(state =>
    {
        try
        {
            DoSomethingFeature(state);
        }
        catch (Exception ex)
        {
            //Handle the exception
        }
    });

The above approach will provide you an opportunity to catch unhandled exceptions but does not provide an elegant means of communicating to other threads so they can take action if needed. To achieve that, you could employ the Observer Pattern using static Events... Here is a simplified example:   

Define a delegate and EventArgs implementation to communicate whatever is needed to facilitate your exception handling needs...  For this sample, all we need is the Exception itself.

public delegate void CustomExceptionHandler(object sender, ExceptionArgs e);

public sealed class ExceptionArgs : EventArgs
{
    public Exception Exception { get; set; }
}

Next, define a static Event in a location that is accessible to all required areas of concern.

public static event CustomExceptionHandler OnCustomException;

With that in place, we can now queue our threads as we did before, but this time we will wire up the new event/delegate created previously to communicate exception details.

ThreadPool.QueueUserWorkItem(state =>
    {
        try
        {
            DoSomethingFeature(state);
        }
        catch (Exception ex)
        {
            if (OnCustomException != null)
                OnCustomException(null, new ExceptionArgs { Exception = ex });
        }
    });

For those layers charged with handling or responding to unhandled exceptions, they just need to subscribe to the Events. 

OnCustomException += ((sender, e) => Console.WriteLine(e.Exception.Message));

Now lets address a second commonly used unhandled exception catch pattern. You may have seen code such as follows:

AppDomain.CurrentDomain.UnhandledException += ((sender, e) => /* catch and continue */));

This approach is often misunderstood... On the surface, it may appear as a method of catching an unhandled exception and preventing your application from crashing, but testing will show that this is not true starting with .NET 2.0. This delegate is provided to allow the application to save state, log exception details, etc. but will not prevent a terminal Exception from bringing down the AppDomain. Using this for the stated purposes is still a good idea, but you will need to employ other methods such as the ones above to prevent total failure.  

Tags: , ,

Jan 1 2010

Follow the chain of command

Have you ever seen those seemingly endless if -> else if -> else if -> ... -> else if statements? Sure you have! You have possibly even written one or two, but confessions are not really necessary. In some cases, all we are trying to do is subject an object to a line of inspection and then branch based on those results. This may be fine, but if you find yourself continuously adding new else if items to the end of that statement, there may be another pattern that is more appropriate. Enter the chain-of-responsibility pattern, What is that?  

In Object Oriented Design, the chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains a set of logic that describes the types of command objects that it can handle, and how to pass off those that it cannot to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain.
- Wikipedia (http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern)

The description sounds somewhat complicated, so a walkthrough can make this a lot easier to understand. Lets start with a simple example. Say we want to have a bunch of independent modules inspect a payload to ensure it contains something. If we exit the end of the chain with no exceptions, it passes; otherwise it fails. The first thing we need to do is define the structure of each link in our chain.

public interface ILink
{
    //Holds the next link in the chain
    ILink SuccessorLink { get; set; }
    void Inspect(object payload);
}

Any module that is a candidate for this chain will need to implement this interface and honor the flow control by passing valid payloads down the chain and short-circuiting others.  Beyond that, each module can do whatever they need. Next we need some links that implement our interface. Both of the below sample modules will simply inspect the payload and either pass it down the chain or short-curcuit via exception.  In reality, using exceptions is not the most efficiant way to do this but it suites the sample. You can use any number of methods to handle the short-curcuiting process, but not calling the Inspect method is enough to end processing. 

public sealed class LinkTypeA : ILink
{
    #region ILink Members
    public ILink SuccessorLink { get; set; }
    public void Inspect(object payload)
    {
        if (payload.ToString().Contains("A"))
        {
            if (SuccessorLink != null)
            {
                SuccessorLink.Inspect(payload);
            }
        }
        else
        {
            throw new NotSupportedException("The payload is not supported");
        }
    }
    #endregion
}

public sealed class LinkTypeB : ILink
{
    #region ILink Members
    public ILink SuccessorLink { get; set; }

    public void Inspect(object payload)
    {
        if (payload.ToString().Contains("B"))
        {
            if (SuccessorLink != null)
            {
                SuccessorLink.Inspect(payload);
            }
        }
        else
        {
            throw new NotSupportedException("The payload is not supported");
        }
    }
    #endregion
}
 

Next we need some infrastructure to build and manage the chain. Normally I like to approach this process using some kind of Factory pattern driven by configuration meta-data. For this sample we will just create a simple chain manager to demonstrate how to build a chain.

public static class ChainManager
{
    public static ILink Chain { get; private set; }
    public static void AddLinkToChain(ILink link)
    {
        if (Chain == null)
        {
            Chain = link;
        }
        else
        {
            AppendLinkToChain(link, Chain);
        }
    }

    private static void AppendLinkToChain(ILink link, ILink chain)
    {
        if (link == null) return;

        if (chain.SuccessorLink != null)
        {
            AppendLinkToChain(link, chain.SuccessorLink);
        }
        else
        {
            chain.SuccessorLink = link;
        }
    }
}

With the ChainManager available, we just need to initialize the chain and then submit a payload for processing:

ILink linkA = new LinkTypeA();
ILink linkB = new LinkTypeB();
ChainManager.AddLinkToChain(linkA);
ChainManager.AddLinkToChain(linkB);

try
{
    ChainManager.Chain.Inspect("ABC");
    //The payload passed all checks
}
catch (NotSupportedException)
{
    //The payload failed a check
}

One of the great things about this pattern is that you can easily add and remove links, and each link can represent a completely seperate area of concern. When building the chain, you can also order items so they execute in the most efficient manner. This involves placing links that are more likely to lead to short-circuiting high in the link chain. Additionally, since all the links are seperate areas of concern, it makes these easy to test in isolation. 

Give it a think...  Worth considering for some architectures.  Enjoy! 

Tags: