Articles by Aysan Isayo

When we talk about building with AI, most of the attention goes to what’s new. Models, agent frameworks, protocols, and tools seem to appear every week, making it easy to assume that adopting AI means introducing an entirely new technology stack.

But Rails developers already have many of the building blocks needed to create useful AI-assisted workflows. Generators, Rake tasks, command-line interfaces, schemas, tests, and APIs were designed to make software easier to work with by providing structure and predictable behavior. Those same qualities make them well suited for AI coding tools.

In this context, an AI-assisted workflow doesn’t mean building an agent into a Rails application. It can be as simple as a developer using an AI coding tool to complete a task in an existing codebase, whether that’s adding a feature, running tests, analyzing technical debt, or helping with a Rails upgrade. As these tools become capable of taking more actions on a developer’s behalf, they need reliable ways to interact with the codebase and the tooling around it.

This article explores how existing Ruby and Rails tooling can become part of AI-assisted development, and why introducing AI doesn’t require starting from scratch.

At OmbuLabs.ai, we’ve explored the importance of identifying meaningful AI opportunities opens a new window before selecting a solution. Once a worthwhile opportunity has been identified, however, a new question emerges:

Is this problem worth solving in the first place?

Too often, teams focus on the technology before evaluating the value. AI can automate tasks, generate content, and process information at incredible speed, but if the underlying work doesn’t matter, making it faster won’t create meaningful business outcomes.

Once a worthwhile opportunity has been identified, however, a new question emerges:

What should we build first?

Waiting over an hour for a test suite to finish is a productivity killer.

On a recent project, that was our reality.

Running the full local RSpec suite took almost 2 hours, making it difficult to get quick feedback and confidently iterate on changes. While there are many ways to optimize test performance opens a new window including fixtures, request stubbing, faster tooling, and more, most of these options require significant effort to implement.

Instead, we explored a simpler approach: bringing parallel test execution to local development. The result was a much faster feedback loop (down to 5 minutes) and a significantly better developer experience.

This article is part of our Upgrade Rails series. To see more of them, click here opens a new window .

This article will cover the most important aspects that you need to know to get your Ruby on Rails opens a new window application from version 8.0 opens a new window to version 8.1 opens a new window .

At our company, we believe the tools we use should reflect our values: simplicity, speed, and transparency. That’s why we use Jekyll opens a new window , a static site generator built in Ruby, to power our blog.

While there are countless blogging platforms and content management systems available today, from WordPress to headless CMS options, we chose Jekyll because it gives us full control, minimal complexity, and a workflow that fits seamlessly into how we already work as developers.

Here’s why we think it’s the right fit for us (and maybe for you too):

Whether you’re debugging a dependency issue, checking for an optional gem, or just curious about what’s loaded in your Ruby app, there’s a handy command that can help:

puts Gem.loaded_specs.keys.grep(/your_pattern_here/)

In this article, we will discuss what this command does, what exactly it’s checking for, and its limitations.

In earlier versions of Elasticsearch, types were a convenient way to categorically organize documents within a single index. However, types were eventually deprecated, pushing developers toward a type-less structure in Elasticsearch 7 and later versions. Recently while working on a project to migrate a Rails application from Elasticsearch 2 to OpenSearch 2, we faced the challenge of identifying a way to replicate this behavior in a way that is allowed with OpenSearch. In this blog we will discuss how types were used for document organization and how to achieve the same behavior in OpenSearch.

This article is part of our Upgrade Rails series. To see more of them, click here opens a new window .

This article will cover the most important aspects that you need to know to get your Ruby on Rails opens a new window application from version 7.2 opens a new window to version 8.0 opens a new window .

Ruby on Rails has a new maintenance policy opens a new window and it can be a bit confusing as to what it means for both new and existing Rails projects. In this blog, we are going to summarize all the details, changes and important dates to help your team plan your next upgrade.

Let’s take a look!

This article is part of our Upgrade Rails series. To see more of them, click here opens a new window .

This article will cover the most important aspects that you need to know to get your Ruby on Rails opens a new window application from version 7.1 opens a new window to version 7.2 opens a new window .

In a previous blog post, How Do You Know When Your App is Not Compliant? opens a new window , I briefly discussed the importance of the accessibility standards of Web Content Accessibility Guidelines or WCAG opens a new window , to ensure that everyone, including those with disabilities, can use web applications effectively. In this blog, we are going to further explore the importance of maintaining accessibility compliance, what it means to users, as well as how to use the axe-core-gems opens a new window for automated accessibility testing to help identify and resolve any gaps that may be currently present in a project.

In software development, there are instances where creating a long-running branch when working on a project will be considered by developers. Long-running branches have been debated a lot by many teams due to their risks mainly around but not limited to, dare I say it, merge conflicts.

However, it isn’t necessarily the evil it’s made out to be and when handled with care, they can present extreme value to a team. Even DHH argues the benefits of maintaining a ‘cohesive architecture’ in this article opens a new window

Ensuring that your company’s website is current with compliance standards is extremely important and essential for any Rails application. Operating with a compliant application guarantees security that can help with handling sensitive data and maintaining users’ trust. The more compliant your website is, the more secure it will be against data breaches, which helps users feel safe when they’re using it.

So what does it take to be compliant? In this article, we will focus on security and cover some indicators to help identify if your Rails app might not be compliant anymore.

Every year, Ruby enthusiasts anticipate the December release of a new Ruby version. At the end of 2023, Ruby 3.3 was released and you can read this article opens a new window to learn more about the new features and improvements it brings. This makes it a good time to start considering if your application is due for an upgrade.

Upgrading your application can sound complicated and difficult, but it doesn’t have to be. Below, we will discuss how to identify when to upgrade your Ruby version and the steps necessary to complete a smooth and successful upgrade.

One of our biggest goals as a company is to aim for transparency and honesty when evaluating a project for an upgrade. We understand that the decision to hire an outside vendor versus doing it in house becomes a difficult one. To provide confidence and a clear path to completing an upgrade, before we even begin a project we invest time in doing a thorough investigation of the project to provide the most accurate and detailed game plan for an upgrade.

In this blog, we are going to break down our Roadmap service and explain how it can be used to guide you and your team to making decisions when it comes to upgrading your application.

Recently, while working on a Rails 6.1 to 7.0 upgrade, we encountered the following deprecation warning regarding changes made to ActiveRecord::Relation’s merge method:

"Merging (#{node.to_sql}) and (#{ref.to_sql}) no longer maintains both conditions, and will be replaced by the latter in Rails 7.0. To migrate to Rails 7.0's behavior, use relation.merge(other, rewhere: true)."

In this article, we will talk about the expected behavior of merge, how it has changed and what to do in order to use the new behavior if you find yourself looking at this deprecation.

Recently I got to work on a task that included understanding how to test JavaScript requests with RSpec opens a new window . One thing that I found missing during my time researching solutions was organized and detailed documentation explaining the solutions based on the version of Rails opens a new window and RSpec the application runs on.

As of May 1st, 2023, Heroku will no longer be supporting the Heroku-18 stack. The reason for this deprecation is to maintain synchronization with the Ubuntu Long Term Support releases. If you are currently running your Rails application on this stack, when you navigate to the Heroku dashboard you will notice a warning to upgrade to either Heroku-20 or Heroku-22 before the end of the Heroku-18 stack life on April 30th, 2023.

While Heroku-18 will not be supported, do not be alarmed or concerned that the apps running on this stack will stop working. Heroku has confirmed that all existing applications will not be interrupted and non-build functionality will still be available. However, to maintain access to security updates, technical support and the ability to perform new builds, an upgrade will be necessary and is highly recommended.