おんやど恵@湯河原でWanoグループの開発合宿してきた (後編)

では前回に引き続き後編です。

一晩明けて 8:00-

朝まで作業していた方が非常に多く、皆さん非常に疲れがたまっていたようです。
やさぐれてます。


 
こちらが朝食のメニューと朝の先輩です。
干物に、湯豆腐などついていました。

うまい

 
 

追加開発 9:00-

寝る部屋を引き払っても会議室は午後まで借りられる!
朝食を終えてからも、各チームの開発はまだまだ続きます。

 
 

成果発表! 12:30-

(1) チーム社内音楽レコメンド

チーム社内音楽レコメンド(チーム不健康)は社内BGMのプレイリストを個々人が追加/お気に入りする機能をほぼ完成させていました。
Dockerのubuntuイメージをベースとして、アプリケーションサーバー側の基本言語はGo,webフレームワークはRevelを使用しています。
それに加えて、いつの間にかAWS Pollyによるテキスト読み上げ/館内放送の仕組みを追加していました。


 

社内に音楽を流している間でも、放送でテキストスピーチによる呼び出しが可能なのだそうです。
恐ろしいですね。どこに呼び出されるんでしょうか。
 
今回の開発は、DockerやGoでのweb開発を皆が試すいい機会にもなったようです。

(2) チーム受付動画配信

弊社受付のプロジェクターにながす動画を操作/プレイリスト変更しようという本プロジェクト。

深夜に一部苦戦していたところはあったようですが、見事形にされていました。
WebSocket経由で、リアルタイムで動画プレイリストのリソース変更・再生/停止操作を行い、それがプロジェクターにつながるクライアントのコンピュータにも反映されます。
ネットワーク越しに某すごーいなアニメを再生/停止するデモを行いました。
Rustの布教も欠かさない!

(3) チームセンサー

オフィスの各部屋の人員管理を一手に担おうというこのプロジェクト。
エンジニアは物理センサー開発をし、デザイナーはGUIの開発を行いました。
運用時にはいくつかの種類のセンサーが使われる模様です。
「オフィスのドアは開いているか?」「予約はされているがミーティングルームは実際に使われているのか?」に対しては、フォトリフレクターなどの装置を用いました。
「トイレに人はいるのか?」には人感センサーなどを用いる話もありました。(どれを使うかまだ決まっていないようです。)

Slackやチーム社内音楽レコメンドの館内放送などとも連携しよう!という意見も出たので、今後の幅が広がりそうです。

(4) チームレンタル

社内端末管理システムに取り組んだこのチーム。
当初の構想に加え、貸出予約期間もオプション設定できるようになり、端末の外部持ち出し時の管理も視野に入ってきました。

パスワード認証だけでなく、「KAIROS」というクラウドの顔認証API経由でも端末利用者の持ち出しを管理することができるようになる予定だそうです。すごい。
苦労した点としては、アプリのカメラ周りをいじるのが初めてだったようで、そこに難儀したようです。

(5) チームVR受付

GearVRによる来客受付システムに取り組んだ僕のチーム。

結果的にはほとんどUnity勉強会!みたいになってしまいました。(というか他に写真なかったんすか!)
実際は、視線で呼び出したいチームのアイコンに視線を合わせ、GearVRのタップで選択していきます。

シーンの切り替えでなく、アニメーションでGUIの変更を管理するのが次の目標です…。

 
 

撤収 14:00-

こうしてWanoグループのエンジニア/デザイナー陣は爽やかな疲れ?と共に1泊2日の開発合宿を終えました。
普段一緒に働いているチーム以外のメンバー以外とも開発を行って、新しい知見を得たり、普段使わない技術にどんどん取り組んでいくことができました。
チーム同士で開発したものを相互に繋ぎこむアイディアも生まれていったので、まだまだ面白いことができそうですね。
おん宿恵さんでの開発合宿、非常に実りのある結果になったかと思います!
 

 

Read More

おんやど恵@湯河原でWanoグループの開発合宿してきた (中編)

では前回に引き続き中編です。

1日目続き

18:30 夕食

みなさん開始から4時間も集中して作業したのでとってもお腹ぺこぺこです。
ご飯を食べます。


見よ、これがWano技術陣だっ!!!!


重鎮の風格漂うWano技術陣の上位3名。


お刺身や…


ちょっとしたアラカルト…


ステーキまである最高のお宿…
それがおんやど恵の底力だっ!!!!
食事中に隣の部屋からカラオケが響くのもご愛嬌

20:00頃 再び開発

夕食が終わったらみんな再び開発に専念。
この時間に温泉に入った人もいるため、ちらほら浴衣姿の人がいますね。
酔っ払って顔が赤い人もいますが、それでも開発を続けるスタイル。
ストイックですね。


何やらセンサーチームはブレッドボードで回路を実装し始めている。


VRチームは相変わらずバーチャルにダイブ中。


飲みながら開発を続けるスタイル。


うまい棒駆動開発。

0:00 ひたすら開発開発開発…

開発が佳境を迎えます。
日付が変わってもとどまることを知らない開発。
みんな徐々に疲れが見えてきました。
だいたいお酒入ってるし。


やられている人1号。


こちらは和気あいあい
とレッドブルとビールとカップラーメンとお菓子。
ジャンキー野郎共ですね。


新しいバーチャルへのダイブを模索するVRチーム。


やられている人2号

そして朝になった。

Read More

おんやど恵@湯河原でWanoグループの開発合宿してきた (前編)

さる2017年3月10日/11日に、神奈川県は湯河原温泉の「おんやど恵」さんでWanoグループの開発合宿を行いました。
本稿では、合宿中にあった出来事を幾つかに分けて記事をアップしていこうかなと思います。

開発合宿の目的

今回の開発合宿では、エンジニア/デザイナー陣が5グループほどに分かれて各々のチームで開発を行いました。
開発のメインテーマは、「日常の様々なタスクを技術によって便利にする!」です。

チームは以下の通りです。

(1) チーム社内音楽レコメンド
(2) チームセンサー
(3) チームモバイル端末管理
(4) チーム受付動画配信
(5) チームVR受付

一応それぞれの開発テーマはあるものの、「普段業務で培っている知識を使って役立つものを作る」だけでなく、
なかなか案件では(まだ)使う機会のないIoT周りやマニアックな言語、VR等の技術に挑戦して、**開発チーム全体の徳を高めていこうぜ!**というのも目的の一つとなります。
 
それでは順次、出来事を記載していこうかと思います。

1日目

出発

集合。
最寄りから直接合流する人もいました。(僕も)

東海道線にてひたすら進みます。
各停なのに1駅の区間長いなー!という個人的驚き。

電車内では早速作業を開始する人や、

台湾出身のエンジニアを中心に、食習慣の違いについての討論会も開かれたりしていました。(ただの雑談ともいう)

12:30 湯河原到着

着きました。
当日の湯河原では源頼朝が兵を起した決起祭みたいなのをやってました。祭を見る機会はなかったのですが、あちこちで看板を拝見しました。
 

 
 
湯河原駅からバスで10分ほど、「おん宿恵」さんに着きました!
こちらのお宿は支配人さんが元システムエンジニアなのだそうです。
開発合宿用途として、痒いところに手が届く素敵な設備がしっかり揃っています。素敵。
他のベンチャーさんでの開発合宿でもよく使われているみたいですねー。

 
 
着いて早々とりあえず足湯につかるエンジニア。We are 足湯エンジニア。

13:30 昼食

宿近くの魚繁さんでお昼いただきました。
鯛のかぶと煮派とブリマグロ丼派に分かれました。

際限なく喋り続ける先輩たちを眺めながら、TunecoreのエンジニアYoheiheiくんが 「テレビみたいっすね。」 って言ったのが昼のハイライト。

14:30 – 開発開始

皆急に静かになり、チーム毎にあらかじめ決めていた行程にしたがって、黙々を作業を始めました。
ここで各チームが一体何をやっているかを見ていきましょう。

チーム社内音楽レコメンド

主に社内のBGMには音楽ストリーミングのサービスを利用しています。
ですが、「もっと面白く、個々人が自前でプレイリスト内に音楽を差し込んだり、気に入った曲情報を直接API経由で取得できるようにしよう」というプロジェクトを担当したのがこのチームです。

チームセンサー

このチームが取り組んでいる問題は「オフィスの残員管理」や「社内男子トイレ難民問題の解決」。
これらをラズパイなどのマイコンやセンサーなどを利用したIoTで解決してみよう!というアプローチを取ったのがこのチームです。

何やらいきなりハンダゴテでの作業が始まっていました。

チームレンタル

社内テスト用モバイル端末や社員そのものの人数が増えてきて、弊社でも端末のリアルタイムな管理が必要なフェーズにぼちぼち入ってきました。
それを顔認証APIを使ったり、端末ロックアプリ開発とかして管理していこうぜ!というアプローチを取ったのがこのチームです。
何やらいきなりホワイトボードでシステム全体の相関図を書きつつ、熱い議論が始まっていました。

チーム受付動画配信

新しくEdocodeのエンジニアとして入った藤田さんのプロジェクト。
弊社の受付スペースでプロジェクタを使って流される動画システムのバックエンドを、Rust/WebSocketで書こうというプロジェクト!

この日までにすでに構成図仕上げていらっしゃいました。すごーい!

僕もそのうちWebAssemblyとかRustで吐いて徳を積みたいです。

チーム受付VR

社内受付電話からの内線の多さを解消したい => タブレット用のかっこいい受付アプリ作りたい => それつまんないからVRでやろうぜ!
という流れで、無謀にも始まったVRのプロジェクトです。

Unity入門2,3日目のメンバーのみで始めるVR体験!

 
 
 
和やかな雰囲気の中始まった開発合宿。
一体どうなるのでしょうか(フラグ)

次回に続きます
 

Read More

PostCssで勧告ちょい前くらいまでのCSSをビルドする

最近はGolangの勉強中心のみやっててちょっと疲れたので閑話休題っす。


要約3行

PostCss
ボイラープレート
書く


Example

やったこと

前に「cssのclearfixハックの代わりとなる記法がChromeに実装される」っていうので注目を集めたこともあって、
ちょっとcssビルド周りの設定を見直しがてら、ここで一旦jsやhtmlじゃなくて最新仕様のcssだけpostcssのcliでビルドする、という主旨でやってみます。
使うもの、postCSSのcliツール。

ここ1年以上、postCSS使用の際はビルドツールの雄webpackからpostcssを呼んでいましたが、多分そっちはやりすぎっていう向きも多いかと思うので、今回はcliでのビルドの紹介に留めます。
(というか単体でのビルドやったことなかったので。)


PostCss

概要

PostCSSは各種css変換プラグインを通すためのAPIを提供するツールです。好きなコンパイラ設定を個々に導入できるイメージです。
cssフレームワークのBootstrapはsassからpostcssになったりと、そこそこ使われている場面があります。

PostCSSプラグインには、もちろんSASS記法を高速コンパイルするものもあります。
ですが、SASSが事実上のデファクト(?)とはいえ、独自記法に関しては今回の趣旨と違うため導入手順は割愛します。

プラグインの追加

特にcliで呼ぶ場合、コマンドで指定してもいいですが、npmで各プラグインをインストール後、
こういう設定ファイルを書くと便利です。

{
  "use": [
    "postcss-import",
    "postcss-cssnext",
    "postcss-flexbugs-fixes",
    "postcss-flow-root",
    "postcss-grid-kiss"
  ],
  "postcss-flow-root" : {
    "fallback" : "clearfix"
  },
  "input": "src/index.css",
  "output": "build/bundle.css"
} 

コンパイル

postcss -c .postcssrc.json 

代表的なPostCssプラグイン

cssnext(postcss-cssnext)

cssnextは幾つかのPostCSSプラグインがあらかじめ同梱されてるPostCSSプラグインです。
基本的には策定中のCSS仕様を使えるようにするプラグインであり、CSS版Babelみたいなものです。

今回の趣旨としては大枠としてこれだけを入れとけばOKです。

同梱されているPostCSSプラグインはこんな感じ
個別に無効化することも可能です。

Bootstrapと並ぶcssフレームワークのFoundationもこれを使ってるぽいです。

できるようになることは本家やCSSの仕様見てください。

  • all : initial; のバックポート実装が使えるようになる。
  • css variables が全ブラウザで使えるようになり、カラーパレットやmargin設定の管理がより強固にできるようになる。
  • custom media queriesで各デバイス用のメディアクエリを論理立てて一元管理できるようになる。
  • 同梱されているautoprefixerプラグインでベンダープリフィックス勝手につけてくれる。

と、まあそれなりに利点があります。

あとはColor FunctionなどSASSとかの文化から策定に行ったっぽい奴もありますね。

autoprefixer

おそらく世界で一番使われてるPostCSSプラグインです。前述のcssnextの中にも同梱されています。
moz-* とか webkit-* とかのベンダープリフィックスを自動で付与します。
下記のような感じですね。

.cannot-selectble {
    user-select: none;
}

 

.cannot-selectble {
    -webkit-user-select: none;
       -moz-user-select: none;
        -ms-user-select: none;
            user-select: none;
}

ちょい足し

cssnextに加えて、魔改造オレオレCSS化しないよう気をつけながらテスト的にPostCSSプラグインをいくつか追加してみます。

postcss-flexbugs-fixes

ブラウザごとに起こるflexboxの挙動の違いをある程度吸収します。

postcss-flow-root

幾つかのブラウザ実装が始まったW3Cのdisplay: flow-rootを入れ込みます。
しばらくはオプション指定でclearfixとかいうあのハックまがいの実装を吐いてもらいますが、これであの実装とは事実上別れを告げます。
こういうとこにはflexboxやGrid使いたいのですが。
しばらくは fallback: "clearfix"の設定が必要そう。

postcss-grid-kiss

Safariでも実装が始まったCSS Grid Layoutのプロパティを非対応ブラウザに対しても適用します。
どうやら全部は再現できていないっぽいですが。

postcss-import

webpackなどでimportした他cssファイルを展開するのに使います。
最終的に1ファイルにして、ブラウザ実行時に@import時の負荷を防ぎます。

番外/SASS記法

独自記法があるので今回は見ませんが、SASS記法を提供するためのプラグインでstarが多そうなものに precss , sugarss , postcss-scss 等があります。
他のも探せばあるかと思います。

まとめ

成果物

トランスパイラを通すことで仕様に則った便利機能を一足先に使っていきたいという意味では有用かと思います。

そうではなく、「バグを潰す」という意味では、あまり期待しすぎない方がいい感じです。
単純にトランスパイラでなんとかなる程度のブラウザ間の差分ならかわいいもので、辛さは多分そこで吸収できない先にあるわけなので。

つらつら書きましたが、あんまり最新の仕様を把握しきってないとこもあるかと思うので、もうちょっとなんとかなるぜってご意見あれば、マサカリ等お待ちしております。
以上です。

Read More

try! Swift Tokyoに参加してみた(2日目)

try! Swift Tokyoの2日目です。
1日目のレポートはこちらをどうぞ。

では以下まとめです。


テスト可能なコードを書くということの2つの側面

  • テスト可能なコードを書くのには、Testing OutputとTesting Inputの2つの側面から考える必要がある
  • Testing Output
    • Outputの検証。それが正しいかどうかテストを行って確認をする
    • 大事なのは副作用をコードの境界におくこと
  • Testing input
    • Co-effectが問題
    • Co-effectとは?
      • 依存性の注入
    • Co-effectがある場合のテストが難しい
    • 一つのアプローチとして、グローバルへのアクセスを必ず一つのstructを通して行うことで、環境を制御するやり方
struct Environment {
    let apiService : ServiceProtocol
    let cookieStrorage: HTTPCookieStorageProtocol
    let currentUser: User?
    let dateType: DateProtocol.Type
    let language: Language
    let mainBundle: BundleProtocl
    let reachability: SignalProducer<Reachability, NoError>
    let Scheduler: DateSchedulerProtocol
    let userDefaults: UserDefaultsProtocols
    ...etc
}
    • だいたい24個とかそれぐらいある。
    • たくさんあるけど、環境が制御できるのでやったほうが良い

誰もが知りたいSequenceとCollectionのすべて

  • SwiftのArrayは、Seaquesnce、Collection、BidirectionalCollectionというProtocolをベースに作られており、それによってSwiftの堅牢さが保たれている
  • Sequence Protocol
    • 要素のリスト
    • 無限に追加できる
    • 1回だけのiterate
    • Iteratorと、IteratorProtoclに適合したプロパティをもつ
      • IteratorProtocolとは、Elementとnextというメソッドをもつprotocol
    • Sequenceにcountというメソッドを追加してみる
let number = users.filter({$0.isAdmin}).count // => fine 一度countしてから捨てるので、処理が二重で行われてオーバーヘッドがある
let number = users.count({$0.isAdmin}) // => great 本当はこうしたい
    • 次のように拡張すると便利
extension Sequence {
    func count(_ shouldCount: (Iterator.Element) -> Bool) -> Int{
        var count = 0
        for element in self {
            if shouldount(element){
                count += 1
            }
        }
        return count
    }
}
    • もう一つEach Pairという拡張がオススメ
      • [A, B, C, D]のリストがあったとき、AB, BC, CDというペアを作って比較したいときがある。
      • これをつぎのようなメソッドを追加することで実現する
extension Sequence where Self.SubSequence: Sequence, Self.SubSequence.Iterator.Element == Self.Iterator.Element{
    func eachPair() -> AnySequence<(Iterator.Element, Iterator.Element)> {
        return AnySequence(zip(self, self.dropFirst()))
        }
    }
}
  • Collectionというprotocol
    • Sequenceベースのprotocol
    • すべてのCollectionは有限
    • 複数回Iterateできる
    • index, startIndex、endIndex, subscriptionメソッド, indexメソッドを持つ
    • APIErrorCollectionはfileprivateで自分で制御できない、自分でextensionで追加すると便利
  • BidirectionalCollectionというprotocol
    • Collectionベース
    • beforeというメソッドがあり、前にも後ろにも戻れる
  • 他にもMutableColelction、RandomeAccessCollection、RangeReplaceableColelctionなどがある

様々な場面でSwiftを使う

  • Swiftのオープンソース化にともなって、ウェブサービス、API、マイクロサービス、それ以外に、デーモン、ユーティリティ、ツールも作れるようになった
  • Swiftを使う理由としては、型安全、protocol、パフォーマンスの良さ等があるので、他言語と比較してSwiftを選択するというのもありだと考えた
  • SwiftはCと同じLLVM基盤なので、C言語のライブラリをimportして読むことが出来る
  • 事例1 – クローリングサービス
    • ウェブクローリングサービスをSwiftで書き直し始めている
      • もともとはpythonで書いていたが、他言語との将来性を考えた結果、Swiftにした
      • クローラー、DB(mysql)、APIサーバーの3つの構成
      • API経由でクローラーを制御するようにした
        • APIは型があるgRPCプロトコルベースでおこなっている
    • クローリングに必要なものは、すべて既存のC言語ライブラリのimportで実現できる
    • 今のところ20日程度動かし続けているけど問題は起こっていない
  • 事例2 – センサーを動かす
    • Swift for ARMというライブラリを使ってラズパイを動かす
    • I2C Bus経由で圧力センサーにアクセスして、slackにpostする
    • I2CBUSへのアクセスは、includeしてfopen, ioctlシステムコールを使えばいける
      • https://github.com/novi/i2c-swift にあげた
  • 作り方
    • すでにC言語のライブラリがあればそれを使えばいい
    • 他の言語のライブラリも、Swiftへのポートをすることで使える
  • Tokyo-Server Side Swift Meetupというのをやっているよ!
  • バッチ処理、APIサービス、コマンドラインツール、社内ツール等に使ってみると良い
  • スクリプト言語のようにつかうこともできる
  • (質問)クローラーをswiftに切り替えて、パフォーマンスは具体的にどう上がったのか
    • まだあまり測定できていないが、使っていたライブラリのオーバーヘッドがあったので、それを使わなくなくなったのは大きい
  • (質問)NSURLSessionを使わずに、libcurlを使っている理由はなぜなのか
    • Foundationはlinuxでほぼ実装はできているので、NSURLSessionも使えるが、NSURLSessionはHTTPの仕様に近い部分がさわれないので、libcurlにした
  • (質問)ラズパイとかにFoundationをのっけてるわけではないよね?
    • ラズパイはSwiftをサポートしているlinuxがのるので動く
    • ArduinoはOSがないので動かない

VRの革新と新たなユーザー体験(LT)

  • VRをどのようにゲーム、エンターテインメント以外に使えるかを検討している
  • ティム・クックはARはとても魅力的だと話している
  • Retail業界
    • アリババはバーチャルショッピングに対応
      • 誰でもニューヨークの店舗で買い物が出来るようにした
  • 不動産業界
    • ラトビアの不動産会社が、物件の360度動画を取って、それをVRで体験することが出来る
  • 自動車業界
    • Volvo、Audi、ジャガー、ホンダ、フォルクスワーゲン等が、VRによるバーチャルショールームとテストドライブを提供していたりする
  • ニュースやメディア業界
    • New York Times等が、360動画による放送をしたりしている
  • スポーツ
    • 東工大が開発したVRスケートボードがある
  • MobileBusinessInsight.com、VR Hub Tokyo Meetupを見てください。

iOSにおけるDocument IndexingとApp Search

  • App Searchとは?
    • Spotlight、Safariにアプリ内コンテンツのサジェスト/検索ができるシステム
  • App Searchはそんなに使っている人は少ないがすばらしい機能なので是非使って欲しい
  • Core spotlight API
    • 特徴
      • インデックス化をする処理を書く
      • これはローカルユーザーだけが見れる
      • 大量のアイテムのインデックス化に向いている
    • 作り方
      • Core spotlightをimportしてインデックス化する
    • 重要な属性
      • expirationDate – expireが設定できる
      • domainIdentifierを使えば複数のアイテムをまとめてインデックスすることも出来る
    • iOS10からは、spotlightからアプリの検索ができるようになる
  • webマークアップ
    • 対応するウェブサイトがある場合に使うと良い
    • ウェブサイトにディープリンクを追加
    • markupを使ってリッチ情報を提供する
    • ユニバーサルリンクか、スマートバナーを追加
    • safariで検索した時に、アプリにリダイレクトされるようになる
  • 詳しくは、gridNAのgithubを見てください
  • (質問)imageをインデックスに載せるにはどうしたらよいのか。リモートからダウンロードするけど、保存する処理を書いたりする必要があるのか。
    • URLでインデックスに追加することが出来る
    • 自動でシステムが縮小してくれる
  • (質問)Spotlightはどれぐらいのユーザーが使っているのか
    • 自分たちのアプリでは、50%ぐらいの人がSpotlightから来ている
  • (質問)データはindexに載せたかどうか確認する方法はあるのか
    • インデックスされたかどうか確認する方法はある

スタートアップのSwift

  • 2016年にアプリを開発した
  • 女性の友情を育むアプリMVP
  • PARSE + SWIFTで開発したら早く開発ができた
  • いくつかのメディアからインタビューを受けた結果、最初の2週間で10万人が集まってしまった
  • あまりにも多くのユーザーが一度に入ってしまったので、幾つかの問題が出てきた
    • 1分あたりのリクエスト数がParseの制限を超えてしまった
      • 一部のlocationのユーザーしか使えないようにして、なんとかリクエスト数を絞り込んだ
    • リテラシーが低いユーザーがどんどん使い始めた想定していないバグが露見した
      • slackチャンネルと繋いで、テストユーザーを募集してテストをしてもらった
      • 再現できないクラッシュに対しては、Slackでコアユーザーに呼びかけて会議に出てもらったりした
  • Swiftの機能を使って安全に書く方法を覚える必要があった
    • 新しいことを覚えたら、コードをどんどん修正していかなければならない
    • そのうちはじめに書いたコードは全部捨てないといけなくある
  • また、Parseがサービスを閉じることになった
    • マイグレーションをしなければならない
    • Parseに依存していたので、APiクラスでラップしていなくて、新しく全部別のサービスに載せ替えなければならなかった
  • swiftの言語のバージョンの変更に対応するのも大変だった
  • ただし、swiftは開発し易い言語だし、改善しやすい言語であるので、結果、大事なことに集中できると思う

きちんと型付けされたメッセージ

  • 可読性の重要さ
  • 複雑性を制御する方法を学ぶ
  • 複雑性は我々のロジックから来ているものと、我々がコントロール出来るものがある
  • 具体的に可読性が高いコードを書くということは?
  • 設計
    • e-mailをユーザー名とドメインに分ける処理
    • func split(email: String) -> (String, String)?
    • 可読性をあげるレベル1 – コメントを書く
      • コンパイルに影響を及ぼさないので、それを理解するかどうかはエンジニア次第
    • リーダビリティレベル2
      • typearliasや、structでSplitEmailというオブジェクトを定義する
      • それぞれ代償がある
        • 認識のコストは下がるが、オーバーヘッドや煩雑さが増える
    • リーダビリティレベル3
      • 返り値がoptionalであるということ
      • 次のようなwrapperを使ってステートを管理する
enum SplitEmail {
    case valid
    case infalid

    func init {
        if hoge {
            self = .valid
        } else {
            self = .invalid
        }
    }
}
      • これによりSplitEmailには2つの状態があることが理解できる
    • リーダビリティレベル4
      • splitterを定義する
      • Split<String, EmailSplitter>
  • 2つめの世界 – Delegation
    • Appleの定義するdelegateはoptionalである
    • これはライブラリのスタンダードな使い方
    • しかし自分たちはそうしたくない
  • Appleの仕様どおりではない場合、むしろ理解を妨げてしまうかもしれない
    • 複雑性、監修、モデリングのコスト…etc
  • 可読性を高める最短のルートはGodモード。つまり人の身になって考えるということ

忙しい人のためのApp Transport Security(LT)

  • 安全なhttpsと安全でないhttpsがある
  • 暗号化の方式によってはhttpsであっても安全でないと判定される
  • 詳しくはAppleのドキュメントである、Information Property Listをみるとよい
  • nscurlコマンドでもATS対応しているか確認をすることができる
  • ATSの無効化はいくつは種類がある
    • 全無効化
    • ATSの特定のドメインのみ無効化
    • iOS10から追加された項目
      • AVFoundationの通信に関して無効化
      • WebViewの通信に関して無効化
      • ローカルホストに対する無効化
  • WebView無効化を試した
    • HTTPの通信、安全なHTTPSの通信は出来るが、安全でないHTTPSの通信ができない
    • iOS10.2では、UIWebViewは通信できるという事実(WKWebViewはできない)

Swiftで堅牢なカラーシステムを構築する

  • カラーシステムのアーキテクチャー設計を1から作った
  • カラーシステム構築による便利さ
    • カラー設定を一箇所でできる
    • プラットフォームで一貫したカラーパレットを提供できる
    • 適用が楽になる
  • Appleのヒューマンインタフェースガイドラインは改訂を何度もしている
    • Dark modeの追加等
  • 色の選択はUXにかなり影響する
  • デザインはInterface Builderで決定するか、プログラマティックにするかという問題
  • Interface Builderはパワフルになってる
    • .clrファイルを共有すれば、カラーパレットの共有も可能
  • Interface Builderは共通のリファレンスがない
    • .clrファイルを共有しても、すべてのintereface builderを設定するのは大変
    • 複数のテーマでviewをカスタム化することができない
  • プログラマティックにおこなう
    • すべてのUIエレメントを一気に更新することができる
    • 影響範囲は一つのファイルのみ
    • カスタムカラーを作成できる
    • Zeplinというカラーエキスパートツールはこの処理をシンプルに行える
extension  UIColor {
    struct Pallet {
        static let hogehogeBlue = UIColor(...)
        static let white = UIColor(...)
        static let black = UIColor(...)
        ...
    }
    class var hogeText: UIColor {
        return Pallet.black
    }
}
  • 色を反転した時に、強調の加減が同じになるかどうかなどをチェックしたほうが良い
  • ユーザーのアクションによって全体の色を変更したい場合
    • Notification Centerを使って複数のViewを一度に変える
    • 次のように実装すると良い
protocol ColorUpdatable {
    var theme: Theme{get set}
    func updateColors(for theme: Theme)
}

protocol ColorChangeObserving {
    func addDidChangeColorThemeObserver(notificationCenter: NotificationCenter)
    func removeDidCngeColorThemeObserver(notificationCenter: NotificationCenter)
    func didChangeColorTheme(notification: Notification)
}

private extension ColorThemeObserving {
    func theme(from notification: Notification) -> Theme? {
        ...
        return theme
    }

    func updateColors(from notification: Notification){
            ...
    }
}

extension UIviewController: ColorThemeObserving {
    @obj func didChangeColorTheme()...
}
  • Inclusive Design
    • 男性の8%、女性の0.4%が色覚障害を抱えている
    • iOS10は色覚障害向けフィルターが設定できる
    • Inclusive Colorというライブラリを使うと良い
    • Inclusive Designの戦略
      • モノクロではなく色を使うと強調することが出来る
      • 大きなテキストは高いコントラスト比をもつのがよい
      • 色ではなく、コントラスト比に注目するということ
    • 昨年のWWDCのInclusive Design Sessionを参考にするとよい

サーバサイドSwiftの実例(LT)

  • Vaporを使っている
  • 開発は、linux固有のバグに悩まされたくなかったこともあり、xcodeで行っている
  • vaportのテンプレートを用意した
  • 実演したように、簡単にサーバーサイドSwiftは実現できる

モックオブジェクトをより便利にする

  • Interaction Test
  • protocolを定義することで、fake objectとreal objctの両方が使える
  • モックオブジェクトにverfyメソッドを追加すると、複数のassertionを一気にできる
  • default valueで#file、#lineを追加してロギングすることで、エラー時のコードの位置がわかりやすくなる
  • 大事なものに反応して、大事でもないものは反応しないようにするというテクニック
    • 大事でないものについては、マッチメソッドを外部から追加することで対応する
  • Hamcrest Matchers – 様々な言語で採用されているマッチャー
  • greaterThanOrEqualTo(2)、anything()というマッチャー
  • fakeオブジェクトを作る理由
    • リソースをつかうとき、グローバルへの影響が大きい時…
  • qualitycoding.org/tryswift2017 にサンプルコード等があるので参考にしてください

チームの生産性を改善するために決断疲れを最小化する

  • ソフトウェアエンジニアは常に意思決定をしているため、決断疲れが起きる
  • 特に何もしないと個々で判断をするので、それぞれで決断疲れを起こしてしまう
  • 意思決定の流れをシンプルにすることで問題を解決する必要がある
  • (問題)Xcodeのどこにファイルの置き方
    • ファイルを探すのに意外に時間がかかっているという事実
    • 色んなアプローチがあるが、シンプルにapplication, components, UIに分けた
    • Application
      • アプリ自体に関する情報
      • info.plistとかassetとか、launchscreenとか
    • components
      • 各コンポーネント毎にまとめた
    • UI
      • 各View毎、ViewController毎にまとめる
  • ペアプロをやっている
    • ほとんどがペアプロ
    • 2人が同じコードを見れるように、一つのiMacに2つのディスプレイと2つのキーボードを追加
    • Ping-Pongプログラミング – 順番にプログラミングしていく
    • Driver-Navigatorプログラミング – 経験があるほうがナビゲートしていく
  • (問題)プロパティ、メソッドの一覧性
    • Swiftの // MARK:- を使う
    • これを自動入力するためにXCodeのテンプレートを作る
    • protocol conformance – extensionでprotocolに適合するメソッドを分けるということ
  • Cross-Functionalペアリング
    • エンジニア-デザインのペアリング等の複数の職種間でのペアリング
    • ボタンをどう定義するかの話し合いとかを行う
  • (問題)UIオブジェクトのデザイン
    • 次のようにしてスタイリングを予め定義しておく
enum UIButtonStyle {
    case primary, nagative
    func applyTo(button: UIButton {)
    case .primary:
        ...
        return  cutomButtom
    case .negative
        ...
        return  cutomButtom
    }
}
  • Retrospective(振り返り)
    • コアチームメンバーだけで行う
    • 食事やお酒を出したりする
    • ホワイトボードをKeep, Discuss, Improveに分けてタスクを分ける
    • ファシリテーターは最後の締めくくりをポジティブになるようにする
  • 決断は一人で行わせるのではなく、チームでブレストすることで行う
  • (質問)ペアプロという二人で働くことにより損なわれる快適さについてどうか
    • 確かに人との関係に集中しないといけない
    • ただ、自分ではやっていないことを学ぶ機会ではある
    • 自分の好みを犠牲にして、もっと良いものを見つけることができる。また、他の人に自分の好きなものを進めることが出来る
  • (質問)リモートで働いているとペアプロが難しいがどうしたらよいか
    • 人によってはスカイプを使ってペアプロをしたりしている
    • 自分の経験から、リモートでもスカイプなどでペアプロすることで寂しさがなくなって良かった
  • (質問) 奇数の開発者がいた場合どうやってペアプロしたら良いか
    • DoITというツールを使う
    • 一人の人がでるようなら、頻繁にペアを変えるようにする
    • 一人の時には小さな仕事をやってもらうようにする

Client-Side Deep Learning(LT)

  • Metal Performance Shaderに追加されたCNN (convolutional neural network) APIs – MPSCNNというのがある
  • 今まではiPhoneからAPI経由でサーバーに送る必要があったが、今はこのMPSCNNを使うことでローカルで行うことが出来る
  • 学習は強力な計算力を持つPCでやって、iOSに学習した結果をもたせて処理を行うという仕組み
  • MPSCNNはいろんなファイルフォーマットに対応している

オープンソースコミュニティをスケールさせる

  • オープンソースの流れ
    • ソースコードを公開する
    • ユーザーが使い始める
    • ソリューションになる
    • どんどんスケールする
  • プロジェクトが大きくなるとどうなるか
    • プロジェクトの勢いを保つということが難しくなる
      • アクティブユーザーが増えるとユーザーサポートに時間がかかってしまう
      • なんらかの方法で機能追加を検討するプロセスが必要
      • 他のことに時間を大きく取られて、メインテナー自身が一番のユーザーでなくなってしまうという事実
    • ユーザーとの情報のアンバランスがおきる
      • ユーザーはissueを投げたら覚えているけどメインテナーは覚えていないという問題
  • どうしたら良いか
    • エラーメッセージの改善
      • 余計なエラーメッセージを表示することをやめて、重要なメッセージは色をつけるようにした
      • 余分なエラーメッセージを表示するオプションをつけた
      • エラーが発生した時点で関連するものを提示する
        • issueへのリンクを貼るとか
    • issue botを使う
      • ボットを使うことで、オープンイシューとプルリクが大きく減った
    • issueテンプレートを導入した
      • ほとんどの人が守ってないけど
    • コマンド1つでユーザーの環境変数を収集して、バグ報告に役立てられるようにする
      • 適切なタイミングでボットによってコマンドを提示するようにする
    • 似たようなissueが沢山上がるような場合はドキュメントを充実させる必要がある
      • 適切な箇所にリンクを貼る必要がある
      • これも関連するissueが投げられたときは、botが自動でリンクを提示するようにする
    • ボットを使うことでissueの一貫性を保つ
      • しばらく投稿がないとissueを自動でクローズする
      • これによってissueのライフサイクルを保つことができる
    • Dangerというサービスをつかうことで、プルリクされたら自動テストをまわして、テストに失敗したらユーザーにテストを改善するように通知するようにする
    • コントリビューターを増やす
      • コントリビューターを増やすためにもコード規範を作る
      • 全員が検証できるように透明性を保つ
      • コードベースのシンプルさを保つ
      • いつでもフレンドリーに受け入れる体制にする
    • ユーザーがソフトを拡大できるようにする
      • DSLを利用できるようにすることでユーザー自身である程度制御できるようにする
      • プラグインとして追加できるようにしても良い
  • (質問)ライブラリでメンテナンスできていないものはあるか。それをどうするか
    • 透明性を確保することで、誰かに引き継ぐ

Swiftでのエラーハンドリングとエラー耐性についての教訓

  • ここではError型の話ではなく、コードの中で理想的なコードパスではないものすべてをエラーと呼ぶことにする
  • エラーハンドリングにおけるinputについて話す
    • 明示的入力 – 引数、self等
    • 暗黙の入力 – 状態
  • 状態
    • グローバル変数とシングルトン
    • 時間的状態
      • コードを実行する順番とか
      • コメントや、間違った順番でコンパイルできないようにするとか
    • リアル世界の状態
      • ファイルシステムやネットワーク、以前のコードの実行出力等
    • これらの状態の変更は無計画にやるべきではない
  • ハンドリング方法
    • 特定の状態を表すインスタンスを作る
    • init時に、特定の状態の型を入れるようにする
  • optionalを使う時
    • あまり大きなエラーではないとき
    • 発生頻度がやや起こりがちなエラー
  • Error型を使うとき
    • 致命的な問題に使われるとき
    • 発生率が低く、影響範囲が広いエラーに利用するのが適切
  • 入出力の流れを意識してあらゆる状態に対処する
  • (質問)fatalerrorを使うときはどういうときか?
    • 確かに”!”を使うことはあるが、そういう箇所の確認はテストを回して確認することにしている
    • また、なぜそれをやらなければならないかをちゃんと探る

ゲーム&ウオッチ

  • 人は昔から時計でゲームをやってきた(任天堂のゲーム&ウォッチの写真を見せながら)
  • SpriteKitでゲームを開発できるようになった
    Apple WatchでNESエミュレータが動作する様子。
  • C++のNESエミュレータでやってみた
    • ウォッチでは低レイヤーの描画が使えない
    • フレームごとにテクスチャーを生成して対処
    • サウンドはAVFoundationが使えるようになったのでそれで行った
      • ただしシミュレータでは動作しなかった
  • 多くのセンサーが利用できそう
  • タッチイベントが、Touch Up取得できないという事実
    • LongPressイベントの時間をめちゃくちゃ短くして対応
  • Watchはマルチタッチイベントに対応していないため、デジタルクラウンでBダッシュを実現
  • Carthageに対応したので、誰でも簡単にApple Watchアプリに組み込むことができるよ!!

なぜ登るのか

  • オススメする理由1
    • チームスポーツはメンバーのレベルがみんな同じでないと面白くない
    • ボルダリングは違う
    • 同じ壁で複数のレベルが楽しめる
  • オススメする理由2
    • 登るのには色んなアプローチがある
      • 体のやわらかさでいくか、筋肉量にものをいわせていくか、ジャンプ力でいくか、バランス感覚でいくか…など
    • これらの要素をミックスさせて、自分だけの解決法を考えられる
  • オススメする理由3
    • 一人でできるスポーツ
    • でもグループで競争でやっても面白い
  • これ、Swiftと同じではないか?
  • みんなボルダリングをやるといいよ
  • (質問)東京周りで、今この時期はどこにボルダリングがオススメか。
    • インドアのボルダリングが良い
    • 新宿のレックスジムにはフローティングルーフがあり、これがとても面白い

Read More

try! Swift Tokyoに参加してみた(1日目)

try! Swift Tokyoに参加してきました。

カンファレンスのネームプレート。try! Swift Birdちゃんが可愛い。
Twitterで名前を募集している。

カンファレンスの様子

僕はしばらく大きなカンファレンスに出ていなかったのですが、アプリも作ってるし、Swiftのイベントがこの時期にあることを知って参加することにしました。

参加してざっくり感じたこと。

  • 参加者は結構多い。
  • 同時に複数の場所で講演をやることはないので、見たい講演は必ず見れる。
  • 同時通訳の精度がすごい。
  • 朝ごはんと昼ごはんが出るよ!
  • 講演の大半が英語なので、ある程度英語ができるともっと楽しいと思う。(自分はできない)

こんな感じです。
他の言語のカンファレンスと比較して、参加料が高くしかも英語がメインな感じなので、ちょっと敷居は高いのですが、それだけの価値は十分にあると感じました。
特に同時通訳の精度が高く、専門用語も適切に翻訳できてて非常に聞きやすかったです。
…同時通訳レシーバーがあることを最初知らず、最初の2講演を詳しく理解できなかったのが悔やまれるところ。

以下、1日目のまとめ。


Swift開発者が知りたかったけど聞きにくい機械学習のすべて

  • 機械学習とは、男の場合の平均値、女の場合の平均値、体重がこれぐらいの人の平均値、こういう職業の人の平均値…etc等、属性ごとに平均値を出すみたいなもの。
  • 機械学習はUIデザインに似て、ちゃんんと動くか、それが正しいのか証明できないのが難しいところ。
  • 機械学習は、TensorFlowのチュートリアルや、ドキュメント、本が揃っている
  • python on the server, Swift in the hand

Swift on Android

  • C言語はすべてのプラットフォームで動く。なのでC言語にしちゃえばよくない?
  • Android NDK (native development kit)というAndroidをC言語で書くSDKがある。
    • AndroidはOSがなかなか統一されないので、Cの標準ライブラリも微妙に違っててやりづらい
    • Hell Problemだぜ!
  • Blurrr SDKというのを作った
    • Macアプリとか、Windowsアプリとかも動くぜ!

SwiftのPointy Bits

  • Swiftって安全な言語だよね。
  • でも安全じゃなく書けるよ。
    • unsafePointerを使おう
  • Unsafe Pointerは次の利点がある。
    • C言語のAPIが使える
    • 速度が速い
      • ただし安全性とのトレードオフはあるので注意。

アプリを新次元に導く3D Touch

  • Appleは3Dタッチに5年もの開発を費やしたんだからみんな使おうよ!
  • 3Dタッチを使う理由
    • ユーザーのショートカット
    • App Storeで3Dタッチ対応アプリのところに出せる
  • 3Dタッチでできること
    • ホーム画面のクイックアクション
    • Peek & Pop – 事前にページを開く前にプレビューをする等によく使われている
    • Notification Content Extension
      • 通知画面にアクションを追加できる
  • 3Dタッチは古い端末に対応していないので、長押しなどのアクションを代用して、同じ機能を古い端末で対応するようにしたほうが良い

Pixcels、プロセスと情熱

  • 主に開発おモチベーションをどう保つかという話
  • 講演者は去年あたりから、Blogを始めたり、様々なハッカソンに参加したりして精力的に活動してきたらしい
  • (あまり興味がなかったのでちゃんと聞いてない…)

毎日リアクティブ

  • シナリオ駆動にすることでステートを減らすというアプローチ
  • Swiftでリアクティブをやる方法
    • RXSwift
    • ReactiveSwift
    • etc…
  • 既存のどのような処理に適用していくか
    • MVVMモデル
    • async operation
  • observerパターンに適用するのがよくある
  • トレードオフ
    • デバッグがやりづらい
      • ログイベントを一連のストリームで発火させることでデバッグをやりやすくする
    • フランクにやりすぎるオーバーヘッドが大きくて死にやすい
    • 変更時の影響範囲のわかりにくさ
    • 多用するとカオスになりがち
  • 大事なのは、必要な箇所だけを使うということ

Unsafe Swiftの安全性(LT)

  • Unsafeで扱いたいことがある
    • C言語で書きたい
    • 速度をあげた
    • Lowレベルにアクセスしたい
  • https://www.raywenderlich.comでUnsafe Swiftについて書いた
  • ちゃんとした書き方をすれば、Unsafe Swiftでも安全性を担保することはできる、らしい…。

クックパッドアプリのテストを味わう

  • UITestにフォーカスした話
  • Cookpadアプリ
    • グローバルアプリと日本アプリの2つがある。統合はまだしていない
    • UIコンポーネントは複数大きく変えている
    • だいたい10万行ぐらいある
    • 以前は2週間、最近は1ヶ月毎にアップデートしている
  • kano-model という品質モデルがある
    • Attractive – Must-be Qualityの2つのパラメータ
    • Diachronic Quality for mobile
  • UITestのやり方
    • テストを書いてからリファクタリングをする
  • UITestの実際
    • マニュアルテストは簡単に出来る、ユニットテストはめんどくさい
    • でも理想はその逆
    • Cookpadでは2015年〜2017年にかけてUITestを初めてCrash率を下げ続けた
  • UITestの書き方
    • シナリオを書く
    • シナリオをRubyコードに変換
    • Appiumで実行
  • Appium
    • XPATHはOSのフレームワークにかなり依存している
    • テストをUIレベルからメソッドレベルに移動することが大事
  • image diffを見せるようにした。
  • 数ヶ月前にSwiftを実装し始めた
    • テストがあるので安心してSwiftの実装出来る
  • テストの自動化は、エンジニアのスキルとはまた違ったスキルセットが必要
  • (質問)Appium使ったことあるけどめっちゃ時間かかるんだけどどうしてAppiumなのか?
    • システムアラートを制御することができる
    • 外部の環境をいじれるのでこれを選択している
    • コミット毎にテストを回しているわけではない
  • (質問)時間がかかるboundaryのテストの代替テストはどういうものを考えたか
    • よくある文字入力などのバリデーションにかかわるテストは、UIテストではやらず、ユニットテストで担保する

データレイヤを分離する

  • MVAモデル(Mininmum Viable Architecture)という考え方
    • 必要最小限のアーキテクチャー
  • CoreDataやRealmObjectはスレッドを意識したりしないといけないけど、Viewレイヤーでそれを意識したくはない。
  • DTOモデルに変換するというアプローチ
  • Plain old swift Object(POSO)で書く
  • CoreDataやRealmObjectからDTOモデルに変換する
  • デメリット
    • 自分たちでモデルを管理しないといけない
    • 変換処理を書く必要がある
  • (質問)DTOに変換するのはオーバーヘッドがあるわけだけど、その線引きをどうするか
    • チームの規模が大きかったら、全員が全員スレッドとかを考えなきゃいけないとめんどくさいので、そういう視点で線引をどうするか考える

UIをSwiftlyに書く

  • Resultライブラリを使う
    • API読み込み時に、成功時のパターン、失敗時のパターン、失敗したけどデータを受信したパターン、通信は成功したけどデータが不正のパターン…等色々考えると大変
    • Resultライブラリを使って、成功/失敗に応じて処理を分ければ2つ考えるだけでよい
  • AutoLayout
    • storyboard、xibではIDベースでコンポーネントが管理されている
    • プログラマティックにAutoLayoutを実現するのは大変
    • Autolayoutを書くとよくわからない
    • Cartograpyというライブラリを使う
      • Autolayoutをわかりやすいコードに書けるラッパーライブラリ
  • ステート管理
    • APIはロード中/成功/失敗3つの主要なステートがある
    • コレをboolで扱う
      • このパターンはisError && isLoadingのステータスの場合がよくわからなくなる
    • enumとswitchステートメントで管理すれば良い
  • コード共通化
    • ProtocolとProtocol extensionを利用する

SwiftのWeb APIとアプリをともに構築する

  • API設計
    • Paginationの例
      • Get /posts?page=2
        • 各ページでのpostコンポーネントの担保
      • Get /posts?before=2
        • このようにすることで、ID 2のページの前のページの要求をすることができる
    • APIのバージョニング
      • /v1/posts
    • REST
    • APIの問題点
      • クライアントのアップデートが必要
        • Web Linking RFC5988を使うというアプローチ
        • SwiftではWebLinking.swiftというライブラリがある
        • application/hal+json, application/vnd.siren+jsonという方式で書くと、APIのアップデートに耐えうる実装にできる
        • さらにHypermedia APIを使うことで、ビジネスロジックをバックエンドに持ってくるができる
  • APIを実装する上で使えるSwiftのウェブフレームワーク
    • 主にfrank, kitura, vaporの3つが有名
    • frankは軽量なフレームワーク
  • テスト
    • linuxでXCTestを使える
  • デプロイ
    • herokuが楽
    • IBMのブルーミックスというのもある
    • 他にもDockerを使ったり、もちろんマニュアルデプロイでも良い
  • ロギング
    • paperteailを使ってプリントしたエラーを取得する等

楽しく便利なSwiftチャットボット

  • 去年は色んなチャットボットサービスが出て来た
  • まだまだ微妙な感じ
  • LINEで言語学習ボットを作ってみた
  • グーグル翻訳のAPIを使う
  • ボット上で言語登録ができる
  • Spaced Reptirionで言葉を覚えたか確認する
  • ボットの作り方
    • 制限のあるインタラクション
      • テキストとかスタンプとか画像とか動画とか、全部に対応しようとしない
    • とにかくシンプルにする
    • 他のサービスのapiを活用する
    • 不必要にユーザーを長く拘束しないようにする
  • (質問)VRにボットを拡張する可能性はあるのか
    • 今すぐではないが、VRが軌道に乗れば、確実にくると考えている

Realmを使ってコラボレーションアプリを作る

  • コラボレーションアプリとは?
    • Google Docs/Slack/JIRA等の複数のユーザーが同時進行で作業をすることができるアプリ
  • Realmとは?
    • 大事なのはDBマッパーではない
    • データーベースそのもの
    • schemalessではない
  • Realmの利点
    • オブジェクト思考で書ける
    • クラスを実装するように書けるので、新しいことを覚えなくてよい
    • React NariveやXamarinにも対応しているので、クロスプラットフォーム
    • すべての環境で同じデータを使いまわせるので、バックアップがとれる
    • トランザクション管理をしているので、リアルタイムの共同編集ができる
    • サーバー、モバイルの両方でRealmを採用すれば、アプリからjsonを排除することが可能
  • Realmの通知機能
    • プロパティの変更、オブジェクトの変更、コレクションの変更、ファイルの変更など、様々な変更に対して通知を行える
    • イベントハンドリング
  • アクセス権の管理
    • Admin Realm, Management Realm, Permission Realmなどの特別なRealmを使えば、アクセス権の管理が可能
  • (質問)RealmをPHPから操作する等、さらに多言語対応をしていく予定はあるか
    • 今のところPHPの予定はないが、いくつかの言語をサポートする予定はあり、そこになくてもGithubで要望を上げてくれれば検討する

独自のツールを構築する

  • ネイティブアプリの問題点
    • ネイティブアプリのテストが長くなってしまう問題
    • ウェブアプリケーションも提供していたが、カスタムUIがたくさんあるとウェブ側の開発のスピードについていけない
  • これらの問題は、コードの再利用が出来ていないことによるのではと考えた
  • 独自コンポーネントのインフラの構築のアプローチ
    • jsonベースのコンポーネント
    • React in swift – Katana
    • React Native
  • すべての実装を、Swiftにするか、Javascript(React Native)にするかすれば、コードが使いまわせるのでは。
    • Swift
      • メリット – 盛り上がっているし非常にエキサイティング
      • デメリット – コンパイルは遅い、独自実装が沢山必要
    • React Native
      • デメリット – 依存性が593もある、まだ若い、アップデートが早い
      • メリット – ただしAPI思考アプリと親和性が高い
  • その他のReact Nativeのメリット
    • シンプルなレイアウトシステム
    • テスト界隈は進んでいる(javascriptなので)
    • コミュニティはオープン
  • React Nativeでコンポーネント化することで、コードを再利用をはかった。
  • (質問)複雑なコンポーネントをReact Nativeだけでできるのか
    • 今のところ自分達のアプリでは、問題になっていない

リアルタイム物体検出アプリでよりよいフィードバックを提供する(LT)

  • Wantedlyで行っている名刺の検出の例
  • 前提
    • カードの認識はできていて、位置が定まっているという前提
  • 複数のオブジェクトがカメラに写っている時に、各フレーム間のオブジェクトラッキングが問題
    • オープンCVの標準のトラッキングを実装したけど、一部の端末で微妙だった
    • なので独自トラッキングメソッド実装した
  • その他iOSアプリでは、CoreImageを使ったトラッキングがあるが、あくまで顔認識に特化したもの
    • サンプルコードをGithubにあげた

UXエンジニアという働き方

  • エンジニアもUXを考える必要があるということ
  • エンジニアにしかできない提案がある
  • UXを良くするためにやっていること
    • リテラシーが高くなく、アプリに馴染みがないユーザーをターゲットにした場合
    • 実際にユーザーにプロトタイプをいじってもらって検証した
  • デザイン思考の学習
    • デザイナーの思考法であり、これによりイノベーションを起こすような思考法
    • ユーザーへの共感がポイントらしい

以上、本日はこんな感じでした。

今日の講演の内容を振り返ると、全体的に

  • Swiftの安全性について
  • ネイティブアプリのテスト、特にUI Test

についての話が多かったように思います。
特にテストについては、質問でもそれに関連した質問が多かったですし、やはりどこもテストについては苦労しているんだな、と。

また、講演の内容によっては自分もやっているようなことについての話もあったので、これはもっとちゃんとブログを書いて情報発信をしたほうがみんな幸せになれるかもれしないな、と。
本ブログではアプリについてあまり書いてないですが、今後は積極的に書いていこうかと思います。

あ、あと夕方ぐらいにMacのバッテリーが持たなくて、最後はiPhoneで講演をメモっていました。
Macのバッテリーを長持ちさせるにはどうしたら良いんだろうか?

とにもかくにも、とても刺激的な一日でした。
明日もまたtry! Swiftに行ってきます!
ではまた明日。

Read More