Hongli Lai writes a provocative post about his research into Ruby memory bloat. Long-running Ruby process, typically grow in their memory usage over time. It’s common to see Ruby servers being re-started once a day (like on Heroku) to avoid this very issue. In this post, the author proposes that the reason behind memory bloat is not memory fragmentation, like a lot of people in the community assume. Instead, he points to the memory allocator (
malloc) not releasing memory. I am not very familiar with memory allocation, so I am left wondering if other languages that also use
mallocsuffer from the same issue as Ruby.
Akira Matsuda released a new templating engine with a novel take. The standard template engine in Ruby is
ERB. It’s the default in Rails when rendering HTML. A user typically starts with HTML and sprinkles in special tags that get processed as ruby and replaced. HAML, is an alternative that was designed to avoid writing inline code in a web document. It always generates valid HTML, because it functions as a DSL. The down-side is that one must learn the new syntax. That is where HIML comes in: It produces valid HTML and provides some of the conveniences of HAML (e.g. autoclosing tags), but as intuitive as HTML and ERB.
<section> <!-- This will auto-close! --> <div> <!-- As will this --> <%= post.content %> <!-- Standard way to interpolate ruby code -->
Jess Frazelle explains the qualities that a distinguished engineer or technical fellow should exhibit. The list is solid and resonates with my views. My only bone to pick is with the often-repeated adage: Have strong opinions, loosely held. I don’t think that is quite accurate. Opinions held in strength proportional to the weight of the evidence doesn’t have the same ring to it. I understand if it doesn’t catch on. Note that the actual description under the heading is spot on:
They do not need to have opinions on everything, that would be pedantic. Technical leaders should be able to use their experience to help others succeed, while also empowering others to own solutions.
As a Software Engineer, I spend most of my day working on a computer. Over the years, I’ve come to customize my setup to align better to the way I work and become more efficient. Efficiency is important because of the time you save, but not because you can do more with the time saved. It’s allows you to keep focus on what you want to accomplish, instead of the mechanics of accomplishing it.
Vineet Gopal from Benchling writes an interesting post about their approach to running migrations on highly-contested databases in production. A new concept for me was that they automatically retry migrations that fail due to lock timeouts. This reduces the number of failed deployments and manual intervention steps.
In this post Paweł Dąbrowski shows how to leverage Ruby’s value equality (
===) method, and overriding the default functionality in custom exceptions. The results is cleaner exception handling code.
Alvise Susmel writes in detail how to use Phoenix Chat PubSub implementation using the
pg2library. The result a distributed, multi-node chat service that does not have an external dependency to a separate system (like Redis).
My go-to tool for analyzing ruby performance is benchmark-ips. It’s an enhancement to Ruby’s own stdlib tool
Benchmark. It’s easy to use, and reports meaningful information by default.
I don’t know what I like more about this guide: The fact that it calls BS a lot of what is gospel for many in the software industry, the fact that it’s published by the Department of Defense, or the power-point-y graphics.
In this article, Graham Lea explains many potential pitfalls with distributed transactions, and general advice on how to avoid them in the first place, or deal with them effectively when must.
The solution to distributed transactions in microservices is simply to avoid them like the plague.
Russ Cox writes about software dependencies, and goes into great detail of what dependencies are and what risks they bring into software projects. I found myself nodding in agreement throughout the post. The need to have a good policy towards updating project dependencies has been a pet-peeve of mine for a while.