2010-09-10 15:42:35
もっと早く知りたかったプログラミングのコツ
テーマ：システム関連
ashdotにTed Dziuba 氏の「もっと早く知りたかったプログラミングのコツ」が載っていた。
http://slashdot.jp/askslashdot/article.pl?sid=10/09/08/2228201
一部しか訳されてなかったので、訳してみようと思います（結構いい加減ですが。。）。まずは、最初の半分です。
---------------
スタートアップ（ベンチャー企業）でのプログラミングは、大企業でのプログラミングとはずいぶん違う。スタートアップでは、あなたは開発だけを行うという事はなく、大半をシステム管理者として過ごす事になる。私は3年間スタートアップで働いているが、荒削りな知識で何とかするよりも、理にかなったやり方を身につけるべきだと痛感させられた。
これらのことは初めから知っていればよかったし、少なくとも意地を張らずに学べばよかったことです。
物事を複雑にしすぎる事を避けるには
大半のソフトウエアエンジニアのように、私も技術的過ぎる傾向があります。その傾向を対処するためにも、私は二つのシンプルなルールを守るようにしています。
１．もしあなたが2つ以上のパーシステントなデータストアに接続するプログラムを書いているなら、それは複雑過ぎます。
そして、ハードディスクはパーシステントなデータストアとしてカウントします。これはある意味、シングルインプット、シングルアウトプットである小さなツールの集合体であるUNIXの再解釈です。たくさんの異なるパーシステントなストアーを介して、状態をトラッキングしたり、失敗ケースをハンドリングするのは、ひとつのプログラムが行うには重すぎます。
２．もしLinuxができることであれば、そちらに任せる
xargsがあなたの問題を解決できないという明確な理由がないかぎりHadoopのMapReduceは使ってはいけません。Linuxのアドバイザリーファイルロッキングシステムがきちんと動いているときに、独自のロックサービスを構築してはいけません。コマンドラインのイメージマジックが動かないと証明されるまでPILでイメージプロセッシングを行ってはいけません。最近のLinuxディストリビューションはたくさんの機能があり、たくさんの難しい問題がすでに解決済みです。あなたはどこを見ればよいか知るだけでよいのです。
パラレル処理は『自分がやりたい時』にではなく、『必要に迫られた時』に行う
それは明白、しかし自分にはっきりと言い聞かせないといけないときがあります。もし物理的なマシンがボトルネックじゃなかったら、稼動をいくつかの物理的なマシンに分割しません。CPUバウンドジョブをパラレル処理しなければならないときはとても明白で、I/Oバウンドスタッフの為に、もっと深く計測をしなければなりません。
例えば、もしwebクロールをしたく、インターネットへのパイプがあまりない場合、たくさんのサーバを使用するのは悪くないことです。この人は私にそういう考え方を教えてくれました。彼はクルージャーで大規模HTTPフェッチングを行っている人です。彼はキューイングシリネスによるパラレル処理について話します。しかし、一つのマシン上のパイプにどのくらいのデータを移しているかは話しません。もしインターネットに対して100Mbitコネクションがあれば、あなたのフェッチャーは700kbitくらい使用しているとしたら、なぜあなたのフェッチャーが駄目なのかわかるのです。
（私はミロのポリフィックシステム管理者とそのポストについて話していました。著者はとてもエラボレイト トロールかただのrun-of-the-mill idiotのどちらかでした。
珍味は（tidbit)は、データストレージに行くことです。Cassandraはすばらしいものですが、あなたには必要がないと保障できます。マルチテラバイトドライブは安く、歩優れは品質がしっかりしていると知られています。それはリスクの問題だけではありません。
http://slashdot.jp/askslashdot/article.pl?sid=10/09/08/2228201
一部しか訳されてなかったので、訳してみようと思います（結構いい加減ですが。。）。まずは、最初の半分です。
---------------
スタートアップ（ベンチャー企業）でのプログラミングは、大企業でのプログラミングとはずいぶん違う。スタートアップでは、あなたは開発だけを行うという事はなく、大半をシステム管理者として過ごす事になる。私は3年間スタートアップで働いているが、荒削りな知識で何とかするよりも、理にかなったやり方を身につけるべきだと痛感させられた。
これらのことは初めから知っていればよかったし、少なくとも意地を張らずに学べばよかったことです。
物事を複雑にしすぎる事を避けるには
大半のソフトウエアエンジニアのように、私も技術的過ぎる傾向があります。その傾向を対処するためにも、私は二つのシンプルなルールを守るようにしています。
１．もしあなたが2つ以上のパーシステントなデータストアに接続するプログラムを書いているなら、それは複雑過ぎます。
そして、ハードディスクはパーシステントなデータストアとしてカウントします。これはある意味、シングルインプット、シングルアウトプットである小さなツールの集合体であるUNIXの再解釈です。たくさんの異なるパーシステントなストアーを介して、状態をトラッキングしたり、失敗ケースをハンドリングするのは、ひとつのプログラムが行うには重すぎます。
２．もしLinuxができることであれば、そちらに任せる
xargsがあなたの問題を解決できないという明確な理由がないかぎりHadoopのMapReduceは使ってはいけません。Linuxのアドバイザリーファイルロッキングシステムがきちんと動いているときに、独自のロックサービスを構築してはいけません。コマンドラインのイメージマジックが動かないと証明されるまでPILでイメージプロセッシングを行ってはいけません。最近のLinuxディストリビューションはたくさんの機能があり、たくさんの難しい問題がすでに解決済みです。あなたはどこを見ればよいか知るだけでよいのです。
パラレル処理は『自分がやりたい時』にではなく、『必要に迫られた時』に行う
それは明白、しかし自分にはっきりと言い聞かせないといけないときがあります。もし物理的なマシンがボトルネックじゃなかったら、稼動をいくつかの物理的なマシンに分割しません。CPUバウンドジョブをパラレル処理しなければならないときはとても明白で、I/Oバウンドスタッフの為に、もっと深く計測をしなければなりません。
例えば、もしwebクロールをしたく、インターネットへのパイプがあまりない場合、たくさんのサーバを使用するのは悪くないことです。この人は私にそういう考え方を教えてくれました。彼はクルージャーで大規模HTTPフェッチングを行っている人です。彼はキューイングシリネスによるパラレル処理について話します。しかし、一つのマシン上のパイプにどのくらいのデータを移しているかは話しません。もしインターネットに対して100Mbitコネクションがあれば、あなたのフェッチャーは700kbitくらい使用しているとしたら、なぜあなたのフェッチャーが駄目なのかわかるのです。
（私はミロのポリフィックシステム管理者とそのポストについて話していました。著者はとてもエラボレイト トロールかただのrun-of-the-mill idiotのどちらかでした。
珍味は（tidbit)は、データストレージに行くことです。Cassandraはすばらしいものですが、あなたには必要がないと保障できます。マルチテラバイトドライブは安く、歩優れは品質がしっかりしていると知られています。それはリスクの問題だけではありません。
