OmbuLabs Blog

Large Language Models (LLMs) are widely available and easily accessible and are increasingly a part of business. Whether you’re interacting with an LLM via the provided interface or connecting via an API and integrating it into other systems, it’s helpful to understand how to get the best possible results out of the model.

Prompt Engineering is a technique that focuses on perfecting your input to get the best possible output out of the language model. Of all the different techniques available to get LLMs to fit your use case best, it’s the most straightforward one to implement since it focuses primarily on improving the content of the input. In this Part I article, we’ll dive into different Prompt Engineering techniques and how to leverage them to write highly effective prompts, focusing on single prompt and chain techniques. In our following article, we’ll cover agents and multi-modal techniques.

For other available techniques to enhance LLM capabilities, check out our Techniques to Enhance the Capabilities of LLMs for your Specific Use Case article!

New to LLMs? Check out this article on the landscape by our friends over at Shift: Guest Post: Navigating the AI Chatbot Landscape.

With the advent of widely available Large Language Models (LLMs), businesses everywhere have sought to leverage these models to handle specific tasks that can increase productivity of their teams, automate specific tasks, increase the abilities of chat bots, among a variety of other things.

However, LLMs are not great at handling domain-specific tasks out of the box. In this article, we’ll explore a few different techniques to enhance the capabilities of LLMs and help them perform well for your specific use case.

We often partner with our friends at Shift Interactive when we need an extra set of hands or expertise to complement our own. Recently we’ve been collaborating with them on interesting Artificial Intelligence and Machine Learning things. Check out their recent blog post below or here to get an overview of the AI chatbot landscape.

You can also check out the next article in this series: Techniques to Enhance the Capabilities of LLMs for your Specific Use Case.

Welcome to the third article in our Machine Learning with Ruby series!

In our previous article Machine Learning: An Introduction to CART Decision Trees in Ruby, we covered CART decision trees and built a simple tree of our own. We then looked into our first ensemble model technique, Random Forests, in Machine Learning: An Introduction to Random Forests. It is a good idea to review that article before diving into this one.

Random Forests are great for a wide variety of cases, but there are also situations where they don’t perform quite as well. In this article we’ll take a look at another popular tree-based ensemble model: Gradient Boosting.

In our previous article Machine Learning: An Introduction to CART Decision Trees in Ruby, we covered CART decision trees and built a simple tree of our own. Decision trees are very flexible and are a good tool for simple classification, but they are often not enough when it comes to real-world scenarios.

When dealing with large and complex data, or when dealing with data with a significant amount of noise, we need something more powerful. That’s where ensemble models come into play. Ensemble models combine a number of weak learners to build a strong model, with increased accuracy and robustness. Ensembles also help manage and reduce bias and overfitting.

In this article, we’ll cover a very popular tree-based ensemble model: Random Forest.

In our previous article, Machine Learning Aided Time Tracking Review: A Business Case we introduced the business case behind Pecas, an internal tool designed to help us analyse and classify time tracking entries as valid or invalid.

This series will walk through the process of shaping the original problem as a machine learning problem and building the Pecas machine learning model and the Slackbot that makes its connection with Slack.

In this first article, we’ll talk through shaping the problem as a machine learning problem and gathering the data available to analyse and process.

In the middle of last year, we released an internal tool to help address a pretty significant issue. That is how the Pecas tool was born, and you can read about the Business Case for Pecas here.

Pecas relies on a binary classification machine learning model to classify time entries as valid or invalid. It is a combination of a Django app, that hosts the Slackbot and other data processing tasks, and a FastAPI app that hosts the machine learning model built using the Scikit-learn Python library. Scikit-learn provides a great set of classification models you can use, which are optimized and very robust, making it a solid choice to build your model. However, understanding the principles behind the classification can be a bit tricky, and machine learning models can feel a bit like a black box.

In this series, we’ll explore some principles of machine learning, namely binary classifiers, and walk through how they connect to each other, in Ruby. This article will focus on decision trees, namely CART (Classification And Regression Trees) and a little bit of the mathematics behind them.

As an agency, our business model revolves around time. Our client activities rely on a dedicated number of hours per week worked on a project, and our internal activities follow the same pattern. As such, time tracking is a vital part of our work. Ensuring time is tracked correctly, and time entries meet a minimum quality standard, allows us to be more data-driven in our decisions, provide detailed invoices to our clients and better manage our own projects and initiatives.

Despite being a core activity, we had been having several issues with it not being completed or not being completed properly. A report we ran at the end of 2022 showed our time tracking issues were actually quite severe. We lost approximately one million dollars in 2022 due to time tracking issues that led to decisions made on poor data. It was imperative that we solved the problem.

To help with this issue, we created an evolution of our Pecas project. We turned Pecas into a machine learning powered application capable of alerting users of issues in their time entries. In this article, we’ll talk though the business case behind it and expected benefits to our company.

Google Cloud Platform (GCP) can be a very good option for Airflow and, although it offers its own managed deployment of Airflow, Cloud Composer, managing our own deployment gives us more granular control over the underlying infrastructure, impacting choices such as what Python version to run and even when to upgrade Airflow itself.

The Airflow community maintains a Helm chart for Airflow deployment on a Kubernetes cluster. The Helm chart comes with a lot of resources, as it contains a full Airflow deployment with all the capabilities. We didn’t need all of that, and we wanted granular control over the infrastructure. Therefore, we chose not to use Helm, although it provides a very good starting point for the configuration.

As a company, we are committed to ensuring our client’s success and believe that maintaining strong relationships with the people who trust us with their projects is a driving force of success. One of our core values is, in fact, Continuous Improvement, and we make an effort to live it every day.

In that spirit, we are excited to announce a new role in our organization, the Account Advocate, a key role in our team fully dedicated to championing client interests, collaboration and ensuring successful partnerships that go above and beyond.

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!

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:

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.

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.

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.

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.

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.

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.

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!