OmbuLabs Blog

Over the last few months, we developed a couple of Snap Minis. Minis are small static web apps that are run inside a webview within the Snapchat native app.

One important part of the development was to make sure our Mini works well across different devices, especially making sure things work the same in both Android’s webview (Chrome by default) and iOS’s webview (Safari).

In this post I’ll talk about a few things to keep in mind when working with the Snap Canvas SDK and in the next one I’ll talk about some common and known issues you’ll encounter when making your app cross-mobile-browser compatible.

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!

As a software consulting company, we bill for the time we work on client projects. So it is vital for us to keep track of the time we put into every task. We’ve had some trouble over the years with our time tracking, and sometimes that led us to work more time than what we finally billed for. We would like to share some of the experience we have collected over the years and the tools that we currently use.

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.

At OmbuLabs we use Tettra to power our knowledge base. As a remote, distributed team it is very important to us to have our content structured and organized. We follow some good practices to keep it organized and up to date, which we describe here, and we use Tettra to keep our knowledge organized and integrated with the tools we use on a daily basis.

As a distributed, remote team we use different tools to communicate at OmbuLabs, like Slack and Zoom. Those are great for live communication. But every company has information that needs to be kept and stored somewhere. In our case, we started off using the GitHub Wiki and Google Docs. However, documentation and policies need to be maintained, updated and checked regularly. And having information scattered in different tools, formats and accounts became a hassle.

That’s where a knowledge base comes in. At OmbuLabs we use Tettra and we will share our experience in a different article. But regardless of what tool you choose, here are some practices that will help you keep your knowledge base organized and updated.

The discussion around the use of problematic words / terms in technology isn’t a new one. This issue can be traced back to, at least, 2003 when a Los Angeles county worker filed a complaint with the city’s Office of Affirmative Action Compliance after seeing “master” and “slave” in computer equipment labels.

This issue has resurfaced with recent events and, at OmbuLabs, we believe it is important to take it seriously. It is past time to remove this metaphor from our codebase and review some of the terminology we use. We have started taking the necessary steps to rename “master” branches to “main”, as well as (and perhaps more importantly) remove any reference to the term “slave” and replace “whitelist / blacklist” with “allowlist / blocklist”. Our team is actively working on that.

But we understand that is not enough. This is not an action that will solve racism by itself. It’s part of a larger commitment. In this article, I’ll explain the context and motivation for this change and how it fits with our core values and long term vision as a company.

Last month, Snap announced a new product during the Snap Partner Summit 2020, Snap Minis. Minis are bite-sized third-party experiences that live inside of Snapchat and can be accessed through Snapchat’s Chat interface. They’re built on the same principles and technology as Snap Games and are easy to develop, allowing you to build an experience that is available to Snapchat users worldwide.

OmbuLabs recently developed a Snap Mini for one of our clients. In this article, I’ll share the main advantages of launching a Snap Mini and how we can help you get started:

Code Review is one of the greatest tools we have as software developers to help us improve the quality of our code. It can be incredibly beneficial, but it can also be a source of pain, frustration, and overall, a waste of time instead of a time-saver.

Because of that, a while ago we wrote these code review tips that should be acknowledged and incorporated by everyone in our team and now we want to share them with you.

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.

We, Ruby developers, are used to running scripts or commands with the prefix bundle exec, but sometimes it’s not needed, but sometimes it is, and when it’s not needed it still works just fine if we add it. So it may not be clear why we need to use it in some cases.

In this blogpost I’ll try to answer these questions with a little insight on what Bundler (and Ruby and Rubygems) do.

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.

As a remote team, we work and communicate asynchronously a lot of the time. Additionally, as a software agency, we work not only on client projects but also internal projects related to various aspects of the company. This means we will have stories and pull requests opened accross different internal projects at all times and it is important that everyone is on the same page when it comes to what needs their attention and what the next steps are.

We have shared more information on how we use Pivotal Tracker here. We also like to use GitHub to its full potential. Therefore, we needed a standardized workflow that would take into account how we use both these tools and ensure everybody on the team knows what is going on by looking at a Pivotal Tracker board or a list of open Pull Requests.

In this article, I will walk you through the workflow we created for our team. You can find a flowchart representation of the workflow here.

Since starting at OmbuLabs as the Junior Developer I have had the incredible opportunity to pair with my teammates. A lot. Over the months we have begun to develop better practices and routines to make the most of our pairing sessions, and now I would like to share some of our practices and tips for making a pairing session successful. At OmbuLabs we are a fully remote company so all of our pairing sessions are done through Tuple or Zoom, but this advice could translate easily to in person sessions as well.

One of the most fundamental tasks when writing or refactoring software of any kind is breaking the problem down into smaller parts. When you’re first starting out - and even as you continue to gain experience - figuring out what those parts should be, and where they should live within a codebase can be a daunting task. Design patterns and principles can help, but trying to keep them in mind as you design and implement solutions can be overwhelming.

Thankfully, there’s a pair of principles that can cut many of these gordian knots, and render decision making much clearer, simpler, and easier to articulate to others. Understanding and using the concepts of coupling and cohesion to guide my design and refactoring decisions yielded immediate results for me.