Quit Smoking with HabitStrap

hanahirodev.hatenablog.com

先日↑で紹介した HabitStrapで禁煙してました。

無事66日間達成。

f:id:hiroyuki-hanai:20170622015045j:plain


これから使う人のために

一度締めると緩められないので、最初につけるときに注意してください。 これからの時期、日焼けが残るので注意してください。

こんなので禁煙できるのか、半信半疑でしたが、本当に意外なほど簡単に実践できておどろいている。


勢いで6本セットを買ったのであと5本習慣の改善ができる。

過剰なルーティングのカスタマイズ

元記事はこちら

翻訳

Bad Smell

map.resources :posts, :member => { :comments => :get,
                                   :create_comment => :post,
                                   :update_comment => :put,
                                   :delete_comment => :delete }

Roy Fielding’*1の論文*2によると、リソースと、その状態を表すには、RESTfulなルーティングを使うべきです。過剰なカスタマイズをせず、デフォルトの9アクション(index, show, new, edit, create, update and destroy)を使いましょう。過剰なカスタマイズを避けるには、別リソースを使うようにしましょう。

Refactor

map.resources :posts do |post|
  post.resources :comments
end

postリソースに対して、create_comment, update_comment and delete_commentというカスタムルーティングを使わないようにするために、commentsリソースのnewアクションを使うようにします。できる限りデフォルトの7アクションを使うようにしましょう。

感想

RESTfulを意識しましょう。デフォルトのアクション以外を作りたくなったらコントローラーを分割しましょう。ということですね。

RESTfulにするならデフォルトのルーティングを使わない

元記事はこちら

感想

内容がRails2の時代のものでRails5と書き方が大きく異なるので、翻訳は割愛。 RESTfulなルーティングを採用する場合は、余計なルーティングが生成されると、セキュリティリスクにもなるからやめましょうという主旨だと思う。

  resources :posts, :member => { :push => :post }

みたいな書き方をするのは7種類のアクション(index、show、new、edit、create、update、destroy)全部を使う時だけにして、 一つでも欠ける時は個別に書くのがよい。と思う。

コーディング規約が浸透しない問題

2017/5/15 20:08 追記

コーディング規約をつくっても読まれなかったり、定着しなかったりで、うまくいった試しがなくて、 なんでかなーと思っていたけれど、このツイートをみて、「実装方針の共有」ってところがキモになるんじゃないかと思った。

今まで見てきた/作ってきたコーディング規約だと、コーディングスタイルの話と、実装方針の話がごっちゃになって箇条書きにされているだけというのが多かった気がする。 コーディングスタイルを統一させたいのであれば、PHPならphpcsとか、rubyならrubcopとかあるし、Scrutinizerとか、SideCIでも静的解析はしてくれるので、そういうものを人間が目で確認しなくてもいいように取り入れていくべき。

実装方針については、フレームワークやライブラリによってある程度縛られる部分はあるし、エンジニアなんだから使っている技術は十分に知っとけっていう人もいるかもしれないけれど、スポットで入る人とか、初めて触る人との共有はやはり難しいと思うので、「こういう処理が書きたくなったら、このコンポーネントにまとめてね。」とか「この部分はテストパターンも厚めに書いてね」とか、共有できると、PR見る方も、投げる方も幸せになれるような気がする。

OSSでなくてもCONTRIBUTING.md作ってあらかじめ共有しときたいことは書いておいたほうが良いのだろうか。それでもやっぱり読まない人は読まないから、無駄なんだろうか。 「これくらい知っとけ」の場合でも、「この記事は読むべし」みたいな一覧があると、ミスコミュニケーションが原因でPR全部書き直しみたいな事態は防げそうだけど、大変でも苦労して頑張れ事案なのだろうか。