Nerdery Public

Bit of context: in June, I changed companies and thus changed projects. In the world I work in, it can take a bit to get new accounts and be viable as a developer, so I think by mid July I was committing code into an established baseline for a monolith service. Technical architecture: Spring Boot, providing RESTful services, interacting with JPA repositories, and a smidge of interacting via Feign clients out to another service. Code is there, can be interactively debugged, etc. Plenty of meat to dig into, plenty of tools to do it with, but a decently robust codebase for a heavily used system for our customers.

Over the summer, we changed objectives. Instead of adding new capabilities to the project, we were figuring out how to safely port it to another environment, where most of the original code for the monolith wouldn’t make it just yet. E.g., rearchitecture it a bit, figure out how we could stub some things out, borrow what we could of the build system, and make it work. Our code would be developed in the new environment and imported into the old, and the goal was to be able to develop new things while not breaking things in the old. Challenging, particularly since the old thing was still moving forward with or without us. Still the same technical architecture, but less code to work with (since not all of the production code made it into our new environment). And moving targets on versioning: is our version foo+1 compatible with the production foo+1 in the production environment? Did they change something we rely upon? Note that things don’t change often in the areas we’re dealing with, but, since the production code’s model is that all things are at the same version, there’s a bit of extra strat-eg-ery to work through. And, of course, we don’t have a strongly built out test dataset or deployment infrastructure in the new environment.

We’re not quite resolved as of early October. But now we’re pivoting to a new thing. Entirely new objectives, entirely new codebase, entirely new architecture. Switch to providing multiple microservices, using Reactive programming and API calls for the microservices. Reading up this morning on Reactive programming, I was relieved to see the statement: “If you’re familiar with Spring MVC and building REST APIs, you’ll enjoy Spring WebFlux. There’s just a few basic concepts that are different.” (1). I’ve long thought Matt Raible was a good geek whisperer, from I think well back in Struts and AppFuse development days.. Matt apparently collaborates with Josh Long (@starbuxman), who wrote much of the code Matt included in that post. So I hop out to @starbuxman and see the following near the top of his feed:

Amused that “a few basic concepts that are different” could translate to “480 pages 😯”. Recognizing that reactive style programming’s been out for a few years now and is a mature construct, I’m not super worried. I do have some development background in asynchronous programming and event handling, after all, based on an interesting websockets-based web user interface I built out a few years ago. Still hoping that 480 pages of “Reactive Spring” is really a rehash of “everything you otherwise need to generally know about Spring” with a few extra Reactive details. Else I’ll start keeping this emoji ( ☢️ ) a little closer at hand and “reactive” might start referring to my facial expression when we get the next new shift in direction.

I created a new Git project on my GitHub profile today as I began some work on a possible conference presentation. I was surprised to see a message that said I’d received an achievement badge because I’d “contributed code to the 2020 GitHub Archive Program and now have a badge for it. Thank you for being part of the program!”

Clicking through the Archive program link to find out more, I saw that “On 02/02/2020 GitHub captured a snapshot of every active public repository. Those millions of repos were then archived to hardened film designed to last for 1,000 years, and stored in the GitHub Arctic Code Vault in a decommissioned coal mine deep beneath an Arctic mountain in Svalbard, Norway.”

Which sounds kind of cool, in more ways than one. However, I’m not excited about not really getting a way to opt out of that archive. Although the message on the achievement badge notification says something about being able to opt out in settings, clicking through to settings doesn’t take me anywhere that makes it clear what setting I’d need to adjust. Further, if they’ve already “archived to hardened film designed to last for 1,000 years”, thinking any setting I list now is sort of moot anyway.

This isn’t the only usage of code item GitHub’s made public lately: their new CoPilot program uses the source of public code repositories, apparently regardless of the license used by the repository owner. Starting to wonder if I need to check more seriously into Gitlab’s offerings….

Was dismayed to discover this morning that O’Reilly is no longer putting on in-person conferences, to include the wonderful OSCON conference I so enjoyed both attending and presenting for. I tripped across that news today when I went to find links to my previous talks (2014, 2016). Both talks were based around the idea of delivering the bad news that your build is broken by way of obnoxious Furby chatter. I had submitted talk topics for several years before that first talk got picked up – guess the conference review assessors similarly thought Furbies might be hard to look away from.

So, farewell, OSCON, Strata, and an abundance of other conferences. I’ve been finding my geek conference fix in other places of late, more related to cyber, and it’s not as if there isn’t an abundance of ways to learn in person and online. But OSCON will forever hold a sweet spot in my heart.