it's been noticed...

§ October 1, 2009 01:22 by beefarino |

Just ignore this post, I just need to release some steam...

We just had an emergency team meeting.  The topic: it's been noticed by the executives that we're not always around when they are.  Someone needed something and one of us wasn't there to oblige.  That must have really chapped their hide.  

Well, I've noticed some things too.  Here's what I've noticed:

  • I'm VPN'ed into work at midnight fixing the build someone else broke;
  • I'm constantly tweaking our unit tests to keep them working as the rest of the team gets to plod on to greenfield pastures;
  • I'm responding to support emails at 2am;
  • I'm answering the support phone at 4am;
  • I still make the 9:30am scrum;
  • I bust my hump as a principal developer on a project, only to hear the executives single-out my superiors to praise for my work;
  • After four rounds of layoffs, I've taken on so many roles here I've lost track;
  • I haven't dropped the ball on any of my responsibilities (or if I have, no one has let me know about it);
  • I've been willing to drop my life for days at a stretch to make emergency trips to fix client issues;
  • I'm frequently the last one out the door at the end of the day;
  • I see my kids for maybe 90 minutes a day;

... and more thing I noticed: the people I work for only notice me when I'm not around.

 



Why I Hate IServiceProvider

§ February 20, 2009 09:18 by beefarino |

I've worked with a lot of code that uses IServiceProvider as a way to disconnect an object from its dependencies.  I've come to loathe this interface for many reasons and have opted for a systematic pattern of dependency injection.

First reason IServiceProvider sucks: it hides the dependencies of an object while decoupling from them.  What do I mean by that?  Pretend you're using this blackbox component from your code:

public class BlackBoxComponent
{
    public BlackBoxComponent( IServiceProvider services );
    public void DoAllTheWork();
} 

Can you tell what services are going to be requested from the service provider?  Me neither.  Now you need another way to discover what dependencies need to be available to the BlackBoxComponent - documentation, source code, something out-of-band that takes you away from your work at hand.

Compare that with some simple constructor injection:

public class BlackBoxComponent
{
    public BlackBoxComponent( IRepository< Thing > thingRepository, ILogManager logManager );
    public void DoAllTheWork();
}

With this, you know exactly what a BlackBoxComponent needs to do its job just from looking at the constructor.

Second reason IServiceProvider sucks: it adds a lot of code.  Fetching the services is cumbersome at best:

    // ...    
    public BlackBoxComponent( IServiceProvider services )
    {
        thingRepository = ( IRepository< Thing > ) services.GetService( typeof( IRepository< Thing > ) );
        logManager  = ( ILogManager ) services.GetService( typeof( ILogManager ) );
    }
    // ...

Sure you can use some syntactic sugar to work around the typeof'ing and naked casting:

public static class ServiceProviderExtension
{
    public static T GetService< T >( this IServiceProvider serviceProvider )
    {
        return ( T ) serviceProvider.GetService( typeof( T ) );
    }
}

which cleans up the code a bit:

// ...    
public BlackBoxComponent( IServiceProvider services )
{
    thingRepository = services.GetService< IRepository< Thing > >();
    logManager  = services.GetService< ILogManager >();
}
// ...

but you're still stuck having to reach out and grab every dependency you need from the service container - which implies that somewhere, some other piece of code is responsible for filling up that service container:

//...
ServiceContainer services = new ServiceContainer();
services.AddService( 
    typeof( ILogManager ),
    new Log4NetLogManager()
);
services.AddService( 
    typeof( IRepository< Thing > ),
    new ThingRepository()
);
//...

More code to write, all of it unnecessary and obsolete given the state of the art in dependency injection frameworks. 



Lack of Consistency in PowerShell

§ February 16, 2009 02:40 by beefarino |

Y'all know I love powershell.

But I'm getting pretty tired of the lack of consistency in the product.  I'm not speaking of quality here - just about how to get things done.  Case in point: at the moment I'm trying to figure out the new modules feature, which so far hasn't been difficult.  The most annoying thing is that I keep trying to get the list of available modules by typing this:

dir module:

which works for other powershell internals like variables:

dir variable:

and functions:

dir function:

but not for modules.  Why doesn't it work?  Well, those little drive-letter-type-monikers need something called a provider to enable them.  There's one built-in to powershell to enable this feature for variables and functions, but not for modules.

Not a big deal really, but one of the original selling points of powershell was its consistency - files, registry, certificates, etc., they all look like a little file system when you work with them.  So the act of adding, removing, moving, renaming these things always looks the same.  Why should I build up this expectation when it's availability is spotty?  And I'm not sure why a provider isn't managing this - modules are stored on the filesystem anyway, in a few specific places, and outside of using them you have all the basic provider operations: create, delete, rename, etc.  Having a provider around them should be a no-brainer.  The fact that one doesn't exist tells me that either it's too much effort (which having done so a few times I can say is probably the case) or goes against the grain of powershell "philosophy of use".

Oh well, it's still CTP3, maybe they'll have it in the RTM, right?  Or maybe I just don't "get" when something should have a provider and when it shouldn't.  Am I missing the point, or is this a case of powershell not eating its own dogfood?

Update

About two seconds after positing this I saw this line at the top of the Modules module.psm1 file:

# Create a drive for My Modules
New-PsDrive -Scope Global -Name MyMod -PSProvider FileSystem -Root (($env:PSMODULEPATH -split ";")[0]) 

which meets my general spelunking needs.

*sigh*

foot | mouth;


Filling Shoes and Killing Trees

§ January 19, 2009 03:09 by beefarino |

Crap.

The recession has claimed another job, and it looks like I'll be taking over documentation efforts at the office.  Unfortunately, this takes a huge bite out of my time, as we produce roughly 2000 pages of material per release.  So expect some posts about writing good technical documentation along with my latest spike notes.

*Sigh.*

Not the job I would choose by any means, but it has to get done.  Of course, it makes me wonder:

...if our last professional technical writer is dispensible, and I'm the one taking over his responsibilities,  where does that put me on the ax-list??