Archive for the ‘Tech Books’ Category

DDD and Aggregates

Friday, September 26th, 2008

I started reading Eric Evans’ book Domain Driven Design.  (Seemed like one of those foundation books you have to have read if you want to be a certain type of developer)  I decided to give it a go after I got about halfway through the “Domain Driven Design Quickly” pdf – it seemed interesting enough that I wanted to have a go at the real thing.

Anyway, one thing it talks about is Aggregates… basically, a tree of dependent objects that don’t mean anything alone-like line items to an order, as opposed to a customer that is an entity that has meaning by itself.  I guess I haven’t explored things enough yet, but I’m thinking abouton something I’m looking at-I’ve got something like an order, and something like a line item.  There should be no separate repository for the line item.  However, in practice you may need to deal with the line item by itself, for instance the “edit the line item” screen on a website.  In a desktop app, you’d pull out the line item w/ roder, keep that around, and then save when the editing’s done.  However with this web scenatio, you come back from the editing screen and have… some IDs.  Sure, you may have selected the line item from the order… but as the web is stateless, you don’t have your order and order item all ready to update, you’ve got to rebuild that and apply the changes before a saving.  So, you’d pull out that line item from the repository *via the ID*. Or if you prefer, pull out the order via its ID, then iterate through its line items and pick out the relevant line item from the line item collection by ID.. also messy-you preserve the aggregate idea since there’s now no repository for  line items, but you’ve got iteration, and worse, a domain-level usage of picking by ID, which feels like bleed-through.  But you really need the order and the order item, so you can make your changes and then save.  Uh, I guess you can put them in your session, but that just seems even worse than either of the above options due to unreliability.  But maybe that’s me being pessemistic.  anyway, is there a clean way do deal with this?  Or at least a generally agreed-upon lesser evil?


Tuesday, 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.

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.

Another book on the stack…

Friday, March 7th, 2008

Working Effectively With Legacy Code is supposed to be fantastic.. and who doesn’t work with legacy code? I know I do…

Agile Principles, Patterns, and Practices in C#

Wednesday, March 5th, 2008

i hear it’s a good book- another one to add to the stack of books-to-read…


Tuesday, March 4th, 2008

Currently reading Refactoring by Martin Fowler. Yeah, any programmer worth the space he/she takes up is going to do some version of refactoring, but this is really attacking refactoring with a systematic, safe, testable approach. It seems like a better way of approaching it than the normal way:

  1. Oh god, this code sucks, it makes me stressed just to look at it…
  2. Destroy, destroy, destroy
  3. Humpty is shattered across the floor
  4. Put Humpty together again (universally known to be non-trivial)
  5. If the step above didn’t end up as an endless pit of pain and despair, things are actually much, much better!

Something that doesn’t involve the level of inoperable destruction in step 3 but still gets to the same final state is probably an improvement! Giving these refactorings names seems like a good way to keep the operations concrete an separate in my mind, and will help in future conversations. Good stuff!

Demeter’s Law

Friday, January 18th, 2008

So, I’m still working my way through The Pragmatic Programmer (yeah, I’ve been busy) and just went through the chapter on Demeter’s Law. I have to say, I’m a little skeptical. The general idea is that you only use objects and methods of objects that your current method(or class) “owns” directly, not things that other objects own. So for example, if your object takes a “Customer” object containing a “Person” object, you should not call Customer.Person.FirstName, because you don’t own the “Person” object. Instead, you should use a wrapper getter in Customer that gets FirstName from Person (CustomerFirstName, say). And if Customer was inside of Order, and you wanted the Customer’s first name from Order, the proper thing to do would be to wrapper the CutomerFirstName up, maybe with BuyerFirstName.

SO, instead of Order.Customer.FirstName

you’d have Order.CustomerFirstName

And THAT you can safely call. What’s the reasoning for this? well, this allows all kinds of changes to Person and FirstName, and once the class is changed in Customer, nobody else needs to know anything happened. since everything else is a wrapper, everything else will just work. Problem? well, Order, instead of being a stripped-down class just dealing with order-related stuff ends up possibly being an enormous class full of Customer and Person wrapper stuff, and depending on what other objects Order has, it could be even worse. Pragmatic suggests dealing with this by using a code generator… Frankly, though I see how coding this way would be safer, the idea of having huge amounts of wrapper crap kinda feels like a smell. Maybe this is worth it, but I’m not quite sold yet on it being worth the clutter. I’m going to have to think about this one a bit more.

The Pragmatic Programmer

Sunday, December 16th, 2007

I’m about 3/4 of the way through this. I’d heard a lot of it from other people so there’s not a lot that’s stunningly new, but it’s a good introduction to a lot of better principles. In particular, I’d heard about the DRY principle, but it was good to actually read about it. Some of the stuff about coding defensively seems good, but I feel like it could be going a bit overboard. The discussion of the constraints in Eiffel sounded interesting, and I hear RSpec has something interesting. Something to look into…