6. #ccc_h4 デバッガ vs ユニットテスト • ユニットテスト! • 実装が期待通りに動くことを確認! • インプットに対して期待するアウトプットが 出るか
4月に新入社員としてWeb制作会社やSIerに入社した方も、開発業務に携わるようになり、HTML/CSS/JavaScriptを使ったフロントエンド開発を始めた方も多いかと思います。HTML/CSS/JavaScriptはWebブラウザーの上で動かせるので、気楽に開発が始められる半面、「デバッグが難しい」「不具合原因の特定が難しい」「どこにミスがあるのか分からない」というような話をよく聞きます。 そんなときに役に立つのがブラウザーに付属している「開発者ツール」です。「開発者ツール」を上手に使うと、不具合の原因特定を効率的に行えます。以下のように現行の全ての主要なブラウザー(Mozilla Firefox/Google Chrome/Microsoft Internet Explorer/Apple Safari)は「開発者ツール」を持っています。ブラウザー自体が無料ですので、もちろんこれら
Gemfile の 「group :test, :development do」ブロックに書いている 個人的に最強な設定 を晒したいと思います。(2013/10/24 現在) 作業環境 Ruby 2.0.0p247 Rails 4.0.0 Gemfileに設定している内容 ※ コメントに随時変更したものを追記しますー group :test, :development do gem 'pry-rails' gem 'pry-doc' gem 'pry-stack_explorer' if RUBY_VERSION >= '2.0.0' gem 'pry-byebug' else # 以下はRuby1.9の時のみ使う(pry-byebugの代わりに) # debuggerは1.9以下でしか動作しない, remote は byebug で使えないようになった gem 'pry-debugger
ソースコードリーディングとかしてると、ただコード読んでてもどうしようもなく、オブジェクトの中身や変数などを見るためにデバッグツールを使いながらでないとやっていけないことが今になって分かりました。自分でもどうしようもなくアホだと思いながら戒めのために覚書。 デバッグツールの機能 僕自身まともに触れる言語はjavascriptとphpくらいなもので、どちらもeclipseのようなIDEを使わず頑なにvimを使って組んできました。phpの場合はxdebugと連携させる方法*1や、javascriptならrhinoなんかを入れてquickrunとかって方法も考えられますが、僕はある程度は知っていながらもひたすら標準のスタックトレースやalert,console.log,console.dirばかりしていたので、まずはIDEなどに搭載されている一般的なデバッグ機能を復習をかねて覚書。 ブレークポイン
FirePHP enables you to log to your Firebug Console using a simple PHP method call. WebサイトやWebアプリケーションを開発する言語としてPHPは人気がある。世界最大規模のソーシャルネットワークサービスFacebookもサービスの開発にはPHPを採用している。提供するサービスが大規模になると一部をC/C++化して高速化をはかることもあるが、開発エンジニアの集めやすさやアジャイル性の良さもあって主要言語のひとつであり続けている。 HTML/CSS/JavaScriptをベースにWebサイトやWebアプリケーションを開発する場合、開発ツールとしてFirebugやブラウザベンダが提供しているデバッグツールが利用できるが、PHPのようにサーバサイドで動作するタイプの言語ではそう簡単にはいかない。しかしいくつか便利な
Seleniumとは SeleniumはIE、Firefox、Chrome、Safari、Operaといった多くのブラウザに対応しているWebテストツールです。操作を簡単にレコーディングでき、C#、VB.NET、Java、PHP、Perl、Rubyといったさまざまな言語から呼び出すことが可能です。詳細はこれはすごい! Web案件必須 Seleniumで確認してください。 環境の準備 本稿では、Visual Studio 2008、Selenium IDE1.0.4、Selenium RC1.0.1、NUnit2.5.2を使用してWebテストを行います。環境設定の手順は次の通りです。 Selenium IDEをインストール Selenium RCの配置 NUnitをインストール テスト用プロジェクトを作成 実行時にNUnitが起動するように設定 (1)Selenium IDEをインストール
前回: PHPソースコードリーディング入門(とっかかり編) - id:anatooのブログ PHPのソースコードを読んでいく際に、どうしてもソースコードを読むだけではよくわからない部分というのが出てくる。この記事ではPHPをデバッガで動かして内部の働きを明らかにする方法を書く。 ソースコードの取得 gitから取ってくる。 $ git clone https://github.com/php/php-src.git デバッガで動かせるようにビルドする 余計な拡張は無しで、デバッガで動かせるようにビルドする。configure時に--enable-debugオプションを渡す。 $ cd php-src $ ./buildconf $ ./configure --disable-all --enable-debug $ make GDBで動かす makeした後、コマンドラインで動かせるバイナリは
この前その紹介記事見つけたんで,それを真似しながら実際動かしてみた。きしださんの例がちょうどよかったので,これを題材にしてみたよ。 Runner#run()の適当なところにブレイクポイント仕込んでデバッガを起動する。するとスレッドごとに同じ場所で止まるんで,こんな具合に教えてくれる(この時点ですでにスゴイ)。 適当なスレッド選んでステップ実行とかするわけなんだが,スレッドの一覧が表示されているんで,どんだけスレッドが起きてるとか,どのスレッドが止まってるとか丸分かり。さらにスレッド一覧の右端には,スレッドの停止・再開ボタンが付いているので,興味ないスレッドは先やっててみたいなことができる(スゴイよね)。 さらにダメ押しなのが,ステップ実行中に他のスレッドがどこで停止しているかも見える!!(超スゲぇ) 緑色の矢印&ハイライト行が現スレッドの実行位置で,歯車アイコンが他のスレッドの実行位置(停
This article covers several techniques for debugging Python programs. The applicability of these techniques ranges from simple scripts to complex applications. The topics that are covered include launching an interactive console from within your program, using the Python debugger, and implementing robust logging. Various tips are included along the way to help you debug and fix problems quickly an
Archives 2018 (1) February (1) 2015 (1) March (1) 2014 (6) June (1) March (1) February (2) January (2) 2013 (4) December (1) May (1) January (2) 2012 (4) December (1) November (3) 2011 (2) September (1) April (1) 2010 (1) February (1) 2009 (11) December (1) July (3) May (3) February (1) January (3) 2008 (22) December (9) August (3) July (2) June (1) May (1) February (3) January (3) 2007 (35) Decem
iPhoneアプリを作ってると、時々プライベートライブラリの中身が気になったりとかありますよねー。 世の中には色々な人がプライベートライブラリのヘッダファイルを解析して、その情報を提供してもらえてるけども、メソッドの引数がオブジェクトの場合は(id)になってることがほとんど。 でも、これじゃオーバーライドしてごにょごにょするのにとても不便。 引数のクラスが分かってるととても便利になるのに。 そういう時にxcodeの「シンボリックブレークポイント」を使うと、プライベートライブラリでもなんでも調べることができる。 ただし、シンボル名が分かっているならば。 以下、使い方。 今回はPhotoLibraryフレームワークの PLCameraView クラスのインスタンスメソッド CameraControllerReadyStateChanged: を例に挙げてみる。
This is a command-line utility for examining the Objective-C runtime information stored in Mach-O files. It generates declarations for the classes, categories and protocols. This is the same information provided by using ‘otool -ov’, but presented as normal Objective-C declarations, so it is much more compact and readable. Why use class-dump? It’s a great tool for the curious. You can look at the
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ƒ‰ƒŠ‚ÌŠ
President of WebFX. Bill has over 25 years of experience in the Internet marketing industry specializing in SEO, UX, information architecture, marketing automation and more. William’s background in scientific computing and education from Shippensburg and MIT provided the foundation for MarketingCloudFX and other key research and development projects at WebFX. Microsoft’s Internet Explorer 6 is alm
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog おひさしぶりです。オークション担当の山崎 賢です。 前回はPHP Serialize についてでしたが、 今回はPHPでのデバッグに関してお話します。 基本PHPはインタプリタ(厳密にはPHPは内部で一度コンパイルしていますのでインタプリタとは言い切れませんが) のデバッグではログ埋め込みが手軽です。 しかし、まれにSIGSEGVやSIGBUSなどでPHPスクリプトが落ちることがあり、途方にくれます。 地道にログを埋め込んでいき、箇所を特定するのも手法の1つですが、今回はgdbを用いたデバッグ方法を記載したいと思います。 ■STEP1 まずは、プログラムが落ちることを目的として以下のようなPHP Moduleを作成します。 ・ ・
Google が公開しているソフトウェアの解説シリーズ(→その1 , その2)の続きです。今回は google-glog を使ってスタックトレースを表示する方法についてご紹介します。 C++ でプログラムを書いているとよく遭遇するのがセグメンテーション違反というエラーです。不正なアドレスへのアクセスなどによりセグメンテーション違反が起きると、通常、 UNIX 系の OS では SIGSEGV というシグナルによってプログラムが終了するとともに、 core というファイルが作られます。 core ファイルにはデバッガから参照できるいろいろな情報が残っていますが、多くの場合に役に立つのは、スタックトレースという情報です。スタックトレースを見れば、プログラムがどこでクラッシュしたのか、どのような関数を経由してそこにたどり着いたのかがわかります。プログラムがクラッシュした箇所を特定できれば、単純な
BOOK: WEB+DB Press TITLE: 常駐型サーバーのデバッグ手法(ドラフト版) AUTHOR: (株)プリファードインフラストラクチャー 太田一樹 *注: この文章はWEB+DB PRESS Vol.48に掲載された記事のドラフト版です はじめに 今回はデバッグ関連特集ということで、常駐型サーバープログラムを作成する際のハマりどころやそれに対する解析方法・解析ツール・対策を、実際の経験を交えながら紹介したいと思います。 筆者は(株)プリファードインフラストラクチャーでインメモリ分散検索エンジン「Sedue (セデュー)」を開発しています。モバイル向け検索エンジン「エフルート」や、2008/11/6にリニューアルされました「はてなブックマーク2」などの検索バックエンドとして使われております。 この検索エンジンはいくつかの常駐型サーバープログラムから構成されており
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く