A while ago, the people from Fullstaq and I started the Fullstaq Ruby project: a Ruby distribution that's optimized for server use cases. Compared to normal MRI Ruby, Fullstaq Ruby uses 50% less memory, is faster, and is easier to install and security-patch because of RPM and DEB packages.

Since I announced Fullstaq Ruby on EuRuKo 2019, I have received many questions about Fullstaq Ruby's vision, purpose and nature:

• Is Fullstaq Ruby a commercial product, or are there such plans?
• How will Fullstaq Ruby stay maintained?
• Who is in control of Fullstaq Ruby?
• Why are the changes in Fullstaq Ruby not in upstream Ruby? What is the current, and envisioned, relationship between the Ruby core developers and Fullstaq Ruby?

In other words, people are wondering: "how do I know this is, and stays, a real thing that I can count on?"

These are legit questions! As the author of Passenger and Ruby Enterprise Edition, I've experienced first-hand what the challanges are of building a healthy open source project. In this post, I will describe my vision on this matter.

When needing to perform HTTP calls in shell scripts, Curl is the go-to tool: it's flexible and installed almost everywhere. But Curl is not primarily designed for use in shell scripts. This article explores common caveats when using Curl in shell scripts, and showcases best practices to adhere to.

Fullstaq Ruby is a server-optimized Ruby distribution: 50% less memory, faster, easy to install and security-patch via APT/YUM.

We've reached an important milestone in the Fullstaq Ruby roadmap. Epic 3 introduces a continuous integration and deployment system! This means that from now on, we can release updates much faster, and with fewer defects.

We put the CI/CD system to the test right away, and used it to release Ruby version updates. We now package Ruby 2.7.1, 2.6.6 and 2.5.8.

Additionally, we now support Debian 10 (contributed by Nathan Broadbent).

Want to install or upgrade? Check the installation instructions, or run apt upgrade/yum update.

In this article I'll explain why having a CI/CD system is so important. I'll also give you a sneak peek into what to expect in the near future.

When you run a command or a script that runs for a long time, it may be helpful to have all its output prefixed with a timestamp. For example we want to change this:

foo
bar
baz

to this:

[2020-12-13 12:20:38] foo
[2020-12-13 12:21:32] bar
[2020-12-13 12:22:20] baz

Here's how you can do it.

I was recently in a discussion between developers about improving the test coverage of a major software project. They needed guidance about what kind of tests to write, and how to write them.

The discussion quickly became confusing: the topic was too large, too general, and it turns out that there wasn't even a well-defined shared vocabulary for testing concepts! The latter turns out to be a wider problem in the software development community: it simply doesn't have well-defined testing terms!

In this post, I'd like to provide some guidance w.r.t. this matter. I'll discuss:

• An overview of the most common testing terms.
• A new way of reasoning about testing concepts: reiterating what actually matters, and categorizing tests based on "size" and "approach".
• How the existing testing terminology fits in this new model.

I am happy to announce that epic 2 is now released. There is an APT and YUM repository to make installation and security-patching very easy. Epic 2 also includes the newly-released Ruby 2.6.4.

Learn more about the new APT/YUM repo, people’s experience so far, how to use it, and what’s in store for the future.

One of the projects I'm working on has a CI/CD pipeline that builds Docker images. The Dockerfile runs yarn install, then yarn build. The latter runs the TypeScript compiler tsc. Everything was working fine, but one day the build failed with the following error:

tsc: command not found

But TypeScript is still part of package.json. Nobody touched package.json or yarn.lock recently. Nobody could reproduce the problem locally with Docker: it only happened in the CI/CD pipeline. What is going on? We needed to debug the Docker build on the CI/CD server.

Estimating how long it takes to build software – or even how much effort a sprint is – is pretty hard. Estimates often turn out to be too optimistic, and mispredictions can be pretty hard to explain to management. I know why this is so – Michael Wolfe on Quora has a great analogy (there is even an interesting discussion on Reddit), which I agree with. But I'm wondering whether there's an easier analogy.

EuRuKo 2019 – the largest Ruby conference in Europe, took place on the 21st and 22nd of June. I gave a talk on the 21st about what causes Ruby memory bloat (where I also reported new findings since I first blogged about the issue), as well as about Fullstaq Ruby. Fullstaq Ruby is a server-optimized Ruby distribution that's faster, uses less memory, and is easier to security-patch thanks to being distributed via RPMs and DEBs.

My blog post earlier this month about what causes Ruby memory bloat, and about a way to potentially reduce memory usage by 70%, triggered quite a storm in the community! It's clear that I stumbled upon a significant pain point.