ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
Fabricでサーバー管理をDRYにしよう
7. $ ssh <web/ap server> $ sudo yum update ... $ exit $ ssh <db server> $ sudo yum update • ssh serverA ... $ exit • sudo yum update $ ssh <scm server> $ sudo yum update ... $ exit • お茶を飲んで待つ $ ssh <pm server> $ sudo yum update ... • exit $ exit $ ssh <ci server> • 以下5回繰り返し $ sudo yum update ... $ exit ... 8. $ scp foo.pub <web/ap server>:. $ ssh <web/ap server> $ sudo mv foo.pub /etc/ssh/keys/ $
Sublime Text を導入して RubyMotion アプリ開発をもっと楽しいものに - Watson's Blog
Twitter のつぶやきを眺めていると、RubyMotion アプリ開発では Sublime Text をエディタに使うのが定番になってきた感じがします。 いい加減、私もライセンスを購入しないといけないなと思いつつ、環境構築の手順などをまとめておきます。 1. Sublime Text をインストール 公式サイト から Sublime Text をダウンロードしてインストールします。 2. Sublime Package Control をインストール Sublime Text は Python で plugin を作成でき、さまざまな機能追加ができるようになっています。Github などを眺めていると便利な plugin がパッケージとしていろいろあります。Package Control は、それらパッケージのインストールや不要になった際にはアンインストールしたりと、文字通りパッケージ
DRY原則とテストの可読性 - ✘╹◡╹✘
DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。 The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。 テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。 値とパターンを与えてValidationを行う機能を提供するライブラリ。 実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。 最近不本意ながらキラキラネームの命名力が上がってきたと思う。 avalon - A validator implementation for Ruby https://github.com/r7kamura/avalon 冗長だが読みやすい例 letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。 冗長だが読みやすく、テストコードを見ればライブラリの使い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
