福岡から iOSDC JAPAN 2017 に参加してきました
こんにちは。 ベガコーポレーションの主計（カズエ）です。
9月15日（金）から9月17日（日）に早稲田大学理工学部西早稲田キャンパスで開催された iOSDC JAPAN 2017 に参加してきましたので、見てきたセッション等の中から特に印象に残ったものについてレポートを書いていきたいと思います。
スポンサー紹介
オープニングでスポンサー紹介があったのですが、何処かで聞いたことのある声が、、、
そっくりさんかと思ったらミサトさんだった #iosdc pic.twitter.com/0Seb0FzAEf
— ぎぎにゃん (@giginet) 2017年9月16日
スポンサー紹介聞き流すことが多いかと思いますが、
今回はみなさん、食い入るようにみていて、twitterのタイムラインがすごい勢いで流れました。
スポンサー企業にとっても嬉しいはずなのですごい良い取り組みだと感じました。
Swaggerで始めるAPI定義管理とコードジェネレート
speakerdeck.com
Swagger Codegen を使うことでクライアントを自動生成してくれるのは便利そうでした。
CocoaPodsのライブラリとして出力したりRxSwiftとの連携も可能だったりと結構実用的そうです。
設計とコードの乖離防止はクライアントとサーバー双方のエンジニアの不要なコミュニケーションを発生させたりするのでSwagger等のツールを使い齟齬を発生させない仕組みが大事であることを再認識しました。
節子、それViewControllerやない…、FatViewControllerや…。
ViewControllerはいろんな処理を書きやすいためつい、節子になりそうですがUIの処理とビジネスロジックが混ざってしまうとテストがしづらくなってしまいます。
UIKitをimportしないPresenterを作り責務を分けることでテストしやすくなります。
設計に関してはメリットデメリットがあるのでなかなか選定が難しいですが、責務を分離しテストしやすくすることに関しては実装コストを上昇することを防ぐためにも必ずやっていきたいです。 dev.classmethod.jp
具体例とクイズで学ぶ、Swiftの4種類のエラーの使い分け
Swiftのエラーには
- Simple domain errors
- Recoverable errors
- Universal errors
- Logic failures
があり、どのようにエラーハンドリングしたいかで利用するエラーを決めることが大事とのことです。発表の後半はクイズ形式であったため、参加者が考える機会がありとてもいいなと思いました。
@koherさんはQiitaでもSwiftのエラーについて記事にされていますので下記も一緒に読んでみるといいかと思います。
qiita.com
qiita.com
Build high performance and maintainable UI library
UIのテストは困難であるが、
- データの流れを１方向にする
- 状態をモデルに分離する
- 振る舞いをモックに置き換える
などを実践することでテストが可能であることをわかりやすく解説されて参考になりました。
発表された内容はブログにもまとめられていますので、こちらもチェックしてみてください。 blog.kishikawakatsumi.com
RxSwiftのObservableとは何か
Observerパターンの解説からRxSwiftの実装を紐解いていくかたちでの丁寧な発表で、
各Observableの違いをとても理解しやすかったです。
発表原稿をQiitaにアップされているので合わせて読むと良いと思います。
qiita.com
ディープリンクの設計と実装
speakerdeck.com
WebがRESTfullなURLであれば基本的にそれにあわせてアプリのURL設計をしていけばよいとのことです。
ただ、UITabBarControllerやUINavigationControllerの階層など考慮すべきことも多いのでをしっかりと検証しないとUXを低下させてしまいそうなので気をつける必要がありそうです。
新しい画像フォーマットHEIFを用いたiOSアプリの通信量削減
speakerdeck.com
現在はWebPで配信しているがiOS11からHEIFに対応したので検証したところ約50%通信量削減に成功。
問題点は特許の関係からiPhoneを爆買い（48台程度）する必要がある（笑）
Qiitaに補足が上がっていたのでこちらも合わせてどうぞ。
qiita.com
コード生成による静的なDependency Injection
speakerdeck.com
DIすることで疎結合になるがインスタンス生成が面倒になることを解消しようとするアプローチでの発表でした。
テストしやすくするためにはDIは重要なので参考にしたいと思いました。
iOSDCで「コード生成による静的なDependency Injection」について話した & 口頭原稿を公開 github.com
サポート効率を上げるためのロギング環境構築
bugsnagではアプリのいろんなところに仕込むだけで、パンくずログが取得できるので、バグの改修に役立つ。
エラーコードをしっかりと定義し管理することが大事。
再現できないバグは多くの人にコストがかかるのでしっかりログをとることが大事であると思いました。
まとめ
今回初めてiOSDCに参加しましたが、一言で言うと「最高」でした。
スタッフ、スポンサー企業、スピーカー、参加者が作り上げているイベントという感じでとてもよかったと思います！
特にスタッフ、スポンサー企業、スピーカーの皆様ありがとうございました。
知り合いもほとんどいないなかでの参加でしたが、
パックマンルールを呼びかけて頂いたおかげで初対面の方ともたくさんお話することが出来ました。
運営の方ありがとうございます！
パックマンルール、輪になって話す時は一人分入ってこられるスペースを作りましょう！
— にわタコ (@niwatako) 2017年9月16日
#iosdc #a pic.twitter.com/An3LdcgXqv
また、ノベルティもたくさん頂きました。
来年も開催されれば必ず参加したいと思います。あとCfP出したいなと思います！
SAP Predictive Analyticsの予測をAWS λで
こんにちは。
ベガコーポレーション所属エンジニアの篠原です。
少し日が開いてしまいましたが、前回ご紹介したSAP PAのモデルをエクスポートし、プログラム（今回はJavaScript）で実行したいと思います。
また、ローカル環境で動かすだけではおもしろくないので、AWS λ（とAPI Gateway）を使用し、数値（説明変数の値）を渡すと予測結果を返してくれる予測APIを作っていきます。
前回記事
なお、本記事の内容は「第二回 合同勉強会 in 福岡」で発表した内容を一部変更してお送りします。*1
*1:第二回 合同勉強会 in 福岡ではJavaScriptでなくJavaで発表しました。
SAP Predictive Analytics 分類/回帰分析
こんにちは。
ベガコーポレーション所属エンジニアの篠原です。
今日は弊社でデータ分析に使用しているSAP Predictive Analyticsをご紹介したいと思います。
SAP Predictive Analytics(以後SAP PA)はHANAで有名なドイツSAP社の予測分析ツールで、分類/回帰、クラスタ、アソシエーションなどの分析を行うことができます。
今回は分類/回帰分析について解説いたします。
分類/回帰分析は教師あり機械学習で、目的変数がカテゴリの場合は分類、数値の場合は回帰となります。
SAP PAでは、目的変数の型で自動的に決められます。
テキストファイルやExcelファイルあるいはデータベースでデータを用意し、学習を行うことで予測を行うことができるモデルを作成することができます。
弊社ではデータ加工の都合上、テキストファイルで行なっています。
テキストファイルの場合はCSVでもTSVでも大丈夫です。
(自動判別してくれます。)
では実際にモデル作成と予測を行います。
今回は最大電力を予測し、電力会社の予想結果と比較・勝負したいと思います。
データの用意
電力会社によりますと、予想最大電力は天候・予想気温、曜日、節電効果、景気動向などを考慮して予想しているそうです。
節電効果や景気動向はデータが手元にないため、電力会社で考慮されているパラメータの内、気温と曜日(及び休日)を説明変数として採用します。
天候は1日の内での決定が難しいために採用せず、気温は最高気温を使用します。
その他のパラメータとして、時期(季節)を特定するための年間通算日（1月1日を1とする）を用います。
予測には用いませんが、ラベルとして日付と比較用の電力会社の予想が入っています。
データはこんな感じになります。↓
データがある2012年1月から2017年7月を学習期間とし、2017年8月の予測を行います。
SAP PAでのモデル作成
SAP PAを開き、分類/回帰モデルの作成を選択します。
データソースの選択で用意したテキストファイルを読み込みます。
変数記述ではデータの保存形式（数値や文字列など）や値の形式（連続値や断続値など）を指定します。
以前行ったことがあるデータと同じカラムで変数記述ファイルが保存してあったり、変数記述を作成してあれば読み込むだけでOKですが、今回は変数記述ファイルがないので、解析し、必要であれば保存形式や値の形式を指定します。
変数の選択では目的変数と除外する変数を選択します。
年月日と電力会社の予測値は予測に使用しないので除外します。
モデル作成の設定画面です。モデルの自動保存や詳細設定が行えますが、デフォルトのまま進めます。
モデル作成が行われます。説明変数の数やレコード数にもよりますが、数秒で終わります。
（1000の説明変数の場合でも数十秒から数分で終わります。）
モデルができたら、モデルの情報を見ることができます。
↓のグラフは実測値と予測値の比較で、緑の理想線と青の検証線が近く、誤差範囲が少ないものが理想です。
モデルの適用と評価
モデルの適用をすると、説明変数から目的変数の予測を行うことができます。
今回は検証用に8/16までのデータに対して適用を行います。
実際の最大電力と電力会社の予想、SAP PAの予測結果をプロットしました。↓
| 電力会社RMSE | SAP PA RMSE | |
| 8/10まで | 91.71 | 49.25 |
| 8/16まで | 78.07 | 93.92 |
8/10まではSAP PAで行ったモデルの予測結果が当たっているようです。
RMSE※を計算しても8/10までのRMSEは電力会社が91.71に対し、SAP PAが49.25とSAP PAの予測が当たっていますが、8/17までのRMSEは電力会社が78.07に対し、SAP PAが93.92と逆転されました。
原因としましては、休日設定は日本の祝日としたためにお盆休みが休日となっていなかったことや、8/11の山の日が2016年に導入されたため2015年までの学習データと状況が異なったことが考えられます。
※RMSE（Root Mean Square Error）
予測値が正解から乖離を示す。モデルの予測精度の悪さを表すため0 に近い値であるほど良い。
残念ながら電力会社に後半逆転され負けてしまいましたが、20分ほどで電力会社に匹敵する予測を行うことができました。
今回はSAP PAのGUIでの操作がメインでしたが、SAP PAの分類/回帰分析ではJavaやJavaScriptなどのソースもエクスポートすることが可能です。
次回以降に作成したモデルのソースエクスポートとその実行を行いたいと思います。
↑の合同勉強会でもSAP PAについて発表する予定です。
興味がある方はぜひお越しください。
Vega Tech Lab立ち上げについて
皆さんこんにちは。ベガコーポレーション所属のIT系エンジニア、宮末です。
ベガコーポレーションでは、これまでECプラットフォーム上でのビジネスをメインに行っておりました。 しかし、今以上の高い価値をお客様へ提供する事を考えたところ、今後は自社開発によってビジネスを進め、その中に新しい体験を作る必要性を感じています。
そのため弊社ではITエンジニアの募集を強化すると共に、テクノロジーを用いて新しいインテリアを研究・提供するをテーマに活動を行う社内の技術者集団Vega Tech Labを本日立ち上げました。
今後は技術力向上を目指し、お客様への新しい体験と高い価値を提供できるよう邁進していきます。
