各セッションの感想
Spring Security にできること・できないこと
opengl_8080 さん。セッション資料
Spring Security にできること・できないことが理由付きできれいにまとめられていました。
例えば
- Spring Security は ServletFilter を利用しているから、そこで対応できない脆弱性はそもそも対処しない（できない）
- セッションID自体の管理は Servlet の仕事なので、Spring Security は責任を持たない
などなど、とにかくとても明快でした。
あと、個人的に印象的だったのは、CSRF のチェックは（デフォルトでは）メソッドが GET, HEAD, TRACE, OPTIONS 以外 でしか行われないということ。
つまり Spring Sequrity 自身は、ちゃんと Web のお作法を守っているし、お作法を守っているアプリケーションのセキュリティは守るけど、守ってないアプリケーションは知らないよ、ってことですよね。そういうポリシーが見えて面白かった反面、見方を変えればお作法を守っていないとハマるってことだし不勉強だととても危ないってことなんですよね。
(2017-06-27 追記)
opengl_8080 さんから直々に
Twitter でご指摘をいただきまして、対象のメソッドは設定によって変更が可能ということと、とはいえメソッドを正しく実装することが推奨される旨がドキュメントに記載されているとのことです。
(2017-06-27 追記ここまで)
メソッドを適切に使い分けるというのは、今でこそ REST API とかの文脈があるから当たり前になりつつあるのではないかと思ってはいるのですが、昔はこんなこと平気でやったりしましたやん？
void doPost(req, resp) {
doGet(req, resp);
}
え、してない？
あと、会場が会場ということもあって言葉を濁されていましたが、（控えめに言って）edge は脆弱性の検証に使い勝手がよいということはわかりましたｗ
普段使いのDDD
haljikさん。セッション資料
DDD は全く勉強したことがなくて、まあ悪く言えば食わず嫌いの状態でした。別の勉強会で、DDD と同じく食わず嫌いだった TDD にリアルに触れられる機会があって、そこでいろんな気付きを得ることができたので、今なら素直に食わず嫌いせずに DDD も受け入れられるんじゃないかと思って今回このセッションを選びました。
そこで、個人的に今回一番衝撃的だった言葉に出会います。
『利用者が「ここ」を「こう」したいという要望に対して、「ここ」を「こう」するだけで変更できるようになっていれば良さそう』
『利用者のいう「ここ」をこうしたいの「ここ」がコード上のどこを指すのか？』
この話を聞いた時、本当に比喩でも誇張でもなく、ちょっとだけ涙腺が緩んだ。私にとってはそれくらい衝撃的でした。衝撃的すぎたので、恥ずかしながら何度もツイートしてしまった・・・。
現実に立ち返ると、よくない DB 設計の上によくないソースコードが載っかっていて、一つ直したら別のところがバグるなんてよくある話で、ソースコードのどこを触ればいいかなんて直感的にはわからなくて、それをどうにかこうにか繋いでいて（でもそもそも繋げられないどころか平気でぶち壊すような人もこの業界には腐るほどいて）みたいな絶望感があって・・・。
でも、たとえば DDD はそれを解決するためのヒントを持つもののうちのひとつであるのかも、という、光が見えたというか希望をもらったというか、そんな感情が私の涙腺を緩ませたのではないかって気がします。
でも、前提が「利用する言語は息をするように書けないとしんどい」って、もちろんそれで飯食ってるんだから当たり前といえば当たり前なんですけど、私自身ももちろんのこと、チームメンバー全体のレベルとか、この業界全体のレベルとかも含めて考えたらやっぱりきついよなー・・・。
Introduction to JShell: Official REPL Tool for Java Platform
吉田真也(@shinyafox)さん。セッション資料
OpenJDK のコミッタである吉田さん直々の JShell の解説。
IDE 上で main メソッド込みのテストクラス作ってテストコード書かなくてもよくなる！前方参照してくれるから、呼び出すクラス、メソッド、フィールドをあとから定義しても怒られない！これは便利。はやく Java9 でてくれー。しかし
Java9 は（うまくいけば）9月リリース
あと、API の仕組みはなんか面白いことできそうかもと思った。具体的になにをどうできそうかは全く見えてないけど。
それから
プラグインを「僕が作りました」
これ最強。
Kafkaを使ってイベントを中心にしたアプリケーションを作ってみる。Spring Cloudにのせて。
椎葉 光行(@bufferings)さん。セッション資料
本人が「ゆるーく話します。関ジャバなので。」って言ってたので、ゆるーく聞いてました。（うそ）
いや、正直なところは、私のスキルも興味の範疇も逸脱してるのでゆるーく聞くしかなかったんですが。（結局ゆるーく聞いている）
実装くらいは後でゆるーく読んでおきますです。
DevLOVE関西からギルドワークスへの越境
中村 洋(@yohhatu)さん。セッション資料
中村さんがDevLOVE関西の前説でいつも話されている話がとても深く広く掘り下げられていたという印象でした。
DevLOVE関西は素振りの場です、現場に持ち帰って実践しないと意味ないです、とか、そういう話に、今回の話によるDevLOVE関西の結成の経緯や継続の意味が乗ることによってより強く理解できたというか。
ただ参加するだけで満足していてはいけないし勉強会で得たものは具体的に生かしていかなければならないという思いを新たにすることができました。
具体的な内容としては、視座は高く持つ、でも高く持ち続けていると実装レベルにリーチ出来なくなるから降りていくことも大事、という話が一番印象的でしたね。
わたしなんかは、油断すると実装レベルに閉じこもろうとするから、それ以前の問題なんですけど・・・。
オフショア開発にも応用可能！？ リモートチームの道具箱
粕谷大輔(@daiksy)さん。セッション資料
結局、リモートは情報量が落ちてしまうリスクを、いろんな工夫や道具を使ったとしてもどうしても落ちてしまうから難しいということなんですかね・・・。
あと、結局はコミュニケーションを取ろうとする人自身の努力が当然ながら必要ということ。
感嘆符とかの大げさな感情表現の話なんかは、私も余裕があるときは心掛けているつもりですけど、感情が高ぶったり怒ったりしてしまったときほど表現に気を使う余裕がなくなっていて、残念ながら緩和が本当に必要になるべきときほど結局は冷たい表現になってしまいがちだったりします・・・。
全体の感想
とにかく勉強になったし、楽しかったし、快適に過ごせました。
改めて、スタッフの皆様、登壇者の皆様、参加者の皆様お疲れ様でした。ありがとうございました。
余談
私もそろそろ、登壇することを念頭に入れていくべきかなぁと思ったり思わなかったり。（登壇するとは言ってない）
