mkawa.xmldo

物作りをする人たちが最終商品の品質についてどこまで考えられるかについて

2011-08-05T01:43:00.003+09:00

ネタ的には、出版界の恥を晒してしまった書籍「アインシュタインその生涯と宇宙下」が機械翻訳だったため回収へ - GIGAZINEという記事について制作という立場から思うことを書いていたら、8月4日に発生した東海テレビのテロップ表示の放送事故、同日開催されたグラフィックコミュニケーションズ工業組合の電子書籍セミナーが本題に関わるのでまとめてみる。

まず、機械翻訳で出版したものが後で発覚して自主回収という、なんだそれ、状態の話。別に糾弾するつもりはない。
これは謝罪文によると7月1日となっていて、発行されたのは6月末頃らしい。ネットで機械翻訳の噂がというか、もうあからさまなんだけど、いろいろと盛り上がって、ここ数日前に投稿された多くの記事でそのひどさについて書かれている。

書籍を制作している自分の立場から考えても「？」が多いこの話。出版社内部で制作してんのかな。
普通だと著者（今回は翻訳者）←→編集←→制作でこねこねしながら、権限のある人が校了フラグを立てるまで、数回「校正」という工程があるはず。
その後印刷に回るわけだけど、そこでも誰かが間違いに気づいたりして印刷機を止めてもう一回その版だけ刷り直すとか、そういうあんまり効率的ではないと思われるほど、完成物に対して神経を尖らせている、そこまでやらないと自分たちの仕事は完結しない、のだとこの話を聞くまでは思っていた。

実際自分でも印刷入れした後に、「はっ！やべえ！」って気づいて印刷屋さんに青くなりながら連絡したりとかあったんだけど、そういうのもなしで、あんだけの本を刷っちゃうんだなあというのがあると、よっぽど腹が据わってるかと思えば自主回収だし、、、て考えていくと、まさか売るためのネタ作り？とか思ってしまうのだった。ま、そんなわけ無いけど、中古本が高値になってるらしいので。
んでもって、早急に修正しますってあるけど、ここまできたら時間よりも内容だと思うんだけどなあ。

著者、編集、制作、印刷という分担作業の中、データでのやりとりが普通になったことで、システマチックな制作フローが組めるようになって、右から左に流れていくようになっている。
それでも、各工程で、今回のような「校正」以前に内容についての推敲や議論がされない状況では、出版社における編集という価値が低下傾向にあって、世の中の出版不況が活字離れとか言ってたけど、それって違うよねと。根本的なところに立ち返る必要がある気がする。

で、これは出版社に対してだけじゃなくて、制作する自分たちも、「これはおかしいよね」と普通に言えるようにならないといけない。
分業で、いつのまにか制作担当者の地位は、「ただ言われたとおりにやればいい作業者」として扱われるようになっている。
内面的な意識も「自分たちは言われたとおりにやればいいだけ」「余計なことをする（言う）と怒られる」とか、そうなっている傾向が見受けられる。当然、そうでない人もいっぱいいる。
それは意識だけの話じゃなくて、行動で示さないといけないわけで、ことの顛末の記事を見ると、編集長から延期を社長に申し入れして、却下されてとにかく出版した、ということらしいけど、編集長さんだけじゃなくて、もしそこに自分たちが関わっていたら、物作りをする立場の人間として「これじゃ絶対に出してはダメです！」って言えたかどうか。。。

東海テレビの放送事故も考えられない失態なんだけど、制作スタッフが先行して作って、あとはダミーデータにしておく、ということはよくあることで、これは印刷物やWEBなどの物作りに限らず、システム開発なども一緒。作っている最中にちょっとした遊び心（今回のは度が過ぎるけど）でダミーを仕込むことがよくある。そういう「緩さ」というのが命取りになるということを制作に携わる人がよくよく理解していないといけない。話によると、番組は打ち切りかもしれないらしい。

ここだけの話じゃなく、企業組織やビジネスの中で普段は軽視されがちな制作のちょっとしたことかもしれない作業が、とんでもないところまで波及する可能性を孕んでいるということを理解できているかどうか。
やっちまったなー、って傍目で見ていていい話じゃないと思うのです。
印刷物やWEB、メディア関係の物作りという仕事における今現在のひとつの象徴である気がするのです。

DTPオペレーターもアニメーターもデザイナーもWEB屋も放送メディアの制作スタッフも給料がめちゃ安いという話を聞いたことがある。
DTPは知っていたけど、他もそうなんだと。これでは育てる環境が作れない、それが作れないということは良いものが作れるはずがない。
そういう中で、物作りの仕事することはもちろんのこと、楽しく仕事するのも大事、でもその領域をちゃんと理解できる良識を持った人材を年代に関係なく教育していくこともとても重要な仕事だと思います。
どうも日本は古来からの営業スタイルによって営業が強すぎる気がするんだよな。それは他業界は違って良いかもしれないけど、物作り、クリエイトする仕事において、価格が営業主導で決められるってのはどうなのって思う。

本日のセミナーによると、一般書（印刷）からeBookになったところで、出版社が痛手を被ることは少ない、若干良い方向へ向いていくが、その中で、「品質を保つ、アップさせるという工程の価値が高まっている」とのこと。

製版・制作会社が多いGC（グラフィックコミュニケーションズ工業組合）に対して、JAGATの小笠原さんが総括的におっしゃっていたが、今まで「印刷物を作る」ということが、データを作って印刷は別のところがやるということで、誰かの手が加わったものが商品になっていたが、電子書籍などを作れば、今自分たちが作っているものが、最終商品になる。
そこにはチャンスがいっぱいあるわけだけど、そのためには、今とは違った意識で取り組む必要があると。その商品の責任がすべて自分たちにかかってくるということ。それは、お客さんの商品だけど、それをどうやれば売れるのか、ということに本気になって向かっていけるかどうか。そういう面で意識を変えないといけないということだった。

「校正」というものが、専任の担当者がやる仕事、という理解ではいけないわけで、「これでいいのか」ということは携わる全ての人が意識をしないといけない。印刷がただ刷るだけでいい、制作もデータ流せばいい、あとは知らん、という意識が浸透してきている気がするのと、物作りが、なんだか歪んだ、ふざけた感じで、いいんじゃね、しらね、という意識が表面化してきている気がする。
そうなると、工賃作業から自分たちの価値を対価に変えることができるというせっかくのチャンスを取り逃すことになりかねない。
もっと、物作りという行為や、商品というものに対する意識を高く持たなければ、自分たちの環境などその上に成り立っているわけで、よくなるわけながない、と思う。

最初の３つが繋がったかどうか、、、

花火を見て思ったこと〜お客さんと一緒にシステムを作る試みのプチまとめ

2011-06-26T04:11:00.001+09:00

40も近くなると、忘れてしまうことも多くなる。

でも、今日の出来事はちょっと胸に刻みたい。
そして、受託開発ではない「お客さんと一緒にシステムを作る試み」の一つの区切りなので、
それをまとめておきたいので書いている。

今日は、うちのdot3（旧WPS）の導入先のお客さんが、
情報誌の誌面リニューアル、WEBサイト公開にこぎつけたので
出版記念パーティをするからおいでと声をかけていただいていた日。

サーバ移行もあったので前入り、後入りで総勢4人。

パーティは総勢80人ぐらい。
海が見える素晴らしいロケーション。

が、しかし、、、

花火を打ち上げる予定があったけれども、
午後から降り出した雨が開始早々いっそう激しくなり、
海はおろか外の景色も見えないような状況で、
これは無理だなと。。。

5年ぐらいのお付き合いの会社さんで、
1年ぐらい前、このリニューアルにかけて当時使っていたWPSを廃止して、
自社開発でやろうかなと。でもまだ迷っているので、ちょっと何ができるか
相談したいんだが、、、というお話をいただいた。

WPSもその頃には、安定期を超え、
次のPA^N（WPSを柔軟な仕組みに切り替えたもの）へと
開発フェーズも移り、さらに練り直しをはかろうかというところだった。

その間、僕らは営業というものが
社内で確立していないことを言い訳にしてしまっているが、
既存のお客さんへのレビューなどほとんどしてこなかった。

だから、新しいものを見せたとき、
「それだよ！なんで教えてくれなかったんだ！」
というような、お叱りでもあり感嘆でもある言葉をいただいた。

しかし、僕たちの見せる技術は、海外では当たり前であっても、
日本国内ではかなり先駆的な技術。

大手であれば、必ずNoと言われる。
そんな知らない技術は、採用できない、
まずは外部設計と、詳細設計がないと受け入れられない、などなど。

技術なんて日々変わっていくものだ。
余計な時間をかけるだけ、日本はどんどん遅れていく。

Web入稿、自動組版やWEBサイト連携という仕組みなので、
入稿したものが出ればいいし、その他付随する機能は、
どんどん付けて、いらなければ外せばいい。
そもそも、お客さんが思う範囲、言われたことしか開発できないなら、
その大元のアイディアはお客さんにあるわけで、
開発者ではない。ただのコードがかけるプログラマ。

お客さんが言うことを覆せとは言わないが、その先を考えて、
いいものを提供する、お客さんがどういおうがそれを説得するだけの力を持つのが、
開発者という立場じゃないだろうか。

ここで、いつも問題となるのが日本の確固たるシステム開発におけるビジネススタイル。
「最初に明確な要件定義とそれに基づく見積もりありき。」
「設計書が全部そろってから開発開始」

これだけビジネスのスピードが速く、技術の進歩も早いなかで、
最初に決めることへのリスクがどれだけ高いかというのは、
多分、開発という行為を「価値」にかえて売るのではなく、
開発した「もの」を売る商社的な人たちには分からない。

そこで、やってみたのが、
「お客さんと一緒にシステムを作る」試み。
今思えば、よく納得してくれたなと思う。

現在では、数本このようなプロジェクトが社内で走っているが、
1年前というつい最近でもまだ認知されるものではなかった。
世の中がアジャイルという手法に取り憑かれ始めた頃だったと思う。

その主な内容は、
・システムリリース、サービスインが納品ではなく、
プロジェクトの開始から月額決めた金額をいただく。
・短期間で区切って進める。
・お客さんからも開発メンバーを出してもらう。サーバ構築、プログラミングを覚えてもらう。
・要望の変更、追加は随時受け付ける。もちろんこちらからも企画を出す。
・金額の範囲内で、動かせる人員、工数が出るので、そこで出来ることを基本として優先順位を決めて動かす。
・ハードウェア、サーバ構築は、スタートアップとしては小さくしておいて、システムがベータ版になるぐらいで導入検討を行う。
・設計書は書かない。動くもので確認して、さらに進めていく。

つまり、両社で納得しながら順番に進めましょうという試み。
アウトソースというよりは、業務提携に近い。
うちからは、アーキテクト、サーバ、プログラム、サポートに関わる専門知識を持つ人間が、
それぞれの役割を、そして、お客さんも開発を投げっぱなしではなく、分からなくてもそこに加わる。

僕らが、やっていくうちに業務を理解できてくるのと同様、
お客さんも僕たちの世界を垣間見る。
そうすることで、あーそういうことか、とか、
ここは自分たちで決めないと先に進まないな、とか
意外と大変だ、これはプロの力を借りないと無理だなとか、
意外と簡単だ、これなら自分もできるなとか、
そういうことが見えてくる。

あんときああ言ったじゃないか、というのがプロジェクトが炎上するときの発火地点。
言った言わないになるのは、「最初に明確な要件定義とそれに基づく見積もりありき」に
全員が縛られるから。そこがあるから、という頭にどうしてもなってしまう。
見積もり段階で、点の技術検証はとれていても、複雑に絡み合う機能になった場合に、
その立証は、動かしてみないと実際のところできない。出来るはずがない。
それが言えない状況がシステム開発にはよくあることだと思う。

納得するというのは、お互いの気持ちを理解する、これが重要だと思う。
そうすれば、柔軟な方向転換が可能になる。

そうやって、お客さんと一緒に、
何でも言い合えるチームというのを確立することで、
開発側も今すべきこと、この先にすべきことが見えて、
意見を言うことができるようになる。

これがパートナーシップに基づいたビジネスだと思う。

といいつつも、、、

すべてが順調に行ったわけではない。
技術コンサル的な位置付けもある中で、お金をもらっている以上、
中途半端なことはできないから、今までよりもさらに
リサーチと検証を注意深く重ねなければいけないこと、
手法の柔軟さから、お客さんの方が決めかねるシーンがあったり、
最初の思惑と違うことが出てきたり、
いや、やっぱりちゃんと決めた上で動かさないといけないんじゃないかという意見が出たり、
今回はなかったけれど、人の問題や、外部要因（震災の影響とか）も入ってくれば、
柔軟でなければ、なんともならない。
プロジェクトがストップしてしまうことが、一番の痛手であって、
大抵の場合、拘りを捨てれば前に進める。

そういう中で、右往左往、試行錯誤しながらも、
無事出版され、WEBサイトも公開され、終わってはないが、
一段落したところで、振り返ってみると、
今後を占う良い事例になったんじゃないかと思う。

それが良かったかどうかは、
こういった場で、関わった人たちが一堂に介し、労をねぎらい、
次への意気込みを語り合うことで確かめられる。

ビジネスである以上、お金ももちろん大事だけれども、
それを生み出す人たちが、同じ方向を向いていないと、何も生み出せない。
そうしなければ単発の意味のないものに終わるだろう。

パーティは、来賓の方のご挨拶や、スタッフの紹介が終わったところで、
いつの間にか雨がすっかりあがっていた。

そして、予定通り（なのかな）花火が打ち上がった。

花火大会でみる花火とは違って、ここにいる人たちのためだけの花火ってのは、
感動もひとしお。

うちの人たちも、時には技術的な面、気持ち的な面で叱責を受けながらも、
夜遅くまで、土日問わずやっていたときもあっただろうし、お客さんの方も、
リニューアルっていう不安の中で、営業の人も制作の人も、
毎晩遅くなってもあきらめずにがんばっていた人たちがいっぱいる。

でも、こうやって一つの結果を出すことができたというのは、
力を合わせれば、あきらめなければ、やればできるっていう証明。
そりゃあ涙も出ます。

開発メンバーの他にもうちには制作もいるわけで、
この話は今苦しんでいる制作にもちかえってやりたいと強く思った次第。

僕たちがやっている開発や制作というのは、縁の下の力持ち的な部分が大きい。
時にその存在を忘れられることもある。

WEBサイトやアプリは華やかにレビューされるが、
そこにデータを渡す仕組みを開発することや、
リスクを考えたサーバ構築や、
コンテンツを作るという作業自体には、あまりスポットがあてられない。
いや、これは見えない世界だから仕方ない。

出版物やサイトが正常にできあがって当たり前。
当たり前を当たり前のようにやる。

それでも、ちょっと悔しかったな。
華々しいことを期待するわけじゃない。

もっと自分たちが認めてもらえるように、
それを個人ではなく、チームとして、会社として認めてもらえるようになりたい。
ここで、自己満足してる場合じゃない。
もっともっとできることがいっぱいある自分たちだからこそ、
それを発揮して、今度は自分たちのためだけの花火をあげてみたい、
と思った一日でした。

来月また行くことになりそうなので、
がんばれば道がひらけるんだという勇気をもらったこと、
この感謝の気持ちを忘れないようにしよう。

あいかわらずぐだぐだなブログだけど、
そろそろちゃんと書き始める。

ということで、4時やん。。。寝よう。。。

PDFの電子書籍アプリ化サービス「NCView」のリリースで、何が言いたかったか

2011-04-28T16:07:00.005+09:00

NCViewは、PDFがあるなら、
それパックしてアプリにしちゃおうよ、というもの。
EPUBとかとはまた別の世界。
すでにあるもの（ここでいうのはDTPの成果物であるPDF）を販売したい、
というニーズを満たすために存在する。
、、、とはオモテの顔で、
実は、「これほんとに必要なの？」という意味もあったりする。
電子書籍ってもんが、どうもこう違うんじゃないって
方向に進んでいくのを感じてしまう今日この頃。。。

うちは、ソフトウェアを開発するけど、
一過性のニーズを満たすものなんかは手を出さない。
電子書籍を開くと、びよーんってうちのロゴ出したいわけでもない。
なのになぜ、今さらViewerを開発したのか。

PDFが読めるViewerと言えば、iBooksやi文庫HDをはじめとして、
たくさんの会社が出している。
アプリとして生成するツールやサービスをやっている会社もたくさんある。
なんならXCodeでビルドしてみなよ、という本を出してる人もいる。
アプリにできる人たちは、そこにビジネスチャンスを見いだしたわけだ。

その機能はすでに成熟している。
電子書籍を「読む」という欲求を満たすにはすでに事足りる。

というか、一番シンプルに考えれば、
まず読めることであって、それ以外は実はいらない機能だったりする。
あればいいなを付け足しただけ。
しかし横並びになれば、あっちはあれがついてて、
こっちはこれがなくて、、、という話が盛り上がる。

そんなところで差別化されたくもないし、
そもそも自分たちの方向性、
いろんなデータ形式へのコンバートやコンテンツ管理
に合わせて作りたいだけで、
大抵のニーズは、分かってることであえてやってない。

作ろうと思えば作れるものであって、そんな小さな世界で競争したって
お互いに疲弊するだけだ。

ストアにしたってそうだ。
AmazonやGoogle、Appleみたいな世界規模でやっているところに勝てるわけがない。
彼らが本気出したら終わりだ。
ただ日本の小さな、言語的にも閉鎖的な世界へ本腰入れないから、
そこがチャンスだと思うなら良いかもしれない。
いずれにしろ、彼らに勝てるわけがない。

その先にやりたいことがあって、そのためのステップとしての機能ならつける。
先々をみたときに必要な機能を、ニーズとして受け取ってしまうならば、
それはどちらかというと遅い。

だから、欲しいと言われた機能をこばんだりする。
「今それ必要？」と。

例えばiPhone版もいると言われたときに、
その誌面がiPhoneでみたら見づらいなら、
ユーザは買わないと思う。

買ってもクレームを言うと思う。
だから、いらないと思うのでやらない。
お金積むからやってよ、っていわれても気持ち的にやらない。
すんごく積まれたら、あっざーす！ってやる。

でも大抵、違うんじゃないのって思ったことをやってしまったときほど
そのプロジェクトが失敗の道へ進む確率が高くなる。
だからやりたくない。
わがままに思われるかもしれないけどやらない。
これがあれば売れるんだよとか後出しするのは、大抵いらない機能。

まあ、こういうのを「とっきとき開発」という。

電子書籍をアプリにする必要があるのかを
もう一度ふらっとな気分で考えてみる。

すでにアプリにしなければならない、
という位置にいるならちょっと前の自分を召還してください。

電子書籍を出す理由
・書店で売れないから
・書店に出しても売れないから
・そもそも売れないから
・流行だから

ちょっとまってね、、、
売れないものは売れないです。
売れなかったもののアプローチを変えるなら別だけども。。。

電子書籍で売れるもの（勝手な想像）
・売れるはずがないと思い込んでたもの
・超新書
・どっかのコミュニティで盛り上がっちゃったもの
　つまり、特定の分野の人たち向け
・そもそも小さな範囲でいきたいと思ってるもの

売れないものが売れるのはたまたまです。
売れてたものがさらに売れるかもしれないけど、
その理由は従来の理由とは違うところにあると思われる。

だから電子書籍うんぬんの前に、営業的な感覚では出す理由がない。
だって売れるかどうかわからんものに販売計画などたてられない。

電子書籍なら売れるかもしれない、というのは多分幻想。

しかし、夢がある（。。。ポッ）

そして、紙がない、インクもない。
被災者の方ごめんなさい。ここではそういう話ではないので許してください。

販売を期待できる読者にも届けられない。

電子書籍、ありですね。

それから、在庫がいらない。
これが端から見て大きいと思うんだけどあんまり言われないな。
そこにどれだけコストがかかってるかしらないけど、
最初に見込み数をたてる必要がないし、
電子書籍の場合、初期投資の回収だけだから、
中長期でみればうんぬんかんぬん。
これは話がずれそうなのでやめよう。

もうひとつ。
提供者と供給される側の感覚は違う。
売れると思ったものが売れず、売れないと思ったものが売れる。
頼みの綱は、書店ではなく、買ってくれた読者。
読者様がどんだけ満足してくれるか。そこに集約される。
電子化は、間がすっとばされた分、本来在るべき姿の、
著者と読者がもっと近づけるチャンス。
今までは一冊ずつぶったぎられた販売を、
なにか連続的なもの継続的なものに変えられる可能性がある。
これも話がずれるのでこのへんで。

まあ、そういうのは期待できる。

だから、とりあえずやってみればいい。
そして、そこにいたる仕組みとか、反応とかそういうのをリサーチするための
テストマーケットだとおもってやればいい。

マーケットは常にテストマーケットであって、
正解なんて存在しない。
今存在しないマーケットをどう作るかであって、
既存マーケットへ投げ込んだって、従来の下をいくだけ。

成功するか分からんけど、それはおいておいて
とりあえずやってみる、というところを開発側として応援する。
だから、機能は最小限。
そこにこだわってちゃだめだよ、というメッセージ。
その反応を一緒にみて、この先を一緒に考えていきたいと思うのであります。

無駄な開発は、評価もされない。
どんだけ時間かかったとしても。
そんなもの作り手側としてやりたいか？
それより既存のもの・技術を利用して、少し先をみて
ユーザを引っ張る方がよっぽどイノベーション？

あなたの欲しいものは、すでにあります。
iBooksとかいろいろ。
だったらPDFにすればいいんじゃない？
いろんな会社が頑張って作ったものにのっかればいい。
DRMは、その人のメアドとかつけてさ。
そんな署名埋め込みなんてAcrobatでできるし。
決済はPayPal。多分明日からでもできるよね。
ほんとは電子書籍って、ちょっと覚えれば自分でできるぜ！すごいぜ！
っていうことが発端じゃないのかしら。

うちはコンテンツホルダーじゃない。
出版社さんたちはその点うらやましい限りだ。
なぜ、すぐにでもやらないんだろうってすごい不思議な感じ。

でもPDFにも限界がある。PDFはPDFであってそれ以上のものではない。
そうすると新しいマーケットの開拓という意味ではちょっと。。。
開拓が決められた仕様によって遮られるのでは、進歩なんかできない。

リサーチして、反応を試しながら機能をつけられる。
それによって違う世界を作り出すことができるかもしれない。

だから違うスタンスでアプリにしてみた。
作ってリリース情報を流すぐらいなので、やるなら本気。
こんなよた話するぐらいなので、さらに本気なのかもしれない。
そういうことじゃないかな。

CPubについて書いてみた

2010-12-07T19:08:00.007+09:00

現在、開発中のWikiからepub,idmlを書き出すWebシステムの紹介をする。
このエントリーをそのまま紹介のショットにしてしまおうと企んでいることは、内緒にして「CPub」について書く。っていうか前置きいいから早く書けと。

CPubとは

文章を最近よく目にするようになってきたマークダウン記法で書く機能と、その文章を各種データにコンバートする機能を提供するWebアプリケーション。JavaベースのWebアプリケーション構築プラットフォーム（オープンソースのフレームワーク）であるGrailsを使用して開発したもの。

↑この画像は、2010年11月27日開催された

「DTPの勉強部屋　第19回」のLTで紹介したもの。

Wikiの（簡単な）解説

その前に、「Wikiってナニ？」「マークダウンってウマいの？」という人のために簡単に解説する。Wikiは極めて広義なので、詳細は控える。Wikiの説明には、Wikipedia先生による解説があるが、読んでいると難しいので、Wiki自体が難しいと思われると嫌なので、ちょっとだけ解説したい。
ものを書く人にとっては、書式に慣れさえすれば、ワ●ドよりも、●太郎よりも、種々あるブログなどのCMSの標準エディタよりも愛おしくなる（はず）。
例えば、ページを作りたいときには、ページ追加という機能もあるが、下記のように、ページタイトルを「[]※カギ括弧」を付けてリンクとして書くことで、準備が整う。

↑新しいページのリンクを書いたところ。（[CPubについて]）

↑更新すると、CPubについて（add）となる。

このリンクをクリックすれば下記のように、新しいページが作られる。

このように作られたページは、先ほどのページを親とした「子ページ」として追加される。これは後からでも移動が可能で、文書を構造化しながら体系的に作成していくことができる。
代表的な記法では、行頭に「*」や、「#」を付ける（直後は半角スペース）と、リスト（箇条書き）にできたり、CPubでは「h1.」と行頭に付けると、HTMLでいうH1扱いになるという記法を採用している。HTMLの場合、<h1>〜</h1>で囲う必要があるが、マークダウンでは、行頭に付けるだけでその書式が適用されるというように、スタイルを簡略化して書くことができる。
どんな記法があるかどうかは、システムにより異なるので、実際に試して確認した方が早い。と、この辺で逃げてみる。。。

CPubからの出力

CPubは、これらの記法で書かれた文書を、現在ではとりあえず3種類のデータに出力する。※HTMLは当然のことなので省略。

bookreader
IDML
EPUB

現状でも出力出来る状態。あとは記法をどこまで実装するか、変換をどこまでするかだけ。

↑それぞれをクリックすると、そのページ以下の文書を各フォーマットに

変換してダウンロードすることができる。

bookreaderへの変換

bookreader形式は、bookreader.jsとしてGoogleCodeでソース公開されている。ライセンスはAPL2のJavaScript。
文章をブラウザで読むときに、縦スクロールではなく、画面サイズに合わせた横スクロール型にするもの。縦が横になっただけの話なのだが、PCのブラウザで読む時には、この形式はかなり読みやすさを提供してくれる。
iPadでもブラウザを通して見ることができるので、CPubでは、iOSのジェスチャーに対応するように改造したものを落とせるようにした。
書き手にとっても、擬似的なページ概念があるだけでも表現力として見たときに、素のHTMLよりはいいだろうと思う。
ダウンロードしたzipファイルを解凍すると、下記のようなファイルが展開される。

↑index.htmlをPCのブラウザで開いたところ。

↑同じファイルをiPadのSafari（GoodReader経由）で開くとこんな感じ。

IDMLへの変換

IDMLは、DTPアプリケーションのAdobeInDesignで開くことのできるデータ。DTPとはDeskTopPublishingの略で、その昔写植と呼ばれていた「版」を作る作業のこと。現在ではPC上でほぼ完結する。InDesignは、「印刷のための版」を出力ターゲットにしているDTP業界ではスタンダードなレイアウトアプリケーションだ。
InDesignの現在のバージョンはCS5で、下記にも登場するEPUB出力なども機能として持っており、ドキュメントに動きを付けたインタラクティブPDF（Adobe仕様）への出力や、Flashへの持ち込みも可能となってきており、前述のように「紙のため」だけではなくなってきているのも事実である。
CPubは、このIDML形式データ（InDesignでレイアウトをするにあたって必要なデータ一式）をダウンロードすることができる。

↑ダウンロードしたzipを展開したところ。

↑図１　book.idmlを開くと、InDesignが立ち上がる。（画面はCS5）

上の図１は、InDesignで開いた直後。ただ流れているように見えるが、マークダウン記法でかかれた「h1」や「h2」といったスタイルを、段落スタイルとして読み込んでいる。
画像も一緒にダウンロードされてくるので、インラインとして配置、リンクされている。
InDesignのワード取り込みと比較した場合に考えなければいけないのは、ワードは機能の豊富さから、自由すぎて、いろんなことができてしまうので、複雑になりがち。その複雑さはかえってInDesignでは邪魔になる。それよりも、マークダウンで書かれてスタイルとして出てきた方が後の取り回しが楽である。

↑図２　簡単にそれらしく調整してみた。

図１の状態から、段落スタイルの調整と、テキストフレーム設定で2段組みにしたりと、それぐらいしかしてないが、体裁を整えていけば出版物のクオリティに持って行ける。
ここまで行けば、InDesignを使える人ならもう説明はいらないと思う。工夫次第でなんとでもなる、という感覚を持ってもらったことだろう。
今までは、制作側の作業は、原稿データを加工するところから始まっていたが、こういうフローが確立すれば、効率化が図れるはずであるし、執筆者にも早い段階で、仕上がりイメージを出せることは良いことであるはず。なんなら執筆者がInDesignと、読み込み用のテンプレートを持っていれば、そのテンプレートにあるマスタページやスタイルを読み込んでしまえば完成、というのもありだろう。そしたら、うちいらんがな、、、ま、いいか。

EPUBへの変換

EPUBは、iBooksなどの電子書籍リーダーアプリに取り込めたりするファイルフォーマット。詳しくはWikipedia先生に聞いてみよう。
EPUBの利点は、PDFやHTMLの場合、文字の大きさなどの見た目は、執筆者側、制作者側が決める。読み手はその範囲内で文書を読む。それに対して、EPUBは、読み手側が自分が読みやすいようにレイアウトを変えることができ、制作側が決めた1行の文字数や1ページの行数などは関係なくなる。まあざっくり言えばそういうこと。
iBooksなんかでは、ページに「しおり」を付ける機能や用語をマーキングするように「ハイライト」してストックさせる機能などがある。そのコンテンツをどう読むか、どう使うかは、ユーザ次第なのだ、というところがええところやないかと思う。
CPubからダウンロードしてきた.epubファイルを、iBooksなら、iTunesの「ブック」にドラッグすれば終わり。
CPubはネットワーク上でしかみれないが、EPUBならiPadに入れて、ネットワークがないところでも見ることが出来る。
今のところ体裁とかはあんまり考えずにダウンロードさせているが、なんかいいCSSのテンプレートとかあったらどしどしお寄せください。

↑ダウンロードしたのは、book.epub。

それを展開して中身を見てみたのがbookフォルダ。

↑iPad（iBooks）に入れてみたところ。

出演：@kanemu

CPubを使った出版物（紙もWebも電子書籍もなんでも）の執筆、制作ワークフロー

従来の一般的な出版フローは、

執筆者がワードなどで原稿を書く。
編集者が内容の精査としての朱入れも含み、編集作業を行った後、何かしらのデータとして制作側に渡す。
制作側がレイアウトして、初稿を出す。
編集者を経て執筆者が確認する。

と、こんな感じのフローが繰り返されて、出版されるわけだが、いろんな人の手、作業を経ているこの状況は、昔から変わっていない。
しかも、電子書籍などが一般化しようとする中、DTPデータが出来上がってから、そこから四苦八苦しながらデータを電子化するという非効率なことが一般的に行われる。
それはそれで、悪いことじゃないかもしれないが、非効率はミスを生むし、時間をかけて結果を出したところで変更があるわけで、ただただお金にならない忙しさが増すだけである。
CPubを使った出版フローでは、下記のようなことが考えられる。

よーし、書くぞ！と、執筆者がCPubで原稿を書く。
ここ、こんな風がええんちゃいます？と編集者が朱入れをCPub上でする。
あ、そうかも…執筆者はその内容を確認する。
そろそろ、レイアウトしてみっか、となったところで、IDMLをダウンロードして、体裁を整えて見てみる。
おー、こんな感じでええんちゃう、となったら、さらにCPub上で内容について精査する。これは、形が見えたときに、さらにやりたくなる傾向があるから。
まー、時間もないし、そろそろ本格的に体裁整えましょうー、となったらもう一度IDMLを落として、スタイルを読み込んだりなんだりして完成させる。
このとき、いかに自動化してレイアウトを再現できるか、いかにDTPオペの手をかけないかが勝負。ダメではないが、制作側としてはそれを目指さないといかんと思う。
どうしてもDTPで手直ししちゃったら、CPubをメンテ。ま、やろうと思えば、InDesignからバックもできると思うけど。そこに価値を感じてくれないならやらない。
んで、EPUB出しますか、ハイ、どうぞと。

美しいですよねえ。素晴らしい。これやりたいんだな、、、なので社内では始めています。
数式とかどうすんの？とかあると思いますが、まずはやってみようという姿勢がないとなんともならんし、やろうと思えば出来る話ばっかりだけど、始められるところから始めつつ、本当にそこに必要なものは何かを、執筆者や編集者、データ制作者で議論しながら進めないと、こういうのは成功しない。よーわかっとると思いますが。
ちなみにDRM（デジタル著作権管理）とかは、僕らが考えることではないので、そちらでがんばってください。
ついでにいうと、このコンテンツに対する著作権が議論されることはよくあるが、そのデータに対する著作権は議論されないのはどういうこと？

何をしたいか

これは売り物のシステムとして考えていない。やろうと思えば誰だって、いつだってできるし、価格を付けた途端によくわからない未来への責任を負うことになるのが嫌。
だれも見えてないこの先に価格という価値観だけで進むのは両者にとって良いことはない、というのがうちの主張。
それよりも、こういうものをみんなでシェアして使いながら、制作を変えて行こうよ、というメッセージの方が強い。
今まで通りの制作なら、印刷というパイが確実に減る中、減退の一途。デジタルデータを作る我々が変えて行かなければ、だれも変えない。
むしろ著者の方がこういう取り組みに積極的じゃないかと思う。そこにニーズはあるわけで、ほっとけば、いつのまにか完全な孤立もしくは融通の利かない業界になる。
こういう気持ちに賛同してくれる人たちなら、一緒になってもっと改善していきたいと思っている。なので、そもそもCPubはオープンソースをベースに作られているので、それにならってオープンソースで公開していく。ダウロードについても、bookreader.js自体がオープンソースだからもちろん無料。IDMLとかEPUBはわがまま出そうなので、どうしようか考え中。
とりあえずやりたい人募集中
あ、PAGE2011でもやりますよ、この辺。

ということで、校正してないけど、時間なくなっちゃったので先にアップしてしまうのだ。

次は、自動組版系のdotSuriを書く。

InDesignを「連続で開く」「何かする」「上書き保存して閉じる」スクリプト覚え書き

2010-07-25T16:25:00.012+09:00

連発で何かしたいことがよくあるので、メモ。

制作現場でさくりと使いたいので、下記の例では、例外処理とか何もしてません。

とりあえず開くファイル名は、CSVで与えるとする。
フォルダを選んでその中にあるファイルとかありますが、
ゆくゆくファイル名以外の情報も与えて与えてそこだけ何かするとかにも使いたいので、
こんなプランにしてます。
※例えば、ファイル名,50-53とかでページ数を与えて、そこだけプリントするとかね。

CSVの取り込みは、配列にさくっとしてくれる「CSVData.js」を使用。

下記サンプルは、
・CSVで与えたファイルを開いて、
・「す」という文字を探して、
・文字スタイルを変更して、
・上書き保存
するだけ。。。


#include 'CSVData.js';

var csvFile = new File('data.csv');

if(csvFile.open('r')){
  var csv=csvFile.read();
}

var fileList = CSVData.parse(csv);

for (i=0;i<fileList.length;i++){
  fileObj = new File(fileList[i]);
  app.open(File(fileObj));
  app.findTextPreferences = NothingEnum.nothing;
  app.changeTextPreferences = NothingEnum.nothing;
  app.findTextPreferences.findWhat = "す";
  var myFoundItems = app.documents.item(0).findText();
  myFoundItems[0].select();
  myFoundItems[0].appliedCharacterStyle= "あか文字"

  app.activeDocument.close(2036691744,fileObj,"",true);
}

上書きしますからね。テストとかするんだったら気をつけてくださいね。
怖かったら、


app.activeDocument.close();

としときましょう。確認ダイアログが出ます。

もうちょっとはしょってみると


#include 'CSVData.js';

var csvFile = new File('data.csv');

if(csvFile.open('r')){
  var csv=csvFile.read();
}

var fileList = CSVData.parse(csv);

for (i=0;i<fileList.length;i++){
  fileObj = new File(fileList[i]);
  app.open(File(fileObj));

  //やりたいことを書く

  app.activeDocument.close(2036691744,fileObj,"",true);
  // or app.activeDocument.close();
}

※ちなみにこれCS3でやったものです。

デジパブ2010行ってきた

2010-07-11T00:45:00.002+09:00

2010年7月10日（土）デジタルパブリッシングフェアというか、ブックフェア、教育ITの併設展示会に行ってきました。

とりあえず参加希望を全員に声をかけて、増えたり減ったりしながら、最終的に8人。東名をPAGEのとき同様、レンタカーで日帰り爆走。。。と言ってもまだ若い大事なお命を預かる大切な運転手の仕事、往復約11時間安全運転で完遂したのでした。

まだまだやれるはずの37歳、二日目腰をやられました。

それはさておき…

教育ITもとっても面白かったのですが、とりあえずデジパブメインで報告します。

今年は年初から電子書籍が盛り上がってますので、予想通りというか、iPadやiPhoneが各ブースに並んでましたね。
１．iPhone/iPad向け電子書籍アプリ作成しまっせ、もしくはそういうサービスやってまっせ
２．あなたの電子書籍を配信しませんか、もしくはそういうサービスやってますよ
３．電子書籍のデータを作りますよ
４．電子書籍リーダーありますよ
と、こんなところで、はい終わりと言いたいところですが、epubというまだ漠然とした中から、
具体的な線で「電子書籍にするなら、特別なリーダーとか作らんでもブラウザでええやん」というように、HTML5とかにも確実に行ってるんだなあという方向性も見えました。
逆にFlashでというのが無かったですねえ。寂しい寂しい。昨年はまだ多かった「ぺらぺらめくるWebカタログ」が見事に消えた感じですね。（ちょっとあったけど）

ただ、まだ流行的なものが多くて、「これからは電子ですから！」みたいな業界先行型が、
地デジ対応テレビ（ちなみにうちはまだアナログ）を売りつける業界みたいでいやだなと、
しまいには３Dみたくよく分からない付加価値を押し付けるしかなくなるような始末におえない状態はいやだなと思うのでした。

しかし、電子書籍が「当たり前の存在」になりつつあるのは間違いなく、読み手の選択肢として登場する割合は非常に高い。
紙で欲しい時、端末で読みたいときというのを、どちらか、あるいはどちらも選べる、というのはユーザにとって、利便性は高い。

利便性の高さでいけば、その名の通り、Portable Document Format（PDF）ならば、リーダーさえあればどんなPCでも見ることができる。印刷物の転用であればそれで充分だという意見もある。しかし、PDFは基本的には固められたデータなので、データの更新や修正などを考えると、取り回しの効くHTMLの方がよいというのもある。今後はそれぞれの良さをユーザがどう捉えるかで柔軟に対応していく必要があって、あまりにも一方に傾くのは良くないと思う。

色んなニーズに対応するには、コンテンツの作り方、管理の仕方から見直す必要があり、なぜ海外の方がそうした動きが早いのかという点について、洋書のバーゲンセールに並んだ本を見て思うところがあった。

洋書は驚くほどシンプルであり、コンテンツそのものに時間をかけて、レイアウトや装飾の作り込みというのはそれほど時間をかけているように思えない。コンテンツという素材が前面に押し出されているという印象を受ける。それに比べて日本の出版物は、その素材を覆い隠すような施しがされているようで、無駄が多いんじゃないか、勝負するところがコンテンツ以外になっているのではないかという印象を受けた。その無駄（労力的にという意味）な部分は本のクオリティを上げているかもしれないが、その分、次へ繋がる道が狭くなっている気がするのです。今後は、力の出しどころを変えていかないとなかなかビジネスとしては難しい世界に突入するのではと思うのです。著者とユーザがネットワーク社会の力を借りてより近くなれる環境にあるわけですから、そういうことも総合してコンテンツそのものに重点を置いたビジネスが成功していくだろうと思います。

展示会というのは、そこにいかないと体験できない空気があります。業界がどう動いていくか、ユーザの視点はどこにあるのか、そういったものが見えるよい機会だと思います。そういう中で、ふと自分たちの方向性を確認するよい機会でもあります。

個人的には誌面にある画像をなぞると音（鳥の声とか）が出る図鑑とか良かったです。
確実にターゲットを絞ってそこにベストマッチさせるというのが、採算が合うベースで展開されることを期待したいです。良い物なのに大量に売れないから、採算が合わないからできないって、とっても悲しい。それを欲している人がいるんだし。ということで、介護事業部に1個置きたいなと。

「第2回テクニカルDTP勉強会」開催されました！

2010-06-30T19:47:00.003+09:00

記念すべき第1回から３ヶ月（？）…2010年6月26日「第2回テクニカルDTP勉強会」が開催されましたとさ。

この記事は、今回の内容についてというより、主催者的立場で今回の開催を振り返った内容です。技術情報については期待しないように。あしからず。

何をやるのか、タイトルさえも決めてない勉強会は珍しいかもしれないですが、決まってないからこそ、自分が勉強会に持ち込んだ期待は、実は自分への期待だということに終わった後に気付かされる。
それが、後味が良いという感触の理由かもしれない。
これは参加してみないと分からないもの。

…と、ずぼらな主催者は思うわけです。

設立当初、集まって10人ぐらいでしょう、コソコソやりましょう、という軽いノリで始まったのですが、1回目に引き続き2回目も20名を軽くオーバー！

いいですねえ、だんだん訳が分からなくなる。
先日「DTPの勉強部屋」が名古屋で開催されましたが、なんと隣の会議室では「Flex勉強会＠名古屋」が開催されておったのです。紙とWebの境目がどんどん低くなっていく気がしてなりません。そして、ここに集まった参加者は、その真ん中に位置する人たち。
面白すぎて仕方ないですね。

１．サーバ自動組版のランニングコスト算出とか
（@mkawax）
自分なので、適当にとおもったら、@iki_osuさんが書いてくれてるではないの！ありがとうございます！
http://kstation2.blog10.fc2.com/blog-entry-424.html

何が言いたかったかよくわからんですが、続く人たちがもっぱら「濃い」と思われ、Web入稿自動組版やりたいっていうけどさ〜みたいなのを柔らかくやって、口火を切ろうと思ったのです。

２．"InDesign CS5 extension + Google翻訳サービス連携デモ" ＋ Flash Builder 4
（@tomoakioshima & @tyama）
Adobe Flexを使って、CS5のエクステンションを作る方法の紹介です。
詳細は下記ブログで。
http://blog.my-notebook.net/indesign_cs5_extension.html

スクリプトをJSで書いて配布というのも別にできるんですが、エクステンションとしてInDesignのパネルに、ここまでさくっと入れられるとこういう配布ができるとベターですね。

３．opub（オレパブ）
（@nbqx69）
http://d.hatena.ne.jp/nbqx69/

解説すると、解説できません。
いや、つまり、制作の環境をひとまとめに"pub(zip)った"もの。
人はそれを「オレパブ」と呼ぶ。
DTPerにスクリプトを使って欲しい、どうやれば使ってもらえるだろう、という
スクリプトを書く人なら誰でも考えるこの壁を無かったことにしてしまうこの作品。
長野からはるばるやってきた彼には他にも色々と見せてもらいました。

紹介は下記から。
http://nbqx.jottit.com/opub

４．カネムー「スクリプト・プログラマー宣言」するの巻
（＠kanemu）
彼自身をなぞった「Adobeスクリプトしか書けなかった自分は、どのようにプログラマとしての成長を試みるべきか」といった内容。
こんな彼に、みなさん是非会うべし。
http://kanemu1117nc.blogspot.com/2010/06/dtp.html

５．FlashCatalystと戯れる
（＠hokori）
AdobeがFlashCatalystを出してきたって事で、AI→FCで作るFlashコンテンツの制作フローがどこまで出来るのか、AI上で画像を配置するときに工夫しないといけなさそうだっだりする話とか、実際使うかどうかとか、試してみた感想を話していただきました。他の参加者からも実際使ってみた感想をいただいたり、「紙」と「Web」の繋ぎが今回の目玉じゃないかと思うCS5ですが、興味を引かれるアプリですよね。Flash慣れてる人は、普通にFlashかもしれないけど。
ちょっと横道にそれますが、InDesignCS5にはインタラクティブ機能がついてて、それをもとにFlashへ持って行ける。しかし、AIにはその機能がついていなくて、書き出してからの作業となる。この辺が、Adobeとして方向性がどっちなんだろうという疑問がある。ただ、パネルなんかがFCはもろFlexで作られてるのでもしかしたら、AIも実はそっち側で統合されていくんじゃないかとか。まあ、想像は膨らむばかりです。

６．Adobe Configurator 2.0って…
（@tyama & @mkawax）
そういやこんなんあったよ、って程度の紹介です。
ツールボックスからオブジェクトを並べてボタン作ったり、スクリプト埋めたりとそうすることで、CS5のエクステンションが作れる。書き出しは、Pluginフォルダを選ぶとそこに展開される。ZXPでのパッケージ化は無理なのか、、、配布を考えるとFlashBuilderを使ってZXPを作った方が良さそうですね。

７．epub談義
（@YUJI_ID）
ちょっと時間あまったので、隣にいたYUJIさんに「EPUBの話してくださいよぉ」とおねだりし、ご本人は「つまんないですよ」と言っておられましたが、すみません、そのまとめっぷり…年の功には勝てません、、、ということで、とっても勉強になりました。
「InDesignの勉強部屋」のYUJIさんですから、やりたいことは下記。
・InDesignでレイアウト・組版する
・InDesignからEPUBを書き出す
・iPad/iPhoneなどのEPUBリーダーで読む
ご自身の著書を使って、フォント埋め込みや書き出し方など、いろいろと試しているところをお話いただきました。

中でも、誌面レイアウトとEPUBレイアウトには違いがあり、印刷物先行である場合は、どうしてもEPUBでは再現できないレイアウトがあり、テキストの流れや図の位置など、ある程度の「レイアウトの型」にはめるしかない。かといって誌面のレイアウトをくずせば、見た目のクオリティが下がる。かといってレイアウトを保持するためにEPUBじゃなくPDFにすれば…とどうどうめぐりになる。

所感では、「その本を一番読ませたい人に合う形（機能）を提供することを優先する」と考えた方が良い気がする。

これは、昨日のtyama昼食談義で、似たような話が…
〜〜〜〜
アプリケーション開発において、色んなシチュエーション、端末、ブラウザなどに合わせることを考えるよりも、一番使われるだろう年代、例えば「40歳女性にウケるアプリ」というようにターゲットを絞って作り、他は合わせられれば合わせる、という方がよい。いろんなものに合わせようとすれば、結果それは担当者の勝手な妄想によって作られたものにしかならない。まずは、ターゲットにばっちりはめて、次第にそこに自ら集まってくるユーザを狙う方がよい。
アプリ開発、システム開発において、すべてのOS、すべてのブラウザ、そしてバージョンに合わせることは、機能が豊富な程、不可能に近い。コスト的な面もそうだが、知らないうちに変わってしまうユーザの使用環境に合わせることは無理である。
〜〜〜〜

例えば、アプリケーションの解説・習得本を例に考えると、
そのアプリを使っている最中にどう使われるかを想定したものであったり、
電車とか移動中に読む場合に適したものを考えたりと、
シーンによって端末は違うと思うので、それを全部無理矢理網羅するものはできないから、順番に合わせて作っていけばよいと思うのです。

逆に言えば、そのシーンをこちらから特定（またはオススメ）することもできるかも。
喫茶店用とか、電車用とか、多分そのロケーションでその人の気分も違う。
そのロケーションだからこそ発揮できる見せ方ってのを考えると楽しくないですか。ただ字の大きさとか縦組みとか横組みとか、その手前にユーザのニーズはあるんじゃないかと、それだけなんですけど。

提供側が全部まとまってる方が制作コストがかからんから、というのは、そもそもこの電子書籍の市場では無理かと。

＜追伸＞
ワールドカップ残念でした…マジ泣きしました。
こんな自分の、明日の自分はとっても恥ずかしいと思われます。

以上
遅くなりましたが、報告でした。

みなさん次回またお会いしましょう！！

ADOBE® CREATIVE SUITE® 5 デザインセミナーツアー in 名古屋で「テクニカルDTP」を紹介

2010-05-19T19:39:00.003+09:00

2010年5月18日名古屋ミッドランドホールにて「ADOBE® CREATIVE SUITE® 5 デザインセミナーツアー in 名古屋」が開催されました。

地元企業として20分のセッション枠が用意されたので、「テクニカルDTP」を紹介させてもらいました。
CS5の発表のために集まった300名近い人たちを前にしたとき、なんてぇ安請け合いをしたもんだと反省。

CS5の話を聞きに来たのに、、、と思ってる人もいたんだろうな。。。まあしょうがないね！

当日話しきれなかった、伝えきれなかった内容を、ここに書いておこうと思います。
※当日の資料はこちら。
テクニカルDTPというと、スクリプト使ってとか、自動組版とかの話でしょ、とか言われると困るのです。
それはあくまで、そういうこともできるよね、というだけのことであって、
もっと制作という部分にスポットライトをあてるべきだ、というところなのです。
またまた長い戯言。お付き合いいただけそうな人は、付き合ってください。

テクニカルDTPについて、20分で語れるものではないですが、せっかくAdobeさんのセミナーなので、

１．どんなにソフトウェアが良くなろうとも、使う側がその価値を理解して、その価値を対価に変えないといけないよね、
２．僕ら制作側（ソフトウェアを使う側）の人たちは、その価値を理解する必要があるし、
３．対価によって得た価値を、今度は自分たちの対価に変えていかないといけないよね、
と、いうことが言いたかったんです。

そうしないと、制作は環境も良くならないし、給料も良くならない。
ソフトウェアを出すメーカーさんも買う人がいなくなれば、オープンソースにでもしない限り続けられない。
作る側、使う側が共存できる関係になければ継続はない。
素晴らしいソフトウェアを開発する人たちも、それを使ってクリエイトする人たちも、みんないなくなる。
であれば、今、この時代はなんなんだと。僕らがやっていることはなんなんだ、ただただ衰退に向かうだけのことなのか。

どれだけ「お求めやすく」なったからって、金はかかる。
Adobeさんからして、開発してバージョンアップするにも金はかかるから、その価値の対価を求めているわけで、
僕らは制作という中で、価値を高めてその対価を要求すべきである、と思う。
そういった努力をせずして、現状に甘んじるのは負け犬だなと、自分に照らして思うわけです。

印刷費の中に制作費がコミコミなる時代に慣れすぎている僕も含めた制作側の人たちは、
作ることに自己満足しすぎて、そしてやりすぎている（時間をかけすぎている）部分もある。
クリエイティブでありたいならば、価値を対価に変えるべき。変えていくべき。主張すべき。
何も間違っていないと思うのだけど、どうなんでしょう。

勘違いしてもらうと困るのは、金を出せ、といっているのではない。
限りあるお財布と、でも今後こうしていきたい、というようなやりたいことがあるのなら、
順番にやっていきましょうよと。
今は、ただ作るだけ、その場しのぎの積み重ねが、今の状態を作り出していると気付かないといけない。

制作の仕事は、直接その版元となる会社から請けることもありますが、まだまだ印刷会社からお仕事をもらうことが多いのが実情。
印刷会社に比べれば、営業の人数は圧倒的に少ない。うちなんて一人もいない。
でもそういう会社だからこそ、「制作＝物作り」を真剣に考えて生きている。
情報を伝える手段として、紙が減っていく中、ユーザー自身がその情報を得るデバイスを選択する時代に、
それを主に考えている人たちのビジネスにぶら下がって、コスト削減要求に応じる必要なんてあるのでしょうか。

営業が「ああ、そんなら他でやってもらうからいいや」「お客さんがここまでしか出せない」と言うならば、
それが、全うであると諦めるしかないのであるなら、そこに未来はないでしょう。
彼らは、その価値を対価に変えようとは何も思ってないということです。
ただただ価格競争に勝つために値下げを受け入れる。
お金を出す側、請ける側、作る側というところの変な上下関係が続くのであれば、この先、紙の世界なんて存在しないでしょう。
それは、「紙」を必要としないから、というわけではない気がします。

別に営業さんだけが悪いわけでもない。その価値を伝えられない、対価に変えられない体制、それを作り出している業界自体が悪いということになります。

オペレーターも、営業さんも、経営者も、お客さんもみんな悩んでるのに、
ポイントがずれている。
自らそうさせている、というところに全体で取り組まないといけない。

その不合理さ、矛盾を一番押しつけられるのは、誰ですか。結局、末端の制作です。
システム開発でいえば、プログラマです。

物が出来た後で、何か言おうとしても遅い。
出来てしまえば、彼らはというか自分も含めて、その苦労、こうした方がいいんじゃないか、ということは
きれいさっぱり忘れてしまいます。

作っているとき、その工程の最中（原稿作りから、DTP、校正、プログラミングなどなど）にこそ、
今の課題をクリアするためのヒント、次の時代へのヒントがいっぱいあるわけです。
だから、制作という工程を大事にしないといけない、ということなのです。

だって、確実に紙は減っていくんです。
ならば、制作の人たち、クリエイトすることが好きな人たちは、情報を提供する側のひとたち（出版社であったり、著者であったり、編集の人たちであったり）ともっとどうすべきかを一緒に考え、違う方、別の未来へ向いていってもいいと思う。
もっともっと、ものを言っていいと思う。

さてさて、みなさんどうお考えになりますか？

「テクニカルDTP」第1回勉強会　無事終了

2010-03-20T23:43:00.005+09:00

2010年3月20日ニューキャストのセミナールームで、テクニカルDTP勉強会の記念すべき第1回が開催されました。

お題を一切決めてませんので、適当に開始されたわけですが、
参加メンバーからして特に心配することもないなと思いつつも、
どうなるかしら、という一抹の不安も抱えつつ開催したのでした。

テクニカルDTPとは、tyamaさんによる命名ですが、その意味を私なりの解釈で解説すると、DTPというもの自体に写植や製版などいろんな意味が込められ、まして今はワードもDTPとして存在するわけで、そんな中、従来の情報処理的な組版というものがその中で陰を潜めている感があります。しかし、これから時代はまさにこの部分が脚光を浴びなければいけません。それこそ、テクニカルDTPという発想は、Webさえも包み込むものだと考えています。Publishのためのデータは、印刷、WEB関係なく、データ作りという点において、テクニカルな手法が必要だということを広めていきたいと思っておる次第です。（多分概ねそういうことだと）

当日は、15名＋αのメンバーが集まり、14:00〜18:00のタイムスケジュールで開催されました。

まずは、自己紹介から。
それぞれ自分が今やっていることなどしていただきまして、
だいたいどういうメンバーか把握できたところで、山本氏からスタート。

セッションテーマ１　IDML
山本氏「TwitterアカウントからIDMLでInDesignで名刺を作ってみる」
ブログはこちら

PAGE2010の頃に、ちゃちゃっと作ったやつですが、IDMLのこういう使い方もあるんだというのをデモしてもらいました。Web入稿されたデータからどうやってIDMLに落とし込むかというところで、議論がなされたのでした。

セッションテーマ２　電子書籍
YUJIさん「自分の本を電子書籍にしてみる。そしてiPhoneとかも」
まだ、実験段階ということでしたが、最近いろいろと挑戦している電子書籍（EPUB形式）とか、iPhoneアプリなどなど、現状と今後についてお話していただきました。
テクニカルDTPという分野が、一般的に言われているDTPと、WEBとを融合させるためには、絶対に必要な気がしてきたのでした。

セッションテーマ３　Script
カネムー「IllustratorのScript作成Tips〜ExtendScriptを自分はどう使って書いているか」
実際、どうやって書いてるかをとつとつと説明してくれました。スゴイ結果も、地道な作業で組み立てたコードで実現しているんですよというところがカネムーらしいお話でございました。
ブログ

セッションテーマ４　XML　GoogleAPI　翻訳
大島さん「XML＋GoogleAPIを使ったなんちゃって翻訳」
いまいろいろ一緒に動いてもらっている大島さんです。翻訳にGoogleAPIを使って、XMLを翻訳してしまいましょうという遊びネタです。遊びといっても、こういうやり方もあるんだよねと。そして、いつかそうなっていく、というのを今まで体感してきたわけですので、今はちゃんと出来なくても、これからの技術の基本になるかもしれませんね。

セッションテーマ５　InDesign　XML　多言語展開
大島さん「InDesign + XML による即効多言語展開」
多言語というと、FrameMakerがまず浮かぶわけですが、ここはひとつInDesignでということで挑戦したデモでした。次のセッションにも関わってきますが、データに自動的にタグ付けを行うという発想。そこまで出来ればFMと同等になれるわけなので、そこにInDesignを使うことで自由度が増す（んじゃないかと）。FMも人口が減ってきてそうなので、今なら、InDesignでも代用できるんじゃないの？ということでした。

セッションテーマ６　InDesign　データ解析　データベース
大島さん「DTPデータを解析しながらデータベースを作る」
このセッションは、ニューキャストネタですが、うちのカネムーとともに大島さんにもいろいろ手伝っていただいて形にすることができました。何より説明がへたくそな我々なので、お任せした次第です。
かなりの反響でその後もしばらく話題の核になりましたが、InDesignのデータを解析しながら、データベースを作っていこうというもので、既存のプロジェクトで苦戦している方々には、目から鱗的な手法です。
この辺をオープンにする太っ腹さを感じていただければ幸いです。
こういう風にでもしないと、業界の技術の底上げなんぞできません。
これが一番だとは思いませんが、いろんな技術がどしどし世に出てくることを期待しています。

第2回も4月後半か、5月にはやりたいなと思ってます。
正直ここまで反響があるとは思わなかったのですが、
下記Googleグループでも開催情報など流していく予定です。
Googleグループ「テクニカルDTP勉強会」
※ユーザになるには申請が必要です。

ということで、テクニカルDTPをどんどん広めていきましょう！

InDesignをiPhoneのStanzaで読める電子書籍にしてみる

2010-02-12T09:45:00.003+09:00

ざっくりですが、、、、

InDesignCS4で、「Degital Editions用に書き出し」というメニューからePub形式に持って行けますが、iPhoneの電子ブックリーダーのStanzaにそのまま持ってこれるかなと思いきや、エラーで持って来れず。。。

なので、とりあえずうまくいった方法を。
１．InDesignCS4→「Degital Editions用に書き出し」でとりあえずePub保存する
２．ePub形式のデータを作ってくれる「Sigil」で、１のデータを開き、Save asで保存しなおし。
３．先に「Stanza Desktop版」をインストールしておいて、それで２のデータを開く。
４．iPhoneでStanzaを開き「ライブラリ」→「共有ブック」とタップすると、「Books on 某」と出てくるので、そうすると、３で開いているデータが出てくるので、それをダウンロードする。
※InDesignから書き出したデータだとここでエラー。
５．取り込み完了すれば自分のiPhoneで見れる。

ということで、なんとなくInDesignからiPhoneで読める電子書籍にできると。

今後例えばですが、AdobeからInDesignで書き出したデータを「うまいこと」持って来れるような繋ぎのツールが出てきたりすると、すごく加速しそうだなと。リーダーとかもですが。

それとInDesignで作ったデータを電子書籍にする場合、というかePubにする場合、作るときに想定した作り、例えば、タイトル、見出し、箇条書きなど、表現しやすい、持って行きやすい作り方にしておくのは重要と感じましたね。
※ちなみに、合成フォントはブブーとなったり現時点ではしています。

「鉄腕アトム」がそうであるように、「システム」は人である

2010-01-16T13:17:00.002+09:00

手塚先生って素晴らしいなと書き終えて思った次第。。。
システム導入の検討にあたってどういうスタンスで考えるべきなのか、みたいな内容です。
長いな、相変わらず。

最初はたいした知識もなく、思わぬミスもするかもしれない
座って、見ているだけ、聞いているだけかもしれない

周りが悪者一味なら、悪いことを覚えてしまうかもしれない

しかし、一番の取り柄は、忘れろといわない限り「忘れない」こと
そして、他の人がめんどくさくてやりたくないと言う
単純で連続する作業を「文句を言わず」に、そして「間違わず」にやってくれる
100万馬力はないけれど、CPUをガンガン回して自らの極限を知らずして頑張る

時間がたつにつれ、いろんなことを知るようになり、出来るようになる
今まで数人で時間をかけてやっていたことを、一人で瞬時にやってしまう

そしていつのまにか想像を超えたパフォーマンスを出せるようになる

「鉄腕アトム」を正しく育てる自信と決意があるならば、システム導入すればいい
彼は地球を救ったが、システムは企業を救うかもしれない

現場は、会社からこう言われる
「コストを削減せよ」

それは、
　残業を減らせ
　余分な人員をピックアップしろ
　もっと生産能力を上げろ
という言葉を別に言い換えたもの
僕もトップだから、その気持ち、よく分かる

現場にも、こういう思いがある
「もっと楽したい」
僕も現場的仕事をすることもあるから、よく分かる

労使間のよくある言い分であり、両方とも正しい
利益を考えない企業はダメだし、効率化を考えない現場もダメだ

そこで、両者が同意するのは、
「システムを入れよう」
または
「システム化しよう」

「よし、じゃあそこの君、調べてくれたまえ」

いろいろ調べ、聞き、見積もりをとり、稟議書をまとめる

「やりたいことができそうなんだな、それで費用は？」

「ウン千万円です」

「費用対効果は？」

「楽になりますし、時間も短縮できそうです。」

「いや、費用対効果を聞いているんだ。どのぐらいで回収するんだ？」

ある特定の部分にしか影響を与えないソフトウェアであれば、限られた範囲で算出することはそれほど難しくないだろう

しかし、我々が相談を受けるものでいけば、それは広範囲に影響を与える
単純な自動組版システムでスタートしたものが、いつのまにか基幹システム並の扱いを受けることも少なくない

企業としては、年単位の決算で利益を出さなければいけないから、どれぐらいで償却するか、そこで利益を生み出せるかを試算する必要がある
うちみたいな小さな会社は、もとより資金繰りが命だ

ただ、うちは小さいから、やるべきときは腹をくくる
すべてはトップである僕が責任をとればいいだけだから

しかし、大きな組織は、いろんな人に与える、その責任の影響は大きい
当事者の想像以上に大きい
自分のせいで数百人単位の仲間の人生を変えてしまうかもしれない
それはみんな慎重になる

こうなってしまうと、採用、導入までの道のりは非常に長くなる
何度も何度も色んな人に説明をし、理解を促す

やがて担当者は疲れ果て、
そのうち予算申請の期限は過ぎ、
通常業務が忙しくなり、
来年に持ち越しとなる

大きくなればなるほど、そこに明確な理由付けが求められる
とにかくやっちゃえ、ということはできない世の中だ

本当にこういうことが多い
知識経験ぐらいは残るが、そこにかけられた費用を合算すると、そちらの方が問題じゃないだろうか
また、営業的に言えば「機会損失」を何度も繰り返している事になりかねない

そうなってしまう要因の根本はなんだろうかと考えてみた

それは、システムをソフトウェア、いわゆる「モノ」だと考えてしまうからではないか

「購入」した以上、その「モノ」は、購入前に約束（コミット）したことが実現することが当たり前である、という考えに基づいている

てめぇんとこみたいに小さい企業じゃねえんだよと言われても続ける

新しいシステムは「新人」であり、
　導入検討は「新しい人材獲得のための採用活動」であり、
　設計は「面接」であり、
　開発は「新しい人材を自社に適用させるための教育」であり、
　テストは「試用期間」であり、
　リリースは「正社員化」であり、
　保守は「人のケア」だ
ひっくるめて、そこにかかる費用はすべて「人に対する投資」である

新人にもいろんなタイプがあるだろう
　高卒で若く、将来に目を輝かせているような、磨けば光る人材
　大卒でしっかり勉強してきた、やる気のある人材
　転職してきた、ある程度スキル・実績を持った人材

しっかり面接して、教育しなければ、適合しない
採用したままほっといて、うまく適材適所にはまることなんてない
そしてその人のパフォーマンスがすぐに出せることなんてない

即戦力、完璧だと思った人材、変な癖を持っていて、
後になって問題になったりすることもあるかもしれない

大丈夫かなと思った人材が突然花開き、莫大な利益をもたらすかもしれない

人の採用は、投資
システムの採用も、投資

投資だから、言ってみればギャンブルと同じ
それまで培った知識と経験、勘からできるだけ高確率を狙う

ギャンブルが人任せであるのに対して違うところは、
周りの努力で変えられる可能性が高いということ
人材を上手く使うには、その人を教育し、その人と話しをし、その人を知り、お互いの信頼関係を構築する
それしかないと思う

ずっと椅子に座っていて給料がもらえるなんてことはないし、
そんなやつに給料を払いたくはない

どう使うかは周り次第

合わなければ、切るしかない
そこまでの給与返せとは言わない
面接の時の実績の話は嘘だったかもしれない
でもそれを信じてしまった会社も会社

雇って、教えて、やらせてみてからでないと分からない
雇うときは、「まぁちょっと雇ってみるか」か「よしやってみるか」というような思い切りがあると思う。それと「とにかくやっちゃえ」は同じで、保証はどこにもない。

それは企業がよく知っていること
それと同じなんだと思う

採用を促す上司が、
「こいつ、良いやつです。僕はこいつを一生懸命育てます。だからとりあえず1年間置いてやってください。どうしてもダメだったら僕をクビにしてください。」
と言ってくれたとき、
「この人について行こう」
と思う「こいつ」なら、きっとやってくれるはず

その信頼関係が築ける環境のある企業なら、人もシステムも育つ

てな感じで…

テクニカルDTPの源流

2010-01-13T01:12:00.003+09:00

この間、組版業の大先輩にお会いして、お話を聞くことができた。

自ら書く「組版を楽にするためのプログラム」を「日曜大工と同じだから」と言い切る。

全ては「自分が楽をするため」であり、「飯を食うため」

XMLだ、eBookだ、なんていうのは、遠くの方で盛り上がっている祭りで、自分たちは、お祭りの途中でのどが渇いたという人にラムネを売る、お腹が空いたという人に焼きそばを売る、そうやって「自分が飯を食うため」に組版という仕事をしている、と。

VBで書き、UIはボタン1個。

今日来た「おねえちゃん」でもボタンを押せば、30年組版をやっている人と同じ結果が出せるという。

これこそテクニカルDTPだと思う。

DTPにもテストという概念がますます必要なんじゃないかしら

2010-01-10T01:19:00.003+09:00

DTPってある意味、システム開発でいう「アジャイル」な方式で出来ていくものだという話をこの前していた。

ここはやっぱりこういう機能が欲しい＝ここはやっぱりこういう文面にしたい

これは完成物を見て出てくる意見（欲求※要件、要求ではなく）であって、僕はそのケツを決定するもの、もしくはそれをやるかどうかは、時間（割り当て可能な時間）だと思ってるんですが、この作業の積み重ねで出来ていくものとすれば、同じような感覚が必要だと考えられます。

反して、ウォーターフォールな方式でいけるかというと、DTPは無理。言うなればシステム開発も無理。
DTPにいたっては、「これ追加」「これ変更」は当たり前であって、それがあるからこそ、DTPの仕事があるわけで、それに対応しません、ということであれば、職自体必要ない。だって、それはただコンバートしただけだもんね。

「無いもの（見えないもの）」を作り出すということは、その目指す先の「有」は、だれも見たことがない。だれもそれが完璧だという姿をなんとなく想像はしていても固定的に限定的に指し示すことはできない。なんとなく自分の想像に近いところで、OKを出すしかない。

だから、DTPもシステム開発もクリエイティブな世界なんだと思うのです。

だからこそ、作り手は、お客さんの想像から、創造しなければいけない。
常にプロフェッショナルな立場からそれを作り出すという関係で成り立つものだと思うのです。
だから、色んな便利なツールとか沢山あって、誰にでもできるんかというと、そうではなく、やっぱりそれが成り立つには相当な努力をした人たち、それが好きな人たちだけが生き残っていく世界なんじゃないかと。

話逸れますが、先日美容院の年下の店長が言うとりました。
たまたま美容院関係を目指す人向けのフリーペーパーがあって、その話題の中ですが、
「美容師ってさ、結構目指してる人多いよね？専門学校とかもあって」
「いっぱいいますけど、結局なれるのはホント一部だけで、みんな対外辞めていきますね。」
「ネイルとかはやってるっぽいじゃん」
「誰でもできるようになっちゃって、どんどん値が下がっちゃって、今やっていけなくなってるみたいですよ。僕らは値段は下げないんですよ。そもそも誰でもができるものではないんですから。」

これを聞いて、ああこいつもクリエイティブな世界のプロなんだなと。そして厳しい修行に耐えて今があるんだよなと思ったわけです。

んでんで。。。話戻します。

僕らの世界に戻すと、どちらかというと完成したものにクリエイティブさを求めるのではなく、その作る過程において求められるものとなります。
だって、DTPでいけば完成したものはレイアウトされたページだし、システムでいっても、使う側からすれば、別に中身のソースコードが綺麗かどうかなんてのは関係ない。

ただ問題は、どう作られたかが重要で、ちゃんと出来ていなければいけない。
DTPで言えば、間違いがない（印刷トラブルになるような要素も含む）かどうか、
システムで言えば、ちゃんと動くかどうか、
両方ともお粗末なミスを含んでいるようではプロとは言えない。

それには、作り方が非常に重要ということで、DTPにもその品質を担保する「テスト」という概念への取り組みが必要だと思うのです。

そのテストは、
・最初の要件では、前述通り決められないので、随時変わっていくもの、足されていくものというのが前提
・プログラム的チェックが可能か、目検が必要かを振り分けをする
・テストが通るように作る
・テストして、それが通ってから初校、再校ごとに納品する
というようなことを考えています。

印刷のためのプリフライトチェックとかありますが、それも含まれます。
しかし、その内容まではチェックされません。
データなんですから、今後は、もっと内容まで掘り下がったチェック（文字、文言とか、画像、著作権とかもあるかも）が必要とされると思います。

それから、もう一つ、なんで必要かという理由になるものは、電子書籍やコンテンツの再利用など、今後「データ」としての扱いが重要になってくるということです。

なので、印刷は、その出力方式の一部でしかなく、当然その品質を保つことも重要ですが、今までのように「印刷ありき」という考え方から、徐々にシフトできるところから「データありき」という認識に変わっていくと思われます。

僕らは印刷にするところが得意だというアプローチから、その制作の仕事をいただいているわけですが、ただ出来るというわけでなく、プロフェッショナルに展開できないと意味がない、ということだと思うのです。

2010年　明けましておめでとうございます

2010-01-04T09:45:00.003+09:00

ひとまず年末ジャンボもかすっただけで終わりましたので、ちゃんと仕事しないとダメだなと、気持ちを引き締めて今年も頑張ろうと思います。

僕が景況なんぞ語ってもしょうがないので、印刷とか出版に関係するあたり、しかも自分のところに関係するあたりで、考えてみたいと思います。

まず、個人が印税35%の電子書籍を出版できる時代 - Amazon Kindleの衝撃とか、
大晦日特番「誰が電子書籍を読むのか」の閲覧メモにあるように、今までのスタイルを貫くか、見切りをつけて新しい方向へ舵をとるかは、版元さんや著者の方々の考え方によりますが、出版の流れは大きく変わっていくのはもう間違いないことなので、それを見据えて備える年になりそうです。

電子書籍やリーダーなんて必要ない、なんていう時代はとうに過ぎていて、ユーザー（読者）が、欲しい本またはコンテンツを手に入れたい「モノ」「手段」として欠かせないものになる、ということは必至であり、必然的に電子データの重要性が高まる。

コンテンツの様々な用途を目的とした作り方もさることながら、データを「保管する」という点においても、不明瞭な点は今でも多く、それがGoogleさんたちの目論見に一網打尽にされてしまう可能性を持たせてしまっていると思います。

コンテンツデータをいつでも使える状態、使いたいときに使える状態というにしておくことが必要で、そのためには、
・データはどこにあるのか？
・データの持ち主って誰なのか？
・そのデータはどんな（何で作られた）データなのか？
・そのデータはいつからいつの期間で有効なのか？
などなど

…ああ、これ濃くなるので「DTPデータの保管について」という別記事にしよう。

この辺りをちゃんと整理する必要があると思います。

今まで頑張って作っても「印刷」という工程を超えて、何年もたてば行き場を失ってゴミ同然の扱いになってしまっていたDTPデータも、その内容（コンテンツ）とともに、その作り方、保管の仕方に至るまで、それがいかに重要であるか、そういう認識が高まって欲しいものです。

昨日から新しい大河ドラマの龍馬伝が始まりましたが、印刷や出版に大きく影響を与えるGoogle、Amazon、Adobe、Appleなど、押し寄せてくるのは全部海外の企業やサービス。日本の今までの歴史、慣習にも当然良いところはあるのですが、この波は抑えようがないのではないかと真剣に思う年始であります。

では皆さま、今年もよろしくお願いいたします。

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

2009-12-29T01:51:00.002+09:00

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年は、その点をしっかりと抑えていくんだ、と結んだのでした。

その後は、忘年会！

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

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

2009-12-27T02:59:00.002+09:00

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

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

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

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

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

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

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

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

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

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

2009-12-26T01:34:00.002+09:00

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

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

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

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

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

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

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

ここからは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-17T00:21:00.003+09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2009-12-16T00:17:00.002+09:00

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

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

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

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

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

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

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

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

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

2009-12-15T02:48:00.002+09:00

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

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

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

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

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

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

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

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

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

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

NGK2009に参加してきました

2009-12-13T01:41:00.002+09:00

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

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

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

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

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

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

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

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

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

2009-12-12T00:18:00.002+09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

2009-12-10T23:54:00.002+09:00

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

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

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

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

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

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

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

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

2009-12-09T01:05:00.002+09:00

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

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

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

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

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

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

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

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

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

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

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

2009-11-24T23:32:00.002+09:00

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本体に内包されたらしいです。

以下、確認のやりとり

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

2009-11-22T14:04:00.004+09:00

先日に引き続き、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さんは、こういう人たちに支えられてるんだな。買っちゃうもんね、β版から教えてくれる人がいたら、理解しやすいし。

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

2009-11-21T15:43:00.002+09:00

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とかです。とても楽しみ。

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

2009-11-19T15:26:00.006+09:00

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

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

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

まったくもう。。。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2009-10-24T01:11:00.002+09:00

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

うちの場合は、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を比較〜価格編

2009-10-24T00:26:00.002+09:00

なんで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＝１：７：４
ということは、EdianWing1台で、InDesign7台分、MC-B2約2台分の仕事をせにゃいかん。
そして、MC-B2　1台でInDesign4台分の仕事をせにゃいかん。

計算あってますか・・・

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

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

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

2009-09-09T00:58:00.002+09:00

だいぶ前にブログでも書いた気がしますが、
ちょっと前から「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!ですよ。

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

2009-09-03T09:22:00.002+09:00

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

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

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

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

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

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

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

・結構データ更新が多い（多そう）

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

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

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

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

2009-08-03T18:03:00.004+09:00

忘れないうちに。。。

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

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

２．これで一回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項目。

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

４．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');
とすれば入れられます。

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

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

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

2009-07-27T00:25:00.002+09:00

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

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

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

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

発表者：たけうちとおるさん（遊文舎）

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

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

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

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

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

セッション２．自動組版のはじめの一歩

発表者：Psychocatさん

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

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

まとめ

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

懇親会で見た風景

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

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

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

2009-07-26T23:27:00.003+09:00

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

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

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

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

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

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

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

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

2009-07-24T00:30:00.002+09:00

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

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

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

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

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

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

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

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

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

G*4に行ってきた

2009-07-23T16:12:00.002+09:00

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

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

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

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

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

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

西尾祭り行ってきました

2009-07-22T01:22:00.002+09:00

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

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

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

さて、金魚すくい。

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

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

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

ザリガニ釣りをした

2009-07-22T00:33:00.002+09:00

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

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

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

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

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

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

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

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

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

2009-07-18T16:25:00.002+09:00

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

１．「学参」とは…

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

２．「白表紙」について

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

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

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

今、何をすべきか

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

「自動組版」、「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-07-16T02:51:00.003+09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

Confluence Plugin (Grails)を試す

2009-07-15T00:08:00.004+09:00

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

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

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

2009-07-14T17:15:00.002+09:00

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

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

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

デジパブに行ってきた

2009-07-14T00:34:00.022+09:00

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

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歳坊主には「昆虫」がかなり興味があるらしく、
重たい本を寝床に持って行って、一生懸命見てるんです。

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

写研をDTPにコンバート

2009-07-06T10:07:00.002+09:00

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

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

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

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

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

2009-06-30T11:39:00.002+09:00

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

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

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

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

2009-06-28T00:10:00.003+09:00

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

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

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

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

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

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

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

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

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

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

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

2009-06-02T20:06:00.001+09:00

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

* 組版ソフト
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 イワタ

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

2009-05-09T09:38:00.004+09:00

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

奥の方が山本です。
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タグを作ってもいいんですが、こねこね面倒で、かつその案件しか使えないタグライブラリになってしまう、とか、同じような実装を別々のコントローラーに書かないといけないとか、多分そんなとき、あるページで、部分的に、ここだけあのコントローラーの機能を使って何か出したいとかというときに便利そうです。

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

2009-04-30T16:15:00.003+09:00

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でちょっと作業を楽にする

１．新規アプリを作る（前と一緒）
　grails create-app アプリ名

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

３．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=アプリケーション名

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

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

６．ドメインクラスを作る
　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をつけておきます。

７．コントローラーを作る前にちょっと。。。
　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-03-30T00:58:00.002+09:00

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

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

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

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

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

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

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

2009-03-20T11:13:00.006+09:00

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

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

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

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

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

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

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

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

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

2009-03-12T13:43:00.002+09:00

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

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

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

Grails Export プラグインを試す

2009-02-17T15:15:00.004+09:00

ここから。

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

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

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

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

印刷業界における「データの橋渡し」という大役

2009-02-17T03:21:00.004+09:00

印刷業界におけるデータの橋渡しは、ちょっと濃い。いや、かなり濃い。
AというデータをBに配置すればいい、という訳ではなく、そこに表現という、人によって見方の違う意味付けがされるということは、極端に言うと、人の数分の解釈がある、ということになります。

・来るはずのデータと同じデータが来るとは思ってはいけない。
・予定した日にデータが来ると思ってはいけない。
・来たデータは、正確なデータだと思ってはいけない。
・ルール通りにデータが並んでいるとは思ってはいけない。

とすると、何でも柔軟に対応できる能力が必要になります。
つまり、豊かな想像力と創造力、イマジネーションとクリエイティブな心が必要とされる、
ということじゃないかと。

前にも書いたのですが、常に更新される流動的なデータを、ある時点で線を引っ張って整合性を保ったまま止めて固定的なデータにするというのはかなりの根性が必要です。すんなり行くはずがないのです。かなり強引な手法も時には使わないとなんともならない場合が多いのです。

上に挙げたことが改善されるとは思えない（お客さんのせいではなく、データの性質上という意味）、というのと、度々で違うパターンでくるので、そう来たか、それなら…と、果敢にチャレンジする場面では、豊富なアイディアと経験も必要とされますので、やっぱりこの間を取り持つ「データの橋渡し役」というのは絶対に必要だと思います。

データベースやシステムとDTPアプリケーションを繋ぐ中間のシステム製品、アプリケーション製品がありますが、何にでも柔軟に対応できる能力を持つ製品には巡り会ったことがありません。

昔は、組版するときに、データをコーディングする、もしくはコーディングを楽にするためのプログラムチックなデータの加工作業があったはずですが、そんなのDTPによる手作業でいいんじゃない、という感じに全体がなってしまったので、あまり重要視されなくなってしまいました。
ですが、様々なデータが支給される、また、様々なデータを要求される、そして作業効率化によるコスト削減、事故の軽減を言われる世の中ですから、それを解決に導いてくれるのは、製品ではなく、その中間を取り持つ「人」である、ということを再認識する必要があると思います。

印刷・出版物とXML

2009-02-12T01:50:00.002+09:00

印刷物や出版物をXMLにすることを考えたとき、
どこでつまずくかというと、DTPデータの中で、構造化されない、しにくい部分があるから。

そもそもXMLがレイアウト情報などの一過性の情報をできるだけ排除したデータ重視であることに対して、DTPはレイアウトを含んだデータでこそ意味があり、その性格が違う。

DTPデータを無理矢理構造化しても手数が増えるだけで、生産性が上がらない。
生産性の低いDTPは、コストが増加するからやってはいけない。そして無理矢理の構造化はその場限りであって意味を持たない。意味の無いことは仕事としてやってはいけない。お互いの損になる。

印刷物や出版物は構造化されない部分が多い。むしろ構造化されている方が少ない。
上記の理由からも同等に見ることはできない。

DTPのデータを何らかの形で吸い出して、保持したいのであれば、
構造化されたXMLで考えるよりも、平面的に考えて、その中で構造化できるものがあればそのように出力しておく、という方が現実的だ。

そうそうQuarkXPressServerを展示会で見たんだ

2009-02-11T00:31:00.004+09:00

×QuarkExpress→○QuarkXPress（間違えてました。。。誰か突っ込んでよ、、、）

PAGE2009でQuarkXPress Serverを見てかなり感動。
とにかくレンダリングが早い。いやバカッぱやい（日本語あってるのか？）
うーん、あれPDFだったよなあ、なんであんなに早いんだっけ？

自動組版のサーバを選ぶときは、レンダリング速度に着目する必要がありますが、とりあえず今まで見た中で一番早い気がする。
どうしても試したい。すぐ試したい。
デモではフォームで修正した結果がすぐ反映された。ボックス単位で送ってるのかな。
まさかQXタグで再構築しているとも思えないし。

手動組版というところで現場でどうなんだろうというのはまだ分かりませんが、QX3.3のユーザがまだ沢山いる中で、その資産を受け継いで自動組版システムに持って行けるものも出てくる可能性がありますね。
ただ、これを買えばOKかというと、そうではなくて、ここまで準備してくれたのなら、実運用での問題、課題を洗い出して整理すれば結構なレベルの自動組版ができそうな気がする。

QPS（QuarkPublishingSystem）は、出版向けにパッケージングされたソリューションで、昔からあったのは知っていたのですが、InDesignを除くDTPアプリケーションの中でレンダリングサーバとしての機能を充実させていたのにはちょっと驚きだった。試してみないとなんともいえないところもありますが、JavaのAPIもあるって聞いたのでとても面白そう。

やっぱり「サーバ」と謳うなら、これぐらいは必要ですよね？
届くかな、メーカー様。。。

ということで、期待高揚

DTPとXML

2009-02-10T01:48:00.002+09:00

この関係は、一度、忘れてしまった方がいいと思う。

InDesignを使って、エレメントとオブジェクトをマッピングするときぐらいにしかXMLは必要ないように思う。

現存するDTPアプリケーションにXMLを取り込みたいときには、大半はXSLTやDOM操作でそれぞれのアプリが取り込める形式のデータに変換している。これはXML以外のタグ付きテキストでも同じです。ということはXMLである必要がない。

変換するときのことを考えるとXMLの方が面倒だと思う。
閉じタグがしっかり入っているから間違いなく引っこ抜けるよね、というぐらいかなと。

それよりも、XMLであるということは、そのXMLの仕様を決めたり、実際データを作る作業が大変だと思う。だったら、簡易タグでよいです。

汎用的に使うために作ったXMLならいいんですが、まず、手作業でXMLを作るのは、なんだかわざと回りくどいことをしているように見える。

XMLの制約は、データに汎用性を持たせるための共通仕様にしよう、という目論見の中でできているのであって、DTPにしたときには、その制約は、DTP上での加工作業という段階で無意味になる。

DTPから取り出すときも同じ。
データベースに書き戻したいということは、何を、どこに書き戻したいかは、明確になっているはずなので（なっていなければ出来ませんので）、であればXMLである必要もなく、もっと適格に、明確に、簡単に取り出して、必要データだけをデータベースに渡してあげればいいんじゃないかしら。

なんだか、全部XMLを書き出して、そこから処理する、という手法は、無駄が多すぎるのでは？

だからあんまりXMLに拘らずにまずは一番大事なデータに着目して行き来させることを考えませんか？
データが何のデータか分かっていさえ取り出せれば、DTPにも取り込めるし、そのデータをXMLにするも良し、何にするのも良しなんですから。

ブラウザから数式を入稿する〜BrEdiMaをちょいと試す

2009-02-09T11:52:00.003+09:00

BrEdiMaの存在を教えてもらったのでちょいと試してみました。

出力がMathML、JSON、TeXということで、なかなか想像を拡げさせてくれる感じでよいなと。
さっそく、死んでいるはてなダイアリーに組み込んでみる。

今度、実際の入稿をイメージして原稿作ってみようと思います。

PAGE2009を終えて

2009-02-07T01:53:00.003+09:00

PAGE2009無事終わりました。そして東名を安全運転でかっ飛んで無事名古屋に帰って来ました。

たしか6回目ぐらいのPAGE（一時期はメーカーさんのブース）だった気がするのですが、今年は壮大なスケールで物事が動きそうな予感をさせてくれる展示会でした。

うちにとって展示会とは、一年の総まとめであり、ここから先を展望するにあたって重要な意味を持っています。

PAGE2009のテーマ
PAGEに来る方たちは、印刷会社、出版社、印刷関連機械・ソフトウェアメーカー、製造メーカー、商社と様々です。

とにかく今年は「何やってんの？お宅は…」というお客さんの質問に対して、前日に完成したポスターを指さして次のようなアピールをしました。

問題を共有する立場であること
・手動写植から組版を20年やっている会社であること。
・制作会社は決められた時間の中で作業の効率化を図ることがマストであって、それで利益を上げるしかない。だからこそ蓄積する、数え切れない日々の試行錯誤で得た技術やノウハウをシステムとして落とし込んで、印刷会社さん、制作会社さん、出版社さんらにご提供している。
これを言わないと、システム屋さんと間違われるからです。
システム屋と呼ばれるより、写植屋、組版屋と呼ばれた方がしっくり来るし、うれしい。

問題を一緒に解決していきましょう
・システムやアプリケーションをパッケージとして売っているのではなく、コアになる技術をもとに皆さんと一緒に問題を解決しながら良い仕組みを作っていくスタンスです。

コンサルですか？と言われることがありましたが、そんな大仰なものではなく、あくまで現場の立場でサポートします、ということです。

完成した製品は、その瞬間から過去のものになります。そこまでにあったニーズに対応したものとなります。

しかし、印刷業界で使うシステム（制作側として）は、それを使って製造するものが型に填ったものではなく、常に違う、常に変化する物である限り、今そこにある製品ではもうすでに古いものとなってしまいます。
だから、作った方は、「ほら、今まであった、あのニーズに応えられるようになりましたよ」というアピールで、
何かを探している方は、その何かが分からないので、「あーそうなんだ、、、でもこうなってないと現場じゃ使えないんだよね」となります。
だからちぐはぐなんだと思います。
「おお、これだ！これを探していたんだ！」というのは、製品でも機能でもなく、概念が通じ合えた時だと思うのです。
僕たちの現場でも日々において色々な問題が発生します。
その問題解決は、自社だけでは無理だと思うのです。であれば、もっと情報を交換できるようにしていかなければいけない、と言う思いがあります。
そのような問題も解決していける仕組みを一緒に作る、というのが僕たちのやりたいことです。

ご来場いただいた方々、本当にありがとうございました。

PAGE2009二日目　そして会社は研修生がたくさん

2009-02-06T00:03:00.003+09:00

PAGE2009二日目が終了しました。

一日目よりは入りが多かったです。
山本担当の濃いお客様が朝から目白押しで本人は目が充血してます。

今年は勢いで2コマで、なんだおい、儲かってんのかと。
いえ、写植屋ですから、無理ですと答えると、大先輩の社長よりそれじゃいかん、と窘められる。そうです、頑張りますよ。

何人もの初めてお会いする方々、よく知っている方々、普段は疎遠ですが展示会では必ず寄ってくれる方々、出展社仲間。。。
そういう人たちにお会いして、話をすることで、実はかなり勉強させてもらってます。
自分のところの宣伝をするより、お話を聞く方がよっぽどタメになる。
でもお話を聞くには、それなりの知識と経験、なにより24時間365日考えあぐね、悩み、迷っていなければ、頭に？は浮かばない。？がなければ話は聞けないし、できない。

今年のテーマは、DTP to WebApplicationとDTPアプリケーション徹底比較。
どちらも現場20年の流れからできているので、説明するには歴史を伝える必要があります。
なぜ、今そこなのか？プリントのところに偏りすぎると、データの重要性を見失う。
それを見失えば、情報化社会から取り残されるのは明らかです。

僕たちはチャレンジの連続なのでやっていることがすべて正しいとは言えません。

ただ、データの重要性を真剣に考えるという基本線からズレたことは一度もない。
地道にコツコツ、そんな20年だったなと。

製品を売っているわけではないというのを強調し、「相談所」のカフェ看板を置きました。
印刷関連の展示としては、？だと思いますが、製品が解決してくれるというのはもう存在しないと思います。製品を理解して解決する、でもない。理解した上で製品を選ぶ、というところしかない。そういう視点でみると、出展者側と来場者の微妙なすれ違いが理解できるのではないかと思います。そこを埋めてみたいと思います。

あと1日ですが、精一杯頑張ろうと思います。

展示会期間中、名古屋では研修生が大勢来ています。
引っ越ししてなかったら入れなかったですねえ。よかったよかった。

そして、研修生なブログを追加しました。
WEB系の道の希望者には、毎日のブログ更新を義務付けしています。
初心者であれ、少なくともその道を進みたいのであれば、最低限それぐらいはできないといけない。それから、聞いたこと、やったことをまとめられること、これは職に限らず重要です。
（でも本当はノートが一番なんだけど）

当然ですが人間はすぐ物事を忘れます。1ヶ月の研修期間が終わり、１，２週間もすればすっかり忘れてしまうでしょう。この先どの道を進むか分かりませんが、せっかく1ヶ月もの間、今までになかった経験をするわけですから、記録を残すことで少しでも意味のある、価値のあるものにして欲しい、という願いも込められています。

それから、自分が何かをしたいと思うことは重要です。それは何でもいいです。しかし、忘れてはいけないのは、何かをしたいという願いが叶うときは、結果的に誰かが自分に何かしてくれる、ということになります。自分の弛まぬ努力が誰かの心に響き、そして認められたときです。
人が巡り会うのは偶然かもしれませんが、出会いというのは自分の歩んできた過去から何かの縁で全て繋がっているはずです。そういう出会いを大切にしていきましょう。

WPSのサービスってSaaSだったんだ…

2009-01-29T17:45:00.002+09:00

この記事で、今更ですが、2003年ぐらいからやっているWEB入稿〜自動組版のサービス「WPS」って、SaaSモデルだったんだと。
だからASPって言う言葉がしっくりこなかったんだな。
レンダリングサーバ、ファイルサーバもシェアして導入コストを抑えましょう、というコンセプトで、なかなか上手く説明できなくて、お客さんはシングルテナントという意識、僕らはマルチテナントという意識があって、結構大変だったです。

苦労したのは、だいたいこのサービス自体が、前人未踏の世界なので、利用制限とかどうすればいいか、処理数の情報から後付の経験から積み上げて、今のサーバ、ネットワーク構成になっていきました。かなり無茶ですねえ。当時はとにかくWEB入稿と自動組版のソリューションを確立させて、もっとその先にいきたかったのでサーバや人的コストなどの内部コストも顧みずに結構投資しました。アプリは山本さんの作品なので心配なかったですが、その他の方が大変でした。でもハードもネットワーク、負荷分散、バックアップ、障害対応のセッティングなどかなり勉強させてもらったので、今となってはよい経験です。この辺りは、どんなソフトウェア、ハードで代用しようとしても穴はあるし、設置して終わりで無くて、常に進化していくものなので、職人技による完璧なセッティングが必要となる領域ですね。

今どちらかというと、SaaSは終わって、個々の会社さんにあった構成作りをすることの方が多くなってきているのが現状です。SaaSのサービスが個々の会社さんで特化し始めると自然とそうなってくるんじゃないかと。特に印刷系だと多種多様ですからね。

ということで、あけましておめでとうございます。
やっと一発目が書けた。。。

研修生と〜お疲れ様〜プレゼン大会。。。そしてここがGCR忘年会の会場です

2008-12-24T18:00:00.004+09:00

研修生のお二人が一ヶ月の研修の最後の日なので、彼らが作ったWebアプリケーションをお披露目していただきました。
そして、先日お話の中で、「今自分たちでGrailsを使ってWebアプリケーションを作ってますが、実際どこまでいけるものなんだろう」「どういうものができるんだろう」という疑問を上げてもらったので、社内で開発、運用しているWebアプリケーションなどをプレゼンすることにしました。

１．ファイル管理システム（研修生）
座学では、DreameWeaverを使って、HTMLにCSSを付加して静的なサイト構築を学習していましたが、GrailsによるWebアプリケーション開発に取り組んでもらいました。
このシステムは、画像、PDFなどのデータをアップロードし、カテゴリを付与して管理するシステムです。ユーザ認証などはまだ付いてませんが、CSSもそれなりにいじってなかなかの出来だったと思います。

２．PDFドキュメント作成・管理システム
複数ページを持つPDFをアップロードし、ページを組み合わせたり、その中に文字や画像を貼ったりしてオリジナルページを作る、というようなシステムです。

３．タウン情報誌制作支援システム
PA^nをベースに、XSLFormatterをレンダリングエンジンにしたWEB入稿、自動組版システムです。ページ割り付けが終わると、それぞれのアイテムのPDFをInDesignに引っ張ってきて、最終ページアップをするという仕組みです。名前出して良いとお客様から許可いただいているので公表すると「Milkl」です。熊本など九州地区で出版されている「Nasse」も同じ仕組みです。
InDesignで作成したデザインをシステムにパターンとして登録できるようになっています。

４．新聞紙面制作支援システム
これもPA^nベースの仕組み。EdicolorやEdianWingを自動組版エンジンとして使っていて、他システムとも連携したりと、大変細かく、そして大きなな仕組みです。

５．会報誌制作支援システム
「２」をベースに作ったもので、オンデマンド印刷に、配送先の住所、名前などはもちろんのこと、プラスアルファとしてオリジナリティ（自分で作ったページを差し込む）を加えることができる仕組みです。

６．掲示板システム（見習い君）
まだ2ヶ月ぐらいの見習い生ですが、制作の仕事をしながらちょっとずつやってます。
自分がどう使いたいかというところが分かっている分、実装は軽いけど、最低限として的を得ているかなと思いました。

７．制作物管理、制作工程管理システム
これも公表してよいはずだったので、言いますと「小川君」という名前が付いたシステムで、制作案件ごとに、そのやりとりを管理しよう、というシンプルなシステムです。無くてはならないシステムとして運用されています。

と言った具合です。

ちなみに会場は、こちらです↓

研修生は、パワポで説明用の資料を作ってました。
人に伝えるっていうのは難しい作業ですが、要点がまとまってて良かったです。
今まで作ってきたものを改めて見ると、「あと一歩だよな…」と思います。良い意味で。そういう気持ちの方が盛り上がる。でも、ちゃんと、相手に伝わるようにまとめて、再利用して売っていかないと飯が食えんからね。どうも僕らは「売る」というのが苦手だな。出来上がったモノは他では出来ないモノであることは間違いないんだけど。最終の完成品を要求されるとうまくいかないことがしばしば。使いながら拡張する手法だととてもうまくいく。これはまた明らかな事実。いつも試行錯誤です。

とにかくお疲れ様でした。

風邪引いた。。。

MacOSX(Leopard)のシェルをzshにする

2008-12-24T14:20:00.003+09:00

ターミナルで、
>bash
と打てばbashに
>zsh
ならzshになる。
でも
>echo $SHELL
すると、
zshにしたのに
/bin/bash
とかなるので、
sudo dscl . -create /Users/***** UserShell /bin/zsh
※*****はユーザ名
にすると、ユーザシェルをちゃんと変えてくれる。
ターミナルを再度開き直すと適用されているのが確認できる。

Ustream.tv〜今さら試す

2008-12-22T10:28:00.002+09:00

テストで我が家のクリスマスパーティを録画してみました。
MacBookでちょいと引き気味で、ちょっぴりだけど。
簡単だね〜〜〜

オンラインストレージ〜とりあえず無料

2008-12-21T16:09:00.002+09:00

http://www.livedrive.com/

Windowsはストレージをドライブとして見てくれるツールが準備されている。
Mac版は「ちょっと待ってね」らしい。

とりあえず登録してみた。
ファイルを選択しておけばアップし続けてくれる。今のところ通常スピードでボンボン上がってく感じ。
共有できるっぽいのでやってみようと思ったら、「500」のエラー。また今度試してみる。
ちょっと使ってみようと思う。

おばあちゃんの孫として思うこと

2008-12-11T00:54:00.003+09:00

熊本の出張から戻って、なんだかんだバタバタしつつ、帰り際になって聞いたのですが、
S君のお婆さまがお亡くなりになられたとのこと。なんと100歳の大往生だそうです。
心からご冥福をお祈りいたします。

僕のおばあちゃん（母方）は、鹿児島にいたのですが、同じように熊本に出張のときでした。
熊本からレンタカーでそのまま鹿児島に入ったのですが、もうそのときには、鹿児島、宮崎の親戚がたっくさん集まっておりました。

そんな中、玄関を上がってその光景を見たときに、すごく不思議な感じがしたのを今でもはっきり覚えています。
おばあちゃんは7人の息子、娘を持つ人で、そこに２，３人の子がいるので、いとこだけでもかなりの数になります。そしてひ孫たちもいますので、お嫁さんや、婿殿を除いたとしてもかなりの人数が一堂に会す場となってごった返していました。

人間の全体数から言ったら少ないのは当たり前ですが、おばあちゃんがいなければここに誰も存在すらしていないんだな、と思うと、偉大さとかを通り超した不思議な感じがしたのでした。

「お葬式初めてなんですよ」というS君
「おばあちゃんがそういう機会を与えてくれたんだなと思います。」と言ってました。
そうだよな、、、何かしらの人生のイベント（言葉悪いかもしれませんが）は、自分にとって何かを得る、変わる機会なので、そういうピュアな気持ち、受け入れる気持ちは大切ですね。

と、そんな彼もブログを再開。
昔のもリンク貼ってね。

研修生による課題アプリちょっと変更。でもできてますねえ。

2008-12-10T23:02:00.002+09:00

ショッピングカートとかなんとかだったんですが、変更して簡易的なデータの管理に、ファイルアップロードとか検索とか付けてみるものにしました。

2日かかりましたが、二週間ぐらい前までなんの知識もない人たちが、周りのちょっとした手伝いがあったとしてもここまではできるんだと確信できたのが、僕にとって一番の収穫。

うむ、素晴らしい。

本人たちはまだしっかりと教えられた内容を把握できていないところに不安があって、自信なさげですが、
まずは、やろうと決めて、それをちゃんと出来たことが素晴らしい！！

多分詳細は、本人たちのブログにあがると思われます。右下のNCブログからどうぞぅ。

以上

移転先事務所になんとなくいろいろ並べてみた

2008-12-10T22:58:00.002+09:00

ああ、大丈夫、広い。まだ広い。よかった。
パーテが立ったり、人が入ったりすると、狭くなる感があっても、まあ大丈夫だろう。
でも、引っ越しって高いんだなぁ。やっぱり。前の時もそうだったから覚悟してたけど。
頑張ろうね。

旅のしおりを作るサイトをちょっと調べてみる

2008-12-03T17:10:00.002+09:00

offbeatguides
かなりのコンテンツ量がある海外のサイト。
行き先、いつからいつ、どこから、などを入力していくと、
その近くの食べ物屋とか、施設の場所とかをざっと出してくれる。
そこから、いるものをチェックして自分の旅のしおりを作る。
というかガイドブックですが。
価格は、印刷したもの、PDFダウンロードで差が付いている。
10〜25$ぐらいの幅。ページ数関係ないのかな。試しに作ったら100ページぐらいになったけど。
こういう既存のコンテンツを有効活用するってステキですね。
ガイドブックを作るというところより、コンテンツをWEBサービス対応にしてくれないかしら。

MapFanの旅のしおり
またたびの旅のしおり
両方とも操作性というところでは同じ感じのようですね。

ただ、ここまでしっかり操作してユーザが作れるのか、またリピートとして使えるかどうか、というところは、まだ実験段階なのかな。リクルートとかもやってそうだし。。。

「旅行」系の話で、DB化とかパンフレットや、しおり自動作成というような案件は、たまに持ち上がったりしますが、どうも使う側のユーザ主体で考えると、もっと簡便なものでないと、いけない気がしてなりません。
入れる項目が多いんだよなあ。もっと連携すれば楽にできそうなのに。
組版は、帳票系でやってしまうと、デザイン性が引き出せないので、InDesignとかXSLFormatterとかがいいんだろうな。
だいぶ前に、旅のしおりをFOでやってた人がいた気がするけど。ものすごく近いところに。

今ならPA^nとかInDesign連携もかなり出来てきてるので、なんなく行けそうだなあ。
既存のWEBサービスとかとも連携出来たらステキだなあ。
何か案件があったら相談してみてください。考えてみますので。

自分たちのミスで起こした事故からの復旧対応で考えること

2008-12-03T02:23:00.003+09:00

言い訳できない状態で…もうくたくたデス

まず第一報からの状況把握で、「まさか、それはないでしょ」という内容のところまで確認できていなかったのが、失敗。その後の対応を遅らせたと思います。
お客さんは、なんとアナログな手法（目検）で、データの整合性をチェックしてくれていたことで、かなりその後の時間を稼げた。本当に感謝です。

人間は疲れてくると、恐ろしく思考が低下する、ということを今までの経験上よく分かっているので、まず状況把握。復旧までの段取りをよく考える。
ここでもちゃんとお客さんと途中経過でも話しをする。

トラブルになると、自社でとりあえず解決したい、怒られたくないという思いから、あとで電話しようとか思うが、心配なのはお客さんも同じ。そして、そうやって途中で話すことで、別のアイディアが出たりもする。ここで隠したりすると、もっといけないことになる。だからお互いに緊急事態を認識して、状況を正確に把握できる状態にすることが大事。そういうときは専門、プロである自分たちが引っ張っていくしかない。そこでつまずいて、お客さんに主導権を握らせてしまうと、自社のスタッフの動きが鈍くなり、復旧にも時間がかかる。

そうなってしまうと、「お客さんがそういうんですよ」とか言う人が出てくる。もうこれではダメです。かなりまずい状態なので、「私が責任をとりますので、こちらの指示に従ってください」ぐらい言えるようにならないといけない。それがプロであると思います。
こういうときに、そこが計られるものだと思います。

今回のような事態は起こさないことが最も重要ですが、起きてしまったとき、ちゃんとお客さんのことを考えて対応できるか、自らプロとして逃げずに動けるか。。。

まだ予断は許さないですが、頑張ります。

研修生なブログが公開されています

2008-12-01T19:45:00.003+09:00

11月27日から研修生が2名来ておりますので、そのブログでございます。
1ヶ月しかないですが、見ていくと、いろいろ面白いかもしれません。

http://sateliteworks.blog57.fc2.com/

http://rs.180r.com/humanite/

実は、この試みには、いろんな意味（願い）があります。

・業界の宣伝〜印刷・制作業界、その仕事がどんなものかをより多くの人に知ってもらうたい、という願い
　最近は、DTP、印刷となると、給料が安い、残業が多い…などなど、あまり良い印象はないようです。面白いのに…。

・「作っている」という感覚と、「作り出す」という感覚の違いを分かって欲しいという願い
物作りには何でも共通することだと思いますが、僕はいつもこう思っています。
作っている人とは、言われたこと、自分が知っている範囲内で「物作りをこなす」人であって、世に出している人ではない。誰かの手によって、例えば営業さんの手によって、お客さんに出されているものである。
作り出す人とは、受け取ったときから、「作り出す」工程はもう始まっていて、出来上がった物に自信を持っていて、それが営業さんの手によってお客さんに渡されたとしても、そこに自分のインパクトを出すことができる。
お客さんの目は決して節穴なんかじゃありません。結構ちょっとした気遣い、違いに敏感です。
「作っている」人は、言葉は悪いですが、「いいなり」になってしまっています。
「いわれたからそうした、言われたとおりにした」＝「いいなり」ということです。
これでは、いつまでたってもそこから抜け出せないです。そして、効率化なんぞ、空想で終わります。

「作り出す」人は、どうしているかをちょと考えてみました。。。

仕事に使うツールをまず熟知している人。ツールとはソフトウェアだけではありません。仕事に使う使わない関係なくです。他にいいツールがあれば試してみます。だからアンテナを張ることはとても重要です。

そして、自分の環境をいつも最善の状態に整備します。環境とはマシン、ソフトウェアのことだけではありません。人の気持ち、自分の気持ちも同じです。

また、自分が効率よくできると自信のある型を持っています。そして、それをいつも磨いています。そこで、何か仕事が来ると、その型にはめるのです。でも、三角形の型に、四角形は入りません。そこで、まずどうするか？
その四角形が、次の仕事、自分の型に入れるべきだと思ったら、仕事を始める前（もしくは途中でも早い段階で）に、四角形の型の作成に入ります。
それは、チャレンジです。うまくいかないかもしれない。
でも、三角形の型を持っているのに、それを破棄して四角形を作ることは、とても屈辱的です。だったら、今度は五角形にも六角形にもなるものを作って待っててやるぜと思います。

もっともいけないのは、三角形だと思ってやったら、後で四角形であることに気付くとか、なんとかなるかなと思いつつやってみたら結局だめで、最初からやり直しになる、とか。

でも、僕はめんどくさがりなので、三角形の型にはめた方が早くできるので、はみ出た一辺について、相談します。「これっていらないですよね？バランス悪くなりますもんね」と言います。運良く「ああ、いらないですね」となったら、即忘却。「いや、これいるんですよ」となったら、理由を聞いてみる。自分の辞書に入れるべきかどうかを判断しなければいけませんので。お客さんは大抵同じような要望、要求をしてきます。だから、自分が切り返せるようになるために、そういう意図はどんどん吸収します。そして、自分の型を拡張するかもしれない。これはいいこと聞いちゃったと。
お客さんが発注先に対してしてほしいことの根本に、「これやって」「了解です」で、ちゃんとしたものが出てきてほしいと願っています。そのためには、お客さんの好みを知るのも必要です。ただ、それ以上に必要なのは、「自分ならどうする」という感覚です。お客さんの好みに合わせていくようにみせかけて、実は自分が良いと思う方向（品質、速度、将来性）へ持って行く、ということです。もっと言うなら「やりやすい方向」です。

ただ手を抜くということではありません。
物作りをする過程で、お互いにリスクを少なく、良い物を仕上げるにはどうすればいいか、を真剣に考えた末のことを、きちんと分かるように説明してあげることです。これこそプロだと思います。
時間を掛けて遅くまで、休日まで使って仕上げることが最善ではない、プロではない、ということです。
いかに日常の作業を短く済ませるかを常に考えていれば自然と流れが良い方に変わっていきます。
ただし、そこで早くできた分、もっと自分の技術に磨きをかけなければいけません。
それこそがプロがプロとして生き残っていくために最も必要なことです。

・「やる気」というモチベーションは、自分で上げるしかない、ということに気付いて欲しいという願い
「うわ、これやらんといかん…」と思ってやる仕事と、「おし、これやっとこ」と思う仕事では全くやる気が違う。やる気が違うということはスピードも、理解力も違う。
あれもこれもやっとかないかん、と思ってしまうと、何にも楽しくない。そのときにはもう「やりたくないこと」になってしまっているからです。それでは仕事は続かない。
仕事でやらされていると思う、もしくはそれさえも感じずにやっているのであれば、ひとつひとつ任されたことから、自分から、「この仕事でこれを身につけよう」「次に同じことをやるときに備えて、今からやることの作業ログをとって、あとで検証して、次はあの人より早くやってやろう」というように考えれば、全部面白い仕事に変わる。

・「教える」「教えられる」ということの大切さ、大変さ、楽しさを理解して欲しいという願い
技術というのは、常に変わっていきます。
既存の技術に追加されたり、修正されたり、無くなったり、全く新しいものになったりと。
今持っている自分の技術を伝えていく、ということが組織作りに必要です。組織も人間と同じ生き物です。ただの「箱である」ということではないのです。そこにいれば雨風しのげるというものではないのです。自分たちで土台を作り、屋根を作り、時には修理したりと、していかなければなりません。そうやって築き上げていく努力を常にしてこそ、組織が成り立つわけです。

新しい人がきたら、自分の持っているものを惜しみなく教える。そして、自分はもっと上を目指す。そこで、教えるときには、どう伝えればいいのか、どうまとめておくのがいいのか、他にどんな技術があるのか、それは本当に正しいのか、ということを真剣にやらないと、企業の中で教えるという行為には当たりません。それは「できそうなことだけやってもらう」ということになると思います。僕もそうでした。でも、それではダメなんですね。そうやってれば、いつか興味が湧いて、そのうち自分から踏み込んでくれるだろうと思っていました。「覚えられないなら、まあ、最悪自分でやるか」みたいな感じだったと思います。今はっきり言えるのは、それではダメだったということです。なので、教えるなら相当の気合いで教える。教えられる方も、分からない、違うのでは？、というように、そこでも真剣勝負する。それは企業にとって命とも言える技術の継承だからです。それを中途半端にしてしまっては、何も形として残らない、と思います。

なのですが、堅苦しくこういうことをやってもダメなので、今いるスタッフがそれぞれ持っている技術をセミナー形式で、それぞれの枠を作って研修生に教える、という試みをしてみることにしました。
さてさて、どうなりますかねえ、乞うご期待。

第13.8回Grailsコードリーディング（その４）　Grails本気の入門～2時間でいけるところまでライブコーディング!?をまとめてみました

2008-11-24T19:44:00.009+09:00

でもって、この辺で「製造元の情報は表示はするけど、編集とか新規登録は一定の人間にしか触らせない」ということを実現するために、認証機能を付けてみます。

25.Acegiプラグインを入れる。
Acegiについては、第5回GCRの山本ざっくりメモを参照してください。
当日は、ver.0.3でやりました。
・Acegiのインストール


$ grails install-plugin /ダウンロードしたディレクトリ/grails-acegi-0.3.zip

・下記二つ実行


$ grails create-auth-domains
$ grails generate-manager

そうすると、grails-appの中に、いろいろ出来てきます。
でも今回は一切触りません。あるユーザ権限を持つユーザのみが？？を操作できるというような感じにします。

この辺で、いちいちrun-appの度にデータがクリアされるのが面倒なのでDataSource.groovyをちょっとだけ書き換えて、登録したデータが残るようにします。


development {
 dataSource {
  dbCreate = "update" // one of 'create', 'create-drop','update' //create-dropからupdateに変更
  url = "jdbc:hsqldb:file:devDB;shutdown=true"
 }
}
test {
 dataSource {
  dbCreate = "update"
  url = "jdbc:hsqldb:mem:testDb"
 }
}
production {
 dataSource {
  dbCreate = "update"
  url = "jdbc:hsqldb:file:prodDb;shutdown=true"
 }
}

Acegi-pluginを入れたところからは、Grailsインストール+簡単な認証付きアプリをサックリ作成して動作確認。を参考にしてください。

今回の場合、Companyを触れるユーザと触れないユーザを分けたいので、
roleを「admin」「user」と２つ作って、適当な2人のユーザを作って、それぞれに割り当てます。最後にRequestmapで、/company/**をadminだけにすると、userのroleしか持ってないユーザは、そのページに行こうとしても「権限ないよ」と言われます。

で、適当なプロジェクトですけど、Morphに上げますので、そこで動作を見てください。

この辺で、TagLibをちょっと。というか、scaffoldしたときの日付表示が英語っぽいので、表示を逆にしたTagLibが社内にあったので、こっそり流用。山本師曰く、順番逆にしただけ、らしいです。
どこかにソースを上げておくと思うで、興味がある人はそこで見てみてください。
item.groovyの中のreleaseがDateなので、これを日本人が見てわかりやすいようにしてみます。
で、ここで、GSPがないと書き換えられないので、generate-allして、views/itemの下に、create.gsp
list.gsp
show.gsp
edit.gsp
を書き出します。



grails generate-all item

create.gspとedit.gspの下記をちょりっと修正します。


<!-- <g:datePicker
 name="release"
 value="${item?.release}" ></g:datePicker> -->
<ex:datePicker name="release"
 precision="day"
 years="${2000..2050}"
 value="${item?.release}">
</ex:datePicker><br/>

こんな感じです。

もうひとつ、表示している方のshow.gspもちょりっと直します。


<!-- <td valign="top"
 class="value">${fieldValue(bean:item, field:'release')}</td>
 -->
<td valign="top" class="value">
<g:formatDate date="${item.release}"
  format="yyyy/MM/dd" /></td>

これで、なんとなく違和感があったところが修正されました。

これぐらいで、一回Morphにアップしようと思います。
http://mkawa.morphexchange.com/
ここだと、URLにgcroneがつけられない？ので、HOMEとかクリックすると、出ません。適当にURLを変えてみてください。一通りできます。
ユーザも制限かけてないので作れます。

第13.8回Grailsコードリーディング（その３）　Grails本気の入門～2時間でいけるところまでライブコーディング!?をまとめてみました

2008-11-24T19:43:00.001+09:00

と、こんな感じでふとお客さんを見ると、多分「？」です。自分の仕事にはまだ合致していない模様です。
だいたい、「Company:1」って、まずそこで違和感ありますよね。なので、ドメインクラスにちょっと細工します。多分、これは最初からやっておいた方がいいと思います。

22.ID表記されているところを見やすくしてみます。
それぞれのドメインクラスに下記のように追記します。
Item.groovy


class Item {

static belongsTo = [company:Company]

String name
String spec
Long price
Date release

static constraints = {
     name(blank:false)
     spec(maxSize:4000)
     price(max:10000L)
     company()
     release()
}
String toString(){ //ここから追記
  return name
}
}

Company.groovy


class Company {

static hasMany = [items:Item]

String name
String note

static constraints = {
     name(blank:false)
     note(maxSize:4000)
}

String toString(){ //ここから追記
  return name
}
}

toString()を使って、そのままnameを返す、ということをしています。
こうすると、下記のように、ちゃんと名前を返してくれるようになります。returnのところには、Groovyで色々かけるので、計算させたりとかもOKです。ドメインクラスとして持たせておいた方がよいものは、ここでやってしまうのも手です。
・商品を登録するところ（セレクタに「ニューキャスト」と出ている）

・商品情報を表示したところ（companyのところに…）

・製造元情報を表示したところ（Add Itemのところに「南天のどあめ」と出ている）

これでなんとなく「へー」から「なるほどね」と、ちょっとお客さんとプログラマが近づいた感が出るかもしれません。
ここで、もう一発、ぐっと近づけるために、フィールド名を日本語で表記させてみます。

23.i18n-templatesを使って、日本語表記にしてみる。
ですが、ここはなんとGCR当日に偶然にも上原さんが書いていたので、そっちを参考にしてください。
■[Grails]好きなGrailsプラグインシリーズその1 i18n-templates
★ちなみに、僕のは今Grails自体が1.0.3なので、grails install-plugin i18n-templateをしたときに、1.0.4を拾ってきてしまいます。そうすると、例えばcreateを開くと、create.jpsとか無いよ、って言われましたので、前に拾っていた1.0.3のPluginを入れると正常に動作しました。途中でPluginを入れ替えたけど特に問題ないのはなぜ？
ちなみに、今回の表記を変更したものはこんな感じです。
grails generate-i18n-messages item及びcompanyで吐きだしてくれたもの


home=Home
create=Create
edit=Edit
update=Update
delete=Delete
delete.confirm=Are you sure?

# Item messages
item.create=Create Item
item.edit=Edit Item
item.list=Item List
item.new=New Item
item.show=Show Item
item.created=Item {0} created
item.updated=Item {0} updated
item.deleted=Item {0} deleted
item.not.found=Item not found with id {0}
item.id=Id
item.name=Name
item.name.blank.error=Property [Name] of class [Item] cannot be blank
item.name.nullable.error=Property [Name] of class [Item] cannot be null
item.spec=Spec
item.spec.maxSize.error=Property [Spec] of class [Item] with value [{2}] exceeds the maximum size of [{3}]
item.spec.nullable.error=Property [Spec] of class [Item] cannot be null
item.price=Price
item.price.max.error=Property [Price] of class [Item] with value [{2}] exceeds maximum value [{3}]
item.price.nullable.error=Property [Price] of class [Item] cannot be null
item.company=Company
item.company.nullable.error=Property [Company] of class [Item] cannot be null
item.release=Release
item.release.nullable.error=Property [Release] of class [Item] cannot be null

# Company messages
company.create=Create Company
company.edit=Edit Company
company.list=Company List
company.new=New Company
company.show=Show Company
company.created=Company {0} created
company.updated=Company {0} updated
company.deleted=Company {0} deleted
company.not.found=Company not found with id {0}
company.id=Id
company.name=Name
company.name.blank.error=Property [Name] of class [Company] cannot be blank
company.name.nullable.error=Property [Name] of class [Company] cannot be null
company.note=Note
company.note.maxSize.error=Property [Note] of class [Company] with value [{2}] exceeds the maximum size of [{3}]
company.note.nullable.error=Property [Note] of class [Company] cannot be null
company.items=Items
company.items.nullable.error=Property [Items] of class [Company] cannot be null

書き換えたもの


home=Home
create=追加
edit=編集
update=更新
delete=削除
delete.confirm=本当に消しちゃうの？

# Item messages
item.create=商品の新規登録
item.edit=商品情報の編集
item.list=商品リスト
item.new=新規登録
item.show=商品情報の表示
item.created=商品 {0} を新規登録しました！
item.updated=商品 {0} を更新しました！
item.deleted=商品 {0} を削除しました…
item.not.found=商品ID {0} は見つからないぞもし
item.id=Id
item.name=商品名
item.name.blank.error=商品名は入れてくれないと登録できませんよ。
item.name.nullable.error=商品名は入れてくれないと登録できませんよ。
item.spec=詳細情報
item.spec.maxSize.error=ゴメン…詳細情報は、4000バイト以上は入れられないんだ…
item.spec.nullable.error=詳細情報入れてよ
item.price=価格
item.price.max.error=価格は、10001円以上は、入れちゃダメなんだ…
item.price.nullable.error=価格はいれなきゃダメなんだよ。
item.company=製造元
item.company.nullable.error=製造元はどこですか？無いわけ無いでしょ！
item.release=発売日
item.release.nullable.error=発売日はちゃんと入れてよね…もう…聞いてんの!
# Company messages
company.create=製造元の新規登録
company.edit=製造元情報の編集
company.list=製造元リスト
company.new=製造元の新規登録
company.show=製造元情報の表示
company.created=製造元 {0} を新規登録しました！
company.updated=製造元 {0} を更新しました！
company.deleted=製造元 {0} を削除しました…知らないよ…
company.not.found=製造元ID {0}？しらねえな…
company.id=Id
company.name=会社名
company.name.blank.error=会社名なしは、あり得ん！
company.name.nullable.error=会社名なしは、あり得ん！
company.note=備考
company.note.maxSize.error=ゴメン…言ってなかったかな。詳細情報は4000バイト以上は入らないんだよ…
company.note.nullable.error=詳細情報は入れてよね。
company.items=製造商品
company.items.nullable.error=商品がないけどいいの？よくないでしょ…

そうすると、下記のように日本語になってくれます。
上原さんも書かれてますが、僕はプロトタイピングのところで、お客さんのイメージできるものを作りたいので、とても重宝しています。そしてgenerate-allとかでViewを吐いた後も、使い続ければ、用語統一がしやすいです。
そうすると、こんな感じです。とりあえず商品登録で、バリデーションエラーを発生させてみました。

出来る限り柔らかくメッセージを書いたつもりでしたが、数行に渡って連発で怒られると、ちょっとヘコみます。気をつけましょう。

と、やっと、この辺でぐっと、また距離が近づくかもですね。

24.「あ、今更だけど、型番入れないといかんわ、ゴメン」
そうですね、そういうのにも対応してあげましょう。
じゃないと、ライブコーディングの意味ないですよね。
型番は大事なので、必須にしておきます。
Item.groovy


class Item {

static belongsTo = [company:Company]

String name
String modelNumber //追加
String spec
Long price
Date release

static constraints = {
     name(blank:false)
     modelNumber(blank:false) //追加
     spec(maxSize:4000)
     price(max:10000L)
     company()
     release()
}
String toString(){
  return name + "(${modelNumber})" //ちょっと変更。商品名（型番）で表記されるように。
}
}

追加変更も簡単にできるんだ、と思わせつつ、本当は、この辺がGCRでも盛り上がりましたが、RoRのようなmigrateの機能がないというところ。ずーっと使い続けるには、上記のようにフィールドの変更があり得るので、そういったバージョンアップのときに、migrationして整合性を調整しつつ、永続的に使用できるようになってるといいのに、という話がありました。確かにそうなんだけどなあ、でも、大将山田さんも山本君もやろうと思えばできるでしょうね、って言ってたので、できるんだろうな。前のGroovyコンファレンスの後でもそういう話あったんだよなあ。実際どうなんだろうな。確かにインデックスの再構築とかいろいろあるんでしょうね。

と、一応こんな感じで、表示されます。ちょっと分かりやすいですね。

modelNumderというフィールドを追加したので、手動でi18n-templateのファイルに書き込んでもいいですが、もう一回、grails generate-i18n-messages itemをして、差分だけコピペして入れてもいいと思います。

その４へ続く

第13.8回Grailsコードリーディング（その２）　Grails本気の入門～2時間でいけるところまでライブコーディング!?をまとめてみました

2008-11-24T19:40:00.002+09:00

７．Grailsロゴの下に、ItemControllerというリンクがあるので、クリックするとItemListページが表示されます。

８．新規登録してみます。
メニューバーのNew Itemをクリックすると、新規登録ページが開きます。

適当に入れてCreateボタンをクリックすれば登録完了のページが表示されます。

※priceは入れないと、nullは許してないよ、っていわれますのでそれは後述参照で。

９．登録データの表示画面でEditをクリックすれば、再編集ページになります。
ここで編集してupdateボタンをクリックすれば、データは更新されます。deleteをクリックすればデータは削除されます。メニューバーのItemListをクリックすれば、登録したデータがリスト表示されます。デフォルトでは11件以上のデータを登録すると次ページに飛べるようなページネイトが表示されます。

ちなみにリストの各ヘッダをクリックすると、昇順降順がソートされます。
下記は、priceをソートしたところ。

ここまでで商品データの登録、確認、再編集、更新、削除、リスト表示が確認できます。

で、大抵この辺までで、最速なら5分ぐらいでいけるはず。
お客さんの反応は、まだ「へー」ぐらい。ここで乗ってくるのは、プログラムに興味がある人ぐらい。
「あのさ、エクセルのとき、名前は入力してないといけないとか、やってたな。
あと、1万円以上の商品は無いんだよね、まえ間違えちゃって怒られたよ業者にさ。
ああ、でも決まってないときもあるなあ。。。
それとこのSpecってのは、もっとたくさん文字はいるよ、こんなんじゃ収まらないねえ。」

10．次にバリデーション（フィールドの制約）を付けてみます。
nameは、商品名なので必須にします。
ドメインクラスのItem.groovyを開いて、constraintsを追加します。


class Item {

String name
String spec
Long price
Date release

static constraints = {
     name(blank:false) //必須入力
     spec(maxSize:4000) //textareaになる
     price(max:10000L,nullable:true) //10001以上はだめだよ,nullでもいいよ
     release()
}
}

ちなみに、このconstraintsに書いたフィールドの順番で、scafflodされたViewの中の表示・入力の順番が変わります。何も書いていないと、フィールド名のアルファベット順（name→price→release→spec）になります。
priceは、Integerにしてあると、10000だけで良いようです。Longだと10000Lと、明示してあげないといけないようです。

「この日付のとこさ、年月とか逆になってるよ。」
「それ後でやりまーす。その前に、商品って自社もあるけど、業者さんのもありますよね」
「ああ、そうそう。100社あるかないかぐらいだね。そうだよ、そこがパスワードかかってて変えられないんだよ、失礼なこった。」

11.製造元をComanyとしてドメインクラスを作ります。


$ grails create-domain-class company

12.会社名と、備考欄ぐらいの簡単なフィールドと、商品（Item）との関連付けを定義します。
折角なので、会社名は必須に、備考はテキストエリアにしてみます。


class Company {

static hasMany = [items:Item]

String name
String note

static constraints = {
     name(blank:false)
     note(maxSize:4000)
}
}

hasMany = [items:Item]とすることで、Companyには、itemsとして、Itemがいくつかぶら下がってますよ、ということになります。

13.商品（Item）にも、その関連付けを定義します。
Item.groovyに２行追加します。


class Item {

static belongsTo = [company:Company] //追加

String name
String spec
Long price
Date release

static constraints = {
     name(blank:false)
     spec(maxSize:4000)
     price(max:10000L)
     company() //追加
     release()
}
}

同じ商品を、違う業者が製造していることはないので、１対多になります。

おっしゃ、ちょっとここまでで3分ぐらい経過しているかもしれないので、お客さんは「？」になります。そうならないように、「しゃべり」をこの辺で入れるのも大事です。
これで製造元の登録を見せよう、と思っても、ちょっとまった。
多分後ろから須江さんが「…Controllerが無いよ」とささやいてくれますので、落ち着いて次の行動に。

14.Companyコントローラーを作成し、Itemのときと同じようにscaffoldを定義します。


$ grails create-cotroller company


class CompanyController {
  def scaffold = true
}

15.今まで作ったItemとCompanyがどんな感じになっているか、ここまでの動作を確認してみます。
もう一回run-appして、ブラウザを確認すると、新しいコントローラー（CompanyController）が出来ています。

16.製造元の会社を登録してみます。
CompanyControllerをクリックして、New Companyをクリックすると、新規登録画面が表示されます。

17.Createボタンで登録され、Show画面（登録した内容の表示画面）に切り替わります。

18.Editボタンをクリックしてください。編集画面が表示されますが、その中のItemsのところに、「Add Item」というリンクボタンが表示されています。

19.Add Itemをクリックすると、Itemの新規登録ページに切り替わります。

20.Createボタンをクリックして登録すると、Show画面になります。

21.ここにある「Company:1」をクリックすると、CompanyのID:1のShow画面になります。
ここで、「Company:1」に、「Item:1」がちゃんとぶら下がりました。
下は、Editボタンをクリックしたところです。

その３へ続く。。。

これは思わず見やすい

2008-11-20T15:45:00.003+09:00

GCRの概略を書いておこうと思いつつ、コード載せるのが面倒でしかも見にくいなというところで、鰯のテクニカルノートさんのところを参照にしてみました。

これは見やすい！



class Company {
  static mapping = {
    table "T_COMPANY"
    id generator:'sequence', params:[sequence:'company_id_seq']
  }

  String name
  String description
  
  String createdUser
  String updatedUser

  Date dateCreated
  Date lastUpdated

  static constraints = {
    name(nullable:false)
    description(nullable:false)
    createdUser(nullable:true)
    updatedUser(nullable:true)
  }
  String toString(){
    return name
  }
}

第13.8回Grailsコードリーディング（その１）　Grails本気の入門～2時間でいけるところまでライブコーディング!?をまとめてみました

2008-11-19T00:37:00.029+09:00

はぁ〜、終わりました。ってかもう三日たっちゃった。。。
書き出したら長くなってしまったのです。

Javaとか、Webアプリケーション開発の根本的な知識がない、よく分かってない人のために、よく分かってない人がライブコーディングをするというおかしなGCRをやって参りました。

Grails初心者でも簡単なWebアプリケーションをその場で本当に作れるのか、ということで、よく分かっている人がやっても意味がないとので、よく分かってない？私目がやらさせていただくことに。。。おいおい。。。

題材
商品管理っぽいものでやってみました。
商品には、製造メーカーが関連付いているイメージです。

僕なりのポリシー
お客さんのところで開発できるぐらいのレベルで考えているので、細かいところは抜きにして、ある程度形として目に見える、動かせるものを目指します。
なので、scaffoldオンリーでコントローラーには手をいれない方針でいきます。

Pluginを使う
せっかくなので、Grailsで公式リリースされているPluginを入れてみようということで、お客さんのイメージを視覚的に盛り上げるi18n-templates-plugin（表記を日本語にしてみるだけですが）と、管理者と一般権限でユーザに機能制限を与える等のユーザ認証機能を持たせてくれるAcegi-pluginを入れてみました。

TagLibを使う
日付表記がいっつも違和感があるので、社内で使ってるのを使ってみます。別にたいしたことはしてないそうです。日本人向けに表記順番を変えただけだそうです。

実際のGCRのときのPDFはほとんど「僕はプログラマではなくて、どっちか言うと営業っぽい感じですよ、何もできませんよ、でも1年ぐらいはやってますよ」っていう内容ですので、みてもしょうがないかもです。
ただ、ライブコーディングなので、これはやっぱりコミュニケーション、お互いの理解が必要だと思って前段で、まずたっぷり言い訳しておきました。

実際は、簡単なWebアプリケーションを作ってみただけなのですが、そのまま書いても普通のQuickStartと一緒になっちゃうので、ちょっと僕なりの脚色を加えてまとめてみました。

Grailsを使った簡単Webアプリケーション構築のターゲットのお客さんを想定してみる。
男性　40台前半　商品を卸している会社の課長ぐらい？
この男性は東京在住20年目だが、実は名古屋出身で、たまに名古屋弁が出てしまう、ちょっと乱暴な物言いだけど根はいい人で、付き合って2年ぐらい、という感じ。実在しません、あしからず。。。

エクセルでうちの商品の管理してんだけどさあ。A君がVBマクロっての？なんかよーわからんことしとって、そのままやめちゃったんだよねえ。

この前去年の探そうと思ったら一苦労したよ。どこにあるかわからねえから、電話しちゃったよ、A君に。ああ、教えてくれたよ。面倒くさそうに「あそこにあるんじゃないですかぁ」だってよ。今までどんだけ世話してやったかっての。虚しいねえ。。。

そんでもってパスワードかかってるのもあるし、開かねえときたもんだ。。。
ついでに「あくせす」だっけ？なんかデータベースっぽいのにしたらって、事務のねえちゃんが言うんだよ。前の会社はそうしてましたって。知るかってんだ、なあ。

でも、これがねえとさ、困ることもあるんだよねえ。いや、たまにだけどね。もともとちゃんと使ってねえしさ、だって何か触ってエラいことになったら、困るし。なんか良い方法ないかねえ。

あ、お金ならかけらんねえよ。だって、おまえこの不況だぞ。おお、そうだ、上司に愚痴ったらよ、なんとかシステムって会社のわけわかんねえ兄ちゃんを連れてきてさ、要件を教えてくださいってさ。なんだよ、こっちが聞きてえよ、何しに来たんだよってなあ。んでオレも真面目だからさ、一生懸命話した訳よ。したらおめえ、見積もりが来て腰抜けちゃったよ、1000万だと。最初に言えっつんだよなあ。まあせめて100万ぐらいとかさ、だいたい10人もいねえ会社で1000万円ったら1月分売上だぞ。社長に言ったら飛び降りちまうぞ。だからA君クビにしちゃダメだって言ったのに。それみたことか、だよなあ。

んなことしてばっかりだから、いつまでたっても忙しいばっかでさ、先がねえよ。
ホント、オレもケツまくるかなあ。。。

でもさ、いい商品もってんだよね。また新商品考えてみたんだよ、これこれ見て、すげーだろ、コレがなんと9,800円！ほら、欲しいでしょ、キタ？お友達価格で今ならなんと…

売られそうになるので一旦停止して、診断内容をまとめると、
・エクセルで商品を管理していた
・VBマクロを使って計算する部分を作った人がいなくなった
・ファイル管理ができてない
・パスワードを使って、触れる人を制限して安全に扱うべきデータもある
・操作に若干の拒絶反応あり
・システム屋に、やりたいことを全部いったら、見積もりが高すぎて無理
・全社員10人ぐらい、多分使う人は限られている。

こういうタイプのお客さんには、難しいことや金額的な話をしても意味がないので、
「イメージに合うかどうか分かんないけど、ちょっと今から作ってみますわ」と、ライブコーディングを始めてみる、という流れでいきませんか。いや、いきましょう。
多分この課長さんも1時間ぐらいは時間とれるだろうし、相談に乗って想像で話しするより、何か作った方が早くないですか、的なノリです。
でもって、このお客さんが「もしかしたら自分でもできるかも？」と思ってくれたら素晴らしいですね。

※アプリケーション名は、当日「Gcr One」と上原さんが命名してくれました。

１．gcroneというGrailsプロジェクトを作成します。


$ grails create-app gcrone

その後、cd gcroneで移動します。ちなみによく移動を忘れます。今回も。。。
※インストール、QuickStartとかはこっちをみてください。

２．商品データとして、Itemというドメインクラスを作成します。


$ grails create-domain-class item

実行すると、/gcrone/grails-app/domainにItem.groovyが作成されます。

で、お客さんに聞いてみる。「商品って、名前とその詳細と価格と、あと何が必要です？」
「ああ、発売日がないといかんね、商品名だけでわからんから」

３．商品データのドメインクラスにフィールドを定義します
エディタでItem.groovy開いて、商品名、スペック、価格、発売日のフィールドをそれぞれの型で作成します。


class Item {

String name
String spec
Long price
Date release

}

※priceはIntegerでもいいと思いますが、あえて失敗したいので。

４．とりあえずScaffoldしたいので
データ登録、編集、削除、リスト表示を確認してみます。
なので、まずその機能を与えるためのコントローラを作成します。


$ grails create-controller item

実行すると、/grails/grails-app/contollersにItemController.groovyが作成されます。

５．Itemコントローラーにscaffoldを定義します。
今作ったコントローラーItemController.groovyを開いて、
def index...のところを下記に置き換えます。


class ItemController {
  def scaffold = true
}

※trueのところはItemでもいいですが、どうも挙動がそれぞれで異なるようです。詳細はまだ調べてなかったです。はい。

６．一回ブラウザでみてみます。
まずは何も考えずにgrails run-appでWebアプリケーションを動作させてみます。
立ち上がったら、http://localhost:8080/gcroneをブラウザで開きます。


$ grails run-app

正常に起動すれば、ターミナルにだらりと起動メッセージが出た後、最後に下記が出てきます。


Server running. Browse to http://localhost:8080/gcrone

成功すると、多分下記のような画面が表示されます。

その２へ続く。。。

JAGATセミナーしてまいりました

2008-11-17T21:35:00.002+09:00

「オリジナルスクリプトを使った自動組版」というタイトルでJAGATさんでセミナーをさせていただきました。
WakuScriptについて言えば、初めての一般公開なので、分かりにくかったと思いますが、本来分かりにくいというか、ここまでの歴史を知らないと、なんでWakuScriptなのか分からないと思うので、そういうつもりでお話させてもらいました。

資料は、NCの本サイト（近日Ploneからコンフルエンスに差し替えます）に一応載っけてあります。ご参考に。

前の枠で、(株)フィットの藤原さん（お久しぶりでした）から自動組版についていろいろお話していただいたので、だいぶ省けました。ありがとうございます。マニュアルとか昔からやっていて、うわぁがんばってんなぁと圧倒されつつ、我々（tyama氏も同席）の方は、いつものように幾分まったりと…いやいや真面目に話ししてきました。

セミナーでもお話しましたが、我々は組版エンジンのメーカーではありません。作りたいですが、そんな時間と資本がありません。我々ができることは、Web開発の技術と、組版技術をどうつなげるか、つまりデータをどう扱うか、というところがテーマです。Web開発の技術といっても、WWWの世界だけの話ではなくて、企業内でもWeb技術を使ったイントラシステムとかあるわけで、全く違う世界の話ではありません。という我々も印刷・出版業界の中ですから。このWeb技術は、ユーザとユーザを繋ぐ、ユーザとシステムを繋ぐ、という点では、なんら敬遠する理由のない技術です。そして、とても面白い。
こういう技術を使って、堅苦しく、そして大がかりなシステム構築をするのではなくて、楽しみながら、効率化やコスト削減などにチャレンジしてみてはどうかな、というのが言いたかったことです。

明日は、Grailsコードリーディングで、自分の番なので、今日失敗した？（してないよ）ライブコーディングをまたやって来ます。興味のある人は、月1回やってますので、http://groups.google.com/group/grails-jaに情報がありますので参考にしてください。