TDDBCに参加＆ペアプロデモをしました #tddbc
tddbcにスタッフとして参加&ペアプロのデモをしました。
ペアプロのデモとは
TDDBCではTDDのやり方を学んだ後、参加者がペアになってペアプロをしながらTDDを実践するプログラムになっています。 このペアプロでどうやって進めていくのか、のデモを行いました。 今回は@yattomさんとFizzBuzzを題材にペアプロしました。
やってみて
ある程度台本があるので安心です。ここでこういう説明が入るとか。 でも後はその場の雰囲気です。実際のペアプロをやってみせてるだけなので疑問とかもガンガン言っちゃっていいので気は幾分楽です。 今回は@yattomさんがリードしてくださり説明などもしてくれたので、なんとかなりました。 自分の開発環境を前のスライドに映しながら行うので自分の開発環境へのツッコミも新鮮でした。
デモプレイヤーさんが Vimmer なのが気になる…… #tddbc
— えび🦐 (@ebc_2in2crc) 2017年9月30日
— てらひで (@terahide27) 2017年9月30日
今回@PoohSunnyさんから煽られてデモをすることになったけど、「人前でライブコーディングするのが一番成長するからやってみな」と言ってくれたと聞いて感謝してます:pray: (FizzBuzzをライブコーディングして成長するかは置いておいて、新しい経験だったので楽しかったです！)
その他
- 午後は参加者に混じってペアプロやってた。1年目、2年目のフレッシュな方とペアを組んでみて自分も気づきがあって何より楽しかった。
- tddbcの参加者の方々は話がうますぎる。どんなコードを書いたかを前で発表する時間があるのですが、皆さんプレゼンがうまくて引き込まれる。
- 他の言語チームのコードを見たり話を聞いたりするのがとても楽しかった。Spock使ってみたくなったり、良い興味の入り口になったと思う。次は覚えたての言語で参加したい。
- 皆テストについての興味や悩みが共通事項としてあるので、質問タイムも懇親会の即興LT大会もすごく盛り上がって楽しかった。こんなアットホームで参加者同士でこんなに仲良くなれるコミュニティはすごい。
GitHubのPRで質問が来た場合はソースコードにコメントで回答する。これいいなぁ #tddbc
— おれたま (@AHA_oretama) 2017年9月30日
- ペアプロしている同士ではすぐ疑問解決されるから良いけど他のチームメンバーに逆に伝わらなくなったりしないの？な質問だったと思う。
- PRのコメント/質問をgithub上で返すのではなく、コードのコメントに反映して設計意図を伝える方法良いと思った。
ご査収ください #tddbc pic.twitter.com/VxpMv57vT5
— ガオピン (@gaopin1534) 2017年9月30日
最高だった。
みなさんお疲れ様でした！！！ #tddbc pic.twitter.com/ftomcuBZsL
— Yotaro TAKAHASHI (@PoohSunny) 2017年9月30日
楽しかった！！！
Tokyo Android Meetupで初英語プレゼンしてきた
Tokyo Android Meetupというイベントで初めて英語でプレゼンしてきました。
#11 Tokyo Android Meetup - July Edition - Tokyo Android Meetup (東京都) | Meetup
Meetup内のイベントは日本開催でも外国の方が参加するイベントが多いらしく、hotchemiさんのブログを見て以前からmeetupのイベントに参加してみたいなと気になっていた。
そんな時にCLEMのイベントに参加したことがきっかけでmeetup参加したことないけど喋ってみることになりました:bow: clem.connpass.com
次回のTokyo Android meetupでtalkをすると良いと思いますね😇 cc: @niko_yuwono
— hotchemi (@hotchemi) 2017年6月29日
準備編
初めての英語プレゼンだったので、アドバイス貰った通りどんなことを話すかスライドとそれに合わせてスクリプトを作成していました。 keynoteのnoteのところにスクリプトを書き出してそれを見ながら練習していました。 英語に関しては、先輩に単純な文法のミスや、言い回しのアドバイスなどをレビューもらいました。
また、内容に関しても直前に社内でLTする場があったので日本語で同じ内容を発表してなんとなく内容について雰囲気をつかんだりしました。
当日行って気づいたこと
英会話のレッスンとネイティブの人が話す速さ、全然違うので聞き取れなかった
- 特に単語と単語がつながりすぎて人によっては全く聞き取れなくて辛かった
- 1ヶ月半英会話続けて単語レベルで英語が聞き取れるようになったと思ったけど速く話されるととたんに駄目だし、はっきり発音されないと何も聞き取れないということがわかった。
DMM英会話で女性の先生のレッスンばかりを受けていたことを後悔した
- DMM英会話初めて1ヶ月半くらい経つのですが、「なんか安心できる」という理由だけで女性の先生ばかり選んでレッスンしていた
- 実際エンジニア界隈は男性が多いのでハードルばかりがあがってしまい当日場が和むまで最高にコミュ障だった
だんだんBGMになっていくのがわかる
- 最初は頑張ってついていってたつもりだけど、途中から完全に頭がついていかなくて全然話が入ってこない
- 自分の今のキャパシティはここなんだなということがわかった。これをどんどん伸ばしていけたらいいなと思った。
感想
- レッスンで話される英語と実際の会話で話されてる英語はちょっと雰囲気が違うのでそれを味わう。本当の会話にどれだけ太刀打ちできるか試しにくる意味ではmeetupのイベントとても良いと思った
- meetup参加すると、「英語ができるようになりたい」じゃなくてこの人たちと話がしたいという思いになってモチベーションアップに良い。
- 参加している外国の方、だいたい日本語も知ってる人が多いので日本人に対して色々な事情理解・配慮してくれているなと感じた
- デベロッパーが使う言い回しなどを覚える貴重な機会。同じ境遇の人が多いから真似できる言い回しなど多いなと感じた。
- 今回はすごくアットホーム。10人くらいの小さなイベントで最初の英語プレゼンをするには良い場所だったと思う。たいしたことない話だったと思うのに、ウンウンうなづいて聞いてくれたのがすごくうれしかった。
- 日本の勉強会とも一緒だが、speakerしたことで日本人だからと関係なく話しかけてくれる人もいて助かった。楽しかった。
- まだ私が来るには早かった、と思ったけど参加してみたらすごく楽しくて参加してよかった。
speaker枠でもらった🎉 pic.twitter.com/WxWSdwDrS3
— よこ ち！ (@chiiia12) 2017年7月25日
Second talk is Introduction to Calabash by @chiiia12 pic.twitter.com/noiuq0ofMY
— Niko Adrianus Yuwono (@niko_yuwono) 2017年7月25日
だいぶ楽しんだ模様。定期的に腕試し&モチベーション維持の意味でも良いと思いました。
Spring Bootのキャッチアップにバージョンアップで理解を深めた話
最近Androidアプリ開発からサーバサイドの開発に移り、移って早々SpringBootのバージョンアップをする案件にアサインしてもらった。SpringBootはじめてです！の段階でプロジェクトのSpringのバージョン担当することもなかなかない話かと思うので、Spring Bootのキャッチアップという点からバージョンアップで対応する時に学んだことをここにまとめる。
前提
- 業務で経験していたのはAndroid開発のみ
- そういえば今まで業務でライブラリのバージョンアップを経験したことはなかった
要約
- プロジェクトのSpringBootバージョンを1.2系から1.5系まであげた
- SpringBoot始めたばかりで通常のエンハンス案件をやっているだけでは知らなかったと思える経験・感覚をつかめたので、学習の導入になった
バージョンアップを経験してよかったこと
SpringBootの導入には「はじめてのSpring Boot」でキャッチアップしていたが、そこでは知れなかったこと&もしこのままエンハンスをやっていたら知るのが遅くなってたであろうと思うことをいくつか。
ライブラリの依存関係について
バージョンアップ作業中に一番対応したのがライブラリの依存バージョンの解決だった。
//TODO:例えば
AライブラリとBライブラリが中でCライブラリに依存してるが、AとBはバージョンによって依存するCのバージョンが違う、みたいなことが起こる。バージョンの違うライブラリに依存していると、順番はわからないがどちらかの依存versionしか参照できず、NoSuchMethodErrorで怒られる。この仕組みについて最初わかってないので困惑した。
mvn dependency:treeやpom.xmlのDependency Hierarchyをみながら各ライブラリの依存ライブラリの整合性を修正していく作業が多かったかと思う。
ライブラリの依存関係を理解する過程で不要なdependencyなどを見つけたり、pom.xmlの整理の仕方も多少は身についたかと思う。
Android開発の時はライブラリのバージョンアップの経験がなくてライブラリ間の依存関係について意識することがなかったので勉強になった。
エラーログに向かう感覚の醸成
SpringBootを初めて触れた時、自分が書いたClassとは全く違うClassからエラーが吐き出されることにとても困惑した。今までは、基本的には自分の書いたコードからExceptionが吐かれることが多かったので、原因もわかりやすかった。 バージョンアップの対応にはたくさんのこうしたエラーに対応しなくてはいけないので、数をこなして慣れることができた。最初に感じていたゲッという気持ちはバージョンアップ経験後ではなくなったので非常によかったと思う。
参考にできるネット上のページの感覚
上にも関連することだが、たくさんエラーが出る中でわからないことを調べる時に参考になるページが集中的にインプットされる。最初はどうぐぐったらヒットするのか模索するのでとても効率が悪かったと思うので。 - Maven Repositoryの各ライブラリのDependency部分 - 公式ブログ - Release Note - Githubのissue - Javadoc - その他QiitaとかStackOverflowなどは普通に。。。 こう書いてみると当たり前なリソースな気がするが、これを経験する前はこれができなかったのである。
Springの各種プロジェクト間の関係性について
恥ずかしながら色々あるSpring系のFrameworkについて全く認識しないまま開発に入ってしまった。例えば以下などがバージョンアップを通して気づき経験した。 - starter系はversionが一緒になるのでそれを踏まえて依存関係を解決しなくてはいけない。 - Bootが依存しているSpring Frameworkのバージョンも変わるので、Spring Frameworkの変更点も確認しなくてはいけない。 - パッケージの変更などで新しくspring-securityをimportしなくてはいけなくなったり。 エンハンスだけしていたらあまり意識してなかったと思うので、いいきっかけにだった。まだ理解してないこともあるのだけど少しだけ。
バージョンアップするにあたり個別に対応したところ
どこで動かなくなったかがわからなくなるのが不安だったので、ひとつずつバージョンをあげて「ここまでは動く」を確認しながら進めた。 意外とボリュームが多かったので別記事にまとめる。うん。まとめる。
まとめ
キャッチアップ材料として「バージョンアップしてみる」選択肢としても考えてみるのも良いかもしれないと思った話。状況と必要性もあるが。 エラーのデバッグを集中的に数こなす意味ではSpring Bootの仕組みに慣れるのでよかった。エラー出ても少しは怖くない！ プロダクトの設計や仕様把握はまた別なので、エンハンス始まって泣きながらキャッチアップしてる。
JJUG CCC 2017 Springで登壇しました~新卒2年目が鍛えられたコードレビュー道場~ #jjug_ccc #ccc_l3
JJUG CCC 2017 Springで登壇してきました。
JJUGについては以下。 www.java-users.jp
発表内容については以下を参照ください。 speakerdeck.com
ここからは忘れないうちに感想文。 外部イベントで2回目の発表でした。（1回目はこちら。）
20分の発表は話の構成のしかたがすごく難しいなと思った。今回はストーリー作りもそうだし、スライドでの伝え方に結構苦戦して、結局最終的なストーリーに行き着くまでに何回か潰した気がする。20分のボリューム感、どこまで話広げるべきかがわからなくて、結局最後の練習まで17分で終わってしまうボリュームだった（本番はなぜかぴったり20分になった）。
本番は小さい部屋でしたが、満員で部屋に入れなくなるほど人が来てくれたり、発表後に質問に来てくれた方もいた。発表してよかった。。。 ちょっと今後気をつけようとおもったのは、新しいmacとアダプター経由でのプロジェクターへの接続が悪くてヒヤッとした。やっぱりしばらく旧macも一緒にもってないと怖いかも。
あとは他のイベントと比べてtwitter実況が少ないイメージ。どんなところが刺さったんだろう？ちゃんと伝わってたかな、心配です。
また登壇後、コーディングスキルアップの仕方について後輩と話したりして、結局今回レビューしてくれていた先輩がすごかった＆かなり恵まれてたんだなぁということに気づく。 多分若手にとってもどんな知らない世界があるのかわからない、先輩にとっても若手がどこまで知らないのかわからない、このお互いの状態をつきあわす機会があって、うまく知識を整理してインプットしてくれる先輩がいて今回の内容に繋がったんだとおもった。 恵まれてる環境だったのは確かなんだが、より横展開しやすい形にできたらもっと良かったなと感じた。
あとは初めてはてなのホッテントリに入って感動！準備してる時は地獄だとおもったけど、こういうアウトプットにできて今回CfP出してみてよかった。
ちなみに2017年の目標は「社外のイベントで登壇する」にしていて、これで叶ってしまったのでまた新しい目標を立てるとする。 自分のアウトプットに反応が返ってくる意味で登壇するのすごくよかったので、これからも機会あったらどんどん出してこ！
社会人2年目をエモめに振り返る
エンジニアとして2年めが終わったので振り返り。今思うことは今書いておかないと忘れちゃう。あと根がネガティブなので記しておかないと「私1年何やってたんだろう・・・」とすぐなっちゃうので。
ちなみに1年目の振り返りエントリは以下。
今年度の主なトピックは以下。
が大きな出来事だったかと思います。
Androidアプリのエンハンス
1年目は新規アプリの開発がメイン&かなり短いスパンでチームを移動していたので、同じチームで一つのプロダクトを開発し続けるという経験は初めて。新規ではなくエンハンスをする中でただAndroidの実装スキル以上のことを学ぶきっかけになった気がする。
ライブラリの導入
今までのチームはモダンなライブラリをいれよう！という話があまりなかったので、今のチームに異動してきてから同じチームの先輩にはすごく刺激をもらった。
Realm、ActiveAndroid、Retrofit、などまだ使ったことなかったライブラリなどを、今年初めて触ったり。導入を進める先輩にライブラリの特徴・思想を聞いたり、何が便利なんだっけ？を考えたりするきっかけになった。特に先輩がRetrofitにプルリク送っているところを隣で見れたりして、すごく刺激になった。 その後、自分でチームにLightStreamAPIを導入したりできて、ちょっとだけチームのプロダクトどういう風にしていきたい？という気持ちが芽生えてきた気がする。 ライブラリを導入すると、何をどうやって便利にするライブラリなの？を考えるようになるので、自分で設計を考えるときにも参考になるなーと感じる。リスクの方が語られがちだったり学習コストなども考えるとライブラリの導入などはハードルが高かったりするけど、設計方針などのインプットにもなるのを考えるともっと導入すべきだなーとも思うようになった。
変更に強い・バグを生みにくい設計
先輩にココらへんの話のインプットはすごくしてもらった。あまり今まで設計のことを考えたことがなかった。正確にいうと、既にあるアーキテクチャに従う練習はちょっとしてきたけど、アーキテクチャを選択する練習をしてこなかった。なんでこういうアーキテクチャになっていてなぜそれを選ぶ？という観点がなかったので、そこを養えたのはよかった。デザパタとかクリーンアーキテクチャの話とかなどなど。 以下の記事は色々インプットしてた時で整理してた頃。
あーちょっと恥ずかしくて見たくないエントリ…
テスト自動化
スクラムを再立ち上げした頃にユニットテストコードを書いていこうというルールになって初めてテストコードというのを書くことになった。 社内のアプリチームではテストコードを書いているチームがあまりなかったので良い経験になった。色々社内の先輩などに相談できる機会があったりなど、ただテスト自動化すごい！じゃなくてメリットやデメリット考えつつどう進めていったらよい？なことは考えるようになったかも。最初はデグレをなくしましょうという話からテスト自動化の話が始まった気がするけど、設計やリファクタの話につながっていくところまで考えられるようになった。 かなりここの分野も楽しくてこれからももっと知りたいなーと思ってる。
スクラムチームの再立ち上げ
スクラムチームをどう立ち上げてどうなったかはこちらのエントリで。
上のエントリに書いたとおりスクラムチームの再立ち上げを2回経験していて。2回やってようやくスクラムの良さみたいのを感じれた気がする。すごく今はアジャイルの考え方の虜になっていてここの分野ももっと知りたいなと思っている。 元がコミュ障で人の言うことをすごく気にしてしまうので、チームの環境によって自分のキャラを出せなかったりパフォーマンスも左右されてしまうんですよね。そういうところをスクラムとかのアジャイルフレームワークは多少でもカバーしてくれる気がしている。なので自分にはすごく合っていたのかも？と思ってる。
コーチの人に言われたことで印象に残っているのは 「問題解決は簡単だ、解決方法はいろんなひとが試しているからそこらじゅうに転がってる。大事なのは問題発見する能力。ここが長けている方が価値の高いことなんだよ」 というようなことを言われたこと。問題発見したからやばい、もうダメなチームだ、じゃなくて問題が見つかったってことは今まで見つからなかったことが問題として見つかったのは良いこととポジティブに言われたことが自分の中でも改善に対する捉え方が変わった出来事だったと思う。
プライベートでのアプリ開発
2年目になって1年目のように資格勉強に時間取られることもなくなったので、プライベートでサービス開発しているチームにjoinしました。Androidアプリ作りたいけどちょうど人がいないという時に誘ってもらって、タイミング良かった。 これまで社外でこういったコミュニティがなかったので、違う会社の話を聞けたり視野も広がったり。
業務で試せてないライブラリやツールを試せる機会になったり、業務とプライベート複数同時にプロジェクトを進められる良さを知れた。一つ自分が作ったプロダクトができたのもうれしい。 その後自分一人でもう一個アプリ作ってみたのも勉強になった。CI自分で回したり自分でストアにあげたり。アイコンも自分で作ったり。自分が作ると他のアプリも注意深く見るようになるなー。自分だけでやってるので放置になりがちなのが反省点。
外部イベントへの参加
これも2年目になって業務都合をつけやすくなったので、ちょこちょこ外部のイベントにも参加するように。同じ年代の人がLT登壇とかしていてやばい！！！と良い刺激にも。
去年も行きたかったけど行けなかったDroidKaigiにも今年初参加！ 他の会社がどんなことに取り組んでいるのか、最新技術等やっぱり行かないとわからないことがたくさんでとてもよかった。登壇にも挑戦してみたいなぁ。
今年はDroidKaigiの公式アプリにもコントリビュートすることを目標にしていて、本当にちっっちゃなBugFixだけど英語でプルリク出してみたり。いつもtwitterで見るアイコンの人がコード見てくれて当日のContributersスライドにアイコンが載ったり。かなりうれしかった出来事。
今年度の最後にはJJUG CCCの登壇も決まり準備をそろそろ始めなきゃという感じ。去年はおっかなくて周りの人に投票なんてお願いできなかったけど、背中を押してくれる先輩もできて、いろんなコミュニティに投票をお願いできたり、良い関係のコミュニティが増えたんだなぁと感じて、前向きに色々がんばれてるなと思う。
その他
そういえば応用取ったし次は高度受けるかっつってネスペを受けたけど午後で落ちた。情報処理試験はいつも勉強がつらい。
後はちょっとしたクリエイティブ。
後は会社でOSS勉強会なるものに参加したり(先輩のコードでnodeにプルリク送ってみたり)、外部の会社のエンジニアとTDD的な勉強会でGo触ったり。 刺激！な1年だったのかも。
まとめ
会社の先輩にこんなこと言われたのが印象的でそう信じてる言葉。
「エンジニアはやればやる程知らない事が増えていく。知らない事が減るってことは成長していないということだから、知らないことが増えていくことは良いことだと思って！」
この1年も色々新しい世界を知れて楽しかった！特に周りの人には恵まれていたなと思っていて、良いまさかりをたくさんもらえたなー。相談できる人も増えたしかなりのびのびやらせてもらえたと思っている。まだまだ技術力は低いと言われているのが悔しいところで、そこはこれからも伸ばしていきたいところ。
今年は取り組んできたことをブログなりなんなりにアウトプットすることを重視してきた気がする。ちょっとブログを読んでくれる人が増えたりして、自分のことを知ってくれる人がいるのはうれしいなーと思ったり。あと精神安定的にも◎。 今年は、ブログだけじゃなくてもっとコード書いてアウトプットしなきゃな。
次はどんな1年になるんだろう！3年目もがんばるぞー！
テストについて相談しにいった内容をまとめる
チームのテストについての進め方についてアドバイスをもらう機会があり、これからの進め方についても参考になったのでまとめる。
前提・背景
- アプリ開発チーム。
- Model,Controllerは必須で単体テストを書くというルールで開発している。
- 振る舞いテストも一部コード化してリリース前に自動で回している。
今のチームでの課題
- 単体テスト書いてきたが、なかなかメリットが享受できていない気がする
- ふるまいテスト書いてみたはいいが、この先どう展開していくのが良いのだろう？
- viewにビジネスロジックが積まれていてなかなかテストが書けない。構造見直ししたいがアーキテクチャの指針なくできない。
viewにビジネスロジック問題
viewにビジネスロジックが書かれていてテスト書きづらい。 どうにかしたいが、リファクタするにはテストがいる。 じゃあテスト書きたいけど書きづらい！の堂々めぐりになってしまう問題。
実装の構造に依存する・実装に近いテスト（例：ユニットテスト）は書きづらいので、実装から遠いテスト(例：ふるまいテスト）を書いてリファクタする準備をまずしましょう、というのが次のアクション。なるほど！
振る舞いテストで安心してリファクタできるようになれるのか
たしかに、怖くてリファクタできない！けど構造変えなくては！の打ちてに対して実装に依存しないようなシステムの外からのテストを書けばよい！というところには納得。 現状、今のチームではアプリをリリースする前に毎回行っているアプリの根幹の機能(主に遷移周り)のテストを書いている。でも、粒度もすごく大きいテストケースなので、それで安心してリファクタできるイメージが湧きません！
それに対してのアクションは、まずカバレッジをとりましょう。まずどこがカバーされているテストがあるのか、どこのコードが通っているテストがあるのかを可視化する必要がある。テストが通っているところから構造変えていくようにすればよい。
この話をふまえると、これから構造よくしていきたいところにユニットテストを書いていくより、ふるまいテストの拡充を優先度を上げた方がいいのだろうな。まずは外から、だんだん中に入っていってカバレッジなどをあげていく。 今までカバレッジなどは気にしないで「書けるところを書いていこう」の指針でずっと来てしまったので、きちんと数値とっていかないとダメですね。
振る舞いテスト(≒スモークテスト）の運用
今チームの中で振る舞いテストと言ってるものは「スモークテスト」と呼ばれる「このテストが落ちると、リリースしてはいけないというレベルのもの」になる。 このスモークテストを今までリリース前に最後のチェックとして行ってきた。本当はリリース前に煙が出てもしょうがないので、普段から本当は回すべき。プルリクがマージされた時などに自動でテストが回るような仕組みにしておくと早めに重大な問題に気づくことができてGood!
アーキテクチャ決まってない問題
アーキテクチャに関しては最初は「王道なもの」を採用してやってみると良い。同じ挑戦している人の人数も多いし、ぶつかった人も多いので、導入もしやすいだろう。MVPならMVPと決めてやってみると処理を書く場所があらかじめ決まっているのでテスト書かなきゃいけない処理も決まってくる。一回入れてみて問題が出てきたらまた考えても遅くなさそう。
[おまけ]テスト自体は品質をあげるものではない
テストコードを書くこと自体は 品質をあげるものではない。 テストコードを書くことで、プロダクションコードに影響を与える（リファクタできれいになる、使いやすいように引数の種類変えてみようかとか）ことで品質があがっていく。なので、テストコード書いてプロダクションコードが変わらないのは別に品質あげてないよ。もちろんデグレを防ぐみたいな役割もあるかもしれないけど、品質はあがってないよね、下げるのを防いではいるけど。 という思想があるので、テストファーストに越したことはないが、テストファーストをするためにはプロダクトの実装の仕方（構造が悪いとか）にも寄るしある程度のスキルが必要なので、テストファーストにこだわらなくてもよい。大事なのはプロダクションコードにプラスの影響を与えられているか。
[おまけ]mock使う派？使わない派？
テスト駆動開発界には流派が2つあるらしく、mock使う派(テストは分離した方がよい）と使わない派(本物のデータを使う方がよい)とがいるらしい。
mockする派
テストしたいクラスを狭めることができる。mockしていなかったら依存しているクラスの中もテストしていることになるけど、mockすると純粋にそのクラスのロジックをテストできる
mockしない派
自作自演のテストになる可能性がある。mockしている実体が変わったら意味がなくなっちゃうから。テストは通るけど結合したらうまくいきませんーみたいなことが起きてしまう。 最近のmockライブラリは強力なので、なんでもできてしまう。そもそもmockが必要になるというのは設計としていかがなものか？を気づく基準にもなるけど、強いmockライブラリがいるとスルーしてしまう可能性。この話は先輩からも聞かされたなぁ〜。
さいごに
今までどう打ちてを打っていいかわからないところをアドバイスもらえて次の一手が見つかった気がする。テストの世界では当たり前の考え方なのかもしれないけど、ぺーぺーの自分にとってはすごく有益なアドバイスをいただける機会でした。
#droidkaigiに行ってきて思ったことをダラダラ書いてみる
初めてDroidKaigi参加したので、ちょっとまとめるのが遅くなってしまったが記憶が新鮮なうちに考えていたことを残しておきます。 https://droidkaigi.github.io/2017/timetable.html
参加したセッション
参考までに参加したセッションは以下。
How to apply DDD to Android Application Development
リリース自動化と効率のよいリリースフローを求めて
インスペクションとAndroid Lint Custome Ruleによる、単一責任実装の実践
Data Bindingで開発を気持ちよくしよう
Android Resources Refactoring
オフラインファーストなアプリケーション開発
How to remodel current testing environment
What's New in RxJava 2.0
Android ORMの選び方
How to implement material design animation
Kotlin + RxJava + Dagger2 + Orma + Retrofit で作るAndroidアプリ
2つのアプリ、1つの設計のデザイン指針
エンジニアが武器にするMaterial Design
LayoutManagerをつくろう
特に強く印象に残ったこと
特に印象に残ったテーマを以下に記していきます
オフラインファーストなアプリケーション開発
https://speakerdeck.com/zaki50/ohurainhuasutonaapurikesiyonkai-fa Realmすごい…。今のチームでもRealmいれてるけどバージョンが昔すぎて全然キャッチアップできてないことがわかった。 オフラインの時の体験を考えるってアプリならではの観点だから新鮮＆そこにも踏み込んで考えていけるのがアプリのいいところ。
実際今のアプリってどれくらいオフラインファーストにされているんだろう
すごくこのセッションの内容に刺激を受けたので、オフライン状態で今のアプリがどれくらい使えるのか触ってみた。
- Facebook、instagram、googleフォト、メッセンジャー、Google Play Musicはオフラインでもだいたい使える
- instaは前に読み込んでいた10件くらいはオフラインでも見えるようになってる。追加読み込みだけできない。
- twitterは微妙。ツイートはできる（iphoneのみ）けどタイムラインは見れない
- Google Play Musicはすごくて、自分の評価した曲はオフラインでも聞けるようになってる。おかげで端末が圏外であることに気づかなかった。
今のチームのプロダクトはどうなんだっけ
アプリの業務仕様上最新の情報を常にリクエスト投げて確認しなくてはいけないので、通信エラーにすごく厳しいアプリになってる（オフライン時は通信エラーダイアログが出てで画面遷移できない）。オフライン時にアプリを立ち上げるとマジでなにもすることができないアプリになってた。
今まで「通信状況の悪さ」はアプリでは担保せず、ユーザーの状況が悪いんだよというふうに伝えてきた。けどこういう簡単に実装できるプラットフォームが出てきたりすると、通信状況というのはユーザーの責任ではなくアプリの責任になっていくのではないか？本当は通信エラーで画面遷移できないとかは、こっちの勝手な仕様のためにユーザビリティ落としているってことになるんだよなぁ。
なのでこれからはより通信状況に依存しないアプリの操作体験を作っていかなきゃいけなさそう、作っていきたい。 実際有名なトップレベルのアプリはオフラインでもある程度操作できるようになっているし、通信状況がないこともとても控えめに伝えるようになってる。気づきそうで普段意識してない観点を考えるきっかけになってよかった。
エンジニアが武器にするMaterial Design
https://speakerdeck.com/seto_hi/enziniagawu-qi-nisurumaterial-design webと比較してアプリのデザインてグラフィカルなスキルだけでなくOSの標準の挙動とかOSが推奨しているデザインも把握していなきゃいけないよね→かなり負担なのでは？というところからアプリのユーザー体験みたいなところにエンジニアがもっと関わっていこうよ、というお話。特に、Androidは「iOSのデザイン、これAndroidにして」事件が多発しているし同じ課題を持っている人は多そう。
KPIの置き方のはなし
企画の人にとってはKPIに直つながる案件をしたいというのは当たり前なんだけど、時たま「ユーザビリティを多少落としてでも」アクションがあがる施策をやる判断になってしまうことがある。そういう時にわかってはいるんだけどもやもやするという経験があって、そういう時に「いやいや、ユーザビリティ落とすのはダメでしょ、なぜなら」を言えるエンジニアになりたい、けど言えない&うまく説明できない自分。この答えの一つが「エンジニアが武器にするMaterialDesign」なんだと思っている。本当はユーザビリティがKPIにつながっていること&重要さを証明できればいいのだが、現状難しいのかも。
キャリア戦略として
自分の会社はいわゆるグラフィカルデザイナーとUXデザイナーが別職種としているので、エンジニアがUXのところまで踏み込む武器のつけかたを見たことがなかったので、すごく刺激的だった。自分も興味がある分野だったので、これからどこ武器にしていくんだっけ？の参考にとてもなった。もうすごくステキな話で本当に聞きに行ってよかったと思った。
その他
他の会社の開発環境が聞けるの、すてき
なかなか会社内にいると開発環境も似たり寄ったりなので、他の会社の開発環境が聞けてとても刺激的だった。世の中のプロダクトがこんなにRxJavaやDaggerなどの今時のライブラリを使って開発してるとは…。ライブラリを入れる入れないはちゃんと判断が必要だけど、若干の悔しさを感じて帰ってきた。
企業ブース、すてき
CyberAgentのブースで看板サービスのbuild.gradleを公開します！という企画をやっていて、開発イケてます！ということがよく伝わってうまいプロモーションだと思った。転職考えてたら絶対候補にはいると思う笑
他にもいっぱいノベルティもらってとにかくはしゃいできた。
アプリのOSS化、すてき
あとは今年はDroidKaigiのアプリにコントリビュートするぞ！と決めていて、なかなかレベル高くてひよっていたけどちっちゃいバグフィックスでコントリビュート達成した。いつもネットで見ているアイコンの人たちにコメントしてもらえたり、コントリビューター一覧に名前が載ったり、はかなりモチベーションあがった（マージされた夜は興奮してしまって眠れなかった）。ただの参加者からDroidkaigiに自分も関わってるんだぞ！と思える感じ、最高。
まとめ
DroidKaigiのセッションはスライドも動画も後で見れるのだがやっぱり当日行って全部の時間なにかしらセッションを聞きに行くのがすごく良いことだよなと思っている。後で動画で〜だったら自分の知っている範囲で課題感持っているところしか見ないと思うので、新しい分野を聞きに行く点で生で参加するメリットはあると思う。アフターパーティに出れなかったのが残念。
ということですごく良い経験をしました。来年も参加したい。今後は登壇にもチャレンジしていきたい！
