から、そろそろ1.0.0にしてもいいんじゃないかな、という気持ちになり1.0.0のリリースに踏み切りました。
ランダムで名前を返す、というコアな機能は最初のリリースからほぼ変わってないのですが
ex: Gimei.address)Gimei.unique.name)などなど、8年で地味に着実に改善が進んでいます。どうぞご利用ください。
僕がお手伝いしているiCAREさん主催のミートアップ、iCARE Dev Meetupで、最近発表されたBasecamp社製jsフレームワークであるHotwireについて話しました。
【iCARE Dev Meetup #18】技術顧問が語る、Ruby on Rails実践開発 - connpass
動画も公開されているので気になる方は探してみてください*1。
弊社サービスであるsavanna.ioはHotwireを使って作っています。Hotwireはつい最近発表されましたが、その前身となるフレームワークであるturbolinksとStimulusの組み合わせで数年間開発していました。
なので「サーバサイドはHTMLを返し、jsは最小限」というスタイルが少人数で開発するチームにとてもマッチすることは身を持って体験しています。Vue.jsやReactを採用していたら機能を開発するスピードはもっと遅かったに違いありません。
もちろん適材適所なのでHotwireが適さない分野もありますが、Hotwireが適しているのに無理して他のjsライブラリを使っているプロジェクトはたくさんあるんじゃないかなあ…と推測しています。この発表でちょっとでもそんなプロジェクトが減りみんながハッピーになると嬉しいです(\( ⁰⊖⁰)/)
*1:恥ずかしいのでリンクは貼らない
弊社サービスである savanna.io はずっとTurbolinksとStimulusで開発してきたのですが、この度 Hotwireがリリースされた*1のでTurbolinks部分をTurboに置き換えてみました。その際のやったことやハマったことのメモを残しておきます。メモ書きなので雑なのはご容赦ください。
webpackerを使ってます。assets pipeline派や素のwebpackを利用している人は適宜読み替えてください
./bin/rails turbo:installをするで問題なくいけるのであればそれで。turbo:installが失敗したらturbo-rails/turbo_with_webpacker.rb と同等のことを手動でやればOKです。savanna.io ではTypeScriptを利用しているためうまくいきませんでした(turbo:install はapp/javascript/application.jsがあることを前提としている)。
document.addEventListener('turbolinks:load', ...のようにしている箇所をdocument.addEventListener('turbo:load', ...に置換します。
turbolinks-cache-controlなどは、Turboのドキュメントには書いてありませんがTurboのコードをみたらturbolinksの箇所をturboに書き換えるだけで問題なさそうだったのでそのようにしたら動作しました。多分turbolinksでできることはturboのドキュメントに書いてなくてもできるんじゃないかな…(未確認)。
savanna.ioはOAuthによるログインに対応しています。omniauthのCSRF脆弱性に対応できるように、しばらく前から次のようにPOSTを利用するようにしていました。
= link_to 'twitterにログイン', '/auth/twitter', method: :post
このコードで生成したリンクにアクセスするとうまく遷移できません。これは、Turboからはformも非同期対象になったのが原因です。twitterのログイン用URLをfetchしようとしてpreflightリクエストでエラーになっていました。
Turboはdata-turbo=false属性をつけることで特定のリンクやformをTurbo非対応にすることができます。
しかし、上記のlink_toにmethodオプションをつけたものについてはうまくdata-turbo=false属性をつけることができません。methodオプションがついているリンクをクリックするとrails-ujsが自動的にformを作りsubmitする、という実装になっています。つまり自動で生成されるformに対してdata-turbo=falseを付ける必要があるのですが、これを行うためのAPIがありません。
なのでlink_toをbutton_toに変更して対応しました。
= button_to('/auth/twitter') { 'Twitterでログイン' }
TurboはTurbolinksでは未対応だったformのsubmitに対応しています。data-remote=trueなformでなくとも自動でfetchを使い非同期でPOSTします。
バリデーションエラー時に422などのステータスコードを返すと、URLはそのままの状態で画面の差し替えが行われます。つまり普通に(scaffoldで生成したようなアクションの形で)バリデーションエラーのメッセージを含む画面を描画できるようになりました。
savanna.io では ajax_error_rendererというgemを使いSJRでエラーメッセージを差し込む、ということをやっているのでそれを普通のエラーメッセージ用のHTMLを返すように変更する必要があります。
すべてのアクションを一気に変更するのは大変なので、徐々に切り替えられるように、Turbo方式とTurbolinks方式を混在させられるような仕組みを作りました。
Turbolinksはrails-ujsによるajaxでPOSTをする想定です。そのときredirectをしたらTurbolinks.visit()を実行するようにサーバからレスポンスを返します。これをturbolinks-railsというgemが実現していました。次のコードは、turbolinks-railsと同等のことをTurboで実現するようにしています。このように書くと、data-remote=trueなformからPOSTしたときはturbolinksの挙動で、それ以外はTurboの挙動になります。
# ApplicationController def redirect_to(...) super.tap do visit_location_with_turbo(location) if request.xhr? && !request.get? && !request.format.turbo_stream? end end def visit_location_with_turbo(location) visit_options = { action: 'replace' } script = [] script << 'Turbo.clearCache()' script << "Turbo.visit(#{location.to_json}, #{visit_options.to_json})" self.status = 200 self.response_body = script.join("\n") response.content_type = 'text/javascript' response.headers['X-Xhr-Redirect'] = location end
request.format.turbo_stream?がtrueのときはTurboからのリクエスト経由のリダイレクトなのでなにもしない(通常のredirect_to)ようにしています。
// application.ts import { Turbo } from '@hotwired/turbo-rails' window.Turbo = Turbo
Turboはwebpack環境ではglobalではないので明示的にglobal変数として扱えるようにする必要があります。
これであとは頑張ってバリデーションエラー時の処理を置き換えていくだけ…と思いきやそんなことはありません＞＜バリデーションエラー時にturbo:loadが発火しないという現象に遭遇しました。https://github.com/hotwired/turbo/issues/85 を見た限りこれは仕様とのことです…。
savanna.ioではturbo:loadがすべてのページ表示のタイミングで発火するのを期待しているコードがあったので、検討した結果、上記の「Turbo方式とTurbolinks方式を混在させる」で書いたやり方は不採用にしました*2。
結局、turbo-streamを利用するとajax_error_rendererと使用感がほぼ同じになるのでturbo-streamでエラーメッセージを差し込むようにしました。次のようにしてrender_errors_by_turbo_streamを呼び出すと<div id="erorr"></div>にエラーメッセージが差し込まれます。
def render_errors_by_turbo_stream(model:) render turbo_stream: turbo_stream.update(:error, partial: 'errors', locals: { model: model }), status: :unprocessable_entity end
- unless model.errors.empty? #error_explanation.alert.alert-danger.error-messages %ul - model.errors.full_messages.each do |msg| %li= msg
バリデーションエラー時にブラウザをリロードしたときの挙動はTurbo使用時とそうでないときとで違いがあります。Turbo使用時はformのページがリロードされます。Turbo未使用時は「フォームの内容を再送しますか？」といったダイアログが表示されます。
これはHistroy APIを利用している以上仕方がない*3ですが、Turbolinksのときと比べるとだいぶ改善された感じがあります。Turbolinks利用時かつdata-remote=trueなしなフォームのときは、newアクションのformにいるはずがリロードするとindexアクションにアクセスしてしまう、という事が起きていました。
参考: Turbolinks5でPOSTするときはajax経由のほうが良いのかも - おもしろwebサービス開発日記チラシの裏
turbo-streamを使うと動的にエラーメッセージを差し込むことができてめでたしめでたし、かと思いきや、バリデーションエラー時にsubmitボタンがdisableのまま、という状況に遭遇しました。
form_withなどでajaxを利用してPOSTしたとき、ajax終了時に自動でdisable状態を解除するようにrails-ujsで定義されています。turboはrails-ujsを利用していないので、独自で対応する必要があります。次のように、フォームsubmit後のバリデーションエラーで、rails-ujsのdisable状態を解除するためのメソッドを呼び出すようにしました。
document.addEventListener('turbo:submit-end', (event: Event) => { if (!event.detail.success) { Rails.enableElement(event.detail.formSubmission.formElement) } })
turbo-railsは今のところassets precompileできるなら、turboをその対象として自動で挿入するという仕様になっています。savanna.io は基本webpackerなのですがassetsを使っているgem(administrate)があるのでassets pipelineはオフにしていません。そしてturbo-railsが提供しているjsはES6の書き方なので、本番デプロイ時にuglifierによる圧縮処理で失敗しました。そもそもassetsとして提供されているjsは使わないので、次のようにして対処しました。
# config/application.rb config.after_initialize do config.assets.precompile -= ['turbo'] end
あとは細かい変更なので概要だけ書いておきます。
本エントリはiCARE Advent Calendar 2020の25日目です。
僕はiCARE社内で技術顧問としていろんなことをやっていますが、そのうちの一つとしてRailsアプリケーションのテスト改善があります。具体的には「たまに失敗するテスト」で難しいものがあったときに調査して解決をしています。この「たまに失敗するテスト」はiCAREに限らず、ほとんどの会社が苦しめられているのではないでしょうか。僕のお手伝いしている他の会社でも同様なので、複数社の社内ドキュメントツールに「こういうふうに調査するといいですよ」という文章を書いています。しかしこれらはどれも社内wikiどまりで、現時点で公開されている文章が存在していません。
そこで今回この場を借り「失敗したテストがあったときにどうしたらいいのか」の決定版を書いて、今後は「これ読んでおいてください」で済ませたいなと思っています。
RailsアプリケーションのテストをRSpec、Capybara、Selenium、headless chromeを利用して書いている
テストが失敗したとき、その原因になり得るものはたくさんあります。
テストコードやアプリケーションコードそのものが原因であれば比較的簡単に修正することができるはずです。しかし、それ以外に原因があったときに悩んでしまう人が多い気がします。しかし悩んでも解決することはまずありません。大事なのは必要な情報を収集することです。悩む前にありったけの情報をかき集めましょう。
binding.pry、binding.irb、byebugなどのブレークポイントを活用し、該当するテストコードやアプリケーションコードが想定通り動いているかを確認する
E2Eのテストであれば、スクリーンショットをとりテスト失敗時の画面の状況を見る
rspec --fail-fast ファイル名:行番号 とすると1000回テストを実行して最初に失敗したところで止まります。これが全部通るのであれば、順番依存などで失敗するテストの可能性が高いです。1000.times do it do # たまに失敗するテスト end end
ログやスクリーンショットを見てもよくわからん、となるとき、そもそもテストがどう動いているかについてよく知らないのであたりがつけられない可能性があります。テストはあくまで本番を模して確認するためのもので、本番とは違ったテクニックで実現されています。それらのテクニックを把握してると、失敗の原因を推測できる可能性が高まります(もちろん本番環境がどのように動いているのか知るのも大事です)。
以下抑えておいてほしいテストの仕組みについて書いています。
テストは基本的に次の3つのファイルで設定されているはずです。特に「開発環境だとちゃんと動いているように見えるんだけどテストだとなぜかうまくいかない」ようなケースではtest.rbとdevelopment.rbをみて、どのような差分があるかチェックしてみるとよさそうです。
config/environments/test.rbspec/rails_helper.rbspec/spec_helper.rb例えばActive Jobは各環境で別々のアダプタを使っている事が多いです。本番時にはsidekiqを利用するけれど、開発時にはasyncアダプタ(スレッドを利用した非同期実行)を利用し、テスト時にはtestアダプタ(テスト用のキューにジョブの情報を入れるだけでジョブ自体は実行しない)を選択するような設定が一般的です。
このように、テストを実行するために本番や開発時とは違う形にしている箇所はいくつかあるはず。思わぬ箇所の設定が影響していることがあるので、設定のそれぞれの行がなにを表しているのか説明できるようになっているのが望ましいです(大変だけど)。
各種設定の内容はRailsガイドにまとまっています。読んだけどよくわからない、という場合はお近くの技術顧問に質問ください。
複数のテストを実行するときは、それぞれ独立した環境でテストを実行したいところです。例えばあるテスト中にレコードをinsertしたら、テスト終了時に何らかの形でDBをロールバックしてから次のテストを実行しないとテストが不安定になってしまいます。
RailsはデフォルトでDBのトランザクションを利用してロールバックする仕組みを持っています。最近のRailsプロジェクトだとすべてその方式(トランザクションを利用してロールバックする)で統一できますが、昔のRailsプロジェクトだとfeature spec用にdatabase_cleanerやdatabase_rewinderを利用してDBを毎回空にして対応しているケースもあります(詳細はコラム参照のこと)。
つまり、DBに関しては特に意識しなくても自動で元の状態に戻るようなっているはずです。またrspec-mocksによるモックの設定などもテスト終了時に自動でもとに戻してくれています。べんりですね。
しかし、ツール側で対応していないものは手動で元に戻さないといけません。例えば、csvファイルを出力するメソッドをテストする場合、作ったcsvファイルをテスト終了時に削除しないとファイルがずっと残ってしまいます。そのcsvファイルの有無で挙動が変わるようなアプリケーションコードがあったら、別のテストが失敗してしまうかもしれませんね。
このように、テスト中の変更をもとに戻さないと順番依存で失敗するテストが出来上がるので、意識して変更をもとに戻すようにしましょう。順番依存で失敗するテストは再現がなかなか難しいです。機械的に順番依存失敗テストを再現させる方法としてはrspec の --bisectオプションがあります(ローカルで大量のテストを--bisectするのは骨が折れるので、実際に適用できるケースは少なそうですが)。
参考: Rails tips: ランダムにコケるRSpecテストの修正に便利なbisect（翻訳）
feature specでは、テストコード用のスレッドとテストサーバのスレッドが異なります。結果としてDBのコネクションが別々になり、テストコード用のスレッドでトランザクションを利用するとテストサーバ側のスレッドはそれを参照できません。つまりトランザクションによるロールバックの仕組みを利用できないことになります。なのでfeature specではそれぞれの変更を都度COMMITし、テスト終了時にTRUNCATE文やDELETE文でレコードを削除するのが通例でした。それを自動で行うためにdatabase_cleanerやdatabase_rewinderのgemが使われていました。Rails 5.1から利用できるsystem specではこの仕組をハックして各スレッド間で同一コネクションを使えるようにして、E2Eのテストでもトランザクションを利用できるようにしています。そのため、system specではdatabase_cleanerやdatabase_rewinderは必須ではなくなっています。
E2Eのテストは実際にブラウザを動かしてテストするため他のテストよりも複雑で、デバッグも大変なことが多いです。まず、昨今の一般的なRailsのE2Eテストではheadless chromeを利用することが多いと思いますが、その際には次の3つのプロセスが起動します(アプリケーションサーバにpumaを使用していると仮定)。
capybara がchrome driverのAPIを叩き、chrome driver が chrome のAPIを叩き、chromeはpumaにアクセスするという流れ。
それぞれが独立したプロセスで動いているので、テストを実行している最中に前のテスト関連のリクエストがpumaに届く、というケースがあります。ajaxで非同期にリクエストを投げる画面で起こりやすいです。これが原因でテストが時々落ちることがあります。
たとえばdeviseを利用しているプロジェクトでrequest specを実行するときに、deviseが提供するsign_inというヘルパメソッドを利用してログイン済み状態のリクエストを作ることがあります。このsign_inメソッドは、「次のリクエストをログイン済み状態として扱う」という挙動をします。これと先ほど説明した「テスト中に前のテストのリクエストが届く」を組み合わせるとたまに失敗するテストの一丁上がりです。前のテストのリクエストでsign_inメソッドによるログイン済み状態が解除され、request specが投げるリクエストが未ログイン状態になりテストが失敗します。
chrome driverはバージョンごとにサポートしているchromeバージョンが違うので、ここが一致していないとE2Eのテストが全部失敗したりします。webdrivers gemを利用するとテスト実行時に自動でインストール済みのchromeに合ったバージョンのchrome driverをダウンロードしてくれるので積極的に使いましょう。
ただしwebdriversは並列テスト時に同時にchrome driverをダウンロードしようとして挙動がおかしくなることがあります。そのようなケースでは並列テストを実行する前に明示的にWebdrivers::Chromedriver.updateを実行してchrome driverをダウンロードすると回避できます。
E2Eテストで問題になるのはajaxを利用している箇所とアニメーションを利用している箇所が多いのではないかと思います。
何かをクリックしたときにJavaScriptによって新しい要素が表示され、その新しい要素をクリックしたい場合は通常と変わらずclick_on '新しい要素'のように書きます。このときAPIを実行するなどでJavaScript中の処理が遅くclick_on実行時に新しい要素が表示されていないような場合、capybaraは一定時間待って再度要素を探す、ということを繰り返します。最大でCapybara.default_max_wait_time秒待ちます。デフォルトでは2秒ですが、5秒などにしているプロジェクトも多いのではないでしょうか。
これだけみるとJavaScript(ajax)を利用した画面でもなにも考えずにテストできるように思えますが、そんなことはありません。明示的に、何かが起きるのを待つためのコードを挿入しないとテストが失敗するケースがあります。
例えばモーダルダイアログがリンクの上に表示されているようなケースで「モーダルを閉じるボタンをクリックする→リンクをクリックする」という処理を書いたとします。このときはモーダルを閉じるときにすでにリンク自体は存在するので、先程書いた「要素が現れるのを待つ」は実行されません。なのでモーダルを閉じるのに時間がかかると、次のリンククリックに失敗します(上にモーダルが残っているのでクリックできない)。そのようなケースでは、リンクをクリックする前にモーダルが閉じられていることを明示的に確認し、もしモーダルが閉じられていなかったら待つようにするとうまくいくでしょう。例えば page.has_no_css?('.modal') のように書くとそれができます。
capybaraのクリックの挙動も知っておく必要があります。capybaraは要素をクリックするときに
という手順をとります。このとき1と2の間にタイムラグがあるため、そのときに
などの理由により要素が移動するとクリックに失敗します。
cssアニメーションをオフにする機能はcapybaraが用意してくれています(Capybara.disable_animation = true)。これはcssアニメーションをオフにするstyleタグをRackミドルウェアを利用してすべてのページに挿入することで実現しています。ただし、あくまでこのようなscriptやstylesheetがテスト中のHTML中に差し込まれるだけなので、ここでオフにしている以外の方法でアニメーションを実現していたら別の方法が必要です。
画像のローディングに関しては特に公式のサポートはないので、↓のようなヘルパメソッドを定義して必要なところで呼び出してあげるとよいでしょう。
def wait_for_image_loading Timeout.timeout(Capybara.default_max_wait_time) do sleep 0.5 until evaluate_script(<<~JS) Array.prototype.every.call( document.querySelectorAll('img'), (e) => e.complete ) JS end end
ここまでテスト固有のTipsについて書いてきました。
しかしRailsアプリケーションのデバッグに必要な知識はこれにとどまりません。Rubyそのものに対する知識も必要ですし、Railsを始めとしたgemのソースコードを読み解かなければ解決できない問題に遭遇することもあるでしょう。他にもプロセス、スレッド、ソケットやJavaScriptなど、Railsアプリケーションが関わっている技術の知識も欲しいところです。
範囲が膨大で大変ですが、近道はないので少しずつ勉強してきましょう。僕もがんばります。
この記事はSmartHR Advent Calendar 2020 11日目の記事です。
僕のお手伝いしているSmartHRでは、毎週バックエンドエンジニアが集まり、技術的なトピックについて共有、相談しあうミーティングを開催しています。そのミーティングでは僕がTipsなどを共有するコーナーが常設されています*1。
このエントリでは、そのコーナーで共有した内容をひとつ紹介します。
APIを外部に提供するとき、一定の制限をかけてユーザがAPIを乱用するのを防ぐことはよくあることではないでしょうか。素直に考えると「1時間に5000回までAPIを実行できる」のようなやり方を思いつきますね。GitHubのAPIもそのやり方ですし、SmartHRのAPIも同様です。
じゃあそれでいいのでは。となるかもしれませんが少し待ってください。いろんなクライアントがAPIを大量に叩くことを想像してみてください。12:00、13:00、14:00 のような時間ごとにAPI回数をリセットすると仮定すると、例えば12:00~12:01の間に大量にアクセスが来てそれぞれのクライアントがリミットに達し、残りの59分間はほとんどリクエストが来ない、みたいなことになりそうです。そうすると1分間の爆発的なアクセスのためだけにサーバを増強しなければなりません。
もうちょっとアクセスが均等になるような制限が欲しいと思いませんか？そこでLeaky Bucketアルゴリズムの登場です。
名前の通りAPIの利用を「穴の空いているバケツに水を入れる」と考えます。
次のようなアルゴリズムです。
このような制限をかけることでクライアントに「ちょっとずつAPIを使う」ことを強いることができます。
ではこれをどうやって実装すると良いでしょうか。素朴に実装しようとすると、クライアントごとにバケツの水量を記録しておき、API利用時にそれを増加させ、一定時間ごとに減少させるような形になるでしょう。しかしそれだと「一定時間ごとに減少させる」のコストが高くなってしまいます。
例えば「1分毎に各クライアントの水を100減らす」という実装をしたとします。このときクライアントの数が多くなると、1分ではすべての処理が完了しないかもしれません。つまりこの実装はクライアントが多い場合は現実的ではありません。
同等のアルゴリズムで「一定時間ごとに減少させる」を不要にしたのがGCRA(Generic Cell Rate Algorithm)です
GCRAは計算不要で自動的に増える値である「現在時間」を使って、時間を計算することでAPIの利用可否を判断します。
GCRAは水ではなくセルという名前をつかいますが、アルゴリズム的には同じです。他にもいくつか覚えないといけない用語があります。
| 用語名 | 内容 |
|---|---|
| 理論到着時間(TAT) | Tごとにセルが到着すると仮定したときの到着時間 。APIが実行されるたびにTの分加算される。現在時刻が加算前のTATより大きい場合もしくは初回は現在時刻+TがTATになる |
| T | セルが放出される間隔 |
| τ | バケットの時間的な最大容量(バケットの最大容量 * T) |
この用語でアルゴリズムを説明すると、「TAT-τが現在時刻以下であればAPI利用可能」となります。
具体的な数値をいれないとよくわからないですよね。仮の数値を入れて考えてみましょう。
「なんかいい感じに均等にAPI利用制限できるアルゴリズムがあり、その名前はleakey bucket(もしくはGCRA)である」と覚えておいてください
Sidekiq Enterpriseのv2.2から、GCRAのアルゴリズムで制限をかける機能が使えるようになっています。もともとSidekiq Enterpriseの機能として利用制限をかけるものはあったのですが、それにGCRA(leaky bucket)用のアルゴリズムが追加された形です。この機能はsidekiqのワーカ以外でも使うことができます。
次のようなコード(The Leaky Bucket rate limiter | Mike Perhamから引用)をRack Middlewareとして利用すると簡単にAPIサーバにleaky bucketな制限をかけることができます。
class LeakyLimiter def initialize(app) @app = app end def call(env) remote_ip = env["REMOTE_ADDR"].tr(':', '_') begin limiter = Sidekiq::Limiter.leaky("ip-#{remote_ip}", 10, 10, wait_timeout: 0) limiter.within_limit do @app.call(env) end rescue Sidekiq::Limiter::OverLimit => ex [429, { "Content-Type" => "text/plain", "X-Rate-Limited-For" => ex.limiter.next_drip.to_s, }, ["Rate limited"]] end end end
もしこれから外部にAPIを公開していくぞ！となったときにこの話を思い出してみてください。
だいたいこのような感じで毎週なにかしら共有をしています。自分も参加してみたい！という方はこちらのリンクからどうぞ。
*1:毎週ネタをひねり出すのに苦労しています＞＜
顧問先のiCAREさん主催のミートアップで登壇しました。技術顧問に対するインタビューを受けてから、Rails 6.1の新機能の話をするという構成。
技術顧問が語る最新Ruby on Rails/Vue.js iCARE Dev Meetup #12 - connpass
スライドはこちら。
speakerdeckだとPDFが持っていたリンク情報が消えてしまったので、gistにもほぼ同じ内容を置いておきました。どうぞご利用ください。
こういう形でインタビューを受けるのは初めてでした。技術顧問についての話なのでそれなりに興味のある人はいそうだけど、基本的には僕の個人的な体験や感想でしかないので聞いてる人面白かったのかな…。
Rails 6.1の機能については時間が足りないことは予めわかっていたので話せるところまで話しました*1。急いで話して紹介する機能の数を稼いだけど、例えばstrict_loadingだけにするなど、数を絞ってそのテーマについて深堀りする、みたいな形でもよかったかもしれませんね。
あと話すつもりだったのだけどどこかのタイミングで抜け落ちてしまったトピックがあったので、気力があったら次のブログエントリで取り上げるかもしれません。
取り上げられてなかったけどdelegated typeが気になっている #icare_meetup
— expa / Shu OGAWARA (@expajp) August 21, 2020
*1:お手伝い先各社については興味ある人いたら再演する予定
パーフェクト Ruby on Railsの改訂2版を書きました - おもしろwebサービス開発日記の続き。
いよいよ明日発売日ですね。前のエントリで書き忘れてたことがあったので追記です。
本書の6章からは、Railsのサンプルアプリケーションを作っていきます。技術評論社さんのサポートページからサンプルアプリケーションのコードを手に入れることができますが、GitHub上でも手に入れることができます。
6章の内容を読みつつ写経する方は、GitHubのリポジトリを活用すると写経が捗ると思います。本の流れに沿ってコミットを積んでいるので「写経したんだけどうまく動かない！」という箇所があったら、リポジトリを巻き戻して比較することでtypoに気づけるはず*1。各節終わりの段階でタグも作っているので、途中の過程を飛ばして気になるところだけ写経してみるということも簡単です。
特にビューを一字一句間違えずに写経するのは大変だと思うので、本と一緒にリポジトリをうまく活用して要点を掴んでいってもらえると幸いです(\( ⁰⊖⁰)/)。
*1:本のほうが間違えているのでは、と思ったら別途教えていただけると…＞＜
