Hatena::ブログ(Diary)

mizchi log

@mizchiの雑記帳

2013-05-23

1つの流儀を持つこと


流儀を知らないということは、何者にも縛られていない、ということではない。自分の癖に振り回されていることに、無自覚なだけだ。


ってのは、中学時代の部活の恩師の受け売りなんだけど、大人になるにつれ、特にインターネットを眺めるにつれ、無自覚に自分の癖に振り回されている人を見る機会が増えている気がする。


インターネットには反知性主義・反権威主義の皮を被った「怠惰の言い訳」があまりにも多い。
わかり易い例として、2chの哲学系のまとめを見るといいと思う。必ず導入かオチにキャッチーでわかりやすい反知性主義の言い訳があるはずだ。


それはまとめ人の程度を示しているだけとも言えるが、傾向として2chは反知性主義が支配している場であると思う。2chは嫌いではないけど相手の弁をそれによって封殺している流れをみると、僕はイライラする。で、はてブにもそういうのが増えてきた。


何かの視点を獲得することは、自分自身を捉えていた檻を自覚するようになることだ。檻を破壊するも、あるいは居心地の良い檻の中の生活を志向するにも、必ずその檻を自覚することからはじまる。


反知性主義の弁は、ほとんどの人の耳に心地よく、また伝搬しやすい。それを理解するのに必要なものは、なにもないからだ。なにも知らないでいいことの根拠になる。


何かに熱くなることはかっこわるい、みたいな風潮は、真摯に向き合っている人に対して失礼だと思う。専門性の獲得はそこからは生まれない。僕は誰もが何かに精通していて、お互いに何らかの価値を交換しあえたら楽しいなと思っているし、そうであってほしい。

2013-05-12

プログラミングはそれ自体が目的であっていい


これ読んで思ったこと。

プログラミングを勉強したい人が勉強する前にすべきこと - もとまか日記 http://d.hatena.ne.jp/moto_maka/20130512/1368308092


僕がプログラミングをはじめたとき、何を思ってプログラミングをはじめたか思い出してみようとしたけど、よく思い出せなかった。
ただ漠然と感じていたのは、プログラミングは個人が現実的にこの世界に直接手を加えることができる手段の1つであり、それをやらないのは勿体無い、といったことだったと思う。たぶん。

というわけで、最初にやったのはFirefoxのユーザースクリプトを書くことだったし、それはそれでよい経験だった。なんとなくゲームとかウェブアプリとか作りてーなー、と思って色んなライブラリを動かすだけ動かして満足した。プログラミング覚えて初めて最初の一年で10以上の言語のHelloWorldだけやったと思う。その結果Unixの環境構築がうまくなった。

その後はひたすらいろんな言語のウェブフレームワークを触り、PythonとMongoDBで遊んでいた。グラフィック関係もやりたくなったのでJavaScriptのHTML5Canvasで迷路を書いて、A*のアルゴリズムで最短経路を解かせたりしていた。


自分が地力でそこに行き着くまでに覚えた環境構築、ライブラリごとの思想、言語の触り心地、出来上がったアプリの感触、そこに無駄だったものは何一つ無い。
半年でアプリが作れる!という謳い文句を僕は信じていない。そこに至る全てをオミットしているからだ。ちょっとパラダイムが変わると簡単にハマってしまうからだ。現実のアプリを作るレベルで、最短経路の知識で済むこと絶対に無い。

大事なのは、いくつ地雷を踏んだか、だ。地雷を踏んだ数だけ強く慣れる。真に必要なのは、独力での問題解決能力。Python2系でsjisのHTMLをlxmlでスクレーピングすると、地雷を7つぐらい同時に踏めるからおすすめだ。


話題になった技術は概要を読むだけでなく、自分の手で動かすことが大事だと思っている。サンプルを少しづつ変更して、この技術は、何を許して何を許さないかを知ること。それが欠けたプログラミング技術は、ネタなしの寿司である。

プラグマティズムと理想


これは業務としてプログラミングをするようになって気づいたんだけど、「動けばいい」というだけの指針で設計されたコードは、ほとんどにおいて糞コードである。

たとえばリファクターを嫌う創業者が、動けばいいというマインドを共有した技術者だけを集めて書かせたコードは、往々にして破綻する。(この業界で一番よくあるパターンだ)
「動けばいい」はプロジェクト初動においてはものすごいベロシティを発揮するが、それを継続するのは至難の技だ。そしてそれを難しいと伝えることは難しい。人は経験からしか学べず、しかもより直近の経験から学ぶから、直近の見た目上のベロシティにバイアスが引っ張られる。コードが書けない人はなおさらだ。

このようなことを起こさないために、そこで必要になるのはある種の言語マニアのような人の存在だと思っている。数万行のコードベース、大規模なアーキテクチャを成立させるためのスキルは、偏執的なデザインパターンや設計に対する執着、言語仕様に対する深い理解から生まれると僕は思っている。(さらに言うと仕様理解度もだが、ここでは割愛する


モデルとビューの分離の指針、デザインパターンの準拠、インスタンスを握るスコープの最小化や、組み込みメソッドによるコードの単純化、そういうのにこだわりを持つ人のレビューがあって、はじめてまともなコードが成立する。継承地獄やシングルトンという名のグローバル変数が検知されず、使用しているライブラリのデザインパターンを無知ゆえに独自の解釈でねじ曲げた場合、糞コード一直線だろう。


僕がよく個人的によくやるリファクタリングは、糞コードに至るプログラムのフローだけ整えておいて、どうしようもなく出来上がった糞コードを一箇所に押し込める。「副作用が0」もしくは「副作用しか無い」ようなメソッドに抽出しておく。その際はメソッド名で、副作用があるかないかわかりやすくしておく。
ここのリファクタリングは、思いついたらやる。だいたい他の箇所のコード書いてるとこう書けばよかったんだって気づく。

言語にしか興味が無い人


たとえば、Rubyist達はRubyで書くこと自体を目的にしているケースをよくみる。一般的に、コミュニティが小さい言語ほどコードの質は高い。美しいコードに囲まれて生活するということは、それだけが彼らの転職目的になりえるわけだ(Rubyを書きたいから転職、もこの業界でよくみるものの1つだ。

プログラミング自体を目的にした人達は、基本的にHaskellLisp関数型言語に手を出す印象がある。それはもちろん小さいコミュニティで、コードの品質が高く、言語そのものに対する研究に興味がむくからだろう。

僕もまあそれなりに手を出しているのだけど、他の人も抑えるべきだと思った概念は、次のものだ。

  • Haskellにおける入出力IOと副作用の概念
  • HaskellのMaybe, またはScalaのOption型
  • Scalaのtrait
  • Node.jsの非同期Promiseパターン
  • C#のgetter/setter/readonly/async等の型アノテーション

それほど敷居が高くないのを選んだので(Haskellの非同期IOはちょっときついが)、興味がある人は調べるといいと思う。

最後に


この記事は昼間からLeague of Legends を飲酒プレーしながらはてブ眺めてたら意識が高まりウッってなったので書いた

2013-04-29

最近買った本


機龍警察(ハヤカワ文庫JA)

機龍警察(ハヤカワ文庫JA)

Land of Lisp

Land of Lisp