Latest topics 近況報告

BLAME!の映画を見た後で原作を読み返したらもっと映像見たくなった - Jun 05, 2017

NETFLIXで映像化されたやつを映画館で見てきた。「すげえええ～～これまさに『俺の見たかったBLAME!のアニメ』やああ～～」って大興奮だったんだけど、帰宅後原作を読み返したら意外と色々違ってた。「シドニアの騎士を経た後の弐瓶勉」感もミックスされて色々アップデートされたBLAME!と言った方が適切なようだ。パンフレットは売り切れで買えなかったので、以下パンフレットに書いてある話と違う的外れなこと言ってたらごめんなさい。

• CG WORLDのインタビューでも触れられてたけど、づるがめっちゃ美少女になってて別人過ぎる。
• あのシャキサク、こうやって食べる物だったの！？ しかもうまいの！？！ っていうか原作みたいに生（？）で食べたら死ぬ……？
• 霧亥がアニメで着てたのは原作終盤の衣装で、原作序盤はもっとあっさりした服だった。あの服でこの映像の中にいたら結構ギャグっぽく見えたかもしれない。
• 種族の違いによる体格差、は今回は省略されてたように感じた。原作だと電基漁師達は大人でも霧亥より小柄だったけど、映像ではそこまで露骨な差は無かったような……？
• シボは原作では有機的なボディという設定だったのか発見時の腐った体も修復後の体も生身の人間っぽくて「えっ？ えっ？ なんでこの人腐ってるのに喋ってるの？？」って思ってたんだけど、アニメでははっきりメカな描写になっててだいぶ「分かりやすい」表現になってるなあと思った。
• 偽装端末遺伝子（だっけ？）とか自動工場とか、原作よりスマートで硬質なビジュアルにデザインが変更されててそこも見やすいと思った。工場の新しいビジュアルは、原作終盤にちょろっと出てきた別の施設のデザインの流用か？
• 珪素生物や東亞重工は出番無し。入れると情報量増えすぎだからこれは妥当だと思う。
• 工場脱出時にシボが霧亥に「ごめんなさいね」か「残念だったわね」か何か言ってたと思うんだけどあれどういう意味だったんだろう？

総じて、原作のぐにょぐにょした有機的イメージは抑えめで、メカはメカと分かりやすい描かれ方に統一されてるなあと思った。これはCG作画だからという制約による部分もあるのかもだけど。

とりあえず、この1作だけじゃなくもっといろんなエピソードをこのクオリティの映像で見せて頂きたい、そしてそれに浸りたい、なんならVRでこの超構造体に挟まれた階層都市内での生活を体験したい（絶対後悔するけど）、という「もっとこれくれぇぇぇええ！！」感を覚えた次第でした。

[まとめ買い] 新装版　ＢＬＡＭＥ！（アフタヌーンコミックス）

posted with amazlet at 17.06.04

Amazon.co.jpで詳細を見る

PHP勉強会で漫画の描き方を発表してきました - Jun 02, 2017

技術書典2で隣のスペースだったマンガでわかるWebデザインとかGitとかの湊川さんが第113回 PHP勉強会@東京で発表されるということでPHP勉強会の運営の方がご挨拶にこられていて、その時になんやかやでお声がけを頂いて発表の機会を頂く運びとなりました。じぶんPHP使ってないんですけど！？（ずっと以前に案件でPHPを使う物があったのでちょっとだけ触ったきり）と戸惑ったのですが会的には全然アリだとのことだったので、第114回 PHP勉強会@東京にて思いっきり漫画の話に振った内容でプレゼンをさせて頂きました。資料はSpeaker Deckで公開済みで、画像の解像度を落としたソースも公開してます。当日の様子の一端はTogetterのまとめをご覧頂くと伝わるかもしれません。

当初は20分の枠でお話を伺っていたのですが、ここは語っておきたいという内容を詰め込んでいるうちにどんどん分量が膨らんでしまい（実は会場で自己紹介が進行してる間にも何枚か足してました……）、第2セッションの枠が空いていたのをいい事に結局2枠分の時間を使わせて頂きました。時間に余裕が生まれた分、ちょっとゆとりを持って話せたと思うのですが、人前での発表自体が結構久しぶりだったので、大変緊張しました。

発表内容は見ての通り解説漫画の描き方の解説というメタな話ですが、前半部分のプロットやシナリオの話はテキストで解説を書く時や人に何かを紹介する時に共通して言える事のように思いますので、新人教育とかそういう場面で知見を生かして頂けたらなあと思っています（なので、Speaker Deckのスライドのカテゴリも図々しいことにEducationとしています）。

スライドに書いてないことで当日会場で話した事のうち、覚えてる話ではこんな話題があったような気がします。

• 奥さんに手伝って貰っているという話を聞いたことがあるが？→最初の1年かそれくらいは、ペン入れをグレースケールの鉛筆ツールでやっていた関係で塗りつぶしツールを活用できなかったため、トーン（塗り）の下塗り作業を手伝って貰ってました。1年目の終わりくらいからベクター形式のペンツールに切り替えた結果、弊領域の塗りつぶしが楽になったため、作業の指示出しにかかる手間を考慮すると全部自分でやった方が早いかなということで、今は実作業は全部一人でこなしてます。ただ、話の展開に自信が無い時に意見を求めたり、みんとちゃんの衣装の事で判断に迷った時にアドバイスを求めたりという形での支援は今でもして貰ってます。
• 編集者の人にフィードバックを貰って直すというのはないのか？→作業スケジュールが恒常的に崩壊してしまっているせいで、ネームを見せて意見を貰って……というサイクルはとても回せないため、ほとんどそのまま通してもらっています。ただ、話題の選定に自信が持てない時に、プロットの段階で「これでいってもいいか？」という事を聞いてみるという事はたまにあります。
• 作業にかかる時間は？→平日フルタイムで勤務しているので、その後帰ってから家で夜間に作業しているのと、土日祝日にさらに集中して作業をしている、という感じで体感的には2～3週間ガッツリ持ってかれてる感じがあります。ただし、一番時間がかかっているのはプロットからネーム、下描きまでの工程で、気分が乗らないとかいい案が思いつかないとかでダラダラ時間を潰すだけに終わってしまっている部分はあります。
• やり直したい回というのはあるか？→正直、今回発表の中で述べた事のいくつか（特にネーム段階のこと）は連載が進む中でだんだんと意識できるようになってきた事だったので、そこを無自覚にがむしゃらにやってた初期の頃の話は、今だったらもっと丁寧に絵解き解説したのに……と後悔に襲われることが結構あります。逆に、意識して取り組むようになってきた近年の回に関しては、あまりそういう後悔を感じることはなくなっている気がします。
• ツールは何を使ってる？→ComicStudio Proを使ってます。Exではないのでスクリプトでの自動化ができない（当初は夏と冬のコミケに合わせてもえじら組の漫画を描くためにと思って導入したので、プロ向けのエディションなんて必要ないやろ……と思ってたのです）し、更新ももう無いし、 いいかげんCLIP STUDIO PAINTに移行しないといけないとは思ってるんですが、連載の作業に追われて学習のために割く時間も気力も確保できず、移行の目処は立っていません。
• いつくらいから絵を描いてた？→物心付いた時には既に。なので、何かを説明する手段の1つとしていつも「絵で説明」が選択肢に入ってる感じはあるし、言葉だけで説明しないといけない時は「絵で描けば一発なのに……！」ともどかしくなる時が結構あります。

あと、質問を受けたこと以外でこんな事も話したなあという話題。

• 解説を書けるのは自分がコマンド操作に苦手意識があって後から覚えたからで、好きでやってた事や、息をするレベルで身に着いてる事になると逆に説明できないと思う。例えば絵の描き方は、気が付いたら描いていたという感じなので、「ここが勘所」というのを言葉にできない。JavaScriptの事も、ツボを押さえた教え方はできないと思う。そんな感じだから成長はある一定の所で止まってしまっていて、「絵の描き方」や「プログラミングの仕方」みたいな解説で勉強してる人に追い抜かれてヘボい所に留まってる実感がある。
• 頼まれもしないのに先日書評を書こうと思って読み返して、改めて湊川さんのGit本は本当にパッケージとしてよくできてるなと溜息出た。こんな完成度の高い物を世の送り出された湊川さんには嫉妬を禁じ得ない。自分も「再録の時に全体の構成を見直して、補足になるような話を描き足そう」みたいなことを最初は思ってたんだけど、いざその時が来たら描き下ろし1本で完全に力を使い果たしてしまい、構成を見直すとか書き直すとかなんて所までは全然手が回らず、結果、「シス管系女子」の本、特に1冊目は、パッケージとしては非常に収まりの悪い物になってしまったと思ってる。
• キャラ立てを意識してるというのは、解説の指針を定めるペルソナにするという実務的な理由もあるんだけど、それ以外に、「意識高いギーク気質の人だけじゃない、技術第一という訳じゃない、服とかオシャレとかの方が好きという『普通の人』がIT分野で働いてたっていいじゃないか」というメッセージを込めてる部分もある。ずっと以前に案件で訪問した企業の情シス部門の方で、若い女性で私服の方が普通に仕事をこなされていた（※みんとちゃんとは全然タイプは違います）のを見て、「あっ、技術一本のオタク男性じゃない人もこの世界にいるんだ」と強く印象に残ったのが、みんとちゃんというキャラの発想のきっかけになってる。

自分の発表が終わった後は開放感からアルコールを飲んでしまったため、LTの方はほとんど頭に入っていませんでした。ごめんなさい。でもBlackfireというプロファイラ的な事のできるサービスがあるという事と、WAF（Web Application Firewall, アクセスのパターンを識別して攻撃っぽい物を見つけたら遮断する）が有効だという話はうっすら記憶に残っています。

久しぶりにたくさん喋ったので翌日は声がおかしくなっていたのが自分で分かりました。こういう発表の機会が無いと自分が思っていることを整理してまとめる事も無いため、今回はそのいい機会になったと思います。発表の機会を与えて下さった勉強会運営の皆様、会場までお越し下さった皆様、ありがとうございます！

Ubuntu 16.04でduplicityを使おうとしたらPythonのエラーが出る件 - May 22, 2017

Ubuntuのバックアップユーティリティはバックエンドにduplicityというツールを使ってるんだけど、ユーティリティ越しだと大雑把な操作しかできないので、個別にファイルを復元したいみたいな時はduplicityコマンドを直接使う必要がある。それでduplicityを使おうとしたらこんなエラーが出て詰んだ。

$ duplicity --version
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 45, in <module>
    from lockfile import LockFile as FileLock
ImportError: No module named lockfile

エラーメッセージで検索すると英語の情報しか見つからなかったんだけど、どうも、Pythonの複数バージョン使い分けのためにpyenvを入れていると、duplicityがシステムのPythonではなくpyenvのPythonの方を見に行ってしまうのが原因だったようだ。

• Bug #1576514 “After upgrade to Xenial Duplicity crashes “No modu...” : Bugs : duplicity package : Ubuntu
• python - Duplicity install error: ImportError: No module named duplicity - Ask Ubuntu

そういえばGroonga関係のドキュメントを書くのにSphinxを使わないといけなくて、Sphinxが要求するPythonのバージョンがシステムのPythonのバージョンより新しかったからpyenvで乗り切ったような記憶がある。そのせいか。

PythonのことはさっぱりなのでどうやればpyenvとシステムのPythonを共存できるのかやり方を誰か教えて！と社内で聞いたら、デフォルトではシステムにインストールされたバージョンのPythonを使うようにして、特定のディレクトリ配下でだけ必要なバージョンを使うようにすれば良いと教えて貰えた

$ pyenv global system
$ duplicity --version
duplicity 0.7.06

でも同時に、Pythonコミュニティ的にはpyenvを使って欲しくない流れになっているみたいな事も聞いたので、自分の中でのPython触りたくない度合いがまた増してしまった。

Qiitaで許容される内容の不明点 - May 15, 2017

Qiitaのコミュニティガイドラインについての発表で参照されているコミュニティガイドラインが何度読んでも肝心の自分の知りたい点について書かれていなくて不安をぬぐえずにいたんだけど、1週間近く経っても特にフォローアップがなされていないようだったので、Twitterで愚痴ってないでちゃんと直接聞いた方がいいかなと思ってお問い合わせフォームから以下の質問を送ってみました。同様の質問が殺到しているようだったら申し訳ない限りです。

http://help.qiita.com/ja/articles/qiita-community-guideline
こちらのガイドラインにおいてQiitaに投稿する事が認められるのは「プログラミングに関する」記事であると限定されていますが、この範囲をもう少し詳しくご説明いただく事は可能でしょうか？
具体的には、自分は以下のような内容が許容されるのかどうかが気になっております。

• プログラミング行為を伴わない、Ansible等のサーバー構成管理ツールの使い方やノウハウ
• プログラミング行為を伴わない、Linuxサーバー上でのApacheやOpenSSH（sshd）といったサービスの設定のノウハウ
• プログラミング行為を伴わない、MarkdownからPDFへのPandocを用いた変換処理のノウハウ
• 一般にプログラミング言語とは見なされにくい言語、例えばシェルスクリプトの書き方やノウハウ

一般に「プログラミング」は設計・コーディングなどの開発行為までを指し、その成果物の実行や実行に必要な環境の整備、運用行為は、「プログラミング」という語が指し示す範囲には含まれないように思われます。
貴社元エンジニアの方の以下の発言は、上記のような内容もQiita上で許容される事が想定されているように読めますが、貴社の公的アナウンスとしてはそのような情報を見付けられておりませんので、上記疑念を払拭するに至っておりません。
https://twitter.com/mizchi/status/861892695236550656

自分の個人的な認識としては、Qiitaは「プログラムを書くすべての人が技術の悩みを解決するのに寄与する、技術的な話題」全般が共有される場と見えており、そのように考え記事を投稿しておりました。
しかしながら、自分の認識が貴社の想定から大きく外れているようでしたら、結果的には貴社のサービスの質を低下させる行為をしていた事になるのではないかと考えております。
今後ともQiitaの健全な運営に寄与できますよう、お手数をおかけしますが、上記の事について貴社の公式な見解を、本問い合わせへのご回答または公式なアナウンスの形でお知らせいただけましたら幸いです。
（また、本問い合わせへの回答としてご連絡を頂く場合、その内容の全文または要旨を個人のブログで公開しても良いかどうかについてもご回答頂けましたら幸いです。）

5月16日追記。本件、運営サイドから回答を頂けました。

• 少なくとも上記4例と自分の過去の投稿は大丈夫っぽい
• そのうちガイドラインについてフォローアップの公式アナウンスがTwitterとかQiitaブログとかでなされるっぽい

ということで個人的な心配はとりあえず解消されました。後は公式発表を待ちましょう。

5月29日追記。23日付けで公式な発表がありました。自分としては特に付け加えることはない感じですが、「まだスッキリしない」という方は直接問い合わせてみるのがよいのではないかと思います。

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

（後日談：ここで移行した先のWindows 10機が死んだのでさらに新しいPCに移行した話。ここに書いた話の発展編。）

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

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

まんがでわかるLinux シス管系女子 (日経BPパソコンベストムック)

posted with amazlet at 17.04.30

Piro(結城洋志)
日経BP社 (2015-02-18)
売り上げランキング: 22,482

Amazon.co.jpで詳細を見る

本書は端的に言えば、「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冊と言えるでしょう。

まんがでわかるLinux シス管系女子 (日経BPパソコンベストムック)

posted with amazlet at 17.04.30

Piro(結城洋志)
日経BP社 (2015-02-18)
売り上げランキング: 22,482

Amazon.co.jpで詳細を見る

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

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

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

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

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

posted with amazlet at 17.04.28

湊川 あい
シーアンドアール研究所 (2017-04-21)
売り上げランキング: 787

Amazon.co.jpで詳細を見る

「わかばちゃんと学ぶ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への理解が深まると思います。

<script src="https://source.pixiv.net/source/embed.js" data-id="60527082_db5d3e091bb0cd27ade787226c645edc" data-size="medium" data-border="on" charset="utf-8"></script><noscript>

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

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

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

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

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

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

posted with amazlet at 17.04.28

湊川 あい
シーアンドアール研究所 (2017-04-21)
売り上げランキング: 787

Amazon.co.jpで詳細を見る