Powershell: testing string length validations

Every time I do this it makes me smile.

If you write apps that have input fields that have max lengths that are validated, then occasionally you may need to test your validations.  I used to do this by typing "this is a really really really long string that should break the validations" and the copying and pasting that over and over until I thought I'd gotten it long enough to exceed the max length.

Now I just switch over to powershell (which I always have conveniently open and ready) and I type:

"quite long" * 100 | clip.exe

"quite long" just happens to be exactly 10 characters long, so this generates a string which is 1000 characters long that looks like "quite longquite longquite long..."  Piping that string to clip.exe saves it on your clipboard. Now just paste into the field you want to test and you're all set!

Insight in Plastic Containers

Two simple small plastic containers.  The one on the left is a considerably better design:

• They nest inside each other because of the tapered shape
• The base of the container snaps into the top of the lid
• The lids snap into each other

I love examples of good design like this, but that's not why I took this picture!  

On the one on the left, see how the lid is facing down and the container fits on top of it, like this?

We have way more left-type containers and only a couple right-types.  The right-types don't fit into each other, and the lids don't snap on the bottom, so there isn't any great way to store them.  I usually just stuff 'em in the cabinet.  But today I opened the cabinet door and noticed the lid on the right-type as in the photo:

FLIPPED!  It's facing up instead of down, and the container nests relatively nicely inside it.  I couldn't help but smile at this!  

I have been fixated on the lids facing down because we have many more of the left-type containers, the idea of simply flipping the lid never occurred to me.  It's wonderful to reflect on the insight of just flipping the lid around.  A terribly simple idea that has been there all along, but I never saw it.  

An admittedly silly example of lateral thinking... Or maybe it's not really lateral thinking, maybe it's just closed mindedness through familiarity.  But in any case, when I saw it today it made me go "neat!"

POODR's Duck Types

I recently read Practical Object-Oriented Design in Ruby by Sandi Metz.  It's a really wonderful book.  I can say without any hesitation it has made me a much better Object-Oriented programmer.  I honestly wish I could have read this 12 years ago when I was first learning an Object-Oriented language.

Although the book is totally focused on Ruby, the OO practices it presents are easily applicable to other OO languages, including static languages like C#.  This makes it one of those timeless books you can be happy to have on your shelf knowing it's not going to be outdated in a year.  I highly recommend it!

I intend to write a few posts highlighting some of the good ideas that struck me the most from this book, but in this post I just can't help but take a few shots at it's treatment of static vs. dynamic languages.

My programming language lineage started by dabbling in C, then taking classes in C++, followed by Java, and finally C#.  Most of the real world code I've written has been in static languages, and I've been programming professionally in C# for the last 8 years.  This makes me a static language guy.

When I learned ruby, about 5 years ago, I fell in love with it's clean syntax and amazing flexibility.  I wrote a few simple tools in it for work, and I've written alot of rspec/capybara tests, plus I dabbled a bit with Rails.  I feel I have a decent understanding of the language, but I'm by no means an expert and I definitely still think in classes and types.

I tell you this to explain where I'm coming from.  Static languages are what I know best and are what I'm used to.  I'm not a dynamic language hater, I'm just comfortable with static langs.  Which brings us back to POODR.

POODR talks a lot of about "Duck Types" which are defined in the book as:

Duck types are public interfaces that are not tied to any specific class.  These across-class interfaces add enormous flexibility to your application by replacing costly dependencies on class with more forgiving dependencies on messages.

I was surprised at this definition because it describes the "Duck type" as being a thing, but in Ruby there is no thing that can represent this across-class-interface.  Most treatments of duck typing from Rubyists I've seen usually just talk about how it's a feature of the dynamic nature of the language.  They talk about "duck typing" but not "duck types."

In C# we have interfaces, which can be used as explicitly defined duck types.  The Dependency Inversion Principle and the Interface Segregation Principle are both trying to get you to use interfaces in this way, instead of just as Header Interfaces.  It's good OO because it focuses on messages instead of types.  As POODR says, "It's not what an object is that matters, it's what it does."

I think there is a lot of power in Ruby's implicit "duck types," but I also think the lack of explicit interfaces is a serious liability, and I was very entertained by how many hoops POODR jumps through to try to work around this problem, all while trying to claim that it isn't a problem at all, and in fact, it's great!

At the end of Chapter 5, there's a section that tries to convince you that Dynamic typing is better than Static typing.  Unfortunately, it just builds up a straw man version of static typing to make it easier to tear down.  What it leaves out is interfaces:

Duck typing provides a way out of this trap.  It removes the dependencies on class and thus avoids the subsequent type failures.  It reveals stable abstractions on which your code can safely depend.

If statics langs didn't have interfaces, this might be true.  But they do have interfaces!  And worse, interfaces represent a significantly more stable abstraction that is dramatically safter to depend on than these invisible "duck types."  POODR demonstrates this itself with examples where the "duck type" interface changes, but not all "implementers" of the interface are updated.  There's no compiler to catch this.  And standard TDD practices wont catch it either.  Your tests will be green even though the system doesn't work.  So you have to write manual tests that you can share across all the implementers to make sure the message names and parameters stay in sync.  Nearly all of Chapter 9 is devoted to testing practices that simply wouldn't be needed if there was even just a rudimentary compiler that could verify just inheritance and interface implementations.

The lack of explicit "duck types" just seems so problematic to me...  Keeping them in sync is a chore, and a potential source of error.  The worst kind of error too, because the same code may work in one context but break in another based on which "duck type" is used.

Another problem I've run into is when trying to understand some code that takes in a "duck type", how do you figure out the full story of what will happen?  How do you find all the implementers of that "duck type"?  Just search your code base for one of the method names?  Try to find every line of code that injects in a different duck type?

Not being able to surface an explicit interface leaves you stuck in a situation where you have to infer the relationship between your objects by finding every usage of them.  Seems like a lot more work, as well as being a recipe for tangled and confusing code.

So what do you think Dynamic language people?  Am I making a bigger deal out of the problems of dynamic typing just as Sandi made a bigger deal out of the problems of static typing?  Is this just a lack of experience problem?  Do you just not run into these issues that often in real world usage?

UPDATE 2/20/2013:
Here's an interesting presentation by Michael Feathers about the power of thinking about types during design.  I felt like it had some relevance to the conversation here.

In The Midst of Wonders

"Where the uninformed and unenquiring eye perceives neither novelty nor beauty, he walks in the midst of wonders" - John Hershel, from The Age of Wonder, originally from A Preliminary Discourse on the Stud of Natural Philosophy

Custom and Example

"I thus concluded that it is much more custom and example that persuade us than any certain knowledge, and yet inspite of this the voice of the majority does not afford a proof of any value in truths a little difficult to discover, because such truths are much more likely to have been discovered by one man than by a nation." - Rene Descartes, Discourse on Method and Meditations

The Basics

Some body I follow on twitter retweeted this tweet from Tim Ottinger:

The reason for writing a function is not to reuse its code, but to name the operation it performs.
— Tim Ottinger (@tottinge) January 22, 2013

My first pompous thought was something like, "how obvious."  I was about to go back to work when a memory hit me out of no where.  I remember very early in my career F5-hacking on some code and thinking about creating a method but worrying about not reusing it, or about someone else reusing it incorrectly, or about the extra lines of code the added syntax would add to my already 1000+ line Windows Form class.

I remember programming like that.  There was a time, not long ago, when I didn't think I should extract a method unless I meant to use it more than once!  And it's weird because I don't remember having the epiphany that took me from where I was then to where I am now.  I once thought A, I now think B, and I don't remember changing my mind.  It's an interesting lesson in the way the mind works.  And it reminded me that everyone was a newbie once, and that most likely, I still am a newbie I just haven't figured it out yet.

Slicing Concerns: Implementations

In Slicing Concerns And Naming Them I posed a question about how to go about separating different concerns while still maintaining a clean and relatable code base.  Some interesting conversation resulted, and I wanted to follow up by investigating some of the different approaches to this problem that I'm aware of.

Inheritance

public class Task : ActiveRecord
{
  public string Name { get; set; }
  public int AssignedTo_UserId { get; set; }
  public DateTime DueOn { get; set; }
}

public class NotificationTask : Task
{
  public override void Save()
  {
    bool isNew = IsNewRecord;
    base.Save();
    if (isNew)
      Email.Send(...);
  }
}

public class TasksController : Controller
{
  public ActionResult Create(...)
  {
    ...
    new NotificationTask {...}.Save();
    ...
  }

  public ActionResult CreateWithNoEmail(...)
  {
    ...
    new Task {...}.Save();
    ...
  }
}

This works, and the names are reasonable. But of course, inheritance can cause problems... I wont go into the composition over inheritance arguments as I assume this isn't the first time you've heard it!

Decorator

public class Task : ActiveRecord
{
  public string Name { get; set; }
  public int AssignedTo_UserId { get; set; }
  public DateTime DueOn { get; set; }
}

public class NotificationTask
{
  Task task;

  public NotificationTask(Task t)
  {
    this.task = t;
  }

  public void Save()
  {
    bool isNew = t.IsNewRecord;
    t.Save();
    if (isNew)
      Email.Send(...);
  }
}

public class TasksController : Controller
{
  public ActionResult CreateTask()
  {
    ...
    new NotificationTask(new Task {...}).Save();
    ...
  }
}

This is not really the decorator pattern... At least not as defined by the GoF, but I have seen it used this way often enough that I don't feed too terrible calling it that. Really this is just a wrapper class. It's similar to the inheritance approach, except because it doesn't use inheritance, it opens us up to use inheritance on the Task for other reasons, and apply the email behavior to any kind of task.

The naming is a bit suspect, because NotificationTask is not really a task, it just has a task. It implements only one of the task's methods. If we extracted an ITask interface we could make NotificationTask implement it and just forward all the calls. This would make it a task (and a decorator), but would also be crazy tedious.

Service

public class Task : ActiveRecord
{
  public string Name { get; set; }
  public int AssignedTo_UserId { get; set; }
  public DateTime DueOn { get; set; }
}

public class CreatesTask
{
  Task task;

  public NotificationTask(Task t)
  {
    this.task = t;
  }

  public void Create()
  {
    t.Save();
    Email.Send(...);
  }
}

This service represents the standard domain behavior for creating a task. In an edge case where you needed a task but didn't want the email, you would just not use the service.

The naming is pretty nice here, hard to be confused about what CreatesTask does... However, this path leads to a proliferation of <verb><noun> classes. In the small it's manageable, but as they accumulate, or as they start to call each other things get confusing. For example, if you know nothing about Task and you have to start working on it, would you know you should call the CreatesTask service? Would you know it exists? And would you be sure it was the correct service for you to be calling?

Dependency Injection

public class Task : ActiveRecord
{
  public string Name { get; set; }
  public int AssignedTo_UserId { get; set; }
  public DateTime DueOn { get; set; }

  INotifier notifier;

  public Task(INotifier notifier)
  {
    this.notifier = notifier;
  }

  public override void Save()
  {
    bool isNew = t.IsNewRecord;
    t.Save();
    if (isNew)
      notifier.Send(...);
  }
}

public class TasksController : Controller
{
  public ActionResult Create(...)
  {
    ...
    new Task(new EmailNotifier()) { ... }.Save();
    ...
  }

  public ActionResult CreateWithNoEmail(...)
  {
    ...
    new Task(new NullNotifier()) { ... }.Save();
    ...
  }
}

I'm going to ignore all the complexity around the fact that this is an ActiveRecord object which the ActiveRecord framework will usually be responsible for new-ing up, which makes providing DI dependencies difficult if not impossible...

The idea here is to pass in an INotifier, and then when you find yourself dealing with a task you'll build it with the notifier you want it to use.  If you want no notification, you use the Null Object pattern and pass in an INotifier that doesn't do anything (called NullNotifier in the code example).

But this has the ORM-framework draw back I mentioned above.  Plus it requires the code that is constructing the task to know what behavior the code that is going to save the task will require.  Most of the time that's probably the same code, but if they aren't, you're out of luck.

Operational vs Data Classes

public class TaskInfo
{
  public string Name { get; set; }
  public int AssignedTo_UserId { get; set; }
  public DateTime DueOn { get; set; }
}

public class TaskList
{
  public TaskInfo Create(TaskInfo t)
  {
    t.Save();
    notifier.Send(...);
    return t;
  }
}

Here I've separated the data class from the operational class. I talked about this in the Stratified Design series of posts.  This separation hides ActiveRecord, giving us the control to define all of our operations independently of the database operations they may require.  If we needed to save a task without sending an email we could just call TaskInfo.Save() directly from whatever mythical operation had that requirement.  Or we could do some extract method refactorings on the Task.Create method to expose methods with just the behavior we need.  Or we might extract another class.  Naming is going to be hard for these refactorings, but at least we have options.

If I missed anything, or if you see an important variation I didn't think of, please tell me about it!  As always you can talk to me on twitter, and you can still fork the original gist.

Slicing Concerns, And Naming Them

Naming is hard.  Especially in OO.  To name something, you have to understand it at it's deepest level. You must capture it's true essence.  This is hard when you're giving a name to a thing that already exists, but it's orders of magnitude harder when you're simultaneously creating the thing out of thin air, and trying to decide what to call it.  Which is after all what we do when we're designing code.

The "essence of things" correlates closely with concepts like Separation of Concerns and the Single Responsibility Principle.  You can slice any object into ever smaller concerns or responsibilities.  You can slice it right down to it's constituent atoms!  Many design problems, like tight coupling and loss of flexibility, are in large part due to having concerns and responsibilities defined at too high a level.  Could this be so common simply because it's so hard to find names for the smaller concepts?  It's frequently easy to see what those separate concepts may be, but terribly hard to think what to name them!

Let's have an example:
This is entirely fictional code, but it's not so different from a lot of real code I've seen in the wild. And it illustrates this problem of slicing concerns very well.

At first glance, it seems very simple. The domain has a Task concept which has a default due date (set in the constructor), and which sends a notification email after it's inserted (using an ActiveRecord hook).  This very nicely and completely describes what a task is and how it behaviors in our system.  And the names make it very intuitive.

Or do they?  Is it really the case that every single time we insert a task in the database it should send an email?  Unlikely.  We should slice that behavior out and put it somewhere else:

public class _WhatShouldThisBeCalled_
{
  public class _WhatShouldThisBeCalled_(Task t)
  {
    t.Save();
    Email.Send(t.AssignedTo_UserId, "New Task", "You have been assigned a new task");
  }
}

This is an incredibly simple refactoring, but I have no idea what this class should be called. The method is a bit easier, it could be InsertAndNotify(Task t) or something similar. But what is this class? What concern does it represent?

No, really, I'm actually asking you.  What would you call it?

Or how else would you write it?  Maybe you'd do something like a fire an event and have someone hook it?  How would they hook it?  Maybe we need an EventAggregator?  This is getting awfully complex for such a simple requirement!

And it's not done, because it's not really so great that it defaults the DueOn date in the constructor.  Is every single task really due tomorrow?  Or is it just a certain kind of task, or tasks created in a certain way?  And where will we put that code, what will it be called?

I sincerely believe this is both a significant design problem, and a significant naming problem.  I want to know how you'd tackle it.  Please do leave a comment or tell me on twitter or even better, fork the gist on github!

These concerns need to be separate!  But what a cost we pay for it!  The simple OO domain model of a Task has turned into something much less relatable.  Either it's event driven spaghetti code with strange infrastructure objects like EventAggregators.  Or it's a hodge-podge of service or command classes, none of which actually model a relatable thing...  They only model functions, features, behaviors, use cases.  Or maybe we try applying inheritance, and then we end up in a whole different world of confusing names and surprising behaviors.

Can't we do better?  Is there some way we can do the slicing of concerns we need but still maintain the modeling of real relatable things?  Even if that may require a different way of thinking or not using the design patterns that led us here (Active Record, in this case).

The Fundamental Software Design Problem

The most fundamental software design problem, that this the the most important problem which underlies all design decisions, is:

Choosing the right amount of abstraction

Say you're starting a brand new project that you don't have any previous experience with.  What sort of architecture should we apply?  We have a lot of choices, some listed here, ordered in increasing complexity:

• SmartUI
• MVC w/ Active Record
• Ports and Adapters
• SOA
• CQRS

For some problems just a glance is enough to know it needs a more abstract and complex solution.  Equivalently, some problems quite clearly should be as simple as possible.  But most problems lie somewhere in between.  And generally there's really no way up front to know exactly where on the complexity scale it will lie.

Worse still, in a large enough application different portions of the application might be more or less complex.  Some areas could be simple crud with no logic, while other areas involve heavy data processing and complex workflow and queries.

And even worser, this is a moving target.  If I had a dollar for every time something I thought was pretty straight forward became much more complicated either because of changing requirements, scope creep, or just misunderstanding...  Well, I'd have quite a few dollars!

As I see it, there are basically two strategies for dealing with this problem:

1. Start as simple as you possibly can, and evolve to more complicated designs as things change
2. Start slightly more complex than may be strictly necessary so that it's easier to make changes later

I would expect people from the Agile and Lean communities to balk at the very mention of this question.  They'd probably bring up stuff like YAGNI and evolutionary design.  And I agree with this stuff, I agree with it completely!

But I also think boiling frog syndrome is a real thing.  Even a great team with the best intentions can easily find themselves stuck in the middle of a big ball of mud.  That's just life.  Little things change, one little thing at a time, and you do "the simplest thing that could possibly work" because hey, ya ain't gonna need to do a big overhaul now, this will probably be the last tweak.  And next thing you know, everything is a tangled mess and all your flexibility is gone!

To add insult to injury, when you find yourself wanting to do a significant refactoring to a more abstract design, it's frequently your unit tests that are the primary problem spot holding you back.  Those same tests that were so useful when you were building the code in the first place are suddenly locking you into your ball of mud.

I can hear you now.  You're looking down your nose at me.  Huffing and puffing that if I'd had more experience it never would have come to this!  If I'd just listened to my tests, the ball of mud wouldn't have happened.  If I'd just understood the right way to build software!  blah blah blah.  Sorry, I don't care.  I build real software for real people with a real team, I'm not interested in idealism and fairy tales.  I'm interested in practical results!  I'm interesting in making the correct compromises to yield the best results while constantly striving to do better!

And that's ultimately my point!  No matter what design I start out with, I want it to allow me to strive to do better.  If the simplest thing that could possibly work is going to be hard to evolve into something more flexible, that's a problem.  Accounting for change doesn't necessarily mean doing the simplest thing, in some cases it means doing something a little more complicated, a little more abstract, a little more decoupled, or a little more communicative.

If this ticks you off, please come argue with me on twitter!

The Dizziness of Freedom

"A man stands on the edge of a cliff and looks down at all the possibilities of his life.  He reflects on all the things he could become.  He knows he has to jump (i.e. make a choice).  But he also knows that if he jumps, he'll have to live within the boundaries of that one choice.  So the man feels exhilaration but also an intense dread."  - Jad Abumrad quoting Kierkegaard

Neat F#: Custom Operators

F# has support for custom operators.  The best use of this I've seen so far is in the canopy web testing library.  Canopy allows you to write code like:

"#firstName" << "Kevin"
"#firstName" == "Kevin"

That code is the same as this code written with the Coypu web testing library:

browser.FillIn("#firstName").With("Kevin")
browser.FindField("#firstName").Value.ShouldEqual("Kevin")

As you've likely deduced, the "<<" operator has been overridden to lookup the field and set it's value, while the "==" operator has been overridden to lookup up the field and assert on it's value.

In this case, both of these operators do exist already in F#, but they obviously aren't usually used to drive a web browser.  So this is a powerful use of operator overloading.  But F# allows you to define custom operators that have no definition in F# as well.  They can be any combination of a certain set of characters.

For example, there is no "=~" operator in F#, but you could define one to do a regex match as follows:

open System.Text.RegularExpressions
let (=~) input pattern = Regex.IsMatch(input, pattern)

And you'd use it like:

"some input" =~ ".*input"

And you could also define one that is case insensitive:

let (=~*) input pattern = Regex.IsMatch(input, pattern, RegexOptions.IgnoreCase)

These operators are not overloaded, they're just custom defined.

There is clearly a tradeoff here between explicit code and concise code.  Look back at the first example from Canopy again.  If you knew that was web testing code, and you recognized "#firstName" as a css selector, you would probably figure out what it was doing.  And this conciseness is going to be really nice in a situation where you're executing the same type of operations over and over and over again (say, like, in a Selenium web test!).  So while there's no mistaking what the Coypu code is doing, I'd rather write the Canopy code!

However, in the regular expression example, since =~ and =~* are not part of the language, how would you know what they do.  Certainly there's a similarity to ruby, but I've never seen a =~* operator.  So introducing stuff like this to your code base runs the risk of making your code harder to understand.

In the end, I think it's an awesome feature to have at your disposal.  And I think a good rule of thumb is to be willing to try some custom operators when you have a high and dense repetition of operations.  That is, it's not a one off operation, or it's not used always by itself in far flung sections of code.

In any case, this another powerful, and very neat, feature of F#.

Neat F#: Inferred Return Types

What is the return type of this F# function?

let hello name = sprintf "Hello %s" name

If you guessed string, you're correct! I know this syntax can be confusing at first glance, so here it is one element at a time:

• let hello name =
  let: the "let binding's" job is to associate a variable name with a value or function.  It BINDS things to names
  hello: hello is the name of the function
  name: hello takes one parameter, and it called name, and it's type will be inferred
• sprintf "Hello %s" name
  sprintf: basically F#'s version of .net's String.Format, it's a function that takes a format string with placeholders and values as arguments and returns a string.  In fact, this function is so neat it deserves it's own post.
  "Hello %s": the format string, %s tells the compiler a string parameter is required
  name: argument to sprintf

sprintf returns a string, therefore the hello function returns a string.  Notice there's no explicit return statement, whatever the last statement returns the function returns.  However, this is made more interesting by the fact that just about everything in F# is a statement that returns a value, including if statements:

let hello name =
    if name = "kwb" then
        "'sup KBizzle!"
    else
        sprintf "hello %s" name

This function still returns a string, because the if statement returns a string. Note this means in F# the if and the else must return the same type!

Also note, there's nothing wrong with that last code sample, but it's my impression that if statements are generally frowned upon in F# in favor of pattern matching. A true F# dev would probably have written that last using the pattern matching function syntax like this:

let hello =
    function 
        | "kwb" -> "'sup KBizzle!"
        | _ as name -> sprintf "hello %s" name

That's really outside the scope of this post, but it makes me happy!

So this brings us to the _really_ neat part: functions with changing return types.  All the functions we've seen so far have had a single static return type.  But what about this function?

let crazy f =
    f 4

What is it's return type? Maybe this will help?

let somestring x = sprintf "the number %d" x
let someint x = x

crazy somestring
crazy someint

Crazy's return type is different depending on what function we pass to it!

Neat F#: Pipe Forward

Functional programming dates back to the 1950s, but from my perspective it seems to have been garnering more attention in the software engineering community recently.  I first got really interested in it last year at CodeMash when Ben Lee introduced me to a little bit of Erlang.  It was so fascinating that I decided I had to dive in deeper.  F# being a .NET language, it was the obvious choice.  So I bought an ebook of Programming F# and started writing a few little programs.

Along the way there have been a few things that completely blew my mind, or that I thought were just flat out neat.  You could (and should) learn about these things from much better sources, but I love to share!

So to kick it off, this first post will cover the first thing in F# that really truly blew my mind: the Pipe Forward operator.  You see it used in F# all the time, and what it allows you specify the last parameter's value first, thus writing your statements in a more logical order.

So for example, this:

let testInts = [1;2;3;4;5;]
let evenInts = List.filter (fun i -> i % 2 = 0) testInts

Can be re-written as this:

let testInts = [1;2;3;4;5;]
let evenInts = testInts |> List.filter (fun i -> i % 2 = 0)

This example is trivial of course, but where this really starts to shine is when you can effectively describe an entire program in one chain of function calls:

let oddPrimes = 
    testInts
    |> filterOdds
    |> filterPrimes

Basically what's happening here is that the value on the left of the pipe forward operator is being passed as the last parameter to the function on the right. In the first example, List.filter takes two parameters. The first is a function, and the second is a list. You'll find that all the functions in F# modules are structured so that the parameter most likely to be passed down a chain like this is defined as the last parameter.

At first I didn't think this was mind blowing at all. It just looked like a simple compiler trick. But then I learned this isn't in the compiler at all. In fact, |> is just a single line F# function. It's definition is nothing more than:

let (|>) x f = f x

F# also has a pipe backward operator:

let evenInts = List.filter (fun i -> i % 2 = 0) <| testInts

And it is defined as:

let (<|) f x = f x

If you've followed along this far, I hope you are boggling your mind as to what possible purpose this could serve! I know I was. The answer comes from the fact that operators have higher precedence in F#. So the pipe backwards operator allows you to avoid wrapping an expression in parenthesis. For example:

let output = "the result is: %d" (2 + 2)

Those parenthesis are such a drag. So we can rewrite this without them as:

let output = "the result is: %d" <| 2 + 2

Stratified Design

The last posted ended by presenting a style of OO in which the objects only exposed operations which communicated via data classes.  We arrived at this design by thinking more deeply about encapsulation.  I asserted that there were a number of benefits to an object structured this way, but promised to also talk about the architectural benefits of applying this practice throughout your code.

A Stratified Design means writing all of our objects in this behavior-only style, and passing data classes between them.  There are lots of detailed decisions to be made around what exactly those data classes should contain, but for now I'm going to stay at a higher level.

You may be thinking to yourself, "Hey!  Those are just layers!  I've been duped, there's nothing novel or interesting in this except a fancier name!"   While what I'm advocating here is very similar to the traditional layered architecture there are some very critical differences.

1. Some definitions of layers include a restriction that lower layers may not reference higher layers.  When applied to domain modeling this tends to lead to ridiculous restrictions where your data layer is not allowed to return domain objects because the domain is a higher level concern than the database.  A stratified design agrees that lower stratum should not use behaviors of higher stratum, but that doesn't mean they can't share the same data classes!
2. Layered architectures usually prescribe an exact number of layers for specific purposes.  In a stratified architecture, there aren't any consistent named layers.  Instead, there's just a series of classes calling into each other as needed.  Each of those classes is defined at some level of abstraction, and calls into it's dependent layers as needed.  And that's as prescriptive as it gets.

There are a lot of awesome things that follow from having objects calling other objects in this way:

• Decoupled: clean interfaces communicating with data is about as decoupled as you can get (and therefore insanely easy to unit test!)
• Simple, not complected: each object knows only about the interface of it's dependencies.  And it accepts small data classes, and outputs small data classes.  There's no static or global knowledge, no god objects.  And each object represents one concept defined at a consistent level of abstraction.
• Behavior only where needed: the simplest example is you will only be passing small data classes into your view, not ActiveRecord objects (which expose query and data persistence behavior).
• Somewhat side-effect free: not entirely side-effect free, but because there is little to no shared state, it's difficult to be surprised by a side effect.
• Intuitive: If you do a good job separating your levels of abstraction, you will find that when you are looking for something, it's always right where you expect it.  Or if it not right there it's one explicit function call away.  Contrast this with OO designs that are riddled with inheritance and misapplied strategy and state patterns...  Or compare it to "light weight" Active Record based designs where logic might be in an AR hook, or might be in a service class, or might be in a controller...

The inspiration for this Stratified Design came from a number of different sources.  But the primary ones were:

1. Rich Hickey's Simple Made Easy and The Value of Values
2. Bob Martin's Architecture the Lost Years
3. David West's book Object Thinking (which I reviewed before)

These don't spell this out exactly, but they contributed certain concepts.  And as always, remember that "architecture" is dangerous.  Lots of people might be excited about CQRS, but that doesn't mean it should be applied to a mostly read only content management site.  And Rails might be an efficient platform for quickly building a web app, but that doesn't mean it's right for building a space shuttle control panel.  And the same goes for Stratified Design.  The architecture of your application should reflect the nature of your application.

But that said, if you give Stratified Design (or something similar) a try, I'd love to hear about your experiences with it!

Encapsulation: You're doing it wrong

In the last post, I investigated just what the devil encapsulation actually is.  I may not have answered that question, but I did decide that whatever it means, there's a subtle but important distinction to be made around encapsulating "data".  The example that launched that distinction was a Queue which stores data from the caller in some encapsulated implementing data structure.  Notice the distinction between the caller's data, and the Queue's implementation.

One way of approaching a new OO design in a "business" environment is to ask, what data do I have?  Then create a "model", and add a property for each data element.  C#'s { get; set; } properties highly encourage this, and ORM and ActiveRecord tools require it.  So now we have little data classes, structures basically.  But we know that we're not doing OO unless we're doing encapsulation, and that means we need some methods!  So we add some methods to our little data classes that usually either modify that data in some way, or perform some calculations with it.

But what is this class encapsulating?  All the data is fully exposed, and the methods are restricted to simple operations on the same data.  Clearly it's trying to represent something, but we started from some data which more than likely corresponds directly to a database table.  So what is it representing?  At best, one data thing.  And what is it encapsulating?  Some logic about that data.

But looking at this again from the perspective of encapsulation as bundling implementation details instead of data, we could go a different route.  When thinking about a Queue, I don't think about it's internal implementing data structure.  I think about the operations I want it to perform for me.  So instead of asking, "what data do I have?", "what operations do I need to perform?" could be better starting point.

What if all the properties were moved off the object onto their own little class -- or structure -- or in F#, record.  The original object would then be left with operations only.  And one of those operations would have to be getting the data, and that would just be a simple method that returned the little data class/structure/record.  This class is encapsulating the implementation details of those operations you decided you needed to perform!  And just the like the Queue, there is now a clear distinction between the caller's data and the class's implementation.

A number of interesting benefits follow from this:

• Enables a coarser grained interface, which is especially useful for data access.  You gain the control to define operations to retrieve as little or as much data as you need.
• Designing around encapsulating implementation details leads to objects that are well defined with intuitive behaviors and clear purpose.  Ultimately that means it's easier to find the behavior you want, and extend behavior when needed.
• The resulting clean behavioral interface, passing and returning data, immediately results in simple and flexible decoupling, which is great for unit testing.

And these are just the benefits realized at the level of just the one class we modified.  In the next post I want to look at what happens when this architecture is applied through out in what I call a stratified design.

Encapsulation: What the devil is it?

I love the word 'Encapsulation.'  It's a big fancy word and I feel smart when I use it.  Unfortunately, I'm not really sure what it means, and neither is Wikipedia.  "Encapsulation is to hide the variables or something inside a class."  I lol'd when I read "or something," what a specific definition!  So, what the devil is it?

The most naive OO definition might be:

A language feature that bundles data and methods together.

You might extend that to say that it hides the data from public consumption, but that part muddies up the water, as the Wikipedia article demonstrates.  My favorite example of Encapsulation is a Queue class.  You get push, pop, and peek operations to call, but you don't know what data structure the uses to implement those operations.  It could be an array, it could be a linked list, whatever.  In this we can easily see the beauty and the power of encapsulation: "data" and "methods" together.

But wait, what did I actually encapsulate in that queue?  Was it the "data"?  I pass my data into and out of the Queue, and the Queue hides its implementing data structure from me.  Maybe it's a Queue<string>, and I'm all: q.Push("encapsulation"); q.Push("is"); q.Push("about"); q.Push("data"); Assert.AreEqual("encapsulation", q.Pop());  For me the data are those strings, but those strings are clearly not what the Queue is encapsulating!

That word "data" in our definition is a tricky one.  It can be applied to too many things to be really useful.  But does replacing "data" with "data structure" in the definition fix the problem?

A language feature that bundles data structures and methods together.

It clears it up, but it introduces another problem.  For example, what if my object is a database gateway?  Certainly there's a data structure somewhere in that database, but my object isn't directly encapsulating that!  No, it's probably "encapsulating" ADO.NET procedural calls, or some other data access library.  The procedural calls are neither data nor data structure...  So could it be that thinking about data is completely misleading?

A language feature that bundles implementation details and methods together.

This is a rather large step though!  Instead of just talking about data, or data structures, this now includes just about anything in the definition of things that can be bundled with methods to achieve encapsulation!  Maybe there is some value in restricting what the word "encapsulation" applies to, but if there is, I doubt it's something that is going to prove useful for Software Engineers.  So while I admit this definition could be a perversion of the word "encapsulation," I find it more useful.

The other definition Wikipedia gives for encapsulation, which I've neglected to tell you about until now, is "A language mechanism for restricting access to some of the object's components."  This is more similar to the definition I just ended on.  I take some issue with the word "restricting" and the word "components" is ambiguous enough to be a problem.  But I don't think it's a stretch to think "components" could include both data and dependencies.

So, perhaps we've arrived at a better understanding of encapsulation.  One that recognizes that data is not the all important concept.  The next step I'd like to take is to extend this slightly deeper understanding outside the realm of data structures and into more typical "business" scenarios.  That will be the next post.

I'm Not Trendy

In October of 2011 we had a Burning River Developers meetup that I unfortunately missed (because I was on a plane returning from Europe!).  I learned from people who attended that during his presentation Dan Shultz said that I am "not trendy".  I guess he was saying something about how Knockout is not as trendy as Backbone, and that I'd appreciate that.

Here's the thing, he's right!

I'm ready to admit the error of my ways. I love my macbook's hardware, but there's little about OSX that's good, and plenty that's bad.
— Kevin Berridge (@kberridge) September 13, 2012

When I bought my mac, it was probably one of the few examples of a time where I allowed the popularity and trendiness of something to sway to my decision.  And I've given it lots of time and lots of patience, but last night I finally admitted that OSX is rubbish.

Why?

• Everything about Finder is broken.  EVERYTHING.
• Window management is garbage.  How do you minimize and restore w/ out the mouse? (I know about command-H, it's no good either)
• The only app I like is chrome.  Guess what, it runs on every OS!
• mail.app is sluggish and ugly
• iCal can't sync correctly with google
• iPhoto doesn't scale and doesn't organize in a way I find useful
• iTunes music file management is totally inflexible, to the point of unusable
• The dock is dramatically inferior to Windows 7's task bar
• Lion is slow to boot, and has worse battery life
• I see no compelling reason to upgrade to Mountain Lion at all (except to remove the stupid skeuomorphic stich graphic from iCal, which as mentioned above, I don't use anyway)

The only thing I like is the swipe motion to switch spaces.  But the only time I use that is when I'm running windows in a VM, so if I was in windows I WOULDN'T NEED IT.  The only other rare time I use it is to maximize a window, which just goes back to how crappy window management is on OSX.

I thought I might like that it was a unix, but the truth is it's a crappy incompatible unix (and it doesn't even have a decent package manager that doesn't break across upgrades).  And any time I've wanted to do something unix-y, it's just been a headache.  

The hardware is pretty though!  And the trackpad is the best I've ever used, so it's certainly got that.  Also the keyboard is pretty great.  So bully to the hardware.  But, I'm being honest here, that's all I can give it.

So why is the mac so popular right now?  Just because it's popular.

Even as I write this, I'm aware of how unpopular this opinion is.  But it's just my opinion, and you should be skeptical of it.  Especially because like Dan said, I'm not trendy.  

Everyone likes Dynamic Languages?  I prefer static and functional.

Everyone's excited about Node?  Looks like an immature waste of time to me.

Backbone is all the rage?  I'll stick with Knockout, thanks very much.

IPhone?  "Meh" at best, I'm happier with Android.

Pair programming?  Code reviews.

Startups want to cash out quick?  Nonsense, build a sustainable business that tackles hard problems and makes an actual difference!

Pop music? Techno? Dubstep?  It's jazz for me.  And even within jazz, I don't like bee-bop (arguably the most popular right now), so I'm totally fringe there too.

This is totally a rant, and if I have a point at all, it's this:  1) I'm not trendy 2) OSX is garbage.  And I guess my other point is just that it's OK to not get caught up in the trends.  You don't have to join the Lemmings, you're allowed to have you own taste and opinions!

I reserve the right to change my mind about all opinions contained in this blog post at any time without notice.

Opinionated

o·pin·ion·at·ed

Conceitedly assertive and dogmatic in one's opinions.

con·ceit·ed

Excessively proud of oneself; vain.*

I'm not sure who first used the word "opinionated" to describe a software framework in a positive light, but I know the place I encounter it most often is in reference to Rails.  The good news is, I bet DHH fully understands the meaning of these words, and is still more than happy to identify by them.  At least he knows what he's doing.  But I still think this is a stupid thing to be proud of.

Unfortunately, writing "opinionated" code has since just become the thing to do.  And I don't think most people who have jumped on that bandwagon bothered to look it up in the dictionary first.  As a result, I now have the impression that when someone says their framework is opinionated what it really means is they're claiming it's general purpose, but it really only works in a very specific scenario, and they don't even understand that other scenarios exist.

Imagine you're walking down the aisles at Home Depot looking for a tool to help you complete a job.  Maybe you need a drill bit extension to reach into a tight corner.  You have a certain kind of drill that accepts standard shaped bits, and your corner has certain dimensions, and you need to set a certain diameter screw.  A helpful sales associate comes up and asks if he can help.  You give him a quick high level summary, and he smiles knowingly.

"What you need is the XYZ fixed flexible dongle attachment!  It's the only choice.  All the other options are total bullshit, I can't believe we even stock them."  He's kind of starting to foam at the mouth now...
"Believe me, this is the one."

OK, you think.  It costs 3x as much as the other items on the shelf, but this guy clearly knows what he's talking about.  You get it home and come to find, it doesn't fit your drill because it has a non-standard bit shape, it doesn't fit your bit because it's built for larger bits, and it's too short to reach into the corner anyway.  And what does the guy say when you take it back to return it?

"Oh, well, this is an opinionated drill bit extension, it's not meant for your job."

Code that does one well understood, well defined thing, is exactly what I want.  But misunderstanding that well defined thing and advertising the code as the solution for everything is stupid.  And being dogmatic and conceited about it isn't helping anyone.

* Definitions from Google

Blogs are Little Islands

You are not blogging enough. You are pouring your words into increasingly closed and often walled gardens. You are giving control - and sometimes ownership - of your content to social media companies that will SURELY fail.  - Scott Hanselman, Your words are wasted

I enjoy blogging.  I've been doing it since April of 2007 (that's 5 years at the time of this writing!).  For me, it's a great way to work through problems and ideas.  It's kind of a "learning out loud" thing.  And lately, it's been just a way to have some fun with writing.  That's why I'm still doing it, but it's not why I originally started doing it.

I first got into blogging because I wanted to be a part of the community of tech people who were on the interwebs learning from each other and arguing with each other.  That didn't happen, because it turns out a BLOG is not a community.

Blogs are little islands, owned by little dictators.  They've all got large towers built right in the center with mega phones mounted on top, and they're shouting out to sea.  

There's this weird aggregator of shouts out there somewhere, we call it Google.  It archives your shouts, so people searching for a solution to a problem can have a chance of finding the echo of something you yelled long ago.  Of course, that echo has been bouncing around for awhile, and it's probably not terribly accurate any more.  Because of that, we don't shout solutions to problems any more, we do that on StackOverflow now.

But we're all still shouting, so it must be because we want someone to shout back.  But if you even hear my shout, and if you do bother to shout back, the chances I'll hear it are slim.

So instead, maybe you'll fly by my island and drop a leaflet on the beach.  I might pay attention to that, and if I do, I'll leave a leaflet for you on my beach in response.  But you'll never see it, it's my beach and you're not there.

If we're really going to talk, you'll have drive your boat over to my island and stay awhile.  But what a big decision that is for you!  Why would you spend your tourist dollars on my island when there are so many other islands to choose from?  And some of them are much larger, and have many more tourists!

Every island starts out abandoned, with just a lone dictator.  If that dictator is willing to shill for tourists through aggressive marketing, he might attract a bit of a crowd.  But the dictator will still be the dictator and the tourists just tourists.  That's not a great format for interesting conversation...

The little islands model just isn't conducive to building community and having great conversations.  Twitter isn't either, but for different reasons.  And Facebook?  Well it's Facebook.  G+?  *cricket cricket*.  If there's a solution to this problem I don't know what it is.  But I'm pretty sure the solution isn't blogs.

Steve Jobs on Experience

"A lot of people in our industry haven’t had very diverse experiences. They don’t have enough dots to connect, and they end up with very linear solutions, without a broad perspective on the problem. The broader one’s understanding of the human experience, the better designs we will have.” - Steve Jobs, Wired, February, 1996