Google Docsに機能を追加できる「アドオン」機能追加 地図埋め込みや宛名印刷など数十件でスタート
米Googleは3月11日（現地時間）、オンラインオフィススイート「Google Docs（日本ではGoogleドキュメント）」の「文書」と「スプレッドシート」に機能を追加するための新メニュー「アドオン」を追加したと発表した。現在、サードパーティー製のものを含む50件以上のアドオンを選択できる。 ドキュメントの編集画面のメニューに追加された「アドオン」をクリックすると利用できるアドオンのリストが表示され、追加したいものをクリックするとアドオンの権限を承認する画面を経てインストールされる。 追加された機能はアドオンメニューのプルダウンメニューに追加され、ここで選択して利用できる。下は、Google製の翻訳ツール「Translate」の利用例だ。 一度インストールしたアドオンは別のドキュメントでも利用できる。文書とスプレッドシートで共通のアドオンもある。なお、スプレッドシートでアドオンを利用す
You don't need API version 2 - yohei's diary
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
