Fuzoku実践入門ブログ

Amazon で好評発売中の『Fuzoku実践入門』に関するエピソードなどを紹介するブログです。

『Fuzoku実践入門』クリスマス無料キャンペーン開催【米国時間 12月23日〜24日まで】

Fuzoku実践入門

本日は、みなさまにクリスマスプレゼントのお知らせです。

『Fuzoku実践入門』をクリスマスプレゼント！

私、村雨秋乃は、これからクリスマスを迎えるにあたり、今年も多くの男性が悲しい思いをすると共に、情緒不安定になる事態を重く捉え、悲観的な状態を打破すべく、現在好評発売中の『Fuzoku実践入門』を無料でプレゼントすることに致しました。

クリスマスイメージ

このプレゼントにより、一人でも多くの人が幸せなクリスマスを過ごしてくれることを切に願っています。

というわけで、まだご購入されていない方は、ぜひこの機会にゲットして、実践してみて下さい。

プレゼント期間

期間は2014年12月23日から24日までに設定していますが、Amazonの仕様によりアメリカ時間となっておりますので、日本では本日の16時頃から25日の16時頃までとなりますのでご注意下さい。

また、もしよろしければ昨日発売されました『転ばぬ先の風俗法』も宜しくお願いします。

Fuzoku実践入門: 裏打ちされた知識で正々堂々とデビューする

Fuzoku実践入門: 裏打ちされた知識で正々堂々とデビューする

転ばぬ先の風俗法: 欲しかった安心感がここにある

転ばぬ先の風俗法: 欲しかった安心感がここにある

それではみなさま、メリークリスマス！

P.S.

日本時間17時30分頃、無料キャンペーンが開始されました。

無料キャンペーンのページ

KWLのお試しとして、新刊『転ばぬ先の風俗法』をKoboとKindleで同時リリースしました

KWL KDP 転ばぬ先の風俗法

先日、楽天Koboで個人出版サービスKoboライティングライフ（通称KWL）が開始されましたので、ものは試しと思い、本日、12月22日に楽天KoboとAmazon Kindleで『転ばぬ先の風俗法』という書籍をリリースしました。

『転ばぬ先の風俗法』の表紙

価格は100円、各販売ページは下記になります。

内容と価格設定について

内容は『Fuzoku実践入門』の中で、特に好評だった第2章「風俗に関する法律」の内容を元に、加筆・修正を行なった書籍になっています。

『Fuzoku実践入門』が少し高いと感られて購入を控えられた方は、ぜひこちらから試してみて下さい。

また、価格については、スピンオフ作品ということもあり、思いきってほぼ最低ラインの100円で設定してみました。

どうなるのか楽しみです。

楽天とAmazonの審査について

ちなみに、昨夜11時頃にKWL、KDPの順番に登録して、朝起きると両方審査は通ったっぽいのですが、KWLは既に商品が購入可能であるのに対して、KWLは残念ながら16時現在、まだ商品ページがないようです。

なお、KDP出版の流れについては、審査タイミングなども含めて過去にKDPによるKindle電子書籍出版の方法（2014年11月版）という記事を書きましたので、興味のある方はぜひ参考にしてみて下さい。

表紙について

今回、表紙についてはボリュームが前作に比べて少ないことから、新書スタイルで一からオリジナルデザインしてみました。

ポイントは、本棚に並んだときのオシャレ感です。

タイトルについて

タイトルについて、初めは『安心して風俗を嗜むための法律ガイドブック（仮）』だったのですが、長いため、色々と熟考した結果、『転ばぬ先の〜』というネーミングが気に入り、『転ばぬ先の風俗関連法』とつけてみたのですが、ゴロが悪いため、最終的に『風俗法』という新語を採用することにしました。

まとめ

この1ヶ月、電子書籍執筆環境を整えたことで、執筆から出版までの流れがとてもスムーズに行なえることを実感しました。

お陰で、内容と直接関係のない作業から開放され、企画と執筆に集中することができました。

KWLについては、正直どうなっていくのか分かりませんが、価格の安い商品（主に250円未満）については、KWLとKDPの両方でリリースする形態をとっていきたいと個人的には思っています。

それでは、最後になりますが、みなさま拙著をどうぞ宜しくお願いします。

転ばぬ先の風俗法: 欲しかった安心感がここにある

転ばぬ先の風俗法: 欲しかった安心感がここにある

Fuzoku実践入門: 裏打ちされた知識で正々堂々とデビューする

Fuzoku実践入門: 裏打ちされた知識で正々堂々とデビューする

CircleCIで簡単にepubcheckを導入する

環境 CI

これまで、電子書籍執筆環境を改善すべく、

  1. CircleCIの導入
  2. 継続的デプロイメント

とステップを踏んできましたが、

というリクエストを受けたので、色々試してみた結果、自分でepubcheckをビルドしなくても、簡単に導入できることが判明したので、サクっと導入してみました。

epubcheckが使えるRubyGems

EPUBのバリデーターは、IDPF/epubcheckというツールが一般的で、ソースコードをmvn installするとビルドできます。

初めは、CircleCI上でビルドしようかと考えたのですが、バージョンさえ気にしなければ、RubyGemsをインストールするだけで、epubcheckコマンドも同梱しているGemが2つもあることが判明しました。

どちらもepubcheck-3.0.1を同梱していて、Rubyから使えるのですが、少しだけepub_validatorの方が便利そうだったので、こちらを採用することにしました。

CircleCIへの組み込み

まずは、Gemfileにepub_validatorを追加して、bundle updateします。

gem "epub_validator"

Rakefileに、epubcheckを実行するタスクを追加します。

require 'bundler/setup'
require 'epub_validator'

epub_file = bookname+'.epub'

def source_exist(source, error_message= nil)
  return true if File.exist?(source)

  puts error_message if error_message
  fail "#{source} does not exist."
  false
end

desc 'validation .epub'
task :epub_validation do
  next unless source_exist(epub_file, 'Cant execute :epub_validation')
  epub = EpubValidator.check(epub_file)
  puts "checking #{epub_file}..."

  if epub.valid?
    puts "OK, #{epub_file} is valid!"
  else
    epub.messages.each do |m|
      puts m
    end
    fail "#{epub_file} is invalid :-("
  end
end

これで、rake epub_validationを実行すると、正しく成功すると、

$ rake epub_validation
checking learning-fuzoku-example.epub...
OK, learning-fuzoku-example.epub is valid!

このようなメッセージになりますが、もし、EPUBファイルが存在しないと、

$ rake epub_validation
Cant execute :epub_validation
rake aborted!
learning-fuzoku-sample.epub does not exist.
/Users/akinomurasame/projects/learning-fuzoku-sample/Rakefile:16:in `source_exist'
/Users/akinomurasame/projects/learning-fuzoku-sample/Rakefile:43:in `block in <top (required)>'
Tasks: TOP => epub_validation
(See full trace by running task with --trace)

という感じのエラーになり、epubcheckがInvalidだと、

$ rake epub_validation
checking learning-fuzoku-sample.epub...
WARNING: learning-fuzoku-sample.epub/OEBPS/learning-fuzoku-sample.opf(6,44): date value '2014-mm-dd' does not follow recommended syntax as per http://www.w3.org/TR/NOTE-datetime: [For input string: "mm"] is not an integer
rake aborted!
learning-fuzoku-sample.epub is invalid :-(
  /Users/akinomurasame/projects/learning-fuzoku-sample/Rakefile:53:in `block in <top (required)>'
  Tasks: TOP => epub_validation
  (See full trace by running task with --trace)

こんな感じでエラーとなりrake abortedになるため、

test:
  override:
    - rake epub epub_validation

上記のようにepub_validationをcircle.ymlに追加しておき、CircleCIで実行すると、epubcheckが通らないとテストが失敗するようになります。

テストがこけるブランチを作成してみたので、どう失敗するか気になる方はこちらを参照下さい。

成功した場合は次のようになります。

epubcheck in CircleCI

まとめ

今回の作業記録は、PRとして処理しましたので、詳しくはこちらを参照して下さい。

いよいよ、残るはCIでPDFビルドしか残らなくなってきましたが、ぼちぼちとやっていきたいと思います。

電子書籍執筆を支えるハードウェア環境

環境

これまで、電子書籍執筆のソフトウェアに関する記事を幾つか書いてきましたが、今回はハードについて触れていきたいと思います。

執筆の要求するハードスペック

電子書籍の執筆に関して、理想的なハードはどのようなものなのかを考えると、気分転換に外で作業ができて、多くの文字をタイプする作業を基軸とする執筆作業は、ソフトウェア開発が要求するスペックと似てくることになります。

つまり、

  • ノートデバイス
  • タイプしやすいキーボード
  • 見やすいディスプレイ

となるわけですが、これらを兼ね備えているデバイスとして、現状最適なのは、やはりMacBook Pro Retinaディスプレイモデルになります。

キーボードは、RealforceやHHKに比べると劣ってしまいますが、どうしても必要だという人は接続すればいいですし、何よりディスプレイが最上級であること間違いなく、MacBook Proを選択する最大のメリットとなっています。

もちろん、ソフトウェアの関係上、Windows OSを選択せざろう得ない人もいるかもしれませんが、MacBookにWindowsを入れることも可能ですので、現状としては、やはりMacBookが理想的だと言えます。

MacBook Pro Retina 15インチ2台による最強執筆環境

現在の私の執筆環境は、15インチのRetinaディスプレイモデル2台持ちという形になっています。

Retina2台

この構成であれば、ファミレスなど充電のできない外での作業であっても、マシンを切り替えることで約9時間は継続して作業を行なうことができるため、存分に戦うことが可能です。

最近では、iCloudキーチェーン、Google Chrome、Dropboxなどの様々な同期ツールが充実しているため、ワンアカウント、マルチデバイスで、同じ環境で継続した作業が実現できることも大きなサポートとなっています。

まとめ

現在の私の執筆環境をハード面から紹介してみましたが、いかがでしたでしょうか？ 執筆環境のハードの情報は意外に公開されていないため、私も他の人がどうのようなハードを使っているのか気になります。

ちなみに、マシン以外ではイヤホンなども案外大事なデバイスで、私はゼンハイザーのCXシリーズを愛用しています。

【国内正規品】ゼンハイザー カナル型イヤホン ブラック CX400-II Black

【国内正規品】ゼンハイザー カナル型イヤホン ブラック CX400-II Black

このような環境で執筆されたFuzoku実践入門をぜひ宜しくお願いします。

Fuzoku実践入門: 裏打ちされた知識で正々堂々とデビューする

Fuzoku実践入門: 裏打ちされた知識で正々堂々とデビューする

ChatOps Next, 2015年に流行るDevOpsはCallOpsだ！

コラム

注：この記事は豊富なネタ成分が含まれていますのでご注意下さい。

この数年、流行り続けているDevOpsであるが、まだまだ流行の熱は冷める気配がなく、今後もTechトレンドの牽引していくテーマであると推測されるが、本稿では、そんなDevOpsの2015年のトレンドを大胆にも予想したい。

2014年はChatOps

まず、2014年のトレンドは、ChatOpsであったことは間違いないだろう。

チームの効率を最大化！nanapi流ChatOpsの取り組みという記事で、広く普及したChatOpsであるが、ChatOpsの牽引の引き金となったボットツールについても、Githubのhubot以外に、rubotyのような開発者フレンドリーな新しいツールが登場してきており、今後ますます敷居が低くなっていくだろう。

ネットへの依存性を克服

ChatOpsは、高いイタラクティブ性を実現していたり、ログが記録されるなど、実に様々なメリットがある。

しかし、あえて現状で満足せず、更なる高みを目指すのだとすれば、実はまだ課題が残されている。それはネットへの依存性だ。この問題を解決することで、DevOpsはより完成度の高い仕組みを実現できるだろう。

ネットがどうしても使えない場合に、人が頼る通信手段は何かと考えてみると、答はひとつだけだ。そう、電話である。最後のピースはここに隠されていたのだ。

CallOpsが変える未来

電話によるオペレーションは、誰もが知っている宅配の再配達で利用される自動音声サービスを筆頭に昔からとてもよく使われている。

もうお分かりであろうと思うが、これを利用したDevOpsがChatOps Next であり、その名もCallOpsなのである。

CallOpsの概要

CallOpsの基盤となる技術は、既に他のサービスによって準備が整っている。TwilioなどのVoice API, Github, Heroku, AWS and more だ。

利用者は電話をかけて、自動音声に従いボタンを押すだけでいい。操作速度こそChatOpsに劣るかもしれないが、インタラクティブ性やイージーさは、ChatOpsよりも更に向上することになる。

自動音声の内容は、こんな感じになるだろう。

  • あなたのPINを入力して下さい。入力が完了したら#を押してください
    • PINを入力させることで認証を行なう
  • 希望する操作を入力してください
      1. デプロイ、2. something、3. anything
    • 1を押した場合
  • 本当にデプロイしますか? よろしければ1、やめる場合は3を押してください
    • 1を押した場合
  • デプロイを実行しています。完了までしばらくお待ち下さい
    • ここで切ってもいい
  • デプロイが無事完了しました。他にご利用があれば1、終了する場合は3を押してください
    • 3を押して終了する
  • ご利用ありあとうございました（終話）。

当然ながら、操作の記録は裏でログを記録する。チャットツールに流すと尚良いだろう。

誰か作ってくれ

というわけで、2015年のDevOpsの本命となるだろう、CallOpsを紹介してみたが、いかがだっただろうか。

実は、書き始めはノリノリだったのだが、最後の方は少し飽きてきてしまった。というわけで、Twilioを使ってネタ用のデモサービスを作ってみようと思ったのだが、残念ながら断念する。

しかし、デプロイは冗談としても、ネットが使えないときに急にサーバー情報が欲しくなった場合、電話で確認できる手段を用意しておくことは、ライフラインとして活用できると思うので、使いどころを間違えなければ、ちょっとした社内イノベーションを実現できるかもしれないだろう。

意欲的な方はぜひ試してみて欲しい。それではまた。

CircleCIのビルド結果をOSXの通知センターで受け取る

環境 CI

CircleCIからビルド結果通知を受け取る方法として、標準ではメールが用意されていますが、ふと、OSXの通知センターに通知する方法はないかなと思って調べてみると、CCMenuというツールを使って受け取る方法がありました。

CCMenu

導入方法は、Polling project status using CCMenu, CCTray, etc. - CircleCIに書かれてあるように、Project settings > API TokensからAPIトークンを作成して（私はCCMenuという名前にしました）、https://circleci.com/cc.xml?circle-token=APIトークンというURLを準備して、CCMenuの設定パネルにURL追加してプロジェクトを選択するだけです。

CircleCIのAPI Token作成画面

CCMenuの設定パネル

これで、masterリポジトリのビルド状況をOSXのメニューバーで確認しつつ、ビルド結果が通知センターに表示されるようになりました。

私は利用しておりませんが、他のCIサービスについても同様のはずです。

まとめ

ちなみに、CircleCIの通知は、これ以外にもSlackへの通知できたり、チャットサービスと簡単に連携する方法も用意されており、私もSlackと連携して使っております。

最近の開発世界では、欲しいと思った機能がたいてい存在していて、開発者の飽くなき要求と、実行力には本当に驚かされるばかりです。

こういった姿勢は、執筆業を営む私もぜひ見習っていこうと思うと同時に、コードを書くことがあまり得意ではない私は、この記事のようなドキュメント面で開発の世界に少しでも還元できればと考えています。

CircleCIによる電子書籍の継続的デプロイメント

環境 CI

先日、CircleCIを導入して、CIによるEPUBビルド環境が整ったわけですが、人間とは欲望が尽きないもので、こうなってくると、今度は継続的デプロイメント環境が欲しくなってきました。

私が考える電子書籍の継続的デプロイメントがどのようなものか整理してみると、EPUBビルド（テスト）が完了した後に、Kindleへファイルを自動送信するのが自然だろうという回答に至りました。

そこで、CircleCIに設定を追加して、継続的デプロイメント環境を整えてみるとことにしました。

kindlemail を改造して環境変数に対応させる

KindleへのMOBIファイルの転送は、以前記事に書いたとおり、kindlemailを利用しているのですが、今回、CircleCIで動かすにあたり、OAuthトークンなどを設定ファイルからではなく、環境変数から読み込むようにした方が良いと思いましたので、改良をほどこしたkindlemailを作ることにしました。

とりあえず、簡単に実現したかったので、lib/Configuration.rbファイルを次のように変更することにしました。

@@ -61,23 +61,33 @@ class Configuration
   def get_email_credentials
-    raise ArgumentError, "Cannot find email credentials file #{EMAIL_CONF_FILE}." if !File.exists?(EMAIL_CONF_FILE)
-    begin
-      load_yaml(EMAIL_CONF_FILE)
-    rescue
-      raise StandardError, "Error parsing #{EMAIL_CONF_FILE}"
+    if (ENV['SMTP_OAUTH_TOKEN']  &&
+      ENV['SMTP_OAUTH_TOKEN_SECRET'] &&
+      ENV['KINDLE_USER_EMAIL'])
+
+      return {
+        :smtp_oauth_token => ENV['SMTP_OAUTH_TOKEN'],
+        :smtp_oauth_token_secret => ENV['SMTP_OAUTH_TOKEN_SECRET'],
+        :email => ENV['KINDLE_USER_EMAIL']}
+    else
+      raise ArgumentError, "Cannot find email credentials file #{EMAIL_CONF_FILE}." if !File.exists?(EMAIL_CONF_FILE)
+      begin
+        load_yaml(EMAIL_CONF_FILE)
+      rescue
+        raise StandardError, "Error parsing #{EMAIL_CONF_FILE}"
+      end
   end
 end

「SMTP_OAUTH_TOKEN」と「SMTP_OAUTH_TOKEN_SECRET」と「 KINDLE_USER_EMAIL」という3つの環境変数が全て存在すれば、設定ファイルではなく、環境変数を優先して利用するという形です。

フォークしたリポジトリに上記の変更を加えて、新規作成したブランチ（use-env-first）が下記になります。

GithubリポジトリからGemをインストールする

次は、新たに作成したリポジトリから、kindlemailをインストールするようにGemfileを書き換えます。

@@ -2,5 +2,5 @@ source "https://rubygems.org"

 gem "review"
 gem "md2review"
-gem "kindlemail"
+gem 'kindlemail', github: 'akinomurasame/kindlemail', branch: 'use-env-first'
 gem "dropbox-sdk"

bundle updateを実行すると、指定した自分のリポジトリのkindlemailに更新されました。

CircleCI の設定を変更する

CircleCI で行なうことは、kindlegenを使ってEPUBからMOBIを作成して、kindlemailによってMOBIをKindleへ送ることですので、作業内容は主に次のようになります。

  1. kindlemailの環境変数を追加する
  2. kindlegenをインストールする
  3. デプロイ設定を追加する

順番に作業を追っていきましょう。

kindlemailの環境変数を追加する

これはCicleCIの設定パネルから、先ほどの3つの環境変数を追加するだけですので、とても簡単です。

環境変数の追加

kindlegen をインストールする

kindleへMOBIファイルを送るためには、CircleCIでkindlegenコマンドが使える必要があるため、これをインストールする設定をcircle.ymlに追加します。

@@ -1,3 +1,9 @@
+dependencies:
+  pre:
+    - mkdir tmp && cd ./tmp
+    - wget http://kindlegen.s3.amazonaws.com/kindlegen_linux_2.6_i386_v2_9.tar.gz
+    - tar zxvf kindlegen_linux_2.6_i386_v2_9.tar.gz
+    - cp kindlegen /usr/local/bin
 test:
   override:
     - rake md2review epub send_to_dropbox

kindlegenはMakefileがないので、べたにインストールしました。そして、ブランチをpushして、CircleCIのビルドを実行してみると、無事にインストールされることを確認しました。

kindlegenインストール確認

さて、毎回kindlegenをダウンロードするのは少し無駄な処理なため、キャッシュを使うように書き換えることにしました。

少し設定が複雑になるため、ついでにインストール処理をスクリプトファイルにしました。

dependencies:
  cache_directories:
    - tmp
  pre:
    - bash ./install-kindlegen-2.9.sh
test:
  override:
    - rake md2review epub send_to_dropbox
#!/bin/sh -xe

if [ ! -e tmp/kindlegen ]; then
mkdir tmp && cd ./tmp
wget http://kindlegen.s3.amazonaws.com/kindlegen_linux_2.6_i386_v2_9.tar.gz
tar zxvf kindlegen_linux_2.6_i386_v2_9.tar.gz
sudo cp kindlegen /usr/local/bin;
fi

pushして、ビルドが完了した後に、リビルドしてキャッシュが利用されていることを確認しました。

キャッシュ利用の確認

デプロイ設定を追加する

circle.ymlにデプロイ設定を追加します。masterブランチが変更されたタイミングで、デプロイすることにしたので、次のような設定になりました。

@@ -7,3 +7,8 @@ dependencies:
 test:
   override:
     - rake md2review epub send_to_dropbox
+deployment:
+  staging:
+    branch: master
+    commands:
+      - rake mobi send_to_kindle

これで、masterブランチにマージされると、kindlemailが実行されるようになりました。最後に、送信先のKindleデバイスを柔軟に追加できるようにします。

デバイスリストからKindleへ送る

kindle_addresses.ymlというデバイスリストのファイルを作成して、こちらに追加されているアドレス全てにMOBIを送るようにRakefileを修正します。

- kindle1@example.com
- kindle2@example.com

desc 'send to kindle'
task :send_to_kindle do
  if File.exist?("kindle_addresses.yml")
    YAML.load_file('kindle_addresses.yml').each do |kindle_address|
      sh "bundle exec kindlemail -f #{bookname}.mobi -k #{kindle_address}"
    end
  else
    sh "bundle exec kindlemail -f #{bookname}.mobi"
  end
end

この変更により、kindle_addresses.ymlに書かれている、全てのsend-to-kindleアドレスに対して、MOBIファイルが自動的に送られるようになりました。

masterへマージ、デプロイ実行

様々な変更をしましたが、masterブランチにマージすると、無事にCircleCIによる自動デプロイが実行され、継続的デプロイメント環境が完成しました。

bundle exec kindlemail -f example.mobi -k kindle1@example.com
kindlemail 0.2.8. Written by djhworld. https://github.com/djhworld/kindlemail

Preparing example.mobi to be sent to kindle1@example.com
Adding attachment: /home/ubuntu/.kindlemail/.staging/c78f78d87f0de292b516a7af051f0d40_209895.mobi (290.9131 kb)
Sending message....sent!
example.mobi was successfully sent to kindle1@example.com
bundle exec kindlemail -f example.mobi -k kindle2@example.com
kindlemail 0.2.8. Written by djhworld. https://github.com/djhworld/kindlemail

Preparing example.mobi to be sent to kindle2@example.com
Adding attachment: /home/ubuntu/.kindlemail/.staging/c78f78d87f0de292b516a7af051f0d40_970393.mobi (290.9131 kb)
Sending message....sent!
example.mobi was successfully sent to kindle2@example.com

デプロイ確認

まとめ

まだまだ電子書籍の執筆環境は改善できる点があるかと思いますが、ひとまずCircleCIによる継続的デプロイメントを試すことができたのは、私にとって大きな進歩でした。

あと簡単に思いつく改善としては、PDFの自動作成もCircleCI上で行なえれば便利かなと考えているのですが、CircleCI上でTeX環境を整えるのは、なかなか骨な気がするため、やるかどうか悩んでいます。

やるとすれば、TeX環境構築済みdockerコンテナを用意して利用するという方法が良いのかなと思うのですが、dockerを利用したことのない一介のライターの私にとっては、なかなか大変そうな作業です。

しかしながら、こういった改善を続けつつ環境を整えて、その情報を共有していくことで、他の電子書籍執筆者の助けになれば幸いですので、これからも少しづつ改善を続けていきたいと思う次第です。