スキップしてメイン コンテンツに移動

開発環境の羅列 2023 秋

開発環境の羅列 2023 秋

自分の現在の開発環境について適当に羅列する。備忘録的な感じ。

OS

  • Windows 11
    • WSL2 on Ubuntu
  • Mac OS X

OS に関しては、メイン端末は Windows 11 に WSL2 を入れて、そこで Ubuntu を走らせている。 日常のメモ書きから、プログラム開発まですべて WSL2 上の Ubuntu でカバーできている。 もしかして、Windows11 無くても生きていけるのではという錯覚に陥りがちだが、Word、Excel、PowerPoint を編集する作業があるので、多分、まだまだ Windows は必要。

Max OS X に関しては、Intel Mac のマシンを 11 年近く使っている。やべー。 こんなに長く使う予定は無かったのにどうして……。 でも、Mac 環境が無いと Safari の動作が確認できなかったりするので、しばらくは Mac は必要だろう。 M1 Mac 欲しいなぁ。

Terminal

Terminal に関しては、WezTerm に乗り換えてからずっと使っている。Win/Mac 共に使えるのが良いことと、同じ設定が使えるので愛用している。 今のところ、特に不満なく使っている

Editor

エディタに関しては、相変わらず Vim を使っている……ように見せかけて、完全に Neovim へ移行した。これは、Shougo-wareをメインで使っている関係上、Vim で四苦八苦するより、Neovim でぺちぺちやった方が早く環境構築が出来るからだ。 Neovim だから良いという訳ではないが、積極的に Vim を選ばなくても良い時代になったと言える。 ちなみに、エディタの起動時間は、WezTerm を立ち上げて、nvim とタイプして起動するまで 5 秒掛からない。この起動速度+十分に精錬された開発環境は VSCode を上回っている。LSP も有効化しているので、VSCode を積極的に使う理由が、今のところ僕には無い。流石に今のマシンスペックだと、VSCode は 10 秒で起動するので、たかが 5 秒くらいと言われるかもしれないので、起動速度が速い!すごい!とは言い切れないのが現状。実は、VSCode で開発したほうがもっと開発効率が良くなる可能性は全然ありますからね……。 僕がただ気がついていないだけで。 denops 経由での ddu がすげー快適なので、当分はこっちを使うんだと思う。 Fern のお陰で、ファイラー関連も快適だしなぁ。 VSCode で Shougo-ware が動くようになったら呼んで。

Language

開発言語は、JavaScript 系列に偏っていて、Node.js と deno を愛用している。 と言っても、最近は実質的に TypeScript の軍門に下ったと言える。 後述する Next.js 門下に下ったのが大きな要因。

Builder

これらをなんと名付けるか微妙だが、まあ、Builder というのが一番近いかな。 npm も yarn も pnpm も bun も全部使っている。 npm は以前死ぬほど遅かったが、最近は割りとストレス無く使える速度になっている。yarn もそこそこの早さなので、特に理由がない場合は yarn を使っている。 pnpm はプロジェクトによって採用されているので、使うことがある。 最近、bun を使い始めたけれど、bun install がめちゃくちゃ速いので、まだ体験していない人は体験するとびっくりすると思う。 Vite は一時期使っていたけれど、最近はめったに使わなくなったなぁ。

Framework

React か Vue かの論争は未だにあると思うけれど、僕は React を選んだ。 ただ、それだけ。というより、Next.js があまりにも便利すぎた。 フロントでやりたいことはかなりやってくれる。すごい。 もちろん、Nuxt でも同じことは出来るので、好みの問題。 というより、Next.js と Vercel の組み合わせによる開発体験があまりにも良すぎて、他のツールを使う気になれない。つまりそういう事だ。 あと、React も useState がすごい使いやすくて、これによって開発体験がまるっと変わった。 やりたいことの大体が React で表現出来る(当たり前だけれど)。そして、学習コストもそこまで高くない(素の JS を組むより楽)ので、もし、新たにプロジェクトを立ち上げる時は、React ベースの開発をおすすめする。 癖が強いけれども、Next.js の app router/page router 当たりを使いこなせるようになると、途端に Next.js への評価が爆発的に上がるようになる。CORS 気にしなくて良いのは相当に楽。 問題点を挙げるとすれば、File のアップロードを実装するのが大変だった。特に page router はむずかった。 逆に、app router だとシンプルに書けたので、Next13 で app router へ移行できる人は早めに移行すると良い。 変な Tips を覚えなくて済むし、素直にバックエンドへの中継処理が書ける。

Hosting

Hosting に関しては他にも、Firebase や AWS の EC2 を使うとかまあ、色々あるけれど、現状は Vercel が一番強い。Netlify でも一応運用してるんだけれど、Vercel の方が圧倒的に使い勝手が良いし、快適。Firebase の Hosting はクセが強くて、Google っぽいなーって感じ。EC2 やっても良いけれど、自前でゴリゴリ設定書くの正直面倒だから、その辺をまるっとやってくれる Vercel や Netlify はフロントエンドの置き場として最高だと思っている。 バックエンドをどこに置くか問題は抱えているけれど、そこは腕の見せどころでしょ。

CSS Framework

CSS Framework と言ったら嘘になるけれど、React と組み合わせならどっちかが良い。 デザインセンスが皆無の人ならば、MUI の方が設定項目少なくてもいい感じにしてくれるから、使いやすいかも。でも、MUI の枠をちょっと超えた事をやろうとすると途端に面倒になる。 TailwindCSS はその点、MUI よりナチュラルに書けるイメージ。 ゼロからコンポーネントを作っていきたい場合は、TailwindCSS はとても魅力的。 ただ、出回っている TailwindCSS のデザインはダサいと思われつつあるので、MUI の方が精錬されているという評価を受けやすい。 なんでや。

Browser

メインブラウザは Vivaldi。本気の広告ブロックを搭載してる、思想強めブラウザ。実質 Google Chrome。開発の際は、Google Chrome メインで開発している。Firefox は完成後にチェックするようとしていつも立ち上げている。皆さん、知っていますか?最近の Firefox マジで速いんですよ。Rust 導入の恩恵を受けているのが伝わる。もしかしたら、メインブラウザにのし上がってくるかもしれない。 Safari は、最終確認用。正直、ほとんど立ち上げない。でも、こっちで確認しないとバグってる事がまれにあって、マジでこいつは現代の問題児。

まとめ

一応まとめてみたが、去年からの進展はほぼ無い。去年が激動過ぎたとも言える。 この中では、やっぱり bun の衝撃度が一番大きい。bun install がとにかく早くて、ストレスが相当減る。 今後も、自分の開発環境をまとめて晒していきたいと思う。

コメント

このブログの人気の投稿

EFIブートローダを移動した話

EFIブートローダを移動した HX90に環境を整え終わってから、アホな事をしたので、その記録を残す。 SSD: Cドライブ SSD: Dドライブ(データストレージ用) + ESP※ SSD: Eドライブ(データストレージ用) ※ESP(EFI System Partition) インストールした時、こんな構成だった。 ESPがDドライブにあるのが気持ち悪かったので、これを削除した。 そしたら、BIOS画面が出るだけになり、Windowsが起動しなくなった。 移動手順 この時の自分はMBRをふっ飛ばした時と同じ現象だと思ったので、MBRというキーワードで検索したが、今はEFIブートローダーと呼んでいるらしい。 【Win10】任意のディスクにEFIブートローダをインストールする 色々検索した結果この記事が参考になった。 Diskpartを使って、パーティションを新たに分割し、bcdbootを実行して、無事に事なきを得た。 パーティションの分割はこんな感じ Diskpart Select volume 0 shrink desired = 200 Select disk 0 Create partition EFI size=200 Format quick fs=fat32 label="ESP" Assign letter=P exit EFIブートローダーのインストールはこんな感じ bcdboot C:\Windows /s P: /f UEFI ちなみに、自分の環境だけの問題なのだが、コマンドラインで、「\」を入力するのができなかった。我が家のキーボードはHHKBだけなので、日本語配列を無理やり適用されると、バックスラッシュが入力できないという不具合が生じる。 結局、コマンドプロンプトからマウスで範囲選択してコピーして貼り付けるという荒業でクリアした。 普通の人は、何も考えずに、\を入力すれば良い。 最終的に SSD: Cドライブ + ESP※ SSD: Dドライブ(データストレージ用) SSD: Eドライブ(データストレージ用) ※ESP(EFI System Partition) という構成に切り替えることができた。

Windows版gVimをアンインストールした日

Windows 版 gVim をアンインストールした話 以前に、 Windows11 on WSL2 + wezterm + Neovim = 最強開発環境 という痛々しい記事を書いたのだが、その続きの記事と言っても過言ではない。 この記事は Vim 駅伝 の 3 月 1 日の記事である。 前回はぺりーさんの netrw を使うために という記事だった。 次回は kuuote さんの Vim 側の組み込みプラグインを無効化するハック という記事である。 gVim との付き合い 思い返してみると、gVim との付き合いは大分長くなった。エディタとしては 自分の人生の中で最も長く付き合ってきたエディタ と言える。Vim のインターフェースとして gVim を何度も使ってきた。自分の手持ちのマシンは Windows なので、必然的に gVim を選択肢として選ぶ必要があった。 gVim の良さは何か。それは、Windows とのシームレスな関係であり、Windows OS の機能をそのまま使いたい場合に有用である。かつての自分にとってこの部分は非常に重要であった。具体的には、印刷機能と画面半透明化機能であり、これが無いとやってられないという認識であった。 しかし、時代が進み、自分の技術力の向上や考え方の変化、さらに Vim 周りのプラグインの更新が進むと gVim で運用していく事がだんだんと億劫になっていったというのが事実である。故に、 WSL2 上で動く Neovim の快適さに心が打ち震えた のである。 技術力の向上に伴う考え方の変化 かつての自分は 何でも gVim で処理したいな と考えていた。メールを見たり天気を見たり、Twitter を見たりするのに、gVim を活用していた。かつての Emacs 使いの guru のような立ち位置を目指していたというのがある。2000 年代初頭にインターネットに多少なりとも触れていた人ならば、「それ Pla」という古の単語を思い浮かべるかもしれない。この概念を持ち出すのはあまりにも古すぎるが、結局言いたいのは、 1 つの手法で全部をこなす という考え方だ。ネットを見るのにわざわざブラウザに切り替えるのはもったいないという今となっては情熱に似た何かを当時は多くの人が持っていた。 しかし、自分自身の技術力

javascriptは外部ファイルにした方がいいの?それとも、インラインの方が良いの?

事の発端 os0xさんのブログコメント で、javascriptの書き方について、面白いやり取りがありましたので、それについての私見を書きたいと思います。 結論から言いますと、プログラマ的な立場から言わせて頂くと、外部ファイル管理が望ましく、コーダ的な立場から言わせていただくとインラインが望ましいです。 なぜそのような結論に至ったのか、まずは経緯を御覧ください。 コメント欄でのやり取り os0xさんのブログコメント欄を引用しています