ユメのチカラ: プログラマの基礎体力
そもそも、プログラマの基礎体力ってなんだろう。学校でアルゴリズムの基礎を習うとか、プログラミング言語を習うとか、あるいはコンピュータの基礎を習うとかそういうことなのだろうか。 断片的な情報を獲得するのなら確かにインターネットや書籍でどうにかなる。しかし、職業プログラマとして一目置かれる存在になるための基礎体力ってなんだろう。 高校や大学などでプログラマの基礎体力は身につくのだろうか。 プログラムと言っても、ゲームのプログラムから、顧客の要求に従ったアプリケーションプログラム、組み込み機器の制御プログラム、あるいはOSやら、コンパイラやら、RDBMSやらの基盤ソフトウェアなど様々ある。 わたしの場合、子供の頃、初めてコンピュータに触る機会があって、その時のなにやら得体の知れない興奮みたいなものが結局のところコンピュータ関連の職業につくことになったのだが、知識０から鍛えるべきプログラマの基礎体
ユメのチカラ: プロのプログラマ
プログラマという職業。プログラムを作って給与を得る。が、定義かと思うけど、オープンソースを趣味で作っていてそれで所得を得ていない人は、じゃあ、プロのプログラマと言えないのか。 日本のIT産業のしょぼさは、ソフトウェア開発を人月単価でやりとりするところにあるというのが多くの人の指摘するところである。SIベンダーのエライ人が、学生の「大学では何を勉強すればいいですか」という質問に対して、「弊社では教育システムが完備していますから、大丈夫です」というような頓珍漢な答えをする。大学での専門的な勉強を期待しないということは、単に人を頭数で見ていることに他ならない。 「求人、プログラマ、未経験」を試しにぐーぐるしてみるとぞろぞろある。（求人 プログラマ 未経験 の検索結果 約 1,160,000 件中 1 - 10 件目 (0.08 秒) ） 誰でもできることをやっているとしたら、それはもう単価勝負に
ユメのチカラ: Intelのマニュアルを読む
Intel 64 and IA-32 Architectures Software Developer's Manuals は下記にある。 http://www.intel.com/products/processor/manuals/index.htm どれから読んだらいいか、よく分からないということであれば、 Volume 1: Basic Architectureをざっと見て、 Volume 3A: System Programming Guideに行くというのがオーソドックスかと思う。インストラクションセットの解説（ Volume 2A/2B）は辞書的に必要な命令について適宜参照するという形になる。 マイクロアーキテクチャについてざっくり知りたい場合は、Intel 64 and IA-32 Architectures Optimization Reference Manualの第2
ユメのチカラ: ロックのいろは
ロックと言うのはプログラミング上のコンベンション、慣用句みたいなもので、共有資源へのアクセスに対する同期のメカニズムとして利用される。 ある共有資源を複数のプロセッサ（あるいはプロセスでもいいけど）から同時に利用したいとする。変数に１を加えるという単純な動作ですら同期をとらないと正しい結果を得られない。 ロックはそのような同期を必要とする場面でよく利用される。ロックを取得したただ一つのプロセスのみその共有資源にアクセスできるようにするのである。 アトミックに値をセットしてテストする命令(test and set)を利用しロックが取得できるまでひたすらループして待つ、いわゆるスピンロックという単純素朴な方法がある。IA-32だとxchgという命令があって、あるメモリとレジスタの値をアトミックに（他のプロセッサに邪魔されることなく）行うことができて、それを利用する。例えば、0がロックされていな
ユメのチカラ: Latencyの隠蔽
プログラマたるものコンピュータの基礎的な知識は必要だと多くの人は言うのだけど、じゃあどこまでが必須でどこまでがオプション（？）なのかというと明確な線引きがあるわけではない。まあ、Kernelとかコンパイラとかをゴニョゴニョする人はCPUのキャッシュがなんたるかくらいは理解していないといろいろ大変かと思う。 時間と空間を交換するというのはコンピュータだけの世界ではない。街のコンビニだって、店頭に並んでいるものはすぐにアクセスできるけど、店頭にないものはすぐにアクセスできないので、在庫量がある一定水準を下回ったら発注のトリガーがかかる。コンビニはその発注サイクルがデパートとかに比べれば異様に多いので、クロックを上げて性能を出すPentium4みたいなものである。発注単位も非常に小さくて、それこそ弁当一個でも平気で発注しちゃうという感じである。在庫をほとんど持たないので、キャッシュミスした時のペ
ユメのチカラ: 山勘で分岐先を実行することを投機的実行と呼ぶ
「機械語ではマシンの挙動は理解できない」というのをはてなの日記で書いた。この手のbinary hack ネタは意外と受けるということを発見したので「ユメのチカラ」でも取り上げる。 あらかじめ言っておくけど99.9％のプログラマにとって下記のような話を意識しなければいけないというような状況は、まあない。OSやRDBMSあるいはコンパイラの実装者のうちでもごくまれな0.1％の状況で意識しなければならないというようなお話である。 多くの人は知らなくても困らないが知っていても邪魔にはならない知識である。 ハードウェアが機械語を実行するプロセスはごくごく単純化すると下記になる。 PC（プログラムカウンタ）がさすアドレスにある命令を取り出す（フェッチという）。 フェッチした命令を解釈する（デコードという）。 命令を実行する。 PCを一つ増やす。（分岐命令ならPCをそのアドレスに書き換える） 命令の実行
ユメのチカラ: メモリアクセスは遅い
多くのプログラマにとってメモリアクセスの速度を気しなければならない状況というのはめったに無いが、OS、ライブラリ、コンパイラ、RDBMSなどの実装をする時には意識をしなければならない場合がある。 IA-32 Intel Architecture Optimization Reference Manual (order number 248966) をひもとくと6章にOptimizing Cache Usageというのがある。 マイクロベンマークの定番 lmbench http://www.bitmover.com/lmbench/ では、一次キャッシュ(L1)や二次キャッシュ(L2)を測定してくれる。例えば、わたしが利用しているノートだと、L1が1.776nsでL2が5.3490ns、メインメモリアクセスが139.4nsである。 Memory latencies in nanosecond
ユメのチカラ: mixiのスケーラビリティ
mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法サービス開始から3年余りで会員数が1000万人を超えたSNSの「mixi」。そのシステムはOSSで構築されており、データベース管理システム（DBMS）には「MySQL」を使う。急増するトラフィックをさばくために負荷分散を重ねた結果、現在ではサーバ1000台以上が連なる超分散システムへ。その中でMySQLが果たす役割とは。http://techtarget.itmedia.co.jp/tt/news/0709/12/news01.htmlという記事があった。 日記だけで4億件。サーバは1000台以上。アクティブユーザは6割を超える。すさまじい規模のサービスである。すべてOSSで構成されていて、自社開発のコードでサービスをささえる。 当初一人のユーザから始まったサービスも2ヵ月後には1万人を超え、さらに半年ほどでデータベースをサービス
ユメのチカラ: ベストセラーは読まない
本の読み方はいろいろある。十人十色。 熟読、濫読、積読、黙読、音読、再読、回読、誤読、精読、速読、耽読、通読、復読、輪読、朗読、輪読、… 本の買い方もいろいろある。十人十色。 本屋でぶらぶら。新聞の書評を見て。アマゾンのリコメンデーション。ブログで紹介されていたから。 人それぞれのスタイルがあると思う。 人様の本の読み方や買い方に別にけちをつけるつもりは毛頭ないが長年培ってきたわたしのスタイル（というほど大げさなものではないが）を記してみたい。 若い頃は手当たり次第にともかく面白いと思ったものを読んでいた。自分の興味の赴くままという感じである。あたりもあればはずれもある。買う方法は本屋で立ち読みしてチェックして、というかそれ以外ほとんどなかった。（インターネット以前の本の買い方というのは本屋以外はなかったと言っても過言ではない）もちろん課題図書や輪講用文献など買わねばならないものは取り寄せ
ユメのチカラ: フリーソフトウェアの価値観
80年代に消滅しかけたハッカー倫理を実現するコミュニティは、リチャード・ストールマンの孤軍奮闘ともいうべき活動によって細々とだが生き延びていた。 リチャード・ストールマンはソフトウェアは私有すべきではないという信念のもとFSF (Free Software Foundation)を立ち上げ、GNU (GNU's Not Unix) というUnix互換のOSを作ろうとしていた。エディタ（emacs)、コンパイラ(gcc)、shell script (bash)、デバッガ(gdb) などなど様々なフリーソフトウェアを精力的に開発し、公開していった。 MITのAI研究所はLispマシンの商用化によって壊滅的な打撃をうけていた。優秀なハッカーたちは高給で商用Lispマシンベンダに雇用され、ソフトウェアの共有は、知的財産権の名の下に不可能になった。DECがPDP-10のサポート中止した結果、彼らのよ
ユメのチカラ: ハッカー倫理
実のところ60年代、70年代にMITにいたわけではないので直接見聞きしたわけではないのだが当時のMITの研究室にたむろっていてプログラマ達に暗黙のうちに了解されていた哲学、倫理、あるいは夢みたいなものがハッカー倫理とよばれるものだ。 スティーブン・レビー「 ハッカーズ」で次のように記している。 コンピュータへのアクセス、加えて、何であれ、世界の機能の仕方について教えてくれるものへのアクセスは無制限かつ全面的でなければならない。実地体験の要求を決っして拒んではならない。 すべての情報は自由に利用できなければならない。 権威を信用するな－－反中央集権を進めよう。 ハッカーは、学歴、年齢、人種、地位のような、まやかしの基準ではなく、そのハッキングによって判断されなければならない。 芸術や美をコンピュータで作り出すことは可能である。 コンピュータは人生をよいほうに変えうる。 フリーソフトウェアある
ユメのチカラ: ノルマ
99年にシリコンバレーから戻ってきてミラクル・リナックスを創業するまでは日本オラクルのサポート部隊にいた。 日本オラクルのサポート部隊にはDDR(Defect Detection and Resolution)という米国直下の部隊があってそこに所属していた。DDRというのはOracleデータベースのバグの修正を行う部隊で、パッチを作成したり、ワークアラウンドを提示したりする。 外資系なのでバグの修正は米国本社がやるだろうと多くの人達は思うかもしれないが、どうしてどうして、日本オラクルの中にはパッチまで作ってしまう専門家部隊があるのである。 わたしの担当はSQLとNLS(National Language Support)なのでbugデータベースの中でSQLおよびNLSと分類されたOracle RDBMSのバグについて日々問題解決をしていた。オラクルのDDRチームは米国本社以外にも日本、イン
ユメのチカラ: デバッグ方法論
実践的なデバッグ方法論（デバッグの仕方、事例研究）も強く求められている。デバッガーというツール依存のTipsではなく、ソフトウェアのデバッグというプロセスそのものの形式化である。 人々は誰に教わるでもなく自分のデバッグのスタイルを持っている。自分なりな定石を獲得している。しかしそれを明示化して人に伝えようと試みる人は少ない。伝承がまったく不可能なような議論も少なくない。 わたしはオープンソースの時代こそデバッグの方法論を広く共有できるチャンスに満ちた時代だと考えている。いくつか事例を紹介しつつ解説する。 優れたプログラマは優れたデバッグ方法論を持つ。そのデバッグ方法論をぜひ共有化したい。そのためには情報公開が要である。 デバッグとはプログラムの不具合を修正するプロセスである。テストなどによって発見された何らかの不具合を期待する結果に修正する作業である。テストとデバッグの区別が十分ついていな
ユメのチカラ: チューニング
パフォーマンスチューニングというのも非常に重要な問題だ。黒魔術のようなかんじもしなくもないが、ヨタ話をいろいろ書いてみる。 性能の問題が表面化した場合、やみくもにパラメータをいじくりまわして問題を悪化させてしまう場合があるが、そーゆーことは避けたい。 何が問題なのか、定量的なゴールを明確化しないと、単なる感覚論になってしまって不毛な時間をついやすことになるので注意が必要である。 パフォーマンスチューニングの参考書はいろいろあると思うので適宜みつけだしてほしいが定番のこれはというのは、あるようでいてよくわからない。データベースのチューニングという題材での書籍はいろいろあるがいかんせん製品特有のTipsにかたよったものが多くてあまり汎用性がなかったりする。Oracleのパラメータを勉強するというのはそれはそれで必要なのだけど、わたしが目指しているものとちょっと違う。 ここでは一般的なアプリケー
ユメのチカラ: 闘うプログラマ
わたしが紹介するまでもなく、「 闘うプログラマー〈上〉」、「 闘うプログラマー〈下〉」はビル・ゲイツの野望を実現すべく雇われた「伝説のプログラマ」デイブ・カトラーのＮＴ開発物語である。 わたしはデイブ・カトラーに会ったことはないがDEC時代にいろいろ伝説は聞いていた。一番、有名な都市伝説は、Windows NT (WNT)というのはVMS (DECのベストセラーマシンVAXのOS)を一文字づつずらした名前にしたというものである。誰かがデイブ・カトラーにその真偽を問うメールをしたところ、今ごろ気がついたのかよ、という返信が来たという。90年代初頭にそのようなメールがでまわっていたような記憶がある。 それはともかく鬼軍曹のような風貌のプロジェクトリーダ率いるＮＴ開発物語はザカリーの筆力もありぐいぐいと人を引きつける。 それは栄光と挫折の物語である。20世紀最後の商用ＯＳ開発物語と言ってもいい。
ユメのチカラ: ソースコードの読み方
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
ユメのチカラ: シリコンバレーの思い出
今から約10年くらいまえにシリコンバレーにいた。米国Oracleのデータベースエンジンの開発部隊にいた。さらにそれを遡ること数年前、米国DECのデータベースの開発部隊、これは東海岸(New Hampshire州Nashua)にあった、で開発していた。 われわれはよく欧米とか言う。欧州の国々の文化と米国の文化を一緒くたに議論したりしがちである。しかし、米国と英国ですら文化的には随分違うし、ドイツ、スペイン、スウェーデンなどなども相当違うのではないかと想像する。 米国ですら、東海岸と西海岸も生活してみて、これが同じ国かというほど違う。東海岸といっぱひとからげに言うのも語弊があるかもしれないが、ニューハンプシャー州の住んでいたところと、西海岸のシリコンバレーでは気候も回りの人々も随分違う。 東海岸の米国DECは典型的な垂直統合型ビジネスモデルで、会社の文化も、西海岸の水平統合型の米国Oracle
ユメのチカラ: オープンソースは資本主義の破壊的イノベーションである
というフレーズを通勤電車で思いついたのだが、そのときは結構いけていると思ったのだが、今考えてみると、それほどいけていない。夢を見ている最中はすげーなこれと思っていて、次の日、目が覚めてみると一体どこがすごいのかと思うようなものである。 破壊的イノベーションは持続的(改良的)イノベーションとことなって、まるっきり新しい市場を開拓し、既存の支配者を駆逐する。あるいはローエンド市場から参入し、既存の支配者を市場から追い出す。みたいな事が教科書には書いてある。 オープンソース的な世界では、著作権を私有するのではなく、共有することによって価値をたかめる。著作権という財産権を否定しちゃったら資本主義ではないではないか、とか思うのがフリーソフトウェアの思想を最初に聞いたときの素朴な感想であったりする人は少なくない。 財は共有すると減る。お菓子をあげれば自分の分が減る。お金をあげれば自分の分が減る。ところ
ユメのチカラ: The Practice of Programming (プログラミング作法)
先日、K&RのThe C Programming Language （プログラミング言語C）は初心者が読む教科書としてはいただけないと紹介した。では、お勧めは何か。 ずばり、The Practice of Programming (Addison-Wesley Professional Computing Series)を推薦したい。（日本語訳はプログラミング作法である） テスト、デバッグ、移植性、性能、設計の選択、スタイルなどのテーマ（プログラミングの実践(Practice of Programming)）という計算機科学の授業でまともに取り上げられなかったものを取り扱っている。 移植性の解説で、国際性(Internationalization)の項目を発見したとき、ああやっとK&Rの呪縛から逃れられるかもしれないと思ったものである。 If one lives in the United
ユメのチカラ: OSの開発
10年前、わたしは米国OracleでOracle 8の開発に従事していた。データベースエンジンを開発する唯一の日本人プログラマであった。朝から晩まで、コードとにらめっこで、自分がチェックインしたコードで、デイリービルドがぼろぼろにならないように毎朝祈っていた。 その当時、RDBMSのような巨大なソフトウェアを開発できる企業は、Oracle以外、IBM、Microsoftなど限られた大企業でしかなかった。SybaseやInformixなどは徐々に競争力を失ないつつあり、ニッチなエリアでの新興ベンチャーはあるにはあったがOracleのような汎用RDBMSベンダーになりそうな企業はみあたらなかった。むしろ、ゴリラのような巨大企業に市場は収斂しつつあるように見えた。 OSのベンダーもそうだ。Microsoft、IBM、Sun Microsystems、HPなどがOSを開発していたが、Microso
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
