Let me start off by saying that I’m no good at making resolutions for an entire year.  I mean, that’s 365 days that I have stay committed to a list I drafted in about five minutes at the end of the previous year.  The whole process feels so arbitrary and failure-prone…

So I went with a different tactic.  I renamed mine to “goals”, and spent a goodly amount of time on them… in the tens of minutes, at least.  Completely different animal.  And I figure what better way to keep them enforced than to make them public.  So here they are, in order of priority:

  1. Blog more.  I honestly want to do more of this.  I enjoy writing; it’s my second-guessing (both on topics and syntax) that slows me down more than anything else.  I think that’s one of those problems that only gets minimized through continual practice.  I figure I should get myself to an average frequency of one post per week this year.
  2. Do more public speaking.  It’s something I’ve only done a handful of times, and loved every minute.  I’m going to find ways to do more of this.  My goal is five presentations – in whatever forum I can get, I’m not choosy – for the year.
  3. Dive head-first into at least three things I barely know.  Sometimes the only way to learn something… to really learn it… is by doing it.  This could just be by implementing small pilot projects at home, participating in something community-driven, or even something at work.  My target list for now * includes:
    1. Domain Driven Design
    2. Behavior Driven Development
    3. ASP.NET MVC
    4. F#/Functional Programming
  4. Read at least two technical books.  I’ve seriously neglected the whole book-reading thing (in terms of growing my developer skills); staying mostly with material I can find online and in ebooks.  In 2009, I’m going to get some highly recommended real books and take the time to read them.  (However, I’m staying away from technology-specific books; I’m more interested in concepts and methodologies than in new skillsets).

* I reserve the right to capriciously change my head-first list at any time.

It’s a short list for now, but it’s enough to keep me motivated.  Most likely I’ll be editing this as time goes on.

Technorati Tags:
Advertisements

Adobe AIR has it.  Mono’s Moonlight has it.  Silverlight doesn’t… at least not yet, depending on what you read.  I’m talking about the standalone host container that allows Rich Internet Applications (RIAs) to live outside the browser.  A Silverlight player that can run applications on the desktop as first class citizens.  There’s even a term for it: “Fit Client” (although I’m not sure if that will stick… I don’t even see it on Wikipedia, for goodness sake; but it’s a bit easier to say than “desktop RIA”, so I’m using it until such time as it becomes completely invalidated).

I’ve been using TweetDeck so much lately that it’s got me wondering a lot why Silverlight doesn’t yet have a desktop container.  I like the idea of having RIAs on my desktop (and yes, I am an unabashed fan of Vista Sidebar, which allows me to actually enjoy my desktop).

So I started searching the tubes for anything I could find on whether or not there actually was a Silverlight container.  Maybe it was out there but I just hadn’t seen it yet; but if there wasn’t anything, and no plans for it in v3, then I wanted to find out why. 

All I was able to find, however, was a scripting solution that allowed you to run Silverlight apps on a Windows-only platform, hosting them inside HTML applicationsIf you want to know more about that, you can find a detailed solution here: Silverlight: Running standalone full trust applications.  (Caveat: the post uses SL 2 Beta 1, as near as I can tell; I had to do some minor tweaking to get it to run against SL 2 RTM).

I concluded that there was no real Silverlight fit client out there, nor was there one on the horizon, and I began laying out a list of wild, uninformed speculations about its absence for this post.  And I almost posted it last night; I’m glad I didn’t, partly because it was turning into a minor rant, and also because I finally found what I was looking for once I started searching for new features in Silverlight 3.

It now appears that Silverlight might actually have a fit client platform in version 3.  This means that you will be able to build desktop applications directly in Silverlight, and they will [theoretically] run on any OS.  If it’s true, then it’s a very, very good thing.  You can find this info among the list of other upcoming Silverlight 3 features at Bart Czernicki’s Silverlight Hack.  His source for the fit client material came from an InsideRIA post by Richard Monson-Haefel, which goes into more detail on the RIA wars happening under our very noses.  And that post is using a NYT article as its source (hmm, starts to feel just a little like “a guy who knows a guy who knows a guy who said something about Silverlight…”)  Richard states about the NYT item:

Sound familiar?  What the NYT is saying is that Microsoft has plans to create a Silverlight runtime outside the browser similar to Adobe AIR, JWT, Gears, or Curl. That means developers will be able to create Silverlight applications that run right off the desktop – any desktop. This is what we call a "Fit Client" solution – a RIA platform that works both in the browser and out of it.

I’m a little concerned, however, that I had to scour for as long as I did before I found this information.  My take on it is that most of this is prediction; but I’m also expecting this to get cleared up at Mix09, when there should be some formal announcement about Silverlight 3’s feature set.  Until then, I plan on following this topic for as long as I can.

Technorati Tags: ,,

A few weeks back I was at an ArcReady event given by Phil Wheat which focused mainly on soft skills for developers.  I like technology a lot, and I love my profession as a software developer, but being a code ninja without interacting with humans is pretty rare these days. 

Phil’s presentation was filled with useful advice, but the one topic that stuck out for me the most was mentoring.  I believe that all developers could benefit from having mentors, but you just don’t see much of it in the wild.  (Well, your experiences may vary, but I personally haven’t seen much of it.)

I’ve been thinking a lot about mentoring, and synthesizing some of Phil’s comments with my own requirements and goals.  I see mentoring as a two-way street: if you are serious about having someone to learn from, then you should reciprocate whenever you get a chance.  So, get a mentor, but also be willing to be a mentor.  So here’s my rough list of what I think that should entail:

  • Get a mentor. 
    • Pick someone that you respect and open up a dialog.  This doesn’t have to be some sort of awkward, platonic variant on a promise ring exchange or anything like that.  Just ask questions, gain knowledge, that’s about it.
    • Look for someone who challenges you and shows you respect.  There are a lot of people out there who are brilliant but just don’t make good mentors because they lack “people skills”, or have larger than life egos.  Do not expect those people to make very good mentors.  A mentor should test your limits and challenge what you think you know, but not in a overly negative or discouraging way.  Put another way, they are not drill sergeants.
    • It should not be someone on your team or anyone you work directly with.  This came from Phil’s presentation, and actually caught me by surprise.  But the more I think about it, the more sense it makes.  You need to have uncompromised communication with your mentor, and that’s just not always possible with someone on your team, or your manager, etc.
  • Be a mentor.
    • Be open to the idea of helping those around you.  If you’re an alpha geek, this shouldn’t be hard since you should be used to answering a lot of questions already.  (And, btw, what are you doing reading this blog? 😉 )  If you’re not, or don’t consider yourself one, just teach what you know.  If you’ve been doing any serious development for the past few years, you do have knowledge that can help someone else.
    • Advocate the learning process, not just the skill.  Given enough time, anyone can learn anything (notice I didn’t say “…master anything”).  Maybe you’re a code ninja now, but at some point you weren’t; developers looking for a mentor want guidance and want to learn from your experience, not to hear how you did some wicked refactoring over the weekend.
    • Be patient with anyone who is actively trying to learn.  I hate to harp on this one point, but I feel it’s worth repeating: I’ve seen scary-smart developers who were also just the worst people in the world to learn from.  And that’s okay, not everyone needs to be a teacher.  But if you really want to educate those around you and you’re finding that you’re impatient, please find a way to work on that.  Your knowledge is important, and you can make a difference to another developer.

That’s all that I can put down now; I’m hoping to refine this list a bit better over time.  Maybe when I get a chance to actually mentor someone myself.

Technorati Tags:

Refactoring, rewriting existing code to make it as small, efficient, and ultimately as testable as possible, is something of a double-edged sword.  In the Test-Driven world, it’s an absolute necessity.  In the non-TDD world, however, it becomes a potentially very dangerous activity that can make things worse off than where you started.

If Only I Knew Then…

Refactoring is something of a hindsight practice.  It’s like traveling back in time with the knowledge you have of the present, and seeking to “set things right” with the code in question.

In TDD, you refactor all the time.  And that’s perfectly fine; in fact it’s expected.  You write tests and code for them, and armed with new insight, go back and tweak, rewrite, move around, and otherwise morph that code into something better.  Rinse, repeat.  And it’s a good thing – your tests, if you’ve written them well – will alert you if you break something.

I’ve Got Something On My Shoe…

But without unit tests, refactoring can very easily degenerate into an exercise in reckless time travel.  Yes, you are going back to make the code better… you can clearly see how this method here is bloated and/or redundant, so why not just take some stuff out, move it around, etc.?  It all looks fine, now let’s just hop in our time machine and get back to present-day.  By the way, what was that thing I just stepped on?…

It’s easy to squash a few butterflies when refactoring “blind”, so to speak.  You can’t really be sure the code you just modified will work, or work as expected, or worse yet… something totally new and unexpected will now crop up.  You’ve altered your entire environment, and you have no measures to tell you just how bad, or just plain different, things might be.  If that doesn’t scare you, it should (in a healthy, makes-you-a-better-programmer way, of course).

The Refactor Paradox

If you have the urge to refactor whenever you’re coding… that’s great.  It means you’re thinking about how to improve things, and that’s an excellent mindset to have.  But if you happen to be in an environment where you can’t unit test, or if you’re averse to testing, then tread a bit more carefully as you refactor.  You’re still writing new code, even though it’s often old code.  The act of altering it makes it new again, and even if you’re absolutely sure there’s no new logic there, it’s good just to assume it’s all brand new and that you don’t really know how it’s going to behave.

I have done my fair share of refactoring sans tests before, and I’ve learned my lessons the hard way.  These days I try to be a lot more careful.  If I refactor code that has never been tested before, I do my best to enforce a “no new code without unit tests” policy, and treat all that old code as brand new.

Technorati Tags: ,,

I was recently performing an ad hoc code review of a custom DLL when I saw what, in my opinion, was an over abundance of exceptions.  I went back to the developer and proceeded to discuss how we could refactor-away various exceptions, shorten certain Try/Catch blocks, possibly even mitigate them altogether, etc.

The developer, whom I consider to be a very smart and very patient man, listened earnestly and responded with what I felt was an excellent use of the Socratic Method:  “Hmm, but I thought that [in this one exception usage] we needed to let the caller know this particular item was incorrect.  Don’t we need to communicate something to them?”  (lots of paraphrasing)

“Communicate?”  Right away he had me seeing exceptions as part of the feedback loop, which I had forgotten in my zeal to optimize and refactor.  (We were in agreement on Try/Catch usage, by the way, which is generally to use sparingly with only the most critical lines of code.)

This started a great dialog between the two of us, and we eventually reached an alignment on exception usage in that instance.  I learned a lot from his viewpoint; and it also got me thinking more seriously about how exceptions are commonly used.

The Popeye Rule

I had typically written my own code with exception handling that followed what I loosely think of as “The Popeye Rule”:

That’s all I can stands and I can’t stands no more!

Meaning that I strived to write my code to be as robust as I could possibly make it, handling everything I thought a caller might possibly give me with guard clauses and graceful exits, finding every excuse I could think of to avoid Try/Catch blocks, etc.  I only wanted my code to ever throw an exception when something truly horrid and abnormal occurred and just couldn’t be handled any other way. 

(Super-extreme caveat: That does not mean I advocated, nor do I ever advocate, the intentional blind swallowing of exceptions.  I just didn’t like having code so brittle that it shattered into exceptions at the slightest fault).

“Let Me Tell You What Happened”

After talking with my colleague, I’m tending to not be so “ruggedly individualistic” with my views on how code should behave.  Instead of handling everything except for the very worst case/last-straw scenario and then throwing a spectacular, brawling exception (maybe tossing in some encoded GIFs of battleships firing their cannons into the stack trace), I want to give my caller information.  If something goes wrong, I need to let them know what happened and why.

I’ve done a lot of reading about how others feel about exception usage and so far the best overall guidelines I have found are Scott Hanselman’s here.  It’s a great short list that’s easy to follow.

Exceptions can seem like disruptions, even symptoms of brittle code or poor design; but this experience reminded me that their true purpose is to help by providing valuable feedback: “Something here went wrong.  Let me tell you what happened…[Stack Trace ensues]…”

Technorati Tags: ,,

Recently I was building an HttpModule project, and quickly ran into a serious problem: I couldn’t test my code.  The reason?  I was using objects that were unmockable.

The scenario involved passing an HttpContext object into my module so that I could manipulate certain properties.  What’s wrong with that?  Well, for starters HttpContext is sealed, along with every property attached to it that I needed.  My standard approach is to use Rhino Mocks, which has served me well in the past.  But here I hit a wall – or rather Rhino Mocks did.

Take a look at the snippet below, which demonstrates the problem.  I’m creating a very simple dynamic mock of HttpContext, and attempting to pass it to my interface (which accepts HttpContext – I’m omitting the interface here for brevity)…

[Test]
public void Should_Be_Mockable_But_Is_Not()
{
    HttpContext context = _repository.DynamicMock<HttpContext>(typeof (HttpContext), null);
    IMyModule module = new MyModule();
    module.ProcessRequest(context);
}

When I run this test, I get this unpleasant error:

TestCase 'MyTests.Should_Be_Mockable_But_Is_Not'
failed: System.NotSupportedException : Can't create mocks of sealed classes

Sealed?!  What is this nonsense?!  And then, the furrowing of my brow as my brain struggled to comprehend… “oh, right… ahem… sealed”.  Apparently one cannot just go right out and mock a sealed class these days.

But I didn’t want to change my object to make it more mockable; I needed that HttpContext object, or at the very least, another property on it which no doubt would also be sealed.  Rhino Mocks couldn’t deal with it; what could I do?

Enter Typemock Isolator

I had to do a lot of searching, but somehow I found my way past duck-typing (which I thought was interesting, but just too much work in this scenario) over to Typemock.  I didn’t really know it very well, other than it was yet-another-mock-framework.  But it did one thing Rhino Mocks didn’t do – it mocked sealed objects.  And that was enough to get my attention.

So how did I mock the unmockable with Typemock Isolator?  I used this forum thread as my guide, the basic gist of which is to initialize some MockObjects to the type that I want to mock, and use those as the initialization values for my real objects that I’ll pass in my tests.

The sample below shows a full setup and one test.

protected MockObject _mockHttpContext;
protected MockObject _mockRequest;
protected HttpContext _context;
protected HttpRequest _request;
 
[TestFixtureSetUp]
public void TestFixtureSetUp()
{
    MockManager.Init();
 
    // Create a mocked HttpContext object.
    _mockHttpContext = MockManager.MockObject(typeof (HttpContext), Constructor.Mocked);
    _context = _mockHttpContext.Object as HttpContext;
 
    // Create a mocked HttpRequest object.
    _mockRequest = MockManager.MockObject(typeof (HttpRequest), Constructor.Mocked);
    _request = _mockRequest.Object as HttpRequest;
 
    // Configure context to return a Request object.
    _mockHttpContext.ExpectGet("Request", _request, 1);
}
 
[Test]
public void Should_Definitely_Be_Mockable_Now()
{
    IMyModule module = new MyModule();
    module.ProcessRequest(_context);
}

Sounds great!  What’s the catch?

So Typemock can solve my unmockable problem for me.  Excellent.  But what’s the catch?  Rhino Mocks is free, Typemock Isolator is not.  This can make all the difference depending on budget, need, and other constraints.  For me in this situation, it’s well worth the price, though.

This may be one of those situations where I’m not supposed to be trying to test code that passes around sealed objects.  Or, maybe I could rewrite my code so that I’m getting what I need, but everything is testable without having to go outside Rhino.  I’m willing to concede that much.  But in this case, I’m keeping my module intact, but I’ve also got the testability I need.  So I’m happy.

Technorati Tags: ,,

I’ve been reading a lot interesting posts lately around Test-Driven Development adoption, or the lack thereof, the collective synopsis of which goes something like:

TDD is too difficult and cumbersome to gain widespread traction.  It needs to change if it is to get anymore mindshare among developers.

Roy Osherove makes a compelling argument that developers continue to shy away from TDD because of its apparent complexity, not just in learning unit testing, but also mocking and the idiosyncrasies of mock frameworks, and dealing with all the ancillary methodologies that get swept up in TDD’s wake (Dependency Injection, IoC, etc.).  And all of these concepts become (paraphrasing) a big barrier to entry for too many developers.

I agree that there is a lot of “stuff” to learn when wading into the waters of TDD, and just trying to take it all in can indeed be daunting for many.

But is it really just the learning curve?

I’ve been thinking a lot about the phenomenon of resistance from developers to TDD, and wondering if there isn’t more going on than just a steep learning curve.  No doubt, I’ve witnessed developer resistance firsthand, and yes… at one time I was not exactly sold on it myself. 

Fortunately, I’ve gotten to a place where I really like TDD.  Granted, I had the help of some extremely knowledgeable, supportive mentors who actively encouraged me to look for the benefits.  (Extra-strength caveat: I consider myself too new to TDD to be any kind of authority; I just appreciate its tenets and find myself happy enough exploring ways to incorporate Test-Driven practices into my daily coding life.)

But I have to say that the learning curve wasn’t what kept me away from TDD, and it hasn’t always been what I’ve heard from other developers.

The message to the developers

My perception is that Test-Driven Development has largely been promoted to developers as a very necessary evil: Yeah, there’s a lot to learn, but it’s good for you, so learn it.  Not everywhere, of course, and not by everyone I’ve ever heard speak about it.  But when the topic of TDD comes up the most common themes (or sometimes just the loudest voices) have been akin to…

"You need to be doing unit testing"

“And while you’re at it, you need to start writing your code so that it can be tested”

"You need to start mocking"

"And while you’re at it, you need to start designing your objects so that they can be mocked"

The intentions behind statements like these are actually well-meaning; the problem is not so much with the content but with the delivery.  Telling developers that they need to be applying some methodology, especially something completely new to them, implies that if they’re not doing so then… well, it’s a wonder how they’re getting anything done, or at least done correctly.  More often than not it creates resistance to the very thing they should be embracing.  And whenever someone is resistant to your message then invariably part, if not all, of it will get lost.

In my experience, the learning curve as a factor in low TDD uptake among developers might have been the most common excuse, but not necessarily the most accurate explanation.  The reality for me is that if TDD has a negative connotation it is mainly because too many times developers were told that they couldn’t be writing solid code without it.  And with that kind of association, a learning curve of any slope at all is going to be an easy target for avoidance.

Showing the positives

The best way I know to sell a methodology like TDD is to show how it can make things better.  I was shown time and time again how unit tests worked, and I always came back to the question of “now… why am I doing this again?”  Then one day I had refactored a huge chunk of code and, feeling very sure of myself that I hadn’t broken anything, ran my (all passing) tests only to discover “what the… a failure?!  No way!”  Sure enough, I had inadvertently introduced a bug that probably would have snuck all the way into QA had I not run those tests.  Thank you, Unit Tests!

I wasn’t drawn to unit testing until I could see for myself what no one else was really showing me: it helped me with my code.  My tests had sniffed out bugs that I had clearly missed… that I wouldn’t really even had thought to look for… and they did it within seconds.  I had to experience the benefit; only then did the methodology make sense.  From that point on, I enjoyed writing tests. 

Rather than asking TDD to change so more developers will appreciate and adopt it, I’d like to see TDD shown more for what it’s goals are: to make the code, and ultimately the deliverables, better.  (Not just different, because different by itself doesn’t mean anything.)  Emphasize the benefits that naturally manifest from Test-Driven practices (more robust code, fewer defects, etc.) and then negotiate the learning curve.

What has been your experience with Test-Driven Development, and how have you perceived its promotion within the community?  If you are already using TDD, how did you get there?  By mandate, desire, or accident?  Were there any problems along the way?  And if you are resistant to TDD, where is that resistance rooted?