タグ

ブックマーク / developer.cybozu.co.jp (13)

  • Kazuho@Cybozu Labs: String::Filter っていうモジュール書いた - 続: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について

    先のエントリ「(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について」の続き。 弾さんが「404 Blog Not Found:DHTML - 構造化テキストは構造化するのがやっぱ正しい」で示されているような DOM ベースの操作を行えば、原理的に XSS 脆弱性を防ぐことができます。ただ、クライアントサイド JavaScript によるレンダリングはウェブの構造を破壊するという点で筋が悪い(テーブルと FONT タグを利用したページレイアウトが批判されていた頃を覚えていらっしゃいますでしょうか。JavaScript によるレンダリングはウェブのリンク構造も破壊するので一層たちが悪いというのが自分の考え)ですし、サーバサイドでの DOM 操作は重たいので、できれば避けたいところです。 構造化テキストの HTML への変換は、よほど複雑な記法でない限り

    Rewish
    Rewish 2010/09/25
  • Kazuho@Cybozu Labs: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について

    昨日の Twitter の XSS 騒ぎは、まだ皆さんの記憶に新しいことと思います。いい機会なので、ツイートのような構造化テキストのエスケープ手法について触れておきたいと思います。 Twitter のメッセージは、単なる平文(プレインテキスト)ではなく、「@英数字」のような他のユーザーへの言及と「http://〜」のような URL を自動的にハイパーリンク化する構造化テキストです。 このような複数のルールをもつ構造化テキストを HTML 化する際には、どのようなコードを書けばいいのでしょう? まず「@〜」をリンク化してから、URL をリンク化すればいいのでしょうか? それだと、@〜 のをリンク化した A HREF タグの中の URL がさらにリンク化されていまいますね。 では、URL をリンク化してから @〜 をリンク化すればいいのでしょうか? それだと、@ を含む URL があった場合に

  • Cybozu Inside Out: ScaleBench 公開

    どーもみなさま。こんにちは。 amachang と申します。 さて、ようやく ScaleBench というプロダクトが発表されましたね! ScaleBench のご紹介 で、僕もこれの開発に携わっていたのでちょっと技術的なことについて書いてみたいと思います。 ScaleBench とは ScaleBench とは、サイボウズ製品向けの負荷テストツールで Grinder というオープンソースの負荷テストツールをベースにしています。 Grinder とは Java を使った Web の負荷テストツールです。 Jython でシナリオ(ユーザがどう行動するか)を書いてそれを実行します。 またブラウザの操作を記録して、シナリオを自動で生成することもできたりします。 で、僕がこのプロジェクトで担当していたのが Grinder の改良、改造 シナリオ(バーチャルユーザがどのような順で負荷をかけていくか

    Cybozu Inside Out: ScaleBench 公開
  • Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)

    といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいいだと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という2つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく

    Rewish
    Rewish 2010/04/25
  • Cybozu Inside Out: SpiderMonkeyを使ってPHPでサーバーサイドJavaScript

    はじめまして。2009年に新卒で入社しました天野祐介です。amachang を期待された方はゴメンナサイ! 先日 SpiderMonkey を利用して PHP から JavaScript を実行する方法を調べる機会がありましたので、ご紹介します。 SpiderMonkey とは SpiderMonkey は  C で実装された Mozilla の JavaScript エンジンです。 これを PHP から実行する拡張を利用すると、 PHP コード内で JavaScript が実行できます。 SpiderMonkey extension のインストール こちらhttp://devzone.zend.com/article/4704に記載されている方法で CentOS にインストールしてみました。 PHP 5.3.0 以上が必要です。 $ wget http://ftp.mozilla.org

    Cybozu Inside Out: SpiderMonkeyを使ってPHPでサーバーサイドJavaScript
    Rewish
    Rewish 2010/02/04
    丁寧な記事。
  • Kazuho@Cybozu Labs: 監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)

    結論から先に。cronlog を使えば、アプリケーションのテストコードと全く同じ形式で、監視用のスクリプトを書くことができます。プログラマが監視ツールの記法を覚える必要はありません。これは、プログラマが運用も行うケースでは特に有効な手法だと思います。 先週公開した Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法 というエントリで、crontab と拙作の cronlog を用いてサービス監視を書く手法を紹介しました。しかし、挙げた例はいずれも ping や http のテストといった外形監視の手法です。RDBMS とウェブアプリケーションのみから構成されるサービスならそれだけで十分でしょう。 しかし、外形監視だけでは、メッセージキューのような非同期処理の遅延を観測することはできません。また、http のログを監視して、エラーレスポンスや平均応答

    Rewish
    Rewish 2010/01/18
    Perl学習のフラグ・・・?
  • Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法

    監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)に続きます 今日ようやく、積ん読状態だった「Software Design 2010年1月号」を手に取ったのですが、特集が「今日から使えるスクリプト満載! [プロ直伝]お手軽サーバ監視術」。興味深く拝読したのですが、もっと楽ができるのにと思うところも。ちょうど、昨年末に運用しているサービス「パストラック」のサーバを移転し、crontab と perl で書かれたスクリプト群を使った監視環境を構築したところなので、そこで使っているスクリプト cronlog を紹介したいと思います。 特集の前書きにも書かれていることですが、サーバやネットワーク機器が多数ある環境なら、Nagios を始めとする、専ら監視のために作られたソフトウェアを使って、監視システムを構築すべきです。逆に小規

  • Kazuho@Cybozu Labs: Perl のテスト用に MySQL 環境を自動で構築するモジュール Test::mysqld を書いた

    ORM やウェブアプリケーション関連のライブラリなどのテストケースを書くにあたっては、 RDBMS へのアクセスが必要になります。しかし、SQLite のようなスタンドアローンのデータベースと比較すると、サーバ型データベースである MySQL に接続してテストを書くのは、既存の MySQL の権限設定やデータベース名を気にする必要があったりと、いろいろ不便です。そこで、MySQL のインスタンスをテンポラリディレクトリに自動生成し、テストが終わったら削除してくれる Perl モジュール Test::mysqld を書きました。こんな感じで使います。 use DBI; use Test::mysqld; use Test::More; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '' }, # TCP接続を

    Rewish
    Rewish 2009/08/05
    すごく良い
  • Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法

    MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a

  • Android初心者の最初の2週間での感想

    Androidの開発機を入手して2週間ほど経つのですが、その2週間の感想です # 2週間といっても、他にいろいろとやってたのですが(個人の方で新サービス読んだ4!のテスト公開とか) この手のことをするのは、2002-3年ぐらいにPocket PCの開発をやって以来なので、少しずれてるかもしれませんが。いろんな事が簡単にできるようになっているなあと、時代の違いを感じました。 開封から設定 設定にパソコンは不要 [開封]-[起動]-[タイムゾーンと日時の設定]-[WiFiの設定]-[Googleアカウントの設定] で。Gmailが使えるようになり、GmailのコンタクトもAndroid上で閲覧できるようになりました。携帯電話として使うためのSIMは持ってないし、持っていたとしても使うとたいへんなパケット料金になるらしいので、無線LANだけで使ってます。 Gmailのコンタクトに電話番号の情報は

  • 記号でPolyglotプログラミング♪(RejectKaigi2009) | TAKESAKO @ Yet another Cybozu Labs

    RubyKaigi2009の最終日に同じ場所で開催された別のイベント「RejectKaigi2009」にて 「はじめてのRuby1.9プログラミング」と題して、記号Polyglotプログラミングの話をしてきました。 3分という限られた時間でありましたが、貴重な発表の機会を与えてくださりありがとうございます。 取り急ぎプレゼンで披露した記号Polyglotのプログラムを公開しておきます。 ■ hello.pl (という名前ですが、Perlの他にRubyJavaScriptでも実行できるプログラムです) "#{",$/*"}";%#=();$^_^=’?“;">)~${`&&@`{;:+`[[‘,$^_^=’/?")-=^{(=!".=.!,!)&&>’,$^_^=’`-+|{!?“*.((-+({:^(_^’,$^_=”^’+@$@&’^’^.@%@’.’$^_^"";’.$^_^"",’

    Rewish
    Rewish 2009/07/20
    読めない。
  • Kazuho@Cybozu Labs: MySQL のトリガーの実用性を確認するために InnoDB の SELECT COUNT(*) を高速化してみる

    最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。 InnoDB はしばしば、「SELECT COUNT(*) が遅い!」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか? 以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャッシュしてみることにします。 mysql> create table t1 ( ->   id int unsigned not null primary key auto_increment, ->   v int unsigned not null -> ) engine=innodb

    Rewish
    Rewish 2009/06/30
  • Kazuho@Cybozu Labs: Pacific という名前の分散ストレージを作り始めた件

    大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名:アプリケーションレベルパーティショニング/レベル2分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加(とそれにともなう負荷の再分散)が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:

    Rewish
    Rewish 2009/06/11
  • 1