2014/11/28(金) 「RESTful#とは勉強会2」に参加してきました。
DoorKeeper
http://rubychildren.doorkeeper.jp/events/17514ちなみに私、ちょうど会社でRESTの必要性に迫られて、以下の書籍で独学している最中なのです。
この本は、JavaのRESTに関する仕様であるJAX-RSの本です。現在、読みながらちょとずつ写経中。
そんな私にとって、この勉強会はタイムリーなネタなのでした。
ちなみに前回も参加したかったんですが、他の勉強会と被ってしまって残念ながら行けなかったのでした。。。
なので今回が初参加。
この日は前半が「Webを支える技術」の読書会で、後半が @t_wada さんの講演でした。
とても参考になる勉強会だったので、当日のツイートをTogetterにも纏めてみました。
http://togetter.com/li/751922
■ 前半：「Webを支える技術」の読書会以下の書籍をターゲットに、テーブルごとに読書とディスカッションを行いました。
今回は5章「URIの設計」が対象範囲でした。
まずRESTを学んで驚いたのが、
URIを「設計する」という概念があることですね。
この章にも出てきますが、「Cool URIs don't change」（クールなURIは変わらない）とWebの発明者が論文で提唱してます。
あと、リダイレクトの仕組みを使ってURIの普遍性を維持する、というお話がありました。
これはちょうど職場で悩んでいた点だったので、とてもヒントになりました。
最後に質疑応答でAmazonのURLについて話がありましたが、これも興味深かったですねー
１つのリソースに複数のURLがある場合、<link rel="canonical">で代表URLを指定する、という仕組み、初めて知りました。
そしてAmazonでは、代表URLに敢えて長い、書籍名を含ませたURLを採用している点が興味深かったですね。
あと、同じリソースへのURLはできれば1種類がよい、というお話もありました。
■ 後半：「和田さんによるRESTfulな設計のお話・座談会千駄ヶ谷.rbで講演されたときの資料をベースとした講演です。
すごく参考になった。以下、個人メモ。
---
■ 結論：RESTは麻疹である- 良いものなので、早く感染して使いまくって、痛い目を見て卒業しましょう。
- 痛い目を見て、しばらく離れて、あとで戻ってくるくらいがちょうどいい。
■ URLに動詞が含まれていないか- まずレビューすのが、URLに動詞が含まれていないか、という点。
- RESTの世界は動詞は５つくらいあればいい。他の動詞はいらない。
- URLに「edit」が含まれる場合は、「まあいいか」とすることもある。規約による妥協、という考え。
- なるべく名詞に近づける努力をする。
- loginは動詞じゃね？と調べてみると、そもそも「login」という英語はなく、logとinの合成後だった。
■ URLが無理な構造になっていないか- 話し言葉みたいに読める、というのはURLにとっては大事でなはい。意味がわかることが大事。
- コピー元とコピー先に上下関係にない。
- レビュー時は、URLの右にいくに従ってサブセットになっているかを見る。
- URLの左に行くほど偉い、右にいくほど偉くない。
- URLの名前探しには英英辞典や類義語辞典が便利。いつも辞書と共に設計をする。
- リソースとリソースの関係を探す第三のリソースを探す。
- 自分が知ってる単語から始まって、自分の知らない単語にどう辿り着くかが大事になってくる。
- HTTPメソッドが４つじゃ足りないよ、とよく言われる。（例：購読する、とか４つでできないじゃないか！）
- そこでまず考えていくのが、「自分がやりたいことが、何かを消したり更新したり、といった４つのどれに該当するだろうか」と思考を持っていくこと。
- 例えば「購読する」なら、「subscription」を「作ろう」としている、と考える。
- 例えば「属する」なら、「belong」という関係を「作る」と考える。「作る」が「入社」で、「消す」が「退社」になる。
- といったふうに、CRUDでけっこう表現できる。この思考を結構頑張ることが大事。
■ URLの意味と意思- URLには、「意味を示す場所」と「意思を示す場所」がある。レビューではそれが混ざってないかを見ている。
- ?の前までは「リソースの意味」。?の後ろが「クライアントの意思」。
- ？以降をすべて取り去っても意味は変わらないか、?以前にリソースの意味と関係ない要素はないか、を見る。
- lang=jaとかは微妙で、グレーゾーン。
■ CRUDの重力に引かれていないか- Webの４つのメソッドがRailsの６つのメソッドに対応づいている。
- 第3正規形のテーブルと１：１のrouteがあるのは粒度が細かすぎて、n+1問題にも容易に突き当たる。
- DBだけでなく、Webでもこの問題が出てきてしまう。
- DBの世界の粒度とWebの粒度は同じではない。
- どうやって１：１と１：１じゃない世界を結びつけたらいいのか、はcontrollerの仕事。
■ ステータスコードの選択- そのリソースに対する操作がどうなったか、がWebの世界にはある。それがステータスコード。
- URL設計の壁を乗り越えていけば、ステータスコードも収束してくる。
- URL設計を頑張ると、その後は結構スイスイ行く。
- ステータスコードで障害の一時切り分けができる。
- 良くない設計は、ステータスコードを全部200で返して、レスポンスのJSONにエラーコードが入っている、とか。
- レスポンスの中を見ないと成功か失敗かが分からないし、コードの解釈も場面で変わるのでナンセンス。
- レスポンスの中身を見なくて、なにがどーなったかが分かる組みがWebにある。それがステータスコード。
- Railsはフレームワークまで例外が到達すると、ステータスコードに例外をマッピングして投げる。
- URLに含まれるのIDを１ずつズラしてアクセスしたり、アクセス権限がないけどリソースは存在、といった情報を知りたがる悪意に対処するために、ステータスコードをわざとズラして秘匿することがある。
■ 表現の設計- 返ってくるJSONにURLが含まれてない、といったことがないかをレビューで見る。
- URLがないと、そこで袋小路で止まり、それ以降、辿れなくなる。
- URLが分からないものに対してURLを提供する。
■ 持続性のある表現のために
- 行き止まりを作らないようにする。選んで遷移できるようにする。
- サービスから送られてくるURLを使うことによってのみ遷移できるように考えてください。
- リンクがすごい大事。サーバから帰ってきたリンクで遷移先を決められるようにすること。
■ よくある議論- 確認画面とかプレビュー画面のurlってどうやってるの？
- 階層構造だと、移動元と移動先、とか対等なものを表現するのに困るよね？
- 一部成功して一部失敗のときのレスポンスコードってどうするの？
- DBを移行して擬似キーのIDが変わったら、ぜんぶリンク切れになりました。。。
- クライアントかサーバか、どっちで処理するかは揺れる。フレームワークの種類によって大きく変わる。
- 時代はサーバである、クライアントである、と安易に言うのは思考停止でしかない。
- Twitterの @logout さんは、Twitter社は盲点だった。URLでログアウトしてしまう・・・
★感想：ちょと前にRESTを学び始めた初学者の私にとって、すげー参考になる勉強会でした。
REST、URI、奥深し・・・。
あと和田さん、あるときはTDDだったり、DBだったり、RESTだったりと、毎回、技術の引き出し凄すぎやで。
そして勉強会が次回もあるなら、是非参加したいなぁ、と思うのでした。
あと、「Webを支える技術」と「JavaによるRestfullシステム構築」の２冊も、きちんと読んで写経しないと・・・
皆様、ありがとーございました。
2014/11/25(火) SQLアンチパターン読書会 「マジックビーンズ(魔法の豆)」に参加してきました。
Doorkeeper
http://sqlap.doorkeeper.jp/events/17729以下の書籍をターゲットとした読書会なのです。
場所は前回同様、秋葉原のクラスメソッド株式会社さんでした。
参加者は9人かな。初参加は2人でした。
ちなみに今回はアクティブレコードがテーマの１つでもあったりするのですが、
「そういや以前、Railsの勉強会でアクティブレコードの章を担当した時にスライド作って発表したっけ・・・」
と思ってslideshare見てみたら、スライドのviewが37000を超えていてフイたｗ
HerokuではじめるRailsプログラミング入門 6-3節「複数モデルの連携」 by @makopi23
キャッチーなキーワードやタイトルに釣られてやって来る人が多いのかな・・・。
正直、スマンカッタ・・・
■ 発表今回は @a_suenami さんが発表担当でした。
DDDネタ、RailsのARの弊害などに言及しつつ深く考察されており、よく纏まっています。
DDDネタをよく発信されている増田さんからもコメントが。
■ ディスカッション今回もディスカッションしたいネタをみんなで付箋に書き出しました。
以下、個人メモ。
---
■ 24.2.1 アクティブレコードはモデルをデータベーススキーマに強く依存させてしまう- Railsでコードを自動生成するとフォームがモデルに乗ってくるので、ビューとDBが密結合になる。。。
- Railsの4から、モデルからフォームを除くことができるようになったらしい。
■ ActiveRecordとDataMapper- 両者ともMartin Fowlerの通称PofEAA本に登場するパターン。
- ActiveRecord
- アプリケーション側のモデル構造とDB側のテーブル構造を1:1対応させる」という割り切った特長を持っている。
- DataMapper
- アプリケーション側のモデル構造とDB側のテーブル構造をn:n対応とし、それらをマッピングさせる。
- ググッたところ、以下のサイトが参考になりそう。
- ActiveRecordとDataMapperの両方を使ってみて、どちらにするか自分で決めるのが良い。
■ JOINはActiveRecordとして許されるか- JOINも隠蔽したほうが良い。
- Railsの場合は、scopeというDSLの層を入れることで隠蔽に成功している。
- リポジトリパターンを使って避ける。
■ SQL vs ActiveRecord- DBアクセスをSQLを手で書く方が良いか、AcriveRecordに任せる方が良いかは、「生産性」と「平準化」が判断軸になる。
- 生産性
- 生産性なら、DBアクセスのSQLとコードを手で書くより、ActiveRecordを使ったほうが断然高い。
- 平準化
- 3年後に修正する場合にもActiveRecrodの方が早いかというと、保守性の観点からそんなことはない。。。
- 「いつ」を照準にするかでどちらが良いか、コンテキストが違ってくる。
- まず市場に早く製品を出して勝つためには、生産性を高めて早く製品を作ることが大前提にある。
- いくら綺麗な設計だったとしても、リリースまでに時間がかかって勝負の土俵にも上がれないようでは負けである。
- ActiveRecordを使う場合、「そのシステムを3年くらい使ったら負け。すぐにポシャったら成功」
■ ドメイン層からインフラストラクチャ層を呼び出すのが自然？- 以前はそうだったが、最近はAlistair Cockburn の「ヘキサゴンアーキテクチャ」が多くなっている。
- ドメインとDBの間にパーシステンス層がいて、ドメインはパーシステンス層のことを知らないほうが良いとされる。
- DBアクセスは、引数にPOJOを渡して「あとはお任せします」的なアクセスとなる。(モデルとDBを疎にする）
- ヘキサゴンアーキテクチャの参考文献
■ 24.2.4 マジックビーンズのユニットテストは困難- テストについては、半年前くらいに話題になった「TDD is dead」が深く関わっている。（翻訳版 by やっとむ氏）
- 「TDD is dead」は、「テストを考えることで良い設計になる」という本来のTDDの思想から離れてしまっている。
- 手段が目的になっている。そうじゃなく、バランスを持った議論が必要。
- DBのモックを作るのは負けパターン。
- 最近はマシンスペックが上がっているので、DBを使ったテストをするのが良い。
- ただ、それは2014年だから言える。原著が書かれた当時は、この手のネタが盛んだった。
■ 寿命が長い方を綺麗に- ビューよりも、データやURLのほうが寿命が長いので、きちんと設計をしないといけない。
- その順序を間違えて、コードとモックの綺麗さばかりに引っ張られるのはダメ。
- 基本的な考え方は、「寿命が長い方に寄せる」。
■ 「犠牲的アーキテクチャ」関連の考え方- Martin Fowler氏のブログで「犠牲的アーキテクチャ」という考えが紹介された。
- 伊勢神宮も、20年に一度、建物を造り替える「式年遷宮」がある。
- 大きなものはいつか死んで総崩れになるので、大きくなる前に分割して、寿命を分断する。
- システムも同じで、ビジネスが軌道に乗り始めたからといって、早さ優先で開発した創業当時のコードをいつまでもコピペしていると死ぬ。
- 最後まで生き残るのは「データ」と「データのインタフェース」。
- コードは、その時その時のトレンドに合わせて、得意なものを使うべき。適材適所なアーキテクチャを採用する。
- ただし、DBやWebのインタフェースとなるデータやURIは「約束事」なので、最後まで生き残らせないといけない。
- ドメイン、データ、インタフェース。この３つは生き残らせないといけない。
- パターンと実装を切り離せ。
■ 実装とパターン- 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.html2章：SQLアンチパターン読書会 「ナイーブツリー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-70.html3章：SQLアンチパターン読書会 「IDリクワイアド」に参加しました
http://makopi23.blog.fc2.com/blog-entry-73.html3章：SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-77.html4章；SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-84.html5章：SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-90.html6章：SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-94.html7章：SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
http://makopi23.blog.fc2.com/blog-entry-97.html8章：SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-105.html9章：SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-109.html10章：SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-115.html11章：SQLアンチパターン読書会 「ファントムファイル」に参加しました
http://makopi23.blog.fc2.com/blog-entry-118.html12章：SQLアンチパターン読書会 「インデックスショットガン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-121.html13章：SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-128.html14章：SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
http://makopi23.blog.fc2.com/blog-entry-130.html15章：SQLアンチパターン読書会 「ランダムセレクション」に参加しました
http://makopi23.blog.fc2.com/blog-entry-133.html16章：SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-134.html17章：SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました
http://makopi23.blog.fc2.com/blog-entry-136.html18章：SQLアンチパターン読書会 「インプリシットカラム」に参加しました
http://makopi23.blog.fc2.com/blog-entry-138.html19章：SQLアンチパターン読書会 「リーダブルパスワード」に参加しました
http://makopi23.blog.fc2.com/blog-entry-140.html20章：SQLアンチパターン読書会 「SQLインジェクション」に参加しました
http://makopi23.blog.fc2.com/blog-entry-144.html21章：SQLアンチパターン読書会 「シュードキー：ニートフリーク(疑似キー潔癖症)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-147.html22章：SQLアンチパターン読書会 「シー・ノー・エビル(臭いものに蓋)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-151.html23章：SQLアンチパターン読書会 「ディプロマティック・イミュニティ(外交特権)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-152.html
2014/10/27（月） SQLアンチパターン読書会 「ディプロマティック・イミュニティ(外交特権)」に参加してきました。
Doorkeeper
http://sqlap.doorkeeper.jp/events/16740以下の書籍をターゲットとした読書会なのです。
場所は前回同様、秋葉原のクラスメソッド株式会社さんでした。
参加者は１１人かな。
今回は冒頭で、@t_wada さんから素敵なサプライズが！
感謝！私の他に、@meijik さんも戴きました。
■ 発表今回は @setoazusa さんが発表担当でした。
この発表の真髄はデモにありました。デモで紹介してくださった各種情報はこちら～
・MyBatis Migrations
http://mybatis.github.io/migrations/・SchemaSpy
http://schemaspy.sourceforge.net/・CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化
(※SchemaSpyについて発表した時のスライド)
http://www.slideshare.net/setoazusa/schema-spypublic・上記スライドのデモ用レポジトリ
https://github.com/azusa/schemaspy-demo・SchemaSpyで出力するドキュメントのサンプル
http://azusa.github.io/schemaspy-demo/schema/index.html各種ツールや環境は、git cloneですべて取得できるよう、１つのリポジトリにすべて入れているとのことでした。
■ ディスカッション今回もディスカッションしたいネタをみんなで付箋に書き出しました。
以下、個人メモ。
---
■DBマイグレーション
■ 読書会参加者のうち、DBマイグレーションツールを使ってる人の割合- 使ってる： ６人 使ってない： ５人
- 使ってる人の意見： 「無いと話にならない」、「使わないと怖くて仕方がない」等
■ DSL型 vs SQL型
■ DBマイグレーションのTIPS
■ DBマイグレーションの可逆性と不可逆性
■ DDLのロールバック
- DDLのロールバックが可能なDBMSは以下。
- PostgreSQL
- SQLServer
- DB2
- Firebird
- DDLのロールバックができないDBMSは以下。
■ DB設計のドキュメント化- 最近はマイグレーションが主だが、大規模プロジェクトではER図が主で、ER図からDDLを生成することが多い。
- ER図からテーブル定義書を出力して、それに追記すると、ER図とテーブル定義書の同期が取れなくなってくる。。。
- Excelの設計書とは別に、ER図やDDLにはコメントを入れましょう。
■ SIerにありがちな「JOIN禁止令」- SQLチューニングのオプティマイザには「ルールベース」と「コストベース」の２種類がある。
- コストベースの場合、JOINするとアクセスパスが悪い方に倒れることがあり、バッチ突き抜けなどが生じることがあった。
- JOINを禁止するとアクセスパスがシンプルになるので、遅くても、処理時間が見積もれるようになる。
- でもオンライン処理は、大量データによるバッチ突き抜けとは別次元なので、JOIN禁止は合わないことが多い。
- 最近は理由も知らずに「JOIN禁止」と言う人が多くて困る。。。
■ DBマイグレーションの利点と欠点- 利点： DBの整合性が合う。
- 欠点： データと設計が混ざって、よくわからなくなる。。。
■ DBマイグレーションの粒度- 粒度は細かい方がいいとは限らず、機能追加の粒度と合わせるのが一般的。
- 一番最初のマイグレーションは、粒度が大きい。
- MyBatisは１トランザクションが１マイグレーションになる。
★感想：ちょうどこの読書会の当日、DBのバージョン管理に関する議論が会社であって、ピンポイントなテーマでした。
以前、データベースリファクタリング読書会に参加したときは、DBマイグレーションツールはほとんど無い、というお話を聞きましたが、この日のディスカッションを通じて、ここ数年でずいぶん改善されてきたように感じました。
ちなみにそんときの読書会について書いたブログはこちら。
やっぱ、最近はDevOpsやらアジャイルやらテスト自動化やら、DBマイグレーションの思想が必要となる場面がだいぶ増えた気がします。
私は仕事でDBマイグレーションツールを使ったことがないので、今日のテーマは斬新でとても参考になりました。
参加者の皆様、会場提供のクラスメソッド様、ありがとうございました。
■おまけ：過去の「SQLアンチパターン読書会」ブログ1章：SQLアンチパターン読書会 「ジェイウォーク」に参加しました
http://makopi23.blog.fc2.com/blog-entry-65.html2章：SQLアンチパターン読書会 「ナイーブツリー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-70.html3章：SQLアンチパターン読書会 「IDリクワイアド」に参加しました
http://makopi23.blog.fc2.com/blog-entry-73.html3章：SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-77.html4章；SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-84.html5章：SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-90.html6章：SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-94.html7章：SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
http://makopi23.blog.fc2.com/blog-entry-97.html8章：SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-105.html9章：SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-109.html10章：SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-115.html11章：SQLアンチパターン読書会 「ファントムファイル」に参加しました
http://makopi23.blog.fc2.com/blog-entry-118.html12章：SQLアンチパターン読書会 「インデックスショットガン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-121.html13章：SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-128.html14章：SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
http://makopi23.blog.fc2.com/blog-entry-130.html15章：SQLアンチパターン読書会 「ランダムセレクション」に参加しました
http://makopi23.blog.fc2.com/blog-entry-133.html16章：SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-134.html17章：SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました
http://makopi23.blog.fc2.com/blog-entry-136.html18章：SQLアンチパターン読書会 「インプリシットカラム」に参加しました
http://makopi23.blog.fc2.com/blog-entry-138.html19章：SQLアンチパターン読書会 「リーダブルパスワード」に参加しました
http://makopi23.blog.fc2.com/blog-entry-140.html20章：SQLアンチパターン読書会 「SQLインジェクション」に参加しました
http://makopi23.blog.fc2.com/blog-entry-144.html21章：SQLアンチパターン読書会 「シュードキー：ニートフリーク(疑似キー潔癖症)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-147.html22章：SQLアンチパターン読書会 「シー・ノー・エビル(臭いものに蓋)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-151.html
