hanahanahunachi’s diary

Android studio でお勉強してます。

「大きめのAndroidアプリでの設計について考えてみる ~pocket~」を読んだ.

はじめに 

こんにちは,ふなちです!

 

1週間以上前になるんですが,技術書店で入手した

「大きめのAndroidアプリでの設計について考えてみる ~pocket~」

を完走させていただきました.

 

booth.pm

 

頭が悪いのにも関わらず,設計のお話は好きなので,楽しかったですし,とても勉強になりました.

ありがとうございます!

あと,この本の土台となっているリポジトリのコード

github.com

も何度も読ませて頂き,参考にさせて頂きました.(実はDroidKaigiの釘宮さんのセッションの影響もあって,本を買わせていただく前からこのリポジトリは何度か拝見させて頂いてました)

 

これ以降技術的に間違えた内容があるかもしれないです.

間違えの指摘,アドバイス等はhttps://twitter.com/_hunachiにお願いします:bow:

 

※ これ以降は,「大きめのAndroidアプリでの設計について考えてみる ~pocket~」の事を「本」と表現しています.かなり大雑把で失礼になっている気がしますが語彙力不足です.すいません.

 

感想

表紙

女の子とピンクドロイド君が可愛い,可愛すぎてやばたにえん.彼女にしたい.

視点が白板側っていうのも好きです.

 

技術的な感想

 先週,個人的な事情で小さいアプリを作っていたんですが,それはこの本で学ばせて頂いた事を取り入れながら書いたので,基本的には実際に取り入れてみた感想を書いていきたいと思います.

 ※ 本の感想と,取り入れてみた感想を分けて両方書こうとするとやばい量になる気がしたので,取り入れてみた感想をメインで書く事にしましたご了承下さい:bow:.

 

ちなみに今回作成したアプリはこちらです.

github.com

(色々あってミラー版です)

 

また,小さなアプリには不向きですって書いてあるのにごめんなさい,小さなアプリなのにも関わらず参考にさせて頂きました.module分けに関しては,規模の関係もあり好き勝手にしてしまっていて,なにを勉強したんだって感じかもしれないコードになってしまったのですが,ドメイン部分の書き方などを参考にさせていただいたりして,コードの品質が以前より改善したと思います.

 

マルチモジュールについて

DroidKaigi 2018 - マルチモジュールのすヽめ / kgmyshin [JA] - YouTubeで以前学ばせて頂いていたのと,インターン先でもmodule分けを体験していたので多少なりともmodule分けの知識あ持っていたのですが,module分けのメリットなどをより詳しく知ることができました.

コンテキスト毎で分けるのは分かるのですがレイヤー毎にmodule分けするというのは驚きました.確かに,強力なレイヤー化アーキテクチャに!(。 ・ω・))フムフム.

 

実際に大きなアプリでなくてもmodule分けを取り入れる事で,infraの部分は他のモジュール(View)からでは基本repository以外見えない状態にでき,コードの品質がよくなりました.

 

先日のGoogle I/Oで「Dynamic feature modules」の発表があった事もありmodule化の流れが (((o(*゚▽゚*)o))).

 

ちなみに,個人的に以下の記事が分かりやすかったです.

tomoima525.hatenablog.com

 

レイヤー化アーキテクチャについて

今までレイヤー化アーキテクチャを実践しようと思ったことはありましたが,綺麗な分け方がいまいち理解できておらず,迷走し中途半端なレイヤー化アーキテクチャをしたことしかありませんでした.

 

しかし,本で詳しく説明していただいていたので,今までのモヤモヤがほぼなくなり,以前よりもだいぶ綺麗なレイヤー化アーキテクチャを実現する事ができました.

 

そのおかげで,レイヤー化アーキテクチャの恩恵をたくさん受けられました.

特に,domainレイヤーの大切さは実際に実装する中でも実感できました.

コードがぐちゃぐちゃにならずに済みますし,自分がどういうコードを書きたいのかというのをきちんと決めておかないと手が進まないというのも大切だと思いました.(とりあえずコードを書くという悪い癖が治りました.)

またコードがより整理され可読性もかなり上がりましたし,後々のコードの管理がとても楽になりそうです!

 

去年の秋に,知識が乏しい中かなり大きなアプリを作った際の苦しみを思い出しつつ,大きなアプリでレイヤー化アーキテクチャ使わない手はないのでは?と思えました.もっと早く知っときたかった(> <。)

 

レイヤー化アーキテクチャを適用した際の実装順について

また,実装順に関しても参考にさせて頂きました.

本によると,

 

              > ui -> usecase 

domain

             ┗ > infra

 

でした.私は今回

 

domain  ->  ui  ->  infra

 

という順で書いていきました.(小さなアプリだったのでusecaseは使わなかった.)

 

またここに詳しいことは書かないのですが,本にはこれらのレイヤー中での実装順も丁寧に説明されており分かりやすく,凄く参考になりました.

実装例が充実していたのには感謝しかないです:pray:

 

余談なのですが,以前は,部内の開発スピードが早い人に普段,どの順番で書いてるか聞いたりしてどうにか効率の良い開発順を知りたかったのですが,同じ分野をしている人がいないというのもあり,迷走して逆に開発スピードがダウンするという事をしていました.

その結果最近は,一人で開発してるんだし書きたいところから〜とか適当に書いていき後に混乱を招くというバカな事をしていました.

しかし,この本のおかげもあり,今回はスピーディーにモヤモヤもなく開発をすることができました.ありがとうございます!

 

その他で学んだ事
  • MVPについて.

今までほとんどMVVMでの実装をしかしたことがないのですが,この本を通じて,MVPの良さも知ることができました.

PresenterとViewとがContract(intarface)で繋がっている?ため役割を明確にContract定義でき可読性がかなり上がるという点と,機能が多いアプリでMVVMを使うとViewModelが肥大化してしまう問題に直面しかねないが,MVPだとBindingModelを別に作れるので,肥大化が起こりずらいという点でメリットを感じました(。 ・ω・))フムフム

 

今回作ったアプリでは色々考えた結果,DataBindingのBindingAdapterを乱用できたのでそこまでViewModelが肥大化しなかった&Viewへの依存関係は完全に断ち切りたかったのもあり,MVVMを採用しました.

 ※ Contractを使ってViewとViewModelを繋いで可読性をあげてもよかったのかなぁって思いもしました.(迷走タイム)

 

  • ScreenTransitionについて.

先日のGoogle I/OJetPackのNavigationの発表があったので今更この話をって感じかもしれないですが,印象に残ったので書かせて下さい.

これは実質,Navigatorクラスが必要かどうか問題についてなのですが,Navigatorクラス(全ての画面遷移を管理するクラス)は採用せずに,ScreenTransition(interface)を作り,画面遷移の実装はActivityにするという方法について知ることができました.

 

今回作ったアプリではFragmentが存在しなかったので,以前インターンで出会って感動したActivityにもFragmentのnewInstanceを作るという形をとりましたが,Fragmentが存在して,Fragmentの切り替えも一緒に実装するとなると,ScreenTransitionを作る方法が個人的に最適だと思いました!

 

また,Navigationクラスを使うデメリットについてのコラムはとても共感できる内容でした.DroidKaigiアプリでもNavigatorクラスは存在してましたし,他の方のコードにもNavigatorクラスが存在することが多かったので,Navigatorクラスって便利なのかぁって思い試した事があったものの,ごちゃっとなってしまったりして何かモヤモヤしてたのですが,そのモヤモヤを全て言語化してくれてる感じで,スッキリしました୧(๑•̀ㅁ•́๑)૭

 

アプリを作ってみたけど,まだ修正が必要かもと思う部分について

注:この章は,ほぼ本の感想じゃないです!

アプリを作ってみたけど,私の頭が足りておらず,まだ修正が必要かもと思う部分が2つあります.

 

1つ目は,ドメインとインフラは他のコンテキスト(モジュール)から見えないようにすべきという事をしないといけないのにも関わらず,モデル(データクラス)をドメインに書いてしまい,しかもそれを他のモジュールから使えるような形(not internal)にせざるおえない事になってしまった事です.小さなアプリだったので,色々な部分で使うためのデータクラスだけをもつモジュールを作るべきだったのかな?と思いました.

 

2つ目は,infraがデータを提供してくれるRepositoryも,インターフェースだけをpublicにして,それを実装したクラスはintarnalにすべきだったと思うんですが,DIを下手に使った関係でその実装したクラスまでもpublicにせざるおえなくなってしまいました.もうちょっとmodule間で上手にDIを使う方法を考えていきたいです.また釘宮さんのコードも参考にしてもうちょっと勉強していきたいです.

 

 最後に

これを機にアプリの設計についてもっと考えていって,いつか社会に出たりして大きなプロジェクトの設計を考えるとなる機会が訪れるなんてことがあった場合に最適解により近い設計ができるといいです.

 

釘宮さんありがとうございました.

社会人になって自分でお金を稼ぐことができるようになったら恩返しできたらいいです.あわよくば,自分も本を出したりして社会に貢献できるようになりたいです.(厳しい道!)

 

P.S.

技術書店でGETした他の本の感想等に関しても

技術書店4に行った. - hanahanahunachi’s diary

にList化していくつもりなのでよろしくお願いします(> <。). 

「The Book od SobaCha ~Androidアプリ技術解説書~」を読んだ.

こんばんは,ふなちです!

はじめに

先日(だいぶ前かもだけど),技術書店*1

で入手した,

「The Book od SobaCha ~Androidアプリ技術解説書~」わかめそば著

を読ませていただきました.

自分の為にも,感想を残しておきたいと思います.

感想

表紙が可愛い

お腹がいい.

f:id:hanahanahunachi:20180506223644j:plain

 

特にお勉強になったこと

アニメーションについてのお話が特に勉強になりました.

特にスプラッシュスクリーンでのアニメーションとタイムラインの読み込みを同時にするとカクカクなる問題についての話題でUIについて考えさせられました.

実際にMateChaを使ってみても,アニメーションが終わってからのタイムライン読み込みでもそこまで遅さを感じませんでしたし,よく考えてあるなぁと思いました.

全体的な感想

少しは知っている技術について多く書いてあったので,スッと理解できました.

また,ProductFlavorのお話など,今まであまり有効活用できてなかった技術を,実際に活用されている事例を提示しながらどういう風に使ったらよりよく使えるか解説してくださっていたので,とてもお勉強になりました.

また,Android wear(現在ではWear OS)の為のアプリ開発についての内容もあり,今までそんなに興味がなかったAndroid wearに興味が湧きました.スマートウォッチすら持っていないので,お財布に余裕ができたら買ってアプリ開発してみたいです.

技術書店4に行った.

こんばんは!

ふなちです.

はじめに 

ほんと今更なんですが,

techbookfest.org

に行ってきました.

戦利品

f:id:hanahanahunachi:20180505231016j:plain

 

全体的な感想

人が多くて大変でしたが,普段絶対に会えないような方々とお会いすることができてとても嬉しかったです.

また,沢山の本を買えて大満足です!(全部読み切るまでにどれくらいかかるだろう?)

実は今回,技術書店4に行けたのは,前日に飛行機を逃してしまったからなので,技術書店5には前もって計画して行くことができたらいいです.

災い転じて福となすとはまさにこの事...?

 

 せっかく素晴らしい本をたくさん手に入れたことですし,読ませていただいた本の感想をこのブログにあげて行きたいと思います!(読むのも書くのもかなり遅いのでご了承ください.)

 

読み終わり,感想を書く予定&書いてる一覧
  • C♡U Coupling Union 
  • 「わかる!ドメイン駆動設計 ~もこちゃんの大冒険~」techBooster編著
感想一覧

 

自分用のめも#sort

 

このツイートに関する補足

https://research.preferred.jp/2011/10/tim-sort/

www.geeksforgeeks.org

 

ついでに,今日の数学で使ったレビチビタ記号について

レビチビタ記号とその性質 | 高校数学の美しい物語

 

 

potatotips #50 (iOS/Android開発Tips共有会) に参加した.

はじめに

こんにちは,ふなちです.

potatotips.connpass.com

に参加して来ました.

先月から続いて2回目のAndroidブログ枠での参加でした!

なんで九州の高専生が木曜の夜に東京にいるんだとかそう言うことは気にしないでください!実は久留米で午前中の1,2限の授業を授けてから来たんです..!

 

今回は記念すべき第50回目のpotatotipsだったのにも関わらず参加することが出来,嬉しく思います(((o(*゚▽゚*)o)))

第一回は 2013年なんですね!長い歴史だ...!

発表者の方には,今までの発表の振りえりもしている方が多く見られました.

 

※今回もただの個人の感想になってしまっているところや,スライドに書いてあるだろうことをつらつらと書いたもの多いですが,ご了承ください.

また,間違い等の発見した場合はTwitterなどで知らせてもらえると嬉しいです🙇‍♀️

 

発表

"Hello Flutter"の次におさえたいFlutterのポイントその3 by かんばらけんいち

www.slideshare.net

AppBuilder v.a 20170605-09:10

ちなみにその1とその2はこちら

Hello Flutterの次におさえたいFlutterのポイント

Hello Flutterの次におさえたいFlutterのポイントその2

Flutterのお話でした.

potatotipsでの発表は7回目!凄い!

初参加の第二回potatotipsの発表でも,クラスプラットフォームに関する発表をしていたそうです.

Androi,iOS,FirefoxOS,Tizen で動くアプリを一気に作れちゃうPhoneGap(Cordova)を使っていたそうです.

私は,後ろの2つのOSをよく知らなくて興味深かい!

FirefoxOSは2016/5に開発終了してるんですね. Tizanは実際に見たことないです.

(競技以外のプログラミング始めたのが2年弱前くらいなので許してほしい)

また,4つのOSでコードの共通化ってどれくらい出来てるんだろう?気になりました.

 

flutterで翻訳アプリを作っていて,近日公開予定らしいです.

私,英語が苦手なのでお世話になるかもしれません...!

 

今回は,UIについてのお話だそうです.

https 通信とかデータの永続化についてのお話しもいつかお聞きしたい!)

Widged Treeの構造は綺麗で分かりやすくて好きです.

Columnの中にどんどんViewの子を追加していけばいいんですね!

Conclution(Flutter向けのGUI Builder)のGoogle I/O 2018でのリリースしてくれたら嬉しいです!

www.ntt-tx.co.jp

recyclerview-selection by くぎみや

 

speakerdeck.com

 recyclerview-selectionに関するお話でした.

何週間か前に,くぎみやさんの記事を読んだ記憶が...!

recyclerview-selectionは,最近お世話になる機会が多くなってきた,android-ktxと同じ'androidx.'パッケージに含まれているそうです.

SelectionTracerを使うんですね(。 ・ω・))フムフム

いつも通りに,Listを作って,それに

  • stableId を使うように設定する.(ViewAdapterにsetHasStableId(true)と書く)
  •  SelectionTrackerのインスタンスを作る.(引数の詳しい説明はスライドとブログに書いてあるので割愛します.)
  • ( SelectionTrackerのインスタンス)で必要なItemDetailLookupを作る.

だけだそうです!

あとは,洗濯部分に色をつけたりなどしたい場合は,selectionTracerのインスタンスをAdapterで受け取り,よしなに実装すればいいようです.

この時,selectionTracerのインスタンスは,Adapterを生成後に設定してあげる必要があるので注意だそうです(※詳しくはブログを読むと良さそうです.)

 

いつも,くぎみやさんのブログにはお世話になっているので生でくぎみやさんの発表を聞けて嬉しかったです!

また,この発表の内容のブログ

inside.dmm.com

もとてもわかりやすく書いてあったので読むべきだと思います!

あと技術書典4にて釘宮さんの本買わせて頂きました!読むの楽しみです.

Glide 4 with Kotlin by Hiroyuki Kusu

speakerdeck.com

Glide4についてのお話でした.

私も(は)Glideにはいつもお世話になってます(感謝)

Glide4は,デフォルトでは"フェードなし"なのですね!

Glideは拡張できて,その関数を書く際には第一引数にRequestOptionを入れる事とNonNull & static であるということは守らないとダメだそうです(。 ・ω・))フムフム

そしてそれは拡張関数として書いたらいい感じになる!

DataBindingのListnerを拡張関数で書くのと同じノリなのでサクサクかけそうで良さげです!(こういう拡張関数の使い方超好きなので&折角教えて頂けたので,Glideへの拡張もやっていきたい(((o(*゚▽゚*)o))))

丸くくり抜くのcircleCrapとか,transrationは,すごく便利!

今まで私,

RequestOptions.circleCropTransform() 

って書いちゃってたんですが,4からはcircleCrap()があったんですね汗...お勉強になりました(> <。).

他に,プレースホルダーとフェードを同時に適用するとプレースホルダーが消えない問題の解決方法,助かります🙏

コードが冗長になってしまうのはしょうがないんですね.(悲しい)

DiffUtil and ListAdapter by くぼで

speakerdeck.com

DiffUtilとListAdpterを使おう!というお話でした.

DiffUtilはO(n)で差分を取ってくれて更新してくれるので最強!

ListAdpterは,RecyclerView.AdapterのDiffUtilを使ったものだそうです.

差分はbackground thread,結果の通知はmain threadで行ってくれるの強いです.

ListAdapterを使うとsubmitListするだけでいい&その時使うListはMutableListじゃないほうがいいってとこが腑に落ちてなかったんですが,Listのインスタンスが同じだったら何もしないって処理をしてたからなんですね,

スッキリしました(((o(*゚▽゚*)o)))

私自身,DiffUtil,listAdapterもだったけ...🤔インターンに行った際に社員さんから教えて頂いて使ったの思い出した&ちゃんと理解し直す良い機会になりました🙏

github.com

(用途は思いつかないが)Viewのキャプチャを撮ってみる by どくぴー

www.slideshare.net

Viewのキャプチャを撮ってみよう!というお話でした.

画面のキャプチャをとる方法には,

電源ボタン+ボリュームダウンボタンを押す,adbを叩く,AndroidStudioのLogcatを使うなどがあるそうです.

私は,最近は基本Logcatのボタンを使っています!便利!

では,画面の必要な部分だけ撮りたい,とかStatus barを除いた画面キャプチャが取りたい!などなど,Viewのキャプチャを撮りたい場合ってありますよね?と..

確かにです.私はViewのキャプチャを撮ることが出来るとは知らずに今までいちいち画像編集してました(> <。).

Viewだけのキャプチャを撮るには,View#setDrawingCacheEnavleをtrueにしてView#getDrawingCache()でViewのCashを作成(取得)し,それをBitmapに変換,(android-ktxを使っているんであれば,View#toBitmapだけで良いらしい)View#setDrawingCacheEnavleをfalseに戻すだけで良いんですね.

めっちゃ簡単だヾ(。>д<)シ 

その後,PDFとして利用したい場合は,PdfDocumentを使ってゴリゴリ実装すれば良いようです.

Canvas芸をする必要があるそう&重い(当たり前だけど非同期処理必須.)

ページを作る際には,PageInfo.Builder(ページの幅,ページの高さ,ページ番号).create()を実行する必要があるそうです.(PageInfoってのはページ情報を管理するクラス)

ちなみにページのサイズ指定時の単位はpoints(72points = 1 inch)で,ページの大きさを指定する際にはちょっと気合が必要そうです.(画面のサイズを測ったり等々)

画面の全体のキャプチャが欲しい際には,MediaProjection API(API21~)を使うといいそうです.

便利そうだしやってみたいと思ったのですが,アプリ側からViewのキャプチャを撮るというのは,どういう時に使うのでしょうか..?(パッと調べた感じだとメールに添付するとかがありましたが,もっと他の用途をしりたいです!)

Preference as a Service by izumin5210

speakerdeck.com

Preference..というお話でした.

potatotipsでの登壇は今回で8回目なんですね!凄いですオオォォォ(゚ロ゚*)

Preferenceの実装には色々な方法, SharedPreferenceや,Realm,FireBase Remote Config等を使う方法があるそうです.

私は,SharedPreferenceしか使ったことない...ヾ(。>д<)シ 

Preferenceは,サーバー側の挙動に影響しやすいものが多いので,ローカルだけで保存するというような方法を取ることは出来ない.

そこで,自前でサーバーを実装していた そうです!

でも,毎回自前でサーバーを書くのは辛く,

また他のアプリとの共有したい部分など出来た時にも困ったそうです.

そこで,Preference as a Server を作ったそうです.

やはり自前な理由は,マイクロサービスであり,内部の別のサービスからも参照したかった,データを外に出さずにすむ,設定値も簡単に追加変更ができ,自分たちが使いやすいカテゴライズ機能を付けれる.といった理由からだそうです.

他にはデバックする際にも有効活用できるらしく,素晴らしいと思いました!

今度,もし高専プログラミングコンテストの本戦出場が出来た暁にはこの方法を,試してみたいと思います!

技術力的にできるか不安ですが(> <。)

 消費型課金を導入する by もりぞー

Play Billing Library を使うと良いぞ!っていうお話でした.

課金が完了するまでの流れは,

  1. クライアント側からGoogleに課金したいよっていうのを伝える.
  2. その後,Googleからレシートを受け取る.
  3. サーバーにレシートの検証をしてもらう.ここでユーザーやアイテムの情報を送る.
  4. サーバーからGoogleに検証してもらう.
  5. その後クライアントはレシートの検証結果をもらう.
  6. 消費リクエストをクライアントからGoogleに送る.

という感じらしいです.(申し訳ないことに,うる覚えの状態で書いたので間違えてたら本当にすいません.)

色々引っかかりポイントがあるので気をつける.べきとの事でした.

課金システムのフローを丁寧に説明してくださってわかりやすかったです.

キーボードの切り替えをいい感じにしたい by わくわく

speakerdeck.com

キーボードの切替を良い感じにしたいというお話でした.

ただ単に,キーボード出ないものが表示されているかを判定してそれを表示させたり,非表示にさせたりするだけのコードだと,

バコン!ガコン!みたいになる.

これを解決する為に,Messengerを参考にしてみたそうです.

View構造のdumpをとりつつ,壊す勢いで調べたそうです!

経験不足の私は,今まで開発者モードのLayoutの境界を表示させたり等しかしたことなかったので,今度から他のアプリの良いところを盗みたいときはdumpも使っていきたいです.

結果,特別なCustom Viewなどは使っていない&裏にViewがあるようだったそうです.

そこで,キーボードを隠す際に高さが変わらないようにすれば良いのでは?という結論に至ったそうです.

そこで,ソフトウェアキーボードを隠す際にはソフトウェアキーボードの設定をWindowsManager.LayoutParams.SOFT_INPUT_ADJUST_RESIZE(キーボードと他のLayoutが被らないようにする)にし,逆に出す際には ,WindowsManager.LayoutParams.SOFT_INPUT_ADJUST_NOTHING(キーボードが出てきた際に高さを調節しないようにする)を設定すればいいそうです(。 ・ω・))フムフム

こうすることで,あのチカチカ,バコン,ガコンとしていたキーボードがチカチカ,バコン,ガコンとならずに隠れたり出てきたりするようになるんですね!

 

経験が浅いのもありキーボード周りを触ったことがなかったので,とてもお勉強になりました.

この発表を聞いた後からキーボードのチカチカが凄くきになるようになりました .

懇談会の時も凄く楽しそうに喋っていらっしゃったのが印象的でした.

adjustnothing

github.com

 

 ディープリンクを実装した by たかしぃ

speakerdeck.com

デープリンクに関するお話でした.

デープリンクを実装した流れは,

  1. 起動画面は透明のActivityにして
  2. その?Activity(schemeが追加されたもの)でURL schemeのデータを受け取る
  3. その後,データのQueryに応じて,どのActivityを表示させるかや,Activityをstuckに積むかなどの条件分岐をする.

という感じなのだそうです.

OAuth認証と同じ手順で行けば良さそうなので,デープリンクの実装はしたことがないのですがスッと理解できました.

また,Activityをstuckに積む操作をする場合の手順は,

ActivityLifecycleCallbackインターフェースを実装したクラスを作成し,他のActivityからの通知を受け取るようにして,onActivityCreatedやonDestoryを通った時点で他のActivity側から通知を送ると,現在起動しているActivity をstuckに良い感じにaddすることができる.

他に,ホーム画面をstuckに積んでから該当画面を開きたい場合はTaskStackBuilderを使えば良いようです.(※TskStuckBuilderを使う前のActivityは消去されるので注意が必要)

最後にdroid girlsの宣伝🎀

私も,参加しました!お勉強になりましたし,気軽にお話することができて楽しかったです! 

また先日,droid girlsのslackに参加させていたのですが,そこで飛び交っている様々な質問にあんざいさんや,強い人たちが丁寧に答えて下さったりしているなど,素晴らしい環境で驚きました.

最後に

 全体の感想なのですが,今回も初めて知ることなどが多くあり勉強になりました.

 

軽食もとても美味しかったです🍔🍟!(ポテトチップスが美味しそうに飾られていたのにも関わらず写真撮り忘れてしまってました.すいません(> <。))

f:id:hanahanahunachi:20180424000946j:plain

また,Wantedlyの社員さんともお話させていただいたのですが,フレンドリーで技術力も高い人が多く,凄く楽しそうでとても良い会社なんだなぁってことが伝わってきました.

 

今回の東京旅行?は,DroidGirls目的であり,せっかくなので以前楽しくお勉強させて頂いたpotatotipsにも参加しよう!という軽い気持ちで参加したのですが,実際に終わってみるととても充実したイベントとなり本当にきて良かったなぁと思えました.

 

長い長いブログですいません,お読みになって下さった方ありがとうございました!

時間があれば,DroidGirls参加記も書きたいと思います.

 

初めてのインターンシップ👧👒

こんにちは!

緑アイコンがアイデンティティふなち(Hunachi · GitHub)です.

 

はじめに

私は,3/5~3/16の間,チームラボ株式会社のインターンシップ*1Androidアプリ開発チーム)に参加させて頂いてました!

期間は2週間でした.

先に結論から言うと,めっちゃ楽しかったです!!

インターンシップに行くまでの流れ

インターンシップを知ったきっかけ

沖縄高専mito (@mitohato14) | Twitter さんにmitoさんがチームラボさんのインターンシップに参加する事になったという事を教えて頂いたのがきっかけです.

ちなみに,チームラボさんの事は高専プロコンなどのコンテストで見かけたり,実際にチームラボさんの展示を見に行ったりしていたので知っていました(๑・◡・๑)♡

応募した動機

  1. 春休みという長い時間を活用したかった.(インターンシップに行けなかったら車校に行こうと思ってました.)
  2. 東京までの交通費と宿泊費を全部負担してくれた.通った後,お給料も出るという事を聞いてより行きたくなった.
  3. 東京のイベント(勉強会)に参加したくてたまらなかった.
  4. KotlinでAndroid開発ができるという話を聞いた.(他は探してもなかなか無かった.)
  5. mitoさんが行けることになったということだったので, 私が挑戦できるギリギリのレベルかも知れないという謎の自信が生まれた.
  6. チームラボさんは私の学校では知られていて歴代のガチプロ先輩方もチームラボさんのインターンシップに参加していた.

選考の流れ

チームラボさんの公式サイトを見てもらえばいい話なのですが,私の感想も入れながら説明したいので書きます!

書類選考

何で行きたいのか〜とか,今まで何してきたのか〜というような内容でした.

他のインターンシップに応募した事がないので正確な事は言えませんが,一般的な内容だったと思います!

他には,自分のSNSのアカウントなどを書く事もできたので,

Github,このブログ, Twitter*2のurlを貼りました.

送信する瞬間,3年前の受験を思い出すくらい緊張しました.

 

〜三日後〜

メールが来ました.

どうにか合格だったようで,ほっとしました.

面接に向けての準備

面接までにweb上での適正テスト?を受けました.(これはメールでの指示)

また,面接で聞かれるかもしれない事を前日に書き出したりしました.

面接

時間は火曜日の13:00~でした.(授業*3があったのですが,自主休講*4させて頂きました.)

ちなみに面接の日程は1次審査の結果を送って頂いた4日後でした!

だいぶ前の話なので,聞かれた事を忘れましたヾ(。>д<)シ 💫

ただ,

「最近きになるアプリや,技術ある?」という質問に,

「Kodeinが気になってます!」というトンチンカンな返答をした事,

「何か質問はありますか?」という質問に,

「趣味を教えてください.」と「残業はありますか?」という

色々反省すべきな質問をしてしまった事は覚えています.

結果発表

なんか,参加できることになった!!

この後,初めて友達や家族にインターンシップに参加する事を伝えました.

(無駄なプライド)

その他

インターンシップに参加する数日前に顧問の先生の元を採用担当の方が訪れていた時がありました.(先生とは昔からの付き合いらしい?です.)

先生が頂いたお菓子を部活で頂いたのでみんなで食べました.美味しかったです.

 

ただ,その時に先生から今までにチームラボのインターンシップに参加した歴代の先輩方がいかに凄い人達だったかという話を淡々とされ,自分に自信の無かった私は「ごめんなさい.勝手に応募しました,ごめんなさい.学校の名前を傷つけたらごめんなさい.うう...(> <。)」という気持ちになってしまい滅入ってしまいました.

もう一人チームラボさんのバックエンドの方のインターンシップに参加するゲ・ドリンク (@gedorinku) | Twitterさんがいなかったら耐えられなかったかもしれないです.

 

しかし,インターンシップがとても不安になった反面,頑張らなくてはいけないという気持ちも持てたので良かったです.

インターンシップ初日

出社する前

前入りしていたのもあり,朝(8時に)起きれるか不安で前日は21時に寝ました.

寝坊はしませんでした.しかし緊張でガタガタしていたのが原因か,準備のスピードが遅すぎて,朝ごはんを食べることを失敗してしまいました.(WA)

出社

約束の時間から3分遅れて本社に到着.(TLE) 怒られませんでした.セーフだったみたいです(> <。)

採用担当の方に出迎えられ,オリエンテーションを行い,働く予定の場所に連れて行ってもらいました.

その後,メンターさんやチームの方に挨拶をして,早速,貸していただいたPCの環境構築をしました.

この日は,参加するプロジェクトがどんなものかの把握や,どういう設計でコードが書かれている(いく)かの確認,自分の担当箇所の確認などをしました.

1日を通して

初めての職場という環境での作業...

元々そこまで明るい人ではないのに,緊張で更に強張ってしまってました.

しかし,先にインターンシップに参加していたmitoさんがいらしたのと,メンターさんやスマホチームの方々とランチを食べに行ったりできたおかげで,退社時間までにはだいぶ緊張が和らいでいました.

3/6~3/16における,大雑把な活動内容

詳しいことは,多分社外秘なので言えません!(> <。)

前半

最初,任された部分が簡単な部分だったのでスイスイコードを書いていき...

たかったのですが,

  • 自己流でclass分けをするとまずいんじゃないか.
  • この書き方をしても大丈夫かな.
  • コードの書き方が汚いって思われたらどうしよう.

と行った不安が頭の中を駆け巡り,ダラダラとコードを書いてしまいました.

 

しかし,コードレビューを1度してもらってからは心を入れ替え,自分が思う最適な書き方でスイスイコードを書いていきました.

(この行為が正解だったのかわかりませんが...)

 

理由は,コードレビューをして頂くとこで,今まで気づけなかった実は危ないバグを生みやすくなる書き方や,もっと綺麗な可読性の高いコードを書くコツを学ぶことが出来る事を知ったからです.

また,コードレビューも攻撃的な内容は全くなくとても優しいものだったからですʚ♡ɞ

中盤

3~4日目,次の画面に取り組めるか?と思って他のですが,毎度お馴染みのバグや,使ったことのないライブラリ,に悩まされ始めます.

私を悩ませたもの一覧
  1. lottieというライブラリで一部だけをループさせるのに苦戦.
  2. 1を解決したと思ったら.ループさせる部分の画面遷移?(ViewPagerを使い表示させるFragmentの変更を行うだけ)で何度か行き来するとアプリが落ちるというバグが発見され,原因がわからず詰まる.
  3. Dagger2を使ったことがなかったので,(Fragment内で)Injectしてるのに,"not initialized"と言われ原因が分からず戸惑う.

全部解決しましたが,多少なりとも時間をかけてしまったので自分の未熟さを感じました.

解決方法
  1. setMinAndMaxFrame辺りを使えばいい.
  2. Listenerをremoveさせるのをやめるか,lottieのversionを最新にあげ忘れない.
  3. SupportFragmentでInjectが出来るようにApplicationで設定する.

バグ潰し楽しかったです(> <。)

後半

2つ目の任された部分を作り終えれるか不安に...

1つ目の部分より実装難易度も高く,特にxmlで長い戦いをする羽目になったからです.

CollapsingToolbarLayoutを使ったり,List処理を書いたり(これはそこまで重くないが)しました.xmlのバグが,とてもとても辛かった.

デザイナーさんの意向が分からず,質問する毎日
  • デザイナーさんが居てきちんとしたデザインが決まって居るアプリの開発は初めだったので,分からないことが多かったから.
  • デザイナーさんの本当の意向が分からず,「ここのアニメーションは静止画を見る限りこんな感じかな〜?」と実装していたら,違うという事が会議で判明しコードを消す事になった時,ちょっと悲しかったから.

というのが理由でした.

質問しまくったため嫌われてないか今でも心配です.(ごめんなさい.)

質問したおかげで学べたことも多かったので,質問したことは後悔してないです!

xmlでのバグに3日悩まされる

CollapsingToolbarLayoutのtitleが表示されないくて苦戦しました.

主な原因は,CollapsingToolbarLayout の content である Toolbar の layout_height を定数にしてなかったからです...社員さんやメンターさんを巻き込んでしまったので本当に申し訳ないです.ごめんなさい.

最終日の退社する1時間前に気づけてよかった.

 

また,後半に入ってからは,逆にチームの方(社員さん)のコードレビューをするよう心がけました.知識がないのと,コードレビューの経験がないのダブルパンチでとても難しかったです.

ただ,コードを読むだけでかなり勉強になりましたヾ(。>д<)シ 

結局コードを読んで直すべき部分は見つからずLGTMを送る事しかしてません.

最終発表

最終日の前日,最終発表がありました.

インターンシップで行った内容や感想を,10人前後のチームラボの方々に見ていただくというイベントです.

とても緊張しましたが,私の精一杯の発表はできたはずです!

質問もたくさんしていただき,嬉しかったです.(返答があまり上手ではなくてすいませんでした(> <。))

 

インターンシップを終えて

学べた事

  • チーム開発をうまく進める為のコツ
  • 自分の知らなかった設計思想
  • コミュニケーションの大切さ
  • CIツールの大切さ
  • 今まで使ったことのないライブラリ達に対する知識
  • (チームラボはラフな方だそうですが)職場とはどういう雰囲気なのか
  • 実際のエンジニアの仕事はどういうものなのか

感想

楽しかった!

2週間がとても短く感じられました.もっと長く働きたかった!!

 

メンターさんや,コードレビューをしていただいた方,同じプロジェクトの方,採用担当の方,一緒にランチを食べに行ってくれた方々など私と関わってくださった方々が,とても優しかったです.

 

特に,メンターさんには話しかけ過ぎたかも,他の仕事の邪魔をしたかもしれないと後悔するぐらい質問などたくさん会話をさせていただきました.それにも関わらず優しく丁寧に応答してくださり,ふなち...とても嬉しかったです.本当にありがとうございます.

 

一緒に開発してくださった某社員さんも丁寧なコードレビューをしてくださったり,一緒にバグを潰す方法を考えて頂き,ありがとうございます.とても感謝しています.同じくらい綺麗なコードがかけるよう精進してまたいつか,出直してきます.

 

また,私がインターンシップを行ったチーム(部署?)のオフィスは雰囲気がよく,椅子もPCもモニタもいい感じで,快適な作業環境でした.(いつも実家では床に座って作業しているからかもですが!)

ただ,Android Studioくんが重過ぎて発狂しそうなときがありましたが,これはしょうがないと思うのでしょうがないです.

 

最初は,休日に給料が発生している感覚でしたが,仕事でプログラムを書く方がSNSを閉じるので集中できたし,デザインがしっかりしているものを作ることができたのでやりがいを凄く感じることが出来,一人でアプリを作っている時とは違う楽しさ,嬉しさを感じることが出来ました.

 

また,「実際にはやれてないけど,〜〜も学んでみたいです.」という話をしたらできる限りの事をしていただけたりしたのもあり,感謝の気持ちでいっぱいです.

ここまでしてくださる会社も珍しいんではないか?と思うくらいでした.

 

最終日,

チームリーダーの方々や採用担当の方から,

「是非またインターンやバイトで来てね!」

と言って頂き,とても嬉しかったです.

別に普通のことなのかもしれませんが,

今まで一人で開発したり,部活でチーム開発している時に,自分って本当に必要な人間なのだろうか...?と自問自答することばかりで,自信を持てずにいた私にとってはとても有難く,多少なりとも自信を持つことが出来た言葉でした.

また,採用担当さんとFacebookで友達になることが出来て嬉しかったです!(※下心なんてないですよ!)

 

他の会社のインターンシップにも参加してみたいという気持ちもあるのですが,また夏に時間を確保できそうだったら,チームラボさんにインターンシップさせていただけるかお願いしてみようと思います.

 

これからも,今回のインターンシップでお世話になった方々と勝手に特定させて頂いたtwitter等でたまにお話できたら嬉しいです!

 

この記事に関連する記事

hanahanahunachi.hatenablog.com

hanahanahunachi.hatenablog.com

あと,

yj-meetup.connpass.com

にも参加させて頂きました!!(設計の話,お勉強になりました.)

おまけ

今回のインターンシップ期間中(前後の土日を含む)に取ったご飯の写真を見納め下さい.

f:id:hanahanahunachi:20180320213859j:plain

 

f:id:hanahanahunachi:20180320213907j:plainf:id:hanahanahunachi:20180320213923j:plain

f:id:hanahanahunachi:20180320214004j:plain

f:id:hanahanahunachi:20180320214058j:plain

f:id:hanahanahunachi:20180320214112j:plain

f:id:hanahanahunachi:20180320214117j:plain

f:id:hanahanahunachi:20180320214126j:plain

f:id:hanahanahunachi:20180320214151j:plain

f:id:hanahanahunachi:20180320214155j:plain

f:id:hanahanahunachi:20180320214201j:plainf:id:hanahanahunachi:20180320214213j:plain

f:id:hanahanahunachi:20180320214217j:plain

f:id:hanahanahunachi:20180320214221j:plain

f:id:hanahanahunachi:20180320214331j:plain

f:id:hanahanahunachi:20180320215005j:plain

 

f:id:hanahanahunachi:20180320214527j:plain

 

f:id:hanahanahunachi:20180320214433j:plain

 

f:id:hanahanahunachi:20180320214225j:plain

 

 

f:id:hanahanahunachi:20180320214233j:plain

f:id:hanahanahunachi:20180320214239j:plain

f:id:hanahanahunachi:20180320215126j:plain

f:id:hanahanahunachi:20180320215223j:plain

f:id:hanahanahunachi:20180320215227j:plain

f:id:hanahanahunachi:20180320215315j:plain

f:id:hanahanahunachi:20180320215257j:plain

f:id:hanahanahunachi:20180320215326j:plain

f:id:hanahanahunachi:20180320215331j:plain

f:id:hanahanahunachi:20180320215335j:plain

f:id:hanahanahunachi:20180320215345j:plain

f:id:hanahanahunachi:20180320215409j:plain

f:id:hanahanahunachi:20180320215419j:plain

f:id:hanahanahunachi:20180320215428j:plain

f:id:hanahanahunachi:20180320215437j:plain

f:id:hanahanahunachi:20180320215440j:plain

f:id:hanahanahunachi:20180320215446j:plain

f:id:hanahanahunachi:20180320215459j:plain

f:id:hanahanahunachi:20180320215507j:plain

f:id:hanahanahunachi:20180320215512j:plain

f:id:hanahanahunachi:20180320215531j:plain

f:id:hanahanahunachi:20180320215539j:plain

f:id:hanahanahunachi:20180320215555j:plain

f:id:hanahanahunachi:20180320215601j:plain

f:id:hanahanahunachi:20180320215608j:plain

f:id:hanahanahunachi:20180320215610j:plain

f:id:hanahanahunachi:20180320215625j:plain

f:id:hanahanahunachi:20180320215629j:plain

f:id:hanahanahunachi:20180320215633j:plain

f:id:hanahanahunachi:20180320215653j:plain

f:id:hanahanahunachi:20180320215643j:plain

 

f:id:hanahanahunachi:20180320215703j:plain

f:id:hanahanahunachi:20180320215708j:plain

その他思い出の写真

f:id:hanahanahunachi:20180320215827j:plain

*1: internship.team-lab.com

*2:twitter.com

*3:Java2の授業.実質Javaの歴史の授業??自分のPCを触るのも許可?されていた授業だったので忙しい時は「私は実質Javaを書いている」と言いながらKotlinを書いていた.

*4:何かしら理由があって自主的に授業をブッチする行為