DevOps / SRE
speakerdeck.com 新卒で入ったのがB2Bのサーバホスティングサービスの障害対応チームだったので障害に起因する辛みはそこそこ身に沁みていることもあり、SRE的な立ち回りは以前から多少興味がある。
今の会社は専任でSREを置くほどの規模ではないのでサービスのコードを主に書きつつ、サービスインフラの改修などはできる範囲で、となっているが。
その状態でもSLI/SLO/SLAの話とか、観測性(observably)の話とか、色々活かせる話はある。
設計
Service層を設けること自体は良いが、Service Classの命名にServiceという単語を含めるのをやめよう、という話。
Serviceという単語を含めると、Userに関するServiceだからUserService、といったようにカテゴリ分けのような扱いになってしまい、Userに関するロジックが雑多に放り込まれるゴミ捨て場になってしまう。
そうならないようにするためには、命名で用途を狭めて、当初想定していた用途とは関係ないロジックが放り込まれようとしているときに違和感を持つような命名にしよう、という話。
これの本筋とは関係ないが、20枚目のスライドでsignIn関数とsignOut関数を持つAuthServiceの改名候補がAuthorizerになっていたのが気になってしまった。signIn, signOutなら認証なのでAuthenticatorでは？
techracho.bpsinc.jp 上記のスライドと合わせて。
命名について、動詞から始めると十分に用途を狭めつつ変な命名になることが少なそう、というのは確かにその通りだと思った。
これに書かれていて納得した一方で仕事のコードではこれに従えていない箇所がいくつか思い当たるので週が明けたらPR出せそう。
その他
ipfs-book.decentralized-web.jp
デバイスの空きストレージを貸し出すとコインが貰えるブロックチェイン通貨、という話。 背景としてIPFSが出てきてなるほどと思ったと同時に、微妙な噛み合わなさも感じた。
IPFSを知ったのは、修士の頃に研究していた情報指向ネットワークの周辺技術として。
ある程度動いているのは凄いと思った反面、ストレージの確保はどうするんだろうかと思った記憶がある。
その答えがこのFilecoinということなのだろうが、記事中では 断片にアクセスするには、ファイルをアップロードした人物の持つ秘密鍵が必要になる と書かれつつ、IPFSではコンテンツのアドレスさえわかれば誰でも取得可能、というのはどういうことなのだろう。
コンテンツのアドレスさえわかれば誰でも取得可能なのがIPFSであるならば、ファイルをアップロードした人物の持つ秘密鍵は内容の取得には必要ないのでは？
という疑問を抱いたところで頭が疲れたので興味が続けばまた今度。
