How Microservices are linked at Cookpad 参加レポート #microsvc

microsvc 勉強会 技術

イベントページ

connpass.com

スライド

speakerdeck.com

今回離さないこと

  • 包括的な話

今回話すこと

  • 事例をどんどん話す

どんなサービスから構成されているか

  • 粒度も含め
  • 社内で明確なルールが有るわけではないが以下の3つ。
    • ユーザーサービス
    • ビューサービス
    • 共通基盤
  • 1つの事業ドメインだとあまり価値が無いのかもしれない

ユーザーサービス

  • 「料理を通じて＝レシピがあれば良い」というわけでない
    • 料理教室とか
    • 特売情報とか
    • 産地直送便を結ぶサービスとか
  • それに特化した独立したサービスを作る
  • ドメインは隣接しているので、他のドメインを使ったりする
  • よくある機能は共通基盤を活用
  • 大事なことは、逆向きになっても良いようにすること

ビューサービス

  • Backend for frontendsに近い
  • デバイスごとに専用ビューを作ることはほぼない
  • OEM版で使われたりする

共通基盤サービス

  • UIもあればAPIのみのものもある

連結方法

  • RESTful Hypermedia API
  • クックパッドのモデルは非常に多い
  • 特定の高負荷なモデルが有るわけではない
    • パフォーマンスの最適化よりも柔軟性重視

Garage

Garage Client

  • xxx-clientが無限増殖しないで済む
  • 特定のサービスを使う時の学習コストがかからない

サービス間通信のコスト軽減/耐障害性

Expeditor

  • 基本的な非同期実行や条件付きの非同期実行、サーキットブレイクなどは搭載されている
  • RESTであるユーザーの情報を複数のサービスから集めたいとかに使える

互換性の担保について

  • サービス間連携をどうテストするか
  • Rubyの会社は型を意識することがあまりない
  • 動くものに対してなんとかしようと考えることが多い

CDC Testing

Pact

  • クライアント側がテストを書いてCIで回す
  • Pactファイルを生成してBlocker側に渡す
  • 自身がそれを実装されているか試す
  • WEB Mockにほぼ近い
  • 後は普通にテストを書くだけ
  • テストした後の生成物は中身が出てくる
  • API側は必要な前処理を用意することで、後はPact側が自動的にテストしてくれる

Rack::VCR

  • 以前導入していた
  • クライアント側が意識しなくてもスタブを用意してくれる
  • API側のビルドが高頻度の場合、クライアント側の検知前にリリースされうる

エラーの追跡

Sentry

  • サービスごとのエラーを集約管理している
  • ただし、サービス間のひも付けはできない
  • リクエストIDを採番する
    • Railsはデフォルトで採番している
  • GarageClientがリクエストIDを次のリクエスト先に伝搬すれば良い
  • Sentryでエラーを検索できるようにしている

Docker

  • 巨大なRailsアプリ以外はほとんどDockerになっている
  • プロダクション環境もDocker
  • 環境依存地のみ環境変数として注入
  • アプリケーションリポジトリに入っている
    • poppetではモジュール管理が複雑
      • インフラ関係者しかできない
  • 手元でミドルウェアを増やすとかもできるように
  • 開発者の自由度を上げる

ビルドパイプライン

  • masterにマージ
  • CIでテスト
  • Dockerのイメージ作成
    • assetなども作っちゃう
  • 自動でデプロイ
  • Chatでデプロイを実行する

Hako

  • デプロイ管理
  • 以前はインフラメンバや基盤メンバが細かく設定を書いていた
  • アプリケーションごとの設定はYAMLで管理

etcenv/etcvault

  • etcdで設定値を管理
  • 特定のカギを持っているインスタンスでしか復号できない

Chat ops

  • Hubotでdeploy
  • 裏ではRundeckで管理
  • デプロイコマンドはアプリケーションに特化しているのでRundexkで管理
  • 基本、Hubotで言えばdeployできる形で統一

バッチジョブ

kuroko2

  • Jobのワークフローの管理
  • 全サービスのJobを一括管理
  • フックして別サービスをKickする
  • サービスの最新のDockerイメージを実行するように
    • 以前だと、ワーカーでサービスごとの構成管理をしていたので、Kuroko用とワーカー用のアプリケーションで管理を別々にしなくちゃいけなかった

組織的な話

技術領域課題共有会

  • 名前とは違い、ざっくばらんな話し合い
    • こういうコマンド毎回打つのだるい
    • ドキュメントどこー
    • 技術的にこのやり方は…
    • こういうのがあったら使う？
    • こういうのまだ使ってる？
      • メンテコストが高くならないように
  • 感覚値がチームによって違うことが把握できる

技術基盤担当

  • 技術基盤に余力があるか、経験のある人がいるかどうかがチームによってバラバラになりがち
  • サービスが大きくなると、どういう基盤があるか分からなくなりがち
  • 各チームに専任の技術基盤担当がいるようにする
    • MTGに参加したり
    • カジュアルな相談に答えたり
    • 必要に応じてガッツリ入ったり

『マイクロサービスアーキテクチャ』とAzure Service Fabric 参加レポート #microsvc

microsvc 勉強会 技術

イベントページ

connpass.com

スライド

docs.com

自己紹介

Microservices

  • Microserviceの言葉が出来たのは2011年5月
  • James LewisやMartin Fowler
  • Netflixなどが初期から採用
  • 日本ではクックパッドが初期に採用
  • Sam Newmanが2015/02に書いた
  • ガートナーのテクノロジートレンドにも登場

目次

  • 5章
    • モノシックなアプリをマイクロサービスへ
  • 6章
    • デプロイをマイクロサービスへ
  • 7章
    • テスト
    • E2Eテストをどうするか
    • プロバイダが変わった時にどうすれば
  • 8章
    • 監視の話
    • 複数のアプリへ行く時にどうまとめるか
  • 9章
    • セキュリティ
  • 10章
  • 11章
    • スケーリング
    • 障害について
    • 障害を隠蔽して全体のサービスをストップさせない
  • 12章

マイクロサービスの原則

www.slideshare.net

ModelledAroundBusinessDomain

Automation

  • 最初の3ヶ月は2つ、1年で10個、18ヶ月で60個に
  • どんどん自動化対象が増えていく

HideImpression

  • 実装の隠蔽を行おう
    • 悪い例
      • 同じDBにアクセスしてしまう
      • スキーマの変更が複数のサービスに影響を与える
    • 良い例はサービスの連結をする
  • 顧客とか製品とか、コンテキストが違うので、別々に持ちましょう
  • RDBの共有はやめましょう

分散

  • 全てのものを分散させましょう
  • 人々に自由を与えましょう
  • プログラミング言語・開発スタイルなどなど
  • GILT社は横軸が時間軸、リリース回数が右肩上がりであることが分かる

DUMB-PIPE, SMART ENDPOINTS

  • SOAはデータ管理などをパスで賢くする
  • マイクロサービスはMQのみ

Deploy Independently

  • サービスをどのようにデプロイするのか
  • HOSTあたり一つのサービスを進めている
  • サービスが2つあるときに、InventoryサービスからShippingExpectationsに沿って行っているかテストしましょう
  • コンシューマ駆動契約
  • Pact

Consumer First

  • SWAGGERを使ってサービスのドキュメントをAPI化

SERVICE DISCOVERY

  • Hashcorpなどを使おう
  • HumaneRegistry
    • Wikiとかも使って

障害

  • 障害のシナリオ
  • Strangler App
    • レガシーアプリを一気に引退させるのではなく、インターセプトしてあげて行うのがStrangler Pattern
  • リクエストが全部落ちましたとかいう例の話
    • 徐々に速度が遅くなる障害があるアプリで発生
      • スレッドプールが全てそのアプリに
      • クライアントからのリクエストがいっぱい
    • タイムアウト時間を適切にした
    • スレッドプールを各レガシーアプリに持たせる
      • Bulkhead
    • 激しく遅くなるとリクエストしないようにする
    • 時々確認して正常になったらまたリクエストを送るようにする
      • Circuit Breakers

AGGREGATION

  • Elastic serachをする
  • 複数の場所にあったりするのをまとめよう

Azure Service Fabric

  • 今日時点ではプレビュー
  • クラスタ組んでる
  • Stateless and stateful
  • Replicationしつつ
  • 自動的に分散配置してくれる
  • アプリケーションのVersionUpにも使う

ドメイン分析勉強会で学んだこと #NaITE

naite 勉強会 技術

前回に引き続き、ブラックボックステストの話です。

2月20日の土曜日にドメイン分析勉強会がありました。

nagasaki-it-engineers.connpass.com

発表スライド

www.slideshare.net

1問目

f:id:nihonbuson:20160222093047p:plain

http://www.slideshare.net/mhlyc/ss-58471801/37

問題に対する意見

  • 「Lv.20に到達したとき進化する」というのは、Lv21以降は進化しないのか？
    • 「Lv.21以降も進化する」とのこと
    • つまり、「Lv.20以上は進化する」と訂正されました
  • 「Lv.100に到達した後、なつき度が200を超えた時、進化できるのか？
    • 進化しません。あくまでもLv.100に到達した瞬間になつき度が200を超えていたら進化します
      • すると、テスト対象は「Lv.Xの時に進化するかどうか」ではなく「Lv.X-1からLvXに変化した時に進化するかどうか」がテスト内容ではないか。
        • それならば、「X=1」は有効同値クラスではないのではないか。(Lv0からLv1に変化した時はエラーになるはず)
    • 登場する条件に主従関係があるので、デシジョンテーブルでやった方が良いのでは？

自分が解いた図

f:id:nihonbuson:20160222093145j:plain

f:id:nihonbuson:20160222093200j:plain

  • 赤い部分が進化する場所、青い部分がエラーの場所

解いた結果後の疑問

  • X≧1やY≧0の条件は必要ないのでは？
    • 「進化する」というドメインをテストしたい場合には必要が無さそう
      • 「進化しない」というドメインもテストする場合には、図のL字部分（赤でも青でも無い場所）のテストを行う必要がある
  • Lv.101以上やなつき度256以上をテストする必要が無いのでは？
    • 「進化するかどうか」をテストするという目的ならばテストする必要はなく、別の「範囲外はエラーになるかどうか」という目的のテストで行うべきでは。
    • ポケモンを想像するとエラー前提でテストする必要があるように思えるが、最近のスマホゲームとかは最大Lvの引き上げとかがあるので必ずしもエラーではない
  • XとYの両方がONポイント（カド部分）のテストをなぜ行わないのか？
    • そのテストをして期待値通りの結果にならなかった場合、どちらが原因で期待通りにならなかったか分からないため
      • ドメイン分析は、あくまでも対象の直線（もしくは曲線）の式が正しいかどうかを見るために行っている。
      • なので、傾きなどが正しいか他のテストケースで示すことができれば、XとYの両方がONポイントのテストを行う必要がないはず。
    • 理科の実験と同じで、テストしたい部分以外はできるだけ影響を与えない場所(INポイント)を取った方が良い
      • すると、「傾きが正しいことも同時に確かめられるため、INポイントを固定しないほうが良い」という考え方は、失敗の原因を隠すのではないか？
        • あるテストケースが失敗した場合、それがONポイントが原因なのか、INポイントが原因なのか判断つかなくなるのではないか？

2問目

f:id:nihonbuson:20160222093235p:plain

http://www.slideshare.net/mhlyc/ss-58471801/39

自分が解いた図

f:id:nihonbuson:20160222093300j:plain

f:id:nihonbuson:20160222093310j:plain

  • 赤い部分が対象

解いた結果後の疑問

  • X<30はX≦29と書き換えた方が良いのでは？
    • OFFポイントが有効で、ONポイントが無効になってしまうので分かりづらそう
    • ちょうど、 @akiyama924 さんがドメイン分析で似たような話をしていたので聞いてみました

  • どちらが良いのではなく、統一することが大切なのは、まさしくそうだと感じました。

  • 3次元の図を描く必要は無いのでは？

    • 描くことが必須ではない
    • ONポイントやOFFポイントがどこか分かるために描いたりする

演習問題を解き終えた後の意見

  • 今回の例題2つはそもそもドメイン分析で解かないのでは？
    • 1問目はデシジョンテーブル、2問目は境界値分析で十分
    • ドメイン分析を行うのは、4次元以上だったり、2変数以上を組み合わせた条件があった場合
  • テスト設計技法を考える前に、そのテストの目的は何なのか考えることが大切
  • テストケースを具体的に考えることで、そもそもの仕様の不透明部分が分かったりするので、今回のように考えることは実装前のレビューとして有用

終わりに

  • 内容はドメイン分析の勉強会ながら、テスト目的やレビューなどにも話が及んで大変参考になる勉強会でした！

テストエンジニアが普段考えていることと、テストをするということ

技術

先日、面白い話題がtwitter上で繰り広げられていたので載せます。

普段のこんなところから、テストエンジニアは考えを巡らせていると知ってもらえればと。

テストエンジニアの日常

  • こういうドキュメントにも思考を巡らせてしまいます。*1
    • 動くものだけがテストの対象ではありません。

テストをすることへの誤解

「テストをする＝開発物が出来てから初めてテストのことへ頭を巡らせる」と思われていないでしょうか。

少なくとも、周りの開発者は（社内、社外関係なく）そういう思いを持っている人が多かったです。

しかし、JSTQBのシラバスによると、テストの目的として以下の4つが書かれています。

  • 欠陥を摘出する。
  • 対象ソフトウェアの品質レベルが十分であることを確認する。
  • 意志決定のための情報を示す。
  • 欠陥の作りこみを防ぐ。

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14

この記事の最初に書いた内容は、欠陥の作りこみを防ぐことにも繋がると思っています。

「この場合はどういう挙動になるんだろう？(101辛以上はどうなるんだろう？)」という、仕様書には書かれていないことを開発者に伝えることができます。

こんな工数を減らしたい！（無くしたい！）

  • 実装したけど、リリース日前日に大幅な修正が入った
  • 実装したけど、出来たものは利用者のやりたいことと違っていた
  • 実装前に想定できたことを考慮せずに実装してしまった

こんな工数はもったいないです。

これらを実装前に指摘するためにも、テストエンジニアがいると思ってます。

最後にちょっと宣伝

今回の話題として使った同値分割・境界値分析と同じブラックボックステストの設計技法である、ドメイン分析の勉強会が今週土曜日にあります！

興味を持った方は是非参加してみてください！*2

nagasaki-it-engineers.connpass.com

*1:ちなみに自分も、106辛は調べなくて良いのか気になりました。1辛～5辛と6辛～10辛を別クラスとして考えるならば、繰り返しのルールとして捉えると106辛は気になってしまうので。（多分1巡目で1辛～10辛を同値クラスとして再編成するのだとは思いますが）

*2:ちなみに私は運営側に関わっていない、ただの勉強会参加者

組織にテストを書く文化を根付かせる戦略と戦術 #jopf

jopf 勉強会 技術

勉強会告知ページ

connpass.com

発表スライド

www.slideshare.net

発表のねらい

  • 戦略の話と戦術の話

自己紹介

  • 昼はコンサルの仕事をしている
    • いろんな組織にテストの書き方を根付かせるための活動とか

銀の弾丸はない

  • レガシーコード改善に正解はない
  • テスト自動化は銀の弾丸ではない
  • 導入方法にも銀の弾丸はない
  • 導入を目的にしてはならない
  • 状況は現場によって全く異なる
    • 勝ちパターンはだいたいある
  • 「t_wadaが来たから大丈夫だ」ではない

ジェラルド・ワインバーグの影響図

f:id:nihonbuson:20160217215450p:plain

  • ストレスが増えるとテストの回数が減る
  • テストの頻度が減るとストレスが減る
  • どうやってこの無限ループを抜け出すか
    • ノードを増やす？
    • テストではなく自動テストにする＆テストが先に来るようにする

f:id:nihonbuson:20160217215505p:plain

  • テストを書く時間がないのではなく、テストを書かないから時間が無くなるのです by James Grenning

文化を変える

  • 文化はすぐに変わらない
    • 大体2年ぐらいはかかる
  • ソフトウェアプロジェクトの掟「動くコードに触れるな！」に戦う
    • コードは緩やかに死んでいく
    • どうやって動くコードに触れるような仕組みにするのか

イマココから始める

  • ToBeではなくAsIsとNotToBeから始める
    • 「自動化すれば、ChatOpsにできて…」とかではなくもっと現実的なところを考える
  • 現状がどうなっていて、どうなりたいか
    • ヒアリングする
    • 「勘弁して欲しい」ということを裏返すことから始める
  • 期待値のマネージメントをする
  • 人やプロジェクトの速度はそこまで変わらない
  • 日本人を行動させる言葉「まわりはもうみんなやってますよ」は劇薬なので、用法用量を守ること

夢を語りがちになるよねぇ…

それよりもロードマップをきちんと引く方が良いと思ってます

人を知る

  • チームメンバーはストロングポイントが違う
    • 楽しいから頑張る
    • 定時で帰れるから頑張る
    • 自分のコードが綺麗になっていくから頑張る
    • 回帰テストを機械がやってくれるようになるから頑張る
    • コードカバレッジなどのメトリクスの達成感があるから頑張る
    • ビジネス価値が増えるから頑張る
      • 不具合修正ではなく、新しい価値を提供する

変えることの難しさ

  • 人は誰しも変化に対して身構える
  • リファクタリング（振る舞いを変えないままで中身を変えていく）をやろうというとやる気になるが、「今やりましょう」というとなかなかやってくれない（リファクタリングのジレンマ）
    • 「後でやるよ」と言ったりする(TODOタスクになりがち)
      • そしてやらない
    • 部屋の掃除と同じ
    • リファクタリングはお客様に価値を与えないように見えてしまう
      • 実際には中長期的には価値を与えるのだが…
        • ソフトウェアの成長速度が下がっていく
      • ボディブローになる
    • リリース後は、別機能の着手に追いやられる
  • プログラミングの中に混ぜ込まなければならない

変えることの難しさは以前に #cooketn でも松尾さんが伝えてましたね

nihonbuson.hatenadiary.jp

Grace Hopper（COBOLの作成者）の言葉

  • 事前に許可を得るより、後で許してもらう方が楽

すべては変化する。これを受け入れざるをえない

  • 仕様が固まることはない
  • 開発が終わることはない
  • 理解は常に深化する
    • 1年前のコードより今書いたコードの方が技術的にも業務理解的には深いはず

技術的負債の四象限（マーティン・ファウラー）

f:id:nihonbuson:20160217215545p:plain

  • 第四象限に対して、どのようにアプローチしていくか
    • 気付くチャンスを増やす
    • 気付いた時に改善できるようにする

テストは品質を上げない

  • 品質が「わかる」ようになる
  • テストは体重計のようなものである
    • 体重計を買ったって痩せない
    • 体重計に乗っても痩せない
    • 体重計があることで現状が分かる
  • テストを書くだけでは良くはならない
    • 情報が増えても、悪いことが分かるだけ
  • 設計とプログラミングを見直すことで品質を上げる
  • 再設計とリファクタリングをテストで支える

戦術編

  • 全部書こう！→破綻する
  • 改革は小さくかつ最も効果のあるところから
  • 最も困っているところから
    • ECサイトなら決済などのお金＆個人情報
    • お客さんによっては、新機能のところから
    • バグを修正をするところから
      • 欠陥は偏在する
    • 静的解析でピンポイントに
      • 複雑度が高いところから

完全にテスト分析・テスト計画の話ですね

テスト戦術

  • 『リーン開発の現場』に、どこから始めるべきか書いてある

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

  • リスクが高い
    • 例えば管理画面の履歴とかはリスクが低い
  • 手動テストのコストが高い
  • 自動化コストが低い
  • リスクが高くて自動化コストが低いならやってみるべき

誰とやるか

  • 少しずつ広げていく
    • 改善の芽が育つように
    • 親離れできるようにするのがコンサルのゴール
  • 最初はペアプロからやってみる
    • 1人が2人、2人が4人に
  • 最初の1人は若手のエースかベテランから
    • 戦略編の「人と知る」にも繋がる
    • 依頼をくださった人と相談することが多い

こだわるな

  • 最初から全部やろうとしない
    • 何はやって、何をやらない
    • テストを書きながらコード書いて、リファクタリングをやって…とかもこだわらない
      • 慣れが必要だし
      • 「テスト駆動までできてないんですよー」という発言はどうでもよい
  • テスト駆動にこだわるな
  • テストファーストにこだわるな
    • テストの書く順番は最初はこだわらない
    • 慣れてきたらテストの書く時間とコードを書く時間を同じぐらいにしていく
  • ユニットテストにこだわるな
    • ネットワークやデータベースを偽物に置き換えて…とかに拘る必要がない
    • t_wadaさん自身もこだわっていない
  • テストの速さにこだわらない
  • テストの網羅性にこだわらない
    • 最初から「例外系を網羅する」とか考える必要はない

こだわろう

  • 良いユニットテストの指標にも優先度がある
    1. 再現可能であること(Repeatable)
      • Aさんは動くけどBさんのところでは動かない
      • もう一回動かすためにはこのファイルを消して
    2. テストは互いに独立していること(Independent)
      • A→B→Cの順番なら通るが、C→B→Aの順番だと通らないとか
      • 並列で走らせる時にエラーにならないようになっていること

レガシーコード改善ガイドは必ず読むべし

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

  • テストが書かれてないコードはテストが書きにくい
    • テストが書けない構造を変えていく
      • 組み込みソフトウェアの場合は、テストが書けるようになるまで外科手術を行う
    • 外から無理やりテストを書くようにする
      • WEBアプリケーションならば、HTTPのrequest/responseとDBの事前状態と事後状態で抑える
  • 絞込点を探す
  • 仕様化テストを行う
    • 仕様との乖離が起きる
    • 何が正しいか分からない
    • とにかく現状で動いていることを正の状態にする
      • 動きが変わったかどうかだけは分かるはず
    • 十分綺麗になったら、何が正しいか考える

見える化

  • 割れ窓理論
    • NYは治安を上げていくために、割れている窓を綺麗にしていく
    • 汚いものがあると罪悪感がなくなっていく
    • 気付いたところから綺麗にしていく
  • メトリクスを取る
    • カバレッジが低いうちは効果大
    • 変化がすごいあると人間のモチベーションが上がる
  • 小うるさいツールを乗りこなす
    • 大量の出力を出したりする
  • 分母分子を見ないで傾きを見る。

静的解析を使いこなす

  • 動的テストと静的テスト
    • 対象を動かすことによって調べる
    • 対象を動かさずに調べる
      • コード行
      • メソッドごとの行
      • テストは書くだけではない
  • 全体のメトリクスを計測して俯瞰の視点を得る
    • ヒートマップ的な
  • 部分的なメトリクスを計測し続けて傾向を見る
    • リスクインパクトのある決済部分は改善しているなど

コードレビュー

  • コードレビューのインフラに投資する
  • WIP pull request
    • 完成する前から共有する
  • コードを見る文化、見られる文化を育てる

設計の可動域を確保する

  • テストがないのは設計が悪い兆候
    • 今の状態のものにテストを書くと、改善時にテストを書き直すはめになる
  • テストと実装の間に遊びを持たせる
    • 大外からテストの手をのばすとか
      • その代わり、動作は遅いし、データの準備が必要だったりする

背中を見せる

  • サンプルとデモが大事
  • 真似してもらう土台を作る
    • 最初はサンプルのコピペでもOK
    • 架空のプロジェクトでもOK
  • テストのある生活を体験してもらうことが大事
    • その生活を体験するとそこから辞める人はほとんどいない
  • その後にテストのメンテナンスを学ぶ

改革について

  • 自分達から始めてみる
  • できるからやるのではなく、やるからできるようになる

OSS活動の活発さと評価の関係について #jopf

技術 勉強会 jopf

勉強会告知ページ

connpass.com

発表スライド

www.slideshare.net

発表のねらい

  • 個人開発者が現在のOSSの現場でどんなことを考えて、どんな問題が起きているか共有する
  • 社会学っぽい話

OSSと私の関わり

  • power-assert
  • いつものAA
  • ちなみに今日の会場でこのAAは生まれた

2016初頭のOSS風景

  • Social Coding革命
    • GitHub
    • 身分制度の変革
    • GitHub以前は組織が階層構造になっていた
      • メインコミッター
      • コアコミッター
      • コミット権の与えるものと与えられるもの
    • GitHubによって起こったもの
    • プロダクトではなく、コミュニティ

tagomorisさんのお話

tagomoris.hatenablog.com

OSS プロダクトに必要なもの

  • 公開だけでなく、努力とか取り組みとか必要
  • 継続的な開発とメンテナンスが必要

OSSコミュニティを作るために

  • 開発チームがオープンであること
    • 何か問題やエラーレポートをどうするかなどをオフラインで決めているような印象を与えないもの
      • 実際にはやっていなくても、その印象を与えてしまってはいけない
    • コントリビューション手順を示すこと
      • ますはissueに
      • まずはチャットに
  • 企業のサポート
    • メジャーになってきたOSSの場合
    • 業務時間外にやっているイメージがあると思う
      • OSSのプロジェクトが大きくなってきた時に馬力が出なくなる
  • 常に英語を使う
    • 例えばロシア語で書かれていたら引き返すでしょ？
    • OSSの界隈は英語が標準
    • たとえチームが日本人しかいなくても
      • 後々、世界中からのコントリビューションを受け入れるため
    • 日本語で来たissueは即閉じるぐらい
    • 日本語で書かれていると、敷居が高くなる
    • せめてタイトルだけは英語にするとか

どこを見るか

  • OSSは結構見られている
GitHubの画面
  • ライブラリを選ぶ時の基準
  • GitHubをよく見ているのは会場の4割ぐらい
  • Starの数
  • 最終更新日
  • issueがどれぐらい溜まっているか
  • 何回リリースしているか
  • 何人が開発に関わっているか
npmのサイト
  • ダウンロード数
  • 少ないのならば、真面目に品質管理をしてないならば危ないかもしれない
  • 最後のリリース日

バージョン番号の付け方

  • セマンティックバージョニングによる

セマンティック バージョニング 2.0.0

  • major, minor, patch
  • 下位互換性のあるバグ修正はpatchを上げる
  • 下位互換性のある機能追加はminorを上げる
  • 下位互換性のないものはmajorを上げる(バグ修正、機能追加関係なく)
    • 利用者側のコードの修正が必要
    • デフォルトの値の変更
    • コードの廃止
  • 詳しくはcodelunchfmで喋っている

The power-assert Leaves From Moratorium | CodeLunch.fm

  • 作者がルールを守ることで、利用者側の負荷が下がる
  • Version1未満は何をやっても良い状態なので使いづらいと判断する

疑念

t-wada.hatenablog.jp

  • コードを書く人が増えれば増えるほど、ブレるのでは？
  • 機能を落とすとVersionを上げる事になるので、なかなか機能を落とせない
  • ソフトウェアとしてエントロピーが増えて、自重で潰れてしまうのではないか
  • うまく出来たソフトウェアとは
    • 足し算ではなく引き算
    • 単機能である
  • 完成する→rejectしまくる=Noする→活発でないように見えてしまう
    • メンテナンスしてないからではなく、完成しているから
    • しかしサイトを見るとその見分けがつかない
  • 賑やか感を出すとソフトウェアが壊れてしまう

戦略1

  • 動作検証も更新に入るべき
  • 最終更新日も更新される
  • 元旦に年を更新するとか

戦略2最終更新日以外にも診てもらう

  • ダウンロード数が上がっていくとか、それを使うプロジェクト数が増えていくとか

戦略3プラグイン機構

  • バランスを取るために、プラグイン機構を作る
  • コアの設計を守る
  • 貢献している感が増える
  • 自分達の設計が完全に破綻するのを防ぐ
  • 特定のOSだけでしか使わない機能はコアではなくプラグインで
    • メンテするときに実際のOSが無くて困ったり

戦略4適者生存の法則

  • 似たようなソフトウェアが食い荒らす状況になっている
  • 極端に流動性が高い状態になってしまう
  • ロードマップ志向とエコシステム志向
    • 一つ一つのエコシステムが矛盾だらけ
    • ロードマップの場合はど真ん中にいれば良い
    • エコシステムの場合は真ん中から距離を取ってみるべき

「社会問題」たち

  • 伽藍とバザールになった…？
  • 一つ一つの発言が強くなっていることによって問題が発生した

社会問題1. 燃え尽き

  • 一時期から燃え尽きてしまう人が増えていた
  • 作者が提供したくない要望に対してサムズアップ(+1)が膨大に発生し、作者が燃え尽きる
  • GitHubは群衆をマネージメント出来ていない
  • GitHubを止めようとか、issueはRedmineに立てようと考えるプロジェクトが多くなった
  • 公開質問状をGitHubに送った
    • 既存のissueの検索の仕組みがない
    • 毎回Close対応をしなければならない

github.com

  • →「+1が連続して出てこないようにします」という返答が来た
    • それのコメント欄が+1ばかり

github.com

社会問題2. Code of Conduct

  • 行動規範
    • 人種差別、宗教批判をしないなどの当たり前のことを明記しよう
      • 「違反したらこういうルートから報告する」というような細かい取り決めまで。
      • メインコミッターなどでも社会的違反をしたら追放する
  • より多くの人に、未来の人に良くなるように
  • 同意したり同意しなかったりするプロジェクトが現れた
  • 僕らはうまく行っているから書く気は無いよ→「お前らのプロジェクトは反社会的だ」と言われる
    • twitterとかの炎上に似ている
  • 行動規範の議論が一番殺伐している
  • The CoC is not about Social Justice.という条項を入れるまでになっている
  • 今までは「当然人種差別しない」と暗黙的に思っていた

OSSプロジェクトの三要素

  • popular
    • 多くの人に使われる
  • healthy
    • メンテナーがアクティブ
    • コミュニティも活発
  • supported
    • 持続性を満たすために企業などから何らかの支援がある
    • 仕事の一部もしくは全部を開発に回さない限り難しい
    • 企業がhiringする形でサポートしている
      • GoogleやMicrosoftもGitHubに移行してきた
      • メインコミッターの殆どは昼に給料を貰って開発している

まとめ

  • Social Codingは本当に「社会」になりつつある
  • コードを通じて社会に関わりましょう

質問

  • Q.power-assertで求める姿は？
  • A.拡大路線か良識的でありたいと考えるならば、プラグイン構造で考えたい
    • もう完成している
    • どんどん狭めて、関数を1つにしようとしている
    • jsは周りが賑やかなので、それに対応しようとして賑やかになる
    • ただしコアは変わらない
    • 同格のメンテナーにした
      • コアチームが出来たから同格になるわけでなく、結局創設者がリーダーになる
        • 死んだら壊れそう
    • 海外の方が貢献している人が多い

JJUGナイトセミナー『Git入門』に行ってみた＆解決策考えた #JJUG

勉強会 技術

JJUGナイトセミナー『Git入門』に行ってみました。

jjug.doorkeeper.jp

Gitはじめの一歩

スライド

www.slideshare.net

感想

  • イラストが可愛くてすごい分かりやすかったです！
    • このスライドを見るだけで、色々とGitのコマンドがイメージで理解できます

  • 困ったときのコマンドを沢山伝えてくださったので、色んな場面でこのスライドを見直す機会ができると思います

  • 「Gitは歴史」という言葉が印象的でした。

    • ちなみに発表を聞いた直後の自分

  • めっちゃ「Git=歴史」が刷り込まれましたとさ

Git実践入門

スライド

www.slideshare.net

参考記事

syobochim.hatenablog.com

感想

  • 大規模なプロジェクトのGit運営の発表を聞いたことが無かったので、大変参考になりました！

  • 特に業務フローをきちんとしていないと大変なんだなと感じました

懇親会で質問したこと

  • Q 小規模、中規模、大規模ってどのくらいの人数を指していますか？

    • A 小規模は自分が見渡せる程度、中規模は2,3人の信頼できる人に任せてその人達と見渡せる程度、大規模はそれ以上

  • Q どれが一般用語で、どれが業界用語で、どれが独自の用語ですか？

    • A 特に意識はしていなかった。
    • （周りの人と話してて）とりあえず「ライブラリアン」とか「UT」とかは業界用語らしい。

発表中の発言の解決策

「名前のbranchにしちゃう人を止めたい（細かい単位でbranchを作ってほしい）」という悩みに対して（下の画像の赤囲み部分について）

f:id:nihonbuson:20160126004616p:plain http://www.slideshare.net/syobochim/20160128-jjug-nightgit/60 より

  • Gitのフックを使えば良いのでは？

  • 例えば、branch名にチケット番号が入ってないと、pushを自動で拒否することかできると思います！

「ケース2では権限の設定が出来ないから、ケース1のようにメインリポジトリとサイトリポジトリで分けて管理してるので重厚になってしまう」というような発言に対して（下の画像の赤囲み部分について）

f:id:nihonbuson:20160126003056p:plain http://www.slideshare.net/syobochim/20160128-jjug-nightgit/53 より

イベントを参加した全体の感想

  • とっても楽しめた！
  • Gitについてまだまだ知らないやり方がいっぱいありそう！
  • 何がGitとしての言葉なのか、後でちゃんと調べたいと思った