https://gihyo.jp/magazine/SD/archive/2024/202405
ドメイン周りのセキュリティとはいえ, 侵入経路は標的型メールだったりと他のセキュリティ上の懸念事項は変わらないのねという感じ.
そもそも新規取得時に「そのドメインは必要なのか？」という点を検討することも重要です。既存ドメインのサブドメインで済ませられるなら新規で取得する必要はありません。
これ. 組織内で一元管理するしかない部分かなと思う.
1, 2章は JavaScript は知っているけど, TypeScript は知らない人向けの言語仕様の話. 今どきそんな人いるのかなと思ってしまった. あえて interface を説明しない強気な解説が良い.
型による静的解析の話. switch式欲しいなあといつも思ってます.
Java とか静的型付けでクラスベースの言語では, OOP由来のモジュラー性とかポリモーフィズムのために型という概念を使っていて, 名前空間としての役割が主だったんだと思う. TypeScript の場合はそもそも動的型付けの JavaScript につけるなら構造的型付けのほうが簡単だったというのはありそう. とはいえ構造的型付けであれば代数的に型を扱うことができるので, より便利だったというところが面白い.
唐突に始まる型パズル. 型が使える嬉しさはIDEとかAIコード支援とかが大きいので, うまく使いこなせるといいね.
WSLとか GitHub Actions とかでデファクトになってるので, それのアップデートの時期かあという気持ち.
リプレイスの大まかな流れは『レガシーソフトウェア改善ガイド』に書いてそうなくらい王道なやり方でさすがという感じ.
ZOZOTOWNはVBScriptで動いています。
ちょっと衝撃的. スタートアップ初期の技術選定やフレームワークがネックになるのはよく聞くけど, よく耐えたなという感じ.
リプレイスを行う初期段階では、事業開発を行ってきたチームが自分たちでリプレイスをやりたい、と思うのは当然だと思います。筆者たちも何度かトライしましたが、そのやり方でうまくいったことはありませんでした。リプレイス専属チームを作り、事例を作り、徐々に既存チームも巻き込み、最終的に融合するか、既存チームにシステムを移管する、という流れを取るのが有効です。
やっぱり普段の開発と並行してやっていくというのはまず無理なんだろうな. このあたり高い視点での判断も必要なので難しそう.
技術的負債解消のための知識として, 依存性逆転の原則とストラングラーパターン, Humble Object パターンが挙げられていて, 『Clean Architecture』を読んでいればわかることだけど, そもそも知識がないと負債解消できないよねというのは「質とスピード」を思い出した.
アプリケーションの特性に合わせてリードとライトをうまく設計しましょうということだと思います.
こういう全然知らないサービス紹介してくれるの助かる.