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の解こうとしている問題自体を消し去ってしまう可能性がある。

Versus Excel Workbooks.

同僚というか後輩の一人にものすごくコードを完成させる速度の速いやつがいる。技術的にもある程度信頼できるので、瞬発力の必要な局面で重用されている。その技術と仕事の速さにはだれも申し分ないのだけど、どうにも仕様書の行間を読めないようだ、というのがこの間同僚の間で話に挙がっていた。 その時話題に挙がっていたのはコードと名称が対になっているような項目で、入力画面で選択したものを別な画面で表示項目として見せる時に、当然名称をラベルとして表示すべきところを、設計書の記述が十分でなかったために彼はコードを表示する実装をつくって作業完了と報告してきたらしい。 設計者とプログラマはここでは別々だったのだが、設計者側にしたらこのくらい気を使って当然というか、せめて何かおかしいのではと声をかけるくらいしてきてもいいのではないかという。まあ、まっとうかどうかはわからないが、気持ちはわかる。

結局システムなんてお客様に使っていただいてなんぼなので、使いにくい実装を看過するという態度そのものが問題ではあるのだけど、果たしてそういった局面でいちいち気をまわしていては当然実装の手も進まなくなってしまうわけで、この辺生産性をどう考えたらいいのか悩んでいる。いくら早くできても使いにくかったら意味ない、という反面、実際に試してみなければ問題にすら気づくことすらできない設計とやらに時間をかけていてもどうなのかという気がする。究極的には顧客の利便性であるとか利益につながることが正義であるにせよ、もちろん時間と金は有限であるわけで、限られた中で最適なやり方を選択していく必要がある。

設計書の行間を読むべしというのはそもそも設計書を疑ってかかることに等しいわけで、となればその設計というものの価値がどの程度であるのか再考する必要はありそうだ。

設計者が自分の意図したことを設計書という特定のフォーマット（大体のケースに於いてExcelで何種類かのシートでまとめられたアレだ）にエンコードし、実装者が設計者の意図を推測しつつそれをデコードしていくという作業が日々行われているわけだが、改めてこう書いてみるとなんだかすごく非効率なことをしている気がしてくる。「特定のフォーマット」というのがまた厄介で、これは設計者の生産性を顕わにする代わりに記述の柔軟性と著者の思考力を制限する。制限された記述でまとめられた設計書にはいろいろ記述しきれないものが出てくるが、基本的にそういったものは捨てたほうが設計者の生産性は向上する（ように見えるようになっている）。実装者はこの記述しきれなかったものを拾うためにExcelワークブックと格闘しなければならないことになる。

ここで捨ててしまう記述をすべて漏らさず記述すればよいのか、といえば、それもばかばかしい話なのはご存知の通りで、実装を一意に確定できるレベルまで設計書を記述するということはできるかもしれないが、それでは実装作業をしたのと同じくらいのコストがかかるはずであるし、そのくせ設計を動かして検証することはできないのだから、その設計で正しく動く保証もない。いくら時間や金をかけてレビューしたり見直したとしてもつまりマイナスでしかない。実装面から見ていくら抜けがあろうとも設計者にとってみればそれでもさまざま考えた挙句の成果物なのであるし、人間だれしも限界はあるわけで、こんなことを考えるのは無駄な努力という気がする。

結局のところ設計は実装の裏打ちがなければ正しいと断定することができないのではないか。であれば、設計が正しいと断ずるところですでに実装があるべきのように思われる。 （証明可能なソフトウェア設計書というのは少なくともこの21世紀にあってまだ登場していないとおもうが、もしご存知の方があれば教えていただきたい）

個人的にこの頃、設計と仕様という言葉は意識的に使い分けている。設計はあくまで計画だ。実際にできているものとは異なる。仕様はできているもののありようを説明するものだ。だから、本質的に設計は仕様ではないし、仕様は成果物に基づいて記述されなければならない。さらにいえば、本来的には両方存在しなければならないのだろう。（どちらかしか成果物として定義されていないプロジェクトがほとんどだし、両方を成果物として作成する時間をあらかじめ見積もっているプロジェクトなんて見たことない）

個人的にはだいぶ以前から、「プロジェクトにかかわるすべてのステークホルダーそれぞれに対して、それぞれに説明するためのドキュメントが本来発生するはずである」という考えを持っているのだけど、その中で、設計書は設計者から実装者へ、仕様書は実装者から実装以後のプロセスに関わる人たちの一部に対して書かれるべきものとして捉えている。

設計が計画であるということを意識すれば、それを使って行うことのそれぞれがどのような意味を持つかが少し変わってくるかもしれない。設計をレビューするのは、計画をレビューするということであり、それによって仕様が説明されるわけではない。仕様をレビューしたいのであれば、成果物に基づいて行う必要がある。

効率を考えれば設計書なんてほとんど正式な文書として存在する意味がない現場も多いだろう。実装を始めるために、最終的な出来を全体で共有するためのイメージや、全体的に重複した作業を共通化したりなどの段取りのためにもちろん事前の設計はあったほうがいい。が、それだけのことかもしれない。ただ、安定的に速やかに実装を確認できるレベルに持っていけること（あるいはその確信）が前提にはなる。先に述べたとおり最終的な決定としてのレビューや承認はそれに基づいて行われるべきなのだが、現時点で経験的に考えられる以上にレビューの差し戻しが発生することが予想され、それを実装力でカバーできるという素地は必要になるだろう。

「実装力でカバー」できなくなると、多分言った言わないとかスコープがどうのの議論になるので、それを回避するために設計フェーズという知恵が生まれたのかもしれない。ちょっと話がそれるが、そう考えると、やはりアジャイルソフトウェア開発宣言とはまず設計フェーズの破棄であるような気がしてくる。設計フェーズとはまさに「お前、最初にこう言うたやん」の言質をとるために必要で、アジャイルはそんなやりかたは（より）価値がないと考える、という宣言だとおもっている（私は）。

まあその話はいい。

そういう意味では、実装の熟練者がプロジェクトの早期から入る必要があるはずだ。設計を作る傍ら、フィージビリティとユーザビリティの裏打ちのために実装も開始しなければならない。そうすればたぶん、実装者と設計者は実装を中心に話をすることになるだろうし、Excelを介して探り合いをする必要はなくなるんじゃないか。

まあこんなことを言ってても直近では何も解決しないんだけど。

WSH(JS) からExcelのセル読み取ったりなんだりする

しょっちゅう忘れて一から調べ直すはめになるので記録しておく。

トピックとしては:

• windows の WSH(Windows Script Host)
• スクリプトの置かれているパスを求める
• 引数をとってチェックする
• javascript でActiveXObjectつかってExcelを自動操作的な事をしながらワークブックの情報をテキストに吐き出す。
  • テキストストリームの簡単な使い方
  • Excel オブジェクトのハンドリングと、ブック、シート、セルのアクセスの仕方

といったところ。

あー、main の中で return 1 とかやっても意味ないです。たしか。 WScript.Quit(1) とかしないと行けないはず。

WSH(JS) からExcelのセル読み取ったりなんだりする