OmbuLabs Blog

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 strongly believe in continuous improvement.

As a Scrum team, before starting a sprint we estimate the complexity of the stories using the Fibonacci scale. But how do we become better at estimating stories? How do we know we’re evolving as a team?

In this article I outline the process we are following to become better estimators.

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.

Here at OmbuLabs, we do a lot of work with older versions of Ruby and Rails. Recently, I’ve been taking a look at Docker, the virtual container platform, to see how it might help us manage the often idiosyncratic setup that applications we work with might require.

When a new team member comes onboard, there are several tools and resources they need to access, as well as processes, practices and guidelines they need to be aware of. There is also workflow and company culture information you want to communicate. After all, each company has its unique features and you want new team members to be comfortable with the existing team.

For remote teams, this process can be very challenging. Thankfully, if you use Slack, you can use their Workflows feature to easily onboard new team members, making the process actionable and easy to follow.

In this article I’ll describe how I used Slack Workflows to make the onboarding process here at OmbuLabs quick and easy.

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.

At OmbuLabs we use Jekyll to generate our blog. If you are not familiar with it, here is a quick description from the Jekyll site:

“Jekyll is a simple, extendable, static site generator. You give it text written in your favorite markup language and it churns through layouts to create a static website. Throughout that process you can tweak how you want the site URLs to look, what data gets displayed in the layout, and more.”

Different clients bring different projects, perspectives, workflows, and experiences, as well as different challenges. Before starting a project, one of those challenges is to define who will be the Product Owner.

Ideally, you would be able to assign the role internally or to the client based solely on the characteristics of the project. However, that’s not always the case. It might just be that the client insists on being the Product Owner or that you are a small team and can’t really assign the role internally. Whatever the reason, you might end up in a situation where your client isn’t really a good Product Owner.

Here I’ll share some strategies we implement to help our clients become better Product Owners and ensure the best experience for them and for our team.

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.

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.