Friday was my last day as a member of the Improving Enterprises team.  I was offered a position at another company in the Irving area that I simply could not, for my sake and my family’s, refuse.  I will admit, however, that the decision to leave Improving was not an easy one.  I’ve learned more, not just about software development but about myself and what I want out of my career, in the last two years than I did in the entire time before I joined Improving.  My time at Improving has been a blessing and it has been both an honor and a privilege to work with some of the most talented technology folks in the metroplex.  Along the way I’ve dropped a few bad habits (regions, etc.) and picked up a ton of new ones but I can guarantee that I would not be embarking upon the opportunity that I am now without my experiences at Improving.

Besides the change in employer, I’ve also had a lot of other things going on recently.  I’ve developed a deep interest in mobile technology (specifically MonoTouch) and have had the privilege of being invited to speak at several user groups including the Dallas C# Special Interest Group, the Shreveport .NET User Group and the Aggieland .NET User Group in College Station.  I’ve learned a lot from these engagements and have had the opportunity to meet some very interesting folks.  By the way, if you’re interested in learning more about MonoTouch, check out my talk on INETA Live.

Beyond that, I also have a lot of other stuff going on that I’m not really at liberty to speak about at the moment.  Don’t worry, though… more details should be forthcoming soon.  Let’s just say that I don’t have a lot of free time lately and I feel very blessed to have an understanding wife.  You may have noticed that I haven’t been posting nearly as often to this blog lately, but, again, I’ve been incredibly busy.  Hopefully the updates will pick up again soon.

In the meantime, keep building better code.  Stay tuned for more information soon.

If you’re interested in digging deeper into MonoTouch, take a look at these resources that I’ve pulled together.  There’s some good stuff in there.  I’m going to clean up the application that we built tonight a little and post it to CodePlex at some point next week.   I’ll be sure to send out a tweet and let you guys know when it’s available.

Again, thanks to those of you that attended and I look forward to seeing all of you at the next meeting in January.  As always, feel free to contact me directly if you have any questions about the material that we went over tonight.  Viva la C#!

UPDATE: The source code from last night has been cleaned up and published to CodePlex.  Word.

YET ANOTHER UPDATE: You can watch this session in its entirety here.  I want to extend a special thanks to Shawn Weisfeld for recording and editing the video.

WriteThisNotThat.com is a community-based site dedicated to building a library of good development practices by profiling the really ugly ones.  By really ugly practices I mean that 700-line-long method that makes you vomit in your mouth a little everytime you think about it.  How about that old class that’s 90% unreachable code because it’s covered in hacked-together bandages?  That’s what we want to see!  This site is welcome to all developers regardless of language (even VB) or experience level.  Seasoned architect?  Great!  Straight out of college?  Even better! 

We’re in the process of courting some sponsors so that we can spin up a monthly contest based on your votes.  Post your ugly source code and there might be a little something in it for you. 

Drop by when you get chance.  If you don’t learn anything the first time around it will atleast be good for a chuckle or two. Next time you run across some especially gnarly source code, share it with us!  We’d love to see it! 

If you like the site, please don’t keep it a secret.

Fluent interfaces allow developers to work with objects in a more natural and readable fashion by chaining methods together.  By building a fluent interface I can make my API not only more concise but much easier to use.  Take a look at the following code:

Wait.Until("1:45 PM").Then(() => DoSomethingImportant());

By chaining methods together we’re forming a sentence describing exactly what we want to happen. We want to wait until 1:45 PM and then do something important. But how do we implement this interface?  Wait is actually a static class that defines the For and Until methods. Let’s take a closer look to see what’s going on under the covers:

public static class Wait
{
  public static WaitContext For(TimeSpan waitFor_)
  {
    if (waitFor_ <= TimeSpan.Zero)
        throw new ArgumentOutOfRangeException("waitFor", "The supplied time span is negative");

    return new WaitContext(waitFor_);
  }

  public static WaitContext For(string waitFor_)
  {
    TimeSpan waitFor = default(TimeSpan);

    if (!(TimeSpan.TryParse(waitFor, out waitFor)))
        throw new ArgumentOutOfRangeException("waitFor", "The supplied time span is invalid.");

    return For(waitFor);
  }

  public static WaitContext Until(DateTime waitUntil_)
  {
    if (waitUntil_ <= DateTime.Now)
        throw new ArgumentOutOfRangeException("waitUntil_", "The supplied date is in the past.");

    return new WaitContext(waitUntil_);
  }

  public static WaitContext Until(string waitUntil_)
  {
    DateTime waitUntil = default(DateTime);

    if (!(DateTime.TryParse(waitUntil_, out waitUntil)))
        throw new ArgumentOutOfRangeException("waitUntil_", "The supplied date is invalid.");

    return Until(waitUntil);
  }
}

Let’s take a second to examine this class.  As you can see, we are defining overloaded versions of the Wait and For methods allowing us to supply a specific DateTime or TimeSpan or a string that can be parsed into the appropriate structure.  By overloading the two key methods to allow strings we can make our interface more natural and easier to read.  Each method first performs some validation logic then returns a WaitContext that defines how long we are going to wait before executing a given block of code.  Let’s take a look at WaitContext so we can complete the full picture of how this is all going to work:

public class WaitContext
{
  internal WaitContext(DateTime waitUntil_)
  {
    _waitUntil = waitUntil_;
  }

  internal WaitContext(TimeSpan waitFor_)
  {
    _waitFor = waitFor_;
  }

  private DateTime? _waitUntil;
  private TimeSpan? _waitFor;

  public void Then(Action toDo_)
  {
    if (toDo_ == null)
        throw new ArgumentNullException("toDo_");

    ThreadPool.QueueUserWorkItem(new WaitCallback(
        new Action<object>(o =>
            {
                Thread.Sleep(
                    _waitUntil.HasValue ?
                    _waitUntil.Value.Subtract(DateTime.Now) : _waitFor.Value);

                toDo_();
            })));
  }
}

The WaitContext can only be initialized within the Wait class defined earlier with a DateTime or TimeSpan structure.  The Then method is the one that actually does all of the heavy lifting.  After checking that the provided Action delegate is valid we then spin up a new thread.  Within the thread we’re going to wait for or until the specified time then invoke the provided delegate.  Since we’re potentially working with multiple threads here be sure to make the delegate that you provide thread-safe.  If you’d like, it would be pretty simple to include some sort of callback mechanism within the delegate that you provide. 

That’s pretty much all there is to it.  Keep in mind that there is no one tool for every situation.  Fluent interfaces just seemed to be a particularly good fit this time around.  I’d like to add some additional functionality in the near future that would allow me to continuously invoke the delegate at a given interval.  I don’t need that right now but I’ll probably add it later.

This source code is free to modify and use for whatever purpose.  All that I ask is that you give a little credit where credit is due and let me know how you’re using it.

Happy hacking!

Twitter is a wildly popular social networking service that allows users to share what they’re up to, in 140 characters or less, by posting “tweets”.  I have been using Twitter for years and find it to be not only addictive, but a great way to keep updated on what those in my social circle are working on in an unobtrusive fashion.  I wondered if it would be possible to leverage this platform to allow my applications to share their status in an equally unobtrusive way.  Fortunately, Twitter exposes almost all of it’s functionality through an easy-to-use REST-ful API.

Originally, I thought that I would roll my own logging framework to support this new model, however, I eventually decided agasint reinventing the wheel.  I have been using Log4Net, a .NET port of the popular Java Log4J platform, for years.  Log4Net is not only incredibly flexible, allowing you to customize nearly every facet of your logging strategy via XML configuration, but it is also very extensible.  The Log4Net platform uses “appenders” to post logging events to a variety of destinations, including databases, files and even e-mail recipients.  Fortunately, Log4Net makes it simple to create your own custom appenders.

Log4Net recommends that when building a custom appender, you inherit from the abstract AppenderSkeleton class, located within the log4net.Appender namespace.  The AppenderSkeleton class exposes some useful functionality via protected methods and requires that your custom appender override the abstract Append method.  This method is the primary entry point for the Log4Net platform and is where you should implement your custom logic for handling a Log4Net event, represented internally by the LoggingEvent class.

I’ve posted the code for my TwitterAppender class below.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Text;
using System.Web;

using log4net.Appender;
using log4net.Core;

namespace TwitterAppender
{
public class TwitterAppender : AppenderSkeleton
{
#region Private Members

private const string REQUEST_CONTENT_TYPE = "application/x-www-form-urlencoded";
private const string REQUEST_METHOD = "POST";

// The source attribute has been removed from the Twitter API,
// unless you're using OAuth.
// Even if you are using OAuth, there's still an approval process.
// Not worth it; "API" will work for now!
// private const string TWITTER_SOURCE_NAME = "Log4Net";

private const string TWITTER_UPDATE_URL_FORMAT = "http://twitter.com/statuses/update.xml?status={0}";

private string _twitterUserName;
private string _twitterPassword;

/// <summary>
/// This is where we're posting the actual event as a tweet.
/// I was originally thinking of using REST-ful WCF, but, to keep things simple
/// and to reduce dependencies on other technologies, I decided to keep it simple.
/// </summary>
/// <param name="eventToPost_">The event to post.</param>
private void PostLoggingEvent(LoggingEvent eventToPost_)
{
// The base RenderLoggingEvent method converts the event to a string
// based on the layout specified in the configuration file.
// It's important to encode the tweet so that the request URL remains valid.

var updateRequest = HttpWebRequest.Create(String.Format(TWITTER_UPDATE_URL_FORMAT,
HttpUtility.UrlEncode(RenderLoggingEvent(eventToPost_).ToTweet()))) as HttpWebRequest;

updateRequest.ContentLength = 0;
updateRequest.ContentType = REQUEST_CONTENT_TYPE;
updateRequest.Credentials = new NetworkCredential(TwitterUserName, TwitterPassword);
updateRequest.Method = REQUEST_METHOD;

// This is in idiosyncracy with the Twitter API.
updateRequest.ServicePoint.Expect100Continue = true;

var updateResponse = updateRequest.GetResponse() as HttpWebResponse;

if (updateResponse.StatusCode != HttpStatusCode.OK && updateResponse.StatusCode != HttpStatusCode.Continue)
throw new ApplicationException(String.Format("An error occured while invoking the Twitter REST API [Response Code: {0}]; unable to proceed.", updateResponse.StatusCode));
}

#endregion

#region Public Members

/// <summary>
/// This is the password for the Twitter account that is to be used.
/// Fortunately, the Log4Net framework automatically populates
/// this property for us based on the configuration.
/// </summary>
public string TwitterPassword
{
get
{
// We need a password.
if (String.IsNullOrEmpty(_twitterPassword))
throw new ApplicationException("Twitter account password not specified; unable to proceed.");

return _twitterPassword;
}
set
{
_twitterPassword = value;
}
}

/// <summary>
/// This is the user name for the Twitter account that is to be used.
/// Fortunately, the Log4Net framework automatically populates
/// this property for us based on the configuration.
/// </summary>
public string TwitterUserName
{
get
{
// We need a user name.
if (String.IsNullOrEmpty(_twitterUserName))
throw new ApplicationException("Twitter account user name not specified; unable to proceed.");

return _twitterUserName;
}
set
{
_twitterUserName = value;
}
}

#endregion

#region Protected Members

/// <summary>
/// This is the main entry point for the Log4Net framework.
/// </summary>
/// <param name="loggingEvent_">The event to append.</param>
protected override void Append(LoggingEvent loggingEvent_)
{
try
{
if (loggingEvent_ == null)
throw new ArgumentNullException("loggingEvent_");

PostLoggingEvent(loggingEvent_);
}
catch (Exception ex_)
{
// Since we're already inside the event logging framework,
// let Log4Net handle this one.
// We don't want to get stuck in a loop!
ErrorHandler.Error("An error occured while posting the provided event; unable to proceed.", ex_);
}
}

#endregion
}
}

Line 44 of the above code uses the custom ToTweet extension method that chops the output of the RenderLoggingEvent to 140 characters (the maximum allowable length for a tweet) and adds an ellipsis if necessary. That extension method is provided below.

private const int MAXIMUM_TWEET_LENGTH = 140;

public static string ToTweet(this string fromString_)
{
if (fromString_ == null || fromString_.Length < MAXIMUM_TWEET_LENGTH)
return fromString_;

return (fromString_.Substring(0, MAXIMUM_TWEET_LENGTH - 3) + "...");
}

Configuring the appender is also pretty straight-forward. I won’t go into all of the details of Log4Net configuration, but, if you do need more information, take a look at the configuration documentation. My configuration is posted below.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
</configSections>

<log4net>
<appender name="TwitterAppender" type="TwitterAppender.TwitterAppender, TwitterAppender">
<!-- This property will be automatically populated by the Log4Net framework. -->
<twitterUserName value="yourTwitterUserName" />
<!-- This property will be automatically populated by the Log4Net framework. -->
<twitterPassword value="yourTwitterPassword" />
<!--
The layout pattern specified here is used by the RenderLoggingEvent method of
the base AppenderSkeleton class.  This element is optional.
-->
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="#%level - %message" />
</layout>
</appender>
<root>
<level value="ALL" />
<appender-ref ref="TwitterAppender" />
</root>
</log4net>

</configuration>

That’s pretty much all there is to it. This class has made my life so much simpler. Instead of checking the application log thirty times a day or having to set up special filtering rules in Outlook (I already don’t care for the Outlook client as it is), I can keep an eye on basically all of my applications in TweetDeck. The cool thing is that since Twitter is so ubiquitous, you can receive notifications on practically any desktop or mobile platform, including the iPhone. The solution itself is only limited in scale by the underlying Twitter service.

I, personally, set up an account for each of the applications that I’m monitoring. I would also highly recommend that you protect your tweets, so that the internal workings of your applications aren’t visible to everyone.

I realize that some may consider it a security risk to expose your application events to a public service like Twitter. It’s a good idea to keep these updates short and to the point in order to not expose too much information. I usually combine this method with a more detailed and secure database or file-based solution, using Twitter as a basic notification platform. Log4Net makes it simple to configure this type of model.

Something I just realized a few days ago is that by channeling your events through a Twitter account, you automatically get an RSS feed as well. Each Twitter account exposes status updates through an RSS feed. I don’t personally use this functionality, but there are certainly situations where it could be handy.

I mentioned before that I use TweetDeck. You can set up “search columns” within TweetDeck (which is now available on the iPhone), to organize your applications events by severity, source, type or pretty much anything else you want. I find this to be tremendously helpful. I’m not sure which other Twitter clients support this functionality, but I’m sure there are a handful out there.

For more information on using Log4Net, I recommend that you check out this excellent tutorial on beefycode.com. The official Log4Net documentation from Apache can get a little dry, so I recommend that you start here if you want to get up and running quickly.

I look forward to hearing your feedback.

UPDATE: TwitterAppender is now available on CodePlex at http://twitterappender.codeplex.com.  Enjoy!

I am a proponent of the underscore.  There, I said it.  The use of the underscore is a polarizing topic in most software development circles, with both sides often citing arbitrary arguments for or against its use.  I, personally, have finally had enough.  Today, I am presenting my defense of the underscore in a public forum and oficially inviting you, the reader, to reply with your argument for or against its use.  The only thing that I ask is that you be objective (I don’t want to hear “it’s ugly”, “you shouldn’t do it” or “it’s bad practice”) and that you present it here, publicly, for all to read.

As with any development convention, I only use the underscore under a very specific set of conditions.  As a matter of fact, I only use it under two very specific conditions: prefixed to a private member variable or postfixed to a function argument.  But, why do I use it?  Do I use it because I think that it looks nice?  No.  Do I use it because other people use it?  No.  This is why I use it:

• By prefixing all private member variables with underscores, you are automatically creating a valuable shortcut.  Now, whenever you enter the underscore character anywhere within the class, Intellisense will automatically provide you with a list of all private member variables within scope.  Tell me that’s a bad thing.
• A quick review of the class reveals all function arguments and private member variables.  While reading a block of code, I can quickly identify the nature of any variable without having to use the tooltip.  Why is this important?  Being able to quickly identify the nature of these variables makes code, in my opinion, more readable and easier to debug.  I can already hear you crying, “Well, if you’re going that far, why don’t you just use Hungarian notation?”  With Hungarian notation, I have to decode the first three characters of each variable to glean its type.  Since this notation seems to vary in convention from developer to developer, it tends to make code less readable.  The underscore doesn’t attempt to share this much information, making it simpler and less ambiguous.
• Although the introduction of automatic properties in C# 3.0 has certainly made life easier, there are still times when traditional properties are necessary.  More often than not, these traditional properties implement some type of private backing variable.  Naturally, this backing variable typically shares the same name with the property itself.  Since C# is case-sensitive, technically this doesn’t present a problem.  However,  if you slip up and don’t enter the name of the backing variable or property using the exact casing, Intellisense will guess for you and it doesn’t always guess correctly.  This can cause a compile-time error, or, more likely, a more painful runtime error.  Yes, I know, you can always give the member variable a different name, but this often forces you to come up with an arbitrary name in order to compile, making your code even less readable.  By prefixing the backing variable with an underscore, you can kill two birds with one stone.  I find this to be a rather graceful solution in most cases.

Now, it’s your turn.  Do you agree with me?  Fantastic.  Do you disagree with me?  Fair enough.  Tell me why you disagree with me.  Remember, be objective.  Don’t tell me that it’s ugly and don’t tell me that it’s bad practice without justifying your position.  If you do, however, have a valid, objective argument against its use, please share.

In order to compile the application, you’re going to need to grab the FluidKit API and have the .NET Framework 3.5 SP1 installed.  If you want to create your own custom questions (answers?), you can do so by modifying the GameCategories.xml file, provided with the project.  I think the schema is pretty self-explanatory, but if you do have any questions, feel free to hit me up via e-mail at casey[dot]watson[at]improvingenterprises[dot]com or, preferably, send me a Twitter DM at @_caseywatson.

I had a great time this year at Dallas TechFest and I hope that you did as well.

I want to extend a special thanks to Improving Enterprises (http://www.improvingenterprises.com) who generously provided some great prizes for our C# Jeopardy session.  For those of you that didn’t get a chance to attend, each contestant left with either a $5 Starbucks gift card or a $50 Amazon gift card, all courtesy of Improving.

Finally, I have to thank Tim Rayburn (http://www.timrayburn.net) who put on this incredible event.  Great job, Tim.

I’ll see you all next year.

More to come soon…

This isn’t really easy to do, so I’m just going to come out and say it. I think we should break up.

First off, it’s not you, it’s me. I mean, I’m the one who wants a reliable, easy-to-use source control system. In a lot of ways you’re a lot better than my last source control system. I mean, in some ways, you’re great at communicating. It’s nice to know that my code builds every time that I check it in. In some ways, however, you’re a little much. It seems like there’s always conflicts to resolve. At first, when things were simpler, you would always give me a hand in resolving these conflicts, but, now that things are a little more complicated, it seems like you don’t want to help at all. I feel like I’m constantly resolving these conflicts all by myself. So, thanks for that.

Also, you never listen to me anymore. When I’m trying to check something in and you and I have a conflict, once it’s resolved, I still want to check it in. Do you honestly think I’ve changed my mind? Why would I change my mind? I feel like you always want me to go that extra mile even when you know exactly what I’m trying to do. Are you purposefully trying to make my life difficult? Sometimes it feels like it. The last source control system that I used never did that. I only had to say things once. It seems like you don’t really care. I mean, when I ask you for the latest version of my code, you often refuse to give it to me just because you think that I already have it. Well, you’ve given it to me before, I must still have it, right? Do you even bother to check? No, no, no. I have to ask just the right way to get what I want or you refuse to budge.

Sometimes I just want to check in some code. I could live without the nagging.

“Why are you checking this in? Which task is this associated with? Blah, blah, blah.” You know what? Can we just skip the conversation every once in a while and get to the point? Again, I feel like you’re doing it on purpose.

I’m really sorry that it’s ending this way, TFS. I never really expected it to come to this. All of my friends told me that you were the best and I believed them, but, I just feel like it’s too much work and I’m not really getting anything out of this relationship. I’d appreciate it if you’d stop by and pick up your stuff from my laptop. It’s taking up a lot of space and I really don’t have any use for it. Also, I think you still have some of my code. I can pick it up from you or you can just drop it off. Either way, let’s try to be civil about this.

I was thinking maybe I would make one last check in, but I think it’s best if we just make a clean break. I’ll never forget about you, TFS, and I know that there’s some masochistic, self-hating developer out there that would love to be with a source control system like yourself, but I’m afraid that’s not me. I guess I’ve seen this coming for a while, but I didn’t really want to accept it. Project after project, I’ve tried to look past these problems, but I think it’s time that we both just admit that this isn’t going to work anymore.

I’m sorry,
Casey.

PS: What’s your friend Subversion up to this weekend? I’m just asking because a friend wants to know, but, I mean, if you’re not comfortable with it, just let me know. Can you give me her e-mail address, though? I’d like to give it to my friend so he can… You know what? Nevermind. It’s too soon.

One thing that I’ve noticed recently is that everyone wants to “be agile”, but very few people actually understand what it means. To most people, agile is nothing more than a buzzword. They understand that it can potentially deliver value and that everyone’s doing it but, beyond that, they really don’t have a clue. Just check out this video from my pal Caleb Jenkins to get an idea of what I’m talking about.

There’s another group that believes that agility equates to a specific method, such as Scrum. While I’m certainly not bad-mouthing Scrum (I’ve seen the value that it can deliver firsthand) or any other method, I don’t believe that agility can be directly attributed to any one practice. These methods can help to set you down the right path, but in reality they’re just tools. That isn’t to say that they’re not valuable tools, but agility is, for the lack of a better term, a lifestyle. I think that may be why, initially, it’s so hard to fully grasp.

The funny thing is, you never really get there, because there is no definite “there”.  Agility is not a destination, but a journey. The biggest part is simply coming to the realization that most aspects of any development project, be it requirements, human resources, schedules… are constantly changing. That’s reality and there’s not much that you can do about it. All that you can do is learn to accept it. Once you accept it, and even welcome it, you’re in the right frame of mind. You can begin to actively prepare for and respond to this reality and that is what makes you agile.

In my opinion, agility is simply the ability to react appropriately to reality. That’s a rather broad definition, but rightly so. If you’re practicing the classic waterfall method and you find that your requirements are in a constant state of flux and that you’re always trying to “hit a moving target”, then you’re not reacting appropriately to reality, are you? On a more broad level, if you keep doing the same thing over and over again expecting different results each time, you’re not being agile.  The funny thing is that, with experience, this is common sense.  The problem is that we’ve been conditioned our entire career to think to the contrary.  There is no magic recipe for agility since agility depends on your context.

So, what do you think? Do you agree with me? Great. Do you disagree with me? Even better… tell me why so we can strike up a conversation.