netail.net

_ [ツール] Graphviz の巨大な出力を TeX に貼り込むとき ▲

どうも図が途中で途切れてしまうことがあったのですが，dvipdfmx を使ってる場合，Graphviz の出力オプションを -Tps → -Tps2 （PDFに変換することを仮定したPS）としてやったら直りました．このオプションでの出力ファイルの違いは，追加でページサイズ情報を埋めるかどうかだけのようです．これで常にうまくいくのかどうかは分かりません．

横長の図のときは，その結果をrotateboxを使って回転させてやります．

\begin{figure}[p]
\begin{center}
\rotatebox{90}{\includegraphics[scale=0.08]{foo.ps}}
\caption{Caption}
\label{fig:}
\end{center}
\end{figure}

_ [hyCalendar] hyCalendar の要望リストを更新しました ▲

hyCalendarの変更要求リストを，アクティブな要望，保留したもの，もう済んだものを別表に分けてみました．

アクティブな要望の「リリース予定」なものは，既に実装が終わってるものです．先日メールでいただいた「違う月の日祝日の色」も入ってます．

あとはタスクトレイ関係にかかる時間にもよりますが，２月中にはリリースすると思います．

_ サイト移転から一年経過 ▲

ということで，久々にアクセス解析の結果を見てみました．

過去６ヶ月でこのサイトへアクセスしてきた人の検索キーワード上位３位は，バラモス 826回，アスペクト指向 717回，レーサーミニ四駆 650回で，バラモスが１位でした．何を探すためにバラモス単独で検索するのかは少し気になります．

アクセス数のほうは，１日平均1000visitsぐらいと，それなりのペースで安定してます．

ヒット数は，１ヶ月15万ぐらいで推移してたんですが，baiduのクローラが１月になって急に大暴れしていました．11〜12月は月に５千アクセス程度だったのが，１月になって約10倍の５万アクセス，２月は最初の２日だけで６千（約10万ペース）と，急増していました．baiduのＱ＆Ａにある「自動的にサーバーの負荷能力によって、アクセスの密度を調整しています」という表記が，「サーバが余裕ありそうならがんがん負荷を上げていきます」という意味なのかと疑いつつ，こちらのサイトの .htaccess 記述を適用しました．

_ [hyCalendar] 起動速度の計測結果 ▲

要望がけっこうたまってきたので，次のバージョンに向けて，ぼちぼち作業を開始しました．こまめにリリースにするか，まとめてからリリースするかはちょっと悩んでます．

そういう作業をしつつ，現在の性能はどんなものかと気になって，ProDelphiを使って計測してみました．Pentium M 1.73GHz のノートPC上で，開発中の版に80KBぐらいのファイル（私が使ってるスケジュールデータ）を読ませてみたところ，起動に使う時間はだいたい250msぐらいのようです．時間の内訳は，ファイル読み込み，iniファイル読み込み，ウィンドウ生成でほぼ三等分で，ボトルネックになるような関数は特に見当たりませんでした．なので，これ以上はあまり性能向上はしないと思います（タスクトレイ常駐という手段は別として）．

なお，上記の数値はわりと最速の構成で，「起動時にIMEを有効にする」オプションや，六曜表示，開くタブの枚数の増加などが加わると，起動時間は増加します．

_ [論文] プログラムの自己進化のためのアーキテクチャ ▲

個人的には，プログラムが自己進化する必要は今のところないと思いますが，いちおう夢がある(?)話なので取り上げてみます．

Ming-Yang Hou, Xi-Yang Liu, He-Hui Liu: Fifi: An Architecture to Realize Self-evolving of Java Program. [ACM site]

Proceedings of SEAMS 2006, p.93, Shanghai, China, May 2006.

１ページの Research Summary で，自己進化型プログラムのためのフレームワークを作ってます，というものです．

このフレームワークでは，JVMTI を使って相互通信する２つの JVM を同時実行し，１つをプログラム実行用，１つを監視システムとします．そして，監視システム側は，プログラム実行時のイベント列に応じてプログラム改変が必要かどうかを判定し，改変の指令をプログラム実行用JVMに送ります（改変されるのは実行プログラムのみで，監視用のコード部分は書き換えません）．

仕組みとしては，今の Java バイトコード書き換えツールを駆使すればそれなりに実現できそうですし，コードの最適化とか難読化にも使えそうです．実行中のプログラムにパッチを当てるという話に似ていますが，この研究の場合，監視プログラムが，機能改変用のパッチを自動生成するという違いがあります．

自己進化の「コードを書き換えるルールを書く」という観点だけを見ると，静的な操作，たとえばリファクタリング操作をスクリプト言語で書くとか，sed でコードをまとめて変更するいったものであれば，あまり変な気はしません．

プログラムの実行を監視して，随時，動的に書き換える必要がある機能変更ってどんなもの，といって何も思いつかないのが，怪しいと感じる要因かもしれません．原稿では「捕まえられない例外が投げられたらtry-catchブロックの自動追加（エラーを無視して実行を再開する）」というものだけが例として載っています．

_ [work] 論文での用語定義 ▲

論文の書き方については，千葉先生の解説がわりと読む量が少なくて良いと思います．あとはこちらの解説文なんかも参考になると思います．

上記の解説では「論理の鎖を省略しないこと」という，ちょっと格好いい表現が使われていますが，論理の鎖で大事なものの１つが，論文中で使う用語の定義だと思います．

未定義な用語を発見するための個人的なチェック法は，論文の先頭から出てくる名詞に対して片っ端から「それって何？」とツッコミを入れていくというものです．その場所から論文を前のほうへ遡っていき，定義（あるいは informal な解説）が発見できればOKです．

この作業は，それなりに時間がかかりますが，アブストラクトや前書きあたりに適用すると，提案手法に読み進むまで何の説明もない用語をたまに発見できたりします．

ただ，未定義の用語を発見するより，その用語の定義・解説を省略しても大丈夫かどうかという判断のほうが難しい気がします．ソフトウェア関連の用語は増え続けているので，特に説明せずに使える用語はどのあたりまでか，という基準はいまいちうまく説明できません．論文での重要度とか，雑誌記事などで目にする頻度が影響していそうですが．良い判断基準があれば教えてください :)

_ [work] 論文の作成工数の見積もり ▲

卒論シーズンなのでというわけでもないんですが，論文の書き方について多少調べています．

論文の品質を向上するための一般的な方法として，書いた後に別の作業や睡眠を挿んで論文を読み直す，というのが言われてますが，それに関連して，卒論のスケジューリングについて書かれた文書を見つけました．論文の作成，添削に関する見積もりの式が示されています．

私の場合，論文を書く→ご飯を食べる→論文を読み直す，といった，もうちょっと早いサイクルで進めることが多いので，係数は違いそうですが，論文のセクション数で見積もるというのは面白いと思います．

卒論・修論を書く人にとっては，添削期間の式のほうが，余裕をもって原稿を添削する人に渡すべし，ということで大事かもしれません．