Codecamp V

On Saturday, I went to Twin Cities Code Camp V. I know, strictly speaking I'm not a developer anymore, I manage them instead, but it's important to me to keep up on the latest technology, even more so than it was in my last job, and I taught myself a bit of constructive Java programming in that role (I got a thank you for the code I wrote that cut out three hours of resetting training materials each time there was a new training class - that's success as far as I'm concerned).

The first presentation I went to (with Erik and Bhavin, I met up with them there. Erik and I had breakfast at the Original Pancake House first) was "Software Evolution: Inversion and Injection". I came away with the following important bits:

• Think of a delegate as a single method interface.
• Injection is the loss of control. Don't get too uptight about loss of control.
• Injection/Inversion and the Provider Model are not that far apart.
• There are several good injection/inversion packages, and if you're playing with them in this order, it takes you this long (approximately, depending on your state of mind): Unity (MS) - 3 days, StructureMap - 1 day, Spring.Net - a long morning, Castle Windsor - 2 hours.
• Faced with an abstract class vs. an interface, abstract classes are sometimes more helpful because those "in the know" can use the implementation you set up (I have experience with this trying to build a provider model with implementation behind bits of it)
• Filearchy is a funny word
• Sometimes just squint at your code and try to think, while I'm squinting, what's the minimum I need to know (e.g. my code needs to know)
• Some objects have a transient lifestyle - this conjures funny images of classes with hobo sticks thrown over their shoulders

Next I went to "Advanced OO Laws & Principles with .NET" by Clint Edmonson. A high level, although very interesting presentation on what developers keep in their programmatic toolbox.

• Domain Driven Design
• Separation of Concerns
• DRY principle (Don't repeat yourself - shared code costs 3x as much as non-shared. So if you have to cut and paste more than three times, you should be sharing the code)
• Theory of the one right place (for your code to live)
• Unit of work - focus on transactional boundaries
• Open-closed principle (open for extension, closed for change)
• Design by contract
• Declarative programming (web methods)
• Provider Model
• Inversion of Control/Dependency injection
• Object:relational mapping (ORM - Hibernate)
• Scenario Driven Design
• Occam's Razor
• Pareto Principle (80% of consequences from 20% of code)
• Law of Demeter (don't talk to your neighbor's neighbor, get the information directly)
• Least resource usage
• Least Privilege
• Liskov substitution (derived classes must be able to sub for their base)
• Idempotence - pass the same item many times, process once
• Cyclomatic complexity - depth of nested decision making should be limited (there are tools to test this)
• Purpose Driven Design (alt) - think about each decision - why is the default set that way, and why are you allowing that choice to be made for you.
• Clint Edmonson's blog: Notsotrivial.net