Bio
When I was growing up in a farm community in Missouri, there was a “special” breed of folks around called Shade Tree Mechanics. Usually they were not the most reputable people in the world, but they had a knack for fixing mechanical problems and a reckless fearlessness to tinker with anything. A shade tree mechanic can be spotted by finding the pair of legs sticking out from under a beater car on blocks, surrounded by other skeletal vehicles crowding the rest of his scrubby, junk-laden yard. The beaters you see abandoned all around him aren’t useless, they’re fodder. He takes bits and pieces and tweaks and tunes, and comes up with a creative solution to your needs. Reputation notwithstanding, a shade tree mechanic knows how to get things running. While I don’t have any particular mechanical ability (despite a degree in mechanical engineering), I like to think that I am the developer equivalent of a shade tree mechanic . My hard drive is certainly littered with the detritus of abandoned open source projects. I’ve had a varied path into and through the land of software development …
- Shadow IT – Getting my feet wet writing rogue applications for my engineering team. Having a blast cowboy-coding and generating a lot of fodder for the DailyWTF. Oracle, ASP, VB, and DHTML. I moved on to be a “real” developer.
- Captive IT – Working in in-house IT for a Fortune 100 company designing enterprise applications. I actually got to be the technical lead and architect on a mission-critical system for my first real development project. No prior experience, no adult supervision, no problems. I described the architecture to a former colleague, and his only comment was, “You’re going to spend some time in Purgatory for that one…” I also got to experience my first Death March Project, a lot of corporate politics, and secretive reorganizations. On the positive side, I learned about high availability, disaster recovery, and instrumentation, and I began to successfully apply OO design patterns and UML modeling. Our waterfall process changed often, and was enforced capriciously by a dizzying array of compliance bodies, laying in wait like 18th century highwaymen determined to ambush hapless travelers. I didn’t particularly like it.
- Non-Coding Architect – The last reorganization left me a non-coding architect just as the Microsoft world was dumping the DLL Hell (think VB/COM/ASP) technologies for .NET. I got to sharpen my Powerpoint skills while decorating my cubicle walls with Dilbert cartoons. The organization simply could not resist any type of evil fad — CMM, Six Sigma, “It’s not a process, it’s a framework,” fuzzy-headed SOA strategies, offshoring, “programmers are a commodity,” “Who Moved My Cheese?”, the “Fish” book, and a matrix model (yay for dotted-line bosses). I made a half-hearted, quixotic attempt to introduce iterative and incremental processes, but no one in management cared. In order to regain some type of technical relevancy and avoid 80-some hours of mandatory CMM training, I jumped again to become a consultant.
- High Priests of Agile – I spent a mostly positive year and a half working in the .NET practice for an elite consulting company. Extreme Programming, Test Driven Development, Continuous Integration and .NET. Consulting is a great experience. The intellectual opportunities are abundant, and no matter how bad an assignment or client is, you can solace yourself that it’s only a matter of time before you’ll get to move on to a new venue. I had to learn software design all over again to incorporate TDD techniques. Besides too much StarBucks on the expense account, I got an absolute bellyful of XP theory and zealotry. If I hear, “In the white book, Kent Beck says …” one more time, I’m going to puke. XP, and agile in general, works — but software was written successfully before XP, and some of the older stuff (UML, Responsibility-Driven Design, Design Patterns) is more effective in certain situations. Besides, constant travel with an infant at home is a non-starter, so I left for a job close to home.
- ALT.NET Celebrity Programmer — After I left the High Priests I thought I knew some things that would be helpful to other developers if only they knew those same things. I started a blog and wrote a lot. I wrote about process, design, testing, and even team mechanics. I jumped into the ALT.NET movement with both feet. I got a recurring column in MSDN, spoke at conferences, and landed a book deal (don’t go looking for it, I never finished). It’s been mostly good, but I’d urge some caution for anyone who wants to pursue that kind of thing.
- Open Source Developer — I’m also the founder and de facto technical leader of the Fubu family of projects and StructureMap. At any one time I’m more or less feeling guilty because of the issues I haven’t fixed, the adequate documentation I haven’t written, and questions on user lists that haven’t been answered.
My name is Jeremy Miller and I am a Developer and Software Architect in Austin, TX.
Jeremy,
Thanks for StructureMap. It is a great product.
I have been using it for some time very succesfully with a config file where the pluginTypes and pluggedTypes are nicely organized. Of course, the assemblies that contain the concrete types are NOT referenced in the calling assembly.
I am trying to use the concept of Registry DSL instead but there is something that I don’t seem to comprehend when using the For.Use(). In order for this to work, the concrete types MUST be in a referenced assembly but …. this really kills the purpose of IoC as far as I am concerned because the calling assemlby should NOT have any knowledge of the concrete assy, just the interfaces.
I tried to use the Scan with Assembly and AddAllTypesOf. This resolve my problem but it does not allow passing any constructor parms like the For.Use does and so I cannot pursue this avenue.
Am I missing the obvious? Should the Registry be in its own assembly that references both the interfaces assy and the concrete types assy?
Thanks, Yves
@Yves,
Let me get a blog post together for you by the end of the weekend.
“Should the Registry be in its own assembly that references both the interfaces assy and the concrete types assy?”
Yes, that’s one way to go about it. The Scan() business can be used (don’t have the code open, so the call might not be exactly right) like so:
Scan(x => {
// specify how you wanna suck in all the other assemblies
x.LookForRegistries(); // this will make it use any Registry classes it finds in the other assemblies
});
No xml necessary.
Wow, thanks for your quick reply, I appreciate it. I’ll be looking for your blog but I thought I would mention that I did try to put a Registry in the assy that contains the concrete types (which I don’t like to do because I then needed a reference to StructureMap) and use LookForRegistries() but it didn’t work for me:
Scan(cfg =>
{
cfg.Assembly(dal);
cfg.LookForRegistries();
});
whereas this works:
Scan(cfg =>
{
cfg.Assembly(dal); cfg.AddAllTypesOf();
});
dal is const with assy name. No need to reply here if you’re going to do a blog as I have already cluttered your BIO page enough
.