Monday, January 30, 2012

New Year, New Job!

Two weeks I parted ways with my previous employer. It wasn’t an easy decision as I had been there for 7 years and my department was tight. More family than co-workers. But it was time to move on.

After a 2 week hiatus I’m now part of the Solutions Practice at CEI America as an Associate Architect! Lots of changes with this move. To start I’m working for an IT company. Typically I have worked for non-technical entities within the IT department. Another big change is working with a team of developers! This is by far my favorite aspect of the new job. A majority of my career has been of a lone developer. Not any more. I have a team of talent to help and challenge me, and vice versa. And finally, the biggest change: ditching the commute in favor of a home office! Well it wasn’t really a choice, I wasn’t looking to relocate across the state, but it’s what made this possible.

My blog will continue to be my own with no direct ties to my new employer. I may also start blogging about other topics too, not just techie-geek-speak.

Tuesday, January 10, 2012

Duty Calls!

Today I came across the following comic strip and busted out laughing. Thought I would share it with you.

 Taken from xkcd:

Wednesday, January 4, 2012

My thoughts on Boiler Plate code

During the same conversation about how I structure code the topic of “what boiler plate(s) do you recommend?”.
My answer: none!
You may be asking why. This comes back to the idea of vertical, context specific, slices. Any boiler plate code would be covered by the infrastructure MVC/P, data access, logging, etc. And these frameworks are really boiler plate as they are implementing compound design patterns.
And if there is some form of boiler plate code that emerges from the vertical slices encapsulate it into it’s own object and inject the component into the calling code. Favor composition over inheritance. It pays off every time.

Architectural Design

I was asked recently “how do you go about designing an application”? Let’s assume we know the problem domain and what the application needs to do. The next step is how we go about solving the problem.
Traditionally you have stacked “layers”
traditional ntier
The problem here is that you must assume one builds on top of the other and that all functionality must fall into a specific layer. You typically end up with Fa├žade classes ending up as God classes. Anything that could ever be done to a user goes in the UserFacade class. Orders => OrderFacade… you get the idea. I find this happens because it lines up nice with the picture of n-tier you are imagining in your head.
Instead I like to think in vertical slices where each feature is a slice. Think of a slice as a specific context in which the user accesses the system. Search is a very common feature, so is placing an order. These features will most likely consist of components touching all the “layers” of n-tier, but they are only used in one specific context. (sorry can’t find an image to demonstrate what I’m writing.)
How does this impact the code. When designing by the slice you end up with many small context specific objects all designed to do one specific task. So you have many objects, but each object is only responsible for a small, one, aspect of the system. reading code becomes so much easier and managing the code becomes easier as well because you can keep all the components next to each other.