スタートトゥデイ研究所リサーチャーの中村です。 今回は、コーディネートからスタイルを自動抽出する技術に関するアイデアの紹介です。こちらは、 企業研究所による研究発表カンファレンス (CCSE2018) でも同様の内容で発表させていただきました。 そのときに使用した資料はこちらです。 ファッションのスタイルについて 服は組み合わせによって見た目の印象が変化します。例えば同じスラックスを履いたとしても、トップスがYシャツのときとTシャツのときでは印象が異なるはずです。ファッションではこの現象をスタイルやテイストといった言葉で表現します。 スタイルはコーディネートを考える際の指針となります。頻出するスタイルにはエイリアスが設定されており、印象を伝える際に利用されます。例えば以下のようなものです。 ところが多くの人にとって、このスタイルという概念はとても厄介です。服の組み合わせは無限に存在し、組み合わせを印象へマッピングできるようになるためには高度な専門知識が必要になるからです。 しかし服をおしゃれに着る際にはスタイルは最も重要な指針のひとつなので、この背後にある法則を解析し、機械で再現することには意義があります。 スタイルを解釈するためのフレームワーク 日本ファッションスタイリスト協会 という団体がStyling Mapというフレームワークを提供しています。 ファッションに関係する物 *1 と人 *2 を、それぞれの個性に応じて4つのテイストに分類するための考え方です。 4つのテイストとはアクアテイスト（Aq）、ブライトテイスト（Br）、クリスタルテイスト（Cr）、アーステイスト（Ea）で、各テイストについて与える印象と属するオブジェクトの有する特徴が定義されています。 ( https://stylist-kyokai.jp/stylingmap ) Styling Mapでは、スタイルを先述の4つのテイストの混合で表現することを許容しています。 4値判別でなくあえて曖昧さを含む表現を用いることで、表現能力の高いフレームワークとなっています。このアイデアは非常に有用だと思います。 解きたい問題 Styling Mapはファッションの専門家が経験に基づいて組み上げたフレームワークであり、実績を上げています。 この知識を再現してECに導入できれば、推薦を高度化すると同時に説得力をもたせることも可能です。 今回はコーディネートを対象に、背後に存在するスタイルの抽出とコーディネートの分類に取り組みます。 なお、Styling Mapでは4つのテイストに分類していましたが、本記事では基底となるスタイルをデータから求めます。 スタイルの定式化 Styling Mapからアイデアを拝借し、コーディネートのスタイルを混合表現で記述することを考えます。 基底のスタイルベクトル と混合比 を与えたとき、コーディネートのベクトル をそれらの線形結合で表現します。 例えば、基底スタイルを先述の4種類のテイストとしたとき、あるコーディネートは以下のように表現できます。 今回の問題では と は未知であり、これらをデータから求めることに挑戦します。 モデル 3層の砂時計型ニューラルネットワークを使います。入力はコーディネートベクトル 、出力は復元したコーディネートベクトル 、中間層はスタイル混合比 に対応します。 スタイル混合比の獲得 スタイル混合比 の各要素は対応する基底スタイルの重みに相当します。コーディネートベクトル を入力とし、全結合層にfeedしてこれを求めます。 比であることを維持するため、softmax関数を適用します。 コーディネートベクトルの復元 とモデルパラメータ の内積によりコーディネートベクトルの復元を行います。 ここで、 の各行は基底スタイルのベクトルであると仮定すると、この操作は定式化の章で述べたスタイルの表現に対応します。 学習 2種類のloss関数を定義します。はじめに復元時の誤差として、 と の類似度をhinge関数で評価します。 ここで、負例 はミニバッチから選択します。2点の類似度を返す関数 はコサイン類似度を使います。 続いて の正則化です。 の各行はスタイルの基底であると仮定しているため、各行は独立であることが望まれます。 これを式にすると、以下の様になるかと思います。 ここで、 は の各行を正規化した行列です。 コーディネートベクトルの抽出 コーディネートベクトル はCNNを用いて抽出します。入力のコーディネートデータはアイテム画像の集合であるため、それぞれの画像をResNet50にfeedして得られた特徴量を平均したベクトルをコーディネートベクトルとします。 データ IQONのコーディネートデータセットを使います。データセットの詳細は以前のブログでも触れているのでそちらをご参照ください。 参考： コーディネートの自動生成 特徴は、1つの標本が画像の集合であり、標本ごとに画像枚数が異なるということです。 結果 の次元数を8に設定し、学習させました。得られた基底スタイルの9近傍を表示します。 各スタイルの1行が、1つのコーディネートに対応します。 やはりファッションに詳しくないと分類に成功したか否かの判断に困りますが、少なくとも色調の違いはかなりはっきりと現れているかと思います。 本家Styling Mapでも説明できそうなクラスタも見受けられます。例えば、#5はアクアテイスト *3 とかなり似ていることが確認できます。 スタイルを混合表現にしたことで、基底スタイルを混ぜ合わせたようなスタイルも表現できるようになりました。 ここに示した例は、混合した基底スタイルの特徴が現れているかと思います。 まとめ 今回はコーディネートからのスタイル抽出に挑戦してました。 スタイルに混合表現を導入し、データから基底スタイルと混合比を教師無しで抽出しました。 poolingの方法の高度化やattentionの導入など、まだまだ改良の余地はあるかと思います。 一方で、コーディネートの特徴量さえうまく作れれば、スタイル抽出はもっとシンプルな手法でも達成できる気がしました。LDAやICAなどの手法は相性が良さそうです。 さいごに 研究所ではスタイルの抽出も含め「似合う」ということについて多角的に研究を始めています。 機械学習に限らず、専門性を活かしてファッションを解析したい方はぜひ下のリンクから応募して、ぜひ一度オフィスに来ていただければと思います。 www.wantedly.com *1 : 服やアクセサリーなど *2 : 骨格や性格など *3 : 本家が定義しているアクアテイストの特徴をご確認ください

こんにちは。スタートトゥデイテクノロジーズ新事業創造部の id:takanamito です。 今日はVASILY時代から活用されているOpenAPI(Swagger)の定義からRubyのクラスを自動生成するgemを作ったので、その紹介をしようと思います。 Swaggerの定義と実際のAPIが返すレスポンスの内容がズレている 弊社ではVASILY時代からSwaggerの導入が進んでいましたが、徐々に「Swaggerの定義と実際のAPIが返すレスポンスの内容がズレている」といった問題が発生しはじめていました。 その問題を解決するために今回つくったのがこのgemです。 github.com 例えばこんなOpenAPI Specification 3.0のYAMLの定義から schemas : user : type : object properties : username : type : string uuid : type : string repository : type : object properties : slug : type : string owner : $ref : '#/components/schemas/user' pullrequest : type : object properties : id : type : integer title : type : string repository : $ref : '#/components/schemas/repository' author : $ref : '#/components/schemas/user' こんなクラスが自動生成できます。 # cliで生成 
$ openapi2ruby generate ./path/to/link-example.yaml --out ./ $ ls . pullrequest_serializer.rb repository_serializer.rb user_serializer.rb class PullrequestSerializer < ActiveModel :: Serializer attributes :id , :title , :repository , :author def repository RepositorySerializer .new(object.repository) end def author UserSerializer .new(object.user) end def id type_check( :id , [ Integer ]) object.id end def title type_check( :title , [ String ]) object.title end private def type_check (name, types) raise " Field type is invalid. #{ name }" unless types.include?(object.send(name).class) end end 開発の経緯 先述の「Swaggerの定義と実際のAPIが返すレスポンスの内容がズレている」問題 APIの改修時に必ずSwagger定義も更新した上でアプリケーションを書き換えるという運用が人の手によって行われていたため、当然起こりうる事象だったのですが 実際にコードを読んでみるとController内で単にHashのオブジェクトを to_json してレスポンスデータを生成している処理が散見されました。 そのためAPIに型の概念を持ち込んでSwagger上の定義とレスポンスを一致させる方法を考え始めました。 実際にはOpenAPIのschema定義から ActiveModel::Serializer のクラスを自動生成しています。 調査 「コードの自動生成」という用途においては swagger-codegen が有名だったので、まずは今回やりたいRubyクラスの自動生成ができないか調査してみました。 デフォルトでは ruby , sinatra , rails5 のコードジェネレータが用意されており、以下のようにDockerを使ってコードの自動生成ができます。 # 通常のコードジェネレート $ ./run- in -docker.sh generate -i modules/swagger-codegen/src/ test /resources/2_0/petstore.yaml -l ruby -o /path/to/output # 独自テンプレートでコードジェネレート $ ./run- in -docker.sh generate -i modules/swagger-codegen/src/ test /resources/2_0/petstore.yaml -l ruby -t path/to/template_dir -o /path/to/output 実際にコードジェネレートすることはできますが、以下の点が気になりました。 テンプレートにmustache記法を使うことを強制される 欲しいのはschema定義された数ファイルだけなのに不要なファイルが大量に生成されてしまう 回避しようと 新しい対応言語を定義 してみたがjarを実行するなどの手順が必要 たまたまやる気があったので、シンプルにOpenAPI Specificaton 3.0のschema定義からRubyのクラスだけを生成するgemを作ることにしました。 (後から知ったんですが --ignore-file-override と .swagger-codegen-ignore を使えば指定したテンプレートのみ使ってコードジェネレートできるようです。) 導入の利点 現状、Rubyアプリケーションにおいてスキーマ定義どおりにレスポンスが返っているか検証するにはテストを書くか もしくはGraphQLなどのスキーマと実装が密接に紐付いている仕組みを採用することになると思います。 しかしテストを書くか否かは実装者に依存してしまいますし、既存APIをRESTからGraphQLに置き換えるのは工数的にもなかなか選べないことが多いはずです。 そういう状況において「スキーマから自動生成したシリアライザーでレスポンスの型を保証できる」今回のようなアプローチは有用かと思います。 スキーマファーストで開発をしていても、スキーマを更新した後アプリケーションにその変更を反映することを忘れてしまうと同じ問題が起こってしまいますが 今回のgemはcliを提供しているので「シリアライザーのファイルをgit管理下から外し、CIでテストやデプロイ時に最新のスキーマから自動生成して配置する」といったことも可能です。 「人が忘れてたことによってOpenAPIのスキーマ定義と実際のレスポンスがズレる」といった問題が防げるところに導入の利点があると考えています。 サンプル このgemを使いつつ、Twitterのような簡単なRails APIを作ってみます。 まずはGemfileに以下を追加 gem 'active_model_serializers' 登場するモデルは User , Profile , Tweet の3種類です。 class User < ApplicationRecord has_one :profile has_many :tweets end class Profile < ApplicationRecord belongs_to :user end class Tweet < ApplicationRecord belongs_to :user end スキーマはこんな感じ。 create_table " profiles " , options : " ENGINE=InnoDB DEFAULT CHARSET=utf8 " , force : :cascade do | t | t.bigint " user_id " t.string " description " t.datetime " created_at " , null : false t.datetime " updated_at " , null : false t.index [ " user_id " ], name : " index_profiles_on_user_id " end create_table " tweets " , options : " ENGINE=InnoDB DEFAULT CHARSET=utf8 " , force : :cascade do | t | t.bigint " user_id " t.string " tweet_text " t.datetime " created_at " , null : false t.datetime " updated_at " , null : false t.index [ " user_id " ], name : " index_tweets_on_user_id " end create_table " users " , options : " ENGINE=InnoDB DEFAULT CHARSET=utf8 " , force : :cascade do | t | t.string " name " t.datetime " created_at " , null : false t.datetime " updated_at " , null : false end seeds.rbでサンプルデータも。 User .create( name : ' takanamito ' ) Profile .create( user : User .first, description : ' プロフィールです ' ) Tweet .create( user : User .first, tweet_text : ' 我が問いに空言人が焼かれ死ぬ ' ) Tweet .create( user : User .first, tweet_text : ' オレは太刀の間合い(半径4m)までで十分...!!(つーか これが限界) ' ) Tweet .create( user : User .first, tweet_text : ' 私の垂直跳びベストは16m80cm!!! ' ) 以下のようなユーザー情報を返すAPIをOpenAPIで定義します。 schemas : user : type : object properties : name : type : string profile : $ref : '#/components/schemas/profile' tweets : type : array items : $ref : '#/components/schemas/tweet' profile : type : object properties : description : type : string tweet : type : object properties : tweet_text : type : string ActiveModel::Serializerを使う前提でControllerを書いてゆきます。 class UsersController < ApplicationController def show @user = User .find(params[ :id ]) render json : @user end end ここまで用意すればあとはgemでシリアライザを自動生成するだけ。 $ openapi2ruby generate ./path/to/openapi.yaml --out ./app/serializers/ Railsを立ち上げて、ブラウザでアクセスしてみると... シリアライザを通して生成したjsonが返せています。 現状の問題点 開発を始めたばかりということもあり、いくつかの問題を抱えています。 OpenAPI上の各schemaのpropertyがActiveRecordのassociatonなのかわからない 上記の問題の解決のためにassociationであっても、シリアライザのattributes定義を使っているため循環参照による無限ループに陥る場合がある まず1点目 例えば上記ユースケース内で紹介しているモデルはすべて ActiveRecordのassociation として関係性が明示されていますが OpenAPIの定義からはその関係性がassociationなのか、単なるクラスのメンバ変数としてアクセスするのかを知るすべはありません。 そのためシリアライザ内で has_one , has_many の定義は使用しておらず 全て attributes として定義し $ref で参照しているクラスのシリアライザで初期化した値を返すメソッドを定義しています。 これによりassociationかどうかを意識せずシリアライザを扱うことができるようになりました。 ( --template オプションにより自作のテンプレートを使うこともできます。 参照: Use original template ) しかし2点目 associationでの対応を諦めたことにより has_one <-> belongs_to な関係性のモデルのシリアライザ生成時した場合、循環参照が生まれてしまいました。 例えば Profile モデルは belongs_to :user な関係にありますが これをschema定義上のProfileのpropertyとして定義してしまうと実行時にお互いのシリアライザを呼び合ってしまい循環参照から抜けられない状態になります。 # profileのschemaにuserへの参照を追加 profile : type : object properties : user : $ref : '#/components/schemas/user' description : type : string class UserSerializer < ActiveModel :: Serializer attributes :name , :profile , :tweets # Profileをシリアライズ def profile ProfileSerializer .new(object.profile) end # ..略.. end class ProfileSerializer < ActiveModel :: Serializer attributes :user , :description # Userをシリアライズしてるので循環参照を引き起こす def user UserSerializer .new(object.user) end # ..略.. end ActiveRecordのassociationが前提であれば Controllerで includeオプション を渡すことによりこの問題は回避可能です。 しかし先述の通りこのgemではschemaのpropertyがassociationなのか判定できず 全てのpropertyをシリアライザのattributesとして実装しているため、今回の問題を引き起こしてしまいます。 ※回避する方法をご存知の方がいればこっそり教えていただけると幸いです。 おわりに 開発の経緯からサンプル実装までご紹介させていただきました。 実際に現場のアプリケーションで導入を検討しているので、これからProduction環境にのせるにあたってgemの改修をしていく予定です。 また弊社では「レスポンスに型をもたせる」という文脈でGraphQL, gRPCなどの技術の採用について普段から議論しています。 RESTにとらわれずAPIを開発したい方はぜひ下のリンクから応募して、ぜひ一度オフィスに来ていただければと思います。

こんにちは、最近のマイブームは マヌルネコ動画 な新事業創造部バックエンドエンジニアの塩崎です。 今回のテックブログでは、以前にDigdagを紹介した記事の続編として、DigdagをHA構成にするためのTipsなどを紹介します。 Digdagとは Digdagはワークフローエンジンと呼ばれるソフトウェアです。 複数個のタスク間の依存関係からなるワークフローを定義し、そのワークフローの実行及び管理を行います。 この説明だけですと、何が便利なのかいまいちピンとこない方が多いかと思います。 ですが、かゆいところに手が届く便利ソフトウェアです。 具体的なかゆいところの紹介は以前にDigdagを紹介した記事の前半部分に書かれています。 Digdagを使用したことのない方はこちらを読んでから本記事を読み進めると理解しやすいかと思います。 tech.starttoday-tech.com さて、前回の記事ではDigdagを使うメリットの1つとしてHA構成を紹介しましたが、それを実現するための具体的な設定などについては紹介していませんでした。 今回はDigdagでHA構成を実現するために必要な構成要素や設定ファイルなどを紹介します。 HA構成にするための知識 DigdagをHA構成にするためには digdag server コマンドで起動しているプロセスが担っているいくつかの役割を理解することから始めると分かりやすいです。 以下でそれぞれのコンポーネントの説明をします。 API server このコンポーネントはHTTPサーバーとして動作し、以下の機能を提供します。 タスクの状態をブラウザから確認できる機能 digdag push などのdigdagのクライアントモードのコマンドを受け付けるためのREST API これはdigdag serverを起動した時に必ず有効化されます。 Agent Agentは実際にタスクの実行を行う部分です。タスクキューからタスクを取り出し、実行をします。 信用できない環境で動かすことも考慮されているため、この処理を行うスレッドはワークフロー情報が格納されているDBと直接通信をしません。 Workflow executor Workflow executorはワークフローの状態を監視し、次に実行するべきタスクをタスクキューにプッシュします。 Schedule executor Schedule executorはスケジュール実行が設定されているワークフローを監視し、設定された時刻になったらワークフローを実行状態にします。 一部の機能の無効化 これらの機能の一部は digdag server 起動時にコマンドにオプションを渡すことによって無効化できます。 指定するオプション API server Agent Workflow executor Schedule executor なし ○ ○ ○ ○ --disable-executor-loop ○ ○ ☓ ☓ --disable-local-agent ○ ☓ ○ ○ --disable-executor-loop --disable-local-agent ○ ☓ ☓ ☓ なお、これらのより詳細な説明はDigdag公式ドキュメントの中の以下の部分にかかれています。 Internal architecture 構成 HA構成のときの典型的なシステム構成図を以下に示します。 上で紹介した4つの機能のすべてがいずれかのサーバーで有効になっています。 以下ではそれぞれの構成要素について説明します。 PostgreSQL ワークフロー定義やタスクキューなどはPostgreSQLに保存されます。 システム全体をHA構成にする場合には当然ここもHA構成にする必要があります。 今回構築したシステムではAmazon AuroraのPostgreSQL互換モードをMultiAZ構成にすることによって、HA構成としました。 API Server API Serverはそれ専用のインスタンスを用意し、ロードバランサーの後段に2台を配置しました。 これらのサーバー上でのタスクの実行を止めるために、 --disable-executor-loop --disable-local-agent のオプションを指定しています。 また、ここではタスクの実行を行わないため、小さなEC2インスタンスを用いています。 Agent + Workflow executor + Schedule executor Agent、Workflow executor、Schedule executorの機能は同一のサーバーに載せています。 digdag server を起動する時に、 --disable-* オプションを指定せずに起動しています。 タスクの実行はこれらのサーバーのみで行われます。 実際には、これらもAPI Serverとしての機能も有していますが、HTTPリクエストを受けることはありません。 タスクの実行ログの場所について digdag serverを1つのサーバーだけで運用する場合、タスクの実行ログ（タスクが標準出力に書き出した内容）をサーバー上のローカルストレージに保存することが多いかと思います。 しかし、上で紹介したような構成を取る場合、全てのサーバーが読み書きできる場所に実行ログを配置する必要があります。 その1つの方法は、NFSなどの方法を使いネットワーク内の全てのDigdagで同じディレクトリを共有する事です。 また、Digdagはaws S3に実行ログを保存することも出来るので、今回はこちらを採用しました。 以下のような設定ファイルを全てのDigdag serverに読み込ませることによって、実行ログがS3に保存されます。 direct_downloadオプションはログをS3から直接ダウンロードするか否かを指定するためのオプションです。 log-server.type=s3 log-server.s3.bucket=<バケット名> log-server.s3.path=<ログを配置する場所のパス> log-server.s3.direct_download=false # S3から直にダウンロードする場合はtrueにする HA構成にしたときにハマったこと 構成例の次に、HA構成にすることによって発生した問題とその対処法を紹介します。 ローカルストレージのファイルの扱い DigdagをHA構成すると一般的にサーバー台数が2台以上になるため、1つのワークフローに属するタスクたちが複数台のサーバーで実行されることがあります。 そのため、タスク間でのファイルの受け渡しにサーバーのローカルストレージを使用すると、ファイルが見つからずエラーになることがあります。 +task1: sh>: echo 'hoge' > /tmp/hoge.txt +task2: sh>: cat /tmp/hoge.txt # ファイルが見つからない場合がある この問題を解消するためには、サーバーのローカルストレージを介したデータの受け渡しをなくす必要があります。 ローカルストレージの代わりにS3やDBなどの全サーバーから参照することのできるストレージを使うことによって、問題に対処をしました。 PostgreSQLのコネクション数 DigdagがPostgreSQLと接続する時に使用しているコネクションが多すぎると、Digdagの起動時にPostgreSQLとの接続を確立できないことがありました。 これはPosgreSQL側が受けることのできるコネクション数の上限に達すると発生する現象です。 コネクション数のデフォルトはCPUコアの数*32とかなり多めになっているので、以下のようにして、コネクション数を絞って問題に対処しました。 database.maximumPoolSize=32 サーバーが落ちた時の挙動 HA構成をとっているときにサーバーが突然死したときの挙動がどうなるのかの検証を行いました。 以下のようなタスクを実行し、sleep 10を実行している最中にDigdagプロセスを kill -9 で落としてみました。 timezone: UTC +task1: sh>: "echo task1 start && sleep 10 && echo task1 end" kill -9 を行ったdigdagプロセスのログは以下のようになり、task1の実行途中でサーバーが突然死をしたような挙動になっています。 2018-06-15 13:50:24 +0900: Digdag v0.9.25 2018-06-15 13:50:25 +0900 [INFO] (main): secret encryption engine: disabled 2018-06-15 13:50:25 +0900 [INFO] (main): XNIO version 3.3.6.Final 2018-06-15 13:50:25 +0900 [INFO] (main): XNIO NIO Implementation Version 3.3.6.Final 2018-06-15 13:50:25 +0900 [INFO] (main): Starting server on 0.0.0.0:65434 2018-06-15 13:50:25 +0900 [INFO] (main): Bound on 0:0:0:0:0:0:0:0:65434 (api) 2018-06-15 13:50:26 +0900 [INFO] (0042@[0:ha_sample]+sample^failure-alert): type: notify 2018-06-15 13:50:34 +0900 [INFO] (0042@[0:ha_sample]+sample+task1): sh>: echo task1 start && sleep 10 && echo task1 end task1 start # ここでdigdagプロセスに対してkill -9を行う。プロセスが突然死ぬので、これ以降のログは無い。 このワークフローの実行状況をweb UIで確認すると、タスクが未だ実行中という状態になっています。 そして、約5分後になると別のdigdagプロセスでタスクが実行され、ワークフローの実行が成功しました。 2018-06-15 13:55:37 +0900 [INFO] (0042@[0:ha_sample]+sample+task1): sh>: echo task1 start && sleep 10 && echo task1 end task1 start task1 end Agentはキューからタスクを取り出すときにqueued_task_locksテーブルの lock_expire_time に現在時刻から5分後のUNIX timeを書き込みます。 Agentは1分毎にこの値を現在時刻の5分後に設定するため、Agentが生きている限りは 現在時刻 < lock_expire_time になります。 一方、Agentが死んだ場合には lock_expire_time の更新がストップするため、約5分後になると現在時刻 > lock_expire_time という状態になります。 この状態のタスクの存在を他のAgentが検知することによって、突然死したAgentが担当していたタスクを他のAgentが代わりに実行するという機能が実現されています。 この動作はタスクのリトライ機能とは関係ないため、リトライ回数を設定していないタスクに対しても行われます。 このような内部実装になっているため、Digdagのワークルフローを書くときには可能な限り各タスクを冪等にするべきです。 オートスケーリングとの組み合わせ HA構成を組んだことによってオートスケーリングによるスケールアウトが簡単に行えるようになったので、その紹介もします。 構成図中でタスクを実行する役割を持っているEC2インスタンスたちに対してAutoScalingGroupの設定を行い、サーバーの起動時にDigdagが自動的に起動するよう設定します。 そして以下のようにすることによって、効率よく複数個のタスクを実行できます。 なお、Agentのサーバー台数をゼロにしてしまうとその後にサーバー台数を増やすためのリクエストを実行することすらできなくなりますので、注意が必要です。 +scale_out: sh>: autoscaling.sh 10 +load_tables: for_each>: table: ["table1", "table2", "table3", ... "table100"] _parallel: true _do: call>: load_table.dig +scale_in: sh>: autoscaling.sh 1 #!/bin/bash REGION='<region>' AUTO_SCALING_GROUP_NAME='<auto scaling group name>' aws --region $REGION autoscaling set-desired-capacity --auto-scaling-group-name $AUTO_SCALING_GROUP_NAME --desired-capacity $1 まとめ 今回はDigdagをHA構成で構築する方法を紹介しました。 ワークフロー管理ツールはDigdag以外にもAirflowやLuigiなどいろいろあります。 それら他のツールと比べるとDigdagはHA構成を簡単に組むことが出来るように最初から考えられている印象を受けます。 バッチをスケジュール実行するサーバーは多くのシステムでSPOFになりやすいので、HA構成にすることによって可用性をより高めましょう。 スタートトゥディテクノロジーズでは、一緒にサービスを作り上げてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください！

こんにちは、バックエンドエンジニアの田島（ @katsuyan121 ）です。 5/31〜6/2にかけて仙台で開催されたRubyKaigi2018に、スタートトゥデイテクノロジーズから5人が参加しました。 今年のRubyKaigiは3日間で50を超える講演があり、参加者も1000人を超える大変大規模なカンファレンスでした。たくさんの講演の中で、スタートトゥデイテクノロジーズのエンジニアが興味を持ったものを、この記事でいくつか紹介します。 また今回スタートトゥデイテクノロジーズはスポンサーブースを出展したので、そこで得られたことを共有します。 セッション Proverbs(Matz) Rubyのお父さんであり、弊社スタートトゥデイテクノロジーズの技術顧問でもある Matz さんの発表です。 今回の発表では3つの諺を例にお話を展開されました。 名は体を表す 「名は体を表す」という通り、名前は重要であるというお話でした。特にソフトウェアには実態がないため、名前付けが重要になるとのことでした。 名前には2種類あり、1つは振る舞いに対する名前でもう1つがプロジェクトに対する名前です。 振る舞いに対する名前付けが難しいという場面はよく訪れます。しかし名前付けが難しいということはその概念を十分に理解していないことであるとのことでした。 プロジェクト名という側面では、Rubyのような求心力のある名前が好ましいとの話でした。また、今の時代だとgooglabilityが非常に大切であるとも語られていました。それを解決するのためにTensorFlowのように単語を組み合わせたり、Jupyterのようにスペルをいじるのは良い手段であるとのことでした。 時は金（価値）なり 時は金（価値）なりが示すように、時間を有効活用することが非常に大切であるとの話でした。開発における時間には開発時間と実行時間という2つの側面があります。Rubyでは主に開発時間という部分に重きをおいてきました。開発時間を短くすることで人件費の節約など直接的に費用削減につながるということでした。 また、実行時間についてもRubyにJITを導入するなど改善を常に行っています。実行時間を短縮することでサーバの台数が減るなど直接的に費用を削減できると例をあげて説明していました。 塞翁が馬 塞翁が馬のように、良いこと悪いことに一喜一憂するなというお話でした。例えば、静的型が流行っているからと言ってRubyには絶対に静的型は導入しないとのことでした。長い目で見た時に安易に静的型を導入しないほうが有利になるとMatzさんは考えているそうです。 コスチュームスポンサー 今回のRubyKaigiではMatzさんには事前にZOZOSUITを着ていただき、測定結果を元にMatzさんピッタリサイズのジーンズを履いていただきました。 またkeynoteの最後でコスチュームスポンサーとしてスタートトゥデイテクノロジーズを紹介していただきました！ Improve Ruby coding style rules and Lint(Koichi ITO) RuboCopのコミッタである Koichi ITO さんによる、RuboCopのStyleとLintについての発表でした。 Styleはコーディングスタイルのことを表します。コーディングスタイルは様々な文化から形成され、会社やプロジェクトによって異なったルールが存在します。RuboCopのデフォルトのStyleは Ruby Style Guide に従って作成されているそうです。Lintは潜在的なバグを指摘するもので、コーディングスタイルとは違い言語仕様的に適切でない箇所を指摘します。 Styleについては、会社やプロジェクトによってコーディングスタイルは違うものなので、積極的にデフォルト設定からカスタマイズしてほしいとのことでした。 また、Koichi ITOさん自身がRuboCopのルールをどのような経緯で新しく追加したかについてもお話されていました。会社のコードレビューを受けて気づいたルールや、RailsのカスタムコップからRuboCopに採用したルールもあるとのことでした。 発表を通して、自分たちが使ってよかったものを他の人にも広めていこうというKoichi ITOさんの意思がとても伝わってきました。 Architecture of hanami applications(Anton Davydov) Anton Davydov さんによる、hanamiを長期的にメンテナンスしていくうえで採用したアーキテクチャを振り返るという発表でした。 ファットモデルなコードから段階的にビジネスロジックを切り離していく方法としてhanamiに採用されている手法の説明がありました。具体的にはInteractor(Service object), Repositoryや、Event Sourcingなどが紹介されていました。 また、Event SourcingのPoC実装としてhanami-eventsというgemについての紹介もありました。 実際にInteractorやRepositoryを入れた意図やhanamiでの実装例が示されていました。 様々なデザインパターン紹介の最後に『必要かわからないときは使わないでおく』ということを書かれていた事は、エンジニアとしてすごく共感できました。 ビジネスロジックの切り分けはhanamiだけでなく、webアプリケーション開発をしている人全体の問題でもあります。良さそうなパターンは実際に検証して自分たちのプロジェクトに取り入れていこうと思います。 bancor: Token economy made with Ruby(Yuta Kurotaki) Yuta Kurotaki さんによるBancor Protocolというスマートトークンを発行するためのプロトコルをRubyで実装したという発表でした。ちなみにBancorはバンコールと読みます。 ブロックチェーン関連の実装はPythonやGo・JavaScriptで実装されているものが多いですが、Rubyで実装されているものがあまりなく実装してみたということでした。 実際のRailsアプリケーションに組み込んでbancor protocolを利用したデモでは、流動的に価格が決定されているところを見ることができました。 Ruby実装が少ないブロックチェーンを実装するという試みは、新しいものに挑戦していくという部分ですごく共感を得られました。 参考： bancorのリポジトリ Hijacking Ruby Syntax in Ruby(joker1007/Satoshi "moris" Tagomori) Hijacking Ruby Syntax in Ruby from SATOSHI TAGOMORI joker1007 さん・ Satoshi "moris" Tagomori さんによるメタプログラミングを最大限に活用しようという発表でした。メタプログラミングというRubyの黒魔術を最大限に活用して、Rubyの文法が変わったのかと錯覚するレベルの機能が示されていました。 肝になる機能は Binding#local_variable_set と Tracepoint で、これらの機能を利用していたるところにフックを仕込みます。そうすることで、いたるところの変数を書き換え邪悪な機能を実現しているとのことでした。 Javaでおなじみのfinal、override、abstractをRubyでも実現し、なおかつこれらはクラス定義時点でエラーを出せるという点に感動しました。 その他にPythonでおなじみのwithや、Goでおなじみのdeferなどと同等な機能をRubyのメタプロだけで実現している例が示されました。 Rubyはメタプロ文化があるとはいえ、ここまでのことができたのかという驚きがありました。 TTY - Ruby alchemist’s secret potion(Piotr Murach) Piotr Murach さんによるTTYというCLI作成用のライブラリを作ったという発表でした。 最初に以下のようにwebのアーキテクチャと比較している点が興味深かったです。 cli - router command - controller stdin - request stdout - response template - view TTYには複数のプラグインがあり、プラグインを導入することでCLIをリッチにできます。 実際にデモではTTYを利用したCLIが示されており、ギュインギュイン動いていて感動しました。 TTYは簡単にリッチなCLIツールを作るにはすごくいいライブラリだと思います。 またアーキテクチャも上に示した通りwebエンジニアにとってすごくわかりやすい構成となっていて、複雑なCLIツールを作るのにも向いているライブラリであると感じました。 参考： TTYリポジトリ Firmware programming with mruby/c(Hitoshi HASUMI) Hitoshi HASUMI さんによる、mruby/cを使って日本酒を醸す（かもす）というお話でした。 日本酒の製造にあたっては麹（こうじ）や醪（もろみ）の温度管理が必要で、そのために温度センサーのデータを収集するためのファームウェアをmruby/cで作ったそうです。 こういう用途ではラズパイの使用も考えられます。しかし冬でも35度である麹室での運用を考えた時に、低消費電力かつ低発熱なことを重視しARM Cortex-M3が搭載されたPSoc5LPマイコンにしたそうです。 このシステムは2018年1月から実際に稼働しているそうです。 mrubyとmruby/cはどちらとも軽量Rubyですが、mruby/cの方がより少ないメモリでも動くようにできているとのことでした。 大きな違いとしてmrubyはRTOS（RealTimeOS）の上で動くことが前提ですが、mruby/cはRTOSなしでその下に直接ハードウェアがあるという構成になっている点です。 そのためにHAL（ハードウェア抽象化レイヤー）があり、ソースコードの中のその部分を読むと面白いのではとのことでした。 開発中に困ったこととしては、デバッガでのステップ実行ができないのでprintデバッグしかできなかったとのことでした。また、 Array#each が未実装なので while と break で代替しなければならないという点でした。このようなことから、mruby/cはまだまだ成長の余地があって楽しみです。 また発表されていた十旭日は、東京では以下の酒販店で取り扱われているそうです。 生原酒と火入れ：新宿の三伊井上酒店 主に生原酒：笹塚のマルセウ本間商店 主に火入れ：中目黒の出口屋、練馬の大塚屋 定番品種：横浜君嶋屋の銀座店、恵比寿店 十旭日のなかでもmruby/cで醸されたお酒は29BY（平成29酒造年度の醸造）のものだそうです。 https://twitter.com/hasumikin/status/1006899085570334727 Ruby code from the stratosphere - SIAF, Sonic Pi, Petal(Kenichi Kanai) Kenichi Kanai さんによる、mrubyを使ったlivecodingの発表でした。 ここでいうlivecodingとは、「コンピュータの言語であるプログラムコードを直接操作することで、さまざまな音や映像をリアルタイムに生成する即興演奏の方法」とのことでした。 Petalというプログラミング言語（実際はRubyのDSL）を使うことで、シンプルな記法で多様な音を出すことができるそうです。 気象観測用の気球にラズパイとセンサーを載せて、上空でセンサーから取得したデータをもとにPetalのコードを生成します。そこから音を生成することによって、成層圏からの音楽を地上に届けるということを札幌国際芸術祭でやったそうです。 最初は気球に搭載したラズパイで音を生成してそれを地上に無線で届けるということをしていたそうです。しかしそれだとノイズが多くのってしまったので、2回目からは音の生成を地上でやるという方法で問題解決をしたらしいです。 発表の最後ではこの時に取得したセンサーデータのログから音楽を生成し、会場のみんなで成層圏からの音楽を楽しみました。 参考： スライド スライド Petalリポジトリ Deep Learning Programming on Ruby(Kenta Murata/Yusaku Hatanaka) Kenta Murata さん・ Yusaku Hatanaka さんによるRubyでDeep Learningをできるようにする試みについての発表でした。 このセッションは2つ分かれており、前半では「mxnet.rb」のについての発表。後半は「Red Chainer」の発表となっていました。 1つめのmxnet.rbのお話は、MXnetのRubyバインディングを開発したというお話でした。MXnetはDeepLearning用のライブラリで複数言語のバインディングが存在するが、Rubyには対応していなかったとのことで開発を初めたようです。 MXnet自体はKerasのbackendにも利用されています。TensorFlowでのバックグラウンドと比較して良いパフォーマンスであったことが確認されており、有用なライブラリであるとのことでした。 ONNXにも対応しており、一度MXnetで作ったモデルを他のONNXに対応したDeepLearningライブラリで利用できるそうです。また逆に他のライブラリで作成したモデルをMXnetで利用できるとのことでした。 mxnet.rbは絶賛開発中で、プルリクをお待ちしておりますとのことでした。 2つ目のRed ChainerはChainerをRuby実装として実現するというお話でした。こちらも絶賛開発中とのことで、まだPythonチックなRubyを書かないと行けない部分があったり、CPUにのみしか対応していないとのことでした。しかし、今後はもっとRubyらしく記述できるようにし、後述するCUMOを利用することで近々GPUに対応予定とのことでした。 Red ChainerはRed Data Toolsというコミュニティに属しています。Red Data Toolsは理念が素敵で誰でも気軽に参加できそうなコミュニティだと感じました。 このように、RubyでDeepLearningをするという試みが活発になってきていることが分かりました。Rubyで楽しくDeep Learningできるのはすごく楽しみです。 参考： Yusaku Hatanakaさん振り返りブログ mxnet.rbリポジトリ redchainerリポジトリ Fast Numerical Computing and Deep Learning in Ruby with Cumo(Naotoshi Seo) Naotoshi Seo さんによる、NumoというRubyの計算用ライブラリをCUDAに対応させようという試みの発表でした。 Numo自体はRubyの計算用ライブラリですが、CPUにのみ対応しています。そこで、Numo互換のCUDA対応ライブラリであるCUMOを作成したそうです。 CPUを前提とした実装をGPUに対応した時、GPUによる並列計算どのように計算させるのかということがわかりやすくまとまっていました。CUDAプログラミングをしたことがない人でも理解できるような内容となっていました。 実際にCUMOを利用する場合、ソースコード中のNumoをCumoに全置換するだけでGPUに対応できるのは感動しました。 またこのプロジェクトはRuby Associationに採択されたプロジェクトだそうです。個人的にやるプロジェクトでもなにかしらの締切が設けられることで、それがマイルストーンになるということも語られていました。 参考： 発表者振り返りブログ CUMOリジトリ NUMOリポジトリ スポンサーブース アンケート 1日目 お題 初日のお題は、「ブロック開始の中括弧とブロックパラメーターの間にスペースを開けるか」というものでした。 このお題の理由としては、技術顧問のMatzさんとの月イチのミーティングでRubCopの話になったことが切っ掛けです。RuboCopのデフォルトではスペースを開けるようになっています。しかし、Matzさんはスペースを開けたくないとのことだったのでこのお題を提示しました。 結果 考察 結果はスペースを開ける派が多数となりました。スペースを開けるという理由として多く挙げられたのはやはりRuboCopに指摘されるからというのが多かったです。また、中括弧でなく do end で記述する場合は do とブロックパラメータの間にスペースを開けるから統一するためとの解答もいただきました。 スペースを開けない派の意見としては、ArrayやHashを作るときにはカッコのあとにスペースを開けないからそちらと統一するためなどの意見をいただきました。 「Improve Ruby coding style rules and Lint」で示されていたように、styleは文化によって違います。そのためプロジェクト内で記法が統一されていれば、どちらでも良いと考えました。 2日目 お題 2日目のお題としては、「クラスメソッドの定義をするときに self.クラスメソッド名 と書くか、 class << self で特異クラスをオープンするのか」というものでした。このお題の意図としてはまたもRuboCopでは後者を使うように示されますが、前者のほうがクラスメソッドとしてわかりやすいのではないか？　という意見が社内であったことからこのお題を提示しました。 結果 考察 結果は class << self で特異クラスをオープンするほうが多数となりました。特に多かった意見としては、クラスメソッドが1つの場合は self.クラスメソッド名 、2つ以上の場合は class << self を使うというものでした。 また、 class << self を使う理由としてはprivateクラスメソッドがこっちの書き方でしか書けないから、grepする時に探しやすいからというものがありました。 self.クラスメソッド名 を使う理由としてはパット見てクラスメソッドかどうかがわかりやすいからという意見が多かったです。 このアンケートは、一日目よりも迷う人が多かった様子でした。このケースはプロジェクトで柔軟に対応していくのがいいと考えます。 3日目 お題 最終日のお題は「文字列の配列を定義するときに、％記法を使うか」というものでした。このお題に関してもRuboCopでは前者が示されます。後者のほうが文字列の配列としてシンプルでわかりやすいという意見があったことからこのお題を提示しました。 結果 考察 結果は％記法を使うという方が多数となりました。％記法を使う理由としては、単純にタイプ数が減る。文字列以外が配列の中に入らないなどが挙げられました。ここでもRuboCopに指摘されるからという意見もありました。 ％記法を使わない理由としては、％の次に何を書けばいいか忘れてしまう。Ruby以外の言語から来た人でもわかりやすい。文字列の配列であることが直感的にわかりやすということが挙げられました。 これについても、それぞれの利点をちゃんと知った上であれば好みのスタイルで書けばいいと考えました。 gem お題 最終日には好きなgemのアンケートを取りました。 結果 考察 今回の好きなgemアンケートでは pry や byebug など手元で動かすgemが多く挙げられました。 実際に自分が助けられたり便利だなって感じたgemを好きだと感じるのかなと思います。 知らないgemも多く挙げられすごく勉強になりました。ぜひアンケート結果から知らないgemを調べてみてください。 まとめ やはりRubyKaigiは日本一のテックカンファレンスだなと改めて実感しました。Rubyコミッタ級のエンジニアがゴロゴロ転がっているカンファレンスは他にはないです。また来年のRubyKaigiが楽しみです！ 今回初めてスポンサーブースを出展させていただきました。ブースを出展することによってRubyのお話をたくさんの方とできました。Rubyコミッタの方たちも立ち寄って頂き気軽に話すことができたのはすごく勉強になりました。 また、今回のRubyKaigi参加に関する費用はすべて会社が負担してくれました。さらに出張手当をもらえたうえに、休日出勤分の振休まで取得させてくれました。 来年のRubyKaigiは福岡で開催される予定です。一緒にいこう！　という方がいましたら、ぜひ以下のリンクからご応募ください。 https://www.wantedly.com/companies/starttoday-tech/projects おまけ RubyKaigi参加メンバー 弊社技術顧問であるMatzさんとの記念撮影 仙台は美味しいものが多すぎてお腹がいっぱい 牛タン からの牛タン からの牛タン うに 海鮮丼 東北大生名物さわき RubyKaigi最終日の次の日に猫島こと田代島にお出かけ いざ猫島 ねこにちょっかい 猫になるリーダー 猫神社 ねこー

こんにちは！スタートトゥデイテクノロジーズ新事業創造部の堀江（ @Horie1024 ）です。 2018年5月8日〜5月10日にかけて、カリフォルニア州マウンテンビューにあるショアライン・アンフィシアターで行われたGoogle I/O 2018（以下I/O）に新事業創造部の堀江、権守、茨木、そして代表取締役CIOの金山の4名で参加してきました。 また、帰国後の5月29日にDMM.comグループさん主催の Google I/O 2018 参加報告会 で堀江、権守、茨木が登壇しI/Oで得た知見を発表しました。 本記事では、 参加報告会での発表内容の紹介とI/Oで印象に残ったセッションの紹介、そして参加した感想をお伝えしたいと思います。 Google I/O 2018参加報告会での発表 堀江、権守、茨木が発表した内容について紹介します。 堀江「Paging Library Overview」 「Paging Library Overview」というタイトルで今回のI/Oで1.0がリリースされた Paging Library について発表しました。 Jetpack のArchitecture Componentsに含まれるPaging Libraryは、無限にスクロールするようなListの実装を非常に簡単にしてくれます。スクロール位置に応じたデータの追加ロードやPlaceHolder、Roomを利用したデータのキャッシュとDiffUtilによる差分更新など実装のしやすさとパフォーマンスにフォーカスされていてぜひ業務で使ってみたいと感じています。 デフォルトではRoomを使用する前提となっていますが、DataSourceを継承したクラスを自作することで様々なケースに柔軟に対応することが可能です。 こちらはPaging Libraryについてのセッションの動画です。ネットワークからのデータの取得からUIへの反映までアニメーションを交えて説明されていてわかりやすいです。PageKeyedDataSource、ItemKeyedDataSource、PositionalDataSourceの各種DataSource型についても解説されています。 Paging Libraryについてより理解を深めたい場合、 Codelab や Android Developers のドキュメントが参考になります。 権守「新しくなったMaterial Designを触ってみた」 I/Oで発表された Material Theme Editor の使い方を中心に、新しくなったMaterial Designを実装していく上での具体的な手順について発表しました。 Material ThemeはMaterial Designで利用するためのパーツ（ボタンやカードなど）のカタログのようなものです。Material Theme Editorを使うとTheme上のパーツの色やフォントなどを簡単に変えることができ、プロダクトに合ったThemeを作ることができます。プロダクトのデザインデータを作成する際にはThemeからパーツを選ぶ形で行うことになります。 Material Componentsの実装状況もあり、Material Themeから作ったデザイン全てをAndroid上にスムーズに実装できるとはまだ言えない状況だと思います。ですが、今後の発展次第ではデザイン実装が容易になることも期待できるものだと感じました。 茨木「フロントエンドの動向 From Google I/O 2018」 I/Oでフロントエンドに関するセッションを中心に聴講しました。また、CodelabsでWebAssemblyやPWAに関するコースを体験しました。報告会では、PWA・WebAssembly・JavaScriptの3点にフォーカスして発表しました。 PWA PWAに関してはログイン・決済APIや実際の運用例が紹介されていました。スターバックスの例が紹介されていましたが、ネイティブアプリに近いUXが印象的でした。 WebAssembly WebAssemblyに関してはコンパイル用ツールチェインであるemscriptenや、実際にWebAssemblyを使っているサービスの実例が紹介されました。サービスの実例で特に印象的だったのがAutoCADでした。ヘビーな計算やグラフィックスを伴うCADアプリケーションがブラウザで動作しているのが衝撃的でした。 JavaScript JavaScriptに関しては色々な発表がありましたが、特に印象的だったのがTensorFlow.jsのNode.js対応でした。GPUに対応していてパフォーマンスもPythonに匹敵するので、今後の機械学習ではJavaScriptも多く使われるようになるかもしれません。 Google I/O 2018で印象に残ったセッションの紹介 I/Oでは3日間に渡り様々なセッションが行われます。その中から堀江、権守、茨木が聴いて印象に残ったセッションをいくつか紹介します。 ML Kit: Machine Learning SDK for mobile developers ML Kitについてデモを交えながら紹介されています。Firebaseの一機能として公開されていて、ベースとなる5つの機能（Image labeling、Text recognition、Face detection、Barcode scanning、Landmark detection）を簡単に利用できます。それらで仕様を満たせない場合、カスタムモデルをアップロードすることでアプリから簡単に使用でき便利です。カスタムモデルのサイズを軽量化しつつ精度を維持する仕組みも興味深かったです。 Android Jetpack: easy background processing with WorkManager JetpackのArchitecture Componentsの1つとして公開されたWorkManagerについてのセッションです。 複数のbackground処理を繋げたり並列で実行するなど柔軟に処理を実行でき非常に便利です。 WorkManagerがどのように動作しているかの解説もあり面白いです。 Code beautiful UI with Flutter and Material Design Flutterで開発されたアプリ「SHRINE」に対してライブコーディングでMaterial Designを適用していくセッションです。 登壇者2人の発表が上手く、サクサクと進むライブコーディングは聴いていてとても楽しかったです。 また、Flutterでこんなに簡単にMaterial Designを適用できるのかと感動しました。 What's new with ConstraintLayout and Android Studio design tools Motion Editorによるアニメーションの作成は必見です。 What's new in Android Runtime アプリ実行中のログを集め、配布前にAPKを最適化することで起動を高速化するという話には驚きました。 Web performance made easy Lighthouseを使ったWebサイトのパフォーマンス改善について実例を用いて説明していてとてもわかりやすかったです。 Lighthouseの進歩を感じられるセッションでもありました。 Best practices for text on Android テキスト周りの細かい話も興味深かったですが、特にRecyclerView中のリンクに関するテクニックはぜひ取り入れたいと思いました。 Introducing .app domain names, and how to secure them .appドメインはHTTPSのみのドメインで、Google I/O初日の5/8に登録の受付が開始されました。Google I/Oの参加者には.appドメインを無料で取得する権利が与えられたので実際に取得してみました。 What’s new in Chrome DevTools Lighthouseとの連携やasync/awaitのデバッグが印象的でした。 Make your WordPress site progressive Webの30％を占めるWordPressに対し、メジャーなテンプレートをAMP対応させていくという内容でした。 Googleらしいアプローチで、なるほどと思いました。 感想 I/Oへ参加することで非常に良い経験ができました。 セッションを聴くことを中心に3日間を過ごしましたが、Office HoursとDesign Reviewにもっと積極的に行くべきだったと感じています。 生でセッションを聴くのも大切ですが、Googlerにその場で質問できる機会は貴重ですしセッションは後から見返すことができます。 次回のI/Oに参加できる場合にはこの点を踏まえスケジュールを組もうと思います。 加えて、KeynoteでのAIに関する発表やML Kitの発表を聴いてフロントエンドエンジニアでも 機械学習やディープラーニングの基礎を理解し、その上でサービスの開発に取り入れていく必要があると考えています。 そして、英語で聴く、話す力が足りないことを身に染みて実感しました。 I/Oに限らず英語を使う機会は弊社が海外展開を進めていく中で増えていくので継続的に勉強したいと思います。 最後に 今回のI/Oは会社の出張という形で参加しました。参加期間は業務扱いとなり、交通費なども含め会社からサポートされます。 国内外のカンファレンス参加についてサポートする体制が整っており非常にありがたく思います。 得られた知見を普段のサービス開発に生かしていこうと思います！ スタートトゥディテクノロジーズでは、一緒にサービスを作り上げてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください！ https://www.wantedly.com/companies/starttoday-tech/projects おまけ Day2の夜にコンサートが開かれるのですが完全にフェスでした。照明の使い方がすごい。 空いた時間でサンフランシスコを観光しました。西海岸の気候は最高ですね。 サンフランシスコにあるGitHub本社オフィスを訪ねました。事前に連絡せず行ったにも関わらずフレンドリーなお兄さんが案内してれました。 有名なOctocatの像が。残念ながら本社のGitHubストアはクローズしたとのこと。今後はOnline Shopのみでグッズを販売するとのことです。

（Headphones icon credit *1 ） こんにちは、2018新卒エンジニアの田島( @katsuyan121 )です。 新卒研修の一環としてZOZOTOWNカスタマーサポートセンターにてカスタマーサポート研修に参加しました。 研修を受けるまではエンジニアがカスタマーサポート研修を受ける必要があるのだろうかと疑問に思っていましたが、実際にやってみると学びが多く会社としてもメリットがあると感じました。 そこで、本記事ではカスタマーサポート研修の内容とそのメリットをご紹介します。 ZOZOTOWNカスタマーサポートセンターとは ZOZOTOWNカスタマーサポートセンターはお客様からのZOZOTOWNに関するお問い合わせを受け付けています。 「お客様と友達になる」を理念として掲げており、困っている友達を助けるように全力でお客様をサポートしお客様が笑顔になれるよう日々努めています。 また高品質なお客様サポートの結果、ZOZOTOWNカスタマーサポートセンターは「HDI-Japan」が定める「HDI 五つ星認証プログラム」において最高評価の「五つ星認証」をアパレル業界で初めて取得しています。詳細につきましては以下のリンクをご参照ください。 https://www.starttoday.jp/news/20170608-2030/ 研修の流れ 研修は以下のように行われました。 前半： 座学・ロープレで実践練習 後半： 実践（電話対応・チャット対応） 研修では実際にお客様対応を行うため、ZOZOTOWNの仕様やルールを学ぶ必要があります。そこで最初にZOZOTOWNについて研修担当者にみっちり教わりました。カスタマーサポートの方々はZOZOTOWNに詳しく、エンジニア以上にZOZOTOWNの仕様やルールを把握しているのではないのかと思うほどでした。 その後学んだことをふまえて研修担当者や研修生がお客様役としてお問い合わせをし、それに対応するというロープレを行いました。ロープレを行うことで学んだことを定着させることができ、座学だけでは見つけることができなかったイレギュラーケースや疑問点を解消できました。 一通りのことを学び終えると実践ということで実際にお客様からのお問い合わせに対する電話対応を行い、研修全体で1人約20件のお問い合わせに対応しました。最初のうちはうまく対応できるか不安でしたが、ロープレを何回も行っていたお陰でお客様の問題を解決することがでました。 またZOZOTOWNではカスタマーサポートとして電話だけでなく、メールやチャットでもお問い合わせを頂きます。そこで、チャット対応についても経験しました。電話とチャットでお問い合わせの内容がぜんぜん違うということが興味深かったです。 カスタマーサポート研修のメリット カスタマーサポートで感じたメリットを6つ紹介します。 サービス開発へのモチベーション向上 相手の背景を理解して話ができるようになる お客様が困っている温度感や細かいニュアンスを知ることができる サービス全体を把握できる 他部署がなにをやっているのかを知れる 部署外に頼れる仲間ができる 1. サービス開発へのモチベーション向上 エンジニアとして仕事をしているとお客様の声を直接聞くという機会がほとんどないですが、カスタマーサポート研修ではお客様の声を直接聞くことができました。お客様の声を直接聞いて感動したことがあります。それはZOZOTOWN側の不備に対してもすごく丁寧にお問い合わせをくださったり、お問い合わせの回答に対して感謝の言葉を頂くことが多かったことです。 お客様の声を直接聞いたことで、サービスの向こう側には実体をもったユーザがいるということに改めて気づくことができました。この経験から「もっとお客様のために良いサービスを作っていきたいな」と、サービス開発へのモチベーションが向上しました。 2. 相手の背景を理解して話ができるようになる 最初にも紹介しましたが、ZOZOTOWNカスタマーサポートセンターは「お客様と友達になる」を理念として掲げています。お客様と友達になるということを意識して会話をすることで、相手の背景を理解しベストな回答をできるようになります。 カスタマーサポートセンターにお問い合わせをしてくださるお客様は、お問い合わせしたい内容がまとまっているとは限りません。そのため相手の背景を理解したうえで会話をするということが非常に大切であることを身をもって体感しました。 「お客様と友達になる」というマインドは、カスタマーサポートにかぎらずエンジニアの領分でも必要になります。業務ではエンジニアに限らず様々なバックグラウンドを持つ人が関わってきます。そんな中で「友達になる」というマインドを忘れずに会話をすることで、スムーズにコミュニケーションを取ることができるようになりました。 3. お客様が困っている温度感や細かいニュアンスを知ることができる 普段の業務ではお客様の声はほとんど間接的に聞くことしかないため、それに対する対応の重要度が分からず後回しにしてしまうことがあります。 しかし直接お客様の声を聞くことで、どれだけお客様が困っているかの「温度感」を感じることができました。これをきっかけとして、後回しにしがちな問題が重要なものであると気づき取り組むきっかけになりました。 また直接お客様の声を聞くことで、サービスのどんな部分が使いにくいのかをエンジニア目線で細かいニュアンスまで感じることができました。これによって、お客様が使いやすいようなサービスを細部までこだわって作ることができます。そして今後のサービス開発においてどんなサービスが使いやすいか考える助けになると考えています。 4. サービス全体を把握できる カスタマーサポートセンターではお問い合わせに間違った情報を返答してはいけません。そこで、研修ではサービスの仕様やルールを覚える必要があります。 ZOZOTOWNの商品をユーザが購入し、どのような流れでお客様のところへ届くのかといったサービスの基本的な部分。ZOZOTOWNの商品が発送されてから大体いつお客様のもとへ届くのか。どういった支払い方法があり、どういった条件であればキャンセルができるのかといった細かい部分までを学びました。普段のエンジニアリング業務ではあまり気にすることがない、配送や決済の詳細な部分までも知ることができたことは大きな学びとなりました。 これらの内容はただ覚えるだけではなく、実際のお客様サポートの中でさらに理解を深めることができたと感じています。ZOZOTOWNをあまり使うことがなかった私ですが、今ではZOZOTOWNのサービス全体を把握できています。 5. 他部署がなにをやっているのかを知れる 3回目の紹介になりますが、ZOZOTOWNカスタマーサポートセンターは「お客様と友達になる」を理念に掲げています。カスタマーサポートセンターの人たちはこの理念に基づき、お客様が笑顔になってもらうためにどうすればいいのか考えながら行動していることが感じられてすごく感動しました。実際に同じ現場で仕事をすることによって、カスタマーサポートセンターの業務はもちろんその場で働く人達がどんな思いで働いているのかということを肌で感じることができました。 また現在ZOZOTOWNに関わる部署は20を超え、さらにオフィスや倉庫と働いている場所もバラバラでどんな人達が一緒に働いているのかなかなか把握しにくい状況となっています。カスタマーサポートセンターではあらゆるお問い合わせを頂くため、他部署との連携が最も多い部署です。そのため他部署がどんなことをやっているのか、どんな人達が同じ会社で働いているのかということを知ることができました。短い期間でサービスに誰がどのように関わっているのか、どんな思いで働いているのかを知ることができたのはカスタマーサポート研修であったからこそと感じています。 6. 部署外に頼れる仲間ができる 今回の研修は新卒エンジニアが6人参加しましたが、バックグラウンド・専門分野がバラバラなメンバーでした。研修に参加した全員がカスタマーサポートの経験がなかったため、カスタマーサポートという共通の話題により気軽に会話ができたと感じています。 研修の期間中は一緒の目的に対して取り組み、研修の中で感じたことや問題を共有することでかけがえのない仲間となりました。部署内で解決できない問題など気軽に聞ける仲間がいることは、個人的にすごく喜ばしいことであると感じています。 まとめ 研修を受けるまではエンジニアがカスタマーサポート研修を受ける必要があるのだろうかと疑問に思っていましたが、エンジニアとして大切なことを学ぶことができました。学んだことをサービスに還元して、カスタマーサポートセンターの人たちはじめ研修に関わってくださった人たちへの恩返しとなればと思っています。 この記事を読んで、カスタマーサポート研修を導入してみようと思っていただけたら幸いです。直接カスタマーサポート研修はどうだったか聞きたいという方がいましたらぜひ弊社まで遊びに来てください。 スタートトゥデイテクノロジーズではお客様に最高のサービスをお届けするためにエンジニアを募集しています。興味がありましたら、以下のリンクからご応募ください。 connpass.com *1 : Headphones icon: Icons made by Freepik from www.flaticon.com is licensed by Flaticon Basic License

こんにちは。zozoバックエンド部の廣瀬です。 弊社のサービスではDBMSとしてMicrosoft社のSQL Serverを使用している箇所があります。 本記事では、過去に経験したSQL Server関連のトラブル及びその調査内容をご紹介し、最後にトラブルシューティングを通して策定した統計情報の更新に関する方針をまとめます。 トラブル発生 ある日突然、SQL Serverが稼働しているサーバーのCPU使用率が高騰し、100％に張り付く状態が一定期間続きました。 CPU使用率のグラフを見ただけでは、なぜ突然高騰したのか原因は分かりません。 そのため、原因を特定するための調査を実施しました。 トラブルシューティング 同一ホスト上で稼働している主要なプロセスはSQL Serverしか無かったため、SQL Server上でCPUリソースを多く消費するようなクエリが実行されていることを疑いました。 現在実行中のクエリのステータスを確認するため、動的管理ビュー（Dynamic Management Viewの略。以下DMVと呼ぶ）を使用したクエリを実行します。 ※実行には VIEW SERVER STATE権限 が必要です。 SELECT TOP 500 dest.TEXT AS [Command text] ,( SELECT TOP ( 1 ) lastwaittype FROM master.dbo.sysprocesses WHERE spid = der.session_id ) AS lastwaittype ,datediff(s, der.start_time, GETDATE()) AS time_sec ,datediff(s, der.start_time, GETDATE()) / 60.0 AS time_min ,DB_NAME(der.database_id) AS DatabaseName ,der.command ,des.login_time ,des.[host_name] ,des.[program_name] ,der.session_id ,SUBSTRING(dest.TEXT, der.statement_start_offset / 2 , ( CASE WHEN der.statement_end_offset = - 1 THEN LEN(CONVERT(NVARCHAR(MAX), dest.TEXT)) * 2 ELSE der.statement_end_offset END - der.statement_start_offset ) / 2 ) AS current_running_stmt ,qp.* -- 実行プラン FROM sys.dm_exec_requests der INNER JOIN sys.dm_exec_connections DEC ON der.connection_id = DEC.connection_id INNER JOIN sys.dm_exec_sessions des ON des.session_id = der.session_id OUTER APPLY sys.dm_exec_sql_text(sql_handle) AS dest OUTER APPLY sys.dm_exec_query_plan(plan_handle) AS qp WHERE des.is_user_process = 1 AND datediff(s, der.start_time, GETDATE()) >= 1 ORDER BY datediff(s, der.start_time, GETDATE()) DESC 実行結果の一部を抜粋します。クエリの内容は伏せさせていただきますが、同一のクエリが多数実行中で、かつ最長で20秒間も実行中の状態でした。 また、lastwaittypeカラムの多くがCPU高負荷の際に発生することが多い SOS_SCHEDULER_YIELD となっており、突然のCPU使用率高騰との関連性が考えられます。 このクエリの平均のCPU使用時間を確認するため、さらに別のDMVを使ったクエリを実行します。 SELECT TOP 1000 [Average CPU used(ms)] = total_worker_time / qs.execution_count / 1000 ,[Total CPU used(ms)] = total_worker_time / 1000 ,[Execution count] = qs.execution_count ,[Individual Query] = SUBSTRING(qt.TEXT, qs.statement_start_offset / 2 , ( CASE WHEN qs.statement_end_offset = - 1 THEN LEN(CONVERT(NVARCHAR(MAX), qt.TEXT)) * 2 ELSE qs.statement_end_offset END - qs.statement_start_offset ) / 2 ) ,[Parent Query] = qt.TEXT ,DatabaseName = DB_NAME(qt.dbid) ,last_execution_time ,creation_time ,[Total Duration(ms)] = total_elapsed_time / 1000 ,[Average Duration(ms)] = total_elapsed_time / qs.execution_count / 1000 ,qp.* FROM sys.dm_exec_query_stats qs OUTER APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt OUTER APPLY sys.dm_exec_query_plan(plan_handle) AS qp WHERE qt.TEXT LIKE '%ここにストアド名やクエリの一部を指定することで絞り込む%' ORDER BY total_worker_time / qs.execution_count DESC 平均のCPU使用時間が約5秒と非常に長いです。 このクエリの1分当たりのクエリ実行回数を計算してみたところ、他のクエリと比べて実行頻度が高いようです。 したがってこのクエリによってCPU高負荷となった可能性が非常に高いと判断しました。 該当のクエリは、かなり前から実行されているクエリだったため、突然実行プランが狂った可能性を疑います。 DMVを使ったクエリでは推定実行プランは取得できますが、実際の実行プランもみれると嬉しいです。 そのためSSMS (SQL Server Management Studio)上で[実際の実行プランを含める]にチェックをつけた状態で該当クエリを実行しました。 ※実際の実行プランを取得する方法として、他には拡張イベントを使用する方法があります。 取得した実行プランの中で、キー参照を約50万回おこなっている箇所があり、ここがボトルネックのようです。 予測実行回数（6301.45）の約80倍も実行されていることが見て取れます。 ボトルネックが判明しましたが、今回はもともと十分な速さで実行されていたクエリが、突然遅くなったという事象です。 そのため、ボトルネックを改善するためのチューニング方法ではなく、なぜ突然CPU高負荷な実行プランが生成されてしまったかを考える必要があります。 原因として、統計情報が古くなっていたことを疑い、該当クエリで使用しているテーブルの 統計情報を更新 してみました。 --統計情報を更新するためのクエリ update statistics <テーブル名> その結果、下図のように問題ない速度で実行されるようになりました。 ※今回は統計情報の更新後にクエリがリコンパイルされることを期待し、期待通りリコンパイルされました。ただし、統計情報の更新＝必ずリコンパイル、というわけでもないようです。 https://www.brentozar.com/archive/2015/01/updating-statistics-cause-recompile-no-data-changed/ SQL Serverにおいて、統計情報は自動的に更新される仕組みも用意されています。ただしレコード数の20％が更新されたとき等、自動更新のためには条件を満たす必要があります。 今回のトラブルでは、自動更新が走る前に統計情報が古くなってしまったことで実行プランが狂ったと判断しました。そのため恒久的な対応策として1日1回、定期的に全テーブルの統計情報を更新するジョブを作成しました。 これで今回のトラブルシューティングは完了したはずでした。 トラブル再発 後日、またCPU高負荷な状態に陥ってしまいました。しかも犯人は同じクエリです。 何故だろうとクエリと再度にらめっこしていたところ、気づいたことがありました。それはレコード更新の性質がテーブルによって異なるということです。 クエリに登場するテーブルは開発時に使用した経験があり、各テーブルのレコード更新の性質についてたまたま熟知していました。 テーブルA : ユーザーの行動によって少しずつ自然に変化していく テーブルB : バッチ処理で定期的に一定のレコード数が変化する 対応策として実施した1日1回の定期的な統計情報の更新は、テーブルAのような性質を持ったテーブルには効果的でしたが、テーブルBに対しては効果が薄いようです。 よく「統計情報が古い」から実行プランがおかしくなったという表現を使いますが、これは決して統計情報の最終更新日から時間が経過している、という意味では無いと思い知らされました。 正確には「統計情報が古い」とは、「統計が実際のデータ分布と大きく乖離している」状態を指します。 そのためたとえ1時間前に統計情報を更新したばかりでも、バッチ処理等で大量にデータ更新された後では、現在の統計情報は「古い」といえます。 上記考察を踏まえて、定期的な統計情報の更新に加えて、バッチ処理等でレコード数に大きな変化がある場合は処理完了直後に統計情報の更新を実施するようにしました。 その結果、CPU高負荷になることはなくなりました。 統計情報の更新に関する方針 今回のトラブルシューティングを通して学んだ、統計情報の更新に関する方針をまとめます。 下記2点の方針で統計情報を更新することで、「統計情報が古い」ことに起因する実行プランの変化とそれに伴う実行速度の低下および、CPU使用率の上昇を避けることが期待できます。 ユーザーの行動等によって自然に少しずつレコード数が変化していく性質をもったテーブルは、1日1回等、定期的に統計情報を更新 バッチ処理等で、大量にレコード削除/挿入/更新を行う場合は、処理完了直後に統計情報を更新 統計情報更新のためのクエリ 全DBの全テーブルの統計情報を更新するための具体的なクエリも紹介します。こちらをSQL Serverのジョブとして定期的に実行する、などの方法が考えられます。 尚、SQL Serverの メンテナンスプラン にも統計情報更新の仕組みは用意されています。 ただしサンプル数を指定する際、全テーブル一律でフルスキャンまたは一定のサンプリングレートしか指定できないようです。 update statisticsを実行する際、サンプリングレート未指定の場合はテーブルのレコード数によって動的にサンプリングレートが決定されます。 この挙動を全テーブルに対する統計情報の更新処理で実現するために、自分でクエリを作成しました。 DECLARE @Database sysname ,@sql nvarchar( 2000 ) DECLARE CUpdateStatsDatabases CURSOR FAST_FORWARD FOR SELECT name FROM master.sys.databases WITH (NOLOCK) WHERE -- システムDBおよびディストリビューションDB除外、かつオンラインのDBに限定 Cast(CASE WHEN name IN ( 'master' , 'model' , 'msdb' , 'tempdb' ) THEN 1 ELSE is_distributor END As bit) = 0 AND state = 0 OPEN CUpdateStatsDatabases FETCH NEXT FROM CUpdatestatsDatabases INTO @Database -- DB単位のループ WHILE @@fetch_status = 0 BEGIN set @sql = '' -- useを使う必要があるが、use単体でexecuteすると実行後にコンテキストが現在のDBに戻ってしまう。そのため丸ごと動的SQLで実行する set @sql = @sql + ' USE ' + CAST(@Database AS NVARCHAR( 100 )) + ';' set @sql = @sql + ' DECLARE @sql_update nvarchar(500) ' set @sql = @sql + ' ,@Table sysname ' set @sql = @sql + ' ,@Schema sysname ' set @sql = @sql + ' DECLARE ' set @sql = @sql + ' CUpdateStatsTables_' + CAST(@Database AS NVARCHAR( 100 )) + ' CURSOR FAST_FORWARD FOR ' set @sql = @sql + ' SELECT ' set @sql = @sql + ' SCHEMA_NAME(schema_id) ' set @sql = @sql + ' ,name ' set @sql = @sql + ' FROM ' set @sql = @sql + ' sys.tables WITH(NOLOCK) ' set @sql = @sql + ' ' set @sql = @sql + ' OPEN CUpdateStatsTables_' + CAST(@Database AS NVARCHAR( 100 )) + ' ' set @sql = @sql + ' FETCH NEXT FROM CUpdateStatsTables_' + CAST(@Database AS NVARCHAR( 100 )) + ' INTO ' set @sql = @sql + ' @Schema, @Table ' set @sql = @sql + ' ' -- テーブル単位のループ ' set @sql = @sql + ' WHILE @@fetch_status = 0 ' set @sql = @sql + ' BEGIN ' set @sql = @sql + ' ' set @sql = @sql + ' set @sql_update = ''update statistics '' + CAST(@Schema AS VARCHAR(100)) + ''.'' + CAST(@Table AS VARCHAR(500)) ' set @sql = @sql + ' execute sp_executesql @sql_update ' set @sql = @sql + ' select @sql_update ' set @sql = @sql + ' ' set @sql = @sql + ' FETCH NEXT FROM CUpdateStatsTables_' + CAST(@Database AS NVARCHAR( 100 )) + ' INTO ' set @sql = @sql + ' @Schema, @Table ' set @sql = @sql + ' END ' set @sql = @sql + ' ' set @sql = @sql + ' CLOSE CUpdateStatsTables_' + CAST(@Database AS NVARCHAR( 100 )) + ' ' set @sql = @sql + ' DEALLOCATE CUpdateStatsTables_' + CAST(@Database AS NVARCHAR( 100 )) + ' ' execute sp_executesql @sql FETCH NEXT FROM CUpdatestatsDatabases INTO @Database END CLOSE CUpdateStatsDatabases DEALLOCATE CUpdateStatsDatabases それでも残る再発の可能性 仮に統計情報をサンプリングレート100％でフルスキャンし、かつ定期的な更新で最新の状態に保ち続けたとしても、クエリが突然遅くなる可能性はまだあります。 ストアドプロシージャやパラメータ化クエリの場合、SQL Serverはコンパイル時に渡されたパラメータを考慮して、最適な実行プランを生成します（パラメータスニッフィングと呼ばれています）。 この時に渡されたパラメータがたまたま非典型パラメータの場合、それ以外の典型的なパラメータにとっては遅い実行プランになってしまう恐れがあります。 Microsoftのブログ の中で、ストアドプロシージャであればwith recompileを指定するなど、実行時に強制的に毎回コンパイルさせることで非典型パラメータに関する問題を回避させる案が紹介されています。 こちらは効果的ですが、毎回コンパイルの分だけ実行時間とCPU使用時間が増大してしまい、ユーザーおよびサーバーにとってマイナスの側面もあります。そのためできる限り使用は避けるべきと考えています。 その他の対策としてはOPTIMIZE FOR UNKNOWNという クエリヒント を使用する方法もあります。 こちらはクエリのコンパイルおよび最適化の際に、その時渡されたパラメータ値ではなく、統計データを使用するよう指定するヒントです。 まとめ 本記事では、実際に経験したSQL Serverに関するトラブルから学んだ統計情報の更新に関する方針について紹介しました。 本記事に出てくる技術的な内容や調査用のクエリはほとんどWeb上で既出の内容かと思います。 しかしながら個々の知識を組み合わせて実際に起きたトラブルを調査し、解決まで至ったというプロセスを紹介する記事はあまり無いように思います。 本記事がトラブルシューティングの実例として参考になれば幸いです。 スタートトゥディテクノロジーズでは、一緒にサービスを作り上げてくれるエンジニアを大募集中しています。 ご興味のある方は、こちらからご応募ください！ https://www.starttoday-tech.com/recruit/

こんにちは！ 最近暑いのでビール最高と感じている新事業創造部バックエンドエンジニアのりほやんです。 今回はAppleが提供しているお試し価格の機能のひとつである無料トライアル機能を紹介します。 お試し価格とは お試し価格とは自動更新の定期購読に対して割引価格を設定したり、定期購読の開始時に一定の無料トライアル期間を設けることができる機能です。 お試し価格には都度払い、前払い、無料トライアルの3種類があります。 お試し価格はユーザーにとって、有料会員の体験ができるとても便利な機能です。 しかし公式ドキュメント以外の資料が少なく実装に何点か困ったことがありました。 そこで今回はお試し価格の無料トライアル機能を導入する方法についてご紹介します。 この記事が無料トライアルを導入しようか悩んでいる方、実際に無料トライアルを導入する方のお役に立てば幸いです。 本記事では、課金機能自体の実装の説明は行いません。 自動更新の定期購読のサーバーサイド実装については、こちらの記事を参考になります。 tech.starttoday-tech.com tech.starttoday-tech.com 無料トライアルとは 無料トライアル機能について 公式サイト には下記のように説明されています。 一定期間無料で定期購読を利用できるようにする方法です。定期購読はすぐに開始されますが、無料トライアル期間が終了するまで請求が行われることはありません。定期購読を試してもらいながら、請求が発生する前にキャンセルすることもできるようにする場合に効果的です。 この機能は通常と同じフローで課金処理が行われますが、実際にユーザーにはお金が請求されません。 無料トライアル指定できる日数は『3日・1週間・2週間・1か月・2か月・3か月・6か月・1年』の8種類です。 注意する点 お試し価格の対象ユーザーは一度もお試し価格を利用したことが無いユーザーです。 そのため現在課金中のユーザーも、無料トライアルを利用したことが無いユーザーは再課金時に無料トライアルを利用できます。 適用の条件を図にするとこのようになります。 https://developer.apple.com/documentation/storekit/in_app_purchase/offering_introductory_prices_in_your_app またフローチャートで表すと下記のようになります。 既に課金機能をリリース済みのサービスに対して無料トライアル機能を追加する場合は、再課金時に無料トライアル適用されるユーザーと適用されないユーザーがいることに注意してください。 実際に適用してみる 無料トライアルを実際に適用する場合は以下の2つの作業を行う必要があります。 iTunes Connect上で無料トライアルを適用する アプリケーション側で、購入レシートから無料トライアルかどうかを判断する 『アプリケーション側で、購入レシートから無料トライアルかどうかを判断する』処理については、再課金時に無料トライアルの適用対象かを判断する場合に用います。 無料トライアルを利用したユーザーが課金を終了し再課金した場合はお試し価格が適用されないため、無料トライアル機能へ誘導することはできません。 このような表示の出し分けに使用することもできるため、ユーザーが無料トライアルを利用したことがあるかどうかの情報はDB上に保存することをおすすめします。 iTunes Connect上で無料トライアルを適用する iTunes Connect上で無料トライアル機能を適用します。 お試し機能は課金アイテムごとに適用する必要があります。 1. iTunes Connectにログイン iTunes Connect にアクセスし、 マイAppから無料トライアルを適用したいアプリのページに移動します。 2. 課金アイテムに移動 iTunes Connect上で無料トライアルを適用したい課金アイテムのページに移動します。 3. お試し価格を適用する ＋ボタンをクリック お試し価格を適用する地域を選びます。 特に指定がない場合は、『すべてのテリトリ』を選択します。 お試し価格の開始日と終了日を選択します。 開始日はお試し価格を開始させたい日です。すぐに始めたい場合はその当日を選択します。 終了日はお試し価格を終了させたい日です。特に決まっていない場合は『終了日なし』を選択します。 お試し価格のタイプを選択します。 今回は無料トライアルを行うため、無料トライアルを選択します。 また無料トライアルが行える期間を選択し、終了をクリックします。 保存ボタンを押します。 これで無料トライアルの設定ができました。 課金アイテム画面の登録価格から無料トライアルが適用されていることを確認してください。 注意点 iTunes Connect上で無料トライアルの設定を行う際に、注意すべきポイントがいくつかあったのでご紹介します。 適用されるまでのタイムラグ サイト上で適用する際の文言は『いますぐ適用』と書いてありますが、実際に使ったところ設定反映までに30~40分のタイムラグがありました。 終了する際も同様に、30〜40分タイムラグがありました。 タイムラグがあることについてはどの資料にも記載されておらず、実装時にとても困りました。 実際に無料トライアル機能が適用されているか確認するには、課金画面を確認します。 下記の画面になっていれば無料トライアルが適用されています。 課金は1度しかされない ユーザーは1つのアプリに対して、無料トライアルは1度しか適用されません。 課金アイテムが複数ある場合も、1度でも無料トライアルを利用したユーザーは違う課金アイテムを購入しても無料トライアルは適用されないため注意が必要です。 レシートから無料トライアルかどうかを判別する方法 次にAppleから取得するレシートから無料トライアルかどうかを判別する方法についてご紹介します。 Appleから取得する定期購読型のレシートは下記のようになっています。 { "quantity": "1", "product_id": "monthly_paid_1", "transaction_id": "12345678901234", "original_transaction_id": "12345678901234", "purchase_date": "2000-01-01 00:00:00 Etc/GMT", "purchase_date_ms": "12345678901234", "purchase_date_pst": "2000-01-01 00:00:00 America/Los_Angeles", "original_purchase_date": "2001-01-01 00:00:00 Etc/GMT", "original_purchase_date_ms": "1234567890123415", "original_purchase_date_pst": "2001-01-01 00:00:00 America/Los_Angeles", "expires_date": "2001-01-01 00:00:00 Etc/GMT", "expires_date_ms": "12345678901234", "expires_date_pst": "2001-01-01 00:00:00 America/Los_Angeles", "web_order_line_item_id": "1234567890123456", "is_trial_period": "true" } 取得したレシートが、無料トライアル中かどうかを判定するためには、レシート内の is_trial_period を確認します。 is_trial_period が true だった場合は、無料トライアルのレシートです。 また通常 expires_date は購入したプランの終了日になりますが、無料トライアルのレシートの場合 expires_date が無料トライアル終了日になっています。 お試し価格が終わった際のレシート お試し価格期間後は下記の2パターンが存在します。 定期購読を継続する 無料トライアル中に定期購読をキャンセルする 定期購読を継続している場合 無料トライアル期間終了後に、 is_trial_period が false のレシートが最新レシートとして取得できます。 { "quantity": "1", "product_id": "monthly_paid_1", "transaction_id": "12345678901234", "original_transaction_id": "12345678901234", "purchase_date": "2000-01-01 00:00:00 Etc/GMT", "purchase_date_ms": "12345678901234", "purchase_date_pst": "2000-01-01 00:00:00 America/Los_Angeles", "original_purchase_date": "2001-01-01 00:00:00 Etc/GMT", "original_purchase_date_ms": "1234567890123415", "original_purchase_date_pst": "2001-01-01 00:00:00 America/Los_Angeles", "expires_date": "2001-01-01 00:00:00 Etc/GMT", "expires_date_ms": "12345678901234", "expires_date_pst": "2001-01-01 00:00:00 America/Los_Angeles", "web_order_line_item_id": "1234567890123456", "is_trial_period": "false" } 定期購読を継続している場合に取得するレシートは、下記のようになっています。 is_trial_period が false expires_date が購入したプランの終了日 このような状態の場合は、ユーザーが継続課金をしているとみなします。 無料トライアル中に定期購読をキャンセル 無料トライアル中に定期購読をキャンセルした場合は、期間終了後にAppleからレシートが送られてこないことに注意してください。 こちら側でAppleにレシートを問い合わせる必要があります。 無料トライアル中に定期購読をキャンセルした場合、レシートは下記のような状態になります。 is_trial_period が true expires_date が現在時刻より過去 このような状態の場合は、ユーザーが継続課金をキャンセルしたとみなします。 無料トライアル中 無料トライアル中に定期購読をキャンセルした場合 無料トライアル後に課金を継続した場合 それぞれの場合 is_trial_period と expires_date がどのような状態になるかをまとめると以下のようになります。 状態 is_trial_period expires_date 無料トライアル中 true 現在時刻より未来 無料トライアル中に定期購読をキャンセル true 現在時刻より過去 無料トライアル後に課金を継続 false 現在時刻より未来 注意する点 Sandbox環境で無料トライアル中のキャンセルができない Sandbox環境で無料トライアルを適用した場合、必ず無料トライアル後課金が継続されます。 継続課金が何回続くかはランダムですが、無料トライアルだけで課金が終了することはありません。 そのため無料トライアル中にキャンセルした場合の検証が行えません。 まとめ 本記事ではiOSアプリのお試し価格の1つである無料トライアル機能についてご紹介しました。 無料トライアル機能はユーザーにとって、有料会員の体験ができるとても有用な機能です。 しかし実際に無料トライアル機能を適用する上で、公式ドキュメントに記載されていないことや注意すべきポイントがいくつかありました。 公式ドキュメント以外にほとんど資料がなかったため、本記事では無料トライアル機能についてまとめてみました。 無料トライアルの導入を検討している方、実際に導入する方のお役に立てば幸いです。 スタートトゥディテクノロジーズでは、一緒にサービスを作り上げてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください！ www.starttoday-tech.com starttoday-tech.connpass.com 参考リンク Offering Introductory Prices in Your App 定期購読を提供する プロモーション用の App 内課金の追加（iOS） 価格および配信状況

こんにちは。zozoフロントエンド部の大平です。さだまさし好きが昂じて社内では「さださん」と呼ばれています。 計測してますか？ 皆さん計測していますか？ 何かを改善しようとした場合、パフォーマンスを数値化し、その内容をもとに改善案を考えて行動することが、基本的な取り組み方になります。 そして、いかに現状を測定可能な状態にし数値化可能な指標を設定するか、という事が取り組みの第一歩になります。ダイエットや体質改善でもそうですし、英語など語学学習でもそうだと思います。 ということで、計測はとても大事です。 私事ですが、私は最近さだまさしさんのファンが集うコミュニティに参加しています。古くからのファンの方々はさだまさしさんのデビュー時からずっと追っかけている猛者も多く、私みたいな若輩者の青二才は圧倒的な「さだ力」の不足を感じる毎日です。 最近、コミュニティの中で「 楽曲検定 」というサイトが流行しました。このサイトではiTunesの試聴データを用いてアーティストの楽曲のイントロクイズを提供しています。 さだまさしさんは今年デビュー45週年を迎え、作った楽曲は550曲を超えると言われています。多すぎて覚えられないよとの一部ファン（私）のため息が漏れる中、2018年もまだ新曲を出す予定のようです。 そんな「ビッグデータ」を相手にしても、先輩さだファンは 「配信曲全て出題、間違ったら即終了 全曲編」 という鬼畜にも程がある問題を選択し、皆軽く全問正解していきます。無論私も全問正解するのですが、さだコミュニティの中では全楽曲を知っているのがベースラインとなり、「さだ力」を表現するKPIとして機能しません。 なので、最近はストップウォッチを片手にタイムトライアルを個人的に実施するようにし、日々の日課にしています。「さだ力」のKPIを楽曲数やクイズの正答数ではなく、 「MSPS (Masashi Sada Per Sec)」 においたわけです。 最初は普通のノートPCを使っていたのですが、時間を計測することによりトラックパッドによるマウスカーソルの移動に予想以上に時間を要している事に気づきました。 抜本的な改善のためには道具が必要ですので、Chrome OS/Android OSのハイブリッド利用が可能な Chromebook を導入し、画面のタッチパネルを使用する事により大幅に時間短縮を果たしました。 今では調子のよい時は「曲視聴~回答~次の問題選択」の一連の流れを1曲あたり2秒台（0.3~0.5 MSPS）で実現できるようになりました。しかしあまりに動きが速すぎるためかサイトがフリーズしてしまうことが頻発するようになってしまったのが悩みです。 Datadogについて よくわからない事を書いてしまいましたが、ここから本論に入ります。 弊社内ではいくつかのサービスを開発運営しておりますが、サービスの安定稼働を実現するためにMonitoringツールを用いた監視を行っています。 各サービス利用しているツールは様々なのですが、私が現在担当しているシステムでは Datadog をメインの監視ツールとして使用しています。 ご存知の方も多いと思いますが、DatadogはNewYorkを拠点にサービスを展開しているいわゆるMonitoring SaaSです。日本においてはMackerelがMonitoring SaaSとしては有名ですが、Datadogはグローバルで使用ユーザーが多いサービスの1つとして知られています。 以下のグラフは、 SRECon というイベントでのアンケート結果です。 NewRelic などと拮抗して来場者の多くが使用しているツールであることが見て取れます。 Datadogの利点は数多いですが、ここでは私の主観でいくつかピックアップします。 豊富なグラフ表現とカスタマイズ性 Datadogの他のMonitoring Toolと比べたアドバンテージは、非常にリッチなグラフ表現をドラッグ&ドロップで簡単に実現できるところにあるかなと思います。 たとえば以下のようなDashboardを手軽に作成できます。 Slackとの連携が容易 現代的な開発エンジニアの間ではSlackなどのチャットツールがコミュニケーションのハブになっており、そこに情報を集約することが開発効率の向上や情報共有の円滑化につながります。 Mackerelなどでも同様の機能がありますが、DatadogではSlackなどに対してグラフ付きでメッセージやアラートを通知する機能をもっており、チーム内でのコラボレーションに非常に有益です。 豊富なAPI DashboardやAlertingの設定は画面からでも行なえますが、Datadogは豊富なAPIを提供しているためそれらの操作をAPIを介して半自動化することも可能です。 よく使われている事例としては、 Barkdog などのツールを用いたAlertingの設定のDSL化かなと思います。 Barkdogを用いると設定をGitHubなどで管理でき、差分管理やCIツールと連携した適用の自動化などを実現することが可能です。 Service Integration 豊富なService Integrationの機能もDatadogの魅力です。 AWS CloudWatchの情報や、NewRelicなどの他のMonitoring Toolの情報などを簡単な設定でDatadogに取り込む事ができます。この機能を用いることでDashboardの情報をDatadogに一元化することが可能になります。 また、Datadogの情報を入力ソースとして他のシステムと連携することもできます。代表的な事例は Pagerduty などのOn-Callツールとの連携です。Datadogのメトリクス内容を使用して特定の閾値に達したらPagerdutyのEscalation Flowに基いて障害通知を行う、といった事が実現できます。 Docker Integration そして、最近は Kubernetes の流行などもあり、Docker/Docker Orchestration環境とMonitoring Toolの連携も必要になってきています。この辺については後段で詳しく触れます。 Kubernetes環境との連携 ということで、DatadogとKubernetesの連携について、AutoDiscovery機能を軸に少しだけ深掘りします。 たとえばKubernetes上にPodを展開すると、設定によってはAuto Scaling/Self HealingにてPod数がダイナミックに増減します。どのHost Computer上にどのPodが置かれるかは基本的にはKubernetesが管理することになり、人間が介在し事前に把握することが難しいです。 またDocker imageの中に必ず監視ツールを同梱する、もしくはSide-Car的に1対1で設置するというのも効率が悪いです。 ですのでMonitoring Toolは、何かしらの方法で現在動作しているPodの存在を自動的に把握し、監視対象とする仕組みが必要になります。 その仕組をサポートするものとして、PrometheusではService Discovery機能があります。これによりKubernetesクラスタ上に存在するServiceやPod、Ingressといったものの追跡が可能になっています。 https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3CKubernetes_sd_config%3E 同様に、Datadogには AutoDiscovery 機能があり、これによりPrometheusのService Discoveryと同様の機能を実現できます。 設定内容など詳しくは以下のQiitaに記事を書きましたので、こちらも参照ください。 Datadog の AutoDiscovery 機能を用いて自動的に Kubernetes pod の監視をする 現場では、以下のようなメトリクスについてAutoDiscoveryの機能を用いて取得しています。 nginxのメトリクス (/nginx_status) Spring Bootのメトリクス Prometheus Exporter経由で取得できるようにしています Datadog を用いて Prometheus Exporter の監視をする Docker時代/Kubernetes時代のMonitoring Toolには、このようなDiscovery機能が必須になってきていると思います。そして、Prometheus同様、Datadogはそういう時代の変化に追随しているサービスだなと感じており、組織の中でも重用しています。 STTクラウド技術共有会 少し話題が変わりますが、先日4月1日に会社が改組されたこともあり、これをひとつのきっかけに社内の技術者が組織を横断して集う情報の共有会を行いました。 技術分野は多岐に渡るため分科会的にいくつかの会を設けており、私はクラウド関連の技術についてディスカッションする会に参加しています。 先日開催された初回ではMonitoring Toolについてをテーマに開催されました。 どうしても監視周りはシステムの導入時期や担当エンジニアの嗜好なども影響します。そのため採用しているツールは各チームまちまちでしたが、その状況が共有できたこと、それぞれのPros/Consや導入の背景が理解できたことは良かったです。 とはいえ各チームとも以下については共通しており、同じ時代を同じ組織の中でともに歩むエンジニアとして、同じ方向性を見れていることを知れた事も有益でした。 クラウドネイティブなツールを使って管理コストを減らしたい、というモチベーションが強い 設定はDSL化してGitHub管理している Slackへの通知など、コミュニケーションツールとの連携を重視している このような会を定期的に開催し、各チームや各エンジニアの考えていることや取り組みを可視化しMonitoringすることも、とても大事なことだなと感じています。 まとめにかえて Datadogについて、そしてMonitoringについてとりとめなく記事を書かせていただきました。 社内でよく話すのですが、Monitoringはひとつの手段でしかなく、目的ではありません。たとえば今回ご紹介したDatadogは本当によく出来たツールで、こちらにメトリクスを流し込んでグラフを作成しただけで何かしら言い知れぬ達成感・全能感があったりします。 しかし、技術者に求められているのは測定することだけではなく、 「システムをいかに安定稼働させるか」「そのためにいかにシステムの状況を正確に知るか」 にあります。 そして、Monitoringした内容等を基に 「仕事やサービスに対していかに効果的なアクションを取るか」 が、本当に求められていることです。 ついつい技術者は目の前の手段にとらわれがちですが、こういう意識を忘れずに、日々サービスを改善をしていければと思います。 私が「さだ力」を向上したいと思っているのも 「えー、さだまさしの事そんなに詳しいんだ、すごーい」 と女の子にキャッキャウフフともてはやされることが目的ですので、本来のゴールを見失わないよう日々慎ましく生きていきたいと思います。 [AD] 弊社では、さだまさしに対する愛情は必ずしも必要ないですが、情熱をもってサービスを支えるエンジニアを募集しております。 ブログでの情報発信の他に、弊社では月一回のペースでMeetupイベントなども開催しております。皆様との交流を通じて、我々の行っている取り組みや、我々のサービスにかける思いを知っていただく場をもっと増やして行こうと考えておりますので、ご興味を持たれた方はぜひぜひご参加いただければと存じます。 starttoday-tech.connpass.com www.starttoday-tech.com

iOSチームの @hiragram です。 所属するプロジェクトでは依存管理にCarthageを使っていますが、Carthageの成果物である Carthage/ 以下をコミットするかどうかはよく議論になる話題かと思います。 私はコミットしない派なので、そのメリットを残しつつデメリットをなくすためにやってみたことを紹介します。 メリットとデメリット コミットしない派のメリット リポジトリが肥大化しない 以前のプロジェクトでは Carthage/ 以下をコミットしていて、リポジトリがめちゃでかくなってcloneにめちゃ時間がかかる感じになっていました。 diffがうるさくならない 言わずもがな。 Xcodeのバージョンを積極的に上げられる SwiftのABI安定化はまだ先なので、コミットされたバイナリはそれをビルドしたのと同じバージョンのSwiftからしか扱えない。 Swift.org - ABI Dashboard Swift ABI Stability Manifesto 複数人で開発していると、新しいバージョンのSwiftでコンパイルされたバイナリをmasterへ取り込む時に、全員せーのでXcodeのバージョンを上げなきゃいけなくなる。 XcodeやSwiftのアップデートに追随していく精神的な妨げになるのでよくない。 コミットしない派のデメリット cloneしたあとすぐにアプリが使えない これそんなにデメリットに思わない。 make install とか昔やってましたよね…？ CIコンテナの上で依存パッケージもビルドするとえらい時間がかかる 「時間がかかる」を解消するために筋悪選択をしてしまうのはちょっとなーという気がする Bitriseにはソリューションがありそう　 https://discuss.bitrise.io/t/how-to-cache-carthage-dependencies/197 異なる依存パッケージをもつブランチ間を移動するたびに再ビルドしないといけない 確かに。 同じ依存パッケージをもつブランチ間での移動では再ビルドは必要ないが、それが必要なのかぱっと分からない 確かに。 異なる依存パッケージをもつブランチ間を移動するたびに再ビルドしないといけない 同じ依存パッケージをもつブランチ間での移動では再ビルドは必要ないが、そもそも必要なのかどうかぱっと分からない 今回はこれを解決する方法を考えてみました。 どのように解決するか 課題解決の要件はこのようにします。 ブランチ切り替えによって Cartfile.resolved が変わった時に毎回再ビルドするのは時間がもったいないので、過去にその依存パッケージ郡をビルドしたことがあったら再ビルドはしなくていいようにする 必要な場合は再ビルドしないとアプリのビルドが通らないようにする = 不要な場合はそのままアプリがビルドできる Cartfile.resolved と Carthage/ 以下のファイルは1対1で対応するはずです。即ち、 Cartfile.resolved の中身ごとに Carthage/ 以下をキャッシュしておけばブランチ切替時の再ビルドが不要になるはずです。 （厳密にはそうではない。後述します） シンボリックリンクを活用し、以下のようなディレクトリ構成にしました。 $ tree -L 5 . ├── Cartfile ├── Cartfile.resolved ├── Carthage -> CarthageCache/`なんらかの識別子` ├── CarthageCache │ └── `なんらかの識別子` │ └── Build │ └── iOS │ ├── RxBlocking.framework │ ├── RxCocoa.framework │ ├── RxSwift.framework │ └── RxTest.framework . . . $ carthage update （or bootstrap ）で出来た Carthage/ ディレクトリを CarthageCache/なんらかの識別子/ に移動し、 Carthage ディレクトリの代わりにそこへのシンボリックリンクを置きます。 先程「 Cartfile.resolved と Carthage/ 以下は1対1に対応する」と書きましたが、実は正確ではありません。Carthageは --configuration Debug のようにビルド設定を指定することが出来ます。 Cartfile.resolved の中身だけで識別子を作ってしまうと、その中身がデバッグビルドなのかリリースビルドなのかわからなくなってしまいます。 そこで「なんらかの識別子」は、 Cartfile.resolved のチェックサムにビルド設定（ Release or Debug ）を付加したものにします。 Xcodeのプロジェクトにフレームワークを追加する時は、このシンボリックリンク経由のパスで追加します（コツがいります。後述します）。 そしてXcodeのBuild Phaseの先頭で、適宜シンボリックリンクの向き先を変えるようにします。 こんな感じでしょうか。 実装と導入 carthage_hack.sh こんなシェルスクリプトを書きました。 まず、普段使っている $ carthage update や $ carthage bootstrap は今後このコマンドで置き換えます。 $ ./carthage_hack.sh [update|bootstrap] [Release|Debug] このコマンドは、 Carthageでビルド できた Carthage/ ディレクトリからフレームワークを CarthageCache/識別子/Build/iOS/ 以下に移動 Carthage/ ディレクトリを削除してそこにシンボリックリンクを設置 を行います。 また、 $ ./carthage_hack.sh symlink [Release|Debug] このコマンドは現在の Cartfile.resolved と引数に渡したビルド設定に該当するディレクトリを向いたシンボリックリンクを張ります。これはXcodeのBuild PhaseのCompile Sourcesの手前にRun script phaseを追加し ./carthage_hack.sh symlink ${CONFIGURATION} こう呼び出しています。 ${CONFIGURATION} はXcodeの環境変数でアプリの現在のビルド設定が入っているので、「アプリはリリースビルドなのに依存フレームワークがデバッグビルドのままだった」という事故を防ぎます。 問題 あとはシンボリックリンク経由のパスでフレームワークをプロジェクトに追加するだけですが、ここで困ってしまいました。 FinderからXcodeにファイルをドラッグ&ドロップで追加する時、シンボリックリンク経由のパスではなく実体のパスで追加されてしまいます（Add filesからやっても同じ）。 これではシンボリックリンクの切り替えによる恩恵が受けられません。 苦肉の策感が否めないですが、以下のような方法で回避出来ました。 シンボリックリンク Carthage を Folder referenceとして プロジェクトに追加する Folder referenceの中のファイルを直接プロジェクト内で使えないようなので、さらにもうひと手間 New group without folder で作ったプロジェクト内の別のGroupに Xcodeのファイルツリーから ドラッグ&ドロップで追加 Finderを経由しなければシンボリックリンク経由のパスとして追加できる ちなみに、画像でいうDependenciesグループが空の状態だと正しく追加できますが、既に何か入ってるところにさらにFolder reference越しにファイルを追加しようとするとおかしなファイル移動が起きたりそれを戻そうとするとXcodeが落ちたりしました。 回避するためには毎回Dependenciesを空にする必要がありそうです。今はプロジェクト初期で依存パッケージが少ないのであまり問題になりませんが、多くなってくると大変かもしれません。 結果 要件を満たせたか確認してみます。 まず、デバッグビルドで依存パッケージをビルドします。 $ ./carthage_hack.sh bootstrap Debug $ tree -L 5 . ├── Cartfile ├── Cartfile.resolved ├── Carthage -> CarthageCache/c0480ba77cbcf45447d7e0ee1e2f25cb92d83e33cf4a38635015c676f91837af-Debug ├── CarthageCache │ └── c0480ba77cbcf45447d7e0ee1e2f25cb92d83e33cf4a38635015c676f91837af-Debug │ └── Build │ └── iOS │ ├── RxBlocking.framework │ ├── RxCocoa.framework │ ├── RxSwift.framework │ └── RxTest.framework . . . Xcodeにフレームワークを追加して、アプリをデバッグビルドしてみます。 通りました。 では、次にアプリをリリースビルドしてみます。 Failed to read file or folder at /Users/hiragram/Development/teikibin-ios/Carthage/Build/iOS/RxSwift.framework Command /bin/sh failed with exit code 1 RxSwift.framework が見つからないと言われてビルドが失敗しました。 リリースビルドのフレームワークはまだ無いのでこれも正しいです。 リリースビルドで依存パッケージをビルドします。 $ ./carthage_hack bootstrap Release $ tree -L 5 . ├── Cartfile ├── Cartfile.resolved ├── Carthage -> CarthageCache/c0480ba77cbcf45447d7e0ee1e2f25cb92d83e33cf4a38635015c676f91837af-Release # 向き先がReleaseに変わった ├── CarthageCache │ ├── c0480ba77cbcf45447d7e0ee1e2f25cb92d83e33cf4a38635015c676f91837af-Debug │ │ └── Build │ │ └── iOS │ │ ├── RxBlocking.framework │ │ ├── RxCocoa.framework │ │ ├── RxSwift.framework │ │ └── RxTest.framework │ └── c0480ba77cbcf45447d7e0ee1e2f25cb92d83e33cf4a38635015c676f91837af-Release # リリースビルドのフレームワークが置かれた │ └── Build │ └── iOS │ ├── RxBlocking.framework │ ├── RxCocoa.framework │ ├── RxSwift.framework │ └── RxTest.framework . . . アプリをもう一度リリースビルドしてみます。 今度は通りました。 次に、 Cartfile で指定しているフレームワークのバージョンを変えて再ビルドしてみます。 すると、 Cartfile.resolved の中身も変わるので別の識別子でシンボリックリンクが作られました。 $ tree -L 5 . ├── Cartfile ├── Cartfile.resolved ├── Carthage -> CarthageCache/5a4a9fb30dcc42dc98d9982e141446e2544b89b1ecac779d665ff76af7466228-Debug # 新しいほうに切り替わった ├── CarthageCache │ ├── 5a4a9fb30dcc42dc98d9982e141446e2544b89b1ecac779d665ff76af7466228-Debug # 増えた │ │ └── Build │ │ └── iOS │ │ ├── RxBlocking.framework │ │ ├── RxCocoa.framework │ │ ├── RxSwift.framework │ │ └── RxTest.framework │ ├── c0480ba77cbcf45447d7e0ee1e2f25cb92d83e33cf4a38635015c676f91837af-Debug │ │ └── Build │ │ └── iOS │ │ ├── RxBlocking.framework │ │ ├── RxCocoa.framework │ │ ├── RxSwift.framework │ │ └── RxTest.framework │ └── c0480ba77cbcf45447d7e0ee1e2f25cb92d83e33cf4a38635015c676f91837af-Release │ └── Build │ └── iOS │ ├── RxBlocking.framework │ ├── RxCocoa.framework │ ├── RxSwift.framework │ └── RxTest.framework . . . これで、例えばフレームワークのバージョンを上げる作業をしているブランチとmasterブランチの間を移動しても、Build Phaseの先頭でシンボリックリンクが切り替わる仕組みによって 一度すればそれ以降再ビルドが不要になりました。 逆に一度もビルドしていないときは、リリースビルドのフレームワークが見つからなかったときと同様にアプリのビルドが失敗するので 間違ったバージョンを使ってしまう心配もありません。 いい感じじゃないでしょうか。 まとめ この仕組みはまだ導入したばかりなので、まだ遭遇していないシーンで困ることがあるかもしれません。その時はまた何か考えます。 この仕組みによって、コンパイル済フレームワークをコミットすることで得られるメリットの1つ「間違ったバイナリを使ってしまうことがない」が得られたのではないでしょうか。更にこのやり方であれば、リリースビルドとデバッグビルドを間違えることもなくなります。 今後はこういった開発環境を健全に保つための仕組みづくりをどんどんやっていこうと思っています。こういう取り組みに興味を持っていただけた方、是非ご連絡下さい。お待ちしています。

VASILY CTOの今村です。 今日はこのブログを普段からご覧頂いている皆様にお知らせがあります。 本日発表させていただきました通り、スタートトゥデイ工務店、VASILY、カラクルの3社が統合され 新会社「スタートトゥデイテクノロジーズ」が誕生いたしました。 http://press.starttoday-tech.com/entry/20180402_news press.starttoday-tech.com それに伴い、VASILYテックブログは本日をもって、 「スタートトゥデイテクノロジーズ テックブログ」として新しく生まれ変わります。 このテックブログでは約6年半に渡り、VASILYが運営するサービスに纏わる様々な技術的内容をお届けしてきました。 実際にこのブログから発信される記事を通して、VASILYを知ってくれたエンジニアの読者の方も多いと思います。 今後はスタートトゥデイテクノロジーズとして、 ZOZOTOWN、WEAR、おまかせ定期便やスタートトゥデイ研究所など 様々な内容をベースにその裏側を支える技術的な記事を投稿していきたいと思います。 まさに今日から始まったばかりのスタートトゥデイテクノロジーズですが、 既存事業のさらなる拡大、テクノロジードリブンな新規事業を創造すべく、 この会社の黎明期にリーダーシップを発揮することができる博士やエンジニア、アナリストやデザイナー、プロデューサーなど 様々な領域の「天才」「逸材」たちを募集します！ 少しでも興味のある方はぜひ、スタートトゥデイテクノロジーズホームページ内の特設ページをご覧ください。 ご応募お待ちしております！ https://www.starttoday-tech.com/recruit/genius/ www.starttoday-tech.com

こんにちは、フロントエンド開発部マネージャーの荒井です。今回はVASILYフロントエンドチームの体制、開発手法、マネージャーの役割について紹介したいと思います。 はじめに 私はエンジニアの採用担当もしているのですが、会う方に「どのように開発をしているのですか？」「リファクタリングの工数は取れていますか？」といった質問をよく頂きます。働く上で事業ドメインや採用技術も重要ですが、同様に日々のタスクの進め方、チーム体制を重要視している方も多いようです。今回はVASILYのフロントエンドチームの体制、開発手法について紹介します。 フロントエンドチームの役割 まず初めにフロントエンドチームの業務範囲を説明します。 VASILYフロントエンドチームは大きく3つのプラットフォームを担っています。 Webアプリケーション開発 iOSアプリケーション開発 Androidアプリケーション開発 ネイティブアプリケーションを「アプリ開発部」などとして分けている企業も多いかと思いますが、VASILYではすべてまとめて「フロントエンド開発事業部」としています。 Kotlin、Swift、 Ruby、JavaScriptといった言語を使用しており、HTMLやCSSをコーディングするのもフロントエンドチームの役割です。 チーム体制 現在は6名の体制で開発を進めています。 多くの企業では明確に役割分担されており、専任が多いと思います。VASILYのフロントエンドチームの変わったところは、プラットフォームの垣根を取り払って開発をすることもある点です。下記図のようにすべてのプラットフォームを担当してるメンバーも2名います。 プロダクション環境に反映されるmasterブランチへのマージはコードレビューが必至となります。コードレビューの体制を整える都合上、各プラットフォームは最小で2名としています。案件に応じて2〜4名で開発しています。 専任と兼任 元々複数のプラットフォーム経験のあるメンバーが揃っていたわけではなく、兼任メンバーは働き初めてから学習期間を設けてコンバートしました。現在Android開発が出来るメンバーは4名となっていますが、元々Android開発を行っていたのは1名で、iOSから1名、Webから2名増えています。 複数のプラットフォームに精通するメンバーが増えることで、案件に応じて柔軟なリソース配分が可能となりました。また、特定のメンバーに負荷がかかることを避けるメリットもあります。 兼任 個人のキャリアパスを無視して業務命令で兼任とさせることはしていません。 以下のことは大事にしています。 他のプラットフォーム開発に興味があるメンバー 学習期間を設ける 有識者のもとで開発をする Android開発は Udacity にて基礎を学び、はじめはベテランのAndroidエンジニアのもとで小さいタスクから行なっていきました。学習方法については随時振り返りを行い手法を変えていっています。 専任 iOSのみ開発するメンバーも2名います。Swiftという言語に興味があり、キャリアパスとしても現状iOSの開発に力を入れたいというメンバーは専任としています。個々がモチベーションを保てる業務内容であることが大前提で、それを踏まえた上でチームとしてリソース配分をしていくことが重要です。 技術の選定 異なるプラットフォームの実装をするには負荷がかかります。その負荷を軽減するためには技術選定も重要です。直近ですとiOS、AndroidではReactiveXを取り入れて開発を進めるといった取り組みをしています。同じパラダイムを採用することでプラットフォームを跨いだ時の負荷を軽減しています。 開発手法 プラットフォームやプロジェクトにもよりますが、多くのプロジェクトでは1〜2週間のスプリントで開発を行っています。現在アクティブなプロジェクトでは以下のような役割分担で行っています。 プロダクトオーナー 開発チーム マネージャー 前述した6名は開発チームにあたります。 役割 プロダクトオーナー プロダクトの方向性を決定します。プロダクト開発における優先順がついたタスクリストであるプロダクトバックログを作成します。殆どの場合、開発チームに直接の指示は出していません。 開発チーム プロダクトバックログに記載されているタスクの工数を見積もります。見積もった結果、マネージャーと共に、どの機能まで次のスプリントに入れるかを決定します。ここで決定したスプリントバックログの進捗をマネージャーが管理していきます。 マネージャー 作成されたスプリントバックログが問題なく完了するように調整していきます。フロントエンド事業部として持つタスクの優先度をつけ、開発チームに「差し込み案件」などが来ないようにします。案件は様々発生してしまうため、その場合、開発メンバーに流れないように開発したりします。 スプリント 2週間の間には以下のことが行われます。 スプリントバックログの作成 開発 QA リリース プロダクトオーナー、デザイナーも含めたQAが完了し、機能がリリースされるとそのスプリントは完了とみなされます。プロジェクトによっては Measure というステータスを設け、実施した施策に対する測定を行なってから DONE へ移行するようにしています。 マネージャーの役割 マネージャーの業務は多岐に渡ります。また、私自身がエンジニアのマネージャーとして大切にしたいことは多々あるのですが、今回は質問が多い「リファクタリング」「新しい技術の導入」の観点に絞って紹介します。 アカウンタビリティ 「リファクタリング」も「新しい技術の導入」も率先して行なっています。リファクタリング用に工数を取りますし、タスクの調整も行なっています。その時に必要なのが「アカウンタビリティ（説明責任）」です。「何故リファクタリングが必要なのか」を明確にする必要があります。幸い会社が開発に対して理解があるので揉めたことは一度もありませんが、説明は意識するようにしています。 新しい技術導入も同様です。VASILYには「 エンジニアマニフェスト 」が存在しており、新しい技術の導入にはポジティブです。しかし、手当たり次第新しいことを試すのではなく、「何の課題を解決するのか」は全員が考えて選定しています。これが担保されるのならば会社として実績がないことでも挑戦する機会を設ける方針です。 開発チームのタスク 新しいことを始めるには学習コストがかかりますし、日々の業務でも集中して作業する時間が必要です。「集計依頼が頻繁にきて開発時間が確保出来ない」等の問題が出来るだけ起きないように意識しています。VASILYにおいてスクラムマスターは存在していませんが、チームとしてスピードが出るように障害を取り除いていくポジションという意味では近しい役割を担っています。 まとめ 今回はフロントエンド事業部の紹介をしました。チームによって様々ですが、VASILYの開発スタイルが少しでも伝われば幸いです。現在エンジニアのマネージャーは私しかいません。一緒にマネージャーとしてチームを作って行ける方、是非ご連絡ください。また、こんなチームで働いてみたいなと思った方は是非一度オフィスへ遊びに来てください。お待ちしております。

データサイエンティストの中村です。 webで発生するトランザクション（購買など）の中には、確率分布を仮定することで抽象化できる物があります。 今回は、トランザクションが発生する現象をモデリングする手法のひとつであるBG/NBDモデルと、この手法にもとづいて将来発生するトランザクションの回数を予測するためのライブラリである lifetimes を紹介します。 トランザクションのモデリングについて 1987年にSchmittlein等によってPareto/NBDというモデルが提案されました。これは顧客の継続的に発生する購買行動に確率分布を当てはめ抽象化する手法で、結果として将来発生する購買を予測することに成功しました。顧客が離脱したか否かの判断や顧客生涯価値の見積もりが可能になるという点で、Pareto/NBDモデルは顧客分析における非常に強力なツールのひとつです。 Pareto/NBDをベースとして改良されたモデルはいくつか存在し、Fader等によって提案されたBG/NBDモデルもそのひとつです。BG/NBDモデルはPareto/NBDに用いられたデータ表現にアレンジを加え、精度を損なわずシンプルに改良したモデルです。 本来これらのモデルは購買行動を分析対象として設計されたものですが、後述する仮定に嵌まるものであれば、購買行動以外の現象にも適用できます。以降はwebのデータを想定して、用語をユーザーとトランザクションに統一します。 BG/NBDモデル データ 観測期間中に発生した、あるユーザーに由来するトランザクションの回数を とします（最初のトランザクションを0回目とカウントする）。 回目のトランザクションが発生した時刻を、0回目のトランザクションを起点として で表します。すなわち、観測期間中の最後のトランザクションは となります。また、0回目のトランザクションから観測終了までの時間を とおきます。 データに対する仮定 ユーザー個人に由来するトランザクションに対して、以下の仮定を敷きます。 i. ユーザーは生存/離脱を示す2値の状態を持ち、生存のときのみトランザクションが発生する。状態は観測されない。 最初のトランザクションが観測された時点で生存となり、この状態である限りはトランザクションがランダムに発生します。ユーザーがサービスを離脱した時、以降トランザクションは発生せず、このユーザーは再び生存状態になることはありません。 生存/離脱を正確に見積もることはターゲティングの観点から非常に重要です。 ii. ユーザーが生存中は、観測期間中に発生するトランザクションの回数は単位時間を としてパラメータ のPoisson分布に従う。 同時に、Poisson分布と指数分布の関係から、トランザクションの時間間隔は指数分布に従うことが言えます。 はモデルのパラメータで、トランザクションの発生率のような量を表します。 iii. パラメータ はGamma分布に従う。 iv. トランザクションの発生後にユーザーが離脱する確率は一定で 、 とする。 すなわち、 回目のトランザクション後にユーザーが離脱する確率は幾何分布で表現できます。 正直、確率変数に を使いたくないですが、表記は元の論文に合わせます。 v. パラメータ はBeta分布に従う。 そして、ユーザー全体に対する仮定として、ユーザーの特性を示すパラメータ は独立とします。 をユーザーのインデックス、 をユーザー数として、 モデルの入力は 、ユーザー個人の行動を制御するパラメータは 、モデルのパラメータは となります。 尤度関数の導出 本記事では導出過程を一部省略します。全体が気になる方はFader05をご覧ください。 観測期間中に 回のトランザクションが観測され、 ]にトランザクションが発生していない時の尤度は、以下のようになります。 の時、 ]にトランザクションが発生しないので、 の時、 で離脱した場合と まで生存しながら ]にトランザクションが発生しない場合を考慮して、 上記2式をクロネッカーのデルタを使って書き直します。 次に、パラメータ の周辺化を試みます。事前分布を用いて となります。式の見た目は屈強ですが計算は意外と簡単です。 に関する積分と に関する積分は別々に計算できますし、確率密度関数と正規化項の関係を利用して楽ができます。 よって目的関数は以下のようになります。 推論時に重要な指標 Fader05ではトランザクションの回数に関する確率である やその期待値 ]の導出が述べられています。式を書き写すだけになるので本記事では扱いません。 の条件付き事後分布 それぞれ混合分布の形になると思います。私の手計算につき間違えている可能性もあるので、おかしな部分を発見した場合はご指摘ください。 のとき、 のとき、 lifetimesについて lifetimes はトランザクションデータからユーザーの生存/離脱を推定し、未来に発生するトランザクションやユーザーの生涯価値を予測するためのライブラリです。生データをほぼそのまま食わせることができるため非常に簡単に使えます。 github: https://github.com/CamDavidsonPilon/lifetimes docs: http://lifetimes.readthedocs.io/en/latest/ 公式のdocumentationにて使い方が丁寧に紹介されています。詳細はそちらを参照いただくとして、本記事ではかいつまんで紹介します。 ちなみに、本記事では購買データの代わりにIQONのコーデ投稿のログを用いています。 データの加工 ほとんど必要ありません。生ログからユーザーIDとdateのみ抽出して pandas.DataFrame にロードします。 In [ 4 ]: transactions.head() Out[ 4 ]: transaction_id user_id date 0 100001 2533078 2017 -08- 18 1 100002 2489799 2017 -08- 18 2 100003 2595561 2017 -08- 18 3 100004 2391692 2017 -08- 18 4 100005 2515961 2017 -08- 18 トランザクションの集計は lifetimes.utils.summary_data_from_transaction_data や lifetimes.utils.calibration_and_holdout_data にDataFrameを食わせるだけです。 In [ 5 ]: summary_calib_holdout = calibration_and_holdout_data(transactions, 'user_id' , 'date' , ...: calibration_period_end= '2017-06-30' , ...: observation_period_end= '2017-12-31' , ...: freq= 'D' ) ...: summary_calib_holdout.head() ...: Out[ 5 ]: frequency_cal recency_cal T_cal frequency_holdout \ user_id 7 0.0 0.0 93.0 0.0 77 0.0 0.0 156.0 1.0 260 0.0 0.0 93.0 0.0 1468 11.0 132.0 140.0 0.0 1938 40.0 134.0 175.0 12.0 duration_holdout user_id 7 184 77 184 260 184 1468 184 1938 184 学習 scikit-learn と同じように fit を実行します。 bgf = BetaGeoFitter(penalizer_coef= 0.0 ) bgf.fit(summary_calib_holdout.frequency_cal, summary_calib_holdout.recency_cal, summary_calib_holdout.T_cal) サポートしているアルゴリズムは github をご確認ください。 可視化 可視化の為の関数は充実しています。 例えば、キャリブレーションとホールドアウトそれぞれの期間で発生したトランザクションのトラジェクトリーを描画するには、以下の関数に学習済みモデルを渡すだけです。 plot_calibration_purchases_vs_holdout_purchases(bgf, summary_cal_holdout, n= 20 ) オレンジがモデルの予測で青が実測です。モデルの予測と実際のトランザクション数が概ね一致している事が確認できます。 サンプルコード というほどのものでもないですが、実験に使ったJupyter Notebookを載せておきます。 後半では、周辺化した をMCMCで復元してみました。モデルパラメータ はユーザー全体の特徴を表現する値でしたが、 を復元することでユーザー個人を分析することができます。 MCMCのスクリプトはNotebookと同じgistに公開しました。 モデルの制約 Pareto/NBDやBG/NBDモデルでは、 定常的に発生するトランザクションをモデル化したもので、周期性のある購買行動や広告などの影響は説明できない 一度離脱したユーザーは二度と復帰しない というかなり強い制約があります。したがってこの手法を適用する前はデータの性質をよく観察しておく必要があります。 モデルの制約を緩める方向に発展させた手法は存在し、例えばRemoro13はユーザーの状態が変化することを許容し、HMMで状態遷移をモデル化しています。 まとめ VASILYでは、最新の研究にアンテナを張りながら、同時にユーザーの課題解決を積極的に行うメンバーを募集しています。 興味のある方はこちらからご応募ください。 https://www.wantedly.com/projects/109351 www.wantedly.com 参考 David C. Schmittlein, Donald G. Morrison, Richard Colombo, Counting Your Customers: Who-Are They and What Will They Do Next?, 1987. Peter S. Fader, Bruce G. S. Hardie, Ka Lok Lee, “Counting Your Customers” the Easy Way: An Alternative to the Pareto/NBD Model, 2005. Jaime Romero, Ralf van der Lans, Berend Wierenga, A Partially Hidden Markov Model of Customer Dynamics for CLV Measurement, 2013.

こんにちは。フロントエンドエンジニアの遠藤です。 皆さん、ConstraintLayoutを使用していますか？ 弊社では最近、ほとんどのレイアウトをConstraintLayoutを使用して実装しています。 今回はConstraintLayoutを使用してレイアウトを組んだ際に便利だなと思ったポイントや難しくてはまったことについて紹介したいと思います。 今回はConstraintLayoutを使用したレイアウトの組み方について注目するので、基本的な使い方については説明しません。 ConstraintLayoutの基本的な使い方は下記の記事が分かりやすくておすすめです。 Google Developer Yukiの枝折: ConstraintLayout 実用例 今回はConstraintLayout1.1.0-beta5を使用しています。 サンプルコードはGitHubにあげてあります。 github.com 1. Chainを利用した複数要素の中央寄せ 例えば次のようなデザインを実装することを考えます。 このデザインは、コンテンツと閉じるボタンを合わせて中央寄せする必要があります。 今まではrootにFrameLayout、中央のコンテンツにRelativeLayoutを使用してレイアウトをネストすることで実装していました。 <FrameLayout xmlns : android = "http://schemas.android.com/apk/res/android" android : layout_width = "match_parent" android : layout_height = "match_parent" android : background = "@color/background_color_dialog" > <RelativeLayout android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : layout_gravity = "center" > <View android : id = "@+id/background" android : layout_width = "240dp" android : layout_height = "250dp" android : background = "@drawable/background_white_corner_radius" /> <TextView android : id = "@+id/title" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : layout_alignTop = "@id/background" android : layout_centerHorizontal = "true" android : layout_marginTop = "20dp" android : text = "@string/sample_1_title" android : textColor = "@color/colorAccent" android : textSize = "15sp" android : textStyle = "bold" /> ・・・ <TextView android : id = "@+id/dismissLink" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : layout_below = "@id/background" android : layout_centerHorizontal = "true" android : layout_marginTop = "20dp" android : text = "@string/sample_1_dismiss" android : textColor = "@android:color/white" /> </RelativeLayout> </FrameLayout> しかし、ConstraintLayoutのchainという仕組みを使うことでレイアウトをネストすることなく2つの要素を中央に配置することが出来ます。 <android . support . constraint . ConstraintLayout xmlns : android = "http://schemas.android.com/apk/res/android" xmlns : app = "http://schemas.android.com/apk/res-auto" android : layout_width = "match_parent" android : layout_height = "match_parent" android : background = "@color/background_color_dialog" > <View android : id = "@+id/background" android : layout_width = "240dp" android : layout_height = "250dp" android : background = "@drawable/background_white_corner_radius" app : layout_constraintBottom_toBottomOf = "parent" app : layout_constraintLeft_toLeftOf = "parent" app : layout_constraintRight_toRightOf = "parent" app : layout_constraintTop_toTopOf = "parent" app : layout_constraintVertical_chainStyle = "packed" /> <TextView android : id = "@+id/title" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : layout_marginTop = "20dp" android : text = "@string/sample_1_title" android : textColor = "@color/colorAccent" android : textSize = "15sp" android : textStyle = "bold" app : layout_constraintLeft_toLeftOf = "@id/background" app : layout_constraintRight_toRightOf = "@id/background" app : layout_constraintTop_toTopOf = "@id/background" /> ・・・ <TextView android : id = "@+id/dismissLink" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : layout_marginTop = "20dp" android : text = "@string/sample_1_dismiss" android : textColor = "@android:color/white" app : layout_constraintBottom_toBottomOf = "parent" app : layout_constraintLeft_toLeftOf = "parent" app : layout_constraintRight_toRightOf = "parent" app : layout_constraintTop_toBottomOf = "@id/background" /> </android . support . constraint . ConstraintLayout> ConstraintLayoutのChainは制約を要素どうし双方向に設定することでグループのように扱えます。 Chainにはいくつか種類があり、今回はグループ化した要素を詰めて表示したいため packed を使用しています。詳しくは こちら をご参照下さい。 2. ネガティブマージンの設定方法 このような重なっているデザインを実装する際に、四角枠の左上にバツボタンを配置してネガティブマージンを使用してデザインを実装する方法を思い浮かべるのではないでしょうか。 しかし、ConstraintLayoutで layout_marginTop に-20dpを設定しても反映されません。 ConstraintLayoutでネガティブマージンを表現するには少し工夫が必要になります。 こちらの記事 でGoogleのデベロッパーが Space を使用する方法を紹介しています。 今回の例を実装するには、四角枠の左上側にSpaceの右下側を配置するようにします。 そのSpaceの左上側にバツボタンの左上側を配置すると表現できます。 <android . support . constraint . ConstraintLayout xmlns : android = "http://schemas.android.com/apk/res/android" xmlns : app = "http://schemas.android.com/apk/res-auto" android : layout_width = "match_parent" android : layout_height = "match_parent" > <View android : id = "@+id/contentsBackground" android : layout_width = "100dp" android : layout_height = "100dp" android : background = "@drawable/background_gray_corner_radius" app : layout_constraintBottom_toBottomOf = "parent" app : layout_constraintLeft_toLeftOf = "parent" app : layout_constraintRight_toRightOf = "parent" app : layout_constraintTop_toTopOf = "parent" /> <android . support . v7 . widget . AppCompatImageView android : id = "@+id/android" android : layout_width = "80dp" android : layout_height = "80dp" app : layout_constraintBottom_toBottomOf = "@id/contentsBackground" app : layout_constraintLeft_toLeftOf = "@id/contentsBackground" app : layout_constraintRight_toRightOf = "@id/contentsBackground" app : layout_constraintTop_toTopOf = "@id/contentsBackground" app : srcCompat = "@drawable/ic_android" /> <Space android : id = "@+id/negativeMargin" android : layout_width = "15dp" android : layout_height = "15dp" app : layout_constraintBottom_toTopOf = "@id/contentsBackground" app : layout_constraintRight_toLeftOf = "@id/contentsBackground" /> <android . support . v7 . widget . AppCompatImageView android : layout_width = "40dp" android : layout_height = "40dp" app : layout_constraintLeft_toLeftOf = "@id/negativeMargin" app : layout_constraintTop_toTopOf = "@id/negativeMargin" app : srcCompat = "@drawable/ic_close_vector" /> </android . support . constraint . ConstraintLayout> 3. 文字の省略とレイアウト寄せ リストで文章を表示するときに全てを表示せずに省略して表示するデザインは多いです。 今回、以下のような文章の横にテキストを配置しているレイアウトを組むのが難しくとてもはまってしまいました。 文章を省略する 文章を省略するのに ellipsize を設定しますが、ConstraintLayoutを使用している場合それだけでは省略されません。 layout_constrainedWidth にtrueを設定する必要があります。 これを設定することで、きちんと文章が省略されるようになります。 文章と「既読」ラベルを左に寄せて表示させる 順を追って説明します。 文章と、「既読」ラベル、日付の要素をchainしてpackedを設定してしまうと以下の図のように表示されます。 文章と「既読」ラベルを左寄せで表示させたいので、日付との双方向の制約を外してChianしないようにします。 しかし、文章が長いときに日付とかぶらないように「既読」ラベルを日付の左側に配置するという制約は残しておきます。 これで、文章と「既読」ラベルだけがグループになります。 これだけは左寄せにならないのでbiasを設定します。 これで文章と「既読」ラベルが左に寄って表示されるようになります。 以下、上記のデザインのxmlです。 <android . support . constraint . ConstraintLayout xmlns : android = "http://schemas.android.com/apk/res/android" xmlns : app = "http://schemas.android.com/apk/res-auto" android : layout_width = "match_parent" android : layout_height = "100dp" > <android . support . v7 . widget . AppCompatImageView android : id = "@+id/imageView" android : layout_width = "80dp" android : layout_height = "80dp" android : layout_marginStart = "8dp" app : layout_constraintBottom_toBottomOf = "parent" app : layout_constraintStart_toStartOf = "parent" app : layout_constraintTop_toTopOf = "parent" app : srcCompat = "@drawable/ic_android" /> <TextView android : id = "@+id/nameLabel" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : layout_marginStart = "16dp" android : ellipsize = "end" android : lines = "1" android : scrollHorizontally = "true" android : textColor = "@color/text_color_black" android : textSize = "18sp" android : textStyle = "bold" app : layout_constrainedWidth = "true" app : layout_constraintEnd_toStartOf = "@id/dateLabel" app : layout_constraintHorizontal_bias = "0" app : layout_constraintStart_toEndOf = "@id/imageView" app : layout_constraintTop_toTopOf = "@id/imageView" /> <TextView android : id = "@+id/dateLabel" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : layout_marginEnd = "16dp" android : textColor = "@color/text_color_gray" android : textSize = "15sp" app : layout_constraintBottom_toBottomOf = "parent" app : layout_constraintEnd_toEndOf = "parent" app : layout_constraintTop_toTopOf = "parent" /> <TextView android : id = "@+id/messageLabel" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : layout_marginEnd = "8dp" android : layout_marginStart = "16dp" android : layout_marginTop = "8dp" android : ellipsize = "end" android : lines = "1" android : textColor = "@color/text_color_black" android : textSize = "15sp" app : layout_constrainedWidth = "true" app : layout_constraintEnd_toStartOf = "@id/readLabel" app : layout_constraintHorizontal_bias = "0" app : layout_constraintHorizontal_chainStyle = "packed" app : layout_constraintStart_toEndOf = "@id/imageView" app : layout_constraintTop_toBottomOf = "@id/nameLabel" /> <TextView android : id = "@+id/readLabel" android : layout_width = "wrap_content" android : layout_height = "wrap_content" android : layout_marginEnd = "8dp" android : layout_marginStart = "2dp" android : ellipsize = "end" android : lines = "1" android : scrollHorizontally = "true" android : text = "@string/sample_2_read_label" android : textColor = "@color/text_color_gray" android : textSize = "12sp" app : layout_constraintBaseline_toBaselineOf = "@id/messageLabel" app : layout_constraintEnd_toStartOf = "@id/dateLabel" app : layout_constraintStart_toEndOf = "@id/messageLabel" /> </android . support . constraint . ConstraintLayout> まとめ ConstraintLayoutを使用したレイアウトの組み方の実用例でした。 ConstraintLayoutは表現力が高く、柔軟に要素を配置することができるのですごく便利です。 レイアウトを組む際に参考として見ていただけると幸いです。 最後に VASILYではデザイン実装にこだわりを持っているエンジニアを募集しています。 少しでも興味がある方は以下のリンクからお申し込みください。

こんにちは、VASILYで主にAndroid開発を担当している @Horie1024 です。先日 potatotips #48 で「Alexa、APKを配布して」というタイトルでLTさせて頂きました。 資料は以下になりますが、本投稿では、Alexaスキルの仕組みから最終的にAPKが配布されるまでを出来る限り詳細に解説していきます。 目次 目次 AlexaでAPKを配布する流れ Alexaスキル開発事始め Alexaスキルの仕組み 対話モデル インテントとスロット サンプル発話 インテントスキーマ APKを配布するスキルの作成 Amazon developerへの登録 Alexaメニューの表示 スキルの作成 対話モデルの作成 設定（AWS Lambdaエンドポイントの指定） Serverlessを利用したAWS Lambdaエンドポイントの開発 Serverlessのインストール テンプレートから雛形プロジェクト作成 必要なライブラリの追加 serverless.ymlの更新 Alexaに対応したLambda functionの実装方法 Bitriseの設定 セットアップ Workflows DeployGateへのAPKのアップロード AWS LambdaからのBitriseのビルドのトリガー AWS Lambdaへのデプロイ IAMの作成 認証情報の登録 デプロイ シミュレータでのテスト 実機でのテスト 公開情報の入力 プライバシーコンプライアンスの入力 テスターへの追加とベータテストの開始 まとめ 最後に AlexaでAPKを配布する流れ 最初にAPKを配布するまでの全体の流れについて概要を示します。 ユーザーがAlexa対応デバイス（Amazon echoなど）に対して音声でAPKの配布指示を出し実際に配布されるまでの流れは以下のようになります。 ユーザーが「Alexa、BitriseでAPKを配布して」と発話 Alexaサービスでの発話の処理とAWS Lambdaエンドポイントへのリクエスト Lambda FunctionでBitriseのビルドをトリガー APKのビルドとDeployGateへのアップロード DeployGateを経由したAPKの配布 ユーザーの音声をAlexaが理解し、AWS Lambdaエンドポイントを経由してBitriseでのビルドを動かす事でAPKを配布します。 Alexaスキル開発事始め Alexaに開発者によって追加された機能を スキル と呼びます。Alexaスキルには以下のような種類があります。 カスタムスキル : 汎用のスキル スマートホームスキル : 家電製品などを制御するスキル フラッシュブリーフィングスキル : ニュースなどを読み上げるスキル APKを配布するスキルはカスタムスキルにあたり、スマートホームスキルやフラッシュブリーフィングスキルは使用しません。 Alexaスキルの仕組み Alexaがユーザーの発話を受けてレスポンスを返すまでの流れは以下のようになります。 引用： Alexaスキル開発トレーニングシリーズ 第1回 初めてのスキル開発 ユーザーが発話し、Alexa対応デバイスからレスポンスを受け取るまでを順番に見ていきましょう。 ユーザーがAlexa対応デバイスに発話 デバイスはマイクで集音した音声データをAlexaサービスに送信 Alexaサービスは音声データを解析し、AWS Lambdaを呼び出して解析結果を伝達 Lambdaはスキルの処理を実行し、結果をAlexaサービスにレスポンスとして返却 Alexaサービスはレスポンスに応じた音声データを生成、デバイスに返信 デバイスは音声データを再生し、ユーザーに結果を伝達 この流れを実現するために開発者が行うことは以下の2点です。 対話モデル と呼ばれるユーザーの音声をAlexaサービスに理解させるためのルールの設定 対話モデルによる解析結果に応じて実行する AWS Lambdaエンドポイント の開発 対話モデル 以下の画像は対話モデルとAWS Lambdaエンドポイントの関係を表す図です。 引用： Alexaスキル開発トレーニングシリーズ 第2回 対話モデルとAlexa SDK Alexaサービスは、対話モデルによってユーザーの発する音声データを理解しAWS Lambdaエンドポイントを呼び出します。 対話モデルは、 インテントとスロット および サンプル発話 から構成されます。 インテントとスロット AlexaサービスがAWS Lambdaエンドポイントを呼び出す際のリクエストは、 インテント と スロット からなります。スロットはユーザーの音声データのうち特定の型（日付や都市名）に当てはまるものを値として受け取れる変数のようなものです。APKを配布するスキルでは使用しません。 インテント（Androidエンジニアには親しみやすい名前ですね！）はユーザーの要望や意図を表し、スキルはインテントに応じた振る舞いを行うようにします。インテントは1つのスキルで複数定義することが可能です。 引用： Alexaスキル開発トレーニングシリーズ 第2回 対話モデルとAlexa SDK また、インテントには標準の組み込みインテントがあり、それらも利用できます。以下は主な組み込みインテントです。 インテント名 概要 AMAZON.HelpIntent スキルの使い方を尋ねるインテント AMAZON.StopIntent 処理やスキルを終了させるインテント その他の組み込みインテントについては Built-in Intent Library を参照してください。 さて、ではAPKを配布するスキルはどのようなインテント名が良いでしょうか。APKを配布するという要望を表した DistributeApk とします。 サンプル発話 サンプル発話は、ユーザーの発話を適切なインテントとスロットに紐付けるための例文です。APKを配布する例文として以下を想定します。例文を増やすほど様々な言い回しに対応できますが、この3通りで恐らく問題ないでしょう。 apk を 配布して apk を 配布 apk を 配って 実際にユーザーがスキルを使用する場合、アレクサ + 呼び出し名 + サンプル発話 の形で発話することになります。呼び出し名はスキルを識別するためのprefixで必ず必要になります。 インテントスキーマ インテントとスロット、サンプル発話はインテントスキーマというJSON形式でスキルに設定されます。これによって、ユーザーの発話がサンプル発話の例文に当てはまる場合、インテント名がDistributeApkとしてリクエストがAWS Lambdaエンドポイントに送られます。 { " intents ": [ { " name ": " DistributeApk ", " slots ": [] , " samples ": [ " apk を 配布して ", " apk を 配布 ", " apk を 配って " ] } ] , " types ": [] } APKを配布するスキルの作成 ここからは、Amazon developerのAlexaコンソールにアクセスし、実際にスキルを作成する流れを紹介します。 Amazon developerへの登録 Amazon developerポータル へアクセスし、アカウントを作成します。この時ハマりやすいポイントがあるので注意してください。 Alexa 開発者アカウント作成時のハマりどころ を読んでからアカウントを作成することをオススメします。 Alexaメニューの表示 ログイン後ALEXAタブをクリックし以下のような画面を表示し、「Alexa Skills Kit」の始めるをクリックします。 スキルの作成 「新しいスキルを追加する」をクリックするとスキルの情報を入力する画面が表示されるので埋めていきます。 以下のように入力しています。呼び出し名がカタカナの方が認識されやすいです。 項目 値 スキルの種類 カスタム対話モデル 言語 Japanese スキル名 Distribute Apk 呼び出し名 ビットライズ 呼び出し名にビットライズを指定することで、ユーザーは「アレクサ、ビットライズで○○」という発話でスキルを使用します。呼び出し名をビットライズにしているのは、APKのビルドと配布に Bitrise を利用するためです。これについては後ほど解説します。また、 呼び出し名を省略することはできません。 対話モデルの作成 対話モデルの作成は、2018年3月現在でベータ版ですがSkill Builderを使用した方が簡単です。「スキルビルダーを起動する」をクリックすると起動します。 左メニューのIntentsのADDをクリックすることでインテントを追加できます。 Create a new custom intentの入力フォームに「DistributeApk」を入力しCreate Intentをクリックします。 「Sample Utterances」のフォームにサンプル発話を入力します。サンプル発話の節で想定したサンプル発話を入力します。 apk を 配布して apk を 配布 apk を 配って 入力が完了したら「SaveModel」をクリックし対話モデルを保存します。保存が完了したら「Build Model」をクリックし対話モデルをビルドします。 これで対話モデルの作成は完了です。ここまでGUIで対話モデルを作成しましたが、Code Editorを選択するとJSONで表現された対話モデルを確認でき編集も可能です。 設定（AWS Lambdaエンドポイントの指定） サービスエンドポイントのタイプにAWS LambdaのARN（Amazonリソースネーム）を選択し、デフォルトにデプロイ済みのLambda FunctionのARNを指定します。Lambda Functionの実装はまだ行っておらず、ARNはわからないので一旦入力せずに保存しておきます。 Serverlessを利用したAWS Lambdaエンドポイントの開発 AlexaスキルはAlexaサービスのリクエスト先としてエンドポイントを用意する必要があり、AWS Lambdaで実装することが推奨されています。 今回、Lambda functionの実装には言語としてTypeScript、AWSへのデプロイにはServerlessを使用しています。 Serverlessは、サーバーレスアーキテクチャへのデプロイや管理を行うためのツールです。AWS Lambda、Google Cloud Functions、Azure Functions、IBM OpenWhiskといったFaaS（Function as a Service）に対応しています。 serverless.com Serverlessを使用するとLambda functionのデプロイおよび管理を簡単に行えます。 Serverlessのインストール Node.jsのインストールが必要になります。 nvm や nodebrew を使うと簡単です。本記事ではNode.js v8.9.4 を使用しています。 Serverlessは、npmを使用する場合は以下のようにインストールします。 $ npm install -g serverless また、 yarn を使用する場合以下のようになります。 $ yarn global add serverless 本記事で使用するserverlessのバージョンは1.26.1になります。 $ serverless -v 1.26.1 テンプレートから雛形プロジェクト作成 aws-nodejs-typescriptをtemplateに指定してserverless createを実行します。 $ serverless create --template aws-nodejs-typescript Serverless: Generating boilerplate... _______ __ | _ .-----.----.--.--.-----.----| .-----.-----.-----. | |___| -__ | _| | | -__ | _| | -__ |__ -- |__ -- | |____ |_____|__| \___/|_____|__| |__|_____|_____|_____| | | | The Serverless Application Framework | | serverless.com, v1. 26 . 1 ------- ' Serverless: Successfully generated boilerplate for template: "aws-nodejs-typescript" Serverless: NOTE: Please update the "service" property in serverless.yml with your service name 以下のように生成されます。 $ tree . ├── handler.ts ├── package.json ├── serverless.yml ├── tsconfig.json └── webpack.config.js 必要なライブラリの追加 開発に必要なライブラリや型定義の依存を追加します。 $ npm install alexa-sdk @types/alexa-sdk @types/request --save-dev requestモジュール については通常のdependenciesで追加します。型定義のみdevdependenciesとしました。 $ npm install request--save yarnを使用する場合以下の通りです。 $ yarn add alexa-sdk @types/alexa-sdk @types/request --dev $ yarn add request serverless.ymlの更新 serverless.ymlをAlexaサービスからのリクエストを受けられるよう変更します。具体的には events に alexaSkill を指定します。serverlessのドキュメントは こちら です。 これでAlexaサービスからのリクエストを handler.bitriseSkill で受けられるようになりました。 service : name : alexa-bitrise-distribute-apk # Add the serverless-webpack plugin plugins : - serverless-webpack provider : name : aws runtime : nodejs6.10 functions : bitriseSkill : handler : handler.bitriseSkill events : - alexaSkill Alexaに対応したLambda functionの実装方法 Alexaスキルのエンドポイントに対応したLambda functionの書き方はシンプルで、 alexa.registerHandlers によって対話モデルで定義したインテント名に対応した処理を登録し、 alexa.execute() を実行するのみです。 AlexaサービスからDistributeApkインテントが送られてくると、対応するプロパティ DistributeApk が実行されます。 Unhandled 、 LaunchRequest 、 AMAZON.StopIntent はそれぞれ標準で用意されている組み込みインテントに対応しています。 import * as Alexa from 'alexa-sdk' import * as request from 'request' export const bitriseSkill = ( event : Alexa.RequestBody < any > , context : Alexa.Context ) => { const appSlug = process .env.APP_SLUG const apiToken = process .env.API_TOKEN const appId = process .env.APP_ID const alexa = Alexa.handler(event, context) alexa.appId = appId alexa.registerHandlers( { 'Unhandled' : function () { this .emit( ':tell' , 'よく分かりません。' ) } , 'LaunchRequest' : function () { this .emit( ':tell' , 'こんにちは。このスキルはビットライズのビルドをスタートさせエーピーケーを配布します。' ) } , 'AMAZON.StopIntent' : function () { this .emit( ':tell' , 'またご利用ください。' ) } , 'DistributeApk' : function () { // TODO ここにDistributeApkインテントがリクエストされた際の処理を書く } } ) alexa.execute() } DistributeApkインテントがリクエストされた場合に行う処理は、Bitriseの Build Trigger API を使用したビルドのトリガーです。具体的な実装を行う前にBitriseの設定を行いましょう。 Bitriseの設定 Bitrise はモバイルアプリにフォーカスしたCI/CDのPlatform as a Service（PaaS）です。セットアップが非常に簡単で数クリックするだけでAndroidアプリのCI/CD環境を構築することができます。また、Worlflowの概念を取り入れていてビルドステップのカスタマイズも容易です。 今回BitriseをAPKのビルドとDeployGateへのアップロードを行うCIサービスに選んだ理由は以下の3点です。 Androidプロジェクトのセットアップが容易である Build Trigger APIが用意されている Workflowを利用できる 以下のサンプルアプリプロジェクトについてセットアップします。 github.com セットアップ Bitriseにログインし、「Add first app」をクリックします。 セットアップ画面が表示されるので画面の指示に従って設定していきます。「Connect your repository」で接続するリポジトリを選択します。 「Setup repository access」では特に必要がなければ「AUTOMATIC」を選択し、「No, auto-add SSH key」をクリックします。 「VALIDATING REPOSITORY」と表示されるのでしばらく待ちます。Bitriseが対象のリポジトリに含まれるプロジェクトがどのプラットフォームに属するかを判別します。 Validationが完了するとプロジェクトの判別結果に基づいてビルドの設定を自動的に行なってくれます。問題があれば「MANUAL」をクリックし手動で設定できます。 特に問題が無ければ「Confirm」をクリックします。 「Register a Webhook for me!」をクリックするとGitHubやBitbucketからのWebhookを自動的にセットアップし、コードをリポジトリにpushした際、Bitriseが自動的にビルドを開始してくれるようになります。 これでセットアップは完了です。 Workflows BitriseのビルドフローはStepと呼ばれる単一のタスクを実行する部品のコレクションとして表され、 Workflows と呼ばれています。アプリケーションのトップページで「Workflow」タブをクリックすることでWorkflow Editorが起動し、Workflowsを編集可能です。 Workflowsはデフォルトで「primary」と「deploy」が用意されています。新たなWorkflowを作る事も出来ますし、複数のWorkflowを繋げる事も可能です。 DeployGateへのAPKのアップロード DeployGateへのAPKのアップロードは、StepをWorkflowに追加する事で実現します。今回、deploy workflowが実行された場合のみAPKがDeployGateへアップロードされるようにします。「deploy workflow」を選択し、Gradle Runner stepの直後に新たにScript stepを追加します。 DeployGateへのAPKのアップロードはcurlコマンドで実行可能です。詳しくは DeployGate APIリファレンス を参照してください。 以下のコマンドを追加したScript stepで実行するよう設定します。 curl \ -F " token= ${DEPLOY_GATE_API_TOKEN} " \ -F " file=@ ${BITRISE_APK_PATH} " \ -F " message=distribute from alexa " \ https://deploygate.com/api/users/horie1024/apps DEPLOY_GATE_API_TOKEN は環境変数としてBitriseに登録します。Workflow Editorからdeploy workflowでのみ有効な環境変数を登録可能です。 BITRISE_APK_PATH はデフォルトでBitriseが用意する環境変数になります。 最終的なScript stepは以下のようになります。これでdeploy workflowが実行された場合にAPKがDeployGateへアップロードされるようになりました。 AWS LambdaからのBitriseのビルドのトリガー 先程deploy workflowが実行された場合にAPKがDeployGateへアップロードされるようBitriseを設定しました。次にBitriseの Build Trigger API を利用してAWS Lambdaからdeploy workflowを実行します。 Alexaに対応したLambda functionの実装方法 で紹介したコードに処理を追加しましょう。 Build Trigger APIでは、branchやworkflowを指定する事が可能で、deploy workflowでmasterブランチについてビルドし「triggered from alexa」というメッセージをビルドに付加するリクエストBodyは以下のようになります。このリクエストBodyをBuild Trigger APIのエントリーポイントへPOSTリクエストで送信します。 { " hook_info ": { " type ": " bitrise ", " api_token ": " ... " } , " build_params ": { " branch ": " master ", " workflow_id ": " deploy ", " commit_message ": " triggered from alexa " } } requestモジュール を利用したPOSTリクエストは以下のように書く事ができます。コード中のappSlugとapiTokenはAWS Lambdaの環境変数に予め登録しておき実行時に取得します。appSlugおよびapiTokenは、BitriseのアプリケーショントップのCodeタブから確認可能です。 Build Trigger APIへのリクエストが完了後、 this.emit(':tell', '') を使用してユーザーへレスポンスを返します。レスポンスからworkflow idを取得してユーザーへ返すメッセージを動的に変更しています。 request( { method : 'post' , url : `https://www.bitrise.io/app/ ${ appSlug } /build/start.json` , headers : { "Content-Type" : "application/json; charset=utf-8" } , json : true , body : { 'hook_info' : { 'type' : 'bitrise' , 'api_token' : apiToken } , 'build_params' : { 'branch' : 'master' , 'workflow_id' : 'deploy' , 'commit_message' : 'triggered from alexa' } } } , ( error , response , body ) => { let workflowId = body.triggered_workflow this .emit( ':tell' , `ワークフローアイディー ${ workflowId } で、ビットライズでのビルドを開始しました。ビルドが完了後、エーピーケーを配布します。` ) } ) 最終的なコードは以下のようになります。 import * as Alexa from 'alexa-sdk' import * as request from 'request' export const bitriseSkill = ( event : Alexa.RequestBody < any > , context : Alexa.Context ) => { const appSlug = process .env.APP_SLUG const apiToken = process .env.API_TOKEN const appId = process .env.APP_ID const alexa = Alexa.handler(event, context) alexa.appId = appId alexa.registerHandlers( { 'Unhandled' : function () { this .emit( ':tell' , 'よく分かりません。' ) } , 'LaunchRequest' : function () { this .emit( ':tell' , 'こんにちは。このスキルはビットライズのビルドをスタートさせエーピーケーを配布します。' ) } , 'AMAZON.StopIntent' : function () { this .emit( ':tell' , 'またご利用ください。' ) } , 'DistributeApk' : function () { request( { method : 'post' , url : `https://www.bitrise.io/app/ ${ appSlug } /build/start.json` , headers : { "Content-Type" : "application/json; charset=utf-8" } , json : true , body : { 'hook_info' : { 'type' : 'bitrise' , 'api_token' : apiToken } , 'build_params' : { 'branch' : 'master' , 'workflow_id' : 'deploy' , 'commit_message' : 'triggered from alexa' } } } , ( error , response , body ) => { let workflowId = body.triggered_workflow this .emit( ':tell' , `ワークフローアイディー ${ workflowId } で、ビットライズでのビルドを開始しました。ビルドが完了後、エーピーケーを配布します。` ) } ) } } ) alexa.execute() } サンプルコードはこちらです。 github.com AWS Lambdaへのデプロイ IAMの作成 Serverlessが使用するIAMを作成します。Serverlessの AWS - Credentials を参考に作成しましょう。 AWSにログイン後サービスからIAMを選択しユーザーメニューから「ユーザーを追加」をクリックしてください。または こちら をクリックするとユーザーを追加画面が表示されます。 ユーザ名に「serverless-admin」アクセスの種類は「プログラムによるアクセス」にチェックを付けます。 次のステップでは、アクセス権限を設定を設定します。「既存のポリシーを直接アタッチ」からAdministratorAccessにチェックを付けます。 最後に選択内容を確認し「ユーザーの作成」をクリックします。ユーザーの追加が成功すると「アクセスキーID」と「シークレットアクセスキー」が表示されるのでこちらをメモしておきます。 アクセス情報の取扱いには十分注意してください 。 認証情報の登録 作成後 serverless config でAWSの認証情報を登録します。 $ serverless config credentials --provider aws --key YOUR_KEY --secret YOUR_SECRET デプロイ 登録が完了後、 serverless deploy を実行するとTypeScriptのコンパイルからAWS Lambdaへのデプロイまで自動的に行われます。 $ serverless deploy Serverless: Bundling with Webpack... ts-loader: Using typescript@ 2 . 7 . 2 and tsconfig.json Time: 3875ms Asset Size Chunks Chunk Names handler.js 4 . 46 MB 0 [ emitted ] [ big ] handler handler.js.map 5 . 99 MB 0 [ emitted ] handler [ 30 ] ./node_modules/alexa-sdk/lib/utils/textUtils.js 1 . 48 kB { 0 } [ built ] [ 82 ] ./node_modules/extend/index.js 2 . 27 kB { 0 } [ built ] [ 144 ] ./node_modules/request/lib/cookies.js 974 bytes { 0 } [ built ] [ 182 ] ./handler.ts 1 . 96 kB { 0 } [ built ] [ 183 ] ./node_modules/alexa-sdk/index.js 1 . 62 kB { 0 } [ built ] [ 184 ] ./node_modules/alexa-sdk/lib/alexa.js 8 . 83 kB { 0 } [ built ] [ 807 ] ./node_modules/alexa-sdk/lib/templateBuilders/bodyTemplate1Builder.js 923 bytes { 0 } [ built ] [ 808 ] ./node_modules/alexa-sdk/lib/templateBuilders/bodyTemplate2Builder.js 1 . 16 kB { 0 } [ built ] [ 809 ] ./node_modules/alexa-sdk/lib/templateBuilders/bodyTemplate3Builder.js 1 . 16 kB { 0 } [ built ] [ 810 ] ./node_modules/alexa-sdk/lib/templateBuilders/bodyTemplate6Builder.js 1 . 16 kB { 0 } [ built ] [ 817 ] ./node_modules/alexa-sdk/lib/services/directiveService.js 2 . 27 kB { 0 } [ built ] [ 818 ] ./node_modules/alexa-sdk/lib/directives/voicePlayerSpeakDirective.js 604 bytes { 0 } [ built ] [ 819 ] ./node_modules/alexa-sdk/lib/utils/imageUtils.js 3 . 33 kB { 0 } [ built ] [ 820 ] ./node_modules/request/index.js 3 . 97 kB { 0 } [ built ] [ 825 ] ./node_modules/request/request.js 44 . 7 kB { 0 } [ built ] + 920 hidden modules Serverless: Packaging service... Serverless: Uploading CloudFormation file to S3... Serverless: Uploading artifacts... Serverless: Validating template... Serverless: Updating Stack... Serverless: Checking Stack update progress... ......... Serverless: Stack update finished... Service Information service: alexa-bitrise-distribute-apk stage: dev region: us-east-1 stack: alexa-bitrise-distribute-apk-dev api keys: None endpoints: None functions: bitriseSkill: alexa-bitrise-distribute-apk-dev-bitriseSkill Serverless: Removing old service versions... AWSコンソールを開きサービスからLambdaを選択すると「alexa-bitrise-distribute-apk-dev-bitriseSkill」という関数が作成されています。関数名をクリックし関数の詳細画面に遷移後 ARN を確認してください。 Alexaスキルメニューの設定でARNを入力し保存しましょう。 シミュレータでのテスト スキルのテストは、Alexaスキルメニューの「テスト」から簡単に行うことができます。2018年3月現在でベータ版ですが、実際に発話して動作を確認できるためテストシミュレータを使用することをオススメします。 「テストシミュレータに進む」をクリックする事でテストシミュレータに切り替える事が可能です。 また、「このスキルをテストするには対話モデルのタブを完成させてください。」を有効に切り替えてください。 Alexa Simulatorタブの入力フォーム横マイクアイコンをクリックしホールドしている間、テストシミュレータは音声入力を受け付けます。シミュレータでテストする場合最初に「Alexa」と話しかける必要はありません。 実機でのテスト Amazon echoなどのAlexa対応デバイス実機でスキルを動かすには、スキルのベータテストを開始する必要があります。 ベータテストを開始するには、「スキル」「対話モデル」「テスト」「公開情報」「プライバシーコンプライアンス」の全ての項目が完了している必要があります。 ここまでで未入力な項目は「公開情報」「プライバシーコンプライアンス」の2項目のはずなので完了させましょう。 公開情報の入力 公開情報の入力を完了するためには全ての項目を埋める必要があります。スキルのアイコン画像2種類（108×108、512×512）を登録する必要があるので用意してください。 今回はスキルを公開しないので仮で入力してしまって問題ありません。公開する場合全ての情報を入力後に審査を受ける必要があります。 以下のように設定しました。 項目 値 カテゴリー Productivity サブカテゴリー Organizers & Assistants テストの手順 test 国と地域 Japan スキルの簡単な説明 AlexaにAPKの配布を依頼します。 スキルの詳細な説明 Alexaに「ビットライズでAPKを配布して」と話しかけることでAPKをDeployGate経由で配布します。 サンプルフレーズ ビットライズでAPKを配布して キーワード 未入力 プライバシーコンプライアンスの入力 プライバシーコンプライアンスは以下のように設定しました。 項目 値 このスキルを使って何かを購入をしたり、実際にお金を支払うことができますか？ いいえ このスキルはユーザーの個人情報を収集しますか？ いいえ このスキルは13歳未満の子供をターゲットにしていますか？ いいえ 輸出コンプライアンス チェック このスキルは広告を含みますか？ いいえ テスターへの追加とベータテストの開始 入力が完了し「申請する」ボタンを押せるようになりますが押さず、Skills Beta Testingの「☆ スキルのベータテスト」をクリックします。 次に、Amazon echoのセットアップに利用したメールアドレスをテスターに追加し「テストの開始」をクリックします。 これでベータテストが開始され、テスターに追加したメールアドレスに招待メールが送信されます。 JP customersのリンクをクリックしてください 。 https://alexa.amazon.co.jp/spa/index.html#skills/your-skills に遷移しますのでログイン後、表示されるダイアログで「スキルテスト」をクリックしてください。 そして「有効にする」をクリックする事でAmazon echo実機でスキルをテストすることができます。 まとめ Alexa対応デバイスに話しかける事でAPKを配布することができました。実際に実機で試してみると声だけで配布を実行できるのが新鮮でとても楽しかったですし、思っていた以上に便利です。今後Slack botで行っていた作業をAlexaスキルで実装してみるなどして、日々の業務効率の改善に生かせるか実験してみようと思います。 最後に VASILYでは、Androidエンジニアを募集しています。少しでも興味がある方のご応募をお待ちしています。

こんにちは。フロントエンドエンジニアの茨木（ @niba1122 ）です。 弊社のAndroidアプリ開発ではMVVMアーキテクチャを用いています。日々肥大化・複雑化していくViewModelが保守性や品質を担保する上で課題になっていましたが、Fluxアーキテクチャの導入により改善することができました。 本記事では、実際どのようにFluxアーキテクチャを導入したのかを、設計やコード例を交えながらご紹介します。 今までのMVP・MVVMの限界 アプリ開発ではMVP・MVVMといったアーキテクチャがよく用いられます。弊社のAndroidアプリ開発でもMVVMを用いています。これらのアーキテクチャはビューとドメインロジックを分割するのに役立っています。しかし、昨今のUIには多くのイベントや状態があり、更にそこにAPIリクエストなどの非同期処理が絡んできます。これらが関わるプレゼンテーション層のロジックをドメイン層に持ち込むことは難しく、結果的にPresenterやViewModelが肥大化・複雑化しがちです。弊社でも複雑な画面でよくViewModelが肥大化・複雑化し、実装・メンテナンス上の課題になっていました。それらを解決するための手法として、アプリ開発でも徐々に普及しつつあるFluxに着目しました。 Fluxについて ここで、一旦Fluxについておさらいしておきましょう。FluxはFacebookが提唱する、イベントや状態を扱うアーキテクチャです。次の図に示すように、Fluxではデータフローを単一方向に扱います。 出典： https://github.com/facebook/flux FluxではイベントやAPIリクエストの完了後、それを直接ビューで購読することなくDispatcherにActionオブジェクトで通知します。StoreはDispatcherを購読し、Actionオブジェクトに応じてState（状態）を更新します。ViewはStoreのStateをウォッチして、変更があった場合に自身を更新します。このようなデータフローにすることで、APIリクエストやリクエスト完了後の状態更新を切り分けることが出来ます。それにより、コードの見通しが良くなるだけでなくテストの書きやすさも向上します。 Fluxを導入してみる 基本設計 特定の画面の状態やイベントをFluxで管理したいので、FluxをMVVMのViewModelに適用します。AndroidにはメジャーなFluxのライブラリがないので、抽象クラスを自作することにしました。Fluxの実装例はReduxやVuexなどいくつかあります。しかし、これらのインタフェースは弊社で積極的に使っているRxJava2との相性があまり良くないです。そのため、抽象クラスのインタフェースも独自で設計しました。次の図は、Flux導入後のアプリのアーキテクチャです。 図中のStoreの範囲がFluxに相当します。Fluxの各構成要素は他のライブラリを参考に定義しています。構成要素の定義は各ライブラリのドキュメントで示されていますが、抽象的なものが多いです。そこで、本記事における構成要素の定義を明確にしておきます。 Store Fluxの構成要素を保持し、依存関係の解決やActionの伝達を行います。 Event ボタンのクリックやタイマーなどのイベントに直接対応します。実体は後述するActionCreatorのメソッドです。 ActionCreator イベントに応じてAPIリクエストなどの処理を実行します。非同期処理は全てここで行います。状態更新が必要なタイミングでActionのインスタンスを通知します。 Action Actionはイベントの発生やAPIのリクエスト開始/完了/失敗といった状態変更の基点を表し、payloadと呼ばれるデータを併せ持ちます。APIリクエスト成功のActionの場合、payloadとしてレスポンスの値を渡したりします。 Reducer&State Stateはビューの表示や更新に必要な状態変数で、Reducerのメンバーとして定義します。ReducerはActionを受け取り、それに応じてStateを更新します。単一方向のデータフローを守るため、Stateは外部からはimmutableにします。また、Stateには動的に取得するトークンなど、表示に使わない状態変数も含まれます。その為、ReducerはFluxの外に公開しません。更に、ReducerはActionのみに基づいてStateを更新するため、クラス外部へのアクセスも行いません。 Getter&View Property View Propertyはビューの状態に直接対応する要素で、View PropertyはGetterのメンバーとして定義します。GetterはReducerのメンバーであるStateを購読し、View Propertyにマッピングして通知します。Stateと同様に外部からはimmutableにします。Getterはビューに通知する必要があるので、Fluxの外部に公開します。 抽象クラス 前述の設計に従って実装を行うための抽象クラスを定義しました。抽象クラスではActionCreator、Reducer、Getterクラスに依存関係を注入します。StateやViewPropertyの通知に関しては敢えて抽象化していません。実装者が柔軟にRxJava2のストリームを定義できるようにしています。StateやViewPropertyのimmutable性は、Subjectをクラス外に公開しない、Observableをvalで公開するというコーディング規約で担保しています。 package com.example.niba1122.flux.util.flux import io.reactivex.Observable import io.reactivex.disposables.CompositeDisposable import io.reactivex.subjects.PublishSubject abstract class Store<AT, out AC, R, out G> where AC : DisposableMapper, R : DisposableMapper, G : DisposableMapper { private val dispatcher: PublishSubject<AT> = PublishSubject.create() private val reducer: R by lazy { createReducer(dispatcher.observeOn(Schedulers.computation())) } val actionCreator: AC by lazy { createActionCreator({ dispatcher.onNext(it) }, reducer) } val getter: G by lazy { createGetter(reducer) } protected abstract fun createActionCreator(dispatch: (AT) -> Unit , reducer: R): AC protected abstract fun createReducer(action: Observable<AT>): R protected abstract fun createGetter(reducer: R): G fun clearDisposables() { actionCreator.disposables.clear() reducer.disposables.clear() getter.disposables.clear() } } open class DisposableMapper { val disposables = CompositeDisposable() } Storeを実装する場合は上の抽象クラスを継承した具象クラスを定義します。この際に、ActionCreator、Reducer、Getterを生成するメソッドの定義を抽象クラスから要求されます。各構成要素でRepositoryなどを用いる場合は、具象クラスのコンストラクタからインスタンスを与えます。 ユーティリティ RxJava2は高い表現力を持っていますが、より開発しやすくするために幾つかクラスを定義して使っています。 Variable BehaviorSubjectに似たようなものです。 .value で値の取得だけでなく通知も可能な点が異なります。値を購読する場合には .observable で取得したObservableを使います。更に、immutableなインタフェースを持っているので、クラス外部へimmutableに公開することができます。 import io.reactivex.Observable import io.reactivex.subjects.BehaviorSubject interface ImmutableVariable<T> { val value: T val observable: Observable<T> } class Variable<T>(initialValue: T) : ImmutableVariable<T> { private val subject = BehaviorSubject.createDefault(initialValue) override var value: T get () = subject.value set (value) { subject.toSerialized().onNext(value) } override val observable: Observable<T> get () = subject.distinctUntilChanged() } NullableVariable 先程のVariableはRxJava2がnullを許容しないためにnullの値を扱うことが出来ません。 そこで、SwiftやRustのOptional型のように値をラップすることでnullも扱えるようにしたのがNullableVariableです。 import io.reactivex.Observable import io.reactivex.subjects.BehaviorSubject interface ImmutableNullableVariable<T> { val value: T? val observable: Observable<Wrapper<T>> } @Suppress ( "unused" ) sealed class Wrapper<T> { class Some<T>( val value: T) : Wrapper<T>() class None<T> : Wrapper<T>() fun unwrap(): T? = when ( this ) { is Some -> this .value is None -> null } } class NullableVariable<T>(initialValue: T?) : ImmutableNullableVariable<T> { private val subject = BehaviorSubject.createDefault<Wrapper<T>>( if (initialValue != null ) { Wrapper.Some(initialValue) } else { Wrapper.None() }) override var value: T? get () = subject.value.let { when (it) { is Wrapper.Some -> it.value is Wrapper.None -> null } } set (value) { if (value != null ) { subject.toSerialized().onNext(Wrapper.Some(value)) } else { subject.toSerialized().onNext(Wrapper.None()) } } override val observable: Observable<Wrapper<T>> get () = subject.toSerialized().distinctUntilChanged() } 実装例 ここまでで説明してきたFluxの実装例として、スクロールによりページングする一覧画面の例をご紹介します。 サンプルコードは GitHub にもアップロードしてあります。 ViewModel 先に述べたようにViewModelではEventをstoreに通知し、View Propertyを受け取ります。ListViewModelでは、ビューの初期化とスクロール完了のEventをStoreに通知しています。そして、View PropertyとしてRecyclerViewのアイテム、初期ローディング、エラー時のスナックバーに関する値を受け取ります。弊社で最近開発しているサービスに合わせ、RxBindingやDataBindingを使用せずにLiveDataをObserveしてViewを更新しています。 import android.arch.lifecycle.MutableLiveData import android.arch.lifecycle.ViewModel import io.reactivex.android.schedulers.AndroidSchedulers import io.reactivex.disposables.CompositeDisposable class ListViewModel(repository: Repository) : ViewModel() { private val disposables: CompositeDisposable = CompositeDisposable() private val store = ListStore(repository) val listItems: MutableLiveData<List<ListItemType>> = MutableLiveData() val isShownPageLoading: MutableLiveData< Boolean > = MutableLiveData() init { store.getter.listItems .observeOn(AndroidSchedulers.mainThread()) .subscribe({ listItems.value = it }, {}).let { disposables.add(it) } store.getter.isShownPageLoading.observable .observeOn(AndroidSchedulers.mainThread()) .subscribe({ isShownPageLoading.value = it }, {}).let { disposables.add(it) } store.getter.errorSnackbar .observeOn(AndroidSchedulers.mainThread()) .subscribe({ errorSnackbar.value = it }, {}).let { disposables.add(it) } } override fun onCleared() { disposables.clear() store.clearDisposables() } fun onInitialize() { store.actionCreator.onInitialize() } fun onScrollToLast() { store.actionCreator.onScrollToLast() } } Store Storeでは画面で用いるActionCreator、Reducer、Getterの注入を行います。Repositoryの注入も併せてここで行います。 import io.reactivex.Observable import io.reactivex.Single class ListStore( private val repository: Repository) : Store<ListActionType, ListActionCreator, ListReducer, ListGetter>() { override fun createActionCreator(dispatch: (ListActionType) -> Unit , reducer: ListReducer): ListActionCreator = ListActionCreator(dispatch, reducer, repository) override fun createReducer(action: Observable<ListActionType>): ListReducer = ListReducer(action) override fun createGetter(reducer: ListReducer): ListGetter = ListGetter(reducer) } Action 状態更新の基点になるActionを定義しています。Action毎に付随するデータが異なるので、enumではなくsealed classを用いています。 sealed class ListActionType { class StartInitialLoad : ListActionType() class SuccessInitialLoad( val elements: List<Element>) : ListActionType() class StartNextLoad : ListActionType() class SuccessNextLoad( val elements: List<Element>) : ListActionType() class Error( val error: Throwable) : ListActionType() } ActionCreator Eventに応じてAPIリクエストなどの処理を行い、状態更新の基点でActionを通知します。 class ListActionCreator( private val dispatch: (ListActionType) -> Unit , private val reducer: ListReducer, private val repository: Repository) : DisposableMapper() { fun onInitialize() { dispatch(ListActionType.StartInitialLoad()) repository.list( 1 ) .subscribe({ dispatch(ListActionType.SuccessInitialLoad(it)) }, { dispatch(ListActionType.Error(it)) }).let { disposables.add(it) } } fun onScrollToLast() { if (reducer.isNextLoading.value) return dispatch(ListActionType.StartNextLoad()) repository.list(reducer.page + 1 ) .subscribe({ dispatch(ListActionType.SuccessNextLoad(it)) }, { dispatch(ListActionType.Error(it)) }).let { disposables.add(it) } } } Reducer Actionを購読し、Actionの種類に応じてStateを更新しています。ここではStateの型を、値の保持や通知が必要かどうかに応じて使い分けています。また、値を実際に保持・通知する変数と外部に公開する変数を分けることで、外部からのimmutable性を実現しています。 import io.reactivex.Observable import io.reactivex.subjects.PublishSubject class ListReducer(action: Observable<ListActionType>) : DisposableMapper() { init { action.ofType(ListActionType.StartInitialLoad:: class .java) .subscribe { mIsInitialLoading.value = true }.let { disposables.add(it) } action.ofType(ListActionType.SuccessInitialLoad:: class .java) .subscribe { mIsInitialLoading.value = false mElements.value = it.elements }.let { disposables.add(it) } action.ofType(ListActionType.StartNextLoad:: class .java) .subscribe { mIsNextLoading.value = true }.let { disposables.add(it) } action.ofType(ListActionType.SuccessNextLoad:: class .java) .subscribe { mIsNextLoading.value = false mElements.value += it.elements page++ }.let { disposables.add(it) } action.ofType(ListActionType.Error:: class .java) .subscribe { mError.onNext(it.error) }.let { disposables.add(it) } } var page: Int = 1 private set private val mElements: Variable<List<Element>> = Variable(listOf()) val elements: ImmutableVariable<List<Element>> get () = mElements private val mIsInitialLoading: Variable< Boolean > = Variable( false ) val isInitialLoading: ImmutableVariable< Boolean > get () = mIsInitialLoading private val mIsNextLoading: Variable< Boolean > = Variable( false ) val isNextLoading: ImmutableVariable< Boolean > get () = mIsNextLoading private val mError: PublishSubject<Throwable> = PublishSubject.create() val error: Observable<Throwable> get () = mError } Getter Reducerから受け取ったStateをView Propertyにマッピングしています。ここでのlistItemsはこのままRecyclerViewに渡され、DiffUtilにより更新される想定です。 import io.reactivex.Observable import io.reactivex.functions.BiFunction class ListGetter(reducer: ListReducer) : DisposableMapper() { val listItems: Observable<List<ListItemType>> = Observable.combineLatest( reducer.elements.observable, reducer.isNextLoading.observable, BiFunction { elements, isNextLoading -> var listItems: List<ListItemType> = elements.map { ListItemType.Data(it) } if (isNextLoading) { listItems += ListItemType.Loading() } listItems }) val isShownPageLoading = reducer.isInitialLoading val errorSnackbar = reducer.error } まとめ Fluxを導入してViewModelの処理を分割したメリットは想像以上でした。どこにどのような処理が書かれているかを把握しやすくなったので、コードの保守性がかなり向上しました。更に、複雑化したViewModelでは難しかったUI改善がFlux導入で可能になり、ユーザー体験も向上させることができました。 最後に VASILYではこだわりをもってプロダクトを開発したいエンジニアを募集しています！ 興味のある方は次のリンクよりお申し込み下さい。

インフラエンジニアの光野（@kotatsu360）です。 今週のテックブログは豪華二本立てでお送りいたします。 一本目はバックエンドエンジニアの木曽による「 福利厚生を使ってAWSソリューションアーキテクト アソシエイトを取得しました 」でした。 二本目は UserData、OpsWorks、Lambdaを組み合わせ、常に新鮮なSpotFleetインスタンスでサービスを運用する という取り組みについて紹介させていただきます。 なお、本記事は先日開催された X-Tech JAWS 【第2回】~9割のX-Techと1割の優しさで切り拓く未来~ での登壇資料を補足するものです。適宜スライドを取り上げて説明をいたします。 キーワード：EC2 SpotFleet、AWS Lambda、UserData、Apache Mesos ネットワーク概要 弊社が運営する IQON は、 独自のクローラー を用いて契約済みECサイトから情報を収集、整理、掲載しています。 そのためIQONにおいてクローラーは非常に重要な存在です。 このクローラー、何度かの刷新を経て現在は次の構成を取っています。 アプリケーションはコンテナ化 計算資源は、Amazon EC2 SpotFleetによるクラスタをApache Mesosで抽象化 クロール状況に応じてコンテナ数が増減 全体図は以下のとおりです 1 。 これらは、大きく3つのフェーズで構築されました。 本記事で触れる範囲は Phase.3 です 2 。 Phase.3以前の悩み SpotFleetによる柔軟な構成を取ることでインスタンスを立てる手間は無くなりました。 しかし、1つだけ手元に残った作業があります。 custom AMIの更新作業 です。 Packer by Hashicorp でAMIの作成自体は自動化していましたが、AMI作成用のクレデンシャルや実行方法は属人化しています。これを解決することを目的としたのがPhase.3です。 UserDataとOpsWorksとLambda 2017年の中頃、構成管理にOpsWorksを導入していたということもあり 3 、SpotFleetインスタンスたちも同様に管理することにしました。 順を追って説明します。 1. インスタンスの起動とUserDataによるOpsWorksの呼び出し まず、SpotFleetインスタンスが起動します。SpotFleetの起動設定として次のUserDataが登録されています。 # SpotFleet インスタンスについての記述 # 記述... UserData : Fn::Base64 : !Sub - | #cloud-config repo_update : true repo_upgrade : security # RedHat系ならこっち apt_upgrade : true # Debian系ならこっち packages : - python-pip runcmd : - LC_ALL=C sudo pip install awscli - /usr/local/bin/aws opsworks --region us-east-1 register --infrastructure-class ec2 --stack-id ${OpsWorksStackId} --local --use-instance-profile 2>&1 | tee /tmp/register.log - export INSTANCE_ID=$(grep 'Instance ID' /tmp/register.log | grep -oE '[a-z0-9\-]+$' ) - while ! /usr/local/bin/aws opsworks --region us-east-1 assign-instance --instance-id $INSTANCE_ID --layer-ids ${OpsWorksLayerId1} ${OpsWorksLayerId2} ${OpsWorksLayerId3}; do echo 'wait...' ; sleep 20; done - OpsWorksStackId : !Ref OpsWorksStack OpsWorksLayerId1 : !Ref OpsWorksLayerCommon OpsWorksLayerId2 : !Ref OpsWorksLayerMesosBase OpsWorksLayerId3 : !Ref OpsWorksLayerMesosSlave # SpotFleet インスタンスについての記述 # 記述... これはCloudFormationテンプレートによるUserDataの設定です。依存するOpsWorksのID類が解決され、最終的にはBase64エンコードされた文字列が登録されます。 runcmd では、3つのタスクを行っています。 awscliのインストール OpsWorksへの登録（register） OpsWorksレイヤへの追加（assign） whileループはregisterの終了を待ってassignするための処理です 4 。 OpsWorksの呼び出しがUserDataの役割 で、これ以降は全てOpsWorks側で行います。 2. OpsWorksによる構成管理とMesosクラスタへの参加 OpsWorks側には Setup と Deploy の2つのタイミングでレシピが実行 されるように設定されています。 OpsWorksLayerMesosSlave : # レイヤについての記述 # 記述... CustomRecipes : Setup : - 'mesos::slave' Deploy : - 'mesos::attach' # レイヤについての記述 # 記述... mesos::slave はMesosエージェントのインストールなどの前準備、 mesos::attach がエージェントの再起動や最終的な設定変更を担当しています。 最終的な設定変更が終了するとMesosクラスタの一員として新しいタスクを処理できるようになります。 Chefはレシピの実行順を制御することができません 5 。その為、OpsWorksのライフサイクルを利用してSetup完了後（=環境構築後）のDeployイベントに最終的な設定を任せることにしています 6 。 余談ですが、昔、手でcustom AMIを作成していた時代には、 mesos::attach 相当の内容がUserDataとして書かれていました。UserDataからOpsWorksを呼び出すなら一緒にChefのレシピにした方が楽だという事でお引っ越しです。 閑話休題。 3. Lambdaによる状態監視とリトライ 2. OpsWorksによる構成管理とMesosクラスタへの参加 までが終わると、新しいSpotFleetインスタンスはMesosクラスタの一員としてタスクを処理します。 ここからは運用面のフォローについて補足します。 OpsWorksで構築を行っていると、時たまネットワーク的な不調で構成管理に失敗することがあります。リトライすると直ります。一時は手でフォローしていたのですが辛くなったので今は Lambdaに状態監視とリトライ を任せています。 CloudWatch Eventsで定期的にLambdaを発火、LambdaはOpsWorksに登録されているインスタンスを監視し、必要に応じて再setupのリクエストを投げます。 4. OpsWorksから削除 最後はOpsWorksからインスタンスを削除する部分です。OpsWorksは明示的にderegisterのリクエストを打たない限り、インスタンスを管理し続けようとします。 その為、SpotFleetインスタンスを落とす際には インスタンス自身がderegisterをリクエストする ようcronスクリプトで準備しています。 #!/bin/bash # terminate notificationを受け取ったときのスクリプト RES = $( curl -w ' %{http_code} ' -o /dev/null -s -- ' http://169.254.169.254/latest/meta-data/spot/termination-time ' ) if [ " ${RES} " = "404" ] ; then : else # SpotFleetインスタンスなので再起動することが無い。困ったら破棄。tmp以下のファイルで連携しても大して問題にならない export INSTANCE_ID= $( grep ' Instance ID ' /tmp/register.log | grep -oE ' [a-z0-9\-]+$ ' ) /usr/ local /bin/aws opsworks --region us-east -1 deregister-instance --instance-id $INSTANCE_ID 2 > & 1 | tee -a /tmp/register.log # mesosのエージェントを止めたり、監視とめたり、Dockerコンテナ止めたり、、、 # 後始末 fi 毎分メタデータから終了予告の有無をチェックし、必要であればderegisterします 7 。 1点注意があります。ユーザ操作でSpotFleetクラスタのサイズを変える場合は termination-time が設定されません。何らか手動で操作する場合は、このスクリプト相当の作業を手で行う必要があります。 日常的なSpotFleetクラスタのサイズ変更は、これまた別のLambdaがコントロールしています。そちらはLambda（lambda.amazonaws.com）による実行となるためか termination-time が設定されます。特に手を出すことはありません。 メリット・デメリット custom AMIを作成して利用するというやり方から、OpsWorksを利用するやり方への変遷についてご紹介しました。 改めてメリット・デメリットを整理します。 メリットは次の3つです。 事前にcustom AMIを作成する準備が不要 クレデンシャルや手順書を用意する必要がない 常にパッケージ類が最新 固定したいものがあれば、それもできる 同じ枠組みでサービスの全インスタンスが管理される EC2インスタンスとSpotFleetインスタンスを共通のレシピから構築 一方、毎回OpsWorksで管理させることのデメリットです。 Mesosクラスタに参加するまでのリードタイムが長い 10〜15分、custom AMI時代は3〜5分 たまに構築が失敗する Lambdaでフォロー インターネットに優しくない 毎回パッケージ類を取得するため 新鮮さと速度のトレードオフ 。 custom AMI作成の自動化を検討したこともありますが、作成自動化+SpotFleetクラスタの更新まで考えると最終的に今の形に落ち着きました。 まとめ 本記事では、UserDataとOpsWorks、Lambdaを使ったSpotFleetインスタンスの構成管理についてご紹介しました。新鮮なインスタンスが使えること、custom AMIの更新がなくなったこと、より健全な運用体制ができたと感じています。 さて、弊社のMesosクラスタに関して、これまでの取り組みを以てネットワーク構成面での不満は概ね解消されました。そのため次はMesos自体も含めた各種ソフトウェアのバージョンアップに取り組む予定です。いずれまたご紹介できればと考えています。 VASILYでは現状に満足せず、より健全な姿を目指して挑戦できる、挑戦が好きなエンジニアを募集しています。興味がある方は以下のリンクからお申し込み下さい。 この構成は、2018年3月で本番投入からちょうど1年になりました🎉 ↩ Phase.2については Docker / Apache Mesos / Marathon による3倍速いIQONクローラーの構築 にて紹介しています ↩ CloudFormationとOpsWorksでインフラを育てる ↩ なお、OpsWorksはwaitのAPIがあるため、 /usr/local/bin/aws opsworks --region us-east-1 wait instance-registered --instance-ids $INSTANCE_ID と書けば、whileで待つ必要はありません。最近、知りました。。 ↩ 大抵は書いた順ですが、include_resipeやnotifiesによる呼び出しを全て把握して書くのは煩雑です ↩ AWS OpsWorks Stacks のライフサイクルイベント ↩ temination-timeはdeprecatedらしく、instance-actionを使うように勧められています。 ↩

つい最近、中途入社しましたバックエンドチームの id:takanamito です。 今回は入社してすぐに会社の福利厚生をつかってAWSソリューションアーキテクト アソシエイトレベルを取得した話をご紹介します。 Amazon - Badge Verification - CertMetrics きっかけ 作戦 後に引けない状況をつくる どんな試験なのか知る どう勉強するかを考える 模試を受ける 試験当日 福利厚生 まとめ きっかけ 転職に伴いまとまった時間が確保できたことや、前職の同僚が同資格のプロフェッショナルを持っていて仕事でけっこう役立ってそうな感じでうらやましかったので取ろうと思いました。 過去に何度か時間ができたタイミングで趣味webサービスを作っていたんですが、途中で飽きたり運営がうまくいかなかったりといい結果が出ていませんでした。 そこで今回は路線変更して、資格という成果がわかりやすいものに挑戦してみることにしました。 作戦 せっかくなので、実際に資格を取るにあたってどのような方針で進めていったかを残します。 後に引けない状況をつくる まず試験に申し込むことにしました（16,200円） この時点で試験日が決まり、クレカ決済が発生します。 締め切りとお金の負担を発生させることで自分を追い込みます。 どんな試験なのか知る 次にどんな試験なのかを調べました。サンプル問題があるので見てみることに。 AWS 認定ソリューションアーキテクト – アソシエイト 選択問題で正しいものを選ばせる形式の問題ということがわかりました。 また詳細な試験要項を読むと出題分野と傾向を把握することもできます。 http://media.amazonwebservices.com/jp/certification/AWS_certified_SolutionArchitect_associate_blueprint_JP.pdf 高可用性、コスト効率、対障害性、スケーラブルなシステムの設計: 60% 実装/デプロイ: 10% データセキュリティ: 20% トラブルシューティング: 10% これらを調べた時点で、試験で問われる知識は クラウドデザインパターン(CDP)に出てきそうな構成 各種サービスの用途や仕組み 高可用性の実現 低コスト化 スケーラビリティ 各種サービスの細かな仕様 であることがわかりました。 どう勉強するかを考える どんな試験で何を問われるかだいたいわかったので、次はどう勉強していくかを考えます。 AWSが公式に紹介しているおすすめフローは以下 AWS 認定 – 認定の準備 トレーニングクラスの受講 試験学習ガイドを読む ホワイトペーパーを読む 試験準備ワークショップの受講 模試を受ける また過去の多くの受験者がブログなどで紹介していたのは以下の3つ 合格対策 AWS認定ソリューションアーキテクト - アソシエイト を読む WEB問題集 に課金 Black Beltの資料を読む AWS公式ドキュメントを読む これらの勉強法から自分にあったやり方や教材を選んでいくことに。 サンプル問題や出題傾向から以下の様なことを感じていました。 使ったことのないサービスについて問われるとキツイ 細かい知識について問われると覚えてない 逆にCDPで紹介されているような高可用性/スケーラビリティを実現する構成は知ってることが多かった 基本的には知識を貯め込んでいく勉強になるのですが、片っ端からドキュメントや資料を読んでいくには量が多く勉強自体を退屈に感じそうな予感がしました。 そこで公式資料をそのまま読み進めるのは避けて、問題を解きつつ 間違えたところについて公式ドキュメントやblack beltの資料を読んで知識を埋めていく やり方を採用し、以下の4つに教材を絞り込みました。 Web問題集に課金 Black Beltの資料を読む AWS公式ドキュメントを読む 模試を受ける ワークショップは、たまたま寒くてあまり出かけたくない日が続いてたのでやめました。 模試を受ける 1日1時間ほどの時間を取りながら2週間ほど問題集を解きました。 700問程度ある問題のうち2〜300問くらい解いたと思います。 知らなかった知識については、個人用の Kibela のブログに問題とその解説をしているドキュメントや資料のURLをセットでメモしました。 試験前に確認する自分専用の参考書にする狙いです。 また、このタイミングでどの程度学習が進んでいるかの確認も兼ねて模試を受けることにしました。 無事に75％の正答率で合格判定が出ました。 総合評点： 75% トピックレベルスコアリング： 1.0  Designing highly available, cost-efficient, fault-tolerant, scalable systems: 66% 2.0  Implementation/Deployment: 100% 3.0  Data Security: 75% 4.0  Troubleshooting: 100% しっかり勉強が成果に結びついていることを確認できたのでうれしかったのと、家にいながらブラウザで実際の試験と同じ形式の画面で問題を解くので本番当日に「どのような画面が出てくるのか」を知れたのが大きかったです。 この模試は問題をスクショで保存しておけるので、後日ゆっくり解き直すことができます。 試験当日 模試の翌週に本試験を受ける日程だったので、残った日は引き続き問題集を解いて知識の穴埋めを進め、使ったことのないサービスについてBlack Beltの資料を読む作業をしていました。 この辺の内容も全てKibelaにメモしています。 試験当日は出発前にKibelaのメモを確認してから出発しました。 試験結果は以下のとおりです。 総合評点： 85% トピックレベルスコアリング： 1.0  Designing highly available, cost-efficient, fault-tolerant, scalable systems: 84% 2.0  Implementation/Deployment: 66% 3.0  Data Security: 90% 4.0  Troubleshooting: 100% 模試のときより正答率を10％上げて合格することができました🎉 うれしい。 福利厚生 VASILYには福利厚生で資格試験の補助制度があり、今回の受験料も会社から全額補助を受けることができました💪 これがなければモンハンワールドを買うための家庭内稟議が通らない可能性もあったので激アツ補助でした。 ソリューションアーキテクトのプロフェッショナルは受験料が32,400円とアソシエイトに比べて高額なので、プロフェッショナル受験も目指す私としては非常にありがたい制度です。 まとめ 実際に稼働していた期間は2〜3週間ほどなんですが、まず最初に申し込んでしまい自分を追い込んでから勉強にとりかかるやり方は、怠惰な自分にとっては非常によい方法でした。 また会社の補助があることで、資格取得のハードルが下がり勉強に取り組みやすかったです。 今後はプロフェッショナルレベルの取得に向けて勉強していきますが、次回もこの制度を利用して合格を目指そうと思います。 VASILYではソリューションアーキテクトを募集しています。 興味がある方は以下のリンクからお申し込みください。

こんにちは、フロントエンドエンジニアの権守です。 プログラミングをしていると頭を悩まされるものの1つにエラーハンドリングがあると思います。シンプルにできた実装に手を入れる必要が生じるなど、正直目を逸らしたくなることもあります。ですが、Androidアプリ開発を通して改めて考える機会があったので、そこで得られた知見を紹介しようと思います。 本記事では特に、エラー時にユーザーへどのようなフィードバックを返すかという点に注目して、それについての考えと取り入れている仕組みを紹介します。 Androidにおけるフィードバックのデザイン まず、エラー時のフィードバックにおいて、どのようなコンポーネントを使い分けているかについて説明します。 VASILYではAndroidアプリを開発する際には Material Design Guidelines にできるだけ準拠するように心がけています。エラー時のフィードバックについても例外ではありません。ガイドラインでは、簡潔なフィードバックを表示する際にはSnackbarを使うように書かれています。そのため、エラーメッセージは基本的にSnackbarを用いて表示しています。一方で、システムからのメッセージはToastを使うように書かれているので、カメラやストレージへのアクセス権限がないときのエラーはToastを用いて表示するようにしています。 また、Activityの初期化時にエラーが起こった場合には、エラー表示用のレイアウトに切り替えて再読込を促すようにしています。 APIリクエスト時におけるエラーのフィードバック 表示するデータの多くをWeb APIを利用して取得するアプリでは、APIリクエスト時のエラーをどのように扱うかが特に重要です。そのため、ここではAPIリクエスト時のエラーに着目して、どのような問題があるかとそれを解決するために導入した仕組みについて説明します。 エラーメッセージの管理 同じサービスをiOSとAndroidなど複数のプラットフォームで開発する際に、エラーメッセージをどのように管理するかは悩ましい問題の1つです。よくある解決法としてはAPI側とアプリ側で共通のエラーコードを持ち、それを元にアプリ側でエラーメッセージの出し分けをするものがあります。 一方、VASILYではAPIに起因するエラーメッセージはAPI側で管理するようにしています。具体的には、更新リクエストやエラー時のレスポンスのJSONには、フィードバックに利用するメッセージを載せるようにしています。 { " message ":" プロフィール画像を保存しました ", " code ": 200 } { " message ":" プロフィール画像の保存に失敗しました ", " code ": 400 } これによりAPI側に起因するエラー時にはプラットフォームをまたいで同じエラーメッセージを表示することができます。 アプリ実装時の問題点 しかし、このアプローチが有効なのは、あくまでAPIのアプリケーションサーバー（Rails等）でのエラー発生時に限ります。なぜなら、アプリからAPIへリクエストを行った場合、アプリケーションサーバーへ到達する間に様々なエラーが起こり得るからです。そして、それらはもちろん上記のJSONフォーマットに沿ったものではありません。 例えば、Webサーバーの不調により、アプリケーションサーバーまで到達せずにエラーステータスのみが返ってくることが考えられます。他にも、端末がそもそもネットワークに接続されていない場合には、OS側からのExceptionとして返ってきます。 これらの様なケースを考慮せずに実装してしまうと、ライブラリやミドルウェアなどが返したエラーメッセージをそのままユーザーに表示してしまうといった事態に陥ります。その結果、ユーザに不信感を与えるだけでなくセキュリティ的に問題を起こす可能性もあります。 ErrorFeedbackクラスの導入 そこで、ErrorFeedbackという以下に示すようなクラスを実装し、エラーメッセージを扱いやすくしました。 ＊サンプルプロジェクト全体は こちら から見れます。 実装はシンプルで、受け取ったThrowableを元に対応するErrorFeedbackを継承したクラスのオブジェクトを返すというものです。 サンプルでは対応するExceptionを少ししか書いていませんが、必要に応じて追加していただければ様々なライブラリに対応することもそれほど難しくないと思います。また、パースするJSONのフォーマットを別のクラスに変えることで、他のAPIに対応させることもできます。 Snackbarを表示するためのExtensionの導入 引数として直接文字列やリソースIDを渡すのではなく、ErrorFeedbackオブジェクトを渡すことでSnackbarを表示できるExtensionを実装しました。これにより、アプリケーション全体で一貫してユーザーフレンドリーなエラーメッセージを表示できるようになりました。 fun Activity.snackbar(errorFeedback: ErrorFeedback, duration: Int = Snackbar.LENGTH_LONG): Snackbar = Snackbar.make(findViewById(android.R.id.content), errorFeedback.getMessage( this ), duration) まとめ Androidアプリ開発におけるエラー時のフィードバックをどのように扱っているかを紹介しました。普段、エラー時の表示まであまり気を配れていない方もこれを機に改めて考えてみてください。 最後に VASILYでは、細部までこだわりを持って実装できるエンジニアを募集しています。少しでも興味がある方は以下のリンクからお申し込みください。

こんにちは、インターンの@takewakaです。 もう春休みなのでほぼ毎日出勤してカスタマーサポートのAPIとUIを作る毎日です。 私は現在大学4年で4月からVASILYに就職する予定です。VASILYでのインターンは来月で丁度1年となります。 私は就職活動を始める前からwebエンジニアとして働く希望があったので、一般的な就職活動はあまりせず実務型インターンを通じてwebエンジニアとしてのスキルと経験を培うことに専念しました。 (ここで言う一般的な就職活動とは、『自己分析&企業研究→志望動機&自己PR作成→エントリー→面接→内定』の一連の流れを指します) 今振り返るとこのような形で就職活動をしたことは、自分にとって素晴らしい選択であったと自信を持って言えます。 本記事では、私がこのような就職活動を経た理由について書きます。 実務型インターンを主軸として就職活動した理由 得られるものの違い エントリーシートを無数に提出し、面接を複数受け精神的にも肉体的にも消耗してしまっている人を見かけたことが何回かあります。仮に落ちたとして得られるものは、面接に受かるコツくらいのものな気がして、あまり価値を見い出せませんでした。 インターンとして働けば、実務で必要とされる能力が得られます。 ここでいう実務で必要とされる能力とは、大規模なアプリケーションが持つ問題を解決する能力、複数人で効率よく開発するためのツールを使う能力、仕事を効率よく完了させるためのコミュニケーション能力などです。 また実力がつけば、効率よく人脈やお金も得ることができます。私はインターンのおかげでお金には困らなくなりましたし、これまでの人生では決して出会うことのなかった人達と出会うことができています。 本当にその職種に就きたいか判断する大きな手がかり 実際に就業するのだから、自分の職業適性を判断する上でこれ以上の判断材料はないだろうという考え方です。 理論と実践の間には少なからずギャップが存在していて、実際に就業してからでないとわからないことがたくさんあります。私にも実際に仕事をしてから気づいたことがたくさんありました。 仕事をする前は、エンジニアの仕事に関してものを作るということ以上のことはわかりませんでした。実際に仕事をしてみて、エンジニアはものを作るだけでなくユーザーに提供できる価値を認識し、提供する価値を高めるための改修を捻出し、それらを定期的にできるように常に将来を見据えた設計&実装をすることを知りました。私が思っていたよりずっと頭を使う、創造性が試される仕事だと気づきました。このことに気づくことができたのは、実際に運用されているアプリケーションの開発を任せてくれるVASILYのインターンのおかげです。 このように自分の職業適性を判断する上で、インターンで実務をこなすことで得た発見を考慮に入れることができるのは、判断の正確性を大きく高めることに繋がります。 また一旦就職をしてしまうと、仕事に向いていないことがわかってもなかなか辞めづらいと思います。インターンの時点でそこの判断ができてしまえば、軌道修正が比較的しやすいはずです。それどころかインターンで得た経験がなければ考えることもできなかった判断が下せるかもしれません。 そこで働く人を知れる 『仕事というものは何をやるかよりも誰とやるかだ』と考える人もいるように、一緒に仕事をする仲間がとても重要なのは言うまでもないと思います。 実務型インターンの利点として、就職した際仕事を共にする人々をよく知れる、ということがあります。 就職を決める前にそこで働く人々のことをよく知ることで、1つの不安要素を消し去ることができるのは大きなメリットだと思います。 インターンを通じて社内の色々な人と関わったおかげで、私にはそこに対する不安はありません。 また仕事上での触れ合いを通じて、就職した後自分がどうチームに貢献できるかを明確に描くこともできます。 真の意味での安定性 就職にあたって誰もが気にすることの1つに、収入の安定性があると思います。私も就職活動をする前は職を得られない心配をしました。 私はインターンとして一線で活躍するエンジニア達の横で仕事をしてきた上で、一つ確信したことがあります。 それは『安定することとは技術を持つこと』だということです。 滑り止めの内定を確保するために使う時間を、実務に当ててスキルと経験を得る方がセーフティネットとしての効果が高いと思います。 また社会で生き抜くために必要なのは実力、エンジニアの場合技術だと思うので、先回りするように実務経験を得ることは長期的に見てもメリットだと思います。 まとめ ここまで私が実務型インターンを中心に就職活動をした理由、及びその利点について説明してきました。 私はインターンのおかげでエンジニアとしての実務経験を得ながら、就職したい会社に就職することができました。 その過程で一人の力では得られなかったであろうスキルや人脈を得ることもできました。 今振り返っても、重要なタスクを振り当て本番デプロイまで任せてくれるVASILYのインターンは、エンジニアとして成長するのに最適なインターンだと思います。 本記事がこれから就職活動を控えている学生の皆さんのお役に立てば幸いです。 現在VASILYではインターンの募集を行っています。 この記事を読んで興味を持った方は以下のリンクからご応募ください。