Of Mulch, Compost, and Water Flow

posted on Apr 04, 2014 with comments

On Tuesday March 11th 2014, I finally closed on the house that I have been trying to buy for the past year. It has been a long and arduous journey just to get to this point. So much went wrong that that I went to the closing still convinced another shoe would fall. Even after all the paper work was signed I was sure something more could go wrong. But it didn’t. The house was, at last, mine.

Mine?
Mine?

In the wee hours of the next morning, I awoke in a deep panic. The purchase process had been so long because no bank would lend on the home. It’s a bit a of a fixer upper, to put it lightly. Foundational issues, bad wiring and plumbing, a leaky roof. The one terrifying me at that instant, as freezing rain fell in a light pitter patter, was the foundation.

Now, here, you might ask, “Daniel, why on Earth did you buy this place?” It’s a fair question. I wanted a house in town, but with enough land that I could build an urban homestead on it. I wanted to be close to Dandelion Village. I wanted a small house and a big lot. But mostly, I’d made the mistake of renting the house before buying it and I’d fallen in love with it. Despite all its flaws, it had become home.

I ended up paying more than it was worth. It was underwater and I didn’t feel like trying to compete with institutional buyers in a short sale. Maybe I wouldn’t have had to. But by the time we got to that point, I’d already been through two attempts at obtaining a mortgage. I’d been at it for over 8 months.  I had spoken to every kind of contractor on the planet. I knew what the home was worth, and I knew every single thing that was wrong with it. It was a long list. But, after all of that, I still wanted it. I ended up essentially paying for the land and 3 - 5 years worth of rent. Whether or not that’s what I’ve actually purchased remains to be seen.

The economics of the whole thing get better if I can start getting most of my food from the land right away. And so, I haven’t wasted time getting started on building the long dreamed of urban homestead. Before the closing, I had started laying down mulch as the foundation of four raised beds in the front yard. If things fell through and I ended up walking away, I figured I could just move the mulch onto Dandelion’s land. But closing went through and I forged ahead.

Mulch, then compost.
Mulch, then compost.

I’d originally purchased the mulch from Good Earth intending to lay it down in the side yard. Every time it rains the whole thing turns to a muddy slush that the dogs track all through the house. I was expecting the mulch to be something closer to wood chips. What I got was half way between finely ground mulch and compost. It was never going to work as mud prevention. I wound up ordering straight woodchips to use for the side yard and was left with 10 yards of composting mulch. Perfect for the raised beds I’d been planning.

I used the mulch to build the bed’s foundation and then I ordered a load of compost from Bloomington Speedway Mulch. I’d heard that Speedway’s compost was more nutritious than Good Earth’s. What arrived was not quite what I expected.  Instead of well aged, rich humus, I got a fairly light and dry powder that smelled strongly of shit and ammonia. It was almost raw manure and there was clearly too much nitrogen and not enough carbon. Suddenly I was very glad I’d laid the foundation of the bed with mulch. The mulch would absorb much of the excess nitrogen and the two would combine and rot to form the perfect soil.

I decided to layer the two, lasagna bed style. On top of the foundation of mulch I put a solid layer of compost. Then a somewhat thinner layer of mulch, and a thinner layer of compost. Finally, a very thin layer of mulch, just enough to cover the surface. The beds wound up almost two feet high. They’ve settled quite a bit since then. I’m still a little worried that they’ll be a bit too nitrogen heavy and burn out the roots of my plants, but we’ll see.  Hopefully I reached the right balance of mulch and compost. Either way, next year they’re going to be amazingly fertile.

More of a swale, really.
More of a swale, really.

In the mean time, I’m was still fretting about the foundation. The house sits on the side of a steep east facing hill. There’s several acres worth of run off that flows down the hill, and right up against the west side of the house every time it rains. Much of it flows into the basement and gets pumped out by the sump pump. All of this puts pressure on the already bowing cinderblock basement wall. There’s a solid 2 cm crack running horizontally down a seam of the blocks right at the frost line. Directly west of the west wall is a particularly steep section of hill. Whenever it rains with any force at all a large puddle forms on the surface of the ground, right up against the west wall.

To alleviate some of this pressure, I dug a drainage trench directing the water out around the front of the house and down the hill. I’m not sure what I’m going to do over the long term. Visions of terraces, digging out the wall to in fill with gravel, and ponds in the front yard swim in my head. I’ll probably need to do some more research to figure out exactly what my options are.

The closing has acted as the starting gun. It released me from my long wait behind the gate and allowed me to act on dreams I’ve been nursing for over a year. I’m glad to be working and it’s wonderful to see my dreams begin to take shape. But man, do I have my work cut out for me.

Article has comments.

Escape From Parameter Hell

posted on Jan 27, 2014 with comments

I’ve been doing a lot of interface design, of late. When first designing a system, it’s pretty easy to keep interfaces simple. It’s easy enough to write functions and methods such that they only need a few things:

function do_action(Person $person, $action){}

But as design progresses, or as you use a system, interfaces change. You need to pass more information. Parameters previously required become optional. Eventually, you end up with function signatures like this:

function do_action(
    Person $person_doing, 
    $action, 
    Person $person_done_to = NULL, 
    $at_time = 'now', 
    $with_implement = 'voice', 
    $with_coconuts = FALSE,
    $are_repressing_the_peasantry = TRUE) {}

Welcome to Parameter Hell. It gets even more obfuscated when you run across the function call:

do_action($king_arthur, 'run away', NULL, 'now', 'legs', TRUE, FALSE);

In plotting your escape, the very first thing to consider is that your interface might be trying to do too much. It may need to be broken down into multiple methods, or possibly moved on to an object (or a different object). In our example, this is clearly the case. The first thing I would consider doing is moving the function to the Person class:

class Person {
    // -- SNIP --
    public function doAction($action, 
        $person_done_to = NULL, 
        $at_time = 'now', 
        $with_implement = 'voice', 
        $with_coconuts = FALSE, 
        $are_repressing_the_peasantry = TRUE)
    {}
}

So now the call would look like this:

$king_arthur->doAction('run away', NULL, 'now', 'legs', TRUE, FALSE);

A little more clear. The next step might be to split this method into two methods:

public function doAction(
    $action, 
    $at_time='now', 
    $with_implement='voice', 
    $with_coconuts = FALSE, 
    $are_repressing_the_peasantry = TRUE)
{}
public function doActionTo(
    Person $person, 
    $action, $at_time='now', 
    $with_implement='voice', 
    $with_coconuts = FALSE, 
    $are_repressing_the_peasantry = TRUE)
{}

Giving us:

$king_arthur->doAction('ride', 'now', 'legs', TRUE, FALSE);
$guardsman->doActionTo($king_arthur, 'question', 'now', 'voice', FALSE, FALSE);

With these sorts of small refactors, you can gradually move your way out of Parameter Hell and back to reasonable interfaces.

Sometimes a function or method can’t be easily split. In that case, the next step is to examine the information it is taking. Does it stick together throughout a request? Does it (or some subset of it) hold together conceptually? If the answer to either of those questions is “yes”, then the next move is to take that subset and make a new class.

In our example case, if we find that $action tends to be associated with a time and an implement in our code, then it might make sense to make a new Action class:

class Action {
    public $what;
    public $when = 'now';
    public $with = 'voice';
}

Now our method signatures look like this:

public function doAction(Action $action, $with_coconuts = FALSE, $are_repressing_the_peasantry = TRUE)
{}
public function doActionTo(Person $person, Action $action, $with_coconuts = FALSE, $are_repressing_the_peasantry = TRUE)
{}

Which gives us the following calls:

$the_french->doActionTo($king_arthur, $insult, FALSE, FALSE);
$king_arthur->doAction($run_away, TRUE, FALSE);

If there isn’t a new class that can be easily created from the parameters, or if you still have the odd configurational parameter hanging around (like we do), then we still have one more trick up our sleeves. The options array. We put the remaining parameters into a single associative array, usually called $options or $config. We name them this way intentionally, things that end up in $options arrays should be just that, optional configuration parameters.

Using an associative array lets you ignore the parameters you don’t need at the moment. You also don’t have to worry about parameter order. Each parameter is associated with its name. And if you need defaults, you can always compare the options array to a $defaults array inside the method. It’s a substantial improvement.

The method signatures become this:

public function doAction(Action $action, array $options=array())
{
    $defaults = array(
        'with_coconuts' => FALSE,
        'are_repressing_the_peasantry' => TRUE
    );   
    // Later values (the ones in options) will overwrite earlier values
    // (the ones in $defaults).
    $options = array_merge($defaults, $options); 
    // --- SNIP ---
}
public function doActionTo(Person $person, Action $action, array $options=array())
{
    $defaults = array(
        'with_coconuts' => FALSE,
        'are_repressing_the_peasantry' => TRUE
    );   
    // Later values (the ones in options) will overwrite earlier values
    // (the ones in $defaults).
    $options = array_merge($defaults, $options); 
    // --- SNIP ---
}

And the calls look like this:

$options = array(
    'with_coconuts' => TRUE,
    'are_repressing_the_peasantry' => FALSE,
);
$king_arthur->doAction($run_away, $options);
$options = array(
    'with_coconuts' => FALSE,
    'are_repressing_the_peasantry' => TRUE
);
$king_arthur->doActionTo($dennis, $repress, $options);

You do have to be careful with options arrays. Storing data in associative arrays can be dangerous in large or long running projects. Associative arrays are not strictly defined. They’re fluid. In a long running project, the definition of the array can become separated from its use. It gets defined and populated. Then more stuff gets added to it. It gets passed to a method, which removes some stuff and adds more, before passing it to another method and so on.

When the new developer goes to fix a bug in a method and looks at the array coming in, he has no idea what is in that array. The data being passed around has been effectively obfuscated. He has to go digging back through code to find the structure of the array before he can fix the bug.

There are a number of things you can do to mitigate this problem.

The defaults array we mentioned helps. It can define the structure, provided you have a default for every possible value.

You can also try to create and populate the options array as close to the method call as possible:

$options = array(
    'with_coconuts' => TRUE,
    'are_repressing_the_peasantry' => FALSE,
);
$king_arthur->doAction($run_away, $options);

It’s not always possible to create it right next to the method call, sometimes you have to do work to populate it. But try to keep it close.

Once inside, don’t let it live beyond the method. Don’t return it and don’t pass it on. If you need to send some of those options on to another method, build a new array.

The final thing you can do is make sure to thoroughly document every array passed to any method. Don’t do this:

* @param  mixed[] $options  (Optional) An array of options.

Do this:

* @param  mixed[] $options  An array of options for the action, with the
*   following possible fields:
*     'with_coconuts' - (Optional) Is the action being performed using coconuts
*     to mimic the sound of a horse hoof?  Do coconuts migrate?
*     'are_repressing_the_peasantry' -  (Optional) Is a peasant being repressed
*     through this action?

That way a developer coming into the method doesn’t have to go farther than the docblock to know exactly what to expect to be in that array. The catch, of course, being that you have to keep the docblock up to date.

Finding yourself in Parameter Hell is a good indication that it’s time to stop and refactor. Sometimes it’s just that one function signature that got out of hand, but often you’ll find many interfaces that need to be rearranged. You can do it gradually. In bits and pieces, one change at time. When you’re finished the result will be a set of interfaces that are much more readable, much more maintainable and should make life much easier on you. At least, until the next time you find yourself in the depths of (in a meanacing, echoy voice) Parameter Hell.

Originally published on EllisLab.com.

Article has comments.