OmbuLabs Blog

Some time ago we wrote an article to explain how to implement Stripe Connect in a Rails application. That article covered mainly the connection part between Rails and Stripe. This one will cover the fun part, which is making transactions, charges, refunds, and more.

If you haven’t checked out the first part yet I recommend you do so since this article will continue from where that one ended.

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.

Service Objects are a controversial idea for several different reasons: some developers like to use them, others like to use similar patterns, and some think that they are just unnecessary because they prefer fat models.

Here at OmbuLabs we like to use service objects whenever we can, we think it’s a great way to keep our controllers skinny.

In this post I would like to discuss my idea about service objects and why it’s adopted by our team.

In a recent project for OmbuLabs, we had to integrate Bitrix24 (the tool that the client was using to administrate their business) with the Rails application that we were building for a client.

The goal of this integration was to sync data between the Rails app and the Bitrix CRM. Basically we wanted to pull data from Bitrix every time there was a change (i.e. Lead was created/updated). We also wanted to sync the other way around, push changes to Bitrix every time something changed on the Rails side.

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.

We have been a fully remote company for a year and a half now. Making the transition to being fully remote can be challenging for any team. During the past year and a half we have worked on making sure that our team is as productive, communicative and social as it was when we had a traditional office space. Here are some tips that we have found to be useful for remote teams:

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.

Everyone has had the experience of working on a gnarly, difficult to understand code-base. The sort of code base that makes you hate your job. Often it comes down to poor design, but code conventions also play a large part in whether you wake up dreading your job in the morning. The overall design (choice of design patterns and how modules and classes are organized and factored) is the long range, big picture strategy of how an application will be made. Code conventions, by contrast, come down to the choices you make about which constructs of a language you use, which you don’t, and when.

Out of all the problems an agency might face, “we have more opportunities than we can handle” is not something you’ll typically hear anyone complaining about. For those who are lucky enough to be in that position, it’s always thought of as being “a good problem to have.” But make no mistake, having more opportunities than you can handle can be a real problem. Aside from the obvious opportunity costs of all the work not taken, there are often good reasons why you may not be able to expand your permanent headcount just yet.

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.