2009/02/14

DoJoメモ

GWTから移って最近はDoJo調べてます。

理由

  • 生成されるHTMLをいじれない
  • レイアウトマネージャが気に食わない

どうしてもWidgetのここいじりたいがうまくできない。RailsのGeneratorみたいに生成したものをあとでいじる系ではなく、生成したそれを使えというGeneratorなので、生成するところをいじらないといけない。

DoJoだと1画面スクロール無しのBorderContainerが気に入ったわけで。

で、DoJo試してて思ったことをメモ

  • デフォルトのテーマがかっこいい。素人でもかっこよくなる。個人的にはSoria。
  • HTMLにdojoType="dijit.form.TextBox"とかアトリビュートを設定してdojo.parser.parse()でパースするとWidgetができる。
  • WidgetはJavaScriptのベース、HTMLのTemplate、CSSのデザインの3段構成
  • dojo.require("dijit.form.TextBox")という感じで必要なJSをロードする。ロードはXHRでやっているっぽい
  • ほとんど素のJavaScriptを書く感じ?prototypeに比べてDOM操作系が少ないと思う。
  • JSのCoreを拡張しないので、dojo.forEach(nodelist, function(x) { x });みたいな感じ。

自作Widgetの中で、BorderContainerを使いたかったのだけど、templateの中でLayout widgetは対応してないといわれてしまった。

設定画面みたいなのをWidgetとして切り出したかったのだけどなぁ。partialとして切り分けといて、サーバサイドでつなげるか。

とりあえず、ようやく本腰入れてJavaScript勉強中。JavaScript第5版を読んで、functionの解析タイミングとScopeChainをはじめて知りました。基礎すっ飛ばしてライブラリやってるから良くないんだな。反省。

2009/02/13

デブサミ1日目

いってきた。楽しかった。

一ヶ月前に選択したトラックを見直して、仕事の都合で開発プロセスに偏ってるのが失敗したかなぁと思ったけど全然そんなことなかった。

3つだけのつまみ食いになってしまったのだけど。。。

角谷さんのオープニングアクトで、開発プロセストラックではなく、ここはAgileトラックですとのお言葉で始まり

萩本さんの開発プロセスの心で、ウォーターフォールと現在の契約の問題点を明確化し、Agileは開発プロセスだけでなくビジネスプロセスに打って出るべき、コタツモデルが理想と心を示し。

角谷さんのセッションでは、「プログラムを書いたとことのないシステムエンジニアが威張っているような会社は早晩亡びる。」を大事なので3回繰り返し、ビジネスと技術のバランスと人間相互の尊敬による、XPという道をしめした。

そして、前田さんのセッションで、実際にお客様と開発者が一緒にゴールを目指した結果の事例を示してくれた。

なんて美しいつながり。

技術者としてテクニカル重要はわかるが、コレをみられなかった人たちはかなりもったいないことをしたと個人的に思うほど。

いや、これは技術者だけじゃなくて、発注者側、ユーザ企業に、官公庁にも一緒に見て欲しいと思った。きっとみんなお互いの立場で困っていて、各自の立場でざっくばらんに話し合える機会が欲しい。

デブサミという技術者側だけでやったのがもったいないセッションだった。

だけど、仕事や責任が増えるユーザ側は嫌がるかもしれないな。

今の、金払ってるのに困ってるんだから何とかしろと一方的に責任を負わせるだけじゃ、お互いに不幸せな状況になるだけだというのがよくわかったが、いかに理解してもらってリスクを負ってもらうか。

予算ありきの開発とか、ビジネスの変化があるにもかかわらず最初が重要と思い込みすぎる計画とか、人月ベースの買い叩きとか、契約とか構造を変えにくいところはどうしてもユーザ側の理解が必要だし。

しかしリスクを負ってもらった以上の価値を提供できる、Win-Winの関係にするために技術者側も一緒にいいものを作ろうという信頼関係をいかに築けるか、ビジネス価値を提供できる提案ができるか相当の努力が必要だ。ある意味今のすいません調査します頑張りますでお互い不幸になるほうが惰性で得意分野に引きこもってすごせる分楽なのかもしれないのだから。

実に楽しいセッションでした。スピーカーの方々に感謝。

Social Change starts with you. SIも捨てたものじゃないなぁ。

2009/02/11

Word

エンジニアのためのWord再入門講座を読んでまっとうにスタイルとかテンプレートとかを使い出した。

で、最近CSSをやってたせいか、ようやくWord = HTML + CSSなんだなぁと思って使えるようになってきた。

あー、段落指向ってpタグなのね、そこにClassつけて、margin-topつけたりすればいいのねみたいな妙な理解。

しかし、いまだに箇条書きとリストスタイルに慣れない。なんで崩れるのか理解できない。アウトラインで書いてるからあまり崩れることはなくなったんだけどいらいらする。

もういっそHTMLで書いたほうがいいんじゃねーのとか心のなかで叫んだり。

きれいに書くにはCSS意識しないと書けないツールってのもどうかと思うんだけど。PC-98のころの一太郎とか松のほうがよっぽどWYSIWYGだと個人的には思う。

たぶんその頃はPTAのお知らせとかたいした文書をうってなかったし、余計なことを意識せずに、ほんとにそのままの書いたものがそのまま出てくるからなのだろう。

見た目なんて最初に決めたり内容を変えることなんてめったにないんだからデフォルトスタイルでちゃんとしてくれればよくて、アウトライン、段落番号、参照の自動割り当てとか、文書の構成をいじるのを楽にする機能のほうが利点としてはよっぽど大きいと思うんだけどな。

あとはちょっとしたインデント、表、図とか思ったものが思ったように書けない。それらが妙に使いにくいから、Excel方眼紙がはやる理由だと思うんだけど。

なんかオプションも妙な翻訳なのかマージンとかインデントとかそのままいわれても最初意味がわからんし、どうしたらなにがどう画面に反映されるのかわかりにくいんだよなぁ。

2009/02/05

iアプリメモ

久しぶりにiアプリを書いたのでメモ。DoJa 5.1プロファイル。

Java(c)2 Standard Editionが見つかりませんとエラーがでる。

JDKが入っているにもかかわらず、DoJaから見つけられなくなっていた。

起動時どころかアンインストーラも同エラー

そんなときは、J2SDKを入れなおすのがいいみたい。

たまたま、Jdk1.4.2_16しか入っていなかったので、1.4.2_19のインストーラを実行して追加インストールしたら、DoJaも正常に見つけられるようになった。どうも、Java_Homeとか環境変数ではない何かをみているきがする。

DrawArea

DoJa 3.0からデフォルトの描画領域はどんなに画面が大きくても240x240になるらしい。

これを大きくするにはADFでDrawArea = 480x854とか書いてあげればよい。

ここ参照

ビルドするときは、エミュレータの端末サイズを元にチェックするので、設定→エミュレータ環境設定→端末ウィンドウで、ビルドしたい画面サイズの端末設定を作ってあげる。

次に、端末→作成した端末設定を選択する。

これをしないとDrawAreaの値が不正です。とか怒られる。

Eclipseのときは、Window→Option→Dojaの設定で同様にエミュレータ設定をして、RunConfigurationで実行時の端末設定を変更すればOK

しかし、480x854とか、うちのディスプレイじゃ表示しきれないのでやめて欲しい。

カメラ

DoJa 3.0プロファイルから、カメラが標準で使えるようになった。デフォルトではJPEG圧縮っぽい。

CameraIdは0が外側のカメラ、1が自分撮り用のインカメラ

Camera#setImageSizeを呼ぶとカメラの画像サイズを変えられる。

で、Camera#takePicture()を呼ぶとNativeのカメラが起動される。

この画面ではなぜか、撮影サイズと画質を設定できない。あらかじめ上記のsetImageSizeで設定しておくこと。(他のやり方があったら教えてください。)

撮影した画像はgetImage(0)でMediaImageを取得して、use()して、いろいろいじったり、ImageStore.addEntryでマイピクチャに放り込んだりできます。

ついでにDoJa3.5から、CodeReader.getCodeReader(cameraId)でバーコードリーダーとして起動も可能。共通でQRとJANコードは読めるようだ。書棚サイトとか作るときに便利かもしれない。

HTTPがiアプリの取得元サイトにしか張れないので、ちょいと不便

ImageLabel

撮影した画像を表示するのにPanelベースの場合、ImageLabelを使う。

ImageLabelの最大サイズは、端末の描画領域に制限される。

デフォルトならば、240x240、DrawArea設定しているならばそのサイズ

このサイズはDisplay.getWidth()とDisplay.getHeight()で取得できる。

Panelの場合、描画領域をはみ出すとスクロールできるようになるが、Display.getXXXはもとのDrawAreaのサイズを常に返してくる。

例えば、240x240の状態で、他のコンポーネントのある画面の末尾にImageLabelで貼り付けると、240px分下にスクロールできるようになる。

なお、ImageLabelは、そのサイズ以上の画像を設定した場合、ImageLabelのサイズより大きい部分は切られてしまう。

ImageLabelのサイズに収めたい場合は、次のようにする。

Image img = Image.createImage(Display.getWidth(), Display.getHeight()); Graphics g = img.getGraphics(); g.drawScaledImage(元画像, 0, 0, Display.getWidth(), Display.getHeight(), 0, 0, 元画像.getWidth(), 元画像.getHeight()); imgLabel.setImage(img);

比率を保持して縮小とかは、適宜頑張れ!

自動更新機能

アプリの中からバージョンアップを呼び出せる。

DoJa開発ガイド 11.5 iアプリ更新機能連携起動がそれ

IApplication#launch(LAUNCH_VERSIONUP, null);を呼ぶと、バージョンアップしますか?というダイアログが表示され、Yesを押すとiアプリの機能メニューにあるバージョンアップが実行される。

Noを押すとそのまま処理継続される。

このメソッドは、バージョンアップの成功、失敗、キャンセルを返さない。

どうやら、バージョンアップ実行すると、アプリはいったん終了され、成功・失敗・更新無し問わずに再起動扱いとなる。

ダイアログでNoを押してキャンセルした場合のみ処理続行なので、launchの直後に、バージョンアップは必須ですとかダイアログをだして、強制終了することも可能。

アプリの起動直後にこのメソッドを書いてしまうと、サーバ側のJAMに変更がないにもかかわらず、必ずダイアログが表示されてしまい、かっこ悪いし現実的でないので、自前でバージョン管理(チェック)は必須となる。

ADFのAppVerはアプリ内から読めないらしいから、AppParamでパラメータとして渡すしかないかもしれない。

バージョンアップはADFのLastModifedDateの設定が、自分より新しいかをチェックしているだけ。アプリを変えたらADFのアップロードも忘れずに。