kalaclista personal instance

個人的にはプログラミング言語への好き嫌いはあっても良いとは思っていて、私も Ruby と Python と PHP は食わず嫌いしてる。

まぁ昔ちょっとだけ齧った事はあったけど全部忘れてるし、出身母体が Perl コミュニティなので、なんとなくのライバル意識みたいなのがある。

とは言え近年では AI 関連は Python が必須、元スタートアップでは Ruby (Rails) 、普通の Web サイト保守では PHP が使われている印象で、Perl はあんまり居場所が無いんだけどね……

プログラミング言語、 複数修得しておくとプログラムでの表現力が上がる印象。あと言語 A だと使える技法だけど別の言語 B だと別の方法を採る必要がある、みたいなケースでは修行になるので、その点でも良い

今回の LRU Cache の実装ではポインタベースの無限リストを作る際に next や prev を使うと混乱する、と分かったので、今回は front と back と言う表現を使った

つか Go で Zero Allocation がカチっとはまると楽しいので、業務ではなく趣味ならそう言う道を通り続けても良いと思う。ただ実装に時間は掛かるけどね

Go 言語で Zero Allocation をするやつ、最初から Zero Allocation を意識して作らないと allocation をが 1〜3ぐらい残って削れないとか良くあるので、結構難しいところではある。

ただ慣れの部分もあるので、Go でライブラリを作るときは常に Zero Allocation で作るようにはしている。その方が早いし、修行にもなるので

今回作ったものは In-Memory な LRU Cache の Go 実装なんだけど、どこかにバグを作り込んでいる予感しかない……

あと Zero Allocation で作ってるので、たぶん早い（？）はず

ライセンスとか API のドキュメントとか何一切用意していないんだけど、 この辺りはまた後で用意する予定です

• https://github.com/nyarla/tinylru

作った:

• https://github.com/nyarla/tinylru

ちなみに弊個人インスタンスも以前 1k クラスのフォロワー持つ方から Boost されたら沈みかけました。

まぁこれはインスタンスのスペックをケチってるせいでもあるんだけど、基本分散 SNS ってちょっとしたアクションでも DDoS クラスのアクセスが発生しやすいので、中央集権 SNS の方がネットワーク効率やデータ保存効率が良いのは確か。

とは言え中央集権 SNS はネットワーク効果で抜けづらくなった時に鳥化するととどうしようも無くなるので、まぁメリデメ両方ある感じではある

io の村上さんが『分散 SNS は効率が悪い』と言う発言をインタビューでして一部から顰蹙を買っているようなんだけど、分散 SNS と言う仕組み自体、効率は悪いよ。

と言うか分散 SNS って結局はサーバサイド P2P だから、P2P であるが故の効率の悪さは当然あるし、あとプロトコル自体もデータが無限に増えていく仕組みなので、その点でも効率は悪い。

それとフォロワー規模の大きいアカウントから Boost とか renote されると弱小個人鯖が一発で沈むぐらいのアクセスが発生するし、日常的に DDoS クラスのアクセスが発生しやすい分散 SNS は効率が悪い、と言う事はある程度の技術をかじっていれば分かると思う