Diverse developer blog

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

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 TestとRobolectric 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やリプライをください！

サポーターズさん主催の Git 初心者向け勉強会にて講師を担当しました

Git

はじめまして、17新卒で Diverse にてiOSエンジニアをしている@imaizume です。

try! Swift の熱気も冷めやらぬ内ではありますが、今回はiOSではなくgitに関する勉強会の登壇レポートになります。

先月2月6日にサポーターズさん主催の元、「detached HEADを理解して脱Git初心者を目指す方のためのGit入門勉強会」というタイトルの勉強会を開催し、私が講師を担当させていただきました。

supporterzcolab.com

 

当日の資料を公開しておりますので気になる方はぜひご覧ください。

 speakerdeck.com

内容としては、主にGitの初学者がつまづきやすい概念の一つである branch と HEAD を1から丁寧に解説し、最終的に detached HEAD の意味を正しく理解するというものになります。


deateched HEAD 状態とは、HEAD が branch を向いていない状態のことで、言い換えれば HEAD が直接 commit を指している状態のことです。

この状態になると、コンソール上には "You are in detached HEAD state" というメッセージが表示されます。

しかし、gitの学び始めではメッセージの意図が理解できず、状態の理解や復帰の方法が分からず戸惑いがちです。

かくいう自分も、かつてはそんな中の一人でした。

そこで今回は、まずbranchとHEADの正体を内部構造的側面から説明し、わかりやすいように図説を交えて丁寧に解説致しました。

例えば、 git を学び始めたすぐは git branch を直訳的に「枝 = 連続するcommit群」と認識して学習を進めてしまいがちで、ネット上でもそういった解説をされている記事が散見されます。

しかし正確には git branch は特定の commit を指すポインタに過ぎません。

つまり、 branch は別の commit へ付け替えることが可能ですし、任意の commit から自由に作成することが可能です。

branch をポインタとして理解しているかどうかで、git を通じた操作の自由度が大きく変わります。

またgit の学習初期ではあまり意識されない HEAD についても改めて解説を行いました。
HEAD もまた branch や commit を指すポインタで、こちらは「自分自身」を表しています。

そのためHEADが branch を checkout している場合、 add や commit といった操作は、HEAD が参照する branch が指す commit に対して行われていることになります。

そして最後に detached HEAD が 「HEADがbranchを指していない状態」であり、エラーでないということを確認しました。

いきなり detached HEAD 状態を理解するのは難しいですが、このように branch や HEAD を正しく理解できていれば理解の助けとなるはずです。

また実際の開発現場で detached HEAD になる必要があるケースについても紹介しました。

例えばモバイル開発では、ある段階でビルドがエラーになった場合、そのエラーが入り込んだと疑われる commit を一時的にcheckoutし、エラーが出ないことを確認した後、必要に応じてブランチを強制的に戻す、または新規にbranchを作成するといった作業をすることがあります。

また過去に作ったローカルブランチをリモートへpushしないまま消してしまった場合、 git reflog というコマンドでHEADの移動履歴を参照し checkout することで復活させられるといったテクニックも紹介しました。

終了後には参加された方から「図解があることでとても解りやすかった」「疑問に思っていたことが解消できた」などの好評をいただきました。

Diverse では、ソースコード管理を Git で行っており、普段から業務で使用する機会も多いため、今後も知見を共有する場を設けていきたいと思っております。

また Diverse の所属するミクシィグループでは、学生向けに git challenge というイベントを不定期で開催しています。

connpass.com


自身も第1回 git challenge の参加経験者であり、今回の勉強会を開催したのもこのイベントで得た知見を外部にも共有したいと思ったことが最初のキッカケでした。

次回の git challenge 開催は未定ですが、決まり次第ミクシィグループ採用ページにて告知する予定です。

もし興味を持って頂けたら、ぜひミクシィグループ採用ページもチェックしてみてください!

もちろん Diverse では iOS, Android, サーバーサイドエンジニアも大絶賛募集中です!!

ご興味ある方は @imaizume または他の弊社エンジニアへお気軽にお声がけください。

DroidKaigi 2018 Reject ConferenceでAndroidエンジニアがiOS開発で力を発揮する方法をお話してきました

DroidKaigi 2018にはCfP（Call for papers、審査用の概要）を3本出して全部落ちました。 id:kikuchy です。

先日開催されたDroidKaigi 2018 Reject Conferenceにて、『AndroidエンジニアがiOS開発でも即戦力になる方法』と題しまして、AndroidエンジニアがiOSアプリ開発をすることになったときに既存のスキルを活かす方法をお話させていただきました。

connpass.com



docs.google.com

（今回のスライドはSlideShareにアップロードできなかったためページ内表示ができませんでした…）

Androidの世界から見るとiOSの世界には似たものもあれば違うものもあります。
「似ている」「違う」という関連を知ることで、iOS開発に必要なものをすぐに覚えたり思い出したりすることができます。

そうした学習の一助になれば幸いです。

スライド中でお話した「iOSでテストが普及していないようにみえるのは、Mockitoのようなライブラリが無いからではないか」ということについて、すたぜろさんから便利なツールがあるという情報をいただきました。感謝！

Java/KotlinでMockitoを使ったテストに慣れていると、Swiftのみの環境下でスタブを手で作るのは非常に時間がかかって（気力も削がれて）困るので、こうしたライブラリがあると助かりますね！

懇親会ではiOS開発の辛いところ、マルチプラットフォーム開発の夢についてたくさんの方とお話する事ができました。


iOSアプリの署名まわりはやはり難解ということで大多数の方の意見が一致しました。
もっと簡単になってくれればよいのですけれど…

また、Kotlin/NativeのMultiplatform Projectsは（Xamarin.Forms登場以前のXamarinと同様に）ドメインロジックの記述を共通化できるというものであって、これだけでマルチプラットフォームアプリを作成できる訳ではない、ということも話題に上がりました。

Kotlin/Nativeの知識だけでマルチプラットフォームアプリを作れるわけではないとなると少々ガッカリしてしまうかもしれません。
マルチプラットフォーム開発をスピーディーに行いたい場合、FlutterやReactNativeを使用した方がよいと私も思います。
しかし、各OSで頻繁に使用するAPIを抽象化したもの（java.io.*やjavax.crypto.*などに相当するようなAPIのKotlinで記述されたexpectと、各OS用のactualのセット）が用意されると、また状況が変わってくるかもしれません。

Diverseは今後もAndroidエンジニアの皆様に知見を共有してゆきます！°˖✧◝(⁰▿⁰)◜✧˖°

AndroidエンジニアもiOSエンジニアも募集中です。
未来のデーティング、人と人との出会いを一緒に作ってゆきませんか？
興味がある方は @kikuchy または他の弊社エンジニアへ、お気軽にDMやリプライをください！