$ node test.js
hogehoge

assert.js:49
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: 'hogehoge\n' === 'fugafuga\n'
    at Socket.<anonymous> (/Users/nakashima/develop/git-learn/test.js:10:16)
    at Socket.emit (events.js:180:13)
    at addChunk (_stream_readable.js:274:12)
    at readableAddChunk (_stream_readable.js:261:11)
    at Socket.Readable.push (_stream_readable.js:218:10)
    at Pipe.onread (net.js:581:20)

テストが通らなかったので、git bisect badコマンドで、HEADのコミットに問題が含まれていることをgitに教える。

$ git bisect bad

次に、テストが通っていたことが確認できているコミットIDを指定してgit bisect goodコマンドを実行して、問題なかったコミットをgitに教える。この場合はinitial commitのIDを渡している。

$ git bisect good 
Bisecting: 1 revision left to test after this (roughly 1 step)
[d27eedce7b2668a995dc0e73560db6f66edb8ed7] hogehogeに戻した

すると、未検証のコミットに自動でチェックアウトしてくれる。ここで再度テストを実行し、gitに結果を教える。

$ node test.js
assert.js:49
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: 'hogehoge\n' === 'fugafuga\n'
    at Socket.<anonymous> (/Users/nakashima/develop/git-learn/test.js:9:16)
    at Socket.emit (events.js:180:13)
    at addChunk (_stream_readable.js:274:12)
    at readableAddChunk (_stream_readable.js:261:11)
    at Socket.Readable.push (_stream_readable.js:218:10)
    at Pipe.onread (net.js:581:20)

$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[10c88efbec451262196cd451ee52618b660c397b] fugafugaに変更

再度gitが未検証のコミットにチェックアウトしてくれるので、テストを実行して結果を教える。テストが通った場合はgit bisect goodを実行する。

これを続けていくと、最終的にどこでバグが混入したのかgitが教えてくれる。

$ node test.js
test OK
$ git bisect good
d27eedce7b2668a995dc0e73560db6f66edb8ed7 is the first bad commit
commit d27eedce7b2668a995dc0e73560db6f66edb8ed7
Author: newnakashima <newnakashima2014@gmail.com>
Date:   Tue Jul 24 00:56:04 2018 +0900

    hogehogeに戻した

:100644 100644 a31254a12816398ce382e6096d7923f330a9ac17 8aa758ae91689ffa39dc30412735a7ddb071032b M    app.js

問題のコミットがわかったら、git bisect resetをして、git bisectの状態を元に戻しておく。

$ git bisect reset
Previous HEAD position was 10c88ef... fugafugaに変更
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

git bisect に自動でテストをやってもらう方法

コミットが多いと毎回手動でテストを実行するのがだるい。git bisectは自動でテストを実行して問題のコミットを見つけてくれたりもする。

git bisect startコマンドには検索開始コミットと終了コミットを指定できる。

$ git bisect start HEAD 8cc2236519e3919bf9edbcd937fd3c0f464dfb04
Bisecting: 1 revision left to test after this (roughly 1 step)
[d27eedce7b2668a995dc0e73560db6f66edb8ed7] hogehogeに戻した

自動でテストを回してもらうには、git bisect runコマンドを使う。

$ git bisect run node test.js
running node test.js
assert.js:49
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: 'hogehoge\n' === 'fugafuga\n'
    at Socket.<anonymous> (/Users/nakashima/develop/git-learn/test.js:9:16)
    at Socket.emit (events.js:180:13)
    at addChunk (_stream_readable.js:274:12)
    at readableAddChunk (_stream_readable.js:261:11)
    at Socket.Readable.push (_stream_readable.js:218:10)
    at Pipe.onread (net.js:581:20)
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[10c88efbec451262196cd451ee52618b660c397b] fugafugaに変更
running node test.js
test OK
d27eedce7b2668a995dc0e73560db6f66edb8ed7 is the first bad commit
commit d27eedce7b2668a995dc0e73560db6f66edb8ed7
Author: newnakashima <newnakashima2014@gmail.com>
Date:   Tue Jul 24 00:56:04 2018 +0900

    hogehogeに戻した

:100644 100644 a31254a12816398ce382e6096d7923f330a9ac17 8aa758ae91689ffa39dc30412735a7ddb071032b M    app.js
bisect run success

手動でやるのと同じ手順をgitが勝手にやってくれた。便利。

git bisect runで指定したコマンドが成功したのか失敗したのかの判定は、コマンドの終了ステータスで判定している。0のときは成功、1 - 127(125除く)のときは失敗、と判定されるらしい。125のときはテスト不能と判定され、スキップされるらしい。

参考

git-bisect(1)

www.ohmsha.co.jp

2018-03-18

LPICレベル1に合格するためのおすすめの教材と勉強法

LPIC Linux

昨日LPICの101と102受験して両方合格したので、これから受験する人たちのために参考になる情報を書いとこうと思う。（といってもこれからLinuCとかいう試験になるらしいからあんまり参考にならないかもだが。。）

自分が買った教材

まず教材。教材がなければ何も始まらない。

Linux教科書 LPICレベル1 スピードマスター問題集 Version4.0対応

白本と呼ばれている問題集。これに載ってる問題は、ほぼそのまま本番で出題された。これ完璧にやるだけでまず合格できると思う。

Linux教科書 LPICレベル1 Version4.0対応

あずき本と呼ばれているテキスト。いい本だとは思うけど、分厚いと聞いていたのでKindle版を買った。そしたらめちゃくちゃ使いにくかった。結局ほとんど読んでない。買うなら紙の書籍を買うのがおすすめ。これ読んでから問題集を解くようにすれば効率よく知識を暗記できると思う。

ping-tの最強WEB問題集

すごく便利だし、問題がたくさんあるのでめっちゃ助かるんだけど、マニアックな問題多い。全部の問題覚えようとすると半端なく時間かかる。これが全部できるようになったら確実に合格できると思うけど、マイナーな問題にそこまでの時間を費やすのはちょっと非効率のような気がする。

やった勉強法

白本を全部読む

とりあえず白本を全部読んだ。この時点で問題が解けるようになる必要はない。

ping-tで定着させる

白本で読んだ範囲の問題を、ping-tで解きまくる。が、問題数が多すぎるのでできる範囲でいいと思う。ping-tの解説は基本的に読んではいけない。そんなことしてたら時間が足りない。わかんないところだけ部分的に解説を読んで、あとはとにかく解きまくることが大事。

マニアックな問題が多すぎなので、あまり解けなくても自信を失う必要はない。（本番を受けてみてわかった）

Linuxをインストールして試してみる

これ、あずき本にやれと書いてあるからやってみたけど、最高に非効率的な勉強法だと思う。試験が終わった後に興味があれば個人的にやってみれば十分。そもそもLPICの試験範囲、実務と乖離してる部分多すぎ。

模試を解く

模試は白本を一通り読んだ時点で早めに解いたほうが良い。自分の苦手分野がわかる。苦手な分野から補強していけば、効率的に点数上げることができる。普段Linux使ってる人でもパッケージマネージャーの細かいオプションとかX11の設定とかは難しく感じると思うので、そのへんを重点的にやれば簡単に点数あげられる。

試験直前は白本に戻る

上でも書いたけど、白本は本番でもほとんどそのままの問題が出るのでマジでおすすめ。試験前の20分くらいで読み直した内容がそのまま出たりした。

まとめ

こんな感じで1.5ヶ月ダラダラ勉強した。一日あたりの勉強時間は10分〜1時間くらい。最後の一週間は一日4時間くらい勉強した。結果、101と102両方共750点だった。試験受ける前（というか回答を提出する前）は受かるか不安だったが、蓋をあけたら合格ラインからだいぶ余裕あった。白本はマジで神。

2018-03-06

睡眠を大切にすると何もできなくなる

最近増田でも話題になったが、8時間睡眠について書く。

睡眠は8時間以上とったほうがいい。それはわかっている。8時間寝た日というのは頭はスッキリしているし体調も良い。日中思いっきり活動して夕方にシャワー浴びてから飲む酒は非常にうまい。毎日こんな風に過ごせたらなあと思う。

問題は、毎日そんな風には過ごせないということだ。8時間以上眠るということは、最低でも8時間は布団の中にいなければいけないということを意味する。毎朝7時に起きる習慣がある人は、どんなに夜更かししても23時には眠っていなくてはいけないことになる。

23時に布団に入る、というのでは間に合わない。睡眠状態に入るのが遅くとも23時ということだ。人間、毎日毎日そんなにすぐ寝付けるわけではないから、22:30には布団に入っておきたいところだ。

となると、風呂は21:30までに入り、遅くとも22:00までには上がっておきたい。風呂から上がって布団に入る前に、髪を乾かしたり、爪を切ったり、ストレッチしたりする時間が必要だ。

18:00までは会社で働いているとして、通勤時間がドアツードアで45分だとすると、夕飯の買い物も含めてだいたい19:00には帰宅する。そこから簡単に食事の準備から片づけまで含めて20:00までの時間で行うとしよう。

すると、自由な時間は20:00 - 21:30だけである。あまりに短い。実際にはイレギュラーな要素は沢山ありえるし、子持ちの人だったら自由な時間などまったくなく、逆に時間が足りないくらいだろう。

何か目標があって勉強や活動をしている人は、その時間を確保するのに苦労するだろう。健康のために運動をしている人なども、運動してご飯を食べたら一日が終わりである。8時間寝るとたしかに日中の調子は良いかもしれないが、何もできないのである。

つまり8時間寝るということは、日中のパフォーマンスが良くなるが、自己研鑽のために何かを行うことができなくなるということであり、勤め先の会社にとっては非常に都合がいい。社員が毎日8時間寝れば、日中は最高のパフォーマンスで働いてくれる上に、夜に自己研鑽ができないので能力を高めて他社に転職していく恐れもない。

何かをしようと思っている人は8時間寝るべきではない。というか、8時間も寝ていたら何もできない。会社から帰って飯を食ったら、何も考えずとりあえずマグカップ二杯分のコーヒーを飲むべきだ。エナジードリンクでも構わない。カフェインは何かをしようと思っている人を助けてくれる。何かを成し遂げたい人は恐れずに積極的にカフェインを摂って、早いうちにカフェインとの付き合い方を身に着けておくべきだ。

人間が最も活動的となる昼間の時間を会社に売り渡してしまっている被雇用者の人間は、自分の地下活動を成就させるためにカフェインの飲むべき。カフェインが人間を賃労働と言う名の隷属から解き放ってくれるはずだ。

2018-03-03

Linuxの基本コマンド一覧を作ってみた

Linux シェル

LPICの勉強がてら基本コマンド一覧を作ってみた。

github.com

まだ全然足りてないのでこれから増やしていこうと思う。

というか、LPICはLinucとかいう得体の知れない試験に変わってしまうのだろうか。。

lpi.or.jp

LPI-Japanでは、設立時から積極的にLPICの試験開発に携わり、LPI Inc.との協力により試験の品質改善を行うとともに、IT技術者の中立かつ公正なスキル認定に努めてきました。しかしLPICは世界中の国や地域を対象とした試験のため、各国のニーズの違いに対応できず、日本の市場が求める技術変化への即応や高い品質と受験者に寄り添ったサービス提供に対応することが難しいという現状があります。
今回、LPI-Japanが従来のLPICに加えて、独自のLinux技術者認定試験「LinuC」を発表する目的は、これらの日本の市場が求めるニーズに応える認定試験を提供することにあります。

っていう文章なんか嫌な予感が少しする。。方眼エクセルの使い方が出題されたりして。

2018-03-01

もくもく会がしたい

もくもく会がしたい。近所にもくもく会を開いている人たちがいない。居るのかもしれないけどネットで参加者募集とかしてないっぽい。もくもく会を開催したい。会社の人とかは気まずいので利害関係無い人同士で集まってもくもく会したい。

あ〜もくもく会に参加してくれそうな人いないかなあ。家帰って勉強しようと思ってもはかどらないんだよな。ついついアニメ見てしまったりプログラミングと関係ない本を呼んでしまったりYouTube観てしまったりしてしまう。

コワーキングスペース月額契約することも検討している。ただ、初期費用がめっちゃかかるんだよな。ただでさえ貧乏な俺なのにそんなことに使う金はあるのか、という心配がある。

とにかくもくもく会がしたい。どんなにやる気が出ない時でも強制的にやらざるを得ない状況を作り出してくれるもくもく会に憧れる。もくもくしたい。もくもくしたい。

コワーキングスペース余裕で借りれるくらいのお金を振り込んでくれるお客さんが現れないかな。コワーキングスペース借りて頑張って作業するので毎月定期的に副業に適したある程度軽めの仕事を振ってくれるお客さんが欲しい。そのためには営業活動をやらなければ。名刺を作り、ホームページを作り、Facebookに顔を出さなければ。。。

そういうことをしているうちに手を動かす機会をどんどん損なっていくのだろうな。だからやはり営業活動より先にもくもく会をやるほうがプログラマーは成長するのだ。もくもく会をしたい。最近はラーメン大好き小泉さんとりゅうおうのおしごと！観てます。姉弟子が良いですね。30台底辺プログラマーの日常から脱却したい。

2018-01-20

ノンエンジニアの営業とかディレクターの人とかがコード読み書きできた方がいい理由

ポエムプログラミング

この文章を書いた理由

大学のときの後輩と飲んでて、彼はとあるWEB企業でコンテンツ制作的な仕事をしているのだけど、彼の会社の人材はエンジニアが半分を占めるらしい。

後輩は自分の4つ下で、自分がプログラミングを始めた年齢よりも若いので、今からでもプログラミングやんないの？　とか聞いたら別に興味ない的な返事が帰ってきた（ような気がする。かなり酒飲んでたので具体的な返事は覚えてない）ので、エンジニアじゃない人がコード書ける（読める）ようになっとくとどういう嬉しいことが起こるかを書いておこうと思った。

お客さんとか社外の人に対して、自分が扱ってる製品の説明ができる

自分の前職は全然IT系じゃないけど、やはり技術を売りにしている会社で、そこでは営業をしていた。でも技術の詳細については教育を受けたわけではない。だからお客さんに対して商品説明するときに苦労した。

テキトーなことは言えないので技術に関する問い合わせに関してはいちいち技術部に確認のための質問をしないといけないし、お客さんに対する返事も遅くなる。スケジュール的な余裕が無いときとかは結局現場に入ってる技術部スタッフに時間を作ってもらってお客さんと直接打ち合わせをしてもらうみたいな、最初からそうしとけよ的な流れになることも多かった。

しかしある程度の技術的な知識があれば、そういうムダはかなり省ける。打ち合わせの初期段階とか製品の説明とかの段階で必要なのは具体的な実装とか構築レベルでの話では無いだろうから、打ち合わせの結果に問題があれば技術部からツッコミをもらうという程度で済むようになるはずだ。

ディレクター職の人の場合も同様で、外部ベンダーとかに何かを依頼するときに自分の製品が一体何をやってるのかということが大まかにでもわかってれば、わざわざ技術部の奴を呼んできて説明をさせる手間が省ける。

もちろんある程度大きい会社になってくると本職でもない人間が半端な知識で話すのは難しく、結局機嫌悪そうな技術部の奴のおだてたりなだめたりしてお客さんに対する説明をさせる必要があったりするのかもしれない。

でもこういうのは細かいところで色々恩恵がある。コミュニケーションの速度が速くなり、誤解も少なくなる。技術の話が通じる営業とかディレクターは、社外の人間からも結構信頼される。そもそも自分が売り込んだり制作したりしてる製品のことなんだから、それについて知識が多くて困るということはあり得ない。コードが理解できるとさらに自信を持って製品について話すことができるはずだ。

技術部の奴らから一目置かれる

一部のエンジニアは、あからさまに営業とかディレクターを見下している。コードが書けない奴ら、スーツ着てる奴ら、というくくりだ。

見下すだけではなくて、信用もしていない。彼にとって営業とはテキトーに夢みたいなことを客に吹き込んで仕事を取ってくる奴らと同義であり、ディレクターとはろくに打ち合わせもせず無茶なスケジュールを組んでくる若造のことである。

そういうエンジニアの傲慢な態度を実際に目の当たりにした人も多いことだろうと思う。彼らは技術力で上下関係が決まる世界で生きていて、それが世界の全てだと無意識に思ってしまっているので、技術がない人のことを自然体でバカにしてしまう。

そんな一部の傲慢なエンジニアの態度も、技術がある人とか技術に興味を持っている人に対してはいきなり優しくなることが多い。コードを理解できる人に対しては、「あいつはわかってる営業（ディレクター）だ」という扱いをする。

結果的に、コードを書けるようになっておけば、いつも機嫌悪そうだったエンジニアとも意思疎通できるようになり、普段はすぐ突き返されてた質問とかも気さくに答えてくれるようになったりする。

前項でも書いたように大きな会社だと社外の人に対しては自分が独自に会得したプログラミングの知識を打ち合わせとかで活かすというのは難しかったりするだろうが、対社内のエンジニアについてはどんな職場だろうとコード書けるようになることの恩恵が享けられると思う。

ともすると自分単体で処理できる作業の幅が増える（嫌な技術部の奴らとの会話を減らせる）

コードが書けるようになると、ちょっとした作業は自分でできるんだから自分でやれよ、という流れになる可能性も高い。毎月の集計処理的なスクリプトの実行は自分でやったほうが速いということは十分にありえる。

コード書けない人とか黒い画面怖い人だと、そういう定例的な作業を毎度毎度エンジニアに頼む必要があるが、ターミナルを開いてサーバーにログインしてコマンドを叩く、位のことができれば自分でやれる。今エンジニアは人手不足で忙しいし、売り手市場だから偉そうにしてることも少なくないだろうから、ちょっとした作業を自分でできるようになると嫌な態度を取るエンジニアとのコミュニケーションを減らせて精神衛生上良い。

まとめ

実際に手を動かす人じゃなくても商品知識を持っとくというのはどんな業界だろうと当たり前のことで、例えば飲食の会社に総合職として入社した人であっても2年間は現場の厨房やホールで働くと聞く。それによって商品知識を得るわけだ。現場で作られている商品が核となって全ての業務は進んでいくのだから当たり前である。

それがWEBとかシステムに関しては当てはまらないということはない。WEBの会社で働く人は全員プログラミングができるようになっといて悪いことがあるはずがない。