• 07 «
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • » 09
ASOK?
ActionScriptでFlashつくるよ
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
page top

今さらITProの連載「まつもと直伝 プログラミングのオキテ」を読んでる。
これが読みやすい文章で、素晴らしい。難しいことをわかりやすく書ける人は、やはり天才だと思う。

まつもと直伝 プログラミングのオキテ---目次

気になった箇所をメモ。

(略)最も古い言語の一つであるLispは,(略)きちんとした数学的バックグラウンドを持つため,言語自身を拡張させていく機能を備えていました。

 もう一つのDSLの実現方法はインタプリタを用意するものです。(略)具体的には文法にXMLを使って,DOM(Document Object Model)などのXML処理ライブラリを使って文法解釈を行います。Javaアプリケーションの設定ファイルにXMLが採用される理由の一つがこれです。XMLファイルによって,いちいちJavaプログラムをコンパイルすることなくアプリケーションの設定を変更したり,挙動をカスタマイズしたりできるようになります。

まつもと直伝 プログラミングのオキテ 第2回(1)

 仕様の継承と実装の継承の区別は,(略)広く使われる言語に組み込まれたのはJavaが初めてだと思われます。多重継承問題に対するJavaの解答と言えるでしょう。

Javaでは実装の共有の問題への対応として,単一継承のまま,共通する機能を実装する別クラスを作り,それを呼び出すCompositeパターンを推奨しています。

用語 内容
単一継承 スーパークラスを1つしか持てない継承
  単純だがいくつか問題がある
多重継承 スーパークラスを複数持てる継承
  単一継承の問題を解決する(オブジェクト指向言語にはなんらかの多重継承の存在が望ましい)
  単一継承にない別の問題がある
静的型言語 仕様の継承と実装の継承がある
動的型言語 実装の継承しかない
仕様の継承における多重継承の問題 Javaのインタフェースなどで対応
実装の継承における多重継承の問題 Mix-inで対応
Mix-in 多重継承のある言語なら使えるテクニック
RubyにおけるMix-in 利用を強制し、積極的に問題を回避

まつもと直伝 プログラミングのオキテ 第3回(3)

 RubyのEnumerableにはcollect,select,detectなど「ect」で終わるメソッドがたくさんあります。これはSmalltalkから引き継いだメソッド名です。

まつもと直伝 プログラミングのオキテ 第7回

内部イテレータの欠点

内部イテレータの欠点は,同時並行の繰り返しができないため,2つのコレクションの要素を順に比較するような処理を書けないことです。

外部イテレータの欠点

(略)イテレータ(カーソル)オブジェクトがコレクション・オブジェクトの内部情報を参照する必要があるため,カプセル化が破れてしまう点です。C++ではfriendを使うことになるでしょう。

まつもと直伝 プログラミングのオキテ 第8回

 Comparableモジュールは大小比較の基本となる「<=>」メソッドを用いて,各種比較演算を提供しています。「<=>」メソッドの仕様はレシーバと引数を比較して,レシーバの方が大きければ正の整数,等しければゼロ,小さければ負の整数を返すというものです。このメソッドを基礎にして,Comparableモジュールは「==」,「>」,「>=」,「<」,「<=」,「between?」の6つの比較演算を提供しています。

まつもと直伝 プログラミングのオキテ 第9回

Comparable

比較演算を許すクラスのための Mix-in。このモジュールをインクルー ドするクラスは、基本的な比較演算子である <=> 演算子を定義してい る必要があります。他の比較演算子はその定義を利用して派生できます。

Comparable - Rubyリファレンスマニュアル

 実際の更新通知は単にchangedメソッドを呼んで更新フラグをセットしてから,notify_observersメソッドで監視に通知を行っています。いずれもloop内に記述されています。

 今回のように毎回必ず定期的に更新を通知する場合には,changedとnotify_observersを分離する意味はありませんが,頻繁に変化し,毎回更新を処理するコストが無視できないような場合のことを考えて分けてあります。例えば先ほどのスプレッド・シートの例ではささいな変更を施すごとにグラフを更新するよりも,キー入力が一段落した時点でまとめて更新する方が効率的でしょう。

まつもと直伝 プログラミングのオキテ 第9回

 データベースに依存する多くのWebアプリケーションでは,しばしばテーブルの各エントリに対してCRUDという操作が行われます。CRUDとはCreate(作成),Read(参照),Update(更新),Delete(削除)…(略)

まつもと直伝 プログラミングのオキテ 第11回 コード・ジェネレーション

久しぶりにJavaのプログラムを読みましたが,普段使っているRubyに比べると,冗長さにくらくらします。

まつもと直伝 プログラミングのオキテ 第11回 コード・ジェネレーション

 シュウォーツ変換は,繰り返し計算される値を保存しておくことで計算量を削減しています。これは「Memoize」と呼ばれる高速化テクニックの一種です。計算においては時間と空間はしばしば交換可能です。計算結果を保存することでメモリーを余分に消費しますが,その代わり計算を省いて時間を稼ぐことになります。Memoizeテクニックはいろいろな局面で,高速化に利用できます。

まつもと直伝 プログラミングのオキテ 第13回 プログラムを高速化する

パレートの法則とは「80:20則」とも呼ばれる法則で,全体の8割の数値は全体を構成する2割の要素が生み出しているという法則です。

 また,Donald Knuth氏*2も「通例,実行時間の半分以上はプログラムの4%未満の部分で費やされる」と述べているそうです。

まつもと直伝 プログラミングのオキテ 第13回 プログラムを高速化する

与えられた2つの配列の両方に含まれる要素を求める手続き


まつもと直伝 プログラミングのオキテ 第13回 プログラムを高速化する

benchmark

ベンチマークを取るためのクラスです。

benchmark - Rubyリファレンスマニュアル

早すぎる最適化はすべての悪の根源である(Premature optimization is the root of all evil)。

(1)行ってはならない。(Don't do it.)
(2)(エキスパート専用)まだ行ってはならない。(For experts only)Don't do it yet.

まつもと直伝 プログラミングのオキテ 第13回 プログラムを高速化する

(1)特定のビットの状態を取り出す

論理積(&)を使います。取り出したい位置のビットのみに1をセットした数Bを用意し,AとBとのビット論理積をとれば,ビットaの状態だけを取り出せます。

(2)特定のビットをセット(1)する

ビット論理和により,元の数の内容によらずに,新しい数のビットをセットできます。

(3)特定のビットをクリア(0)する

まず,論理否定により特定のビットだけがクリアされたビット・マスクが用意できました。このマスクと論理積を計算することによりクリア操作を実行できます。

(4)特定のビットを反転させる

これはビットのセットとほぼ同じで,論理和の代わりに排他的論理和を用います。

ビットマスクを作る

特定のビットだけがセットされた数を作るにはシフト演算子を使います。

まつもと直伝 プログラミングのオキテ 第14回 意外に深い整数の世界

Rubyが「1.0」と表示したとしても,単にインテリジェントな出力ルーチンが「十分に1.0に近い値」であると判定しただけなのです。

●浮動小数点数演算の例
0.1を10回足し合わせても1.0にはならない。

これは0.1が2進数では無理数であるということに関係しています。

 Floatの比較演算子は内部的に全く同じ表現を持つ数同士だけを等しいと判定しますから,鉄則としては「2つの浮動小数点数は == で比較してはいけない」となります。

まつもと直伝 プログラミングのオキテ 第15回 浮動小数点数の謎に満ちた世界

●特別な数を含む演算の結果

まつもと直伝 プログラミングのオキテ 第15回 浮動小数点数の謎に満ちた世界

大きな数が扱えるからと浮動小数点数を安易に整数の代わりに用いてはいけないのです。値が大きくなったとき,インクリメント(値を1増やす)したはずなのに数が増えなくなってしまうなどのトラブルが起こります。

まつもと直伝 プログラミングのオキテ 第15回 浮動小数点数の謎に満ちた世界

分数を表現できるRationalクラス

Rational - Rubyリファレンスマニュアル

ビューはモデルを参照でき
ビューがコントローラを参照できるかどうかはアプリケーションによって異なります。
モデルがビューやコントローラを参照できるようには設計すべきではありません。

まつもと直伝 プログラミングのオキテ 第20回 MVCとRuby on Rails

多くのGUIツール・キットではビュー相当とコントローラ相当が結合したものをコンポーネント(部品)と呼んでいます。

まつもと直伝 プログラミングのオキテ 第20回 MVCとRuby on Rails

HTTPの性質によってUI部分の複雑さはWebブラウザに任せてしまっているWebアプリケーションでは,相対的にUI層が薄くなります。コントローラ相当はほぼ汎用品で十分ですし,モデルとビューのインタラクションも不要です。ですから,モデルをデータベース層とビジネス・ロジック層に分割して,下層をモデル,上層をコントローラと呼ぶようにしたのでしょう。

表2●従来のMVCとRails MVCの比較

まつもと直伝 プログラミングのオキテ 第20回 MVCとRuby on Rails

「破壊的メソッド」とは文字列そのものを書き換えてしまうメソッドのことです。例えば,「s.squeeze」は文字列sの中の連続した文字を1文字にまとめた別の文字列を返します。しかし,「!」のついた方のメソッドは文字列そのものを置き換える(略)

まつもと直伝 プログラミングのオキテ 第21回 オープンクラスとRuby on Rails

表3●ActiveSupportライブラリ中の時間に関するメソッド

表4●Numericクラスに追加されるバイト単位系メソッド

まつもと直伝 プログラミングのオキテ 第21回 オープンクラスとRuby on Rails

2010/07/25追記

さっき読了。おもしろかった!

関連記事
page top

コメント

管理者にだけ表示を許可する
 

トラックバック
TB*URL
Copyright © 2005 ASOK?. all rights reserved.

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。