Home

技術日記
[Zend Framework] Zend_Application動作原理の翻訳Edit

Zend_Application動作原理の原文はこちら。

4.3. 動作原理

MVCアプリケーションを設定して動かすためには、データベース、ビューやビューヘルパー、レイアウトなどの設定や、プラグイン、アクションヘルパーの登録などなど、多くの機能を利用するためのコードがたくさん必要になる。 加えて、テストやcronタスク、サービススクリプトなどを実行するために、同じコードを再利用したいこともよくあるだろう。*1そういう処理は、ブートストラップ(起動準備処理*2)に書いてしまうのが簡単なやり方だが、環境依存の初期化処理が必要となることもあるだろう。たとえば、cronタスクにMVCはいらないし、サービススクリプトにはDBレイヤーだけあればいい。 Zend_Applicationでは、OOPによりブートストラップをカプセル化して再利用可能にすることで、そのような要望に応えようとしている。 Zend_Applicationは以下の3つの領域をサポートする。
  • Zend_Application: PHP環境設定の読み込み、インクルードパスおよび(クラスの)オートロードへの対応、対応するブートストラップのインスタンス化。
  • Zend_Application_Bootstrap: ブートストラップへのインターフェース。Zend_Application_Bootstrap_Bootstrapが、依存性チェックや必要に応じたリソースの読み込みなど、ブートストラップで必要となる機能群を提供する。
  • Zend_Application_Resource: ブートストラップによって必要に応じてロードされるリソースや、いくつかのデフォルトのリソースなど、標準的なリソースへのインターフェースを提供する。
開発者はアプリケーションのために、Zend_Application_Bootstrap_Bootstrapクラスを継承するか、あるいはZend_Application_Bootstrap_Bootstrapperインターフェースを(最低限)実装したブートストラップクラスを作成する。その呼び出し部(=public/index.php)ではZend_Applicationが読み込まれ、以下のパラメータを使ってインスタンス化される。
  • 現状の環境(定義名)
  • ブートストラップオプション群
ブートストラップオプション群は、ブートストラップクラスが書かれたファイルへのパスを含み、その他オプションとして以下のような要素を持つ。
  • 追加するインクルードパス
  • オートローダーに追加登録するネームスペース
  • 初期化に利用するphp.ini設定
  • ブートストラップクラスのクラス名(未指定ならば"Bootstrap")
  • ペアで使われるリソースのパスとプレフィックス*3
  • 利用するリソース(クラス名もしくは短縮名)
  • 追加でロードする設定ファイルのパス
  • その他の設定値
設定値はPHPの配列、Zend_Configオブジェクト、もしくは設定ファイルへのパスで表現する。
4.3.1. ブートストラップ
Zend_Applicationの二つ目の役割は、アプリケーションのブートストラップ(起動準備処理)を行うことだ。ブートストラップはZend_Application_Bootstrap_Bootstrapperインターフェースに以下のようなAPIとして定義されており、それらを最低限実装する必要がある。
interface Zend_Application_Bootstrap_Bootstrapper
{
public function __construct($application);
public function setOptions(array $options);
public function getApplication();
public function getEnvironment();
public function getClassResources();
public function getClassResourceNames();
public function bootstrap($resource = null);
public function run();
}
このAPIは、環境(定義名)と設定オプションをアプリケーションオブジェクトから受け取り、ブートストラップ時に用意する必要があるリソース群を知らせ、そしてブートストラップとアプリケーションの実行を行うためのものだ。 これらのインターフェースをスクラッチで、あるいはZend_Application_Bootstrap_BoostrapAbstractを継承して、あるいはZend_Application_Bootstrap_Bootstrapを利用して実装することができる。 これ以外にも、あなたが慣れなければならないことはたくさんある。
4.3.1.1. リソースメソッド
Zend_Application_Bootstrap_BootstrapAbstractの実装では、クラスにリソースメソッドというものを定義するようになっている。_initから始まるprotectedメソッドは、すべてリソースメソッドとして扱われる。 一つのリソースメソッドを実行するには、bootstrap()メソッドにそのリソース名を渡して呼ぶ。リソース名とは、メソッド名から_initを取り除いたものだ。 いくつかのリソースメソッドを実行したいならリソース名の配列を渡せばいい。すべてのリソースメソッドを実行する場合は引数なしで呼ぶ。 以下のブートストラップクラスを見てみよう。
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
protected function _initFoo()
{
// ...
}
protected function _initBar()
{
// ...
}
protected function _initBaz()
{
// ...
}
}
_initFoo()メソッドを実行したい場合は、以下のようにする。
$bootstrap->bootstrap('foo');
_initFoo()と_initBar()メソッドを実行したい場合は、以下のようになる。
$bootstrap->bootstrap(array('foo', 'bar'));
すべてのリソースメソッドを実行する場合は、引数なしでbootstrap()を呼ぶ。
$bootstrap->bootstrap();
4.3.1.2. リソースプラグインを利用したブートストラップ
よりブートストラップの再利用性を高くしたい人のために、リソースプラグインという仕組みも用意されている。これは(コードではなく)設定を使ってシンプルにリソースを利用できるようにする。後で作り方について説明するが、ここではまず使い方についてのみ説明する。 もしブートストラップでリソースプラグインを使いたいならば、Zend_Application_Bootstrap_ResourceBootstrapperインターフェースを追加実装する必要がある。このインターフェースはリソースプラグインの配置や登録、読み込みを行う。
interface Zend_Application_Bootstrap_ResourceBootstrapper
{
public function registerPluginResource($resource, $options = null);
public function unregisterPluginResource($resource);
public function hasPluginResource($resource);
public function getPluginResource($resource);
public function getPluginResources();
public function getPluginResourceNames();
public function setPluginLoader(Zend_Loader_PluginLoader_Interface $loader);
public function getPluginLoader();
}
リソースプラグインが提供する基本機能は、アプリケーションをまたがって再利用可能なリソースの初期化機構だ。これにより、ブートストラップを比較的クリーンに保つことができる。ブートストラップコードに手を加えず、新しいリソースを導入することができるのだ。 Zend_Application_Bootstrap_BootstrapAbstract(とそれを継承したZend_Application_Bootstrap_Bootstrap)にはこのインターフェースも実装されており、リソースプラグインを利用できるようになっている。 リソースプラグインを利用するには、アプリケーションオブジェクトやブートストラップのオプションとして、その設定を行う必要がある。これらは設定ファイルやオプションパラメータとして渡される。設定はリソース名のキーを持つ値のペアとなる。リソース名はクラスプレフィックスの後に続く部分となる。たとえばZend Frameworkに同梱されるリソースは、"Zend_Application_Resource_"というクラスプレフィックスを持ち、その後にリソース名が続くことになる。例を挙げると、
$application = new Zend_Application(APPLICATION_ENV, array(
'resources' => array(
'FrontController' => array(
'controllerDirectory' => APPLICATION_PATH . '/controllers',
),
),
));
これは、(controllerDirecotry)オプションが指定された"FrontController"リソースが使われることを示している。 独自のリソースプラグインを作る、もしくはサードパーティ製のリソースプラグインを使う場合、ブートストラップにそれらがどこにあるかを教えておく必要がある。ブートストラップは内部でZend_Loader_PluginLoaderを使うので、クラスプレフィックスと検索パスのペアが必要となる。 たとえば、APPLICATION_PATH/resources/に独自のリソースプラグインがあるとして、そのクラスプレフィックスがMy_Resourceだとすると、アプリケーションオブジェクトに以下のような情報を渡すことになる。
$application = new Zend_Application(APPLICATION_ENV, array(
'pluginPaths' => array(
'My_Resource' => APPLICATION_PATH . '/resources/',
),
'resources' => array(
'FrontController' => array(
'controllerDirectory' => APPLICATION_PATH . '/controllers',
),
),
));
これで指定したディレクトリのリソースを使えるようになる。 リソースメソッドのように、bootstrap()メソッドを使ってリソースプラグインを実行できる。リソースメソッド同様に、一つのリソースプラグイン、複数のプラグイン(配列を使って)、すべてのプラグインを指定できる。加えていうと、リソースメソッドと混在して実行することも可能だ。
// 一つ実行
$bootstrap->bootstrap('FrontController');
// 複数実行
$bootstrap->bootstrap(array('FrontController', 'Foo'));
// すべてのプラグインとメソッドを実行
$bootstrap->bootstrap();
4.3.1.3. リソースレジストリ
たいていのリソースメソッドやプラグインは、オブジェクトの初期化を行う。そして多くの場合、そのオブジェクトはアプリケーションの他のところでも利用される。その場合、オブジェクトにはどうやってアクセスすればいいだろうか? Zend_Application_Bootstrap_BootstrapAbstractは、それらのオブジェクトを保存するためのローカルなレジストリを用意しており、(リソースメソッドやプラグインで)リソースオブジェクトをreturnするだけで保存が行われる。 柔軟性を高くするために、レジストリは内部では"container"として参照される。オブジェクトだけがそこに保存される。リソースはリソース名にちなんだプロパティとして登録される。デフォルトでは、Zend_Registryインスタンスが利用されるが、他のオブジェクトを使うこともできる。setContainer()、getContainer()メソッドを使ってコンテナを操作できる。getResource($resource)でコンテナからリソースを取得し、hasResource($resource)でリソースが登録済みかどうかを調べることができる。 以下の例は、基本的なビューリソースだと思って欲しい
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
protected function _initView()
{
$view = new Zend_View();
// more initialization...
return $view;
}
}
登録されているか確認したり、リソースを取得したりするのは、以下のようなコードとなる。
// has/getResource()の二つを使う
if ($bootstrap->hasResource('view')) {
$view = $bootstrap->getResource('view');
}
// コンテナを通して
$container = $bootstrap->getContainer();
if (isset($container->view)) {
$view = $container->view;
}
レジストリやコンテナがグローバルではないことに気をつけて欲しい。つまり、リソース(オブジェクト)を取得するにはブートストラップにアクセスする必要があるのだ。Zend_Application_Bootstrap_Bootstrapはそのための方法を用意している。run()が実行されている間、ブートストラップは自分自身をフロントコントローラの"bootstrap"パラメータとして登録している。それを使えば、ルーターやディスパッチャー、プラグインやアクションコントローラからリソースオブジェクトにアクセスできるようになる。 たとえばアクションコントローラの中からビューリソースにアクセスしたい場合は、以下のようになる。
class FooController extends Zend_Controller_Action
{
public function init()
{
$bootstrap = $this->getInvokeArg('bootstrap');
$view = $bootstrap->getResource('view');
// ...
}
}
4.3.1.4. 依存性の追跡
リソースメソッドやプラグインを実行するだけでなく、それらが必ず1度だけ実行されることを保証する必要がある。アプリケーションをブートストラップするたびに、(リソースの初期化処理が)複数回実行されてしまうのではオーバーヘッドを招くことになるからだ。 また、いくつかのリソースは他のリソースに依存している可能性がある。この二つの問題を解決するために、Zend_Application_Bootstrap_BootstrapAbstractは簡単で効果的な依存性の追跡機構を備えている。 前記の通り、すべてのリソース(メソッドもしくはプラグイン)は、bootstrap($resource)メソッドの$resource指定によって、一つのリソース、もしくは複数のリソース(配列)、もしくはすべてのリソース(引数なし)がブートストラップされるようになっている。 あるリソースが他のリソースに依存する場合、依存先のリソースがすでにブートストラップ済みであることを保証するために、依存元のリソース(メソッドやプラグイン)コードの中で(依存先のリソースをブートストラップする)bootstrap()メソッドを呼んでおくべきだ。その後でもしも同じリソースがブートストラップされたとしても、その呼び出しは無視されることになる。 リソースメソッド内でのそのような(依存するリソースの)呼び出しを行う場合、以下のように書く。
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
protected function _initRequest()
{
// フロントコントローラが初期化済みであることを保証する
$this->bootstrap('FrontController');
// ブートストラップレジストリからフロントコントローラを取得する
$front = $this->getResource('FrontController');
$request = new Zend_Controller_Request_Http();
$request->setBaseUrl('/foo');
$front->setRequest($request);
// リクエストオブジェクトがブートストラップレジストリに保存されるようにする
return $request;
}
}

4.3.2. リソースプラグイン

前記の通り、再利用性の高いブートストラップリソースを作成し、あなたのコードから関係が薄い(リソース初期化の)コードを取り除きたいのならば、リソースプラグインを利用するといいだろう。Zend Frameworkはいくつもの標準的なリソースプラグインを同梱しているが、その意図は、開発者は独自に必要となるような初期化コードのみを書くべきだと考えるからだ。 リソースプラグインはZend_Application_Resource_Resourceインターフェースを実装すればいい。より簡単にはZend_Application_Resource_ResourceAbstractクラスを継承すればいい。基本インターフェースはシンプルだ。
interface Zend_Application_Resource_Resource
{
public function __construct($options = null);
public function setBootstrap(
Zend_Application_Bootstrap_Bootstrapper $bootstrap
);
public function getBootstrap();
public function setOptions(array $options);
public function getOptions();
public function init();
}
このインターフェースには、リソースはコンストラクタでオプションを受け取る、オプションの設定や取得が可能、ブートストラップオブジェクトの設定や取得が可能、そして初期化を実行するメソッドが定義されている。 次のサンプルは、アプリケーションで利用される一般的なビューの初期化処理を想定している。ドキュメントタイプ、CSS、JavaScriptを扱い、オプションから得た基本ドキュメントタイトルを渡す。そのような機能を持つリソースは以下のようになる。
class My_Resource_View extends Zend_Application_Resource_ResourceAbstract
{
protected $_view;
public function init()
{
// ビューを返し、レジストリに保存する
return $this->getView();
}
public function getView()
{
if (null === $this->_view) {
$options = $this->getOptions();
$title   = '';
if (array_key_exists('title', $options)) {
$title = $options['title'];
unset($options['title']);
}
$view = new Zend_View($options);
$view->doctype('XHTML1_STRICT');
$view->headTitle($title);
$view->headLink()->appendStylesheet('/css/site.css');
$view->headScript()->appendfile('/js/analytics.js');
$viewRenderer =
Zend_Controller_Action_HelperBroker::getStaticHelper(
'ViewRenderer'
);
$viewRenderer->setView($view);
$this->_view = $view;
}
return $this->_view;
}
}
このリソースプラグインのプレフィックスパスを登録すると、アプリケーションから使えるようになる。プラグインローダーを利用することにより、デフォルトの"View"リソースプラグインが上書きされ、独自のプラグインが代わりに利用されるようになる。

*1:サービススクリプトって、定期実行するわけではないコマンドライン系の処理のことか? たとえば初期セットアップスクリプトとか。日本語でもサービススクリプトっていうんだろうか? cronの方ならバッチが一番近い感じなんだけど。

*2:ブートストラップは日本語にせずに、そのままカタカナで書いてしまうことにした

*3:Bootstrapで使われているpluginpaths設定のことかなー。だったら「リソースのプレフィックスとパスのペア」って感じになる?

Published At2009-06-24 09:00Updated At2019-12-30 23:55

技術日記
[設計] URLの設計Edit

DB設計によって内部的なサービスのイメージがだいぶ固まってきたので、今度はURL設計を行うことで、外部から見たサービスのイメージを固めていく。
  • / - サイトトップページ。
  • /login - ログイン。
  • /logout - ログアウト。
  • /about - サイトの説明。
  • /search - 検索ページ。
  • /config - ユーザー設定変更。
  • /register - ユーザー登録。
  • /home/ - ログインしたユーザーのホームページ。
  • /uris/ - URI統計ページ。新着、注目など。
  • /uri/[uri_string]/ - [uri_string]というURLに関するページ。
  • /asins/ - ASIN統計ページ。同上。
  • /asin/[asin]/ - [asin]というASINに関するページ。
  • /location/[longitude]/[latitude]/ - [longitude]、[latitude]という位置に関するページ。
  • /tags/ - タグ統計ページ。同上。
  • /tag/[tagname]/ - [tagname]というタグに関するページ。
  • /dj/[personality_name]/ - [personality_name]のトップページ。
  • /dj/[personality_name]/date/[yyyy]/[mm]/[dd]/ - [personality_name]の[yyyy][mm][dd]の更新。
  • /dj/[personality_name]/talk/[talk_id]/ - [personality_name]の[talk_id]発言。
あまり機能を増やしすぎても、あまり使われないわりにはサービスが重くなるだけなので、この程度の機能があれば十分だろうか。実際に作り始めると、もう少しページは増えてしまうだろう。 また、上記URL群は情報表示のそれぞれの切り口での起点ページと位置づけ、実際にはそこに表示された要素からユーザーアクションなどに応じて、(Ajaxなどを使って)必要な情報が後付で追記されていく構成を考えている。 ただ、最初からその辺まで含めて設計を行うのは難しいので、まずはプロトタイプ的に上記URL構成のシンプルなWebアプリケーションを開発し、それを実際に使いながらユーザーインターフェースを洗練させていくというアプローチを取っていくつもりだ。

Published At2009-06-23 09:00Updated At2019-12-30 23:55

技術日記
DB設計ベースでのサービス設計Edit

私の場合、DBのテーブル設計を考えながらアプリケーションの機能をまとめていくので、まずはどういうサービスにしたいのかを考えながら、ざっくりとしたテーブル設計を書いてみた。 f:id:netjockey:20090622172526p:image 利用者はパーソナリティ(personalities)テーブルで管理される。NetJockeyというのは、twitterライクなマイクロブログの語り手をラジオのDJ(パーソナリティ)、その言葉の連なりをDJのトークに見立てて名付けたネーミングだ。だからパーソナリティ(personalities)がトーク(talks)するという形でのテーブル設計となっている。 トークに含まれるURL(talks_uris)、ASIN(talks_asins)、タグ(talks_tags)、位置情報(talks_locations)などを抽出することで、同じ話題に関するトークをまとめることができる。またURL(uris)に関しては、URLのFQDN(uris.hostname)に別途インデックスを用意することによって、URL完全一致だけでなく、「あるドメイン上のURLに関する話題」のような範囲を広げた形で話題を追うことも可能にする。位置情報に関してもGIS関連機能を使って「○○近くの話題」などを追いやすくする。 NetJockey内部でのやりとりに関しては、twitterの「@~」に相当するパーソナリティ対パーソナリティ(talks_personalities)のほかに、発言同士の関連性(talks_talks)も管理する。特定の発言に対する反応を明示する仕組みだ。表記法としては2chライクに「>>発言番号」などで表してもいいかもしれない。 話題をフォローする方法については、発言者(following_personalities)のほかに、URL(following_uris)、ASIN(following_asins)、タグ(following_tags)、トーク(following_talks)、位置(following_locations)などさまざまな方法を用意している。ただ、これをユーザーが手動でいちいち登録するというのでは使い勝手が良くないように思うので、基本的には自分のトーク中に含まれるURL、ASIN、タグ、位置情報、発言者、トークなどを自動的にフォロー対象に追加していく(古いものは自動消去?)といった形にすることを考えている。これならば自然な形でこれらの機能を利用することができるだろう。もちろん明示的に特定のフォロー対象を追加・削除することも可能にする。 フォローの反対に、見たくない情報を見なくて済むようにする方法としては、人間単位でのブロック(blocked_personalities)を用意している。個人レベルでのブロック機能については、私はあまり重きを置いていないのだが、スパム対策としてはこの手の機能は必要だろう。また、システム全体としてのブロック(public_blocked)も用意しておく。こちらに登録されたパーソナリティは、いわゆるスパム系パーソナリティとして通常の表示対象から除去することができるようにする。その逆に、システムからの通知などを強制的に表示するためのシステム全体としてのフォロー(public_following)と言うものも考えているが、実際に利用するかどうか微妙なところだ。 認証(authentications)に関しては、1470.netと同様に外部認証系APIを主に利用することを考えている。はてな認証API、typekey、OpenID、携帯端末IDあたりが主な認証手段となる。また、APIなどで利用するためのサービスローカルなパスワードも一応保持しておくことを考えている。 本当はもう一つ、ディレクトリ(directories)という話題をまとめる単位を用意することも考えていた。ディレクトリとは、2chにおける板的なもの。あるいは、NetNewsにおけるニュースグループ的なもの。つまり、システム側である程度話題の分類指針を示しておき、利用者がそこから自分の好きなディレクトリを選んで発言することによって、半強制的に話題をある程度分類してしまう、というアプローチだ。このディレクトリ自体をWikiとしてユーザーが自分たちで編集できるようにしておくことで、世の中の話題のカテゴライズがリアルタイムで視覚化できるのではないか、などとも妄想した。 これはこれで非常に面白そうにも思えるのだが、それがなくてもすでに話題の分類のための手段は十分に用意されているし、ディレクトリ+Wikiという仕組みはそれ自体がある程度以上に複雑すぎて、まともに立ち上げるのはすごく困難そうに思えた。そこでこの機能は割愛することに決めた。ただし、メインのサービスが十分うまく立ち上がった後に余力があれば、このアイディアは復活させるのも面白いように思っている。

Published At2009-06-22 09:00Updated At2019-12-30 23:55

日記
いろいろとオープンにやってみようかと思っているEdit

でまあ、単に新しいサービスを作るだけだったら、勝手に作って公開すればいいだけなんだけど、今回はちょっといつもと違った感じで作ろうかと考えている。というのは、ここに書いているような開発過程の情報だけでなく、サービスのソースコード自体もオープンに作ってしまおうかと思っていたりするのだ。ライセンスはまだ決めていないんだけど、基本フリーソフトウェア系のライセンスを適用するつもり。

実運用サービスのソースコードを公開してしまうってのはセキュリティ的にどうなんだとか、ソースコードを公開するとなるとその手間がかかってしまって開発が進まないんじゃないかとか、いろいろネガティブ要素はあるんだけど、それでも基本的にソースコード公開でやってしまいたいと思っている最大の理由は、個人でサービス運用するのがいい加減きつくなっているから。

趣味でやっているサービスはそれに対するモチベーションがあるうちはいいんだけど、モチベーションを失った場合に放り投げにくい。特にそれなりの規模になってくると、運用コストがお金的にも労力的にもかかってしまうんだけど、そういうものをモチベーションを失った状態で維持するのは、とってもきびしい。ソースコードを誰でも利用可能な形で公開しておけば、私がモチベーションを失った場合でも、誰かやる気とスキルがある人間がいれば、比較的手軽にクローンサービスを継続することが可能になってくるんで、だいぶ気が楽になってくる。

あと、今回はZend Frameworkのお勉強がてらサービスを作っていこうかと思っているんだけど、こういうそれなりの規模のサービス的なものをZend Frameworkで作ったソースコードが公開されているってのは、結構意義があるんじゃないかと思う。特にPHPに限らず、Webアプリケーションフレームワークを使ったソースコードって、小さなサンプルくらいしか見かけたことがない気がするんで、それなりの規模のサンプルアプリがあってもいいんじゃないだろうか。

ちなみに、ソースコードを公開して作ると言っても、基本的には自分一人で作ってしまうつもり。意見とか参考となるコードとかをいただけたら有用なものは取り込ませてもらうだろうけれども、アプリの開発自体にみんなの力を借りようと思って、ソースコードを公開するわけではない。特に、あまり多くの人の意見を聞きすぎると開発速度が遅くなってしまいそうなので、開発自体は基本ワンマンでやっていこうと思っている。

まあこうやって言うだけ言って、どのくらいちゃんと進めていくことができるかわからないけれども、ひとまずこんなことを考えてこのblogを立ち上げてみたわけですよ。

Published At2009-06-19 16:32Updated At2009-06-19 16:32

日記
はじめにEdit

ここは“NetJockey”(ネットジョッキー)の開発に関するさまざまな情報を記録するためのblogである。

“NetJockey”とは、現在構想&設計中のオンラインサービスの名前である。現在が絶賛放置運営中である1470.netの後継サービス的な内容となる。私の作るサービスは基本的に「自分がほしいサービスは自分で作りつつ、他人にも使えるようにしておこう」なので、要は自分が使いたいサービスを思いついたので、作ってみようと考えているわけだ。

どんなサービスなのかというと、ぶっちゃけSBM+twitterである。twitterのように、シンプルなテキストエリアにどんどんテキストを放り込んでいく。そこにURLが含まれているのならばそれはURLブックマークと同じである。同様にASINや位置情報などが含まれていればそれらも認識する。一つのテキストに複数のURLが含まれていてもかまわないし、その記述方法はURLとして機械的に抽出できるものならば、文頭にあろうが文中にあろうがかまわない。URLが含まれないテキストも許容する。

結局やりたいことは、

  • 入力のシンプル化 - 1470.netでやっていた自由度の高い(複数のURL、ASIN、位置情報などに対応した)ブックマークサービスを、フリーワード入力欄一つでサポートできるようにする
  • ミニブログ対応 - URLやASINなどのブックマーク対象がないテキストも許容する
  • リアルタイムで流れていくテキスト - 興味を持った人、URL、タグなどに関するテキストを抽出し、twitterのようにリアルタイムで読み流していくスタイルの閲覧に対応する

といった内容である。

Published At2009-06-19 13:32Updated At2009-06-19 13:32

日記
tDiaryを2.1.4から2.3.1にアップデートした。文字コードがEUC-JPからUTF-8に変わったはずなのに、何も変換操作をしなくても勝手にデータもアップグレードされてくれたっぽい?Edit

tDiaryを2.1.4から2.3.1にアップデートした。文字コードがEUC-JPからUTF-8に変わったはずなのに、何も変換操作をしなくても勝手にデータもアップグレードされてくれたっぽい?

ここ1年以上、RSSリーダーもほとんど放置状態だったんだけど、いったん未読をリセットしてからちらっと回ってみた感触では、1年以上見てなかった割には、ネット界はあんまり変わっていないように見えるなー。

実際、個人でのネットの活動にあんまりおもしろみを感じなくなって、(仕事と受動的な遊び以外は)何となくネットから離れていたんだけど、ここ最近ってあんまり大きな変化って起こってないのかな?

Published At2009-03-30 00:00Updated At2009-03-30 00:00

日記
熱狂小町 - 発言小町リーダー作りましたEdit

じわじわとブックマークされつつあるみたいなんで、こっちにも書いておきます。Google Codeを使ってみる実験でもあるんで、何かありましたらあちらにどうぞ。 メニュー 最近読んだトピック カテゴリー別トピック一覧 はてなブックマークに登録されているトピック一覧 トピックを表示

Published At2008-07-07 00:00Updated At2008-07-07 00:00

日記
obsoleteフラグEdit

blogとかの古い記事に、簡単にobsoleteフラグを付ける機能があるといいね。消しはしないけど、すでに現状に即していない記事ですよ、というのをわかりやすくするために。obsoleteフラグがついた記事は、古文書風にぼろぼろに表示される(CSSがあたる)といいのかな。

第三者からの評価として行う場合は、ソーシャルブックマークなんかでobsoleteタグを付けておいて、そのタグの数で識別する、なんてのもいいかもね。

あと、記事の掲載日時を表示するときには、単に「○○年×月△日」とだけ書くんじゃなくて、ある程度古くなったら自動的に「○○年×月△日(掲載から□年経過)」とか、その記事が古いことをわかりやすく表示するといいかもね。

っつーか、自分のところもそうだし何か調べていてググった場合もそうだけど、古い技術系の記事のobsolete度合いを簡単に識別する手段があると便利だよね。obsolete度評価専門のソーシャルブックマークとか誰かつくんね?

Published At2008-04-25 00:00Updated At2008-04-25 00:00

技術日記
Zend_Db_Select::where()メソッドの$typeEdit

trunkでは、

    * @param string   $cond  The WHERE condition.
* @param string   $value OPTIONAL A single value to quote into the condition.
* @param constant $type  OPTIONAL The type of the given value
* @return Zend_Db_Select This Zend_Db_Select object.
*/
public function where($cond, $value = null, $type = null)
{
if ((func_num_args() > 3) or (($type !== null) and ($type !== 0) and ($type !== 1) and ($type !== 2))) {
$value = func_get_args();
array_shift($value);
$type = null;
}
$this->_parts[self::WHERE][] = $this->_where($cond, $value, $type, true);
return $this;
}

なんて感じになっているんだけど、この「(($type !== null) and ($type !== 0) and ($type !== 1) and ($type !== 2))」ってのはどこから現れたんだ?

where()メソッドでは、

    * @param constant $type  OPTIONAL The type of the given value

になっているけど、ここから呼ばれている_where()メソッドでは、

    * @param string   $type   optional

になっているし、実際PDO_MYSQLを使ったZend_Db_Tableのinfo()では、DATA_TYPEはstringで返ってくる("varchar"とか"int"とか)。

0、1、2という数値から、Zend_Db::INT_TYPE = 0、Zend_Db::BIGINT_TYPE = 1、Zend_Db::FLOAT_TYPE = 2あたりが怪しそうな気がするけど、この値ってZend_Db_Adapter_Abstract内で$_numericDataTypesとして定義されて以降、まったく使われていないし、意味的にも$typeが数値ではなかった場合に$valueを配列扱いするっていう意味がわからない。

これのせいで、trunkにしたらZend_Db_Tableのリレーション周り(findParentRow()とか)が動かなくなっちゃったんだよなー(Zend_Db_Table_Row_Abstract::findParentRow()内でZend_Db_Table_Abstract::info()で取得したDATA_TYPEをそのまま渡しているため)。自前で直そうにも、コードの意味がわからなくて直せないし。

3/13追記

昨日更新されたrevision 8783で、上記の怪しげな条件文はばっさり削除された。なんだったんだ……。

Published At2008-03-12 00:00Updated At2019-12-30 23:56

技術日記
Zend_Controller_Dispatcher_Standardのtrunk 247行目Edit

           if (!$this->getParam('useDefaultControllerAlways') && !empty($controller)) {

           if (!$this->getParam('useDefaultControllerAlways') && empty($controller)) {

のような気がするんだけど、いい花粉が飛んでいて頭がぼーっとするせいで、いまいち自分の判断が信用できない。ここは、useDefaultControllerAlwaysが無効な場合は、コントローラ名が解決できない→例外を発生させる処理だよな。

Published At2008-03-11 00:00Updated At2019-12-30 23:56