ボルダリングで首を痛めた。2年前にも痛めており、今回も症状が近い。記録を残す。

• 2025/03/29

  • ムーブを試行錯誤しており、右手に少し悪いピンチでサイファ―ムーブを試したら思ったより身体が上がらず首裏が張ったような状態になる。多分これで痛めた。

  • その日はそのあと4,5時間ぐらい登った。

  • ずっと痛かったけどハイになっているのか登っちゃうんだよな

  • ロキソニンの湿布があったのでそれを貼って就寝。

  • 左を向くと痛い

  • 右を向くと痛くない

• 2025/03/30

  • 朝から痛い。29日より痛い気がする。

  • 左を向くとじんわり痛い

  • 左を向いて上下を向くと常に痛い

  • 右を向くと神経っぽい痛み

  • 右を向いて上下を向くと常に痛い（左よりはまし？）

  • 両腕を伸ばすと左側の首裏が痛い。右腕は円のように動かしても痛くないが、左腕は痛い（痛くならないように無意識に他の筋肉が動いている感じがする。）

  • この日はお出かけした。2万歩歩いた

  • 夜はロキソニンの湿布を貼って就寝

• 2025/03/31

  • まだ痛いが、痛みは引いてきている気がする

  • 左を向くと痛くない

  • 左を向いて上を向くと痛い

  • 左を向いて下を向くと痛くない

  • 右を向くと神経っぽい痛み

  • 右を向いて上を向くと痛くない

  • 右を向いて下を向くと痛い

  • 両腕を伸ばすと左側の首裏が痛い。右腕は円のように動かしても痛くないが、左腕は痛い

  • 夜はロキソニンの湿布を貼って就寝

• 2025/04/01

  • かなり痛みは引いてきた

  • 左を向くと痛くない

  • 左を向いて上を向くと痛い（だいぶ引いてる）

  • 左を向いて下を向くと痛くない

  • 右を向くと神経っぽい痛み（だいぶ引いてる）

  • 右を向いて上を向くと痛くない

  • 右を向いて下を向くと痛い（こっちはまだ痛い）

  • 両腕を伸ばすと左側の首裏が痛い。右腕は円のように動かしても痛くないが、左腕は痛い

  • ボルダリングを3時間ほど。問題なく登れた

  • ロキソニンの湿布を貼って就寝

• 2025/04/02

  • まだ痛みはあるが、よくなっている感じ

  • 左右、右上、左下：痛くない

  • 左上、右下：少し痛いぐらい

  • 両腕をのばしても痛くない

1git checkout [取り込み元のブランチ] -- [特定のファイルの相対パス]

定期的にやる

在宅ワークは集中力との戦いである。

自分はこれを読んで、時間を細かく区切って集中して作業するテクニックなんだなと思い、まぁ一理あるよね〜程度でこれまで実践してこなかった。

要は、ポモドーロ・テクニックは集中するテクニックではなく、自分がどれだけ集中して仕事ができたかを可視化するためのテクニックだという。この視点は自分に取って新鮮だった。

この考え方の良いところは、行動目標になることだ。エンジニアの仕事の成果は、費やした時間量と必ずしも相関しない。適切な時間の使い方や道のりを進んできているのに、思ったより仕事が進まないこともある。そういうときに罪悪感に近い感情が生まれてしまうことがあるが、このテクニックを知っていればその過剰な罪悪感を減らすことができる。十分なポモドーロを成功させているならば、仕事人としては及第点だろう。（もちろん、成果を出せたらより良いのだが）逆に、ポモドーロがあまり成功できていなかったら、内省するいい機会になる。

一週間ほど試してみて、自分は一日に10ポモドーロを成功させることが良い目標だと思った。スマホやSlackのtimesをみたり、集中が途切れたと思ったら失敗とみなす。質の高いポモドーロを目指していく。

Qiitaの記事でとても興味深いものを読んだ。

いわゆる Brilliant jerk だと思った。程度の差はあれ、こういう性質は人間誰しも持っていると思う。

正直な話、自分はそういう性質を持っているタイプだと思う。かつて、そういう良くない部分が強く出ている時期が確実にあった。2022年頃だろうか、当時のマネージャーに指摘を受け、深く反省し、それから意識をするようになった。後に、マネージャーからは改善が見られるとのフィードバックを受け取った。

当時と比較したら今は落ち着いている気がする。意識してコミュニケーションをしているつもりだが、正直完璧とは言えない。程度の差はあれ、メッセージを送った後にこの表現は少し良くなかったかもしれないなと、一人反省することが今でもある。これは完全になくすことは難しい物だと考えている。だからといって無くすことを放棄するつもりはない。永遠の課題だと思う。

処理の範囲が違う

• includes は先読みを行いキャッシュする → Railsのメモリに影響する（しない場合もある）

• joins は INNER JOIN する → データベース内だけの話

関連先のデータを使いたいときはincludesを使うが、関連先の条件で絞り込みたい場合はjoinsを使う。メモリのこととか、速度のこととか、ここから考えていけばある程度応用が効く。

例：ユーザーのいいねした順でBookを取得したい

joinsを使う方がスマート

1user.books.joins(:likes).all.order('likes.created_at DESC').to_sql
2=> "SELECT \"books\".* FROM \"books\" INNER JOIN \"likes\" ON \"likes\".\"book_id\" = \"books\".\"id\" WHERE \"books\".\"user_id\" = 5 ORDER BY likes.created_at DESC"