CSSセレクタ簡易対応表｜CSS HappyLife:nth-last-of-type() IE 6：× IE 7：× Fx 2：× Op 9.1：× Sf 2.0.4：×
eAcceleratorとAPCのパフォーマンス比較 - Do You PHP はてブロ
id:koyhogeさんからのリクエスト(^^;で、比較してみました。 実行したコードは、以前Sebastian Bergmann氏がコンパイラとコンパイラオプションの違いによるパフォーマンス比較を行った際に使った（と言っている）コードで、cvs.php.netにあります。 テストした環境は以下の通りです。 CPU:Pentium4 3.0GHz/Mem:1GB CentOS4.4 Apache 2.2.4(src) PHP 5.2.1(src) APC 3.0.14（extension） eAccelerator 0.9.5＋5.2.1用パッチ（extension。zend_extensionではない） Apache再起動後、Firefoxから上記PHPコードを実行 今回の結果は次のような感じです。ちょっとグラフが見づらくてスミマセン。やはり「得手/不得手」があるみたいです。 以下、生デ
Linuxディストリビューション進化図 | 秋元@サイボウズラボ・プログラマー・ブログ
via digg このディストリビューションはあのディストリビューションの流れを汲む、とかそういうのがわかる、タイムライン上に書かれたLinux派生の系統図があった。 とはいってもPlamoとかVineとかもないし、特定用途向けやローカルに勢力のあったものとかも含めるとこんな数ではおさまらないんだろうな。 [参考] Unix全体に関する同様のもの。もっと長くて広くなる。 この記事は移転前の古いURLで公開された時のものですブックマークが新旧で分散している場合があります。移転前は現在とは文体が違い「である」調です。(参考)記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません
ウノウラボ Unoh Labs: 携帯におけるメールアドレスの制限について調べてみました
まず、携帯のメーラでは宛先に入れられるByte数が決まっています。 DoCoMo: 50Byte au: 64Byte SoftBank: 128Byte
DSAS開発者の部屋:パソコン1台ではじめるロードバランサ体験
昨日書いたの通り，記事を寄稿したWEB+DB PRESS Vol.37が，今日発売になりました．それを記念して(?)，記事の内容が簡単に実験できるパッケージを公開します． これは，VMWareを使って，だれでも直ぐにロードバランサの実験を始められるパッケージになっています．何台もマシンを集めたり，Linux をインストールする必要は一切ありません．無償配布されているVMWare Playerがあれば，いつでもどこでも実験ができます． もちろん，このブログで去年の夏に公開した4つのエントリ こんなに簡単！ Linuxでロードバランサ (1) こんなに簡単！ Linuxでロードバランサ (2) こんなに簡単！ Linuxでロードバランサ (3) 高トラフィックに対応できるLinuxロードバランサを目指して〜LVSをNATからDSRへ の実験もできます． ダウンロードはこちらからどうぞ(75MB
まだまだあるクロスサイト・スクリプティング攻撃法
前回はクロスサイト・スクリプティングのぜい弱性を突く攻撃の対策としてのHTMLエンコードの有効性を述べた。ただ，HTMLエンコードだけではクロスサイト・スクリプティング攻撃を完全に防御することはできない。そこで今回は，HTMLエンコードで対処できないタイプのクロスサイト・スクリプティング攻撃の手口と，その対策について解説する。 HTMLエンコードで対処できない攻撃には，次のようなものがある。 タグ文字の入力を許容している場合（Webメール，ブログなど） CSS（カスケーディング・スタイルシート）の入力を許容している場合（ブログなど） 文字コードを明示していないケースでUTF-7文字コードによるクロスサイト・スクリプティング <SCRIPT>の内容を動的に生成している場合 AタグなどのURLを動的に生成している場合注） 以下では，HTMLタグやCSSの入力を許容している場合と，文字コードを明
UTF-8 エンコーディングの危険性 - WebOS Goodies
基本的に、まともな国際化ライブラリを使っていれば、上記のような不正な文字コードはきちんと処理してくれるはずです。実際、 Opera, Firefox, IE ともに適切にエスケープしてくれました。また、 UCS に変換した後にエスケープ処理を行うことでも対処できるかもしれません。しかし、複数のモジュールで構成されるような規模の大きいアプリケーションでは、そのすべてが適切な処理を行っていると保証するのも、なかなか難しいかと思います。ここはやはり、すべての外部入力に含まれる不正なシーケンスを、水際で正規化するという処理を徹底するのが一番かと思います。 例えば Ruby の場合、不正な UTF-8 コードを検出する最も簡単な方法は、 String#unpack を使って UCS へ変換してみることです（昨日の記事への kazutanaka さんからのはてぶコメントにて、 iconv でも同様なこ
おさかなラボ - 携帯電話のIPアドレス制限神話
珍しく間違った批判をしている高木先生＠y-kawazの日記 但し、キャリア毎にIPアドレス制限をする限りにおいて この前提を満たすことが可能なのかどうかについて。 DoCoMo(i-mode) 本情報はあくまでも目安としてご参照ください。iモードセンタ以外から本IPアドレスでのアクセスがない事を保証するものではありません。 SoftBank 本情報はあくまでも目安としてご参照ください。ゲートウェイ以外から本ＩＰアドレスでのアクセスがない事を保証するものではありません。 au(EZweb) 本情報はEZサーバ以外のホストによる上記表のIPアドレスでのアクセスがないことを保証するものではありません。 まるでコピp…いや判で押したような記述だ。つまり、この情報を元にIPアドレス制限を行なっても携帯電話からのアクセスであると保証されるわけではないということだ。これではいわゆる野良
おさかなラボ - 携帯電話からセッションIDの漏洩を防ぐ
携帯電話向けWebアプリの脆弱性事情はどうなっているのか@高木浩光＠自宅の日記 より リンク先のWebサイトには、Refererと共に端末IDもリクエストヘッダとして送信されているわけで、セッションID入りURLと端末IDがセットで流出するのだから、当然、同じHTTPリクエストを送るだけの方法でなりすましアクセスされてしまう。 URIにセッションIDを含める方法では、悪意のあるサイトにリンクを張るだけでRefererヘッダからセッションIDが取り放題となる。また、悪意のあるサイトにアクセスしたユーザーは端末IDもHTTPヘッダに含めそのサイトに送信してしまう。端末IDは簡単に詐称することが出来るので、端末IDをチェックしてもセッションハイジャックの防止線にはならない、というお話。 私は携帯端末は専門ではないので細かいことは良くわからないのだが、以下を前提にして、携帯電話からセッション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
シェル・スクリプト・リファレンス INDEX：ITpro