Diverse developer blog

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

夏のKotlin LT祭 でLTしてきました

id:kikuchy です。

先日開催された夏のKotlin LT祭にてKotlinJSについてお話させていただきました。

kotlin.connpass.com




GoogleがAndroidの公式開発言語にする、Springが対応を表明する、Kotlin/Nativeが発表されるなどして、Kotlin界隈もますます盛り上がってきております。
しかし、Kotlinのファーストリリース時からある機能なのにいまいちパッとしない機能があります。

Kotlin -> JavaScriptのトランスパイル機能です。

当日も会場の方々に挙手をお願いしたところ、予想通り使っている方はほとんどいらっしゃいませんでした。

どうしてパッとしないのか、実は隠れた使い勝手の良さがあるのでは、もしかしたらすぐにでも業務に投入できたりするのでは…
と思って、実際に使ってみた感じを報告するスライドになっております。


結論はスライドに書いたとおりです。

LTを聞いてKotlinについておもうこと

Androidに限定しないKotlinについての勉強会だったため、サーバーサイドの話題も多く、JVM言語としてはかなり主要な位置を占めてきはじめている言語だなと改めて感じました。

JVMで動くプログラムを作るなら、まず第一の選択肢にKotlinが上がる時代がもうすぐに来るでしょう。

私個人は自分用のコマンドラインツールやGUIのアプリなどもKotlinで書いています。
Stream関連の拡張関数も充実していますし、Delegated Propertiesを使ってPropertiesの項目をクラスメンバに割り当てると扱いが楽だったりと、便利に使えています。
趣味プロにもKotlinをぜひお使いください!

Kotlin/Nativeも盛り上がって欲しいですね。
iOSをKotlinで書く未来がくると夢見て…


DiverseではAndroid開発にKotlinを使用しています!
Kotlinを使った開発をしたい方はぜひ一度お越しください!↓

diverse-inc.co.jp

Shibuya.apk #17に登壇してきました

id:kikuchy です。
ここ半年ほどはiOSの開発をしていて、そこで一緒に仕事をしている id:devorgachem から良いアーキテクチャを教えてもらったので、それをAndroid開発に適用する方法をお話させていただきました。
とは言え、難しいことではありません。

スライド中でお見せしたサンプルのリポジトリはこちら。

github.com

要は

Activity/Fragmentにフラグを書くのをやめて、画面がとり得る状態をちゃんと列挙して管理しましょう、というお話です。

もっと言うと

状態を専用クラス(モデル)で管理し、Activity/Fragmentから切り離すととても便利です。
とり得る状態と状態遷移の仕方がわかっているので、

  1. 所定の操作をした時に、所望の状態になっているか
  2. 所定の操作をした時に、意図しない状態に陥っていないか

だけ確認できればテストは最低限のテストはできますし(Viewとかは別問題ですからね!)、一部のモデルを再利用することも可能です。


特に、APIで得られたデータを加工して表示するのが主な責務になっているアプリですと、通信状態 ≒ 画面の状態になりがちなので、通信状況を管理できるとコードの見通しが良くなります。


頂いた質問など

発表後にいくつかご質問をいただいだきましたので、共有させていただきます。

Kotlinのsealed classを使用しているのはなぜ?(enumは使わないの?)

一言で言えば、SwiftのAssociated Values付きenumと同じことをしたかったから、です。

Kotlinには特定スコープ内でのみ継承が可能になるsealed classというクラスがあります。

kotlinlang.org

アプリケーションの状態にはデータを付随させたいことが多々あります。
(例えば、「通信完了」状態には、通信の結果得られたレスポンスor失敗の原因が付随するはずです。)

やりたいことは状態を列挙して宣言しておくことなので、たしかにenumでも事足りそうな気がします。
が、JavaやKotlinにおけるenumはプログラム起動時にすべてのインスタンスが生成されてしまう(シングルトンになっている)ので、状態ごとに違う型のデータを付随させることが難しいのです。
(値をNullableで取り扱うことを許容すれば実現可能だと思います)

sealed classとdata class、それに加えてwhen式を使えば、Swiftのenumと同じことを実現できます。
data classを使えばequals()も自動的に用意されるので、テスト時の比較も簡単でSwiftよりも便利です!

LiveDataを使っている理由は?(もしくは、RxLifecycleの使用を勧めている理由は?)

モデルの生存期間がActivity/Fragmentよりも長くなりえることを想定しているためです。
(必ずしも、長くする必要があるわけではありません)

状態を抱えているモデルの生存期間は、Activity/Fragmentのライフサイクルとは独立しています。
特にDIツール(Dagger2など)を使ってシングルトンとして生成されたモデルのインスタンスなどは、Activity/Fragmentより長く生きることになります。

するとよく言われている通り、onNextのタイミングでViewが居なくなっていてNPEを引き起こしたり、Subscriberがリークする原因となるので、適宜、モデルからの通知を止めてやる必要があります。

そのために用意されているのがLiveDataなりRxLifecycleなので、それの使用をおすすめしているという訳です。


ちなみに

モデル部は通常のJava Libraryとして作れるのでJVM上でテスト可能です。(サンプルではそうしています)
テストが速攻で終わって便利です。



Diverseはこれからも新しい提案や試みを発表してゆきます°˖✧◝(⁰▿⁰)◜✧˖°

iOS Test Night #4 でLTしてきました

id:kikuchy です。
Androidをやっていたはずですが、最近はiOSをガッツリやっています。

先日開催されたiOS Test Night #4に登壇してLTをさせていただきました。


testnight.connpass.com


今回は、テストコードをアプリケーションコードと同じ(Groupの)階層に置きなおすツールを作った話をしました。

紹介しているツールはこちらになります。
github.com





きっかけは、前回 iOS Test Night #3 であった以下のツイートを見てのことでした。

ちょうどその頃、fastlaneのオプションを追いかけたりしてコードを読み、Xcodeprojというgemを知ったばかりだったのです。

github.com

このgemは、Xcodeのプロジェクト設定や含まれるファイルなどを管理する project.pbxproj を抽象化して取り扱うものです。
ビルドターゲットに含まれているファイルを取得することもできますし、ターゲットからファイルを削除したり追加することも可能。

とても便利なgemですので、Xcodeプロジェクトを操作するようなツールを作りたいと思っている方は、ぜひ一度チェックしてみてください。




発表の後に主催の方からこのようなツイートをいただきました。

勉強会で得られるものは、問題の解決方法だけではありません。
問題がある、ということ自体を教えてもらうことができます。
問題があれば、解決するチャンスです!

Diverseのエンジニアは、これからも問題も解決方法も発信してゆきます。\\ ٩( 'ω' )و //

Shibuya.apk #12に登壇してきました

こんにちは。最近はiOSの開発をしている id:kikuchy です。
iOSの開発をしていますが、Androidの新しい動きは引き続き追いかけております。


渋谷近辺のAndroidエンジニアが集まる Shibuya.apk という開発者コミュニティがあります。
先日は12回目の開催でした。

shibuya-apk.connpass.com



今回は Android Things について、AndroidエンジニアがIoTにどう関わり始めたら良さそうなのか、お話させていただきました。

Android Thingsでは普通のAndroidスマートフォン向けのコードがそのまま動くため、
あとはアナログ回路の知識とスキルがあれば、 物理的インタラクションができるAndroidアプリ を作成する事が可能です!

ということは、Androidエンジニアは既存のスキル+αで新しいジャンルに挑戦できる、ということでもあります。

ぜひこのタイミングで、Android Thingsを通じてIoTの世界に足を踏み入れてみませんか?


ちなみに、Yahoo!さんのオフィスビルがとても綺麗だったのが印象的でした。
f:id:kikuchy:20170203193433j:plain

レガシーから脱却する話をしました

f:id:lasa007:20161122215639j:plain
2016年11月22日、ヒカ☆ラボにて、ネットマーケティング様と合同で「レガシーシステム脱却秘話」をテーマに勉強会をさせていただきました。

atnd.org

弊社からはエンジニア3人が登壇いたしました。何を発表したのか、どのような思想や思いでレガシーからの脱却に取り組んでいるのかをご紹介します。




どうしてコードはレガシーになるのか

f:id:lasa007:20161122200148j:plain
id:kikuchy です。
『どうしてコードはレガシーになるのか』という題でお話をさせていただきました。



YYCチームでは昨年から今年の頭にかけてAndroidアプリをフルスクラッチでリニューアルしました。
そのきっかけ(原因)となったリニューアル前のアプリのコードのレガシーさと、その分析から得られた「レガシーコードを生み出さない環境づくり」の方法についてのお話です。

レガシーコードが生まれる原因

人間が当たり前のことを当たり前にやらないからです。
ところが、当たり前のことをやる、というのは意外と大変なものです。
しかし、人間は認知的負荷の低い行動はとりやすい(前例に倣う、など)ので、当たり前のことをきちんと実行できる環境を整備しましょう、というのが今発表の主旨でした。

整備するべき環境
  1. プロダクトがどのような構造で出来上がっているのかを、後から来た人にもわかるようにする
  2. その言語らしいコードを書く
  3. エンジニアがスキルアップを心がけるようにする(仕掛ける)
レガシーコードが生まれたら

スライドに明記していなかったのですが、このようになると思います。

  1. これ以上レガシーコードが生まれない環境を整える
  2. 地道に取り除く
  3. 取り切れる量でなかったらコードを全部捨てる

最後の「コードを捨てる」は時間もお金もかかるため、最終手段ですが……
YYC Androidアプリの場合は経営判断でOKがでたので、フルスクラッチでリニューアルを行いました。



Titaniumから脱却している話

f:id:lasa007:20161122203208j:plain

こんにちは、Diverse 結婚支援事業部 アプリエンジニアの @yuta-fujita-dvs です!

当日のスライドはこちら

YoubrideのiOSアプリをTitaniumからSwiftにするために行っていることについての発表です。

RedmineからGitlab、Jenkinsの導入、チーム横断でのコードレビュー、に開発環境を変えていったお話になります。
詳しくはスライドを参照していただければと思います。

反省点としては、

  1. デメリットにまだ自分の中で解決できていない内容を混ぜてしまっていた。
  2. LTなのに発表時間を意識せずにダラダラ話してしまった。
  3. 発表中にPCを見すぎて会場に目を向ける時間が少なかった。

といったことです。

まだまだレガシーから脱却していくためには壁があり、現在進行中で壁を破っているので、次回があれば反省点を活かしつつそういった話などもできればな・・・と思っています。




集計システムをDBからTDに移した話

f:id:lasa007:20161122205307j:plain

女性向けデーティングアプリ Poiboy でiOSエンジニアをしている中西 @cfiken です。

同様のイベントで、「集計システムをDBからTreasureData(TD)に移した話」というタイトルで、
TreasureDataを使って行ったことと、それによってチームがどのように変わったか、という話をさせていただきました。

Poiboyは今年の1月に正式リリースしたデーティングアプリで、少人数チームでの開発のため、開発効率であったり、PDCAサイクルを如何に早く回すか、という点がサービスのスケールのために重要です。
そのために必須とも言えるのがサービスの各数値の集計です。
より詳しく、より早い段階でチームメンバーが数値を追うことが出来るように、今までサービスのDBからのみ直接集計を行っていたものを、TD上に移して自動化を行いました。

前半は、具体的にどのような手続きを踏んだのか、TDの使い方、集計効率をあげるための工夫、メンバーに浸透させるための工夫などの話を。
後半は、色々と集計に関するレガシーを脱出した結果、チームメンバーの働き方にも影響があったよ、という話をさせていただきました。

まだ変化の途上ではありますが、後半の話が中心だったので具体的にいくつか紹介すると、

  • チームメンバーが以前より数値を追うようになった
  • 施策の企画から反省までの流れが確立した
  • 集計が身近になり、開発者だけでなく一部の企画などのメンバーが直接WebからTDを触るようになった

など、当初想定していなかった色々な良い影響がありました。

今までは施策の度にエンジニアがKPIを集計していたのを考えると、ただ見れる数値が増えたのみにとどまらず、大きな改善になりました。
レガシー要因を改善することで、そのレガシー部分だけでなく、想定していなかった良い影響があるかも、ということがイメージとして伝われば幸いです。

準備時間があまり取れず、時間配分や資料のクオリティがまだ甘かったところがあるので、次の機会ではもう少ししっかりと準備したいと思います。
また、タイトルにTreasureDataと入っていたことで、TDの踏み込んだ使い方やデータサイエンスに関する話を期待されていた方もいたようで、また機会があれば次はそのような話をしてみたいですね。
当日お世話になった皆さま、ありがとうございました。


今回の勉強会で、思いの外たくさんの方が古いシステムから新しいシステムへの移行について悩んだり苦労したりしていることがわかりました。

どんな新しい技術も時間が経てば陳腐化してしまい、その寿命は年々短くなっているようにも感じます。が、Diverse は、常に新しい技術を積極的に導入できるようなエンジニア文化を推進していきたいと思います。

Poiboyのインターンで非日常な体験をした話

はじめに

こんにちは!ミクシィのサマーインターンシップに参加して、Diverseでインターンしていたid:anddev68です。

f:id:kiyoponb:20161014052612j:plain

1ヶ月と短いインターンでしたが、多くの経験を得ることができました。この良き体験を自分自身で整理するため、そしてもっと多くの人に広めるためにインターン体験記&レポートを書きたいと思います。

結論からいうと、時間があるなら今すぐ参加すべきです。

mixi.co.jp

 

経緯・動機

私の今夏のコンセプトは「非日常な体験をしよう!」でした。

皆さんはデーティングサービスを利用したことがありますか?私もインターンするまでは利用したことがありませんでした。デーィングサービス*1のインターン今夏のコンセプトにぴったりではありませんか。

また、mixiのインターンに参加すると、東京で生活できる環境が提供されます。これは地方民である私にとって大きなメリットでもありました。

やったこと

大きく分けて4つあります。初週はアプリを徹底的に使い込んでバグを見つける作業でした。アプリとソースコードを合わせながらどこに何があるのか把握するという目的があります。2週目は実際にコードを触ってみたり、開発フローを学ぶために11バグの修正。3週目は、1,2週目の総まとめとしてお気に入り画面の作成。4週目は残ったタスク処理と発表会という充実したスケジュールでした。 

デバッグ

他の人が作ったアプリのデバッグをしてみて、普段の自分が作ったアプリに対するデバッグの適当さが明らかになりました。これからデバッグを行う際はさらに注意深く見る必要があると思いました。

バグ修正

既知の問題点、あるいは自分が見つけた問題点を直しました。問題点リストから1個ピックして、コードを書き、PRを出して、レビューでチェックしてもらうというのが一連の流れです。コーディング規約*2や設計に従う必要があり、思ったより時間がかかってしまいました。

お気に入りの画面作成

1週間かかる最も大きなタスクでした。画面を作成するためには、API*3や設計、画面レイアウト、非同期処理*4などを理解する必要がありました。Poiboyではクリーンアーキテクチャーという設計技法に加え、RxJavaという非同期処理用ライブラリが用いられており、苦労しましたが大変勉強になりました。

クリーンアーキテクチャーは、役割ごとにしっかりとレイヤーが分かれていて綺麗な設計でしたが、1機能の実装に4ファイル以上書き換えなければならないという点に苦労しました。また、RxJavaについては、Javaとは名ばかりで、実際には別の言語で書き方を覚えるのが大変でした。

実際に作成した画面がこちらになります。

 f:id:anddev68:20161014112047p:plain 

その他

デザイナー・エンジニアなど業種を問わずインターン生で進捗報告会が数回ありました。進捗報告会では、「VCSってなんですか?」など、共通語だと思っていたものが実は業界用語だったということがありました。自分がやっていることを専門外の人にもわかりやすく説明する技術も必要だと感じました。

 

おわりに

インターンシップは、非常に多くの体験をし、様々な知識を得ることができました。技術面、その他の面においても、今後に活かしていきたいと思います。

遠方に住んでいる方は特に、東京で働いてみる絶好の機会ですので、是非応募してみてください。

*1:女性と男性を繋ぐためのサービス, Poiboyなど。

*2:コードを書く上でのチームで決めたルール

*3:Application Programming Interface, サーバとアプリでの通信ルール

*4:画面の裏側でダウンロードするなどの処理のこと

Android版「Poiboy」〜激短(1ヶ月)制作フローと気づき〜

はじめまして。デザイナーの鷹取(id:marucoguma)です。
今年の4月に新卒として株式会社ミクシィに入社し、出向という形でDiverseのPoiboyチームでデザインを担当しています。

今回は社内でデザイナー向けに発表した資料をもとに、
Android版「Poiboy」の制作フローについて書こうと思います。

f:id:marucoguma:20161003171308j:plain:w500


はじめに、「Poiboy」とは

f:id:marucoguma:20160929180502p:plain:w500

お気に入りの男の子をみつけてポイ(お気に入り)する女の子のための恋愛応援アプリです。
女の子がポイした男の子とだけメッセージ交換ができます。
また、ポイした男の子をタイプ別にグループ分けして女の子間でシェアして楽しむことができます。

現在、20万人以上のユーザに利用されています。
最近では、Android版Poiboyリリースを祝してノンスタイル井上とのアプリ内でのコラボ企画やギネスチャレンジイベントも行いました。

Android版Poiboyの制作フロー

前置きが長くなりましたがAndroid版「Poiboy」の制作について書いていきます。

制作スタート時の状況

①制作期間は1ヶ月だけ!
②初回リリースの機能はかなり削らないといけない!
③担当デザイナーは私だけだったので、スケジュールも自分で管理しないといけない!

Androidアプリを研究

私は普段iOSユーザーで、Androidを触ったことがありませんでした。AndroidアプリのUIを学ぶには様々な方法がありましたが、なによりも時間をかけたのは「Androidの実機を自分の手に持ち既存のアプリを触ってみる」ということです。

MaterialDesignのガイドラインは面白いのでついつい読み浸ってしまいますが、私が作るのは人が手に持って使う「道具」です。ユーザーが手にするものも、切り離されたひとつひとつのグラフィックではなく、サービスの流れにそって文脈をもつ「道具」です。なのでまずは既存のAndroidアプリをたくさん使ってみることをしました。一番手っ取り早くAndroidアプリという「道具」を知ることができます。

スマートフォンアプリのUIをデザインする際に、一貫して「道具」を作っているという意識はとても大切です!

Androidアプリに少し慣れてきたら、今度は既存アプリのワイヤーフレームを書き出すことをしました。
流し見にならないようにアプリを触りながら片方の手でペンを持って紙にワイヤーフレームを書き出すことで、既存のAndroidアプリにおいてどのUIが一般的でどのUIが特徴的なのかわかってきます。

時間もなく、Androidの右も左もわからないのでとにかく手を動かしました。

iOS版の機能と遷移書き出し

f:id:marucoguma:20160929190305j:plain:w500

既存のAndroidアプリでよく見受けられたのは、iOS版とほぼ同じデザインで画面下にあったナビゲーションバーを画面上に移動させたようなつくりです。たしかに、ほぼiOSと変わらないデザインにしてしまえば制作時間を短縮できますが、AndroidとiOSは操作感などまったく異なる道具です。

なので、デバイスに合ったUIデザインを考えて1から作ったほうがいいと思い、「Poiboy」の機能を書き出すところから始めました。

また、この書き出しは絵ではなく文字で行います。画面にどんな機能があってどの画面に遷移するか、文字で書き出すことによりiOS版「Poiboy」のビジュアルや設計にとらわれずに機能を整理して作れると考えました。

ワイヤーフレーム

f:id:marucoguma:20160929185743j:plain:w500

ワイヤーフレームを書いたらこまめにPrott(プロトタイピングツール)にはめて操作感を確認します。

繰り返しになりますが、作っているのはサービスの流れにそって文脈をもつ「道具」なので、Prottのようなツールを利用してペーパープロトタイプの時点で組み立てることが重要です。この段階ならば何度でも簡単に壊したり試したりできます。

ユーザーテスト(の後)

f:id:marucoguma:20160929185747j:plain:w500

制作期間が短い状況だったので、社内の他プロダクトのAndroidに知見のあるデザイナーにユーザーテストを行いました。他プロダクトのデザイナーにテストしてもうことで、デザイナーとしての意見とユーザーとしての意見を一緒に調べることができると思ったからです。

ユーザーテストの結果をプロトタイプに反映させようとした時、Prottで作成したプロトタイプのままだと改善点/意見を照らし合わせにく、どこから直していけば良いかが見えにくい状態でした。なので、プロトタイプを遷移する順に模造紙に並べ、ユーザーテストで出た意見や改善点を付箋に書いて貼ることで、プロトタイプの画面と改善点/意見が結びつき、どこに問題があるか、どこから直していけば良いかわかりやすくなりました。

本制作

f:id:marucoguma:20160929185810j:plain:w500

Sketchで本制作する期間は2週間半ほどでした。作るべき画面と、それに要する作業時間を洗い出してスケジュールを立てました。私のスケジュールはAndroidエンジニアに共有し、制作物の進捗もこまめに報告して出戻りが少なくなるようにしました。

制作したデザインを振り返ることもとても大事です。
週に1回、Androidチームで製作中のプロダクトのお披露目会をし、プロダクトを触りながら意見交換をしていきました。初めはAndroidの右も左もわからない私でしたが、いろんなひとの助けもあって1ヶ月走りきり、無事リリースすることができました。リリース後は、AndroidチームでKPT(Keep/Problem/Try)を話し合い、その後の制作業務に活かすようにしています。

さいごに

最後まで読んでいただきありがとうございます。
「Poiboy」は、利用者の80%以上が18〜24歳(2016年6月時点)で、多くの若い男女に受け入れられています。
もっと使いやすく、楽しんでいただけるサービスになるよう、チーム一同取り組んでまいりますので、今後とも「Poiboy」をどうぞよろしくお願い致します!

poiboy.jp