Today I learned that in docker-compose.yml, a variable interpolation with a default can be expressed as ${VAR1:-default value} like shell-style parameter expansion. With parameter expansion, you can do more than setting a default value such as modifying the parameter. However, the supported features in docker-compose.yml are limited to two of them: to set a default variable or to make the parameter mandatory.
Let’s define VAR_ALPHA with a default value for the example service.
While I was playing with act the other day, I found a tool called kind (Kubernetes in Docker) in that repository. With kind, Kubernetes clusters can easily be created in a Docker container.
According to the official document, being an alternative to Docker Compose out of scope for kind. That said, the home page also suggests kind may be used for “local development”.
kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.
Today I learned a MySQL term: online DDL.
The online DDL lets you alter tables efficiently, without making tables unavailable during the entire operation and exclusive table locks. The behavior of a DDL operation can be specified using the ALGORITHM and LOCK clauses. You don’t have to get overwhelmed by the mysterious terms. Actually, you may have used it before without knowing because MySQL will try to use it by default when you execute ordinary alter table statements.
Today I learned that when doing database-migration on Rails, change_table :#{table_name}, bulk: true let us combine multiple alter-table statements and it could reduce the cost of the whole alteration. That is, instead of executing multiple alter-table separately,
def change add_column :users, :first_name, :string, null: false add_column :users, :last_name, :string, null: false end we can run a single alter-table statement by change_table like as follows.
def change change_table :users, bulk: true do |t| t.column :first_name, :string, null: false t.column :last_name, :string, null: false end end However, why should we do that? What are the differences between them?
Today I learned that RSpec’s #to method takes the 2nd argument as its custom failing-message.
expect(actual_value).to eq(expected_value), message Let’s say we are going to test a JSON object. The following example expects a part of the JSON object response_json['eye_colour'] to be "blue".
require 'net/https' require 'uri' require 'json' RSpec.describe do example do response = Net::HTTP.get_response(URI('https://swapi.dev/api/people/1/')) response_json = JSON.parse(response.body) expect(response_json['eye_colour']).to eq('blue') end end Unfortunately, this test fails and displays messages like this:
Failures: 1) is expected to eq "blue" Failure/Error: expect(response_json['eye_colour']).to eq('blue') expected: "blue" got: nil (compared using ==) From this output, we could guess either response_json['eye_colour'] is set to nil or the key eye_colour is not defined. However, there is no more information here. To find out the cause of the error, an additional print-debug would be needed.
