OmbuLabs Blog

Recently, we started using Skylight in production for one of our clients’ Rails applications, in an attempt to try to improve the performance of some of the more critical API endpoints.

Skylight reports on:

• Time taken per request
• Breakdown of time taken per SQL query
• Object allocations per request

I noticed an unusually large amount of allocated objects for one request:

This request would take anywhere from 400ms to 3000ms to respond, which is WAY too long.

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.

Hubot makes it incredibly easy to setup on a Heroku server, by taking advantage of its Procfile support. Simply running git push heroku master deploys the app and starts it.

When it comes to deploying to your own Linux server, given that foreman doesn’t really like background processes (see: ddollar/foreman#65), you need to use something like monit, systemd or tmux to better manage your Hubot process.

Maybe in the past you stumbled over the two different approaches to setup your test variables. One way is the more programmatical approach by using instance variables, usually initialized in a before block.

If you are working with open source or if you are going to open source a repository, you should ensure that none of your sensitive data (API Keys, Credentials, Passwords) can be accessed by anyone.

One thing that a lot of people forget, is that this information stay forever in your repository history, if you do not rewrite the history of your repository.

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

When integrating Backbone.js in your Rails App, you might face the problem of the inability to verify the CSRF-Token.

The CSRF Protection secures your app with a token. Rails makes sure that the person who is interacting with your app is someone who started a session in your site, not some random attacker from another site. So you should not turn it off, unless you know what you are doing.

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

We have been using Slack at OmbuLabs for a while now after switching from HipChat, and haven’t looked back. It looks and feels much better than any other available platform of its kind. Slack provides WebHooks, which you can use to post messages to your team’s channels.

default_scope is a method provided by ActiveRecord, which allows you to set a default scope (as its name implies) for all operations done on a given model. It can be useful for allowing soft-deletion in your models, by having a deleted_on column on your model and setting the default scope to deleted_on: nil

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.