by ·1件のコメント

4/14（土）開催の技術書典6で2冊出展します！

カエルと空というサークル名で場所は「う46」です。ぜひ遊びに来てください！

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

『Knativeの歩き方 KubernetesからServerlessを訪ねて』

今回の新刊はKnativeについてです。KnativeはKubernetes上でサーバーレスなワークロードを実現するためのパーツ群です。

昨年9月に現職に転職してKubernetesを触り始めたことや、AWS LambdaをはじめとするFaaSやサーバーレスアーキテクチャに興味があり調べてみることにしました。

より詳細な動機はSeverless MeetupでKnativeの話をする機会をいただいた際にまとめています。

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

自分の大好きなLambdaを実装するための仕組みを学ぶのはとても面白く、今後も検証を続けていく予定です。増補・改定も伴うはず。

今回の本ではKnativeを構成するコンポーネントであるServing、Build、Eventingをサンプルを触りながら基本的な仕組みを理解できるように（自分が理解したい）という思いで書きました。

Knativeは鋭意開発中のため、入稿4日前にガラッと仕様が変わったのに気づいて慌てて一から勉強みたいなのも乗り越えてここまでやってきました。まさしく愛憎劇です。

Kubernetes上に成立つ仕組みなので、最低限Kubernetesの特徴として知っておきたいこともまとめています。

GKEを触りながらぜひKnativeの世界に入門してください！

本の名前はこんな気持ちでつけました。

ついでにこれは愛猫ふわふわくんの様子です。

目次です。

第1章 Knativeの概要
1.1 Knativeの構成要素
1.2 Serving
1.3 Build
1.4 Eventing

第2章 Kubernetes環境の準備

第3章 KubernetesとKnativeの関係
3.1 Kubernetesの基本的思想
3.2 Kubernetesのオートスケール
3.3 Kubernetesの拡張機能

第4章 Knative Serving
4.1 Knativeのインストール
4.1.1 Istioの設定
4.1.2 Knativeの設定
4.2 Configuration
4.3 Revison
4.4 Routes
4.5 Service
4.6 オートスケールの仕組み

第5章 Knative Build
5.1 Build
5.2 BuildTemplate
5.3 Servingと組み合わせる

第6章 Knative Eventing
6.1 Sources
6.2 BrokerとTrigger
6.3 ChannelとSubscription

お値段は前回に引き続きこんな感じです。

  • 最初の100冊は紙本 + ダウンロードカード: 1000円
  • あとはダウンロードカード: 1000円

実はすでにBOOTHで購入できる状態になっています。

https://toshi0607.booth.pm/items/1309468

当日会場に来れない方や今すぐに読みたい方、お待ちしてます！

『Goで学ぶAWS Lambda 第2版』

技術書典5で出展した既刊の第2版も50部持っていきます。

初版ではS3へのアップロードやログの確認でGUIに移動していましたが、諸々の準備によりコマンドで完結できるようになりましたw

更に、新刊に合わせて表紙も新しくなっています。嫁氏デザイン！

お値段は前回に引き続きこんな感じです。

  • 最初の50冊は紙本 + ダウンロードカード: 1000円
  • あとはダウンロードカード: 1000円

お陰様で商業版を出版したり、こちらもすでに第2版がBOOTHで購入できる状態になっています。

https://booth.pm/ja/items/1034858

GoとSAMで学ぶAWS Lambda

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

お願い

技術書を書くのは技術を身につけるためです。もし『Knativeの歩き方 KubernetesからServerlessを訪ねて』か『Goで学ぶAWS Lambda 第2版』を読んでフィードバックをくださるか宣伝（TwitterでBOOTHのリンク流してくださる程度で大丈夫です）していただける方がいらっしゃれば差し上げます。

ぜひお声がけください。

by ·1件のコメント

Serverless Meetup Tokyo #11お疲れ様でした！久々に登壇したのと、Serverless Meetupには勝手ながら思い入れがあるので振り返ります。

発表資料はこちらです。

登壇経緯

Serverless Frameworkのコアメンテナをやっている@horike37さんにお声がけいただいたのがきっかけでした。

Cloud FunctionsがGoをサポートしたのをきっかけに、サンプルを書いたり、それをテンプレートをServerless Frameworkに追加するPRを出したりしていました。

その辺を踏まえ、GCPのサーバーレス周りで話せることないか？と。（1月末）

ちょうど1月頭に（Kubernetesすら何もわからん状態だったけど）Knativeについて4月の技術書典6で書く予定だったのでKnativeの話させてください！！！と、申し出たらOKをいただきました。

テーマ選定

技術書典6含め、なぜKnativeについて調べようと思ったかにはいくつか理由があります。

みんな大好きLambda奴を自分で実装できるっぽい

AWS Lambdaが好きで技術書典5のテーマはまさしくGoで学ぶAWS Lambdaでした。

ユースケース的にまだまだ実装してないこともある一方で、サービスとしてどう実装されているかが気になったタイミングで登場したのがCustom AWS Lambda Runtimesでした。

これもしかして実装もわかるのでは？という期待を胸にすでにサポートされているGoで実装してみたものの、実態はランタイムのAPIクライアント奴でした。実装しなくても仕様ドキュメント見ればわかる。

そのとき書いた記事は鳴かず飛ばず感すごかったけど、今まで自分が書いた記事の中で一番好きです。

時は突然2018年の10月末のGCPUG Shonan vol.32 feat. Serverless & Knativeに遡ります。

ここでKnativeに出会いました。ようわからんけどk8sでサーバーレスできるんやーっていう印象はあったのと、k8s含め実装は公開されているので深めるにはもってこいというのとで調べてみることにしました。

Kubernetes詳しくならざるを得ない状況を作れる

Knative調べるぞ！みたいなモチベーションがあってもk8sの上に乗るものだし、トラフィックコントロール関連でIstioへの依存もあります。

仕事でGKE + gRPC + Goなマイクロサービス開発・運用していながらk8sちんぷんかんぷんでその上に（k8sはいったん忘れて）Knativeを調べるのは筋も効率もよくありません。

そういうわけでKnativeを進める前にk8sも調べる（基準曖昧）ことにしました。

登壇準備

Kubernetes

1月半ばから2月半ばまではk8s期間として本やソースコード読みました。

この本が最高で、仕事でk8s関連の知見をまとめる際にも秩序が生まれ始めました。（自分比）

Kubernetes完全ガイド

k8s source code reading #1に行ってみると上の本書いた人がいたり、k8sとKnativeの関係がわかったりしてよかったです。

それに関連し、k8sにしてもKnativeにしても、宣言的理想状態定義と、現在の状態と理想状態を調整するコントローラーの仕組みの理解は必須な中、よい記事を社の人に教えてもらえたのもよい出会いでした。

感極まって全訳PRを出しました。

Knative

2月前半に上のKuneretes本を読み終わり、Knativeのハンズオン、ドキュメント、記事などを漁りました。

よかったものは登壇資料の付録にまとめてます。

2月半ばにPivotalさんからKnative本が出たのは大きかったです。

3/2（土）、3（日）で資料準備を終えるはずが終わらず、3/5（火）に休みをとって仕上げました。

RAKU SPA 1010 神田のコワーキングスペースで資料終わらせて整えるかーと思い行ったまではよかったのですが、先に整えてしまい、しばらく薪を眺めるという失敗をおかしました。

先にやることやってから整えような！

突然のtips

準備の過程で海外カンファレンスのCFPにプロポーザルを出す気持ちを高めたり、CloudNative Days Tokyo 2019のCFPにプロポーザルを出したりしました。

CloudNative Days Tokyoは今選考中なので、もし興味ある方はいいねとリツイートで応援していただけると嬉しいです！

技術書典後の活動に大きく関わります。

登壇内容

特にKnativeの各コンポーネントについては口で補ったので資料だけではわかりづらい部分もあるとは思います。技術的な部分は技術書典6の本で書けたらいいなぁと思います。

Serverlessとは何か、KnativeのいうServerlessとは何か、みたいな話はせずKnativeが解決してくれることみたいな部分にフォーカスしたいという思いがあっての今回の構成です。

ただ、今回の構成でもKnativeが解決すると書いてることを厳密に区別すると、

  • KubernetesでもできなくはないけどKnativeでより便利になること
  • Kubernetes + CI/CDで実現できるけどKnativeでもっとKubernetes nativeに実現できること
  • Knativeで初めて実現できること
  • Knativeが拡張するIstioの機能

とかごっちゃになってる気がするんですが、そこには目をつむりました。

これから検証したり、実装を追ったりする人にとって大枠が掴めるものになればいいなぁと。

Kubernetesとの関係性にも入り込まず付録でCRD、Operatorにちょっと触れる程度にしましたが、技術書典6の方ではその辺ももう少しだけ書こうと思っています。

Severless Meetupへの思い

いつかSeverless Meetupで登壇したいなぁという思いがありました。

ServerlessConf Tokyo 2017に参加して心踊らせたり、前職でLambdaを本番導入したりしていた中での1つの目標です。

それ以来本や記事書いたり、ServerlessConf Tokyo 2018にも参加したり、Serverlessconf Tokyo 2018 Contributor DayでServerless Frameworkに初めてコントリビューションしたりの流れの中で実現できたことなので感慨深いものがあります。

ServerlessDaysも何か話したりハンズオン担当したり（？）、海外でも登壇できたらなぁと思っています。

どちらかというと登壇そのものというよりは、人に話したくなったり、話してフィードバックもらいたくなるような好きな技術に常に触れていられたら幸せという気持ちの方が強いです。

そういうハンズオンやContributor Dayも含め、好きになる可能性のある技術に触れたり、どっかの誰かがなんか言ってる技術が自分の身近な課題を解決できるものと感じられるようになる場を作るというのにも興味を持ち始めました。

自分の技術力や思いありきな前提で、これはこれで知見がいりそうですね。

振り返り

Good

社内公開とフィードバック獲得

社内のしかるべきと思われるチャンネルに貼ったらフィードバックや、どういう観点で検証したら社にとってもプラスになりそうかという示唆が得られてよかったです。

Eventとプロバイダー間の一貫性あたりはこの辺参考に考えるとよいとのことでした。

Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Services
(8. Functions and Event-Driven Processing)

1アウトプットにかける時間と粒度大きいのが増える一方で、小さめのもの（Qiitaで記事書くとかサンプルコード書くとか）が減ってる + 両立できないものでもないと思うので動き見せられたらなぁと思います。

完成する前に声に出して読む

最初Eventingを書いたところで16分くらいだろう（持ち時間は20分）と思って読んだら12分くらいだったので、完成に向けて進めるのに加えて時間収まらなさそうだから書かんでいいやって思ったのを足したらちょうどいいくらいになりました。

当日は付録の後半飛ばして20分30秒（付録飛ばせたけどイベント全体けっこう巻いてたので後半だけ飛ばした）。

Spaeker Deckに上げる（PDFにする）前提で変な作り方してるところがある分枚数多く見える（が実際1枚ページ送るだけ）部分があるのでそこはいい感じにつじつまが合うようにしたいものです。

Spaeker Deckで見たらURLクリックで飛べない（？）し、作るのはGoogleスライドだしで、もはやSpaeker Deckに上げずにGoogleスライドのURL公開すればいいのではって思いながらいくつもの季節が過ぎました。

（スライド全体が完成してから練習するのは大前提として）

Challgende

スライドのURL汚い

Speaker DeckのURL生成ルール的に原則タイトルベースで、それっぽく変えたいときはスラッシュの後ろに書く、みたいなの知ってる人増えてるはず。

こんな感じ。
入門 Knative 〜KubernetesとServerlessとの出会い〜 / getting started with knative

が、失敗してこうなりました。

h ttps://speakerdeck.com/toshi0607/getting-started-with-knative-90ff6190-1251-4b7b-ada9-bbba5a8ca4b8

一度
https://speakerdeck.com/toshi0607/getting-started-with-knative
で生成されたものの、PDFをアップロードした後にスライド処理が進まず、いったん削除して上げ直したら区別奴がついてしまいました。

結局時間がかかっても処理されるので放置するか、潔く別のURLになるように変えたりの方が意図通りのURLで公開できそうでした。

少なくとも発表ちょっと前にバタバタしながらアップロードするのやめよう。

検証少ない

去年の登壇では手を動かして作ったものについて発表をすることにこだわっていたものの、今回の発表に向けて手を動かしたのはハンズオンくらいでした。

発表までに残されていた時間と発表内容的に対して最適な手段だったとは思うものの、検証時間比率は増やします。

本出すにあたってはコードよりも原稿書かないとですが…両立できないものでもない。

まとめ

色々な思いが詰まったイベントを迎え、無事過ごすことができてよかったです。

技術書典6に向け原稿進めます。

by ·0件のコメント

このページでは『Goで学ぶAWS Lambda』の正誤表と増補・改訂をお知らせします。

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

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

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

正誤表

PDFページ 誤 正 PDF反映 ePub版反映 MOBI版反映 修正日
22 destBucket = os.Getenv("DEST_BUCKET") destBucket = os.Getenv("UNZIPPED_ARTIFACT_BUCKET") done done done 2018/10/16

増補・改訂

PDFページ 内容 PDF反映 ePub版反映 MOBI版反映 修正日
7 Go1.11.2へのバージョンアップ done done done 2018/11/18
30 利用可能なRuntimeの追加 done done done 2019/04/08
31 RetentionInDaysのリファレンス追加 done done done 2019/04/08
66 DynamoDB localを使ったテストの安定性向上 done done done 2019/04/08
全般 CloudWatch Logs確認にsawコマンドを利用 done done done 2019/04/08
全般 S3へのファイルアップロードにawsコマンドを利用 done done done 2019/04/08

リソース

by ·0件のコメント

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

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

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

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

謝辞

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

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

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

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

執筆環境として、TechBoosterさんのTechBooster/ReVIEW-Template、@atsushienoのatsushieno/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販売だけ行って紙本をもっていかないのも嫌です。

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

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

by ·0件のコメント

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でも頒布中です。

by ·0件のコメント

ちょっと前の話になりますが、4月〜5月にかけてメルペイさん主催のGopher道場#1に参加し、2回LTしました。

業務で1〜2週間Go言語を触ったときのなんとも言えない幸福な日々がきっかけでGoもっと書きたい学びたいと思い参加することにしました。

※Go触ってない他の日々が幸福でないとは言ってない

講義を聴き、次の講義が期限（？）の宿題を解きながら、うんうん完全に理解したと思っていたことがいざ手を動かしてみると理解できてないことを実感する、というのを繰り返しました。

Goで作り直すgitignore生成コマンド

宿題は指定仕様のCLIやサーバーを書くものもあれば、hogehoge interfaceの意義など説明する系のものもありました。

その中でio.Writerを調べていると、自分もそれ使って書きたいという気持ちが高まり書いたのがこちらです。

toshi0607/gig

generate (or output) .gitignore using github/gitignore

.gitignoreを生成するためのコマンドです。

Usage:
  gig [OPTIONS] [Language]

Application Options:
  -l, --list      Show list of available language
  -f, --File      Output .gitignore file
  -q, --quiet     Hide stdout
  -v, --version   Show version

Help Options:
  -h, --help      Show this help message

もともとgiboというシェルスクリプトベースのコマンドがあったのですが、

  • git cloneベースでなくて、毎回最新のファイルをgithub/gitignoreから取得したい
  • コマンド書いたことない（Gopher道場の選考課題で初めて書いた）のでGoで一から書いて配布するところまでやってみたい
  • io.Writer interfaceを活用した柔軟な出力差し替えを体験したい

という動機のもとで書きました。

まだ機能比較でもgiboに追いついてないのはありますが、どちらかというとｼｭｯとリリースするためのスクリプトを準備する方が時間がかかった気がします。

https://github.com/toshi0607/gig/tree/master/scripts

このあたりの組み合わせです。

Gopher道場の最終回でLTする時間をいただけたのでお話してきました。

Goのinterfaceを使って外部サービスに依存しないテストを書く

AWS Lambdaが好きなので、今度は何かAPI書いてみようということで書きました。

toshi0607/release-tweeter

API to tweet the latest release tag version using AWS Lambda(Golang) & API Gateway

コマンドをアップデートするときに、そのコマンドのGitHubリポジトリの最新タグを拾ってきてtwitterに投稿してくれると楽だなぁと。

いかにも既存の何かしらだったり、連携機能やサービスで実現されてそうですがその辺は気にせず…

テーマはAWS Lambda使うという大前提がありつつも、

  • API GatewayとAWS Lambdaをローカル実行する
  • SAMのCLI使ってデプロイしてみる
  • direnv使ってみる
  • 外部サービスに依存する部分はモックしてテスト書く

というのを試してみたかったのでそうしました。

その最後の1つについてGopher道場#1 LT大会でお話してきました。

このLTについてはつぎのようなツッコミをいただいてます。

  • 「差し替えたい対象が複数になったら困る」が正しいのであれば、関数使うのがアンチパターンになってしまい、全部interfaceにすればいいよね？ってなる
  • 処理の差し替えであれば関数でいいし、抽象として扱いたいのであればinterfaceにすればいい

処理の差し替えであれば関数でいいし、抽象として扱いたいのであればinterfaceにすればいい、大賛成です。

差し替え対象が複数になっても困りはしないと思いますが、もし差し替えたい処理が増えてバラバラ1つずつ入れ替えないといけない状況になったら依存するサービスごとinterfaceで抽象化してしまった方が見通しいいかもくらいのテンションで当日はお話していました。

ただ、タイトルを「結論」としてinterface使わない方法はよくないみたいな資料の流れになっているのは間違いないので、資料単体で見返したときにも誤解を生まないかという観点でも見直すなり、資料に表現しきれない部分も記事にするなり改善方法はあるなぁと反省しています。

コメントいただけるのはとても嬉しいです。

振り返り

コードを書く

Gopher道場の影響を大きく受け、これも作りたいあれも作りたいみたいな思いが沸くことが増え（？）GitHubの緑化が進みました。

READMEしか直してないみたいな日もありますが、「作りたい！」ありきでその中で試したいこと、テーマがあるくらいのテンションだと愛着も増すし、手も動くのでいい感じです。

コードを読む

（すでにあるかどうかを度外視して）そのとき作りたいものを作ると大体選考実装や要素技術の実装例はGitHubに転がっているので、個人開発の文脈で人のコードを意識的に読む時間が増えた気がします。

これまではtwitterなどで流れてきた人気リポジトリをなんとなくたどることが多かったですが、自分が知りたいことを探しながら追うと吸収度や感情の振れ幅が変わりました。

発信する

これまでMicrosoft系のコミュニティでしか話したことがなかったので、今年はその外で話すというのが隠れ目標でした。
https://speakerdeck.com/toshi0607

発信する内容としては自分が初めて対外LTしたときみたいに特定技術（サービス）の使い方をなぞる系はやりたくないと思っています。

やるメリットももちろんあると思いますが、技術力をつけるという観点では

  • 何かしらの課題を解決すること
  • 何かをテーマに作りきること

を最重視すべきと思っていて、その過程自体や困ったこと、うまくいったことの言語化・発表を通じより前進できると考えます。

5月に行った2つのLTはたとえ入門レベルの内容であったとしても、信念は貫いたのでよい経験をさせていただいたなぁと思っています。

次はgolang.tokyoで発表できるか？と言われたらとてもハードルを感じているのが正直なところなので作りたいもの作るなり、解決したい課題を解決するなり積み重ねていこうと思います。

次

「こんなことやりたいと思っている」を書くと、書いたことで満足してしまう節がなくはないですが追い込めもするので書いてみようと思います。

Serverlessconf Tokyo 2018

去年参加してとても楽しかったので今年も参加しようと思っています。

ただ、今年はLTしたいなぁと。

CFP受付中ですが、それは尻込みしています…

サーバーレスなアーキテクチャの認証・認可どうやればええねんって思っていて、追っかけてると楽しくなってきたのでその辺の話をする予定です。

もちろんサンプルコードはGoで！

技術書典

前回はレビューと当日の売り子だけ参加で多少寂しかったので、今度はしっかり書きたいなぁと思っています。

技術書典3の『Extensive Xamarin』は強い方々におんぶに抱っこ感がすごかったので、今度はサーバーレスシングルページアプリケーションチュートリアル的な感じで丸っと自分の力で書いてみたい！

rejectされてもnoteで販売するぞ！

by ·0件のコメント

2017/4/21のGlobal Azure Bootcamp 2018@Tokyoでお話してきました。

発表に使用したスライドはこちらです。

テーマ選定

スタンプカードアプリ作りたかった

妻が筋トレ（？）か何かをするにあたり、スタンプカードアプリ（別にアプリである必要はなかった）がほしい、スタンプはできれば猫がいい、みたいなことを言ってたのがきっかけの1つです。

※継続的に筋トレする習慣を作るのに必要なのは本当にスタンプカードなのかどうかはわからない

Durable FunctionのHuman Interactionパターン実装したかった

去年のServerless ConfかなにかでAzure Functionsの拡張機能であるDurable Fuctionsを知り、興味を持ちました。

中でもパターン #5: 人による操作に謎のロマンを感じ実装してみたくなりました。

一定以上のまとまりがあるコードが書きたかった

LTなり、何か記事を書くなり、技術系のアウトプットをするには技術的なインプットが必要と思っていますが、インプットの質を上げるためにももうちょっとアウトプットせねばという思いがありました。

しょうもなくてもいいからGitHubにひとまとまりのソースコードを上げられるだけコードを書くというのが今年の方針です。

振り返り

スライドでは主にコードについて書いてますが、もうちょっと取り組み全体寄りの振り返りです。

Good

  • クライアントもサーバもコードを書いてGitHubに上げたこと
  • 期待した動作をするアプリができたこと
  • Azure FunctionはHTTP Triggerを1回触る程度でよくわかってなかったけど、全体的なお作法をざっと見た上でDurable Fucntionsのキャッチアップに入れたこと
  • Durable Fucntionsの実行の仕組みもなんとなく把握できる程度にデバッグ実行したりストレージの中身のぞいたり研究できたこと
  • PaaSの組み合わせ方にもデザインパターンがあり、実装するからこそそのありがたみを感じられることを実感できたこと

Challenge

  • 声出すの、歌とかでなくてもほんとに音にならなくてつらい
  • 全部喋らんけど資料になるから資料厚くしよう、そして喋るときはいろいろ飛ばそう、はまだ自分には早そう
    • （練習した後）ギリギリまで資料を変えて本番に臨むとわりと混乱して大事などころだけ絞って喋るって緊張してると難しい。今回は資料アップロードした後もここ表現こうした方がいいとか、順番はやっぱこういう方がいいとか10回くらい直してアップロードし直した
  • 実装的にあれも足りないこれも足りないとウジウジしてないで学びたいことを学ぶためのサンプルと割り切ること
    • 足りないと思う部分はissueとかで残しとくともっと深めようとか現実的に稼働させたいとか思ったときに役立つかも
  • 一方で個人的に本番運用するプロダクトがあってもよいなぁ
    • クラウドリソースの認証・認可さすがにザルすぎる
  • ログの追い方は「とりあえずサンプル1つ動いた」の次の段階くらいで意識的に時間とって把握するのがよさそう
    • 今回くらいの規模のサンプルでも途中デプロイすることがあったり、単にブレークポイントはる以外にログきちんと追いたい局面が多々あった
  • Azure FunctionsがV1ベース
    • V2でやろうとするとnugetからのインストールからうまくいかなくて、古めのバージョンでうまくいく組みわせでやり過ごしてしまった感
  • 実行の仕組みの研究とか言うわりに「どう実装されているか」をコード見ながら考えてない。動きからテキトー想像する「だけ」は研究とは言わない
  • UI苦手やぁ
    • よくあるアプリのパーツ実装してみるとか、作りたいと思ってるものに沿った形で取り入れてみるのはやった方が表現の幅が広がっていきそう

まとめ

総じて取り組んでよかったなぁと思います。

需要があるかはおいておいて、今回のスライドでも20分くらいじっくり喋りたかった内容だったりするので機会があればリベンジしたいなぁと思いました。

あと、今回みたいなアーキテクチャでデータの整合性はどうすると保てるのかだったり、クラウドアーキテクチャの原則は何なのかだったり、もっと踏み込んで学んだら楽しそうな分野に出会えてよかったです。

クラス設計もデザインパターンからでなく、その前提となる原則やそれを実現するための具体的なコード（の変化）を追うととても実感がわきました。

今ではクラウド設計の原則的なことも整理が進んでいると思うので、追ってけたらなぁと思いました。

勉強会ではこのセッションが特に印象的でした。

by ·0件のコメント

技術書典3

以前このブログでも紹介した、技術書典3で出展・販売に携わった『Extensive Xamarin』という技術同人誌が3月に商業出版されました。

『Essential Xamarin』同様インプレスさんのNextPublishingからです。

Extensive Xamarin　─ひろがるXamarinの世界─ Essential Xamarinシリーズ

Essential Xamarin　ネイティブからクロスプラットフォームまで モバイル.NETの世界

会社でも同僚が紹介記事書いてくれたのすごいうれしかったなぁ...
弊社エンジニアが共著で参加した Xamarin の技術書が発売されます

Aamazonで自分の名前を検索したら本が出てくる一定の感慨深さはありますが、『Essential Xamarin』がとても好きですし、この本の商業出版化様々という気持ちです。

あとは以前の記事のとおり、「いつか書けたらいいなぁ、で逃げなくてほんとによかったです。」がすべてで、技術書典3は去年一番の思い出かもしれないということに尽きます。

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

技術書典4

自分では何も書いていないですが、一足先に読ませていただいたこともあり、当日は新刊の売り子をやります。

新刊の内容はMonoDevelopとXamarin.iOSについてです。

MonoDevelop

以前仕事でもVisual Studio for Macを使っていたにもかかわらずOSS的な部分とプロプラエタリな部分でどういう風に構成されているのか、自分で拡張するためにはどうすればいいのかの手がかりが掴める内容になっていて感動しました。

ただ、MonoDevelopに限らずIDEやそれに準ずるものがどういう取り決めで本体とデバッガ間で通信するのかなど他のIDEでも共通して考えれるヒントが惜しげも無く散りばめられている貴重な内容になっています。

Xamarin.iOS

なんとなく書いていたらハマるだろう（ハマっていることにすら気づけない自分みたいなパターンもけっこうありそう）現象の原因と対策がサンプルコードとともに丁寧にまとめられています。

ネイティヴなコードをXamarinでラップすることでどう表現が変わるのか、.NETな表現をするためにXamarinが何をやっているのかの解説はただただ鮮やかです。

どっちもほんとにすごいんです！！（こなみ）

えのもとさんの記事
技術書典4新刊によせて

by ·0件のコメント

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

by ·0件のコメント

2017/10/7の .NET Conf 2017 Tokyo, Japan でお話して来ました。

発表に使用したスライドはこちらです。

下記について書いていきます。

  • 登壇のきっかけ
  • テーマ選定の理由
  • 準備
  • 振り返り
  • お知らせ
  • おまけ

登壇のきっかけ

Microsoftの方からXamarinについて登壇してみませんか？というお話をいただいたのがきっかけです。

Xamarinのユーザーグループには登壇してくれそうな人はいるものの、今回は普段あまり喋ったことない人がよいということでお声がけいただいたようです。

聴衆として参加登録はしており、「セッションは公募」というのを見たときは「さすがにこれまで5分しか喋ったことないし、いつかは喋ってみたいけどさすがに長時間（まだセッションの尺も掲載されていなかったので雰囲気）は無理やなぁ」くらいに思っていました。

お声がけいただいてもこの状況や思いは変わらなかったのですがw、ひとしきり周囲の人（たまたま家族旅行中で沖縄にいました…！）ときゃーきゃー騒いだあと、いつものようにネタは何も決まってないけどとりあえず引き受けることにしました。

たぶんいつかやりたいそのいつかも「はいはい45分セッションね？あれとあれとあれ話すから余裕ですよ！やりますよ！」みたいな状態ではないので、この機会逃すのは勿体なすぎる！

テーマ選定の理由

引き受けたものの、Xamarinに詳しいわけではないので、 準備しながら勉強したい、といういか勉強するプロセス自体がテーマにならないかなぁ？と思いました。

  • 体系的に勉強したい（学ぶべき領域整理されててほしいという甘え）
  • 45分という自分にとっては未知な時間を「埋め」やすい

というのを考えたとき、Xamarinの技術書の話をしようと思いました。

技術書にはある程度体系的（深くなくていいから網羅しててほしい）な知識が期待できるし、記憶ではこの1年でたくさん本が出ているので「m分 × n冊」みたいに時間も把握しやすいかなぁと。

そういうわけで、お声がけいただいたその日にXamarin本をテーマにすることに決めました。

5分のLTでも1ヶ月前から準備するタイプなので、本番3週間前スタートだと悩まず進み切るしかないのです…！

準備

本の数を把握する

本の話をするということで、まずはAmazonで「Xamarin」を検索しました。

ここ1年の日本語技術書は8冊。

本番2日前に発売されるものはスルー（しようと思っていましたが買えたので触れました）するとして、読めなくは無さそうです。

去年のスライドを眺める

ちょまどさんが当日の雰囲気や登壇者のスライドをまとめてくれいていて助かりました。

dotnetConf Japan 2016 で登壇してきました！

資料の枚数などを参考にしようと思いましたが、きっとそれぞれ芸風が異なりそうだったので一通り読んでそっ閉じしました。

本を買う、読む

すぐ読み始めたいものはKindleで買い、ある程度業務に関連あれば会社で買ってもらえるので他は購入申請しました。

既に買って読んでいるものもありました。

スライド作成

本を読むのにそれなりに時間がかかったのと、タイミングがいろいろと重なってしまったのとで10/3から当日（10/7）の朝に作成しました。

本を読んだ感想を念頭に構成だけ文字にしてスライド作成していくものの、意外と流れが作れなくて悩んでいる時間が多かったです。

「本を見ていく「基準」を提示して、その基準に各本を当てはめ、最後に傾向と感想を述べる」という大まかな流れの中で、突然本が出てきても流れがよくわからないし、基準の粒度が荒すぎると特徴を見出せないし、細かすぎると自分がわからなくなるしで最終的に資料のような形で腑に落ちたのは当日の朝でした。

練習

無事資料の作成が終わってスライドの枚数は60枚と少し。

いざ練習してみて、余るなら削ろうくらいの気持ちでいたら42分。

狙ってそうなったものでもなく、気持ちゆっくり目に話せばちょうど時間くらいで運よかったなぁ…という感じでした。

練習中に嫁氏が校閲してくれたときにいくつか誤字見つかったので感謝感謝でした。

振り返り

振り返ります。そういう芸風なので…。

Good

引き受けたこと

これは間違いなくよかったです。

準備期間は瀕死状態が続きましたが、そうやって大きくなっていくんです。（てきとう）

テーマ選定

自分が向き合うべきテーマだったのが何よりもよかったです。

前回のXamarin関連のLTではテーマが曖昧過ぎてちょっとアレだったという反省がありました。

XamarinのLT大会で「LottieXamarinで始めるXamarinアプリのアニメーション」を話してきました #jxug

今回はLTのタイトルとは別に「Xamarinやりたいけどよくわからんので、まずは広く見渡して知識を整理する、サンプルアプリで手もできる限り動かす」というテーマをおいて取り組んだので、目的がある程度果たせたのもよかったです。

内容（Xamarin本の整理）自体も、もし自分がやらなかったら他で企画があったかもしれない（関心がある人がいそう）ものだったようでよかったです。

（企画のネタの目を摘んでしまっていたら事故としか言いようがないですね…）

セッション終了後も本の紹介でちょうど困ってたところでよかった等コメントいただけて嬉しかったです。

セッション2日前発売の本にも触れたこと

たまたま入手できたからという側面はありますが、この本の内容自体が価値あるものだったので少し無理してでも触れることができたのはよかったです。

ただ、反省としてはこの本についてはパラパラ目を通したくらいなので、フェアな比較にはできてなさそうなことです。

これからサンプルも手を動かして追って、印象が変わったり事実と異なる扱いになってしまっていたりしたらスライドを修正します。

Challenge

誰向けのセッションなんや

僕は初心者なので初心者向けのセッションしかできないはずですが、初心者向けセッションなら「Xamarinアプリ開発に必要そうな知識」をもう少し整理？わかりやすく話す？　などできればよかったかなぁと思いました。

本を評価していく「基準」なので、伝えられなければ前提が崩れてしまう…。

それか「どんなときXamarin使いたくなると思いますか？」じゃなくて、「Xamarin使ったことありますか？」「なんで使いましたか？」みたいに経験の有無やどういう説明必要か（はしょっていいか）確認したり、セッションの前に告知するとかしておくとよいのかなぁと思いました。

何はともあれ、自分が詳しくないと話すレベルの調整もできないので、詳しくなるところからです。

スライドが文字文字しい

自信の無いことの表れ…という側面と、発表するというか後から読める資料にしたいという側面どちらもあった気がします。

文字ばっかりのスライド見たくないですよね？書いていることをそのまま喋るだけならブログとかでええやんという感じです。

スライド自体は文字減らすか図にするかして、詳しく話ができる程度に準備するのがよさそうです。

また、サンプルアプリがついている本が大半だったので、その本で出来上がるアプリのGIFとか貼っときたかったです。

途中までGIFを準備しながらやっていたのですが、時間が足りなさそうで断念しました。

機材

USB-CとHDMIのコネクタを会社に忘れたのと、持参したUSB-CとVGAのコネクタが動作しませんでした。

Xamarin.Macの人に助けてもらいました。

純正奴買います。

こんなんなんかぁ…。

あと、ひらりんさんのブログ記事に触発されて本番直前に買ってはみたものの、余裕（論理／物理）がなかったので諦めましたw

Logicool ロジクール R1000SL 充電式 プレゼンテーションリモート スレート

posted with カエレバ
ロジクール 2017-03-22

発表中ずっとPCの画面見ていて発表っぽくないので、しゃべり方も変えてけたらなぁと思います。

お知らせ

発表でも触れましたが、技術書3で出展・販売されるXamarinの同人誌の1章分（Xamarin.Macアプリケーションの配布方法）を担当させていただきました。

技術書典3 出展情報 - Xamaritans

当日はブースにもいる予定なので、ぜひ遊びに来てください！

おまけ

5000兆年ぶりにTogetterで当日の自分のセッションやスライド関連のものをまとめてみました。

あと、動画撮っていただいてないと思ってたのですが記念に置いておきますw

まだ全部見てないのに、「まぁ」と「というところで」何回言うねんという喋りになっています。改善ポイントいっぱいですね。

運営のみなさま、聴いてくださったみなさま、資料見てくださったみなさまありがとうございました！

無事終わってほんとによかったーーーーーー