こんにちは、株式会社ヤプリでAndroidエンジニアをしているdais-sasaです！
先日、アプリエンジニア界隈で盛んに活動しているpotatotipsという勉強会で登壇してきました。
毎回主催する企業が異なり、今回はWantedly様が主催されています。
結構先の話になりますが、11月に弊社でも主催する予定なので良ければご参加下さい。
今回のpotatotipsでは、MotionLayoutのtipsを発表しました。
その時に使用した資料を公開します。
Swift 5 対応でやったこと
iOSエンジニアの三縞です。
ヤプリでは2週間に1度木曜日、普段なかなか手を付けられずにいる改善系のタスクに取り組む「Yappdate Day」を実施しています。
私は今日の Yappdate Day で Xcode 10.2 および Swift 5 への対応を行ったので、その内容を紹介しようと思います。
前提
移行前は Xcode 10.1, Swift 4.2 でした。
ライブラリ管理ツールにはCarthageを使用しています。CocoaPodsは使用していません。
行った手順
- Xcode 10.2 をインストールして開く
Preferences > Locations > Command Line Tools を「Xcode 10.2」に設定
Carthageのアップデート
$ brew upgrade carthageCarthage管理のライブラリの再ビルド
$ carthage bootstrap --platform iOS --no-use-binaries
（CocoaPodsを使っている場合はCocoaPods管理のライブラリも）必要に応じてライブラリのバージョンアップ
ライブラリの対応状況を見ながらBuild SettingのSwift Language VersionをSwift 5に設定
ビルド時のError, Warningを解消
Xcodeによるプロジェクト設定の更新を実施 Xcodeに表示される「Validate Project Settings / Update to recommended settings」をクリックして手順に従って実行
感想
ビルドエラーがほとんどなく、短時間で作業を終えることができました。
Swift 2 から 3 への移行を思い返してみるとあのカオスに比べて圧倒的に楽で、Swiftの開発が過渡期を終えて安定してきたのを実感しました。
try! Swift Tokyo 2019 にみんなで参加しました🏃
はじめに
こんにちは！
iOSアプリ開発をしている三縞・古賀・高島・司馬・山本です。
今回ヤプリは try! Swift Tokyo 2019 にシルバースポンサーと学生スポンサーとして協賛しており、iOSエンジニア5人で参加しました。
この記事では各自の視点から、印象に残った発表や参加した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を使うワークショップは２つあり、わたしが参加した方は人数少なめで10人弱ほどでした。参加者は国際色豊かで、みんなで机を合わせてほのぼの（？）と進行していきます。
今回のワークショップでやったこと
Raspberry Piのセットアップ
OSのインストールなど、普通にセットアップをすると４時間くらいかかってしまうそうです。 今回はetcherというサービスを使い、OS（Raspbian）をマイクロSDカードにコピーして時間短縮しました。
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がピカッと光りました。
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 の変更による画面変化にもすぐに対応できるようになります。
他にも
- オーディオデータの高速な読み込み方法と最適化
- vDSPでのダウンサンプリングやL/R channelのマージ
- 描画パスデータ(
Array<CGPoint>)をvDSPで高速生成 （これが一番驚きました) - GCDの落とし穴とその回避策
などどれも有用で、参加前は「4時間かぁ長いなぁ」と思っていましたが、実際にはあっという間に過ぎてしまいました。
これまでの経験上、オーデイオ波形の可視化はたびたびリクエストされる要件だったので、今回のWorkshopでパフォーマンス要件を含めて習得できたのはとてもありがたかったです。
講師の Andrew Coad さんとスタッフの方々、ありがとうございました！
クラウドネイティブなSwiftバックエンドを構築しよう
高島です。 私は今回、Kituraを使ってバックエンドサービスを立ち上げようという内容のワークショップに参加しました。
KituraはIBMが提供するSwiftを用いたWebサービスフレームワークです。 https://www.kitura.io/
ワークショップの流れは以下の通りです。
- Kituraサーバを立ち上げてみる
- OpenAPI, Origin Resource Sharing (CORS) に対応する
- POST, GET, DELETE, PATCHリクエストのハンドリングを実装する
- DataBaseと連携する（PostgreSQLを利用）
- Linuxコンテナにデプロイする（DockerのKubernetesサポートと Helmを利用）
これまでサーバーサイドの開発に携わることのなかった私ですが、
今回のワークショップでサーバーサイド開発のファーストステップを踏み出すことができました。
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の活用がさらに進むことを期待します。
さいごに
ヤプリではエンジニア向けカンファレンスに精力的にスポンサーとして参加しており、それらの有料のカンファレンスには業務の一環としてタダで参加することができます。 ご興味がある方は是非一度弊社に遊びにいらしてください！
Yappli Android Rejected Conf. MeetupでgRPC+ProtocolBuffersについて話ました！
こんにちは、株式会社ヤプリでAndroidエンジニアをしているdais-sasaです！
先日、弊社のMeetupでDroidKaigi2019でrejectされてしまったセッションを発表する機会があり、登壇してきました。
私以外にも外部から人を招いて登壇して頂き、惜しくもrejectされたセッションを聞く事ができました。
私は今回が人生初めての登壇で物凄い緊張しての発表だったのですが、面白かったと言ってくれる方がいたり、私の発表に興味を持って色々と質問をしてくれる方がいたりと楽しく、得難い経験ができました。
もっと登壇の経験を積み、ゆくゆくはDroidKaigiでも登壇したいと思いました。
今回のrejected confで、gRPC+ProtocolBuffersを開発で使ってみて感じた事や注意すべき事について発表しました。
その時に使用した資料を公開します。
JAWSDAYS2019 Open Micでヤプリのインフラ環境について話しました！
こんにちは、SREチームの ”はぶちん” こと羽渕です。
私は、2014年から毎年JAWSDAYSに参加しているのですが、今年はなんとスポンサーとして参加することができました。前職でも提案したことはあったのですが、結局できずじまいでしたので3年越しの願いが転職したらあっという間に叶いました(re:inventも入社半年で行けた)。
さらに、ありがたいことにJAWSDAYSとしてヤプリのサービスを使ってスタンプラリーを提供することができ、多くの方に自社のサービスに触れて頂くことができて感謝しています。自社プロダクトを世に広められる体験は本当に楽しいし、最高ですね。
で、今回はスポンサー向けのOpen Mic枠で「ヤプリの完全にモダンとは言いづらいけど、そこそこ攻めてるインフラ環境をもっと良くしたいエンジニアを募集しています。」というテーマで発表しましたので、資料を公開します。
続きを読む"チームの状況を見える化して自己組織化されたチームの作り方" と題して、登壇してきました。
皆さんこんばんは。Yappli,Incの梶原です。 先日、YappliのTech Meetupで登壇してきましたので、その資料を公開させていただきます。
登壇のテーマは、「チームの状況を見える化して自己組織化されたチームの作り方」でした。
私達は、とても複雑な制約の中でプロダクト開発をしています。 不確実性の高いソフトウェア開発において、自分の能力の範囲をカバーするためにチームで開発を行います。 そのチーム自身が、変化に対応しつつ、生き残れるための能力を身に付けることを自己組織的に行えることが強さの意味となってきました。自分たちの立ち位置を理解して、ステークホルダーからの期待に答える方法について紹介させていただきした。
自己組織化されたチームへのステップ
自己組織化されたチームでは、「自分たちで意思決定ができる。」、「衝突を内部で解決できる力を持つことができる。」特徴を持ちます。 そのため、信頼を得たチームは、自身の裁量で仕事をする領域が徐々に広がっていきます。主体的に仕事に関わる事ができると、自分事化が進んで、より仕事が楽しく感じるようになります。 そういった強いチームをいくつも作っていくことで、組織全体でチーム開発の力が増えて、プロダクトの成長に繋がっていくと考えています。
チームの状況を見える化して、自己組織化されたチーム作り
イベントの様子はこちらからも確認できます。 togetter.com
チームビルディングには正解が無い。
こんな感じに
DONEの定義、マネしよう。https://t.co/2GbqYPbHFO
— 星 永亮@ユアマイスターCTO (@inase17000) February 21, 2019
皆さんのチームでの強いチームづくりの参考になれば幸いです。
Developers Summit 2019に行ってきました！
ヤプリの渡辺です！
いやー、毎年こんなに人が来るなんて、みんなどんだけヒマやる気あるんだろ、とか思っちゃいますが、せっかく来たのでレポートとかしてみようと思います。
まずは個人的に面白かったのは、
アマゾン文化の成長へのループはとてもいい！
日本で、熱意のある社員は、6%しかいない
GoogleのSREの50%ルールやBurnout(燃え尽き症候群)の防止、ふりかえりが素晴らしい！
って辺りでした。 で、印象に残ったまとめは以下の通りですね。
続きを読む