
プログラミングに関する雑多なあれこれ 今号から、「プログラミングの光景」と題して連載することになった高林と申します。プログラミングは趣味として、仕事として、かれこれ10年ほど行ってきました。本連載ではプログラミングに関する雑多な事柄について書く予定です。 第1回は、プログラミングとは切っても切れない関係にある「デバッグ」について取り上げてみようと思います。 デバッグの時間 ソフトウェア開発において、デバッグに要する時間は相当のものです。プログラマとしては「いやいや、自分はそれほどデバッグに時間を使ってないよ」と否定したいところですが、冷静に考えてみると、現実には自分が考えているよりも(そうであってほしいと考えているよりも)デバッグに時間を要しているように思えます。それに、バグは他人が書いたコードに混入していることもあるので、たとえ自分がバグを入れなくてもデバッグするはめになります。 デバ
この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり:私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ
はじめに DTrace とは 皆さんは DTrace をご存知でしょうか? DTrace は Sun Microsystems のブライアン・キャントリル(Bryan Cantrill)氏によって開発された、汎用情報採取のフレームワークです。 キャントリル氏へのインタビューでも語られているように、カーネルの動作状況を調査/確認することは、これまで非常に困難な作業でした。 しかし、DTrace の登場により、実際に稼動中のシステムのカーネルからも、安全に(かつ低コストで)情報を採取できるようになりました。 また、DTraceによって解析が容易になったことで、これまで解決することができなかったSolarisカーネルの(潜在的だったものも含めた)実装上の問題も、多数改善することができたのだそうです。 カーネル開発に関わったことがある方ならもちろん、通常のアプリケーション開発であっても、次のような
https://www.youtube.com/watch?v=7KS4L-mA_-c 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Takipi のFounderであるTalWeissのSan Francisco Java User Groupミートアップでの講演。本番環境で役に立つデバッグテクニックの紹介です。 1. スレッド名の活用 スレッド名はmutable(EJB除く)である。コードのコンテキストにあわせて、Thread.currentThread().setName(Context, TID, Params, Time,...);のようにすれば、トランザクションID、Serveletパラメータ、キューメッセージID、起動時間など、スタックトレースに役に立つ情報を表示できるようになる。 J
完了するまでに結構時間がかかるプログラムを実行している時,そのプログラムの進捗度を確認したくなることがままあると思います.ほんとに動いてんのかお前,みたいな. そうした時に考えうる最も簡単な方法は,こんな感じで進捗度を標準出力に流してしまうという方法でしょう. (1..100).each do |i| # 例えばここで何らかの重い処理をする (下のsleepはその「何らかの処理」の例) sleep 0.1 # ここで進捗を表示 (プログレスバーみたいなもっとリッチな感じでも可) puts "#{i}%" end 簡単なものだとこれで良いでしょうが,途中で端末のセッションが切れると「アッアッ」という感じになったり,そもそもプログラムの実行に際して端末が割り当てられいるとも限らないし,というか時間のかかるプログラムがその処理中ずっと端末を占領しているのはつらいので別の方法が欲しかったりします.
使用頻度が高いのはデベロッパーツールを起動するCtrl+Shift+I(もしくはCtrl+Shift+J)と、コンソールを開閉するESC、コンソールでは補完候補を選択するtabなどが挙げられます。 例えば、長くて間違えやすいencodeURIComponentのスペルは、Ctrl+Shift+Jでデベロッパーツールを起動してコンソールを開き(コンソールが開かなかった場合はESC)、eだけ打ってtabキーを2回押せば encodeURIComponent が補完されるので、スペルを簡単にコピーできます。 JavaScriptデバッガの活用 前回はブレークポイントの設置方法を紹介しましたが、もう一歩進んだ条件付きブレークポイントの設置方法を紹介します。 まず、通常のブレークポイントを設置します。 この青くハイライトされた行番号の上で右クリックすると次のようなメニューが表示されます。 ここで
あるプログラミング言語がその仕事に適したものであるかといった議論は論争に発展しがちだ。時には宗教戦争の様相を呈することがあるものの、プログラミング言語がコーディングプロセスだけでなく完成した製品の特性にも影響することは多くの方が同意するところだろう。これについてカリフォルニア大学デイビス校のコンピューターサイエンス研究者らが、プログラミング言語のソフトウェア品質に与える影響(PDF)に関する調査結果を発表した。研究ではGitHubの729プロジェクト(17言語、29,000人が書いた8,000万行のソースコード、150万コミット)を分析。大きなサンプルサイズを利して混合研究法のアプローチをとり、複数の回帰的モデリングやテキスト解析を組み合わせて静的型付けと動的型付け、型付けの強弱といったプログラミング言語の特徴がソフトウェアの品質に与える影響を調べた。異なる手法による調査結果を組み合わせ、
Firefox 3とFirebugで始めるJavaScript開発 第2回Firebugによるデバッグの基本、Console APIとその活用 さて、前回はインストールからFirebugのタブの基本的な部分について紹介をしてきました。今回は、Firebugに実装されているConsole APIの紹介と、Console APIを利用したデバッグ手法について解説していきます。 Firebugで利用できるAPI Firebugには、デバッグに活用できる2つのAPIが実装されています。今回は、その2つあるAPIのうちConsole APIについて解説していきます。 Console API Console APIはFirebugのタブだけでなく、コンテンツ側のJavaScriptから呼び出すことのできるAPIです。デバッグのために便利な関数があらかじめたくさん用意されています。これらの関数を以下
ソフトウェア開発で不可欠なデバッグですが、知識と経験が求められるため熟練プログラマのなかにもデバッグが苦手という開発者は少なくありません。洗練されたデバッガを利用できても、デバッガのどの機能がどの場面で有効かを見極めるのは簡単ではないからです。本書では、Linux/Unixプラットフォームでもっとも広く使われているGDB、DDD、Eclipseという3つのツールを取り上げ、各ツールに独自のデバッグテクニックはもちろん、コードに含まれるエラーを見つけ出して修正するプロセスを改善するための総合的な戦略についても解説します。翻訳版ではVisual C++でのデバッグ手法についても加筆しました。 関連ファイル サンプルコード(.zip) 正誤表 書籍発行後に気づいた誤植や更新された情報を掲載しています。お手持ちの書籍では、すでに修正が施されている場合がありますので、書籍最終ページの奥付でお手持ちの
更新版: まずはここで私がコンソール ロギングでのデバッグを非難したり、無視しようとしているのではないということをはっきりさせておきたいと思います。コンソール ロギングは組み込み型プログラムやIDEがソースコードをスタックフレームに正しくマッピングできない場合、ブレークポイントが進捗を妨げてしまう場合等、様々な場合に使われます。要は他に適した方法がある時にコンソール ロギングを使うことを悪いと思っているのです。 プログラミングでは新しい機能を加える代わりに、 コードのメンテナンス と問題の解決にそのほとんどの時間を費やされるということが常識になっています。また、デバッグを通じて問題を発見できてもそのバグの解決方法がわからないということが多いのです。また ハイゼンバグやネッシーバグ のような再現できないバグに遭遇することもありますが、通常はどこを探すべきかが全くわからない状態で、大規模なコー
TOPICS Hacks , Programming , Linux , Ruby 発行年月日 2009年04月 PRINT LENGTH 424 ISBN 978-4-87311-404-0 FORMAT PDF ミラクル・リナックス株式会社の精鋭エンジニアたちが、長年のLinuxカーネル開発の経験で培ったデバッグテクニックを詳解。こころがまえから、準備、必要な知識、バグの原因をすばやく特定し修正するために便利なテクニックとツール、高度なデバッグ技まで惜しみなく披露します。多くの事例に基づいた実際的実用的な技が満載です。効率良くかつクオリティーの高い開発のために必須の一冊です。 Debug Hacks推薦の言葉 プログラムにはバグが付き物です。バグは人間の予想を超えたところからやってきます。世界最初のバグは、リレー式計算機の中にまぎれこんだ蛾だったそうです。あわれリレーの間に挟まれた蛾に
https://www.youtube.com/watch?v=VV7b7fs4VI8 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 パッケージ(apt, yum, gem等)レポジトリのホスティングサービスであるPackageCloudを開発している、James Golickの講演です。 パフォーマンスの高いハイクオリティなソフトウェアをデプロイしたければ、あらゆるレベルでバグ修正ができるようになること。 まず、エピソードとして紹介しているのが、友人の会社のサイトが落ちて、あいにく、その会社のエンジニアが出払ってしまっていて、どうにかしてほしいと助けを求められたときのこと。 ソースコードを見たことない。 システムの構成を知らない。 phpは詳しくない。 SSHでアクセスできる情報だけはある。 とい
Linuxカーネルに興味があるんだけど特に作りたいものってないんだよなーなんて割とあると思う訳です。俺とか。。。 まあ、kernelnewbiesのメーリングリストでもよく見る話題かと思います。この辺なんかもそうですね。 で、そんな時にオススメできるのがkmemleak。カーネルに組み込まれたメモリーリーク検出ツールです。 使い方は至って簡単でカーネルのコンフィグレーションにあるKernel memory leak detectorを有効にしたカーネルを普通に使えばOK。カーネルはメインラインのrcでもtipでもlinux-nextでも何でも良いと思います。 設定の場所はKernel Hacking -> Memory Debugging -> Kernel memory leak detectorにチェックをするのと、 その下のMaximum kmemleak early log ent
Rack限定ならむかし rack-spyup というものを書いた。自分で使ってみたけどJSON APIのデバッグとかだと革命的に便利だと思う。 ただ、Rackに到達する前にリクエストがお亡くなりになったりとか、そもそもサーバルビーじゃないしとかあると思うので、もっと汎用的な感じでダンプする手順をメモしてみる。 リクエストが来たら内容を全部ダンプするHTTPサーバを作る Rubyに標準添付されている、WEBrickの基本的な機能で割と簡単に作れる。 # -*- coding: utf-8 -*- require 'optparse' require 'webrick' require 'json' options = ARGV.getopts("p:", "port:") # The :monkey: raises # cf. http://d.hatena.ne.jp/vividcode/
圧縮後のJavaScriptやコンパイル後のCoffeeScriptでも、ブラウザ上で元のソースを参照できる新技術「Source Maps」登場 JavaScriptをデプロイする際には、できるだけ小さくするために余計なスペースや改行を取り除き、さらに関数名なども変換して圧縮することがあります。しかし圧縮後のJavaScriptにバグが見つかるとそのままではデバッグしにくいため、いちいち元のソースコードに戻してデバッグしなければなりません。 Webサイト「HTML5 Rocks」の記事「INTRODUCTION TO JAVASCRIPT SOURCE MAPS」で紹介されたWebブラウザの新技術「Source Maps」は、圧縮状態のコードを実行していても元のソースコードを参照しながらデバッグできるだけでなく、CoffeeScriptのようなJavaScriptへ変換する言語であっても、
子供のころからできるだけ手抜きして成果を挙げることだけは長けている山本です。 今回は、C/C++ で作ったプログラムが運用中にクラッシュするときのデバッグ方法のお話しです。 開発中のデバッグは gdb などでソース追いながらデバッグできますが、運用中ですと strip していたり最適化していたりしてデバッグが難しくなります。 そもそも、いきなりクラッシュすると情報が残らずに困ってしまいます。そんなときどうするか。 Step1. スタックトレースを出力する こんな関数を用意しましょう。Linux 以外の人はそれなりに実装してください。 #include <execinfo.h> #include <unistd.h> void dump_stack() { void* bt[100]; int n = backtrace(bt, 100); backtrace_symbols_fd(bt,
Reveal (http://revealapp.com/) なる iOS 向けのランタイムインスペクタなるものを知人のツイート経由で見つけた。ランタイムインスペクタとは何か ・・・ "Reveal brings the power of tools like Firebug and Web Inspector to iOS developers." ということでiOS アプリ用の Firebug みたいなのだと思えば良い。 動画を観てると確かにすごい。3D で動かしながら View の階層を手繰ってアプリのビューがどういう構造になっているかを見ていくことができる。更に動的にパラメータを変更して大きさや動きを変える、なんて Firebug の css の編集みたいなこともできるようだ。ベータ版は無料のようだ。 これは捗る。 RubyMotion で動かす ドキュメントを見てみたところ Re
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く