OmbuLabs Blog

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.

In the first part of this series we talked about positional arguments, but there are more types. In this second part we’ll talk about keyword arguments.

Positional and keyword arguments share a lot of characteristics so we’ll split this article into similar sections, but there are some key differences we’ll touch on in each section.

Remote work is a growing reality. In the 21st century, we have distributed companies that work 100% remotely, with team members scattered around the world.

While remote work has its benefits - diversity in background and experiences, access to an immense talent pool, cut down office costs to name a few - it also brings its challenges. And the biggest one is communication.

There are several pieces of software that aim to facilitate communication in a remote work environment. At OmbuLabs, we use Slack for our day-to-day conversations and Zoom for our calls. However, as a remote team, we don’t get to meet our teammates face to face. We don’t have “water cooler” chats or as many opportunities for casual chats as an office environment.

So how can we bring our team closer together? How can we build that team spirit that comes from seeing everyone and talking about our casual, social lives? Well, last month we had a team retreat. And it was great.

Ruby is an object oriented language where everything is an object (even methods are objects of the class Method!), so everything we need to do is done by calling methods on objects. That also means that methods have to provide a lot of flexibility because they are used everywhere.

Ruby provides a lot of options to pass arguments to our methods, so we’ll make this topic a series so it’s not too long. We’ll split the options into different categories and then break down everything with some examples and/or use cases.

At OmbuLabs we have many values that have been key to our success. This is an article about the values that differentiate our company from the rest. We truly live and breathe our values throughout every part of our organization.

Every team member is expected to follow these values, especially when things get tough. This is a living document. We have been tweaking these values ever since starting the company.

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.