I’ve finally moved my blog, casey.in.point, from the protective umbrella of wordpress.com to my own server. From here on out, you can read my blog at www.caseywatson.com. I will not continue to make posts to this blog, but I am going to leave it up for those that wish to redirect.

See you there,
Casey.

More to come soon…

Generate your own iconic image free @ http://tinyurl.com/6tc7us. Good stuff.

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:

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.

It's alright... nothing special.

Now, there’s nothing actually wrong with this block of code. Well, there’s nothing wrong with it beside the fact that the name of my structure is Foo and that the exception that I’m throwing is especially abrasive. Of course, this is just demonstration code that I’m using to illustrate my point. Okay, back to the subject. The problem with this code is that it’s used verbatim repeatedly throughout my class. Again, there’s nothing especially wrong with that seeing as is this is an especially simple condition, but it does technically break the before-mentioned DRY principle, if ever so slightly. It can be improved upon, and, you know, that’s what I do. It’s in my employment contract.

So, how do we improve it? If you were to verbalize the condition, it becomes obvious. “If the list in question is null or empty, then it’s time to bail.” Did you catch that? There’s a little nugget in that last statement that in and of itself suggests a rather graceful solution in which to dry this code out a bit. Try reading it again if you didn’t catch it the first time.

“If the list in question is null or empty…” Sound familiar? It should. The static IsNullOrEmpty method is one of my favorite tools and provides a rather graceful solution to testing whether or not a string is null or empty, a common condition used in blocking statements. So how can we apply this to our current situation? Through extension methods, of course! This one is simple:

All the cool kids are using them.

So, there’s actually three pluses here. First and foremost, we’ve condensed this condition, used many times within my own class and presumably many times throughout the application, into a cute, reusable extension method. More importantly, this cute little extension method is generic, meaning that you can use it with any object that implements IList<T>, and God knows you probably have plenty of those.  Secondly, the method is named in a way which will be easy to remember, since we use it all the time when testing strings. And thirdly, extension methods are just plain cool.

So, without further ado, our finished product:

Blocking Statement Part Deux

Looking back, this is actually a very minor change, but, you know, when combined with a growing collection of other minor changes, it can lead to major improvements in the readability and consistency of your code, and that’s always a good thing. If you combine all of these little nuggets of reusability into a handy class library, then you can stay DRY wherever you go… or code.

Happy Refactoring, everbody!

As promised last night, I’ve posted my source code for download here.  Feel free to do with the code what you wish; the only thing that I ask is that you let me know how you’re using it.  There are a few modifications that I was planning on making to it that I didn’t get a chance to wrap up before last night’s meeting including video answers and a couple of improvements to the way that I’m using transitions in FluidKit.  If you want to create your own game of Jeopardy for a meeting or a company party, you can edit the GameCategories.xml file to customize your own game categories and answers.  

In order to build the code, you will need to install .NET Framework SP1 and the FluidKit library.  FluidKit is open source and available on CodePlex.  I have also included, along with the source code, the “Gyparody” font that I used for both the title screen and the answer tiles.

Again, thanks to all that attended and I look forward to seeing all of you at future SIG meetings.

Join us this Thursday, December 4th at the Microsoft offices in Las Colinas to be a contestant on the premier .NET-related game show, C# Jeopardy!  I will be standing in for Alex Trebek and putting your collective .NET knowledge to the test.  If that’s not enough to pique your interest, we’ll also have some fabulous door prizes, free pizza and drinks.  

The session will feature an interactive game board that uses some of the latest and greatest Microsoft technologies including WPF, FluidKit and LINQ-to-XML.  I’m planning on dedicating at least the first half of the night to the game, then, if we have any time left, I plan on walking through the game board code a bit and answering any questions.

For additional details, check out the SIG web site at http://www.dallas-csharp-sig.com/, and please, BRING A FRIEND OR FIVE!

As promised, I am posting my presentation, with notes, as well as the demonstration solution from my talk this morning.

In order to build the solution, you will need the latest version of Rhino Mocks.  I am using the MS Test framework, but feel free to use the testing framework that you are most comfortable with.  If you’re new to unit testing and do not have access to MS Test, I’d suggest NUnit; the syntax is very similar and any modifications should be pretty trivial.  If you have any problems, please feel free to give me a shout.

Again, thank you for attending and I hope that you find these materials useful.  Happy mocking!

New logo... I dig it.

Let me know what you think.  Do you like this one more?  Did you like the other better?  Do you not really care?  Do you wish that you weren’t reading a blog post about a logo?  Well, that’s tough.  You’re already finished.