Latest topics 近況報告

diffの逆の結果を見る（2つのファイルで同じ行を調べる） - May 10, 2017

このエントリはQiitaとのクロスポストです。

「diffの逆」って何だ？

diffコマンドを使うと、ファイルの中で変更があった箇所を簡単に調べる事ができます。

ただ、たまにその逆の事をしたくなる場合があります。つまり、2つのファイルの中で変更があった部分は無視して、同じ行があったらそこを列挙して欲しい、という場面です。

例えば、多言語対応のための言語リソース（ロケール）について、未訳箇所は原語のままにするというルールで運用している場合に、原語のロケールと比較して未訳箇所を調べたいというような場合がこれにあたります。

en-US.properties:

menu.new.label=New File
menu.save.label=Save
menu.close.label=Close
menu.properties.label=Properties
menu.exit.label=Exit
button.new.label=New File
button.new.tooltip=Create new file
button.save.label=Save
button.save.tooltip=Save (Overwrite) this file
button.close.label=Close
button.close.tooltip=Close this file
button.properties.label=Properties
button.properties.tooltip=Show detailed information of this file
button.exit.label=Exit
button.exit.tooltip=Exit without save

ja.properties:

menu.new.label=新規作成
menu.save.label=保存
menu.close.label=閉じる
menu.properties.label=Properties
menu.exit.label=終了
button.new.label=新規作成
button.new.tooltip=ファイルを新しく作る
button.save.label=保存
button.save.tooltip=ファイルを上書き保存する
button.close.label=閉じる
button.close.tooltip=ファイルを閉じる
button.properties.label=Properties
button.properties.tooltip=Show detailed information of this file
button.exit.label=終了
button.exit.tooltip=ファイルを保存せず終了する

こんな感じの2つのファイルがあったとして、menu.properties.label=Propertiesなどの箇所が未訳ということになりますが、あちこちに散らばっているこのような未訳箇所がどれだけあるかをパッと調べたい、ということです。

よく知られたやり方とその欠点

「inverted diff」「opposite diff」「reversed diff」「diffの逆」のようなキーワードで検索すると、以下のようなやり方が紹介されている事が多いです。

• comm -1 -2 oldfile newfile ：2つの入力の共通行を調べるcommコマンドを使った例。ただし、これは両方のファイルの内容がソート済みである必要がある。
• fgrep -x -f oldfile newfile：指定文字列にマッチする行を出力するfgrep（grep -Fと同じ。マッチングパターンを正規表現ではなく静的な文字列として扱うgrep）の-fオプション（マッチングパターンをファイルで指定するオプション。ファイルの1行が1つのマッチングパターンになる）と-xオプション（マッチングパターンに行全体がマッチする場合にのみマッチしたとみなすオプション）を使い、片方のファイル内の各行について、もう片方のファイルのいずれかの行と内容が完全一致する行を出力する。

他にもPerlを使う例もありますが、これらのやり方はいずれも、「2つのファイルで内容が同じ行を出力する」という物です。

それに対し、diffでは変更があった箇所を示すと同時にその前後の変更が無かった箇所も出力する、つまり前後の文脈を見る事ができます。「diffの逆」というなら、「変更が無かった箇所の前後の文脈」も見たくなって当然でしょう。

また、行単位で見れば内容が同じでも、出現位置が違うので全体としては意味が違う、という事もあります。前述の例はいずれも、このようなケースを検出できません。

真の「逆diff」

diffは、「ファイルを先頭から比較していき、内容が変化していない部分は飛ばして、内容が違う部分があったらそこを詳細に出力する」という事をします。

その反対となる逆diffには「ファイルを先頭から比較していき、内容が変化していない部分を詳細に出力して、内容が違う部分があったらそこは飛ばす」という事をして欲しいわけです。

ということで、それらしい事をやるシェルスクリプトを書いてみました。

inverted-diff.sh:

#!/bin/bash
context_lines=3

while getopts c: OPT
do
  case $OPT in
    c)
      context_lines=$OPTARG
      shift 2
      ;;
  esac
done

case $(uname) in
  Darwin|*BSD|CYGWIN*)
    esed="sed -E"
    ;;
  *)
    esed="sed -r"
    ;;
esac

oldfile="$1"
newfile="$2"

diff --new-line-format='+%L' --old-line-format='-%L' --unchanged-line-format=' %L' \
     <(cat "$oldfile" | tr '\r' '\n') \
     <(cat "$newfile" | tr '\r' '\n') |
  paste -s -d '\r' - |
  $esed -e "s/^([-+][^\r]*\r)*(([-+][^\r]*\r){$context_lines})([^-+])/...\r\2\4/g" \
        -e "s/(\r[^-+][^\r]*)((\r[-+][^\r]*){$context_lines})(\r[-+][^\r]*)+(\r?)$/\1\2\r...\5/g" \
        -e "s/((\r[-+][^\r]*){$context_lines})(\r[-+][^\r]*)+((\r[-+][^\r]*){$context_lines})(\r[^-+]|$)/\1\r...\4\6/g" |
  tr '\r' '\n'

実際にこれを先の例のファイルに対して実行すると、こんな結果になります。

$ ./inverted-diff.sh en-US.properties ja.properties
...
+menu.new.label=新規作成
+menu.save.label=保存
+menu.close.label=閉じる
 menu.properties.label=Properties
-menu.exit.label=Exit
-button.new.label=New File
-button.new.tooltip=Create new file
...
+button.save.tooltip=ファイルを上書き保存する
+button.close.label=閉じる
+button.close.tooltip=ファイルを閉じる
 button.properties.label=Properties
 button.properties.tooltip=Show detailed information of this file
-button.exit.label=Exit
-button.exit.tooltip=Exit without save
+button.exit.label=終了
...

ちなみに、前後の行をもっと出力したい場合は./inverted-diff.sh -c 4 en-US.properties ja.propertiesのように行数を-cオプションで指定できるようにしてあります。

実装の解説

キモになるのは、省略せずに全行の差分を出力する方法です。diffに--new-line-format='+%L' --old-line-format='-%L' --unchanged-line-format=' %L'という具合に「追加された行」「削除された行」「変更が無かった行」それぞれの出力フォーマットを個別に指定すると、変更が無かった部分が長く続いてもその部分が省略されていない出力結果を得る事ができます。

後の部分は、その出力に対して「変更が連続している部分をそれらしく省略する」という加工を施すための物です。以下、シス管系女子シリーズの読者の方向けに、本の中で解説していないテクニックについてもうちょっと詳しく解説しておきます。

• while getoptsで名前付きの引数をオプションとして受け取る定番の方法を使って-c 4のような行数指定を受け付けていますが、オプションの検出後にshift 2で引数のリストの先頭から-cと4を取り除く事で、その後の$1と$2が確実に比較対象のファイルを示すようにしています。これは、名前付きオプションと名前無しの引数を併用する形のスクリプトを書く時に気をつけないといけないポイントです（shift 2を忘れると引数の順番がズレてしまいます）。
• case $(uname)からのブロックは、環境によってsedで拡張正規表現を使うためのオプションが違うという問題を回避するために自分がよく使っているやり方です。
• <(cat "$oldfile" | tr '\r' '\n')というのは、「cat "$oldfile" | tr '\r' '\n'の実行結果の出力を内容としたファイルを、そこで指定した事にする」という書き方（bashのプロセス置換という機能）です。
• sedで複数行に渡る置換を行うために、一旦全行をpaste -s -d '\r' -で「\r区切りの1行の文字列」として結合しています。pasteを使った行の結合については別の記事で解説していますので、併せてご覧下さい。
• 拡張正規表現では、(パターン){N}と指定すると「そのパターンがN回繰り返された場合」を示す事ができます。これを使って、変更があった行が何行以上連続していたら間を省略する、ということをやっています。

残された課題

この実装ですが、やっつけ仕事なのでアラが色々あります。例えば以下のような具合です。

• diffの出力を一旦1行に繋げているので、入力が大きいとメモリを使いすぎる（多分）。
• 改行コードがCRかLFかの違いが無視される。
• 改行コードがCRLFであるファイルは改行が二重に表示される。
• diff -rのような再帰的な複数ファイルの比較に対応していない。

自分はここまででやる気が尽きてしまいましたので、どなたかやる気に溢れた方のアドバイスをお待ちしております。

Linuxコマンドで空きポートを探す - May 10, 2017

このエントリはQiitaとのクロスポストです。

適当な空きポートをlistenしたい場面があったのですが、「空きポート 探す」みたいなキーワードで検索しても「あるポートが空いているかどうか（そのポート番号についてファイアウォールでブロックされていないかどうか）を調べる」や「あるポートを誰かがlistenしているかどうかを調べる」という例はすぐに見つかっても、「誰も使っていないポートをランダムに1つ抽出する」という例はパッと出てきませんでした。なので書き留めておきます。

• /proc/sys/net/ipv4/ip_local_port_rangeでエフェメラルポートの開始番号と終了番号が得られる。
• shuf -i [start]-[end] -n 1で与えられた範囲の数字の中から1つをランダムに選べる。
• netstat -a -n | egrep ':[port] .+LISTEN'に成功した場合は誰かがそのポートをlistenしていて、失敗した場合は誰もそのポートをlistenしていない（ポートが空いている）。

という所から、空いているポートをランダムに1つ選ぶシェルスクリプトはこんな感じに書けました。

find_free_port.sh:

#!/bin/bash
available_port_range="$(cat /proc/sys/net/ipv4/ip_local_port_range | cut -f 1,2 --output-delimiter='-')"
while true
do
  port="$(shuf -i $available_port_range -n 1)"
  netstat -a -n |
    egrep ":$port .+LISTEN" 1>/dev/null 2>&1 ||
    break
done
echo $port

ncで一時的なサーバーを立てるとかそういう場面で使えるんじゃないでしょうか。

Windows 10移行時の環境設定でエクスプローラのアイコンのオーバーレイ表示が効かない奴に遭遇した - May 08, 2017

TortoiseGitのステータス表示が出なくてなんでや、と思って検索したらStack Overflowのスレとか日本語の解説とかがヒットした。要するに HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers以下のキーの文字コード順の並びで上位11個に入ってないやつは反映されないと……んでDropboxもTortoiseGitも登録しすぎと……そのうえOneDriveとかも入ってきてもうすっちゃかめっちゃかや。そういやTwitterのタイムラインでそんな話題が流れてたのを見た記憶がある。

とりあえずどっちが致命的かというとTortoiseGitの方なので、そっちが上に来るようにキー名を編集してみたところ、無事アイコンオーバーレイが有効になった。それにしても上位の取り合いのために名前の前にスペースを入れるとか、今は本当に2017年なんですか？って気分だ。

Windows 7からWindows 10への移行 - May 08, 2017

• 自宅のマシンの動作が最近ちょっと怪しくて、スリープから復帰しないみたいな事が発生する頻度が高くなってきた気がしてた。調べてみたら新調してから5年くらい経っていたので、寿命が近付いているのかもしれない。
• 会社で新調したマシンでWindows 10 on SSDを体験したらあまりに爆速だった。

という理由から、作業途中に突然死して慌てるくらいなら先んじて移行しておいた方がいいだろうと思って自宅マシンを買い換えた。パソコン工房のマンガ描きたい人向けモデルをベースに、メインを500GB SSDにしてサブは250GB SSDというSSDオンリー構成で発注し、届いた後で旧マシンからSATAのHDDを移植した（旧マシンには3台のHDDがあったんだけど、ベイが足りないので容量が一番小さかった1台はドロップアウトした。まだ動くので、USB接続で使うかもしれない）。

元々、2画面＋Cintiq Companion Hybridという計3画面の構成で使っていて、旧マシンでは3画面同時出力にビデオカードが必要だったのでそれも移植したんだけど、実際繋いでみたら新マシンはオンボードグラフィックだけで3画面いけた。追加のビデオカード、ただの電熱器になってもうた……

自分がよくやるWindowsの環境移行は、半分くらい真面目に移行して半分くらいは横着するというパターンで、こんな感じの方針でやった。

1. アプリケーションは、関連付け等きちんと初期化されないとまずいので、全部インストーラーから入れ直す。
2. 旧マシンから移植したHDDから、以下の位置にあるデータの中でよく使うアプリに関係する物を新環境の対応するパスにコピーする。（※ユーザの内部IDが変わっているので、コピーの前に、新環境のユーザにフルコントロールの権限を付与しておく必要がある）
   • *:\Users\(username)\AppData\Roaming （大抵のアプリのユーザ設定はここだけ移行すれば引き継げる）
   • *:\Users\(username)\Documents （ComicStudioとか、ここに設定を保存してる物がある）
   • *:\Users\(username)\Music （iTunesのライブラリはここにある）
   • *:\Users\(username)\.* （GIMPなど、UNIX・Linux系由来のアプリはホーム直下の.で始まる名前のフォルダに設定を保存しがち）
   • *:\ProgramData （作りの古いアプリがここに設定を保存している場合があるのと、比較的最近のアプリもユーザに依らない設定はここに保存してるっぽい）
   • *:\Program Files (x86)\JustSystems\ATOK （ATOKのバージョンに依らない広辞苑とかの辞書はここにある）
   • *:\Windows\Fonts （フォント。ファイルを全選択して新環境のC:\Windows\Fontsにコピーしようとすれば、フォントファイルはフォントとしてインストールして、そうでないファイルは警告が出るという感じでフォントだけ引き継げる）
3. レジストリハイブをロードする方法を使って旧環境のレジストリの内容を以下の要領で読み込む。
   • *:\Users\(username)\NTUSER.DAT→HKEY_USERS\old-(username)にロード
   • *:\Windows\system32\config\SOFTWARE→HKEY_USERS\old-softwareにロード
4. 以下の位置にあるレジストリキーの中から、新環境に引き継ぎたいアプリの設定をエクスポートする。
   • HKEY_USERS\old-(username)\Software
   • HKEY_USERS\old-software
   • HKEY_USERS\old-software\WOW6432Node
5. エクスポートした.regファイルをテキストエディタで開き、以下のように置換する。
   • HKEY_USERS\old-(username)→HKEY_CURRENT_USER
   • HKEY_USERS\old-software→HKEY_LOCAL_MACHINE\Software
6. .regファイルをダブルクリックしてインポートする。

他にもエロゲーとかC:\Program Files (x86)以下やC:\以下にデータを保存するお行儀の悪いアプリがあるので、それらも適宜いい感じに移行してあげるとよいでしょう。僕はこの方法で少なくとも以下のアプリの設定を引き継げています。

• Mozilla Firefox
• Mozilla Thunderbird
• ComicStudio 4.0 Pro
• Adobe Illustrator CS4
• GIMP
• ATOK2017
• 秀丸エディタ
• iTunes（ライブラリ）
• VirtualBox（仮想マシンのイメージの置き場所を変えたため、リンク作成シェル拡張でシンボリックリンクを作ってパスを合わせるようにちまちま調整する必要があったのと、UEFIの設定を変えて仮想化支援機能を有効化する必要があった）

こういう引き継ぎ方をしやすいように、ここ2〜3世代くらいは以下のことに普段から気をつけてる。

• アプリのインストール先は基本的に変えない。
• データの置き場所も変えない。ユーザーのホーム以下か、C:\Users\Public 以下に置く。
• ユーティリティの類はなるべく使わない。OSの環境自体のカスタマイズはなるべくしない。

中学高校の頃に中二病こじらせてアプリのインストール先（起動ドライブは空きを多くとりたい→なら別のドライブにインストール！）やらデータの置き場所（起動ドライブは空きを以下略）やら壁紙やらテーマやらカスタマイズしすぎた結果、移行の度にやれあれができなくなっただのこの設定がなくなっただのとイライラする羽目になったので、「できない事をしようとしない。靴に足を合わせる。自分でこうしたいと思って変えたものは、再現できないとストレスがものすごいが、唯々諾々と受け入れて慣れただけのものは、思い入れが無いから楽に忘れられる。」というデフォルト設定順応派にすっかり改宗してしまったのです。

でもそもそもの話、こういう乱暴な移行の仕方を真似するのはおすすめしません。非正規の方法を取って起こるあらゆるトラブルよりも、正規の手順でアプリの設定やデータをちまちま引き継ぐ手間の方が死ぬほど辛い、起こるトラブルは気合いで解決する、という本末転倒な事に陥っても構わない僕のような近視眼的な人以外は、真面目に普通に設定を移行した方がいいと思います。僕も、再設定が面倒でなかった以下の物は普通に入れ直して設定もやり直しました。

• Git for Windows
• TortoiseGit
• Dropbox

書評：まんがでわかるLinux シス管系女子 - May 02, 2017

発売から2年経ってニュース性がなくなっており、新規にレビューされることももはやなさそうなので、自分で読者の気持ちになってレビューしてみようという謎企画です。ダイマです。露骨ですね。それではいってみましょう。

---

本書は端的に言えば、「Linuxサーバーをコマンドで操作する事はあるが、決まりきったコマンド以外は使えずにいて、他にどんな事ができるのかわからないでいる人」「コマンド操作の訳の分からなさに挫折して、すっかり敬遠するようになってしまった人」のための本と言えます。

タイトルに「入門」とありますし、「マンガで分かる何々」と言うと全くの初心者向けの本という印象を受けますが、本書はむしろ全くの初心者にはハードルが高いくらいかもしれません。初心者から中級者へステップアップしようとしている人、ステップアップの仕方が分からず躓いている人向けのケーススタディ集というのが、本書の適切な位置付けでしょう。

技術解説するマンガ

世の中の「マンガでわかる何々」な本には大きく分けて2つの種類があります。1つは直前にレビューしたわかばちゃんシリーズのような、初心者の抵抗感を減じる導入・緩衝材としてマンガを使う物。もう1つは学研の「～のひみつ」シリーズや「マンガで分かる心療内科」のように、解説そのものがマンガになっている、解説のための表現手法としてマンガを使う物。実用書では前者のタイプが多いですが、本書は後者です。

本書はLinux初心者の「みんとちゃん」を主人公に立てて、みんとちゃんが遭遇する様々なトラブルや困った事態に対する解決策をメンターの「大野先輩」に教わる、という形でLinuxのコマンド操作を解説する構成になっています。前の話で紹介されたコマンドを後の話で使うという事はありますが、カリキュラム通りに学んでいくレッスン形式ではなく個別のケーススタディ形式で、マンガとしても4～8ページごとに1話完結のオムニバスとなっています。

それ故に本書は構成上のゴールが無く、スタイルとしては「技術雑誌の連載マンガの単行本」と言った方が適切でしょう（実際、本書は月刊誌である日経Linuxでの連載の最初の2年分をまとめた物で、次の2年分をまとめた物が続刊として出ています）。「1冊の技術書として通読することで何かを達成する、という性質の本」ではないことを把握しないまま読むと、尻切れトンボな最後で面食らってしまうかもしれません。

絵柄や絵の巧拙については、好みもある話なのでなんとも言えませんが、「これは何の事を描いているのか？」が分かる・解説として読む妨げにならない程度の水準は満たしているのではないかと思います。

解説の内容・質はどうか

本書で解説されている話題は、sshによるリモート操作からシェルスクリプトの基本までというLinuxの一般的な操作についてです。舞台設定やタイトルは「システム管理」を想起させますが、Webサービスの運用や組み込み機器の開発など、Linuxをコマンドで操作する際には共通して必要になる範囲の知識と言えます。コマンド操作を使い始めた頃に躓きがちな「あるある」な場面が多く、各トピックはいずれも実践的です。

また、紹介されているコマンドやツールは古くから今に至るまで現役で使われ続けている物がほとんどで、発売から2年が経過（※2017年現在）したものの、内容は陳腐化していません。一度読み込んでおけば、その後長く役に立つ知識が身に付くタイプの本と言えるでしょう。

ただ、本書の知識が長く役立つと言える理由は、単に解説されているツールが伝統的な物だからだけではありません。

コマンド操作が敬遠される理由の1つに、「覚えるのが辛い」というのがあります。コマンドの数は無数にあり、またそのそれぞれが多数のオプション指定を受け付けるため、組み合わせは膨大な数になり、とても覚えきれるものではありません。しかし実際には、中・上級者でもコマンドやオプションをすべて丸暗記しているわけではなく、よく使うコマンドがどのように作用し・どう相互に連携して・どんな結果になるのか、ということを頭の中で想像して適宜組み合わせて目的を達成している場合の方が多いです。

本書ではコマンドやファイルといった「登場人物」達を擬人化し、時にはナビゲーターであるみんとちゃん達自身をその図の中に飛び込ませることで、熟達した人達が頭の中で思い浮かべている主観的な「コマンド操作の向こうで起こっている事」のイメージをマンガとして描いています。文章での説明や抽象的な図よりもずっと生の感覚に近い「（擬似的な）映像体験」を得て、「そうか、先輩達にはコマンド操作の世界がこう見えているんだ！」と思うことができれば、抵抗感も薄れるのではないでしょうか。

全体を通して解説が24トピックというのは少ないように見えるかもしれませんが、個々の話題を丁寧に描いているので情報量自体は多く、実際に読むと物足りなさは感じないと思います（というか、自分は通読してものすごく頭が疲れました）。

残念な所

誉めるべき所がある一方で、技術解説の書籍としての本書には難点もあります。

まず前述した通り、「入門」というタイトルとは裏腹に、本書には基本的なファイル操作のコマンドなどに対する説明が含まれていないため、そのレベルでLinuxの知識が無い人には本書はおすすめできません。事前に最低限、cdやls、cp、rmといったファイル操作の基本コマンドの使い方は把握している必要があります。

（ちなみに、Web上で無料公開されている特別編ではその辺りの基本知識が解説されています。いまいち自信が無い場合は、本書を読む前にまずそこから目を通しておくと良いでしょう。）

文字を読む印刷物として、スクリーンショットの中で文字の色がグレーになっていて背景との判読が難しい箇所があるのも地味に辛いです。読みやすいように文字の色を調整したり、文字はすべてフォントで入れなおしたりといった工夫が欲しかった所です。

また、根本的な所で、手元のPCがWindowsである場合の事が全く考慮されていないというのも、初心者を対象とした本と考えると重大な問題です。Linuxのデスクトップ環境やmacOSであればターミナルからの操作で問題無いのですが、Windowsの場合は、Windows 10の開発者向けの機能であるUbuntu on Windowsや、MSYSやCygwin、もしくは仮想マシンにLinuxをインストールするといった準備をしないと、本書の内容そのままの実践はできません。Tera Termなどのシェル環境一式を伴わない端末エミュレータを使う場合は、本書の内容をすべてサーバー間の話（Tera Termからの接続先が本書中の「みんとちゃんの手元のPC」に相当する）として読み替える必要があります。これは恐らく、連載の掲載誌である日経Linux誌が「Windows XPからUbuntuへの移行」といった記事を多く扱っており、Linuxのデスクトップ環境を使うのが当たり前という雰囲気があることから、それに引きずられたのでしょう……

まとめ

上記のような難点はあるものの、本書にユニークな価値があるのは確かです。

クラウド、SaaS、DevOpsといった最近の技術的な潮流では、サーバーを操作するために自分でLinuxのコマンドを操作するという場面は減っていっています。しかし、障害発生時のトラブルシューティングや、サービス開発時のデプロイ手順の確立など、シェル上でのコマンド操作の知識が必要な場面は依然としてあります。

丸暗記でもコマンド操作は使えるには使えますが、コマンドや構文の意味を理解していないままだと応用が利かず、パターンから外れた途端にお手上げになります。また、コマンドの使い方をその都度検索しても、やりたい事に合致する例がすぐに見つかるとは限りませんし、最悪の場合、闇雲に実行したコマンドでファイルが消えてしまったなんて事も起こります。でも「自分が今何をしようとしているのか」を正確にイメージできるようになれれば、自信を持ってコマンドを組み合わせて、時には組み合わせを変えて、自在に使えるようになるはずです。本書は、そのようなレベルに自分自身を引き上げて、コマンドリファレンスなどの網羅性の高い情報ソースを活用できるようになるための、手がかりとなる1冊と言えるでしょう。

---

ということで、読者目線でのセルフレビューでした。

直前に読んだのがパッケージとして非常にまとまりの良いわかばちゃんのGit本だったので、それと読み比べると「シス管系女子」のパッケージとしての不完全さがどうしても目についてしまい、気が付くと「ここがダメ、そこがダメ」という事ばかり書きたくなってしまうのが辛い所です。でも、書評は駄目な所をあげつらうだけの物ではなく、その本の持つ価値を必要としている人のもとにちゃんと届くよう補助線を引く物でないといけないと思い、実用書としての評価をするよう努めてみました。

本書を薦められた人が「馬鹿にされた」と感じて拒絶してしまうという話を見ると、ああやっぱりピンクとオレンジがまずかったのかなあとか、タイトルがチャラそうなのが良くなかったのかなあとか、もっと成年誌っぽい絵柄だったらよかったかなあとか、詮無い事をつい色々考えてしまいます。レビュー内ではその辺りの事にあまり触れなかったのですが、実際どのくらい評価に影響するものなのでしょうか。気になります。

書評：わかばちゃんと学ぶ Git使い方入門 - Apr 30, 2017

「わかばちゃんと学ぶWeb制作の基本」のレビューを参照しながら書こうと思ったらそもそも書いてなかったので、先にそっちから書いていました。例によって自分は恐らく対象読者ではないのですが、人気の秘密を解き明かしてやんよ！とばかりに自費購入です。

本書は端的に言うと、「チームでGitを使う事になったが、よく分からないという人」「Gitをまだ使ったことがなく、なんだか難しそう……と尻込みしている人」「とりあえずなんとなくで使えてはいるが、決まった操作以外はできずにいる人」「チーム内のITエンジニアがGitを激推ししてくるのだが、使い方を覚えるのが億劫な非ITエンジニアの人」のための本だと思います。「Gitというツールの使い方の入門」＋「Gitを使ったワークフローの世界への入門」という、人がGitに初めて触れる場面に即した内容になっています。

わかばちゃんシリーズの2冊目ではありますが、解説の内容は独立しています。一部キャラクターは前作からの登場のため、説明がないキャラは「誰これ？」となってしまうかもしれませんが、解説の理解を妨げるほどではなく、前作から読んでいる人のためのファンサービスと言えるでしょう。

マンガで技術解説、ふたたび

前作同様、本書も「マンガは導入や簡単な説明で、その後のテキストが本編」という構成です。漫画要素は前作より多く、トピックによってはマンガの内容が解説として機能している部分も増えていますが、テキスト部分をすべて読み飛ばして成立する内容ではないので、基本的にはやはり漫画もテキストも全部読みましょうという事になります。

GitやGitを使ったワークフローはそれ自体がそれなりに複雑な物なので、何か基準を定めないと、解説する側も解説される側も混乱してしまうでしょう。本書は主人公の「わかばちゃん」がその基準となり、「これをしたい！」や「こういう事で困った！」という形で話題を展開していきます。まだGitを使ったことがないという段階の人が、「初心者がGitを使い始める時に起こる一通りの事」をわかばちゃんを通して疑似体験できる構成なので、予習としても苦痛を感じず通読できるのではないかと思います。

（似た分野で解説漫画を描いている自分としては、「あっ、この1コマで済ませてるやつもうちょっと2～3コマ使って段階的に説明したい……」と感じる箇所もあったのですが、これをやり過ぎるとマンガのページがどんどん膨れあがってしまうので、テキストを本文として置く限りにおいては現状はバランスの良い落とし所と言えると思います。）

純粋にGitの解説としての出来は？

本書の（ページ数的な意味での）前半はGitの基本的な使い方、後半は前半を踏まえてのケーススタディ集です。

Gitには山ほど機能があり、また、それぞれが関連しあっていることがあるため、「そういえば、あれも」「そういえば、これも」と解説し始めるとキリがありません。本書前半は「とりあえずこれだけ覚えれば使える」というレベルに持っていく事を優先して脇の話はざっくりカットしているので、多すぎる情報に惑わされることなく、押さえておかないといけない最も重要なポイントを知る事ができます。

また、そうして基本を分かった上でいざ使い始めてみて起こる様々なトラブルや「これをやりたい」といったニーズに対し、本書後半ではケースごとにその解決方法を解説しています。話題のチョイスとして、Gitの初心者～中級者が遭遇しがちな物がまとめられているため、実用性は高いです。

重要な事として、「やりたくなるけど、やっては駄目」な事は極力解説していないのも好印象です。具体的にはgit push -f絡みの話がそれで、データ喪失などの致命的な事態に陥らないためには「それはできない」という事にしておいた方が安全なのは確かです。この点からも、本書が実際の運用の事を強く意識していることが伺えます。

自分も解説を書く立場の人間ですが、自分も含めて自分から本を書こうというような人は、自分の持つ知識を無意味にひけらかしたがるものです（偏見）。よほど自分を抑制しないと、「Gitの生まれた経緯はこれこれこうで……」というような脇の話や、使用頻度の低い使いどころの難しい機能のように判断力（判断材料となる知識）が不足している初心者には使いこなせない知識など、実際の運用上はどうでもいい情報を盛り込んでしまいがちです。

その点、本書はわかばちゃんという視点を設定することで、「ここは教えなくていい」「今は教えない方がいい」というノイジーな情報をバッサリ切り落としていて、この本を必要としている読者のための本というスタンスを貫いています。読者に寄り添う姿勢を崩さない真摯さと、嘘を書かない真摯さを保ち、その上で必要な情報をきちんと盛り込むという本書のバランス感覚は、見事だと思います。

SourceTreeユーザ以外へのケアが課題か

これはターゲッティングによるものなので仕方がないのですが、基本的にSourceTreeを使っての運用の解説なので、それ以外のツールでのやり方は解説されていません。「SourceTreeを極限まで使いこなす」という観点ではなく「Gitを始めるにあたって最初の道具としてとりあえずSourceTreeを選択する」という観点での解説ですし、pushやpullといった用語はどのツールでも共通なので、本書での解説はほとんどそのまま他のクライアントに読み替えて応用できるのですが、コマンドラインツールのようにまったく操作体系の異なるクライアントの場合はそこそこ苦労しそうな気がします。

希望としては、例えば本書の説明の下にgitコマンドや別のツールでのやり方の説明があればなお良かったのでは？とも思うのですが、それをやり始めると内容が薄いわりに分量だけあるという本になってしまいますし、第一、多すぎる情報の提示は初心者を惑わすだけですので、これらをカットしたのは至極妥当だと自分も思います。電子書籍のように、補足的な内容を視界の中にオーバーレイ（スーパーインポーズ）表示できる媒体の発展に期待したい所です。

なお、gitコマンドを使った操作に関しては、著者の湊川さんご自身の手による以下のコンテンツが存在しています。

• 【コラボマンガ】怖くない！黒い画面入門【 #シス管系女子 ＋ #マンガでわかるGit 】 | マンガでわかるWebデザイン
• 魔王教授と学ぶGitコマンド入門 ダウンロード版 【オマケつき】｜湊川あい@わかばちゃんと学ぶ本 発売中｜note

副読本として本書と併せて読むと、SourceTreeを通した見え方以外のGitが見えてきて、よりGitへの理解が深まると思います。

シス管系女子＋マンガでわかるGit コラボ特別編の裏側（想像） by Piro/結城洋志 on pixiv

非エンジニアの人にこそ読んでもらいたい

上では「課題あり」という書き方をしてしまいましたが、コマンド操作に関する説明のような、見た目に抵抗感や苦手意識を持たれそうな内容をばっさりカットしていることで、第一印象でのとっつきやすさは高く保たれていると思います。そこで考えられるのが、非ITエンジニアの人にGitを使ってもらうための入門書としての活用です。

本書の例はWebサイト制作を想定して書かれていますが、Web制作であれば企画やデザイナーといった職種の人も実作業に関わってきます。また、自分が会社の業務として過去に手がけたWEB+DB PRESSの記事執筆でも、複数人で並行して執筆して最後にとりまとめるという事をGitで行っていました。バージョン管理システムや、それを前提としたGitHubのようなサービスの便利さは、ソフトウェア開発に限らずあらゆる場面で実感できるものです。こんな便利なものをITエンジニアだけで使うに留めるのは勿体ないです。

電子化可能なデータを取り扱うプロジェクトに関わるあらゆる人の間で、データを共有しその履歴をトラッキングするインフラとして、Gitを活用する。ファイルの履歴管理や連絡の手間から皆を解放する。そのような働き方の改革にすらなり得る手引き書として、本書は広くおすすめできます。

書評：わかばちゃんと学ぶ Webサイト制作の基本 - Apr 29, 2017

そういえばちゃんとした書評を文章としてまとめていなかったことに気が付いたので、改めて書き留めておこうと思います。自分は対象読者層から外れていますが、「マンガで技術解説」という非常に近い領域で活動をしている以上、気になるのは事実なので、それならいっそちゃんと読んで学びを得ようと思い自費で購入しました。

本書はひとことで言えば、「今これからWebサイト制作を初めてみようと思っている、スタート前の人のための本」「格好いいサービスに憧れてWeb制作を始めてはみたけど、知れば知るほど次から次に新しいキーワードが出てきて、勉強しないといけない範囲がどんどん広がっていってしまい、途方に暮れている人」だと思います。

昨今のWebというと、アプリ寄りの見え方をするSingle Page Applicationと呼ばれるつくりが流行りで、やれAngularだのReactだのという話になりがちだと思うのですが、それらも全て基礎があっての話。SPAを作るにせよ、そこから移り変わった次のトレンドに乗るにせよ、絶対に外せないであろう知識というのはあります。本書は、主人公の「わかばちゃん」をはじめとするキャラクター達を立て、わかばちゃんを皆がサポートして導くという流れに乗せて、Webサイト制作の基礎中の基礎となるトピックを一通り解説する入門書ということになります。

「マンガでWeb技術」？

本書の基本構成は「その節で解説する概念の大まかな絵解き説明、あるいは内容に絡んだネタの4コマ」と「それに続いてテキストや図での解説（本文）」という形で、マンガ部分の分量はそんなに多くはないです。「マンガで」という所に期待しすぎると、もしかしたら肩透かしを食らうかもしれません。マンガ部分だけを追った場合に得られる情報量は限られていますので、当たり前と言えば当たり前ですが、ちゃんとテキストも読むことが必要です。

自分は中学校でNEW CROWNで英語を初めて教わりましたが、いらすとや系の無色透明な・人格を意識させない絵ではない、漫画雑誌で見慣れた絵柄の・趣味嗜好などのバックグラウンドを持っていそうなキャラクター達（当時の物は「緋が走る」のあおきてつお氏がイラストを担当されており、この形式の先駆けだったそうです）がいることで、「堅苦しくてつまらない教科書、ではない。僕らの価値観、僕らの好みの事をちゃんと分かってくれている。頭ごなしに押し付けてきているのではない」と感じ、未知のものへの抵抗感がずいぶん薄れたような記憶があります。

10月の誕生盆栽で誕生日をお祝いするわかばちゃん＆HTMLちゃん by Piro/結城洋志 on pixiv

本書に対して抱く率直な感想は、その感覚に非常に近いと思います。解説のためのマンガというより、読者の心理的抵抗を和らげる緩衝材としてのマンガ、という性質が主であるように感じました。そして、その狙いは見事に果たされていると思います。自分を未熟な初心者のわかばちゃんと重ねて読み進めることで、Web制作にまつわる膨大なトピックの中から「まず最初に押さえておかないといけないのは、ここ！」という部分をストレスなく学べるのではないでしょうか。

肝心の「解説」の質はどうか？

マンガは導入に過ぎないとはいえ、本編のテキストも決して堅苦しくはなく、文字だけではイメージしにくいであろう抽象的な概念の説明に図を多用していて、全体としては平易な解説になっていてます。「分かりやすい解説書にする」ための工夫が凝らされていますので、引っかかりを覚えることなくするっと通読できると思います。

初心者向けの技術解説は、どこまで説明してどこからをカットするか、例え話をする時はどこにフォーカスしてどこを無視するか、話を単純にするために嘘をつくのかつかないのか、という匙加減が難しいものです。あれもこれもと入れていくと、必然的に個々の解説に割ける文章の分量が減り、説明はおざなりになってしまいます。

本書は、自分の役割はあくまで導入と割り切っていて、難しい概念の話は別の専門書に任せるスタンスを取ることにより、解説として無理をせず、極力嘘をつかない、誠実な立場を取っていると感じました。本書を読んだ後であれば、「扱う話題はやたら幅広いが、内容は薄い」初心者向けの本をすっ飛ばして、中級者向けやあるいはそれ以上の難易度の本や解説サイトに挑戦していけると思います。

本書に込められた魂

自分が本書の最大の特長だと思ったのは、HTMLやCSSといった「Webサイト制作に必要な道具」の使い方の説明に終始してはいないという点です。

分量のほとんどの部分がそういった技術の解説なのは事実ですが、本書はそれらの手前の導入部に「そもそも、その道具を使って何を作ろうとしているのか？　何のためにWebサイトを作ろうとしているのか？」という目標設定のフェーズを、後ろに「で、作ったはいいが本当に目的は達成されているのか？」というフィードバックのフェーズを設けています。これにより、本書全体に一本の筋が通っていて、「イラストが豊富で内容も平易だが、作者が何を言いたいというのは特に読み取れない、雑多な内容の本」ではない、「やりたい事の本質は人とのコミュニケーションであり、前提の立て方次第で最適な手段は変わる。手段としてWebを選ぶというのは、こういうこと。その手段はこういうもの」という考え方までもを伝える野心的な構成の本になっていると思いました。

だからこそのマンガ要素、なのかもしれません。そんな深いテーマを語る長いテキストは途中で飽きてしまうという人でも、わかばちゃんと同じペースで進み続ければゴールに辿り着ける、そういう本なのだと言えます。

まとめ

Webは新しい技術が絶えず生まれ廃れる、荒波のような世界であり続けています。Webサイト・Webページ制作に関わる技術の全体像を把握しきることは困難ですし、その場を乗り切るのに必要な部分だけをつまみ食いしていても、それぞれが文脈上結びつかない個別の情報を増やすだけになりがちなのではないかと思います。

本書「わかばちゃんと学ぶWebサイト制作の基本」は、そんな中を自分に自信を持って生きていくための基準点となる、一朝一夕に廃れることのない確かな知識を伝える1冊だと思います。趣味で始める人に、仕事で関わり始めたという新人に、あるいは、自分で制作はしないまでもWebサイト制作の専門家と組んで何かをしようという人に、おすすめです。

シリーズ第2弾のGit本のレビューもあります。

技術書典2への参加で得た物、思った事 - Apr 16, 2017

サークル「シス管系女子会」のここまでの活動の振り返りです。 技術書典と技術書典2、コミティア119、あとデブサミのDevBooks 2017にサークル参加して得られたデータや思った事を書き留めておきます。

商業出版物を同人イベントで取り扱うという観点から

最初にお金の絡む話から書いていきます。

ペイしたのかどうか

技術書典とコミティアは商業誌の販売が可能とのことだったので、シス管系女子1と2を持っていった他、技術書典と技術書典2では無料頒布のフリーペーパーやリーフレットも持っていきました。先に大まかな数字を出しておくと、かかった費用と実績は以下のような感じでした。

• 技術書典
  • 参加費:10000円
  • 無料配布物の実績:コピー本印刷費18000円、500部全て配布
  • 商業本の販売実績:各20冊前後だったか？
• コミティア119
  • 参加費:6400円（5800円＋オンライン申し込み手数料）
  • 商業本の販売実績:各10冊の計20冊（持ち込み分全て）、計34000円
  • 同人誌の頒布実績:新刊コピー本85部、計8500円
• DevBooks 2017
  • 参加費:無料
  • 商業本の販売実績:0（そもそも販売無しだったので）
  • 同人誌の頒布実績:コミティア新刊の在庫11部と今回新刊のコピー本15部、計2600円
• 技術書典2
  • 参加費:15000円
  • 無料配布物の実績:リーフレット印刷費約18000円、900部中640〜670部ほどを配布
  • 商業本の販売実績:計53冊、計90100円
  • 同人誌の頒布実績:コミティア新刊の再発行分18部とブックエンド4個、計9800円
  • その他費用:A0ポスター印刷費約1万円（半分に切ってA1ポスターとして使用）

イベント参加費と技術書典・DevBooksのコピー本、あと技術書典2のリーフレットの印刷費は日経BP持ちで、ムックの販売は中間マージン無しの委託販売の体裁として、ムック売上額はそっくりそのまま日経BP社に渡しています（oh, ボランティア……）。1日人を張り付ける人件費を考慮に入れなければ、多分黒字にはなっていそうな気がします。

無料配布物について

技術書典1ではコピー本を無料配布し、技術書典2ではリーフレットを無料配布しました。 ただのチラシを配ってもどうせ見てもらえないと思ったので、中身は漫画になっています（シス管系女子BEGINSの前後に「いかにも宣伝」という感じの漫画を足した）。通り過ぎる一瞬で目を留めてもらうのは無理でも、持って帰ってじっくり読んでもらえるといいな……という魂胆です。この辺は、イベント以外の場でも買える商業出版物ならではの割り切りですね。

元々、技術書典2でもコピー本の体裁の物を無料配布する事を考えていたのですが、思ったよりページ数が増えて表紙込みで24ページになってしまった結果、どう作っても1冊あたりの原価が100円近くになってしまう事が分かった（なのでDevBooksでは一応100円での頒布としました）ため、A4サイズ3つ折りのリーフレット両面を使った縮刷版という体裁にしました。苦肉の策でしたが、これだと印刷枚数次第ではフルカラーでも1枚20円を下回るくらいになるので、結構アリな気がしています。

最初の技術書典では当初は、スペースに置いておいて立ち寄って話を聞いてくれた方や希望者に手渡すつもりだったのですが、「どうせ無料で配布するのなら通りかかった人にどんどん渡しても同じなのでは？」とツッコまれて、それもそうかと思って「無料配布のサンプルです」と声をかけて渡していくスタイルに切り替えたのでした。

通行中の人への声かけは同人イベントではマナー違反とされている事が多いようで、COMITIAに至っては「呼び込み禁止」とはっきり明記されています。技術書典では「商業出版物を取り扱う場合は企業参加扱い」というレギュレーションで、特に明示的に禁止するようなルールの記載も無かったので「企業ならこのくらいはやってもバチは当たるめぇ」と開き直って声を出していましたが、迷惑行為と言われてしまうとグウの音も出ないので、チラシ撒きともども、やるならせいぜい前を通りかかる人に届く程度の声量に留めた上で、恨まれる＆出禁になる覚悟でやりましょう。とだけ書いておきます。

プロモーションの場としてはどうなのか

元々、シス管系女子会としてのイベント参加は以下のような目論見で始めました。

1. 既存読者層やTwitterのフォロワー層以外の人（会場で初めて知った、という人）へ認知を拡大したい
2. イベント用頒布物のために自主的に特別編を制作し、Webその他で自由に使えるコンテンツを増やすきっかけにしたい
3. イベントに参加された方のブログ等から2次的・3次的に情報が拡散されて欲しい

結論から言うと、このうち1と2は実現され、3は目立った結果には繋がっていないという印象です。

1は、前述の通り会場でのムック売り上げがそこそこあり、その際にシリーズ2冊をまとめ買いしてくださる方が多かったという事から、やはりまだまだリーチできていない潜在読者がいるという事の証明にもなっていると思います。

2は、元々出版社サイドに何度か「試し読みになるように本編の一部を公開したい」という事を打診しているのですが、「原稿料を支払って下請けに制作させたコンテンツを、何故下請けが勝手に外に出したがるのだ？」という意識があるのかないのか進展が無いので、だったら原稿料もらわなくていいから自分で好きに使えるように勝手に描くわという事でコンテンツを制作したという事です。実際にこれを動機として特別編を制作し公開に繋げられていることから、〆切駆動型の自分には確かに効果的でした。

3は、その後のイベントレポートやTwitterでの反応を見る限りでは、「このイベントで初めて知った」「この試し読みで初めて意識した」みたいな新規開拓の方の反応はあまり見られませんでした。また、全一般参加者の方のうち1/5～1/6にリーフレットを受け取って頂けた計算になりますが、イベントレポートの写真等で「会場で入手した物」の一覧に写っている例は少なかったように思いました。

• 「会場で無料配布のリーフレットを受け取るタイプの人」と「自分からイベントレポートを書くなどして情報を発信する人」は属性があまり重なり合わないということ？
• 「なにこれwwwwうけるwwwww拡散しよwwww」みたいなまでに人を突き動かす程のフックの強さが無い、ネタとしての爆発力に欠ける、という事？

理由は色々考えられますが、成果を上げるためにはまだまだ工夫が必要そうです。

「技術同人オンリー」イベントとしての技術書典

初回の技術書典の話はその時のエントリをご参照下さい。以下は技術書典2の感想です。

技術同人に関心のある人ばかりが集まる希有な機会として

技術書典2当日のTwitterの反応まとめを見ると、来場者が多すぎて入場が遅々として進まない事へのコメントが多く、参加を諦めた人も多かったというのは終わった後で知りました。方や会場内では、サークルによっては開場1時間や2時間で完売の拍手が上がっていました（6時間あるイベントの序盤での在庫切れというのは相当な読み違えがあったということになります）。「技術書オンリー」「同日に別の場所でも同人イベントが開催されており、その中にはけものフレンズのオンリーイベントも含まれていた」「天気は雨」など、来場者が少なくなる方向の材料ばかりがあったにも関わらずこの盛況さということで、当日に至ってすらも来場者数の読みが極めて難しい状況でした。

前回は会場が建物内の地下と2階に分断されていた上に、入場が整理券制になっていたことから、全体の様子というのは正直見えにくかったのですが、今回は他の同人誌即売会イベントに近いレイアウトだったので、全体の混雑具合などが俯瞰しやすかったです。そこで抱いた率直な感想は、まさに普通の同人誌即売会だなという事でした。

これは、コミケやコミティアなどに行った事のある自分からすると驚くべき事です。というのも、これらのイベントで評論・技術ジャンルのスペースを訪れると、他の混雑具合とは一転してびっくりするぐらい人がいないからです。そんなガラガラ具合のジャンルのサークルだけを集めるわけですから、本当にイベントとして成立するのか？という心配の声が運営サイドからすらも上がっていたのも頷けます。

別にアンケートや聞き取り調査をやったわけではないのでただの想像ですが、実はみんなこういう「知の共有」に焦点を当てたイベントを求めていたということなのではないでしょうか。

既存のイベントで技術同人が参加できるイベントといったら、基本的にはオールジャンル（取り扱う内容のジャンルを問わない、なんでもあり）のイベントですが、それらのイベントでは技術同人以外のサークルはほとんどが漫画やイラスト、エンターテインメント作品をメインにしていますし、比較的近いジャンルのオンリーイベントと思われる文学フリマであってもメインは小説や評論です。そういう状況では、技術同人に興味がある人でも、行く苦労や金銭的コストに対して得られる物が少ない、つまり「割に合わない」と判断されて、行ってみようという気が起こりにくいのではないかと思います。例えて言うと、アニメイトの一角で技術書籍のコーナーが設けられていたとして、技術者を自認する人がわざわざそこまで買いに行くのか？ あるいは、アニメイトに来る客が技術書コーナーまで見て回るのか？　っていう話です。

その点、技術書典は最初から技術書オンリーと銘打っていますから、「当たり」に出会えるだろうという期待値はグッと高まります。来場者が多いのは、他に類似のイベントが無いからそういうニーズがここに一気に集中してしまっているという事なのではないか。というのが、僕なりの予想です。

より質の高い情報が精錬され形になる機会として

IT技術者をやっていると、よく「技術カンファレンスや勉強会は、発表する人が一番勉強になる」「雑誌の記事や本は、著者が一番勉強になる」なんて話を聞きます。

知見やノウハウは、自分だけが見るメモ程度であればいくらでも書けますが、他の人にも共有できるレベルの内容に引き上げるのには手間がかかります。話を一般化したり、あやふやだった所を調べ直して根拠をはっきりさせたり、話題を整理したり……こういう事が面倒で、メモのまま放置されてしまう情報や、メモすら残されないまま忘れられてしまう情報というのは結構あります。

1コマの発表内容だったり1冊の本だったりといった「パッケージ」の形にまとめる時には、必然的にそういった作業が発生します。「イベントに参加するので」「そこで新刊として発表するので」という風に〆切を設定する事で、情報を精錬するための動機が生まれ、より価値の高い情報が出てくる、そういう動機になるというのは、技術書典というイベントの重要な意義の1つと言えるでしょう。

青田買いの場として

イベント終了後、技術書典2での刊行物をベースに商業出版する事になったという話を見かけました。同人誌で活躍していた人が商業誌で活躍するようになるというのはマンガ・ゲーム業界にはよくある話で、出版社の人が会場内を見て回って、有望そうな人に声をかけるという事が、技術書でも起こっているということのようです。

会場内で実際に売れ行きが良ければ商品化する好材料になるというのはもちろんあるでしょうが、そもそもこういうイベントに物を出している時点で「〆切を設定して」「それに間に合うように」「情報を整理してパッケージ化して」同人誌として世に出すという事ができている訳で、ネットでブログに断片的な情報を書き散らかしているだけの人に比べれば、商業出版物の原稿を書くという仕事にちゃんと取り組んでくれそうだと期待できるのではないかと思います。

著者と読者が対面で話せる機会として

最後に、これは同人誌即売会一般の話ですが、対面での頒布は「読者の方と直接触れ合える」という事が最大の特長でしょう。

先のまとめで「ネットでええやん」という感じのコメントをいくつか見かけましたが、VRでないただのインターネットモールを想定しているのであれば、それは「欲しい物を事前に決めて、買いに行って、買う」という事以上の意義をイベントに対して見出していないという事なのではないかと思います。同人イベントには、会場で作者に直接感想やお礼を言いに行く人もいれば、会場で読者が喜び興奮している様子を見たくて出展する人もいます。

自分の場合は、Webでない紙媒体で連載をやっていて、読者層がWebでアクティブな人達の層とは微妙に違うらしいという日経Linux誌での連載であることから、いつもはあまり「読者の方々に実際読まれている」という実感を持てずにいます。そのため、目の前にいる方に「持ってる」とか「読んでる」とか言って頂けるのは素直に嬉しかったです。普段なかなか認識できない「読者の実在」を意識することができて、励みになるのは間違いないです。

あと、対読者というのとはちょっとズレますが、ご同業の方と話せる機会としても自分にとっては有意義でした。技術書典2ではお隣のスペースがマンガで分かるWebデザイン/マンガでわかるGitの湊川さんのスペースだったため、イベント中やイベント終了後の合同打ち上げでこの仕事の事やそれ以外の事など色々話せたのがとても嬉しかったです。

DevBooks 2017について

そういえば個別にレポートを書いていなかったので、DevBooksの事についてもここに書き留めておこうと思います。

恐らく技術書典の成功を受けてだと思いますが、今年はDevelopers Summit 2017の会場内の1室に小規模な同人誌即売スペースが設けられていました。商業出版物の頒布は不可というレギュレーションだったので、直前のコミティア119での在庫放出と技術書典2向けの頒布物のプレお目見えだけできればいいかと思って参加してみました。

で、参加してみた感想なのですが、とにかく精神的にキツかったです。

というのも、通常の同人イベントだと全時間を通じて人の流れがありますが、DevBooksはデブサミの1コーナーという性質上、セッションとセッションの合間にどっと人が来るもののそれ以外の時間はガラッガラで、もう暇で暇でしょうがなかったです。一人での参加だったので、誰かに店番を任せてセッションを見に行くという事もできませんでしたし……

あと、「シス管系女子」というコンテンツとイベントの来場者層がマッチしていなかったようだという事も感じました。デブサミはどちらかというと流行りの技術に強い関心のある方が多いようで、DevOpsとかと真逆の方向を向いている「シス管系女子」は訴求力が無いのでしょう……多分。

ということで、もし2回目以降があるとしたらですが、「元々デブサミのセッションに興味があって」「技術同人もやっている」「当日は店番の手伝いをしてくれる人がいる」という条件を満たせる方が、会場内での荷物置き場確保も兼ねて参加するのが良いのではないかと思います。

まとめ

まあ何というかタラタラ書いてきましたが、オフラインのイベントはやっぱ良いですよ。オンラインでオンデマンドでいつでも欲しい情報が手に入る、どころか、欲しくない情報まで洪水のように押し寄せてくるのが当たり前の今だから、身体感覚を伴うライブな体験の価値がより際立つ。などという言い方も実に月並みですが、その月並みな体験をした上で「やっぱり月並みだね」と言うのと、体験しない状態で想像で物を言うのとでは違うと思いますので、未体験の人は体験してみて欲しいです。直近では4月29日に幕張メッセで「超技術書典」というのが開催されるので、まずはここから。

続き：技術書典3のご報告

Tree structure and tab icons are always lost after restart / 再起動すると必ずツリー構造やタブのアイコンが失われる - Mar 12, 2017

Q

When I start Firefox, tree of tabs and favicons are always lost. Even if I reorganize tree of tabs again, they are flattened after every restart.

Firefoxを起動すると、必ずタブのツリーとタブのアイコンが失われます。ツリーを作り直しても、再起動する度にツリーが失われてすべてのタブが同階層に表示されてしまいます。

A

Please press Ctrl(Command)-Shift-J to open the "Browser Console" - one of developer tools of Firefox. Is any error message like this reported?: NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE)
[nsISerializationHelper.deserializeObject] Utils.jsm:94

Screenshot:

Then, the problem may be caused by invalid information stored in your session data. Try following steps to cleanup your session data:

1. Close the browser console.
2. Input "about:config" into the location bar and hit the Enter key.
3. Skip the confirmation message by clicking the button in the page.
4. Input "devtools.chrome.enabled" into the "Search:" field.
5. Then you'll see just one entry. Double click it to turn the value to "true", if it is "false".
6. Open the browser console again by Ctrl(Command)-Shift-J. Then you'll see an input field at the bottom of the console.
7. Copy this script and paste it into the bottom field of the console:

   var TabStateCache = Components.utils.import('resource:///modules/sessionstore/SessionStore.jsm',{}).TabStateCache;
   Array.forEach(
     gBrowser.browsers,
     (browser)=>
       TabStateCache.update(browser, {
         iconLoadingPrincipal : null
       })
   );
   "OK"

8. And hit the Enter key in the field. Then you'll see a new message "OK" in the console.
9. Restart Firefox.

Ctrl(Command)-Shit-Jを押して、Firefoxの開発ツールの1つである「ブラウザコンソール」を開いて下さい。以下のようなエラーメッセージが出力されていませんか？：NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE)
[nsISerializationHelper.deserializeObject] Utils.jsm:94

スクリーンショット：

もしこのエラーが出ているなら、問題はセッション情報の中に混入してしまった不正なデータが原因で引き起こされている可能性があります。以下の手順でセッション情報をクリーンアップしてみて下さい。

1. ブラウザコンソールを閉じる。
2. ロケーションバーに「about:config」と入力し、Enterキーを押す。
3. 確認のメッセージが表示されるので、ページ内に表示されるボタンをクリックして先に進む。
4. 「検索：」欄に「devtools.chrome.enabled」と入力する。
5. 項目が1つだけ見つかるはずなので、値が「false」になっている場合は項目をダブルクリックして値を「true」に変更する。
6. Ctrl(Command)-Shit-Jを押してブラウザコンソールを開き直す。すると、コンソール株に入力欄が表示されるようになっている。
7. 以下のスクリプトをコピーして、その入力欄に貼り付ける。

   var TabStateCache = Components.utils.import('resource:///modules/sessionstore/SessionStore.jsm',{}).TabStateCache;
   Array.forEach(
     gBrowser.browsers,
     (browser)=>
       TabStateCache.update(browser, {
         iconLoadingPrincipal : null
       })
   );
   "OK"

8. そのまま入力欄でEnterキーを押す。コンソールに「OK」というメッセージが出力される。
9. Firefoxを再起動する。

テキストファイルの中に書いたinclude文をsedで解決する - Mar 02, 2017

このエントリはQiitaとのクロスポストです。

複数のファイルに共通する部分があるとき、共通箇所をまとめて切り出しておいて、各ファイルからはそれらを参照するだけにする、というのはよくある話です。C言語なら#include <stdio.h>という書き方をしますし、Web制作をやる人なら、CSSの@import規則をご存じだと思います。

しかしたまに、これに似たことを静的なファイルで行って「include文の位置に参照先のファイルがそのまま埋め込まれたファイル」を作りたいという場面が出てきます。

この記事では、そんな「静的なファイルを生成するために、ソースとなるテキストファイルに書かれたinclude文をシェルスクリプトで処理して、参照先ファイルの内容をその位置に埋め込んだ結果のファイルを得たい」というニーズに対する、なるべく効率のよい実現方法を模索してみます。

やりたいこと

以前、さくらのレンタルサーバーの一番安いプランでWebサイトを公開するノウハウという記事で、「ssh接続できない月額129円の激安レンタルサーバーでも、手元にLinuxな環境があるならコマンドラインのFTPクライアントとシェルスクリプトでrsyncっぽいことができるよ！ ついでに色々前処理もさせられるし、シス管系女子のサイトのようにチープな静的コンテンツだけのサイトなら全然余裕で運用できちゃう！ やったね！」という事例をご紹介しました。

その際にやりたかった前処理のひとつに前述のinclude文があり、全ページで共通のヘッダやフッタを

html/_parts/metadata.html（共通パーツ）:

  <meta charset="UTF-8">
  <meta name="twitter:card" content="summary_large_image">
  <meta name="twitter:site" content="@piro_or">
  <meta name="twitter:creator" content="@piro_or">
...

こんな風に断片ファイルとして切り出して用意しておいて、HTMLファイルの中に

html/index.html（ソースファイル）:

<!DOCTYPE html>
<html lang="ja" xmlns:og="http://ogp.me/ns#" xmlns:fb="http://www.facebook.com/2008/fbml">
<head prefix="og: http://ogp.me/ns# fb: http://ogp.me/ns/fb# article: http://ogp.me/ns/article#">
<!--EMBED(metadata.html)-->
  <title>シス管系女子って何！？ - 【シス管系女子】特設サイト</title>
...

のように書いておき、アップロード直前に

html_resolved/index.html（埋め込み後）:

<!DOCTYPE html>
<html lang="ja" xmlns:og="http://ogp.me/ns#" xmlns:fb="http://www.facebook.com/2008/fbml">
<head prefix="og: http://ogp.me/ns# fb: http://ogp.me/ns/fb# article: http://ogp.me/ns/article#">
  <meta charset="UTF-8">
  <meta name="twitter:card" content="summary_large_image">
  <meta name="twitter:site" content="@piro_or">
  <meta name="twitter:creator" content="@piro_or">
  ...
  <title>シス管系女子って何！？ - 【シス管系女子】特設サイト</title>
...

のように解決する、という事をしていました。

良くない実装例

最初に先の記事を公開した時の実装は、以下のようなものでした（実際にはちょっと違う書き方でしたが、要旨としてはこんな感じ、ということで）。

build.sh：共通パーツを埋め込む:

#!/bin/bash

# 環境によってsedで拡張正規表現を使うためのオプションが違うので、
# egrepコマンドのように使える「$esed」を定義しておく。
case $(uname) in
  Darwin|*BSD|CYGWIN*)
    esed="sed -E"
    ;;
  *)
    esed="sed -r"
    ;;
esac

rm -rf html_resolved
cp -r html html_resolved

# include文の検出用正規表現。
# ファイル名部分は、後方参照で取り出せるように`()`で囲っておく。
embed_matcher='<!-- *EMBED\( *([^) ]+) *\) *-->'

# 処理対象のファイル（include文があるファイル）を検索する。
egrep -r \
      --include='*.html' \
      "$embed_matcher" \
      html_resolved |
  cut -d ':' -f 1 | # ファイルパスだけを取り出す。
  uniq | # 1ファイルの中で何カ所も見つかる事があるので、重複を取り除く。
  while read path
do
  # 見つかった各ファイルに対して処理を行う。
  echo "updating $path"
  # ファイルを退避し、
  mv "$path"{,.tmp}
  # ファイルの内容を1行ずつスキャンする。
  # `IFS= read -r`とすることで、行頭・行末の連続する空白文字や
  # 行の中のエスケープ文字を保持する。
  cat "$path.tmp" | while IFS= read -r line
  do
    # include文がある行だったら、
    if echo "$line" | egrep "$embed_matcher" 2>&1 > /dev/null
    then
      # 埋め込み対象のファイルの内容をcatして、
      # リダイレクトで書き出す。
      parts_name="$(echo "$line" |
                      $esed -e "s/^.*$embed_matcher.*/\\1/")"
      cat "html/_parts/$parts_name" >> "$path"
    else
      # それ以外の行はそのまま書き出す。
      echo "$line" >> "$path"
    fi
  done
  rm "$path.tmp"
done

これでも一応目的は達成されていたのですが、以下のような問題が残ってしまっていました。

1. ソースの1行ずつに対してBashのwhileループを回すので、とにかく遅い。
2. 行の中にinclude文があると、include文の位置ではなくその次の行にファイルが埋め込まれる。

1は、処理対象のファイルの行数とファイル数が増えるごとに大きな負担となります。前の記事を書いた時には「変更が無かったファイルは無視する」という別方向からの対策を取ってみましたが、それでも全ファイルを対象に処理し直す時にはずいぶん待たされてしまいます。

2は、とりあえず今のところ問題にはなっていませんが、include文をHTMLのコメントの形式にしたので、もしかしたらこの制約の事を忘れて行中に書きたくなってしまうかもしれません。その時に「えっそんな制約あったなんて……」と戸惑う羽目になる前に、なんとかできるものならなんとかしておきたいところです。

より良い実装

その後長らくそれっきりになっていたのですが、仕事の中でまた似たようなことをやりたい場面（Firefoxの法人導入では管理者による設定を静的なJavaScriptファイルとして用意するのですが、「大部分は共通だけれども一部分だけが異なる」という設定ファイルを複数種類用意する必要が生じたのでした。共通部分を括り出すのでなく、ソースファイルに書かれたプレースホルダの位置に、環境ごとの別のソースファイルの内容を埋め込んで各環境ごとの静的なファイルをビルドしたい、という感じです）が出てたので、これを機にもっとマシなやり方を探してみました。すると、sedのrコマンドというまさにこういう事をやるためにあるような機能の情報が見つかりました。

ということで、ここからがこの記事の本題です。

マッチした箇所に他のファイルの内容を埋め込む、を高速にやる

sedのrコマンドは、「カーソル行の直後（次の行の直前）に別のファイルの内容を読み込んで挿入する」という物です。パターンマッチと組み合わせれば、「include文をパターンマッチで見つける→見つけたinclude文の箇所にinclude対象の外部ファイルの内容を埋め込む」という事もできるはずです。

例えば、最初に示した例をべた書きするとこうなります。

$ cat html/index.html |
    sed '/<!--EMBED(metadata.html)-->/r html/_parts/metadata.html' \
    > html_resolved/index.html

sedの機能なので、Bashのwhileループと比べると圧倒的に高速です。これで、問題の1つ目の「とにかく遅い」という点が解消されます。やりましたね！

マッチした箇所の次の行、ではなく、マッチしたまさにその箇所に他のファイルの内容を埋め込む

ただ、まだ問題はもう1つ残っています。sedのrは「マッチしたまさにその箇所」ではなく「マッチした箇所が含まれる行とその次の行の間」にファイルの内容を出力するため、行の中程にinclude文があると「include文の前の文字列→include文の後の文字列→参照されたファイルの内容→次の行」という結果になってしまいます。

この問題を解消するには、include文の後で必ず改行するように事前処理してしまうのが手っ取り早いです。

$ cat html/index.html |
    $esed "s/($embed_matcher)( *[^$])/\1"\\$'\n''\3/g' |
    sed '/<!--EMBED(metadata.html)-->/r html/_parts/metadata.html' \
    > html_resolved/index.html

何だかゴチャゴチャ書いてあって分かりにくいですが、置換の指定としては以下のような内容になっています。

• 置換前→(<include文>)(<改行と空白以外でinclude文より後の文字列>)
• 置換後→<マッチしたinclude文><改行文字><include文より後の文字列>
• 行内のマッチ箇所をすべて置換（gフラグ）

sedで置換後の文字に改行文字を含めれば行の途中で改行することができますが、それには色々と工夫が必要です。詳細はsedで改行を出力するをご覧下さい。

このように置換してからsedのrでinclude文を処理すれば、ちゃんと「include文の前の文字列→参照されたファイルの内容→include文の後の文字列→次の行」という順で出力されるようになるわけです。

ファイル内のすべてのinclude文を処理する

ここまでのコマンド列にはinclude文を解決するための指定をべた書きしていましたが、実際には任意のファイルでいろんなファイルに対するinclude文を処理する必要があります。後方参照でsed -r '/<!--EMBED\((metadata.html)\)-->/r html/_parts/\1'みたいなことができると楽なのですが、残念ながらsedのrコマンドの読み込み対象ファイルの指定には後方参照は使えません。

解決策としては、sedを実行するコマンド列をsedで組み立てるという方法があります。

$ embed_matcher='<!-- *EMBED\( *([^) ]+) *\) *-->'
$ embed_mark_to_resolver="s|($embed_matcher)| -e '/\\1/r html/_parts/\\2'|"
$ cat html/index.html |
    egrep -o "$embed_matcher" |
    sort |
    uniq
<!--EMBED(metadata.html)-->
<!--EMBED(footer.html)-->
<!--EMBED(header.html)-->
...

grepやegrep（grep -Eと同等）に-oオプションを指定すると、「マッチした文字列がある行」ではなく「マッチした文字列そのもの」、ここではinclude文の部分だけが出力されます。それをsed -r "s|($embed_matcher)| -e '/\\1/r html/_parts/\\2'|"で置換して-e 'sedスクリプト'というコマンドラインオプションに変換すると、こうなります。

$ cat html/index.html |
    egrep -o "$embed_matcher" |
    sort |
    uniq |
    sed -r -e "$embed_mark_to_resolver"
 -e '/<!--EMBED(metadata.html)-->/r html/_parts/metadata.html'
 -e '/<!--EMBED(footer.html)-->/r html/_parts/footer.html'
 -e '/<!--EMBED(header.html)-->/r html/_parts/header.html'
...

この出力に対してtr -d '\n'で改行を削除し（1行に繋げ）てsedのコマンドライン引数に指定すれば、ファイル内のすべてのinclude文を一気に処理することができます。

$ resolve_embedded_resources="sed $(cat "$path" |
                                egrep -o "$embed_matcher" |
                                sort |
                                uniq |
                                $esed -e "$embed_mark_to_resolver" |
                                tr -d '\n')"
$ cat html/index.html |
    $esed "s/($embed_matcher)( *[^$])/\1"\\$'\n''\3/g' |
    eval "$resolve_embedded_resources" \
    > html_resolved/index.html

ちなみに、-eオプションの指定の中には丸括弧など拡張正規表現では特別な意味を持つ文字があるので、これらは本来スケープする必要があります。が、$esedではなくsedを使うようにすればエスケープは不要です。

$resolve_embedded_resourcesと直接書くのではなく、わざわざevalコマンドを使ってeval "$resolve_embedded_resources"と書いているのは、組み立てたコマンドラインオプションの'が値の一部にならないようにするためです。というのも、そのままパイプラインの中に cat ... | $resolve_embedded_resources | ...と書くと、シェル変数が展開されてsed -e "'/<!--EMBED(metadata.html)-->/r html/_parts/metadata.html'" ...のように書かれた扱いとなってしまい、sedに「'なんてコマンドは無い」と言われてしまからです。evalを使えば、指定文字列を改めてシェルのコマンド列としてパースするため、sed -e '/<!--EMBED(metadata.html)-->/r html/_parts/metadata.html' ...と書いたのと同じに扱われるようになります。

また、これだけだとinclude文自体がソースの中に残ってしまうので、ついでにそれらを消す置換操作の指定も加えるとこうなります。

$ embed_mark_to_resolver="s|($embed_matcher)| -e '/\\1/r html/_parts/\\2' -e '/^ *\\1 *$/d' -e 's/ *\\1 *//'|"

1つのinclude文から3つの-eオプションができる形ですね。

さらに、これだとマッチしたinclude文の中にファイルパスのデリミタの/が入った時に破綻してしまうので、マッチングパターンの正規表現を囲う文字を/から;に変えておきます。

$ embed_mark_to_resolver="s|($embed_matcher)| -e '\\\\;\\1;r html/_parts/\\2' -e '\\\\;^ *\\1 *$;d' -e 's; *\\1 *;;'|"

sコマンドでは単に;で囲うだけでいいですが、rコマンドとdコマンドについては\;マッチングパターン;という風に最初に\を付ける必要があります。それをまた全体として1つの文字列の中に入れているので、エスケープがたくさん並ぶ読みにくいスクリプトになってしまいました……まぁこれはしょうがないです。

まとめ

以上を踏まえて前述のスクリプトの例を書き直すと、こうなります。

build.sh：共通パーツを埋め込む（改良版）:

#!/bin/bash

case $(uname) in
  Darwin|*BSD|CYGWIN*)
    esed="sed -E"
    ;;
  *)
    esed="sed -r"
    ;;
esac

rm -rf html_resolved
cp -r html html_resolved

embed_matcher='<!-- *EMBED\( *([^) ]+) *\) *-->'
embed_mark_to_resolver="s|($embed_matcher)| -e '\\\\;\\1;r html/_parts/\\2' -e '\\\\;^ *\\1 *$;d' -e 's; *\\1 *;;'|"

egrep -r \
      --include='*.html' \
      "$embed_matcher" \
      html_resolved |
  cut -d ':' -f 1 |
  uniq |
  while read path
do
  echo "updating $path"
  resolve_embedded_resources="sed $(cat "$path" |
                                egrep -o "$embed_matcher" |
                                sort |
                                uniq |
                                $esed -e "$embed_mark_to_resolver" |
                                tr -d '\n')"
  mv "$path"{,.tmp}
  cat "$path.tmp" |
    $esed "s/($embed_matcher)( *[^$])/\1"\\$'\n''\3/g' |
    eval "$resolve_embedded_resources" \
    > "$path"
  rm "$path.tmp"
done

筆者が普段使用している環境で新旧それぞれのスクリプトをtime ./build.sh -fという感じで実行して計測してみたところ、

環境	改修前のrealtime	改修後のrealtime
Ubuntu on Let's note CF-SX3	3.217秒	0.644秒
Raspbian on Raspberry Pi2 Model B	20.072秒	2.475秒

という感じで実時間で5～8倍の高速化となりました。ラズパイでも、カジュアルに全ファイルを処理させても気にならない程度まで高速になっています。万歳！

sedやawkだけでも頑張ればこういう事ができるのかもしれません。でも、ごく基本的な機能だけしか知らなくても「コマンドの実行結果でコマンド列を作る」という一工夫によってできる事の幅はかなり広がると思います。実際、この記事に「grepの結果をcut | uniqで加工しなくてもgrep -lでいける」というフィードバックを頂きましたが、これもまさに「grepの-lオプションを知らなくても、基本的な文字列加工コマンドの組み合わせで目的は達成できる」という事の一例と言えるでしょう。

この記事をご覧になった皆さんも、「自分はどうせ基本的な使い方くらいしか知らないから……ガッツリ覚えるつもりもないし……」と卑屈にならず、ぜひ柔軟な発想で問題を解決してみてはいかがでしょうか？

別解：Cプリプロセッサ（cppコマンド）を使う

ここまで「include文のようなことをsedでやる」という事を頑張ってみましたが、C言語のプリプロセッサ向けのinclude文そのものと同じ仕様でよければ、それこそCプリプロセッサをそのまま使うという方法もあります。

C言語のプリプロセッサはcppというコマンドとして単体で使う事ができ、UbuntuやDebianであればその名もcppというパッケージでインストールできます。Gemのパッケージ等でバイナリをビルドする必要がある物をインストールする際の依存関係で既にインストールされているという人も多いのではないでしょうか。これがインストールされている環境であれば、

html/index.html（ソースファイル）:

<!DOCTYPE html>
<html lang="ja" xmlns:og="http://ogp.me/ns#" xmlns:fb="http://www.facebook.com/2008/fbml">
<head prefix="og: http://ogp.me/ns# fb: http://ogp.me/ns/fb# article: http://ogp.me/ns/article#">
#include "html/_parts/metadata.html"
  <title>シス管系女子って何！？ - 【シス管系女子】特設サイト</title>
...

このようにソースに書いておいて

$ cat html/index.html |
    cpp -P \
    > html_resolved/index.html

と実行すれば、まさにC言語のソースと同じ要領でinclude文を処理した結果を得る事ができます（cppコマンドの-Pオプションは、プリプロセッサの行番号情報を出力しないようにする指定です。これを指定しないと、# 1 "<command-line>"やら# 1 "html_resolved/index.html" 1やらといった処理中のデバッグ情報的なメッセージまでが出力に含まれてしまいます）。

もちろん、include以外の構文も使えます。ただ、たまたまプリプロセッサ向けの書き方と同じ文字列があると意図せず処理されてしまうというリスクはあります。自分はC言語には詳しくなくて地雷を踏むのが怖いので、しこしこsedで頑張ろうと思います……