IT関係」カテゴリーアーカイブ

おうち情報化2017.1

Wunderlistまじ便利。

https://www.wunderlist.com/

家庭内のコミュニケーションは効率化したいじゃないですか。

我が家の場合、朝起きてから出かけるまで1時間もなく、帰ってくる頃にはみんな寝ていることもあって、平日全然口を聞かないことが割とよくある。
(と言っても帰ってくるのは9時前後くらい。生活サイクルが早寝早起きなんです。)

そんな訳で効率化です。このままでは家庭崩壊待った無し!!

最初にオチを書いたけど、うちではWunderlistが大活躍しています。
その前はGoogle Keepも試していたけど、今はこのサービスがしっくりきてます。

  • 2人の共通タスクが作れる
  • タスクの中でコメントできる
  • 定期タスクが作れる

主な利点はこんな感じ。

具体例を挙げてみます。

買い物

概ね夕方になると日用品で不足しているものが家族の買い物タスクリストに追加されていきます。
牛乳とか卵とかそんなやつ。

それを帰りにスーパーに寄ってカゴに入れながらポチポチチェックして片付けていく。
うっかりオムツが足りないなんて時は、即座にAmazon Prime Nowなんかも使ったりするけど。

相談事

家族のイベント毎の準備とか、保育園がらみの相談は、家族タスクリストに追加しておきます。
タスクの中でコメントがやり取り出来るので、LINEみたいに流れずに結論までたどり着いて、それを残しやすい。

定期作業

家賃の支払いとかゴミ出しとか、そう言うのは定期タスクで登録してリマインダーをセットしてある。うっかり防止。
まぁ忘れるんだけど。


その他のツール

そのほかにも、いくつかのサービスを使って非同期でもお互いの予定だとか相談事を把握してコミュニケーションロスを減らしている。

Googleカレンダー

Googleカレンダーはお互いに共有して、週末の予定は大体1ヶ月先とかでも分かるようになっているし、とりあえず予定だけ追加しといて週末に相談したり。

Googleカレンダースタートガイド

Slack

slackはそこまで活用してないけど主に自分のために。
出かけたとか帰ってきたとか、WunderlistやGoogleカレンダーの予定が集約されて流れてくるので、あんまり見落とさない。
あとは奥さんにも雑談程度に共有したい記事を流したりとか。

参考: 同棲生活を支えるサービスやbot


家庭内1on1

とは言え直接話す事が一番大事で、話さないとやっぱり家庭崩壊なので、最近家庭内1on1を始めてみました。

家庭内 1 on 1 ミーティングのススメ

土曜日の朝食後に30分程度。

ざっくり言うとKPTと共有事項の確認と言うお仕事ライクな感じになってしまうけど、今週のよかった事や悪かった事、来週試してみる事を確認する時間です。
よかったことを振り返るのは悪くない感じ。

ちなみにこれには上の子にも参加してもらってます。
1人でトイレに行けて偉かったね!とか改めて褒めたりしています。
誇らしげなので良いんだと思う。

結婚したころからGoogleカレンダーの共有はやっていて、これだけでも随分スムーズだったけど、
Wunderlistでさらに効率化された感じがする。

自己満でない事を祈りたいですね。

CleanArchitectureとMVPの雰囲気でRxJavaも加えて

最近、お仕事でリファクタリングをやっていて、やっと落ち着いてきた。
最近の潮流を取り入れてCleanArchitectureの雰囲気の中でRxJavaを使ってみた。

参考にしたのはこんな記事やリポジトリたち。
参照はできないけど隣に座っている方のコードもかなり参考にさせていただいた。(頭が上がらない)

それで、昨年末あたりに手を動かすためにapproomに適用してみていた。

がこれはホントに申し訳ないがめっちゃ中途半端な状態である。(最後のコミットが[wip] w

が、上の記事の日付からも分かる通り、2016年時点で割りとデファクトになりつつある手法であるので、基本的には豊富な記事とStackOverflowに助けられてリリースにこぎつけられそうな状態までもってこられた。

現状はData、Domain層の構築とPresentation層へのつなぎ込みまでができていて、Presentation層は実際は既存の構成ほぼそのままな状態。
Presentation層もきちんと作れればActivityのライフサイクルから切り離された純粋なViewのテストが容易になるので、少しづつ移行していきたいところ。

良かった点

そんなわけで良かった点は

  • Domain層が出来たおかげでデータ処理をActivityから切り離すことができた。
    • 例えば、この画面は追加でキャッシュを効かせるようにしたい、と言った変更を行う際に画面側に手を加える必要がなくなった。
    • UIの状態から切り離されたのでさくっとテストが書けるようになって、実際ずいぶんテストコードを増やすことができた。
  • 並列処理にRxJavaを使うことでデータの流れが簡潔になった。
    • 入れ子のAsyncTaskでActivityのメンバ変数にアクセスしてあれこれみたいな辛いコードが一掃された。
    • これはデグレの危険もあったけど、可読性が上がったのと前述のテストコードが増えたのとエラーハンドリングの改善で、メリットのほうが大きかったと思っている。

辛かった点

逆に辛かった点ももちろんあって

  • よくRxJavaは学習コストが高いと言われるけど、これは本当にそうで未だに膨大な情報と機能を全部把握できているとは言い難い。
    • 手を動かして事前に検証していたものの全然足りず、前半のコードを後半一部書き直したりしていた。
    • RxJavaと一口に言っているけどタイミング的にギリギリ採用したのがRxJava1系でメインストリームは2系に移っていくので、移行も考えないといけない。
    • でもまだ移行の必然性と言うまでは高まっていないので様子見。多分個人では今後2系を使うだろう。
  • このぎょーむをしている間、ひたすらIDEとUnitTestの結果を眺める日々だったので、ちょっとつらかった。

RxJavaのエラーハンドリング

ところで、RxJavaのエラーハンドリングが一番つらかった。
最終的にはテストコードで動きを確認して肌で覚えていったけど、どういう時は最後のObserverまでエラーが到達するのか、到達せずにExceptionが起きてしまうのか、最初は本当に良くわからなかった。

参照していたのは以下の記事たち。今読むと、分かる。

当時のメモ(つらそう

- toListする前にExceptionがおきると受け取る人がいないので落ちる
- single, firstは、Observable.emptyを返した時は対応できない。
  - singleOrDefaultなどdefaultValueを定義することで対応できる。
- Observable.createは予期しないExceptionに対応できないので、できるだけ使わない

そんな訳で、もうすぐこの改善が入ったアプリがリリースできそう。
たぶんパフォーマンスも上がっているはず。