July 2012 - Drowning in New Technologies

Sunday, July 22, 2012 9:14 AM

Since April (around the time of my last blog post!), I've been on a gig with a company out of Indianapolis. It's your classic big corp, big ball of mud, type of application. Nothing new to me since I've spent my entire career in corporate America and I'm pretty sure I've created a few balls of mud myself.

The cool thing about this gig, however, is the team. After some turn-over and apparently a breaking point that caused them to get much more picky about hiring decisions, the team I joined seems to be a team of rock stars. Most have figured out they can come to me with questions on just about anything code related and here's the cool thing - answering their questions is always easy. I mean, they just get things insanely fast - every single one of them! Now, I've worked with some freaky smart developers before (last team I worked with at Tyson for example), but rarely do you see a team of dozens where all of them are freaky smart. There is always a handful of laggards (no, I don't think you are one of them).

Additionally, I've gotten to learn a few new things on this gig.

SOLR

I haven't become a SOLR or Lucene expert or anything, but I've had to do a couple things with SolrNet. Seems to be all that I've read about over the years. Can't say I'm enjoying this from a developer's perspective though. You see, they have all the environments setup for it, but when developing locally, the internal SOLR abstractions hit DEV instead of local. This means if you're working on UI that uses the search indexes, it sucks because your local changes obviously aren't going to show up in the indexes from the DEV database. It also means I must be connected to VPN to touch UI using SOLR.

An implementation of the gateway and/or facade patterns would take care of this nicely I think.

Automapper

I'm not entirely sure how I feel about AutoMapper yet. I've heard nothing but praise about it for years now, but this is the first time I've been on a project where it is actually being used. Maybe it's the way they're using it, or maybe I just haven't seen the light yet, but at this point I'm not digging it.

Sure, it does make your controller actions much smaller. It also takes care of DRY if you're mapping between two objects in many places. But mostly I find myself constantly having to hunt down the mapping logic to figure out exactly what is being copied between the objects, or, more frequently, to find out why something is not mapping correctly. I'm sure I'll come around, but right now it seems like a mix of voodoo and magic. Most importantly, there is no "go to definition", search results is the only way to find the mapping.

Topshelf

This one was fun. I played briefly with Topshelf in the past as a spike - never made it to production if memory serves. This time though, we're using it to take care of the Windows service that handles all of the project's scheduled background work. The API is crazy easy and lightweight. Can't think of anything negative to say about this at all.

NServiceBus

Holy crap this thing is cool. NSerivceBus has been on my radar for a long time - as well as Mass Transit. We had a bit of trouble with MS DTC and permissions and whatnot, but it has otherwise been nothing but goodness. I love the feeling of isolation and extremely small units of work you get when dealing with service bus architecture - each message is its own unit of work and tends to be a small one.


I think that pretty much covers it. Well, there are a couple of others (like their internal email handler/service/thingy), but I'm afraid a recruiter might see and start offering me gigs utilizing them. Kind of like the fact that you won't find assembly, C, C++, or BASIC on my resume. I don't want people knowing I know that stuff!
Tags: .net, work, iroh-services, consulting