404 shin1のつぶやきないわー Not Found

Google Pickerが便利すぎた

2012-09-06T01:23:00.000+09:00

Google Pickerっていう、Google Docs(Google Drive)を前提としたPickerがめちゃ便利な事に気づいていませんでした。ずっと GWT 専用のコンポーネントなんだと勘違いしていたという。Pickerですが、基本的にはリソースのURLが返されます。Docsネイティブなリソースの場合にはそのアイコンやらも取得できます。

こんなカンジでDocs内の文書を選択させたり。

地図からPlaceを選択させたり。

Docsへアップロードさせて、アップロードされたファイルを選択したり。

使い方

google.picker.PickerBuilder()をインスタンス化して、Builderを用意する
addView() addViewGroup()で、左側に表示するカテゴリやグループ化したカテゴリを追加する
リソースが選択されてポップアップが閉じた時のコールバック関数を登録する
build()して、setVisible(true)する

リファレンスのURL 書き忘れてたので追記: https://developers.google.com/picker/

App Engine Full-text Search API の使いどころ

2012-09-03T15:46:00.002+09:00

今年になって Google App Engineに Full-text Search(以下FTS)という機能が追加されています。全文検索機能の事で、日本語にも対応しています。リリース前に私も appengine ja night 20 で紹介をしました。その時にも「日本語検索はおまけ、それ以外の機能が強力」という話をしたのですが、それについて少し具体例を交えて説明をしようと思います。

ログインユーザごとのアクセス権限を参照する処理

RDBでは簡単でも、データストアで苦戦することまちがいなしの要件として、次のような要件がよく出てきます。

企業向けアプリケーション等で、リソースへのアクセス制御をしたい
リソースに対するアクセス許可リスト（ACL）として、ユーザIDだったり、ユーザを束ねたグループIDだったりを定義する
ログインユーザに対して、リソースの一覧を提供する。もちろん、アクセスできるもののみが一覧表示される。

企業向けアプリケーションではまず必要になる、よくある処理だと思います。ここでは企業向けアプリケーションと書いていますが、例えばTwitterなどの、ユーザ間の関係が発生するアプリケーションでも同じような要件が出てきます。なお、ここでいうグループはディレクトリ的なものではなく、一ユーザが複数のグループに所属できるような関係を想定しています。

データストアで実装する

これをデータストアで実装しようとするとなかなか厄介ですが、大きく分けると「保存時に頑張る」「クエリ時に頑張る」の二種類の方針が考えられます。

後者の方針は早々に破綻する可能性があるため（一覧表示くらいならなんとかなるが、なんらかのフィルタがくっつくと処理に相当無理が出るし、固定の件数でページングするのも難しい）、多くの場合は前者の「保存時に頑張る」方法で次のように実現することになると思います。

リソースが保存された時に、それにアクセスできると定義されたグループから、ユーザを展開する
展開したユーザ（リソースにアクセスできるユーザ）分だけ、「ユーザごとにアクセスできるリソース」を作成し、保存する。このエンティティはユーザのIDとリソースのIDを保持します。カインド Readable としましょう。
ログインユーザがリソース一覧を表示する場合、Readableに対してクエリを発行します。

独自にインデックス用のエンティティを作るということです。この実装方法ですとアクセスの制限が広いリソース（全社員向け、とか！）が保存された場合、ものすごく大量の Readable エンティティが作成・保存されますし、それ以外に面倒な非同期処理も必要になります。例えば、グループ内のユーザが変更された場合や、ユーザが新たに発生した場合です。しかし、「クエリ時に頑張る」実装よりは、ユーザに対して良いパフォーマンスを提供できるので、保存時に頑張る、を選択することが多いのではないかと思われます。

FTSを利用する

FTSを使うとかなり簡単になります。

リソースが保存された時に、リソースの主キーと、アクセスを許可するグループやユーザのIDを多値フィールドとしてFTSのDocumentに追加して、インデクスさせる。DocumentのIDとしては、リソースの主キーをエンコードした文字列を使用しとくと便利です（FTSにもkeysOnlyなオプションがあるのです）。アクセスを許可するグループやユーザのIDは ACL というフィールド名とします。
例えばログインユーザが g1 ,g2, g3 というグループに所属している u1 というユーザであれば、FTSで「ACL=u1 or ACL=g1 OR ...」とORでつなぐだけ。ソートやフィルタが必要であれば、それらのフィールドをDocumentに追加しておくと良いです。で、取得したリソースのキーを使って、データストアから必要なリソースをバッチGETすればリソース本体も取得できます。それが面倒なら、Documentの方に必要なフィールドを含めても良いでしょう（そうこうするうちにデータストアが不要になった、となる可能性もるかも）

工夫も何もありません、特にめづらしい実装にも思えませんが、FTSを日本語検索ではない目的で使用するのが強力だ、と言っていたのはこういう処理で使うことを想定していたためです。データストアだけでは実装コストもランニングコストも高くなってしまう処理が、工夫もなく簡単に実現できてしまうのです。グループのメンテナンスが発生した場合の整合性を維持する非同期処理は同じように残ってしまいますが、そこはデータストアに対するメンテナンスよりも軽くなるはずです。

これに日本語検索を加えてもいいです。今のところ、FTSを多用する場合の注意点は次のようなものがあるとおもいます。

FTSはまだExperimentalなため、APIのRateと保存容量にLimitが存在する上、利用料金も決まっていません。これらふたつのLimitはGooglerに連絡すれば回避できますが、料金はちょっと心配です。しかし、独自にインデックス用のエンティティを作って実装している場合はWrite Operationsもかなり大きいので、それら程度であれば、実装のコストが削減できる分FTSの方が良いですね。
FTSはまだExperimentalなため、不具合が無いとはいいきれません。
クエリに使える文字列は 2000文字が限界です. ひとりのユーザが数百のグループに所属…となると、それにひっかかってしまうかもしれません。それが心配な場合は、ユーザやグループのメールアドレスなど長い文字は使わず、別の短い値に変換して使うと良いでしょう。

まとめ

SDK1.7.0 から Datastore に対してもORによるフィルタが指定できるようになりましたが、その機能ですとカーソルを返せない（実際には複数クエリを並列実行してるだけなので、当たり前ですね）という問題があります。

Cloud SQLを組み合わせればFTSなしでも同じことができますが、テスト環境の手間が多少なりとも増えてしまうのがイヤな人にはデメリットです。が、このあたりは好みによりますね、素直にCloud SQLで慣れたRDBの設計・実装を行うのも実装コストを減らす選択肢のひとつです。Cloud SQLはスケールアウトしないという特徴にも注意が必要かも。一社のみで使うアプリケーションであれば良いですが、複数社に提供する業務アプリケーションであれば、ボトルネックになる可能性があります。

おまけ

肝心の日本語検索ですが、 Google検索＞＞＞ Gmail検索 = FTS ＞ Google Docs検索といったかんじの性能じゃないかなーと感じました。

coffee, lessなプロジェクトをgruntで便利に

2012-06-21T00:48:00.001+09:00

最近ようやくcoffeescriptにもLESSにも慣れてきました。で、そろそろgruntを活用しようかなと先月くらいから使ってみてますが便利です。

*.less →(コンパイル)→ style.css →(圧縮)→ style.min.css
*.coffee →(コンパイル)→ *.js →(連結)→ app.js →(圧縮)→ app.min.js
*-test.coffee →(コンパイル)→ *-test.js →(連結)→ tests.js
app.min.js, tests.jsを読み込んでqunitでテスト
index.htmlではapp.min.jsとstyle.min.cssを読み込む

こんなかんじの事を簡単にできます。テストもcoffeescriptで書けて良いです。

現在リリースされている grunt v0.3.9 では coffee, less, sqwishに対応したタスクが無いので、カスタムタスクを grunt.js 内で登録して使用してます（pluginとして環境に登録はしていない）。

$ grunt watch &: lessやcoffeeファイルの編集を監視して、自動的にコンパイルして連結して圧縮してくれます。
$ grunt clean: 出力ファイルやフォルダを全て削除します。
$ grunt: lessやcoffeeファイルをコンパイルして連結して圧縮して、圧縮したjsを使ってqunitでテストしてくれます。

フォルダ構成

私の場合はほぼ全てのプロジェクトがGoogle App Engine/Javaプロジェクトで、mavenを使っているのでフォルダ構成は次のような状況です。

src/main/coffee
- プロダクト用の coffee ファイル
src/main/less
- less ファイル
src/test/coffee
- テスト用の coffee ファイル
src/test/qunit
- qunit.css, qunit.js, sinon.js, qunit.html(war/js/app.min.js, target/tests.js)

出力先となるフォルダ・ファイル。

target/js
- プロダクト用の coffee ファイルをコンパイルしたJavaScriptファイル
target/js.test
- テスト用の coffee ファイルをコンパイルしたJavaScriptファイル
target/tests.js
- テスト用のcoffee ファイルをコンパイルしたJavaScriptファイルを連結したJavaScriptファイル
war/css/style.css
- lessをコンパイルしたcssファイル
war/css/style.min.css
- lessをコンパイルしたcssファイルを圧縮したファイル
war/js/app.js
- プロダクト用のcoffeeファイルをコンパイルしたJavaScriptファイルを連結したJavaScriptファイル
war/js/app.min.js
- プロダクト用のcoffeeファイルをコンパイルしたJavaScriptファイルを連結したJavaScriptファイルを圧縮したJavaScriptファイル

grunt.js

次がgruntの定義ですが、これを利用するには、nodejs, npm, phantomjs が必要で、npmでは grunt, less, coffee-script, sqwish をインストールしておく必要があります。

Google API Expertが解説する Google App Engine for Java実践ガイドが発売されます

2012-03-12T14:02:00.000+09:00

書きました。3/16(金)に発売されます。Javaの経験が無いと厳しいです。。Javaの経験があり、Google App Engine/Javaに興味がある人、実際に現場で使っている・使う予定がある人の役に立つと思いますので、興味があればポチってみてください。

目次は次のようになっています。

第1章イントロダクション
第2章 JUnitによるテスト
第3章各機能の使い方
第4章アプリケーションの設計の注意点
第5章課金額の節約
第6章提供されるツールの使い方

1章ではHello worldレベルのサンプルを実施し、2章では1章で使ったサンプルを作り直しながらGoogle App Engine/Javaの環境での自動テストの能力と、IDEの能力を引き出す方法を説明し、Google App Engine/Java環境での開発のリズムを掴めるよう説明します。一番ボリュームがある第3章では、まずは様々なサービス（機能）を実行する仕組みを説明して、その後サンプルアプリケーションを拡張しながら次のサービスについて説明します。

Datastore Service
Users Service
Memcache Service
Task Quere Service
Scheduled Tasks
Mail Service
Channel Service
Blobstore Service/File Service
Images Service
Prospective Search
XMPP Service
URLFetch Service
Backends
Pull Queues & Pull Tasks
Log Service
Capabilities Service
OAuth Service
Multitenancy
Conversion API

4章、5章は主にアプリケーションのチューニングの説明をします。

Google App Engine/Java環境を使った場合の自動テスト対象の広さ＆速さ、開発効率の高さ。それらの支えがあることで、アプリケーションのサーバ側がどれだけラクになるか、という事が伝えたい内容です。

CoCafeでのGoogle App Engine側の工夫

2012-01-15T23:40:00.001+09:00

年末に @aqubi と CoCAFE というアプリケーションをリリースしました。喫茶店のWiFi状況やらなんやらを共有するiPhone用のアプリケーションです（Android版も作ってます）。

このアプリケーションでは Google Places APIとGoogle App Engineを使っていて、Google App Engine側では以下のような工夫をしてます。

Datastore(HRD)

地図のZoomに合わせた範囲検索をEqualityフィルタで実現するため、店の位置情報はGeoHashの先頭4文字,先頭5文字,先頭6文字,先頭7文字...とリストプロパティに保持→前方一致検索を使わずに済むので、別の条件で同時にInequeality Filterを使うこともできる。
利用ユーザ等の統計をとるためのアクセスログ的なデータは、必要な情報を全てKeyに詰め込んでいる→ Datastore Write Operationsの節約

Task Queue

APIごとのアクセスカウンタは、リクエストを受け取ったときにはPull modeのTask QueueにTaskを追加。定期的にそれをPullして集計し、Datastoreに反映→ Datastore Write Operationsの節約、更新の衝突の心配もせずに済む

OAuth Provider

App EngineのOAuth Providerを使用したのでOAuth Provider的なコードはほぼ書かずに済んだ

開発にかかった時間の殆どがクライアント側の実装と、操作性の調整です。Google App Engineだとサーバ側の実装はDBのコネクションがどーたらとか全然関係ないし、自動テストも簡単に実装できるし、全ての自動テストを実行しても大概数秒で実行できるし、ミドルウェアの設定も保守も必要ないし、運用も手間がかからないし、アプリケーションに集中したい人にはラクで良いです。

Slim3+Cross Group TransactionをUnit Testで使う #gaeja

2012-01-13T00:21:00.000+09:00

昨年末から何度か「Slim3でCross Group Transaction(所謂XG)をUnit Testで使う時どうするの」的な話を見かけつつ、反応できていなかったので書いておきます。

まず「UnitTest環境でHRDを有効にする」「（Slim3で）XGを使う」のふたつに分けて考える必要があります。

UnitTest環境でHRDを有効にする

Slim3は1.0.15くらいからGoogle App Engine SDKが提供するUnitTestの仕組みを併用できるようになっています。mavenを使っている方は、最新のslim3-archetype-pluginを使ってプロジェクトを生成した場合にappengine-testing等のモジュールが依存に追加されている事に気づいた人もおられるんじゃないでしょうか。

Slim3のAppEngineTestCaseを継承したテストクラスの場合は、SDKが提供するUnit Testの仕組みを併用して、setUp()/tearDown()を次のようにするとHRDが有効になります。

LocalServiceTestHelper helper;


@Override
public void setUp() throws Exception {
  LocalDatastoreServiceTestConfig dsConfig =
    new LocalDatastoreServiceTestConfig()
      .setDefaultHighRepJobPolicyUnappliedJobPercentage(0.01f);
  helper = new LocalServiceTestHelper(dsConfig);
  helper.setUp();
  super.setUp();
}

@Override
public void tearDown() throws Exception {
  super.tearDown();
  helper.tearDown();
}

Slim3でXGを有効にする

Transactionオブジェクトの構築方法によります。

Slim3のDatastore.beginTransaction()を使ってTransactionオブジェクトを作っている場合は、システムプロパティにslim3.useXGTX=trueが指定されている必要があります。Server環境（Productionサーバ、開発サーバ）で起動している場合はシステムプロパティはappengine-web.xmlでそれを指定すれば良いですが、Unit Testの際にはappengine-web.xmlが読み込まれませんので、setUp()の際にSystem.setProperty("slim3.useXGTX", "true");とする必要があります。

Slim3のDatastore.beginTransaction()を使わず、Low Level APIを使ってDatastoreServiceFactory.getDatastoreService().beginTransaction(TransactionOptions.Builder.withXG(true));としてTransactionオブジェクトを作っている場合はSlim3のシステムプロパティを気にする必要はありません。Slim3が使用するTransactionオブジェクトはLow Level APIで使用するTransactionオブジェクトと同じクラスですので、Low Level APIとの併用も可能です。

私としては、slim3.useXGTX=trueを指定せずSlim3のXGは使えなくしておき、XGを使うときはLow Level APIを使ってTransactionオブジェクトを作成する方が好みです。XGを使用している事がコードから明確に見て取れるという点が嬉しいです。

Google+ Hangout APIが公開されています

2011-09-21T02:43:00.001+09:00

Google+ Hangouts API - Google+ Platform — Google Developers

Gadgetとして作成するようで、Hangouts画面にアプリケーションが埋め込まれる、といった形で実行されます。

手っ取り早い試し方

Google API ConsoleでGoogle+ Hangouts APIをONにする
API Consoleの左側のメニューにあるHangoutsをクリックすると、Gadget URLを入力するテキストボックスが配置されたページが開きます。
本来ならWriting Hangout Apps - Google+ Platform — Google Developersを確認してガジェットのコード（XML）を書いて外から見える場所（Google CodeとかApp Engineとか）に配置する必要があるのですが、サンプルがあるので手っ取り早くそれを使いましょう。
https://google-plus-hangout-samples.googlecode.com/hg/samples/yes-no-maybe/ggs/yesnomaybe.xmlを入力し、saveをクリックします。
Gadget URLが正しく読み込まれると、Enter a hangout!というリンクが表示されるのでクリックすると、ガジェットが実行されますので入室しましょう。入室すると左下の「Chat」の横に「App」があるので、クリックします。すると、Waveでよく使っていた Yes/No/Maybe のVoteアプリが起動しました！
右上にある「Manage Apps」と書かれたツールバーの「Get My App」ボタンをクリックすると、API Consoleに登録されているプロジェクトからアプリをLoadすることができます。同時に複数のアプリをLoadしたらどーなる？と試して見ましたが、一個しか読み込めないようです。

今のところは参加者のアカウント一覧を取得したり、現在のアクティブスピーカー（発言中のアカウント）を取得したり、デバイスの状況（マイクあるの？とか）を取得したり、チャットの領域を表示・非表示するなどの制御ができるようです。Gadgetのコンテナを実装してGadgetでアプリを作るプラットフォームを提供してくるというのは予測済みでしたが、まさかHangouts画面をコンテナにしてくるとは思ってませんでした。あんまり使う気はないけれど、良い意味で裏切られて面白いです。

P.S. Google様、リアルタイムストリームを取得するAPIを心待ちにしているのですが、できればPubsubhubbub経由以外で、デスクトップクライアントから使えるようにお願いします。どーしてもPubsubhubbub経由になるなら、まだ見ぬFeed API V2（Google I/O 2010で発表されてましたね！まだ待ってます！）と共にリリースしてくださいませんかお願いします。

とうとう公式のGoogle+ APIが公開された…気がしたがそうでもない

2011-09-16T04:28:00.000+09:00

Getting Started on the Google+ API - Google+ Platform Blog

この記事のタイトルを見て喜んだ人もたくさんいるんじゃないでしょか？承認はOAuth2だし！
しかし残念。まだDiscovery APIにも対応しておらず、そのためかAPI Explorer上でも使えません。Buzz APIでいうscope:publicしか対応しておらず、consumption/comments/likedが使えません。がっかり。Buzz APIでのscopeはcollectionというパラメタに変わるようです。さらに、likedはplusedとなるのかもしれませんね。まぁ細かいことはどうでもいいです。

プロフィール情報の取得
アクティビティ（投稿）のリストの取得
アクティビティ（投稿）の取得

たったこれだけしかできません。アクティビティのリストも「公開」のもののみ。どれも、これまでだってスクレイプすりゃとっくに取得できてたもんです、がっかり。

API ConsoleでGoogle+ APIをONにする。
API Consoleの左のタブから「API Access」を選択して、「Simple API Access」欄の「API Key」をコピペする。
プロフィール情報の取得であれば https://www.googleapis.com/plus/v1/people/115271879735982073394?key={YOUR_API_KEY}
アクティビティ（投稿）のリストの取得であれば https://www.googleapis.com/plus/v1/people/115271879735982073394/activities/public?key={YOUR_API_KEY}
アクティビティ（投稿）の取得であれば https://www.googleapis.com/plus/v1/activities/z12aejnbcwekizmi304cgnzbcwq0e5cxnag?key={YOUR_API_KEY}

上記が使用例です。115271879735982073394ってのは私shin1ogawaのIDです。{YOUR_API_KEY}には、手順中でコピーするもので置き換えてください。

…これくらいしかやることがありません、がっかり…でもG+API担当者の方、重要な第一歩をありがとうございます。お疲れ様でした。

APIに関する公式ページの http://developers.google.com/+/api の変更を監視開始しましたので、これからガンガン機能追加されて忙しくなんだと思います。

Google App Engineの新料金体系に向けた準備 #gaeja

2011-09-10T23:56:00.003+09:00

新料金体系について公開されている情報

これらの情報の中で、特別重要だなーと思うのは以下の点です。

CPU時間ではなくインスタンス起動時間で課金されることになる。無料枠は24時間…ではなく28時間（上記最後の記事で出ている話で、まだ28時間無料となった状況での課金結果は確認できてません）。
Datastore操作APIが高くなる
いくつかのAPIは無料になる
管理コンソールの「Billing History」で、新料金に換算した時の価格を確認できる
管理コンソールの「Max Idle Instances」「Min Pending Latency」のふたつの設定を触ることで、無駄なインスタンスをできるだけ立ち上げず、スケールアウトしづらくするようスケジューラの動作を制御できる
リクエストを並行処理する設定にすると、複数リクエストを同時にひとつのインスタンスで扱える（GAE/Javaでは現状でも既に可能、GAE/Pythonは将来のPython2.7から可能）

簡単なチューニング結果の紹介

以下は私のアプリケーションで、Lingrの特定のroomへの発言に対してbotとして動きつつ、5分に一回Redmineに対してSVNの更新チェックをキックする、といったbot系のアプリケーションの課金額です。チューニングと言っても、プログラムは一切さわらず、管理コンソールから「Max Instances=1、Min Pending Latency=15s」という設定を行うだけで、その設定を行う前後の比較です。

設定前後のインスタンス数グラフ

二日前に何か設定が変わった？という事が明らかにわかるグラフですが、インスタンス数の平均がガクッと減っています。

設定前の課金額

左が現行の料金体系で、余裕で無料に収まっています。右が新料金体系で、インスタンス時間が103時間を超えていて、$3.3/日となり、月7000-8000円程度になるようです。こういうアプリをたくさん運営している場合は、ちょっと個人にはツライ金額です。

設定後の課金額

先のスクリーンショットと同じく、左が現行の料金体系で、余裕で無料に収まっています。右が新料金体系ですがインスタンス時間が27時間程度に収まっていて、$0.3/日となり、月700-800円程度にまでおさえれそうです。さらに、これはインスタンス時間の無料枠を24時間とした時の金額なので、実際には28時間無料で計算すると月400円程度になります（優良枠で利用する場合は実際には最低$9なので、それより下にしても変わらない）。さらに、このアプリはMemcacheを全く使っていなかったり設計も適当な手抜きアプリなので、少しチューニングすればデータストア操作も無料枠に収まり、結局無料枠で稼働できると思われます。

それでもまだ無料枠に収まらない

シンプルなアプリなんだけど、無料枠が28時間でもギリギリ超えてしまうよ…といった、「無料に抑える」が目的の時に、一部の処理を「Backends」の9時間の無料枠に振ってしまおう、というのが「App Engine のリソース管理 - TaskQueue の設定 - Kay's daddy」の記事に書かれているチューニング方法です。課金額を抑える目的でないとしても、Task QueueをBackendsで処理させるという手法は重要ですので、Backendsという機能を知らなかった方は見ておくと良いです。

大規模なアプリなので無料枠を目指すわけではないがもっと安くｒｙ、といった場合は……主にDatastore操作が高くなると思いますが、そのあたりのチューニングを進めるしかありません。Queryの実行に対して、QueryによるKeyのみのフェッチは価格が1/7、という点に注目すると面白いかもしれませんね。

とはいえ、いきなり設計を変えるわけにも行かないし、これまでは正式版じゃなかったから仕方ない…と簡単に諦められるもんではありません。ボリュームディスカウントの導入とか、もう少しくらい値下げが無いものか？とか色々期待しましょう。提案等がある方は中の人に直接メールをしてみると良いと思います。

新料金体系の導入についての感想

これまでは、Google App Engineというと、「価格」「（自動スケールアウトも含めて）運用の手間が無い」のふたつの特徴が大きく言われていました。これが、「価格」については魅力ががつーんと低くなりますね。でも共有地の悲劇みたいな事がずっと起こってパフォーマンスが出にくい時期もありました（あっと言う間にSpin downしちゃう→毎分Cronで叩き続けてちょっとでも確保しよう→余計にSpinDownしやすくなるとか）し、負荷をかけるばかりのアプリケーションをある程度追い出すという結果になるなら、丁度良いバランスの設定かも？と思います。特に現在のGoogle App Engineのデフォルトの設定では「パフォーマンス優先」となっていて、適切に設定を行わない限りはシンプルなTwitterbotアプリでも簡単に「毎月一万円」くらいに達してしまうので、設定や開発で工夫をしようとしない人は利用をやめることになるのでしょう。

私はというと、OSやらミドルウェアのインストール・設定・パッチ適用などのメンテナンス…といった「運用の手間」に関しては完全に排除したい（そもそも知識も興味も無い）人なので、値上げがあってもGoogle App Engine以外の選択肢は今のとこあまり考えていません。上述しませんでしたが、Google App Engineが提供するテスタビリティが高い開発環境、優秀なApp Engine専用フレームワークの存在、といった状況もアプリケーションの設計実装に集中したい私には重要です。そんなワケで新料金体系については「値上げか仕方ないなー、でもお金取るんだからこれまでよりももっとしっかり運用、情報公開して欲しいですね」という感想です。確実に利用者は減るでしょうから、その点だけは「寂しいな」と思いますけどね。

また、ポータビリティが極端に低いGoogle App Engineで今回のような事件が起こることで、今後のPaaSの選定基準でのポータビリティの重要度が増したりするのかな？といった点も興味深いです。

追記

一定の時間間隔でURLFetchして単純な処理を…といった程度であれば、Google App EngineではなくてGoogle Apps Scriptでも可能ですよ。

Twitter API ポケットリファレンスが発売開始されてますー

2011-07-18T23:13:00.001+09:00

Twitter4Jで有名な@yusukeyさんによるTwitter API ポケットリファレンス (POCKET REFERENCE)が発売されています。

Amazonで予約した分は16日に発送されてる割にまだ届いていないのですが、著者の @yusukeyさんに献本していただき早めに手に入れることができて助かりました。ありがとうございます〜！

感想

まず目次が長い。11ページもあります。が、この目次がよいガイドになってくれており使いやすいです。
比較的新しめの内容も取り込まれており、さすがといったカンジです。
付録の「アプリケーション開発のコツ」がうまいノウハウ集みたいになっていて、既にTwitter APIを駆使している人にも役に立ちそうに思います。自分はgzipとかすっかり見落としていました。

Twitter初心者のかたは…

素直に前から順に読み進めていくとよさそうに思います。

Twitter API初心者の方は…

まずは目次にひととおり目を通して、どんな種類のAPIが提供されていて、それぞれどんな情報にアクセスするのか？をまず確認し、その後認証関連（2章）を理解し、必要なAPIをかいつまんで触っていくのが良いと思いました。で、付録の「アプリケーション開発のコツ」を読んで、お約束というかノウハウを頭に入れるようにすると良さげです。

Twitter API慣れしている人は…

やはり目次に目を通し、知らない機能・見落としていた機能が無いか確認すると良いと思います。また付録の「アプリケーション開発のコツ」を読んで、間違った・効率が悪い使い方をしていないのかを確認できそうです。また265ページの「再接続アルゴリズムのフローチャート」は、正しくストリーム処理を行うためにとても参考になると思います。

Google Plus を使った感想をまとめてみた

2011-06-30T10:34:00.004+09:00

昨日一日感想をメモしながら使っていたのでそれらのまとめ。

まず最初に大雑把な感想を書くと、Buzzをわかりやすく使いやすくして、Google Alert, Latitude(Places API ?)のチェックイン、+1, Picasa, Profiles, Google Talk+ビデオチャット等の各種Google Serviceを（かなりわかりやすく）統合したダッシュボードといった印象を受けました。

メモ

投稿に関しては基本的にBuzzと同じ
ただしBuzzにある外部サイトからのFeed取り込み機能はまだない
APIもない
公開範囲を制限するサークルに関してもBuzzと同じだけど、Buzzの頃のわかりにくさが消え去った
サークルはあくまでも自分から見た共有範囲であって、他人と公開範囲を共有できるFacebookのグループとはちょっと違う
Sparksは今のところGoogle Alertに見える。
最初からマルチアカウント対応している
~~キーバインドが無いっぽいので、操作性はイマイチ。~~jkで上下移動します。投稿時のバインドだけは早めに用意してい欲しいです。
ビデオチャットの「YouTubeを皆で見る」機能は面白い！ただし、そこでのチャットの内容はどこに保存されたかわかんない。GmailのChatのトコにも無かった。なんでもかんでも保存しそうなGoogle様なのにこれはちょっと謎。
Google FeedbackというFeedback機能が埋め込まれている。ただしPreviewした後に編集し直したいと思ってCancelすると、書きかけのFeedbackが葬り去られるので注意。まず最初にその件をFeedbackしておきましたｗ

期待

まずはAPI。しかも早く。APIの提供が遅いと専用クライアントも出てこず、Buzzの時みたいに普及を妨げる要因になると思う。
リアルタイム通知を受け取るためのAPI。BuzzのころはPubsubhubbubのSubscriberとして登録する必要があり、サーバサイドのWebアプリでしか使えなかった。これをデスクトップクライアントでも通知を受けられるようにしてほしい。もしくはPubsubhubbub+Feed API V2. しかしFeed API V2はどこにいっちゃったの。この機会にリリースして欲しいです。
Plusを使うためにProfilesサービスが必須。しかしGoogle AppsではProfilesサービスが使えないからどうしようもなく詰んでしまう。せっかく颯爽とマルチアカウント対応しつつ登場したのにApps全滅とか無いわー。
Google Appsで使えるようになったら、DocsやらCalendarやら、ドメイン内のアクティビティを自動的にPostされて欲しい。そうすることで社内のアクティビティが少しでも多く可視化されて良いのでは。ただし、大きい企業だとドメイン内の共有サークルみたいなのが必要になるんでしょうね。Google Groupsをサークルとして使用する…みたいなカンジで管理者が設定できるとなんとか使えるかも。
buzzの頃の名残なのか、Gmailのユニバーサルナビゲーションから投稿できて、通知数も表示される。しかし、これは逆というかplus内にGmailのタブを用意したほうがいいような。それか、全てのサービスのユニバーサルナビゲーションに投稿と通知の領域を用意するか。
buzzの頃にもたくさん議論されたトピックだった気もするけど、Friendfeed形式に「最近コメントが追加されたら即効で上に上がってくる」という動作を期待しちゃいます
Sparksというか、特定のトピックについて…に関しては whatdoyoulove みたいな見方もできるといいなー

追記: Tips

ストリームを見る際にjkキーバインドがある
右上の赤い四角い通知アイコンをクリックするとお知らせが表示される。そこはカーソルキーの左右でお知らせを行き来できる。
@とか+で特定の人に対する返信になる。通知の種類に影響する。
通知メールが鬱陶しい場合は、右上の設定で制御してもよいし、Gmailの設定で「from:@plus.google.com」でフィルタすると良い。

第一回 GTUG Girls meetup が開催されました #gtuggirls

2011-06-24T00:01:00.002+09:00

先日GTUG Girls 設立のニュースがDeveloper Relations Japan Blogからアナウンスされました。今日はその第一回meetupということでGoogle Apps Script(略してGAS)のハンズオンが実施され、私はチューターとして参加しました。

実施する前は、Google Apps Scriptという題材がマイナーすぎだし、GTUG系のイベントは応募者のスキルレベルがまったく想定できないという点でもサポートの人員不足が心配でした。

しかし実際にはJavaScriptの経験者の方には大して難しくなかったようで、いい具合に「近くに座っている参加者同士でサポートしあう」という、最高の形ができあがって進んでいたようです。ホッとしました。
個人的には女子オンリーのハンズオンは二回目の参加になるのですが、今回も以前の女子ハッカソンの時と同様「みんな真剣で、わからないことがあっても協力しあって着実にこなしていく」というスタイルは男子のそれよりも強い、という風に感じました。

イベントは「GTUG Girls設立についてのアナウンス」「サンドウイッチ等の軽食でアイスブレイク（GTUG Girlsロゴ入りのTシャツが配られましたよ〜）」「GASについて紹介・デモ」「ハンズオン」、そして最後にGTUGGirlsのこれからの展望について説明、その他いくつかアナウンス、といった構成でした。何気にa2cさん〜fumiさんの話を聞く余裕があんまりなかったので、自分でとぅぎゃって後から追いかけてたりしました。

資料類

a2cさんのセッション資料
a2cさんのハンズオン資料 →これはファイル名通り、コピーして使用してください。
ハンズオンが簡単すぎてつまらない人向けの課題
上記の課題の答えが書かれたシート →コピーしてScript Editorを開くと、課題のStepごとにスクリプトファイルを見られます

情報交換の場

GASのデモや、ハンズオンの後でアナウンスされたものです。

Google Apps Script Japan – Lingr: 講師のa2cさん、shin1ogawa, 他にもGASに詳しい人達が集まっているLingr roomです。
本日公開された Google Apps API Japan Group: Google Apps Scriptや、Google Apps APIについて情報交換をするMLです（女子限定ではありませんよー）

感謝

会場と準備作業をしてくださった株式会社ミクシィ様＆スタッフの皆様、GTUG Girlsスタッフの皆様、@fumiさん、@tmatsuoさん、講師の@atusiさん、参加者の皆さん、ありがとうございました〜

あと「今後GTUG Girlsで何やりたい？」にGoogle App Engineと答えてくれた方々にも感謝！ :)

#appengine ja night 16( #ajn16 )が開催されました

2011-05-28T22:46:00.002+09:00

5/27(金)にappengine ja night #16が開催されました。今回はajn史上最高の女性比率を記録するほど、たくさんの女性に来ていただけまして大変よい雰囲気の中で実施されました。過去の最高記録比400%くらい達成した気がするので、この勢いでいけば次々回あたりには参加者が全員女性という可能性も見えてきました。
今回参加された女性陣の方々で、ちょっとでもappengineやサーバサイドの世界、またはコミュニティそのものに興味が！、とかなんでもいいんで興味を持っていただけた方＆楽しんでいただけた方は、是非次回以降も継続しての参加をお願いいたしします。

いつものように@drillbitsさんがtogetterにまとめてくれています、ありがとうございます。

@kazunori_279さんがいつものようにUstream配信して下さり、録画もあります。

@yanzmさん: GWT+UIBuinderのお話

ajn史上二人目の女性発表者です。今回は集まり具合が半端ない（いつもは開始時間では半分ちょっとくらいなのに今回は開始時間で相当埋まった）状況だったのですが、あんざいさんのおかげなのでしょうね。
個人的には GWT は大昔に一度調査したきりでそれ以降使っていませんが、最近の情報を（自分で調査すること無く）知ることができるならこれは美味しい機会だという雰囲気で勉強させてもらいました。またレイアウトに関しても、実はSwing等のリッチクライアントでも「コードから構築したほうが速い（IDEのサポートが必要）・はまらない・テスタビリティが高い」という方針で、通常はレイアウタやテンプレートは使わなかったりします。がしかし、それだとレイアウタやテンプレートの機能について勉強しなくなっちゃうので、やはり自分で調査すること無く知ることができたのは良い勉強になりました。気にしているものの触らない…が気にしている、みたいな状況のプロダクトについての説明を経験者から聞けるのはホント助かりますね。

@tmatsuoさん、@IanMLewisさん、@shin1ogawa: Google I/O 報告

@tmatsuoさんには無理言って、前日開催されたGTUG東京のI/O報告会と同じ Building Enterprise Applications on App Engine を話してもらいました。個人的にすごい気に入っていて、時間を使って話してもらいたかったからです（GTUG東京の報告会では3分縛りがあったｗ）。課金体系の変更には賛否両論（主に「否」かもｗ）たくさんありますが、Google様の事だからうまいバランスで調整してくるだろうなーと思ってあまり心配していません。他に印象に残ったのは、例のRoyal Weddingのサイト、32,000req/sと大規模だったのに「特にそれに向けて何か準備とか調整したわけではない」という事です。我々と同じ条件でそのスケーラビリティを発揮したのですね、素晴らしい。なんでI/OのregistrationでEC2ではなくAppEngineを使わなかったんｒｙ

私の資料は http://goo.gl/DGZMJ に置いてあります。

@IanMLewis さんの Go on App Engine は、Go利用者が少ない中での発表となりましたが、個人的にはGo on AppEngineの雰囲気を伝えるためにも必須だったと思います。RPCについて他の言語とそんなに大きく違うわけではなく、敷居が高いものではないよと伝わったんじゃないかと思います。IDEのサポートがまだ弱い（IntelliJ, Eclipseしか見てませんが）上に、Pythonのように簡潔には書けない…ように見えるのが残念ですが。I/Oのどのセッションだったか忘れましたが、将来の話として「BackendsにJava, Pythonのマルチスレッドサポート云々」というような話がちょろっあったんですね。自分としてはそれを「ついでにGo Runtimeも乗ってくるんだろなーそれならBackendsでは、GoRoutineで簡潔に書ける＆高速に実行出来るGoで書くことになるだろな（Googleはそう考えてるだろな）」と考えていたので、Go on AppEngineは重要な事だと思ってます。ひがさんがヤケに「Goいらんだろ」とおっしゃてましたが、それはFrontEnd（経由のAppServer上）の話だと思います。たしかにそっちでGoは必要なさそうですね。

BeerTalk: Backends他

このあたりは1.5.0プレスリリースで知られていたことだし、前回のajnでも話題に上がった話なのでサラッと流させてもらいました。ただ、@drillbitsさんは女子と話していて聞いてくれていなかったそうです、ヒドイ。

BeerTalk: @bluerabbit77jp さん: Frontend cache control

資料も上がっていますが、これはI/Oのセッション Scaling App Engine Applications で Guido が話していたプラクティスとして紹介されていました。@bluerabbit777jpさんは17,000円程度のcpu使用量が0円になったそうです。ただしこの機能はBilling Onじゃないと使えないから注意！という説明もありました。
ついでに書いておくと、話が終わった後に、とあるGooglerの方がわざわざ前に来て「あ、ちょっとこれには注意が必要なんです。billing onじゃないとｒｙ」とか言い出したりしていたので、この人もやはり女子と話していてBeerTalkをちっとも聞いていなかったようです、ヒドイっすな。

BeeeTalk: @knj77 さん: Zusaarの紹介

参加費の決済もできるイベント開催支援サービス「Zusaar」

すいません、女子と話していて聞いていませんでした。

BeerTalk: @kissrobberさん: クラウド時代の新しいソートアルゴリズムTask Queue Sort

資料も上がっています。例のsleep sortをクラウド時代に…という話でコレは相当おもしろかった。こういうのは毎回一つ欲しいですね。

感謝

今回も会場を提供してくださったニフティ株式会社様、会場での準備・案内・片付けなどをしてくださったスタッフの皆様、大変ありがとうございました。告知に失敗したところをフォローしてくれた @tagomorisさん、大変ん助かりました。またいつもUst, ピザ＆ビールの面倒を見てくださる@kazunori_279さんありがとうございます＆次回もよろしくお願いいたします。
そして盛り上げてくださった参加者の皆様方、スピーカーの皆様方、大変ありがとうございました〜

その他

I/O終了からこの2週間、会社の仕事、ajnの他でもI/O報告系のイベント、I/Oで見ていないセッションを消化、等々で忙しかったです。特に見ていないセッションの消化に関しては、英語力がかわいそうなかんじの自分は動画の消化も実時間の3倍くらいかかってしまい、相当時間を消費してしまいました。そのあたりについて関連リンクを貼っておきます。

次回

7/2(土)に開催されるかもしれません…？なぜ土曜日なのか、は想像しておいてください。詳細が決まれば、参加費の決済もできるイベント開催支援サービス「Zusaar」で告知される予定です。

Google I/Oの #appengine 関連セッション動画一覧 #gaeja

2011-05-16T15:56:00.004+09:00

5/10, 5/11に開催されたGoogle I/Oに初参加してきました。Google App Engineについては1.5.0のプレスリリースが事前にあったり、それを含んだappengine ja night 15が開催されたりしていたためインパクトは小さかったですが、golang他いくつかビックリの話も出ていました。個人的にはGoogle Appsの方がアツかったなー、という印象です。現地では、I/Oに生で参加できたという点よりも、超絶優秀なGoogle API Expert達と一緒に参加・行動できた、というオプションが一番すごい事だったかもｗ API Expertのみなさんお世話になりました。部屋をシェアしてた @IanMLewis と @atusi さんは特にありがとうございました。

帰ってきてからは情報を整理したり、手を動かして試したいものは試したり、色々と作業がてんこもりで大変です。で、見ていないセッションはもちろん、参加したセッションも動画で復習したり…といった時に便利なように、App Engineの全セッションとそれ以外の一部のセッションの動画を一覧にしました。I/Oの公式サイトの各セッションの詳細ページだと、動画へのリンクが無いものもあったりして不便なため、動画へ直接リンクをはっています。

Google App Engineセッション一覧

その他 shin1ogawaが気になったセッション

参加できてないし、まだ観ていないものもありますが。Google Apps Scriptはアツイ事になりましたね、商売あがったりですね！Appsはここのあげたもの以外にもありますが、Appsでメシを食っている人は最低限ここに上げたものはチェックしておいた方が良いです。

Androidは社内の若い衆に任せてますし、GWTは触らないので含んでません。サーバ側ばっかりです。

Google Apps: Developing Apps, Add Ins and More with Apps Script
Google Apps: Using The Google Docs APIs To Store All Your Information In The Cloud
Google Apps: Enterprise Workflow with Apps Script
Google APIs: Google Tasks API
Developer Tools: Writing Web Apps in Go
Developer Tools: Bring the Cloud to Your IDE with the Google Plugin for Eclipse

2011-05-19 追記

Google API Expertの @IanMLewis さんが1.5.0リリースについてのエントリを作成されました。

Appengine 1.5.0 がリリースされました - Ian Lewis

2011-05-28 追記

一部のセッションでSlideやNotesが公開され始めたので、それらも含めた一覧にしました。I/O報告会などでさらに興味を持ったセッションが増えてたりしますが:)

https://sites.google.com/site/shin1ogawa/io2011

#appengine ja night #15( #ajn15 )が開催されました

2011-05-07T15:58:00.001+09:00

5/6（金）にappengine ja night #15が開催されました。人数は数えてませんが今回も女性参加者率が悲しい結果になり、むさい空気の中開催されました。

今回も@drillbitsさんがtogetterにまとめてくれています、ありがとうございます。

AppEngine テスト駆動開発

@IanMLewisさん
Ust録画

AppEngine/Pythonでの自動テスト事情の説明でした。まだ全然触っていないけど個人的には1.4.3からPython SDKに導入されたTestbedについておおよそ仕組みがわかってよかったです。Testbedはsetup等で細かく制御できそうなのはメリットでもありデメリットであるかもしれませんね。
でも、結局はアプリ用のF/Wと一緒になっている方が良いので、@tagomorisさんが作ったF/Wをベースにしたテスト支援機能を持つKay-frameworkがヨサゲなんだろな、と。

Gig in a Nutshell

個人的にずっと興味を持って見ていたAcid Houseの流れでGigも興味を持って見ていて（特にScaffoldの部分）、登壇をお願いしました。PetStoreへのチャレンジに関するエントリもリアルタイムに追っかけていましたよ！会場の反応で面白かったのは、Gigのプロダクトへの反応よりも「いちいち命名がかっこよすぎる（アノテーション名までかっこよい）」「ひとりで作ってるのかすげぇ！」の方が盛り上がっていた気がします。

appengineでクーポンサイトを作った話

@najeiraさん
Ust録画

スポーツSNSのLaBOLA（ラボーラ）に実装されたクーポン系の機能の紹介。ですが「資料がnajeiraさんらしく無い！」という話で盛り上がりました。
個人的に「あーなるほど」と思ったのは、チケットの予約に関しては「厳密にはチケット数を超えて予約できてしまう可能性もある」という話で、それはPaypalの方では一旦決済を保留しておき、最終的に決済を確定するしないを決めればいい、的な話でした。なるほど。

ちなみにこのエントリを書いている途中でクーポンサイトを見に行ったら「加圧トレーニング」のクーポンがあったので嫁に紹介しておきました。

Google App Engine 1.4.3 で追加や変更された機能を紹介

1.4.3で追加された機能を15分程で説明する予定でしたが、開催前々日くらいに1.5.0のプレスリリースがあったため、急遽そちらの内容も含めることにしました。appengine ja night開催日付近にsdkのリリースをぶつけてきて慌てさせるGoogle様の手法は相変わらずですね。というか、1.5.0の方が面白そうな機能が多そうなのでそっちがメインになってしまっています。

オフレコでのトークも含まれるため、Ustでは音声が切れている箇所もあると思われます。そこは想像で補完してください。また、うっかりしてWaveを公開状態にしていなかったようです、すいませんでした。

他

@soundTricker318さんがslim3-gwt用のmaven-archetype-pluginを作っている事を教えてもらいました（気づいてませんでしたすいません）。maven+appengine+GWTあたりの調査・試行錯誤はGWT弱者な私ではあれこれめげてしまう事が多かったので大変ありがたいことです。

今回も、TL上では面識があるものの一度も挨拶出来ていない方とご挨拶できました。ありがとうございました。

najeiraさんの資料はコミポというサービスを使ったらしい。

kazunori_279さんのMBPの背中のシールはGelaSkinsというサービスで作れるらしい。

感謝

今回も会場を提供してくださったニフティ株式会社様、会場での案内などをしてくださったスタッフの皆様、大変ありがとうございました。またいつもUst, ピザ＆ビールの面倒を見てくださる@kazunori_279さんありがとうございます＆次回もよろしくお願いいたします。盛り上げてくださった参加者の皆様、スピーカーの皆様も大変ありがとうございました！

次回予告

次回はappengine ja night #16ですが、5/27（金）19:00から、今回と同様ニフティ株式会社様の会場をお借りして開催いたします。既に決まっているコンテンツは以下のとおりです。

あんざいゆきさん: Favapp紹介/GWTのUiBinderとか
某Googler, @IanMLewisさん, @shin1ogawa: Google I/O報告
@bluerabbit777jpさん: FrontEndのキャッシュ機能を利用する方法、使ってみた結果について説明します。

appengine ja night二人目の女性スピーカーの登壇となります。Android女子部の方々も是非参加してみませんか？AppEngineを簡単に使うためのjsonengineというプロダクトを作っているメンバも参加しますので、その場で質問や要望をぶっつけたりする事もできますよ。
そんなカンジで是非ともたくさんの女性の方にも参加していただきたいです。いつもすぐ定員に達してしまうappengine ja nightですが、女性参加者の場合は専用の枠をいくらか用意するつもりですのでatndの定員の心配をしなくても大丈夫です、是非どうぞ！

#appengine 1.4.3の #slim3 単体テスト環境でQueueへのAddで例外が発生する場合

2011-04-03T04:32:00.002+09:00

追記

このエントリを書いた数時間後に、この問題に対する対策が実施されたslim3-1.0.10がリリースされています。このエントリは無視してそれを使いましょう！

Slim3の単体テスト環境で、先週リリースされた Google App Engine SDK 1.4.3を適用するとQueueへTaskをaddする処理で次のような例外が発生します。

java.lang.IllegalArgumentException: Task name does not match expression [a-zA-Z\d-]{1,500}; given taskname: 'null'
 at com.google.appengine.api.taskqueue.TaskHandle.validateTaskName(TaskHandle.java:103)
 at com.google.appengine.api.taskqueue.TaskHandle.(TaskHandle.java:30)
 at com.google.appengine.api.taskqueue.QueueImpl.add(QueueImpl.java:489)

あれこれ見てみた結果、この原因は、1.4.3 からSDK内でtaskqueue#BulkAddのresponseをチェックするようになった、という事かなと思います。

対処方法

Slim3内部でなんとかするしか無いですが、急いでいる方は次のようにすると応急処置になります。

Slim3を使ったプロジェクトに、org.slim3.tester.AppEngineTesterを作成する
Slim3のorg.slim3.tester.AppEngineTesterをそのクラスにまるごとコピーする

次の箇所を探す。

} else if (service.equals(TASKQUEUE_SERVICE) && method.equals(BULK_ADD_METHOD)) {
  TaskQueueBulkAddRequest taskPb = new TaskQueueBulkAddRequest();
  taskPb.mergeFrom(requestBuf);
  TaskQueueBulkAddResponse responsePb = new TaskQueueBulkAddResponse();
  for (int i = 0; i < taskPb.addRequestSize(); i++) {
    tasks.add(taskPb.getAddRequest(i));
    responsePb.addTaskResult();
  }
  return responsePb.toByteArray();

その箇所を次のように変更する。

} else if (service.equals(TASKQUEUE_SERVICE) && method.equals(BULK_ADD_METHOD)) {
  TaskQueueBulkAddRequest taskPb = new TaskQueueBulkAddRequest();
  taskPb.mergeFrom(requestBuf);
  TaskQueueBulkAddResponse responsePb = new TaskQueueBulkAddResponse();
  for (int i = 0; i < taskPb.addRequestSize(); i++) {
    tasks.add(taskPb.getAddRequest(i));
    TaskResult taskResult = new TaskResult();
    taskResult.setChosenTaskName("task" + String.valueOf(System.nanoTime()));
    responsePb.addTaskResult(taskResult);
    // responsePb.addTaskResult();
  }
  return responsePb.toByteArray();

ついでに

どうせSlim3のクラスにパッチをあてるなら…という事で、テスト時の初期ファイルをSlim3の単体テストで使用してテストの処理時間を短縮したい、等考えている人は次の対処をしておくと便利かもしれません。

AppEngineTester#tearDown()内のApiProxy.setDelegate(originalDelegate);となっている箇所の後ろに次の処理を追加する。

if (!AppEngineUtil.isProduction()) {
  ClassLoader loader = loadLibraries();
  Class apiProxyLocalImplClass = loader.loadClass(API_PROXY_LOCAL_IMPL_CLASS_NAME);
  Method stopMethod = apiProxyLocalImplClass.getMethod("stop");
  stopMethod.setAccessible(true);
  stopMethod.invoke(apiProxyLocalImpl);
  ApiProxy.setEnvironmentForCurrentThread(originalEnvironment);
  new File("build/test-classes/WEB-INF/appengine-generated/local_db.bin").delete();
}

単体テスト用の初期データファイルをSlim3の単体テスト実行フォルダ（build/test-classes/WEB-INF/）にコピーしてテストする際は、データストアを正しく終了する処理をしておかないとデータファイルが正しく読めなくなってくる（タイミングによっては問題なく読める時もあるｗ）ための対処です。念には念を入れてlocal_db.binの削除も行っています。この対策を行って、AppEngineTester#setUp()の前に初期データファイルを"build/test-classes/WEB-INF/appengine-generated/local_db.binへコピーしておけばテストのための初期データ作成が高速になります。

クラウド設計のデザインパターン@ITPro #appengine

2011-03-22T23:05:00.000+09:00

本日3/22日より、ITproにてクラウド設計のデザインパターン - クラウド設計のデザインパターンという特集が始まりました。そのシリーズの中のGoogle App Engine編という事で、金曜日までの4回分を執筆させていただきました。

あまりガッツリ開発をする人ではない読者を対象にということで、開発者の方にとってはもの足りない内容かもしれませんが、これからGoogle App Engine向けにシステムを構築しようと考えておられる方にはどんな点で苦労があるのか？などなどと参考にしていただけると思います。いきなり「よっしゃGoogle App Engine向けの案件を開始するぜ」みたいなノリでとっかかると大概痛い目に遭うプラットフォームだと思うので、これから始めようと考えている方には是非4回全部読んでいいただきたいです。

Google App Engineプラットフォームはかなり速い速度で進化し続けているため、もっと開発者向けのものも、今回の連載とは別にそろそろまとめておく必要があるなぁと、執筆を進めながら思ったりしました。

MacOS Xのアップデート後 #appengine javaで開発サーバが動作しない件

2011-03-12T06:05:00.002+09:00

2011-03-11にあったMacOS Xのアップデート実施すると、ローカルで開発サーバが起動できなくなる問題が出るようです。現象としては、開発サーバ（eclipseから起動しても、結局はSDK内のdev_appserverが起動されます）を起動した後、数秒で開発サーバが終了してしまう、という現象です。私が試したときはたまーに少しだけ動作してから落ちる、という場合もありました。下記でも報告されていますし、対策も説明されています。

Issue 4712 - googleappengine - Java for Mac OS X Update Breaks dev_appserver - Project Hosting on Google Code

対策を簡潔に説明しておきます

http://openjdk-osx-build.googlecode.com/files/OpenJDK-1.7-x86_64-20110221.dmg からOpenJDK1.7のイメージを入手する
dmgを開いて、DukeアイコンのInstallation.pkgを実行してOpenJDK1.7をインストールする

これでopenjdk-1.7がインストールされます。此処から先は開発サーバの起動毎に手順があります。

SDK内の`dev_appserver.sh`を直接起動している人

dev_appserver.shをエディタで開いてJAR_FILE=...などの次の行あたりにJAVA_HOME=/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Homeを追加する

eclipseから起動している人

eclipseの設定画面を開く
左のツリーからJava > Installed JREsを選択する
右側のペインでAddをクリックする
Add JREダイアログでMacOS X VMを選択してNextをクリックする
JRE definitionの画面に移るので、JRE HomeのDirectoryボタンをクリックして/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Homeを選択する
JRE nameにopenjdk-1.7-x86_64を入力する

ここまでの手順で、eclipseがOpenJDK1.7を認識出来るようになります。次に、appengineプロジェクトに対して次の設定を行う必要があります。

プロジェクトのプロパティを開き、左のツリーからJava Build Pathを選択する
右側のペインでLibrariesタブを開き、リストの下の方にあるJRE System Library[JVM 1.6.0 (MacOS X Default)]を選択し、Removeをクリックして削除する。
Add Libraryボタンをクリックする
Add LibraryダイアログでJRE System Libraryを選択してNextをクリックする
どのJREを使うか選択する画面になるのでAlternate JREを選択し、先の手順でEclipseに認識させたopenjdk-1.7-x86_64を選択する
プロジェクトのLibraryにopenjdkが追加される。

これらの手順で開発サーバが起動できるようになります。

追記

上記手順で開発サーバを起動したときにjavax.net.ssl.SSLExceptionが発生するのが気になる場合は、次の手順で解消できます。

cd /Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home/jre/lib/security
cp /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts .

2011-03-15追記

AppleのJDKを入れ直すという、もっと簡単そうな手順も紹介されています。

MacOS XのJavaアップデートとAppEngine SDKの問題に対処した - Basic

空うさぎが Lingr にも対応してより便利になった #sora_usagi

2011-02-26T04:16:00.000+09:00

これまでに何度も紹介してきた、@aqubiが作っている Twitter/FriendFeed/Google Buzz/RSSをストリーム受信・強力通知するクライアントの空うさぎの新しいバージョンがリリースされました。今年は「「これなしでは生きていけない」ウェブ・サービスやガジェット」を書いていませんが、空うさぎは私にとっては相変わらず最も重要なツールで、キーワードやサービスごとに通知の種類を設定できて、大量に流れてくる情報を効率よく処理するために強力なクライアントです。

今回のリリースでlingr.comに参加しているroomの更新通知、投稿ができるようになります。

設定画面でユーザ名とパスワードを入力します。アプリにサービスのパスワードを入れとか今時のアプリにはあり得ないのですが、lingr.comがOAuth対応すれば空うさぎもきっとすぐに対応してくれます。

通知用のフィルタはLingrの全room用にひとつ作ってもよいし、roomごとに設定したい場合は図のようにMatch String項目に^\[room名\]と設定します。私は見落としたくないroom用にクリックしないと閉じない通知フィルタを、それ以外は自動的に閉じる通知（サービスにLingrを設定しただけのフィルタ）を設定して、room用の通知フィルタの下にLingr全体の通知フィルタ、という順に設定しています（フィルタに登録された上から順に適用されます）。

また、Lingrには連続して投稿する事も多いので、投稿後に入力ウインドウが自動的に閉じてしまわないように設定してます。ただし、この動作は別のroomへの誤爆を招きやすいかもしれないので注意が必要かも。

空うさぎは色々と設定も多くて複雑に見えるのでマニアックなカンジがしますが、そんなにユーザ数も多くないしこれからもマニアック路線で突き進むと思われます。キーバインドがカスタマイズ出来るのでhjklバインドにしたり、readitlater対応なんかも便利です。GmailもAtomフィードで取れて便利。

Google API Expert(Google App Engine)に選任していただきました

2011-02-24T23:55:00.016+09:00

Googlerとなってからはぐれメタル並の出現率となった@kazunori_279さんの推薦により、Google API Expoertとして活動させていただくことになりました。

Google App Engineに関する情報発信
初心者向けの普及活動
appengine ja night等の濃いコミュニティへの協力

…などなどの活動はこれまでどおり行いつつ、これまでよりもGooglerとの接続ができるかなと思います。

また、個人的には Google Apps関連APIやその他のGoogle APIも色々と触っているので、他のAPIのExpertの方々とも連動してAppEngine以外のAPIを使うデベロッパーの方々ともコラボできるようなハンズオン・ハッカソン・勉強会もやっていきたいと考えています。今後とも宜しくお願いいたします！

Google Apps Script勉強会に参加しました #gasja

2011-02-21T01:47:00.002+09:00

@atusi さん主催のGoogle Apps Script勉強会#2 に参加しました。

第一回の時とは違い、半分くらいの人が「Google Apps Scriptを触ったことがある！」という状態でビックリです。日本でそんなにGASを触っている人がいるなんて…。

発表資料など

@webos_goodiesさんがAWSのROUTE53とSpreadsheetの連携アプリの紹介を、@atusiさんがGASの概要の説明をされました。

@webos_goodiesさん - GASでアプリ作ってみた
@atusiさん - Google Apps Script #2

ハカソン

今回はハッカソン主体だったので、自分も何か作ろうと作業しました。お題は「会社の勤怠シートの入力を補助するツール」です。私は勤怠シートを月末にまとめて記入するずぼらなタイプで、毎月入力が面倒です。そこで、下記の機能を持ったスクリプトを作ることにしました。

入力する勤怠の対象月を入力する
日本の祝日を取得する
自分の予定一覧を取得する
土日祝以外は基本となる時刻を固定で入力済みにし、自分の予定を補足情報として対象日に表示する

結局作業時間の範囲内では表示に必要なデータの取得までしかできていなかったのですが、ログに出力した内容を表示しつつ「取得まで出来たんだぜ」とか成果発表をしました。

帰宅後に少し作業して表示部分もできたので貼っておきます。アクティブシートにがっつり上書きするので、興味があるなどで試される方は新規のシートで試してください。

新規シートを作ってスクリプトエディタを起動し、コピペでペタっと貼ってシートを再読込すると「gasja2」というメニューが追加されます。その下の「勤怠入力補助」をクリックします。

いくつか入力項目をもったダイアログが表示されるので、2011/02のような形式で年月を入力してOKをクリックします（最初はカレンダーへのアクセスを許可を求めるダイアログが表示されるので、許可する必要があります）。

対象月の勤怠表の雛形が表示されます。土日祝以外はデフォルトの勤務時刻が入力され、土日祝は日付列の背景色が変わります。祝日情報は日付列のコメントに設定されます。また、シート所有者のカレンダー情報は2列目に表示されます。

気になった

今回も新たに勉強になったことがたくさんありましたが、その中でも特に気になった物。

Rage#setBackgroundColor()
Range#setNumberFormat()
Sheet#setColumnWidth()

上記のような、スタイルの設定を行う機能が存在しているということに驚いた。確かgoogle-data-apiのSpreadsheet APIにはセルのスタイルを操作するAPIが無かった記憶があったんですよね。GASは必ずGAS-GData-(Spreadsheet等)という経路でAPIを実行すると思っていたので、実はそれ以外にGAS-(Spreadsheet等)のような経路があるのか？等と思いました。それか、GDataにスタイル操作系のAPIが追加されたか、追加される前兆か？…と気になりました。

#slim3 1.0.6 のSimpleControllerを使った場合のテスト方法 #appengine

2010-12-26T19:22:00.001+09:00

先日、slim3-1.0.6がリリースされました。たくさん機能追加がありますが、最近の自分的に嬉しい機能のひとつにController内でInputStreamが使えるissue62への対応があります。

Support for Controller#createRequestHandler():
http://code.google.com/p/slim3/issues/detail?id=62

この機能を使用する際のテストケースの書き方の例を書いておこうと思います。あと、ついでにMetaクラスにJson->Model、Model->Jsonを行うユーティリティメソッドが追加されているのでそれも使っています。@takawitterさんの仕事です、ありがとうございます、便利です。

まずはController

Httpメソッドとリクエストパラメータによって追加・修正・削除と1件返却、リスト返却を実装しているだけのシンプルなものです。ポイントはControllerではなくSimpleControllerクラスを継承している点と、asString()は使わずrequest.getParameter()でパラメータを取得するという点と、ModelMetaクラスのJson用ユーティリティメソッドが便利という点です。

ControllerをテストするControllerTest

ServletInputStreamを実装したJsonInputStreamというクラスを用意し、MockHttpServletRequest#setInputStream()に設定することでControllerへのpayloadを設定しています。

issue62とJson用ユーティリティメソッドのおかげでjsonをやりとりするControllerが一気に作り易くなって、かなーり助かります。ただ、jsonArrayToModels()やmodelsToJsonArray()が無いのがちょっと勿体無いかな？

closure-libraryをWebStormで使う

2010-12-26T05:19:00.002+09:00

最近closure-libraryの勉強をしているんだけど、WebStormでキレイに補完をしたりする設定方法のメモ。
closure-libraryというよりはWebStormの話だけど、WebStormって全プロジェクトで参照できる共通ライブラリって登録できないのかな？方法を知っている人がいれば教えてください。

以下のようなフォルダ構成を想定。

プロジェクトのルートフォルダ
- closure-library（ここがclosure-libraryのroot）
  - closure
    - goog
    - bin
    - css
- src（ここに自分のjsとかcssを配置）

WebStormで上記のプロジェクトのルートフォルダをOpen Directory
PreferncesをひらいてProject SettingsセクションのDirectoriesを選択
一番右側の領域でproject/closure-library/closureを選択してResource Rootをクリック（真ん中の領域のResource rootsにclosure-library/closureが追加される）
同様にしてsrcフォルダもResource Rootとして追加する

Closure LibraryはJsDocsもかなり書かれているから、メソッドの補完をした時のパラメータなんかもキレイに参照できる

WebStormの機能として知らなかった機能だけど、シングルクオート内でも補完が効いてびっくりした。キャメルケースマッチがあると安心ですね。キャメルケースマッチが無いクソIDEだとイライラしますもんね！

Titaniumのコード補完をWebStromで

2010-12-02T04:16:00.000+09:00

最近Titaniumを使い始めたんだけど、コード補完するための*.jsがどこにあるのかよくわからなかった。いろいろ調べていると、

http://developer.appcelerator.com/apidoc/mobile/1.4/api.jsonで公式のTitanium.*の定義情報が配布されている
上記のapi.jsonを読んでJavaScriptの定義ファイルを出力してくれるモジュール(JavaScript)がhttps://github.com/netpro2k/TiAutocompleteで配布されている

という事がわかった。自分の場合は以下のようにしました。

$ git clone git://github.com/appcelerator/titanium_mobile.git
$ wget http://developer.appcelerator.com/apidoc/mobile/1.4/api.json
$ node TiAutocomplete/tiDocs.js > Titanium.js
作成されたTitanium.jsを、Titaniumプロジェクトの直下（Resoucesと同じレベル、Resources配下ではない）へコピー。

WebStormではTitanium用のプロジェクトをルートフォルダにしている状態です。これでTitanium.*が補完されて大変便利になりました。

#slim3 のテスト環境で投入したデータを削除せずファイルに保存する #appengine

2010-10-15T00:13:00.001+09:00

AppEngine/Javaで、開発サーバで実行するときのテストデータの初期状態を作っておきたい時、私はよくAppEngine SDKのLocalServiceTestHelperを使ってテスト環境を作成してデータ投入し、そこで作成したファイル（local_db.bin）をwar/WEB-INF/appengine-generatedフォルダにコピーしていました。これと同じことをSlim3のAppEngineTesterを使ってできないかなー？と思って試してみました。

Slim3のAppEngineTester#tearDown()はテスト中に投入されたデータは全部消してしまう（それが便利なわけですが）仕様です。これはtearDown()をオーバーライドして削除処理をしないようにすれば回避できます。
それだけだと良いんですが、環境終了時にApiProxyLocalImpl#stop()を呼んでいません。これが無いとデータがlocal_db.binに永続化されないので、ファイルが作成できません。そこで次のようなAppEngineTesterのサブクラスを作って使うことにしました。テスト中に投入したデータのクリア処理を外し、各LocalServiceクラスを停止するためのApiProxyLocalImpl#stop()を実行するようにしただけです。

以下のように使うことになります。

テストデータ投入前に、上記のAppEngineTesterのサブクラスをインスタンス化し、setUp()を実行する
開発サーバで実行するときのアプリケーションIDを返すApiProxy.EnvironmentのインスタンスをApiProxy#setEnvironmentForCurrentThread()で設定する
テストデータを投入する
上記のAppEngineTesterのサブクラスのオブジェクトのtearDown()を実行する
build/test-classes/WEB-INF/appengine-generated/local_db.binをwar/WEB-INF/appengine-generated/local_db.binにコピーする

データファイルに保存されるエンティティにはアプリケーションIDも合わせて永続化されるので、データ投入時と開発サーバ実行時で同じになる必要がある点に注意が必要です。

404 shin1のつぶやき ないわー Not Found