Category: PHP

Jupyter notebookでPHPを動かす

macOS Mojave上で、Jupyter notebookを動かし、PHPのkernelを稼働させる方法を記載します。ほとんど自分用のメモみたいなものですね。なんでJupyterなのかというと、先日Bitcoinのセミナーに行ったのですが、その中で自身が作ったライブラリのデモをJupyterでやっていた人がいて、なかなか良いなと感じたからです。結構分かりやすく、セットアップしていれば実際に動かすこともできるからです。そこで、FMDataAPIのサンプルをJupyter notebookベースで示せるようにしたいということがあります。

まず、Jupyterが動いている必要があります。以前にJuliaを入れた時に色々試行錯誤したこともあって、素直な手順がわからないのですが、Homebrewを使うなら、

brew install jupyter

もし使わないのなら、以下のように、pipのアップデートをしてからjupyterをインストールします。

pip3 install --upgrade pip
sudo pip3 install jupyter

PHPの稼働が必要ですが、Mojaveでは、Homebrewを使って入れるのが良いでしょう。こちらも、いろんな用途に使っているので、あれこれ試行錯誤した結果を使っています。何れにしても、php72を、brew installで入れています。

Jupyter用のPHPカーネルは、Jupyter-PHPをインストールします。なお、このカーネルを使うには、PHPのZMQ (ZeroMQ)のモジュールが必要になります。これは、Homebrewにないので、peclでインストールします。最初のコマンドを入れると、次のように、直接レポジトリを指定しなさいと出てくるので、ともかくそうします。

sudo pecl install zmq
sudo pecl install channel://pecl.php.net/zmq-1.1.3

php -iで、phpinfo()関数相当の情報を見てみますが、おそらくエラーが出ると思われます。peclが識別している.soファイルのフォルダと、php72の.soフォルダが違うからです。

メッセージを読めば、それぞれのパスがわかるので、例えば、以下のようなコマンドで、生成したzmq.soファイルを、php72の.soファイルの位置にコピーします。これで、php -iはエラーなく実行できました。

$ cp /usr/local/lib/php/pecl/20170718/zmq.so /usr/local/Cellar/php/7.2.12/lib/php/20170718
$ php -i|grep zmq
zmq
libzmq version => 4.2.5

続いて、Jupyter-PHPをインストールします。サイトのトップページに、インストーラーのダウンロードリンクがあります。署名付きで試したらエラーになったので、とりあえず、署名なしをダウンロードして以下のコマンドを打ち込むと問題なく終わりました。

cd ~/Downloads/
sudo php ./jupyter-php-installer.phar install

こうして、「jupyter notebook」とコマンドを入れれば問題なく使えるようになりました。NewのところにPHPが出てくるので、それを選択してノートブックを用意します。FMDataAPIのノートブックは出来上がれば。レポジトリに公開します。実行済みのノートブックだと、Outも全部入っているのですが、GitHubは多分、.ipynbをリードオンリーのノートブックとして開ける機能があるようなので、サンプルコードを解説とともに読めるノートブックを、該当ソフトウエアをインストールして稼働させなくても、結果を見ることができるようになります。

で、作業していると、コードのカラーリングがされないのがちょっと寂しいです。方法はあるようですが、これをやっても自分の環境だけなのではありますが、それでもカラーリングしたいので、探してみると、jupyter-themesというのがありました。手順通りインストールできました。wgetではなく、curlを使う程度の違いです。

mkdir -p $(jupyter --data-dir)/nbextensions
cd $(jupyter --data-dir)/nbextensions
mkdir jupyter_themes && cd jupyter_themes
curl -O https://raw.githubusercontent.com/merqurio/jupyter_themes/master/theme_selector.js
cd ../ && jupyter nbextension enable jupyter_themes/theme_selector

しばらくカラーリングはうまく動いていたのですが、今、これを書いている時にはなぜか動いていません。再起動ですしょうね。

[IM] FileMaker Server 17とINTER-Mediator

FileMaker 17が発売されました。そして、FileMaker Server 17がリリースされました。ちょっとずつ変わりながら毎年アップデートするFileMakerですが、サーバーは結構変わっています。大きなところでは、管理コンソールがグッと今風なデザインになり、かっこよくなりましたが、その代わり、管理コンソールで設定変更できない項目が出てきました。その辺りがINTER-Mediatorの利用に大きく関連するので、INTER-Mediatorの利用に重点を置いて、変わった部分を説明しましょう。

PHPはインストール直後は未導入

FMS16までは、セットアップ時に選択すればPHPを設定できましたが、FMS17は初期状態ではPHPは使えない状態になっています。もし、PHPを別のサーバーで動かすなら、もうFMSのWebサイトにはPHPは不要ということになりますが、FMSのWeb機能を自分のマシンで動かして検証するなどの作業をしたい方も多いでしょう。その場合、以下のようにコマンドを入れます。$に続く部分が自分で入力するコマンドで、太字にしてあります。fmsadminコマンドで、管理コンソール上では見えなくなったいくつかの機能の設定を行うようになったのです。ユーザー名とパスワードを聞かれれば、FMSの管理者のユーザー名とパスワードを入力します。

$ fmsadmin set cwpconfig enablephp=true
username (msyk):admin
password:
EnablePHP = true
Restart the FileMaker Server background processes to apply the change.

macOSの場合は、「ターミナル」を使います。ログインしているユーザーが管理者の場合には、sudoをしなくても、fmsadminは利用できます。Windows 10の場合、最近まで、スタートメニューの右クリックででてくるメニューで管理者権限でコマンドプロンプトを起動できましたが、いつの間にかこの項目はでなくなっています。スタートメニューの右クリックで「Windows PowerShell(管理者)」を選択して、PowerShellを使いましょう。「コマンドが違うのでは？」と思われるかもしれませんが、上記のfmsadminも、以下のnetコマンドもPowerShellで使えるので安心してください。

このコマンドを入力すると、最後に再起動をするように出てきます。ここで、Webサーバーだけの再起動（HTTPServerフォルダにあるstop、startというファイルをsudo touchで更新）でやってもPHPは稼働しません。それから、CWP（Custom Web Publishing）の再起動も同様です。以下のコマンドで機能の再起動を行います（松尾さん、ありがとうございます）。もちろん、FileMaker Serverの管理者のユーザー名とパスワードを入力する必要があります。

fmsadmin restart httpserver -y

以下のように、FMS全体の停止と起動を行う必要があります。macOSの場合は次のように2つのコマンドを入れます。

sudo launchctl stop com.filemaker.fms
sudo launchctl start com.filemaker.fms

Windowsの場合は、以下の2つのコマンドを入力します。なお、Windows 10の場合は、他に考慮点が色々あるので、この記事の最後の方にそれを記載をします。

net stop "FileMaker Server"
net start "FileMaker Server"

これで、phpinfo()関数を動かすと、次のように、Ver.5.6.24が稼働していることがわかります。なお、info.phpファイルの中身は、phpinfo()関数だけでなく、タイムゾーン指定を入れないと警告が出て情報は表示されません。例えば、info.phpファイルは次のように作ります。

<?php date_default_timezone_set("Japan"); phpinfo(); ?>

PHP自身は古いビルドのままですし、Ver.7.2が主要リリースな今時にVer.5.6なので、アップデートする気はないというところが感じられます。

つまり、FMS17をインストールすると、PHPの実行環境はインストールされているものの、利用できる状態になっていなかったということです。ちなみに、macOSの場合は、Apache2の主要設定ファイルである/Library/FileMaker Server/HTTPServer/conf/httpd.confの最後に、

Include '/Library/FileMaker Server/Web Publishing/publishing-engine/php/sierra/httpd.fmi.conf.php'

という行が加わり、モジュールが読み込まれます。Windowsでも、FileMaker ServerフォルダはC:¥Program Files¥FileMakerにありますが、そこからのパスはほぼ同じような場所にPHPの実行環境が用意されていますが、IISにサイトを追加してWebサーバーとして稼働するようにしています。phpinfo()関数でphp.iniファイルを確認して、必要であれば設定を変更しましょう。

db-class=”FileMaker_FX”を指定する場合

FX.phpを使ってFileMaker Serverへ接続する場合を説明しましょう。INTER-Mediator 5.7/6現在、現実にはFX.phpの一部分だけを使っていますが、何れにしても、以前からあったXML共有を利用してデータベースアクセスしています。

XML共有を利用するには、まず、Web公開エンジンをオンにします。管理コンソールで、コネクタのページを開き、左側のリストで「Web公開」を選択し、右側の「Web公開エンジン」にあるボタン（右のほうにある左右に動くスイッチ）が全体的に青くなるようにしてオンにします。しかし、これだけではありません。

XML共有をオンにするには、さらに、以下のような$以降のコマンドを入力します。もちろん、FMSの管理者アカウントで認証が必要です。このコマンドに関しては、再起動は不要です。

$ fmsadmin set cwpconfig enablexml=true
username (msyk):admin
password:
EnableXML = true

このように、「Web公開エンジン」のオン、そしてXML共有をオンにすることの両方が必要になります。

db-class=”FileMaker_DataAPI”を指定する場合

FMS16でプレビュー扱いだったFileMaker Data APIも、FMS17では正式機能となり、ライセンス価格も「ダウンロードデータ量」に関連することに決まりました。ユーザー数で考えれば幅が広くなるWebサイトの事情を考慮したという点では評価できると考えます。1年間のライセンスの場合、24GX人数までが購入価格に含まれた分量ですが、ともかく、データ転送量を見積もらないと、かかるコストが分からないという状況になりました。

FileMaker Data APIの正式版は、ある意味で「バージョン1」と呼ぶのが適切でしょう。API呼び出しのURLがプレビュー版と大きく違っており、URLに「v1」という文字があることからも、API自体にバージョン管理を今後は行うということを示唆しているものと思われます。

FileMaker Data APIに応答するようにするには、管理コンソールで、コネクタのページを開き、左側のリストで「Web Data API」を選択し、右側の「Web Data API」にあるボタン（右のほうにある左右に動くスイッチ）が全体的に青くなるようにしてオンにします。これだけでよく、コマンドの入力は不要です。

なお、INTER-Mediatorは、FMDataAPIというライブラリを利用して、FileMaker Data APIを利用しています。FMDataAPIはVer.8で、プレビュー版からバージョン1へと対応APIを変更しました。FMS17リリース直後からVer.8は公開していますが、INTER-Mediatorで利用できるようになるためには、INTER-MediatorにあるFMDataAPIをアップデートしないといけません。アップデートするのは簡単ですが、FMS16のFileMaker Data APIは使えなくなります。もっとも、プレビュー版のAPIで真剣に構築していることはないだろうという見込みもあるので、単にどどーんとアップデートしてもいいのですが、その辺り、現在は検討中というところです。アップデート情報はFacebook等で公開します。

Windows 10でFileMaker Server 17

FileMaker Serverは、以前からWindows Serverが対応OSとなっており、Windows 10は対応OSではありません。また、FMS14に関するFileMaker社の文書では、「互換性はありません」となっています。ところが、Windows 10 Pro に FileMaker Server をインストールする によると、FileMaker Server 14/15のインストールができるようにする方法が書かれています。開発者としては手元のWindowsでFMSが動いて入れば便利だと思うところでもあるので、FileMaker Server 17がWindows 10で稼働するかどうかを試してみました。前述の記事のようにインストーラが動かないということはなく、インストーラは問題なく動き、インストールは可能です。ただし、インストーラが動くとは言え、様々なエラーメッセージをうまく捌かないといけない模様であり、「簡単ではないかもしれない」と言ったところです。そこで、PHPを動かすところまでを実現するためにどうすればいいかを確認しました。なお、FileMaker社は稼働するという保証をしていないので、Windows 10でのFMS利用はご自分のリスクで進めてください。

実際に確認したのは、Windows 10 Proに、バージョン1803のアップデートを当てたPCです。IISが稼働していない状態でインストールをすると、途中で次のようなメッセージが出てきて、インストールは途中で終わってしまいます。

そこで、IISをあらかじめ起動しておきます。スタートメニューを表示した時に左端に見えるギアのアイコンの「設定」を選択して、設定ウインドウを表示します。そして、「アプリ」を選択します。そして、右端にある「プログラムと機能」を選択し、懐かしいコントールパネルの「プログラムのアンインストールまたは変更」を表示し、左側にある「Windowsの機能の有効化または無効化」を選択して「Windowsの機能」ウインドウを表示します。ここで「インターネットインフォメーションサービス」のチェックを入れます。黒い四角になるのは下位の項目が全部チェックされているわけではないということを意味しています。ここで、World Wide Webサービス＞アプリケーション開発機能と階層を下り、「CGI」のチェックを入れておきます。このチェックを入れておくのがポイントです。他はそのままでいいのですが、必要に応じて他の機能を入れてもいいでしょう。OKをクリックします。もし、再起動を求められたら再起動をしてください。

この準備をした上で、FileMaker Server 17のセットアップを行えば、概ね問題なく稼働するもようです。インストール途中で以下のようなダイアログボックスが出てくれば、「Webサイトを無効にする」をクリックしてください。これはIISのデフォルトのサイトをオフにして、FileMakerでセットアップされるサイトだけを利用するためです。

こうしてセットアップが終われば、最初に説明したようにコマンドを入れればPHPが利用できるようになります。ただし、INTER-Mediatorを稼働させるという観点では、初期状態のPHPのモジュール読み込みは十分ではないので、php.ini等の設定を変更する必要があります。これについては、近日中にまとめたいと思います。

IISの設定を見るには、スタートメニューを右クリックして「コンピュータの管理」を選択します。「サービスとアプリケーション」の下位項目に、IISがあります。Default Web Siteは停止状態になり、FileMaker Serverのセットアップにより、FMWebSiteという設定が増えていることがわかります。

ここで、PHPを稼働させる設定は、「ハンドラマッピング」の中にあります。その項目の詳細設定ダイアログボックスは次のようになっています。パスは、C:¥Program Files¥FileMaker¥FileMaker Server¥Web Publishing¥publishing-engine¥php¥php-cgi.exeが指定されています。

ちなみに、WindowsでのPHPの稼働方法をチェックすることも含めて、fmsadmin set cwpconfig enablephp=trueを使わないで、IIS上でPHPを稼働できるかを試してみたのですが、その時には、以下の2つのパスのフォルダに、IIS_IUSRSグループに読み取りと実行の権限を与える必要がありました。要するにWeb公開するフォルダと、PHPの実行モジュールへのアクセス権を設定する必要があるということでしょう。

C:¥Program Files¥FileMaker¥FileMaker Server¥HTTPServer¥conf
C:¥Program Files¥FileMaker¥FileMaker Server¥Web Publishing¥publishing-engine¥php

他に、アプリケーションプールの詳細設定で、32ビットアプリケーションの有効化をtrueにしてやっと動いたということもあるのですが、FileMaker Serverに自動設定させた結果では、アプリケーションプールの設定はfalse（既定値）のままでした。

以上のように、Windows 10でもFileMaker Server 17は使えたのですが、なんども書きますが、対応OSではない点を理解した上で対処をしてください。

FileMaker Server 16より搭載のFileMaker Data APIとは?

FileMaker Data APIは、データベースへの読み書きの処理を、Web APIあるいはREST形式のAPIで利用できるものである。FileMakerデータベースを他のシステムと統合したり、Webアプリケーションのバックエンドとして使う場合には様々なフレームワークや言語と組み合わせ利用しやすい形態がREST APIと言える。FileMakerのREST APIについては、すでにアナウンスされていたとは言うものの、FileMaker Data APIがFileMaker Server 16で初めて製品としてリリースされ、利用できるようになった。本来はFileMaker Cloudに搭載されるものと思われていたが、Ver.16が先になったので、次のCloudのリリースには確実に搭載されるのだろう。REST APIはすでにサードパーティ製品はあるものの、FileMaker本体に搭載されたことは今後の製品を予測する上でも大きな出来事と考える。

FileMakerデータベースのWeb利用

FileMaker Pro/GOをクライアントとして利用するソリューションのバックエンドとして、FileMaker Serverを利用し、データの共有をスムーズにできるようにすると言うのがFileMakerのもっともメジャーな利用形態だ。一方、Webの発展が著しいのは言うまでもないが、FileMaker Serverに蓄積したデータをWebつまりWebブラウザーをクライアントとして利用できるようにするニーズもある。

FileMakerは20年近く前からWeb利用に取り組んでいる。初期のHTML拡張によるCDMLによるデータベース連動ページ作成はVer.4で搭載され、当初はかなり期待されたものの、簡単なソリューションで更新処理が複雑でない程度のものでないとかえって開発が難しく、Ver.7の時点で廃止された。Ver.7からしばらくはXSLTをベースにしたWebページ開発ができたが、こちらもVer.11までの搭載となり廃止された。標準技術をベースにしているとは言うものの、他のWeb開発とあまりに手法が違いすぎた。一方、Ver.5より搭載された初期のXML共有は現在ではCustom Web Publishing（CWP）として若干の機能更新はあるものの、現在のFileMaker Serverまで継続している。その後、PHPのクラスライブラリとして提供されたFileMaker PHP APIやそのバックエンドとしてのXML共有の拡張を経て、これらの機能は現在も利用できる。これに加えて、FileMaker Data APIが登場したのである。データの蓄積や取り出しだけを担うサーバー機能としては以上のような経緯があるものの、FileMaker Server 16では、CWPとFileMaker Data APIと言う過去からの全ての仕組みが搭載されていることになる。CloudではCWPは搭載されず、FileMaker Data APIのみとなっている。

FileMaker Pro/Advancedで作ったレイアウトをそのままWebブラウザーで表示するといった仕組みのWeb対応もなされてきた。Instant Web Publishing（IWP）は若干の改良はされてきたもののVer.12で終了となり、Ver.13以降はWebDirectとして、完成度を高めてきており、Ver.15では動きもスムーズになり、システム開発の1つの手法として実運用可能な状況になっている。ただし、Ver.13でGOからの接続がコネクション数に応じたライセンス体系を取るようになると同時に、WebDirectもライセンスが必要となった。従来のIWPは任意の接続は可能であったが、パフォーマンスの問題で数十程度のクライアントの同時接続までとなっていた。

Webアプリケーションに繋がる手法としては、Ver.15では接続数に応じたライセンスが必要となるWebDirectと、サーバーのパフォーマンス次第で接続ライセンスの不要なCWPの両方が組み込まれている。FileMakerのレイアウトがそのままWebブラウザで見えて利用できるのがメリットかデメリットかは簡単には結論は出せない。ソリューションの設計と運用によるものである。HTMLでWebクライアントを構築したい向きにはCWPが必要になるが、一方でライセンス費用を気にしなくてもいいといったコストに偏った見方をされている場合もある。

ライセンス体系は今後どうなるのか？

FileMakerはVer.13以降、接続クライアントに応じたライセンスということを重視した製品系列へとシフトしてきており、FLTというライセンス体系の追加や、IWPの廃止やGOの接続ライセンス必須化を含めて、CWPのような自由な接続という仕組みを排除してきている。加えて、年間ライセンスへとユーザーをシフトさせようとしている。

そうなると、1つの重要な命題は「CWPがいつまで使えるのか」ということに集約できる。現行のライセンスモデルにマッチしない手法だけに、いつ、機能としてなくなっても不思議ではないのである。しかしながら、それに替わる仕組みがなくなることで、システム構築の自由度がそがれることは明白である。CWPに替わるものが、Ver.16で搭載されたFileMaker Data APIとなるが、「トライアル」ということで、今後の展開を見てライセンス形態を決めようとしている意図が見えてくる。正式にリリースされたことで、まだアナウンスはないもののCWPの継続が中止される可能性はゼロではなく、結果的にどのバージョンまで使えるかという問題に帰着する。そして、FileMaker Data APIに関して、どういったライセンス体系への統合を、どのバージョンで行うかということに注目することになる。Ver.16現在、FileMaker Data APIは自由にアクセスできる状態であるが、FileMakerの製品ライセンス体系を考えれば、「いつかはお金を取る」という姿勢は容易に感じとれるのである。

モダンなデータベース利用が可能なFileMaker Data API

ちなみに、なぜ、CWPがFileMaker Data API置き換わると予想されるのかについてだが、総じてFileMaker Data APIの方がモダンであると言えるからである。サーバーにリクエストを送って結果を得るのは昔からあるXML共有でも現在のFileMaker Data APIでも同じであるが、XML共有はURLに対してXMLで結果が返るのに対して、FileMaker Data APIではHTTPのメソッドを伴うきちんと定義されたAPI動作に対してJSONで結果を返す。データの内容的には、ポータルか、別のTOのフィールドなのかを判別するという点では、XML共有は確実にできなかったこともあった。その後の改良でできるようにもなったが、パフォーマンスが悪くなった。

HTTPのメソッドとURLの組み合わせで動作を記述し、JSONで得られるFileMaker Data APIの方が、様々な用途に展開しやすいことも事実だ。機能的には、レイアウト情報まで取得できるCWPの方が勝るものの、FileMaker Data APIは必要最小限の機能になっており、むしろデータ処理に特化されてシンプルに使えることも、学習しやすい点もあり、実運用に即した進化であると言える。

筆者が現在、開発を進めているWebアプリケションフレームワークのINTER-Mediatorも、もちろん、FileMaker Data APIへの対応を行う予定である。CWPがなくなることを見越しての対応である。そこで基礎部分の足固めとして、PHPで使えるクラス「FMDataAPI」を開発し、こちらは単独でMITライセンスのオープンソースソフトウェアとしてGitHubで公開した。こちらの開発で得られた知見を元に、しばらくはFileMaker Data APIについての情報を本ブログで提供することにする。

[IM] MySQLでエンコードにはまったとき

INTER-Mediatorの話題です。こういうことがあるかどうは微妙かもしれませんが、私の郵便番号検索のサイトで、以下のような状況になりました。

  • 郵便番号検索のアプリケーション(A)はmysql_Connectで稼働している（あー、5.5ではついに書き直さないといかんなー）
  • UTF-8で動いているつもりだったが、MySQLで、エンコーディングの指定をしないままに動かしてしまっていた（これは失敗、でも、UTF-8でなんとなく動いている）
  • その上に、INTER-Mediatorで作った、書籍販売サイト(B)を動かす。これも、なんとなく動いている。郵便番号とは別のデータベースを作ったので、独立しているから問題なかった。
  • INTER-Mediatorでの郵便番号検索ページ(C)をいくつかの理由で立ち上げて、郵便番号データを読み込んでいるデータベースを利用して検索しようとしたら、文字化けた。

とまあ、要するに、2項目目が失敗なのですが、なんとなく動いているという状況下気づかなかったものの、最後の項目ではちゃんとやろうとして失敗に気づいたということです。my.cnfに、エンコードとしてUTF-8をつけると、(C)はきちんと動きました。それから、(A)もきちんと動きました。はいおしまいと思っていたら、(B)が文字化けます。つまり、(A)(B)(C)、同時に動かなくなったのです。なお、(C)の後追加した「character_set_client=utf8」が問題（かどうかも問題）のようで、これはmy.cnfから削除しました。(C)の発覚後、「character_set_server=utf8」も追加しましたが、最終的にはこれは残してあります。

結局どうしたか？　(A)は、実は、「SET NAMES utf8」というSQLコマンドを発行して、うまく動かしていたのです。つまり、これを動かさないとうまく行かない大昔の状況のまま運用していて、エンコードの指定が適切でなかったことに気づいたわけです。(A)(B)(C)全部を動かすために結局何をしたかというと、INTER-Mediatorのアプリケーションで「SET NAMES utf8」を実行するようにしました。クエリーするたびにまず、このコマンドを実施して、SELECTを出すようにしました。これも、定義ファイルの設定でできます。こんな感じの定義ファイルです。scriptというキーワードは、FileMakerではよく使いますが、すべてのデータベースで利用可能です。

IM_Entry(
    array(
        array(
            'name' => 'postalcode',
            'view' => 'pcode',
            'records' => 50,
            'maxrecords' => 50,
            'paging' => true,
            'script' => array(
                array(
                    "db-operation"=>"load",
                    "situation"=>"pre",
                    "definition"=>"SET NAMES utf8"
                ),
            ),
        ),
    ),
    null,
    array('db-class' => 'PDO'),
    false
);

そういうことで、あっさりトラブル解決できました。まあ、でも、郵便番号サイトは、今シーズン終わったら、PHP 5.5か5.6で動くように、全面改修だな。

[IM]メールをポストする機能を追加

2014/2/15にコミットしたINTER-Mediatorでは、メールの送信を機能として組み込みました。つまり、メール送信の処理をプログラムを一切しなくても、宣言的な記述だけでできるようになりました。

まず、メールはサーバで送ります。送信方法は、PHPのmail関数を使う方法なので、UNIX系ならsendmailコマンドをたたく方法になります。一方、これだとSMTPサーバへの転送ができないので、qdsmtpも組み込みました（Thanks to Mr. Spok）。SMTP認証はPlainのみの対応となっています。Windowsの場合はmail関数がすでにSMTPですので、php.iniにサーバ情報などを書くことで対処できます。なお、Windows環境はチェックしていないので、何かあれば知らせてもらえると助かります。

ただ、これだけではだめだろうというのはご存知の方はお分かりかと思いますが、昔作っていたOMEというメールソフトにはPHPのクラスもあったので、それをUTF-8で動くように改造してエンコードなどをさせるようにしました。ちなみに、さらにその前に『メール送信システムの作り方大全』という書籍も書いていて、その中の一部のクラスを使いやすいようにしたのがOME.phpです。この本、もう10年以上前なのですね…。

定義ファイルに指定可能なキーワードは以下の通り全て列挙します。しかしながら、すべてを記述することはないです。

IM_Entry(
    array(   // Contexts
         array(
            'name' => 'request',
            'send-mail' => array(
                 'new' => array(
                    'from' => '',
                    'to' => 'email',
                    'cc' => '',
                    'bcc' => '',
                    'subject' => '',
                    'body' => '',
                    'from-constant' => 'Officer <info@msyk.net>',
                    'to-constant' => 'msyk@me.com',
                    'cc-constant' => 'businessmatching@cocoa-study.com',
                    'bcc-constant' => '',
                    'subject-constant' => 'Cocoa勉強会ビジネスマッチング申し込み',
                    'body-constant' => 'テストメール',
                    'body-template' => 'welcome.txt',
                    'body-fields' => 'name,compnay,email,tel',
                    'f-option' => true,
                    'body-wrap' => 68,
                 )
             )
         )
    ),
    array(   // Options
        'formatter' => array(...),
        'smtp' => array(
            'server' => 'mysmtp.msyk.net',
            'port' => 587,
          　　　'username' => 'msyktest@msyk.net',
            'password' => 'oshienai',
        )
    ),
    array('db-class' => 'PDO'),
    false
);

メールを送信するタイミングの指定

‘send-mail’キーの配列の次のレベルのキーとして、’load’ ‘edit’ ‘new’のいずれかを指定できます。それぞれ、データベースからの読み込み時、更新時、新規レコード作成時を意味し、コンテキストに対するそれぞれのタイミングでメールを送信します。いずれも、データベース処理が終了してからメールの送信にかかります。上記の例では、新規レコード作成時に、メールが送信されます。

宛先や送信者の指定

宛先の指定は、’to’ないしは’to-constant’キーに指定します。もし、宛先が一定のものであれば、’to-constant’キーに指定をしてください。’to’キーにはフィールド名を指定します。データベース処理の結果、たとえば新規レコードの場合には新しいレコードが1つ作成されて、そのレコードの内容から’to’キーに指定したフィールドより宛先のデータが取り出されます。編集も原則は1レコードです。一方、読み出しの場合は1レコードにならないかもしれませんが、その場合は最初のレコードから取り出します。むしろ、1レコードに絞り込むコンテキストにするのがメールを送る場合には妥当だと考えられます。

メールアドレスは「名前 <アドレス>」ないしは「アドレス」の2つの形式のみのサポートになります。’to-constant’キーに対する値、あるいは’to’キーで指定されるフィールドの値は、このどちらかの形式にしてください。

cc、bccについてもまったく同様のルールです。’to’と’to-constant’の両方の指定があれば、’to-constant’が優先されます。cc、bccでも-constantが優先となります。

fromについても、fromとfrom-constantキーがあり、設定や動作等は同じです。ただし、UNIXでSMTPサーバを使わない場合だと、通常はソース側のFrom:は無視されて、UNIXアカウントそのものをFrom:として設定してしまいます。ただし、サーバ側で許可されていれば「’f-option’ => true」の指定を定義ファイル内に記述することで、sendmailコマンドの-fパラメータを指定して、送信者の指定が可能です。

件名と本文の指定

件名は、subjectあるいはsubject-constantのいずれかのキーに指定します。toなどと同じルールです。

メールの本文は、定義ファイル内に指定した通りに送信する’body-constant’、フィールドの内容をそのまま送信する’body’に加えて、テンプレートの処理も可能です。優先順はテンプレート、body-constant、bodyの順になりますので、不要なフィールドは消しておきましょう。

テンプレート処理をするには、テンプレートのファイル名をbody-templateキーに指定します。このとき、テンプレートのファイルは、定義ファイルのあるディレクトリを基準に検索します。つまり、定義ファイルといっしょに何らかのテキストファイルを億としたら、body-templateキーの値はファイル名だけでかまいません。

テンプレートのファイル内では、そのファイルの内容を本文にしますが、フィールドの値との置き換えも可能です。置き換えたい箇所に@@1@@、@@2@@のように、アットマーク2つに囲まれた1から始まる整数を指定します。テンプレートのファイルはUTF-8で保存します。

フィールドについては、’body-fields’キーに、半角のカンマで区切って指定します。最初が1で、順次番号が増えるようになります。例で言えば、emailフィールドの値は、テンプレート内の@@3@@と置き換わって表示されます。’body-fields’キーを省略すると、テンプレートのファイル通りにメールが送信されます。

本文は一定の長さで改行を入れます。既定値では72バイトですが、’body-wrap’キーで異なる値にできます。0に設定すると改行しません。ここで、バイト数ですが、実際のバイト数ではなく、日本語は2バイト、英語は1バイトと数えた結果で示しています。実際のエンコードはUTF-8なので、嘘と言えば嘘のカウントになりますが、おそらくこうして指定をすることに慣れている人が多いので、ここでは実態とは関係ない数値ではありますけども実用的という意味で「2バイトルール」でカウントしたものとします。

UNIXの場合のSMTPサーバの指定

定義ファイルのIM_Entry関数の第3引数のオプション領域に’smtp’キーで配列を指定します。その他のキーは、前記の例の通りで、キーを見れば意味は分かると思います。もし、SMTP認証をしない場合は、serverとportだけを指定します。認証する場合は、server, port, username, passwordを指定します。したがって、2つないしは4つの要素があるかのどちらかになります。

SMTPサーバの指定は、params.phpファイルでも指定が可能です。変数名として、$sendMailSMTPの定義し、値は’smtp’の右側の配列と同様に指定をします。params.phpファイルでの指定よりも、定義ファイルの指定が優先されます。どこにもSMTPサーバの設定がない場合には、mail関数での送信になります。

Windowsの場合は、’smtp’の指定やparams.phpファイルでの指定は一般には不要ですが、もし設定すれば、mail関数ではなく、qdsmtpによるメール送信ができます。

送信されるメールの文字セット

基本的にはメールはUTF-8でエンコードして送られます。ISO-2022-JPの指定はOME.phpではできるのですが、必要なら定義ファイルでの指定ができるようにしようと思います。リクエストがなければUTF-8固定で行きます。

ヘッダについては、base64のインラインエンコードを、ASCIIコード以外の文字について行います。本文はそのままですが、ヘッダのContent-TyleのcharsetにUTF-8という文字を付けます。つまり、本文はbase64等でのエンコードは行いません。

ファイルの添付は実装する予定はありません。ファイルを送りたいのなら、そのリンクを送るようなアプリケーションの動作にしましょう。

[IM]MediaAccessクラスと新たな拡張点(2)

こちらの文書の続きです。

FileMakerのオブジェクトフィールドを参照する

オブジェクトフィールドはデータベースごとに扱いが異なり、統一的にはやりにくい処理ではあります。MediaAccessクラスでは、FileMaker Serverをターゲットにオブジェクトフィールドに対応する機能を作成しました。

FIleMakerはFXを経由し、XML共有の仕組みを使います。テキスト型や数値型は、基本的にテキストでフィールドにあるデータが得られます。一方、オブジェクトフィールドはオブジェクトそのもののデータではなく、フィールドのデータに応じた以下のような「テキスト」が得られます。

/fmi/xml/cnt/photo.jpg
http://server:16000/…

PDFは完全なURLで、FileMaker Serverに16000ポートで接続して取り出すことが可能です。JPEGなどの画像の場合は、URLのパスに相当するものが得られますが、たとえばIMGタグのSRC属性にそのまま指定が可能な文字列になります。

いずれにしても、両方ともURLであると解釈すればいいわけです。この仕組みはFileMaker Serverに限らず、一般的なアクセスにも使えます。つまり、media=URLと指定をした場合は、そのURLにアクセスしたデータをMediaAccessクラスが取得し、さらにクラスを呼び出した元にそのデータを返します。/fmi/xml/cntで始まる物だけは特別にURLであるという処理が組み込まれています。また、URLかどうかはそれ以外には、httpあるいはhttpsで開始するものかどうかで判定しています。

MediaAccessでのアクセス権

認証が成立したらすべて参照可能となり、成立しなければ参照不可という単純なものなら非常に話が早く、前に説明したmedia-tokenの仕組みで事は足りるのです。なお、データはCRUDの4つの側面がありますが、メディアに関しては「編集」というのはWeb世界ではかなり難易度が高い世界であり、MediaAccessクラスはほぼ参照のみのサポートになっています。

ここで、メディアそのものがログインしたユーザごとのアクセス権を持たせたい場合が出てきます。レコードについては、特定のフィールドにユーザ名やグループ名を入力することで、そのユーザやグループに所属したユーザでないと参照や更新ができない仕組みを持っています。フィールドのデータはそれでいいのですが、メディアは実体はレコードと別に有ります。ここで、個々のメディアをコンテキストのレコードと結合させ、レコードごとのアクセス権をメディアにまで及ぼす仕組みを組み込みました。

まず、IM_Entry関数の2つ目の引数（オプション引数）に、キーが’media-context’で値がコンテキスト名（コンテキストのnameキーに対する値）を与えます。すると、メディアはこのコンテキストにある特定のレコードの、1つのフィールドのようなふるまいになります。

‘media-context’ => ‘context-name’,

実際にメディアにアクセスするパスは次のような形式にします。つまり、コンテキスト名、レコードの検索条件をパスに入れます。最初のfilesは特に意味はなく、相対パスの最初のキーワードです。context-nameは、media-contextの値と同じでなければなりません。そのコンテキストのkeyキーに対する値、つまり主キーがpidであるなら、たとえば、field=valueは、pid=312 のような値になります。

context.php?media=files/context-name/field=value/filename.png

ここでもし、media-root-dirが /var/www/media であるなら、実際に

/var/www/media/files/context-name/pid=312/finename.png

という絶対パスの画像ファイルが存在する必要があります。コンテキストの定義には、レコード単位のアクセス権設定があれば、メディアに対するアクセス権の認証の確認を行い、ユーザを特定します。pid=312のレコードがそのユーザにアクセス権があるのかどうかを確認することによって、アクセスの可否を決めます。従って、適当にpid=316などとパスを変えても、その条件で検索されたレコードが他のユーザに対する権利があるものであれば、400番台のレスポンスを返してデータは返しません。認証の確認を行い、そのユーザに対するアクセス権がないものは出力しないという仕様によりアクセス権は定義した通りに適用されます。

pid=312を、age=45のようにできると言えばできますが、おそらく、そういうディレクトリは存在せず、漏洩にはならないでしょう。

ファイルのアップロードのコンポーネントは、コンテキスト名やレコード検索条件のパスを自動的に作成するようにも作られています。

とまあ、ここまで書いたところで、ソースに間違いを発見！　また、グループ名をフィールドに入れる場合はまだ実装していなかったことも思い出しました。今のところ、メディア関連処理は、開発している側で「必要の合った」状況しかうまく動かない可能性があります。ぜひとも、いろいろ試してフィードバックをください。

（まだ続く）

[IM]MediaAccessクラスと新たな拡張点

INTER-Mediatorはデータベースの内容を取り出し、Webページに展開し、場合によっては書き直したデータをデータベースに書き戻します。この一連のDBを中心としたデータの流れがあるのですが、Webアプリケーションではこれだけではすべてはまかなえません。HTMLでページを作るときは写真などの画像を別のファイルで供給します。このHTML外に実データが存在するようなものを「メディア」と呼ぶことにします。

メディアにはいろいろな種類があります。主要なものはIMGタグ要素で表示する画像、OBJECTタグなどで表示するFlashのコンテンツやビデオなど、そしてリンク先で得られるものとなるでしょうか。また、それぞれ、サーバ上にスタティックにあるものや、データベースのオブジェクト型フィールドに存在する場合もあります。WebページからこれらにアクセスするためのものがMediaAccessクラスです。概ね、次のような用途に使用方法は分類できます。

  • サーバ上にある画像ファイルを参照する
  • FileMakerのオブジェクトフィールドを参照する
  • データ生成を指定したクラスにさせる、生成結果を返す

ここで、単なる画像は普通にHTMLを書けばいいじゃないかと思うかもしれませんが、MediaAccessクラスを使う理由は、認証やアクセス権の設定との連携が可能になっているところです。

サーバ上にある画像ファイルを参照する

スタティックな画像で、認証が絡まない場合は、普通にIMGタグを記述します。また、画像ファイル名やパスがデータベースにある場合でも、必ずしもMediaAccessクラスは必要ないかもしれません。たとえば、あるテーブルのfilepathフィールドにファイル名が記録されているのなら、このようなIMGタグで表示できるでしょう。#srcにより、この要素のSRC属性にフィールドのデータが追加されます。

<img src=”figs/” class=”IM[context@filepath@#src]” />

ページの内容を認証しなければ参照できないようにしたとき、やはりページに埋め込んだ画像なども認証を経由したいと考えます。Webサーバレベルでの認証の場合は、ある意味、認証がない場合と概ね同じことで可能ですが、INTER-Mediatorの認証機能を使った場合、SRC要素がスタティックな画像を参照していれば、もしかしたら、認証しなくても画像だけは見えてしまうかもしれません。そんなことをしても大した情報流出にならないとも言えるのですが、ガードしたいものはガードするのが基本ですし、認証しているのに一部は誰でも見えるのは正しい運用ではありません。

そこで、IM_Entry関数の2つ目の引数（つまりオプション引数）に、’media-root-dir’というキーで、サーバ上にあるメディアファイルのフォルダへのルートからの絶対パスを指定しておきます。たとえば、

‘media-root-dir’ => ‘/var/www/images’,

となっていたとします。あるページファイルで使われている定義ファイルのパスがcontext.phpだったとします。すると、次の部分URLが、メディアを返します。ここで背後では、MediaAccessクラスが使われており、このクラスがメディアに対するプロキシになっているとも言えます。

context.php?media=ch1/shot345.png

たとえば、IMGタグのSRC属性に上記のURLを記述すれば、media-root-dirと合成して、「/var/www/images/ch1/shot345.png」というファイルをアクセスし、その内容を取り出して、適切なMIMEタイプのヘッダとともに出力をします。

前記のURLにある画像ファイル名「shot345.png」がフィールドpicfileにあるような場合には、ページファイルの要素には以下のような記述ができます。media=は決められたキーワードです。

<img src=”context.php?media=ch1/” class=”IM[table@picfile@#src]” />

このとき、定義ファイルで認証が必要な設定になっていると、SRC属性のURLからの取得時にMediaAccessクラス内部で、認証の確認を行います。ここで、一般の認証時に使っているクレデンシャルをそのまま使うことが実はできません。一般の認証では、1つのアクセスごとに異なるチャレンジデータを使うことで、認証の乗っ取りをしにくくしています。しかし、そのためにメディア処理ではその仕組みが使えません。なぜなら、メディアへのアクセスは並列的にブラウザから行うからです。

そこで、メディアアクセス時の認証のためだけのクレデンシャルを生成させるようにしています。たとえば、直前のimgタグ要素の場合、tableという名前のコンテキストからの取得となりますが、そのコンテキスト定義（IM_Entry関数の第1引数）の’authentication’キー内部の’media-handling’キーの値をtrueにします。すると、このコンテキストのデータを取得するときに、サーバ側からメディア用のクレデンシャルを出力します。

IMGタグ要素などから実際にメディア取得を定義ファイルに対して行うとき、media=があれば、MediaAccessクラスに処理をまかせます。そのとき、クレデンシャルがクッキーに記録されてサーバ側に到達し、それを発行したクレデンシャルと比較することで認証が通っているかどうかを判定します。つまり、コンテキストが得られるということは認証が通っているわけで、その信頼関係をもとに秘密の合い言葉をやりとりします。このクレデンシャルは繰り返し使われる可能性があります。クッキーに記録し、時間が来れば消去するようにはなっているものの、クレデンシャルを盗まれるのはそれだけでメディアアクセスを可能にしてしまうことになります。従って、HTTPS（SSL）でのサーバ運用は必須とも言えるでしょう。

普通のHTMLでMediaAccessを経由させる

Webページを作って画像を埋め込むと、<img src=”img/cover.jpg” /> などと記述します。これをMediaAccessクラスを使ってデータの取り出しを行いたいとしたら、ソースを全部変更しないといけないのかというとそうではありません。リダイレクトを使うことで、HTMLソースはそのままに、MediaAccessクラスを使うことができます。たとえば、.htaccessファイルを作り、たとえば次のような記述を作ります。

RedirectMatch img/(.+) http://host.name/myapp/context.php?media=$1

すると、<img src=”img/cover.jpg” /> は、<img src=”http://host.name/myapp/context.php?media=cover.jpg” /> と同じことになるわけです。

部分パスと絶対パス、それらを消したり追加したりといろいろ複雑にはなりますが、このスタティックなメディアを認証した上で表示できるようにしたのがMediaAccessの最初のインプリメントでした。

（この内容、続く）

[IM]ドラッグ&ドロップでファイルアップロード

ファイルのドラッグ&ドロップによるアップロードをINTER-Mediatorに実装しました。動作条件を整える方法はドキュメントを改めて書きますが、ページファイル上は、

class=”IM[testtable@vc1] IM_WIDGET[im_fileupload]”

のように、IM_WIDGETで、利用するコンポーネントを書くだけで、以下のムービーのようなドラッグ&ドロップによるファイルのアップロードができるようになっています。

dragdrop

[IM]PHP Ver.5.3 on OS Xで、APCを稼働させる方法

ファイルのアップロードをするときのプログレスバーを出す方法が「A Simple PHP Upload Progress Bar」というページに紹介されています。シンプルなのでやりやすそうと思われるのか、このサイトのスクリプトを単にコピーしただけのサイトなんかもあります（せめて出展くらい出すべきでしょう）。

当初、動かし方を紹介したサイトはないかと思って探したのが「Mac OS XのPHP 5.3にAPC(Alternative PHP Cache)をインストールする方法」というサイトでした。OS X Lion時代のものなのかこの通りでは動かなかったので、追加で必要な作業をまとめてみました。

プログレスバーを出す仕組みはちょっとややこしいのですが、ポイントの1つはPHPのAPC（Alternative PHP Cache）という機能を利用することです。残念ながら、PHP 5.3では生の状態ではこの機能は使えません。この機能を、OS X Moutain Lion + OS X Server Ver.2.2 + FileMaker Server 12という状況で使えるようにする方法を解説します。PHPは、Ver.5.3.13です。FileMaker Serverでない場合php.iniファイルの扱いが違ってくると思われます。

  1. Webサーバ稼働マシンに、Xcodeをインストールしてください。Xcode 4.6.2で以下の動作は確認しています。
  2. MacPortsをインストールします（インストール済みならもちろん何もしなくてもOKです）。まず、以下のコマンドでダウンロードします。以下のURLはアップデートにより変更されるかもしれません。
    curl -O https://distfiles.macports.org/MacPorts/MacPorts-2.1.3-10.8-MountainLion.pkg
  3. 以下のコマンドでインストーラを使ってMacPortsをインストールします。
    sudo installer -target / -pkg MacPorts-2.1.3-10.8-MountainLion.pkg
  4. 以下のコマンドで、autoconfiをインストールします。
    sudo port install autoconf
  5. 以下のコマンドで、pcreをインストールします。
    sudo port install pcre
  6. 以下のコマンドで、ヘッダファイルの1つをコンパイラが認識するディレクトリにコピーします（参考）。
    sudo cp /opt/local/include/pcre.h /usr/include
  7. APCのソースをダウンロードします。URLはアップデートによって変更があるかもしれません。
    curl -O http://pecl.php.net/get/APC-3.1.13.tgz
  8. アーカイブを展開します。
    tar zfvx APC-3.1.13.tgz
  9. カレントディレクトリに移動します。
    cd APC-3.1.13
  10. 以下のコマンドを入れます。
    phpize
  11. 次のように表示されます。warningがありますが、問題ない模様です。
    Configuring for:
    PHP Api Version: 20090626
    Zend Module Api No: 20090626
    Zend Extension Api No: 220090626
    configure.in:3: warning: prefer named diversions
    configure.in:3: warning: prefer named diversions
  12. おなじみの以下のコマンドでコンパイルします。
    make
    sudo make install
  13. 最後のコマンドで以下のようなメッセージが表示されます。1行目のパスをphp.iniファイルに記述するので、コピーしておくといいでしょう。
    Installing shared extensions: /usr/lib/php/extensions/no-debug-non-zts-20090626/
    Installing header files: /usr/include/php/
  14. php.iniファイルを変更します。以下のパスは、Mountain Lion + FMS12の場合です。使用する状況に合わせて正しいphp.iniファイルを編集します。もし、ない場合は、/etc/php.iniあたりに作成します。使用しているphp.iniファイルのパスを調べるには、phpinfo関数の出力を利用しましょう。
    sudo nano ‘/Library/FileMaker Server/Web Publishing/publishing-engine/php/mountain lion/lib/php.ini’
  15. php.iniファイルに以下の3行を追加します。これらの設定をいままで全く行っていないのなら、そのまま追加でかまいません。すでに設定がないかどうかは検索して確認しましょう。
    extension_dir=/usr/lib/php/extensions/no-debug-non-zts-20090626/
    extension=apc.so
    apc.rfc1867=on
  16. 以下のコマンドを入力して、Apacheに設定変更を適用させます。
    sudo apachectl graceful
  17. phpinfo関数の出力を見て、APCのカテゴリがあることと、apc.rfc1867の値が「On」になっていることを確認します。

ポイントとしては、APCのコンパイルのために、autoconf、pcreが必要である点です。また、APCの設定は既定値ではrfc1867はOffですので、設定ファイルで記述してオンにしておく必要があります。

なぜ、この記事のカテゴリにINTER-Mediatorがあるかというと、この仕組みをINTER-Mediatorに組み込んだからです。

スクリーンショット 2013-06-16 16.44.40