hirax.net::Keywords::「ビジュアル言語」のブログ

■「ビジュアル言語」　

　グラフィカルな表現でプログラムを表現しようという「ビジュアル言語」の話を読んだ。この記事を読んで、ふと思い出したことがあった。

　計測・制御などをする場合、National InstrumentsのLabVIEWや、CYBERNETのSimulinkといったツールを使うことが多いように思う。いずれも、（基本的には）アイコンをワイヤー（線）で結ぶ「ビジュアル言語」である。少し前の実験系の理系学生であれば、誰でも98BASICでGP-IBを操作するプログラムを書かざるをえなかったように思うけれど、現在では、そういった場合に使われるツール群がLabVIEWやSimulinkといった辺りに移行しているように感じる。LabVIEWやSimulinkをPC BOX上で動かして計測や制御を行った上で、さらにはFPGAやASICにしてしまう、ということもある。

　こういった「ビジュアル言語」を触り始めたとき、苦手だったことの一つが、「どこから実行されるのかわからない」「どこから眺めて行けば・理解すれば良いのかわからない」ということだった。そして、しばらくそういうツールを使ってから、ようやく気づいたのが「どこからも実行されている」ことを理解していないとダメなんだな、ということだった。「あらゆる箇所で並列計算が行われている」と普通に思えばよいのだな、ということだった。

　VHDLなどのハードウェア記述言語では、基本的に、すべての部分が同時に動作する。行番号順に実行されたりするわけではない。そういうことは回路図という「ビジュアル言語」を見たら当然のように理解できるかもしれないが、そういったことはVHDLを見ただけではわかりにくい。どうしても、上から順番に実行されるような感覚で読んでしまう。最初の頃には、そういう感覚でLabVIEWやSimulinkのダイアグラムを眺めていたので、「どこから実行されるのかわからなくてイヤ」と感じいてたように思う。

　もう一つ、画像処理に「ビジュアル言語」が向くだろうか。私が素人だからかもしれないが、そうは思えない気がする。

■ビジュアル画像スクリプティング環境を作る　

　「ビジュアル簡易スクリプティング環境」を作ってみようと思う。画像処理プログラミングに「ビジュアル言語」が向くかどうかは疑問なのだけれど、既存の処理の「組み合わせ」だけを変えるだけですむような用途であれば、そして、GUIの設計も同時に行わなければいけないような用途であれば、「ビジュアルなスクリプト」でも良いような場合もあるかもしれない。

　ひとまず、操作感はYahooPipesを模範にし、処理データはImagePipesに準拠するようにして、叩き台を作ってみることにしよう。

この記事の「関連お勧め記事」を読む  >> 

■画像処理WEBアプリを簡単作成用「ビジュアル言語」を作る　

　「ビジュアル言語」風の画像処理WEBアプリの叩き台を作ってみました。 いえ、正確に言えば、そんな「ビジュアル言語」環境を作ってみました。つまり、画像処理WEBアプリを簡単に作れる!?「ビジュアル言語」を作ってみた、ということになります。

　ここで言う「ビジュアル言語」という言葉には、３つの意味合い・特徴があります。

1. 処理構造をグラフィカルな部品・ワイヤーで表現・作成すること
2. 各場所で処理されている「データが見える」こと
3. 部品・ワイヤーを並べ終わった画面そのものが「アプリケーション」のGUI画面となっていること

　1,2番目の項目だけでなく、この3番目の点を意識しながら作ってみました。といっても、「叩き台」なので、デザインはいかにも開発時用（デバッグ用のデータ構造が見えたりする）など、イマイチな部分はありますが、イメージを掴むことはできるだろう、と思います。

　ブラウザ上の操作感は（UI周りはWireItライブラリを使っていて）YahooPipesを模範にしています。また、処理データ構造は（YahooPipesを意識した）ImagePipesに準拠するようになっていて（つまりある程度緩い規約にもとづいたJSONになっていて）、 「オブジェクト」に対してユーザが何かしたり、あるいは、入力部に他の部品からメッセージを受けた時に、Javascriptでクライアント内部で処理をしたり、あるいは、サーバに対して同期リクエストを送ることで、出力結果を生成し、そして出力ポートの先にある他部品に結果メッセージを送信する、という作りになっています。

　下の動画がその「叩き台」アプリケーションの動作動画です(高解像度画像もここに置いておきます)。この動画が「何をしているか」を箇条書きすると、

1. 「画像をアップロードするフォームパーツ」を作り（出力はアップロードされた画像情報を示すJSON）
2. 入力を２出力に分岐する（JavaScriptで書いた）部品を配置し
3. 入力された(JSONで表現されている)画像を表示する部品を置いて
4. 部品間をワイヤーをつなぐ

これで、「画像アップロード＋いくつかの処理＋画像表示」WEBアプリケーションのコード実装や画面設計が終了した……ということになります。というわけで、画像処理WEBアプリを簡単に作れる!?「ビジュアル言語」を作ってみたのです。「画像処理ジェネレータを作るジェネレータ」みたいなものの高機能版を、「ビジュアル言語」で作ってみたわけです。

　WireItがYahooUIライブラリに実装された折にでも、適当にサービスを立ち上げてみたいな、と思っています。

■続 WEBベース「ビジュアル言語」を作る　

　『画像処理WEBアプリを簡単作成用「ビジュアル言語」を作る』で作成した叩き台のイメージは、「データ処理フローを並べ終わった瞬間に、基本的にはアプリケーション作成（と簡単なテスト）が終わっている」というものです。「並べること」が「 プログラミング」「画面デザイン」「初期テスト」のすべてを兼ねていること、が大切で、そういう「ビジュアル言語」を作ってみたかったのです。「アイコンを並べたあとに "RUN" ボタンを押してプログラムを走らせる」とか「アイコンを並べコーディングをした後に、今度は画面デザインを別画面で設定する」なんて面倒なことはしたくない、と思ったのです。

　そういう作りをイメージした理由の一つは、画像処理アプリケーション（おそらく多くのデータ処理アプリケーション）は、「画像アップロード（データ入力）部」「スライダーやテキスト入力による数値入力部」「データ選択」「フィルタ（演算）処理」「種々の特性の表示部」といったせいぜい数種の比較的限られた機能を並べることで作られていることが多い、ということです。その並べ方にアプリケーションの特徴があったりするわけです。

　また、それぞれの基本パーツはどれもJavaScriptで覆われていることで機能拡張を楽にしたい、という構想設計ならぬ妄想設計に基づいています。5,6種類の数少ない機能を持つ基本パーツを作ってしまえば、あとはいかようにでもできるだろう、というイメージです。

　たとえば、「フィルタ（演算）処理」なんかは、JavaScript中のSJAX先アドレスを変えるだけで（それらアドレスに応じたサーバ側コードは当然用意するとして）、色んな画像処理フィルタを自由に作ることができるわけです。そういう風に基本パーツを継承した派生パーツを作っても良いし、あるいはパーツの組み合わせでさらに新しいパーツ（関数）を作っても良いわけです。以前 Imagenerator でもやったように、いくつかの簡単な機能を組み合わせたものを、さらに一個のパーツ（関数）として保存できるようにしておけば、機能を増やすことも簡単にできるだろう、ということになります。

　……と書くより、ひとことで言ってしまえば「何だかそれって面白いな」と自分で思えるものを作って遊んでみたかった、ということですね。
　データの送受信が、(下の動画（高解像度版）のように)グニュグニュと揺れ動く振動や画像の変化で実感・体感できたり、それがJavaScriptでラップされている設計構造とか「何だかそれって面白い・楽しいかも」と遊んでみたかっただけ、なんですよね。ひとことで書いてしまえば。

■ビジュアル言語を作ってみたくなる「JavascriptライブラリWireItの進化」　

　WireItが実に便利に進化している。こういうものがあると良いな、と心から感じさせてくれる方向に開発が進んでいる。たとえば、WireItを使ったサンプルアプリケーションのJsBoxをいじってみれば、その「こういうものがあると良いなぁ・面白いよなぁ」と感じ、がわかると思う。

　WireItライブラリを使えば、自分なりのビジュアル言語を簡単に作ることができる。しかも、JsBoxのようなサンプルを眺めれば、自分が考えたビジュアル言語で作った「ひとかたまりの機能」をさらに関数化する方法などを学ぶこともできる。「JavascriptライブラリWireItの進化」を見ていると、マイ・ビジュアル言語を作ってみたくなる。