Diverse developer blog

株式会社Diverse（ダイバース）　開発者ブログです。

iOS Test Night #10 で「iOSアプリのテストを書きたいのに書けないあなたへ」というタイトルで発表してきました

Swift

みなさん10連休はいかがお過ごしですか、iOSエンジニアの @imaizume です。

自分は技術書典 6で買い込んだ積読本にようやく目を通しています。

 

さて前回のOtemachi.swift #3に続き、4/16に株式会社DeNAさんで行われたiOS Test Night #10に登壇して参りました。

testnight.connpass.com

iOS Test Nightは今回が記念すべき第10回で、今回も主にiOSでのテスト手法やCI関連の発表がされていました。

ちなみに過去に行われた回では弊社の @kikuchy が登壇したこともあります。

developer.diverse-inc.com

そんな中今回、自分は初登壇のLT枠で「iOSアプリのテストを書きたいのに書けないあなたへ」という発表をさせていただきました。

speakerdeck.com

自分が入社以来携わり続けているPoiboyでは、恥ずかしながらつい最近までテストコードがほぼが存在しませんでした。

テストのメリットを感じつつも長い間導入できなかった要因はいくつかありますが、その一つに「iOSアプリのテストの書き方が分からない」というものがありました。

大学の授業や入社後の研修でテストの書き方自体は習っていましたが、それは題材のコードが明示的な入出力関係を持っていたためでした。

一方スライド内でも紹介している通り、iOSアプリのコードは必ずしも入出力が明確なものばかりではなく、テストを書こうと思ってもうまく書けず失敗を重ねていたのでした。

その後、明示的な入出力があって小さなコードを選んでテストを書き始めたところ、徐々にテストを書くことができるようになりました。

また実際のプロダクトで起こったことを例に、テストが書きにくそうなコードも書きやすいコードに変えていくための手法として、依存注入と抽象化、また設計を行う前段としてのモジュール分割も紹介させていただきました。

f:id:incheon-special:20190425205049j:plain

iOS Test Night #10 での発表の様子

今回は自分と同じようにテストをうまく書けないという方に向けて発表をいたしましたが、既にテストに慣れている方や他の登壇者からも、発表に対してのポジティブな感想をいただくことができました。

また発表中に紹介した「テストを書きやすいところから書く」という方針に対し、@kariad_uu さんからこのようなご意見もいただきました。

懇親会でもこのテーマでお話しさせていただき、やはりテスト経験のある開発者にとっては、簡単なテストは作業に近くなってしまいモチベーションも下がるという点には自分もまさに同意でした。

一方自分の場合は、iOSでのテスト経験が0でとりあえずの練習をしたかったこと、またチェックマークの数自体が増えることにモチベーションを持っていたこともあり、これまでは特にこの点を気にしていませんでした。

ただ今後は、実効性が高いロジックに有用なテストを書いていくということを意識して、よりレベルの高いテストを実践していきたいと思いました。

 

他の発表者で個人的に気になったのは @susieyy さんの「Snapshot Testing」でした。

Snapshot Image UI Testingというテスト手法は、目的の画面のスクリーンショットを撮影し実際の動作と差が出ていないことを確認するための手法で、スライドにもある通りレビュー負荷の軽減や画面カタログを容易に作成することができます。

またiOSSnapshotTestCaseというフレームワークにより、これをUITestではなくUnitTestのレイヤーで行うことができます。

github.com

自分のいるPoiboyでも、リリースごとにQA担当者に実機を使って表示上の不具合を発見してもらっていますが、デバイスも多様化も相まって負担が大きいことは紛れもない事実です。

そのため今後は同手法を活用してデバッグの高速化を目指したいなと思いました。

 

懇親会では他社でのテストにおける悩みや知見をお話したり、今回お話できなかった組織的な側面についての意見交換もさせていただくことができました。

また懇親会では珍しいカレーの提供がありました、大変美味しかったので自分は2杯もいただいてしまいました（笑）

 

このようにまだまだ発展途上な部分もありますが、Diverseではこうした新しい技術へのチャレンジもサポートしています!

ぜひ自分と同じくアプリのコード・設計改善に興味がある方は、お気軽に @imaizume までDMなりコメントなりをいただければと思います。

Otemachi.swift #03 にて「循環的複雑度を上げないためのSwiftプログラミングTips」という発表をしてきました

Swift

こんにちは、try! Swiftの参加者との飲み会で一番盛り上がったネタは最新のAndroid端末についてでした、iOSエンジニアの @imaizume です。

さて今回は4/10に日本経済新聞社さんで行われたOtemachi.swift #03での参加・登壇報告になります。

nikkei.connpass.com

Othemachi.swift は、その名の通り大手町近辺の企業で主催されている地域Swiftイベントです。

会場提供並びに主催は日本経済新聞社さん、ホールの壁には戦後の日経平均株価の推移が書かれていたりして、まさに日本を代表する新聞社という感じの会場でした!

今回のイベントで、自分は「循環的複雑度を上げないためのSwiftプログラミングTips」というタイトルの5分LTをさせていただきました。

speakerdeck.com

循環的複雑度は、プログラムの複雑さを定量的に表す指標の1つで、言語によらず条件分岐の数をベースとした数式で表すことができます。

過去に自分は会社で「プロダクトコードの循環的複雑度(CCN)を下げる」という個人目標を設定し取り組んだことがありましたが、その際単にif文を減らすだけではCCNを下げることができませんでした。

そこでいろいろと調べたり試行錯誤したりするうちに、抽象化やデータ構造の変更といった手段が必要であることがわかりました。

実際にCCNを計測することはなくても、コードの複雑性を減らすために使えるテクニックとして、明日からの開発に取り入れていただけるような内容にまとめられたのではないかな思いました。

f:id:incheon-special:20190425180829j:plain

Otemachi.swift #3 での登壇の様子

参加者の方からもTwitterや懇親会で多くの反応をいただき嬉しい限りです。

 

またこんなご感想もいただきました。

今回はCCNを下げることを目的とした書き方を紹介しましたが、実際はオーバーエンジニアリングとなりかえって可読性や利便性が下がる可能性もあります。

そのためご指摘の通り、自分も開発効率に影響をしない範囲で複雑性を下げていくことが大切だと思いました。

 

当日の発表は日経電子版アプリの広告流入計測にまつわるお話や、アプリ内課金に関する発表のほか、テストやSwiftlint、Firebaseから、さらにはSwift 5に関するトークなど多岐にわたりどれも大変面白いものばかりでした。

特に個人的にはTsukasa Komiyamaさんの「5分でわかるSwift 5のRaw Text」での内容が気になりました。

これまで文字列リテラルを生成する際にダブルクオート(")をエスケープしたい場合にはバックスラッシュ(\)を使う必要がありました。

Swift 5のRaw Textは、バックスラッシュの代わりにシャープ(#)を使うことができるという仕様です。

自分は過去にRubyで開発をしたときに%q記法のエスケープを使っていたので、この変更は個人的にはかなり嬉しいと思いました。

発表でもあった通り、メタプログラミングやjson、xmlをStringとして直書きする場合などには特に有効な方法だと自分も思いました。

 

併設のカフェスペースで行われた懇親会でも来場した開発者の方々と発表や開発について意見交換をすることができ、大変有意義な会となりました。

今後も開発で得られた知見を積極的に外へ公開していきたいと思います。

ぜひ今回の発表やそれ以外でも何か気になったことがあれば、お気軽に @imaizume までコメントを頂ければと思います!

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

Swift

どうもこんにちは、冬場は隣駅の銭湯まで毎日通っている @imaizume です。
都内だと深夜まで営業している店も多く、たった460円でリラックスできるのでリフレッシュにオススメです。

f:id:incheon-special:20190424191556j:plain

try! Swift Tokyo 2019の会場にて

遅くなってしまいましたが、3/21から3/23にかけてベルサール渋谷にて行われた try! Swift Tokyo 2019 へ参加してきましたので、今回はそのレポート記事になります。

try! Swift 概要

www.tryswift.co

try! Swiftは、Swiftに関するさまざまな技術発表が行われる国際的なカンファレンスで、過去にはアメリカのニューヨークやインドのバンガロールでも行われています。

今回はなんと、30カ国から900名以上が集まっていて、実際に自分が会場を見渡した時も約半分が外国からの参加者だったように見えました。

3日間の会期のうち、1日と2日目がセッションとブース展示、3日目がワークショップとピアラボという構成になっています。

また2日目の終了後には懇親会が行われますが、英語での会話があちこちから聞こえてくるというそんなイベントでした。

セッション (1日目 2日目)

セッションでは、Swiftの言語そのものにまつわる話からiOSやmacOS、テスト、サーバーサイド、IoT、さらには波形編集といったテーマまで、幅広い発表がされていました。

普段の業務で扱う機会がない技術の話も含めどれも非常に面白い発表でした。

今回はその中でも個人的に特に気になったものを3つピックアップしたいと思います。

1. Introduction to Swift Keypaths (@terhechte さん)

speakerdeck.com

Swift 4.0からKVOの書き方が新しくなり、KeyPathをより簡単かつ直感的に生成できるようになりました。

しかし自分もまだあまり使う機会がなく知識を整理できていなかったため、この発表で改めてSwift 4以降のKVOの仕組みや活用法を知ることができました。

またProtocolでは実現できない高レベルな抽象化を例に説明してくださったので、この手法はプロダクトでもぜひ取り入れたいなと思いました!

2. テストケースでMemory Leakを発見する (@tarunon さん)

www.icloud.com

 

こちらはSwiftで起こりがちな循環参照の問題を、コードレビューやメモリデバッガーではなくテストケースにより発見・修正する試みについての発表。

Swiftにはオブジェクト自身の状態を取得するために、Mirrorと呼ばれるAPIがついており、このMirror APIを利用して循環参照の可能性がある場所を検知しweakを挿入するXCTAssertNoLeakというライブラリを作成されたそうです。

自分の普段の開発でも現状はコードレビューに頼っているので、早くSwift 5にアップデートしてこちらのライブラリを試してみたいと思いました!

SwiftCheckで始めるProperty-based Testing (@tobi462 さん)

speakerdeck.com

一般的なテストで用いられる境界値分析では、テストを設計するエンジニアが仕様上検証が必要そうな値を考えて入力と期待値を設定します。
一方プロパティベーステストは、テスト対象の特性に着目しランダムにテストケースを生成するという手法で、これを簡単に導入できるSwiftCheckの紹介もされていました。
自分のプロダクトでも場所によってはこの手法が試せるのではと思い、現在プロダクトに実践導入を行っているところです、大変参考になりました!

ワークショップ (Testing & Performance) とピアラボ (3日目)

f:id:incheon-special:20190424191603j:plain

ピアラボでの講義の様子

3日目は会場を変えてワークショップとピアラボが開催されました。

午前のワークショップはいくつかのテーマごとに講師の方を囲みながら課題をこなしたり相談をするという内容です。

自分はプロダクト開発での直近の関心であるTesting & Performanceのワークショップに参加しました!

最初に講師の @samuelgoodwin さんからInstrumentsのTime ProfilerとNetworkについての説明を受けた後、質問をしながら各自が持参したコードを改善してきます。

自分は現在のプロダクトのコードで起動時間の改善を行いたかったため、初めてのTime Profilerを触りながら時間の掛かりそうな処理を探しました。

するとなんと、APIコール時にパフォーマンスを大きく下げるコードを発見することができました。

そして最終的には、改善により1リクエストあたり数百ミリ秒の短縮につなげることができました!

やはり実際に手を動かして新しい技術を身につけたりレビューをしてもらえるのは、ワークショップの醍醐味と言えるのではないでしょうか。

そして午後のピアラボは、各自が好きな作業をしたり参加者と交流したりする時間です。

3日目にもなると心身ともに疲れてはいたものの、非常に大きな充実感を得ることができ、次回のtry! Swiftへの参加意欲を大きく掻き立てられました。

参加者との交流

f:id:incheon-special:20190424191606j:plain

毎年恒例の畳スペースが今年も人気でした

国際カンファレンスであるtry! Swiftは、普段会えない海外のエンジニアと話せる絶好の機会です。

自分もランチや懇親会、さらにはイベント後のプライベートな飲み会にまでお邪魔し、たくさんの海外エンジニアさんと話すことができました!

ランチに出会ったとあるエンジニアさんとは、アプリの各設計思想に対するお互いの考えや少人数チームでのスキルアップ方法について議論しました。

また懇親会ではカザフスタンから来たというエンジニアさんに話を聞くことができ、日本と違って国内にまだデベロッパーが少なく情報を仕入れるのが大変だという話をしました。
このようにエンジニアが考えたり悩んでいることは万国共通なんだなと思いながら、同時に日本は情報にもモノにも恵まれていてありがたいなと改めて実感しました。

また参加者専用のSlackが用意されており、イベントの終了後も活発な交流がされているのが印象的でした。

自分もたまたまイベント後に打ち上げをしてところにお邪魔し、イベント外でも大変楽しい時間を過ごせたのが良かったです。

全体を通じた印象や感想

iOS以外の分野でのSwiftが広がっている

昨年あたりからサーバーサイドSwiftの話を少し聞いてはいたのですが、今回はそれ以外の分野でのSwiftの利用例の発表が目立ちました。
個人的にはあまり追っていなかった情報なので、今年は少し注目していきたいと思いました。

ノベルティが豪華

f:id:incheon-special:20190424191600j:plain

豪華なノベルティグッズ

try! Swiftのノベルティも各社デザイン性や機能性の高いものばかりでした。
中でも今回一番の目玉はBitriseさんのブースで先着で配られていたオリジナルのポスター!

ちょうどプロダクトのBitriseで困った点があり初日すぐに質問に行ったため運良くGETすることができました!!

try! Swift公式キャラクターのrikoちゃんがプリントされたトートバッグもかわいいですね、さっそく普段遣いしてます。

まとめ

ということで今回、自分は初めてtry! Swiftに参加してきましたが、予想以上に濃い時間を過ごすことができました。

明日からの業務で活かせる内容もたくさん聞けたので、ぜひ次は発表者としての参加を頑張りたい所存です!

またDiverseでは、try! Swiftをはじめとした技術カンファレンスへの参加・登壇を推奨しており、参加費も補助してもらえる制度があります

こうした社外活動にも興味を持たれた方はぜひ自分またはお近くの社員へお気軽にお声がけいただければと思います。

 

新オフィスで初のエンジニア向けイベントとなる『ROPPONGI.swift #7』 を開催しました

こんにちは、先日レーシック手術を受けて視界が大変良好な @imaizume です。

間違いなく人生変わるのでおすすめです（笑）

 

さて3月7日に、新オフィスで初のエンジニア向けイベントとなるROPPONGI.swift #7を開催しました!!

roppongi-swift.connpass.com

ROPPONGI.swift は主に六本木周辺にある企業さんで行われる、Swiftの地域勉強会&コミュニティです。

Diverseのオフィスは溜池山王にあるため六本木からは少し離れていたのですが、主催者の方たちに快諾いただけたため無事開催の運びとなりました。

また同月21日に開催されたtry! Swift Tokyo 2019のプレイベントとしても登録していたただき、同イベントに参加・登壇される方とのトークも楽しむことができました。

 

f:id:incheon-special:20190327153945j:plain

当日の発表様子

 

ドリンクを片手に和やかな雰囲気で始まった本イベント。

最初のトークは @alligator_tama さんの「XCUITestにおける状態制御について考える」。

speakerdeck.com

 

XCUITestでの状態制御を、起動時だけでなくテスト中に動的に与える仕組みをDarwin notificationsを使って実装されたお話でした。

Watch開発なども経験がない自分にとって、Darwin Notification自体の仕様はもちろんアプリ間での通知の送信ができるというのも初耳だったので、大変興味深かったです。

 

次に、私 @imaizume が「シングルトンではじめる状態管理と依存注入」というタイトルで発表させていただきました。

 

speakerdeck.com

 

アプリの設計がしっかりとしてない状況で、内部状態管理が煩雑になった場合に、一時的にシングルトンパターンで状態を集約するというテクニックを紹介しました。

もちろん最終的にはFluxなどの設計レベルで解決することが望ましいですが、それができないケースではまず管理を一元化し依存注入できるようにすることである程度シンプルな形に実装できるのではないかと思います。

 

続いて3番目の発表は @ushisantoasobu さんの「24時間でMacアプリを作ってスベってきた話」でした。

speakerdeck.com

Japan Hack Day 2018 に参加した際に開発された、macのカメラを用いた居眠り検知アプリに関するお話で、ライブデモでアプリの動く様子も見せていただきました。

Vision FrameworkとFirebaseを使って、iOSとは大きく異なる作法やFirebase側APIの対応状況などと格闘した話は、普段iOSメインで開発している方にとってなかなか経験することのない貴重なお話でした。

 

4番目の発表は @hatakenokakashi さんの「Introduction Fluid Interface」でした。

speakerdeck.com

 

2018年のWWDCにてAppleが提唱した "Fluid Interface" について、ハーフモーダルUIを例に大変分かりやすく解説していただきました。

@hatakenokakashi さんはPEAKSで販売中の iOS 12 Programming での執筆に加え、4月の技術書典でもFluid Interfaceに関する書籍を出されるとのことですので、ぜひ皆さんもチェックしてみてください!

 

そして最後の発表は、try! Swift Tokyo 2019でも登壇された @izm256 さんによる「レイアウト実装方法の比較ポイント」でした。

speakerdeck.com

レイアウトをStoryboardでやるか、Xibでやるか、それともコードでやるかについては、iOSエンジニアにとっての永遠の問題の一つであるかと思います。

初期化の仕方や再利用性、チーム開発のしやすさといった様々な観点で実装方法を比較されていて大変分かりやすかったです、さらにプロダクションでは現在全ての方法を混在させているという点も驚きでした。

設計やテスト、UI、Macアプリなどトークのテーマも様々で、どの発表も大変有意義で参考になるものばかりでした。

発表後は懇親会に加えて、Diverseの新オフィスを見学する社内ツアーも開催いたしましたが、参加者の方からはお昼寝スペースやOKRスペース、窓から見える景色といった点に大変好評をいただくことができました!!

今後もDiverseでは様々なイベントを開催していくほか、オフィスツアーも継続して行っていきたいと思いますので、ぜひ公式TwitterやFacebookのフォローをよろしくお願いします!

 

直近でオフィスツアーが行われるイベントとして、4月24日にMatching Dev Meetup #3のDiverseでの開催が決定しています!

matching-dev-group.connpass.com

Matching Dev Meetupは主にマッチング業界のエンジニア・デザイナーによる勉強会&交流イベントで、今回はデザイナーによる発表がメインとなります。

もちろんマッチング以外の業界の方も大歓迎ですし、普段聞けないプロダク制作の裏話なども聞けるチャンスですのでぜひ上記のconnpassページからお申し込みください!!

 

またイベント時以外でも @imaizume をはじめDiverse社員にお声がけいただければご案内いたしますので、みなさんぜひぜひきれいになったDiverseオフィスに遊びに来てくださいね!

f:id:incheon-special:20190327153525j:plain

ご来場いただきありがとうございました!!

弊社エンジニア3人がDroidKaigi 2019に登壇しました

DroidKaigi 終わりましたね。id:kikuchy です。

DiverseからはDroidKaigi 2019にゴールドスポンサーとして協賛すると共に、3人のエンジニアが登壇いたしました。

f:id:kikuchy:20190212201915j:plain
Diverseはスポンサーブースを出しました

登壇者から

PWAでここまでできる（@SAMUKEI）

youbrideでは、AndroidリプレースでFlutterを採択しましたが、PWAもその中の候補として存在していました。
その際に調査したPWAの話はしたいなと思っていたのですが、DroidKaigiのような大きな場で発表するとは・・・と今でも思っています。
聴いていただいた方の少しでも役に立ちましたでしょうか？(役に立ったと思っていただければ凄く嬉しいので、ツイートとかガンガンしてください！)

また、上の動画を見ていただければわかると思いますが、PWA自体は既存の技術の組み合わせで提供するものです。
怖がらずに、ホーム画面からのインストールの機能をはじめの一歩として試してみてください！


All About Test of Flutter（id:kikuchy）

「Flutterでテストを扱ったセッションなら競合は少ないだろう」という比較的安直な考えと、『Androidテスト全書』を執筆した経験からテストに関する見識を更に広められたので、何かしらFlutter開発をする方々に対して役に立てるセッションができるかなという考えからこのテーマになりました。

スライドを作っていると
「これを説明するには、あれも事前に説明しておかないといけないのでは？」
「ライブラリの使い方のようにすぐ陳腐化する内容ではなく、もっと抽象度が高いことを話した方が良いのでは？」
という考えがふつふつと浮かび、気づけばスライドの枚数が130枚を超える事態になってしまいました。

結果としては「読めばわかる部分は発表では使用せず、途中で聴いてくださる方にご意見を頂いて真の意味で『セッション』にしよう」ということで、後半については読み上げておりません。
実際にどんな『セッション』に仕上がったかは、上の動画を見ていただければと思います。

セッション中にめくらなかった後半のスライドについては、資料を御覧ください。

docs.google.com

実践Lottie（id:kumanomi）

Poiboyというサービスで年末年始CPをLottieで実装しました。
その際に得た知見の話をDroidKaigiですることができ非常に良い経験になりました。
デザイナー視点でのお話が結構あり、技術に関してはあまり触れてはいませんが興味がありましたら視聴していただけると嬉しいです。

Lottieでのアニメーション実装は非常に簡単できます！
ぜひアニメーションをlottiefiles.comからダウンロードしてお試しください！

スポンサーとして

Podcast公開収録

DroidKaigi 2019はDiverseが初めて単独で協賛するエンジニアイベントでした。

（正確には株式会社ミクシィ時代にも協賛してはおりましたが、株式会社IBJ傘下に入ってからのDiverse単独での協賛は初です）

社内にノウハウはほとんどなく、何をゴールとするか、スポンサーブースで何を行うのか、そのために何をしたら良いのかも完全に手探りの状況でのスタートです。

社内のエンジニア数人で案出しをした結果、「Podcastの公開収録を行う」というアイデアが出ました。

弊社は広報施策の一環としてPodcastを配信していますので、日本のAndroid業界の著名人が集まるこのイベントでゲストを招いて公開収録ができないか…
そうすれば耳目を集めてDiverseの名前を覚えてもらえるだけでなく、企業とエンジニアコミュニティがどのように付き合っていけば良い関係を築けるのかのヒントを聞いてくださったみんなで考えるきっかけになるし…
ということなのですが、問題はそんな著名な方にお越しいただけるのかどうか、というところ。

なんと

実現してしまいました！！！




Flutter JP オーガナイザーである@rkowaseさん、そしてDroidKaigiのオーガナイザーである@mhidakaさんという、ビッグネームのお二人を招いての公開収録です。
お話いただくことを引き受けてくださったお二方には感謝しかありません。

おかげさまでこんなことが聞けました。どちらの回も非常に興味深く、楽しい回になりました！

  • 『FlutterKaigi』は開催されるのか？（rkowaseさんの回）
  • DroidKaigiの受付 効率化の歴史（mhidakaさんの回）

収録した音声は軽い編集を施した後、Diverse Podcastのサイトで配信します。
RSSを購読していただき、更新をお待ち下さい！

podcast.diverse-inc.com

誤発注事件

DroidKaigi開催前のポストにも記載しました通り、id:kikuchyがノベルティを誤発注しました。

会場でも話題にしていただきまして、ありがたい限りです。

300個もの誤発注コネクタでしたが、無事に貰い手が見つかりました！

話題にしてくださったみなさま、手にとってくださったみなさま、どうもありがとうございました！

もう誤発注はしません！！！

Diverseは今後も、カンファレンス/コミュニティに対する貢献や支援を続けていきます。
また、技術的なアウトプットを行うクリエイターの後押しをしてゆきます。

今後もDiverseにご注目ください！

DiverseはDroidKaigi 2019にゴールドスポンサーとして協賛します

広報の大和です。

Androidエンジニアの祭典、DroidKaigiがいよいよ目前に差し迫ってきました。
DiverseではDroidKaigiにゴールドスポンサーとして協賛しています。
また、弊社エンジニア3名が登壇します！

今回は、DroidKaigi目前に弊社Diverseがどんなことを行うのかご紹介させていただきます！

Diverse単体としてゴールドスポンサーに初めて協賛させていただきます。
スポンサー特典として、当日Diverseロゴのはいったお菓子が配られます。
おかしを目にしてDiverseを思い出した方は、ブースまでお越しいただけますとうれしいです^^

ブース

当日はブースをだしますので、ぜひ足を運んでいただけると嬉しいです。
コンテンツやノベルティーをご用意しております。
また、ノベルティー以外でも同人誌やAndroidテスト全書など、弊社エンジニアの本を置いてますので、ご自由にご覧ください。

Podcast公開収録

Podcast収録に臨むimaizumeさん

Diverseでは、ランチ時間を利用してPodcastを公開収録します。
ゲストは、DroidKaigi責任者の日高さん、Flutter Meetup Organizerの小和瀬さんをそれぞれにお招きし、楽しくトークさせていただきます。

1日目

時間：12:20~
ゲスト：Rui Kowase
内容：Flutter MeetUp Tokyo主催の経緯
　　　Flutterアプリとandroidネイティブアプリの今後の関係
　　　　ぶっちゃけFlutterkaigiやるんですか？　など
twitter.com

2日目

時間：12:20~
ゲスト：mhidaka
内容：今年のDroidkaigiの傾向
　　　DroidKaigiの企業ブースについて
　　　DroidKaigi/技術書典の運営のやりがいと困難　など
twitter.com


公開URL：https://podcast.diverse-inc.com/
podcast.diverse-inc.com

ノベルティー

DiverseロゴがまぶしいUSB-A → microUSBコネクタ

USB-A → microUSBコネクタを配布いたします。
実はこれ、誤発注で、当初はUSB-A → USB-Cコネクタをご用意する予定でしたが、、
弊社エンジニアの id:kikuchy の誤発注によりUSB-A → microUSBコネクタが大量に届きましたｗｗｗ
ぜひ皆様に減らすご協力をお願い申し上げます。

誤発注により大量に届いたmicroUSBコネクタを前に途方に暮れるkikuchy

（追記：id:kikuchy
冗談ではなく本当に誤発注したので、ぜひ持っていってください…！
タッチスクリーンが壊れたAndroidに繋げば、キーボードやマウスを接続してファイル救出などに使用できます。緊急時に備えて持っておきましょう！）

登壇者

弊社から3名がセッション採択され、登壇いたします！

id:samukei
登壇時間：7日(木)14:00　ROOM１　
発表タイトル：PWAでここまで出来る
意気込み：
PWAはWebアプリの開発者がスマートフォンアプリケーションも開発できるという可能性を秘めた技術です。
PWAを知らない方には知ってもらうきっかけに、PWAを知っている人にもこんなことまでできるアプリケーションを作れるんだ！
と感じてもらえるようなセッションにしたいと思っています！
droidkaigi.jp



id:kikuchy
登壇時間：8日(金)12:50　ROOM6
発表タイトル：All About Test of Flutter
意気込み：
Flutterアプリ開発で必要になるであろう自動テストの始め方をお話します。
にわかによく名前を聞くようになったFlutter。
業務でも使用される例もちらほらと聞こえるようになり、普及してきた様子が伺えます。
しかし、テストは書かれているでしょうか？
また、Flutterアプリケーションに対するテストの知見は一般化されているでしょうか？
私のセッションの内容だけで自動テストを書き始められるようになっていただくのを目標にお話をしたいと思います。
droidkaigi.jp


id:kmnmn
登壇時間：8日(金)14:00　ROOM6
発表タイトル：実践Lottie
意気込み：
私が担当しているプロダクト Poiboy にて実際にLottieを使って得たメリットやデメリット、デザイナーさんとのやりとりなども含めて共有できたらと思います。
droidkaigi.jp



Diverseのエンジニア三人が登壇します

是非、弊社ブースまでお越しください♪
楽しみにしております^^

Diverseが健全な開発を行える組織を目指すために

Diverseでかいはつ室の室長をしているnogです。

Diverse Advent Calenderの15日目です。

Diverseの開発全体として現在目指している方向性について書かせていただきます。

 

 

 

私は事業としてサービス運営を行っている会社に置いてエンジニアがやるべき開発というのは大きく3つに分かれると考えています。 

1.サービスのための開発(ユーザーに刺さるコンセプトや時代に求められている要素を伸ばすための開発)
2.サービスを事業として成長させていくための開発
3.サービスを持続的に運営していくための開発

の3つです。

 

新規のサービス等に置いては1か2のどちらかへの比重をほぼ100%に置いての開発も非常に有効です。一定のステージに上がるまでそこへの比重を非常に大きくしなければ生き残ることは非常に難しいと思っています。

 

しかし一定期間以上の運用を行っていくサービスはこの3つのバランスを取って開発を行っていくことが非常に重要だと考えています。

 

これまでDiverseでこの3つのバランスを適切にとれていたかというと、正直なところそういう状態ではありませんでした。1もしくは2のどちらかへの比重を非常に高くし、残った2つに対してはほとんど力を割けない。といった状況が長く続いていました。

 

Diverseでは特にYYC,youbride,Poiboyという3つのサービスに力をいれて開発を行っていますが、

このうちYYC, youbrideに関しては累計運用年数が15年を超えるサービスになっています。

長期運用を行っているサービスにおいて3を軽視することの危険性はエンジニアの皆さんなら簡単に想像が出来ると思います。

 

今Diverseにいる私の役割はこの1,2,3のバランスを取れる状態を作っていくことだと考えていて、特に3に対する割合を増やしていくことに関しては急務だと考えています。

そこで現在各事業部のエンジニアと協力して各事業部に対して横串で

・ビジネス側のメンバーへの技術的負債を軽減することの重要性の啓蒙や実際の改善作業のサポート

・上手くメンテナンスが出来ていない社内ソフトウェアの切り捨て

・クラウド移行のメリットや移行時にかかるコスト等をまとめ事業の計画に盛り込み、実際に移行作業を進める

・新規に利用する技術の検証や実験

・開発環境の構築

・監視環境の整備

等の少人数の開発チームの中で行いにくいけどやっていかなければいけないことを行なっています。
この結果サービスがより成長出来るような状態を作っていけると信じております。

 

技術的なハードルもなかなか高い仕事ではあるのですが、Diverseではこういった仕事に魅力を感じる！といったエンジニアの方を募集しています！

募集ポジション / 株式会社Diverse