BaaS (Backend as a Service) について - snippets from shinichitomita’s journal
正直またXaaSかよ、って感じでしょうが、SaaSとかPaaSとかに比べてまだそれほど流行ってはいないのかもしれないけど、スマフォがこれだけ普及してくると、それに特化した形態としてこのレイヤーでのサービスの切断もあり得る、ということらしいです。 モバイル向けの新クラウド、BaaS（Backend as a Service）とは何か。「Parse」が正式サービス開始 － Publickey BaaSって何か新しいの？ 取り組みとしては、2006年ごろの初期型PaaSや一部のDaaS (Database as a Service) にもアーキテクチャ的に似たのがあったような記憶があります。しかしながら、これらが理念先行型ニーズ模索中だったのに対し、今回のBaaSはすでにアピールするべき確固たる市場（＝スマフォアプリ開発者）があるのがやはり異なります。 ちなみに、この時代(2006-2008年)
Google Apps Script を試す - snippets from shinichitomita’s journal
I/Oでの目玉って、ほんとはWaveなんかよりこれでしょ。Waveが流行るの待ってたら少なくとも１年以上かかるでしょ。ぼくは今すぐそこにあるものが大好きです。 案外はやくうちのApps(Standard Edition)でも有効にしてくれました。これだけのためにPremierでもいい、とおもったくらい。 Hello World的なもの コード function hello() { Browser.msgBox("Hello, World"); } 結果 入力プロンプト 次は入力プロンプトを出してみる コード function helloWithPrompt() { var name = Browser.inputBox("Enter your name"); Browser.msgBox("Hello, "+name); } 結果 単純なんだけど、これ、サーバサイドJavaScriptです
AppEngine有料オプションがCPU課金であるということの重要性 - snippets from shinichitomita’s journal
さらに、肝心の価格。思ったより高かったというのが正直なところだ。 GoogleAppsにおいて価格破壊戦略をとってきたGoogleが、Amazonとほぼ競合する価格を設定している。 価格を同レベルに設定するということは、Amazonに比較して明らかに差別化された何かがあると考えていると とらえるのが普通だろうが、マイクロソフトへの牽制のつもりなのだろうか。 いずれにせよ、これでクラウドの中でPaaSと呼ばれるレイヤーは、ほぼ業界標準価格が決まったといってよい。 クラウド前哨戦会敵ミッション "Azure ready for release by end of year"：Azureの鼓動：オルタナティブ・ブログ AmazonとGoogleでは時間単位の課金でも意味が違うのではないか、と思う。Amazonが起動時間をベースにしているのに対し、Google AppEngineはCPU時間。 A
window.nameによるクロスドメインXMLHttpRequestを実装してみる - snippets from shinichitomita’s journal
前回のつづき。 さて、大体 window.name によるクロスドメイン通信がどんなものかで、dojo のwindowNameモジュールがどんなことやってるかはわかった。個人的にdojoはすばらしいことをやっていると思うが、これだけのために常にdojoを使う気にはならない。ので、可能な限りポータブルなライブラリを実際に自分で実装してみることにする。 実装前におさえておきたい前提 クロスドメインでリクエストを送るためには、ターゲットとなるリソースが配置されているサーバの同一ドメイン上に、プロキシの役割を担うHTMLファイルがあらかじめ配置可能である必要がある。これはFlashで例えればcrossdomain.xmlのようなもので、リソース側がクロスドメインのリクエストをオプトインしている、と考えればよい。さらにポリシーを記述することができるという点でもよく似ている（これは後述）。 何らかの静
window.nameによるクロスドメイン通信 - snippets from shinichitomita’s journal
随分前になるが、SitePenの人 (dojo) が書いたブログに window.nameを使ったクロスドメイン通信についてまとめられていた。 window.name Transport - Blog | SitePen 気になっていたがちゃんと読む時間がなかったので、今ごろ見てみる。抜粋して訳。 window.name による通信 The window.name transport is a new technique for secure cross-domain browser based data transfer, and can be utilized for creating secure mashups with untrusted sources. window.name is implemented in Dojo in the new dojox.io.windowN
重み付きシャッフルの回答案 - snippets from shinichitomita’s journal
前回の続き。 問題：配列の中のある要素aに対してWaの重みが付いている。このとき、要素aが要素bより先に来る確率がWa/(Wa+Wb)となるようにシャッフルするにはどうすればよいか？ # 2007年08月28日 brazil brazil 1, TEMP, JAVASCRIPT, PROGRAMMING 最後の方法じゃだめなんだ...、ランダム はてなブックマーク - 重み付けシャッフル、再び - snippets from shinichitomita’s journal ランダムにそのまま重みを掛けた値でのソートだとだめなのは、絵を描いてみるとわかりそう。 PaとPbがそれぞれaおよびbの方が大きくなるエリアだけど、面積比はあきらかにWa:Wbじゃない。 まあその後色々考えて、多分これならそれっぽくシャッフルされるかな、というのを思いついたのだけど、どんなもんか。 var arr =
NextDB.netを触ってみた - snippets from shinichitomita’s journal
Ajaxianでちょろっと紹介されていたNextDB.netが、いろんな意味で、おもしろい。 NextDB.net is a revolutionary hosted database that lets AJAX applications leverage the full power of data-driven programming. In the past, creating a scalable data-driven website required knowledge of SQL and backend programming-- not anymore. Creating a powerful relational database is now as simple as logging into your NextDB account and using intuit
snippets from shinichitomita’s journal - AOL WebAIM APIを注目すべき５つの理由
AOL OpenAuthがすごいとか、JSONPによる認証だとか騒いでたけど、もう去年の１１月にAOL Web AIM APIが公開されていたということについて、なんで気づいてなかったのか。一年近くもこれを正当に評価してこなかったことは、恥ずべきことだ。 Web AIM APIは、以下の理由で画期的、あるいはちょっとネガティブな側から見れば問題児なAPIである。そして、これからWebサービスAPIを設計／開発する人、およびWebのセキュリティを考える人にとっては、少なくとも現在こういったWebサービスの実装が存在していることについては、ちゃんと注視しておかなければならない。 1. サーバレスでメッセンジャーアプリを構築できる これがとりあず一番目に重要なポイント。これはAPIリクエストとしてJSONP形式のバインディング(運搬方法)を採用していることによる。サーバレスでアプリが作れることの
ASP型のサービスのスケーラビリティについて - snippets from shinichitomita’s journal
直接会って名刺渡したりしてご存知の方は知ってるかもしれないですけど、あえてdiscloseすると、自分はsalesforce.comというところで現在働いております。関係者になってしまってからは、このブログでそのことについて書くのは当初のスタンスからあまりよくないと思ってたので書きませんでしたが、最近ちょっとやっぱり書きたくなったので書きます。 以下これはASPのアーキテクチャの話です。アーキテクチャに関する限り、SaaSとかASPとか、どうでもいい。 多分だいたいのCGM系サイトが、たくさんユーザを集めたときにスケーラビリティを出すのに苦心されていると思います。そういう場合、あるレベルに達すると必ずデータベース側のアーキテクチャを考えることになり、おそらくアプリケーション・パーティショニング的なことをしていると思うのですが、アプリケーション・パーティショニングができるのって、アプリケーシ
Ext JSのUIをブックマークレットで読み込み - snippets from shinichitomita’s journal
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
Pipesチュートリアル、はてな回答全文フィード - snippets from shinichitomita’s journal
先週はPipesのフィードのURLが変更になってたり、そのせいか何か知らんけどRSS2JSONPが上手いこと動かなかったりで、プレゼンを前に散々だったのですが、いつの間にかいろいろ機能が拡充されていたらしい。ぱっと見で新しいところとして、For Eachのところで他のPipesを呼び出せるようになってる。 で、以前はできなかった（たぶん） http://la.ma.la/blog/diary_200703030352.htm みたいなことも実装できるようになってたりする。 http://pipes.yahoo.com/pipes/pipe.info?id=hamster009&_id=bNVikK3b2xGMwJlMYEsBXw&_run=1 ネタに対してまじめにやったのもばからしいけど、まあチュートリアルとしても悪くはないと思います。
PipesのJSONP - snippets from shinichitomita’s journal
http://www.popxpop.com/archives/2007/02/yahoo_pipesbadger.html http://kentbrewster.com/badger/ なんだ、JSONだけじゃなくってJSONPもいけるんじゃん。いいぞいいぞ。 Yahoo Pipes http://pipes.yahoo.com/pipes/zIQi0Iy72xGJ3NMhJhOy0Q/run?_render=json&s=http://d.hatena.ne.jp/shinichitomita/rss&_callback=handleFeeds→テスト つまり、RSS2JSONPサービスとしても使えるってことだ。いままでにもそういうサービスはあったけど、ほとんど個人が好意でやってるものだった。非個人がサービスしているということ、しかもYahooという企業の信用レベルを考えればこれはす
クロスドメインでのデータ読み込みを防止するJavaScript ? - snippets from shinichitomita’s journal
GMailのコンタクトリスト漏洩のエントリのついでに。 JSONデータをscriptタグにのせて配信するサービス（JSONPなど）で、限られたサイトのみにしかそのデータを配信しないようにするためには、クライアントが送出してくるリファラ情報を使ってサービスコンシューマとなっているサイトを特定してアクセス制御する方法がある。 この方法はおそらく大部分のクライアント（ブラウザ）に対しては有効で、例えば実際にGoogle MapsなどもそれとAppKeyを組み合わせてサイトを判別しているっぽいのだけど、意図的にリファラ送出を切っているブラウザであったり、あるいはプロキシプログラムなどが自動的にリファラヘッダを除去してしまうようなクライアント環境に対しては無効になってしまう。 ということで、そんなクライアントでもなんとかならないだろうかと考えていたときにちょっと思いついた、もしかしたらこの方法なら許
パーソナルデータのmashupとクロスドメインJSONのセキュリティ（１） - snippets from shinichitomita’s journal
もし誰かが自分の持っているデータをWebサービスとして公開したいとき、その形式はXMLになるのが今のところ主流だけれども、JSON形式で配信できるように*1しておくと、mashupする側は自前のサーバを用意することなくとも、異なるドメインからデータを利用することができる。この詳細についてはすでにいろいろ書いているので省略する。 これはmashupの可能性を飛躍的に拡大させると言えるのだけど、実はもっと重要なことがある。それはこの場合mashupするデータの伝送がユーザを中心に行われているということだ。 もちろん、よく言われる本当の意味での「ユーザ中心(user-centric)」は、ユーザが自分に関するデータ（パーソナルデータ≒identity）の利用を全て選択しコントロールできる、ということだろう。その意味ではべつにデータの送受信がユーザを経由しようがサーバ間で行われようが「ユーザ中心」
関数名固定のコールバックをJSONPと言うことについて - snippets from shinichitomita’s journal
http://jsonp.yatena.com/ 実際のJSONPデータをご覧頂ければわかりますが、callbackの関数名はkakaku_wsとなっております。 http://blog.livedoor.jp/dankogai/archives/50639200.html 送られてくるjsonpはこんな風になっています。 parse_yubin2jsonp('東京都','千代田区','千代田'); いや、そもそも現在主流のJSONPの解釈自体が提唱者の元々の定義からぶれているので、定義にこだわるつもりはあんまりない。 ただ、「xxxがJSONP対応したよ！」っていわれて、じゃあ試してみようと思ったら、自前のクライアントライブラリが使えなかったときというのがとても悲しい。自分でスクリプトタグをコードに書けばいいんだろうし、ページに結果を貼り付けるだけの小さな用途であればそれで十分なんだろう
dojoのIFrameProxyでクロスドメインでのXML取得 - snippets from shinichitomita’s journal
これおもしろいな。 http://dojotoolkit.org/~jburke/XHRIFrameProxy.html XMLHttpRequestがドメインの壁を越えられないのは悲しい事実。すべてのブラウザで改善されるのを待つのはひどく気の長い話だし、そもそもそうなってるのにはそれなりの理由（セキュリティ関連）があったわけで、うまく要求が通るとも思えない。 そこで、既存の枠組みでクロスドメインの壁を越えられる動的スクリプトロードでのJSONコールみたいなテクニックが出てきてるわけだけど、データソースとなるサーバ側でデータをJSON形式で用意しなきゃいけなかったり、結局JavaScriptロードに頼るので信頼できないサイトからは気軽にデータを取って来れない（⇒任意のJavaScriptコードが実行されてしまう危険性がある）などの問題があった。 IframeProxyはこれを回避する。IF
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
