寒い中暖かい布団は正解だったかもしれないお話
こんばんは。テスト前なのに開発に逃げたりしているふぇりです。
今日はテスト科目であるコンピューターグラフィックスや小論文をやりながら、TEDを漁っていました（います）。
そこで、Matt Walker氏のSLEEP IS YOUR SUPERPOWERを見ていました。
この途中、walker氏は眠りにつき睡眠を継続させるには、深部温度を摂氏1~1.5度ほど下げるといいと述べています。(抜き出しミスがあるかもしれません><)
ここで私はおもいだしました。
夏にクーラーを利かせてあったかい布団をかぶるのが好きだったけど、もったいない、温度をあげなさいとお母さんに怒られていたあの日々を（母さんごめんあげたふりしてた）
眠りにつくまではあったかいほうが好きで、寝た後暑いのは嫌だというぜいたくな性格でそれをしてたのですが、この話を聞いたときに、科学的にも証明されているのかと私は思ったわけです。
布団かぶったままだと暑いままじゃんと思う方がいると思いますが、私は寝相が悪いので、ミイラのように布団をまかないと朝起きた時には布団が逃げています。（布団のせい）
そのため、実質睡眠導入時は暖かく、眠りについたら布団が逃げるので冷たい外気に触れて深部温度がさがって睡眠が継続する。
という科学的理想ムーブを実現していたことになります。
これは使わない手がないですね、全国の冷たい中布団かぶりたい寝相が悪い人たちは、このLTを見せて説明しましょう！
私も「温度をあげたふり」をしていたところは消して親にこの記事を他人が書いたかのように見せようと思います。
競技プログラミングをした話
こんばんは。ふぇりです。
最近スキルチェックの選考を受けることが多いのですが、そこではスキルチェックに競技プログラミングを使用しているため、それをしていない状態で受けると壊滅的なコードを書いてしまうことになるので、勉強しています。
今の時期にやることか...と言われるとぐうの音もでないのですが、楽しいと感じたので、並行して続けていければいいなと思います。
API呼び出しってコルーチンとスレッドどっちがいいのだろう
こんばんは。ふぇりです。
今日も今日とてコルーチンで詰まっていたのですが、（レポートなどでずっと触っていた訳ではないが）API呼び出しってコルーチンとスレッドどっちがいいのだろうとふと思いました。
そうして調べていくと、スレッドはガベージコレクションやオブジェクト割り当て時にオーバーヘッドがあるらしく、多くのスレッドを立ち上げた際にアプリのパフォーマンスが著しく低下する問題を抱えている。
それを取り払って安価に使えるようにしたのがコルーチンとのことでした。
それだとしたら小規模アプリならスレッドでもいいかななんて考えたりしたのですが、やはりコルーチンでパフォーマンスを上げていくしかなさそうです....
Kotlin1.3のコルーチン周りの資料が薄いなと感じているので、色々調べながら実際に試して行けたらなと考えています〜
世界主義と大衆主義ってなんだろう
イギリスのEU脱退スピーチを何度も聞いていたのですが、気になったところは
「It is globalism I get populism」
のところでした（聞いたまま書いただけなので文は間違っている可能性大）
このセリフは、
現在歴史的争いが行われている、世界主義と私たち大衆主義だ。
という部分のものだ。
そもそもなぜイギリスはEU脱退したんだろうと思うほど知識が浅いので、のちのち調べていこうと思います。
今日は世界主義と大衆主義って何が違うの？と感じたので、ざっと調べてみました。
大衆主義はWikipediaでは、
ポピュリズム（英: populism）(平民主義）（公民主義）（人民主義）（大衆主義)とは、一般大衆の利益や権利を守り、大衆の支持のもとに、既存のエリート主義である体制側や知識人などに批判的な政治思想、または政治姿勢のことである[1][2][3][4]。日本語では大衆主義（たいしゅうしゅぎ）や人民主義（じんみんしゅぎ）[5]などのほか、否定的な意味を込めて衆愚政治や大衆迎合主義（たいしゅうげいごうしゅぎ）[6][7]などとも訳されている。
世界主義は
世界主義（せかいしゅぎ）
コスモポリタニズムというものが今回の意味と近いと感じたためさらにリンクをたどってみると
コスモポリタニズム（英: cosmopolitanism）とは、人間は理性をもっている点で平等なので全ての人間は尊重されるべきであるという思想。世界市民主義・世界主義とも呼ばれる。コスモポリタニズムに賛同する人々をコスモポリタン（訳語は地球市民）と呼ぶ。
コスモポリタニズムの発展的・急進的形態として世界国家構想が挙げられる。これは「人種・言語の差を乗り越えた世界平和には全ての国家を統合した世界国家を建設すべきである」という考え方に立って主張されたものである。
現在においてこの構想に似た理想を掲げている組織はEUだが、EUはあくまでヨーロッパ圏内の統合を目指すものとされており、世界国家或いは世界政府を志向するものではない。
と記されている。今回論文などではないのでWikipediaから引用しています。ご容赦くだされ....
なるほど？
大衆主義は大衆の支持を受けて利益・権利を保障するために動く政治思想で、国家などに対して批判的な思想で
世界主義は世界みんなで国家統合して仲良くしようねという思想なのかな？
確かに大衆主義と世界主義はだいぶ違う政治思想ですね。
大衆主義は利益を尊重して、世界主義は協調を尊重するような考え方という認識でいいのでしょうか。
資本主義と社会主義に似たようなものを感じました。
スピーチ最後の
国旗を禁止したいのだろうが私たちはさよならを言うために国旗を振ろう
という所が最高に皮肉が聞いていて好きでした。
ほかにも脱退のメリットとして挙げられていたものを調べていけたらなと思います。
KotlinのコルーチンとDBの結びつけが難しい...
こんばんは。ふぇりです。
DBの設計がだんだん以前のような汚さになってきていて悲しみに打ちひしがれています....
綺麗に実装したいではあるのですが、JSONのパースなども入れてしまうといかんせんコードが増えてしまいます...
将来的にどのAPIからとるかユーザーが決められるように分岐させたりしているのも問題だと考えています。
Repository側の問題をViewやPresenterに持ち込まないように処理はかけているので今のところ順調なのですかね（？）
問題の一つとして、コルーチンを用いて非同期処理でAPIをたたいているのですが、早期リターンをされてしまっていて、これからも非同期処理は使うと思っているので、深めに勉強しています。
awaitなどがあればすぐに導入しようと考えています。
データ取得自体はできているので、関数内でregistを呼び出して登録するのも考えたのですが、localとremoteはクラスを分けているのでそれをなるべくしないように設計していきたいと思います....!
今回の知見を活かしてアーキテクチャを選定設計するのが楽しみで仕方ないです...!
こいつを仕上げて次はもっと質がよくて効率的な開発を目指す！
（今回も目指しているが）
読書管理アプリの進捗
こんばんは。最近睡眠の質が上がってきたふぇりです。
読書管理アプリの進捗なのですが、思っていたより難航しています....
正直なところ今ぶち当たっているコルーチンとDIの壁を突破することができればあとはデザインなどの問題なので、いったんリリースしてからのちのち整えていく方針を取ろうと考えています。
学習しながら並行して進めていっているので開発効率で言うとなかなかに低いのが難点ですが、DI（Dagger）とコルーチンを味方につけることができればそれ以上の効果が見込めると思うのでもっと粘ってみます！
今壁に当たっているのは関数内で新しくコルーチンをlaunchしているのですが、処理が終わる前にほかの処理を進めていて処理が中断されているので、waitをかけるかと思っていたのですが、今一度コルーチンの基礎に戻って検討しています（もともと学習が浅かった）
ここで思ったのが、MVPではなくMVPではなくMVVMにしたほうがよかった...
(動的にデータを追加したり、データ表示を変えたりする面でBindingが生きるので...)
経験値がたまったと思っていったんMVPで作っていきます！
公式リポジトリのガイドなどを見ているとだいぶわかりやすく書いていただいていて、効率はだいぶいいと感じているのですが、いかんせん英語....
卒業研究で英語の論文をだいぶ漁ると聞いたので、そこで英語力が鍛えられてくれたらこの方面でもだいぶ活きそうな気がしていてその面でも研究が楽しみ！
DIを再度学習中
こんばんは。ふぇりです。
読書管理アプリをそろそろ完成させてリリースしないと時間かかりすぎだなと最近しみじみ感じております。
今日はDIを導入するべくDaggerを再学習しました。
(DIは後回しにしてアーキテクチャに沿って作って早くリリースしてといわれたらそれまでなんですが....)
DroidKaigiのDBのDIを読ませていただいたのですが、これまたとても勉強になります....
アノテーションなどは理解が全く不足しているのでそこは弁っ供していくのですが、
DaggerHogeComponent.builder()をCompanionObjectにしてActivityに持たせるというのが大体の記事で見ていたりして多い印象を受けたのですが、DroidKaigiのアプリではComponentのほうでCompanionObjectにしていました。
私自身もこの実装の仕方が好きだなと感じていて、理由としては、コードを追っているときに探しやすい点と再利用をする際に機能がまとまっていてやりやすいなと感じたからです。
これに関しては賛否両論あるらしく、Activityに持たせるべきという方もいらっしゃったので、その意見も見てみて自分の中に落とし込んでいきたいと思います。
余談
余談なのですが、qiitaの記事を見ていると、Injectの仕組みが紹介されている記事を発見して読んでいました。
その際にInjectorというクラスにProviderというクラスを渡してInjectorが依存性の注入が必要になったときに、そのインスタンスの値にProviderで作成したインスタンスを注入する。
という処理の流れだと自分は理解しました。
ここから私は、あるインスタンスを作成する際の窓口をDaggerが担ってくれている。
だから、インスタンスの差し替えが容易になってテストがしやすいものになっているのかなと思いました。
mock等も勉強できていないので、DIを一通り導入できたらいったんリリースしてテストコードを書いていこうかな....
(デザイン.....デザイン.....)
