日本橋にひび トラック通行禁止に

プノンペンのカンボジア-日本友好橋（通称チローイ=チョンヴァー橋・日本橋）の東端の柱に亀裂が発見されたことから、2.5トン以上のトラックの通行が禁止となりました。

Cracks discovered in bridge

この橋は1960年代後半に作られましたが、中央部分は内戦で破壊されたため、日本の支援で再建されましたが、問題の箇所は建設当初の構造が利用されているということです。

あれっ冷房設定が変わってる…？ クラッカーのしわざかも

「フロア全室のDo Not Disturb灯を点滅させてみた」
「国外からアクセスして客室の電灯を午前2時に点灯させてみた」

それにしてもこのハッカーさんノリノリである。

泊まったホテルの制御系にセキュリティホールがあり、全室の電灯や冷房などを全世界から制御しほうだいだった（ひょっとしたら各室ドアロックやロビーも）、という話。

Internet of Thingsの時代に、古いプロトコルを使ってる危険なホテルや家庭が多すぎる、と警鐘を鳴らしています。

Here’s How Easy It Could Be for Hackers to Control Your Hotel Room

GUIの終わり、PUIの始まり ロボット型タブレットJiboは、身体ユーザーインターフェースのさきがけだ

「情報の海を家庭へ繋ぐ方法は、スタートレックのような冷たいコマンドであってはなりません」と語る彼女。

http://www.wired.com/2014/07/jibo-family-robot/

オトコノコの僕は、スタートレックのほうがいいじゃないかとおもってしまう。
が、家庭ではたぶん、彼女の言うとおりだろう。

彼女が開発しているのは、いわば身体を持ったタブレット。
30cmほどの身長のロボットが、人間的な傾聴姿勢であなたの発声するコマンドを聞き取ります。

この姿勢の変化は、ユーザーに対するひとつの、リッチな視覚的出力たりえます。
Physical User Interfaceをデザインする仕事が生まれようとしている。

出力のみならず、入力も、ロボットの身体に対する、ヒトの手の触れ方、やがてはもしかしたら身体全体での相互作用によって、自由に定義できるようになることも、容易に想像ができます。

視覚出力が二次元平面上でのみというGUIの時代がかつてあったよね、と振り返って語られるのは、そう遠い将来ではないかもしれません。

その頃には、PUIを持たない、GUIのみのソフトやサービスは、いまのCUIしか持たないそれらのように、硬派なオトコノコだけが愛用するものになっていることでしょう。

LimeChatのURL認識

LimeChatのマクロ・スクリプトが魔進化すぎる件で

さらに、メッセージ内にURLがあった場合、それをダブルクリックした場合の動作を、LimeChatでは3種類定義できるようです。
シェルにまかせるとか、アプリを名指し指定とかもできるような…。
もしかして、これ、ブラウザではすっごい難しい

• JPG画像へのリンクをクリックしたらPhotoshopで開く
• フォルダへのリンクをクリックしたらExplorerで開く（IEでは容易、Firefoxではもしかして可能、Chromeでは不可能といわれている）

なんてこともあっさりできちゃったりして…！！

なんて夢をふくらませていましたが、実際はこうでした：

http系とftp系しかURLとして見なしてくれませんね。
ショボーン

まあ考えてみたらそれ以外をURL(URI)と見なす意義がIRC的にはあまりありませんね。
というかヘタなスキームをアクティブにしたら、セキュリティリスクを仕込んでるというそしりを受けてしまいますね。

しかし！

LimeChatはスクリプトのほうで、Explorerでパスを開くshellExplore関数、シェルでコマンドを開くshellOpen関数、さらに汎用的なexecuteCommand関数が使えるようです。
ということは、UNCを含むメッセージが来たら（あるいは[OPEN]等の文字列のあとにUNCっぽいブツがあれば）そのUNCが指し示すフォルダか画像ファイルをExplorerかPhotoshopで開く、というプログラミングはできそうです。
別作業中にこれやられたら実にウザそうです。

その方向で実装へ向け構築していきたいとおもいます。

IRCでクメール文字など

LimeChatでテケトーなIRCサーバにつないで（カンボジアからつなぐオラのような者をも受け入れてくれるありがたいお方！）、
クメール文字などを打ってみるtest

エンコーディングをLimeChat（というか日本IRC界の）デフォルトのSJISからUTF-8へ変更。
フォントはとりあえずArial Unicode MS。 # 能登さんまだDL中
クメール文字のために、LimeChatのログのテキストと入力テキストをデフォルトの10ptから20ptに変更してあります。（左のタイムスタンプやNickも、設定すればちゃんと大きくできます）

ベトナム語と朝鮮語の可能表現 なぜ同じ構造なのか

朝鮮語で「～できる」という言い方を学んだとき、ベトナム語と同じ言い方するんだな～、とおもった。

• có thể ～
• ～(으)ㄹ 수 있다 = (eu)l su itta

いずれも、何かがある、という言い方を用いて可能を表現するのだ。

私が学んだ中国語の初歩の範囲において、可能をこのような表現であらわすことはない。

遠く離れた地に住むこの2つの民族が、なぜ同じ構造の言語を用いているのか？

よく言われるように、日本語とクメール語も、「～してみる」「～しておく」などの構造がまるで同じである。

アジアは原アジアというものがあり、そのどまんなかに中国人というミュータントが現れ、原アジアの末裔は日本・朝鮮・ベトナム・カンボジアといった周縁部にのみ残っている、という印象を私は持っている。

この朝鮮語とベトナム語の可能表現の類似は、このことを裏付ける事象のひとつのようにもおもわれる。

作業手順とチェックリストは実は水と油

リンク先
http://itpro.nikkeibp.co.jp/article/Watcher/20110208/357000/?s2p

を私なりに大胆に超解釈すると、
「標準手順書厳守の職場ではチェックリストの有効性はかなり低い」
ということかなとおもった。

標準手順書そのものに改善の余地があることが多く、そのような場合、作業者が「確認できない」「確認しづらい」状況になっていることが多々あり、それでは個人が「気をつける」「チェックを徹底する」と言ってもバグの作り込みは防げないからだ。

チェックリストが弾くことのできるミスは「確認しなかった」という故意的なものだけであり、人事制度と評価体系をある程度作り込んでいれば、そのようなことは少ないからだ。