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:

# 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 a paid feature, too:

  

• 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:

  

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

  

  

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 offer 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 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 and :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 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 with 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!

In the case of my team, part of our focus so far has been on the new payouts application that I also mentioned in another post, which allows us to automate certain payments.

In that application, Sequel provides the ORM layer for mapping database records to Ruby objects. We do not use models like in Rails inheriting from ActiveRecord, but entities that inherit from the Data class, added to the Ruby core in version 3.2.

BankAccount < Data.define(:account_code, :bank, :currency_code, :country)

When I joined the team, we used factories in tests with FactoryBot:

FactoryBot.define do
  factory :bank_account, class: BankAccount do
    account_code { "CITI-00000001-USD" }
    bank { "citibank" }
    currency_code { "USD" }
    country { "US" }
  end
end

However, those factories were only used to generate instances of the entities:

bank_account = FactoryBot.build(:bank_account, account_code: "CITI-00000001-EUR", currency_code: "EUR", country: "ES")

I was quite surprised that those factories were not used to create the necessary records in the database for every single test example.

The records were defined with the required values in a module:

module Test
  module Helpers
    module BankAccountStorage
      def seed_bank_account_storage
        Database.connection do |db|
          db[:bank_accounts].insert(account_code: "CITI-123456789-USD", bank: "citibank", currency_code: "USD", country: "US")
          db[:bank_accounts].insert(account_code: "CITI-123456789-EUR", bank: "citibank", currency_code: "EUR", country: "ES")
          db[:bank_accounts].insert(account_code: "CITI-123456789-GBP", bank: "citibank", currency_code: "GBP", country: "GB")
          # ...more records...
        end
      end
    end
  end
end

Database.connection is just a custom wrapper around a Sequel connection.

The module was then included in the corresponding test file:

require "spec_helper"
require_relative "../test/helpers/bank_account_storage"

describe "POST /payments/initiate" do
  include Test::Helpers::BankAccountStorage

  before do
    seed_bank_account_storage
  end

  context "when paying in USD" do
  # ...

The way I see it, doing that is not maintainable and would not scale well, for several reasons:

• We are generating more records than needed for each example. Therefore, each test is slower than necessary.

• We do not have control over the attributes of each of the records created.

• We are adding indirection within each test file where that module is used, because we are asserting over values that are not defined neither in the test example nor in the test file itself.

I would even prefer to use fixtures rather than keep creating records that way, but only if I knew that the code would never change. And we all know that rarely happens.

When it was my turn to refactor a part of that application, I decided it was time to change that approach as a previous step to introducing new changes.

Of course, the first step was to delete those modules and start persisting records in the database with FactoryBot:

bank_account = FactoryBot.create(account_code: "CITI-123456789-USD", bank: "citibank", currency_code: "USD", country: "US")

However, when I ran the test suite, I found errors like the following:

Failure/Error: bank_account = FactoryBot.create(account_code: "CITI-123456789-USD", bank: "citibank", currency_code: "USD", country: "US")

NoMethodError:
undefined method `save!' for an instance of BankAccount
# /usr/local/bundle/gems/factory_bot-6.4.6/lib/factory_bot/evaluation.rb:15:in `create'
# /usr/local/bundle/gems/factory_bot-6.4.6/lib/factory_bot/strategy/create.rb:12:in `block in result'
# /usr/local/bundle/gems/factory_bot-6.4.6/lib/factory_bot/strategy/create.rb:9:in `result'
# /usr/local/bundle/gems/factory_bot-6.4.6/lib/factory_bot/factory.rb:43:in `run'
# /usr/local/bundle/gems/factory_bot-6.4.6/lib/factory_bot/factory_runner.rb:29:in `block in run'
# /usr/local/bundle/gems/factory_bot-6.4.6/lib/factory_bot/factory_runner.rb:28:in `run'
# /usr/local/bundle/gems/factory_bot-6.4.6/lib/factory_bot/strategy_syntax_method_registrar.rb:28:in `block in define_singular_strategy_method'
# ...

Of course, I have always used FactoryBot in Rails applications where each factory is associated with models inheriting from ActiveRecord.

Our entities do not implement the save! method, which is the default implementation of the to_create method:

to_create { |obj, context| obj.save! }

Therefore, I had to override that behavior for all our factories.

In this case, I did it in the FactoryBot support file:

require "factory_bot"

RSpec.configure do |config|
  config.before(:suite) do
    FactoryBot.find_definitions
    FactoryBot.define do
      initialize_with { new(**attributes) }

      to_create do |obj, context|
        Database.connection do |db|
          if !context.respond_to?(:table_name)
            raise NotImplementedError,
              "define a transient table_name attribute inside the factory with the name of the database table"
          end

          db[context.table_name.to_sym].insert(obj.to_h)
        end
      end
    end
  end
end

In the factory we define the transient attribute table_name:

FactoryBot.define do
  factory :bank_account, class: BankAccount do
    transient do
      table_name { BankAccountRepository::TABLE_NAME }
    end

    account_code { "CITI-00000001-USD" }
    bank { "citibank" }
    currency_code { "USD" }
    country { "US" }
  end
end

Since it is related to persistence, I decided to define the constant with the name of the table in the corresponding repository:

class BankAccountRepository
  TABLE_NAME = :bank_accounts
  # ...

And that is all. With those simple changes we already have at our disposal all the power that FactoryBot.create offers.

It is important that the error message that would appear in case of using the create strategy without having the transient attribute table_name defined, allow anyone to fix that error very quickly.

I must say that the team welcomed the new changes with open arms.

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

Before the start

Before I started I had to go through a background screening process with their provider, Orange Tree. That process took several weeks but finally they gave the green light.

A couple of days before starting, I received an email in my personal email account with details for configuring the laptop received a few days before. Of course, it was a macOS laptop. If you are a contractor, you do not get a new laptop.

Onboarding

The first day was very simple. I joined a call with the IT people along with other people starting at the company that very same day as well so they can install the software that is able to remotely control our computers if needed. According to the IT people, you need to explicitly give permissions before they are able to do anything in the computer.

After that, I met with the engineering manager to tell me about how the project works, how it is organized, what are the responsibilities of the team and how the onboarding would be, among other stuff.

Then I was assigned a board with a series of tasks that I had to complete during the onboarding, like meeting people from different teams, roles and hierarchy levels in the company; reading documentation, completing the first task, doing a code review or deploying to production.

That first day I was already present at the daily meeting so I could meet my new teammates.

The next day I joined my onboarding buddy to set up the various applications we work on and to tell me what the day-to-day work is like. We spent a big part of my first few weeks doing pair programming.

The onboarding was completed in just over a month.

The company

The headquarters of the company are in Boston.

The company has around 1,300 employees around the world, although most of the engineering team is based in Spain.

They recently announced that around 3% of the workforce would be affected by lay offs, with the engineering team not being affected at all right now.

Communication within the company is always in English, unless everyone present at a meeting speaks Spanish (or any other language).

At the company level there are some recurring meetings:

• All Company: a 1-hour to 1.5-hour meeting where the CEO and other senior managers of the company tell how the business is doing and upcoming objectives. It is held once a month.
• All Hands Engineering: very similar to All Company meeting, but only for members of the engineering area. Here they mainly talk about changes already implemented in the different teams and upcoming projects or changes that we are about to implement. It is held once a month.

Everybody is required to log however many hours they are required to work each week, included contractors like me.

The project

In the engineering area there are multiple teams, each with governance over multiple applications.

However, this is not a strict ownership, because any developer can add or modify code in any of the repositories they have access to, as long as the owner team is tagged in the MR so that they can review it as well.

Such a review is usually optional, unless any of the changed files are included in the CODEOWNERS file.

Unfortunately, there is no standard way to do anything in the engineering team. In the documentation I had to read as part of the onboarding I found a style guide with details on how to write code, but in practice I can confirm that that style guide is not being followed by any of the existing teams.

That means that it is very likely that when we change code owned by other team we will have to do things differently than we would do it in our own code. My house, my rules!

In a daily basis, we work with money in one way or another, so security is critical. The company must comply with certain regulations, standards and laws, including anti-money laundering (AML), fraud prevention, and know your customer (KYC) procedures.

Periodically we must complete courses related to these topics to stay up to date.

Therefore, access to production applications, databases or console is totally restricted for developers.

Observability in cases like this is essential, so we make extensive use of logs with tools like Honeycomb and Sumo Logic, generating those logs through an internal gem that provides an OpenTelemetry wrapper.

The error tracking of all applications is done with Sentry.

Sometimes, due to an error or simply because we need to apply a change or enable a feature flag in production, we have to open a support ticket on Jira so that the support team can take care of it, usually by executing a Rake task.

Access to all applications is handled by Okta, usually allowing to authenticate with biometrics (e.g. fingerprint). For certain applications, 2-factor authentication (2FA) is required, especially for those that are only accessible through a VPN.

At the code level, security is also taken into account, since the CI pipeline executes a step in each repository that checks for vulnerabilities either in our own code or in third-party code. At the moment it only shows warnings with all the vulnerabilities found, but soon it will cause our pipelines to fail.

In addition to the applications already mentioned, we work in a daily basis with the following applications:

• Google Suite (GMail, Drive, Meet, Presentations, Spreadsheets, Docs).
• Confluence → Documentation.
• Jira → Project tracking and support
• Slack → Instant messaging.
• GitLab → Coding and CI/CD.
• Postman → API development.

The SRE team has created a series of internal tools that integrate into our daily work in a very simple way:

• A tool similar to Kubernetes that allows us to automate deployments, scaling and manage applications with containers.

  They have everything perfectly organized to generate CI/CD pipelines with IaC, in each of the environments we have available to test our applications, before promoting the code to production.

• A CLI tool similar to AWS CLI that allows to execute commands in those pre-production environments, simply by specifying the environment, the application and the command to be executed.

• A tool that allows to manage the creation, modification and deletion of records of any of the entities of our domain in pre-production environments. It works as a test factory, generating any type of dependency that may be necessary along the way. This tool replaces a Slack bot that has been used until now and that will be deprecated soon.

At the engineering team level there are some recurring meetings:

• Dev Learning: a 15-minute to 1-hour meeting where one of our colleagues talks about a technical topic. It is held every Friday.
• Game Days: a 1.5-hour meeting where first every team shares their post-mortems since the previous meeting, and later we are presented with a series of exercises prepared by other members of the engineering team for us to solve, organized in groups and with time constraints. The challenges usually must be solved without using the tools mentioned above. It is held once a month.

We have dozens of internal gems hosted on Buildkite Package Registries (formerly Packagecloud). Some examples of those gems, in addition to the OpenTelemetry wrapper mentioned above, allow us to integrate with banks we work with, such as Citibank or Bank of America. Among other things, it allows us to test new changes directly against their sandbox before releasing a new version of the gem.

My team

It consists of an engineering manager (EM), a project manager (PM), a QA engineer and 4 software engineers, including myself. Everybody is based in Spain, except for one teammate who lives in Canada.

We have a flexible schedule. The only requirements are getting the job done and attending team meetings.

The team belongs to the Transactional vertical and is in charge of managing funds collection and payouts to many countries and in many currencies.

It is pretty common that we add new payment corridors, which is simply adding support for payments to specific countries in one or more currencies if we do not already have it in place.

Probably the automatic matching of received transactions and expected payments, either debits or credits, is the most important function we have, thus relieving the manual work of the operators who deal with all those transactions.

Some of the clients we work with are Citibank, Bank of America, J.P. Morgan, Deutsche Bank or Cross River Bank.

Most of our applications are pure backend applications, although we also have one SPA developed with React. At the moment, only one of my teammates works with that application in case adding a new feature or fixing a bug is needed.

Regarding our backend applications, they are microservices developed in Ruby with Sinatra. As far as I know, most people in this company are not fans of Rails.

The gems we develop are of course developed in pure Ruby as well.

We have an event-driven architecture (EDA) in place, where the communication between microservices is usually asynchronous with events published to and consumed from RabbitMQ.

Depending on the application, we also expose and consume data from REST APIs endpoints whose response is formatted in JSON.

Each application has its own technology stack, but it is common to work with Docker, docker compose, AWS, Dry gems, MySQL, Elasticsearch and Redis, among others.

As I mentioned previously at the company level, the team did not follow a style guide for writing code when I joined. I am currently in the process of adding RuboCop as a linter to all applications of our governance.

In the same way, the way applications are tested is quite diverse, so I am trying to define a style guide for that as well. In the newest application we have developed I was already able to implement a new testing approach successfully, but I am aware that it will not be that easy to do it for the rest, among other things, because I find some resistance to change from the team.

Either way, what is common is that we use RSpec as a testing framework and FactoryBot as a tool to create database records in our test suite. I also introduced rspec-swag, a rswag fork that can be used with any Rack-compatible framework, to test our APIs and automatically generate the documentation of our endpoints with Swagger, in compliance with the OpenAPI specification.

We follow an agile methodology, more similar to Kanban than to Scrum, to develop our applications.

In the sprint board we have different rows, which represent each of the team's priorities. These priorities vary in each sprint, which lasts 2 weeks.

Regarding the development cycle, our sprint board has the following columns:

• To Do: A task is created and is ready to be refined.
• Ready for Dev (Selected for Development): A task is already refined and has been included in the current sprint.
• In Dev: A developer is currently working on a task or the MR is already created and they are checking that it works as expected in one of the pre-production environments.
• Ready for QA: The developer finished working on a task and the CI pipeline must pass before moving on. The developer checked in one of the pre-production environments that everything works as expected and documented all their tests, with details about the commands executed or screenshots if necessary, so the QA engineer can validate them and add their own tests. At this point having the MR approved is not a requirement.
• In QA Review: The QA engineer is validating the tests made by the developer and adding their owns tests.
• QA Complete: The QA engineer successfully finished testing the task and it is now ready to be deployed. At this point the MR must be approved by at least 2 repository owners before being merged.
• Deployed: The MR was merged and the code deployed to production. The developer could wait until they confirm no errors are raised related to the changes deployed or a Rake task finishes its execution.
• Closed: There is nothing left to do regarding the task.

And the workflow is as follows:

Each developer is responsible for moving their tasks around the sprint board, except when the task is in one of the QA-related columns.

At the team level there are some recurring meetings:

• Daily: a 15-minute meeting where each member of the team explains what they have been working on since the previous day and what they will continue working on. In case anything is blocking us, we mention it here as well. Some members of the support team usually join us a couple of days each week. At the end of their turn, each person nominates the next person who should speak.
• Refinement: a 30-minute to 1-hour meeting from a product point of view, where any doubts the team may have about certain tasks are solved. The "definition of done" is defined here, but without going into technical details. Tasks are rarely estimated, except when we want to know from the beginning if all of us think the task should be divided into multiple tasks or not. We use the Fibonacci sequence, between 3 and 13 points, where 3 points represents 1 day of work approximately. It is held once in each sprint.
• Split: a 1-hour meeting from a technical point of view, where we solve any doubts the team may have about how to implement certain changes and we write it down in the task itself. If necessary, we create a spike and discuss it again in a later meeting. This is held once in each sprint.
• Code Review: a 1-hour meeting where we review the concerns board, where each team member can add their concerns to solve technical debt. In each task we can define what we are concerned about and the solution we propose to solve it. This is held once in each sprint.
• Sprint Planning: a 30-minute meeting where the PM checks the unfinished tasks from the previous sprint and prioritizes the tasks to be included in the next sprint. The previous team's velocity is not taken into account, but the team's opinion is taken into account when it comes to include a task in the sprint or not. It is held on the first Monday of each sprint.
• Retrospective: a 1.5-hour meeting where each team member can add a list of things they think went well and what things we can improve since the previous retrospective, although we usually only talk about what did not go so well. Then everyone chooses the 3 topics that interest them the most and we spend the rest of the session trying to find possible solutions to the 3 most upvoted topics. A person is assigned to follow up on each of those topics. The meeting is lead by a facilitator from another team. Normally this is held once a month, although it sometimes takes longer.
• Game Days: a 30-minute meeting where the whole team spends time together, bonding with each other. We usually play online Pictionary or games like that. It is held on the second Monday of each sprint.
• 1 to 1: a 30-minute meeting with each permanent full-time worker or a 15-minute meeting with each contractor with the EM to talk and periodically check on how things are going on both sides.
• Coffee Chat: a 15-minute meeting before the daily meeting on Fridays where we usually talk about our plans for the weekend.

As you can see, we do not have sprint review or sprint retrospective.

Finally, on rotating basis, each week a developer of the team is the minion.

The highest priority of that person during that week is to help resolve support tickets that have been assigned to the team. If the solution is simple, they can create a task and implement the changes directly. If the solution is a bit more complex, they can create a new task and share it with the rest of the team to give more visibility. If it is urgent, that task is added directly to the sprint board.

In addition, the minion shares their screen with the sprint board on the daily meeting and takes notes in technical meetings.

The minion also has a dedicated row on the sprint board with tasks related to support tickets or technical debt tasks that are created from a concern.

Conclusion

There was a lot more to tell than I had initially thought. In many ways I am sure this American fintech works very similarly to any other company you know or have worked for. Still, I think it is interesting to share how they work and how they are organized, but keeping the company name anonymous, for obvious reasons.

I hope to talk about my experience working with them soon. So stay tuned if you are interested.

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

The platform of this American fintech consists of many applications developed in multiple programming languages, but mainly in Ruby. There are several development teams, each with governance over different parts of the project. As you can imagine, over more than a decade literally several hundred developers have worked on the project and each and every one of us has had our say and preferences when it comes to writing code.

There is no defined standard either at the company level or within each team. It is true that there are certain applications that are currently being developed in different teams that very vaguely we try to take as a reference for new developments, mainly to adopt good practices.

It is relevant to mention that my team is relatively new, formed just this year, and that the code in each of the applications over which we have governance is quite different from each other. Generally, they are legacy applications, where adopting a new approach to doing anything is not that simple and even generates panic among people who have been in the company the longest. Luckily, the team has recently created a payouts application where we have more freedom to innovate.

It is precisely in this kind of context where I think that using a linter is the best option.

Whenever starting a new application, my first commits are usually related to the configuration of the testing tool and the linter. However, these applications were not set up correctly from the get-go, so adding a linter definitely will bring a number of challenges.

The first time I talked to the rest of the team about the possibility of adding a linter to our applications to enforce a coding style, the reaction was mostly negative. The main argument was that other teams do not usually use it and that in some of their previous teams within this company they already tried to use it and it did not work. In addition, some of my teammates mentioned that if they had not been using it until now it is because we do not need it and that we should not enforce its use.

The way I see it, those are not solid arguments for not starting to use it, but I did not want to push it any further because I am a newcomer to the team and I knew the time to bring it up again would come.

A few days later, my onboarding buddy included a change in a MR where she added whitespaces after { and before } in an existing hash. One of the developers whose opinion is most valued within the company, who is not part of my team, reviewed that code and suggested that to avoid such changes in the future we could use a linter.

Of course, his opinion was taken into account, especially as it was meant to be introduced in the payouts application, where, as I said earlier, there is much more flexibility with the things we can do.

So for the next task I paired with my onboarding buddy and we added the linter as a previous step to other changes we had to implement. We decided to use RuboCop, as it is the most used linter in the Ruby community and the linter I have been working with for a long time.

In the unlikely scenario that you are not familiar with this tool, the official documentation states the following:

RuboCop is a Ruby static code analyzer (a.k.a. linter) and code formatter. Out of the box it will enforce many of the guidelines outlined in the community Ruby Style Guide. Apart from reporting the problems discovered in your code, RuboCop can also automatically fix many of them for you.

RuboCop is extremely flexible and most aspects of its behavior can be tweaked via various configuration options.

To start, once installed, we added the basic configuration in the .rubocop.yml file, located in the root of the application:

require:
  - rubocop-performance
  - rubocop-rspec

AllCops:
  SuggestExtensions: false
  NewCops: enable
  TargetRubyVersion: 3.3

Style/Documentation:
  Enabled: false

Note that there is no configuration related to Rails because we usually do not work with that framework.

I added the following make commands to run the linter inside the Docker container where the application runs:

lint:
  docker compose exec <service> bundle exec rubocop $(if $(COP),--only $(COP))

lint-safe-fix:
  docker compose exec <service> bundle exec rubocop -a $(if $(COP),--only $(COP))

lint-unsafe-fix:
  docker compose exec <service> bundle exec rubocop -A $(if $(COP),--only $(COP))

lint-group-offenses:
  docker compose exec <service> bundle exec rubocop --format offenses

lint-generate-todos:
  docker compose exec <service> bundle exec rubocop --auto-gen-config --auto-gen-only-exclude --no-exclude-limit

Next, we ran the linter to check how many offenses exist in the codebase:

$ make lint

Get a list of all offenses grouped by cop:

$ make lint-group-offenses

Usually most offenses are related to quotes (or string literals):

Style/StringLiterals:
  Enabled: true
  EnforcedStyle: double_quotes

Here you can choose the option you prefer, single or double quotes, and run the command that automatically solves those offenses:

$ make lint-unsafe-fix COP=Style/StringLiterals

Make sure you have a good test suite before you start applying automatic changes with the linter.

Since payouts application is still small, we checked each type of offense one by one.

The next cops I usually configure are related to conditionals:

Style/IfUnlessModifier:
  Enabled: false

Style/NegatedIf:
  Enabled: false

Style/NegatedUnless:
  Enabled: true

Style/UnlessElse:
  Enabled: true

Style/IfUnlessModifierOfIfUnless:
  Enabled: true

Style/InvertibleUnlessCondition:
  Enabled: true

For more details about that configuration, take a look to this other post.

Of course, this is a personal choice and I expected to open a discussion with my teammates in the MR later on regarding the final configuration.

We then repeated the same process of checking the cop with most offenses, configured it as desired and automatically corrected offenses where possible. Not all cops allow to autocorrect offenses.

For those cops I find any offenses, I like to be explicit even if it is to configure the default option of a cop.

At least initially, I also like to have a single place where those files that contain some offenses are temporarily being ignored. Therefore, I include in the .rubocop.yml file which files are being excluded for each cop:

Metrics/AbcSize:
  Enabled: true
  CountRepeatedAttributes: false
  Exclude:
    - app/commands/initiate_payment.rb

Another option, if you want to be even more fine-grained, is to disable cops inline, only in certain parts of a file:

# rubocop:disable Layout/LineLength, Style/StringLiterals
[...]
# rubocop:enable Layout/LineLength, Style/StringLiterals

However, I agree with GitLab on this issue, especially in legacy applications.

Once all offenses have been solved or explicitly disabled, we ensure that no new offenses will be added to the code if the developer adding new changes remembers to run the linter, because we are not enforcing its use neither on the machine of every developer nor in the CI pipeline.

What is the point of configuring a linter if you do not enforce its use?

Thus, in a follow-up task where I refactored much of the code for the payouts application, I added the configuration for the CI pipeline, knowing that it would raise some questions among my teammates once the MR was reviewed. And so it did.

We met and agreed that those changes would be removed from that MR and we would have a dedicated meeting to talk about it later.

A few weeks later we met again and it was up to me to try to convince my team about why it is necessary to have a linter configured and also to enforce its use, especially in the CI pipeline.

My main selling point was that RuboCop provides an initial configuration based on the Ruby style guide, in addition to other community-relevant style guides such as RSpec or Rails, with corresponding dependencies added.

Other relevant arguments largely match those mentioned by Evil Martians:

• Consistent code style, avoiding discussions based on preferences of an individual.
• Onboarding new engineers becomes much easier when the code style is standardized.
• Linters help detect and squash bugs in a timely fashion.

I must say that there was no outright refusal from the team, but they were reluctant about using a linter.

Their arguments against it include the following points, in addition to some previously mentioned:

• In the payouts application we can use it, not in the rest of applications.
• We should not use a linter in all our applications because not all teams use a linter and we do not know if next year the governance will change.
• Do not refactor any of the code if it is not strictly necessary, for things like the cyclomatic complexity of a method or a class, because it would be difficult to detect possible errors in a MR that includes changes in (literally) hundreds or even thousands of files.
• Enforce the use of the linter on the machine of every developer with a git hook so it is not necessary to include it in the CI pipeline.
• Some people do not care about linters, although if we use it they will adapt.
• Do not use .rubocop-todo.yml file for reasons very similar to those shared by Evil Martians.
• A teammate suggested we could use Standard as a linter to avoid bikeshedding by having to choose which rules to follow.

Of course, I agree with some of those arguments, so my proposal at all times accommodated their arguments, trying to find a point where we all felt comfortable.

In the case of RuboCop vs Standard, I prefer to invest some time initially and directly have the flexibility provided by RuboCop to decide the rules we are gonna follow, adapting to the application at hand, instead of using Standard that under the hood itself relies on RuboCop and does not allow to overwrite rules. I think that we should adapt the configuration to the application at hand, because not always you can apply the same rules to a greenfield application and to a legacy application. I prefer to start with RuboCop's default configuration and adjust the configuration of each cop as needed.

I suggested that I could create a proof of concept adding the linter to one of our larger applications to gauge the effort needed to add it, see what changes needed to be applied and finally decide together if we wanted to go ahead with it. They agreed.

I added the required gems to the Gemfile and added the RuboCop configuration we already had for the payouts application.

I started again getting the list of all offenses grouped by cop:

$ make lint-group-offenses

The linter found ~32k offenses. More than half related to quotes.

Then I ran the command that automatically fix all offenses, both the safe and unsafe ones:

$ make lint-unsafe-fix

Remember to run the tests every time you change something with the linter. Having a good test suite is the key to success here.

About 60 tests started to fail. All those errors were related to mutated strings by adding the following line to all files:

# frozen_string_literal: true

In some cases it was enough to change String#gsub! with String#gsub. In other cases, the encoding of a string was being changed with String#force_encoding, so we basically had to choose between creating a new unfrozen object with Object#dup and setting the magic comment to false.

Once those changes were made, all tests passed correctly.

However, I only did that to check that it was feasible to start using the linter in that application. What I did next was undo all the changes I had made to start creating a commit for each of the cops with the most offenses. Not all of them, because that would take too long.

Some of the cops with the most offenses were the usual suspects:

• Style/StringLiterals
• Style/FrozenStringLiteralComment
• Layout/DotPosition
• Layout/EmptyLineAfterMagicComment
• Layout/LineLength
• Layout/SpaceAfterComma
• ...

For every one of them I followed the same process I had already followed for the payouts application.

• Check the configuration options for the cop on the official RuboCop documentation.
• Correct the errors automatically for that cop, whenever possible.
• Run the tests.
• Fix any tests that might be broken.
• Create a commit for that cop.

As I said before, fixing one by one all offenses would take too long, so all offenses were securely fixed:

$ make lint-safe-fix

With git diff I checked all the changes made and if for some reason any of them did not work for me, I would undo all changes and repeat the same process as mentioned before.

After that, all offenses were insucurely fixed and the same process was repeated yet again.

Finally, I generated the file with all the remaining offenses:

$ make lint-generate-todos

Exclude the remaining offenses in the .rubocop.yml file after running the linter again.

Also I configured the git hook that would run just before pushing to the remote repository of each application.

Create following config/git-hooks/pre-push file:

#!/bin/sh

echo "Running linter..."

if ! make lint; then
  echo "Linter detected issues. Push aborted."
  exit 1
fi

echo "Linter passed. Proceeding with push."
exit 0

Add config/setup-git-hooks file, that will run when the application is built with Docker:

#!/bin/sh

cp config/git-hooks/* .git/hooks/
chmod +x .git/hooks/*

echo "Git hooks successfully installed"

Add execute permission to that file with following command:

$ chmod +x config/setup-git-hooks

Bear in mind that git hooks can be skipped:

$ git push --no-verify

Use that option only if you really have a good reason for it.

And that was the proof of concept. When we met again, I told the team everything I had done, clarified some of the questions they had, and we agreed on the following:

• We are going to start using the linter in all our applications.
• Create a parent task on Jira containing a subtask for every application to which the linter needs to be added.
• Use the existing configuration for the payouts application as starting point and in all other cases we use the default RuboCop configuration, unless we have a strong opinion about any of the cops.
• Do not add the linter to the CI pipeline step because we have the git hook. I still think it would be the right thing to do, though.
• Use the .rubocop-todo.yml file to maintain the list of offenses that are being ignored, keeping in mind that it can be regenerated as those offenses are resolved.
• We are all committed to resolve the offenses little by little.

That is all I can share for now. Tasks are already created and added to our board, but the hardest part is to find the right time to tackle them.

Nobody said that adding a linter to a legacy application is easy, but I am totally convinced that when we have done it, it will be beneficial for all of us on the team and those yet to come. Hopefully this will be the spark for other teams to think about the possibility of using a linter seriously in all their applications.

In any case, keep in mind that here I am only focusing on a style linter and formatter like RuboCop, but there are other kinds of linters, like Reek or Brakeman, that are complementary to RuboCop and that I also consider to be very useful in any application.

Before finishing, I would like to mention that it is quite handy to view the warnings and errors produced by RuboCop as you type code or save changes in your editor or IDE instead of having to run the checks through the command line every time, so configure any of the integrations available to improve your workflow.

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

Here I would like to focus on what I consider to be in most cases a questionable use of unless and what I think could be a better approach. YMMV.

But first, I will start giving a bit of context about that conditional statement.

As far as I know, Perl was the first one that introduced unless to provide a more readable alternative to using negated if.

Although the keyword unless is not available in most programming languages, Ruby already included it in its first version released in 1995. Other languages highly inspired by Ruby, such as Crystal or Elixir, include that control structure as well.

Its function is the opposite of the if statement, meaning that will execute a block of code only if a condition is false. You could say it is syntactic sugar for a negated if.

Remember that the only falsey values in Ruby, those that evaluate to false, are false and nil.

I have read a lot about how unless improves readability in cases where you are checking for negative conditions, making the code flow more naturally and even closer to plain English.

And I wonder, is that so?

Most of the people I have worked with come to Ruby from other languages, such as .NET, PHP, Python or Java. I have asked many of them what is their opinion about the use of unless in Ruby and not a single one of them has shared with me a positive experience. Ever.

They usually have expressed confusion towards any code where that statement is used. Of course, you could think it is a small sample to draw many conclusions. However, if you search the web you will find other people as confused as my teammates.

I tend to agree, but I must say it was not always like that. In my first contact with Ruby, I kind of liked using unless whenever I considered it was necessary without much hesitation.

However, nowadays I avoid its use as much as possible. In my opinion, it adds cognitive load in most cases. Every single time I see an unless in the code I have to stop and translate it in my head to "if not". Even the easiest condition.

And I have been working with Ruby for almost 15 years now, no wonder it is difficult to grasp for people just learning the language.

In my side projects I completely avoid its use, but in a real job you need to reach an agreement with the rest of the team if you want the codebase to be as consistent as possible.

Although unless is vastly used in the Ruby community, surprisingly I did not find much literature about it, with some exception. I am not taking into account the articles about the basic structures of the language, of course.

I would like to highlight that the author of the post linked above considers following code "little gems":

i += 1 unless i > 10

unless person.present?
  puts "There's no such person"
end

Once again, I wonder if Ruby was designed with an emphasis on programming productivity and simplicity, why complicate things?

I would write the same code as follows:

i += 1 if i <= 10

if person.blank?
  puts "There's no such person"
end

Much easier, right? To me it feels more natural and easier to understand. By far.

Whilst I disagree with his examples, I agree with his rules of thumb:

• Avoid using more than a single logical condition.
• Avoid negation as unless is already negative.
• Never use an else clause with an unless statement.

Next I will show some real-life examples with unless along with the code I would write instead.

Probably the most common example is the use of the truthy value of a given variable:

return unless user

Nobody will ever convince me that previous line is more readable that the following one:

return if user.nil?

Other common example is with collections:

return unless posts.any?

# ...instead of...

return if posts.empty?

Another common example is with equality:

return unless currency == "EUR"

# ...instead of...

return if currency != "EUR"

Certainly there is a lot of personal preference here. What is readable for you may not be readable for me. And the other way around.

A good example could be the next one:

return unless user.confirmed?

# ...instead of...

return if !user.confirmed?

Personally, I prefer negating the condition in that case, but I think we should always stick to whatever the team decides.

I would even prefer the use of not if what we are looking for is readability. Although I have never done that because the Ruby style guide has always discouraged it.

Yet another example would be the use of unless along with else:

unless user_signed_in?
  render "login"
  render "signup"
else
  render "profile"
  render "logout"
end

# ...instead of...

if user_signed_in?
  render "profile"
  render "logout"
else
  render "login"
  render "signup"
end

Fortunately, it is not so common to find such code.

The one rule I always follow, mentioned above, is to never use more than one logical condition with unless.

def user_has_access_to_course?
  return false unless user.present? && course.present?

  user.purchased_course?(course)
end

# ...instead of...

def user_has_access_to_course?
  return false if user.blank? || course.blank?

  user.purchased_course?(course)
end

My brain is about to explode every time I run into that kind of conditions.

I also prefer to see any conditional upfront, so I try to avoid conditional modifiers as much as possible. Those conditionals are placed after another statement allowing to run the code only when the condition is met.

The obvious exception to that rule are guard clauses, mainly used to avoid a condition wrapping the whole body of a method:

def url
  if course
    course_url(course)
  end
end

# ...or...

def url
  course_url(course) if course
end

# ...but preferably...

def url
  return if course.nil?

  course_url(course)
end

Keep in mind that the code before the condition is simple in those examples, but I have found on countless ocassions a conditional at the end of a line with a length of 100 characters or more. That is not exactly what I would call readability.

Besides that when there are two possible paths in the code, I do not care if the code is written with a full if/else or a guard clause:

def url
  if current_user.nil?
    public_course_url(course)
  else
    private_course_url(course)
  end
end

# ...alternatively...

def url
  return public_course_url(course) if current_user.nil?

  private_course_url(course)
end

But usually my teammates have prefered the guard clause, and I am ok with that option, as long as we are consistent.

As I said before, you have to reach an agreement with your team about how to write the code. In my opinion, a linter is the best possible tool to enforce those agreements.

Every single team I have been part of have always chosen RuboCop as linter. Out of the box it will enforce many of the guidelines outlined in the community Ruby Style Guide.

Next, I would like to highlight some cops that are related to conditionals:

• Style/IfUnlessModifier: Checks for if and unless statements that would fit on one line if written as modifier and checks for conditional modifiers lines that exceed the maximum line length. I always disable it.
• Style/NegatedIf: Checks for uses of if with a negated condition. Only ifs without else are considered. I always disable it.
• Style/InvertibleUnlessCondition: Checks for usages of unless which can be replaced by if with inverted condition. I always enable it.
• Style/NegatedUnless: Checks for uses of unless with a negated condition. Only unless without else are considered. I always enable it.
• Style/UnlessElse: Looks for unless expressions with else clauses. I always enable it.
• Style/IfUnlessModifierOfIfUnless: Checks for if and unless statements used as modifiers of other conditional statements. I always enable it.

The related rules from the style guide are the following:

• if as a modifier
• if vs unless
• Using else with unless
• Multi-line if modifiers
• Nested modifiers

Hopefully I have given to you some arguments why unless is not the best option to create readable code, but that is something very subjective, so the take away is to write conditionals in a consistent way, preferably following a style guide defined by the community or your own team.

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

TL;DR

Next I will explain my reasons behind that unpopular opinion.

In case you are not interested in my opinion or simply want to see what I did as a Linux user to (kind of) happily work with macOS, you can jump directly to the part where I share my configuration.

My reasons

The way I see it, Apple is a company that simply sells overpriced products, although usually are products with very good quality. I'll give them that.

Honestly, I will never understand what all the fuss is about, especially in the tech industry.

As a software developer, I don't get why so many tech companies force you to work with macOS, instead of asking you what operating system do you prefer to be more productive.

In fact, lots of them include working with a MacBook in their job offers as if it were a perk. Seriously? I guess they think it's really cool to have a bitten apple on the lid of your laptop. However, most of the time for half the price you could get a laptop with similar features or even better, depending on the laptop we are talking about.

In my previous post, I talked about my new job. The consulting firm allowed me to choose between Windows and macOS. I chose Windows simply because I wanted to install Ubuntu and have a dual boot. Finally I didn't do it because they don't have support for Linux, but mainly because I don't need that laptop at all. I used it for a few weeks but right now it's kept in a drawer, where it will remain until the day I have to return it.

On the other hand, the end client I'm actually working on, an American fintech company, didn't give me the opportunity to choose. They send me a relatively old MacBook Air with the M1 chip. So everybody in the company works with macOS, whether they like it or not.

I get that for IT and security teams (probably among others) is easier that everybody uses the same operating system. I also get that not every tool is available for Linux systems. That being said, I think that there is an open source alternative for most of them.

Anyway, during my first day with my new team I shared my feelings about macOS and everybody said that at least it isn't Windows. I used to think that way too, but after using the Windows laptop I mentioned before for a few weeks with WSL I must say that the experience was better than I expected.

And don't get me wrong, I hate Windows too. But for different reasons.

I know, I know. I'm just another hater...

If you've reached this point, you might ask yourself why so much animosity. And that would be a fair question.

Focusing here exclusively on macOS, it's mainly because of what I consider an awful user experience (UX).

I have previous experience working with macOS in a few companies, so I know what I'm talking about. The frustration I've felt every day working with macOS is something I have rarely felt working with Linux for almost 20 years.

I use a lot of shortcuts and I find quite frustrating in macOS that most of them don't work or do something completely different to what I expect.

The obvious exception in Linux is ctrl+c and ctrl+v in the terminal, where is required to press shift key to make it work as expected. Definitely that was really confusing for me at the beginning.

Although almost every Linux distribution has its own desktop environment, package manager, etc., I love the feeling working with any of them. Everything works just fine from the start. Every shortcut works as I would expect. No frustration at all. And I think that is priceless.

Of course it's not perfect. Among other things, the support for some drivers in Linux is sometimes far from ideal, but I'm talking here about the overall user experience.

Although macOS came first (with another name), and cmd and ctrl keys had different purposes, Windows was the real game changer during the '90s. For that reason and despite my feelings about that operating system, I'm glad that Linux followed the Windows way without the cmd key, allowing a smoother experience for any kind of user that wanted to try a quite different operating system. And that's precisely the main reason I hate macOS: Almost nothing works as I would expect from the start.

And I haven't even mentioned Finder yet. What the hell is wrong with that file manager? Well, let's keep it there...

In my previous experiences working with macOS I assumed I would have to deal with the frustration. So every time I used a shortcut with ctrl that didn't work, I used exactly the same combination with cmd. If you are something like me, that would happen constantly. You can't be really productive that way, always thinking about the next shortcut.

But you can't simply remap ctrl and cmd keys between them, because some shortcuts are expected to work with ctrl anyway.

So this time I decided that to be more productive from the beginning I needed to work as close as possible to how I work in Linux.

My configuration

The macOS version is Sonoma 14.6.1.

The laptop with macOS comes with a U.S. keyboard layout. I didn't apply any remapping to it.

Recently I acquired a wireless keyboard with Spanish layout (Logitech ERGO K860) and a vertical mouse (Logitech MX Vertical), both connected via Bluetooth. As usual, everything works just fine without any configuration in Windows and Linux.

Keyboard

Go to System Settings -> Keyboard.

Some combination of keys was constantly changing my input source so I changed following option:

Press fn key to -> Do nothing

In my case, I configured the Spanish input source during system installation, but if I hadn't, I would had to add it as follows:

Text Input -> Input sources -> Edit -> At the bottom left, click on + -> Search for Spanish -> Add

A few changes were made to the shortcuts:

Keyboard Shortcuts -> Missing Control -> Unfold "Mission Control"

Uncheck "Move left a space" and "Move right a space"

Those options are tied by default to ctrl key, but I prefer to use that key combination for navigation.

Keyboard Shortcuts -> Input Sources

Uncheck "Select the previous input source" and "Select next source in Input menu"

Keyboard Shortcuts -> Function Keys -> Enable "Use F1, F2, etc. keys as standard function keys"

How that behaviour is disabled by default simply beats me.

Mouse

Go to System Settings -> Mouse -> Disable "Natural scrolling"

The default behavior doesn't feel natural at all to me. For that reason, I prefer the so-called reverse scrolling.

Karabiner-Elements

This great application allows to easily remap keys and shortcuts. Check the list of features if you are interested.

I added a custom profile, so I can apply my configuration whenever I want.

I had to enable modify events for both the keyboard and the mouse. Otherwise the application won't be able to do the remapping properly.

Simple modifications allow to interchange keys.

I only apply changes to the desired device, in this case to the external keyboard.

Important note:

System modifier keys configuration in System Settings -> Keyboard -> Keyboard Shortcuts -> Modifier Keys is ignored when you use Karabiner-Elements.

Complex modifications allow to create rules to make some shortcuts available under certain conditions.

Initially I used some predefined rules maintained by the community, but once I started getting how they work, I started creating my own rules.

The event viewer comes in handy to confirm the name of each key and mouse button.

You can see the whole configuration on this gist.

Some modifications are only applied to specific applications, such as the terminal or the browser, and others are applied to all applications except the ones specified, usually VSCode.

Terminal

The first thing I did was replacing the default terminal with iTerm2.

I added a custom profile in Settings -> Profiles -> At the bottom left, click on +.

Add the desired name and set it as default profile clicking on "Other Actions...", placed at the bottom.

The shell I use is ZSH, that is configured through my dotfiles.

The shortcuts I use on this terminal are defined in Karabiner-Elements, except for the command that allows to recover the last argument provided to the previous command executed, alt+.

I couldn't replicate that behavior with that application, so I had to find an alternative. For that I followed the instructions in the following comment on StackOverflow.

You can see the whole configuration on this gist.

Another command I use a lot in the terminal in Linux is ctrl+u that clears the entire current line from the cursor to the beginning of the line. The closest command I found in macOS with that purpose is ctrl+w, cleaning each word from the cursor to the beginning of the line. To get the same result you have to press the same shortcut multiple times. The remapping was made with Karabiner-Elements, of course.

I plan to add all the configuration of this terminal to my dotfiles so I can easily replicate it anywhere I need it.

VSCode

The editor (or IDE) is the application where I spend most of my time everyday, so this is the main source of my frustration working with macOS.

I reused my configuration for VSCodium in Linux, stored on my dotfiles.

However I had to change the font size following the instructions on this comment, because everything looks smaller in macOS.

Open the file that contains user configuration. You can access to that file in ~/Library/Application Support/Code/User/settings.json or pressing f1 and selecting "Open User Settings (JSON)".

The relevant configuration is as follows:

{
  "editor.fontSize": 13,
  "terminal.integrated.fontSize": 13,
  "window.zoomLevel": 0.6
}

After that, having all keyboard shortcuts configured the way I wanted would have been a daunting task if it were not for a wonderful project on GitHub that takes care of people like me.

Open the file that contains keyboard shortcuts. You can access to that file in ~/Library/Application Support/Code/User/keybindings.json or pressing f1 and selecting "Open Keyboard Shortcuts (JSON)".

At the top of that file I have all the custom shortcuts included in my dotfiles. Right below I pasted the negative shortcuts from macOS to remove all those shortcuts. Then I pasted the shortcuts from Linux.

In case of doubt, you can find more details about how to proceed in the README of the project.

I couldn't directly translate all shortcuts from Linux to macOS, so I had to remove some of them from the Linux section, customize them properly, and place them at the top of the file.

Besides, I wanted to remove other shortcuts that I don't need, so I added them right between the customized shortcuts and the negative shortcuts from macOS.

You can see the whole configuration on this gist.

It's worth to mention that in Karabiner-Elements I was remapping some shortcuts from ctrl to cmd, so I was unable to properly configure some shortcuts because VSCode was receiving cmd when certain shortcuts expected ctrl. I became aware of the issue thanks to the Record keys functionality. To avoid that I check in every custom rule that the modification does not affect VSCode.

Finder

IMHO probably the worst application in the whole macOS ecosystem. It goes hand in hand with Preview for such dubious honor.

When you press enter on a selected directory or file, then you can rename that element. Why not?

I made some changes in its settings:

• Include the home directory in the sidebar
• Show all filename extensions
• Customize the toolbar (search, create new directory, move to trash, how to show items, item grouping, back/forward buttons)

Besides, some modifications made in Karabiner-Elements are focused on Finder:

• enter to open a directory or file
• f2 to rename a directory or file
• ctrl+h to show/hide hidden files
• delete_forward to move to trash a directory or file
• delete_or_backspace to go back to the parent directory

Other generic modifications, such as ctrl+c and ctrl+v, are applied to Finder as well.

Other configurations

One of the shortcuts I use the most is alt+tab to navigate between all the open programs. The simplest solution to get that shortcut would be remapping it to cmd+tab, but I still couldn't see all the instances of any given program. At least by default.

That's something else to add to the never ending list of things I will never understand about macOS.

For that reason, I'm using AltTab application, that does exactly what I need, and even more. It allows a lot of customization to get the desired result.

I also move and resize windows constantly using shortcuts, so I've installed Rectangle app. Very nice and simple.

Another essential application for me is the browser. In the last few years I have been using Google Chrome mainly, so I had to configure the shortcuts to which I am more used to. Again, some modifications made in Karabiner-Elements are focused on the browser:

• ctrl+l to put the focus on the address bar
• ctrl+d to save a bookmark
• ctrl+shift+t to reopen a tab
• ...

The work is far from done yet. Among other things, I'd like to be able to do the following with shortcuts:

• Open a image and navigate between all images in the same directory with arrow keys
• Close an image with escape
• Display a dialog that would allow to suspend/sleep, restart or shutdown the computer
• Select a directory or file and get the options available, similar to what you get with a right click of the mouse (or a button like in Linux)
• Navigate between spaces
• Easily move applications to different spaces

Last but not least, I have to update my dotfiles to include all this configuration.

Bear in mind that here I'm sharing my opinion and experience with macOS from the POV of a software developer that has been working and using Linux for most of my life. An operating system that is not as fancy as macOS is, but one that I consider way better and simpler to use. YMMV.

In any case, right now I have to work with macOS and hopefully I'm going to keep improving my UX to be a little bit happier every day (or at least less unhappy).

Are you an advanced macOS user and know another easier way to do what I'm doing? If so, please, share it because I'm quite interested in improving what I'm doing.

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