Showing posts with label Technology. Show all posts
Showing posts with label Technology. Show all posts

Friday, 1 May 2015

Knife of the week


Hi guys and welcome to Roger In Technology.

This week I've picked a bit of steel to talk about. The invention of steel represented a cornerstone in technology for mankind, allowing tools, machines and weapons to be built to a higher standard and precision than ever before.

From blister steel, through crucible steel to the wide ranges of air, water and oil hardening steels we have today the world has been taken on a one way technological journey. Steel revolutionised all aspects of technology, and new technologies were invented to refine steelmaking.



This is a Gurka Kukri style knife dating to the mid twentieth Century. It's a versatile tool and deadly weapon with a proud military history from one of the most famed and feared military units in the world. 

It's about 34cm and has quite a weight to it because of the broad belly and the width of the spine. In fact this small steel blade weighs easily as much as some steel swords, and is as heavy as a generation of bronze age swords.

Pictured here is the "before" from a restoration work I'm doing. The blade itself has clearly suffered a lot in its life. The blade is dull, and while somebody has attempted to sharpen it they just didn't have the right tools. I'm going to grind a new edge on it and then clean it up with about a 1200 grit and hone the blade.

Kukris are traditionally made from leaf spring steel, which was readily available from scrap vehicles so we can take our best guess on the properties of the steel but to be honest the exact metallurgy isn't too important for the restore work I'm doing.

The blade is showing no scaling or flaking that would be evidence of heat damage, so I'm going to assume the temper is good and we don't have to heat treat it.  Heat treating a blade like this was a daunting task that I wouldn't look forward to, and I was somewhat relieved to see no evidence of overheating on the steel.
In Nepal, there are guys that quench the cutting edge with boiling water and allow the spine to carry its heat and temper the blade. I've got no desire to water quench this mystery steel as there is a good chance I'd crack it and ruin the piece. Actually, I've got no desire to heat-treat this at all, as I'd have to remove the handle and then I'm making a lot of work for myself.

There are some spots where water has go to it, but they appear to be surface marks and will polish right out with some high grit paper. The blade is fullered, which I didn't expect from a Kukri blade where I wouldn't have thought weight reduction was a consideration, but I'll admit to not knowing anything about this type of blade so it might not be that unusual.

Other than that, the blade shape is a little uneven and there is evidence that part it has been ground down. I'll try and get a nice even shape although that will mean a little more materials reduction than would be needed to just sharpen an edge and this brings me back to the temper. If its had a differential temper then the edge will be harder than the spine and I don't want to cut into the steel too much but it looks like I've got no choice.  There is also no point second guessing the properties of a mystery steel. I'll learn a little more by working the metal but for the most part it is what it is.

The handle is maybe a little long for a Kukri, but apparently this isn't unusual for service issue blades, and it appears to be a partial tang which again is traditional.  I first thought it was an integral bolster that had taken some damage but its clearly a second block and this is where the craftsmanship lets the blade down and seriously questions the authenticity of the piece.

I don't like the workmanship on the bolster, I don't like much like the decorative/mosaic pins on the handle either. They look out of place and more what I'd expect from a replica sold to tourists than a functional tool. There is an ugly boss on the pommel too, that can't be seen in this picture, but it doesn't scream quality. The chakmak is missing but the karda is a tiny thing that looks like its been stamped out of a sheet. No attention to detail and no craftsmanship on this which again is probably a bad sign.
Finally in my appraisal of the knife my mind keeps coming back to the uneven blade. Either its been used to hit rocks and somebody has ground those nicks out, or the steel is so soft it picked them up from normal use - so it'll be no good for a knife.  Since I'm already pretty certain it's not an authentic blade, I'm worried the quality of the steel is poor too.

My next step is to grind a new edge on it and sharpen it up. I'll use it to process firewood and see how well it holds an edge. If it survives some pretty rough treatment then I'll clean it up and get a dab of oil on it and it can be used as a camping and woods knife, or out in the garden to clear the brush and weeds.
If the blade goes dull quickly then it'll have more value polished up and looking pretty than cutting anything so I'll get it semi sharp and then polish the hell out of it. I can either mount it on something or sell it on to somebody who cares more about aesthetics than practicality.

Tuesday, 4 February 2014

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.