はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Rake とは「Ruby で書かれた Make っぽいもの」でだいたい合っている。 単にタスクに必要な処理をまとめておいて呼ぶ、くらいの使い方でも便利ではあるけれど、Make をリスペクトして用意されたファイルタスクなどを絡めるともっとおもしろいことができる、という話。 ファイルタスク リファレンス・マニュアルなどに詳しい説明があるが、簡単に表現すると「あるファイルを作るためのタスク」である。 典型例でいうと実行バイナリの生成など。必要なヘッダにリンクしつつ適切なパラメータとソースファイルをコンパイラに渡す、といったことをファイルタスクが責任をもって定義する。 タスクの事前条件 タスクには、それが必要とする事前条件を定義することができる。 たとえばコンパイルを実行するタスクならば、必要なファイルや準備を定義したタスクを事前条件に指定しておくことで、必要であれば事前にそれらを実行する。 これ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

たとえば Travis CI は CI 固有の Gemfile を指定することでインストールする gem の数を減らしたり、などの方法をとることができる。 ほかにも、たとえば Rails の複数のバージョンでアプリケーションを実行したいときなど、(Bundler の group を使うより) Gemfile をわけるシチュエーションは考えられる。 Gemfile で定義されている依存のマージを行いたい、というときにどうすればよいか。 eval_gemfile Gemfile を評価する場合、eval_gemfile(gemfile) で評価する。 dependencies gem メソッドで追加された依存 gem は dependencies というメソッドが記憶している。 dependencies は Gem::Dependency のインスタンスを含む配列である。 やりかた

僕はMacBook Airが嫌いですが、MacBook Proは好きです。あのペラペラしたキーボードとトラックパッドがだめです。 しかしMacBook White Unibodyが一番好きです (でした)。 Appleファンボーイ諸氏は使っているApple製品が壊れると「またApple製品を買える!」と喜ぶそうです。 僕はお金持ちではないので頻繁にMacを買えたりはしませんが、気分転換によくOSをクリーンインストールします。 OSをクリーンインストールするたびに入れるものが減っていってとても気持ちがよいです。 しかしOSをインストールしたあとのセットアップはできるだけ手間をかけたくありません。 高揚していた気持ちも既に冷めつつあるかとおもいます。 設定ファイルをGitなどで管理している人も少なくないとおもいます。 Rubyのバージョン管理ツール (RVMやrbenv) も「これ」というお決

変更が追跡できる、つまり差分が見れる、ということは価値です。 空のファイルが作られてもUnstagedである限り差分は見れません。 Gitはコミットしていなくともインデックスワークツリーといった版管理のステージがいくつかあるので、それらのうちのどれかに含まれていれば回復、修正は格段に容易になります。 ファイルの内容をインデックスに登録せずファイルが追加されたということだけを記録したいこともあります。 git-addには-Nオプションがあります。このオプションをつけるとファイルの存在のみをインデックス登録できます。 言葉を換えるとファイルの中身をインデックスに登録しません。 ファイルを自動生成するジェネレータと相性がよいので覚えておいて損はないとおもいます。

ふつうに git init して「最初の」コミットをつくると、最初のコミットの差分が見れない。 たとえばRailsなど、ジェネレータがいろいろつくる場合、どういうファイルが生成されたのか、という記録が残っていると嬉しい。 git-commit に --allow-empty というオプションがあって、これを渡すと空のコミットオブジェクトがつくられる。 空のコミットを最初に作っておくことで、リポジトリにおける実質的な最初のコミットの差分を見ることができる。便利。 git-flowというツールをつかってリポジトリをつくるとデフォルトで空のコミットがつくられる。 git-flowを用いずにリポジトリをつくる場合、以下のようにしてリポジトリをつくることが多い。

MySQLのインタラクティヴ・シェルのプロンプトは、対話実行環境で動的に設定する以外にいくつか方法があって、/etc/my.cnf か $HOME/.my.cnf で設定するか、MYSQL_PS1 という環境変数を定義するとよい。 色をつけると見やすくなるので色をつけたい。シェル上で実行される場合、エスケープシーケンスが有効なのでそれを使うとよさそう。 my.cnfにバックスラッシュを書く場合、バックスラッシュ自身をエスケープしたほうがよい、と書いてあって、面倒そうなにおいを感じるので、環境変数を設定することにする。 Vimだと <C-v><C-[> で \e にあたる文字を入力できるが、git-diff などでもエスケープシーケンスが有効になってちょっと危険なので直接入力せずに済む方法を考えてみる。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

# !/bin/sh echo 'Refresh packages' dpkg -l > default_packages sudo apt-get update sudo apt-get upgrade echo 'Install tools' sudo apt-get install -y screen zsh git-core curl wget echo 'Clone dotfiles from GitHub' mkdir -p $HOME/works git clone --recursive git@github.com:aereal/dotfiles.git $HOME/works/dotfiles echo 'Make dotfiles symlink on $HOME' for f in \ .gemrc .gitconfig .gitignore .irssi .pro

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Octopusというライブラリを用いるとActiveRecordでsharding/replicationが実現できる。 DB構成 ユーザデータを持つDB ホスト: userdb.localhost データベース名: user replication: しない (アプリケーションでは読み取りしかしないので最初からslaveのみ参照するようになっている) アプリケーションのデータを持つDB ホスト: app.localhost データベース名: app_{RAILS_ENV} replication: する 何が問題か OctopusがActiveRecord::Base#connectionとActiveRecord::Base#connection_poolを乗っ取って、クエリを監視して適宜、shardもしくはmaster/slaveへ投げるようになる。 Octopusを使ってrepli

Rails 3から resources というルーティング・ヘルパが用意されてRESTfulなURI設計に非常に役立ちます。 しかしながらサロゲートキーをプライマリキーに据える設計が主流のRails界隈において、データベースのプライマリキーをメンバURIのキーに採用するという戦略は /users/4 といった無味乾燥で、またわかりやすさに欠けるURIを生んでしまう弊害もあります。 たとえばユーザを表すリソースがあったとして、それらを一意に定めるのは名前が考えられます。 つまり /users/aereal や /users/aereal/edit といったURIで表現したいです。 RailsのRESTfulなパス・ヘルパ (user_path など) のうちメンバ・リソースに関するヘルパについてはオブジェクトを渡すと暗黙のうちに Object#to_param が呼ばれます。 これをオーバー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

RSpecのshared contextはもちろんご存知ですよね。 参考: shared_context - 改めて学ぶ RSpec うまく使ってあげることができたならDRYで可読性の高いコードになるのですが、いちいち context の名前を打たないといけないのがだるい! 切られた context は文章の形をとっていることが多いので多くのエディタの補完機能でも打鍵数が多くなってしまいます (単語ベースの補完がほとんどのため)。 我々はこのまま「要素がふたつpushされている」なんて文章をずっと書かねばならないのでしょうか? やはりプログラムのコード、人間が楽をしようだなんて所詮は夢のような話だったのでしょうか。 いいえ、そんなことはありません。人間はテストコードともっと仲良くなれる、そうRSpecならね。 タグを使います。 タグは example groups などを切るメソッド (i

ちょっとややこしいタイトルだけど、つまり 単体テスト (機能テスト): 正しくリダイレクトされるか 正しいステータスコードか (Temporary? Permanent? See Other?) 正しいリダイレクト先か 受け入れテスト: リダイレクトを透過して正しい動作をしているか GET /posts/1/edit -> PUT /posts/1 -> GET /posts/1 みたいなリダイレクトが透過的に行われることがある GET editで入力された値がPUTで更新されたか? RSpecの Kernel.#describe でテスト対象、つまり単体機能か操作フローか、を切り分ける。 follow_redirect! を明示的に呼ぶことでリダイレクトを追うことができるので、それの有無によってテスト対象を切り替えることができる。 describe "PostController" do

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?