前回手術をして、経過観察中に緊急手術になったのでメモ

前回の手術から一ヶ月以上経過した。食事や飲酒も自由にできていたが、手術をしたところが少し痛み始めた。

経過観察の予定があったので、痛み始めてから4日ぐらいのタイミングで再び歯医者へ、先生曰く内部で感染を起こしている可能性があり、切除するために切開するとのこと。

歯医者のあとに飲む約束をしていたが、流石に健康を優先した。（ガチのドタキャンで申し訳ない）

手術は45分ぐらいで終わった。炎症を起こしていると麻酔が効きにくいらしく、何度も麻酔を打った。麻酔を打つと心臓が早くなる。

手術はまた寝てしまった。毎回寝る。

術後、「炎症を起こした膜を全部取った」と言われた。膜？？？という気持ちだったが、調べたら歯根膜という膜が歯にあるらしい。それを取ったのだろうか。

術後は少し腫れているし、結構血がでている。痛み止めを飲む。夜はそうめんを食べた。

前回の手術と比べて比較的軽い印象がある。術後の腫れも引いてきている気がする。

1日後

朝は口から血が出たが、夜には血の感じはなくなった。腫れもないし痛み止めを飲まなかった。うどんとビーフシチューを食べた。

2~6日後

案外軽く、口の中に糸があるぐらいで普段通り過ごせた。コーヒーは控えている

7日後

抜糸した。歯磨きも普通にしてよくなった。良かった。

10日後

酒を飲んだ✌('ω')✌

まず自分はスクラムについて少し誤解していたようだ。これまではスクラムのことを何らかのミーティング手法の集合ような感じで認識していたが、それは違った。

スクラムの目標はチームを自己組織化した状態にすることであり、決まった方法があるものではない。スクラムマスターは常にチームを観察し、ときに導き、ときに教え、障害物をなくし、会議をファシリテーションしてコミュニケーションを活性化させる。ゆくゆくはチームの一人ひとりが主体的にそれらの行動を取れるようにする。スクラムはリーダーを育てるものだ。

この本はチームが自己組織化するために必要なアクションを考えるための知識を提供してくれる。

自分はこういうメタ知識がすごく好きだ。

タックマンの集団発達モデルの話が面白かった。チームが機能するまでの過程を説明したモデルで、次の4段階を経るという

• 形成期：集まったばかり、緊張や不安

• 混乱期：メンバー間の対立が発生する。生産性は下がる

• 規範期：対立を乗り越え一通り落ち着いちゃう。メンバーはそれに満足してしまい、それ以上の成長をしなくなる

• 機能期：より高みを目指す

理想は機能期に入ることだが、多くは規範期で落ち着いてしまう。スクラムマスターはそれに満足せず機能期に持ち上げるアクションが求められる。また、この状態は変動しうる。人が入ったり抜けると状態が変わる。スクラムマスターは常に状況を観察し、チームがどの状態にあるのかを意識してアクションを取っていく。

この考え方はチームに対しても使えるし、個人の成長にも使えそうだ。

抽象度が高く、全体的に学びが多い本で良かった。

データをリストで表示する。データ数が多く、単純なリスト描画をすると初期描画に時間がかかる。わけアリでcursorのようにデータを逐次取得するような状態ではない。フロントエンド側で調整する。

イメージ以下のような構造

1<List>
2  {lists.map((item) => (
3    <Item item={item}/>
4  ))}
5</List>

Intersection Observer API

端的に言うと、ある要素が別の要素（通常はviewport）との交差状況の変化を非同期に監視できる。これを使うことで、必要なときに描画の処理をすればよくなるため、初期描画が最適化される。

react-intersection-observer

useInViewを使う。遅延描画用のLazyItemコンポーネントを作る

1export const LazyItem: React.FC = () => {
2  const [ref, inView] = useInView({
3    triggerOnce: true,
4    rootMargin: "200px 0px",
5  });
6
7  return (
8    <div ref={ref}>
9      {inView ? <Item /> : <div style={{ height: "40px" }} />}
10    </div>
11  );
12};

描画対象じゃないときは少し高さを持たせ、後続のitemが描画されないようにしている。これを使うことで遅延描画が達成

Railsの世界に浸かっていると基本的なことを忘れる。戒めメモ

1User.all.pluck(:type).tally
2=> {nil => 26, "aaa" => 9, "bbb" => 1, "ccc" => 2}
3User.where.not(type: "bbb").count
4=> 11

1User.where.not(type: nil)

で何らかの値が入っているレコードが取れることを考えると、そこまで不思議ではなかった

ちなみにnilも含めたい場合はorを使う

1User.where.not(type: "bbb").or(User.where(type: nil))

個人開発の素のRails + PostgreSQLアプリがある。Redisを導入したくて、ついでにDocker管理するようにした。職場でDockerが使われているが、既に構築されたものをたまにメンテするぐらいで、一から作るのは初めてだったので新鮮だったメモ。

Dockerfileの作成

1FROM ruby:3.2.2-slim-bookworm
2
3## 必要なパッケージをインストール
4RUN apt update -qq && apt install -y --no-install-recommends \
5    build-essential \
6    libpq-dev
7
8# 作業ディレクトリを設定
9WORKDIR /app
10
11# GemfileとGemfile.lockをコピー
12COPY Gemfile Gemfile.lock ./
13
14# Bundlerをインストールし、依存関係をインストール
15RUN gem install bundler:2.6.8
16RUN bundle install --jobs=$(nproc) --retry=3
17
18# アプリケーションコードをコピー
19COPY . .
20
21# エントリーポイント
22CMD ["rails", "server", "-b", "0.0.0.0", "-p", "3000"]
23
24# ポートを公開
25EXPOSE 3000

いろいろなものを参考にしながら作成。古いアプリなのでRubyも古い。今度上げる。

• aptとapt-getの違いを知ったり。機能面で優れているのでaptを使うで良さそう。

• apt update -qq

  • qqオプションは、エラー以外の出力を無くすやつ

• apt install -y --no-install-recommends

  • yオプションはインストール周りの承諾を自動的に「はい」にする

  • no-install-recommendsオプションは推奨パッケージをインストールしない。Debian系のパッケージシステムは、必須ではないがあると便利なパッケージをデフォルトでインストールさせるらしい。必要最低限にするために必要

• build-essential

  • ビルドツールパッケージ

• libpq-dev

  • PostgreSQLに必要

• RUN bundle install --jobs=$(nproc) --retry=3

  • jobはインストール処理の並列実行

  • nprocコマンドでCPUコアの数が返る。いけるところまで並列化している

docker-composeの作成

1version: '3.9'
2services:
3  db:
4    image: postgres:16
5    environment:
6      POSTGRES_USER: XXX
7      POSTGRES_PASSWORD: XXX
8      POSTGRES_DB: XXX
9      DATABASE_HOST: db
10    volumes:
11      - db_data:/var/lib/postgresql/data
12    ports:
13      - "5432:5432"
14
15  web:
16    build: .
17    volumes:
18      - .:/app
19    ports:
20      - "3000:3000"
21    depends_on:
22      - db
23    environment:
24      RAILS_ENV: development
25      DATABASE_HOST: db
26      DATABASE_USERNAME: XXX
27      DATABASE_PASSWORD: XXX
28      DATABASE_NAME: XXX
29      REDIS_URL: redis://redis:6379/1
30
31  redis:
32    image: redis:8
33    ports:
34      - "6379:6379"
35    volumes:
36      - redis_data:/data
37
38volumes:
39  db_data:
40  redis_data:

DBに接続ができずにハマる。何度かPostgreSQLのユーザー名を変更したのと、その変更のキャッシュが残っていた関係で接続ができなくなった。イメージのビルドを明示的に指定することで解決。

1docker-compose up --build

マイグレーションの実行

1docker compose exec web rails db:migrate 

データの移行

1pg_dump database_name > local_backup.sql
2docker cp local_backup.sql db-container-name:/tmp/local_backup.sql
3docker compose exec db psql -U postgres -d database_name -f /tmp/local_backup.sql

ぼんやり知っているつもりだったけど、実際に手を動かしてみると色々時間取られた