Proper Preparation and Planning

Preparation and Planning
While I'm not getting much project time in at the moment, I'm not wasting the time I have in proper preparation and planning.

The first working fire is about to be built - I've got sand arriving tomorrow that I'll need for the refractory mix and I need to buy a hole cutter to make the blast so I should be able to go out this weekend and if the weather holds I'll put it all together.

My first working fire is a foundry that I'll repurpose for some hot metalwork. It'll be fine until I can build something bigger, and will let me make cast brass components that I may well need soon. To this end I also caved in and ordered a graphite crucible online, I think I'm going to make a steel one when I can but having "That crucible problem solved" for now is going to mean I can get stuck in.

I'm going to use a cheap air blower from an outdoor ship and see how hot the fire gets. Long term I've got plans for a peltier effect module to power the fan from the fire. But the first step is putting a blower on there and getting a feel for how much air it needs to get a good burn.

Patio Paving
After making a few sketches and standing in the space, I'm pretty much sold on a patio space 15" wide and 18" deep, with two benches and a circular firepit around 3" in diameter.  This second firepit will be mostly for heat and show, but I want to be able to cook on it so a good first project for the working fire will be making a rotary spit.

Practical Project
The rotary spit will start as a simple A-Frame and crank handle, but if I want to spend two hours cooking a chicken I'm going to need to automate that rotation and the blog comes full circle to Roger in Technology.

Presenting Peltier 
The three engines I'm considering are all quite different in their construction and maintenance, and each with its pros and cons. The first is to use it as an excuse to make a peltier generator, which is a remarkably good project to start now, especially if I want to use it to power a fan later on.
The simple construction is a metal squarebar with a peltier device and heatsink on. The squarebar can be staked into the firepit at an angle, with the heatsink off to the side. And then I'll run an electric motor on a belt drive to turn the spit.

The peltier solution is nice, but it'll be difficult to get much current without a reasonably large array of peltier effect generators and a large heatsink. I don't know how much current I need to generate the torque to rotate a chicken. In fact, I don't even know how much torque you need to rotate a chicken so I could test this with some 9V or 4.5V DC motors and see if they are likely to be up to the task.

Piston Power
While the peltier might not work, the age of steam has me covered. I know I can build a steam engine with a boiler I can place in a cooking fire that will have much than enough power available - so specifically I can build a very small steam engine that will do the job.

It's a little fiddly to have a steam boiler in the fire with brass pipes leading to a steam regulator and crankshaft setup. My concern is that I have two unique units connected by brass pipes, and the pipes will bend and break.

The next option here is an external combustion Stirling engine. Relying on the expansion and compression of the working fluid, the stirling could probably be a single unit. Like the others it would sit on the edge of the firepit. Its probably harder to construct than the steam, but doesn't need as much pressure in the boiler and feels like a safer bet.  I find the stirling a more interesting design, and it should be very easy to maintain and run - needing little tending compared to the steam that might need me to look after the boiler.

Practical problems

Whatever the build, I need something that is easy to store. Its not going to live in the elements all year round, so I want something I can easily carry from the firepit and stow away to cool once the cooking is done.

Thanks for reading everybody, I know this wasn't really an action report and I don't have any pictures.  I'll get some pictures of the gear and the space before the build starts.

This blog was brought to you by the letter "P".

Firepit, Foundry and Forge.

Progress report on the technological terror I am creating.  This year, I'm in hardware mode instead of software.

Hardware this year doesn't mean valve amps and videocards, instead I'm going back a few thousand years and starting with the basics.  Aside from land clearance in the garden, the first construction is about to start - although land clearance and gardening is more challenge than you'd think.

Dakota Firepit

The first thought was to dig a dakota pit, and since I've uprooted some hedges I had a good starting hole to use that I've spent some time looking at.

The Dakota pit is a low-tech solution that I could build with stone age tools, and while I don't have any stone age tools I'm willing to improvise. It'll be enough to heat and beat some metal, and is a good cooking fire too.

I think I can get good airflow from a simple 12V DC brushless fan using an old chimney pot to duct air inwards, so I could upgrade the Dakota pit to get more heat and be a temporary forge fire. This blend of stone-age and modern technology pleases me.

However, the Dakota pit isn't a very visually appealing structure - its a hole in the ground full of fuel and ash at best - and at worse looks pretty naff. Ok, I'll be adding an electric chimney but it's still a hole in the ground. Rain will get to it too.

Its also fundamentally a floor pit which isn't a good height to work at. I'm not going to knock it - as a practical survival fire its amazing but for a domestic garden I can afford to go upmarket so I've been searching for practical alternatives.

Brake Drum Forge

The height of the Dakota pit is annoying, so I'm looking for a raised firebox at about waist high. Being portable is an advantage here because i'll be forging outside, but I'm going to want to store it in a shed to keep it safe from the elements.  Once I've built a forge house I can have a more permanent set-up, but I'm looking at getting started straight away so want something small.

A Brake Drum forge is easy to build, the parts are basically scrap metal and its reasonably portable. brake drums are galvanised, so can give off some fumes but I'll be outdoors and can probably deal with it. It's small, portable, and cheap and brake drums are the starting point for many blacksmiths.

Foundry
While the brake drum forge is probably the best starting project, there are some restrictions on its construction.  A Dakota pit can be dug with stone age tools that I could make myself, while a brake drum forge needs cutting, welding, and tooling.  Normally, practicing these skills is a great task but I want to avoid spending money on gear.  Also, the brake drum forge still makes your garden look like a scrap yard. There are also fumes from a brake drum and I'm not too into that.

The compromise is to make a storm-in-a-teacup, on this case a foundry-in-a-bucket.  I've got a twelve litre steel bucket - two and a half gallons - that I'm going to line with a refractory material and use as a blast furnace. With an air intake about halfway down I can use the same brushless 12V DC fan that'll get me between 30 and 50 cfm of airflow.  With 30 MJ/KG fuel I can get a thousand degrees in there and enough to liquidise brass.

Because the unit is contained in a bucket, it's super portable. It'll weigh in under 10 kilos (20lbs) and can be placed on a stand for working metal, or on the ground for stability if I'm heating a crucible.

Projects
I've got a few early projects in mind.  The foundry is one of the first milestones, and I should be able to 3D print patterns to make greensand molds from and cast shapes from brass. I'll have sand left over from making the refractory lining, and thats the principal ingredient in making casting sand.

Using it as a forge I should be able to make some fire tools, and a combination of cast parts and worked steel will make a rotisserie which will allow me to repurpose the whole thing as a cooking fire in time for BBQ season.  I guess I'll have to run the fire cooler for cooking - I'm not sure the melting point of chicken, but I'm pretty sure that a thousand degrees blast furnace will result in "well done".

The bucket foundry should be enough to work small steel and iron - tools, and some misc stuff. I'll be making nails with it for some woodwork projects. Kitchen hooks, bookends. Stuff.
It *might* be good for making chain, but there are complications and TBH I don't need any chain right now.
It'll be good for making knives, too, although I'll need a serious grinder for materials reduction and knives are a lot of work so its not a project to be taken lightly. There is a defunct lawnmower, so I'm thinking of taking the blade off and making a gardening machete from it. Reduce, Reuse, Recycle.

So overall, I'm hoping to get good use out of the bucket foundry. Pictures and videos are on their way.
Until then, Fly Casual.

Can I axe you a question?

Today was an axe day, destroying the garden - uncovering & discovering a large Mahonia trifoliolata which put up a fight with its super spiky spikes of vengeance.

Only afterwards did I learn that its edible berries ripen in the spring, and can be used to produce wine or as a fruit drink. Damn, had I known I would have left it standing until harvested.  Possibly I was distracted by the amazing bright yellow wood, which I'll keep, season and hopefully make something out of. But dang, I could have had some tasty berries.


Nonetheless, everything at the back save some unidentified reeds and the shed had been cut down and they are next. We don't have a key to the padlock on the shed, but its exterior construction is a wood that will not survive my industrious axework and it won't last once I focus my attention on it.   If it wasn't for the fact that everything has been chopped down, I'd be shopping for a bigger axe right now.


The wood I've collected isn't enough to make the benches from but I'll make a logpile and it'll feed the firepit on a summer evening. There is a tree that I've got my eye on, that might have to come down and then I'd be really tempted to make a bench from it rather than firewood.

The base on the shed isn't all that - Its bordered by pavers and to be honest I don't expect to uncover much more. So now I've got an 18x25 foot space - once the shed is cleared and the ground is dug - to build the forgehouse and patio space. The Forgehouse looks like around 9x15 foot or therabouts, with space for stock, fuel, hot and cold workbenches and all the regulars and comes in under the planning permission radar as long as a few simple checkboxes are ticked. It has to be non-combustable, but I was planning that anyway, and it has to have a decent floor and not have a bed in it. Also, 2.5M eaves and a 4M pitch, but those are way bigger than I need so it should be a breeze.

The hot workbench will be commercial firebrick on a sand base, and hopefully suitable for casting brass and other soft metals. The cold workbench will just be a thick wooden worksurface with a decent vice.

Meanwhile the patio has space for probably three benches, or two benches and a gazebo, and a firepit around three or four foot in diameter. This will be an earth or sand base for wood and charcoal burning, and I guess cooking over. This needs a plan. For all I know at the moment, I have a square space around 18x18 foot and want to have at least a bench and a firepit.

So plans are coming together. The base and patio are going to cost around three grand if I get contractors in, probably more given there is little to no access to the rear of the garden.  I can do it myself for around 750-1000 looking at the materials cost, or around half that for cheap ass paving, and I'm torn between just waving a wand and having somebody do it while I'm at work or plugging away at it with flesh, blood, sweat and tears.

Materials for the forgehouse are expensive in this part of the world, and I've got to choose between stone and brick which may end up being a very very difficult decision. The firebox, anvil and forge tools I need are cheap enough and everything beyond the basics I can make once there is a fire going.

It's a huge plan. Its a grand design. Its a lot of work. I'm starting to feel that this year will be the groundwork and learning year and the construction might not be finished until after the winter.

Starting Hardware mode.

Hardware mode
Today saw the first in a revitalised project. As the winter washes away I find myself in hardware mode again, and itching to make - and break - all manner of things.

There is a space at the back of the garden that I can zone for outdoor projects, and I want to do some ironwork so naturally bought a woodsaw and hatchet.  Between those and some good garden shears I've been able to start the land clearance I'll need before the garden bursts into life with the upcoming spring growth.

It's a dependency satisfying side-quest, a matter of tracing the cause-and-effect back until I get from the ideal set-up to the status quo.  And the status quo is an overgrown area, a vegetable plot and a garden shed.

The Space
We're fortunate enough to have a bit of space at the back of the house, and the rear portion of it looks ideal for a toolshed. The entire width of the garden is about 25 feet, and in the back portion of that stands a garden shed, a vegetable plot and some unused land.  The rear of the property is a brick wall, one side is a 4" high fence with some bushes and the right side is 8" evergreen hedges and some trees.

That gives me an area about 25x18 feet, with a 6" brick wall along the long edge. I intend to replace the dilapidated old shed with a stone tool shed with a solid workbench, fire-pit and small anvil on a solid block.  I'm going to need a solid base on probably that entire area, which means digging it up.

So... naturally if I want to heat & beat the first step was to do some gardening. Raze the bushes so I can dig the earth to lay a concrete base to build a tool shed on. Then I'll be setup for metalworking. I'm thinking of keeping enough space for some seating - a couple of benches, but I might make those myself once I've got some toolworking space.  And to be honest if I'm making a bench, I'll probably make my own nails at the forge.

There are plenty of other hardware projects that'll go alongside this. The question of a smelting fire and crucible have come up.  We had a crucible at the forge I as at before but I was never brave enough to try it.  It was also an antique, and probably against conservation guidelines to use it anyway.  But smelting brass or aluminium isn't so much hassle, and you need to get to about a thousand degrees which is quite achievable in a small fire and I'm game.

So, that's hardware mode. It's a weekend project, and I'll try and get some "before" pictures taken so we can document the transformation.

A most Practical lesson in Clean Code

Our wireless thermostat recently shuffled off its digital coil and I can only assume is on its descent to robot hell.  The maldesign on the device is subtle that you can imagine even a half-competent engineer signing off the specifications without noticing the error.

Just to be clear - this isn’t a metaphor or some contrived example to prove a point - although I’m hoping one day it will be. Our thermostat is broken, its the middle of winter and we are very cold.

The thermostats wireless receiver is a mains powered device that sits in an operations chain in series with the timer control unit. Every few minutes the thermostat receiver polls the wireless thermostat and the input line from the timer. If both are true, it flipflops its output to TRUE - and the heating comes on.

As an additional feature the unit also has a manual override button - so if you want to ignore the thermostat and timer input you can force your heating on. I won’t go all UML on this right now, but you can imagine a reasonably simple diagram that explains this all.

But what I’m facing with a faulty thermostat and its faulty “Manual Override” button. I’ve seen the wiring diagram - an override switch that bypassed the circuitry isn’t very difficult to add. It’d literally be a switch that shorts two physical wires. I don’t want a “manual override” button that relies on the same faulty circuitry that I’m trying to override - I want an external independent mechanism.

The override should adhere to the same interface declaration as the normal thermostat, have the same dependencies at a factory level, but its operation entirely driven by a public method. That way, it could be injected into a test with an instantiated timer or used if thermostasis isn’t a customer requirement for this sprint.

And then BAM! My thermostat was just a metaphor* for The Substitution Principle all along!  Its not always enough just to assume that because you declared an interface and implemented it that you have covered all the bases. Zero-To-One is a great step, but Zero-To-One-To-Many is the path you are trying to lay down to make maintenance easier.

And that’s the take-home lesson for today, in a very practical sense. Clean-Code programming lessons in applied engineering:

• The Thermostat, the Override and the Timer should all fill the signal control interface. (Substitution Principle)
• The signal control interface should just be concerned with being a programmable gate. Two input wires, One output wire. (Interface Segregation)
• Each component should do what is says on the tin (Ronseals Law)
• The factory should be responsible for constructing and wiring them together (Factory Construction)
• Each object should pass its signal on to the next (Dependency Injection)
• The override responsibility and the thermostat responsibility should not live in the same object (Single Responsibility Principle)

Until next time: Enjoy your warm house, keep coding, and remember to think inside the box!

 * = Actually not a metaphor, our house really is brass monkeys right now.

Programming with the Man Flu (Comfort Zone Programming)

To cut the explanation short, Last week I was taken out of action for four or five days with Man Flu. And like all sofa-bound individuals reached for the trusty laptop and immediately opened my IDE to get some uninterrupted* programming time in with the determination that this wasn't going to be a total waste of time.

* = Programming time was frequently interrupted by naptime.

Attempts at developing software under these conditions were met with varying degrees of success - some tasks were quite possible while others not so much.Your brain uses some 20% of your energy, and in my energy-restricted flu-coma my immune system had clearly decided to shut down those pesky thought processes that were hogging system resources.

The end result was a pared-back subset of programming and refactoring skills and I was focused on just doing the things I knew how to do - the core actions that I could perform on autopilot. Coding in my Comfort Zone.

Comfort Zone programming is a reflection on your skillset, and in your confidence in those skills. I naturally tended toward the things I found easiest and away from 'difficult' tasks - when you have no brainwidth, go with what you know.

Over this time I performed several pre-emptive refactors of non-critical systems. Clearly I could spot problems, demeter violations, better injection patterns - but lacked the judgement to ignore problems off the critical path.  I was also quite happy spending a few hours writing some packet processors for data bytestreams, which I attribute to a lot of the image processing and network code I've written in the past rising to the surface.

While dying from Man Flu isn't a great way to identify your comfort zone - and not an experience I'd recommend for anybody - The process of identifying what you are good at provides value not only because you can Keep Doing It, but also because you can stretch further, learn something and better yourself.

Comfort Zone programming has helped me learn which skills I default to when times are hard - what my reflex actions are - who my autopilot is.

Learning what to learn is one of the hardest skills to develop, and in this instance I've got a list of the "difficult" tasks my fever brain avoided, and my programming autopilot wasn't able to handle.  Over the coming weeks I'll be able to reflect upon that list and get practice at my weaker refactoring and programming skills, to drill them into my brain until even my autopilot can manage them.

The take home lesson here - and your challenge, should you decide to accept it, is to get out of your comfort zone. And a great way to do that might just be to get in to your comfort zone and see what it looks like. Identify the skills that you don't use enough, follow the advice you frequently ignore.

Drive By Refactoring

Today's post is a code post, specifically about homebrew programming but actually about programming mindsets in general. I've done some code review recently - professional, personal and random internet peoples code where I just look at what they are doing and see how it differs from what I've seen before.

I'm going to talk about the style of code reviews I've been enjoying recently - drive-by-refactors. In a formal review or refactor process, its sometimes difficult to know what to focus on and its easy to go into too much or too little detail. The Drive-By-Refactor is a way of identifying which changes you need to make and which  can wait.

As an example, I was quickly browsing the API of a package, and about to use it when I noticed an unusual declaration...
public: virtual void MyMethod( int parameter ) {}
Spotting a method in an interface with a default implementation led to a drive-by refactor.  Why a default implementation? Does the concrete class implement it? This rather poor practice has probably pushed a compile-time error to a runtime error.
Of course I changed it to a pure virtual / abstract declaration and boom! compile error. Could not instantiate abstract class.  The game is afoot!
I followed the trail of breadcrumbs and found the problem.  It used to take a filename and now takes a file handle, but the interface had both methods with the obsolete one providing a default implementation.

The drive-by refactor is fun because they are generally small, self-motivated and quality driven. You get to flex one of the too-often underused refactoring tools - the gut feeling. Often referred to as code smells, your gut reaction to a bad fragment of code can count for a lot and you have the chance to eye-spy a problem before it gets any worse.

Drive-By refactors can be great for those moments where you spot a problem and want to investigate, but sometimes you don't need to take any action beyond noting that you've found a problem - in this case just leave a tagged refactor comment and carry on driving would have been enough.
There are times when you don't need to take immediate action and it's acceptable to describe the problem in a comment and move on.
A drive-by review is a quick overview of code where you don't get to see the detail, but do spot the sore-thumbs. You are only going to spot things that are obviously wrong, and you'll find your tolerance for wrong shifts the more you review.

This brings us on to the second thing that a drive-by spots. It spots review comments where you-in-the-past or somebody else has written "Law of Demeter Violation" or "method doesn't use its parameter" or "method operates on side-effects only" or "this class has too many constructors"
You might see one of those and really agree with it, and decide now is the time to fix it - or you might decide its no sufficient to take action.

And that's the take home lesson for today - when you spot a problem you should make a note of it. Make a note in the code, because that's the only place that it'll be read. Make it useful to the future programmer, be brief, descriptive, concise. To start you only need to point out problems, and you can stop there. A typical drive-by code review for me includes spotting problems or responding to previous review comments as much as it is leaving review comments or making code changes.

Typically I'll invest time in the refactor if the functionality is on the critical path to my current sprint feature set, while if its incidental then I'll leave a review comment.  One day I'll be working in that code anyway and see the previous review suggestion and it might be a good time to deal with it.

By learning to do Drive-By reviews, you practice quick decision making, and its this practice that winds its way into your day-to-day programming. Instead of writing something you know to be second rate, you might find yourself adding a review comment explaining what's wrong with it.
Before long you find yourself writing the review comment, and stopping to fix the problem. It starts to become automatic and you can do it at the smallest level.

Review fast, review often. Read a lot of code. Read what you wrote today, read what you wrote yesterday and learn from it. See which shortcuts you took, and unlearn your bad habits. Study history or find yourself repeating it. Drive-By yesterdays code, free your mind and make different mistakes tomorrow.

I hope you've learned something from the Drive-By refactor and are able to add it to your toolbox. Review code every time you read it. Drive by a lot of code, because the more you see then more you learn, but stop when you need to.