「上から目線は言った側も言われた側も上から目線である」

「上から目線でものを言うんじゃない！」などと表現されるこの言い回しはもはや説明の必要がないくらい常套句となっています。下の立場の人から、上の立場のような言い方をされたときに、失礼だとか、お前に言われたくないよという意味で使われます。「上から目線の対処法」という記事が検索すると上位に来ます。確かに、認めてもらいたいがために上から目線になるというのは理解できますし、このページの対処法は確かにポジティブな対処法です。

役職や身分が決まっているならともかく、同等な相手で「上から目線」を感じるということは、言われて感じた側が「自分の方が上である」という認識をしているということでもあります。つまり、「低い位置で上から目線になっても、視野が極端に狭いだけじゃないのか」と感じることになるでしょう。

経過や大局を見ないで、その人が知っている範囲だけの知識で、大きな結論を出すような行為は、言われた側には狭い視野しかないのは一目瞭然だったりします。言われた側の方が、より広く多くの情報が分かっていることがやりとりで明確になれば、言われた側は自分が上であると判断し、相手を「上から目線」と思うわけです。

言う側も、言われる側も、そうなると所詮、自分の範疇が中心となりがちです。相手のことを知り、相手が何を考え、何を欲しているかを考慮するというコミュニケーションの原則もつい忘れがちです。上から目線でものを言わないようにしろと言うのは簡単ですが、上から目線でものを言われたとき、言った人の目線を水平にできるかどうかという点も、言われた側の器量が試されているのではないでしょうか。そして、自分の目線も水平にできるでしょうか？

怒る前に、そして怒ってもすぐに冷まし、そこから上から目線になる理由を探ることは、その人1人とのコミュニケーションだけでなく、重要なことを怠っていたことも分かるかもしれません。伝達されていない情報があったり、誤解されているということを探る機会になるのではないでしょうか。

「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」の見分けがつかなかったりということが発生します。もちろん、フォントの工夫と、アルファベットおよび数字などの使用している文字をサンプルとして印刷するということで対処する場合もあるかもしれません。

ここで、いっそのこと、間違えやすい文字列はもともと含めないでアカウントやパスワードを作るのがいいのではないかとも言えます。とはいえ、「間違いやすい」というのもちょっと曖昧な定義です。ご意見をいただければと思います。なお、ここでは記号類、全角文字は排除されているものとします。

数字＋アルファベット大文字

• 0 O（見栄えが似ている）
• 1 I（見栄えが似ている）
• Q 9（発音が似ている）

数字＋アルファベット大文字小文字

• 1 l i j（見栄えが似ている）
• 6 b（見栄えが似ている）
• 0 O o（見栄えが似ている）
• Q 9 q（発音が似ている）
• C c（見栄えが似ている）
• K k（見栄えが似ている）
• S s（見栄えが似ている）
• V v（見栄えが似ている）
• W w（見栄えが似ている）
• X x（見栄えが似ている）
• Z z（見栄えが似ている）

Zとzを間違えるかというと、微妙かもしれませんが、ありそうなことを排除することを考えています。フォントに寄っては、Zとzは区別しずらい、あるいは間違えやすいことはあるだろうということです。それでも、Tとtは区別はつくだろうとうことでリストには入れていません。

Qと9の区別は、日本語だけだろうということもあります。また、大文字と小文字の違いがある場合には発音だけでは判定できません。音声でコードを伝える必要がある場合は、アルファベットは大文字か小文字かのいずれかだけにしないといけないでしょう。どちらを使うかは、使用するシステムに依存すると思います。

上記のルールを適用して間違えやすい文字列を排除すると、使える文字列はこうなります。

数字＋アルファベット大文字（30文字）

•  2345678ABCDEFGHJKLMNPRSTUVWXYZ

数字＋アルファベット大文字小文字（3735文字）

•  234578ABDEFGHJLMNPRTUYadefghmnprtuy

以前、クーポンコードのようなものを考えたとき、その手入力が必要としたらどうなるかを考えました。その仕様がどうだったかはどうでもいいので、現状での記述に揃えます。ただ、ランダムに作るというよりも、生成した乱数をビットに分離すれば、変換はやりやすいと考えました。つまり、base64の原理です。4ビット16文字なら16進表現の方がいいでしょう。6ビット64文字にするには、上記のいずれのパターンも足りません。そこで、5ビット32文字で考えます。「数字＋アルファベット大文字小文字」をもとに、さらに微妙に間違いが発生しないかと考えられる以下の53文字を排除するとします。

• m n r（お互いにデザインが類似している）
• u y （大文字のデザインにそこそこ近い）

こうして残ったのが以下の32文字、つまり5ビットです。5ビット分ずつ、以下の文字列に置き換えれば、乱数からそのエンコード表現ができあがり、手入力時に間違いやすい文字列が排除されているということになります。

数字＋アルファベット大文字小文字（32文字）

• 234578ABDEFGHJLMNPRTUYadefghprty

こんなことまで考えて、クーポンシステムを作ったのに、全然使われなかった…。まあ、それは仕方ないとして、別件でランダムパスワードの生成が必要になったので、思い出してブログにまとめました。