GitHub Universe視聴まとめ
        
      2015年10月1日、2日にSFで行われたGitHub Universeの視聴レポートです。 近場でしたがお金とか時間の問題で参加はしてません。 ustreamのライブで見てたんですが結構途切れたりしたのと、自分の理解が怪しいところがあるのと、興味がないところはあんまりちゃんと書いてないので、メモ書き程度だと思ってもらえればと思います。 ちなみにKeynote以外は3セッション並列だったんですが、ライブで見てたので自分が見たものだけです。 録画もustreamのサイトから見れるのでちゃんと見たい人はそちらへお願いします。
1日目
Keynote by Chris Wanstrath, GitHub(CEO)
- 始まってるのに気づかず最後の方しか見れず。
 - 最後の方はStarCraftの話をしていた。GitHub Pagesで動いてるらしい。
 
Githubのコマーシャルが流れる
- 多分あとでここに上がるはず?
 
Exploring the Solar System from wherever you are! by Joseph Minafra, NASA
- SERVIの紹介
 - 月の形成に関するビデオ紹介
 - 誰でも参加できるようなイベントも開いている。
 - Lunar Mapping and Modeling Portal(LMMP)で月を探索できる。
- RestAPIもある。(NASAは他にも色々APIあるっぽい)
 
 - 月だけじゃなくてVesta(小惑星用?)とか火星用とかもある。
 - 全然githubは出てこなかった。
 
Five years, building a culture, and handing it off by Kellan Elliott-McCrea, former CTO of Etsy
- 中継あったけど別作業のため殆ど聞けず。
 - ソフトを作るのが下手だから頑張らないといけないみたいな話。
 - デプロイするときに現行システムを壊すリスクと自信の話。
- テストとかモニタリングとかして自信を上げていこう。
 - CSSの小さい修正でシステムを破壊したやつがいたりするので、デプロイする修正の規模と比例しないよみたいな。
 
 
Using Git LFS by GitHub/Microsoft/Atlassian
- Speaker(それぞれが順番に話していくスタイル)
- Traci Coffman, GitHub
 - Saeed Noursalehi, Microsoft
 - Rick Olson, GitHub
 - Allen Smith, GitHub
 - Steve Streeting, Atlassian
 
 
Rick from GitHub
- Git LFS(Large File Storage)の概要紹介
- デカいファイルを追加したときにGitレポジトリにはテキストポインタを保存してファイルの実態はLFSに保存するといったことができる。
 - LFS用にいくつかのサブコマンドを追加した
 - Git hookとintegrateされている
 
 - なんでOSS?
- 他の人にも使ってもらって新しいuse caseを知りたいから。
 
 - LFS1.0リリース
- APIを書き換えた
 - インストーラの改善。特にWindows用。aptもある。
 - LFS拡張という仕組みを作った。
 
 
LFSのコマーシャルが流れた。
Steve from Atlassian
- 今までいろんなOSS作ってきたけど、Largeファイルの扱いにはいつも苦戦してきた
 - 自分たち(Atlassian)もGithubも同じことを考えて同じ結論に辿り着いた
- それぞれgit-lfsとgit-lobというものを作ろうと考えた。同じようなコンセプトでいずれもGoで書こうとした。
 - 2015年のはじめにmergeすることを決めてアナウンスした。
 - https://github.com/github/git-lfs
 - https://git-lfs.github.com/
 
 - コマンドの実行例とか機能紹介
- こんな感じでfetchすることもできる
git lfs fetch --include=models --exclude=models/vehicles - ssh apiとかロックといった機能もある
 
 - こんな感じでfetchすることもできる
 
Saeed Noursalehi, Microsoft
- 大きなチームのためにgitをスケールさせることを目標にしている
 - MicrosoftもLFSにcontributeしている。
- NTLMauth to LFS clientとかいろいろ(色々書いてあったけどメモ忘れ)
 
 - VSO使ってzipファイルをLFSのgitレポジトリにpushするデモ
 
Allen Smith, GitHub
- デモ(ちなみにエディタはatom)
- git lfsをインストールする
 - .gitconfigをいじる([filter “lfs”]の下にsmudgeとかcleanとか書いてあったけどよく見えず。。。)
 git lfs track '*.png'とやると対象のファイルをlfsの管理対象にできる- ローカルのファイルはlfsフォルダ以下に保存される
 - lfs用のpre push hookが追加される
 - git-lfs pull
 - github上ではテキストポインタじゃなくてちゃんとファイルが見える。
 
 
CI in world of MicroServices by Surya Gaddipati, Groupon
- 最初はJenkinsのマスター一つだった
 - 今は400ジョブ、18,000ビルド/week
 - 今までCIがダメで辞めた人もいた
- CIがダメだとbad cultureを引き起こす
 
 - 今の仕組みではビルド(デプロイ)ボタンを押したらジョブを設定してパーミッションに応じたsshキーの作成やコードのpush、独立した環境用のマシンの作成などを行い独立した環境でビルドが走る(のを目指している?)
 - UI - CIはキレイで直感的なUIを持つべき。JenkinsのUIは古臭い。
 - Metrics - ビルド、デプロイではどれくらい時間がかかるか等を測って最適化するべき。
 - Extensible - CIはextensibleであるべき。JenkinsはExtensibleという意味では非常に良い。
 - Secure - CIはセキュアであるべき。誰がアクセスできるか、誰がpushできるか、等。
 - DotCiというOSSのCIツールを作った。
- 一言で言うとJenkinsをTraviceCIのようにするもの?
 - JenkinsとGithubとDockerをつなぐ
 - ジョブの設定はバージョン管理できるべき。DotCiもymlで設定できるからバージョン管理できる。
 - ジョブは簡単に並列化できるべき。DotCiでもymlに書くだけで並列化できる。
 - metricsの例としてビルド時間の遷移グラフの紹介。
 - DotCiもExtensible。DotCiのプラグインが書ける。
 - GithubAuthorization。Githubのレポジトリのアクセス権とのマッピングができる。
 
 - スライドが大分崩れてた。
 
Every Company is a Software Company(パネルディスカッション)
- Speaker
- Kakul Srivastava, GitHub
 - Michael Davis, John Deere
 - Dragos Maciuca, Ford
 - Hima Mukkamala, GE
 - Samir Shah, Target
 
 - 自己紹介が終わったタイミングでストリーミング一時停止
 - まとめると
- ソフトウェアはリリースしても終わりじゃないってことを理解しよう
 - いろんなバックグランドの人とコラボすることになるからお互いを理解しよう
 - ツールを使うことになったりしたら教育しよう
 - エンジニアが何かを試したいって言ってきたときに試させてあげるのが大事
 
 
みたいな感じ?
10 ways people are (mis)using GitHub Pages for fun and profit by Ben Balter, GitHub
同じ時間の他のセッションも聞きたかったけどちょうどGitHub Pages使ったばかりだったのでこれを聞くことに。
- GitHubPagesは主に以下の3つのことに使える
- project page
 - personal page
 - organization page
 
 - staticページはHTML,JavaScript,CSSだけで作れる。昔はPHPでやってたようなことがこの3つでできる。
 - WordpressとかDrupalみたいなCMSも流行ったけど、bespoke pageを生成するし、スケールさせようとすると複雑になる。GitHubPagesならGitHubにpushするだけ。
 gh-pagesブランチ切ったり等の作り方の説明- GitHugPagesの10の使い方(例は全部jekyllだった)
- Collaboration - editボタン設置してtypo直してもらったりおかしなところを直してもらうとか
 - CI - html prooferみたいなツール使ってツールでバリデーションもできる。
 - Collections - choosealicense.comみたいなサイトを作れる。
 - Data - アプリで使うjsonファイルとかの置き場にも使える。pushするだけでビルドしなくて良いしお金もかからない。例はU.S. Department of Veterans Affairs
 - Collaborative Policy Making - Project Open Dataとか政府のプロジェクトでも使っている。ポリシーを決める際にgithubを使うことで誰でもissueを上げたり、pull request送ったりできる。(素晴らしいので日本でもやって欲しい。)
 - Branded Profiles - 技術系の会社はtwitterとかsapとかibmとかmicrosoftとかyelpとかいろんな会社が作ってるよって紹介。技術系じゃなくてもcfpbとかも作ってる。
 - private sites - まだパブリックにしたくない場合はprivateにもできる。jekyll-authを使うと簡単にできる。
 - Documentation - github helpはGitHub Pagesで作られているらしい。lunr.js使ってクライアントサイドサーチを使っているらしい。
 - Automated Publishing - 小さいお店とかでもメールを受信してそれをベースにパブリッシュするような仕組みを作ってたりする。やりかたはいくつかある。普通にaddしてcommitしてpullしてやったり、GitHubのCRUD API使ったり(これ?)。
 - Client-side Applications - StarCraftの話をしたかったけど最初にされちゃったので、proseの紹介。GitHub Pages上でファイルの作成・削除・編集とかができるみたい。
 
 
1日目最後のKeynoteはライブ無し
2日目
Keynote by Nicole Sanchez, GitHub and Tiffani Ashley Bell, Detroit Water Project
Tiffani
- Detroit Water Projectの人
 - アメリカでは35,000,000世帯が水道料金等の基本料金を払うことも難しいくらい貧しい。
 - そういった人たちのためにお金を払えたらどうかということを考えた。
 - Twitterで呟いて反応した人たちとGitHub上でプロジェクトを作って、困っている人とドナーをつなぐシステムを作った。自分はエンジニアじゃないけど会ったこともない人とコラボできたのは素晴らしいと感じた。
 - 払えない人はインタビューだけじゃなくて水道会社からスクレイプしたデータを使って本当に困っているか確認しているらしい。
 
Nicole
- refuge restroomという主にtrans gender向けにrest roomを検索できるプロジェクトも同じようなコンセプトでGitHub上で開発されている。
 - connecthome.hud.govという貧困層にブロードバンドをもたらすプロジェクトも同様。
- インターネットにアクセスしないとできないホームワークがあるのにアクセスできない子どもたちがいるのはおかしい
 
 - まだ自分がdevelperじゃないと思ってる層を発見していきたい。次の天才、革命者を発見したい。埋もれた才能を発見するのは我々の責任。
 
chike aguh
- スピーカーに名前がなかったけどeveryoneonの人みたい
 - everyoneonは情報格差をなくすためのプロジェクトでconnecthomeはeveryoneonの一部みたい。
 - インターネットアクセスが無い子どもたちの中には深夜や早朝にマクドナルドの周辺で宿題をやる子供もいる。
 - こういった層をなんとかするのは我々の責任。皆に参加して欲しい。
 
Anil Dash, Founder, makerba.se
- 多くの人は誰がインターネットを作ったのか知らないし、自分が使ってるアプリを誰が作ったのかも知らない。伝えられたストーリーしか知らないから我々は伝えなければならない。 同時に相手にキミは何を作ったのかを聞かなきゃいけない。みたいな抽象的な話。よく分からんかった。。。
 - ここでやってねみたいな。
 
Marianna Tessel, SVP of Engineering, Docker
- コミュニティの話。結論的にはどんなコミュニティでも良いから関わろうみたいな感じ?
 - 途中で出てきた色々な数字
- Dockerイメージのダウンロード数は800,000,000/月
 - Dockerの公開レポジトリは77%が外からのコントリビュート
 - Meetupは60の国で210グループある
 
 
Rethinking Production Monitoring by James Smith, Bugsnag
- 映像切れきれ
 - 技術的負債は返済するのが大変
 - 開発者は40%の時間をバグの原因究明にかけてるという調査がある
 - 以下は良くない
- リリースが最後のプロセスだと思ってしまう
 - ユーザが文句を言うまで待ってしまう
 - 誰も文句を言ってないからOKだと思ってしまう
 - 誰の責任かという問題が欠如してしまっている
 
 - 7つの原理
- ACCEPT - ソフトウェアが出荷後に壊れることを認める
 - AUTOMATE - エラー・不具合を検知できる仕組みを導入しておく
 - AGGREGATE - エラーをただ流れてくるまま見るのではなく、グルーピングしたりする
 - NOTIFY - エラーで逐一メール通知とかじゃなくてグルーピングした単位とかでこのエラーだけ送るみたいなことをしてノイズを減らす
 - PRIORITIZE - 全てのバグを直すことはできない
 - DIAGNOSE - 何が問題かというだけじゃなくて、こうすれば直るみたいなActionableなものにする
 - TEND - 誰も見ないという状態をなくして、誰かがエラーをケアするという状態を当たり前にする
 
 - 実際の例
- failure hooksを使う。言語に組み込まれているようなものがあればそれを使う(JavaのUncaughtExceptionHandlerとか)。なければコードが何分以上かかったら何かをするというような処理で代替するとか。
 - 影響を測定する。それぞれの問題で何人に影響があるか等。
 - 深刻さを測定する。上記と似ているが違うもの。管理画面のエラーなら気にしないとか、paymentのページで出ているなら重要等、セグメントで優先度を付ける。
 - Capture Diagnostic Data。再現可能なデータを取れるようにしておく。いくら使った時に出るかや、どのデバイスで出ているか等。クラッシュ時にそれらのデータを取得できるようにしておく。
 - コラボレーションしやすくしておく。チャット使うとか。チャットに不具合を送る仕組みを入れるとか。
 - 不具合対応の進捗を追跡できるようにしておく。JIRAとかを使って人をアサインしたり。
 - Team Structures。誰もケアしないという状態を作らない。エンジニアのストラクチャを考えなおす。バグはサポートじゃなくてエンジニアがケアする。
 - Create a bug team。バグをケアするチームを作る。一人では無理。もしくはローテーションを組むのも良い。プロダクトの知識が深まる。
 - 誰がそのコードを最後に触ったかを知る。責任を押し付けるためじゃないけど知るのは大事。
 
 
Changing Lives with Open Data by Hidenori Fujimura, Geospatial Information Authority of Japan, Abhi Nemani, Danny Whalen, Remix
Hidenori Fujimura
- 日本人登場。めっちゃ日本人英語で和むw
 - GeoデータをBSDとかCC0のライセンスで提供している
 - これかな?
 - disaster情報の提供
- 御嶽山の噴火時の例
 - 洪水の例
 
 - droneで撮った映像とかも
 - iOS9で動かないのでコントリビューション待ってます的な。
 
Danny from remix
- remixの会社紹介
- transitシステム
 - OpenStreetMapDataとかGTFSとかのOpen Dataを使っている。
 - データとかAPIの観点で考えると乗り物と場所のデータになるけど、15分以上待ちたくないとかユーザ視点で考えるべき。Human Experienceが大事みたいな。
 - 理解が怪しい。。。
 
 
abhi
- 肩書が書かれてなかった。LAの何かの人
 - LAのウェブサイト
- 400くらいのデータセットを提供しているけど誰も使わなかった。
 - Open Dataにしてusefulだと思わせてからは使うようになった。
 - バウンスレートも50%から5%になった。
 
 - 何かのダッシュボード
- GoogleDocsのデータを表示するだけだけど技術を知らない人からしたらこれだけでも有用性が変わるみたいな話
 
 - 犯罪情報は利用できるまで18ヶ月かかるけどこれをもっと早くしたい
 - 理解が怪しい。。。
 
Electron: Desktop Apps with Web Languages by Jessica Lord, GitHub
- Electronの概要
- atomを開発する際に生まれたもの
 - CEF(Chromium Embedded Framework)やNW.js使ったけど合わなかったのでElectronが始まった。
 - ChromiumベースでHTML、CSSの、JavaScriptだけでクロスプラットフォームデスクトップアプリが作れる。
 - node.js使えるからnpmをそのまま使える。ファイルシステムにもアクセスできる。
 - OSのファイルダイアログとかnotificationとかも使える
 - OSの自動更新とかwinインストーラとかにも対応できる
 
 - Electronの中身の紹介
- メインプロセスとサブプロセスでどんな感じで動いてるかのお話。
 - 図無しのテキストだと意味分からないと思うので省略
 
 - 軽いデモ
- npm install -g electron-prebuild
 - electron .
 - 以上、HelloWorldが動いた的な。
 
 - Electron使ってる企業紹介。MSとかSlackもElectronでプロダクトを作っているらしい。
 - Electron使ってるOSSの紹介
 - API1.0を1月に出す予定
- AppStore compatibleにする
 - Windowsサポートの充実
 - ドキュメントの充実
 
 - electron.atom.io見てね。
 
ここでバトンタッチしてJiboの話
スピーカーの名前無いけどこのブログの右の人
- Jiboは世界初のファミリーロボットでありプラットフォームである。
 - Jiboが挨拶するデモ
 - SDKはElectronで作られている
 - JIBOでできること
- スピーチ recognitionとかできる
 - 音がどこから来るか、誰が話しているか分かる
 - Text to Speechもできる
 - エレクトロンでできることは全てできる
 - 自然言語を理解できる
 - タッチセンサーもある
 - 顔の部分にアニメーション表示できる。ウィンクとかもできる。
 
 - 開発のデモ
- 3DのデザインツールみたいなのでGUIで弄ってる *jibo runって打つと実機の顔にアニメーションが流れる
 
 - 価格は750ドル
 
Offline Web Apps on GitHub Pages by Myk Melez, Mozilla
- オフラインアプリとはネットワーク接続して無くても動くアプリ
 - ApplicationCacheがあったけど実装によっては長い間更新されない問題とかが多発してるので廃止することになった
 - ServiceWorkers使ってね
- 別のコンテキスト、別のスレッドで動く
 - ブラウザがサポートしてなければ普通にオンラインで動く
 
 - OGHLINER(オフライナーと読む)を使うとGitHub Pagesでオフラインアプリを簡単に作れる
- オフラインアプリ用にServiceWorkerを作ってくれる
 - デプロイメント - GitHub Pages用にデプロイしてくれる
 - auto deploy via travis - masterにpushしたらデプロイしてくれる(まだ問題があるらしい)
 
 - デモ
- オフライナー自体でgulpを使ってるらしい。
 - oghliner offline distでキャッシュをするファイルを指定する?
 - oghliner deploy distでデプロイする
 
 - カウントダウンするだけのアプリのデモ
- ネットワークをオフにしてタブ閉じたりブラウザ閉じて開いたりしてもカウントダウンを続けてる
 
 - ServiceWorkersの注意
- HTTPSが必要。ローカルにはいらない。
 - backgroundsync、webpushとかにも使える
 - CORS。(の何が注意かよく分からなかった)
 - ServiceWorkerは全てin progress(Firefox)
 
 - mobileでも動くか?
- chromeは動く。FFも動くようになる。safariは知らん。
 
 
Keynote by Marco Annunziata, Chief Economist, GE
- 殆ど聞かず。
 - とりあえずGEデジタルというソフトウェア会社を2011年に始めて250人から2015年には14000人の開発者と30000人のスタッフに成長したって話だけ聞いた。
 
感想
- LFSは専用のコマーシャルが流れたくらいなので今回の一番の売りはLFS1.0のリリースだったみたい?
 - Open Dataのポリシーとか政府系のプロジェクトでもGitHub使って誰でもissue上げたりPR送れたりするのは良さそう。日本でもやって欲しい。
 - 貧困層へのアプローチが必要等、日本の技術系カンファレンスでは出てこない話題があって面白かった。(日本には貧困層が少ないからとか言われそうだけど)
 
かなり適当ですが以上です。