WritingTestableCode - テストできるコードの書きかた 目次 この文書について まずいのその1: コンストラクタがやりすぎ まずいのその2: 深い仲になってしまっている まずいのその3: 脆いグローバルな状態とかシングルトンとか まずいのその4: クラスがやりすぎ テストできるコードの書きかた この文書について "Guide: Writing Testable Code" の日本語訳です http://misko.hevery.com/code-reviewers-guide/ 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... TODO: 各 Flaw のリンク先も訳す Misko Hevery コードをベストな状態に保つために、 我々は Google でソフトウェアエンジニアに以下のようなをガイドを定期的に送っていた。このガイドを共有できてうれしいね。 この

雑記最近プログラムが簡単だ、という話が賑やかでした。 それには初心者の僕も同意。プログラムは本当に簡単だと思う。文法そのものは一週間あれば十分覚えられるし、手広くやらなければ数日で十分です。これは誇張でも何でもなくて、例えば数学や英語、論理的思考や集中力の低さに定評があった僕でも、中学生の頃に一週間もしないでＨＳＰという言語の基本的なところは覚えました。 オブジェクト指向とかに手を出せば、確かに難しくなる。でも文法だけの理解なら時間は掛からないし、オブジェクト指向が理解できていなくても最低限のプログラムなら問題なく組める。 覚えなきゃいけないことは少ないし、よく使うからすぐに覚えられる。例えば条件分岐なんかで考えてみると、 if(条件式) { 条件式が成立したときの処理 } else { 条件式が不成立のときの処理 } これだけ。どうしても覚えられなくても、構文を神にメモってパソコンの横に

yak shaving で人生の問題の80%が説明できる問題 つい最近、 yak shaving （ヤクの毛を刈る）、という言葉を知りました (原典)。これは「一見無関係に見えるけど、真の問題を解くのに必要な問題を解くのに必要な（これが何段階も続く）問題を解くのに必要な活動」という意味の言葉です。 yak shaving は、ようするに「ある問題を解こうと思ったら別の問題が出てきて、それを解こうと思ったらさらに別の問題が出てきて…」ということが延々と続く状況を表しています。ちなみに、ヤクとは毛が長い、牛の一種です。 yak shaving は、以前に覚えた bikeshed と同じくらい便利そうな表現です。というもの、プログラムを書いていると yak shaving 的な状況がすぐに発生するためです。 たとえば、「Amazon のほしい物リストを CSV 形式に変換して Excel で読み

僕は、約2年間に渡って某企業の業務アプリケーションを作っている(出向)んだけども、そこでの経験を元に少し書いてみようと思う。 自分へ(?)向けたメモ。 0.僕を知らない人が読んでも大丈夫なように、前書き 僕はPHPerとしてS2DaoをJavaからPHPに移植しS2Dao.PHP5っていうしがないものを作っています。 これはApache Licenseで公開されています。 また、僕はOSSプログラマとしては何もすごいことやってないぺーぺーです。 今回、僕が今いる現場で作らさせてもらっているのは、Javaで書かれたWebフレームワーク。 フレームワークと言っても、それ自身を一から作っているのではんく、既存のフレームワーク(Strutsとかそういうの)を拡張した、業務フレームワークといったもの（さすがにこっちは一から作りましたが）。 Webフレームワークが持つ豊富な機能を制限したり、

もしもこの世から「残業」が完全になくなったら ３年ぐらい前に読んだ本を思い出した。 １９８０−９０年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」（１９８５年労働基準法研究会報告）とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」（１９９２年同報告）と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま２１世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人

もしもこの世から「残業」が完全になくなったら ３年ぐらい前に読んだ本を思い出した。 １９８０−９０年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」（１９８５年労働基準法研究会報告）とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」（１９９２年同報告）と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま２１世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人

あなたがプログラミングの初心者なら、友人知人が使っている言語にするといい 2008-02-05 初めてのPC購入(OS選択)相談を持ちかけられたときにこう言ったことがある。 「まわりの人が使っているOSにするといいよ。Windowsの人が多いならWindows、Macが多いならMacね」 多分同じ事を言ったことがある人も多いんじゃないかな。 いい悪いももちろんあるけど、そのジャンルにおける本当の初心者にとっては助けてくれる人の存在がかなり大事だと思う。プログラミングもこれと同じ。というか、それなりにハードルがある技術全てに言えるんじゃないか。 個人的に、何かを薦めるという行為は、本人的にちょっと責任を感じる行為だと思う。だから、もし僕が親密度の高い人から技術選択の相談を受けたら、良し悪しも含めた上で僕がなるべくサポートできる言語やフレームワークを薦める。でも、その人の周りに他の言語やフレー

趣味でやっている人のことは、まあ、いいとして（踏み台にされる可能性はあるけど）、仕事でPHPを使うときの注意を書いておこう。 コーディング規約を守る。組織にコーディング規約がないなら、Zend Framework PHP標準コーディング規約 [zend.com]を使う。オレ流コーディングスタイルは禁止。 内部コードにはEUC-JPかUTF-8を使う。入出力もできるだけShift JISを避ける。Shift JISを使う場合には2byte目に0x5Cを含む文字の動作を忘れずに確認する。 開発環境の警告レベルをE_STRICTにする。本番環境ではdisplay_errorsをオフにする。 register_globals、magic_quotesはオフにする。 type hintingを積極的に使う。 スコープの長い配列をクラスでラップする。 プレゼンテーションとロジックを分割すること。プレゼ

install | tutorial | forum This site is about Arc, a new dialect of Lisp. Arc is designed for exploratory programming: the kind where you decide what to write by writing it. A good medium for exploratory programming is one that makes programs brief and malleable, so that's what we've aimed for. This is a medium for sketching software. Arc is unfinished. It's missing things you'd need to solve some

当日の講演資料と動画を公開です。 動画はニコニコ動画を利用して配信しています。ニコニコ動画のアカウントをお持ちでない方でも，gihyo.jp上で動画を再生できます（コメントの書き込みはできません）。 動画の最後でニコスクリプトを使ったアンケートを行っていますので，ニコニコ動画のアカウントをお持ちの方はご協力いただければ幸いです。動画をクリックすることでニコニコ動画の該当ページへアクセスすることができます（ニコニコ動画のマイリストはこちら）。 今回の動画公開にあたって，gihyo.jp用に新たなニコニコ動画プレーヤーを作っていただきました。この場を借りてニコニコ動画の方にお礼を申し上げます。 JavaScript Tips & Technique IT戦士amachangが最近のJavaScriptのテクニックやTipsについてご紹介します。

オブジェクト指向設計の基本 オブジェクト指向プログラミングの特徴 伝統的な手続き指向プログラミングでは、実行する一連のステップ､すなわちアルゴリズムを記述するものをプログラムと考えます。オブジェクト指向プログラミングでは、プログラムはオブジェクトの相互作用システムをして記述します。一時的に必要となる領域、すなわちテンポラリ・バッファはプログラムのいたるところで用いられます。C++を厳格な手続き型言語として使うこともできますが、オブジェクト指向のアプローチをとることでC++の長所を生かすことができます。 オブジェクト指向プログラミングは、キーとなる概念をいくつか持っています。 ■ 抽象化の概念 最も基本的な概念で、大規模なプログラムをより単純に記述できるようにします。 ■ カプセル化の概念 プログラムの変更とメンテナンスを簡単にします。 ■ クラス階層の概念 プログラムを簡単に拡張できるよう

HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,