Data Pipelining (0.9)
OpenSocialアプリケーションが最初にレンダリングされる際に、開発者がまず行うことは何でしょうか？ViewerやOwnerといったプロフィール情報や、外部サービスの呼び出しなどがほとんどではないでしょうか？ Data Pipeliningは、非常に簡単な記述で、これらの初期情報を取得するための処理を記述することを可能とします。そして、取得した情報をJavaScriptコード内で扱うことはもちろん、Proxied contentやOpenSocial templatesにて利用することができます。 [Data Pipelining] http://docs.google.com/View?id=dhsg598c_1008hj7qqfcf Data Pipeliningは、OpenSocial v0.9の中でも非常に便利な追加仕様の一つです。 Tweet 関連記事 2023年のRemap
OSDE 0.3.0 候補版1 をリリースしています！
mixiアプリやgooホームガジェットの開発をサポートするOSDEのメジャーバージョンアップを計画しています。昨日、OSDE 0.3.0 Candidate 1として、最初の候補版をリリースしました。 Release OSDE 0.3.0 Candidate 1 supported OS 0.9 spec! http://opensocialdevelopmentenvironment.blogspot.com/2009/10/release-osde-030-candidate-1-supported.html このバージョンでは、Apache Shindig 1.1 Beta1をバンドルしています。つまり、OpenSocial Specification 0.9をサポートしているということになります。もちろん、今後のアプリケーション開発で主流となることが期待されているOSAPI(=Li
OpenSocialでの共通課金API - OpenSocial Virtual Currency API
OpenSocialの特徴は、開発したアプリケーションをさまざまなSNSに展開することができるという可搬性にあります。つまり、アプリケーションに対するビジネスを行う市場について、特定のSNSだけでなく、世界中の多くの市場を相手にすることができるということになります。 日本のモバイル市場や、世界のいくつかのSNSでは、すでにデジタルコンテンツを売り買いすることが盛んに行われています。この売買を実現するために、モバイルやSNSといったプラットフォームは、課金を行うための仕組みを整えてコンテンツプロバイダに提供し、利用してもらいます。ただし、そのほとんどが、プラットフォームごとに独自に策定された仕様となっています。プラットフォームごとに、コンテンツプロバイダは課金のための仕様を1から理解する必要が出てきます。 例えば、OpenSocialアプリケーションでSNSが提供する課金の仕組みを使いたいと
Activity Paging Support (0.9)
People & Friends APIを使って会員情報や友達情報などを取得する際に、条件に一致する人数が多くなることを想定し、ページングを指定することができるようになっています。例えば、JavaScript APIであれば、PeopleRequestFields.MAXとPeopleRequestFields.FIRSTを使って、1リクエストに含める件数と開始インデックスを指定することができるようになっています。 しかし、Activities APIにおいては、残念ながらOpenSocial 0.8.1においてもページングが考慮されていませんでした。そのため、多量のActivityがコンテナとクライアント間でやり取りされてしまう問題が発生します。特に、Apache ShindigにおけるActivityServiceインタフェースにおいても、ページングに関する引数が定義されていませんでし
OpenSocialはオープンです
「 OpenSocialアプリを開発する上での落とし穴」というエントリがあったので、ちょっとだけ僕なりの考えを書いてみます。 まず「落とし穴1 まずは「ガジェット」から理解するべし」と「落とし穴2 iGoogle で Gadget API が使えない？！」は、上記エントリのご指摘どおりです。今度の24日に「 OpenSocial入門」本が出版されますので、これからOpenSocialアプリケーションを開発することになる方々のバイブルになればいいな、と思っています。 さて、「[落とし穴3] 仕様変更の可能性」に関して、 現段階では、OpenSocial API のバージョンは 0.8.1 であり、正式バージョン1.0 までにはまだまだ仕様が変更される可能性があります。従って、実験的にアプリを作るのはいいですが、企業などで本格的にアプリを開発してしまうのは時期尚早かと思います。 に関しては、v
僕のCode to Test Ratio歴
Ruby on Railsでの開発では、その規模の大小問わず、短期的・長期的問わず、最低限の品質を確保するためにテストコードの作成と自動化は「必ず」行うべきである、という考えを僕は持っている。つまり、テストコードのないRailsの成果物は、非常識きわまりなく、構造計算が一切行われていない建物と一緒。もしそんな開発プロジェクトがあれば、それは国会で取り上げられる程の騒ぎにならなければいけない事態であり、IT業界からご退場願わなければならない、と思っている。 さて、RoRでは、常に「自分がテストにどれくらい関わったのか」という指標を確認できるように、rake statsというタスクが標準で提供されている。これにより、実装コード行数とテストコード行数の割合がサクッと出てくる。もちろんカバレッジ率ではなく、総行数に関する指標であるので、あくまで参考値ではあるが、それを意識するのとしないのとでは大違
天使やカイザーと呼ばれて: Ruby on Railsのテスト環境が気持ちいい
Javaな世界に10年以上どっぷりと浸かってきたが，Ruby on Rails(RoR)をやっていると「良く考えられているなぁ」と感心してしまう箇所が随所に見られる。とかくScaffoldやActiveRecordに関するコーディングに目が行ってしまいがちだが，僕個人的にはテストに関する環境が最も「おぉ」と感じている。 言うなれば，「JUnit + DbUnit + Cactus」な環境が標準で整備されている，ということだ。 JUnitについては，もちろんTest::Unitがそれに相当する。Test::Unit::TestCaseクラスを継承し，”test_“で始まる名前のメソッドを定義していくというのは，xUnitの流儀とほぼ一致している。JUnitで単体テストを行ったことがある開発者は，違和感なくTest::Unitでテストケースクラスを書いていけることだろう。 Web+DBアプリケ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
