heihei blog

Write once, recall anytime. 自分のために書く 📝

2018年4月を振り返る

2018年も約35%が終わったようです。( ゚∀゚)・∵. グハッ!!(洒落にならない) ※5/3(木)時点

先月に引き続き、振り返ります。

4月やったこと

Google I/O 2018 Pre-Partyに参加した

昨年度参加した経験から絞り出したTipsを紹介しました。内容は下記です

  • Office Hourを有効活用してGooglerに質問したりニーズを伝えたりしよう
  • Sandboxでの展示などを見よう
  • 「お土産」があるかもしれないので荷物の空きスペースには余裕を持とう
  • パーカーなど会場でのお土産は早めに買おう

Tips for Google I/O 2018 // Speaker Deck

去年Twitter上でOffice HourにGooglerに質問する内容をください、という旨のツイートをしたら会社の後輩や同期からメンションいただけて少しだけでも役に立てたかなと感じたので今年も同じように質問を集めています。今のところ試しにGoogle SpreadSheetを使っています。どなたでもお気軽に記載していただいて構いません。質問はあるけどここに書くのは気が引ける、こんな質問していいのかな?と悩んでいる方はDMでもくださればと思います。

docs.google.com

初技術書典

技術書典にて、Coupling Union Android愛好会というサークル名で本を出しました。Coupling Unionについては下記を御覧ください。

CyberAgent COUPLING UNION - CAグループが運営するマッチングサービスの情報メディア

Google Tasks APIやAccount Hold, Okioについて3人でそれぞれ執筆しました。

初めての技術書典で反省ばかりでしたが、控えめの部数だったとはいえ完売できて嬉しかったのと、もっと早く、かつきれいで分かりやすい文章を書けるようになりたい、と改めて思いました。貴重な経験でした!仕事の時期などはもちろん見極める必要はありそうですが、ぜひまた参加したいです。完売後の日本酒は本当に最高だった。(飲みすぎました。)

その他

  • 新しいプロジェクト

今、新しいプロジェクトで数年運用されているAndroidアプリケーションの開発を担当しています。色々もっと良くしていきたいことがあるので、頑張るぞ!

  • Ready Player Oneを観た

4.6 / 5!面白かったです。2Dで観たので、3Dでもう一度観たい。

www.youtube.com

以上になります。4月もお疲れ様でした!

Android関連のユティリティークラスやヘルパークラスの命名などについてざっくり調べてみた

TL;DR

  • ユティリティーとヘルパーの違いは曖昧
  • ユティリティークラスはプライベートコンストラクタを持ちstaticメソッドを公開しているパターンが多そう
  • ユティリティーパッケージ、ユティリティークラスやヘルパークラスの命名には単数形(~Util / Helper)を用いるパターンと複数形(~Utils / ~Helpers)を用いるパターンがある
  • ヘルパークラスはutilパッケージ内部に定義されているパターンが多そう
  • とはいえ、ユティリティークラスやヘルパークラス、またはそのパッケージの命名に関してはチームの中で統一された考え方がありみんな納得感あればそれで良さそう
  • うちのチームだとこうしているよ、というような知見の共有などいただけると幸いですm(__)m

ユティリティークラスとヘルパークラスの違いって曖昧だな、と、最近モヤモヤと感じています。

よくよく考えてみると、「ユティリティークラスとはこういうクラス」、「ヘルパークラスとはこういうクラス」というふうに深く意識したことがあまりなかったです。それはそれでどうなのよ、という意見もあるかもしれません。なぜ意識しようと思ったかというと、最近担当しているプロジェクトのユティリティークラスのコードを読んでいた時に「この関数はユティリティークラスにあるべき関数なのかな?」とふと疑問に思っている自分がいたりしたからです。なのでまずは自分なりの考えをまとめてよう、と思った次第です。

先に書いておくと、言語、プラットフォーム、もしかしたら時代によってもユティリティークラスとヘルパークラスの違いや考え方が異なるかもしれないです。今回はAndroidアプリケーション開発にフォーカスしています。

  • 別に困らないからそこまで違いを意識する必要ないのでは?
  • ユティリティークラス、ヘルパークラスは悪だ!
  • 拡張関数でええやん
  • 不毛だな(゚∀゚)

という意見もあるかもしれませんが、ここではあまり意識していません。コメントでもTwitterにてメンションやDMでも良いので、勘違いやご意見、うちのチームだとこうしているよ、というような知見の共有などもしありましたらいただけると本当に嬉しいです!

そもそも

以前、一人で開発を担当していたプロジェクトでは、ユティリティークラスはアプリケーション独自の仕様への依存がなく、どのアプリケーションにも転用できるようなstaticなメソッド群を定義したクラス、ヘルパークラスはアプリケーション独自の仕様だったり特定のライブラリに依存したstaticなメソッド群を定義したクラスと定義していたつもりでした。改めて見返してみると、常にこの定義に沿っているわけではありませんでした。。

改めて、ユティリティークラス、ヘルパークラスとはなんだろう、ということで検索してみました。

まずはユティリティークラスから見ていきます。たくさんの記事がヒットしましたが、Quoraの記事の回答を引用します。

What is a utility class? - Quora

A utility class is one which:

  • Has no state (fields) of its own, so all the methods can be class methods (static) rather than object methods (requiring an instantiation of an object)
  • Provides methods for multiple other classes (shared code)

上記Quoraの回答によると、

ユティリティークラスは、下記に該当するクラスだそうです:

  • 独自のstateを管理せず全てのメソッドがクラスメソッド(static)にできるクラス
  • 他複数クラスへメソッドを提供するクラス(shared code)

ヘルパークラスのほうも検索してみます。

stackoverflow.com

上記stackoverflowの質問では、helper "objects"という単語が使われています。もしかしたらヘルパークラスはインスタンス化して利用するクラスという認識が、質問を記載した方にはあるのかもしれないです。

stackoverflowの回答の1つを引用します。

These are objects that "sit to the side" of the main body of code, and do some of the work for the object. They "help" the object to do it's job.

ヘルパーオブジェクトは中心となるコードの隣で特定のオブジェクトのために仕事を肩代わりするオブジェクト。特定のオブジェクトの仕事の"手助けをする"オブジェクトである

というようなことが書いてありそうです。ヘルパークラスがなぜ"ヘルパー"なのかはなんとなく理由がつきそうです。この記事ではヘルパークラスという呼び方をしていますが、もしかしたらヘルパーオブジェクトという呼び方がより一般的なのかもしれないです。

Androidフレームワークのコードを参考にしてみる

ここでAndroidフレームワークのユティリティークラス、ヘルパークラスをそれぞれ参考にしてみます。

Util / Utils

Search results for "util"   |   Android Developers

ユティリティークラスに関してAndroid Developerサイト上で検索してみると、java.utilパッケージ内のクラスがたくさんヒットします。代わりに、GitHub上のAOSP mirrorのほうを見てみます。utilパッケージを覗いてみます。

github.com

クラス群の命名に注目してみると、下記に気づきました。

  • Utils接尾語がついているクラスがちらほら
  • Helpersクラスも一つだけ(ContainerHelpers.java)
  • JsonWriter、Logなど、UtilsやHelpers接尾語がついていないクラスがほとんど
  • プライベートコンストラクタが定義されていてstaticクラスとして利用するものが多いですが、インスタンス化して利用するクラスも含まれている

次はSupportライブラリのcore-utilsを見てみます。

github.com

NavUtilsColorUtilsMathUtilsのようにUtils接尾語が付与されているクラス名もあれば、そうではないクラス名もあります。また、AOSP mirror同様、Helperクラス(PrintHelper)も内包されています。

Square社のOSSのコードを参考にしてみる

次はAndroid界隈では有名なSquare社のOSSのコードを参考にしてみます。(ここでは取り上げているライブラリについての説明などは記載していません。)

OkHttp 3

OkHttp 3にはinternalパッケージ配下にUtilという名前のクラスが存在します。

github.com

プライベートコンストラクタが定義されています。internalパッケージ配下に存在しますが、定数やメソッドはpublicスコープなのでアプリケーション側からも呼び出しができそうです。

/** Junk drawer of utility methods. */
public final class Util {
...

というコメントがあります。個人的にはユティリティーメソッド群を寄せ集めしただけのクラスなのかなという解釈をしています。

Picasso 3

Picasso 3にもユティリティークラスが存在します。こちらはUtilsという名前です。

github.com

Picasso 3のUtilsクラスにもプライベートコンストラクタが定義されているため、staticメソッド呼び出しのみの利用が想定されています。Picasso 3のUtilsクラスは、クラス自体やメソッドが全てパッケージスコープとなっているようです。余談ですが、もともと依存があったかどうかは調べきれていませんが、Picasso 3のUtilsクラス内部ではOkioのクラスが利用されていることがわかります

Okio

Okioにもユティリティークラスが存在します。Okio 2に向けてKotlin化作業が進み、UtilクラスはKotlinで書き直されています。OkioはOkHttpと同様、Utilというクラス名が採用されています。

github.com

まとめ

もうまとめなの!?ヘルパークラスはどうした!?と思われるかもしれませんが、体力が尽きそうなのでこのあたりで身勝手にもまとめさせていただきます。

Androidフレームワークや著名なOSSライブラリを複数開発するSquare社のソースコードを参考にと思い読んでみた結果、個人的には下記のことが分かりました

  • ユティリティーとヘルパーの違いは曖昧
  • ユティリティークラスやヘルパークラス、またはそのパッケージの命名に関してはチームごとに統一された考え方があれば良さそう
  • ユティリティークラスはプライベートコンストラクタを持ちstaticメソッドを公開しているパターンが多そう
  • ユティリティーパッケージ、ユティリティークラスやヘルパークラスの命名には単数形(~Util / Helper)を用いるパターンと複数形(~Utils / ~Helpers)を用いるパターンがある
  • ヘルパークラスはutilパッケージ内部に定義されているパターンが多そう

前プロジェクトではhelpersパッケージ内に~Helperクラスを定義していましたが、AOSPの場合、utilパッケージ内部にヘルパークラスを内包するパターンが多く見られたのが意外でした。きっとユティリティーという概念の中にヘルパーという概念が存在するのだろうな、というふんわりとした印象を覚えました。

とはいえ、調べてきた上で「けどやっぱりutilパッケージとhelperパッケージわけたほうがよくないか」という考えだったり「クラス名の単数形、複数形は統一したい」「パッケージ名に関しては複数形にしたい」というようないわゆるエゴのようなこだわりのようなものは消えていないので、これからもチームの他のメンバーさんたちと議論しながら納得感持って開発していきまっす。

改めて、うちのチームだとこうしているよ、というような知見の共有などもしありましたらいただけると嬉しいです。

以上です!

2018年3月を振り返る

2018年も約27%が終わったようです。( ゚∀゚)・∵. グハッ!!(洒落にならない) ※4/7(土)時点

先月に引き続き、振り返ります。

3月やったこと

Droidcon Bostonに登壇者として参加した

3月はこれが自分にとっては一番大きなイベントでした。海外で登壇することも初めてだし、Droidcon Bostonへの参加も初めてだったので不安もありましたが、カンファレンスの登壇者や参加者、ボランティアの方々がみんな優しく、カンファレンス自体に関しても、大規模というよりはどちらかというとアットホーム感が漂う感じでそれもまた良かったです。現地のエンジニアの話(技術・生活周りなど)の話もできたことも、改めて振り返ってみてとても良かったと思います。

肝心の発表に関しては振り返るともちろんあーもっとこうしておけばよかった、とか掘り出せばきりがないのですが、DroidKaigiのときよりも落ち着いて発表できたことと、しっかりと参加者の方々から質問をしていただけたことは振り返ってみても嬉しいです。とはいえ、もちろんもっとうまくプレゼンできるようになりたいのは変わりないので、こればっかりは引き続き色々な上手な方々のプレゼンを聞いたり見たり、アドバイス頂いたりして精進したい所存です。

Droidcon Boston参加に至るまでの経緯や細かい振り返り等に関しては下記記事に記載していますので興味ある方はどうぞ:

blog.shaunkawano.com

技術書典

ウッ…だいぶ遅れ気味ではありますが、、CU Android愛好会、初めての技術書典、頑張るぞー!楽しむぞー!(オー!)(ユルイ)

その他

  • ゆるキャン△した

「手ぶら温泉キャンプ」ということで、埼玉県神川町にあるロハスガルデンキャンプ場にいってきました。会社の同期3人と自分の男4人でゆる〜く。カレー麺もちゃんと食べました(๑•̀ㅂ•́)و✧

埼玉県神川町の手ぶら温泉キャンプ・ロハスガルテンキャンプ場

  • 映画「さよならの朝に約束の花をかざろう」を観た

壮大なストーリーで、時間もわりと長かった気がする。いろいろな意味でリアルだな、と感じた。良かった。(雑)

sayoasa.jp

まとめ

その他、業務では新しいチャレンジをさせてもらえることになったり、いろいろな変化があった3月でした。

エンジニアとして技術力をもっと伸ばさねばとは常々思っていますが、改めてインプットを増やしていかないと、と感じました。4月も精進します。

以上です!3月もおつかれさまでした!

Droidcon Boston 2018に登壇者として参加した

3/26(月)、3/27(火)の2日間、ボストンにてDroidcon Boston 2018というAndroidエンジニアのカンファレンスがあり、登壇者として参加してきました。

  • 3キーノートスピーチ
  • 24セッション
  • 6ライトニングトーク
  • 5ワークショップ

がありました。

自分が発表した内容は、まとめの内容や細かい変更を除いて、着地ほとんどDroidKaigiにて発表した内容と同じものでした。スライドはこちらです。

TL;DR

ざっくりと本記事の内容を箇条書きでまとめています。

  • 初めての海外カンファレンスでの登壇は難しかったし反省もあるけどそれ以上にみんな親切だしまた行きたいと思えた
  • 発表を聞いている際、誰もTwitterみたり書いたりしていない・発表後めちゃめちゃ質問する
  • 海外の方々は素敵な、喜びあふれる言葉をまんべんなく使って本気で褒めてくれる

他人に質問して答えてもらったこと・聞いた話

  • MVVM, MVPなどが主流
  • FlutterはまだHello Worldしたけどー程度の人が多かった
  • MVIに興味がある人が増えている印象(個人の感想)

以降では、CFPを出すまでのきっかけ、だしたあと出発、そして登壇までの流れを時系列にまとめています。後はカンファレンスを通して感じたことなどをつらつらと書いています。

🔦きっかけ

AndroidStudyGroup/conferences

AndroidStudyGroup/conferencesのレポジトリには、世界中のAndroidに関するカンファレンス情報が一覧化されて掲載されています。DroidKaigiのCFPを出して少し経った頃、この一覧をふと眺めていた時にDroidcon Bostonを見つけました。

もともと「海外カンファレンスで登壇してみたい」という思いはありつつも、「きっと倍率は高いし通らないだろうなぁ」という気持ちしかありませんでした。

が、DroidKaigiでは、Fluxについて英語で発表する予定でしたので、ダメ元で同じCFPで応募してみよう、という流れでCFPを出しました。

⏰待っていても何も来ない連絡

案の定、カンファレンスの運営の方から特に何も連絡がこなかったときは「やはりダメだったか」と思いました。しかし、いくら待っても運営からは何の連絡もありません。自分のCFPが採択されなかった場合も、そのうち連絡が来るだろうと思っていたので、待っていても何も連絡がこないので「おや?」という気持ちになり始めました。

🐦来ないなら自分から突っついてみる

「おや?」「もしかして、何らかの理由で自分のCFPが閲覧されていないのでは?」という気持ちを払拭するために、カンファレンス側に連絡をしてみることにしました。カンファレンスのウェブサイトにお問い合わせフォームがあったのでそこから問い合わせをしてみました。

2営業日ほど経っても連絡が来なかったので、今度はOrganizerの方にTwitterで個別で連絡してみることにしました。カンファレンスのウェブサイトにはOrganizerやVolunteerの方々の情報が掲載されていたので、ダメ元で連絡。

f:id:shaunkawano:20180402193028p:plain

個別に連絡した結果、以下の内容のような返事をもらうことができました:

「もう発表しようと思っている内容の少し詳細を教えてくれる? 発表内容の詳細を理解した上で採択するかどうかを改めて考えたい。」

検討してくれるらしい。

そして、登壇したら話そうと思っている発表内容についてや自分なりの思いをぶつけて、最終的には採択されることになりました。

🎒準備

採択された後は、渡米の準備を少しずつ行っていきました。下記にざっと記載します。

  • 飛行機の予約(Expediaでゆるく調べ、直行便を選びました)
  • ESTAの取得(前回取得済みのESTAがまだ有効だったため、今回は不要でした)
  • Airbnbの予約(初めてのAirbnb。結構楽しみでした)
  • そのほか現地の情報について調べる

また、この準備期間中にDroidcon BostonのOrganizerの方からDroidcon BostonのSlackチームへの招待があり、Slack上で他のSpeakerの方々とお互い自己紹介しあったりしました。

f:id:shaunkawano:20180402115046p:plain

運営の方々もこのSlackを使って連絡し合ったり準備をすすめていて、カンファレンス開催のギリギリまでウェブサイトの情報更新だったり、「Wifiが今のままだとキャパオーバーしそうだ、どうしよう!?」「録画って今の準備で問題ないよね? もう少しボランティアの人増やす!?」みたいな慌ただしい報告が飛び交っていて、カンファレンス運営というのは本当に大変なことなのだなと感じました。(DroidKaigiの皆様改めてありがとうございました!今も動画の確認やアップロード作業お疲れ様です。m(__)m)

一方で、「Tシャツ届いたよー!! YEAH! AWESOME!!」という報告だったりカンファレンス前日は「Speaker Partyやるよー!!」という盛り上がる内容のメッセージもたくさんありそのたびにスピーカーや運営の方々がリアクションを飛ばし合っていて、リアルタイムでカンファレンスが構築されていく様を目の当たりにできて、気分が高揚してきていました。

✈️出発

いよいよ日本から出発。と言っても、1日早めに出発をし、まずは観光目的で日本→ニューヨークの飛行機でニューヨークへ行きました。友人宅にお邪魔をさせてもらい、観光をしました。

その後、Amtrackという新幹線のようなものに乗って3-4時間ほどかけて、ニューヨーク→ボストンへと移動しました。

ボストンのホテルに着いたその日に、Speaker Partyに参加しました。

Speaker Party

f:id:shaunkawano:20180402115126j:plain

f:id:shaunkawano:20180402115133j:plain

Speaker Partyには登壇者、Organizer、Co-Organizerの方々、そして運営ボランティアの方々が参加しました。

日本人の登壇者は自分だけだったため、Speaker Partyではぼっちになるかもととっても不安でした。が、一人のボランティアの方がすぐに声をかけてくれて、その人がまた別の人を呼んできてくれて、と、すぐに数名の方々と喋ることができ、最後までいろいろな人とコミュニケーションすることができました。

運営ボランティアの方々はやはり現地の方が多いようで、Speaker Partyで喋った方のほとんどの方が現地ボストンに住んでいました。(住みたいなぁ、ボストン。)

me: Flutterって流行っている?

ボストンエンジニア: Hello World!くらいは書いたけど、それ以上はやれていないな〜

me: 日本だと転職するとエンジニアの給与が上がりやすい傾向にあるのだけど、海外でも同じ?それが理由で転職するということってよくある?

ボストンエンジニア: みんながみんな、というわけではないけど、一定数いるのはたしかだね。

というような会話もしてきました。以外とアメリカだからこう、というはっきりとした違いがあるのではないのかも、と感じました。

カンファレンス

会場

会場は、The Calderwood Pavilion at the Boston Center for the Artsという、普段は芸術舞台に使われている、趣のあるような場所でした。

f:id:shaunkawano:20180402115139j:plain

セッション

いずれセッション動画が公開されると思いますが、個人的には下記のセッションをききました:

  • Tips for Library development(Keynote)
  • Design + Develop + Test(Keynote)
  • Common Poor Coding Patterns and How to avoid Them - Pinterest
  • Why MVI? - Fueled
  • Optimization Strategies at Instagram - Instagram

個々のセッションを振り返ることはしませんが、個人的にはKeynoteはエモいものが多く(iOSと同じデザインにしてくれ!と言われたらどうする?という話など)、 あとはMVP+Event busの既存プロジェクトにてデータの不整合などが発生し状態管理がうまくいっていないことがわかった。ここからどのように改善したか、もしくはどのようにこれを防ぐように改善したか、という話、またはMVIに関する話もありました。

MVIについての発表はDroidKaigiでも発表がありましたが、Droidcon Bostonにおいてもオーディエンスの数が多く、認知度が高くなっていて気になる人も増えてきているアーキテクチャなのだな、という印象でした。

とはいえ、MVIの発表後数名に話を聞いたところによると、現状としてはMVVMやMVPが主流である印象でした。

気づき

ここでは海外カンファレンスで登壇してみて、海外カンファレンスそのものやアメリカの文化とも言える部分について、気付いたことをいくつか、つらつらと書きます。

能動的オーディエンス

まず、海外カンファレンスでは殆どの人はスマートフォンやMacを開いたり、見ていたりしません。殆どの人が登壇者の目を見て話を聞いている印象でした。これはもしかしたらカンファレンスの規模にもよるかもしれませんが、明らかにスピーカーの目を見て聞いている人が日本のカンファレンスとくらべて多かったことは確かだと思います。

そして、Q&Aの時間では、必ず一人は質問をします。だいたい2−3人は質問していました。これももしかしたら、規模が小さいからだったのかもしれませんが、それでも多くの方が、時には鋭い質問をしていて、しっかりと聞いているなと思ったことと、決して自分の疑問は質問するに値しない、とは思ったりしていないと感じました。そして実際に、多くの質問が参考になる、自分も質問したいなと思っていた内容でした。

オーディエンスの登壇者に対する姿勢や質問をみんながどんどんしていくあの感じというのは、日本ではなかなかないものだと感じました。

f:id:shaunkawano:20180402194225j:plain

素敵な言葉をまんべんなく使い尽くす

先程オーディエンスの方は時には鋭い質問をする、と書きましたが、とはいえQ&Aセッションが終わると、ものすごく褒めてくれます。

You are awesome!(君は最高!)

You are more than awesome!(君は最高以上!)

You changed my life!(君は僕の人生を変えてくれた!)

など、日本語では恥ずかしくて言えなそうなことでも、沢山の人が声をかけて本気で伝えてくれます。これは自分が日本人で、遠くからわざわざ来てくれたから、という気持ちもあったのかもしれませんが、他の登壇者の方々にももちろん同じようなかたちで伝えている方が多くいたため、僕だけではないはず。笑

こんな素敵な言葉を浴びせられたら、誰でも嬉しいです。ぼくもかなり嬉しかったです。お世辞でも嬉しい。

また最後には下記のようなカードをいただきました:

f:id:shaunkawano:20180402203355j:plain

まとめ

初めての海外カンファレンスでの登壇でしたが、想像以上に楽しかったしみんな優しくて最高でした。ここらへんは個人の印象ですが、Droidcon BostonはDroidcon NYCなどのより大きいカンファレンスとくらべて特にアットホーム感があり運営者との距離も近かったかもと思います。

英語での登壇はいつも反省だらけでもちろん今回ももっとうまくやれれば、、と反省し始めればキリがないですが、実際に質問したり話すことが上達への一番の近道いだと信じて改めて精進していきたいと思います。できればみんなで一緒にワイワイ精進できたら最高だなー何かいい方法ないかなーともんもんと考えていますが、こればっかりは場数を踏むのが一番良いのかな、とも思っていて何とも言えない感じです。

以上です!

2018年2月を振り返る

2018年も17%がすでに終わったようです。(恐ろしい)

先月に引き続き、やったことベースで振り返ります。

2月やったこと

DroidKaigiに初めて登壇者として参加した

僭越ながら、DroidKaigiにてFluxについて発表させていただきました。

登壇やDroidKaigi自体の振り返りについては、下記ブログ記事に記載しています。

blog.shaunkawano.com

登壇以外にも、上記記事には書いていませんが、1日目が終了したあとの懇親会にて@hakさんとお話できたのが個人的には良い思い出になりました。いつもhakさんの回をメインに聴いていることや、マッチングアプリ作ってます、お〜どんな感じのなんですか、というような会話をしました。またお話したいです。

他にもKaigiを通して色々な、普段はお話できない方々と新しい交流があったことが何より良かったなと感じています。

改めて、運営の皆様に感謝いたします。m(__)m


DroidKaigiでFluxについて発表したのでここでFluxについて余談ですが、先日、@magiepoohと宅飲みをしているとき(9割は「日村がゆく」を観てゲラゲラ笑っていました)にFluxの話になり、

ぷ「Flux人気になってきたよね」

hei「たしかに」

ぷ「Fluxにはいくつか(δ´ω`)カユイところあるよね」

hei「たしかに」

ぷ「今模索中なんだよね〜」

というような会話をしました。(「たしかに」しか言ってない自分)

(δ´ω`)カユイところの例としては、たとえば

  • 「Viewの状態」を管理したくなった場合にどこで管理するのか(Store?それ以外?)
  • Action/EventをDispatchしないけどActionCreator等に任せたい処理をどこに書くのか

などがあるかも、という話を2人でさらっとですがしました。

今後はそれを解決する形でまた新しい設計が出てくるのかなーと思いました。(「コレで行けるっしょ!」という方はぜひお話したいです〜)

余談以上!次。

DroidKaigi Reject ConferenceにてOkio & OkHttpについて発表した

DroidKaigiから一週間後、DroidKaigi Reject Conferenceがありました。そこで@stsn_jpさんと2人で登壇しました。

こちらについての振り返りブログ記事は下記です。

blog.shaunkawano.com

本記事にも記載していますが、資料準備が間に合わず、会場設営後、最後の最後まで資料作りをおこなっていました。

登壇はノリで決まり、もともと「OkHttpとかOkioとかの有名ライブラリの内部実装しっかり読みたいですよね!?」というところからでしたが、いつの間にか応募して登壇することが決まり、いつのまにかDroidKaigiが終わって「あれ、内部実装まだぜんぜん読めてないぞ!?」となり冷や汗しか出ていませんでした。ですが、登壇後は会場にいらした方々から「面白い」とツイートいただけて、どうにか楽しんで頂けてよかったかなという印象でした。

DroidKaigi Reject Conferenceに関しては最後の懇親会でも多くの方が残ってワイワイお話して楽しかったので来年もぜひ開催したいです。

技術書典のための執筆を始めた

今年の4月に初めて技術書典にて本を出します。職場の同じフロアで働くAndroidエンジニア数名で一冊、有志で出します。

書典では、Okioの内部実装について、15ページ〜20ページほど記載する予定です。 DroidKaigi Reject Conferenceで発表した内容は本当に一部分なので、枚数の許す限りガッツリ書こうと思います。執筆を始めた、といってもはじめたばかりですので、これから頑張ります。

ほかメンバー含めみんな初書典なので、お手柔らかにお願いできればと思います。m(__)m

その他

  • お金2.0を読んだ
  • CloudStudyJam行って初めてGCP, Kubernetesあたりを触った

最後に

今月末、Droidcon BostonにてFluxについて発表してきます。内容の大半はDroidKaigiで発表したものと重なるかもしれませんが、DroiconではDroidKaigiと比べ10分ほど発表時間が長そうなので、資料も更新しDroidKaigiで発表しきれなかった部分についても頑張って発表してこようと思います。リベンジ!

終わったら、経緯や振り返り系のブログを書こうと思います。不安もありますが、初Airbnbも楽しみですのでマイペースにやっていけたらと思います。 今月の振り返りは以上です!

2月もお疲れ様でした〜!

DroidKaigi RejectconでOkio & OkHttpの内部実装について発表した

f:id:shaunkawano:20180217192911j:plain

DroidKaigi RejectconでOkio & OkHttpの内部実装について発表しました

資料はこちらです:

https://speakerdeck.com/hei/step-by-step-okio-and-okhttpspeakerdeck.com

DroidKaigi Rejecton

connpass.com

準備期間としては、DroidKaigiが終わってから本日までの、1週間後と少しでした。

登壇までの背景

前々から有名ライブラリの内部実装読みたいなーと思っていたところ、週1で情報共有会をさせていただいているstsn_jpさんと2人で登壇しましょう!! という流れになり、DroidKaigiのニッチ枠で応募をしました。

ですがこちらのCFP通らなかったため、今回、DroidKaigi Rejectconで枠がまだあるという話をきいて応募させていただきました。

想像してたけど、想像以上だった

OkioやOkHttpといったライブラリは、最近のAndroidエンジニアであればきっと多くの方がお世話になっているであろうものです。 ただ、ここまで有名でありあがら、内部コードについての説明等はそこまでインターネット上を探しても見つからず、さらにJake WhartonさんやJesse WilsonさんのGithub Activityを見るに、日々活発に開発されているライブラリなだけに、詳細を知っておくことは大事そうだな、と感じていました。

DroidKaigi終わってから本当に少しずつ読み始め、前日、前々日から本格的にコールドリーディングと資料作りを始め、大きな題材のわりに準備期間が短かった、と反省せざるを得ません。コールドリーディングによって得た知見や今回発表できなかった内容などはまた別記事でまとめるとして、SocketやBuffer周りの処理だったり、ThreadなどJava始めた頃に勉強はちょっとしたけど最近ぜんぜん触っていない、意識できていなかったようなものに対する理解だったり、本当に基礎的なところで勉強しないといけない、と感じることが多々ありとても刺激的な準備期間だったと思います。

DroidKaigiの後だったこともあり、今回の機会がなければきっとここまでインプットできなかったであろうと感じています。

改めて、お誘い、一緒に応募していただいた@stsn_jpさん、運営等で大変お世話になりました@heki1124さん、@shihochanさん、改めてありがとうございました。

最後に

面白い!といってもらえて嬉しかったです!

STEP By STEPやっていきたい!(๑•̀ㅂ•́)و✧

以上です!

DroidKaigi 2018にて、Flux for Androidについて発表した

はじめに

DroidKaigi運営の方へ、本当にお疲れ様でした!!

たくさんの知見を共有する・してもらうだけではなく、初めて出会う方はもちろん、GitHubやTwitterでは知っていたけどリアルで話したことはなかった他のエンジニアの方々や海外出身の方々とも交流することができて、本当に楽しかったです。

f:id:shaunkawano:20180210115329j:plain
こちらは@pside氏作の周辺の音を聞き取り画面に表示するビジュアライザ

発表に向けて

DroidKaigiでは、Fluxについての発表をしました。

もともとは、Fluxの概要+実務で感じているFluxのいいところやイケてないところをざっくり言語化して発表しようと考えていました。

しかし、たとえこちらが言語化できたとしても、ある程度の知識や共感してもらえる「前提」がなければ、メリットをよりうまく説明したりスッと実感してもらうことはできないのではないか、と準備期間後半あたりに気が付きました。さらに、下記は自分がプロポーザルに記載した内容なのですが、

In this talk, I'll talk about flux architecture as one of the solid solutions for managing states within Android application; by achieving unidirectional data flow, we aim to think less, focus more on feature development, and scale faster.

(Androidアプリ開発における状態管理問題を解決する設計の1つとしてFluxを紹介します。データの流れを単一方向にすることで、状態管理であったりロジック管理について無駄に考える・悩むことを減らし、代わりに素晴らしい機能について考えたり実装したりする時間をもっと作り、アプリを大きく(スケール)させましょう!)

このようなプロポーザルの内容を準備の途中からあまり意識できていませんでした。(事業部内の共有会にて途中までの資料を共有させていただいた際に気づかされました。。)

改めてどういう内容を発表しようか、作り初めていた資料を修正し、最後まで悩み、社内の後輩・同期・先輩エンジニアの方々にご相談させていただいたりしました。皆様改めてありがとうございました。特に@kaelaela氏については、発表練習を一緒に何度か行ってくれました。ありがとう!

最終的な発表内容

最終的には、プロポーザルの内容に沿った上で、自分が現時点で一番感じているAndroidアプリ開発にFluxのメリットや悩ましいところをそのまま発表したいと思いました。

ということで、アプリの中でのデータの流れを単一方向にすることと、Storeを唯一のデータを管理するコンポーネントと位置づけることが重要であるということを前提に、FluxをAndroidアプリ開発に採用することのメリット、悩ましいところは以下であると個人的に結論付け、共有したいと考えました:

メリット

  • Fluxの単一方向性という考え方やアーキテクチャの図式自体がシンプルであること
  • Fluxの各パーツの責務がはっきりと分かれているため、実装コードがある程度統一されること
  • 機能ベースでFluxのデータの流れを実装することで、一度実装したFluxのパーツや内部ロジックを、新しい機能や画面を追加する際に再利用できること
  • Kotlinのsealedクラスを用いたり、Actionのクラス名を分かりやすいものにすることで、Storeの内部ロジックを読むことでアプリの仕様が理解できること

これらのメリットを享受することで、Androidの開発におけるデータの管理方法や機能追加の際に考えたり悩んだりする時間を減らすことができます。さらに、コードを書く以外の部分において、たとえば新しいメンバーがチームにジョインした際にも、新しいメンバーが早い段階で実力を発揮でき、最終的にはスケールしやすいアプリになる、という発表をしようと思いました。

もちろんいいところばかりではなく、悩ましいところも紹介したいと考えました。

悩ましいところ

  • 本来のDispatcherの役割が、いわゆるEvent Busである(アプリ全体に対してデータを伝達する)
  • ActionCreatorStoreどちらに処理を記載したほうがいいのか、たまに悩む

これらを踏まえ、最終的にできたスライドは下記です

speakerdeck.com

登壇が決まってから登壇するまでざっくり

登壇が決まった:

2017年の末からすでに緊張しているのを感じる:

そして登壇直前の最後のツイートで緊張しすぎて誤字のfoe:

英語での発表だったため、海外出身の方がたくさんいるのでは、と予想していたのですが実際は5人程度とかで残りは日本人の方でした。笑

反省

1日目終了後の懇親会にて、@wasabeef氏に「日本を楽しんでもらいたいなら何か紹介しなよ、ラーメンとか」、と勧められたため、ラーメンのお店はどこが良いのか自分の中でも一番が決まっていなかったため、海外出身の方にとって珍しい日本のコンビニエンスストアの便利さと、数あるコンビニエンスストアの中で僕が一番大好きなセブンイレブンの「ななチキ」について、登壇前に紹介をしました。これができたのは大きな自信になりました。 ただ、@wasabeef氏にはラーメンのほうがよかったな〜と言われたので、そこは反省です。

発表は、案の定練習の時のようにうまくはいかず、カミカミだったり、最後、時間的にはほぼぴったりだったのですが、タイマーの音に驚いて「Enjoy Japan!」と叫んで終了しました( ゚∀゚)・∵. グハッ!! 恐怖でYoutube動画がUPされても自分のだけは絶対に見れない形になりました。ですが、お褒めのツイートを頂けたり、オフィスアワーで初めて声をかけてくださった方がいたり、会社の後輩氏のツイートからスライドの改善すべき点が見えたり、良かったことも失敗したことも含め、発表できてよかったと改めて痛感しました。

反省としては、設計周りの発表をする際には前提がないと、ただただ簡単なサンプルの一例を紹介するだけでは旨味が伝わらない、ということに最初の方で気づけなかったことです。50分枠のほうが適切だったかも、と感じました。

時間配分に関しては、早めに終わる分には問題ないので早めに終わるように時間配分するくらいが良いのかもと思いました。自分の場合は本番中、まだ時間あると思って詳細を話していたらすぎてしまったので、「時間ある」と思わずさらっと終わればよかったな、と反省しました。

ぜひまた発表したいです。

あとは、これはイベント全体を通してですが、他登壇者の方々ともっとお話できればよかったな、と思いました。ここが一番反省。来年はもっとたくさんの方と仲良くなるぞー!!!

ツイート

終わってからfoeに気付いた自分と、それにいいねをくださるDroidKaigi公式の優しさ:

皆様ありがとうございます!!

最後に、いくつか撮った写真を共有します。

f:id:shaunkawano:20180210122218j:plain:w360
DroidKaigi208いよいよ感

f:id:shaunkawano:20180210124218j:plain:w480
ウェルカムトーク会場

f:id:shaunkawano:20180210121001j:plain:w480
Androidで動画コンテンツを扱うTipsについて発表している@takusemba氏(ブレてる...)

f:id:shaunkawano:20180210121116j:plain:w360
登壇前、緊張がピークに達している@kaelaela氏

f:id:shaunkawano:20180210121714j:plain:w360
ProGuardについて発表している@stsn_jp氏

f:id:shaunkawano:20180210122255j:plain:w360
PrePartyにて出てきたDroidくん🍻

f:id:shaunkawano:20180210122248j:plain:w360
2日目同じ時間帯にInstant Appsについて発表した@_a_akira氏

f:id:shaunkawano:20180210122250j:plain:w360
会社同じだけど初めて喋って仲良くなったEoinさんと@takusemba

f:id:shaunkawano:20180210122223j:plainf:id:shaunkawano:20180210122227j:plain
懇親会会場はキラキラしてた


f:id:shaunkawano:20180210124521j:plain:w480
2日目終了後、@stsn_jp氏と2人でやよい軒で打ち上げ〜(DroidKaigi Rejectonも頑張るぞ!)

改めて、運営の皆様、本当にありがとうございました!!

以上です!