MacOSにYeomanをインストールした時に発生したエラーへの対応

VS Codeのエクステンションを開発しようと、Yeomanをインストールしていた時にパーミッションで怒られた。

Step 1: Set up your dev environment | Yeoman

パーミッションというとなんとなくsudoコマンドで管理権限を実行し、解決してしまいそうだが、上記のドキュメントをよく読むと、sudoを使うのは悪手のような記述があり、リンク先の方法で解決した。

guides/npm-global-without-sudo.md at master · sindresorhus/guides · GitHub

ホームディレクトリ配下に.npm-packagesというパッケージ格納ディレクトリを作って、ここで管理するようだ。グローバルな環境に影響を与えないので、この方が良いということなのだろう、ということは想像できる。

ボリューム名が重複したディスクのLVMボリュームをマウントする

どんな問題だったか

メンテナンスしようとしてpvscan、lvscanしてみると、名前が重複していた。

PV /dev/sdb  VG tank lvm [5.46TiB / 0 free]
PV /dev/sda  VG tank lvm [5.46TiB / 0 free]

lvscan

inactive /dev/tank/tv
ACTIVE /dev/tank/tv

どうしたか

vgdisplayでVG UUIDを調べる

（略）
VG UUID               tHyFVt-lnWm-19Gu-Bhea-29lv-6Xf6-xxxxxx

vgrename でUUIDを指定して名前を変える

vgrename tHyFVt-lnWm-19Gu-Bhea-29lv-6Xf6-xxxxxx VolGroupHoge

（successfullyと表示されればOK）

vgchangeでActivateしてマウントして解決した。

私の批判に対する心の保ち方

ソニックガーデンの倉貫さんの記事を受け、私が感じたことと、私なりの安寧の保ち方を少し書きたいと思った。

倉貫さんの心の保ち方

倉貫さんの記事は以下より。
medium.com

なかでも今まで知らなくて、なるほど、と思ったのがゲニウスのくだり。

外在するゲニウスによってもたらされるものとすることで、作品と作者の結びつきを弱くできる。

さらに、よく考えると今自分が考えていること「アウトプット」の源泉は、他人もしくは他人の著作のインプットによるものであることは事実だと思う。例えば、物心ついたころには親から、学校に行くようになれば先生・友人から、社会に出れば同僚から、識字できる以上の年齢なら本から、インプットをもらって新たにアウトプットさせて頂いている、とも思える。そこからインスピレーション（発想）しているのは自分ではあるものの、考えまくって、悩んだあげく、なんちゃらが下りてくる、なんていう言葉があるように、ゲニウスがポロっと取り付いて、発想できているというのは、ストンと納得できる。

私の心の保ち方

上のゲニウスが加わりそうではあるものの、今日までの考え方の一部を紹介してみようと思う。

私は、まだまだ、多くの批判を受けたことがないと思っている。他人と比較しても仕方がないが、インプットを得ている人たちを見ているとそう思ってしまう。それは、転じて自分のアウトプットが世に広く出せていない証左だと思っている。だからこそ、批判をたくさん受けるほど、アウトプットを出せていることを少々うらやましくも思ったりする。であるから、これから多くの批判を受ける立場になったとき、それは成長し、自分のアウトプットが世に出る、「出世」したと考えることができるような気がする。

次に、少ないながらも、何かしら作っている職業柄、時折、ポジティブ・ネガティブ含めた反応をいただくことがある。
そんな時に思うことは、まず、
「人間は、言葉で意思を正確に伝えることはできない」
という確からしいことだ。
詳細は哲学書に譲るが、ウィトゲンシュタイン氏の言語ゲームあたりで探すと出てくる。
「言語は厳密に定義なんてできない」（ゲームと同じようなものだ）
で、あるからして、
自分の記事が「わかりにくい」とか「伝わらなかった」とか「曲解された」とか、そういう批判はそもそも、「完璧にわかる」文章を書くこと自体が不可能であるから、気にしなくて良い、と考えるのは私の心の保ち方だ。この、偉大な先人が、考えに考えを重ねて、明らかにしてくれた確からしい*1事実をもとに私は心を保っている。

ただし、唯一気を付けたいと思うのは、批判というか、有用な指摘である。アウトプットに対する反応で学ぶこともあるため、この辺のバランスが非常に難しいな、と感じる。

ソフトウェアを作ること、というのは人間の「認知」という能力に基づいているところがあるため、自分の思想がアウトプットに反映されやすいと思う。私も倉貫さんや先人の考え方に学び、批判を過度に恐れることより、アウトプットできなくなることを恐れるように行動していきたい。

と書きながら、この記事の反応を恐れつつも公開しよう

恐れながらも、公開していただいた倉貫さんに拍手を送り、私もこの乱文を公開しよう。

*1:そもそもそれも文章で読んでいるのだから私が完全に理解したとは言えないはずなので、確からしい、となると考えている

Sprottyのサンプルをビルドする

SprottyというEclipseのプロジェクトがある。サイトの解説の一文を直訳すると、Webベースの作図フレームワークである。

はじめに

Eclipseのプロジェクトサイトは以下にある。
Eclipse Sprotty | projects.eclipse.org

ソースはGitHubから取得できる。
github.com

サンプルをビルドする

GitHubからgit cloneする。

Node.js, Yarnをインストールしていない場合はそれらをインストールしておく。
レポジトリのREADME.mdにあるように、clientのディレクトリで以下を実行すれば良い。

yarn
yarn  examples:build

Proxyがある場合は、yarnのコンフィグを設定してから実行するか、yarnのコマンドに`--proxy`と`--https-proxy`あたりを指定すれば良いらしい。

サンプルを実行する

`client/examples/index.html`をブラウザで開くと幾つかあるサンプルページへのリンクが表示される。
例えば、Class Diagram（クラス図）のサンプルであれば以下のようなダイアグラムが表示される。

Sprotty - sample class diagram

Clean Architecture

少し前にコミュニティに関連して翻訳レビューに参加させてもらったClean Architectureという書籍が７月末に出版されたようです。

このClean Architectureという本は、アジャイルソフトウェア開発で著名なRobert C. Martinさんが書かれた本です。
訳者である角さんがあとがきでも記述しているのと同じように、少々クセがあったり、すっきりしない部分もあると思っています。
しかし、提唱されているClean Architectureのみならず、そこに至る考え方、例えばアーキテクチャは何のためにあるか、のような筆者の考え方、なぜそう考えるのか、という説明は、多くの学びを得ることができる本だと思っています。

www.kadokawa.co.jp

電子書籍も出ています（達人出版会）
tatsu-zine.com

Vimで検索した文字列にジャンプせずにハイライトする

Vimで`*`や`?`を使って検索してハイライトするのだけれど、検索先へジャンプしてしまう。
また、複数の文字列をハイライトできない。
そんな時に有効なコマンド。

:match Search /{string}/

goroutineを試してみた

Go言語のgoroutineを試してみたのでメモ。

なぜ試したか

Go言語の筆頭の特徴っぽいので。

どう試したか

Windows環境にGo言語の環境をインストールして、以下のように実装、コンパイルして実行。

func say(s string) {
	for i := 0; i < 4; i++ {
		time.Sleep(1000 * time.Millisecond)
		fmt.Println(s)
	}
}

func main() {
	go say("world")
	say("hello")
}

回数とスリープ時間を変更して試していたらworld出力される前に終了しているケースがあった。