htmlspecialcharsに関する残念なお知らせ - 岩本隆史の日記帳（アーカイブ）
「htmlspecialcharsのパッチ私案」に書いた件、バグレポートを出してみましたが、「すでに同じバグレポートがあるだろ」という理由により、あえなく却下されました。 せめて先方が「同じ」とみなしているレポート番号ぐらいは示してほしくて、そのようにコメントしましたが、お相手のjaniという人は気難し屋のようで*1、教えてもらえる気がしません。 私なりに探した結果、下記のレポートがくさいように感じました。 PHP :: Bug #43896 :: htmlspecialchars() returns empty string on invalid unicode sequence 「不正なUTF-8シーケンスの場合に空文字列を返すのはおかしい」というレポートで、私のそれとは正反対どころか、Shift_JISにもEUC-JPにも触れられていない別個のものです。もちろん、私はレポート送信前に
拡張課金 ― どうすればサラリーマンがWebアプリで稼げるのか - 岩本隆史の日記帳（アーカイブ）
リリースチェッカーの現状 リリースチェッカーへの寄付の募集を始めてから4か月あまり。累積の寄付額は1600円です。 リリースチェッカーに関しては、Amazonの紹介料と寄付を受ける以外に収益化方法が思いつかない*1ため「たまに黒字になれば嬉しい」ぐらいの気持ちで運営を続けようと思っています。 Webアプリの収益化に挑戦したい 次に作ろうと思っている（そして製作がなかなか進んでいない）Webアプリでは、個人的に興味のあるアーキテクチャスタイル（REST、非同期）を利用しつつ、収益化に注力するつもりです。 別に貧乏なわけではありません（え？）。ただ稼ぎたいのであれば、携帯アプリやiPhoneアプリを作ります。私はWebアプリを作るのが好きなので、好きなことで稼ぐ手段を模索したいわけです。いつリストラされるか分からないご時世ですし。 会員制にする リリースチェッカーはユーザ登録不要で、それが売り
リリースチェッカーへの寄付の募集を始めました - 岩本隆史の日記帳（アーカイブ）
寄付の募集を始めました。がめついと思われるかもしれませんが、身銭を切りながらWebサービスを公開している技術者へのエールのつもりです。 リリースチェッカー：Amazonの新着情報をRSSで配信 というわけで、拙作のWebアプリ「リリースチェッカー」に対する寄付の募集を始めました。 Webアプリで稼ぐ手段 Webアプリでお金を稼ぐには、広告掲載、アフィリエイト、有料化など、様々な手段があります。 個人的に、Web上の広告は、役立つ場面よりも、ユーザビリティを損なう場面のほうが多いように感じています。したがって、自作のWebアプリには、広告を掲載したくありません。 また、個人で運営するWebアプリを有料化するのは難しいと思っています。たとえば、不具合があった場合の返金対応などに時間をさくのは困難でしょう。 リリースチェッカーの場合 リリースチェッカーのアイディアを思いついたのには、上記のような
ETagをどう生成するか - 岩本隆史の日記帳（アーカイブ）
ETagとは何か ETagはHTTPレスポンスヘッダのひとつで、RFC 2616の14.19（日本語訳）で規定されています。If-None-Matchリクエストヘッダを使った条件付きGETでの転送量軽減や、If-Matchを使った条件付きPUTでの競合検出などに使われる値です。 強いETag、弱いETag ETag（エンティティタグ）には強弱があります。簡単にいえば、HTML内のアクセスカウンタが1上がっただけで変わるのが強いETag、変わらないのが弱いETagです。弱いETagは、リソースの意味が変わらなければ変わりません。 同13.3.4では「HTTP/1.1 オリジンサーバにとってより望まれる動作とは強いエンティティタグと Last-Modified 値の両方を送る事である」とされています。なるべく強いETagを使いましょう、ということです。 Rails2.0の生成手法 「http:
「Me generation」の人もそうでない人も受け入れるのが理想？ - 岩本隆史の日記帳（アーカイブ）
id:ZIGOROuさんの「Building Relying Party Best Practice」（PDF）に対する工藤さんの指摘が面白い。そしてZIGOROuさんの返答も。 単純にまとめると、RPでは2通りのID管理方法： Claimed IdentifierをそのままRP上での“ID”扱いする あるいはRP上での“ID”に紐付ける が考えられ、ZIGOROuさんが2を推奨なさっているのに対し、「Me generationの人（アイデンティティをURLに求める人）にとっては1のほうが嬉しいのでは？」と工藤さんが指摘されたわけです。 ここからは私の素人考えですが、RPは、1と2のどちらが良いかをユーザが選べるようにしたら親切なんじゃないでしょうか。ZIGOROuさんのPDFでいうと、21ページの画面（Fastladderの例）で「User ID」を必須ではなく任意項目にすればよいのでは
Consumerのアカウント情報にはClaimed Identifierも紐づけるべきでは - 岩本隆史の日記帳（アーカイブ）
「ID管理と OpenID について - まちゅダイアリー(2008-01-11)」のスライドを見ていて、あれ、と思った。23ページの： 利用しているIdPがサービス終了 他のIdPにdelegateすればIDを変えなくてよい に引っかかったのだ。何が引っかかったかといえば、岡田耕一さんの記事と同じようなこと。 Consumerのアカウント情報にVerified Identifierのみが紐づけられていた場合、IdPがサービスを終了してしまうと、他のIdPにdelegateしてもConsumerのアカウントは使えないのではないか。 既存のConsumerはどうかと思い、たまたまアカウントを持っていた（けど全然使っていない）アバウトミーについて調べてみた。delegate先をlivedoor AuthからmyOpenIDに変えたところ、やはりログインできなくなった。つまり、アバウトミーのアカ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
