生涯未熟

生涯未熟

プログラミングをちょこちょこと。

Sapporo.sre#0に登壇しました

sapporo-sre.connpass.com

札幌に新しくできた地域コミュニティ、Sapporo.sreに登壇してきました。 当日は昼からオータムフェストに参加して、さらにジンギスカンを食ってから参加するというエクストリームな勉強会参加となりました。

speakerdeck.com

今回はFinOpsの内容として、設定値を変えるだけで年100万円コスト削減できたよという話をしてきました。とあるサイトをがっつりコスト削減策をやったんですが、その中でもかなりインパクトのあったところをネタにしてみました。当日口頭では話したんですが、他のデータベース周りのコスト削減などを含めると、大体約年300万円ぐらいのコスト削減はやったということを発表した時に、聞いていただいた方の反応が「おぉ〜」という感じだったので、ちょっと嬉しくなりました。

speakerdeck.com

LINEにおける、あけおめLINEの負荷にどう対処したかのお話。事前準備が9月から始まるということで、そんな3ヶ月以上前から準備するんだなということで、現場では驚きの声が上がってました。途中出ていたリクエスト数のグラフでちょびっと増えていたところは何だろう〜と思っていましたが、話を聞いてみると、他の国でのあけおめLINEの影響ということで、グローバルサービスはそういった時間差によるリクエストの伸びもあるんだなと思って、へぇ〜と思って見てました。あと、リクエスト数の予測を出す計算方式もかなり学びになりました。

speakerdeck.com

SREはプラクティスと語られることは多いが、専任ロールを置くことについてのお話。SREを始めようとするにはあるが、チームとしてSREチームを組む、またはSREポジションを作って、SRE専任の人たちでSREを推し進めていくというのは賛成。あと、そういった場合は、最後どうするかというのは考えておかないといけないかもしれない。例えば、組織にSREが十二分に浸透した場合に、SREチームとしては存続するのか否かというのも含めて考えられると、よりベターかも。個人的には、プラクティスである「SRE」という言葉と、SREをやる人としての「SREs」という言葉は分けて使いたいかなと思っている。ただ、この辺は最近はもうふわっとしてるよね。

speakerdeck.com

最近、セキュリティ周りで同じようなことをやったので、首を縦に振りつつ聞いていた。対処としてやっていることは簡単なんだけど、これに気づける仕組みを作っているかどうかが大事ですよね。このお話を聞いて、ちょっともう一度セキュリティ周りについてちゃんとできているか確認したいなと思いました。

懇親会でも様々な人とお話できて楽しかったです。特に自宅k8sクラスタはいいぞ、というお話や、人体へのオブザーバビリティの追求といった話ができたのは非常に面白かったです。

久しぶりに札幌に来たということで、いろんな美味しい食べ物やいろんなところを散策したりして面白かったです。　　 特に記憶に残っているのが、オータムフェストで飲んだ昆布焼酎がかなり衝撃的な味わいで、焼酎の中にうっすら昆布の風味があって、あれは面白いものを飲んだなぁと。

11月の開催はちょっと行けそうにないですが、またその次の開催ぐらいには行けたら行こうかなと思いました。

Nokuchi.sre#0に参加しました

nokuchi-sre.connpass.com

VTRyoさんが新しく地域コミュニティを始めたということで、お邪魔させていただきました。

speakerdeck.com

データストア切り替え時の障害のお話。データ復旧をするっていうのは正しい行動に思えるけども、時と場合によってはやらない方がいいよというお話。 こういうインシデントがあったときに、きちんとチーム内でどうするのが正しいのかという議論に持っていけるという状況は作っておくようにしておかないとねと思った。

speakerdeck.com

ヒーローに頼らない運用の大切さについてのお話。 こういうヒロイックに頼った運用が恒常化してしまうと、それが単一障害点となって、例えばヒーローとなるべき人がいないときにチームとしてどうしようもなくなってしまう。ヒーローに頼らない運用の土壌を作り上げるのがSREの腕の見せどころですよね、というのを改めて思った。

www.docswell.com

やはり健康・・・健康が大事・・・ということを思い知らされるようなLTだった。 ヴィパッサナー瞑想は良いですよね。自分も一時期やっていましたが、余計なことを考えないことで、頭がすっきりする感覚が味わえるのが良かった。

最後にVTRyoさんお手製のスリランカカレーが味わえましたが、普段食べているインドカレーとはまた違った味わいで非常に美味しかった。 VTRyoさんがやってるカレー店にしげにも行かないといけないなぁ。

YAPC::Asia Tokyo 2010 Keynoteを観た

先日、Songmuさん（@songmu）にお会いした時に、「宮川達彦さんのYAPCのキーノートは観といた方が良いよ」と仰られていたので、観ました。

www.youtube.com

www.youtube.com

16年前の映像が残ってるのが本当に有難いですね。

どういうお話か

PerlのPlackのお話で「なぜPlackはさまざまな企業に使われるほど成功したのか？」という成功の要因を解説されています。
このキーノート内では8つの"成功の秘密"が話されていました。

Good artists borrow, Great artists steal.（優れた芸術家は模倣し、偉大な芸術家は盗む。）

まず、初めにピカソの名言から。動画内でも仰られていますが、ピカソが言ったかどうかは怪しいみたいですね。
例としてHTTP::Engineを挙げられており、WSGI/Rackをインスパイアし、そのもととなったCatalyst::Engineのコードベースに引きずられていた、と。これはまさしく"模倣"であり、それは最高なものではなかった。逆にPlackはRackとWebOb.pyを"盗む"ことが良かったのではと仰られています。

Better late than too early

2つ目は「早すぎるより、遅いほうが良い」というお話。

WSGIは2003/12、Rackは2009/8にリリースされたが、Plackは2009/10に0.01がリリース。2012/10に1.0000がリリースされている。
「今更なぜ作るの？」という問いに対しては、鍋パの画像を映しながら「遅く来ると準備とかをすっ飛ばして、さまざまなものが残っている」ということを例えとして、後発だと盗める余地が多くあって、それをベースに開発することができるよね、ということを仰られています。遅く始めることのメリットですね。

JFDI

3つ目は「Just Fucking Do It」。ナイキの「Just Do It」に一単語足されてますね。この中で取り上げてた「やるしかない🔥」ってなんだっけ？と思ってたが、ちょうどサイバーエージェントの内定式の話がありましたね、当時。

まぁそんな感じで「You don't need someone's permission to write code.（コードを書くのに、誰かの許可なんて要らない）」という意識でウダウダ言わずにやれよ、ってお話。PlackではIRCでの2時間の会話の後に、ドラフト書いてたら寝て起きたら、tokuhiromさん（@tokuhirom）がPlackのリポジトリを作って半分くらいは作られていた（早い）。許可なく勝手にやればいいじゃん、の例としてちょっと危ない例えもされてらっしゃって、時代だなぁと。

STFUAWSC

4つ目は「Shut the fuck up and write some code.（ウダウダ言わずにコード書け）」。
まさしくそれを実践した例として、コミット数をグラフ化したものを出されてました。鬼コミット。

TIMTOWTDI / BSCINABTE

5つ目は「There is more than one way to do it.（やり方はひとつではない）」。 TIMTOWTDIは読みにくいんで、Tim Toadyと読む。これを広めたLarry WallのIRC、X、GitHubの名前はこれが由来。（知らなかった

もう一個が、「But sometimes consistency is not a bad thing either.（しかし、一貫性も時には悪いものじゃない）」。やり方はひとつじゃないけど、共通のやり方があってもいいよねというお話。

PSGIの話に当てはめると、統一インターフェースとして共通のやり方を生んだが、それに派生する形でTIMTOWTDIとしてさらにフレームワーク・サーバが生まれる余地が出来たと。

KISS

6つ目は「Keep it simple and stupid.（シンプルかつ、愚直に）」。
これは有名なやつですね。最初、UNIX哲学周りの本で覚えた記憶が。（「UNIXという考え方」だっけか？） PSGIでもこの原則に従っていて、入力としてハッシュリファレンスを受け取り、出力として配列リファレンスを返すという凄くシンプルなものなんですね。「$envのハッシュリファレンスからAPIにしないの？」という質問もあったみたいですが、「シンプルじゃない」と一蹴しています。

※ ここからは個人のメモ

Perlをあんまり知らないので、ここがどういうことか改めて理解をしてみた。
まずは、これがそもそもの形。

で、多分APIの話はこんな感じで入力をオブジェクトにしてくれって話なんですかね。

一理ある、という感じではあるものの、シンプルさを優先するとたしかにハッシュリファレンスの方がいいのか。

glue language

7つ目、「Perlはglue language」。
Webフレームワークは色々あるが、考え方も色々。PSGIはPerlのこの考え方に薫陶を受けて、先ほどのKISSにあるように、極めてシンプルにすることで簡単にサーバ・フレームワークをつなぐことができる方が、HTTP::Engineと違って幸せになれるのではというお話。

Naming

最後は名前について。最初の「There’re only two hard things in Computer Science: cache invalidation and naming things. by Phil Karlton」は知らなかったのですが、「コンピュータサイエンスで難しいことは2つしかない。キャッシュの無効化と、名前を付けることだ」ってな言葉があるんですね。ちょこちょこ笑いが起こってたので、ジョーク格言とも言うべきか。

PlackはCPANのよくある名付けとは違っているというお話で、::が多すぎる！というスタートで、これ大昔にPerl触った時に同じこと思った記憶が。ここでRubyから"盗む"ことで、本来なら「Net::Server::HTTP::Prefork::PSGI」と名付けるところを「Starman」にしたり、面倒なところを省いたって感じですね。ただ、名付けは大変だが、使うのは簡単ですよねと。あと愛着が湧くし。

最後に

RubyやPythonから良いものがあるなら盗もう、そしてシンプルにして、glueでつなげていきましょうという締めではあるのですが、最後の最後に9つ目として「People」を挙げられておりました。なんかこうコミュニティって良いですねというお気持ちと、けいおんがチラチラ映っていて、16年前に放送してたのかそういえば・・・と時の流れを感じました。

最後のこれ、グッときました。

「酒とキャリアとエンジニア」というYouTubeチャンネルを始めました

「お前は一体何屋なんだ？」ってなくらい興味の赴くままに色々やってますが、今回は 公明正大に飲酒したいため エンジニアのキャリアに迫るYouTubeをやり始めました。

youtu.be

なんで始めたのかというと、インタビュー記事などで冒頭に出ているエンジニアさんのキャリアがサラッと紹介されてることがありますが、「この人、こんなことやってたんだ〜」と新たな発見をすることが多いなと思って、エンジニアさん達のキャリアに迫れたら面白そうって感じで始めました。あと、旨い酒も大手を振って飲みたいですしね！

で、動画のスタイルについては、オモコロの原宿さんがやってる「今じゃない企画室」をリスペクトして真似してますが「ボラギノール編集」と言われて確かにとなりました。今後もボラギノールしていきたいと思います。

ありがたいことに、様々な大物な方たちに出ていただけそうな雰囲気でして、肝臓の数値が許す限りは今後もコンスタントに動画を出していきたいと思います。

正直、万人に受ける感じでもなく、TECH WORLDさんや、adachin devさんみたいにチャンネルとして伸ばせる未来はあんまり見えてないですが、ゆるゆるとライフワークとして続けていきます。AI時代が来て、キャリアで迷うことも増えましたしね。

もし、出たい！という方いらっしゃいましたら、是非 @syossan27 までご連絡ください🙏

しょっさん@ʕ ◔ϖ◔ʔ (@syossan27) / X

転職ドラフトさんのイベントに登壇しました

tenshoku-draft.connpass.com

有難いことに、転職ドラフトさんにお声がけいただき、登壇いたしました。
Platform Engineering Kaigi 2025, クラウドネイティブ会議でお話させていただきましたPlatform Engineeringのお話をベースにということで、以前のイケてないところをリファインしつつ、お話させていただきました。

speakerdeck.com

書き直して、改めて思ったのは「手法に囚われない」これに尽きるなと。「なんで〇〇をやるんですか？」「それを達成したいなら別の方法もあるんじゃないですか？」と掘っていけば、実は解決策は単純なものだったりすることがあります。そういった本質的に何を求めているの？をちゃんと見定めるようにしましょうね、ということを伝えたかったことになります。その最たる例が、取り上げさせて頂いたWikiの件ですね。

ということで、いつまでも前のチームでやっていたことの内容で登壇せずに、新しくやっていることで登壇しなきゃなと思ったりしております。本業、頑張ろう。