Category Archives: Uncategorized

FileMakerデータベースをOAuth認証で利用する

FileMaker 16の大きな機能アップの1つは、OAuth対応だ。GoogleのアカウントでFieMakerデータベースへのログイン認証ができるようになったのである。OAuthの大きな特徴は、1度パスワードを入れれば、その後に認証されたことが異なるサービスに対しても継続されることである。これは「パスワードを覚えていて、その都度送り出す」のではなく、認証した事実を別のサーバーにうまく伝達を行うことで、サービスをまたいだ認証の継続を実現している。パスワードのやりとりは最初のログイン時だけになるので、概してより安全な認証方法と言うべきだろう。FileMakerがOAuthにどのように対応したのかを、データベースログインをGoogleアカウントでログインできるようにするための設定を通じて説明する。

FileMakerデータベースへのログイン

FileMakerデータベースをFileMaker Serverで公開したとする。以下はINTER-MediatorのサンプルデータベースをプライベートネットワークにあるFileMaker Server 16で公開した結果を示す。上記のサンプルで改変した点は本文途中で示す。

公開したデータベースをFileMaker Pro/Advancedで開こうとすると、次のようなダイアログボックスが表示され、そして、アカウント名とパスワードを入力して、「サインイン」ボタンをクリックする。

ここで、FileMaker Server 16で、Googleを認証サーバーとして利用するような設定を行い、加えてデータベース側にそのGoogleのアカウントを追加設定すると、サインインのダイアログボックスがでは以下のように、「Google」のボタンが下部に追加される。このダイアログボックスが表示された時には、「Google」ボタンをクリックするだけでOKである。アカウント名やパスワードのテキストフィールドに、Googleのユーザー名やパスワードを入力することは不要である。

そうすると、デフォルトのブラウザが開き、Googleアカウントのログインの「アカウントの選択」の画面になる。ちなみに筆者が複数のGoogleアカウントでログインをしているのでアカウントの選択になるのだが、アカウントが単独の場合には何も出ないかもしれない。あるいはまだログインをしていないのなら、さらにパスワードの入力や場合によってはアカウントの入力も必要だろう。何れにしても、サインインのダイアログボックスで「Google」ボタンをクリックすると、Webブラウザを利用してGoogleでの認証結果を確認する。その時に、Googleのアカウントでログインしていなければログインをするが、ログインして入ればそのまま処理が継続される。

ログインが成功するか、ログインされて入れば、次の図のようなダイアログボックスが表示される。これは認証が成功したことを示しており、データベースを利用するには「FileMaker Pro Advancedを開く」(もちろん、Proの場合もある)ボタンをクリックする。なお、「開かない」にしたら、何もしないので、ここでは必ず「〜を開く」ボタンをクリックする必要がある。

そうすれば、データベースが開かれる。この時、Get(アカウント名)等の取得関数の結果もデータビューアで示したが、ログインしているGoogleアカウントのアカウント名がそのまま見えている。

以上のように全てがうまく設定された状態だと、ログインパネルで、Googleボタンをクリックすることで、パスワードをその場では入力することなく、自動的にデータベースを開き、データベースではGoogleアカウントで誰が使っているのかを識別できる状態になる。あらかじめGoogleアカウントでログインしていれば、何も追加作業は必要ないか、あるいはアカウントの選択の作業が必要になる。 ログインしていなければ、Webブラウザでログイン作業を行う。

OAuthで利用するためのデータベース

FileMakerのデータベースは、ProないしはAdvancedで管理者でログインをして、「ファイル」メニューの「管理」にある「セキュリティ」を選択する。認証を行なったのちに、アカウントの追加をまずは行う。「アカウントの認証方法」の部分には、「Amazon」「Google」「Microsoft Asure AD」の3つの選択肢が増えている。利用するOAuthサービスを選択した上で、ユーザー名は、そのサービスのユーザー名をそのまま指定する。このように、Googleであれば、Googleのユーザー名を指定したアカウントを作っておかなければならない。もし、作っていない場合は、たとえGoogle側のログインが成功していてもデータベースの利用はできなくなっている。一見すると、他のこの種のサービスのように自由にログインできないのは不便と思われるかもしれないが、登録しないと利用できないようにするのがセキュリティ確保の基本である。誰でもログインできる状態というのは、多くのFileMakerデータベースには望まれていない。

アカウントが実際に利用できるようになるには、「アクセス権セット」を選択する必要がある。ここでは既定の「データ入力のみ」を選択しているが、もちろん、このアクセス権セットに、fmappつまり「FileMakerネットワークによるデータベースアクセス」の拡張アクセス権が設定されている必要がある。これは従来からと同様で、FileMaker Serverで公開するデータベースでは必須の設定である。なお、INTER-Mediatorのサンプルデータベースでは、「データ入力のみ」のアクセス権セットには、fmappはチェックが入っていないので、サンプルをそのまま使う場合には注意していただきたい。

アカウントの一覧には、Googleがタイプの項目が増えており、アカウントの列ではGoogleのユーザー名がそのまま見えている。

FileMaker Serverでの設定

FileMakerのAdmin Consoleで作業をする。ログイン後、左側で「データベースサーバー」を選択し、右側で「セキュリティ」のタブを選択する。そこにあるポップアップメニューで「FileMakerと外部サーバーアカウント」を選択する。すると、Amazon、Google、Microsoftの3つの項目が表示されるので、右側のギアのアイコンをクリックして、作業を進める。ここでは、Googleを例にとって説明する。

Googleのギアアイコンをクリックすると、次のようなパネルが表示される。結果的には、ここでGoogle側で得られた2つのコードを入力することになるが、それは、この後に説明する。簡単なようで難しい問題もあるので、それも併せてこの後に説明する。ともかく、2つのコードが得られたら、「保存」ボタンをクリックする。

ちなみに、Microsoftを選択すると、少し違うダイアログボックスが表示される。これらはサービスごとに得られるデータが少しずつ違うと言うことだ。なお、これら3つ以外のサービスはプラグインとして追加は可能となっているが、基本的にはメジャーなサービスの場合はFileMaker社による機能追加を待つことになるだろう。自社でOAuthサーバーを立てているなら、プラグインの開発をしたくなるところだろうが、こちらはFileMaker社による情報待ちの状態だ。

設定終了後、次のようなメッセージがでかでかと表示される。つまり、FileMaker Serverのサービスを再起動すると言うことだ。もちろん、コンピューター自体を再起動してもいいが、macOS、Windowsでの作業方法が、こちらのページに記載されている。

Googleのコードの取得

Admin Consoleで設定をするには、Google側から与えられるコードを取得しなければならない。そのコードは、Google APIのところで取得を行う。以下の手順で「利用規約の更新」が出てくる場合には、もちろん、そこで対応をして進める。

Googleの場合、Admin Consoleの「データベース」のセキュリティ設定のところで出てきた「Google API Console」をクリックすると、以下のような英語のOAuth 2.0のページが出てくる。実際作業は、このページの本文の2パラグラフ目にある「Google API Console」をクリックして進める。

Google API Consoleをクリックすると、以下のページに移動する。こちらを直接開くには、Google Developer Consoleのページにジャンプすれば良い。なお、このページ内容は、それまでにこの機能を使ったかどうかによって大きく違っている。全く初めて使う場合の作業手順も併せて説明しよう。ポイントは、上部に「Google APIs」というバーが出ている点である。

Google APIsと書かれた右側の部分では、初めて使う場合には「プロジェクトを選択」と表示されるので、それをクリックする。すでに何かで利用してプロジェクトが存在する場合には、とにかくプロジェクト名が見えているのでそれをクリックする。すると、以下のように、プロジェクトの一覧パネルが表示される。パネル右上の「+」をクリックすると、プロジェクトが新たに作成される。ここで、FileMaker Server向けにプロジェクトを1つ作っておく。

プロジェクトの作成時に必要なことは、プロジェクトの名前を設定することである。名前は適当に設定する。なお、プロジェクトIDはこの後は特には使用しない。

プロジェクトを作成すると、そのプロジェクト名がGoogle APIsの右に見えていることを確認して、左側で「認証情報」を選択する。すると、「認証情報を作成」というボタンが見える。ここで、ボタンをクリックして「OAuthクライアントID」という項目を選択する。

なお、ここで以下のようにメッセージが見えているGoogleアカウントでは、必要なコードを生成する権限が与えられていない。例えば、組織で作成されたアカウントではコード生成が許可されていない場合があるので、その場合は個人でアカウントをするなどして、コード発行を行う必要がある。組織のアカウントの場合は、その組織の管理者が、クライアントIDの発行を制限していることが一般的な原因だろう。

 「OAuthクライアントID」を選択した後、同意画面の作成を促す表示が出てくれば、それに従って以下のページで必要な情報を入力する。本来はこの「同意画面」がユーザーに示されて、そしてサービスを利用できるようにするという流れをOAuthでは採用している。しかしながら、FileMakerではこの同意画面を利用していないようで、「ユーザーに表示するサービス名」だけを設定して「保存」ボタンで保存すれば良い。

その後にアプリケーションの種類を選択するページが表示される。ここでは、「ウェブアプリケーション」を選択する。すると、名前などを入力する項目が表示される。ここで、名前は適当に設定するとして、もう1つは「承認済みのリダイレクトURI」を入力しなければならない。このURLは、例えば、FileMaker Serverに接続するためのホスト名が「fmstest.msyk.net」ならば、「https://fmstest.msyk.net/oauth/redirect」を指定する。ホスト名の部分だけがサーバーによって違い、他の部分はどのサーバーでも同様だ。なお、:443はあってもなくても良い。ちなみに、ここにmacOSの共有名(Macintosh.local)や、IPアドレスではうまく動作しない。ドメインを含む利用可能なホスト名をきちんと設定し、そのホスト名でサーバーに接続できる環境になっていなければならない。

「作成」ボタンをクリックすると、生成されたコードがパネルに表示される。こちらからコピーして、Admin Consoleの該当するフィールドにペーストすれば良い。なお、コードは後からでも参照は可能である。

うまくいかない場合の対処

手順は以上の通りだが、FileMakerのドキュメントにも書いてある通り、FileMaker Serverを、きちんとしたドメイン名のURLのホストで公開する必要がある。macOSの共有名の場合、ブラウザからのアクセスが正しくできない場合もある。IPアドレスだけではhttpsでアクセスしているはずはないので、Googleの側で登録が進まない。自分でドメインを持っている方は、何らかのテスト項目を作るなどしてともかくドメイン名を含むホスト名を用意する。

例えば、サインインのダイアログボックスで、Googleボタンをクリックした場合に次のようなページが出たとする。ここで詳細を表示すると、redirect_uriに見えるように、https://MacBookPro.localというホストにアクセスしようとしている。もちろん、この名前は共有名である。ブラウザでは共有名でもOKのはずなのにと思うかもしれないが、単にそのURLにブラウザからアクセスするのではなく、裏ではもっと色々複雑なことを行なっている。筆者の場合には、msyk.netというドメインを所有しているので、fmstest.msyk.netが利用できるようして、検証を行なった。IPアドレスは、実は10.0.1.102というプライベートアドレスだが、自宅環境ではそれで運用可能なので問題はない。

ここで、上記のrequest_uriのURIがどのように自動生成されるのか分からず、対処がなかなかできなかった。実際には、FileMaker Pro/Advancedがrequest_uriを「サーバーへ接続した時に使うホスト名」から生成しているようだ。macOSの場合、自動的にBonjour名が左側に出てきてアクセスをしがちであるが、それだと、上記のrequest_uriには共有名が含まれてしまう。サーバーのドメイン名(つまりFQDN)で接続するサーバーを選択できるように、例えば、お気に入りのホストにドメイン名を登録して、そこからデータベースを選択して開くようにすれば良い。以下の図のように、fmstest.msyk.netでデータベース選択ができるように、お気に入りのホストの登録を行なった。もちろん、自動的に識別される名前がホスト名であれば、それを選択すればOKである。

OAuth対応をどう考えるか

以上のように、Google側の使いこなしが必要になるものの、OAuth対応は確かに便利だろう。アカウントそのものの管理を外部に任せることができるのである。ただし、社員全員がGoogle Appsなどでアカウントを持っていれば便利は便利なのだが、データベース個別にそれぞれのアカウントを登録しなければならない。これは、テキストファイルで読み込みはできないため、自動化のスクリプトなどを使用することになると思われる。ともかく、Googleにアカウントを作ればデータベース側を変更しなくても新しいアカウントから使えるようになる…と言う状況は作れない。機能としては素晴らしいが、運用を考えた時に、手間になる部分も見えてくる。ログインしたアカウントのドメイン名がある名前であれば、自動的に登録されて定義されたアクセス権セットを利用するような仕組みがあることで、管理負荷を軽減できると考えられる。

FileMaker Data APIもOAuth対応している。その意味ではWeb対応しているのだが、WebDirect経由ではOAuth対応はなされていない。これは先のバージョンを待つしかないだろう。

[開発プロセス#8] 画面要素に関するモデル記述の試案

前回より少し間が空いてしまった。また、タグをきちんとつけていなかったのを直した。

ロバストネス図やコラボレーション図を作るとき、バウンダリー、コントロール、エンティティの3種類に分類することは、図の中の各要素の役割を考える上で必要かつ多すぎない点から、やりやすい方法ではある。しかしながら、1つの問題は、バウンダリーの表現力が低いことである。「一覧画面」や「何か操作をする」という大まかな1つのアイコンがあるのがよく見られる作図結果である。この記述をまずは詳細化できないかを考えてみる。ここでは、モデルとして、クエリー結果の一覧があり、その一覧の中に各行に対するボタンがあり、その一覧とは別にテキストフィールドやボタンなどのフォーム要素が並んでいるような状況を考える。フォーム要素は、一覧に対する検索条件を当たるものや、あるいは一覧にレコードを追加するものなのが考えられるが、動作は違うものの要素としての構成は同じようなものと見ることができる。

まず、これらのすべての要素を含むWebページが、コントロールから生成されたことを明確に示す必要がある。一方、ページ内部のコンポーネントのうち、単に表示するようなものについては、そこからコントロールを呼び出されることはないので、図の中で特別な記述は不要である。一方、ボタンなどのフォーム要素や、あるいはイベントを受け付ける要素については、それぞれが別々の動きをするので、その点が記述できなければならない。ICONIXの手法を解説したダグ・ローゼンバーグらの書籍『ユースケース入門 ユーザマニュアルからプログラムを作る』では、次の図のような記述を行なっている。つまり、バウンダリーの中で、特別な動作を行うような要素もやはりバウンダリーであるが、画面全体は画面の一部の集約(コンポジション)としている。図中の点線枠に入っている部分が、1つの画面を構成するバウンダリー群となる。なお、一覧表示の各行に「詳細表示」ボタンがあるとすれば、UML的記述をするには多重度の記述を行うことで、複数存在することが示すことができる。この点は書籍には明示されていない。

画面要素を分離

ここで、実際に開発をする場合に必要な情報が込められているかどうかを検討する。この図にない要素としては、ページが一覧と検索領域に分かれていることや、一覧にどんなフィールドが表示されるのかといったような内容である。これらを含めて記述するとしたら、次の図が得られる。画面の領域を、「一覧表示」と「検索条件入力領域」の2つのサブシステムで表現し、それらのサブシステムは「一覧表示画面」の集約であるとした。一覧表示は、通常は「ヘッダ」「内容」「フッタ」の3つの領域を持つのは、HTMLの定義からも明確である。一覧表示のサブシステムはこの3つの要素が常にあるものとして最初から配置されているとする。「内容」については、繰り返されるのであるが、UML上での一般的な表現はないので、repatingというステレオタイプを付与することにする。この場合は、一覧のないように「名前」と「住所」フィールドが配置され、それぞれの行には該当するレコードに対応する「詳細表示」ボタンが組み込まれることを意味する。

画面要素を分離_0

このようにUMLの記述を拡張することで、画面構成も含めたモデルの記述ができるようになる。しかしながら、画面を構成する要素については、その実物を想像しやすいようなアイコンにすべきと考える。

[開発プロセス#7] 開発対象システムのモデル記述

システム開発でモデルを作成することにより、これから作るシステムが要求に合致したものであるのかといった側面の検討だけではなく、効率の良い実装が可能であるのかといった側面や、予想される改変や拡張に対して実現可能性やその効率性、テストのしやすさなど、実装に直結すること以上に利用できる。しかしながら、その作成するモデルは、様々な手法がある。要求の記述という点ではユースケース図とユースケース記述が出発点にはなるが、データベース主体の開発だと、ここでER図の作成を主体にすることが多い。データベースの構造は対象ドメインの状況を記述できるようになっている必要があるのだが、その結果、全てがデータベースの設計結果であるスキーマに集約されているという見方をしてしまいがちである。ある作業を、スキーマで解決するか、あるいは実装するプログラムで解決するかはもちろん考えるのではあるが、では「ここの処理はプログラムで」というアイデアはER図やクラス図では不明確である。メモを残すなどの工夫が必要になる。

一方、Webシステムではワイアフレームといったざっくりとした画面のデザインをもとに、画面遷移を定義することで、システムの全体像を示そうとする。しかしながら、画面デザインが反映するのは、システムへの実装以前にドメインに対して実施される分析をもとにして作成されるビジネスモデルであり、実装に直結したER図等のモデルからのズレが生じする場合もある。しかしながら、HTMLでの動的なユーザーインタフェース作成機能は限られていたので、例えばチェックボックスであればどういう動作をすべきかということを逐一記述しなくても、半ば「常識的な判断」で進めることであまり大きなブレは発生しなかった。さらに、結果的にビジネスモデルとER図で記述されるスキーマとはあまり変わらないことお多いので、HTMLのモックアップが「設計」として扱うのは、デザイン主体の開発会社では頻繁に見られる方法である。

このように、ある程度のスキルや、ワークフローができてくると、途中を省略する傾向は強く、単一の会社でそれが回っている間は特に問題視はされないだろう。しかしながら、Webの世界は変化が激しい。特にここ5年くらいの時期はクライアントサイドの作り込みの度合いが高くなり、ユーザーインタフェースは複雑化している。その結果、Webのクライアントサイドは多階層的な機能分離を図る必要が出るなど、スマホのクライアントのネイティブアプリケーションに近い構造になっている。

こうした状況が変わってきた時、ワークフローを見直す必要があると考える。今までの知見や常識として暗黙知的に取り扱っていた知識だけでは、新しい問題に対する解法がない可能性が高く、最適な設計ができなかったり、チーム内での意識の疎通が悪くなる。そのために、本来的な詳細なモデルを記述するということが必要なのである。そこを出発点にして、省略やあるいは詳細化をするとしても、Webシステムのモデル記述の手法を一定のレベルで確立する必要があると考える。

UML自体の汎用性は高く、その点では有用性も高いのは事実である。しかしながら、UMLやその周辺手法を使ってWebシステムの記述をするにあたり、次の点に対して何らかの解決策が必要と考える。

  1. 詳細化するとき、明確なルールは特にない
  2. クラス図を主体にすると、オブジェクト指向が前提となる
  3. ボックスがクラスやオブジェクトで、呼び出しが矢印線的な切り分けによる分かりやすさはあるが、処理の記述では呼び出し線に名称を書くことになり、図を見やすく作ることが困難になりがちである

まず、1の詳細化についてである。作成したモデルと、使用するフレームワークの提供機能を比較検討して、実装箇所を特定するには、極端に言えば、プログラムの1行レベルまでを、モデル内の1つの要素として記述することも必要とされる。また、ロバストネス図やシーケンス図では「画面」を1つの要素として扱うが、実際に処理の流れを追う場合、ボタン1つ1つは原則として異なる動作をするので、ボタン1つ1つを要素として表したいということになる。このための指針が費用である。

2つ目のオブジェクト指向である点は、Javaのプログラムだけを作るような場合には確かに有効ではあるが、HTML、CSS、JavaScriptが絡む世界では必ずしもオブジェクト指向ではない。つまり、クラスやオブジェクトを1つの単位として考える場面は実装時にはあるかもしれないが、分析時にはどちらかと言えば、より細かい単位での要素を記述したい。最終的にはメソッドが集まってクラスになるとしても、対象としたのはメソッドであり、その中でどんな処理をしたいかということである。

3つ目は、コミュニケーション図でオブジェクトからオブジェクトに線を引き、線に添えてメッセージ呼び出しを記述する。この方法は実体あるいは実体化可能なものはボックスであり、メッセージは矢印線であるという明確な分類があるものの、簡単なモデルでも、オブジェクトとメッセージを見やすく配置するのはかなり大変である。ましてや、複雑なモデルだとなおさらである。ここではメッセージの記述が作図作業を煩雑にしている点は明白であり、それに代わる表記方法を検討すべきであると考える。

これらの懸案をまずは見える範囲での解決を行った上で、Webシステムのモデルを記述することにする。まず、1〜3に対する提案を次回より行う。

 

[IM] クロステーブルの作成

INTER-Mediator Ver.5.4-devでは、クロステーブルの作成ができるようになっています。ここでのクロステーブルは、表があって、いちばん上の列と、いちばん左の列がラベルとなっており、そのラベルの交差するセルには、ラベルに関連するデータが表示されるというものです。例えば、いちばん上の列には自社の「支店」が並び、いちばん左の列には年月が並ぶとすると、その交差するセルには、特定の支店の特定の年月の売り上げが見えるというものです。サンプルファイルはSamples/Practice/crosstable.htmlおよびcrosstable.phpにあります。

まず、クロステーブルを作るには、3つの異なるコンテキストを定義します。1つは列見出し(以下のコードではitem)、1つは行見出し(以下のコードではcustomer)、そして交差するセルに設定されるデータのコンテキスト(同じくsalessummary)です。列見出し、行見出しのコンテキストについては通常と変わりありません。また、列か行かの区別も、定義ファイル内では設定しなくても構いません。行列の見出しのコンテキストでは、検索条件や並べ替えフィールドの指定などももちろん可能です。以下の例では、元のデータが多いこともあるので、意図的に絞り込んでいます。交差するセルのコンテキスト「salessummary」では、relationキーの指定を必ず2項目行います。1項目は列見出し、2項目目は行見出しとの関連付けになります。item、customerともに、主キーはidフィールドです。これに対応するsalessumarryコンテキストのフィールドはitem_idとcustomer_idです。すなわち、列見出し、行見出しの対応するレコードとのリレーションシップを利用して、交差するデータの配置を決めています。

 array(
   'name' => 'item',
   'table' => 'dummy',
   'view' => 'item_master',
   'records' => 100000,
   'maxrecords' => 100000,
   'key' => 'id',
   'query' => array(
     array('field' => 'id', 'value' => 25, 'operator' => '>='),
     array('field' => 'id', 'value' => 35, 'operator' => '<='),
 ),
 'sort' => array(array('field' => 'id', 'direction' => 'asc')),
 ),
 array(
   'name' => 'customer',
   'table' => 'dummy',
   'view' => 'customer',
   'records' => 100000,
   'maxrecords' => 100000,
   'key' => 'id',
   'query' => array(
     array('field' => 'id', 'value' => 250, 'operator' => '>='),
     array('field' => 'id', 'value' => 259, 'operator' => '<='),
   ),
   'sort' => array(array('field' => 'id', 'direction' => 'asc')),
 ),
 array(
   'name' => 'salessummary',
   'table' => 'dummy',
   'view' => 'saleslog',
   'records' => 100000,
   'key' => 'id',
   'relation' => array(
     array('foreign-key' => 'item_id', 'join-field' => 'id', 'operator' => '=',),
     array('foreign-key' => 'customer_id', 'join-field' => 'id', 'operator' => '=',),
   ),
 ),

ページファイルのクロステーブルの部分は、2セルずつの2行の表として作ります。それよりも多い場合や少ない場合はダメで、要するに2行2列のテーブルを必ず用意します。そして、エンクロージャーになるtbodyタグのdata-im-control属性を「cross-table」とします。これら4つのセルと2つの行は取り除かれ、初期状態として、TRタグに左上のセルを入れた状態にします。この左上のセル内部は、ページファイル側での定義通りにレイアウトされます。

fig16

 <table>
 <tbody data-im-control="cross-table">
 <tr>
   <th></th>
   <th>
     <div data-im="item@id"></div>
     <div data-im="item@name"></div>
   </th>
 </tr>
 <tr>
   <th>
     <div data-im="customer@id"></div>
     <div data-im="customer@name"></div>
   </th>
   <td>
     <div data-im="salessummary@qty"></div>
     <div data-im="salessummary@total"></div>
   </td>
 </tr>
 </tbody>
 </table>

続いて、1行目のTRタグをエンクロージャーに、そしてページファイルにあった右上のセルをリピーターとして、ページ合成を行います。つまり、このBのセルには、列見出しになるコンテキストの名前と、データベースから得られるフィールド名をdata-im属性として持つターゲットノードを記述しておきます。その結果、データベースアクセスが発生し、この場合はitemテーブルから一部のレコードを取り出して、それらを列見出しとして並べます。

fig17

さらに行見出しの処理になります。今度は、TBODYタグをエンクロージャー、そしてTRタグにページファイルの左下のセルを入れたものをリピーターとして、ページ合成を行います。つまり、行見出しだけをまずは作成します。

fig18

ここまでは、エンクロージャーとリピーターの違いはありますが、通常のページ合成と同じです。クロステーブルでは、ここで、次の図のように、交差する部分のセルに、一旦、ページファイルのテーブルの右下のセルを全て並べます。そして、コンテキストに応じたデータベースアクセスを行い、交差する部分に入るデータがあれば、対応するセルに値を設定します。列見出しあるいは行見出しに登場しないレコードと対応するものは無視されます。

fig19

サンプルの出力結果は以下のようなものです。2つのセルにしかデータは入っていません。なお、ここでの交差するセルに対応したコンテキスト内に、同一のセルに対応するものが複数ある場合には、中途半端にマージされます。コンテキスト内は、例えばSQLのビュー等を使うなどして、1つのセルに対応するレコードは0ないしは1個になるようにしてください。

shot3220

FileMakerのWebビューアは本当に「IE」なのか?

追加情報:社本さん、ありがとうございます。解決できました。ヘッダに「<meta http-equiv=’X-UA-Compatible’ content=’IE=Edge,chrome=1’/>」というタグを入れれば、Webビューア上でもflexの機能が動き出します。ということは、MS EdgeはこのmetaタグなくてもEdge動作をするのだけど、FileMakerはmetaタグがないとIE9互換動作をするという罠ってことですね。(以下の原稿公開後にこのパラグラフを追加しました)

最近、CSSのflexを理解したので、FileMakerのWebビューアでも使おうとしたら、思いがけない落とし穴がありました。Macは問題なくレイアウトされますが、Windows 10 + FileMaker 14.0.4では次の図のように、flexが機能しません。「ある記事」と「塚口…」の部分は、それぞれDIVタグ要素になっており、その2つのDIVをさらにまとめたDIVがあって、そこにdisplay: flexを記述してあります。上半分は、FileMaker 14のWebビューア、下半分はMicrosoft Edgeでの表示結果です。同じソースなのですが、このように、Edgeでは正しくflexの動作をしてDIV要素を横方向に並べますが、Webビューアでは、flex動作をしないで、単にDIVとして表示します。

スクリーンショット 2015-12-16 16.00.30

FileMakerのWebビューアコンポーネントは、Internet Explorerのものと言われていますが、もしかして、FlexboxはVer.10から対応なので、Ver.9相当のコードで構築されたコンポーネントが入っているということでしょうか?何れにしても、IE/Edgeのバージョンとは連動しないということかと思われます。

HTMLのソースは、IEの画面のURLから取得できるはずですが、貼り付けておきます。

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<style>
.titlearea{font-size: 12pt; display: flex; display: -ms-flexbox;align-items: baseline; margin: 3px 0 3px 0;}
.title{font-weight: bold; flex: 10 0 auto;-ms-flex: 10;}
.credit{font-size: 10pt; flex: 1 1 auto;-ms-flex: 1;}
.content{font-size: 10pt; border-bottom: 1px dotted black;}
BODY{border: none;}
DIV{font-family: Arial, Roboto, “Droid Sans”, “游ゴシック”, YuGothic, “ヒラギノ角ゴ ProN W3”, “Hiragino Kaku Gothic ProN”, “メイリオ”, Meiryo, sans-serif;}
</style>
</head>
<body>
  <div class='titlearea'>
    <div class='title'>ある記事</div>
    <div class='credit'>塚口 三春[2015/12/15]</div>
  </div>
  <div class='content'>いいことばかりです。いいことばかりです。…いいことばかりです。いいことばかりです。いいことばかりです。いいことばかりです。いいことばかりです。</div>
</div></body></html>

[IM]INTER-Mediatorワークショップで作った“イベント参加申し込みサイト”

K-OFのイベントの1つとして、INTER-Mediatorのワークショップを2015年11月7日に開きました。ワークショップとなると、参加者の皆さんに手をうごしてもらって…というのが一般的ですが、その場で参加される方々もいらっしゃったので、手を動かすのはプレゼンターだけでやりました。

今回のワークショップでの開発目標は、イベントの参加申し込みです。別の勉強会での事後アンケートで、「こういうのを作りたい」と希望があり、それを題材にさせていただきました。グループカウンセリングを実施している赤石さんは、現在、フォームズというサービスで参加受付を行い、メールで送られてくる参加依頼の内容を1項目ずつコピー&ペースとしているそうです。当初は「コピペをしないで一発でExcelに入れる」という要望だったのですが、いっそのこと、受付フォームと一覧表示をINTER-Mediatorで作成するのはどうかということで了承していただき、それをワークショップの題材としました。なお、実際の運用サイトでは、以下のコード内にあるパスワードや一部の名称はもちろん変更しています。

12191812_909228155821822_1194109405261025992_n

設計内容とスキーマ

ざっくり書いたユーズケース図は次の通りです。アクターは、赤石さんと、グループカウンセリングに参加される「お客様」の2つです。お客様はブラウザで申し込みをして、その結果をメールで受け取ることになります。その申し込み結果を「申し込みリスト」に蓄積して、それを赤石さんは随時チェックするという流れになります。この時、お客様は認証等なく申し込みを行えるようにしますが、一方で赤石さんしかリストが見れないようにします。ここで、データベースへの新規レコードは認証なし、その他の処理は認証を行わないとできないようにするという基本設計もできてしまいます。また、システムとアクターの接点は2か所あり、それぞれ1ページだけで実現しそうなので、合計2つのWebページの作成で済みそうです。

ユースケース図0

ER図と同じ用途のクラス図は次のようになります。ちょっとシンプルですが、「申し込み」という1つのテーブルで作ります。本来、グループカウンセリングの実施が1つのエンティティになり、カウンセリングのテーブルを作成して、申し込みとイベントが多対1の関係を作ります。現状では1種類のイベントを、シーケンシャルに、つまり同時に複数のイベントの募集をしているといった事情もないので、1テーブルで運用します。言い換えれば、イベントには「開催日時」というフィールドしかないので、別テーブルにする必要性は薄いということです。「義援金支払い許諾」はチェックボックスで、受講条件の1つを許諾するかどうかを明確にするものです。「ユーザー情報」は、INTER-Mediatorで認証を実施するために必要なテーブル群です。

クラス図0

これらを実現するMySQL用スキーマとして、以下の記述を作成しました。実はワークショップでは、これに失敗して悩んでしまったのですが、今後のワークショップはこれを雛形にしましょう(苦笑。ユーザーやデータベースを定義してアクセス権を設定し、applyテーブル(クラス図での「申し込み」)を定義します。その後の、authuser、authgroup、authcor、issuedhashのテーブルは認証で必要とするものです。リスト表示の時に使用するuser1ユーザーのみ定義しています。

SET NAMES 'utf8mb4';
#DROP USER 'web'@'localhost';
CREATE USER 'web'@'localhost' IDENTIFIED BY 'password';
DROP DATABASE IF EXISTS akaishi;
CREATE DATABASE akaishi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE akaishi;
GRANT SELECT, INSERT, DELETE, UPDATE ON TABLE akaishi.* TO 'web'@'localhost';

CREATE TABLE apply (
  apply_id INT AUTO_INCREMENT,
  name VARCHAR(100),
  yomi VARCHAR(100),
  email VARCHAR(100),
  address VARCHAR(255),
  content TEXT,
  agreement INT,
  startdt DATETIME,
  PRIMARY KEY(apply_id)
) CHARACTER SET=utf8mb4, COLLATE=utf8mb4_unicode_ci, ENGINE=InnoDB;

CREATE TABLE authuser (
  id INT AUTO_INCREMENT,
  username VARCHAR(48),
  hashedpasswd VARCHAR(48),
  email VARCHAR(100),
  limitdt DATETIME,
  PRIMARY KEY(id)
) CHARACTER SET=utf8mb4, COLLATE=utf8mb4_unicode_ci, ENGINE=InnoDB;

INSERT authuser SET id=1,username='user1',hashedpasswd='d83eefa0a9bd7190c94e7911688503737a99db0154455354';

CREATE TABLE authgroup (
  id INT AUTO_INCREMENT,
  groupname VARCHAR(48),
  PRIMARY KEY(id)
) CHARACTER SET=utf8mb4, COLLATE=utf8mb4_unicode_ci, ENGINE=InnoDB;

CREATE TABLE authcor (
  id INT AUTO_INCREMENT,
  user_id INT,
  group_id INT,
  dest_group_id INT,
  privname VARCHAR(48),
  PRIMARY KEY(id)
) CHARACTER SET=utf8mb4, COLLATE=utf8mb4_unicode_ci, ENGINE=InnoDB;

CREATE TABLE issuedhash (
  id INT AUTO_INCREMENT,
  user_id INT,
  clienthost VARCHAR(48),
  hash VARCHAR(48),
  expired DateTime,
  PRIMARY KEY(id)
) CHARACTER SET=utf8mb4, COLLATE=utf8mb4_unicode_ci, ENGINE=InnoDB;

申し込みページの作成

まず、お客様がイベントの申し込みを行うページを作ります。コンテキストの定義を含む定義ファイル(apply.php)は以下のようなものです。ポストオンリーモードでのページを作成すればいいので、コンテキストは1つだけです。また、新規レコードは認証なしで、その他のデータベース処理はできないようにしたいので、存在しないユーザー(nobodyknows)に対してのみ読み出し、更新、削除ができるようにして、事実上、これらの3つの処理は行えないようにします。authenticationキーにcreateキーの値がないので、createに関しては認証なく実施できます。オプション指定はなく、データベース指定のところに、dsn、user、passwordのキーで、データベースへの接続についての記述を行っています。

<?php
require_once('../INTER-Mediator/INTER-Mediator.php');

IM_Entry(
  array(
    array(
      'name' => 'apply',
      'table' => 'apply',
      'view' => 'dummy',
      'key' => 'apply_id',
      'post-reconstruct'=>true,
      'authentication' => array(
        'read' => array('user' => 'nobodyknows'),
        'update' => array('user' => 'nobodyknows'),
        'delete' => array('user' => 'nobodyknows'),
      ),
      'send-mail' => array(
        'create' => array(
          'from-constant' => "msyk@msyk.net",
          'cc-constant' => "msyk@msyk.net",
          'subject-constant' => "申し込みを受け付けました",
          'to' => "email",
          'body-template' => "confirm.txt",
          'body-fields' => "name,yomi,email,address,content,startdt",
        ),
      ),
    ),
  ),
  array(),
  array(
    'db-class' => 'PDO',
    'dsn' => 'mysql:host=localhost;dbname=akaishi;charset=utf8mb4',
    'user' => 'web',
    'password' => 'password',
  ),
  false
);

お客様が申し込みを行うページのぺージファイル(apply.html)は次のように定義しました。見出しの文字列は最低限にしていますが、実運用の時には書き直して利用していただくとして、INTER-Mediatorの動作に関わる部分だけを作ってあります。ヘッダ部での定義ファイルの読み込み、BODYタグのonload属性でのフレームワーク呼び出し、そしてボディ部での記述がポイントになります。ボディ部では、TABLEタグによるテーブルが定義されていますが、data-im-control属性により、ポストオンリーモードであることが指定されています。あとは、コンテキストとフィールド名のセットをdata-imに記述します。同意の項目はチェックボックスですが、value=1の指定があり、チェックがあれば1をフィールドに設定します。カウンセリングの日付はstartdtフィールドにしますが、ここの部分はお客様が入力するのではなく、募集するときに日時が決定しているので、その日時を初期値として規定し、INPUTタグ自体はreadonly属性を設定して、表示だけをするようにします。最後のBUTTONもdata-im-control属性を指定して、書き込みボタンにします。なお、定義ファイルのコンテキストにはpost-reconstructキーのみがあり、この場合は書き込みを行うとこのページの再ロードを行うので、そこで入力した結果が消えます。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>Title</title>
  <script type="text/javascript" src="apply.php"></script>
</head>
<body onload="INTERMediator.construct();">
  <table>
    <tbody data-im-control="post">
      <tr>
        <th>名前</th>
        <td><input type="text" data-im="apply@name"/></td>
      </tr>
      <tr>
        <th>名前の読み</th>
        <td><input type="text" data-im="apply@yomi"/></td>
      </tr>
      <tr>
        <th>メールアドレス</th>
        <td><input type="text" data-im="apply@email"/></td>
      </tr>
      <tr>
        <th>住所</th>
        <td><input type="text" data-im="apply@address"/></td>
      </tr>
      <tr>
        <th>相談内容</th>
        <td><textarea data-im="apply@content"></textarea></td>
      </tr>
      <tr>
        <th>同意</th>
        <td><input type="checkbox" value="1" data-im="apply@agreement"/></td>
      </tr>
      <tr>
        <th>日程</th>
        <td><input type="text" data-im="apply@startdt" 
                   value="2015-11-07 13:00:00" readonly/></td>
      </tr>
      <tr>
        <th></th>
        <td><button data-im-control="post">申し込む</button> </td>
      </tr>
    </tbody>
  </table>
</body>
</html>

定義ファイルapply.phpのコンテキストには、レコードを作成した時にメールを送信する設定が組み込まれています。そのためのメールの文面は、confirm.txtファイルに以下のように用意します。メールについては、定義ファイルでの定義通り、差出人、CC、件名は決められたものを設定し、送り先は作成されたレコードのemailフィールドを指定します。本文は、以下のconfirm.txtの中の@@1@@などの部分が新規に作成されたレコードの値に置き換わります。body-fieldsキーの値に列挙されたフィールドとその順番より、@@1@@が名前、@@3@@がメールアドレス、@@5@@が相談内容、@@6@@が開催日時を示します。

@@1@@ 様(メールアドレス:@@3@@)

以下の通り、グループカウンセリングのお申し込みを受け付けました。

開催日時:@@6@@
ご相談内容:
@@5@@

_(などなど必要な情報を追加する)_

作成したページは次のようなものです。

shot3036

申し込みを行うと、入力したメールアドレスに、確認のメールが送られます。

shot3041

一覧ページの作成

一覧ページを構成するために、以下のような定義ファイル(list.php)を作成しました。こちらは、applyテーブルの内容を参照したり、場合によっては変更や削除等があるので、すべてのデータベース操作に対して、user1で認証したユーザーだけが許可されるようにしました。また、開催日の逆順で一覧されることで、最近の開催日に対する参加者がリストの上部にまとまるようにしました。コンテキストには、削除ボタンの追加の指示はありますが、挿入ボタンはありません。挿入ボタンは、必要ならapply.htmlから自分で申し込みを入れてそれを修正すればいいと考えました。

<?php
require_once('../INTER-Mediator/INTER-Mediator.php');

IM_Entry(
  array(
    array(
      'name' => 'apply',
      'table' => 'apply',
      'view' => 'apply',
      'key' => 'apply_id',
      'paging' => true,
      'records' => '20',
      'repeat-control' => 'confirm-delete',
      'sort' => array(
        array('field' => 'startdt', 'direction' => 'desc'),
      ),
      'authentication' => array(
        'all' => array('user' => 'user1'),
      ),
    ),
  ),
  array(),
  array(
    'db-class' => 'PDO',
    'dsn' => 'mysql:host=localhost;dbname=akaishi;charset=utf8mb4',
    'user' => 'web',
    'password' => 'password',
  ),
  false
);

一覧のページファイル(list.html)は以下の通りです。特に変わったところはなく、applyコンテキストの内容をページネーションとともに表示をしています。コンテキスト定義にあるように、20レコードずつ表示をします。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <link rel="stylesheet" href="INTER-Mediator/Samples/sample.css" />
  <title>Title</title>
  <script type="text/javascript" src="list.php"></script>
  <style>
    td{
      border: solid 1px black;
    }
  </style>
</head>
<body onload="INTERMediator.construct();">
  <div id="IM_NAVIGATOR"></div>
  <table>
    <thead>
      <tr><th>開始日時</th><th>名前</th><th>読み</th>
        <th>住所</th><th>相談内容</th><th>同意</th><th></th></tr>
    </thead>
    <tbody>
      <tr>
        <td data-im="apply@startdt"></td>
        <td data-im="apply@name"></td>
        <td data-im="apply@yomi"></td>
        <td data-im="apply@address"></td>
        <td data-im="apply@content"></td>
        <td data-im="apply@agreement"></td>
        <td></td>
      </tr>
    </tbody>
  </table>
</body>
</html>

ページを表示すると、ログインパネルが表示されます。

shot3042

正しいユーザー名とパスワードを入力してログインすれば、リスト形式で、申込者の一覧を見ることができます。

shot3043

ワークショップを終えて

結果的にワークショップでは、入力専用(ポストオンリーモード)のページと、その入力した結果を表示するための2つのページを作成しました。実際のワークショップでは凡ミスに気づかずちょっと時間を無駄しにしてしまって申し訳なかったのですが、通常ではこれくらいであれば1時間程度の作業で行えるということが示せたかと思います。また、典型的なシステム開発の流れも見ていただけるサンプルになったかと思います。

なお、こうして作ったシステムも、作ってから新たなニーズが発生するかと思います。そうした追加の要求や変化する要求についても追跡させてもらって、可能な限り、アフター・ワークショップとしてお伝えできればと考えています。

買ったばかりのMacBookのUSB-C事情

MacBookは5/17に到着、5/20に「USB-C Digital AV Multiportアダプタ」が到着、注文中の「USB-C VGA Multiportアダプタ」はまだ未着の段階です。DELLの4Kディスプレイで、Retina動作をすることを報告しました。これはある種の「予想外の動作」と言えるでしょう。しかしながら、使うに従って、USB-Cについて、いろいろ試行錯誤が必要になってきました。

まず、Nexus 7のACアダプタ(7Wか10Wだと思う)で、充電できることをFacebookにも書きましたが、場所によって充電できる場合とできない場合があることが判明しました。自宅だと、充電できます。しかし、移動先ではできたりできなかったりします。同一のアダプタ、同一のケーブル(USB-AとUSB-Cのケーブルを購入した)でやっているので、これはおそらくコンセントの段階での電圧の問題ではないかと思います。先日、「充電できる」と思っていたら、「充電できない」という状況に遭遇しました。とはいえ、1日程度はなんとかバッテリーは持ちました。

次にディスプレイアダプタ(USB-C Digital AV Multiportアダプタ)を装着すると、Nexus 7のACアダプタでは、100%充電はできないし、給電もできないことがわかりました。アダプタが電源を食うのか、USBの機材の関係なのか、ともかくNexusのアダプタ経由では充電や給電ができないのです。

しかし、なんと、iPadに付属のACアダプタ(12W)だと、ディスプレイアダプタを経由して、MacBookに給電/充電ができるのです。ということは、持ち歩きはiPadのアダプタでいいということになりますね。iPadは、Nexusのアダプタで使えばいいということで、「予想外の嬉しい組み合わせ」がもう1つ見つかりました。

代替のACアダプタ、つまり、軽いとか、安いのでいくつか買ってあっちこちにキープみたいなことができないかと考えるわけですが、USB出力があって、10Wを超える(つまり、1つのポートで20W)みたいな製品ってAmazonで調べたけど、見当たりませんでした。USB出力のACアダプタは、ほぼ、スマホタブレット向けで、出力が低いのです。20Wと書いてあっても2端子合計だったりするのが普通のようです。iPadのACアダプタは2200円なので、純正品が5800円に対して半額以下であり、大きさも小さいということもあり、ある意味、持ち歩き用としては、買い足してもいい範囲なんじゃないかと思います。

USB-Cのケーブルもまだまだ高いですし、USB-Cの反対側が高出力のACアダプタ向けのものなんてまだ見当たりません。ということで、新しいMacBookユーザが欲しいスペックのブツはどうやらまだまだのようです。要するに純正以外の選択肢が非常にない状態ということです。予測はしていましたが、とにかく乗り切らねば。Facebookでリンクを紹介しましたが、クラウドファンディングで募集しているHub+がまずは新しいパターンの製品ですね。mini Display 端子があるので、Apple純正のディスプレイをつなぐことができます。

ディスプレイアダプタが来て本格的に利用

新しいMacBookは日曜日に来ました。そして、今日水曜日に遅れてUSB-C Digital Multiport Adapterが到着し、やっと大画面ディスプレイと接続ができました。薄っぺらいもののちょっと大きなアダプタですが、3つのコネクタを横に並べるとしたら、やっぱりこのサイズになるでしょうか。USB-Cには本体付属のケーブルで、付属のACアダプタへ接続しています。ディスプレイとは、ディスプレイに付属のUSBケーブルと、購入したHDMIケーブルで接続をしています。

IMG_0383

このMacについてを見てみると、ディスプレイフルの解像度で見えています。4Kということで、4000弱の横ドット数です。

shot2012

ところが、「システム情報」を見てみると、1920×1080となっており、ディスプレイ自体のちょうど半分の解像度です。これは、Appleの27インチのCinema Displayの解像度(2560×1440)より低い解像度となります。Command+Shift+3で画面ショットを作成すると、3840×2160ドットなので、ディスプレイのフルの解像度を利用していることがわかります。

shot2013

システム環境設定の「ディスプレイ」では、外付けディスプレイも、内蔵ディスプレイと同じように、ドット数ではなく、4段階の選択になっています。つまり、外付けのRetinaディスプレイとして扱っていると考えていいのではないでしょうか。

shot2011

実は直前まで使っていたのはMacBook Airで、RetinaディスプレイのMacは今回購入したMacBookが初めてなんです。もちろん、美しいのは当然ですが、外付けディスプレイまで、Retinaの処理をしているのは知りませんでした。しかしながら、外付けディスプレイの表示結果は、内蔵ディスプレイに比べて「ちょっと大きい」感じがします。27インチのディスプレイの、従来の解像度よりも低い解像度だけに大きく見えるのは当然でしょう。内蔵ディスプレイの内容がやや小さいので、並べると外付け側が大きい感じが出ます。

しかし、最近、視力も落ち気味だけに、ちょうどいいかとも思っています。システム環境設定の「ディスプレイ」で「スペースを拡大」側のいちばん右にすると、さすがに小さすぎます。しかし、これは、もしかして、5Kだったら大きさ感が一致するのかもしれません。もしかして、それが理由で4KディスプレイをAppleは出さない(部品がなくてだせないとか?)のかもとも思ってしまいます。

Yosemiteでdocdiff

以前、2つの文書の比較結果をカラーリングで示せるdocdiffのことをMavericks向けに書きました。Yosemiteで同じようにすると動きませんでした。しかし、gemで簡単にインストールできるようです(松尾さんありがとう)。

sudo gem install docdiff

これで、/usr/bin/docdiffがコマンドとして機能するようになります。そのほかのライブラリファイル群は正しい場所に入っているということで、気にしないで行きます。

さて、svnで使うには、パラメータの組み換えが必要です。そこで、/usr/local/binにdocdiffを作ってそれを実行用にします。もちろん、viでもemacsでもご自由なエディタで編集してください。もし、/usr/local/binが作られていないのなら、mkdirコマンドで作ってください。

sudo nano /usr/local/bin/docdiff

中身はこのように書きます。

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

そして、もちろん、アクセス権を設定しておきます。

sudo chmod a+x /usr/local/bin/docdiff

こうすれば、以下のようにsvnコマンドを打ち込むときに、docdiffを使って比較を行います。最後のパラメータはファイル名です。

svn diff --diff-cmd=docdiff -r PREV _any_file_name_

もし、パス(echo $PATH で確認できます)が、/usr/local/binに通っていないとか、/usr/binより後にある場合には、上記のパラメータの1つを「–diff-cmd=/usr/local/bin/docdiff」のように指定します。

ということで、docdiffは便利です。

shot2001

ディスプレイをDell P2716Qに置き換えた

Apple LED Cinema Display 27インチは売り先が決まりそうなので、さっそくディスプレイを買い換えました。新しいMacBookにリプレースすると、Cinema Displayへの接続がとりあえずはできない(そのうちできるかもしれないけど)ので、HDMIのあるものに切り替える必要があります。以前のブログ記事のように、BenQの24インチもありますが、もう少しクオリティたかそうなものが欲しいのと、せっかく新しいMacBookなので、4Kにしようと思い、Dell P2715Qに変えました。

しかしながら、まだ新しいMacBookは到着していないので、本体はMacBook Air 2012年モデルのままです。Mini Display Portから直接つないでみましたが、もちろん、つないでほぼ即座に使えました(最初に入力元の切り替えだけ必要)。

IMG_0381

大きさ感はCinema Displayとさほど変わりません。もちろん、筐体のゴージャスさは大きく差がありますが、まあ、それは仕方ないでしょう。MacからはUSBケーブル1本で、ディスプレイ側に接続し、そこから4つのUSBケーブルを接続できます。USBのハブの出力先は1本増えたのは嬉しいところ。ただし、MacBook Airへの電源供給がなくなったので、ACアダプタを自宅でもしばらく使うことになります。

システム環境設定のディスプレイで見ると、本体が4K対応ではないので、2560×1440しか出ません。Cinema Displayだとそれが最大の解像度だったのでくっきり見えていましたが、Dell P2715Qだと、若干「解像度落としてます感」がありますね。まあ、でも気になりません。画質もBeQの24インチより色が自然な感じです。IPSだからというのもあるかもしれません。まあ、3倍くらい高いから当たり前といえば当たり前かもしれません。「プリセットモード」ってのがあるのですね。けっこう色調が変わりますが、とりあえずスタンダードです。

shot0319

システム環境設定の「サウンド」の出力を見ると、DELL P2715Qと見えているのでおや?と思ったのですが、単に項目として出るだけですね。サウンドがないのはもともと知っていました。下手なスピーカーをつけるより、正しい設計だと思います。そういえば、ラインアウトがあるので、つないだら何か出てくるのだと思います。

shot0318

大画面が2枚欲しいと言いながら、実のところ、クオリティ差が大きいこともあって、結局1枚しか使わない状態になりました。ただし、MacBookが来たら、Retinaだし、トラックパッドも新しくなります。ということで、多分、Dellのディスプレイの前にMacBookを置くパターンで作業するでしょうね。ということで、BenQ 24インチはまたまた、使う機会が減ったままです。実は、今ところ、Apple TVとつないで、大画面ラジオ(意味ない〜笑)にしか使っていない状態です。まあ、でも、たまに画面が欲しくなるときもあるだろうから、AirPlayでスタンバイのままで行くでしょう。

などと書きながら考えて、こういうセッティングにしてみました。右側のBenQ 24インチの後ろに、PromiseのPegasus R4とMac mini Serverがあります。なんとなく、スタンドの位置は夜になって悩む気がしますが、MacBookが来るまでの2、3週間はこの体制かなと思いっています。右の方の机は、もちろん片付けます(笑)。

IMG_0382