2015/8/22(土) 「最終回 システムテスト自動化 標準ガイド 読書会」に参加してきました。
全４回、皆勤でした。書籍の第１部のうち、普遍的な概念を扱う１章～９章がターゲットでした。
今回が最終回ということで、これまでの発表スライドを纏めてみる。
■第一回 システムテスト自動化 標準ガイド 読書会http://software-test-automation.connpass.com/event/13255/第1章 テスト自動化のコンテキスト2015/04/18, ふじさわゆうき さん
[参考文献]
参加者で訳者でもある森さんが書いた記事。
『システムテスト自動化 標準ガイド』の第1章で響いたところ、原著が刊行された15年前から進んだところ
http://codezine.jp/article/detail/8527第2章 キャプチャーリプレイはテスト自動化ではない2015/04/18, いしじあつし さん
[参考ブログ]
ブロッコリーのブログ 『第一回 システムテスト自動化 標準ガイド 読書会』の司会をしました■第二回 システムテスト自動化 標準ガイド 読書会http://software-test-automation.connpass.com/event/14313/第3章 スクリプティングの技法2015/05/23, @TakaakiOnoさん, @d_noguchiさん, @camxxmaさん
第4章 自動比較2015/05/23, @toku_toku3
[参考ブログ]
「第二回 システムテスト自動化 標準ガイド 読書会」を開催してきた ふじさわゆうきさん
ブロッコリーのブログ 第二回システムテスト自動化標準ガイド読書会で司会をしました＆第三回で発表します■第三回 システムテスト自動化 標準ガイド 読書会http://software-test-automation.connpass.com/event/15691/ 第5章 テストウェアアーキテクチャ 2015/07/05, @masatoshiitohさん
第6章 前処理と後処理の自動化2015/07/05, @nihonbusonさん
第7章 保守性の高いテストを構築する2015/07/05, @nihonbusonさん
[参考ブログ]
ブロッコリーのブログ 第三回システムテスト自動化標準ガイド読書会で発表して司会もしました■最終回 システムテスト自動化 標準ガイド 読書会http://software-test-automation.connpass.com/event/17862/第8章 メトリクス2015/08/22, @_mirerさん
第9章 その他の課題2015/08/22
■感想：運営のみなさんがとても気配りされていて、とてもよい勉強会でした。
１章に１時間以上割いて、ディスカッションや質疑応答もほどよく交えての進行でした。
読書会ないかなぁ、と以前呟いたこのツイートも、この読書会のおかげで成就されたのでした。感謝！
皆様、ありがとうございました。
2015/8/19(水) 「RESTful#とは勉強会9」に参加してきました。
DoorKeeper
https://rubychildren.doorkeeper.jp/events/29117最近ブログをサボリ気味なので、負荷にならない程度の書きっぷりで、復習のために今後もできるだけ書いていこうと思います。
この日の会場は永和システムマネジメントさんです。
前半はいつもどおり「Webを支える技術」の読書会、後半はRestfulに関する講演、という二段構成でした。
山本 陽平
技術評論社
売り上げランキング: 5,348
進行役の川村さんが纏めてくださった、この日のポイントはこちら。
https://gist.github.com/tkawa/cf6f0187a5f1d54344b6いつもありがとうございます。
■Accept-Charsetヘッダ前回のディスカッションでも、ブラウザが自動で付与する、という話が出てました。ブラウザの設定で切り替えられるようです。
クライアントアプリを作る場合、HttpClientはOSが提供しているAPIを使って、OSの言語設定を判定して表示を切り替えている、という話もテーブルで出ました。
HttpClientはOSごとに用意されることが一般的だそうです。
■チャンク転送このチャンク転送が、本を読んだだけではよくわからず、テーブルでディスカッションしました。しかしいまだによくわからん・・・
HTTPのセッションは貼られたまま、ずっとデータが送られる？
次回、質問してみよう・・・
■認証ここも自分があまり理解していない部分。
まず、現在の一般的な認証方法は、サーバがトークンを発行して、それをクライアントとやりとりして認証する方法らしい。
OAuth2は一度トークンを発行したら変わらないらしい。そのため、httpsが全体なのだとか。
あと、認証が必要なサイトに未認証でアクセスがあった場合、ステータスコード401を返すようです。
OAuthは秘密キーを発行して、信頼しているサービスにしか渡さない仕組みらしく、信頼できないと後から判断した場合はその秘密キーを停止することができるそうです。
この辺の認証まわりはちゃんと勉強せなあかんなー、と思った次第。
次は@moro さんによる講演。
発表者の @moro さんがこの講演について書いたブログはこちら。
http://moro.hatenablog.com/entry/2015/08/20/081131
以下、個人メモ。
■ グランドルールRESTfulはマスタメンテぐらいにしか使えないようなものではない！という点を主張されてました。
私、RESTfulを勉強しはじめたばっかなので、世間ではそういう認識が一般的なのかー、と驚きました。
■ DBのイベントエンティティ起点POST /groups/42/menberships
これは、あるグループにjoinする、という操作ではなく、参加しているグループとメンバーシップの関連を作る、と考える。
■ メンバリソースの起点例えば、下書きモードから公開モードにしたい、という場合は、
POST /articles/42/set_public ではなく、setの先を名詞形にして、「作成する」という概念を持ち込む。
POST /articles/42//publication
■ ポイントRESTの世界観に統一することが大事。
リソースは、ユーザの役立つ単位とすること。DBの１テーブルにこだわらなくても良い。
■ Regist問題registという英単語はない。名詞も動詞もregister。リソースの命名でよくハマる。
■ リソース設計における乖離リソース設計を詰めていくと、createする、とか、人間同士の会話の概念と乖離することが多い。
例えば人間同士なら動詞で表現するところを、名詞ベースで考えたりとか。
⇒ これは、間に一回設計を挟む、と考える。設計として、動詞を名詞に置き換える、という作業を行う。
■ 感想：今回も新しい学びが多くて大変有意義でした。
２本立ては良いですね。マンネリ化しなくて済むし、深堀できるし。講演、とても勉強になりました。
皆様、ありがとうございました。
