バージョン管理ツールというのがある。

バージョン管理ツールというのは「テキスト」の変更履歴を管理するツールのこと。

今日時点だとネットではgitが決定版と言われていて、ほかにもCVSやsvnなんてのもある。

このあたりは、ひとつのプロジェクトをチームで動かしているようなケースでは必須のツールだろう。実際にFreeBSDやlinuxなどOSのソースコードはこの手のツールで管理運用されている。

ただ、個人で、ひとりの作業で使うにはどうだろう。

これからはgitだ、というんでインストールしてみたものの、個人でちまちまやってる分には大袈裟すぎて管理のための管理作業が発生して面倒なだけだった。仕事で他の人が管理しているツリーにメンバーとして参加、コミットしたりとか程度でがっつり使ったこともないし、実際のところはよくわかってない。

とはいえ、

「納品20210110.zip」

「納品20210110b.zip」

「納品20210110-修正1.zip」

「納品20210110-修正0115.zip」

ということもよくあって、変更履歴の管理はさすがに痛感しているので、納品後の修正や差し戻しがあったら(って、なんでやねん、という話だけど)ディレクトリごと別ディレクトリとしてコピーして作業するようにしている。

こういう時に、もう10年ぐらい重宝しているのが、winmergeという差分確認、マージ(差分擦り合せ)のためのツールだ。

https://winmerge.org/

これがなければ仕事にならないし、これのためにWINDOWSを使い続けている、といっても言いすぎじゃない。

神ツールとはまさにwinmergeのことを言う。

2つのファイルの差分をチェック

百聞は一見に如かず。

ふたつのファイルで違いのある箇所が左側のルーラーの黄色の部分。

メインの左右画面では違いのある箇所が赤く表示される。

差分、変更箇所がすぐに目視できる。差分のある箇所を個別にどちらかに合わせることもこの画面ですぐ、だ。編集されて上書き保存されたら元ファイルは拡張子が.bakになって保存される。

これはeasy_epubという電子書籍作成スクリプトのソースコード。

左側がオリジナルのリフローEPUB用、右側がハイブリッド対応版

無駄に機能追加したり、つぶしきれないバグフィックスをするたびに、別フォルダにコピーして修正。修正したらwinmergeで修正箇所、修正漏れの確認をして動作確認。動作が意図どおりじゃない時などもwinmergeのおかげで修正箇所の洗い出しが一発なので楽チン。

ディレクトリごとの比較

winmergeにファイルではなくてディレクトリを指定して読みこませると、ディレクトリ内で違いのあるファイルがこれまた一目瞭然。

違いのあるファイルが黄色くハイライトされている。

これはdoncha.netのサイトの一部。スクリプトやhtml、css、javascriptなどいろんなファイルがてんこ盛り。

webの場合、デザイン変更ひとつ取ってもhtml、構造の変更なのか、css、見た目のデザイン変更なのか、そのためにスクリプトやデータベースの変更は必要なのか、などなど、いろいろ絡んでくる。どのファイルを変更しなきゃいけないのか、実際どのファイルを変更したのか。

winmergeが一目で教えてくれる。

差分のあるファイルを選んでクリックすると２つのファイル比較となり編集更新ができる。

テキストの変更箇所、差分を教えてくれる、直感的で超絶便利なツールがこのwinmergeだ。

ということは。

プログラムとかエンジニアだけのものじゃなく、webのソースとかデザイナーだけのものじゃなく、テキストを扱うすべてのひとにとっての神ツールということだ。

小説書き、モノ書きのひとにとっても、語尾や用語を合わせる前後や、追加エピソードやセリフの確認とその比較に使える。

一太郎やワードはさらにモノ書きに特化した機能満載だから、それで間に合っているかもしれないけど、一太郎もワードも入っていないパソコンもあるしね。

gitやsvnのように更新、変更履歴を追うことはできないけど、winmergeさえあれば、個人でやる仕事については、万全磐石の安心感。

だがしかし、めちゃくちゃ残念なことにwinmergeはWINDOWS版しかない。macにもchromebookにも当然ない。

わたしの弁当箱macはすでに最新のOSアプデ対象外となっていて、今はただの鉄の箱だからいいとしても、去年末あたりから使い始めたchromebookで使えないのは致命的。このchromebook化したASUSのvivobookで委託のWEB運用、請負の電子書籍制作をやっていて、特に電子書籍の方はwinmergeでの作業がはいる。

原本、底本の元データと電子書籍化したEpubデータの差分チェックは欠かせない。

作成中にルビを取りこぼしたり、全角の空白を潰したりしてしまうこともあるし、修正依頼に対応したら修正の必要がない箇所に影響したり、などなど確認項目は多岐に渡る。

そのためだけに、WINDWOS機を起動してwinmergeで確認してたんだけど、さすがにどうにかせんといかんなあ、と必死のぱっちでぐーぐる先生。

「漢」ならdiffで頑張れ

とか言われてるんだけど、いくらなんでも無茶すぎ。そこでvimの出番となった。

エディタのvimがほぼ万能で、こいつもできないことを探すほうが難しいやつ。

vimdiffという差分チェックができるモード(？)がある。見た目もwinmergeとほぼ同じ、ていうか、vimdiffの方が先だろう。これで、ディレクトリ内のファイルの比較もできればなあ、と。

たぶん、いや、間違いなくvimだけでできると思うんだけど、わたしにそんなスキルも時間もないので、diffでディレクトリ比較した結果を適当に整形して読みこんで画面分割してやってみることにした。

winmergeほど便利じゃないんだけど、やりたいことはほぼこれでできることとなった。

ちなみにvimについては

https://knowledge.sakura.ad.jp/23018/

↑こちらのサイトがおすすめ。

しかしなあ。

21世紀にもなって、ラクをしようとするな、ツールなんか信用するな、というクズな仕事場もあって心の底から呆れるばかり。どうぞそのまま滅んでくださいとしか。

つい先日、初の5連勝だ！こんなチームだ！とかここに書いたら、その後5連敗5連敗で一勝もできずに枕を涙で濡らす日々だ。

これはなかなか手ごわい、ていうか難しい、ていうかへなちょこだなあ、おれ。

ヤドラン・ドダイトス・ギラティナ（アナザー）のチームだったのを、ギラティナの代わりにピクシーを入れたら難しかった。

考え方としては、ヤドランでギラティナ、トゲキッスの相手をするんだけど、一対一ではさすがに厳しいのでこちらもギラティナで援軍。その合わせ技で突破、というところだった。

それならギラティナでなくてもピクシーでいいんじゃね、と思ってラインナップを変えたら難しかったなあ。それって、ほぼプレイヤースキルの問題だけど。ゲージ技の貯め方や交替のしかたで勝てた試合を落としてたと思う。

チームとしてはそんなに無茶なチームではないと思う（相手にアロベトあたりが入ってくると手も足も出ない構成だけど）

にしても、上手いひとは本当にうまくて、とても敵わない。

・交替受け

こちらのゲージ技発動のタイミングを読んでポケモンを入れ替えてくる

→ゲージ技が致命的なので、そのゲージ技に耐性のあるポケモンに入れ替える

→HPをミリ残しで下げていたポケモンに入れ替えて受ける

どちらのケースもこちらのゲージ技が無駄になるし、ふたたびゲージ技を撃てるまで貯めるのに時間がかかることになる

・貯めて交替（起点にされるというやつ）

→通常技でゲージを貯めておいてひっこめる。次に出てくる時には最初っからゲージ技を撃てることになっている

いきなりゲージ技が飛んでくるので対応ができない

たぶんこの２つ以外にもあるんだろうけど、この２つでもう負けた感。うひゃあ、これは勝てないと思う瞬間、てやつだ。

今回のメンバーだと対応できなかったなあ。やっぱギラティナが必要か…でもそれじゃあ面白くないし。うううむ。

などなど悩んでるのもまた楽しい時間の過ごしかただ。

とりあえず、音声付きの電子書籍を自力でもなんとか作りたいなあと思ったのでごそごそやってみた。

最大のハードルは音声ファイル。

いや、音声合成のアプリを購入すればそれで済むんだけど、落ち目甲斐性無しの初老フリーターにそんな余裕はなくて（お仕事お待ちしております！）この時点で諦めてた。

ところが検索したら、macのsayコマンドで読み上げさせる・音声ファイル（mp4やm4a）として書き出しまできるというのを見つけて俄然やる気になった。

サンプルは青空文庫『キリストのヨルカに召された少年』（何度もくどいけど、こいつは大傑作の掌編なので読むべし）

手順その1

音声合成するためのEPUB3ファイルの作成。

でんでんコンバーターを参考に、ウチのeasy_epubに、とりあえず本文を句読点ごとにspanタグでくるんでepubファイルの作成ができるオプションを追加。spanタグに通しのidも振るようにした。

これで本文の仕込みは完了。

手順その2

spanタグで区切られた単位の文章一行ずつのファイルを作る。

このファイルを読みこんでsayコマンドに渡して読み上げ用音声ファイル.m4aを作る。

mac スゲー！ていうかunixはスゲーです。

perlは便利…だけど、たぶんautomaterとかシェルスクリプトでもできる、ような気がする。お好みのツールで。

手順その3

音声同期ファイル（.smilファイル）を作る。

・本文に仕込んだspanタグのidをここの text srcに指定する

・音声ファイルと、その再生時間を記述する

・おのおののidはテキトーで良さそう（ほんまかの結果オーライ）

今回は「ひと区切りごとにひとつの音声ファイル」としたので「ClipBeginは0でClipEndは音声ファイルの再生時間」だけどひとつの音声ファイルでまかなう場合はClipBeginとClipEndの指定をしっかり計算する必要がある。

（でも、ここもmp4の情報を取得して足し算して、というだけ。perlなどのスクリプト言語で一括処理できるところなので、あまり難しく考えることもないかな。…あ、うそ。これだといちいちフレーズが何秒か調べなきゃいけないのでとても無理っぽい）

手順その4

音声ファイルと.smilファイルを、OEBPSフォルダの下、たとえば「multimedia」というフォルダを作って放り込む。

手順その5

EPUBのパッケージファイル、content.opfを編集する。

・metadata部

durationに再生時間を記述

読み上げと同期してハイライトさせるためのcssのクラス名を記述（cssには「-epub-media-overlay-active」というクラスを作っておく）

・manifest部

この本文にこの.smilファイルを適用します、というのを記述

.smilファイルや音声ファイルの定義、設定を記述

以上で完成。

media overlaysに対応した（Readiumなどの）リーディングシステムで読み上げできる。

昨日の雑記にも書いたように、読み上げを耳で聞きながら、ハイライト部分を目で追いながら。視覚・聴覚から入ってくる読書体験は刺激的だ。

macのユーザー補助の読み上げ音声を使ってるのでVoiceOverと同じじゃん、ということなんだけど。

手順その2で文章をひとつずつsayコマンドに渡して作るので「明らかな読み間違いはここで校正できる」のがmedia overlaysのポイントかな。

やっぱ、読み間違いは校正・修正したいのが人情ってやつだ。

てことで、校正もしていないそのままのepubファイルはこちら

ttp://t2aki.doncha.net/tmp/20150217_voice.epub

（↑ tmpフォルダは直リンクできないので、こちらからどうぞ）

[02/19 08:11:03] 追記

すみません。macの音声を入れて作ったEPUBファイルを公開するのは、使用許諾契約書を見ると「Appleソフトウェアが起動中である場合」に引っ掛かりそうなので取り下げておきます…。

F. ボイス 本契約の契約条件に従って、お客様は、Appleソフトウェアに含まれるシステムボイス(以下「システムボ イス」といいます)を、(i)Appleソフトウェアが起動中である場合、かつ(ii)お客様自身のオリジナルのコンテンツおよ びプロジェクトをお客様の個人的で、商用的でない利用のために作る場合に使用できます。

↓作成手順を動画にして、作成に使ったスクリプトを公開

『 動画で見る音声付き電子書籍の作り方』

↓実際に作った音声付き電子書籍一覧

『「眼聴耳視」音声付き電子書籍公開リスト』

[更新]2015-07-03 08:33:05

「今さら」以前からあちこちで言われていたように「電子書籍」という名前がまずかった。

「電子書籍」は「書籍」じゃなくて、既存の本を電子データコンテンツに移植したなにか。

売るためにパッケージして名前をつけなきゃいけないのでebookと、電子書籍と名付けられて呪われてしまった。名前をつける行為は昔から呪術的だしねえ（てなことを以前ちらっとだけ書いた）

読む側にしてみると実体として本がまだまだ魅力的だろう。

Kindleストアで電子書籍は売れる？ (2012/10/31)

「本を手に取って、開いてめくる。文字を読む、文章を読む」体験は、味覚以外のすべての感覚を使った豊かなもので、電子書籍では味わえない。
新しい本・古い本で匂いは違うし、本を読んでいて読み進むにつれて右ページ側左ページ側で重さが変わるし、ハードカバーと文庫ではページを捲る音が違う。

上記は、どちらかというと読み手側視点から。kindleのKDPのおかげで電子書籍を作って並べるのに、ハードルがぐぐぐぐぐっと下がって、誰でも簡単にできるようになった…のはいいけど、今度は書き手側に広がる電子「書籍」という名前の呪縛。

紙印刷は誰がどこで見ても同じものが見える。それと同じことを電子書籍に要求するのは筋違い・無い物ねだり（紙のレイアウトデザインを忠実に再現するPDFでさえ、パソコンで見ると、ディスプレイの色調整次第で別モノの印象を与えることもある）

電子書籍は紙の本、書籍というよりもWEBに近いシロモノだ。

「自分のパソコンのディスプレイ上で」デザインやレイアウト、文字の装飾やフォントの選択など細かくこだわって作り上げて販売しても「他人のパソコンのディスプレイ上ではどう見えるか決めることはできない」

パッケージされたデータを解釈して表現するのはユーザー側にあるアプリやデバイス。画面での表示サイズや色などユーザーが接するところはユーザーがアプリを通じて自由に自分の都合で変更できる。書き手が自分の目の前で完成させた形をそのまま伝えるのは難しい。

インターネットの「ホームページ」、昔は「推奨ブラウザはFireFoxで、画面は1024x768以上、フォントサイズは12pxでご覧ください」なんてページがあったのと同じことかもしれない（作り手の環境をユーザーに押しつけちゃいけません。というのがユーザビリティというヤツ）

みんなが同じものを見るのが前提の紙印刷とは真逆（反射光と透過光ですね）

kindleの個人作家のツイート「販売停止にされた！けしからん！！」と怒る気持もわかるけど、電子書籍に対する誤解が元になってないか。

フォントをはじめとする表示まわりを決めウチで作り込んでないか確認するのが先。ファイルの作り方が間違ってないかチェックするためのツールはあるし、kindleは丁寧なガイドライン（PDF）が「ヘルプ」ページにあるので問題点を洗い出してまず調べる。

その上で「意図通りのもの」にすることを考える。

電子書籍は書籍とは別モノ。

[更新]2026-02-02 07:49:38

Ajaxでページ遷移なく見せる、のはいいんだけど、ブラウザの戻るが効かないので、ちょっと弱った。

さっそく検索してあれこれ。

page0の中のリンクをクリックしてpage1に移動。

page1の中のAjax部分をクリックしてpage1の中の一部を書き換える。

と、ここまでは期待どおり。

で、そのpage1を見ていて、ブラウザの戻るボタンを押すと、page0に（当然）戻ってしまう。

page1の中が書き換わっているんで、「戻る」に期待するのは書き換わる前のpage1

ajaxでページが書き換わっていますよ、というフラグを立てておいて、

window.onunload=function(){

if( ajax_page ){

location.replace(document.location)；

}

ajax_page = ’’；

}

とやれば、ブラウザの「戻る」が期待どおりとなった。ただ、これは、単純に戻るだけ。フォームなんかがある場合、きちんと入力されたものの面倒を見てあげる必要がありそう。そうなるとまた面倒かな。

参考にさせてもらったURL

http://japan.internet.com/developer/20080215/26.html

http://fnya.cocolog-nifty.com/blog/2006/12/post_8be2.html

金曜土曜と飲みすぎて、今日はへろへろとウチでごろごろ。そういや、ヨメにつきあっていった表参道のかんざし屋さんは、わたしのようなおっさんが見てもいい感じのカワイイモノだった。

http://www.wargo.jp/

[02/17 23:11:44]

とか思ったら、やっぱり「戻る」がうまくいかんなぁ。何度か「戻る」で、「戻る」のhistoryが尽きてしまって、戻れなくなってしまう。ダミーでもhistoryに突っ込めれば、と思って検索してみるけどヒットせず。

書き換わるコンテナ部分に「戻る」をつけて代用して…もらえるかねぇ。。。

[02/17 23:26:30]

あ。そういや。

ふたたびみたび、東京歯科大学水道橋病院。取れたブリッジをもって久しぶりの水道橋。とりあえずそのまま入れてもらって、歯周病のための、歯石取りなどなど、でしばらく通うことになった。担当の先生は約2年前と同じ、歯ヲタクっぽいねいちゃん先生だ。

地元のヤブくさい歯医者に比べると、やっぱりこっちは数段安心感がある、かな。

予約の時間までちょっとあったんで、時間つぶしにはいった旭屋にびっくり。入り口すぐ、レジ前の面陳スペース（特等席）がコミックコーナーになってた。客もまばらで、儲かってません感、がヒシヒシと。書店としての矜持、みたいなものはないんかい。