VEGA TECH LAB

インテリア×テクノロジー

技術書典5に参加しました

こんにちは。R&Dグループ エンジニアのpondayです。

2018/10/08に開催された技術書典5に参加してきました。今回はその参加レポートを記事にします。

技術書典とは?

その名前の通り、『技術書の祭典』です。

有志が執筆した技術系同人誌を持ち寄って頒布するイベントで、フロントエンド、バックエンド、アプリ、ネットワーク、ハードウェア、電子工作など、幅広いジャンルの技術書が集まります。

商業誌ではなかなかお目に書かれないすごくニッチな技術の本から、注目度は高まってきているもののまだまだ日本語情報が出揃っていない技術の入門書、実際にサービス利用してみての知見など、最新の生きた知識に触れることができるのが最大の魅力です。

2016年6月の初開催から半年に1回のペースで開催されていて、今回が5回目の開催でした。

ベガコーポレーションはサークル『VEGA Tech』として、社内のエンジニア有志が執筆した技術書4冊を頒布してきました。

参加の経緯

今回のサークル参加は自分から提案したものです。

ベガコーポレーションとしては今回が初参加でしたが、実は私自身は技術書典2の頃から継続してサークル参加していて、当然今回も参加する気満々でした。 参加にあたっては個人参加も検討していたのですが、募集がかかる直前にベガコーポレーションにジョインしたので「せっかくなら」と話を持ちかけたらノリノリだったこともあり、会社として参加することになりました。

参加メンバー

執筆に参加したのは以下の3名でした。

  • foxtrackjp
  • mrtk
  • ponday

頒布したもの

Amazon Connect入門

著:foxtrackjp

AWSに何かと詳しいfoxtrackjpさんらしく、まだ東京リージョンにすら来ていない新サービス「Amazon Connect」の解説本です。AWS上でコールセンター業務の一部が自動化できるという一風変わったサービスで、機械音声による自動応答や、ユーザー入力に応じた返答のカスタマイズなど、基本的な使い方を画面キャプチャを交えて解説しています。

blenderによる輪郭線の表現

著:mrtk

3Dエンジニアmrtkさんからはblender本。2Dの表現で重要な役割を担う輪郭線を、3Dの世界に持ち込むための手法を検討しています。私はblenderには詳しくないのですが、画像も多く結果がわかりやすくまとまっているのではないかと思いました。

速習Elixir

著:ponday

弊社で技術検証を行っているプログラミング言語『Elixir』の入門本です。入門編ということでマクロのような高度な機能は省いて基本的な構文のみに絞って解説しています。社内でも参考資料として使えれば良いなという思いで執筆しました。

Web Components First Book

著:ponday

タイトルの通り『Web Components』というWebのAPIを解説した本になっています。上の3冊と違って社内では利用していない技術についての書籍なのですが、「フロントエンドネタも欲しい!」という個人的な意見で執筆しました。

執筆環境

原稿を書く、と言ってもAdobe InDesignのようなDTPソフトを使いこなせるメンバーはいませんでしたし、そもそも各人に環境構築してもらうのも面倒です。できることならMarkdownで済ませたいところでした。

技術書典界隈ではRe:VIEWという書籍執筆用のテキストフォーマットが良く知られていて、MarkdownRe:VIEW → PDFという変換を行ってくれるDockerイメージも主催メンバーの方から公開されています。実際、結構な数のサークルさんがこのDockerイメージを使っている印象です。

一方、最近少しずつですがCSS組版でPDFを生成しているサークルさんも増えてきています。これは、MarkdownからHTMLに変換してCSSで本のようなフォーマットに装飾する手法で、作り方次第では自由度の高いレイアウトが組めるのが魅力です。

page-break-after: always;

のような、Web制作では使わないCSSが知れたりもします。

今回は(面白そうだったので)Markdown → PDF変換を行うプログラムを自前で開発して、CSS組版に挑戦してみました。今回頒布した本は全てこのプログラムを利用して生成したものです。

内部的な実装で言うと、

  • markdown-itMarkdown → HTMLに変換
  • ↑のHTMLはヘッダ要素などがないので、mustacheフォーマットのHTMLテンプレートを別途用意して生成したHTMLを埋め込み
  • 生成したHTMLをpuppeteerで開き、印刷機能を利用してPDF化

という感じで実装しています(画像周りの処理や生成したHTMLに対するDOM操作なども行っていますが、その辺りは割愛します)。

VSCode拡張のmarkdown-pdfを参考に開発しました。

技術的な課題も多く悩まされたこともあったものの、執筆の気分転換に機能拡充する、という切り替えができて良い気分転換になったかなと思っています。時間的な制約もあり、実装できていない機能や足りない機能だらけではありますが次回また改良して使いたいところです。

当日の様子

当日は私と、初参加となるmrtkさんで現地参加しました。

前回までは秋葉原UDXで開催されていたのですが、キャパシティ的に限界ということで今回から会場を池袋サンシャインシティに移しての開催となりました。会場の床面積が3倍程度になった反面、サークル数は2倍程度に抑えられていたようで、通路は前回までに比べると明らかに広くなったな、という印象でした。

それでも開場してみるとその通路が人で埋まってしまい身動きが取りづらい場面すらあり、どんどん技術書典に注目している人が増えていることを実感しました。一技術書典好きとして嬉しい限りです。最終的に、サークル参加まで含めた総来場者数は10,000人を超えた(!)そうです。

我々はと言うと、サークル側で参加しているとはいえせっかく現地に行っているからには他のサークルの本も見たい!ということで、交代で店番をしながらもう一方が買い物に行く、という感じで回していました。買い物を終えて帰ってくるたびに満足そうに本を抱えているmrtkさんが印象的でした(笑)

私達のブースでも足を止めてくださる方もたくさんいらっしゃいました。お越しくださった方々、ありがとうございました!

反省点

社内メンバーを巻き込んでの参加は初めてだったので、反省点もたくさんありました。中でもこれからの課題だと感じたのは「"執筆"に対して感じているハードルの高さ」です。

今回声を掛けたものの断られてしまった社内のメンバーからも、

  1. 忙しい
  2. 本を書けるほどの知識がない
  3. 本にできるようなネタが準備できない
  4. 大変そう

と言った声がよく聞かれました。

1番はサービスのローンチと時期がかぶってしまった面があるので仕方がないかなと思います。

2、3 番はやはり「書籍」や「執筆」という言葉に対するハードルがあるのかなと感じました。「高度な内容でないといけないんじゃないか。」「こんな基本的な内容の本を書いてもみんな知ってることじゃないのか。」という感じでしょうか。実際に書いて頒布してみると「意外と書ける」し、「開発を通して得た知識、ノウハウが役に立つ人も一定数いる。」ということが実感としてあるのですが、このあたりのハードルを取り払えなかったのが自分の反省すべきところかなと思います。

「大変そう」という意見については実際それなりに大変なので否定できないです(笑)ただそれでも毎回本を執筆して参加を続けているのは、現地でその大変さ以上の楽しさを体感しているからなので、そのあたりも上手く伝えていけるようになりたいですね。

その他、

  • スケジュール管理
  • 表紙やDLカードのデザインまわり
  • 当日の売り方や役割分担

などなど、諸々の反省点もありましたが、次回以降改善していきます。

技術書典6に向けて

当然、次回も参加したいと思っています。

今回は多忙で執筆に参加できなかったものの、次回参加に向けて意欲を見せてくれているメンバーも出てきているので、今回の反省を活かしつつ取り組みたいと思います。

iOSDC JAPAN 2018

iOSアプリエンジニアの主計です。

今年も福岡からiOSDCに参加してきました。
去年もとても素晴らしいカンファレンスでしたが今年は更にパワーアップしているように感じました。iOSDCはコミュニケーションの場であり講義ではなく双方向コミュニケーションのカンファレンスとの説明が冒頭にあったのですが、それが実感できるカンファレンスだったと思います。
私自身いろんな方とコミュニケーションもとることができ、とても楽しむことができました。

印象に残ったセッション

どのセッションも興味深い内容でしたが、すべては紹介できないのでいくつか印象に残ったセッションを紹介致します。

MicroViewControllerで無限にスケールするiOS開発

www.icloud.com 今回のセッションのなかで一番聞きたかったセッションです。20人での開発もできるように画面を多数のViewControllerにしているとのことでした。
また、初期化の扱いやすさからInterfaceBuilderはStoryboardではなくXibを使うことでした。
GitHubでも公開されているのでコードリーディングしていきたい💪 github.com

QRコード読み取り?楽勝ですよ😙」=>「AVFoundationを信じたおれがバカだった😇」

speakerdeck.com QRコードには連結機能がありAVFoundationでの読み取りについてのセッションでした。QRコード活用の仕方しだいでとても便利なので扱う際には読んでおくといいと思います。

Depth in Depth

www.slideshare.net 深度情報を使って人物の切り抜きなどのデモをみることが出来ました。制約もありますが、モバイルで簡単に切り抜きが出来れば役に立ちそうです。

諸事情により9/2(最終日)に参加できなかったので9/1までの中から紹介させていただきました。 後日、ビデオが公開されると思うので見れなかったセッションも含めてみていきたいと思います。

iOSDCリジェクトコン

iOSDC JAPAN 2018 は終わってしまいましたが、リジェクトコンが9/18と9/20日にあります。
また面白い企画もありますのでご応募お待ちしております。 iosdcrc.firebaseapp.com

今年は福岡にサテライト会場を用意していますので福岡の方も是非参加お願いします。

東京

iosdc-reject-conference.connpass.com iosdc-reject-conference.connpass.com

福岡(サテライト)

iosdc-reject-conference.connpass.com iosdc-reject-conference.connpass.com

来年はcfpだしてスピーカーとして参加出来るように頑張りたいと思います!

iOSネイティブコードから構造体をUnityに渡す

ベガコーポレーションでエンジニアをやっているStellarBiblosです。   初回からかなりニッチな所ですが、これに関しての情報があまり無いようで、折角ですから記事にしてみました。

構造体

まずは各々の方で構造体を宣言しますが、変数の宣言順序が異なると正しく渡せません。 新規で作成している場合には考慮しなくていいと思いますが32bitサポートの場合バイト長が違ったりするため注意です。 また、C#だとboolはデフォルトで4バイトに対してC++は1バイトなため[MarshalAs( UnmanagedType.U1)]で明示的に1バイトと宣言しなければダメです。 その後3バイト長のchar/stringを用いてパディングしておいた方がいいと思います。 そうでなくても末尾が余っている場合はパディングを推奨します。

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)]
public struct Model {
    [MarshalAs(UnmanagedType.LPStr)]public string name;
    [MarshalAs(UnmanagedType.I4)]public int index;
    [MarshalAs(UnmanagedType.R4)]public float posX;
    [MarshalAs(UnmanagedType.R4)]public float posY;
    [MarshalAs(UnmanagedType.R4)]public float posZ;
}
struct Model_t {
    const char *name;
    int index;
    float posX;
    float posY;
    float posZ;
};

データ受け渡し

正しく構造体を作れていれば構造体のバイト長が一致します。 そのため構造体サイズ分アロケートしたポインタに対してmemcpyすればズレなくデータが取得できます。

class Reciever : MonoBehaviour {
    [DllImport("__Internal")] static extern void getModelStruct(IntPtr ptr);
    [DllImport("__Internal")] static extern void setModelStruct(IntPtr ptr);
   
    Model getModelFromNative() {
        var model = new Model();
        var ptr = IntPtr.Zero;
        try {
            System.Runtime.CompilerServices.RuntimeHelpers.PrepareConstrainedRegions();
            try {}
            finally {
                ptr = Marshal.AllocCoTaskMem(Marshal.SizeOf(typeof(Model)));
            }
            GetFurnitureStruct(ptr);
            model = (Model)Marshal.PtrToStructure(ptr, typeof(Model));
        }
        finally {
            if(ptr != IntPtr.Zero) Marshal.FreeCoTaskMem(ptr);
        }
        return model;
    }

    void setModelFromNative(Model model) {
        var ptr = IntPtr.Zero;
        try {
            System.Runtime.CompilerServices.RuntimeHelpers.PrepareConstrainedRegions();
            try {}
            finally {
                ptr = Marshal.AllocCoTaskMem(Marshal.SizeOf(typeof(Model)));
            }
            Marshal.StructureToPtr(ptr, model, false);
            setModelStruct(ptr);
        }
        finally {
            if(ptr != IntPtr.Zero) Marshal.FreeCoTaskMem(ptr);
        }
    }
}
Model_t myModel = *new Model_t { "Vega", 0, 0.0, 1.0, 1.2 };

extern "C" void getModelStruct(Model_t *model_t) {
    memcpy(model_t, &myModel, sizeof(Model));
}

extern "C" void setModelStruct(Model_t *model_t) {
    memcpy(&myModel, model_t, sizeof(Model));
}

おまけ

配列も取れます。 予め何らかの方法で配列長を知る必要がある為完璧な実装ではないです。

class ArrayReciever : MonoBehaviour {
    [DllImport("__Internal")] static extern void getModelStructArray(IntPtr ptr);

    Model[] getModeArraylFromNative(int length) {
        var models = new Model[length];
        var ptr = IntPtr.Zero;
        Int64 arrPtr = 0;
        try {
            System.Runtime.CompilerServices.RuntimeHelpers.PrepareConstrainedRegions();
            try {}
            finally {
                ptr = Marshal.AllocCoTaskMem(Marshal.SizeOf(typeof(Model)) * length);
            }
            arrPtr = (Int64)ptr;
            getModelStructArray(ptr);
            for(var i=0; i<length; i++) {
                models[i] = (Model)Marshal.PtrToStrucure((IntPtr)arrPtr, typeof(Model));
                arrPtr += (Int64)Marshal.SizeOf(typeof(Model));
            }
        }
        finally {
            if(ptr != IntPtr.Zero) Marshal.FreeCoTaskMem(ptr);
        }
        return models;
    }
}
Model_t myModels[3];

extern "C" void getModelStructArray(Model_t *models_t) {
    memcpy(models_t, &myModels, sizeof(myModels));
}

インターンで内定者さんがやってきた。

こんにちは。

ベガコーポレーション所属エンジニアの田中です。

 

 今回は、インターンで新卒の内定者の方が来社されましたのでその内容について紹介させていただきます。

 内定者さんには、弊社のデータ分析で使用しているSAP Predictive Analytics(以後SAP PA)を使って、電力予測とクラス分けの2つの課題に挑戦していただきました。インターン期間は2018年7月17日〜27日の約2週間で、成果発表を含めた課題解決を行っていただきました。

この記事の構成は、

  §1. 電力予測

  §2. クラス分類

  §3. インタビュー

  §4. 最後に

となっています。§1, 2が技術的な内容で、§3では内定者さんにインターンの感想などのインタビューを行ったものを掲載しています。そして、最後§4に総括・コメントを書いています。

 

§1. 電力予測

 このセクションでは、SAP PAを用いた電力予測について紹介します。SAP PAの詳細については、以前のブログに記載されておりますので、ご興味のある方は参照していただければと思います。

blog.vg-lab.com

 

 インターン課題として、内定者さんにはデータの収集・整形からSAP PAを用いた予測モデルの構築までの一連の行程を行っていただきました。その中で、予測精度を上げるためにどのようなデータを与えれば良いかという点を内定者さん自身で考察していただきました。

 学習データの収集では、電力会社が公開している電力量などの数値と該当地域の気候データの取得を行ってもらいました。これらデータを使って、SAP PAによる予測モデルを作成するためには目的変数説明変数を設定する必要があります*1 。特に、目的変数として何を与えれば、予測制度が上がるのか?を考えることが重要な作業となります。加えて、与える説明変数の期間についても調整してもらいました。ちなみに収集・整形したデータを学習データ評価データに上手く分割することで予測モデルの汎化能力を上げることも内定者さんに行っていただきました *2。 これら地道な調整の結果、今回は全てのモデル作成で「学習データ:2012年〜2017年,  評価データ:2018年〜予測日」の分割期間を採用しました。

 今回の予測対象は、2018年7月1日〜17日の期間での日毎の最大電力となっています。まずは、説明変数として気温を与えたものの中で、2パターンの結果を示します。 2パターンとは、それぞれ説明変数の期間を対象日から過去1週間分と過去1ヶ月間分に設定している場合に分けています。また、予測値を評価する指標としては、Root Mean Square Error (RMSE)を使用しました。RMSEは、予測と実測との差を表している値で、ゼロに近いほど予測精度が高いことを意味します。

 

 それでは、最大電力の予測結果を見ていきます。

1)説明変数:対象日から1週間前の気温  

f:id:TanakaKenta:20180806083024p:plain

RMSE

SAP PA  : 117.1  電力会社: 68.50

 

2)説明変数:対象日から1ヶ月前の気温  

f:id:TanakaKenta:20180806083315p:plain

RMSE

SAP PA  : 112.7   電力会社: 68.50

 上記2つの結果から、説明変数として気温だけを与えた場合は、説明変数の期間を調整することで僅かに予測精度が上がったものの、残念ながら2パターンともに電力会社の予想精度を大きく下回ってしまう結果となりました。

 

 次に、昨年の同時期の電力を説明変数として与えたものを示します。

 説明変数:対象日から1年前の前後3日分の電力 

f:id:TanakaKenta:20180806083546p:plain

RMSE

SAP PA  : 76.47   電力会社: 68.50

 SAP PAの予測精度は大きく向上したものの電力会社の予測精度にはまだ及びません

 

 そこで、説明変数として、気温と昨年の電力を併用したモデル作成しました。

説明変数:当日の気温と前3日分の電力

f:id:TanakaKenta:20180806083939p:plain

 

RMSE

SAP PA  : 36.15   電力会社: 68.50

 結果としては、電力会社よりも高精度な予測値を出すことができました。しかし、今回の予測モデルでは気温の変動が大きい時期に対する予測精度が著しく悪化してしまう汎化性での欠点も見つかりました。このように、予測モデルの性能の観点では、以前に弊社エンジニアが作成したモデルには及びませんでしたが、内定者さんの新しい発想から多くの発見が生み出されました

 

 §2. クラス分類

 次に、挑戦していただいた課題はクラス分類の問題となっています。特に、インターンではある2次元上のデータを2つのクラス(または3つのクラス)に分類する問題を解いていただきました。このクラス分け問題は、以下のように、2種類の値(+1またはー1)が分布しているデータを2色の領域に色分けする課題へと置き換えることができます。 

f:id:TanakaKenta:20180803092055p:plain

  この課題では、新卒エンジニアである私も同じ課題に挑戦し、どちらが上手く色分け出来るかの対決を行いました。 ちなみに私は、SAP PAとは別の手法としてTensorFlow(以後、TF)を用いたディープラーニングのアプローチから挑戦しました。

f:id:TanakaKenta:20180803084058p:plain

 今回は、与えられた学習データに対して、どのような学習モデルをどのように構築するのかという点にフォーカスした課題となっています。それでは、さっそく3本勝負の結果を見ていきます。ちなみに、勝敗の判定基準は内定者さんの主観です。

第1問) 2クラスの分類(長方形)

f:id:TanakaKenta:20180803093544p:plain

僅差で私、田中の勝利!! 正直、微妙なところですが内定者さんに1勝を譲ってもらいました。

 

第2問) 3クラスの分類

f:id:TanakaKenta:20180803093611p:plain

私は2色にしか色分けできていないのに対して内定者さんは3クラスに分類できているので、完全に内定者さんの勝利

 

第3問) 2クラスの分類(ロール)

f:id:TanakaKenta:20180803093626p:plain

 

何となく渦巻きを巻いているので私の勝利!! ということで3本勝負の結果は、内定者さん1勝、私2勝で何とか面目を保ちました。

  最後に、第3問に特化したアルゴリズムを内定者さんが作成して下さったので、その色分け結果を示します。詳細は省きますが、それなりに上手く色分けできているように思います。

f:id:TanakaKenta:20180806081334p:plain

 

 §3. インタビュー

 最後に、内定者さんにインタビューした内容を一問一答形式でまとめました。私からの質問に対して、内定者さんが答えるというものです。

Q1.  今、大学ではどのようなことをしていますか?

A1.  大学ではRubyを使って教育用プログラミング言語Scratchを対象とした研究を行っています。また、ものづくり部でアプリ制作もしています。学外では小・中学生にRubyプログラミングを教える団体に所属しています。あとエンジニア主体のRubyの勉強会に参加したりもしています。

 

Q2.  ベガの選考を受けようと思ったのは何故ですか?

A2.  福岡に知り合いが多い中で、ベガを知りました。福岡という土地柄と社員さんの雰囲気の良さに魅力を感じ選考を進めて来ました。東京の企業も何社か受けましたが、技術レベルの高さとユニークな強みのある会社であると感じたことが決め手となりました。

 

Q3.  インターンを受けようと思ったのは何故ですか?

A3.  一番はベガの社員さんの雰囲気を知りたいと思ったからです。あと実業務に早く触れて実践的に技術力を身に付けていきたいと考えました。

 

Q4.  インターンで技術的に大変だったことは何かありますか?

A4.  今までデータ分析をしたことがなかったので、予測モデルを作成することが大変でした。ただ、メンターさんに親切に教えていただいたので何とか形することができました。

 

Q5.  インターンの雰囲気はどうでしたか?

A5.  社員さんの雰囲気がとても良かったです。質問しやすい環境で自分のアイディアなども聞いていただけて楽しく課題に挑戦できました。

 

Q6.  なんとなくでも職場の雰囲気、業務のイメージはつかめましたか?

A6.  職場はキレイで家具も揃っていて雰囲気もとても良かったです。あとランチにも連れて行ってもらえて、いろいろ話ができてよかったです。業務の具体的な内容までは把握しきれてはいませんが、大まかなイメージはできたように思います。

 

§4. 最後に

 今回のインターンでは、二週間という短い期間の中で試行錯誤をしながら、しっかりと成果発表までやりきった内定者さんを見て、『とても優秀な学生さんだな』という印象を受けました。このような優秀な学生さんが弊社に集まって来ている状況をとても嬉しく思いつつ、弊社のエンジニアとしては身の引き締まる思いです。来年度から一緒に働いていけることを楽しみにしています!!

 

*1:目的変数は予測したい値(今回は日毎の最大電力)で、説明変数はその目的変数の予測値を算出するのに必要な値(例えば、気温)になります。

*2:モデルの学習に使用するデータを学習データ、そのモデルの検証に使用するデータを評価データと呼びます。

try! Swift 2018

ベガコーポレーションのiOSアプリエンジニアの主計です。 だいぶ遅くなってしまいましたが、3月1日〜3月3日で行われたtry! Swift 2018というカンファレンスに参加してきましたので印象に残ったセッションなどを簡単にレポートしたいと思います。 www.tryswift.co

印象に残ったセッション

Swift によるアルゴリズムの可視化

このセッションは内容も良かったのですがデモのライブコーディングがすばらしかったです! デモではPlaygroudを活用してベジェ曲線の仕組みがわかりやすくコードに落とし込んでいてわかりやすかったです。 自分はまだまだ開発段階でのPlaygroundの活用がたりないなとも感じさせられました。

動画・スライド

www.youtube.com speakerdeck.com github.com

超解像+CoreML+Swiftを使ってアプリの画像データ転送量削減に挑戦する

CoreMLと聞くと解析やAIという先入観がありましたが、こんな活用法もあるのか!と気づかせてもらえました。 画像の転送量削減は画像を使っているサービスならどこにでもあてはまることですし、UXにも直結するので試してみたいなと感じました。

動画・スライド

www.youtube.com speakerdeck.com github.com

番外編(お昼休み)

ランチを食べ終わってスポンサーブースを歩いていると人だかりが。。。 Yahoo! Japanさんのブースでライブコーディングが行われていたので覗いてきました。 普段開発している様子を紹介してくださっていたようでしたので時間を忘れて見入ってしまいました。 簡単に概要をまとめると、

  • ペアプログラミングでTDD
  • 細かい粒度のToDoを元に1人がテストコードを記述
  • テストが失敗ことを確認
  • もう1人がテストが通るように実装
  • テストが成功することを確認
  • レビューしリファクタ
  • ToDoにチェック

このような形で開発をしているとのことでした。 また、実装時にレビューは完了しているため、プルリクエストの際にはコードビューは行っていないみたいです。 テストコードのメソッド名を日本語で記述し、テストコードが仕様書になるように実装されていたのも面白かったので参考にしてみたいと感じました。

まとめ

国内外問わず素晴らしいセッションばかりでした。 海外のエンジニアと交流できたりできとても良いカンファレンスでした。 ただ、自分の英語力のなさに毎回落ち込みます。。。少しずつでも勉強しないといけないですね。。。 来年も必ず参加したいと思います。

福岡から iOSDC JAPAN 2017 に参加してきました

こんにちは。 ベガコーポレーションの主計(カズエ)です。

9月15日(金)から9月17日(日)に早稲田大学理工学部西早稲田キャンパスで開催された iOSDC JAPAN 2017 に参加してきましたので、見てきたセッション等の中から特に印象に残ったものについてレポートを書いていきたいと思います。 f:id:nesskazu:20170919164348j:plain

スポンサー紹介

オープニングでスポンサー紹介があったのですが、何処かで聞いたことのある声が、、、

エヴァンゲリオンミサトさんでした!

スポンサー紹介聞き流すことが多いかと思いますが、
今回はみなさん、食い入るようにみていて、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のテストは困難であるが、

  • データの流れを1方向にする
  • 状態をモデルに分離する
  • 振る舞いをモックに置き換える

などを実践することでテストが可能であることをわかりやすく解説されて参考になりました。

発表された内容はブログにもまとめられていますので、こちらもチェックしてみてください。 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に参加しましたが、一言で言うと「最高」でした。
スタッフ、スポンサー企業、スピーカー、参加者が作り上げているイベントという感じでとてもよかったと思います!
特にスタッフ、スポンサー企業、スピーカーの皆様ありがとうございました。

知り合いもほとんどいないなかでの参加でしたが、
パックマンルールを呼びかけて頂いたおかげで初対面の方ともたくさんお話することが出来ました。
運営の方ありがとうございます!

また、ノベルティもたくさん頂きました。 f:id:nesskazu:20170919163958j:plain

来年も開催されれば必ず参加したいと思います。あとCfP出したいなと思います!

SAP Predictive Analyticsの予測をAWS λで

こんにちは。
ベガコーポレーション所属エンジニアの篠原です。

 

少し日が開いてしまいましたが、前回ご紹介したSAP PAのモデルをエクスポートし、プログラム(今回はJavaScript)で実行したいと思います。

また、ローカル環境で動かすだけではおもしろくないので、AWS λ(とAPI Gateway)を使用し、数値(説明変数の値)を渡すと予測結果を返してくれる予測APIを作っていきます。

前回記事

blog.vg-lab.com

 

なお、本記事の内容は「第二回 合同勉強会 in 福岡」で発表した内容を一部変更してお送りします。*1

*1:第二回 合同勉強会 in 福岡ではJavaScriptでなくJavaで発表しました。

続きを読む