OmbuLabs Blog

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.

Over the last few months, we developed a couple of Snap Minis. Minis are small static web apps that are run inside a webview within the Snapchat native app.

One important part of the development was to make sure our Mini works well across different devices, especially making sure things work the same in both Android’s webview (Chrome by default) and iOS’s webview (Safari).

In this post I’ll talk about a few things to keep in mind when working with the Snap Canvas SDK and in the next one I’ll talk about some common and known issues you’ll encounter when making your app cross-mobile-browser compatible.

At OmbuLabs our goal is always to smooth processes, and make work easier. Isn’t that what software engineering is really all about in the first place?

When we are getting ready to do a project or to make a proposal one of the questions that we are always asked by clients is “how long will it take”? To come up with an estimate on timing we like to use a system of points and blind estimates by multiple team members to find an average of how complex the project will be. We can then use this information, together with our database of delivered projects, to estimate how long the project will take.

To accomplish this, and make the process smoother we built a tool called Points and now we have moved it to open source in case it can be of use to any other teams out there!

As a software consulting company, we bill for the time we work on client projects. So it is vital for us to keep track of the time we put into every task. We’ve had some trouble over the years with our time tracking, and sometimes that led us to work more time than what we finally billed for. We would like to share some of the experience we have collected over the years and the tools that we currently use.

Open Source is one of the things that we value as a company. Our philosophy is that “everything we do should be open by default”. This is why in the past few months we decided to open source two of our internal projects. We built Dash and Points to make our daily processes smoother, and then we thought “hey, why not share them with everyone?”. Now we also want to share the process of how we turned them from private to open source.

As a distributed, remote team we use different tools to communicate at OmbuLabs, like Slack and Zoom. Those are great for live communication. But every company has information that needs to be kept and stored somewhere. In our case, we started off using the GitHub Wiki and Google Docs. However, documentation and policies need to be maintained, updated and checked regularly. And having information scattered in different tools, formats and accounts became a hassle.

That’s where a knowledge base comes in. At OmbuLabs we use Tettra and we will share our experience in a different article. But regardless of what tool you choose, here are some practices that will help you keep your knowledge base organized and updated.

The discussion around the use of problematic words / terms in technology isn’t a new one. This issue can be traced back to, at least, 2003 when a Los Angeles county worker filed a complaint with the city’s Office of Affirmative Action Compliance after seeing “master” and “slave” in computer equipment labels.

This issue has resurfaced with recent events and, at OmbuLabs, we believe it is important to take it seriously. It is past time to remove this metaphor from our codebase and review some of the terminology we use. We have started taking the necessary steps to rename “master” branches to “main”, as well as (and perhaps more importantly) remove any reference to the term “slave” and replace “whitelist / blacklist” with “allowlist / blocklist”. Our team is actively working on that.

But we understand that is not enough. This is not an action that will solve racism by itself. It’s part of a larger commitment. In this article, I’ll explain the context and motivation for this change and how it fits with our core values and long term vision as a company.

Last month, Snap announced a new product during the Snap Partner Summit 2020, Snap Minis. Minis are bite-sized third-party experiences that live inside of Snapchat and can be accessed through Snapchat’s Chat interface. They’re built on the same principles and technology as Snap Games and are easy to develop, allowing you to build an experience that is available to Snapchat users worldwide.

OmbuLabs recently developed a Snap Mini for one of our clients. In this article, I’ll share the main advantages of launching a Snap Mini and how we can help you get started:

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.

With the constant pressure to both find and then execute on client projects, agencies often lose sight of the possibility of working on internal projects. While the initial reaction is often to dismiss them as a distraction from the important client facing work, carefully chosen interal projects can be very valuable. Aside from the obvious benefit of solving internal problems that might not have a readily available solution, they also provide training opportunities for developers. They give you a chance to try new ways of doing things with relatively low risk, or perhaps preview new languages and frameworks you’ve been considering.