2009-10-31

日記終了

2009-10-24

とちぎRuby会議02

秘密に少しだけ近づいた気がする。 言葉にすると大部分が消えてしまうんだけど、自分の解釈をメモ。

  • フェアな評価が信頼を生む

    • 他人を助けることが自分のためにもなる仕組みの上では、自然と協力が生 まれる

    • 評価の基準がメッセージとなっている

    • 互助が習慣となり、文化として根づくと、疑問に思わなくなる

  • 信頼による互助のメリット
    • 個人がバッファ（貯金）を溜め込まずにみなのために使うので、バッファ が細切れで死蔵されず全体で生かされる
  • 余裕がある
    • 組織が安定していて、細かいことで汲々とする必要がない
    • 人材の流動性がある
      • 合わない人は自然と離れていき、合う人が集まっている
      • 合わなくても異動で済む。致命傷になりにくい
    • 傘となる人の存在

花を真似るのではなく、土壌を真似る必要がある。

2009-10-23

本の印税

本の印税について興味深い記事が公開されている。

まとめるとこんな感じ。

a) 50% of profit (e.g. Prags) b) 10-20% of sales (i.e. Apress) c) 8-1X% of suggested retail price (i.e. most jp publishers)

aは利益を折半している。ただし純利ではなく粗利（gross profitないし operational profitといったところ？）。要するに著者と出版社は利益だけでな くコストの一部（編集費の類）も折半する。

bは売上の一部を支払っている。あとこのApressという出版社独自の話だけど、著 者にadvance （前払金）を支払っている。プロや学生にとってはありがたいだろ うと思う。

cは小売価格の一部を支払っている。日本の出版社はこれが多いみたい。

個人的には、steakholderと苦楽を共にするやり方がいいかなあ。

2009-10-20

やっぱりこの形式での日記は無理があるなあ。

2009-10-19

義憤

義憤を感じたら要注意。独り善がりな思い込みかもしれない。

2009-10-18

Generative books

本の内容の一部を手続きで生成するというのは、記述を抽象化できるので、基本 的に良い考え。ただし事前に静的に生成しておくのではなく、ビルド時に動的に 生成する場合は、意図どおりに生成されているかをチェックする仕組みが必要。

例えば、本文中のサンプルコードの実行結果を埋め込む場合や、索引の読みを動 的に生成する場合、ツールや辞書のバージョンによって結果が変わりかねない。 （枯れたツールや寿命が短い本は例外。）

増刷や改訂に備えたビルド環境の保全も考えなきゃいけない。

2009-10-17

人間向けソフトウェア

コンピュータソフトウェアもテクストも、解釈に使われるプラットフォームが違 うだけでどっちもソフトウェアで、支援ツールやノウハウを共有できる。

Literacy

リテラシーと言えば文字の読み書きだけど、そのうちプログラミングもリテラシー に含まれるようになるだろうなと思う。今でも表計算ソフトの関数とかはみな普 通に使っているわけで。

IdeoType 0.2

IdeoType 0.2で追加したGauche版の変換器を使ってみている。それなりに使えそ うな気はしていたけれど、思った以上に実用的。

  • 0.1（XSLT版のみ）
    中身はXHTML->LaTeXのスタイルシート。UIなどはRubyで記述。
    • Pros
      • 高速
    • Cons
      • 本ごとの柔軟な対応が難しい（XSLTが汎用言語ではないため）
  • 0.2（Scheme（Gauche）版が追加）
    XSLTプロセッサの劣化サブセット（xsl:apply-templatesとxsl:document相当） に、XHTML->TeXMLとTeXML->LaTeXのスタイルシートをバンドルしたもの。
    • Pros
      • 強力で柔軟（頑張れば何でもできる）
      • トラブルシュートが楽（中間形式にTeXMLを採用したおかげ）
    • Cons
      • 遅い（非効率な書き方の問題）

0.1に比べるとだいぶまし。ただし自分以外の人に使ってもらうという点では、ま だ全然。

  • todo
    • 動的なカスタマイズを容易に
    • パフォーマンスを改善する
    • Ruby版（libxsl-rubyで、テンプレートをXSLTではなくRubyで記述できるよ うになったら試す。パフォーマンスととっつきやすさの両方を満たせそう）
    • XSLT版を削除する（0.3で）

運動

走って泳いで心地良く疲れた。

2009-10-16

編集文献学

編集文献学という学問分野を初めて知った。テクストの執筆から解釈や派生にい たるまで、その編集過程が研究の対象らしい。

A First Step Toward Developing an Editing System for Humanities Research Based on German Scholarly Editing Theory : The Structuring and Implementation of Information from Kafka’s Text
http://ci.nii.ac.jp/naid/110006291451/
編集文献学に基づく人文科学資料エディティング・システム構築の試み : 第一段階としてのカフカ・テクスト情報の構造化と実装 [in Japanese]

ちょっと聞くと、分散バージョン管理システム（DVCS）でかなりの部分を解決で きそうにも感じるけれど、そう簡単ではなさそう。

  • 文字だけでなく図の変遷も扱う必要がある。
  • 「削除」「追加」だけでなく、「移動」「コピー」「入れ替え」も扱いたい。
  • 過去の作品だとテキスト部分のソースが原本の写真だったりする。
  • コミットメッセージ以外にもメタなデータをいろいろ扱う必要がある。

あと、XMLにマップすると単一の切り口によるツリーとしてしか表現できず、その ことが問題になりうるというのは、言われて初めて気がついた。（例えば部分Aと 部分Bが、節は異なるが同じ見開きに載っている場合、両方を要素で表現すると入 れ子が崩れる。）

Markdown

Markdownにアンカーを表現する記法が見当たらない。でも生のHTMLで@idを書くの はぞっとしない。こういう複数のトピックを1ファイルに詰め込んでだらだら書く には向かないかも。でも楽をしたいから簡易マークアップを使っているのだよな あ。

本の原稿をWikiで書けるか

厳密には、コンピュータ系の専門書の原稿を簡易マークアップで記述できるかと いう問い。5、6年前から人にも聞かれるし自分でも考えている。

短い答え：

ケースバイケース

長い答え：

紙向けに出力しなければいけないとなると、結構大変。紙向けの最終原稿（カ メラレディ原稿を機械的に生成できるソースという程度の意味）を表現するに は、少なくとも索引と改ページ位置の制御をサポートした記法が必要。（実際 にはそれ以外にも柱などいろいろある。）

あとユーザが楽に機能拡張できないと本の多様性に対応できない。囲み記事が 5種類あるとか、普通の索引に加えて関数索引を付けたいとかいうときに対応で きるか。

最終原稿じゃなくてドラフトまででいいなら、またはそもそも紙向けに出力し なくていいなら、比較的楽。でも最終原稿まで記述できないと旨味が半減する のも事実。何事もトレードオフだし、何をもって「*で書く」と呼ぶかという解 釈にもよる。

だから結局、拡張可能な「原稿記述言語」が必要になるんだろうな。ただし強力 なだけに濫用されたときにひどいことが起きがち。解決策として、機能と原稿を 別の言語で記述させるというAntのアプローチは良さそう。個人的には microformatでどこまでしのげるか行ってみるつもり。

Micro-project management

数人の小さなチームが数ヶ月だけ一緒に働く小さなプロジェクトを、一人で同時 に数十件、うまく進める方法を知りたい。建築や製造業でのPMのノウハウはいろ いろ聞くのだけど、出版業は規模があまりに小さくて応用しにくい。

今のところ有力なアドバイス：

  • メンバーの大半が毎回異なると蓄積が生かされないので、うまくいったらメ ンバーをころころ変えるな

話が長い

自分用のメモにしては長くなってきた。どうせ自分は読めば思い出すから、キー ワードだけでいいか。誤字もな幼い。

2009-10-15

acquisitions editor（原稿入手担当編集者）

planning/developmental editorだけじゃなく、acquisitions editorも必要ね。 トピックに詳しい必要はなくて、要領が良くて気配りできる人が向いてる。 自分でacquisitionやってたら4-8冊/年くらいのところが、有能なaeが他にいてく れれば8-12冊/年くらいいける気がする。

公開の場で書く際の個人的なルール

  • 他人のことは原則として書かない

2009-10-14

朝方生活で成果を出している方の話を傾聴。憧れる。

2009-10-11

羊羹が買えなかったショックのあまり、パンを買ってしまった。

2009-10-10

オーダーメイドとDIYについて考えている。

2009-10-09

給付型の奨学金が増えるといいなあ。

2009-10-08

メールばかり書いていて、エディタに触れる暇がなかった。

2009-10-07

ファーニッシュトな賃貸住宅がもっと増えてほしい。

2009-10-06

URL難読化サービスは苦手。

2009-10-05

blogger が使えない
http://d.hatena.ne.jp/ku-ma-me/20091004/p2

はてなダイアリーって思ってたよりいいものなんですね。

jwz - Livejournal Deathwatch
http://jwz.livejournal.com/1099745.html

I’ve started divesting myself of reliance on them.

2009-10-02

MS Moneyでも買うかと思ったらディスコンしてた。

2009-10-01

日記をつけてみる。

Other Articles