Tuesday, 11 April 2017

The evolution of a concept

(Dates shown here are very approximate indeed, as is the whole thing.)

Late 2006: The problem first appears. Client needs to send and receive specially-formatted messages via UART, with a few simple inputs and a few simple indicators. There's an existing program that sort of does this, for a different model, but it was written in LabVIEW by some earlier consultant, and none of us speaks LabVIEW, besides which someone would have to buy the development package, which is pricey.

First approach: Cobble up a GUI thing in Scheme, using a widget set that's more or less standard and easy to use. This works, for immediate purposes, but looks to be a nightmare to maintain when there are new models and protocols to be supported.

Later the same year: There's a new model, and a desire for a one-off console thing that's quick, cheap, and somewhat physical. Wire up an AVR to several LEDs and a few switches, and program it to handle the communication protocol. Done!

2008-ish: There's a new family of gadgets, with variations on a few basic communication protocols. Some kind of comm-test software is called for. I've learned a bit of Ruby in the meantime, so that seems like a good language to use. I want to use the Qt widgets, but Qt is still under a licensing scheme that's not favorable to the situation in hand, so GTK+ it is.

I put a bit more effort into building up a framework of sorts, with a collection of custom Ruby widgets built on GTK+. This serves well, with ongoing adjustments, for several years, albeit with annoyances, as later versions of Ruby aren't exactly compatible with 1.8, and later versions of GTK+ aren't fully backward compatible either.

Meanwhile: The licensing scheme for Qt has changed, and it's now available under LGPL, which is fine by me. I re-do the widget collection, for other things (keeping that client's code as it is), using Qt3, then adapt to Qt4.

By maybe 2012-ish, I have thoughts of a test & measurement framework, with GUI, in Ruby, all nicely structured around Ruby objects (which are quite suited to this purpose).

Comes Qt5, with wondrous new features. Me want. But, no Ruby bindings. I don't have time to work on this project anyway, so it gathers dust for more years. I consider dropping Ruby and using Qt's built-in flavor of JavaScript for application-building.

Early 2016: I go off on a new tangent, as inspiration strikes! If I'm playing with JavaScript, why mess with a GUI widget set like Qt or GTK+, when building UIs in HTML - especially this newfangled HTML5! - is dead easy?

So, I think, maybe it's time to split the project into a GUI framework, using HTML5 and the user's browser, and a T&M framework, using node.js, which looks conceptually suitable.

But then I get busy again, and do nothing on the project.

This month: I resume looking at the T&M instrument interfaces, how node.js works, and other sundry matters. The single-threaded, event-driven scheme of node.js doesn't really look all that promising, especially when I figure on exposing scripting features to the user. Also, JavaScript objectness is lame.

But... why, in any case, should the T&M framework (as opposed to the UI framework) involve JavaScript? If it's decoupled from the UI, there's no reason it shouldn't be written in Ruby. And multi-threaded, if that makes sense.

This leaves me with three things to structure:

A lab-GUI framework using HTML5

A T&M framework in Ruby

The communication protocol between the two

Then there'll be test scaffolding, of course, but still: nicely broken-out bits. A fair amount of platform independence. The T&M application can be running on a little Linux SBC* inside a fixture, while the GUI runs on some desktop machine. And, the GUI is optional.

The communication protocol probably looks a lot like JSON objects being passed back and forth over a TCP link (probably with TLS, and maybe with an option to require a client certificate). Doesn't take a lot of architectin', and should be easy to implement on both sides.

So, direction! Purpose! And no more futzin' around with trendy things that don't quite make sense, and trying to figure out how to shoehorn my purposes into their structures.

* Neither RasPi nor BeagleBone, at least not for the applications currently in view. Needs both Ethernet and a gen-u-wine USB host controller. There are small, cheap SBCs out there that fit the requirements. Then, too, I might just design my own li'l Linux board, complete with a gazillion USB host ports.