ken1flanのブログ

自己紹介・最近やってることなどを書くつもりです。

良いコード/悪いコードで学ぶ設計入門 14章のメモ

gihyo.jp

良いコード/悪いコードで学ぶ設計入門読書メモです。

長いので章ごとにしてます。

14章 リファクタリング ー既存コードを成長に導く技ー

  • 実務では未熟な設計やコードでスタートするので、この章に期待…!

14.1 リファクタリングの流れ

  • また読みにくいコードが…。
  • この順番通りに処置していくのがオススメとかあるのかな?

14.1.1 ネストを解消し、見通しを良くする

  • せやな。

14.1.2 意味のある単位にロジックをまとめる

  • せやな。

14.1.3 条件を読みやすくする

  • Rubyは標準ライブラリも否定のメソッドがいっぱいあるので、扱いやすいし、真似たくなります。

14.1.4 ベタ書きロジックを目的を表すメソッドに置き換える

  • プログラミングは…要約の作業かも?
  • Customer.isShortOfPoint って、ちょっと微妙感ありません?
    • PurchacePoint.isShort とかダメですかね…?

14.2 ユニットテストリファクタリングのミスを防ぐ

  • 悪魔を呼び寄せるようなコードにはテストがない……わかる……。
    • テストを書いてると、アレ?ってなって、コードを改善したくなるから、ひどくなりにくいかと思ってます。

14.2.1 コードの課題を整理する

14.2.2 テストコードを用いたリファクタリングの流れ

  • あるべき構造のひな形をつくっておくのはなるほど、ちょっとよさそう…!
  • ひな型のクラスに対してテストを書くのは、無駄にならなくて、精神衛生上かなりよさそうです!
  • レッド、グリーン、リファクタリング

14.3 あやふやな仕様を理解するための分析方法

14.3.1 仕様分析方法1:仕様化テスト

  • テストコードって、繰り返し実行しやすいから、仕様を探索するのに使いやすいのはわかります…!
    •  …だけど、こんなに少ない引数のだったら、コードを読むのも苦労しなそう。
    • 複雑なときもいけるのかな…?
    • 繰り返しやすいから、やっぱりやりやすそうです。

14.3.2 仕様分析方法2:試行リファクタリング

  • 読みやすくするためのリファクタリングかあ。
    • 捨てる勇気がなかなか…。わかってはいるんですが…。

14.4 IDEリファクタリング機能

  • IDEリファクタリング、まだあんまり使ったことないんですよね…。
    • IntelliJ IDEA、よさそうですが、高いんですよね…。
  • ひとつのファイル内なら、copilotにやってもらえるかも。(練習中)

14.4.1 リネーム(名前の変更)

  • これ、めっちゃほしい…けど、VSCodeRuby使ってるときにはないようで…?
    • 「シンボルの変更」を試したけど、同一ファイル内しか…。
    • 結局、grepして置き換えかあ…。
      • それでも、レビューとテストでガードしてれば、ある程度怖くないかも。

14.4.2 メソッド抽出

  • こういう細かいのも、やってもらえるならアリなのかなあ?

14.5 リファクタリングで注意すべきこと

  • 速いテストと小さい改善は相性がよさそう…。
    • テスト、前50分くらいかかってました…。今25分…。

14.5.1 機能追加とリファクタリングを同時にやらない

  • 同時にやってしまう理由は…?
    • プルリクエストがマージされるまでの時間がかかってしまうこと?
    • ほかにはなにかありそう?

14.5.2 スモールステップで実施する

  • コミットログでストーリーを語る…やりたいけどなかなかできないです><

14.5.3 無駄な仕様は削除することも視野に

  • やるやる、めっちゃやる!

Column Railsアプリのリファクタリング

  • ReadyForのことですよね。
  • 型のある言語だと、確かにリファクタリングはしやすい…ですね。
  • Rubyの型を使いこなせるようにしていかねば…。

「良いコード/悪いコードで学ぶ設計入門」読書会 第19回を開催しました

「良いコード/悪いコードで学ぶ設計入門」読書会 第19回 を開催しました。

academist-reading.connpass.com

みんなで書いたホワイトボード

良いコード/悪いコードで学ぶ設計入門」読書会 第19回 ホワイトボード

感想・気づいたことなど

  • 13.1のユーザクラスのサンプル、ありがちな例でめっちゃよかったので、本文でちゃんと使ってほしかったです><
  • OOPでいきない設計せずに、データ設計からはいることが多いです、という話が出て…そういえば自分もそうなんだと気付かされました。
    • ヒアリングとかをするときに、モデルで話すよりは、オペレーションの現場で使っている帳票を下に、正規化などを施したものを確認していく、みたいな進め方してました。
  • モデルをどこに書くのがいいか、どうやってメンテナンスしたらいいか、みんなに訊きました。
    • mermaidなどに限定してしまうとチーム内で描ける・描けないが出て、本末転倒なので、あえて限定しない…!
      • この視点はとても大事にしたいと思いました。
    • 更新漏れは…起きますね!
      • 仕方ないかも。都度直せばいいかも。
  • 13.3.1 Userとシステムの関係で、「システムの中にユーザがいない」は納得でした。ちょっと書きにくいと思ってたので…。あるのはユーザに関する情報、かも。
  • 値オブジェクト、言語やフレームワークによるやりやすさとプロジェクトでの必要性を踏まえて、判断するのがよさそう、という空気感になりました。
    • 実際にいれるかどうかは別にして、サンプルプロジェクトで書いてみることだけはやっておきたいです…。

運営としてのふりかえり

KPT方式で。

Keep

  • 時間前に会場を開けておけました。
  • 常連の方がきてくれました!
  • リピートしてもらえました!

Problem

  • 今日の章、やりにくかったです…。
  • ちょっと時間をオーバーしてしまいました。
    • 5分程度だったので、まぁヨシとさせてください…。
  • ホワイトボードの付箋の配置がよくなく、13.4を取り上げ忘れました><

Try

  • ホワイトボードの付箋紙の並びは前と同じにします。

おわりに

参加してくれたみなさん、ありがとうございました! あとでざっと見直しても、一人で読むより圧倒的に気づくことが多いので、今後も継続してやっていきたいと思います!

参照

「良いコード/悪いコードで学ぶ設計入門」読書会 第18回を開催しました

「良いコード/悪いコードで学ぶ設計入門」読書会 第18回 を開催しました。

academist-reading.connpass.com

みんなで書いたホワイトボード

良いコード/悪いコードで学ぶ設計入門」読書会 第18回 ホワイトボード

感想・気づいたことなど

  • 12章全体が以前の章の振り返りのようになっていました。
  • 12.5.1 引数は不変にすること
    • 基本的に引数は値渡しですが…オブジェクトはそうでなかったりします…。
    • Rubyだとfreezeがありますが…毎回やる?やったらやったでfreezeしっぱなしでは…。
    • 値オブジェクトはfreezeしちゃってもよさそうですが、エンティティのようなものは…?
    • どうしたら現実的に運用できそうなのかさっぱりわからないということが、ここでわかったことかもしれません。
    • 「引数が単純に参照渡しになるような言語設計の失敗がプログラマにしわ寄せされているだけ」という付箋紙になんとなく自分も同意です。
  • 12.6.1 「型」を使って戻り値の意図を表明すること
    • 型があるlintやコンパイル時にエラーがわかっていいですよね、などという話が出ていました。
    • Rubyも外部から型情報を渡せるようになってきたので、試したい!と思いつつ、自社環境がまだ3.0なので、3.2にしたらやろうと、決心したところです。
  • 12.6.3 エラーは戻り値で返さない、例外をスローすること
    • ここの文章だけだと、何でもかんでも例外にしちゃおう、みたいに読めました。
    • 参加者の中では、エラーと例外を分けたほうがいいんじゃないか?ということになっていました。
  • 全体的によい議論ができて、とても楽しかったです!!

運営としてのふりかえり

KPT方式で。

Keep

  • 時間前に会場を開けておけました。
  • 常連の方がきてくれました!
  • 新しい元気な方が参加してくれました!
    • connpassで見つけてくれたようです。
    • 有名な本を題材に読むのはやっぱりいいですね。

Problem

  • 落ち着きのない進行になってしまいました…。
    • 新しい方が来てくれて、ちょっと舞い上がってしまっていました。
    • だって、うれしいんですもん。

Try

  • 新規参加しやすいよう、呼びかけの種類を増やしたいです。

おわりに

参加してくれたみなさん、ありがとうございました! あとでざっと見直しても、一人で読むより圧倒的に気づくことが多いので、今後も継続してやっていきたいと思います!

参照

良いコード/悪いコードで学ぶ設計入門 13章のメモ

gihyo.jp

良いコード/悪いコードで学ぶ設計入門読書メモです。

長いので章ごとにしてます。

13章 モデリング ークラス設計の土台ー

13.1 邪悪な構造に陥りがちなUserクラス

  • うわあ……ありがちw いいサンプル!

13.2 モデリングの考え方とあるべき構造

  • 突然説明パートになっちゃいました?

13.2.1 システムとは何か

  • ですね!

13.2.2 システム構造とモデリング

  • 「特定の目的達成のために最低限考慮が必要な要素を備えたものがモデル」
    • どうやって構成をまとめた文書をメンテナンスし続けたらよさそう…?

13.2.3 ソフトウェア設計におけるモデリング

  • なんでも書いちゃうと目的がぼやける、というのはわかります。
    • 絞って書いたほうが確かに目的がわかりやすいです。
  • メンテナンスするんでしょうか…?

13.3 良くないモデルの問題点と解決方法

  • 辛辣ですねぇ…。
  • 「社会活動や目的の理解が必須」
    • わかります!…が、辛辣ですね。

13.3.1 Userとシステムの関係

  • 「システム内にユーザがいない」なるほど、なんか書きにくい気持ちもしていました。

13.3.2 仮想世界を表現する情報システム

  • まぁ…せやな。

13.3.3 目的別にモデリングする

  • 実世界とシステム上のユーザが1:多って何事かと思いました。
    • 目的によっていろんなモデルに分かれるよ、ということですね。

13.3.4 モデルはモノではなく目的達成手段

  • まぁ、わかりますが…。

13.3.5 単一責任とは単一目的

  • いい言い換えかも。
  • 「共通利用可能な、汎用的な部品」…そんなことを言ってるのもあったんでしたっけ……。

13.3.6 モデルの見直し方

  • ひとにシステムを説明するときには確かに全部は書きませんが…。

13.3.7 モデルと実装は相互にフィードバックする

  • ううむ…じゃあ、モデルは今後どうやっていくの…?
  • 図13.10 … ああ、そうか、値オブジェクトがいっぱいあるからですかね…。

Column クソコード動画「Userクラス」

  • プロジェクト最初期からモデリングに心を砕けって…ムリでしょ…。どんな恵まれたメンバーなんですか…と思ってしまいました。
  • 今自分がその場になったら、気にしてやりますが…なかなかそういうこともないもので…。

13.4 機能性を左右するモデリング

13.4.1 裏に隠れた真の目的を見破る

  • 「法的な顔」
    • 最初からわかってれば!は同意です。
    • ドメイン知識も乏しい中で、どうやって最初から引き出せるのか、方法を知りたいです…。

13.3.2 機能性をイノベートする「深いモデル」

  • 目的によって分類の仕方が変わるのはたしかに…。
    • 自然にやってると思いますが…。
    • スーパーのアプリとかやってたら、魚類の前に青魚、白身、赤身みたいに入れるかもしれないし。
  • 深いモデル…うーん、プロダクトチーム全体で日々の議論が必要な感じが…。
  • 会社でちょくちょく議論するときに、情報の構造をホワイトボードに描くようにしてますが、たしかに効果を感じてます。

第52回Software Design (2024年2月号) 輪読&座談会 に参加してきました

いつもおせわになっている52回Software Design (2024年2月号) 輪読&座談会に参加してきました。

softwaredesign.connpass.com

  • 今回スゴイ人数で、めちゃくちゃ賑わってました…!
    • そういえば危うく参加登録できないところでした…。
    • チャットも大盛り上がりで…しゃべっているのを聴きながら読むのは無理でした…。
      • Zoomの機能でダウンロードできたので助かりました。あとからゆっくり読もうと思います。
  • ひみつのLinux、今回のFはFin.のFだそうで…読み落としてました。なるほどです…!
  • 第一特集のテストの著者の方や、テストに詳しい方が多く、大変学びになりました。
    • チームのテストスキルの底上げ方法は?と訊いたところ、みんなで同じ課題に対して、テストを書いて比べたりしながら、議論しているとのことでした。
    • TDDのテストは作るものが動作するかどうか行うチェッキングで、QAのテストはこうしても壊れないだろうか?と確認するテスティング
      • t-wadaさんの資料に合った言葉だそうです。
        • もうちょっと正確な出典を教えていただきました :pray:
    • テストが十分どうかのチェック
      • すべての状態を通っている or すべてのアクションを行っている が目安
    • 状態遷移表を作ったときに、空欄になる部分が仕様の定義されないことが多い…。
    • いろんな立場の人を集めて、よく議論するのが大事だそうです。
      • うちは人数が少ないから、必然的にできているかもしれません。
  • ハピネスチームビルディングもだいぶ盛り上がっていました。
  • 毎回自分のメモを開いてくれるので…ちょっと章立てを見直します…。
    • 上にまとめて訊きたいことを書いてあると、混乱されがちで :pray:

今回は特に刺激的な会でした。 また次回も行こうっと。

2024年01月

1月何したっけ…?というまとめ。

以前のまとめ

Special Thanks

Software Design 2024/02 メモ

Software Design 2024年02月号を読んで、ちょこっとずつ感想を書いてます。

gihyo.jp

全体を通しての感想

輪読会で聞いてみたいこと

第1特集 QAも、アプリ開発者も テストの設計してますか? 新しいソフトウェアテスト講座

  • 開発チームのテストのスキル、どうやって底上げしていますか?
    • うちは…メインが自分だけなのでアレですが><

第2特集 あなたのサービスは大丈夫? ゼロから学ぶWeb APIセキュリティ 設計から始める攻撃対策

  • セキュア開発のトレーニングとかされてます…?
    • うちは…><
  • 脆弱性診断とかされていますか?どんなものを使っていますか?CIに入れているとか?
    • うちはRuby用のreekだけですが…。
    • OWASPのZAPのオートメーションとか使ってましたら、感想をいただけると!

あなたの知らないChromeの世界【新連載】Google Chromeの登場 ......小河 亮

  • β版使ってますか?
    • 自分は…使ってません!

ぼくらの「開発者体験」改善クエスト【2】開発者体験を計測しよう――Four Keysの意義と使い方 ......高山 温

  • 開発者体験の計測、されてますか?
    • うちは…してません><
      • やってもよさそうだと思いつつあります。

表紙

  • ふわふわっと…かわいらしげですね…。
  • あっ!!400号記念!!おめでとうございます!!!

第1特集 QAも、アプリ開発者も テストの設計してますか? 新しいソフトウェアテスト講座

  • CIに組み込まれて、ホントに安心できるようになりました…万歳!

第1章:ソフトウェアテストとは何か? 目的、プロセス、活用方法から新しい考え方まで ......風間 裕也

  • www.istqb.org
  • jstqb.jp
  • 要件、ユーザストーリーにテストがあることを開発者以外に理解してもらうのに苦労しているような…。うまく説明したいです…。
  • テスト分析、テスト設計…できてないです…!
  • 要求の検証以外に、明文化されていないけど気になることを確認する妥当性の検証も…わかる…。
  • 作業の狭間に落ちるものって、わかる気がします…。
    • この間、めっちゃやりました。
    • …といっても、動かしてみないと想像つかないこともあるから、仕方なかったかなと思ってます。
  • 「テストするなら」という思考法……これ、かなりよさそうですね。
  • テスト分析は「こういう内容はテストしよう」
  • テストの条件につける名前は、値について書いちゃってました…。具体的に書くべきだと思ってたから…。
    • あとからみたときに、と考えたらその値を選択した理由を盛り込んだほうがよさそうですね。
  • 継続的テストモデル…どこでもテストができる…そういう考え方は結構いいかも…。
    • そもそも、なにかしようというなら、それの確認方法について考えておけって意味でもありますよね。

第2章:テスト技法の基礎 効率的なテストケース作成のポイント ......谷﨑 浩一

  • テストを効率的にやる手法があるのは知っているのですが…そこまでやったことがないかも…と思ったら、ところどころ使ってますね。
  • なるべくifがないように工夫はしてるかも。
  • ホワイトボックステストだったのか、テストカバレッジ…意識してませんでした。
  • チェックリストベースドテスト、最初にシステムスペックを導入するときに使いました。
    • 何ができてたらチェックOKということにしてました?と運用メンバーにインタビューして、それをベースに作りました。
  • …なんか自然に使ってるのかも。

第3章:探索的テストで短時間で効率よくバグを見つける やみくもにテストしないためのコツ ......根本 紀之

  • コツ??気になる…!
  • ずっと昔に勤めてた職場に普通に操作しているはずなのに不具合を見つけるひとがいたのを思い出しました。
  • 学習、テスト設計、テスト実行を同時に
    • なるほど…学習と設計が大事かも。
    • 同時にやってるんだという意識を持って、やっていこ。
  • 基本的なテスト技法は使えるようにしておく
    • 探索しながら、そういう場面に出会いますもんね…。
  • 探索的テストって…すべての技を使った総合格闘技的、というのは納得です。
  • 探索的テストの進め方
    • 事前準備
      • 開発者として不安なところはあるか?…事前に訊いておくと確かにスムーズになりそうですね…。
      • チャーター?
        • 事前にチームと対象/リソース/情報などを擦り合わせておく…。
          • 確かにはみ出しすぎたら戻ってこれそうです。
    • まとめと共有
      • 気になったこと、バグと再現手順
        • せやな…!
  • セッションベースドテスト
    • ざっくり方針くらいをまとめて実施すると、スキルのばらつきが小さくなる……たしかに!
  • 注意点、これいいかも。事前に目を通したくなってきました。
  • この話、全体的によかったかも。

第4章:シフトレフトテストを支える現代的なテスト設計 テスト全体の基本設計の工夫でテストの恩恵を拡大する ......井芹 洋輝

  • シフトレフト
    • いろんな図で時間の流れが左から右で表現されていて、それを早い段階から前倒ししよう、左側へ寄せよう、そういう話みたい。
    • アジャイル開発の、プロジェクト初期から何かしら動くものを届けていくことでやっていることで叶えてることかも?
    • 普段開発しているときに…
      • チームメンバーにやっていることを説明しているのもこれに近いのかも。
        • 作り出す前に完成図を共有
        • ざっと動いただけの低品質の状態な状態でデモ
  • 現代では当たり前の活動だから、より効率的にしていこう……なるほど…!

第2特集 あなたのサービスは大丈夫? ゼロから学ぶWeb APIセキュリティ 設計から始める攻撃対策

  • Web API、うちは…まだ使ってないですが…今後はそっちのほうに行くだろうし…予習!

第1章:APIの開発・保守をするなら押さえておきたい Web APIに潜むセキュリティリスク ......石川 朝久

  • APIっていっても、そんなに普通のWebアプリと変わらないように見えますが…見づらいからやりがち、みたいな面があるんでしょうか…?
  • APIのレスポンスを信じすぎる…これはどうしたらいいんでしょう…?
  • セキュリティバイデザイン…?
    • www.ipa.go.jp
    • 開発の各工程でセキュリティを確保せよ、と…。
      • 社内開発だと当然といえば当然かなぁ…。ちゃんと話できるもん。
  • うーん……社員数が多ければこういったことは少しずつ得意な人がいて担保されそうだけど、ひとりだとシンドいですね…。
  • あちこちに自動検知を仕込んで回らないとアカン気がします…。

第2章:DevOpsとシフトレフトを起点に考える Web APIセキュリティの重要ポイント ......徳丸 浩

  • これもシフトレフト…!
  • 開発者にセキュア開発のトレーニングを定期的に…?!
  • cookieもlocalStorageもセキュリティ上は変わらんだろ?と思ったら変わらないそうでした。
  • Log4Shellの話が……。
  • ところどころにセキュリティスキャナ入れたい……。

第3章:正しく検知して攻撃経路をふさぐ 脆弱性 ......松本 隆則

  • 学習用のアプリがあるのはありがたいです。
    • 作り込むの、結構大変ですもん…。
    • github.com
  • 検出ツールも…。

第4章:サービスを不正アクセスから守る 認証・認可 ......川村 修平

  • www.keycloak.org
    • …知りませんでした!よさそう…。
    • 機能が至れり尽くせりです…。
    • railsで試されてる方もいる…!

一般記事

[創刊400号記念特別企画]表紙で振り返るSoftware Designの歩み ......編集部

  • 結構、扱う内容が変わってきているんですね。
    • 自分の印象はインフラ/サーバ管理者向けでした。
  • 今、だいぶ幅広くて…情報収集にめちゃくちゃ役立っていて、ホント、助かっています。
  • これからもよろしくお願いします!!!

連載:Column

平林万能IT技術研究所 2ndシーズン【21】日本列島を伝わる「地震の波」を可視化する――強震観測網がとらえた震動データを分析してみよう ......平林 純

  • 時間を掛けてデータを眺めてみたいところ…。
  • いろんなデータが公開されていて、colabがあって、chatgptがあれば、案外いろんなことができそう…。

ハピネスチームビルディング【23】誰に対してもリスペクトの気持ちを持って接する ......小島 優介

  • 「誰にでもリスペクト」…当たり前なんですが、それが難しい…。がんばっていこう…。

    • だれにでも「丁寧語」はやってるつもり。
    • 一斉にあだ名で、というのもおもしろそうですね。  

      エンジニアのためのやる気UPエクササイズ【18】デスクワーカー必見! エンジニア向け簡単コアトレーニング ......えくろプロテイン

  • これよさそう…ちょっとやってみるかなぁ…。

    • ちょっとやってみてますが…結構いい感じですね…。伸ばす筋肉に力が入っている感じで、姿勢がよくなりそう。

あなたのスキルは社会に役立つ~エンジニアだからできる社会貢献~【146】4年ぶりの対面会場! Code for Japan Summit 2023 ......武貞 真未、田中 伶奈

  • 動画が公開されてました…!
  • 大人の文化祭…たしかに!
  • NERVが…!
    • データだけがあってもすぐに役立つわけではない……ですよね。。。
    • フォーマットもタイミングもバラバラの災害情報を整理統合して提供…。これ、なにげにスゴイですよね…。
  • IDEO!
    • AI/MLへの適合が遅れた組織や個人が被るマイナスの影響……気になります…。
    • T字型人間
      • 手を広げてる…!なんかいい言葉ですね…。

ひみつのLinux通信【最終回】Fワード ......くつなりょうすけ

  • スゴイ風紀部…詳しすぎではw
  • これ、どうやって思いついたんだろ…?
  • 連載、ありがとうございました!
    • 毎回クスリとさせてもらってましたが…なくなってしまうのはとても寂しいです…。

連載:Development

あなたの知らないChromeの世界【新連載】Google Chromeの登場 ......小河 亮

  • Chromeが最初だったんですね、マルチプロセス…!
    • ようやくアクティビティモニタの大量のchromeの意味がわかりました。
    • タブにしやすいのも、別れていることでセキュリティの担保が比較的容易なのも納得です。
  • Stable版、4週ごとのアップデートだったのか…。
  • ITスタッフはBetaを使え…?マヂか…。
  • 単純におもしろかった…!

Google Cloud流クラウドネイティブなシステムデザインパターン【新連載】 ......北野 敦資、(監修)阿部 正平

  • GCPも連載が始まる…。AWSだけしか使えない、とはなりたくないので、ありがたいです。
  • 層にするという考え方、知りませんでした。結構わかりやすいかも。
  • CloudSQLのAuth Proxy、便利でいいなぁ…。

ぼくらの「開発者体験」改善クエスト【2】開発者体験を計測しよう――Four Keysの意義と使い方 ......高山 温

  • 開発者体験の定義が「プロダクト開発に関わるすべての人々」であるところがとてもよさそうです。
  • Four Keys
    • …案外高パフォーマンス組織だった!
      • ほとんどライブラリの自動アップデートだけど…。
    • 計測ツールあるの…?
  • デプロイ頻度の可視化から…。
    • 4つ同時じゃなくてもいいのか…。ちょっと安心…。
    • できそうなところから、というのもいい感じです。
  • なにかの数値をみんなの見えるところに出す、というのは確かに筋がよさそう。
    • 自分も共有会でエラー数とかダウンタイムとか共有してるのは…なにか問題が起きたときに対処したいのだと説得する材料になりそうだから…というのもありました。

実践データベースリファクタリング【3】UIの重力 ......曽根 壮大

  • UIの情報設計が破綻していたときに、テーブル構造も破綻…そりゃそうだ…。
  • あー…うーん……この例、わかりすぎる……。
    • ドメイン知識がついてこないと、この手の危険の察知ができないような…難しい…。
  • 注意点は納得…。
    • 「リリースすることが仕事」はいい言葉ですね。
    • 「しっかり」に傾きすぎないように気をつけます。
  • イミュータブルデータモデル…?
    • scrapbox.io
    • 5W1HのWHO/WHAT/WHEN/WHEREがリソース、WHY/HOWがイベント…なるほど…。
    • よさそうな雰囲気がしているので、後で読みます。
  • ライフサイクルで分割…。うちもやらなきゃなぁ…と思ってて、まだリファクタリングできていないものばかりです…。

Cloudflare Workersへの招待【3】作って学ぶCloudflare Pages ......福岡 秀一郎

  • CDNのエッジに小さなAPIを作っちゃおうって話…?
    • Pages Functions
      • 似たような構成は…AWSのLambda@Edgeでもできるのかな……?
        • RDSプロキシを使ってうんぬん…できるっぽい。
  • Pages … プラットフォーム
  • Pages Functions … Pages用のサーバレス関数、Workersを使っている。
  • Workers … サーバレス関数

実践LLMアプリケーション開発【5】LangChainで開発する初めてのAIエージェント(後編) ......西見 公宏

  • 図1のAIエージェントの流れ、結構いいかも…。
    • AIエージェントの定義、AIエージェントのループ、ツールプールの3つで構成されてることと、ユーザの入出力がエージェントループだというのがわかりやすかったです。
  • エージェントに利用できる関数のリストを渡すと、自分で判断して使うって…なんかすごい…。

画像解析AIの作り方【5】モデルの評価 ......髙木 優介

  • K-foldクロスバリデーション…確かにこれなら少ないデータで効率よく学習/検証/テストができそうです。なるほど。
  • 大きく消えてしまってるのは…そもそも無理やろ感があるけど、そういうものでもないのかなぁ…。
    • Fold1の24、Fold4の15は無理では…と思いましたが、自分が元画像を見てみるとなんか見えますね…不思議…。

MLOpsのすすめ【7】機械学習の推論システム ......澁井 雄介

  • 推論
    • へええ…言われてみれば学習とは違うけれど…なるほどです。
  • 用途によって信頼性もちゃんと設計しないとならないのは…なるほどです。
  • この連載、ホント幅が広いですね…。次回は異動ですか…!

位置情報エンジニアリングのすすめ【7】防災マップの作成② 地図の3D表現と土砂災害警戒区域の可視化 ......小松 聖

  • こんなデータも転がってるのかあ…。ゲームとか作れたりしそうですね…。
  • なるほど、立体の地形データと災害情報の組み合わせは…わかりやすい!

なるほど納得Go言語【最終回】ゴールーチンおまけ&ドキュメント ......崎原 晴香(H.Saki)

  • ゴルーチン、自身のreturnだけで終わるというのはわかりやすいですね。よさそう。
  • パッケージのドキュメントはdoc.goはわかりやすそうです。
  • ドキュメントの指針は言語に寄らないので、また参考にしにきます。
  • staticcheckで書いていないことをチェックできるの、いいですね。仕組で回るようにしたいです。
  • パッケージのExampleテスト、使用例とユースケースのテストを兼ねててよさそうです。
  • 「Goにおけるシンプルさ」はどの言語でも要りそうです。
  • 連載、ありがとうございました。
    • Goは仕事では使ってませんが、たいへん面白く読めました。
    • 面白かったのは、Goらしさが今担当しているRubyのプロジェクトでも応用できそうだったからかも…と思いました。
    • 言語は違えど、活かしていこうと思います。

AWS活用ジャーニー【17】AWS Organizations ......杉金 晋

  • アカウントの上の概念…これがあるなら、開発、ステージング、本番と分けられそう…。
    • 今、ごっちゃになってるから整理したいです…。
    • セキュリティの分離がめちゃくちゃしたいです…。
      • 余計な権限を持っていると、インシデントの際に各人の責務以上の疑いが持たれちゃいますから…。申し訳ないです…。
  • ワークロード?
    • workload
    • 負荷?
    • qiita.com
      • サービスを構成するシステム全体、かな…。
  • OUとかいろいろ知らないことが…。
    • まずはアカウントの分割をやってみるべきか…。

連載:OS/Network/Security

ドメイン解体新書【新連載】ドメイン基礎知識 ......谷口 元紀

  • 1人エンジニア…自分か!連載楽しみにしています…!
  • TLD
    • すぐにTop Level Domainだと出てこない…。
      • TDLと勘違いするほどではないけれど。
    • 最近の長いのは覚えてないけど、そんなものなのかなぁ…。
    • 略号が多くて…難しい><
    • TLDも買えるのか…!
  • レジストリレジストラ、リセラー
    • …わかりにくいけど、役割を分類したらこうなりますね。
  • *.example.comワイルドカード証明書sub1.sub2.example.comが対象外なのを知りませんでした><
  • ホスト名とサブドメインの関係がなるほど…となりました。
  • たまにまとめて読むとよいなぁ…と思いました。

現場から学ぶAWSクラウドセキュリティ【最終回】セキュリティインシデントへの対応 ......花塚 亮祐

  • docs.aws.amazon.com
  • インシデントが起き得る領域がサービス・インフラ・アプリケーションとなっていて、なるほどな切り分け方に感じました。
  • クラウドのインシデントの特徴のところ、かなり大事そうに見えます。
  • 「よりよく」のガイドラインは…クラウドかどうかに関わらず、大事そう。分析環境は…使いこなせなそう><
    • 自分が成長するか、得意なメンバーが来たらやりたいですね…。
  • 連載、ありがとうございました!大変参考になりました!

魅惑の自作シェルの世界【15】ジョブの制御――プロセスグループ ......上田 隆一

  • やっぱりパイプ、つまると固まっちゃうんですね…。シェル、スゴイな…。
  • プロセスグループ、ちゃんと知りませんでした。
    • バックグラウンド処理の単位…。なるほどです。

アラカルト

ITエンジニア必須の最新用語解説【182】.NET 8 ......杉山 貴章

  • また速くなったの…?凄まじいですね…。
    • .NETが出た当初からJITコンパイル、すげぇと思ってましたが…いやはや…。
    • Webアプリばかりなので、触る機会がないのがちょっと残念ですが…気になります…。

読者プレゼントのお知らせ

  • 4KワイヤレスHDMI送受信機
    • ACアダプタじゃなくてUSBなところは◯かも。
  • クリップ付き電子メモパッド
    • この手の機械、気になっているけど…。
    • 紙のほうが軽いし場所も取らないし表現力も豊かで断然いいはずなのに、何故かほしくなるのは…なぜ…。
    • 置いてあるときの存在感かなぁ…。

バックナンバーのお知らせ

SD BOOK REVIEW

  • Efficient Linux コマンドライン
    • こういうの、ゆっくり読みたいけど、後回しになりがち…。
    • cdを使いこなすって……すごいですね…。
  • LEADING QUALITY
    • 品質保証の文化の作り方…!
    • 気になる……。Bookmeterの読みたい本へ。
  • systemdの思想と機能
    • gihyo.jp
    • 渋い…。読みたいけど、優先度低いかなぁ…。地味に役に立つんですが…。
    • Staff Roomにも情熱が語られていました。
    • ううむ、悩む…。
  • その仕事、AIエージェントがやっておきました。
    • 自律的なものも出てきてるんですか…!
    • 期待!

SD NEWS & PRODUCTS

  • プロダクトマネージャーに求められる覚悟
    • 2023.pmconf.jp
    • 「カネを利用する覚悟」
      • 新しいツールを頼むときに少額でも結構悩みます。本当に使って効率が上がるのか…と。
    • こういった決断を「覚悟」を持ってし続けるのかと思うと、ホント大変だと思います…。
  • 2023年11月に最も活発だったマルウェア
    • FakeUpdates
      • 出会ったことはないですが、確かにこういうの、ありそうですね…。
      • ツライ><
  • 既設光ファイバーを用いた大容量マルチバンド波長多重伝送に成功

次号のお知らせ

  • ドメイン駆動設計【実践】ガイド
    • おお…これはありがたい感じです!
  • 使って試す次世代高速RDB「Tsurugi」
    • Tsurugi、たぶん使う機会はしばらくなさそうなんですが…なんかドキドキするんですよね…。
  • いくつか連載が終わったので…次はどんなのがくるんでしょう?

特別広報

グローバルへ挑戦するココネのエンジニアリング力を探る【8】最新テクノロジーでサービスを構築したメリット ......編集部

  • catclub.world
  • なんか規模がすごいですね……。想像もつかない……。
  • 人数が多そうだから、新しいことをやることが結構怖くないかもしれません。
  • かわいいが多いのはいいですねえ。