OmbuLabs Blog

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?

We like to use GitHub to its full potential at OmbuLabs, so any tool we add to the toolset needs to integrate nicely with it. As a growing agency working in larger and increasingly more complex projects, we need a project management tool that allows us to keep track of our work and plan accordingly. For this, we use Pivotal Tracker.

There are many things that are easier with Pivotal Tracker, as long as you are using it the right way. Some of its features are very useful for agile teams like ours. This is how we like to use it to ship value with every sprint and keep track of our team velocity.

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

At OmbuLabs we are big fans and happy customers of Noko. We use their widget to track all the hours that we spend on client projects, open source development, and our own products.

Today I’m happy to introduce Pecas, time tracking leaderboards for Noko! Pecas is an open source tool that integrates with your account and generates beautiful leaderboards per project and per teammate.

Here is a sample dashboard for all your projects:

On top of that, it will send you an email alert if you haven’t tracked any hours during a work day. If it’s a holiday, it won’t bother you. :)

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.

I’ve always been a big fan of scratching your own itch. My latest itch was the insane amount of parking violations that I see everyday in Buenos Aires, near our office.

We decided to build a simple tool that would allow anyone with a Twitter account to report a parking violation. All you need to do is submit a geolocated tweet and a couple of photos (as evidence!)

Here is an example:

Ah, ¿no se puede estacionar en paradas de colectivo? Ya fueee... #InfractoresBA pic.twitter.com/XXmu1pdAib

— E r n e s t o (@_nesto) April 18, 2016

You can check out this tool over here: http://www.infractoresba.com.ar

This page shows all the parking violations reported by users to @InfractoresBA or with the #InfractoresBA hashtag. It’s as simple as that.

This is our process to hire new full-time developers at OmbuLabs. It’s a process that we have been improving ever since we started our operations. It’s very important for us to hire “A” players.

In this article we will focus on how we evaluate new developers, but parts of the process can be customized for other positions as well.

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!

Last Wednesday I gave a lightning talk about open source at the Buenos Aires Ruby Meetup. I proposed a challenge to all attendees: Contribute to one (or many) open source projects for 7 days straight.

The rules are simple:

• You have to do it for 7 days straight
• If you can’t do it one day, that breaks your streak
• When you break your streak, you have to start over from day 1

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.

Often times I find myself working out of a coffee shop with a terrible Internet connection. We have a nice office at OmbuLabs but there is still that Je ne sais quoi at coffee shops.

The cool thing about Git is that you can git commit all your changes while enjoying a cup of coffee and git push later (when you’re back at home with a decent connection)

But what if you want to git push from the coffee shop? Sometimes the only ports that are open are port 80 (HTTP) and 443 (HTTPS).

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.