キムチのきもち

キムチのきもちになって考えてみよう

【PR】翔泳社のSEshopで君もPDF版技術書を買わないか？(たまに50%ポイント還元セールもやってる)

週報27 相手を変えるより自分を変えるほうがコスパが良い 2024/12/08

先週、妹夫婦が喧嘩した。

そのことで、妹の話を聞いたり喧嘩を仲裁したりした。

仲裁してるときは、あくまでどっちの味方もせずに、二人が理性的に話し合いできるよう努めた。

でもそれが終わったあと、思い出すとイライラが止まらなくなってきて、Xに投稿してしまった。

挙げだしたらきりが無いが、とにかく身内である妹の尊厳が踏みにじられたように感じて、心底腹が立った。

  • 義弟があまりにもガキで自分本位なロジックを展開すること

  • 男として夫として父としての自覚が甘すぎること。

  • 妹のことを、喧嘩の中で他人と言い放ったこと。

辛そうにしている妹に対して、何もできない自分が悔しくて、実は一人でちょっと泣いたりした。

その後、母と話す機会があったので、今回の妹夫婦の件についても、どう思っているのか聞いた。

ところが、自分の予想に反して母親はとても冷静で、ある意味ドライで冷たく感じた。

「人のことは変えられない。妹の旦那はそういう人なんだと思うことにした。」

自分の娘がひどい扱いを受けて、腹が立たないのか？と聞いた。

「もちろん腹は立つ。ムカつく。でも、怒りでぶつかっても、人が変わるわけではない。」

たしかにそうかもしれない。頭ではわかってる。でも、傷つけられて黙っていていいのか？

自分の身内を、ましてや娘を傷つけてくる存在に対して、泣き寝入りするのか？

「そもそも、相手が、こちらが思うタイミングで、こちらが思うように変わるなんて、宝くじ当てるより難しいこと。そういう人を選んだのは、娘自身だから、娘が乗り越えていく問題。」

このあたりまで聞いて、ある程度頭が冷えてきた。自分の考えは若すぎた。

怒りに任せて打って出ることは、簡単かもしれない。

でもそれによって、夫婦の問題に、嫁の兄という要素が入り込んできてしまうことになる。

さらに自分は結婚もしてないし子どももいない。

そんなやつに、文句言われても、聞こうとも思わないだろう。

それに、そういう人を選んだのは妹自身であり、妹が乗り越えていくべき夫婦の壁なのかもしれない。

だから私は、彼らを見守ることにしたし、彼らからヘルプ要請が来たときだけ応えることにした。

多分妹からしかヘルプ要請はこないだろうけど。

ガミガミ叱る以外の方法で、間接的に妹の負担を減らせないか。

義弟との関係をうまく築いていく方向で今後進めてみることにする。

人生の壁 (新潮新書 1066)

人生の壁 (新潮新書 1066)

Amazon

話の通じないガキを変えるより、自分を変えて見守るほうが、精神的にも肉体的にもコスパがよいかもしれない。

少しずつリーダーから仕事を奪っている

AWSもReactもspring bootも、なにそれおいしいの？状態だったが、1ヶ月仕事してみて少しずつ仕事が板についてきた。

雑務は全部拾うし、リーダーやサポートメンバーが知りたいことは、全部日報に書く。

そして自分のチケットもちゃんと消化する。

Reactも少しずつわかってきて、spring bootでAPIも作れるようになってきたので、年内に主要なチケットは全部片付けるのが目標。

ブラックフライデーセールで昇降式デスク買いました

Amazonのブラックフライデーが金曜23:59までだったので、アフィ記事を書いた。

yusuke1225math2.hatenablog.com

クソみたいな紹介記事を書いてしまったが、実際滑り込みで買いたいものを買えた方がいた模様。

いつも以上にクリックされたので、1時間ぐらいのやっつけ仕事だけど書いてよかった。

自分も、ずっと買おうと思っていた昇降式デスクを買ってみた。

なんかまだタイムセールやってて、今日の終わりぐらいまで13000円でした。気になる方はどうぞ。

2024/12/08 17:25 時点でのスクショです

FEZIBO 電動 昇降式デスク スタンディングデスク 幅120cm 奥行60cm 高さ72-118cm 上下昇降デスク 高さメモリー機能 静音 衝突検知 収納フック付き pc オフィスデスク ミーティングテーブル テレワーク 人間工学 おしゃれ ブラックフレーム/ブラウン天板

FEZIBO 電動 昇降式デスク スタンディングデスク 幅120cm 奥行60cm 高さ72-118cm 上下昇降デスク 高さメモリー機能 静音 衝突検知 収納フック付き pc オフィスデスク ミーティングテーブル テレワーク 人間工学 おしゃれ ブラックフレーム/ブラウン天板

  • FEZIBO
Amazon

備忘録

React

React v19の安定版がリリースされた

React Router v7がRemixと合流したぞ

useEffectあるある「setHogehogeでstate更新してもstateが更新されてない」

javascript

そもそもjsは、シングルスレッドでどうやって処理を走らせているのか。

  • イベントループを理解しましょう。
  • 実行コンテキスト: コードが実行される際に必ず生成される実行環境。
  • コールスタック: 実行コンテキストの積み重ねスタック。
  • タスクキュー: 実行待ちのタスク(非同期での実行が予約されてる関数)が格納されるキュー。
  • イベントループ: タスクキューを順番に消化する仕組み。コールスタックが空のとき、キューから一つ取り出して実行する。
  // 例
  let val=0;
  setTimeout(function task(){val=1;}, 0);
  console.log(val);
  // 実行結果
  // > 0

となる。setTimeoutのコールバック関数taskは、グローバルコンテキストの消滅後に実行されるから。回避するには、コールバック関数を使えばいいが、コールバック地獄になりやすい。→Promiseを使おう。

Promiseとasyncとawaitをもう一度

java

javaのプリミティブ型

ArrayListとListがあるが、何が違うのか

spring boot

Azure AD B2C

AWS

AWS Health Dashboard

ECS/Fargate

Sentry

RESTful API について、もう一度ちゃんと学ぶ

  • RESTful API とは? - RESTful API の説明 - AWS
    • ウェブAPIは、クライアント(ユーザー)とリソース(クライアントに提供する情報)のゲートウェイ
    • REST: Representational State Transfer
      • 統一されたインタフェース、ステートレス、階層型システム、キャッシュ可能性、オンデマンドなコード
      • これによって、スケーラブルで柔軟で独立したAPIになる
      • RESTは思想、RESTful APIはRESTに基づいたWebAPIの実装
    • クライアントリクエストの内容
      • URLで一意なリソース識別
      • GET,POST,PUT,DELETEというHTTPメソッドで実装
      • HTTPヘッダに、データとパラメータが含まれる
    • RESTful APIサーバーのレスポンス
      • ステータスライン (200など)
      • メッセージ本文(jsonやxmlのリソース表現)
      • ヘッダー
    • AWSだと Amazon API Gatewayで作成、モニタリング、保護とかできる

マイクロサービスからBFL、モノリポの探求

マイクロサービスについて

  • マイクロサービスアーキテクチャってなんだ？
  • 何が嬉しいの？
    • ビジネス機能ごとに開発チームを分けられる。開発チームが保守も責任を負える。
    • サービスごとの変更管理が楽、要するに素早く開発が進んで顧客ニーズに対応しやすい。
  • 注意点
    • サービス分割を注意深くやらないと、分散的なデータ管理や疎結合なサービスにできない
    • インフラ構築は自動化しましょう
    • サービス間通信の異常対処の設計が必要
    • サービス間通信のパフォーマンス改善が必要

CQRSとEventSourcing

  • CQRSとEventSourcingの基本 #CQRS - Qiita
  • CQRS Command Query Separation
    • Command: オブジェクトのデータを変更して何も返さないかメタデータだけ返す
      • POSTメソッド
    • Query: 情報を返すが、オブジェクトのデータは変更しない
      • GETメソッド
    • 要するに、読み取りと書き込みを、明確に分離する。これによってマイクロサービスアーキテクチャによって嬉しいことがたくさんある
  • Event-Sourcing
    • ドメイン駆動設計とCQRSでよく使用されるデータ保存メカニズム
    • CRUDと異なる点
      • UPDATEとDELETEを捨てて、CREATEとREAD(INSERTとREAD)のみを使用する
    • すべての変更は新しいエントリとしてEvent-Store(データベース)に追加され、肥大化する
    • DDDのdomein events と Event-Sourcingのeventは、いずれもビジネスロジックに関連するイベントを記述する
  • CQRS & Event Sourcing モダンアーキテクチャにおける役割と実装

BFF

モノリポvsマルチリポ

  • モノリポとマルチリポの比較が浮き彫りにする開発能力を高めるための課題とトレードオフ - mtx2s’s blog
    • モノリポ → 全部一つのリポジトリ
    • マルチリポ → マイクロサービスごとにリポジトリ分ける
  • Googleのモノリポについて書かれた論文の考察から、各リポジトリ戦略のトレードオフを考察している
    • モノリポの利点(主にGoogleの話)
      • コードベースの可視性が高まり、他の人のコードを真似したり、変更したりしやすい
      • 依存関係に関する悩みから開発者が開放される
        • Googleではトランクベース開発(開発ブランチを持たず、開発の変更はヘッドにコミット)
        • プロジェクトはリポジトリのヘッドにある依存関係のバージョンを使う(単一バージョンルール)
        • APIの更新によって影響を受けるすべての依存元コードは同時に更新される
      • 課題: コミット権限の管理、エンジニアの実力
    • マルチリポの利点
      • コードのサイズが小さい、ビルドも短い
        • 継続インテグレーションの文脈では有利
      • 安定した依存関係
      • 課題: コードの可視性、リポジトリを跨いだ依存関係の管理