How to Write Maintainable Code 日本語訳
以下の文章は、Bram Cohen による How to Write Maintainable Code の日本語訳である。 本翻訳文書については、福盛秀雄さんと竹中明夫さんから誤訳の訂正を頂きました。ありがとうございました。 ソフトウェア技術者は、自分が書くコードがどのようにあるべきか分からず悩んでいる。よく知られたエッセイ「悪い方がよい」（訳注：日本語訳）がその良い例である――どうして悪いほうがより良くなれるの？ やっぱり悪いほうが悪いんじゃないの？ さらにややこしいことに、「悪い方がよい」の話は、それが主張しようとしている内容とは正反対の議論の中で引き合いに出されることが多い。 問題は、みんながコードの「美しさ」を判断するのに非常に多様な、また往々にして相反する基準を採用していることだ。美的感覚よりも客観的な、コード品質に対する基準が明らかに必要である。 僕としては、メンテナンス性に
高度な JavaScript 技集
JavaScript で作って意味があるのかどうか分かりませんが、作ってみました。 応用編 入力したテキストをページ上に書き出し、個々の文字をドラッグ＆ドロップ で動かせるようにする ソースを読んでも中身が分からない HTML を作成する パスワードチェックの部屋 (パスワードは「開けごま」ですが、HTML のソースや JavaScript を解析しても、絶対にパスワードが分からない仕組みになっています。) バー ライブラリ編 こんなの JavaScript で作るかよってな代物です。 できてしまったものはしょうがないでしょう。 utf.js (UTF-8 <-> UTF16 変換) base64.js (Base64 encode/decode) md5.js (MD5) des.js (DES 暗号化/復号化) zlib.js (JavaScript による zlib 実装、zlib
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
Prototype.js を使った JavaScript OOP 講座 #01
社内の精鋭エンジニアを中心に定期的に勉強会をすることになった。んで、 JavaScript の講義は僕がやることになった。 資料を社内だけでとどめておくのはもったいないので、ここに公開していきます。社内の人も社外の人も読んでください。 講義の内容は基本的にソース嫁。ソースレビュー形式。 ※ターゲットは JavaScript は書いたことない、オブジェクト指向言語プログラマ。 Section 00 Prototype.js の前に JavaScript のオブジェクトの概要・・・ オブジェクトを作ってみる。 var object = {};オブジェクトにメソッドとかプロパティを追加してみる。 var object = { field: 'IT戦士', method: function() { alert('hello ' + this.field); } }; object.method()
ネットワークプログラミングの基礎知識
ネットワークプログラミングの基礎知識 ここでは IP アドレスやポート番号、クライアントとサーバの役割などを説明し、 perl・C言語・Java などでソケット (Socket) を使った HTTP クライアントや POP3 クライアント、簡単なサーバを作成してみます。 要はネットワークプログラミングをやってみよう、ということです。 このページのサンプルプログラムは、RFC などの規格に準拠した「正しい」プログラムではありません。 また、全体的にエラー処理が不十分です (今後改善する予定です)。 あくまでも概要を理解するためのサンプルととらえてください。 もし本気でしっかりとしたクライアントやサーバを書きたいなら、このページを読んだ上で、 さらに RFC を熟読し、そして wget・Apache・ftp コマンドなどのソースを参考にしてください。 このページに間違いを見付けたら、掲示板 で
システムコール概論
プロセス プロセスについて考える プロセスの選択的なｋｉｌｌコマンド・ｚａｐ システムコール 低レベル入出力 ファイル指定子 readとwrite 標準入出力と低レベル入出力 標準入出力と低レベル入出力---読みと書き 眠るシステムコール ｓｌｅｅｐ 標準入出力以外のファイルのオープンとクローズ ファイルの作成とオープン ファイルを作成する。 ｃｒｅａｔ システムコール ファイルのオープン---単純な形式 creat と open を使ったｃｏｐｙのプログラム ファイルのオープン・オプションフラグ 前回のmycpの問題 オプションフラグでのファイルのオープン --- 様々なオープン mycp2 --- オーバーライトチェックの試作品 mycp3 --- ＵＮＩＸの精神に反する親切なコピーツール オプションフラグの別の利用の仕方 Ｃ言語の復習 関数 function 制御 If-Else w
良い乱数・悪い乱数
Ｃ言語標準ライブラリの乱数rand( )は質に問題があり、禁止している学会もある。 他にも乱数には様々なアルゴリズムがあるが、多くのものが問題を持っている。 最も多くの人に使われている乱数であろう Visual Basic の Rnd の質は最低である。 そもそも乱数とは 乱数とは、本来サイコロを振って出る目から得られるような数を意味する。 このような乱数は予測不能なものである。 しかし、計算機を使って乱数を発生させた場合、 次に出る数は完全に決まっているので、予測不能とはいえない。 そこで、計算機で作り出される乱数を疑似乱数(PRNG)と呼び区別することがある。 ここでは、特にことわらない限り乱数とは疑似乱数のことを指すとする。 計算機でソフト的に乱数を発生させることの最大のメリットは、 再現性があることである。 初期状態が同じであれば、発生する乱数も全く同じものが得られる。 このことは
yohei-y:weblog: REST の日本語リソース
日本で REST がぜんぜん盛り上がっていないようなので、日本語で読める REST のリソースをまとめてみた。 東大市山氏による Roy Fielding の論文紹介。技術的な要素を理解したいけど RoyF のドク論を読むのは厳しい人にはお勧め。 http://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports/pdmwa 元論文はこれのようだ Principled Design of the Modern Web Architecture http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf 同氏による REST 版ショッピングカートの実装例。こちらも参考になる。 http://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports
デザインパターンFAQ
翻訳: デザインパターン・メーリングリスト有志 原文は Doug Lea<dl@cs.oswego.edu> によってメンテナンスされています。 原文の最終更新は2000年11月です。 この文書は通常の意味でのFAQではありません。 この文書には、 patterns-discussionメーリングリストで議論されてきたトピックの 非常に短いサマリーがQ&Aの形式で含まれています。 項目の取捨選択および内容には管理者の主観的な判断が入っています。 このFAQは不定期に更新されます。 パターンに関する情報は、 The Patterns Home Pageを参照してください。 そこにはオンライン上のパターンへのリンク、 パターンに関する論文、パターンを扱った書籍の説明、 カンファレンスの一覧、 そしてパターンに関連したメーリングリストが含まれています。 「パターン」という用語によい定義がないのは
いやなブログ: 配列操作の比較表: Ruby, Python, JavaScript, Perl, C++
配列操作の比較表: Ruby, Python, JavaScript, Perl, C++ プログラムを書いていると、他のプログラミング言語の記憶とごっちゃになって、「配列の後ろに要素を追加するのは push だっけ、 append だっけ」などと混乱することがあります。特に Ruby, Python, JavaScript はコードの書き方が似ているので、この問題が起きがちです。 そこで、備忘録として、 Ruby, Python, JavaScript, Perl, C++ の配列操作の比較表を作りました。一番慣れている Ruby を基準にしています。間違いなどがあったらご指摘いただけると助かります。他の言語のもあるといいなあ。 Ruby (Array) Python (list) JavaScript (Array) Perl (@) C++ (std::vector)
わたしが知らないスゴ本は、きっとあなたが読んでいる: 画面仕様書を「作らない」リスク
IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。 画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減る。これは帳票にも同じことが言える。 あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ！ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要
秋元@サイボウズラボ・プログラマー・ブログ: Yahoo! UI Library はすごいね
via O’Reilley Radar Yahoo! UI Library で、Yahoo! が実際に使っている Javascript のライブラリ集が公開されている。 Yahoo! のどこでこんなユーザインタフェースが使われてるんだろう? と思うぐらい、サンプルで見せられる UI パーツは豊富だ。それぞれの “Example” を見てまわるだけでもおなかいっぱいだ。 コアユーティリティ アニメーション クロスブラウザ対応の XMLHttpRequest ラッパ DOM 操作 ドラッグアンドドロップ イベントハンドリング UI コントロール部品 カレンダー スライダー ツリー ドラッグアンドドロップなんかは、ファンタジースポーツで使われているのを見たことがあるので知っていた。複数のリスト間でアイテムの移動や並べ替えを行うときには使えるパーツだろう。 日本語カレンダーなんかも、いい感じで再利
Standard Template Library プログラミング on the Web
1985年、AT&TのBjarne StroustrupがC++をこの世に送り出しました。その後C++は様々な拡張を繰り返しながら進化してきました。 1991年、ISOはC++の国際標準(standard C++)を定める作業を開始しました。標準C++の最終草案は1997年にISO C++標準化委員会に承認されました。 標準C++が規定するのは言語仕様だけなく、C++標準ライブラリも規格の中で明確に定められています。それまでC++のライブラリといえばiostreamぐらいのものでしたし、それもあくまで"事実上の標準"でしかありませんでした。 そしてそのC++標準ライブラリの一部として組み入れられたのがSTL(Standard Template Library)です。すなわちSTLは標準C++の仕様の一部ということです。 僕がSTLを知ったのは1995年、いくつかのコンパイラがtemplat
Joel on Software -
プログラマのためのユーザインタフェースデザイン 第 1 章 第 2 章 第 3 章 第 4 章 第 5 章 第 6 章 第 7 章 第 8 章 第 9 章 ストラテジーレターV 2002年6月12日 ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資本主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。ストラテジーレターⅤ 5つの世界 2002年5月6日 5つの世界：すべてのソフトウェア開発が同じではない。 追記：インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばし
ValgrindでApacheモジュールのメモリバグを見つけよう - ひげぽん OSとか作っちゃうかMona-
mod_uploaderの作者さんがまとめている開発Tips(http://acapulco.dyndns.org/mod_uploader/module_dev.htm)にあったデバッグ方法を試してみました。 Valgrind http://valgrind.org/ Valgrindはメモリ周りのバグや、スレッド系のバグを自動的に検出してくれるツールです。 インストールは ./configure make make install で完了です。 a.out(-gオプションでコンパイルしてください)のメモリ周りのチェックを行う場合は valgrind --leak-check=yes a.out とやると、こんな結果が出力されてメモリリークしている場所がずばり表示されます。 ==19182== 40 bytes in 1 blocks are definitely lost in los
ソースコードを読むための技術
$Id: readingcode.html,v 1.13 2003/12/06 00:01:08 aamine Exp $ 2006-05-02 gonzui 追加。thanks: 冨山さん 2003-12-03 ltrace と sotrace を追加 2003-12-03 ツールのところに DDD を追加。thanks: 和田さん 2003-05-27 VCG, SXT などについて追加。thanks: 梅沢さん 2003-05-27 これもすっかり忘れていた strace, ktrace, truss, etags などについて追加 2002-08-30 すっかり忘れていた ctags を追加 2002-07-07 匿名希望さんからメールでいただいた情報を追加 (動的コールグラフ) 2002-06-13 日記経由でいただいた意見をもとに文章を追加。thanks: 柳川さん、まつもとさ
FOFA - Find Once Fix All
バグを見付けたら同じようなバグがそこかしこにあると思え。そしてそれと同じようなまだ発見されていないバグを見付けて全部直せ、という原理原則がFOFAだ。言うのは易く行うのは難し。 某社のサポートの責任者と会食する機会があって、やっぱ、メインフレームの経験ですよね、修羅場をくぐった経験があるかないかで全然違いますよねという話になった。最近のゆるいシステムの話じゃなくて、ぎちぎちの基幹システムで胃がキリキリ痛むようなインテグレーションをして最後に腹を括らなきゃいけないような時、FOFAでやらなきゃ痛い目にあうのは自分だ。 手を抜かない。全力投球をする。それがFOFAだ。 オープンソースの若いエンジニアに伝授しなければいけない原理原則がいくつかあるとすると間違いなくFOFAはその一つだ。日本の競争力のある製造業の現場では問題を発見したら、その原因をとことん追求して同じ間違いを絶対しないような仕組み
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www1.kcn.ne.jp/~robe/cpphtml/index.html
http://www.boost.org/tools/build/v1/vc-8_0-tools.html
C/C++ Technical Documents