Typoraエディタ内で画像を自動アップロードする

Typora は僕がとても愛用している markdown エディタで、今まで使ってきた中でこれ以上に使い勝手の良いエディタはないと感じている。複雑なブログ記事はTyporaで書いてからアップロードしている。Typoraには非常に豊富な機能が備わっている。例えば:
- テーブル(Table)のサポート
- LaTeX記法に対応し、数式の記述が容易
- 画像を直接ドラッグ&ドロップして対応するmarkdown記法を生成可能
- iframe、video、rubyなど、多種多様なHTMLタグに対応
- テーマのカスタマイズが可能(CSSで記述)
- ファイルやフォルダの閲覧・切り替え機能が標準搭載
- その他にも様々な便利機能がある
これらのかゆいところに手が届く機能の数々が、僕がTyporaを手放せない理由だ。 しかし、使っていて一つ悩みがあった。それが画像のアップロードだ。なぜなら、Typoraは画像のパスをmarkdown内に挿入するだけだからだ。以下のような記法になる:

このままコピーしてウェブページ上に表示させようとすると、当然画像リンク切れになる。ユーザーが僕のローカルマシンのパスにアクセスできるわけがないので、画像をクラウドやサーバーのストレージ空間にアップロードする必要があるのだ。手動で処理するのは非常に面倒だし、画像サイズが大きいときはアップロード前に圧縮したくなる。操作が一つ増えると思うだけで億劫になり、記事を書く思考の流れも途切れがちになってしまう。
エディタから離れることなく直接画像をアップロードできる方法はないものだろうか、と思わずにはいられなかった。Typora自体、かなり強力な画像のドラッグ&ドロップ操作に対応しているし、ウェブページからのコピペも完全に機能するため、UIとしてはすでに素晴らしい出来なのだ。
そしてついに、これを見つけた:
見た瞬間、衝撃を受けた!この機能を使えば、エディタに画像を配置した際にトリガーする挙動(特定のフォルダへ一括移動させたり、画像をアップロードしたりなど)を設定できる。さらに素晴らしいことに、独自のカスタムコマンドを定義して画像をアップロードできるのだ!

この upload コマンドの中で、画像を圧縮してS3にアップロードし、画像URLを返すようにした。残りのUIやステータスの処理はすべてTypora任せにできる。これで、完全にストレスフリーな画像アップロードが実現できた!
完成後の動作はこんな感じだ:
実装
僕が Github で公開しているコード(Node.jsで記述)を直接参考にしてほしい。実装自体は割とシンプルだが、早く完成させたかったのでパッケージをいくつか組み合わせてサクッと作った。ゼロから自分で作りたい人は自分で書いてみるのもいいだろう。現在のところ S3 へのアップロードのみ対応している。
あとがき
これで僕の人生に新たな扉が開いた。画像の処理が面倒だからという理由で記事を書くのを先延ばしにすることももうない。markdownでの執筆を愛するみんなにぜひシェアしたい。
関連記事
- 測定が目標になるとき:窓税からPull Request数まで かつて僕は小さなツールを自作し、四半期で自分がどれだけPRに貢献したか、レビューコメントをどれだけ残したか、チケットをどれだけ消化したかを集計して、上司にアウトプットを証明しようとしたことがある。上司は淡々と、評価はアウトプットだけで見るものではないと言った。数年後、僕はようやく理解した――測定が目標になるとき、それはもはや良い測定ではなくなるのだ。英国の窓税、ハノイのネズミ駆除の報奨金から、現代のPR数による開発者評価に至るまで、そのメカニズムはまったく同じだ。
- Cloudflare Images を画像ストレージ・変換ソリューションとして使う ウェブページに画像を1枚置くのはフロントエンドにとって最も簡単なことだが、リサイズや各種フォーマットの生成、さらにはトラフィックの負荷に耐えることまで完璧にやろうとすると、実際には一つの包括的なソリューションが必要になる。僕はその後、すべて Cloudflare Images に任せるようになり、オリジナル画像1枚だけを渡すようにしている。
- もう AWS Access Key を使うのはやめよう Access Key は AWS において見落とされがちなセキュリティリスクだ。OIDC と IAM Role を組み合わせることで、GitHub Actions にシークレットを一切保持させることなく、安全に AWS リソースを操作できるようにする。
- データベース主キー:AUTO_INCREMENT、UUID、そしてUUIDv7 バックエンド開発で度々直面する主キーの決定。auto incrementを使うべきか、それともUUIDか?衝突への懸念は?UUIDv7とcreated_at + インデックスの性能差はどれほどか?実際に2,000万件のデータで検証したベンチマークと設計上の意思決定を解説する。