ばばばばばばばばばばばば

あばばばばばばばばばばばばばばばばばばばば

SIMフリー海外端末を購入してからやった事

・Xperia Arc 2011年3月購入。端末代金はローン式で月々サポートで支払い。
・FOMA プランSS+パケホーダイフラット
・SPモード契約
・FOMA miniSIMカード
な状態から
・タイプXi にねん+Xiパケホーダイフラット
・カケホーダイ契約ナシ
・mopera契約
・Xi microSIMカード
に変更した際のまとめ。

上記の通り2年縛りの最中の変更だけど2年縛りの違約金支払いは無し。
Xiへの変更事務手数料2000円。これは来月分の利用料金に上乗せで請求される。
FOMAからXiに切り替えた事で月々サポート消滅。つまり以後端末代金を実費で支払う必要がある。月々払うの面倒なのでここで一気に残額支払い。手数料等の発生無し。
SIMカードをminiからMicroに切り替えるのは無料。これはFOMAからXiに切り替えたのとは関係なく切替は年一回無料だから。

という事で窓口で支払ったのは、XperiaArcの残額支払いのみ。つまり端末残高残ってない人は窓口ではゼロ円になるはず。
で来月の携帯料金が+2000円。
んでTHE END

あ、あとSPモード契約捨てたので、docomoのメアドなくなります。Gmail一本。

LevelDBのインストール

sudo aptitude update
sudo aptitude install build-essential python-dev automake libtool subversion pkg-config
sudo aptitude update
mkdir svn
cd svn
svn checkout http://py-leveldb.googlecode.com/svn/trunk/ py-leveldb-read-only

cd py-leveldb-read-only/snappy-read-only/
./autogen.sh
./configure
make
sudo make install

cd ../leveldb-read-only/

cd py-leveldb-read-only/leveldb-read-only
make
cd ..
./compile_leveldb.sh
sudo python setup.py install

説得ではなく納得を。説明責任を果たすという事

某鷹野さんや某今井さん程整理して書いてないので悪文かも。

docomoの障害の件、最近のAndroidやiPhone用アプリの勝手な個人情報取得と勝手な利用、政治全般、ステマ騒動、新聞、2chまとめ系の聚落。
これらの問題に共通しているのが実は「説明責任」にまつわるモノなんじゃないかなと最近思い出した。

例えば政治に関して言えば、「説明責任を果たしていない」部分が多すぎる。
何故マニフェストを破ってまで政権を続けるのか、何故TTPに参加するのか、何故増税するのか。

取り敢えず私は彼らから充分な説明をもらったという感覚はない。確かにTVや新聞経由で復興の為、国民の為というお題目は聞く。しかし「では幾ら必要で幾らを何に使い幾らを何に使った上で、幾ら程の効果が生まれるのか」等の具体的な数値を伴った説明は殆どない。或いは数値があったとてその根拠の説明がない事もザラだ。

同時にこれはdocomoにも言えるだろう。確かに最近のスマフォの増加で通信量が増えた、というのは何となく解るがホント？という疑念は払拭仕切れない。
やはりここでも重要なのは具体的な数値とその数値の根拠の説明だ。

またAndroidやiPhoneのアプリに見られる個人情報の不正取得と不正使用。これも簡単に言えば利用者に対する説明責任を果たしてない事が問題だろう。
この手の話題を出すと「FacebookやGoogleも同じだ」と指摘する人がいる。確かにそれは正しい。基本的には同じく個人情報の利用だろう。だが少なからずFacebookやGoogleや用途や目的、利用方法を示している。それを承知した上で利用を許諾している訳だからある意味で利用者は文句を言えない。
しかしその部分をぼかしたままで利用者に利用させた以上、責務を問われるのは当然だと思う。
同じ意味で最近のSNSのアコギな金稼ぎもこれが問題だろう。課金のタイミングや課金量がどうなるか等の説明責任を充分に果たしていない。ソーシャルゲームがいまいち気に入らない人々がいるのはこれが原因だろう。


そして報道に関して。
本来報道というものはこの「説明責任を果たす事を補助する装置」だろう。例えば為政者が説明責任を果たす事なく何かを行おうとすれば、それを問うのが役目の筈だ。或いは為政者が説明責任は果たしたがそれを一般の人々は理解出来そうにない。だからこそそれを理解出来る様に説明するのが報道の役目だろう。

しかし今や報道の多くが如何に「説明責任を省くか」という点に力を入れている様に見える。
情報の単なる転送。偏向としか思えない報道。理論が飛躍した結論を付けた報道。お金の力で動かされているとしか思えない報道。

そしてこれは最近のステマや2chまとめ系にも言える。
過去、インターネットのこういったサイトは従来の報道機関が放棄し始めていた「説明責任を果たす事を補助する装置」としての役目を少しは担っていた。しかし最近はその様な機能よりもステマや従来の報道並み、或いは従来の報道以上に偏向、論理の飛躍等が目立つ様になってしまった。

ステマだって別に堂々とお金をもらったと宣言した上で広告すればいいじゃないか。それで売り上げが伸びれば企業側も執筆者も満足だろう。逆に売り上げが伸びなければその執筆者は金が入らなくなる訳だし、企業側は素早く有用な執筆者とそうでない執筆者を判断出来る様になるだろう。

そして最後に説明をしてもらう側に関して。こちら側のポイントは
・説明責任を果たす場の拒否
・思考停止
・知識不足
の3つだ。
最近とに目立つのは説明を求めて起きながら説明責任を果たす為の場を用意させない事だろうか。
説明しようとする側が何か言おうとすれば無視をしたり邪魔をしたり、根幹から否定する等して聞く耳すら持たない。或いは自分から知識を身につけないという点だ。2chやSNSで言えば荒らしがこれに相当するだろうか。

残りの二つは密接に関係している。思考停止しなければある程度知識不足を補う事が出来る。知識があれば、ある程度の思考停止を防ぐ事が出来る。
最近で言えば放射線に関してがこれだろう。放射線に対してある程度の知識があれば、トンデモ放射能の話がおかしいと気付くだろう。或いは情報を鵜呑みにせずしっかり自分の頭で考えれば知識がなくても何か違和感を感じて自分で調べた上で、言っている事がおかしいと気付くだろう。
ただ放射線に関してかなり突っ込んだ詳しい説明をもらう場合は聞き手もある程度の知識が必要である。精確に伝えようとすればする程に専門の知識が必要になる事はザラだ。ここで受信者側が「お前の話は難しい！もっと分かり易くしろ」と叫ぶのは上述した「説明責任を果たす場の拒否」に繫がるだろう。

ちょっと例を使って言えば、何らかの事象があった場合それは魚や肉の様な素材である。それを元に発信する側は料理人であるそして情報を受信する側は食い手である。
如何に優秀な料理人だとて、かみ砕く力が弱過ぎる客に、その素材を生かした料理を食わせるのは難しい。例え出来たとしてもそれは最早素材が何であったか解らない代物だ。情報で言い換えればそれは既に本来の事象を伝える事が出来ない何か別のモノになってしまっている事だろう。
そういう意味で情報の受け手はアゴを舌を鍛えておく必要がある。アゴが強力であれば料理人の手を介さずに直接その素材を食べる事が出来る。そして舌が強力であれば料理人が何かごまかしを加えたとて見抜く事が出来るだろう。


あとちょと注意したいのは、別に言葉だけが説明責任を果たす手段ではないという事だ。
例えばいい例がApple。というかジョブスか。
ジョブスがiPhoneを世に出した時、キーボードがない事に対してもの凄い批判を受けた。しかしジョブスは「まぁ使ってみなよ」というスタンスで商品をアピールし続けた。結果として利用者は後で「あぁキーボードって余り重要じゃないんだ」と気付いた訳だが、ジョブスがこの様な事を強行できたのは「いざと成ればキーボードが不要な理由を充分に説明する事が出来るし、不要だと言い切れるまで考え抜いた」という自信があったからだろう。
これがジョブスなりの説明責任の果たし方だ。
これはプログラマの開発者にも言える。キーボードがない事はある意味でバグだ。しかしジョブスはそれがバグでない理由を説明出来た。
最近ではプログラムの開発者の人が多いと思うが、自分がプログラムを作る際には優先順位を決めてある機能は後回しにする事がある。では貴方はその後回しにした機能がなぜ後回しになったのか説明仕切る事が出来るだろうか？
或いは言い方を変えれば、バグがあったとしても何故バグがあるかを説明出来れば、それはそれで問題ないのではないだろうか。
恐らく最近の日本の製品はこの点がおろそかになっている気がする。

或いは日本で言えば切腹もこれに相当するのではないかと私は考えている。確かに今でこそ切腹や辞任等なんて無責任の象徴になっているが、戦国時代で言えば武士なんていつ死ぬか解らないし、やろうと思えば周り全部ぶった切って逃げる事が出来るかもしれない。そんな中で自ら腹をかっさばくというのは、関係者に対する説明責任を充分に果たしている様な気がする。飽くまでコレは当時の文化が元になっているから、当時の人々がサムライとはこういうモノだと理解して居たからだろう。


さて最後に一番重要な事を一つ。
「説明責任を果たす」とは相手を説得する事ではない。納得させる事だ。

ジョブスは我々にキーボードがないけど使えと説得してきただろうか？
違う。
ジョブスは我々にキーボードがなくても全然問題ない言う事を納得させたのだ。

そしてこれはここに上げた全ての事例に通じる。
今現在の為政者は増税に関して我々を納得させただろうか？仕切りに説得に従事していないだろうか？
docomoは、アプリ開発者は、機能を省いた開発者は、利用者に対して納得のいく説明をしただろうか？
バグが残ったままの状態を開いてに納得してもらえるだけの説明が出来るだろうか？
貴方は仕事上、相手に納得してもらった上で仕事を渡しているだろうか？

貴方は親として子供にやっていい事、やっては行けない事を説明する責務を果たしているだろうか？
お金に付いて、経済について、政治について、哲学について、性知識について。
これらを説明せずに子供を放置するのは、親の責務の放棄でもあり、説明責任の放棄だ。

そして受信者としての貴方は、納得する為に自分で考え、自分で知識を得ているだろうか？
アゴを鍛えているだろうか？
そして発信者としての貴方は、キチンと相手に納得してもらえるだけの説明をしているだろうか？

と、ここまで書いておいて私は一つだけ説明責任を果たさなくていい、というか果たせないであろう事があると考えている。
それは告白する時だ。
彼を好きな理由、彼女を好きな理由を挙げる挙げられるという事は嫌いになる為の理由を挙げているという事だ。本当に誰かを好きになってしまった場合そんな事等考えられない筈だ。
だからこそ、告白は唯一説明責任が伴わない行為だと思う。

という厨二病くさい落ちが付いた所で終了。

クラウドとはなんぞや

ちょち最近クラウドについての話題がGoogle+で出てくるんで書いて見た。
長文すまん。

■仮想化の流行
ここではCPUの仮想化、サーバの仮想化に絞って説明する。簡単に言えば「一つの物理サーバ上で複数のOSを同時に動かす」事である。この仮想化が流行ったのは以下の理由だ。

• CPUの性能向上手段がマルチコアに切り替わった
• 従来のプログラムの多くがマルチコアを活用しきれない

今までのCPUはコア自体を改善する事で性能向上を果たしてきた。その為多くのプログラムは1コアを前提として作成された。それでもCPUのコア性能がどんどん改善された為プログラムを放置しておいてもプログラムの処理速度は向上していった。しかし最近になりCPUのコア改善によるCPUの性能向上が頭打ちになった為、CPUは出来るだけ沢山のコアを詰め込む事で性能を向上させる手段に出た。多くのプログラムはマルチコアを想定して作られていないので、沢山あるコアを活用出来ず、プログラムの処理速度は向上しなくなってしまった。簡単に言えば8コアあっても1コアしか活動していない状況になってしまったのだ。
8コアあっても1コアしか活動してないのであれば非常にもったいない。元が取れていない。

そこで従来のサーバを仮想化し、8コアの物理サーバに8個の仮想サーバをぶち込めば、CPUコア全てを使い切る事が出来る、と考えて始まったのが仮想化の流行である。更に言えば8個の仮想サーバはそれぞれ役割が違うだろう。それぞれの仮想サーバが高い処理能力を必要とする時間がずれていれば、8コアじゃなくて4コアでも充分かもしれない。であれば8コアの物理サーバに16個の仮想マシンを入れる事も可能である。
極端な話を言えばそれまで100台の物理サーバで運用していたサーバ群を仮想化して5台の物理サーバ上に集約する事も可能な訳だ。

■過剰集約問題

しかし場合に依っては「100台のサーバ群の総合性能≒5台のサーバ群の総合性能」なパターンが生まれる事がある。生まれる理由としては以下の様なモノが考えられる。

• 無計画な集約
• 仮想化環境への追加投資が出来ない為の過剰集約

これを防ぐには以下の対策が必要である。

• 最大負荷時を想定した仮想化環境の準備
• 仮想化環境利用の制限

この様な対策をする位であれば仮想化による集約を行わない方が良い。前者の対策をとる場合、仮想化対象の物理対象の総費用より仮想化環境構築用のサーバの総費用の方が高くなる可能性すらある。

■余剰リソース問題
過剰集約が怖いので少し余裕を見て10台の物理サーバを仮想化し5台のサーバに集約したとする。が、しかし予想以上に仮想サーバは利用されず効果な仮想化用物理サーバが遊んでしまい投資コストの回収が出来なく成ってしまう。

※投資コストの回収･･･高いモノを購入した後それをシコタマ使って元を取る事。投資コストが回収出来ないといった場合、それは高いモノを買ったはいいけど余り使ってない状態になってしまう事。

■仮想化からクラウドへ
そこで以下の様なパターンが生まれてくる。

社内のサーバの仮想化による集約は成功した。しかしリソースが余っている。もったいない。何かいい方法はないか
まてよ？この余剰リソースを外部に有料で貸しだそうか。そうすればサーバの稼働率も上がって投資コストも回収出来る上に儲かるぞ
まてよ？儲かるんであれば大規模な仮想化環境を用意してその上の仮想リソースを販売すればこれはビジネスになるんじゃないか？
しかも利用者は、必要な時に必要なだけのリソースを私から借りればいい。初期コストはゼロだ。

 これを実践したのがクラウドサービスである。

■クラウドの境界線
日本国内では「仮想化すればクラウド」と誤認される事、誤認させる記事や情報が多いが、仮想化は飽くまでクラウド実現の一要素に過ぎない。仮想化とクラウドは別ものである。具体的に言えば以下の通りだ。

・仮想化用の物理的サーバを保有或いは確保した時点でそれはもうクラウドではなくなる。


「本当のクラウド」の利用者は自分達で物理サーバを用意する事はない。つまりこの時点で国内で推進されようとしている「自社内に作成するプライベートクラウド」は否定される訳だ。

・必要な時に必要なだけリソースを借り、不要な時は不要なリソースを捨てる事が出来、そしてやめたい時は即座にやめる事が出来なければクラウドではなくなる。


この時点で課金単位が月次、週次、日次であるサービスは否定される。人間の生活サイクルを考えた場合サーバの負荷の変動は一日毎にサイクルしていくだろう。であれば課金単位は時間単位であるべきである。究極の所、理想は秒単位であるが手間を考えたらやはり時間単位に落ち着くだろう。
同時に時間単位課金であれば、リソースを借りる速度(申し込みしてから実際にリソースが渡されるまでの時間)が1時間以下である必要がある。「今日申請したら明日利用出来ます、来週から利用出来ます、来月から反映させます」なぞというのは問題外だ。

仮想化ではこの様な事が出来ない。
仮想化によるサーバ集約だけではここまでは出来ない。
プライベートクラウドではこれを実現出来ない。
つまりここクラウドの境界線である。

■クラウドの真髄
イノベーションとはそれまで出来なかった事が出来る様になる事である。世に言うイノベーションを例に挙げると例えばテープに対するCD、CDに対するMP3とか。
例えばCDはそれまでテープでは不可能だった瞬時の頭出し、精確な曲送りを可能にした。
例えばMP3はそれまでCDでは不可能だった自由な曲の組み合わせ、移動の簡単さ、バックアップの簡単さ、再生の簡単さ、保存の簡単さを実現した。

ではクラウドがイノベーションである点は以下の通り。

• 従来では保持出来なかった様なリソースを利用する事が出来る
• 不要なリソースを保持する必要がない

どちらも従来の社内サーバ環境で実現する事は出来ない。同時に仮想化による集約を行っただけでは実現する事が出来ない。
クラウドでなければこれらのメリットをもたらす事が出来ないのだ。

例えば分散処理を考えてみよう。ある会社で給与計算が分散処理で行えたとする。ここではAmazon EC2をモデルに話をする。

さて給与計算は基本的に一ヶ月に一回だ。
なので30日中「給与計算をする為に必要なリソース」は一日だけであるとする。であれば残り29日間は給与計算の為のリソース(給与計算をする為のサーバ)を持っている必要はない。つまり費用はゼロ円である。

「さーて今月は特に急いでないから計算に一日かかってもいいや」と成れば、「性能は低いが一時間辺りの利用料も格安のクラウド上の仮想マシン」を一日借りて計算すればいい。
「やばい！明日給与支払いなのに計算してねぇ！後12時間しかない！ええい多少金かかってもいいから確実に終わらそう！」と思えば「性能は高いが一時間あたりの利用料金も高いクラウド上の仮想マシン」を複数借りて一期に分散処理してしまえばいい。

勿論給与計算が終わったらそれらのリソースを解放する。そうすれば再びコストはゼロだ。
そしてこのコストがゼロに出来る、まぁ精確に言えば不要な時はコストを極小化出来る、という事がクラウド最大のメリットだと思う。これは従来の物理サーバ購入では絶対に実現しえない事である。

■クラウドの定義
最後にまとめ。クラウドと呼ぶに値するサービスが備えるべき条件

• 初期費用がゼロである
• 利用した分だけ課金される（金さえ払えば無尽蔵にリソースを利用出来る）
• 下院単位は最低でも時間単位である
• 利用者からみて無尽蔵に見えるだけのリソースを確保出来ている
• リソースの要求をしたら遅くとも1時間以内に利用する事が出来る

と言った所ですか。

Sphinxのバージョンアップをする

Sphinx1.1から1.1.2に上げた時のメモ。

Sphinxの最新版を手に入れる。PythonのこのページからDL出来るっぽい。

■事前にやる事

/usr/local/lib/python2.6/dist-packages/Sphinx-1.1-py2.6.egg/

の中にあるthemeとか加工したソースとかを待避させておく事。

■旧Verの削除と新Verのインストール

sudo rm -fr /usr/local/lib/python2.6/dist-packages/Sphinx-1.1-py2.6.egg
wget http://pypi.python.org/packages/2.6/S/Sphinx/Sphinx-1.1.2-py2.6.egg#md5=d35db7a8ee62dd55522bca523954baa9
sudo easy_install Sphinx-1.1.2-py2.6.egg

終わり。

今日のsphinxメモ

sudo vi /etc/apt/sources.list

deb http://ppa.launchpad.net/vineuser/ppa/ubuntu oneiric main
deb-src http://ppa.launchpad.net/vineuser/ppa/ubuntu oneiric main

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0C95CAFC

sudo add-apt-repository ppa:vineuser

sudo aptitude update

sudo apt-get install texlive texlive-base ptex-base ptex-bin dvipsk-ja xdvik-ja ptex-jisfonts gs-cjk-resource jmpost dvipdfmx texlive-math-extra okumura-clsfiles jbibtex-bin mendexk texlive-latex-extra nkf dvipng python-software-properties python-sphinx

SphinxでHTMLでもPDFでも見やすい文書を一発で作る

昨年の秋位から Sphinx を本格的に使ってきたので色々メモした事、やった事をまとめて見る。Whyの部分は後で拡充するかも。

後これは俺が買って考えた事なので、これよりいい方法とか知ってる方いたら是非に教えてください。マジで。ホントに。
尚Sphinxを使える用にして、PDFまで出力出来る様にする方法は Sphinxとrst2pdfの「domains」がないよエラー を参照してください。


■やらないといけない事
取り敢えずやらないといけない要件は以下の通り。

1. HTMLはHTMLで見やすく。PDFはPDFで見やすく。
2. PDFは各章に通し番号を振る。HTMLは振らない。
3. PDFは見出し必須。しかし見出しに載せる深さは2番目まで
4. 内容的に同一の文書を使い回す場所がある。

これに加えて、HTMLとPDFの両方を作る場合以下の問題もあった。(今はもう Sphinx とか rst2pdf 側で対応してるかもだけど。)

• HTMLを重視する場合、toctreeを使えば1ページに見出しだけが全てそろうので目的のページを探しやすく移動しやすい
• PDFの場合、toctree を使って書くと章の番号を振るのがおかしくなる。
• toctree はリンクになってしまいリンク先のページは個別で評価、変換されるっぽいのでPDFの場合だと章段落の程度がおかしくなる
• include を使えば多数のファイルをマージして(1ファイルにして)から評価変換される用なので章段落の程度がおかしくならない。しかしHTMLだと一個のHTMLが巨大化してしまい死ぬほど見にくい。

つまり toctree は HTML と相性が良く、include は PDF と相性が良い。


■HTMLとPDFとを分けて考える
という事で「HTML用のRootドキュメントとPDF用のRootドキュメントを分ければいいんじゃね？」と考えて、調べてみたら出来るっぽい。Sphinxの conf.py の以下の場所の「indexPdf」の部分を変更する。

pdf_documents = [ ('indexPdf', 'Manualタイトル', u'Manualタイトル', u'Author', 'manual'), ]

初期値だとHTMLのと同じ奴に設定されてるけど、ここを変更するとPDFを作成する際はここで指定されたファイルをRootドキュメントにして作成してくれるようになる。こうしておけば make html pdf って一個のコマンドで違う構成ファイルを元にしたHTMLとPDFとが同時に作れる様になる。


■RSTファイルの構成
次に実際に利用するRSTファイル群は以下の様な構成に成っている。

• index.rst ･･･ HTML用のドキュメント構成。ページ構成のRSTファイルを toctree で記述。
• indexPdf.rst ･･･ PDF用のドキュメント構成ページ構成のRSTファイルを include で記述。
• page.rst ･･･ 章構成。実コンテンツの本体。基本的に重複のない文書を書く。HTML用もPDF用も共通。 paragraph.rst を全て include で記述。 
• paragraph.rst ･･･ 各パラグラフ。使い回す可能性のある文書はここに書いている。HTML用もPDF用も共通

index.rstは以下の通り

########
各章タイトル
########


.. toctree::
:maxdepth: 1


hoge
fuga
pugya
homu

indexPdf.rstは以下の通り。PDFの場合、各章の頭に数字を振りたいのでそのコマンドを先頭に入れておく。

.. section-numbering::


########
各章タイトル
########


.. include:: hoge.rst
.. include:: fuga.rst
.. include:: pugya.rst
.. include:: homu.rst

Sphinx公式のセクション管理 にSphinxでのセクション管理の例が載っているけど、私は以下の様なルールでセクションを利用している。
ただしpage.rstに関してはかなり流動的。使い回す可能性のない説明であれば、一番したのパラグラフまで使う事もある。

• # 部: オーバーライン付き ･･･ index.rst/indexPdf .rst で使用
• * 章: オーバーライン付き ･･･ page .rst で使用
• =, セクション  ･･･ page .rst、 paragraph.rst で使用
• -, サブセクション  ･･･   paragraph .rst で使用
• ^, サブサブセクション  ･･･   paragraph.rst で使用
• ", パラグラフ  ･･･   paragraph.rst で使用

■ PDFでの改ページ処理
一応rst2pdfには自動改ページ設定機能があるがこれが結構微妙。ルール一辺倒なのでいやここは･･･って所でも改ページしてしまう。なのでこれを使わず、面倒だけど自分で改ページを指定する事にした。

まずconf.pyの以下の設定をコメントアウトして自動改ページを無効にする。

#pdf_break_level = 2

で代わりの改ページ指定は、改ページしたい所に以下の記述を加えておく。これを入れておくとHTMLの方では何も出力されない。だけどPDFを出力する時のみ改ページ処理が行われる。

.. raw:: pdf


PageBreak

なお私が作ったドキュメントではこのPDF用改ページコマンドをpage.rstに末尾に必ず追加している。


■DPFの目次管理
次にPDFでのページ管理。toctreeを使うと目次っぽいのが勝手に出来るけど、includeを使うとそれが生成されない。なので rst2pdf の機能を使って目次を生成する。
また目次を設定する際、上から2番目(1.1 インストール方法)までを目次に載せるように設定する。これを指定しないと全てのセクションが目次に載ってしまう。(例えば 1.2.3.4.5 注意 とか)。
その為に conf.py に以下の設定を追加する。

pdf_use_toc = True
pdf_toc_depth = 2

目次に載せるセクションの深さは数字で自由に変更出来ます。


■ただ一つの欠点
これでHTMLとPDFの両方が見やすくなったと思う。
ただ唯一新しい章を追加する際にindex、indexPdfの2つに記述しないといけない事が面倒だけど。

参考になるURL

• はやわかり reStructuredText
• reSTおよびSphinxで文章を書く際のtips
• rst2pdf公式マニュアルPDF
• Sphinx-Users.jp