Windowsコンピュータがもう自分のものに思えない、という感覚 - YAMDAS現更新履歴 yamdas.hatenablog.com/entry/20240701/my-windows-computer
プラットフォーム エンジニアリングに関する 5 つの誤解: プラットフォーム エンジニアリングとは一体なのか | Google Cloud 公式ブログ cloud.google.com/blog/ja/products/application-development/common-myths-about-platform-engineering/
タクシーアプリ『GO』におけるプラットフォームエンジニアリングの実践 - Speaker Deck speakerdeck.com/mot_techtalk/takusiapuri-go-niokerupuratutohuomuenziniaringunoshi-jian
デベロッパーエクスペリエンス（DevEx）とは: 開発生産性Conference 2024 に向けて - Findy Tech Blog tech.findy.co.jp/entry/2024/06/27/090000
Microfeatures I Love in Blogs and Personal Websites danilafe.com/blog/blog_microfeatures/
週報（2024-06-30） 再現が簡単な環境
Terraform 1.9
出たけれどAtlantisが 1.8.2以降に対応していない 状態なのでstayである。もう少しで対応バージョン出そうなのだが。
Terraform 1.9 enhances input variable validations が良いなと思う。
再現が簡単な環境
技術検証をしたいときにプロダクションで動いている環境を使うわけにいかないので、それを再現した環境が当然必要になるのだが、コスト低く再現可能な環境ってまぁ結構難しいよな、って当たり前だけど思う。だからと言って再現可能性の高さが技術選択の要になるかと言えば、それも違うし。
例えばEKSは検証用にちょっと立てましょう、というのもなかなか気が重い。Kubernetes検証として、個人でK3sを動かしているけれど、これもKubernetesと完全互換しているわけではない。ただ、新バージョンのArgoCDをちょっと動かしてみよう、とかはわりと気軽に出来て便利だったりはしている。
結論はないのだけれど、本番再現環境を維持する技術、みたいな話って意外と見ないので需要がありそうだな、と。
プレーンテキスト最強
仕事のタスク管理、チームとしてのカンバンとは別で自分個人のマネジメント系のタスクとかを管理する場所、Notionでカンバンを作っていたけれど、やめてプレーンテキスにした。Logseqでアウトライン操作している。
プレーンテキスト最強。Notionも悪くないけれど、一覧性に劣るというか。Logseqのアウトライン操作だと、要はテキストをツリー構造にできて、どのツリーを開けて見せておくか、というのがコントロールできるから、一覧全部細かいとこまで見える状態にもできれば、ツリーのトップレイヤーだけ見せて抽象化しておくこともできる。
複数人のタスク管理だったらカンバンのほうがいい。アウトライナーのような複雑な構造だと、構造の細部まで複数人でメンタルモデルを一致させるのは困難だから。「チケット」ぐらいの単位で目線を合わせるのがベスト。逆に自分個人だけが触るものであれば、細部まで細かな構造を作れたほうが、メンタルモデルと合致させやすくて良い。
Logseqを選んだのは、プレーンテキストのアウトライナーかつローカル保存ができる、という点だけ。なのでLogseq特有の機能は全然使っていない。
8/10開催「builderscon 2024」チケット販売中 gihyo.jp/article/2024/06/builderscon-2024
nate-parrott/ball github.com/nate-parrott/ball
Terraform 1.9 enhances input variable validations hashicorp.com/blog/terraform-1-9-enhances-input-variable-validations
書店在庫情報プロジェクト info.openbs.jp/news/first-step
週報（2024-06-23） ぜんぶ方法序説に帰結する
『ヴィクトリア朝時代のインターネット』を読了。ICTのIのほうがCより先に発達した気がなんとなくしていたが、Cのほうが全然早かったんだなと。通信、手旗信号とか腕木通信であれば、言わば光の速さで数百年前から通信ができていたわけだ。これを光学式テレグラフと呼んだりするらしいが、光回線の実現はるか前から光学通信があったわけだ！という、言われてみれば当たり前なのに、その響きに興奮する
優先度の低い情報に目だけ通す
時事的なニュースを知るのに、最近ははてなブックマーク検索のRSSを使っている。例えばタイトルに「日本経済新聞」が入った10users以上ブクマしている記事のRSSを購読している。
日経新聞は契約していないので、ほとんどの記事は内容を読めない。それでも、見出しがRSS Readerに流れていくのにつらつら目を通すだけでも、最近の政治経済動向をなんとなく頭にインデックスできる。本当に気になる話は調べれば他社の記事が出たりするし（あまり褒められないやり方だが）。政治経済系の情報はそこまで深く追いたいわけではないが把握はしたいので、これぐらいのインプットがちょうどいい。
本当は日経電子版を購読したらいいのだろう、と思っているが、月4000円というのは、サブスク全盛の時代になって改めて考えると突出して高くて、なかなか手が出ていない。
ぜんぶ方法序説に帰結する
タスク管理でちょっと引っかかることがあって少し調べたりなどしていたのだが、読んだいくつかのエントリーはどれも「問題を小さく分解する」「次のアクションを具体化する」みたいな話にまとめることができる。こういった考え方はデカルトの「方法序説」に書かれている「四つの規則」の1つで、もろもろ思考を巡らせては最終的に「方法序説しか勝たん」みたいな気分に帰結する。これ以上昔に遡れるのかは知らない。
問題の分割が大事、とはそういうわけで昔から知識として知っているし実践もしていたが、最近ここに自分の思考が帰ってくることが多くなった。前回の週報で書いた「その仕事はチケットの形をしていない」のように、曖昧で大きな問題を抱えることが増えたのだと思う。この手の問題は全然やる気が出ない、というかどこから手を付ければいいかわからない、みたいなことも多くて、放置したまま時間が経ったりしてしまう。たぶん、この手のタスクは「分解」が9割（乱暴に言えば）。適切な分解が済めば、個々の問題自体はそこまで難しくなくて、淡々と進めればよい、ということも多い。しかし分解が大変。
小さく分解された問題は、総和を求めれば元に戻るような捉え方をしていたが、これ積分とかなんだろうな、と今更理解している。