ハッカソン参加記

Hana Kondo
Dec 6, 2018 · 7 min read

(もともと色々書いていたがデータが吹き飛んだ)と書いている部分は,

色々頑張って書いてたのに,更新に失敗してデータ吹き飛んだ部分です.過去の自分と貧弱な寮回線のせいです.

人生が辛い.

(気が向いたら書き直します.)

約1.5ヶ月ほど前の話なのですが,Git Push Hackathon val.2 というハッカソンに参加しました.今更ですが,折角なので体験記を書きたいと思います.

多分,ほどんど設計の話になります.

“Git Push Hackathon” とは?

公式から引用すると

「株式会社サイバーエージェントが主催する、Web / iOS / Androidエンジニア向け学生限定ハッカソン」

もっと詳しく言うと,個人で,ある決められた機能をもつアプリを,どのように作るかを競う?ハッカソンです.

評価は,(重要な順)

  1. 設計
  2. 最新技術、言語仕様を正しく用いた実装
  3. UI/UXへのこだわり
  4. その他各々の工夫・こだわり(プルリクエストにて説明したものを見ます)

でされます.

要に”どのように設計”するかが主な評価対象になるハッカソンです.

また,val.2と書いている事から察することができると思うのですが,これは2回目の開催です.

なぜ参加しようと思ったのか?

あのインターンで習得したことを使いたかったのと,折角だし参加したい!という欲に負けてしまったからですね.

あれれ?

ふなちは夏休み終わったら普通の勉強頑張るって言ってたのに,おかしいぞ〜?

(未来の私まじでごめんなさい)

作ったアプリ

俺の答えはこれや(っ’-’)╮ =͟͟͞͞

アプリの説明(使い方)

上のREADMEに全てが書いてあります.

主な機能

  • (必要とあらば)OAuth認証をする
  • Gitsを投稿する
  • Gist一覧を眺める

だけです.

アプリの説明(内部の実装)

今回,アプリを作る上で重視した点は,主に「設計」と「Kotlin Coroutineを使う事」 のみです.

  • 設計

モジュール分け,Flux

の考え方,実装の仕方を取り入れました.

なうなうなもの詰め合わせセットじゃん!

モジュール分けとは,機能ごとにモジュールとして切り出す事です.

上の図の黒い枠で囲まれたもの一つ一つがモジュールで,矢印はモジュール間の依存関係を示しています.

4年生ならデジタル回路設計の授業で,有限状態マシンを切り分けて設計する方法を最近習いましたよね?それをAndroidアプリを作る時に応用させた感じです.

この利点には以下のようなものがあります.

1.一つのモジュール内でコード変更をし,コンパイルした時,コンパイラはその変更した一つのモジュールのみ再コンパイルし,他のモジュールの分はキャッシュがあるのでコンパイルし直しません.

よって,一つのモジュールが小さければ小さいほどコンパイル時間が短縮されるという,良さみを得られます.

2.機能ごとに分かりやすくまとめられるので,可読性が上がります.

3.kotlinで書いたらの話ですが,internalをうまく使う事でよりカプセル化が出来て安全になるので嬉しくなります.

4.これはAndroid特有の話なのですが,うまいことmodule化するとApp Bundleの恩恵が得られます.

App Bundleってなんぞや?ってなると思うので説明をすると,

切り分けたモジュールをアプリをインストールするのとは別に,後から新しい機能が必要になった際に新しいモジュールをインストールする(ユーザーからは見えない)事ができる,Google play上での公開形式の事です.詳しくは:

https://support.google.com/googleplay/android-developer/answer/9006925?hl=ja

上の図を使うと,

「OAuth認証をしなくてもアプリを使用したい方は,oauth moduleとoauth moduleのみに依存する全てのmoduleをinstallしなくてすみ,アプリのサイズが小さくできる.」

という事が出来ちゃうんです.

今回はApp Bundleの部分は実装の仕方を学んだだけで実装してないです.(てへ)

逆に欠点は,

build.gradle書くのが面倒な事くらいな筈です.

dep.gradleはバージョンの競合が発生しないように使うとしても,分けすぎちゃうと悲しい事になります.

今回モジュール分けする上で特に気をつけたのは,App Bundleに対応できるような設計.全ての親である所のapp moduleからinfra周りを見る事が出来ないようにする,1Activityにつき,1モジュール群(例:aouth)を作る事です.

Flux

詳しく勉強したい人はググッてください.それか以前書いた私のブログを読んでくれると嬉しいです(((o(*゚▽゚*)o)))

Presentation Layer で,Fluxを採用しました.

この主な利点は,

1.コードを分散させる&Actionを見ればだいたいなにしてるのかわかる事により,より読みやすい簡潔なコードになる.

2.FragmentやActivity間の通知が,楽に行えるというのがあります.

が,今回2つ目の利点を生かし切りませんでした。゚(゚´ω`゚)゚。

理由は,

ライフサイクルがFragmentに依存したStore間でFragmentが同時に生きているという状態が存在しないのにも関わらずActionの通知を行えないので、この状態を解決すべくBaseとなっているActivityのライフサイクルに依存するMain Storeとかを作りたかったのですが,書く時間がなく諦めたからです.

悲しい.

設計に関してのまとめ

全体としてアプリが大きくなっても,綺麗な可読性の高いコードのままでいられる事を目指してこの形にしました.

  • Kotlin Coroutineを使う事

(もともと色々書いていたがデータが吹き飛んだ)

大変だったこと

書き方が変わってしまったばっかりのCoroutineの使い方がまじで意味わからなくて大変でした.(書き直す必要があるとこあると思います.)

(もともと色々書いていたがデータが吹き飛んだ)

ほんとは実装したかったこと

  1. 詳細画面の作成.(Gist Listを眺めれるだけなんて実用性皆無!!)
  2. gradle をkotlin でかきたかった.
  3. AACのNavigation,MotionLayoutを使いたかった.

かかった時間とか

書き始めたのが,10/11?,提出したのが,10/24 (23:50過ぎ)の2週間弱.

かと言っても,普通にレポートや,TOEICの勉強をしてたわけでまじでやる気を出したのは最後の2日くらいだった筈です.

val.1で作った時のコードがあったのもあり,通信周りで引っかかることがあまりなかったのが大きかったです.過去の自分の遺産大事👑

感想

ちなみに前回は,最低要件でもない自分が欲しい機能に力を注ぎすぎ,その上,3割程度しか理解できてなかったであろう以前までに一度も使ったことのないライブラリばかり使って死にました.

人間って成長するんですね.

なのでそのやらかした反省を踏まえ今回は,評価される基準にそって作りつつ,自分の無理しない程度に新しい技術を使いつつ作りました.

(もともと色々書いていたがデータが吹き飛んだ)

Androidとか設計に興味ある人は話しかけてね!

(もともと色々書いていたがデータが吹き飛んだ)

    Hana Kondo

    Written by

    A Student of National Institute of Technology. I like Android and Kotlin.

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade