http://sportsnavi.yahoo.co.jp/fight/pride/headlines/20050929-00000030-spnavi-spo.html
阪神優勝を差し置いてこのエントリを挙げる！
そして盛り上がりまくりな各地。
mixi から情報ポインタの転載。
◇WILLCOM公式
http://www.willcom-inc.com/ja/corporate/press/2005/09/27/index_01.html
http://www.willcom-inc.com/ja/corporate/press/2005/09/27/index_02.html
http://www.willcom-inc.com/ja/lineup/wx/index.html
◇ケータイWATCH
http://k-tai.impress.co.jp/cda/article/news_toppage/25795.html
http://k-tai.impress.co.jp/cda/article/news_toppage/25796.html
http://k-tai.impress.co.jp/cda/article/news_toppage/25798.html
http://k-tai.impress.co.jp/cda/article/news_toppage/25797.html
http://k-tai.impress.co.jp/cda/article/news_toppage/25799.html
◇ITmedia
http://plusd.itmedia.co.jp/mobile/articles/0509/27/news035.html
http://plusd.itmedia.co.jp/mobile/articles/0509/27/news039.html
http://plusd.itmedia.co.jp/mobile/articles/0509/27/news042.html
http://plusd.itmedia.co.jp/mobile/articles/0509/27/news034.html
◇三洋
http://www.sanyo.co.jp/koho/hypertext4/0509news-j/0927-1.html
◇日本無線
http://www.jrc.co.jp/jp/whatsnew/20050927/index.html
◇京セラ
http://www.kyocera.co.jp/news/2005/0902.html
そうか、京ポン２にだけ java 搭載されていないのか。。。代わりに有償ソフトウェア。こりゃ安易に発売と同時に突撃すると後悔しそうだ。カメラはついに100万画素突破！
先日 maple 3.0.2 がリリース。バグ FIX および 3.0.0 から動作が異なっていたものを修正した内容ですので、3.0.1 を導入した方はノータイムで適応 OK でしょう。
さて、3.0.1 リリース後ようやく案件に適応する機会がきまして、タイトルの内容を確認することができました。
maple では Filter 処理をかますことが可能ですが、その Filter 格納位置は maple ディレクトリ以下の filter 内でした。
自分で追加する filter というのは、その web アプリに依存した内容のものであることが多く (もちろんそうでないものも)、そういうものは個人的には web アプリ格納ディレクトリ下に別途置きたいと思うのです。
ということで、タイトルの通り、PRIVATE_FILTER_DIR という定数が使用できるようにする Hack。maple.inc.php に宣言して使いましょう。仮に同名の filter があった場合は PRIVATE_FILTER_DIR の方が優先されます。
FilterChain.class.php-20050926.patch
実は今日初動かしで、案の定バグがあって、9/13 のタイミングでパッチ公開してなくてよかったなと思ったのであります。
ということで買ってきた。
Radeon9800XT 256bit, 256MB である。18500円也。
今まで使っていたのが 9700pro なので選出こそは簡単なのだが、見極めが難しい。基本 AGP ネイティブで、256bit で、となると物凄い品が限られる。世は PCI-E でコストパフォーマンスの高い品は沢山あるが、AGP で新作となるとほとんどが 128bit か、PCI-E からのブリッジ品ばっかりである。そして高い。2万越え当たり前。最新のものは5万突破とか。そんなものを買っても CPU が追いつかん。
そんな中上記カードがずば抜けて光っていた。というか光りすぎ。なんせ *中古* だからな。性能＋価格面で考えるとこの選択肢しかなかった。事前調査の情報を脳内に蓄えて行ったのだが、いわゆる「地雷」の部類にはリストアップされていなかったし、実際に動作させて ATITool で見てみても、本来の仕様通りの内容であった。
実はクロシコの Radeon9800XT ってのもあって、256bit なんだけれども 128MB、という仕様のものもある。クロックも微妙に低い。その代わり新品で14000円くらい。これを地雷というか否かは激しく微妙ではある。なんせ割り切った形での販売だからな。9700pro と同等品を、と考えるとこっちのが正解だったんだろうけど、やっぱりなんか後々後悔しそうだったのだ。
あとは Radeon9800XT 特有の問題である発熱問題がどうなるかだな。
昨日 DAoC のプレイ、Seer, Caster におけるイケメンの嗜みである (そして当然ながらワシは既に持っている！im ikemen. loot で勝っただけだが) Bracelet of Zo'arkat をやっている最中に PC のうちの一台の描写が急に狂った。
あー久々に熱暴走しよったなということでその PC はシャットダウンしたのだが、一日経った後も明らかに描写がおかしい。Movie 再生は変なポチポチが出力され、DirectX 使用に至ってはモデリングが完全に狂っている。
PC をあけて VGA をチェック、挿し直しなどをしてみると、どうも挿入具合というか角度でまともに描写されたりされなかったりの状態であることが判明。角度の問題ではあるものの、「うまくいったかな」と思ってしばらく放置しているとすぐに狂う。
M/B の AGP スロットが問題である可能性もあるので、念のため浮いている VGA に代えて動作させてみると全くもって問題ない。よって VGA 一択であることが証明された。
ちなみに逝った VGA は Radeon9700Pro である。数々の劣悪環境にも耐え過激な稼動時間にも動作し続けた彼は、この度名誉ある戦死を遂げた。M/B 調査のために緊急出動した Radeon8500 も華麗なる最期に敬礼を送っている。ありがとう、Radeon9700Pro。厳密にはまだ使おうと思えば使えるのだが。
さて、緊急稼動中の Radeon8500 には若干荷が重過ぎる、というか 256bit, 128MB -> 128bit, 64MB という変化は明らかに致命的な動作の違いを来しているので、早速代わりを探さねばならない。世間は AGP 最後の VGA 選択と題し、高クラス AGP モデルを模索しているところなのだが、当方そこまで高級性能は要らない。9700 だったので 9800 へ、とかそんなレベルでもいいのだけれども、折角買うのだからちょっと性能 UP もほしいところ。ただ金銭的制約もある。どうしようか。。。
ちなみに、すでに Radeon PC として動いていたものの VGA 交換なので、GeForce という選択肢は多分ない。多分。
なんとなくで移行した。
さて、Wanderlust で閲覧していたメールを Thunderbird へ移行するのにどうすればいいかなとアレコレ悩んでいたのである。
Wanderlust: MH 形式 (1メール 1ファイル)
Thunderbird: mbox 形式 (1 メールボックス 1 ファイル)
thunderbird の機能に import があるけど、ファイル形式を指定しての方法がない。ということで見つけた方法がこれ。
1. MH 形式メール (ファイル) を Outlook Express にドロップ
2. Thunderbird で Outlook Express からの Import
以上。ただし 1. の段階で、ディレクトリ単位でのドロップが出来ない。ファイルレベルでしか無理。~/mail/ml/hoge とかいう形でディレクトリ分けをしていたので数回ドロップするはめにはなったけど、必要ないものはそこで一斉消去できたからまあよかったかな。
お馴染み First Chara, Druid に加え！
そして早速新パッチを書くくまっち。
PHP 関西セミナー 5 後にメールで送った内容も反映していただいた。感謝。
基本的に今回の Ver.UP はバグフィックスとのことで、激しい機能変更や新機能などは極力避けられた模様。ず〜っと前に話のあった maple 搭載 Filter 以外のアプリ依存 Filter 設置場所の指定も、今回の Ver.UP には盛り込まれなかったみたい。と言うかうちもついさっき気づいた。
ということで個人的追加機能は、
・Action の setter/getter が無くてもいけるアレ
・Validate_Date が YY-MM-DD 形式でもいけるようにする
(第3のパラメータとして、生年月日頭2桁をあとから追加できる)
・PRIVATE_FILTER_DIR 定数の追加 (PRIVATE 優先)
3.0.0 からすでに使っていたものも含めて、動作確認が全然取れていないためまた後日にでも。
できた。
BeanUitls.class.php-20050908.patch
Filter_Action.class.php-20050908.patch
前エントリの setter なしパラメータ渡しを実現するパッチ。当然既存の setter 渡しもそのまま可能です。かなり手抜き実装ですが、こんなとこだろう…
[Action]
logic = ref:Logic ; これは既存でもする良くある書き方
name = ; ブランクなら Request "name" を Action の name へ代入
mail = param:email ; Request "email" を Action の mail へ代入
tel = 0123456789 ; 0123456789 を Action の tel へ代入
zip = sess:zip ; Request "zip" を Action の zip へ代入しつつ
; Session へも zip で代入
pet = param:yourPet,sess:pet ; あわせ技。変態コードも許容する :)
food = meat,sess:hailFood ; こんなことも余裕！
class Example
{
// {{{ properties
/**#@+
* @access public
*/
var $logic;
var $name;
var $mail;
var $tel;
var $zip;
var $pet;
var $food;
...
もはや setter method を書く必要がないぜ！
したいったらしたい。
ともかくコードをサボりたいのである。
あまりやりすぎるとそこが穴になるので注意が必要だけど、最小限「Action に何を渡すのか (入力)」「Action から何が出て行くのか (出力)」の2点を明示的にしていればクリアだと思われる。
出力 (getter) に関しては簡単。一度書かせてもらった。
各 Action の設定ファイルに「何の値をどういう名前で出力するか」という形でリスト記述するのもありだと思うけど、出力の際に値をこねくりまわす場合がどうしてもでてきてしまうため、設定ファイルでそれを許容するような内容を書こうとすると非常に煩雑になる。mojavi でいうところの ActionView クラス のようなことができるのがやはりいいのだけれども、それを設定ファイルでやるならば view クラスの前にそういうフィルタを準備しなければならなくなったり view クラスそのものを根本から変えないといけない。それならば Action 内にこねくりまわすような専用関数を 1 つ準備してみようというのが上記リンクの内容。get get get ... という形でひたすら書く必要はなくなる。加えて見やすい。
入力に関しては、かなり悩んでいるというか面倒なので現在放置中。
出力と同じように set 専用関数がやはり簡単ではある。入力時にも、例えば request の値を Action に渡すだけでなく同時に session へ入れるという処理が考えられるため、この形での実装が一つの回答になると思う。
別のやり方としては設定ファイルへの記述。今のところ Action に渡す処理が含まれているので、わざわざ setter を準備しなくても Action 内 public property (これは現在も処理内で使われている) と設定ファイル内で値を明示記述することで $action->value 処理で一気に代入。こういう処理を嫌う人もいるだろうけど、public にしているのだからやっちゃって構わないでしょというのが私の考え。
ついでに session へぶち込む記述も許してしまう。つーことでこんな感じ。
[Action]
logic = ref:Logic ; これは既存でもする良くある書き方
name = ; ブランクなら Request "name" を Action の name へ代入
mail = param:email ; Request "email" を Action の mail へ代入
tel = 0123456789 ; 0123456789 を Action の tel へ代入
zip = sess:zip ; Request "zip" を Action の zip へ代入しつつ
; Session へも zip で代入
pet = param:yourPet,sess:pet ; あわせ技。変態コードも許容する :)
こんだけ出来れば大体のシチュエーションは許容できるはず！
で、これを coding しようとすると激しく面倒なので、前記のとおり放置だったりする。
さすがに変態すぎるので 3.0.1 リクエストには投げてない。
なんだかんだであと1週間である。
で、落ち着いて我が小選挙区の大阪5区候補を見るとだな。
http://www2.asahi.com/senkyo2005/kouho/A27.html#005
さて、どうしたものか…
昨日無事終了した第5回 PHP 関西セミナー。今回もダイジェスト形式でお送りします。
(1) PHP アプリケーションの脆弱性 (大垣さん) o 基本の説明 o 最近の PHP アプリケーションの脆弱について検証しよう o PEAR XML_RPC - 外部からのコード実行ができる - eval 実行は危険がいっぱい o CMS Made Simple - 不用意に GET/POST の値を別の変数に挿入しない o Simple PHP Blog - 「不可リスト」記述ではなく、「許可リスト」の記述を！ - 不可の内容は一杯ありすぎる、いつか洩れが発生する o phpLDAPAdmin - 単純なコーディングミス - セキュリティ関連の設定と整合性は何度でもチェックすること - この手のチェックは XP, ペアプログラミングすることで回避確率大幅アップ o AutoLinksPro - SimplePHPBlog と同じミス o EXIF - Image に付加されたテキスト情報 - 外部入力値は何も POST/GET, COOKIE, SERVER だけじゃない -- 直接出力すると XSS の危険 -- DB なら SQL Injection o NETQuery - シェルコマンドを実行される - magic_quote_gpc = true であることが前提なアプリが多い o RunCMS - 思いがけない変数上書き - extract() は register_globals = true と一緒 o phpBB - 利用者多し - ホールだらけ - eval による穴 - 複雑な HTML 出力許可はやはり難しい o どこで脆弱が発生するのか o 脆弱性の傾向 - XSS, SQL Injection - レポート時に同一アプリに対する複数の内容 - 単純なコーディングミス - 複雑なコーディングによるミス - PEAR による雪崩式がこのたび発生 o まとめ - まずはやはり基本は重要 - 特効薬などない => よって普段からの情報収集重要 - Sanitize という概念は間違えている o 余談 - グラフィックテキストは安全か => 解析早し - 暗号表は安全か => パターン出せば余裕 - クライアント認証は安全か => スパイで - よって Web 環境でのサービス保障など無理
上記内容の一部について、その詳細が大垣さんの Blog に書いてあります。セキュリティに関して、「口をすっぱくして何度も言ってるじゃないか！」と言ってました(笑)
(2) Web アプリケーション向け GUI ツールキットとしての XUL (下田さん) o よくある GUI ツールのお話 o FLASH - お金かかる - 技術が必要 o JAVA - 自由度は高い - 設計めんどい - でかい o HTML - 貧弱 - 凝り始めると途端にめんどい o XUL とは - XML Userinterface Language - テキストベース - デバッグ環境は揃っている o XUL サンプル o XUL だけでは何もできない - javascript は必要 - バックグラウンドシステムの他言語 o GUI 開発に特化している o Mozilla しかダメ！ - んじゃ Firefox 使わせればいいじゃない！ - 業務アプリとしてならばかなり有効 o 質疑応答 - OS 互換性は OK (ただし凝った事をすると若干差はでる) - 文字コードはなんでも
DHTML + javascript で「ぎゃー！」と言いながら書かなければならないような機能がさらさらっと書けてしまうというのは素晴らしい。それらが標準で搭載されている。もちろん javascript を加えて +α もできる。AJAX 仕様にすればネイティブアプリ並なことができそう。名前は聞いたことあったけど、ここまで面白いものとは知らなかった。ほんと、Mozilla オンリーじゃなければ世の中これで溢れ返っているところなんだろうなあ。
(3) PHP カンファレンス 2005 + LLDN (高橋さん) o PHP カンファレンス 2005 報告 - 午前は基礎セクション - 午後は中級以上セクション -- フレームワーク -- PHP5 への移行と今後 - 懇親会熱い o LLDN - 濃すぎ - PHP 特徴なさすぎ - やはり Ruby on Rails - Pugs -- Haskell による Perl6 実装 -- 本元 Perl 6 が動いてないのにこっちは動いている -- Haskell の勉強がてら作ったらしい (しかも 24歳。本当に「天才」みたい) - 夜はもっととんでもなかったらしい
この手のイベントは東京開催なんだけど、やっぱ無理やり時間作ってでもいかんとダメだな。
しかし RoR といい、Pugs といい、20代前半の人間が LL に風穴を開けているというのは凄いな。というかそうなってみたいもんだ。
(4) Maple 新機能 (高橋さん) o DI の説明 o AOP の説明 - 設定ファイルでの記述は今のところ、 [<関数名> = advice:<コンポーネント>] - 関数名箇所は正規表現あり o ActiveRecord - 今のところ Pear DB でテーブル構成を取得して DTO を決定してるみたい o これらをデモ実行 o Maple は PHP4 系でまだまだいく o AOP が好評だったら外に出してもいい o AOP まわりが導入されれば変更が大きいので 4.0 リリースという形になるだろう
えー項目が少ないですが別に内容がなかったということでは決してありません :) デモに見入っていたし、ダイジェストとしてデモ実行の詳細をグリグリ書いても仕方ないし。
ActiveRecord がこの度お目見えってことで一部な人は色々聞きまくってました。ワシも懇親会で数点。DTO 部分もそこで分かった。とりあえず 3.0.1 に向けてパッチ送らないといかん。
(5) 懇親会 (という名の宴会) o 使っているエディタは？ - Emacs マンセー！ - vi マンセー！ - 上記2大宗教のバトルはなく、お互いに認める優良エディタ - 「外出先 Windows 環境なら、サクラエディタいいよ」x N => 「何だそれは！？」 o PHP の今後
10月にはKOS2005, そして関西セミナーとしての次回は忘年会をかねた開催になりそうです。
