アドベントカレンダーっておいしいの？って聞かれたので全力で答える！
アドベントカレンダー誘われちゃったあなたに
11月に入ると方々で「アドベントカレンダー」参加者募集の声が掛かり始めますよね。それでも初めてだと「アドベントカレンダーってなに？ それ？ おいしいの？」ってなるじゃないですか。
これは、なんだか知らないけど「アドベントカレンダー」に参加しない？って誘われちゃった人のための文章です。
アドベントカレンダーとは
12月1日からクリスマス（24日）までをカウントダウンするカレンダーです。1日1日が小さなボックスになっていて、開けると小さいおもちゃやお菓子などが入っているのです。アドベントカレンダーで画像検索をすると、たくさん出てくるので、見たことはあるはず。
この方式にちなんで、12月1日から25日まで、日替わりであるテーマに基づいてみんなで1日ずつ文章を書いていくのも、アドベントカレンダーと呼んでいます。
どうやるの？
いろんな方法がありますが、はじめは図のように、1日めにブログ記事を書いた人が、2日めは◎◎さんです……と次の人のブログにリンクを貼ったりする方法があります。リンクで1日めから25日めがつながっています。
誰が何日に何を書くかは、エクセルなどに書いておいたりします。
もっとスマートに
で、これをもっとスマートにするのが、AdventarなどのWebサービス。管理の方法はサービスごとに違っているので、ここではAdventarを例に。
Adventarは何をしてくれるかっていうと、さっきの図の「誰が何日に何を書くか」っていうのを管理してくれます。同時に書けたらそのページへのURLを入れることができるので、リンクの一覧表にもなります。
図にすると、こんな感じです。
これだと、Adventarのカレンダーを見ると、1日めから25日めまでもれなく順番にブログを読んでいくことができます。
ミニQ&A
Adventarを使って書く場合に受けた質問と回答を書いておきます〜。
- 私は12月のこの日にWSDを思って日記を書くわと宣言して、当日、約束通り日記を書いてURLを貼り付けるという認識であってますか？
あってます！ その通りです！
- これって公開範囲は世界中？それともメンバー間だけ？
Adventarは普通のサイト、ブログも普通のWebページなので、公開範囲は「世界中」です。検索サイトでも検索できます（検索する人がいれば）。
- facebookのノートとかも、自分の書く日記として使えます？
使えます。ノートは公開範囲というのものがあります。これを「全体」（地球のマーク）にしておかないと、Facebookの友達や、登録がある人しか読めなくなってしまうので、ご注意を！
まとめ
アドベントカレンダーは書籍などの出版物ではないので（出版社の企画もあるかもしれないけれど）、どちらかというとテーマもざっくりしたキーワードのものが多いです（中には特定の職業とか、団体に属していることなどが参加資格になっていることもあります）。
文章だけではなく、写真やイラストのアドベントカレンダーもあります。例えば、冬らしい写真とか、寿司とか。寿司はその日に寿司を食べて、その写真をアップするようです。
つまり、参加している人がそのカレンダーを埋めていくことをお祭りのように楽しむ……というのが大きな趣旨だと思います。そして、たまたまそのテーマに興味のあった人や、偶然、検索サイトで見つけちゃった人が読んで楽しむ。
そのような軽いノリなので、Adventarで興味のあるテーマで、参加資格があれば、気軽に参加してみることをおすすめしますよ〜。
Google Drive内でできたIconrをgitから排除する
Iconrってなに？
Google Driveで作ったフォルダ内にはIconrという不思議な不可視ファイルができます。
gitでは邪魔なので無視を試みる
私はSourceTreeというGUIツールでgitを使っているので、この余計なファイルを.gitignore_globalファイルに登録したかったので、まだコミットしていなかったIconrを選択し、コンテキストメニューから[無視]を選んでみました。
名前に一致するファイルを無視、無視エントリの追加先は「グローバル無視リスト」にします。すると、.gitignore_globalには次のような文字列（一部は改行文字）が入ります。
Icon^M^M Iconr
でもなぜか、Iconrファイルは無視されません。
もうIconrは削除
というわけで、削除をすることにしました。該当ディレクトリで、まずfind . -name "Icon?"とタイプして、目的のゴミファイルが捕捉できるか確認。問題ないようであれば、find . -name "Icon?" | xargs rmとターミナルからタイプすると、消えてくれます。再びfind . -name "Icon?"とやれば、消えたかどうか、確認できます（エンジニアから教えてもろたー）。
これは該当ディレクトリでやらないと、危険です。ご注意を。
また私のケースでは、Google Driveで保管していたフォルダをコピーして、gitのリポジトリフォルダにペーストして行った作業なので、Google Driveの中で、展開するとどういうことになるのか試してません。試す気力もない。
しかしこのクソファイル……
Google Drive App on Mac OSX makes Icon? file.
キレぎみになっている人、多数。
「編集者買い」のススメ
ふと、夜の3時に書き始めてみる
はーい、編集です！（たぶん、ここらへん翌日読み返していきなり嫌になるはず）
今、仕事をひと段落つけて、眠い目をこすりこすりお風呂に入ってきたところなんですけど、以前、CodeGridという技術情報を配信するサービスで、記事を執筆するエンジニア各人のおすすめ技術本をまとめたことがありました。いわゆるひとつのブックガイドです。
私はエンジニアではないので、作文技術を伸ばすための「よき本」を紹介しつつ、ちらりと「よき本」を見分けるポイントも添えました。そのとき書いたのは、どれだけ重版しているか？っていうことでした。
書籍には（たぶん電子書籍でも一部の書籍には）、「奥付」なるものがありまして、いろんな情報が載っております。試しに手元（というか足元）にあった、『JavaScript 第6版』の奥付をみますと、次のような項目があります。
- 書名（あたりまえですな） - 発行日 - 版数と刷数（大きな改訂が入ると版数がi++、改訂が入らず本が売れて新たに刷ったときは刷がi++） - 著者名 - 訳者名 - 印刷所名 - 発行所 - 発売元 - 編集者名（参照した書籍にはなかったが、この項目が入ることもある）
その記事を書いたときは特に「刷数」に注目するとおもしろいよ！なんてことを書きました。本の在庫がなくなって、さらに印刷をしたってことは、それだけ多くの人が読んだ証拠でもありますし、また、編集者（あるいは販売担当者）が「売れるから、また印刷しーよせ」と思った証拠でもあります。
残念ながら売り切れても、その売り切れ方がヒッジョーにスローだった場合、「重版なす」っていう判断もありえます。がっくり。
あと、ポピュラーなのは、もちろん「著者名買い（翻訳の場合は訳者）」ですね。特に最近は人材不足なのか、印税が安すぎて本業やった方が100GB倍マシと思われているせいか知りませんが、ヒッジョーに少数の著者に執筆依頼が集中する傾向もあるみたいです。特に、Web系。フロントエンド系。まあ、この人の書いたものなら間違いはない、と思える著者の存在はありがたいものです。
それから、技術書の場合は「出版社買い」というもありますね。オライリーなどがその例。
んで、今回です。ズバリ「編集者買い」です。ああ、まあ、編集者の90％くらいは、わりとジミーに活動しております。奥ゆかしく奥付に名前が載るくらい。あとは、著者が（心の中では、こいつめ！と思っていても）、◯◯さんに感謝するみたいなことを書いてくださる場合もあります。ありがたし。
完全に私の推測なのですが、編集者は「こ、これはよき本？」って思ったときには、必ず、編集者名を探します。誰のお仕事なんだろう？って。
ちょっとイレギュラーなところでいくと、インタビュー記事などは「文・構成」ってところをチェックします。インタビュー記事は誰かの話を聞き書きしたものなので、「誰か」に当たる人が「主人公」なわけです。けれど、その人が直接書いたわけじゃなくで、その話をテーマを設定しつつ「ふんふん」と聞き、読んでおもしろいように組み立て直す人がいます。これが「文・構成」にクレジットされる人の役割。ライターのお仕事ではありますが、多分に編集的な要素も入ってきます（編集的な要素が皆無なライティングってないですけど、笑）。
あ、余談ですが、『「文・構成」は読者にとってはどうでもいい情報』って発言を聞いて、ちょっとカルチャーショックを受けたことがあります。それって、編集者だけのマニアックな行動だったのかもしれません。
な、の、で。あえて、マニアな視点（いや実はそうでもないけど）を取り入れて、「編集者買い」をおすすめしてみたりします。
編集者のところにクレジットされていても、実質編集作業はしていなくて、著者とのやりとりを担当しているだけ、みたいな場合もあります。が、編集サイドの重要なお仕事としては、著者に「ごきげん元気」なムテ吉ライクな執筆をしてもらうことにあります。実質作業を1mmもしていなくても、「ごきげん元気」に貢献しているのなら、それは編集者の立派な仕事です。
だいたいね、いい著者って、編集者に付いていることが多いです。「この編集さんとしか、仕事しないもんね」と密かに決めていらっしゃる著者もいます。というのも、そこへなんとか「うちでも書いてもらおう！」って思って、玉砕する編集者の姿を何度か見ているのです。馬に蹴られて死にそうになり、息も絶え絶えな編集者。嗚呼。
えーと、なんの話でしたっけ、ああ、そうだ。「編集者買い」。なんとなく手持ちの本をぺらぺらやって、共通の編集者名が洗い出せたら、心に留めておくとよいと思います。
でも……。この情報、Amazonには多分出てないし、自費出版系の電子書籍には、そもそも編集者がいなかったりするので、めっちゃ「本屋」でがんばる感じになってしまうのですが。まあ、たまには本屋もいいじゃないですか。たぶん。
我が家の植物
我が家の植物自慢 Advent Calendar 2013の15日目です。
ブラウンハンドとはなにか？
「グリーンハンド」ってご存知ですか？
その人が触って育てると、捨てる直前のような植物も、生き生きと元気を取り戻すというところから、「グリーンハンド」と呼ばれるそうです。なんか愛に溢れてそうでいいですよね。憧れる。
で、私はというと、その正反対の「ブラウンハンド」。特に世話を怠けているつもりはないけど、ガンガン枯れます。
この前、その理由のひとつがわかったんですけど、真夏の窓際に置いた植物に、思いっきり朝にお水をあげていたからのようです。つまり、水をあげているつもりで、お湯をあげていたと。義父に植物を煮てしまっている、と大笑いされましたorx。
私の家の植物
現存しているのは、これだけ。
ひとつはほぼ日ブックスを買ったときに、「ぽてんしゃるな植物」として特典についてきたチランジア・ウスネオイデスという植物です。
たまに水さえやれは育ちますし、土も植木鉢も要らないですから、
と言われているわりには、日に日に茶色くなっていき、そして今も、たぶんほぼだめなんだろうなあ、という状態に。お水も適当に上げたし、日なたにもおいて、よく日光にも当てたと思うんだけど……。
佐野元春風にいうと「何がいけないのか、教えてほしいのさ」という感じです。
「あんた、これ枯らしたらおしまいだね」
実家の母が遊びにきたときに言われた言葉。もうひとつのまだがんばっている植物は、青山フラワーセンターで買ったやつ。名前は忘れてしまったけど、なかなかいい感じで育っています。たぶんアイビー系のなにか。
今はこれにかけています。
ここまで育てるのが下手ならいい加減、あきらめた方が植物のためっていう気もしないではないですが、やっぱりお部屋の中に緑があるのは、元気になるような気がするし、やっぱり諦めきれない魅力があります。
とりあえず、これ、枯らさないように頑張ります。帰省している間がちょっと心配だけど。
クリスマス限定「獺祭 発泡にごり酒 純米大吟醸 二割三分」ブラボー
ああ、仕事に関することを書くブログっていう触れ込みだったのですが、juegmに持ってたブログのエディタ画面があまりにもあまりだったので、こちらに書きます。
仕事関係ないです、たぶん。
日本酒 Advent Calendar 2013の8日目です。
すごいタイミングなんですけど……。
え？ 知ってた？ 8日に日本酒アドベントカレンダーに参加するの知ってた？ というタイミングで夫宛に、義理の弟から、クリスマス限定の獺祭発泡にごり酒が届きました。
獺祭といえば、日本酒好きならほぼみんな知っているという山口のお酒です。蔵元は旭酒造です。
夫は山口出身。秋に家族で帰省するときに必ずお土産に買ってきます。最近は山口宇部空港でも、購入できるようになりましたが、在庫がまちまちで、ほぼない（笑）っていうときもあります。市内の蔵元と契約している酒屋さんで買うのがいちばん安定しているかも。
東京でも「獺祭」の幟を出した酒屋さん、たびたび見かけるようになりましたね。スクエアガーデンにDassai Barもあるようですし。
まあチャラいクリスマスバージョンだよね
で、今回いただいたのは 発泡にごり酒 純米大吟醸 磨きが二割三分。ものすごい詳しいウンチクはこちらのリンクをば。
パッケージはこんな感じ。
ね、ちょっとクリスマスっぽいですよね。
からのごめんなさいごめんなさいごめんなさい
まあ、パッケージ変えるっていうのはよくあるけど、獺祭もやるのねーと思いつつ、瓶の写真を取ろうとパッケージに手をかけると！
なんと！ なんとそこには、こんな封が！
12月23日から2週間が飲み頃に調整されているんですよ。ちょっと、これには感動した。ただのチャラいクリスマスパッケージだと思っていて、すみません。ごめんなさい。
あと栓を開けるとき気をつけよう！
そしてもうひとつ。こんなアメコミチックなペラの漫画チラシが。
これ、要は取り扱い説明書なんです。シャンパンよりも発泡性が高いので、ちゃんと冷やしてから、そっと栓を開けないと、泡と散るわけです。飲む分ない！的に。
そしてこの失敗をする人が、たぶんすごく多いんだと思います。というわけで、クリスマスまで我が家の冷蔵庫に鎮座ましましていただくことにしました。この獺祭様。
獺祭の発泡酒飲むときは、YOUもTake Careしちゃいなよ！HAHAHA！（おまえがいちばんチャラいわ！）
探検！編集、執筆工場〜某媒体の記事ができるまで
明けましてメリークリスマス！ 2013年の12月がやってまいりました。
CodeGridの記事ができるまで
Editors' & Writers' Advent Calendar 2013の第1日目です。
第2日目は、えどさんの記事を書くときに気をつけていることです。
この記事では「探検！編集、執筆工場〜某媒体の記事ができるまで」と題しまして、CodeGridというフロントエンドまわりの技術情報を配信するサービス（有料）の記事ができあがるまでをご紹介したいと思います。
対象としては、技術者でちょっとなにか記事を書いたりしたいんだよね、という方や、技術書の編集に関わる方を想定しています。エンジニアではないフツーの編集者のワークフローなので、そこまで複雑なことはしていません。
技術情報系の記事の特徴
技術情報記事といいますと、まず情報自体に間違いがあってはいけません。そのため執筆者（いい感じの最強エンジニア）が記事を書いた後に、以下のような過程を経て、読者の手元に届くことになっています。
* 文章構成の妥当性を考える。 * 社内で技術的なレビューを行う。 * 日本語として理解しやすい、読みやすい文章にする。
つまり、ひとつの記事をめぐって複数人で校閲（主に技術面）、構成（主に文章面）を行うわけです。こんなときに便利なのが、バージョン管理や共有が簡単にできるGitとGitHubです。
Gitとはバージョン管理と、複数人でのソースの共有（しようと思えば）できます。主に、技術系の開発現場で使われているシステムです。
ですが、なにも、Gitはコードを書く人だけのためのものではなく、原稿執筆しちゃうぞ！編集しちゃうぞ！という方にも非常に便利に使えます。
誰が文章のどのあたりをいつ直したか、その履歴も残りますし、やっぱり前の方がいいよね（ま、実際にはめったに起きないことですが……）、ということが起きても、大丈夫なわけです。
原稿をお届けするまで
んでは、実際のフローをご紹介します。
1. 執筆者は原稿を書く
だいたい誰がどんなテーマで記事を書くかは、向こう一ヶ月くらい決まっています。執筆者は自分の順番が来たら、おもむろに記事を書きます。このときの形式はMarkdownで書きます。
2. 原稿ができたら校正用のリポジトリにpush
原稿ができたら、GitHub上にあるプライベートリポジトリにpushします。
するってえと、社内チャット（CampfireをPropaneというアプリを使って見てます）にも、pushしたログが出力されます。次のような感じで。
ここで編集者は「お。原稿あがりましたね」ということに気づくわけです。
追記：2013.12.7
このチャットシステムとの連携は、各リポジトリのSettings > Service Hooksで設定できます。海外のチャットシステムの主なものは、ぼほカバーされています。カバーされていない日本のチャットサービスは、APIが公開されていれば、がんばればできるかもしれない（私にそのスキルはないです、笑）！
3. 執筆者がissueを立てて、編集者にパス
執筆者は原稿を書いたことをissueを立てて、編集者に知らせます。なにか申し送り事項があれば、ついでにつらつらと書いたりもします。
編集者は、発行日ごとにMilestoneを切っておいて、そこにissueをぶら下げていきます。
4. がんばって編集
編集者はリポジトリから原稿やら付属の図版、デモファイルなどをGitでpullします。ちなみに執筆陣はエンジニアなので、ほぼCUIで、編集者はSourceTreeというGUIツールを使っています。
編集者はもらったMarkdown形式のファイルを自動的にjade形式に変換します。このあたりのすてきシステムは、フロントエンドエンジニアの@hokacchaが作ってくれました。
で、そのファイルをせっせと編集します。
- わかりにくい表現はないか
技術的に難しいものを難しい日本語で書いたら、二重苦ですからね。
- 実際に自分のマシンに環境を作って試してみる
編集者の環境は普段開発をしていないので、わりとクリーンに保たれています。なので、そこで原稿に書いてある通りの方法で環境を作り、本当にそうなるか試してみます。
すると、執筆者の環境ではうまくいっていたけれど、編集者の環境ではうまくいかないなどの齟齬がある場合があります。そういう細かいところをブチプチと潰していく、けっこう地味な作業をします。
- 小難しいけど、そこをツッコムと本筋が見えにくくなるとき
できれば、読者には文章に書いてある本筋を追っていただきたいのですが、たまに、ちょっと難しい用語がでてきます。しかも、それは本論にはそこまで関係が深くないと判断した場合には、注を補ったりします。
5. 記事をadminにセットする
記事を掲載するadmin画面にjade形式のテキストをセットし、それをステージングサーバーに公開します。そして、執筆者が立てたissueにコメントする形でそのURLを書き込み、申し送り事項とともに、執筆者にチェックをお願いします。
編集済みのjadeファイルは別のフォルダにコミットします。このときにコミットメッセージに以下のようにissue番号を加えると、issueにpushしたファイルへの参照がつきます。執筆者がjadeファイルをすぐ参照できて便利です。
編集済み原稿 著者校正未 #XXX
6. 執筆者（と愉快な仲間達）のチェック
原稿によっては、ここで少しのタイポなどを指摘されて、チェックOKがでます。その場合は、その修正を行ったあと、ふたたぶ記事をセットし直し、issueをcloseして、その記事の校正は終了となります。
変更して、前のバージョンとの差分（diff）は次のように表示されるので、どこをどう修正していったのが、変更の履歴を追うのがとても楽です。
んが、別のエンジニアからもレビューが入ることがあります。
そのような場合は、執筆者はいったん修正用のブランチを切って、jadeファイルに修正を行い、プルリクエストをすることもあります。
プルリクエストというのは、ブランチを切って修正した内容を吟味して、もしOKであれば、masterブランチにマージ（統合）してね！というお願いです。
ここの過程がいちばん、喧々諤々（別に喧嘩しているわけではない）となります。某CodeGridでは3本の記事を毎週配信しますが、編集者の主観からすると、だいたい1本が、ややすったもんだモードになります。
でも、そのすったもんだの先には、ブラッシュアップされた、すばらしい原稿が待っています。ここは執筆者も編集者も校閲者も粘り強くすすめます。
7. issueを閉じる
明けない夜はないように、閉じないissueはない。少なくともCodeGridリポジトリでは。
これでようやく読者にお届けできるレベルの記事ができあがります。ぜーぜー。
まとめ
今回はCodeGridの記事ができあがるまでを、さくっとご紹介しました。エンジニアの時間をかなり割いて行う作業ですので、ヘタすると受注案件よりもコストがかかっているのではないか？と思うことがあります。
幸いにして、CodeGridに関わるエンジニアは単著や共著など、書籍の執筆経験を持つ人がほとんどです。また頻繁にコミュニティの勉強会などでも登壇しています。「難しいことをわかりやすく」という当たり前ですが、難易度が高いことに挑戦できているのも、このメンバーだからなのか？と思うことがあります。
編集者のモチベーションのひとつは「執筆者への尊敬の念」です。これが持てない人は、編集者として不幸です。
だから、私は今日も元気です。どんとこい！クリスマス！
追伸：若干、手前味噌になりましたが、どうぞ、ご海容ください。
SourceTreeで個人的に.gitignoreしたい
個人用のメモです。なにか間違っていたら、ごめんなさい。
個人的に.gitignoreってなに
gitで.gitingore、つまり無視したいファイルには2種類ある。
もしかしたら、SourceTreeを使っているとGUIで設定できる場所があるかも知れないんだけれど、メニューのぞいた限りでは、「これだ！」というのがなかったので、手動で設定する方法をメモしておく。
どちらの場合も、基本はすでに作成されているファイルを編集するだけです。でも、そのファイルが不可視になっていることが多い。ローカルリポジトリをのぞいて、.gitignoreが見えてなければ、不可視になっております。まずは、それを解除。以下を参照しました。ありがとうございます。
1. リモートリポジトリにもpushしてプロジェクトメンバー全員で共有すべき無視設定
このファイルはSourceTree経由で呼び出せます。リポジトリ設定-> 高度な設定のリポジトリ限定無視リストがそれ。横にある［編集］ボタンを押せば可能。SourceTreeを起動してない状態で手動編集しても可。
ファイルが開いたら、例えば次のように書く。
リポジトリ内の_captureフォルダ内のファイルすべてを無視。
_capture/
特定のファイルを無視
drafts/hogehoge.html
ワイルドカードも使えます。
*.txt
あくまでも、こっちの設定はプロジェクトメンバーで共有する用です。だからよーく考えてやってください。
2.ローカルリポジトリだけで無視できればいいんだよねという設定
こちらが自分がやりたかったこと。プロジェクトメンバー全員に共有する必要はまったくなく、あくまでも自分のローカルリポジトリだけでいい、ってやつ。私の場合、かなり大きな画像群が、プロジェクトメンバーに共有する必要もないし、履歴管理も不要で、とにかく無視していいですというものでした。
そのファイルは同じ.gitignoreという名前でホームフォルダにあります。本来なら自分で作らないといけないんです。が、SourceTreeはMac用のアプリなので、デフォルトの設定で、自動的に.DS_Storeファイルを無視するようにしてあるようです。これはMac OS以外には関係のない話なので、「ローカルでできればいいんだよね設定」に書かれます。
なので、自分で作らなくてもすでにある、というわけです。
ホームフォルダのルートに.gitignoreファイルがあるので、さきほどと同じように無視したいファイルやフォルダを書きます。この場合、ホームフォルダにあるからといって、無視したいファイルを絶対パスで書く必要はないです。
これで「作業コピー」がかなりスッキリした。
ターミナルからぱたぱた
ターミナルからぱたぱたする場合は、以下のブログが参考になります＆思いっきり参考にさせていただきました。ありがとうございます。
こちらには、ローカルリポジトリだけで無視すればいいファイルには、例えばこんなものがあって……というのが書かれていて、とてもわかりやすいです。
