このエントリは、ソニックガーデン Advent Calendar 2015 の18日目の記事です。 現在、SonicGardenでは、中途採用のプロセスで「トライアウト」というWebシステムを自分たちで開発しながら、応募者とのやりとりを進めています。 そのやりとりの中では、応募者の方の人となりを伝えていただいたり、SonicGardenでのRails開発における技術力を身につけてもらっています。 ここでは、トライアウト中のRailsの開発力を身につけてもらうためにやっていることを紹介しようと思います。最後に、トライアウトを越えてきた人にとても評価の高いコードレビュー動画をチョットだししているので、ぜひ見てみてください。 トライアウトの技術の学習プロセスは以下の流れになっています。 チェックリスト＋課題 必要な技術を一覧化して、課題を通して基本を学んでもらうコードレビュー動画 他の人が過去に

この記事は Ruby on Rails Advent Calendar 2015 - Qiita の12日目の記事です。 vimでrailsを書く毎日を送っているkoheisgと申します。 一昨年までphperだった自分が、この1年railsを書いて身に付けたテストの間合いについて、書きたいと思います。 rspecアドベンドカレンダーかと思いましたが、rspecでrailsをテストするときの内容なのでご容赦ください。 そもそも、テストの間合いとは twitterでtwadaさんが下記のようなことを呟いていました。 今日はまだテスト駆動開発についてよく知らない人や、少し知っている人、もう間合いを見定めた人、様々な人の前で TDD について改めて話しました。お聞きくださった皆様、ありがとうございました。講演後もたくさん議論できてよかったです。 — Takuto Wada (@t_wada) 2

オプションの意味 -f d = ドキュメント形式で出力する。--format documentationと書いても良い。 --dry-run = テストを実行しない（Dry run） --order defined = 定義されている順に実行する。spec_helper.rb等でランダム実行を指定していなければ省略可。 出力例 $ bin/rspec -f d --dry-run --order defined ContactsController administrator access behaves like public access to contacts GET #index with params[:letter] populates an array of contacts starting with the letter renders the :index templa

(訳注：2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50～100msに高速化できます。 定義についての注意　―　この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング（これは全く別の難物で、あなたのアプリケーションに実装する必要はありません）は、別の機会で扱いましょう。 するべきキャッシングをしない理由

このエントリで書いた内容は、ほぼ Growing Rails Applications in Practice の内容が元になっています。英語ですが、ここで挙げた内容以外にもコードを綺麗に保つテクニックが書かれており、かつページ数も少なく読みやすいです。コードを綺麗に保つのが好きな方は一読してみることをおすすめします。 はじめに Rails で fat model を避けるための方法は、7 Patterns to Refactor Fat ActiveRecord Models を始めとして、多くのやり方が存在します*1。 validation や callback は ActiveRecord(以下AR) を継承せずとも利用することができます。7 Patterns to Refactor Fat ActiveRecord Models の 「3. Extract Form Objects

はじめに 先月、エラーページをAsset Pipelineで管理する - WEB SALADというエントリを書いたのですが、あの後「これはエラーページに限らずもっと一般化できるのでは」と思ってgemを作ってみました。 このエントリでは、このgemの紹介と使い方を説明したいと思います。 Gakubuchiとは READMEにも書いてあるように、GakubuchiはRailsアプリケーションにおける静的ページをAsset Pipelineで管理するためのgemです。 その仕組みは前回のエントリでも述べた通りで、次のようになっています。 使用するテンプレートエンジンを登録する app/assets/templatesのようなディレクトリを作り、そこに静的ページを書く assets:precompileをフックして、実行後にコンパイルされた静的ページをpublic配下に移す 1の設定作業や3のフッ