コンテンツへスキップ 登録は無効化されました。
1. ベンチマーカー プロファイルすると、プロファイル自体に時間がかかるので正しく速度が測れない。そのためベンチマーカーも使うと良い。 ただし、ベンチマーカーはどこが遅いか等の解決の糸口は教えてくれない。 benchmark-ips 2. プロファイラ 実際に速度のボトルネックを見つける際に使う。 stackprof どのメソッドに多くの時間を費やしているかがわかる これを入れても速度にさほど影響がない rblineprof 行ごとにかかっている時間を出してくれる peek-rblineprofを使うとブラウザで結果が見れる ただしプロファイリングに結構時間がかかる (3. NewRelic) 実際、これらのことを手元でやらなくても、特にstackprof的なことや、どこのページやどのSQLクエリが特に遅いかなどは、 New Relic がやってくれます。お金を払うと結構詳細な部分も見れま
一次ソースはこちら→ https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md そのうち誰かが訳してくれると信じています 前提 この記事では、Goで確保されたメモリへのポインタをGoポインタとする1 この記事を書いている時点では、Go1.6はbeta2のため、まだ変わるかもしれない Goで確保されたメモリはGCされたり、将来的には自動で移動するようになるかもしれない2 C側で確保されたメモリはGCされない。将来的な自動移動も行われない Go1.6からどうなるか Goポインタをcgoの関数へ引数として渡すと、そのcgoの関数から返ってくるまでそのポインタが指すメモリは保護3されGCされたり移動したりしなくなる そのため、下記の点を注意する必要があります cgoの関数の引数経由以外の方法でGoポインタ
By Zlatko Unger ウェブサービスに登録したアカウントを守るために、自動生成パスワードや2段階認証を使うといった方法を用いることが多いものですが、時には思いもよらぬところが抜け穴になってしまうこともあるようです。Amazonのサービスを利用していた「Eric」というユーザーは、自身のアカウント情報がAmazonの問い合わせ窓口であるカスタマーサービスを経由して流出していたことを突き止め、どれだけログイン情報のセキュリティを高めても、効果がない場合もあることを明らかにしています。 Amazon’s customer service backdoor — Hacker Daily — Medium https://medium.com/@espringe/amazon-s-customer-service-backdoor-be375b3428c4 ソフトウェアエンジニアのEric
Turnip, Cucumber, RSpec feature などを使った end-to-end テスト のテストデータをどう作るかについて、今までの経験を書いてみます。 RSpecなどを使ったモデルのテストであれば、テストデータは factory_girl 等を使い、テストに必要なデータを it, describe単位でテストで作成する事が多いと思います。 しかし、end-to-endテストでは人がそのアプリを使う手順、シナリオに沿ってのテストにり、モデルのテストのように個々のテストで個別のデータを必要になることはあまりなく、いくつかのデータを作っておけば済みます。また、モデルのテストでは必要になるモデル(テーブル)は少数ですがend-to-endテストではほとんどのモデル(テーブル)にデータが必要になります。 そこで、今まで作ったアプリのend-to-endテスト用のデータをどのよう
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
4年近く前の2012年に僕が考えたChrome拡張機能を作るときのデザインパターンというエントリを書きました。最近参加したイベントで「よういちろうさんの拡張機能の記事見て作ってみました〜」と声をかけてくれた人がいて嬉しかったのですが、2012年のそのエントリは、すでに内容が古くなってしまっています。最近の状況を踏まえて、内容を新しくした「2016年度版」を書いてみようと思います。 変更しようと思った点は、以下です。 prototype.jsは使わず、ECMAScript 2015で書く。 Background Page(常駐型)ではなく、Event Page(非常駐型)にする。 そもそも最初のコードセットは自分で書かない。 本文やコード的には、2012年度版をコピペしています。 (この投稿の内容は、自分のブログエントリと同じです。) 前にいくつかのChrome拡張機能を作っていて、すでに数
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト(単体テスト)の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな?」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか?もしあったら記事にはります。」 僕のコメント「書いていません!」 僕のコメント「書きました!」 僕の主張 本記事は僕の実験結果(経過報告)であり、
本ブログポストは、マイクロソフトの意見ではなく、私個人の意見であることをお断りしておきます。 DevOps 普及活動の一環として、DevOps ハッカソンというイベントを実施しています。DevOps のプラクティスの一つとしてAutomated Testing (自動化されたテスト) があります。 それに関して複数の参加者の皆さんがこのようなことを言っていました。 「自動テストを書くのは好きではないです。何故かというと、自動化されたユニットテストを書いたら、同じ内容のエクセル方眼紙の仕様書を書かないといけないので、二重に書くのは無駄だし大変だと思うんです。」 はっきり言ってしまうと、このケースの単体テスト仕様書は完全なる無駄であると断言できます。 このポストではその理由をお話ししたいと思います。 1. 単体テストのイメージの違い この問題が起きている背景には、「単体テスト」というものがCO
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 色々な案件でディレクターをやっていくと、色々なタイプのエンジニアさんに出会い、一緒に仕事していくことになる。 エンジニアがどういったタイプなのか把握して動くことで、自分に合う合わない以上にグッと仕事がしやすくなったりしたので、そのメモ。 そもそもこのタイプ分類について コミュニケーションの難易度を独断と偏見で★(易)~★★★(難)までランク付けて、それぞれの特徴とその対処法……っと言うとアレだがつまり、より気持ちよくより力を発揮してもらえるようにいかに工夫するか?というところをまとめた。 ★★★は強いが扱いの難しい上級者向けキャラみたい
Broken benchmarks, misleading metrics, and terrible tools. This talk will help you navigate the treacherous waters of Linux performance tools, touring common problems with system tools, metrics, statistics, visualizations, measurement overhead, and benchmarks. You might discover that tools you have been using for years, are in fact, misleading, dangerous, or broken. The speaker, Brendan Gregg, has
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く