The Old Guard: Why Uncle Bob Is Wrong About The 40 Hour Work Week

I’m a big fan Robert Martin. I’ve read a lot of his books, and have benefited greatly.

The enterprise and business is changing; people are changing; and I want you to keep that in mind  because I don’t critique Mr. Martin lightly. Let me say, to no fault of his own, that he’s..wait for it…old guard.

In his book The Clean Coder, he makes statements about owing a certain amount of hours to your employer. I’d like to challenge this notion.

Even if you’re employer is saying that you must work 40 hours a week for them, and there’s paperwork that says that you’re making “so much” an hour, you’re really getting paid for the value you provide. That’s why some people get paid more than others–value.

It’s this thing about the forty hours that we supposedly owe to our employers. if you’re any employee (which I highly recommend against–there I said it). I’ve listened to him give presentations, read books like Clean Coder, and I decided to use him as my target on this subject: you know, to make it more interesting for you. I even think he’s slightly conflicted in his own mind. You can see it start to peek out beyond the pages of Clean Coder when we dives into scenarios where coding isn’t optimal, etc.

Okay, moving on.

Steve Jobs said once in an interview that he loved the idea of amplifying human abilities–that’s what computers did in a lot of ways. He’s talking about human abilities, right, and he starts to talk about inventions and other things that amplified our abilities. He remarked on the industrial revolution: it amplified human sweat. Think about it?

What does this have to do with a forty-hour work week?  Everything. Where did we get this notion that human beings were meant to work forty-hours and that’s what a man or woman owed to someone in exchange for there time putting effort into something?

Answer: the industrial revolution.

How else were they going to fill the factories? The white men then realized that they needed these workers to be just educated enough to control; but they couldn’t let this whole education stuff get too carried away (we can’t have these workers thinking for themselves can we?)

Their idea: lets push for a public, government run education system, yes! (I digress again).

Where was I? Back to the forty-hour thing, right.

Do you really get paid for your time?

“Well it says right here on my paycheck that I’m getting paid a certain amount per hour.”

What you have to realize is that the world before the industrial revolution didn’t think primarily on these terms. It’s an entirely new concept brought about to better standardize and monetize western societies’ human sweat.

I’m thirty-five now. I’ve realized that the most precious, the most valuable thing that you have is your time. If you’re giving it away, you’re losing your freedom.

Specifically for software engineers, like myself, we are even more advantaged to reduce the time we invest through the software we create, but the normal behavior of most, unfortunately, is avoiding the use of our mind–to think first and then act.

Azure Mobile Services: Leveraging StructureMap instead of the default Autofac

First, you want to setup the bootstrap code as usual. Contain this in a method called Activate:

public void Activate()
{
    var options = new ConfigOptions();
    var builder = new ConfigBuilder(options);
    var config = ServiceConfig.Initialize(builder);
    config.IncludeErrorDetailPolicy = _errorDetailPolicy;

    ConfigureDependencyResolver(config);
}

Next, here’s the ConfigureDepencencyResolver method:

void ConfigureDependencyResolver(HttpConfiguration config)
{
	config.Services.Replace(typeof (IHttpControllerActivator), new StructureMapHttpControllerActivator(Container));
}

Next, here’s the StructureMapHttpControllerActivator:

public class StructureMapHttpControllerActivator : IHttpControllerActivator
{
    private readonly IContainer _container;

    public StructureMapHttpControllerActivator(IContainer container)
    {
        _container = container;
    }

    public IHttpController Create(HttpRequestMessage request
        , HttpControllerDescriptor controllerDescriptor, Type controllerType)
    {
        var nestedContainer = _container.GetNestedContainer();
        request.RegisterForDispose(nestedContainer);

        return (IHttpController)nestedContainer.GetInstance(controllerType);
    }
}

Microsoft’s MCSD is (mostly) useless (and 5 alternatives)

Certifications by Microsoft (almost) don’t prove anything, nor do they really benefit you. In fact, the more people get these certifications, the more worthless they become. It’s like inflation where the money supply is so high that it’s not worth the paper it’s printed on.

Here are 5 alternatives:

  1. Write code
  2. Read 10 books that are at least 10 years old in the computer science field
    Most ideas are recycled over and over, and they’re also forgotten. Do this and you’re ahead.
  3. Read blog posts
  4. Do Kata exercises, one per week, and vary around technology you don’t know
  5. Pick at least 1 programming language NOT created by Microsoft, and create a hello world

How do Ninject Modules benefit me?

The Preface

I was recently on a project where one of the developers decided to use Ninject as the IoC framework. Notice I said framework because it calls INTO your code, whereas a library doesn’t; but I digress.

Anyway, so I added a NinjectModule to the library, added some dependency definitions to it, and committed it to TFS (a whole other problem).  All is well.

Well not so well. I get an email a few minutes later questioning why I’m doing such a thing as adding a NinjectModule.  I thought for a second–I had gone for a walk around the block to rest my eyes, and began emailing back; the response?  Still confusion. It was then and there that I decided that I was wrong about something. I took for granted that “senior engineers” understood why and how Dependency Injection containers worked.  I brushed off my frustration and started typing.  This is what I wrote, and maybe (I’m not really confident about it) this will help some other person.

The Explanation

Ninject (and other almost all DI frameworks) have an IoC container implementation that’s called something…for Ninject it’s the Kernel.  In principle there is a single Kernel (IoC container) at runtime (almost always, but that’s another story).

What a NinjectModule does is act as a registry for dependencies.  The principle behind it is encapsulation of higher order implementations, and for components to depend on abstractions. The assembly/component is saying, “Hey you module/component that want to reference me, don’t worry about how “IAmAContract” is implemented (an interface I’m exposing as public), just ask for it, and I’ll make it happen”. The assembly provides a public module (a NinjectModule), which in effect is saying, “Hey I’ve got stuff you want, so add it to your Kernel (IoC Container) without knowing exactly what’s implementing what you want”.

So at runtime in the component that’s one-to-one with the Process, the IoC container is configured, and in Ninject’s case, we’ll tell it to either scan the assemblies in the bin for NinjectModules, or explicitly add them.  When this happens, the NinjectModule’s bindings (for this type, use this type) get added to the IoC container, i.e. the Kernel.

In practice this lets us make implementations of a public contract, for example an interface in C#, internal to the owner (in this case, some library we’re building) without the consumer ever having to know or have access to the implementation.

StructureMap 3 You don’t need HttpContextScoped()

For the new version of StructureMap (v3), there’s a nuget package StructureMap.MVC4. When you install the package it will add the resolver and the dependency scope for you. Before this package you may have had to call HttpContextScoped() method on your type assignments–not anymore.

The code in the dependency resolver will create a nested scope, which will get disposed of after the ASP.NET MVC (or WebAPI) pipeline is complete.


IContainer child = this.Container.GetNestedContainer();

Helping people solve technical problems

I’m currently listening to the Coaching Architect presentation that Roy Osherove gave last year, and it led me to this the 5whys.com website and his post 3 Reasons to stop solving other people’s problems for them. I’m still chewing on this to be honest. I come from a background where didactic teaching is the choice of style. However, I’m realizing that the majority of people in today’s society don’t actually have the reasoning skills to ingest the information and form a pattern to reason about.

Leadership is definitely the act of coaching and educating people, and growing them to solve their own problems. You also have to be flexible with your approach. There are different personalities. I’m very independent and self-driven, and other people are more passive.

Know The Cost

If someone tells you that you’re code isn’t efficient because you have too many methods, and you’re writing for the .NET framework, know that you’re on the right side. I had this happen to me this week.

“Although there is a small delay for JIT compilation of each method as it is first called, every method called runs pure native code with no interpretive overhead.” – http://msdn.microsoft.com/en-us/library/ms973852.aspx

It’s well documented, and the penalty is so tremendously inconsequential, if you’ve given it thought: stop. We’re talking fractions of a nanosecond, here.

Write readable code where the intent is expressed clearly and simply. Do that first and foremost; let that be our concern if we’re writing code. There are many, many more things to be concerned about when it comes to performance. If you need that level of performance, code in an assembly language.

Getting Started With DDD Surrounded by Legacy

This is a great read from Eric Evans.  The majority of designers deal with legacy the majority of the time, and getting from the DDD source himself has tremendous value in its practical understanding of businesses, development teams, and adopting new development styles.

“Introducing a difficult new set of development principles and techniques is best done incrementally, as in a pilot project, in a way that allows members of the team to gain experience and allows the organization to assess the approach…” — Eric Evans

Tips for Async Libraries in C# and Methods That Lie

Lucian Wischik, a Program Manager on the Microsoft languages team, did a great job on creating async libraries. The main lessons of his talk cover:

  • Libraries shouldn’t lie
  • Use ConfigureAwait(false)
  • Optimize (if necessary)

I really liked his point that library methods shouldn’t lie, and I wanted to focus on that generally as a development practice.  While he’s specifically covering asynchronous programming, I’ve found this to be one of the most common problems reading code.  So often I see methods that just flat out lie.

I think there are the two big categories of lying methods. here they are:

  1. The pathological liars
    The method just flat out lies about what it does. This most often occurs when it’s changed over time and the developer’s never bother refactoring the method either into different methods, or not updating the name (if it’s still has a single responsibility. Most often, no).It’s possible that this happens immediately.  You must think through why you’re doing something. In Lucian’s talk, he makes it clear that you need to have knowledge about threads, TPL, and async to create async methods.For example, say you’ve got a method that says “IsAuthorized”. It takes some arguments that represent a security context. You’d expect it to return a result saying, “Hey, you can’t do that!”, or “Hey, you can!”.  In fact, the method returns false immediately, does a Bus.Send, and somewhere down the line there’s another bit of code off somewhere, tucked away, that handles the result.  If the “IsAuthorized” method is actually doing this, it would be better to name the method “SendRequestForAuthorization”.
  2. Over achievers
    Anytime you see a method that you wrote and it’s handling multiple responsibilities but says (in its name) that it’s doing one thing, then it’s over achieving.DO NOT try and fix this with a conjunction, resulting in a method that says, “Hey, I do this…AND this….AND this…AND.”, you get the picture.

So the next time you’re done writing a method, ask yourself if it’s an honest method.

StructureMap Registry Convention – How To Find Specific Registries

In StructureMap’s default assembly scanner, there’s a LookForRegistries method.  What exactly does this do?  Well, all it does is eventually call Convention<T> using the default registry convention build into StructureMap.  The interface is IRegistrationConvention–easy enough.

Since in my case, I wanted to use a marker interface for the registries that I wanted my container to pull in, I first defined that.


    ///
    /// Marker interface for registries that contain security DSL configuration
    ///
    public interface ISecurityRegistry
    {
    }

I still like the explicit nature of the LookForRegistries method, so I then created an extension method for the assembly scanner.


internal static class AssemblyScannerExtensions
{
/// &lt;summary&gt;
/// Looks for registries using the registry convention specified
/// &lt;/summary&gt;
/// &lt;typeparam name=&quot;T&quot;&gt;The type of registration convention&lt;/typeparam&gt;
/// &lt;param name=&quot;scanner&quot;&gt;The scanner&lt;/param&gt;
public static void LookForRegistries&lt;T&gt;(this IAssemblyScanner scanner) where T : IRegistrationConvention, new()
{
scanner.Convention&lt;T&gt;();
}
}

Next, I defined my convention. Now, I did look at the default registry convention, and used some of simple type checks so the convention could easily knockout types that weren’t registries.


    ///
    /// Custom registry convention that will only import in registries that are marked with
    ///
    internal sealed class SecurityRegistryConvention : IRegistrationConvention
    {
        public void Process(Type type, Registry registry)
        {
            if (IsSecurityRegistry(type))
            {
                registry.Configure(x =&gt; x.ImportRegistry(type));
            }
        }

        private bool IsSecurityRegistry(Type type)
        {
            if (type.Assembly == typeof(Registry).Assembly)
            {
                return false;
            }

            if (!typeof(Registry).IsAssignableFrom(type))
            {
                return false;
            }

            if (!typeof (ISecurityRegistry).IsAssignableFrom(type))
            {
                return false;
            }

            if (type.IsInterface || type.IsAbstract || type.IsGenericType)
            {
                return false;
            }

            return (type.GetConstructor(new Type[0]) != null);
        }

    }

Finally, my container used the convention with the extension method. You don’t want to call LookForRegistries since that will end up using the default registry convention, and you’ll end up getting registries that don’t have the marker interface.

I think it came together nicely.

var container = new Container(c =>
{
	c.AddRegistry<DefaultRegistry>();
	c.Scan(s =>
	{
		s.AssembliesFromApplicationBaseDirectory();
		s.LookForRegistries<SecurityRegistryConvention>();
	});
});
return container;
« Older posts

© 2015 Kevin Hillinger

Theme by Anders NorenUp ↑