おうさまのみみはロバのみみ

ネット上での木の洞

あなたの技術書の読み方

なお、技術書はこう読め!みたいな話ではない。

愛聴?しているpodcast の通称しがないラジオで「あなたの技術書の読み方」というフィードバックテーマ(お題?)がでていて 技術書の読み方は読む人のスキルやその技術書でなにを習得したいと考えるか?がバラバラで難しいよなーと思った。

そこでそういえば技術書の読みかたを振り返るのもいいかもしれないと思ったのでKPT形式で振り返ってみようと思う。

元ネタのpodcastは↓、SIer出身じゃないけど割りと楽しく聞いている。 たまに自分のハンドルネームが読み上げられると恥ずかしくて死にたくなる。 (主に会社で聞いているので身悶えしてるときはだいたいそう。)

shiganai.org

前提:

blog.shibayu36.org

ぼくの技術書の読み方のスタンスはshibayu36さんの↑のエントリを参考に自分風にアレンジしたものになる。

  • 目次を見ながら学びたいことを探す
  • 読みながら印象に残った部分をメモ書きする
  • ブログにまとめる

Keep:

目次をみながら学びたいことを探す

shibayu36さんは疑問形式で書くとあったがぼくの場合それだと多すぎたり少なすぎたりして微妙になってしまったので一旦疑問形式は置いておいて どこらへんが目次のなかで自分の琴線に触れたのかをメモしておくようにした。

琴線に触れるものがなさすぎると自分の現状のスキルとミスマッチすぎるし、逆に何書いているかわからないのが多すぎると対象読者のレベルに達していないという判断をしていてだいたいいい感じのフィルターとして機能している。

ブログにまとめるときに気になったことが解消したか?などを後出しだが疑問形式で出せるようになったりしたので割りと自分の中ではいい感じ。

読みながら印象に残った部分をメモ書きする

かなりいい。 疑問に思った部分や自分はそうは思わなかった、完全には同意しかねるが気持ちはわかる的なやつもとりあえず書いてる。 読んだときはこう思ったが、そのあとで考えが変わった…とか時間が経過して読み直したら以前とは感じ方が違ったとかまれにある、そういうとき役立つ。

とにかく雑に書いて、雑に感じたまま書くようにしている。 その中で唯一気をつけてるのはページ数、あとで探しやすいように

以前はポストイットでやてたが管理が大変なので最近はiPad Proでメモ書きしている、その際気になったページが書かれているのであとで見返すときに捗る。

ブログにまとめる

当初気になったがあとの章で説明されて解消したとかたまにある、なのでそういう取捨選択を行う機会を作ってると考えるとやはり重要。

あとメモをそのままブログに書くと何書いてるかさっぱりわからないし、メモを読み直してもわからないことがあって結局本を持ち出して書かれたページを読んでしまう。

なのでブログにまとめたときには文体や流れにはさほど気を配っておらず、とにかくその時読んでなにをどう感じたかを出来るだけ思いつくままに書いている。

Problem:

なにを目的、目標とした読書か?

この技術書を読むモチベーションはどこにあるのか、またそれらは読了後どうだったのか?を書けていない。 だいたい書き忘れてしまう。

読み方があまり効率的でない

技術書は小説のようにさくさくと読み進めるのが難しいのでどうしても時間がかかってしまう。 時間がかかるとダレて読まなくなってしまいがち、結果長い期間読んでなくて内容を忘れてまた読み直してしまう。

Try:

購入ボタン押したらすぐにメモ取る

なにを目的、目標とした読書か?

どういうモチベーションで購入したか?を書いておく。 読了後、どうせブログ書くのでそのときにその結果もあわせて書く。

写経しない

読み方があまり効率的でない

ぼくは技術書を読むときはだいたい出来るだけ写経しながら読み進めていくのだが あまりこの方法がいいと思えなくなってきた。 軽く一読しきってしまってから写経を行ったほうが効率が良さそうな気がしている。

まとめ:

読書スピードがあまり速くないし、理解力も決して高くないので愚直に行くしかないのだけど もう少し効率よくしたいなとは思っていたので年に1回くらいは読書方法の振り返りをKPTでやっていくのはいいかもしれないとエントリを書いてて思った。 人によっては技術書を3回読むとか、いろいろあると思うけどまだ「これがぼくのなかでベストプラクティスな読書方法だ!」と言えるところまでいけてないので改善していきたい。

ぼくは才能がない、あるいは中途半端にあるということ。

響け!ユーフォニアム 北宇治高校吹奏楽部、波乱の第2楽章」を読了した。 響け!ユーフォニアムはアニメも劇場も読んだが今作がもっとも心を揺さぶる小説だった。 まだ残り2ヶ月ほどあるがぼくの中でベスト・オブ・ジ・ブックが本日確定した。

少なくともぼくが今までの人生で読んできた小説、本のなかで5本の指に入るくらい衝撃と心をかき乱した傑作だと思う。 響け!ユーフォニアムは本当に人間描写というか心理描写が見事の一言に尽きる。 この余韻が薄まらないうちに心のなかに渦巻く感情を吐き出しておかなければならないという衝動にかられて書いている。

元々ISUCON7予選に参加する予定だったのでそのあとにご褒美的なものとして終わってから後顧の憂いなく読み耽る予定でいた。

当初、1冊目を読んでいるときには普通にいつもの読書感想文を書こうと思っていたのだが、2冊目を読んだところで考えが変わった。 読書感想文はまた別で書くか、あるいは書かないかもしれない。 とりあえず読んでいて感じたり考えたエモい文章を羅列しておく。 多分あとで読んで恥ずかしくなり死にたくなるタイプの文章なのでノイズが多いことだと思う。

また、小説を読みながらその時その時で思いついたことを書き出しているので取り留めがない点と話しが飛ぶ点は容赦願いたい。 またこの話しはいわゆるネタバレを多分に含んでいるため、それがいやなかたは回れ右してほしい。

結論:

さて、普段の読書感想文ではなく何を書くのか?という話だが端的に言ってしまえばポエムである。 しかもネタバレを含んだポエムだ、これほど酷い話もない。

しかしながら、今作を読んで改めて「自分は何になりたいのだろう?」と考え直すきっかけを得た。

さて、まずは結論から入ってしまおうと思う。

ぼくは今作を読んで改めて「プロになりたい」と自覚した。 獏っとした表現になってしまうがそもそもプロとはなんなのだろうか?

お金をもらっていればプロなのだろうか?

顧客の望むもの、あるいは超えるものを作り出すのがプロだろうか?

よく巷で語られるプロフェッショナルとはなんなのか?

フリーランスのように自分の実力だけで食べていける人間はプロか否か?

ボク個人はこれらに対する解答は自分で見つけたものだけが真実であり、普遍的な答えがないのが正解だと思っている。 ではぼくが考えるプロとはなにか?

  • 顧客では出来ないことを技術的な課題を解決することの出来る人間、チーム、あるいは会社。
  • そして組織に所属しなくても十分に生活することが出来る技術力を持った個人。

この2つの条件を両方満たしている人がぼくにとってのプロなのだと考えるに至った。

とはいえ、元々の考えと改めて考え直しただけなので然程時間がかかったわけではないのだが。

努力と苦悩

自分には才能がない、とは誰しもが1度くらい考えたり感じたことがあるのではないかと思う。 少なくともぼくは自分にプログラマ、エンジニアとしての才能を感じたことはない。

今作のユーフォニアムがなにをテーマにしているのか?と問われたらぼくは努力が生み出す懊悩だと思う。

今作はさまざまなケースで努力、あるいは努力する吹奏楽部メンバーの苦悩やそれにまつわるストーリー実に詳細に描かれている。

恐らくは似たような経験が著者の武田綾乃氏にある、あるいは見聞きしたのだろうと思う。

例えば毎日遅くまで残って練習しているが努力の仕方が間違っている、努力しているように見えるほうが評価される。 実力は劣るが努力している先輩のほうがコンクールに出場したほうがいいなどなど吹奏楽に限らず社会に出てからも似たような話しは枚挙に暇がない。 そういう意味でも今作はいろいろと自分にとって考えさせられる作品だったと言える。

最初にいうとボク自身のエンジニアとしての力量は決して高くないと見積もっている、せいぜいが中の下か下の上だろう。 だからこそ努力していると思っているし、その努力の効率が多のエンジニアに比べて悪いとも自覚している。

だからだろうか、数こそ少ないが映画やアニメでは泣いたことがあった。 ただ数多くの感動作と呼ばれる小説を読んでも心がワクワクしたり、動くことはあっても泣くことはなかった。 目に涙が浮かぶ…くらいまではいったことがある。

だが生まれて初めて小説を読みながら涙が出た。 悲しくてではない、それでは泣きはしなかった。 誰かと自分を重ね合わせてか?それもない、ユーフォニアムには登場するさまざまなタイプの人物が登場するが特定の誰かに自分を重ね合わせるような感情移入の仕方はしたことがない。

では何故涙したのか? 自分自身でも半信半疑であるのだが恐らくは悔しくて泣いたのではなかろうかと思う。

自分はこうはなれなかった、それが悔しくてもどかしくて涙がでてしまったのだろうと思う。 もっと上手くやれたはずだ、もっと上にいけたはずだ、後悔の念が生まれては消え、そしてまた生まれるという感情の渦が発生し結果涙という形で現れたのではないかと思っている。

だからだろうと思うが滂沱したというよりはギリギリまで注いであるカップから水が1雫溢れおちるようにふつりと涙が流れたっきりだった。

恐らくこれは直近でISUCON7というイベントがあったことも無関係ではないだろうと思っている。

目に見えない努力というかたち

後編の330ページ以下のような一文がある。

額からにじんだ汗が、顎を伝い落ちただけだった。なんだかぞわぞわする。肌寒さが全身を覆い、なのに肝心の身体の中身は空虚しか詰まっていない。何も考えられず、思考はがらんどうだった。突き出された現実に久美子はしばし茫然となった。

この一文を今読めたことをぼくは感謝するべきなのかもしれない。

文章自体に特別な点は恐らくない。 話しの流れも恐らくは特別なことはなにもないだろう。

しかしながらぼくはこの一文の前の状態から胸がドクドクと波打ち、何十分の一かはわからないが久美子たちの緊張の一端と思いを共にしていた。

これは先日行われたISUCONで似たような緊張を味わったからこそだろうと思う。 これがなければ本作がここまで味わい深い感想にならなかったと思っている。

そしてその後の展開でぼくは自問自答することとなる「ぼくは彼、彼女らほどISUCONと真剣に向き合っていただろうか?」と。 もちろん部活動とISUCONでは意味が全く異なると思うし、それにかける時間だって全く異なる。 だけど一瞬、ほんの一瞬だけそう考えてしまったのだ。 そして一度考えてしまったものをなかったコトにすることは出来ない。

ぼくはこのことを直視せざるを得なくなってしまった。

無慈悲な才能という壁

またしても後編になるが以下の文章を読んで心の琴線が揺れ動いてしまった。 191ページ目の指導をサポートしてくれる橋本という男性、アニメでも登場したので覚えているひともいるのではないかと思う。

「ぼくは君に対しては『高校生にしては』言いたくないねんなぁ」

この一文を読んでぼくは「非常に残酷な一言だな」と感じた。 恐らくは「君」以外であったならこの一文は生まれなかったはずだからだ。 そしてぼくは「君」側の人間ではない、だからこそ感じ入るところがあったのだろうと思う。

他にも似た感情を想起させる一文がある、ページ247の以下のものだ。

「みぞれより自分のほうが上手いって、思ってたかった。だって、みぞれよりうちのほうが絶対に音楽が好きやんか。苦労してる。つらい思いもしてる。それやのに、みぞれのほうが上なんて」

この一文を読んだときぼくはみぞおちの辺りに重いものが突然発生したように感じた。 まるで我がことであるかのように感じたからだ。 もちろん状況としてぼくとでは努力の総量、質が全く異なるのだが頭の中で一瞬でも考えたことがないか?と言われたら否定できない自分がいるのだ。 醜い、直視したくない自分の汚いところがありありと噴出してきて「何故ぼくではないの?」と一瞬重ね合わせるところがあった。

氷菓で有名な〈古典部〉シリーズにも福部里志の屈託として似たようなシーンがあるがあちらは明言を避ける形で苦悩と屈託を表現していた。そういう意味ではより直接的な心を抉ってくる一文だと感じた。

「そのときにわかったの。みぞれは、選ばれた人間なんやって」

そして最後のこの一言が諦観と自分の複雑な気持ちを実に上手く表現していると実感した。 つらい、認めたくない。でもあまりの実力差を認めざるをえない。 持たざるものだからこそ、持つもののまばゆい輝きを認めざるをえないのだ…と強く実感させられた。

ぼくは響け!ユーフォニアムのキャラクターはだいたい好意的にみている。 ただし1人だけ例外がいる、それが先程から登場している鎧坂みぞれという人物だ。

嫌う理由は色々あったと思うだがこれだ!といえるのは「特定の誰かに強く依存しすぎている」点が気に食わなかったのだろうと思う。

ここだけリアリティーが抜け落ちたように感じていたのだ。 こんな人物がいるのだろうか?他の登場人物は多少の誇張はあれどもその辺の高校に探せばいるのではないかと思わせる人物ばかりだ。 それはあの田中あすか先輩にしてもそうだ、あそこまで完璧超人はいないだろうがそれに近い人物というのはいるだろうと思っている。

一点、この鎧坂みぞれはそうではない、物語めいてぼくの目には写っていたこともあり、違和感が拭えなかった。 今まで読んだ響け!ユーフォニアムのどの人物にもそのような感情を宿したことがなかっただけに純白のキャンバスについた真っ黒な染みのように写っていた。

それが今作で印象が反転した。 魅力的である、とはいえない。少なくともまだ…。サイドストーリーなどで後日談があれば更に変わるかもしれないが。

だが汚点であるような印象やリアリティーにかける印象はくるりと手のひらを返すように評価を変えた。

少なくとも鎧坂みぞれに対するネガティブな感情というのは綺麗サッパリ消えてなくなった。

音楽とシステム開発似ている

ハッカーと画家をぼくはまだ読んだことがないが恐らく音楽とシステム開発は似たようなものなのかもしれないと今作を読んで感じた。

1人でも音は出せる、楽譜通りに奏でることもできるだろう。 でもそれは合奏が生み出すハーモニーとは全く次元のことなる表現方法だ。 そして、それはシステム開発にも当てはめることができるのではなかろうかと思う。

以前なにのpodacstであるかは定かでないが響け!ユーフォニアムはチームビルディングの話しである。といった感じの発言を聞いたと記憶している。 当時のぼくは「そうね、メンバーのモチベーションもバラバラ本気で全国いきたいやつ、そうじゃないけど周りに合わせているやつ、辞めていくやつ。色々いるしあれこれ胃が痛くなるような人間関係の問題や技量的な問題がでてくるもんね」と軽く考えていた。

それはそれで正しいのだろうと思う。 ただ今作は努力の価値やその方向性という意味でいろいろと考えさせられる部分が多くあり、先のチームビルディングの話しを思い出させた。

才能あるものだけが選択できる未来

ぼくたちがウンコードを生み出してもお金をもらえて生活できているのはぼくたちの仕事が持ち得る幅が広く、なによりも分母が大きいからではないかとこのことからふと考えることになった。

もし音楽家のように誰もが自分の書いたコードを把握できてしまうような状態であったならウンコードを書いた人間は死にたくなる思いにかられるのではなかろうか。 その人は次は二度と同じ過ちはしない!と強く思うかもしれないし、もしかしたら自分には才能がないと諦めて別の道を模索するかもしれない。

もし機械がプログラムを書くのが当たり前になれば音楽家と同じようにぼくらの大半の才能がない人間は目指すことすら諦めないといけない状態になるのではないか?

それは恐ろしい、とても恐ろしい話だ。 だが同時に悪魔的な魅力もあるのではないかと感じてしまった。

いままでのぼくならそれは素晴らしい世界だと素直に感じられたと思う。 だが今作を読んだあとでは素直にそれだけを歓迎する気持ちにはならなかった、胸中複雑ではあるがマーブル模様のようにモヤモヤとしたものを感じている。 その上でぼくはやはり機械がぼくらの職を奪っていくべきだと考えているつもりだ。

かつてはプログラマも音楽家と同じくらい狭き門だったのだろうと思う。 それが一般にPCが普及し、扱える範囲が爆発的に広がったことでぼくたちは専門家の基準を満たさない人間でも生活できるようになってしまったのではないか。

将来、ぼくたちはかつての馬丁や水夫のように消え行く存在なのかもしれない。と改めて深く考えさせられた。

そういう意味ではこの時代に生きる人間の特権のようでもあるし、今作を読んで改めて考える機会が出来たのは良かったのではないかと思う。

まとめ:

まあまとまらんよな?という思いなのだが。 才能というのはやはり悲しいかな厳然たる事実としてぼくの前にあって、努力すればいいというものではないよなと改めて思った。

努力の方向性を間違えればそれは努力していても意味がないわけではないが目的は達成できない。 努力の質が低ければ無駄に時間を費やすことになり、これも目的は達成できない。

努力とはなんであるか?目的や目標を達成するための手段である。 努力の総量が足りていたとしても周りに才能があり、同じように努力していればこれまた目的を達成することが出来ない。

最後に341ページの吉川優子部長の言葉を引用したい。 いや心情的にはここで読んでほしくはない、本文を是非とも読んで感じたままに余韻を楽しんで欲しい。 だがこれを語らずにはいられないという思いから引用させてもらう。

「去年は滝先生がきて一年もたってへんかったけど、今年は二年目やん。去年に比べて、そのアドバンテージがある。上手い新入生もいっぱい入ってくれた。やけど、負けた。うちらが弱くなったんじゃない。ほかが、強かった。」

ピンクリボンの優子。

登場当初はクソウザいキャラクターだなと思っていたがあれよあれよという間に好感度がトップクラスのキャラクターに成長していった。

この「ほかが、強かった」で一度区切った辺りに苦悩や懊悩が読み取れて非常に悔しいという心情が伝わってきた。

ぼくも「やりたいこと」に対する貪欲さが足りていない、もっともっと貪欲さを表に出さないといけない。 それは驕りであり、慢心なのだと改めて学んだ。

あまり引用はしたくなかったが心が痺れる一文なので引用とその感想を述べて〆とさせてもらう。

次回作の響け!ユーフォニアムも大変楽しみにしている。 是非ともグサグサと心を抉るより、感情を揺さぶる良い作品を書いて欲しい。

駄目なコードには3つのパターンがあるが最後のやつだけはどうやっても許せない

一般的に駄目なコード、あるいはレガシーコードやウンコード、スパゲッティーコードなどなど駄目なコードに対する語彙は非常に多い。 ただじゃあこれら全部が同列の駄目さかというと個人的には違うと思っていてその所感を書いて整理したいと思う。

よくいう技術的負債というのは「きちんと書いてる時間がないのでとりあえず動くコードを書くけど将来的に直す!」みたいなコードのことだと認識していて 本来お金をもらって仕事をしている以上全ての駄目なコードはこうなっていないといけないと思ってる。 お仕事である以上納期を守るというのは最低限守らないといけない約束事なのでそちらを優先した結果あまり良くないコードが残ってしまうのは仕方のないことだと思う。 納期を無視してでも綺麗なコードを書けとはさすがにどんな人でも言わないと思ってるが世の中トチ狂った人がいないとも限らないので断定は避けたいと思う。

ピヨピヨしたコードは新しくジョインした直後のチームメンバーや使用しているフレームワーク、言語、ライブラリなどに馴染みが薄い人が書きがちなコードのことで誰もがかつては通った道だと思う。 このコードはお金をもらっている以上それを言い訳にすることはできないが少なくともきちんとチームでコードレビューすることが浸透していれば問題になることはないと考えている。 技量が急激に上がることが少ない以上、これらの状態は短いか長いかの違いはあるが必ず発生するし発生しないわけがないと考えている。 なおコードレビューやチューターがいないなどのサポートがない場合は伸びしろがあるコードだったとしてもピヨピヨしたコードではなく次に紹介するコードに該当するとぼくは考えている。

タイトルで最後と表現した一番駄目なやつ。 遭遇すると書いた人間やチームを呪わずにはいられず、ソウルジェムが一気に濁ってしまう危険な呪文。 ガンジーが核持って殴り込みに来るレベル。

そして得てしてエンジニアが揶揄して例題にあげる駄目なコードでもある。 なお伸びしろのあるピヨピヨしているコードもそれをサポートする仕組みや体制がなければ時間が経過するほどにこのコード状態になると考えている。 ぼくはこれらのコードをウンコードと呼んでいる、たまに食事の席で発言してしまい「ヤッチマッター」って顔をしている。

まずなにが駄目かというとウンコードの多くは書き捨てのスクリプトであることだ。 その場でしか使わないし、大したシステムでないからとりあえず動けばいい…みたいな考えで書き捨てられているのがこれに値する。

そしてこれらの問題は書いた時間の10倍近い労力を要さないと修正することが困難であるという一事に尽きる。 まず「なにをしているのかわからないコード」を読み解くのに時間がかかり、「不可思議な挙動をするコードを調べる」のに時間がかかり、「そもそもこれバグってんじゃねえか!」という現象に苛まされ、「直した!と思ったら全然関係ないところで使用されたあげくにエラーになってしまい」、「それらを全て問題ないかチェックした上でリファクタリングバグフィックスを行い」ようやく通常のコードリーディングや修正と同等のタスクに着手出来る状態になる。

とぼくは思っていてウンコードはどう取り繕ってもウンコードで書いた人そのものを攻撃する気はないがその状態で放置したマネージャーに対しては「殺すぞ!」くらい言っても許されると思ってる。 コードレビューがされないのはマネジメントの責任だとぼくは考えている。 テストのないコードがレガシーなコードならば、レビューのないコードはウンコードだ。

くらい言っても許されるのじゃあなかろうか。

何がいいたいかというとコードには賞味期限があってどんなに書いた当時素晴らしいコードも時間が立つに連れ鮮度が落ちていく。 問題なのは定期的に腐った、あるいは腐りそうなコードを適宜選別して捨てるものは捨てる、新しいものと入れ替えるなどのタスクが必要だということだ。

スーパーに置かれている野菜が腐って異臭を放っている状態で放置されていたら誰だって怒るだろうと思う。 それと同じことをプログラムコードで行って何故クレームが来ないと思えるのか?

本当の意味で顧客のことを考えるならサポートを充実させるよりも何よりもこの手のウンコードを撲滅することを目指すべきじゃあなかろうかと考えることが増えた。 特に顧客は自分たちでは実現できない、あるいは時間がかかりすぎることをお金を払ってぼくたちの技術力を買っているのだから、ぼくたちはその金額に見合うだけの技術力を提供する義務があると思う。 金額の結果がウンコードならそれはそれでいいが、それっきりにしてもらうか負債として会社の未来に残さないでいただきたい、書いたやつが墓場まで持って帰ってくれ。

…もう人間がコード書くより機械に書かせたほうが質の高いコードが出来上がるんじゃねえかと最近割りと本気で思ってきた。

休日の過ごし方…と言われても

今週のお題「休日の過ごし方」

だいたい9時くらいに起きる。 10時くらいまで朝ごはんを食べたりコーヒー飲んだりしてのんびりまったり過ごす。 11時くらいから読書したりゲームしたりコード書いたりする。 12時昼飯食べる。 13時風呂掃除する、その後家を出て出町柳あたりの河川敷か三条近辺のカフェで読書する。 19時くらいに家に帰って晩御飯食べる。 20時くらいにコード書くか読書。 22時くらいに風呂入る。 23時くらいから寝るまで読書かアニメみる。 25時くらい寝る。

一応休日の午後は天気が雨でない限りは、出来るだけ外に出るようにして人間強度を下げている。 あと家だと集中して読書出来ないというのもある。

東京と違って休日に勉強会があるとだいたい午後からの予定が勉強会で埋まって晩飯食うあたりで普段の休日と同じに戻る。 基本的に計画を外部要因で乱されるのを嫌がるタイプの人間なのでここ半年くらいだいたいこんな感じのサイクルで休日過ごしているが割りと満足している。

人生で一番行きたい場所

今週のお題「行ってみたい場所」

気になっている観光スポットや、死ぬまでに一度は行きたい国、はたまたファンタジーの世界など、あなたの「行ってみたい場所」を教えてください。皆さまのご応募、お待ちしております。

とのことだったがいろいろ忙しくて下書きで箇条書きしたままになってたので放流。 多分お題の期限はもう過ぎてしまっているんだろうと思うが構うこたあねえ。

イタリアのヴェネツィア

元々イタリアは行ってみたいと思ってたがARIA/AQUAを読んで俄然行きたくなった。 聖地巡礼先としてはカフェ・フローリアンは外せない。

パラシュート勉強法を生兵法で使ったら大怪我した

以前ブログで少し触れたがパラシュート勉強法という概念がある。

luccafort.hatenablog.com

で、ちょうどこのときRails触っていてなかなか思うように進捗を出せていなかったのでちょうどいいと生兵法でパラシュート勉強法でやってみたら悪化してしまったので反省点と感想をまとめておこうと思う。

結論:

パラシュート勉強法自体は悪いものではないと思う。 ただし段階によってはマッチしないケースがあるので 自分がどの段階で、パラシュート勉強法で効果があるかどうかはきちんと理解しておく必要はある。

どこが駄目だったのか?

まず前提として自分のステージというか段階がミスマッチだったと思っている。 Railsが本当になんもわからん、これはヘルパー関数なのかRailsの機能なのか?がわからない状態で 簡単な機能を実装したりググりながら実装していた。

問題はサンプル通りに実装しているわけではなく少し変えて実装していた点。 特にハマって「パラシュート勉強法、少なくとも自分の段階ではあわない」と思ったのがヘルパー関数link_toやurl_forは一体どこから出てきたのか? どういう実装でなにを引数に渡せばいいのか?みたいなところが無性に気になったりしてノイズになってしまった。

あとハマったのがhoge_pathやnew_fuga_urlみたいなメソッド。 こいつらの命名規則や機能を盛大に理解していない状態で使っていたら少しモデル名やルーティングを変更した結果 変えていないところでエラーになって大層頭を抱えた。

段階 パラシュート勉強法 備考
無知識 なにもわからない状態
初級者 多分いちばん効果がある
中級者 ある程度効果はあるがここらへんから体系的に学びたくなる
上級者 わからん チョットデキルヒトコワイ
神はなんでも知っている アイキャンフラーイ

じゃあどうすればいいのか?

以前のブログでも引用していたが結局

勉強の初期段階よりも、学習が進んでから全体の横串を通すときに行ったほうが効果的です

ということで初期状態で採用するのはあまりよくないなって感じました。 むしろ初期状態は入門書レベルのものを一瞥して、ある程度機能の把握(使えるかどうかは別だが読める、想像できる)が必要だなと実感した。

MVC大まかにはわかるし、RailsライクなPHPフレームワークなら触ったことあるし初期状態じゃないのでは?と思って試したが慢心していたなって感じで反省している。

今回のぼくのケースはまさにこれで最低限知っているべきことを調べていない状態で「パラシュート勉強法がいいらしいぞ!」という情報をみて ちょうどタイミング的に良かったことと半信半疑ながらとりあえずやってみないとわからんだろ、と思ってやったら良くなかったね!って結果に落ち着いたってだけの話だと思ってる。

まとめ:

というような状況だったので↓の書籍をKindleで購入して写経はせずに通しで読んだ結果、わからなかったものがどういう理屈で動いているのかがわかって非常に捗った。 基本の動きというか機能レベルをさらっと目で追うくらいはやったあとでパラシュート勉強法を採用するのが一番コストが低いのではないかと感じた。

Ruby on Rails 5アプリケーションプログラミング

Ruby on Rails 5アプリケーションプログラミング

生兵法は怪我の元、というが正しい状態で手法を採用しないとまあ効果も半減するよね?というだけの話なのでまあそらそうだって感じ。

ISUCON7 に参加して惨敗した

isucon.net

ISUCONとは「いい感じにスピードアップコンテスト」の略。 恐らくISUCON3あたりから観測はしていて本番出場者の攻略エントリや予選敗退者の反省ブログなどを読んで面白そうだなとは思っていた。 今回初参加してみて、あわよくば本戦行ければなーと淡い期待をしていたら木っ端微塵に吹き飛んだ。

「ガトリンガー葉の仲間たち」としてcs_sonar、kawakattsun、luccafortの3名で1日目勢として参加。 順位は暫定55位で当然本戦出場圏外、ぼくは正直全く貢献できなかったと思っていて非常に悔しい。

それでもこの順位なのはほぼインフラ周りをみてくれたcs_sonarのおかげだと思ってる、マジ最高。

ISUCON7の予選問題とその解説は↓、目を通しておくだけでも楽しいぞ!

isucon.net

結論:

ISUCONは「周りでみてわいわい」するより参加して「ああでもないこうでもない!」するほうが断然楽しい。 なのでもし「やってみたいけど自信がない…」という何年か前のぼくのような人は是非とも仲間を(無理やり)誘って参加するほうがいい。

やる前までは割りと憂鬱な気持ちになったり、面倒くさいなという気持ちがなかったわけではないのだが いざやってみたら凄まじい後悔とやりきれなかった、もっとスコアをあげれたはずだ!!!という思いでいっぱいになった。

やる前までは今回やったら満足するんだろうな、とか思ってたけどかなり悔しい思いをしたので 来年こそリベンジしたいと思っている。

ISUCON7に向けてやったこと:

  • メンバー集めた(アプリケーションエンジニア2、インフラエンジニア1の構成が過去の経験からベストとのこと)
  • PixivのISUCON問題解いた
    • 今回の予選の構成にかなり近く非常に有意義だったがその有意義さを活かしきれなかった、偏にぼく自身のせいであると思っている。
  • 事前にやることの共有した
    • 当日やることリストみたいなのを共有した(がこれも活かしきれていなかったように思う)

事前にやっておけばよかったこと:

  • もっと過去問を重要視すべきだった
    • せめて1ヶ月に1度過去問読んで、ここは自分ならこうするなどの話し合いを終業後に1時間でもいいのですべきだった。
  • メンバー間の配置を決めておくべきだった
    • 今回近くにはいたがそれぞれ別々のデスクで作業していたので誰がなにしてるのか?が不明瞭なところがあった
    • 相談したいときに距離が障害になることがあった。あとディスプレイみせて説明したり相談できる距離感でないと無駄なロスがある。
  • ログの追い方、スロークエリーのみかた、過去に出たN+1の対策などの対応策を話し合うべきだった
    • 本戦に出た「スギャブロエックス」チームのエントリみてより一層そう思った。
  • もっとISUCONエントリを熟読すべきだった
  • レギュレーションにはヒントがいっぱい
    • もっと注意深く読み解くべきだった。質問の意図を理解せず手を動かしてしまったのが最大の敗因だと思っている。
  • 環境構築は前日に終わらせておく
    • 今回は運営側のトラブルにより比較的時間に余裕があって設営が終わったが元々の時間に集まっていたら多分設営中断して開始時間になってた気がする。

個人的な課題:

  • SQL力の不足
    • /fetchのN+1問題をSQLだけでできそうだと思っていたのに制限時間内にクリアできなかった(開始時間がずれ込んだ関係で途中離脱したため)、結局kawakattsunが対応してくれたが本来ぼくがやりきっておくことだった、反省。
  • ログの監視を任せっきりにしていた
    • アクセスログ、エラーログの解析はともかく目を通さずにいた。ほぼcs_sonarにおまかせだからとコード部分にのみ専念してしまった。戦略としては正しいかもしれないが一定時間ごとに目を通すくらいはしておいてしかるべきだった。
  • ボトルネックをみつけてから対応すべきだった
    • 「あ、ここ問題になりそうだ!」で対応してしまった箇所が多かった。
    • スロークエリはEXPLAIN貼ったりして確認していたがきちんと計測した結果どこが問題か判断してからコードの書き換えなどを行ってその効果を計測すべきだった
  • インフラに関する知識とノウハウの不足を痛感
  • レギュレーションの重要性が全くわかっていなかった、レギュレーションはただのREADMEじゃなくて試験問題のテスト用紙そのものだと認識していなかった。

まとめ:

反省点はクソほどあって頭抱えて寝たいくらいの気持ちなんだけどそれはそれとしてやっぱり面白かったという気持ちが一番大きい。 その次が悔しいで、その次くらいが賞金いらないのでもう一回チャレンジさせてくれ!!!って気持ち。

今までISUCONは傍観者でいて「わー楽しそうだな〜」とか呑気に思ってたけどそのワクワク感の1000倍くらい参加したほうが楽しいので もし興味のある人は是非とも参加しような!

次こそは本戦にいけるよう素振りを入念にしておかねば…。