Captainでdocdiff以前、2つの文書の比較結果をカラーリングで示せるdocdiffのことをMavericks向けに書きました。その後、Yosemite向けにも書きました。Captain版です。/usr/binディレクトリがルートレスの機能により利用できなくなったので、docdiff自身も/usr/local/binに配備されるようになっています。それに合わせてドキュメントを書き直します。インストールは以前と同様にgemを使います。ファイルが存在すると、上書きしていいかを聞かれるので、yで上書きをしてしまいます。docdiffこれで、/usr/local/bin/docdiffがコマンドとして機能するようになります。そのほかのライブラリファイル群は正しい場所に入っているということで、気にしないで行きます。svnで使うには、パラメータの組み換えが必要です。そこで、/usr/local/binにdocdiffsvnを作ってそれを実行用にします。viでもemacsでもご自由なエディタで編集してください。/usr/local/binが作られていないのなら、mkdirコマンドで作ってください。/usr/local/bin/docdiffsvn中身はこのように書きます。$7そして、もちろん、アクセス権を設定しておきます。/usr/local/bin/docdiffsvnこうすれば、以下のようにsvnコマンドを打ち込むときに、docdiffを使って比較を行います。最後のパラメータはファイル名です。確認できます)が、/usr/local/binに通っていないなどの場合には、上記のパラメータの1つを「–diff-cmd=/usr/local/bin/docdiffdvn」のように指定します。Serverのアップデータが途中で止まる件は、こちらのページにまとめました。Server以外のサービスがhttpdを起動していても、やはりアップデートは進まず、そこで単なるシェルスクリプトによる繰り返しでhttpdのプロセスがなくなるまで待ってしまい、フリーズのようになってしまうという状況です。Ver.5を入れた状態で、一度Webサービスを起動し、その後停止した状態を見ることができたので、記録しておきます。Serverのプロセスを完全に落としても、以下のような2種類のhttpdのプロセスが残っています。-fオプションで指定されている設定ファイルを見れば、だいたいどんな機能のものなのかはわかります。httpdapache_serviceproxy.confは文字通りプロキシで、通常のWebサービスやWikiなどのサービスを受け付けてプロセスに流すような設定になっています。リバースプロキシでしょうか。Serviceだと思われます。いろいろな設定を追いかけると、/Applications/Server.app/Contents/ServerRoot/usr/libexec/scsdのプロセスがデーモンとして起動しているようで、それに対するWebインタフェースをApacheを使って稼働させている模様です。Daemon」とタイトルにあります。細かなことはわかりませんが、Webアプリケーションとして動くサービスとなっています。Serverのプロセスは起動しません。httpdを利用するサービスを全てなくすには、次のようなコマンドを打ち込みました。com.apple.service.ACSServer.plistServer.appはいろいろな機能がありますが、Webサービスはもちろん、事実上はWebアプリケーションであるカレンダーやWikiなどの機能を一切使わないのなら、上記のようにしてリバースプロキシとACSServerはなくてもおそらくは問題ないと思われます。DirectoryのMasterとして使う限りでは、上記のサービスを落とした状態でも利用できています。これらのサービスは単純に「落としても構わない」とは言い切れないですし、皆さん自身が判断してください。Serverを同時に使う場合には、Server.appのWebあるいはApacheを使っている一切の機能を使わないでおくようにするしかないと思います。ちなみに、聞くところによると、FileMaker社のサポートに問い合わせると「Server.appはアンインストールしろ」と言われるらしいです。それもどうかと思います。事実上、同じ会社の製品なんですけどね。Ver.5.3よりサポートのsourceキーVer.5.3より、コンテキスト定義(定義ファイルのIM_Entry関数の第一引数の配列の要素)に、sourceキーを入れるようになっています。データベース上のエンティティ名に関連するキーとしては、name、view、tableがありますが、それにsourceが加わります。データベースから読み出しを行うときのFROM句に指定されるビューやテーブルの名前は、viewキーがあればその値、なければnameキーの値が使われます。CREATE/UPDATE/DELETコマンドの対象は、tableキーの値で、それがなければnameキーが使わます。nameキーにテーブル名があれば、そのテーブル名を指定しての読み書きはviewとtableキーの指定はしなくてもできます。表示は何かのビューを使い、更新はそのビューではない特定のテーブルを指定したいような場合に対処できるように、viewとtableキーを用意しました。これだけでは問題があります。あるテーブルのあるレコードのあるフィールドが、ページ上の複数のリンクノードに展開された場合、それが例えば両方ともテキストフィールドであれば、一方の値を変えると、フィールド更新のためのサーバー通信が行われるとともに、クライアントサイドで同一フィールドの別リンクノードの値を更新できるようになっています。その時、何を手掛かりにして反映させるコンテキストを探しているかといえば、「viewないしはnameキーの値が同じだが異なるコンテキスト」です。住所録的なpeopleテーブルがあり、同一ページに全レコードの一覧と、その中で男性の一覧の両方があったとします。view=peopleとして適切なqueryキーの条件を与えればいいでしょう。すれば、同一テーブルから異なるコンテキストを生成して、内容が異なる一覧を1ページ内で生成できます。この時、男性の一覧にあるレコードは、必ず全員のレコードの一覧にもあります。どちらもviewキーがpeopleなので、男性のレコードの1つのフィールドを変更すると、対応する全員の一覧にあるレコードのフィールド値も更新されます。以下、この動作は「連動」と呼びます。同一のviewキーの値を持つコンテキスト同士なので、INTER-Mediatorにとっての手がかりがあります。SQLのレベルで、peopleをもとにしたビューeveryoneとsomeoneがあったとします。それらで表を作るとしたら、nameやviewを使うにしても、everyoneとsomeoneがそれぞれのコンテキストに登場はしますが、コンテキストの情報から各々が同一のpeopleテーブルから導出されていることはわかりません。なると、同一のレコードがそれぞれの一覧に見えていて、一方の値を変更したとしても、その変更結果を伝達する手がかりがなく、連動はできません。source=peopleと定義します。ページファイル側は、everyoneあるいはsomeoneをdata-im属性に利用する点は変わりありません。このsourceの設定により、2つのコンテキスト定義から得られるコンテキストは、同一のテーブルから来ているものということがINTER-Mediatorに伝わるので、同一フィールド値がユーザーインタフェース上で連動するようになります。Serverをどうしてもアンインストールしたい場合があります。インストーラが「先にアンインストールしないといけません」とメッセージを表示して、それ以上進めないとなると、仕方ありません。Serverのアンインストーラがあることを知っていれば、便利かもしれません。Serverという場所にも、アンインストーラがあります。14.0.4bのアップデータがリリースされました。このところ、アップデートが頻繁にありますが、いざアップデートしようとすると、最初の部分でフリーズしてしまうことがあります。フリーズと言っても、マウスカーソルがレインボーになってしまう現象です(画面ショットではレインボー状態は撮影できないので、以下の図は普通のポインタになっています)。ちなみに、この現象は、14.0.4bのアップデータに限らず、13のアップデータでも発生することがあります。いつまで経ってもこのまま進みません。アクティビティモニタを見ると、パッチアプリケーションのCPU稼働率が100%近くになっています。いうことは、本当にフリーズか、適切でない処理待ちをしていることが考えられます。そこで、ターミナルを起動して、プロセスを見てみます。パッチアプリケーションのプロセスには「Patch」という特徴的な文字があります。以下のコマンドで、プロセスIDは27530だとわかります。(以下、コマンドラインの出力が長いので折り返して見えるようにしておきますが、見づらい点はご容赦ください。Patch次に、このプロセスが別のプロセスを起動していないかをチェックします。0」なるプロセスがあります。最後の方の数値は起動ごとに違うものがつけられ、正常終了すると消されているファイルです。0これは/bin/shつまり引数をシェルスクリプトとして実行しているということです。catコマンドで、ファイルパスにスペースがあるのでダブルクォートで囲むなどの対処をして、中身を読んでみます。パッチアプリケーションは、このプロセスが終了するのを、おそらく単なるループで待っているためにフリーズするのでしょう。psコマンドである種のプロセスが存在するかどうかを2秒ごとにチェックし、調べているプロセスがなくなれば、スクリプトを終了します。2donewhileの行を見ると、psコマンドの結果に、fmserver_helperd、fmsib、fmslogtrimmer、fmxdbc_listener、fmsasedという文字列があるかを調べています。Serverの様々なプロセスが起動した状態なのかを調べています。httpdというプロセスまで存在するかを調べています。Serverを停止させて行うようにということで、FileMaker関連のプロセスがなくなっているという条件はまあいいでしょう。Serverのプロセスを事前に全部止めておくには、以下のコマンドでできます。/Library/LaunchDaemons/com.filemaker.fms.plistしかし、httpdとなると、何らかのきっかけで動かしてしまっているかもしれません。Serverあたりがhttpを使っていました。Server.appは、それらのプロセスをオフにしても、httpdの稼働を止めません。Serverのアップデータが動くようになりました。ちなみに、こうしたデーモンは、launchctlで起動しているので、killしてもすぐに再起動されます。そこで、/System/Library/LaunchDaemonsや、/Library/LaunchDaemonsに該当するファイルを探すわけですが、Server.appについては、/Applications/Server.app/Contents/ServerRoot以下の、/System/Library/LaunchDaemonsや、/Library/LaunchDaemonsにあるplistファイルを利用してデーモンを起動しています。これらのファイルから該当するhttpdを起動しているものを探して落とさないといけません。チェックすべきplistファイルのある場所は文中に記載しましたが、見づらいでしょうから以下に列挙します。/System/Library/LaunchDaemons/Library/LaunchDaemons/Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/Applications/Server.app/Contents/ServerRoot/Library/LaunchDaemonsしかし、一番の問題は、「httpdが起動していたらアップデートをしない」という仕様です。Server以外のhttpdの起動を許さないという仕様に問題があります。Server.app自体が色々なサービスでhttpdを使うのですが、80番ポートの取り合いになるのは確かにまずいでしょう。Serverのインストーラーは、自分自身のhttpdのポート番号を指定することで、他のサービスとの同居の可能性を探っています。Serverが起動したhttpd」ではなく、単に「名前がhttpd」のプロセスを探しているにすぎません。Server以外でhttpdを使いっていればトラブルが発生する仕様なのです。これでは仕様の上で矛盾があると言えるでしょう。Serverしか動かさないという前提でもそれはそれで構わないと思いますが、だったら、LinuxのVMで動かすようにして欲しいというのが総意ではないでしょうか。XとWindowsで、アプリケーションみたいなインストーラでセットアップするサーバーはもはや古さを感じます。現在のシステム構築環境にマッチしない仕様を早く改善しないと、先頭集団からさらに引き離されるでしょう。