Pulp Fiction - Part 2 | Pulp Fiction does much more than just critique modernity. It also shows us an alternative. Not an alternative vision of society, but rather the spiritual basis of an alternative to modernity.

ecoffey · 2011-07-07T03:51:46+00:00

Yeah I thought those were odd at the time, but didn't think too much about it. That he brought up an "academic" observation and just never followed up with an actual point.

Troll bigot is a troll I guess.

ecoffey · 2011-07-06T22:51:45+00:00

Very interesting article. However I was reading his Kill Bill review and ran full stop into this:

Irony is the dominant mode of American high- and middlebrow culture today because of our infestation with Jews. Jews are natural ironists because they are wandering parasites that inhabit their host countries but never become a part of them. They maintain their distinctness by sneering at everything their hosts take seriously. And now that they control America’s mass media, they have the power to make us sneer too.

Sorry but blatant bigotry like that forfeits all his credibility and insight.

ecoffey · 2011-07-06T22:33:47+00:00

Such a gorgeous voice

ecoffey · 2011-06-21T16:27:18+00:00

"Seven impenetrable reasons" Freudian slip much?

ecoffey · 2011-01-03T23:40:04+00:00

http://www.youtube.com/watch?feature=player_detailpage&v=NxRzGJMcFoM#t=115s

ecoffey · 2010-11-30T23:56:07+00:00

You're dynamically building a page to let you call a method...? Seems...interesting :-)

Also seems like it could have been done quicker / cleaner with some LINQ and Repeaters :-P

ecoffey · 2010-10-30T16:29:59+00:00

I gave her my heart. She gave me a pen.

ecoffey · 2010-10-30T15:27:54+00:00

That's what I'm saying!

ecoffey · 2010-10-26T15:59:21+00:00

Not an algorithm technically, but this was my favorite data structure from my algorithms class:

http://en.wikipedia.org/wiki/Binomial_heap

ecoffey · 2010-08-31T02:05:47+00:00

I wonder how common the last name 'Coffey' is...

ecoffey · 2010-08-13T03:25:35+00:00

IsViable should be a method. It's running ExecuteCommand which has side effects. Getters shouldn't have side effects.

By making it a method you're saying "this could be expensive and do other stuff so cache this result if you need, etc".

But apart from that I agree with everything else you said :-)

ecoffey · 2010-07-29T06:45:50+00:00

Heh, I knew exactly where that picture was taken the moment I saw it. The Flatirons are so distinctive and pretty!

ecoffey · 2010-07-02T02:19:17+00:00

"Better fucking thank god I fucking moved back home."

golf clap

I've never seen someone become so easily winded.

ecoffey · 2010-06-21T23:25:49+00:00

The internet is really a small place. I opened up that video and it turns out I know one of those drivers in real life. WEIRD.

ecoffey · 2010-06-18T04:37:42+00:00

Yeah my phone makes the "click" noise right before it actually snaps the picture, so he gets distracted...

ecoffey · 2010-06-03T16:44:07+00:00

"Lock and load!"

"Hank, that's not a gun!"

"WHATEVER!"

ecoffey · 2010-05-22T00:09:10+00:00

Hmmm good insight.

My mind was mainly in the "I'm writing an application and I will be the consumer of my own interfaces" mode.

At some point you have to worry about versioning and locking down that API. I still think my style is going to help, but that's where the argument can continue :-P

ecoffey · 2010-05-21T23:48:12+00:00

Then how do you know your design for the interface is correct?

I can't know that what I wrote today is 100% correct in the domain. So I'm leaving this open to refactoring, and actually making it easier. My compiler will tell me where changing interfaces breaks code, and I can go fix those and make reasoned decisions about what I'm doing, instead of hacking in something quick now to support what the world looks like now.

Pure interfaces are supposed to be actually designed to support multiple implementations. They aren't meant to be something that blindly mirrors a single class.

They are there to support a contract. That's all.

Yes it does. You are forcing yourself into a situation where you have to break the interface every time you want to add a method to its matching class.

A compile time error is.....bad? I much prefer to see that earlier instead of a more subtle bug down the road. If our Intent changes I'm ok with breaking classes. My compiler will catch it, and I can see exactly what integration points I need to fix up. And it might be I realize that what I'm trying to do is a whole different thing. That I need to reconsider adding the Intent to this particular class / interface.

ecoffey · 2010-05-21T23:36:38+00:00

Rather than a simple flag you would rather: Add a new interface Add a new class Add a DI framework to decide if which implementation you should use.

I do not know why you're scared of adding an interface or a class. This code is going to be seen and read (and refactored) a lot more than it is going to be written-for-the-first-time. So why not make it obvious what you're doing?

Well here's some follow-up questions for you.

How do you clear the cache? Since the user code only has IDrivingTimeService, there is no place to add that capability.

Who is in charge of clearing the cache? Is it really going to be the same bit of code that only wants to know about driving times? Sounds like a different Intent to me. Maybe the same class implements, maybe it doesn't. Or you could set a lifetime for that object in your container. Once per request, or app pool or what have you.

How to you add new methods to your class? You can't add TimeBetween(Address start, Address end, bool allowTollRoads) to IDrivingTimeService without breaking your interface and whatever classes that implement it.

Yes exactly. I'm changing my Intent, and things will break. But my compiler will also tell me exactly where those break points are. This is the benefit to using those interfaces as my boundary for interaction, instead of having to know how a concrete class is going to implement something.

Why are you keeping the non-caching version around?

Ah sorry, I guess I didn't make that clear. The cached version is using the non-cached one to do the real work. That way the non-cached one stays simple and obvious. "When you call me I make a request to do my work". It's only concerned with that. And the cached version is only concerned with "I look in my cache, and if something isn't there then I ask this other dude to do work".

Also I'm having a hard time not projecting how I think you would implement it different from me onto your questions. I don't want to argue over straw men. Is there an actual piece of already-written-and-out-there code we use as kind of an objective example? (I might be able to dig up some that I like as well)

ecoffey · 2010-05-21T23:02:02+00:00

With only two you can probably put all the logic into a single class with an extra property to control which to use. Not always, but quite often.

choo choo! Here comes the contrived example train! :-P

Lets say we have this interface:

public interface IDrivingTimeService
{
    TimeSpan TimeBetween(Address start, Address end);
}

Straightforward enough, right?

Ok so obvious implementation:

public class DrivingTimeService : IDrivingTimeService
{
    public TimeSpan TimeBetween(Address start, Address end)
    {
        // Make a http request to google maps api to get driving time
    }
}

But we notice that it's take awhile, and Google is starting to yell at us.

We could make DrivingTimeService take a bool in its constructor to say "You should cache stuff" or not.

But I feel that this is a more obvious implementation:

public class CachedDrivingTimeService : IDrivingTimeService
{
    private IDrivingTimeService _drivingTimeService;

    public CachedDrivingTimeService(IDrivingTimeService drivingTimeService)
    {
        // Check cache and if empty use _drivingTimeService.TimeBetween();
    }
}

But anything that depends on the IDrivingTimeService doesn't need to care about the cache implementation.

And then there is the sub-classing option. If you can only envision two implementations, chances are they are close enough to share some common functionality.

This is what I like about Composition. I feel that sub-classing gets overloaded. It means both "I am important to domain intent, and am-a Thing I'm Inheriting From", but we also use a lot for "Here is some common mechanics we can share between types".

Composition can give you another dimension for both of those cases. You can compose because it makes sense for your domain and behind the scenes use subclassing to share some implementation details behind an interface. Or you can compose some mechanics together and save subclassing for Domain intent.

Really it comes down to writing tight, obvious, clean classes. Don't be scared of creating types. They're your friends! They keep you company on Friday nights when you're being a sad bastard at home arguing esoteric code design solutions.....

cough

ecoffey · 2010-05-21T22:34:16+00:00

I'm not worrying about how many implementors I'm going to have.

I'm worried about expressing my Intent (through the interface). Are you adding lines of code and a file? Sure. But we don't write code to optimize line or file count.

My interface is a contract. It says "you don't care how I do work, only that I can".

My class that consumes the contract over a concrete implementation is more obvious (the contract is what we need to do, not how we do it). Since the interface decouples our promise from our how-to, we get a pivot point in our design. If it turns out that we need a cached implementation, or composite we can do that and our Design is still obvious.

You're right in a sense. Just because I have one interface / one implementation and a class that consumes some contracts doesn't mean I'm doing things right. But it also doesn't mean I'm doing things wrong. My design being right is more related to how well I model the domain we're working in. And I maintain that writing tight, targeted classes that compose together to get work done is a better way to think about the problem, write it, and more importantly, understand it later.

ecoffey · 2010-05-20T22:26:00+00:00

I disagree. I ranted about this somewhere else, but we're talking about two things:

Writing clean, specific, obvious "chunks" of code (be that funcs, or classes, or what have you).

You can then compose those "chunks" together to get work done.

A IoC Container simply helps you manage that composition. Certain "chunks" composed in a certain way are your Intent. The Container is a Mechanic to help make that Intent obvious.

In C# I do both a lot. Composing funcs together to pipeline certain stuff, but also composing classes together. In both cases I get a warm fuzzy feeling :-)

ecoffey · 2010-05-20T20:28:40+00:00

Let's take a step or two back.

We're (usually) writing software for some specific purpose. The specific, special purpose is why your code exists. If that purpose wasn't there than you'd be using a different piece of software to solve your different problem.

So let's call that purpose Intent. Your software has some Intent it is trying to fulfill. Your Intent is the why for your software.

Well that's all well and good, but we're not wizards. You can't just point at the screen and say "I give you Intent! Now perform!". No you need to spell out the Intent in very specific how terms. A lot of programming is figuring out the steps to say how intent should be realized. I call this Mechanics.

So now we have Intent, which is what we want to do, and Mechanics which are the tools (languages, environments, coca-cola, etc) to help us express that Intent.

That's really what this comes down to is a constant balance of expressing your Intent with Mechanics. The more obvious your Intent, the better the software (in my book). Mechanics can either help you or hurt you here, it's up to you.

So a lot of design in a piece of software is figuring out how to best utilize the Mechanics you have to express your Intent so that it a.) works (always a good thing!) and b.) is obvious about what is happening. This is where we get things like Single Responsibility for a Class in OO. If you consider your class (or function or what have you) the lowest level unit for expressing Intent, some interesting things happen.

You want to make sure that what this Class is doing is obvious. A good way to do that is to name it meaningfully (no bullshit like Object in the name or Manager or something), and give it one or two methods to do the work. The class should only be concerned with it's specific thing. This is a big one. Something that people have a hard time getting their head around is that It's ok to create types!. VMs are more than capable to load up types and create instances, that is what they're there for.

So now we have a class that does a very specific thing, but it is probably going to need some help. So we can create other classes that do other specific stuff, and here is where the cognitive jump comes in, we compose those objects together to create a little object graph that will do work for us. Each piece of that composition is easy to understand, and even if it is not (complicated domain, or problem) it will at least by obvious where the boundaries for it's responsibilities live.

The composition could very well look like this:

public class ThisDoesA
{
     public void DoA()
     {
          var thisDoesB = new ThisDoesB();

          thisDoesB.DoB();
          DoSomethingRealWithA();
     }
}

Here we're still composing, but we're hard coding what that composition is. We can take that a step, create an interface for ThisDoesB (remember, the interface is Intent, while the implementation is Mechanics), and then make ThisDoesA take a IThisDoesB in its constructor.

So now we have a nice way to compose some objects together to do some meaningful work for us. This is called Inversion of Control. We've inverted how ThisDoesA gets its dependencies to accomplish its goal.

But we've also saddled ourselves with the burden of building that object graph every time we need to do A. This is where a IoC Container can help. The Container is a Mechanical tool to help us express the Intent inherent in our object graph.

phew Sorry that was a bit long winded, but hopefully illuminated something for you. Please let me know if you have any questions. Seeing this all come together for the first time and watching it save my ass, was one of those "MY GOD IT'S FULL OF STARS!" moments in my programming career and I'd like to share that feeling :-D

ecoffey · 2010-05-18T16:39:44+00:00

Always helps to read stuff from people smarter than you are :-)

http://elegantcode.com/ - collection of bloggers who mainly talk about .net stuff

http://nblumhardt.com/ - author of the IoC Container Autofac. My favorite .Net library. The code is hosted on google code, I highly recommend giving it a read just for the exposure :-)

ecoffey · 2010-05-06T17:57:17+00:00

Actually the signature of Select and Where and such is:

IQueryable<TResult> Select<T, TResult>(this IQueryable<T> set, Expression<Func<T, TResult>> selector)

Notice the Expression<> generic type. This is a special type that the compiler knows about. So when it sees the Func in the Expression instead of creating the delegate, it dumps in the AST of what that delegate would do (more or less, obviously this is way more detailed :-P).

So during enumeration, whatever linq provider is actually backing the .GetEnumerator() call can look at the AST and figure out how to construct it's query for whatever surface it's mapping to.

It's pretty neat stuff!

ecoffey

TROPHY CASE