FileMakerカンファレンス2011 1日目

行って来ました、FileMakerカンファレンス2011

今年は椿山荘でやってます。昨年の秋葉原に比べれば中もごちゃごちゃしてなくて

良い感じ。どうせ会社に参加報告しなきゃならんだろうから、メモ代わりに。

 

参加したセッションは、オープニング・業務モデリング・FileMakerGoでのレイアウト・

マイグレーションです。

０，オープニング

いつもの社長挨拶とか。それ以外の内容はNDA？とかいう俗に言う内緒。

 

１，業務モデリング

単純にクライアントの要求そのままのものを　作ろうとするんじゃなくて、

業務プロセスを可視化して、問題の根本を見つけその改善策を提案しましょう

という話。普通そうしますよね？って思ったけど、金払いの悪いクライアントに

対してぞんざいに扱うあまり要求そのままのもの作って後でサポートが増えるとか

あったわ。反省。。。

業務で変更とか多いからエクセル活用せざるをえないんです、だからエクセルみたいに

自由に変更できるもの作ってくれ。ってのはそもそも業務プロセスに問題があるから

変更が頻発したり、DBアプリじゃなくてエクセルを使ってるから部署間の連携が

上手く行かなかったり、２度手間３度手間が発生するんじゃない？っていう話。

 

２，FileMakerGoでのレイアウトテクニック...みたいな

・レイアウトサイズをぴったりに作りましょう→1pxでも大きいとiPad上で画面を

うにょんうにょんドラッグ操作出来てしまう(全く意味のない操作)

これに対しては、やや小さめに作ってアンカー設定しておけば気にしなくても

良いのでは？って思ったけどそれで合っているかは試していない。。

・iOSアプリのように扱うので、他のiOSアプリのレイアウト規則(トレンド)やアイコンを

真似(踏襲)しておけばPC用画面よりも少ないレイアウトオブジェクトで作れるよね？

という話。最もだ。他のiOSアプリでも使われているようなアイコンを目にしたユーザーは

きっと同じ機能を期待するだろうから、踏襲しておけば楽出来る。

・初期化、カスタムメニューを工夫しよう

ログインスクリプトでFileMakerGo用のカスタムメニューをセットして画面上にボタンを

配置する手間を省いたり、余計なメニュー操作が出来ないようにする。またステータス

エリアも隠してロックする(ステータスエリアの出し入れやそこからの操作をさせない)。

・レイアウトオブジェクトにアンカーを設定して縦横変換を想定したレイアウトを作ろう。

左上のメインコンテナ、ランドスケープ時にメインの右側に展開させるコンテナ、縦長

状態の時にボトムに展開させるフッタコンテナみたいな作りにする。SplitViewとか言うらしい。

右や下に展開させるコンテナはアンカーを上と右や左と下にしておいて引っ張られるように

しておいて、メインコンテナの下に一部重なるように配置しておくようだ。

・レイアウト表示スピード(負荷)に配慮したレイアウトにしよう

リスト表示ではレコードの中で特に見せたいものは右側に配置しておくと描画の関係上

良いようだ。また、画面中央固定みたいなレイアウト配置は止める。縦横変えた時に

画面全体再描画がかかるのでイラッとする。

・最後の手段はWebビューア

iOS上で動くのでWebビューアはwebkit。つまりHTML5やCSS3、javascriptバリバリの

Webレイアウトを扱えばとっても立地いんたーふぇいす！何よりオフライン下でも

使える！

 

３，マイグレーション

・さぁ、いいか加減にFileMaker ver6以前のものを使い続ける事から卒業するんだ！

My Graduation......

FMv6以前とFMv7以降ではデータベース構造が変わっているので事前の準備とファイル

コンバート後の作業が沢山あるっていう話。あんまり作業が多いと新しいバージョンで

１から作り直したくなるます。。。このセッションは前から知っている情報しか無かった

仕事で前に結構やりましたし。テーブル構造全く変えない、フィールド名も変えないor

コンバート前に名称変更可能であるなら、データは事前にXMLで書き出して、新しい方に

XMLで取込めばコンバート時にデータがおかしくなるのは防げますよね？違った？

コンバートログも確認しましょうっていう話をされてる時に思ったのが、そもそもログを

csvデータに加工してFileMakerに食わせれば変換ログDBの出来上がりじゃね？って思った。

 

と、まぁこんな感じ。

リレーションシップグラフについて

今回はリレーションシップグラフの書き方について一考

あいつは、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で同じプリフィックスの別テーブルに

カーソルが移動するので便利。

あらゆるドメインを一緒にしてしまうデメリットは、大きくなってくると同じよう

な意味のリレーション定義が出てきたりする。特にリリース後の改修時に必要な

リレーション定義があるのかないのか、既に作られている定義を変更しても良いの

か悪いのかわかりづらくなる＝管理しづらくなる。

 

まぁ、きちんと調査したわけではないので、複数のドメインに跨ったリレーション

シップを作成した場合、関連レコードみなされる、その時には必要のないレコード

までも読み込まれてしまうかどうかは知りません。

 

ただ、業務ドメインを意識しやすくする事や必要最小限のリレーションシップ

グループにして管理やカスタマイズを用意にするという意味で非常に有用だと

考えています。