OmbuLabs Blog

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

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. :)

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.

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.

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.

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.

We recently worked on a series of Christmas presents for the team. We are happy to share part of the process and its final result!