ハンバーガーのブログ

いろいろ書く

DroidKaigi2019/02/08(二日目)

Android App Improvement Challenge Part1: 機能実装編

  • 機能追加した
  • 30分だけ参加だったのでリストに時間を表示するissueのみ

Slice Your App: Inside Slices and How to build it

  • Google検索やAssistantにコンテンツ表示する際に使用する
  • AppIndexingの仕組みと一緒
  • Sliceのスレッドで通信やレスポンスを一定時間内に返却できない場合に死んでしまうので、一度ローディングViewを表示した後データ取得後に再描画すれば良い
    • Sliceはアプリ内ローカルデータしか表示できないものだと勘違いしてた
  • パラメータとして時間を持っているため、単純比較のassertではテストできないので、パラメータを適切にフィルタリングする必要がある

Android App Improvement Challenge Part 2: リファクタ編

  • ヒントブランチ読んでたら終わってしまった・・・

Android Studio設定見直してみませんか?

  • とにかく楽しめた
  • 自分用リストを作ることに決めた

今日から始める依存性の注入

  • 外部から依存関係を注入することで疎結合を実現する。それをすることでアプリを拡張しやすくなったりテストしやすくなる
  • DIにもスコープがある
  • なんとなくわかってきたらgithub上のコードを読んでいくのが理解への近道とのこと

multi-module Androidアプリケーション

  • メリット
    • ビルドの高速化につながる
    • build variantの変更で開発ビルドを分けている場合、プロジェクト外のコードはリファクタ対象外なので修正しづらい。その辺が解消する
  • compile→api or implementationに変更
  • api 参照先が変更されたらすべて再コンパイル
  • implementation 直下が変更されたときだけ再コンパイル
  • どのような構成だと恩恵を受けられるか
    • 資料参照
  • 既存モノリシックプロジェクトをマルチモジュール化する場合
    • 一旦最低限必要なもの(applucationクラス)とそれ以外で分ける
    • 新規機能は個別のモジュールに
    • 新規機能と既存機能で共通する機能を別モジュールに
    • 既存機能は必要以上にモジュール分割しないほうが良い(機能開発が進まなくなるので)

実践 WorkManager

  • WorkManagerを使ってバックグラウンドで画像をキャッシュした話
  • タイムアウトがあるので分割必要

Google Play Consoleのリリーストラックを有効活用してリリースフローの最適化を行った話

  • masterブランチを自動でアルファリリースするようにfastlaneを書いた
  • リリース前レポートを軽いテストとして活用しようとしたが、通知が貧弱だったため断念
  • アルファ→本番リリースは手動

DroidKaigi2019-02-07(一日目)

ウェルカムトーク

  • 最初のムービーかっこいい

マルチモジュールなプロジェクトでテストはどう変わる?

  • テストを書く意識は上がった
  • PITが便利そうだった
    • コードの変更で今書いているテストが失敗するか?を確認することで、テストケースの妥当性を判定してくれるライブラリ

マルチモジュールプロジェクトでのDagger2を用いたDependency Injection

  • DIの利用により疎結合となり、コンポーネント間の依存性が下がることで、テスタビリティが上がる
  • Daggerは どこに 何を injectするかを定義する
    • 何を → module
    • どこに → component
  • fragmentInjectorが複数のinjectorを持てるように実装することで、マルチモジュールにも対応できる

LiveData と Coroutines で実装する DDD の戦術的設計

  • 昨年よりも、より実践に近いDDD講座
  • 話すペースや声のトーンがちょうど良く、すごく聞きやすかった。
  • ユビキタス言語を探しながら、値オブジェクトやエンティティを定義していく
  • idをIntではなくエンティティにするという発想が新鮮だった
// OK
  data class Session(val id: SessionId)
  data class SessionId(val value: Int)
// NG
  data class Session(val id:Int)
  • モデルの形式が保存形式(DBの情報)と一致させる必要はない
  • 例えば、セッション一覧に表示するイベントとして、通常のセッション以外にもウェルカムトークやランチタイムを表示する場合
    • DB的には、Eventテーブルにtypeをもたせて保存する
    • フロントのモデルとしては、typeを使わなくても、 seald class で表現できる
  seald class Event {
    abstract val id: Int
    abstract val userName: String
    data class Session(override val id: Int, override val userName: String,  val title: String) : Event()
    data class Lunch(override val id: Int, override val userName: String) : Event()
  }

ぼくのかんがえた最強のUsecaseの作り方~あるいはビジネスロジックとはなにかという1つの回答~

Redux for Android

  • Reduxについてに実装例
  • オフィスアワーで聞いてみた
    • Q: Storeの初期化はApplicationクラス?
      • A: Dagger使ってるので、そっちで管理されてる。ライフサイクル的にはApplicationと同じ
    • Q: FatStoreにならないか?
      • A: 現状困っていない。ストアが持つ情報がネストしていくので、深くはなるがFatにはならなそう
    • Q: 画面遷移などはReduxで管理しないなら、どこに書く?View側
      • A: Activityなどで、startActivity()やfinish()すればいい
    • Q: マルチモジュールになったらどうすれば
      • 後ろがならんでて焦ってたのか、聞いた内容忘れてしまった・・・

Fireside Chat

  • 何を考えたか、何に苦しんだかをカジュアルに語ってくれた
  • 理解できないところもあったが、こういう情報はなかなかウェブの情報として上がってこないので、すごく助かる

感想

  • 今年は2回目ということもあり、多少余裕があった。
  • コントリビュートできたし、意識して前に座るようにしたし(去年はずっと後ろの席)、オフィスアワーで初質問できた
  • 2日目も頑張る

今日の振り返り

  • kotlin1.3に対応しようとすると、いろいろ影響がでる
    • ライブラリのアップデートが一番つらい
  • PayPayは1000円だと使うモチベーションにならん
  • QR決済のプラットフォームに限って言うと、楽天ペイが唯一ほかサービスとの連携がうまくできてて一つ抜けてる感じがする
    • PayPayもLineも(メルペイも)、サービス単体で使うイメージが強い
  • 今日は暑かったらしいが、朝涼しい、昼社内、夜寒いで、全然実感なかった
  • 昨日ダイエーで騒いでたタイ人風の女を見かけた
  • 月初だからかやたら新入社員の人が増えた気がする
  • DroidKaigi楽しみ

メモ

  • swaggerでapiIF書く
    • 前よりもすんなり書ける様になってきた気がする。
  • deeplink,app indexingの調査
  • ウォーキング・デッド3話
    • 早くショーンが痛い目にあえばいいのに
  • ビール3本飲む
  • 三角チョコパイ美味しい

Androidのマルチモジュール

安心してプロポーズするためのスケジューリング

美容院に行ってきた。担当の人がクリスマスにプロポーズ成功したそう。
人間的に好きだったからすごく嬉しかった。

ただ当日は大変だったらしく、

  • 目当てのイルミネーションが今年はやってなかった(その場についたときに気づいた)
  • 別の所は混んでて体力消耗した
  • 彼女が行きたいと言ってた場所に行く予定が、疲れて行きたくないと言われた

なんだかんだでいろいろ頑張ってプロポーズにこぎつけたらしいが、その話を聞いて学んだことがある。

プロポーズはデートの早い時間にやっておいたほうがいい

理由はいくつかあって、

  1. 早い時間ならトラブルがあっても後の時間にずらせる。遅い時間にトラブルが起こるとリカバリできず特攻するしかない。
  2. 遅い時間にプロポーズ成功すると、上がったテンションの発散先が限られる
  3. 遅い時間にプロポーズ失敗すると、下がったテンションと夜の暗さで精神的な落ち込みが倍増する
  4. 早い時間にプロポーズ成功すると、その後のデートをずっと楽しめる
  5. 早い時間にプロポーズ失敗すると、早めに予定キャンセルできるので損失を最小限に抑えられる

もちろん、マジックアワーの力を借りてドラマティックでムーディーなシチュエーションでプロポーズできると最高だと思うけど、はじめてのプロポーズは余裕がないしやばいくらい緊張した

ホームランが理想だけど、大事なのは三振せずヒットを打つことだと思う

DIについて調べた一日

DroidKaigiのリポジトリを見たけど、全然わからん
そもそもDIについてわからんってことで、今日はずっとしらべてた。

とりあえず、依存性注入のイメージとDIのメリットがふんわりと理解した。
dagger2を使ったサンプルプロジェクトを作って練習してみる

ちなみに、hamburgergithubアカウントは利用中ということで、使えなかった。残念

Githubアカウント取得してみる

同僚に今年のDroidKaigiのリポジトリが公開されたことを教えてもらい、今年こそはコントリビュートしてみるかと思っていたところこんなニュースが

www.itmedia.co.jp

へっぽこエンジニアの自分はpublicなリポジトリを作るのが怖くてBitBucketを使ってた(BitBucketは無料ユーザでもprivateリポジトリ作成可)が、
これはGithubに乗り換えるしかないと思い、帰ってからアカウント作成した。

ひとまず、hamburger のアカウント名がすでに使われていたので、先人の知恵を使って申請してみた。
今は連絡待ち中。

qiita.com

それにしても、マルチモジュール+Fluxってレベルが高すぎて理解できるか心配しかない

2019年の目標

アプリから収益をだす

2018年は自己満スマホアプリをいくつか作ってみたけど、今年はちゃんとサービスを作って収益につなげてみたい。
ひとまず一本ビールを買うことを目標にやってみようと思う。

体力づくり

週一のジム通いでは一向に変化が訪れないので、週二目標で通う。子供が生まれるまでに体力つけておきたい

プラチナエンド感想

漫画喫茶で8巻まで読んだので雑な感想

  • 絵はきれい。さすが
    • 表紙のオシャレ感はブリーチを超えてる
  • 物語初期に出てくるラスボス感があるキャラは実は噛ませ犬っていうパターンを見事に踏襲
  • 主人公があんなに頃したくないって言ってるのに、仲間たちが結構普通に頃してるのはどうなんだろう
    • 主人公が悩む系の漫画って普通は別の方法を考えて回避するもんだと思うけど、そういう展開にできなかったのだろうか
    • と思ったけど、種のキラ様がやりたい放題だったで悩ましい
  • 戦闘シーンで結構思考の読み合いみたいになってて面白いので、オチも同じくらいの深さがほしい

面白いけど、買うに至らない感じだった

買ってよかった・使ってよかったもの

日用品

クリアケア化粧水・高保湿タイプ

私はいい年して結構ニキビができる体質なのだが、化粧水をこれに変えてからかなり改善された。
無添加だからなのか・・?
無印良品週間にまとめ買いしてる。

www.muji.net

ビールの定期購入

コンビニで購入する商品で単価が高かったビールをamazonの定期便に切り替えた。
結果的に飲む本数は若干増えたが、高いビールの衝動買いが減ったので良しとしよう。
ついで買いもなくなったため家計としてはかなり改善された

月に一つだけバラエティパックも購入して、週末の楽しみにしてる

生活家電

ロボット掃除機 Eufy RoboVac 11

2万円半ばで購入した。 毎日家中を雑に掃除してくれる。
部屋の隅は掃除しきれないけど、これを買ってから家で綿埃を見ることがなくなった。妻がホコリアレルギーなので以前は平日もたまに掃除機を掛ける必要があったが、週末に一度だけで十分になったのでだいぶ助かっている。夏頃に一度壊れたのだが、サポートに連絡したら代替品を送ってくれた。
特に不満ないので、次もこれの後継機を買いたいなぁ

ドラム式洗濯機 TW-117X6L

新製品発表前の8月末に15万弱で購入。
ビックドラムを買うつもりだったんだけど売り切れで、在庫があった東芝フラグシップモデルをこの値段で買えるのか!となってこちらを選択。
新製品が30万以上で販売してるのを見ると、この時期に買って正解だったなぁとニンマリ
これまでは一人暮らし用で2日に一度洗濯・すべてベランダに干す必要があったが、今は一週間分まとめて洗濯してタオル等は乾燥機使うのでめちゃくちゃ楽。
乾燥容量7kgは良いぞ

2019年8月はこっちが狙いめなのかな

webサービス

Google One

あまり聞き慣れないかもしれないが、要はGoogleドライブに課金すること。 2Tで月額1300円

one.google.com

以前は個人でMSのOffice365Soloを契約していて、そこにバンドルされてるOneDrive2Tを外部ストレージとして使用してた。
ただ、以前から夫婦間での写真の共有が課題になっていて検討したところ、夫婦で共有しているGoogleアカウントに写真を放り込むのが運用的に楽だと気づいたので、思い切って移行してみた。
Officeソフトは使えなくなったが、今の所そんなに困ってない。スプレットシート等で代用できるし。
Googleフォトで機械学習を存分に活用できるのでちょっと世界が変わった感ある。世の中の夫婦はみんなこれやれば良いのにと思った。
具体例をあげると、

  • 顔写真で分類できる
  • 日付から、勝手にアルバムを作ってくれる
  • 撮影場所でもアルバムを作ってくれる
  • デジカメの写真に、撮影日時を元にして近い時間に撮影したスマホの写真の情報から類推できる位置情報を擬似的に付与してくれる。
    • これが一番すげぇと思った
    • 説明が難しい。。。

需要がありそうなら今度別記事にしてみようかな

Google Keep

これもGoogle
今までは仕事でもプライベートでも、メモはテキストファイルとして残していた。
ただ、検索やモバイルでの確認に課題を感じてたので、Markdownにする必要がない情報は一旦Keepにまとめてみることにした。
タスクもメモも雑に放り込んでいて、検索性能で補ってる感があるが今の所快適。

chrome.google.com

play.google.com

金融関連

楽天証券

多分この辺の記事に触発されて始めた。

sumaraku.blogspot.com

もともとSBI証券投資信託や積立NISAをやってたんだけど、ポイントとはいえ3%のリターンはすごいのでこれを機に整理。 本当は積立NISAも楽天でやれば良いのかもしれないんだけど、一箇所に集中すると改悪された時とかのダメージがありそうなので一旦様子見。
子供が生まれたら、子供の分の積立NISAは楽天証券にするかもしれない

その他

高圧洗浄機

年末の大掃除の日に合わせてdmmでレンタルしてみた

www.dmm.com

主にマンションのベランダ部分。壁や窓のサッシから、面白いように土汚れが取れた 。
年一でこれやるだけで結構きれいになる予感

HUAWEI端末だけ? "Google Play services art updating"のエラー

2018/05/11あたりから発生中
GoogleMap以外のアプリで地図を見ると表題のエラーになって見れない
ストアのGoogle開発者サービスのレビューが荒れてる

ビッグデータ分析・活用のためのSQLレシピ Chapter2

システム

PostgresSQL

Apatch Hive

メリットとデメリット

  • RDBがレコードに対して処理するのに対し、Hiveはファイルに対して処理をする。
  • そのため、クエリ発行 = ファイルの全件走査になる
  • スループットは高いものの、内部的に複数の手順を踏んで処理を実現しているため低レイテンシを求められるときつい

Amazon Redshift

  • 分散データベースだが、Hiveと異なりRDBに分類される

メリットとデメリット

  • AWSなのでスケールアウトが可能
  • 利用時間で課金なのでインスタンスの起動・終了を意識する必要がある

Google BigQuery

  • こちらは読み込んだデータ量で課金
  • データ量が少ない間は低コスト運用可
  • Googleサービスとの連携も魅力

特徴とデメリット

  • 利用できるSQLは 「レガシーSQL」と「スタンダードSQL」がある
  • クエリが短くても読み込むデータ量が多いと爆死する
  • テーブルやカラムを絞り込む工夫が必要

SparkSQL

  • ApatchSparkの機能の一つ

メリットと特徴

  • ビッグデータの関する機能を一通り揃えているのがSparkのメリット
  • 通常複雑な工程を経て分析するが、SparkはSQLだけでなく各PG言語も対応していて実行できる
  • DataFramesと呼ばれるAPIが豊富でどの言語でも同様の記述で実装できる

データ

データの種類

  • 業務データはトランザクションデータとマスタデータに分類れる
  • いわゆるログだけでなく、サイトに埋め込んだタグデータやサーバ側で意図的に出力したデータもログデータとして扱う
    • ログデータは基本更新せず、追記していく

業務データ

  • データ制度が高いが時期によって変更される可能性がある
  • テーブル数が多い
  • 蓄積方法
    • 全レコード
    • 日付ごとのスナップショット
    • 差分レコードの積み上げ
  • ログデータより正確性は高い
    • ログの場合は送信方法によっては欠損するので
  • サービスの回遊や訪問回数といったwebに関する分析は苦手

ログデータ

  • 業務データでは保存しないIPやcookieといったデータも保存する
  • 集計対象を意識しておかないと制度がブレる
  • 過去データを更新せずに残っている
  • 蓄積方法
    • タグやSDKなど、専用の機能を利用したビーコン型
    • サーバ側で実装した処理で出力するサーバ型
      • サーバ型はクローラの影響を受けやすい事を意識しておく
  • 業務データで分析できないPVや回遊状況の分析に使用する

2つのデータを利用することで生まれる価値

業務データ単体

  • 売れ筋商品の解析

ログデータ単体

  • 専用のタグやSDKを使用することで、ツールのレポートを確認できる
  • ただし、汎用的なフォーマットに対応していることが多いため、カバーしていない独自のレポートは確認できない

2つのデータを利用することで生まれる価値

  • ユーザの流入元の違いが与える売上の違いの調査など

データの利用価値

  • 目標管理
    • 目標に対する進捗を把握できれば、今後の活動を検討、実施を促すことにつながる
  • サービス改善
    • ユーザインタビューではコストや母数の少なさが問題になるが、サンプル数が多いデータを活用することで傾向をつかめる
  • 未来予測
    • データの分析でネガティブな傾向に対して対策が打てたり、レコメンドもできたりする

ビッグデータ分析・活用のためのSQLレシピ Chapter1

データを取り巻く環境の変化

  • 2005年にGAが登場して、分析・解析する仕事が認知されてきた
  • その後GA以外のツールも出てきたので集まるデータが増え、保存場所も一箇所ではなく複数の場所に点在することとなった
  • ビッグデータが注目され始め、活用する動きが出てきた

様々な課題

分析担当者の課題

  • 従来はGAなどGUIで解析できるツールがありそれで仕事を出来ていたが、まとまっていないデータを集計するためにSQLの習得が必須になった
    • BIツールを使うことでGUIで頑張れなくもないが、細かい制御はSQLが必要になる
  • 何を指標とするか、これまではツールが教えてくれていた。これからは指標も自分で決める必要がある。
  • そもそもデータ構造の理解がないと何を集計できるのかがわからない

エンジニアの課題

  • 分析・集積のノウハウがないので解決したい課題がわからない
  • システム開発とデータ分析で使用するSQLが異なる

職種を超える横断的な分析力を身につける

  • データを作るまでがエンジニア、レポートを作るのが分析担当者の仕事として分断してしまうと、レポート用のデータを作るところでつまづく
    • アウトプットとするデータの認識合わせの工数
    • データができるまでの分析担当者の待ち時間
  • 互いが互いの領域の理解をすすめることで、積極的にデータを見に行ける分析担当者やデータ活用をできるエンジニアになることをめざす