OTCHY.NET

昨年、うちの近くにオープンした SEIYU があるのですが、その店舗ではセルフレジというものが導入されていました。
このセルフレジというのは、商品の購入時に自分でバーコードを読み込ませて、自分でそのまま支払いを済ませる事が出来るというものです。
支払いにはカードも使う事が出来て、提携クレジットならサインレス、そうでない場合でも電子パネルにサインをする事でカード決済を行う事が出来ます。
カードのサインって電子的なものでも良かったんですね。知りませんでした。

さて、そんなセルフレジですが、もちろん SEIYU の思惑としては人件費削減でしょう。1 台あたり何百万円する機械なのかは分かりませんが、数年運用すればペイする程度ではないかと予想されます。
万引きの可能性も考えてはいるでしょうが、操作補助のために 4 台の機械につき 1 人の人員を当てているので、そう簡単ではないですし、比較的オープンな作りになっている上、監視カメラも回っているので、セルフレジの場所で万引きというのはあまりなさそうです。

SEIYU の思惑に載せられるようで悔しくもあるのですが、有人のレジよりも回転が速く待たされないのと、バーコードを通すそばから袋詰めが完了するという利点があって、たびたび利用しています。
カゴを載せる台 → バーコードを読み込ませる台 → レジ袋のクチが開いている台の順に並んでいて、実にスムーズなんですよ。
経費削減だけでなく、利用者にも利便性を提供しているという上手い例ではないでしょうか。

ここまでがエコノミーなエコの話。

一方、ここ数年来、エコといえばエコロジーですね。
どれほどの効果があるかの科学的な検証はさておき、マイバッグ運動はずいぶん定着したように思います。
もちろん SEIYU も例外ではなく、有人レジで会計をする際は必ず「レジ袋はご利用になりますか？」と聞かれます。
これって、従来はレジ袋を利用するのがデフォルトだったのに、いまや利用しない事がデフォルトという事ですよね。ずいぶんと変わったもんだと思います。

うちはこんなにエコロジーなんですよ、自然に優しい企業なんです。というアピールする事で、企業イメージがアップする社会になってきたというのは、ある種、人間社会の豊かさの象徴であるようにも感じます。
こういう戦略が奏効するのはやはり先進国が中心ですしね。

さあ、ここでまたセルフレジの話に戻ってきます。
本当の意味でエコロジーを目指すのであれば、今の社会のスキームで言えば、レジ袋の利用は減らせるだけ減らした方がいいんですよね。

ところが、最新の方法論で華々しくデビューしたはずのセルフレジは、レジ袋使い放題なんですよ。
むしろ配置的にはレジ袋の利用を推奨しているような感じです。
マイバッグを利用する事ももちろん出来ますが、レジ袋のクチを広げるための棒があって、そこに大量のレジ袋がセットされているので、セルフレジを使用してさっさと会計を済ましてしまいたい層は、当たり前のようにレジ袋を使うと思います。
有人レジだとちょっと躊躇してしまうような人でも、セルフレジなら楽々レジ袋です。

そう、セルフレジでは昔通りレジ袋を使う方がデフォルトなんですね。

なぜか？
理由は簡単です。

レジ袋を使った方が回転が速くなってより少ない台数のレジで客をさばける上に、本当はレジ袋が欲しいのにちょっと躊躇してしまう層を取り込めます。
そして、レジ袋の価格は有人レジの人件費に比べれば微々たるものです。
わずかな投資で大きなリターン。素晴らしい戦略です。

以上、どんなにエコエコ叫んでみたところで、結局のところ、エコノミーの前にはエコロジーは吹き飛んでしまうんだなというお話でした。

ちょっと思うところあって調べたのでメモしておきます。
結局使わない事になったんですが。

mb_regex_encoding('UTF-8');
if (preg_match("/^[ぁ-んー]+$/u", $str)) {
    // ひらがな
} else if (preg_match("/^[ァ-ヶー]+$/u", $str)) {
    // カタカナ
} else if (preg_match("/^[一-龠]+$/u", $str)) {
    // 漢字
}

mb_regex_encoding(‘UTF-8′); は正規表現の基準となる文字コードの指定です。
php.ini がいじれる環境なら、[mbstring] セクションに、mbstring.internal_encoding = UTF-8 とした方が良いかと思います。

[あ-ん] 等の指定は、Unicode 上でひらがなやカタカナを表す文字コードの最初と最後の文字を、範囲指定しています。
また、厳密に言うと漢字の最後は “龠” では無いのですが、一般的に漢字と見なされる範囲の中で、最後にある JIS 第二水準の漢字であるため、この字を採用しています。(この漢字の範囲には、中国の漢字やハングルなどが含まれます)
全然異なる文脈ですが、このページで詳しく考察されています。

preg_match の u フラグは、UTF-8 を正しく扱えるようにするためのフラグです。これがないと、文字コードの範囲指定などが正しく動作しないようです。

WordPress with Twitter の不具合を修正した記念に、Greasemonkey を書く時に頻繁に利用する関数をまとめたので、公開してみます。
外部の JavaScript ライブラリを読み込む方法を解説したサイトもありますが、そこまで大げさな機能が必要でもなく、軽く動作させたいときに便利です。
特に共通ライブラリを利用すると、Firefox 以外のブラウザの対応も無駄に読み込む事になるので、スマートじゃないなぁと思います。

var d = document;
var $ = function(id) { return d.getElementById(id); }
var $x = function(xp) { return d.evaluate(xp, d, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null).singleNodeValue; }
var $a = function(xp) { var r = d.evaluate(xp, d, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null); var a=[]; for(var i=0; i<r.snapshotLength; i++){ a.push(r.snapshotItem(i)); } return a; }
var $e = function(e,t,f) { if (!e) return; e.addEventListener(t, f, false); }

• d
  document のエイリアスです。目的はコードの短縮と実行速度の高速化です。
• $ 関数
  getElementById のエイリアスです。説明不要でしょう。
• $x 関数
  xpath を引数としてとり、最初に一致したエレメントを返します。
• $a 関数
  xpath を引数としてとり、一致したエレメント全てを配列で返します。
• $e 関数
  addEventListener のエイリアスです。説明不要でしょう。

Greasemonkey で既存のサイトをいじくる場合、対象のエレメントに必ずしも id が振られているとは限らない (むしろそうなっていない場合が多い) ので、xpath から任意のエレメントを簡単に取得できる、$x/$a は有用かなと思います。
この辺は、ブラウザ間の互換を考えないといけない汎用ライブラリではなかなか実装できないところですね。

もちろん、下記のように名前空間を汚さないように書くのは基本的なマナーです。
$ 関数とかをグローバル (window オブジェクトのメンバ) に定義しちゃうと、サイトによっては壊滅的に動作がおかしくなってしまうかも？

(function(){
    // 処理本体
})();

2009-01-26 追記 — コメントでご指摘いただいた点について

Greasemonkey の実行環境はサンドボックス上にあるので、function によるラッピングは不要だそうです。
ちまたでよく見る GM は大概ラッピングされていたので、ずっと勘違いしていました。公式マニュアルにリンクしておきます。
公式マニュアル

$a のパフォーマンスが良くないという話もありますが、配列のサイズがあらかじめ確定しているので、配列のインスタンス生成時にサイズを指定するようにして、push を使わないほうがいいよ。って事かと思います。気になる方は直して使って下さい。

いずれにせよ、ご指摘ありがとうございました。

レイアウトの基本となる画面サイズ色々：ITpro

実際のレイアウトサイズの目安には基準があり、最も低い環境に配慮した SVGAサイズなら760×420ピクセルが、標準的なサイズのXGAなら955×600ピクセルが妥当な大きさである。

ウェブサイトを作成するのであれば、最初のデザイン段階で気にしたいですね。

OTCHY.NET は、XGA 以上の環境を基準として、横幅を 950 ピクセル に合わせています。
ダウンロードした 2 カラムのWP テーマを改造して 3 カラム×950 ピクセルにしたものです。
Yahoo も今は 950 ピクセルなので、現状で最もポピュラーな横幅かと思います。

さて、それだけではおもしろくないので、WCR の先月 (2008年12月) のアクセス解析結果から、ユーザの画面の解像度部分を公開してみます。
WCR というサイトであるが故のバイアスはかかっていますが、IE の比率が約 8 割のサイトなので、概ね今時の一般的な PC 環境と合致していると考えられます。
(技術寄りのサイトほど、FireFox の比率が高まる傾向があるため)

これを見て気づいたのは、XGA と SXGA を合わせて過半数ではあるものの、1280 × 800 や、1440 × 900 等のワイド画面が思ったより多いという事です。
最近のノート PC でワイド画面が増えている事が影響していると思われます。

11位以下を見ても、横の解像度が 1024 ピクセル未満の環境は、1 % を割り込む状況なので、「横幅は 600 ピクセル以内で！」と声高に喧伝されていた 20 世紀終盤頃からすると、隔世の感がありますね。

ちなみに、WCR 自体は横幅を 900 ピクセルでデザインしています。
900 ピクセルオーバーのデザインでは、XGA 環境であっても、ブラウザのサイドバーにブックマークを表示している場合に右端が切れてしまうためです。
WCR では、右サイドバーにも比較的重要な情報を載せているため、多少右端が切れてしまっても、情報を取得できるように配慮しています。

逆に OTCHY.NET は同じ 3 カラムでも、サイドバーを右に 2 本の構成として、一番右のバーには比較的重要度の低い情報を載せています。
個人ブログサイトという事で、ある程度割り切った作りに出来るのは楽ですね。

某ゲーム会社に勤める友人が、巨大なバイナリを軽々と扱えるバージョン管理システムは無いものかというので、どんなシステムだったら実現可能か夢想してみました。

既存のバージョン管理システムの問題点

CVS/SVN などの中央管理型と Git を始めとする最近流行の分散管理型とがありますが、「巨大なバイナリ」を扱うという点に置いては、どちらも根本的な問題があります。
数 10 GB の単位のデータを扱う上では、今のネットワーク帯域が狭すぎるためです。

この点だけで言うと、マスタのフルサイズのコピーを持つ現在の分散型はきわめて不利と言わざるを得ません。
かといって、中央管理型が有利かというと、それはそれで中央サーバの帯域が圧迫されまくってしまう上、そもそも帯域が狭すぎて DL に時間がかかってしまうという問題は解決できていません。

そんなわけで、巨大なバイナリを扱う上では、そのコピーに大きなコストがかかるという事を前提に、あるべきシステムを考えてみます。

中央型か分散型か

既存のシステムでは分散型の方が不利というのは確実ですが、いざ実際のシステムを考えた場合には、やはり分散型を基準にした方が良いと思われます。
コミットの度に中央サーバにアクセスするのは、ネットワークの負荷が高すぎます。

そこで、分散型を採用しつつ、リポジトリのマスタのコピーはローカルに持たないというアプローチを採用したいと思います。

ではどこにマスタを持つのか？

答えは P2P の中にありました。

Winny ネットワークの事を考えてみましょう。
Winny ネットワーク自体を超巨大な 1 つの仮想的なストレージと考えた場合に、その全てのファイルを持ったサーバは 1 台として無く、確実にファイルが存在するのは、始めにオリジナルを流したその PC だけです。

もちろん、ダウンロードした PC にはオリジナルのコピーが存在する事になりますが、どこの誰が DL するかは分からないですし、断片だけを持った PC が何台あるかも分からないという意味で、”確実に” オリジナルが存在するのは放流元だけと考えて下さい。

この仮想的なストレージを、P2P 型リポジトリとしてバージョン管理システムに活かす事は出来ないでしょうか？

P2P 型リポジトリとは

仮に Winny ネットワークをリポジトリのように使用する場合、自由度が高すぎて、開発作業を行うのに十分な管理が出来ません。
そこで、P2P 型リポジトリには、中央サーバが必要だと考えられます。
ただ、SVN 等とは違って、中央サーバはリポジトリを持つのではなく、いわば仮想リポジトリのファイルツリーを管理するサーバです。

ユーザは中央サーバを参照する事によって、仮想リポジトリの全容を把握する事は出来ますが、それを元にファイルを取得する場合、ファイルの取得先はあくまで P2P でオリジナルを持った PC からダウンロードされます。

ファイルのコミットは、一応、中央サーバに対して行います。
このとき、中央サーバは何というファイルがどの PC でコミットされたか、そのバージョンがいくつか、を記録しますが、ファイル自体は個々の PC にあるままの状態になります。
本当にそのファイルが他の人から必要とされるまでは、帯域を消費しないという事です。

これが P2P 型のポイントになります。

P2P 型利用イメージ

1. ファイルの新規コミット
   A さんがローカル PC で新しくリポジトリに追加するファイルを作成したら、中央サーバに対してコミットを宣言します。
   このとき、仮想リポジトリのファイルツリーでどのパスにコミットするかを指定しますが、中央サーバが管理するのはオリジナルが存在する場所と、バージョン情報と、仮想リポジトリのパスだけです。
2. ファイルの取得
   B さんがそのファイルを更新しようとする場合、まず中央サーバに問い合わせて、オリジナルの存在する場所を取得します。
   その結果、A さんの PC にファイルが存在する事が分かったら、あとは、A さんと B さんの間で P2P 通信を行い、ファイルをコピーします。
3. ファイルの更新
   B さんが、ファイルの更新を終えたら、中央サーバにコミットします。
   この時点で、ファイルのバージョンと、オリジナルが存在する場所が更新されます。もちろん、新規コミット時と同様、ファイル自体のコピーは行われません。
4. コミットの通知
   B さんがファイルをコミットした事を、中央サーバは A さんに対してプッシュ型で通知します。このタイミングで A さんは、新しいバージョンのファイルをローカルに取り込むか、取り込まないかを選択します(クライアントアプリでは、自動取り込み or 自動拒否オプションなんかを実装して欲しいですね)。
   また、A さん以外にも、過去に同じファイルを編集した人がいる場合、全員のところに通知がいくようにします。近い将来、再度ファイルを更新する予定がある人は、このタイミングで取り込んでおいた方が良いです。

コミットの通知については、少し説明を加えます。

複数の人が関わるバージョン管理システムではどうしても「競合」が発生します。ファイルを取り込んでコミットするまでの間に、自分以外の人が同じファイルを編集しているという状態です。
従来のバージョン管理システムでは、競合の発生が明らかになるのはコミット (もしくは明示的な更新) を行うタイミングなので、そのタイミングでリポジトリから最新を取りなおして内容をマージするという事が行われています。

しかし、巨大バイナリのダウンロードにはどうしても一定の時間がかかってしまうので、いざファイルをコミットしようとした時に競合が明らかになるようだと、ダウンロードからやり直しになり非効率です。
さらに対象がバイナリファイルとなると、マージも簡単ではありません。

コミット通知は巨大バイナリの競合をなるべく回避するための仕組みになります。
競合を完全に防ぐ事は出来ませんが、コミット通知＋人と人とのコミュニケーションがあれば、大概のケースでは問題なく運用できるのではないでしょうか。

以上が、P2P 型バージョン管理システムのあらましになります。

P2P 型をさらに改良する

さらに追加で、以下のような機能を実装すると幸せになれそうな気がします。

• 断片キャッシュ機能
  まさに Winny と同様の発想です。ファイルのダウンロードの際には途中の経路に断片をキャッシュさせる事で、他の人が同じファイルを必要とした時にネットワーク的に最も近い端末からダウンロードする事が出来るようになります。
  狭い範囲での利用であれば、専用のキャッシュサーバを持つような構成にすることで、よりパフォーマンスを稼げるでしょう。また、複数拠点の開発ならば、キャッシュサーバは必要不可欠と考えられます。
• 差分ダウンロード機能
  バイナリでこれが実現可能なのかは分からないのですが、可能なのであれば更新時は差分のみをダウンロードしてマージする機能が欲しいです。
  非圧縮の画像とか、MotionJPG などファイルタイプに特化すれば一部は実現可能な気もします。
• ファイル圧縮機能
  現状のマシンパワーで言えば、圧縮・展開のコストの方がネットワーク帯域よりも安いので、ファイルコピーを行う際に自動的に圧縮を行う機能は、プロトコルレベルで実装してしまって良いかと思います。
• バックアップ機能
  オリジナルファイルが分散してしまう事でバックアップに不安が残りますが、それは、中央サーバが仮想リポジトリをミラーリングすることで解決を試みます。
  PC のアイドル時やネットワークが比較的すいている時などに、中央サーバから各クライアントのオリジナルファイルを吸い上げるようにしておきます。
  「コミットから 24 時間以上経ったら、PC 負荷が高くても吸い上げを開始する」オプションなんかも欲しいですね。
  このミラーリングされたリポジトリは、通常時は一切使用しませんが、万一データが失われた際にバックアップとして使用する事が出来ます。

利用シーン

P2P 型バージョン管理システムは、かなり限定された環境でのみ大きな効果を発揮します。通常のソースコードの管理であれば、SVN や Git の方が確実に管理しやすいです。
そもそも、ソースコードのようにコンパイル時に全てのセットが必要なものについては、P2P 型のアプローチは全く無意味です。
まさに巨大バイナリ専用と考えた方がいいかもしれません。

開発を行っている部署単位で、全員まとめて一気に導入というのが一番あり得る利用シーンですね。1TB のストレージと 1 Gbps のネットワークは全員の PC に標準装備という様な環境でのみ、活用可能なシステムだと考えられます。

あとは

誰か作んないですかね～。