FileMakerカンファレンス2日目行ってきた

FileMakerカンファレンス2日目(30日)に行って来ましたのでそのメモ的なもの

１，ExecuteSQLについて
　　基本的な使い方や注意点などを丁寧に説明してくれていました。

　　バインド変数といえば言いのか第1引数(query)内に「where fieldA=? or fieldB=?」とか
　　に対する第4引数の個数がマッチしなくても無視するだけとか凄いなって思った。

　　パフォーマンスに関してはやはりレコード総数の多いテーブルをjoinで使ったりしたり
　　selectの結果の対象レコード数が多い場合は重いらしい。まぁそうでしょう。

　　自分が使うとしたらGroupe by とか使いそう。あとは、例えば顧客管理に対する検索で
　　関連テーブルAとBの内容に対する割と複雑なandやor検索をSQLで処理して顧客管理の
　　idだけ取得して関連レコード移動使って従来の検索手段の代替にするとかかな。

２，バックアップストラテジー
　　FileMakerServer冗長化についてのセッションでした
　　メインサーバーの電源ぶっこぬいて待機系に移行するデモ失敗したのは残念でしたね。

３，命名規則についてのセッション
　　これは、思っていたのとちょっと(かなり？)違くて、え？ってなりました。
　　でも名前をドメイン(もしくはカテゴリ)_意味を表す名称_補足情報ていう名前にするのは
　　賛成かな。

４，医療現場(在宅医療)でのFileMakerの活用
　　このセッションではクライアント端末側はリモートデスクトップを利用したシンクラ
　　イアントな使い方の事例紹介でした。確かにこの方法はFileMakerServerとリモート
　　デスクトップサーバーとの間で処理してクライアント側には結果の差分更新分のみ
　　送信されるので外からのアクセスにおいてパフォーマンスとセキュリティ等良いバランス
　　がとれているように思えました。何より開発がFileMakerのみで済むのがいいですね。

５，医療現場(継続医療)でのFileMakerの活用
　　このセッションではカスタムWeb公開の事例でした。
　　パフォーマンスを維持するために検索結果等対象レコード数を極力必要最小限になるよう
　　工夫したり、Ajaxで随時更新にしてトラフィックを小さくする努力をされているようです。
　　

自分は長らく既存ソリューションの延長上の開発しかしてないので、レイアウトがやぼったく
今回のカンファレンスで沢山見かけたWebっぽいレイアウトに非常に危機感を覚えました。
ヤバイ、取り残されてる！って感じ。勉強しなきゃ......

FileMakerカンファレンス1日目行ってきた

FileMakerカンファレンス1日目(29日)に行って来ましたのでそのメモ的なもの

１，オープニング・セッション
　　NDA事項が含まれるため記載できません。

２，FileMaker Ver12のオブジェクトフィールドについて
　　FileMaker Ver12からオブジェクトフィールドがぱうわーうっぷしました。

　　・実体データを指定したPATHに保存や暗号化して保存などがオプションで
　　　選択できるようになって、FileMakerファイルの容量を軽く出来るようになった。
　　　※従来の参照PATHのみ保存と似ているが違う。

　　・レイアウト上のオブジェクトフィールドの表示オプションでインタラクティブ~を
　　　チェックしておくと保存しているPDFや音楽、動画ファイルを直接再生できる。

　　FileMaker社の方がスピーカーだったのですが、資料のページ送りが早くてメモ
　　しきれない、話がカミカミで聞き取りづらいなどちょっと残念でした。

３，FileMakerGoとWeb連携的な
　　iOS上で動くFileMakerランタイムアプリFileMakerGoでFileMakerソリューションを
　　開発する際にUIの一部をWebViewerを使ってHTML5やJavaScriptを利用して少し
　　インタラクティブにしましょう的な内容。

　　WebViewer上で入力した内容をソースを取得する関数やfmpプロトコルを使って
　　FileMakerにフィードバックすれば連携出来るよね！という内容。

４，FileMakerServerを活かすためのインフラ設定
　　FileMakerServer Ver12から64bit対応なので64bitでマルチコアなサーバーを
　　使うと良いですよという話。32bitOSだとキャッシュに割り当てられる上限が
　　800MBだが64bitOSだと積んでいるメモリの50%まで割り当てられる。

　　割り当てるメモリの容量はAdminConsoleの使用状況でキャッシュヒット率を
　　見て調整しましょう。

折角それぞれのセッションでメモ取ってたのに今は手元にないのでざっくり記憶を
元にブログ書いてる残念な自分......

FM-Tokyoに行きました。

この間、10月のFileMaker オフラインミーティングに参加しました。 
１，カスタムWeb勉強会 　
　・Githubに沢山カスタムWeb用のライブラリありますよ。 　
　・FMCakeMIX for CakePHP2.x 　
　・Web公開エンジンに負荷の少ない死活管理をしましょう。
　など。開始前の準備時間？にPerlのMojolicious::Liteで簡単な検索だけのものを見せる。
　※もちろんカスタムWeb公開ですよ。DBはFileMakerですよ。 

２，オフラインミーティング
　・ツールを組み合わせてiPhoneでの見栄えの良い名刺管理
　・UUIDについて
　・レスポンシブWebデザインについて
　・などなど

WordPressでやっていたFileMakerのブログをBloggerに移転してみた。
といっても、まだWordPressの方は封鎖してないけど。

FileMakerとRubyのSinatra

Sinatraのチュートリアルを少し触って、これなら簡単にFileMakerと接続出来るんじゃない？
と思ったのでやってみました。

gihyo.jp:第９回 SinatraとSequel・Hamlで掲示板アプリを作る
http://gihyo.jp/dev/serial/01/ruby/0009

が自分がチュートリアル(以下、見本)としてやってみみたもので、これのmodel部分をFileMakerに
置換えました。
※FileMakerやRuby、Sinatraそのものの細かい説明は省きます。

最終的な階層は以下(見本のファイルも混在してます)
---

app/
    start.rb
    model/
           comment.rb
    view /
           layout.haml
           index.haml
           fmbbs.haml
           style.sass

---

FileMaker部分
・bbsテーブルの作成、カラムは見本のapp/model/comment.rb内で定義しているクラス
Commentsを真似て定義。但し、posted_dateはFileMaker側ではtimestamp型で作成時に自動で
現在のタイムスタンプが入るよう設定。

Ruby部分
・app/model/comment.rbにFileMakerとの接続クラス追加

---以下をcomment.rbに追加---

・hamlを編集(追加)
---app/view/fmbbs.haml

※HamlはPythonのようにインデントが文法になってるので注意！

・app/start.rbを編集
---app/start.rbを以下のように変更---

・rfm(lardawge-rfm)をインストールするの忘れずに！

$ sudo gem install lardawge-rfm

GitHub：https://github.com/lardawge/rfm

これでstart.rbのある位置をカレントにして
$ ruby -rubygems start.rb
これで
http://localhost:4567/fmbbs
で試せます。簡単ですね！
今回、自分がつまずいた所は、
１，rfm経由でFileMakerにレコード作成(多分編集も同じ)でtimestamp型のカラムに値を
設定するための方法が分からなかった。※DateTime型だとエラーになる、整形してもエラー
になる。なんでや！
→読み込みは出来るので、FileMaker側で作成時自動で値設定にした。

２，投稿済みデータの降順ソートがうまくいかない！
→lardawge-rfmでは降順の指定が"desc"ではなく、"descend"だった。

Railsでやるほどじゃないけどちょっと簡単にFileMakerとWebアプリつなぎたいとか、これで
どうでしょうか？ 2012/10/24 編集：コード断片をGithubのGistからの読み込みに変えました。

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

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

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

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

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

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

 

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

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

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

 

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

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

考えています。