OmbuLabs Blog

Be it for our own internal tooling or on our client’s projects, we’ve used a variety of package managers. When building our newest tool, we decided to try out the uv package manager that’s been talked about a lot.

One problem with that, though, is that lack of support for uv in Heroku’s Python buildpacks. There’s an issue open in the Heroku roadmap to support it, but it is not supported yet.

We weren’t going to let that little hiccup stop us from using uv though. Inspired by the python-poetry-buildpack, we built our own little heroku-uv-buildpack that allowed us to deploy our application to Heroku.

In 2023, Ciera Jaspan and Collin Green, as part of the Engineering Productivity Research Team at Google, published a paper titled Defining, Measuring, and Managing Technical Debt based on five years of research on tech debt across different teams in their company.

In this article, I will describe the most interesting findings from that paper and how you can apply them at your company to define, measure, and manage technical debt.

As a company, one of our core values is to be “open by default.” At the same time, one of our goals is to use our open source investment time as a way to improve our skills as engineers and designers.

In that spirit, this year we decided to organize our open source contribution time in a way that wasn’t limited to our own open source projects. This is a short post to explain how we aligned our open source contributions with our learning goals, what contributions we made, and why it mattered.

This is part of our series on design sprints. If you haven’t read our previous articles, I encourage you to read more about our design sprint process.

Day 5 of the design sprint is about testing your prototype and getting feedback on your ideas. That way, you can quickly learn what is or isn’t working about the concept. Yesterday, the interviewer spent time putting together a list of questions for the interview sessions. Earlier this week, your team recruited 5 participants for Friday’s research. Now you are ready to do the dang thing.

You’ve signed a contract with an agency, awesome! At this point you already know that agencies like ours offer expertise and resources that can help you overcome challenges, increase efficiency, and achieve your goals.

Now that the executives, sales team, and lawyers have signed off on the project, how do you get off to a quick start to accomplish your business goals?

This is part of our series on design sprints. If you haven’t read our previous articles, I encourage you to read more about our design sprint process.

Day 4 is a little different from the other days of the Design Sprint. Instead of a series of workshops, we will spend most of the day each working on one part of the prototype.

Towards the end of the day, we will do a test run to check on our progress and adjust from there.

In my previous post, I mentioned how I was having issues with populating my random maze. The main problem is that there isn’t a clear way to programmatically add random rooms and paths between those rooms. I ended up with a method way more complex than I wanted and that only did the most basic thing, which was to add random types of rooms and just connect them randomly as well, but without verifying any form of room placement, for example.

This is a clear sign that we need another layer of abstraction. We need something that can hold our maze data and to take care of placing the rooms and connecting them according to the rules we establish. After some research, I think I found the right alternative: the Graph.

Design Sprints lend themselves nicely to a virtual format, and digital tools can enhance this widely-used process developed by Google Ventures.

Day 3 is all about picking a direction and going forward with it. Over the course of the third day of the Design Sprint, we will assess which parts of our designs are most successful and create a storyboard to show the steps that our target customer might take towards achieving the goal.

Remember your sketches from Day 2? It’s time for the team to see them. The purpose of this activity is for the entire team to see each other’s work and get to pick out all the best pieces for our next activity.

So, our little exercise in design patterns is getting quite messy. Which is ironic, considering it’s an exercise in design patterns.

The reason is that I’m mostly trying to be very focused on the Design Patterns book and just fleshing out the example implementations they provide.

Therefore, in order to organize things, I believe this is the right time to add unit tests. As a plus, I also get to test my little gem in an automated fashion.

Here I’ll only go through the RandomMazeBuilder class since it would be quite lengthy to go through every single file. To see all the other specs, just checkout the repo.

As a consultancy specializing in upgrades, dealing with legacy code is our bread and butter. Incompatible versions of Ruby, different version managers, C errors while running bundle install - there are many ways that setting up projects is not always straightforward. Add to this several projects and your development machine becomes a mess of hard to diagnose issues due to mismatched system dependencies. Virtualization to the rescue!

Have you ever wondered what the values on the request queue graph in the APM tool meant or whether a certain value indicated good or poor performance?

The fundamentals of request queue, factors that contribute to longer request queues, and other topics will be covered in this post.

If I were to ask you: tell me in one word or a number here, how satisfied are your users with the response times of your application. What would you say?

I would say the apdex score is 0.98 and that’s pretty awesome. Now, if you are wondering what is this apdex score and what does the 0.98 value tell us, you have come to the right place.

Continue reading to understand this better.

Upon integrating any performance monitoring tool for your application, you must be observing p95, p99 response times on the dashboards. If you are wondering what do these terms and their values mean, you have come to the right place.

Web Sockets are an integral part of a lot of modern-day systems. But have you ever wondered how a Web Socket actually works? Or does your system even need a Web Socket? In this post, we are going to cover the basics of Web Sockets, i.e, the what, the why, and the how.

Frontend development is so exciting nowadays! There is a wide spectrum of opportunities in each particular project. There can be tons of different interesting cases related to feature development, bug fixing and testing! A lot of new components, configurations, and flows.

In the last part of this series, we left our little maze game gem generating random mazes that had random kinds of rooms using the abstract factory pattern.

While that was good enough, in the case of the our maze game, it turns out mazes can be pretty complex objects, being a collection of rooms, doors and walls of many types. And even though I didn’t add too much variety of these components, things could get pretty convoluted.

It turns out there’s a pattern just for these cases: the Builder Pattern.

Since 2016, the company has invested in native-to-mobile civic experiences to encourage political engagement among its users—whether it’s by learning what’s on your ballot, or keeping abreast of current issues, or by running for office.

Have you ever wondered how does Medium recommend blogs to read or how does a platform with millions of users tells if a username is available or taken? If yes, you have come to the right place, as we are going to look at the data structure that makes this and a lot more happen. The data structure is Bloom Filter.

No, not that Meta

What most developers call JavaScript frameworks (React, Vue, Svelte, etc) can more accurately be thought of as UI Libraries. While they can make writing the front end of websites and apps simpler, they have no opinions at all regarding what goes on further back in the stack. They don’t even have prescribed methods of organizing the folders and files in your projects.

Full-fledged frameworks (think Rails or Django), on the other hand, will usually be very opinionated and expect the code to be organized in a certain way, with the hope that this will lead to shorter development time by getting rid of analysis paralysis and bikeshedding.

Thankfully, there are libraries available to fill that role in the JavaScript ecosystem. Since most UI libraries are called “frameworks”, these more full-featured libraries have taken to calling themselves “meta-frameworks”.

In a nutshell, they let JavaScript developers focus on the “what” and take care of most of the “how” for you.

In my last article I introduced this series and here’s the first pattern: the Abstract Factory

Hello everyone, this is my first blog post on the ombulabs.com blog. I am so excited to have joined the company and to have the opportunity to write here.

The second day of the Design Sprint is about finding inspiration, looking back at the decisions made during Day 1, and starting to assemble possible solutions. Now that the team has narrowed down a problem space, it’s time to start the idea generation process again, but this time with sketches.

Have you found yourself in the fortunate position of being the only designer in an organization that doesn’t have any design assets or previous research? Lucky you! Now is the time to do things right and build a solid foundation for excellent research and design practices while also creating value as soon as possible. Here’s my approach to starting off on the right foot as a UX practitioner in an environment where you are breaking ground and creating UX assets from scratch.

Let’s deep-dive into what happens on the first day of a Design Sprint. On Mondays, we understand the problem.

I want to give credit to the creators of the Design Sprint method, Jake Knapp, John Zeratsky, and Braden Kowitz from Google Ventures who developed this Design Thinking method in the mid 2010s. Their process is the starting point from which all variations of Design Sprints come from, and I work with their framework to create Design Sprints that are customized to suit client needs.

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

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

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.

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.

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.

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

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.

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!

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.

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:

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.

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.

This is our first quarter report for open source projects, we will be releasing this report on each quarter of the year with the purpose of motivate us to contribute more and release more open source projects.

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.

At OmbuLabs we are firm believers of open source. We use open source but also like to contribute back to the community and we have open sourced a few projects.

We know that contributing to open source can be a difficult task so we have been looking for easier ways help to onboard new and past contributors. Here is a list of tips and tools that we believe that can help you make your open source project a more friendly space.

A few months ago I received the task of making the FastRuby.io sitemap refresh automatically after each deploy. That sounds like it would be pretty straightforward if we didn’t have one issue (it’s never that easy, right?). For the FastRuby.io blog we created a gem that encapsulates a Jekyll application. The discussion of why do we have a gem for our blog is actually a good topic for a new post. For now, I want to focus on the sitemap task that I had.

Since the blog is a gem, we also need to make sure that whatever tool we use to generate the sitemap covers new blog posts.

In this article I’ll show you my journey to figure out how to make everything work together.

The last time we looked at Docker, we looked at the most basic and easy version of using it - building an image from a base image, a parent, and then layering additions and changes on top of it. With a carefully chosen base image, this can be an extremely flexible and relatively straightforward way of getting an image up and running in a container.

No app is flawless. We all know that. Quality Assurance is an important part of any software development process and the better the tester, the higher quality the software that gets deployed to production.

But… how to be a better manual tester? Applications have evolved greatly and are becoming more and more powerful, but the manual testing process stays pretty much the same. So what is it that will make you stand out?

Here at OmbuLabs we have some techniques that we employ that ensure our high satisfaction rates. In this post, we’ll share some tips with you.

Manual testing is a necessary part of software development and quality assurance. And although it’s important to have a dedicated tester in your team, you as a developer can also help speed up QA, and thus the software development process, by becoming a better manual tester of your own code.

But how to do that? I’ll cover 4 simple points that will help you get there!

We launched FastRuby.io, our first productized service, back in June 2017. At the time, we had been doing Ruby on Rails upgrades since 2009, for our own products and client projects. We decided to package these upgrades under their own domain through FastRuby.io.

Now, over two years later, we have completed over a dozen Ruby on Rails upgrades through FastRuby.io and are seeing consistent interest in our upgrade and estimation services.

We decided that it was time to refresh the look and feel of the website. We worked with Verónica García, UI Designer and Front End Developer, to complete the website redesign. In this post, we talk to Verónica about her creative process and how she approached the redesign challenge.

In my last article, I gave a brief tour of what Docker is, and basic usage. Once you’ve got your feet under you with basic usage, you’ll reach the point where you want to start making your own containers. You’ll certainly need to know how to roll your own if you want to use Docker in your own infrastructure.

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.

If you’re like I was not too long ago, the DevOps world gives you a chance to experience what most non-developers probably feel like when they read about what we do on a day to day basis - confused, and maybe a little bored and frustrated, with an utter lack of even basic knowledge. It doesn’t help that DevOps is rapidly becoming a field of expertise unto itself, or that most of the relevant players seem determined to hide behind vague descriptions like “enterprise platform” and “containerization solution.” As a day to day working developer, adding an entire new skillset can be a daunting and intimidating prospect.

Recently at OmbuLabs I had the mission of setting up Heroku Review Apps for one of our projects. Since the project is built in a multi-tenant architecture (using the apartment gem) it was a bit challenging to setup.

Contributing to open source might be scary, you might think that your pull request (PR) is not good enough; that people will judge you by your code; or that fixing that little typo is not worth it.

I had all these questions in my head before I submitted my first contribution to an open source project and it stopped me many times.

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 recent project for OmbuLabs, we were looking for a payment solution that allows users of our platform to easily start accepting online payments while at the same time allowing us to collect a fee from each transaction they receive. That’s where Stripe Connect came into place.

In this series of code refactoring posts we are discussing how design patterns can be used to make our Ruby code beautiful, maintainable and clean.

Today I want to talk about a pattern that can be very useful when we need to control the flow of a set of events of our objects: The State Pattern a.k.a Finite State Machine.

As a developer it is common to see objects changing their state. At the beginning managing the state of an object can be as simple as having some boolean attributes where you can check if the object is in state A or B. But when the complexity increases you can end up with a number of states that are difficult to manage without breaking the SOLID principles. That is where we can implement the elegant solution provided by the State Pattern.

If you’ve been a web developer for any length of time at all these days, you’ve no doubt used at least a few web based APIs here and there. It’s possible that you’ve even written one (or more!) yourself. API design is a rich topic with a lot of deep roots, but some cursory research will show a number of best practices that public facing APIs should implement. Understanding these practices will give you a firm basis for judging the quality of APIs as a user and consumer, and allow you to design more useful APIs when it’s your turn.

In our last article of the refactoring series we saw how design patterns can be used to make our Ruby code beautiful and clean. Design patterns are a powerful tool for any developer and a familiarity with them will lead to better code by forcing a consideration of SOLID principles.

Now let’s talk about other pattern that when properly used can be very helpful: The Template Method.

Code refactoring can be defined as “the process of introducing small and incremental changes to leave the code in a better state than it was.”. When refactoring your code you have to consider two things: no new functionality should be added and the external behavior should not be affected.

One of the biggest challenges as a Ruby on Rails Developer is to keep your code clean, simple and easy to maintain and that is why we are always refactoring our code.

There are several techniques that a developer can follow to improve their code by code refactoring, such as extract method, move method, move field, switch statements, etc. If you are not familiarized with them, please visit the Refactoring Guru site.

Another technique developers try to follow is to apply good design patterns to their code. In this post we’ll try to go over some of the documented design patterns and how you can apply them to your Ruby code.

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.

Monit is a powerful tool for monitoring processes on Unix systems and sometimes it can be very useful to receive notifications about a specific process from your server to your everyday tool, Slack. This article will show you exactly how to do that.

A few weeks ago I had the opportunity to talk to Preston St. Pierre, CTO of Predictable Revenue. We worked with Preston and his team for 2 years to help them scale their software development.

Today we are happy to announce the launch of our first productized service: FastRuby.io - Speedy Ruby on Rails Upgrades by OmbuLabs.

We are quite familiar with this sort of projects and decided to package it under its own domain. We have been doing Ruby on Rails upgrades since 2009, for our own products and client projects, and we are looking forward to shipping more of them.

When you create IAM credentials and policies for your app, you should make sure that they have access to the resources that they need and not more than that!.

This way, if anyone gets access to those credentials, the impact of this leak is reduced to the resources associated with them (and not all the buckets in your S3 account)

One of the hardest failing tests to debug are those which fail randomly, also known as “flaky” tests. You write your test cases, you run the tests in your environment (in random order), and see them all pass. Afterwards, you push your code, your CI server runs them and one test fails.

This is not an uncommon scenario, and one too common when using integration tests which use JS, with Capybara-Webkit or Selenium. But if your failing test doesn’t communicate with an external API, doesn’t use JS, and passes locally, it can be a bit nerve-wracking.

After you have identified the failing test, and it still passes after running it locally, one way to figure out why it’s failing is running its context multiple times.

To automate this process a bit, I like to use the following command:

We all know the importance of having a CI tool integrated in your project. It allows you to run your entire test suite every time you want to merge a set of changes. If you have a core project and many projects that depend on it, you want to run the tests for the core project and the dependent projects at the same time. This article explains how you can do it with Circle CI.

I have been using the capybara-webkit gem for a while now since I first tried it out after making the switch from Capybara + Selenium.

Using capybara-webkit speeds up my Selenium tests due to its headless nature, and it’s very straightforward. However, I had some trouble testing a Rails based React app.

In this post, I will explain how I worked around the issues that came up when trying to use capybara-webkit with React.

Getting started with a new project should be as simple as possible, even for someone who is not technical. As a maintainer, you must make sure that anyone can clone your project and get it up and running in a few minutes.

After you clone a project, you should follow two steps:

1. Setup
2. Start

There are a few agile practices that I really love. Pair programming is one of them.

We try to do it as much as possible at OmbuLabs. We usually keep the sessions under two hours and try to follow a regular schedule.

When we find ourselves blocked by a code problem, we use our daily scrum to coordinate a pairing session. It’s quite a step up from rubberducking or using a cardboard programmer to find a solution to a problem.

The Joys

As a Senior developer, I find that pairing sessions are great for coaching Junior developers. I enjoy teaching them about best practices, design patterns, frameworks, languages, code style, XP, and TDD.

From the point of view of a Junior developer, I believe it’s a great opportunity to learn from someone who “has been there before”. When you program with someone with more experience, you will often learn about design patterns, elegant object-oriented solutions, tips and tricks.

A few weeks ago, I found an interesting project called Bumbler. If your project uses Bundler, Bumbler shows you your project’s largest dependencies. When you find yourself staring at the screen after running bundle exec rails c, you may want to give this tool a try.

Hubot makes it incredibly easy to setup on a Heroku server, by taking advantage of its Procfile support. Simply running git push heroku master deploys the app and starts it.

When it comes to deploying to your own Linux server, given that foreman doesn’t really like background processes (see: ddollar/foreman#65), you need to use something like monit, systemd or tmux to better manage your Hubot process.

If you are working with open source or if you are going to open source a repository, you should ensure that none of your sensitive data (API Keys, Credentials, Passwords) can be accessed by anyone.

One thing that a lot of people forget, is that this information stay forever in your repository history, if you do not rewrite the history of your repository.

The simplest way to contribute to an open source project is to file an issue. Here are a few steps for you to file issues that are useful for the project maintainers.

As a maintainer of a few Ruby gems, I have to decide what is accepted and what gets rejected into the gems. The other day someone submitted a pull request to add a Dockerfile to DatabaseCleaner

I thought it was a good idea, because the current version of DatabaseCleaner requires you to have Postgres, MySQL, Redis, and Mongo up and running before you run rake.

Here are the steps:

1. Download the Docker Toolbox, a 176+ MB package.

2. Install the package, which will expand to 400+ MB in your filesystem.

3. In the terminal: docker-machine start default

4. Then within your project: docker-compose up (before this I had to run eval "$(docker-machine env default)" because of this issue). Get ready to wait for a few minutes while it sets up your virtual machine.

5. Finally: docker-compose run --rm gem

The other day I was trying to interact with a hidden file input field:

<div class="col-sm-3">
  <input class="btn btn-default" class="hidden" accept=".csv"  id="geofence_file_input">
  <a class="btn btn-default" id="textbox-for-geofencefile">Select File</a>
  <span ng-if="LineItemForm.augmentations.geofence.file">{{selectedFilename()}}</span>
</div>

And the CSS:

.hidden {
  display: none;
}

Which caused this problem:

Failed: Wait timed out after 100015ms

Workarounds include displaying it, interacting with it, hiding it again, which I didn’t like.

We have been using Slack at OmbuLabs for a while now after switching from HipChat, and haven’t looked back. It looks and feels much better than any other available platform of its kind. Slack provides WebHooks, which you can use to post messages to your team’s channels.

On April 17th we discovered a security vulnerability in the Mercado Pago API. Before disclosing this information, we contacted Mercado Libre and sent them a detailed report of the security hole and how to reproduce it.

The vulnerability allowed anyone to get an access token without using the right secret for an account.

Quality should be present in everything you do, but it should be balanced with the time you spend working on a feature. Does it feel like you’ve been working on this feature for a really long time? Maybe you have. Is it “done”?

That is a tough question, so I’ll write down our definition of done.

The other day my friend Juan Rossi reported a vulnerability in the Almundo billing system. Since then, the vulnerability has been fixed by Superfactura, their billing software provider.

Almundo is one of the biggest travel agencies in Argentina. Their site is among the 250 most visited websites in the country.

The vulnerability allowed anyone to download billing information about their clients by creating a pretty simple HTTP GET request. No programming knowledge required.

If you are using git in 2015, you are probably also using Github, unless you’re self-hosting or still betting on Bitbucket.

Below are some cool, useful tricks you can use on Github which can probably make your life easier: