Since SNGULAR is a consulting firm and I work full-time for a client, the truth is that my relationship with the company itself has not changed much compared to what I mentioned last year.

But a year is a long time, and things always happen.

Change of area within the company

The group of engineers working for the same client was moved to SNGULAR's services division at the end of last year. That shift also brought a change in manager for us, as well as a new liaison with the client — roles that had previously been handled by the same person. It was a completely unexpected change for all of us.

What surprised us even more was that the person assigned to replace our manager was scheduled to go on maternity leave in just a couple of months. That means we now have another manager replacing the first replacement, plus a new person acting as liaison with the client.

I have to admit it has not made much of a difference for us on a day-to-day basis. Usually, in our weekly meetings, they just tell us there are no updates from either SNGULAR or the client.

New security policy

This is the biggest change that occurred over the past year, and one that generated quite a bit of controversy.

At the beginning of 2026, the IT team notified us that, within a few months, they would be adding new security layers to restrict which devices can connect to internal company tools in order to comply with certain certifications. From that moment on, we could only access these tools from the laptop provided by the company. This includes things like checking email and Slack, joining the weekly meeting with colleagues assigned to the same client, logging project hours, requesting time off, and so on.

This measure affected us in a phased rollout. I was among the first affected, starting in early April, while some of my colleagues were not impacted until well into June.

In practice, we are forced to keep two laptops running on our desks at all times. Before this, it was very convenient to use just one computer and set up a separate browser profile to access the SNGULAR tools we needed.

It is true that they give us the option to ask the IT team to set up an additional device to access those tools, but under no circumstances can that device be the client's laptop.

In my case, to avoid having two laptops constantly turned on, I requested access from my Android phone. To do that, I had to install an app that sets up a work profile and contact the IT team to add the necessary configuration. Now, I just enable that profile whenever I need to check email or anything else. The rest of the time, the profile stays disabled:

It works for me, but having software installed on your personal mobile device just because of work-imposed restrictions is far from ideal. In fact, most of my colleagues refuse to install that software altogether.

Our manager is aware that response times will be significantly slower than usual due to this constraint. We have complained to the IT team on multiple occasions, but they tell us there is nothing more they can do.

Salary review

This topic also caused quite a bit of controversy. My colleagues had already warned me that salary raises at SNGULAR are modest, to put it politely.

Every time the subject has come up so far, we have been told that the company's revenue from the previous year was lower than expected, so the budget allocated for raises was less than they would have liked.

I already mentioned last year that I was not eligible for a salary review because I had not met the minimum tenure requirement at the company when the reviews took place.

However, my previous manager promised that there would be a salary raise for me this year, considering that I deserved one last year and only missed out due to a technicality.

Naturally, salary reviews depend heavily on the previous year's performance evaluation. In my case, the evaluation is done by another engineer on the SNGULAR team who works for the same client. He assured me he would fight for a fair raise for me and expected at least a 5% increase, though he ultimately did not have the final say.

When the time came, it was the temporary manager who broke the news about the raise they considered fair for me. In this case, they felt 2% was appropriate, but — in her exact words — since that was a rather laughable figure, they bumped it up to a little over 3% to make it a round number. The raise would take effect the following month.

It was a disappointment for me, and it left a bad taste in my mouth that she tried to sell it as if they were doing me a favor.

They gave me the option to submit a formal appeal to reconsider my case. Although the outcome was obvious — as my salary remained unchanged — I never received an official response from the company regarding my appeal, either before or after the manager went on leave.

Later, I found out that some of my colleagues initially received no raise at all, although after filing an appeal, the company apparently reconsidered and granted them a raise.

From what I gather, that 2-3% raise is the company standard when performance in the engineering team is good, but I felt the promise made to me the previous year was not kept. What they did fulfill was a promotion in my professional title, moving from a Senior role to an Expert role. Granted, I was already at the top of the Senior salary bracket, so any salary raise required a title bump beforehand anyway.

Other details to highlight

Before wrapping up the review of this second year, I would like to quickly touch on a few other details:

• This time, no one from HR reached out to me personally; I simply received an automated email congratulating me on my two-year anniversary with the company.
• I still have monthly 1-on-1 meetings with the engineer acting as manager for those of us working with this client, which always helps to maintain some connection.
• This year the company did not organize a summer party, but they did send us a Christmas hamper. The previous year, they made a donation in our name without consulting us and had to backtrack following understandable employee complaints, ultimately paying us the corresponding money in the next paycheck.
• The policy regarding the training and wellness budgets remains as strict as ever. We still cannot use it for things we actually consider necessary for our daily work, like a standing desk.

Conclusion

If I had to sum up this second year, I would say it has been a reality check. The friction over new security policies, the disappointments regarding salary reviews, and the bureaucracy are constant reminders that, at the end of the day, you work for a consulting firm — with everything that entails.

However, my day-to-day work remains 100% focused on the client, and that is where I find the stability, technical challenges, and good team atmosphere that make the job worthwhile. As I mentioned last year, in this line of work, your overall satisfaction depends almost exclusively on the nature of your assigned project.

Despite the things I would certainly improve in my relationship with SNGULAR, the overall balance remains positive thanks to my day-to-day working environment. We will see what year three brings.

Thanks for reading and see you in the next one!

It worked great. Until it did not.

The free lunch ended

If you visit https://gql.hashnode.com today, you no longer land on the friendly GraphQL playground I used back then. Instead, you get redirected to this changelog entry.

The gist of it is this:

Every API request, queries and mutations, now requires a Pro plan on your publication.

So it is not just write operations behind the paywall. Even reading my own posts through the API now requires a paid subscription. Hashnode justifies the change as an abuse-prevention measure — apparently scrapers and spammers were mirroring content and flooding feeds — which is a perfectly reasonable motivation. But the practical consequence for me was that my nice little automation suddenly stopped working.

I had two options:

• Pay for Pro just to keep a README.md table updated (overkill, to put it mildly).

• Find another source of truth for my posts.

Thankfully, that source of truth was hiding in plain sight.

The backups saved the day

If you read the original post, you might remember that Hashnode offers a GitHub integration that automatically backs up every post to a repository of your choice.

Back then I only used that repository as the trigger for my automation — a push to it fired a webhook that told my profile to go and re-query the API. The posts themselves still came from Hashnode.

Then I realized I do not need the API at all. Every post is already in that repository, as a Markdown file with all the metadata I need in its YAML frontmatter.

Here is what one of those backup files looks like at the top:

title: "The one about choosing where htmx logic belongs"
seoDescription: "Compare view-level events and server response headers to handle htmx failures. Explore the trade-offs and decide where your logic truly belongs."
datePublished: 2026-06-22T21:09:14.210Z
cuid: cmqppkjkw00000bj7cakd4owq
slug: the-one-about-choosing-where-htmx-logic-belongs
cover: https://cdn.hashnode.com/uploads/covers/642d433eeaad3d174f737099/5bc78409-7883-4e5b-9ec4-afc3251424e8.png
tags: http, javascript, html, security, hypermedia, htmx

Everything I was fetching over the network — title, slug, datePublished, cover — is right there. No API, no token, no Pro plan. Just files on disk.

The new GitHub action

So I created a replacement for the old action, backpackerhh/github-latest-blog-posts, whose most important design decision is captured in the following:

This action does not call any external HTTP API. The consumer workflow is responsible for checking out the blog-posts repository and passing its path to this action.

This is a fundamental shift in responsibility. The old action fetched the data. The new one reads it. The workflow checks out the backup repository, and the action just parses the Markdown files it finds locally.

The metadata and configuration of the action live in action.yml, and its inputs tell the whole story of how the philosophy changed:

Notice what is gone: there is no HASHNODE_PUBLICATION_ID and no GITHUB_TOKEN. The only required input is now POSTS_DIR — the path to the local directory where the Markdown posts live.

A couple of things worth explaining:

• BLOG_BASE_URL is used to reconstruct each post's public URL. Since the backups only store the slug, the action builds the link as ${BLOG_BASE_URL}/${slug}. This means my profile links point to my own domain rather than to Hashnode, which I actually prefer.

• OPENING_COMMENT and CLOSING_COMMENT keep the same HASHNODE_POSTS markers I already had in my README.md, so I did not have to touch the placeholders at all. Backwards-compatible by happy accident.

The runs section describes the execution environment. It uses node24 as the runtime and dist/index.js as the entry point — same compiled-code approach as the old action, where the contents of the dist directory are what actually run.

As for how it actually reads the posts, the logic is refreshingly boring, and I mean that as a compliment.

The action:

1. Scans POSTS_DIR for Markdown files.

2. Parses the YAML frontmatter of each file, expecting title, seoDescription, datePublished, slug, and cover.

3. Skips (with a warning) any file missing the required fields.

4. Sorts the posts by datePublished.

5. Takes the newest MAX_POSTS and formats them into a table between the comment markers in the README.md.

If everything goes well, a commit is created with the changes — exactly the behavior I had before. From the outside, my profile updates the same way. Under the hood, not a single byte crosses the network to Hashnode.

Wiring it together

Here is the updated workflow in my profile repository:

name: Update Latest Blog Posts

on:
  workflow_dispatch:
  # for trigger via webhooks
  repository_dispatch:
    types: [trigger]

jobs:
  update-posts:
    runs-on: ubuntu-latest
    name: Update Posts

    steps:
      - name: Checkout profile repo
        uses: actions/checkout@v7

      - name: Checkout blog-posts repo
        uses: actions/checkout@v7
        with:
          repository: backpackerhh/blog-posts
          path: .blog-posts
          ref: main

      - name: Update README with latest posts
        uses: backpackerhh/github-latest-blog-posts@main
        with:
          POSTS_DIR: .blog-posts

Once again, a fair amount is going on here, so let me explain it:

• The workflow can still be triggered manually via workflow_dispatch.

• It can still be triggered by a webhook event, listening for the trigger event type — the exact same trigger my dispatcher sends.

• The first Checkout step grabs my profile repository, as before.

• The second Checkout step is the key change. It checks out backpackerhh/blog-posts into a .blog-posts directory. This is how the data gets onto the runner without any API call.

• The final step runs the new action, pointing POSTS_DIR at that .blog-posts directory.

The best part of this migration is that dispatcher.yml in my blog-posts repository is untouched:

name: Dispatcher

on:
  push:
    branches: [main]

jobs:
  dispatch_event:
    name: Dispatch event
    runs-on: ubuntu-latest
    timeout-minutes: 2
    steps:
      - name: Dispatch
        run: |
            curl -L \
              -X POST \
              -H "Accept: application/vnd.github+json" \
              -H "Authorization: Bearer ${{ secrets.DISPATCH_TOKEN }}" \
              https://api.github.com/repos/backpackerhh/backpackerhh/dispatches \
              -d '{"event_type":"trigger"}'

The chain of events is identical to what I described in the previous post:

1. I publish, update, or delete a post on Hashnode.

2. Hashnode's GitHub integration pushes the change to backpackerhh/blog-posts.

3. That push to main triggers the dispatcher.

4. The dispatcher sends a repository_dispatch event with type trigger to my profile repository.

5. My profile's workflow wakes up, checks out the backups, and rewrites the README.md.

The only link in the chain that changed is step 5, and even there, only the source of the data changed — from a remote API to a local checkout.

Fewer moving parts, fewer things to break

Looking back, this migration turned out to be a small blessing in disguise. Comparing the two setups side by side:

The new approach is not only cheaper — it is more resilient. There is no API to go down, no rate limit to hit, no token to expire, and no GraphQL schema that might change under me. The backup repository is the single source of truth, and it is the same data Hashnode itself would have served me. If Hashnode ever changes the shape of that frontmatter, that is the only thing I would need to adapt.

Conclusion

When Hashnode put its API behind a Pro plan, my first reaction was mild annoyance at having something that worked perfectly well suddenly break. But the fix ended up leaving me with a setup that has fewer dependencies, no secrets in the critical path, and no external service to depend on at runtime.

The trigger mechanism I built back then survived intact — I just swapped the data source from a remote API to the local backups that were already being created for me. My original solution reached out over the network for data that was, in fact, already sitting on disk, and it took a paywall to make me notice the redundancy.

Sometimes the constraint that feels like a setback is the exact push you need toward the simpler design you should have had all along.

Thank you for reading and see you in the next one!

Although I recommend reading that post before moving on, here is the most relevant code from the proposed approach, which handles errors through htmx attributes defined directly on the form:

<form
  id="new-comment-form"
  hx-post="/comments"
  hx-target="#comments-container"
  hx-swap="afterbegin"
  hx-select=".comment"
  hx-on::config-request="
    document.addEventListener('htmx:beforeSwap', function(e) {
      if (e.detail.isError) {
        e.detail.target = document.getElementById('new-comment-form');
        e.detail.swapOverride = 'outerHTML';
        e.detail.selectOverride = '#new-comment-form';
      }
    }, { once: true });
  "
>

From now on, I will assume you know how that snippet works.

I have also been thinking about an alternative way to achieve the same behavior, using a different approach. Not necessarily better.

I will first present the alternative version of that code and then lay out the pros and cons of both options.

The code shown below is a simplified version, removing unnecessary noise for this post, such as authorization, logging, HTML markup, or CSS styles.

A new alternative

This approach keeps the form's attributes to a minimum and lets the server tell htmx what to do through response headers on failure.

Endpoints

post '/comments' do
  comment_params = {
    content: params[:content],
    author: current_user.email
  }
  result = CreateCommentCommand.call(comment_params)
  status_code, response = extract_response(result)

  case status_code
  when HTTP_CREATED_STATUS_CODE
    # ...
  else
    htmx_retarget("#new-comment-form")
    htmx_reselect("#new-comment-form")
    htmx_reswap("outerHTML")

    # ...
  end
end

module Request
  HTMX_RETARGET_HEADER_NAME = 'HX-Retarget'
  HTMX_RESELECT_HEADER_NAME = 'HX-Reselect'
  HTMX_RESWAP_HEADER_NAME = 'HX-Reswap'

  def htmx_retarget(target)
    response.set_header(HTMX_RETARGET_HEADER_NAME, target)
  end

  def htmx_reselect(target)
    response.set_header(HTMX_RESELECT_HEADER_NAME, target)
  end

  def htmx_reswap(swap)
    response.set_header(HTMX_RESWAP_HEADER_NAME, swap)
  end
end

Things to highlight in this code:

• The endpoint's behavior stays exactly the same, except for the call to the custom htmx helpers when any error is encountered while creating a comment.

• Those helpers are defined in a module that is included in the application's base controller.

• Those helpers set the corresponding response header, overriding the value defined in the matching htmx attribute on the requesting element — the form, in our case.

Presentation layer

<!-- comments/_new_comment_form.erb -->
<form
  id="new-comment-form"
  hx-post="<%= comments_url %>"
  hx-target="#comments-container"
  hx-swap="afterbegin"
  hx-select=".comment"
>
  <!-- ... -->
</form>

Things to highlight in this code:

• Only the attributes needed for the success case are defined in the form.

Comparing both approaches

Same DOM result, same htmx contract, two very different places to put the logic. Let's compare them honestly.

Approach A - View layer

Pros

• Co-location of behavior: Selector, swap strategy, and retarget element all live next to the form they affect. Somebody opening the view for the first time is able to see the full lifecycle without jumping into the controller. This is the Locality of Behavior (LoB) principle that htmx itself advocates.

• Resilience to renames: The form ID lives in a single file. Rename it and the form keeps working — there is no controller silently pointing at an old selector.

• Controller stays HTTP-pure: The server returns 4xx and an HTML fragment. It knows nothing about DOM IDs or htmx swap mechanics.

• Reusable across endpoints: If multiple endpoints could fail and target the same form, the form itself owns the retarget logic. None of those endpoints have to remember to set the same headers to make it work.

Cons

• Inline JavaScript inside a string: If you want to stick to the LoB principle, you have to write the JS code inside an HTML attribute that is just a string. Your IDE treats it as HTML — no syntax highlighting, no autocomplete, no jump-to-definition — and debugging is harder.

• Duplication: Every form needing this behavior copies essentially the same hx-on::config-request block, with only the target ID changing. The more forms you have, the more duplication. A Ruby helper could render that block but then it would just hide the JS code inside a string in a different file, breaking the LoB principle.

• Status-code blindness: The view cannot easily differentiate 422 (validation error) from 409 (conflict) from 500 (server error) without growing the inline script.

• CSP friction: If the app does not enforce a strict Content Security Policy, this is a non-issue. But if it does — or might in the future — hx-on::* attributes force you into either 'unsafe-inline' (which weakens XSS protection across the entire site) or per-attribute 'unsafe-hashes' (which you have to recompute every time the attribute changes).

Approach B - Controller layer

Pros

• Documented contract: HX-Retarget, HX-Reswap, and HX-Reselect are first-class htmx response headers — stable across versions, no clever workaround, no mutation of internal event details.

• Status-code routing: The controller already knows whether it returned 422 (validation error), 409 (conflict), or 500 (server error), and can trivially return different swap behaviors for each scenario.

• No inline JS: Pure HTTP response. Passes strict CSP without exceptions.

• Debuggability: Easier to debug with a simple curl -i or a glance at the network tab, revealing exactly what the server instructed the client to do.

Cons

• Leaks in the controller: DOM IDs ("#new-comment-form") and swap strategy ("outerHTML") are presentation concerns leaking into the HTTP layer.

• Silent breakage on rename: Rename the form ID and the controller would break silently.

• Drift risk: Every endpoint that could fail and target the same form must set the same headers.

• No co-location of behavior: Somebody opening the view for the first time is not able to easily see how errors are handled.

The tie-breakers

Both approaches work. Both use documented htmx machinery. Here are the factors that I think should help you decide.

Where does this knowledge belong?

The knowledge being expressed is:

When this form fails to submit, replace itself with the server's re-rendered version showing errors.

• The server's job is to validate the input, return 422, and render the form.

• The form's job is to replace itself with the server's response if the submission fails.

• The thing being expressed is therefore form behavior, not server behavior.

By that lens, the view layer wins. The controller should not care that the response is going into a form, a modal, or a toast. It returns a 422 and how the UI displays that is the UI's problem.

Content Security Policy

If your app already enforces a strict CSP, the question is decided for you — hx-on::* attributes are off the table without weakening XSS protection across the whole site. If your app might enforce one in the future, you are choosing between paying the migration cost later or staying on the controller side now.

By that lens, the controller approach wins — but only if CSP is on your roadmap.

Codebase consistency

In an existing codebase with established patterns, a slightly misaligned but consistently applied convention is more valuable than two competing patterns.

For instance, if your codebase already uses htmx_retarget or htmx_reswap somewhere, introducing hx-on::config-request for one new form forces every future reader to ask "why is this one different?", with no good answer. The same applies in reverse — if every existing form uses hx-on::*, dropping headers into the controller for this one form has the same problem.

By that lens, the existing convention should usually win. The cost of having two patterns to maintain is almost always higher than the cost of putting one of them in a slightly suboptimal layer.

Conclusion

Both approaches use documented htmx machinery, both produce the same DOM result, and both are cheap to refactor away from. The choice is not really about which one is correct — it is about which one fits the codebase you already have.

In my case, I ultimately chose the controller layer because we use htmx_* helpers in other parts of the application. The "codebase consistency" tie-breaker outweighed the "knowledge belongs in the view" argument — and I think that is the right call more often than not, even when it feels architecturally less pure.

Pick the boundary that fits your team and codebase, write it down, and move on.

Thank you for reading and see you in the next one!

One of those changes is related to adding new comments. Right now, the user has to click a button to add the form to the page using htmx. The stakeholders prefer to have the comment box always visible to streamline their workflow by requiring fewer clicks.

At the design level, we need to eliminate the button that adds the new comment form to the page and the "Cancel" button that removes said form from the page. Since it is always visible, it is no longer necessary.

At the functional level, we need to remove the endpoint that returns the HTML for the new comment form and change some details in the htmx configuration related to that logic.

The code shown below is a simplified version, removing unnecessary noise for this post, such as authorization, logging, HTML markup, or CSS styles.

Initial state

Endpoints

This is a Sinatra application, where we have the following endpoints:

get '/comments/new' do
  render_partial 'comments/_new_comment_form', locals: NewCommentPresenter.present
end

post '/comments' do
  comment_params = {
    content: params[:content],
    author: current_user.email
  }
  result = CreateCommentCommand.call(comment_params)
  status_code, response = extract_response(result)

  case status_code
  when HTTP_CREATED_STATUS_CODE
    render_partial 'comments/_comment',
                    locals: CommentPresenter.present(response),
                    flash: { type: :success, message: 'Comment added successfully' }
  else
    render_partial 'comments/_new_comment_form',
                    locals: NewCommentPresenter.present(comment_params, errors: response),
                    flash: { type: :error, message: 'Unable to add comment. Please try again or contact support.' }
  end
end

Things to highlight in this code:

• The command returns an instance of the Result monad, Success or Failure, provided by dry-monads.

• extract_response checks the result from the command and extracts the response using pattern matching.

• Depending on the status_code, either the newly created comment or the same form with the errors found during server validation is rendered.

• Presenters only receive data and are responsible for shaping it before passing it to the partials or views.

• The flash alert displays a message with feedback for the user, appearing at the top right of the page and disappearing automatically after x seconds. I would like to talk about this implementation in a later post.

• The server response is implicitly 200 OK in both cases, so the response is always inserted into the DOM.

Presentation layer

These are templates in ERB format, both views and partials:

<!-- comments/index.erb -->
<h2>Comments</h2>

<%=
  link_button(
    'Add new comment',
    htmx: {
      get: '/comments/new',
      target: '#comments-container',
      swap: 'afterbegin show:#new-comment-form:top swap:50ms',
      'on::before-request': "if(document.querySelector('#new-comment-form')) { event.preventDefault() }"
    }
  )
%>

<div id="comments-container">
  <% if comments.empty? %>
    <p id="no-comments">No comments yet</p>
  <% else %>
    <% comments.each do |comment| %>
      <%= render_partial 'comments/_comment', locals: { comment: } %>
    <% end %>
  <% end %>
</div>

<!-- comments/_new_comment_form.erb -->
<form
  id="new-comment-form"
  hx-post="/comments"
  hx-target="#comments-container"
  hx-swap="afterbegin"
  hx-select=".comment, #new-comment-form"
  hx-on::after-request="if(event.detail.successful) { document.getElementById('no-comments')?.remove(); this.remove(); }"
>
  <%=
    textarea(
      name: 'content',
      label: 'New comment',
      value: comment[:content],
      error: errors[:content],
      required: true
    )
  %>

  <%= secondary_button('Cancel', onclick: "this.closest('form').remove();") %>
  <%= primary_button('Add', type: :submit) %>
</form>

Things to highlight in this code:

• Server-rendered UI components are used for buttons and form fields.

• The new comment form is added above the list of existing comments, provided it is not already present on the page, and the view automatically scrolls to the top of the form.

• The new comment or the new comment form with errors is extracted from the server response:

  • In case the comment is successfully created, the new comment is added to the top of the comment list, the new comment form is removed, and the "No comments yet" message is removed.

  • In case of finding any failure when creating the comment, the same form is rendered again with the errors found.

• Clicking on the "Cancel" button removes the form from the page.

Implementation of the required changes

Endpoints

As I mentioned previously, the /comments/new endpoint is no longer necessary. Nothing changes in the other endpoint.

Presentation layer

<!-- comments/index.erb -->
<h2>Comments</h2>

<%= render_partial 'comments/_new_comment_form', locals: { comment: {} } %>

<div id="comments-container">
  <% if comments.empty? %>
    <p id="no-comments">No comments yet</p>
  <% else %>
    <% comments.each do |comment| %>
      <%= render_partial 'comments/_comment', locals: { comment: } %>
    <% end %>
  <% end %>
</div>

<!-- comments/_new_comment_form.erb -->
<form
  id="new-comment-form"
  hx-post="/comments"
  hx-target="#comments-container"
  hx-swap="afterbegin"
  hx-select=".comment, #new-comment-form"
>
  <%=
    textarea(
      name: 'content',
      label: 'New comment',
      value: comment[:content],
      error: errors[:content],
      required: true
    )
  %>

  <%= primary_button('Add', type: :submit) %>
</form>

Things to highlight in this code:

• The "Add new comment" button is replaced by the new comment form.

• It is not necessary to check if the form is already present on the page using JS.

• The "Cancel" button is no longer necessary.

• In case the request to the server is successful, the form itself is not removed, nor is the "No comments yet" message.

The good news is that while removing the hx-on::after-request attribute, I discovered a bug in the code, which occurred only in case of finding an error on the server:

hx-on::after-request="if(event.detail.successful) { document.getElementById('no-comments')?.remove(); this.remove(); }"

hx-on attributes docs

The key lies in the status code returned by the server, which we already mentioned is 200 OK by default, so after each request, it removed the original form and the "No comments yet" message.

The new change causes that, when submitting the form, if any validation error is found on the server, the form with the errors is rendered below the original form, which is no longer removed. The more requests that are made, the more forms will appear on the page.

Of course, the "No comments yet" message is never removed either, even when it is necessary to do so.

A new approach

The goal is to have a different configuration for successful and failed requests.

We start by returning the correct status code from the server in any case that is not a success:

post '/comments' do
  # ...
  status_code, response = extract_response(result)

  case status_code
  when HTTP_CREATED_STATUS_CODE
    render_partial 'comments/_comment',
                    locals: CommentPresenter.present(response),
                    flash: { type: :success, message: 'Comment added successfully' }
  else
    status status_code
    render_partial 'comments/_new_comment_form',
                    locals: NewCommentPresenter.present(comment_params, errors: response),
                    flash: { type: :error, message: 'Unable to add comment. Please try again or contact support.' }
  end
end

On the other hand, we must first configure the htmx responses, allowing the content returned by the server for client error responses to be replaced on the page:

document.addEventListener("DOMContentLoaded", function() {
  htmx.config.responseHandling = [
    // ...
    { code: "4..", swap: true, error: true }
    // ...
  ]
});

The htmx documentation recommends using the Response Targets extension, which allows you to configure the behavior of response codes declaratively via attributes.

However, that extension falls short for my use case, as it only allows specifying different target elements. I would have needed something like the following:

<form
  id="new-comment-form"
  hx-post="/comments"
  hx-target="#comments-container"
  hx-swap="afterbegin"
  hx-select=".comment"
  hx-target-error="this"
  hx-swap-error="outerHTML"
  hx-select-error="#new-comment-form"
>

Perhaps at some point I will have enough time to create a custom extension for this use case.

Another alternative offered by htmx is to modify the swapping behavior of the page content with events:

<form
  id="new-comment-form"
  hx-post="/comments"
  hx-target="#comments-container"
  hx-swap="afterbegin"
  hx-select=".comment"
  hx-on::before-swap="
    if (event.detail.isError) {
      event.detail.target = document.getElementById('new-comment-form');
      event.detail.swapOverride = 'outerHTML';
      event.detail.selectOverride = '#new-comment-form';
    }
  "
>

In my opinion, it is less elegant than what I expected from the extension, but I find it to be a sufficiently good alternative.

To my surprise, defining the htmx:beforeSwap event that way does not work, because it does not execute on the requesting element, but on the target element.

It is possible to declare the event on the target element or on a common ancestor to both, but I quickly discarded that option. Imagine coming across the following code without any context:

<div
  hx-on::before-swap="
    if (event.detail.isError) {
      event.detail.target = document.getElementById('new-comment-form');
      event.detail.swapOverride = 'outerHTML';
      event.detail.selectOverride = '#new-comment-form';
    }
  "
>
  <!-- the requesting element could be one of its children -->
</div>

Would you not wonder what on earth that is doing there?

It can make some sense if the target element or the common ancestor are defined in the same view, but if they are defined in different views, as is this case, I prefer to follow the Locality of Behavior (LoB) principle.

Here, the help of Claude Code was decisive, since it suggested using htmx:configRequest event instead:

<form
  id="new-comment-form"
  hx-post="/comments"
  hx-target="#comments-container"
  hx-swap="afterbegin"
  hx-select=".comment"
  hx-on::config-request="
    document.addEventListener('htmx:beforeSwap', function onBeforeSwap(e) {
      document.removeEventListener('htmx:beforeSwap', onBeforeSwap);
      if (e.detail.isError) {
        e.detail.target = document.getElementById('new-comment-form');
        e.detail.swapOverride = 'outerHTML';
        e.detail.selectOverride = '#new-comment-form';
      }
    });
  "
>

By using addEventListener, we subscribe to the event we want and define the desired target.

Knowing the tendency of AI to include more code than necessary, I questioned it on whether the use of removeEventListener was truly necessary in this case.

Its arguments definitely convinced me:

• If the listener is not removed, they would accumulate over time, since htmx:configRequest event is fired every time the form is submitted.

• Each obsolete listener continues to execute and attempts to redirect the swap. In this case, all of them would perform the same task, so from a functional point of view, it might appear to work, but it could be a memory or event leak that grows without limits.

What I always do when I use AI to write code is to ask if it can do it in a simpler and/or more elegant way. On this occasion, it suggested the possibility of passing the once argument to addEventListener to automatically remove the listener after being invoked:

<form
  id="new-comment-form"
  hx-post="/comments"
  hx-target="#comments-container"
  hx-swap="afterbegin"
  hx-select=".comment"
  hx-on::config-request="
    document.addEventListener('htmx:beforeSwap', function(e) {
      if (e.detail.isError) {
        e.detail.target = document.getElementById('new-comment-form');
        e.detail.swapOverride = 'outerHTML';
        e.detail.selectOverride = '#new-comment-form';
      }
    }, { once: true });
  "
>

Having reached this point, two main issues remain in the code:

• In case of submitting the new comment form and finding validation errors on the server, the textarea renders with a red border and the corresponding error message below it. If the user subsequently fills out the form correctly and submits it, the comment is created successfully and added to the comment list, but visually the form remains as it was. Due to the applied styles and validation errors, simply performing a reset of the form does not work, because it basically only clears the content of the comment.

• The "No comments yet" message still is not removed when the first comment is added to the page.

Next, I show how to solve both problems in a simple way.

In the controller, in case of successfully creating a comment, a new partial specific to this use case is rendered:

post '/comments' do
  # ...
  status_code, response = extract_response(result)

  case status_code
  when HTTP_CREATED_STATUS_CODE
    render_partial 'comments/_comment_created',
                    locals: CommentPresenter.present(response),
                    flash: { type: :success, message: 'Comment added successfully' }
  else
    # ...
  end
end

In that new partial, the newly created comment is rendered, and the form is replaced with a new one by making use of the hx-swap-oob attribute, which allows you to specify that some content in a response should be swapped into the DOM somewhere other than the target:

<!-- comments/_comment_created.erb -->
<%= render_partial 'comments/_comment', locals: { comment: } %>

<div hx-swap-oob="outerHTML:#new-comment-form">
  <%= render_partial 'comments/_new_comment_form', locals: { comment: {} } %>
</div>

And in the comment list we can apply a CSS trick, in this case making use of TailwindCSS, so that it only shows the well-known "No comments yet" message when appropriate:

<!-- comments/index.erb -->
<div id="comments-container" class="group/no-comments">
  <p class="group-has-[.comment]/no-comments:hidden">No comments yet</p>

  <% comments.each do |comment| %>
    <%= render_partial 'comments/_comment', locals: { comment: } %>
  <% end %>
</div>

Now, everything works exactly as I expected. Hooray!

Conclusion

What started as a simple UX request – keeping a comment form always visible – turned into a great exercise in understanding the htmx event lifecycle and DOM manipulation.

It is easy to love a tool like htmx when you are cruising down the happy path. The real engineering happens when you hit a failure path and realize the library's default behavior does not match your product requirements, and have to decide how to bend the tool to your will.

Overriding htmx's default behavior on failure forced me to think about where the UI logic truly belongs. By keeping that logic inside the view layer, Locality of Behavior was preserved and kept the backend clean. It proves that with a solid understanding of how a framework processes requests, you do not need a heavy JavaScript framework to build complex, resilient user interfaces.

Ultimately, the stakeholders got a lower-friction UI that matches their workflow, and I got a much deeper understanding of htmx's defaults.

Thank you for reading and see you in the next one!

Most of these components are simple: you call a method and the page renders the HTML returned by the corresponding template.

Some examples of components:

primary_button "Save"
status_badge "Finished", color: "green"
text_input name: "name", label: "Name", value: "David"
dropdown name: "country", label: "Country", options: countries

Of course, not all components are that simple.

The problem

The first complex component I had to create was a table. I mentioned in the previous post that my first approach was to create a CSS-only component:

<table class="table">
  <thead>
    <tr>
      <th>Name</th>
      <th>Email</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Alice</td>
      <td>alice@example.com</td>
    </tr>
  </tbody>
</table>

I soon realized that a component of that kind is not really useful. While it is true that defining styles is very simple this way, adding common behavior for the different applications that use it, such as making the content of the different columns sortable, is not.

The first block DSL component: table

The goal was to create a table component that would allow consumers to write something like the following inside a single <%= %> tag:

table do
  table_head do
    table_row do
      table_header_cell("Name", **sortable_column_params(:name, sorting_params:))
      table_header_cell("Email", **sortable_column_params(:email, sorting_params:))
    end
  end
  table_body do
    table_row do
      table_cell("Alice")
      table_cell("alice@example.com")
    end
  end
end

Where **sortable_column_params would return a hash containing the required configuration for that column to be properly sorted:

{ sortable: true, sort_direction: nil | "asc" | "desc", htmx: { ... } }

This is harder than it looks. In a plain Ruby method, each helper runs, returns a string, and the outer block has no visibility into what its children did.

The calls to each one of those methods return strings independently. There is no shared place for them to store their rendered HTML.

In situations like this, I usually look at the Rails source code to see how the framework handles it and whether there is a simple way to replicate that approach, instead of adding more dependencies to the project.

In a Rails view, every <%= ... %> tag appends its result to @output_buffer, an ActionView::OutputBuffer maintained during rendering.

capture { ... } works by swapping the buffer: it saves the current @output_buffer, installs a fresh one, yields the block (so any <%= ... %> inside writes into the new buffer), then restores the original and returns what was captured.

Block-form helpers like content_tag(:div) { ... } use capture internally to collect their block's output before wrapping it in markup.

But this only works when the caller is an ERB template rendered by ActionView. In plain Sinatra there is no @output_buffer and no capture, so the nested DSL above has nowhere to collect its children's output.

Next, I shared what I wanted to achieve with Claude Code in plan mode, and after a few iterations, I got the AI to propose an implementation that seemed simple enough.

The implementation, slightly simplified, is as follows:

module Components
  module Table
    def table(&block)
      content = capture_table_content(&block)

      Components.load_template("table/_table.erb", binding)
    end

    def table_head(&block)
      content = capture_table_content(&block)
      result = Components.load_template("table/_head.erb", binding)

      append_to_table_buffer(result)
    end

    def table_body(&block)
      content = capture_table_content(&block)
      result = Components.load_template("table/_body.erb", binding)

      append_to_table_buffer(result)
    end

    def table_row(&block)
      content = capture_table_content(&block)
      result = Components.load_template("table/_row.erb", binding)

      append_to_table_buffer(result)
    end

    def table_header_cell(content, **sortable_params)
      result = Components.load_template("table/_header_cell.erb", binding)

      append_to_table_buffer(result)
    end

    def table_cell(content)
      result = Components.load_template("table/_cell.erb", binding)

      append_to_table_buffer(result)
    end

    # other helpers omitted

    private

    def table_buffer_stack
      Thread.current[:table_buffer_stack] ||= []
    end

    def capture_table_content(&block)
      table_buffer_stack.push([])
      block.call
      table_buffer_stack.pop.join
    end

    def append_to_table_buffer(html)
      table_buffer_stack.last << html if table_buffer_stack.any?

      html
    end
  end
end

Two ideas are doing the work here:

• A stack of arrays instead of a single buffer, so nested blocks do not stomp on each other:

  table do              # buffer_stack = [[]]
    table_body do       # buffer_stack = [[], []]
      table_row do      # buffer_stack = [[], [], []]
        table_cell "a"  # buffer_stack = [[], [], ["<td>a</td>"]]
        table_cell "b"  # buffer_stack = [[], [], ["<td>a</td>", "<td>b</td>"]]
      end               # buffer_stack = [[], ["<tr><td>a</td><td>b</td></tr>"]]
    end                 # buffer_stack = [["<tbody>…</tbody>"]]
  end                   # returns "<table><tbody>…</tbody></table>"
  

  table_body pushes a fresh array; its inner table_row pushes another on top; when each pops, the content of the inner stack merges back into the outer one via append_to_table_buffer. Only the outermost table returns anything, the joined string after the last pop. Every other call's return value is thrown away on purpose: if capture_table_content trusted the block's return value, Ruby's last-expression rule would hand back only the last table_cell's HTML and every earlier cell would vanish.

  Nesting a table inside another table works for the same reason, an inner table do just pushes one more array onto the stack, fills it, pops it, and deposits the whole inner <table>…</table> string onto its parent's array like any other child's output.

• Thread-local storage, because Sinatra on a threaded server, like Puma, handles requests in parallel:

  Thread.current[:table_buffer_stack]
  

  If table_buffer_stack were a class-level @@buffer_stack instead, two requests entering table do at the same moment would push onto the same array; each one's table_cell could append into the other's array, mixing rows across responses. Thread.current gives each thread its own stack, so the two requests can not see each other's state.

All that works perfectly for the table component, but it does not for the next component I needed to create.

The second block DSL component: modal

The goal was to create a modal component that would allow consumers to write something like the following inside a single <%= %> tag:

modal do
  modal_header do
    "Confirm status change"
  end
  modal_body do
    <<~CONTENT
      <p>Do you confirm the change of status?</p>
      <p><span>OLD_STATUS</span> -> <span>NEW_STATUS</span></p>
    CONTENT
  end
  modal_footer do
    modal_cancel
    modal_action "Confirm", htmx: { ... }
  end
end

The implementation is basically the same as for the table component:

module Components
  module Modal
    def modal(&block)
      content = capture_modal_content(&block)

      Components.load_template("modal/_modal.erb", binding)
    end

    # other helpers omitted

    private

    def modal_buffer_stack
      Thread.current[:modal_buffer_stack] ||= []
    end

    def capture_modal_content(&block)
      modal_buffer_stack.push([])
      result = block.call
      buffer = modal_buffer_stack.pop

      buffer.empty? ? result.to_s : buffer.join
    end
  end
end

There are only two differences:

• The thread-local key used to store the component's content in Thread.current is different, :modal_buffer_stack.

• There is an important change in the method that captures the component's content:

  buffer.empty? ? result.to_s : buffer.join
  

  It falls back to the block's return value if the block did not call any DSL child.

  For instance:

  modal_header { "Confirm status change" }
  

  The block returns a bare string, so nothing is pushed to the buffer. Without the fallback, those blocks would render empty.

  Table got away with pop.join because every table block is expected to contain child DSL calls (table_row, table_cell, etc.).

That code works perfectly for both components, but there is too much duplicated plumbing behind both components.

Extracting the common logic

The next step was to extract the common logic for all components that implement a block DSL into a module so it can be reused:

module ContentBuffer
  def self.included(base)
    base.extend(ClassMethods)
  end

  module ClassMethods
    def content_buffer_key(key)
      define_method(:_content_buffer_key) { key }

      private :_content_buffer_key
    end
  end

  private

  def buffer_stack
    Thread.current[_content_buffer_key] ||= []
  end

  def capture_content(&block)
    buffer_stack.push([])
    result = block.call
    buffer = buffer_stack.pop

    buffer.empty? ? result.to_s : buffer.join
  end

  def append_to_buffer(html)
    buffer_stack.last << html if buffer_stack.any?

    html
  end
end

A class-level setter handles the thread-local key name in the clients of the new module:

module Components
  module Table
    include ContentBuffer

    content_buffer_key :table_buffer_stack

    def table(&block)
      content = capture_content(&block)

      Components.load_template("table/_table.erb", binding)
    end

    def table_head(&block)
      content = capture_content(&block)
      result = Components.load_template("table/_head.erb", binding)

      append_to_buffer(result)
    end

    # other helpers omitted
  end
end

module Components
  module Modal
    include ContentBuffer

    content_buffer_key :modal_buffer_stack

    def modal(&block)
      content = capture_content(&block)

      Components.load_template("modal/_modal.erb", binding)
    end

    def modal_header(&block)
      content = capture_content(&block)
      result = Components.load_template("modal/_header.erb", binding)

      append_to_buffer(result)
    end

    # other helpers omitted
  end
end

Besides, extracting that logic into a module makes testing easier.

To do this, we first create a couple of test components:

module TestComponents
  module Container
    include ContentBuffer

    content_buffer_key :container_buffer_stack

    def container(&block)
      capture_content(&block)
    end

    def item(content)
      result = "<item>#{content}</item>"

      append_to_buffer(result)
    end

    def group(&block)
      content = capture_content(&block)
      result = "<group>#{content}</group>"

      append_to_buffer(result)
    end
  end

  module Widget
    include ContentBuffer

    content_buffer_key :widget_buffer_stack

    def widget(&block)
      capture_content(&block)
    end

    def widget_part(content)
      result = "<part>#{content}</part>"

      append_to_buffer(result)
    end
  end
end

Then we add the following test examples:

RSpec.describe ContentBuffer do
  let(:component) do
    Class.new do
      include TestComponents::Container
    end.new
  end

  after do
    Thread.current[:container_buffer_stack] = nil
  end

  describe "block return value fallback" do
    it "returns the block return value when no items are appended" do
      result = component.container { "plain text" }

      expect(result).to eq("plain text")
    end

    it "converts non-string return values to string" do
      result = component.container { 42 }

      expect(result).to eq("42")
    end
  end

  describe "buffered content" do
    it "joins appended items" do
      result = component.container do
        component.item("one")
        component.item("two")
        component.item("three")
      end

      expect(result).to eq("<item>one</item><item>two</item><item>three</item>")
    end

    it "ignores the block return value when items are appended" do
      result = component.container do
        component.item("buffered")
        "ignored"
      end

      expect(result).to eq("<item>buffered</item>")
    end
  end

  describe "nested captures" do
    it "inner group does not leak into outer container" do
      result = component.container do
        component.item("before")

        component.group do
          component.item("nested")
        end

        component.item("after")
      end

      expect(result).to eq("<item>before</item><group><item>nested</item></group><item>after</item>")
    end
  end

  describe "isolation between different buffer keys" do
    let(:other_component) do
      Class.new do
        include TestComponents::Widget
      end.new
    end

    after do
      Thread.current[:widget_buffer_stack] = nil
    end

    it "two components with different keys do not interfere" do
      widget_result = nil

      container_result = component.container do
        component.item("a")

        widget_result = other_component.widget do
          other_component.widget_part("b")
        end

        component.item("c")
      end

      expect(container_result).to eq("<item>a</item><item>c</item>")
      expect(widget_result).to eq("<part>b</part>")
    end
  end
end

The third block DSL component: alert

The goal was to create an alert component that would allow consumers to write something like the following inside a single <%= %> tag:

alert(variant: :success) do
  alert_icon
  alert_title { "Payment processed successfully" }
  alert_description { "The transaction has been completed." }
  alert_actions do
    alert_action("View details", variant: :primary, htmx: { ... })
    alert_action("Dismiss", variant: :secondary, htmx: { ... })
  end
end

The variant should set the background color and the border, as well as the icon to display and its color, if alert_icon is included in the alert.

This poses a problem because alert_icon, if it receives no arguments, has to render the default icon according to the variant defined in the parent. However, the buffer does not allow a child to access data from the parent.

Furthermore, the alert's icon and actions are not rendered in the same block as the title and description. The template does not receive a single flat content string to print; instead, it needs the icon and actions separately, as independent variables, to place them in their respective spots. The buffer at this point only returns a plain string with everything concatenated and is incapable of separating that out.

The code that solves these problems is the following:

def context_stack
  Thread.current[:"#{_content_buffer_key}_context"] ||= []
end

def set_context(metadata)
  context_stack.push(metadata)
end

def reset_context
  context_stack.pop
end

def current_context
  context_stack.last || {}
end

Therefore, the ContentBuffer module now has two main parts:

• Buffer: a linear, append-only stream of HTML fragments from children.

• Context: a shared hash the parent seeds, that children can read from and write into.

The context key is derived from the same _content_buffer_key the buffer uses, with a _context suffix appended. This way, each component that includes ContentBuffer ends up with its own isolated buffer stack and context stack.

The context uses a stack, rather than a single hash, for the same reason the buffer does: a component nested inside another cannot overwrite the parent's context.

The implementation of the alert component, slightly simplified, is as follows:

module Components
  module Alert
    include ContentBuffer

    content_buffer_key :alert_buffer_stack

    VARIANTS = {
      success: {
        ...
      },
      error: {
        ...
      },
    }.freeze

    def alert(variant:, &block)
      set_context(variant:, icon: nil, actions: nil)

      content = capture_content(&block)
      alert_icon = current_context[:icon]
      alert_actions = current_context[:actions]

      reset_context

      Components.load_template("alert/_alert.erb", binding)
    end

    def alert_icon(icon_name = nil)
      variant = current_context[:variant]

      current_context[:icon] = icon(icon_name || VARIANTS.dig(variant, :icon_name))

      ""
    end

    def alert_title(&block)
      content = capture_content(&block)
      result = Components.load_template("alert/_title.erb", binding)

      append_to_buffer(result)
    end

    def alert_description(&block)
      content = capture_content(&block)
      result = Components.load_template("alert/_description.erb", binding)

      append_to_buffer(result)
    end

    def alert_actions(&block)
      content = capture_content(&block)

      current_context[:actions] = Components.load_template("alert/_actions.erb", binding)

      ""
    end

    def alert_action(text, **options)
      result = button(text, **options)

      append_to_buffer(result)
    end
  end
end

Two points to highlight here:

• alert_icon and alert_actions return an empty string. Instead of writing to the buffer, they store their rendered HTML in a named slot in the context (:icon and :actions respectively). The parent alert method reads those slots into its own local variables after running the block, and passes them to the template as independent variables.

• alert_title and alert_description write to the buffer exactly like table and modal children do, so they end up in the concatenated content.

A single alert uses both mechanisms: title and description go into the concatenated content, icon and actions into named slots.

Next, we create a couple more test components:

module TestComponents
  # other code omitted

  module Panel
    include ContentBuffer

    content_buffer_key :panel_buffer_stack

    def panel(variant:, &block)
      set_context(variant:, icon: nil)

      content = capture_content(&block)
      icon = current_context[:icon]

      reset_context

      "<panel variant='#{variant}' icon='#{icon || "none"}'>#{content}</panel>"
    end

    def panel_icon
      variant = current_context[:variant]

      current_context[:icon] = "icon-for-#{variant}"

      ""
    end

    def panel_body(content)
      append_to_buffer("<body>#{content}</body>")
    end

    def read_current_context
      current_context
    end
  end

  module Banner
    include ContentBuffer

    content_buffer_key :banner_buffer_stack

    def banner(variant:, &block)
      set_context(variant:)

      content = capture_content(&block)

      reset_context

      "<banner variant='#{variant}'>#{content}</banner>"
    end

    def read_current_context
      current_context
    end
  end
end

And we add the following test examples:

RSpec.describe ContentBuffer do
  # other code omitted

  describe "context stack" do
    let(:panel_component) do
      Class.new do
        include TestComponents::Panel
      end.new
    end
    let(:banner_component) do
      Class.new do
        include TestComponents::Banner
      end.new
    end

    after do
      Thread.current[:panel_buffer_stack] = nil
      Thread.current[:panel_buffer_stack_context] = nil
      Thread.current[:banner_buffer_stack] = nil
      Thread.current[:banner_buffer_stack_context] = nil
    end

    it "returns empty hash when no context is set" do
      expect(panel_component.read_current_context).to eq({})
    end

    it "sets and clears context" do
      inside_context = nil

      panel_component.panel(variant: :success) do
        inside_context = panel_component.read_current_context
      end

      expect(inside_context).to eq(variant: :success, icon: nil)
      expect(panel_component.read_current_context).to eq({})
    end

    it "nests contexts" do
      nested_context = nil
      outer_context_after = nil

      panel_component.panel(variant: :info) do
        panel_component.panel(variant: :error) do
          nested_context = panel_component.read_current_context
        end

        outer_context_after = panel_component.read_current_context
      end

      expect(nested_context).to eq(variant: :error, icon: nil)
      expect(outer_context_after).to eq(variant: :info, icon: nil)
    end

    it "isolates context between different buffer keys" do
      panel_context = nil
      banner_context = nil

      panel_component.panel(variant: :success) do
        banner_component.banner(variant: :error) do
          panel_context  = panel_component.read_current_context
          banner_context = banner_component.read_current_context
        end
      end

      expect(panel_context).to eq(variant: :success, icon: nil)
      expect(banner_context).to eq(variant: :error)
    end
  end
end

The full ContentBuffer module

Putting it all together, the final ContentBuffer module looks like this:

module ContentBuffer
  def self.included(base)
    base.extend(ClassMethods)
  end

  module ClassMethods
    def content_buffer_key(key)
      define_method(:_content_buffer_key) { key }

      private :_content_buffer_key
    end
  end

  private

  def buffer_stack
    Thread.current[_content_buffer_key] ||= []
  end

  def capture_content(&block)
    buffer_stack.push([])
    result = block.call
    buffer = buffer_stack.pop

    buffer.empty? ? result.to_s : buffer.join
  end

  def append_to_buffer(html)
    buffer_stack.last << html if buffer_stack.any?

    html
  end

  def context_stack
    Thread.current[:"#{_content_buffer_key}_context"] ||= []
  end

  def set_context(metadata)
    context_stack.push(metadata)
  end

  def reset_context
    context_stack.pop
  end

  def current_context
    context_stack.last || {}
  end
end

Possible improvements

The module is simple and covers every block DSL component I have needed so far, but there are still a few rough edges worth calling out before wrapping up, although it is not meant to be a thorough list:

1. Exception safety: capture_content pushes and pops the buffer stack by hand, and alert does the same with set_context and reset_context. If the block raises in between, the stack keeps the orphaned frame. A begin/ensure around each pair fixes both.

2. Explicit buffer-vs-context contract: Writing to the buffer means returning a string; writing to a slot means returning "" and assigning into the context by hand. A helper like with_slot(slot_name) { ... } would make the slot write the block's explicit purpose instead of an empty-string side effect.

3. Typed context slots: The slots :icon, :actions, and :variant are untyped hash keys, so a typo silently returns nil. A context_slots class macro, alongside content_buffer_key, would declare each component's slots and catch typos.

4. Rename the module: ContentBuffer fit when there was only a buffer. With the context stack in place, it should have a name that fits better.

5. Extend module API: add a method to reset the values stored in the tests, instead of assigning nil in an after block.

Conclusion

Building your own component system from scratch forces you to face problems that frameworks like Rails solve for you. Once you solve them yourself, even in a small way, they stop feeling like magic.

The ContentBuffer module is not trying to be a general-purpose abstraction. It only has to work for the components that use it today, and that is why it stays small.

In exchange, what you get is Rails-like ergonomics on top of ERB in Sinatra, with no extra dependencies. There is still room for improvement, but the core is simple and easy to test.

If you have an alternative approach to this problem, feel free to share it with me.

Thank you for reading, and see you in the next one!

The code in that application was quite legacy and highly coupled to an existing API. It was poorly tested, and even those tests did not have a make command to run locally nor were they running in the CI pipeline.

It consisted of a Sinatra application that acts as a proxy between a React frontend and a backend API. For a long time, this proxy only knew about one API, so everything was built around that single dependency.

Then I needed to add support for a new API. But first, I had to isolate anything that was coupled to the existing API, thus making room for the upcoming changes.

In the examples below, I have omitted code that is unnecessary to understand the process, such as logging and observability instrumentation.

The initial setup

The backend application is very simple. The entry point is config.ru, which maps routes to different Rack apps via a Dispatcher:

# system/infrastructure/dispatcher.rb
module Infrastructure
  Dispatcher = Rack::Builder.app do
    map '/' do
      run System::Server
    end

    map '/api' do
      run System::Proxy
    end
  end
end

The server handles static file serving for the React SPA:

# system/server.rb
module System
  class Server < Sinatra::Base
    set root: File.expand_path('..', __dir__)

    not_found do
      render_static_file
    end

    get '/' do
      render_static_file
    end

    private

    def render_static_file
      File.read(File.join('public', 'index.html'))
    end
  end
end

The proxy delegates to a request handler, where the actual API proxying happens:

# system/request_handler.rb
module System
  class RequestHandler
    UNAUTHORIZED_CODE = 401
    ALLOWED_PATHS = %w(
      /beneficiary_collections
    )
    ALLOWED_METHODS = %w(GET PUT PATCH POST)
    HEADERS = { 'Content-Type' => 'application/json' }

    def initialize(env)
      @request = Rack::Request.new(env)
    end

    def call
      return render(UNAUTHORIZED_CODE, { error: 'Unauthorized' }.to_json) if invalid_path && invalid_request_method

      response = # HTTParty logic

      render(response.code, response.body)
    end

    private

    def invalid_path
      !ALLOWED_PATHS.include?(path)
    end

    def invalid_request_method
      !ALLOWED_METHODS.include?(@request.request_method)
    end

    def render(status, body)
      [status, HEADERS, [body]]
    end

    def api_url
      ENV['API_BASE_URL']
    end

    # other private methods omitted
  end
end

If you look closely at the call method, the guard clause uses && instead of ||. This means it only returns unauthorized when both the path and the method are invalid, not when either one is. This was a bug that was present from the start and that I would fix later as part of this process.

Notice that api_url always returns the same environment variable regardless of the request path. The whole request handler assumes there is only one API.

First changes: routing through the proxy

Here is something I had not noticed before: in the local development environment, the frontend was bypassing the proxy entirely. The webpack dev server was configured to send API requests directly to the API stub.

The webpack dev server configuration was as follows:

// client/webpack/webpack.development.js
const API_BASE_URL = process.env.API_BASE_URL || 'http://beneficiary_collections_api:5300';

module.exports = {
  // ...
  devServer: {
    host: '0.0.0.0',
    port: 3001,
    allowedHosts: 'all',
    historyApiFallback: true,
    proxy: {
      '/api': {
        target: API_BASE_URL,
        pathRewrite: { '^/api': '' }
      },
      // ...
    }
  }
}

The pathRewrite stripped the /api prefix and sent requests straight to the stub. This meant the Sinatra proxy was never involved in local development. Consequently, you cannot test routing if you are skipping the proxy.

To fix this, I added a backend service to docker-compose.yml and renamed app to frontend:

services:
  frontend:
    ports:
      - 3001:3001
    depends_on:
      - backend
    command: npm start

  backend:
    ports:
      - 8080:8080
    depends_on:
      - beneficiary_collections_api
    command: bundle exec rerun --dir . --pattern "**/*.{rb}" --background -- rackup --port=8080 -o 0.0.0.0 config.ru

  beneficiary_collections_api:
    build:
      context: ./stubs/beneficiary_collections_api
    ports:
      - 5300:5300
    command: bundle exec rerun --dir . --background -- rackup --port=5300 -o 0.0.0.0 config.ru

I installed the rerun gem so the backend application would automatically restart when any Ruby file changed.

Note that the page still needs to be reloaded in the browser. Until the backend is fully reloaded, requests will return a 504 error.

Then I updated the webpack dev server to point at the backend instead of the API stub directly:

// client/webpack/webpack.development.js
const BACKEND_URL = process.env.BACKEND_URL || 'http://backend:8080';

module.exports = {
  // ...
  devServer: {
    host: '0.0.0.0',
    port: 3001,
    allowedHosts: 'all',
    historyApiFallback: true,
    proxy: {
      '/api': {
        target: BACKEND_URL
      },
      // ...
    }
  }
}

No more pathRewrite. The /api prefix is now kept as-is, and the backend proxy handles it from there. This matches how the application works in staging and production.

Finally, I refactored the scarce tests to route them through the Dispatcher instead of testing the proxy in isolation, and added the make command to be able to run those tests locally:

# spec/requests/api/proxy_spec.rb
RSpec.describe 'Proxy' do
  include Rack::Test::Methods

  def app
    Infrastructure::Dispatcher
  end

  context 'when beneficiary_collections' do
    let(:base_url) { 'https://beneficiary-collections.lol' }

    before do
      allow(ENV).to receive(:[]).with('API_BASE_URL').and_return(base_url)

      stub_request(:get, "#{base_url}/beneficiary_collections")
        .to_return(status: 200, body: { message: 'Success' }.to_json)

      stub_request(:get, "#{base_url}/beneficiary_collections/invalid")
        .to_return(status: 401, body: { message: 'Unauthorized' }.to_json)
    end

    context 'when the URL is allowed' do
      it 'returns a 200 status code' do
        get '/api/beneficiary_collections'

        expect(last_response.status).to eq(200)
      end
    end

    context 'when the URL is not allowed' do
      it 'returns a 401 status code' do
        get '/api/beneficiary_collections/invalid'

        expect(last_response.status).to eq(401)
      end
    end
  end
end

Isolating the old API

I applied a set of changes in both the frontend and the backend.

The key backend change was making api_url conditional in the request handler instead of returning always the same environment variable (properly renamed below):

# system/request_handler.rb
def api_url
  if path.start_with?('/beneficiary_collections')
    ENV['BENEFICIARY_COLLECTIONS_API_BASE_URL']
  end
end

The tests were properly updated, too, adding a specific context for the beneficiary collections API.

On the frontend side, the template that renders the beneficiary collection form was extracted from the page where it was being rendered, so it could be easily duplicated later. I also updated the existing test suite using React Testing Library, adding a new context to ensure the extracted components still behaved correctly in isolation.

Adding the new API

With the groundwork done, adding the new API was straightforward.

On the React side, a new route was added:

// client/src/pages/App/App.js
import Home from 'pages/Home';
import CollectionRequestsHome from 'pages/CollectionRequestsHome';

function App() {
  return (
    <Router>
      <ContextWrapper>
        <Switch>
          <Route exact path="/" component={Home} />
          <Route exact path="/collection_requests" component={CollectionRequestsHome} />
        </Switch>
      </ContextWrapper>
    </Router>
  );
}

export default App;

All components were duplicated and adapted to the collection requests form, including the endpoints specific to the new API. Every change on the frontend was accompanied by new unit and integration tests.

On the backend, the request handler received several improvements:

• All constants are frozen.

• The status code for invalid requests was changed from 401 to 404, which is more semantically correct.

• The validation methods became proper predicate methods.

• An attribute reader was added for the request.

• The api_url method now routes based on the request path prefix.

# system/request_handler.rb
module System
  class RequestHandler
    NOT_FOUND_STATUS_CODE = 404
    ALLOWED_PATHS = %w[
      /beneficiary_collections
      /collection_requests
    ].freeze
    ALLOWED_METHODS = %w[GET PUT PATCH POST].freeze
    HEADERS = { 'Content-Type' => 'application/json' }

    def initialize(env)
      @request = Rack::Request.new(env)
    end

    def call
      if invalid_path_info? || invalid_request_method?
        return render(NOT_FOUND_STATUS_CODE, { error: 'Not found' }.to_json)
      end

      response = # HTTParty logic

      render(response.code, response.body)
    end

    private

    attr_reader :request

    def invalid_path_info?
      !(request.path_info.match?(Regexp.union(ALLOWED_PATHS)))
    end

    def invalid_request_method?
      !(ALLOWED_METHODS.include?(request.request_method))
    end

    def render(status, body)
      [status, HEADERS, [body]]
    end

    def api_url
      if path.start_with?('/beneficiary_collections')
        ENV['BENEFICIARY_COLLECTIONS_API_BASE_URL']
      elsif path.start_with?('/collection_requests')
        ENV['COLLECTION_REQUESTS_API_BASE_URL']
      end
    end

    # other private methods omitted
  end
end

The server needed a new route too:

# system/server.rb
get '/collection_requests/' do
  render_static_file
end

That trailing slash on get '/collection_requests/' will come back to haunt me.

A new stub application was added for the collection requests API, and docker-compose.yml was updated to include it:

services:
  collection_requests_api:
    build:
      context: ./stubs/collection_requests_api
    ports:
      - 5301:5301
    command: bundle exec rerun --dir . --background -- rackup --port=5301 -o 0.0.0.0 config.ru

A new context block for the collection requests API was added to the proxy test, mirroring the beneficiary collections one.

The trailing slash problem

The code was working perfectly locally. Tests were green. It got merged and deployed to staging. And then the collection requests form did not render.

The issue turned out to be a trailing slash added to the route, while React router navigated to /collection_requests, without the trailing slash.

Sinatra does not treat these the same way by default, and it is well documented in their FAQ section.

The fix was to make the route accept both:

# system/server.rb
get '/collection_requests/?' do
  render_static_file
end

The /? at the end makes the trailing slash optional. The not_found handler was also restored so that unknown routes would still serve the SPA. It returns a 404 status code so the React app can show its own not found page.

On the frontend, the webpack dev server configuration also changed. The historyApiFallback option was replaced with a custom middleware that validates routes and handles trailing slashes:

// client/webpack/webpack.development.js
const VALID_PATHS = ['/', '/collection_requests'];

module.exports = {
  historyApiFallback: false,
  setupMiddlewares: (middlewares, devServer) => {
    devServer.app.get('*', (req, res, next) => {
      if (req.headers.accept?.includes('text/html')) {
        const normalizedPath = req.path.replace(/\/$/, '') || '/';

        if (!VALID_PATHS.includes(normalizedPath)) {
          res.status(404);
        }

        req.url = '/index.html';
      }

      next();
    });

    return middlewares;
  },

Not very elegant, but it works.

The React app also got a catch-all route for unknown paths, with a NotFound component:

// client/src/pages/App/App.js
import NotFound from 'pages/NotFound';

// ...
<Route path="*" component={NotFound} />

I also added minimal testing for the server to cover both with and without trailing slash:

# spec/requests/server_spec.rb
RSpec.describe 'Server' do
  include Rack::Test::Methods

  def app
    Infrastructure::Dispatcher
  end

  before do
    allow(File).to receive(:read).and_call_original
    allow(File).to receive(:read).with(File.join('public', 'index.html')).and_return('html content')
  end

  context 'when path is /' do
    it 'returns a 200 status code and HTML content' do
      get '/'

      expect(last_response.status).to eq(200)
      expect(last_response.headers['Content-Type']).to include('text/html')
    end
  end

  context 'when path is /collection_requests' do
    it 'returns a 200 status code and HTML content' do
      get '/collection_requests'

      expect(last_response.status).to eq(200)
      expect(last_response.headers['Content-Type']).to include('text/html')
    end
  end

  context 'when path is /collection_requests/' do
    it 'returns a 200 status code and HTML content' do
      get '/collection_requests/'

      expect(last_response.status).to eq(200)
      expect(last_response.headers['Content-Type']).to include('text/html')
    end
  end

  context 'when path is invalid' do
    it 'returns a 404 status code and HTML content' do
      get '/invalid'

      expect(last_response.status).to eq(404)
      expect(last_response.headers['Content-Type']).to include('text/html')
    end
  end
end

To prevent this from happening again, I added some make commands to run the application in production mode locally:

# Makefile
.PHONY: prod/up prod/down prod/build

prod/up:
  docker compose -f docker-compose.prod.yml up

prod/down:
  docker compose -f docker-compose.prod.yml up

prod/build:
  docker compose -f docker-compose.prod.yml build

The dedicated docker-compose file is as follows:

# docker-compose.prod.yml
services:
  app:
    ports:
      - 8080:80
    depends_on:
      - beneficiary_collections_api
      - collection_requests_api
    environment:
      - NODE_ENV=production

  beneficiary_collections_api:
    build:
      context: ./stubs/beneficiary_collections_api
    ports:
      - 5300:5300
    volumes:
      - ./stubs/beneficiary_collections_api:/opt/stubs
    command: bundle exec rerun --dir . --background -- rackup --port=5300 -o 0.0.0.0 config.ru

  collection_requests_api:
    build:
      context: ./stubs/collection_requests_api
    ports:
      - 5301:5301
    volumes:
      - ./stubs/collection_requests_api:/opt/stubs
    command: bundle exec rerun --dir . --background -- rackup --port=5301 -o 0.0.0.0 config.ru

From now on, catching the kind of failure caused by trailing slashes locally is way easier.

Conclusion

Adding support for a new API provided an opportunity to harden a legacy application. We moved from a poorly tested setup that bypassed its own proxy locally to a robust environment with proper routing and test coverage.

The challenges I faced, from the logic bug in the guard clause to the trailing slash discrepancy, demonstrate why dev-to-production parity is essential. With these changes in place, the application is no longer tied to a single dependency, and the team can now develop and test new features with the confidence that "working locally" actually means "working in production."

Thank you for reading and see you in the next one!

The problem: code duplication

The naive approach looks like this:

<div class="example">
  <%= primary_button "Button" %>
</div>

<%= erb :_toggle_code, locals: { code: 'primary_button "Button"' } %>

The first block calls the Ruby helper to render the actual button. The second block passes the same call as a string to a partial that displays it:

<code><%= code %></code>

This works, but the code is duplicated. Update one, forget the other, and they drift apart. With dozens of examples, that drift becomes inevitable.

Single source of truth

The idea is straightforward: store the code as a string, then eval it to render the component, and display the source.

I wrapped the logic in a helper module:

def render_code_example(code)
  eval(code.strip, binding)
end

Disclaimer: this is an internal tool, never use this pattern with untrusted or user-generated input.

That worked for simple, single-line examples:

<div class="example">
  <% example = 'primary_button "Button"' %>

  <%= render_code_example(example) %>

  <%= erb :_toggle_code, locals: { code: example } %>
</div>

However, I found that examples with multiple lines, like a fieldset containing several radio buttons, would only render the last one. eval returns the value of the last expression, so intermediate lines were lost:

<div class="example">
  <%
    example = <<-CODE
      radio_input(name: "contact", value: "email", id: "contact_email", label: "Email")
      radio_input(name: "contact", value: "phone", id: "contact_phone", label: "Phone")
    CODE
  %>

  <fieldset>
    <legend>Select your preferred contact method:</legend>
    <%= render_code_example(example) %>
  </fieldset>

  <%= erb :_toggle_code, locals: { code: example } %>
</div>

The fix was to split the string into lines and eval each one independently:

def render_code_example(code)
  code.strip.split("\n").map { |line| eval(line.strip, binding) }.join("\n")
end

The method splits the string into lines, evaluates each one in the current binding (which has access to all the component helper methods), and joins the results. Each line is an independent Ruby expression that returns HTML.

The example is now defined once: render_code_example executes it, and the _toggle_code partial displays it.

That solved the rendering side, but the output code was not quite right. The <code> element collapses whitespace by default, so both radio buttons are shown in a single line:

radio_input(name: "contact", value: "email", id: "contact_email", label: "Email") radio_input(name: "contact", value: "phone", id: "contact_phone", label: "Phone")

Wrapping the output in a <pre> tag preserves the line breaks:

<pre><code><%= code %></code></pre>

That fixed the formatting, but introduced a new issue. The heredoc (<<-CODE) preserves the indentation from the ERB template, so the output code was rendered with leading spaces:

            radio_input(name: "contact", value: "email", id: "contact_email", label: "Email")
            radio_input(name: "contact", value: "phone", id: "contact_phone", label: "Phone")

Switching to a squiggly heredoc (<<~CODE) stripped the common leading indentation automatically.

Finally, since the code string may contain HTML characters, the partial escapes it before rendering:

<pre><code><%= escape_code_example(code) %></code></pre>

That new helper uses Rack::Utils.escape_html to handle the escaping.

This eliminated the duplication problem for all examples where each line is an independent Ruby expression.

The new challenge: HTML components

Then a new table component was needed, and instead of building a Ruby helper the first approach was a CSS-only component: plain HTML with custom styles.

<table class="fw-table">
  <thead>
    <tr>
      <th>Name</th>
      <th>Email</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Alice</td>
      <td>alice@example.com</td>
    </tr>
  </tbody>
</table>

You cannot eval HTML. It is not Ruby. A different approach was needed.

When ERB processes a template, it appends the rendered content to a string buffer. In Sinatra, that buffer is the instance variable @_out_buf. The idea was to record the buffer's length before a block executes, let the block run, and then slice out everything that was appended during it:

def capture_html(&block)
  buffer = @_out_buf
  pos = buffer.length
  yield
  dedent(buffer.slice!(pos..-1))
end

The slice! call is important: it removes the captured content from the buffer so it is not rendered twice.

There was one more problem. The captured HTML carries the indentation of the ERB template it lives in. Since the code display uses a <pre> tag, that indentation shows up as unwanted leading spaces.

A dedent helper strips the common leading whitespace, normalizing the output regardless of how deeply nested the ERB block was:

def dedent(text)
  margin = text.scan(/^[ \t]*(?=\S)/).map(&:size).min || 0

  text.gsub(/^[ \t]{#{margin}}/, '').strip
end

With those two helpers in place, the ERB usage followed the same single-definition pattern:

<% example = capture_html do %>
  <table class="fw-table">
    <thead>
      <tr>
        <th>Name</th>
        <th>Email</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td>Alice</td>
        <td>alice@example.com</td>
      </tr>
    </tbody>
  </table>
<% end %>

<%= example %>

<%= erb :_toggle_code, locals: { code: example } %>

Write the HTML once. capture_html grabs it as a string. Output it for rendering, pass it for display.

Unification: block detection

The CSS-only table did not last long. It was eventually replaced with a Ruby block DSL, where the table is built through nested method calls:

table do
  table_head do
    table_row do
      table_header_cell("Name")
      table_header_cell("Email")
    end
  end
  table_body do
    table_row do
      table_cell("Alice")
      table_cell("alice@example.com")
    end
  end
end

Now render_code_example had to handle this too. But unlike the radio buttons from before, these lines are not independent expressions. They form a single do...end block, and evaluating table do in isolation is a syntax error.

The fix was to detect whether the code is a block expression and, if so, evaluate it as a whole instead of line by line:

def render_code_example(code)
  stripped = code.strip

  if block_expression?(stripped)
    eval(stripped, binding)
  else
    stripped.split("\n").map { |line| eval(line.strip, binding) }.join("\n")
  end
end

private

def block_expression?(code)
  code.match?(/\bend\z/)
end

The check is simple: if the code ends with the end keyword, treat it as a block. \b ensures it matches the whole word, and \z anchors to the end of the string.

In the ERB template, multi-line code uses a heredoc to keep things readable:

<%
  example = <<~CODE
    table do
      table_head do
        table_row do
          table_header_cell("Name")
          table_header_cell("Email")
        end
      end
      table_body do
        table_row do
          table_cell("Alice")
          table_cell("alice@example.com")
        end
      end
    end
  CODE
%>

<%= render_code_example(example) %>

<%= erb :_toggle_code, locals: { code: example } %>

With this change, capture_html and dedent were no longer needed. Every component in the showcase now uses Ruby helpers, so the buffer-interception approach was removed entirely.

Conclusion

The core idea never changed: define each example once, then use it for both rendering and display. What evolved was the mechanism: from eval on single lines, to line-by-line splitting, to buffer interception for raw HTML, and finally to block detection when the Ruby DSL arrived. Each iteration solved a real problem introduced by the previous one.

The final code is straightforward, but it earned that simplicity one edge case at a time:

module Helpers
  module CodeExample
    def escape_code_example(*strings)
      Rack::Utils.escape_html(strings.join("\n\n"))
    end

    def render_code_example(code)
      stripped = code.strip

      if block_expression?(stripped)
        eval(stripped, binding)
      else
        stripped.split("\n").map { |line| eval(line.strip, binding) }.join("\n")
      end
    end

    private

    def block_expression?(code)
      code.match?(/\bend\z/)
    end
  end
end

If you have an interesting alternative approach to this problem, feel free to share it with me.

Thank you for reading and see you in the next one!

Disclaimer: This is not a sponsored post.

I recently registered the domain davidmontesdeoca.dev through sav.com. At the time of this writing, they offer a highly competitive price of \(4.99 for the first year, with a renewal rate of \)12.68 per year.

After configuring the blog DNS on Hashnode, I was surprised to find no option for setting up an email account. Since the feature was missing from the control panel, I contacted customer support via their web chat. They confirmed that they do not provide email services, though they did recommend several third-party email providers.

Until now, every time I registered a domain, I had access to a webmail service and had the possibility of creating an email account and multiple aliases for it. Usually, I would configure Gmail to receive and send emails for and from that email address too.

Ultimately, I chose ProxiedMail as my proxy-email provider, a service that was not among the recommendations from the sav.com team. I was impressed by their security and privacy-focused approach, the intuitive dashboard for configuring proxy-emails, and the availability of the following features within their free tier:

The following steps outline how I configured a proxy-email specifically for this post: blog-post[@]davidmontesdeoca.dev.

After registration, the dashboard allows you to create a new proxy-email:

Since I am using a custom domain, I must first add it to the system:

The verification process involves several steps:

To begin the verification, navigate to sav.com: My Domains -> davidmontesdeoca.dev -> Manage DNS -> Custom DNS.

The process for each record is identical: create a record in the domain provider dashboard using the data provided by the proxy-email service, then verify the record.

First, you must verify the domain ownership:

Type: TXT
Name: davidmontesdeoca.dev
Value: proxiedmail-verification=<verification code>

Using @ as the name works exactly the same way.

In the Proxy settings, you must select DNS Only. Choosing Enabled will trigger the following error:

Code 9004: This record type cannot be proxied.

Once ownership is verified, proceed to the MX record configuration:

Add the following record at your domain provider:

Type: MX
Name: davidmontesdeoca.dev
Value: mx.proxiedmail.com
Priority: 10
Proxy: DNS Only

Once the MX record is verified, proceed to the SPF record configuration:

The process for adding this record is the same:

Type: TXT
Name: davidmontesdeoca.dev
Value: v=spf1 include:spf.proxiedmail.com ~all
Proxy: DNS Only

Once the SPF record is verified, optionally proceed to the DKIM record configuration, which helps ensure your forwarded emails are not marked as spam by receiving servers:

To enable DKIM, add the following record:

Type: CNAME
Name: dkim._domainkey.davidmontesdeoca.dev
Value: dkim._domainkey.pxdmail.com
Proxy: Enabled

While other verifications are near-instant, this one may take longer to propagate. Once applied, you will see the message: You are all set.

You are now ready to create your first proxy-email using your verified custom domain:

A confirmation message will appear:

With forwarding enabled by default, emails sent to the proxied email address will be received at your specified real email account:

The email arrived in less than a minute:

This only works if the recipient is in the To field. During testing, emails where the recipient was placed in the BCC field were not delivered.

In the dashboard you can see the total number of emails forwarded to the new address:

ProxiedMail also supports wildcard proxy email addresses:

A modal explains the functionality:

As with the other proxy-email, forwarding is active immediately:

The email sent to this email address was also delivered in less than a minute:

In the dashboard you can see the total number of emails forwarded to this new address too:

To conclude, I will highlight several other features available on the platform, both free and paid:

• Deleting proxy-emails is a paid feature. On the free plan, you can only disable unused email addresses:

  

• Hiding the forwarded email banner is also a paid feature:

  

• Adding an extra layer of securiy to your account with Two-Factor Authentication (2FA) is only available in a paid tier.

• Storing a password to send emails via an alias did not work with Gmail during my testing; so most likely it requires a paid plan:

  

  However, they offer a compelling feature for managing contacts:

  

  This uses a reverse alias process, which worked perfectly in my tests (though the initial email was flagged as spam):

  

• Using unique email addresses for every site where you register to track potential data leaks:

  

• Adding context to remember the purpose of each proxy-email:

  

• Identifying which proxy received a specific message with a reverse lookup:

  

It is also worth noting that if you use the free tier, ProxiedMail requires you to verify your account via email every quarter. This is a simple process to confirm your account is still active and helps them manage inactive accounts:

Thank you for using ProxiedMail.

You are receiving this as part of the quarterly verification of your ProxiedMail account. This verification allows us to track the active accounts and prevent spam.

All accounts that didn't pass the verification during the year could be frozen. That means you will stop receiving your messages when the account is frozen. Although, your account will be unfrozen on any activity in your account.

Additionally, verifying your account will give you some benefits as faster messages delivery and priority support.

The service offers other functionalities beyond those listed here. I encourage you to see for yourself.

Although I have not tested every feature yet, what I have discovered while writing this post is impressive and definitely offers a significantly better user experience than relying on a provider's native webmail interface.

I really like ProxiedMail's approach, being a compelling alternative to traditional email setups. It is also significantly easier to configure.

Thank you for reading and see you in the next one!

But that's not all. As I see it, the perfect combination is fully remote work with true flexible hours. More on this below.

In my first job in Madrid, I worked from 9 to 7 for a year, with a 2-hour lunch break. Totally incomprehensible, considering I had my food already prepared and just had to heat it up in the microwave. 20 minutes was more than enough time; the rest was a complete waste of time.

Furthermore, during this time of year, with the winter schedule, I essentially did not see the light of day during workdays.

After the first year, the schedule changed to 9 to 6, with a 1-hour lunch break. A considerable improvement, but essentially, I still felt like I was wasting much more time than necessary.

Regardless of how productive I was being on any given day, I had to be warming the chair in the office whether I wanted to or not until quitting time.

Of course, I still missed being able to see the light of day for longer, because with the winter schedule, it gets dark shortly after 6 PM in this part of the world.

Little is said about the effect of sunlight on mood, which can even lead to Seasonal Affective Disorder (SAD).

The situation I am describing is known as presenteeism, although it must be clarified that this term can refer to both virtual and physical presence.

By expecting you to always be available, a pressure is generated that can cause burnout in team members and make their productivity drop, achieving exactly the opposite of what is intended with that culture of control.

Unfortunately, this situation is widespread in the software industry. It has been normalized to such an extent that it is common to find job offers selling the idea of fake flexible hours.

For example, Manfred, a Spanish company that takes improving job offers and recruitment processes seriously, sells that idea in many of its offers (this one available only in Spanish) when the company publishing the offer simply offers slight flexibility to start, but the workday remains rigid.

Certainly, that is better than having no flexibility at all. It may even be enough for people who, for instance, have to take their children to school.

However, true schedule flexibility comes when the company understands that with a culture of objectives (as opposed to the culture of control I mentioned earlier), the norm is to achieve better results and reduce burnout.

Of course, enjoying that privilege implies some obligations on your part:

• Demonstrate reliability, consistently delivering high-quality work on time to build the necessary trust.

• Adopt asynchronous and proactive communication with your manager and the rest of the team, so they know when you will be available and your progress on the task you are currently working on. This ensures the team remains unblocked even when you are not online.

• Be available during the team's core hours (e.g., from 10 am to 2 pm). This is usually a common requirement for companies, although my experience has always been that attending team meetings is sufficient.

If you meet those obligations, I see no reason not to have the freedom to work when you feel your productivity will be highest or when you need blocks of absolute concentration without interruptions; whether that is early in the morning or late at night. It is simply adapting to your natural peak performance hours, which may not be the same every day.

The point is that the company considers you a responsible person who knows how to organize themselves in the best possible way. The main consequence of enjoying a flexible schedule is having a better work-life balance and greater autonomy.

You might work only 5 hours one day and 11 the next. You might even decide to work during the weekend to make up for time you could not dedicate during the week or to get ahead on work because you know that during the following week, you will not be able to dedicate the necessary time.

Perhaps another day you cannot attend a meeting because you have a medical appointment or need to take a break for a few hours because you do not feel well; perhaps you have to go grocery shopping or feel like going out for lunch with friends who are visiting for a few days.

There may be many and varied reasons, but they all come down to the same thing: the freedom to manage your life while fulfilling your work duties.

In the end, it is not about working less, but working better. And you, are you still warming the seat?

Thank you for reading and see you in the next one!

Translating a Figma design into code for the new project I am currently working on, I encountered a specific UI requirement: a container with 3 column sections separated by vertical borders. The catch was that these borders could not span the full height of the container; they needed inset padding at the top and bottom.

Right away, it was clear this was a perfect use case for the wonderful CSS grid property. However, exactly how to achieve those inset borders appearing between the columns was less obvious.

Thanks especially to the invaluable help found in this Reddit thread and this video, I landed on a clean solution involving the [:after](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::after) pseudo-element.

I created a CodePen demonstrating this using plain HTML and CSS:

In my specific case, I am not working with plain CSS but rather Tailwind CSS, so I also created a CodePen adapting the solution to that framework:

Regarding the Tailwind example, I want to highlight a specific decision. My initial intention was to define the utility classes inline directly on the HTML elements, as is standard Tailwind practice.

However, combining the [:not](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:not) and [:last-child](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:last-child) pseudo-classes with the :after pseudo-element seemed to prevent Tailwind from generating the correct CSS rule. Therefore, I opted to use the @apply directive instead and keep the HTML clean.

Finally, because this is a static design with exactly 3 columns, I briefly considered using [:before](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::before) and :after pseudo-elements only on the middle column. However, applying a right border to every item except the last one felt like a more robust approach. It ensures the solution remains scalable should a fourth column be added in the future.

There are surely thousands of ways to achieve this. If you have an interesting alternative method, feel free to share it with me.

Thank you for reading and see you in the next one!

For a long time, the company was focused entirely on education. They finally decided to diversify, betting on the travel and hospitality industry. This new strategy kicked off a project at the start of Q3: building a new tool that allows the company's operators to manage the beneficiary network on behalf of clients.

To add some context, there is already a tool for managing beneficiaries still in use. The problem is, no one on the tech team is happy with it. The general consensus is that, looking back, poor design decisions were made.

In addition to that backend, there is an old SPA, developed with React, that collects the beneficiary data. These beneficiaries get an email notifying them that a client is missing some data to send a payment, which includes a link to a form. Sounds like a scam, right?

The new tool consists of two brand-new applications: a REST API, developed with Sinatra, and an SPA, developed with React.

The backend application is being developed by the same team that has had the governance of the old beneficiaries application, in the Transactional area of the company.

Some members of other teams were selected to temporarily join that team, including myself, to gain context about the project and, in time, we will become part of the new beneficiaries team to take over the governance of all the relevant applications.

The new frontend application, however, is being developed by a team from Romania. They are not part of the Transactional area, a decision made due to a lack of internal staff and the very tight deadline we already had.

The idea was to get an MVP ready by the end of the quarter for a demo with a major German client, a big name in luxury resorts and 5-star hotels. Landing them would be a huge boost, though it was not a sine qua non condition for the project to continue.

From the beginning, the head of the Transactional area was uncomfortable with the fact that a team outside of the area was developing that application, so he soon started pulling strings to see what the options were for starting what became known as "the migration."

According to what I was told, the main reason they chose me for this new team was my willingness to work with frontend applications. In this company, almost everything is backend, and the little frontend that exists tends to be internal-use applications that do not get much love.

I was asked to do an analysis of how long it would take to do the migration with AI for the two options on the table:

• Being an SPA, move the logic into another existing SPA, even if the applications were unrelated.

• Create a new microfrontend with Sinatra + htmx that would be embedded in the transactional registry application, where other applications are already embedded.

Initially, I had no doubt that the SPA option was the best one, especially if speed was the main goal. Of course, some adjustments would be needed. The two applications had been developed by different teams and the code was organized differently. For example, one managed state locally with useState while the other used Redux for managing the state of the whole application.

However, what they forgot to tell me was that a critical decision had already been made the previous year on future frontend development in the Transactional area: the preferred option is to create microfrontends with Sinatra + htmx.

The main reason being a general lack of frontend expertise among the area's developers. With the high rotation of team members in the same area of the company, they believed that sticking with React would just create friction for future changes or bug fixes.

Obviously, knowing that changed everything. The final goal was to build the microfrontend with Sinatra + htmx in any case.

Before making an estimate, I created a proof of concept UI with Claude Code to generate a paginated list of beneficiaries, following the design of the current frontend application and the same approach as other microfrontends.

The experience was satisfying and frustrating in equal parts. Replicating the design and code from other applications was relatively easy (after iterating a few times), but it usually meant giving the AI agent too much context. As a result, it was very easy for it to end up doing too much or too little.

In the end, I made a rather naive estimate of 4 weeks to complete the migration. Even so, the head of the Transactional area thought it was too much time. The manager of the team later told me he had thought that with AI, it would be a matter of a couple of days.

Of course, I only consider that estimate naive from my current perspective, now that I have much more context on what actually needs to be done.

Shortly after that, I met with my manager for a couple of sessions where we did a much more precise estimation. We divided all the work into tasks with a very clear and reduced scope, and we added a conservative estimate of how long we might take for each one.

As a result of those two sessions, we estimated it would take a single person approximately 8 weeks. Of course, this is not a job where eight people could complete the work in one week. Many tasks simply cannot be parallelized.

With this new estimate, my manager got the buy-in we needed: if new features were strictly necessary, they would be added to the new React SPA, but during Q4, our team would focus entirely on the migration to the Ruby microfrontend.

In the meantime, I took on the task of replicating the existing functionality for collecting beneficiary information from the old SPA for the new beneficiaries application. This turned out to be a not-so-simple task as initially thought. I will talk about that in a future post.

Before the end of Q3, they confirmed that I was going to lead the migration project, which I have already been working on for a few weeks.

The project team consists of an engineering manager, a product manager, a designer, and three software engineers, including myself. The other two engineers will be more focused on backend tasks.

I started by defining the foundational tasks that will set the groundwork for our work in the coming months, while the product manager will take charge of defining the rest of the upcoming tasks.

I want to highlight that, as part of the detailed estimations we did, we factored in time to properly define the rules Claude Code would use, which are mostly already defined in a dedicated repository available company wide. We also dedicated time to learning how to get the most out of the AI with good prompting, though that is a continuous work in progress.

I have also been spending time deepening my knowledge of htmx and Tailwind, which I have little experience with so far.

At the moment, I am creating a design system in Ruby. I am basing it on components from our existing microfrontends and from the design in Figma, using Claude Code and MCPs like chrome-devtools and Figma for assistance.

We have plans to create a gem that will allow us to reuse the components created for this design system in the various microfrontends that already exist.

I do not expect to talk about the project in the coming months, at least until we have finished it. Then, I will write a retrospective post sharing what went well, and what could have gone better.

I would also like to share the technical details of how we solved the obstacles that we will surely find along the way.

I appreciate the trust placed in me, even as a contractor. I believe it is the result of a job well done.

Thank you for reading and see you in the next one!

As I mentioned when I landed this job, working for a consulting firm was not in my plans when I started looking for a new job at the beginning of 2024.

For most of my professional career, I have worked in product companies. And that is not a coincidence. I really love the deep ownership and the opportunity to build and nurture a single product over the long term.

However, after a few months in which things did not go as I expected, I had to lower my expectations. That included having to consider the possibility of working for a consulting firm.

In fact, I applied for the offer that SNGULAR published on LinkedIn, where they were looking for a backend developer specializing in Ruby to work exclusively for a client in the fintech industry, fully remote.

Selection process

The next day I received a phone call from a person from human resources (HR). We talked for a few minutes to see if there could be a fit on both sides and finally scheduled a video call for a few days later.

During that interview, the HR person shared a presentation where they told me in great detail what the company is like and how things work, what was expected of me, and how I would work with the client. They did not reveal who the client was, though.

Then we moved on to the most common part of any interview, where we went into more detail about what we had already discussed briefly on the phone, especially my work experience and my professional and financial expectations. We also spoke in English for a while to test my level.

In the next step, I appreciated that the technical interview felt more like a friendly conversation than a test, which helped ease my nerves and allowed for a more natural chat about my skills. This step was lead by another SNGULAR developer who works for the same client where I would work and who also has a manager role for the rest of the developers working for this client.

He finally told me who the client was, how things work with them, and asked me about my experience with this or that technology. The usual.

There was a third step that they considered unnecessary, which was an interview with the head of SNGULAR and liaison with the client.

A few days later I received a call from HR people and they confirmed that they wanted to hire me if I was interested, but they wanted to wait and see how the interview with the client went.

I had that interview with the client a few days later. It was very similar to the technical interview I had had with the people from SNGULAR previously. It was mainly a conversation in English with the engineering manager and product manager of the team I would be part of if I ended up joining them.

They told me how the American fintech works, they asked me questions about my previous experience and how I had worked on the different previous projects, from a quite technical point of view.

SNGULAR told me afterwards that I would soon hear back about the client's feedback and that, if all went well, they would make me a formal offer. That offer arrived two days later.

The entire process was very straightforward and pleasant, and I felt very comfortable throughout. I am especially grateful that if any of the steps took longer than expected, HR people always kept me informed.

Onboarding

Before my first day at SNGULAR, I received some things at home: a laptop (which you can choose between Windows or macOS), a monitor, a keyboard, a mouse, a backpack, etc.

The first day begins with a meeting with the HR people to welcome you. They share a new presentation where they tell you where to find everything you will need and what to do in case you need help.

Of course, you have to sign the employment contract and configure the laptop following the instructions you receive by email.

Normally, after a couple of weeks of onboarding, you start working with the client. In my case, I already had a vacation scheduled, so my start with the client was delayed until I was back. In the meantime, I started a Ruby training to some colleagues who were not assigned to a project at that time.

Relationship with the company

On a daily basis, I do not have any type of contact with anyone from SNGULAR, except for a teammate.

Weekly we have optional half-hour meetings where all the SNGULAR colleagues who work in the American fintech get together with the company's liaison with the client to share news from either side.

I also have a 1-to-1 once a month with the manager of the SNGULAR developers.

At the end of the year you have your own performance review and that of your managers.

During this time, I have had a meeting with the HR people when I completed 3 months in the company and another one when I celebrated the first year to see how things were going for me and to know how integrated I felt in the company. In both cases the answer was the same. As I work full-time with the client, my relationship with SNGULAR is mostly reduced to receiving my paycheck at the end of the month.

As a curiosity, they also send us a weekly survey to find out how our week has gone.

The company has an office in Madrid, which is quite far from home, more than 1 hour by metro or bus each way. So it is not an option for me to go there regularly.

On the other hand, everyone I have spoken to when I have requested help of any kind has always been very kind, from HR to IT, for example.

Every year, the company celebrates a Christmas and summer party in various parts of Spain and the rest of the world. Those people who do not live in a city where the party is held have the option of going to the party closest to their city and requesting a travel and accommodation allowance of up to €200.

In addition, this month we celebrated the company's 10th anniversary party in Madrid, which was attended by more than 600 people from all over the world. It was a great opportunity to meet most of my colleagues in person.

Advantages

• I work full-time for the same client.

• In case of layoffs at the client, you do not lose your job directly, but are reassigned to another project.

  • If things do not work out in the assigned project on your part either, you can be reassigned to another project as well.

• You have an annual training budget of €500, which can be spent on courses, books, or tickets for technology events; and an annual well-being budget of €200, which can be spent on gym memberships or psychology sessions, to give a few examples.

  • Although it is true that there is not much flexibility to spend it. For example, you cannot use it to buy a standing desk.

  • On the other hand, if the company considers that a course could be interesting for your work, they pay the corresponding license without deducting it from your annual budget. For instance, some of us got a license for the Epic React course by Kent C. Dodds.

• We have certain tax advantages for contracting a private health insurance policy. There are other benefits too that I do not enjoy, such as meal or transportation vouchers, because I do not go to the client's offices on a daily basis.

• We have free access to AI tools, such as the Gemini pro model integrated into many of the company's tools.

• We have the possibility of attending 1-hour English classes once a week, but outside of working hours.

Disadvantages

• In my experience, you earn significantly less than in product development companies, such as start-ups or scale-ups.

• Salary reviews are only conducted once a year, in February. If you have not been working at the company for at least 9 months at that time, usually you have to wait another year for a salary review.

  • As I was told, in very exceptional cases of excellent performance you can opt for a salary review sooner.

  • In my case, my manager promised me a salary review next year and that they would also take into account that I did not have one this year.

• A lot of bureaucracy for everything, which can sometimes mean a simple request takes a few extra steps and days to approve, especially when it comes to an expense related to the money you are assigned annually for training or for well-being.

• I have to report the hours I work twice: once in SNGULAR, where it is simpler because everything is charged to the same client, and another time at the client, where I have to specify the time dedicated to the different team initiatives.

• By working full-time with the client, the feeling of belonging to the company is practically non-existing.

Conclusion

Probably, many of the advantages and disadvantages mentioned above, if not all, are inherent to most consulting firms.

Taking everything into account, I think my experience so far is positive, although there are things that I would undoubtedly change.

Ultimately, my experience shows that the line between consultancy and product company can sometimes be blurry. I would say the most important question is the nature of your specific assignment and your day-to-day team.

Here I just wanted to talk honestly about what my experience with SNGULAR has been so far instead of just leaving a message on Glassdoor.

Looking forward to my second year in the company.

Thank you for reading and see you in the next one!

A key advantage of Cursor for VSCode users is its support for the same keyboard shortcuts, allowing for a seamless transition:

It allowed me to be really productive with this IDE almost immediately. And I say almost, because I ran into some issues when trying to accept AI suggestions on macOS.

Cursor allows you to autocomplete with Tab, the model they have trained in-house. With Tab, you can autocomplete multiple lines and blocks of code and jump in and across files to the next autocomplete suggestion.

As an example, I am going to show what happens when I try to accept a suggestion by adding a simple console.log to a JS file:

You can see that I can only accept a suggestion if I place the cursor over the suggestion itself and click Accept.

I dealt with this issue for longer than I would like to admit before I finally had time to investigate the root cause.

When I was able to look into the problem, I started with a quick Google search, where I did not find a real solution. Actually, that was a good sign, because it probably meant it was due to a misconfiguration on my end.

So, I continued by visually searching for the keyboard shortcuts associated with the tab key.

To do this, you have to go to the command palette (control + shift + p) and type keyboard shortcuts. There, you choose the option that does not specify JSON.

Then, you have to type "tab", with the quotes, or on the right side of the search bar, click Record Keys and press the tab key.

The first detail you might note is that the source for almost all the commands is User. This is because I do not like working with macOS, but I have to for work, so I configured the system to be as similar as possible to my personal laptop with Linux. I have a post where I discussed this topic in more detail.

Another important detail to note is the first command associated with this key and its when clause context: cpp.shouldAcceptTab. We will need to use it pretty soon.

Next, we go back to the command palette and type keyboard shortcuts again. This time, we choose the option that specifies JSON.

Here we have to search for the commands associated with the tab key and disable them one by one until we find the one that is interfering with the expected behavior in Cursor. I started with the most obvious choice:

{
  "key": "tab",
  "command": "tab",
  "when": "editorTextFocus && !editorReadonly && !editorTabMovesFocus"
}

To test my theory, I commented out the entire entry for that shortcut:

As expected, with that command disabled, I can now accept Tab's suggestions. However, I noticed an strange behavior when indenting code, for example.

So, I added the condition we saw earlier, negated, to this command's when clause:

{
  "key": "tab",
  "command": "tab",
  "when": "!cpp.shouldAcceptTab && editorTextFocus && !editorReadonly && !editorTabMovesFocus"
}

Now I can accept Tab's suggestions without interfering with the default behavior of the tab key.

Once again, there was one small detail that still was not working as I expected:

When I had a Tab suggestion and other suggestions from the current context, pressing the tab key accepted the first suggestion from the context, and only when I pressed the tab key again did it accept the expected suggestion.

To find the command that was interfering with this behavior, I disabled them one by one until I found the one:

{
  "key": "tab",
  "command": "acceptSelectedSuggestion",
  "when": "suggestWidgetHasFocusedSuggestion && suggestWidgetVisible && textInputFocus"
}

Remember to re-enable each command after you have confirmed it is not the one you were looking for.

I added the same negated condition to this when clause:

{
  "key": "tab",
  "command": "acceptSelectedSuggestion",
  "when": "!cpp.shouldAcceptTab && suggestWidgetHasFocusedSuggestion && suggestWidgetVisible && textInputFocus"
}

The result is now exactly what I expected:

In this case, the standard behavior of the tab key was clashing with Cursor's AI suggestion feature. The solution was to only trigger the default tab and acceptSelectedSuggestion commands when the AI does not have a suggestion ready.

The key takeaway is not just about this specific fix, but about the power of when clauses for fine-tuning the IDE to behave exactly how you want it to. Hopefully, this guide saves you some time and helps you get back to coding faster.

Thank you for reading and see you in the next one!

Of course, I did not have to try to do the entire migration at once, but rather migrate a list of beneficiaries and a detail view of a specific beneficiary, following the existing design.

The main goal was to find out if it was possible to do it with AI and, if so, how long it would take to complete each functionality compared to how long I estimated it would take to do the same manually.

The client I work for gives each developer a Copilot license for VSCode or a license for Cursor. You can switch between them as many times as you want, but whenever you activate one, the other automatically expires.

In my case, I have been working with VSCode for a while, but I was offered the possibility of trying Cursor as well, to test the integration with Claude Code.

Cursor is an AI-native IDE forked from VS Code, so it allows for a very easy transition from one IDE to the other. However, I found that a few basic shortcuts did not work as expected: save, find, copy, paste, undo, etc.

The issue was directly related to the shortcuts I configured with Karabiner-Elements in macOS to behave like in Linux. I talked about it some time ago here.

VSCode's bundler identifier is very easy to find anywhere if you look for it:

com.microsoft.VSCode

Cursor's bundler identifier is not as widely known. Finally, I came across this Cursor issue, which shows how to get it:

osascript -e 'id of app "Cursor"'

The surprise was that the value seems quite random:

com.todesktop.230313mzl4w4u92

I did not know osascript, so I thought it might not be the bundler identifier I was looking for.

To be sure, I did the same with VSCode:

osascript -e 'id of app "code"'

The value is as expected:

com.microsoft.VSCode

I assumed that, at least for now, that Cursor's bundle identifier would be enough. I added that value to the array of bundle identifiers of one of the shortcuts configured for VSCode in Karabiner-Elements and it worked perfectly.

Finally, I added it to the rest of the shortcuts for VSCode. You can see the complete configuration in this gist.

In case you did not know, the official Karabiner-Elements documentation includes an alternative way to get an application's bundle identifier.

In any case, I continued investigating about that unusual bundler identifier and found this thread in the Cursor forum, where Cursor's CEO and founder confirm that this value will not change, because the application is already published.

Therefore, we can rest assured that it will not be necessary to change the configuration in the future.

Thank you for reading and see you in the next one!

In any case, I must admit that these issues were caused both by bad decisions made in the past and by not having configured these tools properly more recently.

I will use the precise terminology that the Sidekiq wiki recommends. Therefore, I will not use the term worker.

Context

We started with a legacy payouts application, what we call payouts v1 (just v1 from now on).

It is a somewhat old Sinatra application that, among other things, does not use Zeitwerk, so:

• It does not follow a conventional file structure. The namespace of the different classes and modules does not respect the directory hierarchy, so it is common not to find what you expect where you would expect to find it.

• There is no configuration for inflection, but submodules like AMQP or SFTP exist anyway.

• It does not use eager loading in much of the code, so you must require classes and modules explicitly at the beginning of each file.

For a new feature of internal payouts between the company's own accounts, it was decided to do it separately from v1.

The team considered the possibility of making what we call payouts v2 (just v2 from now on) as an independent (micro)service that would communicate with v1 through domain events if needed, but the final choice was leaving the source code of v2 in the same repository as v1.

However, it does not follow the classic directory structure of other monorepos I have worked on before, where each application has a separate subdirectory. In this case, v1 code is still at the root of the repository, while v2 code is inside a /v2 directory.

Although v2 is a somewhat more modern application, using Zeitwerk, for example, there is also a lot of logic copied from v1 and adapted as needed. Sidekiq configuration was not copied, though.

In v1, all available queues, their weight, the maximum concurrency, and the queue where each job will run in are explicitly defined:

bundle exec sidekiq -r ./config/sidekiq_boot.rb -q high_priority,6 -q medium_priority,3 -q low_priority,1 —concurrency 10

In v2, nothing is explicitly defined, so by default, all jobs run in the default queue with a concurrency with 5 threads:

bundle exec sidekiq -r ./config/sidekiq_boot.rb

Both applications run in separate Docker containers.

Although we also have separate containers to run the background jobs with Sidekiq separately, both applications share the same Redis instance. Not only between them, but they also share it with other main applications of the project.

The team is expected to start working on using a non-shared Redis for the payouts application very soon.

The current configuration has caused us many problems, especially with Sidekiq, although we have faced other problems that we will not discuss here.

In the case of v1, we use the sidekiq-scheduler extension to schedule some Sidekiq jobs:

# config/initializers/sidekiq.rb
require "sidekiq"
require "sidekiq-scheduler"

# other logic omitted

redis_config = {
  namespace: "sidekiq_payouts",

  # other keys omitted
}

Sidekiq.configure_client do |config|
  config.redis = redis_config

  # other configurations omitted
end

Sidekiq.configure_server do |config|
  config.redis = redis_config

  # other configurations omitted
end

Sidekiq::Scheduler.enabled = true
Sidekiq::Scheduler.dynamic = true

# config/sidekiq_boot.rb
require "sidekiq"
require "sidekiq-scheduler"

require_relative "./boot"

# other logic omitted

Sidekiq.set_schedule(
  "bank_acknowledge_notification_job",
  {
    every: "3 minutes",
    class: "Jobs::BankAcknowledgedNotificationJob",
    queue: "high_priority"
  }
)

SidekiqScheduler::Scheduler.instance.load_schedule!

Part I

Recently, a new functionality require us to schedule jobs in v2 as well, and we used the same extension for that purpose.

We started by copying the scheduling configuration, not from v1 but from other more modern project, where the same Redis instance is not shared.

An important detail is that when Sidekiq was configured in v2, the same Redis configuration was kept, including the namespace, for the server and the client:

# v2/config/initializers/sidekiq.rb
require "sidekiq"

redis_config = {
  namespace: "sidekiq_payouts",

  # other keys omitted
}

Sidekiq.configure_client do |config|
  config.redis = redis_config

  # other configurations omitted
end

Sidekiq.configure_server do |config|
  config.redis = redis_config

  # other configurations omitted
end

In the first approach to schedule jobs in v2, the configuration was something like this:

# v2/config/sidekiq_boot.rb
require "sidekiq"
require "sidekiq-scheduler"

require_relative "./boot"

# other logic omitted

Sidekiq.schedule = {
  "bank_transfers_download_feedback_files_job": {
    cron: "0 */5 * * * *",
    class: "Jobs::BankTransfers::DownloadFeedbackFilesJob"
  }
}.freeze

Sidekiq::Scheduler.enabled = true

This job is responsible for downloading feedback files from the banks indicating whether the bank transfers were successful or not.

We deployed the changes to production and checked that the new job was running correctly every 5 minutes.

These changes were part of an epic that was still in progress at that moment, so our clients were not yet using them in production.

Coincidentally, the team members involved in this feature had the next day off because it was a public holiday in Madrid.

During our day off, a support ticket was opened reporting that, for some payments from a certain bank, the receipt confirmation had not been sent.

The next day, when we returned to work, we quickly identified the problem: The bank saves the feedback files on the same SFTP server and in the same directory for both processes, with slightly different filename patterns.

The process in v2 was saving a backup copy of those files in an S3 bucket and deleting the files that v1 was supposed to process from the SFTP server.

The process in v1 runs every 3 minutes, so in a particular case, the process in v2 got ahead of the process in v1. The same would have happened the other way around if the new feature for v2 would have been used in production.

Both processes use a filename pattern to determine if they should process a file.

e.g. dbdi.000_report_00000000000000000.xml:

# v1 filename pattern
/dbdi.000_report_*/

# v2 filename pattern
/dbdi\.\d{3}_report_\d{17}\.xml\z/

The filename pattern in v2 is more restrictive but also matches the given filename.

During the QA process of the new feature in v2, we did not notice this problem because it never happened that the process in v1 got ahead of the process in v2.

The solution was quite clear: change the filename pattern in v2, as it includes a different prefix than v1.

However, we first quickly deployed a hotfix to production to prevent the same thing from happening again and thus be able to take enough time to test the change calmly:

# v2/config/sidekiq_boot.rb
require "sidekiq"
require "sidekiq-scheduler"

require_relative "./boot"

# other logic omitted

# Sidekiq.schedule = {
#   "bank_transfers_download_feedback_files_job": {
#      cron: "0 */5 * * * *",
#      class: "Jobs::BankTransfers::DownloadFeedbackFilesJob"
#   }
# }.freeze

# Sidekiq::Scheduler.enabled = true

A better approach is to use environment variables for enabling/disabling that functionality, so we would not need a new deployment.

In production, we simply checked that the new job from v2 was no longer running every 5 minutes. Then, we proceeded to apply the change in the filename pattern and re-enabled Sidekiq Scheduler.

# v1 filename pattern
/\Adbdi.000_report_*/

# v2 filename pattern
/\A[A-Z]{3}_dbdi\.\d{3}_report_\d{17}\.xml\z/

We pushed the changes, the CI pipeline passed, and we calmly tested in our test environment that the new job from v2 did not process the files for v1.

Approximately 4 hours after having deployed the hotfix, we deployed the new changes to production.

It was then that we started monitoring the scheduled jobs in both v1 and v2.

There we realized that since the deployment of the hotfix, no scheduled job from v1 had been processed again.

I'll tell you the reason later in part II. No spoilers here!

We ran a Rake task in our test environment that shows us the output of Sidekiq.get_schedule in v1:

{
  "bank_transfers_download_feedback_files_job": {
     "cron": "0 */5 * * * *",
     "class": "Jobs::BankTransfers::DownloadFeedbackFilesJob",
     "queue": "default"
  }
}

There was no doubt. The scheduler from v2 was overwriting the scheduler from v1.

graph TD;
    subgraph "Sidekiq Containers"
        V1[Payouts v1 Container];
        V2[Payouts v2 Container];
    end

    subgraph Redis[Shared Redis Instance]
        SharedNamespace("sidekiq_payouts" namespace);
    end

    V1 -- "Writes schedule to" --> SharedNamespace;
    V2 -- "OVERWRITES schedule in" --> SharedNamespace;

    style V2 fill:#f7baba,stroke:#c71f1f,stroke-width:2px

We thought then that we could schedule the job from v2 in v1, since we knew that the configuration for v1 had been working well until then:

# config/sidekiq_boot.rb

require "sidekiq"
require "sidekiq-scheduler"

require_relative "./boot"

# other logic omitted

Sidekiq.set_schedule(
  "bank_acknowledge_notification_job",
  {
    every: "3 minutes",
    class: "Jobs::BankAcknowledgedNotificationJob",
    queue: "high_priority"
  }
)

Sidekiq.set_schedule(
  "bank_transfers_download_feedback_files_job",
  {
    every: "5 minutes",
    class: "Jobs::BankTransfers::DownloadFeedbackFilesJob"
  }
)

SidekiqScheduler::Scheduler.instance.load_schedule!

Desperate times call for desperate measures.

We deleted all the configuration for Sidekiq Scheduler from v2 and tested that everything worked.

Note that I said the configuration. This is an important detail. More on that later.

To give some more context, when we merge the changes of an MR, they are first deployed to the staging environment. There we were able to check that everything was working as expected by scheduling all the jobs, both for v1 and v2.

We deployed the changes to production and requested in a support ticket to run the same Rake task that before, the one that shows the scheduled jobs.

We confirmed that the output of that task was showing all the scheduled jobs we expected.

That day we finished around 6 p.m. Not bad for a Friday afternoon.

As you may have imagined, this story does not end here.

Part II

For 10 days, we forgot about the scheduled Sidekiq jobs. There had been 6 deployments to production since that fateful Friday and everything had been working as expected. We had been lucky until then.

With the 7th deployment, which had nothing to do with Sidekiq jobs, our luck ran out.

The day after that deployment, we realized that none of the scheduled jobs had been processed since then.

We first checked what had been deployed to production since the last time we fixed it. Again, nothing related to Sidekiq jobs.

We found the following trace in our logs in production:

Removing schedule bank_acknowledge_notification

Removing schedule bank_transfers_download_feedback_files_job

We tried restarting the application in production without success. Same trace in the logs.

We had to deploy some changes to production that same morning, so we decided to wait and see if we got lucky again, although we were still trying to figure out the root of the problem. Again, no luck.

That afternoon, the team dedicated the refinement meeting we had scheduled to figuring out what was going on.

Although we had removed the configuration for Sidekiq Scheduler from the Sidekiq container from v2, we were still seeing the following trace in the logs:

Scheduling Info

We started the application locally and carefully checked the logs, filtering for references to "scheduler".

Finally, we found the problem in one of our dependencies:

begin
  require "sidekiq-scheduler"
rescue LoadError
  return
end

We had deleted the configuration from v2, but we had not removed the gem from the Gemfile in v2.

We deployed that change to production and checked that everything was working correctly.

We had found a race condition. We had been lucky from the beginning because the Sidekiq container from v1 had been starting after the Sidekiq container from v2.

The moment the Sidekiq container from v2 started after the Sidekiq container from v1, all scheduled jobs from v1 were removed, because v2 had no scheduled jobs.

Of course, we did not carefully read the gem's documentation, where we would have found the following recommendation:

If you're running multiple Sidekiq processes on the same Redis namespace with different configurations, you'll want to explicitly disable Sidekiq Scheduler for the other processes not responsible for the schedule. If you don't, the last booted Sidekiq processes' schedule will be what is stored in Redis.

RTFM!

And that is the reason why the scheduled jobs from v1 had stopped running when we had disabled Sidekiq Scheduler in v2 with the hotfix.

We also discovered that scheduling jobs from v2 in the Sidekiq container from v1 had worked by chance from the beginning.

The scheduled job from v2 did not have a explicitly defined queue, so it was being processed in the default queue. As that queue was not defined in the Sidekiq container from v1, by sharing the same Redis instance and the same namespace, that job had been processed in the Sidekiq container from v2.

Part III

During one of the tests that the stakeholders did in production of this new functionality, we received an alert in the corresponding Slack channel because an error had been registered during the process of downloading the feedback files from the bank.

We rushed to investigate it and found that the same file had been processed twice.

The first time the process had succeeded, so a record was created in the database with details of the downloaded feedback file, including the filename. The second time an error was registered, because we already had that record in the database for the same filename.

For now, it is registered as an error, although we should probably change it to a warning later.

Our first thought was that maybe the bank had mistakenly left us the same file on the SFTP server twice. However, that hypothesis did not add up because we only delete files from the SFTP server when the entire process succeeds, and the job is scheduled every 5 minutes, so we should have been registering the exact same error every 5 minutes.

Then we realized that the same file had been processed twice in a matter of 2 seconds.

Without finding an apparent reason for this to be happening, we assumed that the cause would be related to still having multiple Sidekiq containers sharing the same Redis namespace.

We already had a task on our board to explicitly add queues to jobs classes and scheduled jobs in v2, so we started from there.

The idea was to deploy it in two steps, doing the following:

1. Define the default queue in v1, so that any job from v2 that was already enqueued at the time of deployment could be successfully processed in v1.

bundle exec sidekiq -r ./config/sidekiq_boot.rb -q default,1 -q high_priority,6 -q medium_priority,3 -q low_priority,1 —concurrency 10

And explicitly specify in every job class in v2 in which queue should be processed:

bundle exec sidekiq -r ./config/sidekiq_boot.rb -C ./config/sidekiq.yml

In that configuration file, something like the following is specified:

# v2/config/sidekiq.yml
:concurrency: 10
:queues:
  - [v2_high_priority,6]
  - [v2_medium_priority,3]
  - [v2_low_priority,1]

In the job class, it is defined as follows:

# v2/app/jobs/bank_transfers/download_feedback_files_jobs.rb
require "sidekiq"

module Jobs
  module BankTransfers
    class DownloadFeedbackFilesJob
      include Sidekiq::Job

      sidekiq_options retry: false, queue: "v2_medium_priority"

      # other logic omitted
    end
  end
end

Note that when a job is scheduled from v1, a queue from v1 is used, while when the same job is processed in a non-scheduled way, a queue from v2 is used:

# config/sidekiq_boot.rb

# other logic omitted

Sidekiq.set_schedule(
  "bank_transfers_download_feedback_files_job",
  {
    every: "5 minutes",
    class: "Jobs::BankTransfers::DownloadFeedbackFilesJob",
    queue: "medium_priority"
  }
)

1. Delete the default queue from v1, now that all jobs run in a specific queue.

However, with this configuration, we encountered unexpected errors at that time when processing the scheduled job from v2 in v1:

NameError: Services::BankTransfers::DownloadBatchFiles::Dry

In our services, we use Dry::Monads to return Success or Failure, so it should be enough to add the following:

# v2/app/services/bank_transfers/download_feedback_files.rb
require "dry-monads"

Indeed, that error was already resolved, but one error after another kept appearing, in what seemed like an endless loop. With each require we added, a new dependency had to be specifically required. Some tests in v1 started to fail due to this problem.

The problem basically is that the v2 files are not autoloaded in v1 because it is not really necessary. In practice, they are independent applications, although we were taking advantage of the fact that both are in the same repository to process jobs from v2 in v1.

A possible solution for the dependency issue is the following:

bundle exec sidekiq -r ./config/sidekiq_boot.rb -r ./v2/config/sidekiq_boot.rb <...rest omitted>

Although that configuration did not solve the problem of the scheduled jobs running twice.

Finally, we opted for implementing another solution that the team had agreed on in another of the tasks that were on our board: Configure Sidekiq in payouts v1 and v2 to use different Redis namespaces.

We added sidekiq-scheduler to the Gemfile again in v2 and defined a different namespace for each application:

# v2/config/initializers/sidekiq.rb
require "sidekiq"

redis_config = {
  namespace: "v2_sidekiq_payouts",

  # other keys omitted
}

Sidekiq.configure_client do |config|
  config.redis = redis_config

  # other configurations omitted
end

Sidekiq.configure_server do |config|
  config.redis = redis_config

  # other configurations omitted
end

# v2/config/sidekiq_boot.rb
require "sidekiq"
require "sidekiq-scheduler"

require_relative "./boot"

# other logic omitted

Sidekiq.schedule = {
  "bank_transfers_download_feedback_files_job": {
    cron: "0 */5 * * * *",
    class: "Jobs::BankTransfers::DownloadFeedbackFilesJob",
    queue: "v2_medium_priority"
  }
}.freeze

Sidekiq::Scheduler.enabled = true

graph TD;
    subgraph "Sidekiq Containers"
        V1[Payouts v1 Container];
        V2[Payouts v2 Container];
    end

    subgraph Redis[Shared Redis Instance]
        direction LR
        V1_NS("sidekiq_payouts" namespace);
        V2_NS("v2_sidekiq_payouts" namespace);
    end

    V1 -- "Reads/Writes" --> V1_NS;
    V2 -- "Reads/Writes" --> V2_NS;

    style V1_NS fill:#d4edda,stroke:#155724,stroke-width:2px
    style V2_NS fill:#d4edda,stroke:#155724,stroke-width:2px

We also checked that the namespace change only affected Sidekiq. For example, the gem developed by the company to define feature flags uses Redis internally, but uses its own namespace.

We deployed these changes in our test environment and were able to verify that everything worked as expected. We deployed to staging and production and we got the same result.

With this configuration, each Sidekiq container is independent at the namespace level, although they still share Redis between them and with other applications.

We also managed to get the scheduled jobs to run only once.

Conclusion

We definitely learned the hard way how to configure Sidekiq properly according to our current needs.

It was not easy, it took us a lot of time, but we are happy with the result.

Some lessons learned:

• Better organize the structure of applications that share the same repository.

• Carefully read the documentation of the tools we use.

• Add alerts when a certain period passes without processing scheduled jobs.

• Test any change more exhaustively before uploading it to production.

• Do not share a Redis instance between multiple applications, especially the same namespace, because it can lead to unpredictable behavior.

Thank you for reading, and see you in the next one!

It is generally agreed that software engineers occupy a privileged position. This profession is not only highly in-demand but also offers a host of advantages rarely found elsewhere: competitive salaries, remote work, and flexible schedules, among others.

However, this privilege comes with a set of unrealistic expectations. A case of divine justice, you might say?

I recently came across an excellent post about the insanity of being a software engineer and felt compelled to expand on its insights.

Getting started is not easy at all, especially if you have no experience. I would say that it is difficult to find job offers for junior engineers, but in those rare cases where you do find them, it is common that companies ask for 2-3 years of experience. How can one get the experience if no one will provide the first opportunity?

Nowadays, you have bootcamps, for example, that have collaboration agreements with tech companies that give the student a chance to start an internship upon finishing, but they are not guaranteed to continue in the company once the internship is over.

That brings me to another key point. While it is probably nothing new, I feel that the hiring processes nowadays are wild.

Companies have unrealistic job requirements, often demanding an entire development team's worth of skills in a single candidate. It risks discouraging candidates who would otherwise be excellent fits but feel they do not tick enough boxes to apply.

But even when you decide to apply for a position, many candidates are rejected because interviewers fail to see that skills are transferable and the match should not be limited to a predefined checklist.

The way I see it, this situation is a consequence of the normalization that engineers must master (almost) all related areas. For instance, check the roadmaps for backend, frontend, full stack, or software architects.

For a typical backend position, you are expected to master the main programming language used in the project, but preferably you should master more than one, because that will give you the tools to apply different approaches depending on the occasion, especially if those languages allow you to apply different programming paradigms, such as OOP and functional.

Of course, you must be fluent with the entire ecosystem surrounding those languages, starting with the most popular frameworks, because they are the tool you will work with in your day-to-day.

You are also expected to master databases, at least one of the most popular SQL DBMS (PostgreSQL, MySQL) and some NoSQL (MongoDB, Redis). Performance tuning, data modeling, security... What happened to the role of the database administrator (DBA)?

Experience designing, implementing and consuming REST APIs or GraphQL is also a must.

Depending on your level, you must also be able to design efficient systems, always with performance, scalability, maintainability, and security in mind.

In a world dominated by (micro)services, you are also expected to know every architectural pattern, such as event-driven architecture (EDA).

You could think that is enough, right? Well, not quite...

You must know your way around the command line to be able to configure the system you are working on and ensure it is working nicely.

Do not forget about monitoring the system, responding to incidents caused by changes introduced to applications in your team's governance, and automating tasks to ensure the reliability of the system.

You are expected to be proficient with containers and cloud providers too, configuring and provisioning the infrastructure using code instead of manual processes and settings (IaC). Who needs SysAdmins, SREs, or DevOps anymore, right?

Do not forget about AI, which makes it increasingly common to find job offers asking for knowledge in LLMs, RAG, fine-tuning, or transformers, to name a few.

And all of that is without even getting into the full-stack role, where you will need to add frontend skills to the equation.

On the one hand, if the main workload is on the backend, you will not need to be an expert, but you will certainly have to know JS and the web ecosystem well enough.

On the other hand, if the entire project stack is based on JS, also working with Node on the backend, for example, then you will have to be an expert in the entire web and JS ecosystem in particular, whether it is frameworks, UI libraries, or other tools.

For sure, in a more purely frontend role, you are expected to be an excellent designer, have good taste for interfaces, and have solid knowledge of UX and usability.

And we are still just getting started, because I have not yet mentioned all the expertise required no matter the role.

You are required a high level of technical proficiency and a strong understanding of software development best practices, partaking in all stages of the development lifecycle, from initial task definition to final deployment.

Needless to say, your code must be clean, scalable, maintainable, and testable, preferably applying TDD. For that, you will need to master design patterns, refactoring techniques, and every software design principle ever coined, such as SOLID.

I really like what the author that somehow inspired this post says about it:

Software gets more complicated. All of this complexity is there for a reason. But what happened to specializing? When a house is being built, tons of people are involved: architects, civil engineers, plumbers, electricians, bricklayers, interior designers, roofers, surveyors, pavers, you name it. You don't expect a single person, or even a whole single company, to be able to do all of those.

Jack of all trades, master of none.

And there is still more, although it is not exclusive to this profession. You are expected to have not only a wide variety of hard skills but also a bunch of soft skills that would make you a solid candidate for "Employee of the Year".

You are expected to be a highly motivated team player with leadership skills; an excellent communicator with both technical and non-technical people; and possess proactivity, the ability to give and receive feedback, a capacity for self-management, abstract thinking, attention to detail, and adaptability to change, among many others.

Naturally, you should be someone with experience working in startups or fast-paced environments, with a business-driven, product-focused mindset, and be able to balance technical debt with delivering new features quickly.

Note that all those skills have been extracted from real job offers I have seen lately.

I love what I do, and the opportunity to constantly learn is one of the best parts of this job. However, I think the industry needs to move away from seeking mythical 10x engineers.

My suggestion is to not expect to hire a single person to do the work of an entire department, and rely on the candidates' ability to learn and adapt. Foster a culture that values deep expertise as much as broad knowledge to build stronger teams.

Thank you for reading and see you in the next one!

The way I see it, maintaining a blog requires discipline. Those who know me well know that discipline is one of my key strengths.

However, I never dared to take the leap before because several developer friends, whom I admire professionally, had tried and quickly fell by the wayside, usually after the first or second post. Why would I be any different?

I knew that if I were to start, I had to take it seriously. Two years later, I can say that, for now, I have achieved what I initially set out to do: publish at least one post per month.

It all started with a post where I talked about an error that caused Domestika application to lose access to AWS S3 in production for a few minutes.

Normally, I would have saved the solution to that error in an Evernote note, including a link to where I found it. I would also save that link as a bookmark. That was my modus operandi for many years.

Over the years, I rarely actually used those notes or bookmarks when I found myself in a similar situation. Typically, when in need of that information again, I had completely forgotten that I had noted it down or saved the bookmark. To be perfectly honest, it is very easy and convenient to perform a quick search and, in fact, I normally ended up on the same Stack Overflow thread where I had already found the solution before.

So why did I keep saving them? Old habits die hard.

My approach now, instead of saving that stuff in notes or bookmarks, is to write a post. Writing a post is completely different. There have been several occasions when I needed something I had previously written about, and I always come directly to the blog to see what I wrote instead of doing a quick search.

Do not get me wrong, I still save some notes with details that are not quite enough for a full blog post, but I do it much less than before.

An important decision was also which platform to host my blog on. I was pretty sure I preferred not to create a custom solution when very popular options already exist, especially for developers, like dev.to or Medium, which would likely also give me more visibility. However, when I researched the options a bit, I quickly opted for Hashnode. Without getting into too many comparisons, it is exactly what I was looking for: the ability to easily export my posts, write in Markdown, back up to a GitHub repository, add a custom domain, among many other things. Also, in my opinion, it is a platform with a much more attractive look and feel than other options. And, as if that were not enough, Hashnode has a public API that lets you interact with it.

Choosing the language to write in represented another important decision. Spanish is my mother tongue, thus it is the language where I feel most at ease. Furthermore, while Spanish content is growing, there is significantly less of it compared to English, presenting a chance for potentially greater impact on the Spanish-speaking community. Still, I knew the best path for me was writing in English, intending to improve my writing skills and aiming to become a better storyteller in that language.

The only post I have written in both languages so far is the one about my experience at Domestika. The reason was that some news had appeared in the press that, as far as I knew, were not entirely true and I wanted to avoid anything getting lost in translation.

Without a doubt, I still have room for improvement in that area, although I feel more comfortable over time. Sometimes, I still find myself writing the text in Spanish initially, as it comes more fluidly, before translating it into English. This approach, however, involves a considerably larger investment of time compared to writing directly in English.

On the one hand, I write for myself for the reasons I already explained, aiming to keep useful stuff accessible, functioning somewhat like a diary or logbook. While I was job hunting last year, every selection process involved questions about how I do certain things, projects I have worked on, or my experience in general. As time goes by, remembering specific details becomes harder, so I am sure having a post with lots of details will help me be more precise in future selection processes. That is also why I decided to write the series about my experience working for an American fintech as a contractor.

On the other hand, I like the idea of sharing knowledge. If it is useful for me, it might be useful for others too. I am aware I do not have a huge audience; only a few posts have had some impact (according to analytics), but I am proud that the post where I talk about how to learn Ruby was included in the Short Ruby Newsletter. Visits to that post increased considerably after that feature.

Maintaining a blog takes more time than I initially thought. When you have the chance to write about something you have done recently, it is usually quite straightforward, especially for purely technical posts. However, for various reasons, writing about what you do day-to-day is not always possible, either because I have not finished it by the time I want to write the next post or due to confidentiality. It is in those moments that I turn to a note I keep in Notion where I jot down ideas I think might be interesting.

Once I decide what I am going to write about, the next thing I do is make a list of points I want to include in the post. After that, it is time to shape all those ideas so they make narrative sense and are not just a jumble of loose thoughts. This is probably the phase that takes me the longest.

I usually write at the end of my workday, especially when I can finish earlier. I try not to spend more than a couple of hours each time, because I do not like spending the whole day in front of the computer.

In the future, I would like to write more purely technical posts, because I think those are the ones I enjoy writing the most, and at the same time, they are the ones I feel are most useful. Especially when it comes to writing about my approach to a certain topic or about a mistake made and what I learned from it.

And that is basically my process for maintaining this blog.

Thank you for reading and see you in the next one!

For obvious reasons, I will not share that message, but I would like to share some highlights:

• The revenue growth was slowed in 2024, so to keep growing the company must adapt.

• The company decided to restructure teams, and as a result, approximately 120 positions (both employees and contractor roles) will be eliminated globally, affecting around 10% of the organization.

• The company announced the acquisition of a leading software provided to the travel and hospitality industry for over $300M, further helping to diversify the business.

• All employees will receive an email stating whether their role was impacted by that restructure.

That day I started working later than usual and the first thing I noticed was a Slack message from my engineering manager (EM) asking me if I had received the email, although he mentioned the communication plan might differ for contractors.

However, some colleagues from SNGULAR unexpectedly received that email, informing them their role was not impacted. I will get back to this later.

This whole situation took everyone off guard, since it was a decision coming from the top management of the company in the USA. Not even our team managers knew about it, so they had no answers to give to all of us.

Tying all the loose ends, for a few weeks before the big announcement they had been gradually installing Kandji, an automation-forward Apple device management (MDM) software, to remotely control our laptops. That software works like a middleware even in the login process of the operating system, so if they remove your access to the project the laptop is basically useless.

In this case, SNGULAR knew nothing about it and even worse, my manager told us he was hiring people to join to this project. So weird.

An All Hands Engineering meeting was scheduled that same day, where the CTO of the company answered some of the questions that were sent anonymously. Not much was clarified at that meeting.

One of the items he did confirm though was that a dozen contractors would stop working on the project and that they were already deciding who would be affected.

Of course, not all contractors affected by the restructure are from SNGULAR, as the client collaborates with other consulting firms as well. But we did not know who nor how many of us would be affected.

The very same day the layoffs were announced, some colleagues from other areas of the company no longer had access to the project. In the engineering area, however not many people was affected, especially in the Transactional area, of which my team is part of.

According to what I later found out, there are several reasons why they could not do the same to everybody else affected by these layoffs, mainly due to the laws of each country:

• In Spain, the standard notice period for terminating an employment contract is 15 days, applicable to both employers and employees, but it is common for companies to terminate employees without prior notice, assuming a severance pay.

• In some cases, it was necessary to wait to remove the access to the project to workers in other time zones.

• In other cases, there was a consultation period.

• In the case of contractors, it depends on the notice period agreed with the consulting firm.

In our next 1 to 1 meeting, the EM confirmed that 2 or 3 people from SNGULAR would left the project, but they did not know who exactly yet. He also told me that I was among the top contractors in terms of performance and implied that he did not expect any changes concerning my position, but could not guarantee that I would not be affected. I felt somewhat relieved in that moment, although it was not yet confirmed.

A couple of weeks later, in my monthly 1 to 1 meeting with the manager from SNGULAR, he confirmed that two colleagues would left the project at the end of the month and they had already been notified. In that moment, he did not know if more people would be also affected.

Surprisingly, one of the colleagues who had received the email stating their role was not impacted, was one of the people affected. D'oh!

Since the notice period agreed upon with SNGULAR is 3 weeks, my colleagues are still working on the project, until the end of the month. Tough position for them.

Finally, a week later both managers confirmed that the budget for 2025 is set in the fintech company and no further changes are expected, barring a disaster. The EM also confirmed our team will stay the same during Q2.

Although the company's stock price fell by nearly 40% immediately following the release of their previous year's financial results and the announcement of the layoffs. Who knows what is yet to come.

Anyway, I must say that during those weeks, I was very concerned about my future, because I was hired specifically to work for this client and did not feel like working for another one, that would have been the worst case scenario for any of us.

Given the uncertainty, I seriously thought about starting to search for a new job, although I did not feel much like it either.

As I said in my previous post, working on this project is allowing me to learn a lot and I want to continue learning a lot more in the upcoming months.

After my experience at Domestika, going through something like this again is really unpleasant. Luckily, for the time being, it is over.

Thank you for reading, and see you in the next one!

I initially planned to write this post after my first three months, but I postponed it when we learned that all teams in the Transactional area would be reorganized at the start of the year.

This change took me by surprise. I knew that my team had been formed at the beginning of 2024 with members from other teams, but I did not realize this was something the company regularly does at the start of each year. The goal is to prevent knowledge from becoming siloed within specific teams.

This time, the teams were restructured based on the new architecture design, which was announced at the end of last year in an All Hands Engineering meeting. The goal is to complete it by 2027.

Given all this, I decided to wait until I had first impressions of the new team before writing about my experience. It has now been six months since I started working on this project and one month since the new team was formed.

Let me start from the beginning.

My first team

All the details about how that team worked can be found in my previous post.

Although it might sound like a cliché, I really felt like everyone on the team welcomed me with open arms.

For the first few weeks, I met every morning with my onboarding buddy, who explained how each application in the project works. We also spent part of the day pair programming on tasks she was working on.

Normally, I would spend the rest of the day completing tasks from the board that I had been assigned as part of the onboarding. I also spent several weeks configuring the macOS laptop they provided me.

During that time, I had no autonomy and often felt lost. I had no prior knowledge of the domain, and the project itself is quite complex, requiring many moving parts to come together. Still, my colleagues were incredibly patient and helped me as much as they could, especially when it came to testing tasks before moving them to "Ready for QA".

From the beginning, I noticed the team had been working together for several months because everything ran smoothly. Tasks arrived at refinements with enough detail, making it easy to decide what needed to be done.

I have to say that I integrated perfectly into their workflow. At first, I could barely participate in technical meetings, not due to a lack of technical knowledge, but because I lacked context and did not know the scope of certain changes. Over time, I gradually became more active in these meetings.

After applying several refactors and adding a couple of new features, I gained the trust of my teammates, who started to recognize how I could contribute and I quickly became a reference within the team when working with Ruby and applying best practices, as most of them had more experience with other programming languages. I always felt comfortable expressing my opinions and sharing ideas with them, even when we did not always agree. We would always reach a consensus for the good of the project. For example, I managed to add RuboCop to all projects under our governance.

For the most part of my career, I have been working with Rails, but I never had the chance to work with Sinatra before. I am enjoying learning a simpler and lighter framework, although sometimes it lacks certain useful features, such as many methods available in the Time class.

That being said, I have often missed having a well-defined company-wide standard so that all teams could follow certain guidelines ensuring we work similarly. I understand this is hard to achieve, but I think it would be great to work on a project this large and always know where to find things, how to name them, what to test, and how to do it. In short, I miss consistency.

Regarding security, this project is unlike any othe project I have worked on before. For example, in AWS, we only have read permissions, and we do not have access to the database console in production, which makes perfect sense. Because of this, we rely heavily on observability. Any data changes in production are done through Rake tasks, which must be requested via a support ticket.

We must also be extra careful during what they call "peak times", such as Black Friday and Christmas, because breaking something in production could mean certain transactions do not reach their destination on time, potentially involving millions of euros, dollars, or any other currency.

In fact, a couple of months ago, I developed a feature that had to be deployed to production and executed right before Christmas. Of course, things did not go as planned. As a result of running thousands of background jobs, response times for one of the most critical tables in one of the most essential applications skyrocketed. I plan to talk about it in a future post.

Thankfully, the issue only affected that table, but I felt terrible about it. The engineering manager (EM) was very supportive, telling me that these things happen and that we must learn from them to prevent them to happen again in the future. His words were a huge relief.

As for the rest of the teammates, I have a very good relationship with the two developers I worked with the most, who also live in Madrid. Before Christmas we met in person when another teammate came to town for a conference and I also attended the company's Christmas dinner, where I met several colleagues from other teams.

My new team

We started working together in mid-January.

The new team consists of an EM, a project manager (PM), a QA engineer, a tech lead and 5 software engineers, including myself.

I repeat in the team with the EM, the QA engineer and my onboarding buddy.

We follow the same agile ceremonies as before, but one major difference is that we do not have sprints. This is an unusual way of working for me, especially since we follow agile principles in almost every other aspect.

Our governance over the different applications in the project is different now, with a couple of exceptions, such as the payouts application that I have mentioned in other posts.

All team members currently live in Spain, so we usually have our daily meetings in the morning and scheduled meetings still happen in the afternoon, such as refinements.

Interestingly, almost half the team works as contractors through SNGULAR.

A role we did not have in my previous team is the tech lead. He has been at the company the longest and ensures everyone understands the overview and implications of new features to guarantee everything fits together correctly.

During the first few days, he organized several workshops to explain the so-called "transactional registry", which is a crucial component of the new architecture.

We also had several mob programming sessions where we started developing together the first functionality in that application.

I will not go into much detail about what that service does, but I should mention that its governance belongs to another team. As I mentioned in another post, that ownership is not strict, as any developer can make changes to any application. Out of courtesy, the team with governance over each application is tagged.

Even though that other team shares with us the EM and the PM, and the tech lead often collaborates with them, we have encountered in a month several occasions where both teams have worked on similar functionality, because of a lack of proper communication.

For example, I recently worked on a feature that made certain attributes of an event optional, including them in the payload only if those attributes in the original event published in another application had led to a change in the corresponding object of our application. Normally, such change would involve changing the version of the event, but since no one was consuming the event yet, we decided in the refinement not to change it. However, by the time the feature was developed, reviewed, and tested by QA team, a couple of weeks had passed. When I deployed the changes to production, we suddenly started to see errors in a third application related to that event I had modified.

How was that possible if no one was consuming that event? In the time between our refinement and the deployment to production, another team had created a new event handler in that third application. Fortunately, it was only logging some information, so there was no real impact. This is an example of the lack of communication I mentioned earlier.

We clearly have room for improvement in terms of task planning. However, given that we are a newly formed team, it is understandable that these things happen.

That said, our timeline is tight. Ideally, we should complete several key components of the new architecture in Q1. The team was formed with that goal in mind.

The EM mentioned that it is likely the team will stay the same during Q2, but beyond that, no one knows what teams there will be or who will be part of each team.

For sure there is a good atmosphere in the team, but we have different points of view on key aspects of our work. This goes beyond just how we write and organize code.

Most of us prefer tasks to be as detailed as possible before refinement, while the tech lead prefers the opposite. I assume we will end up somewhere in between, especially since some of us lack context on the applications we are working with, making it difficult to move forward without enough details.

Our refinements are taking much longer than usual. We have scheduled a weekly 1-hour refinement, but we have often extended it for several hours or even continue the next day.

In some cases, a refinement has even resulted in re-refining some tasks already started because we totally changed the way we want to approach it. That situation is not sustainable over time and, of course, is an issue that we discussed in our first retrospective meeting.

Everybody in the team respect and follow the tech lead's vision, but right now it is creating a bottleneck, especially regarding how we want to implement certain details of the code. When in doubt, he is obviously the go-to guy.

In the same way we must find our sweetspot, being able to identify where we can be more or less demanding, thus generating some technical debt if necessary.

I have to admit that on a day-to-day basis we do not really feel pressure at all, but being a new team, it is noticeable that we all want to deliver and sometimes we have not paid enough attention to the whole software quality process and because of that we have had some unnecessary and relatively important bugs in production.

During a 1-to-1 meeting, the EM told me that if I ever feel any kind of pressure, I should let him know so we can handle it properly.

However I have noticed that even though we all discuss the progress in our tasks during the daily meeting, the EM sometimes asks me in private about the progress in certain tasks. In some cases, he even have moved a task to a different column on the board before I do.

Even though he tries not to rush us, I get the feeling that he is under pressure from his own manager to ensure we deliver the expected features on time.

On top of that, security restrictions cause additional delays in delivery. For example, to take a new application to production, we must first complete an initial use case and review it with the security team. Once they validate that first use case, the new application becomes available for deployment, and we can then proceed normally with new use cases.

Finally, as for me, I have to admit that my attention is somewhat divided because I am still working on a task related to the production incident I mentioned earlier. As I said before, I hope to talk about it soon.

These first six months have flown by, and I have to say that not everything has been easy for me. However, the teams I have been part of have done their best to make me feel like one of them, even though I am a contractor.

This is by far the most complex project I have worked on. Many times, I have felt lost, but I never hesitated to ask for help, and the team was always there when I needed it.

It is a system where multiple applications interact, meaning a lot of things can go wrong. Moreover, this company operates in a completely different way than what I was used to in other projects, as production has far more security constraints than usual. And it makes sense, after all, we are constantly dealing with money, one way or another.

Just when I was starting to get into the rhythm of my first team, to better understand our processes and how our governance applications were connected, we had to split up.

I was really sad when I found out we would not be working together anymore. When I came back from the Christmas break, the team no longer existed. And unfortunately, it seems pretty likely that the same thing will happen again in the next few months.

On the other hand, I am happy because it is a technical challenge that is allowing me to learn a lot about the fintech world. That was one of my goals when I started looking for a new job last year.

Right now, it is a matter of being patient, as the beginning is always difficult for everyone. Hopefully, we will find our rhythm soon, and everything will start falling into place.

Thank you for reading, and see you in the next one!

15 years later, I work at SNGULAR, which is a consulting firm that mostly works with Java and its ecosystem in the backend of their software development projects. They also have projects with popular languages such as PHP or Node.js, among others. Focusing exclusively on what they call the Backend chapter, each of these technologies has an internal learning path defined. This is not the case with Ruby, since they do not have many projects where this is the main programming language.

When I started working at this company I was already assigned to a project, but as I already had booked my vacations, my start at the American fintech was delayed for a few weeks until I was back.

I had several weeks ahead of me before leaving, so in addition to completing my onboarding, my boss proposed to do a Ruby training to some colleagues who did not have a project assigned at the time. All of them were experienced developers who were used to work mainly with Java or PHP, but had no previous experience with Ruby. I accepted without hesitation.

You will find below the guide I shared with the company to learn Ruby, to which I have been adding some stuff that I consider interesting during the last months.

Ruby Training

Recommendations

The most important recommendation is always learn Ruby first and then learn the framework of your choice if needed, usually the most popular. This is applicable to any ecosystem. That way, when you work on a gem, a script or anything else where you do not have available any of the libraries provided by the framework, you will be able to work with Ruby pretty easily.

Even if you already have experience with this language, I recommend you to access this quiz and you will probably understand what I mean.

Another recommendation that I consider important is that you look at the version of Ruby used in the articles and documentation that you find, because some things might be outdated. On the official website you will always find news about the latest versions released.

Documentation

• Ruby documentation

• Ruby API

• Ruby from other languages

• The Ruby Reference

• Learn Ruby

References in the community

Not an exhaustive list and in no particular order:

• Yukihiro Matsumoto "Matz"

• Sandi Metz

• Janko Marohnić

• Nate Berkopec

• Avdi Grimm

• Katrina Owen

• Aaron Patterson

• Mike Perham

• Akira Matsuda

• Rafael França

• DHH

• Thoughtbot

• Evil Martians

• Shopify Engineering

• GitHub

Key concepts

Going beyond the most basic concepts present in every programming language we can find the following concepts:

• Global Interpreter Lock (GIL):

  • Concurrency vs parallelism

  • Threads vs Fibers vs Ractors

• YJIT:

  • Ruby is an interpreted language

  • The JIT allows to dynamically compile Ruby code into machine code at runtime without interpretation

  • Improve performance and memory usage

• Types:

  • Duck typing vs is_a?/kind_of? vs instance_of?

  • There are no interfaces

  • Type checkers:

    • Not very extended in the Ruby community

    • Sorbet

    • RBS

• Debugging:

  • <object>.methods.sort: what methods an object respond to.

  • <object>.method(:<method_name>).source_location: where is defined a certain method.

  • <object>.method(:<method_name>).super_method.source_location: where is defined certain method with the same name in one of the ancestors.

• Metaprogramming:

  • define_method

  • Always define respond_to_missing? when overriding method_missing

  • send vs public_send

  • Monkeypatching

• Exceptions:

  • The class hierarchy

• Pattern matching

• Shorthand hash syntax

• Safe navigation operator (&)

• Strings (to_s) vs symbols (to_sym):

  • Frozen strings

• Classes vs modules

• Lambdas vs procs vs blocks

• Memoization:

  • Beware booleans

• Logical operators:

  • and vs &&

  • or vs ||

  • not vs !

• Namespaces

• Inheritance

• Constants lookup

• super

• self

• Attribute macros:

  • attr_reader vs attr_writer vs attr_accessor

• Variables:

  • local vs global vs instance variables vs class instance variables vs class variables

• Methods:

  • Visibility: public vs protected vs private

  • Endless

• Ranges:

  • Beginless and endless

• Regular expressions:

  • Rubular Playground

• Documentation:

  • YARD

Frameworks

• Ruby on Rails:

  • Documentation

  • Guides

  • The Rails Doctrine

• Hanami:

  • Documentation

  • Guides

• Sinatra:

  • Documentation

• Padrino:

  • Documentation

  • Guides

• BrutRB:

  • Documentation

Testing

• Frameworks:

  • Minitest (default):

    • Documentation

    • Learn how to write tests with Minitest

  • RSpec:

    • Documentation

    • Blog

  • Cucumber:

    • Documentation

    • Learn BDD and Cucumber

    • Blog

• Articles:

  • Testing Ruby for beginners

  • The Case for WET Tests

  • Mystery Guest

  • Testing Objects with a Functional Mindset

  • Four-Phase Test

  • Write Reliable, Asynchronous Integration Tests With Capybara

  • Thoughtbot (lots of articles)

Interpreters

• Matz's Ruby Interpreter a.k.a. Ruby MRI a.k.a. CRuby

• JRuby

• Others

Installation

• In a real project, whenever possible, it is recommended to use Docker containers.

• Version managers:

  • RVM

    • .ruby-version (include in the version control)

    • .ruby-gemset (do not include in the version control: Add to .gitignore)

  • asdf

  • rbenv

  • chruby

• GoRails setup

Editors and IDEs

You will find plugins for Ruby in any editor/IDE.

• RubyMine: the best integration

• VSCode

  • Add a language server protocol (LSP):

    • Ruby LSP

    • Extension

Linters

• RuboCop

  • How to start using a linter in a legacy project

• Standard

• Brakeman

• Reek

Style guides

• Ruby

• Rails

• RSpec

• Ruby in Style

Playgrounds

• Try Ruby

• Ruby Playground

• Ruby Next Playground

• RunRuby.dev

Courses

The company provide us with access to the courses catalog available on Udemy.

Some interesting courses to start learning Ruby and Rails:

• Learn to Code with Ruby

• Testing Ruby with RSpec

• The Complete Ruby on Rails Developer Course

• How To Build Instagram Clone Using Ruby on Rails 7

Not yet available for us, but hopefully will be soon:

• Ruby on Types: Static Typing with Ruby and Ruby on Rails

Other courses:

• RubyCademy

• The Odin Project: Full Stack Ruby on Rails:

  • Ruby

  • Rails

Videos

• Ruby conferences

• Upcase

• Drifting Ruby

• GoRails

• Railscasts (outdated)

Books

• The Pragmatic Bookshelf: lots of books could be outdated

  • Programming Ruby 3.3

  • Agile Web Development with Rails 7

• Practical Object-Oriented Design: An Agile Primer Using Ruby (POODR)

• 99 Bottles of OOP

• Ruby Science

• Painless Rails

• The Complete Guide to Rails Performance

• Testing Rails

Newsletters

• Ruby Weekly

• Short Ruby

• Ruby Central

Exercises and katas

• Exercism

• Codewars

• Leetcode

Interesting websites and articles

• PHP to Ruby

• RubyGuides

• Design Patterns: every pattern includes examples in Ruby

• GoRails guides

• Rails hurts

• Upgrow: A Better Architecture:

  • Proposed by Shopify and somehow inspired by DDD

  • Bear in mind that this is not a usual approach in a Rails project

• How to train senior developers in Ruby on Rails

• GitLab: Why we're sticking with Ruby on Rails

• Writing Less Error-Prone Code

Useful and popular gems

• RubyGems: Find, install, and publish Ruby gems

• Awesome Ruby: A collection of awesome Ruby gems, tools, frameworks and software

• The Ruby Toolbox: Find actively maintained & popular open source software libraries for the Ruby programming language

Some gems are available for any Ruby project and others are only available for Rails:

• Testing:

  • RSpec

  • Minitest

  • Cucumber

  • FactoryBot

  • Capybara

  • VCR

  • RSwag/rspec-swag

  • Webmock

  • Faker

  • database-cleaner

• Next generation:

  • dry (dependency injection, types, schemas, validations, monads, ...)

• Web servers:

  • Rack (Interface)

• Application servers:

  • puma

  • passenger

• CORS:

  • rack-cors

• Databases:

  • PostgreSQL

  • MySQL

  • MongoDB

  • Redis

• Migrations:

  • Strong migrations

• Bulk imports:

  • ActiveRecord Import

• Cloud:

  • AWS

  • GCP

  • Azure (no longer maintained)

• Background jobs:

  • Sidekiq

  • Resque

  • Delayed Jobs

• Events:

  • Bunny (RabbitMQ)

  • Kicks (RabbitMQ)

  • Karafka: (Kafka)

• Cron:

  • whenever

  • rufus-scheduler

  • Sidekiq Cron

  • sidekiq-scheduler

  • resque-scheduler

• WebSocket:

  • AnyCable

• Uploads:

  • Shrine

  • Carrierwave

• Caching:

  • Dalli (Memcached)

• Full text search:

  • Elasticsearch

  • OpenSearch

  • Algolia

• HTTP client:

  • Faraday

  • httparty

• APIs:

  • GraphQL

  • JSON:API serializer

  • ActiveModel serializers

  • JWT

• Deployment:

  • Capistrano

• Geocoding:

  • Geocoder

• Feature flags:

  • Flipper

• Authentication:

  • Devise

  • Doorkeeper

  • Omniauth: Standardized Multi-Provider Authentication

  • Clearance

• Authorization:

  • Pundit

  • CanCanCan

  • ActionPolicy

• Mobile:

  • Hotwire Native: Android/iOS

• Templates:

  • ERB

  • Haml

  • Slim

• Assets:

  • Sass

  • Tailwind

  • Bootstrap

  • React

  • htmx

• Interactivity:

  • Stimulus

  • Turbo

• Views:

  • View Component

• Forms:

  • Simple Form

• Pagination:

  • Kaminari

  • will_paginate

  • pagy

• State machines:

  • State Machines

  • AASM

• Videos:

  • m3u8

• Money:

  • money

• Audit changes:

  • audited

• Dependency updates:

  • Renovate

Community

Last but not least, get involved in the community the way you prefer. Follow people in social networks, read as much as you can about the language, its frameworks and tools, and even collaborate in open source projects if you feel like it.

In your city probably there is a Ruby group that gathers from time to time, usually monthly, to talk about the language and related stuff. For instance, in Madrid, where I am currently living, we have Madrid.rb.

Recently, I found RubyFriends, an app that allows people to reconnect after a conference. A great idea!

That training for me was an enriching experience that took about 4 weeks. My colleagues approached the training as a challenge and at all times I felt that they were really interested in learning the language and its ecosystem, and that they wanted to put into practice what they were learning.

My boss told me that they were very happy with the training and I can confirm the guide I created will be used for future trainings at SNGULAR.

I would also like to take this opportunity to thank my mentor, Eddy Josafat, for coming up with the brilliant idea of using this language in which he saw a promising future. He was not wrong.

By the way, this is a list that I will keep updating over time. Is there anything you miss in this list? If so, leave it in the comments, please.

Thank you for reading and see you in the next one!