Diverse developer blog

株式会社Diverse 開発者ブログです。

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 初心者向け勉強会にて講師を担当しました

はじめまして、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やリプライをください!

Connehito Marché #1〜Android市〜にて二人のエンジニアが登壇してきました

明けましておめでとうございます。
新年初めての更新です。 id:kikuchy です。


先日開催されましたConnehito Marché #1〜Android市〜にて、id:kikuchyが『Android Developer Toolsのバグを見つけて直してもらった話』、Yoshihisaが『OkHttp3+Retrofit2+...』と題しましてお話をさせていただきました。

connehito-marche.connpass.com


『Android Developer Toolsのバグを見つけて直してもらった話』では、id:kikuchyが昨年末に踏み抜いたAndroid Lintのバグについて、発見から解決までの流れについてお話させていただきました。

www.slideshare.net

ソフトウェアも人が作るもの。多くの人の目を通されたOSSであっても、利用する人がいつ何時バグを踏み抜くかわかりません。
バグ報告は品質向上の手助けにもなります。
もしバグを見つけた際には適切に報告をして、品質向上のために貢献しましょう!




『OkHttp3+Retrofit2+...』では、AndroidにおいてHTTP通信を実装する際によく採用される OkHttp + RetrofitにKotlinのコルーチンを組み合わせて非同期処理を同期的に書く方法についてお話させていただきました。

speakerdeck.com

Kotlin1.1からExperimentalで提供されているコルーチンですが、1.2でProduct Readyであることが宣言され、1.3ではいよいよExperimentalが外れる予定です。これまでRxをPromiseの代わりとしてしか使っていないシーンではコルーチンに置き換えることでよりわかりやすいコードになるでしょう。



懇親会では、(iOSやサーバサイドからの)Androidエンジニアへの転身について、KotlinのCoroutineの実戦投入、PWA (Progressive Web Apps)の台頭による未来予想など、幅広い範囲のお話が飛び交っておりました。
KotlinのCoroutineは1.2時点でProduction Readyであるとアナウンスはされていて、1.3ではパッケージ名やAPIが変更になる(かも知れない)とのことです。
わざわざRxのストリームにしなくても済むものは、Coroutineで置き換え始めても良いかもしれませんね。



いよいよ来週はDroidKaigi 2018ですね!!
DiverseはDroidKaigi 2018プラチナスポンサーとして、DroidKaigiを応援しています。

技術書典でもないのになぜか同人誌を頒布します!
無料ですが、紙の冊子は数に限りがありますのでお早めにお越しください! PDFでも頒布しますのでそちらもダウンロードしてください。


AndroidまたはDroidKaigiをテーマに、DiverseのAndroidエンジニアが、普段の業務ではできないことに挑戦しました。
取り扱っている内容は以下のとおりです。

  • Flutter
  • ConstraintLayout
  • 最新のライブラリの組み合わせ
  • Google Assistants
  • Kotlin/Native

是非お立ち寄りください!



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

Android Test Night #2 で、Androidのテストについての総まとめをお話してきました

DroidKaigi 2018が迫ってきて、それに伴って社内でもいろいろなことが動き始めていて面白いです(DiverseはDroidKaigi 2018 プラチナスポンサーです!参加されるあなたと当日はブースでお会い出来るのを楽しみにしております!)。 id:kikuchy です。


先日開催されたAndroid Test Night #2にて、『今更聞けない? Androidのテストのいろは』と題しまして、Android特有のテストの事情を解説させていただきました。

testnight.connpass.com


www.slideshare.net


「Androidのテストをこれから始める人に『コレ読んでおいて』と渡せるくらいまとまった資料が今まで無かったので、良い資料が出てきて嬉しい」というご意見もいただくことができました。
お役に立てれば何よりです。
読んでいただけますと幸いです。



Test Nightシリーズも今回で2回目、ということで、相変わらずレベルの高いテストの話をたくさん聞くことができました。
今まで理解が曖昧だったIdlingResourceの話なども聞けて、一歩理解が深まった気がします。

また、懇親会ではAndroidエンジニアが少ない話や、Google Homeの話題に花が咲きました。
スマートスピーカーが普及の兆しを見せている中、我々エンジニアの主戦場もスマートフォンから別の場所へと移り変わっていくのかもしれませんね。


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

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

Shibuya.apkでkotlinのsealed classをJavaから見た時のsealed具合について話してきました

はじめまして!今年の4月にインフラエンジニアからAndroidエンジニアに転生したYoshihisaです。

先日開催されたShibuya.apk#20にて「kotlin界のsealed classはJava界からみても『sealed』なのか」というタイトルで5分LTをしました。

shibuya-apk.connpass.com

www.slideshare.net

Kotlinには「sealed class」という継承範囲を同一ファイル内に制限する仕組みがあります。これをJavaから使おうとしたとき継承の範囲制限は有効なのか?を調べた結果をまとめたものです。*1

調べた動機と方法

そもそもこれをなんで調べたのかというと、YYCのAndroidアプリのある画面に新機能を追加する案件の開発中にAPI通信に関わる部分のモデルをsealed classで状態を定義したステートマシンとして作りそれをJavaで書かれたFragmentから使おうとしたことがあったからでした。

ふと「Kotlinの世界ではsealed classはsealedされていることをコンパイラがやってくれてるけどJavaの世界から見ると本当に『sealed』されているの?制限を突破して継承できたりしない?」と思ったのです。

気になったのでselaed classでクラスを作りそれをコンパイルしたバイトコードからJavaへ逆コンパイルする、というお手軽プランで調査してみました。(ついでにsealed classをJavaから使うコードを書いてみましたがif-else文とキャストまみれになり辛くなりました。Kotlinは同じコードをwhen式やif式、スマートキャストを駆使して簡単に書けます)

後日談

改めてsealed classを逆コンパイルした結果を見てみました。

逆コンパイル結果抜粋

sealed class本体のプライマリコンストラクタはprivateですがコンパイラがpublicなコンストラクタを自動生成しており子クラスはそれを使うようにバイトコードが生成されています。(スライド中では「DefaultConstructorMarkerが必要らしい」と書きましたが自動生成されたコンストラクタについて回るものらしくsealed class特有のものではありませんでした)

sealedを突破するためにDefaultConstructorMarkerをimportしようにもできず、またキャストなしでnullを渡してコンストラクタを呼び出すことも試みましたが存在しないことになっていて呼び出せませんでした。

コンパイル時はpublicなコンストラクタは存在しておらず呼び出せないので継承することができない、というような仕組みで守っているのでしょうか。もしこの記事を読まれた識者の方がいらっしゃればはてブのコメント等で教えていただけるとうれしいです。

 


 

今回は5分LTという形でしたが社外の勉強会で発表するのははじめてでした。とても緊張しましたが終わってみると楽しかったのでまたどこかで登壇できたらと思います。

宣伝

DiverseではAndroidエンジニアを募集中です!
興味がある方は @bomneko_attack または他の弊社エンジニアへお手軽にDMまたはリプライをください!

*1:sealed classそのものや使い途についてはid:kikuchyKotlin Advent Calendar 2017 12日目でまとめているのでそちらをご参照ください。

Shibuya.apk #20で新規アプリ開発において大切なことをお話してきました

こんにちは、一人でAndroidの新規アプリ開発やってます、 id:kikuchy です。

先日開催されたShibuya.apk #20にて、Androidの新規アプリ開発において感じた、大切だと思うことについてお話させていただきました。

shibuya-apk.connpass.com


www.slideshare.net

プロダクトオーナーと事前に目的などのすり合わせしておきましょう、というお話です。
聞き取りを行う際に便利なヒヤリングシートのテンプレートも作りましたので、こちらも合わせてお使いください。

「コードベースの寿命について議論する発想が今まで無かったので、チームの人とも話してみたい」といった感想もいただきました。
お役に立てれば幸いです。

頂いた質問など

いくつかいただきましたのでご紹介します。

4系をサポートしないとなると、市場で何割かのユーザーに価値提供ができなくなる。POは納得したのか?

ヒヤリングシートにも記載した国内外のOSバージョンシェアをお見せし、また社内の類似サービスユーザーのOSバージョンシェアもお見せした上で判断していただきました。
結果、ターゲット層が似ている社内の他サービスでもほとんどのユーザーがAndroid 5.0以上を使っていること、4系のサポートコストをかけられるほどエンジニアリソースがないことから、4系のサポートをしないことになりました。

どんな設計にしたのか?

まだまとまっていない&有用な設計であるかどうか自身を持てる段階でないので公開していませんが、Model-View-IntentやReduxに近い考えです。
が、(私は記憶力がないので)一画面あたりの関連クラスが増えると全体像の把握が困難になることと、少人数開発なので細かい分業の必要性が薄いことを鑑みて構成などを変えています。
来年のどこかでお話できるとよいのですが…

          • -

Shibuya.apkも、もう20回目を迎えたそうです。
その間にAndroid界隈でもいろいろなことがありました。
Kantar Woldpanel によると、日本でもAndroidのシェアがiOSのシェアを上回りました。
2018年、Androidの市場はどのように動いていくのでしょうか。この先が楽しみです。

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

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