Kaigi on Rails 2023 で同僚とモブプロしました

勉強会など

これは フィヨルドブートキャンプ Part 2 Advent Calendar 2023 1日目の記事です。

10月27日・28日に開催された Kaigi on Rails 2023 に、同僚でありフィヨルドブートキャンプ仲間でもあるトミーさん、あんすとさんと3人で登壇しました。 3人とも現在 Tebiki株式会社 で働いています。

登壇のきっかけ

3人とも、2023年5月に長野県松本市で開催された RubyKaigi 2023 に参加しました。

オフラインで大きい技術イベントに参加するのは初めてだったのですが、例に漏れずモチベーションが爆上がりしました。 （たとえほとんど理解できなくても…）

会場でお昼ご飯を食べているときに、私たちも登壇してみたいねという話になり、業務時間を週に1時間使わせてもらって Kaigi on Rails 2023 登壇を目標に、登壇内容を考え始めました。

最初は各自でプロポーザルを出すつもりでしたが、3人でペアプロ/モブプロしたら面白そうという話が出て、我々のチームで普段やっているペアプロ/モブプロ開発を紹介したら他の参加者にも役立ちそうということで、3人で1つのプロポーザルを出すことになりました。

発表内容

Kaigi on Rails 2023 での実際の発表はこちらから動画で見られます。

kaigionrails.org

ペアプロ/モブプロ開発のメリットと実践 Tips の紹介、そして LIVE モブプロを行いました。

私たちが所属する Tebiki株式会社 では、開発やテストなど大半の作業を複数人で行っています。

フィードバックをもらうタイミングは、早ければ早いほど修正コストが低いというデータがあります（詳細は動画をご覧ください）。

ペアプロ/モブプロをすることにより、フィードバックサイクルを高速で回すことができ、結果的にプロダクト品質を向上させることができます。その上、ペアプロ/モブプロは楽しいです。

あと、レビューのやり取りって結構つらくないですか？コード見ながら直接話せば一瞬で終わることが何日もかかったりして。。。ペアプロだと、レビュー時間ほぼゼロです。

いろんな課題の解決策と思って導入したペアプロ/モブプロですが、導入当初はさまざまな問題にぶち当たりました。それをどうやって我々のチームが乗り越えたのか、そして実際どのようにペアプロ/モブプロをやっているのかを発表しました。

ペアプロ/モブプロ開発を本格的に導入したいチームにとっては参考になると思います。

LIVE モブプロでは、FJORD BOOT CAMP（フィヨルドブートキャンプ） のアプリを題材に使わせていただきました。

数週間かけて新機能を追加していたのですが、本番の約1週間前、発表の練習の段階になって、内容的にペアプロ/モブプロのよさを伝えるのに十分でないという話になり、急遽内容を変更することになりました。ちょうどよい Issue があって本当に助かりました。

（フィヨルドブートキャンプ関係者の皆様、使わせていただいてありがとうございました！）

発表内容の要約

  • ペアプロ/モブプロのメリット
    • フィードバックのタイミングが早ければ早いほど修正コストが低い
    • ペアプロするとソロプロに比べ不具合が少なくなる
    • ペアプロで増えるコストよりペアプロによって減らせる修正コストの方が大きい
  • 我々がペアプロ/モブプロ開発導入によって解決したかった課題と導入後の結果
    • レビューが終わらない
      • →レビュー依頼〜マージに平均2日以上かかっていたのが、ペアプロ開発導入後は24時間以内に
    • 属人化
      • →アンケートでは全員が属人化が減ったと思うと回答
    • 新メンバーがキャッチアップしにくい
      • →アンケートでは全員が新メンバーのキャッチアップが早くなった/どちらかといえば早くなったと思うと回答
  • ペアプロ/モブプロ導入後の課題と解決策（ペアプロ実践 Tips）
    1. うまいやり方がわからない
      • →Slack のハドルミーティングで画面共有
    2. ペアの息が合わず迷走する
      • →開始前に方針を書き出す
    3. めちゃくちゃ疲れる
      • → 1時間やったら10分休憩
    4. ペアの役割を交代するタイミングを失う
      • →時間で強制的に区切る（15〜20分）
    5. ドライバー超大変、ナビは見てるだけ？
  • LIVE コーディング
    • 題材：フィヨルドブートキャンプで実際に使われているアプリ

speakerdeck.com

登壇しての所感

こんな大きなイベント登壇は初めてかつオフライン登壇も初めてででしたが、運営の方々からの連絡は丁寧でわかりやすく、安心して当日を迎えることができました。本番もトラブル等なく大変スムーズでした。

発表の様子（写真）

本番は3人いたこともあり、思ったほど緊張しませんでした。手は震えてましたが…

3人いたら準備も分担できるから1人で登壇するより楽かと思いきや、必ずしもそうではありませんでした。各メンバーで思っていることが違ったり、うまくいかなかったりして揉めそうな場面も何度かありました。バンドの解散理由でよく聞く“方向性の違い”ってこういうことなのかと思ったりもしました。

でも、終わった今感じているのは、楽しかったという気持ちが一番大きいです。大変なこともありましたが、この3人で Kaigi on Rails という大舞台で発表することができてよかったです。

会社や同僚にもたくさんサポートしてもらいました。この日のためにTシャツやシールを作ってもらったり、内容についてアドバイスをもらったり、業務時間内に準備・練習をやらせてもらったりなどなど。

自分が言うのもあれですが、いい会社だなーと思いました。

最後に

個人的に、毎年楽しみにしていたイベントで登壇する機会をいただけて感慨深く、うれしかったです。

初回のとき書いた記事を見つけました。。。

masuyama13.hatenablog.com

運営の皆様、素晴らしいイベントを開催していただいてありがとうございました。

ということで、これからも毎日ペアプロ/モブプロやっていきたいと思います。

ついでに宣伝ですが、「ほぼ全部ペアプロ開発」に興味のある方、ぜひ一緒に開発しましょう〜

Tebiki株式会社

近況報告（プログラマになって1年8ヶ月）

日記・ひとりごと

これは「フィヨルドブートキャンプ Part 2 Advent Calendar 2022」の18日目の記事です。

フィヨルドブートキャンプ卒業生として近況報告をします。

最近の生活

仕事

2021年3月にフィヨルドブートキャンプを卒業後、Tebiki 株式会社で働きはじめ、1年8ヶ月が経ちました。

普段は朝10時前に新宿のオフィスに出社し、19時頃退社します。週1〜2日はリモートワークもしています。

リモートかどうかにかかわらず、10時から19時までほぼオンラインでずっとペアプロ or モブプロで作業します。ペアプロについては前に少し書いたので、興味があれば読んでみてください。スライドの中にオフィスの写真もあります。分割キーボード最高。

masuyama13.hatenablog.com

最近はエンジニアが増えてきていて、フィヨルドブートキャンプ卒業生も入社してくれました。おかげさまで楽しく仕事できていると思います。

ペアプロ・モブプロでは相手の経験年数にかかわらず、学ぶことが多く、毎日いい刺激をもらっています。エディタの便利機能とか、ペアプロしてなかったら一生知らなかったようなことを毎日知れて楽しいです。

入社後思ったことは、フィヨルドブートキャンプでチーム開発を通して Git・GitHub 力をつけておいたのがよかったということです。リベースしたらどうなるか、マージしたらどうなるかとかそういうやつです。GitHub の運用ルールは会社によって異なりますが、最低限知っておかないと、そもそもルールが理解できなくて困ります。

フィヨルドブートキャンプ在籍中にいろいろ練習して失敗しておいてよかったです。普段は RubyMine を使っているので、コマンドラインはほぼ忘れてしまいましたが。

仕事以外

週に2〜3回、フィヨルドブートキャンプ卒業生や現役生とオンライン勉強会（輪読会）をやっています。在籍中から継続している感じです。

仕事を始めるとなかなか勉強の時間を取れないこともあるので、定期的に勉強する場を設けて習慣化するのは有効でした。技術の話はもちろん、他の勉強会情報や仕事上の悩みなどいろいろ話すことができ、自分にとっては強制的に勉強というよりは息抜きの時間のように感じることもあります。

こうやって気軽に話せる友人ができたことも、フィヨルドブートキャンプに通ってよかったと思うことの一つです。イベント参加や輪読会・もくもく会とかやっておいてよかったなと思います！

今後やっていきたいこと

最近は、テスト（RSpecとか）に興味があるので、そこをもっと勉強していきたいです。効率的なテストケースの洗い出し方とか、テストに必要最低限の DRY はどの程度か？とか。

あとはスクラムについても勉強中です。先月 PSM I という試験を受けて、スクラムガイドについて最低限の知識はついたものの、実践時にはスクラムガイドに書かれていない部分がたくさんあってわからないことばかりなので、本を読んだり勉強会に参加したりしています。結局は、そのチームに合ったやり方を見つけるしかないですね。

scrapbox.io

TypeScript の勉強も始めました。どうも JavaScript に苦手意識があるので、これを機に TypeScript マスターになって苦手を克服したいと目論んでいます。

フィヨルドブートキャンプ生の名に恥じないようにやっていきます〜

読んでいただきありがとうございました。

Kaigi on Rails _2022_ new でペアプロについて LT しました

勉強会など

2022年10月9日（日曜日）に開催された、Kaigi on Rails 2022 new というイベントで LT（5分間）をやらせてもらいました。10月21日・22日に開催される Kaigi on Rails 2022 のプレイベントです。

YouTube ライブ配信で、参加者は80名ほど。

今働いている会社で取り組んでいる「ノンソロ開発」をやる中で、チームで試行錯誤してみつけた「ペアプロをスムーズに進めるための Tips」について発表しました。

スライドはこちら。

speakerdeck.com

自分も実際やってみるまで知らなかったのですが、1時間以上ペアプロ・モブプロやるとめちゃくちゃ疲れます。休憩大事。

今回は5分という短い時間だったので「ノンソロ開発」自体の意義などにはふれられなかったのですが、フィードバックサイクルを高速に回すことで、質の高いプロダクトをできるだけ早くユーザーに届けるために導入しました。

そのほかの LT も興味深いものばかりで、Rubocop 好きとしては特に気になったのがこちらの発表。早速リポジトリだけ作ってみた！

運営の皆様、LT 聞いてくれた皆様ありがとうございました。

Kaigi on Rails 本編も楽しみです。

kaigionrails.org

『達人に学ぶDB設計 徹底指南書』輪読会をやった

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書

2020年の年末から、フィヨルドブートキャンプ内で『達人に学ぶDB設計 徹底指南書』の輪読会をやった。

Slack で輪読会の話が出たときに、DB関係の本を読みたい！と言ったところ、フィヨルドブートキャンプのアドバイザーであるベテランエンジニアの方がメンターをやってくださることになり、開催に至った。

初学者で集まって読むのも楽しく一人で読むよりは知識も深まるが、その分野の知識や経験が豊富な方に参加してもらえたことで、さらに何倍も有意義な会になったと思う。

ものすごく勉強になったのを独り占めするのはもったいないのと、自分の復習のためにも特に印象に残ったところだけでも書き残しておくことにしたい。

学んだこと〜データベースを制する者はシステムを制す

データベースは事実を保存するもの

プログラムと比べ、データはあまり変化しない。というか、そう設計されるべきだ。データ設計（データベース設計）は、プログラム設計に先立って行う。

たとえば、ユーザーの氏名（事実）が変わることはあまりないが、名前の表示の仕方（プログラム）を変えたくなることはよくある。

名簿はフルネームだけど、担当者名のところには苗字だけ表示させたい、とか。

可能な限り NOT NULL 制約をつける

事実を保存する前提に立つと、基本的にNULL（データが空っぽ）となることはない。 NULLを許容したくなったときは、データ設計自体を見直した方がよい。

たとえば、以下のような社員テーブルを考える。

社員ID 姓 名 年齢 部署
200500123 山田 太郎 45 総務
201000111 高橋 花子 36 広報
202100567 鈴木 一郎 20 ？？？

今年入社したばかりの鈴木さんは、研修後に配属が決定されるので、入社日時点では部署が決まっていない。

NULLを許容しないとなると、部署が決まるまで鈴木さんを社員テーブルに追加することができない。

こういうときは、このテーブルの設計自体がまずい可能性が高い。

社員テーブルに「部署」を入れる必要があるのか？配属先が変更になったら？複数の部署に配属される可能性はゼロか？

ということを考慮すると、「配属」というイベントが存在していることに気づく。

部署テーブル

部署コード 部署名
010 総務
020 広報
以下略 …

配属テーブル

配属日 終了日 社員ID(外部キー) 部署コード(外部キー)
2005-06-01 2011-3-31 200100123 070
2011-04-01 2018-03-31 200100123 050
2018-04-01 200100123 010
2010-06-01 2015-03-31 20100111 030
2015-04-01 20100111 020

現在進行中のところの終了日はNULLを入れたくなるからまた設計がおかしいのか…

と思うかもしれないが、こういうところには最大値を入れておくというテクニックがある。「事実」ではないが、つっこまないで…。

未来に起こる「かもしれない」ことを全て考慮するのは難しく、NULLを許容することが絶対に悪いということではない。

何かを優先すれば何かが犠牲になる「トレードオフ」の世界なので、部署を未定で登録しておくケースもあるかもしれない。

何を優先するかによって、考え方・正解がたくさんある世界だという点も大事。

可逆 / 不可逆を考える

上の社員テーブルでは、社員名の姓と名を別々のカラムにした。

データはできるだけ分解した方がいいというのはなんとなくわかるが、姓だけ、名だけでは誰かわからないので意味が失われてしまうのではないか？

カラムを分けるか、テーブルを分割するか考えるときは、可逆的か（元に戻せるか）どうか？を考えてみるとよい。

姓・名を別々のカラムにしておいたとして、フルネームが必要なときは、2つのカラムのデータを単純にくっつければいい（可逆的）。

逆に、氏名という1つのカラムに「山田太郎」と保存していた場合、社員の姓だけが必要になったときに、プログラムで姓だけを取得することは不可能。 絶対にフルネームでしか使わないということであればいいのかもしれない。

ちなみに、「年齢」はあまりよくなさそう。誕生日が来たらいちいち更新するのか？「生年月日」にしておけば、年齢はプログラムで求めることができる。

正規化は絶対ではない

データベースの勉強をすると必ず出てくる「正規化」という言葉。

ざっくりいうと、冗長性（重複）をなくしデータの不整合を防げるように整理すること。

正規化にはいくつか段階があり、正規化を進めれば進めるほどデータ整合性を高められるが、検索性能は劣化する。ここもトレードオフ。

正規化するのが絶対に正しいというわけではなく、パフォーマンスを優先してあえてデータを冗長に保持することもある。

たとえば、Twitter の「いいね!」数は、ある特定のツイートに対し誰が「いいね!」しているかをデータベースに問い合わせて計算すれば求めることができる。ただ、何万もの「いいね!」がつくことも珍しくない Twitter で、一つ一つのツイートに対してそんな処理をやっていると、結果が表示されるのに時間がかかったりデータベースに負荷がかかったりする。

こういう集計データ（サマリデータ）は、計算後の結果を別途保持しておくことによって、パフォーマンスを上げることができる。

トレードオフを理解した上での非正規化は、アンチパターンではない。

ER図をいきなり描くのは難しい

フィヨルドブートキャンプでは、Twitter の ER 図を描くという課題がある。苦戦した過去の自分へのアドバイスをいくつか。

とにかく、まずは具体的なデータを置いてみること。どういう形でもいいから、具体的な例を考えてデータの置き場所を作ってみること。

エクセルのような表を作って、セルに複数のデータが入ったりしてもいいから、とりあえず書いてみる。

その後、正規化したりリレーションシップを考えたりしていく。いきなり ER 図を描くのは難しい。

この本では、2種類の表記方法が紹介されているが、ググってみると、いろんな描き方をしている人がいて、どれが正しいの？となる。

ER図に関しては、厳密にどれが正しいというより、伝わることが一番大事。

主キーの考え方がRailsとは違う

この本を読むときに注意が必要なのが、主キーの考え方。

主キーの考え方には、ナチュラルキー（自然キー）とサロゲートキー（代理キー）というものがある。

参考：「ナチュラルキー」と「サロゲートキー」の違い｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

ナチュラルキーは、事実を（必要に応じ組み合わせて）主キーにするのに対し、サロゲートキーは、事実とは関係のない番号などを人工的に主キーとしてつけるもの。ナチュラルキーの例は、上の社員テーブルでいうと「社員ID」や「部署コード」。これは、プログラムのためにつけたものではなく、現実世界に存在するID（コード）。

この本は、ナチュラルキーを使うべきで、サロゲートキー（代理キー）は推奨しない立場で書かれている。詳しくは本の「8-2 代理キー〜主キーが役に立たないとき」を参照。

一方、Rails はデフォルトでサロゲートキーを使うようになっているので、この立場の違いを知らないと理解が難しいところが多々ある。 自分も1回目に一人で読んだときはそれを知らず、理解できないところが多かった。

現在、現場ではサロゲートキーが使われることも多いようだ。

サロゲートキーは連番か

ちょっと話は逸れるが、サロゲートキーを連番にするかランダムな数字にするかという話題で興味深いツイートを教えてもらったのではっておく。

たとえば、ユーザーIDが連番だと、登録した人が「全ユーザーが何人いるか」わかってしまうので、あえてランダムな数字にすることもよくある。

難しい用語にこだわらなくていい

この本では、部分関数従属とか推移的関数従属のように難しい用語がいくつか出てくる。

現場ではあまり使わないようなものもあるので、細かい用語を一つ一つ覚える必要はない。難しい言葉は、ざっくり理解して次出合ったら覚えるぐらいでよさそう。

輪読会の概要

毎週土曜日22時〜23時に Discord で開催し、全13回。

参加者は、多い日は20人弱、少ない日は3人ぐらい。

項目ごとに5〜10分の時間を取って各自読みながら疑問点などを HackMD に書いていき、時間が来たら意見交換を繰り返す流れで進行した。

第7〜8回は、参加者を2チームに分けてモブプロっぽく ER図の作成会をやった。

参加してくれた皆さん、bluerabbit さん本当にありがとうございました。

『トヨタの失敗学 「ミス」を「成果」に変える仕事術』を読んだ

読書

トヨタの失敗学 「ミス」を「成果」に変える仕事術

トヨタの失敗学 「ミス」を「成果」に変える仕事術

どんな本か

「失敗=悪」。これが世間の常識です。だから誰もが「失敗などしたくない」と思いながら仕事をしています。 「失敗したら上司に叱られる…」 「 問題を起こせばまわりに迷惑をかけてしまう…」 「 失敗したら責任をとらされる…」

このような事態が想定できるからこそ、 「失敗しないように無難に進めよう」 「失敗したら、バレないように隠してしまおう」 「いざとなったら力技でごまかそう」 という発想になってしまいます。しかし、「失敗は避けなければならないもの」という意識でいるかぎり、失敗から目をそらす姿勢が強くなります。そして同じような失敗を繰り返すことになり、事態は悪化していきます。また、新しいことや困難なことへのチャレンジにしり込みするので、職場のチームも自分自身の成長も減速します。

トヨタの現場の第一線で活躍してきたトレーナーたちが、口をそろえて証言していることがあります。 「トヨタの現場では、たくさんの問題やトラブルが起きる。でも、『失敗』という言葉はほとんど聞かなかった」 もちろん起きた現象だけをとらえれば、トヨタにもミスやトラブルなど大小さまざまな失敗がありますが、少なくとも現場レベルでは「失敗」という概念は存在しません。失敗したことをそのまま放置したら、それは文字通りの「失敗」に終わってしまいます。しかし、失敗に正面から向き合い、次に活かすことができれば、その失敗は改善プロセスのひとつとなります。「失敗」が「失敗」で終わらないのです。

現場のメンバーが知恵を絞って、「なぜ不良が起きたのか」を徹底的に考えます。そして、問題を引き起こしていた原因を突き止めて、二度と不良が出ないような対策を実施し、そのしくみは、他のラインや工場にも展開することで、組織として強くなっていくのです。

つまり、トヨタの現場では、問題やトラブルをよりよいモノづくりをするための「改善の機会」ととらえているのです。 トヨタの現場で働く人たちにとって「失敗」とは、改善へとつなげるチャンスであり、成果に結びつける「宝の山」です。 (はじめにより)

Amazon.co.jp より

所感

いろんな職場で使えそうな実践的な内容だった。上の抜粋を読めば大事なところがなんとなくわかるかもしれない。

「失敗＝悪」ではない

失敗は改善のタネで宝の山。これが一番大事だと思った。今まで、失敗についてじっくり考えたことがなかったが、当然のように失敗は悪いことだと思っていた。

できれば失敗は避けたいし、もし失敗したら隠したい。そう思っていた気がする。

この本を読んで失敗は悪ではないとわかっても、実際に仕事をする中で、失敗を隠したい気持ちをゼロにできるだろうか？

自分の無知やミスをさらけ出しても責められたりバカにされたりすることがない、心理的安全性が確保されている職場なら、可能だと思う。この本の中で「心理的安全性」という言葉自体は出てこないが、トヨタでは、工場で異常を見つけてラインを止めた作業員を誰も責めたりすることはなく、むしろ奨励されているという。そうやって問題を小さいうちに発見し、改善を続けていくことが大事なのだと知った。

心理的安全性が低く、失敗したとき個人が責められるような職場だと、失敗を宝の山と考えるのは難しいだろう。先日読んだ 不機嫌は罪である (角川新書) という本にも似たようなことが書いてあったのを思い出した。みんながニコニコして明るい職場は、離職率が低くなり業務効率が上がるそうだ。Googleによる調査で、生産性の高い職場にもっとも重要な要素が「心理的安全性」とされたことにも触れられていた。

心理的安全性が高いと生産性が高まると聞いて、メンタルが仕事の生産性にまで影響を与えるのかと漠然と考えていたが、今回『トヨタの失敗学』を読んで、生産性が高まる理由がわかった。それは、失敗を隠すことがなくなるだけでなく、日頃からさまざまな情報が共有され、ちょっとした気づきの段階で失敗の芽を摘み取ったり改善したりしていくことが可能となるからだろう。

エンジニアは、気をつけていてもバグを一度も出さない人はいないので、この「失敗学」の考え方はとても大事だと思った。

失敗から学び、改善してよりよくすることができれば、それはもはや失敗ではなく成長の1ステップ。

大事だと思ったことをメモ

  • 「失敗＝悪」ではない
  • 失敗を放置したら文字通りの「失敗」になってしまう
  • 失敗は宝の山、改善のタネ
  • 失敗したら真因を追求する
    • 何が起こった？
    • なぜなぜ5回
  • 失敗しても個人の責任にしない
    • 真因ではない
    • 失敗が隠されるようになる
    • チャレンジしない組織になってしまう
  • 「人はミスをするもの」という前提で失敗しないしくみをつくる
  • 小さい問題は繰り返されたり、後で大きい問題になったりする
  • 問題が小さいうちに、自らの意思で問題を明るみに出す
  • よその失敗を自分ごとととらえて対策を講じる
  • 明るい職場は「失敗」が隠れない
  • あきらめずに前進を続ければ「失敗」にはならない

大人の勉強法について考えた

日記・ひとりごと Scrapbox

学生の頃の勉強といえば、覚えるものだった。覚えなければテストで点数が取れないので、きちんと理解して覚えるようにしていた。

大人の勉強は覚えることが最終目標ではないと気づいたのが自分はかなり遅かったので、ブログに書いておくことにした。ここでいう大人の勉強というのは、プログラミングとかその周辺の話。

大人の勉強の目的は未来の自分へのカンニングペーパーを作ること

Webエンジニアが仕事をするときを考えてみると、学生の頃と違ってググってOK、カンニングし放題なので、仕事に生かすための勉強をするのであれば、一度理解したことをいかに早く正確に思い出せるようにしておくか、が一番重要だと思う。

つまり、大人の勉強とは、対象を理解した後に未来の自分へのカンニングペーパーを作ること、そして必要なときにすぐにそれを出せるよう整理しておくことだと思うに至った。

未来の自分を信用しないことも大事で、「さすがにこれぐらいは覚えていられるだろう」というような基本的なことも、迷ったら書いておいた方がいい。その後学んだ他の言語とごっちゃになってわからなくなってしまうかもしれないから（経験談）。

個人的にScrapboxはおすすめ

メモツールはいろいろあるので何でもいいと思う。自分が愛用しているのは Scrapbox。

scrapbox.io

フォルダ分けがなく階層構造を持たないことや見出しなどが作れないことにはじめはびっくりしたが、これが非常に使いやすい。書き出すまでの時間がゼロ。そして検索やページ間リンクもしやすい。もっと早く使っとけばよかった！と思っている。そういえば前にも書いた気がする。

masuyama13.hatenablog.com

書くハードルが低すぎる分、後から見ると意味不明になってることもあるけど、なんかの拍子にそういうのを見つけて修正したりするのも面白い。

公開プロジェクトにしておけば共有も楽だし、意外な場面で話題になったりすることも？

最近は技術的なことに限らず、何でも放り込んでいる。

タブ開きすぎ症候群にも効くかも

それから、自分の場合は、Scrapbox を使い始めてから、「気づいたらブラウザのタブを大量に開きっぱなしにしてしまう問題」も解決した。後から見返したいようなページであれば Scrapbox にリンクを張ったり必要な部分をメモしたりすることで、また見る「かもしれない」タブを閉じることができる（検索で上位に来ない公式ドキュメントのページなど）。検索すればすぐにたどり着けるようなページならそこまでしなくてもいい。

情報の粒度みたいなところも気にしなくていいからいいのかもしれない。ほんのちょっとしたメモからブログみたいな長文まで、内容も問わず何でも放り込めるところが好き。

こういうの（WebページをMacアプリっぽくする - masuyama's notes）を使うと、アプリっぽく使うこともできたりする。

今のところ、自分にとって Scrapbox 最強。これがないと多分何もできない人になりつつある。（バックアップ取っとかないと…）

masuyama's notes

間違いを見つけたら教えてください〜

「【iCARE Dev Meetup #18】技術顧問が語る、Ruby on Rails実践開発」に参加

勉強会など

2月17日、オンライン開催された【iCARE Dev Meetup #18】技術顧問が語る、Ruby on Rails実践開発 - connpassに参加した。

所感

RailsバージョンアップやSQLなど興味のある話題が多かったので参加してみた。

「Railsバージョンアップを実践してみて」では、テストの大切さを再認識した。バージョンアップの難しさをあまりイメージできていなかったが、Gem同士の依存関係の具体的な話もあり、作業のイメージができた。思っていたより大変そう。やはり、テスト大事。

「SQLとActiveRecordについて」は、SQLをゴリゴリ書いていた人がRailsに入門するときに、SQLを組み立ててからそれをどうRailsで表現するかという内容。例がこのMeetupの参加者や登壇者だったのでわかりやすかった。

自分の場合、SQLの理解が浅くActiveRecordに頼りっきりだが、SQLをわかっている人の考え方を知るのは興味深かった。ActiveRecordは便利で、SQLを知らなくても大概のことができてしまうが、SQLを意識せずにいるとパフォーマンスが悪くなってしまうことがあるので、SQLについても勉強したいと思った。

「HotwireからDHHが考えるこれからのRailsとJSとの付き合い方を知る」では、TurboとStimulusの詳しい話を聞くことができた。Stimulusは、「控えめなJaveScriptフレームワーク」としてパーフェクト Ruby on Rails　【増補改訂版】に載っていたので理解していたが、Turboについてはまったく知らなかったのでとても勉強になった。

Hotwireを使うと、ロジックをサーバーサイド側に集中させ、フロントエンドをわかりやすく書けそうだと思った。モバイルにも一応対応できるようなので、今後使われることが増えるかも？

全体的に勉強になったので復習したいが、発表スライドを1つしか見つけられず残念。 YouTube にアップされていたのでリンクをはった。

内容メモ

Railsバージョンアップを実践してみて

youtu.be

バージョンアップ前の状況

  • Gem更新など3年ぐらい止まっていた
  • 新機能開発が優先になっていた
  • 使用しているGem、150以上
  • 管理画面側はテストが少なく人力で確認しないといけない状態

バージョンアップ

  • Railsガイドがわかりやすかった
  • Change log
  • dependabotの導入
  • CIを通す
  • Gemをアップデート
    • Gem同士の依存関係によりスムーズにいかないことも多い
  • bundle outdatedで確認
    • 使っていないGemは削除
  • 本番環境に影響が出るものは1個ずつ

まとめ

  • テスト大事！
  • 不要なGem入れない
  • 使わなくなったら削除する
  • メンテナンスされているGemを使う

Rails APIモードにおけるToken認証機能について

youtu.be

認証Tokenをどこに保存するか？

  • LocalStorage
    • 実装が簡単
    • XSS脆弱性があった場合、Tokenを容易に盗むことができる
  • Cookie
  • In-memory
    • JavaScriptでブラウザのメモリ内に保存する方法
    • 永続化されない（リロードすると消滅）
  • Auth0のSilent Authentication
  • それぞれの目的や扱う情報に応じて選ぶ

SQLとActiveRecordについて

youtu.be

SQLからActiveRecordの使い方を考える。

  • Meetupと参加者、登壇者を例にしたER図
  • SQLを組み立ててからRailsのコードにする

HotwireからDHHが考えるこれからのRailsとJSとの付き合い方を知る

youtu.be

Hotwireは、Basecamp社製のjsフレームワーク。複数のフレームワークから構成されている。

“最小限の労力でユーザが求めているサービスを提供すること”に特化しているライブラリ。Railsと同じ方針をフロントエンドにも持ち込んだものといえる。小〜中規模のサービスに向いている。

Hotwireを使うと、

  • サーバサイドにロジックを寄せることができる
  • クライアントサイドのコードは最小限におさえることができる
  • それでいて、それなりにSPAができる
  • 結果として
    • ひとつのチームですべてを担当できる（かも）
    • 好きな言語を使える（Rails以外でも使える）
  • VueやReactと比べると細かいことはできない

Hotwireのアーキテクチャ

  • Turbo
    • Turbo Drive（Turbolinksを改善したもの）
    • Turbo Streams
    • Turbo Frames（HTMLの一部を差し替えることができる）
      • 遅延評価も可能（loading="lazy")
    • Turbo Native（iOSやAndroidでTurboを使うためのライブラリ）
  • Stimulus
    • 学習コストが低い
    • ファイルが自然と整理される
    • 特定のページだけで発火させたいjsが書ける
  • Strada（未発表）

Turbolinks

  • 全てのリンクをAjaxに置き換えるライブラリ
  • E2Eテストやformの挙動がわかりにくい
  • ハマる人が多く、基本消されるライブラリに...

（参考）TurbolinksからTurboへの移行 - おもしろwebサービス開発日記