We tried to load scripts but something went wrong. Please make sure that your network settings allow you to download scripts from the following domain: https://id-frontend.prod-east.frontend.public.atl-paas.net
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか?プロセッサーがどのくらい忙しいか?違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
What is EditorConfig? EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they
OpenAPIとは、API、すなわちアプリケーションを作ることができるプラットフォームを、無償で自由に使うことができるサービスです。 開発者は、今回ニワンゴが提供するOpenAPIを使用することで、携帯電話のメール機能を使ったアプリケーションを作成することができます。 今回公開するOpenAPIを利用して開発したアプリケーションをサーバーに設置することで、エンドユーザーからの問い合わせに対して開発者(デベロッパー)が回答することができます。 具体的には、エンドユーザーの送ってきたコマンド付きのメールが、ニワンゴを介して、そのコマンドに対応する開発者のサーバーに問い合わせをします。 開発者サーバーからの返答は、再びニワンゴを介してメールの形に整形されて、エンドユーザーに届けられます。 メールを送ってから帰ってくるまでの手順を説明するとこうなります。 m@open.niwango.jp にコ
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。(ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない) アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現(オブジェクトにメッセージ送信)するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ(前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている)による、ユーザー定義型(抽象データ型)を SIMULA67 にあった「クラス」という言語機能を使って実現(カプセル化、継承、多態性)するアイデアに基づく「抽
WritingTestableCode - テストできるコードの書きかた 目次 この文書について まずいのその1: コンストラクタがやりすぎ まずいのその2: 深い仲になってしまっている まずいのその3: 脆いグローバルな状態とかシングルトンとか まずいのその4: クラスがやりすぎ テストできるコードの書きかた この文書について "Guide: Writing Testable Code" の日本語訳です http://misko.hevery.com/code-reviewers-guide/ 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... TODO: 各 Flaw のリンク先も訳す Misko Hevery コードをベストな状態に保つために、 我々は Google でソフトウェアエンジニアに以下のようなをガイドを定期的に送っていた。このガイドを共有できてうれしいね。 この
昨日のNative ClientはX86バイナリをブラウザで動作させるという素晴らしいソフトウェアだった。言わばデスクトップをWebに移行させる代物だ。対する技術としてはAdobe AIRやSilverlightなどがあるだろう。だがプラグイン必須という点が難点になる。 Windows向けアプリケーションも開発できる そして逆にWebのリソースをデスクトップに持ってきてしまおうというのがTitaniumだ。Webからデスクトップへとその道はつながっている。 TitaniumはApacheライセンスの下に公開されているオープンソース・ソフトウェアで、Rubyを使ってデスクトップアプリケーションが開発できてしまう。 Titaniumが手掛けるものはAdobe AIRに近いと言える。ただしRubyをベースにしているのでWebプログラマにとってはさらに開発しやすいかも知れない。モバイル対応もうたっ
※ 画面は一部公式サイトより ソースコードのレビューシステムも2008年になって急激に注目を集め、各種オープンソース・ソフトウェアが登場したジャンルだ。Java、Python、Perl、Rubyと各種言語向けに登場しているが、思ってみればこの言語は初だったかも知れない。 ソースコードをコミット前にレビューする そう、Webベースのプログラミング言語と言えばのPHPだ。PHPで開発を行う方であれば、やはり使い慣れたこちらが使いやすいだろう。 今回紹介するオープンソース・ソフトウェアはGroogle、PHPで作られたソースコードレビューシステムだ。 PHPは開発者の技量によって、ソースコードの見やすさや書き方が大幅に異なる言語だ。その補正を行うためにもレビューシステムの導入は重要と言える。そしてGroogleを使えばその使い慣れたPHPを使ってWebベースのソースコードレビューが可能になる。
受託開発におけるプロジェクト管理というと、開発会社側で管理すべき項目に対して有効なものが多い。そのため、開発案件が終わるとあまりメンテナンスはされなくなる。さらに開発プロセスの管理に限るので、実際の納品物とは乖離することがある。 WebサイトもWindowsアプリケーションプロトタイプも作成できる だがそれでは勿体ない。開発のはじまりから終了、そしてその先まで全体を見られる管理ツールがあると便利だ。そう考えたことのある方はSerena Prototype Composerを導入しよう。 Serena Prototype ComposerはWindows向けのフリーウェアで、プロジェクト管理のみならずプロトタイプやワークフローの管理まで行えるプロジェクト管理ソフトウェアだ。 Serena Prototype Composerは特にWebシステムに限ったものではないようだ。プロトタイプ作成では
SubversionとTracでファイル管理の“迷宮”から脱出:ユカイ、ツーカイ、カイハツ環境!(2)(1/4 ページ) プロジェクトで修正/仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理(ファイル管理)を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その1(かもしれない)」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD(Create/Read/Update/Delete)のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに(HTTP Requestに返事をする前に)データベースに変更を加え、Readの際にも(キャッシュを使う・使わないを別にして)データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く