Posts with tag ruby

Array columns

One of the reasons people hesitate to use SQLite in their Ruby on Rails applications, in my opinion, is a fear that they will miss certain features they are accustomed to from PostgeSQL or MySQL. As discussed in an earlier post, we can load SQLite extensions into our Rails applications to enhance the functionality of SQLite. Moreover, today I want to show you that it is possible to build on top of SQLite’s primitives to provide matching behavior for one of my favorite features of Postgres—array columns.

Optimizing compilation

This is the next in a collection of posts on how to enhance SQLite in order to power up our Ruby on Rails applications. In this post, we dig into how to tune SQLite at compile-time to better support production usage in a web application. This is a close companion to a previous post on optimizing the run-time configuration of a SQLite database.

Setting up Litestream

This is the next in a collection of posts where I want to highlight ways we can use SQLite as the database engine for our Rails applications without giving up key features or power. In this post, I want to discuss one of the most often discussed disadvantages of SQLite—disaster recovery—and how to address it.

Loading extensions

Once again we are enhancing our Ruby on Rails applications to power up SQLite. In this post, we dig into how to load extensions into our SQLite database.

Fine-tuning your database

This is the next in a collection of posts where I want to highlight ways we can enhance our Ruby on Rails applications to take advantage of and empower using SQLite as the database engine for our Rails applications. In this post, we dig into how to tune the SQLite configuration to better support production usage in a web application.

Linked headings in your BridgetownRB site

BridgetownRB is a powerful and flexible “progressive site generator” written in Ruby. I use it to publish this blog. One feature that I wanted to support with my blog is having headings that provide a quick anchor link to that section of the page. In this post, I want to walk you through the simple steps to add this feature to a Bridgetown site.

Branch-specific databases

This is the first in a collection of posts where I want to highlight ways we can enhance our Ruby on Rails applications. Specifically, in this first series, I want to dig into the ways that we can take advantage of and empower using SQLite as the database engine for our Rails applications. In this inaugural post, let’s dig into how using SQLite as our database engine opens up powerful new possibilities for our local development workflow; specifically, allowing us to have and use branch-specific databases.

Generating Hex-ULIDs in Ruby

In the previous post, we explored how to generate a base16-encoded ULIDs with only native SQLite functions. In the end, we built an expression that will generate hex-ULIDs for us:

SELECT PRINTF('%012X', CAST(ROUND((JULIANDAY('now') - 2440587.5)*86400000) AS INTEGER)) | HEX(RANDOMBLOB(10)) AS qulid;
SELECT PRINTF('%012X', CAST(ROUND((JULIANDAY('now') - 2440587.5)*86400000) AS INTEGER)) | HEX(RANDOMBLOB(10)) AS qulid;

This expression will return a 32 character string like 0184E14B9D33DF0EA40E00D20FC31406, which encodes a 48 bit timestamp and an 80 bit random portion, producing a 128 bit blob just like ULIDs and UUIDs. The string is composed of an 12 character base16-encoded timestamp and a 20 character random portion.

But what if we need to generate a hex-ULID in Ruby?

Handling variables

The third in a series of posts laying out the process, step by step, of building an interpreter in Ruby for working with propositional logic. In this post, we expand the interpreter to work with variable expressions in classical propositional logic, like ~p & q. Since we are dealing with variable expressions and not fixed expressions (like ~T & F), we need to be able to output full truth tables, and not simply resolve the final boolean output.

Rails Forms and Request Parameters

Sometimes in our Rails applications we need to build forms that represent state stored in URL query parameters that is independent of any persisted object in our backend datastore, like in the case of a search form. In this post I offer a simple, flexible, generic helper for doing just that.