The latest project – improving the home’s sprinkler system, part I of probably a lot

I normally don’t play much with hardware, mainly because there isn’t/wasn’t much I want to do that tends to require hardware that’s not a regular PC or maybe a phone or tablet. This one is different, because no self-respecting geek would want the usual rotary control “programmable” timer to run their sprinkler system, would they?

We do live at the edge of the desert and we have pretty strict watering restrictions here. I’m all for it – water being a finite resource and all that – and I want to improve our existing sprinkler system at the same time. It doesn’t help that the people who set up the sprinklers were probably among the lower bidders, to put it politely. OK, to be blunt they seem to have failed the “giving a shit” test when they put the system together. I’ve spent a lot of  last year’s “gardening hours” just trying to make it work somewhat. Not well, just “somewhat”. Time to fix that.

First step was researching hardware. I’m comfortable with Unix type OSs (obviously) and with seemingly the world and their dogs releasing small, low power consumption embedded Linux devices I figured one of them would be perfect. The original plan was to get a Raspberry Pi or a BeagleBone with relay shield/cape and drive the sprinkler valves that way. A bit more poking around the web led me to the various OpenSprinkler modules (standalone, Raspberry Pi shield and BeagleBone cape) and they look ideal for what I have in mind. I’m planning to order the Raspberry Pi version as one of the nice touches is that the Raspbian repository has packages for the Java JDK, which gives me bad ideas of hacking parts of the sprinkler system in Clojure or Armed Bear Common Lisp. I’m not sure that the system is powerful to run either, but one can dream.

The good thing about the various OpenSprinkler systems is that they have the 24V to 5V converter on board so the power supply isn’t a problem. There is already open source software for them that covers the normal requirements and either of them can control enough valves for our current needs without resorting to genius solutions like running two valves off the same controller output because someone installed a wiring loom that is one wire short of being able to control all valves individually. Apparently the fact that the water pressure wasn’t high enough to run two zones at the same time fell in the category of “not giving a shit”.

The next step after getting the hardware is to run convert the existing system to run off the new controller with some additional wiring to be able to control all zones individually. This will require fixing up some of the wiring issues and will also have to tie in with my project of running some Ethernet wiring around the house unless I decide to go wireless for the sprinkler controller. Haven’t figured that part out yet. Given that the controller is “headless” I’m tempted to hide it away out of sight and just run Ethernet and 24V power to it.

Once it’s all up and running I’ll look into adding some sensors for a bit more fine-grained control over the system. Rain sensors are not really helpful out here as it hardly ever rains during irrigation season. I’m thinking about adding at least a couple of moisture sensors for some of the more sensitive plants to ensure that they get the appropriate amount of water but not more than necessary. Not sure I’ll get around to that part this year, first the system needs to be up and running reliably before I go and break it again.

Stay tuned.

I prefer ConEmu over Console2, and so should you…

OK, I admit it – I’m a dinosaur. I still use the command line a lot as I’m subscribing to the belief that I can often type faster than I can move my hand off the keyboard to the mouse, click, and move my hand back. Plus, I grew up in an era when the command line was what you got when you turned on the computer, and Windows 2.0 or GEM was a big improvement.

One of the neat features of the console emulators on both on Linux and Mac OS X was and is that you could run a set of shells in a tabbed single console window. A post on Scott Hanselman’s blog put me onto Console2. That was more like it and I pretty much immediately housed my Windows shells – either cmd.exe or PowerShell – in there. Much better, but over time the pace of development slowed and the last beta release dates from 2011. It’s not like the Beta is buggy or anything – in fact, in my experience it works very nicely indeed – but of course as a software engineer I like shiny new things.

Enter, via another post on Scott Hanselman’s blog, ConEmu – or ConEmu-Maximus5, to give it its full name. If Console2 is the VW Golf to the stock Windows’ console emulator’s 1200cc VW Bug, then ConEmu is the VW Phaeton to Console2’s VW Golf. It’s got a lot more features, it’s actively developed, it works well with Far Manager if you miss the Norton Commander days and it’s highly configurable. Of course, it also can handle transparent backgrounds, but so can Console2.

For me, it has one killer feature – recent versions detect which shells you have installed on your machine and offer you a selection via the green “new tab” button (the one that looks a bit like a French Pharmacy sign), with a choice of running them either as a regular user or admin user:

ConEmu with visible command line processor menu
ConEmu with visible command line processor menu

Why is this such a big deal? Well, it’s neat if you’re using both PowerShell and cmd.exe, but for me it’s a killer feature because I like using TCC/LE, at least at home. TCC/LE is the familiar Windows command prompt at first glance but in the same way that ConEmu is a much expanded console emulator compared to the regular Windows one, TCC/LE is a much expanded command prompt that is a lot more feature rich and has a lot of sensible extensions. And because I’m such a dinosaur, I’ve actually been using its predecessors (4DOS and 4NT) way back when they were distributed as shareware on a floppy disk and you had to buy the manuals for them to get the registration code. And yes, I still have at least the 4DOS manual.

Back to console emulators, though. If I wanted to go nitpicking, both ConEmu and Console2 work less well over an RDP connection than the stock console, which is noticeable if you tend to remote into machines quite frequently. It’s not that they work badly, but Microsoft clearly spent a lot of time optimising the stock console to work well over RDP (or to have RDP work well with the stock console), so there is a bit of lag when scrolling. It doesn’t make either tool unusable but you notice it’s there.

Anyway, if you check out one new tool this week, make it ConEmu.

The coder/programmer/software engineer debate seems to be rising from the undead again

First, a confession – I actually occasionally call myself a coder, but in a tongue in cheek, post-modern and ironic way. Heck, it does make for a good blog title and license plate.

Nevertheless, with all the recent “coding schools” cropping up all over the place – at least if you are in the Bay Area – it does seem that being able to code in the context of a reasonably sought after web technology without much further formal training is the path to new, fulfilling careers and of course untold riches in an economy where recent graduates in all fields have problems finding work. Well, at least a career that allows you to rent a room instead of crashing on somebody’s couch.

There are some problems with the whole “mere coder” thing. Dave Winer has some interesting thoughts on his blog, and I agree with a lot of what he says. Scott Radcliff has some additional thoughts, which I also find myself agreeing with a lot.

The process of building a software system is a lot more than just coding unless you subscribe to the view that all the coders do is to take the gospel handed down by A Visionary Leader and convert it into software. Anybody who’s ever built a moderately complex system knows that software doesn’t happen that way, at least not the type of software that doesn’t collapse under its own weight shortly after its release. Of course that doesn’t sit well with the notion of The Visionary Genius that is all that is required to build the next and the narrative doesn’t work at all once you recognise that building software is, in most cases, a team sport.

Expecting someone who has learned to write code to o create a great piece of software is like expecting someone who’s just gone through a foreign language course of similar length to go and write the next great novel in that particular language. Sometimes you get lucky, but most of the time the flow isn’t there, the language isn’t yet used in an idiomatic way and all that together makes for less than an enjoyable experience. Some of the people who manage to enter the profession of software development will learn on the job and grow into people who can build robust, maintainable systems and those are to be congratulated.

The way most people use the term coder, ie in a non-postmodern ironic way, reminds me very much of the time when a programmer’s job was to unthinkingly program as part of a little cog in the giant waterfall development machine, which led to the WIMP (Why Isn’t Mary Programming) acronym. Basically, if the keyboard wasn’t constantly clattering, there was no programming going on.

That said, maybe we are at a point in time where an army of coders as the modern equivalent of the typing pool is able to create good enough software. Given that most users are conditioned to believe that software is infuriating and buggy, we as an industry might well get away with. Is that the world we want to live in, though?

As creators of software, we do have the ability to choose the environment that we work and live in. If you care about quality, work with like-minded people.

Me? I prefer to call myself a software craftsman. I’m not an engineer, I write code but that’s almost an afterthought once the design is figured out but at the end of the day what I do is build something that wasn’t there before, using vague guidelines that are wrong as often as they are right while trying to tease out what the customer needs rather than what they tell me they want. In most cases there is no detailed blueprint, no perfect specification that only needs to be translated 1:1 into lines of code. Instead, I get to use my experience and judgement to fill in the blanks that most people – myself included – probably didn’t even think were there.

Sounds like a job for a craftsman to me.

Initial thoughts on Swift

Like pretty much every other programmer with a Mac, I’m currently looking at Swift. Will I write anything but toy programs in it? I don’t know yet – I don’t really write any Mac-ish software on my Mac,  just unix-ish programs. If Swift doesn’t escape the OS X and iOS ecosystems it’ll be a nice exercise in a neat language that’s not really that relevant to the world at large, or at least to my part of the world at large. Not that this sort of vendor lock-in can’t work well – Visual Basic 6, anybody?

I hope Apple will open the language to be used outside its software ecosystem but from what I have read so far, it’s tightly integrated into the iOS and Mac OS X runtimes so I’m not sure how feasible that even would be. Still, I’m pretty sure it’ll remain on my list of languages to play with.

Someone is building a BBC Micro emulator in Javascript

For those of us who remember when the BBC Micro was the home computer with the fastest Basic implementation available, a long time ago, and was pretty legendary in home computing circles in Europe. It didn’t sell that much outside of the UK, mostly because of its price. It was also the target system for the original implementation of Elite. Matt Godbolt is building an emulator in JavaScript. First post of his series can be found here.

It’s amazing how far we have come since I started playing with computers, yet they’re still not fast enough.