「後回し」にしない技術 eBook : イ・ミンギュ, 吉川南: 本
Amazon.co.jp: 「後回し」にしない技術 eBook : イ・ミンギュ, 吉川南: 本...
amzn.asia今週やったこと
- Obsidianのインボックスを整理した
- “「後回し」にしない技術” を読んだ
- JWTに権限を持たせる実装をした
インボックス整理について
日々の気づきとか考えをデイリーノートに書いて、週末にインボックスに個別ノートとして移すという運用をしている。 これらの個別のノートを永続ノートとして深めていきたいんだけど、なかなか思考の断片が昇華できず、インボックスが膨れ上がっていた。
そこで、Claudeにノートを見てもらい、永続ノートに仕上げる手伝いをしてもらったところ、結構消化できた。(といっても10個くらいだけど）
必要だったのは、「背景」と「核心的アイデア」だったと気づいた。 「背景」があることで、その考えの適用範囲や文脈が定まって、ふわふわしてた主張がはっきりする。 そこで「核心的アイデア」として、まさにここが自分の考えという点をはっきり書くことで、 より独自の価値を見出せると学んだ。
今後も継続的に永続ノートを増やしていきたい。 少なくともこれ以上インボックスを増やさないように、日々少しずつ整理しよう。
“「後回し」にしない技術” について
前から Kindle Unlimited でライブラリに入れていたものの、読んでなかった。 最近、アウトプットを意識しないといけないと思い立ち、何かしなきゃ、そういえば本も読みたいな、 みたいななんかよくわからん理由で、正に「後回し」にしていた本を読んでみた。
- 自分の目指す方向を見定めよう
- その方向に向かう小さな一歩を今すぐやろう
- やると決めたことを公開しよう
全体的に、割とマインド面が多かった印象だけど、モチベーションには繋がった。 そして今ブログを書いている。
権限チェック周りの話
今仕事で作っているシステムは、ユーザーの権限をJWTのアクセストークン内に持たせる設計にした。 なぜなら、サーバー側でセッションを持つ必要がないし、フロントエンドでも権限の有無の判定が簡単だから。
このシステムは、ユーザーが複数のプロジェクトに所属し、そのプロジェクトごとに異なる権限を持つため、 アクセストークンに権限を持たせると、プロジェクト別に多数の権限を持たせる必要が出てくる。 まあ別に大丈夫だろうと甘くみていたが、一つのプロジェクトに関する権限が10個以上あり、 かつプロジェクトのIDがUUIDで比較的長いため、格納する文字列がかなり長くなるという課題に直面した。
このアクセストークンはフロントエンドでCookieに保存するため、Cookieの4KB制限だけ気にすればいいだろうと思い、 複数のCookieエントリーに分割保持するようにしたものの、HTTPのリクエストヘッダーにも上限があることが発覚。 Tomcatはデフォルトでは8KBだそうで。まあそりゃ上限あるか。。。
基本的にPCから使うシステムだし、上限を増やせばそれほど問題ないとわかったため、 一旦今の方針のまま突き進むことにしたが、こういう問題ってみんなどうやって解決してるのだろう？
使うプロジェクトを切り替えるたびに、そのプロジェクト向けのアクセストークンを払い出し直すのが一番スマートか？と思いつつ、 現状はそこまでやるメリットが少ない気がしてやってない。どうやるのがベターか知りたい。
今週の学び
- 小さくてもアウトプットを継続することが大事
- 物事には背景が必要。背景があると意味が際立つ
- アクセストークンの設計は難しい
来週やりたいこと
- インボックスの整理を継続
- 「なぜ、あなたの仕事は終わらないのか」を読む
- AxonのEventHandlerのエラーハンドリングについて設計する