In this post, we'll turn to the last piece of the puzzle in LiteStack: Litesearch. As an example, we will equip a prompts index page with a search bar to query a database for certain prompts. We will generate a couple of fake records to test our search functionality against. Let's get to it!

At Honeybadger, we use Ahoy for first-party analytics in Rails. Ahoy is excellent for developers because it lives in your Rails application alongside your other data and code. Want to answer a specific question about your product or website visitors? It's just one ActiveRecord query away: Ahoy also works with Chartkick and Groupdate to visualize your data.

In our last post, we looked at the basics of RSpec and explored how well it works with Behavior Driven Development in Ruby. Now, we will look at specific types of RSpec tests for different parts of a Ruby on Rails application. Let's dive straight in!

Reusable UI components are user interface widgets or elements that can be used in various places in a web project. These components are typically small and created for a specific functionality. Typically, you write the code once and then import the UI components wherever needed. For example, you can create a card component that displays certain information or have a navigation bar that will appear at the top of all web pages. Such UI elements can be imported and added to your desired web page.

In this series, we have looked at the "musts" (databases) and "shoulds" (asynchronous jobs, websockets) of a web application. Now we turn to one of the "coulds" (that is nonetheless recommended for scaling businesses): caching. In particular, we mean caching HTML fragments and other snippets of data, as referred to in Rails Guides. We are not concerned with HTTP or SQL query caching. In this part, we'll see how to speed up our Rails app using LiteCache.

Primary keys are vital in the design of a relational database. They are crucial in uniquely identifying records. For example, if you have a table of users, you will need to identify each record uniquely. This is where primary keys are used. Primary keys are usually single columns that auto-increment. There might be cases where you'll need a combination of column to serve as the primary key - this is where composite primary keys become helpful.

Ruby on Rails has always been at the forefront of developer productivity, and building robust, highly interactive web applications has never been easier. Rails has been accurately described as the one-person framework. However, building your app is only half the battle. The other half is publishing it for others to use. Unfortunately, being able to deploy your application has always been an afterthought for most developers.

So far in this series, we have been exploring the capabilities of SQLite for classic HTTP request/response type usage. In this post, we will push the boundary further by also using SQLite as a Pub/Sub adapter for ActionCable, i.e., WebSockets. This is no small feat: WebSocket adapters need to handle thousands of concurrent connections performantly.

When writing tests in Rails, you should avoid repetition and have the right amount of tests to satisfy your use case. This article will introduce you to shoulda-matchers with RSpec for testing functionality in Rails. At the end of the post, you should feel confident about using shoulda-matchers in your Rails application. Let's get going!

When working with money in an application, ensuring everything is accounted for is important. In this post, we will explore some common methods and best practices of handling money in your Ruby app, and see how you can use money-rails to write maintainable money-handling code. Let's get started!