 |
VOOZH | about |
|
VOOZH | about |
「新しいLinuxの教科書」という本を書きました。Linuxの入門書で、友人の大角(id:ozuma)と二人で書きました。2015年6月6日発売なので、もう本屋さんに並んでいます。
学習に役に立つ本ができたので、ここで内容を紹介します。
上の目次からも分かるように、この本はごく普通のLinux入門書です。
逆に、この本では以下のような項目は取り扱っていません。
これらは、この本では応用的な技術とみなしています。Linuxを使う用途はさまざまで、必要になる応用的な技術はその人によって違います。
でも、何を学ぶにしても前提となる、基本的な技術があります。基本が分からないまま応用を学ぼうとしても効率が上がらず、うまく進みません。
この本のねらいは、Linuxをどんなふうに使うにしても必ず必要になる基本的な技術を理解することです。応用を扱っていない代わりに、基本についてはすべて網羅しています。
具体的には、Linuxで次のようなことができることを目標としています。
僕の学生時代に、学校の先生は「シェルとテキストエディタさえ使えるようになれば、あとは何とかなる」と教えていました。今は少し時代が変わって、「バージョン管理システム」も必要になっています。これらをしっかり理解しておけば、もう怖いものはありません。さらに先の専門的な技術を学習するときでもスムーズに進むでしょう。
LinuxまたはUNIX系OSについて勉強したいという人にちょうどよい本になっているので、ぜひ読んでみてください。この本がLinux(またはUNIX系OS)学習の入り口となることを期待しています。
僕はIT系の勉強会によく参加しているし、主催者として勉強会を開催したこともある。そういう中で、参加者の中に無断欠席する人がいるということが非常に気になっている。ここで言う無断欠席というのは、主催者への連絡なしに欠席すること。
無断欠席は主催者に非常に迷惑をかける行為なので、絶対にやらないでほしい。このあたりどうも主催者と参加者で意識に差があるようなので、主催者の立場でなぜ無断欠席がだめなのか、僕なりの意見を書く。
まず一番大きな理由が、無断欠席によって本来参加できるはずのキャンセル待ちの人が参加できない、ということだ。ほとんどの勉強会の参加枠には限りがある。定員を超えて申し込んだ場合は、普通キャンセル待ちになって、もしキャンセルが発生したら繰り上がって参加できる。でも、キャンセルの手続きを行っていない場合はこれが発生しないので、キャンセル待ちの人が参加できなくなってしまう。そのせいで、20人の枠に25人が申し込んだのに、当日15人しか参加してない、なんてことになったりする。
主催者はわざわざ開催している以上、一人でも多くの人に参加してほしいと考えている。というか、参加者がいなかったら開催している意味がない。なので、こういうケースは非常に、非常に残念なことなのです。
だいたい、どんな勉強会でも会場選びには苦労しているもので、およそ次のようなポイントを考慮して場所を探してる。
開催する地域にもよるけど、こういう都合のいい会場がそんなに簡単に見つかるわけなくて、ほとんどの主催者は、悩みながら、どこかしら妥協しながら、それでもなんとか探してると思う。
その中でも、会場の定員というのは特に制限が強い。余裕のある部屋が見つかればいいけど、実際には定員を増やそうとすると会場の選択肢は狭くなる。有料の貸し会議室だったら、定員を20人から30人の部屋に変えただけで料金が1万円以上変わることもある。そんな中で、主催者は「15人ぐらい来そうだから、すこし余裕を見て20人入れる会場を探そう」とかいろいろ考えながら、少しでも多くの人が参加できるように工夫してる。
そうやってがんばってるのに、さっきみたいな入れるはずの人が入れないみたいなことが起きるともう悲しくて、やってられない。たぶん、この会場確保の大変さが無断欠席する人に理解されていないんだと思う。
あと、じゃあ定員割れの勉強会だったら無断欠席してもいいのかというと、そんなことはない。
特に懇親会はお店の予約が発生しているので、一人来ないだけでも金銭的な被害が発生してしまう。でもキャンセルの連絡があれば、お店に連絡して人数を減らしたり、代わりに追加の参加者を当日募集したりといった対策がとれる。
懇親会がなくても、部屋によっては備え付けの椅子の数が少なめで、増えそうなら追加で椅子を用意するとかいう場合もある。そういうのは急には用意できないので、主催者としてはなるべく早めに確定した人数を知りたいものだ。
それに、発表者にとっても参加者が何人なのかは重大なことだ。多めの人数だったら中には初心者もいるだろうから序盤は入門的なことを話そうとか、そういう工夫することがある。勉強会の内容を良くするためにも参加人数ははっきり決まっていたほうが良い。
そんなわけで、無断欠席する人は気がついていないだろうけど、勉強会を開催する上で参加人数を確定させるというのは非常に重要なことなのです。
ただし「絶対にキャンセルをしてはいけない」と言っているわけではないので、注意して欲しい。
たまたま大事な用事が入ったとか、当日急に体調が悪くなったとか、申し込んだのに参加できなくなることは当然ある。それはしょうがない。なので、参加できないと分かった時点で、できるだけ早くキャンセルの処理をしてください。勉強会の申し込みに使っているイベント管理サービスにキャンセルの機能が含まれている場合は、それを使ってください。そういう機能が無い場合は、Twitterやメールなど、何らかの手段で欠席する旨を主催者に伝えてください。
多分実際に無断欠席で多いのは、なんとなく申し込んだけど、忘れたとか興味がなくなったというケースだと思う。IT系勉強会は気軽なものが多いし、ボタンひとつで申し込みできるイベント管理サービスがいっぱいあるし、楽に申し込んでもらうのはいいことだと思う。それでもやっぱり、申し込んだ以上は自分でスケジュール管理して、参加しないときはキャンセルして欲しい。「申し込んだなら参加する」、「参加しないならキャンセルの手続きを行う」、あたりまえのことです。全然難しくないことなので、僕も含めて、みなさん気をつけましょう。
👁 https://scontent.cdninstagram.com/hphotos-xpa1/t51.2885-15/s150x150/e15/11187020_405163169656087_873252848_n.jpg
2015/05/04に「宇宙zsh #2」というzshの勉強会を開催した(告知ページ)。今回は東京で開催ということで、一泊二日のちょっとした旅行も兼ねて開催した(僕は普段神戸に住んでる)。
前半はzshについて基本的な設定から勉強しようということで、最初のインストールとよく使われる設定について解説した。
| タイトル | 発表者 |
|---|---|
| はじめに | @mollifier |
| 今から始めるzsh | @mollifier |
| 本格的に始めるzsh | @mollifier |
| zshでコマンドライン履歴を活用する | @mollifier |
後半はもう少し進んだ使い方について解説した。
| タイトル | 発表者 |
|---|---|
| vcs_infoを使おう | @mollifier |
| Antigenを使おう | @mollifier |
| pecoを使おう | @mollifier |
| anyframeを使おう | @mollifier |
あとは、@hoto17296さんと僕とでLTを2つやった。
| タイトル | 発表者 |
|---|---|
| peco活用術 | @hoto17296 |
| oh-my-zshを使うのは止めよう | @mollifier |
発表の資料はconnpassの資料一覧ページにまとまってる。
レベルとしては、基本的には初心者向けを想定して進めた。初心者の人がこの勉強会をきっかけに使いはじめて、その後もう少し応用的なところも、今はまだ分からないことでも、なんとなく真似しながら、将来必要なときにまた振り返る、というようなつもりで発表した。
zshを使い始めて1年前後の参加者がわりと多かった。「初心者歓迎」として募集をしていたけど、おおよそ想定通りの人が参加した感じだったように思う。
前半の「zshのインストール」と「代表的な使い方」という基本的な解説は続ける。実際には、基本的なところは分かっているので、そこは飛ばして発展的な話題を扱ってほしいという参加者もいる。でも参加者全員が基本を理解してるってことはありえないだろうし、最初に基本を抑えて、前提を揃えた状態で後半に進んだほうがよいと考えてる。
後半の約1時間は自習の時間として、その日学んだことの確認や、zshについての質問にみんなで答えたり議論する時間とした。シェルの使い方というのは自分で使ってみないと分からないものなので、話を聞いたその場で試してもらおうという意図。この時間についてはいまいち参加者からの反応がないので、意味があったのかどうかは正直よくわからない。でも、やっぱり話を聞くだけでなく自分自身で試してほしいので、これは続けたほうがよさそう。むしろ全体の真ん中あたりにも少し自習の時間を入れたり、今より増やしても良さそう。
SlideShareのプレゼン資料からコピペできなくて困ったという意見があった。自分では気が付かなかったけど、言われてみると確かに不便。SlideShareのサイトからPDFをダウンロードすればいいんだけど、それも手間なので、PDFの元になっているMarkdownもあわせて公開するとよさそう。
あと、「初心者歓迎」と謳っていたけど、そもそも初心者って何?っていうのもはっきりしていなかった。初心者と言っても「シェルやCLI操作の初心者」と「zshの初心者」では意味が違う。僕としては後者の初心者を想定していたけど、前者の意味にとっていた参加者もいたかもしれない。前者の意味の初心者向けにしようとすると、ディレクトリとは、とかリダイレクトとは、とかそういうお話になってzsh関係なくなるので、そういう人向け勉強会は(宇宙zshでは)やるつもりはない。このあたりはもっと明示的に告知するべきだった。
沖縄とか北海道とか、別の場所で開催したい。
懇親会は今回やってないんだけど、参加者の反応も欲しいし、やってみるのも良いかもしれない。ただ懇親会を開催するとけっこう負担というか気にするところが大きくなるので、簡単にはできそうにない。要検討。
そもそも僕は、自分のzshの話を誰かに聞いてほしいと思っていた。それで、まずはやってみようということで今回も含めて2回勉強会を開催して、とりあえず当初の目的は果たせたと思う。
参加者の側としてはどうかというと、反応から推測するに、この勉強会が役に立った人は(やや少なく見て)全体の5割から6割ぐらいだと思う。満点ではないけど、まあまあ悪くない感じだと思う。
継続的に続けるかどうか含めて、今後どうするかはまだ決めていない。でも、外に出て何かしらの活動をしないと自分の幅が狭くなってしまうので、これからも活動は続けていきたいと思っている。
参加してくれたみなさん、ありがとうございました。次回も(もしあれば)、またよろしくお願いします!
新しいMacBookが発表されて、USBポートが1個だけとか、いろいろ話題になってる。僕は買うつもりで、来月の発売を楽しみに待ってる。でもよく考えたら僕は普段Linuxを使っているので、なんでわざわざMacを買おうとしてるんだろう、という疑問が出てきた。なんか「Macの新しいやつ!!」みたいな感じで勢いで買ってしまいそうになってるので、これを機会に、冷静にそれぞれのOSのメリット、デメリットを検討してみることにした。
現在、僕が個人的に使ってるPC一覧は以下の通り。
PCの主な用途としては、Webブラウズ、メール、動画閲覧、ソフトウェア開発、など。ごく一般的な使い方だと思う。
Linux, Mac, Windowsと3つのOSを使ってるんだけど、それぞれの長所、短所、主な役割をまとめてみた。
ここで言うLinuxとは、正確に言うとLinuxディストリビューションというか、具体的に言うとUbuntuのことを想定してる。
Linuxマシンは、僕の場合はメインのPCとして使ってる。zsh, Vim, tmux, Gitが何の問題もなく動いて、テキスト処理とかプログラム開発とか普通にブログ記事を書いたりとかに関しては、3つのOSの中で一番やりやすいと思う。
それでも困ることはいくつかあって、その中でも一番厄介なのがiTunesが使えないこと。僕はiPhoneを使ってるんだけど、LinuxではiTunesが動かないので、iPhoneと同期出来ないし、iTunes Storeで買い物も出来ない。結局ここだけはWindowsを使って凌いでる。
それ以外にもぱらぱらと困ることがあるけど、まあ我慢できる程度。例えばATOKが使えないとか、Flash Playerが開発終了になってる(セキュリティアップデートはまだある)こととか。他にも、僕はHuluを見るんだけど、映画の日本語字幕が文字化けして読めないとか。
でも、日本語入力はまあなんとかなるし、Flash Playerもニコニコ動画ぐらいでしか使わないので、そこまで困ってない。Microsoft OfficeとかPhotoshopとかは元から使ってないので問題ない。Huluは気合でなんとか…。今は大抵Webアプリになっていてブラウザが動けば何とかなるので、特定のアプリが使えないっていうLinuxの弱点はだいぶなくなってきてると思う。
以前はノートマシンにもUbuntuを入れて持ち歩いていたんだけど、勉強会で発表しようと思ってプロジェクタに繋いでも映らないという事件が2回ぐらいあって、それで発表用のマシンにLinuxを使うのはやめた。事前にプロジェクタの種類が分かっていれば準備もできるんだけど、そんなことは普通ない。わざわざ発表の準備して行ったのにそんなことでだめでした、ってことになったらめちゃくちゃ悲しい。僕にとってノートマシンは発表するためにあるもので、発表できないと意味がないので、ノートマシンにはLinuxは使わなくなった。
Macは、MacBook Airで持ち運び用のマシンとして使ってる。
MacはLinuxとWindowsの間みたいな位置づけで、よく言えばいいとこ取り、悪く言えば中途半端なポジション。zsh, Vim, tmuxとかUnix系の便利なツールが使えて、ターミナルで快適に開発できる。その一方でiTunesとかATOKとか独占的なアプリでもMac版がある。なので、Macだけでほぼすべてのことができるのが強み。僕も3つのOSの中でひとつだけしか使えないってことになったら、Macを使う。
あとは、何も設定しなくても見た目がきれいっていうのもうれしいポイント。フォントは明らかにきれい。Linuxでも個別にインストールして設定すればきれいなフォントを使えるんだけど、そういう手間が必要ないっていうのは簡単で良い。
でも、開発環境としては、なんかこうしっくりこない感じがする。だいたいHomebrewでインストールするんだけど、なんか遅いし、たまにbrew linkとか手作業がいるし、OSのバージョンを上げたらHomebrewが壊れた、とかトラブルもあるし、いまいち安心して使えない。Rubyをインストールするときでも、なんか事前にopensslを入れろとか、readlineを入れろとか、gemでnokogiriをインストールするときも、その前に別途libxmlを入れておけとか、パッケージマネージャーのくせに完全にお任せできない。そもそも最初にXcodeを入れる必要があるのが面倒(なんかライセンスに同意するボタンを押したりしないといけないし)。
あと、BSD由来のツールが微妙に使いにくい。Linuxの(というかGNUの)ツールは、一部過剰なところはあるけど、やっぱり便利。それに比べるとMacに入っているツールは使いにくい。sedとかなんかおかしい。
なので、開発環境としてはベストでないと思ってる。僕にとっては、軽くて確実にプロジェクタに接続できる持ち運び用マシンという位置づけ。
Windowsはデスクトップマシンで、補助的に使ってる。
Windowsは、一言で言うと便利じゃないOS。開発環境を整えるのが難しいというか、面倒というか、まったくやる気にならない。
シェルもターミナルもしょぼいし、フォントが汚いのもつらい。Windowsでもフォントをインストールして使えるような気もするけど、僕はその方法を知らない。RubyとかGitとか、そいういうやつは明らかにWindowsを軽視していて、Windowsで使おうというのは茨の道。
それでもなんで使っているかというと、iTunesでiPhoneを管理するため。MacでもiTunes使えるけど、WindowsだったらOSだけ買ってきてLinuxとデュアルブートにできるので、費用が安くて済む。あとは、Windowsはゲームをするのにも向いてる。そういうわけでWindowsも使ってる。
というわけで、3つのOSの特徴と使いどころを見直してみた。どのOSにも向き不向きがあって、ひとつには絞れない感じだと思う。
それで、結局僕にとって新しいMacBookがいるかというと、正直微妙なところ。勉強会のときぐらいしか使わないし、その割には高すぎる気がする。MacBook Airの一番安いやつのほうがよさそう。でも、ちっちゃくて軽いのを使ってみたいし、新しいやつはなんかよさそうなので、やっぱり買うことにします!
11/30に大阪でzshの勉強会を開催します。
zshの勉強会を開催するのは初めてなので、初心者のかたも歓迎です。zshをどう使えばよいか分からないとか、みんながどういうふうに使っているのか知りたいとか、そういう情報共有の場にできればと思っています。ぜひ参加してみてください。
よろしくお願いします!
2014年10月24日発売のWEB+DB PRESS Vol.83で、「zsh大活用」というzshに関する特集記事を書いたので紹介します。
zshの特徴や使い方については、Web上でもいろいろと紹介されているし、僕もQiitaやこのブログなどで紹介記事を書いています。でも、そういうのはたいてい個別の機能を紹介した単独の記事で、zsh全体を通しての使い方が解説がされているわけではありません。なので、なんとなくzshを使っているけど最近の標準的な設定が分からないとか、他のみんながどういうふうに使っているか気になるとか、もやもやしたものを感じている人もいると思います。そういう疑問を解決するためにこの特集記事を書きました。
この記事を読めばzshの使い方を一通りおさえることができます。また、zshが標準で持っている機能だけでなく外部のプラグインを活用した使い方も解説しているので、シェルをばしばしカスタマイズして使うような今どきの開発環境が構築できるようになります。
シェルは開発の基本なので、一度カスタマイズしておくとそれ以降の操作が格段に快適になります。今回の特集を参考にして自分なりのシェル環境を作ってみてください!
今回、僕がこうやって雑誌の記事を書くのは初めてのことでした。普段は自分のブログとかに短めの記事を書くことはあっても、まとまった原稿を書いたことはありませんでした。なので、始めに記事を書くお話を受けたときはびっくりしたし、不安もありました。でも、僕はzshが大好きで今までいろいろと解説記事を書いたりしていたので、そういう自分のzsh活動をまとめる良いチャンスだと思い、今回の執筆に取り組みました。
原稿はMarkdownで書いてGitHubにコミットし、進捗管理や修正作業もすべてそこで行いました。なので普段のブログ記事を書く感覚に近く、雑誌の記事だからといって特別な手間もなく、本来の内容に集中して作業ができました。そんな感じで作業環境がうまくシステム化されていて、担当者さんの協力もあって今回の特集記事が完成しました。 関係者の皆様、ありがとうございました。
というわけで、10月24日発売のWEB+DB PRESS Vol.83をぜひ読んでください。そして、感想などがありましたらアンケートハガキを送ったりTwitterでつぶやいたりしてみてください。よろしくお願いします。
友人の大角(id:ozuma)が最近「UNIXシェルスクリプト マスターピース132」という本を書いた。シェルスクリプトの実践的なサンプルをいっぱい集めた本だ。
僕もこの本の制作に関わっていて、原稿のレビューをした。レビューというのは書評という意味ではなく、ソースコードレビューのレビュー。
いろいろ思うところがあるので、レビューというのがどんなものなのか含めてちょっと紹介してみる。
サーバー管理とかで使うようなシェルスクリプトのテクニックを紹介してる本で、実践的な見本のスクリプトが132個載ってる。実際シェルスクリプトでやりたいことがあったとして、それをどう書けばいいか分からない、みたいなことはけっこうあると思う。そういう人向けのサンプル集といった位置づけの本だ。
あと、Linux, BSD(FreeBSD), Mac に対応していて、どの OS でも動くように書いたり、OS ごとに違うところは「Macのときはこう書く」みたいに補足で説明したりしてる。親切。
原稿やレビュー内容のやりとりはサイボウズLiveで行うことにした。
まず著者が一週間分の原稿を投稿し、その内容をレビュアーが確認してコメントで指摘事項を書く感じ。これを毎週繰り返した。一週間でだいたい5から7Tips、全部で132個Tipsがあるので5ヶ月ぐらいかかった。初めはレビュアーは僕一人だったが、主に僕の負荷的な都合で途中からレビュアーをもう一人増やしてもらった(ありがとう)。
確認用のマシンとして Linux, BSD, Mac が必要になった。Linux は普段のメインマシンとして使っているのでそれをそのまま使った。Mac は MacBook Air を持っているのでそれを使った。BSD は持ってなかったので、VirtualBox で FreeBSDをインストールして使った。
レビュアーとして僕が何をしたかというと、本としての体裁とか日本語の表現とか、そいういう国語っぽいところはほとんどチェックしていない。そうではなくて、シェルスクリプトのプログラムとしてのレビューを行った。開発で行う普通のソースコードレビューに近くて、だいたいこんな感じのことをした。
元の原稿の時点で根本的に間違ってるみたいなことはなかったけど、細かな間違いや不具合はけっこうあった。例えば通信エラーやファイルが存在しないような異常時の処理が考慮されていないとか、文字列内にスペース、改行、カンマなどが含まれているときに問題があるとか。"$var" とダブルクォートで囲わないとダメなところが $var とそのまま書いてあるようなパターンもけっこうあった。
誤記とか typo とかもチェックした。普通のコードレビューなら些細なことだけど、本として出来上がったものに誤記があるとかっこ悪いし紙に印刷してしまったものは修正できないので、けっこう大事なところだと思う。なので例えば英単語は辞書で確認したりとかした。
著者はスクリプトとしてどう書くかとか文章としてどうやって説明するかとか、そういう本としてのメインのところを意識して書いているだろうし、自分が書いたものは当然正しいと思ってるので、細かいところまで気が付きにくいと思う。
それに比べて、僕はまず前提として「間違いがあるかもしれない」と疑って色んなパターンを考慮して確認やテストをしたので、そういう細かいところを指摘できたんだと思う。
逆に言うと細かいところしか指摘できてないわけなんだけど、その分著者が些細なことを気にせず本来の記述に集中できるわけで、役割分担としては有効に機能してたと思う。
最初のきっかけとしては、著者の大角から「シェルスクリプトの本書くんやけど、レビューやってや」みたいな感じで依頼が来た(もうちょっとフォーマルな頼み方だったかもしれない)。そういうレビューは初めてだったけど、シェルスクリプトは好きだし、大歓迎で OK の返事をした。
著者曰く「小さな Tips をいっぱい載せる本で、Tips 単位でレビューできるので普通の本よりやりやすいよ、簡単だよ!」という話で、シェルスクリプトは僕も書けるし、作業内容についてはまあいけるだろうと考えてた。今考えると死亡フラグだったと思う。
実際に初めてみるとこれがなかなか大変で、異常系とかいろんなパターンを考えながらのテストは思ってたより難しいし、それを Linux, BSD, Macと3つの環境で確認するとなるとけっこう時間がかかってしまった。平日の夜になんとか時間作って少しやって、残りは週末まとめてという感じで進めた。
最初の週にとりあえずユーザーインターフェース周りの Tips をやってみたんだけど、これがかなり難しいし、めんどくさかった。
とかで、「いきなりこんなマニアックなもん載せるのかよ」とか思ってた。結論としては最初の週にやったやつが一番難しかった。
だいたい、よく考えたら普通一冊の本に132個もコードが載ってるのだろうか。標準より多いように思う。
結局途中からもう一人の人にもレビュアーとして参加してもらった。それでだいぶ楽になったし、後半作業にも慣れてきたこともあって、無事全部のコードのレビューが完了した。
レビューを通していろんなスクリプトを試したし、man を読んだり参考サイトを調べたりもした。著者は当然僕よりもっとやってる。
10のことを人に伝えようと思ったら100ぐらいのことを知っていないといけないと思う。本というのは人に何かを伝えるためにあるんだけど、今回一番勉強になったのは書いた人本人なのかもしれない。
この本が多くの人の元に届くことを期待しています。
実家の親に本のレビューをしたことを伝えたら、「あんたなんかがそんなことやって大丈夫か」みたいなこと言われた。あんまり信用されてないようだ。次に実家に帰った時にはその本を持ってこいと言われた。なんとなくうれしそうにしてた。
引用をストックしました
引用するにはまずログインしてください
引用をストックできませんでした。再度お試しください
限定公開記事のため引用できません。
