技術書典6、無事終了しましたね!関わられたすべてのみなさんお疲れ様でした。

つぎの出展に備えて振り返りたいと思います。

本の内容についてはこちらにまとめています。

技術書典6で『Knativeの歩き方 KubernetesからServerlessを訪ねて』と既刊第2版を出展します #技術書典

手にとってくださった方はこちらのページで変更内容をお知らせしていくのでぜひ見てみてください。

早速修正がありますすいません…

『Knativeの歩き方 〜KubernetesからServerlessを訪ねて〜』の正誤表と増補改訂情報 #技術書典

謝辞

今回も単著と言いつつも妻に編集や表紙デザイン、サークルカット作成、入稿(本とダウンロードカード)をお願いしました。

初めてだらけの前回と比べると多少平和だった感はあるものの、4/8入稿に対して4/7の夜まで粘ってしまったので丁重に労わせていただく所存です。

執筆環境として、TechBoosterさんのTechBooster/ReVIEW-Template@atsushienoさんのatsushieno/vscode-language-reviewを今回も活用させていただきました。ありがとうございます!!

振り返り

Good

テーマ

こちらでも書きましたが、Kubernetesをある程度理解しないと先に進めないKnativeをテーマにしたことは仕事にも大いに役立ちました。

Serverless Meetup Tokyo #11 で「入門 Knative 〜KubernetesとServerlessとの出会い〜」を話してきました #serverlesstokyo

さらに、サーバーレスと謳っているとはいえ最初は愛しのLambdaには程遠く感じたKnativeも、愛しのLambdaに感じる愛しさの根源を見つめ直し、それをKubenretesの利用者に届けたい気持ちを感じとれたことは今後の検証の方向付けになりました。

CloudNative Days Tokyoでも「Knativeで実現するKubernetes上のサーバーレスアーキテクチャ」というタイトルで発表させていただけることになったので進めていきます。

その検証の課程で『Knativeの歩き方 KubernetesからServerlessを訪ねて』をよりよくしていきます。

具体的にはつぎのような内容の章を追加します。

  • Knativeのコンポーネントを組み合わせたユースケース
  • Knativeを使ったプロダクトを利用することで「開発者にとってより機能・サービスのユーザーに対する価値向上」に集中できるか
  • Knativeで作る俺たちのLambda

そして何より、普段の仕事で感じるような感じないような課題と自分の趣味の交点がこのあたりな気がするので楽しい!!楽しいよ!!!

わくわくする技術との出会いが何よりも大きな価値です。

って書いたら振り返りもう満足した。

BOOTH事前販売

技術書典5では本番後に販売を開始しましたが、今回は入稿日に販売を開始しました。

Knativeの歩き方 KubernetesからServerlessを訪ねて(PDF、ePubセット版) #技術書典

前回そうしなかったのは「本来紙本を買ってくれるはずの人が紙本でなくBOOTHに流れ、紙本が売れ残るのがこわかったから」です。

BOOTHで事前に買ってくださる方は当日参加できない事情がある(別の用事がある、興味があるが会場が遠い)方のような気がしたのと、紙本売れ残るリスクそんなに感じなくなりました。

ABテストできるわけではないので何とも言えないですが、収益が目的ではないので告知タイミングで欲しいと思ってくださった方が当日を待たずその場で手に取れる方が幸せだと思うので今後もそうします。

うれしい感想

いただいた感想が嬉し過ぎて本当に書いてよかったなぁと思いました。

前書きに始まるKnativeを僕が書く必然性(僕が書くのにふさわしいとかそういう意味ではない)や、それぞれのコンポーネントのサンプルの登場させ方、順番、組み合わせ方。

中身としてはREADMEを超えるものにはなりませんでしたが、話の流れとして自然になるようにする部分にはこだわりました。

そういう部分や愛情が伝わったのは嬉しいです。

そしてKnativeを一緒にわいわいやる仲間が増えていくのは財産です。

本のタイトル

お気に入りです。

Serverless meetupを諦めなかったこと

去年のServerless ConfはLTやってみたい!と思っていたものの、技術書典5の準備と重なったり、それを発表できる形に整理する方法も思いつかずただただ指をくわえて見ていました。

今回は3月頭という技術書典1ヶ月前のタイミングでのServerless Meetup登壇を1つのマイルストーンとし、自分の認識もブラッシュアップしながら進めることができました。

Serverless Meetup Tokyo #11 で「入門 Knative 〜KubernetesとServerlessとの出会い〜」を話してきました #serverlesstokyo

継続して取り組みたい大きなテーマがあるときはアウトプットの場が分断されずいい感じに繋がるので継続したいです。

最新バージョンへの追従を諦めなかったこと

入稿数日前に0.4系から0.5系へのアップデートがリリースされ、1つのコンポーネントのアーキテクチャが大きく変更されました。

進捗も逼迫していたので迷ったのですが、開発に勢いがありどうせすぐ情報が古くなるなら可能な限り新しいものを届けたいと思い追従することにしました。

もし古いままだと、本を読みきったと思ってもまた別途新バージョンをキャッチアップする必要が生じやや二度手間感が生じます。

それよりは早くユースケースに進んでわいわいして欲しい。結果期限ギリギリになり妻には迷惑をかけてしまったので丁重にry

CloudNativeコミュニティの方々との交流

事前にテーマの近い人が知れる(そういう風に配置していただける)ことで事前にTwitterでいろんな方と交流できたのもよかったです。当日を迎えるのが楽しみになる要素の1つでした。

CloudNativeコミュニティやその勉強会、Meetupでもぼっちにならない…!ありがとう!!!

謎の試み

何に1000円を支払っていただくのか

前回比ページ数が減った上で同じ値段なの気が引けると思っていたこともあったのですが、そう考えるのはやめました。

検証された最新技術が本当に必要最低限の分だけまとまっていて、安心して気軽に入門できるのも1つの価値です。

当日実際手にとってみて、「この分量で1,000円かよ」って思われるなら別にそれでいいなぁと。

ソフトウェアをコードの行数で値付けする・しないと似たような話かもしれません。

あと僕は一度買ってくださった方には増補改訂版(電子)を無料で配布しています。

目の前にある紙に1,000円払ってくれと言ってるわけでもありません。

「紙を渡して1,000円を受け取る」しか見ないのは悲しいし、本質から遠いです。

Challenge

うやむやにしていること

期限あるものに間にあわせるにあたり妥協している部分があります。

たとえば、詳細は割愛する形でリンクだけのっけているようなものを全部完全理解しているわけではないし、公式のREADMEに書いてる仕様の実装全部追ってるわけでもありません。

今後ユースケース中心に見ていくにあたり、それが楽しくて疎かになりそうだが理解する時間を確保すべきだなぁと思う部分は個別に整理するなり、Knative本に唐突にコラムとして追加するなりしたいです。

  • Istio、Envoy、サービスメッシュ
  • IstioとKnative Serving(、Eventing)の関係
  • 実装としてのKnative
  • Kubernetesで特に弱いService周りの仕様、基礎事項
    • DNS、kube-dns
    • L4/L7
    • iptables
    • Ingress
    • kube-proxy
    • パブリッククラウドのLB
  • イベントドリブン、リアクティブなアーキテクチャ概論
  • 分散システムのアーキテクチャ

無限に学ぶことがあって楽しいですね。

実装面は5月の後半に少しGoにフォーカスした内容で30分くらいお話しすることが決まりつつあるのでいい流れです。

OGP画像

圧倒的失敗。せっかく作った本を視覚的に伝えるチャンスなのにもったいない。

OGP画像に最適なサイズと、これらを使えばキャッシュクリアできる知見を得たのでよかったです。

過去に投稿した分も更新されます。再投稿してもいいし、再投稿しなくてもいい。

https://cards-dev.twitter.com/validator
https://developers.facebook.com/tools/debug/og/object/

こういう感じに整理するのすごく見やすくていいなぁと思いました。何を頒布しているかわかりやすい。

コミュニケーションパス

何かあったら@toshi0607まで!みたいなのわざわざメンションしてコミュニケーションすることもないのかな。結構頻繁に「Knative」でTwitter検索してるのでだいたい拾えている気もする。

と考えていたところこんなツイートが!

ハッシュタグでゆるくつぶやいていただけたら拾いますくらいの方が楽に感じたり、何か言葉を投げかけてくれる人がいるかもって思いました。

ハッシュタグ作りやすいタイトルだと便利、しかしハッシュタグに最適化したタイトルつける必要もないみたいな姿勢でいけたらと思います。

みんなその辺どうしてるんやろうと思ってBOOTHのぞいたら完璧な方がいらっしゃって感動しました。

りあクト! TypeScriptで始めるつらくないReact開発 第2版

ハッシュタグ検索結果のURL貼っておくの正しいっぽいし、それに限らず親切な作りになっていて勉強になります。

会いに行けるアイドルならぬ、タイムライン上にいる著者をたくさん生み出した技術書典。

気軽に絡んで技術もふもふわいわい盛り上がりたいものです。

新刊の部数

数字の整理は後からしますが、Knative本の方は100部刷って完売が14時過ぎでした。

一方Lambda本は既刊の第2版で50部刷ったものの完売が終了直前。

Lambda本はちょうどいい具合だったと思うのですが、Knative本は150部刷ったらその分頒布できたのかわからないし、毎回テーマも異なるのでなんとも言えないですね。

ただ言えるのは、紙本が当日残ってもそれを必要としてくれる人に届ける手段はいろいろあるので、ちょっと余るだろうなぁくらい刷ってみるのも試してみようと思います。

金銭面では紙よりも電子で買っていただける方がよいかもしれませんが、自分は技術書はほぼ紙でしか読まないし、読もうと思ってくださった人が読みやすい形で手にしていただけるのが一番です。

査読

事前に募集したものの、その時メンションしてくださった方にすぐ返せず、いざというタイミングで探したらメンションはなくなっていました。

興味持ってくださる方は大切にしつつ、ゆるぼで集めるのは厳しく感じます。

紙本になる前に読んで欲しいケースもなったあとに本でほしいケースもどちらもあるので、目的を明確にしてお願いする形にすることにしました。

Knativeの動向

Cloud NextでCloud Run(Knativeを利用したプロダクト)が出たのは追い風になったと思うのですが、その追い風や発表直前のアップデートは頑張れば読めたかもしれなです。

発表前にBOOTHで販売を開始していたのはすごくよかったと思います。一方でこの点考慮できていれば紙本もうちょっと刷ろうと思っていた可能性が高いです。

今後

このとおりです。振り返りの「テーマ」と「うやむやにしていること」あたりをいい感じにやっていきたいと思っています。

  • Knativeのコンポーネントを組み合わせたユースケース
  • Knativeを使ったプロダクトを利用することで「開発者にとってより機能・サービスのユーザーに対する価値向上」に集中できるか
  • Knativeで作る俺たちのLambda
  • Knativeの実装
  • IstioとKnative Serving(、Eventing)の関係
  • 分散システムのアーキテクチャとKnative

めっちゃ楽しそう。楽しそう…!!!

数字の整理

売上

  • 本 + ダウンロードカード(PDF、ePub、MOBI): 1000円 × 100部(Knative) + 1000円 * 50部 = 150,000円
  • ダウンロードカード: 1000円 × 16枚 = 16,000円
  • BOOTH販売(PDF、ePub。MOBIは希望者に送付、Knative本を公開した4/8〜この記事を書いている4/20まで): 1000円 × 40部(Knative) + 1000円 × 11部(Lambda本) = 51,000円

-> 217,000円

きっとBOOTHはまだまだ伸びる…!BOOTHでのそう販売数は累計113部(Knative: 40部、Lambda: 73部)です。

かんたん後払いは 81/166(100 + 50 + 16)でした。半分くらい!

41/124で3割くらいだったので普及が進んでますね。あれだけ混んでても2、3件ちょっとアプリUI更新遅れたくらいで不自由をほぼ感じず、管理する側も便利でした!

原価

紙本印刷費(日光企画さん): 23,600円(Knative) + 21,890円(Lambda) = 45,490円
ダウンロードカード印刷費(プリスタさん): 1,700円(Knative)
技術書典参加費: 7,000円

-> 54,190円

Lambda分は前回とQRコード変えてないので残り分をそのまま利用、小物も追加なしです。

執筆関連の人の稼働という観点では、技術書典なくても検証するしまとめもするので皆無です。

表紙やダウンロードカード、サークルカットのデザインは妻がやってくれましたが、仕事として他の方に依頼するとけっこうかかる気がします。

大丈夫そう!

被チェック数

雑に貼ります。前回は最高127だったので前回よりは手にとっていただけそうな雰囲気はあるものの、当日ブースまでたどり着いて見つけていただくまでには混み具合なども影響すると思います。

あと複数頒布するとどちらにどの程度興味をもっていただけてそうなのかがわかりません。

来場者数も増えて母数増えたのかなとも思ったのですが、入場者数自体は前回と大差なさそうでした。

前回参加者10340人、今回10260人、運営や出展者込み。

  • 20190319 2227 16
  • 20190320 2353 18
  • 20190322 1530 24
  • 20190323 1850 25
  • 20190324 1925 26
  • 20190325 1904 29
  • 20190326 2227 31
  • 20190327 2121 34
  • 20190328 1819 34
  • 20190329 1100 35
  • 20190330 0931 36
  • 20190331 1038 38
  • 20190401 1224 39
  • 20190402 2245 42
  • 20190403 0853 42
  • 20190404 1022 47
  • 20190405 2054 48
  • 20190406 2139 50
  • 20190407 2211 56
  • 20190408 1842 57
  • 20190409 0826 66
  • 20190410 2128 82
  • 20190411 2358 96
  • 20190412 1357 104
  • 20190413 1931 138
  • 20190414 0836 185
  • 20190414 1400 207

技術書典5の数字はこちら

まとめ

技術書典好き!!!

このページでは『Knativeの歩き方 〜KubernetesからServerlessを訪ねて〜』の正誤表と増補・改訂をお知らせします。

この本を手にとってくださった方がちょっとでも選んでよかったと思う本に育てていきたいので、章の追加なども楽しみにしていてください。

引き続きフィードバックお待ちしてます!@toshi0607

更新情報や新刊情報もこのアカウントでつぶやきます。

正誤表

ダウンロードカード経由の方は

PDFページ PDF反映 ePub版反映 MOBI版反映 修正日 version
25、37 istio-system –output ‘jsonpath={.status.loadBalancer.ingress[0].ip’)} istio-system –output ‘jsonpath={.status.loadBalancer.ingress[0].ip}’) done done done 20190418 v1.0.1

増補・改訂

PDFページ 内容 PDF反映 ePub版反映 MOBI版反映 修正日

リソース

技術書典5、無事終了しましたね!関わられたすべてのみなさんお疲れ様でした。

つぎの出展に備えて振り返りたいと思います。

執筆のモチベーションについては宣伝記事に書いたので、今回はこれからに向けての話を中心に書こうと思います。

技術書典5で『Goで学ぶAWS Lambda』を出展します #技術書典

謝辞

今回は単著やで!と言いつつ、大いに助太刀してくれた2人にまずお礼を言いたいです。

まず前職の同僚@Shuheiktgwさんです。査読でわかりにくい部分を指摘してくれたことで特に2章は大きく構成を見直せました。更にGitHubのリポジトリにもPRをくれ、大きく貢献してくれました。

そして妻です。9月12日時点ではまだ原稿0のようなペースで原稿以外に時間が割けなかったので9/8に「原稿以外のすべてを頼む!!!」と一任(丸投げ)し、締切管理、表紙デザイン、ダウンロードカードデザイン、発注・入稿、当日のチェックリストに基付いたパシリまで何一つ文句も言わずにやってくれました。改めて文字にしてみるとひどい夫や。

それでも、発注してくれた本の開封の儀やイベント当日の売り子を通じて「つぎは書いてみようかな…!」なんて言ってくれるのは心の救いです。ディズニーで打ち上げしてきます。

執筆環境として、TechBoosterさんのTechBooster/ReVIEW-Template@atsushienoatsushieno/vscode-language-reviewを大いに活用させていただきました。ありがとうございます!!

フィードバックが欲しい

今回頒布した『AWS Lambda』は技術書典3の『Extensive Xamarin』で担当したXamarin.Macの章と比べ実装に基づく内容になっています。もっと言えばAWSのアカウントがありGitHubからソースコードを落としてくればそのままデプロイできるものです。

それは、書籍を執筆するとは言いつつも自分が実装する手触りが欲しかったのが1つあります。そして、自分が技術を学ぶときは最低限のルール説明を読んだら掲載したサンプル+αの粒度のコードが読みたいと思うからです。

説明しないと伝わらないソースコードなら書き方がよくないかもしれないし、どうしても必要ならコードコメントでよいのではないかと思います。

けどそれならGitHubにしっかりREADMEを書いて公開して終わりになるし、書籍にする意義が見出せません。結局、GitHubと技術書の間みたいな構成の本になりました。

幸い印刷していた分は売り切れ、ダウンロードカードも購入いただき、BOOTHで販売している分も着実に売上を伸ばしています。

つまり、売れ残った紙本に縛られず思い切って増補改訂ができ、ダウンロードカードのURLを通じて紙本を買ってくださった方にも更新情報をお伝えできる状況です。

そこで、フィードバックをくださる方にダウンロード版(PDF、ePub、MOBI)を差し上げたいと思っています。ぜひ@toshi0607までDMをください。もちろん購入いただく分は止めません。それはそれでとても嬉しいです。

  • 本としてこの形式がありと思うか?
  • ソースコードはわかりやすいか、どうすればわかりやすくなるか?
  • 構成として過不足はあるか?
  • ユースケースから自分でLambdaを利用したアーキテクチャを検討するイメージはわくか?
  • もしあまり触ったことがなければ触りたくなるか?何が辛そうか?

このあたりの感想がほしいです。

僕が欲しかったのは売上ではなく自分の技術力を高めるための言葉だったことに気がつきました。

お金は社が十分供給してくれます。

増補改訂

他の記事でちょっと書いたのですが、目次を考えている段階ではLambdaを活用する上で組み合わせそうな技術要素をもっと盛り込む予定でした。

  • 認証・認可(4章、CognitoとかAutn0とか使う) 
  • サーバーレスSPA(4章、Vue.js)
  • Lambda上でヘッドレスブラウザ使うユースケース(途中まで実装してた)
  • GitHubアサインのSlack通知
  • AWS Serverless Application Repository
  • Kinesisを使うユースケース
  • DLQの設定
  • Alexaスキル系
  • GraphQL(AppSync)
  • SQS(FIFOキュー)のユースケース
  • CQRS(とても実装したかった)

しかし、9月12日の午前段階で3目のユースケースの実装が一通り終わったような状況だったので見送りました。

4章関連とCQRSはやって章も足したい。自分が買ったPDFの技術書の章、気付いたら増えてるとテンション上がりませんか?上がらなくても大丈夫です。

ただ、仕事ではAWSに触れなくなったのでいい感じに共存したいなぁとは思っています。

AppSyncもFargateも触りたい気持ちはあります。

けど、Serverless Conf Tokyoで@marcy_teruiさんのセッションを聞いて、プロダクトそのもの以外の技術系アウトプットの理想形はこういうのだと感じました。

実運用に裏打ちされた教訓が他には無い独特かつ研ぎ澄まされた視点で語られる40分はただただ感動ものでした。

季節性のあるいい感じのアウトプットイベントに一生懸命向き合うこと自体はもちろん価値があるけれど、それが自分が向き合うべき課題の解決に関連するものであれば尚更素晴らしいということです。

逆に関連ない方がよい結果になるかもしれないけれど、やってみないことにはわからないやってみよう。

数字の整理

売上

  • 本 + ダウンロードカード(PDF、ePub、MOBI): 1000円 × 100部 = 100,000円(14時完売)
  • ダウンロードカード: 1000円 × 24枚 = 24,000円
  • BOOTH販売(PDF、ePub。MOBIは希望者に送付、技術書典終了日23時頃オープン): 1000円 × 22 = 22,000円

原価

  • 紙本印刷費(日光企画さん): 30760円
  • ダウンロードカード印刷費(プリスタさん): 940円
  • 技術書典参加費: 7,000円
  • ダイソーで小物(ホワイトボード、テーブルクロス、見本誌台など): 1,000円
  • 人の力

被チェック数

技術書典当日(10/8)最高で127、そこから減って最終的に123。

  • 10/1: 38
  • 10/3: 51
  • 10/4: 57
  • 10/6: 73
  • 10/7: 98
  • 10/8 8:00: 116

何が原因で売れる・売れないが決まるかよくわかりません。

僕は10/1の夜入稿したので、結果的に完売は嬉しかったものの100部刷るのすらだいぶこわかったです。

そのためBOOTH販売に本来紙で買ってくださる方が流れて欲しくなかったので技術書典終了後に開始しました。

ただ言えるのは技術書典で自分のブースに来てくださったお客さんを見ているとやっぱり紙の本が欲しそう。

そしてBOOTHで買ってくださる層(住んでる地域とか紙・電子書籍のスタンスとか)と違ってそう。

まとめるとやっぱりよくわかりません。テーマやサークルの配置によっても変わりそう。

いろいろと考え方はあると思いますが、僕は紙本を余裕をもって売り切ってスッキリした気持ちでつぎの技術書典を目指したいです。執筆やその根底にある技術力向上にフォーカスしたいなぁと思いました。かと言って当日のダウンロードカード販売とBOOTH販売だけ行って紙本をもっていかないのも嫌です。

技術書典は楽しくてしょうがないけれど、技術書典でアウトプットすること自体は自分にとっての目的ではありません。

これからも自分なりのスタンスで向き合っていきたいなぁと思いました。

10/8(月/祝日)開催の技術書典5で『Goで学ぶAWS Lambda』という本を出展します。76ページです。

カエルと空というサークル名で場所は「か76」です。

ぜひ遊びに来てください!!

興味ある方はサークルのチェックリストに登録しておいていただけると助かります。印刷数の参考にします。

本の紹介

Goで実装したAWS Lambdaのユースケースを見ながら開発方法を学んでいく構成になっています。

目次はこんな感じです。

  • 第1章 環境構築
    • anyenv
    • anyenvupdate
    • goenvとGo
    • pyenvとPython
    • aws-cli
    • aws-sam-cli
    • インストールトラブルシューティング
    • direnv
    • dep
    • gig
  • 第2章 S3イベントの活用
    • 概要
    • S3
    • シーケンス
    • フォルダ構成
    • ソースコード
    • テスト
    • デプロイ
    • 削除
  • 第3章 SNSとSQSによるファンアウト
    • 概要
    • SQS
    • SNS
    • シーケンス
    • フォルダ構成
    • ソースコード
    • テスト
    • デプロイ
    • CloudFormationトラブルシューティング
    • 削除
  • 第4章 API GatewayとDynamoDBを使ったURL短縮サービス
    • 概要
    • API Gateway
    • DynamoDB
    • シーケンス
    • フォルダ構成
    • ソースコード
    • テスト
    • LambdaとAPI Gatewayのローカル実行
    • デプロイ
    • DynamoDBのテーブル定義変更
    • 削除

ユースケースは3つです。

3つともSAM(AWS Serverless Application Model)で定義を書いていて、Lambdaはもちろん、関連するAWSのサービスのデプロイはすべてコマンドで完結します。

勢いでシーケンス図も載せてみます。

  • 2章

  • 3章

  • 4章

執筆のモチベーション

Lambda好きや!!!

なんというか、AWS Lambdaがかわいくてしかたがないです。

趣味で触り始め、前職ではC#で書いて本番運用してました。

Rubyがマジョリティな会社でC#を使ってAWS Lambdaの本番運用を開始した話

今のお仕事ではAWSは触らなくなったものの今年に入ってからGoに出会い、Goを書いたら書いたで幸せな気持ちになることができました。

つまり、GoでLambdaを書けばよいのでは?ということで、他の言語に比べたらGoのサンプルも少ないし布教したい!という ~~名目~~ 一心で書いてみることにしました。

ただ、Lambdaの制限はーとか、実行方法はーとか、AWS公式チュートリアルを見ればおしまいなことだけを書いても悲しいのでとにかく実装に寄せることにしました。

よく見るアイコンが並べられたアーキテクチャ の図を眺めてふんふん言ってるのではなくて実装するのです。自分で手を動かすのです。

SAMなりCloudFormationなりも各リソースのプロパティをYAML・JSONで定義すれば終わりでしょうとは言わず、エラーにハマりまくってInfrastructure as codeを体得するのです。

そんな気持ちで書きました。

勉強になるかは知りません。ちょっとでもこのLambda(とGo)への愛情が伝わり、興味を持ち、触るきっかけを掴む方が増えたら嬉しいです。

「技術」書、単著

技術書3の頃にちょうど前職でXamarinでMacアプリを開発していたこともあり、Xamaritansというサークルの『Extensive Xamarin』の出典・販売に携わりました。そして技術書典4では同サークルの本のレビューにちょこっと携わり、当日売り子をさせてもらいました。

技術書典3で『Extensive Xamarin』という同人誌の出展・販売に携わりました

技術書典3で携わった『Extensive Xamarin』が3月に商業出版されました。そして間近な技術書典4

やっぱ技術書典は!書かないと!!寂しいの!!!

というわけで技術書典5の申し込みが開始されてから秒で申し込みました。

ここ半年の社会生活に鑑み単著で、『Extensive Xamarin』では全然技術書っぽい章にできなくて(他の著者はちゃんとした内容でしたよ)不甲斐なかったので思いっっっ切り実装してから書く前提で。

ルールを調べてまとめただけの記事をもう書いてはいけないの!!!

つまりモチベーションはエンジニアとしての愛と憎しみです。

あと年初目標的には年間執筆数があります。

カエルと空

前々職のCMで一時期カエルを使っていたことから今も惰性でカエルグッズを集めています。

机はカエルでいっぱいです。

蛙(かわず)から連想するものの1つに、「井の中の蛙大海を知らず」という諺があるじゃないですか?

一方で、日本の後付けで「井の中の蛙大海を知らず、されど空の深さ(青さ)を知る」というのもあります。

由来の真偽はどうでもいいです。

自分にカエル属性があるかどうでもいいです。

ただ、思い上がるのも卑下するのも時間の無駄で、自分が見識を深めるべきもの、解決すべきものにひたすら向き合うのだという思いがあります。

その象徴としてカエルと空というサークル名にしました。

今向き合うべきはLambdaではない可能性があります。

現在はBOOTHでも頒布中です。

2017/10/22開催の技術書典3で『Extensive Xamarin』という同人誌の出展・販売に携わりました。

https://techbookfest.org/event/tbf03 より

忘れないうちに感想や振り返りを書きます。

参加のきっかけ

7月の初旬頃(?)にXamarinの中の方がtwitterで書く人を募ってらっしゃったのを見たのがきっかけでした。

最初見たときは「あー、いつか書けたらいいな…」みたいな気持ちで流していたのですが、もうそろそろ募集は締切るというタイミング(8月の半ば)で参加することにしました。

参加しようと思ったきっかけは、何かすごく書きたいことがあるからではなく、Xamarin、強くなりたいからです。

テーマ選定

参加表明時はXamarin関係の興味がある分野として

を調べながら書こうと思っていました。

しかし、LottieXamarinはLTで調べたときにもっともっと深めたいとは思わなかったし、Realmもいつかは自分のアプリで使ってみたいなぁと思っていたものの自分のアプリで検証してそれから原稿を書いて…みたいなスケジュールで動くことは無理そうでした。

ならば自分が今業務で関わっていることに正面から向き合おうと思い、Xamarin.Macアプリ関連について書くことにしました。

ちょうどXamarin.Macを使い始めて間もないころだったので、開発フロー全体をどう組み立てていくのかについて不安を感じている時期でした。

そのため、自分のその不安を低減できるよう勉強・整理すべく「Xamarin.Macの配布方法」を具体的なテーマにすることに決めました。

Xamarinそのものを扱うことにはならないかもしれないけれど、Xamarin.Macを使ったMacアプリ開発を行う上で欠かせない情報、他の誰でもなく「自分が開発をスタートするときに欲しかった体系的な情報」を書くことにしました。

執筆

早速8月の半ばから記事を書き始めました。Extensive Xamarinのリポジトリに記事(Re:View形式)のPRを送ったのが9/10です。

土日のうち、イベントやその予習以外の時間と、たまに平日の夜に書きました。

少し空いて9/28には相互レビューが始まりました。僕はXamarin.Macの強い人にかなり詳細なレビューをいただき、このレビューがあったからこそ当日を迎えられました。

ここだけの話、レビューの修正対応期間が.NET Confの準備の佳境と重なってしまい、レビュー対応のうち体裁系は妻に手伝ってもらいました。

当日

会場に入って自分たちのブースに行き、『Extensive Xamarin』が入ったダンボールを開封したときの本に対するいとおしさが半端なかったです。

カバーイラストも画像では見せてもらっていたものの、いざ印刷されたものを目にするとたまらなくいとおしいです。

台風直撃(の直前)の生憎な天気でしたが、足を運んでくださったみなさまありがとうございました!

参加者としては最初の方に回らせていただいたので、気になる本は一通り買うことができました。

振り返り

Good

参加することにしたこと

いつか書けたらいいなぁ、で逃げなくてほんとによかったです。

もっとああすればよかった、こんな風に書けるようになりたい、も第一歩があってこそです。

テーマ
「自分が向き合うべき課題」に取り組めたことはよかったです。

Xamarin色が強くなかったことは心残りです。

期限
期限からだいぶ前倒しで書けたのはよかったです。

ただ、Challengeにつながる内容ですが、レビューが始まるまでに体裁や調べ足りない自覚があった部分は改善しておきべきでした。

Challenge

クオリティ
レビューしていただくにあたってそれまでにできることがあったというのは一番の反省点です。

Webページ用のビルドしかせず、PDF(実際に紙の本になるときの印刷状態に近い)で確認しなかった罪は大きい…。

Xamarin
どんな内容を書くか以前の話ですが、もっと「本質的なこと」について書いたり、理解したり、理解した上で開発したりしたいとは常々思っています。

それは動作原理に関するものです。

「こうすればこういう問題が解決できる」にとどまらず、「こういう問題はこうすれば解決できるが、それはこういう仕組みになっているからだ」という部分に踏み込めなければ成長しないんだろうなぁ…という気持ちが強いです。

なので、唐突ですが今年のQiitaのAdvent Calendar(きっとXamarin関連)はそういう内容にします。

そこで調べた内容をもとにどこかで話す機会があれば話せたらなぁとも思っています。

まとめ

どうまとめてもやっぱり参加してほんとによかったです。

特に主催の@atsushienoさん、レビューしてくださった@ailen0adaさん、一緒に技術書典3を仕上げてくださった執筆陣のみなさま、イベントの企画運営をしてくださったみなさま、足を運んでくださったみなさま、修正手伝ってくれた嫁氏、ありがとうございました!!

業務連絡

拝借します。
※情報が増えたら随時足します

booth