Deveroper メモ

記事内容に絶対の保証はなく..どちらかというと自分用のノウハウ蓄積ページ。 それでも良ければ見ていってください。

Gunma.web #52 テスト駆動開発

gunmaweb.connpass.com

表題の通り開催しました。 今回は あの @t_wada さんにお願いをして基調講演していただきました。

ちょうど前日に...

こんなブログの投稿があったもんだから、数人でワクワク感満載

t-wada.hatenablog.jp

t_wadaさん meet に来る

  • 会場の準備を済ませて、大型ディスプレイと繋げて PC を台上に置いて準備万端、あとは呼ぶだけ
  • 「初めまして」と数回お会いしたことはあるものの、こちらでは初めてだったので思わずこんな挨拶にw
  • 台上のPCを会場全体が見えるようにカメラを向けて欲しいと要望あり
    • 開催後、運営メンバーで「確かにオンラインで発表する側からしたら会場の雰囲気気になるよね」と
    • 幸い、ちょうどいい感じの高さの台で会場の雰囲気が伝わりやすいカメラ位置だった。
    • 次回オンラインでゲストを呼ぶ開催時の反省点としたい

いよいよ始まる

  • 当日の流れはこちら
  • やはりというか前日のブログ記事の話題に

FizzBuzz のTDD(ライブコーディング)

  • スムーズにライブコーディングというか、箇条書きにテストケースを同じ文脈に揃えることを解説しながらやってました。
    • 実際に自分でやるとなったら、ここまでスムーズは難しいよな。
    • 見せ方も非常に上手。確実に相手に伝わってる感ある

解説しながら用語など解説

  • テスト容易性
    • 観測容易性
    • 制御容易性
    • 小ささ
  • Humble Object Pattern
    • テスト容易性を低く下げている要素を薄く切り離すテクニック
    • 標準出力など
  • ToDoリスト作る段階が一番重要
    • テスト容易性 と 重要度 を 「高 」と「低 」に分割できれば勝ったようなもん
    • 同じ文脈で揃えていく
  • 3Aパターン
    • 準備:Arrange
    • 実行:Act
    • 検証:Assert
      • 検証から書く!
  • テストをゴール(Assert)から書くの最初むずいけど慣れると無駄な準備コードを書きすぎずにスムーズになるイメージ
  • 作りやすさに引っ張られると使いやすさが犠牲になる
    • 作る前に使う側に回ればその悲劇を回避できるのでは
  • 仮実装
    • テストを通過させるような簡単なコードをわざと書く
  • テストコードのテストは実装コードでやる
    • 実装コード(product code)をいじってわざと失敗させる
  • 三角測量
    • 2つ以上の値を使用しテストを書く
    • ここでテストが失敗するが、狙い通りの失敗 -> 失敗することを確認する
  • 明白な実装
    • 自信があれば = 明白な場合は 三角測量せずに本実装しても良い

ここに来て...バッドシナリオ!!

  • 動作する詳細設計書になっているか? -> 違った
    • 現場あるある話
  • 仕様の構造をテストコードの構造に落とし込む
    • テストコードを仕様書として読めるようにリファクタリング
    • テストの実行結果を粒度を揃えたツリー構造として表現する
  • 三角測量で書いたテストは不要なテストとなる可能性がある
    • 不要なもの = 意図が伝わらないものは未来のために消しておく
    • 残っていくテストのメンテナンスコストも考える

終盤

  • いよいよ完成系になってきたところで、TDDを続けていく上で必要なことを解説
  • テストがあると楽っていう体験をしてもらう

下記の記事の紹介

fortee.jp

gihyo.jp

質疑応答

  • DB にロジックを埋め込んでしまった場合はどのようにテストすればいいか?
    • DBから値を取得したという前提で、ロジックの部分を切り出してテストする
    • この本の紹介
    • 背景の後ろがリアル本棚で数人がビックリ!
  • 現場で実際には緊張したりする場で、重複がある事を気づかず次に行ってしまいがちになる事がある どうしたらいいか?(自分の質問でした)
    • コピペ判定ツールを使ってみる。
    • 構造化して、文脈で同じ事を気付きやすくする
  • etc...

t_wada さん発表時の slide

  • 今回のものが大体網羅されているので、これを貼り付けておきます。 speakerdeck.com

基調講演の後のLT

  • 素晴らしい発表のあとに LT をするのは緊張感半端ないですね。
  • 自分の LT はこれをしました。 speakerdeck.com

終わった後...

  • t_wada さんの発表は「TDD の良さはこれだよ!」と言いたくなるくらいに解りやすく伝わりやすいものでした。
    • 自分じゃこうは出来ないな〜汗
  • 特に感じたのは...
    • インクリメンタルな開発・設計 の部分ですね -> この言葉自体も今回がキッカケで知りました。
    • 頭の体操に近いとか感覚の話を後輩にするのですが、一番大切な要素は、動作する詳細仕様書(設計書)であり、「反復しながら動作を頭の中に整理しながら落とし込んでいく、人に優しい手法」だという事が伝わってない感あったのでいい経験になりました。
  • さて、来年度の研修資料を作り直すぞ〜!

Ruby の rescue

今更ながら Ruby技術者認定試験のGOLD を受けようと思い
模擬試験問題を解いていたところ...奇妙なコードに出くわした。
忘れると痛い目を見そうなので、ここに記述する

begin
  'aaa'.bbbb
rescue
  puts "レスキュー出来たね"
end

#=> レスキュー出来たね

何も問題はない

begin
  'aaa'.bbbb
rescue NoMethodError
  puts "レスキュー出来たね"
end

#=> レスキュー出来たね

これも問題ない
期待通りの動きである

begin
  'aaa'.bbbb
rescue NameError
  puts "レスキュー出来たね"
end

#=> レスキュー出来たね
  • むむ?
    • エラーの種類が違うのでは?
begin
  'aaa'.bbbb
rescue StandardError
  puts "ここには来ないよね?"
rescue NoMethodError
  puts "レスキュー出来たね"
end

#=> ここには来ないよね?

来てしまったのである
原因を追うと...

NoMethodError の親クラス = NameError
NameError の親クラス = StandardError

という事みたい。
トラップだな。気をつけないとね。

クリーンアーキテクチャを読んで...

  • 印象に残ったことをつらつらとメモに残しておきます。
    • 読むだけだと忘れるので
    • まずは 22章まで

以下印象に残った文章

  • アーキテクチャの重要性は変更コストによって計測できる
  • 不完全な知識で運用する事を認める
    • そうするのが人間であり得意である
  • アーキテクチャは、実装と計測によって証明すべき仮説である
  • 設計とアーキテクチャに何も違いはない
  • ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑える
  • ソフトウェアのソフトは...簡単に振る舞いを変更できるため
    • 対して変更ができないものをハードウェアとよんだ
    • ウェアはプロダクトの意味
  • アイゼンパワーのマトリックス
    • 緊急と重要の2種類の問題がある。緊急と重要は違う。重要なことが緊急になるわけではない
  • 3つのパラダイム
  • 「構造化プログラミング」の価値を高めるのは反証可能なプログラミングの単位を作成する能力である
    • 機能分割がベストプラクティスであると考えられる理由
  • UI, ビジネスルール, DBアクセス
    • ビジネスルールは 独立させる事ができる
    • ビジネスルールは独立してデプロイ可能である
    • DBやUI とは別のチームが開発可能である
  • 構造化プログラミング
    • 直接的な制御の移行に規律を課すものである。
  • オブジェクト指向プログラミング
    • 間接的な制御の移行に規律を課すものである。
  • 関数型プログラミング
    • 代入に規律を課すものである。
  • ソフトウェアの振る舞いは、既存の成果物を変更せず拡張できるようにすべき
    • アーキテクチャを学ぶ理由
    • 拡張ではなく大量の変更になってしまったら失敗である
  • SRP
    • 単一責任の原則
    • モジュールはたったひとつのアクターに対して責務を負うべき
      • 単一の修正が一つだけではなく複数の修正を誘発してしまうのは違反
  • OCP
    • オープンクローズドの原則
    • 拡張に対しては開き、修正に対しては閉じてなくてはならない
    • 既存の成果物を変更せず拡張できるようにすべき
  • リスコフの置換原則(LSP)
    • クラスの継承 = S型のオブジェクトo1の各々に、対応するT型のオブジェクトo2が1つ存在し、Tを使って定義されたプログラムPに対してo2の代わりにo1を使ってもPの振る舞いが変わらない
    • 派生型である
    • 置換可能性に少しでも違反してしまうと、システムのアーキテクチャが特別な仕組みだらけになってしまう
  • 変化しやすい具象クラスを参照しない
    • 変化しやすいクラスを継承すると
    • 変化のたびに変更が必要になる危険性があがる
  • 全再利用の原則(CRP
    • どのクラスをひとまとめにすべきか ではなく...
    • どのクラスをひとまとめにすべきではないか
  • 循環依存は厄介
    • あるコンポーネントの変更が 依存関係を循環し、自身にも悪影響を与えてしまう
    • 解消するには依存関係の逆転が必要
  • 初期段階では必要しないが...モジュールなどが増えてきたら
  • 独立コンポーネント
    • 外部要因で変更が必要になることはない
    • ほかのコンポーネントに依存していない
  • 複数のコンポーネントに依存しているコンポーネント
  • ファン・イン
    • 依存入力数
  • ファン・アウト
    • 依存出力数
  • 不安定さ
    • I = ファン・アウト÷(ファン・イン+ファン・アウト)
  • 「方針」と「詳細」
  • アーキテクトの目的
    • 方針とは無関係に詳細を決めながら、方針をシステムの最も重要な要素と認識するシステムの形状を作ること
    • 方針を決める際に 詳細を気にする必要はない
  • 会社がDBの選択を決めていた場合...
    • 優秀なアーキテクトならば、まだ決まっていないと主張するだろう
  • 切り離し方式
    • ソースレベル(rubygems など)
    • デプロイレベル
      • あるモジュールのソースコードに対する変更が、ほかのモジュールに影響を与えない単位
    • サービスレベル(マイクロサービスなど)
      • 物理的な場所に依存しない、通信で繋がっている
    • どの方式が最適か?は初期段階で判断するのは難しい
      • サービスレベルは依存が疎になりやすいが、コストが大きくなりやすい
      • 初期はソースやデプロイ単位で切り離すが、サービスレベルで切り離せるよう組んでおく(著者の好み)
  • 早すぎる決定とは...
    • ビジネス要件とは関係のない意思決定をしてしまう
      • framework, DB, web server, ライブラリ, etc...
    • 1台しかサーバが使えない状況もあり得る
  • 境界線を引くとは...
    • 例: RDB を使うべきか? 迷っている
      • データの入出力をする部分に「境界線」を引いた(疎結合にした)
      • 結果: TEXT ファイルで十分だった
      • 境界線以降をtextファイルにした
  • DB と ビジネスルールは別物
    • 本来切り離せる
    • DB を何にするか?決定を遅らせても構わないはずである。
  • エンティティ
    • 最重要ビジネスデータを操作する最重要ビジネスルールを含んだインターフェース
    • ビジネスを表すものとして独立させる
    • これがないとビジネスとして成立しない最低限の単位
  • ユースケース
    • 自動化されたシステムを使用する方法を記述したもの
    • アプリケーション固有のビジネスルールを記述する
    • 入力データ、出力データ、それらがやり取りする適切なエンティティへの参照といった、データ要素を持っている
  • エンティティは自身を制御するユースケースのことを知らない。
  • クリーンアーキテクチャ
    • 依存関係の方向性と円の図
    • 図はいろいろなサイトに載っている
    • 依存の矢印は外側から内側に向かわせる
    • フレームワーク非依存
    • テスト可能
      • ビジネスルールはDB, http, その他外的要素がなくともテストできる
    • UI非依存
      • ビジネスルールの変更なしに変更できる
      • 項目自体を増やすとかじゃなく...http 経由 -> コンソールUI にするなど
    • データベース非依存
      • ビジネスルールはDBが何であろうと構わない -> 束縛されない
    • 外部エージェント依存
      • ビジネルルールは外界のIFを知らない
      • ブラウザ経由 -> アプリにする際に変更がない

「エンジニアリング組織論」を読んで...刺さった言葉集

前提

  • ただ漠然と読むのだと、読んだ後覚えてない事が多いので刺さった言葉を文章に書き出してみる

以下、箇条書き

  • エンジニアリングは実現の科学
  • 認知範囲とシステム思考
    • 視野の広さと視座の高さ
  • 個人でなく関係性に注目する
    • 無能で十分に説明のつくことを悪意のせいにするな
  • 「自ら考える人材」
    • 自ら問題を発見し解決することができる
    • 自立型人材
  • 謙虚、敬意、信頼
  • 階段を上る手助けをする
  • 自己説得
  • 問題の可視化
    • 人 対 人 -> 問題 対 人
  • ラーニングゾーン
    • NG: コンフォートゾーン(忖度), 無関心ゾーン, 不安ゾーン
  • SMART
  • コントロールできない
    • 能力, 成果
    • 「プログラミングできるようになれ」は威圧でしかない
  • コントロールできる
    • 行動, 習慣
    • 階段を自力で上がれるようになるまでサポートし続ける
  • アジャイル開発は3倍の成功率、1/3の失敗率
  • プロジェクト, プロダクト の違い
    • プロジェクト: 始まりと終わりがある
    • プロダクト: うまくいけば終わりはない(継続される)
  • アジャイルをするなアジャイルになれ
  • チームマスタリー
  • ウォーターフォールアジャイルは 見る対象自体が違う
    • 比較するの事に意味があるのか?(似たもの同士ではない)
    • アジャイルは経営理論に近い考え方
  • what に対する学習, how に対する学習
  • 暗黙知形式知 にする
  • リーンとは贅肉を削ぎ落としたという意味
  • チームに権限委譲する
  • AよりもBを重視しよう -> A はいらなくないよ
    • いらないと曲解されがちである
  • 通信不確実性を減らすには...
    • 大人数よりも少人数
    • リスペクト
  • 不確実性の3種類
    • 方法不確実性
    • 目的不確実性
    • 通信不確実性
  • 情報の非対称性
  • 多点見積もり
    • 偏差が大きい順に不安度が高い
    • 優先順位を上げる
  • エージェンシースラック
  • 目的不確実性
    • 何を作るか?が不明瞭
  • 動作可能なプロトタイプを最も安価な方法で作り、早期に動作を確認してもらう
    • データベースの詳細な設計は後回し
    • データベースの設計を見て仕様変更を指示されないから
    • 仕様変更があるか?確認を後回しにしない。
  • ユーザストーリー
    • どのような人が
    • 何ができる
    • そのことでどのような感情になる
    • ユースケース図との違いは「感情」が絡む
  • 検証とは
    • 仮説を構成する不確実性のうち最も大きなものを最も安いコストで削減する
    • 小さなコストで検証し失敗したら別の仮説をたてる -> 繰り返して仮説検証を成立させる
  • 高価値、高リスクのものほど「早く安く」実現する
  • インセプションデッキ
    • whyを明らかにする
    • howを明らかにする
  • デリゲーションポーカー
    • 権限の委譲には7つの段階がある
  • 技術的負債の4象限
    • 意図的な
    • 無意識の
    • 慎重な
    • 無鉄砲な
  • 「綺麗さ」と「速さ」は交換可能だが...
    • ソースコードが汚くて遅い人もいれば、綺麗で速い人も多くいる
    • 要求に対して綺麗さと速さを意識する事は不可能では?
  • 見える/見えないの軸, プラスの価値/マイナスの価値の軸がある
    • 見える+: 新機能
    • 見えない+: アーキテクチャ
    • 見える-: バグ
    • 見えない-: 技術的負債
  • 技術的負債の定量
    • 理想システムの追加工数との差(現状システムとの)
    • それぞれにある機能eを追加しようとしたときに、かかる工数に差が生まれ、それが技術的負債の単位
    • 理想的なシステムというものを具体的にしないと不明なままだが...「技術的負債への対策」にどの程度のコストを費やして良いか?は考えられる。
  • 技術的負債のポイント
    • エンジニアと経営者の認識の差
    • システムの複雑性の増加そのものではない
  • 情報の非対称性の解消は「コミュニケーション」そのもの
  • システム外注における取引コスト
    • 探索のコスト: クオリティの高い技術者を探すのは困難
    • 交渉のコスト: 契約条件を整える
    • 監督のコスト: 品質を監督しクオリティの維持をチェック
    • 結局コストがよりかかるので内製化が進む
  • 機能横断チーム
    • 地理的に近い配置
    • 十分な権限委譲
    • 心理的安全性の高さ
    • 目的の透明性
    • 様々な職種のメンバーが1つの目的のために集まる
  • 機能別組織
    • 特定の職種の人を集める
    • ビジネス上の競合が特定分野に限定されればこれの方が良い
  • 知の探索
    • 機能横断型組織による組み合わせを考える
    • 新しいビジネス分野を開拓していくための活動
  • 知の深化
    • 機能別組織によって行われるような特定の領域の効率を上げる
    • 注意が必要: 勝ち筋が見えると特定領域のみを考えるようになってしまう
      • コンピテンシートラップ
      • バランスを見る必要がある
      • 全体で見れば利益になっていない事がありがち
  • 誤解された目標管理
    • ノルマに渋々従属し給料をあげないための成果主義
    • ホワイトカラーとブルーカラーによる衝突
    • 機械の一部のようにあつかうマネジメントには限界がある
  • 目標による管理
    • 心理学の成果を取り入れる事で生み出されたもの
    • ノルマとは本質的に違う
    • ピーター・ドラッガーの本にも書いてある
  • 本来の 目標による管理 の目的
    • 目標設定による主体性向上
    • モチベーションアップ
    • 問題解決能力の向上
  • セルフコントロール
    • 従業員自らが設定し
    • 従業員が納得して達成に臨む
    • モチベーションの内的動機付けを重視
  • 目標はなるべく定量化する
    • 定量化すると達成できたか出来ないかを判断しやすくなる
    • 透明性を重視した
      • 何をもって達成できたか?を明確にした
      • 情報公開する
      • 情報非対称性, 限定合理性を減らしていく

Gunma.web #38

gunmaweb.connpass.com

初のオンライン開催という事で色々とドキドキしながらも無事開催できたという感じです。

オンライン

ビデオチャットは zoom を使いました。 比較的、ここはスムーズに出来たかな?と。 ただ、人数と料金のバランスを見ると google meet でもよかったような...という反省点です。 (google meet の方が安い)

発表中の盛り上げは comment screen を使いました。 こちらも比較的盛り上げることに成功したのですが...これをやると twitter で盛り上げる手が追いつかないというオチが.. みんなどうやってたんだろう?

他の人の発表

gunmaweb.connpass.com 今回も色々な話が聞けてうれしかったです。

とりわけ、slack app開発のフレームワークの話は自分でやる時の参考になりそうですし
web管理画面から伝票を出す仕組みは驚きでした。(youtubeの動画)

自分の発表

自分はPWAの今さら聞けない話を発表しました。 正直、応用的な技術は発表できませんでしたが、基本はやり切った感があります。 また、解りづらい点などツッコミ下さい要望にも忌憚なく意見を言っていただいたので、参考になりました。 ありがとうございます。

speakerdeck.com

では、みなさんまた次回にお会いしましょう!

devsumi 2020

久々に devsumi 2020 に参加しました。

  • 前提として...刺激になる講演が多く、ほとんどが為になりそうなものでした。
  • 自分が聞きたかったものがそういうベクトル? になっていたのか、解りませんが、登壇者は違うのですが発表されてる内容がフラッシュバックしまくってました。
  • その中でも特に印象に残ったものを ブログに残します。

世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた

発表者

  • 鈴木 雄介
  • 河村 明彦

三越伊勢丹グループにおけるDX推進

三越伊勢丹 の靴売り場とは?

  • 世界的に有名なお買い場
    • 売上: 62億円/年
  • 三越伊勢丹用語
    • お買い場 = 売場
    • スタイリスト = 販売スタッフ

yourfit 365 を作った時の話

道のり

2年間、模索期間

  • シューカウンセラー
    • 三越伊勢丹が独自に整備した資格制度
    • そもそも足に合う靴を提供したいという文化があった
  • スキルさを埋めるために 3D計測が使えるのでは?という仮説があった
  • 2年間、計測し続けて...
    • 計測精度が高い
    • トライヤル期間を得て「勝てる」と確信
    • ここまですべて現場(お買い場)の予算でやった。
  • アジャイルの開発手法でやる事に...
    • 企画からのTOPダウンではない
    • 現場と やりとりすべき
    • 現場(お買い場)の担当者を情報システムに異動
      • この人が PO を兼ねる
      • システム開発の経験がないためPOを支援するメンバーを入れる
  • お買い場 <-> PO <-> 開発チーム

立ち上げ

  • ワークショップを開催
    • 関係者全員が参加
    • バイヤー、マネージャー、シューカウンセラーなど
    • ビジョンと優先度を共有
  • データを入手
    • 木型を集める
      • レコメンドには木型が必須
        • 足形と比較するよう
      • 来門外不出
        • 靴の設計書と同意義のためコピーが作られてしまう
          • メーカが渡さない
        • 過去からの信頼もあって貰えた
  • 現場(お買い場)とともに
    • スタッフ全員がやる気になる
    • サービス名、デザインなどスタイリストが選定
    • 頻繁にデモしていく
      • 実際に使いながら意見をもらう
      • 不必要なものがなくなった
  • 業務とITを同時に検証
    • システム側の都合で業務が変わる部分が明確になる
    • その逆もある
  • 実質3ヶ月で初期リリース
  • 8/28 にリリース
    • メディアにも取り上げられる
      • 数十件/日
      • 接客には 1.0h-2.0h
    • 継続的な機能改善
      • 最小機能でリリースしたため日々のフィードバックを毎週リリース
      • 小さく出して大きく育てる

次にむけて

  • 開発をストップして考えるフェーズにする

    • どうすれば価値が上がるか?
      • どう利用されて、何があれば便利か?
      • 何をすれば満足度を下げずに効率化できるか?
    • ユーザビリティ調査
      • 閉店後にお客様を招いて行動観察
        • 改めて検証する事で意見が多数
  • 再来店を促す

    • 夏に買ったお客様が秋冬の靴を買いに来る
    • 同じ木型は安心して買える
    • 明らかにコンバージョン率が高いため自動化を実施中
  • 足形から靴を作る
    • 市販靴の領域でカバー出来てないものが明らかに
    • その靴に合う人むけにプロモーションを予定

ともにつくるとは?

  • 当事者意識を持って行動する
  • 当事者にならない人は不要
    • 企画部門問題
    • 「それAIで」問題
      • 定義がないのに、何がAIか!?
  • お客様から学んで改善する
  • 当たり前だけど難しかった
  • アナログと、ともにつくる
    • デジタルが中心ではない
    • 両方がいい方向に成長するよう
  • 既存組織とともに作る
    • 適度な自治権
    • 距離感が重要
      • 既存に影響されてスピードがでない
      • 既存と切り離しすぎてもスピードが出ない

「ともにつくる」を実践するドメイン駆動設計

発表者

DDD(ドメイン駆動設計) の必要性

こんな経験ありませんか?

  • 新しいシステム使いづらい
  • 大金かけたのに使えない
  • 経営グループと開発者と利用者で情報が断絶
  • 大した修正じゃないのに時間かけすぎ
  • あの人バグ多いよね

どうして起きるのか?

  • 詳しい人がいない
  • 仕様書がない
    • 仕様を探す旅に出ます
    • つまりコードを追っていきます
  • コードを見ても解らないと旅が長くなります

ドメインって何?(よくDDDの本に出てくる用語の解説)

  • URLに出ているあのドメインじゃないよw
  • この領域、このエリア
    • 配達の仕組みで言うと
      • 荷物
      • 集荷センター
      • 輸送トラック
  • 何が重要か?は企業によって異なる -> 知識
  • 知識をモデルに落とし込む = モデリング
  • モデルをコードに落とし込む = ドメインオブジェクト
  • ドメインを知るのは誰? = 実際に運用してる人
  • 実際に運用してる人 = ドメインエキスパート
  • 実際に運用している人と共通言語を決める
  • 共通言語 = ユビキダス言語

ドメインエキスパートであってもドメインはぼやける

  • 厳密に定義されてない場合がある
    • 企画: お客さんに荷物がどうなってるか?知ってもらいたい
    • ドメインエキスパート: 解りました。from と to をcommit してlogに残すようにします。
    • 企画: ??? うん。とりあえず、それで...
    • 結果: 中継地点を通ったという記録しかないので、配送全体のステータスが解らない
    • 本当に必要なもの: 発送(xx:xx) -> 集荷センター(xx:xx) -> xxに配送中(xx:xx)いまここ -> お客様
  • 行き違いが起きやすい
  • 共通言語は作る側が主体となってやるべき
    • ドメインがぼやけていると自覚出来るのは誰なのか?

構成要素

  • 分け方(例)
    • backend と front や ビジネスロジック と データレイヤ
    • 開発チームが別れる
    • コンテキストマップが補助になるはず

経験談

  • ドメインの把握は難しい
    • 一人じゃ出来ない
    • 開発チームだけでも出来ない

受注開発時代...

  • 製鉄所システム
  • 鉄の焼き方, 冷やし方
  • ただワンパターンに焼いて冷やせばいいというものではなかった
  • しかも長年勤めている人にじっくりヒアリングしてようやく出てきた
    • 冷やし方に複数のパターンがある
    • 相手の受付窓口の人だけじゃ出てこなかった

言うは易し、行うは...

  • 開発作業をやりながら出来るの?
  • でも、やりたいよね?
  • どうやるか?
    • 色んな人を巻き込みながら
    • DDD の必要性を説きながら

プリンシプル・オブ・“ともにつくる”~ Web Performerを支えるドクトリン ~

はじめ延々と 前座を語られる..前座がメインかってくらい(心理学系)

我と汝、我とそれ

  • 我と汝
    • 相手を人間として扱う
    • 相手も自分を人間として扱う
  • 我とそれ
    • 相手を人間として扱わない
      • 例: 自分がお金を払う側の場合
      • 人を使って当たり前と接する
      • 相手もお金を払うマシーンとして扱ってくる

シニフィアンシニフィエ

  • シニフィアン
    • 「海」という文字や、「うみ」という音声
      • free = 自由 と 無料 という曖昧さをもつ(一つの意味ではない)
  • シニフィエ
    • 海のイメージや、海という概念、ないしその意味内容

無知の知

  • 無知にも大きく二つに別れる
    • 既知の無知
      • 自覚がある部分
      • 知らない事を知っている
    • 未知の無知
      • 自覚がない領域
  • 自分が無知である事を知る
    • 謙虚な姿勢

Web Performer(ほんのちょっと)

  • canon の開発ツールの話
  • GUI からDBのモデルを自動生成 -> java?

プロダクトを10年運用するチームをつくる

発表者

  • 粕谷 大輔さん
    • はてな
    • Mackerelチームディレクター

Mackerelの話

変化し続ける周辺環境とシステム

  • 格言: 動いているシステムは触るな
    • NG
    • 触らざるを得なくなる
      • os update
      • security
      • 他社と通信する系
        • 他社が新しいものを作ってくる
      • ブラウザのupdate
  • CI/CD
    • テストの自動化, デプロイの自動化
  • 監視の整備
  • devops の構築
    • 開発と運用は表裏一体

人の入れ替わりへの対処

  • 異動や退職、新陳代謝
  • プロダクト固有のスキル, ドメイン知識
  • スキルマップ
    • 誰がいなくなると、どこのスキルが失われるか?が解る
      • 人によっては、複数のスキルが一気に失われるので回らなくなる事に気付ける
    • 学習目標の指針になる
    • 運用のコツ
      • 評価には使わない
      • 正直に答えてもらう事が重要
      • 項目の粒度を気にしない
        • 粒度を気にすると決まらない
        • 一旦は慣れている粒度でやる
      • 定期的なメンテナンス
  • 障害対応
    • 属人化しがち
      • 古参メンバーの独壇場
      • 新規メンバーはなかなか入り込めない
      • そもそも緊急事態なので丁寧に教育していく暇がない
    • なので演習を行う
      • ステージング環境をわざと落とす
      • 頻度
        • 半年に一回
        • 今まで障害対応してこなかった人を中心に参加させる
      • 何が出来ないか?が解る

式年遷宮

  • 元々は...
    • 神社などにおいて周期を定めて社殿を更新する
    • 新たな社殿に神体を移す
  • 定期的に社殿を建て替える
    • 隣にまったく同じものを建てる
    • 宮大工の技術継承
    • 社殿の姿が恒久的に維持される
  • ソフトウェアの場合
    • アーキテクチャフレームワークなどシステム根幹部分に手を入れるようなプロジェクトを一定間隔で行う
    • モダンなソフトウェア環境への適応
    • エンジニアの技術継承
      • 前パートの「人の入れ替わり対処」も兼ねる
  • 現実の式年遷宮と異なりフルスクラッチではない。
  • スケールアップへの対処。
  • エンジニアの技術継承

apng を python で見つける

python でバイナリーを解析する勉強がてらに書いてみました。

qiita.com

crc32 の使い方など、中々いいトレーニングになったかな?

オチとしては 既にきちんとした ライブラリ が出回っていた点かな苦笑

目的は達成したので結果オーライ。