GitHubKaigiに参加してきました。#githubkaigi

Git 勉強会

去る2014/06/01（日）にGitHubKaigiに参加してきました。
貰ったもの↓ステッカーが嬉しい！

私は申し込み開始2日目位？に申し込んだのですが、既に250人待ちとかいうことになっていたので期待していなかったのですが、
会場を大きくしてくれたのか開催前々日位に参加できることになりました。（それでも350人位はキャンセル待ちがいました。。。）

私自身はそれほどGitHubを使いこなしている訳ではないので、勉強のために参加！

詳細とか

参考URL

私が学んだこと

どちらかというと既に使っている人向けのセッションが多かったので簡単にまとめます。
↑の資料のとこでも書きましたが、私は普段GitHubをそれほど使っていないので「Github実践入門 ─ Pull Request による開発の変革」が一番勉強になったので、この辺りの内容が響いた。
GitHubKaigi Keynote - Speaker Deck

  • Pull Requestがあると、ちょっとした事を話しあえたりする。
    • ロジック、クラスやメソッド分割、変数名など
    • レビューが積極的に行われ、根付いていく

この辺がPull Requestがあるなしでの違い。

  • 習慣
    • 見る、読む、見られる、読まれる
  • 機械
    • 修正、拡張、学習
  • 品質
    • 2eye、over 4 eyes
  • 心理
    • 不安、安心、自信
  • GitHubはコード書いてないくせに声がデカイ人の化けの皮がはがれるシステム
  • Atom（GitHub製エディタ）はWindows対応は多分ずっと先。。。

以下メモ

Hello, Github Kaigi

  • GHEが21%
  • private repositoryは26%
    • 結構少ない
  • PRを受け取ったことがある人
    • 38%
  • PRを送ったことがある人
    • 57%
  • 会社でGithubを使って開発している人
    • 50%位
  • 会社でissueを使ってチケット管理している人
    • 10%位？結構少ない

Github実践入門 ─ Pull Request による開発の変革 (仮)

  • @HIROCASTER
  • 毎日github使ってる人
    • 8割〜9割
  • 今日の話は三本立て
    • Githubを利用していた開発の世界を知る
    • Githubを（利用:活用）する違いを知る
    • GitHub実践入門はガイドブック
Githubを利用していた開発の世界を知る
  • 業務とかである場合とない場合
  • GitHubの世界へようこそ
  • Pull request
    • PR プルリ プルリク
  • よくあるせかい
    • しっくりこないけどなんとなく変数名をつける
    • 後で適切な名前を思いついたら変更しよう
    • 「後で」は一生こない！！
  • githubだとpushの際のコメントに書いておく
    • 他の開発者がレビュー
    • 良い変数名 + α をフィードバック
    • コードに反映
  • 2つの世界の差
  • 習慣
    • 見る、読む、見られる、読まれる
  • 機会
    • 修正、拡張、学習
  • 品質
    • 2eye、over 4 eyes
  • 心理
    • 不安、安心、自信
  • GitHubを使っている世界の中にも差がある。
  • 使っているだけの人、活用している人の差。
    • コードを管理する道具
    • コードの価値を高める道具
  • 活用している人になる
  • 使っているだけのPR
    • このメソッド名は抽象的すぎませんか？
    • このようなコメントだけ
  • 活用している人
    • このメソッド名は処理している内容に対して抽象的すぎませんか？
    • ○○××という名前のほうが具体的で良いと思うのですが。
    • なるほど、○○はクラスに付いているから××とかどうでしょ。
    • なるほど××でもいいですね！
  • っというように、対話して欲しい。
  • 指摘=簡単
  • 提案=難しい
  • 「なんだよこのコード！」というのはコードを理解してなくても書けなくても言える
  • コードをレビューする（ことになる）
    • 行動を起こすキッカケを作ることができる

  • 粗悪なコード
  • 会社や組織の耐性、
  • 現実と戦うワークフロー
  • コストのお話
  • GitHubを使うために学ぶことは多い
  • gitの操作、ブランチの概念
  • コミットメッセージだとかだとか。。。
  • 参考資料
    • YAPC::ASIA Tokyo 2013 2日目
    • GitHubでつくる、楽しい開発現場
    • 「GitHub実践入門」→ コレ読んでメソッド
      • 仕事でプルリク開発しましょう〜て時々あるけど、これ読んどけでOK
まとめ
  • GitHub != 目的
    • GitHubの先にあるものを獲得しなければならない
    • 開発効率？品質？
    • ビジネスの成功？ソフトウェア価値の向上？

はてなブログの開発フローと Github

開発の流れ
  • タスク管理
  • REDMEINE
    • メインの時代
    • タスクはREDMINE
    • pullrequest はGithub
    • 開発者が両ツール見る必要がある
    • 開発者の効率が上がらない
  • GitHub
    • Issuesのみの時代
    • ツールを一つに
    • タスク管理はissuesのみ
    • コードレビューはpullrequest
    • 効率アップ
  • 問題発生
    • チームの重要なものは何？
    • issuesには優先度・締め切りの仕組みは少ない
  • 今誰が何をやってるの？
    • issuesでは進行中のタスクを俯瞰できない
  • 開発者の効率は良い
  • マネージャがチームの俯瞰を出来ない
  • issuesメインに開発者効率は保つ
  • カンバン
  • issuesの役割
    • すべてのタスクはここに入っている
    • だれでも追加OK
    • 追加されたタスクは毎朝検討
  • カンバンの役割
    • issuesの中で重要なものだけ
    • マネージャが選択
    • 重要なものしか追加しない
    • 朝会しかみない
  • Githubとタスク管理
    • 開発者にとって一番効率のよいIssuesをメイン
    • ホワイトボードで重要なものを管理
    • スクラムまでいかないゆるいタスク管理
  • レビュー
    • PRしたけど、担当者は決まっていなかった。
  • 問題発生
  • PRの状態が分からない（のでレビューをためらう）
    • レビュー依頼中？
    • レビュー一度して修正中？
    • レビューもう終わってる？
  • レビューが消化されず、PRが凄い量に。
  • ベテランだけがひたすらレビューし続けるはめに。
  • ○GitHubのレビューツールは最高
  • ×しかし促進は少ない。
  • 解決案
    • レビュー状態をはっきり
    • レビュー依頼一覧をわかりやすく
  • 解決案として2つ導入
    • レビュー状態ラベル
      • issuesにラベルを貼り付ける
  • レビュータイム
    • 14時になったらBOTにレビュー依頼件数を知らせる。
    • レビュー依頼を消化する
  • リリース
    • GitHubとリリース
    • マネージャに確認
  • マネージャ確認せずにリリースしてしまった
    • 自動化しきれない部分でミス
  • 自動化しきれない部分を教えないと新人がリリースできない
  • リリース用PRにまとめる
  • 独自に作業手順書のテンプレートを作れる
  • git-pr-release
まとめ

ワークフローは改善し続けることが大事

OSS と GitHub (仮)

  • @amatsuda
  • github
  • sicuak coding
  • Social Coding 3部作
  • Social Codingではみんながコミット権をもっている。
  • 参政権をもらってるのに、選挙に行かないようなもの
本番
  • OSS and me
    • 職業プログラマ
    • 自分の仕事上の問題を解決する手段
    • 他人の問題を解決するOSS活動

web+db vol.50特集2の神Git記事なるものがある

  • GitHubでぷるり
    • コミッターの誰かがレビュー
    • コミッターの誰かがマージ
  • pull requestを積極的に歓迎
    • 射幸心を煽る
まとめ
  • ドキュメントがとても重要
  • コミットキレイに
  • 名前重要
  • GitHubで人のつながりを
  • フォローするだけじゃなくて、実際にあってみよう
  • アイコンは、画像と本人が一致するものが望ましい
  • とにかくコードを書こう
  • 毎日コードを書こう
  • なんでもいいからコードを書こう
  • 草をいっぱい生やそう
  • GitHubはコード書いてないくせに声がデカイ人の化けの皮がはがれるシステム
  • コードの下の平等
  • 必要なのは一歩を踏み出す勇気
  • ソーシャルコーディングは人間賛歌

How Github Works

  • GitHubの人がどうやってGitHubを作っているか
  • スライドに日本語で字幕を入れてもらっている。
  • 60%の人がリモートで働く社員。
  • リモートがデフォルト
  • 全てがURLを持つ必要がある。
  • 人間のような言葉で話す。
  • 絵文字は素晴らしい。
  • リモートでやるからこそコミュニケーションコストは低くならない。

※英語のセッションだったので、内容を追うことに精一杯でメモできず。。。
※Tweetを見てると、リモートで働くということに対してかなりいいセッションだったらしい。

Githubで雑誌記事を作る

  • どのように作っているのか
  • GitHubで原稿管理とやりとり
  • md2inaoというやつで変換している。
  • MarkdownからIndesignタグに変換している？
  • 雑誌・書籍作りは、ソフトウェア開発に近づけたほうがうまくいく
    • 著者さんの普段のワークフローに近い
    • 書籍もソフトウェアだから

Atom, the Programmable Text Editor

Qiita で人気の Git & GitHub ノウハウ（仮）

  • タイトルちょっと違うらしい
  • Qiitaの中の人
  • GitのTipsらしい。

中身は普段からGit使っていないとほぼ理解できず。。。
資料公開されるのでそこを見たほうがいい感じ。
また、資料自体は結構簡単に書いているので、Qiitaの該当記事へのリンクもある。

Rebuild.fm Live

  • Rebuild.fm
  • 週1位でやっているpodcastの番組
  • pull request駆動開発のお話。
  • podcastで公開されています。
  • モバイルとWebは同じ感じのbranch戦略にするのは難しい
  • 製品のライフサイクルとかによって変わるのでbranch戦略は一般解はない
  • GitHubが落ちてるとデプロイ出来ない問題。
    • ちゃんとした会社はGitHuub落ちた時に何とかする手段を用意している
  • Sqwiggleの話。

LT

メモなし。