-
Using expect to tailor environment
I recently learned to leverage
expect
. According to the man pages it is:expect - programmed dialogue with interactive programs
I often need to
ssh
into remote hosts that both are ephemeral and I don’t have much control over. Any environment customization that I do is one-time only, because odds are that next time I connect, it will be to a different host. Yet, I’d like to be in a familiar environment. That is whereexpect
comes in.expect
provides a DSL of sorts to interactively use programs in the command line. I use it to frontssh
and do a few common tasks every time I log in:#!/usr/bin/env expect # Front ssh and automate env settings once on remote machine set environment [lindex $argv 0]; spawn ssh $environment expect "\$ " { send ". entry.sh" send -- "alias db_replica='psql ..." send -- "\n" send -- "export EDITOR=nano" send -- "\n" expect "\$ " { interact } }
That script:
- Reads the first argument to it and sets to a local variable named “environment”.
- Starts an instance (
spawn
) ofssh
, passing the value of environment to it. - It then waits (
expect
) until it reads a$
- It
send
s a few commands to source a file, create an alias, export a variable, etc. - It then
expect
s another prompt and starts and switches to interactive mode (interact
)
That last steps is what “drops” me into the terminal in the remote host, personalized with my taste.
This is just the proverbial tip of the iceberg. The expect manual has a lot more information.
-
The REPL: Issue 120 - August 2024
Structure Your ERb and Partials for more Maintainable Front-end Code in Rails
Interesting exploration of how to write better ERB views in Rails. One the one hand, adding ERB tags and interspersed Ruby code in HTML is not optimal. On the other extreme, is generating everything in Ruby with
tag
helpers, which is also less than optimal. No matter where you land, it seems that one needs to know both HTML, ERB and some Ruby DSL to write views, with an eye to what HTML will be generated.actual_db_schema: Wipe out inconsistent DB and schema.rb when switching branches
Interesting library. It attempts to solve the issue of jumping between multiple branches in Rails code bases and the DB schema getting out of sync. I have not used it, and can’t say that I’ve struggled much with this problem. What I do struggle with is
structure.sql
conflicts of different branches all wanting to insert their migration number in the same spot. -
The REPL: Issue 119 - July 2024
Entering text in the terminal is complicated
Most of the things that I associate with “usable” CLIs actually comes from
readline
. TIL that you can wrap anything with readline!rlwrap nc
. It doesn’t seem to be installed on my Mac, by default though.PostgreSQL INSTEAD OF Triggers
I’ve been working with Postgres triggers recently. They are immensely powerful, but I find the syntax hard to get used to, and the manual has limited examples. In particular this tutorial shows a use of
RETURNING ... INTO
to put a value into a variable that made it much easier to achieve what I wanted, instead of a chain of CTEs withINSERT INTO
that was becoming unwieldy.Event sourcing for smooth brains: building a basic event-driven system in Rails
I don’t consider what this article described to be event sourcing. It’s a light event system in Rails, which is great, but not exactly event sourcing.
In event sourcing (as understood by most of the literature), the event records are the source of truth, and by “applying” those events you get the current state of the system. What they describe is not that. The system in the article has events and subscribers that act on those events, and the state of the system is maintained separately from the events.
In trying to simplify, they threw out some of what the event sourcing typically consider the most useful parts. Basically, they kept a pub/sub system hooked into
after_commit
hooks. Useful, but not what is described on the tin. -
The REPL: Issue 118 - June 2024
Better Know A Ruby Thing: On The Use of Private Methods
Noel Rappin writes thoughtfully about private methods. I actually approach writing classes in the opposite way that he does, and I also do it because of past experience. I currently work on a smallish team, but I used to work on a team that had ~200 engineers committing to the same monolith. Effectively, the cost of writing public-by-default methods was essentially the same as maintaining a library: It wasn’t clear to me who would use my class, when, or how. My approach is private-by-default: Make the API as small as possible.
If, in fact, there is a future need to re-use some abstraction that is currently used in a private method, I am happy to refactor later and make that functionality available purposefully.
Inline RBS type declaration
Experimental syntax, but this mode of type declarations are something I can get on board with!
Since it’s using
#::
and# @rbs
as special comments, they can probably be recognized by syntax highlighters and other tooling.Lesser Known Rails Helpers to Write Cleaner View Code
I’ve been writing Rails for over 12 years, and some of these are new to me! I wonder if I’ll remember that they exist next time I have opportunity to use them!
-
The REPL: Issue 117 - May 2024
Why PostgreSQL Is the Bedrock for the Future of Data
The take is not exactly surprising, since Timescale is all-in on Postgres, and the last part of the article feels a bit like an ad. That said, Postgres is fantastic and getting better with each release.
Free Yourself, Build the Future, Embrace PostgreSQL
Why, after 6 years, I’m over GraphQL
Well reasoned critique of GraphQL, with practical examples of the issues of working with GraphQL. Instead, the author wants to keep the strict typing, but go back to REST endpoints.
(Bi)Temporal Tables, PostgreSQL and SQL Standard
This is exciting! The article says that temporal support (and later bi-temporal support) is coming natively to Postgres! That is welcome news! I am excited to learn how will temporal modeling be supported and how can Rails (and other) frameworks can take advantage of it.