すごい良い記事。 知られざる「マルチテナントアーキテクチャ」（2）～スケーラビリティのカギは組織ID － Publickey 知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey 頼まなくてもこういう記事を書いてくれる人が増えている（頼まれてないっすよね？）のは、SFDCにとって、デベロッパーマーケティングとして成功だと思う。大事にしてくださいね。 スキーマについて 上記記事では、データベースの物理スキーマについて、公開情報をもとに分析されています。 掟破りのスキーマ セールスフォースのアプリケーションで扱われるすべての数字や文字のデータは、Dataテーブルに保存される。このことがセールスフォースのデータベーススキーマの核心です。 Dataテーブルはどんなデータでも受け入れられるよう、次のようなスキーマになっています。恐らく、データベースに詳し

このブログでは、ずいぶん前に作った「JSONで使えるサービス一覧」というエントリが今のところずっと人気エントリらしいです。最近いっぱいJSONPサービスは出てきてるっぽいので、もしかして少しでもこのエントリが役に立ってくれていたならうれしいことです。 でも、そもそもブログの１エントリだったことですし、ずっとページをメンテしてないので、もはやJSONP情報のディレクトリとして扱うには古いと言わざるを得ません。でもメンテも大変なので、できればユーザ参加型でメンテしたいところです。 おそらくこういうののためにたぶんWikiとかがあるのかもしれないですが、なんか別の方法を使ってみたくなって作りました。 で、作ったのが、こんなの。 http://www.geocities.jp/stormriders999/jsonpdirectory.html JSONPのディレクトリサービスなので、JSONP(

JavaScriptからRailsをRESTfulに操れるJesterの話 http://blog.tkmr.org/tatsuya/show/301-jester-restfull-rails-javascript データベースへのCRUDな操作をブラウザのJavaScriptコンソールでやる世界。FirebugがSQL*Plus的なターミナルにもなり、一層IDEに近づく。 正直最近のエクスペリエンスはこれに近い。もうTeraTermとか使わないでも仕事できるという環境にある。時々もはや技術者ではないのではないかとまで思ってしまう。実際「一日中ブラウザばっかり見ているよ」とか普通の人に言ったらたぶん窓際社員確定の印象しかもたれないだろうしな。

いろいろなことを手抜きしようと思ってExt JSを見ていたのだけど、なかなか良さそう。少なくとも今のプロジェクトの手抜きには適している。 案外よかったのが、クロスドメインで読み込みしてもちゃんと使えるということ。ウィジットまで含めてクロスドメインで読み込めるUI系のライブラリは案外少ない。あ、嘘、dojoとYUIはもう対応してるみたいだし、他にもあるかも。dojoはクロスドメインかつ動的に読み込めるのはすごいよね。がんばったね。 もちろん、ちゃんとライブラリのアーカイブをダウンロードして自分のサーバにインストールして使うというのが、相手サーバにも迷惑をかけず、かつセキュリティ的にも好ましく、まっとうなアプリを作ろうとする人にとっては正しいのだと思います。でも、クロスドメインで読み込めるということはbookmarklet化も出来るということなのです。つまり、どんなサイトであったとしても、bo

AOLのOpenAuthという認証APIがあります。YahooのBBAuthだったり、Google Account Authentication、日本で言うならはてな認証、livedoor Authなどに代表される、最近流行のサービスプロバイダによる認証APIの一種なんだと思います。ただ、少なくともAOL IDを使うことはほぼないから、アナウンスは聞いてもとりあえずスルーしてたのだけど、たまたま仕様を読んでいたらかなりびっくりした。なんと通信経路にJSONPを使って認証トークンをやり取りできてしまう。JSONPはパブリック情報の配信以外に使うな、ってのが常識になりつつあった人たちから見たら、これはたぶん衝撃。 でも、これがセキュリティ的にヤバいかっていうと、決してそうではなくって、OpenAuthではいわゆる「リファラによるサイト制限」を実装しているところがポイント。つまり、JSONPリク

情報共有の進んだ会社とかでは、メールをもらったお客さんのことをちゃんと組織として覚えておくために、コンタクト情報としてデータベースに共有することを推進していることが多い。でも、いくらメールには署名があって、すでに電子化されているとはいえ、ふつうはテキスト直書きの署名だったりして、構造化されてなくってかなり扱いにくい。データベースに登録するために、メーラーとブラウザの間で氏名をコピペ、メアドをコピペ、電話番号をコピペということをひたすら繰り返す。正直あまりやりたくない。 まあそんな作業をやらされる側にいるという大前提があるのだけれども、そんな不毛な作業をちょっとでも軽減するために、このスクリプトは作られました、実用系スクリプト第３弾。実用系ということですが、実装はたいしたことない、でもなんか今までになく便利になりそうな予感。 デモサイトはこちら： http://www.geocities.j

http://code.google.com/apis/gears/security.html Database Security Best Practice:: Avoid SQL injection attacks. Never insert user input directly into a SQL statement. Instead, use substitution parameters in Database.execute(). ユーザの入力をダイレクトにSQLに入れるな、SQLインジェクション攻撃食らうよ、と書いてある。 ぱっと見たところなるほどね、ってなるけど、よく考えたら攻撃するのはそのユーザ自身が持ってるローカルデータベースでしょ、もともと自由自在じゃんって思うのだけどなあ。サーバとのデータ同期がバックグラウンドで自動的に行われるから？いまいちデータ同期のところは

http://labs.cybozu.co.jp/blog/kazuho/archives/2007/05/coopthread.php JavaScript/1.7 の話なので Firefox 限定です。以前、 残念ながら、JavaScript には非同期メッセージを同期化する方法はない！残念！＞＜ほんとに残念！ JavaScript 1.7 なら yield でできるんじゃないかと思いました。 と書いたっきり失念していたのですが、社内で話題になったので実装してみました。 ということはyield使えばきっと http://d.hatena.ne.jp/amachang/20061129/1164799871 の逆に、最後にcallbackをとる非同期関数を同期化して Function.prototype.synchronize = function() { var args = Arra

元ネタ： http://labs.cybozu.co.jp/blog/kazuho/archives/2007/05/coopthread.php これを見て書いたエントリ： http://d.hatena.ne.jp/shinichitomita/20070525/1180106472 上のエントリは、実装前とはいえかなり大間違いなスクリプト書いてる。何やってるんだか。 とりあえず先のエントリのコメントで「for ループの中でyield使えばできる」とわざわざもらったので、ちょっとやってみる。 /** * del.icio.usのJSONP呼び出し。非同期でコールバック関数に値が呼び戻される。 */ function getDeliciousNetwork(id, callback) { var url = 'http://del.icio.us/feeds/json/network/'

http://d.hatena.ne.jp/shinichitomita/20070520/1179659949 のつづき。 どうやらfollowersをとるのにはBASIC認証が要るらしいので、あくまでfriendsの情報のみからアクセスしているTwitter IDを「推測」してみるスクリプトを作ってみた。ある程度ネットワークに双方向関係があることが前提。あと全部のfriendsのfriendsをなめているので、ネットワークの数によっては判定までにかなり時間（＆ネットワークリクエスト負荷）がかかる。 http://www.geocities.jp/stormriders999/twitterid.html （追記） なんだ、ユーザIDはuser.timelineで取れるって(from bulkneets)。意味なかったか。 http://twitter.com/statuses/user

Pure JavaScriptで出来たTwittter Reader。 http://ss-o.net/twitterreader/ ああ、むかし似たようなことをdel.icio.usでやったなあと、そこまで思ったところで、表示されているのが自分のTwitter Friendsだということに気づいてぶっ飛んだ。 これは今まで知らなかったのだけど、どうやら以下のJSONPリクエストで、いまWebサイトにアクセスして来ている人のTwitter friendsが取得できるらしい http://twitter.com/statuses/friends.json?callback=onLoadTwitterFriends かなり画期的というか挑戦的な仕様。これってほとんどGmailのCSRFのときと同じだと思うんだけどなあ。 もともとめざしてるのがオープンなものであればそれでいいのか。でもどんなサイ

Ext JSで作ったアプリケーションのUIをブックマークレットで動的に読み込むサンプル。今見ているページに含まれているRSSを好みのUIで見ることが出来る。 以下のスクリプトをブックマークレットとしてブラウザに登録しておき、RSS情報を含む任意のサイトで起動する。 javascript:(function(){var s=document.createElement("script");s.type="text/javascript";s.src="http://stomita.sakura.ne.jp/lab/feedviewer/feed-viewer-bootstrap.js";document.body.appendChild(s);})()livedoor newsのサイトから起動してみた例。RSSのリストはRSS Autodiscoveryの情報から抜き出している。 ちなみにf

http://ajaxian.com/archives/subspace-enabling-trusted-cross-domain-ajax http://www2007.org/papers/paper801.pdf これ読んだときは単純に「へー、これでJSONPみたいなのを気軽にできるんだったらまあいい話なのかなあ」とか思ったんだけど、あくまでJavaScript読み込み元のページへの無制限リソースアクセスができちゃうのをSandboxにとどめるための手法ってだけなんで、たとえばブラクラみたいなコードをダウンロードしちゃったときはブラウザ全体でアウトになるから、やっぱそのレベルまで考えるんであれば使えないよなあ。 まあ言ってることの有用度はともかく、さまざまなクロスドメインコミュニケーションの手法とかが整理されていて、そういう意味でいい資料だとおもう。 とりあえずCross Doma

TwitterのJSONPがcallback変数名に「.」（ピリオド）を受け付けない。「[」「]」も。英数字およびアンダースコアのみ、っぽい。 http://www.twitter.com/statuses/user_timeline/3628361.json?callback=JsonWebServicesStub.responseCallbacks._0&count=1 なんとかしてくれないかなあ、こういう微妙な違い。。。常にグローバルにコールバック関数を直書きしろと言ってるのかしら？ dojoのScriptSrcIOをはじめ、JSONP対応のほとんどのライブラリはグローバルの汚染を嫌って独自オブジェクト内にコールバックを押し込めているので、まったく使えないです。 もし意味があってやってるなら、その意味を是非知りたい。

http://usrb.in/amachang/static/devsum/ 複数ユーザが 同ドメインを使い ユーザが JS を 自由に 記述出来る場合 要注意 プライベートな 部分はすべて 別ドメインにする ブログのように表示はパブリック、編集はプライベートと完全に分けられる場合は上手く行く。ブログパーツ貼り放題でも大丈夫。 SNSのように、表示にもアクセスコントロール必要性がある場合は、任意のJSのコンテンツを許すのはかなり工夫がいる。というかほとんど禁止している。 そういう状況を見る限り、このあたりの話というのは、結構その道の人にはあたりまえなのだろう。 でも、分野が変わると、もしかしたらそれほど浸透してないような気もする。 たとえばWebDAVをサポートしたドキュメント管理サーバがあって、そこでは複数ユーザやグループでドキュメントの共有・アクセスコントロールも可能で、さらにHTML

http://la.ma.la/opmlburner/ なんか、他人のフィードリストを読むという基本的なスキルが身に付いていなかった。なんでこの人のフィードを登録してなかったんだろう、というのが多くって、びっくりした。 とりあえず、６人以上を閾値に叩き込んで、Perl系が多いように感じたので、そこは後で解除する。 日本人のフィードが格段に増えた気がする。ちょっと偏るなあ。

まあ特にどうという話ではないです。またJSONPにしているだけです。 以前は避けていたコールバック関数名の文字制限も組み込んでます。Yahooと同じく [A-Za-z0-9_\.\[\]]+ で。 XMLからJSONへの変換はXSLTです。なので、サーバがningという都合上PHPでやってますが、汎用性はあるはずです。 これでサンプルコードが作りやすくなりました。早く正式にサポートしてくれるとうれしいなあ。 HotPepper グルメサーチAPI http://recruit2json.ning.com/hotpepper/GourmetSearch?key=guest&Latitude=35.660818&Longitude=139.775426&Range=3&callback=handleResult →テスト 店名サーチAPI http://recruit2json.ning.co

PlaceEngineという無線LANから位置情報を得るサービスなんだけれども、このサービス、WiFiから得た位置情報にJavaScriptのAPIでアクセスできるようになっている。 Firefoxからも楽勝でアクセスできるのできっとActiveXなんかではないだろうという思い、どういう仕組みになっているかを解析してみた。 まず、あらかじめPCにPlaceEngineのクライアントをインストールしておく必要があるのだけど、これが簡易Webサーバとしてサービスしている形になっている。このあたりはなんとなくGoogleデスクトップ検索の結果がGoogle検索に埋め込まれる場合とちょっと近い。 で、localhostに対してクロスドメインでそのWebサーバに対してスクリプト要求をすることで、WiFi関連のデータをとってくることができる。情報はコールバック関数の引数として渡される。 位置情報リクエ

Mashup Engineの中で今のところイケてたのはDapperとPlaggerだとおもってました。 今度出てきたPipesには民主化に対する強い思想があるような気がします。 GUIで敷居を低くし、Runtime EngineもConfigurationもすべてShareさせて級数爆発させよう、というような。ある意味王道です。 PlaggerではConfigurationはYAMLでShare可能にして、Runtime Engineはローカルで、という現実的な選択がありました。 EngineをSaaSするにはあまりにも初期コストがかかるし、直に触れなくなることのデメリットがGeekの興味をそぐ可能性があるためでしょうか。 今、隠れプロジェクトで、JSONPベースのPipesともいうべきものを作ってます。 UIが苦手なので、まだEngineのみの実装で苦戦してましたが、Pipesはちょっと

GMailのコンタクトリスト漏洩のエントリのついでに。 JSONデータをscriptタグにのせて配信するサービス（JSONPなど）で、限られたサイトのみにしかそのデータを配信しないようにするためには、クライアントが送出してくるリファラ情報を使ってサービスコンシューマとなっているサイトを特定してアクセス制御する方法がある。 この方法はおそらく大部分のクライアント（ブラウザ）に対しては有効で、例えば実際にGoogle MapsなどもそれとAppKeyを組み合わせてサイトを判別しているっぽいのだけど、意図的にリファラ送出を切っているブラウザであったり、あるいはプロキシプログラムなどが自動的にリファラヘッダを除去してしまうようなクライアント環境に対しては無効になってしまう。 ということで、そんなクライアントでもなんとかならないだろうかと考えていたときにちょっと思いついた、もしかしたらこの方法なら許