Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝1。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

宣伝2。Firefox Hacks Rebooted発売中。本書の1/3を使って、再起動不要なアドオンの作り方のテクニックや非同期処理の効率のいい書き方などを解説しています。既刊のFirefox 3 Hacks拡張機能開発チュートリアルと併せてどうぞ。

Firefox Hacks Rebooted ―Mozillaテクノロジ徹底活用テクニック
浅井 智也 池田 譲治 小山田 昌史 五味渕 大賀 下田 洋志 寺田 真 松澤 太郎
オライリージャパン

Page 1/240: 1 2 3 4 5 6 7 8 9 »

技術書典4に参加して「まんがでわかるLinux シス管系女子3」とかグッズとか頒布しました - Apr 23, 2018

去る2018年4月22日、東京・秋葉原UDXにて開催された技術同人誌オンリーイベント技術書典4に、サークル「シス管系女子会」として参加してきました。無駄にパトロン枠での参加でした。

毎度、シス管系女子の草の根的な営業活動とファンサービス、あと〆切を設けることで何か新作を作るモチベーションにするという目的で参加していますが、今回も結果のほどを記しておこうと思います。なお、技術書典、技術書典2の結果、および技術書典3の結果は過去記事をご参照下さい。

数字的なこと

今回の数字は以下の通りでした。一般的な技術同人誌のサークルというよりも、一般書店で購入可能な商業出版物メインの企業参加者の例という感じで見て頂いた方が良いと思います(申し込みは自分が個人的にやっていますが、商業出版物は日経BPの委託販売という形で、売り上げもそっくりそのまま渡しています)。

技術書典2の時に作成した、サンプルを兼ねたチラシ形式のリーフレットも持ち込んではいました。ただ、こちらは前回に引き続き今回も積極的にばらまかなかったので、数としてはほとんど出ていないと思います。

今回特筆すべきは、本の持ち込み分が早々に完売してしまったという事です。特に「シス管系女子3」は、当初持ち込み分60部は11時の開場から12時50分頃までの間に払底してしまい、途中で日経Linux編集部にあったという19部を急遽追加してもらいましたが、14時30分の頒布再開後14時58頃までの間になくなってしまいました。本が無くなって以後も何度か「3を……えっもうないの」的な反応を頂いていて、数だけは多く用意できるはずの商業出版物であるにも関わらず、せっかく来ていただいたのに申し訳ない限りです。一応、Amazon等の通販や書泉ブックタワー等会場近くの書店でも普通に入手できる旨は案内させていただきましたが……

持ち込み部数は前回までの実績を踏まえて検討した結果だったのですが、晴天に恵まれてのべ参加者数が倍増した事と、今回の新刊である「シス管系女子3」が4月19日発売でこれ目当てに来て下さった方が相当数いらっしゃったようだという事から、全く想定外の売れ行きとなりました。新刊が多めに出るのは想定の範囲内でしたが、既刊も前回参加時より多く出ており、全ての本が15時台にはなくなってしまいました。やはり天候の効果は大きかったようです。グッズも、ステッカーは頒布価格が高めだったので10〜20ほど出ればいいくらいかなと思っていたのですが、気がつくと半分程なくなっていました。タイツは……元々あしピタが本命の物なので、まあこちらは想定の範囲内ですね。

スペース設営のこと

今回は商業誌3冊に加えてグッズも並べる必要があったのですが、今までのやり方だと確実に場所が足りなくなるので、どうにか縦方向にディスプレイする方向で工夫してみました。

まず本を縦にディスプレイする方法ですが、既製のイベント展示用の雛壇を調達しました。できれば何度も使える耐久性の高いプラスチックや金属や木の物を調達したかったのですが、ちょうど良さそうな物は品切れだったり、微妙にサイズが合わなかったりしてなかなか良い物が見つからず、最終的に選んだのはIGARASHI PROというメーカーの段ボール製組み立て式雛壇でした。本来はイベント毎に使い捨て前提の製品のようですが、それは勿体ないので、両面テープで固定する部分をマジックテープで置き換えてバラして持って帰れるように改造しました。また、結構奥行きがあってこれを置くと平積みのスペースを確保できないため、一番手前の段を潰すことにしました。

タイツは普通に置くと滑り落ちて危ないので、普通の店舗でワゴンセールになってる物のように縦にしてケース(たまたま家にあった未使用の不織布製収納グッズ。ある程度の柔軟性がある)に詰めて、その後ろに背の高いディスプレイでサンプルを展示する形にしました。高さを出すための物は最初は段ボール工作を考えていたのですが、もえじら組の最初のイベント参加の時に買ったスチレンボードの残りが出土された(10年以上前の物……)ので、それを切り貼りして適当に作りました。

後ろ側は紙製の簡易スタンド(同人誌の見本や値札を立てかけるために使われるような物)ですが、高さがある分倒れやすいので、後ろの方に足を延長してバランスを取ってみました。

POPは、タイツがネタグッズなのでそれに合わせる形でヴィレヴァン風POPの作り方を参考にそれらしい物を作ってみました。手書きでやる自信が無かったので、青地の部分をたぬき油性マジック、それ以外の部分をふい字Pで「手書き風」にしました。ロゴは、フォントの形状がヴィレヴァンのロゴの物に似ているとして紹介されていたHelvetica Ultra Compressedベースで作成しています。

(POPのひとつ。「ステッカー MacBookでなくても貼ってええねんで? 800yen」の表記あり。)

本物のヴィレヴァンPOPには値段は書かれていないようですが、今回は値段も一緒に入れてしまっています。

「完売しました」のお知らせをその場で書いたりするのに、何も書かれていない白紙の状態の物も用意しておけばよかったなあ……と思いましたが、後の祭りでした。

物を作るモチベーション維持のこと

技術書典への参加目的の1つは何か作る事へのモチベーションを高めるという事なのですが、今回はちょうど「シス管系女子3」の作業とタイミングが重なったため、これをモチベーションに作業を進めていました。

まんがでわかるLinux シス管系女子3 (日経BPパソコンベストムック)
Piro(結城 洋志)
日経BP社 (2018-04-19)
売り上げランキング: 1,552

元々は、この1週間後くらいの発売予定で作業スケジュールが組まれていたのですが、そうなると技術書典の直前くらいは作業の大詰めで何も他の事ができそうになく、技術書典合わせの何かコピー本を用意するという事ができない&「シス管系女子3」も間に合わないという最悪の事態になってしまう事が予想されたため、〆切を早めてもらって発売日をイベントの前に変更、イベントにも新刊として持ち込むことができました。冒頭のプロローグの構成をギリギリで変更する事になったり、目立つ所では裏表紙の大野先輩のスカートのテクスチャが抜けた状態になってしまっているなど詰めの甘い箇所が残ってしまったりと、心残りもいくつかありますが、本来の価値である技術の本としては申し分ない物にできたのではないか……と自画自賛しています。

また、〆切が手前にずれた関係でイベント直前に2週間ほどの余裕が生まれ、コピー本は無理でしたがグッズを用意することができました。

なお、グッズ類は現在BOOTHで通販もしています。会場に来られなかった方や、会場で見落とされていた方は、こちらからご注文いただければと思います(あんしんBOOTHパック利用のため、こちらに個人情報が伝わる事はありません)。グッズがなければBOOTHを使ってみる事もなかったので、これも技術書典がきっかけで活動の幅が広がったという事だと言えそうです。今後は、過去に少数だけ生産したブックエンドもラインナップに加えられたらなあと思っています。

会場での反応のこと、新刊への反応のこと、今後のこと

毎度書いている気がしますが、会場では読者の方に何度もお声がけをいただき、大変ありがたかったです。紙媒体の商業出版物でしか読めない連載ということもあってか普段あまり感想を見聞きする機会が無く、こういう場で「1も2も持ってます」「3をずっと待ってました」のようなありがたいお言葉を頂けると、大変励みになります。

また会場外でも、今回の「シス管系女子3」についてはWeb上、というかTwitter上で今までにない量の反応を頂けている印象があります。2年前にWebサイトTwitterアカウントの運用を開始して以降、自分にできる範囲で地道なプロモーションとも言えないようなプロモーションを続けてきましたが、その間湊川さんや沢渡あまねさん、ビタワンさん、ナツヨさん(※今回イラスト内のキャラクターの使用許可を頂いた方々)、他にも数多くのフォロワーの方々に度々告知やアピール文を拡散していただけていて、その影響がこうして目に見える形で表れてきたという事なのではないかと思っています。皆さんのご厚意に感謝するばかりです。

正業の傍らでの短いページ数の連載、しかも掲載媒体の日経Linux誌が月刊から隔月刊になったということで、今まで以上にページ数が溜まるスピードが落ちる事が予想され、次の本が出るとしたら一体どのくらい先になってしまうのか全く見えない状況ではありますが、今のこの気持ちを忘れないで、腐らず歪まず続けていければと思っております。皆さん本当にありがとうございます。(……と感謝の意を激しく表明すると「最終回」っぽさが漂ってしまいますが、別にそんな事はなく実際これから次の回の作業に入らなくてはいけないので、今後とも見守っていただけましたら幸いです。)

余談

どういう訳か、スペースにお越しの方に「マンガで分かるGitのスペースはどこですか」と訊かれてしまいました。それは僕じゃなくて湊川さんなんです……タイトル似てますが別作品です……

tmuxとかの仮想端末で複数の画面間でBashのコマンド履歴を共有すると同じ履歴が何度も記録されてしまう問題を解決する - Mar 04, 2018

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

まんがでわかるLinux シス管系女子の74ページで、仮想端末(本編中ではtmux)の使用時に複数の画面間でコマンド履歴が共有されない問題の解決策として~/.bashrcにこういう記述を追加すると良いという話を書きました。

function share_history {
  # 最後に実行したコマンドを履歴ファイルに追記
  history -a
  # メモリ上のコマンド履歴を消去
  history -c
  # 履歴ファイルからメモリへコマンド履歴を読み込む
  history -r
}
# 上記の一連の処理を、プロンプト表示前に(=何かコマンドを実行することに)実行する
PROMPT_COMMAND='share_history'
# bashのプロセスを終了する時に、メモリ上の履歴を履歴ファイルに追記する、という動作を停止する
# (history -aによって代替されるため)
shopt -u histappend

ところが、これを使用しているとコマンド履歴に同じ項目がどんどん溜まっていくという問題が起こるようになります。自分の場合だと、git commit -pしてからgit pushするとか、その前にgit pullするとかいう操作が多く、コミットの粒度も細かくするようにしているので、コマンド履歴があっという間にこれらのコマンド列で埋まってしまいます。

Ubuntuの場合だと~/.bashrcには最初からHISTCONTROL=ignorebothという記述がありますが、この指定は「直前のコマンド列と同じコマンド列の実行時にはコマンド履歴を残さない」という物です(正確には、これはHISTCONTROL=ignorespace:ignoredupsの省略形で、重複を記録しないという動作はignoredupsの効果です)。似た指定でHISTCONTROL=erasedupsという指定もあり、こちらは直前のコマンド列に限らずコマンド履歴全体の中で重複を排除する物です。しかしどちらを指定しても、上記の設定と組み合わせると期待通りの結果を得られません。何故なのでしょうか。

これは、HISTCONTROLの指定が一体何に対して作用するのかという事を考えると分かります。GNUのbashのバージョン4.4.18のソースコードを見てみると、ignorebotherasedupsはどちらもメモリ上のコマンド履歴に対して、新しい項目を追加する時にメンテナンスを実行するようになっています。しかし、上記の設定を使用している場合、せっかくそのようにメンテナンスしたコマンド履歴はhistory -cで消去されてしまって、その後、重複を含んだままの履歴ファイルからhistory -rで履歴を読み込み直しています。これではignorebotherasedupsも全く効果を得られなくて当たり前です。

ではどうすればよいかという話なのですが、とりあえずの解決策としてはこういう方法があります。

function share_history {
  history -a
  # ここから追記
  tac ~/.bash_history | awk '!a[$0]++' | tac > ~/.bash_history.tmp
  mv ~/.bash_history{.tmp,}
  # ここまで追記
  history -c
  history -r
}
PROMPT_COMMAND='share_history'
shopt -u histappend

tacコマンドというのは、catの逆で最後の行から最初の行に向かってファイルの内容を出力するコマンドです。これを使ってファイルを逆順出力してから、重複行の最初の1行目を残して残りを削除して、それをまた逆順にして出力し直した後、出力結果で~/.bash_historyを置き換えています(1行の中でそのままリダイレクトでファイルを置換しようとすると元ファイルが消えてしまうので要注意!)。その後で、history -cでメモリ上のコマンド履歴を消去してhistory -rで読み込み直すようにするわけです。これにより、同じコマンド列を何度も実行しても最新の1つだけが履歴に残るようになります。やりましたね!

もっとスマートなやり方もあるんだろうとは思いますが(例えば、BashではなくZshを使えば最初からこういう挙動になっているそうです)、自分がパッと思いつく解決策はこういう物でした、ということで主にシス管系女子読者の方向けの3年越しのフォローアップ記事として公開しておきます。

余談:tacの代用

tacはGNU coreutilsのコマンドの一つなのですが、macOSなどのBSD系の環境だとコマンドが存在しません。そのためtail -rで代替する必要があります

WindowsでのFirefoxのビルドに使用するMozillaBuildだと、tactail -rもどちらも使えません。このような環境では、sedでの代替実装を使って以下のようにtacコマンドの代わりの関数を定義しておくとよいでしょう。

function tac {
  exec sed '1!G;h;$!d' ${@+"$@"}
}

技術書典3に参加して「まんがでわかるWindows Subsystem for Linux」をリリースしました - Oct 25, 2017

去る2017年10月22日、東京・秋葉原UDXにて開催された技術同人誌オンリーイベント技術書典3に、企業サークル「シス管系女子会」として参加してきました。

シス管系女子の草の根的な営業活動とファンサービス、あと〆切を設けることで何か新作を作るモチベーションにするという目的での参加でしたが、結果のほどを記しておこうと思います。なお、技術書典、技術書典2の結果は過去記事をご参照下さい

数字的なこと

今回の数字は以下の通りでした。

  • 技術書典3 Webサイト上での被チェック数:79
  • 持ち込み部数:
    • ムック「まんがでわかるLinux シス管系女子」30部(うち1部を立ち読みスペース用に提出)
      • ムック「シス管系女子2」は出版社にすら在庫が無い状態のため、持ち込み部数は0でした。
    • 新刊コピー本 「まんがでわかるWindows Subsystem for Linux シス管系女子」 102部(うち1部を見本誌として提出、1部を立ち読みスペース用に提出、1部をサンプルとしてスペースに常設)
    • シス管系女子BEGINS 0.1+0.2リーフレット版 部数不明(恐らく200くらい?)
  • 頒布実績:
    • ムック「まんがでわかるLinux シス管系女子」26部(1700円×26=44200円)
    • 新刊コピー本 「まんがでわかるWindows Subsystem for Linux シス管系女子」 99部すべて頒布(13時頃に在庫切れ)
    • シス管系女子BEGINS 0.1+0.2リーフレット版 100部ほどを頒布(実数不明)

ポスター等は前回の使い回しなので、今回新たにかかった費用はイベント参加費(企業扱い)と新刊コピー本の費用くらいです。

当日は台風直撃かつ衆議院議員選挙とも重なるという、前回・前々回を上回る悪条件でしたが、主催者発表によると来場者数は2700人ほどだったとのことで、来場者数に対するムックの販売実績としては前回を上回る比率となったと言えます。

前回の技術書典2では積極的に声かけを行い、サンプル代わりのリーフレットをチラシのように積極的にばらまいていましたが、今回はそこまでの積極的な声かけはせず、スペース前で足を止めて下さった方に「よかったらこちら無料なのでどうぞお持ち帰り下さい」と勧める程度に留めました。これは、リーフレットを増産していなかったためばらまいていると足りなくなると思ったのと、技術書典2までに参加した人にまた配ってもウザイだけだろうと思ったのとが理由です。

新刊が間に合うかどうかすら危うかったので事前のアピールをほとんどしておらず、会場内でもほとんどずっと座ったままだったので、数字は前回からかなり後退するのではと考えていたのですが、商業出版物と新刊の頒布数的には全然そんなことありませんでした(コピー本に至っては昼過ぎになくなってしまいました)。 近くにキンコーズがあるので追加で刷ってこようかとも思ったのですが、宣伝活動と考えたときにこれ以上お金をかける意味があるのかよく分からなくなってしまったため、そのまま増産無しで閉会まで居座っておりました。

立ち読みについて

今回、技術書典3というイベント自体の新たな試みとして「立ち読み専用スペース」「戦利品確認用スペース」という物が用意されており(自分は行かずじまい)、サークル参加者は見本誌とは別に本を立ち読み用に提出することでそちらにも置いてもらえるようになっていました。

どれくらい効果があるのか?については未知数の状態でとりあえず提出してみましたが、会場内でスペースまで足を運んで頂いて本をお買い上げ下さった方の中に、「上の立ち読みスペースで読んで気になったので」とおっしゃって下さった方がいらしたので、まったく効果無しということはないようです。

新たに制作したもの

今回のイベント参加に当たり、元々はシス管系女子BEGINSの0.3話として新作を用意しようと思っていたのですが、

  • 直前の10月18日にWindows Subsystem for Linuxが一般向けの機能として解放されたWindows 10 Fall Creators Updateの提供が開始されたニュースを見ていて「あれっそういえばこれLinuxって付いてるから『まんがでわかるWindows Subsystem for Linux シス管系女子』ってタイトルにできるんじゃね? むしろ旬の話題じゃね?」と思った。
  • 連載は枯れた技術の紹介を主にしていて、時事ネタは取り扱わない方針なのだが、これは本編ではない広報資材なので、むしろ時事ネタの方が拡散してもらいやすいのではないかと思った。
  • 技術書典(第1回)の時以降細々と実施していたWebアンケートで、読者の方の過半数が普段使いの環境はWindowsであることが判明していた(今さらかよ!という感じですが、当初の連載のテーマ決めの時に見せてもらった本誌がUbuntuのデスクトップ環境推しだったため「そういうものなのか」と思ってみんとちゃんの環境もUbuntuに設定してしまったのです……)ので、WSLの使い方を紹介すればWindows環境でも本編で解説している内容を役立ててもらえるのではないか、「Windows環境でも役に立つ一通りの知識」というパッケージとして見せられるのではないかと思った。

ということで、突貫作業でWSLの紹介の特別編を制作し、新刊としてリリースしました。 元々、イベントが終わったら公開するつもりだったのですが、昼過ぎの時点で頒布物の在庫が無くなりそうということが見えてきたため、早々に会場内からTwitterにも投稿しました。

コピー本として頒布したバージョンと最初に公開したバージョンでは、最後のページでWSLのことを「準仮想化」と表現していたのですが、Twitter上でご指摘を受け、冷静に考えると間に挟まるレイヤーが薄いという点では準仮想化に似ているけれども仮想マシンがいるわけではないのだから「仮想化」と言うのは間違いだったと思い至り、帰宅後に最終ページの内容を大幅に更新してTwitterに再投稿しました。 結果として、前半4ページ分と後半4ページ分のそれぞれのツイートのうち後半の方が多くRTされるというヘンテコな状況が発生してしまいましたが、それだけWSLと他の競合技術との違い・使い分けに皆さん関心があるということなのでしょう。

また、まったくの副作用として、この話を描くにあたって色々調べ直したことで自分自身のWSLへの理解が深まりました。一応Cygwin・MinGW(とMSYS/MSYS2)・PowerShell・仮想マシンとの違いは何となく分かっていたつもりではあったのですが、漫画にするにあたって「どういう絵にすればより適切な表現になるのか?」を考えたことで、今までよりもそれぞれの違いをより具体的に言い表せるようになったと思っています。技術発表や紹介記事はそれを読むだけよりも自分で書く方が勉強になる、ということを改めて実感しました。

イベント外への広がりのほどは?

例によってTogetterの当日のまとめ等も見てみたのですが、戦利品報告として写真を公開されている方の戦利品ラインナップを見ると「ものすごいディープな内容・商業誌では扱われていないような内容の技術同人誌」が主で、今回のコピー本が写り込んでいる物はほとんどありませんでした。シス管系女子のような「解説対象が枯れた技術で、且つ、ものすごく技術的に高度な事をやっているわけではない、初級者向け(中級者以上へのステップアップ用)の内容」というのは、やはり、技術書典というイベントに台風の中わざわざ足を運んで戦利品報告までするようなアグレッシブな方にとっては魅力的ではないということなのだと思います。

宣伝活動としては、直接会場でリーチできる層以外に、その外側・イベント外にも拡散されるような場を選ぶのが効率的なのですが、「シス管系女子」というコンテンツにとってのそういう場所は一体どこにあるのか、そもそも「ある」のかどうか、むしろ拡散されるに足るコンテンツとしての価値は本当にあるのか、まだ答えは見つかっていない感じです。

おわりに

以上の通り、商業出版物の広報活動としては今回もあまりパッとしない結果に終わってしまいましたが、上記のような悪条件下にも関わらず多くの方が来場して下さり、また、シス管系女子会のスペースまでお越し下さり、暖かい声援の言葉をおかけ頂けました。普段Webではあまり感想・反応を見かけないため、このように直接「ちゃんと読まれている」ということを実感できる機会は自分にとって非常に大きな意義があり、他の何にも代えられない喜びです。お声がけ頂いた皆様、本当にありがとうございます。

今回、事前の準備を疎かにしていたため頒布物は無料のコピー本だけだったのですが、次回以降の参加に際してはファンサービス的な面にもっと注力し、グッズ類の制作にも手を広げていきたいと思っております。

ということで、技術書典3のご報告でした。

技術書典4の結果はこちらからどうぞ。

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, アクセスのパターンを識別して攻撃っぽい物を見つけたら遮断する)が有効だという話はうっすら記憶に残っています。

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

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

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


まんがでわかるLinux シス管系女子 (日経BPパソコンベストムック)
Piro(結城洋志)
日経BP社 (2015-02-18)
売り上げランキング: 22,482

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

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

技術解説するマンガ

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

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

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

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

解説の内容・質はどうか

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

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

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

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

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

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

残念な所

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

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

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

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

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

まとめ

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

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

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

まんがでわかるLinux シス管系女子 (日経BPパソコンベストムック)
Piro(結城洋志)
日経BP社 (2015-02-18)
売り上げランキング: 22,482

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

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

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

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

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

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

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

ペイしたのかどうか

技術書典とコミティアは商業誌の販売が可能とのことだったので、シス管系女子12を持っていった他、技術書典と技術書典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ではリーフレットを無料配布しました。 (技術書典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のご報告

テキストファイルの中に書いた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ファイルとして用意するのですが、「大部分は共通だけれども一部分だけが異なる」という設定ファイルを複数種類用意する必要が生じたのでした。共通部分を括り出すのでなく、ソースファイルに書かれたプレースホルダの位置に、環境ごとの別のソースファイルの内容を埋め込んで各環境ごとの静的なファイルをビルドしたい、という感じです)が出てたので、これを機にもっとマシなやり方を探してみました。すると、sedrコマンドというまさにこういう事をやるためにあるような機能の情報が見つかりました。

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

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

sedrコマンドは、「カーソル行の直後(次の行の直前)に別のファイルの内容を読み込んで挿入する」という物です。パターンマッチと組み合わせれば、「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つ残っています。sedrは「マッチしたまさにその箇所」ではなく「マッチした箇所が含まれる行とその次の行の間」にファイルの内容を出力するため、行の中程に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で改行を出力するをご覧下さい。

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

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

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

解決策としては、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)-->
...

grepegrepgrep -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倍の高速化となりました。ラズパイでも、カジュアルに全ファイルを処理させても気にならない程度まで高速になっています。万歳!

sedawkだけでも頑張ればこういう事ができるのかもしれません。でも、ごく基本的な機能だけしか知らなくても「コマンドの実行結果でコマンド列を作る」という一工夫によってできる事の幅はかなり広がると思います。実際、この記事に「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で頑張ろうと思います……

自分の作品のグッズを作りたいだけの人生だった - Feb 13, 2017

昨年、このツイートを見たんですよ。

それで「うらやましすぎる!!!」とテンション爆上がりになってしまった勢いで妄想グッズの絵を描いてしまったりなんかしまして。

いやね、元々シス管系女子も何かグッズ作りたいなあとは思ってたんですよ。でも、ステッカーとかマグカップとかの比較的すぐ作れそうな物で読者の方に喜んで頂けるイメージがわかなくて。

思えば、以前Mozilla JapanのFirefoxマーケティング活動のお手伝いをしてた頃にストラップや紙袋やフォクすけぬいぐるみのデザインをやらせてもらった時も、やれ「印刷のペラいのじゃなくてちゃんとしたラバーストラップの方が絶対満足感ありますって!!」だの「紐の色と紙袋本体のコントラストが大事なんですよ!!」だの「もっと鼻の所がツンと出てた方がカワイイですって!!」だのと好き勝手駄目出しして、自分が素直に欲しいと思える物を他人のお金で作ってもらうというヤクザなことをしていたのでした(ぬいぐるみは根来さんの駄目出しもすごかったけど)。

でも、Firefoxならロゴマークがかっこいいからそれだけで満足感あるけど、自作の美(少)女イラストとなると、まず美(少)女という時点で照れの方が勝ってしまうし、そもそも自分の絵自体がそんなに上手なわけじゃないし……と色々考えてしまって、何作っても素直に自分で使える気がしなかったのです。

そんな折に見かけたのが冒頭の写真。見た瞬間に「これだ!!!っていうか自分が欲しいわ!!!!」と思いましたね。

だってシス管系女子って一応技術の本で学習(解説)マンガですやん。「これ使って本棚が技術書で埋まるくらいにいっぱい勉強しましょう!」っていうの、シャレが効いててよくないすか? 作品コンセプトにめっちゃマッチしてません? いや「今どき紙の本かよ」って呆れられそうですけども……

あと、仕様上どうしたって単色にならざるを得なくて、でもそれが却ってポップでかっこよくね?とも思いましたし。自分の絵ってそんな上手な方じゃないから丁寧に描いたり塗ったりすればするほどアラが目立って死にたい気持ちが増してくるけど、デザイン的に処理すれば見る側の脳内で勝手に補って見てもらえて実物以上に良く見えそうだし。

そう思ったらもう止まらなくて、妄想絵だけじゃ満足できず、実現できないものかと水面下でなんやかや動いていたのです。日経BPからは予算が出ない自主制作で、完全に趣味の世界です。

そしてついに実現された試作品がこちら!!! (試作1号) まさにイラストの通りの仕上がり!!!! 素晴らしい!!!!

ですがひとつ難点が。

(青色の表紙の本を重ねた様子) 後ろの本の表紙の色で顔色が変わっちゃうんです……

単色の場合はまだマシで、絵が入ってきちゃうと (シス管系女子の本を重ねた様子) もうワケが分からないことに…… これは正直盲点でした。デザイン画の時点で表紙画像と合わせたりすれば一発で分かる事だったのに、それを怠ったばかりに、試作品で実物を見るまでこの問題に全く気付いてなかったという。

なので泣く泣く一からやり直しました。 (試作2号) 明暗反転版です。 といっても、単純に図案の明暗を反転するだけだとパーツが宙に浮いてしまう箇所が結構ありました。そこで、妄想イラストの単純化された図案から「元絵」にあたる線画を起こして、そこから改めて各所の線を拾い上げる形で図案化するという事をした結果がこれです。

これなら、多少うるさい内容の表紙と合わせても顔がちゃんと判別できます(真っ白の紙でも、本の表紙に対してブックエンド自体の影が落ちるので)。 (試作2号をシス管系女子の本と重ねた様子)

しかも、タイツの部分を抜いたので、本の表紙の色や柄がそのままみんとちゃんのタイツの色や柄になります。つまりタイツの履き替え遊びができます。試しに手元の本をいくつか合わせてみました。 (Webの創世) 濃い色はもちろん合いますし…… (わかばちゃん本) 文字が入っててもへっちゃら。 (シェルプログラミング実用テクニック) 帯部分だけ色が違うのも良いですね。 (Firefox Hacks Rebooted) オライリー柄とか。 (ヒューメイン・インタフェース) 英字柄とか。 (徳丸本) 淡い色もいいですね。

試作2号で勝利が見えたので、これをベースに微修正した物を最小ロットで量産して、シス管系女子Advent Calendar 2016にご参加頂いた皆様にお礼として贈答した残りを4月9日の技術書典2に持っていこうと思ってます。利益をほとんど載せない状態でも数千円にはなってしまいます(少数生産だとどうしても割高になってしまう……かといって個人で何百個もこんなかさばる物を発注しても手に負えませんし)が、もし良かったら手に取ってみて頂ければと思います。

以下、デザインするときに分かったこととかコツとかをメモしておきます。

基本的には切り絵の要領なんですが、切り絵の中でも全パーツが繋がってるタイプの形になってないといけないというのがポイントです。

試作1号の図案の時は顔の肌部分を抜いて輪郭を残すデザインにしようとしたのですが、そうすると普通に絵を描くと鼻と口がどうしても輪郭に繋がらないパーツになってしまいます。なので、顔の角度やポーズを工夫してそれらのパーツに髪や目や膝が接するようにすることで、どうにか浮かない形でパーツを残すことができました。

明暗反転版では鼻や口のように短い線は逆に穴を開けるだけなので簡単だったのですが、顔全体を残して輪郭を穴にする場合、輪郭を全部繋げないでちょっとだけ橋渡しする部分を残してやらないといけません。あまり橋をかけすぎると見た目が悪いと思って、目立たない所(普通に線画を描く時に輪郭を途切れさせるような所)に絞って橋をかけてみました。ただ、試作2号では数を絞りすぎて頭の曲線部分が完全に枠から切り離されてしまい、枠が歪むと頭の方が飛び出てしまうようだったので、強度を増すために量産版では頭と枠の間に2箇所橋を増やそうと思ってます。

ということで、ご報告という体裁でのただの見せびらかし記事でした。

雑に描くイラスト100枚チャレンジの振り返り - Dec 25, 2016

2016年4月2日でに始めて、途中からペースダウンしつつも同年12月25日に100枚を達成したので、これを一区切りとして振り返ってみます。

なぜ始めたの?

背景事情の要点を整理すると、

  • シス管系女子はWebにおいてのオフィシャルな広報が出版社サイドからほとんどなされておらず、日経Linux既存読者層以外にほとんどリーチできていない。このままでは本誌ともどもジリ貧。
  • コンテンツ先見せがデフォのWebでは、勿体ぶり型モデルでは埋没してしまう。既にブランド価値を築けているプレイヤーならそれでも成り立つが、ブランド価値が無い・これから築いていくしかないプレイヤーが同じ事をしても話にならない。
  • かといって既存の絵や原稿を大々的に公開すると日経BPに怒られる。出せるコンテンツの絶対数が足りない。無い物はフォロワーの方々にも拡散してもらいようがない。
  • 他のプレイヤーは既にコンテンツを出していて、拡散を担う受け手もそれを材料に共有する事でもう手が塞がっている。自分でコンテンツを作ってくれるほどの熱量の高いファンにだけ期待して、自分で何も出さないのでは、土俵にすら上がれない。
  • 出せるコンテンツが無いなら作るしかない。自分で手を動かさない無名の人に、人はついて来ない。

そんな感じで、現状分析も甘ければ効果測定の方法も定義できないまま、とにかく数を増やさねばという焦燥感にのみ駆られて始めたのでした。

失敗だった点

広報的な成果は、期待したほどには無かったように思います。

タイムラインによく艦これ等のラフなイラストが流れてきていたので勘違いしてしまっていましたが、あれは作品のファン同士のコミュニケーション、あるいは神絵師とそのフォロワーの方々のコミュニケーションという文脈のものであって、すでにある巨大なコミュニティからこぼれ落ちる雫のようなものなのですよね。焦りと「これくらいならやれるかも」という妥協とで完全に見誤ってしまっていました。

それに、シス管系女子というコンテンツの最も大事な価値は解説する事にこそあるわけで、日常の一コマを切り取ってもプレビューになりません。宣伝としてやるなら1枚絵ではなく、本編同様の解説絵にするべきだったのだと今となっては思います。1枚絵で喜んで頂けるのは既存のファンの方だけですし、落描きレベルの雑なイラストではそれすらも……

得られた物

自分の中で絵を描く事の心理的ハードルが下がったのは、収穫と言えると思います。学生時代にはノートの隅に落描きをしていましたが、社会人になってからはその機会がなくなり、なにか特別な理由がないと絵を描かないようになってしまっていました。1日に1時間だけでも無理やりにでも絵を描く時間を設けたことで、季節のイラストもそれほど気負わず描くことができました。

副次的な効果として、絵描きの方との交流のきっかけになったのも良かったです。絵を描く事のハードルが下がったことで、他の人へのお祝いイラストや、オリジナルキャラの絵等を描きやすくなりました。億劫がっていたら、気に入った絵の描き手の方にご挨拶すらできないままだったでしょう。

また、なるべく手をかけずに見栄えのする絵を描くノウハウが多少は身に付いたとも思っています。例えば、自分の場合はペン入れ工程が最も時間を食うため、それをスキップするやり方を取るようになりました。また、背景や小物などについて、今まではいつも律儀に線画を仕上げてから塗っていたのを、いきなり塗りから始めるというやり方を取れるようになりました。夏に描いたヒマワリや七夕の笹、仙台七夕の飾り等は、このやり方でなければもっと時間がかかっていたでしょう。

まとめ

総評としては、よく頑張ったけどピントがずれてたね、というあたりでしょうか。

来年以降は、無理の無い範囲までペースを落としつつも、当初の目的である広報に繋がるように、解説を主にしたイラストの割合を増やしていきたいです。

2016年のアドベントカレンダーのふり返り - Dec 25, 2016

今までアドベントカレンダーには熱心に参加した事はなかったと思うのですが、今年はシス管系女子の草の根広報活動の一環として、自分でもびっくりするくらい力を注いでおりました。

シス管系女子アドベントカレンダー

まず、自分で初めてシス管系女子 Advent Calendar 2016というアドベントカレンダーを立てました。IT系のクリスマスといえばアドベントカレンダーが定番という印象があったので、思いつきでのチャレンジです。

とはいえ、現状のWebでの認知度を鑑みるに読者の方のご協力だけで全日程はまず埋まらないだろうと見込んでいたため、全25コマの構成で事前にマンガを用意しておき、最悪の場合でも1日1コマ公開していけば日程は埋められるという準備を整えた上でスタートしました。Webでの試し読み代わりに自由に使える話を増やしたいという動機が元々あったので、「描くつもりだった話を描ければそれでまず成功。アドベントカレンダー関係のブームに乗っかって露出が増えれば一石二鳥。読者の方のご協力を得られれば一石三鳥」というつもりでした。

蓋を開けてみると、およそ3割の日程を読者の方に寄稿して頂けており、予想以上の結果に大変嬉しい思いをしております。自分なんかの思いつきに乗っかってくれた方がこんなにいた事、エールを頂けた事がとても励みになりました。本当にありがとうございます。

一方で、課題も色々あったと思っています。

  • コラボ対象としてのシス管系女子のコンテンツ力不足。例えば湊川さんに寄稿頂いた記事は、大変な労作なのにも関わらず、ブクマ数は1桁台に留まってしまいました。ご恩に見合うメリットを提供できていないというのは心苦しい所です。
  • アドベントカレンダーは大人数が参加するからこそ盛り上がるという事。世間には最初から最後まで一人だけで完遂しているITアドベントカレンダーもありますが、テーマ自体が魅力的であるとか話題性があるとかでも無い限り、ネットの片隅でひっそり始まってひっそり終わるだけになってしまいます。
  • ファン向けコンテンツとして見た時の魅力の見えにくさ。ConoHaアドベントカレンダーでは参加者にカレンダーをプレゼントという事がアナウンスされていましたが、シス管系女子アドベントカレンダーでは具体的にどんなプレゼントがあるという事をアナウンスできていませんでした(現時点でも。これはグッズがまだ準備できていないせい)。また、こちらで投稿していく内容が本編でスキップした初歩的な部分についての物であったことから、多くの既存読者の方にとっては「知っている事」に過ぎず、連載を追う楽しみを感じられにくかったのではないかと思います。

以上を総合すると、今回誰が一番得をしたかというと自分自身だった(自由に使える特別編を1つ増やす契機になった、読者の方々からのエールを頂けて元気が出た)という気がします。つまり俺得。自己満足に付き合わせるだけになってしまってすみませんでした……こんな風に人の厚意を食んで自分のやる気に変えるような事ばかりしてたら信頼を損なうばかりですよね。ほんとに。

他のアドベントカレンダーへの参加

元々、自分から見つけてきてくれる人だけを対象にしていても認知は広がらないので、どこか「外」に出ていく必要があるという事は認識していました。

そんな折、Geek Women Japan 2016の懇親会で、「シス管系女子」を読まれた方から本編で扱っていなかった話についての質問を頂きました。それに対する回答を記事化して公開するにあたり、ちょうどそのタイミングで各アドベントカレンダーの参加募集が始まっていたため、「外」のアドベントカレンダーに参加すればその読者層に認知を広げる機会になるのでは?と思い至りました。ただ、無差別に参加して宣伝をばらまくだけではただのspam行為なので、

  • 記事の内容はそれぞれきちんとそのカレンダーの趣旨に則ったものになるように務め、その記事単体でちゃんと情報として価値がある物になるようにする。これはspam行為にならないようにという消極的理由よりも、積極的に良いコンテンツにする事で信頼の種を蒔きたいという理由が大きい。
  • その上で、「その記事でやっているような事を自分でやれるようになりたい人向けのコンテンツ」としてシス管系女子を紹介する。
  • そのために、参加するアドベントカレンダーは「シス管系女子」の内容や周辺事情と親和性が高そうな物を選ぶ。

といったあたりの事を考えながらエントリーを増やしていった結果、以下の8記事ができました。

結論としては、この試みは一定の成功を見たと思っています。特にShellscript Advent Calendarに投稿した記事がどういうわけか若干バズってくれて、ここからの流入が突出して多かったです。この記事は日を開けて何度か紹介されていて、その度にアクセスが発生するという状況になっていました。

ただ、このアクセス増は狙って起こせたものではなく(記事のタイトルを付ける際に若干挑発的なタイトルを意識したのは事実ですが……)、それ以外の記事のPVはそれほど伸びなかった事、また増加したアクセスも継続的なものではなくあくまでスパイク状の一過性の増加に留まった事から、やるならもっと継続的にやった方が良さそうという事は思っています。そうする事で、「シス管系女子」の内容や技術レベルに対する懐疑的な見方を払拭する材料を増やせれば、という思いもあります。

自分のサイト内でコンテンツを公開するよりも、技術情報であればQiitaのように、多くの人が見ていて且つ情報をシェアしやすい場所で公開するようにした方が良いという事も実感しました。

Groonga

会社の業務の一環で、Groonga Advent Calendar 2016にもGroonga名義でいくつか記事を投稿しました。

これらはGroongaの知名度向上や盛り上がり感の演出、既存ユーザ・新規ユーザ向けの情報の整備を目的に行いましたが、シス管系女子の場合と同様、これ自体が知名度向上に役立ったという事は言えなさそうです。

まとめ

以上をまとめると、認知度向上のための手段としてアドベントカレンダーを使う時は、既に人が多く集まっている場所(サイトもそうだし、アドベントカレンダーもそう)に飛び込んでいくのが有効なようです。 という、当たり前といえば実に当たり前の話なのでした。

Page 1/240: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき

オススメ

Mozilla Firefox ブラウザ無料ダウンロード