/var/log/da1

日々の活動や生活のログ解析

ERBファイルでJavaScriptを書きやすくするVSCodeの拡張機能の紹介

ERB(eRuby、embedded Ruby)の HTML 上で JavaScript を書きやすくする VS Code 拡張機能を公開しました。

marketplace.visualstudio.com

まずは実際に動作している様子を見てください。javascript_tag ブロック内に書いた JavaScript コードに対して以下の機能が利用できます。

  • シンタックスハイライト
  • コード補完
  • ホバーによるメソッドの型や定義の表示
  • 定義ジャンプ

https://github.com/kudoas/erb-inline-js-helper/raw/HEAD/sample.gif

本来、ERB ファイルに JavaScript を書いてもコード補完やシンタックスハイライトは効きません。 それを JavaScript ファイルでコードを書くときに近い体験として、ERB 上でも再現できるのが今回の拡張機能です。

開発したモチベーション

筆者は普段、Rails + Hotwire で画面を構築することが多いです。

Hotwire では基本的に Turbo の仕組みを利用して画面を作れます。 しかし実際の開発ではイベントハンドラーを追加したり、HTML のプロパティを付け外ししたりするために、ちょっとした JavaScript を書く場面もよくあります。

しかし、JavaScript を ERB ファイルに直接書く場合は、コードハイライトやコード補完がまったく効きません。 そのため、エディタ支援なしで書いたり、いったん JavaScript ファイルに書いてからコピペしたりして凌いできました。

ただ、こうしたやり方で JavaScript を増やしていくのは流石に大変です。解決できる VS Code 拡張機能も探した範囲では見つかりませんでした。 そこで拡張機能を自作することにしました。せっかくなら同じ問題で困っている人にも役立つかもしれないと思って公開することにしました。

仕組み

シンタックスハイライトは VS CodeTextMate 文法を利用しています。 javascript_tag ブロック内の JavaScript コードを正規表現で検知して、JavaScript として解析・ハイライトされるように設定することで実現できます。

code.visualstudio.com

補完やホバーの情報は、javascript_tag に書かれている JavaScript コードを TypeScript Language Service API に渡して取得しています。 取得した情報は VS Code Extension API で連携することで VS Code 上に反映されます。

code.visualstudio.com

VS Code Extension API で具体的に提供されているものはざっくり分けて3つです。

  • Completion API コード補完候補を返すための拡張API
  • Hover API カーソル位置の型情報やドキュメントを表示するためのAPI
  • Definition API 「定義へ移動」を提供するAPI

それぞれに TypeScript Language Service API の情報を連携しています。

ぜひ使ってみてください

今は最低限の機能しか入っていませんが、今後は HTML 属性(onclick など)に書いた JavaScript にも反映させることや、簡易的な型チェックなど機能を増やしていくつもりです。 同じ問題でお困りの方はぜひお試しください。

設計に対するコメントや機能要望も歓迎です。

marketplace.visualstudio.com

ネクストアクションを決めて仮説検証のサイクルを回そう

こちらは そーだいなる Advent Calendar 2025 22日目の記事です。

adventar.org

3行要約

  • 行動しない「考えてみます」は無価値であり、必ず具体的なネクストアクションを置くことが大事
  • 仮説に基づいたネクストアクションがあると行動後に検証できる。それが次の仮説につながりサイクルが回る。
  • 特に若い方ほど、そーだいさんと1on1をする価値がある。

そーだいさんとの関係

そーだいさんは弊社の技術顧問として関わってくださっています。
社内メンバーではない立場から、常に一段引いた視点でアドバイスをいただける存在です。

技術そのものの相談というよりも、エンジニアとしてのキャリア観や仕事への向き合い方、考え方について相談することが多く、社内にいながら社外視点のフィードバックを得られる貴重な機会になっています。

そーだいさんに言われて印象に残っている言葉 「考えてみますだけで、行動しないのは意味がないよ」

2023年、最初の1on1で悩みを相談した際、自分は「考えてみます」と返答しました。
そのときに言われたのが、「それでは次のアクションが明確ではないから意味がない」という言葉でした。

大事なのは、振り返りできる行動を記載して、必ずネクストアクションを置くことが重要だと強調されていました。

ネクストアクションとは、例えば、

  • 考えるための予定を入れる
  • ブログを書く
  • 誰かに聞く

など、「次に何をするか」が明確で、完了が判断できるものです。 行動がなければ仮説検証は回らず、結果として成長も評価も起きない、という指摘でした

実際に自分が取った(取っている)具体的な行動

最近の行動の手の内を明らかにするようで少し恥ずかしいですが、以下のようなことを意識的に行っています。

  • 日報を書き必ず振り返りを入れる
  • 紹介された本はその日のうちに注文する
  • 社内エンジニアと1on1を行い、自分一人では得られない視点を取りに行く
  • チーム内で筋が良いと感じた発言や判断をメモし、次に似た状況が来た際に自分も発言できるよう準備する

ここで意識しているのは、「達成できたかどうか判断できること」をネクストアクションにすることです。
「何かについて考える」といった曖昧なものではなく、「誰かと1on1を組む」「ブログを書く」など、完了条件が明確な行動に落とし込みます。

完了できるレベルまで分解することで、次に何をすればよいかが明確になります。
また、達成できなかった場合でも、なぜできなかったのか、どうすればできたのかを考える材料になり、それ自体が次の改善につながります。

行動を立て、早く実行し、検証し、その結果を次の行動に結びつける。
このループを回すことが何より重要だと学びました。

若い方こそそーだいさんと話すべき

自分がそうだったように、若手が感じる悩みや課題の多くは、すでにそーだいさんが考え抜いており、何らかの形でブログや登壇資料として言語化されています。
実際、1on1の場では、相談してからすぐに関連するブログのURLや資料が返ってくることがとても多いです。

若手のうちは、そーだいさんクラスの方と話すことに緊張したり、気後れしてしまう方も多いと思います。
しかし、だからこそキャリアが浅い段階で一度しっかり話しておく価値があると感じています。

社内に直接の接点がなくても、エンジニアの知り合いを辿ればどこかで繋がれる方です。
ぜひコンタクトを取ってみてください。

私もまた飲みに行きたいです。よろしくお願いします。

日報書くツール最適解の現在

このブログを読んで、「日々の新しい情報や調べたことをストック情報として保持できていない」と感じた。
そこで、情報をうまく保持できるようにするためのメモツールについて考えた記録。

soudai.hatenablog.com

メモツールに求める条件

自分が日報や学びの記録を書くために求める条件は次のとおり。

  • PC・iPhoneiPadなど、すべてのデバイスで書き込み・閲覧できること
  • リッチテキストではないこと(Markdown対応なら理想だが必須ではない)
  • シンプルで、すぐにメモできる操作性があること
  • 無料

日々の学びをざっと記録したいだけなので、Notionのような高機能ツールは日報用途には向かない。
特に重要なのは「操作がシンプルで、必要な時にどのデバイスでもすぐにメモできること」である。メモに凝った機能は必要ない。

試した結果、Consenseに落ち着いた

最初はApple標準のメモアプリを使っていたが、コピペ時にリスト(li)が消えることや、iCloud アカウントでログインできない環境では iCloudメモ を使わないといけないので面倒でやめた。

その後、Consense を試した。
今まで使ったことはあったが、独自記法や公式アプリがない点が好きではなかったので続かなかった。ただ改めて使ってみると、独自記法を使いこなさなくてもメモアプリとして十分だった。そして公式アプリの代わりにPWAで代用できることから、最終的にこれで良いということになっている。

Kaigi on Rails 2025 に「Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し」というタイトルで登壇しました #kaigionrails

先日 Kaigi on Rails 2025 で登壇しました。 登壇内容の相談や、会社で何回も練習に付き合っていただいてありがとうございました。 特に id:kozy4324id:kiryuanzu にはとてもお世話になりました。

speakerdeck.com

資料に盛り込めなかった話の補足や反響に対する私見を載せます。

当日のTwitterの反応

https://x.com/search?q=(%23kaigionrails)%20since%3A2025-09-26_15%3A45%3A00_JST%20until%3A2025-09-26_16%3A05%3A00_JST&src=typed_query&f=live

反響への回答

custom element へのデータの渡し方が複雑じゃない?

custom element へのデータを渡すインターフェースは、HTML属性DOMプロパティ の2つです。発表では渡したいデータ型によって使い分けるように説明しましたが、どちらかに統一できた方がシンプルだとは思います。

仮に HTML 属性に寄せたい場合は、コンポーネント側で文字列を型キャストする必要があります。Angular なら transform という API が用意されています。
入力プロパティによるデータ受け入れ • Angular 日本語版

ただ、この型キャストもプロパティごとに実装するのが面倒になりそうだったので採用しませんでした。

その代わり、DOM プロパティを利用して JavaScript 側から直接値を渡しました。これなら文字列以外も扱えます。 ただし、この方法は inline script が必要になるため Strict CSP(特に script-src 'self') が使えません。*1

CSP によりセキュリティを担保したい場合は、DOMプロパティは使いづらいと思います。

developer.mozilla.org

今回 custom elements を採用したのは新規サービスであり、コードベースも小さいです。そのため、セキュリティ的にまずいコードが混入しないようにレビューで担保できるので成立していると思っています。

データ属性に配列やハッシュを入れるとき、もっと良いサニタイズ方法はない?

正直なところ、現状は難しいと思います。サニタイズしつつ、ちゃんと動作するコードにするには少なくともの要件を満たす必要があります。

  • HTML として正しいこと
  • JavaScript として正しいこと
  • ERB(Ruby)として正しいこと

この条件を同時に保証する API はなく、自前で作るのも大変です。なので「data 属性に文字列として入れて、JavaScript 側で JSON.parse する」のが現実的だと思います。 もし属性が増えて管理が面倒なら、script 要素に逃げるのではなく HTML 属性の工夫で対応するのが良いと考えています。*2

custom element を自作するとメンテナンスコストが高くない?

ここは設計次第です。うまくカプセル化できれば再利用性も高く、コストは抑えられます。逆に安易に作るとコストは増えます。

また、そこまで作り込むなら Hotwire で自前実装するのも選択肢です。私たちのチームは Angular の知見を持つメンバーが多かったので、custom element 化することで既存の知識を活かせるメリットがありました。チームのスキルセットや環境によって最適解は変わると思います。

こぼれ話

今回初めての登壇で半分病みかけながら、準備をしました。できうる準備はして望めたので、それは良かったかなと思いつつ、今後に活かしたい改善も見つかりました。そのあたりは別でまとめるかもです。

いろんな方に声掛けられまして、「初めて custom elements 知った」「今度使ってみたいといった」声を届けてくれた方々がいて嬉しかったです。 登壇者は正直大変でしたが、その分コミュニティと繋がれた感覚が味わえて、またやりたいなと純粋に思いました。

あとは、懇親会で大倉さんとお話しできる機会がありまして、採択理由やコミュニティの話ができました。今後も Web 標準を追っていくモチベーションが湧きましたし、コミュニティや勉強会を主催したくなりました。*3 ありがとうございました。

同世代のレベル高い発表を見て、刺激ももらいました。自分も今日から良い発表ができるように日々の活動頑張ります。

最後に、Kaigi on Rails を主催していただいたオーガナイザーの皆様ありがとうございました。

*1:ちなみに Kaigi on Rails 2025 で紹介されていた Herb を触っていたのですが、 lint ルール で inline script を禁止するものを追加する issue がありました。erb に lint が掛けられるのはいいですね。 github.com

*2: id:hk_it さんに昔厳格なHTMLを定義するものとして XHTML という仕様があったことを教えてもらって、へぇ〜となりました。

*3:現在構想考え中です

「わかったつもり」を乗り越える本の紹介

2024年の"推し"本 Advent Calendar 2024 の 7日目の記事です。昨日はまつーらとしおさんでした。

adventar.org

今年読んだものの中で、特に推したい本として『わかったつもり 読解力がつかない本当の原因』(以下、本書)を紹介します。

books.rakuten.co.jp

本書を読むと、今まで読んだ本をまた読み返したくなります。

読解の最大の障害は「わかったつもり」である

本書は、小学2年生の教科書に掲載されている物語を読むところから始まります。その物語は平易な文章で書かれており、特に詰まるところがなく全て理解できている感覚になると思います。おそらく、これ以上同じ文章を読み返そうと思わないはずです。

しかし読み進めていくと、すぐに物語の読み込みが甘かったことに気付かされます。なぜ最初に読んだタイミングで物語を読み返す気にならなかったのか、それは「わかった」状態になってしまったことが原因であるというのがこの書籍の主張です。

「わかった」状態は、ひとつの安定状態です。ある意味、「わからない部分が見つからない」という状態だといってもいいかも知れません。したがって、「わかった」から「よりわかった」へ到る作業の必要性を感じない状態でもあるのです。浅いわかり方から抜け出すことが困難なのは、その状態が「わからない」からではなくて、「わかった」状態だからなのです。

「わかった」状態とは、よくエンジニアでいう「完全に理解した」に近いかもしれません。全てを理解している、いわば全能感に浸っているような感覚です。 ただ、一旦その安定している状態になると、もう一歩深く理解することができなくなってしまいます。

「わかる」から「よりわかる」うえで必要なのは、「わかったつもり」を乗り越えることなのです。「わかったつもり」が、そこから先の探索活動を妨害するからです。

この状態をどう脱していくかは、文章を読む上で非常に重要なポイントになります。

「わかったつもり」を乗り越える方法

「わかったつもり」状態から抜け出す方法がいくつか紹介されています。1つは「矛盾」や「疑問」を見つけることです。一見すると「矛盾」や「疑問」を見つけると、文章の内容を理解できていないネガティブな印象になりがちです。しかし実はその発見が、次の「よりよくわかる」ためのきっかけになることがあります。

「矛盾」や「疑問」は、次の「よりよくわかる」ための契機となるものです。「矛盾」や「疑問」はネガティブに捉えられることも少なくないのですが、むしろ次の解決すべき問題を発見できたという意味で、「認識の進展」という観点からはポジティブな存在なのです。

ここはしっくりくる内容でした。文章を読みながら疑問を見つけると、自分で内容を検証したり、整理して読み直したりしたくなります。文章を素直に読みすぎず、違和感を見つけるプロセスが「よりよくわかる」に繋がるというのは納得感がありました。

この他にも「わかったつもり」状態から抜け出す方法として、要注意ワードを見つけることや文脈を整理することなど、色々なテクニックが紹介されています。本書では、これらのテクニックを実際の題材の文章を読みながら紹介しています。そのため、腑に落ちやすいと思います。

読解とは終わりなき探求

最後に一番刺さった内容を紹介して締めようと思います。

「わかったつもり」の状態から、「わからない」状態などを経由して、「よりよく読めた」状態に移行できれば、それで読みが終わるわけではありません。自分でかなり読めた、読みの進展があったという文章に、しばらくして出会ったとき、そこに、新たな「わからなさ」を見いだしたり、部分間に関連をつける新しい解釈を思いついたりすることは、珍しくありません。(中略) つまり、「よりよく読めた」という状態は、「以前よりはよく読めている状態」かも知れないけれど、その状態を乗り越えるための、もっとよい読みが存在するのです。

文章は一度読んで終わりではありません。特に名著や名文は何度も読み返すことで、その度に新たな発見や学びに気づけるものです。 より良い読み方を学ぶと、新しい本だけではなく、今までの本もまた読みたくなると思います。

ここまで読んで本書の内容を「わかったつもり」になっていませんか? 気になる方は、ぜひ『わかったつもり 読解力がつかない本当の原因』を手に取ってみてください。

ありがとうございました。2024年の"推し"本 Advent Calendar 2024 、次はうーたんさんです。

2024年の"推し"本 Advent Calendar 2024 - Adventar

Google Engineering Practices Documentationを読んだ

先日、会社の同僚の方に勧められて Google Engineering Practices Documentation の Google’s Code Review Guidelinesを読んだ。

google.github.io

このドキュメントは、Googleが様々なプログラミング言語やプロジェクトで培ったベストプラクティスのまとめをオープンソースとして公開しているものである。Google’s Code Review Guidelinesはレビュアー用のガイドとレビュイー用のガイドに分かれている。

ちなみにこのドキュメントには非公式な日本語翻訳もある。自分は基本こっちを読みつつ、わかりにくいところは原著にあたるようにした。

google-engineering-practices.translation.shuuji3.xyz

それぞれ内容も多くなく、全体として数ページしかないのでサクッと読みやすかった。

また内容もコードレビューの基準、期待値、レビューの進め方、レビューのスピード、レビューコメントの書き方など多岐に渡っている。実際に明日から取り入れられるような具体的なHowも書いてあるので、理解しやすかった。またレビュー時の反対意見の書き方や不満が生まれてないような振る舞い方などにも触れている。経験に基づいた内容だと感じた。

明日からできることを考える

このガイドライン守破離の守として、具体的に明日からのコードレビューでできそうなことをNext Actionとして積む。

  • PR に対してシステムが今よりも良い状態になっているのであれば、Approveする。完璧を求めない
  • PR を読むときは diff だけではなく、システム全体のコンテキストから妥当かを判断する。
  • PR に何か優れたところがあったときには、コメントやチャットで伝える。

全部やるのは難しいので、適宜見返しつつやろうと思う。

感想

人間は知ったかぶりをしてしまう生き物だと自覚しておきたいなと思った。

PRを読んでいてなんとなく合ってそうでApproveするには一番避けたいし、ありがちなことだと思う。例えば、よくわからないアーキテクチャや知らないメソッドが出た場合は、その都度調べることができるので理解は進む。しかし、なんとなく知ってるメソッドだったり、他のリポジトリで使われているコードだったりすると、そもそも疑問が湧かない。なので特に調べずに、わかった気になってしまう(結果 Aprprove してしまうこともある)。

エンジニアリングの文脈ではないが、最近読んだ本にも似たような話が書かれていた。

www.kobunsha.com

一歩深いレビューをするためには、自分でもドキュメントを読んだり、実際に手元で動かしたり(動かしたログを読んだり)して、ある種批判的に見て行く必要があると感じた。抗いたい。

要求を整理してリリースまで進める方法を整理する

要求の整理、実装からリリースまでの進め方をまとめました。「参考」にある本を読んだり、1on1 やチームメンバーの動きを見ていて気づいた学びを言語化しておきたいので綴ります。 ここで考えるのは着手する前提のものであって、そもそもの問題設定や問題同士の優先順位を考えることは、スコープ外にします。

※ これが最善ではなく、あくまで現時点でのスナップショットです。

具体的な進め方

問題を理解する(事前条件の整理)

  • 要望を受け取る
    • ユーザーストーリーと Whyを明確にする

  • 要望から要件を整理し、ステークホルダーとエンジニアで要件の合意をする
    • 要望に対してエンジニアはそもそも実現可能か?より実現性の高い方法がないか?のすり合わせを行う
  • 合意を得た要件から仕様を整理する

計画を立てる

  • 仕様を元に実装方針を計画する
    • 実装を進める上で必要なステークホルダーを認識しておく(ドメインエキスパート、SRE、別チームのエンジニアなど)
    • このタイミングで詰めきれていない仕様が発覚した場合は、ドメインエキスパートと仕様の確認・合意を行い、要件を整理し直す
    • 実装方針はチームでレビューを通す
  • 実装できる単位で分割する

実装する

  • 実装方針をもとに実装を行う

振り返る

  • 実装したものが要件を満たしているか確認する
    • 事前条件が変わった時に正しく要件を満たすか(もしくはちゃんと満たさないか)も確認する
    • 例. 正常系だけでなく、雨の日のユースケースが漏れていないか
  • 受け入れテストを行う

補足

  • 順番は大事。一番大事なのは「問題の理解」と「計画」だと思っている。逆にここさえ整理できればエンジニアのボールにできるので、あとはやるだけの状態に落とし込める。
  • 先に実装方針に対してチームのレビューを通すことで、より良いプランを提案されたり、具体的な実装に対して認識が揃い、その後のレビューを通しやすくなるメリットがある。
  • 事前条件の理解が浅い状態で実装を着手することは陥りやすいアンチパターン
    • 人は具体的なことから着手しやすい(要出展)
    • 要件が理解できていない状態で具体的にわかっている実装から着手すると、全体がぶれて手戻りが発生し、結果的にロスタイムが生まれる可能性がある
  • 事前条件が足りず机上の空論で議論して先に進まない場合
    • 具体的なものを見せることで前に進むことが多い。例えばPoCなどの叩きを作ってそれをベースに議論するなどが良い案だと思う。

参考