KindleでTideSDKの入門本を出版してみた話
昨年末、TideSDKの最新版が出ていることを知って、試しに単純なMarkdownエディタを作ってみたら、思ったよりハマらず作れました。
で、いつもなら「Hello, TideSDK! Markdownエディタを作ってみた」みたいなエントリを書いて済ませるんだけど、なんかワンパターンで飽きたし、どうせ無料でやってもdisられるポイズンな世の中だし、どうしようかなぁと考えてたら、Kindleさんの存在を思い出した。
というわけで、TideSDKについて知り得た情報をまとめたものを、AmazonのKindle ダイレクト・パブリッシング (KDP) で出版してみました。
こちらです。
TideSDKでつくる!Macデスクトップアプリ(v1.3.1-beta対応)
価格は、ロイヤリティ70%オプションを選択した場合の最低価格(ドル)です。
※ Kindleストアはほんとに1クリックで買えてしまうのでご注意ください。
ストアの説明にもある通り、クオリティはこのブログ上の記事と同等のレベル、ということであまり期待しないでください。それでもなお興味があるという方はお手…じゃないな、ご端末にとってみていただければと思います。
超ニッチな内容のため売れて10冊ぐらいと見込んでいます。作業時間を考えると完全に赤字ですが、万が一利益が出た場合は、一部をTideSDKのプロジェクトに寄付する予定です。(大企業がたくさんスポンサーについてるので、端金かもしれませんが…。)
ちなみに以下がiPadでとったキャプチャですが、実際に端末で見れるのを確認すると、不覚にもちょっと感動してしまいました^^
以下、やってみた感想とか。
思いつくままに書いてたら長くなってしまいました、すみません。
KDPで出版しようと思ってる人には、もしかしたら参考になるかもしれません。
ePub作成はsigilが無難だと思う
KDPではHTMLやdoc(x)ファイルもサポートしていますが、一番無難そうだったePubを選択しました。
PagesがePubを吐けるという情報を得たので、はじめはその方法でやってみました。
(何も考えずにWordで書き始めちゃったので、それをPagesに読ませてePub出力)
確かにそれなりに見た目も整えてくれるし、Kindle Previewerでも特に問題なく閲覧できるようでした。しかし、ソースコードなどを見やすくするためには、出力されるXHTMLを修正する必要が出てきます。で、Pagesはどんなタグを吐くかというと、
1 2 3 4 5 6 7 |
<div class="body" style="white-space:pre-wrap"> <h1><span id="b1"></span><span class="c3">TideSDKとは</span></h1> <p class="s1"> </p> <p class="s1 c2">TideSDKは…</p> </div> |
のように、変なspanや空白のpがあったり、急にstyle属性使ってみたりとか、調整するにはしんどそうな感じです。
かといって、1から全部自分で書くのはもっとしんどい、ということでsigilの登場です。
ごく普通のWYSIWYGエディタの感覚で書いていけば、段落はp、見出しはh1〜6、リストはul/olと、素直なマークアップを出力してくれます。preとかblockquoteは自分で書きました。classやstyleは特につきません。見た目はCSSで整えましょう。
sigilで困りそうなところ
僕がつまったところを列挙しておきます。
- 表紙の設定
Imagesを右クリックして、「Add Existing Files…」から画像を追加。
追加した画像を右クリックして、「Add Semantics」→「Cover Image」をチェック。 - 論理目次の作成
端末の移動機能などで使われる目次。
メニューバーの「Tools」→「Table Of Contents」→「Generate Table Of Contents…」から作成できる。 - HTML目次の作成
ページとして表示される目次。
メニューバーの「Tools」→「Table Of Contents」→「Create HTML Table Of Contents」から作成できる。
CSSの読み込みなどの修正は最後にやるのが無難。(途中で目次が変更になった場合やり直しになるので) - 改ページ
<mbp:pagebreak/>というタグでできるらしいけど、sigilがそんなの知らないということで消してしまう。(xmlnsを書いてもダメだった。)
代わりに、CSSでpage-break-after: always;を指定すると、その要素の後ろで改ページしてくれる。
HTMLが別ファイルになれば、そこでも改ページされる。 - 落ちる
0.6.2はダメだったので、Downloadsから0.6.1を入れて使ったら、落ちることはなくなりました。(僕の環境はOS X Lionです。) - 選択範囲がおかしくなる
なります。我慢です。
プログラミングの本に関しては、フォーマットも凝る必要はないし、見出し・本文・コード・画像・引用と、必要なパターンも決まってるので、良い感じのオーサリングツールが出てくるんじゃないかと思います。それまでの辛抱です。
Kindle Previewerに注意
ePubをKindleで使われるmobi形式に変換、エミュレータで表示までしてくれるありがたいツール、それがKindle Previewerです。Amazon.co.jp:Kindle ダイレクト・パブリッシング:ヘルプ からダウンロードできます。(日本での名称はKindleプレビューツール)
※ 変換は同梱されているKindleGenが行います。というわけで、コマンドラインでやりたい人以外はKindleGen単体のダウンロードは不要です。
僕の使ったVersion: 2.751は、font-family: monospace;を解釈してくれなかったり、KDPのサイトで提出時に変換されるファイルとfont-sizeが違ったり…と結構くせがありました。
あと、TideSDK/TideSDK · GitHubとかで使われている「·」が文字化けしてaになりました。これはPreviewerの問題ではなく、実機でもなるのかもしれません。
そしてコンパイルにそれなりに時間がかかるので、修正・確認のサイクルがげんなりしてきます。
と、いろいろ書きましたが、いちいち実機に転送することを思えばはるかに楽ができるので、これなしではやってられません。今後のさらなる進化に期待します。
提出から出版までの時間
1/14の18時に提出して、翌日1/15の16時45分に出版されました。
Appleのレビュー速度と比較すると半端ない早さです。
ただ、出版されましたメール内のリンクが.comのサイトになってたり、KDPのサイトから書籍のページに飛ぶ方法がよくわからなかったり(未だにわからない。Kindleストアを検索する方がはやい。)、まだ荒削りですw
税金の手続きがめんどい
書類を出さないとアメリカで源泉徴収されるので二重課税になります。(昔のApp Storeと同様の手続きが必要。僕はまだやってません。Web上で完結するようにならないかなぁ。)
手続方法(不備があるらしいので、実際にやる前に他のサイトも参照することをお勧めします。)
Amazon.co.jp:Kindle ダイレクト・パブリッシング:ヘルプ
本を書くのは勉強にいいかも
ブログの記事なら、「〜についてはよくわかりませんでした^^」ですませるところですが、「あかん、もっと調べないと」という思いが襲ってきます。
例えば今回、App Storeへの提出は現状難しい、というデメリットを書いたんですが、難しいって書くからにはそれなりに裏を取らないと…ってなりました。
それでも間違ってたらごめんなさい。
広告モデルの本もあっていいんじゃないか
最後の最後、これは売るほどのものなのか…?という激しい葛藤がやってきました。
僕みたいなチキンな著者向けに、広告とか、あとから課金とか、読者が値段を決めれるとか、そういう電子書籍ならではの売り方ができてもいいんじゃないかと思いました。
Kindleが変えたのは出版であって執筆じゃないよ
確かに、コネもなにもない矮小な僕でもAmazonに本を並べられるようになりましたが、書く作業自体は何も楽になってません。むしろ手続きとか校正とか自分でやらなきゃいけないので、手間が増えているのかも知れません。
というわけで、「2〜3時間とかそんなんでできるわけじゃないよ」と、年始に軽い気持ちで始めた過去の自分に突っ込みを入れたいです。
“コード”より、“コンテンツ”を生み出す
いきなりまじめになりますが、今年というかこれからの僕の個人活動について。
皆さんは、以下の記事を読まれたでしょうか?
日米で半年ニートをするまで気付かなかった、「お金・理念・コード」より大切なこと【連載:上杉周作⑤】 – エンジニアtype
僕は以下の部分にとても衝撃を受けて、未だに頭のなかで鐘が鳴り響いている感じです。
エンジニアにとって、「コードを書くか、もしくは記事やスライドなどのコンテンツを作るか」は永遠の二択問題だ。
中略
1. 自分に影響を与えたエンジニアを何人か思い浮かべる。
2. どのようにして自分がその人から影響を受けたかを考える。
3. その人の素晴らしいコードに影響されたならコードを書く。反対に、その人の素晴らしいコンテンツに影響されたならコンテンツを作ればいい。
この二択は確かに僕の中にもあって、その時々の気分でコードを書いたり、入門記事を書いてみたりしてたんですが、この解決方法の発想はなかったなぁ、と。
これの基準で考えると、完全に僕はコンテンツを作るべき。
Encode.pmのコードは読んだことはないけど、404 Blog Not Foundは大好きだ。Matzさん、結城浩さん、amachangさん…影響を受けた人はたくさんいるけど、彼らの書くコードより文章から受けた影響の方が大きい。
というわけで、しばらくはものを作るためにコードを書く作業より、コンテンツを作るためにコードを書く作業を優先しようと思っています。
勢い余ってブログのタイトルもKindle JUNEとかにしようと思ったけど、そんなダジャレはもう誰かが言ってそうだし、Amazonアソシエイトから怒られそうな気がしたのでやめました。
そんなこんなで、いつもどおりグダグダですが、本年もよろしくお願いいたしますm(_ _)m
最近のコメント