YAPC::Asia Tokyo 2015

今年も行ってきました、ということで。

前回の感想エントリでは門外漢が行くべきかどうだかな〜と思っていたのだけど、いざ参加募集が始まったら迷ったものの結局行くことにした。前夜祭から参加。

Day 0

聞いたのは以下のトーク

PHP帝国の逆襲！（を願うPHPerが話す最近のPHPについてのクイックツアー PHP7対応版）

Yet Another Perl Conference の口火をきるのがPHPとRubyのトークというのがやはりここのところのYAPC::Asiaらしさなのかな。 多分 uzulla さんのトークを聞いたのは初めてなんだけど前年ベストトーク賞を取っているだけあってどんどん会場をあっためていくのはさすがとしか。 しかし内容はだいぶ濃かった。もともと長い枠向けに書いていたのか？かなりボリュームがある内容をどんどん喋っていくので、PHPに関してはせいぜいにわかというレベルの自分には途中まったくわからない点などもちらほら。

とはいえたまにPHPの案件などもあったりするのでPHP7情報は今後役に立ちそう。

はてなブックマークのトピックページの裏側

はてなブックマーク１０周年おめでとう御座います。

ということで１０周年の企画として作ったというトピックページの裏側がどうなっているかという話。意外と「これとこれとこれを使えばできる」というような話で随分簡単なんだなという印象。（まあ実際にはいろいろ困難もあるのだろうけど）

最近 elasticsearch をいじっているので自分の作っているもので使えそうかな〜と考えながら聞けた。

技術ブログを書くことについて語るときに僕の語ること

どうやればブクマを稼げるか、というところから話が始まった。個人的にここのブログにはどういったことを書いたものだかなというのはしばしば悩んでいるんだけど、あまりそういう悩みの参考にはならないかな、という雰囲気だった。

ただ最終的には

• 良いエントリを書くにはそれなりに時間も知見も必要になる
• 時間や知見が必要になるエントリを書くにはエネルギーが必要。
• エネルギーを得るためにブクマ（まあブクマじゃなくてもいいけど）を稼がねばならない

とうまくまとめられてしまった感じ。 ちまちまネットで調べたことを書き綴っても仕方ないというのは確かにそう思うんだよな〜。

Day 1

なぜだか 10:00 開場と感違いしていて 10:10頃到着。 オープニングトーク聞きたかったのだが失敗。

メリークリスマス！！

ラリーの英語トークだったんだけど、同時通訳のレシーバ売り切れだったのかもらえず、そのまま入ったのでとりあえず通訳なしで聞いてた。ホビットの話をしてたのはともかく、まあ全体的には細かい話がよくわからなかった。残念。

Perlの大将いい声で喋るな〜と思って眺めていた。

DeepLearning の前に知っておくことがある！ 再帰型のニューラルネットワークや自己組織化マップについて語ろう

ニューラルネットワークの経緯的な話から始まってだいぶ頑張ってい急いで喋っていたのだけど、時間が足りずに全て説明仕切れていなかった感。今回聞いたトークでは割と多かったんだけど、説明がやたら早かった。

個人的には全然この辺の分野は知らないものの経緯的なところはなんとなく聞いたことはあって、逆にちょっと突っ込んだ話になると全くわからなかった。 ただ質疑応答の時間には全くよくわからない会話がされていたので、分かる人には分かる内容だったのだろう。

TBD

Rubyの大将のお話。

トークの導入でRubyを封印しますといってやっぱ封印解きますといった話の流れとか結構慣れた感じで全編面白おかしく聞くことができた。 すでにいろいろなところで書かれているけどRubyのまずかったところとして「Perlの影響を受けすぎた」「Lispの影響を受けすぎた」といったことをあげてた。けどまあ質疑応答でRubyのほとんどは正しいはずとも言い直していて結局どっちなのか感はある。

Rubyはほとんど書かないけど個人的にRubyの嫌いなところはto_sとか。短くしたいにしても中途半端な対応に見える。まあどうでもいいか。

後半Streemの話だったけど、パイプラインを構成して一向という２フェーズある感じが、わかりやすいのは間違いないのだけどなにかもやもやする。普通のソフトウェアなら設定とコードに分かれるような感じがあるからかな。

Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜

ベストトーク賞１位おめでとうございます。

はてなのサービスの内側の概要と、はてなブログを作るにあたってどういった設計を採っているかという話。途中幾つか書籍が引用されてて「最高」とのことなんだけど、喋ってる内容としては（十数年Webシステムを作っては壊ししている身としては）特に新しさはない感じではある。まあ結局こうなるのかというような。 しかしこういった現在の着地点を確認できるトークは安心して聞けるし、自分のやってきたことの振り返りになって良い。

ドメイン駆動設計はどうなんだろう？まあユビキタス言語等個別プラクティスそれぞれについていろいろあるが、個人的にはここ10年でさすがに無理が出てきていたり、時代にそぐわない部分が出てきているように感じている。

PietでLISP処理系を書くのは難しい

Pietってそもそも何か知らなくて、トークが始まる前の休憩時間にググってみたんだけどビットマップをインプットとして解釈する言語らしい。ただいろいろ制約が多くて（ただでさえビットマップを書くのが大変そうなのに）もう辛くて辛くて仕方ない、みたいな話だった。

ただのもの好きがやる事かと思ってたら質疑応答の時間にPiet処理系いじった経験のある人が出てきたりガチLISPerがそんなんじゃ困るみたいな意見を申し立てていて面白かった。

発表はちょっと準備不足感があって、トークの途中で出てきたURLとかちゃんと共有されるのか不安。

Perl6 on JVM: It works??

Perl6のサブセットというのかミニマルセットというのか、nqp(Not Quite Perl)というものが定められていて、nqpが動けば、そこでPerl6を動かすことができるということで、今のところParrot、More-VM、rakudo-startという3種のVMが開発中。で、以前はだいぶ遅かったんだけど、ここのところだいぶ早くなってきて実用的ですね！という話。 多分 nqp と rakudo の話はだいぶ前のrebuild.fmでtokuhiromさん出演回でも話をしていたのでその辺はなんとなく知っていたんだけど、インストールもだいぶ簡単にできるように整えられていますよ、というのは初めて聞いた。

スレッドに関してはJVM上で動いているrakudoはだいぶましだけどMore-VMでは動くけど思った風には動いてくれないということを言っていたので、まだ前途多難なのかもな～。

Lightning Talks Day 1

LTに関しては一言づつ

• 日本最多のオフィス訪問シリーズ 「行ってきたシリーズ」のTOP5＋αとして日本のイケてるオフィスを紹介しちゃうよ！
  • マイクロソフトオフィス（製品ではない）のPVが高いとのこと。あとISUCONのCMが半分
• Gitの作り方
  • 意外とお手製でやれるという話。
• SaaSを組み合わせて作る, ぼくらの障害対応術!
  • デモ中にガチ通知飛んできて最高
• cpm - an experimental cpan client
  • 依存解決を並行処理して最高
• Norikraで作るPHPの例外検出システム
  • システムでカバーしなければキャッチできない例外がPHPにはあるんです！
• RSSをざっくりクロールしてゆるふわにパースする
  • 結構複雑なユーザ入力の検証なんかでよく出てくる問題。あまりがちがちにやるといい感じに処理できないという。
• Slack + Hubot でお前の一番好きな二次元嫁キャラと一緒に仕事をする
  • 別の方面でも一度聞いたことがある話の気がする。なんでこういうのSlackがいいんだろうか。やってることはバッチとかシェルスクリプトのような気がせんでもないんだけど。
• YAPC?雨事情
  • 今は北陸で働いているんだけど、確かにオフィスビルで仕事してた時代は本当に外に出るまで雨とか気にしない事が多かった気がする。窓の外を眺めさえすればいいはずなんだけど。
• Haskell Strikes Back
• (昔の) PHP が誇った最高の機能 register_globals の真実、そして未来へ
  • マニュアル「その結果に驚くことでしょう」
  • 「ちゃんとかけ」
• Perl同人活動報告2015
  • レスペーパー化の時代にワープロであるところのMicrosoft Wordなんて不要になったんじゃと思ったけど意外と需要が生き残ってた

Day 2

どうしてこうなった？ Node.jsとio.jsの分裂と統合の行方。これからどう進化していくのか？

個人的にはNode.jsでアプリケーションを書くことはないんだけど、フロントエンドのビルド環境としては度々使うので、まあ若干の不安があったので聴講。 コミュニティリーダーの交代とロールモデルの変遷について話していて、なかなか興味深かった。ほかのプロダクトなんかではどうなっているのか興味ある。Javaだと支配者がいたとしたら James Goslin だろうか。結構早い段階からJCPが成立していたような気がするけど。 取り合えず今後の使用に関しては問題ないのかな～という感触を得たけど、まあ先のことなんてわからないしな。

NASA主催の世界最大級ハッカソンSpaceAppsを運営した話

発表者の湯村さんは別の筋で見かけたことがあったので、リアル湯村さんを見に聴講。

SpaceAppsというハッカソンの運営は以前からやっていたのだけど、今回石川に住まいを移したのでリモートでの運営ということでいろいろ苦労したとのこと。Google Hangoutsを使ってたくらいの説明しかなかったと思うんだけど、個人的に今の仕事もいろいろチームが分散して作業することが多いのでその辺もっと突っ込んで聞いておけばよかったかも。

アイディアソンにはそれ専門の人を呼んでるといってたな～。どんなことをしているかも軽く話してくれてたけど、それでうまくいくのかどうかまったくわからないので何とも。

3分でサービスのOSを入れ替える技術

正直インフラ屋ではないものの、最近ちょいちょい手を出し始めているので興味があったので聴講。

インフラの現場がわかっていればいろいろ納得感があったのかもしれないけど、rebuild.fm で聞いたような単語がしっかり出てくるなーというような感覚で聞いてた。時系列で問題を順次解決していくような形で説明されてて内容はとてもわかり易かった。 SSHみたいな何でもできるみたいな手段は極力封じておいたほうがイノベーションが進む、みたいな考え方がでてきたんだけど、現場で初めからそのように思い至って進めたんだろうか。後から振り返ったらそうなってたというのならわかる気はするのだけど、そうでなければ自分ではそんな発想には至れなさそうだ。ただまあ、SSHが使えるようになるところまでも若干しんどいと思われるので、そのしんどいところを超えてしまえるのならSSHに頼らなくてもいいかも、とは考えられるのかな。

最後のBlue Green Deploymentのところはやはりストレージまでは対応できていないということで、その辺の「現状ここまで」感がわかったのもよかった。

ソーシャルゲームにおける AWS 移行事例

個人的に社内のあれやこれやをいい加減AWSでやれないのか、と思い始めていたので聴講。

移行時間を短くするためにいろいろ調べていて、実際に自分でやるときにも使えそうかもな～という感じで聞いていた。 MySQLに関してだいぶいろいろやっていて、今思い返してみるとこれらの問題はどうやって検出したんだろう？移行期間は手順をChef化したりRDSの検証をやったりで約一か月間くらいらしい。割となんども移行してみてテストしてを繰り返したのかな。

yrmcds って初めて聞いたなーと思ったら、Garoonのバックエンドなのか。

developer.cybozu.co.jp

あと一つ上のトークでも出てきたけど、結構Consulが今回のYAPCでは頻出ワードだったみたい。まったくマークしていないのでちょっと手を動かしてみておくかなあ。

HTTP2 時代の Web

ベストスピーカー賞2位おめでとうございます。

mozaic.fm とどのくらい違うんだろうなどと思いながら聴講。

HTTP2を理解した上で移行しないのもありと話しながらも、言いたいこととしてはHTTP2使っていこうぜということだったんだろう。 多分個人的にはそんなに高トラフィックの対応を要求されることも多くないのでさして差し迫って必要という感覚ではないし、インフラがいつの間にか対応してたところに乗っかっていけるといいなくらい。ちょっと気になるとすれば、HTTPS化かなあ。

Lightning Talks Day 2

• MySQL 5.7の罠があなたを狙っている
  • すごく面白かったし、役に立ちそうな情報が満載だった。個人的にはPostgreSQL派なので、MySQLは使わないかもしれないけど。
• 吉祥寺.pmというイベントを作った話〜聞きたいトークが有れば自分でイベントを作ろう！〜
  • 勉強会毎回遠いよね。遠い遠い。
• 命名の話をします
  • なんだかイマイチ落としきれていない感じだったけど
• botになる技術
  • コンテンツ力が極まるとBotになれる
• モダンなクライアントサイド JavaScript に追い付くためのための小さな（しかし大変な）一歩の話
  • あるある
• Evaluating your stylesheets
  • Naoya 最高！
• Thank you for ${^ENCODING} variable
  • perl 最高！
• 本物の "ロック" ってやつを魅せてあげますよ - 分散排他ロック篇
  • 高信頼で高可用性で伝統も実績もある電話最高！
• コミュ力あげてこ
  • 電話より伝統も実績もあるモールス最高！絶対やると思ってたけど
• CONBUの道具箱
  • デモが圧巻でした
• Vim script静的解析の光と闇
  • ざわざわ落とさなくても闇しかないと思ってた

The END

このエントリはさっき一度間違って公開してしまったんだけど、yuuki氏のアドバイスに従って予約投稿により平日にポストするとしようと思います。逆に被って埋もれてしまうかな。ま、それはさておき。

今回を以てYAPC::Asiaはいったん終了するとのことで、自分が参加したのは去年の今年の二回だけだったんだけど、今回も非常に楽しめました。

運営の方々、スピーカーの方々、参加者の方々、お疲れ様でした。ありがとうございました。

まだWSHで消耗してる

var shell = new ActiveXObject('WScript.Shell');
shell.run('java -version' , 0, true );

これを実行するとどういうわけか

Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

fatal: Not a git repository (or any of the parent directories): .git
C:\test\test.js(2, 1) (null): エラーを特定できません

なぜ Git が・・・・。

ちなみに java ではなく notepad とかなら問題ない。Javaが何かしてんのかなあ。

var shell = new ActiveXObject('WScript.Shell');
shell.run('cmd /c java -version' , 0, true );

これならいける。

PSQLException: ERROR: キャッシュした計画は結果型を変更してはなりません

PSQLException: ERROR: キャッシュした計画は結果型を変更してはなりません

— もぐら㌠ (@carrotsword) July 27, 2015

なんなんこれ

— もぐら㌠ (@carrotsword) July 27, 2015

intra-mart Accel Platform のテナント環境セットアップやってる途中に こういうエラーでて進まなくなることがあったのだけど、Google先生で調べてみてもどうもリリース元のエラーメッセージの国際化関連のリソースか何かが出てくるだけでこれが一体なにを意味しているのかさっぱりわからない。 いろいろいじくり回してみたところおそらく、アプリケーションサーバ側の要求するコネクションか、PreparedStatementの数にPostgreSQL側がついていけないということみたい。

この「ついていけない」が具体的にどういう値がどうでってのは、結局のところ理解してない。

iAP側のmax-connectionとかprepared-statement-cacheとかの数を下げたところ問題なくテナント環境セットアップを完走したので、まあそういうことなんだろうというフワッとした知見を得た、という話。

追記 2016-04-11

PotgreSQLのprepared-statement-cacheの設定の仕方がPostgresql Driver, Version 9.4-1202 以降変更になっているらしい。

resin-web設定 — 設定ファイルリファレンス   第13版 2016-04-01   intra-mart Accel Platform

あとこの話は当然Oracleでも同様シチュエーションで同様の現象が発生する。

分散環境を構築する場合は時刻を同期する

まあ当たり前の話なんだけども。

つまり時刻がずれている場合にどういうエラーになるかという話。

時刻のずれたサーバでResinを2台に構築してintramart Accel Platformをデプロイし、起動したら以下のメッセージがログに延々と出力された(xxx.xxx.xxx.xxx:nnnはIPアドレスとポート番号)

（Resin1側）

[INFO] j.c.i.s.j.q.JobStoreMirageSession - [] ClusterManager: Scanning for instance "intra-martAPP:xxx.xxx.xxx.xxx:nnn"'s failed in-progress jobs.

（Resin2側）

[WARN] j.c.i.s.j.q.JobStoreMirageSession - [] This scheduler instance (intra-martAPP:xxx.xxx.xxx.xxx:nnn) is still active but was recovered by another instance in the cluster. This may cause inconsistent behavior.

何が起こっているのか良くわからなくていろいろ検索してみたけど、（Quartz Scheduler関係で時刻がずれているらしいエラーということはわかるのだけど）クラス名で引いてもどうもはっきりした情報にたどり着けず、誰かがGoogleのインデックスに載せないといけないと思ったのでとりあえず貼り付けておくものです。

再起動したらOracleが上がってこない・・・。

Cent OS 6.5 にインストールしていた Oracle 11g xe が再起動後復帰しない。

なんだかごたごたやったので経緯をめも。

VMを一度落として再起動したらOracleのインスタンスが起動していない

1. そもそも XE ってどうやって起動するんだっけと思っていたら initd で管理しているみたいだったので、おもむろにservice oracle-xe status とやってみる。その結果に起動しているサービスが表示されるようなんだけど、いくつか起動しているのがいいるみたいだけどDBのインスタンスがない。
2. Oracleのインスタンスって概念よく理解してないんだけど、「Oracle インスタンス 起動」とかでぐぐって出てきた方法でやってみようとするも、接続するだけでなにやらエラーをはく。確かストレージがいっぱいで監査ログが吐けないみたいな感じ。

ディスクが足りない

1. df とか打って見ると使用率 100% なんで、仕方ないディスク拡張するかとなる
2. vmware esxi 上で動いているものなので、esxiの管理画面上からディスクを増やす。しかしOS内から見て増えているわけではない。当然パーティションを拡張する必要がある。
3. LVMとかいうので近頃は楽になってるんじゃないの？ということでやり方を探す。手順的には以下のようになるらしい
   • fdiskでLinux LVM の 追加パーティションをきる
   • LVMの物理ボリュームを上記のパーティションに作成する
   • 現在使用している論理ボリュームのボリュームグループに上記のボリュームを追加する
   • これで論理ボリュームは増えるので、ファイルシステムを増えたサイズに合わせて拡張する

まあ何とかなった

Oracleのユーザのパスワード期限が切れているとか言われる

1. いつもSQL Develoer使っているんだけど、突然「200日以上前にsystemのパスワード有効期限切れてるぞ」といわれる。SQL Develoerからは変更させてくれないっぽい。多分前から切れてたんだろうけどなんでこのタイミングで怒られるのかはわからない。
2. Application Express（Webから各種管理できるやつ）がなぜか起動できない・あるはリモートからアクセスできない
3. 仕方ないのでターミナルでログインして、ORALCE_HOMEやらORACLE_SIDやらの環境変数を設定してsqlplusでログイン
4. めでたくパスワード変更完了

で

多分パスワードの有効期限はインストール時に何とかしておいたほうが良いですね。いや、もちろん運用環境とかだとまた話は違うだろうけど（にしたってAPサーバなどからアクセスするアカウントに有効期限とか切られても困る気はするが）、開発用などの場合最初に設定する手順に含めておいたほうがよさそう。

Java Day Tokyo 2015

行ってきました。

Keynote

前半はJava20周年です、ということで、どれだけJavaが使われているか、どれだけJavaプログラマがいるか、どれだけJavaの世界が広がっているか・・・といった内容の話を中心に、今後のロードマップとまさにIoTみたいなところのデモを幾つかやってた。だいたいすでにどこかで聞いたような話だったり、まあここで突っ込んだ技術的な話も期待してなかったりだったんだけど、ただデモにALDEBARANのPepperが来ていて「Pepperをコントロールするライブラリがあって、Java向けのSDKもあるよ！」というような話をしてたあたりがなかなか面白そうだった。IoTってことでなんかMinimalな感じのデバイスにJava乗っけてやってますよっていうのは正直デモを見た感じでは「まあなんとでもしようはあるだろうなあ」と思ってしまったのでそれほど印象的でもなかったかな。実際どんなコードが動いているのか見れたら違ったかもしれないけど。

後半はコミュニティ活動重要ですよね、というような話でした。Javaの仕様はJCP(Java Community Process) に従ってコミュニティの手によって策定されてきていて、例えば楽天なんかがそれに参加しようとしているという話とかJJUGの代表の方がJJUGっていう大きなコミュニティがあるので参加しましょうねとか、関西Javaエンジニアの会の代表の方はもっと各地でユーザグループと作る活動をして盛り上げていきましょうというような話をそれぞれ話されてたかな。 個人的にはコミュニティカンファレンスに参加してみるようになったのも最近のことで経緯的にコミュニティで修行を積んできたわけではないわけなので、その辺はあまり実感のない感じではあったかな。

#jdt21 JAVA EE 8 - directions and new features

Java EE 8 の仕様として以下を中心とした解説。

• JSON-B / JSON-P
• MVC
• Server-Sent Events
• HTTP/2
• Web Sockets
• あとなんだっけ

JSON-Pの中にJSON-Patchという話があって、JSONオブジェクトに対して部分的に変更したり付け足したりする（まさにpatchのような）操作をJSONでかけるようにするみたい。多分この辺JSON-Pathとか先行の仕様ある気がするけど、どの程度整合しているんだろう。

とはいえ、最近のインフラ周りとかクライアントサイドのReactの動きなんか見ていると、冪等性を保証できない方法論はそれができる方法論にだいたい取って代わられるのではないかと思っているので、なんかもう一回ブレイクスルーあんのかなあという気がしている。

それ以外の話はあまり印象に残っていない。居眠りしてたわけではなかったと思うのだけど、食後でだいぶ集中力が削がれたかな・・・。

#jdt42 Oracle Developer Cloud Service , what can you do ?

Oracle Develoepr Cloud の紹介といった内容でした。 まさにどんなものか聞きたくて参加したのだけど、会場のハッシュタグのツイートでもいまいちな感じのコメントが多かったのと同様、自分としてもただ流行りのツールを組み合わせたというだけで新しいユースケースが生まれたりブレイクスルーがあるわけでも無いように思われた。

まあこれからブラッシュアップしていけば良いとはおもうけど、他のベンダと比べるとちょっと動きが遅いかもなあというのが心配なところ。実際使ってみるとまた違う発見があるかもしれない。

[書籍] Java パフォーマンス

確かこのタイミングで、オライリーのJava パフォーマンス買って監訳者の方にサイン頂きました。

最近仕事でパフォーマンスの問題に見舞われて相談を受けることが増えてきた気がするので、職場に神棚を作って祀ろうと思います。

#jdt23 Applied Domain Driven Design Brue prints for Java EE 7

少し前に日本語版のDDDの本が出て若干話題になってたからか、結構聴衆がおおかったですね。

けどタイトルの割に、内容はあまり実践的ではなかったのではないか・・・と思うのだけど、実は最後の方、うとうとしていたきがしてよく分からない。なんかあれ、もう終わりかとおもって若干びっくりした気がするんですけど、分かる人にはわかったのですかね。

#jdt44 脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編

SSLの基本的な仕組みの説明から「こーいうコーディングをしてたせいでサーバ証明書の検証が甘くて危険にさらされたよ」という事例をつぶさに紹介してくれてました。

まあ事例集ということで仕方ないかもしれないんだけど、あまり関わりたくないなという印象が強くなってしまった。「仕様的にもともと複雑なために微妙な落とし穴にはまることがが多くて全ての分岐を綿密にテストしないとどこかを踏み外すだけで致命的な脆弱性になるんだなあ」というような感想。

そういえばこのセッションを聞いている間に以下のようなツイートをしたんだけど

固定的にtrue返すって何かのサンプルかで聞いた気がするな #JavaDayTokyo #jdt44

— carrotsword (@carrotsword) 2015, 4月 8

証明書検証をしている部分をオーバライドして固定的に許容してしまう（検証をスキップする）ロジックにしてしまってる例が結構あるらしい。

なんか過去にやった気がしてなんだったっけなと思い返していたんだけど、以前SOAP Web Service で作ったアプリの試験をしていた時に、HTTPとHTTPSの両方で試験する必要があって、その時にサーバにオレオレ証明証を使用したためにクライアント（これはテスト用にWSDLからざっくり生成したもの）でサーバ証明書の検証とかやってられっかーということでこれをスキップしようとして、この例ような回避策を取った事があったのだった。

ただなんかこの回避法ってどこかのBlogか何かで読んでやった気がするのだよね（自分が最初からそんなオーバライドしてやれば良いということまで知っていたと思えない）。なので変な拡散の仕方してるのではというのがちょっと気になった。

#jdt25 Reactive Java EE 7 Let Me Count the Ways!

Java EE における Reactive な部分、ということでイベントハンドラとか非同期処理が書けるポイントを順に説明していた（のだと思う）このへん、なんとなくこんな仕様があるということを知っているだけで実際使ったこともないので、ほ〜、と聞いているだけだったんだけど。

個人的にEE における非同期ってどの程度有用なのかちょっとよくわかっていなくて、というのは、夜間にバッチ処理というのはともかく、リクエストにたいして非同期にサーブレットが動くであるとか、コンテキストにたいしてイベントをフックして処理するなどして、サーバサイドの負荷が上がる割にクライアントへの応答は良くなるという方向なんだけど、クライアントの応答が良くなってしまうとクライアントサイドからのアクショントリガーも多くなるであろうと思われるわけで、利用実態としてサーバの負荷がうなぎのぼりになるのでは？という疑念がある。個人的にはクライアントがレスポンシブであることよりもサーバの性能が足りない事案の方が多いので、あまり使いどころがない気がする。まあ実際やったことないからよくわからんしスケールアップなりアウトなりすればいいと言われればまあそう。だし、まあアドホック的にこういう対応が必要になるケースがあって、こういうやり方が用意されているということが重要なのかな。でもだとするとReactive Java EE 7とか言ってしまうのは行き過ぎている気がするけれど。

どういうところでどのくらい使われているものなのか事例聞いてみたい気がする。

そういえば、なんかいい加減アノテーションの記述量多すぎだろというのが気になってきたんだけど、どうなんだろう。手続き的な記述から宣言的な記述に移行しているのだからいいということになのかなあ。

#java20th Java 20周年記念セッション

クイズとLTのハイブリッド進行ということで、クイズもあんなに多いと飽きそうだと思いましたが、以外といけましたね。なんだかあまり聴衆受けを取りに行く人のセッションを取らなかったせいか？（失礼）1日で一番空気があったまってた気がします。 全体がゆるい雰囲気で楽しかったです。

運営・関係者の方々、お疲れ様でした。今後２０年も、さらに発展したコミュニティになると良いですね。

Javaエンジニア養成読本よんだ

けど、その内容については書かない。

Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus)

Javaエンジニア養成読本という本があって、その頭できしだ(@kis)さんという人が今までのJavaについてまとめてられていた。自分としてはいろいろ脇道にそれつつも10年程度Javaでやってきているので、懐かしい話を読みながら自分でもいろいろ考えたことを思い出したので書いてみた。

まぁあんまりまとまらなかったんだけど、出さないといつまでも下書きに保管されたままになるので出してしまう。

中途半端に神が登場する

オブジェクト指向という思想は既に世界が組み上がってしまっている前提で語るには美しい論理なのだけれど、その世界をくみ上げる作業についてはあまり現実的には考えられていないと思う。

車オブジェクトは車体オブジェクトとタイヤオブジェクト×4の組み合わせでできていて、accelerate() をコールすれば車輪は回り前へ進む。だけれども、そのまえに車自体を組み立てる必要がある。そのためには Engineer とかいうクラスを用意して、constructCar() とかなんとかいうメソッドを用意して、そこに組み立て方を記述してやると良い。 Engineer がいることによって車オブジェクトをまともに使えるようになるがしかし、これがまた新たな問題を生む。Engineer インスタンスを果たして誰が生み出すのか。 それは当然 Enginner に父と母がいてという事なんだが、こんな事を延々繰り返していくうちにアダムとイブまで記述しなければ成らなくなるので、もういいよというわけで神様が Engineer インスタンスを作り出す（あるいはEngineerは自然発生する）事にする。

どこから神様が介入していいのかは議論があるだろうが、まあそんな事はどうでも良い。要するに、オブジェクト指向の基本コンセプトはその世界を構築する段階ではちょっと忘れた方がいいってことで、この辺まだ進化の余地がある気がしている。

リテラルは悪っぽい

割と2000年代から、リテラルは悪という感じの空気がある気がしている。Javaコードに成っているものには一切のデータを含んではならない、というような。

基本リテラルとして扱えるものは何らか別ファイルにされる事に成っている。これはJavaがコンパイル言語であることに起因しているような気はする。つまり、コード中に書かれてしまうと変更の度にコンパイルし直さなければならないしアーカイブし直さなければならない。

慣習的にリテラルはすべて外部化されるべきみたいな空気が出来上がってる気がする。

その影響を受けてなのかなんなのか、Javaはリテラルがとても貧弱だと思う。リテラルが使いにくいということはテストに悪影響を与えているような気がしないでもない。 神様の話とも関連するが、テストはとにかくテストの前提状態をくみ上げるブートストラップが簡単に書けないといろいろつらい（はず）。設定とか外部ファイルでできるから良いじゃんということかもしれないが、個人的にはその程度の分離でも面倒だ。コードの世界でブートストラップを分かりやすく簡潔にまとめる為にはやはりオブジェクトリテラルが、当然、簡潔な形で存在したほうがいい（のではないか）。

最終的に別の言語が誕生する

さて2000年代後半になるとリテラルに留まらずコンポーネント同士の接合も外部化するのが良いという空気になってきた。いわゆるDIによって。発想の起源としてはEJBのようなローカル・リモートでオブジェクトを分散するといった話だったのかもしれない。 コンポーネント同士の接合面はInterfaceとして設計され、その実態は設定や特定の規約によって構成される。

これがさらに進み、コンポーネントは細分化し設定の記述量は増え、気がつくと設定ファイルでプログラムを組むような事さえできるようになっていて、それってもはや設定じゃなくてスクリプト言語じゃないの、といった域に達すると末期である。

共通化というか規格化できたらドメインを記述する為の新しい言語に成りうるのかもしれないんだけど、そこまで突き抜けた人は未だ見た事は無い。BPMの分野がこの辺掘り下げていってそうな気がするけどどうなんだろ。個人的にはBPMは最終的にビジネスの人がコード書くのと変わらない状態にたどり着くと思っているのであまり真剣に見ていないのだけれど。

コードの文脈感と型

rebuild.fm#59 (http://rebuild.fm/59/) にて、まつもとゆきひろさん (@yukihiro_matz)が、こんなような事を言っていた。

• 手続きが書いてあることで何となくそのオブジェクトに要求しているものが記述されている。それが型のようなものを表しているはず。
• そこにさらに型を書くのは冗長。

長くJavaを書いてきた者の感覚としては型は単に情報の型ではなく役割としての意味合いも期待しているところがある。手続き的に処理を書いていく事でボトムアップ的にそのロジックやオブジェクトの役割が決まっていくのと平行に、トップダウン的にクラスとして役割を明示することで自分の思い描いているロジックやクラスの構成に誤りというか違和感が無い事を検証したいという欲求がある。 しかし考えてみれば、現状これはコードの見た目上違和感がなくなるということで自分の中で確認しているだけの事であって、コンパイラによってロジックと役割の矛盾が指摘されるという訳ではないから別に静的型付けの優位性ではないのかもしれない。

いやいや。ずらっと手続きから書いていった感覚と、クラスの定義を中心に見た時の感覚と、コンパイラのチェックの3本の柱で設計の違和感を抽出していっているのだ。そのはず。そんな気がする。多分。

EmacsでJava楽しめるわけない（と思っている）

上記のような感覚でプログラムを書く事に慣れていくと、プログラムができていくに従って増えてくる概念を分離したりメソッドの構成を全体的に見直したりと言った事が発生しやすいのかもしれない。これはあくまで設計ベースで行われるので、その処理に流れるデータがいかに効率的に処理されるかは若干蚊帳の外に成る。 現在のJavaであれば、メソッドやクラスの再編成や分離・統合はIDEがかなりの部分でカバーしてくれている。これが静的な型無しで実現できるものなのか、がJava使いからLLを眺めたときに不安になる。

この辺、Java（というか私の感覚）ではリファクタリングの範疇なんだけど、「そもそも機能が変更されるならリファクタリングといわないだろ」というツッコミを見たことがあるので、人によってはリファクタリングじゃないのかもしれないが、個人的にはこのレベルの変更は安全にできないと快適にプログラミングできない。

そもそも、LLに慣れた人がLLを書く感覚と、Javaを書く人がJavaを書く感覚はメンタルモデルからしてに大きく異なっているだろうなあとは感じている。あくまでJava屋の私の感覚で言うならば、LL系のプログラムを書く際には、関心の中心となるデータに対して、積極的に処理によって関与していくようにコードを書く印象を持っている。Javaでコードを書く場合には、まず存在するデータや概念をクラスやアーキテクチャによって表現することから始まる。データの実態に関与するのは、抽象化できなくなった所でようやくと言った印象がある。 LLで書く場合はいきなり本題である問題を解くコードを記述し始める（ような気がする）といえばいいのか。それに対して、Javaで書く場合はまず問題を解くための世界をどう構築するかから入ってるような気がする。感覚としては、本題である問題を解くコードをうまく記述するために、中間レイヤーをもう一つ設計しているような感覚がある。

まあこれは単に経験の違いというだけのことかもしれない。（つまり、私はLLでちゃんとしたシステムを作った経験が乏しいので、いままでJavaでしてきたような経験を得ていない、というような。まああるいは逆に、Javaでも最近はそんなやり方ができるように変化してきているところもある）

setter getter

getter/setterでなんやかんや公開したくない処理を書いても最終的に取り除いてる場合が多い気がする。結局外部からコントロールできない部分があるコンポーネントというのは後々の保守なり拡張でネックになりがちな印象がある。 個人的にはgetter/setterはIDEで生成してしまう派なので、getterとかsetterの中に処理書くなと思っている。Beanにバグになりうるようなコード入れて欲しくない、というのもある。つまり、publicフィールド使えばいいような気がしている・・・が、publicフィールドだとそれはそれで問題だと思った経験がある気がするのだけど、具体的に思い出せない。逆にprivateは極力使わないほうがいいと言えばいいのか。（多分フレームワーク屋さんはもうちょっと違った見解があるだろう）

プロパティはまああってもいいけどC#みたいなんだったら今更入れてもらってもという感じはある。Lombokは使ったことがないけど、わりと好評のようなのでそれでいいのかもしれない。

別に率直に書いても良い筈

Javaを敬遠する向きに多いのは、文法が冗長というものだが、文法として冗長というよりも文化的に回りくどい事をしたがると受け止められているのではないかという気がする。もちろんLLに比べれば冗長にならざるを得ないのはそうなのだけれども、Javaの常識を無視して今までとは違った姿を目指してみるのもいいのかもしれない。

Java EE

いまやWeb開発をするには必須ではないにしろ押さえておくべきポイントになったと言っていいとは思う。先進的なフレームワークがいろいろある中で着実な手法を選んで進歩することで人類の英知を蓄積して行っている。・・・とまでは言わないんだけど、そんな感じなので先進性はない気がする。かといって10年大丈夫かというと、なんだかんだコンポーネント毎に勃興ある感じなので必ずしもこれ使っとけば10年安心というわけでもなさそう。まあ、大丈夫だったとしても今から10年前のJavaのコードなんて見たくないというのが本音であるので、正直なんでもいい気はする。

JSFとJPAが2大悩みの種という感じがする。みんな関心があって人気のある部分なのだけど、なかなかカッコよく問題が解決されない。

JSFは使ったこともないんだけどここのところフロントはクライアントサイドで生成するのも普通になってきているし、個人的には現状のJSFは解決する問題に対してレイヤが厚すぎるという印象があってHTTPとの親和性も薄い気がしている。最終的にはデザイン（見た目）がネックになってあまりオープンに流行ることはないと思っているけど、どうなんでしょ。

JPAもこれ以前の永続化レイヤーと比べればマシなんだろうけど別に使わなくていいじゃんという空気がある気がする。個人的には永続化レイヤーはメモリに置いてあるものとストレージに置いてあるものをシームレスに扱えるようにすることが命題だと思っているので、今の仕様では物足りない。ストレージから必要なオジェクトグラフを柔軟に切り出したり書き戻したりできなければならないが、それができる仕様ではない。少なくとも今のスペックリードはその辺意識しているような記事をどこかで読んだので、5年とか10年くらいしたらそれなりになるのかもしれないけど、そんなに待ってたらメモリかストレージが進化してJPAの解こうとしている問題自体を消し去ってしまう可能性がある。