「DBのバリデーションを確認したいから、このログを正確に255文字で切りたい。」 「フロントの表示崩れをチェックするために、50文字ごとに改行したテストデータが必要だ。」
開発の現場でよくある光景です。しかし、多くのエンジニアがVSCodeの正規表現をいじったり、即席のスクリプトを書いたりして時間を溶かしています。かつての私もそうでした。何より、深夜のデバッグ中に検索して出てきたツールサイトが「眩しすぎる真っ白な画面」で、ダークモードも選べない時、私のストレスは限界に達しました。
iOSアプリ開発に携わる人間として、Appleの洗練されたUXを基準に生きている私にとって、Web上のツールサイトの「使い勝手の悪さ」は看過できない問題でした。「深夜に目を焼かれず、iPhoneアプリのように直感的に、かつ安全にテキストをぶった切りたい。」 その執念が、この 167個のツール を自作させる原動力になりました。
1. 境界値テストにおける「正確さ」という正義
デバッグ作業において、テキスト分割は単なる「見た目の調整」ではありません。システムの「境界値」を突くための重要な工程です。
境界値を手作業で作るリスク
例えば「255文字制限」の入力フォーム。テストすべきは254、255、そしてエラーが期待される256文字です。これを手動コピペで用意していると、全角・半角が混じった瞬間にカウントが狂います。1文字ズレたデータでテストを通しても、それはデバッグとは呼びません。
正確に 「指定した文字数で確実に切る」 道具があれば、こうしたテストデータの作成は数分から数秒へ短縮されます。私はその数分を、より本質的なコード修正に充てたいと考えました。
2. エンジニアが直面する「見えない文字」の罠
単純な分割に見えて、コンピュータの世界はサロゲートペアや改行コードという罠に満ちています。
- サロゲートペアの恐怖: JavaScriptの
lengthでは一部の絵文字が2文字扱いされます。これを考慮せずに切ると、データの末尾が文字化けします。 - 改行コードのノイズ: 分割前に 不要な改行を一括削除 したり、 先頭や末尾の空白をトリミング したりして、データをクリーンにするのが合理的です。
3. シーン別：無駄を削ぎ落とす整形テクニック
現場の「困った」に対して、私は以下の最短ルートを用意しました。
長文を一定間隔で区切る
100文字ごとにカンマを入れる、50文字ごとに改行する。こうした「使い捨てのデータ」を作るためにスクリプトを書くのは非効率の極みです。 指定した文字数ごとに分割 できる環境をブラウザに持っておけば、思考を止めずに作業を継続できます。
JSONや環境変数の可視化
巨大なJSONレスポンスを文字数で切る前に、まずは JSON整形 を行うべきです。また、 .env ファイルを扱うなら envからJSONへの変換 を行うことで、プログラムから扱いやすい形式に落とし込めます。
4. 実行ログすら外部に漏らさない「安全性」への執着
私は心配性です。デバッグで扱うログデータには、時に顧客の機密情報や環境変数が含まれます。
巷に溢れる「便利ツール」の中には、入力データを一度サーバーに送り、向こう側で処理して返すものが存在します。そのデータはどこに保存され、誰が見ているのか？ 私は自分のキャリアをそんな不透明なリスクに晒したくありません。
このツールを使ってみる →
文字数を入れた瞬間に、リアルタイムで分割が実行される。通信は一切発生しない、これが私の設計思想です。
私のサイトのツールはすべて クライアントサイド（JavaScript） で完結しています。入力した長文ログは、あなたのブラウザの外へは1バイトも出ません。 「通信を行うコード自体を書いていない」 ことこそが、エンジニアとしての誠実さだと考えています。
5. 結論：道具に悩む時間は、もう終わりにしよう
開発の現場は、常に時間との戦いです。 「文字数で切りたい」と思ったその瞬間に、環境構築もログインも不要で、手元のブラウザですぐに実行できる。しかもダークモードで目が疲れない。この快適さを一度知ると、もう以前の環境には戻れません。
- 正確にぶった切りたい時: 指定文字数ごとに分割
- データの行数を確認したい時: 行数カウント
- 差分を厳密にチェックしたい時: テキスト差分比較
次にあなたが長大なログを前にして「どう切り分けよう……」と立ち止まった時、私の作ったこの道具箱を思い出してください。手作業の15分を、数秒に変えるために作ったものです。