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!