GPLとJavaScriptとWeb Loophole - snippets from shinichitomita’s journal
標題について、あいまいだったけど、最近さらに混乱してきたので、人力検索にでも聞くべきか、とおもって調べたら、こんなのがあった。 http://q.hatena.ne.jp/1210679294 GPLライセンスについて質問です。 あるGPLライセンスの"JavaScriptライブラリ"を使ってASPサービスを作成しようと考えています。 この場合、「組み込んだシステム」としてサーバサイドのシステムのソースの公開義務は発生するのでしょうか？ それともJavaScriptライブラリはソースの公開を実現しているのでサーバサイドのシステムのソースは関係ないのでしょうか？ だが、今回疑問に思ったのはこれとは違う。サーバサイドが公開義務がないのはまあいいとして、クライアントでライブラリとして利用するJavaScriptはどうするの、という話を聞きたい。なので投げるとしたらこう。 オープンソースライセンス
iOS6でメガピクセル画像をCanvasに描画するとおかしくなってしまう件と、その対処 - snippets from shinichitomita’s journal
iOS6によるアップデート まず最初に、iOS6において、Safari上のWebアプリから簡単にカメラ＆フォトライブラリの写真にアクセスできるようになりました。いままでカメラにアクセスするにはPhoneGapなり何なりでネイティブ化する必要があったので、写真共有サービスなどにはかなり有用なアップデートです。 File API、HTML Media Capture への対応 HTML Media Capture に対応し、Safari から カメラを起動してのファイルアップロードが可能になりました。 type 属性値に file を指定すれば単体ファイルのアップロードが簡単に。 （略） ファイルを選択したあとは何ができるか... action による Multipart post Ajax （XMLHttpRequest 2） を使用したファイル送信（プログレス表示にも対応） File AP
シングルログアウト - snippets from shinichitomita’s journal
ブラウザを落とせ？いやいや、persistent cookieもあるしね。 シングルログアウトは、一見必要性が感じられないことも多いけど、もしペルソナっぽくアイデンティティ切り替えをしようとするなら、価値があるな、と思う。 クロスドメインにおいて他のシステムとの依存性が低まったのは良いのですが、横断的かつ同時性の高いシングルログアウトは非常に設計しにくい。 認証サーバからログアウトメッセージを配布する必要があり、関連システムが１０００個と増えた場合を想定すると処理コストが馬鹿にならなくなる。 やむにやまれず : クロスドメインシングルログアウトの難しさはスケーラビリティにある（＆生きてます報告） 画像ファイルイメージによるログアウト。サーバ側でセッションを消し込むのじゃなくてクライアントからログアウトリクエストをimg srcに記して各サービスに送る。確かSAMLにもあったし、古典的な手法
Heroku上でスクリーンショットサーバを動かす - snippets from shinichitomita’s journal
前回、PhantomJSのbuildpackを作成したので、Heroku上でPhantomJSのプロセスを自由に稼働させることができるようになった。 PhantomJSはGUI環境のない(Headless) WebKitブラウザであるため、ブラウザ上のJavaScriptの単体テストor結合テストをサーバ上で走らせて、継続的インテグレーションに組み込むなどの利用方法もあるだろう。これも興味深いトピックではあるけど、ここでは触れない。 今回はPhantomJSの画面レンダリングの機能を使って、スクリーンショットサーバをHeroku上に構築する。 構成と処理フロー PhantomJSにはwebサーバ機能も含まれており、単独でHTTPサーバとしてリクエストを受け取る事もできるが、実サービスで利用するようなシロモノではない。そのためクライアントからリクエストを受け取るNode.jsのサーバを別に立
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年)
SAMLについて自由勝手に紹介 - snippets from shinichitomita’s journal
宿題をid:ZIGOROuさんから課せられたので、早めにやっつけで片付けます。でも入門、というのとはちょっとちがうだろうな。今回は、SAMLを知っている人には当たり前の話でも、知らない人はきっとわからないだろうことを補足するだけです。しかもとみたの主観的におもしろいと思ってるところだけ。 そもそも僕自身の能力的な話で、Libertyの時代も仕様は気になったところしか読んでないので、網羅的に書くのは正直つらいし、割に合わないと感じてます。ただ、今回はきっとtkudoさんが添削してくれるはずなので、かなりのびのびと書いちゃいます。 歴史のおさらい まず間違え易い点として、SAML1.0とか1.1ってのは、SAMLが出たてのときの仕様なので、いまの話(v2.0)と結構違う。結構SAMLで検索するとこのころの話が引っかかったりする。むしろ今のSAML 2.0を調べようとしたらLiberty ID-
なぜiOSでUDIDが必要とされていたのか、メモ - snippets from shinichitomita’s journal
iOSやその開発事情に詳しいと言える状態にはないので、調査を兼ねて書く。 Apple Sneaks A Big Change Into iOS 5: Phasing Out Developer Access To The UDID – TechCrunch http://wirelesswire.jp/Watching_World/201108221335.html 上記の「iOSでUDIDの利用が禁止」というニュースを聞いた時、正直TL上にこんなにいっぱい反応が貼り出されるとは思っていなかった。さすがにUDIDをいじるのはまずいよね、っていうコンセンサスは開発者の間では常識的部類に入ってくるのだろうと楽観的に捉えていたのかもしれない。 以下、なぜUDIDがそのようにスマートフォン開発者に利用されてきたのかについて、調べた限りでまとめてみた。 アプリケーションのサーバとのセッション保持 い
OAuth 2.0 User-Agent Flowを使ってサーバレスでSalesforceにアクセスする - snippets from shinichitomita’s journal
もはや自分はブログほとんど更新しておらず、最近はゆるいことをTwitterでのみやってる感が強いですが、ネタ的にこれは自分が書いとくべきとおもったネタに関してはこのブログで書いておくことにしています。今回もそれです。 Salesforce の Winter '11 で、OAuth 2.0へ対応（Draft 10相当）されたわけだけど（OAuth 1.0a への対応はすでに去年の秋にしている）、この中にはUser-Agent Flowという方式への対応もなされている。これはJavaScriptやFlashなどのWebページ埋め込みのスクリプトからOAuth認証を受けるためのフロー。 つまり、これを利用すると、Facebook ConnectやTwitter @Anywhereなどと同じように、任意のWebページからSalesforceのAPIに対して直接、サーバの介在なしで接続できるようにな
3rd-party cookie について、Facebookの場合 - snippets from shinichitomita’s journal
昨日の Shibuya.js でmalaさんが話してたことの内に、3rd Party Cookie の是非があった。 USTREAM動画 http://www.ustream.tv/recorded/8605067 Shibuya.jsの第一部まとめ、みたいな感じのやつ Shibuya.js beyond HTML5 に参加してきます - 北海道苫小牧市出身の初老PGが書くブログ では3rd Party Cookieに対して、実際のサービスはどうなってるのか。はてなスター、はてブくらいだったら、正直世界的には影響ないかもしれない。ブラウザの実装はこれらサービスのことなどたぶん何も考えずに進化していく可能性が高いんではないかな（すいません）。 でもFacebook(FB)は違う。ユーザ規模が大きすぎる。Facebookが使えないと困るので、ブラウザの実装がそっち側に揺れる可能性は十分ある。ま
Twitter @Anywhere を斜め上に掘り下げる - snippets from shinichitomita’s journal
Twitter @AnywhereというDeveloper向けの新サービスが出てた。このサービス、この自分的にはいろいろな理由によりちゃんとチェックしておく必要がある。ので久々にブログ書く。 Facebook Connect (JavaScript) を知ってる人は、それがTwitterでもできるようになった、と思ったらいい。つまりサーバレスでTwitterに接続してAPIをJavaScriptから利用できるようになった。今でもJSONPである程度APIの利用はできたが、JSONPとは違い認証が必要な操作、例えば書き込み系の操作もOK（ただしversion 1のAPIでは許されている操作はそれほどない）。 詳しくはこちらの記事とかをどうぞ。 Twitter 新 API のドキュメント「Getting Started with @Anywhere」日本語訳 - WebOS Goodies さ
Google Friend Connect を使った OpenSocial Dashboard を作った - snippets from shinichitomita’s journal
Social Web #4 でなかじまんさんに動画まで作ってもらってリークされてたりしましたが、当初考えてた最低限の機能はそろったので、ブログにあげます。 Google Code Archive - Long-term storage for Google Code Project Hosting. ソースコードはこちら。 http://opensocial-dashboard.googlecode.com/svn/ デモンストレーションサイトもこちら。Google Code上で動いています。 http://opensocial-dashboard.googlecode.com/svn/trunk/index.html で、昨日MA5の会場でプレゼンしてきましたので、その資料もついでに。 OpenSocial Dashboard これを作った動機 見て分かるように、ガジェットコンテナの見栄
jQuery用 Live Clipboard プラグイン - snippets from shinichitomita’s journal
その昔（３年以上前）Microsoft がLive Clipboardというのを発表していた。これに対応したサイトでは、Webアプリのデータを構造化した状態でコピー＆ペーストしてアプリケーション間で持ち回ったり、クライアントソフトにコピーできたりする。なかなかおもしろかったが、その後どうなったのか知らない。なので思い出しついでにjQuery用のLive Clipboardもどきをつくった。 ソースコード http://code.google.com/p/liveclipboard-jquery/ サンプル http://liveclipboard-jquery.googlecode.com/svn/trunk/videosearch.html Google動画検索結果をマウスで選択し、右クリックメニューから検索結果をクリップボードにコピーできる。 スプレッドシートに Ctrl(MacではC
Salesforceのデータベース - snippets from shinichitomita’s journal
すごい良い記事。 知られざる「マルチテナントアーキテクチャ」（2）～スケーラビリティのカギは組織ID － Publickey 知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey 頼まなくてもこういう記事を書いてくれる人が増えている（頼まれてないっすよね？）のは、SFDCにとって、デベロッパーマーケティングとして成功だと思う。大事にしてくださいね。 スキーマについて 上記記事では、データベースの物理スキーマについて、公開情報をもとに分析されています。 掟破りのスキーマ セールスフォースのアプリケーションで扱われるすべての数字や文字のデータは、Dataテーブルに保存される。このことがセールスフォースのデータベーススキーマの核心です。 Dataテーブルはどんなデータでも受け入れられるよう、次のようなスキーマになっています。恐らく、データベースに詳し
OAuth CrossDomain JavaScript Proxy を作った - snippets from shinichitomita’s journal
サービス： http://xdoauthproxy.appspot.com/ ソースコード： http://xdoauthproxy.googlecode.com/ 何ができるか OAuth(3-legged)のAPIがJavaScriptクライアントから簡単に呼べるようになります。 プログラム的には非同期の呼び出しのみで記述でき、面倒な手続き（トークンのやり取り、同意画面の表示など）はプロキシ側で完了します。 プロキシサービスはGoogle App Engine上で動いてます。 コード例 http://xdoauthproxy.googlecode.com/svn/trunk/assets/example.html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/ht
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
