プログラマでありたい

おっさんになっても、プログラマでありつづけたい

Kindle本の販売という実績解除しました

 2016年から目標として掲げ続けてきた、Kindle本の販売という目標を2020年3月15日にようやく達成しました。

AWSの薄い本 IAMのマニアックな話

AWSの薄い本 IAMのマニアックな話

IAMのマニアックな話とEPUB

 Kindleで販売を開始した本は、昨年執筆しBOOTHで販売していた『AWSの薄い本 IAMのマニアックな話』です。この本は、Re:VIEWという紙書籍・電子書籍作成支援ツールを利用していて、PDFだけでなくEPUB形式でも出力可能でした。なので、執筆している当時は、BOOTHと同時にKindleでも販売開始しようとしていました。が、出来上がったEPUB版をみて、販売を見合わせていました。

 書籍を作成する場合、図の位置であったり内容に合わせて改ページを考えます。しかし、一般的なEPUBは、リフロー型といって画面や文字サイズに合わせて、テキストやレイアウトが変わります。電子書籍のメリットの一つですが、その反面、意図を込めて配置した図や改ページが無視されます。実際、EPUBでデフォルトで表示してみたら、読めたものではなかったです。

 出版社から出した自分の本が、画像による固定レイアウトにしていることについて、常々文句を言っていました。が、いざ自分で出すとなると、リフロー型の問題点を認識できるようになりました。

リフロー型と固定レイアウトのジレンマ

 読者にすると執筆者の意図を込めたレイアウトより、自分に自由に設定できるリフロー型の方がメリットある場合が多いです。画像による固定レイアウトの場合、検索もできなければハイライト等もできません。検索できない技術書なんてと思いますよね。私も、そう思っています。でも、Amazonに出す場合は、リフローで出すのが怖いのですよ。
 Amazonで出す場合、レビューが非常に重要になります。レビューでは内容そのものだけでなく、レイアウトであったり値段や本の対象とするする読者層に関係なくレベルまで含まれます。ex)私には簡単すぎた or 難しすぎた 果ては物理本の場合は、紙質まで言及されることがあります。そんな中でリフロー型で出すのは、恐怖があります。
 今回、Kindleで販売するにあたっては、画像化による固定レイアウトで販売しました。その代わり、BOOTHではKindleより200円安くした上で、PDF版と固定レイアウトのEPUBとリフロー型のEPUBの3つをダウンロード可能として優遇しています。本当は、Amazonでもこのような形で販売したいのですが、現状はできません。

Kindleで売る意味

 それではBOOTHをメインにしているのに、Kindleで売る意味は何があるのでしょうか?実は、そこを模索中です。BOOTHに比べてAmazonの方が圧倒的にリーチする層は多いです。一方で、当初想定していた以上にBOOTHでも売れつづけているのです。そこでしか買えないのであれば、ちゃんと買ってくれるというのが解りました。ただ、その上でKindleで発売したらどうなるのか試してみたいというのが今回の販売開始の意図です。まだ始めたばかりなので、試行錯誤中ですが、ある程度解ったらまたブログで報告します。

AWSの薄い本 IAMのマニアックな話

AWSの薄い本 IAMのマニアックな話

 BOOTHでは、2冊セットや5冊・10冊セットとバリエーション揃えています。社内で利用すると言った場合は、こちらもご検討ください。

booth.pm

IAM本こと『AWSの薄い本 IAMのマニアックな話』の物理本、販売中です #技術書典

Twitterで告知はしているのですが、ブログの方でも改めて告知です。
技術書典8向けに用意していた『AWSの薄い本 IAMのマニアックな話』の物理本、ただいまBOOTHで販売中です。

f:id:dkfj:20200314171352j:plain

入庫作業に時間が掛かっているので、自宅から注文のたびに1冊1冊私が梱包してファミリーマートから発送しています。また、自宅から発送なので商品バリエーションの自由度があるということに気がついて、2冊セットや5冊セット、10冊セットなども用意しています。

takuros.booth.pm


そういったバリエーションを用意しておいて何ですが、ポツポツと2冊セットや5冊セットが本当に売れているのですね。どういった人が買っているのか、気になります。商品に対してリクエストがあれば検討しますので、お気軽にお問い合わせください。

技術書典 応援祭に参加します

新型コロナの影響で、残念ながら技術書典8は中止となりました。しかし、オンラインで技術書典 応援祭が開催されるということで、サークルとして参加します。今回はチームになったササキですということで複数人で新刊を出します。既にBoothでの販売開始していますが、ここで一挙に紹介します。

クラウドネイティブファーストストーリー

f:id:dkfj:20200129021551j:plain

 1冊目は、新井さん(@msy78)と馬勝さん(@HorseVictory)さんの共著であるクラウドネイティブファーストストーリーです。この本は題名のとおり、ECSやFargate、Code兄弟を使ったサクセスストーリです。初級者から中級者向けに、クラウドの利点を最大限に活かすクラウドネイティブってどういう感じでやるのというのを、コンテナを中心に紹介しています。Lift & ShiftでいうとShiftの方ですね。
 特徴としては、前半でコンテナ(ECS, Fargate)の使い方と構築例を紹介した後に、CI/CDを使った運用の話までしていることです。実際にコンテナ運用をしている方はご存知だと思いますが、コンテナ運用にはビルドやデプロイなどのパイプラインが不可欠です。AWSにはCode兄弟と呼ばれるCodeCommit(リポジトリ)、CodeBuild(ビルド環境)、CodeDeploy(デプロイツール)、CodePipeline(パイプライン)のサービスがあります。その辺りを使ってのコンテナ構築からデプロイまでの一連の流れができるようになっています。

表紙も素敵ですが、裏表紙もとっても可愛いので、ぜひ現物をみてください。物理本も販売しています。

booth.pm

AWSを使って学ぶ 監視設計

f:id:dkfj:20200305233640j:plain

 2冊目は佐藤さん(@tenbo07)による『AWSを使って学ぶ 監視設計』です。この本のテーマは、ずばり監視設計です。AWSを使って学ぶとついているように、AWSでの設定例を使っていますが、あくまで監視の設計の仕方がメインのテーマです。そのため、AWS利用者以外が読んでも参考になるのではないでしょうか。
 また単純に監視の実務的な設計手法ではなく、どのように考えて設計するのかという道筋が紹介されています。Googleが提唱するSite Reliability Engineeringに基づき、運用においてSLI(サービルレベル指標)とSLO(サービルレベル目標)をどのように設定するのか、またそれを設定に落とし込むにはどうするのか丁寧に解説されています。
 また単純にシステムの監視にとどまらず、パイプラインの監視といったように、監視すべき対象の広がりを紹介し具体的に解説しています。クラウドネイティブファーストストーリーでビルドパイプラインを構築したら、この本を読んでそのパイプラインの監視をしてみましょう。それ以外にもダッシュボードの設計をどうするのかとか、色々参考になりました。確かにダッシュボードは適当に配置すると色々な指標が表示されますが、どういう考えに基づいて表示させればよいか、なかなか解りませんよね。
 ということで、国内有数といってよい大規模なシステムを運用してきた佐藤さんの血肉を分けた1冊です。

booth.pm

認証サービスCognito・Auth0・Firebaseを比べる

f:id:dkfj:20200305233734j:plain

 3冊目が高柳さん(@yanayanalte)による『認証サービスCognito・Auth0・Firebaseを比べる』です。これもタイトルどおりにストレートに認証サービスであるCognitoとAuth0とFirebaseを比較しています。本当にストレートなタイトルで、他に何かなかったのかという気はしますが、どんな内容なのか解りやすいのでこれがベストだったのでしょう。
 ユーザーID管理とは何かという話からはいって、各サービスの概要、コスト比較、管理・運用面や開発面での比較がされています。また導入する際に移行どうするかとことにも軽く言及されています。現実に悩むのはここですよね。

booth.pm

IAM本とその続き

 最後に私が書いた本ですが、まだ未完成です。サークル主だけ原稿落としているサークルってどうなんよと小一時間、問い詰められたい気持ちで一杯です。技術書典8の中止が決まり、気が抜けて完成させられませんでした。3月中には何とかします。代わりと言っては何ですが、IAM本こと『AWSの薄い本 IAMのマニアックな話』の紙版を増刷しました。予定通り500部刷ったので、たくさんあります。Boothに入庫は時間がかかるので、現在自宅から温かみのあるデプロイを実施中です。注文が入ると1冊づつ丁寧に梱包されて出荷しています。私の指紋等、ベタベタとついていると思うので、採取して悪用しないようにお願い致します。

booth.pm

まとめ

サークルの仲間が書いた本、どれもテーマがハッキリしていて面白いと思います。興味をもったら、ぜひご購入をお願い致します!!あと、原稿落として、本当にすいません。現在もちゃんと書いているので、今暫くお待ち下さい。

技術書典8(初日2/29)に出展します #技術書典

Twitterでつぶやいておりましたが、2/29,3/1に池袋で開催される技術書典8に出展します。前回の技術書典7で大好評だった『AWSの薄い本 IAMのマニアックな話』の続刊として、『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』を出します。
f:id:dkfj:20200129020844j:plain


そして今回は、私一人ではなくサークルとして複数人で参加し、それぞれが執筆します。ということで、私の新刊1冊を含め一挙4冊の新刊を発表します。ということで、執筆者と書籍の紹介です。

クラウドネイティブファーストストーリー

コンテナとBlue Greenデプロイ、DevOpsについて一日中喋り続けられる新井さんと、ボイスUI本の作者でありAlexaマスターの馬勝さんによるコンテナ&DevOps本です。

f:id:dkfj:20200129021551j:plain

概要:

クラウドネイティブを支える技術である「コンテナ」と「CI/CD(継続的インテグレーション/継続的デリバリー)」を中心トピックにご紹介します。本書を通して、自分達が過去に悩んだ点、躓いた点、気をつけなければならない点などをシェアすることで、クラウドネイティブなアプリケーションの開発を考えている方々に最初の一歩をお手伝いしたい、という想いから執筆しました。
本書は、AWSのECS/Fargate/Codeシリーズなどの各種サービスを組み合わせていくことで、コンテナやCI/CDのベース環境の構築を行うハンズオン形式で構成しています。アプリケーション観点というよりは、インフラストラクチャーや運用観点にトピックの主軸を置いています。
中級者にも満足してもらうために、ハンズオン内には随所に構築に役立つTipsや補足情報なども記載していますので、是非、Tipsを探して読んでみてください。

対象読者:

  • AWSでコンテナ・CI/CDを使ったことがなくチャレンジしてみたい方
  • AWSでコンテナ・CI/CDの構築に苦戦している方
  • コンテナ・CI/CDに関して、初心者から中級者にステップアップしたい方

技術者としてメチャクチャ濃い二人の共著です。飲みに行っても、俺のデプロイ方法を聞けとずっと語っている二人です。そんな二人の熱い思いがこもった一冊です。
ちなみに表紙の動物は名前からとって、アライグマと馬とのことです。かわいい表紙にハードコアな内容のギャップに期待!!

CognitoとAuth0とFirebase認証を比べる

Amazon Web Services クラウドネイティブ・アプリケーション開発技法の共著者である高柳さんは、Webシステムを実装する上で、認証をどうするか。それの実装であるメジャーなサービスの比較です。

概要:

ユーザーのIDを管理するのはWebサービスを展開する上で必要になりますが、独自で実装するにはハードルが高いです。外部のサービスを利用することでユーザーのサインアップとサインインを比較的簡単に実現できます。この本ではCognito User Pools、Auth0、Firebase Authenticationを中心にサービスの紹介と比較をします。

f:id:dkfj:20200129021605p:plain

高柳さんは、モバイルアプリやサーバレスアーキテクチャを中心に取り組んでおり、最近は何の因果かひたすらシステムの認証認可周りの担当をしています。そんな経験がギュッと詰まった一冊になると思います。

AWSを通じて、とにかくモニタリング(監視)を考える本

同じくAmazon Web Services パターン別構築・運用ガイドAmazon Web Services クラウドネイティブ・アプリケーション開発技法の共著者である佐藤さんは、モニタリングの話です。なんかエモい話が聞けそうです。

概要:

2020年になり、2010年代が終わりました。2010年代はクラウドやコンテナが発展とともに、「モニタリング(監視)」の形も大きく変わったと思います。この本は、「モニタリング(監視)」というテーマについて、CloudWatchを中心にAWSの各サービス見ながら、今何を監視すべきなのか、どのように行うべきかを著者の経験を基に考えて行く本です。
また、本来技術書であれば、客観的に事実や理論を記述していくと思いますが、今回は同人誌という形でもあるので、普段私が監視について考えていることをなるべく主観を交えてありのまま書いて行きたいと思います。そして、所々この10年を振り返りつつ記述していきますので、ある意味「2010年代を生きたエンジニアが残したサーバー監視にまつわる手記」のようなものと思って楽しんでいただければ幸いです。

対象読者:

  • 普段なんとなく監視を行っている人
  • 他の現場のエンジニアがどのように監視を考えているか気になる人
  • AWSを触り始めたが、どのように監視を設計していけばいいかわからない人

f:id:dkfj:20200129021618p:plain

ユーザー企業で働く佐藤さん。大規模なAWS運用を支えてきた実績にもとづくポエムが期待です。

pages.awscloud.com

まとめ

 自分で言うのも何ですが、かなり濃いメンバー集めての出展です。締め切り近づいているのに、全然執筆の時間が取れず焦っておりますが、なんとかやりとげます。ぜひ、当日お会いいたしましょう!!初日(2/29)の『い20』です
f:id:dkfj:20200129100422p:plain

なお、BOOTHの紙版で品切れ中であるIAM本も増刷します。紙の本が欲しいよという方は、ぜひBOOTHに起こしてください。オンライン版を既に購入済みの方には、何らか安売りの方法検討します。
booth.pm

サークルページはこちらなので、ぜひチェックをお願いします。刷り部数に影響します!!
techbookfest.org

『AWSの薄い本 IAMのマニアックな話』の輪読会に参加してきました

 エゴサーチが趣味なので、『AWSの薄い本 IAMのマニアックな話』の輪読会が開催されることを知りました。参加してよいか暫く逡巡しましたが、属性縛りが無かったので参加させて頂くことにしました。

weeyble-infrastructure.connpass.com

どんな輪読会だったのか?

秋葉原にあるコワーキングスペース Weeyble(ウィーブル)さんで開催されていました。コワーキングスペースがサポートして、その中の利用者が有志で始めている輪読会のようです。インフラ系の輪読会が多く、過去にはAWSパターン別構築・運用ガイドも開催されてた模様です。

輪読会のスタイルとしては、読んでこられた方がスライドを作っていたので、それを元に章ごとのサマリーと重要な項目のディスカッションをするというスタイルでした。2時間弱の時間でしたが、かなり効率よく知識をインプットできるスタイルでした。

参加してどうだったのか?

IAM本の著者なので、参加してうざがられるか心配しておりました。輪読会のSlackに事前に登録して、著者である旨を宣言した上で何食わぬ顔で参加させて頂きました。


発表者の方は、最初はものすごく話しづらそうだったのが印象的でした。申し訳なかった。でも、すぐに慣れて、私もディスカッションに参加したり、記述する内容について質問を受けたりできました。読者層の興味範囲が解って、なかなか貴重な時間でした。あとIAMロールの概念を説明するの、やっぱり難しいですね。

どんな話題がでた?

IAMに興味があるということで、マルチアカウントも視野に入れている方がちらほらいました。、OrganizationのSCP(Service Control Policy)についての関心はやはり高く、次の本ではまだ中心として取り上げない予定と話すと心底がっかりされました。夏までにがんばりますので、お許しください。後はControl Towerは良さげだけど、ちょっと敷居が高いという話も挙がっていました。この辺りは、2月末で出す本で解説する予定です。

感想

わりとドキドキしながら参加しましたが、行って良かったです。書いた本でどの辺りが解りにくいのか、或いはニーズがあったのかなどは、ダイレクトに知る機会はなかなか少ないです。また機会があったら参加したいと思います。地方でも良いので、もし開催予定がありましたら、お気軽にお声がけください。都合つけば参加させて頂きます。

booth.pm

APN Ambassadorとして参加したre:Inventの感想

 2019年12月にラスベガスで開催されたre:Inventに参加していました。2015年、2016年、2018年に続いて4回目です。そしていつもとの違いとしては、Ambassadorとしての参加だったということです。この辺りの感想を残してみます。帰国後すぐに書いてたのですが、下書きに埋もれてたのでサルベージです。エモい話系です

アンバサダーとは?

 知らない人も多いと思うので、APN Ambassadorの制度の紹介を最初にしておきます。AWSさん曰く、アンバサダーは
『APN Ambassadorは、世界中のAPN Consulting Partnerから卓越した技術力を持ち、社外への情報発信(セミナーでの発信、Blogや書籍での発信)をしているメンバーが選出されます。』とのことです。私の場合は、会社内でもAWS関係のビジネスの責任者でもありますし、書籍出版などもしておりますので、その辺りが評価されたのかなと思っています。

 選ばれた経緯等は下記のエントリーで紹介しているので、興味がある方は読んでください。
blog.takuros.net

アンバサダー特典

 アンバサダー特典については、どこまでが守秘義務の範囲か定かではないので詳細は書きません。が、主たるものとしては、自分を含めた所属する組織が、よりAWSを学べるように優先的に機会を与えられるといったものと理解しています。もう少しだけ具体的に話すと、AWSのそれぞれの担当者とディスカッションの機会が増えます。そこで要望等をダイレクトに伝えられるようになります。
 それ以外に外形的なものとしては、re:Inventのキーノートでアンバサダー向けの予約席があったりします。朝早く起きなくても、前の席に座れるので楽ちんです。

f:id:dkfj:20191206010831j:plain

アンバサダーは特典を与えるものではない

 上記がアンバサダーの特典なのですが、前回のre:Inventに参加して、特典を与えられることに満足していては勿体無いということに気が付きました。アンバサダーであれば、何かアクションをする機会を格段に得やすくなります。先述のAWSとの打ち合わせの機会もそうですが、外部への登壇等も同じです。アンバサダーという箔があるので、外部との調整が格段にしやすくなります。○○という施策(イベント・ミーティング・その他)が必要なので、やってみませんかという調整がしやすくなります。それこそ当社比100%程。
 せっかくアンバサダーになったので、それを使ってアグレッシブに活動しないと勿体無いということですね。

今後の活動

 AWSのアンバサダー担当の相澤さんからは、常に「Go Globalの精神で、世界に進出していってください」と言われています。前回のre:Inventでその言葉が意味することを、少し垣間見れたような気がします。やらなきゃなという気持ちになったので、あとは自分の得意とすることでGo Globalします。

AWSのアカウントセキュリティ

 いま技術書典8に向けてAWSのアカウントセキュリティをテーマに執筆中です。(進捗1%)
執筆の元ネタと告知を兼ねて、私がAWSのセキュリティをどう捉えているか紹介します。

AWSのセキュリティの3要素

AWSのセキュリティをざっくり分類してと、次の3つで考えるのが良いと思います。

  • AWS上に構築するシステムのセキュリティ
  • AWSアカウント自体の管理(≒IAMの設計・運用)
  • AWSアカウントのガードレール設計

f:id:dkfj:20200108200235p:plain

 AWS上に構築するシステムのセキュリティについては、ネットワークであったりEC2やRDSなどを利用して構築したサーバ・ミドル・アプリなどがあります。マネージドサービスというAWSならではの要素がありますが、基本的な考え方は従来のオンプレと大きく変わらないと思っています。システムとして穴がない状態を、AWSを使ってどうやって実現するのかという問題です。
 次にAWSアカウント自体の管理です。これはほぼIAMの設計・運用に依存する部分が多いです。こちらについては技術書典7で発表した『AWSの薄い本 IAMのマニアックな話』の中心テーマです。ここでは割愛します。
 最後のAWSアカウントのガードレール設計。この言葉だけ読んでもピンとこない人が大半だと思います。IAMの設計はAWSアカウントのセキュリティの大部分を担いますが、運用しているうちに抜け漏れが出てきたり、あるいはカバーしきれない部分があったりします。またAWSアカウントが適切な状態で運用されているのか、或いは危険な状態にあるのか可視化していないと適切な判断ができません。それらの予防・検知するための施策が、ガードレール設計です。

 今書こうとしている本は、この3つ目のAWSアカウントのガードレール設計をメインのテーマとしています。

AWSアカウントセキュリティとマルチアカウント管理

 そもそもこのガードレール設計というのがどこから来ているかというと、AWS Control Towerです。このサービスは、複数アカウント環境をセキュアに設定、管理するためのサービスです。これ使えよという話ではあるのですが、現状では新規のアカウント対象かつマルチアカウント前提という形になります。AWSのアカウントセキュリティは万人が必要だと思うものの、この前提だと敷居が高いのも事実です。ですので、Control Towerの機能の中心にあるガードレールやランディングゾーンを紐解いて、AWSアカウントのセキュリティを保つためには何が必要で、どういう設計・設定をすればよいのかを抽出しようと思います。その考え方を用いて、1アカウントにも適用できるようにパターン化を目指しています。

 一方で、マルチアカウント管理のニーズも高く、どうすればよいのかまとめる必要もあります。分量も多くなることもあり、かつ私のリソースも足りないので技術書典8ではすっぱり諦めます。その次のテーマとして必ず書きたい内容なので、(当選するか解らないですが)技術書典9で出すことにします。当選しなくても、とにかく書いて頒布します。今年は3回も技術書典があることですし。ということで、IAMから始まるAWSのセキュリティ3部作という形でまとめる予定です。


ガードレール設計って何?

 ここまで読んでいる人は、じゃぁガードレール設計って具体的になりするのと思っていると思います。今、必要と考えているのは、大まかにいうと下記の事項です。

  • 操作履歴の記録・通知
  • 定点・イベント発生時にAWSの状態を記録し、違反がないかのチェック
  • 脅威の検出・通知
  • 上記アラートの一元管理
  • コスト最適化

 これをAWSのサービスに当てはめると、それぞれCloudTrail, Config, GuardDuty, SecurityHub, Trusted Advisorになります。じゃぁそのサービスを入れればいいじゃんとなりがちですが、そもそもの導入の目的を整理しておかないと実際はせっかくの機能も有効活用できていないとなりがちになります。そこを整理した上で、具体的な設定までのガイド的な本になれればと願っています。

まとめ

 構想はあれど、筆が進んでいないです。神頼みをやめて、愚直にやっていくこととします。これ以外にも、全く別の商業誌も執筆中だったりします。何とかなる?

booth.pm