これは Ruby アドベントカレンダー 24 日目の記事です。 Railsを長く開発していると機能を追加していくにつれてテストコードも肥大化し、初めのうちは一瞬で終わっていたrspecも気がつけば数十分かかるようになっていたということも多いと思います。テストをCIで回していると、結果が得られるまで作業が止まることになるので、テスト時間の肥大化は結構大きなインパクトを持ってきます。 テストの中にボトルネックがある場合それを解消することである程度の高速化ができますが、純粋にテストの数が多いということになると、全てのテストを実行するのを諦めないのであれば、テストを並列に実行するのが高速化のアプローチとなります。 テストを並列実行するgem テストを並列に実行するgemはすでに世の中にいくつもあります。 rrrspec Cookpad社が作っているrrrspecはRSpecを複数サーバで分散実行し

「vim入門」系記事で解説されないためか、意外と使い方が知られていないvimgrep。 ファイルを開いては検索、開いては検索ってしてる？ grepするためにvimから出てる？ grep結果を見て改めてvimで開き直してる？ それ、vimgrep使えば256倍早くなる（かも）よ。 簡単なまとめ vimgrepは… ファイルをまたいで検索できる grepやgit-grepよりは遅いので巨大プロジェクトでは検索対象を絞ったほうがいい ワイルドカード使うと簡単に絞り込める 繰り返し同じ対象から検索する場合はargument listを使うと捗る gitリポジトリではgit-ls-filesと組み合わせる 該当箇所に素早く移動＆編集できる quickfix-windowと組み合わせると更に捗る この記事読むと分かること :vimgrepコマンドの使い方 :cwindowコマンドの使い方 :argsコ

"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に

自動的にCircleCIがいい感じに調整してくれるのでGitHubのprivateリポジトリをCircleCIでテストするのは簡単ですが、テスト過程で他のprivateリポジトリをcloneするにはちょっとした工夫が必要になります。 CircleCIにuser keyを登録する まずCircleCIの "Project settings" > "Checkout SSH keys" に行きます。 みたいなのがあるので、ボタンをクリックします。するとGitHubのOAuthページが表示され公開鍵への書き込み権限を要求されるので許可します。 これによりあなたのGitHubアカウントに新しい公開鍵が設定され、それに対応する秘密鍵がCircleCI上に登録されます。なので、あなたがアクセス権限を持つGitHub上のPrivateリポジトリにはこの時点で全てこのCircleCIのプロジェクトからはア

自動実行の流れ 1. CircleCIを起動する Nightly builds というAPIを使います。本来は重たいテストを夜中に1回だけ実行する、みたいな用途で使うことを意図しているのでNightly buildsという名前になっていますが、簡単な話が「外から環境変数を追加した上で、特定のブランチに対するテストを実行させる」機能です。 BUNDLE_UPDATE という環境変数を設定した上でmasterブランチをビルドするとbundle updateが実行されるようにすることにしました。以下のようなスクリプトを用意し、cronで平日の朝に自動実行するようにしています。 _project=user-name/repo-name # 適当に変える _branch=master _circle_token=$1 trigger_build_url=https://circleci.com/ap

TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏

Boxen使わなくても許されるのは2012年までだよね を書いたのも今は昔、1年間の運用の末にこの度Boxenを卒業しました。なぜBoxenをやめたのか、やめて今はどうしているのか、といった話を書きます。 Boxenのつらいところ ここで述べるBoxenの問題点の大部分は筆者のBoxenおよびPuppetに対する理解の低さが根底にあります。間違った使い方をしている可能性は十分にあり、適切に使っていればこのような問題は発生しないのかも知れません。しかしながら、深い理解がなければまともに使えないというのもどうかと思いますのでつらつらと並び立てたいと思います。 挙動を把握するのが難しい BoxenはPuppetの上で動作します。Puppetを便利に使うためのフレームワークみたいな位置づけだと思っています。 Rubyに詳しくなくても、RailsのDSLを組み合わせるととりあえず動くものを作れるよう

続編を書きました - Boxen使ってて許されるのは2013年だけだった すごいすごいと話題な割に誰も使っていないと話題のBoxenを使ってみた。 3行で分かる結論 Boxenは... Macのセットアップを自動化してくれる 個人用途でも十分便利だが真価を発揮するのは大人数で使うとき Puppet知らなくても案外使える この記事で分かるもの Boxenの個人用途での使い方 Boxenのチーム用途での使い方 Puppetのmanifestの簡単な書き方 この記事を読んでも分からないもの Puppetの詳しい使い方 Boxenを使うと何ができるのか BoxenはGitHub社が開発しているシステムで、Macのセットアップを簡単にできるようにしてくれる。新しくMacを購入したら開発環境や各種アプリケーションをインストールすることから始めるが、これをコマンド一発で全てやってくれるようになる。 Bo

結局jQuery.Deferredの何が嬉しいのか分からない、という人向けの小話 一年ほど前に JavaScript - jQuery.Deferredを使って楽しい非同期生活を送る方法 - Qiita [キータ] という記事を書きました。 で、一年経って、ふと、「もっと分かりやすくjQuery.Deferredの便利さを説明できるんじゃないか」と思い立ってざざざっと書いてみました。 小話と言うにはちょっと長いけど。 -- jQuery.Deferredを使うと嬉しいのは、jQuery.Deferredの仕様を満たす部品同士を簡単に組み合わせることが可能だからです。中には処理を書き下すことができるとかコールバックのネストを防げるのがいいとか言う人もいますが、個人的にこっちのほうがよっぽど重要だと感じます。 例えるならレゴブロックです。レゴブロックはあの凸と凹を持ってるブロックを自由に組み合

閲覧上の注意 この記事で対象としているバージョン0.5.3は結構古いので注意してください。この記事でいえば、bindは無くなり、現在ではonやlistenToが使われています。 その他の割りと新しい情報は Backbone.js Advent Calendar 2012 などにあります。 （追記ここまで） ネタ切れ感が否めないBackbone.js Advent Calendarですが、今回から何回かに分けて懇切丁寧な入門記事を書いていこうと思います。 以下のように書き進めていく予定です。 Events View Model ViewとModelの連携 Collection ViewとModelとCollectionの連携 RouterとHistory なおここで扱うBackbone.jsのバージョンは0.5.3です。 Backbone.jsのドキュメントを開くとまず最初に解説されているの