πŸ§‘β€πŸ’» agile sysadmin

by Ferenc Erki

Minimum Viable Rex

We consider enabling graceful bootstrapping as one of our main guiding principles around Rex, the friendly automation framework.

While our How to get started with Rex page provides a good initial set of concepts, I wondered about the minimal set of features that already proves useful in practice. I find this especially interesting when using Rex from a cronjob or in a CI/CD pipeline.

Let’s see what I found through this exercise in minimalism.

Continue reading …

Perl basics for Rex

Rex, the friendly automation framework does not expect much previous programming or Perl experience, though knowing a few foundational elements may go a long way.

While we provide a Just enough Perl for Rex page on our website, I often find myself sharing my own experience about getting started with Perl.

I decided to write my own take about the basics from a Rex perspective, and collect further resources I keep recommending or referring to.

Let’s see what I considered useful when I started out.

Continue reading …

Installing Rex

We briefly describe the different ways to install Rex, the friendly automation framework on the Get Rex page of our website, as well as in the Installation section of our README:

  1. Install from the Comprehensive Perl Archive Network (CPAN)
  2. Use standard, native package managers
  3. Build from source code

Depending on the situation at hand, one of these often fit better than the rest.

Let’s go through the available options in more detail to help choosing the best match.

Continue reading …

Virtues of Rex

We follow a set of guiding principles while developing Rex, the friendly automation framework:

  1. Use a programming language
  2. Empower users through trust
  3. Enable graceful bootstrapping

While we summarize these concepts briefly on our website, I consider it worthwhile to elaborate on the underlying details.

Let’s take a closer look at why we find these choices important.

Continue reading …

Lint early, lint often

Wikipedia defines linting software as:

a static code analysis tool used to flag programming errors, bugs, stylistic errors and suspicious constructs.

Linters play an important role to detect common mistakes fast. I often find that running them first in the build pipelines happens already too late, reducing their usefulness.

When to lint to maximize their value?

Continue reading …