2013年4月30日火曜日

AngularJS date filterで日付がずれる

AngularJSでDate Filterを使うと日付が一日ずれる。
例えば


{{ '2012-04-01' | date:'d MMM yyyy' }} convert -> 31 Mar 2012

このように日付をフィルターした場合、UTCに変換され、前日の日付となってしまう。
この現象はバージョン1.1.2で修正されて、ローカルのタイムゾーンを使用するようになる。

しかしこれは今のところunstableなバージョンなので、アップデートしないで、保存時にUTC->JSTへ再変換することで対応した。


var date = new Date($scope.transDate);
date.setHours(date.getHours() + 9);
$scope.transDate = date;


AngularJSのバージョンアップ時に再度確認すること。

2013年4月25日木曜日

アジャイルサムライ読書会松山道場 #14


アジャイルサムライ読書会松山道場に参加した。
今回は、シトラス・スペース・カンパニーでの開催。シトラスさんには初めてお邪魔させてもらいましたが、いいところです。私はコーヒーを飲む方なので、コーヒーの美味しいお店は大歓迎。

今回は「第11章、現場の状況を目に見えるようにする」。
アジャイルに限らず、混乱している現場ではまずここに手をつけるべき。以前は見える化にはツールを使っていたのだが、最近は付箋紙などに書いて壁に貼る、アナログ手法がいいのでは。

ツールで行っていると外部公開できるようにすれば、社外での閲覧も可能になり便利だが、アナログ方式だどPCやタブレットなどなくてもみる事ができる。見やすい事が大切だと思う。

しかし、手書きだと字が汚いし、漢字も忘れてしまって分かりずらいのだが、汚いのは味だ!、漢字が書けなければひらがなでいいだろ。
と開き直れるようになった。

用語の定義と確認も大切だ。同じ用語でも業界によって意味が変わってくることもあるから確認しよう。読んだことはないが、エリック・エヴァンスの「ドメイン駆動設計」がオススメみたいだ。

平日開催だったので、参加がちょっと少なかったし、メンバーの平均年齢がちょっと高かったようだ。

次回以降はアジャイルサムライの筆者が「問答無用で実践すべき」と思うテーマなので、興味があれば参加してみてください。

bundlerでNetwork error



Ruby on Railを使ってRestfulなサービスを作ろうとしている。
しかし今回も環境構築でハマってしまった。アプリの依存性をチェックして必要なパッケージをインストールしてくれるbundlerがエラーとなり動かない。

bundle install
Fetching source index from https://rubygems.org/
Resolving dependencies...
Network error while fetching
https://rubygems.org/quick/Marshal.4.8/rails-4.0.0.beta1.gemspec.rz


これもproxy環境での問題だ。どうもbundlerにはproxy設定ができないようなのでローカルにある情報でチェックさせる。

bundle install --local
Resolving dependencies...
Could not find gem 'rails (= 4.0.0.beta1) x86-mingw32' in the gems available on
this machine.

--localオプションをつけるといいそうです。


rails new foo --skip-bundle

作成時必ずエラーとなってしまうので、スキップしよう。

DevLOVE四国

4/20土曜日にDevLOVE四国に参加した。DevLOVEとは「開発の楽しさを再発見し、広めて、現場を前進させる」ために様々なコミュニティを融合させて、技術者同士の出会い、学べる機会を提供するものだ。

今回はDevLOVEが四国に初上陸するので高松市まで行ってきた。松山市からでも高速道路を使えば高松までは2時間ぐらいだ。せっかくなので早起きしてうどんも食べに行った。

午後1時開始で、開催の挨拶のあと、「アジャイル開発体験」として、ワークショップがあった。3〜4人のチームでペーパータワーを作成し、高さを競うものだ。以前スクラムのワークショップでマシュマロタワーを作ったが、今回はペーパータワーだ。

物理的、時間的制約下でどのようなタワーを建てることができるか。3回チャレンジしたのだが、なんと1回目で一位の71cmの記録を作ってしまった。何気なくテープで接着した台座が功を奏したのか、安定して立っていた。

2回目は失敗してしまい記録は0cmだったが、3回目はなんと全体でも最高の101cmのタワーを建てることができた。1回目に記録がでたので、以後余裕をもって出来たのが勝因かもしれない。開発も同じで常に動くものがあると、いい感じで開発が続けられる。


その後、HTML5の話。これはブラウザだけで、凄いグラフィックのゲームが作れることに感心、HTML5はWebの可能性を広げたのを実感した。

Google Developer Expertの方はAndroidの今後について数字で説明された。でもプレゼン前半の個人的な内容を説明されていたのが面白かった。東京からのUターンで、どちらかと言えば、後ろ向きな起業だったそう。なんか、「後ろ向きな起業」と言うところが相通じるところがあるのだが...
オラクルJava エバンジェリストの方はさすがに講演がうまかった。多いと年間200回ぐらい講演しているらしく、話も分かりやすく、GlassFishってそんなにいいのか、と引き込まれた。

続いて、私です。今回愛媛県枠で依頼を受けたと思っていたのだが、なんと四国枠として発表。アジャイル導入について話をした。
このように人前で話すことなどないので、緊張し、しどろもどろになった。事前の練習では講演時間ぴったりだったが、次々と話したいことが浮かんできて、付け足していると、後半部分が説明できなくなった。
正直他の方と比べて差があったので、次回このような機会があればリベンジしていきたい。


その後LT、クロージングと進んだが、このあたりは安堵感いっぱいで、良く聞けてなかった。ただ、GDS Shikokuの方がグーグルグラスを購入されていることは覚えている。羨ましい。一度使ってみたい。

DevLOVE終了後、懇親会があり、参加した方々からたくさんの話ができてよかった。同年代の人達とはマニアックな昔話など一人で盛り上がった。

このような機会を与えてくださった関係者の方々ありがとうございました。準備、運営等お疲れさまでした。





2013年4月6日土曜日

Google App EngineでLocalServiceTestHelperを使用した時のタイムゾーン

Google App Engine(GAE)でアプリを作成していて、いいなと思うことはローカル環境でのテスト環境を提供してくれていることだ。

先日、記したJDOを使ってオブジェクトの永続化をする場合でも、ちゃんテストユーティリティが用意されている。LocalServiceTestHelperを使えばローカルでユニットテストができる。


public class LocalDatastoreTest {

    private final LocalServiceTestHelper helper =
        new LocalServiceTestHelper(new LocalDatastoreServiceTestConfig());

    @Before
    public void setUp() {
        helper.setUp();
    }

    @After
    public void tearDown() {
        helper.tearDown();
    }

 }

マニュアルに書いてある通り。Helperの開始処理と終了処理を行うだけで、ローカル環境でユニットテストができる。なので、データベースとか用意しないでいいのでお手軽
だ。

しかし、このLocalServiceTestHelperを使うとデフォルトのタイムゾーンがUTCに設定される。なので、日付関連のプロパティを持っていたり、ロジックを書いている場合はテストエラーになるので注意が必要である。


    @Before
    public void setUp() {
        helper.setTimeZone(TimeZone.getTimeZone("Asia/Tokyo"));
        helper.setUp();
    }

 }

Helperにタイムゾーンの設定をすると日本時間でテストできる。Javaのタイムゾーン設定は初めてだったので、調べてしまった。

2013年4月5日金曜日

Gsonでjava.lang.StackOverflowError

Google App Engine(GAE)での永続化はJDO(Java Data Objects)で行われる。作成したモデルはPOJOとして使えるのでモデルがきれいに使える。オブジェクト永続化の情報はアノテーションを使って指定する。

親オブジェクトが子オブジェクトを複数もつようなモデルを永続化するときは、アノテーションで1対Nの関係を指定しなければならない。


//親クラス
@PersistenceCapable
public class Parent {

 @PrimaryKey
 @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
 @Extension(vendorName="datanucleus", key="gae.pk-id", value="true")
 private Long keyId;
 
 @Persistent(mappedBy = "parent")
 private List children;

 public Parent()
 {
 }
}

//子クラス
@PersistenceCapable
public class Child {

 @PrimaryKey
        @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
 private Key key;
  
 @Persistent
 private Parent parent;
 
 public Child()
 {  
 }
}


コードで表すとこうなる。Childクラスには親インスタンスをもつプロパティを作り、関係性を持たせる。
これをJDOで永続化すると1対Nの関係性をもつオブジェクトがそのまま保持される。

Webアプリの通信をJSONで行う場合、この親オブジェクトからJSON化していけば、綺麗にシリアライズされるはず。そう思ってこんなコードを書いた。ライブラリはGsonを使ってみた。


Gson gson = new Gson();
gson.toJson(parent);


シンプルだ。これでJSON化できるのだから簡単だ。
と思ったら、java.lang.StackOverflowErrorで落ちた。

もう、分かってると思うが、Gsonは親クラスをシリアライズした後、子クラスをシリアライズする。そのとき、マッピング用に指定している親オブジェクトもシリアライズしてしまう。するとまた親から子に向けてシリアライズを行い、永久ループに入ってしまう。

分かると単純なんだが、原因が分かるのにちょっと時間を使った。以前Hibernateでも同じように悩んだ記憶がある。同じ事を繰り返さないように記事にしておいた。

2013年4月4日木曜日

MongoLabからGAEへ

フロントエンドの開発はAngularJSで、バックエンドはMongoLabを使っていた。MongoLabはNo SQLのMongoDBをホスティングサービスしていて、無料で500MBまで使用できるサイトだ。

RESTfulなAPIをサポートしているので、フロントエンドとバックエンド間をJSONで通信するアプリの場合、MongoDBのようなNo SQLだとブラウザからデータをポストするだけで、簡単にデータを永続化できる。

とりあえずフロントエンドを作ってみて、永続化させたい部分をDBに入れる。これだけで、ちょっとしたWebアプリが作成できる。

ただ、残念なことにMongoLabはパフォーマンスがちょっといけてないので、本当に使いたいのであればバックエンドを別に作った方がいい。

今回AngularJSで作ったものを一段グレードアップする為に、Google App Engineを使うことにした。Java+JDOでデータの永続化に挑戦してみる。GAEは料金体系がよくわからないので、使用したことはなかったが、いい機会だ。

パフォーマンスは良くなるのであろうか。楽しみだ。



2013年4月1日月曜日

シマリスScrum

名古屋アジャイル勉強会スタッフ@you_and_iさんによるスクラムワークショップに参加した。
じつはスクラムは体験したことがなかったので、今回が初スクラムだった。始めにチームビルディングでマシュマロタワーチャレンジを行った。これが難しいが、面白かった。2回行ったのだが、1回目は時間内に完成しなかったので、記録は実質0cmだった。だが2回目は心を入れ替えて、アジャイル的に進めて58cmだった。


これが完成したマシュマロタワー。アジャイル的とは最後にマシュマロを載せるのではなく、始めからマシュマロを載せておき、少しづつ改良していく方法だ。2回目はこれでうまくいった。ちなみに世界記録は98cmらしい。
建築とか勉強している人とやってみたい。有利な構造とかあるのではないか。

一通りスクラムの説明を受けたあと、ワークショップで実践。今回のお題は「動物園を
つくる。」
ルールとして動物園に動物を置くためには、それに応じた折鶴を折る必要がある。もしパンダを置きたければ折鶴を4個折る必要がある。トラなら1個。こんな感じで自分の動物園に動物を増やす為には、折鶴を折る作業が必要になる。この作業をうまくマネージメントできるようにスクラムを使う。

しかし、一番の問題は私は折り紙したことがないことだった。チームの中で折れないのは自分一人なので、空き時間をみつけて必死になって勉強したが、どうしても覚えられない。

スプリント1では成果が0であった。これが本当のシステム開発ならば1イテレーションで1つも機能が完成しなかったこととなり、えらいことだ。

その後、見かねたメンバーが助けてくれ、なんとか折れるようになり最後のスプリントでは1.5個折れるようになった。大きな進歩だ。アジャイル的にはベロシティがアップしたのだ。


これが我々の動物園だ。折り紙がきつかった。


これが別チームの動物園。

最後に振り返りを行い、今後に生かせること、問題点、トライしたいことなど話し合い終了。
シマリスScrumワークショップ面白かった。シマリスはリスの一種だったのか!