役に立ったらぽちっとよろしく。

ひさびさの更新、ブックマークレット

古いブラウザ向けに作られたサイトはレイアウトが変になって読みたい部分に他の部分が重なってうがーってなる時がある。Web インスペクタみたいな開発者ご用達ツールを使えば要素の削除もできるけど、これはこれで結構手間だし、リロードしないと元に戻せないという素晴らしい罠がセットになっている。同じレイアウトのページが沢山あって一つ一つ読む場合なんか泣けてくる。そこで、ちょっと自作。

1. clickAndHide (start)
2. clickAndHide (stop)
3. clickAndHide (restore)

使い方…

1. 上のリンクを全てブックマーク (お気に入り) に登録
2. レイアウトがおかしいページで start のブックマークをクリック
3. ページ内の消えて欲しい部分をクリックすると消える
4. 複数消せるのでどんどん消す。
5. もうこれで十分と思ったら stop のブックマークをクリック
6. 元に戻す場合は restore のブックマークをクリック

注1: IE9 や Chrome 等、最新のブラウザなら大概動くはずです。

注2: Flash 等で作られている部分は直接は消せませんがちょっと外側をクリックすると消えます。

Yahoo Japan なんかが実験しがいのある騒がしいコンテンツの充実したサイトです、笑。

す～っきり！

役に立ったらぽちっとよろしく。

昔の JSF、JSF1.2 の頃には、@ViewScoped がまだなく、おいらは同じ機能を自作してた。無かったのが不思議な位の機能なので、たぶん同じ事をしていた人も多いはず。で、ViewScoped がせっかく導入されたので、全部置き換えた。さよなら my code (涙)。。。

…けど、何か変。何故か c:if (JSTL) の test 属性の EL 式にビュースコープのマネージドビーンがあると、ポストバック時にも関わらず、新規作成される。…ぬ～、おいらは最近よく地雷を踏む、もしや、と思いまた検索してみると、Mojarra (GlassFish 同梱の JSF の参照実装) のバグだった。

で、どんなバグかと言うと、まず、Facelets で Partial State Saving が有効な場合に発生する。そして、ビューの再構築時に EL 式の評価が必要な属性で発生する。JSTL の属性や binding 属性がこれに該当する。例えば、c:if の test 属性は Restore View フェーズで動作し、下位コンポーネントの有無を決める。一方、JSF の rendered 属性はコンポーネントの表示の有無に関わるだけで、コンポーネントの有無自体には関わらない。そして、Partial State Saving の場合、ビューステートはテンプレートとの差分で保存されているので、復元時に最初にテンプレートを適用する構造上どうしても、一部の属性の評価がビュースコープのマネージドビーンの再構築より先に動いてしまう。結果、それらのビュースコープのマネージドビーンが、"無いので最初から作成します" という事になる。

しかし、最近本当によく地雷を踏んでしまう。まぁ、比較的新しい機能にすぐ飛びつくおいらの性格も悪いのだけど…。新機能を使って安全かどうかを確認するのに、プロジェクト毎の生還率 (バグに遭遇しなかった割合) を書いてて欲しい…と思った。で、本物の地雷原みたくドクロマークで表すとか。…ぬぉぉ～！周り全部ドクロマークじゃん！おぃおぃどうやって入ったんだよ！パラシュート部隊なんだよ俺は！！って事にならんように新技術の採用は慎重に、笑。

役に立ったらぽちっとよろしく。

ひさびさに EclipseLink (2.2 nightly) を使っていたら、はまった。フィールドにアクセスしただけで NullPointerException が出る。しかも、その stackTrace が null になっている。バイトコード変換が悪さをしてるっぽい。以前も書いたけどこれはホコ天で車にはねられるようなものだ。…以前まだ EclipseLink が TopLink だった頃、随分使ってたんだけど、このバグは初めて出会う気がする。で、EclipseLink の Bugzilla にバグですよ～と毎度の事ながら下手な英語で報告してみた。

すぐに Tom Ware さんなる方から返信があり、WONTFIX との事。WONTFIX ...??? どんな意味？と思って bugzilla のリンクを辿って調べると "バグだけど修正しない" ってな事らしい。そ、そうなの…あ、なるほど…即答だったし既出って事!? …早速、オートボクシングが関係しているらしいので、それを頼りに調べると、あったあった既に一年以上前にバグとして上がってる。で、さっきの Tom Ware さん曰く、将来直す！との事。それまでは文字通り手動ボクシング！が必要みたい。
ぬ～ん…真っ白な灰になるまでには治ってると助かる…。

バグの詳細

現状、EclipseLink はオートボクシングの部分がバイトコードウィービングの時点で誤って消されてしまう模様。つまり、this.value != 1 を this.value != Integer.valueOf(1) と自力で変換すると解決する (this は JPA の EntityBean, value はその Integer 型のフィールド)。

役に立ったらぽちっとよろしく。

EcmaScript 5th に興味あるけど、Rhino も FireFox も Chrome も Opera も IE も今の所完全には実装して無いみたい。一々、仕様書読むのも面倒だし、、、で、探して見たら BESEN ってのが SourceForge にあった。

どうも、Object Pascal で実装されてるっぽい。で、親切な事にコンパイル済みの Windows 用実行可能ファイルがある。試してみる…うん、動く。しかも、すぐ使えてシンプル！

せやけど、なんかあんまし紹介されてへんぽい…みんなあまし ES5 に興味ないんかなぁ…ちと残念。

BESEN 基本情報

トップページ	http://besen.sourceforge.net/
Win 版実行可能ファイル	http://besen.svn.sourceforge.net/viewvc/besen/trunk/ide/
ソース	http://besen.svn.sourceforge.net/viewvc/besen/trunk/src/
スクリーンショット

役に立ったらぽちっとよろしく。

セキュリティ対策ソフト (Avast) と Google と FireFox の相互作用でびっくりな現象が発生したのでメモ。

というのも、Google で Windows のレジストリ周りについて調べていたら、いきなり Avast が検索結果にウィルスが…みたいな画面を出してきた。

Google の検索結果にもしウイルスが含まれてたら、世界中で偉い事になる。だからそんな事はまずあり得ないはず。そして、Avast の誤検出とすれば、Google の検索結果を誤検出するセキュリティ対策ソフトなんて(怒)！…ってな訳で、これもまずあり得ない。………という事はおいらのパソコンが既に何かに感染？？？いや～ん！！！と思って調べ始めたら…そうでは無かった。

事の顛末は、以下のそれぞれの相互作用で起こったっぽい。

FireFox の Link prefetching

Web ページの作者が次にユーザがクリックしそうな、URL を予め指定しておいて、そのダウンロードを予め行っておく機能。これにより、実際にユーザがそこをクリックした場合に既にダウンロードが完了しているので表示が素早く行える。

Google が Link prefetching を検索結果に利用

Google の検索結果では Link prefetching を使って先頭の検索結果を指定している。

検索結果の先頭ページの内容

たまたま、IE6 のセキュリティホールを取り扱ったサンプルページが検索結果の先頭に来ていた。

う～ん、この問題、Avast 以外でも起こりそう…。対策としては Link prefetching を利用した場合は、HTTP ヘッダに X-Moz: prefetch が含まれるのでそのタイミングでマルウェアが検出されたら、そこではユーザに通知せずロードを遮断し 404 エラーとかを返しておいて、実際に必要なタイミングでは、ヘッダが含まれていないので「ウィルス検出」みたいなのを出す。…たぶんこんな手法が適当かな…。

思うに、こうした幾つもの要素が絡み合う問題って本当難しい…。

役に立ったらぽちっとよろしく。

続きを読む »