Web ComponentsのWebブラウザ別動作を調べてみた
Web Componentsでは、標準技術として幅広いWebブラウザで利用可能とすべく、Polyfillという名の「未対応Webブラウザ向け実装」が開発され、すでに利用可能です。このPolyfillを使うことで、Chromeだけでなく、Firefox、Opera、そしてIEでもWeb Componentsを動作させることができます。 では、実際どこまでPolyfillでWeb Componentsが動作するのでしょうか？Polyfillとして適用するのは、もちろん platform.jsです。これを使って、複数のWebブラウザで動作検証をちょっとしてみようと思います。試してみたのは、以下の3つです。 基本的なWeb Componentsの動作確認 HTMLElement#createShadowRoot()の動作確認 Shadow DOMのCSSスコープ それぞれ見ていきましょう。 基本的
Chromeウェブストアにて段階的にユーザを増やせる機能が追加されました
Chrome拡張機能を久々にバージョンアップしようとして、Chromeデベロッパーダッシュボードに行ってみると、何やら新しい機能を発見！それは、 「段階的に新しいバージョンの利用ユーザを増やしていける機能」 です。Chrome拡張機能のzipファイルをアップロードすると、以下のようなUIが出てくるようになりました。 つまり、ここで入力した割合で限定されたユーザ数にのみ、このバージョンを利用してもらうということが可能になります。例えば、新しい機能の評判を徐々に見ていくとか、新しい機能によるサーバ側の負荷の影響を観察しながらリリースする、といったことができるでしょう。 既に多くのユーザを抱えているChrome拡張機能であれば、これは開発者にとって嬉しい機能です。ぜひ活用しましょう！ Tweet 関連記事 2023年のRemap Remapにファームウェアビルド機能を追加しました Google
Chrome拡張機能におけるエコ対策（Event pageへの移行方法）
いくつかChrome拡張機能を作ってChromeウェブストアに公開しているのですが、それを最初に公開したときはmanifest.jsonファイルのバージョンがまだ最初の頃でした。現在ではバージョン2が主流であり、そろそろ古いバージョンの拡張機能は撲滅される予定になっています。そのため、開発者はそろそろ急いで新しいバージョンに変更すべく、せっせと移行作業を進めなければなりません。これは何もGoogleの開発者いじめではなく、ちゃんとした理由があります。その理由は、どれも開発者およびユーザへのメリットがあるものばかりです。 このバージョンアップの中で、ユーザにとって大きなメリットとなるものがあります。それは「Event pageへの移行」です。Chromeはメモリを非常に大きく消費することで有名ですが、拡張機能がメモリを大きく使ってしまうことも問題視されていました。拡張機能は「常駐して機能する
僕が考えたChrome拡張機能を作るときのデザインパターン
最近いくつかのChrome拡張機能を作っていて、すでに数千人のユーザを獲得できているものが出てきてたりします。 Image collector extension goo.gl URL Shortener extension mixi Check button extension Semantic inspector これだけ作ってると、何となく自分でのChrome拡張機能を作り出す際のデザインパターン・・・っていう大それたものじゃないけど、ようはテンプレが確立されてきます。全く褒められない書き方をしているかもしれませんが、ここでそのテンプレ達を晒しておこうかな、と思います。 manifest.json まずはChrome拡張機能の要であるマニフェストファイルです。これは誰が書いてもさほど変わらない記述内容となるでしょう。 { "manifest_version": 2, "name":
続：Web IntentsとSchema.orgの連携が模索され始めています
続：Web IntentsとSchema.orgの連携が模索され始めています Written on Jul 13, 2012. Posted in Web IntentsSemantic Web 13日に「 Web IntentsとSchema.orgの連携が模索され始めています」というエントリを投稿したんですが、実は原文の表現がそもそもわかりにくく、僕の日本語訳レベルの低さにより、「で、結局なんなのよ」と感じた人が少なくないのかな、と反省しております(そういう声を実際に目にした訳じゃないけど、きっとそうかなと)。 なので、結局何がしたいか、を改めてここで紹介したいと思います。 Web Intentsは「○○したいから誰かその願い叶えて！」とクライアントが投げると、それを実現することができるサービスの一覧がユーザに提示され、あるサービスを選択するとそれが起動して○○を実際に行い、その結果を
Web IntentsとSchema.orgの連携が模索され始めています
Web IntentsとSchema.orgの連携が模索され始めています Written on Jul 13, 2012. Posted in Web IntentsSemantic Web Web Intentsは、Webアプリケーション間の連携を可能とする技術となりますが、そこで規定されていることの中心は「ユーザが何をしたいか」についてです。つまり「共有したい」「編集したい」「保存したい」といった行為に関することであり、「何を」という部分については、そのペイロードの部分の規定はあれど、厳密な説明は仕様に書かれていません。それは当たり前であり、Web Intentsの守備範囲外ということになりますが、では「何を」の部分が実際にどのように規定されるかについて、Schema.orgがその答えになるのではないか、という記事が semanticweb.comに投稿されていましたので、翻訳してみま
Google OAuth2 Web Server Profileでのリフレッシュトークン
久々にGoogleのOAuth 2.0のWeb Server Profileを使っていて、あれ？って思ったので、ここでメモ代わりに書いておきます。 基本的には、以下のブログエントリで語られている話です。 Upcoming changes to OAuth 2.0 endpoint - The official Google Code blog OAuth 2.0でのWeb Server Profileのセオリーでは、以下の手順が踏まれます。 Client IDとScopeを指定して認可画面を要求します。 ユーザは認可画面を見て、許可するか拒否するか選択します。 redirect_uriにリダイレクトされ、その際にauthorization_codeが渡されます。 authorization_codeと引き替えに、access_tokenとrefresh_tokenを取得します。 acces
「OpenSocial 3.0 Summit 議事録」から読み取れる流れ
2月28日に、メジャーバージョンアップとなるOpenSocial 3.0をテーマにしたサミットが行われました。その議事録が公開されています。 OpenSocial 3.0 Summit Minutes 参加者の所属企業を抜き出してみると、以下のような感じになります。ちなみに括弧内の数字は参加人数です。 Jive Software (5) Mitre (2) IBM (6) Sutro Software (1) Sugar CRM (1) EPFL (1) Office of the DoD (1) Atlassian (1) AppFusions (1) これを見ればわかる通り、すっかりエンタープライズなメンバーが揃ってます。一般的にソーシャルメディア、ソーシャルネットワーキングサービスと言われるサービスをやってる企業は一つもない。昨年の5月に行われたOpenSocial Union ev
Chrome extensionからOAuth対応APIを使うための工夫
あるAPIがユーザ認証と認可を必要としている場合、主要なサービスプロバイダはOAuth 2.0をサポートしていることが当たり前になってきました。Chrome extensionからも様々なOAuth対応APIを利用してマッシュアップしたいところですが、残念ながら現状では簡単なことではありません。ここでは、Google+ APIを題材として、実現方法の一つを紹介したいと思います。 問題となるのは、OAuthにて必要となる「元のアプリケーションへのリダイレクト先が制限されるサービスプロバイダが存在する」という点にあります。 通常のWebサービスであれば、httpもしくはhttpsで始まるURLにリダイレクトされれば、それがすなわちアプリケーションの世界に戻ってきたことを意味します。しかし、Chrome extensionは”chrome-extension://”で始まるURLで実行されていま
OAuth2.0によるGoogle+ APIのアクセス方法
Google+のAPIが先日公開されました。API Keyを使ってシンプルにAPIアクセスを試すことができるのですが、本来であればOAuth2.0にてアクセストークンを取得しAPIアクセスする方式でなければ今後公開されるであろうAPI群は利用できないはずですので、ここでOAuth2.0によるGoogle+ APIのアクセス手順を紹介しておきましょう。全手順において、プログラミングをすることなく試すことができます。 Client IDの発行 まずはClient IDやClient secretなどを発行しましょう。まずは、Google APIs ConsoleにWebブラウザでアクセスします。 https://code.google.com/apis/console/ まだプロジェクトを作成していないのであれば、Other projects→Create…にて新規にプロジェクト作成を行います
HttpServletResponse#getOutputStream()したストリームは自分でclose()するのか？
久々にJavaな話題。昨日社内で、 「Servletの中でresponse#getOutputStream()や#getWriter()したストリームは、自分でclose()する必要があるの？それともclose()せずに放置が正解なの？」 という質問を受けた。僕は「自分で獲得したリソースは自分で明示的に解放すべき」という考えが基本にあり、思い返すと、doGet()やdoPost()メソッド内でちゃんと自分でclose()するコーディングを長年に渡って行ってきた。flush()に関してもclose()したタイミングで行われるだろうし、初期のアホコンテナに対しては、ちゃんと後処理を行ってくれないんじゃないか、という不信感があったため、いつも自分でclose()を明示的に呼んでいた。 でも、昨日質問を受けて、果たしてclose()を自分でする必要があるのか？コンテナにclose()は任せる必要が
OpenSocial State of the Unionイベントに参加しました
Google I/O 2011の次の日、Google San Franciscoオフィスにて「OpenSocial State of the Union event」が開催され、それに参加してきました。「今年はやらないの〜？」とMLにて聞いたところ、めでたく今年も開催される運びとなりました。 現在OpenSocial v2.0の策定が進んでいます。これは結構意欲的な試みが含まれており、OpenSocial Foundation的にも「この日は”Open App Revolution”が開始された日として記憶されるだろう」と言ってしまうほど、重要なイベントとして位置づけられています。だいたい30〜40人くらいの参加者だったと思います。その中に僕もいることができたことは嬉しいことです（別に参加資格があるとか、そういうことじゃないけど）。ロゴからして、「革命だ！」って感じでしょ？ Mark We
OpenSocial v2.0の策定が始まっています
OpenSocial Foundationでは、既にOpenSocial v2.0の策定が開始されています。現時点で提案されている仕様は、以下のものがあげられます。 View Level Features Proposal [Social Data Model] Identifying ‘Guests’ Embedded Experiences Proposal CMIS Status [Social Data Model] Proposed Changes Simple Gadget Format gadget manifest proposal Space extension 簡単に言うと・・・ View Level Features Proposal ： 今後スマートフォンなどViewの多様化が見込まれ、それに応じてGadget Specファイル内で各Viewに対して機能を柔軟に指定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
