ken1flanのブログ

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

Software Design 2025/08 メモ

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

gihyo.jp

表紙

  • マンゴーを思い出すような、フルーティなカラーですね。
  • 「インコ 赤いくちばし」で画像検索したら…ヤマブキボタンインコかしら？

第1特集 自信を持って決断したい そのリファクタリング、今やるか？見送るか？ 適切なタイミングとビジネス面の価値

第1章：なぜリファクタリングは議論になるのか？ 定義を再確認して考える……米久保 剛

  • 振る舞いと構造を分けて捉える…これ、難しいよなあって思います。リファクタリングで済むコードって稀じゃない…？
    • そもそもテストがないこともしばしば。
    • テストを書いてから始めようというわけですが……そのテストが書きにくいこと書きにくいこと…。
      • ああ、だからテストなかったんだ、という発見に…。
    • …こういうときは作り直しって言ってます><
  • …でも読み進めていくと…いっぺんにやり過ぎだったかもしれません。
    • 散らかったコードの一部を切り出してメソッド化、メソッド化した部分だけテストを追加すれば…もともとの部分に対して振る舞いが書かれていようといまいと、既存の動作について言及しないので、リファクタリングって言ってもいいかしら。
  • 割引料金の例、めっちゃいいですね…！ゾッとするほど現実っぽい><
  • 「建設的な議論をするために」…は人数が少ない故にできているかな…。
    • ビジネスサイドに協力的な姿勢は、基本的にやってます。同じ会社の業績のために、ですもんね。
    • なんかよくわかんないけど、対立構造を作ろうとする力がどこからか湧いてきて、やりにくくなるときがあるんですよね…。現職は人数が少ないのでないですけど。
  • ソフトウェアの 経年劣化 は…ピンとこないですねぇ…。ソフトウェア単体では変わらないですもん。ただ…ひとことで言えって言われて難しいのもまぁ…。
    • ビジネスモデル、設計と実装の乖離
      • 突貫工事による本質に合わない実装の積み重ね
      • ビジネスモデルが変わる
    • 実行環境の変化
      • ネットワークで繋がっている周りの環境が変わる
      • 載っているハードウェアやOSが変わる
    • 知識の散逸
      • 人の異動

第2章：リファクタリングの実施判断力を養う どんなコードに対し、いつ、どのように取り組むか……家永 英治

  • 自分はリファクタリングは「振る舞いを変えない」を強く意識してるんですが…そこの認識が結構個人差が多そうですね…。
  • ああ、なるほど…。 小さなステップの連続性 のために Tidy が提案されてたんですね。
    • 小さい ふるまいを変えない 改善をウチももうちょっとやってこう。
    • しかし、ネーミングがかわいくっていいですねw
  • 影響範囲…小さくしていても、他のひとも近い位置をいじっているときには声掛けがいりますね。
  • 空気を吸うように毎日行う … 明日からやるかあー。
    • プルリクエストにタグをつけて個数の数えてもいいかも。
  • 帽子を被り直す という表現、結構好きです。
    • オフィスで働いてるなら、実際にやってもいいかもw
  • AIアシスタントの話が…！
  • コードの音読 …！
  • む…たしかにコードの内部品質が悪くて、作るのが思った以上にかかるとか…ありますね💦
  • 知識があったとて、ドメイン知識がちゃんとないと、リファクタリングの知識だけでは逆リファクタリングになりかねないですね…。（1章より）
  • 共通化してはいけないコードを共通化する……あんまりバグが頻発するんで、今度直そうとしてるところでした…。

第3章：アンチパターンから学ぶ適切なリファクタリング 破壊せよ！リファクタリングの地雷原……ミノ駆動

  • ミノ駆動さんの話、結構対立モノが多いんですよね…。これが現実なのかしら…。
    • 今のうちは少ないこともあって、そうじゃなかったし…前職もそうじゃなかったんですが…運がよかったのかも。
  • これまた幸いにも、逆リファクタリングをする人にはまだあったことがないです。
    • リファクタリングをしようという人が…そんなにいろいろ知らんなんてことが…あったら本当にしんどいですね…。
  • 値オブジェクトかあ。まだうまくRailsで使えてないんですよね…。
  • 1章と2章と結構被ってるかもしんないけど、大事なことは何度読んでもいいかも。

第4章：プロダクトマネージャー視点で考えるリファクタリング 「価値」から逆算する意思決定と覚悟……及川 卓也

  • プロダクトマネージャーって、コードに対する知識がいるのか…。
    • どの得意分野から来たとかはあるような気がしてますが…。
    • …よく考えたら、システムが中心のプロダクトなら、やっぱり必須ですね。
  • プロダクトの棚卸し…たしかにこれをやってくれると本当に助かります…！
  • プロダクトの管理の視点から見てくれるひとがいるとか、ホント良すぎる…。
    • 開発者もプロダクトマネージャーも、プロダクトが継続的に価値を届けるために働いてるんですもんね。
      • 継続的に がキモかも。

第2特集 OSの基本のキ 今さら聞けないファイルシステム＆ストレージ 見落としがちなデータ管理のしくみを学び直そう

第1章：ファイルシステム入門 ファイル管理の考え方の基本を総ざらい……青田 直大

  • ファイルシステム……N88 BASIC、MS-DOS、Windows、Windows2000〜XP、FreeBSD、Linux、MacOSと渡り歩いてきたので…いろいろつまづきましたw
  • inode…これもつまづきました…。ディスクがいっぱいになるより先にinodeが足りなくなったことがあったような。
  • マウント…MS-DOS/Windowsから来たから、最初マウントってわかんなかったですね…。
    • フロッピーはA、B、ハードディスクはC〜、外付けフロッピーはF…。

第2章：ファイルシステムのしくみ FAT32、ext4、OverlayFSの実装をひも解く……青田 直大

第3章：ストレージの基礎 ストレージの種類からKubernetesにおける利用まで……坂下 幸徳

  • 使ってないから、なんかフワッとしちゃっててピンと来ません…。
  • kubernetesを使うときに、もう一回読もう…。

特別企画 2038年問題を考える……上原 哲太郎、星名 藍乃介

  • 暗黙で32bit符号付き整数…。
  • 2038年…働いてそうですねぇ…。
  • まぁ、ウチはwebだし、ハードウェアとの連携もないので影響がなさそうです。
  • …と思ったら、MySQLのTIMESTAMP型だと？！
  • time_tをlongに代入…いやあ、やりますよね…。やったことがあるかもしんないw
    • ダウンキャストされるんで、厄介極まりませんね…。
  • MS開発者ドキュメントにダメな例……これはみんな見るし、厳しいです><
  • github.com
    • おお…ありがたや🙏
    • とりあえず、☆しました！

特別企画 ITエンジニアのためのメンタルヘルス相談室……長谷川（金） 千夏

  • www.kurusugawa.jp
    • AIの会社でしたよね…？
    • …と思ったら、会社で心理士面談の運用をしてて、そのお裾分けでしょうか…！ありがたや🙏
  • 心理的なことを訊くより、普段の生活の中の行動を訊くと答えてもらいやすい…。これは確かにそうですね。
    • 普段の1on1でも使える手段だって。たしかになぁ。
  • スモールステップで始めて、習慣化すると時間や頻度が増えやすい……これも確かに…。

特別企画 ITエンジニア必須の用語解説 200回記念 時代に取り残されないキャッチアップ術……杉山 貴章

  • 若い頃は…ここまで…できませんでした。
  • 今も変わらずで…。
  • 昔と違うのは、ここ数年Software Designを購読、全体をザッと読んで、そのとき思ったことをメモしておき、輪読会に参加。自分に興味がなかったことでも目に入るようになって、いい感じ…だと思っています。
  • 今の仕事をするのに、最先端の情報を集める必要はないので…幅広い情報を信頼度高く得るのには、雑誌が一番あってると思っています。
  • 世の中におもしろいもの多すぎません？

連載

ITエンジニア必須の最新用語解説 【200】Devin……杉山 貴章

  • Devinかあ。ちょっと気になっているんですよねぇ。
    • ラクだけど面倒なタスクをやってもらいたい…。
  • devin.ai

万能IT技術研究所 【39】「中原中也肖像」で機械学習顔分析や美顔処理——「在りし日」の詩人写真、バズり狙いで美化された説!?……平林 純

  • 美顔加工疑惑があったこと自体知らなかったです。よく知っていますねぇ…。
  • 最終的に印刷具合の違いっぽいとのことで、よかったです。
  • しかし…若いのになにげに洒落た格好をしてて…うらやましいですねw
    • 昔は今ほど写真が安くなかっただろうから、思いっきりおしゃれして撮ったんじゃないかしら。

FE/AP試験問題に挑戦 【10】プロジェクトマネジメント……石田 宏実

  • PMBOK懐かしい…。知識エリアとプロセス群の表がわかりやすいですね。
  • 問題
    • その1 … ア
    • その2 … イ
      • アルファベットが作業名なのでわかった感…。慌ててるとひっかかりそう💦

ドメイン解体新書 【19】ドメイン名の監視でサービスを守る……谷口 元紀

  • うち、監視できてないんですよね…。やらねば…。

ネコ、コード、ネコ 【2】セキュリティの話……植山 類

  • SourceForgeの「Download Now」広告…ありましたよね…。未だにそういう広告が野放しになってるし…。広告インフラ屋にはちゃんと審査をしていただきたい…。
  • スペクター👻

つまみぐい関数型プログラミング 【3】関数型プログラミングの便利な道具①：パターンマッチ……田尻 裕喜

  • デカルト、名言多いですね…。分割統治の他に「我思う、ゆえに我あり」も。
  • 副作用があるとせっかく分割した問題に影響…考えたことなかったけど、そりゃそうかあ。
  • 分割した問題を貼りり合わせる…？へええ…。
    • 言われてみれば、返り値が一種類の型になるし、貼り合わされたという解釈ができるのか…なるほど。
  • あ…型検査がガッチリすると、網羅性が検証できるようになって、パターンマッチでその他を入れなくてよくなったりする…？

プログラミング×AIの最前線 【5】サンフランシスコ〜シリコンバレー、AI企業訪問レポート……木下 雄一朗

  • オフィス訪問記…！
    • 思った以上におもしろい…！
  • Windsurfの買収の話は聞いた記憶があったけど…claudeが…みたいな話になってたのは知りませんでした。
  • 著者さんはcursor推し。
  • 最後につけてくれた街の様子は…なるほどそうなのか…という気持ちに…。

Ruby×静的型付け戦略 【4】プロジェクトへの型導入戦略……新谷 哲平、廣江 亮佑

  • タイミーのビジネスの話をサラッとでも知れてよかった…。
    • 雇用契約、労務、税金、給与の一時立て替え…スキマバイトを実現するためにクッションを設けてるのがよくわかりました。
  • 型チェックでやらなくていいテストが出てくる…。
    • たしかにありえない入力は型チェックで検知できますね。これはいいかも。
  • 機械でチェックできるところを機械に任せるために使ってる…なるほどです。
  • 既存プロジェクトと新規プロジェクト、両方の例があるのは…さすが。参考になります。
  • gem_rbs_collectionへのコントリビュート…ありがたい🙏
  • 実プロジェクトでの例、参考になります！
  • とりあえず、うちにも型チェックの足がかりだけでも入れよう…だとダメかもしれん。
    • 目的の定義からやるかあ。

実践LLMアプリケーション開発 【23】Supervisorパターン／Swarmパターンで始めるマルチエージェント……西見 公宏

  • Supervisorパターン
    • それぞれに明確なタスクを与えて、間違いにくくしている…？
      • LLMも自己評価が甘くなりやすいから…か。
    • 分業されていることで、デバッグや改修がやりやすいみたい。
  • Swarmパターン
    • 柔軟な対応が求められるときにはよさそうです。
      • その反面、デバッグはやりづらそうですね…。
    • ここではハンドオフして切り替えてますけど…協調して並列に作業して、合議制で結果を求めるようにしたら…エヴァンゲリオンのマギシステムですよねw

AWS活用ジャーニー 【34】AWS CloudTrail Lake……杉金 晋

  • CloudTrailがAWSの操作ログで…それを操作できるようにしているのが〜 Lakeっぽいんですね。
  • ログを扱うAWSのサービス
    • CloudTrail … AWS APIの操作記録
    • CloudWatch Logs … アプリログ、システムログの記録・検索、ストリーミング対応

はじめてのオフェンシブセキュリティ 【2】ペネトレーションテストに入門してみよう！……皆川 諒、監修：株式会社エヌ・エフ・ラボラトリーズ

  • Purple Flairは監修された会社さんの製品です。
  • 実際にnmap使ったりするのは…結構いいですね。
  • あとで時間があったらやってみます。

乱数のひみつ 【6】認証付き暗号を支える乱数……荒木 誠

  • 今日はむずかしかったです…。
  • ChaCha20
    • 加算、ビット回転、XORでCPUフレンドリーな演算でできているから早いのか…。
  • Poly1305、誤りの検知をする、チェックサムよりずっと難しいw

インターネットの姿をとらえる 【12】インターネットの障害――世界中で発生している数々の障害事例をひも解く……土屋 太二

  • テキサスってそんなに寒いの…？
  • 海底ケーブル……錨をしまいわすれてひっかけるやつ……。
  • いろんなパターンを読めてよかった…！

魅惑の自作シェルの世界 【33】関数の実装（前半）……上田 隆一

  • 関数の定義…！これがないとカスタマイズは捗らないですよね…！
  • 関数定義がコマンド扱い…なるほど、そのほうが作りやすそうではあります…。
  • 関数定義は…リダイレクトまで含まれるって…なんとトリッキーな……。
  • …毎回だけど、知らないことだらけです。

あなたのスキルは社会に役立つ～エンジニアだからできる社会貢献～ 【163】シビックテックが挑む参議院選挙～偽情報対策の最前線～……陣内 一樹

  • 偽情報…世の中がツラくなってきましたね…。
  • 以前IPA NEWSに偽情報の分類が載ってました。
  • 偽情報は発信する側が有利すぎるんですよね…。
    • 指摘して直してくれても、その情報は目につきにくいし…。
  • 偽情報対策、技術的にどうにかできる日がきますように🙏

その他

SD BOOK REVIEW

SD Staff Room

  • 「文系エンジニア」はコンピュータサイエンスの基礎をどうやって学んでいるのか…。確かにどうしてるんでしょう？…というか、文系に限らず、コンピュータサイエンスを大学などでやってない方はどうやって習得してるんでしょう…。
    • 自分はコンピュータサイエンスをやった側ですが…それだけじゃ全く身につかず、情報処理技術者試験を受けたり、自分のPCで遊んだり、大学寮の連中とLANで結んで遊んだり…まぁとにかく遊んで実感したんだと、今になって思います…。

プリンシプル オブ プログラミング 第3章のメモ(7)

プリンシプル オブ プログラミングの読書メモです。

第３章 思想 〜プログラミングのイデオロギー〜

3.55 UNIX哲学

  • UNIXを支え続けている哲学
  • UNIXの哲学は普遍である
  • UNIX哲学を利用する
  • サブセクションのままでした。詳細はこのあと…。
  • www.ohmsha.co.jp
    • 読んでなかったです><

3.56 UNIX哲学① 小は美なり

  • 小さいソフトウェアは美しい
  • 小さいソフトウェアは扱いやすい
    • プログラムが短ければ、理解が容易なのはさすがに自明か…。
      • ただ、読みやすさを犠牲にした「圧縮」はしないほうが、きっとよさそう。
    • 小さくする手段としては…
      • 責務を絞る
      • 現在いらないものは実装しない
  • 小さく作って小さく保つ
    • 使わなくなったものを消す
      • むずかしい…。
      • なかなか踏ん切れないけど、大丈夫、バージョン管理もしてるし、テストもあるじゃないか！…と自分に言ってます。
      • あと…消すのが面倒というのも大きいけども…どうしたら…。
  • その他
    • www.kodansha.co.jp
      • スモール イズ ビューティフル - Wikipedia
      • この本のタイトルから来ているそう。
      • ただUNIX自体はこの本以前からなので、設計思想自体はもともとあった感じですかねえ…。
      • この言葉が仏教徒のあり方から来ている…というのを見て、ちょっと親近感が！
    • Railsは大仰？
      • …そういうふうにいわれているような気もしますが…自分はあんま思ってなくて。
      • むしろ、「Webアプリケーションフレームワーク」として必須なものをちゃんと集めてある、という印象です。

3.57 UNIX哲学② 1つ1仕事

  • １つのソフトウェアは１つの仕事
    • Webアプリケーション、会社のサービスは…？となっても、これを意識してもいいと思っています。
    • 何を実現するものだっけ？というのはとても大事なことで…ここから外れたものは、あとからやっぱりイラネってなることが多い……と思ってます。
  • ソフトウェアがピュアになる
    • 複数のことをやっているときは…問題を完全に理解できてない
      • これは納得。名前付けに失敗してたりするのかも。
  • １つの仕事に集中
    • できあがったら手を入れないって意味じゃないと思ってます。
      • 目的に沿わないものを追加しない、というのをいつも気をつけているつもりです…。

3.58 UNIX哲学③ 即行プロトタイプ

  • できるだけ早くプロトタイプ着手
    • UNIX思想の最適化の原則の発展で言及されてましたね。
    • 一旦形を作ってみるというのは、結構効くのは経験してます。
      • ただの絵でも、動かないモックでも。
  • 試行錯誤なしでよいものは作れない
    • プロトタイプがあると見たり触ったりできるので、その作るものに対する解像度がググッと上がりますもん。
      • プロトタイプがなかったときは…しばしば出来上がったものを操作して、さらなる改修をさせられたり…仕様がひっくり返ったり…いろいろな目にあったことがありました。
  • プロトタイプで確度を高める
    • ウチだと、毎朝やってる共有会で前日に作ったものを見せたりしてるので、大怪我しないで済んでいる気がします。
      • こういうの作るよっていうプロトタイプ見せたりも。
        • 最近はGoogle Formとかも使ったり。
  • 第３のシステム
    • この言葉、知らなかったです…！
    • プロトタイプを使うと、たしかに早く到達しそうですねえ。

3.59 UNIX哲学④ 効率性より移植性

  • 効率性より移植性を優先
  • ソフトウェアの価値を持続
  • ハードウェアに依存しないコードを書く
    • ハードウェア…については今あんまり依存してないと思います。
    • 今どきの依存なら…クラウドベンダーですかね…。awsべったりです。
      • なるべく直接利用せず、一枚抽象化を挟んで使うようにしています。
        • awsのgemを直接利用しないとか…。

3.60 UNIX哲学⑤ データはテキスト

  • バイナリよりテキストファイル
  • テキストファイルは万能型
    • 「ポータブル」は、プログラム内に埋め込むことと比べてですよね…？
    • 「扱いやすい」はホントそう！
      • UNIXのあらゆるコマンドで処理できる…！
      • でも、「改ざんしやすい」ともいう。
        • 重要なものは暗号化とか適宜しよう…。
          • /etc/passwd か！
    • 例
      • UNIXの設定ファイル群
        • いくつかのものは実行前に書式チェックをできたりしますね。これがあれば、間違いやすいテキストも正しく運用しやすそうです。
      • 開発関連の設定ファイル
        • テキストだとリポジトリで管理したときに差分が見れていい！
        • VSCode…これは保存しないか。
        • git
        • 静的解析
      • IaC
      • 反例
      • Windows関連の設定…レジストリ
  • 標準規格のテキストファイル
    • 今ならYAMLやJSONもそうですかね。
      • そのままだと使いにくいけどjq、yqを経由で…。
    • 文字コードの話は？！と思った自分は古い時代の人かも。UTF-8が

3.61 UNIX哲学⑥ レバレッジ・ソフトウェア

  • ソフトウェアの梃子で力増幅
  • 少ない労力で巨大な成果を得る
    • 書かずに済ます→借りてきて組み合わせる→書く
    • 将来的になるべく同じ巨人の肩の上に乗り続けられるよう、寿命が長そうだったり、使うソフトウェアの方針とズレないように借りて組み上げるようにしてます…。
    • 例
      • シェルスクリプト
      • gem、npm、pip
      • github actions
      • サプライチェーン攻撃が気になってます><
        • dependabot alert以外に、別途osv-scannerを入れてもいいかもしれません。
        • あと、VSCode拡張を見直さなきゃ…！
      • いろいろ揃いすぎていて、「レバレッジの効きすぎる世界」かも。選ぶ力が要りそうです💦
  • 手作業を自動化する
    • これは自分の仕事の大部分ですねw
    • 既存のライブラリ、既存の小さい部品、なるべく少ないコードで作る、的な。
      • もちろん提起された問題が本当に問題なのかをもっとも最初に確かめますが…。

3.62 UNIX哲学⑦ シェルスクリプト活用

  • シェルスクリプトで接着する
  • 梃子の効果を増幅する
    • UNIXコマンドの多くは、後方互換性を大事にしているから、結構バージョンが違ってもなんとかなっちゃうことが多いですよね…！これが移植性か…！
  • グルー言語はシェルスクリプト
    • 基本的にshでできるような基本的な書き方でがんばりたいです…。
    • あと、なるべくインストールなしで済むようなものを中心に…。
    • CIのYAMLのrun: |…ってシェルスクリプトだ！
    • ほとんどのマシンにも入ってるなら、それはDSLと言っても？！
  • グルー言語

3.63 UNIX哲学⑧ 対話インターフェイス回避

  • 拘束的ユーザインターフェイスは避ける
  • ユーザもマシンもソフトウェアも束縛される
    • CIとかで慣れてるからか、基本的につけませんよねえ。
    • 束縛がいるかいらないかをよく考えるようにしてます…。
      • 技術的に足りてなくて、マニュアルの確認が必要なときだってありますもん。
    • 確認が必要なときには、notionやgithub issueなどにスクリプトの代わりに手順書を書きますね。表現力豊かですし。
  • コマンドインタプリタに制御を返す

3.64 UNIX哲学⑨ フィルタ化

  • ソフトウェアはフィルタとして設計
  • ソフトウェアは入出力である
    • これは…実感するまでに結構時間がかかったかも。
      • 昔Cで書いてたとき、引数に参照を入れて、関数内で書き換えてもらってたりしました。
        • C++以降はやらなくなったかも。
      • 副作用をなるべく避けるようになりもしましたね。
  • 標準入出力を使う
    • rake taskとかで意識してもいい…かも？あんまないかな？
  • UNIX哲学・小定理
    • 環境カスタマイズ
    • 軽薄短小カーネル
      • セキュリティ的にもいいですよね。基本はユーザランドで実行しましょう。
    • 小文字使用
      • これは…もしかしたら変わるかもしれませんね。
      • CLIで補完が効くようになってくると、プログラミングと同じように誤解の少ない名前になっていくかも。
    • 森林保護
      • これは…最近はディスプレイで読みますが…場合によっては紙がいいときもありますね。
      • なにかのチェックはメモを書き込める紙がいいです。
    • 沈黙は金
    • 並列思考
      • あんまり個人としては使わないですが…バックグラウンド実行が簡単にできますもんね。
    • 部品コラボレーション
    • 90%解
      • これはよく相談してます。
      • 超エッジケースまでいることって、そんなにないですもんね。
    • 劣るが優る
      • 「劣る」というか「最大公約数」…これは確かに納得ですね。
    • 階層思考
      • 人間、一度に認識できるのは10個くらいでしたっけ？
      • 階層にすれば、一度に見る数を抑えて認知負荷を下げられますもん。

情報セキュリティ対策自主研修 第32回 「「検証！スマートフォンのワンクリック請求」を観よう」を開催しました

academist-reading.connpass.com

情報セキュリティ対策自主研修 第32回 「検証！スマートフォンのワンクリック請求」を観ようを開催したので、簡単な感想を書きます。

題材

  • youtu.be

    • 先日、Wikipediaで犬のビーグルのページの外部リンクを辿ったら、フィッシングのページに行き当たりました。ワンクリックとはちょっと違ったんですが、対処法が結構似ているので、今回この動画をセレクトしました。

  • www.ipa.go.jp

    • こちらは…一応長期休暇前なので。

感想

運営としてのふりかえり

KPT方式で。

前回のTry

Keep

  • 時間が結構余ってしまったのですが、苦し紛れの話題から結構広がってくれたのでよかったです。

Problem

  • 今回の動画が短かった…。

Try

  • 興味ある話題を地道に訊き続けます…！

メモ

  • 終わったあとにやること
    • [ ] Google Meetのメッセージの保存
    • 謝辞と感想
      • [x] twitter
      • [x] facebook
      • [x] mastodon
      • [x] bluesky
      • [x] mixi2
      • [ ] connpassのイベントメッセージ
      • [x] ブログ
  • 次回準備
    • [ ] Canva ホワイトボード
    • [ ] connpassイベント
    • [ ] ネタぎめ
    • [ ] 告知
  • 直前
    • [ ] 告知
    • [ ] リマインドメール

「検証！スマートフォンのワンクリック請求」のメモ

「検証！スマートフォンのワンクリック請求」を観て、思ったことをメモします。

youtu.be

この動画を選んだ理由

  • 先日、wikipediaで犬の「ビーグル」のページの外部リンクがいくつかあったのですが、それが公開終了されており、ワンクリック請求のサイトにリダイレクトされました。
  • 日常的にこういうサイトにつながりやすくなっているので…実際にあったときの対処をおさらいできるよう、取り上げました。
  • 動画の作成時期は結構前ですが、内容的にはそんなに変わらないと思います。

メモ

体験

  • 「退会希望」「クーリングオフ」について書かれてて…普通の相手だったらアクセスする先なので、ホント慣れてないと引っかかってしまいそうです><

振り返り

  • 体験のところを見直しながら解説してくれますが、わかりやすいです。
  • いろいろ対策に失敗し個人情報が知られてしまった場合についても言及していて、「必要以上に恐れない」と言い切っているのがいいです。

その他

  • 役者さんの演技がじわじわくる。結構好きw
    • 対策について語るときの力強さが結構いい。

Wikipedia

  • 詐欺リンクの報告をしようと思ったら…めっちゃやりにくい…。
    • 問題を報告するページの「ここから下に、報告をお願いします」を編集して書くみたいですが…アカウントを作ってなど、結構たいへん…。
    • すみません、断念してしまいました><

最後に

IPAチャンネルの情報セキュリティ普及啓発映像コンテンツ、いくつか観てますが、結構よいのでおすすめです。

「プリンシプル オブ プログラミング」読書会 第18回を開催しました

academist-reading.connpass.com

「プリンシプル オブ プログラミング」読書会第18回を開催したので、簡単な感想を書きます。

感想

3.55 UNIX哲学

  • 全体の紹介だったので、何もナシで次にいっちゃいました。

3.56 UNIX哲学① 小は美なり

小は美なり

  • 小さくする手段として…
    • 単一責任原則
    • Interface分離原則
    • 関心の分離
    • YAGNI
    • etc...
  • 不要なコードを消すのって、力がいりますよね…？
  • 小さくなりすぎは美じゃないのでは…？
    • あとから思ったけど、適切なグルーピングが鍵になりそうです。

3.57 UNIX哲学② 1つ1仕事

１つ１仕事

  • 「小は美なり」とかなり重なってますよね…。
  • トランザクションのうまく区切られておらず、モジュール外のものを一緒に更新する必要があったりすると…ホワイトボードに描いてくれた図のようになって、ゾッとしますね><
  • 要件や制約を理解し、テスト駆動で考えれば避けられる…かも？

3.58 UNIX哲学③ 即行プロトタイプ

即行プロトタイプ

  • 「起点となるテーマ」から「上位の目的」を洗い出して…そこから代替手段を考えるという話が出て…これは納得ですね。
    • 自分も、仕事を頼まれたとき、上位の目的を探して、あらためて仕事のやり方を考え直しますもん。
  • 第3のシステムのサブセクション、読みづらいですね><

3.59 UNIX哲学④ 効率性より移植性

効率性より移植性

  • 本文にハードウェアが挙がっていたのでつい、ハードウェアのことばかり考えちゃいました…。
  • もうちょっと抽象的に捉えて、自分たちの文脈に合わせればよかったかも。

運営としてのふりかえり

Keep

  • 今回も録画しました。
  • Geminiの議事録も取りました。

Problem

  • とくにないかなぁ。

Try

  • 次も録画していいか訊いてみる！
  • 次次回のページをなるべく早く作る。

最後に

この先もやっていきますので、なるべくみなさんの経験や疑問を聴いて、参考にしていきたいと思います！

第70回Software Design (2025年7月号) 輪読&座談会 に参加してきました

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

softwaredesign.connpass.com

予習

第1特集 つまずきポイントの基礎固め Rustの4大機能をマスター

  • あまりガッツリRustを使っているひとが少なかったです。
  • そんな中、yanoさんが、小さいツールを作った際のパッケージサイズの話をシェアしてくれました。
    • 最初Goで書いたときにサイズが3MB
    • Rustに書き直してビルドしただけのサイズが6MB
    • 最適化オプションに気づいてをつけたら2MB
      • これ…自分だったら気が付かないかも。なんとなく頭の片隅に置いておきます。

第2章：分析用クエリの設計方法 可読性とメンテナンス性の高いクエリは適切な設計から生まれる！

  • meijiさんがSQLの講師？をやったときの話をしてくれました。
    • GROUP BYが結構鬼門…。WINDOW関数はもはや…。
      • 自分も過去に非開発者有志メンバーにやりましたが…全く同じ感想でした。

特別企画 祝 MySQL30周年＆ユーザ会25周年記念イベント

  • この輪読会の真骨頂、著者トークと昔話でした。
  • www.shoeisha.co.jp
    • もっと前の版でしたけど、自分もお世話になりました。

【新連載】ネコ、コード、ネコ 【1】ネコ用AIトイレ

  • この連載が企画された秘密がReader's Linkに…。
    • 最近減ってきた猫成分を補うため！
  • 以前から言われている、猫が表紙のときは売上がいい、という話も久しぶりに出ましたw

Ruby×静的型付け戦略 【3】型検査器を使ったプログラミング

  • 導入がよかったと思ったので、推してきました。
  • この連載をやっているうちに導入にこぎつけたいです…。

【最終回】実践データベースリファクタリング 【18】ライフサイクルの違う属性を持たせる

  • WebDB Pressから続いた連載で、だいぶ長かったですよね、と話題になってました。
    • （自分は第一回からの読者で、かなり楽しませていただきました。）

その他

  • プリンシプルオブプログラミング読書会があったので20時まででしたが、とてもあたたかく送り出していただきました🙏

最後に

今回も刺激的な会で、ひとりで読むよりずっと学びがありました。 また次回も行こうっと。

Software Design 2025/07 メモ

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

gihyo.jp

表紙

  • ダズル迷彩でおなじみのシマウマさんですね…！どうやってこの迷彩を獲得したのか、本当に不思議…。
    • 群れていると何がなんだかよくわからんですね。

第1特集 つまずきポイントの基礎固め Rustの4大機能をマスター

第1章：Rustの基本構文 必要事項を押さえて次のステップへ……青葉 憲紀、矢光 隆太郎、青柳 康平、福永 健悟、石原 喬平

  • 変数がイミュータブル…最初聞いたとき、え？ってなったけど、あらためて考えると、わざわざ同じのを使い回すときって…よくないときですよね><
  • 変数の再宣言のシャドーイング、ちょっと便利かも…。
  • Result型ってちょっとおもしろいですね…。
  • ドキュメント生成とテストフレームワークが言語に組み込まれてるって…なんかスゴイですね。
  • 組み込み以外のツールも結構あるようで、大変やりやすそうです…。

第2章：所有権と借用 基本的な考え方と問題の対処方法を押さえる……青葉 憲紀、矢光 隆太郎、青柳 康平、福永 健悟、石原 喬平

  • 所有権……。
  • let value2 = value1; で移動するのって大変じゃ…？って思ったけど、コピーのときはcloneすればいいじゃんって言われて、ちょっと納得。
    • おっと…型によって違うらしい…。
  • 初心者はまずクローンしちゃって…その後最適化すればいいっていうアプローチは、理にかなってそうです。
  • 参照/借用でうまくできそうですね…。
  • 読んでたら…結構なれるまでに時間がかかりそう…。

第3章：構造体 データの整理から高度な活用まで……青葉 憲紀、矢光 隆太郎、青柳 康平、福永 健悟、石原 喬平

  • クラスじゃなくて構造体でしたね。
  • メソッドも持てるし、機能としてはそろっていると思うので、そんなに違和感なく使えそうです。

第4章：Enumとパターンマッチング 異なる複数の型を持つことができる強力な機能……青葉 憲紀、矢光 隆太郎、青柳 康平、福永 健悟、石原 喬平

  • Enumはいいですね。間違いを検出してもらいたい！
  • もううちのRubyのバージョンならパターンマッチングを使えるので…慣れなければ…！

第5章：トレイトとジェネリクス 安全性を維持しつつ型に共通の振る舞いを定義する……青葉 憲紀、矢光 隆太郎、青柳 康平、福永 健悟、石原 喬平

  • …さすがについていけない…。

第2特集 データ分析のためのSQL講座 クエリの書き方、設計、データ加工処理

第1章：分析SQLの基本 開発と分析における違いを押さえよう……高橋 光

  • Window関数…あんまり分析の機会がないので…まだ身についてません><

第2章：分析用クエリの設計方法 可読性とメンテナンス性の高いクエリは適切な設計から生まれる！……假家 大輔、ゆずたそ

  • 設計手順……こんなやり方したことなかったです。なるほどφ(･･
  • 勘所、なるほどです…φ(･･

第3章：SQLによるデータの加工処理 分析用テーブルとデータ前処理のコツを押さえる……高橋 光

  • Garbage In, Garbage Out … そりゃそうだ…。
  • 会社で使っているQuickSightだと…
    • データセットがデータマート…って、構造化したあとのものが一番大きな粒度のデータだった…。
    • あんま加工ってしたことないな…って思ってたら、それが不要なものだったという…。なるほど。
    • S3とかにある生ログがデータレイク、それを加工してRedShiftにまとめるデータウェアハウス…あたりになるのかしら。
  • WITH句…思い出した、事前にいい形に整えた一時テーブルを作れるヤツだ！
    • 使ってた当時、PostgreSQLにしかなくて、ちょっと悔しい思いをしたヤツ…。
  • 欠損値の対応って…概ねいつもやってるやつでした。

特別企画 祝 MySQL30周年＆ユーザ会25周年記念イベント……tomo

  • おめでとうございます！
  • 最初に触ったMySQLのバージョン…3.23だった可能性は結構ある…。
    • Bugzillaを使おうとして触ったかな…。

短期連載

ローコード開発ツール「プリザンター」 【5】アプリの配布とシステムの移行……内田 太志

  • あ、配布できるのってちょっとおもしろいかも。JSON形式なのかあ。
  • インポート・エクスポートの手順って、最終回にふさわしいかも。
  • 機会があれば検討してみます…！

連載

ITエンジニア必須の最新用語解説 【199】Obsidian……杉山 貴章

  • obsidian.md
  • この記事きっかけで再び入れようか…という気持ちになったのに、また放置してます…。
  • Google NotebookLMと相性がよさそうなんですけどねぇ…。

万能IT技術研究所 【38】進め・止まれとBLEで指示をする、交通信号機の聲を聴く——道を渡り前へ歩む、未来の時刻表を手に入れる……平林 純

  • 幸い、そんなに信号で困っている生活を送ってないので…。（リモート勤務）
  • 信号機が情報を発信してるのかあ…。ちょっとおもしろいですね。

FE/AP試験問題に挑戦 【9】情報システム開発……石田 宏実

  • 設問1
    • a … プロダクトオーナー
    • b … イ
  • 設問2
    • ア、エ

ドメイン解体新書 【18】ドメイン移管完全ガイド……谷口 元紀

  • まだやったことないけど…またそのときに読み直してみます。

【新連載】ネコ、コード、ネコ 【1】ネコ用AIトイレ……植山 類

  • (ΦωΦ)
  • うわあ…猫用トイレ、スゴイものが出てるんですね…。

【新連載】はじめてのオフェンシブセキュリティ 【1】ようこそ、オフェンシブセキュリティの世界へ！……皆川 諒、監修：株式会社エヌ・エフ・ラボラトリーズ

  • オフェンシブセキュリティって、攻撃者の目線になって〜という意味だったんですね。知らなかったですφ(･･
  • 確かに「脅威」はマネジメントできませんね…。そしたら「脆弱性」と「資産」しかない…。
  • フレームワークベースで対処項目を出して、脅威ベースでトリアージ…なるほど、現実的かも。
  • 能動的サイバー防御との関連の説明はありがたいですね。
  • IPカメラ💦
  • shodan

Ruby×静的型付け戦略 【3】型検査器を使ったプログラミング……松本 宗太郎

  • 導入がめっちゃいいです！
    • 「正しく動くプログラム」の集合 > 「型検査で型エラーなし」の集合…これゆえに窮屈？
    • 実感は、型検査器を使いながらのほうが自由にできることがある…。
      • めっちゃ興味が湧いてきました。
  • 書き忘れを検知してくれるとなれば…たしかにいいかも。
  • Stringかnilを返すようなときに、nilの処理を忘れてるとエラーになってくれる…地味にいいですよね。
  • 次回は開発の現場から…！ちょっと楽しみ！

プログラミング×AIの最前線 【4】AIエンジニア「Devin」がもたらす開発の未来……木下 雄一朗

  • Devin…気になってはいました…。
  • devin.ai
  • コアプランなら…案外使えるかも？
    • 地道な作業が必要なものとか…やってもらいたいことも多そう。

【最終回】RAGアプリケーション評価・改善の極意 【7】RetrievalとGenerationの改善……佐藤 陽

  • Retrieval
    • ElasticSearchとかでも出てきている話ですね…。
    • Re-Rankは便利そう…いいですね。
    • あああ…！AIにクエリを書かせるのは試行錯誤がめっちゃ早そう……。
      • AIを効果的に使うのは、こういう試行錯誤のところというのは、めっちゃ納得できますね。
    • なに？AIによって仮回答を出して、それを検索クエリに使うだと…。ものによってはかなり効率的かも…。
  • Generation
    • 検索結果から回答と作ったときに、質問に対する回答として適しているか？という評価を入れてる…。なんかスゴイ…。
  • やろうとすると、時間とコストが…と書いてあったけど…これ、見積もりづらいですね><

【最終回】実践データベースリファクタリング 【18】ライフサイクルの違う属性を持たせる……曽根 壮大

  • これはやっちゃうなぁ…と思ったら、ちょっと違いました。JSONとかで複数管理はさすがにやったことなかったです。
  • カテゴリごとに…みたいなときには別テーブルがたしかによさそうです。
    • JSONで管理って…よく考えたら別テーブルで管理と同義ですもんね。

つまみぐい関数型プログラミング 【2】「式」と「不変性」の考え方……田尻 裕喜

  • そういえば「変数」？
  • ifとかswitchってCだと文だったんでした…。Rubyで式として使うのにそんなに苦労してなかったから…あんま考えてなかったです。

実践LLMアプリケーション開発 【22】LangGraph Functional APIのInterruptを使った領収書OCRエージェント……西見 公宏

  • 結構作り込まなくてもOCRやってくれるの、マヂスゴイですよね…。
  • これ、人間の確認アクションを入れることで、ホント、精度があがるし、めっちゃよさそう…。

AWS活用ジャーニー 【33】Amazon Data Lifecycle Manager……杉金 晋

  • なんかシブいの来た…！（よい！）
  • EBSの管理だったんですね…知らなかった…。
  • 今のポリシー、どうなってるんだろう？

乱数のひみつ 【5】乱数で暗号化するストリーム暗号……荒木 誠

  • たしかに処理が速そうだし、データサイズが決まってるなら、ストリームには最適なのかも。

インターネットの姿をとらえる 【11】インターネットの原理原則「インターネットルーティング」……土屋 太二

  • ピアリング・トランジットってなんだっけ？
  • 使用料、トラフィックを加味して経路を決めてる…個人だとルーティングテーブルを見るくらいまでだったので…なるほどでした。

魅惑の自作シェルの世界 【32】ダブルクォートによるクォート……上田 隆一

  • ダブルクオート…複雑ですもんね。
  • グロブやチルダは展開されないんですね…あんま考えて使ってませんでした…。なるほどφ(･･
  • チルダやグロブをダブルクオートで囲んでls
  • 注2…ややこしいですね><

あなたのスキルは社会に役立つ～エンジニアだからできる社会貢献～ 【162】AI実写風マンガで“多機能トイレ”を再現！〜オープンデータとLoRAを活かした制作裏話〜……小泉 勝志郎

  • スゴイ使い方ですね…。これはおもしろい…。

その他

SD BOOK REVIEW

  • gihyo.jp
    • QEMUで動かすみたい…。おもしろそう…。