Escaping The Cozy

Not too long ago, I went out to my vegetable garden to fertilize all the plants. I have events on my phone’s calendar that reminds me when it is time to fertilizer particular things in our yard. After I was done, I left the bag of fertilizer on the grill shelf outside because I knew I was going to have to fertilize again soon. Or maybe I was being lazy. Either way, the bag got left there. I use fertilizer from Gardens Alive and it comes in a heavy duty brown paper bag that sits upright. About a month ago, we went out onto the patio and were greeted by an explosion of brown feathers pouring out of the bag of fertilizer streaking towards the creek calling us horrible names as it went.

Turns out, a Carolina Wren had taken up residence in the bag, built quite a cozy nest and laid her eggs there. Our book on Texas birds notes that Carolina Wrens are notorious for nesting in odd places like car bumpers and mailboxes. I guess this one decided the small bag of fertilizer was perfect.

Over the next few weeks, we’ve watched mom and dad come and go. Scooter seems to be blissfully unaware of the proceedings thankfully as that was my biggest worry, that he’d start to investigate. His investigations with most wildlife aren’t of the harmless curious sort and he has a way with keeping the population of all sorts of things low in our backyard. Last week, K noticed chirping noises coming from the bag and mom and dad started bringing various insects back home. Now the biggest issue was managing to keep Scooter occupied somehow when the chicks made their virgin flight. Luckily, he went to boarding last week for a vacation which seemed to coincide perfectly.

On Tuesday morning, one of the parent birds was sitting on a tiki torch making a particular call over and over again. I quickly figured out that he was trying to coax his offspring to come out of the bag and fly around with him. I’m not sure how this normally works but I expected it to be a reasonably quick procedure. However, when I came home last night, there he was, still in the same spot doing the same thing. Apparently, it’s dark and cozy in that little bag of fertilizer and the outside world is noisy and scary. As of this morning, no chicks had come out yet even though both mom and dad had joined the effort, holding bugs in their mouths while they made that same noise over and over again. Tonight, after almost 36 hours of coaxing, they were gone.

It’s easy to find yourself doing the routine, living in a comfort zone. I feel like I’ve been living in that bag for quite awhile myself. Not in the same sense as relying on my parents to bring me grasshoppers to eat mind you. Definitely in the sense that it’s dark and cozy and doing things differently from what I’m used to is scary. My comfort zone in all sorts of things hasn’t measurably been expanded since well…I don’t know when exactly. I’ve been doing the same things in my career, in my hobbies and in my personal life for years. It’s resulted in some great successes but it’s also kept me from growing. That lack of growth is starting to haunt me, both figuratively and literally.

I’m terrified of risk. I’ve always been cautious but the constant reinforcement of not taking any risks has created a monster inside of me, one that is uncomfortable in all but the most comfortable situations. It’s become dysfunctional. Unfortunately, my instinctual way to fix it is do something extreme, totally change something in a drastic manner. That’s probably not good on any level. You’d never want someone who hadn’t exercised in years to suddenly run a marathon. What I need to do instead is instigate a plan for getting to the point where I can run a marathon. Right now, that plan is limited to a daily meditation but I’m hoping to expand it as my comfort zone gets wider.

Eventually, if you want to be happy, you have to take things into your own hands. You can’t keep thinking how things ought to be unless you’re willing to do what it takes to ensure they are. For a long time I’ve been afraid of the risks involved in making things how they ought to be. I’m trying to fight through those fears and start doing things.

When Decoupling Goes Bad

I’m currently reading ASP.Net MVC 2 in Action and overall, the books seems solid. I can say this because I’ve read about 20 pages and agree with most of it. However, the 20 pages I’ve read do contain some advice that seems overdone at best and downright confusing to future developers at worst. The chapter I’m reading is Data Access with NHibernate. I’m working on an application that contains an ASP.Net web site backed by a PostgreSQL database. Previously, all my applications used MSSQL and therefore were set up using Linq-to-SQL as a poor man’s ORM. With PostgreSQL, that’s no longer an option so I’m in the process of learning NHibernate and Fluent NHibernate, a task that’s long overdue.

I hate learning a new technology by doing everything wrong the first time so I went looking for some best practices or architecture suggestions for setting up NHibernate. This book had an entire chapter on that and so I dove right in. Overall, it’s been very useful. Heavy use of Dependency Injection and Inversion of Control nicely decouple the pieces of the app from each other. However, the authors recommend something that seems a little extreme to me.

The example solution has a UI project which is the ASP.Net site, a Core project containing domain models and code, an Infrastructure project for things like data access and assorted test projects including an Integration Test project. The authors point out that the only project that references the Infrastructure project is the Integration Test project. Their rationale for this is that Infrastructure is necessarily fluid. Because of this, you don’t want to couple the core or UI to it. They set this up by using runtime DI to inject dependencies from the Infrastructure project into UI components. Specifically, the data access repositories that certain controllers need are discovered at runtime using settings in the web.config. They claim that this results in a completely decoupled application.

However, in order for this to work, the UI project needs to have access to the Infrastructure assemblies and config files. Normally, this would happen via an explicit reference in Visual Studio which would result in the necessary files being copied into the UI project at compile time. Because the UI project doesn’t have that reference, the authors have to get the files there another way. Their solution is to use a post build step in the Infrastructure project to copy the necessary files. To me, this only serves to make the reference implicit, something is likely to cause issues down the road.

The UI definitely has a dependency on the Infrastructure project. It seems extreme to hide that dependency in a post build step instead of showing it explicitly in the project references of the website. It’s one thing to write decoupled code that is easy to test and change. It’s entirely another to force developers to jump through hoops and keep track of idiosyncrasies like implicit project references. However, being a complete newbie to this form of architecture, maybe I’m missing something. Is there a true reason for managing dependencies between projects in this manner? If so, why not manage all of them in the same manner, do everything at runtime and copy all files via post build steps? I think the answer is that there isn’t a real reason for this except for the purity of the architecture, something that should immediately be questioned for intrinsic use. I’d love to hear any opinions from the experts out there.