よもやま話β版

よもやま話を書きます。内容はぺらぺら。自由に書く。

Kaigi on Rails 2024 楽しかったです!

Kaigi on Rails 2024 お疲れさまでした!

kaigionrails.org

国際展示場駅の駅広告

今回はオーガナイザーのチームメンバーとして、春先の準備フェーズから関わらせていただきました。今まではいち参加者としてのほほんと色んなカンファレンスにお世話になってきましたが、時間をかけて準備されて当日を迎えているんだなぁということを改めて体験として実感しました。

当日は主に受付の担当をしていました。有明まで足を運んでくださった参加者のみなさんに、イチバンにご挨拶ができて嬉しかったです!

セッション

スタッフとしてお仕事もしつつ、いちRubyistとしてセッション聴講もやはり外せません。うまくスタッフ間でシフト調整していただいて、拝見できました。*1 タイミングが合わず残念ながら見れなかったセッションがたくさんあるのですが、2トラックあった以上、スタッフに限らず参加者全員もれなく半分は見逃してるはずなので、録画の公開を楽しみに待ちたいと思います! 下記、拝見の記録。

入門『状態』

(Day2 13:05〜13:20)
『状態』を定義する・保持する・変更するというのは、システムをつくる上で避けては通れないところです。『状態』の管理方法について、自分が無自覚に注意していたことをあらためて明文化してもらった感覚がありました。紹介されたソースコードが話が進むにつれて、どんどんリファクタリングされてシンプルに、より読みやすくなっていくのが分かりました。初学者の方のコードをレビューする機会が時々あるのですが、状態の管理でお困りの様子を感じたらこちらのセッション記録を紹介しようと思いました。

Sidekiq vs Solid Queue

(Day2 13:30〜14:00)
自分が面倒をみているリポジトリでは Sidekiq に大いにお世話になっているところなので、対抗馬としての Solid Queue に大変興味がありました。やはり後発の方に乗り換えがいいのかしら…という気持ちで聴講開始したのですが、Sidekiq 使っているならそのままでもよい・いまから気軽に Rails new なら Solid Queue、というおおまかな方針を知ることができてよかったです。バックグラウンドワーカーの歴史が、ストレージ性能の向上・ Active Job 以前/以後で変遷していく様子もあわせて把握できて、とても勉強になりました。

WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと

書籍『Rails によるアジャイルな Web アプリケーション開発』との出会いを “恋に落ちた” と表現するところから始まった島田さんの基調講演、大変感銘を受けました! 特に、「修復する」という言葉の意味について、「元の状態に戻す」ではなく「変化に適応(調和)させる」ことなのだ、というお話にハッとさせられました。

自分の個人的な体験の中でも、「これは Rails Way から外れようとしている」という直感がはたらき、設計を見直すという行動につながったことがこれまでに何度もありました。Rails に親しんでいると、修復(再調和)が必要な箇所に対して”直感”・”違和感”という形で検知でき、それらを解消する方向に進むことこそが将来のトラブル回避につながるということが確かにあるように感じます。おお…これが…「導きの星」…!?

一方で、Rails Way に助けられつつも、そこに乗り続けていられるかというと、時間的都合とか技術的都合とかあらゆることで常に脱線との戦いがあります。「シンプルを保つのは難しい」ということにも首がもげるほど頷きつつ、それを実現し続けるための学びをこういった書籍やカンファレンスから獲得して、研鑽を積んでいきたいと思いました。もちろん、「たのしい」を忘れずに!

そして Next Kaigi へ…

個人的なスタッフとしての反省は多々ありますが、それはチーム振り返りに持ち込むとして…。いまは無事に閉会したことにほっとしています。Twitter(X)*2 のタイムラインには「良い会だった!」というコメントがたくさん投稿されていて、自分が微力ながらその会をつくる一員として稼働できたということがものすごく嬉しいです。8月上旬、凄まじい数のCFPを読み切った甲斐がありました。

今回、自分はCFP出したいなぁと思ってはいたものの、ふわふわっとした考えを言語化・具体化しきれず、出しそびれてしまいました。採択有無はともかく、チャレンジも出来ていなかったというところに悔いが残っています。来年の会場はもう決まっており、Next Kaigi はすでに動き出しているので、自分が考えていることを形にする訓練をしていきたいです。

そもそも半年後には RubyKaigi 2025 (2025/4/16-18) があるわけで…。
というかその前に RubyWorld Conference 2024 (2024/12/5-6) があり…。
もっと言うと 東京Ruby会議12 (2025/01/18) も…。

おっ、忙しいぞ…!
たのしいことで忙しいのは良いことだ!

Kaigi on Rails 2024 の名札、ピンバッジ、ステッカー
たのしかった〜!

*1:こばちえさん、しげるさん、ふぁらおさん、調整ありがとうございました〜!

*2:まだ指と脳みそがTwitterって反射的に書いちゃう人間です

STORES Tech Conf 2024 聴講記録

storesinc.tech

STORESさんの自社テックカンファレンス「STORES Tech Conf 2024 "New Engineering"」を聴講してきました。 特定の会社さんが主体のカンファレンスを初めて体験しましたが、OPムービーがあったりとか、会社さんの汎用のノベルティでなくこの会専用デザインのものをいただいたりして、すごいパワーを感じました。また、いつも他の参加者のみなさんの意見を眺めるための場としてTwitter(X)を利用していますが、今回はDiscordが開設されていました。Discordで感想のTimelineもみれるし、疑問/質問があればスタッフさんに聞ける場所があって大変助かりました。Wi-Fi のID/pass は自分も困ったのでDiscordで他の人のやりとりを拝見して解決しました。感謝です! 🙏

Keynote: AIの時代で我々はどのようにコードを書くのか

AIが台頭してきたなかで「残された仕事」は何か、ということを哲学側面から深ぼる話でとても面白かったです。Techカンファレンスであんまりこういう哲学の話とかをじっくり聞く機会は少ない気がします。 哲学をしっかりと修めていないので、用語には明るくはないのですが、こういう雰囲気の話がすごく好きです。働くなかで出会う合理的にビシッと決められないアレやコレやが脳裏を巡りました。もしかしたら "決める" こと自体はAIにも出来るのかもしれませんが、その決定にYesと言う / 何かし決めたことの結果を受け入れる / その上で先へ進む、ということは人間主体であり続けることは変わらないのだろうと思いました。面白いな〜〜〜。

発表の感想

  • 『繋がっていくサービスを支える開発環境作り』: いっぱい関連サービスを持たれていると、開発環境を整えるのにも苦労がいっぱいあるんだな…としみじみ感じました。 make dev 万歳!!!
  • Jetpack Compose で作る楽しい金額入力画面!』: 金額入力画面のここがステキ!というのを作り手が言えるプロダクトは素晴らしいですね。快適なUI/UXはきめ細やかな気遣いのソースコードで成立しているんだなと改めて思いました。
  • 『STORES の OAuth 大改造!認可対象変更までの険しい道のり』: 認可対象変えるってものすごい大変なことだと思うのですが、やり切った体験談が聞けると勇気がもらえますね。めでたい!
  • 『プロダクトのバンドル化を見据えたプライシングにおけるデータマートの新しい活用方法』: 「値付け」以外にも、色んな変数を持ってて業務で必要なものをスプシ管理する…というシーンは自分もよく出会いがちなので、データマート化しておくというのはトライしてみたいと思いました。とても参考になりました。
  • 『複数の ScrollView が連動! STORES レジでスプレッドシート風 UI を実装しました』: なければ作る!というマインドはアツくて良いですね! UIに対する捉え方(スプシ風にすれば動きそう)、データをどう可視化するか、可視化した結果追加される要求(ドラック&ドロップしたい)の話など UI起点の話題をまとめて聞けて面白かったです。事前にデモを拝見していたので分かりやすかったです。
  • 『本当は秘密にしておきたい、STORES 決済 QA 本番環境での検証の話』: タイトルに秘密とあるのであんまり書きませんが(?) 決済系の本番で問題が起こらないように、様々な検証が注意深く実施されているということを改めて知り、店舗を利用するいち顧客としてありがたいなぁと思いました!
  • 『10年物のRailsアプリにキャッチアップ! 〜コードを読まずに理解したかった〜』 : 歴史のあるプロダクトに親しむためのHowToが詰まっていた凄い発表でした。最終奥義としてのコードを読む方法も、何を手がかりに辿っていくかのフローが整理されており、とても分かりやすかったです。「アプリと仲良くなりたい・健康でいてほしい」という言葉がとてもステキでした!
  • コンポーネントライブラリとして作る、ポータブルなデータ分析』: 「必要は発明の母」を強く感じる発表でした。理想に達するまでに課題が大量に出るなかで、それに立ち向かい続ける、やってみよう!マインドを持ち続ける姿勢がすごくカッコよかったです。また、この業界の「blogを書いて公開する」という慣習がとても有用なんだなということを改めて感じる事例でした。

Keynote: New Ruby Engineering

いちRubyistとして最後にコミッタのお二人の対談を聞けて嬉しいなぁと思いつつ拝聴しました。型・並行処理・速度、いずれも興味深いですが、個人的にはAtCoderRubyで時々やっている影響もあり、速度に関心があります。「すごく速いRuby」、とても楽しみです。またRubyを使っている最大の理由として「書き心地が良い」というところがあるので、変更を入れていくにもRubyを書くときに生じる良い体験が変わらないように、というところを考慮してくださっているというのが本当にありがたいことだと改めて思いました。 15年後はどうなってるのか分からないが、5年後は地続きに感じる、というところから自分もふと色々考えてしまいました。5年か…長そうに思うけど、あっという間なんだろうな…。とりあえず、Rubyに本格的に親しみはじめてからちょうど自分は10年くらいなんですが、ずっと変わらず楽しいので、15年後も楽しいだろうなと思いました。

ありがとうございました

いわゆる「自社テックカンファ」というものが初体験だったのですが、色んな角度の発表が聞けてとても満足感のある会でした。STORESさん、お誘いいただきありがとうございました! 🙌

AI時代の「プログラミング」を目撃した

あるいは、ChatGPTに敗北した記録。 すごいな〜という感動が新鮮なうちに書いておく。


友人が突然、自前のPCを持ってきて「Pythonを入れたい」と言ってきた。自分が普段活用しているのはRubyなので、Python埒外ではあったが、HelloWorldくらいならGoogleに尋ねつつできる。とりあえず Python3 をインストールして、 print("Hello World") の出力をやってみてもらった。それはあっさり終えたところで、ところでここから何がしたいの? と尋ねたところ「株価の予測をしたい」とのことだった。

その要望を聞いた時点で自分の脳みそが最初に出した回答は「無理では?」だった。予測の方法がわからない / 学習の元データどこから取ってくるのか / アウトプット(グラフとか)大変なのでは、などの実現の前に設置された多数のハードル を想像した。

素直に「いやっちょっとそれは難しいのでは…」と伝えてみた。すると友人は「ChatGPTでソースコード出てこないの?」と提案を出してくれた。なるほどそれは令和の解決法だ、と思い、早速聞いてみようということになった。質問文はこうだ。「Python3で動く株価を予想するコードをください」。

ChatGPTにPythonで動く株価予想コードを要求してみた様子
友人が記録をシェアしてくれました、感謝

株価予測のためのPythonコードを提供します。以下のコードは、Yahoo Financeからデータを取得し、FacebookのProphetライブラリを使用して予測を行います。Prophetは、時間シリーズデータの予測に適したライブラリです。 まず、必要なライブラリをインストールします。これには、yfinanceprophetが含まれます。…(以下略)

ChatGPTは友人の要望をほぼ完璧に叶える形で回答を提供した。自分は yfinance も prophet も知らなかったが、APIを使うという発想を持って調べてみることも出来たはずなのに、最初から出来ないと判断してしまったことが大変恥ずかしく、悔しかった。大反省だった。しかしながら、APIを使うという発想が当初からあったとしても、具体回答を提出する速度は完全に負けていただろう。この時点でChatGPTに対しては完全に敗北の白旗を挙げることにはなり、以降はプログラミング完全初学者の友人とChatGPTとのやりとりのフォローアップに努めることになった。

さすがにChatGPTが初回に出したソースコードは一発では動かなかった。エラーメッセージによると、どうやらソースコードそのものではなくライブラリ周りの問題のようだった。自分はPythonのライブラリ周りは詳しくないので、相当頑張らないと解決しないかも、と思いつつ調査を始めた。それと並行で友人には「動きませんでした。エラーメッセージはこちらです」+出力内容の全てをChatGPTに貼り付ける、という対応を試みてもらった。

エラーメッセージに対して要因と解決策を提示してくるChatGPTの様子
あれ? ワイ要らないのでは???

十二分に詳しい説明と対応策が出てきた。敗北の底ってもう一段下があるんだ…。 (しかも、株価のコードをやり始める前に自分がチュートリアル的にNumPyの2系のインストールを友人に勧めたという経緯があり、なんならChatGPTの足を引っ張っていた可能性があるかもしれない。)

友人は初めてのプログラミングに対して興味津々で、ライブラリとは何ぞや、OSSとは何ぞや、似たようなライブラリがあったらどう選ぶのが一般的なのか、このエラーはどういう意味なのだ、等々の質問をしてくれたので、例え話を交えて説明しつつ、エラーが出てはChatGPTに全文貼り付けて修正せよと命ずることを繰り返した。ごく稀に自分のほうで調べたStackOverflowの回答を適用して進捗したシーンもわずかにあったが、ChatGPT側が「過去の回答もダメだった、ならば」ということも踏まえて少しずつ改善したソースを凄まじい速度で再提出してくれるので、自分のほうでソースを書き換える対処をすることはほとんど無かった。

やり取りすること2時間くらいで、友人の「株価の予想をしたい」という要望は、次のように実現した。

ChatGPT製のPythonコードによって出力された株価グラフ
うわー、マジでグラフ出た。すごいな。

ChatGPTが出してきたサンプルコードは、2023年1月1日までのデータをもとに+1年の予想をする、という表記になっていた。その辺りの値をいじれば簡単に2024年夏〜+3年の予想のグラフも取れた。ただし、向こう3年予想が単純にナナメ右肩上がりな雰囲気で「ちょっとこれはありえなさそう」という感想になったが、それもProphetの理解をもっと深めて適切な設定を投げてやれば改善されそうだと思った。

友人の好奇心はグラフを出しただけでは止まらなかった。

「このデータをGoogle スプレッドシートに出力できないの?」

スプレッドシートに出力された株価数値
ChatGPTが数秒でやってくれました

Google スプレッドシート上のグラフ描画はできないの?」*1

スプレッドシートの機能で描画されたグラフ
ChatGPTが数秒でやってくれました

マジでできた。いや〜、すごいな…本当に…。

夕方17時頃から開始して、Googleスプレッドシートにグラフの出力を完了するころには22時を回っていた。逆に言うと、わずか6時間程度で Python未インストールからこのアウトプットまで到達したことになる。しかも手段の9割は「とにかくエラー全文貼ってChatGPTに改善させ続ける」ことだった。すごい時代が来た、と思った。

自分も一応プログラマーの端くれとしてやっているなかで、時折どうしようもないバグの沼にハマるケースがある。そういった問題に出会ったとき、いかにして素早く問題を特定して回避・解決するかというのも、この職業でやっていくために必要なスキルだと思う。そのスキルを発揮する方法として、これまでは「経験則を活用しつつGoogleに尋ねる」というのを主な手段としていた。しかし、これからは経験則+「生成AIに尋ねる」が当たり前になっていくんだろうなぁ、と改めて感じたワンシーンだった。*2

また、Gitの使い方を共有する時間は無かったので、今回は 「ChatGPTが出力してきたコードを毎回全行上書き保存する」 という力強い手法で作業を進めることとなった。そのため、書き換えたい部分があった場合は、都度ChatGPTに「スプレッドシートの名前は "株価グラフ" としてください」などと指定して出力内容を作業者の環境に合わせにいく方法を取った。そのため、友人自身が ソースコードを編集する」という"一般的なプログラミング"をするシーンは殆ど無かった。 わずかにあったとしても、次の修正のタイミングで全行上書きされて掻き消えていった。普段はGitで変更内容をチェックしながら自力でコードを書き換える生活をしているので、「指示して意図通り書き換えさせる」という体験が新鮮だった。 通常であれば必須なはずの、if文・for文・変数などの基礎学習を完全に省略し、「やりたいこと」について具体的に考え、ツール(生成AI)に指示を与えて実現していく…という一連の流れを目撃して、ものすごい衝撃をうけた。これからの「プログラミング」ってこういうことなのかな、と思った。

ちなみに、自分がこの6時間程度でアシストできたのは次のようなシーンだった。

  • ターミナルの開け方
  • ChatGPTが出してくるコマンド $ pip ... は友人の環境では $ pip3 ... としないと動かない点
    • 「以降のコマンドは pip3 で出してください」でコピぺしやすくして解決
  • Ctrl+C でプログラムを終了できること
  • ↑キーで直前に実行したコマンド履歴から呼び出しできること
  • エラーメッセージの解説、エラー文のどのあたりをChatGPTに投げるべきなのか
    • 一応解説はしたが、結局、都度判断するより全文投げたほうがわかりやすいし誤りがなさそうだった…。
  • Prophet が依存するライブラリのインストールエラーの解決
  • 出力されたコードの、どのあたりをいじれば期間設定などが変更できるかの解説
  • Google Cloud で サービスアカウントキーの作成、権限付与の操作
  • サービスアカウントにGoogleスプレッドシートの編集権を与える操作
  • GoogleCloud の Credentials情報が入ったJSONファイルを .py ファイルから呼び出す方法( .py と同一階層に配置し、出力コードのファイル名を指定した )
  • 書き出し先のスプレッドシートの名前の指定方法 ( "タブ名" と "スプレッドシートそのもの" の2つの変数があり、ChatGPTが指示をやや誤解したシーンがあった )
  • Googleスプレッドシートにグラフを描画したいと伝えたら、Pythonで描いたものを画像としてアップロードする方法が提案されてきたので「”スプレッドシートAPIを使って”グラフを作って」という指示が必要そうだと提案
  • Googleスプレッドシートにグラフを描画するためのJSONのキーが仕様にあってなかったらしく弾かれまくったので調査
    • ただし、合間に諦めずにChatGPTに聞きまくってもらっていたところ、何回目かの試行でうまくキーが合致したようで、結局自分の調査の出番は無かった…。

プログラムを「書く」仕事、マジで無くなるかも、と思った体験だった。 一方で、プログラムそのものを書かないとしても、プログラムを読むスキルを持った人間が、適切な語彙や用語で指示する/意図通りの出力を得るために創意工夫する/想定外の問題を解決する、などの出番はあるとも感じた。

「プログラムは思った通りには動かない。書いた通りに動く」という言葉があったはずだが、「指示した通りに動く」と言い換えれば、まだまだ有効な格言だと思う。生成AIと仲良くする方法、覚えよう…。

このエピソードの投稿許可をくれた友人に感謝!

*1:サッとみるだけなら手動でやったほうが速いかもよ、と提案してしまったが、友人曰く「イヤ。自動化したい。」とのことでChatGPTに頼んでAPIJSONを投げるコードを出力してもらった。

*2:Copilotを活用する機会をまだ得られておらず…。生成AIによるdebugはすでにやろうと思えば出来るはずかなとは思っていますが未体験です。やってみなければ…。

沖縄の神社巡りの記録

RubyKaigi 2024 のDay4は神社巡りをしたので記録しておこうと思った。Helpfeel Cosense ( 元・ Scrapbox ) に書きつけておこうかなと思ったが、見出しが欲しくなったのでこっちに記録する。

沖縄行きのちょっと前に本棚整理をしたところ、死蔵していた御朱印帳と再会したので、これもご縁かと思い衝動的にスーツケースに入れて持っていった。沖縄の御朱印なんていただける機会も滅多に無いし良いアイデアだと思った。でも良く考えると、他のRubyistのみなさんとの交流の時間を棒に振ったかなぁという反省がある。しかし、自分はひとり時間もかなり好きなので、なかなか充実した数時間を過ごせた。

琉球八社」というものがあるそうで、全部巡るのも興味があったが、うちいくつかはあまりにも距離があったため、挨拶できるぶんだけしよう、という気持ちで一部だけ参拝することにした。

末吉宮

まず空港から一番遠いところから始めよう、と思い「末吉宮」を目指した。しかし最寄りの「儀保駅」に辿り着いたところ、計画としてはタクシーで行こうと思っていたが、まったく捕まらない+往復して歩いていたら帰りの飛行機の時間がヤバいということに気づき、断念して次点目標の「識名宮」を目指すことにした。

行こうとしたけど断念した記念の案内看板

識名宮」行きも本来はタクシーにお願いする予定だったところを、全くタクシーが捕まらないという誤算のため、ひたすら徒歩で向かうことにした。GoogleMapと神社巡り即席タイムテーブルを照らし合わせるとギリギリ間に合う計算となっていたので。途中、首里城公園エリアを横目にブルーシールを満喫したり、偶然にも「日本の道100選」の「首里金城町石畳道」に行き当たったのでずっと辿ったりなどしてみてみて、これはこれで楽しかった。

首里城跡の石碑をバックにブルーシールアイス
マンゴー味を食べておかねばと思っていた

「日本の道100選」の石碑
日本の道100選」に行き当たった

いい感じの道

ひたすら下る

超小道に分け入ってみようかとも思ったが蜘蛛の巣がすごくてチャレンジ失敗

眺めもよかった。時間の都合で「大アカギ」は断念した。

路地の真ん中に生えている不思議な雰囲気の樹木
これってガジュマルというやつか? ものすごく大きくて圧倒された。

橋の欄干に据えられているシーサー
シーサーかわいいなぁ

凄まじい坂
成り行き上、想定外の凄まじい急坂を越える必要に迫られた。徒歩の決断をちょっと後悔した。

坂の頂上からの眺め
天辺からは街が一望できて、ちょっと救われた

識名宮

識名宮の鳥居
識名宮

ようやく識名宮に行き着いた時にはすでにヘトヘトだった。気温のために食べ切るよりも溶けるのがやや速かったブルーシールアイスでべっとべとだった手を水道(※手水舎と別)で洗わせてもらって本当に助かった。授与所のにこやかなお姉さんからひとつめの御朱印をいただいた。観光ですと雑談して、残りの神社を頑張って回ろうという決意を新たにした。そこからはタクシーが無事に拾えるようになってスムーズに回れるようになった。地理的な都合もあるだろうが参拝のおかげと思うことにした。

安里八幡宮

安里八幡宮の鳥居
安里八幡宮、住宅街の真ん中に鎮座されていた。

…が、授与所がたまたまお休みだった。そういうご縁もあるかと思い断念。参拝するのが大事なのでちゃんとお参りはした。

授与所がおやすみですの看板
そういうこともあるだろう

天久宮

鳥居の横の路地から入っていく形になっており、不思議な雰囲気のある神社だった。「あめくぐう」と読む。

路地の入り口とその横に立つ鳥居、奥には駐車場
鳥居があるのは駐車場で、お社は路地の奥にあった

授与所に神主さまがおられたので、数軒回ってお社に「米」「酒」と書かれた入れ物が置かれていたり、「拝みはこちらで」と言った貼り紙を見かけていたことについて尋ねてみた。快く説明してくださったところによると、沖縄での参拝方法で「拝み」と呼ぶものがあり、6マスに仕切られたお弁当箱のような道具にお米とお酒を入れて持ってきてお参りする、とのことだった。後から調べたところ、お弁当箱=瓶子(ビンシー)というものらしい。沖縄文化の一端を感じた。神主さま、ありがとうございました。

波上宮

噂の「ステーキヒカル」で腹ごしらえを済ませて(Rubyistが入れ替わり立ち替わりきていたようで凄かった。美味しかったです!)、「波上宮」(なみのうえぐう)に向かった。

大きな鳥居とお祭りの掲示
波上宮の入り口

ちょうどお祭り期間だったらしく、境内ではちびっこ相撲大会が行われていた。元気な子どもたちの様子に癒されつつ、水辺を見ておきたかったのと、崖上に建っているという様子の観察のためビーチに降りてみた。

波上宮のよく撮られているアングルの真逆からの眺め
これ多分逆方向から見た方が映えたな…。

透明度の高い海辺。海の青緑と白い砂浜とのグラデーションが素晴らしい。
めっちゃ綺麗だ…。

ビーチは遊泳している人もいたりして、わぁ、もう夏だな。と思った。沖縄にきたものの浜辺ウォッチチャンスはまったくなかったので、寄り道してよかった。泳げないが、水辺はとても好きだ。

沖宮

波上宮を辞して、またもやタクシーにて一路「沖宮」(おきのぐう)を目指した。

白い鳥居と奥に続く長い階段
「沖宮」入口

どうも空手と縁のある神社らしく、空手の心得が書いてある石碑があったりした。また、奥のほうに登っていくと様々な碑が安置されていたりした。階段がとても多く、ちょっとした山のようなところに建っているようだった。多種多様の「おみくじ」箱がずらっと20種類ほど陳列されており、どれをひこうかとても迷った。結局、一番オーソドックスなものを引いて末吉だった。御朱印自体も書いてもらう形式は今日は担当者の方がおられないので据え置きの紙のものを購入できたのだが、これまた20種類くらい貼り出されていた。結局一番どシンプルな御朱印でお願いした。他にもお守りやグッズ類もたくさん売られていて、ちょっと圧倒された。

ありがとうございました

本当は神社を見終わったら国際通りでもブラつこうか、と画策していたが、その余裕は無く空港に向かい帰路となった。神社巡りは僅かに残った体力を完全に使い果たす選択肢ではあったが、沖縄の風景・自然・文化の濃い部分に直に触れさせてもらったように思う。とても貴重な半日を過ごせて良かった。

頂戴した4つの御朱印の写真
ありがとうございました!

いやー、また行きたいな〜、沖縄。

RubyKaigi 2024 感想メモ

2024/05/15〜17 の3日間開催された RubyKaigi 2024 に参加した記録をつけます。

初のヘルパー参加

ヘルパー募集に応募し、今年はスタッフTシャツを着用しての参加となりました。ずっとトランシーバーをつけて、参加者のみなさんに「運営側」として声掛けしたり・されたり……、昨年までの RubyKaigi とは見える世界が全然違いました。これまでの参加ではスタッフのみなさんの大変な努力の上で楽しい体験をさせてもらっていたんだな、ということに改めて感謝すると共に、今年は自分がその楽しい RubyKaigi に微力ながら貢献できたということにとても満足感を覚えています。

メインの対応としては、自分はひたすら「かりゆしT持ってってください!」「島ぞうり持ってってください!」を言う & 在庫管理する係をさせてもらいました。公式ノベルティを持ち帰ってくださったみなさん、ありがとうございました!

また、自分の担当エリアの主采配は co_bachie さんが主導してくださいました。慌ただしさからしっかりとしたお礼はお伝えしそびれており…。困った時に的確に対処いただき、本当にありがとうございました!

これは通りすがりの emorima さんに撮っていただいた自分↑ ヘイ ラッシャイ

セッションメモ

ヘルパーのため、運営お手伝い > セッション聴講 という優先順位がどうしてもありましたが、スキマ時間でいくつか拝見できました。采配・調整してくださったスタッフのみなさま、ありがとうございました!

  • day2, 11:30- Finding Memory Leaks in the Ruby Ecosystem
    • Ruby 3.3から RUBY_FREE_AT_EXIT=1 が使えるようになる。ruby_memcheck によって色んなgemのメモリリークも発見されている。メモリリークでの問題は今のところ自分の利用範囲だとそんなに踏んだことは無いのですが、いざ出会ったときにはにっちもさっちも行かなくなる問題ですね。RUBY_FREE_AT_EXIT=1 、覚えておこうと思います。
  • day2, 17:20- Lightning Talks
    • 自分がアートの領域にすごく興味津々なこともあり、小芝さんの取り組みに憧れています! Processing そのものを学生の時分に触ったときも楽しかったですが、 Ruby で動かせるとさらに楽しさ倍増なのは間違いないですね。ライフゲームとか作ってみたいな。
      • (アート的な意味ではQuineもとても興味深いです…Day1の tompng さんのkeynoteを終盤だけチラッと拝見できましたが、正直なところ凄すぎて何もわかってないです。まずは小さいやつを読めるようになるところから始めなきゃ…。)
    • 金子さんのLTは3倍濃縮だったので、録画を1/3のスピードで改めて聴きたいです! 溢れる parse.y 愛を浴びさせていただきました…!
  • day3, 10:10- Ruby Committers and the World
    • やっぱりCommiterのみなさんが壇上に集まる様子は壮観ですね!
    • #frozen_string_literal: true 、長年書いている印象がありましたが、いよいよデフォルトになる日も近いですね…覚悟はしております。よっしゃ頑張るぞ。
    • 型について「(コメントとして書く分には)黙認する」という話題が出たり、どんな表記が良いかの会場アンケートがあったり、Ruby と型との関わりの今後の動きをより具体・身近に感じました。

たとえ一般参加だったとしても、どう足掻いても身体が3つないとセッション全制覇はできないですからね…。気になってたけど見れなかった分は、録画が公開されたら拝見しようと思います!

謝辞・お宿

女性の RubyKaigi 参加者たちが共同で宿泊する企画 emorihouse( https://emori.house/ )に今年も参加させていただきました! 今回は2棟のうちの「ヤダハウス」にお邪魔しました。自分はフィヨルドブートキャンプ(略してFBChttps://bootcamp.fjord.jp/ )のメンターとしても現在活動させていただいておりますが、FBCの女性受講生の方も同じ宿泊所だったので、ご一緒してお話しする機会がありました。Day1の夜更け、『エンジニアとして実際に働いている体験談・苦労話・面白話・etc』を複数人でつらつらとリビングソファ周りで駄弁るシーンがなんともエモい思い出になりました。FBCで実施しているPullRequest経由のコードレビューの場ではお伝えする機会が少ないウェットな話ができたし、FBCメンター以外のエンジニアと交流を持ってもらう機会としても、大変貴重なワンシーンだったように思います。

宿泊企画を主導いただいている emorima さん、ヤダハウス家主 yadaita さん、今回もお世話になりました! 出来るだけ新規参加の方に枠をお譲りしたいなという気持ち vs 自分が参加すると最高にたーのしー! という気持ちがせめぎ合っており、なかなか難しい心境ではありますが、うまく空き枠あればまたお邪魔したいです 🏠 引き続きよろしくお願いします!

謝辞・予算

今年は弊社(株式会社ARROWS https://arrowsinc.com/ )に交通費・宿泊費を負担してもらいました。弊社メンバーのみなさんも、こころよく自分を沖縄に送り出してくれ、とても感謝でした!会社で自分は Rails で動くサービスを運用保守しています。Ruby は年々進化しているので、自社サービスもそれにちゃんと追いついていけるようにしていきます。

直前のGWに、既に沖縄でちんすこうを買ってきてくれたメンバーがいたので、自分のお土産はシーサークッキーにしました。社内で議論が発生した結果、このお土産について「結局のところ、ちんすこうを形を変えて焼いたやつである」という結論に達しました。うーん、美味しいからオッケーってことで!

KaigiEffect

RubyKaigi 2023でも「英語がんばるぞ」と思い、この1年ほどアプリ「Duolingo」に取り組みました。しかし、今年ヘルパーとして参加してみて、英語での質疑応答が必要になるシーンでうまく聞き取れない、答えられない……というシーンがあり、今の取り組みでは全然足りんなぁ、と痛感しました。聞けたセッションでも、どうしてもスライドの文字情報に頼った理解に偏りがちで、勿体無かったなぁという気持ちがあります。最近は「スピーク」というAI相手の会話アプリも始めましたが、2〜3分の簡単なアクティビティだけで満足しがちです。そんな自分の学習の方針としては無理にでも長めの対話をする体験を1年の中にたくさんねじ込まねば、という結論に達しました。なので、脊髄反射的にDMM英会話に登録してみました。

2025年に松山に行くまでにどれくらい効果がでるのか、とりあえずやっていこうと思います 💪

BFSの勉強メモ

これの続き: DFSの勉強メモ - よもやま話β版

BFSとは

幅優先探索( Breadth-First Search )のこと。

BFSの例

BFSは A → B → C → D → E → F → G → H → I → J → K → L の順で探索する。 BFSは キューを利用し、最短経路を解くケースで使う。

BFSを使って問題を解く

まずはこれをやるといいよ、とオススメしていただいた問題を解いてみる。 https://atcoder.jp/contests/abc007/tasks/abc007_3

ものすごく丁寧に問題内に解き方が載っているので、ありがたく参考にしつつ書いたらACになった。 https://atcoder.jp/contests/abc007/submissions/49629732

今回の学び

  • キューの中身全部吐くまで回さないと意味がない
  • 先に埋まった手数より短い手数が後から探索されることがあるので、その時は上書きする

おまけ

abc007_3 をやる前と後に、abc317_e にトライしてみていたが、修正したことでACの数が増えた。

もっとカンタンなやつをたくさん解かないとどうしようもなさそうなのでこれくらいで…。

DFSの勉強メモ

競技プログラミングの勉強会にて、DFS について教えていただいたのでメモ。( Thanks for あのぶるさん( @thatblue_plus! お世話になっております🙏 )

グラフとは

そも、DFS というのは「グラフ」についての用語である。グラフというのは、ノード(点)とエッジ(線)で構成されている、よく見るこういうやつである。時々「木」のことを考えることがあるが、「木」とは「"連結"で"閉路"を持たないグラフ」のことを指す。

グラフの例

DFSとは

深さ優先探索( Depth-First Search )のこと。自分は木のほうがわかりやすいので、まず木で把握する。

DFSの例

DFSは A → B → E → F → J → K → G → C → D → H → L → I の順で探索する。 DFSは「大回りをしてどうなるか」等を見たい時に使い、再帰を利用するのが特徴。

DFSを使って問題を解く

改めて、以前参加して自力ではまったく歯が立たなかった https://atcoder.jp/contests/abc317/tasks/abc317_c がDFSで解けるとのことで、実装をやってみる。

好きな街からスタートして同じ街を二度以上通らずに別の街へ移動するときの、通る道路の長さの和としてありえる最大値を求めてください。

上記の説明より、まさに「大回りをしてどうなるか」を調べるということに該当するので、DFSが適当だと判断できる。再帰利用と「探索済み(seen)」を保持しておくのが肝要な様子、というのを念頭においてコードを書いたが、結果として全然ダメだった。

ACを出したものも、結局のところ過去にあのぶるさんにペアプロしてもらって書いたコード( https://atcoder.jp/contests/abc317/submissions/46458009 )をほぼ参考にしながら、なんとか書けたという状況となった。結果としてDFSを知っただけではダメだなということを痛感した…。DFSの再帰の中で何をするかというのが肝要。それはそう。

今回の学び

失敗した場合、どのように失敗しているのか、結果をちゃんとみた方がいい。 TLE が出てるということは仕組みはあってて速度の問題かなと思いこんでいたケースがあったが、改めて詳細をみたら「回答が出ない」というバグを抱えていた状態になっていたようだということに後から気づいた。AC7割、TLE3割という感じで、TLEは遅かったのではなく変なループにハマって答えに辿り着かなかったと考えたほうがよさそうだった。仕組みは合ってると思い込んでしまうと永久にTLEから逃れられないので、ちゃんと実行結果の一覧を見にいくようにする。

続き: BFSの勉強メモ - よもやま話β版