OmbuLabs Blog

When starting a new software development project with a client, it is important to get started on the right foot. The way you communicate with a client at the beginning of a project can set the tone for how communication will be throughout the project.

Therefore, at OmbuLabs, we believe it is crucial to start off every new project with a Kickoff Call, where we can take time to get to know the client’s team and speak in depth about their goals and priorities for the project. We like to discuss the following list of topics with clients during our calls:

The internet is a wonderful place, but there will always be people that don’t have good intentions when they visit our websites. That’s why you need to be aware of the vulnerabilities that your application can have and how to avoid them. In this article I’ll cover two common security problems in Rails applications (I’ll probably make a second part since this is a very extensive topic).

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.

At OmbuLabs we believe that if we are not learning from our mistakes we are doing it wrong. It is simple: The only unforgivable mistake is to not learn from our mistakes.

That is why we try to incorporate feedback into everything we do. We embrace peer reviews and pair programming as a way to get constant feedback on a daily basis. Even this article had reviews from 3 different people! (https://github.com/ombulabs/blog/pull/154)

Another step that we incorporate into every client relationship is an exit call. This call gives us an opportunity to assess how well we performed.

If we performed well: Great! What can we do more of? If we performed poorly: What can we improve? What can we do to make it better for our next project?

Transcript:

Hello and welcome to the first OmbuCast by OmbuLabs. In this screencast we’ll be taking a look at the derailed_benchmarks gem, and how you can use it to benchmark your Rails application and find, and hopefully fix bottlenecks in your code.

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.