『欠陥ソフトウェアの経済学』を読んだ。ソフトウェアのベンダや開発者には間違ったインセンティブが与えられており、ユーザの求める方向とは異なる方向に進化している、という話。

第1章 文明の礎
第2章 60億の衝突テスト用ダミー:理不尽なイノベーションと間違ったインセンティブ
第3章 弱さの力:割れた窓と国家の安全
第4章 近視眼的見落とし:スピードに目をくらまされ激動に惑乱される
第5章 完全なる免責:訴えられるものなら訴えてみろ
第6章 オープンソース・ソフトウェア:無料の代償
第7章 進歩は可能か:別の未来へ向かう合理的インセンティブ
エピローグ
注釈

目次は欠陥ソフトウェアの経済学 その高すぎる代償|Ohmshaより

ソフトウェアのバグを減らして安全にしたり、インターフェイスを整えて使いやすくすることは大事なことである。にもかかわらず、ユーザたちはそれにお金を払おうとしない(というより、それだけの価値をそこに見出せない)。その代わり、ユーザたちはソフトウェアに追加された新機能に対しては(比較的)あっさりと財布のヒモをゆるめる。そのため、ベンダはソフトウェアを安全で使いやすいものにするよりは、先鋭的にするほうに力を注ぐ。結果として、宣伝しやすいがあまり使わない機能ばかりが強化されていく。

というわけでソフトウェアが脆弱なものになるのは、市場経済の働きとユーザのファストフード好きのツープラトン攻撃によるものである。計算機は思ったとおりではなく指示したとおりに動く。それと同じく、ソフトウェアベンダは正しいものではなくユーザがほしがるものを作るのである。基本的には我々がほしがったものしかそこにはない。

というのはソフトウェアの消費者としての自虐であるが、生産者としての自虐もここに含まねばならんだろうと思う。ソフトウェア開発者は基本的に新しい物事が好きである。何かを提案しようとしたとき、既存のものを地味に使いやすくするより、それとは全然関係ない新しい機能をつくるほうが不思議とわくわくする。それにだいたい評価も得やすい。

評価が得やすい理由は前述したソフトウェアの消費者としての自虐がまさにそれであるし、新しい機能をつくるほうが楽しみなのは開発者なら自明である。先週書いたコードを理解するのに1時間はかかるし、1ヶ月も前に書いたコードならそれを見るのにもある程度の覚悟が必要である。気が重いことから逃げようとすると、必然的に新しいコードを書きはじめている。そしてソフトウェアの規模はまた不必要に大きくなり、再構築の可能性を小さなものにしていく。

そういう悪循環に対して開発者個人としてできることはあまりなくて、リファクタリングの機会を多く持ったり、リファクタリングしようとしたら構造ほとんど忘れてましたみたいなことを避けるために定期的にレビューすることが必要だろう。これはどちらかといえばチームとしての取り組みである。

たしかに放っておけばソフトウェアは肥大化・複雑化の一途を辿るだけなので、それを防ぐことが必要ですよ、ということを管理者とかにわかってもらうために読ませる本として、メタファが多用されて親しみやすい本書はなかなか適切だと思う。

余談。上記のとおりある程度技術的なことを把握してると、ひたすらに比喩を読まされることになって若干退屈を感じるきらいもあるのだけど、それを帳消しにできるくらい「エピローグ」が秀逸である。冷戦中、ソフトウェアのバグが引き起こした一触即発の事故の話であるが、どの程度真実かは別にして、男の子なら胸をときめかせること必至の4,5ページであると思う。

Centosでもtmux使おうと思って、最新版の1.2を落としてビルドしようとしたら event.h がないみたいなことを言われた:

公式ページでChangelogを見ると、

Since the 1.2 release that tmux depends on libevent. Download the stable version from: http://www.monkey.org/~provos/libevent/

とのことなので、libeventの安定版を入れてやりましょう。

参考: CentOSにtmux1.1をインストール - K氏のCentOSサーバ構築メモ

raphael-radar-screenshot.png

概要

JavaScriptでSVGを描画するライブラリRaphael.jsを使って、 操作可能なレーダーチャートを描画するライブラリ Raphael Radar を作りました。

Raphael Radar は次の2つの機能を持ちます。

  1. レーダーチャートをSVGで表示
  2. レーダーチャートの各軸の値をフォームと対応づけて、インタラクティブに値を選択

(2)の機能は任意で無効化して単純なレーダーチャートとして利用することもできます。

入手と使い方

依存ライブラリ

Raphael Radar を使う前に、2つのライブラリをインストールする必要があります。

  1. Raphael.js (1.3.1 以降)
  2. jQuery (1.4.2 以降)

もしうまく動作しない場合、Raphael.jsとjQueryのバージョンを合わせてみてください。

インストール方法

  1. 上記の依存ライブラリをインストール
  2. Raphael Radarのリポジトリかアーカイブをダウンロードして、raphael-radar-*.*.*.jsを Webから見えるところにアップロード

使い方

  1. Raphael.js, jQury, Raphael Radar をscriptタグで読み込む(Raphael Radar はRaphael.jsより後に読み込んでください
  2. scriptタグを、レーダーチャートを表示したい要素のあとに追加
  3. さっきのscriptタグ内で radar 関数を呼ぶ。次のとおり:
    1. String: チャートを表示したい要素のID
    2. Integer: チャートの幅
    3. Itneger: チャートの高さ
    4. Array: チャートの各値を要素とする配列
    5. Array: チャートの要素の名前を要素とする配列
    6. Array: チャートに関連づけたいフォームのID
    7. Integer: チャートの各値の最大値。第4引数の要素は 0 からこのmax の値の範囲に収まらないとダメです

具体的な使い方は次のページをみてください: http://www.tnzk.org/devel/Raphael-Radar/example

動作環境

Raphael Radar 0.0.0は以下の環境での動作を確認しています:

  • Fedora 11/Firefox 3.5.8
  • Windows Vista/Firefox3.5.8
  • Windows Vista/Internet Explorer8
  • Mac OS X Snow Leopard/Firefox 3.6
  • Mac OS X Snow Leopard/Safari 4.0.4

バグとか見つけたら

@tnzkにお知らせください。githubのBTSはみてないのでほぼ間違いなく見逃します... メールやSkypeとかその辺の手段でもいいです。お気軽にどうぞ。

見積りのむずかしさ

ソフトウェア製品の見積りは難しい。 あるソフトウェア(とまではいかないまでも、何らかのプログラム)を作るのに どれくらいの期間が必要となって、最終的にできあがったものがどの程度の大きさに なるか、ということを見積もることは難しい。 以前から知識としては知っていたけれど、最近だんだんと、その理解が実感を伴うようになってきた。

難しいからといって避けてとおれるわけでもない。

それはそれとして、最近『人月の神話』を読んだ。 実は数年前にも読んでいたけれど、当時はいまいちピンとこないものがあってそれほど印象に残っていなかった。 最近になって翻訳がまずいらしいという噂を聞いて、 せっかくだから原文を読んでみようと思って大学の図書館を当たったのだが、 残念ながら"The Mythical Man-Month"は貸し出し中だった。 隣には新装版の『人月の神話』があって、どうやら追加の章(「銀の弾丸再発射」という洒落たタイトルだった)が あるようだったのでこれを借りてみた。 ひさびさに読むと、これほど思慮深く書かれた本だったのかと驚いた。 当時の自分にはほとんど右から左で、いかに未熟だったかを思い知った。 おそらく今も相対的にはあまり変わってないだろう。

有名なブルックスの法則のほかにも、 興味深い記述がたくさんあったが、特におもしろいと思ったのは 「見積りの精度は経験によってしか向上させられず、 その練習としてこれから書くプログラムの最終的な行数やバイト数を予想してみるのは 試してみる価値のある試みだ」という一節。 たしかに少しずつでも経験を積むことができるし、何より簡単でつまらない課題に、 この予想という要素を加えれば随分とエキサイティングになるような気がした。

テーマとした課題

情報科学類の一年次では、2学期と3学期に「プログラミング入門(I/II)」と呼ばれる C言語によるプログラミングの講義と演習が実施される。 全体をとおしてとてもシンプルな課題が出されるので、見積りの練習には持ってこいだと思う。 残念なのはこれから手をつける課題が学年最後の課題で、 来年はどの講義でこの遊びをすればいいのか今のところ見当がついていないことだ。 まあたぶん何かあるのでそれはいいけど。

課題の内容は小さな有向グラフに関するもので、以下の2つのプログラムと実装せよということだった:

  1. グラフ内の任意のノードから、任意のノードへの最短経路を表示
  2. グラフ内の任意のノードから、任意のノードへのすべての経路を表示

課題には例題が添えられていて、これは概ね(1)の正答に近いものでちょっと残念だったのだけどそれはまあそれとして、 まあそういう問題のそれぞれの成果物についての予想をすることにした。

予想(見積り)

予想のパラメータとして、『人月の神話』では以下のものが挙げられていた:

  • ソースコードの行数
  • バイナリのバイト数

現代にあってはバイナリのバイト数はあまり重要じゃないので、今回は省く。 その代わりに今後は以下の要素を追加したい(今回は小さいので省く)。

  • コード内の関数の数
  • コード内の構造体の数
  • 構造体内での相互参照(再帰的定義)の頻度

これはC言語での用語なので、別の言語でやる場合は適宜読み替える必要がある (言語によってはその重みが異なることがあることが問題かも。一行の余地あり)。

この遊びには僕の他にもう1名参加した(@opentaka)。 結果の比較ができて結構おもしろかった。

今回の課題はとても小さなものだったので、複雑性に関する予想はしないことにした。

予想と結果、その誤差を次の表にまとめた。うーん。

予想 結果 誤差
課題1 150行 82行 68行
課題2 180行 53行 127行

結果との乖離

行数レベルでの具象的見積りはこれがはじめてだったので、 誤差の行数が大きいか小さいかについては判断の材料を持たない。 個人的にショックだったのは、課題2の行数が課題1の行数を下回ったことだ。

実は見積りを立てる段階で「課題2のほうが課題1よりも小さくなるのではないか」 という仮説も一度立てていた。課題2はすべての経路、課題1は最短経路であり、 課題1を含む問題じゃないだろうかと判断してのことだったのだが、 最終的には「課題1のソースコードに追加の記述をして課題2を解くことにしよう」 と考え、課題2の行数を課題1よりも大きく見積もった。

実際には課題2のコードは課題1とはほぼ別個のコードとなった。

課題1で用いた最短経路を表示する関数 show_trace は、その内部で 最短距離を手がかりとして記述している(さらに具体的にいえば、 最短経路の内もっとも自分自身に近いノードを返す関数を再帰的に呼んでいる)。 そのため最短経路に限らずすべての経路を表示する課題2の要求には この関数は再利用さえできず、そういうわけでまったく別のコードを書くことになった。

この誤算の最大の原因は前述した「課題2のほうが課題1よりも小さくなるのではないか」 という推測だと思う。一見すると課題2は課題1を包含するようにみえるけど、 実際にはそうではなかった、ということでプロトタイプの作成によって回避できる 典型的なパターンなので、結構残念。

見積りの段階で実装手法まで考えるべきなのかなあ。 プロトタイピングって見積りの範疇なのだろうか?

感想

シンプルにいって結構おもしろかった。若干不純かもしれないけど、 見積もった行数になるべく近づけようという謎の意識も働いて、 単純なワンライナー化とか難読化よりも個人的には知的興味をくすぐられるかもしれない。

来年もコードを書ける演習を含む講義があったらこの遊びをやるかー。

オープンソースカンファレンス 2010 Tokyo/Spring に、筑波大学 Linux User Group として出展してきました。場所は明星大学で、東京の静かなところにある大学。キャンパスがキレイでした。建造物と建造物の間の距離が短いというのはこれほど便利なのかーと思いました。

前回と同じく冊子を配布。今回は業者さんに依頼せずに代表といっしょに手作業で作成しました(写真は製本が終わってうれしくなって並べてみたところ)。手作業のわりにはそれなりの出来だったし、必然的にコストもとても小さく収まったけど、その傍らで問題もありました。これは後述します。

ブースにいらっしゃった皆様、ありがとうございました!中にはgwitを使ってみたことがある方がいたり、前回の冊子を受け取っていただいた方がいたりと、うれしい言葉をたくさんいただけて励みになりました。1日目は花粉症でほとんどダウンしていたため、もしかしたら不快にさせてしまったかもしれません...申し訳ありません。

つくらぐブースはこんな感じでした:

tsukulug_booth.jpg

冊子の内容

今回の冊子は(その表紙によれば)、

  • Twitter クライアント "gwit" をカスタマイズしよう
  • つくらぐ勉強会レポート: PS3活用術~Linuxを入れてみよう
  • つくらぐ勉強会レポート: カーネルモジュールプログラミング超入門
  • その他

という構成でした。僕はgwitの記事を担当して、ページレイアウトをInkscapeで完結させることができるかどうかに挑戦してみました。結果としてこれは充分に可能で、ちょっと面倒な点を挙げるなら:

  • アウトラインやスタイルを作れるわけではないので面倒くさい
  • 今回は発生しなかったけど、段落内での改ページを避けられないときにどうしよう?

といったところ。でもこれは Illustrator とかでも同じはずなので、どちらかといえばベクタードローイングツールでのページレイアウトに際しての問題というのが適切か。

次回は全ページこれでいきたいなあ。その前にノウハウをまとめる必要がある。そうだな。

反省点

前回同様、大きな問題は起きずに無事その閉幕をみたOSCですが、つくらぐ的には「冊子をはじめとした準備全般がギリギリだった」という反省点が。文字どおり前日に作ってたので...次の2つが原因と見ています:

  • 業者さんに頼まなかったので、別の組織のスケジュールに合わせる必要がなかった
  • 同様の理由で冊子の内容がなかなか決まらなかった

次回はどこかPDF入稿できるところに頼もう...。

その他

  • なでしこ友の会のブースの見せ方がおもしろかった。以下のような感じ。真似しよう:
  • 今回もマイクロソフトは水を配っていた。コメントに「MSDNの日本語をなんとかしてください!」とあって笑った
  • modxのブースで超かわいいステッカーを配っていた(このブースにいた方は半透明名刺をお持ちで、これが案の定超かわいかったので俺も半透明名刺にしようか迷っている...

Ruby から kumofs に接続して、値を入れたり出したりしてみる。

環境

  • Linode 上のCentos 5.1
  • Ruby 1.8.7
  • Rubygems から memcache をインストール
  • kumofs 0.3.1

kumofs のインストール

kumofs のインストール自体は前のエントリに書いておきました。

Ruby への memcache のバインドをインストール

gemから:

# gem install memcache-client

問題なく入った。

kumofs を起動

チュートリアルにしたがう。サーバ1台だけで動かすので、そこだけ読み替える。

$ kumo-manager -v -l (ホスト名 or IPアドレス)
$ kumo-server -v -l (ホスト名 or IPアドレス) -m (ホスト名 or IPアドレス) -s /path/to/dbfile.tch
$ kumo-gateway -v -m (ホスト名 or IPアドレス) -t ポート番号
$ kumoctl (ホスト名 or IPアドレス) attach

準備完了。

簡単なスクリプト

ruby-memcache を通してkumofs をインタラクティブに操作するスクリプトをつくる。

shebangを適宜書き換えて...

$ ./imemcache.rb localhost:11211
$./rubymemcache.rb
localhost:11211> set please mrlostman
=> set(please,mrlostman)...mrlostman
localhost:11211> set little busters
=> set(little,busters)...busters
localhost:11211> get please
=> get(please)...mrlostman
localhost:11211> get little
=> get(little)...busters
localhost:11211> get hybrid
=> get(hybrid)...nil
localhost:11211> quit 
Type C-d to exit

キーがないときは nil が帰ってくるようす。エントリ書きはじめてから delete つくってなかったことに気づく。ううん。

kumofs について

最近 OSS としてリリースされて話題の Key Value Store。 試して見ようと思ってインストールしたら何度かつまづいたので、 メモしておきます。

  • Centos である
  • gccが4.1系である

という条件でコケる傾向にあるようです。 kumofs 0.3.0 でこれを解決するのはなかなか面倒っぽかったのですが、さっそく 0.3.1 がリリースされて俺でもビルドできたので、似たような環境で悩んでる人に助けになれば。

環境

米国 VPS のひとつ Linode 上の Centos 5.1 でインストールを試みました。Rubygems が入ってる以外はほぼ登録直後の状態。デフォルトで入っていたgccは4.1.2でした。こいつが諸悪の根源だったようす。

手順

基本的には以下の手順どおり:

必要なもの

Githubのwikiを参考に、今回入れたものをとかデフォルトで入ってたものを明記しときます。

  1. linux: 2.6.18 (デフォルト)
  2. gcc = 4.4.0 (yumから)
  3. g++ = 4.4,0 (yumから)
  4. ruby = 1.8.7 (デフォルト)
  5. Tokyo Cabinet >= 1.4.41 (ソースから)
  6. MessagePack for C++ = 0.4.1 (ソースから)
  7. MessagePack for Ruby = 0.3.2 (gemから)
  8. libcrypto (openssl) (デフォルト)
  9. zlib (デフォルト)
  10. kumofs = 0.3.1 (ソースから)

gcc 4.4とg++ 4.4 をインストール

gcc/g++ 4.1だとkumofs のビルドに失敗します( _syncandaddfetch_4 がどうとか言われる)。なので、先にgcc/g++ 4.4をインストールしておく。こいつらはTokyo Cabinet とかのビルドには使わなくてもOK。

yumから入ります。

# yum install gcc44 gcc44-c++
# gcc44 -v
# g++44 -v

Tokyo Cabinet をインストール

バックエンドとして利用される Tokyo Cabinet をインストールします。僕は 1.4.41 を利用。

./configure してようとするとbzip2がらみの何かがないとか言われます。そしたらdevelを入れてやりましょう。

# yum install bzip2-devel bzip2-libs
$ ./condifure
$ make
# make install

どこに入ったか覚えて置きましょう。デフォルトは /usr/local/libです。

Message Pack for C++ をインストール

SourceForgeのリリースページから最新版の 0.4.1 をダウンロードします。

で、ここで gcc44 と g++44 が登場。 ./configure します。

$ CC=gcc44 CXX=g++44 ./configure
$ make
# make install

ここでもインストール先を覚えておきましょう。デフォルトなら /usr/local/lib です。

Message Pack for Ruby をインストール

これはgemから。

# gem install msgpack

kumofs をインストール

これでラスト。最新版の 0.4.1 を使います。Githubのリリースページか、git clone します。

ここでも gcc44 と g++44 が登場。

$ CC=gcc44 CXX=g++44 ./configure
$ make
# make install

起動してみる

急いでインストールしたので、今回はkumo-manager を起動するだけです。

$ kumo-manager -v
kumo-manager: error while loading shared libraries: libtokyocabinet.so.9: cannot open shared object file: No such file or directory

おうふ! Tokyo Cabinet と MessagePack のインストール先を教えてあげましょう。

$ export LD_LIBRARY_PATH=/usr/local/lib
$ kumo-manager -v
usage: kumo-manager -l  -p 

  -p     --partner        master-slave replication partner
  -a                        --auto-replace   enable auto replacing
  -Rs             --replace-delay  delay time of auto replacing in sec.
  -k      --keepalive-interval     keepalive interval in seconds
  -Ys     --connect-timeout        connect timeout time in seconds
  -Yn     --connect-retry-limit    connect retry limit
  -Ci     --clock-interval         clock interval in seconds
  -TW     --write-threads          number of threads for asynchronous writing
  -TR     --read-threads           number of threads for asynchronous reading
  -o      --log                    output logs to the file
  -g     --binary-log             enable binary log
  -v                --verbose
  -d      --daemon

  v0.3.1 revision 5b53cc4277e6ed951db7f599de9fcfcd3738b2cd Wed Jan 20 15:52:34 2010 +0900

error: required but not set: -l

うふふ

血と細胞の鎖

2009年が終わった。

2000年代がそのひとつの区切りを終え、2010年代の最初の一年が幕を開けた。

90年代生まれの僕にとっては、「10年代」という響きはひどく奇妙に聞こえる。90年代や80年代、さかのぼって60年代くらいまでは何となく耳に馴染みを感じるんだけど、50年代くらいから少しずつ違和感が増してくる。基本的には(意識的にか無意識にかに関わらず)耳にした回数に反比例するのだと思う。

そんな10年代がはじまりを告げた。

20年代がはじまるとき、ぼくは29歳になっている。「今年で30」だなんて言っている。ぼくはどんな気持ちでその言葉を口にしているのだろう?そこにはどんな種類の重みが宿っているのだろう?

ぼくは誰に、何のためにそれを言うのだろう?

それは今のぼくには知りようのないことだ。10歳のとき、20歳になる年に何を思うか、何をしているかなんて考えもしなかったし、考えたとしてもすべての予想は決定的に外れている(予想というのは、あの世界を別にすれば本質的に外れるものなのかもしれない、というのはここでは置いておく)。

それだけに、大切な10年であろうと思う。2010年から2020年の間、僕はどのような僕に変わり、世界はどのような世界に変わり、その変化の間には何らかの関係が生まれているのだろうか?

わからない。

ただひとつ言えることは、結局のところ僕にできることは、流した血や剥がれ落ちた細胞を集めてもうひとつ自分を作り、それをどこかに押し隠す、そういったことの繰り返しなのだと思う。

歩いてきた足をふと止めて振り返る。そこには小さなビニール袋を一杯にするくらいのおびただしい量の血が流れており、バケツを溢れさせるだけの細胞が細かくちぎれた破片となって連なっている。それは遠い過去からぼくの足元まで、ゆらゆらと寄り道をした形跡を残しながら繋がる一本の線になっている。

2009

ぼくは歩いていた。というよりも歩いている。トンネルの中かどうかはわからないが、そうであっても不思議に思わないくらいに辺りは暗い。目に入るのは闇だけで、何度も何かにつまづくが、何につまづいたのかはわからない。積極的に襲ってくることはないから、害意を持った生き物ではないことだけはわかる。でもそれ以外には何もわからない。何につまづいたのかもわからないまま、ぼくはその歩みを続ける。死にはしないだろうという漠然とした自信だけを頼りに一歩ずつ歩く。

ぼくが足を進めるたびに、鎖が引きずられる重苦しい音がする。血と細胞の鎖は、僕からはるか遠くまで続いている。それは闇の奥に消えていて、どこから来ているのかはわからない。深い闇の奥から僕の体に繋がっている。僕を逃がさないようにしっかりと足首を掴んでいる。僕は歩く。鎖を引きずる。暗闇から少しだけ鎖が姿を現し、そして視界から消える。

僕は吐き気をもよおす。闇の中で、ときどきどうしようもない不安に駆られて後ろを振り返ることがある。そこには過去の僕の血と、過去の僕の細胞でできた鎖だけが見える。そこには過去の僕が過去のままでいるように見える。少しの間、ここで鎖を引いて歩く僕自身をそれに重ねてしまう。僕は吐き気をもよおす。いちばん手前の鎖が今の僕の血と細胞でできていることを思い出して、貧血を疑うけれど、あまりにも馬鹿馬鹿しいのですぐにやめる。

ときどき出会う人々の存在が、この空間がトンネルではないことを教えてくれる。彼らは自由にこの世界を歩き回り、おそらくは思い思いの生き方をしている。ぼくの近くを通る一瞬だけ、彼らの姿が見える。ほとんどの場合、言葉を交わすこともなくすれ違うだけだ。時間を気にしながら小走りの人、似合わない大きな荷物(たぶんプレゼントだろう)を抱えた人、派手なメイクをした人、いろんな人間が僕の近くを通り過ぎていく。彼らはほんの一瞬、僕にしか見えない暗闇の中を歩く僕に視線を送り、すぐにやめる。それは僕というよりは僕から伸びる長い長い鎖と、ときどきそこに浮かぶ過去の僕によく似た幻影を見ているように思える。そして視線を外したとき、彼らは少しだけ嘲笑を浮かべているように僕には見える。そういうとき、ぼくはまた貧血を疑うことになる。

とても少ない割合で、ぼくと同じような鎖を引きずっている人に出会う。彼らが彼ら自身の暗闇の中にいるのかどうかまではわからない(それは本質的に本人にしか見えない暗闇だからだ)が、鎖の音と匂い、そこに浮かぶ幻影ははっきりと見える。けれど多くの場合、その出会いは良くない結果を残すことになる――特に、相手の引きずる鎖が僕の鎖の一部分とよく似ている場合には。一部といっても、先端部分(遠くの側の端っこは闇に飲まれて見えないので、手前側のこと)によく似ているときはとても上手くやっていける。というよりも基本的にはそうでなければならない。そうでないとき、ぼくは相手の鎖に自分自身の過去の幻影を見てしまう。そして強烈な嘔吐感を得る(自分の汚物と他人の汚物はどちらも汚いけど、その間には決定的な差異があるのと同じだろう)。相手が僕の鎖を辿ってしまったら、同じ吐き気をもよおすことになる。ぼくらはお互いの暗闇の中に消える。鎖が少しずつ伸びる。

僕はこの鎖を断ち切りたいと思う。けれどそれが実行に移されることはない。僕はその重さや、幻影がもたらす嘔吐感、それがあることで傷つけあうことを受け入れ、重たい血と細胞の鎖を引きずりながら歩く。それは暗闇の中で、僕の進むべき方向を示してくれる唯一のものだ。

現存するMMLコンパイラについて

mugeneは、MML(Music Macro Language)コンパイラのオープンな実装のひとつ(といっても対象はmugene MMLという独自の形式で、標準的なMMLとはずいぶん違う)。

今のところ、軽く調べると以下の3つが簡単に見つかる:

  1. テキスト音楽サクラ
  2. PMML
  3. mugene

『テキスト音楽サクラ』なんかもなかなか優秀なエンジンを含んでいるけど、Delphi(言語としてはObject Pascal?)で書かれていて移植性に乏しい。PMMLのインストールについては昔ブログにまとめたが、PMMLはあまりにも標準的なMMLからかけ離れているのと、今後更新される予定がなさそうなのが問題。mugeneはC#なので、.NET Frameworkの動くWindowsではもちろん、Monoさえ動けばLinuxでも使える。

Monoのインストール

mugeneの前にMonoをインストール。Fedoraならyumで入ります:

$ sudo yum install mono-core mono-devel

入手とインストール

mugeneはgithubで公開されてます:

atsushieno's mugene at master - GitHub

ので、githubからcloneしてconfigureしてmakeしましょー:

$ cd ~/src
$ git clone git://github.com/atsushieno/mugene.git mugene
$ cd mugene
$ ./configure
$ make
$ sudo make install

なぜか make install に失敗することがある(cpがコケる)ので、その場合は以下のように手動でインストール:

$ mkdir -p /usr/local/lib/mugene
$ cp mugene/bin/Debug/mml/* /usr/local/lib/mugene
$ mkdir -p /usr/local/bin
$ cp mugene/bin/Debug/* /usr/local/bin

実行してみる

Github の mugene の wiki からサンプルをコピーしてコンパイルしてみる:

//----two slashes are used to indicate a comment line---
#meta title "Rhapsody in Blue (introduction)"
#meta copyright "George Gershwin (1898-1937)"
1 t140 @71 V110 o6 l4 a2.g8a8gagfedc+c2dd+e2c+

サンプルはなぜか二重引用符が2byte文字か何かになっている(Wikiの記法との衝突?何かしらのエスケープ手段でもないのかしら)ので、それだけ書き換える。

$ mugene test.mml

何かしらのmidiが吐かれ、何かしらのメロディーが聴こえればOK。

Subversionでのコンフリクト

Subversion 1.6以降だと、コンフリクトが2種類に拡張されているらしい:

  1. ファイルコンフリクト
  2. ツリーコンフリクト

ファイルコンフリクトは普通のやつで、よく知られているほう。同じファイルの同じ行が変更された場合に起きる。

ツリーコンフリクトというのは、ファイルの存在そのものについてのコンフリクト。以下の場合に起きる:

  • HEADでは削除されたファイルに対して、変更をコミットしようとした
  • HEADでは更新されているファイルに対して、削除してコミットしようとした

ファイルコンフリクトだけの時代にはこれは検出できなかったそうな。

ツリーコンフリクトの解消

なぜか解消方法があまりWebにないけど、手動で変更を適用したあとに svn resolve すればいいっぽい。

$ svn resolve --accept working conflicted_file

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

最近のコメント

アイテム

  • raphael-radar-screenshot.png
  • setting_our_booth_up.jpg
  • tsukulug_booth.jpg

ウェブページ

Powered by Movable Type 4.32-ja