OmbuLabs Blog

As a company that is open by default we take pride in sharing a lot of our content on social media. Social networks like Twitter (now X), LinkedIn, Reddit, and Mastodon have helped us broadcast our content to people who trust us and respect us.

At the same time we are proud of our commitment to diversity, equity, and inclusion. As part of our core values we believe that diverse teams are smarter teams:

“There is value in all types of diversity, it is the best way to stay competitive in our industry. Problem solving with minds from different backgrounds leads to more creative and better thought out solutions.”

Recent changes in Twitter (now X) and their leadership are not aligned with our core values. We believe they are taking the social network in the wrong direction and we don’t want to have our brand associated with it anymore.

In 2023, Ciera Jaspan and Collin Green, as part of the Engineering Productivity Research Team at Google, published a paper titled Defining, Measuring, and Managing Technical Debt based on five years of research on tech debt across different teams in their company.

In this article, I will describe the most interesting findings from that paper and how you can apply them at your company to define, measure, and manage technical debt.

As a company, one of our core values is to be “open by default.” At the same time, one of our goals is to use our open source investment time as a way to improve our skills as engineers and designers.

In that spirit, this year we decided to organize our open source contribution time in a way that wasn’t limited to our own open source projects. This is a short post to explain how we aligned our open source contributions with our learning goals, what contributions we made, and why it mattered.

We recently learned that a website (ph-ombulabs dot com) is impersonating our company. They are unlawfully using our branding to take advantage of people who are looking for remote work.

At OmbuLabs, you are not just working with a premier software boutique when you work with us. You are collaborating with compassionate individuals, change-making innovators, and industry leaders who understand your challenges because we’ve faced them. More importantly, we know how to solve them.

Since 2016, the company has invested in native-to-mobile civic experiences to encourage political engagement among its users—whether it’s by learning what’s on your ballot, or keeping abreast of current issues, or by running for office.

At OmbuLabs, we value and respect our teammates and we are committed to protecting their mental health, physical health, and well-being.

On Friday June 24th, the Supreme Court announced a decision to overturn Roe v. Wade, removing the federal right to an abortion and leaving the decision up to each state.

We at OmbuLabs are prepared to ensure that all of our teammates have consistent and safe access to the benefits we provide, regardless of the state in which they live.

At OmbuLabs we have many values that have been key to our success. This is an article about the values that differentiate our company from the rest. We truly live and breathe our values throughout every part of our organization.

Every team member is expected to follow these values, especially when things get tough. This is a living document. We have been tweaking these values ever since starting the company.

At OmbuLabs, we are big fans of Ruby on Rails and design patterns, especially convention over configuration! The beauty of Rails is that you can inherit a legacy project and easily find the different layers of code in different directories.

When it comes to database migrations the policy of Rails is very clear. It’s all about altering the database structure with gradual migration files: “Migrations are a convenient way to alter your database schema over time in a consistent and easy way.” (source)

But, what about data migrations? What’s the best way to write, maintain, and run migrations that alter the data in your production database?

In this article I will talk about three different patterns for writing and maintaining your data migrations:

1. Data migrations in db/migrate
2. Data migrations with a set of Rake tasks
3. Data migrations with data_migrate

If you are interested in Ruby and Rails performance, you have definitely read articles by Nate Berkopec from Speedshop. At Ombu Labs we are big fans of his work, his Complete Guide to Rails Performance book and Slack community.

When Nate announced a series of public workshops I didn’t hesitate and signed up as quickly as possible. Here are my notes from my experience at the workshop on October 17th.

At OmbuLabs we believe that if we are not learning from our mistakes we are doing it wrong. It is simple: The only unforgivable mistake is to not learn from our mistakes.

That is why we try to incorporate feedback into everything we do. We embrace peer reviews and pair programming as a way to get constant feedback on a daily basis. Even this article had reviews from 3 different people! (https://github.com/ombulabs/blog/pull/154)

Another step that we incorporate into every client relationship is an exit call. This call gives us an opportunity to assess how well we performed.

If we performed well: Great! What can we do more of? If we performed poorly: What can we improve? What can we do to make it better for our next project?

A few weeks ago I had the opportunity to talk to Preston St. Pierre, CTO of Predictable Revenue. We worked with Preston and his team for 2 years to help them scale their software development.

Today we are happy to announce the launch of our first productized service: FastRuby.io - Speedy Ruby on Rails Upgrades by OmbuLabs.

We are quite familiar with this sort of projects and decided to package it under its own domain. We have been doing Ruby on Rails upgrades since 2009, for our own products and client projects, and we are looking forward to shipping more of them.

When you create IAM credentials and policies for your app, you should make sure that they have access to the resources that they need and not more than that!.

This way, if anyone gets access to those credentials, the impact of this leak is reduced to the resources associated with them (and not all the buckets in your S3 account)

Getting started with a new project should be as simple as possible, even for someone who is not technical. As a maintainer, you must make sure that anyone can clone your project and get it up and running in a few minutes.

After you clone a project, you should follow two steps:

1. Setup
2. Start

I’m a big fan of having small classes. I’m not a big fan of having huge specs for a small class/object. Every time I see an opportunity to DRY my specs, I take it.

Today I wrote a spec to make sure that we gracefully ignore SPAMmy contact requests in the OmbuLabs contact page. It initially looked like this:

test "gracefully ignores spammy requests with valid attributes" do
  @valid_contact = contacts(:two)
  attributes = @valid_contact.attributes
                             .merge(email_confirmation: @valid_contact.email)

  assert_no_difference("Contact.count") do
    post :create, contact: attributes, format: 'js'
  end

  assert_response :success
end

The new behavior adds a simple SPAM trap field that bots will usually fall for. If a bot is submitting the email_confirmation field (which is hidden by a CSS class), then it is SPAM and it gracefully ignores the request.

There are a few agile practices that I really love. Pair programming is one of them.

We try to do it as much as possible at OmbuLabs. We usually keep the sessions under two hours and try to follow a regular schedule.

When we find ourselves blocked by a code problem, we use our daily scrum to coordinate a pairing session. It’s quite a step up from rubberducking or using a cardboard programmer to find a solution to a problem.

The Joys

As a Senior developer, I find that pairing sessions are great for coaching Junior developers. I enjoy teaching them about best practices, design patterns, frameworks, languages, code style, XP, and TDD.

From the point of view of a Junior developer, I believe it’s a great opportunity to learn from someone who “has been there before”. When you program with someone with more experience, you will often learn about design patterns, elegant object-oriented solutions, tips and tricks.

There is no good reason why an MVP should take more than one month. If that happens, it means that the scope of the minimum viable product wasn’t small enough.

You want to build the smallest feature set in order to start learning from your target market. It doesn’t have to be feature complete. It doesn’t even have to offer a feature. It doesn’t even need to be a web-based MVP.

It will come a time when you will have to decide whether to maintain a Rails project or not.

If you want to seriously consider it, you should follow these 10 steps:

1. Setup the development environment

Git clone the repository and try to start the server. Is the README clear enough? Can you follow the steps in the file and easily get started?

A lot of projects will have a README that is out of date and/or instructions that don’t work right off the bat.

Most of the projects will define guidelines like these:

• Configure your config/database.yml
• Configure your .env file
• Setup the database rake db:create db:migrate db:seed
• Start the server rails server

The best projects will have a one-liner that will setup the entire environment for you.

The simplest way to contribute to an open source project is to file an issue. Here are a few steps for you to file issues that are useful for the project maintainers.

As a maintainer of a few Ruby gems, I have to decide what is accepted and what gets rejected into the gems. The other day someone submitted a pull request to add a Dockerfile to DatabaseCleaner

I thought it was a good idea, because the current version of DatabaseCleaner requires you to have Postgres, MySQL, Redis, and Mongo up and running before you run rake.

Here are the steps:

1. Download the Docker Toolbox, a 176+ MB package.

2. Install the package, which will expand to 400+ MB in your filesystem.

3. In the terminal: docker-machine start default

4. Then within your project: docker-compose up (before this I had to run eval "$(docker-machine env default)" because of this issue). Get ready to wait for a few minutes while it sets up your virtual machine.

5. Finally: docker-compose run --rm gem

The other day I was trying to interact with a hidden file input field:

<div class="col-sm-3">
  <input class="btn btn-default" class="hidden" accept=".csv"  id="geofence_file_input">
  <a class="btn btn-default" id="textbox-for-geofencefile">Select File</a>
  <span ng-if="LineItemForm.augmentations.geofence.file">{{selectedFilename()}}</span>
</div>

And the CSS:

.hidden {
  display: none;
}

Which caused this problem:

Failed: Wait timed out after 100015ms

Workarounds include displaying it, interacting with it, hiding it again, which I didn’t like.

As of 2016, we will no longer work with clients on fixed bid projects. They are not a good fit for us and we are not a good fit for them.

All of our clients are startups. Fixed bids are counterproductive for startups. They give the client a false sense of security and they punish changing requirements.

Fixed bids make clients think that their project will be finished in a fixed period of time if their requirements don’t change while developing the project. That is a big if!

On April 17th we discovered a security vulnerability in the Mercado Pago API. Before disclosing this information, we contacted Mercado Libre and sent them a detailed report of the security hole and how to reproduce it.

The vulnerability allowed anyone to get an access token without using the right secret for an account.

At OmbuLabs we like to split our time working on our own products, client projects, and open source code. We have embraced the Lean Startup methodology not only for our own products but also for our client projects.

It is easier to apply the methodology to our own products than to our client projects. With our products, we decide what goals we want to reach and what experiments we are going to run to validate our hypotheses.

Quality should be present in everything you do, but it should be balanced with the time you spend working on a feature. Does it feel like you’ve been working on this feature for a really long time? Maybe you have. Is it “done”?

That is a tough question, so I’ll write down our definition of done.

The other day my friend Juan Rossi reported a vulnerability in the Almundo billing system. Since then, the vulnerability has been fixed by Superfactura, their billing software provider.

Almundo is one of the biggest travel agencies in Argentina. Their site is among the 250 most visited websites in the country.

The vulnerability allowed anyone to download billing information about their clients by creating a pretty simple HTTP GET request. No programming knowledge required.