2018年11月08日

技術書典5へ委託&売り子で参加しましたレポート(感想とログ)

概要

技術書典5へ、サークル「Clear-mint:き24」さんの売り子として参加&委託頒布させていただいた感想。

技術書典5_頒布本とサークル参加証.jpg

技術書典2から数えて、薄い本の作成4回目。自分の中での振り返りと「記録」のための言語化(頭の外に出そう!)。 簡単に感想を述べるなら、次の3つ。

  • こういう本が当時に欲しかった!を書けたので満足♪
  • Re:VIEW環境+キンコーズ利用で、初めてのコピー本も困ることなく作成できた。
  • 頒布数は盛大に爆死した。委託頒布はサークル参加しての頒布とは別物と心得よ。

ちなみに前回の技術書典4では「頒布数、ほぼ読み通り!」とかほざいてましたね、私。ハッハー。 http://fluorite2.sblo.jp/category/4409735-1.html

なお、頒布した新刊本は次の1冊。

こういう本が当時に欲しかった!を書けたので満足♪

技術書典5への参加日程を確保した頃と前後して、 Node.js上でユニットテストするときのスタブ関数の作成周りについて、 Sinon.jsライブラリを利用して最短距離で使い方を覚える道はコレなんじゃない?って経験を偶々ゲットした。なのでそれをベースに書いてみた。

テストコード側のスタブ作成に悩んだり、そもそも何が嬉しいのだテスト駆動開発は?って疑問に思っていた過去の自分が読んだ時に 「必要最低限のテスト駆動開発をやってみる具体例はコレだ!」、 「このくらいの具体例と粒度と分量の本が読みたかった!」 って思える薄い本に仕上げられたと思う。 当時に「このライブラリって何?目的は?」など疑問を思ったところも含めて書けたので、満足♪

後半の「TypeScriptをやってみよう!」はオマケ的な位置づけ、、、 の割にはページ数を食われたけど、気になりつつも手を出せてなかった TypeScriptをやってみれたので、手を出して良かった。 初めてやるときは、このくらいの「ついで」で取り組むのも良いと思う。

Re:VIEW+キンコーズで、執筆以外へのコストは最低限に

今回がサークル参加ではなくて委託参加となった理由は「1ヶ月前を切るまで日程が確保できなかった」から。 実際、参加を決めたのは3週間前で、薄い本を書き始めたのは2週間前。 そんなギリギリの日程だったこともあって、製本版だと締め切りが間に合いそうになかったので、「せっかくなら」ってことで初めて『コピー本』を作成してみた。

そんな余裕のない日程だったけれど、「Re:VIEWで書いてキンコーズで刷る」の組み合わせで48Pコピー本、なんとかなった。「執筆以外のこと」へ割くリソースは大分少なくて済んだかなー、と感じた。出力形式や印刷時の配置、ホチキスの仕方、などを考えなくて済んだ。もちろんこれは、「過去にRe:VIEWで一度薄い本を書いた(環境がある)」という前提があるので、一般には当てはまらないかもだが。

Re:VIEWの良いところって、前回の感想でも書いたけど「見た目に拘らないなら、使い勝手良い」ってところだと思う。 今回も、先ずは文章もコードも区別なくテキストエディタでダーッと書いた。テキストだから端末を問わずに入力できるし。半分くらい?できた時点から、Re:VIEWの記法に乗っ取って章タイトルをマーキングして、引用コードをマーキングして、装飾しながら残りの文章を書いていった。

原稿が書きあがったのはイベントの前々日で、その日にキンコーズさんへ行って刷った。キンコーズさんの「セルフ製本」機能、初めての私でもあっという間にコピー本に仕上げられた。凄い! ・・・ただし、「ギリギリまで執筆でOK」はもう止めましょう(理由は後述)

頒布数は盛大に爆死した。

頒布数に関しては、今回は盛大に爆死した。

※ここの内容は、note.muに書いた次の2つの記事とほぼ同じ。

頒布数の結果報告

新刊50部持ち込んで、頒布数が7部。これを「爆死」と呼ばずして何と呼ぶ? 技術書典4の時の既刊も若干数持って行ったんだけど、こっちも盛大に爆死。

具体的には次の結果だった。

持ち込み数 頒布数
新刊コピー本 50部 7部
既刊 10部 1部

今回得た知見は→ 「委託頒布は、サークル参加での頒布とは大分勝手が違う。ゼロベースで計画せよ」。

コピー本だったので、実際のコスト観点での爆死具合が製本版に比べれば軽かった、のが不幸中の幸い。 勉強になった。

なんで爆死したのか?

初めて経験する「委託」へのリスク検討が甘かった。 今回に初めての要素は以下。

  • 委託頒布(Notサークル参加)
  • ポスター無し
  • 製本版では無くコピー本

売り子で入らせていただいたサークルさんで委託頒布したんだけど、自分でサークルを持つ場合と比較して以下の点が違った。

  • 被チェック数が見えないので、フィードバックを得られない。
  • ジャンルが違う場所に配置されるので、人の流れが違う。
  • 告知の手段が限られる。

配置される場所は大切。人の流れがやっぱ大分違う。 ポスター無し、って要素も「ここにこんな本がありますよ」ってのを伝える観点からだいぶマイナス。 テーブルの上の展示だけど通路の両端を歩いている人からしか見えないけど、ポスターを立てておくと、通路の中央からでも見えるから。

コピー本を今回に初めて作ってみて分かったんだけど、これ「保管づらい」。 製本版と比較して、積み上げた時に安定しないし、取り出すときもだいぶ気を付けないとすぐ曲がってしまう。 したがって製本版のように「在庫になったら、別の機会(別イベント、店頭委託など)に出せば良いし」という発想は止めた方が良さそう。出来ないわけじゃないけど。コピー本の委託を引き受けてくれたCOMIC ZINさん、マジで感謝!

そんなわけで、次回にコピー本する場合の部数は絞りに絞る予定。 もし次回も池袋会場なら、近くにキンコーズがあるからその場で増刷も出来る気配だし。

過去の数字に基づいて振り返ってみる

過去の技術書典2〜4の公式発表のサークル参加数と来場者数の数値を拾ってみると以下のようになっていた。

これをもとに過去の当方の「サークル当たりの来場数に対する、頒布係数」を乱暴に求めてみると、「×4.1」だった。

技術書典5に対しては、以下のように見積もってた(んだけど、過去との比較してなかった※1)。

  • 来場者数:10,000人(±2,000人:予測値)
  • 参加サークル数:500(概算値)

したがって、「自サークル」で且つ「製本版」の場合の頒布予想数は「82部(±16)」。 あー、ちゃんと計算してみるもんだなぁ。フィーリングで「ざっくり頒布数は80部くらい?」とか決めちゃだめだ(※1)。 ・・・キンコーズで刷ってる途中で「この紙の量はアカン気がする。やっぱ頒布数は50部に抑えよう」と 考え直した俺の第六感、良い仕事した!ギリギリ致命傷で済んだぜー。

委託の場合の見積もりは?

82部予測を2種類に単純に振り分けて考えると、「委託であること」「コピー本であること」の影響度は次のように見積もればよいのかなぁ?1サンプルしかないから気休め程度だけど。

  • 自サークルではない:×0.02〜0.17
    • (既刊の製本版が1部、新刊コピー本が7部)
  • コピー本である: ⇒影響は考える必要は無い。
    • (むしろ上振れした?でも新刊としての分もあるか)

コピー本であること、は頒布数に関しては考慮する必要がなさげ。 保管のしづらさだけ考慮すれば良さそうだ。 委託頒布の場合は、「自サークルでの頒布数の0.2〜2.0割弱」程度と考えることにしよう。

頒布数の決定には余裕をもって、平常な精神状態で行おう。

振り返ってみると、「何故に私は、80部で行ける!と当初に考えたの?」と不思議でしかない。 思い当たるところはあって、、、「イベント数日前はテンションが変だった」から、かな。 そんな状況でイベント日の前々日に部数キメて刷った。 締め切りもイベントも一緒に迫ってくる。 そりゃー、変なテンションに飲まれても不思議じゃない。 だから「フィーリングで、ざっくり頒布数は80部くらい?」とか決めちゃうのだ(※1のところ)。 ・・・これは、印刷所への入稿でも同じかもね? いくら割り増しすればギリギリまで執筆できる、とは言え、そういうテンションで部数を決めちゃ、少なくとも素人はダメだ。 きっとたぶん。

その他の要因について

今回の考察は「同じコンセプトなら、係数は変わらん」という前提に基づいている。 実際のところはある程度は異なるし、今回の薄い本では前回までと比較して「需要は凄く狭い」という自覚があった。 自分では気に入っているけど、これを欲するエリアに居る人は少ないだろう、って思ってた(通過点だと思うので)。 なので、その分も係数に入れるべきかもしれない。今回は考慮してないけど。

他の外的要因として、「客層が変わった」というのはあると思う。 正確には 「サークル数が大きすぎて事前チェックも当日のリアルタイムチェックも、全数はしきれない。なので、買う側の行動パターンが変わった(変わらざるを得ない)」 と言うべきかもしれない。 これの影響度は不明。だれか「それっぽく」推しはかれる方、居たりしますか?

全体としての感想

頒布数の観点では爆死して悲しみ(・_;)、なのだけれど。 でもイベント参加自体には「満足感」を抱いているのが、自分でも不思議。 新刊コピー本は、自分で読み返して「私はこういう本が欲しい!」と思えるものが書けたし、 購入した本も「読むのが楽しみ」(未だ1冊も読めてないのはヒミツでw)と思えるものをGet出来た。

ただ、、、TLの戦利品報告を見ていて「え、そんな本もあったのか?!」と思う率は、前回よりも高いかなぁ。 母数が多いので絶対値が上がっただけかもしれないが。あと、 会場内での移動が大変で「見えてるんだけど辿り着けない・・・」で消耗した。。。(o - _-)o

最後に、「キンコーズでコピー本作成ならギリギリまで執筆出来るぜ!」は止めましょう。 これ重要。ダメ、絶対。

なんにせよ、イベント自体は楽しかった。 技術書典5を開催してくれた運営の方々、足を運んでくださった方々、 薄い本を手に取ってくれた方々、打ち上げ含めてF2Fで話せた方々、ありがとうございました!

技術書典5_撤収後.jpg.jpg
posted by ほしまど at 12:52| Comment(0) | 日記

2018年05月05日

技術書典4へサークル参加しましたレポート(感想とログ)

概要

技術書典4へサークル参加(か19:Fluorite)した感想。
技術書典2から数えて、薄い本の作成3回目。 自分の中での振り返りと「記録」のための言語化(頭の外に出そう)。簡単に感想を述べるなら次の3つ。
  • 自分の中でのモヤモヤを言語化出来てスッキリ♪
  • Re:VIEW、使い勝手良いじゃん!
  • 雑感とログ(頒布数とか)
tbf04_display.jpg

なお、頒布&販売した本は次の2冊。

公式Webページのサークルページはこちら。

頒布した同人誌「テストで作ろう初めてのAzureアプリ」のサポートページはこちら。

自分の中でのモヤモヤに「名前を付けてやる!」できた!

技術書典4への参加はギリギリまで迷ったのだが、 「Node.jsでのテストコードの入門書が欲しいけど見つからない。よし書こう!」 と結論づけて、参加を申し込んだ。

「TDD(テスト駆動開発)、、、あたりの大層な事に手を付ける前に、テストコードって素敵じゃん!を実感したいじゃないですか」 がモチベーション。 今感想を書きながら振り返って気付いたが、 「こちらメモ書き記事に肉付けした」って内容に成っているのが面白い。

Mochaを使ったユニットテストベースのコーディングっていいよね、を伝えたいメモ

以前からもやもやと思っていた事、今なら言語化出来ていて、この2つなんだろうなと思う。

  • なんで「テストコード」を「素敵」って感じるんだろうなー?
  • テストコードに初めて触れる人には「面倒」って言われるのはなんでかなー?

このもやもやに対して、今回に薄い本の新刊 「テストで作ろう初めてのAzureアプリ」 を書く中で 「テストコードは、仕様書のように書けるんですよ!が伝わらないから」 って言語化が出来た。 スッキリできて嬉しい。

非公式打ち上げで、 「テストコードは、仕様書のように書けるんですよねー。ってことが分かりにくいですよね」 という意見を頂いて、「それだ!」って思えたのも良かった。 打ち上げで、同じ考えを持った方を見つけられたの、嬉しい!

技術書典4にサークル参加を決めてよかった。 サークル参加しなかったら、言語化できなかったし、「それだ!」とも思えなかっただろうから。

Re:VIEW、使い勝手良いじゃん!

今回の薄い本作成では、前回と前々回までの「LaTex」利用から「RE:VIEW」利用に鞍替えしてみた。感想としては「見た目に拘らないなら、使い勝手良い」。

先ず「ザザーっとテキストで書いて」、後から「見た目を装飾していく(図やコード、節を参照させる)」進め方が気に入った。装飾の仕方(マークダウン)も 覚える事少ない ので苦労しないし、VSCode+プラグインならインテリセンス効くし。 「とりあえず書ける。その時点で製本した場合のレイアウト(箇条書きとか)も、だいたい分る(コンパイルできる)」って良い。 プレーンテキストだから、差分も取りやすい。

TechBoosterさんのRe:VIEW本あたりに「技術書なんだから、見た目なんて些事ですよ。読むのに苦労しないならOKです」(だいぶ意訳) って記載があったと思うのだが、それを心の中で唱えながら書いた。 「書き切る」ってこと自体が目標になる人には(=私)、テキストで書ける&後から装飾できる「Re:VIEW」をお勧めしたい。

欲を言うなら、これをベースに「アドバンスドモード(もっと自由にレイアウト可能)」とか あると良いのかなー、思った。 一定以上に見た目を拘り始めると、途端に扱いが難しくなる(というか無理×_×)、とは思った。

当日のリソースの配分はミスった。

当日に関しては、リソースの時間配分をミスった。 前回、前々回とも「 15時過ぎたら空いた 」ので、それを前提にリソース配分してんだけど、完全に読みを外した(×_×)。 「あれ?まだ混雑してる・・・」の戸惑いのまま16時半を過ぎてた。そして終了の17時を迎えた。

とりあえず、頒布開始と同時に気になっていたサークルを回って買って、 後からもう一回サークルに足を運んで、作者に話を聞きたい、 15時以降の空いて来たころに買った薄い本をザザッと読んでから、、、 などと計画くしてたのだが、最初の「頒布開始と同時に」以外は全く回れず。話せず。残念。 「あとからブラブラ立ち読みして、気になった本を追加で買おう」 も全くできず。『晴れの技術書典』を甘く見てた。。。 (非公式打ち上げで、他のサークル参加者と話せたのは良かった)

前回、前々回に比べると、時間中の忙しさとピーク混雑は緩和されてて、サークルに足を運んでくれた方々と話せた率は高かったのは楽しかった♪ でも、「混雑は緩和」された割にはトータルでは疲労感が多かったかなぁ。混雑の平均値が高い&持続時間が長かったせいかもしれない。

まだ解は見つからないんだけど、次回の参加時はもう少し他のサークルを回る時間を取れるようにしたいねぇ。

その他、雑感。

次回へ向けた検討事項などのメモ。

作成過程が〆切重なってキツかった。

インプレスR&Dさんから、技術書典2で頒布した薄い本「初めてのAzureでNode.jsとSQL」について 「商業化しませんか?」とありがたくも声を掛けていただいていたんだけど、実は商業版では「3/1くらい書き下ろし」してる。 なので、技術書典4へ向けて 2つの締切

  • 薄い本の新刊「テストで作ろう初めてのAzureアプリ」
  • 商業版「Azure無料プランで作る!初めてのWebアプリケーション開発」への追加書き下ろし

が、ほぼ同時に走ったのはキツかった。 新刊2本とか書き下ろす方、尊敬するわ。。。

もうちょっと書きたいことがあったんだけど、調べてる時間を確保できずに、当初の内容からはいくつか章を削った。残念。

タイトルの検討が不足

今回の新刊のタイトルは「テストで作ろう初めてのAzureアプリ」と したのだけれど、これはもう少し分りやすい表現があったんじゃないかなー、と終えてから思った。これも未だ解は見つけてないのだけれど。

サークルに足を運んでくれた方々のうち複数の方から「あれ、初めての自動テス本は?」って言われた。サークルカットには「初めての自動テスト」って書いてたので、そことの乖離には気づかなかった。本の趣旨としては、「初めての自動テスト、、、を実際にAzureで公開できるWebアプリ作成でやってみよう!」(具体例が欲しい)だったので、こういうタイトルにしたんだけど、分りにくいかったかもしれない。

頒布数はほぼ読み通り!(※運です)

薄い本の新刊は、110部ほど頒布して30部をCOMIC ZINさんに委託。 前回は、160部ほど頒布して30部をCOMIC ZINさんに委託。薄い本頒布の経験を重ねてる方々からは「少し委託するくらいでちょうど良い部数」と聞いているので、ちょうどよい比率かな。

前回の技術書典3では200部を刷ったのだれど、

  • 他のサークル参加者の被チェック数との相対値
  • 他のサークル参加者の被チェック数の伸び率との相対値

が「・・・なんだか前回とは違う?」と感じたので、150部にした。結果としては正解♪

ただし、定量的に見積もった場合はさっぱり相関が見えない。 試しに、前回と前々回と合わせて当サークルの被チェック数をグラフにしてみたんだけど(自分のツイートから拾った)、被チェック数自体の途中値と最終値の相関はバラバラに見える。

被チェック数20180422.png

ついでに、最終的な「被チェック数」と「実際の頒布数」も次の通りでバラバラに見える。なので部数を「読み切った!」のは完全に「運です」ね。

最終チェック数 実際の頒布数
技術書典2 113     100(※1)
技術書典3 82 150
技術書典4 181 110

※1:13時ごろに完売のため実際の需要は不明

被チェック数だけじゃなくて、実際の来場者数やその分野への関心度もパラメータな気がする。 なお、来場者数だけ取り出しても、それとの直接相関も見えないね( 3400:3100:6300 )

この辺の分析は、公式さんのレポートに期待!。

なお、商業誌(初!)の新刊「Azure無料プランで作る!初めてのWebアプリケーション開発」は29部(※2)を準備して、14時頃に29部完売御礼♪ ありがとうございました!

※2:この部数は、同人誌の新刊と合わせて200部手前、、、という辺りで決めた。

最後に

最後に、というか雑感の続き。

書くのはツラかったけど、「言語化出来た」ってのはやっぱ楽しい。 そして、当日足を運んでくれた方々とF2Fで話せるのは、楽しい♪ 「技術書」を目的とした来場者数がメッチャ多いので、「需要なんか知らん。私がココを知りたいんだ」で書いた本でもなんとか黒字に出来るのありがたい!(赤字だと継続モチベーションがキツイ)。参加のハードルが低い、って大切だと思うんだ。

来てくださった方々、本を手に取ってくださった方々、技術書典4イベントを開催してくれた方々、ありがとうございました!

posted by ほしまど at 14:57| Comment(0) | 日記

2017年11月06日

技術書典3へ参加しましたレポート

技術書典3『初めてのWebアプリをAzureとNode.jsで』本を頒布させていただきました。技術書典2に続いて、2回目の「薄い本」作成。
tech03_space.jpg

大雑把な感想と次回へ向けて。
  • 「薄い本」を出すのに、ハードルが大変低い。参加しやすい。ありがたい。
    1. 100部くらいは頒布が見込める
      「技術書典」のイベントパワー、ありがたい(公式レポートによれば前回「2」の平均頒布数は132)。。
      在庫が出ても、COMIC ZINさんへ簡単に委託できる。これの認識、もっと広まって欲しい。

    2. 申込み期限が3か月前で、且つ参加費が4桁に届かない。心理的ハードルが低い。

    3. 「もくもく会」など、「執筆している他の方々」と接する場があるので、ペースメーカーになる。

  • 健康管理は大切。
  • 以下が揃えば、次回も参加したい。
    1. 自分が欲しい、と思う内容の本が無い(→よし書こう)。

    2. 体調管理の目途。

    3. 無事に当選すること(→これは運まかせ)。



数字の記録。

  • 持ち込み数と頒布数について

    1. 製本版の持ち込み数:200

    2. 頒布数:159
      ※技術書典決済システムの利用者数:13人で、頒布数全体の8%ほど。

    3. PDF版:12


    前回の100部完売を教訓に150で、、、→やっぱ200で、最終決定した。結論から言うと200にして正解。完売を回避できた。入稿日に、「やっぱ150→200部へ変更出来ますか?」と相談して、受け入れてくれたポプルスさんに感謝&「200にしとけw 」と適切に背中を推してくれた玄人 @bosuke さん、@oyakata2438 さん、に感謝。

    前回に「pdf版は無いんですか?」と結構聞かれたので、今回はシリアルコード印刷した電書カード作った。シリアルコードの認証は、前回の自分の薄い本に書いた内容をベースに、技術書典2後に習作で自作してたwebサービス使った。敢えて自作のを利用。

    なお、二つ並べてると「紙の本の方が欲しい」と言う方の方が多かった印象、なのは伝えておきたい。

    それから、COMIC ZINさんの「会場での委託受け付け」が神対応(運営さんが神対応、は言うまでもなく。決済システムのポップ、ありがとうございました!)。会場での直接委託を当てにして「在庫は委託すればOK」というのが、「200部」の決定の最後の一押しになった。が、あんなに委託依頼が簡単だとは想定してなかった。




  • 価格設定について

    1. 製本版(本文64ページ):800円

    2. PDF版:600円

    3. PDF版:12


    10ページで100円を基準に。でも印刷代くらいは安心して回収したい、、、前回は100部で完売したので、今回も100部はたぶん越えれると思う、、、で価格設定した。PDF版は「前回の技術書典2を見て回った感じでは、製本版に対して200円マイナス、くらいの価格設定が多かった(気がする)」で決めた。


  • 公式サイトの「被チェック数」と頒布数について

    • 技術書典3
      10日前の時点で32 → イベント終了直後79
      頒布数159。13時時点で100部くらいの頒布ペースだった気がする。

    • 前回の技術書典2
      10日前の時点で14 → イベント終了直後114
      頒布数100。13時で完売御礼。

    なお、10日目が当方の入稿日。この時点で印刷部数を最終決定した。



前回の技術書典2からの「次回参加へ向けた申し送り事項」に対する振り返り。

  • 入稿の日程
    前回は「すみません、入稿を1日待ってもらえませんか?」と依頼して延期してもらった。薄い本の作成の初回から、やらかした。
    今回は「入稿予定日」を守れた。ちゃんと改善。

  • 当日向けに準備した持ち物リスト
    前回を踏襲して大きな問題点は無し。

  • キャリーケースからの出し入れのしやすさ、は重要
    「一般入場開始後は、机の下で上開き状態のダンボールと机の上だけで完結させる。キャリーケースとの出し入れをしないで済むように配置する」を実践できた。これも、ちゃんと改善できた。



次回への申し送り事項。

  • 体調管理は大切。
    何故か、唐突に10月初旬の三連休(10/7)から体調崩した。「夜になると体調不良(寒気)」が頻繁に起きて困った。頻度と症状は軽くなりつつも、結局イベント10月いっぱい続いた。ツラかった。原因が良く分らないんだが、、、たぶん疲労管理ミス? 体調管理は大切。

  • 「展開と再収納の手間」を次回は気を付けたい。
    設置作業と撤収作業が、予定よりも時間を食った。そのせいで、他のサークルさんに挨拶行く暇が無かった(残念)。キャリーケースから出す順番も意識して詰める、に次回は取り組みたい。

  • つり銭は「全てが千円札で支払われた」を想定して準備すべし。
    前回は問題なかったので「半分もあれば〜」で臨んだら盛大に不足した。途中で、もっこすさん( @moccos )と、もふもふさん( @froakie0021 )さんに両替ヘルプ頂いて何とか乗り切れた。ありがとうございました。大変助かりました。



その他、記憶に残っていることを振り返り。

  • 執筆のペース
    ツイートから遡るに、9/18開始で10/9にとりあえず完成、10/11に校正終了。・・・正直、校正の時間が短くてツラかった。「終わらん・・・(泣)」だった。次回は倍は確保したい。



  • こういう本です、という宣伝について。
    なるべく早くに、執筆中からした方が良いかもしれない。140字でツイートするってことは「要約」をツイートすることなので、「何を書きたいのか?」が明確になってブレない効果があるんじゃないかなーとか、後から思った。



  • 嬉しかった、お客さんの一言、二言。
    「分り易い目標設定だね」
    「スタートと、ゴールが具体的に書いてあるの、イイね」
    うん、そこは意識して書いた。



「そのうち勉強しようかなー」と思っている事を「勉強した!」に変える事、が「薄い本を出す」事の一番の効果かなー、と思った。体調管理ミスもあって、大分ツラかったんだけど、今回もイベント参加を決めて良かった。
 技術書店3イベント当日に台風直撃の中をで足を運んでいただいた方々&当サークルに立ち寄ってくれた方々、素敵な技術書典3を開催くださった運営の皆様、大変ありがとうござました。おかげさまで楽しく過ごすことができました\(^▽^)/
posted by ほしまど at 12:22| Comment(0) | 日記