Posts with tag rails

Manipulating database.yml

This is the second in a series of posts on building powerful and resilient Rails application templates. In the previous post, we discussed parsing and emitting YAML files with comments. Today, we will be looking at manipulating the database.yml file’s AST.

Parsing and emitting database.yml

Recently, I have been working on Rails application templates. These are scripts that can be run with rails new to enhance or extend the setup of a new Rails application with a specific configuration. They can also be ran against existing Rails applications using rails app:template. So, they are a powerful tool for automating certain kinds of configuration, modification, and setup tasks. But, there are also many limitations and stumbling blocks to what you can do with them.

In this series, I will be sharing some of the things I have learned while working on these scripts. This post is about the difficulty of manipulating the database.yml file. Let’s jump into it.

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.

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?