日時：2014/06/01（日）13:30 - 19:30
場所：東京都渋谷区道玄坂一丁目12番1号 サイバーエージェント本社 13F セミナールームA
Togetter：http://togetter.com/li/674634
所感
GitHubを中心として多くのトピックスを聞くことができた。
- GitHubを利用することで生まれる開発プロセスの変革
- ソーシャルコーディングがもたらすエンジニアへの恩恵
- Atomの開発背景とモダンアーキテクチャ思想
- 雑誌の編集・構成にGitHubを利用している
- デザイナーさんもGitを扱っている
- GitHubから生み出す自らのエンジニアとしての市場価値
業務ではまずGitすら利用していないので、世の中との乖離を大きく感じた。
なんとなくでしか知らなかった、「GitHubフロー」を用いることで生まれる効果を少し実感することができた。
プライベートで有志と行なっている開発ではBitBucketを利用しているが、それもやはり「ソースコードを管理」しているだけの運用になっている。
何事も新しいことを導入することは抵抗が多い。ましてやこのようなプロセスに対しては後回し、ないがしろ、現状維持になることが多い。
しかし、地道に少しずつ改善していくための材料をたくさん得られた一日だった。
来年もあるならば、ぜひ参加したい。個人としてはまず草を生やし続けることから始めようと思う。
※草を生やす：GitHubへコミットをしてProfileの「Contributions」に色をつけること。「初耳ｗｗｗｗｗ」ではない。
以下各発表ごとのまとめ。詳細はリンク先のスライド参照のこと。
GitHub 実践入門 Pull Requestによる開発
@hirocasterさん
http://hiroki.jp/githubkaigi
GitHubを使っていない開発でよくある世界
変数名命名付けしたけど、しっくりこない。。
あとで変えればいいや、という「あとで」は一生こない。
GitHubのある開発の世界
githubを使っていれば。。。「しっくりこないことはGitHubに書いておこう」
他の開発者がレビューしてくれる。早くて一瞬、遅くても一日でフィードバックが戻ってくる
数分単位でどんどんコードのブラッシュアップがされていく
これがGitHubの有り無しの差
プルリクエスト（プルリク）を用いた開発
プルリクを行うことで、以下の活動が生まれる
対話ができる。フィードバック、コードレビューができる、テスト、マージ
GitHubを利用することで新たな習慣、機会、品質、心理を得ることができる。
コードを見る・読む・見られる・読まれる習慣ができる。
修正したもらえたり、コードの品質を良くする機会が生まれる。
一番大事なのは心理面。誰にでも見られるという緊張感、他のエンジニアからフィードバックを得られるので、自信もつく。
GitHubを使っているだけではダメ。
使っているだけの人は、GitHubをコードを管理する道具だと思っている。
GitHubを活用している人はコードの価値を高める道具として活用できている。
プルリクを対話、設計、改善するために使っているのが活用している人。ただマージするためだけにプルリク使っていてはだめ。
また、活用している人はコードレビューをする、してもらう習慣ができている。
使っているだけのプルリク
「このメソッド名は抽象的すぎませんか？」のようなコメントだけ。
(他の開発者が見ていない世界よりはマシだけど。。。)
活用しているプルリク
「XXXYYYZZZというメソッド名の方が具体的で良いとおもうのですが？」
「ご指摘のとおりですが、XXXYYYZZZはクラス名が含まれているのでYYYZZZに。。。」
などの対話が生まれていく。
プルリクを通してエンジニア同士の対話ができるようになる。だからGitHubのプルリクタブはConversasionと書いてある
指摘は簡単、提案は難しい。GitHubを活用できるようになろう。
Red Pill or Blue Pill?(映画Matrixより)
赤いピルを飲むと、今までの現実と戦い、真実に向き合わなければいけない。
現実と戦うということ
- 粗悪なコードを直視しなければならない。
- 会社、組織体制、ワークフローを変えることの政治的な戦いが待っている。
- 全員がGitの使い方を学ぶ必要もある。
GitHubを使うことが目的ではない。その先にある品質・効率、価値向上という効果を獲得しなければならない。
はてなブログチームのGithub開発フロー
@shiba_yu36さん
https://speakerdeck.com/shibayu36/hatenaburogutimufalsekai-fa-hurotogithub
はてなブログチームの体制
５エンジニア、２デザイナーでやっている
170プルリク、1300commit、45リリース/月
GitHub Enterpriseを使っている
開発の流れは通常のGitHubフロー準拠。ブランチ運用は３つ。master, develop, feature branch
レビューが完了したフィーチャーブランチをdevlopにマージしていって、溜まってきたらmasterへリリース
タスク管理
- GitHub Issuesをメインにタスク管理に活用。
- 重要なタスクだけカンバンで管理。既存文化との影響を加味してツールを多用しない
- マネージャと開発者双方にとって効率の良いカタチ
Redmineなどと併用すると開発者の効率が下がってしまう。
GitHub Issuesだけではマネージャが俯瞰的にプロジェクトを管理できなかった。
レビュー
- レビュー状態ラベルを導入し、プルリクのレビューステータスを可視化
- レビュータイムを導入し、全員でレビューしプルリクを処理していく雰囲気を作っている。
GitHubのレビューツールは最高。しかし、上記を併用しないとレビュー促進力は少ない。
例：
プルリクの状態がわからなくてレビューをためらってしまう。
ベテランだけがひたすらレビューするはめになってしまう。
リリース
- リリース用（materへのマージ）プルリクにリリース手順書を書いている。
- コマンド一発でリリースできるようにはしている
リリースを自動化できても、マネージャへの確認、リリース前の検証などの部分が自動化できない。
そのため、devlopブランチからmasterへのマージプルリクにリリース内容や作業リスト、検証項目などをまとめている。
このプルリクはコマンド一発で作成できる。
リリース用プルリクを作成するgit-pr-releaseパッケージを作成した。
リリース待ちのissueを集めたり、プルリクに記載する手順書作成のテンプレをまとめている。
https://github.com/motemen/git-pr-release
まとめ
ワークフローは改善しつづけるのが大事
OSSとGitHub
@amatsudaさん
https://speakerdeck.com/a_matsuda/oss-to-github
Rails、Rubyのコミッター。kaminari作成者（使わせてもらってます！！！）
Asakusa.rb主催。
GitHubといえばソーシャルコーディングのプラットフォーム
プログラマにとって一番大事なのは「ソースコード」
GitHubで誰もが読み書きできる場所にあることで、自由を手に入れることができた。
今までのOSSのような「コミット権」という特権もなくなった。
この状況でコミットしていないなんて、参政権使わないようなもん。
GitHubは、コード書いてないくせに声がデカいだけの化けの皮が剥がれるシステム
どんどんコードを書こう。草を生やそう（commitしてContributionsに色をつけよう）
エンジニアはコードの下の平等である。境界はない。
ソーシャルコーディングは人間賛歌ッ！！！
How Github works
@cobyism -san
https://speakerdeck.com/cobyism/how-github-works-github-kaigi-tokyo-2014
GitHubのデザイナー、開発者。GitHubは約60%がリモート勤務。
HAPPINESS comes first
働きたいと思う企業を自分たちで構築する。
働くモチベーションの種類は「外発的意欲（給料とか、物欲）」と「内発的意欲（柔軟性、自主性、透明性）」がある。
幸福への鍵は内発的なモチベーション。
- 柔軟性には信頼が必要。信頼できる人を雇う必要がある。才能が全てではない
- 自分にあった場所で、自分にあった時間で働くべき。あなたの人生に合う時間で働く
- 必要なときに休暇をとる
- 柔軟性は家族を持つ人には最高
- リモートで働くことが最高の経験であるためには発想の転換が必要。中途半端ではできない。
- 全ての企業でリモートがうまくいくわけではない。しかし、リモート作業は未来である。
--
リモートワークで大事なのはツールではなく使用方法。
- 会話をショートカットしようとしないこと。
- 全員がリモートを得意にする必要がある。
- すべてのツールや情報がURLを持つ必要がある。
非同期でも休みはとってもいい
常に良いわけではない。反復が成功への鍵である。
全ては時間で変化していく。常にベストプレイスを探求していく姿勢を保つことが大事！
GitHubで雑誌記事を作る
@inaoさん
http://www.slideshare.net/inao/githubkaigi
GitHubで行う雑誌WEB+DB PRESSの編集・構成方法
- プルリクでTODOやら進捗管理できている。進捗状況が見える化できた。
- ひとつの特集でだいたい500コミットくらい行なっている。SourceTreeだと行単位でコミットできる
- プルリクやIssueで連絡するので、メールも使わなくなった。
- コミットメッセージで編集者、執筆者間で意図が伝えやすくなった。
- 自社でGitLabも用意しているが、膨大なプライベートなリポジトリが必要なので、現状リポジトリは執筆者任せになっている。
WEB+DB PRESSエンジニアのハブの一つでありたいと思っている。
だからみなさん読んでね！書いてね！
Atom
@nathansobo-san
https://www.dropbox.com/s/utaud80bk5egse3/Atom%20%E2%80%93%20GitHub%20Kaigi_jp.pdf
AtomはGitHubより以前から歴史がある。
モダンなEmacsライクなエディタが理想、作成しようと志したのがAtom。
クロスプラットフォームのためにネイティブ層部分をどう作るか？これをHTML5+CSS3ベースで実現した。
DevtoolでJS書いて操作することもできる。CSSなので、configなどもすぐ反映することができる。
プラグイン開発もHTML5+CSS3を扱えるエンジニアならば可能。
Qiita で人気の Git & GitHub ノウハウ（仮）
@yuku_tさん
https://speakerdeck.com/yuku/ru-men-shu-nihazai-tutenai-git-and-github-tips
GitHubのチートシートにも「入門Git」にも載っていなQiitaに投稿されたGitHubのTips。
＃私自身がGit初心者でどれもほとんど使ったことがないので、詳細はスライド参照のこと
Rebuild.fm Live
@Miyagawaさん
http://rebuild.fm/
公開を待ちましょう！
LT
新たなるソーシャルコーディング時代の幕開け
@kenchanさん
https://speakerdeck.com/kenchan/github-kaigi-2014-lt
GitHubを用いることで変わる受託開発の可能性について。
Git・Githubに隠された便利な機能
@sota0805さん
http://qiita.com/sota0805/items/1cf05f2a2be3d6fb3388
知っているとすごーく便利な機能一覧！
GitHub@Ameba (仮）
@pnskさん
- GitHub Enterprise(GHE)導入から1年、Amebaで変わったこと。
- １年間で1000アカウント、1900Repos 360 organizations.
- 導入前はバージョン管理が混在していた。
- 野良バージョン管理がいたるところにあるのは問題
- GHEを導入して構成管理を統一。それに伴い、プルリクなど開発プロセスも変化
- GHEによってエンジニアが働きやすくなった。開発効率も上がった。
- GHE導入後、JIRA、Hipchatの導入がスムーズに。社内プロセス改革が進んでいる
Using GitHub to get a better job
@pwim-san
https://speakerdeck.com/pwim/using-github-to-get-a-better-job
GitHubで市場価値を創造するための使い方という感じ。
GitHubで行うreproducible research
@uriboさん
統計解析、論文執筆にGitHubを用いる。
Hubot レビュアーおみくじ
@sakatamさん
https://speakerdeck.com/sakatam/hubotrebiyuaomikuzi-at-githubkaigi
レビューアをランダムにアサインするためのHUBOTプラグイン
BOTでランダムにアサインすることで属人化、作業負荷の集中、他メンバへ依頼する際の心理的負荷などを避ける
本当は怖くない！デザイナーがGitを大好きになった♡５つの理由（仮）
@yunico-jpさん
https://speakerdeck.com/yunico/20140601-github-kaigi-yunico
http://nanapi.co.jp/blog/2014/04/23/git-love/
デザイナーでもGitを大好きになるためにとった方法、考え方、モチベーションの作り方。
pplog.net の作り方( ˘ω˘)
@taeaさん
https://speakerdeck.com/ken_c_lo/pplog-dot-net-falsezuo-rifang-vov-yuruhuwa-development-on-github
https://pplog.net
違う会社の人たちが集まってチームで開発している。
ポエム駆動開発(PDD)。良いコンセプトがあれば、サービスやチームは自走する！