The GitHub poweredby Agile渋谷 に参加してきた #Agile渋谷

勉強会 Git


(写真：この日発売となった書籍『WEB+DB PRESS』最新vol.69。主催者である(@hirocaster)さんの渾身の執筆記事を掲載！)


最近プライベートでは勉強時の写経や個人開発プロジェクトなどでMercurial(＆Bitbucket)を利用しているのですが、Git(及びGithub)も最低限使えるようにしとかないとこの先アカンな、と思う部分があったのでイベント告知がされた際には即申込み。主催の@HIROCASTERさんによるブログエントリから以下のドリルアプリ環境の事も知り、開催数日前の空き時間にちょこちょこ試して見たりしてました。

開催会場はリクルート メディアテクノロジーラボ＠銀座。会場内の写真については(講演風景を含め)後の写真で幾つか載せますが、とても綺麗で設備も充実した、良い空間でした。正面側のモニターに対する形で、部屋の後ろ側には島毎に個別のディスプレイが設置されているなど、参加者には嬉しい部分だったり。


(開催前のこのテーマについての自らの状況・事前にやっといた事)

このイベント参加に際して、事前にやっといた事や心構えとかを列挙。

  • Git自体はそこまで習熟していない
    • SCMBCで一度Git選択で参加したものの、あまり把握仕切れずに終わる。その後他のイベントに参加したりで多少Gitに対する抵抗感も消え(Windows機を主に利用→Macを使うようになったのとかもある)、今はMecrurialと併せて使いこなしたいな〜、という思い。
    • Gitの基本的なコマンドはそこまで把握してない(とは言え、Mercurialもそこまでは…)。ハンズオン等でスキル向上を図ろうとしている所。
  • Github自体は、アカウントは取ってるもののコード的な側面では使ってない(以前、アジャイルサムライ絡みの活動を行って以来Wikiは時折触る)
  • WEB+DB PRESS vol.69をフラゲしといた(でもそこまで読んで無い)
  • 書籍等を片手に、『githug』をLv20位までは進めてみた

以降、内容についてのメモ等。

会場説明・諸注意


割とギリギリな感じで会場に到着。会場諸説明とか。

CodeIQの詳解

  • CodeIQ運営事務局

自分の実力を知りたいエンジニア向けサービス『CodeIQ』関する紹介。このタイミングで『いいね！』をした人にはRedBullを贈呈！というのがあったので、光の早さで『いいね！』ボタン押下(笑)美味しく頂きました！


まだ出来たばかりのサービスのようなので、興味のある方は是非アクセスし、利用してみてはいかがでしょうか。


PythonとGitHubとベンチャー企業の上手な付き合い方


PythonのパッケージとGitHubリポジトリの連携方法、
GitHubとアジャイル開発手法、GitHubで公開されている便利なPythonパッケージの紹介。
  • 現在、精力的に『スマホおじさん』というアプリを開発中。
  • 弊社の開発フロー
    • (1).かんばん方式の採用
      • ユーザーストーリーを大きめに作成、左から右へ
      • スマホおじさんもこれを使っているらしい。
      • 最後に『検証』タスクを追加
      • ※なお、かんばんは自作しました。


リーン・スタートアップ

リーン・スタートアップ

      • 仮説と検証というタスクを入れている。
        • 誰が/何をしたいのか/どうなるのか
        • 検証の手法については、ユーザーストーリーをつくった時点で作成。
  • Githubで活用している機能
    • issuesの課題管理
      • メンバー全員アカウント持っている。誰でもissuesに投稿可能
      • POが管理し、かんばんへ載せる
      • バグやUX/UIに関する課題を見つけた場合に投稿
    • Wikiページ
      • 2種類のWikiを活用中。
        • プロジェクトWiki(プロジェクトに紐付いたもの)
        • 社内Wiki(社内技術情報など、コードはなし)
    • networkのブランチ分岐図
      • 分岐図：non fast-forwardでマージが適切に行われたか確認出来る。
      • 全てのブランチを横断的に確認可能、commitページにダイレクトに飛べる。
    • commitページのコード差分
      • コードレビューに活用
      • コメントも残せる。
    • コミットのzipダウンロード
      • ソースコードを直接渡したいとき（そういうケースはあんまないけど）
      • ※ちなみにどのページでもダウンロード可能。
  • お金も人もありません！でもリポジトリ欲しい。→苦肉の策として『github + Gitolite』を採用。
  • なお、ATNDにはpythonについて語るとありましたが、pythonの部分はつくる時間はありませんでした…。なので今回は関連ツール紹介を。
    • hyde：静的ファイル生成ツール
    • legit：gitコマンドを簡単にしてくれるツール
    • pyramid：FW嫌いの為のFW
    • cornice：Restful Web APIフレームワーク
    • mongoengine：MongoDBとパイソンのためのODM
    • fabric：パイソンで書かれたデプロイツール
  • 質疑応答
    • [Q].コミットコメント、何を入れてますか？
      • どんな機能修正を施したかについて、『英語』で入れてます
    • [Q].コードレビューはオンライン？オフライン？
      • 基本的にはコミット→githubのページからコミットページに飛んでレビュー。
    • [Q].ベンチャー企業と言うことですが、楽しいですか？
      • はい！つくばで一軒家借りてやってます。一緒に住んでます(シリコンバレー方式)。
      • 車が9台停まれるらしい。
      • 家賃は16万→諸々あって10万掛からない程度らしい
      • アジャイルで紹介：ジャンケンで負け二人が飯当番
      • 楽しくやってます。
    • [Q].issueとカンバンの切り分けは？
      • 今そこのルール決めはあんまり。POが見て適宜判断。（※この点についてはあまり上手くは回ってない）
    • [Q].カンバンの一枚一枚、(テンプレの)元ネタは？
      • 一応オリジナル。Agileの書籍等を参考にしている
        • USに関するタスクをpostitで貼れるようにしている
        • 利用しているフォーマットは自作(by デザイン担当)

とあるプロジェクトのGithub

GitHubを実際に受託開発のプロジェクトで利用した際のお話をします。
  • 自己紹介
    • 『永和システムマネジメントの提供でお送りします』
    • (永和システムマネジメントの)活動：coderwallで29位。活発に活動しています。
  • 今日のお話
    • 受託開発を行うプロジェクトでのgithubの役割や活用方法についてお話します。
  • 注意：
    • こんな人はいません
    • 学園最強のlv5
    • その幻想を打ち破る
    • ソーシャルコーディングの話しはしません。気になる方はこちらのスライドを御参照下さい。(資料見当たらず…)
  • プロジェクトの状況
    • 2年以上続いていたプロジェクトを昨年移行
    • メンバーが増えた（→開発者8名）
    • 業務知識が無いメンバーが多いため、コードレビュー必須
    • gitを使った事ない人が居る
  • 開発のすすめかた
    • 実装→ソースコードレビュー→業務レビュー、という流れ。
    • Pivotal Trackerも使ってます。
    • 進め方
      • pivotalのcurrentにあるストーリーの状態を開始
      • githubでプルリクエストを送る
      • ストーリーをfinishに
      • ソースコードレビュー
      • レビュー終了
        • merge pull request
        • リモートのトピックブランチを消す
  • 困ったこと
    • Pull Requestが溜まる（レビュー対象がたまる）
      • 朝会で今日のPull Requestを確認、issuesでレビューの主担当を確認。
    • Binary File（diffが見れない）
    • S2JUnit4
      • 事前データをexcelファイルから挿入しているため、修正を行うとバイナリデータの為githubで差分表示出来ない。
      • →Pull Requestしたあと、ペア作業でレビューを行うようにした。
  • 活用
    • Emojiが使えるので楽しくコードレビューした
    • プロジェクト外の人もコメント頂けるように
  • 手元にソースコードを持ってくる必要が無いため。気になったときに読む事が出来る。
  • まとめ
    • 朝会でPull Request：回るようになった。Github中心に回り出した。

参加のSocial Coding


Ruby on Railsに初のPull Requestをキメた話をします。

  • 私とgithub
    • はじめてのgit push
    • はじめてのissue登録
    • はじめてのgithub共同作業
    • はじめてのgithubのお仕事
    • 翻訳を公開したら、知らない人からpull request
    • ※github、結構何でも使えます。
  • Pull Requestをキメるきっかけ
    • Railsのテンプレートをカスタマイズしたい。
    • Yokohama.rbのイベント中にpull req を送る事に。
    • Pull Requestを送るまで
      • 当然、英語です。
      • 相手はプログラマだから何とかなる
      • 科学の世界の公用語はあ英語ではありません。Poor Englishです。
      • githubのコメントは後で修正出来る。（←ココ試験に出ます）
      • 他のpull reqが参考になる。
    • あとは待つ。待つ…来ない。
    • 助け船来た！（※テストケースが無いと無視されがちだったらしい)。テストケースは重要。
    • Pull Requestの修正がなされ、コメント来た！
  • 『情熱プログラマー ソフトウェア開発者の幸せな生き方』の著者、Chad Fowlerによる言葉。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

誰でもRailsを使えるが、Railsコントリビュータを名乗れるのは少数。
オープンソースの開発者の多くは、単に楽しみと自己表現のためにやっているんだけれど、 そこには現実的な動機もいくらか存在する。彼らは自らの活動をコミュニティとの社会的な 人脈にしようとしている。彼らは名声を築きつつある。彼らは業界で一定の評価を獲得しつつある。 意図してそうしていないかもしれないが、結果的に自分自身を売り込んでいるんだ。
    • %git commit/コミットの意味…関わり合うこと。関係すること。
      • #=> 1つのPull reqだけど、オンライン・オフラインで色んな人が参加した。
      • それがgithubであり、social codingなのかも。
  • まとめ
    • 小さなパッチだが、Ruby on Railsの開発に参加した。
    • git logに出て来ない人も参加している。
    • 新たな社会構造が出来るかはわかんない
    • でもSOCIAL CODINGするとwkwkするからみんなもやろうよ！

詳解GitHub

当日発売されるWeb+DB PRESSの特集「詳解GitHub」について

WEB+DB PRESS Vol.69

WEB+DB PRESS Vol.69

  • 作者: 大塚弘記,渡辺修司,堤智代,森田創,中島聡,A-Listers,はまちや2,川添貴生,井上誠一郎,近藤宇智朗,ヒノケン,後藤秀宣,佐藤鉄平,mala,奥野幹也,伊藤智章,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2012/06/23
  • メディア: 大型本
  • 購入: 13人 クリック: 143回
  • この商品を含むブログ (18件) を見る

開始前のこのつぶやきに、恐れ戦く参加者一同。一体どんな発表になるんだろう…？

内容はこちら。超スピードで展開されるスライド資料に会場は多いに盛り上がっておりました♪

大まかな内容(メモ)はこんな感じでしたよ。

    • ソーシャルコーディングの革命
    • 過去と未来のお話
    • コードを公開する簡単な手順
    • Pull Requestを送る為の手順、易しく解説。
    • Pull Requestを受けたときの手順も易しく解説。
    • 会社でgithubを使ったことない人にも易しく読めます。
    • 『Githubは世界標準だから！』。
    • どうやって上司を説得するかのポイントも。
    • 後は読んでください。
    • 実際、Pull Requestを送ると数値が上がる。
    • やがて君にもPull Requestが。
    • githubを使いこなしてない、って人は是非買って欲しい。
    • 使う機会が大事。
    • 計36ページ、頑張って書いた。
    • github,2回もデザインリニューアル。2回も撮り直した…
    • そういえば、懇親会で話すしかない。
    • 銀座(a.k.a ザギン)で懇親会。
    • githubにグッズサポーターをお願いしたが、在庫が無く断念…。
  • 質疑応答：
    • [Q].雑誌かった後のgit書籍おすすめは
      • 濱野さんの『入門git』。

入門Git

入門Git

GitHubのEnterpriseとはいったいなんだったのか

グリーのソーシャルコーディングは、GitHub:Enterpriseが支えています。
そんな社内に当たり前にGitHubがある風景からのお話をします。
  • 書籍紹介
    • 絶賛発売中。

JRuby on Rails実践開発ガイド (Professional Ruby Series)

JRuby on Rails実践開発ガイド (Professional Ruby Series)

  • こちらについては来月出るらしい。

たのしい開発 スタートアップRuby

たのしい開発 スタートアップRuby

  • 経歴紹介
    • プログラミングを始めたのは小4から！(basic)
  • 大場さんのお仕事
    • CTO室所属：開発に関わるモノなら何でもやる
    • 開発環境全般（noと言えないCTO室）
    • エンジニア全体の事を考えてよりよい環境を作る
    • 必要なら自分たちで作る事も。
  • 技術の流れの変化
    • 70〜80年代/labs -> commodity
      • 研究機関や国などが新技術を発明、それが段々アカデミックに、普遍化。
    • 90年代/vendor -> commodity
      • MS/Sunが開発→大企業が採用→中小へ
    • 00年代/community -> commodity
      • ベンダーの力がバブル破壊により弱まる。OSSが台頭
    • 10年代/consumer -> commodity
      • みんなが触って、当たり前になる→逆輸入的に企業が採用
  • Githubとは何だったのか
    • グリーのSCMの変遷
    • gitでもいいんじゃない？
      • →gitだけでは、プロジェクトを越えて開発する為の機能が足りない。
  • 代替検討
    • gitosis+gitweb/Bitbucket/GitLab…どれもなかなかしっくりこない。
    • githubの開発スピードは恐ろしく早い。競合はそれに着いてこれるのだろうか
    • →最終的にgithubを採用。
    • githubを採用：何が嬉しいか？
      • コラボレ−ディブな開発を支援する環境。
  • github:enterpriseとは
    • 紹介：
      • 会社のイントラ上にgithubを設置出来るサービス。
      • 自社鯖として使える。
      • ソースコードを外に出す必要が無い。
      • 特徴：ディズニーランドが会社にあるよ！みたいな感じ。
        • 仮想アプライアンス
        • githubのフル機能が使える
        • 管理コンソール
        • LDAP認証
        • アップグレード機能
        • ユーザー数/年のライセンス
      • デメリット：自分達で運用する必要がある。
        • (※メンテナンス中)永和さん『githubつかえねぇよ！』で阿鼻叫喚を横でニヤニヤ
    • 導入：でも高いんでしょ？
    • →実際高い。
    • 20user = 1 seat pack
    • $5000/year
    • ※それでも、人を雇うよりかは…
      • アンリミテッドも検討したが『3000人居ないとペイ出来ないよ』(by githubの中の人）
  • 松田明 says
"github:enterpriseという解決策はなにか違う"
by ソーシャルコーディングの世界
    • 会社という閉じた空間に置くことで、ソーシャルでなくなる。
  • github:enterpriseとはなんだったのか
    • 導入後、各方面からの喜びの声
    • 他にも多数
      • githubが無かったらxxのリリース無理でした
      • トイレで用を足しているとすれ違いざまに感謝される
      • がいじんから感謝のskypeが届きmtg入れられる
    • 変わるのはシェアとコラボレーション
      • 誰が何を開発してるのか可視化
      • 手元で書き捨てるようなコードも公開
      • 作った人でなくても修正して使い続けられる
        • ソフトウェアの寿命が延びた。
  • 個人repos
    • gitosis時代
    • github
      • 一人幾つでも無限repos
      • 好きなときに作成
      • 自動化も出来る
    • ※githubが効果や影響を与えるのはのはコラボレーション促進の部分が大きいかも。
  • github導入にあたって
    • 単なるリポジトリの変更だけでは無く、プロジェクト開始から開発、
    • リリース運用といった開発のライフサイクル全体で使える準備が必要。
    • ネットワーク環境
      • 開発環境
      • ステージング
      • プロダクション
    • organization/ team/ repositoryポリシー
    • 運用環境
    • 会社で使うためにはorganizationの設計が必要。
    • Greeでは全サービス移行に1.5ヶ月(で済んだらしい)
  • 運用する覚悟
    • サポートは英語
    • 時差
    • 最後は自分で何とかする
  • 大切な事はスピード、品質、デリバリー。

Gitホスティングサイトの気になる中身 〜Backlog+Git編〜

GithubのようなGitホスティングサイトの中身がどのように構成されているのか、
現在Gitホスティング機能を開発中のBacklogを一例として紹介します


  • Backlog + Gitの概要
    • Backlog：
      • どこでもプロジェクト管理バックログ
      • ポップなデザインで非エンジニアにも親しみやすいBTS。
      • gitに詳しくない人達も多数
      • Git機能の提供（7月中旬予定）！
      • 残念ながら世界標準ではありません…。
      • githubとの比較
        • 日本語をフルサポート！初心者向けドキュメントも充実。
          • 英語もサポートする方向ではあります。
        • 無料でクローズドなプロジェクトを立てられる！
  • Backlog+Gitのシステム構成
  • 処理の流れ：Gitクライアントからの流れをイメージ図付きで解説。
    • Backlogのドキュメントレビュワー募集中です！

AimingのGitHubを使った開発フロー

[f:id:absj31:20120623173042j:image:w700]
AimingでもGitHubを使ったプロジェクトが増えてきました。pull request、CIとの連携、
ブランチの管理など運用フローが安定しつつあるのでご紹介します。
  • 自己紹介
  • Aimingについて
    • オンラインゲーム会社
    • Ruby/Javascriptプログラマー募集中です！
    • コードレビューをする文化が根付いてる
    • 元々はgrritを使っていた
  • Aimingでよくある開発フロー
    • リポジトリを各メンバがfork
    • トピックブランチを作成
    • Pull Request
    • Pull Request上でレビュー、誰かがマージ
    • github helpに準拠したやり方
  • forkベース開発の流れ
  • fork式/本体ブランチ式　どっちがいいのか？
    • fork式
      • 本体masterへの誤pushが起きない
      • 自分用のリモートが作れる
    • ブランチ式
      • リモート管理が楽
      • 本体からfetchする手間が省ける。
    • (藤村さん)個人的にはfork式がいいかな〜と。
  • Tipsを幾つか。
    • レビューをメンションでお願いする
      • どうしても放置されるpull reqが出てくる。
      • メンションは@でメンション出来るので、メンションでレビューをお願いする
      • 絵文字でお願い感を醸す
    • ペアgit
      • プロジェクト開始直後はgitの走査をペアでやるとよい
      • 気が付いたらみんなのgit力がupしてた
      • ペアgit中に .gitconfigの設定改善もガンガンする
      • 顰蹙を買ったgitconfigがこちら。
    • Pul Requestへの横槍
      • 他プロジェクトのpull reqに勝手にコメント
      • 見て欲しい人にpull reqのURLを送りつけてコメントをもらう
      • こだわり派によるrubyコードのマナー指南などが発生
      • 結果的にコミュニケーションが増えて、知識の共有が進む
      • 楽しい。
    • README.mdを書く
      • ディレクトリーにREADMEを書くと、github上にひょうじされる
      • インストール、ビルド、実行方法を書いておくと何かと便利
    • （おまけ）有名人をフォロー
      • トップページのnews feedは素晴らしい情報源
      • 新作ライブラリの情報はgithubが一番速い
      • 有名なライブラリの作者は片っ端からフォローすると良い
      • みんなのgistも面白い。
    • （おまけ）有料アカウント
      • プライベートリポジトリは何かと便利
      • 執筆とか
      • 決して完成しないwebサービスとか
      • 人に公開したくないものとか
    • （おまけ）hub便利過ぎる
      • githubをより便利にしてくれるgitコマンドのラッパー
    • （おまけ）githubber自体が面白い
      • 働き方自体がすごい面白い。
      • zach holmanさんのブログ参照
      • github自体の歴史は37signalのインタビューが面白い。
      • 情熱プログラマーにもインタビューが載っている。
  • まとめ
    • CIの話が無くてスミマセン
    • 実はpull req毎にci回してビルド結果をコメントしています。
その他

本編については以上で終了。ちなみにこの他にも休憩時間を利用して幾つかのトークがあったのでざっくり紹介。

  • 渋谷のMatz(TwitterID:@shio1997)さんによる『自動化テストのススメ』。手動テストの問題点や限界点を指摘し、自動化への流れを解説していくLTでしたが、資料自体未完成のため途中で終了。


タイトルだけ見て、『ジョジョは出ないのかな』…と思ってましたが、ちゃんと出てました(笑)


スライドはこちらになります。

また、スタッフの方からの書籍ご紹介コーナーも。

ソフトウェアの世界でキャリアを築く Making it Big in Software

ソフトウェアの世界でキャリアを築く Making it Big in Software

プログラマのための論理パズル 難題を突破する論理思考トレーニング

プログラマのための論理パズル 難題を突破する論理思考トレーニング

なぜ3人いると噂が広まるのか 日経プレミアシリーズ

なぜ3人いると噂が広まるのか 日経プレミアシリーズ

クールダウントーク

  • Svn手強いっすね…(直前の@joker1007さんのLTを受けて)
  • 管理コンソール以外については書籍で紹介しています！
  • WEB+DBのステッカー欲しい人！3人まで。
    • 3人ジャンケンでget!
  • 感想をPull Requestしてくれると嬉しいです。

また、最後は『Agile渋谷』の話も。Agile渋谷は@HIROCASTERさんが中心となって発足したコミュニティです。詳しくは以下の記事及びFacebookのグループにて。


勉強会タイトルとしては『GItHub』とありましたが、GitHubだけではなく様々な情報が得られた面白い内容でした。Git自体の熟練度が個人的にはまだまだなので、Git自体のスキルアップも行いつつ、GitHubも使いこなせるようになるべきだな、としみじみ感じたのでありました。

主催者の@HIROCASTERさん、講演及びLTを行われた皆様、会場ご提供頂いたリクルート メディアテクノロジーラボ及び関係者・スタッフの皆様、そして参加された全ての皆様、ありがとうございました！


その他関連：



この勉強会を受けての自らへの今後の課題

『勉強会に参加しただけ』では勿体無い部分も多いしそれだけでは満足すべきでもなくスキルアップとならない。なので自分なりにて事前・事後に於いてやった事、やる事、やってみたい事等を参加した毎にふりかえり、思いだし、洗い出してみようと思います。

Git/Githubについては、そもそも利用頻度自体が少ないのでまずはそこのスキル向上から。

  • Gitの基本操作を覚える
    • 書籍を読む
    • SCMBC等の過去の参加ログ等を見なおす
    • ハンズオン資料を探し、自分でそこそこ使えるようにコマンドを覚える
    • 先日からやり始めた『Githug』を最後までやり通す
  • Githubの使い方を覚える
    • Git/Githubを使った個人的プロジェクトを始めるのが一番手っ取り早いかな？今やろうとしてるのはJava系/Mercurial/Bitbucketなので別案で考えるか…

時期や内容については早急には求めないが、どこかの段階で内容を振り返って行こうかなと思います。『お前あ〜やって書いてるのにやっとらんやないか』と突っ込まないで頂ければ幸いです。(;´Д｀)