almost weekly useful materials - 11/23 -

[GENZITSU]

Gradioを使った機械学習モデルのデモンストレーションをAWS App Runnerでサービスする

Gradioを用いて作成してデモwebアプリをAWS Copilot CLIを用いることでDockerfileひとつでAWS App Runnerにデプロイする方法の紹介

コメント

とても簡単そうなので、どこかで使いたい

出典

• Gradioを使った機械学習モデルのデモンストレーションをAWS App Runnerでサービスする

[GENZITSU]

時系列データの汎用的な表現学習の研究動向

時系列データに対するTransformerの適用方法および、事故教師あり学習の研究動向について語れている記事

時系列へのトランスフォーマーの適用

ナイーブなTransformerだと時系列の長さの2乘に比例して計算量が増加するので、ボトルネックとなっているAttentionの効率化が研究されている。

Informer: Beyond Efficient Transformer for Long Sequence Time-Series Forecasting (@AAAI2021)という手法では重要なトークンはごく一部しかないという仮定の元、一部のトークンのみを選抜してAttentionの計算をするという方法をとっている

一方でPyraformer: Low-Complexity Pyramidal Attention for Long-Range Time Series Modeling and Forecasting (@ICLR2022)は元の特徴量を時間方向で段階的に要約し田植えで、Self Attentionを行うことで、効率的な長期依存性の表現を可能にしている。

時系列データの表現学習

Self-Supervised Contrastive Pre-Training For Time Series via Time-Frequency Consistency @NeurIPS2022では時間に関するデータ拡張とフーリエ変換などの周波数変換を加え、時間、周波数それぞれにおいて、Contrastive Learningを行う。加えて、時間に関する特徴と周波数に関する特徴を同じ空間にマッピングされるようにすることで、汎用的な特徴量の獲得を目指している。

注目すべき点はドメインAで事前学習したモデルをドメインBでファインチューニングした際に良い性能を出している点である。

コメント

時系列データに対する表現学習手法奥が深そうだ

出典

• 時系列データの汎用的な表現学習の研究動向
• Informer: Beyond Efficient Transformer for Long Sequence Time-Series Forecasting (@AAAI2021)
• Pyraformer: Low-Complexity Pyramidal Attention for Long-Range Time Series Modeling and Forecasting (@ICLR2022)
• Self-Supervised Contrastive Pre-Training For Time Series via Time-Frequency Consistency @NeurIPS2022

[GENZITSU]

Layer Normalizationを理解する

TransformerやBERTなどの系列モデルでなぜBatch Normalizationではなく Layer Normalizationを用いることが多いかを解説している記事。

Batch Normalizationの短所

• バッチサイズが小さい時に不安定
• サンプルごとにテキスト長が異なる場合の統計量の扱いが難しい

Layer Normalization

これらを解決しようとしたのがLayer Normalization

こいつはミニバッチごとの各レイヤーの統計量を求めるのではなく1サンプルごとの各レイヤーの統計量を求めるもの

比較結果 (論文より)

Batch Normalizationを用いることでLSTMの収束も早くなっているが、Layer Normalizationによってさらに早くなっていることが確認できる。

コメント

改めて勉強になった

出典

• Layer Normalizationを理解する
• Layer Normalization (論文)

[GENZITSU]

だれかの進捗をうまく把握できないときのフレーズ集

リスクや不確実性を低減させるための進捗把握方法が紹介されている。

進捗を確認する目的

・リスクを軽減する ・不確実性を減らす ・意思決定を支援する ・信頼を確立する ・情報を伝達する by Mike Cohn『アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～』、p29

効果的な確認方法

次にやることは何ですか？／このあとは何をしますか？

またこの質問をキッカケに「そういえば〜の設計が難しそう」「〜について他チームに連絡する必要があるけどどうする？」など、目の前の課題が明確になることもよくあります。 一方で返答に詰まってしまう場合は、タスクが停滞していて進捗は出ていなかった可能性もあります。周りが積極的にサポートするべき場面だと感じます。

大変だったことはありますか？

相手の回答があれば「今後もときおり発生するものか」や「プロジェクト全体のリスクになりうるか」などを考えられる 具体的なタスクを取り出して「〜の実装は大変でしたか？」などのように聞いても良さそうです。

〜時点でどんな状態を目指しますか？

しかし「やることをやった」からと言って「進捗が出た」とは限りません。進捗とは変化であり、行動の集積ではないからです。 もし「〜という状態だ」と返答があれば、あとはその状態に到達できる可能性を上げるための工夫やリスク・不確実性についても意識を統一できるでしょう。

意外と認識が異なっているのが完了条件です。完了した結果どうなるかを深堀りしてみたり、具体的な成果物を定義してみたり、お互いのイメージが一致することが確認ところまで話してみると効果的です。

〜に伝えておかないといけないことはありますか？

この質問は「とくにないです」率が高いので、頻繁に利用するものではありません（ルーティンで質問すると無回答がルーティンになる）。ですが上手く利用できれば、チーム間のトラブルを解消できることが多くあります。

そんなときに「〜チームに連絡すべきことはありますか？」「〜さんに言っておいたほうがいいことはありますか？」などのネタ振りを適当なタイミングでしてみると、たとえば開発周辺の話や仕様・スコープの変更に関係する話など、質問者が気付いてなかったタスクや課題が出てくることがあります。

どうでもいいけど話しておきたいことはありますか？

それは理由があって「どうでもいい」という前提を設けることで、話し合いのテーマからズレてもよいこと、および発言者が責任を持たなくてもよいことを明らかに示せるからです。 「どうでもいい」話題が実はかなり重要である

個人的には「どうでもいい」情報というのは「その人がコントロールできない課題」が多い気がします

コメント

1 on 1とかで使っていけそうな質問集。 自分が進捗を確認される際も意識しておきたい。

出典

だれかの進捗をうまく把握できないときのフレーズ集

[GENZITSU]

State of AI Report 2022

AI系スタートアップに集中的に投資を行っているVCによる2022年のAI業界のトレンドをまとめた100p超のスライド

研究 / 産業 / 政治 / 安全性 の4軸に加えて、2023年の予想も綴られている。

印象的なスライドのみ抜粋

研究

AIの生化学への応用がトレンドになっている。

Attentionの効率化は探索されているものの、実用には至っていない

モデルの大きさよりもデータの大きさが性能を支配しつつある

大規模モデルはモデルサイズに関する臨界点が存在する

モデルの訓練に必要な計算量は指数関数的に増加している

大規模言語モデルがロボティクス業界に大きな影響を与えている

AI創薬は一歩間違えると、生体兵器開発に転じうる

研究界隈での中国勢が躍進している

中国語論文を含めると、さらにわかりやすい

産業

NVIDIAのチップがめちゃくちゃ使われている

どの企業がA100をたくさん持っているかのグラフ (Meta凄すぎる)

DeepMindやOpenAI, Google Brainなどのビッグテックの卒業生がスタートアップ起業する流れが

AIコード生成ツールが様々な企業で使われ始めている

AI創薬が実用化に近づいている

AI画像診断が初の承認を得る

スタートアップへの資金流入ペースは2021年に比べて減少中

世界の投資状況

分野別の投資状況: ロボティクスや半導体への資金流入が加速している

Exitや買収などは去年を超えるベースで増加している

政治

大規模モデル開発において産業界と研究界隈でのギャップが生まれている

リサーチ共同体が大規模モデル開発を行うようになっている

AI x 防衛がかわらず熱い

半導体製造の技術力はアメリカよりも中国・台湾が勝るようになっている

これ受けて、アメリカは自国の半導体製造メーカーを支援する代わりに中国への技術提供をストップするよう求めている

安全性

AIの安全性を研究する動きは勃興しつつもまだ市民権を得ていない

人間のFBを元に大規模モデルをより安全にしていく取り組みが模索されている

未来予想

音声の生成AIの発達やRedditなどのユーザー投稿サイトが大規模モデル開発に優勝データ提供を実施するとかは面白そう

コメント

2022年本当にいろいろありましたなという感じです。

出典

State of AI Report 2022

[GENZITSU]

Vald: OSS ANN Nearest Neighbor Dense Vector Search Engine - Introduction and Case Studies -

Kubernetes上で動作するベクトル検索エンジンの紹介スライド

気になったスライドのみ抜粋

コメント

検索エンジンにLBとリソース監視機能も一緒についてきてくれるのは嬉しい helmで環境構築できるのも◎

出典

• Vald: OSS ANN Nearest Neighbor Dense Vector Search Engine - Introduction and Case Studies -
• vdaas/vald

[GENZITSU]

End-To-End MLOps Platform at LINE

LINEで開発されているデータの取得からデプロイまでを一気通貫でサポートするMLOpsプラットフォームMLUの紹介スライド

MLシステムを構成する要素

MLOpsシステムの一般的なフロー

MLU

コメント

MLOpsシステムの一例としてとても参考になる

出典

End-To-End MLOps Platform at LINE

[GENZITSU]

20221116_MLOps勉強会_クックパッドマートにおける推薦タスクとMLOps

クックパッドマートにおけるMLOpsの事例紹介スライド

気になったところだけ抜粋

コメント

こちらの例も参考になる。 便利OSS結構あるんだなー

出典

20221116_MLOps勉強会_クックパッドマートにおける推薦タスクとMLOps

[GENZITSU]

プログラマが知るべき97のこと (1 ~ 20)

書籍版を読んだので要点をまとめていく

1. 分別のある行動

• やむなく産んでしまった技術的負債はできるだけ早く対処する
• どのような技術的負債があるかをトラッキング可能にしておく
• 技術的負債がどのような弊害を産むかを明確化しておく

3. ユーザが何をするかを観察する（あなたはユーザではない）

• ユーザーが何を考えているかを知るには、ユーザーがどう行動しているか観察するのが一番である

4. コーディング規約を自動化する

• コードを書いた人の私物からチームの共有物にしなくてはならない
• コーディング規約はテキストで定めても皆が遵守するわけではないので、自動的・強制的に守られるようにする
• コーディング規約は固定的ではなく流動的であるべき

5. 美はシンプルさに宿る

• 美しいコードというのはシンプルなコード
  • それぞれのメソッドを5~10行程度に抑える
  • 個々が担う責務を最小限に抑える
  • 部分同士の関連をシンプルにする
  • 機能を絞る
  • 機能の類推が可能な名前をつける

6. リファクタリングの際に注意すべきこと

• 既存のコード・テストコードを十分に検証する
  • リファクタリングによって質が落ちる可能性がある
• 既存のコードをできる限り活かす
  • 作り直すことで、これまで対処してきた問題にもう一度直面するかもしれない
• 1度に全て作り替えるのではなく、少しずつリファクタリングを行う
• 必ず既存のテストコードが通ることを確認する
• リファクタリングは保守性や機能、生産性の向上が見込める時だけ実施する

7. 共有は慎重に

• コンテキストを無視したコードの共通化をすると、無かったはずの依存性を生み出す

8. ボーイスカウト・ルール

• 既存のコードに手を加える時は、もとより少しでもよくしてからコミットする

11. ドメインの言葉を使ったコード

• ユーザー定義型を活用してドメインの言葉を利用する
• コードが表している概念を一眼でわかるようにしておく

12. コードは設計である

• コードを書くというのは機械的な作業ではなく創造的な仕事である
• 建設現場でまず模型を作るように、コーディング時にはまず自動テストを整備するべきである

13. コードレイアウトの重要性

• プログラマはコードを書くことよりもコードを探したり読むことにより多くの時間を使っている
• コードリーディングの効率化のために
  • 目立たない部分を作る
    • ドメインにに関係ない部分を目立たせないように、書き方のパターンを統一させる
  • レイアウトに語らせる
    • インデントや改行に何らかの意味を持たせる
  • コンパクトにまとめる
    • できるだけディスプレイ1枚に収まるようにコードを書く

14. コードレビュー

• コードレビューの目的
  • 誤りの修正
  • 知識の共有
  • 全員が守るべきガイドラインの確立
  • (+コードの共同所有化)
• Tips
  • レビュワーを固定せず、無作為に選ぶ
  • レビュー範囲の担当を決めておく
  • レビューを実施する日時を決めておく
  • レビューが楽しくなるように心がける

15. コードの論理的検証

• コードを短いセクションに分けてそれぞれが正しいと認められれば全体としても正しいという半形式的証明という方法がある
• セクション分け時のポイント
  • セクション中のプログラムのステートが簡単に説明できる
  • セクション中の状態変化は1つに絞られていて簡単に説明可能できる
• ベストプラクティス
  • グローバル変数は変更できない定数とする
  • オブジェクトのスコープを限りなく小さくする
  • オブジェクトは可能な限り、mmutableにするる
  • 特性や機能がすぐにわかる簡潔な名前をつける
  • セクションを入れ子にする必要が出た時は、それを関数にする
  • 関数は出来る限り短くし、機能は1つに絞り込む
    • 24行制限は、人間の認知能力が変化していない点で未だ有効である
  • 関数のパラメータはできるだけ減らす(最高でも4つまで)
    • どうしても多くなってしまう場合は関連するパラメータを1つのオブジェクトにまとめる
  • コードのどの単位においても、インターフェースをできる限り狭ばめる
  • オブジェクトの「getter」を使うのではなく、オブジェクトがそれを処理するようにカプセル化を行う。
  • オブジェクトに「setter」を持たせない

16. コメントについてのコメント

• コードは、次に見る人がすぐに理解できるように書く
• 書くのに苦労したコードは、読むのにも苦労する

17. コードに書けないことのみをコメントにする

• たとえコメントを入れても、それが不適切なものであれば価値はゼロ(あるいはマイナス)である

  • コメントがコードを読む人のノイズにになっては行けない
  • コードと同様にコメントも時間と共に劣化する

• できるだけコード自身に語らせ、コードで表せないことのみをコメントに付す

19. 誰にとっての「利便性」か

• APIを使う側にとって便利な実装を心がける
• APIとは複雑な処理の隠蔽である
  • 実装側は隠蔽のために頭を使わなけれならない
• より良いAPIを作るには、APIを言語とみなす
  • 一つの問題に対応する手段は1つである必要はない

20. すばやくデプロイ、こまめにデプロイ

• プロジェクトの初期段階からインストール/ ビルド手順を整えておく
  • プログラムは顧客の前で動いて初めて価値を産む
  • 本番と同じ環境で自動テストを回せるように準備しておくとなおよい

コメント

勉強になる

出典

• プログラマが知るべき97のこと(web版)
• プログラマが知るべき97のこと(書籍版)

[GENZITSU]

プログラマが知るべき97のこと (21 ~ 40)

書籍版を読んだので要点をまとめていく

21. 技術的例外とビジネス例外を明確に区別する

• 技術的例外とビジネスロジックからくる例外を同階層で処理しない
  • ビジネスロジック由来の例外はクライアントサイドで対応可能にする

22. 1万時間の訓練

• Peter Norvigは、何かでエキスパートになるには約1万時間の訓練が必要と述べている。いわばこの1万時間というのが「マジックナンバー」ということになる。

• Mary Poppendieckも、著書「リーンソフトウェア開発と組織改革」の中で「どんな専門的職業であれ、入念に計画された、集中的な訓練を最低10,000時間積み重ねることとで専門家になると言う」と書いている。

• Mary Poppendieckは次のように述べている。専門家のパフォーマンスを研究している人たちの間では、もって生まれた才能はあるレベルを超えると大きな意味を持たなくなると意見の一致をみている。プロスポーツ選手になろうと思った場合、確かに最低限の才能は必要だ。だがその後、勝ち抜いていくのは、最も厳しい練習に耐えた人たちだ。

• ただし、訓練とは自分にとって楽にできないことをやって初めて意味を持つ

24. 変更を恐れない

• 大切なのは、外科医が身体を切ることを恐れずに病気を治すように、コードに変更を加えることを恐れず、積極的にシステムを改良していく姿勢です。

25. 見られて恥ずかしいデータは使わないこと

• コードに入力するテキストは全て公になっても問題ないものにする

27. 死ぬはずのプログラムを無理に生かしておいてはいけない

• クラッシュするべき例外は握り潰すのではなく、ちゃんとクラッシュさせる

28. 「魔法」に頼りすぎてはいけない

• 自分があまり関わらない仕事を簡単だとみなして、「魔法」のように自動的にできるものだと錯覚しては行けない
  • 自分の知らない仕事をしている人を尊重する姿勢を忘れては行けない

29. DRY原則

• アプリケーション中の重複をできるだけ避ける

  • すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない

• 作業の重複があればそれは自動化する
• ロジックの重複を抽象化で防止する

30. そのコードに触れてはならない！

• 開発者はどんなことがあっても本番環境を直接触らないようにする
  • 唯一触って良いのは運用チームからの依頼があった時のみである

31. 状態だけでなく「ふるまい」もカプセル化する

• 状態だけをカプセル化しでも、ふるまいのカプセル化ができていなければそれはレコード型と変わらない

32. 浮動小数点数は実数ではない

• 浮動小数点には桁落ちや丸め誤差がつきものである
• Decimalクラスを適宜利用する

34. API設計の黄金律

• 「APIを提供するときは、API自身のテストだけでなく、必ずそのAPIを利用するコードのユニットテストも書く」

35. 超人の神話

• どれほど優れたプログラマも彼らも他の人と同じように、論理的に考え、体系的に分析をしない限り、どんな問題も解決できない

• どれほど素晴らしいプログラマであっても、はじめから十分な知識と技術を持っていたわけではありません。今は超人に見えるかもしれませんが、それは長い時間をかけて学び、自分を磨いてきたからです。賢い人が長い間、強い好奇心を持ち続けた結果、超人に見えるようになった

36. ハードワークは報われない

• ハードワークに酔わず、より少ない時間と労力で良い成果を出せないかを考える

• 脳外科医や航空機のパイロットと同じく、プロのプログラマなら、知識と技術の研鑽を怠ってはならないのです。それには主に、帰宅後や休日などの時間を利用することになります。

  • 脳外科医が週60時間も執刀していたとして、そんな医者にかかりたいと思うでしょうか?

• プロジェクトに貢献するとは、仕事に長い時間をかけず、より効率的な問題解決方法を探す努力を常にすることである

• プロはただ、がむしゃらに働けばいいというものではありません。プロの仕事には、入念な準備と効率化のための努力、そして日々の反省と絶え間ない変化が必要なのです。

37. バグレポートの使い方

• バグレポートに含めるべきこと
  • バグの再現方法と発生頻度
  • 本来期待される動作
  • 観測した動作
• バグレポートでは決してコードやコードを書いた人を責めてはいけない

38. 余分なコードは決して書かない

• 今必要なものだけを書く
  • 実装を作り込みすぎたことで、パフォーマスが劣化することもある

40. プロセス間通信とアプリケーションの応答時間の関係

• リモートIPCのチリツモで全体のアプリケーションの応答速度が大幅に遅くなることがある
• リモートIPCの減らし方
  • その時必要な最小限の通信だけを実施する
  • IPCを並列化する
  • キャッシュを利用する
  • IPCを減らすような設計を心がける

コメント

勉強になる

出典

• プログラマが知るべき97のこと(web版)
• プログラマが知るべき97のこと(書籍版)

[GENZITSU]

プログラマが知るべき97のこと (41 ~ 60)

書籍版を読んだので要点をまとめていく

41. 無駄な警告を排除する

• 警告(warning)はノイズになる
• 無意味な警告は見つけ次第潰す

44. IDEを知る

• IDEを利用する際はショートカットを積極的に覚える

45. 限界を知る

• データ構造やアルゴリズム、アーキテクチャーの時間・空間方向の特性をよく理解する
• ハードウェア性能の限界を抑える

46. すべきことは常に明確に

• 常に何をすべきか、いつまでにすべきかを明確にする

48. いろいろな言葉を学ぶ

• コミュニケーションを円滑するためにソフトウェア業界外の人が使う言葉を理解できるようにする

49. 見積りとは何か

• 見積もり、ターゲット、コミットメントを明確にする
  • 見積もり: 部分的な観測に基づく大まかな推測
  • ターゲット: 実現したい仕様
  • コミットメント: 期日や実現しようの約束
• 見積もりはターゲットやコミットメントが現実的なものかを判断するためのもので、約束ではない

51. プロジェクト自身にしゃべらせる

• プロジェクトの進捗や開発状況などは皆が自動的に気付きやすいように通知する仕組みを整える

52. 「その場しのぎ」が長生きしてしまう

• とりあえずで作った暫定解は思ったよりも長生きする
• 対応策
  • 初めから質の高いものを作る
  • 暫定解よりも有用なものを作って、不要にする

53. 正しい使い方を簡単に、誤った使い方を困難に

• 良いインターフェースとは: 正しい用法が、誤った用法よりも常に簡単になインターフェース
• 作る前に使ってみる
• 謝った使い方を困難にするには
  • ユーザーの間違い方を推測する
  • ユーザーの行動を観察する
  • そもそも誤った使い方を不可能にする
• 使い手の気持ちに立ってインターフェースを作る

54. 見えないものを見えるように

• プロジェクトや開発の状況を可視化する
  • テストコードを書く
  • テストを定期的に実行する
  • 掲示板やチケットを用いてプロジェクトの状況を可視化する
  • 動くものを作る

56. 未来へのメッセージ

• 自分の各コードは未来の誰かへのメッセージであると考える

58. テスト担当者はプログラマの友人

• テスト担当者は敵ではなく、仲間である

59. バイナリは常に1つ

• 環境ごとにバイナリを複数もつのではなく、設定ファイル + 1つのバイナリになるようにする
  • 環境に関するファイルも管理する

60. 真実を語るはコードのみ

• プログラムの動作を正確に把握するにはコードを読むしかない
  • コメントは補足であり、コメントに書いた通りに動く保証はどこにもない
• 書き手の意図が正確に伝わりやすいコードを書く習慣をつける

コメント

勉強になる

出典

• プログラマが知るべき97のこと(web版)
• プログラマが知るべき97のこと(書籍版)

[GENZITSU]

プログラマが知るべき97のこと (61 ~ 80)

書籍版を読んだので要点をまとめていく

61. ビルドをおろそかにしない

• ビルドスクリプトもプログラマの管理対象であり高品質に保つ

62. プリミティブ型よりドメイン固有の型を

• 1999年9月23日、火星探査機「マーズ・クライメイト・オーピター(MCO)」は火星を周回する軌道への突入に失敗し、燃え尽きました。3億2,730万ドルが失われた原因はソフトウェアのエラーでした。そのエラーは、具体的には「単位の混在」でした。

• ドメイン固有の型をつくることでコードの品質は高まる
  • ドメイン固有の名前がつきコードが読みやすくなる
  • 機能が一つ一つカプセル化され、テストがしやすくなる
  • コードの再利用が簡単になる

63. ユーザの操作ミスを防止する

• 「ユーザーに入力して欲しいのはあくまで情報であり、データではない」

• 操作ミスが起きにくいようにする
• 操作ミスに対して寛容にする

64. プロのプログラマとは？

• プロのプログラマとは
  • キャリアに責任を持ち、自分の力は自分で高め、常に最先端である努力する
  • 自分の書いたコードに責任を持つ
  • チーム全体のアウトプットに責任をもつ
  • 間に合わせの仕事をせず、自分の誇りにかけてできる限りのことを行う

67. コードを読む

• コードを読む際は色々考えながら読む
  • わかりやすいか？わかりにくいか？それはなぜか？

68.「人間」を知る

• ソフトウェア開発は人とともに、人のために行われる「人のビジネス」である

• ルートヴィヒ・ウィトゲンシュタインは「哲学探究」中で、「私たちが互いに話をする際には言語を使うが、私たちの頭の中にある思考や発想、画像などが、そのまま言語に変換されて他人の頭に送られるわけではない」と言っている

• プログラマーとユーザーの間にはツールを触ったことないという点で大きな意識のずれが存在する
• 物事を分類してユーザーを理解するのではなく、「例」を通して物事を理解せよ

70. シングルトンパターンの誘惑に負けない

• シングルトンをグローバルアクセス可能にすることがさまざまな弊害生まれる

72. シンプルさは捨てることによって得られる

• 質の悪いコードは容赦無く捨てる
• コードに余分な変数宣言や関数を残さない

74. 「イエス」から始める

• 顧客からの要望は、叶えられるかを始点に検討する
• 馬鹿げた要望が来た場合は、なぜそのような要望がくるのかを自問する
• 「ノー」から始まる対立関係ではなく、「イエス」から始める協力体制を作る

77. 偶然の仕様ではなく本物の仕様のためのテストを書く

• 実装の詳細にテストコードが強結合してはいけない
• テストコードは元々の要求を正しく実現できているかをみるものである
• ホワイトボックステストではなくブラックボックステストを書く

79. テストのないソフトウェア開発はあり得ない

• テストは、ソフトウェアの品質、再現性を保証するために必要不可欠なもの

• テストをするということは、作るものに責任を持つということなのです。

80. 1人より2人

• ペアプロによってソフトウェアの質は高くなる
• ペアプロはどのような関係性の2人でもお互い学びがある

コメント

勉強になる

出典

• プログラマが知るべき97のこと(web版)
• プログラマが知るべき97のこと(書籍版)

[GENZITSU]

プログラマが知るべき97のこと (81 ~ 107)

書籍版を読んだので要点をまとめていく

81. エラーがエラーを相殺してしまう

• 2つのバグが思いがけず相殺し、問題なく動作してしまう場合がある

  • アポロ11号の月着陸船のソフトウェア設計を指揮したAllan Klumppは、あるインタビューで、エンジンを制御するソフトウェアにバグがあったことを明かしています。そのバグのせいで、着陸船の動きが不安定になる恐れがあったというのです。しかし、結果的にそのバグは別のバグによって相殺されたため、発見も修正もされず、アポロ11号、12号の月着陸は無事成功しました。

82. 他者への思いやりを意識したコーディング

• プログラマには、開発チームだけでなく、ソフトウェアに関わるすべての人の成功に寄与する責任がある

• Ubuntuは元々、ズールー語で「他者への思いやり」という意味です。

  • Ubuntuの理念は”Umuntu ngumuntu ngabantu”です。これもズール一語で、翻訳すると「人間は、他の人間がいるお陰で、人間になっている」という意味です。

• 他人の存在を意識してコーディングをする

86. WETなシステムはボトルネックが見つかりにくい

• DRY原則の反対にWET(Write Every Time :必要なものをその都度書く)という概念がある
• WETによるデメリットはパフォーマンスチューニングの際にある部品による影響が薄まってしまうこと

88. コードは生涯サポートするつもりで書く

• いつも「このコードは生涯、自分がサポートし続けなくてはならない」と思ってコードを書く。

• コードを1行書く度に、ユーザのこと、顧客のこと、そして自分のキャリアのことを考えるべきです。このコードは自分の今後の人生を決めるのだ、と思って書くべき

89. 関数の「サイズ」を小さくする

• 関数が取り扱う状態空間をできるだけ小さくする

90. コードを見る人のためにテストを書く

• 良いテストコードはドキュメントのような働きをする
• 以下の三つを抑える
  • コンテキストや前提条件がわかる
  • どのように起動すれば良いかわかる
  • 期待される結果とその確認方法がわかる
• 時折テストコードが意図通りにエラーを検出するかのチェックをすると良い

91. 良いプログラマになるには

• 以下のような心掛けをする
  • 「とりあえず動く」だけのコードは書かず、誰が見ても正しいとわかり、美しいコードを書く
  • わかりやすく保守しやすいコードを書く
  • 他のプログラマと協調し、チーム全体の成果を最良にすることを考える

  • 自分が扱ったコードは、必ず、自分が最初に見た時よりも少しでも良いコードにする

92. 顧客の言葉はそのまま受け取らない

• 顧客の言葉を一回だけ聞いて理解したと思い込んではいけない。2度3度繰り返して聞くべきである
• 話し合う際は図や絵を利用する

96. テストは正確に、具体的に

• テストコードにコーナーケースがないかチェックする
• テストコードは明快で誤解の余地が内容に書く

98. 命を吹き込む魔法

• プロジェクトを楽しくワクワクするものにするために名前をつける

100. ルーチンワークをフローのきっかけに

• 集中状態に入るためのルーチンワークを持っておく

102. 快適な環境を追求する

• 身の回りの環境を整えて生産性を上げる

103. 見知らぬ人ともうまくやるには

• やっていいことだけできるように適切な権限設定を行う

104. 不具合にテストを書いて立ち向かう

• 不具合修正をする際は以下の手順を踏む
  • 1. 不具合の再現
  • 2. 原因の箇所を特定する
  • 3. 不具合が修正されたら通るテストコードをかく
  • 4. テストコードがちゃんと通らないことを確認する
  • 5. 不具合を修正する
  • 6. テストが通ることを確認する
  • 7. 既存のテストが通ることを確認する

105. 育ちのよいコード

• 品質の高いコードはコードの修正箇所もまとまっている傾向にある

106. Noといえることの大事さ

• 提供するソフトウェアのコア機能に関わらない部分の実装を拒むことでシンプルさを維持できる

107. 名前重要

• ネイテイブ・アメリカンの信仰に「すべての人物・事物には真の名前があり、その名前を知るものはそれを支配することができる」というものがある

• 適切な名前がつけられたものは実装の8割が完了している

  • 適切な名前をつけられると言うことは、その機能が正しく理解されて、設計されているということ

コメント

勉強になる

出典

• プログラマが知るべき97のこと(web版)
• プログラマが知るべき97のこと(書籍版)

[GENZITSU]

Assessing AI Trustworthiness Through Stress Tests

LINEにおける大規模言語モデルの倫理的安全性のチェック方法の事例紹介

LINEでは大規模言語モデルの安全性チェックのためにEthicsRaderというツールを作成している。

安全性チェックの流れ

テストケースの文章を入れてそこから出てくる文章の有害性をチェックするという流れ

安全性 + α のチェック項目

有害性チェック

意図的に有害なアウトプットを生成するためのadversarial triggerというものを作成している

adversarial triggerは事前に決めておいた有害な文章を勾配を用いて生成しやすくなるような単語の組み合わせを探索する手法である。

adversarial triggerを用いると普通に作ったテストケースよりも有害率が高まる

情報匿名性

効率的にテストケースを生成するためにRed Teaming、Iterative Few-Shotという手法を取り入れている

Red Teamingとは言語モデルによる生成文を対象の言語モデルに入力し、事前に作成した判定機を用いてテストケースのペアを自動的に作成する方法

Iterative Few-Shotは詳細は不明不明だがかなり、効率的にテストケースを生成できる模様

![Uploading スクリーンショット 2022-11-22 10.44.42.png…]()

公平性

こちらは2グループを代表するキーワードを入力して生成した文章のセンチメントを元に測っている

コメント

テストケースを人手で用意するのもなかなか厳しいなと思っていたが、自動的に作成する手法が模索されているのが興味深かった

出典

• Assessing AI Trustworthiness Through Stress Tests
• Universal Adversarial Triggers for Attacking and Analyzing NLP
• Red Teaming Language Models with Language Models