Diverse developer blog

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

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

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

VEAT Product TEAMで1ヶ月インターンしてきたので報告など

はじめに

はじめまして。 id:mktakuyax です。8月末からの約1ヶ月間、インターンとして株式会社ミクシィに入社し、株式会社Diverse VEAT Product Teamでお世話になりました。

このエントリでは、インターン期間中やったことやインターン前の期待、実際に得た学びなどについて、比較的長い文章を真面目に書いていきたいと思います。

こちらはpoiboyチームの武田くんと一緒に写った写真です。

f:id:t-amano:20160927185307j:plain

VEATについて

VEAT Product Teamでは、VEATというプロフィール動画でマッチするデーティングサービスを開発・運営しています。今年の春に海外向けにリリースしました。詳しくはDiverse公式ブログの紹介記事を読むと良いです。

VEATは、上記の通りサービス開始が今年の春と、フレッシュなサービスだったので、他のミクシィインターン生から聞いた長く運営しているサービス特有の闇などを味わうこともなく、レールに沿った気持ち良い開発をすることができました。

VEATは、サーバサイドのフレームワークとしてRuby on Railsを採用しています。APIサーバはRails 5から追加されたAPIモードを使って実装され、別アプリケーションとして中の人が操作する管理画面があり、クライアントとしてiOSのアプリがありました。僕は主に、サーバサイドの開発を担当させていただきました。

Rails自体は他社のインターン・アルバイトや趣味の開発である程度触っていましたが、管理画面を自前実装しているサービスの開発は未経験だったり、WebViewに逃げずJSON APIのサーバとネイティブのモバイルアプリという組み合わせのサービスを扱うのも初めてだったので、「新しいことやりに行くぞ」という気持ちで開発に臨むことができました。

また、社内ではGitLabを使っていて、gitを利用したバージョン管理はもちろん、Issue管理やコードレビュー、さらにはCIまでもがキレイにGitLab内で完結していました。

期待していたこと

比較的大きめなチームでの開発

今までは、創業者以外全員学生インターンなスタートアップだとか、リモートワーカー3人だけのチームといった、小さなチームでの開発しか経験したことがありませんでした。今回のインターンへの参加にあたっては、エンジニアやデザイナさん、マーケティングさんなどを含め15人くらいの比較的大きめなチームで、ひとつ屋根の下サービス作りを進めていく体験をしたいという期待がありました。

特に僕はざっくりとですがチーム開発について興味があったので、自分の地元のバイト先と比べて足りないものは何か、逆に僕の方から何か貢献できることは無いか、という気持ちが強くありました。地元北海道のバイト先での開発フローについては、学内発表会で発表したときの資料があるのでリンクを貼っておきます。 

チーム開発事例紹介 / Work with a team in BULB inc. // Speaker Deck

これまで扱ったことのないようなサービスを扱うこと

今までは、学校の先生向けのサービスやシェアリングエコノミーサービスのためのプラットフォームの開発だったりをしてきたので、今回デーティングサービスというまた一味違った性質のサービスを扱うという事に不安もあり、またちょっとした気持ちの高まりも感じていました。やっぱりこの手のサービスは社会からの厳しい目に晒されることも多く、当然運営側としてはそうならないような努力をしてきているはずで、それを現場のエンジニア目線から見てみたいといった期待です。

やったこと

インターンに来た時期がちょっと微妙だったようで、すでにサービスのベーシックな機能は実装し終えていて、「じゃあこれからどういう方向にサービスを持っていこうか」ということを決めていきながら細かい修正などを加えていく段階だったらしく、細切れのタスクが多めだった印象です。

大きめのタスクとしては、管理画面のKPIレポートの改善や、開発用のダミデータ自動生成機能、ユーザに提供されるフィードの高速化と検索の改善などがありました。

学び

比較的大きめなチームでの開発について

体制が整った大きめの会社の中のひとつのチームというだけあって、毎回のMTGや物事が進んでいく流れはしっかりしていたような気がします。毎朝のスタンドアップミーティングや毎週のKPT会議など、一緒の場で、チームで同じ目標に向かっているという感覚を持ちながら働くのはとても楽しく、またまわりの人たちが何をしているのか意識しながら緊張感を持って働くことができました。

基本的な開発体制などに関しては、正直「まぁ2016年にマトモにRailsで開発してたらこうなるよね」という感じでした。レビュー自動化のスクリプトがgitlab CI内で走っていたり、そのレビューも単なるRailsのコードのレビューではなくschemaなどのチェックスクリプトなどがあり、そういったところは持ち帰りたいなと思いました。

これまで扱ったことのないようなサービスを扱うことについて

やはり、サービスの健全化への努力はしっかりしていて、プロフィールや動画などをチェックするための仕組みはあったし、管理画面系でもそういうタスクがありました。

その他、技術的なことについて

RubyやRailsは普段からいじっているので、そのあたりの技術に関して何か新しいものを求めていたわけではありませんが、気になっていたRails 5のAPIモードや、Rails Engineなどをまともに使っているアプリケーションに触れることができたのは良い経験でした。

また上の方でも書きましたが、レビュー自動化、特にDBのスキーマのチェックなど大きなチームで開発する上で生まれた品質を担保するための工夫的なところは良い学びだったと思います。

おわりに

インターン前に期待していたことについて、何か得るものがあったので、良い経験だったなと思います。

めちゃくちゃできる人の下で働くということや、実際にビジネスが動いている場で働くということには、それだけで価値があり、ミクシィ・Diverseにはそういう環境があるので、もし興味のある学生さんはまた来年のインターンに応募してみると良いと思います。

VEATチームのみなさん、Diverseの皆さん、そして他のインターン生やミクシィグループの皆さん、1ヶ月間大変お世話になりました!

デーティングサービスの中の人としてインターンしてきた話

こんにちは。この度インターン生としてPoiboyチームでお世話になりました、id:teakunです。
今回はこの6週間のインターンで取り組んだこと、インターン生から見たDiverseの環境、そして、デーティングアプリについて感じたことについて紹介します。
写真は右が私で、左がこのインターンを同じDiverseで過ごしたid:mktakuyaxくんです。彼のブログ記事も、私と同じタイミングで公開されるはずなので、是非そちらもよろしくお願いします。


f:id:teakun:20160923143547j:plain

参加の経緯

今回私が参加したのは、こちらのインターンです。
mixi.co.jp

ミクシィグループのインターンでは応募時に、部署の希望を決めることができます。普段iOSアプリの個人開発をしていることもあり、iOS開発がやりたいと人事の方に言ったところ、提案された部署がDiverseのPoiboyの開発チームでした。正直なところ、デーティングアプリということで始めは渋ったのですが、とにかくiOS開発がやりたかった私は、どんなアプリでも結局開発することは同じと腹を括って、Poiboyでインターンに参加することを決めました。

参加にあたっては現場の社員との面接があり、「デーティングアプリへの偏見はありませんか?」と何度か質問されたのですが、ちょっと嘘つきました。すいませんでした。これを書いている今現在は、何一つ偏見なくデーティングアプリを楽しめるようになっています。このあたりのことはまた後から書きます。

Poiboyについて

Poiboyは"ポイして恋するコミュニケーションアプリ"とある通り、女性が男性を"ポイ"(LIKE)することでコミュニケーションが始まるデーティングアプリです。男性は、プロフ写真や自己紹介を充実させ、女性からポイされるのを待つことになります。私も参加にあたって実際に自分でも使っているのですが、やはり女性にポイされるのは嬉しいものですね。
poiboy.jp
詳しくは、こちらの説明がわかりやすいです。


Poiboyは今年の2月にリリースされたサービスで、iOSのアプリはすべてSwiftを使って書かれています。そのため、大昔にObjective-Cで書かれたコードなどに悩まされることなく、開発にスッと入ることができました。また、開発に当たってはGitlabやDeployGateなどのツールが利用されており、バージョン管理やデバッグの環境が非常に整っていて、我流で進めていた個人開発との違いをひしひしと感じます。

インターン期間中にやったこと

インターン期間の流れ

8/16-9/23の約6週間の参加期間の過ごし方として、社員の方に提示された6週間の流れはこのようなものでした。

  • 1週目 環境構築と簡単なバグ修正で開発フローに慣れる
  • 2週目 少し大きめのタスクでもっと開発フローに慣れる
  • 3-5週目 画面1つを丸々改修するような大きいタスクに取り組む
  • 6週目 このブログを書いて6週間をまとめる

またこれらに加えて、毎週Qiitaに記事を上げるという課題が課されました。普段アウトプットをしていなかった私にとっては、なかなかつらかったです。

意識したこと

私はどこかの企業や団体に属したことがなく、小規模な個人開発しかしたことがなかったため、チーム開発をするのは初めての経験でした。それを踏まえて、インターン期間中に私とメンターさんとの間でこれをやって帰ろう!といって具体的に意識して取り組んだことは以下のようなものです。

  • Gitのフローを学ぶ
  • コードレビューをできるようになる
  • MVCフレームワークの概念を理解する
  • スケジュールを意識した開発をする

中でも、スケジュールは特に強く意識して取り組んだ部分でした。これはチーム開発だけに限らず、どんな事にも通じていることだと思うのですが、しっかり予定を立てずに作業を取り組み始めることはとても非効率です。一人で作業していると、ついつい横道にそれてしまい、当初の予定とは違う作業に入ってしまったりするのですが、チーム開発ではそうはいきません。今週はこのバージョンを出す、この頃にはiOS10が出るから準備しなくては、といったようにしっかりと現実を見て準備をする必要があります。また、Poiboyではコードを書くエンジニアだけではなく、デザイナーさんや企画の方など、多くの人や要素が密接に関わり合って進めていくことになるので、自分のスケジュールだけでなくチーム全体の状況を把握することの大切さを感じました。

インターン期間の成果と得たもの

実際に作ったもの

Poiboyにはグループ機能と呼ばれる、女性がお気に入りの男性をグループとしてまとめる機能があります。そのグループ機能の画面を改修することが、今回の私の最も大きなタスクでした。実際に私が作った画面はこのようなものです。

before

f:id:teakun:20160923174855j:plain:w300

after

f:id:teakun:20160921142203j:plain:w300

改修とは言ってもこのレイアウトは私が考えたものではなく、デザイナーさんに用意していただいたものです。確かにbeforeと比べるとグループの画像やview数の追加など、情報量は充実しつつも、うるさくない画面になりました。

稼働中の大きなサービスのコードを読む機会は個人開発をしているとなかなかない機会なので、コードを読んでいるだけでも勉強になります。自分の作ったコードだけを読む個人開発とは異なり、他人が作った膨大なコードをしっかりと把握しなければならず、その点に苦労しました。ついつい時間をかけて読んでしまうので、そこは反省です。大まかな部分はすぐに作り上げることが出来たのですが、そこからのレビュー、修正の作業が難航しました。普段一人で開発を進めていると、多少レイアウトが崩れてしまってもとりあえず動くからそれでいいか、と言った風になりがちなのですが、そういった妥協は一切ありませんでした。

社員の皆さんのレビューは的確で、どんな些細な部分でも冗長なコードやアプリが落ちる可能性のあるコードを書いてしまうと、ビシバシとマサカリが飛んでくるエキサイティングな環境でした。私も社員さんのコードをレビューをさせてもらいまして、まだまだ社員さんの指摘からは程遠いですが、ネストが深くならないような書き方や、メソッドが呼ばれるべき場所はどこなのか、などなどなんとなくコツを掴めたかなと思います。やはりこのような経験は、実際の業務ならではの経験でした。この経験はこれからの自分の開発にも活かして、妥協のないコードを書くようにしようと肝に銘じました。

チーム開発

参加期間中のPoiboyのiOSクライアント開発はインターン生の私を含めた3人で進めました。基本的には

  1. コードを書く
  2. プルリクを出す
  3. レビューを受ける
  4. 修正(2~4をLGTMが出るまで繰り返し)
  5. マージ

と言った流れで作業を進めていました。これまでGitについては簡単なコマンドを知っているくらいでほとんど使った経験がなかったのですが、6週間みっちりと指導を受けて、自分の作っているコードをGitでしっかり管理するようになるまでに成長しました。ちなみに、私がこのインターンに来てはじめに教えてもらったことは、「コミットメッセージは文頭を大文字にした方が分かってる感が出る」ということでした。

また、画面の改修にあたってはデザイナーさんと協力して進めていくことが多くありました。
UIのガイドラインやUIのパーツが、お願いしてからすぐにササッと仕上がっているので、デザイナーさんは凄いなと思わずにはいられません。

Qiita

私がインターン期間中に投稿したQiitaの記事については以下の通りになります。
qiita.com
qiita.com
qiita.com

アウトプットする習慣を付けようということで始まったQiitaへの投稿でしたが、普段あまりアウトプットする機会のない私にとっては、なかなか慣れない作業でした。書いた内容は、業務の中で自分がつまずいた部分をまとめた部分と、もっとPoiboyを良くするためにはこういう部分に気をつければいいのでは、という内容をまとめたつもりです。また、投稿した内容にタイポがあって編集リクエストが来て修正されるということがあり、エンジニアのコミュニティの優しさに触れたような気がしました。メンターさんからも知らなかった〜と言って頂けた部分もあり嬉しかったので、これからも継続してアウトプットを続けていこうと思いました。

デーティングアプリ

インターン前に思っていたこと

デーティングアプリは所謂、出会い系と呼ばれるものです。出会い系、といって皆さんはどのような印象を持たれるでしょうか。正直なところ良い印象を持っている人はなかなか少ないように思います。サクラが横行しているんじゃないか、変な商材を売りつけられるんじゃないか、実際合ってみたらカツアゲされるんじゃないかなどなど、怖い、危ない、という風に考えている人も少なくないのではないでしょうか。私もこのインターンに来るまでデーティングアプリに対して、あまり良い印象はありませんでした。しかし、実際に中の人として働いてみて、その考えが偏見に満ちていたものであると知ることになります。

インターンが終わってみて感じること

インターン中は、Poiboyだけではなく同じDiverseの別のものや、他社のデーティングアプリなど色々な種類を使ってみて、デーティングアプリが実際にどのようなものであるかを学んでいました。
これは、どれを使ってみても感じたことですが、「デーティングアプリを使っている人はみんな普通」なんだな、と思うようになりました。これは、既に利用している人からしたら当然の事なのかもしれませんが、使ったことのない私からすると拍子抜けでした。大体のデーティングアプリではマッチするとメッセージ交換ができるようになるのですが、普段やり取りをしている友達かのように趣味や仕事の話をできるので、こんな優しい世界があったのかと驚きでいっぱいです。

私は理系の大学院生をしていて、「女の子と知り合う機会がない」「一緒に遊びに行ける友達が欲しい」といった嘆きの声を多く耳にします。そういった人たちにデーティングアプリを是非勧めたいです。デーティングアプリは、一歩踏み出すまでのハードルが高いです。自分の顔写真をアップロードすることに抵抗のある人や、自分のプライドが登録を許さない人もいるでしょう。でも、その一歩を踏み出すことで新しい出会いがあるかもしれません。

その他インターンをしていてよかったこと

リアルイベントに参加した

私がインターンに参加している間、PoiboyではNON STYLEの井上さんとのコラボ企画が行われていました(これを書いている現在も真っ最中ですが)。
その中でも一つの大きなイベントとして、井上さんが「3分間で何名とツーショットが撮れるか」という世界記録へ挑戦するというイベントがあり、インターン生ながら見学として参加させて頂きました。
イベントの結果はこの記事によく書かれています。
www.oricon.co.jp
残念ながら記録達成とは行きませんでしたが、会場は非常に盛り上がり、多くメディアにも露出したようで、とても面白かったです。
また、司会の方と井上さんが私がこれから改修する予定の機能についてトークされていたり、実際のPoiboyを利用しているユーザさんがたくさん集まっていたりなど、自分が携わっているサービスの規模の大きさを感じ、身が引き締まったことを覚えています。

他のインターン生との交流

ミクシィグループのインターンではそれぞれ部署は異なりながらも同時期に参加しているインターン生が20名ほどおり、インターン生同士の交流が盛んでした。毎週、人事の方がインターン生同士が集まる機会を用意してくださって、それぞれの部署での話や、自分が今抱えているタスクについて話し合うような機会がありました。
ミクシィほどの大企業となると、集まってくるインターン生はとても優秀な人たちばかりで、一緒にご飯に行ってもすぐに技術の話になったりと、刺激的な毎日を過ごしました。もう既にTwitterの学生エンジニア界隈でブイブイ言わせている有名人もいたので、彼らに負けないように良いプロダクトを作って名声を上げていきたいです。

f:id:teakun:20160921160624j:plain:w300


私はこのインターン中に誕生日を迎えたのですが、インターン生の皆に祝っていただきました。できるエンジニアは幹事も完璧にこなすのかと感動しました。奥の方にチョコで書かれた文字はさておき、とても嬉しかったです。ありがとうございました。

東京で働くことのイメージができた

私は滋賀生まれ滋賀育ちの生粋の滋賀県民で滋賀を離れたことがなく、東京は恐ろしいところなんじゃないかと思っていましたが6週間過ごしてみて、意外と過ごせるな、という感覚を得ました。この業界で働くためには、東京は避けて通れない道だと思っていたので、この感覚を持てたことは非常に良かったです。インターン中の宿泊先はミクシィの方が無料で宿泊先を手配してくださり、非常に快適でした。これで遠くから参加するインターン生も安心ですね。実際インターン生は北海道から沖縄までいろんな地方から集まっていたので、これからインターンを考える人にはオススメします。

反省

ここまで良いことばかりを書いてきましたがいくつか反省もあるので、そこについても触れておきます。

作業途中でインターンの最後を迎えてしまった

これが今回のインターンの中で一番反省しているところです。しっかりとレビューを受けてマージされるまで、自分のコードは責任を持ってやろうとメンターさんから何度か話がありました。にもかかわらず、中途半端に進めたタスクを残してインターンの最終日を迎えてしまうことになり、非常に反省しています。インターン中は毎日一日のスケジュールを建てて無意味に時間を消費したりすることはなかったものの、本来かけるべきではない場所に時間をかけてしまうなど、時間配分の部分で失敗があったので、この反省を今後に活かしたいです。願わくば、道半ばで残された私のコードがメンターさんの手によってマージされリリースされることを祈ります。

時間の使い方

上でも少し書きましたが、もっと効率よく作業を進めることができたんじゃないかなと思う部分が多くありました。普段使うツールからしてもXcodeさえ入れたら開発始められるしオッケーと考えるのではなく、より効率よく作業を進めるための準備をしっかりとしておけば、長い目で見たときに大きな差がつくと思いました。メンターさんからこういうツールがいいよ、と教えていただいてインターン中盤で一度環境を整え直しましたが後の祭りだったので、初日にガッツリ時間を使ってでも整えるべきだったと今になって反省しています。
また、ミーティングやレビューなど想定外のタスクが突然降ってくることがあってバタバタしてしまうことがあったので、そういう部分を加味してスケジュールを考えておけばよかったです。

最後に

これを読んだ人にいいたい

新しい出会いが欲しい人、気にはなってたけど使わずにいた人、是非デーティングアプリを使ってみましょう。オススメはもちろんPoiboyです。

感謝

最後になりましたが、株式会社ミクシィ、株式会社Diverse、インターン生、そしてインターン中にメンターとしてお世話になったid:cfikenさんを始めとするPoiboyチームの皆様、6週間と短い間でしたが本当にありがとうございました!!
この経験を大きな糧に、エンジニアとしてもっと成長していきます!!!

GithubでSlackのカスタム絵文字を表示する方法

こんにちは!

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


みなさんはSlackのカスタム絵文字大好きですか!?
みなさん大好きということで、今回はGithubでカスタム絵文字を表示するChrome拡張を
作りました!

何を作ったの?

f:id:yuta-fujita-dvs:20160808195823p:plain
これが

f:id:yuta-fujita-dvs:20160817164529p:plain
こうなります。


これを見たあなたはホッコリとした安らぎが得られるているのではないか・・・と思います。

ソースコード

GitHub - SAMUKEI/emoji-chrome


インストール方法はREADMEを参照ください。
フィードバック大歓迎です!

困ったこと

Chrome拡張の実装時に困ったことと対処内容をまとめます。
今後Chrome拡張を作成する際に参考にしてください!

Chrome拡張で外部リソースにアクセスできない

原因

一般的に外部リソースの画像を表示する際には、

<img src="http://hogehoge.com/hoge.png">

のように記載すると思いますが、Chrome拡張においては外部リソースへのアクセスは
Content Security Policy に違反するためできません。

対処方法

公式ドキュメント の解決策を参考に、XMLHttpRequestを利用する必要があります。

対応例

GitHub - SAMUKEI/emoji-chrome
content.js

    var xhr = new XMLHttpRequest();
    xhr.open('GET', emoji[match], true);
    xhr.responseType = 'blob';
    xhr.onload = function(e) {
      var src = window.URL.createObjectURL(this.response);
      $("#" + _id)[0].src = src;
    };
    xhr.send();

    var img = "<img id=\"" + _id + "\" width=\"32\" height=\"32\" />"
    console.log("img = " + img);
    return img;

Chrome拡張でリアルタイムに画面更新されない
(Issue投稿の直後の絵文字が変換されない)

原因

GithubではIssue投稿、Issueへのコメント投稿などの画面の更新(F5)が行われません。
そのため、$(document).readyではキャッチできません。

対処方法

こちらのQiita記事のように通信をキャッチし、
キャッチしたタイミングで処理を行うことで実現可能です。

対応例

GitHub - SAMUKEI/emoji-chrome
manifest.json

  "permissions": [
    "webRequest",
    "http://*/*",
    "https://*/*"
  ],

background.js

chrome.webRequest.onCompleted.addListener(
  function(details) {
    chrome.tabs.query({
      active: true,
      windowId: chrome.windows.WINDOW_ID_CURRENT
    }, function (result) {
      var currentTab = result.shift();
      chrome.tabs.sendMessage(currentTab.id, details, function() {});
    });
  },
  { urls: [ "<all_urls>" ] },
  [ "responseHeaders" ]
);

content.js

chrome.runtime.onMessage.addListener(function (message, sender, sendResponse) {
  // 通信完了時の書き換え
  replace();
});

今後(いつか)の改修したいこと

  • キー入力時にサジェストから絵文字選択可能に
  • 速度面が不安なので速度改善など(未計測なので速度計測も)

お約束

 
 

『Androidオールスターズ2』に登壇しました

はじめまして。
株式会社DiverseでYYCのAndroidアプリの開発をしている id:kikuchy です。

f:id:t-amano:20160809173121j:plain

先日開催されました Androidオールスターズ2 に登壇させていただきましたので、この場を借りて報告させていただきます。

eventdots.jp


発表内容

『なるべくコードを書かないAndroid開発』という題でお話させていただきました。

YYCチームでは昨年から今年にかけて、Androidアプリをフルスクラッチでリニューアルするということを行いました。
その際にaptとKotlinを用いてエンジニアが管理すべきコードの削減を行ったので、そこで得たaptとKotlinの知見を元にお話させていただきました。


Q&A

懇親会でいくつか質問を頂いたりしたので、ご紹介します。

Kotlinの導入はどれくらい簡単?

既存のJava + Gradleで作っているプロジェクトがあって、開発IDEにAndroid Studioを使っているのであれば非常に簡単です。
Kotlin公式のドキュメントをご覧ください。ワンコマンドで解決します。

kotlinlang.org

また、KotlinからJavaのコード呼び出すのも、JavaからKotlinのコードを呼び出すのも、通常のJava/Kotlinのコードを呼び出すのと全く変わらない手軽さです。
Bridging-Header的なファイルを用意しなくても良い分、Swift <-> Objective-Cの相互運用よりも簡単だと思います。

ですので、新規に作成するクラスからはKotlinで書き始め、段々Kotlin比率を増やしていく、といったスタイルがおすすめです。
(私達、YYC Androidチームもこの方法を取りました)

チーム開発の際に新しい言語を導入するのは大変ではなかったのか?

以前にShibuya.apkという勉強会でお話させて頂いたことがあります。


自分が社内エバンジェリストになる感じで、新しい言語を学ぶことは楽しい、とメンバーに思ってもらうことが大切だと思います。

Kotlinのデメリットは?

まだ成熟していない言語ですので色々つらいところがありますが、代表的なものをいくつか。

  • コンパイルが遅い
  • AndroidのDataBindingとの相性が悪い
  • kapt (Kotlinのapt) を使うとコンパイルが更に遅くなる & kaptの設定を間違えると不具合が出ることがある

aptのデメリットは?

  • コンパイルが遅くなる
  • Javaのメタプログラミングの知識を(多少)要求される

生成しようとするコードによっては TypeMirrorElement の扱いを要求されることがありますが、その程度だと思います。
(作ろうとするものによりますが…!)


会の雰囲気

他の登壇者の方の発表についてはブログの主旨から外れますので、ここでは書きません。
公開できる登壇者は #eventdots ハッシュタグを付けてスライドを公開しているはずですので、探してみてください。

登壇者の方々はもちろん、聞きに来てくださっていた方々もAndroid開発界隈では有名な方がいらっしゃって、セッションだけでなく懇親会でも、とてもレベルの高いお話を聞くことができました。

全体的になごやかな雰囲気で、懇親会の話も弾み、会場が閉まる直前まで多くの方が残られていました。

主催のdots. 小沢さんから「また来年も開催します!」というお話があったので、来年も開催されたら参加したいと思います。


さいごに

実は私自身、Android開発を始めて1年と少ししか経っておりません。
かなりがむしゃらにやって来ましたが、そのがむしゃらなやり方を許容してくれる環境がDiverseにはあります。

自分を急成長させたいあなた、ぜひDiverseへ!