OmbuLabs Blog

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

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.

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.

Since starting at OmbuLabs as the Junior Developer I have had the incredible opportunity to pair with my teammates. A lot. Over the months we have begun to develop better practices and routines to make the most of our pairing sessions, and now I would like to share some of our practices and tips for making a pairing session successful. At OmbuLabs we are a fully remote company so all of our pairing sessions are done through Tuple or Zoom, but this advice could translate easily to in person sessions as well.

One of the most fundamental tasks when writing or refactoring software of any kind is breaking the problem down into smaller parts. When you’re first starting out - and even as you continue to gain experience - figuring out what those parts should be, and where they should live within a codebase can be a daunting task. Design patterns and principles can help, but trying to keep them in mind as you design and implement solutions can be overwhelming.

Thankfully, there’s a pair of principles that can cut many of these gordian knots, and render decision making much clearer, simpler, and easier to articulate to others. Understanding and using the concepts of coupling and cohesion to guide my design and refactoring decisions yielded immediate results for me.

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.

Becoming the Apprentice, and then Junior Developer at OmbuLabs was both exciting and nerve racking. Learning a new company can be challenging, especially when the skills are new and the work is remote.

Fortunately OmbuLabs made the journey a smooth and easy process. Here are some of the things that have been working.

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.

Tough Love

One of the first things that a journeyperson programmer will have to learn when they transition from full time student to working developer is that things in the real world are never as cut and dry as their classes may have made it seem. At the end of the day, software is not written because we love building castles of logic in the sky, it’s written to solve a real problem. That might seem like a trite observation, but it explains almost everything you observe as a working developer.

I will not bore you by telling you the history of Vim, and the differences between vi and Vim and all of its philosophy…

If you are interested in that, you can give it a look here.

Pull Requests let developers tell other team members about changes they’ve made to a project repository. Once a pull request is created, team members can review the set of changes, discuss potential modifications and even push follow-up commits before the changes are merged into the repository. Therefore, it is important to make sure that your pull requests are easily understandable to the reviewers.

In a previous article we talked about one of the Rails Girls events that we sponsored and co-organized in 2018. Fast forward one year to our first event of 2019 at A3, a new coworking space located in Buenos Aires, we were once again sponsors and volunteers at another successful Rails Girls event.

Last month was the fifth edition of the Rails Girls Buenos Aires event, and the third time OmbuLabs participated as a sponsor and part of the coaching team. This time it took place in the impressive offices of Google Argentina where 25 participants attended. All of them were very excited and motivated to start learning new skills.

After reading introductory primers and watching instructional videos for beginners learning Ruby, I needed a program that would allow me to test out Ruby concepts for myself. I began practicing Ruby Koans, a testing-based program that runs through a variety of Ruby concepts in a trial and error fashion.