2009年12月29日火曜日

2009年最終日レビュー大会を終えて

2009年最終日となった今日というか昨日(12月28日)は、当初から総まとめとしてのレビューをしよう、なんてことになってまして、
開発関係、制作関係それぞれで2時間程度をとって行いました。

開発では、今動いている案件の話とか、今やっているものの話を順次していきました。
開発2課によるコンバート関係は、引き続き写研データの調整や、入稿されるAccessデータを解析してEdianに流すとか、ワード2007のXMLを解析して数式を抜くとか、そういったものと、
あと、新しい試みでInDesignで作った商品カタログのデータから、CouchDBという究極?のKey、Value型DBへの取り込みという、ずっと山本さんが言っている、今で言うNoSQLですか、そういう試みの途中経過の発表でした。


※↑はInDesignからcouchDBにぶっこむスクリプトを実行するところ


※↑はCouchDBにとりあえずぶっこんだところ。


商品カタログ系DTPとコンテンツをどうするかの将来像、可能性が見えた気がします。
もうここまでくれば、既製品がほんとに必要なくなりますよね。これから、どんどんオープンソース系の技術がこの業界にも浸透してきて欲しいです。

続いては、PAGE2010でサンプル出展する絵本を作るAIRアプリの途中経過。
AIR2.0への取り組みは、AdobeAIRDayへの参考出展などで取り組みをしているわけですが、FlashCS5からは、TLF(Text Layout Framework)が、InDesignと同じエンジンになるそうで、なんだかAdobeという枠の中でどんどんやりたいことが出来ていく感が、急速に進行していてとても面白くなってきています。


↑Flex4の上で縦組み表現しています。


その他、データ差分をとるためのプラグインとか、バリデーションチェックのモジュールとか、日々必要なものがざくざく出来ていっている感じでした。

制作では、大量ページものが多いわけですが、それをどういう手順でやるか、その手順が正しいのか、といったところを検証しつつ行われました。



これからもっとも心がけていくべき「テクニカルDTP」という分野をしっかりと認知させていくには、いつも同じでやり方が変わらないものについては、しっかりと手順書を作り、ただ作るだけじゃなく、それをやってみて、さらに問題・課題がないか追求し、誰でも出来る状態、誰がやっても同じ結果が得られるように、漏れ、ミスのないようなフローを構築しなければいけません。2009年は試行錯誤の中、粗が目立つときがありましたが、2010年は、その点をしっかりと抑えていくんだ、と結んだのでした。

その後は、忘年会!



紆余曲折、なんだかんだありながら、なんとか年越しできました。
いつも応援していただいている方々に心から感謝いたします。

2009年12月27日日曜日

SGGAE/J勉強会に参加しました

SGGAE/Jは、Scala、Grails/Groovy、GAE/Jを組み合わせたもので、
「すっげーじぇ」と読むんだそうです。

2009年12月26日ニューキャストセミナールームで開催されました。
名古屋Scala勉強会とJGGUG名古屋支部の合同勉強会になります。

1.Google App Engine for Java入門/tantack@名古屋Scala勉強会
Google App Engineとはどういうものか、といった基本的なところのお話でした。
GAEの制限事項とかとても勉強になりました。

2.Lift on GAE/J/RKTM@名古屋Scala勉強会
ScalaのWebフレームワーク「Lift」をGoogle App Engine for Javaで動かすということで、あまりにも簡単にできてしまって驚きました。mavenとか使ったことなかったですが、だいたい追いついて出来ました。当日の資料どっかにあがるのかな?聞いてみます。

3.GroovyなGAE/J:Gaelykでかんたんbot工作/kskyさん@日本Grails/Groovyユーザーグループ
横浜から参戦のkskyさんによるGaelykの紹介と、Gaelykを使ったTwitter botの作成ということで、まずはGaelykで作ったものをGAE/Jに載せるハンズオン。その後、Twitter botの作成では、パイプラインの話、つぶやくウサギ(nabaztag)が登場したりととても面白かったです。名古屋のお天気情報をつぶやく@nagoyaweatherは、このセッションで完了したのでした。

4.Grails、Gaelykでハンズオン/tyamaさん@日本Grails/Groovyユーザーグループ名古屋支部
GrailsをGAE/Jで動かし方についての紹介(ハンズオン)
お持ち帰り資料を準備してあるあたりが、tyamaさん、さすがだね。



うちのセミナールームも、皆さんのように技術に詳しくない、勉強ばっかりさせてもらっている私の営業の成果?もあって、徐々に認知されてきたのではと勝手に盛り上がっておりますが、今日ご参加いただいた方からも「駅(JR千種、地下鉄東山線千種)が近くてとてもいいねぇ」「IT系の勉強会には必須アイテムの無線LAN、電源、ホワイトボード、プロジェクタと全部揃ってるし」と言っていただいたので、勉強会を開きたい、場所を探しているコミュニティの方々には無料開放してるのですが、こう言っていただけるだけで、採算合わずとも家賃を払う価値あり、と自分に言い聞かせるのでした。

根がイベント屋なのかな、こういうのをお手伝いするのがとても楽しいのです。
やろうと思えば、場所があれば、どこでも出来そうなので、そうなっても、
「ニューキャストさんとこのセミナールームでやりたいな」と、思っていただけるように、設備じゃない何か、お金じゃない何かをこの場所で築きたいと思います。

快適な勉強会ライフを提供できるように、もっと頑張ります。

2009年12月26日土曜日

Amazon EC2ユーザ会 クリスマス・オフ会に参加しましてきました

Amazon EC2ユーザ会 クリスマス・オフ会に参加しましてきました。

12月25日クリスマスまっただ中、しかも金曜日、渋谷のアマゾン ジャパン株式会社で開催されました。

看板を見て「あ、オレ、ユーザじゃない」と少し尻込みしながら、学びingの社長さんが受付されている中、会場に入っていったのでした。学びing?あー、PAGE2009で聞いた気がすると思いつつ。。。

会場には、なんかそれっぽい人たちばっかりで、山本がいれば、もっと濃い話になったんだろうけど、僕は、アカウント作ってちょっと試してみた口で、よく分かってない部類の人間なので、隅っこで会場を眺めておりました。山本氏は、本日は、明日12/26に開催されるScala勉強会との合同勉強会でGAE/Jの資料に集中したいということで泣く泣くキャンセルしたのでした。

まずは、「AWS新着任日本人スタッフ」小島さんによるAmazon本体の話、AWSの紹介と、スタッフ募集の話。

上のスライドは、Amazonのビジネスモデルの図と小島さん
(レストランでナプキンに書かれた伝説の図?)

初っぱな、データセンターの場所についての話でしたが、現在はUS2拠点、EU1拠点、2010年前半でシンガポールが準備段階、そしてアジア2拠点目はどこか!という話で結構盛り上がったのでした。アジアでは日本しかスタッフ、体制の準備がされていない、ということは「東京?」。書くなっていわれたからこれぐらいで。

ここからはAWSのサービス内容についての紹介で、中でもいちおししてたのは、AmazonVPCの話でした。VPNでプライベート利用できるもので1時間1セントらしい。社内リソースを拡張したいときは是非ということでした。これは特別に難しい設定が必要というわけではなく、通常のVPNと同じだと考えていい、ということでした。

リリース済みのようですが、「EC2 spot instance オークション型で利用価格を入札」や、「CloudFrontStreaming 静的なファイルしかできなかったが、AdobeFlashメディアサーバがビルトインされる。これは完全従量制で提供。オンデマンドストリーミングのみ対応。ライブは未対応」という話がありました。
MicrosoftでなくAdobeと提携したところが、僕らにとっては好都合。
小島さんは、前職AdobeJapanだそうで、PDFソリューションや、Flexユーザコミュニティの立ち上げをされたそうで、そういう意味では僕らに近い存在なんだと思うと、勝手に身近に感じたのでした。

終わってすぐ名刺交換させてもらって、「今日も仮想化の話をお客さんとしてきたんですが、印刷・出版業界って大量のコンテンツがあって、画像があって、変換が必要で、そして使う時期使わない時期がある、大量の処理をいっきにかける時がある、とかだと、こういうサービスを使うのってありだと思うんですが、どうなんでしょう?」と質問したら、「十分ありです。向いていると思います。」みたいなお返事をいただいたので、これはセールストークにいただきだなと。印刷・出版業界は、ついつい「印刷」もしくは「印刷機」に頭がいっちゃって、あんまり関係ないと思ってるかもしれないけれど、ビジネスインフラとしてのAmazon利用に真剣に取り組む必要があるんだ、という思いに背中を押してもらった気がしました。

ユーザ事例としては、「ウェブポ※年賀状作るサイト」「アンケート集計」がありました。UIの部分はFlexを使ったRIA開発されていて、バックエンドの処理でAmazonを使っている、アンケートについては、ある時期にある処理をまとめて行わなければならない、ということで使っているということでした。これによって次年度のハードウェア予算はほとんど削られ、その分開発の方へ回して、さらに良いものにしていく、ということができるようになったらしいです。

その後、質問タイムから上記になかった話をいくつか紹介。

クレジットカードがないとできない、というのは企業利用に壁ができてしまうのでは?という質問がありました。
これについては、カードを使うことですぐ使える、という利点に重きを置いていてそうしていると。カードがあれば、予審しなくてもいい、というところもコストを抑えられるポイントだと。
毎月100万円を超えるものについては請求書発行という流れもやっているが、マニュアルオペレーションなので、いつかはコストを圧迫することになるので整理が必要だということでした。
また、学生向けにもプリペイドカードのようなもので出来るように準備を開始しているらしいです。

それから、やっぱり安心できる事例が欲しい、というのがあって、その辺はどうなんでしょうか?という質問には、言えませんが進行中案件があることは確かだと、いうことでした。
それから、最近不況もあって、コストを抑えなければいけないということで、お客さん側が機能を削るなどの妥協する事も少しずつ現実的に出てきていて、そのようなコストプレッシャーの中、クラウドを提案するための「風穴」が出てきつつある、クラウドが話の土俵にあがることが出てきている、ということでした。

Amazonは、安く提供するために、とにかくマニュアルオペレーションを抑えた「ローコストオペレーション」を徹底的にやるという方針とのことで、ユーザとしてはそれが長く続いてくれるように応援したいものです。

あとは、「ホワイトボードじゃなくてホントに壁に書くんだ」ということで、壁にペンで書いてました。
上手くとれてませんが、スライドの右側に赤いペンで書かれてます。


うちでもやりたいな。セミナールームならいけそうだけど。ちゃんと消えれば良いんだけどね。

そうそう、ジャンケン大会があって、RightScale社のプレミアム?なシャツをゲットした。

2009年12月17日木曜日

備えあれば

2009年12月16日20時頃、NTTBフレッツとau one netのあたりで回線障害がありました。

当社でSaaS提供しているWEB入稿・自動組版のお客さまがその影響を受けてしまうことになりました。

回線については、なんともしようがないんですが、こういう時のためにも複数の回線が用意してあるので、入り口を変えて接続してもらうという緊急時の対策を施しました。
他にも考えられる障害への対応策は、数年の歳月をかけてかなり施してあります。

お客さまからすると、えっそんなのプロなんだからすぐ直せるでしょ、と考えると思います。
実際、簡単に終わることもあります。しかし、いろいろな可能性を探りながら慎重にやらないと二次三次の障害を起こす原因にもなってしまいます。そうなっては右往左往しながら余計な時間を要してしまうことにもなりかねません。
そういったことを全部含めて、最速で復旧できるように心がけています。

が、なかなか理解はしてもらえません。
おまえらちゃんとやってんのか!と。
見えないんだから仕方ないですね。
見えないから余計にイライラしてしまいますよね。

実際今回は、まず監視サーバから全員の携帯にメールが送信され、その後5人全員が携帯で招集されました。一人は帰宅中に途中下車して一番近い友人宅に陣取りしたようです。第一報から10〜15分ぐらいだったと思います。

その後は、全員オンラインで状況を確認、情報を収集しながら、これが原因だとしたら、どうする、それをしたらどうなる、他に影響は?などなど、こういう場合、一人の判断、知識では不十分なときがあります。いつもはのんびりしてそうな人たちがそれぞれの力を発揮しながら解決、そして対応まで持ち込みます。チームワークが試される時でもあります。

でも、見えないんです。悲しいことに。
今回の全員のやりとりチャットを公開したいぐらいです。

回線が復旧するかもしれない。それでも回線が大変なことになって復旧しなかった時を想定して職務を全うするために動きます。

。。。今回は、緊急対応が完了したとたんに、NTTの回線が復旧しました。

ネットワーク障害も、ハード障害もいつ起こるとは誰も教えてくれません。
逆にいつでも起こる可能性がある、ということです。
世の中が便利になる反面、気にしなくなった反面、見えないリスクも背負っています。

最後は、機械ではなく、人間がやるしかありません。

NTTの人たちもそうだと思います。そういう裏方さん達が、僕らが何気なく使っている物を必至になって守ろうとしているというのは、こういう障害が起こったときぐらいでいいので思い出して欲しいなと思います。
そうしないと、重要性が軽視されて、やがてそれは品質の低下を招くという結果にもなりかねないとちょっと危惧してしまうのです。

印刷・出版系システムは、印刷入稿日が決まっているので、もしデータが出来なかったら損害額が半端な物ではありません。
ボタン押して、自動組版されて出てくる、それだけのシステムなんですが、それを当たり前のようにできるように、相当なノウハウが詰まっています。

それでも障害は発生します。そういうときは、皆さんが思う以上に相当な緊張に包まれます。
ですが、過度の緊張は失敗に繋がります。ほとんどの復旧失敗は、急ぎ過ぎが原因です。
絶対に焦ってはいけない。これが鉄則だと思います。

とにかく下版できないとか、そういう大事故に発展しなくて良かった。。。

2009年12月16日水曜日

ユーザーに想像させるにはシステムの余白が必要だと思う

昨夜はタイトルを書いて、内容を考えながら寝てしまった。。。

システム構築するときに、まず初めに必要な機能の整理とかを充分にやろうとするのは、あと(納品・検収)で、それが出てきてれば完成だよね、という合理的な考えをする周りの人間に必要なだけであって、それだけのコストを掛けた企業、使うユーザーはそこで満足するわけではなく、パフォーマンスが出なければ受け入れてくれない。

一番大事なのは、ユーザーに受け入れられ、自ら使いこなすようになれることだと思います。
そう考えると、使ってみなければ、動かしてみなければ受け入れられるはずもない。
なのでまず、機能モリモリではなく、簡単なというかシンプルさを優先して芯の部分を先に作って、使ってみる、動かしてみる、想像してみる、という場面をユーザーに提供することから、システム開発はスタートするんじゃないかと思います。

うちで使っている制作作業コストを管理するシステムは、Grailsで数時間で自作したものです。
社内システムなので、こういうの欲しいんだけど、と言うと、まず、
案件があって、その中にタスクがあって、そのタスクに各ユーザーが作業時間を登録する、というのが多分芯になる部分なので、それを作ってもらいました。
ほぼScaffoldで開始して、まず登録してみる。
とりあえず、金額と時間の計算とかはできたので、あとは何が必要か分からないので、たくさん文字が入る備考欄を準備して終わり。

数ヶ月運用して、リストの出し方がこうなってると集計しやすいんだよね、とJIRAに入れて、時間のある人が修正→確認→クローズと。

ゆくゆくは月集計とか個人集計とかやりたいなと思ってましたが、しばらくして、
「あ、備考欄に必要なキーを文字で入れといてそれで文字で検索すればリストでるじゃん」と。数ヶ月でかなり会社のコアなシステムになりました。それが今まで見えなかった部分の可視化にも繋がって、当初考えていた使い方よりも変わってきています。

これは一例でしかないですが、検索キーって、何になるか分からないし、キーの種類、タイプなんかも、先に決めようと思ったら、そこから大幅に話しが膨らんだり、横道に逸れたりして、それがプロジェクトを遅延、クラッシュさせる原因になる。そうすると、本来やりたかったことが小さくなって、他のことの方が重大に思えてくる。

だったら、ユーザーに想像させるシステムの余白(開発者の視点からも作り込みすぎない)を作っておいて、自らがその想像を実現させようとして使いこなすようになる。自らが使いこなせるようになれば、あとは、プログラムの世界へようこそ、ということで、自分たちでもコーディングしてもらうという、まあ最後は本人のやる気によりますが、システム開発ってそういうステップを踏む分野もあっていいんじゃないかなと思います。

2009年12月15日火曜日

InDesignとEdianWingとMC-B2を比較〜流し込み編

ずっと続きを書いてないので、どこまで書いたか忘れてしまいましたが、
InDesign、EdianWing、MC-B2というところにとりあえず絞って考えると、向いている案件、向いてない案件てあるよね、というところまでだったですね、多分、、、

制作現場では、あまりアプリに固執してしまうと、そればっかりになって、アプリが持つ機能として、できるできないという議論になる可能性が高く、違うアプローチから開発されたアプリではさっくり解決できてしまったりすることもある。
なので、導入はしないにしても、広く検証なりしておかないと、全体として良くならない。

今回は、流し込みの視点で、どうなの?を見てみます。
それぞれ持ち味が違うので、組版機能で出来る、出来ないというのはありますが、
流し込み自体は全部対応していて、EdianWingはトリガー、MC-B2はB2タグ、InDesignもタグテキストと、いうことで、それぞれで流し込みができます。

これまたそれぞれですが、流し込みを補助するようなツールもあったりします。
流し込みを選択する時点で、大量ページものでないと、設計にかかる時間がとれないので、意味がないですが、スタイルの機能を持つ(当たり前なんですが)、InDesign、MC-B2の方が、まとまりがつきます。

そして、これからは流し込みだけじゃなくて、取り出しというのも考えていかないといけませんので、さらにスタイルの概念が重要になってきます。

もうひとつは、手をいれやすいデータにできるかどうか。
この辺りは、長い組版専用機の流れを組むEdianやMC-B2の方がよさそうです。
しかし、InDesignは、スクリプトという強力な魔法が存在するので、そういうのもカバーできるかもしれません。

MC-B2の表機能は、セル内の泣き別れができるのは素晴らしい。
でもInDesignのエクセル連携する表もこれまた素晴らしい。
両方とも、表もスタイルという位置づけになっていて、扱いやすい。

組版アプリは、組版作業を、いかに短い時間でやるか、というチャレンジに対して、失望させない将来性を持っている必要があります。

組版作業では、繰り返し作業を自動化するというのは、無くてはならない手法です。
そしてまたその部分を、組版仕様として、例えばスタイル、スクリプト、マクロなどで、ドキュメント内に管理できる、というのはかなり強力な支援機能だと思います。
そう考えると、総合的にみて、それができるのは、MC-B2かInDesignだろうなと。

Edianにスタイル機能がついてくればちょっと機能として魅力ですが、価格がなぁ、、、
安定性と歴史でしばらく前まではいちおしでしたが、ここまで周りが整備されてくると、決定打に欠けてしまいますね。頑張れEdian。

2009年12月13日日曜日

NGK2009に参加してきました

名古屋で活動しているコミュニティが集まって、LT(ライトニングトーク)するという企画。
なんで参加することになったんだっけ、と思い起こせば、ここ1年ぐらい勢力的にそういう人たちとコンタクトとろうとやってきた中で、自然な流れでそうなってました。

ここ見ると、いろんなコミュニティが参加しているのが分かります。
山本が積極的に動いてはいますが、関東方面がメインなので地元のことは、実はよく知らなかったりしたわけですが、今では、名古屋のコミュニティにも参加したりできるようになってきました。まだまだこれからも発掘していこうと思います。

本日は50人ぐらいでしょうか、名古屋市立大学の会議室が一杯になる感じで、そんな中、私と山本もLTしてきました。

といっても、僕の場合は、勉強会会場を探している人たち向けに、うちのセミナールーム、無料なんで是非使ってください、という宣伝をしてきました。
「探している人いますか?」という問いかけに対して、10名以上の方が手を挙げていたので、やっぱり需要はあるよなと。

休憩時間に遠く遠く離れた喫煙所(要は敷地外)でたまたまいた人に話しかけてみたら、使いたいと言ってくれたので、来て良かったなと思いました。
「無料でいいんですか?」って言われたので、「まあ実は動きたくないんで、来てくれた方が楽だし」という半分本気の冗談をかましながら、「勉強会って結局コミュニケーションなので、根っからそういうのが好きだし、技術者の人たち、技術者を志す人たちがコミュニケーションをとりたいのに、そういう場を探すのに苦労してしまっているなら、場所を提供することしかできないけど、役に立てるならやり続けたい」というような主旨で返答した気がする。

山本は、いっつも濃いお話をじっくりするのが好きで、大量のプレゼンシートを作る人ですが、なんとなんと、すっきりしっかりきっかり5分でまとめきって、エンターテイナーだけあって、ウケもよく上々の仕上がりでした。
Java is Groovy,Groovy is Javaのくだりでは、結構みんなが見入ってました。
Grails/Groovyへの関心が増えるといいなと思いました。

懇親会では、入社1年目の子とか、大学生とかが来ていて、ああ、こういう意欲がある若い人たちをもっと巻き込んで、もっと増やさなければと思ったのでした。
会場はなぜか錦三で、大安ということもあり結婚式の二次会がそこら中であるようで、入ったところもそんな感じのスペース。
プロジェクタとモニタがあって、LTの続きをしたりしました。
こういう飲み屋作りたいと思ってたのですが、是非今度音楽付きで、長野のGroovy?なVJを名古屋に呼びたいなと思うのでした。

いろんなコミュニティ、いろんな人と触れ合うことが出来て、とても良かったです。
さあ次は来週のScala勉強会と合同でGAE/J勉強会!

2009年12月12日土曜日

某専門学校で企業説明してきた

組合関係の活動ですが、うちは今回で2回目。
大学、専門学校とかに、インターンシップ受け入れまっせという企業が出張して、学生に企業説明をするというプチイベント。本番は、夢プロジェクトというイベントです。

とりあえず前回の企業説明で第一志望で逆指名した2名は3月中旬からインターンシップとして受け入れが決まっています。
2週間なので、特に何かすごい力になるようなことが教えられたり、吸収出来たりするわけではないですが、就活や面接、採用されて就職する前に、実際の職場を体験できるのは、学生にとっては良いことだろうと思います。

企業にとっては、というか、組合企業は中小ですから、そうそう10人も20人も採用できるわけはなく、1,2名というところも多いんじゃないかと思いますが、中小企業にとっての「人」の重要度からすると、今のうちから、次世代を担う人たちとのコミュニケーションは必要だと思って僕は取り組んでます。

今日ジョブエンジンのdipの営業君が言ってましたが、「つぶしちゃうつもりなら人材をとる必要はないですが、やるんだったら継続的にやらないと穴空きますよね」と。こいつ、いい営業だな、はっきり言うやつは好きです。

今日は100人ぐらいだったと思いますが、だいたい同じような時代を通過してきた人たちの塊なわけで、塊としてみると、それがひとつの時代にも見えてきます。

自分たちの世代と比べて考えてしまうと、なんだかいつもギャップを感じてしまうのですが、そうではなく、この世代の人たちの考え方みたいな中心にもやっとあるものを基準に置いた方がギャップを小さくできるんだろうなと思えるようになってきました。

リクルート系の人(ってあのリクルートではなく)が、就活についていろいろ学生に語ってましたが、履歴書とかそういえば書いたことないなというところから、今の彼ら学生の時代に数分間だけタイムスリップしてしまいました。

よくよく思い出してみると、高校の授業が終わって、適当な大学に合格して、入学までのバイトで、今の会社に入ったというか手伝いで行ったのですが、昔でいう写植が楽しくって、どっかで「これは天職だな」と思った瞬間があります。前社長に褒められて、確か昔使ってた事務所のエレベータだったと思うけど、「天職だと思います」って言いきった記憶があります。「そうか、頑張れ」と、とても喜んでくれたことを思い出しました。
僕は社員にこんな風に言われたことはない。でもそう言われるようになりたいなと改めて思いました。それがその時の勢いであっても、頑張って輝こうとする人たちを潰しちゃいけないと。

1時間ぐらいのオリエンがあって、その後、ブースに分かれて説明会。前回は山本氏が頑張ってくれたのですが、20人ぐらいを5ターン。1ターンが17分で、しゃべり倒しました。
内容は次のようなものです。対象は、新2〜3年生が多かったです。
・DTPで印刷物とWEBアプリを作ってる会社です。
  Flash系の技術が紙とWEBを繋ぐことになるんじゃないかという話をちらり。CG系もいたので。でもAIRとかは知ってる人がいなかったな。
・IT希望が多いので、ITでも常駐派遣タイプの企業とか社内開発スタイルの企業とかいろいろあるよ、営業はこういう人がむいてそうだよ、設計は、PGは…みたいな話。
・Grailsを使って、5分以内でWEBアプリケーションを作る
 Javaをちょうどやりはじめたぐらいなのですが、こういう技術もあるんだよと。
・勉強会とかに学生のうちから参加してみると、仕事や職場のもっと深いところまで聞けるかもよ。そこで拾ったキーワードを探っていくと興味の持てるものが出てくるかもしれないよ。

前半は向き合って話しをする形で、
後半は、学生君側の席に座って、隣から、後ろから僕のMacをみてもらって、実際作って動かしてみました。身を乗り出して聞くやつもいるし、つかれちゃったやつもいるし、寝てそうだったので、ゴルァの意味を込めて「大丈夫?」と言ってやったが、ノーリアクション。まあ仕方ない。一人でも多く、自分たちがやっていることを覚えてくれればそれでいいんだ、と涙をこらえながら5回の説明を乗り切りました。

最後に片付けしてたら、同組合員の社長さんが、僕が学生に混じって説明する姿を見て「町のにいちゃんが一生懸命後輩たちに教えてる感じがして良かったよ」と話しかけてくださいました。ちょうど黒板が後ろにあったので、それを勝手に使ったりもしてたので、もしかしたら、おめぇ目立ちすぎだというボディブローだったのかな。だったらごめんなさい。根が素直なので、褒められたと今でも思ってます。でも仕事の話とか、今度うちに遊びにいくよ、みたいなことも仰ってたのでいいのかな。気にしないでおこう。

あと、何人かインターンシップで来てみたいという学生もいるらしい、という情報を耳にしたので、とりあえず頑張った甲斐があったかなと。
こういうのは続けてこそ、積み上げてこそ成果が出る物なので、地道にいきます。

2009年12月10日木曜日

中間データを意識してWikiで文章を書いてみた

Wiki書式を中間データにして、InDesignとかMC-B2に持ってこう、なんて企画があって、実際お客さんに言ってみたらサンプル的な題材をいただくことができたのでやってみました。
※公開はできないですが。

「文書構造」なんていうと、XMLを思い出してしまいますが、ぱらぱらとその辺の本を見てみれば分かりますが、「ルールは、あるようでない」のが普通。なのでXMLとか考えるのはやめましょう。

今日あるお客さんのところでも、「XMLは機械(システム)同士のやりとりのためにあるだけで、人間がタグ打って作る物じゃない」という話で盛り上がりつつ、数年前は、それしかなかったから進めてた学会系のって、そろそろ変えませんか?的な提案をしないとな。。。

マニュアルとか、書き物自体が一定の構造を持っているもの、持っていた方がいいものは別として、たいがいの読み物は、ルールはなかなか作れないので、それならば「書式」として統一性を持たせる方向で考えた方が素直じゃないかということでWikiなのです。

XMLだと書式、スタイル、レイアウト、文書構造が一緒くたに考えられがちで、混沌とし過ぎて、「結局、何でこうするんだっけ?」みたいな意味不明の作業になってしまいます。

とりあえずWiki書式で書いておいて、複数の著者が好きなように書いたやつを統合するときに、全体のバランスをみて、揺れの調整をばっさり掛けてしまう感じで、一度に難しいことをやろうとせず、徐々に整合性をとっていくようにすれば、深く考えずにいけるかなと。
それよりもまず、DTPにしかなっていないデータをちゃんとその他メディアとも行き来できるコンテンツとして集約していかないと、とにかくもったいない気がしてならないのです。

なので、次のステップは、WikiをB2とInDesignに落とし込みをする予定になってます。

2009年12月9日水曜日

制作フローを分析してみて思ったこと

分析といってもあんまり大袈裟なものでなくて、入稿から納品まで、どのようなフローになっているのかなと、再確認したかったのでやってみました。

久々のオムニグラフ登場で、こいつぁ使えるねえ、とぶつくさ言いながらやってみたわけですが、だいたい出来たものを眺めてみて、

「うーん、分かりにくい…」

確かに、分かりにくい。。。矢印が各方面に出ていたり、分岐が多かったりということで、
気付いたのは、

「分かりにくい=作業が複雑化しすぎている」

複雑化は、無駄を生み、ミスを誘発する可能性があるので、これはなんとかせにゃいかんなと。

メールとかFTPとか、PDFとか便利なシステムや機能がたくさん出てきていいんだけど、乱立してしまったり、それぞれの連携を考えていないと、分散、複雑化するだけで実は時間が余計にかかっていることがある。そもそも時間を短縮するためのものだから。

確かに、これだけ複雑になっていると、迷いが多くなるので、初心者ほど、作業の手をストップさせてしまうとか、作業の流れを見渡せないので、その人しかわからなかくなっちゃう、という、「なんかよく分からないけど時間がかかってる」理由のひとつなんじゃないかと思えてくる。

作業はパターンな訳で、こうきたらこうする、こうきたらこれらの選択肢から一つ選んで次へ進む、というだけ。通常の制作業務で新しいパターンが存在してくることはまず無いと思う。(多分)
出会ったことのない新しいパターンのように思えるのは、それを単品で考えてしまうからで、何かの派生、何かの類似として、パターンにはめれば驚くことはない。たまに、今までやってきたとおりにしかできない人がいますが、そういうパターンを外れた瞬間こそ、いつもどおりやればいいし、今までの経験から何かと何かが繋がって、こうすればいいじゃん!という発想が生まれやすい瞬間でもあると思うのです。

もうちょっと事情を聞くのと、所々でトラップしようと思います。

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

2009年10月24日土曜日

InDesignとEdianWingとMC-B2を比較〜向き不向き編

前回の価格編から、早々と続けます、、、

うちの場合は、DTPはもうコレ一本でいこう、とかいう無茶なことはしない方針で、そもそもDTPアプリはツール(道具)なので、どれを使うかは用途に合わせるべきだと考えています。

今回の比較は、ソフトウェアに対しての「慣れ」という視点を外さないと成り立たないので、そこは注意したつもりですが、いやいやこう使えばいいんだよ、とかあれば、優しくつっこんでください。

昔、組版とDTPの違いなんてのをブログに書いた気がしますが、おさらいすると、
・枠を置いてから位置を合わせる(数値とか整列とかで)→DTP的
・数値を決めてから枠を置く→組版的
な感じです。

先日、うちの開発部長O氏と話していてもう一つ気付いたのですが、
・一度置いた枠は、全体のバランスを調整するために、移動するのは当然→DTP的
・一度置いた枠は、計算して配置したのだから原則移動しない→組版的
というのがあります。

それはO氏の「Edianで、枠を動かそうとしたら、その枠の端っこ(つまり線上)をつかまないと、移動してくれないんですね、ちょっと戸惑いました」という話から。
O氏は、開発部長ですが、もとはDTPオペレーターです。
イラレとかQuarkとかを使って、チラシなどを沢山作ってたと聞いています。
僕はEdianオペレータでもあったのですが、InDesignをさわり始めたとき、感じたことがありました。それは、「枠が簡単に動きすぎる」ということです。「ああ、また動いちゃったよ。Ctrl+Z」の繰り返しが多くてイライラしてしまいました。それも慣れたら別に気にならないのですが。

そういう視点からすると、まず1点目の向き不向きのポイントは、
・InDesignに向いているのは、ページ上に複数のオブジェクトを配置する必要があって、それをさらに動かすこと(調整すること)が多い仕事
・EdianやMC-B2に向いているのは、本文枠(動かない固定された枠)を使って、ほとんどがそこに流れて、その間にいくつかオブジェクトが配置されるもの。本文に対してその他オブジェクトの発生する比率が低いもの

これは、InDeisgnがデザイン的なものに向いていて、MC-B2、Edianは文章ものに向いている、と言われる一つの理由かなと思います。

ここをもう一つ掘り下げて言うと、
・InDeisgnに向いているのは、コンテンツ(内容)に応じて、オペレータ判断で、自由に調整していいもの、もしくは、調整が必要なもの
・Edian、MC-B2に向いているのは、最初の組版設計に基づいて作業するもの、またはしなければいけないもの。

と、これは、デザイン的センスが多分に問われるDTPと作業効率命の組版の考え方の違いによるものということになります。

しかし、InDesignは文章ものが弱いのか、効率化できないのか、というとそれはちょっと違いますね。いやかなり違いますね。

では、次回は、もうちょっと作業そのもの(効率化とか)に掘り下げて比較してみようと思います。

InDesignとEdianWingとMC-B2を比較〜価格編

なんでInDesign、EdianWing、MC-B2かというと、うちが使っているものなので、それ以上の意味はありません。

色々比較をすることがあるのですが、まず今回は価格で見てみます。
※価格は現時点です。

●InDeisgnの場合
・CS4 Design Standard 約20万円
・Office 2008 for Mac 約5万円
・Parallels 約1.2万円
・WindowsVista 約3万円
・Macmini 2.53GHz Intel Core2Duo 4GBメモリ 約9万円
・21インチモニタ 約3万円
その他もろもろ(フォントとか)合わせて、50万円ぐらいですかね。

●EdianWingの場合
ハードウェア込みで350万円。
スペックもそこそこ出してくるので、それは特に問題ないですが、早いところソフトウェア売りを前面に出した方がよいと思われ。。。

●MC-B2の場合
MC-B2は色々オプションがあるので、うちの場合は、学参系があるので、数式オプションを込みにして、その他諸々で、ハードウェアもそこそこ準備して約200万円ぐらいですかね。

●価格比 InDesign:EdianWing:MC-B2=1:7:4
ということは、EdianWing1台で、InDesign7台分、MC-B2約2台分の仕事をせにゃいかん
そして、MC-B2 1台でInDesign4台分の仕事をせにゃいかん

計算あってますか・・・

まあどんな仕事でもこの比率で考えてOKかというと、そうではないのは確か。
数式が多いものなら、MC-B2は軽くInDesignの4台分の仕事をこなすだろうし、ラウンド罫巻きの表が繋がる大量ページものなら、EdianかB2の方が早いだろうと思う。
要は内容に合わせてどう使い分けるか、だと。

なので、次回は、仕事の種類から見てみようと思います。

2009年9月9日水曜日

Firefox add-on Selenium IDEでWebテスト再び

だいぶ前にブログでも書いた気がしますが、
ちょっと前から「Seleniumスゲー」「っていうかやるべき」「なんかGroovyで書き出せるらしい」と、盛り上がってまして、
使用前、使用後で自分自身どう変わったかというと、Grailsで何か作るときに、
・コントローラーの中に、初期データ取り込みのアクションを書いていた自分
・新規登録ボタンをクリックして、各フィールドにテストデータを入れていた自分
そんな自分が、なんと、
・Seleniumでテストを書いている
そうなんです、いちいちブラウザでテストデータとかを登録しなくなった。

これは快適です。生産性が上がってます、確実に。

使ってみたい人は、ここに詳細があります。

で、今日たまたま山本さんもおらんので、開発メンバーのテーブルでちょっかい出しながら、何かやっていたのですが、何やら対面の部長から、Kムーに指示が。
「このサイトで、こうやるとこうなるかチェックして欲しいんだけど…」
とリストが渡されました。
「これはキタ」と思ったので、Seleniumでやるといいよ、と助言したんですが、
とりあえず急ぎらしく舐めるようにやってました。
そして、次の指示…
「じゃ、こうなったときも」と追加指示。
「ホントにキタ」と思うや「だからSelenium使えばいいのにっていったのにー」
と椅子を何度か叩いてみました。
最初から使っていれば、ちょっと追加、変更するだけで使い回せるんですよね。
Webテストだと見た目でのテスト、ユーザの立場としてブラウザのテストなだけに、
絶対何度もやるハメになります。

でも、テストのテスト的にしか使ってなかったので、実際「業務」としてやるとどうなんだろうと、一緒にやってみました。
そこで今回使ったのは、以下のコマンド。
多分これらを使いこなせば大抵のことはできそうです。
※コマンドを全部見てるとくらくらするぐらい沢山あります。

・ページを開く(遷移する)
コマンド:open
対象:ベースURL以降に行きたいページを入れる

・文字を入力する
コマンド:type
対象:エレメントID
値:入力する文字

・ボタンをクリック
コマンド:clickAndWait
対象://input[@value='ログイン'] 
「//」は、XPathの始まり。この場合、inputタグでvalueがログインになっているところをターゲットにしている。firebugで対象を調べると楽ちん。

・そのページの中に指定した文字があるかどうか
コマンド:assertText
対象://h1
値:ログインしてください。

・そのページのURLが指定したものを一致しているか
コマンド:verifyLocation
対象:そのURL

・今いるページの画面キャプチャをとる
コマンド:captureEntirePageScreenshot
対象:保存するパスとファイル名
例えば、/work/project/webtest/shot01.pngとか。

完璧です。テストが通るとガスター10なみにスッキリします。
テスト結果をとっておくなら、とりあえずログをコピペなんだろうか、、、

最初、Seleniumの存在は知っていても、「仕様変わるから、今テスト作っても無駄になるもん」と思ってました。
でもこれは大きな間違い。そういってたらいつまでたっても書けない。
面倒か、無駄か、と言われると、絶対にそうじゃないと言えます。
変わるからこそテストを書く必要がある。

仕様が変わったら、コードの中身を変えたら、テストも合わせて変えればいいんです。
だって、コードを書き換えたら、ブラウザでのチェックって絶対やりますよね。
そういうとき、絶対「あああ」とか「test」とか沢山うってるはずです。
そして確認作業は、コンディションによってとっても左右されます。
だから機械的にやるべき。Don't Repeat yourself!ですよ。

2009年9月3日木曜日

InDesignCS3か4で表をエクセルとリンクさせる

マニュアルとか読んでないので、間違ってたらごめんなさい。

「InDesign上の表と、エクセルで作った表をリンクさせる」という結構、夢広がる機能ですが、
ちょっと触ってみた感想です。

方法としては、「InDesignの勉強部屋」の「表スタイル・セルスタイル 」にあります。

データ更新は、エクセルの更新日とInDesignに配置したときの日付で差分をみてるようです。

これの使いどころは、以下
・表の形がだいたいパターン化できそう
  ※全部ばらばらなら、最初の取り込みの時だけ楽しいです。

・結構たくさんあるとき
  ※1、2個なら何も考えずに作った方がいいです。

・セル内の文字に対して、文字スタイルを付ける必要がない
  ※正規表現スタイルとかでいけてしまうならOKかと。
  ※リンク更新すると、単純につけた文字スタイルはとれてしまいます。

・結構データ更新が多い(多そう)

なので、
 表・セルスタイルでばっちり作れるなら、是非やるべき。
 これはお客さんにも校正や制作速度においてメリットがあるので、ちゃんと出来ること、出来ないこと、やっていいこと、やっちゃいけないことを説明してお客さんを巻き込んでやらなければいけないです。

しかし、以下とっても大事なこと
 アプリを信用しないこと。
 何かあってもアプリのせいにはできません。
 ちゃんと確認することは変わらず大事です。
 ただそれがちょっと楽になるというところです。

DTPって
 なかなか手順というのが揃えにくいものですが、こういう良い機能があるなら、
せめて表のところだけでも仕様を決めてやると、楽しくなりそうですね。
 

2009年8月3日月曜日

Grailsで運用中アプリのドメインクラスを変更したとき

忘れないうちに。。。

もう3ヶ月ぐらい使っていて、2500行ぐらいあるテーブルに、フィールドを2つ追加する。
これらは、NotNullにする。
前からあるフィールドのうち、2つはNotNullをとる。

1.まんず、ドメインクラスを追加、変更
class Task {
.....
 // 作業依頼時間
 Double assignTime
 // 作業依頼日時
 Date assignDate
.....
 static constraints={
.....
  assignTime(nullable:false)
  assignDate(nullable:false)
  workTime(nullable:true) ←falseからtrueに変更
  workDate(nullable:true) ←falseからtrueに変更
.....
 }
}

2.これで一回GrailsをRun-appして起動すると、、、
ポスグレさんがどういう風になるかというとで、pgAdmin3氏に聞いてみます。
すると、、、
・assign_time,assign_dateのフィールド(列)は追加されているが、NOT NULLになってない。
・work_time,work_dateがNOT NULLのまま。
となっています。
これだと、なんやかんやGrailsさんから怒られるので、DBを調整します。
調整しなければいけないのは、
・assign_time,assign_dateにデータを入れる(とりあえずwork_time,work_dateをコピー)
・assign_time,assign_dateをNOT NULLにする
・work_time,work_dateのNOT NULLを外す
の3項目。

3.pgAdmin3でできるのか?
とりあえずGrailsを停止。
pgAdmin3でTaskテーブルを右クリックでプロパティを選びます。
ここで「列」のところで、assign_timeを選んで、NOT NULLにチェックボックスを入れてみます。
そうすると、pgAdmin3氏が、「いやー、この項目はデータが入ってないから、NOT NULLにはでけんへんよ、無茶やわぁ」と言ってきます。多分、そういってる気がします。

4.psqlでデータを入れる(今回はあるフィールドの内容をそのままコピー)
$su - postgres で、ポスグレさんになります。
postgres$ psql DB名 で、データベースにアクセスできる状態にします。
DB名=>\d ドメインクラス名 で、フィールド一覧が出てきます。
Table "public.task"
Column | Type | Modifiers
--------------+-----------------------------+-----------
id      | bigint          | not null
version    | bigint          | not null
date_created | timestamp without time zone| not null
last_updated | timestamp without time zone| not null
project_id  | bigint          | not null
title     | text           |
work_date  | timestamp without time zone| not null ←ここを外す
work_time  | double precision      | not null ←ここを外す
work_user_id | bigint          | not null
assign_time | double precision      |  ←ここにnot null
assign_date | timestamp without time zone|  ←ここにnot null
多分こんな形がでてきます。
フィールドの追加はうまくいってますが、制約が微妙になっています。

↓work_timeをコピーして、assign_timeに入れる
DB名=>UPDATE テーブル名 SET assign_time=work_time; 

↓work_dateをコピーして、assign_dateに入れる
DB名=>UPDATE テーブル名 SET assign_date=work_date;
※ちなみに日付を指定していれたいときは、
DB名=>UPDATE テーブル名 SET assign_date=TO_DATE('2009/08/03 23:59:59', 'yyyy/mm/dd hh24:mi:ss');
とすれば入れられます。

5.NOT NULLをつけたり、とったりする。
↓とるのはDROP
DB名=>ALTER TABLE テーブル名 ALTER COLUMN フィールド名 DROP NOT NULL;
↓つけるのはSET
DB名=>ALTER TABLE テーブル名 ALTER COLUMN フィールド名 SET NOT NULL;
pgAdmin3氏のテーブルのプロパティにあるSQLを見ると、どんなSQL文なのかすぐわかります。

6.まとめ
一度走ってしまってから、こういう変更って結構ありそうですよね。
テーブルの追加、リレーションの追加とかは結構影響範囲も大きく、大幅な変更なので、時間をかけてやってもいいですが、これぐらいはさっくりできないと、ということで、さっくり出来たのでめでたし、めでたし。

2009年7月27日月曜日

DTPの勉強部屋 第14回に行ってきました

昨日Twitterで、ブログ3本かかなきゃと言い放った後、爆睡zzz
お昼近くに目が覚めたとき、今日が何曜日か分かってなかったので、そうとう深いところまで行ってたと思います。帰って来れてよかった。。。

せっかく、浅田さん(psychocatさん)が、このブログを紹介してくれたのに、「ザリガニ釣り」の話だと「???」になってまぅーっ、、、はい、ということで。。。

なんと80名ぐらいですか、すごい人数集まってましたね。


セッション1.DTP作業を楽にするスクリプト入門


発表者:たけうちとおるさん(遊文舎)

現在、InDesign、Illustratorのスクリプトが50個ぐらいになって、
たけうちとおるのスクリプトノートからダウンロードできます。

そのスクリプトを1個ずつ、丁寧に解説してもらいました。
「へー…」と思いながら聞いてましたが、たけうちさんて、仕事もしながら、こういうのまとめてるんだよな、、、と。スクリプトを書く人は沢山いると思うんですが、ちゃんとまとめて、そして人前で紹介するというのは、、、よっぽど好きじゃないとできないですよねえ。

こういったスクリプトって、結構「使い捨て」になる可能性が高い。
だから、上手く出来ても自己満の世界で終わる可能性も高い。
スクリプトを書くこと自体は、それほど技術的にスゴイスキルが必要というわけではない。
誰でも「やろう」と思えば、絶対にできる。スゴイのは、実作業の経験、現場経験の中で、「やろう」「やってみよう」と思って実行に移せる実行力だと思う。多分好きか嫌いか、興味があるかないかの違いです。
その時には、時間がかかってしまうかもしれないけれども、経験を積めば、足し算できるものだから、徐々に効率は上がるはずです。

たけうちさんやせうぞーさんなど、参考にさせてくれるサイトもあるので、勉強するには敷居は低いと思います。まずは自分で試しながら、そのうち、ユーザーインターフェース(たけうちさんのはやっぱり経験豊富だからぱっと見使いやすい、使いたくなる)も洗練されてきて、使いやすくできれば、他の人にも喜ばれるようになると思います。DTPオペレーターは、仕事柄お隣の席に座っているオペレータとコミュニケーションするのもなかなかできない気がしています。そういうコミュニケーションのツールとしてもいいんじゃないかなと、あの大勢の参加者を見て思いました。

最後に見せてもらった、Rubyで作ってるのかな?Word→XML→InDesignタグテキスト出しする仕組みも面白かった。まずはクライアントで動くスクリプトを作って、それを活かしていけば、WEB入稿の仕組みを作ることも今はそれほど難しくないと思います。皆さん、というか僕もですが、もっと進めていきたいですね。

セッション2.自動組版のはじめの一歩


発表者:Psychocatさん

まずは自動組版とはなんぞやということについて、メーカーではなく、ひとりの現場の人間としての意見をまとめておられました。共感できる内容ばかりで、「自動組版」という言葉に踊らされてしまう、だまされてしまう、そういう幻想と現実について1時間ぐらい。いろんなところで、自動組版に関するセミナーとかありますが、こういう話がまず最初に語られるべきであって、製品紹介とか事例紹介とかいらないと思います。ほとんどの場合、現場に合わない。よいツールであるとは思いますが、結局何もしてくれない。大事なのは、その仕事に関係する人たちの「考え方をまとめていくこと」であって、、、そのあたりは、前に書いた気がするのでこの辺で。

懇親会で聞いたのですが、今おいくつか忘れましたが、プログラムを書き出したのは37歳からだそうです。そこから、AppleScript、Perlなどなど自分で勉強、実践しながら、ここまで来たそうです。スゴイですね。
当日の内容は、ここにあります。後半はこの内容に沿っていろいろとエッセンスを教えてもらいました。僕は実際試しながら聞いていましたが、とっても面白かったです。スクリプトだから、動かせばその場で結果が見える。そういう手軽さはDTPにとっても必要です。設計書なんてものはないんですよね。ハハハ。ここだったか、うちが最初に仕様を書かないのは。。。確かにこの手のものは、パッケージ商品にすることは難しいんですよね。あまりにパターン(レイアウトという意味じゃなく)がありすぎる。

まとめ



お二方の作ったものを垣間見ることができましたが、どちらも「相手が思う一歩先まで考えている」ということです。たけうちさんもPsychocatも、やりたいことに対して、こういうものが必要だろうとか、こういうときはこうするべきだという、現場経験から出てくるアイディアであったりするので、現場に採用されるのだろうと思います。
「現場のものは現場で作る」という発想は、幻想ではなく当然のことだなと思いました。
Psychocatさんが懇親会でちらりと仰ってた言葉で、「もし自分が作ったプログラムで何かおかしい結果を生んでしまったら、自分で全部直す。。。プログラムでね。」という気合いと責任感。この人はプロだなと思いました。

懇親会で見た風景



居酒屋なんすけど、、、たけうちさんによるNDD(飲み屋ドリブン開発)。
いいですねえ。今度は最初からお酒ありでやってもいいかも、ですね。飲みながら何か作る。
Grailsの忘年会のときやりましたね、そういえば。面白かった。

・関係ない話
今日はお子さんのお友達のおうちがやっている中華料理のお店に行って来ました。
麻婆豆腐絶品。四川なのかな、一瞬辛いんだけど後を引かない。日進市の「八兵衛」です。行くときは声かけてください。一緒に行きます。もちろん、アンタのおごりでね、、、はい、おやすみなさい。

2009年7月26日日曜日

JGGUG名古屋支部 第2回 Grails/GroovyそしてAIR勉強会 

第2回も、またまた結局20名以上の参加者となりました。
なんにせよ、来ていただけるというのは、主催者としてはうれしいもんです。

レポートは後ほどユーザグループから配信されると思うので、ここでは、私的所感を。

今回は、昨年の忘年会、0.9回、第1回とやってきて、Grailsが中心で、そういえばGroovyをやってないなと。知名度的には、やっぱりスクリプト言語系でいけばRubyの方が高くて、RoR同様、Grailsとの比較もされたりしますが、ここ名古屋近辺では、どちらでもなく、WEBアプリ開発と言えば、どちらかいうと、PHPなんですかね、やっぱり。。。

日本語のドキュメントからすると、Groovyなんてほとんどないわけで、実務プログラマの言語の選択条件としては、不利なんだろうな。ま、日本語文献あったからどうよってのもありますけどね。あまり親切すぎる(?のときにすぐに回答を探せる)と、回り道をしなくなるので、それは技術を磨くと言う意味では、あまりよろしいとは思えない。もしくは、すぐに辿り着けると、その答えが全てであって、はい次、となって、それも深くない。といいつつ、情報が足りなくて、右往左往、うんざりするのも生産性としてはよくない。商売なので。難しいですが、長い目で見ればもう少し「探る」という人間的感覚、機能を養うことも重要なので、多少回り道であっても、自分コントロールをしながらやらなければいけないよなと思ってます。
なので、GParallelizer試そうかな。関係ないけど。

一番後ろで、サンプルコードを試しながら、再確認してました。勉強会ってPCがあった方がいいです。その後、勉強しようと思ってもなかなか時間とれないし、その場の雰囲気やニュアンスってすぐ忘れてしまうので、こういうときこそチャンスと思って、僕は、一緒にガンガン試します。やっぱり、自分で動かして、おーっとなれば、なんとなく「内容の理解はともかく、動かすことまではできた」という経験値を頭に入れておきます。そうすれば、あとで、「あんとき出来たんだから出来るはず」となれます。そのぐらいのことはやっておかないと、僕の場合、頭に入らない、ということだけなんですけどね。そして時間を有効に活用しないとね。
だから、山本さんが「どうだったのかなー」と言うので、「個人的には超勉強になった」と答えておきました。


芳村君のFlexも面白かったな。社内でもあんな感じやって欲しいね。やっぱり「見ず知らずの人に何か教える」というときに、色々考えてやると思うんですが、その丁寧さって重要で、社内だと、分かってる、理解してる前提、人も知っている前提で話すけど、実は、僕をはじめ、あんまり分かってないので、この日の内容はとっても丁寧で勉強になりました。


うーん、なんだか自分ばっかりしっかり勉強になっちゃってたら、申し訳ないな。。。
皆さんはどうだったんだろう。。。

2009年7月24日金曜日

GC中部の広報委員になったのでした

かなり前に、写植組合みたいなのには参加していた気がします。
JP@大阪で流れに身を任せつつ、二つ返事で入会。新参者は何でもやって目立たねばならんという家訓のもと、広報委員もやらせていただくことに。

ちなみにGC中部というのは、正式名称を「中部グラフィックコミュニケーションズ工業組合」と言います。写植・製版の会社の集まりで、印刷を主とする会社ではないのです。

チャリで10分ぐらいで委員会打ち合わせ会場へ。

うーん、たまに見るビル。ココだったのか、、、


ちゃんとありますね。。。

今まで、本拠地名古屋で業界的繋がりがない中で、そういう輪に入るのが苦手だった20代中盤からすると、オレも大人になったもんだと。しかし、リュックを背負って汗ダーダーでお腹が気になる36歳は、立派なオッサンだなとも思うのでした。

ここ最近は、自社のことを考えると、行き着くのは、もっと周りと一緒に、周りを巻き込んでいかないといけないなと思い始めたところでした。今の考えや、やりたいことが正しいのかどうか…そういうのは、もう少し行動範囲を広げて、意見を言ったり、聞いたりしないと、分からない。中途半端でほっておくと、多分、「ま、いいや」とか「どうせ」とか愚痴になってしまって、一歩下がって見ていることになる。そういうのが嫌いというか、後悔し、自己嫌悪に陥るのはイヤなのです。と言いつつ、ずっと自ら蚊帳の外であったわけですが。。。

委員会6名中、3名が同年代だったのですが、関東ではまだまだご年配の方がほとんどの組合もあるとか。中部は比較的若返りしている会社が多いとのことで、何かできるかもしれない、変えられるかもしれないという私自身期待を膨らませるのでした。

会合のあとは、ラーメン屋さんというか中華屋ですよね、で雑談。最後の「涼麺」は上手かったです。

2009年7月23日木曜日

G*4に行ってきた

JGGUGイベントのG*第4回(2009年7月22日)に行ってきました。

横浜CIJさんに行くのは久しぶりだなあと道中。
GCRの頃からすると、参加メンバーも増えて盛り上がってきたよなあとぶつぶつ。

2時間で4セッション。ちょっとオーバーしたけれども。
レポート役をかって出てしまったので、超真剣に聞きました。
上原さんのところで、「…やべー…わかんねえ」となりながらも、「そうだ、この人は言語ヲタクなんだ」と言い聞かせて乗り切ったのでした。

とはいいつつ、それぞれ個性豊かな内容で、大変興味深かったです。
僕にとって近くて遠いGrails。近づいたかなと思うと、また離されて。でも気がつくと近くにいたりと、そんな毎日です。

懇親会で、とある方が、「昔はこんなに違う会社の人たちが集うことってなかったな…」と仰っておりました。時代は変わっていくし、変えていかなければいけない。そう思う人たちが集まると単純にオモロイです。僕はもっぱら「ついてかなきゃ」ですが。。。

今週7月24日は、JGGUG@名古屋でイベントです。
その後25日はDTP勉強部屋です。こちらも盛り上がりそうだな。

2009年7月22日水曜日

西尾祭り行ってきました

基本的にお祭りは大好きなのです。
生憎の天気。でも雨はぱらぱらで、なんとかやり過ごせた感です。



なんだか若い子が多かったですねえ。
でもあんまりやんちゃな感じではなかったです。

ふと、ヨーロッパ方面の革命運動で、「民衆のガスが溜まりに溜まって爆発した」なんてフレーズを思い出し、町全体で、状況が悪くならないうちにちゃんとそういうガス抜きを公然としておかないといけないんだよなと。住んでる町じゃないのになんですが。お祭りにはそういう意味もあると思いました。

さて、金魚すくい。

前日風呂でおじいさまと練習していたようで、その成果が出てました。


この後、さらにもう一軒金魚すくいにいって、コクワガタ(3匹100円)をゲットし、今ではザリガニ、カブトムシ、クワガタ、メダカ、金魚とおうちをかなり占拠し始めた次第です。

不況というのは事実半分、気持ち半分だと個人的には思っているので、現実で考えていたらそれが自分の限界値、明るく楽しく前向きに考えないと将来もない、と自分に言い聞かせるのでした。

ザリガニ釣りをした

僕も一児のパパとして、思い出をつづらなければいけない。。。と夜中にふと思い立ったので。

住んでいるところの近くに、山から下りてくる小さな川がありまして、そこに「ザリガニがいる!」と言い切るので、行ってみました。


釣果は↓+α。はっきり言って入れ食いです。わんさかおりました。
6歳児のみで10匹弱いったと思います。

お持ち帰りは、厳選の3匹。うち一匹は先日哀れな姿に・・・

今回の仕掛けは、↓んな感じ。竿は、バス用ロッドは却下。家庭菜園でツルを絡ませる緑の棒です。それに軽めのラインに、よりもどし+大きめの針。あとは、もう2年ぐらい使っていない、バス用の疑似系ワーム。これがまた水の中で、オタマジャクシに見えるんですよね。


ふと、パパは思い立ち、さらに後方にある調整池に行くことに。


びゅ、ビューティホー!パラダイスじゃあないですかああああ!
子バスがぴょろぴょろ。うーん、これは・・・
家から車で5分弱。チャリで10分弱。こんなところにあったとは。

と、自分のことはさておき、
「ザリガニ釣り」と言えば、今でも幼少の記憶として残る数少ない父とのイベントの一つであり、我が子もそのような記憶になるのだろうか。その後、「川釣り(木曽川が近かったので特に河口釣り)」については、糸の結び方、えさの付け方、ウキの見方、合わせの仕方、潮の見方、竿の出し方、お祭りになったときのほどき方、川や海の怖さ(何回か落ち、何回か流されかけた)、何より釣れたときの感動、などなど釣りを通して色々教わったんだなあと思い出したのでした。

2009年7月18日土曜日

学参のDTP・組版をどうするか〜大改訂に備える

「学参の波」は、じわじわと忍び寄ってますが、実際どうなるんだろうということで、現時点でちょっとまとめてみます。

1.「学参」とは…


「学参」は、「学習参考書」の略。多分。
教科書を元にして作られる本です。本屋さんに並んでいたり、学校で配られたりする本です。
教科書の内容は、文部科学省による学習指導要領が何年かおきに改訂されます。
それに伴って、学参書籍も改訂したり、新しく作ったりします。

2.「白表紙」について


教科書を巡る問題は度々報道されたりしていますが、その中でも白表紙問題というあります。「白表紙」とは、教科書検定に申請する申請本のことを意味しています。
参考書や問題集などは、教科書と一緒のタイミングで必要となります。
以前は、この白表紙をもとにして、学参書籍の本作りを進めて、その教科書が検定に通って、多分そこからちょこちょこと修正が入って完成するわけですが、それに合わせて、学参書籍も修正して発行すると、そういう流れだった(…らしい。出版社の人間ではないので詳細は分かりません。)のですが、この白表紙にあたる書籍の内容を検定前に公開する行為が、出版社による教科書の宣伝行為だと、いう話になってしまって、検定まで外部へ出してはダメということになりました。※その他利用もあると思います。
これによって、学参系出版社は、作りたくても、元の本が手に入らないために作ることができないという状況に陥っています。
「公開されてから作ればええやん」と思うかもしれませんが、なんせ時間がないのです。
まあしかし出てこないのは出てこないので、さてさてどうするか…

学参組版の課題・問題点(制作会社という立場から)


この辺から、制作の立場での意見になります。
最初に現在考えられる課題・問題点をまとめておくと…
1.制作期間が極端に短い
2.制作できるところ、人が減っている
多分現実ダブルパンチ(おお、懐かしい響き…)です。
学参組版にもいろんな種類があるけれども、一般書籍と違ってそれなりの技術と経験が必要とされます。なので作業は結構時間がかかります。
しかし、現実的、物理的な「時間」あるいは「コスト」という制約がある以上、次のことを考えなければいけません。

今、何をすべきか


「短い時間(短期間)で、効率よく(省力で)下版までもっていける制作フローの確立」
「省力って、手を抜くんかい」と思うかもしれませんが、そうではなく、原稿作りから、やりとりの手間、印刷工程までスムーズに流す、ということであって、決して適当にやるということではありません。
「少ない力で高い品質の組版を実現する」ということであり、今やらなければいけないことは、やるべきことは、この準備です。

「自動組版」、「XML」は解決策じゃない


「省力化」というと、ついついこういう発想にいきがちです。
「自動組版」は、頭からおしりまで、すっぽりと収まらないと意味がありません。
ちなみにWPS(情報誌の自動組版システム)は、すっぽり収まってますが、多種多様、組版の性質からして、これに当てはまるとは言えません。まして「XML」なんていうのは、何かに使うときに考えることであって、使える状態でデータが揃っていないという今、考えるべきことではありません。

まずは情報を整理してデータを集めましょう


改訂本にいたっては、製版以降で修正している可能性もあって、DTPデータと最終データがイコールであることも疑わしい状況です。ちゃんと管理しているようでも、実際のところできていないところが多いと思いますが、これには理由があります。
「環境が変わりすぎ」なのです。組版が専用機で行われていたときは、外部環境との関係が、悪く言うと「孤立型」「親和性がない」、よく言うと「依存しない関係」にありましたが、現在はどこでも買えるPC上で動くので、OS、ソフトウェアなどなど依存する部分が多い。
こういう環境下では、どう管理するかも変わってきてしまうので、だったら、とりあえずデータをここに置いておこう、という程度しかできないのです。
整理できていないという前提のもと、一度ちゃんと表に出してみて、整理し直すのが第一歩だと思います。

失敗や苦労を繰り返さないために〜コンテンツを無駄にしない


学参のコンテンツは、使い捨てのものではありません。編集者の方たちが一生懸命原稿として仕上げた知識のかたまりです。
しかし、そのコンテンツが収められている場所は、DTPデータの中です。
DTPデータは、その先の行き場を失ったデータ、言いたくないですが、「ゴミデータ」であることが大半です。DTP化によって「他アプリケーション(データ)との親和性の向上」「デジタル化による印刷コスト削減」というのがまるで恩恵のように謳われていましたが、なんのなんのそれによって引き起こされた問題は、この業界の将来性をも削っています。
一昔前のアナログ→DTP化では成し得なかった、このデータを生きたデータにして使えるようにするということも、今回は重要な課題です。

組版側として考えなければいけないこと


印刷は機械の性能の向上によって、時間短縮、ミスの軽減など図れると思いますが、制作作業は、機械やソフトウェアがやってくれるわけではなく、「人」がするものです。これは昔から変わりません。しかし、その重要性が、印刷の付加価値、効率化などなど、そのようなうわものの方へ考えがいってしまって、忘れられたのは、我々にも責任があると思います。もともと立場の弱く、表舞台にたてない、スポットライトのあたらない場所であるという諦めから、悪い流れに対して、堰き止めることができなかった。
組版側=作り手側として、そういう反省をしたうえで、まず以下のような後々問題を引き起こす可能性があるものへの考え方を改めなければいけません。
・ソフトウェアやそのバージョンへの依存
・フォントへの依存
・作った人(作り方)への依存
・印刷工程への依存
これらを解決していかなければ、またまた「ただ作るだけ」に陥ります。

「作り方(制作手法)」の重要性


品質を高めることに対して、無限の力(時間)が使えるなら別ですが、往々にしてそうではないのが現実です。であれば、品質とコストのバランスを考えた作り方をしていかなければいけません。基本的に「人が手を加えるべきところを極力減らす」ことができればよく、元来組版は、すべてオペレーションによって完成まで持ち込むものではありません。そんな非効率な手法はありません。組版のルール、本作りのルールの上に成り立つものです。人が手を加えればいいものができるかというのも、現状のレベルを考えると、今ではもうなく、「手を加えれば加えるほどおかしくなる」というのが現実でしょう。作り手が考えることは、いかに手をいれずに作るか、いかに手を入れやすい作り方をするか、これがポイントです。

「乗り換えありき」で考える


さあ、学参組版にはどんなソフトが一番いいんでしょうか。InDesign?MC-B2?EdianWing?Quark?写研?その他いろいろあって、それぞれにメリットデメリットがありますね。
・InDesign
メリット>安い(CS買うとついてくるおまけ)、QXからの乗り換えとかもあって普及している。スクリプトを使いこなせれば強力なツールになる。データの出し入れはそれによって吉。
デメリット>学参でも細かいものになると手数(人もそうだけど、操作ステップ)が必要。ちょっと不安定っぽい。やっていて「うっそ〜ん。。。」とかよくある。
・MC-B2
メリット>「組版」には向いている(「DTP」には向いていない)。数年前と比べて格段に良くなっている。タグやマクロを使いこなせばかなりよい。
デメリット>ちょと高い(セットで150万円ぐらい?)。ちょと不安定。
・EdianWing
メリット>DTP的、組版的両方に使える機能がモリモリ。オールラウンドで使えて安定もしている。
デメリット>かなり高い(ハード込みで350万円)。対応とかこれからが微妙。
・Quark
メリット>往年のQX使いは多い。なんだかんだでQX3.3ユーザはまだまだ多い。いろんなツールが出ている。
デメリット>ちょっとInDesignに押されすぎで影が薄くなった。最新の情報(メーカーではなくユーザの)が少ない。
・写研(最近使ってないので、聞いた話と見た話で)
メリット>専用機なだけあって、組版を考えつくされている。書体(あえてフォントではなく)の良さは、なんともいいようがない。
デメリット>いろんな意味で減っている。
と、まあ総合すると、InDesignを頑張って使いこなすか、B2やEdianのようなものの機能を使いきって人手を減らすかというような感じです。多分トータルコストは同じなはずです。違うところといえば、日本語組版というちょっとやっぱり海外の組版とは違う要素を、米国産(だっけ?)のInDesignがどこまで吸収してくれるか、じゃないかと。

どんなソフトウェアでも、寿命があります。今までの経験、これからを考えたら、「乗り換え」を視野にいれなければいけません。乗り換えとは、DTP・組版ソフトでもあるし、そのコンテンツが使われる場所もそうです。汎用的でなければいけないということです。もう誌面に掲載されて終わり、という時代はとっくに通り過ぎていて、そこにあるデータをどう使うか、どう作るか、ということの方がはるかに重要なのです。

という感じでどこかで頼まれたときのための原稿の元にしときます。

2009年7月16日木曜日

今日はシステムレビューの日

本日はお客さんにご来社いただいて、セミナールームでレビュー。
本番運用まではまだ先だが、締めないといけない日。

前日お電話をいただきちょっぴり心配そうな雰囲気。
確かにJIRAにタスクがまだ残っている。ううう。。。
「大丈夫なん?」
「大丈夫だと思います。。。」
「思いますはあかんな。大丈夫って言ってくれ」
「じゃあ大丈夫ですっ」
そんなこんなで、とりあえずタスク完了し当日なのでした。

8時間に亘るレビュー+開発をその場でこなし、
「ここおかしいんやけど」「おーすごいねえ・・・」「えっこんなこともできるの?」
「もうちょっと」「OK!」
そんな言葉が飛び交いながら、前日からの徹夜明けでひとりふたり脱落しかけるなか、
なんとか目標値までたどり着き、お客さんも大変満足されてひとまず帰られました。

あーでもない、こーでもないという話をするより、さっさとやった方が早いんですよね。

で、ちょっと今回の内容ではなくやり方について紹介します。

1.プロトタイプでレビュー
これを2回ほど。
うちの案件なので、Grailsで作ってます。重要度が高くない部分はScaffoldのままだったりします。見た目と流れ確認を優先です。ドメインなんて後で変わるので。

2.要望、タスク、バグなどをJIRAを使ってプロジェクトを管理
よくある言った言わない問題による信頼関係の崩壊、依頼者、開発者のやりとりの不透明感、それらを一切払拭してくれる便利なツール「JIRA」。最近はもうこれなしではプロジェクトができないんじゃないかと。お客さんにも評判良いです。さぼっても、徹夜して頑張っても一目瞭然なのです。

3.あとはひたすら作業、チェック、クローズの繰り返し
タスクが増えたらゲンナリだけど、減ると終わりが見えてくる、そういうイメージが関係者全員で共有できるのはよいです。できるだけ一気に勢いつけてやらないといけないです。
この辺の反省点は、サーバへのアップをもっとこまめにした方がよかった。
こちらのタスクは消化されているが、お客さんから見ると、「まだ直ってへん・・・」となってしまいます。そういうところで、「こっちはあっせってんのに、なんでのんびりやってんのや」と思うお客さんもいるかもしれません。今回のお客さんはそういう人たちではないのでいいのですが、ヤキモキさせたと思います。そういうところから「温度差」が発生するのではないかと思います。いくら良いツールを使っても、結局は人対人。そこは忘れてはいけないのです。

4.リリース時点での目標値を決める
リリースまでにどの状態に持って行くか、これは最初の段階である程度あったとしても、現実的に見て、この機能は絶対いる、この機能は次のリリースにまわす、など、お客さんと調整します。

5.リリースに向けて最後の調整
今ココです。

6.次のバージョンのための計画、追加実装・修正、サーバーアップ、、、と続くのでした。
こう作ってくれと言われたから作りました、ここまでに作ってくれと言われたから作りました、はダメなんですよね。
これは責任転嫁の声であって、こういったからこう作った、だからおかしくなった、ここまでに作ってくれといったから間に合わせで作った、自分のせいじゃない、自分の責任範囲外ですと言っています。
いやいや使う人のこと考えてください。お客さんが思うよりももっと良い物をその日までに作る、それが作り手のプライドであり、その前提で仕事しないと、やらされ感たっぷりでイヤになる。自分の意見があるなら通す努力をする、でも拒まれたりもする、そして議論もする、良い意見は取り入れる、ヤバイと思ったら方向転換する、そこで自分を諦めたらもう終わりです。やっている間、話している間に、「ああ、ここがお客さんの気持ちいいところだったんだ」と気付くところがあります。それに気がつければあとはそこを外さないように頑張るのみ。うちのような小さな会社が生き残りをかける、小さな会社で他の企業とわたりあうには、プライドを持って仕事をする、いい物を提供する、そして、またお願いしたいと言ってもらえる状況を作る、それしかないと思います。安心や保険のかけられたネームバリューがモノ作りという状況下において期待通り機能するかというところは今後ますます開発手法も変わってくるでしょうから、じっくり見てジャッジしていただきたいと思います。
納品して、はい終わりじゃないのです。作った人が誰とかは使う人には関係ないんですが、それが普通にそこに存在する。そういう光景ってものすごく好きです。そういう光景を作ってる最中に思い描きつらさを和らげる。それが動き、使われ続ける、それはある意味作った会社、作った人が受け入れられるわけです。それで飯が食えるならそれは素晴らしいことだなと思います。

ある意味アジャイル的な工程でやっているわけですが、決まり事がないだけに、気がつくとシステムの本筋からすごく外れたところにいたりして、暗中模索なところにはいってしまったりと大変なときもありますが、モノを作っていくという行為を一番シンプルに考えたときの理にかなっていると思います。

それから、「Powered By Grails」を入れる許可をいただきました。
社内アプリ開発が多いうちにとって、やっと一般の目にも触れられるものが出来そうです。
Grails1.1.1になって、プラグインを使ったチーム開発も、さらに使いやすくなってきました。
今日もさっくり山本さんがicu4jを使って携帯サイト用にカタカナを半角にするプラグインを作ってくれたのでちゃっかりインストール。おー、さすが。。。
他にも公式版、NC版の10個ぐらいのプラグインで構成されています。
ここへ来てやっと加速気味だ。いいことだねえ。

2009年7月15日水曜日

Confluence Plugin (Grails)を試す

GrailsのGSPの中にConfluenceのページを取り込んでくるプラグインです。
ドキュメントは、ここ

適当にCreate-appしてGSPにタグを差し込んで社内のConfluenceのページを出してみました。

2009年7月14日火曜日

yahooPipesで複数RSSを統合したフィードを作る

まんずYahooのUSのアカウントを取得するのにひと苦労。
知ってる人は知っている、知らない人は知らない。
そして私は知らなかった。。。
アカウントを作るにあたって、Guamに移住。そしてpostalCodeを入れる。
それだけです。

JGGUGでkskyさんがやっていたのをそのままコピーさせていただきました。
流行に乗り遅れている感がありますが、Pipes面白かったです。

ちなみGoogleガジェット選びは大変です。
なんせリストのロードが遅い。
とりあえず良いのが見つかったので設定。

デジパブに行ってきた

いかんいかん、つい他ごとに頭がいっちゃって。。。

7月9〜12日に東京国際展示場(ビッグサイト)で開催されていた「国際ブックフェア+デジタルパブリッシングフェア(略してデジパブ)」に行って参りました。


2回ほど?出展社として出したこともある展示会です。
なかなか展示会費用もかかるので、PAGEは外せないので、デジパブは今回は見送り。

学参系の動向調査がメインです。

金曜の夜に出発し、東名で4時間ぐらい?。横浜志賀家にお世話になり、朝食までいただいて会場へ。
(出発した当日は、私、お腹か胃の調子を崩して、朝からずっとくたばってました。正直終わったかと思いました・・・が翌日はなんとか。皆さん拾い食いは止めましょう)

どれか一つにマルを付けてくれと言われたのです。




写植屋という業種カテゴリは昔あったんだろうか・・・ま、いいや。

朝イチは、さすがにまだ空いてましたが、時間がたつにつれ、図書部門は、
歩くのもちょっと大変なぐらいでした。
<before>


<after>


全部紹介できないですが、あまり基準もなくピックアップします。

PDFを活用した「パラパラめくりではない」デジタルカタログ





一見、よくあるPDFをJPEG化してFLASHでパラパラ見せるやつかなと。
説明を聞いてみると、情報を吸い上げて検索キーワードみたいなのを抜いて、
その誌面上のインデックスを作って、さらにそこにいろんな付加機能が付いている。
うーん、なるほど。山本さんが言ってたな、できるって。またやられちゃったねえ。
あんまりデータベースとか考えずにやるこういう発想、個人的には好きですね。

裏の組版エンジンはInDesignだそうです


凸版さんのブースで、辞書作りのための入稿用インターフェースを紹介してました。
実際本が出来てました。でもやっぱり製品というよりは事例であって、このためにスクラッチで作り込んでるそうです。お客さんの要望にマッチしてるんだろうなと、まとまった画面でした。ルビとかはタグを埋めてもらう了承を得ているらしく、テキストエリアの隣にHTMLのビューが付いてました。現実的でよかったです。



文書を構造化する難問にチャレンジしている企業があった!!



「いやー、これ大変っすよね」、やりたかったんだよなーと見てました。こうすればできるっていう理論はあっても、ここまでよくやったなと言う感じの出来具合。構造化するって、こういうことなんですよね。今はもっとユーザーフレンドリーなインターフェースも沢山あるから、技術的にはかなり現実的。あとは、あんまり複雑怪奇になって、結局誰も分からなくならないようにしないと、本末転倒になってしまいますよね。しかし、構造化できる文書であれば、マッチしますね。組版エンジンはFormatterっていってたかな。確かに向いてます。

InDesignで数式を組む


竹田印刷さんの出展製品です。
ワードで作った数式入り文書をTeX経由で、InDesignに、編集可能な状態で持って行くものでした。InDesignには数式機能が当然のようにデフォルトではないので、InDesignで数式入りの組版をする場合、こういう選択肢もある、ということでした。
InDesignが判断組っぽく、カタカタと組版するところも見ていると、シンプルさんのWAVEを彷彿させる感じです。これもよくやったよなあと感心しました。
課題は、InDesignで編集できるにせよ、Wordからの完全原稿入稿でないと力を発揮しにくいところです。完全自動組なら可能性として有りです。
写真OKだということでぱちり。


AdobeScene7


えーと、、、うーんと、、、Adobeさんのサービス?で、印刷で使った高解像度の画像をWEBその他に適したデータで返してくれるらしいです。
見せてもらったのは、例えば商品カタログであるメーカーの靴があったとして、それの色をブラウザ経由というかFlash経由で変更できるとか、下の写真のように、パーツを組み合わせて、色柄とかコーディネイトできるとか、、、このサービスを使うと、そういうインターフェースを使うことができるらしいです。海外の事例が中心でした。面白そうなんだけど、こういうのをスイスイ作れて、スイスイ使える方法が出てくるまで待ちだなと。でも、印刷物で使った高解像度の写真をうまく使おうよ、というコンセプトならそれはそれで良い発想だなと思いました。


ノリが良い神戸の粋な会社(と見た)


神戸の印刷会社さんで、Metaworksを使ってるそうなので、
ユーザの視点から見た感想を聞いてみたりしました。
やっぱりアプリの善し悪しは別として、実際案件で使おうと思うと、
どう使うかねえ、もしくはどう使えるかねえ、ということを考えないといけない。
当然のことを当然のようにやっている企業さんですが、
アプリを買えばなんとかなると思っている企業も沢山あって、
使わずにほかってあるのもよく聞きます。
そういう「どう使うか」という部分まで、しっかりコーディネイトできるような
企業になりたいなと、ことある度に思うのです。
世の中には良い製品、良いアイディアが沢山あるのに、
うまーく使えていない。そう思うのは僕だけなのかしら。

ちなみにこの腰巻きは、全社員に以前配られたもので、ここぞとばかり持ってきたそうです。
なんか、「っらっしゃいっ!!」って感じで、元気が伝わってきていいですよね。

InDesignでラウンド罫囲みプラグイン


京都の会社さんでした。InDesignで結構ネックになるのがラウンド罫囲み。
スクリプトを使えばなんとかなりそうですが、それをプラグインにして提供しています。

説明される方の話口調が、「ああ、この人はずっとこの世界でやってきたんだろうな、いろんな事にチャレンジして形にしてきたんだろうな」と感じさせ、敬意を持って拝聴しました。
「できるだろう」から「やってみよう」、そして「やり遂げる」。周りからは分からないと思いますが、雲を掴むような意外と大変な作業なんですよ。

モリサワさんを覗く


山本さんの各ブース立ち寄り時間は非常に長いので、ふらっとひとり旅に。
お、学参って書いてある、ああ、モリサワさんだ。。。
MC-B2の導入結構多いでしょ、と質問すると「かなり」と。
学参ももうほんとうに大改訂が近づいていて、準備しておかないとやれるところがなくなるんですよね。我々もまだ見ぬ世界ですが、大変なことになるんだろうなと不安と期待で過ごしてます。それまではなんとか頑張ろうと。今のうちに仕込めるものは仕込んどけと。
とと、あ、やっぱりNasse置いてるんですね。。。


塾などの教室でプロジェクタと合わせて使うデジタルな黒板


「天気予報」なんかで使われているアレとよく似てます。
しかし、先生方コレを使い切るのか?という素朴な疑問。
使えてる姿はカッコイイんだけど、なんか勉強を教える前に、
また覚える事増えちゃってみたいな意見が出てきそうな。
しかし、コンテンツのデジタル化が図れればこういうところでも使えるんだよなと。
コンテンツとしては供給もしやすくなるし、受けもしやすいのは確か。


下は日本地図をネタからひっぱてきてその上に何か書いているところ。

今回何が一番印象に残ったか3人でアンケート調査したところ、↑が一番でした。
なんか夢がある。多分そこです。

おまけ:ガンダム見てきました!


だって、会場からすぐなんだもの。。。
歩いて会場に入っていくと、期待をじらすかのようにまずは後ろ姿がちらり。

そこで、おーっとなるわけです。
横向きから見て、前面を見る。あーっ、でけー、、、ぽかーんですわ。



しかーし、限定本とか限定プラモとか、2時間待ちの長蛇ですよ。さすがに帰りました。
帰り際、BGMが消えたと思ったら、プシューっと蒸気がガンダムから。
クビを左右にゆっくりと振り、そして最後には上向きですよ、
さすがに観客から「おーっ」と歓声があがったのでした。
クビまで動くから、全体的に動き出すのもそう遠くないですね。きっと。

最後に・・・
息子に小学館の図鑑NEOシリーズ「宇宙」と「昆虫」を買って帰りました。
なんと20%引きなのです!!

個人的には「宇宙」の方が好きなんですが、6歳坊主には「昆虫」がかなり興味があるらしく、
重たい本を寝床に持って行って、一生懸命見てるんです。


「本作り」に携わる企業として、こういう光景をいつも思い出してやっていかないといけないなと、もう寝るよ、と言いながら思ったのでした。

2009年7月6日月曜日

写研をDTPにコンバート

うーん、GoogleSites、クロールしないのかな。
地道に上げるしかないのかしら。

仕方ないので、ここでも紹介。
写研データをDTPデータにする

SlideShareにもあげてます。(が、フォントがない、、、)
ここです。
※SlideShareを試したかっただけです。

そのうちPDFにしておいておこう。

2009年6月30日火曜日

夢プロジェクト2009 参加してきました

「夢プロジェクト」というのは、3年目になるイベントですが、
その実態をあまり知られていないとされているIT業界の中小企業の事業内容や、インターンシップの受け入れ内容などを説明し、学生たちとの接点を作る試みです。
私たちも中部IT協同組合の組合員として参加出展しました。



山本によるWEBアプリケーション開発とは、そして、Grailsのライブコーディングを交えてお話しました。


Scafflodで出てきたViewを見て、「スゲー…」という声をいくつか聞くことができました。
それを見ているとやっぱり言語は何であれ、プログラミングの勉強というのは、最初には必ず「興味」というところからスタートしたはず。でも、覚えることが沢山、回り道が沢山、寄り道が沢山、という中で、最初の興味を維持していくのは、かなり難しいだろうなと思いました。
IT業界で、人がなかなか育たないという実態、何をすればいいのか(しているのか)分からない、または、やってみたけど「つらい」職業だと、そういう意見が、前段の討論会では、数値で見て取れたのですが、このあたりを改善していくためにも、「効率の良い教育」というところにも焦点をあてるべきだなと感じました。

2009年6月28日日曜日

「Springユーザ会との合同勉強会」終了~4日間出張のまとめ

6月24日Springユーザ会との合同勉強会が無事終了。



山本さんの気合いの入ったお話「Grails Spring Bean Builder」も盛況のうちに終了。
よく考えたらよくやるよなと、かなり後から感心感心。
一日前から東京に缶詰にした甲斐があったね。

会場のオラクル@青山のたたずまいに、半歩さがり、エレベータのモニター2つに、さらに半歩。会場の広さで二歩下がるぐらい。でも、終了時にはプラス一歩行けたんじゃないかな。

ところで、「Grails Spring Bean Builder」ってなんのこっちゃと。
よく分かっている人たちと、私のようににわかGrailserには?なので、ちょっぴり。
多分、栄養たっぷりのこの土に種を蒔いておけば、春には豆が出てくるから、後は、ちゃんと水をあげて、陽に当てて、精魂込めて育ててあげればいいんだよ、と。
お?適当に書いたつもりが5%ぐらいは合ってる気がする。
残り95%については、資料がアップされているはずなので、そちらをご覧下さい。

山本さん的には、GAEを本格的に進めるなら、もうちょっと、今回の周辺をしっかりと探ってからにしたいと言ってました。

ユーザグループというと、巷には沢山ありますが、それぞれの体質というかが当然のようにありまして、なかなか合同勉強会というのは、できるところとできないところがあります。
SpringとGrailsについては、似たものというわけではく、やってることが違うだけで、考え方は同じなので比較的すんなり行くわけですね。

Springの方の話を聞いていて、Grailsをやっていると、本当に知らないうちに、実はGrailsという仕組み自体がすごいことをしてくれてるんだなあと。
だって、Springのスの字も知らない人が、Springの機能を知らずに使っているわけですよね。
で、Grailsの良いところは、「はっ!!」と、例えば僕が今回のように「Springってそういうことなんだ…」と思うと、そっちにもいける。まさに良いとこ取り(By山田さん)
最初は良いと思います、そんな難しいところまで知らなくても。それを知らないとモグリGrailsだと言うことも無いんですよね。そりゃ知ってれば知ったことに超したことはないけど、必要なとき、興味が湧いた時に進めばいいよ、それに、そんなに回り道してたら何年かかるか分かんないよ、と言われている気がします。
ということに思いを馳せる勉強会でした。すみません、技術的でなくて。

東京、熊本と出張続きだったわけですが、
お客さんと話し、悩み、飲み、そしてお客さんのお客さんと話し、悩み、、、
と思ったら別の話が出てきたり、そして飲んでと。
決して、酒飲みではないのですが、4時間ぐらいはみっちり近況交えて、いろんな話を、濃く激論してきました。

人間なので、生きていれば、いろんな意味で浮き沈みがある。
そういうときに、必ず何か、タイミングよく、自分に何か足りないもの、忘れていたことを、思い出させたり、気付かせてくれる。
言葉以上に感じ取れるものがあるという信頼関係は、お金を出して買えないものです。
信じるという行為は、その後で何かがあったとしても、責任は「信じた自分」にあるので、そこまで腹をくくってこそ信頼関係と呼べると思います。

話をすれば、疲れもありますが、スッキリ感の方が大きい。
そういう話が出来る、信頼関係の上で突っ込んだ話ができる、そういう人たちが周りにいるというのは、社会人として幸せだし、そういう人たちは僕にとって宝ですね。

2009年6月2日火曜日

印刷・出版系のソフトウェア・ツールなどのまとめ

いろいろ書きためて行こうと思います。

* 組版ソフト
o MC-B2 株式会社モリサワ
+ WordIIn
+ MDS
o EdianWing キヤノンシステムソリューションズ株式会社
o Adobe InDesign
+ 表組みくん 株式会社コトブキ企画
o QurakXpress
o WAVE
o ELWIN
o BookStudio
* その他DTP系ツール
o

* ドロー
o Adobe Illustrator
+ 123 da! 株式会社遊文舎
+ 遊・リーフ 株式会社遊文舎
* 画像
o Adobe Photoshop
* 出力
o TrueFlow 大日本スクリーン株式会社
* 校正
o ProofCheckerPro 株式会社Too
* 自動組版システム
o WPS
o PA^n
o Orbit
o MetaWorks
* 画像管理システム
o WebNative
* WEBカタログ
o MyPageView 株式会社コトブキ企画
* テキストエディタ
o TextMate
o MIFES
* フォント
o モリサワ
o フォントワークス
o イワタ

2009年5月9日土曜日

「Grails-1.1を斬る!〜Grails-1.1からのチーム開発〜」in 品川

名古屋の再演+アルファでした。



奥の方が山本です。
20人ぐらいだったと思います。
相変わらず濃い内容だったと思われます。
あとは、そろそろらしい1.1.1を待ちたいです。

Pluginのところがやっぱり面白そうで、
開発をどう進めていくと効率よく安定させてできるのか、というところへのチャレンジが、
Plugin周りの機能強化に繋がっているとすると、是非実践したいなと。

とりあえず、1.1のGSPタグのincludeを試してみました。

GSP内で、<g:include controller="book" action="test"/>を書いて、例えば、コントローラーの中で、

class BookController {
def test = {
render(text:"テスト">
}
}

とやると、GSPの中に「テスト」という文字が反映されます。
params="パラメーター"を付けるとそれも渡せます。
カスタムでGSPタグを作ってもいいんですが、こねこね面倒で、かつその案件しか使えないタグライブラリになってしまう、とか、同じような実装を別々のコントローラーに書かないといけないとか、多分そんなとき、あるページで、部分的に、ここだけあのコントローラーの機能を使って何か出したいとかというときに便利そうです。

2009年4月30日木曜日

Grails1.1で認証機能付きアプリを一気に作る 第1回

Plugin関連が結構変わったので、もう一回、バージョン1.1のGrailsで簡単WEBアプリを作るところをまとめてみます。
何回分か分かりませんが、始めてみます。では。。。

<ここで使用するプラグイン>
・Acegiプラグインを使う。0.5.1
・Calenderプラグインを使う。1.1.1
・i18n-templatesプラグインを使う。1.1.0.1
・fckeditorプラグインを使う。0.9

<やってみたいこと>
・カレンダーから日付を入力する
・ユーザロール(Authority)とReqestMapでユーザの機能制限を付ける
・i18nを使ってプロトタイプ作りを楽にする
・byte[]を使ったファイルアップ
・hasManyとかbelongsToを使ってリレーション
・install-templatesでちょっと作業を楽にする

1.新規アプリを作る(前と一緒)
 grails create-app アプリ名

2.プラグインの置き場所を指定する
 前のバージョンでは、install-pluginをして入れてましたが、現バージョンでは、定義しておけば勝手にインストールしてくれます。ちょっと楽になりました。
 conf/BuildConfig.groovyを作成し、プラグインの格納場所を作ります。
中身のサンプルは以下。
 grails.project.plugins.dir="work_tmp/plugins"
 grails.project.work.dir="work_tmp/work"
 ※work_tmpは初回起動時に勝手に作られます。

3.application.propertiesを編集する
 #utf-8
 #Tue Apr 28 02:40:17 JST 2009
 app.version=0.1
 plugins.acegi=0.5.1 ←追加
 app.servlet.version=2.4
 plugins.i18n-templates=1.1.0.1 ←追加
 app.grails.version=1.1
plugins.fckeditor=0.9
 plugins.hibernate=1.1
 plugins.calendar=1.1.1 ←追加
 app.name=アプリケーション名

4.とりあえずRun-appしてみる。
 work_tmpディレクトリに、「3」で指定したPluginが取り込まれます。

5.acegiをセットする。
 初回起動時にAcegiPluginは、インストールされていますので、コンソールから、
 grails create-auth-domains
grails generate-manager
 を叩きます。
 そうすると、Person,Authority,RequestMapのドメインクラスや付随するcontroller、configなどが各ディレクトリに作られます。

6.ドメインクラスを作る
 grails create-domain-class item
 Item.groovyがdomainディレクトリに作られます。
 同時にtest/unitにもテスト記述用のファイルが生成されます。
 以下サンプル
class Item {

static mapping = {
id generator:"org.hibernate.id.enhanced.SequenceStyleGenerator",
params:[sequence_name:'item_id_seq',initial_value:1,increment_size:1]
}

/** 名称 */
String name
/** 備考 */
String note

/** 作成日 */
 Date dateCreated
/** 更新日 */
Date lastUpdated

static constraints = {
name(blank:false)
note(blank:true,nullable:true,maxSize:40000)
dateCreated(display:false)
lastUpdated(display:false)
}
}
point1...
 mappingのところは、入れておくと、IDが1から振られるようになります。
 HSQLとPostgreSQLでIDの挙動が違うので、ここで調整しています。

point2...
dateCreatedは、create、editではいらない(セレクタのビューが出てきて正直鬱陶しい)ので、constraitsにdisplay:falseをつけておきます。

7.コントローラーを作る前にちょっと。。。
 grails create-controller item
 とやると、
class ItemController {
def index = {}
}
というのができるんですが、いっつもscffolod = trueにしてるので、
 最初から出るようにしておきます。1コではあまり意味ないですが、
 結構さっくり作るということは、さくさくドメインクラスを作ってCRUDしたり、ということが連続しますので、先にやっておきます。
 grails install-templates
 とすると、src/templates/artifactsディレクトリが作られます。
 その中にあるController.groovyを下記のように編集します。

class ItemController {
def scaffold = true
}

この状態で、generate-controllerをすると、上記が適用されたファイルが生成されます。
同様に、Domainやcreateなども書き換えられますので、generate-allした後のよくやる作業は、ここでやっておくと便利です。

とりあえず第1回は、準備するところまで。

2009年3月30日月曜日

九州の旅〜中盤

金曜日から始まった「宮崎〜鹿児島〜宮崎〜福岡〜熊本 5日間の旅」が中盤戦にさしかかりました。

各地でお世話になりっぱなしな感じです。
母親が鹿児島の出身なのです。ちなみに父親は佐賀県。

今日は、歴史愛好家の山本さんが桜島を眺めたい、と仰るので、志布志から日南方面に行かずに、垂水へぐるっと旋回。
ちらっと見えたので、これでよしと。iPhoneでとった写真がまた読み込めない。。。

途中で腹が減っている、減ってないでもめつつも、黒豚カツ丼を平らげました。

都城で、MacBookにParallelsでWindowsXPを入れて欲しいということで、チャレンジ。

意外と日本語版4.0がくせもの。いや、VAIOがくせものなのか。
ParallelsTransporterがVAIOに入らず苦戦。
Mac側も英語版の古いバージョンに落として、Windows側もTranporterも古いビルドを拾ってきて出来た。
英語版から4.0にアップグレードするときに、Windowsの認証で、インターネットに繋がってくれないので、ライセンス認証を電話でやったんだけど、酔っぱらってると、番号を間違えるらしい。
朝起きてもう一回やったら、お姉さんがやさしく48桁?の番号を教えてくれました。
おっかしいなー。まいいや。
なんだかんだで完了。
そして今福岡です。
明日は大事な打ち合わせなので、そろそろ寝ます。

2009年3月20日金曜日

第0.9回 Grails勉強会inNagoya「もやっこでいこみゃ~か!?」無事終了〜


当社セミナールームで、念願のGrails勉強会が終了しました。
全部で16人だったかな、直前のアナウンスにもかかわらず、まずまず。

「もやっこ」って、助け合ってやっていこみゃーという意味だったらしいです。

Grails1.1についての話がメインで、Grailsを触ったことがない人もいましたので、どうかな〜と思いつつも、でも今「一番熱い」部分なので、じっくりコトコト、、、

1.1での変更点、改善点とかは沢山あるんですが、やっぱりPluginのところが、現状の一般的な開発スタイルと比較すると、Grailsらしさを説明するのにちょうどよいのかな。
チーム開発について、効率の良さ、確実性、何より開発者は人なので、既製品のツールによる管理ではなく、コミュニケーションを重視したチームの結束力の強化みたいなのに繋がるんじゃないかと、期待しています。

本番当日時間ぎりぎりまで、悩みながら必死の形相で資料を作ってたのを見ていたですが、日本で山本さんしか、こういうのは話せないんでねえ、だから頑張ってねと見守ってました。

懇親会は「世界の山ちゃん」で!手羽先とりあえず10人前っ!ビールがうめぇ!
最近知り合った人とか、初めての方とか、いろいろお話できてよかったな。名古屋でもこんな風に盛り上がれるんだと、ちょっとこの先を期待できる感触を得ました。

次回は、もっと早くアナウンスしますね。4月後半の予定です。

山本さん、お疲れさんでした〜

2009年3月12日木曜日

名古屋でGrailsの勉強会します

Grails-jaに案内を流しています。

早くやりたかったのになかなか時間が決められなかったのですが、半ば強引に設定してますので、急なことになってしまいました、、、、

お近くの方は是非お越し下さい。

2009年2月17日火曜日

Grails Export プラグインを試す

ここから。

Grailsで作ったアプリのList画面で使えるExportPluginです。
上記URLの説明に従ってやってみると、下記のような感じになりました。



出力は、CSV、EXCEL、ODS、PDF、XMLになっています。
PDFは、iTextを使って組み立てていて、ソースディレクトリにあるDefaultPDFExporter.groovyをいじるとそれなりに出せそうです。

ちなみにPDFで出力したもの↓日本語×だけど、調整次第ということで。


帳票までは難しいかもしれないですが、とりあえずCSVで出力したいとか、XMLで出力したいとか往々にしてあるので、便利に使えるんではないでしょうか。