[IM] コンテキストを実体化する改良

4月からずっと、ちょっとずつ、INTER-Mediatorを改良してきました。内部の構造については別記事にまとめる予定です。

INTER-Mediatorでは「コンテキスト」という概念を、データソースつまりデータベースから得られる結果に当てはめています。単にテーブルということではなく、テーブルから得られた列構造を持つレコードの集合を「コンテキスト」として位置づけています。たとえば、住所録から「会社関係」「親戚関係」といった分類をして取り出すとすると、それは住所録テーブルから得られるものではありますが、列構造を持つレコード群が、意味を持ちます。そうした意味付けされてデータベースから取り出された結果をコンテキストと読んでいます。システムのアーキテクチャとして、DCI(Data, Context and Interaction)という手法が提唱されていたりしますが、そこでのコンテキストと同じ意味です。この考え方は別に新しいものではなく、FileMakerなどでも見られる概念です。ただ、コンテキストと抽象的に説明すると分かりにくくなり、一方で「検索条件を適用したテーブルアクセス結果」というとあまりに陳腐な感じになってしまい、とらえどころのない用語でもあります。

これまでのINTER-Mediatorでは、コンテキストは「定義する」ものでした。定義ファイル(.phpファイル)で、どのテーブルあるいはビューであり、主キーは何で、検索条件やソート条件は何でと言ったいちれんの設定を「コンテキスト」と読んでいました、この定義ファイルにあるコンテキストに名前をつけて、その名前をページファイル(.htmlファイル)側から参照します。シンプルに説明するときには、ページファイルにテーブル名とフィールド名を書けば、その要素とフィールドがバインドして、データを表示し修正すれば書き直しができるという言い方をします。しかしながら、正確には、コンテキストとして意味付けされた一連の列構造を持つレコード群を、ページ上に展開するということです。従って、同じテーブルから一覧表を作る場合と、単一のレコードを示す場合では、目的が違うので、「異なるコンテキストを要求している」と見なして、定義ファイルに別々のコンテキストを記述するというのが原則と考えています。

定義ファイルに記述した、コンテキストの仕様に相当する者は、「コンテキスト定義」と呼ぶ事にします。

一方、このコンテキストに従った動作をするために、内部的には明確な形でオブジェクトを作っていませんでしたが、それを実現しました。内部的なコンテキストは、クライアントのブラウザ内でオブジェクトとして存在し、一つの見方はデータベースの内容のプロキシです。データベースの内容は、コンテキストのオブジェクト内に「再現」されていると考えてください。加えて、コンテキスト内のデータと、ページ上の要素あるいはその属性との間でのバインドが実現されており、たとえばテキストフィールドでデータを修正すれば、コンテキストオブジェクトの関連したデータも更新されることを自動的に行えるようにしました。

ただし、ここで、内部的なコンテキストは、JavaScriptからタッチすることは可能で、プログラマに対して解放されているとも言えますが、一方で、INTER-Mediatorはそうした手続き的なプログラミングを必要としなくても多くの目的をまかなえるように作りたいことがあります。本来、こうしたバインドの実装は、厳密な意味ではオブザーバブルな実装が必要になりますが、まずは、メソッドベースでの実装を行うことにしました。従って、オブザーバとオブザーバブルは明確になっていない実装になり、そうした仕組みの拡張については今後の課題と考えています。現状は、コンテキストのオブジェクトのメソッドを使って値を設定すれば、同じレコードの同じフィールドの結果を表示している他の要素にも変更結果が伝わるという状態にしてあり、スタティックな意味でオブザーバブルになっています。

こうした内部的にコンテキストを持つことに対して、データベースと連動しない「ローカルコンテキスト」も実装しました。ローカルコンテキストは、ターゲット指定でのコンテキスト名に「_」を使い、フィールド名は自由に使います。次のような2つのテキストフィールドを用意します。そして、INTERMediator.construct(true); を実行します。すると、一方に入力してタブキーでchangeイベントを発生させると、他方のテキストフィルドに入力したデータがコピーされます。連動させるためのプログラムの作成は必要ありません。

<input id="tf1" type="text" data-im="_@feeling" />
<input id="tf2" type="text" data-im="_@feeling" />

このローカルコンテキストは、FileMakerで言えば、グローバルフィールドのようなものです。また、ターゲット指定からそのテキストフィールドの値を取り出すメソッドも用意しているので、他の機能との統合を行うときにも気軽に利用できます。以下のように、IMLibLocalContextで参照されるオブジェクトでローカルコンテキストは実現されており、getValueメソッドで引数にターゲット指定のフィールド名のみを指定することで、テキストフィールドの値を取り出すことができます。

var inputValue = IMLibLocalContext.getValue("feeling");

ローカルコンテキストはクッキーに記録されるような動作を考えました。たとえば、検索条件をテキストフィールドに入れていれば、別のページから戻って来たときにも元の検索条件を覚えているような動作を自動化させたいからです。ただし、この動作については、おそらくさまざまな要求が実際の開発では発生すると思われるので、ぜひとも使ってみた意見をいただきたいです。

ページナビゲーションの「更新」ボタンをクリックすると、このローカルコンテキストのクッキーによるキャッシュをクリアします。

[IM]ドキュメントの方針

INTER-Mediatorについて、ドキュメントをもっと充実させるべきという声は常に聞かれますし、その通りだと思います。とは言え、いかに効率的に作るかを考えないと、本体以上に破綻するかもしれません。ドキュメントはテストドリブンでの制作はできないのですから。そういうわけで、当面の方針をきちんと作り、そして書いて、実行することにします。

以前は、最終的には「パターン」への落とし込みが重要ではないかと考えていましたが、パターンとして落とし込むには、知の集約が必要であり、一定期間に少人数でできることではありません。既存のパターンを使うとしても同様です。

現在考えているのは、プラクティスの充実です。たぶん、サンプルや例題というのもプラクティスの一つなのでしょうけど、サンプルは説明がしづらいとか、デバッグ用に無意味な組み合わせの機能があるとか、プラットフォームを初めて見る人には辛いものです。その意味で「例題」なのですが、fluent 2014に言ったときにEmber.jsのセッションで言われていたのは「フレームワークはコミュニティのプラクティスを取り込まないといけない」というところで、ピンと来ました。例題の題材は、コミュニティにあるものを採用しないといけないということです。機能説明になっては本末転倒になるというところでしょうか。そういうわけで、プラクティスという言葉がきっかけで、やるべきことが整理された気がします。

ソフトウエアプラットフォームの開設のための文書にどのようなタイプのものがあるかを考えてみました。マーケティング的なことを抜きにして、利用者(通常は開発者)に対するコミュニケーションのためには次の4つがあるのではないかということです。

  • 仕様の記述:当然必要、網羅性が求められる
  • チュートリアル:手を動かして学習、INTER-Mediatorでは有償コンテンツとして用意
  • プラクティス:これから充実させたい
  • パターン:抽象度の高いノウハウ

今は、プラクティスを充実させる段階であり、それが一段落してからパターンに進むのが手法としてはステップを踏む感じがするのです。

プラクティスとして作成する予定のテーマは次の通りです。もちろん、みなさんからの要望やアドバイスを期待します。とは言え、あまり重いものはプラクティスではなく、実システムになってしまい、微妙なところです。以下の5、6はえらく長くなりそうですし、むしろ上級向けのチュートリアルのテーマではないかとも思います。

  1. 検索をしてその結果を一覧表示する
  2. 一覧表示と詳細表示を行き来する
  3. アンケートなどの入力のみのページ
  4. 伝票形式のページを作成する
  5. 会員制サイト(ヘビーか?)
  6. カート(不要か?)

一方、「こういう作りのページを簡単に作れることは意図していない」という、ある意味のアンチプラクティスも記述が必要と考えています。たとえば、こんなテーマです。とりあえず、1つだけです。

  1. 入力フォームの後の確認ページが不要な理由

ということで、プランを立てないと前に進めない気がするので、とりあえず、書いておこうと思います。

[IM]ローカルコンテキストの利用方法

INTER-Mediatorでは、タグのdata-im属性に、「テーブル名@フィールド名」の形式で記述するターゲット指定により、そのタグ要素がデータベースのフィールドにバインドされて、データベースから読み込んだデータを表示し、フォーム用のコンポーネントであればユーザによる変更結果をデータベースに書き戻す事が自動的に設定されます。しかしながら、データベースとは関係ない記憶領域があると何かと便利です。言い換えれば、データベースにしか保持できないとなると設計の順内製がそがれます。そこで、クライアントサイドの計算フィールドを実装し、さらにローカルコンテキストという機能を実装しました。

ローカルコンテキストの利用方法

ローカルコンテキストとは、データベースと連動していない記憶領域で、テーブル名は一律に「_」を使います。フィールド名は任意の変数名でかまいません。Sample_searchでは、type属性がtextのINPUTタグに対して、<input type=”text” data-im=”_@placeCondition”/> という設定を行いました。placeConditionがローカルコンテキスト内の名前です。この記述をするだけで、テキストフィールドに一度入力したデータは、ページを更新しても必ず再現されます。イメージとしてはどこかに記録されて、それが必要に応じて自動的に復活すると考えてください。保存場所はクッキーの中です。

通常のコンテキストは、1つのコンテキストに複数のレコードがあり、そのレコード内にフィールドがあるという構造です。ローカルコンテキストは「レコード」という構造がありません。コンテキスト名も常に決まっているので、実質的にはシンプルなキーバリューストアと同一です。一般のコンテキストは、エンクロージャーとリピーターという繰り返しを誘発する階層構造をベースにしますが、ローカルコンテキストは1ページごとに1つずつ持っており、どこにどう書いてもかまいません。同一のフィールド名のタグ要素が複数あれば、それらでの編集結果も連動します。

ローカルコンテキストへの直接アクセス

テキストフィールドがある場合、そこに入力した値を取り出すのは、通常はgetElementById等を使ってノードを参照します。一方、ローカルコンテキストを利用したテキストフィールドなら、ローカルコンテキストから値を取り出すほうが確実です。たとえば、前述のinputタグ要素の場合、

var c1 = IMLibLocalContext.getValue("placeCondition");

とすれば、テキストフィールドに入れた値を取得できます。なお、テキストフィールドをローカルコンテキストに反映するタイミングは、フォーカスがはずれたとき、つまりonchangeイベントで行っています。もし意図的に値をローカルコンテキストに記録するには、

IMLibLocalContext.setValue("placeCondition", value);

と記述します。

計算式の中に、ローカルコンテキストのリンクノードを参照する記述「_@field」などがあった場合、他のコンテキストにあるフィールドと同様なルートで検索します。つまり、同一のエンクロージャーを探し、なければ上位のエンクロージャを探してその子孫のノードを検索します。

ローカルコンテキストは、URLにひもづくクッキーに記録し、とりあえず、期限は1年にしてみました。いろいろなタイミングで自動的にクッキーに記録し、一方でクッキーから取り出すので、ほぼ、そういうことは意識しなくてもいいのですが、この後に説明する件で、一部のブラウザで書き込みを明示的に記述しないといけない場合があります。

連動するプロパティ

こうして、ローカルコンテキストが稼働しているので、一部のプロパティについては、ローカルコンテキストで保持することにしました。

INTERMediator.startFrom = 0;
INTERMediator.additionalCondition = {};
INTERMediator.additionalSortKey = {};

これらは、前から順番に、検索結果の何レコード目から表示するのか、追加の検索条件、追加のソート条件となります。たとえば、ユーザインタフェースを使って、追加の検索条件を与えると、それがローカルコンテキストに記録されて、事実上永続化されます。検索条件は、随時適用されるので、検索条件を与えるといつまでもその条件が適用されるようになります。

これらの動作に関連する情報は、以下のキー名を使ってローカルコンテキストに保存しています。なお、_im_で始まるキーは、システム予約としておきます。今後、こうした記録が増える可能性があります。

_im_startFrom
_im_additionalCondition
_im_additionalSortKey

たとえば、検索条件を特定のコンテキスト「context」に対して設定する場合、例えば、次のように記述するのは、従来と変わりありません。

INTERMediator.additionalCondition['context'] = {
    field: 'zipcode',
    operator: 'LIKE',
    value: IMLibLocalContext.getValue("criteria") + '%'
};

このとき、背後では、ローカルコンテキストに右辺のオブジェクトを記録し、さらにクッキーへの記録まで同時に行います。

Internet Explorer 8での対処

Ineternet Explorer Ver.8のみ、プロパティに記録したデータを自動的に永続化する事ができません。IE8の場合のみ、INTERMediatorオブジェクトのstartFrom、additionalCondition、additionalSortKeyプロパティに設定した直後に、

IMLibLocalContext.archive();

という呼び出しを入れて、ローカルコンテキストに反映しつつ、クッキーへの保存を行うようにします。IE9以降や、その他のブラウザではこの呼び出しはなくてもかまいませんが、あっても問題はありません。ただし、同じ作業を複数回行うことになるので、効率は低下します。INTER-Mediatorの内部ではIEやそのバージョンの把握を行っているので、たとえば、次のように記述すれば、IE8の場合だけ、前述のメソッド呼び出しが実装できます。

if (INTERMediator.isIE && INTERMediator.ieVersion < 9) {
    IMLibLocalContext.archive();
}

OS X Mavericksとdocdiff 0.5.0

単語単位での2つのファイルの相違点をカラー表示してくれるdocdiffは非常に重宝します。wdiffだと日本語がうまくいかないということで、rubyで作られているdocdiffを使っていますが、Mavericksにアップデートしたら動かなくなるとか、インストーラが以前はあったけど現在のシステムで動かないといろいろあり、困ってしまいました。ソースから動かす方法を、ほとんど自分の備忘録として書いておきます。

まず、githubにあるdocdiffのサイトから、ソース一式を「Download ZIP」ボタンでダウンロードします。Makeとかあるのだけど、Ver.1.8 onlyとあります。MavericksはVer.2.0がデフォルトです。それで、最低限の作業を考えた結果このような流れでできることが分かりました。ダウンロードしたファイルを展開したdocdiff-masterフォルダを基準に説明します。

  1. bin/docdiffを/usr/local/binにコピーする(あるいは/usr/binにコピー)
  2. libにある1フォルダ3ファイルを、Rubyのライブラリフォルダにコピーする

ライブラリフォルダとは、以下のパスになります。

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0

これで、1でコピーした先にパスが通っていれば、docdiffコマンドとして稼働します。つまり、

docdiff --format=tty file1 file2

とすれば、カラーリングした結果でファイルの違いを文字単位で表示します。

なお、これをsvn上で使いたいので、次のようなことをしています。まず、上記、ダウンロードしたdocdiffファイルを/usr/local/binにコピーしたとして、/usr/binに以下のようなスクリプト「docdiff」を作ります。もちろん、実行権限を与えておきます。

#/bin/sh
/usr/local/bin/docdiff --format=tty $6 $7

こうすれば、svnでのコマンドで

svn diff -r PREV --diff-cmd=/usr/bin/docdiff file

とすることで、たとえば、こんな感じに見えます。このコマンドだと、現在のファイルとRevision 15のファイルを比べていて、赤は消えたもの、青は追加されたものです。黄色の代わりに緑になるという感じです。

shot0180

ブログを整理しました

会社員時代はブログは書いていなかったのですが、独立してしばらくしてから、だいたい2010年あたりからブログを書いていました。最初は、Mac OS X Server Snow LeopardのWikiを使っていたのですが、Lionへはうまく移行できたものの、その後に失敗(アカウントを消した)とか、Mountain Lionのときに変な場所に移行したとか、いろいろあって、2013年2月からはWord Pressで運用しています。

さらに、Mavericksに移行しようとして決定的な失敗をしてしまい(とほほ)。「過去のブログを見るだけ」のWebサーバとしても機能しなくなりました。FileMaker ServerをWebで動かしているのでどっちに転んでもやっぱり両方の用途に使うのはかなりしんどいです。ということで、日曜日に過去のブログをサルベージしました。PostgreSQLのデータベースからダンプして、手作業も入りながらのコピペで移行しました。INTER-Mediatorのブログは思考のプロセスを思い出すのに必要なこともあり、この関連記事は全部以降しました。他に、受けたとか、今でも意味があるというのはみんな移行しましたが、OS X Server関連はもういいかということで省略としました。

そんなわけで、過去の記事が突然、Twitter公開とかでよみがえってしまってすみませんでした。これで、ここ何年かの消えた記事が復活して一安心です。

[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等でのエンコードは行いません。

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

Internet Explorer 8にまた苦しめられる

Web系のお仲間の皆さんも同様にいつも苦しめられていると思われるIE8ですが、ここ最近にあったいくつかのはまりポイントを自分の備忘録としてもまとめておきます。まあ、あと数年はIE8からは逃れられないということで。

  • jQuery 2.0を入れたら動かない(対応ブラウザからはずれている)。慌てて1.10に戻す
  • JavaScriptではObject.keysという記述が使えない
  • 要素のid名と同一のグローバル変数が作られる

特に最後のは苦労しました。メッセージを見る限りは、「オブジェクトでサポートされていないプロパティまたはメソッドです。」と出ます。プログラムはこんな感じ。INPUTタグ要素で、idが「yourname」になっていると思ってください。

yourname = document.getElementById("yourname").value;

まさかgetElementByIdが使えないのかと思ったら、使えます。他の箇所では動いている。valueがない訳は絶対にない。当然右辺を疑うわけですが、必死に検索した結果、問題は左辺でした。つまり、以下の条件が満たされると発生されるトラブルだったのです。

  • IE8でJavaScriptでプログラムを組む
  • ページ内の要素のid属性と同一の変数を、何も定義しないでJavaScript側で使う

どうやら、IE8は、id属性と同一名のグローバル変数を勝手に定義するようです。上記のプログラムは、つまり、勝手に定義しているyourname変数が何らかのオブジェクトを記録していて、そのオブジェクトが書き換えに対応していないためにエラーが出ていると思っていいようです。

対処法は「var yourname」のように頭にvarを付けるか、ページにリンクされたjsファイル等でグローバルとして「var yourname;」のように変数定義することで回避できます。自分自身のグローバルでも、同一名称の変数は後から定義した方のストレージが有効になるので、IEが勝手に作るグローバル変数は無視されるようになるということです。つまり、変数定義を必ずしろというプラクティスをしていれば、エラーに合わないのですが、こう書いてしまったらエラーになってしまうよということですね。

講義でのペアプログラミングの使いどころ

今年度のJavaの講義では、ペアプログラミングを導入して、演習に取り組む時間を比較的多く取ってみました。そして、必須課題として、その感想を聞きましたが、総合的に良かったあるいはどちらでもないというのが33%、残りの67%は「よくなかった」という感想でした。理由は知らない相手や、理解度の違う相手との演習は思った以上に神経を使うということで、それほど効果的ではないという感想でした。全員に利点とデメリットも書かせましたが、ほぼ、同じような答えで、よくなかったと感じた人たちも利点がある点は理解しています。なんかうっとおしからいやだ…ということではなく、きちんと理由を考えさせた上で、総合評価させています。

1つあるのは、友達関係にない相手と組ませることになるのは、確かに大変かもしれません。とは言え、講義運用上どうしてもそれは必要になります。レベルが違う人と組むのは、それなりに悪い事ではないと思うのですが、「課題を行う」というまじめな学生達のゴールにとっては足かせと感じたのかもしれません。ただ、他人がどう考えるのかということが理解できる点は良かった点として挙げられていました。

今年度は比較的多くペアプロをやりましたが、来年度は、限定的にやろうかと思っています。アジャイルのプラクティスは、形のないソフトウエアを作るプロセスを進化させるいちばん有力な手法だと感じています。ただ、プログラミングの初心者でできそうなプラクティスはペアプロではないかというのが当初の考えです。しかしながら、まずは基礎力をつけてレベルを比較的揃えてからやるというのが重要なようです。また、講義全体の進行度合いとはある程度独立した課題を与えるひつ模様もあると感じました。つまり、講義の流れは追えている学生もいれば、遅れている学生もいるということで、そこで一様でなくなる可能性があるということです。来年度は、「ペアプロの日」つまり、ペアプロで課題だけをやる日を1回か2回確保しようと思っています。

ようするにペアプロが機能する状況を、講師が作った上で、させないといけないという当たり前の結論なのですが、現場の開発と教育の現場の違いはまさにそういうところではないかと感じました。

FileMaker Server 13とOS X ServerのWeb

FileMaker Server 13と、OS X ServerのWebサービスの共存は基本的にはできません。となると、OS X ServerのWikiとかはあきらめるか、設定ファイルをあれこれということになりますが、ともかくいったんあきらめてFMS13を入れるといういう場合、80番と443番ポートが使われているのでインストールができないというメッセージに出くわします。

Webサービスを止めても、Wikiを止めてもまだそのメッセージが出ます。コマンドで落としてインストールしていたりしましたが、再起動したらやっぱりFMS側がだめになってどうしようもありません。徹底究明した結果、なんと、WebDAVが動いていました。ファイル共有でWebDAVを利用すると、Webサービスがオフでも、80番ポートを使ったhttpdが動いています。

では、WebDAVを全部オフにして再起動してみます。それでも、httpdは動いています。どうやら一度オンにすると、テコでも動くようです。そこで、すべての共有ポイントでWebDAVがオフになっていることを確認して、以下のコマンドを入れれば、おそらくすべてのプロセスが止まります。念のため再起動してもhttpdが動かないことも確認します。

sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist

httpdが動いているかどうかを確認するには、以下のコマンドを入れてください。このコマンドで80番や443番ポートをLISTENしているプロセスが見えるはずです。このコマンドで何も出てこなくなれば、OS X ServerのHTTPDのサービスはすべて止まった事になります。

sudo lsof -i | grep httpd

こうしてFMSをセットアップしますが、Web関連のフォルダが大きく変わります。/Library/FileMaker Server/HTTPServer以下に必要なファイルがあります。Webの公開フォルダはHTTPServer/htdocsにあります。ここにファイルを起きますが、httpdプロセスはfmserverアカウントで稼働していることに注意が必要です。_wwwではありません。

設定ファイルは、HTTPServer/conf/httpd.confがまず読み込まれます。設定を変更するには、まずこのファイルから確認しましょう。OS X Serverのよう「全部バーチャルホスト」的な設定ではなく、デフォルトのドキュメントエリアを使います。以下はその設定例です、ほとんど自分のメモみたいなもんです(笑)。赤字は追加記述です。.htaccess等を稼働させるには、AllowOverrideの指定が必要です。PHPはすでに動いていますが、既定のファイルはindex.htmlだけです。なので、DirectoryIndexの指定も行います。もちろん、必要に応じて設定は加えます。

<Directory "${HTTP_ROOT}/htdocs">
     Options All -Indexes -ExecCGI -Includes
     AllowOverride All
     Order allow,deny
     Allow from all
 </Directory>

DirectoryIndex index.php index.html

ここで、設定ファイルを変更したらapachectl gracefulと思いたいところですが、普通にこのコマンドを入れても、OS X ServerのApacheの状況を変えようとするだけで、FMSが起動しているhttpdには適用されません。FMSのhttpdのスタート、ストップ、そして設定の反映は、次のようなコマンドを打ち込みます。

sudo touch /Library/FileMaker\ Server/HTTPServer/start
sudo touch /Library/FileMaker\ Server/HTTPServer/stop
sudo touch /Library/FileMaker\ Server/HTTPServer/graceful

もちろん、フルパスでなくてもかまいません。これらのファイルの修正日を更新するのです。こうすると、/S/L/LaunchDaemonsにあるcom.filemaker.[start|stop|graceful].plistによるファイル修正の監視が行われていて、FMSのhttpdデーモンの処理を行います。これらのlaunchdファイルを見れば分かりますが、/Library/FileMaker Server/HTTPServer/bin/httpdctlというコマンドが用意されていて、このコマンドを経由して、httpdをコントロールするようです。

そういうわけで、設定ファイルを変えてはsudo touch gracefulとやればいいということです。日曜日はOS X ServerとFileMaker Serverのメンテで終わってしまった…。

FileMaker Server 13の管理コンソールが別のコンピュータから接続できない理由

*** 内容が少し違っていたので、修正しました。2013/20/50 ***

FileMaker Server 13になって、管理コンソールが純粋なWebアプリになり、クライアント側ではJavaのバージョンなどは気にしなくてもいいようになりました。これは非常に便利です。サーバ側はTomcatなので相変わらずJavaですが、そちらは管理された環境なので、利用者はJavaのバージョン等は気にしなくていいようになりました。

一方、FMS13では、16000ポートがHTTPSで、16001ポートがHTTPでの接続ができるようになっています。管理コンソールへの接続条件は、インストールしたサーバでは「https://localhost:16000」「http://localhost:16001」で接続ができます。FMS12のときと、HTTPSとHTTPが入れ替わっています。また、他のコンピュータから「https://ホスト名:16000」での接続は可能ですが、「http://ホスト名:16001」の接続はできません。

なぜか? パケットをキャプチャしてみました。コンソールへのログインをするときに、クライアントからサーバへのリクエストをダンプしてみました。以下の最初の数行の固まりはヘッダです(クッキーは省略しています)。そして、行をあけて1行だけあるのがボディです。

POST /admin-console/APP/connector/3/304/login HTTP/1.1
Host: homeserver.msyk.net:16001
Connection: keep-alive
Content-Length: 29
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://homeserver.msyk.net:16001
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://homeserver.msyk.net:16001/admin-console/APP/connector/3/304/login
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ja,en-US;q=0.8,en;q=0.6
Cookie: JSESSIONID=6706...888

username=admin&password=abcdef

わお!ユーザ名とパスワードがそのまま流れています(もちろんabcedfは置き換えてあり、abcdefの代わりに本物のパスワードが見えました)。ハッシュですらありません! つまり、localhostからの接続でないと、通信経路上での盗聴で簡単にログインのアカウントとパスワードを取り出せてしまうのです。サーバのコンピュータからしかログインできなくなっているのはそのためでしょう。同一コンピュータ内なら、パスワードをそのまま流しても、問題になることはないと言えます。しかし、他のコンピュータから接続するという状況では明らかに問題です。すなわち絶対に通信そのものを暗号化しないと危険なので、HTTPSでの接続しかできなくなっています。

それでも、どうしても、他のコンピュータから16001ポートを使って管理コンソールに接続したいという方は、以下のファイルを修正してください。OS Xでは必要に応じてsudoで作業をしましょう。Windowsは、多分、「FileMaker Server」がProgram Filesにあると思うので、それ以下は同じと思います。

/Library/FileMaker Server/Admin/admin-master-tomcat/conf/server.xml

このファイルの最初に以下の部分があります。開いて「16001」を検索します。このポート番号はここだけです。最後の方の下線、赤字の部分を削除してファイルを保存してください。

<Connector port="16001" protocol="HTTP/1.1" maxHttpHeaderSize="8192" maxThreads="150"
 minSpareThreads="5" maxSpareThreads="75" enableLookups="false"
 redirectPort="8443" acceptCount="100" connectionTimeout="20000"
 disableUploadTimeout="true" address="127.0.0.1" URIEncoding="UTF-8"/>

この後、サーバの再起動をしますが、管理コンソール自体を再起動させます。うまく行かない場合にはコンピュータの再起動を行いましょう。そうすれば「http://ホスト名:16001」で管理コンソールに接続できます。ホスト名はIPアドレスでももちろんかまいません。

くれぐれも、この状態で、インターネット経由での接続は細心の注意を払ってください。パスワードがバレない限りは他人にアクセスはできませんが、現状では容易にバレてしまうような通信方法です。安心な方法は、FMS13を稼働させているコンピュータにVPNで接続することですが、一手間増えるならVNCでサーバにログインしてページを開くのとあまり変わらないですよね。したがって、こうした変更はしないで、現状通り使うのが安全です。あるいは、自己署名証明書である点が微妙ですが、16000ポートで接続しましょう。いくら暗号化されているとは言え改善を期待したいですが、次のバージョン以降なのでしょうか。