Code From Within

Letting Go Of Regions

noreply@blogger.com (R. Eric Geiger) — Tue, 10 Feb 2009 04:52:00 +0000

I’ve stopped using regions in my code. And, to be honest, I’ve never looked back. I don’t need them, don’t even miss them. In fact, the more I go on coding without attempting to group my methods, properties, etc., into sections of magically collapsible text, the more convinced I am that regions are unnecessary.

Requisite Caveats: Before I go too far, let me clarify: I’m talking about regions in user-generated code. My concern is really about developers making decisions about how they organize their own code for purposes of readability.

And yes, I’ve used them in the past – repeatedly – in the manners listed below.

They Distract From Refactoring

I look at regions as pseudo-refactoring tools. All too often, their usage is the result of logic like “Hmm, this file is pretty big and unwieldy... I know, I can use regions to get it under control.” Leading to what I consider the fallacy of thinking that by condensing code inside the editor, we’ve made it more manageable. When in fact, we haven’t done anything.

Big files are blazing neon red flags that real refactoring opportunities are at hand. Using regions, however, can trick some developers into thinking that n-thousand lines of code in a single file is really maintainable, because well, see, we’ve got them all organized into nicely labeled areas. They’re a distraction from the real work that needs to be done.

Regions don’t make the file smaller, but they can mislead you into thinking this much code is maintainable.

Personally, I feel that when a file is growing to about 300 or more lines, something is amiss. Whether it’s something like an SRP violation, a lack of optimization, or just that’s it becoming the “miscellaneous” file, a big class usually means big trouble. I’m happy with small. Small is readable; it’s maintainable; it typically doesn’t need regions to stay organized.

They Conceal Surprises And “Ugly” Code

Regions can be, and often are, used to hide ugly and/or mysterious code. The really scary stuff (general cruft, old commented-out lines, or my personal favorite… the “surprise!” code that tends to throw reviewers for a loop) that you know you don’t ever want to see again. And maybe that you don’t want anyone else to see, either.

I’m of the belief that ugly code should never be hidden. You don’t want a “people under the stairs” scenario; that stuff will fester, rot, and mutate… and it will always come back to haunt you. It has to be exposed; literally dragged out into the center of your editor, kicking, writhing, and screaming, so that it can be healed and cared for.

Regions can cleverly disguise code that’s loaded with surprises. Or, at least not what you’d expect when you read their captions…

…and then expand them out to find, well, hopefully something good.

Make Your Code Readable

Readability has nothing to do with regions, in my opinion. It has everything to do with making your code sensible, logical, and straightforward.

The best way to keep your code organized is to think critically about what you’re writing. Don’t rely on editor shortcuts; they can become very addictive habits that are hard to break free from. I put regions in this category; they trick you into thinking you’ve made your code more readable, but in reality you’ve done very little. Far worse, you’ve inadvertently hidden stuff that other developers may need to see one day.

What do you think? Let me know if you still use regions. Do you consider them necessary? And, if so, where have they helped you the most?

What Is “Community” To You?

noreply@blogger.com (R. Eric Geiger) — Tue, 27 Jan 2009 05:33:00 +0000

A question for all the developers out there: What is “community” to you?

I thought about that question, and my own answer, after attending the the January Houston ALT.NET Geek Dinner. To me, ALT.NET is about fostering the developer community, but I know not everyone sees it that way. This got me wondering about how developers define the term for themselves.

All I know about the developer community, to be perfectly honest, is what I’ve conjured up in my head. So the rest of this post… and consider this fair warning… is nothing more than my perception, and probably a distorted one at that.

It’s a necessity

Developers need… in fact, crave community. The stereotype of the geek who doesn’t talk to anyone, stays in their cube or office all day, only comes out for coffee or a [mandatory] meeting, and generally is unable to communicate very well with other bipedal organisms… I refuse to perpetuate it. I’m not sure how that image got started, or how the connection between “writing software” and “being socially isolated” got made, but I cannot subscribe to it. And moreover, I think most serious developers… who care deeply about their profession… feel the same way.

Rather than solitary and isolating, I choose to see software development as a social experience. And not because there is the potential to have what we write end up in the hands of other people; some of whom are going to give us feedback, wanted or otherwise. It’s actually because of the developer user groups, events, and conferences. I find it amazing that all these fundamentally social gatherings, focused in one way or another on development, even exist. I see them as natural manifestations… as proof, really… of the need for developers to connect and exchange information.

It’s a social fabric

The developer community is a hodge-podge at best. It’s not just a single group that, say, meets once per quarter and proclaims “Yep, we’re pretty much it”. It’s an amalgam of individuals, groups, and entities. It’s a chorus of voices, via blogs, tweets, speaking engagements, magazines, coworkers and colleagues, that all work to shape and expand our craft. They all do this in different ways, of course, but the net effect is the same.

I enjoy reading lots of blogs (and I would say “books”, but I’ve been unintentionally remiss on book-reading), attending conferences, going to HDNUG meetings, and just about anything else that allows me to meet and hear other developers. Reading blogs is critical, in my opinion; so much so that I consider it a bare minimum for community involvement. I have a long list of feeds and I make use of a good RSS aggregator (I’ve been extremely loyal, or maybe just too lazy to change from, Newsgator). Confession: There are podcasts and vidcasts that I’d like to really digest, but I have a difficult time getting into continuous, heavy AV use. I’m much, much better at reading than I am at listening to podcasts. But that is something I want to work on.

I use Twitter, which is a relatively new tool for me; I’ve found it immensely valuable. I’ve watched countless fascinating discussions happen in real-time. And every user I follow has had something useful to say.

Beyond micro-blogging, I rely on social networks (like LinkedIn), IM, wikis (well, at least one for now), this blog, and even email as ways of staying in touch with other developers. My goal is to use every tool I can find (and that suits me) to help establish and maintain connections. I think that’s how the developer community works; we’re technologists at heart, but we’re social ones, so we use a variety of tools to that end.

It cultivates learning

Good developers, of all skill and knowledge levels, understand the necessity of continuous improvement. They willingly foster the learning process, support those who want to learn, and always remain open to new ideas. For me, that exemplifies the goal of the community: encourage its members to improve. It’s not about ego, “supreme coders” on parade, or being in an “everyone-else-is-doing-it-wrong” clique. (And if that’s all you find around you, look elsewhere until you find something more positive.)

What I want out of the developer community is to learn more than I can on my own. So I expect that it will demonstrate a sincere commitment to developer education. In my view, those with the knowledge I seek can tolerate giving more than a few “Getting started…” presentations, a dozen or so rudimentary questions, as long as it helps raise the awareness of everyone in the audience. Of course, it shouldn’t always be about 101-type experiences; a healthy association pushes its members to grow; not just stay on the remedial track.

It’s not for everyone, but it should be

Despite all that I’ve said, it’s true that there are many talented, highly proficient, even brilliant, developers out there who probably don’t give one whit about any sort of community. They get by just fine with maybe a few books, whitepapers, and near-perfect recall of their Computer Science courses, thank-you-very-much.

The only problem I have with that kind of developer is that they end up being “hidden” resources; their knowledge and experience stays locked away inside their brains. They could benefit a lot more people than just the ones who happen to be lucky enough (or not) to work with them. They may not need the community, but it could always use them.

Community is important. If you don’t see yourself as part of it, I recommend getting involved at least a little bit. That could be anything from attending a user group meeting to reading a developer’s blog and leaving a comment. Even if you don’t get a benefit from the content, the mere act of participation will still move you in the right direction. Ultimately, community is whatever you make of it; just remember that it’s there to help you.

Technorati Tags: Community,ALT.NET

D2SIG Meeting For January 2009

noreply@blogger.com (R. Eric Geiger) — Tue, 06 Jan 2009 12:30:00 +0000

The next meeting for the Designers and Developers Special Interest Group (D2SIG) (think: Silverlight/WPF/Anything-else-that-uses-XAML SIG – okay, that’s my own term) is having their next meeting tonight at the Houston Microsoft office. Specifics below:

When: Tuesday, January 6th, 2009 @ 6:00 PM CST

Where: Microsoft Houston
One Briar Lake Plaza
2000 W. Sam Houston Pkwy. S. #350
Houston, TX 77042

Topic: If I remember correctly, this meeting should be covering Silverlight out of the browser. However, there’s a strong possibility that I’ve projected my hopes and wishes onto that agenda. Whatever the real topic, it promises to be good.

More Info: The D2SIG main site

This is a very, very new group, dedicated to the User Experience (UX), but it’s quickly getting a strong following. If you’re interested in anything having to do with the latest in UI, this group is for you. Feel free to drop on in.

Technorati Tags: D2SIG,Silverlight

Houston ALT.NET Geek Dinner For January 2009

noreply@blogger.com (R. Eric Geiger) — Tue, 06 Jan 2009 01:00:00 +0000

This is just a quick post that the next Geek Dinner for the Houston ALT.NET group is coming up this Wednesday, January 7th, at Freebirds restaurant. Here are the specifics:

When: Wednesday, January 7th, 2009 @ 6:00 PM CST

Where: Freebirds World Burrito
3745 Greenbriar
Houston , Texas 77098

Topics: TBD, but you can see the working list on the forum here.

More Info: Houston ALT.NET Group

I’m new to the whole ALT.NET scene, and to be clear I am NOT the organizer of this dinner… that would be Ben Scheirman. But I am really looking forward to it; I’m hoping it will be a great way to discuss various developer-related topics with lots of bright people. And maybe eat something… I’m taking the “dinner” part of that title very seriously.

Technorati Tags: ALT.NET,Geek Dinner

My Goals for 2009

noreply@blogger.com (R. Eric Geiger) — Fri, 02 Jan 2009 17:17:00 +0000

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:

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.
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.
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:

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: Developer Goals

What I’ve Learned About The Silverlight Fit Client

noreply@blogger.com (R. Eric Geiger) — Fri, 02 Jan 2009 00:58:00 +0000

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 applications. If 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: Silverlight,Fit Client,RIA

Get A Mentor, Be A Mentor

noreply@blogger.com (R. Eric Geiger) — Tue, 23 Dec 2008 06:45:00 +0000

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: Mentors

Refactoring Without Unit Testing – Like Traveling Back In Time And Stepping On Butterflies, Only More Dangerous

noreply@blogger.com (R. Eric Geiger) — Thu, 23 Oct 2008 03:17:00 +0000

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: TDD,Refactoring,Time Travel

Throwing Exceptions Like Popeye

noreply@blogger.com (R. Eric Geiger) — Sun, 19 Oct 2008 18:35:00 +0000

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: Programming,Exceptions,Popeye

Mocking The Unmockable

noreply@blogger.com (R. Eric Geiger) — Tue, 14 Oct 2008 23:12:00 +0000

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: Typemock,TDD,Rhino Mocks

Understanding TDD Resistance – Is It More Than The Learning Curve?

noreply@blogger.com (R. Eric Geiger) — Tue, 30 Sep 2008 11:55:00 +0000

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?

Technorati tags: Test-Driven Development, Programming

Silverlight Stuff: Blacklight

noreply@blogger.com (R. Eric Geiger) — Tue, 23 Sep 2008 12:02:00 +0000

Note: This post is written in the style of one of my favorite bloggers, Greg Duncan. I stumbled across his feed a few years ago, and have rarely been disappointed in any of his posts. His blog echoes a mantra I’ve been trying to incorporate into my life more, which is to “always be of service”.

Martin Grayson has posted Project Blacklight up on CodePlex to highlight UX (User Experience) technologies. Currently only in Silverlight Beta 2, others (like AJAX, etc.) are sure to follow. Quote below leached in full from the site:

“Blacklight is a UX focused code sharing project. Microsoft has released a bunch of technologies that allow designers and developers to work closely together to make beautiful software. This project is a collection of controls, samples, visual assets and ideas that has been put together by User Experience designers and developers to both show you what the technology is capable of (from a UX point of view), and give you code and samples that you can use in your own projects, completely free of charge (see the License tab above). Check out the showcase to see what is currently available...”

The Blacklight Showcase currently has demos for three types of controls in Silverlight: Outer glow Border, Simple Media Player, and Drag Dock Panel. I don’t know why, but for some reason the drag dock panel samples are the most impressive to me. I would expect to see more develop in the coming weeks and months.

Technorati tags: Silverlight, CodePlex, Project Blacklight

Ike

noreply@blogger.com (R. Eric Geiger) — Sat, 20 Sep 2008 02:23:00 +0000

Hurricane Ike barreled through Galveston and Houston in the early hours of Saturday, 9/13, with maximum sustained winds of 110 mph. I can say that while my own neighborhood has mostly recovered (power is back on, water is running, and the phones work), there is still a lot of cleanup ahead.

I wanted to try and write something slightly humorous about my own experiences during and after Ike; however, as I saw more and more devastation (both locally and on the news), nothing was funny anymore. We were very fortunate not to have had severe damage or injury to deal with, but thousands throughout our area were not so lucky. A lot of people I know are still coping with no electricity and/or major damage to their home, among other things.

And aside from the sheer physical destruction that Ike brought, there’s the economic hit that is just really starting to be felt. (The latest estimates I’ve seen were between $6 to $16 billion in financial impact). A lot of businesses have been either significantly disrupted or stopped dead in their tracks since last Friday. Almost nothing in my area was open on Monday, though some places struggled to their feet by Tuesday and Wednesday. But even today I noticed places that were still closed (mostly due to lack of power).

Ike was brutal. I can’t sum it up any clearer than that.

Technorati tags: Hurricane Ike

Silverlight Stuff: Project Rosetta, Silverlight Spy, and Building A Composite Application

noreply@blogger.com (R. Eric Geiger) — Thu, 11 Sep 2008 11:44:00 +0000

Just a quick run through some very interesting items I’ve seen lately in the Silverlight world…

Project Rosetta
A site for helping Flash designers and developers work in/migrate to Silverlight. It’s a lot of content focused on UI, design, etc., to which I say “the more the better”. And, I think it’s great that an olive branch has been extended out to the Flash community.

Silverlight Spy
A very, very cool idea… a free ClickOnce application that parses your running Silverlight app, revealing the internals so you can see for yourself how it was put together. Like the site says, “No more XAML secrets with Silverlight Spy!” Excellent. Screenshot below…

Building An Enterprise Composite Silverlight Application
From a former teammate, JP took the current Prism release and started building his own Silverlight composite application implementation. As he caveats, it’s a work in progress; but one thing to know about JP is that once he gets going on a project, he doesn’t stop until it’s a fully functional, polished deliverable.

I am a huge proponent of Silverlight, and it’s always great to see what the developer community comes up with around the technology. I think [read: “hope”] Silverlight has the potential to change how websites are built and used. I’m also of the opinion that most users will eventually want web-delivered functionality along the lines of an RIA, rather than from a series of static HTML pages mixed with a soup of JavaScript. And (just my own personal goal) I’d like to see a lot of very, very AJAX-heavy sites go the way of the dinosaur and get replaced with Silverlight*. (Topic for another post, but I am not terribly impressed with sites that leverage AJAX to the hilt. They always feel, well, “jittery” to me. …Yahoo Mail, I am looking in your direction).

* I think it would be fantastic if someone out there could come up with a “convert your AJAX website to Silverlight” tool, if such a thing were even possible…

Technorati tags: Silverlight, Project Rosetta

Have You Checked For Null Lately?

noreply@blogger.com (R. Eric Geiger) — Wed, 10 Sep 2008 03:00:00 +0000

Here’s a trick question for the developers out there: What’s wrong with this code?

    public class SomeClass

        public string GiveMeAnObject(object someObject)

            return someObject.ToString();

The title of this post gives it away, but technically there’s absolutely nothing wrong. It compiles just fine. And it runs just fine… as long as it’s given what it’s expecting, in this case a valid object. The problem is that there is no guarantee it will always, or really ever, get what it expects since it’s public and therefore anyone can invoke it.

What’s wrong is that there is no guard clause to ensure that “someObject” is valid before we attempt to use it. Without validating our parameters, we can never be sure they’re okay.

Consider the same code with the added security of a guard clause:

    public class SomeClass

        public string GiveMeAnObject(object someObject)

            if (someObject == null)

                throw new ArgumentNullException("someObject", "Bleh! That was null!");

            return someObject.ToString();

Guard clauses and parameter validation are not new by any stretch, but they are still very relevant. We see this type of code all the time, or at least bump into it whenever we see a System.NullReferenceException thrown in our application. And, unfortunately, users will see this from time to time as well. On one project I was on long ago, we would see so much code that failed to handle invalid parameters that it became our ongoing phrase…

Me: Say, I tried running our app this morning and it just threw an unhandled exception…

Teammate: Hmm… did you check for null?

Me: Aha! Nope, no parameter validation on this one method here…! Thanks!

A few hours later…

Me: Say, I have this problem with this class I’m writing…

Teammate: Did you check for null?

Me: But you don’t even know what my problem is yet...

Teammate: But, did you check for null?

Me: No.. but…

Teammate: I really think you should check for null first.

* Not quite as catchy as “ninjas on fire”, but it worked for us.

Remembering to “check for null” is part of the defensive programming methodology that strives, among other things, to keep your code running no matter what happens. And while users may not always, at least consciously, appreciate how often your app has not crashed on them, they definitely will remember the next time it goes belly-up. And if they get some cryptic “unhandled exception” dialog (if it’s an executable) or YSOD (if it’s a website) while your app makes its last gasp, what that tells them is that something bad just happened and no one coded for it. It can be disheartening, even scary, and serves to only diminish their trust in what you’ve built. Keeping your code robust is one of those practices that might feel like a bit more work up front, but pays dividends later on.

And in case you’re wondering… yes, I too have forgotten to “check for null” before… so this post is just as much for me as anyone else.

Technorati tags: Null Reference, Programming, Parameter Validation, Defensive Programming

The List – Movies That Inspired Me To Code (It’s Just A List)

noreply@blogger.com (R. Eric Geiger) — Mon, 08 Sep 2008 11:36:00 +0000

Full Disclosure – This is the third attempt at posting this list, which was originally framed in a way that seriously just did not work. The list is still the same, but minus it’s original context which, while intended to be opinionated in a humorous way, unfortunately just created a woeful distraction.

I’ll admit it.. I am science fiction geek. I have a deep fondness for good sci-fi movies, and more so for the ones that center on, or at least have a strong theme involving, computers. And, as the title says, some really did inspire me (directly and indirectly) to pursue my chosen profession as a developer. Others kept me motivated, kept me interested, or at the very least kept my imagination going.

So, without further ado, here is my list:

Tron
At a time when computers were still out of reach for most of the general population, this movie touched on AI, virtual reality, the value of software, network security, and the dichotomy between technology and the User. For those virtues alone, a truly visionary piece of cinema.

Blade Runner
The one that started the tech noir genre. Stunning visuals of a dystopian future with bio-engineered android slaves, flying cars, perpetual acid rain, and some of the best dialog ever written in science fiction. This one, strangely enough, just got me interested in the future and how technology was going to evolve.

Colossus: The Forbin Project
Before Skynet, there was Colossus. Essentially a giant supercomputer that’s hooked into all our defense systems, that quickly gets too smart for its own good (or, our own good) and decides to start running the show. It’s on the list for AI, easily enough, but also for its incorporation of networking, machine-to-machine communications, and what I consider a fairly realistic depiction of UI for the time. And good story-telling, to boot.

2001: A Space Odyssey
This was the movie I had to watch a few times… okay, several times, before anything ever clicked for me. And to this day, I’m still not sure I understand the ending. But that’s okay; this movie finally spoke to me about AI, the wisdom of having an unquestioning reliance on computers, and the ethics of just “turning off” something that can think and feel.

Alien
Simply the best in sci-fi and horror, but that’s not why it’s on this list. Just like 2001 before it, this movie excellently portrays how blind acceptance of the systems we trust our lives to can lead to, well, let’s just say unfavorable outcomes. In this case, it’s the ship’s mainframe and the android mole that, as we find out in the sequel, was from a “twitchy” model line.

WarGames
A great echo of Colossus for me, with a more humanistic, sunnier tone. Another deeply connected defense computer with too much brain and no apparent “off” switch (who forgets to put that in the requirements, by the way?). A good examination of whether wholesale automation of our most critical systems is necessarily better than putting unreliable humans in the decision chain. Also spotlights hackers, computer crime, and (obviously, via the title) wargame simulations.

The Matrix
Virtual reality to the Nth degree, AI gone completely amok, the end of the world as we know it. It simply had to be on the list, even though it’s an easy pick. But, to be honest it’s a little too easy, which is why I followed with…

Animatrix: The Second Renaissance 1 & 2
For me, these two animated segments say volumes more about the world of the Matrix than any of the main films. Short, brisk story-telling, and with plenty of tragedy, they depict the world leading up to the nightmare that the Matrix becomes. Asks the question that I never seem to hear enough of: would humans willingly choose to coexist with machines vastly more intelligent than themselves? And chillingly shows how AI can be a Pandora’s box if left unchecked.

Logan’s Run
Last on the list, but still just as important to me as the others. The message of this movie can best be summed up as: never be afraid to question legacy systems. Depicts a utopian city run by technology that no one really quite understands (having been installed many generations prior), but that everyone accepts. It’s an entire civilization on “maintenance mode”, where having new ideas can be pretty risky. Maybe it’s just that I’ve accumulated experience with all kinds of systems, I feel that now I can appreciate this movie even more. Legacy systems can be very intimidating (“somebody set this up this way for a reason, right?”), but I feel you should never be afraid to ask questions (“... yeah, but why? and do we still need it?").

There you have it. Probably not a complete list, but for me these stand out the most.

Technorati tags: Tron, Programming, Animatrix, Science Fiction