plusplusbot: Recent activity
Karma for anything and anyone Did someone go out of their way to help you? Is a web site being particularly slow and flaky? Make your feelings known with plusplusbot. You can ++ (pronounced "plusplus") or -- ("minusminus") anything. Think brownie points (but archived forever). is welcome. Getting started Make sure you have a Twitter account. Add plusplusbot as a friend. To increment "foo", your mo
ユメのチカラ: プロセスプログラミングの実践方法
学ぶ方法を学ぶことは重要だ。知識は陳腐化する。しかし、学ぶ方法というのは、道具立てが変わってもかなり安定的で変化は少ない。 インターネットのおかげで確かに知識の取得方法は劇的に変化した。量的な変化が質的な変化に転換した。なんでもかんでもインターネットで検索してからことをはじめるという感じになってしまった。あんまりじっくり考える機会がなくなったような気がしないでもない。 かつてプロセスプログラミングと言う概念が流行った。最近ではあんまり言わないがソフトウェア開発の究極の姿だと言われた。ソフトウェアは人が作るのだが（当たり前だけど）、そのプロセスを厳密に記述していければ、つまりコンピュータが理解可能なくらい精密に記述できれば、ソフトウェア作製も自動化できるのではないかというアイデアである。随分荒唐無稽なことを言うとあなたは思うかもしれないがあながち夢物語ではない。 例えば、ソフトウェア開発では
ユメのチカラ: デバッグの話（昔の日記から）
わたしは、90年代にシリコンバレーにいたとき、シリコンバレー日記と言うものを書いていてWebで公開していた。今そのサイトはないのであるが、インターネットのWebアーカイブにその内容が残っている。先日「プロセスプログラミングの実践方法」というエントリでデバッグの話を書いたので、それつながりということで、当時、記した日記を全文転載し、ちょっと長くなるが後書き的な解説を加えたい。文体が微妙に違うがご愛嬌と言うことでご勘弁願いたい。 転載始まりデバッグ 誰もが使っている言葉なんだけど，実のところよく分からない言葉というのがある．少なくとも，なんとなくの定義はあるのだけど厳密な全員が納得できるような定義があるようでない言葉というのがある． デバッグというのも実はわかったようでいてよく分からない．とりあえづ，デバッグというのはプログラムのバグを直す作業だとしよう．そうするとプログラムのバグとは何か？と
OProfile
OProfile とはOProfile はカーネルも含めたシステム全体のプロファイリングを行います。システ ム全体の処理時間が、カーネル、各カーネルモジュール、各ユーザープログラム、各 共有ライブラリのうちのどの部分で消費されたかという統計を得ることができます。 この統計はバイナリイメージごと、あるいは関数ごと、より詳細にアドレスごととい うように多様な形式で表示できます。OProfile はパフォーマンスカウンタを利用してハードウェアイベントに基づいた プロファイリングを行うことができます。パフォーマンスカウンタによって測定でき るイベントは、アーキテクチャーモデルにより異なりますが、例えば、キャッシュミ ス、クロックサイクル、TLB ミスといったイベントを測定できます。 そのため、さまざまな側面からプロファイリングを行うことが可能です。2.5 系のカーネルのバージョン 2.5.43 か
ユメのチカラ: gdbの実践的使い方
「大規模ソフトウェアの効率的な理解(その1、2、3、4、5、6)」などという大袈裟なタイトルでブログを書いたが、今回は一気に実践編ということでフリーソフトウェア定番のデバッガ gdb の実践的使い方について記す。 プログラマの日々には、プログラムを書くためのエディタ、プログラムをコンパイル(あるいは実行)するためのコンパイラ(あるいはインタプリタ)、そしてプログラムを理解するためのデバッガという三種の神器が必須である。 この定番はわたしの場合xemacs/gcc/gdbである。前々職(DECという会社に務めていた)の場合、それぞれプロプライアトリな物を使っていたので微妙に異なるがやることは一緒である。 gdbは何のために利用するかというと、プログラムを理解するために利用する。デバッガなんだからデバッグのために利用するというのは、gdbの底力の半分も利用していないと言ってさしつかえない。 g
ユメのチカラ: gdb/xemacs/cscopeの使い方
プログラムの状態は変数の値の変化によって変化していくわけだが、変数は、宣言され、値を代入され、参照されるなどして利用される。 ポインタによって字面では変数が登場しなくても参照、変更される事もあるので油断禁物である。 またグローバル変数が嫌われるのは、ソースコードを局所的に調べていてもその代入、参照の範囲がつかめないからである。別のディレクトリに格納されている見た事も聞いた事もないファイルで変更されていて、当該ディレクトリをgrepしただけでは発見できなかったりする。 ローカルな変数ならばソースコードを静的に読解していけば、宣言、代入、参照それぞれが局所化しているので簡単に理解できる。 変更の影響もローカル変数ならば局所化されているがグローバル変数だとどこに影響が発生するかよくわからないのである。 さてブレークポイントを設定し、そこで実行が停止したとする。最初の仕事はその関数がどこから呼ばれ
ユメのチカラ: 大規模ソフトウェアの効率的な理解（その5）
動的理解、静的理解 ソフトウェアの理解のもう一つの視点は、ソフトウェアの動的な理解と静的な理解というのがある。 動的というのはソフトウェアを実行した時の挙動のことをさし、静的というのはソフトウェア(プログラム)の字面をさす。 静的な側面からの理解はソフトウェアのコードを読み、そこから何らかの形でプログラムの挙動を理解していくというアプローチになる。字面からの理解ということで、ディレクトリ構造やファイル名や変数の命名規則、コードリファレンスなどが静的な理解の対象になる。 動的な理解は、デバッガによる実行、プロファイラ、トレーサー、ベンチマーク、リグレッションテスト等々実行結果による理解となる。各種ツールが理解を支援してくれる。 ソフトウェアというものは、単純化すれば、ある入力に対して何らかの出力をする機械ととらえれば、ソフトウェアを理解するという事は、その入出力の組を知ることに他ならない。動
ユメのチカラ: 大規模ソフトウェアの効率的な理解（その4）
巨視的、微視的な理解 大規模ソフトウェアを理解する視点として、巨視的な理解、微視的な理解というのがある。巨視的な理解では、ソフトウェアをトップダウンに全体像から細部へと理解の道筋をたどる。一方、微視的な理解では、逆に細部から全体像へとボトムアップな理解の道筋をとおる。 規模の理解というのは、典型的な巨視的な理解の手法であり、ソースコードの解析は微視的な手法である。どちらも重要な視点で、それぞれの手法をバランスよく利用する必要がある。 大規模ソフトウェアの場合、微視的な視点からスタートすると、その規模のため、時間がおそろしくかかるという特徴があるので、最初は、巨視的な理解からはじめるのが王道である。その理解のプロセスの中で、興味のあるサブコンポーネント(論理的あるいは物理的な部分)へ到達したとして、そのサブコンポーネントの理解は徹底的に微視的な視点からはいるという方法もある。 例えば、あるソ
ユメのチカラ: 大規模ソフトウェアの効率的な理解（その3）
規模の把握 大規模ソフトウェアの理解はいろいろな観点からのアプローチがある。ソースコード一式(通常tarballと呼ばれている)を入手し、適当なディレクトリに展開する事からはじまる。tarballではなく、CVSのようなソース管理システムから直接入手する場合もある。 tar.gzというような形式の場合、$ tar xvzf XXXX.tar.gz というようなコマンドで展開する。$ cd XXXX してざっとディレクトリをながめる。通常、READMEないしINSTALLなどのファイルがあるので最初にそれを良く読む。またDocsなどというドキュメントを置いておく場所があれば、その中になにがあるかをざっと見る。 いきなりソースコードを変更するのではなく、このようにディレクトリ構造を調べたり、規模の把握をしたり、おおまかな骨格を理解するようにする。ディレクトリ構造は当該ソフトウェアの物理的構造を
ユメのチカラ: ソースコードの読み方
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
cscope: 対話的な C プログラムの検査
第 9 章 cscope: 対話的な C プログラムの検査 cscope は、C、lex、または yacc のソースファイル内のコードの特定の要素を探し出す対話型プログラムです。cscope ブラウザを使用すると、従来のエディタよりも効率的にソースファイルを検索、編集できます。これは、cscope が関数呼び出し (関数がいつ呼び出され、いつその関数を実行するか) についてと、C 言語の識別子と予約語を理解しているためです。本章は cscope ブラウザについて説明します。 この章は、このリリースに付属している cscope ブラウザの使い方を学ぶための資料として利用できます。説明項目は次のとおりです。 「cscope プロセス」 「基本的な使用方法」 「不明な端末タイプのエラー」 cscope プロセス cscope は、C、lex、yacc のソースファイルを読み取り、ファイル内の関
Life with Cygwin
沖ソフトウェア株式会社は、沖通信システム株式会社および株式会社沖インフォテックと平成22年10月1日をもって合併いたしました。新会社名は、株式会社OKIソフトウェアとなります。3社が行っております事業は新会社にて従来通り継続いたします。
Java IDE新潮流--第3回 Ruby/Rails開発も可能に：NetBeans 6
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Ruby／Railsにも対応するNetBeans 6.0 NetBeans 6.0の大きな特徴の1つとして、スクリプト言語RubyおよびRubyによるWebアプリケーションフレームワークRuby on Railsに対応していることが挙げられる。 RailsはRubyという言語の持つ柔軟さと強力さを最大限に活かした生産性の高いフレームワークとして注目を集めている。NetBeans 6.0の現在入手可能なプレビュー版（M9）はJava開発に関する基本機能のみの「Basic」、Web開発やモバイル開発をサポートした「Standard」、フルセットの「Full」と3種類のインストーラが提供されているが、Fullバージョンには標準でRuby／Ra
Life with Cygwin
沖ソフトウェア株式会社は、沖通信システム株式会社および株式会社沖インフォテックと平成22年10月1日をもって合併いたしました。新会社名は、株式会社OKIソフトウェアとなります。3社が行っております事業は新会社にて従来通り継続いたします。
2007-02-04
Tor Nobeyが今週のNetBeansーRuby環境の様子を書いていたりするんだけど、 2/2にNetBeansのCVSにあげたようです。 ■ Ruby Screenshot of the Week #3 http://blogs.sun.com/tor/date/20070202 ビルドのやり方も書いてくれているのでさっそくビルドしてみることにした。 ・・・・というわけで、 「はっし〜〜が夜なべをしてNetBeansビルドしたよ♪〜」 ・・・ああ、昨日は木枯らしが吹いていたなぁ。 チェックアウトからビルドまでを4回失敗して、結局５時間以上かかっちゃったよ（遠い目）。 最後はEclipse環境上でビルドしてやっと成功。 試してみると、おいおい、RDT（EclipseのRuby環境）って何だよ！くらいにすでに完成度が高い。 特にスゴイのが、 Syntax Coloring（コードの色づけ
ユメのチカラ: デバッグ方法論
実践的なデバッグ方法論（デバッグの仕方、事例研究）も強く求められている。デバッガーというツール依存のTipsではなく、ソフトウェアのデバッグというプロセスそのものの形式化である。 人々は誰に教わるでもなく自分のデバッグのスタイルを持っている。自分なりな定石を獲得している。しかしそれを明示化して人に伝えようと試みる人は少ない。伝承がまったく不可能なような議論も少なくない。 わたしはオープンソースの時代こそデバッグの方法論を広く共有できるチャンスに満ちた時代だと考えている。いくつか事例を紹介しつつ解説する。 優れたプログラマは優れたデバッグ方法論を持つ。そのデバッグ方法論をぜひ共有化したい。そのためには情報公開が要である。 デバッグとはプログラムの不具合を修正するプロセスである。テストなどによって発見された何らかの不具合を期待する結果に修正する作業である。テストとデバッグの区別が十分ついていな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://news.livedoor.com/article/detail/3187669/
ruby [Hudson]
netbeans.jp
http://shortcutkey.ivory.ne.jp/NetBeans/list1-2.html
bookshelf.jp
プログラミング言語 Ruby リファレンスマニュアル
IBM Developer
