node.js+QUnit+QUnit-TAP+ant+JenkinsでJavaScriptのCI
2004 01 02 03 04 05 06 07 08 09 2004年9月：1エントリ 10 2004年10月：1エントリ 11 2004年11月：1エントリ 12 2004年12月：1エントリ 2005 01 02 03 04 2005年4月：13エントリ 05 2005年5月：18エントリ 06 2005年6月：28エントリ 07 2005年7月：42エントリ 08 2005年8月：39エントリ 09 2005年9月：41エントリ 10 2005年10月：22エントリ 11 2005年11月：20エントリ 12 2005年12月：35エントリ 2006 01 2006年1月：12エントリ 02 2006年2月：6エントリ 03 2006年3月：10エントリ 04 2006年4月：17エントリ 05 2006年5月：9エントリ 06 2006年6月：12エントリ 07 2006年7
[PHPプロ!] FirebugをPHPのデバッガとして使う方法
AJAX Magazineで、Firefoxのアドオン Firebug を使ってPHPのデバッグを行う方法が紹介されています。FirebugはJavaScriptのデバッグをするときに非常に便利なプラグインですが、ここで紹介されているスクリプトを利用すればJavaScriptだけでなく、PHPのデバッガとしても非常に有効なツールとして使うことが出来るようになります。 AJAX Magazineで、Firefoxのアドオン Firebug を使ってPHPのデバッグを行う方法が紹介されています。FirebugはJavaScriptのデバッグをするときに非常に便利なプラグインですが、ここで紹介されているスクリプトを利用すればJavaScriptだけでなく、PHPのデバッガとしても非常に有効なツールとして使うことが出来るようになります。 まず以下のURLの記事の下の方にある150行ほどのスクリプト
![[PHPプロ!] FirebugをPHPのデバッガとして使う方法](https://cdn-ak-scissors.b.st-hatena.com/image/square/106c7e478be88bc515873fc79870c7b92dd94618/height=288;version=1;width=512/https%3A%2F%2Fcodezine.jp%2Fstatic%2Fcommon%2Fimages%2Fczlogo4fb_ogp.png)
KMC Staff Blog:リアルタイムトレース
2009年09月08日 リアルタイムトレース ARM のリアルタイムトレースで、ETM と ETB という似たような用語が存在し、それぞれがどのようなものなのかイマイチ理解していなかったのですが、辻先輩に軽くレクチャーしていただいたので忘れないうちにメモしておきます。 （ただし、これはあくまでも私が理解したところなので、間違いが多分にあるかと思いますし、特にレビューを受けてもいない文章です。文責は私にあります。） リアルタイムトレースとは、プログラムの実行中の PC の動きや、データアクセスの際のアドレスやアクセスタイプ (R/W) などをキャプチャーする機能のことです。基本的には CPU に負荷をかけずに済むので、実際にプログラムを動作させた時の CPU の状態遷移をそのまま見ることができます。(遅くなるものもあるそうです。) 組み込みではリアルタイム性が重要なプログラムが多いので、トレ
Debug Hack - odawaraの「はてな de メモ」
次の日も深夜ですが(書き忘れてたんだよ…)とりあえず買っておきました。 Debug Hacks -デバッグを極めるテクニック&ツール 作者: 吉岡弘隆,大和一洋,大岩尚宏,安部東洋,吉田俊輔出版社/メーカー: オライリージャパン発売日: 2009/04/27メディア: 単行本（ソフトカバー）購入: 12人 クリック: 419回この商品を含むブログ (74件) を見るodawaraはデバッガ大好き、デバッグ大好きですよ。 VisualStudio、gdb、HEW、insight、デバッグが楽になるならなんでもいいよ。 特にハードウェアなデバッガが好きで、 PARTNERはいい。 京都マイクロコンピュータ株式会社：JTAG ICE PARTNER-Jetは、高速・高機能で多様なCPUシリーズに対応したJTAG ICE(エミュレータ)です。 E8a+HEWもすばらしい。 http://japan
大変なバグというか出力データ内のバグというか - 兼雑記
TCC というコンパイラをいじって遊んでいるのですが、簡単なバグから潰しているので、だんだんと混み入ったバグになってきました。今いじっているのは、 ./tcc tcctest.c && ./a.outとして実行した結果と、 ./tcc -DTCC_TARGET_X86_64 tcc.c -ldl -g -o tcc2 ./tcc2 tcctest.c && ./a.outなどとして tcc で自身をコンパイルして、それでできた tcc2 を使って tcctest.c を実行した結果で、結果が違うというものです。 問題となっているテストケースは printf もどきを test 内で実装して、 stdarg がきちんと動作しているかを確認するようなテストケースでした。 実際コードを見てみると、確かに生成されている printf もどきのコードは微妙に違っていて、まぁそれはヘンだなぁと生成され
テストドキュメントやらなんやらを書く - ニート=>ネトゲ屋=>ブラック=>電話屋
テストドキュメントを書く。初めてだ 詳細設計をにらみながらテストを書いて。。。 なんだこのゆるふわな詳細設計。。。私が書きました。 関数を叩くループは黒い画面にprintデバッグな文字列が流れていく。 修正もたくさん。 自分のコードが鍛えられていく感じがちょっとうれしい。 しかしコードを書くより詳細設計とテストと修正をしている時間の方が 長いとは大丈夫なのか? 才能は無いな。 悩まず書ける様にならねば。 詳細設計を書く段をもっとソリッドにしないと後が大変だと 思います。 で、詳細設計を書く人間とコードと単体テストを書く人間は同じな方が 良いと思います*1。とりあえずは。 おもしろいなぁ。 *1:設計は独りよがりじゃなくてチームの承認が必要ですけど
hogetrace - 関数コールトレーサ - memologue
でかいソフトウェアの、大量のソースコードを短時間で読む必要が生じたので、その補助ツールとしてptrace(2)ベースのLinux用関数トレーサを自作しました。こういうツール上でまずソフトウェアを実行してみて、どのファイルのどの関数がどういう順で呼ばれるか把握おけば、いきなりソースコードの山と格闘を始めるより楽かなーと思いまして。せっかく作ったので公開します。 http://binary.nahi.to/hogetrace/ straceはシステムコールだけ、ltraceは共有ライブラリ(DSO)の関数呼び出しだけ*1をトレースしますが、このツールは、実行バイナリ中の自作関数の呼び出しもトレースします。例えば再帰で1から10まで足し算するソースコードを用意して % cat recursion.c #include <stdio.h> int sum(int n) { return n ==
ホワット・ア・ワンダフル・ワールド アルゴリズミックデバッギング
研究グループの内輪の研究会がありまして，ET プログラムの自動デバッギングの話が面白かったです． (人間が頭で考えて，直接ルール (プログラム) を手書きした場合用．また，原理的に，形式的仕様記述から自動生成されたプログラムは，仕様に対しては 100 % バグが無いわけですが，それとは別のレイヤーとして，生成されたプログラムが「人間の直感的意図 (ここはインフォーマル)」と異なる挙動を示した時には，仕様のデバッグが必要になってくるので，さらに高度な研究が必要になってくる) その研究自体の詳細は (私の研究ではないので) 書けないのですが．既存研究との比較として挙げられていた，サーベイペーパーが，これまた興味深かったです． Josep Silva, "A Comparative Study of Algorithmic Debugging Strategies", 2007 論理プログラムや
ホワット・ア・ワンダフル・ワールド いろいろあって，就職することになりました
2008 年 11月 21 日付けで，京都マイクロコンピュータ株式会社に入社することになりました． 「デバッガは神の手 （社長談）」 ということで，ハードウェアとソフトウェアの全てを掌握し支配するデバッガ技術を基幹として，ソフトウェア開発の世界を改革していけたら良いなと思っています． 社長の名言集 （ちなみに KμC は，社長が一番コードを書いてるという変な会社です） 「パートナー ※ が無い環境ではもうプログラミングできへんわ．逆に言うと，パートナーさえあれば，OS はなんでもかまへん．emacs 使う人が，emacs の中で全部やるのと同じやな」 (※ KμC が販売しているデバッガ．一番 KμC のデバッガを使っているのは，KμC の社員です) 「優れたデバッガがあれば，コードの書き方が変わる．うちの会社のコードはかなり独特で，普通のプログラマは追えないしわけわからんと思う．だけど，
プログラミングの生産性向上
このコーナーでは、プログラミングの生産性について考えます。システムのコスト は検討段階から始まって、稼働後に色々の改良や変更を経て、廃棄するまで掛かりま す。システムが稼働するまでの初期コストと、稼働後の維持コストを調べてみると、 予想に反してほぼ３：７の割合で維持コストが倍以上にななります。ですから、 メインテナンスのし易いシステムを最初に作り上げて置かないと、莫大な維持コスト が必要になります。 さらに、プログラミングの生産性を左右する仕事にデバッグがあります。デバッグ が不十分だと、稼働後に大きな損失となる事はもちろんですが、プログラミング作業 の中でもデバッグは作業の大部分を占めます。デバッグの上手下手がそのままプログ ラミングの生産性に繋がります。 それでは、上手なプログラミングについて、探求にでかけましょう。 講演内容 １. 構造化プログラミング手法 ２. プログラムの定型を作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 実践 デバッグ技法 ―GDB、DDD、Eclipseによるデバッギング: Norman Matloff (著), Peter Salzman (著), 相川愛三 (翻訳): 本
デバッガとか - なつたん
長文日記