digが入っていない環境で名前解決のテストをするのにperlが便利

これで名前解決できる

$ perl -E 'say join(".", unpack("W4", gethostbyname("example.com")))'

用途

• EC2インスタンスやらコンテナから外にほんまに出られるんかな？みたいに調べたいことがある
  • VPC内でprivate subnetだとNAT Gatewayとかがないと外に通信できない
• サービスメッシュとかで名前引けるかどうかを確認したい時がある
  • 特定の環境でしか引けない名前とかある
• 今回の用途はGuardDuty ECS Runtime Monitoringを導入した際にちゃんと不審な動きが検知されるかどうかで使いたかった
  • モネロのマイニングプールを引くと検知されるらしい GuardDutyのEC2タイプFindingsを簡単に検知させる方法 – CryptoCurrency編 | DevelopersIO
• digやらnslookupをaptやyumで入れるのは気が引ける or できない
  • 本番環境のコンテナイメージなのでroot取れないとか
• perlは入っていることがそこそこある
  • debian:bookworm-slimなど
• アドレス一つしか返ってこないとかそういうデメリットはありますが、使い所はありそう

perlをシェルスクリプトの代わりに使うのはどうかという話を3/15か3/16にします

github.com

hachiojipm.connpass.com

2023年の振り返りと2024年の抱負

2023年もいろんなことがありましたね。2024年を迎えて皆様はいかがお過ごしでしょうか。というわけで去年の振り返りと今年の抱負について書いていきたいと思います。

前回

mackee.hatenablog.com

登壇やイベントなど

YAPC::Kyoto 2023

YAPC::Japanが久しぶりにオフラインで開催されて、京都に行ったり、それから登壇もしました。

mackee.hatenablog.com

そんでもって、このトークの内容はlogmiさんで書き起こししていただいているのがあります。

logmi.jp

書き起こしされると、動画やスライドと違い、検索で辿り着きやすくなるので良いですね。また、このトークは個人的には今まで自分がやった中で一番よかったなあというのがあります。今回はライブで解説しながらデプロイしていくというのをやったのですが、こういうライブ感のあるトークはオフラインじゃないと難しいじゃないかな〜と思うし、オフラインだからこういうのをやりたいなあと思います。

と、というわけで、2月にも広島でライブコーディング主体のトークやります。YAPC::Hiroshima 2024です。

yapcjapan.org

今回は、WebAuthnを認証として使うPerlアプリケーションをできるだけ専用のモジュールを使わずに書きます。パスワードレス認証の一つとしての、WebAuthnの仕組みなどもわかるトークにするのでチケット買って見に来てくれ！！！

fortee.jp

チケットはこちら

passmarket.yahoo.co.jp

湘南.pm #1

湘南在住(諸説あり)なので、湘南.pmに参加して喋ってきました。

speakerdeck.com

ずっとsqllaというORMを作っているのですが、ORMの課題であるJOINを含んだ複雑なクエリをビューを使って解決できないかという提案です。sqlla側にいろいろ実装はしております。

湘南.pmは今年も色々イベントをやるそうなので、どんどん参加していきたいですね。

Asakusa.go #1

浅草だいぶ遠いですけれど、Asakusa.goに参加して、LTもしてきました。

speakerdeck.com

趣味ではCloudflare Workersを使っていますが、こちらでもGoを使いたいので、syumai/workersというライブラリを使っています。CF WorkersにデプロイするにはGoのプログラムをWASMにビルドしないといけないのですが、オフィシャルGoコンパイラのWASMはでかいので、TinyGoという別のコンパイラを使っています。ただ、色々動かないのでその時の工夫などについて書いています。

CF WorkersとかWASM関係は今年も攻めていきたいですね〜。

仕事

相変わらずTonamelですが、テックリードは交代して、現在はアーキテクトと名乗っています。

Tonamel関連で書いた記事はこちら。

techblog.kayac.com

他も相変わらずトーナメント表のチューニングとかやっています。

趣味

ISUCON

負けた。来年は勝つ。

mackee.hatenablog.com

3Dプリンタ

色々やってた。デルタ型のエフェクターを自分で設計したやつに入れ替えたりしていた。あとフィラメントをPETG-CFにしてみたり。キーボードのケースなど実用品を作るようになってきた気がします。

旅行 前半

キャンプ。ラウンドグリドルパンで芽キャベツのアヒージョ。2月だったので伊豆の南の方のキャンプ場でした。

箱根の彫刻の森美術館。2022年に直島の地中美術館に行ってから彫刻とかハマってる気がする。

ピカソ館。漫画みたいにでかいPICASO

ステンドグラスの塔。「幸せをよぶシンフォニー彫刻」。映えるな〜。

山中湖近くの忍野八海。富士山が見えると間違いない感じある。

YAPC::Kyoto 2023の前日に京都鉄道博物館行ってました。SLアベンジャーズ感。

またキャンプ行ってた。今度は森の中です。確か設営中雨降ってたな。

西九州新幹線乗りにいってた。軍艦島に上陸するツアーにも行ってたんですが、海が荒れて上陸できず。再チャレンジしたい。

旅行 アメリカ横断編

5月に3週間ほどアメリカに行ってました。目的は車で西海岸から東海岸まで横断することと、インディ500を見ることでした。

ロサンゼルスから出発しましたが、ロサンゼルスにはSpaceXの工場があり、ファルコン9の1段目がありました。

モハヴェ砂漠あたりですが、めちゃくちゃまっすぐだし、スケール感じる。

ラスベガス。派手なアメリカが詰まっている感。

グランドキャニオン。マジで観光している。

アリゾナのメテオクレーター。こんなん残ってるのって感じ。

テキサスのバーベーキュー屋さん。今にも吹き飛びそうな小屋の外観で大丈夫か？と思ったが、めちゃくちゃうまい。他の二人が食ってた塊肉食えばよかったなと思うものの、このコンビーフとかもうまかった

ナッシュビル。ロックの街。ここよかった。

旅の目的のインディ500。熱気がすごい。ドラマチックな展開。優勝した人のファンが、目の前にいて、勝った時に気絶しかけていた。だいぶすごい光景だった。

シカゴはめちゃくちゃ大都会。摩天楼。

ワシントンDCのスミソニアン博物館。いや〜、とにかくよかった。そういえばインディアナポリス近郊の空軍博物館にも行ってます。SR-71見れたのよかった。

そしてたどり着く、目的地のニューヨーク。本場のブルーノートよかったっすねえ。この前に食ったステーキも美味かったし、その前に食ったニューヨークスタイルのピザも美味かったし、とにかくこの旅では美味いものをいっぱい食った感じ。

でした！

旅行 後半

サンライズ出雲で出雲市駅まで行って、出雲大社行って帰るっていう予定だったんですけれど、大雨で松江で打ち切りを喰らって、スーパーまつかぜで鳥取、スーパーはくとで姫路まで行き、そこから新幹線で帰りました。帰りはやくもの予定だったのですが、次乗る時には車両新しくなってそう。

鉄道と言えば、秩父鉄道のパレオエクスプレスにも乗ってました。何気にSL初乗車だった。

富士山近くで夏キャンプ。木に囲まれていて、涼しかったのが幸い。

白馬八方池。車で行ったが遠い。旅館のご飯美味かったのでまた行きたい。今度は電車で。

尾瀬も行きました。尾瀬沼の方を一周した。いやー〜いい体験。

秦野の大山登ってたが、雨で何も見えなかった。帰りに食べたラーメンが美味かった。

ふもとっぱらでキャンプ。毎年行ってる気がする。

奥鬼怒温泉に途中から紅葉狩り目的で徒歩で行った。目的地の宿は自家用車では行けず宿のバスを使う必要がある。前回行った際は宿のバスを使ったが、今回はその部分を歩いた。だいぶよかったですね〜。

カーフェリーで横須賀から北九州まで。山口の実家に自分の車を見せに行くという旅行だったが、フェリーはだいぶ快適でした。

コンテンツ系

• AC6出て俺たちのやつが来た！ってなったが、途中で止まってしまっている
• 映画は色々みた気がする。なんだかんだ「君たちはどう生きるか」が一番残っている感じする
• 怪奇!YesどんぐりRPGにハマってしまっている気がする

2024年の抱負

• 仕事は求められていることはやりつつ、自分で仕事を作るみたいなのに挑戦したい
• YAPCベストを尽くす
• WebAssemblyとかCloudflare Workers関連の興味があるもの何か外に出したいな

ISUCON13に出場していました #isucon

こんにちは。「失敗から学ぶISUCONの正しい歩き方 - 葬送のPostgreSQL」チームとして、id:soudaiと@tetsuzawaと共に出ていました。言語はGoです。

とはいえ芳しくない結果に終わりました。その辺は id:soudai のブログにあります。

soudai.hatenablog.com

我々のアプローチ

過去にfujiwara組として優勝した時などは特に素振りなどはしていなかったわけですが、これはチームの3人とも普段から一緒に仕事しているから、お互いの動き方というのがわかっているというのがありました。ただ、今回組んだメンバーたちとは一緒に仕事をしていないので、月並みな言い方をすると仲良くなるところからのスタートでした。

というわけで、この1年間は大体毎月素振りをしていました。

結果的に我々の戦略というのは以下の3つに絞られます。

1. どういう問題であってもPostgreSQLに移行する
2. 事前準備で計測ツールやデプロイ方法を明確にする
3. あとはその場で解く

1のPostgreSQL移行する、というのは id:soudai さんが得意だから、このチームの最大風速を目指すのであれば選びたい戦略という理由だと僕は考えています。

3回目とか4回目ぐらいまでの昔のISUCONというのは、俺の考えたロマン構成や、ISUCON決戦兵器をぶっ放す人も多かったように思えます。ユーザーランドで処理を行わずにカーネル上でアプリケーションを書いてどうにかするチームや、nginx module上のPerlを使う人など、尖ったアーキテクチャを採用するチームもありました。あとテストカバレッジを100%にするのを目指すチームもいましたね。

今回の我々のチームの戦略であるPostgreSQLに移行する、というのはロマンの塊ではあります。しかし、過去のロマン戦略を取ったチームと同じく、勝つことを目的としています。過去の素振りではPostgreSQLに移行した結果、同時にインデックスチューニングが既になされて高速化するということもありましたし、JSON型や配列型などPostgreSQLならではの手法も使えます。

自分たちの土俵に上げるために、この1年間はひたすらPostgreSQLに移行する訓練をしてきたと言えます。その結果、今回のISUCON13では開始から2時間後の12時台にはもうPostgreSQLに移行が完了していました。

2の事前準備に関しては@tetsuzawaが初期セットアップの自動化や手順書を色々書いてくれたのと、僕の方でVPS上にGrafanaとPrometheus、Tempo、Pyroscopeを用意して、アプリケーションから飛ばすようにしていました。tetsuzawaが用意してくれていたalpの結果を表示する君と合わせて、だいぶ解像度高くアプリケーションの実態を測ることができるようになっていました。また、この辺まで含めて12時台に入っているので、最初はまあまあ合格点かなと思っています。

なぜスコアが出なかったのか

なぜスコアが出なかったかといえば、3の当日やる部分が全くうまくいかなかったという点があります。僕がやった部分と言えば、

• PowerDNSをMySQL backendからLMDB backendに切り替える => 名前解決数は増えたもののCPUはそこまで下がらず
• user statisticsをフルRedis化 => 失敗
• user statisticsをsingleflightによるオンメモリキャッシュ化 => スコア上がらず

結果的に言えば、これらは手をつける順番も間違っていたし、手法もやりきれてないということで、全然ダメダメだったなあという感じです。PowerDNSに関してはiptablesによるdropをやるべきでしたが、手法を知っていたのにも関わらずキャッシュに手をつけてしまって結果的に中途半端になってしまいました。フルRedis化も本来得意なところだったはずなのにバグらせて結局時間を溶かしただけなので、実力不足と言えます。また、その手前に他にやることがいろいろあったと思うので、この辺りは素振りで確認していきたいと思います。

振り返り

良かったところ

• 過去の参戦ではできなかった計測について取り組むことができた
• OpenTelemetry TraceやPyroscopeなど現代的な武器を活用できた
• 全く知らないPowerDNSの設定変更について立ち向かってその場で対処できた

悪かったところ

• 肝心の実装で精度を出せなかった
• ベンチマーカーが行うシナリオの観測ができていなかった
• シナリオの観測ができなかった結果、手をつける順番を間違えた

次へのトライ

• 実装に集中してみる
  • いい結果が出ている時は実装に専念しているので、観測はそこそこに実装をやるのが一番バリューが出る
• シナリオをちゃんと追いかける
  • OpenTelemetry Traceで追いかけることができないかやってみる
    • アプリケーションのコミットごとにトレースを分けることができていたのでもうちょっとこの辺サマれるようにして実用的にしたい
• 仲間を信じる

おまけ: PostgreSQL移行 アプリ視点

ISUCONの参考実装はたいていMySQLなので、MySQLからPostgreSQLに移行することを考える。Goの場合、MySQLではgo-sql-driver/mysqlが使われるが、PostgreSQLのドライバーはいくつか選択肢がある。弊チームではjackc/pgx/stdlibを採用する。

MySQLとPostgreSQLとではSQLにおいて主に以下の違いがある(これはライブラリの違いも含まれる)

• プレースホルダ
  • MySQLでは ?
  • PostgreSQLでは $1 $2 $3 ...
• カラム名を囲むクオート文字
  • MySQLではバッククオート
  • PostgreSQLではダブルクオート "
• AUTO INCREMENTのテーブルに対して挿入した行のIDを取得する方法
  • MySQLでは LastInsertID
  • PostgreSQLではINSERTの末尾に RETURNING id を付ける
• Upsertのやり方の違い
  • MySQLでは INSERT ~ ON DUPLICATE KEY UPDATE ...
  • PostgreSQLでは INSERT ~ ON CONFLICT DO UPDATE ...

他にも型の厳密さが違ったり、標準でのトランザクション分離レベルが違ったり、いろいろあるが、頻出パターンは以上である。

前2項目についてはクエリを実行時に動的に書き換える以下のライブラリを制作し、実戦投入していた。

github.com

後者の2つに関しては、手で書き換えるようにしていた。今回のISUCON13ではLastInsertIDが5箇所ぐらいあったように思える。

github.com

また、行の衝突のエラーハンドリングも頻出パターンではある。MySQLのエラー番号とPostgreSQLのエラー番号は当然違うので対処が必要。これはあらかじめスニペットを用意していた。今回は出番はなかった。

DDLの変換や初期化スクリプト、データ移行に関しては id:soudai さんに完全にお任せしていた。DDLの変換はChatGPTに投げたやつを手直しして使っていたらしい。時代ですね。

というわけで次も(次があれば)PostgreSQLでやって、いいところまで行きたいですね。できればデータモデリングからやり直したり、ビューをうまいこと使うとかそういう感じでやりたい。なお仕事は完全にMySQL使っています。

また来月振り返りがあるので、反省していきます。ではまた。

Goで複数の引数を取る関数やメソッドをどう書くのがいいのか

普段Go書いているときにそこまで気にしてなかったが、ふと気になったので色々パターンを挙げてみる。なおこの記事には「答え」が書かれてないので、みなさんの意見を聞かせてください。

複数の引数を取るパターン一覧

• そのまま引数を羅列する
• 複数の引数をまとめたstructを取る
• Functional Options Pattern

そのまま引数を羅列する

例えばHTTPリクエストを行うような関数があったとして、

func Request(ctx context.Context, method http.Method, _url string, query url.Values, formValues url.Values) error {
    // do something
}

というシグネチャが考えられる。

実際にnet/http.NewRequsetWithContext は func NewRequestWithContext(ctx context.Context, method, url string, body io.Reader) (*Request, error)というシグネチャになっている。

このやり方のメリットとしては、引数の記述を呼び出し側に強制できることである。例えば、methodという引数は必ず呼び出す時に書かないといけないため、http.MethodPostなのか、http.MethodGetなのかを呼び出し側が指定することを強制できる。これにより呼び出し側コードに現れない暗黙の挙動の出現を抑えられる。記述は冗長になるが、暗黙の挙動が少なければ、コードレビューのレビュワーからすると嬉しい。

一方で、引数は記述順が固定であり、それぞれ記述が必須になるため、呼び出す側は関数の定義を覚えておかなければならない。ただ、現代はgoplsによる関数シグネチャの補完が効くので、コードを書く側の環境さえ整っていれば、この心配もいらないと思われる。

複数の引数をまとめたstructを作る

先ほどと同じような関数を以下のように変形する。

type RequestInput struct {
    Method     http.Method
    URL        string
    Query      url.Values
    FormValues url.Values
}

func Request(ctx context.Context, input RequestInput) error {
    // Do Something
}

実際に、net/http.Client.Doというメソッドは、このようなパターンのメソッドであると言える。

func (c *Client) Do(req *Request) (*Response, error)

このパターンのメリットは、呼び出し側で引数を列挙する順番が固定でないことである。また、RequestInput自体が呼び出し側で入れ物として使えるので、以下のように、適宜判断しながら引数を詰めていくこともできるだろう。

var input RequestInput
if isPost {
    input.Method = http.MethodPost
}
input.URL = something.URL()

if err := Request(ctx, input); err != nil {
    return fmt.Errorf("error Request: %w", err)
}

また、RequestInput自体にメソッドを生やすことも可能である。例えば引数にはURLを取るが中身はそのbasenameしか利用しない場合は、RequestInput自体にメソッドを生やすとRequest関数の中身の量を抑えられる。

func (r RequestInput) urlBasename() (string, error) {
    u, err := url.Parse(r.URL)
    if err != nil {
        return "", fmt.Errorf("error url.Parse: %w", err)
    }
    return path.Base(u.Path), nil
}

func Request(ctx context.Context, input RequestInput) error {
    basename, err := input.urlBasename()
    if err != nil {
        return fmt.Errorf("error RequestInput.urlBasename: %w", err)
    }
    // Do something
}

RequestInputのような引数のためのstructは他の関数やメソッドにも使いまわせる。個人的には、使いまわさない方が良い気がしているが、この言語化はうまくできていない。

また、Goにおいて、短い識別子は有限な資源である。「そのまま引数を羅列する」で述べたときの関数シグネチャ内のURLを取る仮引数の名前はあえて、_urlとしている。これは、packageであるnet/urlとの重複を避けるためである。実用的には一文字でuとしてしまうことが多いが、型がstringであるゆえ、uに何を入れればいいかをコメント等で指示しなければならない。urlという名前が使えれば、そこまでの配慮はいらないはずである。 一方、structを使う場合は、関数内ではinput.URLという名前を使えるため、このケースではフィールド名でわかるため、何を 入るべきかをあまり記述しなくて良いと思われる。また、structであれば、フィールド自体にコメントを詳細に書くことも可能である。

デメリットとしては、呼び出し側にフィールドに値を明示的に入れることを強制できない。つまり、

Request(ctx, RequestInput{})

という呼び出しもコンパイルは通ってしまう。この場合、各フィールドにはゼロ値が入ってしまう。また、Goにおいて、ゼロ値をあえて指定した場合と、何も指定しなかった場合の区別は関数側ではできない。このケースではあまり考えられないだろうが、あえてURLに空文字を指定した場合と、何も入れなかった場合（もしくは記述し忘れた場合）の区別はできない。

Functional Options Pattern

Functional Options Patternは必須ではない引数を指定する際に用いられるが、指定した場合と指定しなかった場合の区別にも使える。

type requestInput struct {
    hasMethod bool
    method     http.Method
    hasURL bool
    url        string
    hasQuery bool
    query      url.Values
    hasFormValues bool
    formValues url.Values
}

type RequestOption interface {
    Apply(*requestInput)
}

type WithURL string

func (w WithURL) Apply(input *requestInput) {
    input.url = string(w)
    input.hasURL = true
}

func Request(ctx context.Context, options ...RequestOption) error {
    input := &requestInput{}
    for _, o : = range options {
        o.Apply(o)
    }
    // Do something
}

こうすれば、URLが指定されたかどうかをhasURLフィールドで区別できる。ただ、この区別は実行時の話であり、指定しなかったらコンパイルに失敗するという挙動を実現するには「そのまま引数を羅列する」を使わないといけないだろう。

番外編

関数を分けてしまう

上記の関数でmethodは数パターンしかなく、またRequest関数自体がGetとPostしかサポートしないのであれば、引数で取るのではなく、関数自体を分けてしまうことも考えられる。

func GetRequest(ctx context.Context, _url string, query url.Values, formValues url.Values) error
func PostRequest(ctx context.Context, _url string, query url.Values, formValues url.Values) error

中身の記述が冗長であるのであれば、別のプライベート関数に委譲すれば問題がなさそうである。

func GetRequest(ctx context.Context, _url string, query url.Values, formValues url.Values) error {
    return request(ctx, http.MethodGet, _url, query, formValues)
}

func PostRequest(ctx context.Context, _url string, query url.Values, formValues url.Values) error {
    return request(ctx, http.MethodPost, _url, query, formValues)
}

func request(ctx context.Context, method http.Method, _url string, query url.Values, formValues url.Values) error {
    // Do something
}

また、GETとPOST以外のメソッドは記述すらないわけであるから、サポートしていないDELETEやPUTなどを投げようとしても記述しようがないし、無理やり書いてもコンパイルエラーになるだけである。なので一種のバリデーションとしても機能している。

私はコードレビューでこういった状況で、パターンが少なく、またif文でバリデーションを行うぐらいであれば、関数でわけてしまった方が良いという旨のコメントをよく行う。

まとめる引数、まとめない引数

この記事の例では、context.Contextは一貫してまとめない対象である。context.Contextはドキュメントで明示的にstructに含めずにひとつ目の引数として関数に渡しなさいと書かれている。

Do not store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it. The Context should be the first parameter, typically named ctx

pkg.go.dev

よって、この例でもそのようにした。net/http.Requeststructについては歴史的経緯でcontext.Contextが含まれている。Go 1.7より前はcontext.Contextが存在しなかったが、net/http.Requestやnet/http.Client.Doは存在したためである。

その他にもstructにまとめない方が良い引数はあるかもしれない。例えば拙作のORM sqllaを使う際にcontext.Contextとともに渡すsqlla.DBは必ず2つ目の引数として渡すようにしている。この引数はDBの接続情報を持つものであるが、トランザクションを使う場合はある特定かつ、その呼び出しでしか使ってほしくないコネクションが含まれている。なのでstructに入れて使いまわされるよりは、その危険性が少ないシグネチャにしている。

テストでよく見かける*testing.Tもそのような対象に見える。こういった変数には何らかのパターンがあるかもしれない。

株式会社はてなに入社しました

株式会社はてなに入社しました

株式会社はてなに入社しました - hitode909の日記

YAPC::Kyoto 2023に行ってきました #yapcjapan

はい、というわけですね、YAPC::Kyoto 2023に行ってきました。「ブログを書くまでがYAPC」とのことなので、書きます！

yapcjapan.org

自分の発表

speakerdeck.com

「デプロイ今昔物語 〜CGIからサーバーレスまで〜」という話をさせていただきました。デプロイにとどまらず、僕が興味がある話をするみたいな感じになりましたが、皆さんも楽しんでいただけたでしょうか？　こういう技術デモ主体のトークは聴衆の反応で盛り上がる面があるので、オフラインならではということで、今回の形態を選択しました。会場ではデプロイが成功するたびに拍手をいただき、大変助かりました。ありがとうございます。

多分上のスライドだけでは、何の話しているかはほとんど伝わらなくて、このトークは実際にデプロイするデモを主体として構成されています。当日配信された動画も問題がなければアーカイブ配信されるそうなので、その時に見てみてください。

また、このトークは仕事に役立つ！とか人生の糧になる！みたいなのを目指したものではなく、娯楽としてやっています。僕は歴史物のドキュメンタリーであったり、ノンフィクションの本が大好きです。例えばサイモン・シンの「フェルマーの最終定理」という本が好きです。

フェルマーの最終定理（新潮文庫）

こう言った数学の歴史を辿るのとは少し違いますが、Webの技術にも歴史があります。すでに30年ぐらい経っているのだから、昔に考えられていたWWWと今のWWWは大きく想定が違うでしょう。なので、今からするとなんでこうなっているんだろう？という技術があります。

でも歴史は繋がっていて、技術も繋がっています。技術と技術のつながりを知ると僕は面白い！と思えます。そういった面白い面が皆さんに伝わったら僕は大変嬉しいです。

また、このトークを作るのに際して、昔話のネタを提供してもらった会社の皆さんや、Hachioji.pmの方々に大感謝です。

このトークに盛り込まなかった当時のCGI環境の歴史探訪であったり、環境構築のメモも後日公開予定です。実験的にzennで100円ぐらいで売ろうかなと思っています。

久しぶりの"オフライン"開催

前回のオフライン開催はYAPC::Tokyo 2019で、それまでもYAPC::Okinawa 2018 ONNASONであったり、YAPC::Fukuoka 2017 Hakata、はたまたYAPC::Nagoya::Tiny 2019というのもありましね。

こうやってコンスタントに続けられてきたYAPC::Japanでしたが、開催予定だったYAPC::Kyoto 2020が例のアレで"延期"になり、そこからはJapan.pmであったりYAPC::Japan::Online 2022といった形で繋げられてきたわけです。そこでやっと満を持してYAPC::Kyoto 2023が開催というわけで、僕も周りもなんだかはしゃいでいたり、「前どうしていたっけ？」みたいな雰囲気もあり面白かったです。

僕はオンラインではやはりどうしても難しかった「廊下でのコミュニケーション」を久しぶりにやってみて、「ああこれこれ」みたいな気持ちなりました。またYAPC::Japan::Onlineでも実験的に行われていた「懇親会」ですが、今回は前と大体同じ形で行われて、「ああこれこれ」ともなりました。

懇親会ではyusukebeさんが目の前の席だったのですが、隣に立ち替わり立ち替わりで、比較的若い人たちがyusukebeさんの横に話に来ていたのを思い出します。僕は以前から知り合いでしたが、それでも僕から見るとyusukebeさんはすごいPerlハッカーです。そんな憧れの人と直接話せる場があるというのも幸せだなあと思いました。

他にも僕が(主にrebuild.fmで)miyagawaさんのファンで、会場に来ていたらしいが会えなかったという話もしましたね。そういうこともある。

刺さった話

nekokakさんのゲストトークであったり、onishiさんのKeynoteはじんわり来てしまいました。僕は今でも「エンジニアリング一本でこれからも食っていくんだ！」っていう気持ちはあるんですけれど、エンジニアリングにしてもお客さんがお金払ってくれてからこそっていうのはあります。だからnekokakさんの自分の領域を狭めずに「全部やる！」みたいな気持ちはすげー大事だなって思うし、それがサービスを成功に繋げるよなって。またonishiさんのその時に応じてロールを変えるというか、これは逆説的だがきっかけを掴み損ねないというか、めっちゃ大事だな...っていうのがあります。

最近だけCGIでデプロイわーいってやってるけれど、普段は真面目にどうやったらサービスを前に進められるか、みたいなことを考えているので、クニュッとなっていました。よかったです。

裏トーク

ちょいちょい裏トークに入り浸っていました。廊下の延長みたいなところがあリマス。みんなでトークを見つつ、脱線しながら話すという体験は廊下そのものですが、会場にいると見ながらダベるみたいなのは出来ないので新体験ですね。danさんやkazeburoさんなど、ここも憧れのハッカーの方たちがいてくれて、そういった方々とあーでもない、こーでもないと話ができて幸せでした。今回のYAPCは体験から得られる幸福度が高い。

はてな社

入社 pic.twitter.com/q7ZCxQBRAH

— とっとこラム太郎🐑 (@mackee_w) 2023年3月19日

「これがあのはてな社」かとなってて、実は初来社です。東京オフィスは何度か行ったことはあるのですが、こういうカンファレンスの後に行くみたいなのはなかったですね。ここでも色々テックやそうでないことについてあーでもないこーでもないとダベってました。

「長寿と繁栄を」

長寿と繁栄を #yapcjapan pic.twitter.com/yWLMcQL2Ci

— とっとこラム太郎🐑 (@mackee_w) 2023年3月20日

いわゆる🖖のサインですが、長寿なPerlは長寿なりの価値というのがあると思います。長寿なコミュニティもある程度入れ替わりを繰り返しながら、長寿であるがゆえの価値が溜まっていくと思います。YAPCも継続することで価値があるし、これからも価値が大きくなっていってほしい。僕もその一翼を担えたらいいなと思いました。あと、僕も広島に縁があるPerl Mongerなので！

というわけでお疲れした！！！　こういう素晴らしい会を開いてくれたスタッフさんたちに大感謝です。

YAPC::Kyoto 2023に行ってきました #yapcjapan

はい、というわけですね、YAPC::Kyoto 2023に行ってきました。「ブログを書くまでがYAPC」とのことなので、書きます！

yapcjapan.org

自分の発表

speakerdeck.com

「デプロイ今昔物語 〜CGIからサーバーレスまで〜」という話をさせていただきました。デプロイにとどまらず、僕が興味がある話をするみたいな感じになりましたが、皆さんも楽しんでいただけたでしょうか？　こういう技術デモ主体のトークは聴衆の反応で盛り上がる面があるので、オフラインならではということで、今回の形態を選択しました。会場ではデプロイが成功するたびに拍手をいただき、大変助かりました。ありがとうございます。

多分上のスライドだけでは、何の話しているかはほとんど伝わらなくて、このトークは実際にデプロイするデモを主体として構成されています。当日配信された動画も問題がなければアーカイブ配信されるそうなので、その時に見てみてください。

また、このトークは仕事に役立つ！とか人生の糧になる！みたいなのを目指したものではなく、娯楽としてやっています。僕は歴史物のドキュメンタリーであったり、ノンフィクションの本が大好きです。例えばサイモン・シンの「フェルマーの最終定理」という本が好きです。

フェルマーの最終定理（新潮文庫）

こう言った数学の歴史を辿るのとは少し違いますが、Webの技術にも歴史があります。すでに30年ぐらい経っているのだから、昔に考えられていたWWWと今のWWWは大きく想定が違うでしょう。なので、今からするとなんでこうなっているんだろう？という技術があります。

でも歴史は繋がっていて、技術も繋がっています。技術と技術のつながりを知ると僕は面白い！と思えます。そういった面白い面が皆さんに伝わったら僕は大変嬉しいです。

また、このトークを作るのに際して、昔話のネタを提供してもらった会社の皆さんや、Hachioji.pmの方々に大感謝です。

このトークに盛り込まなかった当時のCGI環境の歴史探訪であったり、環境構築のメモも後日公開予定です。実験的にzennで100円ぐらいで売ろうかなと思っています。

久しぶりの"オフライン"開催

前回のオフライン開催はYAPC::Tokyo 2019で、それまでもYAPC::Okinawa 2018 ONNASONであったり、YAPC::Fukuoka 2017 Hakata、はたまたYAPC::Nagoya::Tiny 2019というのもありましね。

こうやってコンスタントに続けられてきたYAPC::Japanでしたが、開催予定だったYAPC::Kyoto 2020が例のアレで"延期"になり、そこからはJapan.pmであったりYAPC::Japan::Online 2022といった形で繋げられてきたわけです。そこでやっと満を持してYAPC::Kyoto 2023が開催というわけで、僕も周りもなんだかはしゃいでいたり、「前どうしていたっけ？」みたいな雰囲気もあり面白かったです。

僕はオンラインではやはりどうしても難しかった「廊下でのコミュニケーション」を久しぶりにやってみて、「ああこれこれ」みたいな気持ちなりました。またYAPC::Japan::Onlineでも実験的に行われていた「懇親会」ですが、今回は前と大体同じ形で行われて、「ああこれこれ」ともなりました。

懇親会ではyusukebeさんが目の前の席だったのですが、隣に立ち替わり立ち替わりで、比較的若い人たちがyusukebeさんの横に話に来ていたのを思い出します。僕は以前から知り合いでしたが、それでも僕から見るとyusukebeさんはすごいPerlハッカーです。そんな憧れの人と直接話せる場があるというのも幸せだなあと思いました。

他にも僕が(主にrebuild.fmで)miyagawaさんのファンで、会場に来ていたらしいが会えなかったという話もしましたね。そういうこともある。

刺さった話

nekokakさんのゲストトークであったり、onishiさんのKeynoteはじんわり来てしまいました。僕は今でも「エンジニアリング一本でこれからも食っていくんだ！」っていう気持ちはあるんですけれど、エンジニアリングにしてもお客さんがお金払ってくれてからこそっていうのはあります。だからnekokakuさんの自分の領域を狭めずに「全部やる！」みたいな気持ちはすげー大事だなって思うし、それがサービスを成功に繋げるよなって。またonishiさんのその時に応じてロールを変えるというか、これは逆説的だがきっかけを掴み損ねないというか、めっちゃ大事だな...っていうのがあります。

最近だけCGIでデプロイわーいってやってるけれど、普段は真面目にどうやったらサービスを前に進められるか、みたいなことを考えているので、クニュッとなっていました。よかったです。

裏トーク

ちょいちょい裏トークに入り浸っていました。廊下の延長みたいなところがあリマス。みんなでトークを見つつ、脱線しながら話すという体験は廊下そのものですが、会場にいると見ながらダベるみたいなのは出来ないので新体験ですね。danさんやkazeburoさんなど、ここも憧れのハッカーの方たちがいてくれて、そういった方々とあーでもない、こーでもないと話ができて幸せでした。今回のYAPCは体験から得られる幸福度が高い。

はてな社

入社 pic.twitter.com/q7ZCxQBRAH

— とっとこラム太郎🐑 (@mackee_w) 2023年3月19日

「これがあのはてな社」かとなってて、実は初来社です。東京オフィスは何度か行ったことはあるのですが、こういうカンファレンスの後に行くみたいなのはなかったですね。ここでも色々テックやそうでないことについてあーでもないこーでもないとダベってました。

「長寿と繁栄を」

長寿と繁栄を #yapcjapan pic.twitter.com/yWLMcQL2Ci

— とっとこラム太郎🐑 (@mackee_w) 2023年3月20日

いわゆる🖖のサインですが、長寿なPerlは長寿なりの価値というのがあると思います。長寿なコミュニティもある程度入れ替わりを繰り返しながら、長寿であるがゆえの価値が溜まっていくと思います。YAPCも継続することで価値があるし、これからも価値が大きくなっていってほしい。僕もその一翼を担えたらいいなと思いました。あと、僕も広島に縁があるPerl Mongerなので！

というわけでお疲れした！！！　こういう素晴らしい会を開いてくれたスタッフさんたちに大感謝です。