※スマホ対応はしてません。

カテゴリー: 開発環境

WSL2をインストールしてDocker使ったりUbuntuを変換したり戻したりした。

カテゴリー: 開発環境

これまでも WSL を愛用していたんだけどいよいよ WSL 2 が来たようなので、入れてみました。そんで戻しました。

ちなみに WSL の 1 と 2 はそれぞれ長所短所ある別の仕組みであるらしく、同じ Windows 機に同時にインストールできるみたいです。Docker 使うなら 2 が必要。

本記事の内容

  • WSL 1 を利用中が前提
  • WSL 1 の環境を 2 へ変換する
  • WSL 2 の環境を 1 へ戻す
  • デフォルトで 1 で使うか 2 で使うかの設定
  • Docker は Docker Desktop を使うよ

Windows Terminal

本件とは直接関係ないんだけど、すっげー便利なのでおすすめです。このアプリひとつで Power Shell もコマンドプロンプトも、ついでに WSL で動いてる Linux シェルも開けます。

Windows Terminalで開いたPower Shellからっ更新作業を行う様子
Windows Terminal で Power Shell を開ける。中身は普通の Power Shell のまま。

WSL 2 の用意

Windows バージョンの確認

Windows の設定 (Win+I) → System → About → Windows Specifications を開いて、”Version” の項を確認してください。(最初から version とかで検索しても出てくるはず。) これが最新の 2004 (かそれ以上)である必要があります。

まだなら Windows を更新

OS の Windows Update の画面から更新を何度確認しても降ってこなかったので(そういうものなの?)、インストーラーを探してインストールしました。こちらから。

URL 的に将来再利用されそうだけれど、現時点では最新版 “Windows 10 May 2020 Update” がダウンロードできます。このファイル自体はダウンローダー?なので一瞬で終わるんだけど、それを起動して更新をダウンロード、インストールするのに 30 分くらいかかりました。ほげえ。

なお最新の状態でこのインストーラーを起動しても「今最新版だよ~」と教えてくれるだけなので無害です。

ただし人によってはこれでインストールできない場合もあるらしい。どういうんだろう。

Virtual Machine Platform を有効化

管理者権限で PowerShell を開き、以下を実行します。

> dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

1 分くらい?

カーネルをインストール

この “Download the Linux kernel update package” の節から wsl_update_x64.msi をダウンロード、実行。

Windows Subsystem for Linux Update Setup のウィンドウ
更新はウィザードでぽちぽちするだけ。

WSL 2 を使う

(任意)デフォルトで WSL 2 を利用するように

WSL 1 と 2 を併用できます。Microsoft Store とかでダウンロードした Linux ディストロをインストールするときの初期値をそのどちらにするか設定できるようです。

2 にするなら、こう。

> wsl --set-default-version 2
For information on key differences with WSL 2 please visit https://aka.ms/wsl2

利用中の WSL 1 を 2 へ変換

一覧から名前を得て、その名前を対象に更新します。

まずは一覧を表示して、名前を得ます。この例では “Ubuntu” ですね。

> wsl --list --verbose
  NAME      STATE           VERSION
* Ubuntu    Stopped         1

この名前 “Ubuntu” を覚えておく。

続いて --set-version します。

> wsl --set-version Ubuntu 2
Conversion in progress, this may take a few minutes...
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
…

数分かかるとのことだが 60 分経っても終わりませんでした。ま、まただましたな!

完了したらバージョンが上がったのを確認。

> wsl --list --verbose
  NAME      STATE           VERSION
* Ubuntu    Running         2

使う

あとは普通に使うだけ。やったね。

やっぱり戻す

WSL 側から Windows 側ファイルの監視があやしい。

/mnt/c/User/ginpei 下にプロジェクト配置してるんだけど、どうも watch が怪しい感じがする。かつて普通の VM (VirtualBox) を使ってた頃も同じような問題に直面したような。

新機能は別途試すとして、やっぱり今の環境はそのまま残しておこう……ということにしました。残念。

バージョンをまた変える

さっき WSL 1 → 2 にしたのと同じ手順で 2 → 1 へ変換します。

> wsl --set-version Ubuntu 1

はいこれで元通り。こっちの変換の方が所要時間が少ない様子。

変換にかかる時間

対象は新規にダウンロード、インストールした空っぽの Ubuntu 20.04 LTS です。空っぽだと変換が速いみたい。

WSL のデフォルトを WSL 2 にしているので、2 → 1 → 2 の順番に変換してます。

2 → 1

1 分。

> Measure-Command { wsl --set-version Ubuntu-20.04 1 }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 49
Milliseconds      : 284
Ticks             : 492840008
TotalDays         : 0.000570416675925926
TotalHours        : 0.0136900002222222
TotalMinutes      : 0.821400013333333
TotalSeconds      : 49.2840008
TotalMilliseconds : 49284.0008

1 → 2

4 分。

> Measure-Command { wsl --set-version Ubuntu-20.04 2 }


Days              : 0
Hours             : 0
Minutes           : 3
Seconds           : 42
Milliseconds      : 670
Ticks             : 2226708369
TotalDays         : 0.00257720876041667
TotalHours        : 0.06185301025
TotalMinutes      : 3.711180615
TotalSeconds      : 222.6708369
TotalMilliseconds : 222670.8369

WSL 1 vs 2

表を翻訳して転載。

機能 WSL 1 WSL 2
Windows と Linux の統合
高速起動
省サイズ
Managed VM
完全な Linux カーネル
完全なシステムコール互換性
現行版の VM Ware や VirtualBox と併用
OS のファイルシステム越しのパフォーマンス

(Managed VM って何? 本当の VM だよって意味?)

感覚的には、こんな感じ↓かなと思ってます。正しいですか?

  • WSL 1 は Windows のまま Linux のコマンドを動かす(Cygwin や MinGW みたいな)
  • WSL 2 は Windows とは別に Linux VM を動かす(VM Ware や VirtualBox みたいな)
    • あと、 2 は Windows 10 Home でも使える

Docker

Docker が WSL2 サポート!というニュースだけ耳にしてろくに追ってなかったため勘違いしてたんですが、

WSL2 の中で Docker が完全に動くわけではない

っぽいです。

WSL2 で用意した Ubuntu に Docker を用意してもデーモン起動に失敗しました。

Docker がサポートしたのは WSL2 上の Linux ではなく「WSL2 バックエンド」だそうで、つまり Docker Desktop for Windows を経由してコンテナーを WSL2 の仕組みで実行させる、というものであるらしい。……これで合ってる?

Docker を使う流れ

なので、こんな流れ。

  1. WSL2 準備(本稿)
  2. Docker Desktop インストール
  3. Windows のコマンドプロンプト cmd.exe から docker run hello-world

さっくり動きました。

Docker側がWSL2を利用する設定をオンにするか聞いてくる様子
Docker Desktop を更新すると WSL 2 を使うかどうか聞いてくる。

エラー

管理者権限が必要

Power Shell なり何なりを普通に起動すると、権限を elevate してねと言われます。管理者権限で起動してください。

>dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Error: 740

Elevated permissions are required to run DISM.
Use an elevated command prompt to complete these tasks.

不明なオプション

メモ取り忘れたんだけど、WSL 2 の準備が終わってないと --set-version とか諸々が使えません。( wsl コマンド自体は存在する。)

順にやっていきましょう。

カーネルが古い

「不明なオプション」と同じ。まだ WSL 2 の準備が終わってません。『カーネルをインストール』の節を参照。

> wsl --set-default-version 2
WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel

Docker が使えない

WSL2 で動かしてる Linux の中でも Docker 使えないっぽいです。そうじゃなくて Docker Desktop for Windows 経由で、コンテナーを WSL 2 で走らせます。『Docker』の節を参照。

以下 Ubuntu で試したもの。

$ docker run hello-world
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.

Docker デーモンが動いてない? じゃあ動かそう。

$ sudo systemctl start docker
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

このエラー見たことある……。

$ sudo reboot
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Failed to talk to init daemon.

だめっぽいですね。VM の中に VM はだめ、みたいな。Docker Desktop 経由でやりましょう。

おしまい

仕事は引き続き WSL 1 でやることにします。

とはいえ Docker 使ってやっていきをしたいところ。ファイル監視はな~どうしたら良いかな、気のせいであってほしいけど。

参考

Neovim for Windowsでcolorschemeを置く場所は本体らへん。

カテゴリー: 開発環境

<Neovimインストール先>\share\nvim\colors に foo.vim を置いて、 init.vim で colorscheme foo する。ディレクトリはないので自分で作る。

ちなみにGUI版は <Neovimインストール先>\bin\nvm-qt.exe ね。

ちゃんとやらないとこんなエラー。

E185: Cannot find color scheme 'foo'

当たり前すぎるのか情報が見つからなかった。まあgvimもこんな感じだったっけな。

あんまり関係ないリンク

「Web製作者のためのGitHubの教科書」は非技術者におすすめの本です。

カテゴリー: 開発環境

著者の一人、平木聡さんから頂いてましたので、紹介させて頂きます。

GitHubは年中無休なので、お正月に本書を読みながら諸々を試しておくと、新年の業務がスムーズになるんじゃないすかねー。

概要

  • GitだけでなくGitHubだけの機能も紹介
  • GUIアプリ(SourceTree Win/Mac)とコマンドラインとの両方で作業を解説
  • 画像多数、ちなみに総天然色
  • 言い回しや書体、図解が読みやすい

    (さらに…)

最初にドキュメントから書く話。(JavaScriptおれおれAdvent Calendar 2014 – 17日目)

カテゴリー: 開発環境

JavaScriptおれおれAdvent Calendar 2014 – 17日目

特にライブラリー的なものを作るとき、最初にドキュメントを書くようにしてます。

例えばこれ、まだドキュメントしかないです。

最初にドキュメントを書く効能

もちろん後で書く手間が省けるってのもあるけど、それより、最初にAPIのリファレンスを作る事で、成果物の最終形が明確になります。最終形が分かっていれば、ごりごり書いてそれに近づけるだけっすね。

APIが決まっていれば試験を書ける、試験が書ければリファクターができる、リファクターができれば雑なコードでも実装を進められる。とまあそんな感じ。

もしここで明確な最終形を記述できなかったとしたら、それは現時点ではまだ何を作れば良いかわかっていないという事になるでしょう。それだとコードも書けない。

モジュールでも同じように

製品内の部品を作る場合も、同じように最終形を最初に考えます。これはいちいちドキュメント作成したりはしない場面が多いけど、脳内には用意しておく。必要ならメモ書きくらいは作っても良い。

理由は前述のものと同じで、これから何を作るのかを確認するため。

書く内容

短い紹介文が欲しい。というかそれが一番大事だと思う。端的な紹介文はこれが「何であるか」だけでなく「何でないか」も表現し得るので、方向性を定めやすい。

あとはリファレンスと使用例。例は具体的な利用場面も想定できるとなお良し。

別に変更してもいい

実装コードを書いてから気付く(あるいは単純に思い出す)事もあるので、最初に作った仕様を厳守するというわけじゃないです。

あと十分に先が見えていないと最終形を定める事はできず、こういう形で作業を進めるのは無理ですね。そういうときは適当にそれっぽいものを作って、触って、捨てて作り直して、を繰り返す。新しい何かを作るときはそうなりがちだと思う。

ただ、思想については曲げずに進めたいなと。

まあ

言うほど毎回しっかりやってるわけでもないんだけど……。理想的な働き方みたいなもの。

EditorConfigで文字コード設定を共有して喧嘩しなくなる話。(Frontrend Advent Calendar 2014 – 14日目)

カテゴリー: 開発環境

edcon_color_transbg2_400x400

Frontrend Advent Calendar 2014の14日目の記事です。

ご存知ですか、EditorConfig。

便利すぎてほんのり涙出てくるくらいなんですが、いまいち周囲で聞かないので流行っていないのではないかと思います。是非とも流行らせてください。平和のために!!

フロントエンドにあんま関係ない代物だけど、改行コード絡みで恨みつらみを聞く機会が多い気がするのでご容赦くださいまし。

なにそれ

様々なエディターで利用できる、共通の書式設定ファイルです。”.editorconfig”というファイルをプロジェクトのルートに配置しておくだけで、エンコード等の書式をそのディレクトリー配下のファイル編集時に固定できます。

もちろん設定自体は各エディターでやってもらえば良いんだけど、やっぱりほら、好みとかもあるわけじゃないですか。プロジェクトごとに設定変えるとかやってられないし。

サイト

こちらです。

設定

こんな項目を設定できます。

  • 文字コード
  • 改行コード
  • インデント

これでwinとmacと両方からファイルをいじっても「めっちゃ文字化けしとる! ふざけんな!!」とか「なんか^Mが行末にくっついてる! しね!!」とか「ここだけインデントがタブじゃねーか! やろう、ぶっころしてやる。」とか、そういう喧嘩がなくなりますね。平和万歳!

bukkoro
じぶんどうしのあらそいは、みにくいものだ。

他にも余分な空白を除去するとかそういう設定があります。

対応エディター

それぞれのプラグインで対応する感じです。

主要なところでは以下で利用可能です。

  • Atom
  • Brackets
  • Emacs
  • IntelliJ
  • Sublime Text
  • Vim
  • MS Visual Studio

plugins
多数のエディターに(各プラグインが)対応。

んあーCodaやEclipseはないのかな。対応してよーっていう要望だけ見つかった。

設定

プラグインのインストールはエディターごとに違うので、それぞれの配布ページの記述をご覧ください。

で、ファイルは例えばこんな感じ。

root = true

[*]
end_of_line = lf
charset = utf-8
indent_style = tab
indent_size = 2

これは私個人が通常利用している設定です。

ファイルの文法はMS-DOSのiniファイルのやつ? 手元のvimだと”dosini”という名前のシンタックスハイライトが有効になりました。

root=true

.htaccessみたいに、.editorconfigもディレクトリーごとに入れ子(?)にして配置する事ができます。で、その上位ディレクトリーを見に行くのを止める設定が、これ。なければファイルシステムのルートまで遡るのかな。

プロジェクトディレクトリーのルートに配置する場合は書いておきましょう。

ファイル

[*]はファイル名のセクションで、全てのファイルを対象に設定しました。

ここで拡張子やファイル名を指定できます。例えば、前述の設定に加えHTMLだけはインデントにスペースを使いたいなぁーという場合は、追加してこんな感じにします。

root = true

[*]
end_of_line = lf
charset = utf-8
indent_style = tab
indent_size = 2

[*.html]
indent_style = space

他にもディレクトリーを指定したり、個別のファイル名でも指定可能です。

いくつかの個別ファイルで同じ設定を使用する場合は”{}”を利用し、”,”で区切って指定します。

[{package.json,bower.json,Gemfile}]
indent_size = 4

コメント

“#”で始めるとコメントになるみたいです。

リファレンス

そんなに量もないから書いちゃおう。

ファイル名指定

ファイル名の指定では以下のパターンが利用可能です。

記述 説明
* 任意の文字列、ただしパス区切り子”/”を除く
** 任意の文字列
? 任意の1文字
name “name”という名前のファイル
!name “name”という名前でないファイル
{s1,s2,s3} “s1”, “s2”, “s3″という名前のファイル

ファイル名指定はどのディレクトリーにあっても合致します。(つまり”*.js”ならどの階層のJSファイルでも有効。) もし.editorconfigと同じディレクトリーのファイルだけを指定する場合は[./*]のような指定になります。

複数指定とワイルドカードは一緒に使えない模様。あ、でもプラグインに依るかも。

設定

項目名は全て小文字。値に引用符は不要です。また値を空白にしておく事も可能です。

記述 値 説明
charset “latin1”, “utf-8”, “utf-8-bom”, “utf-16be” “utf-16le” 文字コード
end_of_line “lf”, “cr”, “crlf” 改行コード
indent_size 整数 インデントの各階層の幅
indent_style “tab”, “space” インデントの種類
insert_final_newline “true”, “false” 末尾に空行を追加
root “true” このファイルより上位の設定を検索しない。必ず先頭に記述する
tab_width 整数 タブ文字の幅。indent_sizeより優先される。省略時はindent_size
trim_trailing_whitespace “true”, “false” 行末の空白を除去

文字コードにShift JISはないみたい。まあ日本専用の文字コードだしな。

いつまでも幸せに開発を続けましたとさ

めでたし、めでたし。とっぴんぱらりのぷう。

参考