FileMaker で作業ログを取るようにした
２回目の投稿となります。ootake です。
前回（FileMaker で真っ白レコードを見つける - ピティナ開発者ブログ）から、約２０日振りにレコードが破損して、
今回、あたらしく作業ログを取得することにしましたので、その方法をレポートします。
続きを読む画像ビューアのVixが「応答しない」になる件の解消
前置き
画像ビューアのVixってありますよね。
「今更Vixかよ！」っていうツッコミもあるとは思いますが、便利なのでずっと使い続けています。
リサイズ・トリミングや画像形式の変換がビューアで軽快にできるのは本当に良いです(単なる懐古厨というわけではない)
問題
そんなVixを起動しようとしたら、以下の症状にあたりました。
- 起動直後、サムネイル生成しようとしたまま「応答しない」でフリーズする
実行環境は以下の通り。
- Windows7 SP1(64bit)
- Vix.exeの互換モード設定はXP SP3
もう十数年ぶりにVixのREADMEを開いてみたところ、もしかしたらカタログファイルが肥大化しているのが原因か？と思い当たりました。
解決
カタログファイルは各所に分散されていてどのファイルが原因かよくわからなかったので、お掃除ソフトを実行することに。
私はWisecare365を愛用しているのでそれを使います。
download.cnet.com (ちなみに、Wisecare365は、CNETから落とすのがオススメ)
これでお掃除してみたところ、無事に起動するようになりました。
まだまだVixには現役で闘ってもらえそうです。
Windows10でも動きますからね。
(著: Hiroyuki Noguchi)
一つの社内共有フォルダをwebdavでサーバのディレクトリに同期させよう
はじめに
IT系知識に明るくない一般事務担当者が、ありもののCMSなどを使わずに、さらにFileZilla(SFTP系ツール)なども使わずに、画像ファイルを特定のサーバ内ディレクトリにアップロードする！というシチュエーションってありませんか？
当協会では、従来、個々の担当者のクライアントPC内にFileZillaをインストールして、画像アップロード作業をする、ということが通例になっていたのです。
が、でも、それって、一歩間違えれば関係ないディレクトリやファイルをいじくることができてしまって大変リスキーですよね。
この状況を何とか打破できないかな、と考えたのが、以下のやり方。
- 画像を保管するディレクトリをサーバに設置する
- 特定の一つのローカルクライアントPCに、画像を保管するフォルダを作成する
- 上記クライアントPCのフォルダに、Windowsの共有フォルダ機能を設定して、同一ネットワーク内PCからの読み書きを可能にしておく
あとはサーバ側のディレクトリと、ローカル側のフォルダとが同期できていればよいのですが、そこにwebdavを用います。
以下ではそのやり方を詳述していきます。
JavaScript(jQuery)でのフィルタリング機能
検索結果の表示といえばAjax!と思っていた時期が私にもありましたが、ほぼ完全クライアントサイドでの検索機能を実装する機会があったので、ここにその内容をまとめておきたいと思います。
ざっくりと処理の流れを簡単に説明すると、
サーバー側から表示させるデータを予め全てブラウザに持っておく ⇒ テキストフォームなどの入力情報をリアルタイムに取得し、それに応じた検索をかける ⇒ 検索結果に応じてDOMの表示非表示を切り替える
という感じになっています。かなりシンプルな流れです。
環境 - Ruby on Rails 4.2.3
続きを読むFileMaker で真っ白レコードを見つける
はじめまして、ブログ幽霊部員のootakeです。
昨年PTNAに編入してきて、はじめてFileMakerを使っているのですが、
MySQLやPostgreSQL界隈では見かけないあの子やこの子たちを
たまに紹介していこうと思います。
FileMaker で困ったことNo.1
といえば、たぶん破損レコードです。
idなどで検索したら見つけることはできるのですが、データが見えない。。
いわゆる「真っ白レコード」になってしまう現象です。
破損理由が分からない
さて、データが見えないのはもちろん困るのですが、
一番困るのは、、
「破損理由が分からない」
ということです。
何かのスクリプトで壊しているのか・・
はたまた作業の仕方が悪く（作業途中でLANを引きちぎるとかね）壊れてしまうのか・・
どれくらい頻繁に起きるのか
PTNAでは、多い時で１０日で７件くらいのペースで壊れていきます。
※ もちろんデータはすぐに復旧出来るようにしていますが。
そのため、担当者は毎日新しく破損したレコードがないか、チェックをしているとのことでした。
破損レコードを防止するまでの道
ということで、今回調査から始めました
- 壊れたタイミングを調査する ← イマココ
- 壊れた直前の作業を担当者に確認して、根本原因を把握する
- 解決する
壊れたタイミングを調査する
大分前置きが長くなりましたが、ここからが本題です。
破損レコードの検索方法
onRecordBroken
いつ壊れたのかを知りたいので、onRecordBroken というトリガ
があれば最適だったのですが、未実装なようでした。
破損レコードだけを検索する
ならば、破損レコードだけを検索する方法を調査しました。*1
これは分かってみれば単純で、
- 修正時刻が空になっているレコード
でした。
どゆこと
レコード破損が頻発しているファイルでは、
- 修正時刻をフィールドに持ち
- FileMakerの"修正情報：時刻" を保持するよう定義
しています。
つまり、なにか修正したらFileMakerが勝手に修正時刻を入れてくれる
設定にしています。
そしてこの "修正情報" はレコードが破損する時に、空白が入ってしまうようです。*2
なので、修正日時フィールドが空のレコードを検索することで、
破損レコード数をチェックすることができるようになりました！
今回はここまで。
次回
「破損を検知した！！」をレポート予定です。
ではまた
(著: ootake)
