\ay diary

iPod touch(やiPhone)で使えるPDFリーダーでコメントをいれられるものはないかなと、何度目かの探索をしていたところ【iPhoneアプリ】下線やマーカー機能の使えるPDFリーダー､Aji Annotate PDFがかなり便利！という記事に出会った。

少しまよったが紹介されているAji Annotate PDF 2.5.1を試してみたところ、なかなか使えそうな感触を得た。

(その他のスクリーンショット)

PDFの取り込みはHTTPでのダウンロードか、専用ツール(Mac用とMS-Windows用のみ)を使っての同期による。iPod Touch側で用意されたすべての操作を行うにはこの専用ツールでの同期が必要なようで、Linuxなど他のOSからの利用では残念ながら機能が限定されることになってしまう。

それでもPDFの閲覧はもちろん、コメントをいれるくらいのことならHTTPダウンロードだけで可能である。ただし、そうして操作を加えたPDFをアップロードすることは、あまり詳しくは見ていないけれど、HTTPでというわけにはいかなうようだった。

同期ツールを使うのであれば機能的に十分だが、それら機能について以下のような問題もある。

• 日本語での検索はできない。日本語の文書でも英単語での検索はできる。おそらく専用ツールでのインデックス処理が英語以外に対応していないのではないか。
• ハイライトや下線を付ける際、文字単位ではなく、おそらく英語のワード単位での指定になってしまう。このため日本語の文書では、タップしただけでほとんど一行全部が対象となってしまい、しかも範囲を狭めることができない。選択の最小単位の問題は前項と同根だと思われるが、それはともかくとして選択範囲を狭める機能が欲しい。
• 文書に直線やフリーハンドの線を描く機能を使って水平や垂直の線を引いても、それを保存することができない(確定しようとすると消えてしまう)。

手元のiPod touchは第一世代(であっるてるのかな? スピーカーのないタイプ)で、数百ページのPDFで試してみたところではそれほどストレスを感じるということはなかった。ただ、使いこんだというわけではなく、気になるところを触わっただけの段階であって、たとえばページ数が多いときとか、図やイメージがあるとどうかとか、コメントなどがたくさんあるとどうかとか、そういったことは確認できていない。

前述の通り問題点もいくつかあるが、PDFにコメントをいれられるアプリケーションが他になさそうであることもあり、十分に使えそうな感触を得た。まずは某レビューのために使ってみよう。

4月24日に発売になるWEB+DB PRESS Vol.50[rakuten]で「Unix/Linux開発環境ミニマルスタイル」という記事を書かせてもらいました。

主な作業環境はMS-Windowsだけれども、本番環境はUNIX系OSである。本番環境での作業にはいつも通りの手順(や決められた手順)があるから困りはしない。ただイレギュラーな状態になると手も足も出ない(かもしれない)。コードやログを持ってきたり持っていったりを繰り返すのも煩わしいし、UNIX側でできることがもう少し増やせるとよいな。そんな人々に向けた記事です。

端末・シェル上での操作の基本を扱います。基本的なコマンドの紹介、リダイレクト・パイプの仕組みと使用例、コマンドを組み合わせて使う方法などを説明しています。環境としてはDebian/Ubuntuを想定しています。また、近年、一般的に使われるようになってきている仮想環境(andLinux、VMware系プロダクト、VirtualBox)を念頭に、パッケージ運用管理の基礎的な部分もカバーしました。

今号ではJunio C Hamanoさんの大ボリューム特集記事「はじめてのGit」で、基本的なところからから、一般的な使い方としては十分すぎるくらい深いところまで、かなり広範かつ詳細な解説がなされていて読みごたえがあります。またknuさんのPractical Ruby Programming!(6)では誰もが使うようになってきているTwitterと、注目されつつもなかなかブレイクしかけてますという状況が続いているFriendFeedの、それぞれのAPIを使って両者を結び付けるプログラムtw2ffが作成されていています(tw2ffはruby-friendfeedに含まれています)。

今号の内容からは離れてますが、FriendFeed関係では、携帯電話端末などからFriendFeedを使いやすくするf2pというアプリケーションもあります。当初はまはさに携帯からFriendFeedを使うために利用していましたが、「後で読む」機能や地理情報付きのポストができるなど、FriendFeedの標準的なインタフェースにはない機能があるため、最近ではPCでもf2pを介してFriendFeedを利用することが多くなっています。

ruby-friendfeedもf2pもGitでアクセスできるgithub上にありますから、Git大特集から読み進めると、自然とFriendFeedまでたどりつくようにできていますね。加えていえば、同時期に発売されるSoftware Design 2009/05の「はてな流! システム管理のツボ(10)」ではCapistranoが扱われていますので、あわせて読めばRailsアプリケーションであるf2pのデプロイも万全です。

そういうわけで、聞いたことはあるけれどもまだ使っていないという人は、これを機会にFriendFeedを始めてみてはいかがでしょうか。

(ちなみにSD誌の特集ではUbuntuが扱われています。私の記事とともに、などというのはおこがましいですが、これからUbuntuを始めるという人は参考にしてみてはいかがでしょう。)

できるコンサルタントになる方法 - ぽっぺん日記@karashi.orgで紹介されている売れるコンサルタントの「仕事の技術」[rakuten]の中に「本の執筆と出版の位置付け」という章がある。コンサルタントが自身のノウハウなどを本にするメリットと、一冊の本として形にするまでのプロセスを扱っている。

その内容からはちょっと離れるのだけど、雑誌記事を書くときの私のプロセスはどうなっているのかをふりかえってみた。

1 ネタ出し

まず記事のネタがある。ネタ作りがどのようにされるかはその時々で違うが、おおまかに分ければ以下のようになる。

• 依頼がくるケース
• ネタを持ち込むケース
• 原稿を持ち込むケース

私の場合、たいていは依頼がきたことでプロセスが始まる。自分でネタを持ち込むのは書きたいことがあるときか書いてみたいことがあるとき。書きたいよりも書いてみたいのほうが多いかな。これまであまりないけどたまにある。

本当は(ラフな)原稿といっしょにネタを持ち込めると良いのだろうけど、そこまでできたことはこれまでのところない。

2 テーマ・ストーリーの決定

自分でネタを考えたときでも、依頼されたときでも、テーマやストーリーは改めて考える。この時点では雑誌記事としての企画が通っているので、編集さんといっしょに調整しつつ考えることになる。

もちろん自由にできるわけではなく、時間や分量に応じて書けることと書けないことが出てくる。企画内容や他の記事とのかねあいで書いてほしいこと、書かなくてもいいことがあることもある。

依頼されたときには最初のステップがここになるのだが、内容や期日を確認して断ることもある。また得意な分野かそうでないかということでも。ついでにいえば、記事で扱う内容はよく知っているけども記事にするのは難しいということもある。

それられいろいろを合わせつつ、記事のテーマ=記事のねらいと読んでもらうためのストーリー展開を決めていく。

よく言われるのは、読者が「読みたい」ものを書かなければというやつだが、依頼があったときにはそのような内容になっているはずなのであまり考えない。自分でネタを出した場合は、編集さんとの調整をすることでそのような点をクリアできる(はず)。いずれにしても企画の意図の確認はきちんととしておいて、はずさないよう気を付けている。

3 調査

私は書き始める前に調査することが多い。これは楽しい時間。脱線していくこともあり、あれもこれも記事に入れたくなるが、たいていは入れられなくてあきらめることになる。

調査するのはストーリー上で扱うものの仕組み、設定例や実行例、ものによっては事例など。だいたい8〜9割くらいは調査を先行させることが多いように思う。画面イメージが必要なときは、動作確認をするのといっしょにとってしっておく(後でとり直すのは面倒なことが多い)。

図が必要ならそのイメージもだいたいのところは考えておく。可能なら描いておくが、ここではASCIIアートで済ませることも多い。

4 書く

まず、ストーリーに合わせて構成(具体的には見出し)を考えて配置する。そして、それぞれの部分で書くことを箇条書きのような感じか、断片的な文章で書いていく。実行例などはここでいれてしまう。

次に、前後の関係を調整しながらつなぎを入れていき全体的な流れを作る。この辺で実行例の再確認とか、実行例を変えるとかすることがある。

そして、ひとまとまりの文章になるよう全体を書き上げていく。

(ただ、その時々でやり方は変わっているかもしれない。)

5 読み返す

書きながら読み返すというのもするけれど、全体は見えにくい。そのため予定の内容を書き上げたらひとまず印刷して、場所を変えて読み返すというのをする。自分で読んですらけっこう赤くなる。

ストーリーを見直し、分量をチェックし、必要に応じて――まあだいたい必要になるのだけど構成を変えたりいろいろする。

その後、修正を加え、印刷して、読んで、というのをあと一回か二回はやる(使える時間に応じて)。可能ならちょっと(一日とか)時間をおくようにしている。

6 編集さんに送る

時間に余裕があればいったん、そうでなければ最終稿として編集さんに送る。フォーマットはplain textにしている。内容によってはHTMLを付けることもあるけど、まあ、これはあってもなくても変わらないのかなとも思う。MS-Wordなどは使わない。

編集さん側でどれくらい余裕があるかどうかによって、つまり、どれくらい余裕を残して脱稿できたかによって、手直しできる程度が変わる。私は分量オーバーめになってしまうことがしばしばあって、削れるところを出してほしいといわれることがある。逆に足してほしいとかも。わかりにくいところの指摘をうけることももちろんある。

時間の具合いで校正前に手直しができることもあれば、校正がすぐに始まって大きな直しはできないこともある。この段階での編集さんとのやり取りは間があきがちになる(編集さん側でバリバリ作業をする時間帯なので)。

7 そして完了

校正が終わったら発売を待つばかり。世に出まわったあとではたまに読者からの指摘や質問が送られてくることがある。記事が間違っていた場合には訂正し、質問であれば回答する。

ちょうどよい機会があれば「読んでもらえてそうですかね?」などと、つい尋いてしまう。感触はなかなかつかめない。

A ツール

ここ数年はRDで書いて、テキスト変換している。この間、ReVIEWにチャレンジしようと思ったのだけど、ぼんやりしているうちに時間がなくなってしまって、結局またRDで書いた。図が多い場合にはHTML変換して印刷する。

分量は文字数でだいたいのところを見るようにはしている。ただ図の大きさとかレイアウトとかでけっこう変わるので、やっぱり目安くらいになってしまう。

WEB+DB PRESS Vol.47[rakuten]の特集で「バックアップの研究」という記事を書いた。とりあげたのはrdiff-backup、duplicity、Baculaで、これらのツールを使ってバックアップを始めましょうといような内容。すぐに始められるということを念頭に置いたので、バックアップ先はHDDとしている。

Baculaはあたってみればかなりのボリュームのドキュメントがあるのだけど、そのせいか日本語の情報が少ない。他のツールにしてもまとまった記事はなかなかない。オライリーのバックアップ本があるけれども日本語版はさすがにちょっと古くなってきている(今でも使えるん内容ではあるのだけども)。そんなことからバックアップは書いてみたいなと少し前から考えていたネタであった。

1. Unix系OS向け バックアップツール選び
   • いざというときのために、備えていますか?
   • どのようにバックアップを行うかの検討
   • 個人データのバックアップツール
   • マシン全体をバックアップ
   • いくつものパシンを集中バックアップ
   • まとめ (バックアップツール比較表)
2. 小規模なバックアップ〜rdiff-backup/duplicityで始める自分のためのバックアップ
   • 小規模なバッアップにトライ
   • rdiff-backup編
   • duplicity編
   • まとめ
3. 複数マシンのバックアップ〜Baculaでマシン群をまとめてバックアップ
   • はじめに
   • Baculaの構造
   • 相互接続のための設定
   • プールとボリューム
   • ジョブとカタログ
   • Baculaの起動〜バックアップ運用
   • レストア
   • クライアントの追加
   • まとめ

内容については「がんばりました」としかいえないけれど、一通りのことはできるようにしたつもりで、書いてよかったなと思った。

風邪をひいた影響を最も受けまくった仕事だったが、ようやくのこと、著者校正が完了した。ムックになるのかな。まあ、そのうち出ると思います。経験のない誌面なのでドキドキする。

追記(2007-03-29): WEB+DB PRESS総集編[Vol.1〜36]6年分のバックナンバーを大収録という本です。記事が先頭にあってびっくり。さらにドキドキしております。