2016-12-24

GWT を使ってみて感じたこと

※この記事は「AltPlus Advent Calendar 2016」の24日目の記事です。

こんにちは、オルトプラスのミーです。
日本語を勉強中です。わかりにくいところがあるかもしれませんが、よろしくお願いします。

今日は「Google Web Toolkit （以下、GWT）」というフレームワークについて書こうと思います。

大学時代にGWTを半年ほど使っていました。詳しくはわかりませんが、使ってみた感想を書きます。

GWTとは

http://www.gwtproject.org/overview.html

GWT is a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript. GWT is used by many products at Google, including AdWords, AdSense, Flights, Hotel Finder, Offers, Wallet, Blogger. It’s open source, completely free, and used by thousands of developers around the world.

詳細は上記ページを参考にしていただければわかると思いますが、簡単に言うとJavaを使って、あまりウェブサイトの開発知識がなくても（Javascriptとか）、ウェブサイトを作れるようにサポートしてくれるフレームワークです。

GWTを使う理由は何ですか？

自分の考えですが、以下の理由があります。

1. Javaでウェブ開発してみたい

自分のイメージですが、簡単なウェブページを開発する場合、PHPのようなオブジェクト指向的でない書き方のできる言語を使っても大丈夫です。リクエストを受けてページを返すのに十分で、オブジェクトをあまり導入しなくてもいいかもしれません。

私は大学時代にはウェブ開発より、ミニゲームの開発をする機会が多くありました。ミニゲームの世界では、何でもオブジェクトなので、オブジェクト指向言語のJavaを使っていました。それを基にしてウェブ開発する時にもJavaでしてみたかったのです。ウェブはミニゲームのように、なんでもオブジェクト化できれば面白いなと思いました。

2. Googleのプロダクトと連携しやすい

https://cloud.google.com/appengine/docs?hl=ja

GWTの開発言語はJavaなので、開発アプリはJavaを使ういろいろなGoogleのプロダクトを導入しやすいと思います。
大学時代の自分のプロジェクトではGoogle App Engineを使いました。
Googleのプロダクトを使ってアプリを開発したい場合、Google Mapsによる地図アプリ開発などはGWTを使うといいかもしれません。

次に、GWTを使ってみたいと思っている方は、以下のところに気をつけてください。

プログラマー入門の人にとってちょっと学びにくい

一つ目の理由は、GWTはJavaを使っています。Javaのsyntaxルールは少なくなくて、GWTもそのルールを守らないといけません。サーバーとクライアントでやり取りするデータのタイプを定義しないといけません。具体的にタイプ定義するとコードがわかりやすくなりますが、プログラマー入門の人にとって、ページを表示できるようになるまで普通より手間がかかるかもしれません。

2つ目の理由は、開発ツールが複雑ということです。Javaの開発では、重い開発環境のEclipseなどを使わないといけないでしょう。LaravelとPHPなら、エディタのsublime, atomなら軽くてよいと思います。入門者にとって、普通より開発環境を理解する時間がかかると思います。

サポートコミュニティーがまだ多くない

開発していた時に、デバッグや困る時にGoogleで検索してみましたが、結果の件数がまだちょっと少ないと思いました。

おわりに

GWTを使ってみて感じたことは以上になります。
次回は大学時代にミニゲーム開発で使っていたフレームワークの「Libgdx」を紹介したいと思います。

2016-12-23

通信量を減らすビット演算

※この記事は「AltPlus Advent Calendar 2016」の19日目の記事です。こんにちは。オルトプラスの福原です。

昨今誰でも簡単にアプリが作れる環境が整い、手軽に開発も出来るようになってきました。中でもリアルタイムで通信を行い複数人数で遊ぶアプリも増えてきています。ここで注目しておきたいのは通信量です。いくらネットが普及し光回線設備が整ったとしても無制限ではありません。一度に送受信できる量の限界、光の速度の限界は当然あります。今現在、スマートフォンではキャリアが設けた通信量の制限にすぐ到達してしまわないように配慮する必要が出てきます。そして運営している側から見た場合、サーバーのデータ転送量を極力下げコストを抑えたいところでもあります。

どのような方法があるか

通信する量を減らすかまたは極力通信を行わなくても済むような設計が必要になると思います。今回は前者の量を減らすという部分について述べてみます。お手軽な方法はデータ(jsonなど)を圧縮して送る方法ではありますが、今回はもっと根本的な部分から見てみることにします。ほぼ全ての言語で利用可能なビット演算^1です。

1 バイトの中身

ビット番号	7	6	5	4	3	2	1	0
対応値	128	64	32	16	8	4	2	1
値	0	0	0	0	1	1	1	0

上記は整数 14 を表します。

例１

４人でデータの送受信を行ったケースを見てみます。この例ではサーバーで４人のマップ上の X 座標、Y 座標を収集しを４人へ送ることとします。

X 座標を float 型 4 バイト y 座標を float 型 4 バイト

１回の送信で

8 bytes x 4 = 32 bytes

４人分で 32 bytes になります。

これを JSON 表記した場合^2

{
  "player1" : { "x" : 350.48, "y" : 190.66 },
  "player2" : { "x" : 80.21, "y" : 200.34 },
  "player3" : { "x" : 128.93, "y" : 260.66 },
  "player4" : { "x" : 288.19, "y" : 90.12 }
}

この例では大体の位置が分れば良い前提として、左上からマップを 16x16 のブロックで分割しておき、対応する座標から対象となるブロックを xy の座標としてしまいます。

{
  "player1_xy" : 107
}

このように他のユーザーの座標も含めると以下のようになります。

{
  "player1_xy" : 107,
  "player2_xy" : 119,
  "player3_xy" : 187,
  "player4_xy" : 76,
}

このデータをさらに短くするためビット演算を使うと以下のように一つの整数にすることができます。

なぜ 1803008844 になったのかと言うと、４つの値をビット演算を用いて１つの 32bit 整数へ入れたため

01101011 （107） << 24 bit 左へシフト = 1795162112
01110111 （119） << 16 bit 左へシフト = 7798784
10111011 （187） << 8 bit 左へシフト = 47872
01001100 （76） はそのまま

ビット位置	24	16	8	0
元の値	107	119	187	76
1進数	01101011	01110111	10111011	01001100
ビット数	8bit	8bit	8bit	8bit

それぞれを左へシフトすることで 01101011 01110111 10111011 01001100 = 計 32 bit 整数 = 1803008844 となります。

結果を JSON 表記した場合[^3]

{
  "player_positions" : 1803008844
}

４人の座標データが一つの 32bit 整数にまとまりました。この整数を逆に右シフトなどさせてそれぞれのプレイヤーの座標を取り出すことになります。

まとめ

最初の 32bit float 型 8 個のものより、 1/8 ほど通信量を減らせたと言えます。特にリアルタイムで何度も送受信するケースでは重宝してくるでしょう。極端な例でしたが適切な要所で扱えればかなりの量が節約できてしまうビット演算でした。

では今回はこの辺りでまた次の機会に。

2016-12-23

2016年有馬記念の予想

AdventCalendar

※この記事は「AltPlus Advent Calendar 2016」の23日目の記事です。

こんにちはこんにちは、shohojiです。

今週末は競馬ファンお馴染みのG1レース「有馬記念」が開催されますね。
有馬記念は、今年活躍した馬たちが一堂に会し、今年最後の活躍馬を決めるグランプリレースとも呼ばれる大きなレースです。

ダービーズキングの伝説やダービーゲート、ダービーロードなど、数々の競馬ゲームのを企画や開発をしてきたこの私が、そんなビッグレースがあるのに無視できるはずはありませんので・・・
今回は有馬記念の予想記事を書いてみようかと思います。

とはいえ、この記事は、QiitaのAltPlus Advent Calendar 2016の23日目の記事
ここでは技術的な話を書く必要があるとのことなので
今回は私が予想するのではなく、プログラムで有馬記念を予想してみようと思います。

なにで予想する？

競馬予想をする上で、様々なアプローチはあるとは思うのですが
今回は出走馬の過去のレースの走破タイムから予想してみようと思います。

とりあえず、実際の競馬ではレース展開、相手関係との駆け引きなどもあるので単純にタイムが早ければ強いというわけでもないのですが競馬の専門誌などでも、ベストタイムが掲載されていたりするぐらいには重要な要素です。
普通に考えて、平均的にタイムが速い馬の方がポテンシャルは高いはず。
今回は出走馬の過去のレースから、それぞれの平均タイムを算出して、順位付けしてみます。

とはいえ、例えば距離が違う、斤量が軽ければ速くなるなど、いろんな条件で結果が変化するのが競馬。
単純に平均タイムを出しても全く意味のない数字になります。
なので今回は、タイムの比較ができるように、過去のレースが、全て今回の有馬記念と同じく、3歳以上の重賞、2500m、良馬場の条件で開催されていたとしたらどんなタイムだったのか？
というタイムの置き換えを行った上で、平均タイムを算出してみます。

どうやってタイムの置き換えをするか？

タイムが変動する大きな要素でグループ化
- 距離
- 馬場状態（良、稍重、重、不良）
- レースのクラス
- レースの年齢条件（2歳、3歳、それ以外）
- 競馬場
で過去5年のログをグルーピングし、それぞれの条件の平均勝ちタイムを算出します。
その中から「有馬記念」の中山、2500m、重賞、良馬場を「基準タイム」とします。
各馬の出走ログから、走ったレースと同じ条件の平均勝ちタイムと、基準タイムとの「タイム差」を算出
出走馬の実際の走破タイムに、タイム差を反映し「想定タイム」を生成
各馬の想定タイムから「平均タイム」を算出