hirax.net::Keywords::「開発」のブログ

■画像処理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ライブラリに実装された折にでも、適当にサービスを立ち上げてみたいな、と思っています。

■LEGO Mindstorms NXT でロボット開発　

　リアルタイムOSであるOESK RTOS(TOPPERS/OSEKをLEGO NXT 向けに移植した nxt OSEK)で動く LEGO Mindstorms NXT　を見ていると、自分でも色々なロボットを作ってみたくなる。たとえば、下の動画は Simulink(…と各種ToolBox)　でロボットの制御プログラムを書き、Embedded Coder Robot NXT で LEGO Mindstorms NXT 用にコンパイル・実行したものである。まさに、昔子供（こども）だった大人心をくすぐる「大人の玩具（おもちゃ）」だ。

　もちろん、Simulink といった値の張るツールを使わずとも、複雑な色々な制御を短時間にコーディングしようと思わなければ、制御プログラム開発はできそうだ。というわけで、「nxtOSEKアプリケーション動画」の数々を眺めていると、小中学生のこどもの「夏休みの課題」にかこつけてLEGO ロボットを購入し、ロボット・ハッキングで真夏の暑い夜を過ごしてみたくなる大人も多いはず。

■伸びない人は「銀の弾丸」を捜し求める。　

荒井玲子「ソフトウェア開発 で伸びる人、伸びない人 (技評SE新書002) 」から。

伸びない人は「銀の弾丸」を捜し求める。

■「RICOH & Java Developer Challenge 2010」の参加募集を開始　

　リコー、「RICOH & Java Developer Challenge 2010」の参加募集を開始

　リコーは、Javaプログラミングの経験を持つ日本国内の大学の学生/大学院生および指導教官を対象とした、同社のデジタル複合機(MFP)上で稼動する Javaによるビジネスアプリケーションの開発技術を競うコンテスト「RICOH & Java Developer Challenge2010」の参加募集を開始した。同コンテストは、欧州で4回開催され、日本でも2008年より開催、今回で3回目となる。

　コンテストでは、エミュレータを用いて開発したプログラムによる一次選考を実施。同選考の通過チームに対しては、MFPが貸出され、2011年1月の最終選考に向けた実機でのプログラミングが行われることとなる。最終選考会では独創性、システムデザイン、プログラムの完成度、MFP上でのデモンストレーション、プレゼンテーションスキル、技術資料の品質などが評価の対象となる。

■「たった３行で書けた」もの…「それ全然ガウシアンフィルタじゃないです」　

　「たった3行で書ける、iPhoneでお手軽ガウシアンフィルタ」という記事を読みました。

　特別なライブラリやカテゴリを使わなくても、iOS標準のフレームワークだけで、超簡単にガウシアンフィルタ(ぼかし効果)をかけるテクニックを紹介します。

たった3行で書ける、iPhoneでお手軽ガウシアンフィルタ（iPhoneアプリ開発トピックス）

…記事を眺めながら、違和感を２つ感じます。

　まず１番目の違和感は、記事中に貼り付けられているボカし画像（たとえば右に貼り付けた画像）が、「どう見てもガウシアンフィルタじゃない」ということです。「滑らか」じゃなくて、近傍線形補間特有のテクスチャが自己主張激しく現れています。

　そして２番目の違和感は、「画面上で拡大補完をするという状況でガウシアンフィルタを掛けたのと同等のことを実現するようなコードなんて（ライブラリを実装するのに）書かないよね、書けないよね。…計算量と効果を考えれば開発者には当たり前の話だけど…」というものです。

　というわけで、記事に貼り付けられていた「ガウシアンフィルタ(ぼかし)」画像のRed・Greenチャンネルの数値を、３次元グラフにしてみました。それが下の２枚のグラフです。

　こうしてみれば、この画像には「ガウシアンフィルタを掛けたような滑らかさ」なんてなくて、見事なまでに近隣４画素からの線形補間がされた画像であることが見てとれます（ガウシアンフィルタはNxNでも計算コストが2Nで済む…とはいえ近傍４点線形補間に比べれば多いですから、”開発者”からすれば当たり前のことだと思いますが…）。