Posts with tag ruby

Introducing Solid Errors

Solid Errors is a Rails engine that provides a dashboard for viewing and resolving exceptions in your Rails application without the need for an external 3^rd party service. With version 0.3.0, I am happy to announce that Solid Errors is now ready for production use.

Rails security quick wins

I recently launched a major new feature for an application I maintain at $dayjob, and I needed to ensure that the application followed current basic security best practices. It took me a couple of hours to track everything down, so I thought I would document it here for future reference. So, let’s dig into some quick wins for Rails security.

Rails engine migration generator with support for multiple databases

Rails supports multiple databases. This means you can specify which database to point a migration at when you use a generator (e.g. bin/rails generate migration CreateDogs name:string --database animals). For gems, when you are creating a Rails engine, you will often need to create some tables, so you register a generator to install the migrations (e.g. bin/rails generate my_gem:install). I want to ensure that the generator I am providing from my engine/gem allows the user to specify a specific database, and my gem respects that. With the help of some folks from Twitter, I figured out the requirements.

Non-blocking timeout

Last month I released version 0.4.0 of the activerecord-enhancedsqlite3-adapter gem, which added support for a non-blocking busy_timeout to the SQLite adapter in Rails. As with all of my lower-level SQLite work, the goal is always to push these solutions into the foundations of the ecosystem so that everyone can benefit from them. In this case, I’m happy that the busy_timeout feature has made its way into the sqlite3 gem, which is the most popular SQLite gem for Ruby.

SQLite Quick Tip: Multiple Databases

When building a full-featured Rails application, you will want not just a database to store your model data; you will want a job queue backend, a cache backend, maybe even a pubsub backend. When building a Rails app leveraging the power and simplicity of SQLite, you will likely wonder how best to architect these various services? 37signals has been releasing new gems to use solid-state storage via relational databases. They default to using one database to back all of these services, but they use MySQL. How should we handle this with SQLite?

Installing extensions

In a previous post, we discussed how to load SQLite extensions distributed as Ruby gems into a Ruby on Rails application. Unfortunately, there aren’t many SQLite extensions that are distributed as Ruby gems. So, in this post, we dig into how to install a wider range of SQLite extensions into our apps.

How (and why) to run SQLite in production: RubyConf Taiwan 2023

Prefixed ULID keys

I have written previously about using custom primary keys for your Rails app when using SQLite. In this post, I want to show how you can use the same sqlite-ulid extension to create prefixed ULIDs. Shout-out to Andy Stewart who suggested this.

Introducing litestream-ruby

I have already detailed why Litestream is essential for SQLite on Rails applications. But, as that original post makes clear, getting this utility setup and working in production requires some systems administration. Rails applications deserve better. Thus, litestream-ruby.

Improving concurrency

Two months ago I released the activerecord-enhancedsqlite3-adapter gem, which adds a number of enhancements to the SQLite3Adapter for ActiveRecord. Today I am releasing version 0.4.0 of the gem, which allows your Rails application to work in Puma’s clustered mode with multiple workers without getting those dreaded database deadlock errors.