ディスク使用量をFlameGraphで可視化する - ( ꒪⌓꒪) ゆるよろ日記
こんにちわ。しいたけです。今日はディスク使用量をFlameGraphにするツールの話です。 FlameGraphについては、 Flame Graphs や GolangでFlame Graphを描く | SOTA を読んでもらうのが手っ取り早いのですが、ようはプロファイル結果を可視化する方法です。縦軸が呼び出しの階層に、横軸がサンプル数や実行時間などに対応しており、どの関数が支配的かを直感的に見ることができる優れたグラフですよ。 で、このFlameGraph、別にプロファイル結果だけではなく、ツリー構造で各ノードが量を持つ場合に、枝毎の累積量を可視化するのに利用できます。プロファイル以外に、ツリー構造でノードが量を持つ例として、ディレクトリ階層毎のディスク使用量が考えられます。 というわけで、指定ディレクトリ以下のディスク使用量をFlameGraph化するツールを書きました。 GitHub
Railsの太ったモデルをダイエットさせる方法について - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はよくリファクタリングをしています。 今回は、最近僕がリファクタリングしている内容についてまとめようと思います。 メドピアではFat Model/Controllerを避けるために、rubocopの設定を利用しクラスの行数が300行以下になるよう制限しています*1。最近300行を超えるモデルが出てきたので、一部の処理を別のクラスに切り出し始めました。 このとき、Railsが提供している機能であるconcernsを利用すると楽に行数を減らすことができますが、それだとrubocopの指摘を回避できるという意味しかないので、なるべく委譲(composition)を利用して処理を別クラスに移していっています*2。 複数モデルにまたがる処理を切り出す Railsアプリケーションを書いていると、複数のモデルを一度
10ヶ月かけて完成した15000個の電子パーツで作った脳 - MIKINOTE
去年の末から作り始めた電子パーツの脳がやっとのことで完成しました。 タイトルは「接続する脳」としました。 実は先月の中旬くらいには完成していたんだけど、作品の写真撮影やら作品タイトルなら何やらを悩んでいたらあっという間に２〜３週間くらい経っていました。 最終的には制作期間は約10ヶ月、パーツの入っていた空き箱の数を数えてみたら使用したパーツ数はちょうど15000個ほど使ったということがわかりました。 いや〜長かった！！ここまで長い期間、1つの作品を作り続けたのは人生で初めてだったんじゃないかな。使用したパーツ数に関しても電子パーツハンダ付け系の作品の中では最も多い作品となりました。ちなみに1個のパーツにつき、最低でも2箇所はハンダ付けしなくちゃならないので、少なくとも30000回はハンダ付けしたということになります。 前回の作品制作記事で「あと一ヶ月くらいで完成できたらいいな」みたいなこと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
