Talk about computer, network and how we should work.
来ました。予約した覚えはないのですが、1泊で1800ドルとはゴージャスなものです。ただ、よくあるタイプの別のサイトへの誘導は明示的ではなく、HTML内にあるのリンクはちゃんとbooking.comに行きますね。しかし、金額は書いてあるけど、どこのホテルか書いていない。そんな予約はありえないでしょう。このメールアドレスで昔booking.comを使った可能性もあるのですが、なんとアカウントは作られていませんでした。まあ、これでほとんど安心なのですが、念のためアカウントを作ってみたのだけどやはり予約は入っていません。また、添付するzipを展開するとexeが入っていたので間違いなく、嘘メールでしょう。あと、巧妙なのは、本物のBooking.comの広告メールと同じような時間に配布しているところですね。
だけど、ClamXavだとマルウェアと判定はしませんでした。Booking.comには似たような警告はありますが、このメールではなく、１年ほど前の別のもののようです。ということで、警告の意味も含めてブログに記載します。1ヶ月ぶりの書き込みがこんな話題ですんません。
「上から目線は言った側も言われた側も上から目線である」
「上から目線でものを言うんじゃない！」などと表現されるこの言い回しはもはや説明の必要がないくらい常套句となっています。下の立場の人から、上の立場のような言い方をされたときに、失礼だとか、お前に言われたくないよという意味で使われます。「上から目線の対処法」という記事が検索すると上位に来ます。確かに、認めてもらいたいがために上から目線になるというのは理解できますし、このページの対処法は確かにポジティブな対処法です。
役職や身分が決まっているならともかく、同等な相手で「上から目線」を感じるということは、言われて感じた側が「自分の方が上である」という認識をしているということでもあります。つまり、「低い位置で上から目線になっても、視野が極端に狭いだけじゃないのか」と感じることになるでしょう。
経過や大局を見ないで、その人が知っている範囲だけの知識で、大きな結論を出すような行為は、言われた側には狭い視野しかないのは一目瞭然だったりします。言われた側の方が、より広く多くの情報が分かっていることがやりとりで明確になれば、言われた側は自分が上であると判断し、相手を「上から目線」と思うわけです。
言う側も、言われる側も、そうなると所詮、自分の範疇が中心となりがちです。相手のことを知り、相手が何を考え、何を欲しているかを考慮するというコミュニケーションの原則もつい忘れがちです。上から目線でものを言わないようにしろと言うのは簡単ですが、上から目線でものを言われたとき、言った人の目線を水平にできるかどうかという点も、言われた側の器量が試されているのではないでしょうか。そして、自分の目線も水平にできるでしょうか？
怒る前に、そして怒ってもすぐに冷まし、そこから上から目線になる理由を探ることは、その人1人とのコミュニケーションだけでなく、重要なことを怠っていたことも分かるかもしれません。伝達されていない情報があったり、誤解されているということを探る機会になるのではないでしょうか。
ファイルのドラッグ&ドロップによるアップロードをINTER-Mediatorに実装しました。動作条件を整える方法はドキュメントを改めて書きますが、ページファイル上は、
class=”IM[testtable@vc1] IM_WIDGET[im_fileupload]”
のように、IM_WIDGETで、利用するコンポーネントを書くだけで、以下のムービーのようなドラッグ&ドロップによるファイルのアップロードができるようになっています。
ファイルのアップロードをするときのプログレスバーを出す方法が「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ファイルの扱いが違ってくると思われます。
ポイントとしては、APCのコンパイルのために、autoconf、pcreが必要である点です。また、APCの設定は既定値ではrfc1867はOffですので、設定ファイルで記述してオンにしておく必要があります。
なぜ、この記事のカテゴリにINTER-Mediatorがあるかというと、この仕組みをINTER-Mediatorに組み込んだからです。
INTER-Mediatorで、テーブルに新たにレコードを作るときの挙動にバグがあり、全体的に見直しをしました。以下の内容は、Ver.3.4以降で有効です。
まず、「新規レコード作成」のクライアント側でのAPI、つまり、JavaScriptベースでの呼び出しは4カ所あります。最初の3つは、主としてINTER-Mediator自身が使うものです。
最後のメソッドは、INTERMediator_DBAdapter.db_createRecordでもかまいませんが、上記のメソッドだと認証のある場合、ない場合、どちらでも利用できます。
さて、データベース処理に関係する定義ファイル内のコンテキストのキーはまとめるとこんな感じです。ここでは、レコード作成に絞って考えます。
一時期のINTER-Mediatorでは、queryキーで指定した内容を、初期値として設定するようなプログラムが組み込まれていました。そうしないと、新規レコードを作った後に「検索されない」という状況が発生するからです。しかし、それはdefault-valuesキーで指定をすることで、検索される状態は設定できるので、あえて、queryキーを無視するようにしました。
一方、relationキーについては、関連レコードのテンプレート処理側では、これに対応した外部キーへの値の設定がないと、新しく作ったレコードは関連レコードになりません。なので、INTERMediator.insertbuttonメソッド内で、コンテキストのこの情報を見て、外部キーのフィールドの初期値を自動的に与えています。なお、演算子は無視しているので、演算子に>があるような場合などは要注意です。INTERMediator.insertRecordFromNaviメソッドは、ナビゲーションのボタンで呼び出されます。従って、通常は関連レコードのコンテキストには適用されず、relationキーは無視します。INTERMediator_DBAdapter.db_createRecordWithAuthについても、relationキーは無視します。
一方、JavaScriptのプログラムで、検索条件、ソート条件、さらに新規レコードの初期値を指定するプロパティが以下のように定義されています。新規レコードの初期値はVer.3.4が初出です。
新規レコードではソート条件は関係ありません。検索条件のINTERMediator.additionalConditionについては、新規レコード作成時は一切無視されます。一方、すべての新規レコード作成時に、INTERMediator.additionalFieldValueOnNewRecordに指定した値が初期値として設定されます。
まとめると、新規レコード作成時には検索条件は一切利用しません。その代わり、スタティックな初期値としてのdefault-valuesキー、ダイナミックな初期値としてのINTERMediator.additionalFieldValueOnNewRecordが適用されます。また、関連レコード内でのInsertボタンを押したときにはrelationキーの値が利用されますが、その他の場合にはrelationキーは適用されません。
「7つのデータベース7つの世界」という書籍の書評を書こう（久しぶりに書評を書くぞ）。「7つの言語…」が有名な米国のPragmatic Bookshelfから出版された翻訳本であり、この書籍についてはオーム社から発売された。原書は手にしていないので、翻訳本についての紹介になる。
本書で紹介しているのは、PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4J、Redisとちょうど7つだ。まず、このチョイスにMySQLがないことがポイントだ。データベースと言えばRDBという時代が長く続いたがここ数年来NoSQL（Not-only SQL）がブームになっている。とは言え、RDBやSQLがなくなるわけではなく、データベースにも適材適所の時代が来たということである。NoSQLにもいろいろなタイプがあり、キーバリュー、列指向、ドキュメント指向、グラフ指向から代表的なものを選択して紹介しているわけである。
1つのDBあたり、30〜40ページというところで、すべてを知るための書籍ではない。これは「7つの…」シリーズで踏襲されている「その世界をツアーしガイドする」というコンセプトによる。DBの概要となると、言語とは少し違う。本書では基本的なデータの扱いの概念と、そのDBを使ったおいしい事例というところにフォーカスされている。詳細や他の世界との接点については「宿題」として自分で考えましょうというスタンスだ。たとえば、MongoDBではMapReduceの事例をしっかりと紹介しているが、ショートカットや正規表現については宿題として自分で調べることになっている。
NoSQLは何だと言われても、うまく答えは見つからないが、本書はNoSQLの世界への非常に巧みなガイダンスとなっている。DBは何と言っても基本的なデータの扱いという絶対にはずせない情報があり、そこはどのDBについても実践的な解説でうまく体験できるような説明となっている。それぞれのDBについての最初の解説を読むだけでも、DBのコアな仕組みが見えてくる。NoSQLに興味がある人は、まず最初に手に取って読んでみることを勧めたい。
ここからは余談…コンピュータ書籍はオライリーの独断場のような様相であると言い切るとして、その中で、Pragmatic Bookshelfの企画力には注目していた。オライリーはユニークな企画ものもあるけど、やはり「Perl」とか「SSH」といった直球勝負な書籍が中心だ。そのオライリーにもっと早い重い直球で勝負するぞと意気込んだところでなかなか勝てない。しかし、Pragmaticはある意味オライリーがだしそうにない書籍という点で注目できるのである。個人的には「SQL Antipatterns」のファンでもある。そのSQL Antipatternsは、日本ではオライリーから出た。え？なんで？と思って調べたら、Pragmatic Bookshelfの書籍のディストリビューション（意味的には販売会社だろう）はオライリーだったのである。やっぱりオライリーの独断場なのだろうか。
余談は続くが、Pragmaticの書籍をアメリカのアマゾンから買って読んでいた頃、ふと、電子版は割引と書いてある。紙の書籍を持っていないと買えない仕組みである。その絶妙な価格付けで、思わず電子版を買ってしまった。書籍の4分の1ほどの値段で電子版が購入でき、しかも改訂があれば最新版が手に入る。紙の書籍を買って、必要なら電子版を買い、読んだら紙の書籍は古書流通に流す…。これだと、自炊もしなくてもいいし、軽いPDFやePubファイルが手に入る。中身の翻訳はもちろん歓迎されることだが、こうした仕組みも含めて出版社にはローカライズして欲しいところだ。
追記：6とbも間違うぞという指摘があったので、修正します。
ユーザ名やパスワードは、時として「手で入力する」ことを必要とします。もちろん、コピペもあるんですが、手入力を必要にすることで、意図的にセキュリティレベルを高めることもあるかもしれません。そのとき、印刷状況によって、数字の「１」と「小文字のL」の見分けがつかなかったりということが発生します。もちろん、フォントの工夫と、アルファベットおよび数字などの使用している文字をサンプルとして印刷するということで対処する場合もあるかもしれません。
ここで、いっそのこと、間違えやすい文字列はもともと含めないでアカウントやパスワードを作るのがいいのではないかとも言えます。とはいえ、「間違いやすい」というのもちょっと曖昧な定義です。ご意見をいただければと思います。なお、ここでは記号類、全角文字は排除されているものとします。
数字＋アルファベット大文字
数字＋アルファベット大文字小文字
Zとzを間違えるかというと、微妙かもしれませんが、ありそうなことを排除することを考えています。フォントに寄っては、Zとzは区別しずらい、あるいは間違えやすいことはあるだろうということです。それでも、Tとtは区別はつくだろうとうことでリストには入れていません。
Qと9の区別は、日本語だけだろうということもあります。また、大文字と小文字の違いがある場合には発音だけでは判定できません。音声でコードを伝える必要がある場合は、アルファベットは大文字か小文字かのいずれかだけにしないといけないでしょう。どちらを使うかは、使用するシステムに依存すると思います。
上記のルールを適用して間違えやすい文字列を排除すると、使える文字列はこうなります。
数字＋アルファベット大文字（30文字）
数字＋アルファベット大文字小文字（3735文字）
以前、クーポンコードのようなものを考えたとき、その手入力が必要としたらどうなるかを考えました。その仕様がどうだったかはどうでもいいので、現状での記述に揃えます。ただ、ランダムに作るというよりも、生成した乱数をビットに分離すれば、変換はやりやすいと考えました。つまり、base64の原理です。4ビット16文字なら16進表現の方がいいでしょう。6ビット64文字にするには、上記のいずれのパターンも足りません。そこで、5ビット32文字で考えます。「数字＋アルファベット大文字小文字」をもとに、さらに微妙に間違いが発生しないかと考えられる以下の53文字を排除するとします。
こうして残ったのが以下の32文字、つまり5ビットです。5ビット分ずつ、以下の文字列に置き換えれば、乱数からそのエンコード表現ができあがり、手入力時に間違いやすい文字列が排除されているということになります。
数字＋アルファベット大文字小文字（32文字）
こんなことまで考えて、クーポンシステムを作ったのに、全然使われなかった…。まあ、それは仕方ないとして、別件でランダムパスワードの生成が必要になったので、思い出してブログにまとめました。
パターンとして微妙、あるいはパターンと言えるほどの考察がないのじゃないのかと思われる1つのパターンを紹介しましょう。しかしながら、問題点は明確であると思います。
関連パターン：（TBD）
本当はこれを最初にまとめないといけないのかもしれません。そもそも、パターンの記述を読み込むための前提知識は前提知識として定義できるはずです。パターン集ではあまりそういう記述を見ませんが、パターンなのか、たんなる機能なのかを判断する上でも、必要な情報と考えます。つまり、前提知識はパターンではないというところが出発点です。前提知識は、問題解決というよりも、単一の機能であるとも言えるかもしれません。以下、見出しが前提知識として提示します。
データベースあるいは表形式のデータそのものは、フォーマットです。もしかすると、広い意味でのシステム構築パターンには「データベースを使う」というのがあるかもしれませんが、ここではリレーショナルデータベースを使用した場合の設計に関する問題解決にフォーカスしているので、フィールドやレコードといった存在、あるいはその概念は前提知識とします。
テーブル演算そのものは、パターンでないと考えますが、パターンの中で特定のテーブル演算を使うことはあり得ます。言い換えれば、テーブル同士の演算があるという前提から出発している話なので、これらも前提知識とします。
前項と同じ意味ですが、テーブル同士は結合できるという事実も、前提知識です。いや、むしろ、この仕組みが出発点なのです。これはパターンではなく、いちばんコアな意味での前提知識と言えるでしょう。
ここの切り分けが難しいところですし、どこまでの機能が前提知識で、どこからがパターンなのかは問題解決への貢献度や、自明さから考えることになるでしょう。「レイアウト」というのは機能であり、動作は明確であり、目的を持って使えるものです。しかしながら、レイアウトの機能でも「データに応じて文字列の色を変更したい」という問題点から出発すれば、「条件付き書式」はパターンかもしれません。一方、条件付き書式に対するトレードオフはFileMakerで実装しているかどうかの問題しかなく、問題解決で発生する葛藤は薄いでしょう。そうなると、「条件付き書式」はやっぱり単なる機能でしかないかなと考えるわけです。機能そのものがパターンになり得る場合も一部はあると考えますしかしながら、一般には機能そのものはパターンにはなり得ないと考えます。
他に項目を思い付いたらまた追記します。
前回の、FileMakerリレーションパターンの記事は、「いいね」が非常に少なくなり、みんなが引いているのが分かりますが、ともかく進めましょう。前回は、「種類フィールドを持つテーブル」というパターンがなぜ問題解決につながるのかを説明しました。パターンでは、そうした発見を、パターン記述にします。そのとき、適当に書き散らすのではなく、項目を決めておくのが一般的です。それもふまえて、「種類フィールド」パータンを記述したのが以下の通りです。
関連パターン：ポータルフィルタ、定数フィールド
パターンにおけるフォースの説明は大変難しいのですが、問題と解決策では記述しきれないことをフォースとしてまとめるというのが1つの方法です。フォースの1つの役割は、パターンを適用したり展開するときの前提条件や、制約条件を記述できる点があります。さらに広い意味では、人間の意思に近いものもフォースと言えるかもしれません。まさに、ある種の力関係、力学的作用、そういうものが働くことによってパターンが成り立つというその状況を記述するための項目になります。