Within the last two years the air above Santa Rosa has become thick with ash, acrid, and severely unhealthy. A year ago the immensely destructive Tubbs Fire bore down on northern Santa Rosa obliterating thousands of homes. For days afterwards the skies were filled with the smoke and ash from the epic destruction.

Whenever possible, I typically send much of my traffic through the Tor network, including traffic to some services which I operate for myself, such as a secure shell server. When I am traveling or otherwise not on my home network, I use one of Tor’s more fun features: Onion Services (formerly known as Hidden Services). Onion Services can be identified by the *.onion top-level domain and allow the server’s location to be anonymous/concealed just like the client.

One year ago today, I watched the Sonoma county fires pour over Shiloh ridge towards the Fountaingrove neighborhood. I wrote about the experience, and subsequent evacuation in “Watching fire come down the mountain”. The response across Sonoma county to the fires was as monumental as the fires themselves, and for my part, I spent the next two weeks working with old and new friends to build and support Sonoma Fire Info to strive to get as much accurate information to our fellow residents as possible.

Santa Rosa is a wonderful city located within Sonoma county, and I have been encouraging just about anybody who will listen to come visit since I moved here some years ago. Glossing over a bunch of details, one year ago today the fires began, which tore into Santa Rosa. In reaction to that, a few of my friends and I, along with a number of other hackers and volunteers created Sonoma Fire Info. Some time after the fires were contained, a few of us set out to create something in response to rebuild in a different way, something would help invigorate the area we know and love, we created Startup Sonoma County

A number of organizations I am part of use Google Apps for their Email, Calendaring, Storage, etc, which means that I recently became one of the millions of users who recently had too much load time, excessive white-space, and awkwardly huge buttons foisted upon them by the new Gmail re-design. On my 13” large screen, the new design leaves far too little space for email, which seems like perhaps somebody missed the point.

For Jenkins, the plugin ecosystem is one of its key advantages over other tools offering some similar functionality. That power and flexibility does not come without its own set of problems for the project itself. From an outsiders perspective, the challenges around dependency and update management between Jenkins plugins is a substantial topic, worthy of at least a couple of doctoral theses in computer science and sociology respectively. For insiders within the Jenkins developer community, the relations between plugins in the ecosystem makes a bizarre kind of sense. Like the tax code, it’s something you figure out how to work within, but never dare dig in too deeply, for fear of your head exploding. In this blog post, I’d like to share my philosophy on how we, the Jenkins project, should think about plugin dependencies and how that contrasts to the status quo.

It took me a little while to get comfortable with TypeScript when used in conjunction with Feathers. I have found the combination to be quite useful for building small little web APIs and applications over the past couple months, but starting from scratch has been a bit of a pain. Tweaking all the configuration files, and getting all the right dependencies installed is not somemthing I want to keep resident in my memory, so I have created this feathers-typescript-starter repository.

I have been using Feathers for a number of projects lately, including the backend and client for Jenkins Evergreen. It is obvious from the design and structure of Feathers that a significant amount of thought went into its development. Overall, I have been happy with the experience implementing clean APIs, and have added Feathers as my default toolchain for new web API and application development. Feathers has been great for building JSON-based RESTful APIs, but I stumbled over some hurdles when using it as a more traditional web application framework.

Almost every web framework I have used in the past five years shares the same stupid flaw: mishandling of redundant slashes. Invariably this causes problems when some script somewhere joins URL segments together with multiple slashes in them, and ends up receiving a 404.

I find posts from other hackers on their equipment to be rather interesting and figured I should share my latest Minimum Equipment List. Lately I haven’t been traveling, but I tend to move around Santa Rosa and the greater Bay Area with a fairly standard set of equipment regardless of the distance I’m traveling. My international trips usually necessitate a larger wardrobe, but the bag on my back remains very consistent.

Kubernetes is so hot right now. So hot. Not to brag, but the Jenkins has been using Kubernetes for a couple years, in production even! While Kubernetes is certainly worth the hype, so hot, I have traditionally done all of my development with Kubernetes resources using a personal Azure Kubernetes Service instance rather than running minikube locally. Recently I took some time to do some hobby-hacking, which included some Kubernetes work, and ended up revisiting using minikube on my local machine. It went…okay.

This year I got tired of my strapped bike pedals and decided to get a smidge more serious by purchasing clip-in pedals. Going into it, I knew that there was a high risk of falling over at a stop light or any number of the calamities other cyclists have experienced when their feet become attached to the bike frame.

In my previous post I mentioned Jenkins Evergreen which requires a significant backend service to built and deployed to manage a pushed-update lifecycle. The prototype of that service which I wrote sometime late last year was in Ruby, but I quickly realized that my usual comfort area of Ruby and Python were not going to meet some requirements for the service. Consequently, I ventured into JavaScript, with the fantastic framework FeathersJS. Almost a year later, I now have some thoughts on the strengths and weaknesses of server-side JavaScript, and have in turn started to explore TypeScript. Overall I have found TypeScript to be interesting, but it is not without its weaknesses.

This year I’ve been working on an ambitious new project referred to as Jenkins Evergreen. It is ambitious in that we’re aiming to significantly alter the way in which Jenkins is downloaded, updated, and used. In most visible ways Evergreen is the same as a traditional Jenkins installation, but the way it is assembled into a package and delivered is radically different. Among the many challenges which the Evergreen project must tackle, there is one problem in common with most other organizations: how do you take a big, complex system, and make it continuously deliverable.

You might not be surprised to know that among my many views and opinions, I have given serious consideration to writing instruments. While much of my day is consumed by typing away on the keyboard, I carry no fewer than three notebooks with me at all times, filling each with tasks, ideas, designs, and so on. The paper notebook for me is a scratchpad for my own thought process. There are numerous spiral bound pages in my office which hold early designs for many of the products I have built, and probably more from those more crazy designs which I was not able to build.

A link was sent my way to the Redis Labs “Commons Clause”, which definitely raised my eyebrow. While the Commons Clause, as defined by Redis Labs, does not apply to Redis itself, it is applied to their non-closed source software.

Somehow I have been blogging for over eleven years now. When I first registered unethicalblogger.com it more or less a joke in response to a deluge of holier-than-thou rhetoric about the “ethics of blogging”, as if it were anything more than soap-boxing on the internet.

1. Configuration languages are too complex; YAML is much simpler and easier to understand.
2. Declarative YAML configuration is brilliant.
3. Lots of our things look similar, we have too much copy and pasted YAML.
4. We’ve written a tool which uses templates and parameters to dynamically generate our YAML
5. The declarative YAML format now supports conditional, iteration, and inheritance syntax; it is now turing complete.

This year I have started to see a new buzzword get thrown around, one which I can feel especially hipstery about: GitOps. While the folks over at WeaveWorks have made the term fashionable in the Kubernetes ecosystem, stodgy old-timer Puppet users might recognize the same practices they’ve used for a few years now by combining R10k and Git. In fact, I was first introduced to the concept by Gary Larizza, an absolutely loud, foul-mouthed, and wonderful hacker. The concepts Gary blogged about I rapidly introduced to the Jenkins project’s own Puppet-based infrastructure. This blog post isn’t about how sunglasses-at-night cool all us Puppet users have been, but instead I wished to clarify some areas where “GitOps” as a practice falls short, and what is needed to compensate.

The wind carries the spring
along the roadside
down, over, and through the hills.