Yappli Engineer Blog

株式会社ヤプリの開発メンバーによるブログです。最新の技術情報からチーム・働き方に関するテーマまで、日々の熱い想いを持って発信していきます。

try! Swift Tokyo 2019 にみんなで参加しました🏃

f:id:mishimay:20190327163605j:plain

はじめに

こんにちは!
iOSアプリ開発をしている三縞・古賀・高島・司馬・山本です。

今回ヤプリは try! Swift Tokyo 2019 にシルバースポンサーと学生スポンサーとして協賛しており、iOSエンジニア5人で参加しました。 f:id:mishimay:20190328121051j:plain

この記事では各自の視点から、印象に残った発表や参加したWorkshopについてご紹介します。

発表

ヤプリのiOSエンジニア 古賀です。 今年3月に入社したばかりなんですが、さっそく try! Swift に行かせてもらいました。 会場が駅から少し距離があったので雨降らない日でよかったです。

全体的な感想

思っていた以上に外国の参加者が多く、英語の発表も多かったので、英語学習をサボりがちな自分には大きな刺激になりました。 またSwiftのカンファレンスだけあって、SwiftのString、コンパイラコード、アセンブリなど、iOSアプリケーションの話というよりもSwiftの話に特化した濃い話が多かったことが印象に残りました。 普段はそこまで深掘りして調べることが少ないので、新しい視点を得られて良かったです。

個人的に印象に残った発表

  • native macOS application、またはAppKitの世界

スピーカー: https://twitter.com/1024jp

「nativeとは何か?」
「言語でNativeを考えると、非ネイティブの言葉をきいて違和感を感じるのと、Nativeでないアプリは同じ」

Native言語で書かれたものがNativeアプリという単純ことではなく、 アプリケーションを使っていることをできる限り意識せずに、ユーザーが目的を果たすことができるような透明なアプリケーションこそがNativeなんだという考え方が新鮮でした。

確かに、ヒューマンインターフェイスガイドライン(HIG)を無視したCocoaフレームワークを使ったアプリよりも丁寧にガイドラインに沿ったReactNativeの方がユーザーにとってはNativeなアプリケーションと捉えてもおかしくないですね。Nativeらしくするためには、ネイティブフレームワークだけでなくHIGの理解も絶対必要だということですね。

また、macOSの開発はiOSの開発と違いアプリケーションの表示サイズが可変なので、他に動作する複数のアプリケーションと違和感なく混在させ馴染むような設計をする必要があり、例え「iPhone」「iPad」「Mac」のアプリを統合させるような Marzipan プロジェクトがリリースされたとしても上記のような思想を理解していないとユーザーから求めるNativeにはなりえないということが新しい気づきでした。

ワークショップ

Raspberry PiでSwiftを探検する

ヤプリのiOSエンジニア、司馬です。 以前はObjective-Cで開発することが多く、昨年からSwiftでも開発するようになりました。

try! Swiftは今回が初参加で、Raspberry Piのワークショップに参加してきました。内容はSwiftコードでLチカさせるものです。 Lチカは「LEDチカチカ」の略で、電子工作の世界で言う「Hello World」のことらしいです。

Raspberry Piを使うワークショップは2つあり、わたしが参加した方は人数少なめで10人弱ほどでした。参加者は国際色豊かで、みんなで机を合わせてほのぼの(?)と進行していきます。

今回のワークショップでやったこと

Raspberry Piのセットアップ

OSのインストールなど、普通にセットアップをすると4時間くらいかかってしまうそうです。 今回はetcherというサービスを使い、OS(Raspbian)をマイクロSDカードにコピーして時間短縮しました。

https://www.balena.io/etcher/

Raspberry Piにswiftをインストール(なぜかSwift3だった)

$ sudo apt-get install swift3 

Raspberry Piに wiringpi をインストール

※wiringpiはこのあと出てくるGPIOを制御するためのライブラリです。

sudo apt-get install wiringpi

まずはLピカ

講師から必要な備品が配布され(ラズパイとマイクロSDカード、電源コードは持参)、いよいよLEDを光らせます。

配布されたもの

  • LED
  • レジスタ(抵抗器。電圧を緩やかにする。)
  • ブレッドボード
  • ジャンパーワイヤーのオス端子(ブレッドボードに刺す用)、メス端子(Raspberry Piのピンに差し込む用)

部品とつなぎ方の説明は、他にも分かりやすい詳細な記事が多いので割愛します。

散らかった写真で恥ずかしいのですが、ブレッドボードに刺したLEDがピカッと光りました。

f:id:mishimay:20190327163530j:plain

GPIOコマンドでLチカする

Lピカが成功したら、今度はRaspberry PiのGPIOピンを、コマンドで制御していきます。

こちらのコマンドで、今のGPIOピンの状態が表示されます。

$ gpio readall

GPIO番号2を出力モードに変更します。

$ gpio -g mode 2 out

GPIOピン番号2へ出力します。 0が off でLEDが消えます。 1は on なので、LEDが点きます。これでコマンドでLEDの点滅を操作できます。

$ gpio -g write 2 0
$ gpio -g write 2 1

swiftyGPIOを使ってLチカ

最後にこちらのライブラリを使い、点滅が繰り返される状態にします。

https://github.com/uraimo/SwiftyGPIO

ワークショップは基本英語での進行のため、なかなか理解が難しかったですが、初のRaspberry Pi(しかもSwiftで!)に純粋にワクワクして楽しめた4時間強でした。 try!Swiftに参加してみて、Swift大好きな人達がこんなに多くいることや、IoTやバックエンド開発での活用が進んでいることが新鮮で、以前よりSwiftが好きになりました。

Accelerate Frameworkを使った高速オーディオ波形レンダリング

山本です。 このWorkshopは、オーディオ波形描画にとどまらず様々な高速化のテクニックが紹介されとても実践的な内容でした。これだけで参加費の元が取れると思います。

具体的には、オーデイオ波形描画をオーディオデータの読み込み・整形・描画の3つフェーズにわけ、それぞれフェースで高速化テクニックをサンプルコードをもとに実際に試すことで理解を深めていきました。

ここでは、SoundCloudのような波形を描画する際のテクニックをご紹介します。

すぐ思いつく方法は UIBezierPath によってLineを追加する方法ですが、これだとサブパスが多くなり描画が重くなります。

その代わりに CGMutablePath.addLines(between:transform:) を使う方法が紹介されました。これにより波形を1つの閉路パスとして表現することで高速な描画が可能です。また、アフィン変換によって UITraitCollection の変更による画面変化にもすぐに対応できるようになります。

f:id:mishimay:20190327163534j:plain

他にも

  • オーディオデータの高速な読み込み方法と最適化
  • vDSPでのダウンサンプリングやL/R channelのマージ
  • 描画パスデータ(Array<CGPoint>)をvDSPで高速生成 (これが一番驚きました)
  • GCDの落とし穴とその回避策

などどれも有用で、参加前は「4時間かぁ長いなぁ」と思っていましたが、実際にはあっという間に過ぎてしまいました。

f:id:mishimay:20190327163538j:plain

これまでの経験上、オーデイオ波形の可視化はたびたびリクエストされる要件だったので、今回のWorkshopでパフォーマンス要件を含めて習得できたのはとてもありがたかったです。

講師の Andrew Coad さんとスタッフの方々、ありがとうございました!

クラウドネイティブなSwiftバックエンドを構築しよう

高島です。 私は今回、Kituraを使ってバックエンドサービスを立ち上げようという内容のワークショップに参加しました。

f:id:mishimay:20190327163550j:plain

KituraはIBMが提供するSwiftを用いたWebサービスフレームワークです。 https://www.kitura.io/

ワークショップの流れは以下の通りです。

  1. Kituraサーバを立ち上げてみる
  2. OpenAPI, Origin Resource Sharing (CORS) に対応する
  3. POST, GET, DELETE, PATCHリクエストのハンドリングを実装する
  4. DataBaseと連携する(PostgreSQLを利用)
  5. Linuxコンテナにデプロイする(DockerのKubernetesサポートと Helmを利用)

f:id:mishimay:20190327163546j:plain

これまでサーバーサイドの開発に携わることのなかった私ですが、
今回のワークショップでサーバーサイド開発のファーストステップを踏み出すことができました。
KituraはiOSエンジニアにとって言語の壁がないフレームワークであるのがいいですね。
アプリエンジニアがバックエンドにまで開発領域を広げることで、
自身が作りたいサービスを実現しやすくなり、開発に対するモチベーションも上がるかと思います。
私もこれを機に、何かひとつアプリを出すことを目標にしてサーバサイドの開発を続けていきたいです。

また、今回のワークショップでは以下のソースコードを利用しました。
シンプルな内容であり、手順も丁寧に記載されていて分かりやすいです。
ぜひ手元で動かしてみてください。

https://github.com/IBM/ToDoBackend

Open Source Swift

三縞です。 Swiftは仕事でもプライベートでも長い時間触れているプログラミング言語なので、Swift自体への理解をもっと深めたいという思いでこのワークショップに参加しました。

ただスタートラインであるSwiftのビルドでかなり苦戦しました。 事前準備としてできるところまでやって来たのですがビルドに成功するまでには至らず、ワークショップ当日のスライドや紹介してもらった資料からヒントを得ながらなんとか道筋を付けました。 結局ビルドは家に帰ってから成功させることができました。

ワークショップでは https://bugs.swift.org 上で StarterBug のラベルで検索することで比較的取り掛かりやすいバグを探せることを知りました。

また、SwiftSyntaxで構文解析すれば簡単なツールならすぐ作れるということも知ったのでもう少し深く調べてみようと思います。

Swift活用の広がり

サーバーサイドSwiftなど、iOSアプリ開発以外でのSwift使用の話はSwift発表当時からありましたが、実運用に耐えられるのかという懐疑的な意見が多かったと思います。
しかし今回の「Swiftでソーシャルネットワークをつくろう」という発表の中で実際にSwiftがiOSアプリ以外で動いているプロジェクトを知りました。

Swiftが使用されていると紹介されたプロジェクト

またワークショップの中にもサーバーサイド開発や Raspberry Pi を使うものがあり、Swiftがさまざまな場所へ広がっていっているのを感じました。
Swift 5 のABI安定化によってSwiftの活用がさらに進むことを期待します。

さいごに

ヤプリではエンジニア向けカンファレンスに精力的にスポンサーとして参加しており、それらの有料のカンファレンスには業務の一環としてタダで参加することができます。 ご興味がある方は是非一度弊社に遊びにいらしてください!

www.wantedly.com

Copyright © 2018 Yappli, Inc. All rights reserved