ぐらめぬ・ぜぷつぇんのはてダ

2008/11/24以降のメインブログはこちらになります。 : http://www.glamenv-septzen.net/

本はてなダイアリにはコメント・トラックバックを受け付ける記事を公開します。

2008-11-13

[][] 画像について If-Modified-Since ヘッダーの処理を実装

前に実装した(と思ってた)自作コードを引っ張り出してきて、組み込んだりしてた。

まぁ、時刻表記のGMTに振り回されたり組み込んだコードの変数名で惑わされたり少し嵌ったけど、ようやく画像については304を返せるようになった。

あと、前に作った自作コードでは "Content-Transfer-Encoding: binary"をわざわざ指定していたのだけれどこれ、HTTP1.1では使われてないのね。何で自分、入れたんだろう。他にも "Pragma: public" とか謎のヘッダーを入れてるし。忘れた・・・。

も1つ、今まで画像を表示しようとすると添付ファイルと同様に「名前を付けてファイルを保存する」ダイアログが表示されてしまっていたのだけれど、あれ、単純に "Content-Disposition: attachement" にしちゃってたみたい。画像でもHTTP_Download使ってたんだけれど、取っ払って自前でヘッダー作る事にして直した。まぁ画像じゃ部分的GETも使われないだろうから大丈夫だろうと高を括っている。

これで0.0.3迄のTODOはこんな感じに。

  • ヘルプ(ja, en)
  • README(ja, en)
  • PEAR同梱
  • trackbackフィールド削除(追加)

2008-11-08

[][]今日の分のメモ。

済:

  • login/logout時のリダイレクト先のURLチェック(_YB('url')で指定されたURL範囲内である事)
  • template日時置換
  • protector.phpで文字コードチェック
    • さらに、$_REQUESTに$_GETと$_POSTのみ入るよう上書き処理
  • バージョンがモデレートされている時に、編集の「changelog」テキストエリア付近に「モデレートされてるよ」注意書きを表示。
    • 今まで特に表示していなかったので、作者自身、更新してから「ん?表示が更新されてない・・・あ、バージョンがモデレートされていたのか」と気づく始末だった。
  • helpディレクトリをmisc/以下に配置。
  • 't'URLクエリで指定されたタイトル文字列で始まるページの一覧を表示する"ls"モジュールを追加。
  • タイトルを "/" で区切り、viewモードでそれぞれlsモジュールへの自動リンクになるよう調整。
    • 一応、この機能を使う場合はviewモードで、只のテキストとしてのタイトルとdisplay: hiddenなh2タグで出力してる。
    • _YB('use.title_auto_ls')をfalseにするとこの機能はOFFになり、タイトルは通常のテキストとしてh2タグで出力される。

残:

  • ヘルプページ(ja, en両方)
  • setup.phpのバグ(templateのdatatypeがおかしかったりカテゴリがtranslationかかってない?)とか、initdataにSandBoxを追加とか。
  • READMEファイルをトップディレクトリに移動。修正。英語版も用意。
  • GoogleMap用のHTML/Wikiプラグイン追加。
  • Modifiedヘッダー処理
    • これは欲しい。特に画像表示では特にサムネイル画像の生成などはしておらず、index.phpのrawモジュールを叩きに行く。modifiedヘッダー処理を入れて、少しでも処理を軽くしておきたい・・・。
  • PEARライブラリ同梱

2008-11-07

[][]outlineのバージョン未検知の件修正。あとTODOとか。

結局Wikiプラグインで、ページのソース全体を取得し直しているのはoutlineプラグインのみだと分かった。ということで、yb_Wikiクラスのstaticメソッドとしてオリジナルのソースデータを保持するメソッドを用意し、yb_Wiki::convert()メソッドを呼ぶ時にここにファイルからロードした直後のデータを入れておき、outline内部で取り出す事で解決できた。

あとはTODO。

  • templateの日時置換:まだやってないんだよな・・・。あとこのヘルプも書かないと、何だか分からないぞ。使う人。
  • ヘルプドキュメント:ACLとテンプレート。あと英語版・・・。
  • GoogleMapのWikiプラグイン
    • ID貰う必要があって、どこに保存しておくかが問題。・・・dataディレクトリ配下に空ディレクトリ用意しておいて、そのなかにplugin名でファイルを用意して貰い、その中にIDをべた書きしてもらうか。
  • login/logout時のリダイレクト先が_YB('url')の範囲内かチェック。
  • misc/READMEファイルの修正と英語版の用意。
  • バージョンがmoderatedになっている時は、編集画面のchangelogテキストエリアの近くに一言メッセージが欲しい。「モデレートされてるので直ぐには反映されませんよ。」って。
  • protector.phpでmbstringが有効の場合は文字コードチェック
  • setup.phpで使用するtranslationとか初期ページファイルの中身修正。
    • テンプレートの添付ファイルのデータ型が古い。Attachとかになってる?
    • カテゴリ名がtranslationかかってないっぽい。
    • SideBarのヘルプへのリンクが古い。
  • PEARファイルを同梱。コレがないと動かない・・・。

あと最後に0.0.4の方で実装するかも、な思いつき。

  • lockが欲しい。分単位くらいでタイムアウトできるの。
  • conflict検出がやっぱり欲しい。
  • すっかり忘れてたけど、ログ出力もっと入れないと会社用途でアクセスログの採取に対応できない。

余談。ふと昔のログ見てたら・・・

でも、ここから、ようやく、YakiBikiが始まります。

Xhwlay-0.9.0(beta)をリリースします。 - ぐらめぬ・ぜぷつぇんのはてダ

そうか。もう、Xhwlayの最初のbetaを出してから1年が経過したのか。自分もようよう、しつこいというか執念深い性格かもしれない。

2008-10-27

[][]コメント機能、一旦実装完了。

最新のコメントN件一覧をHTMLプラグインとWikiプラグインで実装できたので、ようやくコメント機能をひとまず実装完了とします。

<yb_newcomments 件数 /> : HTMLプラグイン版

&newcomments(件数) : Wikiプラグイン版

Wikiプラグインは、HTMLプラグインのラッパーです。動的に変わりますので。

随分間が空きましたが、これで0.0.3への残機能は

  • templateから作成する時、日時指定文字列の置換
  • 新しいdao/idxコードに対応し終わっていないHTML/Wikiプラグインの修正
  • protector.phpで(mbstringが利用可能であれば)文字コードチェック
  • ヘルプドキュメント

余裕があれば・・・0.0.3が終わった後の予定ですが、

  • RSS
  • 変更メール通知
  • "googleで検索"みたいなプラグイン
  • GoogleMapのWikiプラグイン(座標を採るのと、ぐりぐり動かせるのと、固定表示っぽいの)
  • 認証(LDAPとか、はてなとか、TypeKeyとか、mixiとかかな?)

余力があればという感じです。

2008-08-05

[][]アイデアメモ

  • plain text, html, wikiは"type"というよりは"format"という概念にした方がよい。
    • →ドキュメントのフォーマットを変更するのに一々新規作成し直さないとイケナイのはナンセンス。
    • →アイコンの見た目が区別しづらい。
    • あとは、実際に書いてる途中で text から wiki, その逆、というのがあり得たから。

で、データの型についてなんだけどこんな風に現時点では整理しておきたい。

  • "text" : formatとしてplain text, html, wikiを選択できる。
  • "image" : 画像。タイトルとして自由に付けられる任意文字列と、画像のファイル名を別個に持つ。コメントも付けてもいっか。
  • "file" : 添付ファイル。画像と同様のタイトル、ファイル名、コメント(?)。
  • "bookmark" : URLを保存しておく為だけのもの。用途は・・・まぁ、SBMに保存しておけないようなURLを保存する、とだけ言っておこう。

で、今までは"yakibiki"モジュールでこれらの作成・編集を一手に引き受けてたのだけれど。

まぁいっかな、と。

それぞれ分離しちゃった方が、あとあと新しいデータ型を追加するのに楽だし、なによりも例えばbookmarkの編集ロジックに変更が入った時、他のコードには影響したくない。今は一箇所に固まってswitchさせちゃってるからその辺が窮屈。

あとは・・・threadなんだが。これ、やっぱネーミングが悪い。

「ゾーン」("zone")というのがしっくり来る。

スレッドというと、どうしても2ch的な掲示板のイメージに引きずられるし、あるいは「フォーラム」的なイメージを持ってしまう。またその派生として、どうしても「テキストデータ中心」というイメージを持ってしまう。

例えばスレッド的なものを作りたいのであれば、Wiki中心にしてlsとかnaviプラグインを使いこなせばそれで出来てしまう。ただしそれだと画像やfileなどが漏れかねない。

なので、やはりそれとは別のレイヤーでデータのグルーピングを行いたいわけで。となるとやはり、「ゾーン」(zone)という名称が来るのかも知れない。・・・まぁ、これはそのうち。ひょっとしたら「やっぱスレッドでいいや」となるかもしれない。ゾーンって言ってしまうと少し強すぎる感じがする。

・・・タグでいいんじゃね?と言われてしまえば身も蓋も無いのだけれど・・・。うーん、でもACLやカテゴリセットのデフォルト値を保持する・・・ってカテゴリセットはまだ持ってないか、とにかくそうしたデフォルトセットを定義してかつグルーピングしてくれる概念が無いと、少し辛いかも知れない。

素直に「ドキュメントグループ」(DocumentGroup)と呼ぼうか。でもなぁ、なるべく単語は一つに収めたいよね・・・。

いっそユーザーのグループを「クラウド」(crowd)と呼び、こちらを「グループ」(group)と呼ぶか。あるいはその逆。

まぁ基本はWikiNameでのセパレータ("/")を活用した階層化がお手軽なんだけれどね。上のアイデアの影響で、画像やファイルにもWkinameをAliasみたいな感じで付けられるようになるし。

それともう一つ出てくるのが"template"という特殊データ。

んとー、例えばテキストであれば、ある程度中身のテンプレートまで作っておく、みたいな。データ型に依ってしまうのだけれど。

これは入力ルートの幅を広げる為の伏線。タイトルとかに特殊なキーワードを埋め込むことで、自動的にYYYYMMDDが展開されたりすると面白いかな。

まぁようするにbookmark型とか、text型とかでいわゆるbookmarklet的な機能を実装したい時に使うわけですよ。

そんな感じで、grain化した事によるデータの柔軟性というかいい加減さというか節操の無さを活用できればいいかなーと。

以上、妄想メモ。

2008-07-22

[][][]Hackathon当日メモとYakiBiki TODO メモ

有休取ってようやく復活する程度に普通以下の体力のid:msakamoto-sfです。ということで今日買ったばかりのNOSTRADAMUS(JUDAS PRIEST)聴きながら記憶をまとめ直してます。ところでNOSTRADAMUS、エエですね。暫くRhapsodyもBlind Guardianも新譜出してなかったので、正直メロディアス/シンフォニックメタルにマジで飢えてました。

Hackathonですが・・・結局、id:msakamoto-sfは23時には寝てしまいました。(爆)

えーっと、背もたれがないと姿勢を保っていられない程度に筋肉が無い貧弱な肉体で、やっぱ無理でしたね。またPHPのコードに触るのが実に2-3週間ぶりで、片づけようと思っていた自分のコードを理解してどう手を加えるのか考えるので精一杯という感じで。YakiBikiのDAOレイヤーをgrainベースに入れ替えようと思っていたんですが、find系のメソッドの構造が結構関数キャッシュとかcallbackが入り組んでて、どう解体してどう再構築しようかで悩んで終わってしまいました・・・。

結局、十分寝たせいか、そして会場の椅子が背もたれつきでしかも大会場にずっと居たのですが空調が効いていたせいか、PHPカンファレンスでの最前列に座っていた時の方がめちゃくちゃコーディングが快適だった始末。Hackathonでは悩むだけで終わりましたが、翌日のPHPカンファレンス中のコーディングで何とかDAOのBaseクラスをgrainベースのコードにreplaceすることができました。但し、E-Mobileユーザーがバリバリに接続しまくってたらしくSVNのコミットが異常に遅くなったため、さらに明けて今日、コミットした次第です。この影響で、現在のYakiBikiのtrunkは正常に動作しなくなっています。Baseが変更された為、全DAOおよび全TXレイヤーが動かなくなっているためです。

後はHackathonとか翌日中に思いついたり気づいた事。

  • 作ったは良いけど結局使ってないインデックスがあった。
    • G2Aインデックス
    • U2Aインデックス
    • ここら辺はACLキャッシュで使う予定だったけど、結局全く使わずに実装できちゃったんだよな。
  • モデレート機能:変更があっても、バージョンを変えないように出来れば良い?
  • スレッドは只の名前空間に。権限とかは外す。っつーかWikiの命名規約があればほぼ無用じゃない?
    • →どちらかというと、「スレッド」自身が名前空間であり「テンプレート」だよなぁ。
    • →「スレッド」じゃなくて「デフォルトセット」というべきかな?概念を表す上手な言葉が見つからない。
  • カテゴリの作成やスレッドの作成権限→ROLEに押しつけていいんじゃね?
    • 開発した本人ですら訳分かんなくなりそうな微妙な権限ポリシー、やめよう。カテゴリとかスレッド周りの。
  • SmartyのHTMLエスケープ機能の組込:default_modifierというのを調整すれば良いらしい。
  • 機能と見た目をシンプルにする。開発者本人が、特に権限周りの機能に振り回されかけてる。

忘れかけてた自分のメモにリンク。

http://d.hatena.ne.jp/msakamoto-sf/20080608/1212931311

あと、id:kunitさんに隙を見て気になっていた点を確認できた。これだけでも収穫。

  • APL2のライセンスにLGPLのコードは混ぜられるか?
    • → 難しい。やらない方が良い。LGPLの方が感染力が強い。
  • privateメソッドのxUnitはどう実装しているのか?
    • 派閥がある。
    • リフレクション使って無理矢理呼び出したり、
    • privateじゃなくてアクセス修飾無し(=packageスコープ)にして同じパッケージにxUnitを入れたり、
    • そもそもprivateになりそうだったら、委譲する、とか。
  • ネットワークやDBなど、外部世界との境界線上の異常系のテストの自動化の話題は上がっているのか?
    • まだその辺りの話は出てきていない。ニーズが有れば出てくるのでは?

privateメソッドのテストについては、実は自分的には private を呼ぶだけのpublicなラッパを実装したクラスを用意してそれ経由で・・・とか思ってたんだけどそう人は居なかったみたい。また境界線上の異常系なのだけれど、雑誌記事やBlogで見る限りでは非常に理想型のロジック部分だけしか取り上げて居らず、

  • 例えばトランザクション処理中にDBが突然ダウンした時、一定時間のT.O.後にX回リトライするとか、
  • SYNパケット受信後、X秒間何もパケットが届かなかった時の異常系とか、
  • TCP/UDPソケットでread()/write()中に突然LANケーブルが外れたりとか、

そうした滅茶苦茶ボーダーマージナルな部分の異常系の取り扱いロジックのテスト自動化については、まだそうした話は出てきてないみたい。

実際の所、今自分が出ているところがそうした通信系で非常にシビアな部分までもテスト(しようと)する文化で、この辺りまでクリアできないと上の人達にテスト自動化のメリットを納得させるのが難しいと考えていたりいなかったり。でもこのレベルになるとカーネルレベルの挙動をHOOKINGできないといけなかったりで、KernelHacker級の技量が無いとそもそも無理な世界だよな。プラットフォームの縛りも入るだろうし。

2008-06-08

[][]YakiBiki 0.0.1 (alpha-2) リリース

KinoWikiスタイルのWikiドキュメントサポートが追加された、YakiBiki version 0.0.1 alpha-2 をリリースします。PHP 4.3 以上(PHP4.4.x or PHP5.1.x 以上推奨)で動作する筈です。ダウンロードは、下記引用元のsf.netのプロジェクトページからダウンロードできます。

Now, I release YakiBiki(Yet Another Blog like Wiki) version 0.0.1, alpha-2.

Main view of this release is KinoWiki-style wiki document and some usefull wiki plugins are suppourted.

Please see, and try it.

no title

自分自身、本格的にWikiとして動き出すのを見ると、色々とカスタマイズを加えたいところも出てくると思います。

個人的には2007年の時点で見えていた最大の山場を越えた感じはありますが、まだ今少しalphaリリースは続きます。

  • RSS出力のサポート:当面はRSS2.0だけで良いかなと思ってます。
  • ユーザー登録・パスワード変更・パスワード再発行時のメール確認機能:コレが無いとまだまだ一般向けとは言えないと。
    • あと、やっぱりデータが変更された時にownerへの通知は欲しいよね。
    • マスタ変更系はsys権限持ったユーザーに通知したいよね。
  • パスワードにsalt付け解け。:ヤヴァイ、すっかり忘れてました。
  • Wiki書式を色々カスタマイズ。:多分、色々弄っている内にあれもこれもと出てくるはず。
  • Wiki用のCSSを追加。:KinoWikiから拝借・・・。
  • amazon, GoogleMap用のWikiプラグイン追加。

TrackBackはどうしようか、と真剣に悩んでいます。折しも

これはblog運営者によって差が大きなところだけど、最近TB SPAMをほとんど気にしたことがない。livedoor blogががんばってくれているおかげだ。はてなダイアリーも割とこのあたりを継続的に対応している印象がある。

404 Blog Not Found:TBを見直せ、いや打ち直せ

というような記事が出ています。

stand-aloneで個別に動作する、こうしたユーザーインストール型のBlogシステムに於いてはアンチスパム対応がどうしても追いつかないという状況があると思います。PukiWikiとかでは色々ノウハウが蓄積されているようですが・・・。一つにはmodelate型にして、TBを受信しても承認待ちとして非表示にしておく、という手があります。

ただ、そもそもその前にデータ構造をどうしようかというのも頭にあります。

YakiBikiはRDBを使って居らず、自前で細かいファイルを大量に作成しています。マスタ系は一つのファイルでSeparated Fieldで区切って入れているのでまだ平気ですが、データ系については特にテキスト系がパーティションのブロックサイズ(4KBとか)以下のデータファイルで大量に生成されます。いくら何でも少し厭らしいな、と・・・。

そういう訳で、alpha系は今のところ「機能」を見定める為の試験実装という位置づけです。一通り機能が出揃ったところで、データ構造の取り扱いについて見直しを書けます。恐らくdaoとtx系は全面書き直しを迫られると思いますが、今のデータ構造ではディスクを上手く使っていないし、なによりデータの拡張が容易に出来ません。

そもそも、機能が一通り見定められたらRDBにしても良くない?というのもありますし。*1

とまれ、Wiki形式のドキュメントサポートは一つの山場でもありました。ご質問・ご意見は例によりメーリングリストをご利用下さい。

*1:元々RDBを使わなかったのは、ACLキャッシュ機構の実装がふらついていたため、スキーマを定められなかったというのが主な理由。