OmbuLabs Blog

OmbuLabs is a fully remote company based out of Philadelphia with team members in many countries. Currently we are growing pretty steadily, and we thought it would be a good idea to let prospective employees know what it would be like to work at OmbuLabs.

This article is based on questions we often get during interviews, so we hope it helps if you are thinking about applying to OmbuLabs. You can learn more about the recruitment process here.

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.

This post is the third one in the SOLID principles series. The first post discussed the single responsibility principle and in the second post we discussed the open / closed principle. Next, as the title suggests, we will take a look at the principle represented by the letter L from the SOLID acronym. L is for the Liskov Substitution Principle (LSP).

In simple terms LSP requires that supertypes and subtypes be swappable without affecting the correctness of a program.

In a previous post we considered the practical value of the Single Responsibility Principle (SRP). This is the second post in this series where we take a deeper look at each of the SOLID principles.

Robert C. Martin (a.k.a. “uncle Bob”) refers to the O in Solid as the heart of Object Oriented (OO) design. He goes so far as to say that this principle improves reusability and maintainability more than any other OO principle. You most likely already know that the O in SOLID belongs to the Open/Closed Principle (OCP).

We often hear about SRP or DRY (don’t repeat yourself) but seemingly less often about OCP. It turns out that this principle lays the foundation for many of the OO best practices. In this post we will talk about OCP and find out why uncle Bob is such an advocate of OCP.

Rails UJS (Unobtrusive JavaScript) is the JavaScript library that helps Rails do its magic when we use options like remote: true for many of the html helpers.

In this article I’ll try to explain the main concept of how this works to make it transparent for the user. Knowing a bit about the inner workings can help when debugging issues and also if we need to do something more complex than the provided interactions but reusing what’s provided.

If you are using an old version of Rails and you are still using jquery-ujs, some code will not reflect how it does the magic, but most of these concepts apply as well (rails-ujs is a re-implementation of jquery-ujs removing the jquery dependency).

Previously, I outlined the new hotness that is Hotwire. New features are nice, but what can you build with it? Let’s build a little project, and let’s make it something different from the usual Twitter clone that’s being used to demonstrate this new feature. Instead, I’ll show how to build a basic scrolling price ticker like you’d see on any stock site that updates in real time. We’ll learn a few interesting things along the way.

“If you can’t measure it, it doesn’t exist” - Peter Drucker

Tackling technical debt can be a thankless task. You can spend hours tidying up old files but at the end there’s little to prove it was a good use of time. No target was met and no new feature exists to show the bosses.

The lack of metrics means that maintenance tasks gets pushed back behind work with obvious outcomes and the debt keeps building.

To make matters worse, the costs of technical debt are also hidden. Projects will start to overrun and developers will get burnt out, but there’s nothing clearly showing that tech debt is the reason why. It means maintenance starts to feel like a chore with no obvious outcome or benefit.

We have had to come up with ways to show the value of our work when performing maintenance for clients, so we wanted to share them here to serve as inspiration for other developers.

We agree with Sandi Metz when she describes Object Oriented (OO) design as a style guide for arranging code. The so called “OO style guide” is underpinned by a few rules that we have come to know as the SOLID principles.

In this post we will discuss the S in SOLID. We will talk about the significance of this principle and perhaps even look at some practical ideas for applying it.

One of the main goals we set for 2021 is to become more efficient as an agile team. And one of the challenges we addressed was how to minimize the decision-making bottleneck. To confront that we decided to take some actions that I’m listing below.

The impact of technical debt is obvious to developers. Devs are the ones that have to tackle the headaches of dependency issues and patch holes in the security.

But the reasons for performing software maintenance can get lost in translation when they’re discussed with non-technical executives. It can be unclear how rewriting functioning code can translate into more money in the bank and why it’s worth dedicating time to.

So, here’s how we describe the business reasons to prioritize your maintenance.

Have you ever had to deal with complex forms creating multiple objects and hierarchies in one request? Rails is there to help provide a set of helpers, methods and conventions to build nested forms, handle assignment, and creation of the objects involved in only a few lines of code. In this blog I’ll explain how that works using accepts_nested_attributes_for, fields_for, strong parameters and more.

One of the most visible and controversial new developments with the release of Rails 6.0 is Hotwire. Like anything in web development, the growing popularity of single page applications using JS frameworks has sparked some resistance. Arguably, the duplication of logic that single page applications often require violates the DRY principle. There are also many developers who would like the responsiveness of single page applications without all of the client side JavaScript and it’s associated headaches. There are a considerable number of developers who’d like the pendulum to swing back towards the server, but maybe keep some of the more desirable aspects of the SPA pattern. Hotwire is a fresh take on how to do this the Rails way.

Devise is a well known solution for authentication in Rails applications. It’s full featured (it not only adds authentication but also password recovery, email changing, session timeout, locking, ip tracking, etc.) and can be expanded to add even more (like JWT authentication).

In this post, I’ll go over the code related to the basic database authentication process, how it relates to Warden and some of the magic behind it. If you don’t know what Warden is, I will be explaining the role it plays for Devise in this article.

Since the release of Rails 6, Webpack is the default JavaScript bundler for new Rails apps. We all struggled at first coming from a Sprockets background, and more often than not, we, as Rails developers, tried to avoid making JavaScript changes so we wouldn’t have to deal with it.

In this post, I’ll try to explain some basic concepts and ideas from the point of view of a Rails developer used to working with the Assets Pipeline, comparing how to do the same thing on both.

In keeping with the first part of this series, I’ll list a few interesting issues we found when making the apps work as similar as possible for Android’s webview and iOS’ webview.