2014-02-12 20:31:40 +0900
Marty Caganという人のInspired: How To Create Products Customers Loveという書籍がよさそう。日本のKindleストアだと780円くらいで買える。
日本語版はないのかなと思ってちょっと探してみたら、翻訳チームのWebサイトがあって、1,200円でiPhoneアプリとして販売されているみたい。
Marty Caganという人のInspired: How To Create Products Customers Loveという書籍がよさそう。日本のKindleストアだと780円くらいで買える。
日本語版はないのかなと思ってちょっと探してみたら、翻訳チームのWebサイトがあって、1,200円でiPhoneアプリとして販売されているみたい。
本日は5ヶ月ぶりくらいに散髪しました。このサイトは、こうした日記っぽいエントリを書けるようにあまりブログっぽい作りにはしていないのです(ブログエントリのタイトル駆動ではない)。
いわゆるブログ的なプラットフォームを使っているひとたちは日常のしょうもないことを書く時、タイトルや落とし所をどう捻り出してるのか気になります。それともそんな無意味なことは書かないのか。
以下、今日見つけたURLたち。
Continuous Deployment at Square: Hard & Soft Skills to Avoid Outages
1月にEtsyで開かれたContinuous Delivery NYCというミートアップで、Squareのニューヨークオフィス所属のエンジニアさんが発表したスライドと動画。Continuous Deploymentにおいて、障害を起こさないためのテクニックを紹介しているようです。
How do I test an application_controller on a rails app - Blog do Time
rspec-railsのanonymous controllerという仕組みを利用すると、ApplicationController
に記述したコントローラー横断的なコードのテストが綺麗に書けるよ、という話。current_user
メソッドなんかのテストをあるべき所に書けるというのはよさそう。
同じような話として、最近はapp/{controllers|models}/concerns/*.rb
のテストをどこでやるか、というのが個人的な悩みどころです。
before_action an anti-pattern? | Transcending Frontiers
Railsのコントローラーにおいて、なんでもかんでもbefore_action
でやるような設計はアンチパターンではないか、という話。
before_action
でメソッドの呼び出しを宣言的に記述するのと、アクションメソッド内でそれらのメソッドを単純に呼ぶのとで、それぞれのメリット・デメリットを挙げたうえで、「アクションの実行を回避させるようなフロー制御をbefore_action
で書くのはいいと思う。それ以外の、単にデータをロードするためだけのメソッドなどはアクションメソッド内に書こう。コードが少し長くなるけど、そのほうが読みやすくて理解もメンテナンスも簡単だ」とのことです。
# Bad
before_action :find_post, only: :show
def show
...
end
# Good
def show
find_post
...
end
コードで示すとこういうこと。
Dockerで任意のプロセスを実行することができるクラウドサービス。課金は1時間単位で、料金はスペック毎に何段階か。PiCloudを思い出したけど、あれよりはレイヤーが下な感じ。
Hakiri: Ruby on Rails Security
Railsアプリの脆弱性チェックをしてくれるサービス。14日間トライアルありで、5プロジェクト月額$19.99から。Gemfile.lock
ベースのチェックだけなら、同サイトのFacets — Scan Gemfile for Security Issuesで無料で行えます。
2014年はqnyp.comのユーザー数を1万人超えさせたい(低めのハードル)。
Railsアプリが大きくなっていくにつれてうまく機能しなくなっていくパターンというものがあり、それに関してReverb.comが簡単に5つのアーキテクチャアンチパターンとしてブログにまとめていました。
Reverb.comはミュージシャンのためのマーケットプレイスサービスです。
紹介されている内容は、ドメインレイヤーのコードがRailsの想定する枠組みの外に配置されている構造を前提としいます。具体的には、ドメインレイヤーのクラスをActionControllerやActiveRecordといったRailsのアーキテクチャの範疇からは独立したものとして構築している形を指しているようです。
(1) 責務を抱えすぎたサービスオブジェクト (Service objects with many responsibilities)
UserService
ProductService
Reverb::Accounts::ForgotPassword
Reverb::Orders::FinalizeCheckout
参考:The Clean Architecture | 8th Light
(2) 名前空間に分けられていないドメインレイヤーのクラス (Un-namespaced classes in the domain layer)
app/reverb
以下に236個以上のクラスとして定義されているapp/reverb/checkout
やapp/reverb/offers
のように分類している(3) 機能を共有するためのモジュールインクルード (Including modules to share functionality)
(4) あらゆる種類の動的なメソッド呼び出し (Any kind of dynamic method invocation)
send
、特にメソッド名を動的に指定するような呼び出しはgrepもリファクタリングもしづらいmethod_missing
は1度も使っていないsend
の呼び出しがないことをテストするRSpec Matcherを使っている
(5) Railsのヘルパー (Rails Helpers)
button_to
とlink_to
を組み合わせて適切なCSSクラスを持ったボタンを定義するような用途はそれほど問題にはならないlink_to_user
といったようなドメイン固有の知識を含む使い方はよくないコメント欄ではサービスクラスに対して「クラスよりモジュール関数にしたほうがよいのでは」、「サービスクラスのメソッド名はForgotPassword.forgot_password
とForgotPassword.execute
とどっちのスタイル?」といったやりとりもされているので、読んでおくと面白いかも。