OmbuLabs Blog

If you live in Argentina and you ever use AFIP, you should already know that their platform is not the best in terms of user friendliness. We wanted to integrate OmbuShop with AFIP (using their API) in order to generate and print the bills for each seller. Unfortunately, there is no way to do this because the API doesn’t generate a printable version (PDF) of the bill.

How many times did you come across a great gem you wanted to try out in a production console, like benchmark-ips or awesome-print?

Be it for performance or for readability, sometimes it’s nice to be able to try out something new quickly without going through a pull request + deployment process. This is possible by modifying the $LOAD_PATH Ruby global variable and requiring the gem manually.

When working on a Rails project, you may have seen present? calls on ActiveRecord relationships. This might feel natural, mostly because present? exists on all objects via ActiveSupport, so you expect the relationship to respond to it, but it’s actually not a very good idea. If all we want to do is check if the scope returns any results from the database, there are better ways than using present?.

A few weeks ago, I noticed weird output in the RSpec test suite (~4000 tests) for a Rails application:

.............................................................................................unknown OID 353414: failed to recognize type of '<field>'. It will be treated as String  ...........................................................................................................................................

This Rails app uses a PostgreSQL database. After some Googling, it turns out that this is a warning from PostgreSQL. When the database doesn’t recognize the type to use for a column, it casts to string by default.

When writing tests for services, you may sometimes want to use mock objects instead of real objects. In case you’re using ActiveRecord and real objects, your tests may hit the database and slow down your suite. The latest release of the rspec-mocks library bundled with RSpec 3 includes at least three different ways to implement a mock object.

Let’s discuss some of the differences between a spy, a double and an instance_double. First, the spy:

[1] pry(main)> require 'rspec/mocks/standalone'
=> true
[2] pry(main)> user_spy = spy(User)
=> #<Double User>
[3] pry(main)> spy.whatever_method
=> #<Double (anonymous)>

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

A few times in the past I’ve had to interact with IMAP via Ruby, and wrapping your head around its API is not so easy. Not only is the IMAP API a bit obscure and cryptic, but Ruby’s IMAP documentation is not so great either.

Searching the internet for examples doesn’t yield too many results, so I’ll try to write down some of the things I’ve learned. The examples I’ll show use Gmail as the target IMAP server.

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.

A few weeks ago, I found an interesting project called Bumbler. If your project uses Bundler, Bumbler shows you your project’s largest dependencies. When you find yourself staring at the screen after running bundle exec rails c, you may want to give this tool a try.

Sessions provide you a nice little data storage feature where the application does not need to get the information directly from the database. So you do not have to persist data in your database and can easily store info about the user on the fly. This is a nice way to enhance the user experience on your page.

Let’s say that you want to show some users a new fancy sign up form and the rest the old form. If you store the version of the sign up form in a session variable, you don’t need to persist this info in your database.

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.

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.