Kaigi on Rails 2025に参加しました！
9/26(金)、9/27(土)にKaigi on Rails 2025に参加してきましたー！
今回の会場はJPタワーホール＆カンファレンスでした。東京駅丸の内南口から徒歩1分というとてもアクセスが良い場所でした！
事前準備
これまでKaigi on Rails 2023, 2024に参加してきたのですが、事前準備は特にしていませんでした。今年のRubyKaigi 2025の参加前にたくさん準備をしたことによって、初参加でしたが技術的な内容も楽しむことができました。
その経験がきっかけとなり、「Kaigi on Railsも事前準備をした方がもっと楽しめるんじゃないかな？」と思って参加前に以下のことをしました。
- 所属しているコミュニティ(Fjord Boot Camp)内でイベントを共同主催した
- connpass上の事前イベント2つに参加した
- 見たいセッションを決めて、分からない単語を軽く調べた
このおかげで、セッションで話される内容について少し知識がある状態でお話を聞けたので今までよりはセッション内容が理解できてより楽しめたように思います。
特に印象に残ったセッション
Railsアプリケーション開発者のためのブックガイド
タイトルの通りRailsアプリケーション開発者向けの本紹介のお話でした。紹介された本の分野が膨大で、「これらの本を全て読まれているのか...」とびっくりしました。
本の紹介の前に冒頭でRailsでサービスを作るときに必要なもの、現代でも書籍を読む理由についてお話をされていた内容が印象に残りました。
- Railsでサービスを作るには、ソフトウェア、チーム、文化を作る必要がある
- ここでの文化とは、個々人を超えたチームで良いアプリを開発し続けるための知識や習慣のこと
- チームメンバーはずっと固定ではないので文化が必要になる
- 不明な箇所について過去のチームメンバーに聞くことはできない
- 未来のメンバーとも会話はできない
- 書籍は「みんなが同じものを読める」というメリットがある
- 情報の鮮度が不要、あまり知らない領域について学ぶ時に書籍が有用
「事前のおことわり」で「文章が読める速度を超えてページをめくることがある」と書かれていたのですが、本当に読めないスピードでスライドが進んでいました！
これだけの量の本を読んで、紹介までできるのが凄すぎます。
セッションには関係ないことですが、スライド作りの際にいつも高橋メソッドを使っているので、ご本人の登壇が見れたのが嬉しかったです
2分台で1500examples完走！爆速CIを支える環境構築術
並列処理によりRSpecの実行速度を早くする方法についての話でした。
- parallel_tests gemを使ってテストを並列実行
- 論理DBに分けて複数プロセスによりテストが実行されるけど、バラツキが発生するため一番遅いプロセスに律速されてしまう
- Knapsack Proを使うことで最適な分割をしてもらう
- EC2のEBSのデフォルトは3,000IOPSなのでDB書き込みでIOが飽和する
- IOPS(Input/Output Per Second): 1秒間にできる読み書き回数
- メモリ上にファイルシステムを構築できるtmpfs
最後に、ハイスペックな物理マシンにしてCIが爆速になったのがめちゃくちゃ面白かったです！ つよつよ物理マシンを組み立てて爆速でテストを終わらすのにロマンを感じました😃
今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
Serviceクラスについて、いつからどのように使われたのか、joker1007さんがどのように考えていたか、今はどう考えているかをお話されていました。
- 『エリック・エヴァンスのドメイン駆動設計』の影響を少なからず受けて、サービスクラスという名前が使われ始めた
- Fat Modelが問題になってきていた
- 『パーフェクトRuby on Rails』では、サービスクラスの利用時には適切な命名が必要と説明していた
- 乱用は危険とも書いていた
- 乱用についての度合いが人によって違う
- Fat Modelに対応するための折衷案としてのFormクラス
- ただし、サービスクラス同様ActiveRecordをうまく整理しないといけない
- RDBと向き合うことが大事
- 重要なのはドメインコンテキストの理解
DDDについてほとんど知らないためお話しされていた内容自体の理解度は低いと思うのですが、自分の理解では「まずドメインについて理解して、同じ文脈で話せるサブセットに分割してそれぞれの依存関係を整理したうえで、社内で役割が違う人でも通じるような命名を行う。そのうえで、そのドメインを自然に表現できるようなRDBの設計を行う。」ということかなと思いました。
一言に要約すると「ドメインの整理ができてない状態でServiceクラスを使うな」ってことかなと思いました。
最後のページに書かれていた「正解は無い、一緒に考え続けましょう」「ソフトウェア設計は継続的な営み」という言葉が印象に残りました！
さいごに
今年で3回目のKaigi on Rails参加になったのですが、過去一いろんな方とお話ができてとても充実した2日間になりました！
イベントを通じて技術の話で盛り上がったり、その話がきっかけとなり関連イベントを立ち上げることになるというKaigiEffectもありました。
去年は参加できなかったKaigi on Rails事後勉強会にも参加する予定なので、楽しみですー！
今年のKaigi on Railsも最高のカンファレンスでした！運営の皆様やお話していただいた方々ありがとうございましたー！！
関西Ruby会議08に参加しましたー！
6/28(土)に京都で開催された関西Ruby会議08に参加してきました！
今回は先斗町歌舞練場という会場でした！とても趣があって京都らしい素敵な会場でしたー。
今回のカンファレンスは8年前の関西Ruby会議2017以来の開催みたいです🎉
自分にとっては初めての地域Ruby会議の参加が去年の大阪Ruby会議04だったので、同じ関西で開催される今カンファレンスもとても楽しみにしていました！
このカンファレンスは「Rubyとつくる」というテーマだったため、個人開発の話も多くて、これから個人開発を始めたいと思っていたのでとても参考になりました。
特に印象に残ったセッション
「1ヶ月でWebサービスを作る会」で出会った rails new、そして今に至る rails new
いろいろイベントに参加されて、個人開発からエンジニアになられたという話がとても素敵でした。
趣味のポッドキャストに関したアプリを自作されようと思ったのがすごい。趣味に関するアプリだとモチベーション高く開発できそうで良さそうです。
ChatGPTと協力して要件を整理されたり、アプリを作る過程も発表していただいたので、自分もアプリを自作する際にとても参考になる内容でした。
サービスをローンチするにあたって、「小さく作って出す」「様子を実況する」「自分が最初のユーザーであること」は自分も真似をしようと思いました。FBCというオンラインスクールに通っていて、卒業前に自作アプリを作成するのでその際に意識するととても良さそうだと思いました。
このトークの狙い通り、セッションが終わった後は自分も「自作ブログアプリを作るぞ！」という気持ちになりました。
ふだんのWEB技術スタックだけでアート作品を作ってみる
Creative Codingという言葉は知っていたのですが、幾何学模様を出力するイメージが強かったため、今回のような動きのあるものがあるということが衝撃的でした。
時間とともに長針短針が動く小さなアナログ時計の様なものが並べられていて、それらの時計が集合としてデジタル時計として時刻を表示するという発想がとても面白かったです！
Creative Coding系の発表を今まで聴く機会がなかったため、今回の発表はとても刺激的でした。
Rubyを使った10年の個人開発でやってきたこと
タイトルの時点で「10年も個人開発をされているのすごい」と思っていました。
Annictという観たアニメの情報を記録できるアプリの話をされていました。以前から情報の記録はされていたようなので、やはり自分の欲しい機能を持つサービスを作成されているので個人開発を続けられているのかなと思いました。
Wikinoというアプリについては、自分もMarkdownで記載できるCosenseのようなアプリがあったらいいなと思っていたので、その問題を解決するためにアプリを作成されているのがすごいなと思いました。
個人開発をして得たこととして話されていたのが、「自分が欲しいものを作る」「続けるために無理をしない」「技術的な実験ができる」だったので、自分もこれらのことを大切にしながら自作アプリを作っていこうと思いました。
さいごに
クロージングでのydahさんによる関西Ruby会議に対する熱い思いが伝わってきてとても感動しました。
自分も去年の大阪Ruby会議04で初の地域Ruby会議に参加して、すごく刺激を受けてRubyコミュニティの良さを実感したので、今年の関西Ruby会議にも参加できて本当に良かったです！
来年は滋賀で開催される予定みたいなので、とても楽しみにしています！
懇親会でもいろんな方とお話できてとても楽しかったです。懇親会がきっかけで新たなつながりもでき、最高の思い出となりました！
運営の方々、本当にありがとうございましたー！
TokyoWomen.rb #1に参加しました！
3/1(土)に開催されたTokyoWomen.rb #1に参加してきました。
会場は六本木グランドタワー8階のSmartHR Spaceでした。
オープニングで説明があったのですが、元々はTokyoGirls.rbという名前のイベントだったものをTokyoWomen.rbに変更してリブートされたみたいです。
名前にWomenと入っていますが、登壇者が女性限定になっているだけで参加については男性でも大丈夫でした。
印象に残ったセッション
Ruby でつくる CLI 横スクロールアクションゲーム〜Road to RubyKaigi〜
すごく楽しみにしていたセッションの1つでした！
「バグを倒して締め切りから逃れてRubyKaigi参加を目指す」というコンセプトが面白かったです。
端末ゲームプログラミングの要素としてアニメーション、入力、ゲームループがあるということを知りました。
入力には2種類あり、改行した時に入力文字を送信する「Cookedモード」と、入力文字列を入力直後に送信する「Rawモード」があるということを知りました。
普段は全然モードのことを意識していなかったのですが、プログラミングでTerminalを使う時はCookedモードを使ってコマンド実行をしていたということに気づきました。
実践編ではレイヤー合成と、物理シミュレーションのお話がありました。
物理シミュレーションの話に一番興味を惹かれ、自分でも実装してみたいなと思いました😃
コードもGitHubに上げられているので、参考にさせていただきたいと思います。
この発表を聞いて、Chromeブラウザでできるchrome://dino/のようなランゲームをCLIで作ってみたくなりましたー！
推しメソッドsource_locationのしくみを探る - はじめてRubyのコードを読んでみた
Method#source_locationについてのお話でした。
僕は、最近Rails のコードを読むという本を読んでいて、このメソッドについて知りました。
nobu09さんのセッションでは、このメソッドの便利ポイントとして「どこで定義されたか分かりにくい動的に定義されたメソッドやgemのメソッドの定義もすぐ特定できる」と説明されていて、「なるほど！！」と思いました。
動的に定義されたメソッドは文字列検索をかけても結果にひっかからないし、RubyMineの定義元にジャンプする機能も使えないしで、結構困っていました。使いどころまで説明してくださっていて、ありがたいです。
GitHub上のRubyリポジトリをクローンして、ChatGPTやGitHub Copilotを使って質問をしながらC言語で書かれたsource_locationの理解をしていく説明がとても参考になりました。
methodメソッドはKernelモジュールに定義されているのですべてのオブジェクトで利用できるようですが、C言語ではMethodだけではなくProc, UnboundMethod, Bindingクラスにも定義があるというのが面白かったです。
Rubyのコードは一度ISeq(命令シーケンス)に変換されてから、Ruby VMで解釈・実行されるみたいですが、この辺りで自分のキャパを超えて理解できなくなってしまいましたw
nobu09さんのセッションを聞いて、まずはsource_locationを使いこなせるようになったり、Rubyのクラスについて勉強する意欲が出てきました！
たのしいSocketのしくみ / Socket Under a Microscope
このセッションを聞く前に、先月2/1(土)にフィヨルドブートキャンプ内で開かれたワークショップ『Rackを理解するための技術ハンズオンワークショップ』に参加してRackについて学びました。
そのワークショップ内でRackサーバを実装する際にSocketライブラリを使ったのですが、そのことがきっかけで自分がサーバーやネットワーク技術に興味を持っていることに気づき始めました。
なので今回の塩井さんのお話をめっちゃ楽しみにしていました！
サーバプログラムとクライアントプログラムをどちらもRubyで実装して実行するデモを見て、テンションが上がりました😃
セッションを聞いている際はSocketについての雰囲気を知れたくらいなので、登壇資料を読みながら自分でも手を動かして理解を深めたいと思いました。
Rails 1.0のコードで学ぶfind_by_*とmethod_missingの仕組み
maimuさんが開催されているしんめ.rbで行った、Rails 1.0のコードリーディングで面白いと感じた部分(find_by_*とmethod_missing)、面白いと感じた理由についての発表でした。
今のRailsのActiveRecordだとfind, find_by, whereが使えますが、Rails 1.0はすべてfindで表現されているというのが面白かったです。
findだけで表すのは大変なので、今でいうfind_byの機能を使いたい場合はfind_by_attr1_and_attr2のように書ける。
これはメソッド定義されていないので、 method_missingで実装されているということでした。
面白いと感じた理由を「今は当たり前にあるメソッドがなかった当時特有の背景」「仕事では使われないmethod_missingを使った実装」「find_by_*は今もあるけど実装方法が違う。Railsの変遷」のようにしっかり、言語化されているのが素敵だなと思いました！
実は自分もちょうどこのRails 1.0コードリーディングの勉強会に参加させていただき、Railsのコードリーディング自体も初めてだったのですが、とても楽しかった記憶があります😃
一人だと絶対読めなかったのですが、maimuさんや他の参加者の方々と一緒に読んで雰囲気だけでも理解できたのがすごく嬉しかったです。
今回のセッションでは、どこが、なぜ面白かったのか分かりやすく言語化されていて、参考にさせていただきました。
基調講演: Rubyと自由とAIと
Rubyはよく自由度が高い言語と言われていて、この文脈での自由は「技術的な自由」を表わしている。
もう1つの自由として「社会的な自由」があり、こちらは「技術的な自由」に誰でもアクセスできる自由のこと。
とても印象に残ったのが、「Rubyは本質的に「自由」を求める。ゆえにRubyコミュニティは社会的な自由も実装しようとする」という言葉でした。
自分が感じていたRubyコミュニティの居心地の良さが、自分がRubyコミュニティを好きな理由が「Rubyコミュニティは社会的な自由も実装しようとする」という言葉で表され、すっきりしました。
あまり他のコミュニティに参加したこと無いのですが、Rubyコミュニティは比較的女性の割合が多いと聞いていて、そういう意味では「社会的な自由」度も比較的高いと思っていたのですが、 むしろTokyoWomen.rbのように「社会的な自由も実装しようとする」姿勢のおかげで比較的に社会的な自由度が高くなっているんじゃないかなと思いました。
まだ自分の中で言語化し切れていないのですが、「技術的な自由」と「社会的な自由」の関連性のお話はとてもおもしろくて、「社会的な自由」に関しては、自分が気になっている言葉「無名の質」に似た考え方のように感じました。
さいごに
今回のTokyoWomen.rb #1に参加申込みをする時、まだ男性の参加登録者が少なくて、少し躊躇しました。
他のイベントではあまり男女比やそもそも参加者の性別を意識したことがなかったのですが、それは男性が多いコミュニティに慣れていたからかもしれないということに気づきました。
そういった意味で、TokyoWomen.rbのようなイベントを通じて今まで参加しづらかった女性がRubyコミュニティやカンファレンスに参加しやすくなるのはとても良いことだと思います。
今回のイベントではしくみを知るためのセッションが3つもあり、とても面白かったです！
改めて、コードが動く仕組みを知ることが好きということや、サーバーやネットワーク関連の技術が好きだという気づきがありました。
また、去年の夏頃からいろんなRuby系イベントに参加するようになって、最近はLT登壇もしたいと考え始めているため、皆さんの発表内容をすごく参考にさせていただきました。
懇親会でも色んな人と話したことで多くの気付きが得られたり、久しぶりに話せた人もいてとても楽しかったです。
運営、スポンサー、参加者の皆様ありがとうございましたー🙌
自作キーボード沼にハマっている話
この記事はフィヨルドブートキャンプ Part 1 Advent Calendar 2024
の22日目の記事です。Part2もあります。
昨日はYuukagoさんの初めてオフラインイベントを主催した話【フィヨブーボドゲ会2024】でした！
はじめに
自分はキーボードが好きで、理想のキーボードを探しています。
その中でも自作キーボードは自由度が高いので、より理想的なキーボードが見つかりやすいと思います。
今回は自作キーボードの面白い部分を伝えたくて記事を書きました！
自作キーボードを始めたきっかけ
もともと、Ducky One 3 Miniというキーボードを愛用していました。
- 60%サイズのコンパクトなキーボードなのでマウスまでの距離が近くなって取り扱いやすい
- US配列なのでEnterキーが横長になっていて、ホームポジションを崩さず改行できる
- メカニカルキーボードなので、キースイッチ、キーキャップが自由に変更できる
このキーボードもすごく気に入っていたのですが、社内で自作キーボードを使っていた人から勧められたことがきっかけで自作キーボードについて調べ始めました！
ここから深い沼にハマるという事も知らずに...。
自作キーボードの良さ
自作キーボードについて調べていく内に、既成品のキーボードにはない魅力に惹かれました。
ここでは自分が感じた魅力を2点紹介します。
デザインの選択肢が豊富
キーボードデザインやキー配列のバリエーションが多いのが1つの魅力だと思います。
たとえば、以下のような特徴を持つ自作キーボードがあります。
- キーボードにトラックボールが一体化されている
- マウスが不要になる
- 一般的なキーボードはロースタッガード(row staggered)が多いのに対して、カラムスタッガード(column staggered)なキーボードもある
- キーボードに指を置く際に、自然な形で置ける
- 親指を活用できるキー配列がある
- 親指の使用率を上げることで、他の指の負担を減らせる
愛着が持てる
半田付けしたり、スイッチやキーキャップ、ケースを自分で組み立てるので完成させると達成感があり、すごく愛着が湧きます！
キーボードがどういう部品で構成されているかを知るきっかけにもなりました。
あとは、キースイッチ、キーキャップ、その他備品を自分で選択するので、組み合わせ的に他の人とかぶることはほぼ無いので、オリジナルのキーボードになるのも嬉しいです😊
自作キーボードの始め方
自作キーボードは種類がとても多いので、初めて調べ始めた時は何を基準に選べば良いのか分からず困っていました。
考えるポイントを決めれば選びやすかったかなと思ったので、自分が決めた時のポイントについて書きます。
好きなデザインを見つける
- 左右分割したいか
左右分割キーボードの利点としては、キーボードの位置を肩幅に合わせられるので肩が凝りにくいと言われています。
個人的には左右分割の方が見た目が好きです。少し気になる点としてはマウスを置く位置と被ってしまうので、マウスが若干扱いにくくなることです。
- 物理キーの数
大きく100%, 60%, 40%サイズのキー配列があります。
60%サイズは最初に画像を貼ったDuckyと同じようなサイズで、ファンクションキー、テンキー等がないため代わりにFnキー+他キーを押して無いキーを補うことになります。
40%サイズはそこからさらに数字キー列と記号キーと修飾キーを削ったものです。40%くらいになるとそのままではキー数が足りないので特定のキーをレイヤーキーとして割り当てて、そのキーを押しながら他のキーを押すと記号が入力できる、というような設定が必要になります。
~%というのはあくまで目安なので同じ%でもキーの数が違います。
- 見た目
自作キーボードは本当に多種多様で、同じ左右分離でキーサイズが同じくらいのものでも見た目が違うというところが面白いところだと思っています。
毎日触るものだと思うので、最終的には見た目が気に入ったものを選ぶというのも良いんじゃないかなーと思います。
実際に触ってみる
自作キーボードは本当にいろんな種類があるので、実際に触ってみたほうが自分にしっくりくるものを決めやすいかもしれないです。
いくつか自作キーボードを触れる場所、イベントを紹介します。
- イベント
- 店舗
自分の場合は欲しい自作キーボードのあたりを付けた後、遊舎工房に触りに行って決めました。
本体以外のパーツをそろえる
自作キーボードは本体だけではなく、キースイッチ、キーキャップ、左右分割タイプの場合は左右をつなぐためのTRRSケーブル(3.5mm, 4極)を揃える必要があります。
この辺りは初めからこだわりすぎると大変なので、ざっくりと書きます。
- キースイッチ
大きく分けると、「Cherry MX 互換スイッチ」というよく使われているものと、「ロープロファイル」と呼ばれる薄型のものがあります。
これはキーボード本体がどちらに対応しているかによって決まります。
選ぶポイントは、押した時の感触の違い(リニア、タクタイル、クリッキー)と、押すのに必要な力(45g, 55gなど)の2点です。
よく使われているのはリニアの45gで通称「赤軸」と呼ばれているものです。
分かりやすい記事がいくつかあったので、リンクを貼っておきます。
shop.yushakobo.jp archisite.co.jp
- キーキャップ
基本的に見た目が好きなものを選ぶのですが、自作キーボードのキーは特殊キー(文字、記号、数字キー以外のキー)も文字キー等と同じサイズのことが多いため、
キーキャップを買う時はその点に注意しないといけないです。
あとは、アルチザンキーキャップというものがあり、これは普通のキーキャップとは違い装飾されたものです。キーがゲーム機になっていたり、顔文字になっていたり、他にもいろいろあって面白いので調べて見てください😆
組み立てる
ここまで来ればあとは組み立てるだけです！
具体的な組み立て方は自作キーボード本体によって違うので割愛します。
自作キーボード本体に説明書が付属していたり、オンライン上にビルドガイドがあるので、ガイド通りに組み立てることになります。
半田付けなど、ガイドに書かれている説明文と画像だけで分かりづらい場合はYoutube上で組み立て動画があったりするので、そちらを参考にするのも良いと思います。
遊舎工房には工作室も用意されていて、そこで工具をレンタルできたり半田付け講習サービスもあるのでおすすめです。初めて自作キーボードの半田付けした際にミスをして自分で解決できなくなった時に相談させていただいて、お世話になりました🙏
今使っている自作キーボード
最近買った自作キーボードと選んだポイントについて紹介します。
Corne V4 Cherryというキーボードです。
選んだポイント
- 左右分割タイプ、左右対称
- 左右分割なのは見た目が好みだからです
- 一般的なキーボードの場合、特に右小指で押すキーの数が15キー程あり、一番自在に動かせない指に一番多くの負担がかかっているのが不満でした。左右対称を選んだのはなのはできるだけ各指の負担を均等にしたかったからです
- キー数
- 46キーあります。この内、10キーは使わないようにして36キーを使うようにしています。これはホームポジションから1キー分だけ指を動かすだけでどのキーも押せるようにしたかったからです
- PRK Firmwareに対応している
おわりに
自作キーボードのことについていろいろ書いたのですが、実はまだコーディングの際には自作キーボードを使えていないです😅
36キーしか使っていないので、論理キー配列を調整する必要があるのですが、なかなか良い配列が見つからず調整し続けています。
キースイッチ、キーキャップ、論理配列などなど、まだまだこだわりたい部分が多くあるので、これからも理想のキーボード探しを続けようと思っています💪💪
一緒に自作キーボードを楽しめる仲間が増えれば嬉しいので、この記事を読んで少しでも興味を持っていただけたら幸いです😃
明日はkomagataさんのマクロパッドの活用についての記事です！
VimConf 2024に参加しましたー
11/23(土)に開催されたVimConf 2024に参加してきました！ vimconf.org
会場はアキバプラザ・アキバホールでした。秋葉原駅から近かったので、他のカンファレンスに行く時にいつも迷うのですが今回は迷うことなく到着できました！
ホールに入ってから名札をいただいたのですが、名札に自分のアイコンが付いていたのが印象的でした。「ネット上でのアイコンと名前は分かるけど、リアルで会うと誰か分からない！」が解消されそう。
Vim歴が半年くらいなのと、VimConf初参加なのでドキドキしていましたが、結果的に大いに楽しむことができました！
印象に残ったセッション
全てのセッションが面白かったのですが、技術的に理解できなかった部分も多かったので特に印象に残ったセッションについて記録を残そうと思います。
Keynote - The new Vim project - What has changed after Bram
Christian Brabandtさんの発表。Vimコミュニティの話しでした。Vim作者のBramさんがこれまでどういった活動をされていたのか、亡くなられた後どんな活動をしているのか、これからどうしたいのかという話しをされていました。
コミュニティ活動を続けるということはコードを書く以外にもしないといけないことが多くあり、その内の多くをBramさんがされていたということに驚きました。
お話の中で何度も「Vimコミュニティを健全に保つことを一番考えている」という言葉があり、強調されていたことが印象的でした。
Keynote - (Neo)Vim Made Me a Better Software Developer
TJ DeVriesさんの発表。kickstart.nvimの設定でNeovimを使い始めて、Youtubeで説明動画を観ていたこともあり、唯一知っている方でした。
Better Software Developerについてのお話でした。その中でも印象的だったのは、playgroundを探して手を動かすことが大切、playgroundがあることでアイデアを試すことができるし、閃きが得られるということでした。
TJさんにとってはNeovimがplaygroundということでした。
自分が何かに熱中する時はいつも、いろいろ試行錯誤して自分なりにより良い方法を見つけることだったと思いました。このplaygroundという考え方はとてもしっくりきましたし、分かりやすいお話と例えで言語化してくださったので自分の中での気づきが多かったので印象に残りました。
途中で小さな声で「playgroundはEmacsでもいいんですよ」という感じのジョークを言ってたのが面白かった。
Lunch break
セッションではないですが、お昼ご飯も思い出に残るものだったので。
vim-jp内でVimConfで出るご飯が美味しいということは聞いていたのですが、予想よりもさらに美味しかったので思い出に残りました！
お弁当は多めに用意されていたようで、おかわりをいただきました。弁当とは思えないほどの肉の旨さ！しいたけも味がしっかり染み込んでいて最高でした。
Building Neovim Plugins: A Journey from Novice to Pro
2KAbhishekさんの発表。Neovimのプラグインを作るうえでの前提知識として、アイデア、実用的なLuaの知識、Lazy.nvim、プラグインテンプレートの準備が必要。
プラグインを作成するにあたっての基礎的なところから、そこから応用的なプラグインをつくるまでの道のりを示してくださっていました。
自分はまだNeovimをより良く使うために精一杯ですが、慣れてきたらプラグインの作成もしたいと思いました。
あと、Tips for Plugin Authorsとしていくつか紹介されていたのですが中でも印象的だったのが
- 自分の欲しい機能を作って最初のユーザーになる
- User Configurationを尊重する
- 楽しむ！(一番重要)
でした。自分の欲しい機能を作ることでモチベーション高く続けられそうだし、User Configurationを尊重することはVimmerらしいと思いました。
最後の「楽しむ」はTJさんのplaygroundの話しと通じるところがあると思います。
さいごに
初めてVimConfに参加してみて、ブログには書ききれないくらいの良い思い出が残りました。
周りにVimを使っている人がほとんどいないのもあり、Vimmerというと尖った人が多い印象を若干持っていたので実は参加前に少し不安になっていた時がありました。
参加前にvim-jpに入って、皆さんに暖かく皆さんが迎えてくださったおかげで参加のハードルが下がりました、ありがとうございます。
そして、懇親会で話してくださった皆さん、素敵なカンファレンスを開催してくださった運営の皆さん、本当にありがとうございました！
来年も参加したいと思える最高のカンファレンスでした！
Kaigi on Rails 2024に参加してきました！
ブログ書くのがかなり遅くなってしまったーーー！時間が経ちすぎてしまったのですが、思い出として残しておきたかったので書きます。
10/25(金)、10/26(土)に開催されたKaigi on Rails 2024に参加してきましたー！
去年に続き2回目の参加になります。今年の会場は有明セントラルタワーホールでした。
特に印象に残ったセッション
本当はもっと書きたいセッションがあったのですが、時間が経ちすぎて書ききれないと思ったので今回は3つだけ...。
RAILS WAY, OR THE HIGHWAY
アプリケーションが大きくなるとMVCだけでは足りなくなる。そこでRails Wayから離れる実装をしてしまうと、怪獣 on Railsになってしまう。
Rails Wayはそうならないための導きの星になってくれる。
MVCから拡張する際に、Rails Wayに従いつつMVCの隙間を埋めるためには『Layered Design for Ruby on Rails Applications』がガイドになるみたいです。
この本は積読しているので、次に読むRails本にしたいと思います！
MVCからRailsを拡張する際の考え方として、関心事を分離して各ユニットをプロセスの一部に集中させる。
抽象化レイヤーを分離するためにレイヤードアーキテクチャの原則を参照する、という説明がありましたが、自分の理解度を超えてしまったのでここは今後勉強していきたいです。
Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -
サービス層を入れるのはできるだけやめる、ということを強調されていました。
自分でも以前よりサービス層について、テストがしにくかったり、似たような処理が散らばっていることを課題に感じていたのでとても参考になりました。
イベント型モデルを見つけることが重要で、名詞であるモデル名に「〜する」をつけて自然なものがイベント型モデルになる。
イベント型モデルを作成することで、複数モデルにまたがっていた処理をそのモデルに記述ができる。
PORO、フォームオブジェクトの導入についての説明もありましたが、いまいち自分の中に落とし込めていないのですが使えるようになると便利そうなので、アーカイブ動画が公開され次第もう一度セッションを観て理解を深めたいです。
WHOLENESS, REPAIRING, AND TO HAVE FUN
島田さんのセッションの中で、一番印象的だったのが後半のオプションのお話でした。
設計初期段階で不確実性が高い中で、何にでも対応できるような構造や仕組みを作るのはむしろ選択肢を狭めている、どの方向にも進めるようシンプルに作る、という言葉が印象に残っています。
シンプルに作るというのは「標準の道具、標準の方法で、必要十分に作る」ということで、「Railsはオプションのための設計をサポートしてくれるフレームワーク」ということに納得しました。
ここで、シンプルに作るためにはRailsをマスターすることが大事という話しになり、Palkanさんの「RAILS WAY, OR THE HIGHWAY」の話とつながってきたところが面白かったです。
あと、システムが成長すると部分的にシステム全体的に合わなくなってくる箇所が出る(これがボトルネックと呼ばれる箇所?)ので、それを修復し続けることで変化に適応するという考え方が勉強になりました。修復というと、マイナスを0にする作業のようなイメージでしたが創造的なイメージを持てました。
そこで修復が必要な箇所に気づくことが重要になるのですが、「複雑なシステムを直感的に理解する」Process Feelが大事というお話になり、認知負荷の低減が大事だということを学びました。
ここで、Kaigi on Railsの多くのセッションの話しがまとめられたような感覚があり、とても感動したことを覚えています！
学んだことを自分なりにまとめました。
システムコンポーネントを詳しく知ることで問題の解像度を上げることができる。また、設計パターン(よくある問題・解決策)を知って実際の問題を丁寧に解決していく。
オプションのために、アプリケーションはシンプルにし続けることが大事。RailsはそのためのFWなのでRailsを習得することが重要になる。
機能変更・追加によりシンプルさを失わないために全体と調和していない部分を見つけて修復するという創造的な行為をしつづけることが重要。修復が重要な箇所に気づくためには、感覚に頼ることが大事。感覚を養うためにはシステムコンポーネントや設計パターン、Railsを習得し、システムをシンプルに保つことにより認知負荷がない状態にしておくことが大切。
あとは、書籍、コード、コミュニティで学び続けることも大事だというお話を聞き、自分は書籍に偏りがちだということに気づいたので、これからはOSSのコードを読む時間を増やそうと思いました！
さいごに
Ruby/Railsを触り始めて1年以上が経ったので、今回のKaigi on Railsでは理解できる部分が増え、去年より楽しむことができました！
また、所属しているコミュニティの方々と実際に会って話したり、コミュニティ外の方とも話しとても刺激的な2日間でした。
楽しかった思い出とRails熱が上がったので終わってから1週間くらいはずっと気持ちがフワフワしていました😃
今年の会場は去年よりも大きくなっていてビビりました！来年は東京駅からすぐのところみたいで、さらに大きくなりそうですね。
運営の方々に本当に感謝しかないです。来年のKaigi on Railsもとても楽しみにしています！
改めて運営、登壇者、一緒に話してくださった方々、ありがとうございました！！！
大阪Ruby会議04に参加してきた！
8/24(土)に開催された大阪Ruby会議04に参加してきたー！
カンファレンスに参加したのは去年の10月に開催されたKaigi on Rails 2023が最初だから、10ヶ月ぶり？くらいの参加かな。
会場は中之島フェスティバルタワー・ウエストってところで、ビルがめっちゃキレイなところで入る時めっちゃ緊張した🤣
発表のスケジュール: regional.rubykaigi.org
確か2-3週間くらい前に大阪Ruby会議04が開催されることを知ったけど、最初は「行きたいけど遠いしちょっときついな」と思って諦めて全然スケジュール見てなかった。
ちょうど開催1週間前になんとなくスケジュール見て、発表内容がめっちゃ気になってちょっと無理して予定空けて参加した！
本当に参加して良かったーーー！！！
特に印象に残った発表
正直全部の発表が刺激的で面白かったけど、特に自分に刺さった発表を残しとく。
Keynote: 最高の構文木の設計 2024年版
抽象構文木、具象構文木があるということを知った。
構文木を解析する時、ツリーを
- 上から下へ
- 下から上へ
- 上から下 + 下から上へ
解析するパターンがあるということを知った。それぞれユースケースが違う。
他にもいろいろメモしたけど、理解度が低いから金子さんのブログを見て復習するかー。
Ruby Parser開発日誌 (19) - 最高の構文木の設計 2024年版 - かねこにっき
GitHub - yui-knk/lr-parser-101という構文解析のhello world的なチュートリアルがあるらしい。
確かドラゴンブックを半分くらい読んだ人だと分かりやすいと話されてたはず。
会議中、何回かドラゴンブックの話しが出てきてめっちゃ気になってた🤣
調べてみるとこの本のことみたい。気になる👀
コンパイラ[第2版] - 株式会社サイエンス社 株式会社新世社 株式会社数理工学社
Rustで作るTreeSitterパーサーのRubyバインディング
RustでTreeSitterパーサーのRubyバインディングを実装する話だった。
難しすぎて9割程は理解できなかったけど、
- magnusというCrateを使えば、Ruby APIとやり取りする箇所がコーディングしやすくなる
- C言語と比較して、メモリ安全のための制約があるためしんどい部分がある
- C言語で文字列を扱うのはかなりしんどい、Rustは比較的最近の言語なのでそこらへんは楽
ということを知った。
まずは放置してるパーフェクトRubyの「C言語でライブラリの作成」の章を読みたくなった（読む！）
Keynote: 令和の隙間産業——PicoRubyはどこから来て、どこへ行くのか
RubyKaigiの80%のトークはすぐには役に立つものじゃないけど、後に役立つこともある。
隙間産業 = ちょっとしたプロダクト、を持とうという話し。
お誘いを受けてC言語があまり分かっていない状態でPicoRubyを触るようになってから、PR2040で動かせるようにするまでの話しがめちゃめちゃ面白かった！
キーボードが好きだからPRK Firmwareはめちゃめちゃ気になった。
ちなみに 大阪Ruby会議04 の @hasumikin sanが言っていたほとんどのペリフェラルを網羅しているので本当に電子工作入門本としておすすめです #osrk04 https://t.co/RjPXajAKQ5
— hachi (Hayao Kimura) (@hachiblog) August 25, 2024
ちょうど面白そうな題材が紹介されてたから、こっちもやってみようかなー。
After Party
顔見知りの方がほぼいない状態の参加だったので、途中で帰ろうか迷うくらい不安だった😂
参加してみると、話しかけてくださる人がいて、案外会話に参加できてすごく充実してた。
「Ruby会議初参加で理解できた事少なかったんですけどめっちゃ面白かったです！」って話してたら「それ、RubyKaigiあるあるですよ」って教えてもらった。
Ruby/Rails開発経験がまだ浅い自分にも気さくに話しかけて下さる方がいて、本当に楽しかったし嬉しかったなー
Rubyコミュニティについて
他の言語コミュニティに入ったことないけど、Rubyコミュニティの人たちは技術について本当に楽しそうに話される方が多いと思った。
「自分もこの方たちみたいになりたいな」と思えた。
感謝！！！
運営、登壇者、参加者、スポンサーの方々には本当に感謝しかないです。
本当に充実した1日を過ごせました、ありがとうございました！！！
おまけ
大阪駅に展示されてるThe Fountain Boy。めっちゃ見たかったやつ！！
一番上のスタンドは9部主人公のスタンド、ノーベンバーレインっていうらしい。名前かっこいい
