Home

日記
tracのanonymous権限をほとんど削りましたEdit

いくつか置いてあるtracの設定を、ticketとかwikiとかをanonymous権限でもある程度いじれるようにしてあったんですが、tracを対象にしたspamが非常に多く、特にticketに関しては通常のインターフェースでメンテナンスすらできないし、wikiはメンテナンスはできるけれども数が多くていちいち対応してられない感じなんで、anonymous権限での操作は基本的に禁止にしてしまいました。本当は1470.net系のバグ管理で使おうと思っていたんだけどなー。もはやspam対策が充実していないと、オープンなバグ管理システムとしては使えないか。結局自作になるのかなー。

Published At2006-08-01 00:00Updated At2006-08-01 00:00

日記
MONO発売日カレンダーを追加しましたEdit

MONOの発売日カレンダー表示を追加しました。サイドバーなどから今日発売のMONOのようにリンクが張られています。あとトップページにも近日発売予定のMONOを掲載しています。

掲載対象となるのは、1470.net上でメモされた or 検索された or フィードから取得した結果、キャッシュに登録されているMONOのみですので、すべてのMONOが対象となる訳ではありませんが、Amazonの新商品リストは自動的にチェックするようにしておくので、たいていの新商品は載ってくると思います。

あと、発売日が未来で日付単位まで確定しているMONOのメモを取る際には、自動的にToDoに発売日を挿入するようにしました。発売日カレンダーをざっとながめて、欲しいものを適当にメモしていく、といった感じの使い方を想定しています。

今回は、テーブル構造を含めて結構大規模にあちこち変更したんで、もしかしたら何か不具合が出ているかもしれません。何かあったらここのコメントででも教えてください。

Published At2006-08-01 00:00Updated At2006-08-01 00:00

日記
MONO発売日カレンダーの表示単位を日単位に変更しましたEdit

最初は月単位の表示で十分だと思っていたんですが、新製品情報をまめにチェックするようにしたら、とてもじゃないけど月単位では表示しきれない感じだったんで、日単位で表示するように変更しました。

Published At2006-08-02 00:00Updated At2006-08-02 00:00

日記
MONO関連地味な改良Edit

発売日カレンダーの表示を、Amazonの商品カテゴリー別に表示できるようにしました。2006年08月05日発売のMONO[Book]みたいな感じです。

あと、MONO検索の際のソートオーダーを、発売日が新しい順に変更しました(デフォルトは売れ筋順)。

Published At2006-08-05 00:00Updated At2006-08-05 00:00

日記
spammerな感じの人が元気にメモを投稿しているけどEdit

どうしようかなー。削除するのは簡単なんだけど、ひとまず何をやるつもりなのか、しばらく様子を見ておこう。はてなの方のアカウントが先に無効になったりするかな?

マルチアカウントでばりばり投稿したりしない限りは、別に消さなくてもいいかなーと思っているんだけど、大量のマルチアカウントはさすがにうざいしなー。

ちなみに、HTTP_USER_AGENTにAlexa Toolbarとか出ているあたり、いかにもそういう方面で飯を食っている人って感じだ。

spam用に自動取得したっぽいアカウント一覧

apple5001sweet apple5002sweet apple5003sweet apple5004sweet apple5005sweet apple5006sweet apple5007sweet apple5008sweet apple5009sweet apple5010sweet egg5011sweet egg5012sweet egg5013sweet egg5014sweet egg5015sweet egg5016sweet egg5017sweet egg5018sweet jdkfnaf840 johyywrph3 jflnfowjr378 ggdnwgri8027 ktogqiwti95829 glejpqrh72 hgoti4woi9y0 nlghwkehjfut673 thfrlghr0p06jd ghhsjrjlu26496 i3otywkrjg gkerhtpey kjirdlofi839tke fo3u4joth5i sjfjg3uykfor yoejeu3pru yoyyp897r9 hro2gti4i2 jldnwo2u56of kjdi3ojojwir hi5u0utofji jyo6kifhk gljpskdt3o kgkpdmwi80 nwiry4ih2y5b i6mjeoe4g nhgitjew1 itj4ofj2jyp65 j79y39jf0 ju6032jf jw94756ufki0 jtej3o47ut ghjo3u8njg j5igonjflrh kjrnhelwo5o3y4 gkthjlrhu7ti7o fkrbt35o6urn970 jtkt8i06u3y jfhek3696 jirege6294 johrky36469 jfehe954hglrh ghekjr3996i rhjritp935 joeh370th tmjpo3y5mj hgo0tjep3 jfjt385 jgjrl303y j3ugjrhlryi9y hkebhelto9y jgklbrl720n jfkrbelk0u jele2029jo0 mjro392yt72 kgej730io mrldi54hridh90 fs4hd64vfiwsg high2000low dokodemo55 fhuebl87sgju lajow57839 woi8999cb dowcbksa8 sjuhasu982r5 zcxv87a sk8dh7rt6sf4 sga6dhj4eoy8 aksj133dhw tekuteku123po weoi837264 gjro98bn world9999wlfh cat22dog11sdu aoshd76234hb s6fugh947fhvo s7fj38fyj29ryb asug231g0y78u g4y6u8kj9lt3ad2 db37jgy4947alo uniextra129873 aiyt2736sdhfg10 awawawa6555g fhy2938hgdiuw asiyg37rg58yj7 qiwu3323gvhas3 piropiro101010 d64ht8hj69r d4f5g6h7j89k9 ko8976hg54td aqwsugd328746 w4e5r6t7y8u8 asidu2376sdhgf oity87kj87hyhh7 sonnnani293846 power8787jcdh t5y6u7i8o9i8u7 woeofuhdbf56r4 aq1sw2de3rf4t gt5hy6ju7ki8lo9 asiudg76dufhg8 asd6g7h8h89j qopqop068068 s2f5j7l8j5d2 sodiasiugd655 austfd387465h as6fy8jy9k80g o9i8u7y6t5r4dd gdhfgr764hdfg asiuy23765ahs s5d6f7g7h8 flash8080rush school2837 q728eh35rhfg qw87yweuhy9 asd_ouhas344 as623g9th0ppp porepore6868 aq37fhsi8eq m9n8b7ytfq super28376shgdf i1j1taji1asd1 do9068cdo zwmnzwmn37 uth74h63g_0e asuh7gf83nc2 s35inmwp49u l95ngu36_38fn rtyry37t7ugn bvbv65hgb7 ikdomwiesd10 ikdomwiesd11 ikdomwiesd12 ikdomwiesd13 ikdomwiesd14 ikdomwiesd15 ikdomwiesd16 ikdomwiesd17 ikdomwiesd18 ikdomwiesd19 ukkkigzass54 ukkkigzass55 ukkkigzass56 ukkkigzass57 ukkkigzass58 ukkkigzass59 ukkkigzass60 ukkkigzass61 ukkkigzass62 ukkkigzass63 blackblack0728 deunfhh3481 uyyhsxx344i zawuwssn18 nvhfgklx854 mxhfuyeut6 lseetfhdy56 mcnxsye645k uryerurhfje5 oii2lsiekoe pjieirtutir84 etryfjdkvmf5 mcddddjx65 kiujfnghdfy cvbmvky65i ddedsweer12 dffghh1235h isksdyefhanx ieutueye2346 siuethw234mc sewcxdarsf43 ofkhiyjh876 okimnbhg65e3 ujdhfnfmv76 etrfyfhdbd56 lkweret52639 opytrye464 qweqw8762 cndhey567we sweqrsy55221 cmdjfarw2387 mznceyq425 dfeei446720 wieufiekd219 woiexjhe2334 oiuqqkx262dh mwdhjki16286 yrujj87919djw lks11333ksud73 wecjks7c3nf92 u73nc6whr5 c7s8ejx4ee w7d5vg7c43 ls347de8 l2s9dek7r355 iwe88823dddd etwoio343258n wieueudueb iwje2833873 vyruy36576iyi x223445558n jieo287hjj76 qqaawwss0001 qqaawwss0002 qqaawwss0003 qqaawwss0004 qqaawwss0005 qqaawwss0006 qqaawwss0007 qqaawwss0008 qqaawwss0009 qqaawwss0010 wwsseedd0001 wwsseedd0002 wwsseedd0003 wwsseedd0004 augjf93847 sidjr84758 flgkt98473 dhtik94637 sigkr64758 sigur84736 ghuth99987 seirn56565 ghjfu47567 thfur66657 vbght85746 vbfhg74352 qwert74636 kijuh76453 hhjfh34563 poiuy78639 yturi88876 urhfy56471 udhrn74633 vbcnf63471 lkfjr09876 erydb54356 rtfgv43621 cvdfe55555 xvdcf34627 yhfbg09340 unfhg66866 cbvgf64536 asdfg93847 hjgkh12121 qwhjo74377 tytyr55575 bnmmn96789 rvvbf77412 mkjio78654 lpoik97534 cvfhr34534 ifkrj47583 cbvhf76384 vjguti99999 ksjrm39845 cjfnr87364 akdir39485 fjfjf94949 kglto99874 poium43562 ifmrj38475 jfhgu77771 porjt84637 dlrkt84950 aaskk94857 plfor93847 forkt93748 okfir84958 ckfit94857 aisurj39485 fjrut87634 sifir88888 sssir87485 sifun83746 aisur47364 hwlorje4i9dg qwiyg763jhs ksieudfyy37cjnw lslsslsl1344lsi zzowuueksl5

上記アカウントの人が投稿したURI一覧

(後で書く)

Published At2006-08-07 00:00Updated At2006-08-07 00:00

日記
RSS経由で取得したタイトルをURI情報として利用する場合Edit

従来、RSS経由で取得したタイトルなどの情報を、そのままURI情報として利用していましたが、ノイズがあまりにも多いようなので、RSSのURLとアイテムのURLのホスト名が一致する場合のみ、RSS経由の情報をURIなどに利用するように変更しました。

Published At2006-08-14 00:00Updated At2006-08-14 00:00

日記
Zend_Db_TableでdescribeTableを使う場合と使わない場合のベンチマークEdit

Zend_Db_Tableで、毎回describeTableでテーブル情報を取得する場合と、class定義にあらかじめテーブル情報を記述しておいた場合の、速度比較。

サンプルテーブル定義

CREATE TABLE memo (
id int(11) NOT NULL auto_increment,
user_id int(11) NOT NULL default '0',
title varchar(255) NOT NULL default '',
rgdt datetime NOT NULL default '0000-00-00 00:00:00',
updt datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY  (id),
)

サンプルコード

$db = /* デフォルトDBアダプター */;
Zend_Db_Table::setDefaultAdapter($db);
// 標準のZend_Db_Table
class Memo extends Zend_Db_Table {}
// テーブル情報をあらかじめクラス定義で記述
class Memo2 extends Zend_Db_Table {
protected $_name = 'memo';
protected $_cols = array(
'id' => 'id',
'user_id' => 'userId',
'title' => 'title',
'rgdt' => 'rgdt',
'updt' => 'updt',
);
}
// シリアライズしてファイルに保存したテーブル情報を利用
class Memo3 extends Zend_Db_Table {
public function __construct()
{
$serializedColumns = './columns.txt';
$this->_cols = unserialize(file_get_contents($serializedColumns));
parent::__construct();
}
}
$start = microtime(true);
for ($i = 0; $i < 1000; $i ++) {
$table = new Memo();
}
$end = microtime(true);
echo 'Memo: ' . ($end - $start) . "\n";
$start = microtime(true);
for ($i = 0; $i < 1000; $i ++) {
$table = new Memo2();
}
$end = microtime(true);
echo 'Memo2: ' . ($end - $start) . "\n";
$start = microtime(true);
for ($i = 0; $i < 1000; $i ++) {
$table = new Memo3();
}
$end = microtime(true);
echo 'Memo3: ' . ($end - $start) . "\n";

結果(3回分)

Memo: 3.4024510383606
Memo2: 0.2038938999176
Memo3: 0.67136812210083
Memo: 3.6163651943207
Memo2: 0.20920920372009
Memo3: 0.87713384628296
Memo: 3.3675861358643
Memo2: 0.20081806182861
Memo3: 0.63753986358643

Published At2006-08-14 00:00Updated At2006-08-14 00:00

日記
18:15〜18:30までサーバーが止まっていましたEdit

フロントに立てたpoundの動いているサーバーが刺さってしまい、18:15くらいから先ほどまで1470.net関連のサービスが停止していました。申し訳ありません。

それにしても、このpoundを動かしているサーバーはそろそろやばそうだなー。サーバーを切り替えることを本格的に考えてみるべきだろうか。

Published At2006-08-17 00:00Updated At2006-08-17 00:00

日記
Zend Frameworkの方向性Edit

今日のZendのセミナーでZend CTOのZeev Suraski氏の発言のうち、Zend Frameworkに関する部分を思い出しつつ書いておく。

  • (PHP本体と同様に)とにかくシンプルさがポリシー
    • 使いやすい、エラーが出にくい、互換性が高い、メンテナンス性が高い
  • よく使われる機能(20%)だけに注力
    • それ以外は拡張性で対応
  • 使いたい機能だけ使えばいい
    • 他のライブラリなどと一緒に使えるようにする
  • よそのフレームワーク(PHP用のものも、それ以外も)は、アイディアレベルではチェックして、良いものは取り込む
    • コードレベルでは他のフレームワークやライブラリのものは絶対取り込まない
      • 高品質を保証する
      • 知財の問題を回避する
  • 利用例まで含めたドキュメント作成にも力を入れている
  • 高品質で必要なコンポーネントのみで構成される
    • PEARのような幅広いライブラリレポジトリとは違う
    • 将来的にはZend Coreの一部を構成するらしい
  • 追加予定の機能
    • Ajaxとイベントモデル → たぶんAjax(クライアントサイドのロジック)からの通知をPHP(サーバーサイド)でイベントとして処理する仕組みだろうな。
    • JSON、Widget → ってなんなのかいまいち分からないけど、WidgetってのはZend Studioとかでもサポートするとかいっていたし、上記と含めてビジュアルコンポーネントっぽいものなのか?
  • スケジュール
    • 今年中には1.0.0を出す予定(他の人は9〜10月と言ってたけど、本人は言ってなかった気がする)
    • 現時点でも品質は保証するが、APIレベルでの互換性は保証できないので、今から使う人はそのあたりを自己責任で

PEARとは全然違うんだと強く言っていた。「疎結合のフレームワーク+流行りの機能は取り込むよ」というZend FrameworkとPEARの違いって、使う側からすると大して変わらない(俺的には、PHP5フル対応という点が一番大きな違い)んだけど、作る側(特に企業名を出して)からしたら同じに見て欲しくないってことかな。

ただ、ユニットテストしているから品質が高いと繰り返していたけど、そういうもんでもないよなー、実際。まあPEARよりも品質を気にしているのは分かるけど。

そういやPEARのことはいつもは「ピア」と読んでるんだけど、質問するときには正しい発音通り「ペア」といってみたのに、他の人はみんな「ピア」に近い発音をしていた気がするな。

Published At2006-08-18 00:00Updated At2006-08-18 00:00

日記
PHPカンファレンス2006Edit

フレームワークのパネルでZendの回し者になってきました。ネタはいろいろ用意してあったけど、話の流れでほとんど言う暇なかったな。

最後のZeev氏のプレゼンが終わるまでいたんだけど、懇親会までの待ち時間の間に、眠くて吐き気がしてきたんで、懇親会には出ずに帰ってきてしまいました。挨拶できなかった方々すみません。

そういやZeev氏がプレゼンの最後の方で出していた、ZActiveRecord(今はZend_Db_Table)とかZMail(今はZend_Mail)とかZSearch(今はZend_Search_Lucene)とかは、Zend Framework 0.1.1が発表される以前のちょー古い仕様で、そこで使われていたサンプルコードは現状のZend Frameworkのコンポーネントとは全然違っているんで、あれは信用しないように。っつーか、いったいZeev氏はいつのプレゼン資料を使い回しているんだ? あれを見てちょっとげんなりした。

一応事前に準備しておいたネタ帳は以下のような感じ。

  • [各フレームワーク] 現状
    • Preview 0.1.5が7/10に出た。
    • 高機能な(RoRやSymfonyのような)フレームワークとしてはまだ足りないが、基本的なコンポーネントは一通りそろっている。
    • Zend Studioとかと連携しての開発支援系は考えているらしい(昨日のセミナーネタ)。Widgetとか言っていたけど、詳細不明。
    • 完成度は、コア部分は実用レベル。流行りもの系(フィードとかWebサービスとか)はまだビミョー。実際に使う人が増えないと、この辺の品質は上がらないんじゃないかな。たぶん開発者もテストケースとかは書いているけど、アプリケーション風の使い方はしていないように思う(結構基本的なところでダメだったりするし)。
  • [各フレームワーク] 今後
    • 一応今年中には正式版1.0.0が出るらしい。今年9、10月あたりという説もある。まだコンポーネントが足りてない気がするけど……。
    • 開発の様子は、SubversionレポジトリやMLを見ている限りでは、ちょっと停滞気味かも。がんがん新しいコードが追加されている感じはない。
    • proposalはいろいろ出ている。
    • バグ管理とかドキュメント管理とかの仕組みも、ようやく安定してきた(それまではいろんなツールをとっかえひっかえ状態だった)。
    • PEARが5〜6対応を推し進める方向に向かっているようなので、そちらとのバランスを取らないとリソースの無駄遣いになりそう。と思ったんだけど、PEARとZend Frameworkは全然別物だし、品質とか知財の関係とかで、PEARのような既存のライブラリをZend Frameworkが取り込むことはないそうだ(昨日のセミナー)。
  • [meta] PHPフレームワークは普及するのか?そもそもフレームワークを使う価値はあるか?
    • 基本的に、フレームワークの考え方自体はあらゆるシーンで使える。フレームワークは先人の知恵がコード化されたもの。
    • 実際の制作物にフレームワークを使うかどうかは、ケースバイケース。ただし、環境さえうまく整えることができるならば、かなり小規模なケースでもフレームワークを採用するメリットが得られる。逆に環境が用意できない場合は、フレームワーク的な考え方だけを利用するか、あるいは小規模な自作フレームワークもどきを使うなどもあり。
  • [meta] フレームワークの選択基準
    • フレームワークを知らない人は、何でもいいからWebアプリケーションフレームワークの考え方を身につけた方がいい。ある程度メジャーならばなんでもいい。
    • 実用レベルでの採用を考えると、コードの品質、採用実績、将来性、環境、パフォーマンスあたりが検討材料となる。
    • うちの場合は、PHP5への完全移行を決め、それに伴い環境的にPHP5にフル対応しているものを選択し、その中で将来性、コードの品質を重視してZend Frameworkを選んだ。
    • コードの品質というのは、PHPのライブラリでは、バグの少なさよりも、いざというときにソースを読んで自分で対応(修正)しやすいかどうかが重要。もちろんバギーすぎるのは困るが、ドキュメントも実績も十分ではないPHPのライブラリでは、自分のコードと同程度にライブラリのコードを追う必要がある。
    • そういう意味では、コード規模がまだ小さく、きちんとした規約に基づいて書かれ、異常系処理が例外ベースで統一されたZend Frameworkが、相対的にベストだった。
    • 現時点だけで言うと、他のフレームワークの方が便利なことが多いとは思う。
  • [各フレームワーク] バージョンアップ...どう?
    • まったく不明。まだそのあたり(運用後のフレームワークのバージョンアップ対応)まで考えるレベルまで来ていない。
    • ただ、設計的に各コンポーネントの結合度が比較的低く、インターフェースもきれいな設計のものが多いので、比較的未来は明るいんじゃなかろうか。
  • [各フレームワーク] アプリにどこまで食い込むか?(コアonly or CMS方面へ...)
    • 現状では、アプリケーションレイヤーよりのフレームワークというよりは、独立したライブラリレイヤーのフレームワークといった位置づけ。というか、疎結合で部分的に他のライブラリと差し替えて使えるように設計してある(昨日のセミナー)そうだ。
    • ただし、ZAppのようなアプリケーションフレームワーク的な方向のものもproposalとしては出てきているし、Zend自体もZend Studioと組み合わせての開発支援は考えているみたいなんで、Rails的なアプローチではなく、たぶんマイクロソフトがVisualStudioでやっているようなアプローチに近い支援機能がくるんじゃないかなー。
    • ちなみにうちで作っているWEBXPというフレームワークも、Zend Frameworkのコンポーネントを組み合わせてアプリケーションレイヤーよりの作業を効率化するための仕組み。Zend Frameworkは、フレームワーク on フレームワーク的なものを作るのに向いている。

他にも現地でパネルが始まるまでの間にいろいろ追記したんだけど、W-ZERO3[es]が熱暴走して追記した分が失われてしまった。Zend Frameworkを選択した理由とか、他のフレームワークと比較しての特徴とか、いろいろ書いていたんだけど。

Published At2006-08-19 00:00Updated At2006-08-19 00:00