Announcing GitHub Japan
CommunityCompanyAnnouncing GitHub JapanGitHub <3s Japan, and today we’re excited to announce the formation of GitHub Japan G.K., a subsidiary of GitHub, Inc. Our new office in Tokyo is our first official office… GitHub <3s Japan, and today we’re excited to announce the formation of GitHub Japan G.K., a subsidiary of GitHub, Inc. Our new office in Tokyo is our first official office outside of the U
AWS 対応した GitHub Enterprise v2 へスムーズに移行した話 - クックパッド開発者ブログ
技術部 id:sora_h です。今回は v2 より AWS 上での運用に対応した GitHub Enterprise を、オフィスにある既存の環境から AWS へスムーズに移行した話について説明します。 GitHub Enterprise v2 GitHub Enterprise (以下 GHE) とは、github.com を自前の環境で運用できるアプライアンスです。クックパッドでは主に GHE 上で開発を行っています。 従来まで GHE の実行環境として VMware vSphere, VirtualBox 上の実行しかサポートされていませんでしたが、11 月にリリースされたアップデート v2 より、AWS での実行がサポートされました。 クックパッドでは全面的に AWS を利用していますが、いままで GHE を AWS 上で動作させる事はできませんでした。そのため、オフィス内に E
cocos2d-x-3.3からWebViewが使えるようになる。 - 銀の人のメモ帳
cocos2d-x-3.x系で使えるWebView作った - 銀の人のメモ帳 前に書いたこれがcocos2d-x本家にMergeされたってだけの話なので、作った経緯とかはこれ見るといい。 本家にPR出すつもりではあったんだけど、適当に入れたらerror出てて解決方法もよくわからなくて放置してたら、別のPRのレビューしてくれたcocos2d-xの人が僕のリポジトリ見て、issue投げてくれた。 Merge into official repository · Issue #2 · gin0606/cocos2dx-WebView · GitHub なんというか見る人は見るんだなーという感じで、オープンソースプロジェクトにcommitする楽しさみたいなのを感じられた。 PR眺めてたら早速Winでの実装がPR出てて、承認〜〜〜〜という感じで良かった。 add simple implement o
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
sbt で github にあるライブラリを直接使う方法 - 宇宙行きたい
github にあるライブラリを使うのにローカルにインストールして云々しようとして色々試していたら id:xuwei と id:j5ik2o に github にあるライブラリ、直接使えるよ m9(^Д^)ﾌﾟｷﾞｬｰ と言われて涙目でした。 んで、 あんまり知られてないし、教えてやったんだからブログに書け！！ と、id:j5ik2o に脅されたので涙目で書いているところです。 import sbt._ import sbt.Keys._ object ProjectBuild extends Build { lazy val root = Project( id = "root", base = file("."), settings = Project.defaultSettings ++ Seq( name := "coderwall-bot", organization := "o
GitHub Pages now runs Jekyll 2.2.0
ProductGitHub Pages now runs Jekyll 2.2.0We've upgraded GitHub Pages to support the latest version of Jekyll, the open source static site generator. Whether you're a new user or a savvy veteran, here are a few… We’ve upgraded GitHub Pages to support the latest version of Jekyll, the open source static site generator. Whether you’re a new user or a savvy veteran, here are a few features that might
A better branches page
ProductA better branches pageBranches are an essential part of collaborating using GitHub Flow. They’ve always been cheap and easy to create within a GitHub repository, and today we’re making branch management more straightforward.… Branches are an essential part of collaborating using GitHub Flow. They’ve always been cheap and easy to create within a GitHub repository, and today we’re making bran
Docker HubとGitHubを連携させてmod_mruby実行環境をDockerで簡単にデプロイ
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 Docker Hub公開のアナウンスがあったので、早速Docker HubとGitHubを連携させてmod_mrubyの実行環境をDockerイメージとして作った上で、それをMac上のVagrantで動くCoreOS内のDocker環境にデプロイしてみました。 本エントリではmod_mrubyとしていますがここは重要ではなく、自身が開発しているGitHubのアプリケーションに置き換えて読んで頂けると、便利さが見えてくるかと思います。 試してみると、非常に簡単にDockerイメージを作成できた上に、迅速にmod_mrubyの軽量な実行環境をデプロイできたので、その流れを簡単に紹介したいと思います。 Docker Hubにアカウントを作ってGit
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
WIP (Work in Progress) な Pull Request を目立たなくする Chrome 拡張をリリース - @kyanny's blog
Pull Request ベースの開発手法（いわゆる "GitHub Flow" というやつ）では、未完成のブランチに "WIP" という件名をつけて作業中である旨を示しつつ途中経過もレビューしてもらう、というのをよくやります。 Quipper ではそれに加えて "DONT MERGE" とか "DO NOT MERGE" というのもよく使っています。 WIP と同じ意味で使うこともあれば、レビューの過程で発生した議論にまだ決着がついていないのでマージしないでね、という意思表明として使うこともあります。 僕は一日にだいたい十個弱の Pull Request をレビュー・マージしています（個人差はありますが Quipper のデベロッパーの多くは似たようなものです）レビュー・マージのタイミングははやいほうが良いので、一日に少なくとも二回か三回は Organization の Pull Req
octorelease という gem をつくった - Gosuke Miyashita
serverspec とか specinfra の Changes を手で書くのがだるくなってきたので、自動化するために octorelease という gem をつくりました。 rubygems.org にもあげてあるので、gem install で入ります。 Rakefile の中に require "bundler/gem_tasks" require "octorelease" みたいに書いて、 $ rake octorelease すると、 こんな感じになります。 何をしてるかというと、rake release した後に、前のバージョンとリリースするバージョンの間に含まれるプルリクエストをgit logで拾って、各プルリクエストに Released as vX.X.X. とコメントをつけ、GitHub 上にリリースを作成し、リリースの本文にはプルリクエストへリンクを張る、ってなこ
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点 - プログラマの思索
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点について指摘していた記事があったのでメモ。 【参考】 GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録 GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ] Fujimura ? GitHubで既存のissueに対してpull requestする hub コマンドで github から fork して pull request をさくっと - #生存戦略 、それは - subtech Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記 bleis-tift/Git-Hooks かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）：Redmine×Gitのハー
GitHub で Pull Request を Merge したらコードが消えた話
会社で使ってる GitHub のプライベートリポジトリで master ブランチに対して出てる Pull Request を Merge したらコードが消えるという珍事があった。ファイルを削除する commit とかないにもかかわらず、全消しされてしまった。ちなみに同じ Merge を手もとでやるとコードが消えたりはせずちゃんと Merge された。極めて謎な現象だった。 master ブランチが空になるとデプロイができなくなって不都合があるので（ Webistrano 上でデプロイするとき master ブランチからしかデプロイできないようなレシピになってる）、コードが消滅したブランチを bukkowaremaster にリネームして手もとで Merge したブランチを force push してしのいだ。 GitHub に問い合わせてみたところ、ぬるい感じの一次返信が来たので原因教えて
Githubの組織が成長する過程で変えたことと変えなかったこと - ワザノバ | wazanova
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としてよく知られるとおり、人間が良
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう Jenkin developers accidentally do "git push --force" to over 150 repos on github | Hacker News Jenkinsの開発者、Luca Milanesioによって、Jenkinsの多くのgitレポジトリに対してpushが行われた。不思議なことに、pushをしたというのに変更点はほとんどみられない。一体ルカは何をやったのだ。 Dominik Bartholdi やあみんな、とくにルカ。 昨日、GitHub上のJenkinsの多くのレポジトリ（50以上）に、なにか変なことが起こった。 どうやら、Luca Mmilanesioが、何の変更もないのに、たくさんのたくさんのレポジトリにpushしたらしいのだ。
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Primer
会社に Github導入した話
TechCrunch | Startup and Technology News
github を用いた開発フローテンプレート