インフラエンジニアに成る

しゃべるインフラエンジニア。

2008年09月

なぜ、転職をしないのだろうか。

それは、現状に不満がないからである。

逆に転職する理由については、
個人的にはすでに結論は出ている。
単に現状に不満があるから人は転職する

では、改めてなぜ転職をしないのだろうか考えてみた。
そのためには、なぜ転職をするのか知る必要がある。

今回は、退職理由アンケートとしてここを参考にした。
だいたい、どこの統計を見ても
大なり小なり上位の結果は皆同じである。

・人間関係
・給与
・仕事内容

この3つだ。

特に人間関係を理由にするところがほとんどだ。
個人的には意外というか無自覚なところなのだが、
バイトや学校のくくりで考えるとあー同じだと気がつく。
このクラスがいやだとか、バイトの上司がいやだとか
集団という組織においては
人間関係は不満の対象になりやすい。
よく耳にするグチ話題のひとつである。

ということは、仕事においては
この3つに不満がない限りは、
人は転職しないのである。
人間関係がよくて、給与も満足できて
仕事内容がまあ好きであればOKってことである。

転職未経験者が転職経験者を見て
よく転職できるなーというセリフが飛び出すが
不満があるかないかだけの違いである。
不満をハングリー精神に変えたものが
転職という手段を用いるわけだ。

つまり、不満を感じなければ転職する必要はないのだ。
それが一番いい選択だろう。
不満がないなんて、なんてストレスレス。

ただ、このご時世。
会社の将来や世の中の未来を見据えたとき、
不満はなくとも不安はつのる。
このままではいいのかという不安。
これに気がついてしまうと転職もちらつく。
未来を見ると転職がちらつく。

ただ、この場合の転職は
不満が原動力でないことに注意したい。
不満は欲でもあるので力に変換しやすい。
不安は即、力へとはならない。
不安には不安の原因となる不安材料があるはずだ。
それが、何なのかをまずは発見しなければならない。

不安材料が金銭であれば、
給与Upを意識するかもしれない。
キャリアアップのない将来への不安であれば、
職制を変える選択肢を検討するかもしれない。
結局は、現状との天秤。
はかりが現状と未来のどちらかに傾くだけである。

まあ、結局不安をあらさがしすると
どこか不満があることに気がついていない
ということに気がつくだけだ。
なれてしまっているのだ。
そのままでいいやと。
なれってこわいぜ。

あと、人間関係に不満がなければ、
転職するという動機は生まれにくいだろう。
不満(欲)が少なければ
不安に気がつくことも遅くなる。

不安→不満→行動が必要だ!と判断した場合、
転職という方法もまんざらではない。
かといって、転職をおもいっきりすすめる気もない。
離婚よりは簡単な契約解除だろうが、
それなりに大きい意味をもつのだから。

ただ、転職してない人は、たぶん転職したいんだと思う。
現状が不安であればね。
何か動かなければいけないかもしれないって。

その点、転職経験者は一度転職しているから
転職がそんなに難しいことではないと気がついている。
いつだって、今でも転職しようとしてできないことはない。
だから、転職した人だけが転職する権利を得た
といえるのかもしれない。
不満があれば次があるという発想が自然体になるからだ。

こうやって、なぜ転職しないのかから、
いろいろと考えてみたが
どうやら、転職するという手段も
案外悪くないのかもしれないねっていう結論が出ちまった。

そんなに現状に不満がないのかい?

このエントリーをはてなブックマークに追加

再び前回の続き。を、書こうとしてやめました。

このシリーズをいつまで続けようか今一瞬悩んだ結果、
前回ぐらいでちょうどいいかなと思ったのでもう、打ち止め。
1ヶ月半ぐらいの話ですが構築ばかりやっていれば、
これぐらいはやるという話です。
あと、書いていてあまりおもしろくないという本音もちらり、と。

今回のことでいいたいのは、
ネットワークを構築しないと、今回紹介したような体験はできない
ということです。

ある意味では、強制的にこういった時間をおくらないと
なかなか人は成長しないものなのかもしれません。
たとえ、同じ時間をかけて一人でネットワークの勉強をしたとしても、
構築者と同等のネットワーク力を身につけることはできないでしょう。
同じ時間をかけたとしてもです。

また、ネットワーク初心者が構築後のネットワークだけを見て
構築した人と同じレベルになるためには
構築者より時間がかかることは明白です。
3ヶ月分を1年かけても同じレベルにひきあがるとは到底思えません。
なぜなら、同じ体験をしたわけではないからです。

カレーを例にします。
カレーを作った人には作った人にしかわからない体験をしています。
包丁にぎってまな板の上で野菜や肉を切って煮てを経験しています。
これが、カレー作り経験者です。

一方、できたカレーという完成図を見て
カレーを理解しようとするのがカレー作り未経験者のかたです。
この人がいくらがんばってカレーのことを勉強したとしても、
実際にカレーをつくらない限りはカレー作りのことは
よくわからないままでしょう。
作らずに料理本なり、料理メモ(ドキュメント化された文書)を読んだだけでは
すべてを理解することはできません。

そうなると、ネットワークであれば構築が体験できる環境に
いきなり飛び込むだけでも飛躍的な成長は望めるということです。
逆に言えば、ネットワークを生で感じる体験ができなければ、
いつまでも初心者レベルをうろうろしてしまう可能性があります。
この場合、未経験者との差はあまりありません。

だから、てっとりばやいのが環境をかえる
という意味での転職という手段もあるということです。
それが、契約や派遣であったとしてもです。

カレーを作りたいなーと思ったのであれば
カレーを作るしか方法はないわけです。
だから、カレーを作っているところに飛び込めば、
短期間でカレー経験者になることができるわけです。
カレー作りをネットワーク構築にあてはめてもいっしょの話です。

前回まで私が紹介したようなネットワーク経験ができなくて
やりたいというのであれば、
そのような現場にいくしか方法がないと思いますがどうでしょう。
このエントリーをはてなブックマークに追加

前回の続き。

ネットワークエンジニア未経験者の仕事メモを
ただひたすら書いていくという話。
ネットワークといっても、構築それも
サーバではなく、L2/L3機器中心の作業であればこんな感じです。

(2006年6月〜)
ポイント:やはりルータやスイッチの検証や構築の話ばかりでちょいサーバ


続きを読む
このエントリーをはてなブックマークに追加

毎日、お仕事日記をつけている。

そのとき、感じたことやメモしたことを全部
かきとめるだけかきとめている。
いわゆる、ToDoリスト。
特にツールも使わずテキストにひたすら入力。

これを今、読み返してみた。
すると、あれこれしていたんだなと自分自身を再発見。
そして、この内容って、ネットワーク未経験者が仕事で何をしていたのか?
という目安になるかもしれないなと感じた。
そこで、せっかくだからここにまとめて書きとめておこうと思う。

たいしたことのない内容が9割を占めるので、
いろいろとはしょって箇条書き。
感想やぼやきはそのままコピペ。
下流工程としてネットワークの構築と保守が中心だと
こんな生活をおくります。

(2006年5月〜)
ポイント:Ciscoのルータやスイッチの話ばかり

続きを読む
このエントリーをはてなブックマークに追加

最近は、サーバ中心。

それもLinux。
もっというと、シェルスクリプトをやる機会が多い。
というか、できるだけでそうなるように
自分自身、近づける努力をしている。

前々からちゃんとやらないとなーって思いながら
本を買うだけ買って放置という状態が
かれこれ何年も続いていた。

前からdialogコマンドが気になっていたので試してみる。
おー!簡単なGUI画面が表示される。
調子にのってXdialogをインストする。
Helpを参照した1、2行の簡単なコマンドで、
それっぽいGUIが表示されるのでおもしろい。

(引用:XdialogでGUI気分


最近はちゃんとやっている。


UNIXシェルスクリプト逆引き大全333の極意―Linux,FreeBSD,Solaris,Mac OS X対応
中橋 一朗
秀和システム
売り上げランキング: 16708
おすすめ度の平均: 5.0
5 これから始める人に是非!
5 UNIXコマンドの知識が多少ある人向きです
5 shellはなくならない?



発売当初から保有しつつも全然使っていなかった
この本が最近までの一番のお気に入り。
やはり逆引き。
初心者本を何冊も参考にして作成されているだけあって、
ほとんどの機能が網羅されている。

とにかく、一度試してみるというのが一番いい。
そこから、こんなことできないかなーって
発想していって、組み立てていけばいいと思う。
そうそう、CシェルじゃなくてBシェルの話ね。

はじめは
・1行スクリプトをつくる(パイプで並べる)
・おぼえたコマンドをとりあえず試す
・grepで簡単な正規表現にチャレンジ
・awkで区切り文字にチャレンジ
・echoでメッセージを吐き出すif文の作成

このあたりができると、
・標準入力・出力・エラー出力の使い分けをする
・testを使うようになる
・case文を使うようになる
・引数に$1やら$2やら$**系を使うようになる
・if文にあわせてexprやshiftや$#に$?を使うようになる
・ついでにforやwhileも
・findの豊富なオプションを使用するようになる
・dateの豊富なオプションを使用するようになる
・cronをからめるようになる
・ログに出力とかやるようになる
・cutを使うようになる
・関数をつくってみるようになる
・引数の数を意識してxargsかexecを使うようになる
・echoだけじゃなくて、printfも使うようになる
・printfだけじゃなくてヒアドキュメントも多用する

自分はこのあたりをうろうろ中。

できれば、
・evalで配列
・trapでシグナル処理
・expectで対話処理
・sedやawkやperlらと正規表現をまぜまぜ
・自作関数用の引数オプションを意識したgetopts
・shだけじゃなくてbash利用も考慮

というのがすぐにできるようになって、
最終的には、やりたいことをその場でかたかたと
シェルを組めるようになるのが理想。
今年中に、このレベルにひきあげたいところ。

初心者の山場は引数の使い方とtest文かなあ。
あと、関数化したときの戻り値かな。
自分も、まだ初心者なのでなんともいえないけど。

シェルを扱うレベルを底上げするなら
最近発売したこの本がよさげ。

ゲームで極める シェルスクリプトスーパーテクニック
山森 丈範
技術評論社
売り上げランキング: 43301
おすすめ度の平均: 5.0
5 「ゲーム」をタイトルにするのはもったいない


プログラムだから結局は、
アルゴリズムというか考え方の話。
自分でもシェルでゲームつくれるレベルになると
そりゃ、そこそこできるようになるよってな本。
最近は、これに手を出しはじめたところ。

で、プログラムできる人であれば
本を買う必要はまったくない。
/etc/init.d/配下のスクリプトを参考にするだけで
何すればいいのかすぐにわかるし。
printfもC言語使った人ならなんてこないだろう。

ぶっちゃけ、うまい人(Linuxなら書かれたシェルそのもの)を
参考にするのがマネするのが一番の上達方法です。
本は、最低1冊あれば他はいらない。
全部、OSに書いてるじゃんって話。

でも、大量に自分は本を購入。
買ったのかよと自分つっこみ。

初心者本ばかり買ってあうやつ探しをした。
でも、結局、はじめに紹介した逆引きだけでことたりた。
軽くレビューでも。

詳解 シェルスクリプト
アーノルド ロビンス ネルソン・H.F. ベーブ
オライリージャパン
売り上げランキング: 92423
おすすめ度の平均: 4.5
4 POSIX準拠
5 不得意分野
5 歴史的背景から基本コマンドまで

オライリーより一冊。
オライリーだけど初心者向け。
Linuxのコマンドリファレンスももってなくて
シェルもやろうかなって思っている人向け。
内容は薄めで本としての賞味期限も短いかも。
大事なことは、たくさん書いてるんだけど
ちょっと物足りない内容。


入門UNIXシェルプログラミング―シェルの基礎から学ぶUNIXの世界
ブルース ブリン
ソフトバンククリエイティブ
売り上げランキング: 7348
おすすめ度の平均: 4.0
4 わかりやすい入門書
4 とてもわかりやすく書かれているかと思います
4 shellの奥深い世界
3 内容はわかりやすい
5 目からうろこのシェル解説


皆が進める初心者本。
たぶん、一番売れているのでは?
でも、自分には全然あわなかった。

学生のときに買ったけど、なんかダメ。
今そこそこさわるようになって改めて読んでも
それでもあまり内容が頭に入ってこない。
なんでだろう?不思議だ。
結果的には、この本を使って
シェルをやりはじめたのは失敗だった。


UNIXシェルスクリプトハンドブック (Technical handbook series (001))
関根 達夫
ソフトバンククリエイティブ
売り上げランキング: 223682
おすすめ度の平均: 4.0
3 説明が足りない
5 bashで書くシェル・スクリプト


shじゃなくてbashの話が中心。
サンプルスクリプトもほとんどがbash。
それらをはじめから駆け足でサンプルばかり
のせるもんだから、戸惑うかも。

自分は、この本は合いませんでした。
2冊目にこの本を買ったのも失敗だった。
bashやるならshでできない、物足りないときに
使うという使い方でやりたいところ。

とまあ、本をちらちら紹介しましたが
途中でいったように買う必要はないです。
それでも、本一冊というならはじめの逆引きが
一番オススメ。

とにかく、試すのが一番。
試して軽く基礎をおぼえたら
あれやってみよーこれやってみよーになると思うので。

そうならないとスクリプトやプログラムって
全然できるようにならないです。
ってことに、最近ようやく気がついた。
遅っ。

このエントリーをはてなブックマークに追加

どうしてもネットワーク技術を例えたくなるときがある。

ネットワーク業界未経験者が特にそうである。
普段ネットワークの用語を耳にしない人にしてみれば、
どの用語が耳を通過しても初めて聞いた言葉になる。
つまり、何を聞いてもよくわからない、
イメージができないということである。

Ethernet ARP STP Ping TCP UDP SSL 
SMTP DNS HTTP HTTPS NTP SNMP 
などといった横文字ネットワーク用語は
知っていなければ何のことだかわからない。
でも、知っているか知っていないかの違いだけでもある。
だから、まずは知る必要があるし、
知るしか方法はない。

知らない単語を知るためには、
その言葉の意味をイメージしなければならない。
イメージができないとその仕組みを理解できない。
理解できないと、ネットワークというものが
なんだかよくわからないものになる。

ここで、陥りがちなのが、
知らないことをわかりやすくするために
すでに自分が知っている何かに例えてしまうことだ。

たしかに、「例える」という行為は
わかりやすさへの明確な手段の一つである。
また、説明する際に「例える」という手段は非常に有効だ。

私は、ネットワークの世界をよく料理に例える。



包丁やまな板という名のターミナルソフト
パケットキャプチャといったネットワークツールがなければ、
また、その使い方を知らなければ調理ができない。

おぼえることはもちろん大事だ。
しかし、料理用語を知らないからといって、
全部をおぼえてからという心構えはよくない。
全部おぼえなくても、料理をつくれないというわけではない。
それは、あとからおいおいおぼえることだ。
まずはやってみることが大事だ。

そして、自分流といったなめたマネをする前に
先輩のマネから入るのが重要だ。
なにより、基礎が大事であり、
皿洗いという名の物理敗戦を経て
人はネットワークの世界を知るのである。

たとえ、カレーがにんじんやじゃがいもや
カレー粉が入った食べ物であるという知識があっても、
それをつくることができるかどうかは別である。

さて、君はスタティックルーティングが設定できるか?
なぜ、PCにデフォルトゲートウェイや
DNSの設定するのだろうか?
これらの単語を聞いたことがあっても、
その仕組みまで理解しているかは別だ。
やってみないと理解はできない。

たとえ、料理本丸暗記の証明としての資格があっても、
それは和食なのか洋食なのか中華なのか
という話にもなってしまう。
料理本だけが、料理のすべてではない。

料理の世界は広い。
そして、ネットワークの世界も広い。


といった感じだろうか。

しかし、おぼえる身の立場であれば例えてはいけない。

HTTPというネットワーク用語をはじめて聞いた。
ネットで調べてみた、という場合。

Webサーバとクライアント(Webブラウザなど)がデータを送受信するのに使われるプロトコル。HTML文書や、文書に関連付けられている画像、音声、動画などのファイルを、表現形式などの情報を含めてやり取りできる。IETFによって、HTTP/1.0はRFC 1945として、HTTP/1.1はRFC 2616として規格化されている。

(引用:e-Words:HTTP


単語を調べても初めて聞く言葉ばかり。
サーバ?クライアント?RFC?
HTMLは聞いたことがあるけど...となるはずだ。
そして、上記の用語を丸暗記しても、
HTTPのことがわかるわけでもない。
だから、イメージがわかなくてよくわからない状態になる。

そうすると、どうしても知っている何かと結びつけて
おぼえようとしてしまう。
なぜなら、すでに知っていることと結びつければ、

 すでに知っていること + 知らないこと
 =なんとなくわかる

という計算のもと、納得感を得ることができるからだ。
とりあえずは、なんとなくわかるのだ。
しかし、この、納得感というものがくせものである。

納得すればわかったような気になる気がする。
気がするだけで、実やよくわかっていない
ということはよくあることである。
つまり、すでに知っていることと知らないことを
結び付けようと例えようとする行為は
よくわからないことをわかった気にさせる恐れがある。

一度、納得すればそこからさらなる疑問はうまれにくい。
疑問が浮かばなければ、そこから先には進まない。
本当に理解する道というのを失う可能性がある。

HTTPを知らない人が一瞬
 あっ!わかった!そうか!
 HTTPって、インターネットのことですね
と納得してしまったとする。

さて、このおぼえかた。
間違ってはいないこともないけど、
そうおぼえていいものか悩むこちらがいる。
○じゃなくて×じゃなくて△なときだ。
はじめのうちはそれでも、と思わなくもない。

でも、そう例えたところでHTTPとは何か?に
それほど、近づかいてはいないのである。
実際、HTTPとは何か?となると、
意外に説明が難しいのではないだろうか。
そう、実際にHTTPは難しいのだ。

そして、HTTPのことがわからないと
人に説明することは、まずできない。
それは、よくわからない単語をなるべく並べないようにして、
人に説明するしか方法がないからである。
そうなると、説明する際にも例えを使って
うやむやにするという方法がとれてしまう。

つまり、説明する際の例えも同じことが起きてしまうわけだ。
さきほどの、ネットワークの世界を料理の世界として
例えてみたがなんとなくわかったような気に
なってしまったのではないだろうか。

包丁やまな板を知らないで料理のことを
説明するのが不可能なように、
ネットワーク用語を知らないで
ネットワークを知ろうとするのは△じゃなくて×だ。
それは、ネットワーク素人の発想である。

だから、極論をいえば、RFCを読め!になるし、
本当にHTTPの動きを知りたいんだったら
HTTPのプロトコルを実装したプログラミングをしろ!
には、なってしまうといえばなってしまう。
きついだろうか?

しかし、はじめに用語を調べただけで、
HTTP1.0はRFC1945といってるから
そのままRFC1945を読むのは正しい判断である。
最終的には、そのままおぼえるのがベストだ。

はじめておぼえた言葉ってなんだろうか?
パパ?ママ?おとうさん?おかあさん?
決して、例えてはいないはずだ。
母親を見て”おかあさん”と言ったから”おかあさん”なのだ。

その言葉を発した瞬間は、
意味もわかっちゃあいないだろう。
でも、それが正解だ。

だから、HTTPはHTTPであるといえるように
近づかなければいけない。
それを最終目標にして理解する必要がある。
適当な計算の適当な二アリーイコールで
わかったと判断するのはわかっていないことを意味する。

ネットワーク初心者本には、例えが満載である。
そうすると、一通り読んだだけで
なんとくわかったよう気になってしまう。
でも、なんとなくなだけでわかったわけではない。
理解できたわけではない。

だから、ネットワーク初心者という身であれば、
経験者を参考にしておぼえることはおぼえ、
わかんないけどまずはやってみるしかないのである。

すなおが一番だ。
HTTPといえば、HTTPなのだ。
そのままおぼえるしかないし
その仕組みも地道におぼえるしかない。
時間はかかるがそういうものである。

私も、ネットワーク業界経験3年目。
まだ、2年半しかたっていない。
だから、ひとつのプロトコルについて
詳しく説明しようとすればまだまだ経験が足りない。
皿洗いの身からようやく包丁をにぎらしてもらった
といったところだ。

そう、ネットワークの世界は広い。
一生、修行中の身である。
だから、すべてを例えて本質から遠ざかってほしくない。

このエントリーをはてなブックマークに追加

C言語をやりなおし中。

専門学校時代にC言語の授業があった。
アセンブリの授業もあった。
C++もJavaもあった。
電気・電子や論理回路設計の授業があった。
OSやアルゴリズムやコンパイラの授業もあった。
SQLやネットワークの授業もあった。

どれもIT系の基礎を学ぶものとして
かかせない科目ばかり。
情報技術の本質ってのはこのあたりのジャンルを指す。
ここから技術のT字型を生み出すのが真の技術。

でも、私はネットワークと名のつくもの以外は
てーんでダメな学生だった。

興味があってその学部を選んだはずなのに
2年目からわけがわからなくなって
途中から授業中は寝てばかりのバイトばかり。
典型的なダメ学生まっしぐらの道を選択してしまった
という自分歴史がある。

特にプログラムの課題はいつもギリギリ。
ギリギリOKではなく、ギリギリダメ。
ひどいときはギリギリですらなかった。
つまり、科目落とし。
それも、必修でC++。
なんとか、先生がたにすくっていただいて卒業したって感じ。

それぐらいプログラムがダメ。
だから、むいてないって思っていた。

なのに、なんで今またC言語なのか。
結局は、プログラム苦手だー
わかんないからいやだーとかいいながら、
本当はちゃんと理解したいのである。
それに、やっぱりというか、このあたりの基礎を
きちんと学んでこなかったつけが今になってきている。

ちなみに、何も開発系にいくとかWeb系に転職するとか
そういう話をしているわけではない。
そのためにプログラムをやっているわけではない。

確かに、今の仕事に直接つながるかどうかは別だ。
でも、今は遠回りをするべきだと思っているし、
自分がやりたいとかやりなおしたいって思ってることに
積極的に力を注ぎたいと思っている。

だから、まずはC言語。
次にアセンブリ。
そのうち、H/W系として半田ごてでもにぎろうか。

で、実際に8月中旬からやり直し始めた。

はじめにこの本を1冊やった。

デバッグではじめるCプログラミング
山本 貴光
翔泳社
売り上げランキング: 100244



この本の狙いは考えるつくりになっているところ。
わざと間違いサンプルが用意されているので
そのままコンパイルするとエラーになる。
そこから、考えようというやりかた。

だから、いきなりはじめにやるならこれだろう。
まずは、やる。
いきなりやる。
これが、最善。

そして、プログラムって楽しいかも!
って思わせるいいつくりになっている。
自分は、あーそうそうそんなんだった
と思い出しながら一冊やりきった。

でも、C言語の肝であるポインタの話は最後にちょこっとだけ。
もっというなら、Cである必要はあまりないぐらい。
といえちゃうところはあるが、
別に狙いはそこじゃないのでいい。
自分は復習用にと使用した。

学生の授業に照らせば
1日1.5時間×2コマの10回分の内容といったところ。
週1で授業があれば約3ヶ月の前期といった感じ。

で、Cの本質ならポインタということで、
アセンブリをからめてやりなおし。
そこで、この一冊を熟読。

Cプログラムの中身がわかる本
日向 俊二
翔泳社
売り上げランキング: 29356


C言語をコンパイルする途中で
アセンブリを読んでしまおう!というつくり。

環境はWindowsのCygwin環境を想定。
でも、いきなLinuxのgccでやるべきだろう。
自分の目標もLinux上であれこれだし。

学生時代はMASMというWindows用のアセンブリを
使っていたので「インテル表記」になれていたが、
gccだと基本的に「AT&T表記」なのではじめは違和感。
まあ、とまどうほど勉強してたわけでないので、
「AT&T表記」でも別に問題なし。

この本を使ってアセンブリ視点でC言語を読むと
配列もポインタも構造体も共用体も
あれ?こんなに簡単だっけ?と思ってしまう錯覚に陥る。

だれだ、ポインタ難しいっていったやつ。
俺か。

おかしい。
どんなはずというかこんなはずじゃないので、
リスト構造や木構造といった
本格的なポインタ使用のときにちゃんと理解しよう。

なので、今はLinux上のgccでC言語コンパイルして
途中でアセンブリを見てデバッグしてって感じ。


あと、今は、あのK&Rの本を読書中。

プログラミング言語C ANSI規格準拠
B.W. カーニハン D.M. リッチー
共立出版
売り上げランキング: 17088
おすすめ度の平均: 4.0
5 解説書より実践的思想書だと思いましょう
3 ある程度C言語に慣れた人が知識補強のために読む
4 初心者に読ませてよいか、ちょっと迷うが…
4 古典的教科書
2 Cコンパイラのソースを読もう


Cはこの1冊でいいと豪語するほどの本。
というか、化け物本。
なんせ、自分のもっている日本語版で
第2版316刷発行、というバージョンである。
だれが、316回も刷ったんだって話だ。
そんな、本、他にない。

ちなみに、念のためだか何のためだか
英語版のほうもスタンバイ


これらを今月やりきったら
OSをつくるというびっくりテーマのうわさの一冊を
使用予定。

30日でできる! OS自作入門
川合 秀実
毎日コミュニケーションズ
売り上げランキング: 2251
おすすめ度の平均: 4.5
5 非常に有意義なOS作成本
1 ファイルシステム無しではOSと言えない
5 とても面白い
5 ハッカーへの最短距離?
3 GUIより肝心なこと



それがおわれば、ハードの復習と
OSということで、システムコールあたりでC言語だな。

さて、プログラム苦手な自分が
どこまでできるだろうか。

現在、やりなおC中だ。
このエントリーをはてなブックマークに追加

一度、多読というものをやってみたかったからやってみた。

今年の9月の時点で本を100冊読んだ。
いつも読むようなSFやファンタジーやエッセイの小説に加えて
1,500円レベルのビジネス書や800円レベルの新書を
片っ端から読んでみた。

気になった本を気にせずとりあえず買ってみる
というルールでやってみた結果、
どの本も書いてる内容はいっしょ、というしょうもない結論が出た。
あと、本を読むということ自体が思ったより
時間の無駄でもあるんだなとも。

本をとにかく数だけでもたくさん読め!、っていうビジネス書が多い。
これは、たくさん読めば勉強になると最もなことをいいつつも、
ビジネス書そのものの宣伝を意味するものでもある。
でも、たくさん読まないとわからないことがある。

本をちゃんと読むためには数をこなす必要がある。
数をこなさないと良い本と悪い本の区別がつかない。
多読という練習量を数だけでもこなさないと、
ちゃんと本を読むということができないように思う。

また、本の時間のかけかたも大事で
短時間で済ますべきは済まし、
何度も読み直すものは読み直すというメリハリも必要。
そして、目的をもって本を読むという姿勢が必要で
ただ読むだけだと何も頭には入らない。

多読をしてみてそう感じた。

また、いい本に出会う確立ってめちゃくちゃ少ない。
今のところ100冊読んで一生本と言えるのは1,2冊ぐらい。
結局のところ、古典というか昔から読まれているというか
時代を経ても残っている本が結局いい本のようだ。
そして、どの本も結局引用元があって、
同じように皆が引用している本はいい本ってことだ。
そんな、至極簡単な結論にたどりついた。

悪い本とは自分にとって意味のない時間を
もたらしてくれる本が悪い本である。
良い本とは自分に考える時間を与えてくれる本が良い本である。

一度本を読んで何も折り目がつかない本は捨てていい。
たぶん、2,3度読み直しても自分にとって
意味のある時間とはならないだろう。

それがたとえ、ネットワークの本であってもそうである。
できるだけおぼえるというよりは考える本であるべきだ。
もちろん、基礎の基礎を学ぶ際には
本を丸々暗記するぐらいのことはするべきかもしれないが。

多読してから本の買い方・読み方が以下のように変わった。

・1,500円レベルのビジネス書・自己啓発・GTD本を読まなくなった
 →どれもいっしょ。一冊自分に合う本がみつかればいい。
・800円レベルの新書を読まなくなった
 →新書は何も頭に残らない。
・2,000〜3,000円の少し難しいなと感じる本を読むようになった
 →頭使うから
・自分の直感で本を買わないようになった
 →本読み初心者だとダメ本しか買わない。
  最近50冊ぐらいいらない本をまとめて捨てたが、直感本ばかり。
・ネットの書評をそこそこ参考するようになった
 →本をちゃんと読んでいそうだという人の書評に出会えれば
・同じ作者の本をたくさんは読まない
 →小説以上に、同じことしか書いてない気がする

あと、最近はプログラムの本ばかり買ってる
ネットワークの初心者本は卒業したと思っているので、
より頭使って体を動かす本を中心に読んでいる。
って感じかな。

その上で、人にすすめれそうな本の紹介でも。


本を読む本 (講談社学術文庫)
モーティマー・J. アドラー C.V. ドーレン
講談社
売り上げランキング: 203
おすすめ度の平均: 4.5
5 読書の目的が意識化できました
5 読解力を「科学」する読書本決定版
4 丁寧に…
4 本から何かを得たい人にオススメ
5 読書好きを自認するのであれば一読すべし

読書の方法本。
本の読み方をまずは意識したほうがいい。

フォーカス・リーディング 「1冊10分」のスピードで、10倍の効果を出す いいとこどり読書術
寺田 昌嗣
PHP研究所
売り上げランキング: 8
おすすめ度の平均: 4.5
5 フォト・リーディングの練習帳
5 速読術を超えた読書論
4 理論編は賛否あるようですが
4 コメント
4 新しい速読書


オススメまではいかないけど、うさんくさい即読本よりはコレ。
読書の具体的な読み方手取り足取りが知りたければ。
でも、この本の参考本の一冊は上記の「本を読む本」。

ビジネス書系って引用元だらけだから、
その引用元を読んだほうが絶対にいい、っていう一例でもある。


無理なく続けられる 年収10倍アップ勉強法
勝間 和代
ディスカヴァー・トゥエンティワン
売り上げランキング: 519
おすすめ度の平均: 4.5
3 言っていることはもっともだが。。
1 年収10倍アップって??
4 モチベートしてくれる本
4 使えるが、使いこなすのは難しいかも
5 基本の重要性を改めて再認識

GTDというかライフハックというならこの1冊だけでいい。
他はいらん。
GTD系の本を試しにたくさん読んでみたが
どれもいっしょのことしか書いてない。
だから、これだけで十分。

読み直すとけっこう自分は影響受けてるなと感じた。
パソコンを速くして、耳も使うようにしてとまるまる参考にして実践中。

また、別の見方をすれば本のリンク集本としても使える。
この人の本のリンクをたどったほうが
自分の直感で選ぶよりいい本に出会える確率が格段にあがる。

成功の五角形で勝利をつかめ!
三田 紀房
大和書房
売り上げランキング: 37630
おすすめ度の平均: 4.5
4 仕事と学びを一刀両断
5 ビジネス本とお別れしよう
4 私のお気に入りのフレーズ
5 痛快
5 勇気もらえます


ビジネス本をタバコのようにどうしても読み続ける人にコレ。
漫画・ドラゴン桜の作者のビジネス本。
数学は考える力という一言がインパクトある。


本を読んで気がついたのは本質を知るということ。
薄っぺらい中身の本ではなく、
本質について語っている本に出会わなければいけない。

だから、本質とは何か?という視点で
常に本と向き合ったほうがいい。

まだまだ、本読み初心者だが、
本にかける時間や本の読み方ってのがわかってきた。
そして、自分の場合はプログラムに手を出すって意味で
本を利用しないといけないなと感じている。

でも、まあ、プログラムの本質っていっちゃうと、
OSを読め!向き合え!になっちゃうんだけど。
このエントリーをはてなブックマークに追加

立ち読みしてきた。

Cisco WAN 実践ケーススタディ
土屋 師子生 竹田 直哉 生田 和正 木村 滋 牧瀬 隆之
インプレスジャパン
売り上げランキング: 38033

ISRCatalystの本に続いてという意味では
シリーズ3作目という位置づけになるのだろうか。
コンフィグを中心とした内容だった。
エンタープライズ向けになるのかな。

Ciscoのサイトで探せば似たような設定例が
手に入りそうな気もしますが、本としては他にないタイプかと。

この手の本は実際に設定してみるしかないですね。
ただ読むだけじゃ意味なし。
プログラムの本でもそうですが、動かすしかないので、
この本と同様の機器ができれば手元に欲しいところです。
でも、個人じゃちょっとお高い構成かも。

仕事でCiscoの本を参考にコンフィグを作る機会とかありますが、
最終的には動くか動かないかだけです。
設定例どおりが正しいとは限らないわけで、
本に書いてあることやマニュアルに書いてあること
がすべてってわけでもないです。
まあ、頼りっきりはダメって話です。

それでも、一応情報チェックということで立ち読み。
仕事先で誰か一人は買ってそうだから借りてやろう。
このエントリーをはてなブックマークに追加

このページのトップヘ