2009年11月24日火曜日

Grails 1.2でi18n-templates pluginは使わない

grails-1.2でドメインクラスを作って、generate-allすると、scaffoldされたViewが出てきますが、例えば、show.gspの中を見てみると、
<g:message code="product.name.label" default="Name">
な感じで出ます。

grails-app/i18n/messages_ja.propertiesというのがあるので、
product.name.label=名前
としてあげると、ちゃんとロケールで変換してくれます。

ということで、長らくお世話になったi18n-templates pluginは使わなくてよくなったと。
Grails本体に内包されたらしいです。

以下、確認のやりとり


2009年11月22日日曜日

Flex3,4ハンズオンセミナー2日目

先日に引き続き、Flexハンズオンセミナー。
受講者約20人ぐらいになってましたね。

二日目前半 BrazeDS

昨日とは打って変わって、最初からスピード感のある感じで、
ArrayCollectionとArrayの違いとかから入る。
BrazeDSを動かして、RemoteObjectを使って、サーバにあるJavaのClassを叩いてみる。
remoting-config.xmlのdestinationを設定して、
mxmlのRemoteObjectにidとdestinationを合わせる。
なんやようわからんけど、動いている。

社内では、Grailsで作ったWEBアプリにinstall-pluginでflexとすると、BrazeDSを使ってFlexと通信できる状態に簡単になってしまうので、WEB-INFとか全く気にしてなかったけど、そうやって動いてるんだと知ることができました。

list.filterFunction でビューを切り替えるとかも、便利ですね。

二日目後半 FlushBuilderとFlashCatalyst

FlushBuilder(旧称FlexBuilder)
Flex3との違いとかを教えてもらいました。
layout指定が別になったりして面倒になっているところもある。
mx:RemoteObjectじゃなくてs:RemoteObjectだったり。。。

Flash CataLyst
ボタンとかをドローツールっぽく作って、動きをつけて、それをコンポーネントにできる。
デザイナー向けのツールとなる。イラレからのコピペもできた。
デザイナーがFireworksならまだ移行できるかもしれないが、Illustrator信者だと、ちょっとCatalystは厳しいかも。それは機能というより、UIだと思う。パネルの見せ方が、他のAdobe系アプリと一緒だったら、その敷居は低くなると思います。
ただ、イラレでも、レイヤー分け、グループ分け、命名などをFlexの人とちゃんと認識があってれば、間のCatalystをどっち側が触るかは別として、「デザイン」という要素は、Flex側から見て、だいぶ接近したと思います。
いずれにしろFlashBuilderとセットで使うことになるものですね。

とりあえずGrails、BrazeDS、Illustrator、Catalyst、Flex4で何か作ってみようと思います。

そして、懇親会

仮面ライダーあたりから、天野さんが暴走モードに突入。
Flex(というかプログラミング)は、人間の行動と心理で置き換えれば、とても楽しく覚えられる。
懇親会のときのネタで、是非LTをして欲しいもんです。

まとめ
天野さん、金像さん、お疲れ様でした。
認定インストラクタって大変なんですね。Adobeさんは、こういう人たちに支えられてるんだな。買っちゃうもんね、β版から教えてくれる人がいたら、理解しやすいし。

2009年11月21日土曜日

Flex3,4ハンズオンセミナー1日目

2009年11月21日、22日は、Adobeインストラクタの天野 英明 (Rose)さんが「なんと」無料でFlexのハンズオンセミナーをされるということで、FxUGの方から場所提供を依頼されたので、二つ返事でOKしました。

ということで、会社でハンズオンセミナーが聞ける、しかも無料、という贅沢な環境で、セミナーを受けました。
※ハンズオンなので、PC持ち込みです。

この内容は、チュートリアルではないです。感想文ですのであしからず。

1日目第1部前半(12:30〜13:30)
Adobe Flash CS4(体験版)を使って、Flashの基本概念と基本操作


初めは、これからFlexを勉強するにあたって、最低限必要なFlashについて、という感じのお話です。
CS4になって、ドロー系の機能が良くなっているみたいで、隣に座っていた、とあるコンサルさせてもらっている印刷会社営業の超初心者の彼は、「イラレみたいっすね」と言ってました。多分、彼は自社サイトのバナーぐらいは、作れるようになったと思います。
※この前、InDesignのデータ結合を教えたら、早速業務で使ってるそうです。

1日目第1部後半(13:40〜15:00)
ActionScriptの書き方の基礎


AS特有の話というより、プログラミングの基礎的な話(型、関数、リスト、パラメーターとか)と、メモリの使い方の重要性など、その後のFlex アプリを作るときにとっても重要になるので、初歩の時点からそういうところを抑えておきましょう、ということでした。ASはGC(ガベージコレクション だっけ)が若干弱いみたいなので、あとで効いてきます、ということなので皆さん注意しましょう。
また、型もしっかり定義してあげることで、かなり速度の違いが出てくるそうです。

1日目第2部前半(15:30〜16:30)
FlexBuilderの使い方からコントロールの話


Builderの概要説明から簡単な操作レベルの使い方、そして新規プロジェクトの作成。とりあえず何も考えずにプロジェクト名をつけて作成する。 Editorとしての使い方とかも交えながら。ボタンとかテキストとかこんなに簡単にできるんだよね、とまずはコントロールの書き方。

1日目第2部後半(16:40〜18:00)
コンテナ(レイアウト)、イベント、データバインディングとか


layoutの切り替え。デフォルトは、verticalになっている。absolute(aを入れてからコントロール+スペース)は、絶対位置指定。とまあそんな話から始まって、boxの使い方とか。
※Flexではレイアウトするときはboxを使う方法が軽いらしいです。
文字を入力すると、別のところがカタカタと変わるとか、超簡単なんですね。
この辺から、少しずつ探るように深いところへ…

あとがき

勤務先が千葉で、愛知県が地元のFlexプログラマの方が帰省もかねて、セミナーを受けに来ていました。明日の方がメインみたいですが、次の案件を探すためと。ウン十万のセミナーから考えると、交通費だけで受けられるからと言ってました。感心だなあ。。。
しかし、東京方面ではもっと盛んにやってるんだろうなと思うと羨ましい限り。

FlexとかBlazeDSとかAIRとか、Grailsを絡めて、バリバリの人は社内にいますが、なかなか基本的なところが聞けないし、しかも僕はTextMateがもっぱらなのでEclipseもあんまりよく分かっていない。
UIとしてはExtJSも面白いけど、AIRとかInDesignとかAdobe系と絡ませたいときは、Flexの技術も必要。

ながーく色んなところで使われている印刷・出版物のページレイアウトを決める「コマワリアプリ」は、かなり昔からFlexで作られています。
また最近では、クライアントアプリはFlex/AIRで作ることが多くなりました。
サーバサイドはGrails、BlazeDSを使ってFlexと通信して、クライアントにはパックしたAIRを提供。一年ちょっと前かな、当時はかなりチャレンジャーな感じでしたが、あっという間に標準技術になりつつありますね。

明日はBlazeDSとかCatalystとかです。とても楽しみ。

2009年11月19日木曜日

著者が書いたTeXは出版物の制作現場で有効に使えます

「雑な物づくり」に未来があるを読んで思ったこと。

なんか、我慢できないので他の保留記事をさしおいて早速投稿します。
この記事を書いた方ではなく、TeXが使えないと言っている出版業界にです。

「少なくとも電子原稿は、「手書き原稿の山」なんて状態に比べれば、出版社の人も圧倒的に楽できるだろうなんて思ってたんだけれど、手間はそんなに変わらないらしい。」(前出より)
これは間違ってますよね。
使い方によっては、「圧倒的に楽」で合ってます。少なくとも「楽」です。

まったくもう。。。

ちょっと間違いを正します。
このままだと、著者が書いたTeXは出版物では使えない、なんてことになる。

「原稿は、今のPDFからテキスト部分だけを抜き出して、それをDTPソフトで再編集」(前出より)
 ↓
「いただいたTeXからスタイル情報を(例えば)InDesignのスタイルに置き換えて再現」
※とかね

ここでフォントの影響で文字の送りが変わるかもしれないので、一度著者に確認したり、合わせて、文字化けが残ってないか確認してもらう。まあ、ここでプロの編集者の方の朱入れが入るかもしれないです。
ここが自動でいけるようなら、修正はもとのTeXでしてもらうとかもできますよね。

「TeX の図版はそのままだと使えないので、これはイラストレーターで全部作り直したうえ」(前出より)
 ↓
「一度、図版全部ください。保存形式、画質によっては作り直しになると思いますが、素材としては有効です。」

「ページの相互参照が200箇所ぐらい、索引が300箇所以上あるんだけれど、こういうのは全部「手」でやるんだという。」(前出より)
 ↓
「定義されたものを上手く使えばそのままいけるかもしれないですね」

加えて言うなら、TeXで書いた数式とかも再現できますよ、DTPアプリによりますが。

データをみないと、最終的にどうなるか、どう言えるか分かりませんが、まずは解析してからです。基本的に、あっても変わらない、なんてことはないです。

通して読めば、「雑な物作り」で出来たものこそ、コンテンツとして高品質な素材であって、「プロの物作り」と言っている方は、今までの体裁に拘った「無駄な物作り」なんじゃないかしら。それによって、かえってコンテンツの質の低下に繋がらないか心配です。
なんなら、TeXの方がよっぽど高品質だったりするんじゃないの、とも思います。
※そうなると仕事が減るのであんまりいいたくないですが。

本物のプロの物作りは、一般の人が作ったものをちゃんと印刷できるように、その人が納得いくレベルで仕上げるところに付加価値があるわけであって、使える素があるなら、それを最大限に活用して、効率よく作ることなんじゃないの。間違ってますかねえ。

もし、100%いけたら、TeXを管理すれば、改訂のときもそのまま使えたりするとか、めっちゃ便利になりますよね。著者と出版社が協力して、そこを目指すべきだと思います。
※ちょっと古いけど、こんな感じで。大好きな本(アジャイルプラクティス)がこうやって作られたのは嬉しいです。

だって、「たとえばそれを電子化したいなら、LaTeX ならhtml の出力も簡単だから、こういうのが、少しは役に立つだろうなんて考えてた。」(前出より)、これ合ってますもん。

もちろん、出版社の方のプロによる編集作業で、文章を整えたり、分かりやすい表記するとかプロデューサー的なことというのは、重要なことです。それこそ僕にはできません。でも、著者が作ったTeXをうまく使えば、自分たちも楽になるのに、ということが理解されていないのは非常に残念です。

出版不況だって言いながら、こういうポイントを外すのはどうかなと思います。
制作会社はもっと厳しい。せめて無駄なことはさせないで欲しい。無駄なことをしないで済むなら、いくらでも協力しますよ。テストとか。

TeXに限らず、今は一般の人でも、プロが使うDTPアプリもしくは同等アプリを使って原稿を書くことができる。そういう時代なんですから、コンテンツの価値を高めるために、書く、編集する、制作する、印刷するというそれぞれのパートではあるけれど、どこに向かうのか、何を目指すのかを、一緒に考えないと、いつまでもこの不況からは脱出できないと思います。