Huh, I realised I had written “farewell” to Blue Systems and Calamares back in may – Calamares is still trundling along at a much reduced pace – but have not yet written about where I went to work. So, let’s fill in a little of that. I work at Vimec, which makes glass inspection machines. I went to work there because I know nothing about glass inspection, but I do know about C++, Qt, and CMake. So I’ll learn about glass while doing my usual software things.

One of the things I notice is how “Open-Source”-ish work is. Vimec is a small company, and I can best describe a work day as “like a KDE sprint, but only from 9 to 5”. I sit down at a Linux workstation, log into KDE Plasma (backed by Active Directory, that’s the corporate angle there), poke at GitLab to see what went down overnight, git pull to see what’s up, and then fire up the editor of my choice to get stuff done.

Some thoughts about Editors

Kate (https://kate-editor.org/) is amazeballs, always. I don’t use IDE auto-completion or code-following all that much, so having a fast and configurable editor is the most important thing. I have configured the build plugin for Kate to connect to my docker build-container and do the thing: build the software. What it doesn’t do well is build truly remotely (e.g. on the build cluster). This is something I’ll figure out at some point – along with maybe remote editing.

Kate with the build plugin is really good with C++ errors. Stepping through the errors during a refactoring is quick and painless, even when there’s a lot of them.

VSCode does a lot of things right, like remote editing and remote building (over SSH into a remote docker container). The default keybindings are not Kate, which leaves me slowly rebinding things once a particular key annoys me enough. Support for layered and remote configuration (e.g. in the git repo there’s a file setting up VSCode-specific behavior, along with an .editorconfig for all the sensible editors) is pretty good and allows for a shared and consistent experience for developers.

Building remote with VSCode is really good, but dealing with the resulting errors is a huge pain in the butt. The display is large and intrusive, breaks screen layout, and is insufficiently de-duplicated. I end up fixing one thing and then rebuilding, rather than what Kate helps me do: fix a dozen things, then rebuild when I run out of things to fix. VSCode is nice when writing new code, not when refactoring.

CLion has some really cool-looking remote development tools, and I think this could be an excellent tool based on the description of the features. I found using it just too clunky, though, and I couldn’t get the remote features working on FreeBSD at all, and only in limited fashion on Linux. I tried it for a couple of weeks and it just didn’t take.

You might notice the absence of KDevelop (https://www.kdevelop.org/). It doesn’t add much compared to Kate for the use-cases I have. If there was LSP and remote building in KDevelop, I would switch back to that in a flash. It’s the IDE of my choice for whatever non-work-work coding I still do.

Some thoughts about GitLab

I think work-work has the Enterprise Edition. I can’t really tell. Participating in KDE development has been a huge benefit here, because I’m already used to a GitLab workflow. With setting “pipeline must succeed before merge”, it’s always summer in the develop branch. We use a branchy merge-commit workflow, but with rebases. This leads to a git alligator like history. Approval for merge requests is mandatory, but in a small team that means shouting in text chat “this thing is done” and waiting for someone to eyeball it well.

Since I spend a fair amount of time every day clicking around GitLab, I notice now how much it gets out of your way for getting things done. I like it more when using it heavily with just a handful of projects (the KDE GitLab has over 1000 projects, which makes it kind of unwieldy to navigate, but once settled in in one place it’s much nicer). The only feature I miss is “show me last night’s scheduled pipeline”.

Some thoughts about Glass

Kidding. I still don’t know much about glass. The company sent everyone to a trade fair (in shifts) to see what was up, so now I have a great deal of respect for mechanical engineering where half-kilogram blobs of glass at 800 degrees C are thrown around at a rate of two per second. And for the melting point of tin. And for suction cups, and recyclable conveyor belts, and .. all the things that I wouldn’t normally think about, in the abstractions of software.

Take Away

I suppose I should have learned this, from prior job changes, but I notice that at the end of a day of KDE-like programming, I don’t have much energy left over for more actually-KDE programming. I sit down to do a little light Python or Haskell more than C++ these days, for kicks.