はじめに

こんにちは。紗希と申します。プログラマーを目指して、フィヨルドブートキャンプというプログラミングスクールで学習をしています。
先週の6月20日(土)に、著者である三宅さんと大角さんによる、「新しいLinuxの教科書」のオンライン読書会#2 に参加させていただきました。お二人がそれぞれLTをしてくださり、資料をコンパスのページに載せてくださっています。その中で学ばせていただいたことや感想をまとめさせていただきました。

linuxbook.connpass.com

✅ lsコマンドは-Fオプションが便利なので、エイリアスを設定するのがオススメ

-Fオプションをつけると、それぞれのファイルがひと目でファイルかディレクトリか判別できる。例えば、ディレクトリには後ろに/が付く。エイリアスを設定して、lsを入力するとls -Fが実行されるようにすると便利。以下は私のホームディレクトリでls -Fコマンドを入力した例。 f:id:Saki-Htr:20200625074347p:plain

✅ なぜディレクトリ名に日本語を使ってはいけないのか

本では、「日本語のディレクトリは、文字化けなどさまざまな問題が発生するおそれがあるため、利用しないことをお勧めします。」(三宅英明,大角祐介. 新しいLinuxの教科書 (Japanese Edition) (Kindle の位置No.1666-1667). Kindle 版.より)とある。
これに関して三宅さんと大角さんは、「今は文字化けすることは無いと思う。しかし、圧縮・展開する時に文字化けすることがあり、そもそも日本語名のディレクトリにすると入力する時に面倒である」と仰った。
たしかに、通常Linuxを使う時は半角英数字で使うので、わざわざひらがな入力の設定にして日本語を入力するのは面倒だと思った。

実際にmkdirで日本語のディレクトリを作ったが、文字化けしなかった。しかし、日本語名を使うことで余計な問題が発生する可能性があるのなら、使わない方がいいと思ったので、使わないことにした。

✅ rmコマンドは本当に簡単に消えるから気をつける

rmコマンドは-iオプションをつけないと「本当に消していいですか？」と聞いてくることも無いし、バックアップをとってくれることも無いし、ゴミ箱機能もない。本当に跡形もなく消える。
以下、とくに気をつけるべきコマンド

#入力ミス(例:ファイル拡張子が.txtのファイルを全消去したい時)
$ rm *.txt  #これが正解
$ rm * .txt #*と.txtの間にスペースがあると、*と.txtの両方が全消去される😱

#絶対うってはいけないコマンド
$ rm -rf -no-preserve-root #全部消去😱
#rmのコマンドが/usr/bin/rmからメモリに読み込まれ、最後まで実行されてしまう

$ rm -rf / #ファイルシステム上のファイルを全消去する(今は実行できない)→システムは機能しなくなる😱

#上記のオプション解説
-r:ディレクトリごと削除
-f:強制的に全消去

✅ シンボリックリンクはバックアップをとる時に注意

バックアップをとるためにcpコマンドを使う時に、間違えてシンボリックリンクをコピーしていて、元の実体ファイルをコピーできていないことがあるので、注意。

✅ ハードリンクは現場ではほぼ使われていない

lnコマンドを使ってリンク作成することができる。リンクには2種類あり、オプション無しでハードリンク、-sオプションを付けるとシンボリックリンクが作成できる。
昔はハードリンクしかなかったため使われていたが、今はシンボリックリンクの方が便利なので、能動的に使われることはない。
- 「今この世にあるハードリンクは-sオプションをつけ忘れて、間違えて作られたハードリンクが一番多い」という話も😂
では、なぜハードリンクを学習する必要があるのか?

→ -sオプションをつけ忘れて間違えてハードリンクを作ってしまうことがあるので、その時ハードリンクがなにかを分かっていないと困るため。

✅ ファイル検索するfindコマンドとlocateコマンドの使い分け

ファイルを検索するコマンドは2つあり、findコマンドとlocateコマンドがある。
それぞれ特性があり、メリット・デメリットがある。以下は、私がまとめた違い。
これを踏まえ、お二人に以下の質問をさせていただいた。

findコマンドとlocateコマンドはそれぞれメリット・デメリットがあるかと思いますが、
お二人は実務でどのように使い分けていらっしゃるかお聞きしたいです。

✍🏻 三宅さんのご回答

findしか使わない。findだけでもそんなに困らない。
昔はすごく時間がかかったが、今はfindも早くなってきている。どれくらい早くなったかというと、検索に1hかかっていたものが今は20秒で検索できる程の早さ。
findの方が細かい条件指定ができる点は大きい。(書き方が細かいが)

✍🏻大角さんのご回答

findはフォーマル、locateはカジュアル
「ファイルを探して、何かを実行する」プログラムを書く時=プログラムにかませる時にfindを使う。
絶対にそのファイルが存在していることが分かっている時に使う。
障害があってシステム報告書を書く時、エビデンスのためにfindを使う。
locateはフランクに使えるコマンド。

➡人によって使い分け方が違うので、自分にとって最適な方法を模索していきたい。

✅ 使い方がわからない時はまず、一次情報に触れる

Linuxにはコマンドの使い方などが載っている、manや--helpがある。検索してQiitaなどのネット記事を見たくなる気持ちは分かるが、まずmanを見よう。
ワンランク上のエンジニアになるには、この癖をつける。
Linuxのマニュアルの和訳サイトがある:JM Project
ターミナルの狭い画面よりブラウザの方が見やすい。
ただコピペするのでなく、そのコマンドの意味も調べる
なぜ最初にネット検索してはいけないのか
- Qiitaなどのブログ記事は、書いた人の勘違いなどがある可能性がある。
- Qiita自体が悪いといっているわけではなく、一次情報を読む前にネット検索することが良くないということ

✅ infoコマンドはすごく難しく、初心者向けではない

本に載せなくてよかったとのこと...(笑)
なぜなら、初心者向けでなくすごく難しいから。
難しすぎて、info infoと入力するとinfoを読むためのチュートリアルが出てくる。ヘルプのためのヘルプ!(笑)
しかし、より最新の情報が反映されているので、見ても無駄ということはない。

✅ 三宅さんのLT:『READMEを書こう』

READMEとは：アプリケーションの使い方や注意を書いた文章。自分がリリースする時の準備。
ちゃんとしたものを書くと、インストールするか迷っている人が、「この開発者はしっかりしてる」と思い、使う気になる
誰に向けて書いているか:まだ使い始めていない人、使い始めた人、自分も結構忘れるので自分にも。
- インストールした人に向けて書くものだと思っていたので、使うかどうか迷っている人の判断基準の一つになるという点は意外だった
本体の実装前に書くのがおすすめ
理由①実装している時が盛り上がりのピークで、完成したらやる気がなくなってしまうため。
- "やる気"という観点が面白いと思った。
理由②実装し終わってる頃にはすごく詳しくなっていてユーザー目線で書けなくなっているため。 だんだん詳しくなると、前提知識が違うから使うか検討している人、これから使う人の目線に立って書けなくなってしまう。でも実装前だとユーザーと同じ気持ちで書ける。
なので、✕こういう風に作りました→◎こういう風になってほしい、こういう使い方をしたい、というユーザー目線で仕様を決めて書く
→そうやって仕様を決めると使いやすくなる。
- READMEを書くことで、何のために作るのか、どんなものを作るのか、どんな実装をするのか頭の整理をすることができるのは大きいと思った。
はじめのうちは他の人が作ったツールを参考にするのがよい。なので、世の中にあるアプリケーションやツールを使ってみることが大事。

✅ 大角さんのLT:『/proc を見てみる』

/procとは?これもman procでマニュアルが出てくる →これによれば、procとはプロセスの情報を含む擬似ファイルシステム
プロセスとは→本のチャプター10に説明が載っていた
この/procファイルを通して、カーネルの現在のプロセス管理状態や各種情報の取得を行う。一部は書き込み=設定変更も可能。
これを使ってわざとシステムをクラッシュさせることもできる

✅ チーム開発で気をつけていること

以下を質問させていただいた。

前回の勉強会で大角さんは、表示内容を全消去するclearコマンドをペアプロで使うと、
相手に無駄に余計に考えさせてしまうので使わないと仰っていましたが、
他にチームで仕事をする時に気をつけていることがございましたら、
教えていただきたいです。

✍🏻 大角さんのご回答

相手の脳のメモリを無駄に消費させないように心がけている。
例として、「GitHubでlgtmという文化があるが、これには反対」というお話をしてくださった。

◎ lgtmの問題点

例えば、 GitHubを使ってAさんとBさんで一つのシステム開発をしているとする
↓
Aがコードを修正して、プルリクエストを送る
↓
Bがレビューする。このレビューする時に「lgtm」とコメントするのが最近流行している。
lgtmとは:"Looks Good To Me”=「自分的にはOKだよ」という意味。
開発したシステムやコードのレビューをお願いされた時に使う。

◎ lgtmと返すことの何が問題なのか？

この後別の開発者Cさんが入ってくるかもしれない。
AさんBさん同士はなぜそのプルリクエストが採用されたか分かっていても、Cさんにはなぜそのレビューを通したのか、lgtmでは分からない。
とくにトリッキーなコードは良くない。
またペアプロでは、当人同士で話して完結して満足して終わりになってはいけない。

◎ 大角さんがレビューする時に書くこと

1. 「私は○○をチェックした」 =自分はどこをチェックしたか
2. 「✗✗機能はちゃんと動いていた」
3. 「△△はちょっと変な書き方に見えるけど、まあ細かすぎるので良いでしょう」

多くの人は3まで書かない。
しかし、今後このプログラムがどのように使われるのか分からないので、できる限り細かく書く。
結論=人の頭の中を過剰にテキストにする

✅ 感想

✍🏻大角さんの「チーム開発で気をつけていること」に対するご回答について

質問したらとても深いご回答をいただけて、「lgtmだけをコメントしないで細かくレビューすべき」というお話は、私も実務に入ったら心がけようと思った。(もちろんスクールのカリキュラムでも!)
また、このお話もためにGitHubとはそもそも何か、lgtmとはそもそも何かまで丁寧に説明してくださった。
「相手の脳のメモリを無駄に消費させない」という点は、どのお仕事でも当てはまることで、私も仕事で意識していることでもあったので、とても共感した。
まだGitHub等を使ってチーム開発をしたことはないが、"lgtmとしか書いてなかった場合に起こりうる無駄"を考えてみた。
- 後から入ってきた人が、なんでだろう？と考える時間が無駄である
- 理由をレビューした人に聞く時間が無駄である。
- しかもその人が覚えていたらいいけど、前に書いていたら覚えていない可能性もある...
- レビューした人が退職していたら、採用した理由はもう分からない...
細かくレビューを書くことは、その瞬間のその人の時間だけを考えると、その人にとっては面倒かもしれない。
しかし、チーム全体の「時間」と「人に無駄に考えさせることを減らす」という観点から私も考えてみたところ、「細かくレビューするべき」と思った。
✍🏻復習することの大切さを知る
この本を初めて読ませていただいたのは今年の1~2月なのだが、今回復習をしたら、理解が十分にできている所と理解が曖昧な所が浮き彫りになった。
中には、毎回同じ箇所でつまずく度になんとなくで先に進めている所もある。
なので、今回理解が曖昧な所は復習してきちんと理解して次に進もうと思った。そしてそれをブログでアウトプット！

✍🏻勉強会参加にあたっての準備の大切さを知る

勉強会の前にその単元を予習してから参加にのぞむことの大切さを実感した。
その方が勉強会の時間を有意義にできると、頭では分かっていても、なかなかサボって行動にできていなかった。
実務で既にバリバリLinuxを使っているならまだしも、勉強の時にしか触っていない＆オプションもそんなに使いこなせていない＆教科書の内容の細かい部分は頭から消えてしまっている状態では、せっかく良い話をしてくださっても、前提知識にとても差があるので意味が理解できない。
例えば、findコマンドとlocateコマンドの使い分け方について質問させていただいたが、そもそも私が2つのコマンドの違いを把握していないと、せっかく実務ではこう使っていると話してくださっても理解できなかった。

✍🏻 質問を用意して参加した

質問を2つ用意していて、チャットにコピペする用のメッセージも用意していたが、オンラインで何十人もいる中で送るのはとても緊張した。一瞬諦めようかと思ったが、復習･準備した意味がなくなってしまうので、質問したら、とても丁寧にご回答いただけたので、勇気を出してよかったと思った。おそらくオフラインよりもオンラインのほうが質問することのハードルは低いので、どんどん質問して慣れていきたい。

さいごに

著者のお二人が「本の内容と関係ない質問でも大丈夫ですよ」と仰ってくださり、とても質問しやすい雰囲気でした。

「このコマンドはこのオプションを使うと便利」という使い方のお話、「本ではこう書いたけど現状はこうなっている」という最新の情報など、たくさんお聞きすることができました。

また開催されましたら、ぜひ参加したいです。三宅さん、大角さん、大変貴重な機会をくださり、誠にありがとうございました！

Sakiのプログラミング学習ブログ

プログラミングについて学んだことや、学習の振返りを書いています。

「新しいLinuxの教科書」を読む会オンライン #2 参加レポート