ken1flanのブログ

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

Web Designinig 2023/12 メモ

book.mynavi.jp

  • Web+DB Pressが休刊になってしまったので、他の情報源を探していました。
  • Webデザインだと若干専門から外れる気もするのですが、周辺の情報を得るという意味では今の仕事の延長でもあるし…。
  • ちょうど見かけた号が苦手な法律の話だったので、手に取った次第です。

Introduction【AIと著作権のリアルな関係】

1章 核心

  • 著作権は人に与えられるので、AIには…
    • 実際作業をすると、プロンプトであれやこれや指示して試行錯誤するけれども…
  • そういえば、本などの編集者に著作権って認められていましたっけ?
    • チーム制作して、そのチームが後日解散したときってどうなるんでしょう…?
  • AI、学習させた人と使用してコンテンツを作る人が違うから、学習しただろと言われてもしてないと言い切れず、使っちゃうと避けきれず…今のところは難しいのか…。
  • コンテンツの説明で、アイデアの立ち位置がちょっとわかりました…!
  • あ…うーん…結局難しい><

2章 活用

  • Adobeは学習元が許可されているところがアドバンテージかあ…。
  • あくまでも、AI生成物をインスピレーションのもとに留めて、オリジナルを作るのも無難、みたい。なるほど。
  • …記録の習慣。これはプロならたしかに必要かも……。難癖をつけられたときに、どういう由来で…ときっちり答えられるようにしておく、と。
  • Photoshopに創作のログを改ざんできないように残せる機能が載ってる…?

特集:Webビジネスの【法律相談書】

  • 著作権フリー」の判断って難しいですよね…。一応商用利用とか見ますが…怖くて怖くて…。
  • 結構事例がよいかも…。
  • 法律リストもいい感じ。構造や概要が載ってました。

1章_クリエイティブに関わる【知的財産権の世界】

PART1 著作権の基本と知的財産権の骨格

著作権」とその財産権的側面
  • 譲渡できるものとできないものがあるのはなんとなく抑えてました…!
著作者人格権」と「著作隣接権
  • 著作隣接権に「レコード製作者」?レコードはCDとかもそうですよね?
商標や意匠は「先に登録したもの勝ち」
  • 著作権が早いもの勝ちじゃないのは、少し安心しました。
「パクり」問題を議論する上での注意点
  • 議論している場所の図がめちゃくちゃいい…。
  • たまにはてブで見かけますが、論争が噛み合ってないと思ったら、舞台が違うんですね。
  • トラブルになったときに、法律だけではなくて、感情まで考慮に入れていければいいなと思います。

PART2 具体例で学ぶ知的財産権と制作における注意点

「著作物」とは何か
  • 「思想または感情」、「創作性」、「表現」が揃っていること…φ(・
  • 例外の説明がわかりやすいかも。
1 コンテンツ制作
  • 「著作物」の定義が先にあったのでだいぶわかりやすかったです。
  • ラーメンブログの話は参考になりました。
    • ネタは同じなら、似ちゃいますよね…。
    • 法律的には問題なさそうですが、感情論的にはどうなんでしょう…?
2 撮影
  • 今まで写り込み、大変だったんですね…。改正されてよかったです。
  • 著作権的には意図してなんかしない限り大丈夫そうですが…肖像権やプライバシー権には注意したほうがよさそうです。
3 素材の利用
  • 自社用の素材でも、利用用途が決められている場合があるので、契約を見ておいたほうがいいのか…φ(・
  • フォントは気をつけてます…!
4 音声・動画配信
  • CDは…そうなりますよね。わかります…!
5 商品開発
  • 実物をイラスト化して使用…ダメだと思ってたんですが、グレーっぽいですね。いずれにしてもちゃんと話を通すのがよさそう。
  • 鬼滅の刃の着物の柄の話、著作権的には問題ないけど…。
    • 事実誤認させて売ろうというのはNGだそうですが、そもそもそれでいいと思う…。
自社の権利が脅かされたらどうすればいいですか?
  • 侵害された箇所をちゃんと説明できるようにしておくために、スクショは大事かも…。
  • 価格感も書いてあって、この記事ありがたいかも…。
  • 誹謗中傷の特定はだいぶやりやすくなったはずですが…それでもやっぱり大変ではありそう…。

2章_必須の知識をQ&Aで紹介! ジャンル別で押さえる【Webビジネスと法律 基礎知識】

個人情報保護法

  • そもそも3年ごとの見直し規定が…全然知りませんでした。
  • 個人情報は…個別の項目だけじゃなくて、組み合わせも。
    • これ、結構判断が難しいですよね…。
    • ちゃんとわかんないように!…と思って処置していますが…。
先生に聞くQ&A
  • これもいい感じ…。
  • 三者提供は…どう加工するか、よりも、提供先が持っている情報で個人を特定できるか否かかも?気をつけないと…。

特定商取引法

  • …売るときに騙そうとする行為が禁止されているみたいに見えます。
  • 最終確認画面で分量と価格が義務付け…知らなかったんですが、ちゃんとやってましたね…。
    • やー…こういうの、どうやって知ったらいいの…?
COLUMN 法律は難しいけれど…弁護士費用の捻出が難しい場合は?

特定電子メール法

  • メルマガやるなら、いいこと書いてあるかも…。
  • 同意にデフォルトチェックは…意思を示したのかという議論が、とか。

薬機法

  • 国に承認されていない効能・効果は謳えない…。
    • うまく効果が出てないのも多そうですが…。
    • 自分たちがやるときには気をつけねば…。
  • アフィリエイターかぁ…。

EC事業者にとっての法律の悩みと助け

  • あー…しょっちゅう法改正があるから、随時追従しようとすると大変かぁ…。
    • そういう意味でECプラットフォームに出して、ある程度任せてしまうというのもひとつの手なんですね…。
  • あ…なるほど、プラットフォームと出店者の力の不均衡を是正するのに「透明化法」というのがあるのか…。
    • ひどい噂も聞こえてきてたし…。

景品表示法

  • 不当表示…気をつけないとなぁ…。
  • 優良誤認、有利誤認…マーケティングに間違った力がかかると起きそう…。
    • うちは今のところ大丈夫そうだけど。
  • 「個人の感想です」…ダメですよねw そのほうがいいです。

ステマ規制

  • これ、難しいです…。
  • なにげに会社の情報を自分の個人アカウントでコメントつけて拡散したときって、どうなるんでしょう?

不正競争防止法

  • 有名企業のドメインに似せたヤツがダメなのは知りませんでした。

職業安定法

  • 職業安定法が出稿者にも及ぶのは知りませんでした…。多少は気をつけないとダメそうです。
  • 自社サイトは求人サイトとは違う、別のルールが適用されるようですが…書いてありません…!
    • とはいえ、誤認させるようなことを避けるようにするのが基本なんじゃないですかね…わからんですが…。

電気通信事業法

  • 外部送信規律…!
  • もう少し読みたいです…!

各種ポリシーや規約を適切に設置すべき理由

  • 外部に表明することで、結果、自身を守る盾🛡に…なるほどです。
  • 弁護士に頼む費用が…という方向けに、質問に答えるだけで規約ができるサービスを作ったって…?!

仕事で使える生成AI「Adobe Firefly」は権利問題とどう向き合っているのか

  • 著作権の問題がなさそうなところが一番いいですよね…。
  • 画像を広げてもらったりとか、普通にツールとしてよくできていそう…。
  • デザイナー以外でも、センスのいいひとは使えるかも…?

Point of View~制作会社の【社内業務と新しい法律】

フリーランス新法

  • 今年の秋から…?
  • 当たり前のことが並んでますね…。
  • 育児介護への配慮とか、ハラスメント対策、中途解除の事前予告が入っているのはいいですね…。
なぜ必要?[新法成立の背景を知る]公正な取引のために
  • …こういうのなかったんですね。よくぞ勝ち取ってくれました…。
  • 当たり前の対等の扱いがあるなら、働き方を選びやすくなりますね。
    • 副業もですね…。めちゃいい…!
  • www.freelance-jp.org
    • スポットワークは含まないんですね…。
      • これはこれで何か必要な気もしますが…何かあるんでしょうか…。

電子帳簿保存法

  • タイトルのQを「この記事のポイント」ですぐ拾ってて、読みやすいかも。
  • うち、ほとんど電子でやっているはず。
  • 真実性…ハッシュ値!みたいなことまでは求められないんですね…。

制作会社経営者のための法律相談ガイド

  • 弁護士もアウトリーチ活動…!たぶんこの本の記事もそういった活動のひとつなのかしら…。ありがたや🙏
  • 弁護士の強みはトラブルを知っていること …なるほど、これはたしかに…。
  • 結構いろんなところで相談会をやってるんですね。覚えておきます…φ(・

連載

Personalization X オムニチャネル

  • あ…なるほど…みんなすぐに情報を確認できるスマホを持った時代だから、チャネル別で考えることががあんまり意味をなさなくなってきてると…。
  • 顧客体験として考えていったほうがいい、というのはちょっと納得です。
    • 説明や追跡がしづらいけれども…わかる…。
  • うまいことやってるなーというところは、たしかにチャネル別っぽくないですね…。
    • オンライン・オフラインがミックスしているイメージ…。
  • 連続した体験の提供、時間の短縮、情報の付加、店舗での認知率の向上…複数のチャネルで接触することを前提にしてるから、表現?の幅を広げられるってことですかね…。
    • うまく使ってるところはたしかにこうだなぁ、と感じました。
  • ポイントの整理のシート、結構いいかも。

文章力を上げる鉄板ルール 生成AI時代に問われる文章技術、それは適切な「接続詞」の活用だ

  • 接続詞は分岐案内…たしかに。ちょっと覚えておきたい感じでした…!

どうする要件定義 技術要件への向き合い方

  • ひどい例だw でもありえそう……。
  • 技術用語は使わざるを得ないので、それの用途とかを説明しながらやる、みたいなことはよくやりますね…。
  • ただ、相手に聴いてもらえないといけないので…受諾とかだと……大変そう……。
  • 自分の場合は社内での開発だったから、ここまで大変にはならなかったですが…制作会社とクライアントだと、もっと大変でしょうね…。
  • 案件最初で、協力してよいものを作っていきましょう、的な合意をなんとか作れるといい感じなのでしょうか…。
  • この記事、おもしろいかも。
    • クライアントサイドと制作者サイドでそれぞれこの問題の解決策を模索してる!

ECサイト業界研究 ECと法律

  • うわあ…生々しい……。事件簿、いいかも…。

ど根性ディレクションコンプライアンスの重要性

  • 法令遵守はわかりますが……意識を高める、というだけだと難しそう……。
  • 法令遵守」とか「コンプライアンス」という言葉をことあるごとに出して、つい、数字に追われてしまうようなときでも、ちゃんと考慮する雰囲気を会社内に作っておこう、みたいな感じでもあるのかな…。

データのミカタ ステマに関する景品表示法改正は誰もが無縁ではない

  • なるほど、割と依頼してくるんですね……。
  • グラフを見てると、たしかに人ごとじゃない感じがスゴイですw

知的財産権にまつわるエトセトラ 法的な問題がないのに叩かれるコンテンツ

  • この号の特集にあった最初のほうの図のとおりかも。
  • 法律、契約、職業倫理、感情
    • どこで問題にしているかを意識したほうがちゃんと話せそう感。

コラム「Webと法律」

  • デザインデータ…うーん、なるほど…。
    • 事前にちゃんと話しておきましょう、というのが一番ですね。
  • GDPR……大事だとは思う……。
    • 罰金がすげーのは………ううむ………。

その他

  • 広告がきれいですね…。
  • 記事の前に目次に載っていない関連のコンテンツもある…?
  • この本、紙で読むようにデザインされてそう。
    • 電子だと、結構読みづらい…。

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

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

academist-reading.connpass.com

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

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

感想・気づいたことなど

  • 設計しないと…と何度も書かれてましたが…この章で初めて「変更容易性の工場のための」が省略されていたことが明かされて、自分はびっくりしてたんですが…本の最初のほうでガッツリ品質特性を書かれると、読み始めることが困難だったんじゃないかという意見が出て、これはなるほど、と思いました。
  • 「木こりのジレンマ」のたとえ、あんまりビシッとハマってない気がするんですが…。
    • チームメンバーに説明するときによく使ってますという方もいて、なるほど…と思いました。
      • 中で説明したいことについては、自分もよくわかるので、やっぱり自分も使いますかね…。
  • 技術的負債は、問題としても顕在化してないので、工数を確保しにくい…と切実な声が出ました。自分もめっちゃそう思ってます…。
    • この章の後半(次回予定の箇所)にめっちゃ期待してます!
      • (すでに読んだので、めっちゃやる気になってたりしますがw)
  • 今回読んだところ、全体的になにかの発表のときのスライドだったかな?という印象でした。
    • 本でよく読むと、説明の仕方や図がイマイチなところがあったりと…。
    • とはいえ、説明したいことはわかるので…よいのかな、と思いました。

運営としてのふりかえり

KPT方式で。

Keep

  • 時間前に会場を開けておけました。
  • 常連の方がきてくれました!
  • リピートしてもらえてます…!常連になってもらえるとうれしい…。
  • あんまり話すことにかな…と思ってたのですが、案外いろいろしゃべれて、盛り上がったと思います。
  • GWで、次回をいつにするのか迷っていたのを、最後に相談できてよかったです。

Problem

  • ちょっと時間をオーバーしてしまいました。
    • 5分程度だったので、まぁヨシとさせてください…。
    • またでした…。

Try

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

おわりに

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

参照

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

gihyo.jp

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

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

15 設計の意義と設計への向き合い方

15.1 本書はなんの設計について書いたものなのか

  • 設計とだけずっと書いてあったけど、その設計変更容易性の向上を目的としたものだったのか…。
    • 本のタイトルに入れてもらいたい気持ちもあります…。
    • はじめにを見直したけど、そこにも書いていなかったです。

15.2 設計しないと開発生産性が低下する

  • セクションタイトル、設計しないとだけだと足りない気持ち。本文のように変更容易性がほしいような…。

15.2.1 要因1:バグを埋め込みやすくなる

  • 漏れやすい、勘違いしやすい…わかります><

15.2.2 要因2:可読性が低下する

  • うーん…15.2.1と同じことをいっているような……?

15.2.3 木こりのジレンマ

  • これ、刃を研ぐ時間がどれくらいかによると思うんです…。
    • 研師に出して、1週間かかるとか言われたら、場合によっては待てないかもしれない…。
    • 自分で30分研ぐだけなら、やりそうだし…。
  • 木こり、そんなに急いで仕事をしているイメージがないし、自分の成果が収入に直結してるから、研ぐだろっていう違和感が…。
  • 木こりを雇っている
  • あんまこのたとえ、好きじゃないや…。

15.2.4 一生懸命仕事した感覚だけが残って生産性は悪いまま

  • 言いたいことはわかりますが………。

15.2.5 国家規模の経済損失

  • 1人1日3時間…!例えが極端過ぎません…?
    • 8時間労働のコードをどれくらい書いてるかって言ったら…6時間あったらいいほうでは…?
    • とすると、コードを書いている時間の半分以上持っていかれている……。
    • …でも、おそらく……技術的負債が蓄積しているときは、測れていないし、測れないと思います…。
    • …と書いてきて、ちょっと大げさだけど、最終的には案外あってるのかもなぁ…と思えてきました。
  • 複雑で混乱したロジックがあると、もっと混乱した…
    • わ、わかる (T_T)
  • 国家規模で集計すれば、国家規模の損失になるのは…

15.3 ソフトウェアとエンジニアの成長性

  • ソフトウェアの成長性
    • 生産性の言い換えな気もしますが、ちょっとワクワク感を感じるかも?

15.3.1 エンジニアにとっての資産とは何か

  • アレなコードをなんとか使うためにアレな工夫をしても…ということでしょうか。
    • わかる(T_T)

15.3.2 レガシーコードに人は引きずられやすい

  • 既存の動いているものがエライと思っていて、再検討なしにコピーしちゃうときありますもんね…。
  • ああ、たしかにレガシーコードと気づくのにはスキルが要りますね…。

15.3.3 レガシーコードは高品質設計を妨げる

  • レガシーコードは極めてアンバランスでトリッキー
    • これはたくさん向かい合ってきての実感でしょうか。
    • 自分も実感はありましたが、こんなにしっくりくる言葉に…!

15.3.4 レガシーコードは開発工数を減少させる

  • タイトルを見て、? ってなりました…。
    • 必要な作業量のことを工数だと思ってて、思ってたことと反対のタイトルでした。
  • レガシーコードのお守りのせいで、本来の開発に割ける時間が減っちゃうって意味でした。これはめっちゃわかります…!
    • これのせいで、スキルを伸ばせなくなる!というのも、まぁ、なるほど…。

15.4 課題を解決する

15.4.1 課題が見えないとそもそも設計する意識が生まれない

  • 「知覚できなければ」と言いたいのはわかりますが……ううむ……。

15.4.2 知覚容易な課題と知覚困難な課題がある

  • 技術的負債は見えないマイナスの価値…。
    • わかる…。どうやって説得したもんか、みたいな位置ですよね。

15.4.3 理想形を知ってはじめて課題を知覚できる

  • 突然の空手ですが…いいこと言ってますね!
    • 理想的な形をちゃんと描いてみるのは、やったほうがよさそうです。
  • クソリプかもですが…
    • 矢印の長さは揃えてほしいですね…。
      • 数学とか物理では長さが値の大きさを表してたりしますから…。
    • 相手を地面に対して平行に、自分より遠ざけようとしている前提をちゃんとしたほうが…。
      • 殴った威力だったら、接触面に垂直ならよさそうですし。
        • 空手の正拳突きは、押し返されないように足腰も使ってたりしてそうなので、結局まっすぐ打つのがいいと思ってますが、ここの図ほど簡単じゃないのではないのかなって思いました…。

15.4.4 変更容易性を比較できないジレンマ

  • せやな…。うまく表現するのが難しいですよね…。

15.5 コードの良し悪しを判断する指標

  • メソッド行数とかいろいろありそうですが…みんな、普段どんなものを指標にしているんでしょう…?
    • 静的解析ツールを入れていますが…可視化まではやってません。
    • 見てたら結構rubocopにありますね…。全体を対象にした警告数をメトリクスにしてもいいかも。
  • 整地部…!この活動いいですね…。

15.5.1 実行可能コードの行数

  • スコープごとに上限を設定するとたしかに良さそうです。
  • rubocopにありました!

Column クラスを分割すると読みにくくなる?

  • なるほど…分割した先が信頼できなければ、分割した先を気にしなくてはならず、それならファイルがまとまってたほうが読みやすいだろ?と…。
  • 適切に小さく、ちゃんとした名前で分割して、十分にテストしとけってことですね。そうすれば忘れちゃえるよ、と!

15.5.2 循環的複雑度

  • rubocopにありました!

15.5.3 凝集度

  • 度とはついていますが…
  • ABCでもいいかしら…。これならrubocopにあるし。

15.5.4 結合度

15.5.5 チャンク

  • rubocopのMetrics/MethidLength、Metrics/BlockLength、reekやflayの警告でも出るようです。
    • flayは知らなかった。コードの類似性を見てくれるんだって。めっちゃ、よさそう!

      github.com

15.6 コード分析をサポートする各種ツール

15.6.1 Code Climate Quality

- - 自分たちで揃えるより楽かなぁ、入れてみようかなぁ…。 - codeclimate.com

15.6.2 Visual Studio

  • Rubyで使えるのかなぁ…。だったら試してみたいところだけれども…。

15.6.3 Understand

  • 初めて聞きました。品質改善に集中的に取り組むときにだったら入れてもいいかも…。

Column シンタックスハイライトを品質可視化に利用する

  • なるほど…コードレビュー用にシンタックスハイライトの色合いを変えるとかしてみたい気持ちになりました。
    • 普段この色だとどうなんだろう…?

15.7 設計対象と費用対効果

15.7.1 パレートの法則(80:20の法則)

  • どうやってあぶり出し方たもんか……。
    • 変更が多いところを改善するとか、変更に合わせて少し改善を入れるとか、そういうことですかね…。

15.7.2 サービスの中心的領域、コアドメイン

  • 時間、有限ですしね。

15.7.3 重点設計対象の選定にはビジネス知識が必要

  • うーん、何をすればいいとか書いてあるわけではないんですね…。
  • 自分がやってるのは、運用してるひとにいろいろ訊いて、自分が詳しくなることとか、かなあ…。
    • ドメインエキスパートがいないことが多かったので…。

15.8 時間を操る超能力者になろう

  • おもしろい言い方…!
    • 操るための工数は…コードのメトリクスの悪化とかよく言われている値からの乖離とかから説明して得る感じですかねえ…。
    • 操るぞ!という気概を持って、事に取り組むのはいいことな気がしてきました!

情報セキュリティ対策自主研修 第17回 「3つのかばん -新入社員が知るべき情報漏えいの脅威-を観よう」を開催しました

academist-reading.connpass.com

情報セキュリティ対策自主研修 第17回 「3つのかばん -新入社員が知るべき情報漏えいの脅威-を観ようを開催したので、簡単な感想を書きます。

題材

感想

  • 自己紹介で、みんなの新人研修の話がよかったです。
  • いろいろとドラマ内で出てきたものに対して、参加者それぞれの工夫を披露してもらえたので、だいぶ参考になりました。
  • ドラマ自体は…「笑ゥせぇるすまん」っぽいって話題に出て、なるほどでしたw
    • こんなに工数をかけて研修してくれたら身になりそう…。

運営としてのふりかえり

KPT方式で。

前回のTry

  • 次回のネタを決めます…!
    • 決められていませんでした。うーん、どうしよう?

Keep

  • ひさしぶりに社外の方が来てくれました…!うれしい!
  • いろいろと感想や体験、工夫していることがが出てたすかりました…!
  • ちゃんと予習した…!
  • 研修をやっていて、なんとなく社内で情報セキュリティが意識されている状態が保たれているように感じます。

Problem

  • 動画の途中の話し合いからの復帰のタイミングが難しい…。
    • 再開してからメッセージが投稿されたりしました…。すみません :pray:
  • 「華麗なる情報セキュリティ対策」を映していてちょっと恥ずかしくなってしまいました…。
  • 次回何をやるか、まだ未定…。
    • 電気通信法の話がどっかにあったらやりたいのですが…。

Try

  • 次回のネタを決めます…!

おわりに

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

メモ

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

3つのかばん -新入社員が知るべき情報漏えいの脅威-を観た

3つのかばん -新入社員が知るべき情報漏えいの脅威-を観て、ざっと気になったり思ったことをメモしています。

メモ

顧客情報

  • 配属初日に関係者を名乗るメールを開いて感染とか、エグすぎる…。こういうときって別のことで頭がいっぱいだから、簡単に引っかかってしまいそう…。
  • 事故った気持ちになってるときにUSBや書類の話を出されたので、思わず深くうなずいてしまいました…。

業務上知り得た情報

  • やった記憶がなかったのに…あれぇ?!
  • 次のカバンあけたくないよなー、わかるw

営業秘密

  • 営業秘密の話だと、「島耕作」が…。
    • 昭和過ぎてアレなところも多いけども…ハニーポットとかも使いこなしてて…まぁ、昔から変わりませんよね…。
      • ソーシャルハック!情報セキュリティ!と思って、また読んでみますw

資料の紹介

  • IPAの「対策のしおり」は…全く知りませんでした…。

感想

  • 「自分がその立場だったら…」と思って疑似体験をしたつもりで観ると、結構キました…。
  • こんなふうに情報セキュリティの研修ができたらスゴイだろうなぁ…。
  • 知らなかった資料があるのに気づけてよかったです。

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

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

academist-reading.connpass.com

理由は…

  • 本業で不具合対応があり、忙しかったこと
  • 参加者が自分と社内の一人だけだったこと(connpassではいませんでした。)

参加登録者がいなかったのはこんなふうなことだったのでしょうか…?

  • 年度末で忙しかった?
  • 14章後半は題材がIDEの話で、みんな興味なかった?

次回は4/22で、15章を半分やろうと思っています。(5月もGWでやりにくいなぁ…)

おまけ

読書会を始める前に、少しだけ同僚とIDEの話をしていました。 彼はRubyMineを使ってるそうで、この章をきっかけにリファクタリングの機能を見たら、かなり充実していることに驚いていました。 動かして見せてもらいましたが…かなりよさそうでした…。メソッド名や変数名の変更が気軽にできそうになるのは本当によさそうです。うらやましい…。

pleiades.io

2024年03月

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

以前のまとめ

Special Thanks