I have never regretted a bike purchase and my recent acquisition of a Yuba Supermarché is no exception to the rule. I have thoroughly enjoyed the front-loader (non-electric) cargo bike and have already ridden over 25 miles in the past two weeks. The bike has a couple minor annoyances, but one which I had to quickly address has been the tendency for the steering to loosen up, especially over bouncier terrain. In this short post, I would like to document how to tighten the steering up on this cargo bike.

The web is getting faster but feeling slower, something which I have complained about loudly on Twitter but now some folks have put together data to back it up. The web is simultaneously a medium to transmit documents (e.g. an article) and an application platform (e.g. Jira). Anecdotally it seems to me like far too many publishers think of the web only as the latter. There are more and more websites which require significant JavaScript or other multimedia resources to render what ends up being a few paragraphs of text. If you don’t believe me, just visit the website for your local television news station with NoScript turned on. In my own way, I have been resisting this push by keeping this blog as barebones as neceessary to present the content you’re reading now. On a whim, I recently took this idea a little bit further by deploying a Gopher site (viewable over HTTP via a proxy).

You never really appreciate disk space until it’s all gone. This morning I noticed that my laptop had come perilously close to exhausting all its available disk space. Oops! Normally I would prune some Docker images with docker system prune -f but this time around I couldn’t blame Docker, the wasted space was due to cargo, critical part of the Rust development toolchain.

I stumbled across a crate which implemented string parsing that I wished to incorporate into some of my serde.rs deserialization code. Unfortunately the crate in question, cron does not implement the #[derive(Deserialize)] macro on its Schedule, so I needed to fiddle with one of serde’s “field attributes” in order to move forward: deserialize_with.

The Real-time Data Platform is one of the fun things we have been building at Scribd since I joined in 2019. Last month I was fortunate enough to share some of our approach in a presentation at Spark and AI Summit titled: “The revolution will be streamed.” At a high level, what I had branded the “Real-time Data Platform” is really: Apache Kafka, Apache Airflow, Structured streaming with Apache Spark, and a smattering of microservices to help shuffle data around. All sitting on top of Delta Lake which acts as an incredibly versatile and useful storage layer for the platform.

Delivering a simple payload to IRC is an ideal use-case for Function-based cloud computing. Last year when GitHub discontinued their service for pushing notifications into IRC channels, I had a perfect situation to couch-hack with a library I had recently discovered: Azure Functions for Rust

The async/await keywords in modern Rust make building high-throughput daemons pretty straightforward, but as I learned that doesn’t necessarily mean “easy.” Last month on the Scribd tech blog wrote about a daemon named hotdog which we deployed into production: Ingesting production logs with Rust. In this post, I would like to write about some of the technical challenges I encountered getting the performance tuned for this async-std based Rust application.

Much of the information I read during the day, not counting e-mail, comes from my RSS reader: Newsboat. Whenever I see an interesting blog post on Twitter or elsewhere, I habitually subscribe the author’s RSS feed. I recently stumbled across an interesting RSS feed which wasn’t served over HTTP, leading me to wonder: how can I subscribe?

I discovered today that since version 8.1, Vim apparently supports spawning a terminal from within the Vim editor. This is a handy little feature that could make life easier for checking documentation, running tests, and so on.

I have been writing a lot of Rust lately and as a consequence I have had to get a lot better at writing unit tests. As if testing along weren’t tricky enough, almost everything I am writing takes advantage of async/await and is running on top of the async-std runtime.

Suddengly managing a remote engineering team may seem like a daunting situation, one which many people are suddently finding themselves in as tech companies institute sudden “work-from-home” policies in response to the Corona virus. If you find yourself in this situation don’t panic. Managing remotely is not significantly different than managing in-person, and your already existing good management and communication habits will greatly help. Nonetheless, I thought I might be able to help newly remote managers by hosting an open office hours, with the first experimental session yesterday in the afternoon PST.

If you are a sysadmin, Open Build Service is one of the tools you should add to your toolbox..today. “OBS”, hosted at build.opensuse.org is one of my favorite “killer apps” for openSUSE, yet for system administrators it has continued to be relatively unknown, but disproportionately valuable. At a high-level OBS is a tool for building and distributing packages, but on build.opensuse.org, there’s a social component which may someday save your bacon!

Build performance has always been important to me, but my pain tolerance has always varied widely depending on the project. The projects I have worked on which require the JVM, such as Jenkins or JRuby/Gradle, anything under 30 seconds seems amazing. For small Node and Ruby projects, anything over a few seconds feels atrocious. Since I’ve been hacking with Rust lately, I haven’t been able to figure out what constitutes “acceptable.” For my relatively small project, incremental compilation was very quick, but for some reason linking the project would talk almost 10 seconds. That seemed pretty unacceptable.

If the people I know tweet enough about something, eventually I’m bound to breakdown and just buy the thing. It happened with the Intel NUC, and now it’s happened with Yubikey. The Yubikey is a USB-based security device that can do a lot of things, but in my case I just need it to act as a security key for a number of websites such as GitHub, Google, and Twitter. Much to my dismay it did not work exactly as I expected right out of the box on my openSUSE-based laptop.

People will sometimes look at my screen covered in terminal windows overflowing with text: “how do read all that?” These moments remind me how inscrutable backend development can appear to the outsider. Today I would like to introduce a tool that I hope makes a some parts a little more easy to understand: Kafkakitty

This year I have been struggling to learn Rust, but I am now pleased to share that I’m finally understanding the language. Earlier I lamented the challenges of adopting Rust. Between semantically important apostrophes and angle-brackets a plenty, I was struggling to read and write basic Rust. I can easily read Ada, C, Python, JavaScript, Java, and Ruby. Something about the syntax of Rust remained difficult to process. The code looked jarring and dissonant, I could read snippets but translating entire functions or modules into a workable mental model was not feasible. Over the past month however, I believe I have made some progress up the learning curve. I can now write some Rust!

This week we launched the Scribd tech blog, on which I published today’s article: We’re building the largest library in history. I frequently have to remind myself that I have been here less than a year, and we have undergone incredible positive change, with more coming in 2020.

I have a love/hate relationship with containers. We have used containers for production services in the Jenkins project’s infrastructure for six or seven years, where they have been very useful. I run some desktop applications in containers. There are even a few Kubernetes clusters which show the tell-tale signs of my usage. Containers are great. Not a week goes by however when some oddity in containers, or the tools around them, throws a wrench into the gears and causes me great frustration. This week was one of those weeks: we suddenly had problems building our Docker containers in one of our Kubernetes environments.

A number of years ago I was building out a product with a small team, like most teams I’ve worked with, an irreverent sense of humor emerged. One of my colleagues quite enjoyed using the term “bro” ironically; he certainly was the type of person who wouldn’t come within earshot of any group of people who might use the term with any level of seriousness. As the product started to take shape, we found ourselves in need of fake users in our test system. I’m not sure who created this first user, but the user’s fullName was set to “Test Bro.” Shortly thereafter another user was added: “Broam Chomsky.”

TLS certificates have the largest “complexity/importance” scores imaginable. Everything about them is error prone and seemingly over-engineered from top to bottom, yet they are one of the most important pieces of security and authentication in our software architectures. From an engineering management standpoint, I am finding myself adopting the rule of: estimates for any project involving certificates should be multiplied tenfold. If the project involves the Java Virtual Machine (JVM) and the Java Key Store (JKS), multiply by another ten I suppose. For my own future convenience, in this blog post I would like to outline how to add a root certificate to a Java Key Store in Red Hat-derived environments.