Clickety clack!

 As usual, it's been a while.

Lots of life changes since the last post, for certain. And with it, new direction and focus. (Or lack thereof.)

I've spent the better part of the past three days diving headlong into code. I have a project that I wanted to develop primarily in C# on Windows and compile it as cross-platform, but there were just too many hurdles that kept jumping in my face to make that practical for me to rapidly develop on. The resulting requirements all but demanded that I develop on and build for Linux (which is a wholly new experience).

C++ was never really my bread and butter, but that's what I ended up starting with. I'm more comfortable in C#, and after the past few days, I've determined that a not insignificant portion of that comfort was really founded in utilizing the crutch of the Visual Studio environment.

Coding in a straight text editor is an entirely different beast. Finding a simple error in a class definition only after the third re-compile, whereas in the past, the IDE would have caught that for me... Those are painful reminders of days long since gone. And I am not nostalgic for them.

Needless to say, I installed VS Code rather quickly.

In any event, I found a rather useful multi-pronged sandbox project: First, I want a console application to communicate with one of my amateur radios over a USB serial interface, grab some essential information (frequency, band, signal strength, mode, &c.) and use those as database fields in a console-based contact logging application. (I haven't found any that I like, so I figure I'll spin my own.)

Handling the serial communications with a radio is not a wheel I want to reinvent. There are too many nuances in the communication spec for even a single manufacturer for me to even think about handling that piece. (Remember, I want rapid!) So to do that, I'm letting the hamlib library talk directly to the radio, and I'm interfacing with hamlib (specifically, rigctld) over TCP.

I did originally want to write that socket code from scratch, but again, time is an issue, so I opted to use the Boost library here to accomplish the I/O. I will also likely use Boost as the springboard for part two.

Ah, part two. That's where I get to dust off the web development neurons. Part two of the project is to expose that data via a web-enabled API so I can easily replicate (and theme) the radio's display on a web page. I haven't settled on the exact architecture for that yet, but most likely a combination of node.js and Angular. Seeing a pretty analog needle swinging across a screen, joined by blinking status indicators and various cosmetic display elements... That's just sweet.

In both cases -- web and console -- I also want the ability to send control selections back to the radio through the hamlib interface.

The long and short of it is that I'd like to wrap up next week with renewed confidence in my coding skills. It's been three or four years since I've done any truly heavy lifting in any language, and another solid five before that since I've considered myself a "real" developer.

That's a really long time to be away from one's passions.

I have a few lessons learned that I will share as this project continues.