読者です 読者をやめる 読者になる 読者になる

北海道苫小牧市出身の初老PGが書くブログ

永遠のプログラマを夢見る、苫小牧市出身のおじさんのちらしの裏

今日はThe GitHub poweredby Agile渋谷の日です

github レポート

The GitHub poweredby Agile渋谷にこっそりとお邪魔しています。タグは#Agile渋谷です。

会場説明・諸注意

  • お菓子の差し入れ有り(ありがとうございます!)
  • ustreamの予定はないので、勝手にやるときはスタッフに声を
  • 写真はリクルートさんとAgile渋谷で公開するかも
  • 各テーブルで自己紹介

CodeIQの詳解 / CodeIQ運営事務局さん

  • CodeIQ
  • 各社の"すごい人"に問題を出してもらい、採点してもらう
  • 開発者としては、人脈を広げられる
  • 企業としては、優秀な方を発掘できる
  • いいね!したらレッドブルあげるよ!
  • 質疑応答
    • Q. 企業は無料で出せるのか?
    • A. 無料で出せる。転職が決まったらお金を頂く。
    • Q. facebookアカウント必要?
    • A. はい。9月の開発でgithubでもログインできるようにしたい
    • Q. 問題が3つしかないけど、いつもこんなもん?
    • A. この後増える予定
    • Q. 20人しか解けないの? すぐ終わってしまう
    • A. 採点者のリソースの問題。審査を1次、2次などにするなど手法を考えたい

(勝手にLT)自動テストのすすめ / ??? さん

  • 「勝手にLTします」
  • 手動 → チェック表、マトリックス
    • 単純作業で間違える
    • 2重チェック、レビュー → 100%にはならない
    • 回帰テストのコスト
    • EDIT&PRAY → 即日は大丈夫でも翌日に問題が
  • 自動テストのメリット
    • 具体的、実施忘れがない、大量のデータ
  • 「続きはこれから作ります」
  • 質疑応答
    • Q. 自動テストを作るコストは?デメリットは?
    • A. コストはかかるが、トータルで見るとコストはかからなくなるはず(本や色々な方の意見)。
    • Q. レイヤは?
    • A. 単体テストのみ
    • Q. エンハンス時のコストは?
    • A. かかる。わざとデメリットは資料に入れていない
    • Q. これは受け入れレベルのテスト?
    • A. NO, ユニットテスト
    • Q. QAのテストをやりたいはず。違和感がある

PythonGitHubベンチャー企業の上手な付き合い方 /@tfmagician さん

  • 開発フロー: かんばん
    • かんばんボードを利用
    • プロダクトバックログ、スプリントバックログ、開発、レビュー、完了、リリース
    • ユーザーストーリーを左から右へ
    • 看板も自作 / コルクボード+ベニヤ板=5000円
  • リーンスタートアップ
    • 「誰が」「何をしたい」のテンプレ → 仮説を立て、検証する
    • ユーザストーリーを作った時点でKPIを設定する
  • githubのカンパニーアカウントのプライベートリポジトリを利用
    • 1プロジェクトについて2~3リポジトリ → [開発名]_[プラットフォーム]
    • Wikiしかないプロジェクトもある
  • githubの個人アカウントも利用
  • ブランチ戦略
  • GitHubの活用法
    • Issues, Wiki, Networkの分岐図、Comittページの差分、コミットのzipダウンロード
  • Issuesでプロジェクト管理ツール
    • メンバー全員にアカウントが有り、Issuesにおける → プロダクトオーナーがかんばんに載せる
    • ラベル : Bug, Experience(UX), Kaizen(ビルドの自動化など)
    • 数時間で直るバグはかんばんにせずその場で
  • Wikiページ
    • プロジェクトWiki → デバグ方法など。仕様はWikiにまとめない。JavadocSphinx、テストコード
    • 社内Wikiリポジトリは空っぽ。開発環境の作り方など
  • Networkのブランチ文傷、Commit
    • non fast-forward でマージされているか
    • 全てのブランチを横断的に確認、Commitページにダイレクトに
    • 行コメントを使い、コードレビューする (昔は#reviewth.isを使っていたが、今は直接)
  • コミットのZipダウンロード
  • GitHubの使用量の節約
    • Bronzeが精一杯
    • 者ないツールも使いたい、古いプロジェクトはGitHubに不要
    • Gitoliteを利用
    • GitHubさん、お願いします!!」
  • Pythonの話は・・・?
    • hyde, legit(gitのコマンド名を整理するラッパー), pyramid, cornice, mongoengine(MongoKitよりおすすめ), fabric
    • 「書く時間がありませんでした」
  • おまけ: Octcat好きな人のための壁紙など紹介
  • 質疑応答
    • Q. コミットコメントはどんな内容?
    • A. 英語で、コミットの内容を。コードレビューは日本語で。
    • Q. レビューはコミットをしてから行う?
    • A. YES。コミットをしてgithubへ上げてから
    • Q. ベンチャー企業で仕事するのは楽しい?
    • A. 楽しい。オフィスに住み込んで働いている。車が9台止められるような一軒家を16万円で。朝会後じゃんけんをして飯当番を決める
    • Q. Issues とかんばんの切り分けは?
    • A. 特にやってない。現状では見つけたらIssuesでもかんばんでもよい
    • Q. かんばんのフォーマットは元ネタあるの?
    • A. オリジナルで自作している。きちんとデザイナーが作ってくれている。拘ると仕事している感が出てよい

とあるプロジェクトのGitHub / @kunitoo さん

  • 受託開発のプロジェクトでのGitHubの活用方法
    • プロジェクトのGitHubへの移行
    • メンバーの増加(開発者8名。業務知識がなくレビューが必須。Gitを使ったことのない人も)
    • 実装 → コードレビュー → 業務レビュー
  • 実装
    • まずpivotal のストーリーをStartedにする
    • トピックブランチを切る
    • 実装が終わったらPull Requestを送り、ストーリーをFinishedへ
    • レビュー後、merge。必ずトピックブランチを削除。
  • 難点1. Pull Requestが溜まる
    • 朝会でIssues からレビューの主担当をアサイン
  • 難点2. Binary Fileはdiffが見れない(Excelなど)
    • S2JUnit4Excelから事前データをとっている
    • Pull Request した後にペア作業でレビューする(あまりよくない)
  • Githubの特色を生かす
    • GitHub のコメントに絵文字を使って楽しく
    • IRC Hookを利用
    • プロジェクト外の人からのコメントも歓迎 → 手元にソースがなくてもブラウザから気軽に読める
  • 質疑応答
    • Q. 社内の別の人が見るという導線は? IRC
    • A. 自発的。レベルの高い人が巡回している。社内でわいわいしていたら人が集まる

参加のSOCIAL CODING / @suginoy さん

  • github との関係
    • はじめてのgit push → Rails Tutorial
    • はじめてのIssue → Rails3 レシピブックの誤植報告
    • はじめての共同作業 → デザイナー向けプログラム部ハッカソン
    • はじめての仕事 → 既成事実に
  • pull request のきっかけ
    • rake rails:templates が動かない → Yokohama.rb
    • セッション中にPull Requestを
  • pull requestの送り方
    • 英語を書く必要がある
    • 公用語は英語ではなくPoor English
    • Github のコメントはあとで修正できる
    • 他の人のPull requestの文面を参考
  • 採用されるまで
    • 時差、休日があり、じれったくなる
    • テストケースがなかった → 追加
    • とりこまれた
  • Railsにフリーライド
    • Rails 3 レシピブックによると「Railsにコミットを行う自由」がある
    • →「Rails はみんなで作るフレームワーク
    • オレゴン大学の実験」 → 参加の原理。建築家と利用者のバランスをとるのに失敗
    • 1つのpull request に多数の人が参加 → SOCIAL CODING
  • まとめ: SOCIAL CODINGはわくわくするからみんなもやるべき

詳解GitHub - Welcome to social coding / @HIROCASTER さん

  • リクルートさん、会場提供ありがとうございました
  • Pull Requestの送り方、受け方
  • GitHubは世界標準 → 会社で使うための解説(たぶん厳しい)
  • 後はWEB DB+Press読んで
  • Pull Request が999を超えると∞になる
  • 執筆中に2回もデザイン変更があった
  • 質疑応答
    • Q. 次のおすすめの書籍は?
    • A. 入門Gitが1冊あれば

GitHubのEnterpriseとはいったいなんだったのか / @koichiroo さん

  • @a_matsuda さん「Alpha Social Coder」
  • 技術者が、どの技術にbetするかは重要
  • CTO室とは → こぼれた球を全て拾う。NOと言えない。
  • 技術の流れの変化
  • GitHubを支える技術 → ソーシャルネットワーク
  • GREEgithubの導入を推進した理由
    • コンシューマーからの技術の採用を検討できない会社は危ない
    • オープンソース開発で良いとされるメソッドを導入
  • GREEのSCMの歴史: 2004年 SVN → 2010年 Git → 2012年 Github
  • Gitだけではプロジェクトを跨いで開発をする機能が足りない
    • github以外の候補: gitosis + gitweb(既存環境), BitBucket, GitLab
  • gitweb → プロジェクト主体。プロジェクトを跨いだ開発は無理
  • BitBucket → gitwebにインスパイアされたUI。ソーシャルっぽくない
  • GITLAB → 当時主要の開発者が2名しかいなかった。githubの開発スピードの方が速い
  • github
    • コラボレーティブな開発を支援する
    • 機密な内容が多いプロジェクトでは不要
  • github enterprise
    • イントラネット内にgithubを設置できる
    • 仮想マシンgithubの機能が入っており、自社で運用する → ソースは外に出さなくてよい
    • 仮想アプライアンスGitHubのフル機能、管理コンソール、LDAP認証、アップグレード(月1程度のパッチ)
    • ライセンスは ユーザ数/年 → $5000 / year・20user (20user単位でしか買えない)
    • unlimitedライセンスは? → 3000user程度を要求されたが、これは無理
    • 運用は自分たちで行う必要がある
  • github enterprizeの管理コンソール
    • unicorn
    • Rails2.0で動いているっぽい
  • @a_matsuda さん "github:enterpriseという解決策はなにか違う"
    • 会社はソーシャルではない(からだと思う)
  • github は世界標準なのはメリット
    • グローバル企業では採択しやすい
  • github:enterprise の効果
    • pullreqのコードレビューがいい
    • デザイナーもgithub好きになった
    • 海外のエンジニアからも
    • 全メンバーの作業の可視化(書き捨てのコードまで含めて)
    • 誰かがメンテする → ソフトウェアの寿命が延びる
    • リポジトリが自由に作れるようになった。Gistも
    • ソーシャルコーディングで一番時間を裂かれているのは「コミュニケーションの時間」
  • github導入に必要なこと
    • 開発のライフサイクルを考える(単なる保存先の引越ではない)
    • githubとのネットワークを確保(開発環境、ステージング、プロダクション)
    • Organization で開発チームを分割する
    • 1.5ヶ月程度で全サービスを移行した
    • 運用の覚悟 → サポートは英語、時差、最後は自分
      • ユーザ数が増え、CPU2個では足りなくなった。メンテナンス用の裏コマンドなどで対応
  • スピード、品質、継続的 → githubが役立っている
  • GREEでは水とインタネットとgithubは無料です
  • 7/27のデブサミでもっと詳しい話をする

Gitホスティングサイトの気になる中身 ~ Backlog+Git編 ~ / @ikikko さん

  • Backlog
    • BTS。非エンジニアもターゲット(経理の方も使っている)
    • Gitに詳しくない人も多い
    • 7月中旬にGit機能の提供
  • Githubとの比較
    • 日本語をフルサポート
    • 初心者向けドキュメントを充実
    • 無料でクローズドなプロジェクト(容量制限などはあるので注意)
  • Git+Backlogのシステム構成(Gitサーバの要件)
    • Git SSH、Git HTTP
    • 内部API(Gitリポジトリの作成など)
    • Gitラッパ(Gitリポジトリの中身を直接)
    • ユーザの認証のためにDB参照
    • pull, push のフックでDBへキャッシュデータを登録
  • ドキュメントのレビューアを募集してます

AimingのGitHubを使った開発フロー / @ffu__ さん

  • 元々はgerrit によるレビューをしていた → githubと併用
  • github はレビュー用。管理ツールとしては使ってない
  • 開発フロー
    • 各メンバーがfork、トピックブランチ、pullrequest、レビュー、マージ
    • Fork A Repoのやり方
  • forkするか共有するか
    • fork → 誤pushがない、自分用のリモートブランチ
    • 共用 → リモート管理が楽、別途fetchが不要
  • Tips
    • @ユーザ名でメンションが使える → pull requestの催促
    • 絵文字で柔らかさを出す
    • ペアGit → rebaseやブランチ発生元の間違いの対応。Gitのノウハウが浸透する。.gitconfigも改善
    • 他のプロジェクトのpull request への横槍が楽しい → 知識の共有が進む
    • README.mdを書く → インストール、ビルド、実行の仕方
    • 有名な人をフォロー (Rubyだと@rknやgithubの中の人) → gistも面白い
    • 個人の有料アカウント → プライベートリポジトリ。執筆など。
    • hubgithubのラッパー
    • Githubの中の人々が面白い → Zach Holmanさん。37signals、情熱プログラマーのインタビューなど
  • pull request毎にCIしている → 時間がなくて話せなくてすみません
  • 質疑応答
    • Q. CIの実現方法は?
    • A. githubのpull-requestをポーリングしている

(飛び入りLT)VCSクエスト - そしてGitHubへ / @joker1007 さん

  • SVNが主流のプロジェクト
    • ブランチ、マージ、歴史改変、並行開発力
  • git-svn で使い始める
  • SVNのクローンのgit リポジトリを作成
    • 競合で死ねるので、SVNはもう更新しない
  • Redmineなどの参照もgitに置き換えて行く
  • SVNでまとまっているリポジトリのgitリポジトリの分割
    • git filter-branch --subdirectory-filter
  • githubへ移行
    • Organizationで課金(数千円)
    • セキュリティ面 → リモートリポジトリを使うのであれば一緒でしょう
  • pull requestを活用する → レビューしやすい
  • SVNをやっつけた!開発環境のレベルが上がった!」

クールダウントーク / @HIROCASTER さん

  • 技評のステッカー3枚ありますよ!
    • じゃんけんでプレゼント
  • pull request 送ってね!