This is the talk I gave at GitHub Kaigi (http://githubkaigi.org/), in Shibuya, Tokyo, in June of 2014.
![How GitHub Works (GitHub Kaigi, Tokyo, 2014)](https://cdn-ak-scissors.b.st-hatena.com/image/square/49d1630cb560eacd1c08cc82cfed9461c3965432/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Feb0cf950cb8c01310e9a6a5281375720%2Fslide_0.jpg%3F3096454)
チーム開発実践入門 以下に引用しながら私の体験を交えた感想を記載して参ります。 ※先に引用して書いているので、感想がない部分がございますがご了承願います。 理想的なプロジェクト チケット管理システムに課題・障害などを集約し優先度と重要度が分かるようにする できる限り(正しく)バージョン管理システムを利用する 繰り返し再検証可能なCIシステムを用意する 環境の影響を最小限にとどめ、常にリリース可能にしておく すべてを記録して追跡可能にする これまで客先常駐ばかり経験しているので、このような内容を網羅しているプロジェクトには参加したことはありません。 チケット管理やバージョン管理やリリースに関してはルールはありましたが、CIは使用したことがなく名前しか聞いたことがない状態でした。 分散バージョン管理システムを使うべき5つの理由 リポジトリの完全なコピーをローカルマシンに持つことが出来る 動作が
schooで授業もやるし、まぁ隠しておく意味もないかなーと思ってので、wri.peのソースを公開する事にしました。 https://github.com/masuidrive/open-wripe 全部公開しているので、キーを適切にセットすれば自分で動かす事ができます。 元々、公開するつもりでは無かったので、ソースは読みやすくはなっていません(汗 pull-requestを貰えれば取り込みなども行いますので、興味のある方は直接投げてもらうか、Twitter/Facebookなどで声をかけてください。 4/1からwri.peの作り方を解説する授業を4週間schooで行いますので、興味のある方は聞いて頂けるとうれしいです。 増井雄一郎の「wri.pe」を事例に学ぶ、自作サービスの作り方〜サービスデザイン編 増井 雄一郎 先生 – 無料動画学習|schoo(スクー) Webサービスのつくり方
The document discusses the role of software testing engineers (SWET) at DeNA Co., Ltd. It provides: 1) Background on the creation of the SWET group to improve quality and productivity as the Mobage Open Platform expanded globally and the system was refactored. 2) An overview of the SWET group's work, including testing the Mobage RESTful API, web applications, mobile web, and SDKs using techniques
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としてよく知られるとおり、人間が良
#frontrend Vol.5に行ってきた - しるろぐ 前回のFrontrendから約半年。11/16のFrontrend Vol.6に参加してきました。 http://frontrend.github.io/events/06/ いつやるの?Git入門 概要 Gitのコマンドを覚えるだけじゃなくて、Gitの仕組みを理解しよう! speaker 松下 雅和(まつした まさかず)@matsukaz slide http://www.slideshare.net/matsukaz/git-28304397 いつやるの?Git入門 v1.1.0 from Masakazu Matsushita メモ コマンド紹介とかtips紹介じゃなくて、gitの仕組みの説明。 スライドがわかりやすかったのでメモとかいらない。 完全保存版だ! フロントエンジニアとCIとテスト 概要 フロントエンドでも十分j
svnから解放されたのもつかの間、今度はひどい運用のgitとGithubのプロジェクトにアサインされて、これまたひどい歪みのBackboneを矯正するバイトをしている。Backboneに対しては、どんな過酷なプロダクトでもとりあえず導入されていればまだ大丈夫だろう、という印象だったのだけれど、クソプログラマはそんな希望さえもあっさりと打ち砕いてくる。クソBackboneの話は長くなるので割愛するが、単純なページ構成のはずなのに、なぜかViewが複雑に絡み合い、liveとbindとonが混在しているし(これはjQueryアンチパターン)、そもそもそれはBackbone.events使えやという感じだし、なぜかBackbone.Routerが3000行超えてるし椎間板ヘルニアみたいな状態だけど、なんとか意図を読み取り、インデントを正し、git blameして呪詛の詞を並べている。 それとは関係
気になるブログエントリとかを読みやすく整形してくれるみんな大好きReadability。自分のアプリに組み込めるようにAPIも公開されています。が、API Docsの冒頭に次のような一文が。 All requests to the Readability service require access tokens. 認証マストですって。OAuth。わざわざページを読みやすくするためだけにOAuth認証なんてやってられません。現にみんな大好きReederは認証しなくてもReadabilityによる整形が可能じゃないですか! というわけで、認証せずに使えるReadabilityの非公式なAPIをご紹介します。認証せずにページを整形するには、次のような手順を踏めば良いみたいです。 CSRFトークンを取得 記事IDとセッションIDを取得 整形済みドキュメントを取得 こんな感じですね。ではもう少し詳
1 pixel|サイバーエージェント公式クリエイターズブログ サイバーエージェントのクリエイターの取り組みを紹介するオフィシャルブログです。最新技術への挑戦やサービス誕生の裏話、勉強会やイベントのレポートなどCAクリエイターの情報が満載です。
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
README.md Steve Freeman氏とのペアプロ雑感 http://tddbc.doorkeeper.jp TDD Boot Camp 2013-07 -- TDDBC で、偶然にもロンドンから来日していたSteve Freeman氏を招くことができた。ちなみに本当に偶然の来日で、その日の夕方にご家族と隅田川の花火を見る予定だったらしい。貴重な時間である。 20分ほど講演していただき、さらに参加者と一緒にペアプロ課題に挑戦してもらった。しかもペアプロでっていう貴重な体験をさせてもらったので、そのことについてまとめたい。 Steve Freeman氏は書籍 "Growing Object-Oriented Software, Guided by Tests" (邦訳「実戦テスト駆動開発」)の共著者の一人で、Javaのモックフレームワーク "JMock"の開発者の一人。当然、自動販
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
[for English user] This article is a simple introduction about my project for Japanese developer. You do not have to read this, reading this project directly would be enough. RequireJSの応用方法について調べた内容をGitHubでまとめています。実装詳細はGitHubをご覧いただくとして、このエントリではそれぞれの応用について簡単な紹介をしたいと思います。 キャッシュ防止 JavaScriptファイルがブラウザにキャッシュされてしまうために、スーパーリロードなりキャッシュのクリアなりをしないと変更後のファイルが試せないことがあります。 キャッシュを防ぐ方法としてクエリパラメータの利用が知られていますが、Requ
GitHub や GHE を使って多人数で開発していると,プルリクエストを横断して試す必要が頻繁に発生すると思います. プルリクエストを次々に試したり,#30 と #31 をマージした結果を試したい!なんてケースもあるのではないでしょうか. GitHub では git ls-remote すれば分かるように,プルリクエストの番号と対応したブランチがリモートに存在しているので,これを取得してみます. .git/config に追記(あるいは git remote add とかで適当に) [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ(丸投げ): https://gist.github.com/3342247 git fe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く