2002-05-26
_ target指定
そこここでリンクのtarget指定を_blankにしているのがいいとか悪いとかうざいとかうざくないとかいう話題を見かけたりして、個人的にはその手の話は一般論としてはケースバイケースとしかいいようがないと思うんだけど、textmaniaとしての見解というのも一応あるんで試しに書いておこう。
フレームを使っていないページにおいて、target指定は設定しない方がユーザーが自由にページの開き方（同窓/別窓）を選択できるというメリットがある。だから、特に理由がない限りはtarget指定はなしが基本。
textmaniaのnewlistみたいなリンクページの場合、そのページを使って多数のリンクをたどるという使い方を想定している。それでもし同窓でリンクをたどられてブラウザが極力キャッシュを使わない設定になっていると、リンクをたどって戻ってくるたびにnewpageに対しての読み込みが発生する。newpageは非gz圧縮版だと約140kバイトあるんで、そんなのをいちいちリロードされていたんじゃ転送量がもったいない。だから、newlistページではtarget指定は_blank固定にしてある。
textmaniaのmylistも、基本的には同じ考え方が適用されるが、mylistの場合は使う人によってそこに表示されるリンク数が異なる。リンク数が少ない場合は、わざわざtargetを_blank固定にするほどのことはない。だから、初期設定ではtarget指定はなし。しかし、ある程度以上登録数が多くなった場合は、タブブラウザユーザーの利便を考えて、optionページからtarget指定を_blankに変更することができるようにしてある。
2003-05-26
_ 駅のロッカー、鍵は携帯電話で from ZDNet (13:49)
（携帯）電話の番号通知機能を鍵の代わりに使うってアイディアは、いろいろ応用が利きそうだな。インターネット上のサービスなんかでも、携帯電話でいったんどこかに電話をかけることによって、一定時間その電話番号に結びつけられたIDが有効になり、IDが有効になっている間だけログイン可能になる、みたいな感じのサービス形態は取れそうだ。個体IDを取得できる端末ならば、携帯電話経由でWebサイトにアクセスすると、通常のサービス用ワンタイムパスワードが発効される、みたいな仕組みも作れるな。ただ、携帯電話番号なんてものがどれだけ鍵として有効なのか、という議論はありそうだけど。
_ RGBに白を加えてTFT液晶の輝度をさらに向上させる新技術 - Samsungが開発 from MYCOM PC WEB (13:49)
- RGBに白を加えてTFT液晶の輝度をさらに向上させる新技術 - Samsungが開発 - http://pcweb.mycom.co.jp/news/2003/05/22/26.html
なるほど。光の三原色を均等に混ぜると白（グレースケール）になるからといって、白（グレースケール）を造るのに必ずしも三原色を混ぜる必要はないんだよな。インク印刷でわざわざ黒を用意しているような感じか。
_ Opinion：今こそインターネットを再構築する時だ from ZDNet (13:49)
- Opinion：今こそインターネットを再構築する時だ - http://www.zdnet.co.jp/enterprise/0305/23/epn01.html
NotesとGrooveを作った人が挙げる、現在のインターネット上でさまざまなアプリケーションを構築しようとしたときの問題点。
>分散化したインターネットアーキテクチャ上で機能する、標準的な認証とセキュリティモデルを作り出すことである。
>一人の人間が使うすべての端末を同期する、標準的な手法が欠如している点だ。
確かにその2点に標準がないのは問題だよな。この辺に関して、俺の場合はアプリケーションレイヤーより下はあまり考えないんだけど、結局現状のインターネット技術の上に、アプリケーションレイヤーだけでちゃんと使える（セキュアで信頼性の高い）標準的な手法を確立するのは難しそうだし、もっと低レベルなところ（ネットワークレイヤーあたり）からの改善を考える必要があるんだろう。
ハードウェアキーというアプローチ（Palladiumとか）も悪くないけど、特定ハードウェア（しかも特定メーカーの）だけでしか使えないんじゃ意味がないしな。
と書いた瞬間の思いつき。ものすごくリッチなアプローチとして、セッションごとに鍵ペアを生成して専用のHTTPS（もどき）で通信するってのはどうだろう？ 鍵ペアの結びつきを解決する手段を考える必要があるけど、そっちは鍵とは無関係なキーを使って解決すればいい。その部分は暗号化せずに通す必要があるな。ただ、そっちは盗まれても構わない。単にサーバーにどの鍵ペアを使ってデコードするかを通知するためだけのキーであって、実データは鍵ペアを知らなければ読めないし。ものすごくコストはかかりそうだし、httpdにもクライアントにも手を加える必要があるけれども、逆にいうとそれだけのコストでセキュアな通信が出来るならば結構いいんじゃないか。とかいいつつHTTPSの仕組みってよく知らないんだよな。ちゃんと調べておかないと。
2005-05-26
_ Windows環境でバイナリ配布の4.1.11を (13:48)
default-character-set UTF-8で使おうとしたんだけど、my.iniを書き換えても反映されない。もしかしてmy.iniって見てないの？ しょうがないんで必ずプログラムの頭で
set names utf8
とかするようにしてごまかしていたんだけど、ふと思い立ってMySQLサービスの起動オプションに--default-character-set=utf8をつけたら、ちゃんと効いた。そういやそっちで指定する手もあったんだっけ。
それにしても、MySQL 4.1以降はいろいろ扱いが面倒だなー。
_ ゴミを残さずsession_regenerate_idする (16:34)
単にsession_regenerate_idしただけでは、古いセッションIDにリンクしたセッションデータが消えないので、
session_start(); $tmp = $_SESSION; session_destroy(); session_start(); session_regenerate_id(); $_SESSION = $tmp;
なんて感じで回避していたんだけど、これだと古いセッションIDにリンクした空のセッションデータが残るんでうざいなー（セキュリティ的には問題ないけど）と思っていた。けど、次のようにやればゴミを残さずにセッションIDの付け替えができそうだな。
session_start(); $tmp = $_SESSION; session_destroy(); session_id(md5(uniqid(rand(), 1))); session_start(); $_SESSION = $tmp;
新しいセッションIDの生成ロジックは「md5(uniqid(rand(), 1))」でいいのかという点については、要検討。
このセクションに対するはてなブックマーク
2006-05-26
_ Zend_Db_Tableにシリアライズしたデータを格納する方法は？
text型（blogblobでもいいけど）のカラムを一個作っておいて、コードからはそれを連想配列として扱いつつ、DBに書き込む前にseriailizeして保存、DBから取得する際にはunserializeしてから取得したいわけだ。
保存する方だけならば、
class Foo extends Zend_Db_Table
{
public function insert(&$data)
{
$data['bar'] = serialize($data['bar']);
return parent::insert($data);
}
// updateも同様
}
とかすればいいけど、読み込む際に自動的にunserializeするいい方法はないだろうか。
読み込みの実体はZend_Db_Table_RowとかZend_Db_Table_Rowsetクラスが受け持っているせいで、Zend_Db_Table側に直接読み込み全体をハンドリングする口がない。一応Zend_Db_Table::fetchRowをoverrideすれば、1行単位での読み込みはフックできるけど、fetchAllとか配列渡しのfindとかには対応できないしなー。
というのを昨日から考えているんだけどまだいい方法を思いつかない。
_ Zend_Db_Tableにシリアライズしたデータを格納する方法 その2
外部から解決する方法をいろいろ試してみたけれど、結局きれいに対応するのは無理っぽい。っつーか外部からの対応だと、不完全な方法しか思いつかね。
ってことで、直接Zend_Db_Table_Rowを書き換える汚い方法で対処してみた。
class Zend_Db_Table_Row
{
public function __construct($config)
{
....
} else {
$this->_data = (array) $config['data'];
if (is_callable(array($this->_table, 'fetchCallback'))) {
$this->_table->fetchCallback($this->_data);
}
}
}
}
なんてものを追加してしまう。すると、データ付きのRowが生成されるときに、そのZend_Db_TableオブジェクトにfetchCallbackというメソッドがあれば、データハッシュを引数にしてそのメソッドを呼び出す。そうしておけば、
class Foo extends Zend_Db_Table
{
public function insert(&data)
{
$data['bar'] = serialize($data['bar']);
return parent::insert($data);
}
// updateも同様
public function fetchCallback(&$data)
{
$data['bar'] = unserialize($data['bar']);
}
}
なんて感じで、読み書きでの自動シリアライズ、アンシリアライズを書けるようになる。ひとまずしばらくこれでごまかしておこう。2行の追加程度ならば、Zend Frameworkのバージョンアップ時の追随もそれほどつらくないだろうし。
