タイトル通りなわけだが。先日、とあるコンサルの個人面接で珍しい質問をされた。 「じゃあ、最近"俺ってスゲー"と思ったことは？」 思いつかず焦った僕は、最近まとめた去年の読書冊数を伝えた。質問に答えた瞬間社員さんの反応が「微妙」であることを悟り、しかるのち軽薄な自分を恥じた。 全然すごくねーよアホ。 コンサルティング、とりわけ戦略コンサルティングという仕事はインプット量が半端ない。なにしろ経験のない事業について、その事業の専門家にアドバイスせねばならないのだから、生半可な情報インプットではまともに会話すらできない。 具体的にその社員さんが何冊くらい読むのかは聞けなかったが、というか恥ずかしくてそれ以降ろくな受け答えが出来なかった*1のだが、明らかに僕は、勝負を仕掛けるフィ−ルドを間違えたのだろう。反省することしきりである。 それぞれのインプット・スタイル 僕程度の読書家はごろごろいる。上を見

@自宅（個人の見解に基づいており，所属組織などとは一切関係ありませんし，事実かどうかもわかりません） この世界に希望をもつためには批判し続けることこそが必要だ - Edward W. Said (1935-2003) 少し時間が空いてしまったが，やっと形になったので，公開してみる．dis覚悟なので，disって下さい．叩き上げて，より良い資料になればと思います． サーベイの仕方・論文の読み方 情報系院進学予定の卒研生とM1を対象にしています．内容に偏りがあるのは，その分野しか分からないからです．色々な方からのご意見を頂きたいです． 見て頂ければわかると思いますが，naoeさんにインスパイアされています．参考にさせて頂いております．ありがとうございますm(__)m． まとめていて気付いたんですが，世の中には「論文の書き方」や「プレゼンの仕方」なる資料は良質なものがゴロゴロと見つかりますが，「研

研究 | 00:06 | 最初に言っておくけど、このタイトルはホッテントリメーカーでつくったんじゃないよ！結果としてこうなったんだよー！！ ゴホッゴホッ（咳をする音）、では気分を取り直して、以下本文です。 しんぷる大先生 (id:simpleA) が読書をする上でいかに自分のアイデンティティーを大事にするかという興味深いエントリーを上げていたので、本エントリーでは研究者の論文の読み方について思うところを。 ライフサイエンス系の最前線の研究者は論文を読むことと実験をすることに忙殺されていると思うから、ほとんどの研究者は論文か実験に使う時間を出来るだけ減らしたいという願望を持っていると思うのです（エラクなるごとに実験量は減り、論文を読む量は増えるよー）。私は（エラクはないけど、っつーか、シタッパーズです！それでも）読む必要性のある論文が常に山になっているのですが、論文を読む時はこんな点に注意し

$Id: readingcode.html,v 1.13 2003/12/06 00:01:08 aamine Exp $ 2006-05-02 gonzui 追加。thanks: 冨山さん 2003-12-03 ltrace と sotrace を追加 2003-12-03 ツールのところに DDD を追加。thanks: 和田さん 2003-05-27 VCG, SXT などについて追加。thanks: 梅沢さん 2003-05-27 これもすっかり忘れていた strace, ktrace, truss, etags などについて追加 2002-08-30 すっかり忘れていた ctags を追加 2002-07-07 匿名希望さんからメールでいただいた情報を追加 (動的コールグラフ) 2002-06-13 日記経由でいただいた意見をもとに文章を追加。thanks: 柳川さん、まつもとさ

列挙体名がない列挙体変数は Reading Gauche/gauche/vm.h/SCM_ERROR_BEING_HANDLED のような書き方でいいでしょうか。 -- ココサブ 2007-09-27 (木) 23:26:32 はい。良いと思います。#define と同じような扱いですね。 -- ひげぽん 2007-09-28 (金) 00:43:20 週末に合宿に出ていた間の分のcatch-up中です。struct HogeHogeRef は HogeHoge のページに記載、という風になってきたようなので従います。その方が手繰りやすいですし。既にポストされたstruct関連ページのリンクや内容も適宜修正します。 -- naoya_t 2007-09-25 (火) 14:46:08 ReadingGaucheの階層構造でsrcを省略してしまっていたために、srcと同じ階層になるgcなどの

学ぶ方法を学ぶことは重要だ。知識は陳腐化する。しかし、学ぶ方法というのは、道具立てが変わってもかなり安定的で変化は少ない。 インターネットのおかげで確かに知識の取得方法は劇的に変化した。量的な変化が質的な変化に転換した。なんでもかんでもインターネットで検索してからことをはじめるという感じになってしまった。あんまりじっくり考える機会がなくなったような気がしないでもない。 かつてプロセスプログラミングと言う概念が流行った。最近ではあんまり言わないがソフトウェア開発の究極の姿だと言われた。ソフトウェアは人が作るのだが（当たり前だけど）、そのプロセスを厳密に記述していければ、つまりコンピュータが理解可能なくらい精密に記述できれば、ソフトウェア作製も自動化できるのではないかというアイデアである。随分荒唐無稽なことを言うとあなたは思うかもしれないがあながち夢物語ではない。 例えば、ソフトウェア開発では

わたしは、90年代にシリコンバレーにいたとき、シリコンバレー日記と言うものを書いていてWebで公開していた。今そのサイトはないのであるが、インターネットのWebアーカイブにその内容が残っている。先日「プロセスプログラミングの実践方法」というエントリでデバッグの話を書いたので、それつながりということで、当時、記した日記を全文転載し、ちょっと長くなるが後書き的な解説を加えたい。文体が微妙に違うがご愛嬌と言うことでご勘弁願いたい。 転載始まりデバッグ 誰もが使っている言葉なんだけど，実のところよく分からない言葉というのがある．少なくとも，なんとなくの定義はあるのだけど厳密な全員が納得できるような定義があるようでない言葉というのがある． デバッグというのも実はわかったようでいてよく分からない．とりあえづ，デバッグというのはプログラムのバグを直す作業だとしよう．そうするとプログラムのバグとは何か？と

「大規模ソフトウェアの効率的な理解(その1、2、3、4、5、6)」などという大袈裟なタイトルでブログを書いたが、今回は一気に実践編ということでフリーソフトウェア定番のデバッガ gdb の実践的使い方について記す。 プログラマの日々には、プログラムを書くためのエディタ、プログラムをコンパイル(あるいは実行)するためのコンパイラ(あるいはインタプリタ)、そしてプログラムを理解するためのデバッガという三種の神器が必須である。 この定番はわたしの場合xemacs/gcc/gdbである。前々職(DECという会社に務めていた)の場合、それぞれプロプライアトリな物を使っていたので微妙に異なるがやることは一緒である。 gdbは何のために利用するかというと、プログラムを理解するために利用する。デバッガなんだからデバッグのために利用するというのは、gdbの底力の半分も利用していないと言ってさしつかえない。 g

動的理解、静的理解 ソフトウェアの理解のもう一つの視点は、ソフトウェアの動的な理解と静的な理解というのがある。 動的というのはソフトウェアを実行した時の挙動のことをさし、静的というのはソフトウェア(プログラム)の字面をさす。 静的な側面からの理解はソフトウェアのコードを読み、そこから何らかの形でプログラムの挙動を理解していくというアプローチになる。字面からの理解ということで、ディレクトリ構造やファイル名や変数の命名規則、コードリファレンスなどが静的な理解の対象になる。 動的な理解は、デバッガによる実行、プロファイラ、トレーサー、ベンチマーク、リグレッションテスト等々実行結果による理解となる。各種ツールが理解を支援してくれる。 ソフトウェアというものは、単純化すれば、ある入力に対して何らかの出力をする機械ととらえれば、ソフトウェアを理解するという事は、その入出力の組を知ることに他ならない。動

巨視的、微視的な理解 大規模ソフトウェアを理解する視点として、巨視的な理解、微視的な理解というのがある。巨視的な理解では、ソフトウェアをトップダウンに全体像から細部へと理解の道筋をたどる。一方、微視的な理解では、逆に細部から全体像へとボトムアップな理解の道筋をとおる。 規模の理解というのは、典型的な巨視的な理解の手法であり、ソースコードの解析は微視的な手法である。どちらも重要な視点で、それぞれの手法をバランスよく利用する必要がある。 大規模ソフトウェアの場合、微視的な視点からスタートすると、その規模のため、時間がおそろしくかかるという特徴があるので、最初は、巨視的な理解からはじめるのが王道である。その理解のプロセスの中で、興味のあるサブコンポーネント(論理的あるいは物理的な部分)へ到達したとして、そのサブコンポーネントの理解は徹底的に微視的な視点からはいるという方法もある。 例えば、あるソ

規模の把握 大規模ソフトウェアの理解はいろいろな観点からのアプローチがある。ソースコード一式(通常tarballと呼ばれている)を入手し、適当なディレクトリに展開する事からはじまる。tarballではなく、CVSのようなソース管理システムから直接入手する場合もある。 tar.gzというような形式の場合、$ tar xvzf XXXX.tar.gz というようなコマンドで展開する。$ cd XXXX してざっとディレクトリをながめる。通常、READMEないしINSTALLなどのファイルがあるので最初にそれを良く読む。またDocsなどというドキュメントを置いておく場所があれば、その中になにがあるかをざっと見る。 いきなりソースコードを変更するのではなく、このようにディレクトリ構造を調べたり、規模の把握をしたり、おおまかな骨格を理解するようにする。ディレクトリ構造は当該ソフトウェアの物理的構造を

ltrace で共有ライブラリの関数呼び出しをトレースする ltrace は共有ライブラリの関数呼び出しをトレースする Linux 用のツールです。システムコールをトレースするstrace と同様に、デバッグに大変役立ちます。 ltrace は Debian GNU/Linux の場合は sudo apt-get install ltrace でインストールできます。 ltrace の使い方は簡単です。基本的には ltrace コマンドの引数にトレースしたいコマンドとその引数を並べれば OK です。デフォルトでは ltrace のメッセージは標準エラーに出力されます。これをファイルに出力させるには -o オプションを用います。たとえば、次のように実行します。 % ltrace -o log.txt wget https://www.codeblog.org/ この例では wget が ht

What's gonzui? gonzui is a source code search engine for accelerating open source software development. In the open source software development, programmers frequently refer to source codes written by others. Our goal is to help programmers develop programs effectively by creating a source code search engine that covers vast quantities of open source codes available on the Internet. What's New 200