Ruby on Rails is currently in major version 7.1 and rolling towards Rails 8, the next comprehensive new release. Before Rails 8, though, there’s a significant version that will help bridge the gap: Ruby on Rails 7.2. In this post, we’ll dive into several noteworthy changes in Ruby on Rails 7.2, focusing on the support for database changes in Active Record. You'll come away with hands-on opportunities to work with these features. Let's get started!

From custom-made to plug-and-play forms of authentication, Ruby developers have plenty to choose from these days. Yet, as you may know, building your own solution can be costly and dangerous. If Devise is the de facto standard for most teams, an alternative might simplify the lives of most. This article will cover the setup and use of Auth0 in a Ruby on Rails application, including everything you need to get going properly, from handling roles to relying on multiple providers to authenticate users.

Check out Scout Monitoring's ollama-rails GitHub repo for samples on how to use ollama-ai to communicate with Ollama. Large Language Models (LLMs) have emerged as a game-changer, enabling machines to understand, generate, and process human language with unprecedented accuracy and fluency. One such tool that has gained significant attention is Ollama, a cutting-edge platform that allows developers to run LLMs locally without relying on cloud services.

Versioning APIs is a critical part of building web applications, as it allows you to make changes that may otherwise break existing API users. Changing the contract between the API and the clients that depend on it is dangerous, and versioning endpoints adds flexibility and safety. Versioning is implemented in many ways - You can version with subdomains, query parameters, URL schemas, headers, and more!

It's hard to overstate the importance of Cascading Style Sheets (CSS) for all websites. Since the first CSS standards were published in late 1996, we have come quite far regarding features and ecosystems. Several frameworks have appeared and proved popular, one of the most recent being Tailwind CSS. In this post, we'll first examine Tailwind's utility-first approach before diving into how to use it in a Ruby on Rails application.

APIs are the bread and butter of the internet. The ability to interact with our applications programmatically enables interoperability and makes our lives as developers easier. Unfortunately, web applications are vulnerable to malicious actors that seek to misuse them or degrade their performance, which is why rate limiting is an important part of any API.

Ruby on Rails has long been celebrated for its ‘convention over configuration’ philosophy, simplifying web development for countless programmers. However, what if you’ve started with a lean Rails API-only application and now find yourself needing a front-end? This isn’t uncommon, especially with the rise of JavaScript frameworks and SPAs.

Ruby on Rails has changed how we build web applications. Early on, the framework came with some great features to help you get started and build robust applications. However, it can still be tricky to build and handle forms. Simple Form is a great option. Let's examine what Simple Form is, why we might need it, and some real use cases.

Background jobs are essential to many Ruby on Rails apps. Since the introduction of ActiveJob, Rails developers have been able to manage their background jobs as natively as they do their database records. Still, ActiveJob requires you to select (and support) a backend adapter that will implement ActiveJob's backend. Many use Redis, a memory cache, to queue and process background jobs. Redis comes with incredible speed but is yet another dependency to maintain.