OmbuLabs Blog

Just before the world shut down in 2020, the team at OmbuLabs participated in an in-person retreat in Punta Cana. It was a wonderful experience, and the team was eager to have another retreat in 2021. We even began planning one, but with the safety of team members at risk because of the pandemic and the difficulty of traveling it soon became obvious that an in-person retreat would not be possible. Therefore we turned our attention to having the retreat virtually.

This ended up being a very successful event, and we wanted to share the experience and strategies that we used to plan and execute this retreat which took place virtually over four days towards the end of 2021.

At OmbuLabs one of our core values is Open by Default, which means that we want to have open communications, contribute to open source projects, give back to our community, and become thought leaders in our industry. We also believe that one great way to give back to the community is sharing our knowledge, especially the things that we discover as developers in our day-to-day.

That’s why we try to keep consistency in this blog and also encourage every team member to speak at conferences, on podcasts and at meetups. I want to share with you things that are working for us as an “open by default” team.

Code Review is one of the greatest tools we have as software developers to help us improve the quality of our code. It can be incredibly beneficial, but it can also be a source of pain, frustration, and overall, a waste of time instead of a time-saver.

Because of that, a while ago we wrote these code review tips that should be acknowledged and incorporated by everyone in our team and now we want to share them with you.

A few months ago I received the task of making the FastRuby.io sitemap refresh automatically after each deploy. That sounds like it would be pretty straightforward if we didn’t have one issue (it’s never that easy, right?). For the FastRuby.io blog we created a gem that encapsulates a Jekyll application. The discussion of why do we have a gem for our blog is actually a good topic for a new post. For now, I want to focus on the sitemap task that I had.

Since the blog is a gem, we also need to make sure that whatever tool we use to generate the sitemap covers new blog posts.

In this article I’ll show you my journey to figure out how to make everything work together.

Service Objects are a controversial idea for several different reasons: some developers like to use them, others like to use similar patterns, and some think that they are just unnecessary because they prefer fat models.

Here at OmbuLabs we like to use service objects whenever we can, we think it’s a great way to keep our controllers skinny.

In this post I would like to discuss my idea about service objects and why it’s adopted by our team.

Recently at OmbuLabs I had the mission of setting up Heroku Review Apps for one of our projects. Since the project is built in a multi-tenant architecture (using the apartment gem) it was a bit challenging to setup.

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.

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.

In our last article of the refactoring series we saw how design patterns can be used to make our Ruby code beautiful and clean. Design patterns are a powerful tool for any developer and a familiarity with them will lead to better code by forcing a consideration of SOLID principles.

Now let’s talk about other pattern that when properly used can be very helpful: The Template Method.

Code refactoring can be defined as “the process of introducing small and incremental changes to leave the code in a better state than it was.”. When refactoring your code you have to consider two things: no new functionality should be added and the external behavior should not be affected.

One of the biggest challenges as a Ruby on Rails Developer is to keep your code clean, simple and easy to maintain and that is why we are always refactoring our code.

There are several techniques that a developer can follow to improve their code by code refactoring, such as extract method, move method, move field, switch statements, etc. If you are not familiarized with them, please visit the Refactoring Guru site.

Another technique developers try to follow is to apply good design patterns to their code. In this post we’ll try to go over some of the documented design patterns and how you can apply them to your Ruby code.