ken1flanのブログ

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

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

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

academist-reading.connpass.com

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

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

感想・気づいたことなど

  • 影響力を持つレベルの人数 10.9%
    • 10人以下なら1人なわけですが…一人はフォロワーがほしい気持ち…。
    • それ以上なら、経験的にあってそうに感じました。
    • …いやあ、一人はフォロワーがほしい!心細い!
  • 17.1のおすすめ図書群、よかったです。
    • 次に読みたいものが結構ありますね…。
    • もっと人数がいたら、読んだ人のおすすめの弁が聴けたのに…残念でした…。

運営としてのふりかえり

KPT方式で。

Keep

  • 既読、未読、おすすめ…などのスタンプは悪くなかったのでは…?
    • 参加者がもうひとりだけだったので…わかりませんが…。
    • また使ってみます。
  • 前回たどり着けなかった残りにちょっと救われました。
    • やっぱ、自分の書いたもの以外がほしい…!

Problem

  • もう少し早く資料を仕上げたい…。
    • …が、がんばりすぎだから仕方ない、こんなもんかも。
  • 社内のひとだけで、ちょっと寂しかったです。
    • それはそれで、中のひとなりのしゃべり方があるので、悪くはなかったかも。
    • 他の人の本の感想を聴きたかったなぁ…。

Try

  • 引き続きがんばります…!

おわりに

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

参照

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

gihyo.jp

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

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

17 設計技術の理解の深め方

17.1 さらにステップアップするための設計技術初紹介

  • 「橋渡し」というか、読んだけどうーむ?となったひとにもう一度渡ってもらうための本という印象を受けました。
    • あれこれ議論するのにとてもよかったと思っています。

17.1.1 現場で役立つシステム設計の原則~変更を楽で安全にするオブジェクト指向の実践技法

  • gihyo.jp
  • 未読です。
  • 著者の増田亨さんはSoftware Designの特集で何度かお見かけしましたが、解説の切り口がよくてわかりやすかったと思いますので、いいかもしれません。

17.1.2 リーダブルコード ─より良いコードを書くためのシンプルで実践的なテクニック

  • www.oreilly.co.jp
  • 読みました!
  • チームで開発を続けていくためには読みやすいは必須だと思います。

17.1.3 リファクタリング 既存のコードを安全に改善する(第2版)

  • www.ohmsha.co.jp
  • 未読です。
  • 不吉な臭いとその改善方法…この本と同じ構造なんですかね。
  • Rubyエディションもよかったと思うのですが…途中になっちゃてますね><

17.1.4 Clean Code アジャイルソフトウェア達人の技

17.1.5 レガシーコード改善ガイド

  • www.shoeisha.co.jp
  • 未読です。
  • テストのないコードへの立ち向かい方が書いてあるようで、結構おもしろそうですよね…。

17.1.6 レガシーソフトウェア改善ガイド

  • www.shoeisha.co.jp
  • 未読です。
  • コードそのものではなくて、その周辺環境の改善ガイドのようです。
  • 現場の反発などが書いてあるんですね…。結構おもしろいかもです。

17.1.7 レガシーコードからの脱却 ─ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

  • www.oreilly.co.jp
  • 読んで、おもしろかったのは覚えていますが…。
  • 開発の仕方を全体的に書いてあるような…また読んでもよさそうです。

17.1.8 エンジニアリング組織論への招待~不確実性に向き合う思考と組織のリファクタリング

  • gihyo.jp
  • 未読です。
  • システム開発の生産性向上を阻む、組織的な課題について切り込んだ
    • ちょっとおもしろそう…。
    • うちの会社がもっと大きくなったときに効いてきそうな内容に感じます…。

17.1.9 プリンシプル オブ プログラミング 3年目までに身につけたい一生役立つ101の原理原則

  • www.shuwasystem.co.jp
  • 未読です。
  • ソフトウェア設計の原理原則指針のカタログのようです。
  • 覗いてみたくなりました。

17.1.10 Clean Architecture 達人に学ぶソフトウェアの構造と設計

  • store.kadokawa.co.jp
  • 未読です。
  • あの有名な玉ねぎっぽい絵の本のようです。
  • うーん、読まねば…!

17.1.11 エリック・エヴァンスのドメイン駆動設計

  • www.shoeisha.co.jp
  • 未読です。
  • これだけ長い間取り上げられているのだから、良い本であるのは間違いなさそうなので…。
  • とはいえ、ひとりで読むのが難しそう…なら、読書会でゆっくり読むのもアリ?

17.1.12 セキュア・バイ・デザイン 安全なソフトウェア設計

  • book.mynavi.jp
  • 未読です。
  • セキュリティは身近で気になる話題なので、ちょっといいかもしれません。
  • ひとつひとつのクラスが仕様通りに動くように、というアプローチも結構おもしろいかも。

17.1.13 ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本

17.1.14 ドメイン駆動設計 モデリング/実装ガイド

  • booth.pm
  • 未読です。
  • まさかBoothとは…!
  • このあとのサンプルコード〜が続編だそうで…読むならセットかも。

17.1.15 ドメイン駆動設計 サンプルコード&FAQ

17.1.16 テスト駆動開発

  • www.ohmsha.co.jp
  • 未読です。
  • TDD自体をまだうまく使いこなせないんですよね…というのはありますが、興味はあります。
  • 読みたい…。

Column バグ退治RPG『バグハンター2 REBOOT』

  • www.freem.ne.jp
  • 未プレイ
  • なるほど、アンチパターン名と対策の組み合わせを覚えるのにはよさそうです。
  • ちょっと絵は好みじゃなかったんですが、ちょっとやってみてもよさそうな気がしてきました。

17.2 設計スキルを高める学び方

17.2.1 学習のための指針

  • 手を動かすとか説明するとか…アウトプットすると身につくのは実感しています…。こうしてメモを書いているのも、時間がないなりに少しでもアプトプットしようという試みだったりします。
  • 設計効果が…感覚的にキレイになったとか、テストが書きやすかったとか、なんかしらあるようにしています。

17.2.2 悪魔の構造を見破る練習

  • プロダクションコードを見るのは…やってみたいと思います。

17.2.3 リファクタリングで大幅スキルアップ

  • 簡単なところからちょっとずつ改善、を繰り返すのも良さそう。
    • 次のクオーターにそういうのを入れたい…?

Column C#と長き旅、そして設計への道

  • regionディレクティブ…確かにヤバそう><

  • 便利機能も気をつけて使います…。

17.2.4 動くコードを書いたら、設計し直してからコミット

  • 動くコードを書いたら、テストを書きながら、コードを整理しなおしています。
    • なるべく早いうちに動かして、勘違いがないかとかいろいろ確認して…
    • そのあとにテストコードを描きながら、構造的におかしいところを直してます。
    • …だいたいテストを書きたくないところが複雑でおかしいことが多いです><

17.2.5 設計技術書でさらなる高みを目指そう

  • …この章を読んじゃったら、次回の読書会のテーマが「リファクタリング」になっちゃうじゃん…。
  • どうしよう🤔

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

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

  • 第2特集 CTF
    • M1 Macでパッと動かなくて、yamlを書き換えたそうです。
      • MySQL5.7のプラットフォームをx86したら動いたのだそう。
  • Github Actions
    • キャッシュを使って、10分かかっていたものを1分にして、気持ちよかったのだそう…!スゴイ!
      • うちももう少し高速化できるはず…。がんばろ!
    • 技術書典などのための執筆環境で、GithubへプッシュしたときにPDFを出力するようなActionを書いてるのだそうで、よさそうです。
      • Re:VIEWを使ってるとのこと。
  • ハピネスチームビルディング モチベーション3.0
    • この輪読会、休刊までは…!とおっしゃってたので、しばらく安心して遊びにこれそうでよかったです。
    • チームのモチベーションでみなさん苦労してそうです…。
  • やる気UPエクササイズ
    • そろそろなのでがんばりますw
  • 開発者体験改善クエス
    • みなさん、あまりオンコールをされてない方が多いみたい。自分もしてませんですし…。
  • データベースリファクタリング
    • SQLiteにもWITH RECURSIVEが入っているんだそうです。
    • MySQLなどでは最大実行時間をセーフティネットにしてもよさそう。
    • クエリに必ずLIMIT 200つけたり。フルテーブルスキャンを避けるために、workbenchは勝手につけてるんだそうです。なるほど。
  • ドメイン解体新書 DNSとプライバシー

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

Software Design 2024/07 メモ

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

gihyo.jp

表紙

  • 鮮やかなオレンジと白のハチワレ?顔も愛嬌があっていいですねえ。

第1特集 実運用でどう使う? GitHub Actions実践講座 CI/CDの理想を実現するために

第1章:GitHub Actionsの基本 技術用語と定義ファイルの書き方 ......佐藤 礼於

  • 公開リポジトリでの利用が無料なのはとても助かってます🙏
  • 結構適当にやっていたので、用語の説明は助かります…。

第2章:CI/CD実現ハンズオン 静的解析からコンテナレジストリへのプッシュまで ......高見 諒

  • まだウチではDockerを入れてないので、マージをトリガーにしてイメージのビルドとかコンテナレジストリへの登録とかまでは…。やりたい…!
    • そのときになったらまた読み返します…!

第3章:実運用で求められる機能 ワークフローの制御、高速化、セキュリティなど ......加瀬 健太、谷 昌典

  • コンテキスト、こんなにあるんですね…。(ちゃんと調べてませんでした💦)
  • 次のステップへの成果物の受け渡し…。
  • ジョブが失敗しても必ず実行するステップが作れるんですね…知らなかった💦
  • そういえば、失敗したテストケースだけの再実行をしても、カバレッジの集計がうまくいかないんですよね…。どうしたものか…。
  • ブランチプロテクションやシークレットの話も書いてある!助かります!

第4章:大規模開発におけるGitHub Actionsの課題と解決策 便利機能の使いどころ・注意点 ......三村 遼

  • 大規模に限らず、使う機能が紹介されてて助かります🙏
  • matrix strategyは…gemの開発には必須ですよね…。

第5章:大規模開発におけるワークフロー設計 保守性や運用面の要件に応えるためのテクニック ......平木場 風太

  • Custom actions、気になります…。Reusable workflowもありそう。
  • ちょっとした命名規則で、名前の混乱を避けられるのは、いいですね。
  • CircleCIを使っている自分に、神のような投稿が…!

第2特集 キュリティの強化・改善に役立つ 脆弱性診断入門 脆弱性の発見手法と対策アプローチを身につけよう

第1章:昨今のセキュリティ事情と対策の基礎知識 リスクと向き合い、必要な対策を理解する ......松本 隆則

第2章:脆弱性診断に必要な知識とスキル 脅威に備えて対抗する力を磨く ......松本 隆則

  • 自社でやると…ホワイトボックス診断までできてよさそうだけど、スゴイ工数がかかりそうです。
  • どこかプロにお願いすると…お金はかかるけど、工数はだいぶ減りそうです。
    • 前職で頼んでレポートが上がってきましたが…さすがプロっていう感じでした…。
    • 今思うと、外部から「ありますよ」と言われると、圧がありますね。工数を確保しやすいかも。
  • 日常的にやるなら、やっぱりツールですかね…。
    • portswigger.net
    • www.zaproxy.org
    • 設定を動く環境をCIで準備できたら、チューニングを本業の方にお願い…みたいなことができたらありがたいんですが…どうだろう🤔
  • オンライン学習を使って、設定方法等々になれるのは結構いいかも。いい時代になりました。

第3章:Webサイトの脆弱性を突く攻撃の具体例 被害を防ぐための根本原因を突き止めて対策する ......水野 沙理衣

  • 新しい手法!みたいなものはなく、昔からあるものをちゃんとやっていこう、という感じでした。
  • booth.pm
    • これ、更新したくなりました。

第4章:CTFに挑戦 脆弱性の探し方と対策を実戦形式で理解しよう ......養田 篤也

  • パズルですね…。いくつかできる手立てを組み合わせて旗を取りに行く感じが。
  • 1サイトに対してやるとペイしなそうですが、いくつもやるなら、案外大変ではないのかも。
    • 秘伝のスクリプトをちょっとずつ設定を変えて…ゲーム感覚でやってるんだろうな…というのが垣間見られますね…。
    • 今日日はこのスクリプトも売ってたりするのかなぁ…。マヂかよ…。
  • 自前エスケープは…考慮漏れがスゴイからやらないのが吉ですね…。
  • ……参考になりました🙏

連載:Column

万能IT技術研究所【26】赤外から紫外線まで!スマホで写す「見えない世界」――画像位置合わせ技術で分光画像の歪みを補正 ......万能IT技術研究所

  • 赤外線フィルタ…そうやっていわれればできるのかも…。ちょっと欲しくなりましたw
  • そういえば、桜の花も、可視光以外でなんか輝いてるんでしたっけ…?
  • そのうちにスマホのカメラが赤外線紫外線あたりの写るレンズがついて、5つになったりしてw

ハピネスチームビルディング【28】モチベーション3.0を刺激するプラクティスを考えよう ......小島 優介

  • モチベーション3.0はめざすところ…。
  • 試行錯誤を繰り返すって、かなり難しいと思いますが…がんばりたいところ…。
    • めーっちゃ考えてからやってるより、早く結果がわかっていいのはわかってるんですが、時間がー!
  • モチベーション3.0の要素…めっちゃ実感してます。
  • チームのプラクティスに取り入れる……やってみたい……。
    • そもそも…チームメンバーがほしい!!

エンジニアのためのやる気UPエクササイズ【23】30歳超えのエンジニアが筋トレをすべき理由 ......えくろプロテイン

  • 60歳を超えると筋肉量の減少速度が加速……。
    • 家族を見てると、実感しますね…。
  • 食事を使って筋合成強化…!ちょっと覚えておきます…。

あなたのスキルは社会に役立つ~エンジニアだからできる社会貢献~【151】テクノロジーの力でともに生きる社会へ ......小泉 勝志郎

  • バーチャル空間はたしかに障がい者でも参加しやすい場なのかも…。これはよいですね…!

連載:Development

レガシーシステム攻略のプロセス【3】API Gatewayとサービスメッシュによるリクエスト制御 ......富永 良子、吉江 守弘、亀井 宏幸

  • ストラングラーフィグパターン…って大げさに聞こえちゃうけど、段階的に置き換えるって言ってるだけなので、みんなよく使っていそうな感じ。
  • ファサードも使い慣れない言葉だけど「正面からみた外観」だそうで…いい名前かも。
  • API Gatewayを自作するって……経験豊富な方が設計するなら、アリですよね。
    • 逆はあとでツライことに……よくあります……。
    • しかし、全アクセスが集中するだろうに、パフォーマンス・拡張性その他諸々ちゃんとしてそうでスゴイ…。
  • 今はIstioなんですね。
  • ストラングラーフィグパターンを実装するために、ファサードパターンを採用した…。
    • 覚えちゃうと、たしかにスッキリした書き方で、伝わることも多そうです。
    • …いずれにしてもスゴイ…。
    • techblog.zozo.com
  • いずれにしてもスゴかった…。

Databricksで勝つデータ活用【4】DatabricksとLLM ......阿部 直矢

  • RAGがLLMに外部情報を組み合わせて回答制度を向上させる技術のことだとわかりました。
    • 言葉は覚えきれないけれども……普段自分が検索をしながら考え事をしている作業、そのものっぽいですね。
    • www.nri.com
  • インフラ部分のコードがないところが、Databricksの強み、かあ。
  • RAG、実践LLMのほうでも出てきましたね!

あなたの知らないChromeの世界【6】ChromeのセキュリティとSpectre ......小河 亮

  • セキュリティの境界をページ単位としちゃうと、リンクで移動するWebでは難しいですよね…。
  • オリジンは同じホスト、同じポート。
  • HTTPヘッダに許可する他のオリジンを書く…と。
  • サイトというもう少しゆるい境界でプロセスを分割…なるほど…!
  • spectre…スペクターって読むんですね…。しかし、これはキツイ…。
  • あいかわらずこの話、興味深い…。

Google Cloud流クラウドネイティブなシステムデザインパターン【最終回】セキュアなシステム ......北野 敦資、監修:阿部 正平

  • ゼロトラスト…!
  • へええ…Endpoint Verification、スクリーンロックやストレージ暗号化の有無の情報も持っていくんですね。
    • (よいと思います!)
    • たしかに接続用のソフトを介せば、接続元のPCの情報を検査することができますね。
  • よさげ!ちょっと覚えておきます。

ぼくらの「開発者体験」改善クエスト【7】プロダクト開発エンジニア全員で取り組むオブザーバビリティ ......安藤 裕紀

  • www.oreilly.co.jp
  • みんなで取り組んでいるって…強いですねえ…。
  • 全員プロダクト開発エンジニア…!いいですね、こういうつもりで働いてるつもりですが、チーム全体となると、ひと工夫いりそうです。
  • 全員オンコール…!こりゃすごい…。
  • アプリとかのエラーも計測してるんですかね…。結構高そう…。現状だと見る余裕がないし、ちょっと真似はできないけれど…うらやましい!
  • 推進担当は…やっぱりいるといいですよね。きっちり使い倒したいですし。
  • どうやってNewRelicの資金を出したのかと思ったら…AWSのコストダウン……憧れる……。
    • 自分も新しいものを導入するときに、めっちゃ考えます……。

実践データベースリファクタリング【8】実行計画 ......曽根 壮大

  • 本番に調査用クエリを…!!!
    • 会社のフェーズ的には…まぁ、よくある話ですね><
    • 見るところでやって、すぐ止められるようにする、くらいがいいのかも…。
    • お金と人がいたら、分析用の別のデータベースがほしいです。
  • MySQLでもWITH RECURSIVEが使えるんですね…知りませんでした。
  • こういうチューニング、しくじる前には…やりませんよね…?
  • 今回もよくある場面でした…!

Cloudflare Workersへの招待【8】Service bindingsで複数Workerを連携してみよう ......福岡 秀一郎

  • 外部から秘匿するようなWorker、DBの位置を考慮した位置でWorkerを起動…
  • これ、便利すぎますね…。
  • 使い始めたらロックインされちゃって、ほかへ移れなそう。
    • 競合ってあるんでしょうか?
  • 非同期で呼び出すだけ…!RPC、便利ですね…。
  • アプリケーションの作り方が根底から変わりそうな雰囲気です。

実践LLMアプリケーション開発【10】LangGraphで開発するCorrective Retrieval Augmented Generation ......西見 公宏

  • RAG、Databricksのほうでも出てきましたね!
  • 前回もそうでしたが、「評価器」が興味深いですよね…。CRAG、よさそう…。

AWS活用ジャーニー【22】Amazon API Gateway ......杉金 晋

  • 他の記事で出てきたものに対して、AWS版を紹介してくれるの、いろいろ捗って助かるかも…。
  • 他のタイプのものも並べてくれるのは助かります…!
  • エッジ最適化、リージョン、プライベート…エンドポイントのタイプも結構選べてよさそうです。
  • バックエンドも結構選べますね…。
    • 開発期間中用にモックが選べるのも気が利いてるかも…。
  • ステージが作れるのもいいですね…。
  • 認可も…。なんでもありますね…。
  • 最後のベストプラクティスがいい感じです。

連載:OS/Network/Security

ドメイン解体新書【6】DNSとプライバシー ......谷口 元紀

  • ですよね…。
  • 電気通信事業法、出た。これのおかげで、事業者は黙っててくれるんですね…。
  • 最後のまとめの図がめっちゃわかりやすい…。

成功するPSIRTの極意【2】PSIRTの日々の業務 ~ログ解析/脆弱性診断について~ ......松本 太一、越智 郁

  • 業務をざっくり分けたOKR、ask、インシデント対応、ログ・アラート解析、脆弱性診断という分類がわかりやすいです。
  • 脆弱性診断の実施タイミングがなかなか参考になります…。
    • リリースを止めてやるのがセオリーだけど、それでは回らないので…といった、業務を止めずにでもなるべくしっかりやりたい、という工夫が読んで感じられました。

魅惑の自作シェルの世界【20】SIGINTをスレッドで受けてwhileコマンドを止める ......上田 隆一

  • 止まらない理由は、自プロセスがSIGINTに対応していなかったからなんですね…。
    • 止めるとsleepが止まって、また続いちゃうみたいな。なるほど…。

アラカルト

ITエンジニア必須の最新用語解説【187】Oracle Database 23ai ......杉山 貴章

  • AIが統合???
  • AIの学習用のベクトルに変換して格納、検索…スゴイ…。
    • ベクトルへの変換って、LLMによらないんでしょうか?(わからん)
  • 自然言語で問い合わせ…これはおもしろそうだけど、どれくらいまでできるんでしょうか…?

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

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

SD BOOK REVIEW

SD NEWS & PRODUCTS

  • Canva
    • GoogleのJamboardがサービス終了になっちゃうので代わりを探してたときに見つけました。
    • せっかくだし、使ってみようかなぁ…。
  • HDDの出張破壊…!
    • その場で、というのはまぁ、持ち帰ったものが転売されたなんていうニュースがいっぱい出てましたからね…。
  • 今回、結構量が多かったかも?おもしろかったです!

次号のお知らせ

Software Design Plus

定期購読のご案内

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

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

academist-reading.connpass.com

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

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

感想・気づいたことなど

  • まさにチームにプルリクエスト/レビューを導入しようとされているか検討中の方がいらっしゃいました。
    • 経験談をいくつかしましたが、自身が思うメリット・デメリットを再確認できてよかったです。
  • レビュー、しっかりしようとしすぎて遅くなったりしているので、少し肩の力を抜こうと思いました。
  • Google re:Work勧めちゃった。
  • いっぱいしゃべってしまいましたが…しゃべりすぎじゃなかったかしら…😓

運営としてのふりかえり

KPT方式で。

Keep

  • 自己紹介のときに「最近したこと」を入れたら、他の参加者も続いてくれてよかったです。
  • 初めての参加者が来てくれました!
    • しかもいっぱいしゃべってくれました!

Problem

  • 大きなチームでの開発経験のある方にも経験を聴きたかったです…。
  • しゃべりすぎていないかな…ちょっと心配です💦
  • 予定の半分くらいで時間が終わってしまいました。

Try

  • 引き続きがんばります…!

おわりに

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

参照

「名簿を作るときに知ってほしい個人情報保護のチェックポイント」を観よう の予習

「名簿を作るときに知ってほしい個人情報保護のチェックポイント」を観よう - connpassの予習です。

academist-reading.connpass.com

名簿を作るときに知ってほしい個人情報保護のチェックポイント(マンション管理組合・PTA・自治会編)

www.gov-online.go.jp

メモ - 個人情報とは? - 特定の個人を識別できる情報のことですが…どんなものがありそうですか? - マンションの管理組合の理事長を例に - 気軽になっちゃったって… - PTAやら自治会、同窓会! - 他にどんなものがありそう? - チェックポイント - 利用目的を特定する - 新規入居者に名簿に書いてもらうときに、ちゃんと目的をいったり、書いてもらう紙にも書いておくのはいいですね。 - 訊かれる側も、安心するし…。 - 利用目的を明示する - …なるほど。 - 集めた個人情報の管理を徹底する - パソコンにウィルス対策ソフト、ファイルにパスワード…他にはなにかありそうですか? - 第三者に個人情報を提供する場合は本人の同意を得る - 近所の商店街組合から…みたいな例で他に思いつくものがあれば…! - 付き合いのある団体からのお願い……これ、引き受けちゃいそうですね…。

資料に貼り付けるもの

質問形式の付箋

  • 名簿を作るグループってどんなものがありそう?
  • それぞれのグループの利用目的は?
  • どういうときに第三者提供を求められそうですか?
  • 適切に管理されなかったときのリスクは?
  • グループメンバーのプライバシー意識

チェックポイント

  • 個人情報を集めるときは利用目的をあらかじめ特定する
  • 利用目的は個人情報を記入してもらう用紙や規則などに記載し本人に明示する
  • 集めた個人情報の管理を徹底する
  • 三者に個人情報を提供する場合はあらかじめ本人の同意を得る

これだけは知ってほしい個人情報保護10のチェックポイント(中小企業編)

www.gov-online.go.jp

メモ - 利用目的を決める - フォームで図示って結構わかりやすいですね。 - こんなに具体的に決めてあるのはスゴイかも…。目的がシンプルだからかな? - 不適正な利用…ってどんなですかね…? - 利用目的を本人に通知または公表する - フォームのデザインのときに入っているか、あまり見てませんでした。気にするようにします。 - 取り扱いのルールや責任者を決める - これ、うちほど小さいと…全員? - 従業員の教育を行う - 裏側に見えた資料…。 - data.e-gov.go.jp - data.e-gov.go.jp - data.e-gov.go.jp - 社内教育を行え、はわかるのですが、どんなふうにしたものかしら…。 - 「読んどけ!」じゃないし…。 - 委託する場合 - 適切な管理を求める…委託されたら、逆に求められるんですよね。 - 個人情報の交換 - 「できない」じゃなくて、「〜すればできる」という言い方がいいですね…。

資料に貼り付けるもの

質問形式の付箋

  • 利用目的の具体的な事例は?
  • 従業員教育をどうやってやるのがよさそう?
  • セキュリティ対策しています?
  • 委託先に個人情報を共有したときにどうやって管理していますか?
  • 提供・受領時の記録をどうやって保存していますか?

チェックポイント

  • 利用目的を決める
  • 利用目的を本人に通知または公表する
  • 取り扱いのルールや責任者を決める
  • 従業員の教育を行う
  • 物理的な安全措置を行う
  • パソコン等にセキュリティ対策を施す
  • 事業者に取り扱いを委託する際は、適切な管理を求める
  • 個人情報を提供する場合は、本人の同意を得る
  • 提供したり提供を受けたりしたときは、年月日等を記録し保存する
  • 本人からの開示や訂正、利用停止等の申出には、速やかに応じる

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

gihyo.jp

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

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

16 設計を妨げる開発プロセスとの戦い

  • コードそのものじゃなくて、コードを作る環境に問題があるだろうと…。わかる…。

16.1 コミュニケーション

16.1.1 コミュニケーションが希薄だと設計品質に問題が生じる

  • せやな…。

16.1.2 コンウェイの法則

  • コンウェイ作戦で失敗してるケースを実際に見たということでしょうか…。だとしたら結構ツライですね…。

16.1.3 心理的安全性

16.2 設計

16.2.1 「早く終わらせたい」心理が品質低下の罠

  • とにかく早く書ける……それはそれで大きな価値ですが…。
    • 前職でも現職でもそういうコードを引き受けることに…。結構たいへんですよね💦

16.2.2 粗悪なコードはきれいなコードを書くより常に遅い

  • アプリケーションが小さくて、仕様が単純、テスト環境を作るのに慣れてない…みたいなことが重なったときはそれにあたらないので、常にはダウトかと…。
  • だいたいなら真だと思いますw

16.2.3 クラス設計と実装のフィードバックサイクルを回す

  • うーん…サボってますね…。改修時にちゃんと組み込むようにしてみます。

16.2.4 厳密に設計しすぎず、サイクルを回し続けるのがコツ

  • 運用し続けること自体が一番大事、というのは自分も賛成です🙋‍♂

16.2.5 「パフォーマンスが落ちるからクラスを追加しない」は正しい?

  • 大規模テキストファイルを処理するようなところではあるかもしれませんが…全部じゃないと思います…。
  • どう分割したらいいかわからないだけ、なのかも。

16.2.6 設計ルールを多数決で決めるとコード品質は最低になる

  • そうなの?そんなもんなの?
    • あんまり大きなチームじゃないことが多かったので、そんなことになったことがなく…。

16.2.7 設計ルールづくりのポイント

  • あー…確かにルールを自分たちで作るとひどくなりそうです。
  • すでにある静的解析のルールを読み合わせる、くらいが今は適当かも?

16.3 実装

16.3.1 割れ窓理論ボーイスカウトの規則

  • あー…よくないのに限ってコピーされたりするんですよね…。
  • ボーイスカウトの規則 、これいいですよね。明記しておきます…。

16.3.2 既存コードを信用せず、冷静に正体を見破る

  • 「これが先輩のお手本」…やめてくれ!
    • でも、これに気がついたの、そこそこに経験を積んでからだったと思います。
  • 知覚できるようになるのが大事なので、アンチパターンを書いてみるのもおもしろいかも。

16.3.3 コーディング規約を利用しよう

16.3.4 命名規則

  • キャメルケースだ、スネークケースだ、そういうのは大丈夫ですが…クラスやメソッドの名前の付け方とかに指針を出したほうがいいかもしれない気持ちです…。やらねば…。

16.4 レビュー

16.4.1 コードレビューをしくみ化しよう

  • セルフアプルーブ、できるようにしてほしい…。
    • 常勤が自分だけなので…明確に「セルフだけどレビューした」印がほしい…。
    • これがないせいで、アプルーブなしをマージ禁止にできないです><
  • プルリクのテンプレート、入れてもいいかも。
    • ひとことプルリクで、あれこれ訊かされるのがツライ><

16.4.2 コードを設計視点でレビューしよう

  • テストや静的解析をCIに組み込めたおかげで、欠陥の有無やコーディングスタイルについて気にしなくてもよくなったのがめちゃくちゃ大きいです…!

16.4.3 敬意と礼儀

  • (クソコードとか悪魔とか書いてあって、どうなの?感はありますが…)
  • 敬意と礼儀は大事にしたいと思っています。
    • ダメなところがあったら言ってほしい…。
    • ちゃんと理由書けてるかなぁ……がんばってるつもりだけどなぁ…。
      • あと、こっちは理由を書いてがんばって説明したことに対して、どういう思いでそうしたのか、なるほどと思ったのか…返信はほしい……。
        • コードを書いている人に比べれば、レビュワーは向き合っている時間が短いはずなので…。
  • 気をつけていることが全部書いてある…!
    • レビュー以外でも言えることだけど、守れているひと少ない気がする…。

16.4.4 定期的に改善タスクを棚卸しすること

  • コードの健全性を測るのに、fixmeの数を入れてもいいかも。

16.5 チームの設計力を高める

  • このやりとり…ありますね><

16.5.1 影響力を持つレベルにまで仲間を集める

  • 10.9%…少ない?と一瞬思いましたが、案外あっていそう。小さいチームなら一人仲間がいるだけで、状況が動きますもんね。

16.5.2 基本はスモールステップ

  • わかる…。(だから読書会してる。)
  • つい、「自分の知っていることは相手も知っていて当然!」みたいな気持ちになりがちで…。
  • 新しいひとが入ったときにどうしたもんか、的な。

16.5.3 実感が大事、手を動かしてみよう

  • プロダクションコードに適用してみる…は確かにそうかも。
    • 対象箇所を探すのが大変そうではありますが…。
    • やってみたい。

16.5.4 フォローアップ勉強会を開いてみよう

  • なるほど…。
  • このフォローアップ勉強会、どれくらいの頻度でできるかな…。

16.5.5 勉強会のバッドノウハウ

  • 設計手法の紹介だけだと、ほえ〜で終わっちゃうのは…わかります。
  • 時間があるなら、取り上げた話題のリファクタリングするの、よさそうですよね。
  • 成果物を否定されたら良い気分はしない
    • わかる…。気をつけています。
    • しかし…この章の前までクソコードとか悪魔とか言ってたのに…と若干思いました。

16.5.6 リーダーやマネージャーに設計と費用対効果の話をする

  • マネージャーと意思疎通が大事…はわかります。
    • 聴いてくれるひとだとやりやすいんですが…実世界はどうなんですかね…?
    • 自分は…比較的小さいところなのでそこまで困ったことはないけれど…。
    • 前職のリーダーはうまく説明していたと思います。
      • そして、なぜやりたいのかはっきりしないような企画も来ないようにもしてました。

16.5.7 設計責任者を立てる

  • 形から入るのはいいかも。
  • しかし、この予算はどこから…?