Runner in the High

技術のことをかくこころみ

gpd-pocket-ubuntu-respinの更新を適用したらファンが止まらなくなった

本日久しぶりにGPD Pocketのコミュニティパッチを更新して適用したところ、まだ44℃だというのにCPUファンが思いっきり回転しはじめた

おそらくこれはファン周りのデーモンかなにかがうまく動いてないな...ということでおもむろにログを確認

 $ journalctl -u gpdfand.service 
-- Logs begin at 金 2018-08-24 17:54:08 JST, end at 金 2018-08-24 18:06:16 JST. --
 824 17:54:10 izumisy-gpd-pocket systemd[1]: Started GPD Fan Daemon.
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]: Traceback (most recent call last):
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:   File "/usr/local/sbin/gpdfand", line 78, in <module>
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:     set_fans(1,0)
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:   File "/usr/local/sbin/gpdfand", line 46, in set_fans
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:     gpio.write(unicode(a))
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]: IOError: [Errno 1] Operation not permitted
 824 17:54:11 izumisy-gpd-pocket systemd[1]: gpdfand.service: Main process exited, code=exited, status=1/FAILURE
 824 17:54:11 izumisy-gpd-pocket systemd[1]: gpdfand.service: Unit entered failed state.
 824 17:54:11 izumisy-gpd-pocket systemd[1]: gpdfand.service: Failed with result 'exit-code'.

変更を遡って見てみると、どうやら以下の変更でIOErrorが起きるようになったっぽい?

github.com

いったんコミットを 7813b8a まで戻して再び更新を適用

$ git checkout 7813b8a
$ ./update.sh

これでとりあえずはファンが静かになった

Golangではinterfaceはどのパッケージに属するのか

Golangを使い始めてinterfaceでDIPっぽいことをしようとするとたしかに湧きがちな疑問のひとつ。結論から言うと、interfaceはそれを使う側のパッケージに所属させるのがセオリーらしい。なるほど。

Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values.

CodeReviewComments · golang/go Wiki · GitHub

なぜか

せっかくなので理由を考えてみた。

以下はJSONXMLなど複数のフォーマットでログを出力できるロガー・アプリケーションのクラス関係図の例。 このアプリケーションの設計は、中核となるLoggerクラスと具体的なXMLJSONなどへのシリアライザ実装がそれぞれISerializerインターフェースという抽象に依存している典型的なDIP(依存性逆転)だ。LogParamsクラスは、ログとして出力するデータの内容を保持しているものとする。

f:id:IzumiSy:20180819114326p:plain

それぞれ、黒矢印は「利用」、白矢印は抽象に対する「実装」、点線の矢印は「依存」を表している。

まず、このアプリケーションにおいてserializerパッケージというのは「どのように出力するか?」のHowが所属するレイヤであり、一方でmainパッケージはアプリケーションのビジネスロジックとして「なにをするのか?」のWhatが所属するレイヤにあたる。

そう考えると、具体的な実装を持たないinterfaceであるISerializerが、「出力の方法」を責務として所属させるべきserializerパッケージにいるというのは違和感がある。なぜならinterfaceは単なる「使い方」を示すだけのものであって具体的な実装を持つものではないのに、Howが所属するパッケージにいるからだ。このような理由で、interfaceはそれを使う側に配置するのがよい、というプラクティスに合点がいく。

(ちなみにではあるが、そもそもこの関係図だとmainパッケージとserializerパッケージが双方向依存になっているため、Golangではコンパイルの時点でエラーになってしまう)

f:id:IzumiSy:20180819115021p:plain

ということでISerializermainパッケージに所属させる。

パッケージ内での依存関係はいくら循環していようと構わないので、これは問題なく動作する。また、ISerializerインターフェースが実装先のパッケージから切り離された。これで正しく「使う側」に所属させることができた。

DDD的な観点: 例えば今回のISerializerに当たる部分が、DDDでいうところのリポジトリであると考えてみる。そう考えると、リポジトリドメイン層のインターフェースに当たる部分なので、リポジトリの具体的な実装のパッケージにそれが所属するのは解せない、というのがしっくりくる。意図せずここで不思議なつながりが見えた気がする(?)

依存関係について再び考える

izumisy-tech.hatenablog.com

  • あとからこの過去記事を読み返して「ムム」と思うところがあったので改めて。

  • CategoryId ではなく Category を引数として渡すことでデータ構造が隠蔽されているという旨の説明をしているが、これは fetchArtclesByCategory を呼び出す側の責務が「Categoryの データとしてIDが取れる」という知識を持ってしまうのを防げるという意味で書いたのではないかと思う。

  • けれどもその実装だと、結局 fetchArticlesByCategory 関数側が、引数として受け取る Category からIDを取り出すという処理をせなばならず、ID呼び出しでないという設計指針が fetchArticlesByCategory に対して Category への依存を与えてしまっている。

  • この依存が別に構わないという可能性もあり、たとえば Categoryドメインモデルなのであれば、そのドメインモデルに対して単方向の依存を持つクリーンアーキテクチャ的観点でいうところの外部のレイヤとして fetchArticlesByCategory が存在していると考えることもできるので、さほど問題を感じなくなる。

  • ところで fetchArticlesByCategory 関数を呼び出すのは、アプリケーションの責務のうち誰になるのだろうか... またまたクリーンアーキテクチャを考えてしまうが、おそらくユースケース層ではないかと思う。

  • DDD的観点: CategoryId を渡す場合においての別の懸念点としては、もしも CategoryIdCategory という集約ルートにおける値オブジェクトだとしたら、それを CategoryId 単体で受け取ってしまえるインターフェースもった関数 fetchArticlesByCategoryId があることで、利用者によって不変条件を保たずにつくられたおかしな CategoryId が渡ってくる可能性があるのではないかということ。正直ここは実装の問題のような気もするけど...

クラウドバンクをやっている

OneTapBUYをやっていたときもこういう記事を書いていたので今回はクラウドバンクについて書く izumisy-tech.hatenablog.com

つい最近クラウドバンクも始めた。いまのところ投資額はOneTapBUYと同じくらいだが、パフォーマンスで言うと年6〜7%といったところらしく、さほどリスキーではなさそうな利幅でよろしいと思う。こちらもどういう風にお金が増えるのか楽しみだ。

ちょうどこの記事を書いた2017年の10月から始めていた。結論からいうと、自分のクラウドバンクのパフォーマンスは年利で3.8%という感じになっている。

f:id:IzumiSy:20180805121827p:plain

今現在で80万程度つっこんでいるわけだが、それで増えたのが1.8万くらい。こう見るとOneTapBUYにもっとお金を突っ込んでいたほうが今頃には利益がもっと出ていたかもしれない。

2017年の10月の記事ではOneTapBUYでは12万で1万の利益がでている! みたいに書いたが、その翌月には5000近くまで下がってしまっていた。もちろん株なんてものはそうやって上がったり下がったりするものではあるが「こういうの、いつも気になってしまってソワソワしてしまうな〜」という感覚を持った。その当時はまだ学生で毎月定期的な収入があるわけでもなかったため、いわゆるドルコスト平均法のような積立戦略を実践するにも難しさがあり、短期的な売買に終始していたからという理由もある。

その点クラウドバンクはある意味ただの投資に近いので、自分の利益が上がったり下がったりするのを見る必要はないし、そもそも見えない。預けたものに毎月分配金がつくだけでシンプル。見方を変えれば、株と違って自分で取捨選択をしている感覚がないので、地味といえば地味ではある。とはいえ、社会人にもなるとそんなに毎日自分のポートフォリオの上がり下がりを見ている余裕はそんなにないので、どちらかといえば勝手に誰かがやっていてくれるほうがうれしいというものだ。そういう理由もあって2017年の11月にはOneTapBUYで投資していた分を5000円プラスで売却し、クラウドバンクに突っ込むことにしたのだ。

f:id:IzumiSy:20180805122942p:plain

ココ最近のペースでは毎月3000円くらいの分配金が入ってきている。毎月一回くらい飲み会にタダでいける程度ではあるが、それでもこうやってお金が増えていく様子をみるのはうれしいものがある。

JavaScriptにおける配列操作の計算量オーダー

日本語だとググっても出てこなかったのでまとめた

操作 計算量
添字アクセス O(1)
挿入(splice) O(n)
削除(splice) O(n)
削除(delete) O(1)
最後に追加 O(1)
先頭に追加 O(n)
スワップ O(1)

添字アクセスがO(1)だったりするのは、JavaScriptの配列は連結リストなどではなく単なるインデクスをキーで持つObjectだから。

ちなみにdeleteを使った削除というのはspliceと違って要素がundefinedと交換されるだけのものなので後続要素への走査が走らないためO(1)になる。

参考: https://stackoverflow.com/questions/11514308/big-o-of-javascript-arrays