Recently I have been exploring using Diesel for a simple Rust web application. I quickly ran into a very confusing trait bound error, listed below when integrating with chrono. It took me a while to understand and fix the error, which I thought I should write down for later!

I stumbled into an annoying problem yesterday when setting up Onion Services for the Gopher site(s) I operate on a FreeBSD machine: two different rc.d scripts were conflicting.

Never trust a developer who praises the purity or elegance of the C programming language. I find comparisons often made between Rust and C for “systems programming” to be one of my least favorite, and most disingenuous discussion topics among developers on the internet. It’s like comparing roller skates to an electric car. While they both can transport you from one place to another, only one of them is likely going to bring you safely to your destination.

Good news everyone! This site can now be accessed via a Tor Onion Service. While the main site brokenco.de is served via GitHub Pages for HTTP, the entirety of this content is also available at the following onion (v3) service:

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!