WireframeSketcher でワイヤーフレームドキュメント作成

以前、サイトを眺めてすごいなぁと思っていたものの、有料($99)だったため試さなかった、WireframeSketcher を本日購入してみました。

用意された部品や操作系を元に、アプリケーション開発時のワイヤーフレームやモックアップなどのドキュメント作成を支援するソフトウェアです。 SI の世界だと、エクセル方眼紙でやっちゃうような、外設の画面設計書をつくるの、で通じるでしょうか(笑)

WireframeSketcher

WireframeSketcher is a wireframing tool that helps designers, developers and product managers quickly create wireframes, mockups and prototypes for desktop, web and mobile applications. It’s a desktop app and a plug-in for any Eclipse IDE.

デザイナー、開発者、プロダクトマネージャさん向け。

Eclipse GEF/EMF ベースでつくられており、Windows、Mac、Linux 対応。ダウンロードしすぐ実行できるオールインワンのスタンドアローン版の他、Eclipse プラグイン版も用意されています。

130422-0007

下のような、描くのも変更するのも大変そうなイラストが、

wp_tree_f

次のテキスト入力だけで作成できてしまう。。

wp-content
-plugins
--otenki
---otenki.php
-themes
--[v] twentyeleven
--[v] twentytwelve

[tegaki]なんてことだ…[/tegaki]

このことだけで、なんでもっと早く試さなかったのだろうと後悔です。。15日のお試し期間中の 1 日目で購入してしまいました。

以下、これまたどう考えても描くの面倒だろうJK、と言われそうな一覧表とフォームの組み合わせも、

130422-0019

こんな感じのテキストでサクッとつくることができます。

130422-0020

あっという間。。 🙂

試しに、このサイト hiromasa.another のモックアップを作成してみました。

130422-0011

出力を手書き風味にできるのがポイントで、(お客さんなどに)まだデザインとかはイメージですよ、というようなことを表現できるとのことです。

ちなみに Screen のプロパティーを Sketch から Clear に設定することで、びしっとすることもできます。

130422-0002

びし。まっすぐ。

130422-0010

WireframeSketcher の操作はパレットビューより部品を選択し、ぺたぺた貼り付け、それぞれの個別属性を指定していく感じです。

部品は PC 用、モバイル、Android、iOS、Web フォームなどなど沢山。 これらは一般的な .svg 形式で、フォーマットに従えば自分で描いた絵も部品に取り込むことができるようです。

130422-0021

ブログのコメントフォームを描いてみたの図。

130422-0022

ドローアプリとしての操作感は、利用開始当初、レイヤー機能がないため若干厳しい部分あるかなと思いましたが、アウトラインビューなどからのZオーダ設定、グルーピング系と、そのグループへの突入(?)、またプロパティーからの位置ロック操作をうまく使えば、問題なく描くことができると感じました。

130422-0023

画面上、オブジェクトの単一選択と矩形選択の切り替えの UI がぱっと分かりませんが、(Fn + ) F3/F4 でそれぞれに切り替わります。クリック to ドラッグの範囲選択において、カーソル位置のオブジェクトを引っ張りたくないケースでは F4 を押すといいと思います。

さて、WireframeSketcher の良いところのひとつは保存形式に XML のテキスト形式が用いられていることで、さらに画像となる .svg ベクターデータと、骨組みとなる .screen データは完全に分離されています。

このため、骨組みの .screen の変更履歴をみると、どの部分が修正されたかが分かります。

130422-0016

スクリーンショットは新旧ファイル差分を出した図。–File Three が増えてその下のアイテムの y 座標が増えたことが分かります。

このように、WireframeSketcher はテキストファイルベースのデータ形式を採っているため、ローカルヒストリーの利用や Subversion、Git などバージョン管理との統合も得意です。

Eclipse マーケットから EGit や Subclipse などを追加することで Git や SVN が使えるようになるハズです。(スタンドアローン版 は Eclipse Juno ベース。自分は Eclipse Juno for JavaEE に WireframeSketcher をプラグインの形で入れました)

さて、ぼくは普段からドキュメントの作成に Eclipse Mylyn の .textile サポートを使っていましたので、今回ワイヤーフレーム作成に WireframeSketche という心強い見方が統合されたことになります。

ワイヤーフレームはもちろん、ちょっと億劫だなと思っていた図形の描画もできるようになってとても嬉しいです。 🙂

130422-0018

ブログ”徹底解析”シリーズを Eclipse で書いているの図。

日本に一人しかいないんじゃないかと思うくらいの Eclipse の利用法ですが、ソースコード見ながら記事を書くことが多いので、この使い方はすごく便利です。(ちなみに 300ページの原稿に耐えてます)

上記スクリーンショット下部は、PlantUML。これもテキストベース図形描画 & Eclipse プラグインあり。 UML を描くツールですが、これがまた色々な用途に使えるのです。

PlantUML についてはプログラマーズ雑記帳さんが非常に参考になります。(とても助かりました!)

PlantUML の使い方 | プログラマーズ雑記帳

テキストから UML を生成する PlantUML についての解説記事を書いてみました。

PlantUML の Eclipse プラグインについては、そのうちまた。 🙂

JavaScript デバッグ環境の用意(JSDT + Firebug + Crossfire)

前回に引き続きまして JavaScript の開発環境構築です。 今回は、少し大きなプログラムを作り始めるとなくてはならないデバッガを設定してみます。

JavaScript のデバッグ環境は、IE の開発者ツールや Firefox の FIrebug などでも準備できますが、ここでは Eclipse WTP/JSDT の環境のビューから直接ブレイクやウォッチをする方法をかいてみます。

WTP/JSDT についてはこちらです。

JavaScript 開発環境の用意(Eclipse WTP/JSDT) | hiromasa.another :o)

Eclipse に含まれる Web Tool Platform(WTP)には、JavaScript Development Tools(JSDT)が含まれており、おそらくみなさんがインストールしているであろう、Eclipse for  JavaEE Developer に最初から含まれています。

JSDT からブラウザの JavaScript にリモートアタッチしてデバッグする方法はいくつかあるようですが、JSDT の標準インストールで FIrebug / Crossfire プロトコルに接続して行うパッケージが入っていますので、こちらを用いてみました。

JSDT/Debug/Crossfire – Eclipsepedia

Support for remote Firebug using the Crossfire protocol is available in the JSDT development bundles and is provided to allow remote debugging of JavaScript using Firebug via Crossfire.

まず、Firebug / Crossfire を使うために Firefox に Firebug と Crossfire アドインをインストールします。 Crossfire の .xpi についてはこちらです。(下の方に .xpi へのリンクあり)

mrennie/crossfire · GitHub

Crossfire is a Firebug extension which implements a JSON protocol to allow remote clients (like an IDE or code editor) to connect to Firebug.

Firefox にアドインがインストールできたら、Eclipse から接続する準備を行います。Crossfire アドインのスタートがちょっとわかりにくいのですが、FIrefox の表示 -> ツールバー -> アドオンバーを表示して、右下のアイコンからスタートします。

130322-0001

アタッチポートを聞かれてくるので、ここではそのまま 5000 で起動します。

130322-0002

でもって、FIrefox でデバッグしたいサイトを開いて Firebug で一度「スクリプト読み込み」しておきます(これが重要)。ここでは Eclipse の jstest プロジェクトに配置された、http://127.0.0.1/jstest/index.html を開きました)

130322-0003

次に Eclipse 側のデバッグ構成をします。 デバッグ構成からリモート JavaScript に jstest 構成を追加します。 コネクターは Crossfire – Remote “Attach” を選択し、ソースからソースコードをマッピングします。

130322-0004

130322-0005

このステップで準備完了です。 そのまま右下デバッグボタンを押下すると、Firebug に接続され、先のアイコンが接続状態になり、Eclipse のデバッグプロセスも起動します。

130322-0007

何かデバッガの挙動がおかしいなと思ったらここから再起動してあげてください。なおります。(ブラウザとの通信状態によってブレイクポイントの位置などが不整合することがあるようです)

130322-0006

あとは通常の Eclipse のデバッグ操作です。 ソースコードにブレイクポイントをはってみます。 F6, F7, F8 キーなどでステップ実行やウォッチが可能です。

130322-0008

ブレイク中のウォッチはカーソルあてればホバーしてきます。

ふむ。

130322-0009

ほう。

130322-0010

ほほう。

130322-0011

変数ビューを使えば、Firebug から送られてくる生のブラウザの状態もみれます。

130322-0012

これを見ているだけでもブラウザの内部動作の理解ができますね。

この手順で Eclipse から Firebug にいったん接続すれば、あとはそっとしておいて大丈夫です。作業開始時にでもつないでおくといいでしょう。

機能的には Firebug でも当然同じことが出来ますが、Eclipse からであればそのまま見やすいソース表示でデバッグブレイクでき、変数ウォッチなどもビューを使って操作しやすいかなと思いました。 🙂

プログラムのなぞの挙動は、考えるよりデバッガひっかけたほうが解決簡単。論より run が座右の銘のひろましゃでありました。がってんがってん。(←調子が悪いとオチが弱くなるらしい・・・

JavaScript 開発環境の用意(Eclipse WTP/JSDT)

いわゆる業務系アプリをつくっている現場でも徐々にモダンな JavaScript の開発が導入されるようになってきました。もちろん今までもバリデーションやコントロールの制御に使われてきましたが、なんというかノリっていうか、Java プログラマーがその知識だけで、それとなく動くものをつくってきたように思います。

そのような昔ながらの JavaScript しかみていないと、jQuery などで使われている近代的な JavaScript 記述方法はもはや別の言語にも見えてしまいます(笑)

てなかんじで、そろそろちゃんと JavaScript を勉強しないといけないねって感じも含めて去年末にプログラムをかいたのが「バッタになりたい魔法使い」でした。

Web絵本|バッタになりたい魔法使い

wizard_ogp

内容の詳細はこちらを。:)

canvas と Web 仕掛け絵本 | hiromasa.another :o)

実際の実装ですが、絵本のコマに対して canvas タグを対応させ、CSS では canvas を display: block; してブラウザの描画領域を全て埋め、横幅、余白を含め全ての描画制御を JavaScript から行っています。たとえば、背景画像横幅が足りなければ CSS で真ん中にもっていくのではなく、”白”を画像の左右に描画しているイメージです。

さて、JavaScript は特に Java のような静的型付け言語しか知らない場合、非常に特異な言語に見えるかもしれません。プロトタイプベースのオブジェクト指向や、コンテキストの考え方など、一般的なプログラミング言語の常識が通用しない部分が多々あります。

またブラウザという実行環境についても知識が必要で、HTML/CSS の操作や、そもそもどこから言語の機能で、どこからブラウザの実装なのか分からなかったり、なかなか難儀なものです。

専門の人が現場にいればいいのですが、お客さんによってはそもそもこういったジャンルの仕事があると思っていない場合もあり、小技を持っている専門外プログラマーの英知をもって、ひどいものができるという惨状を目の当たりにし、ぼくはついに立ち上がった、、かどうかは分かりませんが、よくある Java の現場で JavaScript をかかねばいけなくなった時の環境の用意の仕方や、ちょっとしたテクニックを書いてみたいと思います。 🙂

良い仕事には良い環境から。

よくある Java の現場ってことで Eclipse を用いていますが、「バッタになりたい〜」でも Eclipse 使っています。この方法は普通に JS かく場合にも便利ですのでお試しを。

Eclipse に含まれる Web Tool Platform(WTP)には、JavaScript Development Tools(JSDT)が含まれており、おそらくみなさんがインストールしているであろう、Eclipse for  JavaEE Developer に最初から含まれています。

Eclipse から JS サポートをうけるには、使っているプロジェクトを「JavaScript プロジェクトに変換」してあげます。変換といっても、機能追加みたいなイメージなので、その他は現状通りです。

ここでは新規にプロジェクトをつくって変換しています。「JavaScript プロジェクト」を新規に作成することも出来るのですが、一般的によくやるワークスペース外の htdocs の下にプロジェクトを配置する操作を行うと、JavaScript リソースの設定がおかしくなるようなので、いったん別のプロジェクトから変換するというやり方をとっています。

130320-0001

jstest をプロジェクト名としました。

130320-0002

サンプル的にファイルを配置してみました。ここでは js フォルダの下にソースを置くとします。

130320-0003

プロジェクトを右クリックして、「構成 -> JavaScript プロジェクトへ変換」します。既存プロジェクトがある場合はここからの操作です。

130320-0004

この後、ソースファイルの配置などを決めるダイアログがでますが、そのままOKしてください。(どうもこの段階で設定などをすると JavaScript リソースがおかしくなるようです)

これでプロジェクトが次のようになると思います。

130320-0008

JavaScript リソースが追加され「ECMAScript ビルトイン・ライブラリー」と「ECMA 3 ブラウザー・サポート」が入れば成功です。補完などが効かなくなったら、この二つが正しく入っているかを確認します。(ここで書いている手順以外だと、ビルトインライブラリーが入らないパターンがあるようです。。)

このままだとJavaScript リソースがプロジェクト配下の全てのファイルを対象としてしまうので(特に問題はないですが)、ソースファイルの位置をプロジェクトの右クリック -> プロパティー -> JavaScript -> ソース -> フォルダの追加から指定します。(jstest/js にしました)

130320-0005

さて、これで準備完了です。ようこそ、JavaScript の世界へ。 🙂

統合環境はプログラム言語の勉強のよき先生です。特に、静的型付け言語の場合は、コンテンツアシストやインテリセンスといった補完機能やリアルタイムエラー出力などの IDE の強力な機能が、いろいろな手助けをしてくれます。

オブジェクト指向なんか統合環境ぽちぽちいじって、コード補完駆使してフレームワークのライブラリ呼んでるうちに覚えるもんじゃなかろうか、なんて思ったりしますがどうでしょうか。ぼくはそうでした(笑)

JavaScript の場合動的型付け言語なので、IDE は少し貧弱な先生になりさがってしまいますが、それでもあるとないのとではだいぶ違います。

まずは、プロジェクトに追加された JavaScript リソースを眺めるところから。これはコンテンツアシスト用の JSDoc になっています。

ECMAScript ビルトインライブラリー。これが JavaScript の言語としての実態になります。これで全部ですがほとんどなんもありません。

130320-0009

ECMA 3 ブラウザサポート。見たような名前が並んできましたが、これは全部表示しきれていません。まだまだあります。これらはブラウザが言語につっこんできているオブジェクトとなります。

130320-0010

この中で、Window オブジェクトを選択して JSDoc をみると次のような記載があるのが分かります。

/**
 * Object Window()
 * @super Global
 * @constructor
 * @since Common Usage, no standard
*/
function Window(){};
Window.prototype = new Global();
Window.prototype.self = new Window();
Window.prototype.window = new Window();
..略..
Window.prototype.document= new HTMLDocument();

Global は JavaScript 側のオブジェクトですが、これをプロトタイプにして Window オブジェクトが生成されています。こんな感じで ECMAScript とブラウザは、グローバルを介してつながっている感じです。ちなみに「@since Common Usage, no standard」の記述がもの悲しい・・・。

こんなのを眺めていれば、alert() や document.getElementById() なんかがなぜその記述で動くのかが分かるようになりますね。

ちなみに Eclipse がこれらの JavaScript リソースを使ってコード補完ができるのは、次の設定によります。「プロジェクト -> プロパティ -> JavaScript -> インクルードパス -> グローバルスーパータイプ」

なんだかちょっとバグっているのですが「フィールドおよびメソッドを継承する元の SuperType」のところがブラウザと同様「Window()」になっているのが分かります。”null 中の”ってなんだって感じですが(笑)

130320-0014

というわけで、コード補完をやってみます。

グローバルスコープ。

130320-0027

window。

130320-0011

String オブジェクト1。

130320-0012

String オブジェクト2。static のように。

130320-0013

Math。あれ。。。(バグ?)

130320-0022

という感じで、JSDoc みたり、補完に出てくる候補を見たり実際にブラウザでグローバル this の中身を表示していたりすると、JavaScript についての理解が進むのではないかと思います。

なおあんまり関係ありませんが、JSDT jQuery を導入すると jQuery の補完もできるようになります。

130320-0015

130320-0016

次の変数名の補完はなんかちょっと微妙です。this がからむと厳しいですね。 JSDoc の @memberOf は効くようなのですが、、@this タグが使えるとなんとかなるのかもしれませんが、この辺は動的型付けの難しさ。

ほほう!

130320-0019

無念。。

130320-0021

最後に、リファクタリングを。 あらかじめお断りしておきますと、ローカル変数名変更以外のリファクタリングはうまく動かない感じです。でも、これだけでもだいぶ違います。

適当すぎるローカル変数名リファクタ用サンプルコード。

130320-0023

とりゃ。 hoge -> moge 変更。

130320-0024

パチパチ。

130320-0025

その他、リアルタイムエラー申告も役立つことでしょう。

未使用変数申告と、セミコロン忘れ。どっちもやりがちで、プログラムは動いちゃうパターンです(8行目、10行目)。こういうのは IDE にお任せです。だいぶ助けられます。

130320-0018

というわけで、いろいろ見始めると深みにはまっていく JavaScript の世界。ついブラウザのソースコードまでダウンロードし始めてしまいましたが、、そろそろやめておきましょう。。

とりあえず、現場で JavaScript かかなければいけなかったりしたときに思い出していただければ!