スマフォのリワード広告におけるUDIDに依存しない設計案 - snippets from shinichitomita’s journal
前回のまとめ 前エントリで触れたとおり、スマートフォンのUDIDの問題点というのは、自分の把握する限り３つあった。 1. サーバとのセッションを管理するための認証に使われてしまっている 2. アプリケーションをまたがっての行動トラッキングに使われてしまっている 3. スマフォにおけるリワード広告がUDIDが取れることに依存した実装になっている。 このうち、1. に関しては代替案があり、ほぼ既存のユーザビリティを損なわない形に実装できるものなので、単に実装側の怠慢か知識不足に帰結されると感じている。今の時点でこれほど安易に使われてしまっているのは残念なことではあるかもしれないが、今後改善できる余地がある。 2. に関しては、実はデバイス固有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がそのようにスマートフォン開発者に利用されてきたのかについて、調べた限りでまとめてみた。 アプリケーションのサーバとのセッション保持 い
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
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です
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
http://hail2u.net/blog/coding/synchronous-requests-to-jsonp.html forループなら並列リクエストでも工夫次第でできると思うけど、前後的な依存関係が各リクエストにある場合は、やっぱり直列処理をしなければいけない。 2、3段くらいの直列処理ならコールバック関数を連鎖させて書いたり、インラインで無名関数指定したりしても困らないと思うけど、もっと多段階の直列処理をコールバック関数名の指定だけで記述しようとすると、コードを書く人でも頭の中にちゃんとフローのイメージが出来上がってないと厳しいし、コードを読む側はもっとこんがらがることになる。 たとえば del.icio.usからnetwork情報をJSONPで取得(http://del.icio.us/feeds/json/network/stomita) del.icio.usからfan
Webアプリケーションのマッシュアップおよびクロスドメイン通信のアーキテクチャ、分類 - snippets from shinichitomita’s journal
あらかじめ、結構勝手な観点から語った内容なので、その辺ご容赦ください。 Webアプリケーションのマッシュアップおよびクロスドメイン通信のアーキテクチャについて、一度文章として整理してみたほうがよいかなと思ったので、まとめてみる。まず前提として、この議論における主体は３種類に分類されている。*1 マッシュアップWebアプリケーション Webサービスプロバイダの提供するデータを利用したサービスを提供する主体。 Webサービスプロバイダ 元となるデータをWeb経由で配信するサービス主体。マッシュアップWebアプリとは異なるサイト（ドメイン）で提供されるものとする。 ユーザ 実際にWebブラウザを開いて上記のサービスを利用する主体。 マッシュアップ実現のためには、このうちのどれか１つがクロスドメイン通信に協力的である必要がある。 以下、それぞれの場合について詳細および利点／欠点を挙げる。 マッシュ
IFrameとFragment Identifier使ったクロスドメイン通信について - snippets from shinichitomita’s journal
なぜかちょっと盛り上がり気味な記事 XhrIframeProxy(dojo) ○？ ○ △？ 中？ マウスクリック音有り iframe内iframe ○？ ○ △？ 中？ マウスクリック音有り http://d.hatena.ne.jp/nopnop/20080408/1207669947 この２つはFragment Identifierと多重IFrameを利用しているという点では同じなのかなあ。 正直、これらは何を内部でおこなっているか分かりにくいと思う。JSONPのような簡潔さはない。 説明を試みてみる。理解するためにまず押さえておくことがいくつかある。 まずひとつ目に、フレーム（ウィンドウ）に含まれるドキュメントを示す location の値はそのフレーム外部から書き換えることができる。こんなかんじ。 <iframe id="ifr" src="http://www.example.
ASP型のサービスのスケーラビリティについて - snippets from shinichitomita’s journal
直接会って名刺渡したりしてご存知の方は知ってるかもしれないですけど、あえてdiscloseすると、自分はsalesforce.comというところで現在働いております。関係者になってしまってからは、このブログでそのことについて書くのは当初のスタンスからあまりよくないと思ってたので書きませんでしたが、最近ちょっとやっぱり書きたくなったので書きます。 以下これはASPのアーキテクチャの話です。アーキテクチャに関する限り、SaaSとかASPとか、どうでもいい。 多分だいたいのCGM系サイトが、たくさんユーザを集めたときにスケーラビリティを出すのに苦心されていると思います。そういう場合、あるレベルに達すると必ずデータベース側のアーキテクチャを考えることになり、おそらくアプリケーション・パーティショニング的なことをしていると思うのですが、アプリケーション・パーティショニングができるのって、アプリケーシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
