OmbuLabs Blog

Contributing to open source might be scary, you might think that your pull request (PR) is not good enough; that people will judge you by your code; or that fixing that little typo is not worth it.

I had all these questions in my head before I submitted my first contribution to an open source project and it stopped me many times.

Everyone has had the experience of working on a gnarly, difficult to understand code-base. The sort of code base that makes you hate your job. Often it comes down to poor design, but code conventions also play a large part in whether you wake up dreading your job in the morning. The overall design (choice of design patterns and how modules and classes are organized and factored) is the long range, big picture strategy of how an application will be made. Code conventions, by contrast, come down to the choices you make about which constructs of a language you use, which you don’t, and when.

Out of all the problems an agency might face, “we have more opportunities than we can handle” is not something you’ll typically hear anyone complaining about. For those who are lucky enough to be in that position, it’s always thought of as being “a good problem to have.” But make no mistake, having more opportunities than you can handle can be a real problem. Aside from the obvious opportunity costs of all the work not taken, there are often good reasons why you may not be able to expand your permanent headcount just yet.

Pull Requests let developers tell other team members about changes they’ve made to a project repository. Once a pull request is created, team members can review the set of changes, discuss potential modifications and even push follow-up commits before the changes are merged into the repository. Therefore, it is important to make sure that your pull requests are easily understandable to the reviewers.

In a previous article we talked about one of the Rails Girls events that we sponsored and co-organized in 2018. Fast forward one year to our first event of 2019 at A3, a new coworking space located in Buenos Aires, we were once again sponsors and volunteers at another successful Rails Girls event.

Sidekiq Pro comes with a great feature to process a collection of jobs as a batch, allowing them to be monitored as a group and executing a callback function when all the jobs are finished. This is useful when you need to load a lot of spreadsheet files into your database.

Recently, that was the case of one of OmbuLabs’ clients. They needed to upload a CSV file with over 10 thousand rows of loans data, which makes processing the file synchronously impossible because the browser will time out after a few seconds. Breaking the file into smaller ones wasn’t a good idea either, because it would take an unacceptable amount of time to finish. So we decided to use the Sidekiq’s batch logic.

Since Sidekiq Pro wasn’t an option at the time, we had the challenge of implementing the same pattern that Sidekiq Pro uses in their Batches processing. This article will show how we did it.

One of the first complications that most webapps of any complexity will run into is the need for privileged users who can do things that normal users can’t or shouldn’t be able to do. Before too long, you’re headed towards writing your very own administrative interface. This is not only extra work, but can be tricky to do without compromising the security of the application you’re administering. Most Rails developers will be familiar with this story, and Rails being Rails, it turns out that there are a couple of good options for extending your existing applications with a pre-generated, customizable admin console.

Sprint Retrospectives are a crucial part of our project management strategy at OmbuLabs. Because we are a remote and international team of software developers, we miss out on the “water-cooler” conversations and small talk that would normally occur between employees in a typical office environment.

In a recent project for OmbuLabs, we were looking for a payment solution that allows users of our platform to easily start accepting online payments while at the same time allowing us to collect a fee from each transaction they receive. That’s where Stripe Connect came into place.

In this series of code refactoring posts we are discussing how design patterns can be used to make our Ruby code beautiful, maintainable and clean.

Today I want to talk about a pattern that can be very useful when we need to control the flow of a set of events of our objects: The State Pattern a.k.a Finite State Machine.

As a developer it is common to see objects changing their state. At the beginning managing the state of an object can be as simple as having some boolean attributes where you can check if the object is in state A or B. But when the complexity increases you can end up with a number of states that are difficult to manage without breaking the SOLID principles. That is where we can implement the elegant solution provided by the State Pattern.

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

At OmbuLabs, we like to split our time between working on our own products, open source and client projects.

Our own products include everything from OmbuShop, an e-commerce platform, to FastRuby.io, a Ruby on Rails upgrade service. In terms of open source, we recently created Audit Tool and are constantly searching for more projects to contribute to. We also work on a variety of interesting client projects, and with our current team size, like to take on two to three of them at a time.

As an Account Manager, it can get hectic trying to manage all of this. Google Calendar can be a serious help.

If you’ve been a web developer for any length of time at all these days, you’ve no doubt used at least a few web based APIs here and there. It’s possible that you’ve even written one (or more!) yourself. API design is a rich topic with a lot of deep roots, but some cursory research will show a number of best practices that public facing APIs should implement. Understanding these practices will give you a firm basis for judging the quality of APIs as a user and consumer, and allow you to design more useful APIs when it’s your turn.

If you’re looking for services that handle the delivery of your emails and SMSs in your app, SendGrid and Twilio are some of the most complete options out there.

In this article we are going to focus on a common scenario when using those services: How can we have a real time status of the emails and text messages that we send from our Rails app.

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.