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, we have some projects where multiple teams work at the same time on different features or fixes. We started using Heroku’s Review Apps because we kept running into blockers when a team needed to deploy a branch to our staging server but another team was using it.

There are two configurations in Heroku to create Review Apps: manual and automatic. A manual creation gives us more control, but not every person involved in the QA process has access to the Heroku pipeline. So, for many months, we used the automatic Review App creation every time a PR was created/updated. This was an easy workaround, but there’s one problem, the Review Apps for Heroku Teams can’t use free dynos, so we were being charged for Review Apps that were created before they were actually needed or even for PRs that didn’t really need a Review App at all.

We started looking for an easy way to control the creation and deletion of Review Apps that can be triggered by anyone directly from the GitHub PR and here are the details and how we do this now.

Do you know what the most successful apps and digital products have in common? An idea. An idea that was challenged, tested, recalibrated, and validated to be a perfect market-fit. New startup leaders may find it challenging to turn their ideas into a product. More specifically, a product that solves the right problem for the right users. That’s where we come in. Introducing the OmbuLabs Design Sprint 🎉.

I joined OmbuLabs as a Senior Software Engineer on February 11, which was a Friday-more on this later! Tomorrow I will have completed 2 weeks here. So if you want to find out about the onboarding process at OmbuLabs, read on.

At OmbuLabs the first step in the interview process for any of our open positions is the cultural fit interview. This interview will tell us a few things about the candidates. It should let us know if they have the kind of experience that would match well with the open job, it also shows us if the candidate would settle in well with the values of the team, and it tells us if we think we should offer a second interview.

“You can have a little imperative React, as a treat.”

When building modern applications with React, Function Components and Hooks are the de facto way to do it. Hooks make your code more declarative and easier to reason about (usually).

However, with all great hammers, you run the risk of everything looking like a nail. Occasionally, some more object-oriented solutions might be the right tool for the job. For example, what if you had a child component that contained a function that needed to be called from the parent? You might want an instance method, but we don’t use Classes anymore!

Fear not – you don’t have to abandon Hooks to be able to call methods on child components. In this post, I’ll show you how – using forwardRef and useImperativeHandle.

Email threads are great for improving the user experience of your app. In this post we will learn how the RFC 5322 specification expects us to thread emails. We will also learn that emails don’t always work as we expect them to. At the end of this post you will have email threading as another tool in your Rails belt.

It’s been a few months now that we’ve been toying with Elixir here at OmbuLabs. Particularly with Phoenix. However, I like to toy a bit with the language without the added complexity of a framework on it, in order to better understand it, how it works and how things are done.

It took me a while, but as I read through “Programming Phoenix”, I had the idea to implement a “simple” calculator program in Elixir. The reasons were quite simple:

• I wanted to better grasp unit testing with ExUnit, and a calculator has very clear specifications, making it the ideal candidate.
• I also wanted to put a little twist to things and while math has very clear specs, it can have some very complex operations, so I decided to make my calculator do derivations.

For those of you that aren’t versed in calculus, don’t worry, I’ll give just what you need to know in order to understand what I’m doing, but trust me, you won’t need to really understand calculus to understand the code.

The title says it all, but how does one actually implement object oriented design patterns in Ruby? If you’re like me and always struggled with putting what you read about programming into an actual implementation and the examples in the book or around the internet weren’t enough to quell your doubts, read on.

To the seasoned developer this may seem like a silly question, but to developers who are self-taught, bootcamp trained, or even just have never come across a project in TypeScript - understanding exactly what it is and how to use it can be a bit of a mystery.

In this article we will try to explain the basic concepts behind TypeScript, and the reasons for using it.

Audit is a Rails application that allows users to check for vulnerabilities in their Gemfiles in an efficient and secure manner.

The tool has been around for a while, but now we decided to make the repository open source! You can find it here: https://github.com/fastruby/audit

Open source powers many of the tools that we rely on daily for our work. As developers, we have the privilege of being able to read, learn, and build from thousands of codebases at our fingertips. What better way to give back to the community that creates the software that powers our world than to contribute to those very same tools?

Contributing to the open source community can be daunting for a seasoned developer, let alone a novice. One problem I’ve had as an early-career developer has been figuring out how to find a project that aligns with my interests as well as the skills that I want to practice. One great resource I’ve found very helpful with finding answers to my questions is the book [Forge Your Future with Open Source, by VM Brasseur] (https://pragprog.com/titles/vbopens/forge-your-future-with-open-source/).

In this article, I will show you what I’ve learned from VM Brasseur’s book about what to consider when I’m determining what open source projects to work on.

With the release of Rails 6, Webpack was introduced as the default JavaScript bundler by using the Webpacker gem. We tend to think about Webpack only as a tool to handle JavaScript files, but it can be used to handle all kinds of asset files. This article shows how to create a Rails app that uses only Webpack to handle all the assets, including images, fonts, styles and videos.

Today we will discuss the I in SOLID which, you may or may not know, represents the Interface Segregation Principle (ISP). This is the fourth article in the SOLID series. We have already discussed the Single Responsibility, Open/Closed and Liskov Substitution principles.

In this post we will discuss the value of and the process for crafting easy to maintain interfaces. If we have enough time we will also discuss how interfaces might apply to dynamically typed languages such as Ruby. With no further ado, let us start by finding out what an interface actually is.

This article covers the basics of onboarding with a new client as a software engineer contractor. We will look at the people, resources and dynamics involved in successful onboarding with thoughts to reference as you onboard.