2024年11月30日土曜日

macOS で nexe を使って devcontainers/cli をシングルバイナリにする

前提

  • OS: macOS Sequoia 15.1.1 (24B91)
  • Homebrew インストール済み

前の macOS セットアップ記事の続きから。

Node.js のインストール

brew install nvm
mkdir ~/.nvm
export NVM_DIR="$HOME/.nvm"
[ -s "/opt/homebrew/opt/nvm/nvm.sh" ] && \. "/opt/homebrew/opt/nvm/nvm.sh"  # This loads nvm
[ -s "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm" ] && \. "/opt/homebrew/opt/nvm/etc/bash_completion.d/nvm"  # This loads nvm bash_completion
nvm install v21.7.3

devcontainers/cli のクローン

git clone --depth 1 -b v0.72.0 https://github.com/devcontainers/cli

ビルド

cd cli
yarn
yarn compile-prod
npx nexe --python=/usr/bin/python3 --loglevel="verbose" -i ./devcontainer.js --make="-j8" -r="scripts/updateUID.Dockerfile" -t -b -o ../dist/devcontainer-darwin-arm64-v0.72.0

node 自体に手を入れるらしく、初回に node 自体のビルドが走ります。

マシンスペックによりますが、初回ビルドは 1 時間以上かかることもあるので気長に待ちましょう。

ビルド後の node は保存されるので、 2 回目以降は一瞬です。

ファイルを埋め込んでアクセスしたいなどが無ければ Node 自体の Single Binary Application の仕組みを使う方ががおすすめです(これはこれで新しい node じゃないと無理ですが…)

以上。

おまけ

上記手順でシングルバイナリにしたモノを、以下リポジトリで配布しています。

mikoto2000/devcontainers-cli: Distributing a single executable binary for devcontainer/cli.

参考資料

変更履歴

日付 内容
2024/11/30-1 新規作成
2024/11/30-2 nexe の注意点について追記
Posted by at 0 件のコメント:
Labels: , ,

macOS で Nodejs をビルドする

前提

  • OS: macOS Sequoia 15.1.1 (24B91)
  • Homebrew インストール済み

前回の macOS セットアップ記事の続きから。

Nodejs のクローン

git clone --depth 1 -b v23.3.0 https://github.com/nodejs/node

ビルド

cd node
./configure
make -j8

以上。

参考資料

Posted by at 0 件のコメント:
Labels: ,

2024年11月29日金曜日

M1 mac mini を買ったのでセットアップしていく

この記事はなに？

作っているアプリの macOS での動作確認を行うために M1 Mac を買った。

それのセットアップ記録。

やりたいのは以下。

  • SSH 接続で作業
    • ホスト名で接続したい
  • Docker を使いたい

前提

インストール・初回起動時のセットアップは省略。

  • OS: macOS Sequoia 15.1.1(24B91)

SSH 接続

SSH 接続の有効化

  1. システム設定 -> 一般 -> 共有 -> リモートログイン を ON にする

ホスト名変更

システム設定 -> 一般 -> 共有 -> ローカルホスト名 を変更

ホスト名で接続できるようにする

Windows のネットワーク共有を ON にする。

これで、 Windows の SSH から macOS へホスト名で SSH 接続できるようになった。

Docker のインストール

※ Docker Desktop は SSH 接続のみで使うのに向いていなかったので abiosoft/colima: Container runtimes on macOS (and Linux) with minimal setup を使う事とした。

Applie silicon の Mac - Mac に Docker Desktop をインストール — Docker-docs-ja 24.0 ドキュメント の手順通りに実施。

Rosetta 2 のインストール

macOS のターミナルで、以下コマンドを実行。(SSH 越しにやったらエラーになった…)

softwareupdate --install-rosetta

Docker Desktop for Mac のダウンロード

Get Docker | Docker Docs から Docker Desktop for Mac -> Docker Desktop for Mac with Apple silicon を選択。

docker.dmg がダウンロードされるので、ダブルクリック -> Docker のアイコンを Applications のアイコンにドラッグアンドドロップ。

そのまま Applications のアイコンをダブルクリック -> Docker のアイコンをダブルクリック。

Accept したり、 Use recommended settings を選んだり、 Docker にログインしたりして完了。

Colima のインストール

brew install colima
brew install docker

これで、 colima start 後に docker コマンドが使えるようになる。

その他開発ツールのインストール・設定

GitHub

GitHub CLI のインストール

brew install gh

GitHub に公開鍵を登録

gh auth login

表示されたガイド通りに進めれば OK.

Vim

インストール

brew install vim

dotfile 取得

git clone --recurse git@github.com:mikoto2000/dotvim ~/.vim

参考資料

変更履歴

日付 修正内容
2024/11/29-1 新規作成
2024/11/29-2 「その他開発ツールのインストール・設定」を追加
2024/12/03-1 Docker Desktop for Mac を止めて Colima にしたことを追記
Posted by at 0 件のコメント:
Labels: ,

2024年11月25日月曜日

VimConf 2024 で登壇してきました

この記事はなに？

VimConf 2024 の参加記です。

参加レポートも、「登壇者にしか書けないもの」を求められている空気を感じたので、自分語りをやっていきます。

プロポーザルを出したきっかけ

「タイミングが良かった」に尽きる。

devcontainer.vim - VSCode Dev Container の Vim 版。 を 3 月ごろから作り始めて、9 割満足できるくらい出来上がったところで VimConf 2024 の CfP が公開された。

「devcontainer.vim 自体はただのコマンドラインツールで、作った周辺ツールもただのコマンドラインツール なので Vim の話はほとんどで無いけどいいのかな？」と少し悩んだが、 「まー、僕の考えた最強の Vim 開発環境だし」と思い結局エイヤで出してしまった。

実際に出したプロポーザル

Vim Conf 2024 CfP のやつ 
---
title: Vim Conf 2024 CfP のやつ
author: mikoto2000
date: 2024/7/13
---

mikoto2000@gmail.com



mikoto2000



https://raw.githubusercontent.com/mikoto2000/TIL/master/svg/icon/myicon.svg



Creating the Vim Version of VSCode Dev Container Extension: Why and How



Vim is great. Containers are great too. But combining them is not as easy as VSCode.
We have created a few tools to make it easier to combine them for development.
I will talk about why I made the tool, its overview, how it works, and the challenges I faced.


# 自身について

## 概要

仕事と趣味でプログラミングをやっているプログラマー。
一生を Getting Started の実施で過ごす人。
最近は [Tauri](https://tauri.app/) のベータ版でアプリを作りながら issue や Pull Request を出す生活をしています。

## Vim 活

「自身の使うプラグインは、できるだけ自身がつくったプラグインで済ませる」という挑戦をしている
 LSP や補完系のものはさすがにあきらめたが、その他小粒なツールは自作している

- ファイルエクスプローラー
- バッファーセレクター
- ファイルファインダー
- スニペットジャンプ


# 講演の概要

コンテナ内で Vim を使った開発をするためのツールを作成しました。
(「VSCode Dev container 拡張機能の Vim 版」と放言しています)
そのツールを何故作ったのか？・概要・仕組み・苦労話を話します。
https://github.com/mikoto2000/devcontainer.vim

Vim と何かをインテグレーションする際の一例として、誰かに刺されば良いかなぁと思っています。


# 話すこと

・何を作ったのか？
(仕組みの比較のため)VSCode Dev Container 拡張機能について。
作ったもの(devcontainer.vim)の仕組み説明

・何故作ったのか？
なんでコンテナ内で Vim を使いたいのか？

・解決したい課題と解決方法
初期の方法とその課題
課題を解決するために取った方法
(ツールの作成と、インテグレーション)
どんな方法でどんな課題を解決したのかの説明。

・(時間があれば)作る際の苦労話をいくつか

- NeoVim移行を考えてあきらめた話
- Vim に Pull Request を送った話

# 話さないこと

以下 2 点以外の Vim の機能全て

- channel による TCP 通信
- コマンドライン引数 `-S` による Vim Script の実効


20, 15



Japanese



English


Yes

書き始めたのは 7/13 だったらしい。実際出したのはもっと後のはず…

採択されてから

CfP を出した時点で章立てがほぼ決まっていたので、それに合わせてがりがりとパワーポイントを書いていった。 図を盛り盛りに盛り込んでインクで印をつけながら説明していくスタイル。

結局発表時間が足りなかったので、「時間があったら話すこと」は省略した。

Slack のログを見ると、スライド自体は 10/21 に提出、英語表現や図の表現に関してレビュー・指摘を受けて 10/23 に再提出したようだ。

スピーカーノートまで含めた最終版は 11/6 に提出。

その後は時間を計りながらしゃべりの練習(合計 10 回くらい？)をして、当日を迎えた。

ちょっと練習足らんかったな…。緊張しててもカンペなしでしゃべれるくらいまでやらないと。

当日の様子

登壇前

死ぬほど緊張していた。

登壇

死ぬほど緊張していましたが、スピーカーノートで一命をとりとめました。カンペ大事。

スピーカーノート通りにしゃべれなかった箇所があったり、改善点はあれど、あの時点でのベストは尽くした…

登壇後

魂が抜けた…

席に戻る途中で TJ 氏に「Good session」(うろ覚え)と声をかけてもらえてとてもうれしかった。

懇親会

端っこで人見知りしていたが、何人かの方が話しかけてくれたり、 ツールの仕組みや Dev container に興味を持って質問してくれたりして嬉しかった。

登壇で話せなかったこと

NeoVim に移行しようとしてあきらめた

  • NeoVim は、VSCode と同じく、 UI と実処理をクライアント/サーバーに分けて起動できる
  • クリップボード連携にとても都合の良い構成なので、この機会に NeoVim に移行し、クライアント/サーバー構成を利用しようとした
  • しかし、利用している自作プラグインが、 job_start を多用しており NeoVim で動かなかった
  • せっかくなら Vim/NeoVim 両対応しようと思って修正していたら、別案の clipboard-data-receiver の仕組みの方が先にできてしまった…

Vim に Pull Request を出した話

  • devcontainers が公開している Docker イメージでは、プロンプトに → が使われている
  • ターミナル版 Vim では、 ambiwidth の設定にかかわらず → が半角分の領域で描画される
  • → が描画された行では、リフレッシュが上手く行われず画面にゴミが残りがちになる
  • これが我慢ならずに Vim に改善の Pull Request を出した

なんでここまでしたの？

VSCode Dev Container 拡張機能の Vim 版という事なんですが、

  1. 「VSCode で Dev container が使えるのがうらやましい → コンテナに Vim 突っ込もう」から始まり、
  2. 「コンテナ内で快適に開発したい」となり、
  3. 「周りが VSCode な中で、どうにかこっそり Vim で Dev container したい」になり、
  4. そんなこんなで「Vim で Dev container を利用した開発ができる、かつ、既存 VSCode ユーザーの邪魔にならないようにする」

という仕組みが出来上がった。

devcontainer って便利なの？

この辺りにメリットを感じる人にはフィットするかも。

  • 「開発環境 as Code」ができる
    • 開発環境の構成が devcontainer.json を見ればわかるし、 devcontainer が自動で解釈してくれるので Docker さえインストールしていれば、開発環境の再現が容易になる
  • docker compose ファイルにも対応しているので、複数サーバーが必要な開発環境も構築できる
  • VSCode Dev 拡張機能で利用されている資産を利用できる

devcontainer.vim って便利なの？

devcontainer のメリットに以下をプラスした感じ。 この辺りにメリットを感じる人にはフィットするかも。

  • いつものイメージにそのまま Vim を突っ込めるので、 Dockerfile の作成が不要
  • LS って大体ランタイムと同じ言語で実装されているので、 何も考えずにコンテナ上に LS をインストールできることが多い (私は、コンテナを立ち上げるたびに vim-lsp-settings で LS をインストールしている)

※ Vim から出れないので、 Vim の :sh や :terminal を使いこなせる必要がある

最後に

意外と話したいけど話せなかったことがいっぱいあったな…

devcontainer.vim - VSCode Dev Container の Vim 版。、説明できなかったこまごました機能もあるので、一度 README を読んでみてください！

何か質問があれば @mikoto2000 でもこのブログのコメントでもなんでもよいので聞いていただければと思います。

参考資料

Posted by at 0 件のコメント:
Labels:
登録: 投稿 (Atom)