Jeff W. Barnes

Return to Twitter

Due to the persistence of Keith Elder, he has managed to convince several of the speakers at Alabama Code Camp to either sign up for Twitter or start using it again.  Some of the suckers that fell into the trap include Robert Cain (Arcane Code), Todd Miranda, and Doug Turnure. 

Several months ago, I signed up for Twitter and managed to stick with it for a little while, but it became too much effort.  One of the biggest gripes that I had with it was the limited abilities to send updates.  At the time, you were restricted to the web site or text messages from your phone.  Personally, I'm not a huge fan of text messaging, especially when I'm sitting at the computer.  There was supposedly an IM interface, but it never worked.

Fast forward to present day and it appears as though their web site has been greatly improved.  Twitter has opened up some web services that have enabled a number of custom clients to be created.  Keith was a big advocate of Witty, which is a WPF smart client.  (What a shocker...Keith evangelizing a smart client application).  After getting it downloaded and setup, I have to admit that it is quite nice.  The application has that smooth WPF look and it appears to be fairly responsive.

So, I have made my return to Twitter.  For the last couple of days, I have been sending periodic updates.  Admittedly, I can feel it becoming somewhat addictive.  When there is a moron at the office causing the day to suck tremendously, it provides a nice little outlet to let everyone know about it.  If you are interested in following stalking me, here is the link to my twitter feed: http://twitter.com/jeff_barnes.

Alabama Code Camp Presentations

I decided to take a couple of nights to catch up on sleep.  So, I'm a little late about posting a follow up about code camp.  At any rate, another code camp has come and gone.  In my opinion, the event was enormously successful.  It appeared to be one of the largest crowds to date for the Alabama Code Camp series.  Registration prior to the event was closed after 200 people, and I would be willing to wager at least 150 or more of them showed up on Saturday.

For the most part, I felt as though my sessions went well.  I would have to say my classic "Introduction to WCF" presentation was my best of the day.  The room was packed out and most of the attendees seemed to be engaged and interested.  If it hadn't been for a few slots that needed to be filled, I probably wouldn't have even given the introductory talk.  But, I'm glad that I did.  It goes to show that there are still a lot of folks unacquainted with WCF or were looking for a refresher.  I'll be sure to submit this one again at future events.

My talk on REST vs SOAP from a WCF perspective also went relatively well.  However, the 45 minute limit on the session really caused me some grief.  During my rehearsal of the presentation, I felt pretty good about the layout in regards to time, but it didn't pan out so well for the real deal.  I ended up having to rush through a lot of the code at the end. 

The parallel programming talk was easily my worst of the day, but I appreciate those who told me they enjoyed the material.  It was definitely an experimental presentation, and I probably kept it at too high level.  As I was preparing the material, I restructured it several times and never reached a point where I was completely happy with it.  Given the wide range of experience and backgrounds of individuals attending code camp, it was difficult to decide which group to target.  At any rate, I appreciate the attendees allowing me to use them for a trial run.  I will definitely be giving this presentation again, but it will be dramatically different.  Most likely, it will become a two part presentation.  The first one will be mostly conceptual with adequate code to reinforce the concepts and the second part will jump right into the nuts and bolts of Parallel LINQ.

Here are the downloads for each presentation.  Each zip file contains both the presentations and the demos.

Introduction to Parallel Programming
Introduction to Windows Communication Foundation
REST vs SOAP: Is There Really A Winner (WCF's Perspective)

SOA Society Meeting - Feb 26th

Below is the announcement for the February Meeting of the SOA Society...

After exploring domain-specific modeling at the January meeting, the SOA Society is going to look at service-oriented architecture in the context of the Business Services Model at the February meeting.  Marc Guthrie, the CEO of COMFRAME, will present, “ SOA – The Perfect Storm”.

According to Guthrie, “How parallel progressions in Information systems complexity, business knowledge requirements, and technology /standards advancements has created the perfect environment for the business services model.”

Join us Tuesday and hear about the forces that are driving the next wave of technology innovation. The meeting is as usual free but please R.S.V.P. The January meeting was a packed house. We want to be sure that there will be pizza enough to go around.

Meeting Date: Tuesday February 26, 2008
Meeting Time: Gather at 6:00 PM, Presentation @ 7:00 P.M.
Place: Intermark Group, 1800 International Park Drive, Suite 500 (off Acton Road, near the Acton Road Exit off I-459); Birmingham, AL 35243 [Directions 1800 International Park Drive]
Host: Scott Pierce
Coordinator: Margaret Marston
Refreshments: Pizza
Meeting Fee: FREE
RSVP: Margaret Marston [mmarston@windstream.net]

Getting Started with PLINQ

Going forward, I am hoping to write at least one post per week about PLINQ.  Since this is really the first one, it seemed like a good starting point would be going over how to get setup with the bits.  Keep in mind that PLINQ is currently available as a CTP.  The most recent version is the December 2007 CTP.  Although I haven't experienced any problems, you should remember that it is still in a pre-release status.  In other words, don't go installing it onto critical environments.

You can download the CTP here.  It should be noted that PLINQ requires .NET Framework 3.5 and Visual Studio 2008.  Windows Server 2003, XP, and Vista are the only supported OSes.  Hopefully, you aren't trying to install it on Windows 95 or you have bigger problems.  There are two files to download:  ParallelExtensions.zip and ParallelExtensions_Dec07CTP.msi.  Obviously, the msi file will install the bits on your machine.  The zip file contains the API documentation. 

Before you even open up Visual Studio, I strongly recommend reading through the API documentation.  It also contains an overview of the different ways to leverage PLINQ as well as some of the concepts behind it.  There isn't a huge amount of information, but it is a good primer that helps point you in the right direction.  I think it is rather commendable of the Parallel Programming Team to provide this type of documentation with their first CTP.  I have worked with some CTPs that didn't give you anything to go on in terms of documentation.

When you get ready to fire up Visual Studio, you will need to add a reference to the System.Threading assembly.  After your reference is added, the fun stuff is contained within System.Linq, System.Linq.Parallel, and System.Threading.  You may find it helpful to peruse the assembly with Reflector to get an idea of the classes and their relationships.

Enjoy!

My Technical Focus Areas for 2008

When it comes to my list of favorite technologies, it is no surprise to find WCF at the top of the list.  Ever since I first experimented with the bits of the early CTPs, I have been an avid supporter of the platform.  The design is so flexible and extensible that I suspect it will continue to be the communication goo of Microsoft .NET solutions for a number of years.  While I have no intentions of abandoning WCF, I have been feeling a desire to branch out a bit into some other areas.  After giving it quite a bit of thought, I have decided that I am going to focus my research/learning efforts in the following areas for 2008:

Oslo
In case you haven't heard, Oslo is the codename for a concerted effort by the Microsoft Connected Systems Division to unify some of their products into a complete SOA platform.  For the most part, it will be manifested in the next major version of BizTalk, Visual Studio, and .NET Framework.  However, I suspect there will be some announcements within the next few months that unveil some of the pieces to the puzzle.  This is an area that greatly interests me, and I intend to follow the developments of Oslo very closely.  As a side effect, I anticipate becoming much more intimate with BizTalk this year.

Parallel LINQ (PLINQ)
I have always been fascinated by the complexities of parallel processing.  It has so much potential to provide truly scalable solutions that really harness the capabilities of the underlying hardware.  However, let's be honest.  Parallelism is not a simple programming endeavor.  It can quickly become very complicated, and a lot of developers have a hard time really understanding the intricacies of multithreaded execution.  Furthermore, the current state of the hardware is making it difficult to ignore the necessity of parallelism.  In seven years from now (maybe sooner) when there are CPUs with 128 cores, you will have a hard time taking advantage of the hardware if you are still programming in a single-threaded sequential fashion.  Fortunately, PLINQ has a lot of promise for making the lives of developers much simpler in regards to parallelism.  During the coming months, I intend to delve more deeply into PLINQ and it will likely be the subject of a number of posts.

F#
Functional programming has recently received a lot of attention, particularly in the realm of Microsoft .NET.  Personally, I think F# has a lot to do with it.  While it is still considered an incubation project within Microsoft Research, it has been revealed that F# will become a featured language of .NET with full support in Visual Studio.  I'm really excited about the benefits this language has to offer.  While many of the concepts are still somewhat foreign to me because of my imperative programming background, there have been a number of "wow" moments from listening to podcasts from DNR and Hanselminutes that featured F#.  Within the next month or so, you should begin to see a few posts showing up here about F#.  I suspect there will be some good material to write about as I attempt to wrap my mind around many of the functional programming concepts.

Don't Use Types for Locking

Earlier this week, I posted a reminder that static methods don't always require locking.  However, I also wanted to emphasize to exercise caution when selecting the object that will be used for a lock.  For years, there have been many examples that use the containing type for the lock object, but this is not really a good idea.

Here's an example of the wrong way:

public class MyClass
{
    private static int _counter = 0;

    // Don't do this!
    public static int StatefulAdd(int value1, int value2)
    {
        lock (typeof(MyClass))
        {
            _counter++;
        }

        return value1 + value2;
    }
}

There have been numerous publications and blog articles written with locking examples that do something similar.  However, this is not a recommended best practice, and Microsoft has been attempting to modify their documentation to reflect the preferred approach.  Before I get into the recommended approach, let me clarify what's wrong with the other solution.

First, the typeof operator is relatively slow, at least when compared to accessing a variable within the class.  Second, typeof returns a Type object, which is a publicly accessible object.  As such, any other class could choose to lock on the same object, which opens up the potential for deadlock scenarios. 

So, what is the recommended best practice?  Rather than using a Type object or some other publicly accessible object, it is recommended to use a private static member variable.  This ensures that only the implementation within the containing type has access to the lock object. 

Here's an example of the right way:

public class MyClass
{
    private static int _counter = 0;
    private static object _lockObject = new object();

    // Do this!
    public static int StatefulAdd(int value1, int value2)
    {
        lock (_lockObject)
        {
            _counter++;
        }

        return value1 + value2;
    }
}

For a more insight into possible problems with the typeof approach, there are a couple of articles that I recommend reading.   Here is a link to an MSDN article from 2003.  Here is a link to a blog post from Joe Duffy aka Threading Master.  Even though the MSDN article was dated back in 2003, I have still seen some articles as recently as 2007 that still contain examples of using typeof.  As they say, some habits die hard.

IPSA Meeting - February 8th

The February meeting for the Internet Professionals Society of Alabama (IPSA) will be on Friday, February 8th.  The meeting will be held from 12PM to 1PM in the Special Events Room of the McWane Science Center.  There will be designated networking time from 11:30AM to 12PM prior to the beginning of the presentation.

Jere Chandler will be presenting "Simplicity in Design". Here is the abstract:

Simplicity in design is one of the primary concepts that will give software companies a competitive advantage over the next few years. Jere Chandler, a User Experience Engineer for DAXKO, will discuss why simplicity is so important, the reasons we tend to complicate things, and why the software that's easiest to use is usually the most difficult to create.

Be sure to RSVP at the site if you are planning to attend.

I'll see you there.

BSDA Meeting - February 7th

I meant to post about this earlier in the week, but I suppose it is better late than never. 

On Thursday, February 7th, the Birmingham Software Developer Association will be meeting at New Horizons.  Doug Turnure, our regional Microsoft .NET Developer Evangelist, will be giving a technical overview of Visual Studio 2008 and LINQ.  The presentation will begin at 6:30 PM.

If you haven't had an opportunity to learn much about VS2008 and what it has to offer, this will be a good chance to do so.

Static Methods and Locking

Recently, I was reviewing some code for a new application and noticed several static methods that were locking to safeguard against concurrently executing threads.  However, the majority of these static methods did not involve any static data.  So, it seemed like a good opportunity to post a reminder that it isn't always necessary to lock a method simply because it is static. 

Recall that static methods belong to the class rather than instances of the class.  As such, any concurrently executing threads will invoke the same static method.  Obviously, it becomes a possibility that a collision could occur between concurrent threads.  However, this is only the case when the static method uses static state.  As long as the static method is stateless, the static method will operate upon the stack of each thread independently of one another.

Consider the following example:

public static int StatelessAdd(int value1, int value2)
{
    return value1 + value2;
}

In this method, there is no state that has to be managed between invocations.  Each time the method is executed, the executing thread will supply the parameters from its stack.  The implementation is simple and doesn't utilize any static state that could be concurrently accessed by multiple threads.  This situation doesn't merit any need for locking.

Now, consider another example:

public static int StatefulAdd(int value1, int value2)
{
    _counter++;
    return value1 + value2;
}

In this method, there is a static member variable used to track the number of times the static method has been invoked.  This scenario introduces static state that is modified during the operation.  As such, it is possible that a collision could occur between concurrently executing threads.  This situation does merit the need for locking.  

Here is a revised example:

public static int StatefulAdd(int value1, int value2)
{
    lock (_syncLock)
    {
        _counter++;
    }

    return value1 + value2;
}

Note that the section of code that modifies the static state has been enclosed with a lock statement for thread safety.  Obviously, this is a contrived example, but it sufficiently conveys the concept of when locking is necessary.  The key thing to remember is locking should only be used when absolutely necessary.  Otherwise, you are unnecessarily introducing points of contention that contribute to performance degradation.