Posts with tag ruby

Update to Litestream gem

Version 0.5.1 of the Litestream is out. The 0.5.x versions of the gem adds a new restore command along with some useful introspection commands, making it simple to restore a database from a remote backup. This is a huge feature that makes Litestream even more useful.

The how and why of optimal performance

Update to Solid Errors

Version 0.4.2 of Solid Errors is out. The 0.4.x versions of the gem adds a number of awesome new features, most notably email notifications. If you need a self-hosted error tracking solution for your Rails application, Solid Errors is a great choice.

Isolated connection pools

If you want to squeeze as much performance out of your SQLite on Rails application, at some point you will need to confront the problem of writes saturating your connection pool. Let’s dig into this problem and how to solve it with some clever usage of Rails’ multi-database support.

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.