Windsor, for real

September 16th, 2008

So, I finally got an implementation of an IoC Container (Castle Windsor) set up and being used in a production environment…. Based on the whole settings things up for mocking, it became very clear why they were needed!

On a current project, I’d set up and gone though writing tests as I went along.  It was a colleague’s task to write a bunch of integration tests.  (The question of how many full, top-to-bottom integration tests are actually needed is an interesting, but different question… regardless, they are well understood and trusted)  It turns out that all of these interfaces and the tons of newing up required for the dependency injection got to be pretty painful, and what’s worse, confusing and unclear.  Also, as I was refining things, I continued to refactor what was there, so the constructor signatures were changing… messing up AL those integration tests.  I think if he were less nice, he would have said “WHY do you have to make this so confusing??”

Exactly the situation IoC containers were made for.  And I think I got it all set up in about an hour, from download to finish!  Which is a few hours less than I’d expected.  I couldn’t quite get my create down to a single line a) because I was dealing with VB.Net, an irritatingly verbose, hard-to-scan language, but more importantly b) I had to pass in a configured object in to one of my objects, and then pass THAT on to the constructor of object I was really trying to get.  Previously, this chain was hidden among the plethora of newed-up stuff.  Once the container was in place, all I had were these special items, right after each other-this chain of dependencies on the configured object was very clear… the cluttering vanilla dependencies were out of sight.  I consider this a huge, and unexpected benefit.  If I need to change my constructors to break things up more (I have a few places in mind)  then I won’t break these complex integration tests.  My mocked out tests, sure… but they are each restricted in what they touch anyway, so the trouble there is much less.

I know, these were tests, and people often don’t use containers for tests.  However, because of their being integration tests, it felt appropriate.

An interesting point is that this is all going to end up being accessed through a single webservice, so the “live” newing up is only going to be in one place-so less *need* of a container for live.  This is just as well, because another team is doing the maintenance, and this way the unfamiliar stuff isn’t in actual live stuff that’ll could freak them out if something happens with it on live.  Same reason we went with VB…  Anyway, even if we don’t use it on “live” code, Windsor will still save us time.

Of note is really how all these things sort of come together as a package-  DI, mocking, IoC.  You want mocking, you do Dependency Injection, probably Constructor Injection.  You do much of that, and you’ll find yourself wanting something to magic everything up… thus your Inversion of Control Container.  I’d looked at containers a few months back (I’d heard them mentioned a LOT, and thought I should look into them), but I didn’t quite get a grasp of when or why you’d ever use them in practice.  I changed how I worked, and it became obvious.

AlamoCoders

September 9th, 2008

Attended an AlamoCoders meeting tonight.  Interesting talk on jQuery by John Teague. I’d previously seen Front-End Developers doing stuff with it, but I didn’t really “get” it-not that I’d looked into it, or tried… what with struggling to pick up nHibernate, DI, and that whole world of things, I felt like my plate was already pretty full.  This overview really helped though.  Previously, I’d glanced at a bunch orf jQuery code and just thought “uh, that’s not js…. not sure what this is. must look at-eventually”  turns out, the key things with jQuery are 1) philisophically jQuery is set up to work on elements much like CSS does.  it finds, groups, filters, etc upon the same IDs and element types that CSS does.  It looks a bit different, but much of jQuery stuff is really just finding elements, picking out selectors, etc.  2) jQuery is sort of like working at the UNIX command line-it’s all about feeding the results of one thing to the other… jQuery code is chains of long commands that find, filter, and then do something (like assign a function to a click action)  this code is short, and once you get the hang of it, easy to read.  As a side benefit, it even keeps code out of the HTML.. not even any “onClick” commands.  Nice.  doing *that* without a library is not fun at all.

As an aside, I won a copy of “LINQ Unleashed”.  I confess the actual naming of the “Unleashed” titles amuses me.  It seems one step short of a wacky reality show title… imagine, “When SQL Attacks” or “Mocks Gone Wild” ..I mean really… eh… no looking a gift book in the mouth, I guess.

Tried for a spot at KaizenConf (Kaizen, as in a Japanese word for Continuous Improvement, it seems)… it sounds like a great learning experience, and it’s practically down the street in Texas-terms.  Sounds like it’s not a direct registration process, but some sort of judgment-on-mystery-criteria-then-invite.  That’s a bit discomfiting, but hopefully it’ll work out.

Moq and mocking on a real project

September 9th, 2008

So, back to blogging… (the whole moving, changing jobs, losing boxes, and generally throwing my life in disarry made expounding on topics an admittedly lesser priority)  in the past week or so, I’ve looked into Moq, mostly on the basis of it being the newer, cleaner, super-awesome mocking framework.  I’d played with Rhino Mocks in the past, so I did have some baseline for comparison.  However, in this case, time and ease was of the essence-I was using this on a real project in which nobody else knew mocking, so quick rampup and ease of explainability were key. Maybe not the best time to pick up an unfamiliar tool, but… uh, no time  like the present and all, I suppose.  I figured since a testing framework is only used on the test side and the production code is not dependent on it (please, don’t split hairs about testing code being production code, I know it sort of is, but that’s not the way I mean) that the risk was a manageable level.  I went out, and set up tests using mocking for all repositories, and for internal utilities.

Moq sure is different from Rhino Mocks.  The basic idea of mock as stub-type thing is preserved, but the actual usage is very different.  In Rhino Mocks, you declare a repository for the mocking framework, get an object from it that fits your interface, and then record a bunch of calls onto it.  Later, you set the mode to play, then run your test code.  Finally, you can verify that all the calls you set up were actually used.  This record/play model takes a bit of time to understand, and to see what it’s for.  In contrast, Moq does away with the special mocking repository, and the who record/replay stuff.  Sounds really easy, right?  Not so fast.  Moq uses lambdas/delegates to set up the calls on the mock object.  Lampdas are a pretty new feature, (thus still new to a lot of people)  and one of the less-easiliy-readable-to-a-newbie- features I’ve come across in .Net.  I’d say they’re up there with regular expressions in terms of initial incomprehensibility.  Worse, I am restricted to implementing using VB.Net on this particular project.  If you thought lambdas were weird with C#, they’re even worse in VB.  I’m a bit worried that I may have introduced a *big scary* thing into this project with using these VB lambdas.  We’ll see if I’ve shot myself in the foot or not here.

Another item of note about this is that is is actually the first time I’ve used mocks in a real project and not just toy projects at home….(old projects sans interfaces could probably be TypeMocked, but not regular mocked without a whole lot of destruction)  It changes the whole project, pushes into the dare I say “modern” way of developing.  This project is essentially greenfield, so there was some oportunity to set things up the way I needed.  This may be obvious, but interfaces really are key.  You use an interface, you can mock.  No interface… well, it’s going to be a whole lot tougher.   The other thing, you have to be able to inject your mocks to use them instead of the regular classes. So… poof, project gets DI.  Once you’ve got things heading that way, your constructors explode.  I have the feeling I’m going to get some pushback on those.  So, if your repositories are mocked, and various utilities are mocked, you end up with a constructor with 8 things in it, and some of those have constructors with a bunch of things… yow!  Which brings in (hopefull) an IOC container to manage the madness.  It’s a waterfall of cause/effect.  Is all that worth it?  Well, you get a lot more flexibility and significantly more granularity in testability.   But what if 95% of developers have no clue about IOC/mocks/DI- these concepts are not only somewhat unknown/advanced, but are genuinely tough to wrap your head around-you’ve just wounded your maintainability through no fault of the technology itself.  Still worth it?  I can’t really say.

Prepping for the big move

June 12th, 2008

So, I’m working on heading to San Antonio-permanently! I’m still locking down details about exactly when and how, but I’ve started my research on tech groups in the area. Unfortunately, I don’t see an Alt.Net specific group down in San Antonio like the fantastic DC Alt.Net group, but I’ve found Alamo Coders, which sounds like a pretty good and relevant group. I’m hoping I’m still in DC for Matt Podwysocki‘s F# talk… I should be, but we’ll see how it goes. Either way, one good thing about this move is it looks like the next big Alt.Net meeting is going to be in Austin in October. Clearly, a no-brainer to go, these conferences are free or inexpensive, said to be a great experience, and it’ll be happening right around the corner from me. I’m looking forward to it!

DC Alt.Net meeting

May 28th, 2008

OK, this is a bit late, but last week we had the monthly DC Alt.Net meeting. On a bit of a different spin, the topic of the week was Lisp, led by Craig Andera. I hadn’t done any Lisp save for some very, very simplistic stuff back in the college Programming Languages course, so it was really very interesting to get a look at it now, both in that Craig covered much more sophisticated topics that the simple list adds we’d done back then, and that I now have a lot more programming experience. From the strongly-typed, heavily structured background I’m coming from these days, Lisp struck me as fascinatingly different; in regards to my recent experiences, I have to say the mindset was significantly more like Python than anything else I’ve worked with in a long time. Actually, the similarities are convincing me that I should make a serious effort to achieve a pretty sophisticated understanding of at least one of the dynamic languages (Python, Lisp, Ruby, etc) so I have that mental model in my toolbox. Sometimes a different way of thinking about a problem results in finding an answer, but there’s a bonus of a more directly applicable usage in that C# is beginning to borrow some dynamic language features such as lambdas; and the better I “get” dynamic languages, the more I’ll see how and when to appropriately use those new features.

Mini programming exercises

May 14th, 2008

For the past few days, I’ve been practicing writing up small programs. By that I mean small, self-contained programs made up of a few classes, maybe in a single file, with a main method so it can be run as a console app, things that can be whipped up quickly. As I’ve pretty exclusively been working on adding to and modifying a single huge app over the past year and a half, this is pretty different. For one thing, it’s been interesting figuring out the minimum amount is to get a working program, accompanied by unit tests. No Asp.Net, no “Page”, no “Monorail”, no “Enterprise Architecture”, just a bare little program that calculates or solves something. I know it may sound weird to command-line scripters, but this often isn’t done in the web world, particularly the Microsoft web world. Sure, I did this sort of thing in C++ back in school, but I haven’t done it in C# and as I’ve been focused on web, I really did everything from a browser UI perspective, with all the overhead that requires . I’m out of practice, and it’s a bit embarrassing. For the first one, I literally sat there for a bit thinking “how does one go about doing this?” sigh… well, at least this is one lack in my tools at hand I’ll have fixed.

My first 5k

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

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

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: http://bazaar-vcs.org/TortoiseBzr  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.

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.