内輪中の内輪ネタで申し訳ないが、たった今、ふと思った。 調べたいもの、ここではgtkimmoduleの詳しい（すくなとも日本語の） ドキュメントがないって現状なわけだけど、 じゃーソース読めばよくね？

# apt-get source gtk2
$ ls -l | grep gtk
-rw-r--r--   1 root root 9295045 10月 15 06:06 gtk2-2.4.13-0vl1.src.rpm

（・∀・）キター!

解凍したらgtkimmodule.c, gtkimcontext.cハケーン。 研究室のこととかもあるんだが、ちと読んでみようかな。いや、やめとこうかな。 でもちょっとだけ見てみようかな。

しっかしソース見れるってのはすばらしいね。 見るだけでも勉強になるし、気に食わなかったら自分で直せるし、 gccとか標準で入ってるからすぐ開発できるし。 Windows使ってた半年前では考えられない。Linuxばんざーい。

最近ネットしてるとRubyって単語がよくページに出てくるので、 さすがにPerlでいいじゃん派の俺も気になっていて、 るびまにふらっと行って 0005号を見たら インタビューのところにPOBoxの増井さんの名前が！　迷わずクリックした。

俺はヘタレなのでPOBoxでしか増井さんを知らないので言語処理関係の人かと思って読んでいたんだが、 全然そんなことはなくて。この人はなかなかいろいろやっているんだね。ソフトからハードまで。 というか、まず発想があって、その実現手段としてソフトもハードもやる、という感じですか。 うちの大学だと竹林さんと近いのかねぇ。いや、研究室訪問もまだ行ってないから、なんとなくだけど。

インターフェイスについての話は新鮮だったな。達成したいことと、その手段とのマッピングのとこ。 これ、考えてみるといろんなところに無駄なマッピングってあるはず。 POBoxもインターフェイス改善の一つの形ということなんですかね。 入力メソッドという狭い範疇の仕組みではなくて。

ああいう観点が新鮮に思えたのは、インタビューにあるようにやっぱ今のに慣れ過ぎというか、 迎合し過ぎなんだろう。「こういうものだ」「慣れちゃったし」「今あるのでいいじゃん」って 納得することはよくあるけど、これが発想を止めるんだとつくづく思ったよ。 大体考えること放棄してるもんな！　楽だもんな、そう言ってれば。 こういう問題意識を持たない態度が視野を狭くして、研究してみたいことが具体的に見えないとか、 院に行くにもイマイチ何しようか具体的に浮かんでこないことの原因になってくるんですかね。OTZ

• ７日以内にＭ６級地震が関東地方を直撃
• 非常に大きい地震雲が発生しました

関東のほうらしいけど。 マジでこっちも地震に備えて準備しといたほうがいいかもしれん……いつかは来るしな……。 静岡県人として、地震への意識は常に持っておかないと…… つーか小学校のころからの教育が生きてない俺。 乾パンだー、水だー、懐中電灯だー、ラジオだー。 コンタクトないとまったく見えなくて致命的なのでメガネも買おう。

これからの俺のテーマは自然言語処理なので、 プログラミング言語は好き嫌いや流行り廃りではなくて、 いかにツールとして最適かで選ばなきゃなと思う。

研究のインフラとしての Ruby

_ 組織または個人名：（匿名，仮称も可）

九州工業大学 情報工学部 知能情報工学科 野村・中村研究室

_ 対象とする問題の概要：

自然言語処理の研究に際しては小道具としてのプログラムやデモプログラムで 様々なテキスト処理が必要となります． 当時，テキスト処理能力と開発効率とに優れていることから Perl を 使っていたのですが， 大きな問題がありました． 大学の研究室としての性格上， 学生の入れ替わりに伴って引き継ぎが必要となるわけですが， 他人の書いた Perl スクリプトは非常に読みづらく， 読み解くよりも自分で書き直した方が早いというケースが多発しました． そこで，Perl と同等以上のテキスト処理能力と開発効率を持ち， Perl よりも 読みづらいプログラムに *なりにくい* ような言語が求められました．

日本Rubyの会 公式Wiki - Ruby活用事例集

うわー、今から思い浮かぶぞー。引き継ぎの時だけじゃなくて、研究室内で お互いのソースが理解できないって図が。 特にPerlってのは熟練するほど「省略の美学」に洗脳されてしまうので（だがそれがイイ） 俺の書いたソースでさえ初心者には意味も利点もサパーリのはずだし、 「書き方は一通りではない」というスタンスをPerlという言語はとっているので、 ある書き方で書かれたものは、それを知らなければ理解できないってことになる。 逆に初心者のプログラムを俺が見た場合でさえ 「なんでこんな回りくどい書き方をするんだ、ムキー ヽ(`Д´)ノ」って なってイライラがたまる→こっそり俺が書き直すってことになりそうだ。 つまり、他人の書いた Perl スクリプトは非常に読みづら い理由がそこにある。

例えばCでお互いのソースを読みにくくする要因はこんなところだと思う。

• アルゴリズムの洗練度の違い
• スペースや空行の取り方の違い
• 命名が不適切
• モジュール分割の仕方が不適切

これらは言語の使い方の問題だ。つまり言語の学習コスト自体は低い。 でもPerlは多少熟練するまで目の前にある構文がわからないってことがありうる。 もちろんPerlが学習困難で利用しにくい言語と言うわけではない。 他人のソースを読むにはそれなりのPerlのボキャブラリーが必要ってことだ。 つまり可読性が、アルゴリズムの構成力や作法だけではなく言語自体の熟練度にも左右されてしまうと思う。 と、偉そうに書いてみた。その点Rubyはどうなのか、勉強しながら考えてみたい。

今日は研究室でネットができるようになった。 研究室内にひっぱってあるLANの状況がわかったので、あとはPC待ちだな。 とりあえずキタ野さんからハブを借りたので、ノートPCでネットが利用できる。

入口横の掲示板で訪問者を出迎える（・∀・）

なかなか5階ってのは静かなもんで、いい環境だ。南向きで部屋も明るい。 眺めもいいし、給湯室もトイレも遠くない。部屋もでか過ぎず、 人も多過ぎず。金もあるみたいだし……。 あとは本や雑誌を持ち込めば、1日あそこにいても問題ない。

ただ、まだまだ困ることばかりだ。メーリングリストがないから連絡とりにくいし、 なんかシステム置こうとしてもサーバがない。 ほとんど勉強してないから、言語処理に関係したアイデアも出ない。 今日はRubyの本を読んでただけだったな。

今日は研究室で勉強する言語について、PerlやめてRubyにしね？ってのを提案してみた。 まー俺にとってRubyを使う最大の利点はオブジェクト指向プログラミングにおける 文法の素直さと効率の良さなんだけど、オブジェクト指向をかじったことない人達には Perlが持つ例外的文法をつっつく方がわかりやすいかと思って、いろいろくどくどうざく講義じみたことをした。

例えばPerlの変数には、ある値を保持する$scalarという書式を持つ変数と、 変数の集合をあらわす@array, %hashという、2種類が少なくともあるはず。 でもCにしろJavaにしろRubyにしろ、さらーと勉強した感じ、 変数は値の集合をそのまま保持するようなものはなくて、 数値か文字かポインタ（参照）というある単一の値を保持するようになってる(Rubyは数値かポインタ、 Cは構造体もか）。

で、問題はこの2種類の変数がお互い代入しあったり、引数になったりして、 両方をごちゃ混ぜに扱う場面になったとき解釈はどうなるんだーってのが、まず立ちはだかる壁としてある。 これは、変数名と値が1対1に対応するCなどでは、決して問題にならない （もちろんポインタの理解は必要だが別問題）。

こんなのはまだ一例だけど、結局 一見真新しい文法が予測可能で「想定内」であったり、既存の知識から説明がつくほうが やっぱり言語の理解というのは進みやすいわけで、 Cなどをある程度まで知っている人からすると習得しやすいと思う。 だから検索でひっかかったRubyのプレゼン資料？にある、 「驚き」は少ない方が良い というのは大賛成。

まー、俺はさすがにこれではもう驚かないけどね。慣れてしまったから。 あくまでこれから勉強する人にとってどうだって話でした。 俺にとってPerlを非難する理由はオブジェクト指向がしにくいって点だけ。

まー今日は試験日だったが、やっぱり行かなかった。受けるなら来年ですか。秋はセキュアド？

まー言い訳をすると、Linuxのインプットメソッド作り〜研究室訪問の辺りから まったく勉強してないうえに、その前の段階で午前の範囲の勉強が半分も終ってなかったわけで、 5100円はもったいないがさぼっちまった。

まーさっさとRubyをPerlレベルまで使えるようになりたいのでここんとこRubyに興味があるし、 研究室に読みたいものがいっぱいあるので、ほかのことやってられんよ。 あと1年でなんか成果出したいしね。（そうしないと来年研究室にゴミが入ってくるかも……）

まーそんな感じでRubyなんだが、WebアプリのフレームワークRailsを試そうと思って 見てたがわかんね。日本語の情報少な過ぎ。てことでちょっとわきにそれて ruby-gnomeを 見てみた。これ、思ったとおり簡単にGUIアプリができそうだ。 研究にも使えそうで、カリカリ言語処理やるプログラムのGUIフロントエンドをこれで作れば なかなかいい感じかもしれん。同じ言語で書けるっていうのはいいことだ。

まーあれだ、Rubyより何倍も難解だけどインプットメソッドもやらないとな。 あそこまで調べたんだから、結果を出さないともったいない。

あなたのモテ度はどのくらい？を見て、 俺もやってみた。なーんか無駄にワクワクすっぞー（・∀・）

。・゜・(ノД`)・゜・。 認定された…。

83さんのモテ度は26点です。ランクはEです。（最高：A〜最低：E）

あなたのモテ度採点します Ver.2

E判定なんて大学受験開始時以来だYO！

今、 83さんとおつきあいしたいと思っている人が0人います。

あなたのモテ度採点します Ver.2

（　´∀｀）。o（○人かー、何人かな？　何が入るんだろー、この○には……）

あなたは全くもてないようです。恋愛に向いていない体質のようです。 並の努力じゃ改善されないのでここは思い切って他の対象に目を向けてみましょう。 たとえばペット。良き相談相手として一生つれそってみては？

あなたのモテ度採点します Ver.2

それって……。

RDの話なんだが、 RDをpdfにする方法があったよ。というか、RDをtexにするrd2latexってのがあった。

rd2latexはRDtoolのフォーマットライブラリで、 各種フォーマットライブラリ にある。でもrd→tex→dvi→pdfはめんどっちーので、 例によってこれをシェルスクリプトで楽をする。

追記[2005-04-23]：入力ファイルがShift-JISだとダメだったので、nkfでeucに変更するようにした。 あととっぱらう拡張子が.rdだけだったんで、.*に変更。 存在しないファイル突っ込むとエラーでplatexあたりが止まるので、一応対処。 空っぽのファイルをpdfに変換しようとするやつはもう知らん。 そこまでシェルスクリプトわかんね。

追記[2005-07-29]：タイトルをつけられるようにしたやつに書き換えときますね。（・∀・）つ

#!/bin/bash

if [ $# -gt 0 ]; then

    #ファイルが存在するなら
    if [ -f $1 ]; then

        name=${1%.*}
        texfile=${name}.tex
        dvifile=${name}.dvi
        auxfile=${name}.aux
        logfile=${name}.log

        #texにして
        if [ $# = 1 ]; then
                nkf -e $1 | rd2 -r rd/rd2latex-lib > $texfile

        elif [ $# -gt 1 ]; then
                nkf -e $1 | rd2 -r rd/rd2latex-lib --maketitle --title="$2" > $texfile
        fi
   #コンパイルしてdviを作って
        platex $texfile

   #dviをpdfにする
        dvipdfmx $dvifile

   #途中でできたファイルを削除
        rm -f $texfile $dvifile $auxfile $logfile

    else
        echo "$1 does not exist."
    fi
else
   echo 'Usage: rd2pdf inputfile'
fi

これをrd2pdfという名前で保存して、実行権限を与えてパスの通ったところに。

使い方。

$ rd2pdf hoge.rd

で、hoge.pdfが作られます。

$ rd2pdf foo "わらびもち"

で、「わらびもち」というタイトルが先頭についたfoo.pdfが作られます。

ちなみに入力ファイルの拡張子はなんでもいいです。

RDは書き方のページでも 見てもらうとして、これちょっとした整形文書を書くにはいいかもしれんよ。 文法が簡単だから。texなんて去年の前期にレポートで使ったけど、もう忘れたし。

rd2latexはオプションでタイトルをつけたり、著者をつけたり目次をつけたりすることができる。 てことは、なんとなくこれだけで形になるんじゃないのかね？　 あ、目次をつける時はplatexによるコンパイルが2回必要なので注意。

サンプル作ってみたよ。内容は適当。test.rd test.pdf

昨日との繋がりでRDtool のvisitor.rbのソースを見てたんだが、 そのなかにこんなのがあってRuby初心者の俺は戸惑ったわけね。

class Visitor
     ・
     ・
     ・
    def Visitor.define_visit_Nonterminal(element_type)
      eval <<-END_OF_EVAL
      def visit_#{element_type.id2name}(element)
        apply_to_#{element_type.id2name}(element, visit_children(element))
      end
      END_OF_EVAL
    end

    def Visitor.define_visit_Terminal(element_type)
      eval <<-END_OF_EVAL
      def visit_#{element_type.id2name}(element)
        apply_to_#{element_type.id2name}(element)
      end
      END_OF_EVAL
    end

    define_visit_Terminal(:Include)
    define_visit_Terminal(:Verbatim)
    define_visit_Terminal(:MethodListItemTerm)

    define_visit_Nonterminal(:DocumentElement)
    define_visit_Nonterminal(:Headline)
    define_visit_Nonterminal(:TextBlock)
    define_visit_Nonterminal(:ItemList)
    define_visit_Nonterminal(:EnumList)
    define_visit_Nonterminal(:DescList)
    define_visit_Nonterminal(:MethodList)
    define_visit_Nonterminal(:ItemListItem)
    define_visit_Nonterminal(:EnumListItem)
     ・
     ・
     ・
end

忘れないようにメモっておくんだが、Rubyはclass〜endの中 （でありメソッドや変数初期化の中ではない位置）で クラスメソッドを呼ぶことができるみたいだ （上のソースではdefine_visit_Terminal(:Include)など）。

で、呼ばれるタイミングはそれが書かれているファイルがrequireされた位置だ。 これは以下のような簡単なテストをすればわかる。

#test.rb
#----------
class Test
  @@name = 'noname'

  def initialize(name)
    @@name = name
  end

  def Test.name()
    @@name
  end

  puts '(In Test)' + name()
end

#test2.rb
#----------
require 'test'

puts "kitano"
a = Test.new("shiomi")
puts '(In Main)' + Test.name

$ ruby test2.rb
(In Test)noname
kitano
(In Main)shiomi

見てわかるように、実行しているプログラムは"kitano"を出すことから始まってるのに、 その前にTestクラス内からメソッドが実行されている。

で、初めのプログラムに戻ると、visitor.rbがrequireされたときに define_visit_Terminal(:Include)などが呼ばれ、Visitorクラスのインスタンスメソッドとして visit_Include(element)とかが定義される……ってことになるんじゃないかと。 中身が同じのメソッドを、require時に自動で生成している、ということか。 いや、横着のためにここまでするとは……。

しかし未だにシンボルがよくワカンネ(´・ω・`)

昨日のゼミは発表するという形では初めてのゼミだった。 その中で先生の補足が何度も入ったりしたので、 レジュメ作りについていろいろ考えてみた。 にしても、上の人がいないとこういうことを教えてもらえないから困る。

必要なら教科書の図を使う（レジュメには図番号を）

• わざわざ図を描く無駄をしない
• 説明がしやすい

例をあげながら説明する

• 百聞は一見にしかず

メモ用のスペースを多くとる

• 結構メモすることはある

用語には教科書のページ番号を付加する

• 聞いているほうも参照しやすい

読ませるのではなくて見せる書き方をする

• 内容が見てとれるのがベスト
• プレゼンのような簡潔な記述
• ゼミは朗読会ではない

教科書と同じことは書かない

• 教科書にあることは皆知っている
• 要点を抜き出すこととは違う

教科書で足りないところは補足する

• そこが知りたい

自分なりに章立てや内容をまとめる

• 理解していることをアピール
• 足りない・わかってない点をあぶり出せる