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.

I recently came across this post from Nick Heer castigating “the bullshit web.” A term he uses to describe the fairly despicable state of modern web applications. While I overwhelmingly agree with the points he lays out, especially in his disparaging remarks towards AMP, I think there’s more to be said about alternative approaches for web users to once again experience the web without the bullshit.

With the latest (quantum!) releases of Firefox, a number of things changed for the better but one of the few things that seemed to get worse was the Open File dialog. I tend to use the dialog quite frequently to open up HTML generated reports from test and coverage tooling, and with the newer Firefox versions I had become very frustrated with the mouse-heavy requirements to use the dialog.

Living in Northern California has taught me many valuable lessons, but perhaps the most fundamental has been to appreciate high quality food. This appreciation was further enhanced when I started a garden, and began to savor freshly grown, vine-ripened, fruits and vegetables. Providing a strong counter-example, my travels to areas without great access to either fresh ingredients or strong culinary culture (strip malls, strip malls everywhere), usually results in a change in my own well-being. An upset stomach really hammers home the importance of high-quality food.

Over the past seven years, the Jenkins project has been an associate project with an umbrella 501(c)3 organization called Software in the Public Interest (SPI). Debian, PostgreSQL, and a number of other associate projects utilize SPI as a legal entity with which they can collect donations and assign intellectual property, such as trademarks. For the past few months I have been coming up to speed as an interim director on the board, replacing a seat vacated, but now I’m running for the seat in the 2018 board election

Some time ago, whenever I started the draft for this blog post, I was discussing with my colleague Kathy why I feel it’s important for people to write out their thoughts in long-form, ideally sharing them via a blog such as this. My reasoning is not to build “your brand”, share information, or anything else like that per se. I find that fundamentally, taking the time to write my thoughts down long-form helps draw more reasoned and nuanced thoughts out, and allows the cultivation of a richer inner mental landscape.

Last season I wrote down some of what I’ve learned about growing tomatoes and made certain to highlight the importance of soil health. Unfortunately this season’s tomatoes aren’t doing as well as I would like, and I’m relatively certain I know the culprit, despite not having the time to correct it: soil health.

Pulling Docker containers from Docker Hub doesn’t require any special handling or credentials, making it quite simple to consume Docker containers in a Jenkins Pipeline. In this blog post however, I’ll describe a simple pattern which I have been using to programmatically publish Docker containers to Docker Hub from a Jenkins Pipeline.

To ignore Node.js as a possibility in certain problem domains, for which it is the best tool for the job, is a tremendously silly and at times unprofessional decision. While I don’t delight in writing JavaScript, I must acknowledge that JavaScript has matured quite nicely over the past ten years. Perhaps the most helpful addition, for me at least, are the async and await keywords which aim to prevent the callback nightmare many casual JavaScript developers may dread.

I have been thinking a lot about customer support over the past two years. My role as “Director of Evangelism” has placed me at the leading edge of what could be referred to as “customer success” or “user education.” What I have come to appreciate, especially in Enterprise-focused startup companies, is the connected and complimentary roles between Product, Engineering, Quality, Evangelism, Customer Support, and Sales. In an Enterprise-focused organization what defines the success for each of these groups is fundamentally the same, but they are not all equally “connected” to the customer’s feedback and concerns.

At my previous company one frequent request made by developers was along the lines of “I want to be able to run a development stack on my machine.” Frankly, I never understood this desire, and still don’t. While I would agree that my laptop is underpowered, running a stack of JVMs and other applications, in addition to a web browser, would bring most machines to a crawl. An ideal alternative, is to simply operate a personal Kubernetes environment in a public cloud. Fortunately, that is now a genuinely simple task.