MovableType4(MT4)でウェブページを同一MT内の別ブログに移す
Hiroyuki Noguchiです。
のっぴきならない事情により、古めかしいMovableType4(MT4)を弄る必要が出てきました。
特に、一つのブログ内にある「ウェブページ」を、別のブログに移さなくてはならなくなったのですが……
何と、それがオフィシャルではできない！！ ……という、超残念仕様に、立ち向かってみました。
前提
MovableTypeって？
数多くある静的CMSのうちの一つです。
MT内部の階層構造(ざっくり)
同一MT内で複数のブログを運用することができます。
階層構造は概念的にはこういう感じです。
- MT
- blog_1
- blog_entries
- blog_entry_1
- blog_entry_2
- …
- web_pages
- web_page_1
- web_page_2
- …
- etc…
- blog_entries
- blog_2
- blog_entries
- …
- web_pages
- …
- etc…
- blog_entries
- blog_3
- …
- blog_1
MovableType4(MT4)で使われるMySQLテーブルと各カラムの説明
Hiroyuki Noguchiです。
今さらのMovableType4(MT4)ですが……
今回、どうしても調査せざるを得なくなったので、得た知見を記録しておきます。
どうしても調査せざるを得なくなった理由については別記事にて。
前提
MovableTypeって？
数多くある静的CMSのうちの一つです。
内部で使用されているデータベース
MySQLです。
というわけで、この中身をざっくり見ていきます。
MT4の各テーブル毎のメモ
mt_asset
- 画像とかの素材＝アイテムを管理するテーブル
mt_asset_meta
- 画像とかに設定されるパラメータが入ってくる
- 例： image_width 60 みたいな
- asset_meta_asset_id というカラムがあって、ここに、mt_assetのidが入る
- このテーブルの固有キーが格納されるカラムは存在しない
クレジットカード決済にOmiseを導入してみている最中で、良さそうな点・いまいちな点
前置き
2017年の1月も半ばですね、Hiroyuki Noguchiです。
Webpay終了事件への対応に追われている方々が、結構出てきている頃なんじゃないかなーと思いますがいかがでしょうか。
当協会では、あれこれ検討した結果、Omiseさんを移行の第一候補として進めることにいたしました。
導入の決め手
導入の決め手はいくつかありますが、
- バックグラウンドがしっかりしていそう（Webpayのようなクローズはなさそう）
- Recursions API (定期課金) の実装予定がある
- 日本向けに ******(本決まり未定とのことで一応伏せ字) の実装予定がある
- 日本向けにJCBの実装もできる
- リンク型決済の実装がある
- 営業担当者さんのご対応
このへんが、やはり大きいところでした。
APIの充実度などはやはりStripeに惹かれるところもありましたが、JCB対応できないというのが、当協会としてはかなり厳しい判定要因になりました。
リンク型決済とは
さて、導入理由の4番目、
- リンク型決済の実装がある
と書きました、これについて。
続きを読むCarrierWaveでActiverecordを使わずに、jQuery.facedetectionで実物の顔認識をさせつつプロフィール画像をアップロードする
CarrierWaveとはRuby on Railsで動く画像のアップロードをサポートするgemです。
よくSNS等で使われる、ユーザー画像（アバター）のアップロードに使うことが出来ます。また、ActiveRecordをサポートしているため、ユーザー情報と紐づく形でDBに画像情報を格納することが出来ます。（画像自体はサーバー上の指定した場所に保存しており、BLOB型で保存するにはcarrierwave-blobが必要です。）
今回の要件としては、
ユーザー情報変更画面でユーザー画像のアップロードができる。
画像のファイル名は[ユーザーID].jpgとする。
画像専用のテーブルは用意しない。
画像をアップロードする前にプレビュー画像の表示をする。
画像をアップロードする前に人物の顔写真であるかどうかを判定する。
以上の５つが挙げられます。
続きを読むWindowsでFileMakerProのアプリケーションエラーが出たらプロセスを自動killする
前置き
Hiroyuki Noguchiです。
早いもので、もう2016年も最後のブログ記事投稿となりました。本日の投稿は、冬休み前にやっておきたいことベストワンな、エラー時の自動復旧ネタです。
当協会では、Windows7のタスクスケジューラ機能と合せ技で、FileMaker Proの定時タスクを実行させています。
もちろん、FileMaker Serverでタスク実行をおこなっているものもあるのですが、どうしても、スクリプトの互換性の関係によって、とか、クライアントのWindows端末に入れているあれやこれやとの連携をおこなうために、とかで、FMPで実行しないといけないタスクというものが出てきてしまいます。
基本的には、問題なく動いてくれているのですが、時折、クラッシュしてくれることがありまして（時折、というか、結構な頻度……）
そういう時、人間側が能動的に察知してFMPのプロセスをkillしてあげたりする必要があるのですが、冬休みに入るとそんなこともやっていられないですよね、というお話。
いや、冬休みじゃなくてもエラーからの手動復旧なんて嫌なので、自動化できる限りで自動化を試みましょう。
FileMakerProがクラッシュしたときのエラーログを見る
まず、FileMakerProがクラッシュしたときに、どんなエラーログが出ているのかを見つけます。
以下の通りです。
- イベントビューアー
- Windows ログ
- アプリケーション
- エラーが出ている行
- アプリケーション
- Windows ログ
その行の中を見てみると、
続きを読む