2025-07-17

RustでCSVをJSONに変換するツールをリリースしました

概要

最近、Rustを使って、CSVをJSONに変換するツールをリリースしました。

ctj - crates.io: Rust Package Registry

cargo install ctjですぐインストールして使うことができます。

2025-07-17現在のバージョンは0.1.8。ちょこちょこ機能を追加しています

このツールを作った理由について、簡単に書いてみたいと思います。

作った理由

一言でいうと、ヘッダ行がないCSVファイルにも対応をしたかったのが一番大きな理由です。他のツールを使うと情報が欠落することがありました。

また、CSVの真偽値や数値について、ツール側で文字列に変換されるのが困っていました。

具体的には…？

,b,
,,FALSE
,55.5,

このようなファイルがあったとき、別のツールを使うと次のような結果になります。

[
  {
    "": "FALSE",
    "b": ""
  },
  {
    "": "",
    "b": "55.5"
  }
]

大文字のFALSEがそのまま文字列として扱われています。また、55.5という数値も文字列になってしまっています。

真偽値と数値はそのままJSONで扱えるので、できればその型情報を識別し、同じように展開したいです。

それでは自分が新たに作成したツールを紹介しましょう。このctjを使うと、次のような結果になります。

[
  {
    "": false,
    "b": ""
  },
  {
    "": "",
    "b": 55.5
  }
]

FALSEはfalseに、55.5は数値（float）として扱われます（小数点が無ければintegerとして処理されます）。

また、今回のCSVファイルはヘッダ行がありません。このような状況は実際にあり得ると思います。ヘッダ行がないと、情報の欠落が生じるリスクが高まります。

そのユースケースに対応するため、オプションを用意しました。--no-headerをつけると、ヘッダ行がないことを ctj に伝えられるため、このように出力できます。

[
  {
    "column_0": "",
    "column_1": "b",
    "column_2": ""
  },
  {
    "column_0": "",
    "column_1": "",
    "column_2": false
  },
  {
    "column_0": "",
    "column_1": 55.5,
    "column_2": ""
  }
]

何列目にどの情報が入力されていたのか、すぐに把握できます。

無事に変換時の情報の欠落を防ぐという目的を達成することができました！

おわりに

あえて機能はシンプルにしつつ、実務に活かせるように設計してみました。すでにあるCSVファイルだけでなく、パイプで渡した文字列を処理することも可能です。

CSVをJSONに変換するツールを探している方は、ぜひ使ってみてください。コントリビュートも歓迎です！

github.com

2025-07-05

開発生産性Conference 2025に行きました！

開発生産性Conference2025に行きました！

何よりも嬉しかったのが、やはりKent Beckさん御本人にお会いできたことです。自分がプログラミングの学習をし始めてから、アジャイルソフトウェア開発宣言をはじめとして、色んなところで名前を聞いていた伝説的な人物の講演を、肉眼で見ることができたのは僥倖でした。

発表はほとんどスライドを使わず、身振り手振りを用いながら行われており、壇上の左から右へと歩きながら喋っていくスタイルでした。

内容については、jgeemさんやginkounoさんがまとめてくださった、こちらの資料に詳しく書いてあります。

scrapbox.io

note.com

「プレッシャーではなく、気づきを促す」。自分も将来教育する立場に回ったときは、このことを強く意識したいと思いました。

講演のあとにはサイン会がありました。拙い英語でしたが、直接Kent Beckさんに感謝を伝えることができて嬉しかったです。timer.teamのカードも直接お渡しできました。

（サイン会のときにはできなかったのですが、翌日たまたまKent Beckさんが会場の廊下で佇んでいて、握手してもらいました！🤝）

また、お一人お一人を挙げると長くなってしまうので省略しますが、他のイベントや仕事でもお世話になっているRubyistの方々にお会いすることもできました。RubyとAgileの結びつきについて再確認する機会になりました。

今回、このような貴重な機会に参加することができて、本当に良かったです。イベントを主催してくださった皆様、お話ししてくださった皆様、ありがとうございました。

2025-06-22

Railsで別ファイルに切り出さずに、Viewのプライベートなpartialを実装する

結論

captureメソッドとprocを使おう！

経緯

部分テンプレート（partial）はとても便利な機能ですが、使いすぎるとコードが少し散らかってしまいます。

たった1つのViewファイルで使うためだけの場合でも、_foo.html.erb や_bar.html.erbといったファイルが増えてしまいます。それにもかかわらず、これらのファイルはどのViewからも呼び出せてしまいます（スコープが広いです）。

また、複数のファイルを行ったり来たりする手間もかかります。

例えばReactの場合では、単一ファイルの中でコンポーネントを分割することができます。このような機能をRailsのView（erb, haml, slim）でも実装する方法があるので共有します。

実装方法

結論に書いたように、captureメソッドとprocを使います。

captureメソッドについてはRailsガイドのこちらに説明があります。

railsguides.jp

captureメソッドを使うと、以下のようにテンプレートの一部を抽出して変数にキャプチャできます。

このcaputreメソッドを、procと組み合わせます。

docs.ruby-lang.org

２つを組み合わせて、次のようなコードにします。

<%# --- 定義：UIの断片を Proc オブジェクトに束ねる --- %>
<% row = proc do |user| %>
  <tr>
    <td><%= user.name %></td>
    <td><%= user.email %></td>
  </tr>
<% end %>

<%# --- 呼び出し： capture ヘルパーで Proc を評価・描画する --- %>
<table>
  <% @users.each do |user| %>
    <%= capture(user, &row) %>
  <% end %>
</table>

この方法によって、UIの断片を別ファイルに切り出すことなく、プライベートなpartialを実現できます。

もちろん、次のように複数の引数を渡すことも可能です。

<% row = proc do |user, book| %>
  <tr>
    <td><%= user.name  %></td>
    <td><%= book.title %></td>
  </tr>
<% end %>

<%= capture(current_user, featured_book, &row) %>

具体例

例えばこのようなerbを書きます。

<h1>Products</h1>

<%# --- 定義：テンプレート断片を Proc に束ねる --- %>
<% render_product = proc do |product| %>
  <div class="product">
    <h2><%= product.name %></h2>
    <p><%= product.description %></p>
    <span>¥<%= product.price %></span>
  </div>
<% end %>

<%# --- 1回目の呼び出し：通常の一覧表示 --- %>
<div id="products">
  <% @products.each do |product| %>
    <%= capture(product, &render_product) %>
  <% end %>
</div>

<%# --- 2回目の呼び出し：おすすめ商品セクション --- %>
<h2>Recommended Products</h2>
<div id="recommended">
  <% @products.select(&:recommended?).each do |product| %>
    <%= capture(product, &render_product) %>
  <% end %>
</div>

データを用意してCSSをつけると、次の画像のように表示されます。

おわりに

この方法が一般的かは分かりませんが、一つのファイル内でプライベートなpartialを実装したいときに便利です。外部のGemや、複雑な実装をおこなうことなく、RubyとRailsの基本的な機能のみで実現できます。

（もしかしたらもっと良い方法があるかもしれないので、お気軽にコメントください！）

えにしテック内のSlackでtmaedaさんとdarashiさんに頂いたコメントが、この記事のアイデアの元でした。この場を借りて感謝いたします🙏

2025-04-23

「私が知る最高のプログラマーの習慣」という記事が良かった

endler.dev

The Best Programmers I Know | Matthias Endler

こちらの記事、Hacker Newsでたまたま見つけたのですが、とても良かったので紹介します。

素晴らしいプログラマーの習慣として、次の項目が挙げられていました。

公式リファレンスを読もう
使うツール（道具）に熟知しよう
エラーメッセージを読もう
課題を分解しよう
コードに触れることに恐れない
チームのみんなを助けよう
良い文章を書こう
学び続けよう
地位を気にしない
信頼を築く
忍耐力を持つ
コンピュータを責めない
「分からない」と言うことを恐れない
推測しない（調査する）
シンプルに保つ

見出しを元にざっとまとめてみました。どの項目も的確で、指針になる内容だと思いました。

個人的に面白かったところをピックアップしてみます。

「使うツールに熟知しよう」という項目は、えにしテック社内でもよく言われていることです。ツールを使いこなすために、そのツールが「なぜ」作られたのかという根本的なところを意識して、掘り下げながら習得していく。表面上の使い方を知るだけではなく、背景や仕組みを理解することで、熟達の道につながります。

「コードに触れることに恐れない」。実際に自分の手でコードを書いたり読んだりしないと、分からない面は多いです。例えばむかしCSSに苦手意識がありましたが、自分の手で色々実験した結果、少しずつ体系的に理解が深まってきた気がします。自分が苦手かもという思う領域も敬遠せずに、コードに触れて色々実験するのは大切です。

「良い文章を書こう」。これは37signalsの本にも書かれていましたが、テキストで情報を伝達することはとても大切です。他者とのコミュニケーションを潤滑にする役割だけでなく、最近はLLMとのインターフェイスという点でも重要になってくると思います。

「地位を気にしない」。お互いの地位を気にしなくて済むチームは、心理的安全性も高いです。また自由な発想も出てきますし、意見が出しやすい環境になります。Googleの研究でも心理的安全性の効果が示されていました。

www.businessinsider.jp

グーグルが行なった「最高のチームをつくる」調査の意外な結果。メンバーは重要ではなかった | Business Insider Japan

「信頼を築く」。Reputationを敢えて「信頼」と訳してみました（評判・名声・信用などの多義的な言葉です）。アジャイル開発で大切にされている習慣として、「信頼貯金」という概念があります。角谷さんの記事に詳しく書かれていますが、チームのこれまでの習慣を変えたい、新しいプラクティスを導入したい、などと言った漸進的な組織づくりにはお互いの信頼が必要です。

gihyo.jp

最終回　信頼貯金を増やす | gihyo.jp

「推測をしない（計測や調査をする）」。これはロバート・C・パイクの五箇条が元ネタですが、色んな場面で引用されています。思いつきで行動をするのではなく、まずは数値を計測して客観的なデータを出してから行動に移る。定量的な指標（数字）で考える大切さについては、まつもとゆきひろさんのこちらの記事が素晴らしいのでおすすめです。

logmi.jp

エンジニアは推測するな、計測せよ　まつもとゆきひろ氏が説く、非機能要件で数字を重視すべき理由 | ログミーBusiness

「シンプルに保つ」。複数の解法があったとき、迷ったときはできるだけシンプルな方法で解決を試みる。一度複雑化してしまったコードベースを、スッキリとリファクタリングするのは大変です。なのでシンプルなコードを保って、技術的負債を溜めないことが、長期的な開発を可能とし、ユーザーへの価値提供に繋がります。

例えばRuby on Railsというフレームワークでは、Rails Wayという考え方があります。これは、フレームワークが推奨するアーキテクチャのデフォルトに可能な限り従いつつ、ソフトウェアを育てていく方法論です。シンプルさを保ちながら、いかにスケールさせていくかがテーマであり、探求しがいのある設計論となっています。

youtu.be

基調講演 | Kaigi on Rails 2024

最近えにしテック社内で読んでいる Sandi Metzさんの『99 Bottles of OOP』は、コスト効率が高く、保守しやすく、満足のいくコードを書くことについて掘り下げられていてとても面白いです。JavaScript, PHP, Python, Rubyなど様々な言語版を一度に読めるので、気になった方はぜひ読んでみることをオススメします。

sandimetz.com

99 Bottles — Sandi Metz

と、見出しから連想したことをつらつらと書いてみました。

最高のプログラマーになるためには、こうした基本をきっちり実践していくことが大事だと改めて意識させられた記事でした。🌱

（もちろん、頭ではわかっていても、恐怖を克服するのは難しいですが）

ちなみに、もし自分が上の項目に付け加えるならば……

――アウトプットを続けよう

そして

――最後まで作り切ろう

自戒を込めて。

2025-03-31

【VSCode】erbのコードをctrl + /で簡単にコメントアウトする方法【Ruby on Rails】

結論

この拡張機能を使おう！

marketplace.visualstudio.com

https://marketplace.visualstudio.com/items?itemName=setobiralo.erb-commenter

経緯

VSCodeでerbのファイル内でRubyの部分を、ctrl + /（もしくはcommand + /）でうまくコメントアウトすることができませんでした

具体的にはこんな感じで変なふうになります。

あーっ、これはいけません。

というわけで先程の拡張機能を導入しましょう。

もういちどctrl + /でコメントアウトします。

するとどうでしょう。うまく全部コメントアウトできます！

ちなみに、複数行でも大丈夫です。HTMLのところとRubyのところをうまい感じに切り替えてくれます。

というわけで便利なのでerbを使う方はぜひ試してみましょう！

marketplace.visualstudio.com

2025-03-06

過去の Pull Request の diff を CLI 上で確認する方法（マージコミット）

チーム開発をしていて、特定のマージコミットの diff のみを手元で確認したいときがあります。

言い換えると、過去の GitHub の PR の差分だけを表示したいときです。ブラウザ上で見ることはできますが、CLI でも確認したいときがたまにあります。

というわけで方法を調べました。

まず PR 番号で検索を掛けます。--mergesオプションを使ってマージコミットのみを探します。

git log --merges --grep="#11111"

するとこんな感じで対象のマージコミットが見つかります。

commit hogehogehoge (main)
Merge: foo bar
Author: LEF <777777+hoge@users.noreply.github.com>
Date:   Tue Feb 25 22:36:59 2025 +0900

    Merge pull request #11111 from lef237/title
    
    Title

あとはマージ前の親コミットと、対象のコミットを^を使って比較します。

git diff hogehogehoge^ hogehogehoge

これだけ！　便利なのでおすすめです。🐘

追記（2025-05-29）

よくよく調べると他の方法もあることが分かりました。

ghコマンドが使えるなら、gh pr diff 12345で良さそうです。

cli.github.com

あるいは、こんな感じでgitのaliasを設定するのも手です。

ghに依存しないですし、作業が簡単になります。オススメ！

  prdiff = "!f() { \
    sha=$(git log --merges -E -n1 \
      --grep=\"^Merge pull request #$1([^0-9]|\\$)\" \
      --format=%H); \
    test -n \"$sha\" && git show -m --color \"$sha\"; \
  }; f"