YAPC::Kyoto 2023 参加と自分のこと #yapcjapan

YAPC::Kyoto 2023 に参加してきた。

セッションの軽い感想とYAPCのエモい話に影響されて長々とした自分語りを書いてみた。

参加したセッションについて

小さく始め、長く続けるOSS開発と貢献

SongmuさんのOSSの話はもう何回も聴いているけれどやっぱり毎回新しい発見はあったので出て良かった。OSSのコードの癖の話も面白かった。

ジョブキューシステムFireworqのアーキテクチャ設計と運用時のベストプラクティス

チームではFireworqを使っているけれど、アーキテクチャ設計や開発の理由を詳しく知っているわけではなかったので理解の助けになった。

日常業務のカイゼンで図る開発チームへの貢献

自分もECS移行の際にフローの改善を混ぜ込んでいてそこでいくつか工夫をしていたので共感できる部分が多かった。

ORM - Object-relational mapping

ORMのパターンについても知らなかったし、Teng導入でのgreppability確保に関してはORMに関係なくちゃんとしたいところだなと再確認できた話だった。

あの日ハッカーに憧れた自分が、「ハッカーの呪縛」から解き放たれるまで

どうしたかを言語化するのが素晴らしくて納得のベストスピーカーだった。こういったキャリアに悩んでいる人はたくさんいそうなので後で動画でまた見たい。

ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す

身に覚えがある。最近は廃墟を直すみたいなことがあまりできていなくてそのまま住みがち。質疑応答にあった説得材料としてFour Keysの値が悪いことを示すのはかなり良さそう。

デプロイ今昔物語 〜CGIからサーバーレスまで〜

昔のHTTPサーバやデプロイについて、せいぜいmod_perlまでしか知らなかったのでCGIの話などが特に面白かった。

prototype大全

たまにPerlを書くときにpushやmapを始め変な構文だなと思っていたものが同じprototypeによって提供されていると知ってだいぶ身近なものになった。

あなたの知らない(かもしれない)コアモジュール 2023

Benchmarkとか手作りしてしまいそうだけど使えそう。こういうのに限らず解決したい課題を解決するモジュールはもう既にあることが結構あるのでちゃんと探せるようにしたい。

様々な環境へコマンドラインツールを提供する上での苦労とその対策

形態は違えど古い環境や様々な環境をサポートするというのは体験したことがあるので共感できる話が多かった。

my new error...

開発を止めてこういったタスクを一気に進めるというのはチームで一度やってみたいなと思う。アラートをオンボーディングとして考えるのも良さそう。

ライトニングトーク

Java移行の話や文字コードの話が面白かった。

キーノート

とても良かった。最近のonishiさんは社外の特に学生向けに話すことが多い印象で、社内でもこういった昔の話を聞くのは初めてかもしれない。当時の様子とか社内に残ってると思うので時間があったときに色々見てみたい。

自分のことについて

キーノートであるonishiさんの発表でのモブについての話と懇親会での出来事で自分の成長について振り返るきっかけになったのでここからは自分語りのコーナー。

前回のYAPC::Tokyo 2019は自分が社会人になってすぐのタイミングだったけれどそこから4年も経つと色々変わったと感じている。

振り返ると4年で様々な仕事を経験し、それをブログに書いたり発表したりOSS貢献したりもした。社内での評価も気づけば上から数えたほうが早いくらいにまでになった。

それでも周りの有名な人を見ながら過ごしてきているのもあり、それに比べると自分は有名な人に比べて技術力は高いわけではない、かと言ってアウトプットも多いわけではないので所謂モブという認識のままだった。

ところが今回はスタッフでも発表者でもなかったのに懇親会でOBだけでない他の参加者の人から話しかけてもらえるというのがあった。

自分が存在を認知していなかった発表者の方が自分のブログ記事を認知していたり、自分が書いたOSSやPRについて「今でも便利に使っていますよ！」を始めとして会話すると言うことが何回もあって嬉しくなり、こんなモブでも多少なりとも界隈に影響を与えているんだということを実感した。

この界隈の温かい空気にもっと貢献したいと思えたし、発表を聞いて共感する事が多いということは自分が発表して共感してもらえるだろうという気持ちになったので、次のYAPC::Hiroshima?は発表者として参加したい。 とはいえこんなこと言ってRejectされたらカッコ悪いのでそのためにも今から頑張りたいなと思った。

GitHub ActionsでJobやStepをデフォルトブランチだけ動かすようにする (2023年版)

この記事は はてなエンジニア Advent Calendar 2022 の43日目の記事です。

GitHub ActionsでJobやStep単位でデフォルトブランチの時だけ実行したい処理を書く時にはいつもこのように書いていました。

if: github.ref == 'refs/heads/main'

これは2023年現在ではこのようにブランチ名を書かない形で書き換えることができます。

if: github.ref_name == github.event.repository.default_branch

ref_name はrefsの含まれていないブランチ名やタグ名単体が入っており、 github.event.repository.default_branch も同様にブランチ名だけが入っているのでそのまま比較できます。

The short ref name of the branch or tag that triggered the workflow run. This value matches the branch or tag name shown on GitHub. For example, feature-branch-1. https://docs.github.com/en/actions/learn-github-actions/contexts#github-context

ref_name はGitHub Actionsのリリース初期にはないプロパティで、おそらく2021年11月のこのPRで追加されています。

github.com

複数のリポジトリを扱っている場合でデフォルトブランチ名がバラバラだったとしても単純にコピペできるし、後からデフォルトのブランチ名を変えたくなった時にも書き換えする必要がなくなるので便利です。

ちなみに on で指定する部分には github.event.repository.default_branch のような変数は使えないのでブランチを列挙する必要があるので注意です。*1

on:
  push:
    branches:
      - main
      - master

*1:https://stackoverflow.com/questions/64781462/github-actions-default-branch-variable

クリアした美少女ゲーム2022

2022年はプレイする時間も取れるようになって、とある人*1の影響でモチベも上がったので久しぶりにプレイしていくつかクリアすることができた。

今回感想を書かなかったら一生書かなさそうなのでネタバレなし自分用のメモもかねて書いておく。

つくとり

ど田舎を舞台にした伝奇ミステリー作品で、Trueエンドは蛇足ではあるけどそれを差し引いてもいい作品ではあった。

ネタバレになるから書きづらいけど当時よりも話題にしづらい題材を扱っていて2022年現在プレイするとまた違う印象を受けると思う。

3ルートあるけど1→2→3→真1→真2→真3→Trueという順番で固定されているので今誰がどういう状態かめちゃくちゃ分かりにくいので一気に進めるの推奨。

ブランドは解散しているしDL版も存在してないので入手は難しいかもしれない。(自分も中古で手に入れたのが10年くらい前なので今の入手難度は不明)

ゴア・スクリーミング・ショウ

サイコホラーに分類されるであろう作品で、悪役であるユカをどれだけ好きになれるかで評価が変わりそうな作品。

個人的にはユカはそんなに好きになれなかったけど、闇子ルートのユカは良かった。

推奨ルートはあかね→葵→希衣佳→闇子→ユカ。

各キャラのBADエンドは後回し推奨。BADのルートに過激な表現があるので苦手な人は選ばないかシステム設定から文章・CGの表現を変更するのおすすめ。

2006年のゲームで学校が舞台なのもあり時代をよく反映していて、ポータブルMDプレイヤーや911の話題など時代を感じる発言も結構あった。

幼なじみは大統領 My girlfriend is the PRESIDENT.

パロディ多めのギャグゲー。

ギャグもあんまり質が良くなくて量がいっぱいあるので一気にやるのは推奨しない。(例えるなら安い食べ放題の焼肉屋)

推奨ルートは雪乃→イリーナ→蘭→エルだけど蘭ルートだけ明らかにシナリオのクオリティが低いのは注意。

きまぐれテンプテーション

ホラー&ミステリー&いちゃらぶ作品。

短いけどよくまとまってる作品で、ぬるぬる動いたりシステム周りもちゃんとしているのでおすすめしやすい作品。

この作品に限らず同じブランド・同じライターのなないろリンカネーションやあけいろ怪奇譚でもあったけどキャラクターの魅力をシナリオに組み込むのがうまいと思う。

選択肢自体は難しくなくて正解の選択肢もわかりやすいので最初は攻略サイトなしでTrueエンドを目指すといいと思う。

その他のエンディング回収は面倒公式が用意してくれた｢行動選択スキップ機能｣追加パッチを使うといいと思う。(使わずに回収したらかなり面倒だった)

ふゆから、くるる。

SFとミステリーと百合の入門みたいな作品。

世界観は難解だけど伝えたいテーマや展開はお約束も守っていたりと意図的にわかりやすく作られている雰囲気を感じるが人には勧めづらいので難しい感じ。

多分同じライターの四季シリーズと呼ばれる他作品をやるともう少し何かわかるかもしれない。

シナリオ以外だとCGの質と量は圧倒で綺麗なCGがどんどん出てくる体験も良かった。

OPムービーもかっこいいので必見。

www.youtube.com

ユメミルクスリ

いじめや薬物をテーマにした学園もので、詳細はこの記事で紹介しているので割愛。

cohalz.co

なないろリンカネーション

家に住んでいる鬼と共に幽霊に関する事件を解決していく話。

メインヒロインの琴莉のことをどれだけ好きになれるかで作品の評価が変わってくるくらい全ルートに琴莉が関わっている作品。

とはいえ、全ルートに関わらせるほどの魅力があるキャラクターなのは間違いなくて、たまたま見つけたこのツイートがいい紹介になっているので載せておく。

推奨ルートは琴莉1→伊予→梓→由美→琴莉2。

あけいろ怪奇譚

幽霊に関する学園の七不思議を解決していく作品。

なないろリンカネーションの続編の要素もあるので前作を先にプレイすることを推奨。

最大瞬間風速はなないろリンカネーションに負けるけど、各ルートで納得感のある多種多様なエンディングがあってどのルートも楽しめた。

ほんの少しだけユメミルクスリを意識している要素も感じたけどこれは気のせいかもしれない。

推奨ルートは美里→るり・るか→葉子→佳奈→ベルベット→True。

おわり

来年はこの棚に飾っている作品の1/3くらいは終わらせたい。

*1:https://twitter.com/hirasakamei

京都から福岡に引っ越した

もう2ヶ月以上前の話になるけれど10/21に京都から福岡に引っ越した。

引っ越した理由

2022年5月に会社の働き方制度が変更され、日本全国のほとんどで働けるようになった。

これきっかけで自分の住む場所について考え直し引っ越すことに決めた。

hatena.co.jp

引っ越した理由は一言で言えば「京都にこのまま住み続けるより面白いことをしたい」が一番の理由。

趣味で出かけることも多いけど、京都にはもう4年以上住んでいて近くの主要な場所は行ったというのもあり、新しい場所に行ってみたいという気持ちが強くなってきた。

それと事前にチーム異動することが決まっていたので、働き方とかを始めとした生活習慣をこの機会に新しくするためにというのもあった。

異動前のチームでは比較的激しく働いていて、その働き方を新しいチームでもそのまましてしまうともうしばらくは抜け出せなくなる予感がしたので周りの人が変わるタイミングで環境も変えることにした。

京都の部屋は2018年から住んでいて自宅で働くことを想定してないし当時から大きく給料も上がったので、学生の延長みたいな部屋からグレードアップするというのも目的としてあった。

という感じで諸々を新しくして自分が面白いと思うのもそうだしそれをまた会話のネタとして話題を提供できれば良いなと思って思い切って今と全然違う環境に引っ越すことにした。

場所に関して特に福岡に縁があるわけでもなくて、今まで住んだことのあるところが名古屋、埼玉、京都で次を考えたときに福岡あたりが面白いだろうと思ってただそれだけで決めた感じ。

なのでまた何年かしたら全然違うところに引っ越す可能性も十分にある。

部屋に関して

ざっくり部屋はだいぶグレードアップしたけど市街地への距離はあんま変わらない感じの変化になっている。

Before

  • 家賃5.6万円、共益費3000円 合計5.9万円
  • 築34年 1K 専有面積 24.7㎡
  • 京都地下鉄東西線 二条城前駅 徒歩5分
    • 三条京阪駅から3駅220円
  • インターネット別5000円ぐらい
  • 会社まで片道徒歩15分
  • この部屋

After

  • 家賃10.1万円、共益費3800円＝10.48万円
  • 新築（2022年10月）1LDK 専有面積 40.9㎡
  • 西鉄天神大牟田線 高宮駅 徒歩4分
    • 西鉄天神駅まで3駅160円
  • インターネット込み
  • ZEH-M
  • 建物

2ヶ月住んでの感想

他の地域との違い

よく言われるIT先進みたいなのは一日乗車券がスマホでそのまま買えて使えたり、粗大ゴミの支払いがLINEからできるみたいなところで感じるのがちょくちょくある。

とはいえ自分が住んでいるところは市街地とは離れていて個人でやっているお店も多いので現金のみの店もまだ多い。

スーパーの品揃えも結構印象違っていて、メーカーも九州のものも多く、海鮮コーナーやお酒のコーナーが広め。

物価に関しては京都がそもそも高いから比較はフェアじゃないけど安く感じる。ここ最近の高騰で差は縮まった印象だけど、福岡で高いものは明らかに質が良いと感じるので安いのは間違い無いと思う。

ゴミ捨てに関しては日没から夜24時までに出せば良いので時間をほとんど気にしなくて良くなり非常に楽。

逆に24時間ゴミ出し可みたいな物件の価値はかなり下がるので検索条件から外すのがおすすめだと思う。

あとはよく言われるのは人が温かいというのは確かにあって、引っ越しして2日後にはこのツイートの内容に遭遇している。

これ以外にも海鮮丼を買いに行ったらおまけであら汁用の魚を丸々おまけでくれたりとかびっくりすることがあって楽しい。

部屋や周りの環境について

家賃が倍近くになって、福岡関係なく体験もかなり良くなったのでその紹介もする。

今の部屋はZEHという簡単にいえば太陽光発電+高断熱で電気代などがかなり抑えられる物件になった。

電気代が抑えられるのはもちろんだけど、それよりすごいのは断熱で、エアコンを入れ始めたのも12月になってから。

何日か前に雪が降ったけど、その日も夜にエアコンを10分くらい入れたらあとは朝まで布団一枚で寒くないくらいで快適に過ごせている。

その分家賃は相場より高いけど、防音に関しても性能が良いのに加えて家賃の高さによるものか普段は生活音が全く聞こえないのも嬉しいポイント。

あとはウォークインクローゼットも最高で、いろんな縁で持っている服をどんどん収納できたり、引っ越しで持ってきた段ボールを全てそこにしまって寝室含め広々としたスペースを確保できたりと思ってた以上に役に立っている。

周りの環境に関しても徒歩数分のところに普通のスーパーと高級スーパーがあり、10分も歩けば24時間営業のスーパーもあるのでもはやスーパーに行くのが趣味になっている。

特に高級スーパーに関してはそこそこ広いので品揃えも十分で2~3日に1回くらいのペースで行って酒とつまみを買うみたいな生活をしているので居酒屋を全然開拓できてない。

もし今後また引っ越すことがあってもZEHとウォークインクローゼットありで高級スーパーの近くという条件は外せないと思うくらいには今の部屋を気に入ってる。

不満点

目立って不満なところというと可燃ごみ以外のゴミ捨てが月一ということで、ちゃんと日にちを覚えていないと全然出せないのが困る。

ウォーターサーバーを契約したのでペットボトルのゴミに関してはほとんど出ないようになっているのでなんとかなってるけど缶や瓶は難しい。

あとは朝など市街地に出る道路は混雑していて、バスに関してはそこそこ遅延している感じなので時間を気にしているときは余裕を持った方がいい印象。

とはいえバス自体の混雑は京都の方が酷いのでどこもそんな感じかもしれない。

部屋探しについて

日本全国どこでも働けるようになったということで部屋探しはめちゃくちゃ難しかった。

通勤もしないので駅からの距離はもはやどうでも良く、何回か行ったことはあるにしても土地勘はないので結局全域から調べることになって選択肢が多い。

最初は無駄に専有面積の広い順で検索していたけれどあんまりピンと来ず、絞り込みをしたところで変わらず結果は大量に出るので難航していた。

そこから作戦を変えて広さはそこそこに高級志向で行こうと思ってシャーメゾンにたどり着き、断熱も大事だと思って最終的にシャーメゾンのサイトで検索条件に入れたのは「福岡市全域」「1LDK」「ZEH」だけであとはそこからの選択肢で決めた。

京都から福岡の引越しということで内覧から契約までできる限りオンラインで済ませたかったけどそこもなんとかなった。

今回の部屋を取り扱っている不動産屋がLINEでのやりとりに対応していて、重要事項説明も含めて全てオンラインで済ませることができた。

不動産屋に行ったのは引っ越し当日鍵の受け取りだけだった。

ちなみに今回の引っ越しで掛かった費用は契約の57万+引っ越し業者の12万で約70万近い出費で多分人生で一番でかい出費になった。

今回利用した不動産屋はこちら。

www.t-living.net

仕事の変化は特になし

同じ自宅からのリモートワークからとはいえオフィスからの近さが段違いになったので何かしら変化があるだろうかと思ったけど、ありがたいことに本当に何も変わらず仕事ができている。

現行のフレキシブルワークスタイル制度から約半年、それ以前から考えると約二年間オフィスを前提にしない働き方を全社で行っていたこともあってこの辺はさすがだと思った。

最後に

今までいろんな人の部屋に遊びに行ったことはあったけど、呼んだことはほとんどないなと思ったのでそのお返しといってはなんだけど是非遊びにきてください。

「ユメミルクスリ」をプレイした

2005/12/22発売のユメミルクスリを最後までプレイした。

この作品を今プレイした理由は2022/10/05に公開された以下の動画で作品のOPを聴いたから。

www.youtube.com

個人的にここ一年近く配信を見ていた人の久しぶりの歌ってみた動画で、自分はこの作品の世代でもないし知名度を正確には知らないので、なぜこの曲を選んだのか全く理由がわからず逆に興味が出てきたと言う感じ。

ユメミルクスリ自体も十年以上前から存在は知っていた作品だし、5月にも同じブランドの「つくとり」をプレイしていたのでこの機会にやってみるかと思って始めた。

感想はあまり言うとネタバレになるので細かいところは言えないけれど、作品内のとあるキャラクターと歌った人の活動におけるスタイルが強く重なる部分が感じられる部分があり、そこを意識して欲しくて選んだのではないかと思えるような印象的な作品だった。(もちろん合っているかは本人にしかわからないけれど)

少なくとも自分には二人の初見のインパクトと長く見てきた中での印象のどちらもがかなり近くてルーツとすら思えるほどだった。

また別のあるルートではそう言ったことと関係なく自分の過去の体験を思い出すようなシーンもあり先が気になって一気にプレイしてしまった。

こういった複数の理由もあって個人的にかなり刺さった作品になった。

パッケージに似合わずすごく現実的な作品で描写など人を選ぶ部分はあるけれど、あえて言うなら学生時代に死にたいと思ったことがあるような人には特に刺さるそんな作品だと思う。

余談

仕事でAsanaを使っているのでスクショを同僚に見せたところウケが良かった。

Fluent Bit のメトリックを Mackerel に送る

Fluent Bit では以下のようにHTTP_Serverを有効にすることで内部のメトリックをHTTP経由で /api/v1/metrics というパスからJSON形式で取得できるようになります。*1

[SERVICE]
  HTTP_Server       On
  HTTP_Listen       127.0.0.1
  HTTP_PORT         2020

これで各プラグインで今までに処理したレコード数やバイト数が取得できるわけですが、実はこのJSONはmackerel-plugin-jsonでそのまま扱える形式になっています。

下はoutputのcloudwatch_logsプラグインに対してのメトリックを送信する例です。

$ mackerel-plugin-json -prefix='fluent-bit' -url='http://127.0.0.1:2020/api/v1/metrics' -diff='.?' -include='output.cloudwatch_logs'
fluent-bit.output.cloudwatch_logs.1.retries 0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.retries_failed  0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.dropped_records 0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.retried_records 0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.proc_records    0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.proc_bytes  0.000000    1653008277
fluent-bit.output.cloudwatch_logs.1.errors  0.000000    1653008277

このようにdiffオプションを使ってFluent Bitで1分間に処理したログに関するメトリックをMackerelで確認することができるようになります。

ユースケースとしては、Fluent Bit経由でCloudWatch Logsにエラーログを送っているけどエラーの増加はMackerelで通知したいという時にわざわざCloudWatchから集計しなくても良くなるというのがあります。

ちなみにmackerel-container-agentのpluginsイメージにはmackerel-plugin-jsonが最初から同梱されているので、HTTP_Serverを有効にすればあとはすぐに取得できるようになります。

参考

htnosm.hatenablog.com

cohalz.co

*1:https://docs.fluentbit.io/manual/administration/monitoring#metrics-examples