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 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.

When it comes to improving application performance and areas to focus on, I would recommend looking at the APM data, and then deciding which areas to prioritize.

However this article isn’t about where to focus efforts, but rather a compilation of techniques to improve your application’s performance, from tackling common problems like N+1 queries and database indexing to leveraging the jemalloc memory allocator. Let’s look at these performance-boosting strategies designed to fine-tune your application.

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 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.

Late last year our team members headed to beautiful San Diego to join the incredible Ruby community at RubyConf 2023. Attending the conference is always a highlight, and we were excited to participate as a sponsor and engage with attendees, learn and share expertise, and have some fun.

The Ruby community is special. It has an incredibly inclusive and supportive culture that feels different than other languages. It was great to take some time to come together and enjoy the community’s hard work, network, and plan for the future.

Here at FastRuby.io we always try to have our own applications in such a state that they can always be pointed to as models in terms of performance and accessibility.

One of the tools we use to achieve that is our CDN. After all, considering we have clients everywhere from the US to New Zealand, we want anyone perusing our websites to have good loading times for the pages and, especially, the assets.

However, no matter how thorough, one always misses a spot or two.

Security is a huge concern for web applications. To protect your Rails app from potential vulnerabilities and threats, it’s essential to perform regular security assessments. Brakeman, a widely used static analysis tool for Ruby on Rails, can help you identify security vulnerabilities proactively.

In this article, we’ll explore how to use Brakeman to check your Rails app for security vulnerabilities.

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.

Recently, Robby Russel posted posted on Twitter asking for Heroku alternatives for small Rails apps. Since it got quite a bit of traction, I decided to explore some options and post my experiences as blog posts.

For my first post, I’ll go for one that I’ve already used in the past and liked it very much: Fly.io

I like them because they’re dead simple and have great docs. The dashboard is pretty good too, but since I’m not one to have too many requirements around my apps, the simplicity of use is what I like the most.

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.

By default, Ruby defines many constants and global variables that can be used in the code to get information about the current state of the application and the runtime. In this article we’ll go over most of them to understand what they are and what information we can set and get to simplify our scripts or to debug problems.