GitHub Japan Constellation Tokyo 2018 〜Day 1 Community〜 #GitHubSatelliteTokyo
2018/06/12 (火)
11:00 - 20:00 JST
公式サイト：https://githubsatellite.com/
参加申し込み：https://peatix.com/event/366890
ライブストリーミング：https://githubsatellite.com/live-stream/
Twitter HashTag： #GitHubSatelliteTokyo
基調講演：ソフトウェア開発の未来
公家 尊裕 (GitHub) ジェイソン・ワーナー (GitHub)
GitHub サービス開始が2008年、今年でちょうど10年。
GitHubという会社は、コラボレーションとリモートオフィスという考えを大事にしている。全世界に社員がいるが、長い間オフィスはアメリカ１つだった。
2015年、GitHubのアメリカ以外の最初のオフィスができた。場所は、Tokyo。
ソフトウェア開発の未来に貢献していきたい。
今、開発現場で起きていることは？（ジェイソン・ワーナー）
開発者
- 皆様が書いているコードが、今、地球上で大きな原動力となってる。
- ソフトウェア開発者になるのに、今ほどいい環境・状況はない。
より複雑化する開発環境
- 数年前の時点で、平均的な自動車は、1億Stepのコードで動いている。
- 2017年、平均的な開発者は1000以上のクラウドサービスから選定をしている
- 進化は止まらない、追いついていくのは容易なことではない
コミュニティは知識の集合体
私達が最初に作ったもの。
- 信頼性の高いバージョンコントロールシステム、Web経由でアクセス可能なもの。
作ったシステムは、次第にコミュニティを構築していった。
- そしてオープンソースソフトウェアが活発に作られるようになった。
人やデータ、ツール、すべてが繋がっていくことで成長・進化していく。
開発環境の複雑化は止まらない
- アイデア、コード、ビルド、デプロイ
- 無数の意思決定がプロダクト作成までの道のりでは必要。
過去、今日、未来
- 人々が積み上げた試行錯誤を段階的に未来につなげていけるのが、GitHub
ツール・サービスには、あまりにも多くの選択肢が用意されている
- これらをすべて評価してマスターしていくのは不可能
これらの乱立するワークフローを解決するのが、Pull Requestだった。
複雑化する開発環境
- 単純化するプラットフォーム、合理化したソリューションが必要
- ガチガチに固められたソリューション？
より良い開発環境構築のために
開発者感コラボレーションの促進
開発者に必要なのは、より多くコードを書く時間と、ユーザのことを考える時間
新しいテクノロジーは次々と出てくる
ソフトウェア開発が将来どういうかたちになっていくか、は誰もわからない
- どのようになろうと、複雑性を排除してシンプルに開発できる環境を整えることに注力したい
様々な問題を解決するのは開発者の皆様です。
- GitHubはそれを支援します。
日本マイクロソフト株式会社CTO 榊原 彰 氏
設計図共有サイトのファンの皆様、こんにちは（会場爆
すべてがコンピュータ・ソフトウェア産業になっていく。
- それを作り、支えていくのは開発者の皆様です。
マイクロソフトは変わってきた、あなたのお父さんの世代のマイクロソフトとは違います。
- 言っても信じてもらえない人もいる
- 言葉ではなく、行動で示していきます。
GitHubの独立性を保って、すべての開発者が今までどおりGitHubの機能を安心して使っていけるようにする。
- LinkedIn やマインクラフトでも独立性を維持してきた
- これが、我々の今のミッションです。
- これからの我々の行動を見ていただきたい。
empower all developer
- 我々がやりたいこと。
- すべての開発者とともに、未来を作っていきたい。
パネルディスカッション：Rubyが生まれた頃、そしてこれからのRuby
アーロン・パターソン (GitHub) まつもと ゆきひろ (Rubyアソシエーション)
GitHubのソフトウェアエンジニア、アーロン・パターソン
（互いに旧知の仲らしく、2人でのセルフィー撮影に始まり、終始和やかなムードで対談）
あ：GitHubはRubyで書いてあるので、まつもとさんありがとう。
あ：Rubyはいつ生まれた？ ま：1993年です。 あ：どうやって生まれた？ ま：バブル経済が崩壊して景気が悪かった、ソフトウェア会社の社内ツールを開発するチームに在籍していた。そういうツールは売上がたたない。景気が悪いのにそんなことをやってられない、プロジェクトが解散した。社内にはツールのユーザが既にいたので、面倒を見るために残されたエンジニアが2人だけ残った、そのうちの一人。何年もかかって作ったツールを2人ではサポートを回せない。自分で作ったもの以外も多数あったので、基本的にトラブルシュートは「再起動してください」で終わらせていた（笑。上司は兼任で忙しかったが、自分たちには時間があった。誰も管理していない状態、そんな中で作ったのがRuby。 ま：会社で作ったが、著作権の考え方に厳しい時代じゃなかったのと、上司が許してくれたので、退職時に外へ持っていけた。上司が許可してくれなかったら今のRubyはなかった。
ま：GitHubに公開されているRuby/Rubyは、公式のミラーであり、実際はSVNで開発が行われている。 ま：なぜGitHubに移行しないのか？をよく聞かれる。RailsもGitHub。PythonのセントラルリポジトリもGitHub。 ま：RedmineでIssueを管理していて、RedmineとSVNを連携させる作り込みを相当しているので、使い続けるという状態。あと、GitHubサービス自体はOSSではないので、一部のコアなエンジニアが完全オープンなサービスにしかアカウントを作りたがらない、というのもある。そういう人々を離脱させたくない。
あ：まつもとさんがGitHubを初めて使ったのはいつ？ ま：Ruby本体で使えなかったので、アカウントは作ったが、ほとんど使っていなかった。自分用のメールリーダーを自作している、OSSにしていないのでユーザは自分しかいない。それを修正するためだけにPRを3回だけやった。
ま：mRubyは、最近の普通の開発がしたかったので、最初からGitHubにホストしている。やっぱり楽でいい。リポジトリなどを自分で管理するのはよくない、と改めて思った。
あ：Ruby開発のコミュニケーションの問題はあるのか？ ま：Rubyのコアコミッターは100名くらいいる。日本人が半分くらいだが、スーパーアクティブな人が日本人なので、日本人がコミッターであるイメージが強い。 ま：Rubyの開発は、オープンソースだけどクローズドだ、と海外の人で言われた。日本人が日本語でいつの間にか方向を決めてやっている。それ以降、Redmmineにすべて内容をダンプして、公式言語も英語にして、オープンになるよう心がけている。議事録も英語で書いているので、日本語がわからないとRubyができない、という世界にはならないようにしている。
あ：Rubyの未来について ま：頑張って進歩を続けている。RubyやRoRは「ハイプ曲線」を過ぎて、Rubyは死んだ、と言われている（笑 ま：Goなどの静的な型がある言語が持ち上げられてきたので、様々な理由で毎年死んだと言われ続けている（笑 ま：大きなサイトでRubyが使われているのは事実で、そういったサイトをもっと支援したい、と考えている。性能問題が出たときに独自カスタマイズしたRubyを作っている人々が昔はいたが、大体が残っていないと思うし、本来Rubyユーザが汗をかくべきところではないと思っている。 あ：アウトオブバウンズGCの説明。Webサイト利用者にGCによるレスポンス遅延影響を最小化する手法。GitHubで利用することで劇的にUXが改善した。 ま：そういう感じでコアチームの努力によって、Rubyユーザが独自にRubyをパッチしなくてもいいようにするのが責任だと思っている。
あ：プログラミング言語を作るのが好きなまつもとさんの、プログラミング言語のストリームについて教えてください。 ま：言語をデザインする人が、言語をデザインするときにどういう事を考えて設計しているのか、ということが分かるような連載を書いている。そこで作り始めたのがストリーム。まず200行くらいの文法イメージを書いてGitHubにバックアップ目的でアップロードした。特に隠す必要もないと思いパブリックリポジトリにしていたら、次の日に、「まつもとがプログラミング言語を作っている！」というのが見つかって、バズって1000スターくらい一気に行った。。。全然作業途中のものなのに、PRは来るわ、言語のアイコンを作って投げつけられたり、色んなことが起こって、OSS時代の開発は全然違うな、と思った。フリーソフトウェアの時代とは違う。
あ：まつもとさんの開発環境について ま：普段使っているエディタはEmacs。コンパイラーはgcc。 あ：なんでRubyのソースコードの中で同じファイルの中にTabとSpaceが混在しているか？ ま：どっち派の人もコミッタにいるが、最後に触った人の修正した行が、その人の行はその人の流派になる。特に統一しようとしていない。 ま：昔はスペースよりもタブ派だった。データ数が少ないので。最近はスペース派になった。git blame が効かなくなるので、変換するためだけのコミットをしていない。
あ：私は自作キーボードを使っているが、どういうキーボードを使っているか？ ま：Thinkpadのキーボード、マイクロソフトのエルゴノミクスキーボードを使っている。最近はレッツスプリットというキーボードを使っている。タップキーボードを最近買ったが、まだ使いこなせていない。
余談：日本独自文化「笑う」の意味での「草（w）」の話と GitHubの「草（Contribution activity）」の話。（アーロン大爆笑）
所感
話を聞いている雰囲気から、Matzは細かいことを気にしすぎない包容力があるから、Rubyのコミッタを含むコミュニティを「いい感じにゆるく」まとめていけるんだなー
エンジニアにとって窮屈さを感じさせる環境を作らない、というのが非常に感じられる。 でも大事な部分はキッチリ真面目に説明責任を果たすし、Techリードはこうあるべきと感じた。
OpenSTFをオープンした結果
シモ・キンヌネン (Dragon Standard Inc.)
https://github.com/openstf/stf
Co-Founder
- OpenSTFとは？
- 2015年サイバーエージェントがオープンソースした社内プロジェクト
- ブラウザから多数のスマートフォン端末を操作して動作確認ができる
- Control and manage Android devices from your browser.
- 今日は、OpenSTGについては話さない、どのように成長したかを紹介します
- GitHub Starは
- 9345ついた
- 公開後、安心安定の成長
- Fork数、Issue対応数もどんどん増えてる
- PRの数、200弱あった
- 公開前は誰もPRしてくれないのでは、という不安があった
- 公開直後はJumpStartした（知名度が最初にドッと増えた）
- サイバーエージェントというブランドの後押し
- 話題性、日経新聞に載った
- ポイント
- 実際にニーズがあった
- 他のオープンソースのものがなかった
- なぜ成長が進んだか？
- ライセンス：Apache2.0なので、ほぼなんでもできる
- 自然な成長
- インド・中国・ロシアでは意外と人気
- クラウドが安定していない、または信用できない傾向のある国である
- 端末の種類が多い
- 定期的なアップデート
- インド・中国・ロシアでは意外と人気
- 辛くなったこと
- メールボックスの状態が、OpenSTFのメールだけで埋まっている…
- オープンソースのイメージが変わった
- 文化的な違い（サポートの辛さ）
- 他人の時間を大事にしない
- 困ったことがあったら自分で調べるより誰かに聞きたい
- ドキュメンテーションがあっても読まずに直接聞きたい
- （折角用意してある）Issue Template を消す
- 他人の時間を大事にしない
- 言葉の壁
- 何で困っているか、通じないことがある
- 問題を把握するのに非常に時間がかかる
- 詳しい説明がないから何回も同じ情報を聞く必要がある
- Issue Template が理解できない
- 技術の進歩
- 昔、私達しかできなかったことが、新しいAPIのおかげで比較的ラクに
- 他のソリューションもある
- ライセンス
- Apache2.0なので、ほぼなんでもできる
- 私達のものをそのままか、ロゴを変更するだけで売っている会社がある、残念
- 普通に嫌なこと
- 「○○機能ってまだ？」
- 「有料の他のツールでは、それができてるよ？」
- 「じゃ、ほかのものにするよ」
- すべて解決できるわけではない
- 役に立ったこと
- メンバーを増やす
- 昔は厳しかったが今は２〜３回目のPRでPushを許可する（権限を付与して正式なContributorに）
- 最初は怖いかもしれないがGitなのでかなり安定する
- （いざとなれば force push で履歴改変）
- Issue Template をできるだけ短くする
- 何が起きた・何をした・ログの有無
- 考えすぎて無駄に長くすると誰も入力してくれない
- スクロールすると読んでくれない
- もちろんCIを設定する
- （ビルドが落ちても直さない人がいるけど・・）
- Issue が来たら、すぐに対応にかかる時間を判断する
- 3分以下なら、すぐ返事してクローズする
- それ以上なら、あとにする
- CHANGELOG.md をちゃんと管理する
- 何がいつ変わったか簡単に分かるから無駄に聞かれない
- リリースノートでそのまま使える
- 無駄な約束をしない
- 「それ、いつかやるつもり」と言ったら無駄に期待されるので、興味・時間がなかったらハッキリ言おう
- ビジネスをやるつもりがなくてもサポートの値段ぐらいはちゃんと準備しよう
- 高めにすると面倒くさい要求が簡単に回避できる
- メンバーを増やす
- 良かったこと
- 普通より面白い仕事をチャレンジできた
- いいエンジニアと連携できると最高
- いろいろなイベントに招待された
- LA、ロシア、中国など
- 「タイに来てうちの経費で○○機能を作って」という依頼も
- いろいろな会社と連携できた
- 恐ろしいスケールのデバイスラボも見せてくれた
- 仕事にもなった
- たくさんの端末と遊ぶことができて楽しかった
所感
オープンソースプロダクトを扱う身の 生々しい苦労話とやりがいの話。
Matzのストリーム話との共通点は、オープンにすることで多くのフィードバックが生まれプロダクトの成長が加速した、という点かと。
Microservices in ABEJA Platform - 集約と分散のサービス設計
石川 尊教 (株式会社ABEJA)
我々がどのようにマイクロサービスを開発＆運用しているか？
- 3 Topics
- About us
- Technology
- Culture
About us
- Deep Learning のGoogleトレンド紹介
- 2012年付近から、急激に右肩上がり
- 2012年 ImageNet Challenge 2012
- インターネット上にある画像を分類・画像認識をするコンテスト
- 毎年開催されていたが、2012年にブレイクスルーが発生
- Deep Learningモデルが従来の統計的モデルを圧倒
- 認識エラー率は年々低下している
- Abejaも2012年創業
ニューラルネットワークの簡単な説明
- （「ゼロから作るDeep Learning」）
- Data collection
- Annotation
- Training
- Inference
- Re-Training
- に戻る
Abeja は創業6年
Technology
Microservicesとモノリシックサービスの連携
- 30を超えるリポジトリ
- 5つの開発言語
- サービス間は gRPC で通信
- なぜ10名程度の会社でマイクロサービス化を進めたか？
- Complexity（複雑性）
- スケーラビリティが求められる機能
- UI/UXが求められる機能が
- 並列実行のバックグラウンド機能
- Motivation（）
- 開発者は顧客にサービスを届けるのが使命
- 開発者は新しい技術を使いたい、使う機会を得たい
- Microserviceであれば、新しい技術の採用ハードルが低くできる
- No Rules
- 世の中で定められているレベルの最低限のルールを守っているだけで、社内の独自縛りはない
- Complexity（複雑性）
- ARMSの紹介
- モノリシックなGatewayサービスがバックエンドのマイクロサービスのドメインの管理しやすさを後押ししている
- 中央集権的に実現したい機能はここに実装する
Culture
Diversity
- 英語を公用言語としているが、日本語ベースのトレーニングも用意
- Self Starter
- 待ち、ではなく、能動的なキャッチアップと貢献を推奨
- LEAN & Flow
- Waffleをつかったカンバンで朝会を実施
- リモートオンライン会議はZoom
- LEAN開発
- 毎朝のミーティングでカンバンを見ながら同期
- 自分のスキルと興味に応じてタスクを
- 壁の一部がホワイトボードになっていて、すぐに会議が始められる
マイクロサービスアーキテクチャを採用して良かった点
- プラットフォームの構築に向いていた
- 複雑とはいえ、各サービスの役割が明確
- 今のフラットな組織に合っている
- メンバーが固定化されづらい
- 新規メンバーが参入しやすい
- 興味のある言語や分野から入っていける
各サービスをつなぐ中心になるもの、（ARMS）を用意することをオススメする。
GitHub LT大会 ~ 事件は現場で起きている!?
モデレーター 鈴木 順子 (GitHub) アーロン・パターソン (GitHub)
36名の応募者、7名が選ばれた。
GitHubでポータルサイト ドキュメントを運営して幸せになる話
NTT.com 岩瀬ヨシマサさん
https://www.slideshare.net/iwashi86/github-102233959
- GitHub Pages
- GitHub Pagesを使うモチベーション？
GitHub as an Authenticator
Wantedlyオオツボシンペイさん
- 情報共有
- 社員名簿
- 権限管理
- GitHub を使って法務コミュニケーションのスピードを2倍にした話
- 組織上のチームとGitHub上のTeamが対応
- 複数チームの兼務も表現できる
GitHub Teamをベースに認可
- HRのフローに乗るだけで良い
- JOINしたときにTeamに所属させるだけ
- 権限の外し忘れがない
- Orgから外せばすべての権限がrevokeできる
- 特定Teamに入っているとプロダクションへのSSHを許可
- Webhook Token Authentication on kubernetes で
- Teamごとに異なるk8sの操作を許可する
- HRのフローに乗るだけで良い
Summary
- 社員全員をGitHubに入れる
- 組織に合わせてTeamを作成
- Teamに準じて認可する仕組みを
Githubをどうやって初心者に教えるか
湊川あい @llminatoll
「マンガでわかるGit」の著者
http://webdesign-manga.com/git01/
https://www.amazon.co.jp/dp/4863542178
- 土日にブログで書いたGitに関する初心者エントリーがメディアに取り上げられて書籍化
- git教え方いろいろ
- 口頭
- ドキュメントを紹介する
- 聞かれるたびに手を止めて対応
- 「なんかおかしくなっちゃいましたー」
- Gitを教えるのは大変！
- なぜ？
- 初心者にとってGit用語は異国の言葉に聞こえる
- まずは用語を１つ１つ説明していく
- それでもなかなか覚えてもらえない
- ビジュアル化すると理解が早まる！
- 人の脳が見たものを理解するのにかかる →0.1秒
- 脳の50%は視覚関係に使われている
- 文章＋絵だと認識率が圧倒的に高い、という研究結果
- ＋漫画だと
- 時間軸
- 状況
- 登場人物の心理
- を表現できる（私が漫画という手法を選択している理由）
- 漫画でリポジトリを説明してみる
- フォークとクローンを説明してみる
- まとめ
- 学習コストが高いと言われるgit
- ビジュアル化されていれば短時間で理解できる
所感
そういえば、gitの社内説明で絵を何枚も書いたなぁ。
git説明に限らず、ビジュアル化は本当に大事。
GitHubを導入したいとき、どう説得するか
Yahoo! タナカマサユキ
- GitHub使っていて当たり前？
- 導入に向けｍ社内を説得するために戦っている人もいるはず
- 導入の壁いろいろ
- 重要な関係者がGitHubを理解できていない
- うまく説明できない
- GitHubってなに？を改めて考えてみる
- 機能がいろいろある
- Yahoo!のアプリ開発環境で考えてみる
- 「開発業務の起点」
- 開発の中心にいる
- 向き合っている課題
- 大事なのは、導入するサービスを理解し、腹落ちさせること
技術系同人誌執筆のすすめ
イマイケンタさん ＠Henteko07
- I love Developer Tools
- 同人誌は早く出版できて楽しい
- GitHubを使うと複数名の執筆でもうまく書ける
- 商業誌は出版に14ヶ月かかった（経験談）
- 同人誌だと2ヶ月程度でOK
- デメリ：リーチできる人が限られる
- 同人誌は自由（Freedom）
- なにものにも縛られない自由
- GitHub上でどうやって同人誌を作るか？
- ツライ点
- たくさんの画像を扱う書籍
- 画像管理がワケわからなくなる
- デザイン系の本であれば、GoogleDrive＋GoogleDocumentを使ってる
- たくさんの画像を扱う書籍
Mixiにおける技術競技イベント「git challenge」の裏側
Mixi：サトウリョウスケさん
- git challenge？
- 学生を対象としたgitを題材にした競技
- すでに8回開催、のべ168名参加
- どんな問題？
- チュートリアルをみんなで解く
Start OSS Contribution with you know
シバヤマリョウさん @serima
自分にできることからOSSコントリビュートしてみよう
- 初めてのコントリビュート
- CircleCIが1.0→2.0に（2018.8末で完全移行）
- OSSは継続的に開発されることが重要
- コントリビュートしたいな、と思うものがあれば気軽に参加すればいい
- 自分にできることを探す
- Issueを探す（Help wantedラベルは比較的難易度が低い？）
- ソーシャルコーディングを楽しみましょう♪
会場風景
入り口
GitHubグッズショップ
会場案内
GH Satellite : real-time contribution visualizer
Ask GitHubコーナー
CircleCIコーナー
講演会場ではテクノサウンドが流れる
戦利品
