ソフトウェアのバグをなくすには？--プログラミングの際に避けるべき10の失敗
筆者はカリフォルニア大学バークレー校の公開講座でオブジェクト指向プログラミングを教えており、ソースコードそのものに対する理解を助けるために費やす時間と同じくらいの（あるいはそれ以上の）時間をかけて、優れたプログラミングプラクティスとは何かを教えている。本記事では、この講座の学生らがしでかす数多くの過ちを紹介したい。 なお、本記事を執筆するにあたり、ノースウェスタンポリテクニック大学工学部のJames A. Connor教授に連絡を取り、同教授の学生たちがしでかす過ちを紹介してもらった。 ＃1：コメントの付け方が貧弱 コメントという要素は、プログラム内に記述されながらも、コンピュータによって実行されることはない。これはプログラマーによって記述されるメモ書きであり、ソースコード内での処理を説明するためのものだ。 学生らの多くは、ソースコード中にコメントを記述せずに済ませようとする。また、コメン
第5回 体力vs.スキル | gihyo.jp
最近、ジム通いをはじめました。最初は億劫（おっくう）でしたが、慣れてくると体を動かすのも良いですね。ただ、自分の体の輪郭がだんだん気になりはじめ、ジムを闊歩（かっぽ）する筋骨隆々の男たちを眺めながら申し訳ない気持ちになったりしています。 職業プログラマである私にスポーツ選手のような筋肉がなくても、それは仕方がありません。代わりに専門たるプログラミングでならそこらの非専門家には負けないはずです……と言いたいところですが、どうでしょう。スポーツ選手の筋肉に並べて恥じないプログラミング力を、どれだけのプログラマが持っているのでしょう。そもそもプログラミングで筋肉にあたるものは何なのでしょうか。 筆者の勤務先には競技プログラミングの出身者が多くいます。競技プログラミングとは、与えられた問題に答えるコードを書いてコーディングの速度や正確さを競うゲームです。TopCoderやICPC（Internat
実行中のアプリケーションを外から観察するコマンド。 - こせきの技術日記
strace システムコールをトレース。カーネルと何を話しているか。 strace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 straceを使ったデバッグ - SourceForge.JP Magazine : オープンソースの話題満載 Linuxカーネルの作り出す世界 − ＠IT自分戦略研究所 - ふつうのLinuxプログラミング 青木峰郎 システムコールとライブラリ関数 − ＠IT自分戦略研究所 システムコール・ライブラリルーチン - UNIX の部屋 ltrace 共有ライブラリの呼び出しをトレース。*.soと何を話しているか。 ltrace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 ltrace で共有ライブラリの関数呼び出しをトレースする - bkブログ 404 - エラー: 404 - Linux JF ƒ‰ƒCƒuƒ‰ƒŠ‚ÌŠ
Apacheモジュールの作成とgdbとloggerでのデバッグ方法 - よねのはてな
ApacheのFilterモジュールを作った話しをしたらid:c9katayamaに情報公開しろと言われたままでしたので公開します。 C言語の勉強しようかな、Apache2.xのモジュールを作ってみようかな、gdb使ってデバッグしてみようかなと考えてた人にお勧めです。 JavaでのServletの開発経験のある人であれば、Filterの処理の動きやリクエストコンテキストの考え方は分かり易いはずなので、エントリを読み終わる頃にはApacheのモジュールをgdbでデバッグしながら作る事が出来るはずです。 mod_orzを作成 今回はmod_orzというApacheモジュールを作成します。 Apacheモジュールを作成する際には、apxsというモジュール開発用のコマンドを使用しテンプレートを作ります。 # apxs -g -n orz Creating [DIR] orz Creating [F
C++ のプログラムのデバッグを楽にする方法
Google が公開しているソフトウェアの解説シリーズ(→その1 , その2)の続きです。今回は google-glog を使ってスタックトレースを表示する方法についてご紹介します。 C++ でプログラムを書いているとよく遭遇するのがセグメンテーション違反というエラーです。不正なアドレスへのアクセスなどによりセグメンテーション違反が起きると、通常、 UNIX 系の OS では SIGSEGV というシグナルによってプログラムが終了するとともに、 core というファイルが作られます。 core ファイルにはデバッガから参照できるいろいろな情報が残っていますが、多くの場合に役に立つのは、スタックトレースという情報です。スタックトレースを見れば、プログラムがどこでクラッシュしたのか、どのような関数を経由してそこにたどり着いたのかがわかります。プログラムがクラッシュした箇所を特定できれば、単純な
Web 開発者の責任 (翻訳): Days on the Moon
John Resig 氏による A Web Developer's Responsibility という記事が素晴しかったので、著者の許可を得てここに日本語訳を掲載します。 Web 開発者の最大の負担は、ブラウザのバグと非互換性への対応に膨大な時間を費やすことであるといって間違いないでしょう。それゆえに、それらへの対応に不満をいうのは、Web 開発者全員の常となっていました。ブラウザのバグは迷惑でいらだたしく、仕事を大幅に難しくします。 ブラウザのバグはとてもいらだたしく、通常の開発における最大の負担です。ですから、開発対象のブラウザが、自身のバグを見つけ修正できるようにしてやるのは、すべての Web 開発者にとっての責任です。自分が見つけたバグに対して責任を持ち、「ほかの誰かがこれを見つけるだろう」とは思わないことで、ブラウザの進歩の速度は加速していくでしょう。 ブラウザを支援する解決策
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Efficient data transfer through zero copy
