Fuzoku実践入門ブログ

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

【特報】英語版『Fuzoku実践入門』、本日(4月5日)限り無料です

先日、発売を開始した英語版『Fuzoku実践入門』こと『Fuzoku: The Complete Guide to Sex Industry in Japan』ですが、出版を記念して無料セールを開始しました。

英語版 Fuzoku実践入門

日本語版をお持ちの方も、そうでない方も、ぜひ英語の勉強がてらダウンロードしてみて下さい。

そして、外国人の知り合いがいる人は、ぜひオススメして下さい。

.com アカウントをお持ちの方へ

ちなみにもし、amazon.comのアカウントをお持ちの方は、

http://www.amazon.com/dp/B00VF5J0BY こちらの amazon.comの販売ページからダウンロードしていただけると、とても嬉しいです。

どうぞ宜しくお願いします。

英語版『Fuzoku実践入門』を出版しました。

かねてからの予定通り、無事に英語版『Fuzoku実践入門』となるが無事に発売されましたので、お知らせ致します(ただし、英語版の登録にあたり、サブタイトルが日本語が優先されてしまったため、現在修正中です)。

Fuzoku: The Complete Guide to Sex Industry in Japan (History, Law, Policy and Services)

次のページで販売中です。なお価格は、翻訳書のため、日本語原版よりも高くなります(ただし、レートを下げているので、円で購入した方がお得です)。

英語版 Fuzoku実践入門

Book Description

Do you know Fuzoku? Fuzoku means Japanese sexual entertainment witch is no.1 sexual service in the world.

It's difficult to access reliable and useful information about Japanese sexual entertainment especially to foreigners even if they are interested about it.

However, you will be Fuzoku master after reading the entire book.

This book explains awesome Japanese sexual entertainment and law specifically based on author's wealth of experience and latest information.

Provably this book is only book to explain Japanese sexual entertainment by technical writing.

なぜ英語版を出版したのか?

Amazon KDPを利用した出版を行うにあたり、私の中で、最もやりたいことは、実は英語の書籍の出版でした。

KDPによる電子出版は、日本にいながら英語圏に向けて書籍を出版できます。これこそ、まさにインターネットを使った電子出版の最大の魅力だと思います。

日本語の紙の本であれば、いくつか出版する方法が思い浮びますし、誰でも出版のチャンスはあると思います。しかし、英語だとどうでしょう。絶望的に方法が思い浮びません。

しかし、KDPであれば、英語の本を用意さえすれば、誰でも簡単に英語の本を出版できるのです。アメージング。

英語版 Fuzoku実践入門

上記の画像は、EPUBで出力したものをiBooksでプレビューしたものです。今回もRe:VIEWを利用して電子書籍化しましたが、国際化に対応しているため、特に悩まず原稿作業に集中できました。

どうやって翻訳したのか?

今回の英語版執筆にあたり、翻訳を行なったのは私ではありません。クレジットにもある通り、海外在住のMakoto Izumi氏に翻訳を依頼しました。

電子書籍では、インターネットをフル活用できるため、海外の方に翻訳を依頼して作業を行うことが紙に比べて容易に行うことができます。

なお、翻訳の原稿は MS Wordで共有させていただいたため、こちらの記事で紹介した方法で私の方でGit管理を行いました。

最後の校正では、GitHubのプライベートリポジトリを利用して、行番号のURLと修正文をテキストデータでいただき、それを元に私がPRを作成して、修正漏れがないか確認してもらいながら、作業を進めましたが、とても分かりやすかったです。

表紙とタイトルについて

英語版の出版にあたり、表紙とタイトルを大きく変更しました。これは、日本語原版と比べて、より海外の方に理解を得られやすいように考慮したためです。

表紙のデザインは、今回も私自身で行いましたが、教科書のようなクリーンな印象を与えつつ、日本文化、とりわけ夜をフィーチャーした結果、歌舞伎町のネオン写真を利用することにしました。

フォントについては、Bookman Old Style を使用、そしてカラースキームは、白を貴重としつつ、インパクトを与えたいと思った結果、最終的にトリコロール落ち着きました。

タイトルは、とても悩んだのですが、知らない文化を伝えるという目的から、『Fuzoku』という直球勝負のネーミングになりました。

もちろん、海外にはない言葉であるため、サブタイトル『The Complete Guide to Sex Industry in Japan (History, Law, Policy and Services)』で、内容を詳しく説明する形にしました。

まとめ

今後は、海外で認知してもらえるようにマーケティングに注力したいと思っています。しかし、特に良い方法を知っているわけではないため、もし何か良い知見をお持ちの方がいらっしゃいましたら、ぜひご教授下さい。

また、日本の方であっても、もしよろしければ、英語の勉強のためにご活用下さい。

それでは、今後ともどうぞ宜しくお願いします。

gitコマンドをタイプするのが流石に面倒になってきたので、gitコマンドを省略したエイリアスを使うことにしました

ログは取っていないのですが、多分、ここ数年で一番タイプしたコマンドは、lsを除くとgitコマンドだと感じてきました。

git自体はタイプしやすい部類なので、タイプすることに関してはそこまで苦でもないのですが、それでも流石に面倒になってきたので、久しぶりにzshエイリアスを登録することにしました。

いっそのこと、gitコマンドを省略すればいいんじゃないか?

zshエイリアスを登録する場合、よくあるパターンが一文字に省略するスタイルです。例えば、gitであれば、gみたいに省略し、git addg addといった風に利用する形です。

ただ、いちいちgをタイプするのであれば、gitとタイプするのと、そこまで時間は変わらないし、脳内コンテキストも切り替えにくいような気がしました。

そこで、考えてみたのが、いっそのことgit自体を省略してみる試みです。zshのautocdと似たアプローチですね。

実際に登録してみたエイリアスは次の通りです。

alias add='git add'
alias ci='git commit'
alias co='git checkout'
alias s='git status'
alias d='git diff'

checkoutはconfigでco = checkoutを設定して使っていたので、coをにしました。このエイリアスを利用すると、

$ git add .
$ git commit -m "commit"
$ git co <branch>
$ git status
$ git diff

が、それぞれ、

$ add .
$ ci -m "commit"
$ co <branch>
$ s
$ d

で実行されるようになります。

git statusgit diffは、状態に変化を及ぼさないので、いっそのこと一文字にしてみよう思い、とりあえず登録してみた次第です。

とりあえず、しばらく、これで生きてみたいと思います。

まとめ

まだ登録して日が経っていないため、この設定によってライフチェインジングするかどうかは分かりませんが、面倒に感じたことは、とりあえず動いてみる方針なので、今後もこういった細かいチューニングを続けていきたいと思います。

MS Wordで書かれた原稿をテキストファイルでGit管理する

MS Wordで書かれた原稿を電子書籍化する作業を行ったのですが、個人的には使い慣れたRe:VIEWで管理したいものです。

そこで、MS Wordをテキストファイル化してRe:VIEWファイルに書き換えることにしました。

docx2txtを使ってMS Wordをプレーンテキストに変換する

ワードファイルのテキストをコピペしてテキストファイルに置き換えるのは流石に面倒ですし、ヒューマンエラーも発生しそうです。

そこで、何か良い方法はないかと思って、おもむろにGoogleで『docx2txt』と検索してみると、まったく同じ名前のソフトウェアを発見することができました。

ページはややレトロですが、ツール自体はメンテナンスもされているようで、これを導入することにしました。

リポジトリ作成

まずはリポジトリの作成です。とりあえず、次のようなファイル配置をしました。

.
├── Rakefile
├── script
│   ├── docx2txt.pl
│   └── docx2txt.sh
└── src
    ├── Chapter1.docx
    └── Chapter2.docx

そして、Rakefileには次のようなスクリプトを書きました。

require 'rake'

desc 'convert ./src/*.docx to ./src/*.txt'
task :docx2txt do
  Dir.glob('./src/*.docx') do |docx|
    txt = File.basename(docx).sub(/\.docx$/, '.txt')
    if File.exist?("./src/#{txt}")
      puts "#{txt} exist."
      sh "rm ./src/#{txt}"
    end
    sh "./script/docx2txt.sh #{docx}"
  end
end

テキストファイルへの変換

ファイルの配置が終ったら、rake docx2txtコマンドを実行。

$ rake docx2txt
./script/docx2txt.sh ./src/Chapter1.docx

Text extracted from <./src/Chapter1.docx> is available in <./src/Chapter1.txt>.

./script/docx2txt.sh ./src/Chapter2.docx

Text extracted from <./src/Chapter2.docx> is available in <./src/Chapter2.txt>.

すると、

.
├── Rakefile
├── script
│   ├── docx2txt.pl
│   └── docx2txt.sh
└── src
    ├── Chapter1.docx
    ├── Chapter1.txt
    ├── Chapter2.docx
    └── Chapter2.txt

こんな感じで無事にテキストファイルが作成されました。

とりあえず、これをコミットしておけば、今後もしワードファイルが更新されても、差分を確認することが可能になりました。

なお、docx2txt自体はファイルを上書きしないように作られていますが、Gitで管理していれば、上書き上等なので、Rakeの中でファイルの存在を確認し、削除するようにしました。

まとめ

MS Wordをコピーして貼り付けると、記号文字がちょっとアレな感じだったのですが、docx2txtを使って変換すると、いい感じに変換してくれたので、編集作業もとても楽に行うことができました。

作業が終ってから、この記事を書くにあたって調べてみると、docx2txtを使ってgit diffで直接差分を表示するという方法を紹介している記事を見つけたりして、人によってはこれだけで十分嬉しいかと思います。

やり方は他にも色々とあるかと思いますが、今回私が実際に利用した方法を紹介してみました。

追記

d:id:zariganitosh さんにコメントで、 テキストでないファイルのdiff(差分)をとる方法 - ザリガニが見ていた...。という記事を紹介していただきました。(コメントで すいません、リンク先の方法と同じでした。未承認としておいてください。 といただいたのですが、折角なのでこちらでご紹介させていただきます。)

上でリンクした記事と根本的な手法は同じですが、Word以外のバイナリファイルをGitで差分を確認する方法が紹介されています。

Shadow DOMとVirtual DOM

Shadow DOMとVirtual DOM、影と仮想、何となくニュアンスが似ているため分かりにくい、そういう声を聞きました。

そこで、一介の風俗解説本の著者が分かりやすく両者を説明する方法を考えてみました。

現実にあるのが影(Shadow)、現実にないのが仮想(Virtual)

色々と自分の中で整理した結果、現実に存在するかしないかで区別すると、理解しやすいと考えました。

要するに、言葉にしてみると次のような考え方です。

  • 影は現実に存在しているので、Shadow DOMも実際のDOMツリーには確かに存在している。
  • 仮想は現実に存在していないため、実際のDOMツリーにも存在しない。

それでは、上記を踏まえた上で、実際の例を見てみましょう。

存在しているけど、触れられないのが影

Shadow DOMの役割は、Shadow DOM 101 - HTML5 Rocksの冒頭にも書かれている通り、DOMツリーのカプセル化です。

<html>
<!-- グローバルなCSS -->
<style>
h1 { color: red;}
</style>

<h1>Outside Shadow DOM</h1>

<template id="shadow">
  <!-- Shadow DOMのみ適用されるCSS -->
  <style>
  h1 { background-color: blue; }
  </style>
  <h1>Inside Shadow DOM</h1>
</template>

<!-- Shadow Hostの要素 -->
<shadow-host></shadow-host>

<script>
var host = document.querySelector('shadow-host');
var root = host.createShadowRoot();
var template = document.querySelector('#shadow');
var clone = document.importNode(template.content, true);
root.appendChild(clone);
</script>
</html>

たとえば、 上のようなHTMLをブラウザで表示すると、次のような表示になります。

Shadow DOMのサンプル

インスペクタに#shadow-rootが表示されている通り、Shadow DOMで作られたDOMツリーは確かに存在しているのですが、人は影に触れることができません。

そのため、Shadow DOMの外部で定義されているCSSは、Shadow DOM内部に触れることができないのです。

実際に存在しないのが仮想

次にReactを使ったVirtual DOMを見てみましょう。

<html>
  <head>
    <title>Hello React</title>
    <script src="http://fb.me/react-0.12.2.js"></script>
    <script src="http://fb.me/JSXTransformer-0.12.2.js"></script>
  </head>
  <body>
    <div id="content"></div>
    <script type="text/jsx">
var VirtualDOM = React.createClass({
  render: function() {
    return (
      <h1>Virtual DOM</h1>
    );
  }
});
React.render(
  <VirtualDOM />,
  document.querySelector('#content')
);
    </script>
  </body>
</html>

上の例では、<VirtualDOM />という仮想DOMを作成しています。しかし、実際にそんなDOM要素はHTMLに存在していません。

実際のDOM

しかし、React Developer Toolsを利用すると、<VirtualDOM />を確認することができます。

仮想DOM

仮想DOMはあくまで仮想世界の存在であり、実際のDOMツリーには存在しませんが、Reactによって指定されたDOM要素に埋め込まれることで、その中身のみを現実世界のDOMに写し出すのです。

要するに、仮想DOMを作り出すJSライブラリ専用のDOMと言えます。

まとめ

なんとなく、最近自分でも疑問に思っていたShadowとVirtual DOMについて整理してみたのですが、これで理解できるでしょうか?

というわけで、みなさまDOMについては分からないけれど、風俗についてはよく分かるFuzoku実践入門を宜しくお願いします。

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

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

私の中のJavaScriptライブラリの歴史

最近、JS界隈ではReactが大いに盛り上がっていますが、私のような一介の風俗解説本の著者からみると、何の話だろうといった感じです。

そこで、一度自分の中のJavaScriptライブラリの流れを整理してみようかなと思ってメモしたので公開してみます。

Ajax登場

2004年くらいまでは、

  • JSは危険だからブラウザでオフにしよう
  • JSなしでも見られるページ作りをしよう

という考え方が、Webに詳しい人達のわりと一般的なコンセンサスだったが、Ajax(主にGmailGoogle Maps)の登場により世界は一変。Webの世界は、はっきり言ってJSなしでは生きられなくなった。

ちなみに、それまでのJSといえば、右クリックを禁止したり、ポップアップウィンドウを開いたりする、ただただウザい存在でしかなかったので、上記の考え方は別に尖っているわけではなかった。

素のJS書くのつらい → 最初の有名ライブラリprototype.jsの登場

JSなしでは生きられなくなり、世のWeb制作者はJSを書くことと真剣に向き合いはじめた。しかし、そこには大きな問題があった。

いざJSを書きはじめてみると、HTMLはIDまみれになり、JSのソースコードはdocument.getElementByIdの嵐になったのである。せめて getElementByClassNameくらいは欲しい。誰もがそう考えた。

そこで登場したのが、prototype.jsだった。

prototype.jsは素のJSより書き易いだけでなく、簡単なアニメーションを実現するメソッドまで提供してくれた。これが世間でバカ受け。その流れを組んで登場したのが、script.aculo.usだった。

script.aculo.us によるアニメーション競争勃発

script.aculo.usがまだ自然にタイプできた自分に驚きつつ、.usというドメインが懐しく感じる今日では、アニメーションはJSよりもGPUアクセラレーションの効くCSSの仕事となっている。

しかし、当時は違った。なぜならば、CSSはまだ2.0であり、CSSでアニメーションなんて誰も考えていなかったからだ。

なので、WebでアニメーションをさせるにはJSかFlashしかなく、当時プロプラな環境だったFlashが使えない人はJSのライブラリに頼るしかアニメーションを実現する方法がなかったのである。

当時はネット環境も貧弱でCDNもなく、差別化の要素はカッコいいアニメーションだけでなく軽量という要素も重要だった。当時3Kbだったmootoolsなどが受けていた記憶がある。ただ、王道としてはprototype.js + script.aculo.usが鉄板だった。

しかし、JSは難しい。なぜなら、プログラミング的な知識以外にもDOMの知識が必要不可欠だからだ。なので、prototype.jsを使ったからと言って、誰でもJSが書けるという訳ではなかった。

何とかならないものか。そこで登場したのがjQueryだった。

jQuery幕府時代

わたしです

jQueryの登場は、いまから考えると日本における鎌倉幕府みたいな感じだ。

$を使うことで、誰もが簡単にDOMを扱えるようになり、メソッドチェーンを使って適当に書いたらなぜか動いた。これが世界を変えた。

数多のプラグインが作られ、当時世間を変えつつあったスマホにも対応するjQuery Mobileなど、カッコいいjQueryワールドに世界が包まれ、誰もが天下太平を予感した。

しかし、jQuery幕府は永遠ではなかったのだ。

テスト書けなくね? メンテナンス厳しくね? よろしい、ならばJSフレームワークだ。

まぁ、新たなものが生み出されるきっかけは色々とあるし、まだ歴史の途中なので、個人的な感覚でしかないが、jQueryの欠点としては、テストが書きづらく集団メンテナンスが厳しいと感じる人が現れたのがきっかけな気がする。

要するに、独りでゴリゴリ書くのは良いが、高度化するWebアプリケーションにおいて、jQueryだと設計とか保守性を担保するのが難しかった。

時代も変わり、誰もがWeb Application Frameworkを使うようになった。そこで、誰かが言ったのだ。『よろしい、ならばJSフレームワーク』だと。

JSフレームワーク戦国時代

そして、気付けばJSフレームワークが始まっていた。

まず、中央に踊り出たのはBackbone.jsだった。WAFの王者RoRで採用されたのも大きい。

しかし、勢力争いは留まるところを知らない。MVCからMVVM、アルファベットがどんんどん並び、Ember.jsAngularJS、よくわからんけど凄そうなヤツらがぼんぼん現れる。

まるでラグナロクであり、門外漢からして、この世の終りを感じた。

正直、フロントは難しい。しばらく静観しよう。誰もがそう考えた。そして、気付けば、Reactが生き残っていた。

React ← いまここ

WAFのMVCでは、JSはVに所属している。しかし、JSの中でもMVCがあるのは、神戸牛ステーキの上に松坂牛ステーキを乗せるようなものである。

JSなんだから、Vだけでよくね?Reactは当たり前のことを言った。そしたら、驚くほど使い勝手がよくなり、誰もが理解できるようになった。

そして世界は平和に包まれつつあった。To be continued...

別方面の戦い。それがAltJS。

JS界隈ははっきり言って過激だ。ライブラリ以外にも負けられない戦いがある。それがAltJSだ。

現状、生き残っているのは、Coffee ScriptTypeScriptが最有力候補で、Dartが瀕死の模様。最近のGoogleは負けが込んできている。

最近は、AltJSだけでなく本家とも言えるES6が注目を集め、AltJSに頼らなくても良くなるのか?という機運も高まりつつある。

しかし、現状では何とも言えない。たったひとつの真実があるとすれば、JSは滅びないということだけなのである。愛と同じだ。

つまり、JSは愛だったのだ。

というわけで、みなさまJSの歴史は分からないけれど、風俗の歴史はよく分かるFuzoku実践入門を宜しくお願いします。

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

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

pecoを使ってAtomでプロジェクトを開く

Atom使ってますか? 私はAtomを使って原稿を執筆しています。そして、最近は複数のプロジェクトが平行して走ることもあり、それら全てをAtomで編集しています。

様々なプロジェクトをAtomで開くには、Atomからプロジェクトマネージャーを使って管理する方法もありだと思うのですが、何だかんだでターミナルから開く方が早かったりします。

ターミナルからプロジェクトを開く

これまで、ターミナルからプロジェクトを開くには、私は次のようにしていました。

$ atom /path/to/project

atomコマンドからプロジェクトディレクトリを指定して開けばよいだけなので、過去に開いたプロジェクトの場合はC-rでプロジェクト名を検索して開いていました。

この方法も悪くないのですが、プロジェクトを開くためにコマンド履歴を使い続けるのも、少し違う気がしてきたので、別の方法を導入してみるとことにしました。

pecoを使ってプロジェクトを開く

ターミナルで絞り込みを使ってコマンドを実行すると言えば、近年だとpecoが最有力ツールだと言ってよいと思います。そこで、pecoを使ってAtomでプロジェクトを開くようにしてみることにしました。

pecoを使ったコードはみなさん色々と公開されているのですが、今回はzshにpeco + ghqを導入したメモを参考にして、Atomで開くコマンドを作成してみました。

function open-src-atom () {
  local selected_dir=$(find $HOME/projects/ -maxdepth 2 -type d | peco --query "$LBUFFER")
  if [ -n "$selected_dir" ]; then
    BUFFER="atom ${selected_dir}"
    zle accept-line
  fi
  zle clear-screen
}
zle -N open-src-atom

bindkey '^t' open-src-atom

私の場合、~/projects/CATEGORY/REPOという形式でリポジトリを配置しているため、find $HOME/projects/ -maxdepth 2 -type dというコマンドをpecoに渡しています。

これで、C-tから絞り込んでAtomでプロジェクトを開けるようになりました。

まとめ

本当はAtomproject-managerを使いたいところなのですが、自分でプロジェクトを追加するのが面倒で、結局使わなくなってしまったので、しばらくpecoで頑張りたいと思います。