Tweets保存のためのMikutterプラグイン

とりあえずコード

# -*- coding: utf-8 -*-
require 'json'

Plugin.create(:save_timeline) do
  
  logdir = "#{ENV['HOME']}/.mikutter/plugin/save_timeline/log"

  on_update do | service, messages |
    File.open("#{logdir}/#{BOOT_TIME.strftime("%y%m%d%H%M%S")}.#{service.user || "default"}", "a") do |f| 
      messages.each do |msg|
        f.puts JSON.dump msg.instance_variable_get(:@value) rescue puts $!
      end
    end

end

#  on_direct_messages do |service, dms|
#  end

end

プラグインの書き方を調べながら書いた。 色々インスペクションしたので、そこに時間がかかった。内容的には難しくない。

messagesArrayなのだけれど、その各要素はmsg.inspectするとHashに見えるが、実際はMessageクラスのオブジェクトだった。 Messageクラスはその内容をそのまま出力するメソッドがないようなので、msg.instance_variable_get(:@value)の形でデータを取得している。 もちろん、@valueに値が格納されていることを確認するまでが一番手間だった(全体で言えば、Messageクラスであることになかなか気づかなかった部分に時間がかかった)。

JSONライブラリは出力に際して1行にまとめてくれるため、単純に行出力していけば、行単位でパースして処理できるログファイルができあがる。

このあと、flockに対応させた。

ダイレクトメッセージも対応したかったが、on_direct_messagesの取り扱いがよくわからなかったので、そのままにした。

追記

GitHubにてコードは公開中。

Mikutterのプラグインページにも掲載させていただいた。

PureBuilder2 (2)

Kramdown拡張でPDocオブジェクト化

PureBuilder2はもともと思っていたよりもかなり大規模なものになっているが、MarkdownオブジェクトをPureDocと同様に扱えるようにする、というのが今回のテーマ。

例えばテンプレートで

DOC.body

のように書かれている場合がある。この場合は当然、HTMLへ変換したのであればHTML文字列が得られなくてはいけない。 また、

DOC.meta["title"]

のようにもアクセスできる。 それだけなら単にアクセッサを拡張してやればいい話なのだが、PureDocオブジェクトはTOCのためのループ機能が組み込まれている。 これにより章立てをループさせることができ、簡単に任意の形式でTOCを組める。 これはどうしてもパース時に情報を取らなくてはいけない。

もし、HTMLに出力するものである、というのであれば、単純に結果のHTMLをパースして取得する方法もある。 だが、KramdownライブラリはLaTeXとPDFをサポートする。PureDocもゆくゆくはLaTeX形式での出力をサポートする予定である。

であれば、やはりKramdownでのMarkdownパース時にTOCを作りたい。

基本的な方針としては、実際にPureDocオブジェクトを使用する。 これはパーサ/コンバータを含まないベースクラスで、本来は直接このクラスのインスタンスを生成することは想定していなかった。 だが、外側から使用するメソッドは一通り持っており、インターフェイスは揃っている。

DOC.bodyで返すべき@bodyDOC.body=を用いて入れ、DOC.metaに関してはPureDocクラスが持っている機能によってドキュメントから取り込むといったことが可能。 そのため、DOCPureDocインスタンスであり、Kramdownの結果はDOC.body=によって入れるだけだ。

だが、DOC.stock_ehaderを用いてヘッダを入力し、TOCを生成できるようにしなければいけない。 そこで、Kramdownに手を入れる必要があった。

ソースコードを追っていったが、結局Kramdown::Parser::Kramdown#new_block_elをオーバーライドするのが良いと分かった。 ヘッダを取得するパートはあるが、new_block_elメソッドはメソッド自体が短く、あくまでパース時に各エレメント対して呼ばれるものだ。何のために呼ばれているかを判定する必要もなく、引数を丸々渡すだけで良いため、overrideしやすかった。

require 'kramdown'

# Override Kramdown
class Kramdown::Parser::Kramdown

  alias _new_block_el_orig new_block_el
  

def new_block_el(*arg)

   	if arg[-1].kind_of?(Hash)
    
      case arg[0]
      
      # Is Header?
      when :header
        p arg[-1][:level]
        p arg[-1][:raw_text]
      end
      
    end
    
    _new_block_el_orig(*arg)

end end

p Kramdown::Document.new(ARGF.read).to_html

というテストコードを書き、実際に動作することを確認、when :header部分を

::DOC.stock_header(arg[-1][:level], arg[-1][:raw_text])

と書き換えた。

KramdownはPure Rubyで書かれているため、扱いやすいし、ソースコードを書くのも楽だ。 だが、できればサブクラス化するなど、もう少しスマートな方法でできればよかったな、と思う。クラスが細かく分割されて連携しているため、置き換えるのはかなり難しいと判断した。

Kramdownは非常に良いライブラリなのは間違いない。

forkの代わりに

RubyのKernel.forkをはじめとするfork機能(例えば、IO.popen-を渡すことを含む)はWindowsでは動作しない。 Perlerだった私としてはこれはかなり不満な点だ。Perlはコミュニティの努力により、forkがWindows上で動作する。これは、Windows版Perlではforkをエミュレートするためだ。

今回は、設定やドキュメントオブジェクトなどをセットアップした状態で、forkによって環境を独立させたいと考えていた。 これはグローバルなオブジェクトに変更を加えるためであり、また出力先の制御をSTDOUT.reopenによって行うことができるかということについて考えていたためだ。

RubyのforkとWindowsについて検索すると、「forkは邪悪だ、threadを使え」という内容があふれる。 だが、今回は並列化のために使いたいわけではないため、Threadは用を成さない。

また、大量のドキュメントを変換する際のオーバーヘッド低減という目的もある。

Unicorn(Webアプリケーションサーバー)がこのforkによるCOWを活用した設計となっている。Unicornはどうしているのかと調べてみたら、UnicornもMongrelもWindowsでは動作しないらしい。

というわけで、forkの利用は諦めて、グローバルな名前に対する変更をいなす方向とした。

グローバルな名前のオブジェクトが変更されるのは、ほとんど

DOC.is {
...
}

という書式で記述するためだ。 これはPureDocドキュメントを分かりやすく記述するためであり、実際にテンプレートもDOCオブジェクトを利用したデザインとなっている。 つまり、DOCはthe PureDoc objectであることを期待している。

この設計を維持するため、Delegateライブラリを使用することとした。 実体はDOCではなく、DOCはただのDelegatorというデザインだ。これはDOCに実体はなく、ただの代名詞となるわけだ。

DOC = SimpleDelegator.new(nil)

とすることにより、まずDOCという名前を用意しておく。 実際に新しいドキュメントを生成する場合は、

::DOC.__setobj__ @@config[:puredoc_class].new

のようにする。 これにより、DOCが意味するドキュメントを入れ替えることができ、DOCを変更しても、変更されるのはDOCではなく、移譲されているドキュメントであり、DOCをまた新しいドキュメントにすることもできる。

PureBuilder2

PureBuilder2とは

PureBuilder2は現行のPureBuilderを置き換える新しいサイトビルドツールだ。 コマンド一発でウェブサイトの更新が可能になる。「動的生成の事前作業化」が可能となる。

PureBuilderからの主な変更点は次の通り

  • Rubyでの実装 (Windowsで動作可能に)
  • MarkdownとeRuby対応

変更点は少ないようにみえるが、PrueBuilderとは互換性はないし、コードも新規に起こす。

Markdownへの対応

Markdownへの対応はKramdownライブラリを使用した。 非常に使いやすく、問題はないように見えた。 何を何に出力するかは、指定クラスの入れ替えによるポリモーフィズムによる。

このラッパークラスはごく簡単だと思ったのだが、そうはいかなかった。

現状、PureDocはライブラリであり、ドキュメントがRubyコードである。 これを出力するためのユーティリティはZshスクリプトになっている。

PureBuilderはその多くをPureDocに依存している。 PureBuilderが直接に依存していなくても、テンプレート側はPureDocオブジェクトを触れることになっているし、現状テンプレートを呼ぶところまでがPureBuilderの仕事なので、当然テンプレートではドキュメントを出力するために、PureDocオブジェクトを必要とする。

だが、当然ながらKramdownオブジェクトはPureDocオブジェクトと互換性がない。 機能を維持するためには、単にKramdownを呼び出すラッパーではなく、Kramdownを内部で使うPureDoc互換クラスが必要となる。

予定とは比べ物にならないほど大変な作業だ。

PureDocのインターフェイス

加えて、今のところPureDoc Translatorが保持している機能については、PureBuilderから使用することができなくなる。 旧来のPureBuilderは、コマンドとしてPureDoc Translatorを呼んでいたため問題がなかったが、ライブラリとして使うとTranslatorは使えない。

PureDocにその機能があるにはかかわらずPureDocに組み込まれていないのは、PureDocの仕様によるものだ。

PureDocの

##-----
...
##-----

という形式でYAMLをヘッダーとして埋め込めるという仕様は、PureDocにはないが、便宜上の拡張としてTraslatorにあり、PureBuilderはそれを前提として使用する。

これをPureDocに組み込むのであれば、PureDocクラスにその機能をいれてしまえば良い。 要はこの仕様をPureDocに取り込むか、PureBuilderに取り込むかの話なのだが、おそらくはPureDocに取り込むのが妥当なところ。

一方同じようにこのヘッダを取り扱いながら、ヘッダにLast UpdateとSinceを書き込む機能があったりするが、これはあきらかにPureDocではなくPureBuilderに実装されるべき機能だ。

一応、いまのところ次の方針を考えている。

  • meta取り込みはPureDoc#read_meta(text)で行う。このヘッダはコメントになっているので、テキストを与える必要がある。これはPureDocライブラリが勝手に実行することはない
  • PureBuilderはpuredoc.metaによりsincelast-updateを確認し、ない場合は追記する

PureBuilder2のおおまかなモデル

purebuilder本体はRubyライブラリとなり、基本的には各ディレクトリの.rebuild_rulesまたは.up*ファイルが処理手順となる。

これらをまとめて呼ぶためのスクリプトが、purebuilder.rebuildallになる。

対象ファイルに対して

PureBuilder.build(file, outputdir, extname)

とすることでビルドできる形だ。

インタープリタ起動役は

rebuildallでrebuildスクリプトのインタープリタは拡張子によって判断するが、拡張子がない場合はperlを使う。

これは、perlはshebang行を解釈するためだ。この機能はsh/bash/zsh/rubyにないことを確認している。 Perlは「Shebangを解釈できないダメなシェルに代わって」起動するそうだが、どうやらLinuxが解釈するだけで、シェルに解釈を期待するのは厳しそうだ。

MailDeliver2 : 完全にプログラマブルなフィルタ機能を持つMDA

MailDeliver2がついに完成した。 おおよそできてはいたのだが、テストできておらず、テストしたらまだまだ足りない機能があることに気づき、 また不完全な部分が多かったため、2日かけてデバッグ、テスト、修正を繰り返した。

概要

保存・配送

Mail Deliverは完全にプログラマブルなフィルタを持つMDAと、それを補助するユーティリティ群である。 フィルタ、ソーター、通知の基本機能を備える。

基本的にはLinuxあるいはUNIX向けで、MH形式のメールフォルダに対して保存することになっている。

localdelivがMDAだ。その役割としては、フィルタを呼び出し、フィルタに従って処理することにある。 フィルタはメールの保存の機能を兼ねる。もしフィルタがメールを保存も破棄もしなかった場合は、localdeliv自身がデフォルトのメールフォルダへと保存する。

デフォルトのメールフォルダもフィルタ同様の方法で決定することができる。 MailDeliver2はRubyで書かれており、保存先メールフォルダの決定はRubyのprocオブジェクトによって行われる。このprocオブジェクトにはメールのヘッダの情報に加え、それを取り扱いやすくした情報を加えたメールオブジェクトが渡される。 そのため、静的な文字列ではなく、より動的に保存先を決定することができる。 ほとんどの場合、これで事足りるだろう。

例えば、設定サンプルでは次のように書かれている。

DefaultRule: ->(mail) { "inbox/address/#{mail.in || "Default"}/#{mail.domain || mail.address }/#{mail.address}" },

これはつまり、

inbox/address/<ユーザーのアカウント名 | Default>/<相手のドメイン名>/<相手のメールアドレス>

というフォルダに保存される、ということを意味している。 多数のメールアドレスを使用して使い分けている人は、そのメールアドレスによって相手の意味は既に分かれているだろう。まず、自分のどのアカウントに送られたものかをフォルダで分けてしまうことで相手を分類でき、この3段階の分け方があれば「だいたい分かる」。

ちなみに、副次的な効果として、詐欺にひっかかりにくくなる。受け取りアドレスとドメインを必然的に意識するからだ。 メールの「名前」をAmazonにしてお知らせを装った詐欺メールを大量に受け取っているが、ドメインがAmazonでないためすぐ分かる。 銀行関連もすぐわかるだろう。なぜならば、名前はメールを開くまでわからないが、アドレスは到着した時点から既に意識しているからだ。

フィルタは完全にプログラマブルであり、Rubyで自由に書くことができる。 もちろん、保存と破棄はよくある処理なのでそれを助ける機能がある。

さらに、保存してそのメールの処理を完了するかどうかは自由に選べる。 例えば複数のフォルダに保存するとか、特別に直ちに通知するとか、あるいは保存はするけれど通知の対象からは外す、ということも可能だ。 destroymail()は通知のためのファイルを削除するため、savemail()のあとdestroymail()すると通知はされない。

フィルタは条件自体がプログラマブルなので、例えば差出人によってのみ判定できる、というようなことはない。条件に単にtrueと書けば、常に適用されるフィルタが書ける。 現在デフォルトではclamAVしかサポートしないが、もっと強力な何らかのフィルタによって判定することもできる。その場合は、その判定処理を条件式に書けば良い。条件式に渡されるメールオブジェクトから完全なメール本文を得ることも可能で、IO.popen$?を用いて外部プログラムを条件として使用できる。

そのためにルール記述がやや難しいことは否定しないが、最低限であればマニュアル通りに記述することで、常識的に判断できる人ならば動かすことはできるだろう。

通知

通知機能はプラグイン方式を取っている。

そのため、して欲しい通知方式を好きに組み合わせることができる。 現在はnotify-sendを用いたGUI表示機能と、play(SOX)を用いた音声通知機能を備える。

ディスプレイ表示機能はプログラマブルではない。選択式だ。 「アドレス」または「Fromの値」のどちらかで、各差出人あたりの通数か、 または総数を通知する。

音声通知機能はプログラマブルだ。 音声ファイルは静的に指定しなければならないが、適否に関してはProcオブジェクトなので、その気になれば判定とは関係のないプログラムを書くこともできる。

その重要性は、アドレスのマッチングにしても

  • 完全一致
  • case insensitiveな一致
  • Glob
  • 正規表現

とそれらの否定から選べることにある。また、論理和、論理積も使用可能だ。 一致だけでは大量のルールを書かなくてはいけない場合に、同じファイルを再生させる場合も楽になる。 設定ファイルの中でインスタンス変数を定義しておくことで、例えば複数のアドレスをマッチさせる、というようなことも可能だ。 マスター設定ファイル内でアドレスごとのグループを設定しておくこともできる。

何がしたかったかというと、「ケータイメールのような使い心地」だ。 ケータイならば、着信音で相手が分かる。通知で、メールを開かなくても誰から来たかも分かる。 「着メロ」機能があるMUAは極めて少ない。着メロ機能と強力な振り分け機能を兼ね備えるものはない。 そもそも、振り分けのルール記述が極めて面倒だ。

そのような、大量のメールを受け取る人が、効率的にルールを書くことができ、メールを確認したり処理するための効率を大幅に向上させる、画面にかじりついていなくても、その時がきたことをアクティブに教えてくれる、という使い心地を、MUAではなく、MDAで実現した形となる。

1からの変更

まず、完全にRubyになった。 フルプログラマブルにするために、今まで開発効率からZshを使用していた部分に関しても、全てRubyとした。外部プログラムでなく、ライブラリの呼び出しとすることで、連続したマッチングも高速化でき、また渡せる情報も大幅に増えた。

一部手段としてUNIX系OS固有のものを使用しているが、恐らくWindowsに対して移植可能なものになったというのもメリットだろうか。 問題はKernel.forkを使用していることと、playコマンドやnotify-sendを使っていること、Sound Notifyはログを/dev/nullに書いていることだろう。

当然、このこととセットになって、よりプログラマブルになった。 そもそもの出発点が、フィルタが保存する内容には関与できない(保存するフォルダを出力するだけだったため、必ず保存されるし、保存内容を加工することもできない)という点が要求を満たさないケースがあったことについてだ。

これに対応したため、メールの破棄や、保存内容の加工も可能になった。 メールオブジェクトがメール全文を持っており、それがそのまま書き込む内容でもある。 メールを破棄した場合は、通知にも残らない。

構造がすっきりして、手を加えることもしやすくなった。 これまで通知系はプログラム自体を変更して、手元で専用のものにしていたが、汎用性があるものとなり、 単にプラグインフォルダに入れているものが適用されることとなった。

このあたりは、自分用だったものが、使ってもらうことを考えた変更が加えられたといっていい。

このほか、開発効率を優先して非常に複雑な構成(トリッキー)だったプログラムが、しっかりと設計されたものに変更されたため、挙動を把握しやすく、プログラマブルな部分がちゃんと活かせるようになった。 従来はフィルタが動くはずのものを書いても動かないことが多く、デバッグも難しかった。 今回はデバッグしやすいようにログもわかりやすいしてある。 これは、プログラマブルなためにユーザー定義部分でプログラムのエラーがでる場合が多いからだ。

プログラム

見どころは多いが、いくつか紹介。

プラグイン

単純にロードしているが、

class StandardNotify
  PLUGINS = []

と名前に約束を作り、プラグインは自身のオブジェクトをStnadardNotify::PLUGINSにpushする。 プラグインはfireメソッドをインターフェイスとして義務付けられている。

メールの準備

ヘッダとボディは次のようにして取得。

head, body = NKF.nkf( "-w -Lu -m", mailstr ).split(/\r?\n\r?\n/, 2)

ヘッダは次のコード

    head.each_line do | l |
      if l =~ /^\s*$/
        break
      elsif l =~ /^\s+/
        headerlines.last.concat(l.lstrip)
      else
        headerlines.push(l)
      end

    end
    
    headerlines.each do |i|
      if i =~ /\A([-_A-Za-z0-9]+)\s*:/ # match header format?
        mailobj[$1.upcase] = $'.strip
      else
        next
      end
    end

caseやspaceなどを守らない変なメールに対応するための措置を取っている。

メールアドレスの抜き出し

恐らく最もテクニカルだ。

  def extract_addr(f)
    if f =~ /(?:[^"<]*(?>"[^"]*"))*<([^>]+)>/ # Do From term have NAME<addr> format?
      address = $1.delete("\" \t/")
    else
      address = f.delete("\" \t/")
    end
    
    address
  end

単に仕様だけでなく、実際に使われている形式に則っている。 アドレスをクォートしているものに対しては対応しない。

メール方向の判定

    if @maildeliv_conf[:MyAddress].any? {|k, v| in_k =k; File.fnmatch(v, from) }
      mailobj.direction = :send
      mailobj.address = to
      mailobj.in = in_k
      
    elsif @maildeliv_conf[:MyAddress].any? {|k, v| in_k =k; File.fnmatch("*" + v + "*", mailobj["TO"]) }
      mailobj.direction = :recieve
      mailobj.address = from
      mailobj.in = in_k
      
    else
      
      mailobj.direction = :unknown
      mailobj.address = from
      mailobj.in = nil
    end

fromtoもアドレスを抽出したものだ。 差出人アドレスがマイアカウントとして定義されたものと一致するか?をチェックしている。 ちなみに、Toは単一とは限らないので、Fromを先に判定するのが確実で好ましい。

Linux Tips

YouTubeのプレイリストからタイトルを抽出する

結局使わなかったのだが、ワンライナーで書いた。 比較的素直なHTMLなので解析は簡単。行指向ではないので、PerlでなくRubyにした。

$ curl 'https://www.youtube.com/playlist?list=<playlistid>' | ruby -e "s = STDIN.read" -e 's.scan(/<a class="[^"]*pl-video-title-link[^"]*"[^>]*>(.*?)</m) {puts $1.strip }' | grep -v 動画は削除されました

ffmpegでh.264/aacな360pのmp4を

元動画は1080pのmovまたはmp4。 オーディオはいじらず、元々aac(ac3)。

$ ffmpeg -i <infile> -vcodec libx264 -s 640x360 -crf 34 -strict -2 <outfile>.mp4

ちなみに480p(16:9)は720×280。 -crfの値は18-28が推奨されている(小さいほど高ビットレート)が、今回はモバイル向けなので34を指定。

なお、6の増減でビットレートはおよそ1:2の変動となる。

ffmpegでCowon M2向けの動画を作る

COWON M2はXVidとmp3のAVI動画で、解像度は320×240またはWMVをサポートするとある。

WMVだと結構サイズが大きいので、AVIで作る。 ソースは前回と同じくh.264*ac3のMOVまたはh.264*m4aのmp4。

$ ffmpeg -i <infile> -vcodec libxvid -acodec libmp3lame -b:v 372k -b:a 128k -s 320x240 <outfile>.avi

随分としょぼい解像度の上にアスペクト比も壊れる(プレイヤー側で調整することは可能)が、案外見られる。 ただし、360pでも細部は潰れてしまっているのでよく分からない部分は出てしまう。

XineのUIの文字化けを直す

fontにHerveticaを要求しているので、フォントエイリアスを設定すれば良い。

ネストされた構造のためのPureDocのTOC展開

ネストTOC機能

文書からTOCを作る上で、やはり構造的にネストしたいことはあると思う。 最もポピュラーなのは、ulをネストさせることだろう。

だが、難しいのは、例えば最初にh4が来て、次にh2が来て、などということがありうるのだ。そして、h3は存在しないかもしれない。

間の全てのレベルが存在することにするのか。順に礼儀正しく登場すると仮定していいのか。

結局だが、汎用性のある仕様として次のようにした。

  • 最低レベルはオフセットかまたは実際に使われた最も大きいヘッダーに基づく(数え方としてはmin)
  • レベルの変遷に応じて変遷分proc4openproc4closeを呼ぶ。例えば->(l, ol) { "<ul>" }のように書く。
  • 当該レベルまではopen/closeした後はproc4eachを呼ぶ。

    def nest_expand(proc4open, proc4close, proc4each, offset=nil) result = [] mi = self.min { |i| i.level } or return nil mi = mi.level

     if ! offset.respond_to?(:to_int) || offset > ( mi - 1 )
             offset = mi - 1
     end
    
     cur = offset
    
     self.each do |i|
         if i.level > cur
             (i.level - cur ).times {|n| result << proc4open.call( ( i.level - (i.level - cur - 1 - n) ), ( i.level - offset - (i.level - cur - 1 - n) )) }
         elsif i.level < cur
             result << (cur - i.level).times {|n| proc4close.call( (cur - n), ( cur - n - offset ) ) }
         end
    
         result << proc4each.call(i.level, (i.level - offset), i.title)
    
         cur = i.level
     end
    
     result.join

    end

eRubyでは内部のメソッドがputsすればいいような言い方をされることが多いが、それは先に出力されてしまっていたので、置換できるようにするために一旦配列に格納した。

テンプレート側の記述量が多く、また直感的でないというデメリットはあるが、なんとかうまく処理できた。

instance_evalと定数

しかし、むしろ苦戦したのは、ProfileでTOCを含めることだった。

Profileは基本的にそれ自体がPureDocを拡張したRubyコードである。

文章としてヘッダーを含めているわけでもないので、TOCを作るためのとっかかりがないのだ。

そこで結局は

  • テンプレート側でテーブル手前にリンクを貼る
  • profileであとから各カテゴリをヘッダとして登録する

という方法を取ったのだが、意外な理由でうまくいなかった。 というのは、

instance_evalで評価した場合、そのコンテキストが認識する定数にアクセスできない」

のだ。PureDocはソースをObject#instance_evalを使って解析するため、この問題にひっかかっってヘッダーの登録ができなかった。

そこで、PureDocに登録用のメソッドを追加することとなった。

簡単に書いているが、profileは整頓されていない部分が多く、結構大変だった。

Rubyのサブクラス内のスーパークラスのネストされたクラス

意味が分からないと思うが、ちょっとした疑問だ。

class A
  class B
  end
end

Class AA < A
  B
end

このコードではAAの中のBA::Bになる。 つまり、AAのコンテキストの中でBは使用可能だ。

class A
  class B
    def hi
      puts "Hi"
    end
  end
end

class AA < A
  class B
    def hihi
      puts "HiHi"
    end
  end
  
  def initialize
    @b = B.new
  end
  
  def b
    @b.hi
    @b.hihi
  end
end

aa = AA.new
aa.b

このコードでは

class AA
  class B
  end
end

AA::Bが作られ、@b#hiがないためエラーとなる。

class A
  class B
    def hi
      puts "Hi"
    end
  end
end

class AA < A
  class B < B
    def hihi
      puts "HiHi"
    end
  end
  
  def initialize
    @b = B.new
  end
  
  def b
    @b.hi
    @b.hihi
  end
end

aa = AA.new
aa.b

この場合は、

class B < B

によって、A::BをスーパークラスとするサブクラスAA::Bが作られる。

この定義によってBという名前がオーバーライドされることとなる。

class A
  class B
    def hi
      puts "Hi"
    end
  end
end

class AA < A
  B = B
  class B
    def hihi
      puts "HiHi"
    end
  end
  
  def initialize
    @b = B.new
  end
  
  def b
    @b.hi
    @b.hihi
  end
end

aa = AA.new
aa.b

これが本来意図するところだ。 オープンクラスを用いてスーパークラス内で定義されたクラスを拡張したいのだろう。

そこで

B = B

によって

AA::B = A::B

とした上でクラスを開けば良いのだ。

だが、今回の場合はPureDocのために実験した。PureDocではサブクラス内での#instance_evalによって評価された時に呼ばれるメソッドが名前でこのクラスのインスタンスを生成するため、あくまでもサブクラス(AA相当)の中に閉じ込められたクラス(B)でしかない。

ということは、そのクラスは

AA::B = A::B

ではなく

AA::B < A::B

であることが本来望ましいのではないだろうか。

PureDocのTOC機能

PureDocにTOC機能をつけた。

これまでPureDocで生成されたドキュメントにはドキュメント内リンクのためのID振りがなかった。

そのため、長文になると結構たどりにくい。 また、文書を参照してもらうのが難しかった。

そこで暫定的にHTMLに直接IDを書いたあと、更新に備えてその機能を急造した。

今回はかなり書き直した。 ヘッダー関連のメタメソッドを書き換えただけではない。 専用のクラスまで書き足した。

TOCクラスはStructだが、TOCContainerArrayのサブクラスとなっている。 これは、TOCを作るためにストックされたヘッダ情報を展開するためのメソッドをもたせるためだ。

だが、ネストした構造(例えばリストでネストさせる)のTOCを作るための展開用メソッドはなかなか作れない。

必ずしもh1から順にあるわけでもなく、例えば

h3->h4->h2ということもありうる。 ネストした状態でこれを処理するのはかなり難しい。徐々に深くなる前提にしてしまわない限りどうやって開き、どうやって閉じるかは難しい。

とりあえず単純にインデクシングのためのヒントと共にイテレータを回す構造としたが、 インデックスの1増減の問題が激しく大変だった。

既にReasonsetのサイトは適用されている。まだ整頓されていない状態だが、あまりにも使いやすかったため、実際に全体に取り入れてしまっている。 ただし、IDの付け方は将来的には変更されるだろう。現在のままではコンフリクトする可能性が高い。

PureDocの変更によって実装された(ReasonSiteでの採用はテンプレートも編集された)ため、既にGitHubには変更が反映されている。

Markdownにまつわるもろもろ

Markdownで書くということ

Markdownはもうだいぶ普及している形式だと思う。

様々なマークアップ言語や記法がこれまで発達してきた。 それは例えばWikiであったり、plain2だったり、textileだったり、 場合によってはRDocだったり。

しかしながら、そのいずれもそれほど普及しなかった。 だが、Markdown記法はもはやスタンダードとも言うべき普及を見せている。

PureDocは当初、Markdownのような形式をとっていた。 実際に正規表現パーサだった時期もあるし、もう少し発展してZshの内部DSLだった時代もある。

この目的はHTMLと印刷用フォーマットの両方を生成するドキュメントメタフォーマットで、 かつHTMLと比べ簡潔に記述できるフォーマットを求めていた。

その要求を満たしてくれるのだ。 現在はPureDocはReasonSetに特化した多彩な機能を持つためMarkdownに乗り換えるということはしないが、 多くの場合Markdownで事足りるのも事実だ。

Markdown Editor

Markdownは普及している分、専用のEditorが多く存在する。 単に強調表示や入力支援があるだけでなく、リアルタイムで表示を確認できる。

主要な候補となるのは

  • Markdown#Editor(Windows)
  • Remarkable(Linux)
  • CuteMarkEd
  • Haroopad

の4つであるようだ。

Markdown#Editorに関しては表示領域がマッチしないことが多く、 いまひとつ使いにくい。この問題はCuteMarkEdでも生じる。

Haroopadはクロスプラットフォームで、最初はフォントに違和感があったが、 CSSによってフォントを含め見栄えを指定することができる。

Haroopadの弱点は、改行を反映してしまうことだろう。 だが、全体にはスタイリッシュで見やすく使いやすい。 ドキュメントの動的なリロード機能がないのと、Donateのバルーンがちょっとしつこいのは残念。 だが、Windowsではこれを使っている。 基本的に表示位置は狭い画面ではエディタ側の入力位置を上のほうにもってくると適切に表示してくれる。

Haroopadの欠点として、Fcitxで入力できなくなることが結構あるというのもある。 この対応として、入力のない、空のHaroopadを立ち上げておくと入力できるようだ。

RemarkableはUbuntu的なUIを持つ。 使いやすいといえば使いやすいが、D&Dによって開くことができないため、ファイル操作がちょっと面倒。

おもしろいのが、Remarkableはビューワがめいっぱい上までスクロールすると下にループする。下はしない。

またエクスポート機能もあり、CSSにも対応する。 今のところ最も安定しているということもあり、LinuxではRemarkableを使用している。

Remarkableで記述する場合は、エディタの記述部分を上のほうになるようにするか、めいいっぱい下にすると適切に表示される。 当然ながら、中途半端で適切に表示されない位置はどうしても生じる。

だが、なるべくならどのエディタも最も下に書いていくのが良いようだ。

Markdownで既存のテキストを引用する

HTMLを含め引用はpreされるべきではないかと思うのだが、そうなっていない。 プレーンなテキストを引用するには、次のようにすると良いようだ。

sed -i "s/\(.*\)/> \1\n> /" file

sedの出力は改行を伴うので最後には改行はいらない。 段落を分けてもらう必要があるため、空行を入れておく。 ちょっと複雑だ。

MarkdownをPureBuilderに取り込み

Markdownのほうが楽に、適切に書けるケースが多いようなので、MarkdownをPureBuilderの一部として取り込んでみた。

とりあえずblog用で、変換にはpandocを使う。 これはいずれPureBuilderの一部となる。

ちなみに、今回コードの埋め込みは次のようにした。

sed "s/\(.*\)/\t\1/" ~/local/devel/reasonset_builder02/scripts/md_processor.rb >| ~/tmp/out

主な動作としては、PureDoc同様のヘッダの取り扱いと、 pandocからbodyだけを切り出すことである。

#!/usr/bin/ruby
# -*- mode: ruby; coding: UTF-8 -*-

require 'yaml'

module YEK
  class ReasonBuild

#=NAME
#
#ReasonBuild MD Processor - PureBuilder script for Markdown file.
#=SYNOPSIS
#
#  md_processor.rb [ _file_ ] [ -- _pandocoptions_ ... ]
#
#=DESCRIPTION
#
#MD Processor reads ARGF and process with pandoc.
#
#If +-s+ any _file_ given, MD Processor understands header with same style as PureDoc,
#modify timestamp, and write out to given _file_.
#
#If pandoc options given, MD Processor invoke pandoc with these options.
#Otherwise, MD Processor invoke pandoc 
#
# pandoc -t -s -p
#
    class MDProceessor
      
      def proc_header(file=nil)
        @file_content ||= ARGF.read
        # Any file given?
        if file && @file_content =~ /^##--.*$/ && $' =~ /^##--.*$/

          begin
            yax = $`.each_line.map {|i| i.sub(/^# /, "") }.join
            header_meta = YAML.load(yax) || Hash.new
    
            # Is Header missing last-update or since?
            if  ( ! header_meta.key?("last-update") ) || ( ! header_meta.key?("since") )
                
              now = Time.now
            
              modsince, modupdate = nil, nil

              # Set to since
              if ! header_meta.key?("since") 
                modsince = true
                header_meta["since"] = now
              end
            
              # Set to last-update.
              if ! header_meta.key?("last-update") 
                modupdate = true
              end
            
              # OK, Header is ready.
              # Open the file!
              File.open(file.first, "r+") do |f|
                content = f.gets(nil)
            
                if content.sub!(/^##--.*?^##--.*?$/m) {
                  el = $&.each_line.to_a # Get header texts.
                
                  el.insert(1, "# since : #{now.strftime '%Y-%m-%d %H:%M:%S %:z'}\n") if modsince # Add since if since was not exist.
                
	          # Update last update time if last-upadte is not set or last-update is older than mtime.
                  el.insert(1, "# last-update : #{File.mtime(file.first).strftime '%Y-%m-%d %H:%M:%S %:z'}\n") if modupdate# Add last update timestamp 
              
                  el.join
                }

                  # Write to file if updated.
                  f.seek(0)
	          f.truncate(0)
	          f.write( content )
                end
              end # Close file.
            end # Missing header
            
          rescue # YAML or IO Rescue.
            STDOUT.puts $!
          end
          
        end # file given.
      end #proc_header
      
      # Invoke pandoc, format, and out.
      def pandoc(options)
        
        outstr = nil
        
        # filter pandoc.
        IO.popen(( ["pandoc"] + options ), "w+") do |io|
          io.write @file_content
          io.close_write
          
          outstr = io.gets(nil)
        end
                                                  
        # subscribe content
        flag = false
        outstr = outstr.each_line.select do |line|
            
          if line =~ /^<\/body>$/
            flag = false
          end

          if line =~ /^<body>$/
            flag = true
            next false
          end
            
          flag
        end.join
        
        return outstr
        
      end
      
      
      def initialize
          
        pandoc_opt = nil
        
        # Get pandoc options from argv.
        if sep = ARGV.index("--")
          pandoc_opt = ARGV[(sep + 1) .. -1]
          ARGV.pop
        else
          pandoc_opt = [ "-t", "html", "-s", "-p" ]
        end
        
        proc_header( ( ARGV.empty? ? nil : ARGV.dup ) )
        
        doc = pandoc(pandoc_opt)
        print doc

      end
   
    end #MDProceessor
    
  end
end

YEK::ReasonBuild::MDProceessor.new

PureDoc:インデント機能、段落字数制限機能

段落字数制限

きちんと章立てせずにだらだら長い文章を書くことを抑制するために、指定した文字数を超える連続する段落がある場合警告する機能を搭載した。

通常、段落はブロックによるan Arrayであるので、マークアップではなくPureDocクラスで面倒をみることにした。

# Paragraph element.
# For notify length for too long flat text.
def p(*text)

text = block_given? ? yield : text

if @par_length_limit

if text.join.length < @par_length_limit
STDERR.puts "*WARNING : A single paragraph is too long (#{text.join.length} characters.)"
end
end

return text

end

基本的な値の取得も面倒を見るようになった。

制限文字数はユーザーが@par_length_lumitを設定する。設定しなければ機能しない。

インデント

HTMLでの出力を基本としてきたため、いままで改行すら入れていなかったが、ちょっとひどいのでインデントも入れることにした。

インデントの考え方としては、reading spaceを含めタグで始まる行をインデントする。このため、ネストしているものはこのインデント処理が複数呼ばれることになり、うまく処理できる。また、codeなどについては触らないようにできる。

改行については各エレメントのフォーマッタで面倒をみる。といっても、大半はstdメタメソッドで作られているので触るところは少ない。さらに、stringifyメソッドによってインデント処理とともにString化も行う。これにより、各エレメントは必ず文字列を返す、という仕様に統一された(これまでは文字列または配列を返していたが、Array#to_sが変更された現在、その仕様は不適切となった)。

ちなみに、stringifyに渡されてくる時点では文字列か配列かが確定できないので、これを処理して一旦文字列にしたあと(改行処理もする)、String#each_lineでインデントしてから、配列をまた文字列にしている。アルゴリズムとして効率はよくないが、開発を優先した。

ちなみに、インデントは@indent_spacesにセットするか、もしくは$puredoc_indent_spaces環境変数にセットすることでコントロールできる。デフォルトはタブ文字ひとつである。

これに伴って、要素はインラインかどうかを判定するためのキーワード引数が追加された。