valid,invalid

関心を持てる事柄について

Ruby Weeklyに自作のgemが掲載された

毎週購読しているRuby Weeklyに初めて自作のgem pbtが掲載された記念。

rubyweekly.com

おそらく先週Hacker Newsで少し目立ったので拾ってもらえたのだと思う。おかげでまた少しstarsが増え、ようやく自分のGitHub repositoriesのtopを更新できた。(長らくtopにあったのが6年前に作った学習用のtemplate repositoryみたいなやつだった)

実際のアクセス数や伸びでいうとHacker Newsのトレンドになったときのほうが大きかったのだが、普段読んでいるNewsletterに掲載されるのはまさに"光栄"で、異なる嬉しさがある。

Hacker Newsで自作のOSSを紹介したらRanking 1位になり一晩で+100 stars付いた

自作のRuby gemをHacker Newsにて紹介したところ、一晩でGitHub repositoriesに100以上のstarsが付いて驚いた。また、リアルタイムでは見逃したのだがHacker News Rankingで数時間1位におり、20時間ほどトップページに載っていたらしい。2024-05-26現在は落ち着いて195pt。

投稿はこちら Show HN: PBT – A property-based testing library for Ruby | Hacker News

2024-05-22のdaily rankingでは11位だった。

続きを読む

Ractorを用いたproperty based testingの並列実行についてRubyKaigi 2024で発表しました

表題の通りRactorを用いたproperty based testingの並列実行についてRubyKaigi 2024で発表してきました。かつスピーカーとしての参加は初めてで、いろいろ稀有な体験ができて総合的にはめちゃくちゃ楽しかった。

続きを読む

RubyKaigi 2024に登壇します

RubyKaigi 2024 に "Unlocking The Potential of Property Based Testing with Ractor" というタイトルで登壇します。Ractor枠、もしくはtesting枠といったところでしょうか。

rubykaigi.org

Abstractに書いた通り、Property based testingというテスト手法のイテレーションをRactorで並列化したら効率的だし誰もやってなくて面白いのではないか?という話をします。

何かしら引っ掛かるものがありましたらぜひ見に来てください。


Ractor。Rubyで真に並列処理が簡単にかけてしかもスレッドセーフであることが保証されてるの、すごいことだと思うのだけどなかなか普段のプログラミングでユースケースが見つかっていなかったんですよね。

一方僕は、普段から並行並列処理をガンガンやっているわけではないものの、Fintech事業従事者としてテスト設計や手法にはそこそこ関心があり。昨年にはProperty based testingに興味を持って他言語のライブラリコード読んだりRubyで試したりしていました。

その過程で

「テストコードって独立した小さい単位の処理だよな」

「propety basaed testingだとそれが数百回イテレーションで実行されている」

「これは並列化の恩恵を受けそうだし、Ractorの良いユースケースたりうるのでは?」

と着想し、今に至ります。


スライドの初稿を完成させて事前提出した段階でこの記事を書いているのですが、練習したところ5~10分ほど時間オーバーしており、削りどころをどこにしようかまだ悩む日々が続きそうです。

いつもは技術的な"深さ"よりも"理解りやすさ"を重視する傾向にあり、深さを求める相手とはAsk the speakerなどで議論するというスタンスをとってきました。が、今回はあのRubyKaigiということもあり、"自分が面白いと思うこと"を詰め込む方針へ転換してみようかなと思っています。

吉と出るか大凶と出るかはわかりませんが、動画を組み合わせた解説やデモなど、これまであまりやってこなかったこともやっていみたいですね。


いやー、RubyKaigiへの登壇は人生でやりたかったことリストに含まれていたので、本当に感無量です。

残り一週間、健康に気をつけていきます。(GWに一度体調を崩した人の顔)

YAPC::Hiroshima 2024のついでに広島観光してきた

YAPC::Hiroshima 2024に関する記録はYAPC::Hiroshima 2024に参加してIdempotency-Key Headerの話をしてきた - valid,invalidに残したので、この記事は旅行記とします。

かつてTwitterで "広島の粗大ゴミ" を名乗っていた男の、人生初の広島遠征────

続きを読む

YAPC::Hiroshima 2024に参加してIdempotency-Key Headerの話をしてきた

表題の通りYAPC::Hiroshima 2024にスピーカー、およびスポンサー企業の一員として参加してきました。最近はブログ不精となっていてイベントに参加しても記事を執筆せずにいたものの、YAPC参加者のすさまじい熱量にあてられたので久々に筆をとってみます。

自分とYAPCとbuilderscon

YAPC初参加です。が、実はYAPCには思うところがありました。

YAPC::Asiaの後継として開催された(ですよね?)buildersconに2017, 2018, 2019と参加しており、このイベントからは過去にめちゃめちゃ感化されていたのでした。特に初参加のbuilderscon 2017に強く影響を受けてから僕は登壇やOSS活動を始めたので、勝手な思い入れがあるカンファレンスです。

「buildersconにもやがて登壇するぞ」と思っていたものの直近の数年は非開催となってしまったので夢が潰えたような気もしていました。ところがどっこい「buildersconに一番雰囲気が似てるカンファレンスはYAPCなのでは(想像)」「YAPCに登壇できたら目標達成では(妄想)」という気づきがあり、プロポーザルを出してみたところ採択いただき、広島凸という背景でした。

トーク「My Favorite Protocol: Idempotency-Key Header」について

YAPC::Hiroshimaのテーマが"What⁨ I like"ということで、僕の好きなプロトコルであるIdempotency-Key Headerの話をしてきました。RFCにはなっていないものの、StripeやPayPalといった著名決済SaaSでは実運用されている便利HTTPヘッダーです。

僕が携わるB/43でも2021年から導入しており、データ堅牢化に一役買っているという自慢をしました。

テーマ的にソフトトークやキャリア論でもプロポーザルを出せそうだなと思ったのですが、初見のコミュニティで顔を売るならしっかり技術的な内容で興味を惹きたいと思ったのでテクニカルな内容にしました。

ベストトーク賞は取れなかったものの同僚のmitaniさんが素晴らしいトークで広島凱旋&受賞という偉業を成し遂げていたのでオッケーです。いや、ぜんぜんオッケーじゃなくて悔しい!このような投票型の企画があるカンファレンスをあまり知らないので、今度登壇する際にはベストトークを獲りたい。

というわけで逃したものの「ベストトークとして投票しました!」という方に懇親会でお声がけいただいたり、複数の方がブログにて言及してくれたのを観測しており、しっかりと人の心に残る登壇ができたのはポジティブです。

登壇のふりかえり

  • 前夜祭の番宣リレーで「冪等!冪等!冪等!」がウケてたようで良かった
    • SmartHRのブースでinaoさんに挨拶したとき「あっ、冪等の人ですか」って言われて嬉しかった
  • 時間が押してて即開始となってしまい、会場を暖める"前説"ができなかった
  • 愛機のLogicool Spotlightがかっこいいと言われた
    • けど会場でうまく動かないシーンがありちょっと焦った
  • 質疑応答がいっぱい来て嬉しかった
    • YAPC、全体的に質問が多くてとても良い雰囲気だった
  • 大量のスライドを作っておきつつ「時間がないので」と言って飛ばしまくるテクを褒められた
    • Appendixに書いてても読まれない・触れずに終わってもったいないので本旨に混ぜ込んだほうがいい
    • 「ここで止まる」スライドが面白い

スポンサー企画「CTOを破産から救おうチャレンジ」

所属するスマートバンクが椅子スポンサー────椅子にチラシを掲載する権利を得る────となった機会を活かし、今回は軽めのコーディングクイズを出題してみました。

Idempotency-Key Headerを理解するとシュッと解ける問題になっており、僕のトーク内容で学んだことを実践し、身につけていただけるような教育的なクイズを意図しました

github.com

Perl, Ruby, Goの3言語のいずれかで挑戦可能ですので、参加者も非参加者問わずまだ見ていない方はぜひ一度cloneして挑戦してもらえると喜びます(Xにpostしていただけると更に喜びます)。

ちなみにLTにはこのクイズに関連したコード難読化ネタで応募していました。残念ながら非採択でしたがどこかにて供養したいと考えています。

fortee.jp

良かったトーク

naoyaさんの「関数型プログラミングと型システムのメンタルモデル」

  • 以前の講演のスライドだけ目を通していたがリアルに聞くとさらに面白かった
  • これは型にとどまらないモデリングの話だと僕は捉えている
    • なので静的型付けを用いない言語であってもある程度のエッセンスを活用できる
      • RubyでUserをActiveUserとDeactivatedUserに分けたって良い
      • classである必要がないならDataやStructで宣言したって良い
    • 型は検証のためのツール。それでもメンタルモデルに影響を与えるので型とモデリング間の相互作用が生まれるので当然あると良い
  • どうしたって副作用はあるけどどうする?という問いに「純粋関数の世界とIOの世界を分けるという」のは納得感が高い

...のようなことを思っていたらご本人も同じようなことをpostされていました。

naoyaさんにできれば質問したかったのは、「世界を切り離さずに済む、あるいは近づける方法としてRDBでイミュータブルモデリングを実践するのはどうか?」という点。

世界を切り離すことへの納得感はありつつ、RDBにおける物理表現と論理表現の間にギャップがあるのは大部分の開発者にとって難しい(変換の認知負荷が生じる)と考えていて、そこを埋めるアプローチがあるのではないか?

t_wadaさんの「理解容易性と変更容易性を支える自動テスト」

  • 自動テストについて最もよく整理された資料だと感じており、折に触れて引用したい
  • Test ScopeとTest Sizeのマトリクスが特に好き
  • 僕はデトロイト学派

変更不可能な外部からの要求で大量のパラメーターを送りつけられるWeb APIのように、自分たちが管理できないコードベースとの接合点で信頼性の高いテストを書くにはどうすればいいか?」という質問をさせていただきました。

仮定をテストに混ぜ込むしかない、自作自演にならざるを得ない、実物をCIで呼び出せない...といったことが起こりがちなこの課題に対して「腐敗防止層やHumble Objectの導入でTest SizeとScopeを狭めていき、信頼性の高いテストの割合を増やしていくと良い」という回答を頂いた。

mitaniさんの「VISAカードの裏側と “手が掛かる” 決済システムの育て方」

身内びいき抜きに一般公募では最も感銘を受けたトークでした。

今回のmitaniさんの登壇内容に、僕はmoznionさんの「Javaカードの世界 」(2018) を勝手ながら重ねており、どちらも技術者の心のくすぐり方が最高に巧かったなと感動していました。そういえば、どちらもカードの話題だな...。

このように業務上で学んだことを公知にしていく試みがベストトーク賞というのも感慨深いものです。というのも、登壇しない/できない理由の第一位は「ネタがない/業務で大したことやっていない」というものだからです(ohbarye調べ)。いち事業会社の中で必要に迫られ行う日々の業務の延長にも、このように多くの人の心を捉える登壇があるのだ... と多くの人が思えたのではないでしょうか。

加えて、クレジットカードのように現実世界に存在する物理的なアイテムとソフトウェアの交差点に存在する難しい課題と、それらをどう解いていくかに関心を抱くエンジニアは思っていたよりも多そうだというのも発見でありました。

とほほさんのキーノート

もはや何を言うまでもなく、とにかく今回のYAPCテーマにもぴったりで圧巻の内容。技術でもそれ以外でも、自分も好きな何かをゆるくても長く続けてみようと思える素晴らしいトークでした。

懇親会で話した20歳ぐらいの学生さんもとほほさんを知っており、オールタイムレジェンドであることを知りました。

その他の感想

良かったこと

  • お昼の穴子めし弁当がめっちゃおいしかった
  • ゲストや登壇者はシニアな方が多そうだったが、参加者の年齢は幅広く、学生の方とも話せた
  • 見知らぬ人にも話しかけてくれる良い雰囲気があった
  • serimaさんなど久々にリアルで話せた方がいた
  • karasawaさんが話しかけてくれた

反省 / 心配

  • 2日目の懇親会後に腹痛になってしまい二次会に参加できなかった
  • ogijunさん、kyannyさん、shibayuさんなどじっくり話したい方がいたが話す機会がつくれなかった
  • YAPCのクオリティやホスピタリティが高いものの、一方チケット安すぎて大丈夫...?と思った

ニュートラルなこと

  • ベストトーク賞の投票数は非公開でいいけどフィードバック/感想文を共有してもらえると嬉しい
  • 前夜祭はトークと飲み会が同時会場で行われており、TokyuRuby会議みたいだと思った

広島旅行の話も混ぜると大変な長さになりそうなのでYAPCの感想だけで筆を置くことにします。

SmartBank, Inc.に入社して3年経過した

タイトルの通りSmartBank, Inc.に入社して3年が経過したので記念に整理。

ちなみに前回書いたのは1.5年経過のタイミングで、だいぶ遅まきの入社エントリであった。

ohbarye.hatenablog.jp

やってきたこと

半年なり1年なりの区切りをトリガーに書いていれば差分を書きやすいのだけど、その習慣がついていないのでやむなく、今回は3年分まとめて書いてしまおう。3年間でやってきたこと*1のうち公にしているものたち*2を並べるとたくさんあるが、もちろんほとんどはチームでやってきたことである。

所感

いろいろやったな〜と思いつつ事業に直結する機能開発とエンジニアリング面での取り組みを両立するには、資金調達の成功や事業がしっかり成長軌道にあることが前提だと再認識した。

一つ目のプロダクトローンチ前の"立ち上げ時期-ゼロイチ-"に入社したにも関わらず、"方向転換-ピボット-"することなく"成長-グロース-"に繋がり、今も集中的にリソース投下できている環境はありがたい。3年前の意思決定の成功は追認しても良いだろう。


余談だが、最近アーリーステージのスタートアップの選び方なるものを知人に聞かれることが何度かあった。メガベンチャーや上場後の企業勤めで、一度はスタートアップで働いてみたいという好奇に由来することが多いようだ。経験はしてみたいけれど事業以前に組織が破茶滅茶でないか、エンジニアリングが軽視されていないか、ハードワークすぎるカルチャーでないか。等々の不安を解消できるほど情報がオープンにされている会社が少ない...という感じられているらしい。

スタートアップに限らず会社選びは何を求めているのか次第なので画一的なアドバイスはできないし、事業の良し悪しや成否の蓋然性を評価できる"眼"は自分にはないけれど、ファウンダーや経営陣に複数回の起業を経験しているメンバーがいるかどうかを評価軸に加えてはどうかと伝えている。シリアルアントレプレナーというやつだ。

そうした経営者は前回までの起業の成否や反省を踏まえて落とし穴やアンチパターンを避けることに意識的だし、事業を伸ばすには持続可能でスケーラブルな組織が必要なことも知っている可能性が高い。*3

やるべきこと・やりたいことに注力できている環境の一要因、一例として自己の経験からそんなことを思っていた。


話が逸れたけれども引き続きやっていきます。僕と同じサーバサイドエンジニアに限らず各職種を積極採用中なので気になる方はぜひお声がけください。

カジュアル面談への応募

*1:時系列はバラバラ

*2:公にしているというか、CVに記載しているようなもの

*3:もちろんこういう質問をしてみようとか、バックドアリファレンスはとろうとか、他にもたくさん言えることはある