■ トピック AIを使った新規開発 新しい技術への対応 AIの「記憶喪失」問題 生前贈与型アプローチ fidxの開発 OSS公開の容易化と心理的ハードルの低下 AI時代のセルフコードレビュー v1.0.0リリースの覚悟 ■ 参考リンク Claude Code GitHub - crescware/fidx GitHub - yoshiko-pg/difit ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック 既存コードベースでAIをどう使う？ LLMに任せる作業の種類 README.mdを書かせる コードベースの「地層」問題 リファクタリングの新たな目的 ■ 参考リンク Claude Code ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック 桜井政博のゲーム作るには 「お客さんに説明できるの？」 ヘルプメッセージへのこだわり 「監修あれこれ」 名前の回「ファイル名は合理的に」 「仕事の姿勢」シリーズは新卒におすすめ ■ 参考リンク 桜井政博のゲーム作るには - YouTube #73 銚子ドライブ編③ どうする？新人エンジニア育成 lacolacoイチオシ回 - お客さんに説明できるの？ 【仕事の姿勢】 メニューにヘルプを 【UI】 okunoイチオシ回 - 監修あれこれ 【グラフィック】 ファイル名は合理的に 【プログラム・テクニカル】 ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック コードレビューする側で考えていること、やっていること 自動化できないルールを守らせるのは無理 LLMを使ったルールの非決定論的自動化の可能性 AIによってルールがねじ曲がった例 LLMのためのコード内コメント コードレビューのWhyに立ち返る ■ 参考リンク 秀和システム『Looks Good To Me』 #20 コメント① コメントを「ちゃんと書く」って何？ #74 リンター/フォーマッター① Prettierは脳にインストールされている ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック プルリクエストを出す側の話 誰がレビュアーか念頭に置いてコードを書くか レビュアーのコメントをドキュメントの材料にする 「リファクタリング定例」 セルフレビューの重要性 diffの出方にこだわる美意識 ■ 参考リンク 秀和システム『Looks Good To Me』 #32 Diff① 「ついで直し」はボーイスカウトルールではない ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック 秀和システムから発売されたコードレビュー本『Looks Good To Me』の紹介 コードレビュー本ブーム セルフレビューの責務 バグの発見をコードレビューの目標に含めるべきか AIコードレビューの限界 次回からコードレビューの現場編へ ■ 参考リンク 秀和システム『Looks Good To Me』 Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考 - 秀和システム 秀和システム『Looks Good To Me』を読んだ | lacolaco's marginalia ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック vol.77のV言語に続き、新しい言語を学ぼうシリーズ okunoがMoonbitを学んでみた WebAssemblyに特化した言語 構文の特徴 エラーハンドリングの癖が強い 嬉しい検査例外 入門してみての感想 「年に1つ言語を学ぶ」ことの重要性 達人への道は続く... ■ 参考リンク 達人プログラマー（第2版） 熟達に向けたあなたの旅 | Ohmsha MoonBit ReScript WebAssembly ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック lacolaco のTSKaigi 2025登壇からSignalについて掘り下げる Signalとは何か？ なぜ今Signalが盛り上がっているのか？ Qtに遡るSignalの歴史 Signalを標準化する意味とは？ いろいろやっておくと点と点がつながる ■ 参考リンク TSKaigi 2025 TSKaigi 2025のYouTubeチャンネル TSKaigi 2025「SignalとObservable ― 新たなデータモデルを解きほぐす」発表スライド TSKaigi 2025「SignalとObservable ― 新たなデータモデルを解きほぐす」補足解説 Qt tc39/proposal-signals Signals - Solid Docs useSignal() is the Future of Web Frameworks ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.ap...
■ トピック TSKaigi 2025で登壇してきた話 lacolacoの登壇内容 TSKaigi会場で出会ったリファラジリスナー 今年のTSKaigiの感想 最近のリファラジの数字 ハッシュタグ投稿よろしくお願いします 次回はlacolacoの発表内容掘り下げ ■ 参考リンク TSKaigi 2025 SignalとObservable―新たなデータモデルを解きほぐす | TSKaigi 2025 TSKaigi 2025のYouTubeチャンネル Anthony Fu ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック 達人プログラマーの「シェル遊び」 IDEに頼るな 使っているシェル Ghosttyを試してiTerm2に戻った話 自分の道具箱を磨け プログラミングスキルとタイピング速度 キーボードショートカットの重要性 「今何した？」 Raycastへの乗り換え 1年に1回ツールを変えよう ■ 参考リンク 達人プログラマー（第2版） 熟達に向けたあなたの旅 | Ohmsha Ghostty is a fast, feature-rich, and cross-platform terminal emulator Raycast - Your shortcut to everything ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック 『達人プログラマー』におけるプレーンテキストの威力 プレーンテキストとは何か？ Unix哲学とプレーンテキスト LLM（大規模言語モデル）の登場とプレーンテキスト データ形式の選択：Excel, WordよりCSV, Markdown 奥野のブログ記事管理方法 データロックインからの解放 プレーンテキストへの揺り戻しとObsidian ■ 参考リンク 達人プログラマー（第2版） 熟達に向けたあなたの旅 | Ohmsha プレーンテキスト - Wikipedia UNIX哲学 - Wikipedia Obsidian - Sharpen your thinking ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック 達人プログラマーへの道 V言語の概要と出自 あなたがもしGOを知ってるならもうVの8割は知ってます printlnのおもてなし dump 機能がすごい デフォルトでイミュータブルな変数 Result型・Option型の第一級サポート V言語の嬉しさ V言語のつらさ 新しい言語を学んで気づくいつもの言語のありがたさ ※ vlang/setup-v は後日ちゃんと動かせました コントリビューションチャンスがいっぱいありそう ここから2回、達人シリーズが続きます ■ 参考リンク 達人プログラマー（第2版） 熟達に向けたあなたの旅 | Ohmsha vlang/v 画面共有しているテキスト ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック okunoがBiomeを推す回 Biomeとは？ とにかく高速 Biome 2.0でプラグイン対応の予定 ASTをクエリする言語「GritQL」 デフォルト設定に注意？ 試してみよう ■ 参考リンク ESLint - Pluggable JavaScript Linter Prettier - Opinionated Code Formatter Biome, toolchain of the web Biome formatter wins the Prettier challenge | Biome GritQL ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック リンターの設定どうしてる？ 05:08 個人開発とチーム開発でのルール設定の違い リンターとCIの遅延 自作リンターで高速化 「あ、これじゃ俺も自作できんじゃないと思って」 ASTを触ることは怖くない ■ 参考リンク ESLint - Pluggable JavaScript Linter Prettier - Opinionated Code Formatter no-restricted-imports - ESLint Declutter your JavaScript & TypeScript projects | Knip ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック フォーマッターが普及してなかった時代 JavaScriptにおけるフォーマット・リンターの歴史 JSLintからJSHint、ESLintへ 強い思想とカスタマイズ性 Prettier普及前の思い出 個人開発とフォーマット・リント AI生成コードとフォーマット・リント ■ 参考リンク JSLint - The JavaScript Code Quality and Coverage Tool JSHint, a JavaScript Code Quality Tool ESLint - Pluggable JavaScript Linter Prettier - Opinionated Code Formatter Biome, toolchain of the web ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは ...
■ トピック 新卒・新人エンジニアは何を身につけるべきか トレーニング機会の減少と高度化 「桜井政博のゲーム作るには」全部見ろ ワークショップ「リモートドローイング」 文章力・チャット作法は教わる機会が少ない 専門知識・共通言語（語彙）の重要性 やっぱりレッド・グリーン・リファクタリング ジオゲッサーも研修になりそう ■ 参考リンク 「さかな料理 礁」 桜井政博のゲーム作るには - YouTube ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック マネジメントの話 リファクタリング観点のマネジメント マネージャーとしてのlacolaco 技術顧問としてのokuno 「噛み合い」と「持ち味」 SREにおけるリファクタリングとは？ 結局レッド・グリーン・リファクタリング 銚子に到着 ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック オープニング 物理的な構造物とリファクタリング 生成AIは「ガチャ」か？ AIコーディング支援と音声入力 生でJavaScriptを書く機会 リファクタリング前提言語としてのTypeScript トランスパイルと型チェックの分離 次回に続く... ■ 参考リンク AIは計画を立て時に嘘をつく — Anthropicが言語モデルの思考回路を解明 \| XenoSpectrum tc39/proposal-type-annotations ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック Chapter6 想定外の事態をなくす nullの話みんな好き 10年経っても変わらない 「値なし」についてどう考えてる？ プログラミング言語ごとに異なる「値なし」の扱い undefined vs null 結果なしをどうする問題（NullObjectパターン） Nullableを受け取るところ・受け取らないところ 「想定外の事態をなくす」 いかにユニットテストを短く書くか より少ないユニットテストでカバレッジを確保できるようにしたい 静的な検査と動的なテスト、契約のバランス 方法はユニットテストだけではない サンプルコードは架空の言語 『ルールズ・オブ・プログラミング』との共通点 やっぱり新人に教えたいことは共通している 著者の思想が出ている現場のドキュメント 『クリーンアーキテクチャ』との違い ■ 参考リンク Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考 - 秀和システム SQLアンチパターン - O'Reilly Japan O'Reilly Japan - ルールズ・オブ・プログラミング ■ おたよりフォーム htt...
■ トピック 『Good Code, Bad Code』の紹介 理論・実践・ユニットテスト 今回は第一部をメインに 『プリンシプル オブ プログラミング』とよく似た対照読者層 「正しく動作し続ける」ことへの思想 新人の教育で苦労してる姿が思い浮かぶ 例えが多いし的を射ていて上手い 「契約プログラミング」が第3章に出てくるのに驚いた 『ルールズ・オブ・プログラミング』でも「表明」について書かれていた 契約プログラミングは生成AIも読み取ってくれる 明確な契約は人間にとってもAIにとっても役に立つ 普遍性がありつつ、時代と噛み合ってる気がする本 次回はokunoのおもしろかった部分を紹介 ■ 参考リンク Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考 - 秀和システム プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則 - 秀和システム O'Reilly Japan - ルールズ・オブ・プログラミング ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Tw...
■ トピック アンクルボブのISP原則 ISPのこと意識してる？ 依存性逆転原則とごっちゃになりやすい SQLを例に考える 求めていないインターフェースにまで依存してしまうことを避ける原則 lodashのサブパッケージはISPに従っている？ いらないものに依存すると、不要なリスクやコストを抱えることになる 原則として認識してなくても、いろんなものに埋め込まれている GraphQLはクエリごとにインターフェースが分離される フェイクつくる君（第67回参照） ISPへの反論としてのカプセル化 結局は変更頻度？ 分離したインターフェースに名前がつけられるかどうか 一個のモデルとしてインターフェースを命名するときにはISPが意識されている SRPとISPは矛盾する？ いろんなプラクティスの背景にISPがある ■ 参考リンク Interface segregation principle - Wikipedia Lodash GraphQL ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.co...
■ トピック lacolacoとテストダブル フェイクオブジェクトのファクトリ関数を作る テストケースごとに依存するパラメータをすべて明示する どのテストが何に依存しているのかをはっきりさせたい HTTPクライアントと差し替え・スパイのしやすさ そもそもテストでHTTP通信を発生させるかどうか 本物を使いたい気持ちとツール依存度とのせめぎあい HTTPレスポンスが欲しいのか、データが欲しいのか ユニットテストを書き続けられる状態を保ちたい テストフレームワークの柔軟さに甘やかされる ikuma-tさんおたよりありがとうございました ■ 参考リンク GitHub - faker-js/faker Mock Service Worker - API mocking library for browser and Node.js Testing Library ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.a...
■ トピック okunoとテストダブル 時間が経つと複雑なテストが増える テストコードとDRY モック作る派 「神」はひとつに保つ expressとmswに二重管理された神レスポンス フィールドごとの意図の違いとコピペ事故のリスク アプリが大きくなって、モジュールが大きいままならテストもつらくなる テストを直接小さくしようとするより、モジュールを小さくしていく 次回はlacolacoとテストダブル ■ 参考リンク テスト戦略（テストピラミッド、テストダイヤモンド） Mock Service Worker - API mocking library for browser and Node.js express ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック ikuma-tさんからのおたより テストフィクスチャってなんだっけ？ フィクスチャはなにかの代替物というわけではない テストダブルの種類 xUnitというフレームワークの系譜 なんでも「モック」と呼びがち 『Good Code, Bad Code』のテストダブル解説が詳しい 次回からは神レスポンス、神モックとの戦いについて ■ 参考リンク XUnit Test Patterns - Gerard Meszaros Xunit - Martin Fowler's Bliki (ja) テストダブル - Martin Fowler's Bliki (ja) Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考 - 秀和システム ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファ...
■ トピック しゅうさんからのおたより リファクタリングとビジネスの折り合い 「リファクタリングをねじこむの大変」問題 リファクタリングだけをやったとして、その効果実感はいつ得られるのか？ リファクタリングをする前に完成することはない リファクタリングしないと恥ずかしくてコードレビューに出せない Good First Issueとしてのリファクタリング 泣きそうなトピックなら押し通す リファクタリングのスピード リファクタリングは練習可能 脳内リファクタリングでだいたい完成させておく すばやいリファクタリングの実績が次の説得を楽にする 割れ窓理論とAI AIは割れ窓も模倣してくる AIも新人扱いしたほうがよさそう 脳内リファクタリングはジャンキーですか？ ■ 参考リンク O'Reilly Japan - ルールズ・オブ・プログラミング ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile...
■ トピック ヒホさんからのおたより クラスを使ったリファクタリングの使いどころについて クラス構文を使ってないだけでクラスっぽいものを自作しているコード 何をどうカプセル化したいのか 継承を抜きにしてもクラスは便利 グリッド状メニューの実装 フレームワークの仕組みとの噛み合わせ そのリファクタリングで何を解決したいのか？ クラスという選択肢を完全に捨てるのはもったいない ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック リスコフの置換原則だけ浮いてる？ Javaが生まれる前に生まれた原則 リスコフの置換原則としては意識していなかった 『クリーンアーキテクチャ』より「正方形・長方形問題」 抽象的な型で受け取ったのに具体的な型での条件分岐が発生する タクシー配車サービスの例 SOLIDの中での存在感 もっといい名前はある？ 元になる型と派生型があればリスコフの置換原則は成り立つ 型として置換可能であることと、振る舞いとして置換可能であることを一致させる 関数の中でどうせ分岐するなら最初からシグニチャを分けたら？ 心当たりある人は多そう やはり『クリーンアーキテクチャ』は読むべき ■ 参考リンク リスコフの置換原則 - Wikipedia バーバラ・リスコフ - Wikipedia 「Clean Architecture 達人に学ぶソフトウェアの構造と設計」ＲｏｂｅｒｔＣ．Ｍａｒｔｉｎ - KADOKAWA ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■...
■ トピック Javaの知識が止まっているokunoさんのミリしら回 バージョンアップサイクルの変化 ローカル変数の型推論、ダイアモンド演算子 JEP(JDK Enhancement Proposal) パターンマッチング switch式が欲しい 賢いText Blocks Recordクラスが欲しい instanceofのパターンマッチング パターンマッチングが本当に欲しい Java 21 LTSは2031年まで switch式が欲しすぎる public static void main(String[] args) がなくなる？ われわれはJavaに嫉妬しています ■ 参考リンク Wikipedia Javaバージョン履歴 きしださんの記事一覧 Java8からJava11への変更点 - Qiita Java 12新機能まとめ Java 14新機能まとめ tc39/proposal-record-tuple: ECMAScript proposal for the Record and Tuple value types Java 17新機能まとめ Oracle、「Java 21」を...
■ トピック 更新系リクエストのスキーマについて REST的な発想 すべて必須フィールドにするか、オプショナルにするか /users/:id/name エンドポイント 大きなリソースの部分的な変更はグループ化してエンドポイントを分ける 変更できるフィールドを制限することで安全になる オプショナルなフィールド、空値での上書きとの区別が難しい 必須フィールドだけにしておくほうがよさそう ■ おたよりフォーム https://forms.gle/RYUG7T4ctmF7Srf36 ■ X（Twitter） https://twitter.com/refactoradio ■ Bluesky https://bsky.app/profile/refactoradio.com ハッシュタグは #リファラジ です。...
■ トピック shinshinさんからのおたより 寿司回で気になっていた、POST/PUTのレスポンスについて If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server SHOULD send a 201 (Created) response containing a Location header field that provides an identifier for the primary resource created and a representation that describes the status of the request while referring to the new resource(s). アプリケーションで使わないレスポンスの必要性 イミュータブルな単方向データフローにしたい 富豪的プログラミング Responses to POST...
