OmbuLabs Blog

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.

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.

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.

Audit is a Rails application that allows users to check for vulnerabilities in their Gemfiles in an efficient and secure manner.

The tool has been around for a while, but now we decided to make the repository open source! You can find it here: https://github.com/fastruby/audit

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.

At OmbuLabs one of our core values is Open by Default, which means that we want to have open communications, contribute to open source projects, give back to our community, and become thought leaders in our industry. We also believe that one great way to give back to the community is sharing our knowledge, especially the things that we discover as developers in our day-to-day.

That’s why we try to keep consistency in this blog and also encourage every team member to speak at conferences, on podcasts and at meetups. I want to share with you things that are working for us as an “open by default” team.

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.

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.

At OmbuLabs we are always trying to find or create tools to help our processes and workdays run as smoothly and efficiently as possible. For the past few months we have been developing just such a tool, and recently we made it open source. Dash is a dashboard application written in Ruby on Rails that integrates open pull requests and issues from GitHub with Pivotal Tracker stories.

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.

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.

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.

If you live in Argentina and you ever use AFIP, you should already know that their platform is not the best in terms of user friendliness. We wanted to integrate OmbuShop with AFIP (using their API) in order to generate and print the bills for each seller. Unfortunately, there is no way to do this because the API doesn’t generate a printable version (PDF) of the bill.

At OmbuLabs we are big fans and happy customers of Noko. We use their widget to track all the hours that we spend on client projects, open source development, and our own products.

Today I’m happy to introduce Pecas, time tracking leaderboards for Noko! Pecas is an open source tool that integrates with your account and generates beautiful leaderboards per project and per teammate.

Here is a sample dashboard for all your projects:

On top of that, it will send you an email alert if you haven’t tracked any hours during a work day. If it’s a holiday, it won’t bother you. :)

I’ve always been a big fan of scratching your own itch. My latest itch was the insane amount of parking violations that I see everyday in Buenos Aires, near our office.

We decided to build a simple tool that would allow anyone with a Twitter account to report a parking violation. All you need to do is submit a geolocated tweet and a couple of photos (as evidence!)

Here is an example:

Ah, ¿no se puede estacionar en paradas de colectivo? Ya fueee... #InfractoresBA pic.twitter.com/XXmu1pdAib

— E r n e s t o (@_nesto) April 18, 2016

You can check out this tool over here: http://www.infractoresba.com.ar

This page shows all the parking violations reported by users to @InfractoresBA or with the #InfractoresBA hashtag. It’s as simple as that.

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

Last Wednesday I gave a lightning talk about open source at the Buenos Aires Ruby Meetup. I proposed a challenge to all attendees: Contribute to one (or many) open source projects for 7 days straight.

The rules are simple:

• You have to do it for 7 days straight
• If you can’t do it one day, that breaks your streak
• When you break your streak, you have to start over from day 1