OmbuLabs Blog

Configuring your Rails application can be tricky. How do you define secrets? How do you set different values for your local development and for production? How can you make it more maintainable and easy to use?

Using environment variables to store information in the environment itself is one of the most used techniques to address some of these issues. However, if not done properly, the developer experience can deteriorate over time, making it difficult to onboard new team members. Security vulnerabilities can even be introduced if secrets are not handled with care.

In this article, we’ll talk about a few tools that we like to use at OmbuLabs and ideas to help you manage your environment variables efficiently.

When working with complex forms, it’s really easy to immediately start adding JavaScript to implement non-common behaviors. But there are some hidden gems in the HTML standard that allow us to do a lot of that without adding a single line of JavaScript!

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.

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.

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).

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.

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.

We, Ruby developers, are used to running scripts or commands with the prefix bundle exec, but sometimes it’s not needed, but sometimes it is, and when it’s not needed it still works just fine if we add it. So it may not be clear why we need to use it in some cases.

In this blogpost I’ll try to answer these questions with a little insight on what Bundler (and Ruby and Rubygems) do.

In the first and second parts of this series we talked about positional and keyword arguments, but we still have some extra options so that our methods can do anything we want.

In this final part we are going to explore blocks, array decomposition, partially applied methods and a few syntax tricks. We’ll also study a few known methods to understand how everything is used in real world applications.

In the first part of this series we talked about positional arguments, but there are more types. In this second part we’ll talk about keyword arguments.

Positional and keyword arguments share a lot of characteristics so we’ll split this article into similar sections, but there are some key differences we’ll touch on in each section.

Ruby is an object oriented language where everything is an object (even methods are objects of the class Method!), so everything we need to do is done by calling methods on objects. That also means that methods have to provide a lot of flexibility because they are used everywhere.

Ruby provides a lot of options to pass arguments to our methods, so we’ll make this topic a series so it’s not too long. We’ll split the options into different categories and then break down everything with some examples and/or use cases.