GoogleAppEngineとGoogleCloudPlatformの知識アップデート2017/05

3年ぐらいGoogleAppEngine (GAE)を使っていなかったのですが、GCPの無料枠も増えてるみたいだし久しぶりに触ってみようと思って調べていました。 以下、GAEとGCP周辺の知識のアップデートなメモ書き。

GoogleCloudPlatform (GCP)

cloud.google.com

  • Googleが各種コンピュータリソースを提供するサービスはGoogleCloudPlatformというくくりでまとめられた。
  • 管理コンソールから各種サービスを設定できる
    • 各種サービスを『プロジェクト』という単位で設定し、まとめるようになった
  • 各種サービスを利用する開発は、Cloud SDKを使う
    • gcloudコマンドが管理用のコマンド
    • 以前はGoogleAppEngineのSDKは個別で配布されいるものだったが、gcloudコマンドからコンポーネントをインストールする形になった
    • GAEへのデプロイもgcloudコマンドからできる
    • CloudStorageを操作するgsutilなどもインストールされる

CloudShell

https://cloud.google.com/shell/docs/?hl=jacloud.google.com

  • Webブラウザ上で、Linuxのシェルを利用できる。
    • GCPの管理コンソールからすぐに利用できる
  • 無料で使える
  • CloudSDKがインストールされているため、管理用端末として使うような感じ
  • 作成したファイルなどは残る(VMの停止/再開をしているっぽい?)

GoogleAppEngine

cloud.google.com

  • スタンダード環境とフレキシブル環境から選べる
    • スタンダード
      • 最初からあったもので、ミドルウェア等の追加インストールなどができない環境
      • スケーリングの設定のGUIは管理コンソールには無いようで、app.yamlから設定することになったみたい
      • 以前と同様であれば、インスタンスの再起動時にランタイム環境が更新される?
        • 以前はセキュリティアップデートが自動で反映されてるような感じ
          • たまにバグで動作がおかしくなることもありましたが…
    • フレキシブル
      • ランタイム環境をカスタマイズできるもの
        • 以前はManaged VMと呼ばれていたもの?
        • あらかじめ用意されたテンプレートもしくは、カスタムランタイムを使える
        • Dockerfileを使える
          • 要するにDocker環境で動くGAE
      • デプロイすると、Dockerイメージがビルドされ、ContainerRegistryに登録され、dockerdで起動される
        • スタンダードのほうがデプロイや起動は速い感じ
        • ContainerRegistryはCloudStorageを使うので、そちらで料金がかかる?
      • app.yamlで使える設定がスタンダードとは異なる
      • Dockerなので、インスタンスを再起動してもランタイム環境は更新されない?
        • 環境が保たれるのはよさそうだけど、セキュリティアップデートなどは再デプロイ(ビルド)が必要?
      • ContainerEngineへの移行ドキュメントがある
      • SSHでログインできる
      • スタンダードの機能がそのまま使えるわけではない
  • リージョン
    • us-central1、us-east1、europe-west1、asia-northeast1から選べる
      • asia-northeast1は東京。昔はUSしか無かったのでレイテンシかなり改善
  • Datastore
    • 昔はGAEに含まれるサービスだったが、独立して外部からもAPIを利用できるようになった
    • GAEからは以前と同様に使える
  • スケーリング
    • スタンダードとフレキシブルで設定項目に違いがある
      • スタンダード
        • 以前からあったもの
        • Automatic、Manual、Basicから選べる
        • Automaticだと、リクエストの処理待ち時間の上下幅を与えてスケーリングの目安としたり、不要ならインスタンスがシャットダウンされたりする
      • フレキシブル
        • 最低インスタンス数1
        • CPU使用率の目安を指定できる
        • アイドリング時に指定時間が経過したらシャットダウンするような設定にできる
    • スタンダードのほうが細かい単位でスケーリングするようなイメージ?
      • スタンダード環境はOSやミドルウェア層がチューニングされているのかも?

ツンパァードラグーン・VR

前置き

今月は案件が無くて時間があったので、VRについていろいろ調べて試していました。

来月も今のところ暇になりそうなので、案件のお話があれば是非お問い合わせください。

www.open-c.jp

以下、本題です。

きっかけ

HTC VIVEを試すために何かアプリケーションを作ってみよう、ということで、題材を考えていたところ、「そうだ、ツンパァードラグーンがあるじゃないか」という流れで作ってみることになりました。

jsdo.it jsdo.it

某クローズドなコミュニティで人気の作品です。オリジナルはJavaScriptワンライナーで作られていたものでした。

今回はコードは特に使わず、ゲーム内容だけ参考にしてVR対応ならどうすると面白いか?を考えつつUnityで作ってみることにしました。

作ったもの

github.com

ツンパァードラグーン・VRです(HTC VIVE専用)

f:id:nullpobug:20170427152006p:plain

移動範囲が制限されたエリア内に下着が降ってきてコントローラー(手)を伸ばしてキャッチするゲームです(ヒドい)

f:id:nullpobug:20170427152005p:plain

上ばっかり見ているとドラゴンに体当りされてダメージを受けます。ライフが0になるとゲームオーバーです。

f:id:nullpobug:20170427152003p:plain

f:id:nullpobug:20170427152004p:plain

VIVEのヘッドマウントディスプレイとコントローラーを使ってみるのにちょうどいい感じになりました。

オブジェクトを移動させるためにベクトルの計算が必要でしたが、ベクトルを扱うのなんて学生の時以来でかなり忘れてしまってました。

下着のモデルがUnityのAssetStoreで探しても見つからなかったので、自分でモデリングしてテクスチャも作る、なんてこともやったりしました。なかなかおもしろかったです。

開発の参考にした情報

UnityでVIVEを使う開発についてはフレームシンセシスさんのページが網羅されていて大変参考になりました。

framesynthesis.jp

Unityでゲームを作る部分については、書籍が参考になりました。(Unityのバージョンの違いでそのまま使えない部分も少しありました)

ほんきで学ぶUnityゲーム開発入門 Unity5対応

ほんきで学ぶUnityゲーム開発入門 Unity5対応

AWS LambdaをPython3.6とChaliceで試す

AWS LambdaがようやくPython3に対応したそうなので試してました。

AWS Lambda Supports Python 3.6

Lambdaを使う際、Pythonランタイムだとchaliceというフレームワークを使うと楽なのですが、Python3サポートに合わせてchaliceもバージョンが上がっていました。

GitHub - awslabs/chalice: Python Serverless Microframework for AWS

ChaliceのREADMEも3.6になっていたので、これを試してみました。

手順通りで特に問題なく動いたので、説明は割愛。

コードだけ少し変更してPythonのバージョンを表示させてみることにしました。

app.py:

import sys
from chalice import Chalice

app = Chalice(app_name='helloworld')


@app.route('/')
def index():
    return {'python': sys.version}

デプロイして表示されたURLを確認したところ、Pythonのバージョンは3.6.1でした。

f:id:nullpobug:20170419204531p:plain

管理コンソールのランタイムの表示もPython3.6になっているので良さそうです。

f:id:nullpobug:20170419204532p:plain

使っていきたいと思います。

Travis CIのmatrixでtoxを実行する

Djangoフレームワークに依存するPythonのモジュールを作っていると、複数のPythonバージョンと複数のDjangoバージョンでテストコードを実行する必要があります。

手元で実行する場合はtoxを使うのですが、CIツールでもテストを実行したいです。

Welcome to the tox automation project — tox 2.7.0 documentation

GitHubで公開しているプロジェクトの場合、Travis CIを使うのが簡単でした。

Travis CI - Test and Deploy Your Code with Confidence

Travis CIは、複数の実行環境で並列してテストを実行し、テスト結果を分けて表示してくれます。

設定例

toxはTOXENVで実行する環境を指定できるので、.travis.ymlのmatrixでこれを指定します。

Pythonのバージョンを変えつつ環境変数を指定する設定の書き方がわかりづらくて試行錯誤した結果、次のように落ち着きました。

.travis.yml:

sudo: false
language: python
matrix:
  include:
    - python: '2.7'
      env: TOXENV=py27-dj18
    - python: '2.7'
      env: TOXENV=py27-dj19
    - python: '2.7'
      env: TOXENV=py27-dj110
    - python: '2.7'
      env: TOXENV=py27-dj111
    - python: '3.4'
      env: TOXENV=py34-dj18
    - python: '3.4'
      env: TOXENV=py34-dj19
    - python: '3.4'
      env: TOXENV=py34-dj110
    - python: '3.4'
      env: TOXENV=py34-dj111
    - python: '3.5'
      env: TOXENV=py35-dj19
    - python: '3.5'
      env: TOXENV=py35-dj110
    - python: '3.5'
      env: TOXENV=py35-dj111
    - python: '3.6'
      env: TOXENV=py36-dj110
    - python: '3.6'
      env: TOXENV=py36-dj111
    - python: '3.6'
      env: TOXENV=flake8
    - python: '3.6'
      env: TOXENV=coverage
script:
  - tox
install:
  - pip install tox

tox.ini:

[tox]
envlist =
  py27-dj18,
  py27-dj19,
  py27-dj110,
  py27-dj111,
  py34-dj18,
  py34-dj19,
  py34-dj110,
  py34-dj111,
  py35-dj19,
  py35-dj110,
  py35-dj111,
  py36-dj110,
  py36-dj111,
  coverage,
  flake8

[testenv]
commands = nosetests
deps =
  pyftpdlib
  nose

[testenv:py27-dj18]
basepython = python2.7
deps =
  django>=1.8,<1.9
  {[testenv]deps}

[testenv:py27-dj19]
basepython = python2.7
deps =
  django>=1.9,<1.10
  {[testenv]deps}

[testenv:py27-dj110]
basepython = python2.7
deps =
  django>=1.10,<1.11
  {[testenv]deps}

[testenv:py27-dj111]
basepython = python2.7
deps =
  django>=1.11,<1.12
  {[testenv]deps}

[testenv:py34-dj18]
basepython = python3.4
deps =
  django>=1.8,<1.9
  {[testenv]deps}

[testenv:py34-dj19]
basepython = python3.4
deps =
  django>=1.9,<1.10
  {[testenv]deps}

[testenv:py34-dj110]
basepython = python3.4
deps =
  django>=1.10,<1.11
  {[testenv]deps}

[testenv:py34-dj111]
basepython = python3.4
deps =
  django>=1.11,<1.12
  {[testenv]deps}

[testenv:py35-dj19]
basepython = python3.5
deps =
  django>=1.9,<1.10
  {[testenv]deps}

[testenv:py35-dj110]
basepython = python3.5
deps =
  django>=1.10,<1.11
  {[testenv]deps}

[testenv:py35-dj111]
basepython = python3.5
deps =
  django>=1.11,<1.12
  {[testenv]deps}

[testenv:py36-dj110]
basepython = python3.6
deps =
  django>=1.10,<1.11
  {[testenv]deps}

[testenv:py36-dj111]
basepython = python3.6
deps =
  django>=1.11,<1.12
  {[testenv]deps}

[testenv:flake8]
basepython = python3.6
deps =
  flake8
commands =
  flake8 src/

[testenv:coverage]
basepython = python3.6
deps =
  django>=1.11,<1.12
  coverage
  {[testenv]deps}
commands =
  nosetests --with-coverage

実行結果

tokibito/django-ftpserver - Travis CI

f:id:nullpobug:20170415154656p:plain

ハマった点

  • Pythonのバージョンを3.6にすると、Python3.5が入っていない
  • Pythonのバージョンを3.5にすると、Python3.6が入っていない

Django 1.11がリリースされましたね

Djangoフレームワークの1.11がリリースされましたね。

Django 1.11 released | Weblog | Django

  • 1.11はLTS(Long Term Support)バージョンです。メンテナンス期限はリリースから3年後までなので、2020年4月までになります。

    • 1つ前のバージョン1.10のメンテナンス期限は2017年12月までになります。
    • 1つ前のLTSバージョンは1.8で、メンテナンス期限は2018年4月までになります。
  • 対応するPythonのバージョンは、2.7、3.4、3.5、3.6です。Python2系をサポートする最後のバージョンです。

  • 次の大きなバージョンアップは2.0で2017年12月に予定されています。Python3.5以上をサポートする予定になっています。

ここ最近はロードマップのスケジュール通りにリリースされているので、次のバージョンも、さほどずれることはないのかもしれません。

エラーメッセージなどのリソースの日本語翻訳はやっておきました。変な訳があればTransifexかGoogleGroupなどで連絡して頂けるとよいかと。

気になった変更点など

全部には目を通してませんが、いくつか気になった点など。

Django 1.11 release notes | Django documentation | Django

  • install_requiresにpytzが入った

    • Djangoに初めてinstall_requiresが追加されました。今のところpytzだけ。
  • モデルに指定するデータベースのインデックスがクラスベースになった

    • インデックス名の指定ができるようになったみたいです
  • フォームのwidgetレンダリングがテンプレートシステム経由になった

    • 以前はPythonコードでHTMLパーツを生成してたので、分離しやすくなりそう?
  • ORMのサブクエリまわりをいくらか明示的に記述できるようになった

  • django.contrib.authのviewがクラスベースになった

参考情報

バージョンアップの準備の参考に。

Unity使い始め

HTC VIVEで遊びたくて、まずはUnityをちょっと使えるようになってみようって感じで勉強し始めたのでメモを残したり。

Unity - Game Engine

読み始めた書籍

購入して読み始めた本はこれ。

ほんきで学ぶUnityゲーム開発入門 Unity5対応

ほんきで学ぶUnityゲーム開発入門 Unity5対応

Unity 5.6とVisualStudio 2017をインストールして、本を読みつつ写経していってみてます。

まだ1/3程度しか読めてないですが、本の感想を少し。

  • 本のUnityバージョンが少し前のものなので、メニュー項目名など変わっていることがあり、若干戸惑う
  • スクリーンショットがいっぱいで説明が丁寧なのでわかりやすい。
  • 主要な各プラットフォーム向けのビルドについて説明されているのがうれしい
  • すぐに動かせるサンプルがあってうれしい

Unityを使いはじめての所感

3Dグラフィックスを扱うプログラミングがまったくはじめてなんですが、今のところさほど問題なく勉強を進めていけてる感じですが、この先数学の知識など足りなくてつらくなりそう。

UnityはWeb上にも情報が多いので楽できている感じ。

C#もはじめてに近いぐらいでしたが、他のプログラミング言語をいくつか使っていたのもあり、今のところ問題なさそうです。

ダウンロードしてきた無料のAssetをキー操作で動かせるようにして遊んだりしています。

f:id:nullpobug:20170405002325p:plain

メモ

  • アニメーション

    • AnimationControllerを用意してステートの遷移を設定
    • ステートの条件となる値をスクリプトで変更していく
    • アニメーションの終了をまたずにステートを遷移させるには「Has Exit Time」チェックを外す

引き続きやっていく。

参考

VRをやっていきたい

会社でHTC VIVEを購入したので、VRやARについて知見を得ていきたいと思う。知識ほぼないところからスタートだけども。

VIVE™ 日本 | 想像を超えたバーチャルリアリティの体験

HTC VIVEを少し動かしてみた感想としては、次のような感じ。

  • ルームスケール用の場所を確保するのが大変

    • 障害物のない長方形エリアを確保するのは意外と難しかった
  • 没入感すごい

    • Android端末でのVRも一緒に試していて、比較した感じではHTC VIVEのほうが没入感があっていい感じ。視野角が広いせい?
  • コントローラが画面に表示されるのはよい

    • 両手に持つコントローラが目の前に表示されるので、VR内の世界に触れる感じがあってよかった

      • 振動のフィードバックもあったりして楽しい
    • Android端末のほうで見てるだけだと、ちょっと物足りない、画面へのタッチが難しいので操作デバイスほしくなる

開発ツールはUnityになるのかなー?

Three.jsでWebVRなんかも試していきたい。