GithubのZach Holmanが語るGithubの組織戦略です。まず最初に、 Step #1: ロックスターエンジニアを雇う Step #2: ものすごく透明性のある経営をする Step #3: ブログ/ソーシャルメディアなどでテクノノロジーについて発信する Step #4: カンファレンスで会社について話す Step #5: カネに余裕ができる Step #6: 社員を大勢雇う Step #7: 会社のことを話さなくなる Step #8: コミュニティを無視する Step #9: 創業者が株を売って儲ける Step #10: 別の会社をはじめる という事例を挙げて、Githubは組織が成長する中で、このようなパターンに陥らないように、コミュニケーション及び仕事の進め方をどのように進化させてきたかについて紹介してます。 Dunbar's numberとしてよく知られるとおり、人間が良
1 pixel|サイバーエージェント公式クリエイターズブログ サイバーエージェントのクリエイターの取り組みを紹介するオフィシャルブログです。最新技術への挑戦やサービス誕生の裏話、勉強会やイベントのレポートなどCAクリエイターの情報が満載です。
最近、Quipper という会社で「リリースマネージャ」という名前のお仕事をしています。開発以外の仕事は久しぶりだったので大変でしたが、最終的にそれなり上手く行った方法を振り返りとしてブログに書いておくことにします。 経緯 自分のチームとは別のチームが開発しているサービスのリリースが迫っている中、それまで開発者の1人がリリース管理っぽいことをやっていたのですが、さすがに開発と管理の二足のわらじが辛くなってきたとのことで、急遽サポート的に自分が「リリースマネージャ」という役割りで参加することになりました。 コンセプト コンセプトは「使用するツールを増やさない」です。 管理のために新しいツールを増やすと、その使い方を教えるなど新たなタスクが発生してしまいます。タスクを減らすためにタスクが増えるなんてナンセンスです。 ということでQuipper では普段の開発に Github を利用しているので
常連プログラマがほぼ Rubyist しかいないP4Dなのですが、なぜかPHPカンファレンスで枠をいただいたとのことで、デザイナーとGitについて話し合ってみようという企画に参加してきました。 「生煮えぷるり」をプログラマとデザイナーの間で行ったり来たりさせる話 Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー// Speaker Deck GitHubを使った、実際のプログラマとデザイナーの協業の様子を見てもらおうということで、私がお手伝いさせていただいている、[https://forkwell.com:title=Forkwell] と [https://jobs.forkwell.com:title=Forkwell Jobs] での開発の様子を例にお話させていただきました。 補足とか 「生煮えぷるり」という
pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
2013年2月14日と15日の2日間にわたって東京・目黒で開催されるDevelopers Summit 2013(デブサミ2013)の1セッションで、QA@ITの委託開発の話をさせて頂くことになりました。 ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例(仮) 私はこれまでいつも、デブサミは取材記者という立場で見て来ました。記者として取材して、例えば以下の様な記事を書いて来ました。聴衆に混じって講演を聞く側だった私が、まさか話す側に回ることになるとはと、今からドキドキしています。 デベロッパーズ・サミット2008:すばらしいソフトを作るには、カリスマが講演 未来の言語は「APL」? Rubyのまつもと氏が講演 IIJのRuby対応PaaS「MOGOK」は、どんなサービスか? さて、デブサミは開発者のイベントですが、私は委託側、つまり受託開発における「お客の声」ということでお話
こちらは旧アカウント 新アカウントはこちら👇 @on_lab 今日はGitHub COO PJ Hyett氏・CIO Scott Chacon氏をお招きしOnlab内部向けのInternal Sessionを開催しました! http://t.co/jXFEZTfh 2013-01-29 18:20:52 佐藤 茜@デジタルデトックス中 @AkaneSato 今日は「GitHub創設者が語る"立ち上げから利用者250万人までの軌跡"」に参加予定。予習用に→CEOが自ら語った「イノベーションを起こすためのGithubの哲学」 http://t.co/yRR59RAl #on_lab 2013-01-30 08:40:33
Subversion vs Github 青い線と赤い線。 あなたの会社は、どちらと運命をともにしたいでしょうか? 業界誌でも大きく特集されている 「Githubは世界標準の開発環境である(キリッ」by @HIROCASTER さん Githubを導入している先進企業たち 公開されている情報をもとにリストアップしてみました。 ご要望があれば追加します! (Piece of Cakeさんを追加しました。) (サイボウズさんを追加しました。) これらの事例の中から資料をキリハリして、上司の説得に使いましょう。 \(サイボウズ)/ \(ペイパーボーイ)/ 技術的なアプローチを強化しようと、エンジニアのトップであるmizzyに 直属になってもらい、全社的に取り組むべき課題とチャレンジしたいことの洗い出しや 技術のアウトプットを高めるための取り組みを始めました。 [中略] そのような取組の結果、エン
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
関係各所の協力により実現した1日にとても感謝している@HIROCASTERでございませう。 スタッフとして協力してくれる仲間がいたり、突発LTやってくれたりなど、Agile渋谷のおなじみのの雰囲気がアウェイの銀座も垣間見れたのもよかったです。 1日暇になったからLTやりにきてくれる仲間がいたり、おもしろかった。 Book1st銀座コア店では、Web+DB PRESSを1冊ずつ持った人が7人以上並ぶという光景があったとか。 「The GitHub」イベント詳細発表!話題のあの人が登壇 #Agile渋谷 こちらのイベントのまとめです。 感想 個人的な感想としては、やはり感じていたとおり、GitHubを使いまくってる人とほとんど使っていない人にグッサリわかれてしまっているのかなと。 仕事じゃ使えないけど、プライベートだと使いまくってるなんて、ケースはあまり聞かない。 そして、GitHubを使って
「オレ、入社2週間で大きな決裁を通しましたよ! まだ試用期間中だったのに(笑)」。JRubyのコミッターで、Rubyコミュニティで広く知られた大場光一郎さんに久しぶりにお会いしたら、ちょっと興奮気味にこうおっしゃるのですよ。具体的な数字は書けませんが、確かに、ふつうの企業なら1週間や2週間で決まるような金額ではありません。まして入社2週間の試用期間中の社員の提案です。 大場さんは2011年12月に、日本で5本の指に入る大手SIerを退職し、ソーシャル・ネットワーキング・サービス「GREE」を運営するグリーに入社したというではありませんか。そして、あまりの2社のスピード感の違いに驚いているというのです。Developers Summit 2012(通称デブサミ)が終わった後の飲み会でお話を伺ったのですが、水を得た魚とはこのことかというほど楽しそうに、新しい仕事上のチャレンジについて話をされて
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。 GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 (マークアップ) されて表示されていることはご存知でしょう。 マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown (略して GFM) という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 (もちろん GitHub 初心者です!) の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ (レンダリング) を気にして
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く