やわらかテック

興味のあること。業務を通して得られた発見。個人的に試してみたことをアウトプットしています🍵

ミヒャイル・エンデ作のモモは現代の大人こそ読むべき本だった

昨日、ミヒャイル・エンデ作の「モモ」という書籍を読了しました。
この本は児童文学として書かれているので、普段の自分とは縁もゆかりもない書籍です。一週間前にアップロードされたアバタローさんの解説動画を見て「何だこの本は...面白そう」と思い、いつものように衝動買いをしました。

www.youtube.com

大学生の時はよく小説や文学を読んでいたものですが、最近となっては技術書ばかりを読んでいたので、ちょっとした息抜きということで読み進めていたのですが、良い意味でモモには驚かされました。

エンデによる現代社会への痛烈な風刺は非常に的を得ています。子供だけではなく、現代を生きている我々のような大人こそ、エンデ作のモモを読むべきだと感じました。

続きを読む

Railsのマイグレーションファイルでt.stringを使うときはlimitを指定してほしい

Railsではマイグレーションファイルを作成してマイグレートを実行することで、テーブルが作成されます。
非常に便利で手軽にテーブルの定義・作成ができるのですが、マイグレートされた結果、どのような型が選択されるのかが隠蔽化されるという問題があると思っています。一例として、t.stringt.textでそれぞれカラムを定義した場合に実際にテーブルで採用される型はどうなるでしょうか。

class CreateUserTable < ActiveRecord::Migration[7.0]
  def change
    create_table :users do |t|
      t.string :string_name
      t.text :text_name
      t.timestamps
    end
  end
end

postgresqlに接続した状態で実行すると、以下のような結果になりました。
気になるのはt.string :string_nameで定義したカラムでは型がcharacter varying(varchar)(制限付き可変長文字列)となり、t.text :text_nameで定義したカラムではtext(制限無し可変長文字列)が選択されるという点です。

(※ここでいう制限の有無は最大文字数のこと)

postgres=# \d users
                                          Table "public.users"
   Column    |              Type              | Collation | Nullable |              Default              
-------------+--------------------------------+-----------+----------+-----------------------------------
 id          | bigint                         |           | not null | nextval('users_id_seq'::regclass)
 string_name | character varying              |           |          | 
 text_name   | text                           |           |          | 
 created_at  | timestamp(6) without time zone |           | not null | 
 updated_at  | timestamp(6) without time zone |           | not null | 
Indexes:
    "users_pkey" PRIMARY KEY, btree (id)
続きを読む

【書評】単体テストの考え方 / 使い方 を読了しました

2022/12/28に「Manning Publishing: Unit Testing Principles, Practices, and Patterns」の翻訳書である「単体テストの考え方/使い方」という書籍が発売されました。買うか迷っていたのですが、TDD(テスト駆動開発)で有名なt_wadaさんがツイートされているのをお見かけして、いつものように衝動買いをしました。

著者は単体テストの第一人者であるウラジーミル・コリコフさんが書かれたもので、原書の評判は良く待望の日本語版です。先日、読了しましたので内容を簡単にまとめつつ、書評を書いてみようと思います。お値段は少々お高いですが、それだけの価値がある書籍だと僕は感じました。

続きを読む

小さな声で話し出すことがリモートワークのミーティングを加速させた

日々のリモートワークでミーティングをしていると、相手と同時のタイミングで話し始めてしまうことがよくあります。特に自分から話を振ってから、返答を待ってる間に何かを追加で自分が話し出した時なんかひどいもので、せっかく相手が話しだしてくれたのに遮ってしまった時は申し訳なさすぎて消えたくなります。

「どうしたものかなぁ...」と長らく悩んでいました。
しかし、ある日のこと「ハイッ!」と返答したつもりが「...ハイッ」とかすれた声になってしまったのですが、相手の会話を遮らずにそのまま会話が続いていることに気づきました。

「これ使えるんじゃないか...?」と思い1ヶ月ほど、あえて小さな声で話し始めるようにしてみました。

続きを読む

中間テーブルには複合インデックスと単一インデックスどちらを作成すれば良いのか

データベースの設計において正規化の結果、中間テーブルを作ることがよくあると思います。
以下のようなテーブル群があったとします。登録されたユーザーと登録された商品を誰が出品した商品なのかを中間テーブルへ記録しています。

  • users
  • products
  • user_products(中間テーブル)

中間テーブルuser_productsにインデックスを作成する場合、3つの方法が考えられます。

  • A: user_idproudct_idに対してそれぞれ単一インデックスを作成する
  • B: user_idproduct_idの複合インデックスを作成する
  • C: AとBの合わせ技

インデックスの作成方法はAとBのどちらが良いのでしょうか。
Railsでuser_productsのような中間テーブルを作成して、user_idproduct_idに外部キー制約を付与すると、それぞれに単一のインデックスが作成されます。

create_table :user_products do |t|
  t.references :user, foreign_key: true
  t.references :product, foreign_key: true
  t.timestamps
end

確証はないのですが「複合インデックスの方が、いいんじゃないの?」と思ってしまいます。
user_productsが参照されるストーリーを考えると、出品された商品の一覧にユーザーと商品情報をつけ合わせたデータが必要になるケースが考えられます。その際にはuser_productsにJOINを行う必要があるためuser_idproduct_id両方のキーを使うことになります。

...と推測ばかりしていてもしょうがないので、実際に計測してみます。

続きを読む