あと一つプログラミング言語を 覚えたら死ぬ! 脳みそがパンクしそうな あなたのための nodeJSことはじめ
趣味プロダクトで楽しいコードライフワークを送る
あと一つプログラミング言語を 覚えたら死ぬ! 脳みそがパンクしそうな あなたのための nodeJSことはじめ
Droneのオープンソース版を試してみました。 - Yosssi's blog
Droneのオープンソース版が公開されたということで、早速こちらを試してみました。 GitHub: https://github.com/drone/drone デモビデオ: https://docs.google.com/file/d/0By8deR1ROz8memUxV0lTSGZPQUk GitHubのREADME.mdによると、Droneは現在以下のバージョンのUbuntuで動作検証が実施されているとのことでしたので、今回は前述のデモビデオでの手順通り、DigitalOceanでDocker 0.8 Ubuntu 13.04 x64のDropletを作成・起動し、その上でDroneをインストールすることにしました。 Ubuntu Precise 12.04 (LTS) (64-bit) Ubuntu Raring 13.04 (64 bit) インストール $ wget http:
Coveralls + Perl - naoyaのはてなダイアリー
Coveralls は Github に置いているソースコードのテストカバレッジを git push の度に調査して報告してくれるクラウドサービス。「カバー率100%を維持したいなら継続的インテグレーション (CI) のレポーティングにテストカバレッジも含めちゃえばいいじゃない」という貴族向けのサービスです。いえ、貴族はフィクションです。 こんな感じでモダンなデザインで色々教えてくれる。各行が何回テストされたかみたいな詳細なレポーティングもある。 Travis CI と同じく Github の README なんかに貼り付けるバッジがあります。というか Travis CI なんかのCIツールと連携して Coveralls にレポートを投げるのが前提になっているようです。 つい最近 プロトタイプ開発用のRailsプラグイン「Chanko」を2.0.0にアップデートしました - クックパッド開
Xcodeのプロジェクトファイル（pbxproj）がコンフリクトしまくるのをなんとかしたい！ | TOKOROM BLOG
2014/02/09 追記 コメントのところでやり取りしているようにmergepbxの作者さんから連絡があって、この記事で書いた問題が修正されました！ 今現在は merge=mergepbx がいい感じになってきているのでそっちがオススメです。 複数人でプログラミングしているとpbxprojがやたらとコンフリクトする 例えば、 Aさんが AALabel.m をプロジェクトに追加して Bさんが BBLabel.m をプロジェクトに追加して とただそれだけなのにマージのときにコンフリクトするpbxprojさん。。。 ただそれぞれファイルを追加だけのことでコンフリクトするなんて… どうにかならんもんかいとTwitterでつぶやいたところ、 @azu_re さんから有り難い教えが！ @tokorom gitはファイル別にマージ方法を指定できるので、mergepbxみたいなのをpbxprojのマージ
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）：プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - ＠IT
プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する：Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）（1/2 ページ） 数回にわたってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。最終回は、GitHubが採用している、git-flowよりシンプルな構成のブランチ管理フローについてです。5つの運用ルールや開発の流れを図を交えて解説します。 本連載「Gitブランチを使いこなすgit-flow／GitHub Flow入門」では、これまでgit-flowについて解説してきました。git-flowはプロダクトを厳格にリリースすることを念頭にフローが考えられていますが、プロジェクトによっては、冗長過ぎると感じることもあるかもしれません。本連載の最終回となる今回は、git-flowに比べシンプルなブ
はてなブログチーム エンジニア座談会 - 株式会社はてな
2013年11月20日アプリケーションエンジニアはどのように仕事をし、どんなことを大切にしているのでしょうか。はてなでは、さまざまなサービスの開発を、複数のチームに分かれて行っています。サービス開発の現場で、はてなブログやはてなダイアリーを開発する「はてなブログチーム」から、id:onishi、id:hitode909、id:shiba_yu36、id:cockscombの4人に話を聞きました。 左からid:shiba_yu36、id:hitode909、id:cockscomb、id:onishi はじめに─本日は、はてなブログチームからプロデューサー兼ディレクターのonishiさん、そしてアプリケーションエンジニア3名にお集りいただきました。はてな社内にはいろいろなチームがありますが、特にブログチームではこのように開発している、という話をお聞きしたいと思います。よろしくお願いします。
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
ITの地殻変動は、だいたいGitHubで起きてる。
http://forza.cocolog-nifty.com/blog/2014/01/it-d213.html なんか、ぎょーかい系のつまらん用語が並んでたので、俺の主観で今の世の中をみよう。 最も大きな変化は、アーキテクチャの解放だと思うよ。 新しい理念ではないけど、その理念を支える基盤が揃った時代だと思う。 まず、共産と資本が衝突しなくなった、ブラウザ戦争とかそう。 昔のブラウザは相手より優れてることが優先されて、標準というのはおざなりだった。 それが今や標準こそが正しく、その正しさによって、みんなは恩恵を受けてる でも、これは共産主義や共産の精神で達されたものじゃない。 あくまでもビジネス上の戦略だ。標準に準拠したほうがユーザーが多いとか、 技術を公開することが企業の技術アピールになるとか。 資本主義の先にあるのが現状だ。 そして、その背景には、アーキテクチャは売り物じゃなくなった
Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ
開発合宿でDevOps界隈やモニタリング界隈で流行りのツールを組み合わせてBlue Green Deploymentできる何かを作りました。 同じチームで開発したid:shiba_yu36 先生やid:wtatsuru 先生が既にブログを書いてますが、自分の視点で書いてみます。（13/12/24追記: より詳細な内容が新規に書かれたのでリンク先を入れ替えました） Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog; Docker コンテナにアプリケーションを立てて Graphite でいい感じに可視化するまで - wtatsuru's blog 僕は主に、各ツールから得られる情報をまとめて管理し、デプロイを実行するデプロイ管理ツールを作成していましたので、それについて書きます。 普段は運用の修行をして
レビューフレンドリーな開発のしかた - tomykaira makes love with codes
2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。 コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。 自分が普段の開発でこころがけていることをまとめてみます。 前提 レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。 なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。 なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。 レビュアーはレビュイーよりも、変更について詳しくありません。 レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して
いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識
いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識：Gitブランチを使いこなすgit-flow／GitHub Flow入門（1）（1/2 ページ） 数回に渡ってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。初回は、ブランチ管理の課題と効率的にバージョン管理できる5つのブランチモデルと、ブランチの管理を簡単に行えるツール「git-flow」について。 Gitなどの次世代のバージョン管理ツールの特徴として、ブランチの機能を高度に活用できるという利点があります。Gitのブランチを生かしたツール・フローとして「git-flow」「GitHub Flow」が注目を浴びていますが、本連載では数回に渡ってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。初回は、git-flowの概要を紹介します。 効率的にバージョ
Git入門 v1.1.0
Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・！15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
結婚式の二次会をGithubで管理するといろいろ便利って話 | -&-
一定期間更新がないため広告を表示しています
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
GithubでPull Requestは絶対消せない。ヤバい＼(^o^)／ｵﾜﾀ - アジャイルSEの憂鬱
2013/10/16: Githubのhelp「Remove sensitive data」について追記 先日、初めて知ったのですが、GithubのプルリクをCloseは出来ても、削除は出来ない。(*1) 普段使う上では困らないのですが、パスワードなどの公開すべきでない情報がプルリクに含まれると、結構ヤバい事になる。 結論 結論を先に書くと「リポジトリを作り直すしかない」 試したこと プルリクしてるブランチを上書きする パスワードなどの情報をコミットから(rebase -iなどで)消してからブランチを上書きしてみた。 $ git push -f origin topic_branch プルリクに上書き前後の履歴が全て表示される... プルリクエストしたブランチを削除する 実はGithubでプルリク中のブランチを削除すると、自動的にプルリクがCloseになる。 Closeになるだけだった..
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
今さら聞けないXcodeのバージョン管理 Gitの基本的な使い方からGitHubへソースコードを公開するまで | DevelopersIO
今さらですがXcodeでGitを使ったバージョン管理の仕方をいろいろ調べたので調査結果をまとめたいと思います。調査した環境は以下になります。 Mac OS X 10.8 Mountain Lion Xcode 5.0 XcodeでのGitの使い方の記事なので、Gitって何？もしくは バージョン管理って何？という方は以下の記事を見た後でご覧ください。 ガチで5分で分かる分散型バージョン管理システムGit 目次 ローカルリポジトリ 準備：ローカルリポジトリの作成 ローカルリポジトリにコミットする ソースコードの変更を破棄する ローカルリポジトリの変更履歴を確認する 以前のバージョンとの差分を確認する リモートリポジトリ 準備：リモートリポジトリの作成 リモートリポジトリを複製する(Clone) リモートリポジトリを更新する(Push) リモートリポジトリから変更を取り込む(Pull) リモート
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-flowでもgithub flowでもない、Git本家推奨のワークフロー
github を用いた開発フローテンプレート