HUnitを使ってみた（ついでにHLintも） - 岩本隆史の日記帳（アーカイブ）
HaskellのユニットテストフレームワークであるHUnitを使ってみました。テスト対象のコードは、先日書いたsign関数です。 HUnitのインストール なにはともあれ、まずはHUnitをインストールしました。Cabalのおかげで簡単に入れられました。 $ cabal install HUnit テスト対象コードのモジュール名検討 つづいて、テスト対象コードのモジュール名を何にするか検討しました。このモジュールは「キープリスト」というWebアプリケーションで使う予定であり、AmazonのAPIに関わるものなので、「KeepList.Amazon」に決めました。 ファイル構成の検討 つづいて、テスト対象コードとテストコードをどのように配置するか検討しました。モジュール名の名前空間の階層をそのまま生かし、テストコードを「tests」ディレクトリに入れることに決めました。 $ tree . |
私が RESTful API の後方互換性を気にするケース - 岩本隆史の日記帳（アーカイブ）
前回の記事「RESTクライアントが知っているべきこと」に、id:nsiena さんからトラックバックをいただきました。 RESTful API の後方互換性 - Siena.の日記 斜め上の応答になってしまうかもしれませんが、思ったことを書いてみます。 API変更の性格分類とサーバがとりうる対策 まず、APIがどのように変更されるか分類し、サーバが取りうる対策をまとめてみましょう。 API変更の性格 サーバがとりうる対策（概要のみ） リソースのURIが変わる ステータスコードで「301 Moved Permanently」を返し、Locationヘッダで新規URIを返す。 リソースのメディアタイプが変わる Content-Typeヘッダで適切なメディアタイプを返す。リクエストのAcceptヘッダによっては、ステータスコードで「406 Not Acceptable」を返さなければならないかも
RESTクライアントが知っているべきこと - 岩本隆史の日記帳（アーカイブ）
クライアントとサーバの密結合を避けられるのが、RESTスタイルに従って得られるメリットのひとつです。クライアントが、アプリケーションの挙動に関する知識をほとんど持たなくてよいわけです。 とはいっても、まったく何も知らないではクライアントたりえません。では、何を知っていればよいのでしょうか。 知っているべき4点 その答えは、Roy T. Fielding による記事「REST APIs must be hypertext-driven」で、すでに示されています。下記の4つです。 通信プロトコル（communication protocol） 初期URI（initial URI） メディアタイプ（media types） リンク関係（link relations） AtomPubを例にとると分かりやすいでしょう。 通信プロトコル＝HTTP 初期URI＝サービス文書のURI メディアタイプ＝「a
続・コマンド的な処理をどうやってRESTfulに実装するか - 岩本隆史の日記帳（アーカイブ）
「コマンド的な処理をどうやってRESTfulに実装するか」に書いた内容を敷衍します。 SunのクラウドサービスAPI 先日、Sun MicrosystemsがSun Cloudというクラウドサービスを提供すると発表しました。 米Sun、Amazon対抗のクラウドサービス「Sun Cloud」を発表 - SourceForge.JP Magazine この記事には、クラウド操作用APIがRESTベースで提供される予定であることも書かれています。 Sunは開発者向けにクラウドAPI「Sun Open Cloud API」を提供する。RESTベースのAPIで、CreativeCommonsライセンスの下でリリースするため、開発者はSun Cloudと相互運用性のあるクラウドを構築できるという。 そのAPI仕様のドラフトが「The APIs for the Sun Cloud: Wiki: Hom
Rack用HTTPデーモンの複数起動を制御するスクリプト - 岩本隆史の日記帳（アーカイブ）
RailsでいうところのMongrelClusterのような、複数のHTTPデーモンを起動したり停止したりする仕組みがRackにもあったら便利だなーと思い、Daemonsを使う方法を考えてみました。 以下、サンプルコードに注釈をまじえながら。 まずはrequire require 'rubygems' require 'rack' require 'daemons' コマンドラインオプションで渡しそうなものをとりあえず変数で定義 app_dir = '/path/to/app' port = 3000 number = 3 command = 'start' # or 'stop' or 'status' or 'run' この例では、3つのポート（3000、3001、3002）でlistenします。 commandは、「start」なら起動、「stop」なら停止、「status」ならステ
ROAに準拠できない（しづらい）シチュエーションを列挙してみる - 岩本隆史の日記帳（アーカイブ）
ROAに準拠したWebアプリを作りたいのに、準拠できない or 準拠しづらいシチュエーションってありますよね？ 私はあります。それを列挙してみようという試みです。 なお、「ROAに準拠している＝ROAの4つの特性を満たしている」という等式を前提とします。これに納得できない方は、もう自分で考えればいいじゃない！ ROAの4つの特性 ROAには4つの特性があります。 アドレス可能性 ステートレス性 接続性 統一インターフェイス 詳細はid:ikasam_aさんの「ROA と Catalyst」をご参照ください。 ここからが本題。各特性について、「準拠できない（しづらい）かも」というシチュエーションを考えてみます。 アドレス可能性 Ajaxアプリだと準拠しづらいですね。たとえばAjaxベースのウェブメールで、メール検索結果にURIが割り当てられていなければ、その検索結果はアドレス不可能です。アド
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
