Diverse developer blog

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

GDG DevFest 2018 Tokyoで、FlutterをKotlinで書きたいという気持ちのあらわれをお話しました

Flutter Meetupで登壇したその週末にもGDGに登壇しました id:kikuchy です。
準備が大変すぎて大変でした。


GDG DevFest Tokyoは、Google関連のテクノロジを扱ったコミュニティが集まって開催されているカンファレンスです。
毎年開催されており、私は昨年に続き2回目の登壇となりました。
推薦してくださったShibuya.apkのみなさま、ありがとうございます!


https://tokyo2018.gdgjapan.org/tokyo2018.gdgjapan.org



今年は30分の発表枠をいただき、『KotlinでFlutterを書きたい』というタイトルでお話しました。

docs.google.com

現在、私が開発に携わっているyoubrideという婚活サービスでは、クライアント開発にFlutterを採用することが決まっています
が、Flutterの開発言語はDartです。
Kotlinに慣れたAndroidエンジニアの方には少々言語機能が物足りないのではないでしょうか。

私もDartの言語機能に物足りなさを感じたりストレスを感じたりしたので、FlutterをKotlinで開発できないかを検討しました。
その結果がこちらのスライドになります。


現状、KotlinでFlutter開発をするために考えられる手段がいくつかあり、そしてそれぞれに高いハードルがあります。
今の私の知識とスキルではそのハードルを簡単には乗り越えられずまだまだ研究が必要そうでした。
現状、わかっていることを公開して、同じ志の人を増やせないか、というのが、このスライドのテーマでした。


Ask the Speakersのコーナーにもたくさんの方に来ていただけまして、
Kotlin on Flutterの実現に関する議論をする事ができました。

一番有力なのは、やはりFFI経由でDartのライブラリをKotlinから使用することでした。
現状のFlutterではDartランタイムから直接FFIを使用することができませんが、もしかしたら可能にする方法があるのではないか、また、需要を説明してFlutter開発陣に機能を追加してもらうことはできないだろうか、というご意見をいただきました。

また、この手の話題は英語でも公開することを勧めていただきました。
Flutter開発に関わるGooglerの方々は結構Mediumを見ていることが多く、簡単にでも書けば反響があるのでは、ということです。
時間を見つけて、Mediumでも発信していきたいところです。


Flutterでマッチングアプリの開発をしてみたい方は @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!
まずはご一緒にご飯を食べにいきましょう!!

Flutter Meetup #4をホストしました&発表しました

Flutter Meetup #4のホストをしました、 id:kikuchy です。

Flutter Meetupは比較的新しい、マルチプラットフォームフレームワークFlutterの勉強会です。
第4回目になる今回も、Flutter開発スキルを更に向上できるような充実した内容でした。

flutter-jp.connpass.com



発表については、Flutterをプロダクション導入するに至った経緯とその過程で検討したことなどをお話させていただきました。

docs.google.com

弊社のオンライン婚活サービスyoubrideでは、現在Androidクライアントの改修が計画されています。
そこにチームが現在抱える問題も一緒に解決すべく、Flutterの導入が検討され、本決まりになった、というお話です。

人的リソースはそうそう簡単に確保できるものではありません。
ただ、今いる開発メンバーにスキルがあれば、マルチプラットフォームフレームワークを使う、という選択肢を取ることも可能です。

この選択がどうなるか、究極的なところはわかりません。
もしかすると、将来的にFlutterが流行らなくなってメンテナンスコストや採用コストが高く付くことになるかもしれませんし、そもそもプラットフォーム依存の機能を要求されることが多くなって狙い通りに開発・保守コストを下げることができないかもしれません。

それでも今は、Flutterの未来を信じて、改修を進めたいと思います。
結果がどうなるかは、今後もこのブログをご覧になってお確かめください 😉



開催について。

実はrkowaseさんからFlutterのMeetupを開催したいというお話を伺ってからしばらく経ってからの開催でした。
「しばらく経って」というのが重要です。
なぜなら、そのしばらくの内に親会社がミクシィからIBJに変わってしまったからです!!!

そのためイベントの開催ではいろいろな困難がありました。
困難の一例は、こんなツイートに現れてしまっています。


困難にお付き合いくださいましたミクシィ関係者の皆様、弊社Diverseのお手伝いいただきました皆様、この場を借りてお礼申し上げます。🙇


Flutterでマッチングアプリの開発をしてみたい方は @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!
まずはご一緒にご飯を食べにいきましょう!!

ROPPONGI.swift #5 にて標準ライブラリだけでスロットゲームを実装した話をしました

こんにちは、完全食COMPを始めてもうすぐ1周年、PoiboyグループiOSエンジニアの @imaizume です。

先日VISITS Technologies株式会社さんにて行われたROPPONGI.swift #5にて、半年ぶりの勉強会登壇をさせていただきました。

visits.connpass.com

 

今回の発表内容は今夏Poiboy内のキャンペーンで表示したスロットゲームの実装についての話になります。

speakerdeck.com


スロットゲームといえば、回転する複数(通常は3つ)のドラムロールが横に並び、ボタンを押して絵柄を止めるゲームのことです。
アプリの画面内で現実世界と同じスロットゲームのUIを実装するとなると様々な要件が発生します。
例えば無限スクロールや中心線での停止、回転速度の調整などです。

様々な実装方法が考えられた中で、自分は最終的にほぼUIScrollviewのみで実装しました。
その詳細についてはSlideShareの方をご覧いただきたいのですが、
無限スクロールは同じリール(絵柄の並びのパターン)を複数用意することで瞬間的にスクロール位置を戻して実現したり、回転速度についてはsetContentOffsetをよしなに設定することで安定した速度を実現しました。

また最終的には、UIScrollViewを継承したクラスを定義しUI更新の処理をカプセル化することで、意外にもシンプルに実装をまとめることができました。
なお発表タイトルに「ほぼ」とあるのは、3つある全てのドラムロールの停止を待って同期的に次のアクションを呼び出す必要があったことから、この部分だけPromiseKitに依存しているためでした。
しかしその結果としてリールや回転数等をパラメータで与えるだけで思った通りの動きを実現でき、理論上何個でもドラムロールを増やすことができる実装となっています。

そのため現在、この実装をライブラリ化して外部に配布することも検討しています。
なお今回の実装はゲームを開始する時点で停止位置やアタリ判定結果は決まっている前提のため、実際のユーザーのアクションで回転を止めるのにどう対応するのかが課題となっています。

スロットゲームを行った結果、キャンペーン期間中はトラブルもなく無事に終了し、ユーザーのアプリ内でのアクションを増加させることにも成功しました。
また今回の実装は時間こそかかったものの、チームメンバーの応援のもと様々な実装にトライできた結果でもあります。

自分の所属するPoiboyに限らず、Diverseには仲間のチャレンジを応援し良いプロダクトを作っていく土壌があります。
そんな組織やチームに興味を持った方は一度お話ししてみませんか?
ぜひ私 @imaizume はじめ、弊社エンジニアへぜひお気軽にご連絡いただければと思います。

 

Shibuya.apkで地獄が生まれて縮小するまでの話をしてきました

本職はFF14でララフェル族の光の戦士(白魔道士)をやっているYoshihisaです。

先日開催されたShibuya.apk#26にて、『Android Architecture Components(AAC)を使ってリファクタリングした話』と題して泥臭く地道にリファクタリングしていった話をさせていただきました。

shibuya-apk.connpass.com

speakerdeck.com

P.4からP.11ではそこはかとなくやばい香りがするだけでまだマシだったActivityが度重なる機能追加などにより地獄へと変貌していく様子が手に取るようにわかると評判(?)でした。

この地獄を縮小すべく取った手段がAAC ViewModel(VM) + LiveData でした。
AAC VMとLiveDataでステートマシンを実装しActivityと各Fragmentでロジックと状態を共有、表示状態の決定をそれぞれで行うようにすることでFat Activityから脱却しました。
またリファクタリングの大事なポイントも合わせて紹介しました。

最後に会場で質問をいただいたのでその内容と回答を書いておきます。

Q. この作業にかかった時間は?

A. 最後に入れた送信機構以外の部分も含めて実作業時間は1週間程度です。(実際はQA等でリリースまでにはさらにもう1週間ほどかかっています)
送信機構とプロフィールやメッセージ履歴を取得する機構は独立していてロジックは単純だったこと、コールバックを追いかけるのに時間がかかった程度です。

Q. JavaをKotlinに書き直すことと、このようなリファクタリングどっちを優先する?

A. リファクタリング優先です。書き直すにも責務を抱えすぎているものをそのまま書き直すには高コストですので…まずはダイエットして責務を適切に分割してスッキリさせてから書き直す作業に入れば安全に進められるでしょう。またJavaで書かれているものを必ずしもKotlinで書き直す必要はないので「気が向いたら」で良いと個人的には考えています。


はじめて(少し早めに終わりましたが)15分話したので発表寸前まで緊張で胃が痛くなっていました。

また「こんな話してもウケんのかなぁ」と心配でしたが終わってみると皆様同じような悩みを抱えているようで少しはお役に立てている様子で安心しました。

資料を共有したツイートには過去最高の「いいね」をいただきました!ありがとうございます!

 

弊社に興味を持っていただいた方は、@bomneko_attackまたは他の弊社エンジニアへお気軽にDMやリプライをください!

Android Test Night #4で『Androidテスト全書』の内容についてお話しました

『Androidテスト全書』を執筆中の id:kikuchy です。

執筆の近況報告として、Android Test Night #4 にて執筆陣のトークに参加させていただきました。
testnight.connpass.com

ファシリテーターを務めてくださったながのさんからの質問と、それに対する私の答えはだいたい以下の通りでした。
当日の参加者のみなさまのツイートと合わせてお届けします。

Q1 どんな感じになりそうですか?

JUnit 5の章を担当しています。
後述しますが苦労しているところがあるので、このままでは「JUnit 5にはこんな便利な機能があるけれどAndroidでは使えないよ」という内容になりそうですこし苦しいです。


思い描いたことを書き出すのは良いのですが、それが本当にそうだったか、自分の理解や記憶が正しいか、の裏取りですごく時間がかかっています。
JUnit 5や、それを使えるようにするGradleプラグインのソースまで見に行ったりしています。
公式のユーザーマニュアルには載っていない機能が隠れたりしていて、そういうのを見つけると楽しいです。

Q2 進捗どうですか?苦労しているところは?

文章は書きたいことの6-7割が書けている段階です。
このままいけば多分なんとか締切には間に合うんじゃないかと…

苦労は多く、先程の通り、Android実機ではJUnit 5が動作してくれないのが一番つらいです。
AndroidではAndroidのランタイムでJavaのコードを動かすために、Java8の言語機能を使用したclassファイルにdesuagrというプロセスを通してJava7相当のclassファイルを生成し、それをdexに変換しています。
JUnit 5はどうやらJava9の機能を使っているらしくdesugarでコケるためInstrumented Testで使用できないようです…

また、紹介しているGradleプラグインのandroid-junit5にバグがあって、JUnit 5の新機能であるTagを使った実行するテストケースの制御がうまく行かず、修正を依頼するissueを立てたりしていました

Q3 会場の方からのご質問(のうちkikuchyがお答えしたもの)

UIテストをすばやくうまく行かせるにはどうしたらよいか

無理に自動化しないほうが良いかなと…
ほかの登壇者の方々がおっしゃっていた通り、当然画面が変わると改修が必要になりますからメンテナンスコストが高いですし、実装が大変なので。
UIテストでの「期待通りに動作している」というアサーションには暗黙的に「この部分の色が指定どおりであること」「文字が見切れていないこと」などコードに落とすときに面倒くさかったり曖昧だったりすることが求められたりしていてコードに落とすのも大変です。
が、人間はそうしたファジーなものも受理できてかつ適格であるという判断までできてしまうので、アルバイトなど雇ってテストを頑張ってもらう、というのは十分ありだと思いますし、自動テストを整備するのにエンジニアのコストを掛けるより安く上がることもあると思います。


著者陣の受け答え総まとめは id:t-miliya612 さんのまとめブログを御覧ください!



奇しくもこの日は弊社のPodcastを始動した日でもありました。

podcast.diverse-inc.com

こちらについても会場で前向きな感想をいただけてすごく嬉しかったです!

今後もスピーカーを増やしながら、弊社Diverse(ダイバース)の内情をお伝えしていきたいと思います。
ぜひお聞きください&ご購読ください!✧\\ ٩( 'ω' )و //✧

弊社に興味を持ってくださった方は @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!
まずはご一緒にご飯を食べにいきましょう!!

Shibuya.aab #25でGoogle I/O 2018の報告をしてきました

初めてGoogle I/Oの申込みを忘れなかったのでI/Oに行くことができました、 id:kikuchy です。
Google I/O 2018に参加して得られたものを公表すべく、shibuya.aab で報告させていただきました。

shibuya-apk.connpass.com

なんと今回は shibuya.apk ではなくshibuya.aab!
今回のI/Oで発表されたAndroid App Bundleのaabですね!
が、運営の都合上面倒くさいためかaabは今回限りでdeprecatedだそうです。

毎年Google I/O直後はI/O報告会の回となっておりまして、今回は私も登壇させていただけることとなりました。
折角の機会ですので、今現在、日本語ではきちんとした解説記事がない、Android TestとProject Nitrogenについてお話させていただきました。

docs.google.com

今まで別々のAPIだったInstrumented TestのAPIとRobolectricのAPIが統一されました。
これで何が言いたいかといえば、24ページ目の

同じコードで速度と精度のバランス取ったテストできるの最高

ということにつきます。
最新のJetpackのAndroid TestRobolectric 4.0の組み合わせから使用できるので、興味のある方はぜひお試しください。

また、鳥アレルギー保持者にはつらい話についても、出発前にまったく耳にしなかったので、この際に多くのI/O関係者の方に認知されたらいいなと思います。


また、現在執筆中の『Androidテスト全書』についてもたくさんの反響とご声援をいただきました。
まことにありがとうございます。頑張って書いておりますので、引き続きご声援をいただけますと幸いです。

peaks.cc


6/21のAndroid Test Night #4で本の内容についてお話させていただきますので、気になる方はぜひお越しくださいませ。


ますますAndroidのテストを書くのが楽になりますね!
品質の高いアプリをスピーディーにユーザーさんに届けてゆきましょう✧\\ ٩( 'ω' )و //✧

Diverseでは引き続き、一緒に働いてくださるエンジニア(Android, iOS, サーバサイドも!)を募集しています!
未来のデーティング、人と人との出会いを一緒に作ってゆきませんか?
興味がある方は @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!

Shibuya.apk #23でPWA時代のAndroidエンジニアのお話をしました & ホストしました

Shibuya.apk #23のホストをしました、 id:kikuchy です。
参加人数が50人を超えるような大型の勉強会のホストをしたのは初めてだったのにも関わらず、たくさんの方に楽しんでいただくことができて何よりでした。

そのShibuya.apk #23にて、『PWA時代のAndroidエンジニア生存戦略』と題しまして、PWA台頭後のAndroidエンジニアの活路についてお話してきました。

docs.google.com

(またSlideShareにアップロードしたらエラーが出ました。スマホからも閲覧しやすくGoogle SlidesのPDFも掲載できるスライド共有サイトがあれば是非お教えください…)

PWAの波が本当にくるのかどうかはまだわかりませんが、もし来たとしたら一部のAndroidアプリはネイティブである必要がなくなりPWA化を余儀なくされる可能性があります。
Androidエンジニアとして先鋭化するか、それともスキルを活かしてPWAに乗り換えるか、選択が必要になるかもしれません。


懇親会でもPWAについてお話を伺うことができました。

問題なのは「ネイティブアプリである必要がないのにネイティブなアプリを作る必要があった状況が変わり始めている」ということなのでしょう。
今そんな状況を作り始めているのがPWA、というのが実感のようです。

また、Androidアプリの市場も成熟してきていて、どちらにしろエンジニアに求められる技術は高度化してゆきそう、というお話も伺いました。
何か専門分野を作っておくのも手かもしれません。例えば

  • Android TVに詳しい
  • ライフサイクルとチーム規模を考慮に入れたアーキテクチャに一家言ある
  • ランタイムの仕組みをわかっている
  • エンジニアの需要を掴んでライブラリを作れる
  • kiosk端末を開発できる
  • など…

集中することは能力を伸ばすことの近道だからです。
その専門分野に需要が全くないと困ってしまいそうですが、ニッチであるほど、所によっては強く求められるでしょう。
そう言えばこの前のDroidKaigi 2018のテーマにも「ニッチ」が入っていましたね!


参加していただいた皆様、会場運営を手伝ってくださった皆様、どうもありがとうございました!!
今後は更にスムーズな運営を目指して行きたいと思います。✧\\ ٩( 'ω' )و //✧

そしてDiverseでは引き続き、一緒に働いてくださるエンジニア(Android, iOS, サーバサイドも!)を募集しています!
未来のデーティング、人と人との出会いを一緒に作ってゆきませんか?
興味がある方は @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください!