makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「RESTful#とは勉強会2」に参加しました

2014/11/28(金) 「RESTful#とは勉強会2」に参加してきました。

DoorKeeper
http://rubychildren.doorkeeper.jp/events/17514

ちなみに私、ちょうど会社でRESTの必要性に迫られて、以下の書籍で独学している最中なのです。

JavaによるRESTfulシステム構築JavaによるRESTfulシステム構築
(2010/08/23)
Bill Burke

商品詳細を見る


この本は、JavaのRESTに関する仕様であるJAX-RSの本です。現在、読みながらちょとずつ写経中。
そんな私にとって、この勉強会はタイムリーなネタなのでした。

ちなみに前回も参加したかったんですが、他の勉強会と被ってしまって残念ながら行けなかったのでした。。。
なので今回が初参加。
この日は前半が「Webを支える技術」の読書会で、後半が @t_wada さんの講演でした。

とても参考になる勉強会だったので、当日のツイートをTogetterにも纏めてみました。
http://togetter.com/li/751922


■ 前半:「Webを支える技術」の読書会
以下の書籍をターゲットに、テーブルごとに読書とディスカッションを行いました。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
(2010/04/08)
山本 陽平

商品詳細を見る


今回は5章「URIの設計」が対象範囲でした。

まずRESTを学んで驚いたのが、URIを「設計する」という概念があることですね。
この章にも出てきますが、「Cool URIs don't change」(クールなURIは変わらない)とWebの発明者が論文で提唱してます。

あと、リダイレクトの仕組みを使ってURIの普遍性を維持する、というお話がありました。
これはちょうど職場で悩んでいた点だったので、とてもヒントになりました。

最後に質疑応答でAmazonのURLについて話がありましたが、これも興味深かったですねー
1つのリソースに複数のURLがある場合、<link rel="canonical">で代表URLを指定する、という仕組み、初めて知りました。
そしてAmazonでは、代表URLに敢えて長い、書籍名を含ませたURLを採用している点が興味深かったですね。
あと、同じリソースへのURLはできれば1種類がよい、というお話もありました。


■ 後半:「和田さんによるRESTfulな設計のお話・座談会
千駄ヶ谷.rbで講演されたときの資料をベースとした講演です。
RESTful Web アプリの設計レビューの話 from Takuto Wada


すごく参考になった。以下、個人メモ。
---

■ 結論:RESTは麻疹である
  • 良いものなので、早く感染して使いまくって、痛い目を見て卒業しましょう。
  • 痛い目を見て、しばらく離れて、あとで戻ってくるくらいがちょうどいい。


■ URLに動詞が含まれていないか
  • まずレビューすのが、URLに動詞が含まれていないか、という点。
  • RESTの世界は動詞は5つくらいあればいい。他の動詞はいらない。
  • URLに「edit」が含まれる場合は、「まあいいか」とすることもある。規約による妥協、という考え。
  • なるべく名詞に近づける努力をする。
  • loginは動詞じゃね?と調べてみると、そもそも「login」という英語はなく、logとinの合成後だった。


■ URLが無理な構造になっていないか
  • 話し言葉みたいに読める、というのはURLにとっては大事でなはい。意味がわかることが大事。
    • TumblrのURLは悪い例。
  • コピー元とコピー先に上下関係にない。
    • レビュー時は、URLの右にいくに従ってサブセットになっているかを見る。
  • URLの左に行くほど偉い、右にいくほど偉くない。
  • URLの名前探しには英英辞典や類義語辞典が便利。いつも辞書と共に設計をする。
  • リソースとリソースの関係を探す第三のリソースを探す。
    • 自分が知ってる単語から始まって、自分の知らない単語にどう辿り着くかが大事になってくる。
    • HTTPメソッドが4つじゃ足りないよ、とよく言われる。(例:購読する、とか4つでできないじゃないか!)
    • そこでまず考えていくのが、「自分がやりたいことが、何かを消したり更新したり、といった4つのどれに該当するだろうか」と思考を持っていくこと。
    • 例えば「購読する」なら、「subscription」を「作ろう」としている、と考える。 
    • 例えば「属する」なら、「belong」という関係を「作る」と考える。「作る」が「入社」で、「消す」が「退社」になる。
    • といったふうに、CRUDでけっこう表現できる。この思考を結構頑張ることが大事。


URLの意味と意思
  • URLには、「意味を示す場所」と「意思を示す場所」がある。レビューではそれが混ざってないかを見ている。
  • ?の前までは「リソースの意味」。?の後ろが「クライアントの意思」。
  • ?以降をすべて取り去っても意味は変わらないか、?以前にリソースの意味と関係ない要素はないか、を見る。
  • lang=jaとかは微妙で、グレーゾーン。


■ CRUDの重力に引かれていないか
  • Webの4つのメソッドがRailsの6つのメソッドに対応づいている。
  • 第3正規形のテーブルと1:1のrouteがあるのは粒度が細かすぎて、n+1問題にも容易に突き当たる。
  • DBだけでなく、Webでもこの問題が出てきてしまう。
  • DBの世界の粒度とWebの粒度は同じではない。
  • どうやって1:1と1:1じゃない世界を結びつけたらいいのか、はcontrollerの仕事。


■ ステータスコードの選択
  • そのリソースに対する操作がどうなったか、がWebの世界にはある。それがステータスコード。
    • URL設計の壁を乗り越えていけば、ステータスコードも収束してくる。
    • URL設計を頑張ると、その後は結構スイスイ行く。
    • ステータスコードで障害の一時切り分けができる。
  • 良くない設計は、ステータスコードを全部200で返して、レスポンスのJSONにエラーコードが入っている、とか。
    • レスポンスの中を見ないと成功か失敗かが分からないし、コードの解釈も場面で変わるのでナンセンス。
    • レスポンスの中身を見なくて、なにがどーなったかが分かる組みがWebにある。それがステータスコード。
  • Railsはフレームワークまで例外が到達すると、ステータスコードに例外をマッピングして投げる。
  • URLに含まれるのIDを1ずつズラしてアクセスしたり、アクセス権限がないけどリソースは存在、といった情報を知りたがる悪意に対処するために、ステータスコードをわざとズラして秘匿することがある。


■ 表現の設計
  • 返ってくるJSONにURLが含まれてない、といったことがないかをレビューで見る。
  • URLがないと、そこで袋小路で止まり、それ以降、辿れなくなる。
  • URLが分からないものに対してURLを提供する。


■ 持続性のある表現のために
  • 行き止まりを作らないようにする。選んで遷移できるようにする。
  • サービスから送られてくるURLを使うことによってのみ遷移できるように考えてください。
  • リンクがすごい大事。サーバから帰ってきたリンクで遷移先を決められるようにすること。


■ よくある議論
  • 確認画面とかプレビュー画面のurlってどうやってるの?
  • 階層構造だと、移動元と移動先、とか対等なものを表現するのに困るよね?
  • 一部成功して一部失敗のときのレスポンスコードってどうするの?
  • DBを移行して擬似キーのIDが変わったら、ぜんぶリンク切れになりました。。。
  • クライアントかサーバか、どっちで処理するかは揺れる。フレームワークの種類によって大きく変わる。
    • 時代はサーバである、クライアントである、と安易に言うのは思考停止でしかない。
  • Twitterの @logout さんは、Twitter社は盲点だった。URLでログアウトしてしまう・・・

★感想:
ちょと前にRESTを学び始めた初学者の私にとって、すげー参考になる勉強会でした。
REST、URI、奥深し・・・。
あと和田さん、あるときはTDDだったり、DBだったり、RESTだったりと、毎回、技術の引き出し凄すぎやで。

そして勉強会が次回もあるなら、是非参加したいなぁ、と思うのでした。
あと、「Webを支える技術」と「JavaによるRestfullシステム構築」の2冊も、きちんと読んで写経しないと・・・

皆様、ありがとーございました。
スポンサーサイト

SQLアンチパターン読書会 「マジックビーンズ(魔法の豆)」に参加しました

2014/11/25(火) SQLアンチパターン読書会 「マジックビーンズ(魔法の豆)」に参加してきました。

Doorkeeper
http://sqlap.doorkeeper.jp/events/17729

以下の書籍をターゲットとした読書会なのです。

SQLアンチパターンSQLアンチパターン
(2013/01/26)
Bill Karwin

商品詳細を見る


場所は前回同様、秋葉原のクラスメソッド株式会社さんでした。
参加者は9人かな。初参加は2人でした。

ちなみに今回はアクティブレコードがテーマの1つでもあったりするのですが、
「そういや以前、Railsの勉強会でアクティブレコードの章を担当した時にスライド作って発表したっけ・・・」
と思ってslideshare見てみたら、スライドのviewが37000を超えていてフイたw

HerokuではじめるRailsプログラミング入門 6-3節「複数モデルの連携」 by @makopi23

キャッチーなキーワードやタイトルに釣られてやって来る人が多いのかな・・・。
正直、スマンカッタ・・・


■ 発表
今回は @a_suenami さんが発表担当でした。
マジックビーンズ from Akira Suenami


DDDネタ、RailsのARの弊害などに言及しつつ深く考察されており、よく纏まっています。
DDDネタをよく発信されている増田さんからもコメントが。





■ ディスカッション
今回もディスカッションしたいネタをみんなで付箋に書き出しました。
20141125_sqlap.jpg

以下、個人メモ。
---

■ 24.2.1 アクティブレコードはモデルをデータベーススキーマに強く依存させてしまう
  • Railsでコードを自動生成するとフォームがモデルに乗ってくるので、ビューとDBが密結合になる。。。
  • Railsの4から、モデルからフォームを除くことができるようになったらしい。


■ ActiveRecordとDataMapper

■ JOINはActiveRecordとして許されるか
  • JOINも隠蔽したほうが良い。
  • Railsの場合は、scopeというDSLの層を入れることで隠蔽に成功している。
  • リポジトリパターンを使って避ける。


■ SQL vs ActiveRecord
  • DBアクセスをSQLを手で書く方が良いか、AcriveRecordに任せる方が良いかは、「生産性」と「平準化」が判断軸になる。
  • 生産性
    • 生産性なら、DBアクセスのSQLとコードを手で書くより、ActiveRecordを使ったほうが断然高い。
  • 平準化
    • 3年後に修正する場合にもActiveRecrodの方が早いかというと、保守性の観点からそんなことはない。。。
  • 「いつ」を照準にするかでどちらが良いか、コンテキストが違ってくる。
  • まず市場に早く製品を出して勝つためには、生産性を高めて早く製品を作ることが大前提にある。
  • いくら綺麗な設計だったとしても、リリースまでに時間がかかって勝負の土俵にも上がれないようでは負けである。
  • ActiveRecordを使う場合、「そのシステムを3年くらい使ったら負け。すぐにポシャったら成功」


■ ドメイン層からインフラストラクチャ層を呼び出すのが自然?

■ 24.2.4 マジックビーンズのユニットテストは困難
  • テストについては、半年前くらいに話題になった「TDD is dead」が深く関わっている。(翻訳版 by やっとむ氏)
    • 「TDD is dead」は、「テストを考えることで良い設計になる」という本来のTDDの思想から離れてしまっている。
    • 手段が目的になっている。そうじゃなく、バランスを持った議論が必要。
  • DBのモックを作るのは負けパターン。
    • 最近はマシンスペックが上がっているので、DBを使ったテストをするのが良い。
    • ただ、それは2014年だから言える。原著が書かれた当時は、この手のネタが盛んだった。


■ 寿命が長い方を綺麗に
  • ビューよりも、データやURLのほうが寿命が長いので、きちんと設計をしないといけない。
  • その順序を間違えて、コードとモックの綺麗さばかりに引っ張られるのはダメ。
  • 基本的な考え方は、「寿命が長い方に寄せる」。


■ 「犠牲的アーキテクチャ」関連の考え方
  • Martin Fowler氏のブログで「犠牲的アーキテクチャ」という考えが紹介された。
  • 伊勢神宮も、20年に一度、建物を造り替える「式年遷宮」がある。
    • 大きなものはいつか死んで総崩れになるので、大きくなる前に分割して、寿命を分断する。
  • システムも同じで、ビジネスが軌道に乗り始めたからといって、早さ優先で開発した創業当時のコードをいつまでもコピペしていると死ぬ。
    • 最後まで生き残るのは「データ」と「データのインタフェース」。
    • コードは、その時その時のトレンドに合わせて、得意なものを使うべき。適材適所なアーキテクチャを採用する。
    • ただし、DBやWebのインタフェースとなるデータやURIは「約束事」なので、最後まで生き残らせないといけない。
    • ドメイン、データ、インタフェース。この3つは生き残らせないといけない。
    • パターンと実装を切り離せ。


■ 実装とパターン
  • 20年前は、「パターン ⇒ 実装」だった。パターンが先にあって、そこから実装例が出てきた。
  • 今は「実装 ⇒ パターン」の時代。最新のコードから、野生のパターンが出てくる。
  • そういう意味で、本が設計を引っ張る時代は終わった。
  • ActiveRecordは、「実装」が「パターン」を超えている例。

★感想:
奥野さんの25章を除けば実質最終章ということもあって、なかなか高度な内容を扱う章でした。
私もRailsのアクティブレコードは前述したRails勉強会で触った程度なんですが、初めて触れた時は、かなり異質に感じました。
そんなの特殊な状況でしか使えないじゃん、自分でDBアクセスのコード書けばいいじゃん、みたいな。
今回この章でいろいろ学んで、いろんな考え方があるんだなぁ、と再認識しました。

あと、 @t_wada さんの「本が設計を引っ張る時代は終わった」という言葉は重いです。。。
いつまでも本でINPUTばかりしてるようじゃダメですね~

あと、誤植っぽいところを @t_wada さんにチラッと報告したが、ここにもメモ書きしておく。
P.268のenterActionメソッドで、$accountTalbe変数が未使用。
P.268のdisplayActionメソッドで、$productTable変数が未使用。メソッド最終行の$bug変数も未定義。

残すは忘年会と、奥野さんの25章のみ。終わりが見えてきましたね。
参加者の皆様、ありがとーございました。


■おまけ:過去の「SQLアンチパターン読書会」ブログ

1章:SQLアンチパターン読書会 「ジェイウォーク」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-65.html

2章:SQLアンチパターン読書会 「ナイーブツリー」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-70.html

3章:SQLアンチパターン読書会 「IDリクワイアド」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-73.html

3章:SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-77.html

4章;SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-84.html

5章:SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-90.html

6章:SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-94.html

7章:SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-97.html

8章:SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-105.html

9章:SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-109.html

10章:SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-115.html

11章:SQLアンチパターン読書会 「ファントムファイル」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-118.html

12章:SQLアンチパターン読書会 「インデックスショットガン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-121.html

13章:SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-128.html

14章:SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-130.html

15章:SQLアンチパターン読書会 「ランダムセレクション」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-133.html

16章:SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-134.html

17章:SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-136.html

18章:SQLアンチパターン読書会 「インプリシットカラム」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-138.html

19章:SQLアンチパターン読書会 「リーダブルパスワード」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-140.html

20章:SQLアンチパターン読書会 「SQLインジェクション」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-144.html

21章:SQLアンチパターン読書会 「シュードキー:ニートフリーク(疑似キー潔癖症)」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-147.html

22章:SQLアンチパターン読書会 「シー・ノー・エビル(臭いものに蓋)」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-151.html

23章:SQLアンチパターン読書会 「ディプロマティック・イミュニティ(外交特権)」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-152.html

FC2Ad