TechRAMEN 2025 Conference 参加レポート


2025/07/26(土)に旭川で開催された最高のイベントTechRAMEN 2025 Conferenceに参加しました。 特に琴線に触れたセッションについて振り返っていこうかと思います。

ちなみに昨日収集した公開済の発表資料一覧はこちら

多田さんとのSpring勉強会!

ということでまずは本祭でなく非公式前夜祭の【旭川7/25】多田さんとのSpring勉強会! #TechRamen25conf 非公式前夜祭について振り返っていきます。 このイベントでは、多田真敏さん(@suke_masa)による、Spring Framework関係の各種ライブラリの使い方の講義が行われました。

ハイレベルSpring Security -アーキテクチャ、カスタマイズ、コードリーディング-

私は今までそこそこ長い間なんちゃってJavaエンジニアとしてやってきました。当然、Spring Securityのような複雑なライブラリは雰囲気でやってます。 (適当にググったり公式ドキュメントを眺めたりしながらデファクトスタンダートっぽい実装がかろうじてできるだけのレベルで一生止まっています)

そんなJavaエンジニアはきっと大勢いるかと思いますが、そんな人にとって救世主となり得るセッションがこちらです。 このセッションでは、Spring Securityのアーキテクチャの全体像を、図とサンプルコードを見ながら学んでいくという内容になっていました。マーヴェラス。

また、セッションの中では、実装時の諸注意やコツが随所に散りばめられており、非常に学びになりました。例えば下記のようなトピックがあります。

フィルタークラス

Spring Securityの各種セキュリティ機能は、複数のサーブレットフィルタークラスで成り立っています。また、デフォルトのフィルターをそのまま使うだけでなく、自作のフィルタークラスを作って処理の合間に差し込むこともできます。 しかし、自作の処理を差し込むにあたり、セキュリティに関係ない処理を入れない方が良いというコツがあります。理由は、各種フィルターが順番に呼ばれて処理される中で、認証に失敗した場合にその自作の処理が呼ばれなくなってしまうためです。

発表資料

JJUGナイトセミナー ハイレベルSpring Security

余談

AuthenticationProviderの実装クラス多すぎワロタ

入門Spring Session

このセッションでは、

  • そもそもセッションって何?
  • セッションが抱える問題
    • 問題1:APサーバが複数台あって負荷分散する場合、セッションをメモリに保存していると管理できない
    • 問題2:アプリが止まったらセッションが消える
  • 解決策
  • Spring Sessionの使い方

という流れで話が進んでいきました。

まず話の構成が美しい。最初にセッションについての仕組みと、それが抱える問題について説明し、次に解決策について述べる。 そして最後に、その解決策を実現するためにSpring Sessionを使えば良いよ、という流れ。

セッションが抱える問題についての解決策についての説明も明快。以下のような内容でした。

  • スティッキーセッション(問題1は解決)
  • セッションをシリアライズ(問題2は解決)
  • セッションをシリアライズしてさらに外部ストレージに保存(1と2の両方が解決。ただしちょっとレスポンスは遅くなる)

発表資料

入門Spring Session

Springの地味に便利な新機能: JdbcClientとRestClient

JdbcClient

JdbcClientを使うと、Mapperクラス内にSQLがシンプルに書けるぞ!という話でした。私はMyBatis信者なのであまり使う機会は無いかもしれませんが、このクラスは知らなかったので学びになりました。

RestClient

HTTPクライアントの一種。ロジック内で外部のAPIにHTTPリクエストを投げてレスポンスを受け取るまでの一連の処理がスッキリ書ける。これはちょっと使ってみたい。

余談

最初にORマッパーの話が出た際に「理解しなきゃいけない技術が多すぎて、ORマッパーで悩んでるヒマなんて無い」という発言が飛び出したのが印象的でした。本当にそう。

発表資料

Springの地味に便利な新機能:JdbcClientとRestClient #javado

TechRAMEN 本祭

実機を触って繋ぐ、ネットワークの一歩目体験会

現物のCiscoのルーターにSSHでアクセスしてVLANを構成したりして、ネットワークの仕組みについて学んでいくワークショップに参加しました。 (ルーターは講師のみゆ吉(@miyukichiOSPF)さんの私物だそうです。頑張って値切って買ったとか。すごい)

ルーターの設定、GUIでなんとなくいじったことぐらいはありましたが、SSHで繋いで各種設定をすべてコマンドで行うというのは初めてだったのでとても新鮮だった。何ならちょっとルーター欲しくなった。

このワークショップの参加者は、私を含めて4人でしたが、皆爆速でトラブルなく演習を進めており、講師の想定より早く終わったのが面白かったです。 そしてそのおかげで、本来出す予定じゃなかった追加コンテンツが大量にデプロイされてきたのが最高でした。

(あと私は、直前に聞いていたセッションが機材トラブルで終了時間がずれた影響で、1分ぐらい遅刻しました。すみません。結果なんとかなって良かった)

入門 灼熱エンジニアリング

米内貴志さん(@lmt_swallow)によるキーノート。エンジニアが灼熱状態になるための話。

灼熱状態とは

「内的動機と外的期待が均衡しており、かつ取り組みの利益率が正の状態」だそうです。 私は何となく「プロダクトポートフォリオマネジメントの花形」みたいなものだと解釈しました。 「自分がやりたいこと」と「周りから自分に対して求められていること」が合致しており、やればやるほど良い成果を出し続けられる状態のこと。

呪い

人は生きていると以下のような呪いにかかることがある。

  1. 有意義なものを作らないといけないと思うようになる
  2. 勝ち負けを気にしすぎる。負けたくない欲求が生まれる

この呪い、どうにかして解かないとずっと苦しみ続けることになる。それはまぁ嫌だよね。以下の考え方で解きましょう。

呪い1の解呪法

まずは有意義じゃなくてもいいから作りたいものを作ればいいい

呪い2の解呪法

勝ち負けとか別に無いしどうでもいいから作りたいものを作ればいい

呪いを乗り越えた先に

とにかく思うがままに作り続けて、それが評価され始めたタイミングで、外的要因に答えることを意識し始めると良い。そうすることでいずれ灼熱状態に入れる。

感想

私は逆に「有意義じゃないものの方が好き」という呪いにかかっているので、今のところ今回の話で挙がった呪いにはかかっていない。 が、いつか裏返ってこっちの呪いが発症したときのために、「まずは作りたいものを作れば良い」という考え方は心に刻んでおく。

余談

GMOに良いニックネームがついていた

プロダクトという一杯を作る - プロダクトチームが味の責任を持つまでの煮込み奮闘記

幡ヶ谷亭直吉(@asagayanaoki)さんのセッション。タイトルがちょっとラーメンに寄せられてて良い。

内容はかなり硬派で、この方がプロジェクトマネージャーとして奮闘しながらプロジェクトを成功まで導くという話でした。 途中でトラブルが起きて遅延した時に、総合テストの推進や品質分析など、大きなコンテキストが必要な作業を自らが引き受けてなんとかした、というくだりにとても共感した。わかる。 なんだかんだトップが直接手を動かすのが(最善かどうかは置いといて)結局早い。

No Install CMS戦略 〜 5年先を見据えたフロントエンド開発を考える

榊原昌彦(@rdlabo)さんのセッション。 CMSのメンテナンスって大変なので、メンテの一部をユーザーが自分でできるような環境を作るとか、そもそもCMSを使うのをやめるとか、そういった対策をしよう、という話でした。 話の前半で、

  • DBのバックアップがとれてなかった
  • アクセスが集中してサイトが表示されない
  • ユーザーに自分でメンテしてもらったら壊れた とか、運用保守で起きがちなトラブルが色々出てきたのが面白かった。わかる。

MCPサーバー開発はプログラミング入門にうってつけ!

白雀(@azurdiary)さんのセッション。

MCPは以下のような要素があるのでプログラミング入門に最適!という話。

  • 成果物の実用性が高い
  • 実装のハードルが低い
  • 登場してから日が浅い概念なので、今やっておけばアドバンテージが取れる
  • 需要がある

確かにその通り。私もMCPサーバー作ろうかと思いました。

AI時代の技術の楽しみ(方)・学び(方)

ワークショップその2。きんじょうひでき(@o0h_)さん主催。 AIについて語りたいことを周りの参加者とざっくばらんに語り合おう、というワークショップでした。

私は「新入社員向けの研修をやる際、生成AIの利用を許可すべきか否か」というトピックを放り込んで色々な意見交換をしました。 最初は生成AIの使用を禁止する、AIエージェントを使っても良いことにする、などやり方は多種多様でしたが、「生成AIは使いこなせるようになってもらわないといけない」というところだけは共通認識として持っている、ということがわかったのが大きな収穫でした。

おまけ

旭川の買物公園の看板が絶妙にゆるくて良いんですよね。こういうの。

買物公園の看板

ということで、帰りの車内で勢い余ってジェネレータを作りました。 ご査収ください。こんな画像が作れます。

生成した看板

買物公園の看板ジェネレーター

皆さんわかりますか?これが「有意義じゃなくても作りたいものを作る」ってことだぞ!!どうだまいったか!!