Tweet

今日、オブジェクト指向について1時間ほど語りました。整理するため自分用に書いたメモを公開します。大まかな構成はメモどおりに話しましたが、メモに書いていないこともたくさん話していますし、書いていても話さなかったこともあります。

前提として自分自身のオブジェクト指向へのスタンスを書いておきます。

自分のプログラマとしてのキャリアとオブジェクト指向の隆盛の重なりを考えると客観的に見て自分はオブジェクト指向世代のプログラマなんだと思います。一方で、世間で過剰にもてはやされる技術には反発してきました。オブジェクト指向も例外ではありません。オブジェクト指向を否定はしませんが、金科玉条のように扱う人の前では、オブジェクト指向なんて技法のひとつに過ぎないと、冷たく突き放してきました。

ただここ数年、かつてに比べてオブジェクト指向の威光は下がっている気がします。関数型プログラミング支持者から、オブジェクト指向なんて副作用をベースにした技法だと揶揄されることすらあります。過去10年でプログラミング技法がそれほど進歩したとも思っていませんし、人間の思考能力が大きく進化したとも思えないので、オブジェクト指向の(相対的な)影響力の低下は、価値の低下ではなく、単なるかつてのブームへの反動だと思います。ブームの反動だとしても、オブジェクト指向は時代遅れで無価値だと主張する人は(寡聞にして)ほとんど知りません。要は、オブジェクト指向は過剰に持ち上げられるでもなく、過剰に蔑まれるでもなく、冷静に価値が評価される時代になったのだと思います。これでぼくも無理することなく、普通にオブジェクト指向を話せる時代になりました。

改めてぼく自身のオブジェクト指向への評価は、全能の技法ではないけどれど優れた技法のひとつ、です。率直に言って過剰な思い入れはありません。

大部分のプログラミング技法の価値はコードの依存性の整理をいかに補助するかだと思っています。コードの依存性を整理するひとつの有効な策が、コードの中に不変の部分を作り込んでいくことです。マクロに見ればインターフェースです。ミクロな技法を挙げれば不変オブジェクトや副作用の排除などがあります。コードの中に不変の部分を作っていくことで依存の連鎖を断ち切って、変更の影響を管理可能な範囲に押し込めます。

不変の部分を作っていくにはコードの中の変わりやすい部分とそうでない部分を見極める目も必要です。多くのプログラマはある規模までは無意識にできています。何かを設定ファイルに追い出したり、外部パラメータに追い出したりするのは自然にできていると思います。そうやって無意識に追い出しているのは変わりやすい部分だと認識しているからです。コードの規模が大きくなっても変わりやすい部分を外に追い出す感覚は重要です。

不変を作り込む時にも注意があります。本質的に変わりやすい部分を扱うコードに早々と不変を持ち込むと融通の効かないコードになるからです。早すぎる最適化というプログラミングのアンチパターンがありますが、同じような言い方をすると、早すぎる不変の作り込みと呼んでもいいかもしれません。早すぎる不変の作り込みをすると、回避するためのラッパーコードや無駄なフラグを持ち込む羽目になります。形式的にはインターフェースを使った固いコードで美しいのに、現実的には足かせにしかならないコードができあがります。

だらだら書いていたら前置きのほうが長くなりました。以下がオリジナルメモです。

関連文書:

• 関連文書は見つからんがな

Tweet

パーフェクトJavaとパーフェクトJavaScriptの両方の増刷が決定しました。

ありがたい、ありがたい。

先週JJUGの集まりで今年のJavaOneの様子を聞いてきたのでその感想を書きます。雑多な感想なので全体のまとまりは特にありません。

Java8リリースの予定が2013年に延びたようです。去年のJavaOneでJava7は2011年リリース、Java8は2012年リリースと発表していました。Java7は約束を守りましたがJava8は延びました。予想どおりです。この業界にいれば誰でも予言できる未来でしたが。2013年にリリースできるかですが、2013年の末まで考えれば今から2年あるので流石にリリースできるような気がします。

予想外だったのはJavaFXの動きです。Swingを置き換えてJavaのGUIライブラリのメインになるようです。AWT、Swingの流れの次がJavaFXという位置づけです。OpenLook時代からSunのGUIライブラリに裏切られてきた自分としては、もうJavaのGUIに夢を見る気はありませんが。

JVMで動くJavaScript実装のRhinoがダメ出しされて、新しい実装のNashornで行く、ということのようです。Java6以降の配布にはRhinoが標準添付されていますが、Java8でNashornに置き換わるようです。Rhinoが捨てられてしまいました。

Java EEは次のJava EE7でクラウド対応するそうです。何を持ってクラウド対応と呼んでいるのか(皮肉ではなく)本当にまったく不明です。

Java EEのWebプロファイル対応のアプリケーションサーバTomEEというのがASFから出ていたようです。Java EE準拠の処理系のリストが下記にあります。TomEEも載っています。

Java EE Compatibility

ASFでJava EE準拠の処理系と言えばGeronimoじゃなかったのか、と言いたくなります。Java EEは仕様の間の関係も(それなりに)複雑ですが、実装の関連も複雑で困ります。

自分は、普通の人よりだいぶJava EEを詳しく調べているという自負があります。仕様と実装の固有名詞も結構押さえているつもりです。にも関わらず、結局、Java EEでWebアプリを作りたい時に何を使えばいいのか確信がありません。GlassFishは間違いの少ない保守的な選択肢ですが、なんとなく、たいして根拠もないですがGlassFish一択になる世界がよろしくない気がしてASF系の実装を推したくなります。しかしASFのJava EE関連の実装はどれが推せてどれが推せないかカオスです。そしてTomEEもまた単に固有名詞が増えただけに感じてしまいます。Java EE6の仕様は悪いものじゃないと思っているので残念です。

最後、JavaOneと関係ない件です。@ITにJavaOneレポートを書いた山本さんのサイトの記事で驚いた記述がありました。Liferayの開発でJenkinsサーバが数100台のオーダーで稼働しているとのことです。そもそもなんでJenkinsが数100台も必要になるのか見当がつきません。開発のインフラ担当者がマッチポンプ的に仕事を作ってるんじゃないのかと邪推したくなります。

関連文書:

• 関連文書は見つからんがな

Tweet

WEB+DB PRESS Vol.65

出たばかりのWEB+DB PRESS Vol.65を早くも読み終わりました。ちなみにSoftware Designは2011年3月号を読み始めたところです。半年以上ビハインドですが週に1号のペースで読めばほどなく追いつけるでしょう。

WEB+DB PRESS Vol.65の印象に残った記事の感想を書きます。

特集1 Webエンジニアが知るべきインフラの基礎知識

綺麗に体系化して情報を整理してくれている点で良記事だと思います。知識のないままこの記事を読んだだけでは浅い知識のままですが。

新卒向けカリキュラムで、ネットワークの良い本を探していると書きました。とりあえずこの記事をベースに講義をしようと思います。

特集2 PHPフレームワーク実践活用

記事中、何度かDI(Dependency Injection)の用語がでてくるのですが、DIの使われ方がいまいち分かりません。

ぼくのDIの理解は(詳しくは「パーフェクトJava」に書きましたが)、オブジェクト構築(コンストラクション)の役割の分離です。ファクトリ(パターン)の進化(強化)版、あるいはフレームワークプログラミングが本来的に内包していた機能の汎化版だと理解しています。

この記事中のDIは…よく分かりません。ぼくのPHPの理解が甘いだけで、同じ概念を指していることに気づけないだけか、それともDIの意味が変容しているのか判断できません。

特集3 ビッグデータ時代のDB設計入門

松信さんの記事です。流石の内容です。所々NoSQLを揶揄するところが笑えます。正確に言うとNoSQLを揶揄しているのではなく、無批判にNoSQLを礼賛している人を揶揄しています。

何事も無批判はいけません。

そんなわけでぼくも松信さん記事を批判的に読んでみようと思います。(皮肉ではなく)松信さんのような頭の良い人のお守りが必要という点で、MySQLはD社の要件に合っていないのではないでしょうか。やることなく毎日暇ですと松信さんが言った時はじめて、MySQL凄い、と言いたいと思います。

その他

太田さんの「JavaScriptベストプラクティスラボ」でJavaScript Lintを知りました。記事はCoffeeScriptについてです。個人的にCoffeeScript自体はあまり好きになれません。理由は、立ち位置が中途半端すぎるからです。

LightSwitchに少し興味があったので「いまどきの.NET開発」を少し興味深く読みました。少しですが。

「SQL緊急救命室」はいつもマニアックなSQLネタが多いのですが、今回は趣向が違います。SQLで頑張る代わりにデータモデルを変える代案を考えてみよ、というテーマです。これは読む価値があります。クエリの複雑さとモデルの複雑さはトレードオフになることが多々あり、どちらに複雑さを寄せるかは大きな課題だからです。クエリが(相対的に弱い)NoSQLではモデル側に複雑さを寄せるのがより切実な課題だったりします。

関連文書:

• 関連文書は見つからんがな

Tweet

明日、Crash Dartがあるので行く予定です(参加登録していませんが)。パーフェクトJava、パーフェクトJavaScriptの次にパーフェクトDartを書こうと思っているからです。うそです。

明日は人が来るのでしょうか。万が一、イワガガ氏とふたりきりになったら、一日中英語で会話しないといけません。なかなか厄介です。

今日はじめてDartを触ってhello worldしたレベルです。Dartのぱっと見は、JavaScriptよりJavaに似ています。Go言語は構文などが個性的すぎて慣れるのに時間がかかりましたが(そして既にほぼ忘れました)、Dartはすぐに慣れそうです。構文はプログラミング言語にとってさほど重要ではない、可能な限り構文の制約を取り払って自由度を高める方が良いという意見もありますが、賛成できません。構文の制約は重要です。思考が制限されても構いません。考えることを減らしたいからです。

Dartの未来が明るいかと言うと…。クライアントサイドJavaScriptを置き換えるのは厳しそうです。IEに載らないとJavaScriptの置き換えにはならないからです。今のところ、マイクロソフトがIEにDartを載せるメリットが見つかりません。もしGoogleのサービスがDartなしで動かないようになるとマイクロソフトも渋々従うのでしょうか。Windowsを使っていない自分には他人事なので、是非、Googleにはトライして欲しいものです。

GNU/LinuxでDartをビルドしたメモです(/home/inoue/work/dartで作業しています)。https://code.google.com/p/dart/wiki/Buildingを参考にしました。

関連文書:

• 関連文書は見つからんがな

Tweet

しばらく公開をさぼっていましたが、「Emacsのトラノマキ」の原稿を公開します。画面上のメニュー「ドキュメント」からたどれます。本記事は前号に引き続き袖山さん執筆です。タイトルは「Lispの世界」です。Software Design 2010年6月号の掲載記事です。ラムダ計算、Yコンビネータ、継続の説明が続く「Emacsのトラノマキ」史上、もっとも難易度が高かった記事です。一般に、Yコンビネータや継続の話は、理屈や言語機能を使う側の話が多いですが、本記事はEmacs Lispでの実装もあります。ローテーションの谷間に見せかけて先発投手が完全試合したぐらいアリエルの底力を見せつけた記事です。

関連文書:

• 関連文書は見つからんがな

Tweet

追記
タイトルが微妙にミスリーディングだったかもしれません。RangeヘッダのCVE-2011-3192はリバースプロキシとは無関係に起きる問題です。

Rangeヘッダの問題(CVE-2011-3192)が大きすぎて、Apacheにある他のリバースプロクシの問題の影が薄いので書いておきます。きっかけは、このITmediaの記事です。ふたつの別個の問題を混在して伝えている気がするからです(書き方が思わせぶりで詳細を書かないので真相は不明ですが)。

Apacheをリバースプロクシで使った時に次のふたつの問題が最近見つかっています。

• mod_proxy_ajpとmod_proxy_balancerを組み合わせた時に起きる問題。不正リクエストを送ってDoS攻撃が可能
• mod_proxyと特定の設定で起きる問題。内部サーバなどに外部からアクセスされる可能性がある

前者のCVE-2011-3348のバグ情報はこれです。

mod_proxy_ajpとmod_proxy_balancerを組み合わせた時に起きる問題なので、組み合わせ的には微妙にレアと言えばレアですが、細工したリクエストを送れば簡単にDoS攻撃が可能なので狙われればアウトです。もっとも、CVE-2011-3192のDoS攻撃でメモリを食い尽くされるひどさに比べると、CVE-2011-3348の場合、mod_proxy_balancerがretryを繰り返すだけなので多少マシかもしれません。

問題は最新のv2.2.21で修正済みです。最新版へのバージョンアップ以外の回避策はありません(バージョンアップ以外の暫定的な回避策は、mod_proxy_balancerのretryタイムアウトを短くする設定ぐらいでしょうか。被害は減らせそうです)。

コードの修正を見ると原因はエラー処理です。ただエラー処理自体は元からあります。致命的なエラーにするか否かの判断ミスです。致命的なエラーであればmod_proxy_balancerはretryしませんが、そうでなければretryします。外部からの不正リクエストは致命的エラーにすべきところをしていないため、retryが繰り返されるDoS攻撃が可能になる、というシナリオです。

これは事前にコードだけ見ても見つけるのは困難だろうと思わせるバグです。エラー処理はきちんとしているからです。致命的か否かの判断の漏れがあっただけです。と言うより、これはApacheだから見つかる問題で、世の中の分散処理のコードで冗長性のためにretryするロジックを入れているコードだったら、類似の問題はどこに隠れていてもおかしくないと思われるぐらい発見困難な問題だと思います。

後者のCVE-2011-3368のバグ情報はこれです。

mod_proxyと特定の設定で起きます。最新のv2.2.21でも未修正です(パッチは存在するので次のv2.2.22で修正されるでしょう)。該当する設定を書き換えれば回避できます。

次のようなパターンの設定で問題が起きます。この設定の意図はApacheが受けたリクエストをリバースプロクシで内部サーバ(internalserver)にそのまま投げる動作です。リバースプロクシとしてはそれなりにありふれた設定な気がします。

知っている人には自明だと思いますが、念のため書くと、RewriteRuleとProxyPassMatchの両方を書いたという意味ではなく、どちらでもです。そもそもふたつの設定は同じ動作の設定なので、通常、どちらかを書きます。

下記のように書き換えると回避できます。

面白いと言うと不謹慎ですが、なかなか興味深い攻撃方法です。

のようなリクエストを送ると、リバースプロクシ設定の書き換え結果が次のようになります。

このURLはtarget.example.comのホストにinternalserverのユーザでアクセスするという意味になります。この結果、target.example.comにリバースプロクシが向いてしまいます。見せたくない内部サーバのホスト名を書かれると、リバースプロクシのApacheを踏み台にして外部からアクセスされうる、というシナリオです。

関連文書:

• 関連文書は見つからんがな

Tweet

　前回 は遅延指数による為替予測を遺伝的アルゴリズム (以下、GA [Genetic Algorithm]) で行うプログラム (azumi くん) の設計部分の話をしました。

　最初にお断りをしておくと。azumi くんは、世の中の経済事情を全く考慮に入れておらず、そこまで作り込んでもいないシロモノで、はっきり言っておもちゃです。
　もちろん単なる当てずっぽうではなく、過去の為替レートの中に遅延指数が隠れているという期待の基 GA によってそいつを解析し、未来を予測をしようとしていますが。そもそも遅延指数が存在しなければ、ここでの予測は当てずっぽうにすぎません。仮に遅延指数が存在していたとしても、見つけられなければ、やはり出力結果は当てずっぽうです（GA は “解” そのものを出すのではなく、”解っぽい” モノを出すので）。
　間違っても、現ナマを賭けて、一山当ててやろうなどと思わないでください。
　というわけで。これの情報を鵜呑みにしたために発生した損害は一切保証しませんのであしからず。

　言い訳が済んだところで。さっそく中身 [1] を見ていきます。
　azumi くんのクラス構造はとても単純で、次の２つだけです。

　まずは Value クラス。こいつは value.rb で定義されて、ある日の為替レートの終値に関する情報を持つクラスです。アトリビューションとして、日付、為替価値と為替価値の前日比の情報を持ちます。
　次に Chromosome クラス。こいつは chromosome.rb で定義され、前回紹介した３つの遺伝子情報をアトリビューションに持つ、染色体を模したクラスです。

　それでは GA による解析の中身を見ていきます。
　以下が、この処理を行う azumi_training.rb のソースコード全文です。

　4,5 行目は初期化処理になります。
　4 行目の処理では、シリアライズした Chromosome オブジェクト群をメモリに戻しています。
　5 行目は、過去の為替レート [2] から Value オブジェクト群を生成し、Value クラスのクラス変数の配列にブッこみます。

　あとは GA の評価・交配処理を行っています。初期世代の染色体が持つ DNA 配列 (前回の “遺伝子情報” のくだりの１番目) はランダムに設定します。
　8 行目で、現世代の全染色体を評価関数に突っこみ、適応度を算出します。この適応度が、遅延指数としてのどれだけ有効かという「有効性」と、それがどれだけ過去に再現したかの「一般性」を表します。
　また eval_all メソッド内部では、エリート保存戦略によって解析速度を上げます。
　そして 9 行目で、不良遺伝子を持つ個体の淘汰と、各染色体の交配処理を行います。交配は、シンプルな１点交叉を行います。ただ多様性を出すために、交差点はランダムに設定します。また、これも多様性の為に一定確率で突然変異をお越し、DNA 配列情報 (遅延指数出現の予測日数) の数値をいじります。
　そして、世代交代後の染色体に対して上述の処理を繰り返します。

　多様性が出るようにする理由は、（動かしてみるとわかりますが）多様性を考慮しないである一定世代まで進化させると、遺伝子全体が局所解に落ち着き、それ以上変化しなくなります。
　人間で例えると、優勢遺伝子によって駆逐された同じ顔つきで同じ体系、同じ肌の色、同じ体質の人間が溢れ返っている様子を想像してください。
　それが本当の解ならばいいのですが。本当の解かどうかを確かめることは出来ないので、なるべく局所解に落ちないように、それでいて適応度を上げるようにします。
　突然変異は多様性を出す為の有名なやり方ですが。他にも、各民族（別に設定した評価関数によって残った個体）が特定の地域に偏在し、時々往来して交配するという現在の世界を模した「島モデル」といったようなやり方などもあります。

　最後に。次の日 (raw_data.txt の最後の行の次) の為替レートの予測をする処理について。
　次が、この処理を行う azumi_eval.rb のコードの全文です。

　7 行目以外は進化処理と同じです。
　進化させた個体のうち、エリート個体の遺伝子による評価を行います。具体的には『エリート個体の遺伝子が遅延指数である』という前提で、どれだけそれが現象として現れているのかを判定します。具体的には以下の擬似コードの処理を行います。

　これもやってみるとわかりますが。学習を行う過去の為替レートの期間によって結果は大きく変わります。
　期間を短く (過去 1,2 年くらい) 設定すると。ここ数年、慢性的に円高が続いているので、エリート個体はこぞって「円高になる」と言ってきます（円高になると予測した個体が生き残る為）。
　期間を長く（過去 10 年くらい）遡って学習すると、今度は遅延指数が見つからなくなります。

　やはり。過去の為替レートの情報だけで、為替予想をするのは難しいです。

[1] http://dev.ariel-networks.com/wp/wp-content/uploads/2011/10/azumi.tar.gz
[2] http://homepage1.nifty.com/Gaku/

関連文書:

• 関連文書は見つからんがな