2011年10月 1日 22:00

indexの更新遅延を考慮した実装を行う

実はバリデータ関係でちょっと問題があったりします
これは会議室の名前の重複をチェックするバリデータですが、appengine固有の問題により正常に動きません。
ユニットテストでも問題ないため最悪本番稼動した後に発覚する一番質の悪いバグですね。これに関してはまた別の機会に書きます。
(これはappengineで何らかのサービスを運営してしてないと気づかないかなぁと)

前回のブログでこんなことを書いてましたが解答編です。タイトルにもあるように、インデックスの更新遅延が原因でバリデータは正常に動きません。(appengineじゃなかったらこういう問題はおきないんですがねw)

Entity自体はすぐにDatastoreに反映されるのですが、indexの更新には若干ラグがあります。厳密に調べたことはありませんがひどい時で1?2時間くらいindexが更新されなかったことがあります。
検索系は多少古い検索結果が返ってくることを許容することでいけますが、データの整合性に関してはそうもいきません。

例えば今回の場合だと登録するタイミングによっては同一名の会議室が存在する可能性があります。

よってindexやqureyを利用しない重複チェックを使用することになります。解決方法としては2つあります

1. keyに会議室の名前を入れる

keyはuniqueなのでこれがベストですね

2. Datastore.putUniqueValueを利用する

keyを利用するのがベストなんですが、運用中で容易にkeyを変えられないという場合があります。また、key以外の要素でもuniqueな要素を持たせたいというのはあると思います。
そういう場合はSlim3のDatastore.putUniqueValueを利用するのがいいです

これはソースを見ててたまたま見つけたやつなんですが、uniqueな名前を管理するためのEntityを1つ作ってしまうというやり方です。valueをDatastoreのkeyにしているので原理的には1と全く同じです。

サンプルコード

import static org.hamcrest.Matchers.*;
import static org.junit.Assert.*;

import org.junit.Test;
import org.slim3.datastore.Datastore;
import org.slim3.tester.AppEngineTestCase;

public class PutUniqueValueTest extends AppEngineTestCase{

    private static final String UNIQUE_INDEX_NAME = "ConferenceRoomName";

    @Test
    public void test() throws Exception {
        boolean actual1 = Datastore.putUniqueValue(UNIQUE_INDEX_NAME, "会議室A");
        assertThat(actual1, is(true));

        // 重複登録しようとするとfalseが返却される
        boolean actual2 = Datastore.putUniqueValue(UNIQUE_INDEX_NAME, "会議室A");
        assertThat(actual2, is(false));

        assertThat(tester.count(UNIQUE_INDEX_NAME), is(1));
    }

}

2011年9月26日 22:23

TDD Boot Camp 札幌 2.1に参加してきました

ブログを書くまでがTDDBCです(挨拶)

TDD Boot Camp 札幌 2.1に参加してきました

福岡、東京1.5に続いて3回目の参加。
丁度この時期はまだ暑いだろうから避暑も兼ねていたのですが、東京も以外に涼しかったらしいorz
(ちなみに札幌はストーブをつけるレベルの寒さでしたが)

詳しいまとめサイト


思い出しレベルで記載

9/23(金)
夕方くらいの飛行機で札幌入り。
札幌駅に降りた辺りで自分だけ半袖だったので奇異の目で見られました(吐血)
@shuji_w6eさんが開催してたJenkins勉強会に懇親会から参加。
飛行機のチケットとるときのこれの開催を知ってればJenkins勉強会にも参加してたのにorz

9/24(土)
TDDBC本番。JavaのTAとして参加。
4人チームでしたが、自分は基本的にコーディングをせずアドバイスやリファクタリングに徹してました。
(事前に予習をしてて完成形が分かっていたため)

ちなみにこれが自分たちのチームの成果物です

実はバリデータ関係でちょっと問題があったりします
これは会議室の名前の重複をチェックするバリデータですが、appengine固有の問題により正常に動きません。
ユニットテストでも問題ないため最悪本番稼動した後に発覚する一番質の悪いバグですね。これに関してはまた別の機会に書きます。
(これはappengineで何らかのサービスを運営してしてないと気づかないかなぁと)

ついでにLTもさせてもらいました。

僕が作っているjubeat++を元にappengineやslim3などの紹介をしています。
TDDBCなのにテスト成分がほとんどないことに終わった後に気づいた。(先週社内勉強会で発表した時の資料をベースにしてるしw)

資料

録画もあります
http://www.ustream.tv/recorded/17463733 (34:00くらいから)

余談ですが、僕が初めて参加した勉強会(appengine ja night #8)で@shuji_w6eさんがScenic3とPirkaEngineの紹介をしていました。そして今度は僕が@shuji_w6eさんが主催する勉強会でScenic3とPirkaEngineの活用事例を紹介するというのは個人的に非常に感慨深いものがありました(笑)

9/25(日)
@shuji_w6eさんに連れられて札幌観光をしていました。味噌ラーメンとスープカレーおいしゅうございました
 

9/26(月)
有給をとってお昼くらいの飛行機に乗って東京の家に帰宅。
帰りの飛行機は爆睡でしたw


Javaに関してはある程度こなれた感があるため、次にTDDBCに参加する時はJavaScriptで参加したいなぁ・・・

2011年9月17日 18:57

appengineの料金体系変更に伴うjubeat++の運用に関して

特に変更はありません( ´∀`)

以降分かる人ネタ

旧料金体系
旧料金体系

新料金体系
新料金体系


新料金体系でも無料枠内に収まっているので余裕で今まで通りです。
PVはだいたい30~40/日くらいなので今まで通りなら問題ないかと。


ちなみにこの辺に書かれていたチューニングポイントに関しては元から行っていたため、新料金体系のためだけのコード変更は特に行っていません

せいぜいバラバラに動いていた複数のcronを同じ時間に動かすことで1つのインスタンスを効率良く使ったり、TaskQueueの同時実行数を1にしたくらいですかね。


ちなみにjubeat++のアーキテクチャについてはTDDBC 札幌2.1でも話させて貰う予定です(宣伝)

「僕と契約して札幌に行こうよ!」

2011年7月12日 21:33

TDD Boot Camp 東京1.5に参加してきました #tddbc

http://atnd.org/events/16311

3月の福岡に続いて2回目の参加。
一応経験者ということで今回はJavaのサポートメンバーに立候補しました。

周りが優秀すぎて特にサポートすることもなかったですがね!w

自分のペアプロの相手はdaichamさんでした。前回はこっちが主体的になりすぎで今回は逆にサポートに徹しすぎてあまりバランスがとれてなかったです。ペアプロって難しいですね(´・ω・`)


詳しいことはこの辺にまとまっています
ustで最後の質問コーナーで僕が出演しています。(声だけですが)
見るなよ!絶対に見るなよ!(上島風)

今はQUnitを勉強中なので次回参加するとしたらJavaScriptで参加したいところ