JavaScriptデバッグツール集:phpspot開発日誌
Ajax Digest // Javascript debuggers overview JavaScript debugging has some specifics in comparison with stand-alone applications. JavaScript programs usually rely on interaction with the loaded page's Document Object Model (DOM) so errors may be caused by wrong DOM usage in a technically correct script. JavaScriptデバッグツール集。 様々なJavaScriptデバッグツールが紹介されてます。 （Microsoft Script Debugger) IE上で動作するもの Micros
まつもと直伝 プログラミングのオキテ 第5回（3）
ソートや大小比較に使える ブロックは，C言語のqsortのような要素ごとの条件判定にも使えます。例えば，Rubyのソート・メソッドは以下のようにブロックを扱えます。 ary.sort{|a,b| a＜=＞b} C言語のqsortと比較するとずいぶん簡単に使えることが分かります。もっとも，sortメソッドはブロックが指定されないと要素を「＜=＞」演算子を使って比較しますから，このような指定をしてもデフォルトと同じことになるため，あまり意味がありません。 今度は各要素を整数に変換してソートしてみましょう。 ary.sort{|a,b| a.to_i ＜=＞ b.to_i } これも簡単ですね。ブロックを指定しない方法では，文字列を辞書順に比較しますが，このようにブロックを指定した場合には，整数として値が小さい順に並び替えます。辞書順の並びでは「10」は「1」と「2」の間に並びますが，数値順であ
まつもと直伝 プログラミングのオキテ 第5回（2）
ブロックを使う2つの方法 Rubyのブロックについてもう少し詳細を見てみましょう。Rubyのブロックはメソッド呼び出しに付加できるコードの塊であって，それ自身はオブジェクトではありません（ブロックをオブジェクト化したものがクロージャです）。渡し方も通常の引数とは違います。次のメソッド呼び出しを見てください。 ary.each {|x| puts x} このコードを観察すると，以下のようなことが分かります。 ●aryオブジェクトのeachメソッドが呼び出されている ●通常の引数はない ●ブロックが付加されている メソッドから渡されたブロックを利用する方法は2つあります。一つは「ブロック引数」でブロックを受け取ることを明示的に宣言する方法，もう一つは予約語yieldを用いる方法です。図6[拡大表示]ではブロック引数を用いています。配列に対する繰り返し処理を進めるeachメソッドが定義されていま
まつもと直伝 プログラミングのオキテ 第5回（1）
今回はRubyの特徴的な機能である「ブロック」という構文について解説しましょう。Rubyでいうブロックとは「メソッド呼び出し時に追加できるコードの塊」を意味します。 例えば，配列の各要素に対する繰り返し処理を進める次のコードを見てください。 ary.each {|x| puts x} この例ではかっこ（ブレース）に囲まれた領域{|x| puts x}がブロックに相当します。これだけで，「各要素を変数xに代入した上で，putsを実行する」という意味になります。 Rubyにあるブロックは，Rubyオリジナルの機能ではありません。他の言語に古くから存在していたものを文法的にアレンジしたものです。ブロック機能の発想の基になった他言語の機能も含めて解説しましょう。 関数を引数に取る高階関数 Rubyのブロック機能は原理的には「高階関数」と呼ばれるものと同じです。高階関数とは「関数を引数に取る関数」を
まつもと直伝 プログラミングのオキテ 第4回（3)
図7 明示的な型チェックを実行した例<BR>Stringクラス以外を受け取った場合，例外を発生させている。 動的型のメリット では，もう一方の動的型についてはどうでしょう。動的型を採用したプログラミング言語の最大の利点は，ソース・コードが簡潔になることです。プログラミング言語はより簡潔により多くのことをコンピュータに伝えるために進化してきました。きちんと動き，エラーも検出できるのであれば，プログラムの動きの本質とは関係のない型指定などない方が良い，というのも一つの考え方です。 プログラムが簡潔に記述できれば，プログラムを書くときに，型のような処理の本質に関係ない部分のことを考えなくても済みます。本質に集中した簡潔な記述ができれば，生産性も向上することでしょう。 一方，いくら簡潔に記述できてプログラムが書きやすくなっても，型情報がなければ，プログラムを読解しにくくなるのではないか，という懸念
まつもと直伝 プログラミングのオキテ 第4回（2）
オブジェクト指向で開花した動的型 プログラミング言語におけるデータ型は，FORTRANに起源がある変数や式に型を指定する静的型と，Lispを起源とし，データそのものに型情報を付加する動的型の2つの方法に分かれました。静的型はFORTRANからCOBOL，ALGOLを経由して多くのプログラミング言語に引き継がれました。 Cはデータ型を持たないBCPLを祖先としますが，ALGOLなどの影響を受けて静的型を導入しています。 一方の動的型は，長らくLispとその影響を受けた言語（例えばLOGO）でのみ採用されてきましたが，あることをきっかけに広く受け入れられるようになります。 その「あること」とは，オブジェクト指向プログラミングです。最初のオブジェクト指向言語であるSimulaはALGOLの影響を強く受けた言語なので，整数などの基本的なデータ型については静的型を採用していました。しかし，新たに導入
まつもと直伝 プログラミングのオキテ 第4回（1）
今回はプログラミング言語の型について学びます。型には静的型と動的型の2種類があります。それぞれの歴史的な背景から始め，利点，欠点について学びます。動的型の新しいプログラミング・スタイルである「Duck Typing」も紹介します。 プログラミングの世界では，しばしば「静的」（Static），「動的」（Dynamic）という言葉が使われます。静的とは，「プログラムを実行しなくても，ソース・コードを見るだけで分かること」という意味です。プログラムの静的な部分とは，変数や手続きの名前と型，制御構造の構成などです。 それに対して動的とは，「プログラムを動かしてみないと分からないこと」という意味になります。プログラムの動的な部分とは変数などの具体的な値，実行時間，使用メモリー量などでしょう。 プログラムが採用するアルゴリズムと入力値が分かれば，実行してみなくても出力が分かる場合もありますが，現実には
まつもと直伝 プログラミングのオキテ 第3回（3）
図7 Mix-inによるStreamクラスの構築例<BR>クラス階層はツリー構造を保ちつつ，コードのコピーも避けている。 継承には2つの意味がある Javaのような静的型のオブジェクト指向言語の変数には，変数を介して呼び出されるメソッドを制限する働きがありました。ただし，制限がかかるのは「どのようなメソッドを持っているか」であって，「どのように実装されているか」ではありません。 今まで一まとめにして継承と呼んできましたが，実は継承には2つの異なる概念が含まれています。一つは，「どのようなメソッドを持っているか」あるいは「どのように振る舞うか」ということに着目した「仕様の継承」です。 もう一つは「どのようなデータ構造を使い，どのようなアルゴリズムで処理するか」ということに着目した「実装の継承」です。 静的型言語では両者の区別が重要になります＊4。Javaでもこの2つを明確に区別しており，実装
まつもと直伝 プログラミングのオキテ 第3回（2）
多重継承から生まれる3つの問題 もう少し，細かく見ていくと，多重継承の問題は以下の3点にまとまります。 ●構成の複雑化 単一継承では，あるクラスのスーパークラスは簡単に決まります。直接上のスーパークラス，そのスーパークラス，そのまたスーパークラス，…と一列に並ぶ単純な関係です。多重継承では，あるクラスに複数のスーパークラスがあり，その複数のスーパークラスそれぞれにさらに複数のスーパークラスがあるので関係が複雑になってしまいます。 ●優先順位 複雑な関係を持つスーパークラスがあるということは，クラス群の優先順位が一目で分からないということです。例えば図4[拡大表示]のようなクラス階層があるとします。Dがあるメソッドを受け継ぐ順番は，D，B，A，C，Objectなのか，D，B，C，A，Objectなのか，あるいは全く違う順序なのかが分かりません。一つに決まらないのです。クラスの優先順位がはっき
まつもと直伝 プログラミングのオキテ 第3回（1）
今回は継承についてより深く学びます。特になぜ多重継承が必要なのか，多重継承にはどのような問題があり，JavaやRubyがどのように解決しているのかを学びます。 前回はオブジェクト指向プログラミングを構成する3原則（ポリモーフィズム，データ抽象，継承）のうち，継承について扱いました。人が一度に把握，記憶できる概念の数には限りがあること，これを解決するため，クラスのうち似たような部分をくくり出す仕組み（継承）が必要であることを解説しました。継承はプログラムの構造化，抽象化の流れが自然に進化した形として登場したとも説明しました。 しかし，最後の部分は厳密には正しくありません。構造化，抽象化とは，共通部分をスーパークラス（親クラス）としてくくり出すボトムアップ・アプローチを意味します。このように継承が誕生したのであれば，最初から複数のスーパークラスを持つことができる多重継承＊1が主流だったに違いな
まつもと直伝 プログラミングのオキテ第2回 （3）
ひな形 プログラム中にオブジェクトが登場する場合，同じ動作をするものが多いでしょう。交通シミュレーション・プログラムでは車を表すオブジェクトや信号を表すオブジェクトが数多く登場します。同じ種別のオブジェクトはみな同じ性質を持っていますが，位置や色などそれぞれ状態が異なります。 抽象化の原則から言えば，同じものが数多く登場する場合にはグループ化してまとめてしまうべきです。このことをDRY（Don't Repeat Yourself）原則と呼ぶこともあります。 既に見てきたように，プログラムの重複は諸悪の根源です。重複があるとプログラムの修正が広範囲に及びますから，修正コストが高くなります。変更カ所が複数に及び，そのうちのたった1つでも修正を忘れてしまうとプログラムは正常に動作しません。重複はプログラムの信頼性を低下させる可能性が高いといえます。 さらに言えば，重複のあるプログラムは冗長ですか
まつもと直伝 プログラミングのオキテ第2回 （2）
複雑さという敵 実際にオブジェクト指向プログラミングを進めるために重要な原則に戻りましょう。 ソフトウエア開発の最大の敵は複雑さです。人間の脳はあまり複雑なものを扱うことができないのです。記憶力と理解力に限界があるためです。人間は一度に把握できる概念の数に限界がありますし，複数のことを記憶しようとするとたいていいくつかは忘れてしまいます。 ソフトウエアを実行するコンピュータにはこのような制約はなく，コンピュータはどんなに複雑なソフトウエアだろうとも，どんなに処理するデータが増えようとも処理時間が長くなるだけで処理できなくなることはありません。世の中のデータ処理がどんどんコンピュータ化されるにつれ，ソフトウエアへの要求は増し，開発されるソフトウエアはどんどん複雑になってきています。 年々性能が向上するコンピュータの処理能力の限界よりも，人間の理解力の限界によるソフトウエア生産性の限界の方が，
まつもと直伝 プログラミングのオキテ 第2回（1）：IT Pro
オブジェクト指向プログラミングを構成する3原則のうち，前回は「ポリモーフィズム」を学びました。今回はオブジェクト指向の歴史を復習した後，残りの「データ抽象」と「継承」について解説します。 オブジェクト指向プログラミングを構成する3原則は「ポリモーフィズム」，「データ抽象」，「継承」であると言われます。3原則を別の名前で呼ぶこともあります。例えば，「ポリモーフィズム」を「動的結合」と呼んだり，「データ抽象」を「情報隠ぺい」，「カプセル化」と呼んだりします。しかし，名前が違っても指し示すものは同じです。多くの人はオブジェクト指向プログラミングにこれらの原則が重要であると考えているようです＊1。 オブジェクト指向の歴史 最近になってオブジェクト指向という単語を耳にした人にとっては，オブジェクト指向というのは新しい単語が山のように出てくる難しい概念だ，という印象を持たれることが多いようです。実際，
まつもと直伝 プログラミングのオキテ 第1回（3）：IT Pro
ポリモーフィズム ポリモーフィズム（Polymorphism）とは，複数を意味する接頭語「poly-」と形態を意味する「morph」との合成に，接尾語「-ism」が付いたものです。つまり「複数の形態であること」という意味です。和訳して「多態」と呼ばれることもあります。 別の言い方をすれば，多態とは複数の種類のものをあたかも同じものであるかのように扱うことができることを言います。 これだけだと，なんのことだか分からないかもしれないので，一つのたとえを使いましょう。 ここに3つの箱があります。箱にはそれぞれふたがあり，ふたが乗せてあるだけのもの，鍵が付いたもの，リボンで結んであるものに分かれます。箱自体が非常に高価なので，それぞれの箱には専任のオペレータが付いていて，箱に対してなにかしたいときには，オペレータに命令します（図1[拡大表示]）。 3種類の箱はそれぞれ開け方が違っています。しかし「
まつもと直伝 プログラミングのオキテ 第1回（2）：IT Pro
いかに書くか プログラムの記述方法であるプログラミング言語に対して，「いかに書くか」というのがプログラミング・テクニックです。本連載では，表1に示すさまざまな領域のプログラミング・テクニックに踏み込みます。 表1にあるコーディング・スタイルは，プログラムの書き方の細かい部分，例えば変数名の選び方や，関数の書き方などを含みます。 アルゴリズムは問題を解決する手順のことです。世の中にはさまざまなアルゴリズムが知られています。プログラムはアルゴリズムの具体化と言っても過言ではありません。 いくつかのアルゴリズムは，自分の力だけで考え出すのは 困難です。例えば，配列要素を大きさの順に並べ替えるソートのアルゴリズムは数多く知られていますが，既存のアルゴリズムを全く知らなければ高速なソートは実現できないでしょう。アルゴリズムはしばしば特定のデータ構造を伴います。かつて「プログラミングとはアルゴリズム＋
まつもと直伝プログラミングの掟1(1) プログラミングとオブジェクト指向の関係（上）：IT Pro
プログラマを目指す人々の中にも，「オブジェクト指向は難しい」とか，「なかなか分からない」という印象を持つ方が多いようです。そこで，Rubyを題材にオブジェクト指向という考え方について説明していきます。（ネットワーク応用通信研究所 まつもと ゆきひろ） プログラミングとは，コンピュータに作業手順を教え込むことです。ただ，コンピュータは決して賢くないので，言われた通りの作業をこなすことしかしません。コンピュータが優れているように見えるのは，単に超高速で計算する能力があるからです。効率の悪い作業を命じられても，プログラムによって指定された通り，文句の一つも言わずに黙々と処理します。コンピュータの能力を生かすも殺すもプログラムの書き方ひとつなのです。 ですから，プログラムを書く人（プログラマ）はコンピュータを自分の意のままに扱う人であり，コンピュータの「ご主人様」であると言ってもよいでしょう。にも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
