Google FriendConnect APIとFacebook Connectという変態たち - snippets from shinichitomita’s journal
遅ればせながら、Google FriendConnect がAPI出しましたね。Google FriendConnect本体がブログパーツ的にウェブに貼付けるものだったので、それ用のガジェット開発キットかなと思ってあつかうと、間違えますね。これ、ぜんぜんガジェット開発者だけの話ではないですよね。 早速えーじさんが記事を書いてます。 サービス提供者にとって，今回公開されたGFCの認証機構は魅力です。OpenIDを使ってすら複雑なサーバー実装を必要とした認証が，HTMLファイルとJavaScriptの設置だけで実現できるのです。認証機能を完全に外部にたよることで，Cookieのパラメータでログイン状態を判断し，さらにそれを認可にも用いることで，サービス提供者は開発の手間を劇的に減らすことができます。 http://gihyo.jp/dev/column/01/social/2009/03180
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
Facebook Connect をブログにセットアップする簡単チュートリアル動画 - snippets from shinichitomita’s journal
すばらしくわかりやすい。 HOW TO: Add Facebook Connect to Your Blog in 8 Minutes via How to Add Facebook Connect to Your Blog in 8 Minutes – Adweek HTMLにタグを書くだけでできる。この簡単さはヤバい（実際は JavaScript 書いてるところも結構あるけど、まあ無視）。 注意すべき点として、上記の作業だけでは実は何も認証になってない、ということ。なぜって、アイデンティティ情報の取得になにもサーバを絡ませてない（ブラウザ <=> Facebookのダイレクトクロスドメイン通信）ので、コメントのポストで送られてきた情報が正しいかどうかなんて検証のしようがない。なのでコメントをFacebookの友達だけに限定したい、とかいった用途に使える訳じゃない。あくまで名前入力を簡単
Google Visualization API が任意のデータソースに接続可能に - snippets from shinichitomita’s journal
Today, we are expanding the capabilities of the Google Visualization API by enabling developers to display data from any data source connected to the web (any database, Excel spreadsheet, etc.), not just from Google Spreadsheets. Official Google Blog: Visualizing data in the cloud まあ、Salesforceとの連携はともかく、問題はExcelもデータベースもありよ、と言ってしまったことだ。 共通のインターフェースを切ることで、任意のデータソースに接続可能にする（データソース側はここのインターフェースにあわせる必要
Salesforce, Google App Engineとユーザコードのホスティング - snippets from shinichitomita’s journal
こういう方が書いてくれると、僕も書き易い。今までは論じるにはあまりにマイナーすぎた。 salesforceのTour de Force Tokyo(-ツール・ド・フォース-)に行ってきました。 * http://www.salesforce.com/jp/events/crm-events/2008-07-03.jsp IBMには悪いですが、Notesの正統な後継者の一番手はsalesforceかもしれない、という思い — ありえるえりあ まず、最初におことわりしておくと、僕は去年までsalesforce.com Japanに在籍していました。で、今の仕事も多少関わってたりします。その上で以下お読みください。 「ページ」相当の機能は、facebookも同様の仕組みを提供しています(FBML)。これはこれで両者とも凄いのですが、salesforceが行っちゃったなと思うのがApexコードです
Database as a Serviceについて議論 - snippets from shinichitomita’s journal
この前、ひょんなことから、友人と「Database as a Service」というのはいったいなんなのか、という話になった。 巷を賑わせつつある、プラットフォームレイヤーのサービス化。それもデータの永続化というレイヤーにフォーカスしたサービス。具体的には、Amazon SimpleDB *1, Facebook DataStore, Salesforce Database (force.com Database) のそれぞれの違いはなんなのか、という話。 「サービスとして提供されるデータベース」の分類の仕方として、いろいろ着眼点はあるけれども、もっとも自分が面白いと思っている分類の仕方に、それがデータベースホスティングから由来しているのか、それともWebサービスAPIの拡張なのか、という観点がある。それぞれHosted Database 型とExtended Web Service型とし
Facebookが JavaScriptのAPI提供 - snippets from shinichitomita’s journal
いい。まだ試してないけど。 The Facebook JavaScript client library allows you to make Facebook API calls through JavaScript code from any Web site and makes it easy to create AJAX Facebook applications. Since the library does not require any server side code on your server, you can now create a Facebook application that can be hosted on any Web site that serves static HTML. http://wiki.developers.facebook.com/i
SAMLについて自由勝手に紹介 - snippets from shinichitomita’s journal
宿題をid:ZIGOROuさんから課せられたので、早めにやっつけで片付けます。でも入門、というのとはちょっとちがうだろうな。今回は、SAMLを知っている人には当たり前の話でも、知らない人はきっとわからないだろうことを補足するだけです。しかもとみたの主観的におもしろいと思ってるところだけ。 そもそも僕自身の能力的な話で、Libertyの時代も仕様は気になったところしか読んでないので、網羅的に書くのは正直つらいし、割に合わないと感じてます。ただ、今回はきっとtkudoさんが添削してくれるはずなので、かなりのびのびと書いちゃいます。 歴史のおさらい まず間違え易い点として、SAML1.0とか1.1ってのは、SAMLが出たてのときの仕様なので、いまの話(v2.0)と結構違う。結構SAMLで検索するとこのころの話が引っかかったりする。むしろ今のSAML 2.0を調べようとしたらLiberty ID-
アイデンティティ飲み会 - snippets from shinichitomita’s journal
これはレアすぎでした。 http://blogs.sun.com/tkudo/entry/identity_nomi_next_friday 話してたこと、覚えている事のみ。文脈とかごちゃまぜなので、解釈違ってたらすいません。 アイデンティティってわかりにくい。IDと同一だと思ってる人が多い。 ソーシャルブックマークサイトなどでブックマークされてるのをみると、あまりidentityタグって使われてない。なんでも「認証」って、おいおい（tkudo） 日本ではそもそも欧米に比べてアイデンティティという概念に関する関心が低い。宗教的なものもある？(nat) 何でも「アイデンティティ〜」って言っちゃう事で、逆に受け入れられにくくなってない？(stomita) どうやって一般の人にOpenIDのエクスペリエンスを受け入れられるようにするのか。(西村) URL入力させなくても、裏側でOpenIDが使わ
OpenSocialに関する妄想？ - snippets from shinichitomita’s journal
OpenSocialって、GDataのAPI必須なのかな？ いや、そりゃドキュメントに書いてあるってのはわかるんだけど。 なんでこんな馬鹿なことを言ってるかというと、Salesforce（地味にOpenSocialに参加表明している）に socialforce というSalesforce 上でOpenSocialを実装しているコードが転がっていて、最近これを眺めていたから。 知っている人は知ってるかもしれないけど、SalesforceのAPIって全部SOAPでできていて、そのSalesforceがOpenSocialに参加してるってことは、何、RESTのAPIだすの？って思ってしまうのだけど、まさかそんながっつり既存のインフラ運用に関わることをたかだか話題性のためにトップが承認するとも思えず、やるとしてもかなり後（OpenSocialの実効性を見極めてから）になるだろうと思っていた。 で、
OpenAuth, Google GData API JavaScript とプライベートデータのクライアントサイドマッシュアップについて - snippets from shinichitomita’s journal
なんかいろいろと書きたくなってきたので書きます。長文失礼。 AOL OpenAuth のように、iframe でメールアドレスを選択させて、その結果を親フレームに返すようにすべきだと思いました 上の続き - kazuhoのメモ置き場 なるほど。クライアント側でのマッシュアップで Service Provider → Consumer の流れなら IFRAME + HTTP Referfer を使った方が軽いということですね。 OpenAuth の仕組みは全然追っていなかったので、 id:shinichitomita さんのエントリをもう一度読んで勉強します。まず、そこから把握しないと議論にもならなそうですね。 クロスドメインのセキュリティ問題を OAuth で解決する, OAuth のアイデアに kazuho さんからツッコミをいただいた, それ OpenAuth で (ry - まちゅダ
クロスドメイン通信とアクセスコントロール - snippets from shinichitomita’s journal
とりあえず好きな分野なので、こういう話には飛びつくようにできている クロスドメインのセキュリティ問題を OAuth で解決する, OAuth のアイデアに kazuho さんからツッコミをいただいた, それ OpenAuth で (ry - まちゅダイアリー(2007-12-07) これがおそらく可能な実例としてはすでにあり（OAuthじゃないけども）、AOL WebAIM APIはJSONPにOpenAuthのセキュリティトークンを乗っけてクロスドメインで機密情報の通信してるし、Google GDataのJavaScript APIはGoogle Authのトークンを含めた形でカレンダーにRead/Writeなリクエストをクロスドメインで投げている（iframe越しのトリッキー通信）。いずれもトークンの受け渡しは各サービスとブラウザとの間でダイレクトに行い、サーバ要らずになっているところ
GData JavaScript のクロスドメイン通信の解析 - snippets from shinichitomita’s journal
以前の続き。JavaScriptからプライベートデータの参照、更新が出来る。Google Account Authenticationの仕組みを利用している。この前動かなかったサンプルはいつの間にか動くようになってた。 最初プロトコルは勝手にJSONPと思ってたけど、中身見てみたらIFRAME 使った fragment identifier (window.location.hashの値、URLの＃以降)による通信だった。たしかに、IEで音をONにしたらクリック音カチカチする。ちなみにfragment identifierによるクロスドメイン通信は他にdojoがライブラリとして実装しているのは知っているけど、これだけ大々的にサービスで使われてるのを見たのは初めて。もっとも、ブラウザでクロスドメイン通信を達成する方法のうち現時点でもっともマシなのはこれじゃないかという意見もある。 解析してみ
Afrous Beta 公開 - snippets from shinichitomita’s journal
マイルストーンとして９月中にベータ公開だったので、あわててなんとか作りました。パブリッシュ以外の基本機能はそろっています。 http://www.afrous.com/ 日本人が作ってるのに英語の説明しかないです。このブログをご覧の皆さんのお知り合いのギークな外人に紹介していただけると幸いです。 あ、あと、発音はアフロス、あるいはアフラスみたいです。この前ネイティブに発音させてみたらそう言ってましたので。もはや言葉にあまり意味はありません。名前空間でぶつかることはほぼないでしょう。アフロヘアのキャラクタのロゴを考えてましたが、自重しました。 とりあえずこちらに日本語の説明を若干おいておきます。 Afrousについて Afrous は JavaScript 上に作られたマッシュアップエンジンです。Webブラウザ上ですべて動作しますので、ソフトウェアのインストールおよびサーバの用意は要りません
Google Calendar Data API - snippets from shinichitomita’s journal
プライベートカレンダーにもJavaScriptからアクセスできるようになった http://googledataapis.blogspot.com/2007/09/calendar-mashups-anyone.html Calendar API | Google Developers しかしこのサンプルがまったく動かん！だれか動いてる環境の人いないの？ http://gdata-javascript-client.googlecode.com/svn/trunk/samples/calendar/meeting_notes/meeting_notes.html この前のWeb AIMに続いて、自分の中では結構大ニュースなのに。これがちゃんとできてるのならば、Webってマジで変わるよ、などといってみる。もちろん、Googleのサービスだからということじゃなくって、そのアーキテクチャ自体
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形式のバインディング(運搬方法)を採用していることによる。サーバレスでアプリが作れることの
MIT SIMILE TimelineとGoogleカレンダー プライベートスケジュールのマッシュアップ - snippets from shinichitomita’s journal
MIT SIMILE Timelineというのがある。まあGoogle Mapsの時間軸版と言えばいいだろうか。表示される時間軸上にイベントをプロットでき、マウスでスクロールして自由に時間を行き来できる。 時間ベースの情報とのマッシュアップに最適なので、Googleカレンダーとのマッシュアップなんかきっともう誰かやってるのかなー、と思ってたのだけど、案外見つからない。単にあまり気合いれて探してないからかも。 じゃあそれなら、と思って、この前のGoogleカレンダープライベートフィードのJSONPプロキシサービスを、これとくっつけてみた。 http://www.geocities.jp/stormriders999/timeline.html スクリーンショット ちなみにカレンダーとのマッシュアップ、パブリックなカレンダーなら別に普通だよね。プライベートってところが重要なつもりなんだけど、あ
Afrousその後 - snippets from shinichitomita’s journal
Afrous - Ajax for the rest of us 以前にも紹介したことがあるAfrousがどんどんパワーアップしているので再度ご紹介したい。AfrosはYahoo pipes同様に各種Web APIを簡単に組み合わせる事ができるサービスだ。なお、現状ではデータを保存することはできない。 Yahoo! Web Search、del.icio.usといったWeb APIや、RSS等からデータを取得し、それを加工（並び替えなど）すると言った操作が容易にできる。パラメータを与えることもでき、非常に柔軟なシステムになっている。 http://www.mashupedia.jp/docs/view/38 紹介ありがとうございます！でも、本気公開はもうちょっとまってくださいね。結構バグ多いので。。。 とりあえず、今の段階でなにができるか、スクリーンキャストをとったもの。 http://w
Mashup Award 3rdのサービス、JSONP - snippets from shinichitomita’s journal
そういえば、関係者です。APIのうち、 JSONPに対応してるもののリスト 赤すぐnet Webサービス http://webservice.recruit.co.jp/akasugu/ →テスト エイビーロードWebサービス http://webservice.recruit.co.jp/ab-road/ →テスト カーセンサー・ラボWebサービス http://www.carsensorlab.net/webservice/files/webapidoc_ver2.1.pdf →テスト (注意：JSONP callbackパラメータに指定できる文字が通常より狭い) ホットペッパーBeauty Webサービス http://webservice.recruit.co.jp/beauty/ →テスト リクルート進学ネットWebサービス http://webservice.recruit.c
livedoor メールにGmail採用 - snippets from shinichitomita’s journal
http://www.itmedia.co.jp/news/articles/0707/24/news041.html このニュースが面白いのは、これでlivedoor IDは３つの認証仕様のIdP（アイデンティティ・プロバイダ）になった、ってとこだな。 livedoor Auth OpenID SAML2.0（aka. Liberty ID-FF） SAMLのインターフェースについては、”Circle of Trust”という性質上、OpenIDのように市井の開発者が勝手に使えるような感じでは多分ない。基本的に一方向じゃなくって双方向の信頼を求められるから。まあここらへんへのアンチテーゼであのDick Hardtの名プレゼンが出て来たわけだけども。 でもSAMLは、比較的大きなサービサー同士とか、エンタープライズとの連携では、そうした用途で古くから仕様が練られていることもあり、おそらく使
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
