Debugging a Memory Leak on HerokuWritten by: Richard Schneeman This is one of the most frequent questions I'm asked by Heroku Ruby customers: "How do I debug a memory leak?" Memory is important. If you don't have enough of it, you'll end up using swap memory and really slowing down your site. So what do you do when you think you've got a memory leak? What you are most likely seeing is the normal m
この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり:私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ
2012年09月19日10:58 Ruby RubyistならデバッグにはPryのbinding.pryがおすすめ Pry("ぷらぁい" と発音します)はirbをもっと便利にしたものでRubyistならぜひ使うべきなgemです。しかもインストールはたったこれだけと非常に簡単です。 # pry-docは無くてもまぁいいですが、いろいろ調べられるので入れとくと良いでしょう。 gem install pry pry-doc Pryを使うとどういうことが出来るのかについてはこちらの動画をご覧ください。 #280 Pry with Rails - RailsCasts さて、この動画の中でも説明されていますがbinding.pryと書くことで任意の場所にブレイクポイントを設置することができます。ブレイクポイントを設定しておけば、処理を実行した際にそこで止まって自動的にPryコンソールが立ち上がるため
弊社で(総力を上げて)メンテナンスしているtappというライブラリがあるのですが、思ったより認知度が低いようなのでここで紹介させていただきます。 まとめ tappは、従来のPrint Debugの問題点を解決する画期的なライブラリです。 次のような経験がある方は、いますぐGemfileにtappを追加することをお勧めします。 メソッドチェーンの間のオブジェクトの状態を見るためだけに一時変数を使ったことがある ppやp、putsを消し忘れてリポジトリにコミットしてしまった tappとは tappは、Print Debugを簡単に行うためのRubyライブラリです。 リポジトリはhttps://github.com/esminc/tappになります。 tappの歴史 tappの作者である@ursmは、2008〜2009年頃に社内向けのモンキーパッチとしてtappを生みだし、Rails勉強会41.
$200K 1 10th birthday 4 abusive ads 1 abusive notifications 2 accessibility 3 ad blockers 1 ad blocking 2 advanced capabilities 1 android 2 anti abuse 1 anti-deception 1 background periodic sync 1 badging 1 benchmarks 1 beta 83 better ads standards 1 billing 1 birthday 4 blink 2 browser 2 browser interoperability 1 bundles 1 capabilities 6 capable web 1 cds 1 cds18 2 cds2018 1 chrome 35 chrome 81
はじめに KCachegrind は、プログラムのプロファイル結果をグラフィカルに分かり易く表示してくれるオープンソースのソフトウェアです。 KCachegrindを活用すれば、性能上のボトルネックや、メモリリーク箇所の特定など、機能テストでは分からないような問題の検出が容易になり、ソースコードの改善に役立てることが出来ます。 この記事では、KCachegrindの紹介から始まり、最終的にはプロファイル結果を解析してプログラムの問題点(バグ・ボトルネック)を見つけるまで、について3回に分けて説明していきます。 以下の構成を予定しています。 今回(準備編)はKCachegrindの概要 次回(入門編)はKCachegrindの使い方 最後(実践編)はKCachegrindを使ってプログラムの問題点を見つける方法 必要なソフトウェア KCachegrind は他のツールと組み合わせることが前提
Railsでの開発をしているとき、ブラウザは何を使ってますか? 私はFirebugが使いたいのでFirefoxがメインでしたが、最近はGoogleChromeが多いです。 GoogleChromeにもディベロッパーツールというのがあり、ブラウザとサーバ間の通信内容や各ファイルのロードに掛かった時間などを見ることができます。 どちらの開発者向けツールでも、Javascriptのソースにブレイクポイントを設置し、その時の変数の中身を見ることなどもできます。これらのツールがないと仕事にならないくらいです。 では、サーバ側は? ということで、Rails3でかつRuby1.9.xの場合でのデバッグ方法についてです。 では、さっそく 準備する手順 1、Gemfileに追記 gem "ruby-debug19" 2、「bundle install」を行う 3、ソースの止めたい場所に「debugger」と
Goal Jenkins で達成出来る事は沢山ありますが、この記事では複雑な設定を伴わないで実現可能な、apk の自動生成、テストの自動実行までを対象とします。 またビルドツールも Ant, Maven, Gradle, Ivy 等がありますが、標準でもサポートされており、最小構成な Ant を選択しています。 ※ Jenkins でどこまで自動化したいかによりますが、様々なタスクを実行しようと思うと豊富な Plugin を持つ Maven が便利ではあるので、それはまた別途。 ant でビルド出来る様にする Jenkins で CI するには、まずはプロジェクトをコマンドでビルド出来る必要があります。 Eclipse で作成したプロジェクトでは、そのままではビルドする事が出来ない為、後から Android SDK に含まれるコマンドを利用して Ant 用の build.xml を生成しま
昨年の9月以来、約10ヶ月ぶりにGAE Pythonに戻ってきた。 Antで、GAE Python用のウェブサーバーを起動させたりしていたが、心機一転環境を作り直したら、PyDev が、その辺のところに対応しているではないですか。 以下、手順。 Pythonのインストール、Eclipse 3.4 のインストール、Pydevのインストールは済ませて、以下の手順で、GAE用のプロジェクトを作成できる。 1. File – New – Other から、Pydev Google App Engine Projectを選択 2. プロジェクト名等を設定して Next 3. ここで、Google App Engine SDK for Python のインストールパスを指定する 4. アプリケーションのID(おそらくGAEに登録したAppのIDだろう)と、テンプレートを選択(Hello Webapp
googleのAndroid開発者向け ブログに「Memory Analysis for Android Applications」という記事があったため、自分のために訳しました。参考になれば幸いです。本エントリを見るうえで、eclipse の基本的な使い方を理解している必要があります。 Androidアプリのメモリ解析手法 Dalvikランタイムは、ガベージコレクトしてくれるかもしれませんが、それはメモリ管理を行わなくてもよいというわけではありません。モバイル端末上でのメモリ利用状況は特に注意を払わなければなりません。本投稿では、開発するアプリのメモリ利用状況の把握を支援する Android SDK で提供しているメモリプロファイリングツール群のいくつかを紹介させて頂きます。 メモリ利用時の問題はいくつか明らかになっています。例えば、もしあなたのアプリがユーザの画面タッチ操作のたびにメモ
どうもこんにちは、os0xです。 実は(Twitterに書いただけで)ブログに書いてなかったのですが、3ヶ月ほど前からクックパッドで働いています*1。なんかもう今更ですよね、すみません。 さてさて、クックパッドですが、つい一昨日までprototype.jsを使っていました。で、昨日jQueryへの移行をリリースしたところだったりします。 というわけで、その辺の話を少し書いてみたいと思います。 そもそも、なんでjQueryに移行するのか まあ、prototype.jsとjQueryどちらを使うかと問われたら、大抵の人はjQueryと答えますよね。確かにjQueryの使いやすさは魅力的です。使いやすいということは、みんなでjQueryを使ってサービスを作ることができます。特定の誰かに依存してボトルネックになったりすることがないなら、それは素晴らしいですね。 しかし、ライブラリを変えるのは簡単な
Note that memory usage on modern operating systems like Linux is an extremely complicated and difficult to understand area. In fact the chances of you actually correctly interpreting whatever numbers you get is extremely low. (Pretty much every time I look at memory usage numbers with other engineers, there is always a long discussion about what they actually mean that only results in a vague conc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く