A default Rails application is typically built with a relational database, such as PostgreSQL or MySQL, as its default data store. Building a Rails application with a NoSQL database can bring some benefits.

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.

With the Ruby 3.3.0 release around the corner, we wanted to share a summary of the changes that are coming in this new version. There are many exciting new features and improvements!

Whether you are working in a legacy Ruby application, or a brand new application, measuring your dependency freshness score can be a positive indicator to understand whether you are staying current or gradually falling out of date.

Dependency freshness is defined as the difference between the currently used version of a dependency and the version that the system would ideally use.

In this article, I will discuss a couple of ways to keep track of how outdated or how fresh your dependencies really are.

You just finished upgrading your app to the latest Rails version and you made the decision to never stay behind and always be ready to upgrade as soon as possible… But how can you do that?

In this article we’ll explain how the Dual-Boot technique can be used to test the app against Rails’ main branch, to catch problems and warnings before a new version is released.

One essential tool that we as software developers rely on is known as “test doubles.” These versatile components come in various forms, including dummies, fakes, stubs, spies, and mocks. However, like other power tools, they require careful handling to prevent unintended consequences.

In this post, we’ll explore the strategic use of test doubles at the boundaries of our application, harnessing their full potential while minimizing associated risks.

Most people and companies that we talk to about upgrades assume that we generally help organizations that need to migrate to the latest Rails version.

However, this isn’t necessarily the truth. Instead, we mostly perform Rails upgrades for companies who are all the way back on Rails 3 or 4. To give you a better understanding of how common it is for companies to be on much older versions, this is a general list of our statistics from the past few years.

• Rails 2.3 - 3.2: 5 - 15 upgrades
• Rails 3.2 - 4.2: ~40 upgrades
• Rails 4.2 - 5.2: ~40 upgrades
• Rails 5.2 - 6.1: ~10 upgrades
• Rails 6.1 - 7.1: ~10 upgrades

We generally work with a lot of large, well established companies, so how did these successful companies fall so far behind, and how can you help your company to never need to hire us?