BLeak: Automatically debug memory leaks in web applications
Automatically debug memory leaks. BLeak automatically locates, ranks, and diagnoses memory leaks in client-side web applications. Works on , , and . Install today: $ npm install -g bleak-detector Builds on and requires MITMProxy 4 $ pip install mitmproxy==4.0.1 1. Write a configuration file. The configuration file specifies a loop of screens (or "visual states") that BLeak will run through.
インタプリタ開発者によるRubyの挙動解析への道 - クックパッド開発者ブログ
Ruby インタプリタを開発している笹田です。今年のクリスマスにリリース予定の Ruby 2.6、楽しみですね（無事、出るといいな）。 この記事では、私がRubyの挙動を調べるために頑張った記録を書いておきます。 基本的に、単純作業の積み重ねなので、難しい内容はありません。お気楽にお読みいただければ幸いです。 大雑把にまとめると、こんな内容が書いてあります。 デバッグカウンタの導入によるRubyの詳細な挙動調査の紹介 （私には）簡単な話で、Rubyをいろいろいじって、Rubyの細かい挙動、しかもほとんどの人が気にしない挙動を調べられるようにした話です。 多くの人が興味ないだろう、Rubyに仕込まれている統計情報をとる仕組みを紹介します。 クックパッドアプリを手元で調査できるようにした話 （私には）難しい話で、Ruby 開発版で弊社アプリを手元で動かすために四苦八苦した記録です。 Ruby
iOSDC ベストトーク賞2位の発表の蛇足 #iosdc - 若くない何かの悩み
iOSDC Japan 2018 で、ベストトーク賞2位をいただきました。タイトルは「iOSアプリの開発速度を170%に向上させたデバッグノウハウ」です。この記事では、スライドの紹介に加えて、スライドに書ききれなかった背景やレビュー体制などについてお話ししようと思います。 発表スライド スライドでは語られていない発表の目的 この発表は少し特殊な構成で組まれています。発表内で繰り返し出てくる「動作確認の自動化」とは、実のところ「テスト」のことです。しかし、私はこの発表でなるべく「テスト」というキーワードの使用を避けました。 この背景には、iOSDC ではテスト関連の CfP が通らないという経験則があります。私はこの原因を CfP 選考に関わる方たちに次のような人が多いからではないかと推測しました： テストをやったことがなくて興味がない テストに嫌な体験がある そこで、上記のような方にも受け
Xcode8 で開発はどうかわったのか
iOSオールスターズ2 https://eventdots.jp/event/602872
Xcode で快適なデバッグライフを追い求める
iOSDC https://iosdc.jp/2016/c/node/116 僕は怠惰な人間です。プログラミングの大半はデバッグに時間を費やすと思っているので、なるべく早く原因に辿りついたり効率のよいデバッグライフを送りたいと常々思っています。 プリントデバッグもいいのですが Xcode には便…
他人の書いたコードに挑もう – Part 1 | POSTD
この記事では、他人が書いたコードを扱うための練習法を一から説明します。目標は、 Spyder Python IDE という今まで触ったこともないプロジェクトのコードに任意の変更を加え、途中で行き詰ることなく、目的達成に必要な情報 のみ 習得することです。ここでは、勘や実験的な手段、そしてプロの現場で養った洞察力を武器に問題に対処する方法を学びます。形式ばったレッスンのように、苦痛を感じることはないでしょう。満足感や挫折、葛藤を味わいながらプロジェクトを進め、最終的には（なんとか動く程度の）パッチを完成させ、大規模で不慣れなコードベースに機能を追加します。 プログラミングを学んでいる人は皆、あらゆる種類のプログラムで大量のコードを書いています。それは、問題集に載っているアルゴリズムを実装するにせよ、ウェブサイトの構築やビデオゲームの作成をするにせよ同じです。ところがプロのソフトウェアエンジニ
gdbを使ったrubyのデバッグ - クックパッド開発者ブログ
技術部の国分 (@k0kubun) です。 先日byebugの高速化を行っていた最中、変更を加えたbyebugを使っていると一定の確率でrubyがSEGVするバグを発見しました。 私はC言語のコードのデバッグの経験はなかったのですが、デバッガの使い方を調べながらSEGVの原因調査を行いパッチを送ったところ無事取り込まれ、最新の高速なbyebugが安全に使えるようになりました。 その際、ruby自体をデバッグするために必要な情報が分散していて大変だったので、まだrubyのデバッグをしたことがないけれどやってみたいという人を対象に、gdbというデバッガを使ったrubyのデバッグの方法を紹介します。 デバッグ用にrubyをビルドする デバッグ時に変数名やソースコードなどの情報を見るためには、最適化オプションをオフにしてデバッグ用にrubyをビルドしておく必要があります。 rubyのデバッグ用ビル
byebugやpry-byebugを使った後の挙動を10倍高速にしました - k0kubun's blog
byebugとpry-byebugのbundle updateをしましょう byebugはRails標準でインストールされるRuby 2.1, 2.2向けのデバッガで、pry-byebugはpry *1 にデバッガの機能を追加するpryのプラグインです。 一昨日から今日にかけて、以下のパフォーマンス改善を含む byebug v8.0.0 と pry-byebug v3.3.0 がリリースされました。 github.com github.com byebugとpry-byebugには、一度byebugやbinding.pryを叩くとそれ以降ずっとアプリケーションの挙動が10倍遅くなるという問題がありました。 これが上記の変更により改善されたので、 Railsアプリやgemのデバッグにbyebugやpry-byebugを利用している方はそれらのbundle updateをおすすめします。 bi
通信系のデバッグには Charles が便利 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Charles を使うと PC 上に HTTP プロキシを立てて端末の通信をキャプチャし、リクエストやレスポンスの内容を覗いたり書き換えることが出来る。類似のソフトウェアとして Wireshark や Fiddler, Paros がある。 アプリの開発をしていてよくあるのは、APIがスタブで固定値しか返してくれない、異常系エラーのデバッグがやりづらい、という場面だが、Charles なら通信を好きに値を書き換えられるのでこれらに簡単に対処することができる。 Charles は Java アプリなので OS X だけでなく W
iOSデバッグ時に有用なメソッド - Qiita
(lldb) po [self _ivarDescription] <DetailViewController: 0x7fc94b637db0>: in DetailViewController: in UIViewController: _view (UIView*): <UIView: 0x7fc94b63c360> _tabBarItem (UITabBarItem*): nil _navigationItem (UINavigationItem*): <UINavigationItem: 0x7fc94b63ae20> _toolbarItems (NSArray*): nil _title (NSString*): nil _nibName (NSString*): @"jAO-Jw-mTY-view-IBP-J8-Ec0"<__NSCFString: 0x7fc94b6380e
Swift での #ifdef DEBUG のやり方 - Qiita
試しに #if DEBUG ... と書いてみましたが期待した動作をしません。 Apple のドキュメントをよく読むと以下のように書いてあります。 Swift code and Objective-C code are conditionally compiled in different ways. Swift code can be conditionally compiled based on the evaluation of build configurations. Build configurations include the literal true and false values, command line flags, and the platform-testing functions listed in the table below. You can spec
AngularJSのパフォーマンス改善入門 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これまでAngularJSでアプリを作ってきた中で、いくつかパフォーマンスの問題に遭遇しました。 それらの問題は、AngularJSの仕組みを十分に理解できていないために、よくないコードを書いてしまって発生しているものでした。 というわけで、AngularJSの内部構造を解説しつつ、パフォーマンスを改善するコードの書き方を紹介したいと思います。 計測できないものは改善できない パフォーマンス問題に取り組むには、ソースコード修正の前後でパフォーマンスを計測し、改善の効果を計測することが重要になります。 というわけでまずはツールの紹介です。
iOSのデバッグを極める - ワザノバ | wazanova
http://www.objc.io/issue-19/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 objc.ioはベルリンのメンバを中心に、月替りでiOS関連技術の特定のテーマに絞って発信しているブログ。もう既に知名度はかなり高いかと思いますが、毎月ものすごく力の入った特集ゆえに、その分ボリュームも相当で、読むのも大変というか、時間がないから読めてない人もいるかと。今月は#19としてデバッグの話題です。 Peter Steinbergerの「デバッグ : ケーススタディ」では、UIKit上のバグをLLDBで対処した話を紹介。 「デバッガーでのダンス - LLDBのワルツ」において、Ari GrantはLLDBの使い方を詳説してくれています。 「DTrace」はiOSシミュレータでしかまだ利用で
エンジニア・光成 滋生の「バグを突き止める技術」 | サイボウズ式
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第18回（これまでの連載一覧）。サイボウズ・ラボの光成 滋生さんにお話を伺うシリーズ（1）です。 本連載は、「WEB+DB PRESS Vol.80」（2014年4月24日発売）に掲載された「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部） 文：西尾 泰和 イラスト：歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第2弾は、サイボウズ・ラボのエンジニアとして、楕円曲線などの難しい数学を使った暗号の論文を読んで実装したり、サイボウズが遭遇した問題の原因を掘り下げていって最終的にLinuxのバグを修正したり、と幅広い活動をされている光成滋生さんです。 光成さんが、どういうプロセスで問題の原因を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
211120 他人の書いたPythonスクリプトをステップ実行で理解する
poから始めるlldb
GitHub - deivid-rodriguez/pry-byebug: Step-by-step debugging and stack navigation in Pry
第18回yidevで「まだNSLogで消耗しているの？」を発表してきました
iPhone(実機)の通信ログ(パケットのキャプチャ)を簡単に取得する方法 - Qiita
【デバッグの友】現在位置のEmacs Lisp関数をトレースする超簡単な方法！
