メタプログラミング Ruby 講義ノート・メモ

目次

メタプログラミングRuby / 毎回 の講義 / OO へ至る道 / ruby 入門 / 講義ドキュメント / meta-ruby まとめ / note / ruby-note / poker

オブジェクト指向へ至る道のノート

Done ソフトウェア危機

ソフトウェア危機

コンピュータが進歩するにつれて、 より複雑なソフトウェアが求められ始める その複雑さをコントロールするための道具やアイデアが不足

プロジェクト管理手法もなければ、 抽象度の低いデータ型,変数,制御構造

Done 構造化プログラミング

構造化プログラミング(wikipedia)

つまり、現代風に言い換えると「レイヤリングアーキテクチャ」のよう なもので、ある土台の上にさらに抽象化した土台をおき、その上にさら に・・・というようにプログラムをくみ上げていく考え方のことだ。

だから、我々は、ひとつのアーキテクチャないし関数の中で異なる抽象 化レイヤの実装を同居することをさける。

Done モジュラプログラミング

大きく複雑になるプログラムの分割

凝集度と結合度

結合度:よいコラボレーションとわるいコラボレーションを定義した http://ja.wikipedia.org/wiki/%E7%B5%90%E5%90%88%E5%BA%A6

凝集度:よい機能群のまとめ方とわるい機能のまとめ方を定義した http://ja.wikipedia.org/wiki/%E5%87%9D%E9%9B%86%E5%BA%A6

これらは「関心の分離」を行うためにどのようにするべきかという指針でもあった。 http://ja.wikipedia.org/wiki/%E9%96%A2%E5%BF%83%E3%81%AE%E5%88%86%E9%9B%A2

この「関心」とはそのモジュールの「責任」「責務」と言い換えてもい いかもしれない。この責任とモジュールが一致した状態にできるとその モジュールは凝集度が高く、結合度を低くすることができる。

悪い結合、良い結合

悪い結合としては、あるモジュールが依存しているモジュールの内部デー タをそのまま使っていたり(内容結合)、同じグローバル変数(共通結 合)をお互いに参照していたりというようなつながり方だ。

こうなってしまうとモジュールは自分の足でたっていられなくなる。つ まり、片方を修正するともう片方も修正せざるをえなくなったり、予想 外の動作を強いられることになる。

逆に良い結合としては、定められたデータの受け渡し(データ結合)やメッ セージの送信(メッセージ結合)のように内部構造に依存せず、情報の やり取りが明示的になっている状態を言う。

これはまさにカプセル化とメッセージパッシングのことだよね、と思っ た方は正しい。オブジェクト指向は良い結合を導くために考えだされた のだから。

悪い凝集、良い凝集

凝集度が低い状態とは,つまり悪い凝集とは,何か,

暗合的凝集
アトランダムに選んできた処理を集めたモジュールは 悪い。何を根拠に集めたのかわからないものも悪い凝集だ。
論理的凝集
論理的に似ている処理だからという理由だけで集めて はいけない。
時間的凝集
他にも同じようなタイミングで実施されるからといっ て、モジュール化するのもの問題がある。たとえば、 initという関数の中ですべてのデータ構造の初期化を するイメージをしてほしい。

一方、良い凝集とはなんなのか、それは

通信的凝集
とあるデータに触れる処理をまとめることであるとか、
情報的凝集
適切な概念とデータ構造とアルゴリズムをひとまとめ にすること。
機能的凝集
それによって、ひとつのうまく定義されたタスクをこ なせるように集めることである。
状態と副作用の支配

よいモジュール分割とはなにか

  • それは、処理とそれに関連するデータの関係性を明らかにして支配し ていくことの重要性だ。

    できれば、完全にデータの存在を隠蔽できてしまえると良いが、現実 のプログラムではそうは行かない場合も多い。

こういった実務プログラミングの中で何が難しいかというと、それが状 態と副作用を持つことだ。

オブジェクト指向に至るモジュラプログラミングは、こういった状態や 副作用に対して,積極的に命名,可視化,粗結合化をしていくことで 「関心の分離」を実現しようとした。

たとえば、現在でもC言語のプロジェクトなどでは,構造体とそれを引 数とする関数群ごとにモジュールを分割し,大規模なプログラミングを 行っている。

Done 抽象データ型

よいモジュール化の肝

  • 状態と副作用を隠蔽し、
  • データとアルゴリズムをひとまとめにする

それらを言語的に支援するために抽象データ型という概念が誕生した。

抽象データ型は、今で言うクラス

  • すなわちデータとそれに関連する処理をひとまとめにしたデータ型のこ とだ。
  • 抽象データ型のポイントは、その内部データへのアクセスを抽象データ 型にひもづいた関数でしか操作することができないという考え方だ。

内部構造を隠し,型とインタフェースを公開する。

  • 公開するヘッダと非公開のヘッダを分けることで、情報の隠蔽を行い抽象 データ型としての役目を成り立たせている。
抽象データ型の情報隠蔽とカプセル化

言語機能として外部からのアクセスを制限できるようにした。

カプセル化やブラックボックス化というのは情報隠蔽よりも広い概念で はあるが、これらの機能によって、「悪い結合」を引き起こさないよう にしている。

これによって、複雑化した要求を抽象化の階層を定義していくという現 代的なプログラミングスタイルが確立した。

Done オブジェクト指向?

simula

  • オブジェクト、
  • クラス(抽象データ型)、
  • 動的ディスパッチ、
  • 継承
  • ガーベジコレクト

Simulaの優れたコンセプトをもとに,2つの,今でも使われている,C言語 拡張が生まれた。

一つはC++。もう一つはObjective-Cである。

SimulaのコンセプトをもとにSmalltalkという言語というか環境が爆誕した。

Smalltalkは、Simulaのコンセプトに「メッセージング」という概念を加え、 それらを再統合した。Smalltalkはすべての処理がメッセージ式として記述 される「純粋オブジェクト指向言語」だ。

そもそもオブジェクト指向という言葉はここで誕生した。

オブジェクト指向という言葉の発明者であるアランケイは後に「オブジェク ト指向という名前は失敗だった」と述べている。メッセージングの概念が軽 視されて伝わってしまうからだという。

何にせよ、このSmalltalkの概念をもとにC言語を拡張したのがObjective-C だ。

Done Simula & C++のオブジェクト指向

C++のオブジェクト指向

継承と多態性を付加した抽象データ型のスーパーセット

どの処理を呼び出すか決めるメカニズム

さて、継承と多態を足した抽象データ型といっても、なんだか良くわからない。

特に多態がいまいちわかりにくい。オブジェクト指向プログラミングの説明で

string = number.StringValue
string = date.StringValue

これで、それぞれ違う関数が呼び出されるのがポリモーフィズムですよと 呼ばれる。

これだけだとシグネチャも違うので、違う処理が呼ばれるのも当たり前に 見える。

では、こう書いてみたらどうか

string = stringValue(number) // 実際にはNumberToStringが呼ばれる
string = stringValue(date)   // 実際にはDateToStringが呼ばれる

このようにしたときに、すこし理解がしやすくなる。引数の型によって呼 ばれる関数が変わる。こういう関数を polymorphic (poly-複数に morphic- 変化する) な関数という。

これをみたときに"関数のオーバーロード"じゃないか?と思った人は鋭い。 http://ja.wikipedia.org/wiki/%E5%A4%9A%E9%87%8D%E5%AE%9A%E7%BE%A9

多態とは異なる概念とされるが、引数によって呼ばれる関数が変わるとい う意味では似ている。しかし、次のようなケースで変わってくる。

function toString(IStringValue sv) string {
    return StringValue(sv)
}

IStringValueはStringValueという関数を実装しているオブジェクトを表す インターフェースだ。これを受け取ったときに、関数のオーバーロードで は、どの関数に解決したら良いか判断がつかない。関数のオーバーロード は、コンパイル時に型情報を付与した関数を自動的に呼ぶ仕組みだからだ。

stringValue(number:Number) => StringValue-Number(number)
stringValue(date :Date)  => StringValue-Date(date)

function toString(IStringValue sv) string {
    return StringValue(sv) => StringValue-IStringValue (無い!)
}

それに対して、動的なポリモーフィズムを持つコードの場合、次のように 動作してくれるので、インターフェースを用いた例でも予想通りの動作を する。

function StringValue(v:IstringValue){
    switch(v.class){ //オブジェクトが自分が何者かということを知っている。
    case Number: return StringValue-Number(number)
    case Date   : return StringValue-Date(date)
    }
}

このようにどの関数を呼び出すのかをデータ自身に覚えさせておき、実行 時に探索して呼び出す手法を 動的分配*,*動的ディスパッチ と呼ぶ。

このように動的なディスパッチによる多態性はどのような意味があるのか。

それはインターフェースによるコードの再利用と分離である。

特定のインターフェースを満たすオブジェクトであれば、それを利用した コードを別のオブジェクトを作ったとしても再利用できる。

これによって、悪い凝集で例に挙げた論理的凝集をさけながら、 汎用的な処理を記述することができるのだ。

オブジェクト指向がはやり始めた当時は、再利用という言葉が比較的バズっ たが、現在的に言い換えるなら、インターフェースに依存した汎用処理と して記述すれば、結合度が下がり、テストが書きやすくなったり、仕様変 更に強くなったりする。

動的ディスパッチ

動的ディスパッチのキモは、オブジェクト自身が自分が何者であるか知っ ており、また、実行時に関数テーブルを探索して、どの関数を実行する かというところにある。

こうなってくると、多態を実現するためには、3つの要素が必要だとわかる。

  • データに自分自身が何者か教える機能
  • メソッドを呼び出した際にそれを探索する機能
  • オブジェクト自身を参照できるように引数に束縛する機能
継承と委譲
継承
委譲

このようにメソッドの動的な探索に対して、どのような機構をつけるのかというのが オブジェクト指向では重要な構成要素と言える。

rubyの module やその include, prepend、特異メソッド,特異クラスなどは まさにその例だ。

オブジェクト指向の要素

  • 抽象データ型:データと処理をひもづける
  • 抽象データ型:情報の隠蔽を行うことができる
  • オブジェクト:データ自身が何者か知っている
  • 動的多態:オブジェクト自身のデータと処理を自動的に探索する
  • 探索先の設定:継承、委譲

ということになる。

Done Smalltalk & Objective-Cのオブジェクト指向

アランケイによるオブジェクト指向の定義:

パーソナルコンピューティングに関わる全てを『オブジェクト』とそれらの 間で交わされる『メッセージ送信』によって表現すること

仮想機械としてのオブジェクト

アランケイの世界観
コンピュータを抽象化するとしたら、データと処理と命令セットをも つ仮想機械で抽象化されるべき
構造化プログラミング
仮想機械として階層的に抽象化すべき
オブジェクト指向
オブジェクトを独立した機械と見なし、それに対してメッセージを送 り、自ら持つデータの責任は自らが負う。

Smalltalkの実行環境もまた仮想機械として作られている。

メッセージング

Smalltalkでメッセージ送信は下記のように記述する:

receiver message

メッセージングは通信。

  • アドレスさえ知っていれば、メッセージは自由に送れる。
  • レシーバはメッセージを受け取リ,その解釈はレシーバ自身が行う

このメッセージらしさが出てくる特徴をいくつか紹介しよう。

動的な送信

メッセージの内容もまたオブジェクトなので、動的に作成し送ることができる。

class A
  def hello
    p "hello"
  end
end

a = A.new
# 動的にメソッドを作成
method = "he" + "ll" + "o"
# それを呼び出す
a.send(method)
メッセージ転送 (Wikipedia)

受け取ったメッセージは、仮にメソッド定義がなかったとしても自由に取 り扱うことができる。

  • rubyの method_missing は,メソッドがない時に呼ばれるメソッド。 メソッドの未定義を知ることができ,その処理を他のオブジェクトにま かせるのが,メッセージ転送。

    proxy.rb

class Proxy
  def method_missing(name, *args, &block)
    target.send(name, *args, &block)
  end

  def target
    @target ||= []
  end
end

Proxy.new << 1

'end'
非同期送信

メッセージの送信と結果の受信を別々に行なう。

並列計算が可能になる。

オブジェクト指向という言葉が意味していること

http://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang

オブジェクト指向プログラミングの3つの主義は、

  • メッセージ送信に基づいて、
  • オブジェクト間で分離し、
  • ポリモーフィズムを持つ

オブジェクト指向はクソか

Joe Armstrongのオブジェクト指向はクソだ!

オブジェクト指向はクソか? - Qiita を読んで

オブジェクト指向が"Suck"である理由

私のOOPに対する反対意見はOOの基本的なアイデアに対するものも含まれます。 以下にそのアイデアのアウトラインと私の反対意見を述べます。

反論その1

  • データ構造と機能は一緒にすべきではない

(Objection 1 - Data structure and functions should not be bound together)

オブジェクトは関数とデータ構造が分割出来ない単位としてひとつまとめにし ています。しかし、私はこれこそが基本的でかつ大きな誤りであると考えてい ます。なぜなら、関数とデータは異なる世界に存在するからです。なぜでしょ う。関数は何かを実行します。そして関数はインプットとアウトプットを持ち ます。関数の入力と出力はデータ構造であり、関数により変更されます。

  • 「関数とデータは異なる世界に存在するからです」は,理由が希薄です。
    • 「関数とデータは,異なるものです。」は認めます。
    • データとその処理関数は近くにあって,同時に見られた方が,分かりやす いことが多いと思う。
    • データだけからなるクラスがあってもいいし,インタフェースだけからな るモジュールがあってもいい。Rubyではそうなっている。

多くの言語の関数は命令のシーケンスから作られます。すなわち、「まずはこ れを実行して、次はこれを実行しなさい」という手順です。関数を理解するた めにはどのような順序でものごとが実行されるかを理解しなければなりません (遅延評価をサポートする関数型言語と論理型言語ではこの制限は緩やかで す)。

  • 関数についての説明はそのとおり。

データ構造はそれそのものです。これらは何もしません。これらは本来宣言的 なものなのです。データ構造を理解することは関数を理解することよりもはる かに簡単なことなのです。

  • これは違うと思う。データ構造だけを見て,データ構造を用いてできる ことを理解することは,ほんとうに難しいこと,だと思う。

関数は,入力から出力へと変換するための,ブラックボックスです。入力と出 力を理解すれば,関数を理解したことになります。でも理解したからと言って, 関数を記述できることにはなりません。

  • 些細なことですが,「入力と出力を理解すれば関数を理解したことになり ます」ではなくて,関数を利用できることになるだと思います。そして, 「関数を利用できない人に,関数の中身は記述できません」だと思います。

関数は通常、コンピュータシステムにおいてジョブがデータ構造をT1からT2に 変換することの観察を通して理解したことになります。

  • ここは最初,理解できませんでした。
  • 「関数を書くには,複数のデータを見なくてはいけない。ある一つの型を主 にみて,書くことはよくない」と言ってるのかな。
    • そうかもしれないが,。。。
    • 適切な抽象度で見れば,関数のやってることは下記の3種 (ほんとかな?):
      変換
      自身 -> 自身
      簡約
      自身 -> 自明なもの
      合成
      自身 -> 高いレベルのもの

      だとすると,変換や簡約は自身と一緒に記述してあると,わかりやすい。 合成は,自身の中に記述するのではなく,高いレベルのものと一緒に書 くべきだと,思えます。

      入力が複数ある場合は,「どれか主になるものがある」場合や,「一纏 めとして扱うことができる」場合は,型(データ)を主に,処理の記述が でき,何をやっているのかが,分かりやすいと,思えます。

このように関数とデータ構造は全く異なるタイプの生き物です。そしてそれを 同じカゴの中に閉じ込めるのは全く持って間違っていることなのです。

  • 「異なるタイプの生き物を同じカゴに閉じ込めるのは間違い」は,理由になっていません。
  • 関数とデータ構造を近くに置いて,同時に見られることは,いいことです。
  • 問題があるとすれば,同じデータ構造に対し,異なる操作関数からなるク ラスが沢山ある場合の冗長さかな。
  • 「データを理解することは簡単」が考え方の違いの根本ですね,きっと。

    データ駆動なのか関数駆動(こんな言葉ある?)なのかの違いですね。

    関数駆動において,関数をできるだけ汎用にするためには,入力の型は, できるだけシンプルにし,入力の意味を多様に解釈・適応できることが, 関数の汎用性を高めるこになる。

    オブジェクト指向では,その解釈や適応できることを,書いておきたいんだ よね。きっと。

反論その2

  • すべてはオブジェクトではない

(Objection 2 - Everything has to be an object.)

「時刻」について考えてみましょう。OO言語の立場での「時刻」はオブジェク トであるべきです。でも、非OO言語では「時刻」はデータタイプのインスタン スです。例えばErlangでは「時刻」の多くのバラエティがあります。これらは とても明白で曖昧さがありません。

  • 時刻を表すデータ型はあったほうがいいでしょう。自明だと思います。時 刻を表すのに整数の組み合わせをもちいたいならそうもできます。 オブジェクトであるべきかどうかの議論にはなっていません。
    -deftype day() = 1..31.
    -deftype month() = 1..12.
    -deftype year() = int().
    -deftype hour() = 1..24.
    -deftype minute() = 1..60.
    -deftype second() = 1..60.
    -deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}.
    -deftype hms() = {hms, hour(), min(), sec()}.
    ...

これらの定義はどの特定のオブジェクトにも属していません。これらはどこで
も利用できるデータ構造で「時刻」を表現しており、システムのどの関数から
でも利用することができます。

そしてどのようなメソッドにも関連していません。
  • これらはインタフェース群とクラス (abstime(), hms()) )に見えるなぁ。
反論その3-オブジェクト指向言語ではデータタイプ定義はあちこちに散らばってしまう

(Objection 3 - In an OOPL data type definitions are spread out all over the place.)

オブジェクト指向ではデータタイプはオブジェクトとして定義されます。そう するとデータタイプは一箇所で見つけることができません。ErlangやCではす べての私のデータは一箇所であるinclude fileもしくはデータ辞書でみつける ことができます。でも、OOPLではこのようなことができず、データタイプ定義 はあちこちに散らばってしまいます。

  • Rubyでは,class/module 単位のまとまりをつくり, 継承やincludeにより 階層を作り,require によって,必要なライブラリを記述し, 適切な抽象度で,見ることができる。散らばっているのではなく, 適切なまとまりごとに*リンク*づけられている。 一望したければ,ツールをつくればいいだろう。

この例を示しましょう。私が汎用的なデータ構造を定義したいとします。この 汎用データタイプとはシステムのすべての場所で使えるものです。

LISPプログラマであれば「わずかな汎用データタイプと多くの小さな関数がこ れらに作用すること」が「数多いデータタイプとこれらに作用する少ない数の 関数よりも良いこと」という真実を知っています。

そして、汎用データ構造としてリンクリストや配列、ハッシュテーブルがあり、 さらには時刻、日付、ファイル名などがあります。

OOPLでは私は汎用的なデータ構造を定義する際にはなにかベースオブジェクト の中から選択しなければならないというとても面倒くさいことをしなければな りません。そして、そのデータ構造はこのオブジェクトを継承して作る必要が あります。もし何か「時刻」のオブジェクトを定義したい場合、これがどのベー スオブジェクトに所属していて、それ自体、どのようなオブジェクトであるか 考えなければならないのです。

反論その4

  • オブジェクトはプライベートな状態を持っている

(Objection 4 - Objects have private state.)

状態(state)は諸悪の根源です。特に関数の副作用は避けるべきです。しかし ながらプログラミング言語において状態は好ましいものではないのに関わらず、 実世界では状態は至るところに存在します。

  • はい,実世界をモデル化するプログラムでは,状態を持つことは 避けら れませんね。

例えば私は銀行口座の状態、すなわちに預金残高に大いなる関心があります。 そしていつ私が入金や出金をする場合には銀行の口座が正しく更新されなけれ ばとても困ったことになります。

実世界でこのような状態が存在したとして、この状態を取り扱うためにはプロ グラミング言語はどのような仕組みを提供すればよいのでしょうか。

OOPLはプログラマから状態を隠しなさいといいます。状態は隠されてアクセス 関数を通してしか見えません。

伝統的なプログラミング言語であるCやPasalでは状態変数の可視性は言語のス コープのルールによってコントロールされます。

でも、純粋に宣言的な言語では状態は存在しないことになっています。このよ うな宣言的言語ではシステムのグローバルな状態はすべての関数の入力や出力 になりうるのです。関数型言語におけるモナドや論理型言語におけるDCGでは 「状態はあたかも関係のないように」プログラミングすることができます。に も関わらず必要な場合にはこれらのシステムの状態に完全にアクセスをするこ とができるのです。

ほんとうは「プログラマから状態を隠す」というOOPLで選択されたオプション はとても悪いものなのです。状態を公開して状態の厄介さを最小限にしようと する努力をすべきなのに、その代わりとしてOOPLではそれを隠し去ってしまっ たのです。

  • よく理解できていませんが,「プログラマから状態を隠すのは良くない, OOPLだけがそうしている」という主張と読みました。
  • 「隠くすことも,公開することも,できるようにしよう」という立場だと思 います。アクセスすべきものは,アクセスできるようにします。でも,アク セスする時は,その持ち主のメソッドを通してというのが,Rubyのやり方。

オブジェクトが広まった理由

オブジェクト指向が広まった理由は次のとおりだといわれています。

  • Reason 1 - It was thought to be easy to learn. (簡単に学べると思われていたから)
  • Ruby は簡単に学べると思う。

  • Reason 2 - It was thought to make code reuse easier. (再利用がより簡単だと思われているから)
  • Rubyでは,再利用が簡単だと思う。

  • Reason 3 - It was hyped. (売り込まれたから)
  • Reason 4 - It created a new software industry. (新しいソフトウエア産業を作ったから)
  • そういう風潮もありますね。

しかし、1と2が事実であるという証拠はまったくを持って見たことがありま せん。

  • 筆者は Ruby を使ったことがあるのかなぁ?

それでも実際にオブジェクト指向が広まった理由はテクノロジーに対す る逆向きの作用であると思われます。つまり、あるテクノロジーがひどすぎる と、そのテクノロジー自体が作った問題を解決するための新たなビジネスが登 場して、金儲けをしたい人たちのアイデアになるのです。実はこのことが実際 のOOPに対する推進力になっているということなのです。

  • そういう風潮もありますね。

ruby のノート

emacs のノート

emacs

C-x SPC (rectangle-mark-mode &optional ARG) 
M-q 整形
C-x r x register 
C-x r g register 
C-x n n narrow region
C-x n w widen regions
M-x string-insert-rectangle

C-x r コマンド レジスタ関連

C-x r C-@     point-to-register
C-x r ESC     Prefix Command
C-x r SPC     point-to-register
C-x r +               increment-register
C-x r N               rectangle-number-lines
C-x r b               bookmark-jump
C-x r c               clear-rectangle
C-x r d               delete-rectangle
C-x r f               frameset-to-register
C-x r g               insert-register
C-x r i               insert-register
C-x r j               jump-to-register
C-x r k               kill-rectangle
C-x r l               bookmark-bmenu-list
C-x r m               bookmark-set
C-x r n               number-to-register
C-x r o               open-rectangle
C-x r r               copy-rectangle-to-register
C-x r s               copy-to-register
C-x r t               string-rectangle
C-x r w               window-configuration-to-register
C-x r x               copy-to-register
C-x r y               yank-rectangle
C-x r C-SPC   point-to-register

C-x r M-w     copy-rectangle-as-kill

Emacs24.4組み込みブラウザewwで目の疲れを1/10にする方法 | るびきち「日刊Emacs」

Emacs での テキストブラウザ eww を使えるレベルにする

http://futurismo.biz/archives/2950

KeyBindings

N (eww-next-url) P (eww-previous-url) l (eww-back-url) r (eww-forward-url) H (eww-list-histories) & (eww-browse-with-external-browser) b (eww-add-bookmark) B (eww-list-bookmarks) q (quit-window) 見にくいときは, R eww-readable

eww-mode (eww.el) binding

key             binding
---             -------

ESC             Prefix Command
SPC             scroll-up-command
&               eww-browse-with-external-browser
-               negative-argument
0 .. 9          digit-argument
B               eww-list-bookmarks
C               url-cookie-list
H               eww-list-histories
b               eww-add-bookmark
d               eww-download
g               eww-reload
l               eww-back-url
n               eww-next-url
p               eww-previous-url
q               quit-window
r               eww-forward-url
t               eww-top-url
u               eww-up-url
  (that binding is currently shadowed by another mode)
v               eww-view-source
  (that binding is currently shadowed by another mode)
w               eww-copy-page-url
  (that binding is currently shadowed by another mode)
DEL             scroll-down-command
S-SPC           scroll-down-command
<delete>        scroll-down-command
<remap>         Prefix Command

M-n             eww-next-bookmark
M-p             eww-previous-bookmark

This mode runs the hook `eww-mode-hook', as the final step during initialization.

org-mode のノート

org文書の構造

文章の構造

org#document structure

  • headlines
  • lists
  • drawers
  • blocks

ruby ソースコードの埋め込み方

org#working with source code

org#Structure of code blocks

#+name: 
#+begin_src ruby <arguments...>
body
#+end_src

ruby ソースコードのedit

ruby ソースコードの実行方法

ruby ソースコードの export

org#Exporting code blocks

#+begin_src ruby :exports both
body
#+end_src

ruby ソースコードの extract

org#Extracting source code

#+name: 
#+begin_src ruby :tangle <file>
body
#+end_src

memo

memo

Doing test-unit

Doing poker.org

~suzuki/COMM/Lects/meta-ruby/site/lects/poker の下に org 文書を作り ました。

global

ソースコードを快適に読むための GNU GLOBAL 入門 (前編) - まちゅダイアリー(2009-03-07) globalを使いブラウザで快適にソースコードを読む - ほろあま記念館

  • <2015-12-13 日> ~suzuki/public_html/Documents/ruby20に置きました。が,cgi動かず。
  • global-6.5.1 install しました。
    • ~suzuki/local/bin/gtags
  • ruby-2.0.0-p353 download し,gtags, htags しておきました。
    • ~suzuki/working/ruby20/ruby-2.0.0-p353

ruby-2.0.0-p353 ソースコードをHTML化したもの

EmacsでPATHの設定が引き継がれない問題をエレガントに解決する - Qiita

gem install spreadsheet for meta-ruby

meta-ruby 講義内容

  • meta な説明
    • meta programming
  • class library を使った ruby プログラミング
  • OO

Done .ob org-mode #+babel_include の導入   include babel org

why

include ファイル中の named_src_block の noweb 参照ができない

how
  • 同一ファイル中の named_src_block は noweb 参照ができるので, include を展開することにした。
  • 通常の include は展開したくないので, babel_include だけ展開する ことにした。
script
#!/usr/bin/env ruby
# coding: utf-8
def org_babel_expand_include (file)
  File.open(file, 'r:utf-8') do |io|
    io.read.each_line do |line| 
      if line =~ /^#\+babel_include:\s*(\S+)/
	org_babel_expand_include($1)
      else
	print line
      end
    end
  end
end

if __FILE__ == $0
  org_babel_expand_include(ARGV[0])
end

Doing org-tangle   auto tangle babel org

tangle を make できるように
ruby gem org-converge 中の org-tangle

:nowebの機能が使えないので,あきらめる

シェルコマンド化

org2html と同様に, org_tangle を作成

Makefile 中の tab が展開されるので, config/emacs-org.el を読むよ うにする

#!/usr/bin/env bash
# http://blog.nguyenvq.com/2010/10/30/bash-batch-script-to-convert-org-mode-file-to-html/
# orgdir=/r/src/org-mode/lisp/    # Git版org-modeのディレクトリ
# opts="-l ~/.org2html-batch.el"  # カスタマイズしなければ "" にする
opts="-l ~/.emacs.d/config/emacs-org.el"
f=""
for file in "$@"
do
#    f="${f} --visit ${file} --funcall org-export-as-html-batch"
#    f="${f} --visit ${file} --funcall org-html-export-as-html"
    f="${f} --visit ${file} --funcall org-babel-tangle"
done
# Emacs標準添付のorg-modeを使う場合はこっち
~/bin/emacs --batch -l org $opts $f
#~/bin/emacs --batch -q --no-site-file -l org $opts $f
# Git版org-modeを使う場合はこっち
# emacs --batch -q --no-site-file -L $orgdir -l org $opts $f

[2015-11-26 木 06:06]

new org-mode babel-include を展開する

ruby 日本語

ruby -K [e|s|u|n] euc-jp|cp932|utf-8|ascii-8

多言語化 (Ruby 2.2.0)

class Encoding (Ruby 2.2.0)

internal_encoding, external_encoding default_ … magic comment

# coding:utf-8

[2015-11-16 月 11:01]

ruby入門のサイトを変更したい

org babelを調べる

meta-ruby

クラス・モジュールの概念 Ruby - Qiita http://qiita.com/ToruFukui/items/2dd4d2d1ce6ed05928de

カレントオブジェクトselfについて Ruby - Qiita http://qiita.com/ToruFukui/items/be29968da6dc9d125315

誤解されている 6 つの Ruby の機能の真相を知る http://www.ibm.com/developerworks/jp/opensource/library/os-sixrubyfeatures/

[2015-11-13 金 20:59]

Rubyを勉強する上で有用な情報源まとめてみた - Qiita

ob-ruby

:session name を指定すると*nameバッファで inf-ruby が動く 実行はしているが,プロンプトの定義がおかしいためか,結果が取れてい ない。

pry をやめるとうまく動く

若手エンジニア/初心者のためのRuby 2.1入門(12):難しいが強力! Rubyのメタプログラミング、self、特異クラス/メソッド、オープンクラスとモンキーパッチ (1/4) - @IT

Ruby - 【mkdirからデプロイまで3分】Sinatra+Haml+Sass+Coffee でサクッとHerokuに公開して捨てるwebアプリ - Qiita

emacs-24.5 for @cis.iwate-u.ac.jp

~/bin/org2html index.org

Cannot fontify src block (htmlize.el >= 1.34 required)

  • melpa の htmlize の version は,1.47 なのに

log new_file graphviz

[2015-10-09 金 15:54]

Emacs org-modeを使ってみる: (19) graphvizとditaaの図を埋め込む - 屯遁のパズルとプログラミングの日記

org2HTMLの自動化

~/COMM/bin/org2html

著者: suzuki@cis.iwate-u.ac.jp

Created: 2016-02-15 月 09:28

Emacs 24.5.1 (Org mode 8.2.10)

Validate