ken1flanのブログ

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

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

「名簿を作るときに知ってほしい個人情報保護のチェックポイント」を観よう - 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 設計責任者を立てる

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

2024年05月

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

以前のまとめ

Special Thanks

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

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

academist-reading.connpass.com

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

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

感想・気づいたことなど

  • 心理的安全性

    • 「クソコード」「悪魔」こんなことを書いておきながら…!とツッコみたくなりましたが…。
    • それはそうと、これがないとそもそも開発が…ということなので、いつも気を配っている…つもりです。
    • Google re:Workを会社みんなで読みましたが、今も効果が続いていると思っています。
  • ボーイスカウトの規則

    - 「ちょっと良くする」が継続できそうで…今までもそういうつもりでしたが、これからもやっていきます…!

    ja.wikisource.org

  • 経験年数じゃなくて「向き合った年数」
    • いいこという人は年齢じゃないんだよなぁ…と思ってたら、いい言葉が出てきました。
    • 「向き合った」時間を自分もちゃんと重ねていきたいです。
  • 「俺のアンチパターン図鑑」を書きたくなりました。
    • 名前をつけて、そのスケッチまで書いたら、自分が書いたりレビューしたりしているコードに敏感になれそうだし。
  • RuboCop\(^o^)/
    • コーディング規約とそのチェックをだいたいやってくれるので、めちゃくちゃ助かっています。
    • github.com
  • メソッド名の長さで警告を出してもよさそう
    • 例外的な内容を付け加えたメソッド名とかはありそうですが…
    • 多くの場合は、他のクラスの責務の可能性がありそうですし…入れてみてもよさそうです。

運営としてのふりかえり

KPT方式で。

Keep

  • 自己紹介のときに「最近したこと」を入れたら、他の参加者も続いてくれてよかったです。
  • 人数が少なかったですが、よく喋った気がします!

Problem

  • 大きなチームでの開発経験のある方にも経験を聴きたかったです…。

Try

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

おわりに

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

参照

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

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

softwaredesign.connpass.com

  • SQLチューニング
    • いろいろと裏話がw
    • 特集最後で触れられていた記事が、幻の第4章だと聞いて、あとで読まなきゃってなってます。
    • データベースが激強な方がおられるとやっぱり面白いですね…。こういう方が常連なのでこの輪読会、かなりいいですよ!と勧めちゃいます。
  • DNSセキュリティ
    • 先月やった勉強会に触れてもらいました。
  • ハピネスチームビルディング
    • 参加者に発言しやすい環境をどうしてます?と訊いたら、みなさん結構苦労されてそうでした。
    • 話しにくいと感じている方は…
      • 「そんな当たり前のこと訊く?」と言われるのでは?というおそれが…。わかります。
      • 言ったら自分に仕事がきてしまう。
    • 自らが初歩的な質問を最初にしたりして、発言のレベル感を示すとか。
  • 「開発者体験」改善クエス
    • 生産性の可視化とかみなさんされてますか?
      • アジャイルでやっていれば多少は…見えるようにできているかも?
      • うちはそこまでできてないので…でもやりたい気持ち。

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

Software Design 2024/06 メモ

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

gihyo.jp

表紙

  • どなたさんでしょう、このかわいらしいねずみさんは…?

第1特集 SQLチューニングする前に知っておきたい 実行計画&インデックスのしくみ RDBMSの性能を引き出すための基礎 ......奥野 幹也

第1章:RDBMSSQLの基礎概念 リレーショナルモデル理論から理解するSQLの性質

  • 普段ほとんど触れる必要がないし、必要になったときは逼迫してるからて…
  • リレーショナルモデルにはNULLがない…?真偽値が3値になって大変なのに、どうして導入されたんでしょう…。
  • こういった読む機会がとても貴重です。

第2章:SQL実行のしくみと実行計画 効率的にクエリを実行できているか見極める

  • 実行計画のツリー型、結構よさそうですね。
  • なんとなく追っかけ方がわかった気がします…。
  • 困ったら読み直してみます。

第3章:インデックスの機能とアルゴリズム 検索処理を高速化させるしくみを理解する

  • マルチカラムインデックスの一方だけが含まれるときの挙動が書かれているのを初めて読みました。想像はしていた通りでホッとしました。
  • こちらも参考にさせていただきます!

第2特集 気になる機能は?性能は?[実証]Bun 次世代JavaScriptランタイムの実体に迫る

第1章:Bunの全体像をつかむ 誕生の背景、特徴、機能を押さえよう ......鈴木 正樹

  • ziglang.org
  • Bunって中華まんなのか…知りませんでした。
  • Nodeの問題点を解決している点ではDenoと同じだけど、Denoは互換性がないから…ということなんですね…。
  • 各種トランスパイラを内包しているみたいですが…プロジェクトのサイズ的にどうなんでしょう?大変じゃないのかな?
  • shellはおもろいw

第2章:Bunを使ってみよう 追加設定不要! 標準機能で始める快適開発 ......近藤 正裕

  • いろいろ内包してるので、メンテナンスが大変そう…とは思いましたが、使う側としてはラクでいいですよね。

第3章:BunとNode.jsの徹底比較 どちらがどれくらい速いのか、性能の違いを見よう ......鈴木 正樹

  • ja.wikipedia.org

  • !テストが速いだと?!
    • いいなぁ…。
  • Lambda関数をTypeScriptのままデプロイできるのはいいですね…。
    • あ…でも実行前にトランスパイルするから遅いのか…。

一般記事

[特別企画]DI―依存性の注入―はなぜやるの? 「コンポーネント間の結合度を下げる」とは ......成瀬 允宣

  • あんまり意識してませんでしたが…なにげに使ったりもしてますね…。
  • ただメリットをしっかりわかっていなかったので、これからはちゃんと使っていこうと思います…!
  • めちゃくちゃわかりやすかったので、困ったときにまた読み直そうと思います。

連載:Column

万能IT技術研究所【25】人類の歩みを眺めるために、過去の世界に行ってみる――昭和初期から最終氷期まで、時代の水辺にダイブする ......万能IT技術研究所

  • 過去の地形データじゃなくても、海水面を上下させるだけで過去の地形が想像できる……なるほど、確かに地形は変わりにくいですもんね。
  • おお…水面を下げると、擬似的に氷河期の地形が……面白い……。

ハピネスチームビルディング【27】会議で主体的に発言してもらえるようにする ......小島 優介

  • 発言したくない理由、めっちゃわかります……。
  • 問いかけちゃっても負担じゃないかなぁ…。勉強会でちょっとやってみてもいいかも…?
  • ポジティブフィードバックは自分もそう思ってるので、してる……つもりです。できてるといいなぁ…。
  • あとで感想を書いてね!は…仕事ならありかも。勉強会ではその場ですが、次回予告をしている間に書いてもらって、戻って見直す、みたいなことしてます。
  • とにかく、発言しやすいポイントをたくさん設けるようにしてはいますが……うまくいってるといいなぁ。

エンジニアのためのやる気UPエクササイズ【22】継続率と生産性を高めるエンジニア向けグループエクササイズ ......えくろプロテイン

  • グループエクササイズ…!
    • 運動に限らず、集団で集まるといろいろ長続きするのはなんとなく体験でわかります…!
  • フロント・リバース・サイドプランクとスクワット30回…たしかにバランスよさそう…。
  • 10分かからなそうなので、割とよさそう。やってみます!

あなたのスキルは社会に役立つ~エンジニアだからできる社会貢献~【150】能登半島地震におけるIT DARTの支援活動~IT技術者ができる災害支援~ .....大菊 健太

  • こういう活動もあるんですね。
  • たしかに専門家集団が現地とネットワークの両方を駆使してあたってくれるのは、とても助かりそうです。
  • こういう場で協力団体を紹介してくれるのもいいですね。
  • itdart.org

連載:Development

実践データベースリファクタリング【7】意図を忘れ去られたテーブル ......曽根 壮大

  • タイトルを見て、(´;ω;`)ウッ…となりました…。
  • 本来持っていない役割を担ってしまってるってことですか…。これ、やっちゃいますね…。
  • 消さなくても困らないし。いったんそのままに …やっちゃうなぁ…。
    • これ、万事でそうですよね…。
  • 名前を変えたりして、使われなくなったことを確認してからちゃんと消そう…として、忘れ去ってしまう…
  • いついつ以降は消消すぞというコメントを残すようにします…!

Google Cloud流クラウドネイティブなシステムデザインパターン【5】CI/CDシステム ......北野 敦資、監修:阿部 正平

  • クラウドベンダー謹製のだと、セキュアにできそうでいいかも…。
    • コンテナにしたら、そっちでビルドするようにしよう…。

あなたの知らないChromeの世界【5】Progressive Web Appのしくみ ......小河 亮

  • 段階的にWebアプリケーションからネイティブアプリケーションに近づける…この考え方は結構いいかも…。
  • Service Worker、ようやく何者かわかってきました…。
  • Project Fugu、扱いを間違えると猛毒の意だったとは…。たしかに危ういところを扱ってますもんね…。
  • ちょっとPWAが気になってきました…!

レガシーシステム攻略のプロセス【2】ZOZOTOWNリプレイスにおけるIaCやCI/CD関連の取り組み ......籏野 光輝、堀口 真

  • IaCは…すべての始まりですね…。うちはまだここがやっと…。
  • Canary Releaseは…Elastic Beanstalkもデフォルトでついてて、助かっています…!
    • ナシとかもう、考えられませんね…。
    • アクセス数とか考えたりしなくてもよいので、心理的負担がめっちゃ軽くなりました。
  • Progressive Delivery…これもElastic Beanstalkもデフォルトでついてて、助かっています…!
    • テストを定義しておけば、自動でロールバックしてくれるし、これも心理的負担がめっちゃ軽くなりました。
  • 普段使っているCI/CDの便利機能の名前を再確認できてよかったです。これでうちもこのあたりの置き換えをするときに、要件をまとめやすくなった気がします。

Databricksで勝つデータ活用【3】機械学習の実運用をサポートする機能 ......志賀 優毅

  • なにげにAI Playground、楽しそう。同じプロンプトを同時にいろいろなLLMに投げられるなんて。
  • うーん、時前でこういったことを構築し切るのはかなり大変そう…。
  • 機械学習の開発をするときには、従量課金だし、入れたほうがよさそうです。

ぼくらの「開発者体験」改善クエスト【6】アーキテクチャ特性からみるWeb開発基盤の改善 ......飯田 有佳子

  • アーキテクチャ特性…こういう先人の分類をサッと取り出せるようになるにはどうしたらいいんでしょう… 🤔
  • BFF…そういうのがあると統一しやすいんですね…。
    • うちがfrontendをがんばってないのでわからなかったのですが…frontendとbackendでフォーマットをお互いちゃんとするのは大事そうなので…気に留めておきます。
  • せっかくその環境にあったアーキテクチャを考えても…
    • 「やってみた」になっていたバッチシステムをついこの間、普通のActive Jobに移行しました。
      • 野心的だったと今でも思いますが…いかんせん、監視しづらいし、リリース作業がしづらくて…。
  • SLOを可視化できる、New Relicの柔軟なNRQL…。
    • うちは…数が少ないからですが、まだ狼少年なんですよね…。
  • 活動を共有すると助けてくれるひとが増える…これは今めちゃくちゃ実感してます。
  • 生産性を可視化するのにこういうのもあるんですね…。
  • 今回もよい記事でした 🙏

Cloudflare Workersへの招待【7】RustとCloudflare Workers ......井手 優太

  • Rustのin-source testing、知りませんでした…。
  • キャッシュを制御するVary、記憶しときます…。まだCloudflareで対応してないそうですが、そのうちに使うこともありそうですし。
  • Cloudflare Workersの記事のはずなのに、Rustええな!って思えた記事でした。

実践LLMアプリケーション開発【9】LangGraphで開発するリサーチエージェント ......西見 公宏

  • 自律的の情報収集・分析・レポート生成を行う、「リサーチエージェント」…なんかスゴイな…。
  • LLMアプリケーションは、LLMを使ってどんな風に調査とか調べ物をするのかという手順をプログラム化したものっぽく見えます。なるほど…。

AWS活用ジャーニー【21】Amazon CodeWhisperer ......杉金 晋

  • あるとは思っていましたが、github copilotを入れて満足しちゃって探してませんでした…。
  • コマンドラインの補完ができるのは結構いいかも…。
    • AWS CLIとか難しいですもんね…。
    • これのためだけにアカウントを作ってみるのもアリ…?
  • Amazon CodeGuruとかと組み合わせられるのは結構いいのかも…と思いました。
  • …ここまでいいなぁ!と思って読んできたのですが…Rubyがない!ダメだああああ💦
    • プロジェクトに入れるのは断念かなぁ…。
  • 輪読会で、AWSで知りたい機能あります?と訊かれても、いい提案が出てきませんでしたが…全容を知らないからですね…。
    • 今回も存在自体を知らないので、「知りたい!」と言えなかった感じですね…。

連載:OS/Network/Security

ドメイン解体新書【5】DNSへの攻撃とセキュリティ ......谷口 元紀

  • 前回はホント読んでるだけで縮こまるないようでしたが…今回は運営者向け…。
  • とはいえ、そこをやられたらかなりヤバいので…どういうものかをざっくりとでも知っておきたい気持ちです。
  • キャッシュポイズニング
    • 長期TTLのAレコードで…えええ💦
      • 防ぐ方法としても使ってますね…。
    • トランザクションID
      • xtech.nikkei.com
        • なるほど…本当に実装が古いための問題ですね…。
        • UDPだし、認証しないのかあ…。
        • DNSSECに期待…。
  • SSL/TLSの証明書をうまく使うのはありがたい…。
  • 自社のドメインを確保するときに業者を選定する条件に足してもよさそう…。

成功するPSIRTの極意【新連載】PSIRTってどんなもの?/PSIRTの始め方 ......杉浦 英史

  • セキュリティ専任の人数の出し方というのがあるんですね…。
  • 普通の会社はCSIRTだけでいいけど、SaaS的なWebサービスを提供しているなら、それ向けのPSIRTがほしい…ということかしら。
  • あっ…障害訓練をしていた記事が以前出てましたね……。
  • 常にしていることの中に「協力への感謝」と「未然に対処することの素晴らしさを知らしめる」があって、納得。大事ですね。
  • 全体を俯瞰するこの回は、保存版かも。

魅惑の自作シェルの世界【19】whileコマンドの実装 ......上田 隆一

  • 毎回ながら、bashの構文について勉強になっています…。
  • リファレンスとかで見る文法の書き方、構文解析のものっぽく見えますね…。
  • Ctrl+Cで止まらないとは…wこういうのが現れるから、手を動かすといいんですよね…と思いました。
    • 次回も楽しみですw

アラカルト

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

  • JSランタイムだけど、V8じゃなくて、MozillaSpiderMonkeyのフォーク…!
    • V8ばっかじゃ…と思ってたら、よかったです。
  • W3CのWinterCG仕様のサポート…安心感がありますね…。
  • 結構いいかも。

SD BOOK REVIEW

  • 生成AIの教科書
    • 推進計画やリスクについて書いてあるのはよさそう…!
  • エンジニアが最初に読むべきLinuxサーバの教科書
    • 500ページ…!多いのか少ないのか…。
    • ただ、知識を網羅的に扱ってくれているのはありがたそうです。
  • Azure OpenAI ServiceではじめるChatGPT/LLMシステム構築入門
    • LLMと検索の連携とか、アプリサポートとか…例が面白そうです。
  • Tailwind CSS実装入門
    • 気になってるんですよね…。使ってみたいと思いつつ、まだ触ってない…。
    • Twitter Bootstrapからの移住先、どうしようかなぁ…。

SD NEWS & PRODUCTS

  • U-22プログラミング・コンテスト
  • バグバウンティプラットフォーム…?!
  • Fastlyのボット管理ソリューション
    • パッチを当ててもらう…みたいなことが期待できないから、どうしたらいいもんかと思っていましたが…。
    • CDNは多様なサービスで使われているし、ボットを判断するネタを持っていそうですね。

次号のお知らせ

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

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

academist-reading.connpass.com

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

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

感想・気づいたことなど

  • Column クラスを分割すると読みにくくなる? がよかったです。
    • ファイルを分割した先が信用なければ…という話を読んで、いろいろなものを分割することを嫌う気持ちが理解できました…!
  • コードの健全性の可視化をしたくなりました。
    • 現職ではいろんなことを公開するようにしているせいか、とても話がスムーズです。
    • コードの健全性も公開することで、値の悪化が見えたり、それの改善をしたいときにすぐに納得してもらえたりしそうで…。
    • あと、少しずつ改善、みたいな機会を作りたいような気もしてきました。そしたらこの値の改善も見えるかも。
    • 可視化のツールは…ちゃんと運用するならCodeClimate Qualityを入れるのも悪くないですが…ちょっと高いんですよね…。

運営としてのふりかえり

KPT方式で。

Keep

  • 時間前に会場を開けておけました。
  • 「この勉強会の雰囲気がよいのでたまに寄らせてもらっています」と言ってもらえました…
    • やっていてよかった…。
    • 雰囲気は気をつけています。
      • 誰に対してもリスペクト、これをすべての基本にしているつもりです。
    • たまにこういった声を聞けるよう、これからもやっていこうと思います…!

Problem

  • 人数がちょっと少なめでした。
    • そのぶん、普段発言されない方が喋れたんで、それはそれでよかったです。

Try

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

おわりに

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

参照