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.

One foggy morning a few weeks ago, I received a disk usage alert courtesy of the Jenkins project’s infrastructure on-call rotation. In every infrastructure ever, disk usage alerts seem to be the most common alert to crop up, something somewhere is not properly cleaning up after itself. This time, the alert was from our own Jenkins environment. The logging filesystem wasn’t the problem, the filesystem hosting JENKINS_HOME was perilously close to running out of space. The local time, about 6:20 in the morning, and yours truly was quietly furious at the back of a bus headed into San Francisco for the day.

One of the first pain points many organizations endure when scaling Jenkins is the rapid accumulation of artifacts on their master’s filesystem. Artifacts are typically built packages such as .jar, .tar.gz, or .img files, which are useful to persist after a Pipeline Run has completed for later review as necessary. The problem that manifests over time, is quite predictable, archived artifacts incur significant disk usage on the master’s filesystem and the network traffic necessary to store and serve the artifacts becomes a non-trivial problem for the availability of the Jenkins master.

In this post I would like to share a handy little workaround for returning to Google Hangouts, despite Google Meet. Having narrowly escaped working at Google via acquisitions twice, I have stood by and watched as the Ad Words money-pipe funded rewrite after boondoggle after rewrite. When Google announced “Google Meet” earlier this year as an “enterprise-friendly version” of Google Hangouts, I was annoyed, but not surprised.

After learning how to build my first terrible website, in ye olden days, perhaps the second useful thing I ever really learned was to run multiple websites on a single server using Apache VirtualHosts. The novelty of being able to run more than one application on a server was among the earliest things I recall being excited about. Fast forward to the very different deployment environments we have available today, and I find myself excited about the same basic kinds of things. Today I thought I would share how one can implement a concept similar to Apache’s VirtualHosts across Namespaces in Kubernetes.

This research was funded by CloudBees as part of my work in the CTO’s Office with the vague guideline of “ask interesting questions and then answer them.” It does not represent any specific product direction by CloudBees and was performed with Jenkins, rather than CloudBees products, and Kubernetes 1.8.1 on Azure.

Months ago Microsoft announced Azure Container Instances (ACI), which allow for rapidly provisioning containers “in the cloud.” When they were first announced, I played around with them for a bit, before realizing that the pricing for running a container “full-time” was almost 3x what it would cost to deploy that container on an equitable Standard A0 virtual machine. Since then however, Azure has added support for a “Never” restart policy, which opens the door for using Azure Container Instances for arbitrary task execution.

A couple weeks ago I boarded a plane at the always-adorable Charles M. Schulz Sonoma County Airport en route to Seattle to participate in a Microsoft Azure OpenDev Event. Thanks to my pal Ken Thompson, who recently joined Microsoft as a product marketing manager for their Open Source DevOps team, I was invited to talk about all things Jenkins with a dash of Azure.

2018 will be the sixth year for the Testing/Automation dev room at FOSDEM. This room is about creating better software through a focus on testing and automation at all layers of the stack. From creating libraries and end-user applications all the way down to packaging, distribution and deployment. Testing and automation is not isolated to a single toolchain, language or platform, there is much to learn and share regardless of background!

The traffic on the Bay Bridge connecting San Francisco to Oakland is one of the most congested routes of traffic in all of Northern California. Somehow it gets even worse on Saturday and Sunday. One weekend, a few years ago, I was driving my wife and some of the women from her soccer team back to Berkeley, from a game in San Francisco’s Golden Gate Park. On the east side of the bridge, before inching onto I-580N, I was pretty pissed off, and half-joking half-frustrated shook back-and-forth at the steering wheel “GAHHHHHHHHHHHH.” The woman sitting behind me, who was certainly the “funny one” of the group, put her hand on my arm and gently said “Tyler, this is your reality now.”

The insanely strong gusts of wind would not stop clattering the tin roof panels over the back patio. Begrudgingly, I awoke, dressed, and tried to secure the roof panels before the neighbors got too ornery. Stepping up the ladder, I noticed an orange glow north of the house. Just after midnight, I had not heard any sirens, I jumped into the car on the assumption that one of those houses by the park was burning and had not yet been reported.