GitHub Kaigiに参加してきました! #githubkaigi

概要

GitHub KaigiはGitHub User Group主催のイベント。
募集開始時には、500人定員であっという間に埋まった中、なんとか参加できました。
http://githubkaigi.org/
http://githubkaigi.doorkeeper.jp/events/11081

タイムテーブル

1:30 to 1:40 @naoya Hello, Github Kaigi
1:40 to 2:10 @hirocaster Github実践入門 ─ Pull Request による開発の変革 (仮)
2:15 to 2:45 @shibayu36 はてなブログの開発フローと Github (仮)
2:50 to 3:20 @amatsuda OSSGitHub (仮)
3:25 to 4:05 @cobyism How Github Works
4:05 to 4:35 おやつ休憩
4:35 to 4:55 @inao Githubで雑誌記事を作る (仮)
5:00 to 5:30 @nathansobo Atom, the Programmable Text Editor
5:35 to 6:05 @yuku-t Qiita で人気の Git & GitHub ノウハウ(仮)
6:10 to 7:00 @miyagawa Rebuild.fm Live
7:05 to 7:45 LT x 8
7:45 to 7:50 kanpai

詳細

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

Speaker : @hirocaster さん

mixi, github, ruby, server-side, agile

Presentation document

Note

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

Speaker : @shiba_yu36 さん

はてなブログチームのエンジニア

Presentation document

Note
  • チームは、5人エンジニア、2人デザイナー
  • ブランチ運用の活用方法:master, develop, feature branch1,2...
  • GitHub タスク管理.
    • Before: Redmineでタスク管理。GitHubでレビュー目的。両ツールを見なきゃいけなくて面倒。
    • After: GitHubのIssues/PullRequest に統合。開発者/効率アップ。
    • その後の課題:チームの重要度がわからない。優先度/締め切り/アサインが不明瞭。
    • 解決策:GitHub x カンバン(重要なものをピックアップ)
    • マネージャー :朝会 x カンバン / 開発者:朝会 x GitHub/Issues
  • pull request
    • 課題:pull requestのレビューのフローと促進/ステータス管理がまだまだな状態に。
    • 解決策:レビュー状態ラベル/レビュー依頼,レビュー中,レビュー完了 、レビュータイム(IRCbotで告知する)を明示的に導入。
  • リリース
    • リリース全ては全部自動化できてない。リリースチェック用のテンプレートを導入。
    • git-pr-release を作っている。

OSSGitHub (仮)

Speaker : @amatsuda さん

Rails, Ruby, kaminari => 4000 stars 越えました!

Presentation document

Note
  • ソーシャルコーディングの世界
    • プログラマーにとって一番大事なものを共有するプラットフォームができた。
    • コミッターじゃなくても今はだれでもコミットできる世界。
  • OSS and me
    • 自分の仕事上の問題を解決する手段
    • しょうがないから直しているの延長線上の話。
  • WEB + DB Vol.50 特集2 / 神Git エントリが。
  • rubyプラグイン
  • RailsGithub
    • 唯一の神は、DHH
    • コミットを良しとするためのとりくみ。公式URLでコミット貢献度のランキングを導入している。
    • Rails Contributors - All time
  • Ruby
    • 唯一の神は、Matz
    • なぜGHに移行しないのか? 自由なswの開発プロセスが特定企業のプロダクトに依存するのは。
    • Railsの文化とは逆。コミットは少なめ。
    • リアルなコミュニティ:asakusa.rb
  • kaminari
    • GitHub上のコミュニティ活動、リアル上のコミュニティ活動は、両軸でやり続けていきたい。
    • GitHubで会って、実際に本人とFaceToFaceで話しているときが楽しい。
    • ドキュメントをちゃんとして、みんなから読んでもらえるようにするのが、とても重要。
    • アイコンは、画像と本人が一致するのが望ましい。
  • とにかくcodeを書くしかない。
    • プレゼンスをあげるためには。草をいっぱい生やすしかない。あちら側とこちら側の境目がない世界。
  • ソーシャルコードは人間賛歌。人間讃歌は“勇気”の讃歌ッ!!

How Github Works

Speaker : @cobism さん

GitHub, Inc.
coby@github.com

Presentation document

Note
  • 自発性、透明性、柔軟性
  • リモートがデフォルト
    • デフォルトだからこそリモートが最も良い状態であるべき
    • sync <=> async
    • informal <=> formal
    • いくつかのツールを使うことで解決する.例えば、Chat
  • Hubot
    • Hubotを経由して、Deploy, CI/Builds
    • ChatOpsが別チームでワークしている
    • 会話の中心にツールをもってワークするようにする。
  • とはいえ直接会うことが大事。
    • Summits(全員あつまった会議)
    • Product minisummits / Team minisummits / Onboarding
    • 信頼関係を。
    • Video Chats.
    • 会話でのショートカットは利用しないようにしてほしい。
    • リモートを得意にするためにも。
    • Everything should have an URL.
    • あなたの言葉を人間の言葉のように話す
    • その上で絵文字は、とても素晴らしい!
  • Be patient.
  • Iteration is always the keys.
  • 組織の人の数でどんどんやりかたは異なってく。

Githubで雑誌記事を作る (仮)

Speaker : @inao さん

WEB+DB Press 編集長

Note
  • md2inaoは、md2indesign
  • Adobe InDesign
  • GitHubで何が変わったか?
    • 進捗状況が、見える化された
    • メール使わずにIssue /Pull Requestによりメールを使わなくなった
  • Git / GitHubの習得
    • 「はじめてのGit」特集Vol.50
    • 知りたければ書いてもらえればいいじゃないメソッド
  • 注意点
    • GitHub プライベートリポジトリは用意いただく必要がある
    • あくまで私の場合のお話、人によって抵抗ある人もいる。
  • ぜひ読む人、か、書く人になってほしい

Atom, the Programmable Text Editor

Speaker : @nathansobo さん

atom developer
nathansobo (Nathan Sobo) · GitHub

Presentation document

https://www.dropbox.com/s/utaud80bk5egse3/Atom%20%E2%80%93%20GitHub%20Kaigi_jp.pdf
※公開されたら、差し替える

Note

入門書には載ってないGit & GitHub Tips ( Qiita で人気の Git & GitHub ノウハウ(仮))

Speaker : @yuku-t さん

CTO @ Increments

Presentation document

Note
  • Qiitaに載っていた、GitHub Cheat Sheetにも載ってない、入門Gitにも載っていないTipsの紹介
    • git diff-highlight は、知らないと損している.
    • そもそもgit fsckとは?
    • GitHutとReviewの話
      • hub browse :
      • hub pull-request : current branchをプルリクエストしてくれる
    • git rebase -i --autosquash
      • fixupとautosquashの違い
      • fixup : コミットメッセージを修正しない。
      • autosquash コミットメッセージを修正できる
    • レビューはローカルで(個人的にはですが)
      • GitHubのWebViewが遅いから。
      • 個人的にはtig推し。
  • 開発 & レビュー 状況のデモ

Rebuild.fm Live

Speaker : @miyagawa さん、@naoya_ito さん

http://rebuild.fm/

Note

LT x 8

  1. @kenchan 新たなるソーシャルコーディング時代の幕開け => Idobata の紹介。
  2. @sota0805 Git・Githubに隠された便利な機能 => GitHubチートシートのオススメの紹介。
  3. @pnsk GitHub@Ameba (仮) => schacon/git-media · GitHub に期待 ! もう巨大なデータをgitignoreしなくていい! ~git-mediaの使い方~ - 3度の飯と最新技術
  4. @pwim Using GitHub to get a better job
  5. @uribo GitHubで行うreproducible research => 再現可能な研究では、objectivity,clearly,properlyでは重要視している。Ten Simple Rules for Effective Computational Research。
  6. @sakatam Hubot レビュアーおみくじ => 開発体制をスケールするためにコードレビューを必須に。コードの属人化が課題に。ランダムにアサインできない。Hubotのおみくじでやらされ感を緩和。
  7. @yunico-jp 本当は怖くない!デザイナーがGitを大好きになった♡5つの理由(仮)=> デザイナー視点でgitでやっていることを理解デキるまでの話。苦手意識がなくなることでなくなる。本当は怖くない!デザイナーがGitを大好きになった♡5つの理由 | nanapi TechBlog
  8. @taea pplog.net の作り方( ˘ω˘) => pplog - ゆるふわインターネットにポエムを刻もう。ゆるふわチーム開発について。

kanpai(beerbash)

Beerbashをピザを囲んでビールを。ピザは一瞬ではけました( ˘ω˘)
GitHub, Incの方やSpeakerの方たちと導入/導入後の話できてよかった。

まとめ

  • 今回のイベントを開催してくださったGithub会議スタッフの方々ありがとうございました!
  • GitHubのポロシャツほしかったw
  • 目的忘れずに現場にGitHubを入れる方向にもっていきたい。それで現場で既に導入している人たちの課題を踏まえて、導入段階〜充分に活用できている段階までこの半期中になんとかしたい。
  • GitHubでコード書く習慣つけなきゃなと。草を生やさねばといい意味での危機感持てたのでコード触る時間を意図的に作る。
  • 現場のチームのベストなやり方は、それぞれ違うので改善は常につづけていきたい。改善促進のために、個人的にはレトロスペクティブとしてKPTの定期開催を継続していきたいなと。
  • Rebuild.fmを周りのエンジニアに勧めて拡散させる。
  • 昨日はGoConference 2014 springにも参加しましたが、今日のGitHub Kaigiもかなりアツいカンファレンスで、アツい土日でした!