達人プログラマーに学ぶ どこでも自動化 | Act as Professional
達人プログラマーはどうするのか？p.240 第8章 達人のプロジェクトより 我々よりもコンピュータの方がうまくやってのけるような繰り返しや俗っぽいことは、すべてコンピュータに任せてしまいましょう。我々にはもっと重要で難しい仕事が待ち構えているのですから。 HIROCASTERの経験から cobblerをつかって、OSのインストールは自動化 puppetやChefをつかって、OSの設定やアプリケーションの導入と設定を自動化 capistranoをつかって、デプロイ作業を自動化 Nagiosなどの監視システムやCactiなどのモニタリングシステムへの追加も自動化こんなことはさっさとやってしまおう。物理サーバが到着したら数分で本番環境へ投入できるように。 Amazon EC2を使えば、物理サーバが到着するのも待たなくてすむ。 達人プログラマーから想像できる開発中の自動化は… シェルを書いてしまっ
拡張性に関する悪習慣
例えば、キーと値の組み合わせを管理する一般的な解決策はデータベースを用いる方法です。この方法が選択されるのは通常その組織ないしは開発者がデータベースに精通していることと多くの問題に対して同じ解決策を選択するからです。ところがデータベースの機能(参照整合性、ロッキング、結合やスキーマ)がボトルネックや拡張の阻害要因となった途端、問題が発生します。データベースに基づく解決策を拡張することは、それ以外の技術を利用した場合に比べて一般的にコストが高いからです。データベースに格納したキーと値に対するアクセスが頻繁になるに連れ、その優れた機能を利用しないことにより、データベースの並列処理モデルがパフォーマンスを落とす要因となるのです。伝統的なリレーショナル・データベースに対してCouchDB、SimpleDBやBigTableといった多くの代替手段でこれらの欠点を解決することができます。 別の一般的な
より良いベストプラクティス
組織ではよくベストプラクティスがプログラムや品質の改善対策の一環として導入されます。それらは”クックブック”やチートシートから本格的で監査や認定に対しても万全なコンサルタント主導の方法論まで様々です。 この記事ではベストプラクティスを単純に適用するやり方に疑問を投げかけるためドレフュス学習モデルを紹介します。そして単純なベストプラクティス適用が役立たないだけでなく、一番力のある人たちにとって重い悪影響を与えることをお見せします。 ベストプラクティスを導入する理由 ビジネスに大きな影響のあるプログラムを作る人たちは常に、ベストプラクティスを組織に広げるよう大々的に取り上げるもっともな理由を持っています。 ベストプラクティスは一貫性を保証する。 私たちは○○を導入しようとしている。みんなには同じ方法で仕事をしてもらいたい。こちらから何らかの方向性を提示しないで誰かを見捨てる気はないし、他の方法
Practices of an Agile Developer -- よいプログラマの習慣：An Agile Way：オルタナティブ・ブログ
「アジャイルプラクティス」、読んだ。よかった！ もしあなたが、開発者としてアジャイルでありたい、と思っているのであれば、必ず読んで欲しい。「アジャイル」は方法論ではないし、プロセスでもない。あなたが明日から始められる「習慣」と「心構え」なんだ。 ■ アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 http://www.amazon.co.jp/dp/4274066940/xpjp-22 この本は、アジャイル開発、の本ではない。アジャイル開発の手順を解説なんてしていない。そうではなく、「あなた」が開発者としてアジャイルでありたいならば、こういう習慣を身に着けよう、と言っている。あなたは「気持ちよく」納得した感情で開発をしたいだろう？誇りをもって、自分自身とチームが書くコードが高品質である、と言いたいだろう？顧客に価値を提供している、と言いたいだろう？ たとえば、本書では、あるプ
できる開発者になるための7つの習慣 - builder by ZDNet Japan
Sun Microsystems Asia-PacificのスタッフエンジニアであるLee Chuk Munn氏によると、アプリケーションを書くことは本を執筆することに似ているという。 「私はさまざまなプログラミング言語を学んできた。しかし、どんな言語を使ってプログラムを書いているかは問題ではない。書く物語がよいものでなければいけないのだ」Lee氏はZDNet Asiaの電話インタビューでこう答える。ソフトウェアのプログラミングでは27年の経験を持つベテランのLee氏はSunのソフトウェア部門で働いており、社内の開発者やJavaやSolarisを使用している個人ソフトウェア開発者のネットワークを指導している。 彼はこう続ける。「プログラミングは解決策の一つの表現にすぎない。プログラミングの多くを構成するのは、問題を理解して認識し、助けを得ることだ。この考え方はすべてのプログラミング言語にお
EfficientJavaScript - Dev.Opera - 効率的な JavaScript
EfficientJavaScript - Dev.Opera - 効率的な JavaScript 目次 この文書について 効率的な JavaScript ECMAScript eval や Function のコンストラクタを使うのはやめよう eval を書き換えよう 関数を使いたいなら function を使おう with を使うのはやめよう 性能を決める関数で try-catch-finally を使うのはやめよう eval と with は隔離しよう グローバル変数を使うのはやめよう 暗黙のオブジェクト変換に気をつけよう 性能を決める関数で for-in を使うのはやめよう 文字列は累積スタイルで使おう プリミティブの操作は関数呼び出しより速い setTimeout() や setInterval() には文字列でなく関数を渡そう DOM 再描画と再フロー 再フローの回数をでき
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふりかえりについてのふりかえり
ペアプログラミングは大衆向けでない？
ペアプログラミングの1ドルの価値
ペア・プログラミング vs. コード・レビュー
Brain Marick氏「アジャイルマニフェストに足りないもの」
Nokiaテストの価値は何か？
ルールを破ってもいいのはいつか？
IBM Developer
IBM Developer
チーム専用の部屋は、より生産性の高いチームを生み出すか？