はてなブックマーク

ブックマークを http://b.hatena.ne.jp/IwamotoTakashi/ から http://www.delicious.com/iwamot に移動します。もちろん今般のトラッキング問題が大きなきっかけではありますが、それより前に「新ユーザーページの使いづらさ問題」という小さなきっかけもありました。自分のブックマークでなく「マイホットエントリー」をデフォルトにするセンスが僕には合いません。 優秀なエンジニアの退職はやまず、はてなアイデアは放置されっぱなし。今回のような大きな問題が起きても、社長が外遊中のためか対応が遅い。はてなには上場より先にやるべきことがあるのではないかと苦言を呈したくもなります。 ブックマークだけでなく日記も、そのうち別のサービスに移動しようと考えています。

前回の日記で「クライアントに的確なエラーメッセージを返すため、文字種のチェックと文字数のチェックは分けて行うべきかもしれない」と書いた。 このうち、文字数のチェックは簡単である。文字数をカウントし、許容文字数を超えていないかどうか調べるだけでよい。 文字種のチェックには悩みどころがある。どのような正規表現を使うのが適切かという点だ。読みやすく、かつ速い正規表現が知りたい。 さて、文字種チェック用の正規表現は2種類に大別できる。 禁止文字が1文字でも含まれればマッチ 許容文字のみで構成されていればマッチ 具体的には下記のようなものだ。制御文字（定義は前回の日記を参照）を禁じ、ただし改行とタブは認める例である。 /[\p{C}\p{Zl}\p{Zp}&&[^\t\r\n]]/u /\A[[^\p{C}\p{Zl}\p{Zp}]\t\r\n]*\z/u どちらも意図は明確で、読みやすさは変わらな

制御文字は不許可にすべき 前回の日記で「単なる書式チェック（文字種や長さなどのチェック）なので、アプリの要件にしたがって粛々と行えばよい」と書いた「(c)パラメータ文字列の妥当性検証」であるが、実は考えるべきことがそれなりにある。アプリの要件として、各パラメータの「許容文字種」と「許容文字数」を決める必要があるのだ。 このうち許容文字数については話が簡単である。最短および最長の許容文字数を決め、入力値がそれを外れていたらエラーにすればよいだけだ。 問題は許容文字種である。たとえば電話番号の入力を想定したパラメータ文字列であれば「数字またはハイフン」が許容文字種となるだろう。では住所欄や感想欄はどうか。あらゆる文字を受け入れてよいのだろうか。 もちろんアプリによってはあらゆる文字を受け入れなければならない場合もあるだろう。しかし「第11回■制御文字や不正な文字エンコーディングによるぜい弱性を

Hubrisという、RubyからHaskellのコードを呼ぶためのブリッジがあります。HaskellパッケージとRubyライブラリで構成されており、現在のバージョンは0.0.3です。 とある理由から、このHubrisで遊んでみようと思ったのですが、Haskellパッケージのインストールにかなり手こずったため、ポイントをまとめておきます。ちなみにRubyライブラリのほうは「gem install hubris」で簡単に入りました。 今回まとめる内容は、あくまで僕の環境（CentOS 5）でうまくいったもので、他の環境ではどうだか分かりません。誤った記述があるかもしれませんので、お気づきの際はぜひお知らせください。 Hubrisで遊びたくなった理由については、後日書くつもりです。 ざっくりした流れ $ wget http://hackage.haskell.org/packages/archi

今回はRuby製Webアプリでの入力チェック手順について考えてみる。Ruby1.9を使い、Railsなどのフレームワークは使わない前提だ。 文字エンコーディングの妥当性検証こそが重要 徳丸浩さんの『体系的に学ぶ 安全なWebアプリケーションの作り方』には「入力処理」として下記3つの処理が挙げられている。 (a)文字エンコーディングの妥当性検証 (b)文字エンコーディングの変換（必要な場合のみ） (c)パラメータ文字列の妥当性検証 このうち(c)は単なる書式チェック（文字種や長さなどのチェック）なので、アプリの要件にしたがって粛々と行えばよいだろう。 (b)も必要な場合にだけ行えばよいので、さほど重要ではない。 重要なのは(a)で、これをいかにRubyで実現するかだ。同書では（おそらく意図的に）Rubyへの言及はなかった。 Rubyでは(b)→(a)→(c) RubyのStringには、St

RVM上のRuby1.9.1にThinをインストール後、ためしに「thin -v」したら、「thin.rb:6:in `require': no such file to load -- openssl (LoadError)」となった。 どうしようかといろいろ調べたら、「All about Ruby on Rails & Data recovery software」に答えが書いてあった。 $ rvm remove 1.9.1 $ rvm install 1.9.1 -C --with-openssl-dir=/usr/localのようにすればOKということ。 実際にやってみた。 $ rvm remove 1.9.1 Removing /home/iwamot/.rvm/src/ruby-1.9.1-p378... Removing /home/iwamot/.rvm/rubies/ru

いつも思いつきで恐縮ですが、「Webアプリの画面はRESTfulなAPIの一クライアントにすぎない」んじゃないかと考え始めています。 ひらめいたのは、Rails2.0のルーティングを調べていたとき。scaffoldを使うと、下記のようなルーティングになるらしい。 アクション メソッド URL例 一覧画面 GET /bookmarks 登録画面 GET /bookmarks/new 登録処理 POST /bookmarks 参照画面 GET /bookmarks/1 編集画面 GET /bookmarks/1/edit 更新処理 PUT /bookmarks/1 削除処理 DELETE /bookmarks/1 このうち、登録画面と編集画面に違和感を覚え、はたと気づきました。一覧画面や参照画面がリソースの素直な表現であるのに対し、登録画面と編集画面はPOSTやPUTのためにやむなく用意された

書きました。 Twitter - Better saved searches for Greasemonkey リアルタイム検索結果が0件になると検索メモが削除（解除）できなくなるんですが、なんでこんな仕様なんでしょうね。 ともあれ、不必要な検索メモが削除できて、僕はすっきりしました。 追記（2010-07-20） バージョンを1.1.0に上げました。リアルタイム検索結果が0件の場合でも、検索メモが保存できるようになっています。このほうがテストしやすいので。 保存できるし 削除もできる 追記その2（2010-07-20） 何度もすみません。バージョンを1.1.1に上げました。@include に「https://twitter.com/*」を追加しています。 追記その3（2010-07-22） バージョンを1.2.0に上げました。検索メモを10件以上保存できるようになっています。せっかくな

HaskellのユニットテストフレームワークであるHUnitを使ってみました。テスト対象のコードは、先日書いたsign関数です。 HUnitのインストール なにはともあれ、まずはHUnitをインストールしました。Cabalのおかげで簡単に入れられました。 $ cabal install HUnit テスト対象コードのモジュール名検討 つづいて、テスト対象コードのモジュール名を何にするか検討しました。このモジュールは「キープリスト」というWebアプリケーションで使う予定であり、AmazonのAPIに関わるものなので、「KeepList.Amazon」に決めました。 ファイル構成の検討 つづいて、テスト対象コードとテストコードをどのように配置するか検討しました。モジュール名の名前空間の階層をそのまま生かし、テストコードを「tests」ディレクトリに入れることに決めました。 $ tree . |

『Webを支える技術』の101ページに、こう書かれています。 リソースの状態に変化を与えることを副作用（Side Effect）と言います 僕の読み落としでなければ、この定義の出典は同書には明記されていません。ただ、HTTPメソッドの冪等性や安全性を解説する文脈で紹介されているので、HTTP/1.1の仕様書であるRFC 2616が出典なのだろうと思います。 RFC 2616の本文には、「副作用」（side-effects あるいは side effects）という言葉が9回出てきます。最初に出てくるのは「9.1.1 Safe Methods」においてです。橋本英彦さんによる日本語訳を引用します（強調は岩本、以下同じ）。 本質的に、サーバが GET リクエストを実行した結果として副作用を起こさないという事を保証するのは不可能であり、事実、いくつかの動的なリソースはそれが特徴であると考えている

なぜHaskellに興味をもったのか 僕がHaskellに興味をもったきっかけは、『まつもとゆきひろ コードの世界?スーパー・プログラマになる14の思考法』（通称「ホスト本」）でした。 ホスト本の第14章「関数型プログラミングについてなど」では、関数型プログラミングの特徴が4つ挙げられています。 関数そのものをデータとして捉える（ファーストクラス関数） 関数を引数として取る高階関数 同じ引数を取る関数は同じ結果となる参照透明性 参照透明性を実現するための副作用の忌避 このうち「参照透明性」が特に興味深く感じました。「同じ引数を取る関数は同じ結果となる」のですから、きっとテストが書きやすいはずです。「状態」によって結果が変わるオブジェクト指向言語ではテストが書きづらいと日頃から思っていたので、この参照透明性は福音のように感じられました。 その「参照透明性を実現するための副作用の忌避」が徹底さ

キープリストで提供するリソースのURI キープリストというWebアプリを作ろうとしています。気になる商品（Amazonで扱っているもの）を放り込んでおけるサービスです。 以前の日記では、URIの設計について考えました。それからも断続的に考えていて、現在は以下のようにしようと思っています。 リソースURI トップレベルリソースhttp://keeplist.in/ 商品検索結果リソースhttp://keeplist.in/amazonsearch?q={キーワード}&format={html または json} 商品リソースhttp://keeplist.in/Item:{ASIN}.{html または json} 本当はもっとたくさんのリソースが必要ですが、書き込み可能なWebサービスの設計は高難度なので、まずは読み取り専用部分のみ考えることにします。 さて、『Webを支える技術』で紹介さ

先日書いたように、作りたいWebサービスがあります。当然ながら、まずは設計から始めなければなりません。 設計にあたっては『Webを支える技術』の第15章で紹介されているサービス設計手法を用いることに決めたのですが、URI設計のステップで、はたと考え込んでしまいました。 以下、第15章に掲載されているURI例で違和感の原因を探ってみます。 郵便番号リソースのURI http://zip.ricollab.jp/1120002これは違和感ありません。 検索結果リソースのURI http://zip.ricollab.jp/search?q=小石川ここで若干の違和感を覚えます。郵便番号データのキーである「1120002」と「search」が同列に並んでいるのが原因です。 いや、とくに気にする必要はないのかもしれません。「search」という郵便番号は今後も現れないでしょう。もし現れたとしても、ク

前回の日記の続きです。『Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)』の第3部と第4部を読みました。以下、特に勉強になった点などのメモです。 第3部 HTTP リソースの作成はPUTよりPOSTが望ましい。PUTはサーバとの結合が密になる（96ページ） キャッシュ可能なリソースにはできるだけETagヘッダを利用する。Last-Modifiedより正確に更新確認できる（148ページ） 第4部 ハイパーメディアフォーマット hProductというmicroformatsドラフトがある（179ページ）→前々回の日記に書いたとおり、Amazonの商品情報を扱うWebサービスを作る予定なので、これが使えるかも。調べてみよう。 Atom Threading Extensions（201ページ）→スレッド機能を表現するためのAtom拡張（RFC

昨日の日記の続きです。『Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)』の第1部と第2部を読みました。 第1部 Web概論 「第2章 Webの歴史」が知らないことばかりで面白かった。個人的に興味深かったのは、SOAP対RESTの論争に火を付けたのがAmazon Webサービスの利用比率報告だったこと（23ページ）。私も早くから利用していたけれど、（いわゆる）REST形式のAPIをまよわず選んだのを覚えてます。「Webサービスを提供するなら、なるべくシンプルにしないと、使われない可能性が高まる」ということが分かります。 第2部 URI 「クライアントで相対URIを解決するには面倒な処理が必要になるので、WebサービスやWeb APIを実装する場合はなるべく絶対URIを使ったほうがクライアントにとって親切でしょう」（51ページ）という発

この記事の更新履歴 2010-03-04 この記事を随時アップデートしていくことに決めた。「Gmail Unread Message Count in Favicon」を追加。 本題 Firefox 3.6上で有効にしているGreasemokey一覧を晒してみます。珍しいものもあると思いますので、お役に立てば幸いです。 逆に「あれ入れてないの？」とか「こっちのほうが便利だよ」とかあれば、ぜひお教えください。喜びます。 全サイトで有効 AutoPagerize 定番。次ページを自動で読み込める。 LDRize 定番。livedoor Readerのショートカットキーが他のサイトでも使える。が、あまり活用していない。 Minibuffer 定番。いろんな便利コマンドがCUIで実行できる。が、あまり活用していない。というか、LDRizeのために入れているだけ。 Fast Look up Alc

「RubyでオレオレWebアプリケーションフレームワークを作ろう」と思ってからどれほど経ったのか、過去記事をさかのぼれば分かりそうですが、きっと呆れるくらい経っているので、あえて調べないことにした岩本です、こんばんは。 フレームワーク作りにこれだけ時間がかかっているのは「フルスタックにしなければならない」という固定観念があったせいだと、最近ようやく気づきました。id:dannさんによる「Angelosで学ぶ優しいWAFの作り方」のおかげです。 フレームワーク作りはそんなに大変じゃない dannさんのプレゼンテーションでは、フレームワークの最小構成要素が下記のように示されています。 Engine - req/res, サーバー抽象化 Dispatcher - URLとControllerのmapping Component Loader - controllerのload + control

前回の記事にて、妥当なユーザIDとパスワードを決めました。そこで、さっそくバリデーション処理をBDDで実装しようとしたのですが、適切なシナリオがなかなか決まりません。 たとえば、ユーザID。許可する文字種は英数字および「-」「.」「_」です。妥当な文字数は2〜24文字。この仕様で妥当となるユーザIDは、計算するのも嫌なぐらいありえます。したがって、これらをすべてテストするわけにはいきません。どこまでテストすればよいのでしょうか。 また、妥当でないユーザIDのテストケースも必要です。たとえば「~」が含まれるユーザIDは「妥当でない」と判断されなければなりません。そのような文字は山ほどある（ひらがな・カタカナ・漢字・記号など）ので、これらもすべてテストするわけにはいきません。 テストケース作りの指針 そこで、何か指針はないかと探したところ、下記のPDFが見つかりました。 ソフトウェアテスト技術

このところ、スケーラビリティについて私が考えても無駄ではないかと思い始めている。私が仕事で作っているのは小規模のWebアプリだし、転職する予定も今はない。趣味のほうはといえば、Webアプリ運営に使える予算などたかが知れていて、安いVPSが1台借りられる程度だ。大規模サービスなど作れない。 さらにいえば私は、数十万、数百万ユーザのためのサービスを作ろうと思ったことがない。ユーザが多ければ多いほど儲かる可能性はあるのだろうが、私の目的はカネ儲けではない。私が不便と感じている日々の作業は、この世でたぶん数十人ぐらいの人が同じように不便と感じているはずで、そんなちょっとした不便を解消するWebアプリが私は作りたいのだ。 グリーの社長は「みんな、そこそこの人生で、そこそこで楽しくて、そこそこの成長というのは目指してないよね。日本に失われつつある高度成長期を、この会社だけでやろうよ」といっているらしい

お題：クラス名からそのクラスを得るライブラリ Webアプリのフレームワークを作っていて、クラス名からそのクラスのインスタンスを生成したくなりました。リクエストURIによって呼び出したいコントローラが変わるためです。 そこで、下記のような ClassGetter ライブラリがあると便利だと思いました。 class_name = "MyFramework::Controller::#{controller_name}" controller_class = ClassGetter.new.get(class_name) controller_class.new.run 普通に実装してみる Rubyには、クラス名からインスタンスを得るためのイディオムがあります。 c = classname.split(/::/).inject(Object) {|c,name| c.const_get(name