行って来ました、FileMakerカンファレンス2011
今年は椿山荘でやってます。昨年の秋葉原に比べれば中もごちゃごちゃしてなくて
良い感じ。どうせ会社に参加報告しなきゃならんだろうから、メモ代わりに。
参加したセッションは、オープニング・業務モデリング・FileMakerGoでのレイアウト・
マイグレーションです。
0,オープニング
いつもの社長挨拶とか。それ以外の内容はNDA?とかいう俗に言う内緒。
1,業務モデリング
単純にクライアントの要求そのままのものを 作ろうとするんじゃなくて、
業務プロセスを可視化して、問題の根本を見つけその改善策を提案しましょう
という話。普通そうしますよね?って思ったけど、金払いの悪いクライアントに
対してぞんざいに扱うあまり要求そのままのもの作って後でサポートが増えるとか
あったわ。反省。。。
業務で変更とか多いからエクセル活用せざるをえないんです、だからエクセルみたいに
自由に変更できるもの作ってくれ。ってのはそもそも業務プロセスに問題があるから
変更が頻発したり、DBアプリじゃなくてエクセルを使ってるから部署間の連携が
上手く行かなかったり、2度手間3度手間が発生するんじゃない?っていう話。
2,FileMakerGoでのレイアウトテクニック...みたいな
・レイアウトサイズをぴったりに作りましょう→1pxでも大きいとiPad上で画面を
うにょんうにょんドラッグ操作出来てしまう(全く意味のない操作)
これに対しては、やや小さめに作ってアンカー設定しておけば気にしなくても
良いのでは?って思ったけどそれで合っているかは試していない。。
・iOSアプリのように扱うので、他のiOSアプリのレイアウト規則(トレンド)やアイコンを
真似(踏襲)しておけばPC用画面よりも少ないレイアウトオブジェクトで作れるよね?
という話。最もだ。他のiOSアプリでも使われているようなアイコンを目にしたユーザーは
きっと同じ機能を期待するだろうから、踏襲しておけば楽出来る。
・初期化、カスタムメニューを工夫しよう
ログインスクリプトでFileMakerGo用のカスタムメニューをセットして画面上にボタンを
配置する手間を省いたり、余計なメニュー操作が出来ないようにする。またステータス
エリアも隠してロックする(ステータスエリアの出し入れやそこからの操作をさせない)。
・レイアウトオブジェクトにアンカーを設定して縦横変換を想定したレイアウトを作ろう。
左上のメインコンテナ、ランドスケープ時にメインの右側に展開させるコンテナ、縦長
状態の時にボトムに展開させるフッタコンテナみたいな作りにする。SplitViewとか言うらしい。
右や下に展開させるコンテナはアンカーを上と右や左と下にしておいて引っ張られるように
しておいて、メインコンテナの下に一部重なるように配置しておくようだ。
・レイアウト表示スピード(負荷)に配慮したレイアウトにしよう
リスト表示ではレコードの中で特に見せたいものは右側に配置しておくと描画の関係上
良いようだ。また、画面中央固定みたいなレイアウト配置は止める。縦横変えた時に
画面全体再描画がかかるのでイラッとする。
・最後の手段はWebビューア
iOS上で動くのでWebビューアはwebkit。つまりHTML5やCSS3、javascriptバリバリの
Webレイアウトを扱えばとっても立地いんたーふぇいす!何よりオフライン下でも
使える!
3,マイグレーション
・さぁ、いいか加減にFileMaker ver6以前のものを使い続ける事から卒業するんだ!
My Graduation......
FMv6以前とFMv7以降ではデータベース構造が変わっているので事前の準備とファイル
コンバート後の作業が沢山あるっていう話。あんまり作業が多いと新しいバージョンで
1から作り直したくなるます。。。このセッションは前から知っている情報しか無かった
仕事で前に結構やりましたし。テーブル構造全く変えない、フィールド名も変えないor
コンバート前に名称変更可能であるなら、データは事前にXMLで書き出して、新しい方に
XMLで取込めばコンバート時にデータがおかしくなるのは防げますよね?違った?
コンバートログも確認しましょうっていう話をされてる時に思ったのが、そもそもログを
csvデータに加工してFileMakerに食わせれば変換ログDBの出来上がりじゃね?って思った。
と、まぁこんな感じ。
2011年11月10日木曜日
2011年11月5日土曜日
リレーションシップグラフについて
今回はリレーションシップグラフの書き方について一考
あいつは、RDBMS使ってた人から見ると結構誤解しやすいものらしくて、
単純なER図を書く要領で定義しようとして詰まるってのを聞いたことある。
だから自分がそういう人に説明するときはViewTableの定義みたいなもんだとか
select * from Table_A as tA inner join Table_B as tB on tA.x = tB.x みたいな定義を
GUI化したものとか説明している。
それでも「?」って感じになることは多いんだけど、両方触った人間からすると
これがしっくり来るかなーと。MySQLとかガッツリやってる人間とかから
聞いたりした訳ではないので別の説明方法はあるかもしれんけど。
さて、リレーションシップグラフ。個人的にはFileMakerがレイアウトと
テーブルが結びついている関係でそのレイアウト毎にメインとなるテーブルを決め
そのレイアウトで行う仕事毎にリレーションシップのグループを作るのが
好み。イメージとしては業務のドメインで区切る、トランザクションで区切る
みたいな。
何度も同じ組み合わせを作らなくちゃいけなくなるけど、そのグループ特有の
リレーション定義とか出来るし、命名規則でプリフィックスつけるようにしておけば
日本語入力モードでプリフィックス部分入力→そのリレーションシップに飛ぶ、
目的のテーブルじゃなかった場合→Ctrl+gで同じプリフィックスの別テーブルに
カーソルが移動するので便利。
あらゆるドメインを一緒にしてしまうデメリットは、大きくなってくると同じよう
な意味のリレーション定義が出てきたりする。特にリリース後の改修時に必要な
リレーション定義があるのかないのか、既に作られている定義を変更しても良いの
か悪いのかわかりづらくなる=管理しづらくなる。
まぁ、きちんと調査したわけではないので、複数のドメインに跨ったリレーション
シップを作成した場合、関連レコードみなされる、その時には必要のないレコード
までも読み込まれてしまうかどうかは知りません。
ただ、業務ドメインを意識しやすくする事や必要最小限のリレーションシップ
グループにして管理やカスタマイズを用意にするという意味で非常に有用だと
考えています。
あいつは、RDBMS使ってた人から見ると結構誤解しやすいものらしくて、
単純なER図を書く要領で定義しようとして詰まるってのを聞いたことある。
だから自分がそういう人に説明するときはViewTableの定義みたいなもんだとか
select * from Table_A as tA inner join Table_B as tB on tA.x = tB.x みたいな定義を
GUI化したものとか説明している。
それでも「?」って感じになることは多いんだけど、両方触った人間からすると
これがしっくり来るかなーと。MySQLとかガッツリやってる人間とかから
聞いたりした訳ではないので別の説明方法はあるかもしれんけど。
さて、リレーションシップグラフ。個人的にはFileMakerがレイアウトと
テーブルが結びついている関係でそのレイアウト毎にメインとなるテーブルを決め
そのレイアウトで行う仕事毎にリレーションシップのグループを作るのが
好み。イメージとしては業務のドメインで区切る、トランザクションで区切る
みたいな。
何度も同じ組み合わせを作らなくちゃいけなくなるけど、そのグループ特有の
リレーション定義とか出来るし、命名規則でプリフィックスつけるようにしておけば
日本語入力モードでプリフィックス部分入力→そのリレーションシップに飛ぶ、
目的のテーブルじゃなかった場合→Ctrl+gで同じプリフィックスの別テーブルに
カーソルが移動するので便利。
あらゆるドメインを一緒にしてしまうデメリットは、大きくなってくると同じよう
な意味のリレーション定義が出てきたりする。特にリリース後の改修時に必要な
リレーション定義があるのかないのか、既に作られている定義を変更しても良いの
か悪いのかわかりづらくなる=管理しづらくなる。
まぁ、きちんと調査したわけではないので、複数のドメインに跨ったリレーション
シップを作成した場合、関連レコードみなされる、その時には必要のないレコード
までも読み込まれてしまうかどうかは知りません。
ただ、業務ドメインを意識しやすくする事や必要最小限のリレーションシップ
グループにして管理やカスタマイズを用意にするという意味で非常に有用だと
考えています。
2011年9月26日月曜日
レイアウトの拝借について
新たに、FileMakerで何か作る時に割りと悩むのがレイアウト
ひな形があって、必ずそこから作るのなら別ですが、そうじゃない時や
思いつきでモックの用な感じで作る場合、無味乾燥な状態で作る事も
あるかと思います。そんな時にはスターターソリューションのレイアウトを
拝借すればよいでしょう。レイアウト→新規作成で出てくる変な色の
ものよりずっとマシです。
ただ、そのまま拝借しようとしても、既に作りこまれている部分もあったりして
そのまま利用はかえって手間になったりしますので、パーツだけコピーして使うとかが
良いと思います。
ひな形があって、必ずそこから作るのなら別ですが、そうじゃない時や
思いつきでモックの用な感じで作る場合、無味乾燥な状態で作る事も
あるかと思います。そんな時にはスターターソリューションのレイアウトを
拝借すればよいでしょう。レイアウト→新規作成で出てくる変な色の
ものよりずっとマシです。
ただ、そのまま拝借しようとしても、既に作りこまれている部分もあったりして
そのまま利用はかえって手間になったりしますので、パーツだけコピーして使うとかが
良いと思います。
2011年5月29日日曜日
FileMaker 小技 ※Ver11限定かも
最近見つけた?仕様のようなバグのような小技。
ちゃんと動く(動き続ける)保証はありません。
例として請求書を挙げます。
1,請求書、請求書明細、商品マスタをテーブル定義
2,請求書→請求書明細(請求書idで関連付け)
3,請求書明細→商品マスタ(商品コードで関連付け)
4,簡単な請求書レイアウト作成、この時請求書コンテキストでポータルで請求明細を
表示
さてここで、請求書明細を作成された順番ではなく、商品名で並べた順番で表示したいとする。
だが、商品名は商品マスタにあり、請求明細が持っているのは商品コードのみ。
どうするか?
1,ポータルのコンテキスト定義を商品マスタにする
2,商品マスタテーブルのカラムをポータルソートで指定できるので、商品名を指定
3,ポータルコンテキストを請求明細に戻す
以上。
もしも、仕様だとすると、親(請求書)→子(請求明細)→孫(商品マスタ)と繋がっているので
OKということなのだろうか?だとすると初めから選べるようにして欲しい。。
あんまSQLとか分からんですけど
select i.商品名,i.単価,d.数量,d.金額 from 請求明細 as d inner join 商品マスタ as i
on d.商品コード = i.商品コード where d.請求書_id = 1 order by i.商品名
※請求書idが「1」の請求書明細
みたいな感じ?
自習として、FileMakerとPythonやRuby、おまけでPHPと連携(Web公開)を
試しているので、まとまったらつまったところとかまとめよう。。。
ちゃんと動く(動き続ける)保証はありません。
例として請求書を挙げます。
1,請求書、請求書明細、商品マスタをテーブル定義
2,請求書→請求書明細(請求書idで関連付け)
3,請求書明細→商品マスタ(商品コードで関連付け)
4,簡単な請求書レイアウト作成、この時請求書コンテキストでポータルで請求明細を
表示
さてここで、請求書明細を作成された順番ではなく、商品名で並べた順番で表示したいとする。
だが、商品名は商品マスタにあり、請求明細が持っているのは商品コードのみ。
どうするか?
1,ポータルのコンテキスト定義を商品マスタにする
2,商品マスタテーブルのカラムをポータルソートで指定できるので、商品名を指定
3,ポータルコンテキストを請求明細に戻す
以上。
もしも、仕様だとすると、親(請求書)→子(請求明細)→孫(商品マスタ)と繋がっているので
OKということなのだろうか?だとすると初めから選べるようにして欲しい。。
あんまSQLとか分からんですけど
select i.商品名,i.単価,d.数量,d.金額 from 請求明細 as d inner join 商品マスタ as i
on d.商品コード = i.商品コード where d.請求書_id = 1 order by i.商品名
※請求書idが「1」の請求書明細
みたいな感じ?
自習として、FileMakerとPythonやRuby、おまけでPHPと連携(Web公開)を
試しているので、まとまったらつまったところとかまとめよう。。。
2011年4月10日日曜日
ちょー久しぶり
あまり、気は進まないのですが、久しぶりに更新。
全く書くことが見つからない訳ではなくて、本来の書きたい内容
・FileMakerのちょっと変わった使い方
・FileMaker特有の仕様
・FileMakerと他の言語との連携
など、ネタをきちんとやるに当たって、気が進まなかったのです。
言い換えればメンドくさくってw
仕切りなおして、今日はちょいわざ。
メインコンテキストのテーブルAがあります。
そのテーブルにA+という自己リレーションの定義を行います。
定義は必ず成立させる「X」で扱う項目はなんでもいいです。
レイアウトは一覧レイアウト、ヘッダに先ほど定義した自己リレーションを
1行ポータルで横に並べていきます。そのポータル上にフィールドを置くと、、、
もうおわかりですね。マトリクス表の出来上がりです。
この時、特定のフィールドの値でソートするようにしている場合は、そのソートキーを
リレーション定義にも使っておけば、常に縦横同じレコードの並び順になりますね。
何かのマスタや一次処理レコードを使った印刷等の場合にはらくちんですね。
全く書くことが見つからない訳ではなくて、本来の書きたい内容
・FileMakerのちょっと変わった使い方
・FileMaker特有の仕様
・FileMakerと他の言語との連携
など、ネタをきちんとやるに当たって、気が進まなかったのです。
言い換えればメンドくさくってw
仕切りなおして、今日はちょいわざ。
メインコンテキストのテーブルAがあります。
そのテーブルにA+という自己リレーションの定義を行います。
定義は必ず成立させる「X」で扱う項目はなんでもいいです。
レイアウトは一覧レイアウト、ヘッダに先ほど定義した自己リレーションを
1行ポータルで横に並べていきます。そのポータル上にフィールドを置くと、、、
もうおわかりですね。マトリクス表の出来上がりです。
この時、特定のフィールドの値でソートするようにしている場合は、そのソートキーを
リレーション定義にも使っておけば、常に縦横同じレコードの並び順になりますね。
何かのマスタや一次処理レコードを使った印刷等の場合にはらくちんですね。
登録:
投稿 (Atom)