hisashim's Journal (2000-2008)

[Announcement]Blogを書く場所を引っ越します

2009-01-03T00:25:34Z

Blogを書く場所を引っ越します。

自前でホストしたいなとか考えてたんですが、理想のツールを待つ間にも時間は流れていくので、割り切って他人様の厄介になることにします。

なお、既存の記事はそのまま残します。ありがたいことにリンクしてくださっている方もいますから。

では今後もよろしくお願いします。

----

と思ったんだけど、ちょっと保留（2009-01）。

----

自分の要求が特殊なことが分かったので、自前でやることにしました（2009-02）。

----

とりあえずここで試行錯誤中（2009-03-31）。たぶん一生試行錯誤のママ。

http://hisashim.org

どうぞよろしく。

[memo][blog] Journal digest 2007, 2008

2008-12-31T21:35:37Z

2007年分と2008年分から、自分が気になった記事を抜粋してみた。だいたいが本や出版に関するもの。並び順は古いものから新しいものへ。

-------- 2007

[Publishing] 作家森博嗣から出版業界への疑問
http://hisashim.livejournal.com/325140.html

[tmp][translation] Paul Graham, "How to Fund a Startup", 2005
http://hisashim.livejournal.com/329243.html
http://www.kt.rim.or.jp/~hisashim/graham/startupfunding.ja.html

[Work][Math][TeX] 数式の体裁に関する慣習
http://hisashim.livejournal.com/330343.html

[Copyright] 「公表された著作物は、引用して利用することができる」
http://hisashim.livejournal.com/338101.html

[Publishing] SIST 科学技術情報流通技術基準編集者向けメニュー
http://hisashim.livejournal.com/338677.html

[Workbook][Publishing] Choosing an E-book Compiler
http://hisashim.livejournal.com/344293.html

[Work] プログラミング言語の入門者がぶつかる問題点
http://hisashim.livejournal.com/351033.html

[Publishing][Event] O'Reilly Tools of Change Conference presentations
http://hisashim.livejournal.com/353074.html

[Life] Ten Things I Have Learned / Milton Glaser
http://hisashim.livejournal.com/355125.html

[PM] The Chicken and the Pig
http://hisashim.livejournal.com/357962.html

[Publishing][Book] 良い本の見つけ方
http://hisashim.livejournal.com/358765.html

[Publishing] PODによるPublishing Renaissance / Allison Randal
http://hisashim.livejournal.com/361238.html

[Publishing][Editing] 「編集者入門ミニ講座」
http://hisashim.livejournal.com/362984.html

[Quote][Tech] 「情報技術（ICT）の先行きを占う」
http://hisashim.livejournal.com/365286.html

[cg][publishing][typesetting] "Texts Rasterization Exposures"
http://hisashim.livejournal.com/366786.html

[Work] ルーチンワーク
http://hisashim.livejournal.com/369997.html

[Life] 義理と本懐
http://hisashim.livejournal.com/373375.html

[publishing][editing] shared annotation
http://hisashim.livejournal.com/380526.html

[publishing] 本は人間向けのソフトウェア
http://hisashim.livejournal.com/384499.html

[people][education] "Randy Pausch’s Last Lecture: Really Achieving Your Childhood Dreams"
http://hisashim.livejournal.com/385098.html

[art][font][publishing] 小林章の欧文タイプ・セミナー「実践アルファベット！」
http://hisashim.livejournal.com/385888.html

[floss][publishing] "open source technology at The New York Times"
http://hisashim.livejournal.com/386742.html

[publishing][rant] hack
http://hisashim.livejournal.com/387260.html

[publishing][copyright] Copyright Assignment Benefits
http://hisashim.livejournal.com/388344.html

[publishing] author guideline（執筆の手引き）の必要性
http://hisashim.livejournal.com/388686.html

[publishing] PragDave on Computer Book Publishing
http://hisashim.livejournal.com/389480.html

[publishing][event][xml] 「第23回多言語組版研究会：XSL-FOによる書籍出版の経験から」
http://hisashim.livejournal.com/391327.html

[publishing][editing] 簡潔に編集する
http://hisashim.livejournal.com/393133.html

-------- 2008

[publishing] "John Resig - Programming Book Profits"
http://hisashim.livejournal.com/397126.html

[TeX][FLOSS][publishing] multipagebox.sty
http://hisashim.livejournal.com/398344.html

[cg][education] 若いCG研究者へのアドバイス
http://hisashim.livejournal.com/400118.html

[publishing][event] Tools of Change for Publishing Conference 2008
http://hisashim.livejournal.com/401881.html

[publishing][tex][ant] マークアップ言語とプログラミング言語
http://hisashim.livejournal.com/402553.html

[people][talk][event] 石井裕教授「独創・協創・競創の風土とタンジブル・ビット」
http://hisashim.livejournal.com/403248.html

[translation] Gabriel "Worse Is Better", Waldo "Worse is worse"
http://hisashim.livejournal.com/404606.html
http://www.kt.rim.or.jp/~hisashim/gabriel/
Worse Is Better（悪いほうが良い）
Lisp: 良い知らせ、悪い知らせ、大成功への提言
http://www.kt.rim.or.jp/~hisashim/waldo/
Worse is worse（悪いものは悪い）

[esp] 未踏に応募するときの工夫
http://hisashim.livejournal.com/411381.html

[publishing][continuousintegration] 編集制作における継続的インテグレーション
http://hisashim.livejournal.com/412899.html

[gauche][document] gauche-refe-0.8.13-unofficial.pdf, gauche-refj-0.8.13-unofficial.pdf
http://hisashim.livejournal.com/419775.html

[publishing] Boris Kachka "The End: Have We Reached the End of Book Publishing As We Know It?"
http://hisashim.livejournal.com/425519.html

[event][cg][people] SIGGRAPH Tokyoセミナー#50 Henrik Wann Jensen氏講演会
http://hisashim.livejournal.com/426671.html

[event][talk][typography][design][typesetting][publishing][printing] 小林章の欧文タイプ・セミナー2008 「欧文フォント質問箱」
http://hisashim.livejournal.com/430960.html

[publishing][work][translation] 翻訳書の訳者の方へのお願い
http://hisashim.livejournal.com/434549.html

[publishing][retrospective] "What is it like to write a technical book?"（技術書を書き終えての振り返り）
http://hisashim.livejournal.com/433063.html

[lecture][talk] Andres Duany, "San Antonio By Design", 1991
http://hisashim.livejournal.com/433820.html

[talk][business] Guy Kawasaki, "The Art of the Start"
http://hisashim.livejournal.com/433629.html

[publishing][paper] "Refactoring the Publishing Process"
http://hisashim.livejournal.com/434302.html

[life][work] 2008年の振り返りと2009年の抱負

2008-12-31T20:47:32Z

2008年の振り返りと2009年の抱負
==============================

2008年を対外的な活動を中心に振り返ってみる。

仕事での成果：
------------

書籍：

『プログラミングErlang』
『実践Common Lisp』
『Manage It!』
『+GAINER』

（いずれも実作業の主担当ではない。）
その他、進行中の企画がいくつか。

インフラ整備：

バージョン管理リポジトリ（Subversion）
メールサーバ（Postfix、Dovecot）
問題追跡システム（Trac）
メーリングリスト（QuickML）
CIサーバ（CC.rb）
ファイルサーバ（FTP、SFTP、WebDAV）

リポジトリとメールサーバ以外は2008年から実運用。
その他、導入すべく調査中のサービスがいくつか。
ただしシステム管理の負担が高まったので、体制を考える必要がある。

課外活動での成果：
----------------

未踏で、社会に貢献しうる人材であると評価していただいた。

2007年度第II期未踏ソフトウェア創造事業スーパークリエータ認定
http://hisashim.livejournal.com/410922.html

RubyKaigi Tokyo 2008のライトニングトークで発表させていただいた。

Lightning Talk on DocDiff at RubyKaigi Tokyo
http://hisashim.livejournal.com/420035.html

ブックコンパイラIdeoTypeは開発を続けている。

http://ideotype.svn.sourceforge.net/viewvc/ideotype/trunk/?view=log

その他、これから公になる予定の活動がいくつか。

2008年を振り返って
------------------

続けたいこと：

得意なことに集中する。自分の場合は「本とコンピュータ」らしい。
プロジェクトには人選からかかわる。
（仕事上の役割に加えて）一個人としても社会に貢献する。
組織を越えて横のつながりを持つ（Publishing BoF #0に続き#1を）。

反省点：

諸般の事情で仕事に全力で取り組めず、成果が落ち込んだ。
課外活動でも、IdeoTypeの次期バージョンをリリースできていない。

挑戦したいこと：

外を向く。
- 組織外の人ともっと積極的にかかわり、協力する（広義のPR）。
- 課外活動で非商業的な本を作ってみる（いわゆる同人誌のようなもの）。
- ちゃんとしたBlogを書く。
評価基準を自分の内に持つ（他人に評価されないからやらないという考えは、行きすぎると倫理観を蝕む）。
自分発の仕事をする。

やめること：

新しい挑戦がないルーチンワーク。
よけいなお節介（もちろん依頼されたら協力する）。

2008年は失敗から学ぶ一年だった。手痛かったぶん、有意義ではあった。

自分の本分は、仕事を減らすことでは達成されない。たくさんの意義ある仕事を、効率良く進めて成し遂げることで達成されるのだと思う。

2009年は、効率良く・良い仕事を・たくさんしよう。

[ideotype] IdeoType on Windows

2008-12-25T17:19:09Z

IdeoType 0.1をWindowsで動かせないか試してみた。

結論から言うと、おそらく動く。たぶんあとちょっと。ただしそれなりに面倒。仮想化環境で動かすほうが楽。

一番面倒なのは、LaTeXやRubyのプラットフォーム依存なライブラリの配布パッケージが、Unix系OSほどには網羅されていないところだった。

Cygwin
------

/setup &
(install xsltproc, ruby, imagemagick)

XML DTD
-------

% mkdir /etc/xml
% wget  http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd
% mv xhtml-math11-f.dtd /etc/xml
% vi /etc/xml/catalog
% cat /etc/xml/catalog
<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
 "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
  <system systemId="http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd" uri="xhtml-math11-f.dtd" />
</catalog>

Ruby
----

% cd /usr/bin
% ln -s ruby ruby1.8

Rake
----

% svn checkout http://svn.ruby-lang.org/repos/ruby/trunk/lib/rake \
               /usr/lib/ruby/site_ruby/1.8/rake
%  svn cat http://svn.ruby-lang.org/repos/ruby/trunk/lib/rake.rb \
  > /usr/lib/ruby/site_ruby/1.8/rake.rb
% svn cat http://svn.ruby-lang.org/repos/ruby/trunk/bin/rake \
  > /usr/bin/rake

IdeoType
--------
Windowsのコマンドと同名のコマンドが衝突する。convertとかtimeとか。LaTeXインストーラでインストールされるコマンドも同様に衝突しがち。

Cygwinが優先されるようにPATHを調整。

  PATH=/usr/bin:$PATH make test

しかしCygwinではだめそう。OneClickInstallerを試す。

RubyInstaller
http://rubyinstaller.rubyforge.org

ruby一式をインストールして、優先して使われるようにPATHを設定。

  export PATH=/cygdrive/c/ruby/bin:$PATH

lib/build.rakeが、そんなプログラムはないよというエラーを出す。check_requirements()で、使いたいプログラムがPATH上にあるか自前でチェックしているので、チェックしないように書きつぶす。

TEXINPUTS=value progとするとWindowsのシェルが文句を言うので、TEXINPUTS指定を省くようにlib/build.rakeを書き換え。

当然.styがないと言われるので作業ディレクトリにコピー。

  cp lib/*.sty test/

cm-superがないらしいのでごまかす。

  wget http://www.ring.gr.jp/pub/text/CTAN/fonts/ps-type1/cm-super/type1ec.sty

jis-cjk.mapがないらしいのでごまかす。

  cp /cygdrive/c/tex/share/texmf/fonts/map/dvipdfmx/base/{cid-x,jis-cjk}.map

RMagickがない。OneClickInstallerにもCygwin版にも含まれていない。自前でコンパイルすれば動きそうだけど、そろそろ時間切れ。

可搬性・移植性について考えさせられた。Uni*xになったMacOSXに比べて、Windowsはサポートが大変。マルチプラットフォームなスクリプティング言語などを活用しても、機能を拡張する部品が動かなければ動作しない。非標準のライブラリ等を使うときは、コンパイル済みのパッケージを一緒に配布すべきかも。

[cg][event] 「OoO 第五回レンダラ忘年会 '08」

2008-12-22T18:05:08Z

OoO #5に参加した。素晴らしかった。みなさんありがとうございます。

OoO 第五回レンダラ忘年会 '08 - OoOO
http://groups.google.co.jp/group/oooo_renderist/web/ooo---08
今回はレンダラ忘年会 08 です. 今年のレンダラ界隈の話題をまったりと振り返ります.

話題の予定
- Progressive Photon Mapping 講演 by bee
- SIGGRAPH ASIA の DVD を鑑賞する.
- iPhone レイトレ by syoyo
- CUDA レイトレ by kioku
- GI 本進展状況 by syoyo
- 今年のレンダラ界隈を振り返ってみる.
- その他ボーナスステージ. OoO 参加者だけの特典!?

Progressive Photon Mapping
--------------------------
蜂須賀さん自身が解説してくれた。

http://graphics.ucsd.edu/~toshiya/
http://graphics.ucsd.edu/~toshiya/ppm.pdf

分かった気になった。途中で参加者側から適切な質問が何度も出たのもよかった。

僕の理解はこう（自分用のメモで、いいかげんなので注意）。

クラシックなPMは2パスで、最初にフォトンを1回だけ射出して分布を求め、それを参考にピクセルの値を求める。

PPMはマルチパスで、どこに視線が当たっているかを最初に調べておき、フォトンを何度も撃ってピクセル値を徐々にリファインしていく。

主な利点

* メモリ消費量を一定に抑えられる。PMできれいな画を描くには一度に大量のフォトンを射出する必要があるが、メモリ容量には限りがある。PPMでは繰り返す回数を増やせばよい。なお、極端なことを言えば、1回に使うphotonは1個だけでもいいとのこと。

* 他の方法では扱いにくかったLSDSE pathを正しく扱える。LSDSE path（light-specular-diffuse-specular-diffuse-eye path）とは、例えばプールサイドからプールの底を見るときの経路（太陽・水面・プールの底・水面・目）。厳密には、ガラスで覆われた電球で照らされたシーンや、角膜やレンズを通して見ているシーンはすべてLSDSE pathを含む。

* 途中経過が分かるので、ユーザが望めば十分な質の画像が得られた時点で中断すればよい。

僕のあほなQ。

Q. メモリが潤沢にあったらどういう改善が可能？
A. 無限にあるとしたら普通のPMが使える
Q. リアルタイムで対話的な応用は可能？
A. GPUの類で実装すればよいのでは

CUDA
----
Okuさんが既存のコードをCUDAへ移植したときの苦闘の記録。エラーメッセージがひどいので苦しめられたとのこと。ほかにもいろいろはまりどころがあるらしい。

OpenCL
------
CUDAと比較しつつOpenCLを藤田さんが紹介。割とまともそうなので、各社がどのようにサポートしてくるか待ちましょうという感じらしい。

GI本進展状況
------------
レンダラ書きを育成するために藤田さんが執筆中の本についてディスカッション。みなさんの意見のうち僕が書き留められたぶんをメモ。

「glossy =/= specularであるとはっきり言ってほしい」
「local illuminationの解説を早めにしてほしい」
「早めに用語説明を」
「Jensen本ではrayが何を運んでいるのか分からなくて困った」
「同じモデルを使って少しずつ改善していくという構成はどう？ Realistic Ray-Tracingでは、2種類見せてる。ノイズが出る方法を見せてから、ノイズが出ない方法を見せる」
「アルゴリズムの説明は自然言語でやってほしい。擬似コードはいや」
「TAをしたとき、ピクセルの値を求めるところで間違える人が多かった。間違えるとこうなるという典型的な画像を載せてはどうか」

あと、研究に必要なアートワークをどう手配するかというのは割と深刻な問題のようで、研究者はみな苦労されているようだった。（自動生成ではない）大規模なモデルやシーンが欲しいとか、たまにはSponza以外のシーンも使いたいとか。一方、大手プロダクションで働いているアーティストさんは創作意欲をもてあましていたりするそうなので、両者をうまく橋渡しすればよいのではとのこと。

SIGGRAPH Asia 2008 DVD
----------------------
安藤さんから寄贈されたDVDを蜂須賀さんの解説付きで鑑賞。

詳しい話はどなたかが書いてくれると思うのでそちらを。

懇親会
------
いろいろ話せてよかった。迷惑かけた人はごめんなさい。でも優秀でやる気に満ちた人たちの集まりっていいね。

[profession][ethics] 「情報技術者の定義」再公開

2008-12-22T13:29:14Z

何度も読み返す文章がある。力武さんの「情報技術者の定義」もそのひとつ。

オフラインになっていたのを再掲していただけたので、読み返した。

情報技術者の定義 - jj1bdx: life beyond Japan
http://d.hatena.ne.jp/jj1bdx/20081218/p1

数ある項のなかでも、特にこの2つをよく思い出す。

技術力の行使は，それ自身武力の行使と同様の意味を持つ．故にその無制限な利用は厳しく戒められなければならない．言い換えれば，それだけの倫理的な規準を持たない人物は，情報技術のプロと呼ぶに値しない．

技術者は技術力を持ってその思想を証明しなければならない．思想なき技術は存在しない．技術力の裏づけなくして，技術者としての思想は証明できない．

技術者以外の職業でも、自分がプロである条件が何であるかを、はっきりとした言葉で意識していることは大事だ。

[work][event][ann] 『新春座談会このコンピュータ書がすごい！ 2009年版』

2008-12-21T15:50:46Z

遅くなってしまいましたがお知らせです。

ジュンク堂池袋店の長田さんに声をかけていただいて、2009-01-10(土)のトークセッションに、出演者側で参加させていただくことになりました。

ジュンク堂書店池袋店　トークセッション詳細情報
http://www.junkudo.co.jp/newevent/evtalk.html#20090110ikebukuro
『新春座談会　このコンピュータ書がすごい！ 2009年版』
――2008年に出たコンピュータ書ならこれを読め！――
高橋征義（日本Rubyの会会長・読者側代表）×コンピュータ書仕掛人（出版社側代表）
2009年1月10日（土）19時～

気づかない人がいそうなので書いておくと、

森田尚（もりたひさし）
（株）オーム社開発部で書籍の企画編集を担当。担当書目は『Rubyプログラミング入門』『ハッカーと画家』『プログラミングRuby 第2版』『On Lisp』など。

とあるのが私です。

高橋さんの熱い告知はこちら。

ジュンク堂書店池袋本店でトークセッション
『新春座談会　このコンピュータ書がすごい！　２００９年版』をやります
http://d.hatena.ne.jp/takahashim/20081213#p1

先日あった出演者の事前ミーティングでは、私が見逃していた面白そうな本をたくさん教えてもらいました。参加される方も、きっと何かしら発見があるんじゃないかと思います。ご興味があればぜひご参加ください。

参加ご希望の方は、上記の案内のページにあるとおり、電話か店頭にてお申し込みください。
（大丈夫だとは思いますけど、万一締め切られてたらごめんなさい。）

[quote] Elegance / Erik Naggum

2008-12-14T14:44:33Z

Erik Naggum
http://en.wikiquote.org/wiki/Erik_Naggum

Erik Naggumといえば毒舌で有名だけど、そうじゃない名文句もある。

例えばこれが好き。

Elegance is necessarily unnatural, only achieveable at great expense. If you just do something, it won't be elegant, but if you do it and then see what might be more elegant, and do it again, you might, after an unknown number of iterations, get something that is very elegant.

洗練（elegance）は、自然には得られない。大きな代償を支払ってやっと手に入るものだ。何かをただ為しただけでは、洗練されたものにはならない。しかし、振り返ってどうしたらもっと美しくなるかを考え、もう一度やってみる。これを数え切れないほど繰り返したなら、とても洗練されたものが出来上がるかもしれない。

拙訳は全然ダメだな。あと100回くらい訳しなおす必要がある。

[paper][hci][computing] J. C. R. Licklider, "Man-Computer Symbiosis"（人間とコンピュータの共生）

2008-12-08T17:58:46Z

J. C. R. Licklider, "Man-Computer Symbiosis"を眺めた。

Man-Computer Symbiosis
http://groups.csail.mit.edu/medg/people/psz/Licklider.html

Man-computer symbiosis is an expected development in cooperative interaction between men and electronic computers.

via リックライダーの"人間とコンピュータの共生" - NextReality
http://d.hatena.ne.jp/rkmt/20081128/1227881952

これは妄想が広がるなあ。

----

人間の注意力がどんどん高価になり、浪費が許されない資源になっていってる気がする。

普段は単純作業を人間の介入なしに自律的にこなしていて、でもいったん人間が接続すると一体となって「拡張された人間」になる、そんな機械が欲しいなあ（SFマンガの読みすぎ）。

[environment] 「環境リスクと学生のエッセイ」

2008-12-08T17:44:44Z

中西先生の雑感は毎週楽しみ。

2008-11-28の記事は、自分で答えを考えながら読むとさらに面白い。

J. Nakanisi Home Page
「環境リスクと学生のエッセイ」
http://homepage3.nifty.com/junko-nakanishi/zak451_455.html#zakkan455

ある大学の3,4年生に90分の講義を４回行った。その中で、１回目と２回目には、次のような課題を出して10分くらいでエッセイを書いてもらった（学生数130名程度）。

課題１：重油を使う発電では二酸化炭素排出量が増加するので、温暖化対策のために原子力発電を進めるべきだという考え方がある。重油を使う場合と、原子力を使う場合のそれぞれについて、何が最も大きなリスクで、そのリスクの受け手は誰かについて、あなたの考えを書きなさい。

課題２：築地市場が豊洲に移転することになった。豊洲の土壌が汚染されていることが分かり問題になっている。あなたは、どういう暴露経路で何が起きることが一番問題だと思いますか？

以下ネタバレ注意。

確かに、この課題のリスク比較という課題からは外れるが、このことは重要なことだ。我々は、化石燃料によるリスクを扱っているが、実は、その原料がなくなるかもしれないという条件を考えずに議論していることは、確かに問題である。教えられた。

また、今後10年か15年しか生きることのない私とは違って、学生達は60年も70年も生きる。とすれば、温暖化はともかくとして、石油が枯渇すること、及び、枯渇の過程で起きる値段の高騰や、戦争などについて、少なくとも私よりは不安を大きく感じていることが分かった。

僕も学生たちと似たことを考えた。重油にはいつまで供給が持つかというリスクがある。しばらくはもつだろうけど、底をつきかけてから次のエネルギー源を開発してたんじゃ遅いし、特に日本は資源ないんだし。

原子力のリスクは、廃棄物処理が孫子の代まで負担になりそうなことが真っ先に思い浮かぶ。半減期が短い廃棄物しか出ない炉、毒性が低い廃棄物しか出ない炉ってあるのかな。

築地のほうは正直分からなかった。地下水を食料品の洗浄に使ったりはしないだろうし。豊洲も知らなかったという体たらく。

ともあれ何を考えるにも社会的コストが気になる年頃。

[notice] Twitter

2008-12-08T17:23:03Z

Twitterをpublicにしました。ゴミを公園に捨てるのをためらうのと同じ理由でprotectedにしてたんだけど、ノイズだと感じる人はfollowを外せばよいので、だったらpublicでも一緒かなと。lchinさん、背中を押してくれてありがとう。

https://twitter.com/hisashim

ハードルが低いのを生かして、プライベートなIMに書いて終わりにしてたような狭いことを中心に垂れ流していくつもりです。それでもよければどうぞ。

----

あとはブックマークもpublicにしたいところ。僕は興味が偏ってるので、見る人が見れば面白いかも。だけど、全部publicにすると仕事上差し障りがありそう。部分的に公開できたらいいのにな。

----

というかこのブログロを何とかするのが先ですね。

[event] オブジェクト倶楽部2008冬イベント

2008-12-07T18:12:34Z

オブジェクト倶楽部の忘年会に参加させていただいた。関係者の皆さんに感謝。

第11弾2008忘年会
オブジェクト倶楽部2008冬イベント
『オブラブ忘年会～ふりかえり2008～』
http://www.objectclub.jp/event/2008winter/

* お世話になってる人にお礼を言わなきゃなと思ってたので、果たせてよかった。

* LTはよかった。建設的な自慢話は聞いてて楽しい。

* 一緒に仕事をした方や、お客さん（読者の方）と一緒に振り返りができたのもよかった。

まとめ：
* 自分たちの仕事の成果は役に立っているようだ
* たまには出かけよう
* もっとお客さんの近くにいる努力を

[rant][life] 喪中通知

2008-12-07T18:10:56Z

喪中につき
年末年始のご挨拶はご遠慮させていただきます。

[reading][tips] 本の読み方の手引き（"How to Read a Book"）

2008-12-07T18:09:55Z

本の読み方の手引きを見つけた。簡潔にまとまっていて良い。

How to Read a Book:
Strategies for Getting the Most out of Non-Fiction Reading
http://www.si.umich.edu/~pne/PDF/howtoread.pdf
http://www.si.umich.edu/~pne/essays.html

NEVER read a non-fiction book from beginning to end.

見出しはこんな感じ。

1) Read the whole book
2) Decide how much time you will spend
3) Have a purpose and a strategy
4) Read actively
5) Read it three times
6) Focus on the parts with the highest information content.
7) Use PTML (personal text markup language)
8) Page vs. screen
9) Know the author(s) and their organizations
10) Know the intellectual context
11) Use your unconscious mind
12) Rehearse, and use multiple modes

大雑把なまとめ：レビューするつもりで読めばいい。

その他気になったポイント：

* 時間配分を考えて3周読もう：
- 10%で概要をつかむ
- 60%で詳細を読み込む
- 30%でノートを取る
* ノートはbibliographyに書き込んでしまうと便利。
* その本が書かれた背景や文脈に注意しよう。
* 読むだけでなく、それについて発表し、他者と議論しよう。

----

無関係な感想：

本はもっとwritableになるべきだと感じた。writableなだけでは不十分で、読者の思考を支援できなければいけない。

具体的には、紙と電子データの組み合わせとして利用者に提供する。利用者は、紙を読みつつデータに注釈を加えて、それを他のユーザと共有するような仕組みがよさそう。それなら今の技術でもある程度実現できる。

[book][vcs] 『パターンによるソフトウェア構成管理』

2008-12-07T18:08:23Z

SCMの利用パターンを調べるために読んだ。

パターンによるソフトウェア構成管理
http://www.amazon.co.jp/dp/4798112593/

当初の目的とはちょっと違っていたけれど、とても面白いトピックについて書いていると思う。***.

残念なのは、構成や表現に改善の余地があること。（原著の執筆時に）もう少し手をかけたら、もっと良くなっただろうなと思う。

あと執筆時期がやや古いらしく、CVSは取り上げられているけれど、Subversionやそれ以降のDVCSは触れられていない。逆にproprietaryなVCS/SCMツールの情報が結構載っている。

本来の目的はさておき、いくつか見かけた良いプラクティスをメモ。
SCMはビルドやテストやリリースと切り離しては考えられないということを改めて感じた。

----

branchの方針
------------
* branchの必要がなければなるべくmainline1本で開発する
* 非互換な変更はbranchを切って進める。でもなるべく早くmainlineに還元・復帰しよう。branchしたままの期間が長いとマージのコストが上がる
* branchを切らないなら、stableなbaselineを定義して、それをもとに作業をしろ（rev321は割と安定してるよ、とか）

リリースに関するtips
--------------------
* リリースはbranchを切って隔離して準備する。リリース後はmainlineに還元すること

branchを切る際のtips
--------------------
* branchはmainlineを親にすること。branchからbranchすると複雑になりすぎることが多い

commitのtips
------------
* 意識的に意味のあるchangesetを作ってcommitする
* なるべく頻繁にcommitする

テストのtips
------------
* 粒度の違うテストを使い分ける。commit前には軽いスモークテスト、nightlyで網羅的な単体テストと統合テスト、のように

ビルドのtips
------------
* 重いビルドやテストは人間ではなくサーバにやらせる（CIする）
* リリース時のパッケージングまで自動化する

----

[rant][translation] superfluous translation may spoil us

2008-12-07T18:06:05Z

Translation is necessary for the time being, but *superfluous* translation _may_ not only require extra resources but eventually spoil us.

I wish I could read/write/talk in Spanish and Chinese, besides English.

[job][rant] 愛社精神

2008-12-07T18:04:12Z

愛社精神ってなんだろう。

職業人として報酬に見合った働きをすること、なら分かるんだけど。

[journal] .. 2008-11-20

2008-12-07T17:45:21Z

節目だから振り返っておく。

----

仕事に関してこの10年を振り返ってみると、お客さんに対しても、一緒に仕事をする人たちに対しても、結構いいものを提供できたんじゃないかと思う。僕らの仕事に注目し、やり方に共感してくれる人が現れるまでになった。結果的に会社の利益にも貢献できたはず。

ただ、それはあくまで内側を向いた努力の結果だったように思う。僕も一個人としてはいろいろなコミュニティに参加してきたし、実験的に始めた社外の人との協働も今では定着しつつある。でも、仕事上の立場で、意識して組織外に働きかけるという努力は十分にしてこなかった。

今後は外に目を向けたい。インターネットという自由なチャネルのおかげで、書き手と読み手の区別はよりあいまいになって、出版業の役割も変わっていっている。
これまでの出版業の役割は、ほぼ一方通行に近いパイプラインを運営することだった。一方、これから出版業が果たすべき役割は、書き手と読み手が渾然一体となったコミュニティの中で、参加している人たち同士の知的なやりとりを促進したり手伝ったりすることじゃないかなと思う。
そうするには、今までどおりに内向きで仕事をしているのでは不十分。

これからは、組織の外の人たち、当事者である人たちともっとうまく協力していきたい。そのなかで、どうしたらもっと楽しく有意義なことができるか、一緒に考えたい。

[event][xml] 電子情報通信学会WI2研究会（12/11,12）

2008-12-05T15:00:31Z

これ行きたかったな（既に過去形）。

電子情報通信学会WI2研究会 - IEICE SIG-WI2
http://www.ieice.org/~wi2/next.html
電子情報通信学会 Webインテリジェンスとインタラクション研究会では、来たる2008年12月11日(木)・12日(金)に、神奈川県横浜市にある神奈川近代文学館において，第13回研究会を開催致します。

via http://kunishi.blogspot.com/2008/11/xml.html

おさらいから各分野の研究までを一度に聞けるのがいいな。関東だし、お金も個人で出せる範囲だし。

そういえば2007-12-21の「XML開発者の日」は行けなくて残念だったなあ。余裕がなかったので仕方なかったけど。NVDLの話とか聞きたかった。

どうしたもんだろか。

[publishing][work][translation] 翻訳書の訳者の方へのお願い

2008-11-25T06:25:46Z

もう2年近くも経ってしまったんですねえ。野田さんとのお仕事は、苦しくもとても楽しい、実りある経験でした。

2008-11-03 - flatline＠物工の日記
On Lisp翻訳の回顧
http://d.hatena.ne.jp/flappphys/20081103#p1
計算機関係の某教科書を勉強がてら日本語に翻訳しており，できれば出版まで持って行きたい... という方から私の体験談を求めるメールをいただいたので，その方への返答の抜粋をここに転記してみる．

じゃ編集者の立場からの提案とお願いを書きます。

バージョン管理システムを使いましょう
- バージョン管理するだけでなく、ネットワーク越しの非同期な協働のためにも、ネットワーク対応のVCSは必須です。
オリジナルの原文原稿に基づいて訳しましょう
- 当たり前に聞こえますがとても大事です。
必要に応じて原著者に問い合わせましょう
- 分からない部分をそのままにしては、読者も原著者も不利益を被りますから。
- 原著者も忙しいでしょうから、箇条書きなどに整理して相手がすぐ答えやすい形で問い合わせるのがおすすめです。
原文やオリジナルのマークアップを生かしましょう
- 原文が更新されても追従できるように、タグや原文を削除せず、日本語を追加するようにしましょう。
- もし更新されなくても、errataを反映するのが楽になります。
- Errataは公開されていなくても必ず存在するので、原著者に問い合わせましょう。
対訳形式で出力できるようにしましょう
- コメントアウトするのではなく、ビルド時のオプションで出力を切り替えられるようにしましょう。
- 原文と見比べながらレビューすると、訳文だけを読むのに比べて楽で効率的ですし、良い結果が得られます。品質60-70%程度までは対訳形式でなくてもいける気がしますが、それを超えて詰めていく際には、きっと対訳が役に立つでしょう。
レビューアを募って読んでもらいましょう
- 書き下ろしでも翻訳でも、徹底的なレビューは品質向上への鍵です。トピックに詳しくて遠慮なく意見してくれる人たちにお願いしましょう。
- 誤字脱字は後回しでよいので、方針など大枠の駄目出しを先に。
- フィードバックの集約にはITSを使いましょう。
- VCSやITSに不慣れな人がいたら、使い方を説明しましょう。代理で操作するやり方は、長期的には破綻します。
- いいフィードバックをくれる人にはVCSの書き込み権限を差し上げて、双方とも楽をしましょう。
道具について
- 機械翻訳はたぶんまだ時期尚早かと思います。
- 辞書を何冊か串刺し検索できる環境を整えておくと便利です。
- 翻訳メモリ（OmegaTなど）は、同じ語句が頻出するなら役に立つかもしれません。
- 関連記事
  今使っている辞書
  http://hisashim.livejournal.com/187558.html
  translation-review-helper.el
  http://hisashim.livejournal.com/236028.html
身体に気をつけて
- 長期戦ですから無理は禁物です。

良い結果につながることを、心から願ってます。

頑張って。

[publishing][paper] "Refactoring the Publishing Process"

2008-11-25T04:59:00Z

"Refactoring the Publishing Process"（Steve Loughran, Erik Hatcher, 2006）を読んだ。

「現状の出版物の編集制作プロセスはいまいちなので、ソフトウェア開発のやり方を持ち込んだらどうかな。原稿はちゃんとバージョン管理して共有して、最終成果物は自動でビルドしたいよね」というごく真っ当な主張。

Refactoring the Publishing Process (Steve Loughran, Erik Hatcher)
October 27, 2006
http://people.apache.org/~stevel/papers/refactoring_publishing.pdf

This paper dicusses how the technical book publishing process could address time to market and eBook issues through the adaptation of collaborative software engineering processes to the entire publishing process, from the initial authoring to the final preflight stages.

目次はこんな感じ：

概要

1 はじめに

2 競争原理による圧力
2.1 オンライン書店の成長
2.2 電子書籍（eBooks）の失敗
2.3 オープンソースの挑戦

3 電子書籍を介した共同作業

4 新しいワークフロー
4.1 反復的な開発
4.2 構成管理
4.3 プロジェクトのポータル
4.4 注釈（アノテーション）
4.5 テスト
4.6 読み手の参加
4.7 変更をマージする
4.8 自動化されたビルドプロセス
4.9 好みに応じて調整する

5 未来に向けての展望

6 結論

7 この報告書がどのようにビルドされているか

第4章の前半では問題点と対策を挙げている。

バージョン管理がされていない
電子メールでバイナリを送るのは間違っている
グループ履歴がない
不具合追跡システムがない

1. 反復的な開発
2. 自動化されたビルドプロセス
3. バージョン管理にSCMを使う
4. 電子メールをやり取りするのにメーリングリストを使う
5. 不具合追跡システムで問題を追跡する
6. 大きなポータルサイトの一部としてプロジェクトのスタートページを設ける

目新しさはないけれど、それくらいに、誰もが考える当たり前でまともなことが、よくまとめられている。共感した。みんな考えることは同じだね。

面白いのはアノテーション（注釈）や読み手の参加を重視しているところ。筆者は出版を協働的（collaborative）な活動と捉えていて、そこに参加するのは書き手だけじゃなくて読み手も含まれるというわけ。

僕も出版は協働的な活動だと思っているし、アノテーションは協働において重要で、コンピュータによる強い支援が必要だと常々思っていた。Mondrian（ http://video.google.com/videoplay?docid=-8502904076440714866 ）やRietveld（ http://code.google.com/p/rietveld/ ）といったコードレビューシステムに注目・期待してるのはそのせい。

でも、読み手の参加が大事だから注釈が大事なんだよっていうのはFLOSSファンなのに考えが行き届いてなかった。Pragsが実践している、PDFからITSへのリンクという実例もあるのにね。大事なことに気づかせてくれてありがとう。

[video][architecture][design][agile] "How Buildings Learn"

2008-11-25T04:57:05Z

"How Buildings Learn"が面白かった。

How Buildings Learn - Stewart Brand
1. “Flow”
http://video.google.com/videoplay?docid=8639555925486210852
2. “The Low Road”
http://video.google.com/videoplay?docid=5088653796598486022
3. “Built for Change”
http://video.google.com/videoplay?docid=6141960341438553915
4. “Unreal Estate”
http://video.google.com/videoplay?docid=-8761299882173964035
5. “The Romance of Maintenance”
http://video.google.com/videoplay?docid=5407846553590755822
6. “Shearing Layers”
http://video.google.com/videoplay?docid=2283224496826631552

via http://blog.iaspectrum.net/2008/09/bbchow-building.html

詳しくは元の紹介記事を。

IA Spectrum: BBCのシリーズ番組『How Buildings Learn』を見ました
http://blog.iaspectrum.net/2008/09/bbchow-building.html

本の概要：

aki's STOCKTAKING: HOW BUILDINGS LEARN / digest
http://landship.sub.jp/stocktaking/archives/000012.html

HOW BUILDINGS LEARN
What happens after they're built

(仮題：建物はいかにして学ぶか-建てられたあと何が起きるか）

著者：スチュワート・ブランド Stewart Brand

この要約は翻訳家の村松潔氏によるものです

----

建物が時とともに変化・適応していくべきであるという主張は、Guy Steeleが言う「言語を育てよ」という主張に通じるものを感じた。

建物をプロセスとして捉えるというのは、本にも当てはまるかもしれない。発行後のことも含めて本づくりを捉えるべき。

[lecture][talk] Andres Duany, "San Antonio By Design", 1991

2008-11-23T15:33:23Z

建築家Andres Duanyの1991年の講義を観た。

間違った都市計画のせいで、米国の郊外（suburban sprawl）が町として機能しておらず、人々のquality of lifeに著しい悪影響を与えていることを、ユーモアを忘れずに、でも真剣に強く主張している。

"New Urbanism"
Andres Duany Lecture: "San Antonio By Design" Seminar
1991, San Antonio, Texas
http://youtube.com/view_play_list?p=3F372CFBA3A87C1F

via http://blogs.yahoo.co.jp/giantchee2/34917796.html

講義は全編通してとても分かりやすく、面白い。どこをとっても面白いので、引用しようとするとtranscriptの全訳を載せることになりかねないくらい。

「このパターンに沿って設計すると、町が窒息して成長が止まる。」

「（郊外の大通りとモールの写真を見せて）さて、この（郊外の）都市設計で最も配慮されている事は何か。……自動車にとってハッピーな町であれ、ということだ。」

「この（郊外の殺風景な）ショッピングモールは、セットバックから駐車場の収容力まで、すべてが規制に沿って設計されている。一方、こちらの写真の町並は、（何もかもが普通で良さそうだが）すべてが規制に違反している。」

「大通り（avenue）の周りは価値が上がるが、高速道路（highway）の周りは価値が下がる。」
「高速道路の交差のクローバーは、1葉で昔ながらのロータリーと同じ面積を占めるが、ロータリーが町の価値を大きく高めるのに対し、高速道路は用地取得に700万ドルかかることを抜きにしても、町に価値を全く加えないばかりか周囲の不動産価値を破壊する。その代わりに得るものは何か？ 10秒間早く家に着けるようになる。」

「この建物は強制収容キャンプじゃなくて、子供が通う学校ね。」
「子供は、友だちと野球をするにも親の車で送り迎えしてもらわなきゃいけない。そして親は試合の間中待ってなきゃいけない。送り迎えで日が暮れる。」
「自動車通勤に1時間かけると、年に8週間、車の中で過ごすことになる。2週間の休暇と比べて価値を量ってみてごらん。子供が18になる頃には車の中で3年間だ。夜中じゃなく、昼間の貴重な時間が費やされるんだよ。生活の質を破滅的に下げる。」

この調子で延々続く。

（Paul Grahamは、郊外は子供にとって非人間的で悲惨な環境だと書いたけど、もしこれが本当なら、そうだろうなあと思う。）

New Urbanismには批判もあるようだし、この講義を聴いただけでは見方が一方的になっている危険性があるけど、大筋で納得がいく。1991年の講義だけど、2008年現在のほうが自動車社会の行き詰まりがはっきりしている分身近に感じる。自分も、維持できないシステムには先がないということを最近強く感じる。ライフスタイルにしてもビジネスにしても、維持できる（sustainable）かどうかという観点が必要だなあと思う。

（残念なことにこの問題には即効性の対策というものはなくて、何年も何十年もかけて市民社会の成熟度を上げることでしか解決できないだろうと思う。だから自分の身近なところから始めるのがよさそう。無駄な物を持たないとか、公共の交通機関や自転車を使うとかね。

）

----

85分はちょっと長いよという人は、この講義と同じく郊外型の生活の問題を取り扱った映画のトレイラーが、凝縮されててよいかも。

Radiant City Trailer
http://youtube.com/watch?v=pFNdQDBy2rY

The End of Suburbia promo trailer
http://youtube.com/watch?v=qHr8OzaloLM

Escape from Suburbia: Beyond the American Dream Trailer
http://youtube.com/watch?v=J2y9BbNjLAY

----

参考資料：

Duany Plater-Zyberk & Company
http://www.dpz.com/

Suburban Nation: The Rise of Sprawl and the Decline of the American Dream
Andres Duany, Elizabeth Plater-Zyberk, Jeff Speck
http://www.amazon.com/dp/0865476063/

New Urbanism
http://en.wikipedia.org/wiki/New_Urbanism

[talk][business] Guy Kawasaki, "The Art of the Start"

2008-11-23T14:57:21Z

Guy Kawasaki（ http://en.wikipedia.org/wiki/Guy_Kawasaki ）の2004年のトークをまた聴いた。たまに聴きたくなるらしい。

とても話がうまくて、2008年の今でも抜群に面白い。技術系ベンチャーとは無縁の人間が聴いても、得るものはたくさんある。小一時間と手ごろだし、聞き取りやすいし、おすすめ。

Guy Kawasaki, Garage Technology Ventures
"The Art of the Start", 2004-10-20
http://ecorner.stanford.edu/authorMaterialInfo.html?mid=1171

Play all in a new window
http://ecorner.stanford.edu/playerPopup.html?groupId=45

1. 02:37 Make Meaning in Your Company
2. 05:00 Don't Write a Mission Statement, Write a Mantra
3. 03:41 Get Up and Get Going!
4. 03:18 The New Business Model
5. 03:20 Weave a MAT and Outline Your Priorities
6. 03:35 Know Thyself and Niche Thyself
7. 02:51 Make a Great Pitch
8. 06:20 Who to Hire
9. 03:44 Lower the Barriers to Adoption
10. 03:57 Seed the Clouds and Watch the Sales Grow
11. 03:02 Be a Mensch
12. 01:55 Funding Choices
13. 01:52 How Do You Find Evangelists?
14. 02:04 How Do You Find Soul Mates?
15. 03:25 The Career Path to Becoming a Venture Capitalist or an Entrepreneur
16. 03:27 Experience Is Overrated

今回の僕にとってのハイライトはここ：

"My naive and romantic belief is that if you make meaning, you will probably make money."
（「うぶで夢見がちな考えかもしれないけど、僕はこう信じてるんだ。（他人を幸せにするような）意義があることに取り組んでいれば、たいていお金はあとからついてくるって。」）

お金の意味は本来そういうものだろうと思う。

で、僕のマントラはたぶん"Quality books."

[memo][tip][sysadmin] sshfs

2008-11-23T14:54:43Z

Installation
------------

server% sudo apt-get install openssh-server
client% sudo apt-get install sshfs fuse-utils

Configuration
-------------

client% view /usr/share/doc/sshfs/README
client% view /usr/share/doc/sshfs/README.Debian
client% sudo adduser jdoe fuse
client% exit #(or su --login jdoe)

client% sudo edit /etc/fuse.conf
user_allow_other
client%

Testing
-------

client% id | grep fuse
client% sshfs 'johnd@example.org:/home/johnd' \
  /home/jdoe/johnd \
  -d \
  -odebug,sshfs_debug,loglevel=debug3,identityfile=~/.ssh/id_foo

Usage
-----

client% sshfs 'johnd@example.org:/home/johnd' \
  /home/jdoe/johnd \
  -oidentityfile=~/.ssh/id_foo,idmap=user,allow_other

client% fusermount -u ~/mnt

Note
----

* Use latest software (including kernel)
* Make sure to use same version of sshfs on client/server