Archive for April, 2008

My first 5k

Monday, April 28th, 2008

OK, this post isn’t actually technical, but learning comes in a lot of forms, right?

This weekend, I ran my first 5k, and got a chip time of 34:35.  Yes, that is slow, but I did actually run the whole way, which was my main goal.  Particularly interesting was the discipline required to run at a slow sustainable pace when packs of people were sweeping by.   Of course those people have probably been running for longer than a month and a half, but that only goes so far in fighting the feeling that you’re supposed to be keeping up with these people.  Sure, maybe I would have been able to do one 10 minute mile, but I would have been half-dead by mile 2.  And yes, I know it’s not a marathon, but training for this has been the first time I was running neither because a class required it, nor because someone was chasing me, so it’s been educational in its own way.

Working Effectively with Legacy Code

Wednesday, April 23rd, 2008

I mentioned this book in an earlier blog, and I’ve started to read it. (I was somewhere around 2/3 through Martin Fowler’s Refactoring, and in the weeds of arcane refactoring patterns when I decided to switch out) I’m maybe 70 pages in, and I have to say Working Effectively With Legacy Code thus far seems quite good. It’s actually a great companion to the refactoring book, and to the design patterns that I keep trying to get back to so that they really sink in (through reading the Heads Up book last time I made a concerted effort at patterns, though I might give the GoF book a go as it is the canonical choice.)

Unlike the patterns, and even more than the refactoring book, this book really gets at how to approach a messy codebase. Rather than just talking about refactoring, it really discusses them in context, usually in the context of separating concerns enough to test. At this point in the book at least, testing seems to be the short-term goal, making the assumption that you probably don’t have tests covering your legacy code. Fair assumption to make. So, it doesn’t focus on making the code easier to read, more maintainable, or elegant. It actually focuses on smashing apart your concerns, by whatever means necessary, so that you can get stuff under test, and *then* make stuff pretty and maintainable. The chapter I just read focused on finding what it referred to as “seams”-places where you can change the behavior of the code to make it testable *without* messing with the code under test in a significant way. for instance, if you’re already passing in a class to use in your operation (Dependency Injection) you’re golden. But Feathers suggests much more “wily” seams, such as overriding included libraries with your own wrapper libraries during compilation to introduce hooks for testing. Whew. that could get ugly… but then, you’re trying to reform legacy code from a test-unfriendly state, it’s probably not going to be pretty. Anyway, that’s a fair bit different from the refactoring book, as that tends to discuss tests as an assumption that you have before doing sometimes significant changes.

The book also has some chapters ahead of me that seem refreshingly realistic.  These are from memory so don’t quote me, but there are chapters titled things like “I can’t get my code into a test framework!” and “I don’t even understand my code enough to change it!” Working on a complex, deteriorated codebase is a programming challenge, but also a morale problem.  It’ really easy to throw up your hands and say “this code base cannot be saved!  It needs to be totally rewritten, and since that won’t get paid for, we’re screwed!” … OK, frankly, this IS sometimes true, and I do think it is important to recognize when that’s what you are really dealing with-and to recognize that’s a high bar.  The vast majority of the time, you’re facing some code that’s okay, but could be much, much better.  The transition will be tough, and involve a lot of rewriting and duplication, but you know it’ll pay off.  Do you do it?  Well, it depends, of course.  But the answer should not be determined, as it so often is, by pondering the work involved and deciding that it feels to exhausting to even contemplate.  This book thus far seems to be pretty good at illustrating a straightforward path to get to somewhere better, and get over the intimidation of all that badness.

Bazaar gets a GUI

Friday, April 18th, 2008

Looks like this is still in the early stages, but Bazaar, one of the new generation of distributed source control systems is getting a gui:  Yeah, I know, “guis are for wusses” that’s fine and all, but when you’re checking in some files and not others, the checkboxes are kinda nice. 🙂 Not to mention the far more important reason:  If you’re on a project with Front End Developers (your slicer/HTML coder people, photoshoppers, etc) they may fight you with a vengance if you require them to use arcane command-line stuff to work on a site.   So, that’s limited choices for such projects to CVS, SVN, and the like.  It’ll be nice to have Bazaar as an option as well!

Pain encourages change? Not sure I buy it.

Wednesday, April 16th, 2008

A frequently repeated theme on the Alt.Net list is that certain ideas, like IoC, are not understood until you feel significant pain, and you’ll be motivated to try something new.  From Derik Whittaker’s post today, “[…] do this not because he is told or shown, but because he is in so much pain because of NOT using them that the only other option IS to uses these techniques.”  Frankly, I’m not convinced that this revelation will ever happen for many developers.  In my experience, if certain kinds of pain is seen as integral to the development process (whether really it is or not) there will be no searching for alternatives.  Instead, that developer will ask for more time/resources, or just say those problems are part of development, etc, and yes, sorry, but this task IS going to take 10x longer than planned.  The solution to make it much better could be handed to the developer, but if it conflicts with previously-held ideas, it’s seen as a threat and rejected.  It’s kind of an eyes-open vs. eyes-closed attitude, and there are a whole lot of people with their eyes closed.  The majority?  Sadly, I’m pretty sure that’s the case.

Code Camp!

Sunday, April 13th, 2008

Yesterday, I attended my first Code camp.  I thought it was great! Yes, semesters of lectures in college was a bit tiring, but now, I find I’m hungry for them, especially when it’s just a day. I work with some smart, nice people, but as I’m pretty much on my own in my technical area, I don’t really have any real mentors, and so learning has been kind of a do-it-yourself project. So these sort of events are doubly valuable.

I attended “A Gentle Introduction to Mocking” taught by Scott Allen, which was pretty good-I’ve done some experimentation on my own, so I was ready to hear more. And I really don’t have a C# mentor at work, so seeing someone else do it, and *how* they went though was really informative. Sometimes you pick up little things that they do as a matter of course that you just didn’t catch when walking through examples on your own. And there was a discussion on when to use mocks vs. stubs, which I found interesting. I also had some revelation about my code base at work. There are certain parts of the code base that I’ve never been sure of how to test, or even if it was possible, because they jump off to NH calls a lot. Amusingly, I was also unsure of when one would use DI, or an IoC container. At this talk I suddenly figured out that the way to test those classes is that LOTS of stuff that I hadn’t even considered a problem creating in place needs to be inserted with constructor injection, enough so that it would actually be pretty ridiculous to do by hand. and so, I apparently need a container.

I had originally planned to attend Jay Flowers’ talk on TDD, but as he couldn’t make it, Kevin Jones kinds stepped in for a review of C# 3.0 features. He was actually pretty negative about a fair number of them, and I have to say after reviewing them, I am a little skeptical about some of them as well. The “var” feature in particular seems a bit dubious to me. I mean, we’re dealing with a strongly-typed language here. Introducing something like that feels like inviting in the craziness of vbscript. Maybe I’m wrong, but I feel like opening that door is questionable. I mean it works for Ruby and Python, but but those languages work on the basis of trust-it’s a different philosophy, and I wonder whether mixing in duck typing (though once you assign, it’s actually strongly typed, so it’s hidden typing, not true duck typing as I understand it, at least) to a strongly typed language is really a good idea.

Next was Constructive Code reviews. I was actually hoping for a little more meat in terms of how to approach the code, what things to think about, possibly something involving walking through it with code snippets. It was more a review of the different levels of code review from desk check to a full formal process. Still informative, but maybe not as interesting for me as what I was envsioning.

Next, Michael Podwysocki reviewed Dependency Injection and Inversion of Control. Again, I’d done some review of this on my own, but it was great seeing someone else explain the idea, and then walk through how to actually do it. The lecture took on a lot of extra meaning since I had earlier seen how I could apply it to my current project (whether I actually will be able to reorganize things is a separate manner, but at least I see an application for DI) I’m looking forward to him putting his code up, so I can more closely go over what we did in the class. It was also interesting hearing about other frameworks. I’d also heard about Windsor quite a bit on Alt.Net, and heard mention of Unity and StructureMap and Spring, but hadn’t known there were many more than that. Anyway, very useful.

Lastly, I attended a talk on LINQ To SQL in an N-Tiered Application. I’m still mulling over the level of usefullness of Linq to SQL when there’s NHibernate which is so full-featured. However, the Linq syntax itself is very interesting, particularly as it’s compiled and understood by Intellisense, etc. If it was brought in to nHibernate, it could be a *very* nice third querying option to complement HQL and the criteria interface.

Afterwards, they gave away some swag. Yeah, I can’t complain how I did… got a copy of Vista. Could be very nice to set up for Parallels on a future Mac purchase? Then, some attendees headed over to a next door bar. As usual, some of the most value in the tech events comes from the conversations. Interesting, smart people. Almost enough to make me reconsider my opinion of the average .Net developer… but then I remembered that anyone who cares enough to use their own weekend time to go to a code camp is quite a bit different from the typical 80% of the developer population, so I was not dealing with a good cross section. heh.

MonoRail is rolling

Monday, April 7th, 2008

Got MonoRail set up on SharpShop, and got a Product List page working with it.  I haven’t done too much thus far,  but I’ve gotten a taste.  First off, it seemed like much more of a pain to set it up than turbogears… It might be because tubogears might be more mature, but it seemed a lot more one-command-and-your-stuff is set-up.  With MonoRail, I spent a fair amount of time futzing with the web.config, copying in a variety of dlls, wondering why I was getting page not found messages, etc.  It probably would have been better if I’d been using VS2005 and used their startup thing, but requiring a costly tool to get a decent setup experience seems lame.

Anyway, after much copying, and comparing of configuration, and staring that their Getting Started project I finally got SharpShop set up.  At that point, it really came to me how different this was going to be.  No Page_Load, the usual starting place.  No Page at all, actually, and some sort of scripting language with a for loop seems to be the way to handle repeater tasks and such.  I’m a little uncomfortable with this.  I know some people don’t like the page model, but if you declare “no <%” in the aspx pages you kind of force people to code in the code-behind (overall, good).  This monorail style is maybe a little less magic in the regard of binding and repeaters, but compensates by having some amount of logic in the view page.   Truthfully, I’m not sold yet. I’ve worked on some horrific ColdFusion, as well as classic ASP, and even Perl, and having logic strewn all over the views is a common, massive problem in terms of readability and maintainability.  I worry this could be a slippery slope of allowing people to feel it’s OK again to code right in the view.  I sure as heck don’t want THAT. Maybe the solution is to hire people whose coding judgment you fully trust, and not hire developers that are just waiting and hoping to go back to the bad old days of spaghetti code, but I don’t have that luxury.  (though wow, what a perk that would be)

I’m going to dive further into MonoRail, and see how it deals with a variety of common tasks, and compare that to the usual .Net way.  The page model and all of the goodies it includes are a pretty big selling point of ASP.Net, so I’m curious to see if rails-style development on the platform proves to be worth what you’re giving up.