先日に引き続き、Flexハンズオンセミナー。
受講者約20人ぐらいになってましたね。
二日目前半 BrazeDS
昨日とは打って変わって、最初からスピード感のある感じで、
ArrayCollectionとArrayの違いとかから入る。
BrazeDSを動かして、RemoteObjectを使って、サーバにあるJavaのClassを叩いてみる。
remoting-config.xmlのdestinationを設定して、
mxmlのRemoteObjectにidとdestinationを合わせる。
なんやようわからんけど、動いている。
社内では、Grailsで作ったWEBアプリにinstall-pluginでflexとすると、BrazeDSを使ってFlexと通信できる状態に簡単になってしまうので、WEB-INFとか全く気にしてなかったけど、そうやって動いてるんだと知ることができました。
list.filterFunction でビューを切り替えるとかも、便利ですね。
二日目後半 FlushBuilderとFlashCatalyst
FlushBuilder（旧称FlexBuilder）
Flex3との違いとかを教えてもらいました。
layout指定が別になったりして面倒になっているところもある。
mx:RemoteObjectじゃなくてs:RemoteObjectだったり。。。
Flash CataLyst
ボタンとかをドローツールっぽく作って、動きをつけて、それをコンポーネントにできる。
デザイナー向けのツールとなる。イラレからのコピペもできた。
デザイナーがFireworksならまだ移行できるかもしれないが、Illustrator信者だと、ちょっとCatalystは厳しいかも。それは機能というより、UIだと思う。パネルの見せ方が、他のAdobe系アプリと一緒だったら、その敷居は低くなると思います。
ただ、イラレでも、レイヤー分け、グループ分け、命名などをFlexの人とちゃんと認識があってれば、間のCatalystをどっち側が触るかは別として、「デザイン」という要素は、Flex側から見て、だいぶ接近したと思います。
いずれにしろFlashBuilderとセットで使うことになるものですね。
とりあえずGrails、BrazeDS、Illustrator、Catalyst、Flex4で何か作ってみようと思います。
そして、懇親会
仮面ライダーあたりから、天野さんが暴走モードに突入。
Flex（というかプログラミング）は、人間の行動と心理で置き換えれば、とても楽しく覚えられる。
懇親会のときのネタで、是非LTをして欲しいもんです。
まとめ
天野さん、金像さん、お疲れ様でした。
認定インストラクタって大変なんですね。Adobeさんは、こういう人たちに支えられてるんだな。買っちゃうもんね、β版から教えてくれる人がいたら、理解しやすいし。
2009年11月22日日曜日
2009年8月3日月曜日
Grailsで運用中アプリのドメインクラスを変更したとき
忘れないうちに。。。
もう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文なのかすぐわかります。
６．まとめ
一度走ってしまってから、こういう変更って結構ありそうですよね。
テーブルの追加、リレーションの追加とかは結構影響範囲も大きく、大幅な変更なので、時間をかけてやってもいいですが、これぐらいはさっくりできないと、ということで、さっくり出来たのでめでたし、めでたし。
もう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文なのかすぐわかります。
６．まとめ
一度走ってしまってから、こういう変更って結構ありそうですよね。
テーブルの追加、リレーションの追加とかは結構影響範囲も大きく、大幅な変更なので、時間をかけてやってもいいですが、これぐらいはさっくりできないと、ということで、さっくり出来たのでめでたし、めでたし。
2009年7月26日日曜日
JGGUG名古屋支部 第2回 Grails/GroovyそしてAIR勉強会
第2回も、またまた結局20名以上の参加者となりました。
なんにせよ、来ていただけるというのは、主催者としてはうれしいもんです。
レポートは後ほどユーザグループから配信されると思うので、ここでは、私的所感を。
今回は、昨年の忘年会、0.9回、第1回とやってきて、Grailsが中心で、そういえばGroovyをやってないなと。知名度的には、やっぱりスクリプト言語系でいけばRubyの方が高くて、RoR同様、Grailsとの比較もされたりしますが、ここ名古屋近辺では、どちらでもなく、WEBアプリ開発と言えば、どちらかいうと、PHPなんですかね、やっぱり。。。
日本語のドキュメントからすると、Groovyなんてほとんどないわけで、実務プログラマの言語の選択条件としては、不利なんだろうな。ま、日本語文献あったからどうよってのもありますけどね。あまり親切すぎる（？のときにすぐに回答を探せる）と、回り道をしなくなるので、それは技術を磨くと言う意味では、あまりよろしいとは思えない。もしくは、すぐに辿り着けると、その答えが全てであって、はい次、となって、それも深くない。といいつつ、情報が足りなくて、右往左往、うんざりするのも生産性としてはよくない。商売なので。難しいですが、長い目で見ればもう少し「探る」という人間的感覚、機能を養うことも重要なので、多少回り道であっても、自分コントロールをしながらやらなければいけないよなと思ってます。
なので、GParallelizer試そうかな。関係ないけど。
一番後ろで、サンプルコードを試しながら、再確認してました。勉強会ってPCがあった方がいいです。その後、勉強しようと思ってもなかなか時間とれないし、その場の雰囲気やニュアンスってすぐ忘れてしまうので、こういうときこそチャンスと思って、僕は、一緒にガンガン試します。やっぱり、自分で動かして、おーっとなれば、なんとなく「内容の理解はともかく、動かすことまではできた」という経験値を頭に入れておきます。そうすれば、あとで、「あんとき出来たんだから出来るはず」となれます。そのぐらいのことはやっておかないと、僕の場合、頭に入らない、ということだけなんですけどね。そして時間を有効に活用しないとね。
だから、山本さんが「どうだったのかなー」と言うので、「個人的には超勉強になった」と答えておきました。
芳村君のFlexも面白かったな。社内でもあんな感じやって欲しいね。やっぱり「見ず知らずの人に何か教える」というときに、色々考えてやると思うんですが、その丁寧さって重要で、社内だと、分かってる、理解してる前提、人も知っている前提で話すけど、実は、僕をはじめ、あんまり分かってないので、この日の内容はとっても丁寧で勉強になりました。
うーん、なんだか自分ばっかりしっかり勉強になっちゃってたら、申し訳ないな。。。
皆さんはどうだったんだろう。。。
なんにせよ、来ていただけるというのは、主催者としてはうれしいもんです。
レポートは後ほどユーザグループから配信されると思うので、ここでは、私的所感を。
今回は、昨年の忘年会、0.9回、第1回とやってきて、Grailsが中心で、そういえばGroovyをやってないなと。知名度的には、やっぱりスクリプト言語系でいけばRubyの方が高くて、RoR同様、Grailsとの比較もされたりしますが、ここ名古屋近辺では、どちらでもなく、WEBアプリ開発と言えば、どちらかいうと、PHPなんですかね、やっぱり。。。
日本語のドキュメントからすると、Groovyなんてほとんどないわけで、実務プログラマの言語の選択条件としては、不利なんだろうな。ま、日本語文献あったからどうよってのもありますけどね。あまり親切すぎる（？のときにすぐに回答を探せる）と、回り道をしなくなるので、それは技術を磨くと言う意味では、あまりよろしいとは思えない。もしくは、すぐに辿り着けると、その答えが全てであって、はい次、となって、それも深くない。といいつつ、情報が足りなくて、右往左往、うんざりするのも生産性としてはよくない。商売なので。難しいですが、長い目で見ればもう少し「探る」という人間的感覚、機能を養うことも重要なので、多少回り道であっても、自分コントロールをしながらやらなければいけないよなと思ってます。
なので、GParallelizer試そうかな。関係ないけど。
一番後ろで、サンプルコードを試しながら、再確認してました。勉強会ってPCがあった方がいいです。その後、勉強しようと思ってもなかなか時間とれないし、その場の雰囲気やニュアンスってすぐ忘れてしまうので、こういうときこそチャンスと思って、僕は、一緒にガンガン試します。やっぱり、自分で動かして、おーっとなれば、なんとなく「内容の理解はともかく、動かすことまではできた」という経験値を頭に入れておきます。そうすれば、あとで、「あんとき出来たんだから出来るはず」となれます。そのぐらいのことはやっておかないと、僕の場合、頭に入らない、ということだけなんですけどね。そして時間を有効に活用しないとね。
だから、山本さんが「どうだったのかなー」と言うので、「個人的には超勉強になった」と答えておきました。
芳村君のFlexも面白かったな。社内でもあんな感じやって欲しいね。やっぱり「見ず知らずの人に何か教える」というときに、色々考えてやると思うんですが、その丁寧さって重要で、社内だと、分かってる、理解してる前提、人も知っている前提で話すけど、実は、僕をはじめ、あんまり分かってないので、この日の内容はとっても丁寧で勉強になりました。
うーん、なんだか自分ばっかりしっかり勉強になっちゃってたら、申し訳ないな。。。
皆さんはどうだったんだろう。。。
2009年7月23日木曜日
G*4に行ってきた
JGGUGイベントのG*第4回（2009年7月22日）に行ってきました。
横浜CIJさんに行くのは久しぶりだなあと道中。
GCRの頃からすると、参加メンバーも増えて盛り上がってきたよなあとぶつぶつ。
2時間で4セッション。ちょっとオーバーしたけれども。
レポート役をかって出てしまったので、超真剣に聞きました。
上原さんのところで、「…やべー…わかんねえ」となりながらも、「そうだ、この人は言語ヲタクなんだ」と言い聞かせて乗り切ったのでした。
とはいいつつ、それぞれ個性豊かな内容で、大変興味深かったです。
僕にとって近くて遠いGrails。近づいたかなと思うと、また離されて。でも気がつくと近くにいたりと、そんな毎日です。
懇親会で、とある方が、「昔はこんなに違う会社の人たちが集うことってなかったな…」と仰っておりました。時代は変わっていくし、変えていかなければいけない。そう思う人たちが集まると単純にオモロイです。僕はもっぱら「ついてかなきゃ」ですが。。。
今週7月24日は、JGGUG＠名古屋でイベントです。
その後25日はDTP勉強部屋です。こちらも盛り上がりそうだな。
横浜CIJさんに行くのは久しぶりだなあと道中。
GCRの頃からすると、参加メンバーも増えて盛り上がってきたよなあとぶつぶつ。
2時間で4セッション。ちょっとオーバーしたけれども。
レポート役をかって出てしまったので、超真剣に聞きました。
上原さんのところで、「…やべー…わかんねえ」となりながらも、「そうだ、この人は言語ヲタクなんだ」と言い聞かせて乗り切ったのでした。
とはいいつつ、それぞれ個性豊かな内容で、大変興味深かったです。
僕にとって近くて遠いGrails。近づいたかなと思うと、また離されて。でも気がつくと近くにいたりと、そんな毎日です。
懇親会で、とある方が、「昔はこんなに違う会社の人たちが集うことってなかったな…」と仰っておりました。時代は変わっていくし、変えていかなければいけない。そう思う人たちが集まると単純にオモロイです。僕はもっぱら「ついてかなきゃ」ですが。。。
今週7月24日は、JGGUG＠名古屋でイベントです。
その後25日はDTP勉強部屋です。こちらも盛り上がりそうだな。
2009年5月9日土曜日
「Grails-1.1を斬る！〜Grails-1.1からのチーム開発〜」in 品川
名古屋の再演＋アルファでした。
奥の方が山本です。
20人ぐらいだったと思います。
相変わらず濃い内容だったと思われます。
あとは、そろそろらしい1.1.1を待ちたいです。
Pluginのところがやっぱり面白そうで、
開発をどう進めていくと効率よく安定させてできるのか、というところへのチャレンジが、
Plugin周りの機能強化に繋がっているとすると、是非実践したいなと。
とりあえず、1.1のGSPタグのincludeを試してみました。
GSP内で、<g:include controller="book" action="test"/>を書いて、例えば、コントローラーの中で、
class BookController {
def test = {
render(text:"テスト">
}
}
とやると、GSPの中に「テスト」という文字が反映されます。
params="パラメーター"を付けるとそれも渡せます。
カスタムでGSPタグを作ってもいいんですが、こねこね面倒で、かつその案件しか使えないタグライブラリになってしまう、とか、同じような実装を別々のコントローラーに書かないといけないとか、多分そんなとき、あるページで、部分的に、ここだけあのコントローラーの機能を使って何か出したいとかというときに便利そうです。
奥の方が山本です。
20人ぐらいだったと思います。
相変わらず濃い内容だったと思われます。
あとは、そろそろらしい1.1.1を待ちたいです。
Pluginのところがやっぱり面白そうで、
開発をどう進めていくと効率よく安定させてできるのか、というところへのチャレンジが、
Plugin周りの機能強化に繋がっているとすると、是非実践したいなと。
とりあえず、1.1のGSPタグのincludeを試してみました。
GSP内で、<g:include controller="book" action="test"/>を書いて、例えば、コントローラーの中で、
class BookController {
def test = {
render(text:"テスト">
}
}
とやると、GSPの中に「テスト」という文字が反映されます。
params="パラメーター"を付けるとそれも渡せます。
カスタムでGSPタグを作ってもいいんですが、こねこね面倒で、かつその案件しか使えないタグライブラリになってしまう、とか、同じような実装を別々のコントローラーに書かないといけないとか、多分そんなとき、あるページで、部分的に、ここだけあのコントローラーの機能を使って何か出したいとかというときに便利そうです。
2009年4月30日木曜日
Grails1.1で認証機能付きアプリを一気に作る 第1回
Plugin関連が結構変わったので、もう一回、バージョン1.1のGrailsで簡単WEBアプリを作るところをまとめてみます。
何回分か分かりませんが、始めてみます。では。。。
＜ここで使用するプラグイン＞
・Acegiプラグインを使う。0.5.1
・Calenderプラグインを使う。1.1.1
・i18n-templatesプラグインを使う。1.1.0.1
・fckeditorプラグインを使う。0.9
＜やってみたいこと＞
・カレンダーから日付を入力する
・ユーザロール（Authority）とReqestMapでユーザの機能制限を付ける
・i18nを使ってプロトタイプ作りを楽にする
・byte[]を使ったファイルアップ
・hasManyとかbelongsToを使ってリレーション
・install-templatesでちょっと作業を楽にする
１．新規アプリを作る（前と一緒）
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回は、準備するところまで。
何回分か分かりませんが、始めてみます。では。。。
＜ここで使用するプラグイン＞
・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年3月20日金曜日
第0.9回 Grails勉強会inNagoya「もやっこでいこみゃ~か!?」無事終了〜
当社セミナールームで、念願のGrails勉強会が終了しました。
全部で16人だったかな、直前のアナウンスにもかかわらず、まずまず。
「もやっこ」って、助け合ってやっていこみゃーという意味だったらしいです。
Grails1.1についての話がメインで、Grailsを触ったことがない人もいましたので、どうかな〜と思いつつも、でも今「一番熱い」部分なので、じっくりコトコト、、、
1.1での変更点、改善点とかは沢山あるんですが、やっぱりPluginのところが、現状の一般的な開発スタイルと比較すると、Grailsらしさを説明するのにちょうどよいのかな。
チーム開発について、効率の良さ、確実性、何より開発者は人なので、既製品のツールによる管理ではなく、コミュニケーションを重視したチームの結束力の強化みたいなのに繋がるんじゃないかと、期待しています。
本番当日時間ぎりぎりまで、悩みながら必死の形相で資料を作ってたのを見ていたですが、日本で山本さんしか、こういうのは話せないんでねえ、だから頑張ってねと見守ってました。
懇親会は「世界の山ちゃん」で！手羽先とりあえず10人前っ！ビールがうめぇ！
最近知り合った人とか、初めての方とか、いろいろお話できてよかったな。名古屋でもこんな風に盛り上がれるんだと、ちょっとこの先を期待できる感触を得ました。
次回は、もっと早くアナウンスしますね。4月後半の予定です。
山本さん、お疲れさんでした〜
2009年3月12日木曜日
2009年2月17日火曜日
Grails Export プラグインを試す
ここから。
Grailsで作ったアプリのList画面で使えるExportPluginです。
上記URLの説明に従ってやってみると、下記のような感じになりました。
出力は、CSV、EXCEL、ODS、PDF、XMLになっています。
PDFは、iTextを使って組み立てていて、ソースディレクトリにあるDefaultPDFExporter.groovyをいじるとそれなりに出せそうです。
ちなみにPDFで出力したもの↓日本語×だけど、調整次第ということで。
帳票までは難しいかもしれないですが、とりあえずCSVで出力したいとか、XMLで出力したいとか往々にしてあるので、便利に使えるんではないでしょうか。
Grailsで作ったアプリのList画面で使えるExportPluginです。
上記URLの説明に従ってやってみると、下記のような感じになりました。
出力は、CSV、EXCEL、ODS、PDF、XMLになっています。
PDFは、iTextを使って組み立てていて、ソースディレクトリにあるDefaultPDFExporter.groovyをいじるとそれなりに出せそうです。
ちなみにPDFで出力したもの↓日本語×だけど、調整次第ということで。
帳票までは難しいかもしれないですが、とりあえずCSVで出力したいとか、XMLで出力したいとか往々にしてあるので、便利に使えるんではないでしょうか。
2008年12月10日水曜日
研修生による課題アプリちょっと変更。でもできてますねえ。
ショッピングカートとかなんとかだったんですが、変更して簡易的なデータの管理に、ファイルアップロードとか検索とか付けてみるものにしました。
2日かかりましたが、二週間ぐらい前までなんの知識もない人たちが、周りのちょっとした手伝いがあったとしてもここまではできるんだと確信できたのが、僕にとって一番の収穫。
うむ、素晴らしい。
本人たちはまだしっかりと教えられた内容を把握できていないところに不安があって、自信なさげですが、
まずは、やろうと決めて、それをちゃんと出来たことが素晴らしい！！
多分詳細は、本人たちのブログにあがると思われます。右下のNCブログからどうぞぅ。
以上
2日かかりましたが、二週間ぐらい前までなんの知識もない人たちが、周りのちょっとした手伝いがあったとしてもここまではできるんだと確信できたのが、僕にとって一番の収穫。
うむ、素晴らしい。
本人たちはまだしっかりと教えられた内容を把握できていないところに不安があって、自信なさげですが、
まずは、やろうと決めて、それをちゃんと出来たことが素晴らしい！！
多分詳細は、本人たちのブログにあがると思われます。右下のNCブログからどうぞぅ。
以上
2008年12月1日月曜日
研修生なブログが公開されています
11月27日から研修生が2名来ておりますので、そのブログでございます。
1ヶ月しかないですが、見ていくと、いろいろ面白いかもしれません。
http://sateliteworks.blog57.fc2.com/
http://rs.180r.com/humanite/
実は、この試みには、いろんな意味（願い）があります。
・業界の宣伝〜印刷・制作業界、その仕事がどんなものかをより多くの人に知ってもらうたい、という願い
最近は、DTP、印刷となると、給料が安い、残業が多い…などなど、あまり良い印象はないようです。面白いのに…。
・「作っている」という感覚と、「作り出す」という感覚の違いを分かって欲しいという願い
物作りには何でも共通することだと思いますが、僕はいつもこう思っています。
作っている人とは、言われたこと、自分が知っている範囲内で「物作りをこなす」人であって、世に出している人ではない。誰かの手によって、例えば営業さんの手によって、お客さんに出されているものである。
作り出す人とは、受け取ったときから、「作り出す」工程はもう始まっていて、出来上がった物に自信を持っていて、それが営業さんの手によってお客さんに渡されたとしても、そこに自分のインパクトを出すことができる。
お客さんの目は決して節穴なんかじゃありません。結構ちょっとした気遣い、違いに敏感です。
「作っている」人は、言葉は悪いですが、「いいなり」になってしまっています。
「いわれたからそうした、言われたとおりにした」＝「いいなり」ということです。
これでは、いつまでたってもそこから抜け出せないです。そして、効率化なんぞ、空想で終わります。
「作り出す」人は、どうしているかをちょと考えてみました。。。
仕事に使うツールをまず熟知している人。ツールとはソフトウェアだけではありません。仕事に使う使わない関係なくです。他にいいツールがあれば試してみます。だからアンテナを張ることはとても重要です。
そして、自分の環境をいつも最善の状態に整備します。環境とはマシン、ソフトウェアのことだけではありません。人の気持ち、自分の気持ちも同じです。
また、自分が効率よくできると自信のある型を持っています。そして、それをいつも磨いています。そこで、何か仕事が来ると、その型にはめるのです。でも、三角形の型に、四角形は入りません。そこで、まずどうするか？
その四角形が、次の仕事、自分の型に入れるべきだと思ったら、仕事を始める前（もしくは途中でも早い段階で）に、四角形の型の作成に入ります。
それは、チャレンジです。うまくいかないかもしれない。
でも、三角形の型を持っているのに、それを破棄して四角形を作ることは、とても屈辱的です。だったら、今度は五角形にも六角形にもなるものを作って待っててやるぜと思います。
もっともいけないのは、三角形だと思ってやったら、後で四角形であることに気付くとか、なんとかなるかなと思いつつやってみたら結局だめで、最初からやり直しになる、とか。
でも、僕はめんどくさがりなので、三角形の型にはめた方が早くできるので、はみ出た一辺について、相談します。「これっていらないですよね？バランス悪くなりますもんね」と言います。運良く「ああ、いらないですね」となったら、即忘却。「いや、これいるんですよ」となったら、理由を聞いてみる。自分の辞書に入れるべきかどうかを判断しなければいけませんので。お客さんは大抵同じような要望、要求をしてきます。だから、自分が切り返せるようになるために、そういう意図はどんどん吸収します。そして、自分の型を拡張するかもしれない。これはいいこと聞いちゃったと。
お客さんが発注先に対してしてほしいことの根本に、「これやって」「了解です」で、ちゃんとしたものが出てきてほしいと願っています。そのためには、お客さんの好みを知るのも必要です。ただ、それ以上に必要なのは、「自分ならどうする」という感覚です。お客さんの好みに合わせていくようにみせかけて、実は自分が良いと思う方向（品質、速度、将来性）へ持って行く、ということです。もっと言うなら「やりやすい方向」です。
ただ手を抜くということではありません。
物作りをする過程で、お互いにリスクを少なく、良い物を仕上げるにはどうすればいいか、を真剣に考えた末のことを、きちんと分かるように説明してあげることです。これこそプロだと思います。
時間を掛けて遅くまで、休日まで使って仕上げることが最善ではない、プロではない、ということです。
いかに日常の作業を短く済ませるかを常に考えていれば自然と流れが良い方に変わっていきます。
ただし、そこで早くできた分、もっと自分の技術に磨きをかけなければいけません。
それこそがプロがプロとして生き残っていくために最も必要なことです。
・「やる気」というモチベーションは、自分で上げるしかない、ということに気付いて欲しいという願い
「うわ、これやらんといかん…」と思ってやる仕事と、「おし、これやっとこ」と思う仕事では全くやる気が違う。やる気が違うということはスピードも、理解力も違う。
あれもこれもやっとかないかん、と思ってしまうと、何にも楽しくない。そのときにはもう「やりたくないこと」になってしまっているからです。それでは仕事は続かない。
仕事でやらされていると思う、もしくはそれさえも感じずにやっているのであれば、ひとつひとつ任されたことから、自分から、「この仕事でこれを身につけよう」「次に同じことをやるときに備えて、今からやることの作業ログをとって、あとで検証して、次はあの人より早くやってやろう」というように考えれば、全部面白い仕事に変わる。
・「教える」「教えられる」ということの大切さ、大変さ、楽しさを理解して欲しいという願い
技術というのは、常に変わっていきます。
既存の技術に追加されたり、修正されたり、無くなったり、全く新しいものになったりと。
今持っている自分の技術を伝えていく、ということが組織作りに必要です。組織も人間と同じ生き物です。ただの「箱である」ということではないのです。そこにいれば雨風しのげるというものではないのです。自分たちで土台を作り、屋根を作り、時には修理したりと、していかなければなりません。そうやって築き上げていく努力を常にしてこそ、組織が成り立つわけです。
新しい人がきたら、自分の持っているものを惜しみなく教える。そして、自分はもっと上を目指す。そこで、教えるときには、どう伝えればいいのか、どうまとめておくのがいいのか、他にどんな技術があるのか、それは本当に正しいのか、ということを真剣にやらないと、企業の中で教えるという行為には当たりません。それは「できそうなことだけやってもらう」ということになると思います。僕もそうでした。でも、それではダメなんですね。そうやってれば、いつか興味が湧いて、そのうち自分から踏み込んでくれるだろうと思っていました。「覚えられないなら、まあ、最悪自分でやるか」みたいな感じだったと思います。今はっきり言えるのは、それではダメだったということです。なので、教えるなら相当の気合いで教える。教えられる方も、分からない、違うのでは？、というように、そこでも真剣勝負する。それは企業にとって命とも言える技術の継承だからです。それを中途半端にしてしまっては、何も形として残らない、と思います。
なのですが、堅苦しくこういうことをやってもダメなので、今いるスタッフがそれぞれ持っている技術をセミナー形式で、それぞれの枠を作って研修生に教える、という試みをしてみることにしました。
さてさて、どうなりますかねえ、乞うご期待。
1ヶ月しかないですが、見ていくと、いろいろ面白いかもしれません。
http://sateliteworks.blog57.fc2.com/
http://rs.180r.com/humanite/
実は、この試みには、いろんな意味（願い）があります。
・業界の宣伝〜印刷・制作業界、その仕事がどんなものかをより多くの人に知ってもらうたい、という願い
最近は、DTP、印刷となると、給料が安い、残業が多い…などなど、あまり良い印象はないようです。面白いのに…。
・「作っている」という感覚と、「作り出す」という感覚の違いを分かって欲しいという願い
物作りには何でも共通することだと思いますが、僕はいつもこう思っています。
作っている人とは、言われたこと、自分が知っている範囲内で「物作りをこなす」人であって、世に出している人ではない。誰かの手によって、例えば営業さんの手によって、お客さんに出されているものである。
作り出す人とは、受け取ったときから、「作り出す」工程はもう始まっていて、出来上がった物に自信を持っていて、それが営業さんの手によってお客さんに渡されたとしても、そこに自分のインパクトを出すことができる。
お客さんの目は決して節穴なんかじゃありません。結構ちょっとした気遣い、違いに敏感です。
「作っている」人は、言葉は悪いですが、「いいなり」になってしまっています。
「いわれたからそうした、言われたとおりにした」＝「いいなり」ということです。
これでは、いつまでたってもそこから抜け出せないです。そして、効率化なんぞ、空想で終わります。
「作り出す」人は、どうしているかをちょと考えてみました。。。
仕事に使うツールをまず熟知している人。ツールとはソフトウェアだけではありません。仕事に使う使わない関係なくです。他にいいツールがあれば試してみます。だからアンテナを張ることはとても重要です。
そして、自分の環境をいつも最善の状態に整備します。環境とはマシン、ソフトウェアのことだけではありません。人の気持ち、自分の気持ちも同じです。
また、自分が効率よくできると自信のある型を持っています。そして、それをいつも磨いています。そこで、何か仕事が来ると、その型にはめるのです。でも、三角形の型に、四角形は入りません。そこで、まずどうするか？
その四角形が、次の仕事、自分の型に入れるべきだと思ったら、仕事を始める前（もしくは途中でも早い段階で）に、四角形の型の作成に入ります。
それは、チャレンジです。うまくいかないかもしれない。
でも、三角形の型を持っているのに、それを破棄して四角形を作ることは、とても屈辱的です。だったら、今度は五角形にも六角形にもなるものを作って待っててやるぜと思います。
もっともいけないのは、三角形だと思ってやったら、後で四角形であることに気付くとか、なんとかなるかなと思いつつやってみたら結局だめで、最初からやり直しになる、とか。
でも、僕はめんどくさがりなので、三角形の型にはめた方が早くできるので、はみ出た一辺について、相談します。「これっていらないですよね？バランス悪くなりますもんね」と言います。運良く「ああ、いらないですね」となったら、即忘却。「いや、これいるんですよ」となったら、理由を聞いてみる。自分の辞書に入れるべきかどうかを判断しなければいけませんので。お客さんは大抵同じような要望、要求をしてきます。だから、自分が切り返せるようになるために、そういう意図はどんどん吸収します。そして、自分の型を拡張するかもしれない。これはいいこと聞いちゃったと。
お客さんが発注先に対してしてほしいことの根本に、「これやって」「了解です」で、ちゃんとしたものが出てきてほしいと願っています。そのためには、お客さんの好みを知るのも必要です。ただ、それ以上に必要なのは、「自分ならどうする」という感覚です。お客さんの好みに合わせていくようにみせかけて、実は自分が良いと思う方向（品質、速度、将来性）へ持って行く、ということです。もっと言うなら「やりやすい方向」です。
ただ手を抜くということではありません。
物作りをする過程で、お互いにリスクを少なく、良い物を仕上げるにはどうすればいいか、を真剣に考えた末のことを、きちんと分かるように説明してあげることです。これこそプロだと思います。
時間を掛けて遅くまで、休日まで使って仕上げることが最善ではない、プロではない、ということです。
いかに日常の作業を短く済ませるかを常に考えていれば自然と流れが良い方に変わっていきます。
ただし、そこで早くできた分、もっと自分の技術に磨きをかけなければいけません。
それこそがプロがプロとして生き残っていくために最も必要なことです。
・「やる気」というモチベーションは、自分で上げるしかない、ということに気付いて欲しいという願い
「うわ、これやらんといかん…」と思ってやる仕事と、「おし、これやっとこ」と思う仕事では全くやる気が違う。やる気が違うということはスピードも、理解力も違う。
あれもこれもやっとかないかん、と思ってしまうと、何にも楽しくない。そのときにはもう「やりたくないこと」になってしまっているからです。それでは仕事は続かない。
仕事でやらされていると思う、もしくはそれさえも感じずにやっているのであれば、ひとつひとつ任されたことから、自分から、「この仕事でこれを身につけよう」「次に同じことをやるときに備えて、今からやることの作業ログをとって、あとで検証して、次はあの人より早くやってやろう」というように考えれば、全部面白い仕事に変わる。
・「教える」「教えられる」ということの大切さ、大変さ、楽しさを理解して欲しいという願い
技術というのは、常に変わっていきます。
既存の技術に追加されたり、修正されたり、無くなったり、全く新しいものになったりと。
今持っている自分の技術を伝えていく、ということが組織作りに必要です。組織も人間と同じ生き物です。ただの「箱である」ということではないのです。そこにいれば雨風しのげるというものではないのです。自分たちで土台を作り、屋根を作り、時には修理したりと、していかなければなりません。そうやって築き上げていく努力を常にしてこそ、組織が成り立つわけです。
新しい人がきたら、自分の持っているものを惜しみなく教える。そして、自分はもっと上を目指す。そこで、教えるときには、どう伝えればいいのか、どうまとめておくのがいいのか、他にどんな技術があるのか、それは本当に正しいのか、ということを真剣にやらないと、企業の中で教えるという行為には当たりません。それは「できそうなことだけやってもらう」ということになると思います。僕もそうでした。でも、それではダメなんですね。そうやってれば、いつか興味が湧いて、そのうち自分から踏み込んでくれるだろうと思っていました。「覚えられないなら、まあ、最悪自分でやるか」みたいな感じだったと思います。今はっきり言えるのは、それではダメだったということです。なので、教えるなら相当の気合いで教える。教えられる方も、分からない、違うのでは？、というように、そこでも真剣勝負する。それは企業にとって命とも言える技術の継承だからです。それを中途半端にしてしまっては、何も形として残らない、と思います。
なのですが、堅苦しくこういうことをやってもダメなので、今いるスタッフがそれぞれ持っている技術をセミナー形式で、それぞれの枠を作って研修生に教える、という試みをしてみることにしました。
さてさて、どうなりますかねえ、乞うご期待。
2008年11月24日月曜日
第13.8回Grailsコードリーディング（その４） Grails本気の入門～2時間でいけるところまでライブコーディング!?をまとめてみました
でもって、この辺で「製造元の情報は表示はするけど、編集とか新規登録は一定の人間にしか触らせない」ということを実現するために、認証機能を付けてみます。
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時間でいけるところまでライブコーディング!?をまとめてみました
と、こんな感じでふとお客さんを見ると、多分「？」です。自分の仕事にはまだ合致していない模様です。
だいたい、「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時間でいけるところまでライブコーディング!?をまとめてみました
７．Grailsロゴの下に、ItemControllerというリンクがあるので、クリックするとItemListページが表示されます。
８．新規登録してみます。
メニューバーのNew Itemをクリックすると、新規登録ページが開きます。
適当に入れてCreateボタンをクリックすれば登録完了のページが表示されます。
※priceは入れないと、nullは許してないよ、っていわれますのでそれは後述参照で。
９．登録データの表示画面でEditをクリックすれば、再編集ページになります。
ここで編集してupdateボタンをクリックすれば、データは更新されます。deleteをクリックすればデータは削除されます。メニューバーのItemListをクリックすれば、登録したデータがリスト表示されます。デフォルトでは11件以上のデータを登録すると次ページに飛べるようなページネイトが表示されます。
ちなみにリストの各ヘッダをクリックすると、昇順降順がソートされます。
下記は、priceをソートしたところ。
ここまでで商品データの登録、確認、再編集、更新、削除、リスト表示が確認できます。
で、大抵この辺までで、最速なら5分ぐらいでいけるはず。
お客さんの反応は、まだ「へー」ぐらい。ここで乗ってくるのは、プログラムに興味がある人ぐらい。
「あのさ、エクセルのとき、名前は入力してないといけないとか、やってたな。
あと、1万円以上の商品は無いんだよね、まえ間違えちゃって怒られたよ業者にさ。
ああ、でも決まってないときもあるなあ。。。
それとこのSpecってのは、もっとたくさん文字はいるよ、こんなんじゃ収まらないねえ。」
10．次にバリデーション（フィールドの制約）を付けてみます。
nameは、商品名なので必須にします。
ドメインクラスのItem.groovyを開いて、constraintsを追加します。
ちなみに、このconstraintsに書いたフィールドの順番で、scafflodされたViewの中の表示・入力の順番が変わります。何も書いていないと、フィールド名のアルファベット順（name→price→release→spec）になります。
priceは、Integerにしてあると、10000だけで良いようです。Longだと10000Lと、明示してあげないといけないようです。
「この日付のとこさ、年月とか逆になってるよ。」
「それ後でやりまーす。その前に、商品って自社もあるけど、業者さんのもありますよね」
「ああ、そうそう。100社あるかないかぐらいだね。そうだよ、そこがパスワードかかってて変えられないんだよ、失礼なこった。」
11.製造元をComanyとしてドメインクラスを作ります。
12.会社名と、備考欄ぐらいの簡単なフィールドと、商品（Item）との関連付けを定義します。
折角なので、会社名は必須に、備考はテキストエリアにしてみます。
hasMany = [items:Item]とすることで、Companyには、itemsとして、Itemがいくつかぶら下がってますよ、ということになります。
13.商品（Item）にも、その関連付けを定義します。
Item.groovyに２行追加します。
同じ商品を、違う業者が製造していることはないので、１対多になります。
おっしゃ、ちょっとここまでで3分ぐらい経過しているかもしれないので、お客さんは「？」になります。そうならないように、「しゃべり」をこの辺で入れるのも大事です。
これで製造元の登録を見せよう、と思っても、ちょっとまった。
多分後ろから須江さんが「…Controllerが無いよ」とささやいてくれますので、落ち着いて次の行動に。
14.Companyコントローラーを作成し、Itemのときと同じようにscaffoldを定義します。
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ボタンをクリックしたところです。
その３へ続く。。。
８．新規登録してみます。
メニューバーの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月20日木曜日
これは思わず見やすい
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
}
}
2008年11月19日水曜日
第13.8回Grailsコードリーディング（その１） Grails本気の入門～2時間でいけるところまでライブコーディング!?をまとめてみました
はぁ〜、終わりました。ってかもう三日たっちゃった。。。
書き出したら長くなってしまったのです。
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プロジェクトを作成します。
その後、cd gcroneで移動します。ちなみによく移動を忘れます。今回も。。。
※インストール、QuickStartとかはこっちをみてください。
２．商品データとして、Itemというドメインクラスを作成します。
実行すると、/gcrone/grails-app/domainにItem.groovyが作成されます。
で、お客さんに聞いてみる。「商品って、名前とその詳細と価格と、あと何が必要です？」
「ああ、発売日がないといかんね、商品名だけでわからんから」
３．商品データのドメインクラスにフィールドを定義します
エディタでItem.groovy開いて、商品名、スペック、価格、発売日のフィールドをそれぞれの型で作成します。
※priceはIntegerでもいいと思いますが、あえて失敗したいので。
４．とりあえずScaffoldしたいので
データ登録、編集、削除、リスト表示を確認してみます。
なので、まずその機能を与えるためのコントローラを作成します。
実行すると、/grails/grails-app/contollersにItemController.groovyが作成されます。
５．Itemコントローラーにscaffoldを定義します。
今作ったコントローラーItemController.groovyを開いて、
def index...のところを下記に置き換えます。
※trueのところはItemでもいいですが、どうも挙動がそれぞれで異なるようです。詳細はまだ調べてなかったです。はい。
６．一回ブラウザでみてみます。
まずは何も考えずにgrails run-appでWebアプリケーションを動作させてみます。
立ち上がったら、http://localhost:8080/gcroneをブラウザで開きます。
正常に起動すれば、ターミナルにだらりと起動メッセージが出た後、最後に下記が出てきます。
成功すると、多分下記のような画面が表示されます。
その２へ続く。。。
書き出したら長くなってしまったのです。
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
成功すると、多分下記のような画面が表示されます。
その２へ続く。。。
2008年11月17日月曜日
JAGATセミナーしてまいりました
「オリジナルスクリプトを使った自動組版」というタイトルでJAGATさんでセミナーをさせていただきました。
WakuScriptについて言えば、初めての一般公開なので、分かりにくかったと思いますが、本来分かりにくいというか、ここまでの歴史を知らないと、なんでWakuScriptなのか分からないと思うので、そういうつもりでお話させてもらいました。
資料は、NCの本サイト（近日Ploneからコンフルエンスに差し替えます）に一応載っけてあります。ご参考に。
前の枠で、(株)フィットの藤原さん（お久しぶりでした）から自動組版についていろいろお話していただいたので、だいぶ省けました。ありがとうございます。マニュアルとか昔からやっていて、うわぁがんばってんなぁと圧倒されつつ、我々（tyama氏も同席）の方は、いつものように幾分まったりと…いやいや真面目に話ししてきました。
セミナーでもお話しましたが、我々は組版エンジンのメーカーではありません。作りたいですが、そんな時間と資本がありません。我々ができることは、Web開発の技術と、組版技術をどうつなげるか、つまりデータをどう扱うか、というところがテーマです。Web開発の技術といっても、WWWの世界だけの話ではなくて、企業内でもWeb技術を使ったイントラシステムとかあるわけで、全く違う世界の話ではありません。という我々も印刷・出版業界の中ですから。このWeb技術は、ユーザとユーザを繋ぐ、ユーザとシステムを繋ぐ、という点では、なんら敬遠する理由のない技術です。そして、とても面白い。
こういう技術を使って、堅苦しく、そして大がかりなシステム構築をするのではなくて、楽しみながら、効率化やコスト削減などにチャレンジしてみてはどうかな、というのが言いたかったことです。
明日は、Grailsコードリーディングで、自分の番なので、今日失敗した？（してないよ）ライブコーディングをまたやって来ます。興味のある人は、月1回やってますので、http://groups.google.com/group/grails-jaに情報がありますので参考にしてください。
WakuScriptについて言えば、初めての一般公開なので、分かりにくかったと思いますが、本来分かりにくいというか、ここまでの歴史を知らないと、なんでWakuScriptなのか分からないと思うので、そういうつもりでお話させてもらいました。
資料は、NCの本サイト（近日Ploneからコンフルエンスに差し替えます）に一応載っけてあります。ご参考に。
前の枠で、(株)フィットの藤原さん（お久しぶりでした）から自動組版についていろいろお話していただいたので、だいぶ省けました。ありがとうございます。マニュアルとか昔からやっていて、うわぁがんばってんなぁと圧倒されつつ、我々（tyama氏も同席）の方は、いつものように幾分まったりと…いやいや真面目に話ししてきました。
セミナーでもお話しましたが、我々は組版エンジンのメーカーではありません。作りたいですが、そんな時間と資本がありません。我々ができることは、Web開発の技術と、組版技術をどうつなげるか、つまりデータをどう扱うか、というところがテーマです。Web開発の技術といっても、WWWの世界だけの話ではなくて、企業内でもWeb技術を使ったイントラシステムとかあるわけで、全く違う世界の話ではありません。という我々も印刷・出版業界の中ですから。このWeb技術は、ユーザとユーザを繋ぐ、ユーザとシステムを繋ぐ、という点では、なんら敬遠する理由のない技術です。そして、とても面白い。
こういう技術を使って、堅苦しく、そして大がかりなシステム構築をするのではなくて、楽しみながら、効率化やコスト削減などにチャレンジしてみてはどうかな、というのが言いたかったことです。
明日は、Grailsコードリーディングで、自分の番なので、今日失敗した？（してないよ）ライブコーディングをまたやって来ます。興味のある人は、月1回やってますので、http://groups.google.com/group/grails-jaに情報がありますので参考にしてください。
2008年11月10日月曜日
GlassfishでGrailsアプリを動かしてみる
なんも無いとこから5分でGrailsをGlassFish v3 Preludeに・・を試してみたメモを参考に試して見ました。ホントに5分でできるんかい。
まず、Glassfishってなんぞや、の人は、
Sun，Javaアプリ・サーバー「GlassFish」新版でJava EE 6の機能を先取りを見てください。
「GlassFishはモジュラー・アーキテクチャを採用する軽量なアプリケーション・サーバー」だそうです。
うちの案件でも2件ぐらい納品されてるんじゃないかな。。。
自動ビルドとかHudsonでやって、こっちに連携とかさせてるんだよねえ、確か。。。
Hudsonを使ったアジャイルな開発入門を後で見てみよう。っていうかyossyがやってたな。。。試してみよう。
手順は、上述通りですが、確かに5分でできますね。
まず、Glassfishってなんぞや、の人は、
Sun，Javaアプリ・サーバー「GlassFish」新版でJava EE 6の機能を先取りを見てください。
「GlassFishはモジュラー・アーキテクチャを採用する軽量なアプリケーション・サーバー」だそうです。
うちの案件でも2件ぐらい納品されてるんじゃないかな。。。
自動ビルドとかHudsonでやって、こっちに連携とかさせてるんだよねえ、確か。。。
Hudsonを使ったアジャイルな開発入門を後で見てみよう。っていうかyossyがやってたな。。。試してみよう。
手順は、上述通りですが、確かに5分でできますね。
2008年9月20日土曜日
アジャイルプラクティスとGettingReal
Getting Realは、37signalsの人たちによって書かれています。
37signalsは、BackPackとか、BaseCampとかのWEBアプリケーションを開発し、サービスとして提供してる会社です。（だよね？）
アジャイルプラクティスは、その後に書かれた本です。
どちらもアジャイル開発についての手引きみたいな感じの内容ですが、ともに英語の翻訳なので、翻訳のされ方で若干、読者に伝わるニュアンスが違うのではないかと思います。
僕が読んだ感想で言えば、アジャイルプラクティスは、より現場サイドでの出来事を想定しているのに対して、Getting Realは、より哲学的な印象が濃い。
両方を読んで感じるのは、現場ってどこも大変だよなと。うまくいく開発なんて存在しないんじゃないかと思うぐらいです。うまくいっているように見えて中身が大変なことになっていたりすると思いますし。
結論になるかどうか分からないけれど、自分たちが携わっている開発は、情報社会の上に成り立つものであって、その情報社会がめまぐるしく変わる状況の中では、お客さんがそのとき良いと思ったもの、僕たちがそのとき、これだと思ったモノは、次の瞬間まったく意味をなさなくなることもある。だから、発注する側も受注する側も常に変わり続けることを前提としなければ上手くいかない。
工業製品として車を作ります、というシステムであれば、その最終の形が見えているわけで、それを出せばよい。でも、最終の形が見えていない、見えないものを作り出すシステムというのは、世の中の情勢とともに進化し続けるシステムとして成立させていくしかないんじゃないかと思います。
なので、作る側として、どんな小さな案件でも、小さなモジュールでも、より真剣にならないといけないし、お客さんと一緒に、さらにその先をしっかり見続けることが必要だなと思います。
37signalsは、BackPackとか、BaseCampとかのWEBアプリケーションを開発し、サービスとして提供してる会社です。（だよね？）
アジャイルプラクティスは、その後に書かれた本です。
どちらもアジャイル開発についての手引きみたいな感じの内容ですが、ともに英語の翻訳なので、翻訳のされ方で若干、読者に伝わるニュアンスが違うのではないかと思います。
僕が読んだ感想で言えば、アジャイルプラクティスは、より現場サイドでの出来事を想定しているのに対して、Getting Realは、より哲学的な印象が濃い。
両方を読んで感じるのは、現場ってどこも大変だよなと。うまくいく開発なんて存在しないんじゃないかと思うぐらいです。うまくいっているように見えて中身が大変なことになっていたりすると思いますし。
結論になるかどうか分からないけれど、自分たちが携わっている開発は、情報社会の上に成り立つものであって、その情報社会がめまぐるしく変わる状況の中では、お客さんがそのとき良いと思ったもの、僕たちがそのとき、これだと思ったモノは、次の瞬間まったく意味をなさなくなることもある。だから、発注する側も受注する側も常に変わり続けることを前提としなければ上手くいかない。
工業製品として車を作ります、というシステムであれば、その最終の形が見えているわけで、それを出せばよい。でも、最終の形が見えていない、見えないものを作り出すシステムというのは、世の中の情勢とともに進化し続けるシステムとして成立させていくしかないんじゃないかと思います。
なので、作る側として、どんな小さな案件でも、小さなモジュールでも、より真剣にならないといけないし、お客さんと一緒に、さらにその先をしっかり見続けることが必要だなと思います。
GrailsでBDDとTDDの比較
Pluginを作ってみようと思って調べてたら、antを使ったサンプルがあったので、試してみようと。
[Java][Groovy] Grails プラグインの作り方 - シンプルな easyb 実行プラグインを作成
で、easybってなんぞやと、Javaのビヘイビア駆動開発をやさしく実現する"easyb"を試すを見て、へえー
、知らなかった。easybとはビヘイビア駆動開発（BDD）ですと。
テスト駆動開発（TDD）との違いも書かれているのですが、どっちがいいんだろうな〜。
お客さんから聞いた内容を、検査仕様としてまとめていきやすいのはBDDかなと。BDDはDSLで書くみたいだから、文章（ドキュメント）にはしやすい気がします。
無いものと言えば、TDDとしてのWEBTestのプラグインはHTMLとかファイルが出てくるけど、easyBのプラグインでは出てこない。出せるようにすれば良いんだけど。
面白いなと思うのは、Pendingという内容が書かれていない検査項目の数が出てくるところかな。
「こういう状況で(given)、こういう条件を満たしたとき(when)、このように振る舞う(then)」
だそうです。
でもって、初回、バージョンアップリリース直前とか、そういうときには、TDDで作ったテストを回した方がいいのかな。使い分けるべきか、使い分けられるものなのか、きっと山本氏が答えてくれるんじゃないかと。
[Java][Groovy] Grails プラグインの作り方 - シンプルな easyb 実行プラグインを作成
で、easybってなんぞやと、Javaのビヘイビア駆動開発をやさしく実現する"easyb"を試すを見て、へえー
、知らなかった。easybとはビヘイビア駆動開発（BDD）ですと。
テスト駆動開発（TDD）との違いも書かれているのですが、どっちがいいんだろうな〜。
お客さんから聞いた内容を、検査仕様としてまとめていきやすいのはBDDかなと。BDDはDSLで書くみたいだから、文章（ドキュメント）にはしやすい気がします。
無いものと言えば、TDDとしてのWEBTestのプラグインはHTMLとかファイルが出てくるけど、easyBのプラグインでは出てこない。出せるようにすれば良いんだけど。
面白いなと思うのは、Pendingという内容が書かれていない検査項目の数が出てくるところかな。
「こういう状況で(given)、こういう条件を満たしたとき(when)、このように振る舞う(then)」
だそうです。
でもって、初回、バージョンアップリリース直前とか、そういうときには、TDDで作ったテストを回した方がいいのかな。使い分けるべきか、使い分けられるものなのか、きっと山本氏が答えてくれるんじゃないかと。
登録:
投稿 (Atom)