松亭での会話を雑にあげてみるはずだった #2
前回の予告通り、 @red_fat_daruma を迎えて、雑飲み#2 を公開する予定だったのでした。
実際に決行してまぁ飲んでる最中に完全に察していたのですが、はい、全カットです。
2回目にしてお蔵入りです。
次回は @maetoo さんをゲストに迎えてリベンジします。
最近ダイジェスト
暇なので最近やったこととかをダイジェストでまとめてみようと思う。
松亭行ってきた
いままではこにふぁーさんがダイジェストを文字でまとめてくれてたけど、今回は初めて音声を公開してみた。
次も音声を公開してみようと思う。ちなみに、この前回の公開時に音声を編集したり、フェードさせたりする技術身につけて満足。
Androidオールスターズ2で発表してきた
Androidオールスターズ2というイベントで登壇者として参加してきた。
それなりに人がいた(100人くらい？)けど、そんなに緊張しなかった。 というのもまさに自分が発表する時間に障害対応してて、発表中気が気でなくて逆に発表は力を抜いてできた、と思う。
iOSアプリを一から作ってみた
作ってみた(まだ現在進行形だけどほぼできた)。 設計としてはMVVMで作っててRxSwift導入した。 はじめはプロトレベルなので至る所にsharedInstanceとしてシングルトンつくってたけど、 テストしづらいのでDIを導入して絶滅させた。
そういえばiOS界隈だとDIをあまり聞かないのはなぜだろう。 DIの必要性とかよく分からない人は下記を見てもらえるといいと思う。
今回はDIライブラリとして、 Swinjectを使った。 自分が普段AndroidでDaggerを使ってやってるものと同じ構成で作った。
各レイヤーでどの具体クラスを提供するかを登録するクラスを作って、Injectorなるクラスを作ってそれをAppDelegateでもたせるようにした。 各ViewControllerでは下記のように、injector.injectを呼ぶ。(appDelegateはextensionで生やしてる。) これで、ViewControllerにインジェクトしたいものがインジェクトされる。
class HogeViewController {
var インジェクトして欲しいもの
func viewDidLoad() {
appDelegate?.injector?.inject(self)
:
}
}
ViewControllerにもAppDelegateにも自分で具体クラスを指定してない(意識するべきじゃないことを意識しなくて良い)こととか、どこにもテスト用のコードを書いてないこととか(よくテストのためのコンストラクタ作ってたりしませんか？)あるけど、詳しいことは希望あれば書こうかなぁ。
swinjectを使ってみた感想として、結構同じようなことを愚直に書かないといけないので、aptのような機構が欲しいなぁと思った。
ポケモンGo
ようやくレベル23になったところ。
上野公園に行ったのだけどすごい人がいた。本当に花火大会でもあるのかってくらいに。 一部の人だけどマナーを守れない人がちょこちょこいるのが気になって、それだけはやめてくれと思った。 人混みで走ったり、急に真ん中で止まったりするのはマジでやめてくれ。
燻製
前々から気になっててのだけど、ただAndroid業界で少し前に流行り「これ今やったらミーハー感でてやだなぁ」と思ってた。 のだが、そろそろその話も聞かなくなってきたので今が機として始めた。
写真は撮ってないのだけど、チーズとウィンナーと豚バラうまい。QOLが上がった。
SAO
SAO新刊読んだ。ネタバレになることを覗いた僕の感想「報われもしたが喪失感ある。」
機械学習
ちょっと作りたいものができて、学び始めてみた。
ひとまず有山さんの本を読んでるところ。わかりやすい。
TensorFlowはじめました 実践！最新Googleマシンラーニング (NextPublishing)
- 作者: 有山圭二
- 出版社/メーカー: インプレスR&D
- 発売日: 2016/07/29
- メディア: Kindle版
- この商品を含むブログを見る
中学時代の相棒が結婚
自分のことのように、それ以上に嬉しい。 滅多にこういうこというキャラクターじゃないしどういう言葉選んでも安っぽくなっちゃうんだけど、心からそう思う。
高校の頃に始めて彼らに彼女ができた時にも同じことを思ったなぁとしみじみ。
アニメLT
資料まだできてません。。
松亭行ってくる
また音声公開します。
松亭での会話を雑にあげてみる
過去2回 @konifar さんによって、まとめられてきた柗亭雑飲み。
今回は雑に音声をそのままあげたいと思います。
下記を念頭に聞いてただけるとありがたいです :bow:
- 思ったより背景が騒がしいのはご愛嬌
- disらないでもらえると、精神安定する
- もちろん、みんなお酒入ってます
今回のキーワードは
- ジト目
- 神回
です。(文字によるダイジェストは需要があるのだろうか？)
次回のゲストは、だるまです。(まだ本人に言ってない)
Todoistが最高かもしれないという話
Todo管理アプリを今までいくつも使ってきましたが、あまり自分のニーズと合わなかったためか長く使うということがありませんでした。 長くても２週間も持たないくらいでした。そんな自分がTodoistを無料会員で使い始めてもう2ヶ月以上経とうとしています。
いろんなTodo管理アプリを使っても上手くいかなかった理由
単純なTodo管理アプリは追加/削除のみの機能を持っています。一覧表示は自分が今結局何をするべきなのか？を明確にするために重要な機能です。 しかし、これには欠点があります。例えば、〈仕事でのTodo〉と〈趣味でのTodo〉があるとします。 その状況で単純なTodo管理アプリを使おうとすると、例えば仕事をしている時、その時にはノイズでしかない趣味でのTodoが表示されてしまいます。
そのため、これをラベルやプロジェクトという概念(Todoリストそのものを複数作ることができる)を用いて解決しようとしているリッチなTodo管理アプリがいくつもあります。 しかし、これらも冒頭に述べたように実用に耐えうるものではありませんでした。
理由は様々ですが、主に二つあります。 一つは、全部入りを一覧表示ができない場合があるということです。プロジェクト別にみることも重要ですが、全部入りで一覧表示することもTodo管理には重要な機能です。 「朝起きて、今日は何をすればいいんだっけ？」ということを確認したい時は、プロジェクトそれぞれ眺めるよりは、すべてを一覧にしたもので確認できた方が一日の計画をたてるのに便利です。
もう一つは、そもそもプロジェクトごとに綺麗に分けることが困難ということです。先ほど仕事でのTodoと趣味でのTodoがある場合を例に出しました。 しかし、仕事でも複数プロジェクトを抱えている場合や、趣味が複数の趣味がある場合はどのようにプロジェクトを分ければいいのでしょうか？ 粒度の一番小さいものを基準としてプロジェクトを作るという解決策が一つありますが、その解決策では気持ち良く運用できないことが殆どです。
Todoistはそれらの問題を綺麗に解決する
プロジェクトをネストで表現できる
プロジェクトをネストで表現することができます。
見ての通り上手く表現できており、どの粒度でプロジェクトを切るか悩む必要がありません。
もちろん、プロジェクト1を選択した場合は、プロジェクト1のスコープでのTodo一覧が表示され、プロジェクト1のiOSを選択した場合はこのスコープでのTodo一覧のみが表示されます。
さらに、プロジェクトにするほどでもない場合はタスクをネストすることも可能です。
どんなプロジェクトに入らないような些細だけどやらなければならないことなどは〈インボックス〉というものがデフォルトで用意されているのでそこに追加しておくと良いです。
〈今日〉と〈7日間〉で全部入りの一覧表示ができる
それぞれのタスクには期限を設定することができ、その期限をもとに今日中にやらなければならないもの、直近7日間でやらなければならないことを一覧表示することができます。
下記が〈今日〉を選択した場合。
下記が〈7日間〉を選択した場合。
自分の場合は、朝にどちらも確認し、ある程度タスクが片付いたら改めて〈7日間〉の方を確認して先に片付けることができるタスクなどに手をつけるようにしています。
他にも紹介したいTodoistの機能やtips
繰り返しという概念がある
〈毎日メールチェックする〉、〈水曜日はジムに行く〉などを追加することができます。
スケジュールの欄を選択すると〈定期的な日付、その他〉というメニューが出てくるのでそこからも登録できますが、タイトルで〈平日〉と打つと自動で繰り返しタスクと認識してくれたりします。
ショートカットキーで追加できる
何か突発的にすることができた時などに便利です。〈今日 ○○さんに返信する〉などと打てば今日という期限付きで追加できます。
自動でインボックスに追加されます。
(githubユーザー限定) プルリク検知で特定プロジェクトに追加
ifttt(リンク付き)というサービスをつかって、Githubにプルリクが来たら自動でTodoを追加するということができます。
自分の場合レビューしなければならない立場なので、重宝しています。
その他にも
綺麗なデザインで操作に迷うことはありません。他のリッチなTodo管理アプリ同様マルチプラットフォームで使うことができます。 ちょっとしたところでも手が届いているなぁという感想を抱いています。例えば、TodoにURLを貼り付けると、ちゃんとリンクとして認識される(マウスオーバーしてクリックするとブラウザが開く)ところとか。 その上まだまだ他にも自分が把握していなかったり、使いこなせていない機能(生産性を測ったり、優先度をつけたり)があります。 そこまで含めて、すべて無料なのです。 機能を解放しすぎで誰もプレミアム会員にならないのでは？と心配するくらいです。
ちなみに課金すると下記の機能が使用できるようです。
- リマインダー機能(メール、SMS、モバイル)
- Todoにコメント
- Todoに添付
- ラベル機能
- フィルター機能
現状でかなり満足しているので、課金する必要性はないのですが、最高すぎるのでもういっそ課金します。
設計と冗長さに対する自分の考え
最近、いろんなところで「設計と冗長さ」に関する議論をして、あらかた自分の考えがまとまってきたので、ここで文字に起こしてみます。
ただ、この話は自分の周りのお話で読者のいる環境には当てはまらない可能性があります。また、説明の都合上言い切っているところがあります。そういう背景の違いや断定の部分は察していただけると。
前提
スキルレベル様々なチーム開発内でのお話です。
設計に冗長さはつきもの
自分の関わるプロジェクトでは単純にMVCにしようといったものではなく、Layered Architectureを採用しよう、◯◯レイヤーを作ろう、◯◯レイヤー間のやりとりはこうしよう、非同期はこうしよう、永続化はこうしよう、などまで考えて、ある程度サンプルも作りそれをチームに設計方針と共有しています。
こうすることで複雑な問題は単純化され、方針が明確で詳細であるので技術レベルに多少の差があっても、設計レベルではほとんど差が出なくなり、だれでもメンテナンスできるものになります。
と、ここまではメリットなのですが、これを採用した時に出てくるデメリットがやっぱり「冗長さ」です。
複雑な問題を単純化するものであるがゆえに、はじめから単純な問題をそれに当てはめるとどうしても「冗長」と感じてしまうんですよね。
そして、それなりのボリュームのソフトウェアを作る以上、複雑度の濃淡はさまざまで、淡い部分においては冗長さが浮き彫りになるわけです。
冗長さがなぜ悪いのか
冗長さが悪い理由を考えると「面倒」などというキーワードが出てきますが、クリティカル性があるように書くと「人の時間を無駄に使ってしまう」でしょうか。
ソフトウェア開発において、時間は限られたものでやはり重要なものです。そういう意味で本当に「無駄」と言えるならやはり「冗長さ」は悪です。
では、どこからが冗長なのか。
「冗長である」という基準はどこからなのでしょうか。「冗長さ」はどうしても主観の域を超えることができないものですが、それでもチーム開発する以上何らかの判断基準は必要です。
MVCのCが冗長だよね、という人は、ではどうしてMとVを分ける必要があると考えるのか？Cが冗長なら、MVも分けなくていいのでは？
こういう会話に対する答えは基準なしでは導けません。
とはいえ、一般的な基準があるわけでもないので、ここは自分なりの答えを出してみました。それがこれです。
そのソフトウェアあるいはそのコンテキストの一番複雑な問題に当てはめても冗長と感じるかどうか。
例えば、先の<ソフトウェアの一部の機能は簡単に実装することができ、そこに関しては冗長に感じる> という事例に対して、この基準を照らし合わせると、複雑な場所において設計は機能しており冗長と感じないので、そのプロジェクトにおいては<冗長ではない>と判断できます。(許容すべき冗長さとしても良いです。)
「Hello, World」を出力するアプリを作る場合を考えます。誰がどう考えてもMVCなどは「Hello, World」を出力する上で<冗長である>ため不要であると判断できます。(例が簡単すぎたかもしれないですが、これしか思いつかず。。)
複雑度の濃淡に偏りがあるとき。例えば、ある機能の塊だけ複雑度が高いという場合、その場合はそこだけをパッケージやモジュールで区切り、区切りによって設計方針を変えましょう。コンテキストごとに設計に一貫性があれば良いと考えています。
この基準にした理由
理由は明確で「設計方針に例外を作りたくない」からです。
たとえば、ここは簡単だから冗長さを除いた書き方にすることを許してしまったとします。 そうなると、開発者によって簡単と感じるかどうかが異なるために設計レベルで箇所によって個人差が生じ、またさらに冗長さを除いた書き方の指針がないとどんどん無法地帯化していきます。 そしてすぐに全体から統一感がなくなってしまいます。統一感のないソースコードをメンテナンスすることは難解ですし、誤解を生みやすく、またバグも生みやすいです。
所感
正直言うと冗長と言っても、よほどでない限りそこまで時間は取られないし、それよりは設計の一貫性を選んだ方が良いのでは？という考えでした。それに何があるかわからないから多少は冗長にやっておいた方が良いだろうくらいの。
ただ漠然と考えは持っていたものの、うまく説明できてなかったので、ここで一度整理できて良かったです。
賛否両論ありそうですが、考えを整理するきっかけになれば幸いです。
