システム開発で，「あればいいのに」と思う７つのもの

以下のものが，あればいいのに。

「レガシーJavaScript」に関する情報が完全に除去された，Google検索結果。

Windowsのウィンドウ部品を，jQueryのように操作できる，セレクタAPI。

COM経由で，マウスを自動操作するAPI。

「アプリケーションとしてのコマンドプロンプト」を扱うための，確立された方法論。

.NET化され，単体テスト手法の確立した，VBA。

クロスブラウザで，ブラウザを自動操作するための，共通言語。

動的型付け言語のメトリクス解析ツールと，それをリポジトリに組み込むためのプラグイン。

（１）「レガシーJavaScript」に関する情報が完全に除去された，Google検索結果。

きょうから2011年なわけだが，

2010年までの2000年代後半の間，「プログラミング言語としてのJavaScript」の地位は急速に上昇した。

JavaScriptが第一級のプログラミング言語へ、分散バージョン管理にも注目が集まる
http://www.publickey1.jp/blog/10/java...

だから，開発者は，モダンJavaScriptに関する良質の情報を，切実に必要としているわけだ。

需要がある。

にもかかわらず，ふつうに検索すると

「e3で動作します」

「NN4で動作しないのですが」

のような，読んで力の抜けるWebページが，Google検索結果の最上位を独占している。

化石時代のJavaScriptに関する情報を，見えなくしたい。

「レガシーJavaScript」に関する情報が完全に除去された，Google検索結果が，あればいいのに。

私は，その点に怒りを覚えていた。

だから，以下のエントリを書いた。

JavaScriptの動かないコード　　(JavaScriptエラー集)
http://language-and-engineering.hatenablog.jp/entry/20080912/1221297779

上記エントリは，JavaScriptのアンチパターン集ではあるのだが，

実は，「JavaScript中級文法を学ぶための情報を集約するための置き場，スペース」でもあるのだ。

ここを見れば正確な情報が手に入る。

そういう信頼性があって，

そのWebページ上に「動作するコード片」が，良質のサンプルとして掲載されており，

そのコード片を一瞬でカット＆ペーストしてローカルでの開発作業に問題なく統合できるような，

そんなWebページがあればいいのに，と思っていた。

結局，自分で作るしかなかった。

とはいえ，まだまだ情報不足だから，情報源を探索し続ける日々。

Google氏には今でも頼らざるを得ない。

Google検索結果も，刷新されればいいのに。

（２）Windowsのウィンドウ部品を，jQueryのように操作できる，セレクタAPI。

デスクトップのGUIアプリを自動操作する時に，以下のように書けたらいいのに。

$("window[@title='アプリケーションタイトル'] > pane[@width>300]")
	.find("button#btnSubmitConfirm")
		.sendKeys("ENTER")
			.next()
				.selectPullDown("希望しない")
			.end()
		.end()
	.find("button#btnSubmitOK")
		.sendKeys("ENTER")
	.end()
.end();

jQueryのセレクタAPI，および属性操作のための関数群は，強力だ。

$("input:not(:checked) + span").css("background-color", "yellow");

とか

$("div.section")
  .find("dt")
    .addClass("section")
    .onclick()
      .next()
        .toggle()
      .end()
    .end()
  .end();

JavaScript < jQuery < Lisp ?
http://d.hatena.ne.jp/amachang/200708...

私は，これをWindowsアプリでも利用できれば，と思う。

WSH（もしくは，VBAや，UWSC）から，GUIアプリを自動操作する時に，

いちいちWindowをActivateして，TABキーでボタン要素まで移動して，EnterキーをSendkeysする，

なんて面倒なことは，疲れた。

DOMモデルのような構造定義を，Windowsアプリにも持ち込んで，

なおかつ（COMとかを経由して）そのモデルを自由に触らせてもらえないだろうか。

まるでCSSを扱うように，Windows部品の属性を動的に操作させてもらえないだろうか。

もちろん，モデルがあったとしても，各種属性（ボタンのIDとか）はリバースエンジニアリングしないとわからないんだけど。

ネイティブのWindows部品（＝生の「ウィンドウ」）は無理としても，.netとか特定の基盤の上のアプリだけは対応してもらえないだろうか。

そうしたら，それは「自動化のイノベーション」なんだが。

誰か，無理やり作ってくれまいか。

（３）COM経由で，マウスを自動操作するAPI。

JavaScriptからも，WSHからも，マウスポインタを自動操作できない。

私は，この事にも怒りを感じていた。

なので，以下のエントリを書いた。

コマンドラインからマウスを操作する方法　（rundll32.exeで動くDLLの作成法）
http://language-and-engineering.hatenablog.jp/entry/20081117/1226943698

そしたら，便乗して，私のエントリのパワーアップ版として以下のエントリを書いてくれた人がいた。

WSH JScriptを使いこなそう〜マウス操作〜
http://3rd.geocities.jp/kaito_extra/Source/MouseCtrl.html

この調子で，「マウスの自動操作」が一般化し，

世間にいっそう流通し，

十分にテストされた，そのためのデファクト・スタンダードな手法やライブラリが出回ってくれればいいのに。

そうすれば，それもまた「自動化のイノベーション」なんだが。

そして，UWSCが不要になるのだが。

（４）「アプリケーションとしてのコマンドプロンプト」を扱うための，確立された方法論。

例えば，「batUnit」のような単体テストツールがあればいいのだが。

そして，非構造化言語としてのMS-DOSの可能性を限界まで突き詰めたノウハウが，

まとまって集約されて提供されてくれると嬉しいのだが。

例えば以下のようなノウハウが。

１つのファイルをBATファイルとしてもWSH用スクリプトとしても起動可能な，WSH用shebang
http://d.hatena.ne.jp/miya2000/200908...

バッチファイルで配列を使う（環境変数を使って配列変数風に使う）方法について
http://d.hatena.ne.jp/jak-san/2009030...

そして，「システム開発におけるBATのポジション・役割」がより一層明確化され，

コマンドプロンプトに対する世間からの評価が見直されればよいのだが。

それ無しには，旧世代のWSHも，次世代のPowerShellも，

よりいっそう普及する事は不可能と思うのだが。

※2013/5月に追記：下記のエントリで，「ノウハウの集約」というタスクを，擬似的に実現した。

開発に役立つ，BATファイルの書き方・パターン集　（コマンドプロンプトの定石を体系的に学び，バッチ中級者になろう）
http://language-and-engineering.hatenablog.jp/entry/20130502/PatternsOfMSDOSo...

（５）.NET化され，単体テスト手法の確立した，VBA。

Excelは，うまく活用した場合，開発生産性が非常に高い。

システム開発生産性が最も高い言語
http://itpro.nikkeibp.co.jp/article/C...

理由としては

モデルがそのままビューになっているのでアプリ基盤の構造が単純。

そのわりには，フォーム部品を設置したり，ビューの自由度も広い。

WindowsネイティブのAPIも呼べるから，何でもできる。

事務系ツールとして，ビジネスシーンでは「誰でも持っている，誰でも使える」。

VBAが「何でもできる」は，本当。

例えば，Excel VBAだけでWebサーバが作れる。（Cより面倒だが）

VBAでTCP/IPサーバー(1)
http://www.serpress.co.jp/winapi/no01...

にも関わらず，Excelを操作するための言語「Excel VBA」は，言語としては，終わりつつある部類のものだ。

しかも，Excel VBAを扱うための唯一のIDE「Visual Basic Editor」の使い勝手たるや，これも，要するに駄目だ。

VBA で map とか fold
http://igeta.cocolog-nifty.com/blog/2...
「VBA には VBA のやり方がある。ただ僕は、目の前に並べられたメンテナンス性の欠片もないレガシー資産を抱えながら、後輩にまでこんな思いはさせたくないと願い、行動するのだ。
それにつけてもつくづく思うのは、組み込みキーワードとしての Let と Set は、レガシー VB の抽象化能力を大きく妨げているってことだ。それがなくなったとして、すべてが解消されるわけではないだろうけど。」

VBA より便利で手軽 Excel 操作スクリプト言語「Ruby」へのお誘い
http://jp.rubyist.net/magazine/?0027-...

VBA での文字列操作の不満やイライラ

ミスタイプしたままに別の行にフォーカスを移動すると、文法エラーのメッセージボックスが表示される

「Visual Basic Editor上で快適に作業できます」と言えるためには，マイクロソフトが用意した，手続き型の頭脳を自分のものにしなくてはならない。

改善要望は多い。　ビジネス要件の変化が速い時代なので，それに対応できるようにしてもらえまいか。

具体的に言うと，

言語を抽象化し，オブジェクト指向を完全に取り入れよ（せめてVB.NETぐらいの使い勝手が欲しい）

リファクタリングしやすいIDEを準備せよ

本格的な単体テスト環境をください

などの要望になる。

「VBAから.net Frameworkを呼び出せる」だけではなく，

言語そのものを VB.net （VBA.NET）にしてほしい，ということ。

※VBAから.NET Frameworkを使う
http://officetanaka.net/excel/vba/tip...

事情がどうであれ，私はVBAを使い続ける。

なぜなら，ドキュメントを「実行可能」にするために必要だからだ。（仕方のない必要）

しかし，どうか，VB６をいつまでも引きずらないでほしい。

Excelには生産性の高い開発環境としての価値が，可能性があるのだから。

「実行可能ドキュメント」が満たすべき性質　−　テスト自動化ツール「Excelenium」で使われている技術や手法
http://language-and-engineering.hatenablog.jp/entry/20101112/p1

画面のスクリーンショットを，Excelブック内に自動的に保存するバッチ
http://language-and-engineering.hatenablog.jp/entry/20100425/p1

WSHに制限があるのは仕方ない。
ならば，かわりに制限のないアプリケーション基盤を見つけて，WSHからコールして利用すればよい。
そのために最適なのは，Excel VBAではなかろうか。
魅力は，

Windows APIを自在に組み込めるプログラミング環境であること。

ドキュメントという成果物に対して，非常に近いポジションに存在すること。

など。
特に，前者はでかい。
わざわざC言語で，バッチ呼び出し専用のDLLを作ったりしなくて済むのだ。

（６）クロスブラウザで，ブラウザを自動操作するための，共通言語。

Seleniumを使うための言語を「Selenese（セレニーズ）」という。

セレニーズは，「クロスブラウザでブラウザを自動操作するための，共通語」と言える。

しかし，「COM経由でのIEの自動操作」と比べると，Seleniumシリーズにはまだまだ制限が大きい。

COM経由で，あるいはクロスドメイン制限やファイルアップロード制限のない，

任意のどんなグラフィカルな基盤でもよいので，

任意のブラウザを自動操作するための「共通言語/共通API」（DSL）があればいいのに。

「upload_file()」というただ１つのコマンドでファイルがアップロードされてほしいし，

「drag_drop()」という関数で，Webページ上のDOM要素が指定位置までドラッグドロップされてほしい。

IEでも，FFでも，Operaでも，Safariでも，Chromeでも，だ。

そうすれば，Webアプリの自動テストについて，やはり極めてinnovativeなのだが。

（７）動的型付け言語のメトリクス解析ツールと，それをリポジトリに組み込むためのプラグイン。

要するに，rubyとかPerlで開発してる時に，「変なコードをコミットさせたくない」のだ。

コーディングスキルの低いメンバが，「コミットエンドラン」するのを，強制的に防ぎたいのだ。

リポジトリを「守りたい」。

私は，これを考えた時に，まず「SVNコミットをサーバ側でフックしてバリデーションするには，どうすればいいんだろう？」と考えた。

その結果，以下のエントリを書いた。

SVNで，コミット時にログの入力を強制する　（Windows版subversionのサーバ側フックスクリプトの作成方法）
http://language-and-engineering.hatenablog.jp/entry/20100819/p1

上記エントリの下のほうに，

「補足２　
いちおう，コミット内容のソースコードもフックスクリプトから参照できる。
下記は，特定のパスのソースコード内で，特定のキーワードの利用を禁じる例・・・

とある。

この方法は，だめだったのだ。重すぎた。

動的言語を静的に解析して，それをフックにするなんて，いちいちやってられるほど軽くなかった。

だから，私は，次に以下のエントリを書いた。

バッチで，コーディング規約を守らせよう　（全ソースコードをチェックして，ルール違反を自動検出）
http://language-and-engineering.hatenablog.jp/entry/20101208/p1

フックにできないなら，日次バッチにするしかない・・・。そう考えた。

そして，このバッチは実際に，一定の効果を奏している。

だが，欠点はなお残っている。

「静的解析」と言えるほどの解析はしていない。

だめなコードのコミットを，事前防止できるわけではない。

これらの要素を解決してくれるような，動的言語の解析ツールと，

SVNプラグインがあればいいのに。

もちろん，物事の限界はわきまえている。

もとから，NetbeansとかEclipseなどのIDEを土俵にして考えた方がいいのかもしれない。

また，テスト駆動の徹底や，ペアプロの徹底がもしできるのであれば，それでもいい。

でも今は，上記にあるような事ができれば助かるのだ。

結び

以上，システム開発で「あればいいのに」と思う７つのものを取り上げた。

これらは私が開発行為に対して継続的に抱いているニーズ（のごく一部）であり，

今後，シーズ探索の際の原動力となるだろう。

ニーズがあれば，シーズもつかみやすい・育てやすい。情報を吸い寄せやすい。

私が公開したマウス自動操作の自作APIを見て，それを拡張して再公開して下さった方が実際存在するように，

ここに挙げた７つのニーズの叫びも，誰かが聞いてくれるかもしれない。

その誰かとは，Google検索でここを偶然訪れた誰かかもしれないし，

将来の私自身かもしれない。

おまけ

このブログは，システム開発だけでなく，言語も取り扱うブログである，

という事になっている。

なので，言語の分野で「あればいいのに」と感じているものを，最後に一つだけ掲載する。

（８）「CDエクスプレス　日本語古文」と，「CDエクスプレス　漢文」。

学生時代，古典文学の授業には，常に違和感を覚え，欲求不満だった。

いわゆる「古文」「漢文」は，れっきとした外国語である。

したがって，教師も，れっきとした外国語教育としてそれらの科目を扱うべきだ。

そういつも思っていた。

CDエクスプレスシリーズは

左側ページに，スキット（外国語原文の会話や短文集）

右側ページに，和訳と単語集

という構成になっている。

日本語の古文も，こうやって教えてほしかった。

恐らく，「CDエクスプレス　古典ギリシャ語」「CDエクスプレス　ラテン語」あたりの構成と類似させるのが一番良いのではないか。

そんな入門書があったら，私は，もっと古典を学びやすかったのに。

仕方ないのはわかる。

もし，古文の学び始めの段階で，その人が英語も満足に学習しておらず，

外国語学習の経験が浅いのであれば，ああいった伝授方法が最適なんだろう。

「竹取の翁」の数ページ全体をいきなり見せて，

フィーリングで全体を読ませて，だんだん古文に親しませる，

という教育方法を取るしかない。

だが，

動詞の変化（人称・法・態）

名詞の変化（性・格変化）

などに慣れ親しんでいる段階であれば，もっと別の学び方があるだろうに。

でも残念ながら，そういう人向けのポピュラーな古文・漢文入門は，ない。本も情報もない。

時間とスポンサさえあれば，私が出版するんだがね。

誰か執筆して下さい。

もし出版してくれれば，今からでも，私はその本を買う。仕事の息抜きに読む。

そしてマスターしようとするだろう，古文漢文を。。。（もし読み書きできれば，歴史がわかって面白いと思う。）