Validate TypeScript にインストールエラーの修正についてのプルリクを送る

Web API の リクエスト パラメーター を 入力チェックするのによさそうな Validate TypeScript というライブラリを見つけ使おうとしたところ、インストールエラーが発生してしまいました。
こちらをプルリクエストで修正してもらいましたので、プルリクエストの手順と合わせて整理します。

Validate TypeScript

Validate TypeScript-https://github.com/Grant-Zietsman/validate-typescriptはスキーマベースのバリデーターで、JSON などのオブジェクトの値や型をチェックできます。

プルリクを出すことになった背景

ドキュメントにしたがってnpm installするとエラーとなります。またnpm install -Sとセーブオプションを付けてもエラーなのでpackage.jsonに反映されませんしnode_modulesディレクトリにも保存されません。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
lulzneko@PC:/tmp/project$ npm install validate-typescript

> validate-typescript@4.0.0 install /tmp/project/node_modules/validate-typescript
> cd test && npm install

sh: 1: cd: can't cd to test
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! validate-typescript@4.0.0 install: `cd test && npm install`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the validate-typescript@4.0.0 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! /home/lulzneko/.npm/_logs/2019-03-13T25_67_89_000Z-debug.log

普段はYarnを使っているのですが、こちらも同様にエラーとなりpackage.jsonに反映されません。しかしながらダウンロードはできているのでnode_modulesに保存されます。CI とかで環境が変わると、パッケージ名を明示してインストールはしないので、そちらではエラーとなるので注意が必要です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
lulzneko@PC:/tmp/project$ yarn add validate-typescript
yarn add v1.13.0
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
error /tmp/project/node_modules/validate-typescript: Command failed.
Exit code: 2
Command: cd test && npm install
Arguments:
Directory: /tmp/project/node_modules/validate-typescript
Output:
/bin/sh: 1: cd: can't cd to test
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

インストール・エラーとなる原因

どうもcd test && npm installというコマンドを実行しようとしてtestディレクトリが見つからないためエラーとなっているようです。
普段Yarnを使っているのでnpm installは出てこないでしょうしcd testすることもないです。

自分のプロジェクト内で問題となってるわけではなないようなのでValidate Typescriptに何かの処理があるのではないと探ります。

利用しようとしていた v4.0.0 cf81b3b のファイルを見るとscripts"install": "cd test && npm install",があります。
これが実行されてエラーとなっているようです。
https://github.com/Grant-Zietsman/validate-typescript/blob/cf81b3b17a2b37f2fb7d72006eff9bc28519220c/package.json#L12

Yarn だとダウンロードできているので、ディレクトリを確認したところtestディレクトリは含まれていませんでした。
またインストールに成功する Version 3.0.0 にもtestは含まれていません。
パッケージングの忘れか、意図しない実行のいずれかなのでしょうか 🤔

変更履歴の確認

ひとつ前の Version 3.0.0 はインストールに成功するので、Version 4.0.0 リリースに至るまでに変化があったといえます。

3.0.0 3e3c296"setup": "cd test && npm run setup",installでなくsetupという名前で作られていたようです。
これならインストール時ではなく、明示的に呼び出した時に実行されるので問題ないです。
https://github.com/Grant-Zietsman/validate-typescript/blob/3e3c2967150ae88c828b1479576ba922227c2eb7/package.json#L12

次のFixed outstanding issues, except feature request. 5dce751でエラーとなっているinstallに変わっています。
変更が多数あるのですがコミットが分かれておらず、またコメントからもちょっと推測しにくいところです。
https://github.com/Grant-Zietsman/validate-typescript/commit/5dce751b6cea0870be3287835befa437ed37c8cf#diff-b9cfc7f2cdf78a7f4b91a753d10865a2

残念ながら変更意図の理解につながりそうなコメントなどはなさそうでした。
とりあえず、元に戻すプルリクを出して相談してみることにします。


勝手な推測ですが、Validate Typescript自体の開発を行う際に外部依存ライブラリ(現時点だと"chalk": "^2.3.1") をnpm installします。その時に合わせて、テストで依存している外部ライブラリのインストールも一緒に行いたかったのではないでしょうか。

Version 3.0.0 だと、以下の手順が必要です。

1
2
3
$ npm install
$ npm run setup
cd test && npm run setup

これが Version 4.0.0 だと、1回。

1
2
$ npm install
cd test && npm run setup

開発環境を便利にした反面、これが利用者側のインストールするときにも同じことが起こるとは想定外だったのかなと想像します。

フォークしてプルリク作成の環境用意

プルリクを出すために、まずは元リポジトリをフォークして、プルリク作成の環境を作ります。

Validate Typescriptのリポジトリへ行き、画面右上の [fork] ボタンをクリックします。

リポジトリをスキャンしてる画像が表示されます。いい感じ。

無事フォークが完了し自分のリポジトリが作られます。
フォークしたことが [forked from Grant-Zietsman/validate-typescript] の表示で分かります。

後はいつも通りクローンして作業環境を用意します。

1
2
3
4
5
6
7
8
lulzneko@PC:~$ git clone git@github.com:lulzneko/validate-typescript.git
Cloning into 'validate-typescript'...
remote: Enumerating objects: 44, done.
remote: Counting objects: 100% (44/44), done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 450 (delta 16), reused 32 (delta 12), pack-reused 406
Receiving objects: 100% (450/450), 758.22 KiB | 1.76 MiB/s, done.
Resolving deltas: 100% (240/240), done.

フォークした自分のリポジトリに変更を加える

プルリクを送りたい変更を、まずはフォークした自分のリポジトリに行います。
しっかりやるにはブランチを切って作業したほうが良いですが、今回はdevelopブランチがあることと、パッチ1個という感じで継続的にコントリビュートしていわけではないので、developブランチへ直接変更を加えてしまいます。

1
2
3
4
5
6
7
8
9
lulzneko@PC:~/validate-typescript$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/develop
remotes/origin/master

lulzneko@PC:~/validate-typescript$ git checkout -b develop origin/develop
Branch 'develop' set up to track remote branch 'develop' from 'origin'.
Switched to a new branch 'develop'

変更の方針

  • package.jsoninstallsetupに戻す
  • 開発環境のセットアップが1回で行える機能は残す

よって、以下のように修正します (script部分を抜粋)

1
"setup": "npm install && cd test && npm install",

これによって開発環境のセットアップはnpm run setupの 1回です。
それでいてnpm installcd test && npm installの 2つが実行できます。

修正できたら、コミット&プッシュ!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
lulzneko@PC:~/validate-typescript$ git add package.json

lulzneko@PC:~/validate-typescript$ git commit -m "Fix error when this npm module user installs"
[develop f3ec461] Fix error when this npm module user installs
1 file changed, 1 insertion(+), 1 deletion(-)

lulzneko@PC:~/validate-typescript$ git push origin develop
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 337 bytes | 25.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://github.com/lulzneko/validate-typescript.git
482bf65..f6a9885 develop -> develop

プルリクの作成

フォークした自分のリポジトリに変更が反映され、プルリク作成ボタンが表示されるので [Compare & pull request] ボタンをクリックします。

プルリク作成フォームが表示されるので、確認と内容を記入し [Create pull request] ボタンをクリックします。

  • 左の [base] が元のリポジトリ&ブランチになっていることを確認
  • 右の [head] がフォークした自分のリポジトリ&作業ブランチになっていることを確認
  • プルリクのタイトルと内容を記入

元のリポジトリにプルリクが作られました!マージされといいな。

Fix error when this npm module user installs by lulzneko · Pull Request #7 · Grant-Zietsman/validate-typescript

一晩でマージされた!

この記事をつらつらと書いているうちに一晩でマージされて、Version 4.0.1 がリリースされました。はやっ!!
マージされたのでブランチの削除と、必要に応じてフォークしたリポジトリを削除します。プルリクのフォームにボタンがあるので簡単です。


無事、インストールエラー問題が解決され、パッチされたバージョンがリリースされました。

ホントはライブラリ紹介を書こうとしていたのですが、先にプルリクとなり。せっかくなのでプルリクの流れも整理して書いておこうと思ったら、あっという間にマージしてくれたのでびっくりです。
2019年3月14日 0:40 JST にプルリクして、2019年3月14日 1:28 JST にリリースの返事。1時間していないという。Grant Zietsmanさん、ありがとうございます!

※ なお英語はまったくできないのでプルリクの文章はグーグルです。

CTO vs Hackers ハッカソン戦記

『【CTOって本当にかけるの!?】ベンチャー6社のCTOチームと競う新規サービス立ち上げハッカソン』という、強いキーワード盛盛なハッカソンに参戦してきました。
果たして CTO たちは何を作ったのか、ハッカーズ軍団は CTO軍に勝ち得たのか、ハッカソン戦記です。

ハッカソン概要

【CTOって本当にかけるの!?】ベンチャー6社のCTOチームと競う新規サービス立ち上げハッカソン』、なんという強烈で挑戦的なキーワードが並ぶイベントでしょう。

ベンチャー6社さんの CTO が参加者とサービス開発で戦うといいう趣旨のハッカソン・イベントです。
CTO が参加者に混ざるのではなく、CTO は CTOチーム、参加者は参加者でチームを作り開発をする形です。

募集は一般 30人、学生10人でしたが、初開催であることとタイトルの強い感があったためか、参加者は8名でした。
大きいイベントもいいですが、3チームの対戦となり動きやすかったりカジュアル感があってよかったです。

会場は HENNGE(N2つ大事/ヘンジでなくヘンゲです)株式会社さんのオフィスでシブヤ・ビットバレーなロケーションです。
室内は緑が多く配置され、仕切りがなくフリーな感じで、スタンディング、ソファー、テーブル、ファミレスタイプ、オフィスタイプ、集中席などと多様な席タイプがあり、とてもステキな感じです。(写真は後掲)

当日の進行

開会でまず CTO さん、スポンサーさんの自己紹介と会社紹介をいただきました。

社名お名前
シタテル株式会社和泉 信生 執行役員CTO主催者さん、ゲーム作りなどもされている
ラクスル株式会社泉 雄介 取締役CTOChart.js でかっこいいグラフを作成
HENNGE 株式会社小椋 一宏 代表取締役社長兼CTO会場提供者さん、和服がステキ、CEO兼 CTO
Wovn Technologies 株式会社Jeffrey Sandford 共同創業者CTO急用につき欠席でした、残念
ENECHANGE株式会社白木 敦夫 取締役CTO急用につき欠席でした、残念
ルームクリップ株式会社平山 知宏 取締役CTO私たちのアイデアにキー・メッセージを!
株式会社オプトベンチャーズ細野 尚孝 パートナースポンサードありがとうございます
HENNGE 株式会社天野 治夫 エグゼクティブオフィサー写真撮影と会場管理ありがとうございます

続いて参加者の自己紹介。
「社会人1年目で~」「3年目~」「1年で~」って、みなさんお若くないですか!?
たぶん、おっさん1名(私)、中堅~ベテランさん1名、あと若い方の 8人のメンバー編成と思われます。若いとはいえ、CTO に挑むだけあってめちゃくちゃすごいエンジニアさんたちです。ご一緒させていただいた方は、ハッカソン優勝者、Django & DB でサーバーサイドのスペシャリスト、あっという間に iOS アプリを作り上げたモバイルアプリのスペシャリストと、とにかくすごかったです。(ご一緒できて楽しかったです。ありがとうございます。)

アイディアピッチを募集していましたが、応募がなかったとのことで、仮チーム分けをしてアイデアソン・タイム約1時間。テーマ設定はなく、フリーで議論。

昼食のサンドイッチ(とても美味しかった!)をつまみながら、アイデアソンの結果から開発対象を検討。
チームは最初の仮分けしたメンバーのまま進むことに。やっぱり自分で練ったアイデアを作りたいですよね。

開発開始!
11:00 ~ 17:30 の 6.5時間1本勝負!!

17:30 開発終了、発表、クロージング。

ハッシュタグ#cto_vs_hackers、当日は忙しすぎて何もかけなった(ツイートしたけど付け忘れた💦)
当日の雰囲気https://photos.app.goo.gl/LtJEL8TrvTPdRg4h8

チーム メンバー

@imodeiciousは、ハッカソンのプロといっても差し支えないでしょう。
アイデアソンでのアイデアの広げ方、開発に当たっての進め方、エンジニア間の調整にドキュメンテーション、ファシリテーションにプレゼンテーションとチームを盛り上げ、そしてひとつへと導いてくれました。ありがとうございます!(せっかくのハッカソンなのにコーディングの方で活躍できる機会がなく、すみませんでした。)


@dumblepytech1は、Django & DB 使いでサーバーサイドのスペシャリスト。ざっくりとした要件から、見事なデータモデリングをしてサーバーの実装をしてくれました。ミュージシャンにしてスポーツマンそして技術書展に出展を狙うなどといった趣味と技術の広さがすごく、アイデアソンでもたくさんのアイデアを出してくれました。ありがとうございます!

「現場で使える Django の教科書」を紹介いただきました。そして自身でも技術書展での出展を目指すとのこと、すごいです。
出版なら(でなく出展だけど)ラクスル株式会社泉CTO。私は本ではないけど、アイコンの猫をステッカーにしてPCに貼りたいのと天板をがっちり覆うようなシールをしてみたいのでお話してみればよかった、しまった。


@rn1ttaはモバイルアプリのスペシャリスト。
「自撮りで自分の写真をサーバーに送って~」みたいなざっくり要件をきっちり整理して、また必要なアプリ機能をしっかり分解してメニュー化しつつ短時間でアプリを作ってくれました。実装機能が膨らんでしまう部分についても、ハッカソンの当日向け代替実装を考える設計実装力、そしてキーとなる部分での核心に入る発言と、サービスの確実な実現をしてくれました。ありがとうございます!


素晴らしいメンバーとであえ、そして一緒に開発できとても楽しかったです。

アイデアソン

テーマ無しでのアイデアソンでアイデアを出しつつ、せっかくなので自分たちで「シブヤ | CTO」を設定してみました。フリーでアイデアを出していくのも楽しいですが、やっぱりテーマ設定すると軸がはっきりしてより楽しめたように感じます。

“シブヤ” の観点では、109 のファッションや路上ライブやタワレコなど音楽のイメージが連想されたり。
ファッションといえば、主催者のシタテル株式会社和泉CTO。アイデアソンで切り込んでみてもよかったかも(vs CTO ハッカソンではあるけど、アイデアソンは)

ハロウィン、これは暴動的な盛り上がりをどうした良いか。チョット難し。
規制や制限のためのシステムではなく、やっぱり「楽しいこと! 最近楽しいことありましたか!?」by@imodeicious。ですです。

イベントごとからは子供がいる場合でも楽しめるには?などと広がりがでました。
そこから、子供向けや、お子さんのいる世帯向け、そこから子供含め使っているであろう LINE を使ったアプリでできそうなことなどなど。

“CTO” の観点では、エンジニアのボスとして、エンジニアに向く人って知りたいかな?など。これは自分たちもで自己分析他、著名なハッカーさんとかを知りたいとか。

こちらは設定してみたものの、ちょっとイメージしにくかったなぁと思いました。
CTO、立場や役割は漠然と知っているものの、なかなかお話する機会もないし、やっていることも多様かなって。
懇親会の時間にお話させていただき気づいたHENNGE 株式会社小椋CTO、CEO もされていて経営者そのものなんですよね (もちろん CTO 職も経営陣ですが)。

“CTO” とテーマ打っているイベントなので、CTO のみなさんの役割や業務などのお話時間があってもおもしろかったかもしれません。懇親会で CTO LT とか。

そんなこんなで、10個近いアイデアが出てキーになる4つを発表しました。
開発6時間ではスタートしてからアイデアや実装困難から切り替えなどに悩む時間はないですが、アイデアソンでは実装技術度外視でたくさんのネタを出したいところです。

ウチのチームにはたくさんのアイデアが出て、どれも魅力的で、作りたいものを絞らなければならない贅沢な悩みをさせてもらいました。ありがとうございます。

こんなに順調に、 これだけのアイデアがでるってすごいし、各々のアイデアに敬意をもって楽しんで聞いて膨らませるといったステキなサイクルが回っていたように感じます。

開発!

幸運にもたくさんの魅力的なアイデアが続出。その中から「提案型ヘアサロン・アプリ」を作ることにしました。
この案をアイデアソンで発表した際に、ルームクリップ株式会社平山CTO から、強烈なメッセージをいただきました。そしてこのキー・メッセージこそが、私をこの案の実装に駆り立てたところがあります。

アプリ:ミツカルヘアサロン 〜提案型のヘアサロン〜

アプリ概要

  • 髪を切りたい人が、写真やなりたいイメージを登録
  • ヘアサロンが、登録された情報から、提案を作成
  • 髪を切りたい人が、提案を見て決める

開発対象と主担当

開発対象と担当が決まり、開発開始。
アプリ2つにサーバーと作成物が完全に分離されているので Web API とデータ構造の認識があっていれば、得意な技術で一気に進められます。
他のアイデアもすごくよくて作りたかったのですが、開発対象が漠然としていたのと実装した際に作業が密になりそうだったので、限られた時間で実働と完成度を求めると、作業分担を明確にしたほうが良いと考えました。(他のアイデアを押してくださったのに、すみません)

@imodeiciousが速攻で GitHub のリポジトリを用意し、Slack チームの作成と開発環境を整え、続いて Web API 仕様を Google ドキュメントを使って画面共有しながら詰めていきます。そのまま設計を詰めつつ、Google スライドでプレゼン・スライドを作りました。このあたりの構築の速さと、ツールの使いこなしが抜群です。
こういったつなぎの部分を滞りなく構築するのは大事で助かりました。

サーバー は@dumblepytech1の Django です。データモデルを定義することで簡単に DB を作れ、しかも Web UI が起動してマスターメンテしていました。これは便利。
またローカルサーバとのインテグレーションには ngrokhttps://ngrok.comを使ったとのこと。こちらはローカルのポートをウェブサービスとして公開できるようにします。

髪を切りたい人用アプリは@rn1ttaFlutterで Android, iOS のアプリを開発。シングルコードベースで両対応のネイティブ・アプリが作れるんですね。勉強になりました!

@lulznekoヘアサロン用アプリは Nuxt.js の PWA です。ブラウザで見ることもできるし、モバイルアプリとして使うこともできます。
いつもの手法でって感じで GitHub Pages にホスティング。CircleCI は権限設定とかがあったので省略し、適時手動デプロイしました。今回のような短時間でしたら手動でもよいですが、やはり CI/CD は入れておきたいところ。この辺の話は別途整理します。

11:00 から設計開始の 17:30 終了で発表。
時間が圧倒的に足りないとは思いつつも、しっかり作り切れたようにも感じますが、集中しすぎでせっかくの開発憲章「楽しくコミュニケーションする」を満たせず「もくもく」で作業しすぎてしまったのが反省。
ソファー席エリアを使って、大型ディスプレイで音楽かけたり、映画流したりして緩い感じで、かつ集中して作業できました。(靴脱ぎソファーで全開くつろぎスタイルのコーディングしてましたが、めっちゃ集中!)

作ったアプリは、クリーンに再実装して勉強にしたり遊べるようにします。
(それなりにクリーンコードでコミットはキレイに積んだつもりですが、やはり時間制限中では変なものが混ざっちゃってますし)


CTO チームはモブ形式で楽しそうにやっていたので、やり方を考えてみるのも一考かもしれませんが、はじめて会った即席で技術もまったく異なる混成チームなので、短時間でモブるのはキツいかもしれない。ワークショップとかハンズオンだったらよいかも。
開発案件は会議中の参加者の感情をモニタリングするサービス。会議で話しているときに、参加者はどう感じ取っているのかをフィードバックできるようにする仕組みです。同意しているのか、反対なのか、理解しかねているとかをわかりやすくしたら意思統一を流行りやすいよねってところです。まずはアプリのボタンからフィードバックを入力、将来的には画像認識から感情を読み取ることを考えたいとのこと。

もう1つのチーム「さくらもち」さんは、オフィス型の外部ディスプレイが使える環境で開発していました。ちょっと離れていたので雰囲気はわかりませんでしたが、少しお邪魔させていただいたときは楽しそうにお話をされてた感じでした。チーム名がついているのいいですね。つけたかったけど回らなかった。
開発案件はミステリー。謎解きを楽しむアプリで、目的地とそこに至る経路のヒントをもとに、次々と謎を解いて目的地を目指すもの。「経路」も大事でルートがあってない場合は目的地についてもゴールにならないとのことで、経路判定がとても難しそうと感じた通り、GPS 周りの実装で苦労されたとのこと。とくに GPS は HTTPS でアクセスしないと利用できなかったり、GPS のブレがあると判定エリアが難しいなどの困難を乗り越えて実装されたのだとか。すごい。

全チームとてもおもしろいアイデアで、6.5h で実現できてすごかったです。
この集中感がたまらないですね。

会場の風景

HENNGE 株式会社さんのオフィスで、なんと執務エリア含め自由に使わせていただきました!
フリーアドレスで、スタンディング、ソファー、テーブル、ファミレスタイプ、オフィスタイプ、集中席などと多様な席タイプがありとてもステキな感じです。

エントランスに入って壁一面にメッセージ。熱いです。エントランスがイベントにも使えるようになっていて、当日は海外の方が英語でラズパイについて発表をされていました。
日本人エンジニアは約30% とグローバルな体制とのことです。

オフィスエリア入ってすぐに “銅鑼”、最後に「じゃーん」ってやればよかった。
オフィスグリコも充実しています。

ドリンクも充実。こちらのコーヒーマシンがとても美味しく、たくさんいただきました。懇親会ではビールもいただき、ごちそうさまでした。

0円ドクターペッパー自販機!?、”CEO の思い”HENNGE 株式会社小椋CTO(兼CEO) ですよね??

会議室エリアです。ステキな旅館の廊下みたいな場所から、くぐる感じで会議室に入ります。
畳の会議室で洒落た感じに、蔵のような部屋などがあります。こういった場所で話をするのもいいですね。

会議は 45分で!大事大事。


思いっきり開発を楽しめる1日でした。
1日の限られた時間の中、初顔合わせの4人でもサービスの基本機能までは作り上げられるものなのだなぁと感慨深いです。

懇親会の時間では CTOさんとエンジニアのボスとしての立場、経営者としての立場の二律背反の難しさなどの話を聞かせてもらいました。
開発終了の解放感から、いろいろと考えていたことも吹っ飛びビールを楽しむ方向に行ってしまったのは反省。CTO についてもっと踏み込んでいろいろと聞けばよかった。
とはいえ、いろいろのなお話を聞いたりでき、とても楽しい時間でした。

熱い1日、ありがとうございました!!

共有:

独自ドメインでメールの送受信できるように、Google Domains のメール転送と Gmail の送信元を設定する

2019年2月28日に.devドメインの早期アクセスプログラムが終了し、追加費用なしで取得できるようになり多くの方がドメイン取得をされたのではないでしょうか。

.devドメインに限らないのですが、オリジナルのドメインでアプリやウェブサイトを公開するほかに、メールのアドレスとしても使うことができます。

Google Domains は管理しているドメインのメールを転送するサービスも提供しています。そして Gmail の送信元設定と組み合わせることで、取得したオリジナルのドメイン名でメールの送受信ができるようになります。その設定方法を紹介します。

.devドメイン

Google が取得している gTDL(generic Top-Level Domain) で、example.comのようにexample.devのようなドメインを作ることができます。

トップレベルのドメインは、.com,.netなどのような一般用途のドメインや、.jpのような国別コードのドメインが使われてきて、.biz.asiaといった gTDL, sTDL が追加されてきました。

2012年に gTDL が開放されさまざまなトップレベルのドメインが導入され、たとえば Riotz.works の.worksなども、これを機に導入されたものです

このとき Google は.devを取得していたのですが、長らく一般開放はされませんでした。
たまたま使われているのを見かけては欲しがったのを覚えています。

2019年2月20日、ついに.devドメインが一般開放されます。
早期アクセスプログラムとして 1万1500ドルの追加から、徐々に追加費用が下がり 2月28日に追加費用なしとなり、日本時間 2019年2月28日 25時からドメイン取得のちょっとしたお祭り騒ぎのようになりました。これは夕方ごろの Twitter トレンドですが入っています。(日中は東京ローカルではなかった気も)

Google Domains とメール転送

.devドメインはGoogle Domainsから購入できます。また他にも取り扱っているレジストラーはあります。
Google Domainsのよいところは、すでにアカウントを持っていること(が多いか)と、メール転送が使える点になります。あと好みはありますが UI/UX がよいのではないでしょうか。
.devほか、多数のドメインを取り扱っているので、比較的好みのドメインがとりやすいです。

ここからは。.devに限らず、Google Domainsで購入したドメイン全般の話になります。
Google Domainsで購入したドメインは、1ドメインにつき 100個までメール転送の設定ができます。(2019年3月現在)

Google Domainsのマイドメイン管理https://domains.google.com/m/registrar/へアクセスし、メール転送を設定したいドメインを選択します。
左のメニューから [メールアドレス] を選択します。
画面中央のメール転送の設定に、自分のドメインで使いたいアカウント名と、転送先のメールアドレスを入力します。
ここではアカウント名contact(@100%.dev) を100% @gmail.comへ転送する例とします。
(※ 実際には%は使えず、% @のスペースは自動リンク防止のためにスペースを入れている、架空のアドレスになります)

これで、contact@100%.devへ来たメールは100% @gmail.comへ転送されます。
新しく取れたドメインで 100個までは転送設定できるので、ある程度の規模までは耐えられるのではないでしょうか。

現代のコミュニケーションにおいてメールはメジャーではなくなりつつありますが、contact@example.comのような対外コンタクト用やinfo@example.comのような情報発信など完全に廃止しきれない部分はあります。

Gmail と送信元設定

Google Domainsによってメール転送ができるようになりました。
これで取得したドメインのメールを受け取りできるのですが困るのは返信。
このままでは転送砂礫のアドレスでメールを書くことになり「※contact@example.comは発信用のため~」みたいなことを書くことになります。(かきました😢)

そこでGmailに送信元の設定をして、転送設定した際に作ったアカウントのメールから送信できるようにします。

[重要]この設定は 2段階認証を迂回する設定のため場合によっては危険です。実際に「セキュリティ診断 - サードパーティによるアクセス」の警告が出ます。必要の有無を確認の上、自己責任で設定してください。
詳しくはアプリ パスワードでログイン - Google アカウント ヘルプをご確認ください。

転送先のGmailアカウントで Google アカウントのセキュリティ設定https://myaccount.google.com/securityへアクセスし、[アプリ パスワード] を選択します。

[アプリを選択] から [メール] を設定します。
[デバイスを選択] から [その他(名前を入力)] を設定します。

アプリ パスワード に 任意の名前を付け、[生成] をクリックします。

アプリ パスワード が 生成されるのでひかえておきます。

続いて転送先のGmailのアカウントとインポート設定https://mail.google.com/mail/u/0/#settings/accountsへアクセスします。
[名前: (Gmail を使用して他のメール アドレスからメールを送信します)] の [他のメール アドレスを追加] をクリックします。

設定ダイアログが開きます。
[名前] にメール送信者の名前を入力します。
[メールアドレス] にGoogle Domainsで設定した、新しいドメインのメールアドレスを入力します。
[エイリアスとして扱います。] のチェックを外します。

SMTPサーバーの設定を入力します。
[SMTP サーバー] に [smtp.gmail.com] を入力します。
[ユーザー名] に [Gmail のアドレス] を入力します。
[パスワード] に 先ほど生成した アプリ パスワード を 入力します。

Goodle Domains で設定したアカウントのアドレスへメールが送信されます。
メール本文のリンクをクリックするか、確認コードを入力します。

送信元のアドレスが追加されます。
常に新しいドメインのメールでよい場合は、そのメールアドレスの横の [デフォルト] をクリックします。
また、下の [デフォルトの返信モード] も必要に応じて設定します。

デフォルトに設定しておくと、新しいメールを書く際にも、選択したメールアドレスが設定されて表示されます。
変更する場合は、[From] に設定されているメールアドレスの右の [▼] をクリック思案す。


Google Domainsによるメール転送とGmailの送信元設定になります。
最近はメールを使うことも少なくなってきましたが、対外的なコンタクトなどではまだまだ使いますし、Gmailのアドレスよりも、ちゃんと取得したドメインでメール送信できるといいですよね。

メールサーバーを立てるのは大変なことですし、送受信セットで手軽に使えるクラウドのサービスもまだないように感じます。Google Domains、アカウント設定、Gmailと行ったり来たりになりますが、この組み合わせだと比較的容易に設定できるのではないでしょうか。

なによりも、Gmailがそのまま使えるのがありがたいです。

共有:

JAWS DAYS 2019 にて「AWS x JAMStack なサーバーレス Web Front」について発表をしました

2019年2月23日に開催された JAWS DAYS 2019 で『AWS x JAMStack で構築・運用するサーバーレスな Web Front』と題して JAMStack とサーバレス Web Front にまつわる発表をしました。そのサマリーです。

シリーズの記事

JAWS DAYS 概要

発表したイベントJAWS DAYS 2019ですが、AWS のユーザーコミュニティJAWS-UG主催、後援 アマゾン ウェブ サービス ジャパン株式会社さん で 行われる JAWS-UG 最大のイベントです。

場所は TOC五反田メッセで、さまざまなイベントや展示会などが開催される場所です。

そして各開催にはテーマが設定されます。今回は「満漢全席」です。

AWS にはたくさんの機能があります。そしてフロントエンドにもたくさんの技術があります。

それらの中から最近注目を集めている JAMStack を中心に、選りすぐりの技術を集めた素晴らしいアーキテクチャをご紹介したい。

満漢全席なイベントに、1つのコース料理としての満漢全席の皿(アーキテクチャ)を詰め込みお伝えしたい、そんな思いから『AWS x JAMStack で構築・運用するサーバーレスな Web Front』の発表となりました。

タイトルこそ満漢全席は含まれていませんが、アーキテクチャの表現として盛り込みました。

“お残しはあきまへんぇ〜”

発表資料と Togetter

2019/02/23(土) JAWS DAYS 2019 <7> 15:10~ #jawsug #jawsdays - Togetter
たくさんのツイートありがとうございます!!

JAWS DAYS 2019 で 頂いた QA まとめ
QA・ディスカスありがとうございます!!

サマリー

発表の主旨は「JAMStack、サーバレス Web Front を広めよう」です。

主にサーバサイドを担当することが多く、サーバーレスなサーバサイド開発にこだわって行く中で、フロントサイドが (広義の) SSR したいとの相談があり、そのたびに「インスタンスは持ちたくないです」「ホントにサーバ側で HTML 作る必要がありますか?」と議論することがあり、結局 SSR 必要なかったことが多々ありました。(もちろん発表の通り SEO x CGM とか SSR 必要な場合は SSR します)

サーバーレスを専門でやっているので「フロントもサーバーレスで」のキーワードを使うこともあるのですが、今1つ伝わりにくかった。どうしたら伝わるのか、何か共通のキーワードはないのか、そう思っているさなかに JAMStack が浮上してきました。

JAMStack は HTML を事前ビルドし CDN へ配置するので、まさにサーバーレスになります!
これが共通の言葉として認知され、定着されればフロントサイド、サーバサイドともにサーバレスで作れます。
これはサーバーレス推進派としては広めねばとのことをお話しするに至った次第です。
「JAMStack、サーバレス Web Front」として、サーバレス界隈、フロントエンド界隈の盛り上がりに貢献できたら嬉しいです。

大きく3つのテーマでお話ししました。

  1. JAMStack とは
  2. AWS における JAMStack の配置
  3. JAMStack の可能性

JAMStack とは

まずは、公式サイトhttps://jamstack.orgおよび提唱者@biilmannさんのThe JAM Stackを中心に JAMStack そのものについて説明をしました。ご存知の方も少なからずいらっしゃるかと思ったのですが、JAMStack の概念、メリットをしっかりお伝えした上で活用をお話ししたかったものになります。


ほぼすべては、このスライドに集約されます。

JAMStack の定義

  • JavaScript of client side、Web API 呼出しはクライアントで行う
  • APIs of resusable、再利用可能な Web API でデータを提供する
  • Markup of prebuilt、HTML は事前構築済みで CDN に配置する

また JAMStack なサイトを構築するには SSG(Static Site Generator) を使います。
その SSG がリストされているのが StaticGenhttps://www.staticgen.comです。
こちらから好みの技術や使い勝手などを試して使うとよいでしょう。

オススメとしては以下でしょうか(すごく個人的な主観です)

  • GatsbyJS: JAMStack のコンテキストでも一番登場しますし、一番成熟しています
  • Hexo: 手ごろで使いやすい静的なブログ構築ツール、JAMStack を謳ってないが JAMStack
  • Gridsome: まだまだ開発中で上級者向けになりますが、開発の過程を一緒に楽しめます
  • Nuxt.js: アプリのフレームとして使うのに向いています

※ 終盤でお話ししましたが、Riotz.works では 2019年2月現在、ウェブサイトGridsomeラップアプリNuxt.js本投稿Hexoです。システム構成を見直しているので変わるかもしれません。

AWS における JAMStack の配置

JAMStack の定義やベストプラクティスは AWS のサービスで賄うことができます。
ホントに “AWS と JAMStack は相性が良い!” といえるでしょう。

そして JAWS DAYS 2019 テーマ「満漢全席」になぞらえて、選りすぐりの技術で作られたアーキテクチャ例です。


すべて AWS で固めたイメージです。(Serverless Frameworkが入ってますがツール部分なのでってことで)
この構成でよいのですが、右下の開発者周りはもう少し落とし込んで。


“俺の” 構成。料理だけにレストランを展開されているネーミングをモチーフにしました。(書きながら本当にあってもよさそう)
やはりGitHub,CircleCI,Slackを使うケースが多いのではないでしょうか。
アプリはNuxt.jsで SPA の Generate を使うと作りやすいです。Nuxt.jsは SSR もできますが JAMStack なので Generate になります。

Dependabotはリポジトリの Node.js のpackage.jsonや Java/Mavenpom.xmlを解析し、依存している外部ライブラリのバージョンアップをチェックし、バージョンアップしてたらプルリクエストを作ってくれます。

その他ブログなどの情報発信用の満漢ミニ席や WordPress リニューアル席とネーミングが苦しいアーキテクチャを紹介しました。
どれも選りすぐりの技術を活用した一皿となっています。

満漢ミニ席はRiotz.works の ウェブサイトで使っているパターンです。
これまでの開発経緯から GitHub Pages にホスティングしている部分が一部異なります。(始まりは手書きHTMLだったので)

WordPress リニューアル席はNuxt.jsで作ったパターンがあります。
GatsbyJSGridsomeは WordPress に対応しているので、単純リニューアルでしたらそちらを使ったほうが良いでしょう。

これらのように、さまざまなパターンで JAMStack と AWS は活用できます。

JAMStack の可能性

一番向いているのは「情報発信サイト」です。
公式サイト、ブログ、ドキュメントなど、特定管理下で情報を追加していくようなユースケースはとても相性が良いです。
GatsbyJSHexo、VuePress、Gridsomeといったツールが使われます。

次に「ウェブアプリのフレーム」です。
こちらも最近話題の PWA(Progressive Web Apps) のようなアプリやウェブアプリのフレームとして使たりします。
動的なデータは Web API 経由で取得しますが、可能な限り構築済みの HTML としてフレーム化します。
たとえばラップ・バトルの『ラップ、タップ、アップ 🎶』はNuxt.jsで SSG した PWA です。
Next.js、Nuxt.jsが使われます。

一方で「SEO 重視で CGM(Consumer Generated Media) や変化の激しいコンテンツ」には向かないです。
JAMStack は HTML を事前ビルドするので、変化の激しいコンテンツには処理が追い付かず向きません。
そうなるとフレームだけ JAMStack にしコンテンツは Web API 経由になりますが、SEO 関連のヘッダーは HTML の必要があります。HTML にするには JAMStack のように事前ビルドするか SSR(Server Side Rendering) にする必要があります。

まとめ

エゴサ

まとめ、参加録、フィードバック、いろいろな記事ありがとうございます🙏 とても嬉しいです😆

2019/02/23(土) JAWS DAYS 2019 <7> 15:10~ #jawsug #jawsdays - Togetter
共感いただけたり、的確なコメント、フィードバックさまざまなツイートをいただき嬉しいです!!

JAWS DAYS 2019に行ってきた - せてぃーずノート
Dependabot と Java についても触れてくださっています。ありがとうございます!

JAWS DAYS 2019参加レポ | NologoyAnce.net
参加されたセッションをシンプルにまとめていただきました。ありがとうございます!

JAWSUG2019に初参加してきました - プログレッシブ・プロレタリアート
JAMStack がはやるのか、確かに気になります。頑張って流行らせたいです。ありがとうございます!

JAWS DAYS 2019手がきメモまとめ #jawsdays #jawsug|kondoyuko|note
ステキなグラレコでまとめてくださいました。ありがとうございます!

できる限り探してまとめさせていただきました。
もし入ってなかったり、新たに投稿いただいたなどありましたら Twitter@lulznekoへ DM やメンションいただけたら幸いです。


JAWS DAYS で発表させていただくのははじめてで、とても良い経験をさせていただきました。
オープンな会場と小さめのマイクの音に、いつもの雰囲気が違うので上手く話ができるのか不安と緊張が入り混じった感じで発表に入りました。出だしで噛んでしまったところから吹っ切れた感もでて、勘が戻ってきて話ができました。

最後になりますが、セッションにご参加いただいた皆さま、万事支援してくださったスタッフの皆さま、そして貴重な機会を作っていただいた運営の皆さまに感謝です! ありがとうございす!!

デブサミ 2019 にて「サーバーレス開発の楽しさ」について発表をしました

2019年2月14日~15日に開催された Developers Summit 2019(通称:「デブサミ」)で、『サーバーレスで最高に楽しめるアプリ開発』と題してサーバーレスにまつわる発表をしました。発表内容のサマリーです。

シリーズの記事

デブサミ概要

発表したイベントデブサミですが、技術書籍で定評のある翔泳社さんが開催している “技術者コミュニティとの連携から生まれた総合ITコンファレンス” です。

今回はDevelopers Summit 2019 冬のイベントで、ホテル雅叙園東京で開催されました。よく結婚式などで使われ、建物内に滝と庭園があるすごい場所です。

そして各開催にはテーマが設定されます。今回は「SHARE YOUR FUN!」です。

まさに「サーバーレス開発って楽しいよね」と思っていたところで、その楽しさを多くの人にお伝えしたい、そう考えていたところでの『サーバーレスで最高に楽しめるアプリ開発』の発表となりました。

タイトルが弾け気味なのは楽しさを伝えたいという思いをテーマに乗せました。
(他の登壇者さんのタイトルを見ると、もっと弾けてもよかったかな)

発表資料と Togetter

デブサミ2019【15-B-6】サーバーレスで最高に楽しめるアプリ開発 #devsumiB - Togetter
たくさんのツイートありがとうございます!!

デブサミ 2019 Ask the Speaker で 頂いた QA まとめ
Ask the Speaker 他、QA・ディスカスありがとうございます!!

サマリー

発表の主旨は「サーバーレス開発の楽しさ」です。

これまでさまざまな形態で開発をしてきました。オンプレミス、Amazon EC2、AWS Elastic Beanstalk、Docker…
それが AWS Lambda の登場によって開発体験が激変し、それと同時にさらなる開発の楽しさを体験できました。
もちろんプロジェクトが不調な時もあり、サーバーレスによる制約もあり、たくさんの困難は変わらず待ち構えていますが、それを踏まえても楽しさが勝ると感じています。

そんな体験や思いを多くの開発者さんにお伝えしたく「サーバーレス開発の楽しさ」にフォースし、大きく3つのテーマでお話ししました。

  1. アイデアを即、形にできる、楽しみ
  2. アプリの開発に専念できる、楽しみ
  3. ピタゴラ装置を組み立てる、楽しみ

アイデアを即、形にできる、楽しみ


サーバーレスの環境にすることで、多くのことがクラウドに任せられます。
これはホントにすごいことで、たとえばウェブサーバーもアプリサーバーもデータベースもすべて構築済みでいきなり使い始めることができます。

つまりアイデアが浮かんだら、即コーディングを始めてしまってプロトタイピングできてしまうことです。そして思い切って世に出してしまうことができるということでもあります。

アイデアを形にしていくことは開発者にとって、とても楽しいことではないでしょうか。
また作ったアプリは、過度なアクセスが発生しない限り大した費用にならないことも多く(もちろん、作りにもよりますが)稼働させたままにできます。ポートフォリオとして作品を並べておくこともできます。

アプリの依存ライブラリこそ管理は必要ですが、インフラ部分のパッチあてやバージョンアップなどの運用はクラウドに任せられます。
このアプリの依存ライブラリの管理はDependabotRenovateといったサービスを使うことができます。GitHub などのリポジトリと連携することでpackage.jsonpom.xmlといったプロジェクトのライブラリ管理のファイルを参照し、バージョンアップがあったらプルリクエストを上げてくれます。テストなどに自信がある場合は自動マージさせてしまうのも手です。

サーバーレスには、アイデアを即、形にする楽しさがある!
思いついたら、すぐに作って、どんどん公開して、楽しみましょう♪

※ 発表時に「ラップ、タップ、アップ 🎶」のコスト 500円と話しましたが、さすがに今月は JAWS DAYS 2019 でAWS x JAMStack で 構築・運用する サーバーレス な Web Front| Slides | Riotz.worksもあったので 1,000円にかかりそうです。それでもコスパよいのではないでしょうか。

アプリの開発に専念できる、楽しみ


サーバーレス、FaaS の実行ランタイムにフォーカスして、サーバーレスはアプリ開発に集中できるという話になります。

実行ランタイムが構成済みで使うものを簡単に選択できます。そして、それらは周辺システムと統合されているので、ランタイムを選択するだけで使う始めることができ、他のことを考える必要がありませんし実行ランタイムの違いから周辺システムへの変化を気にすることもありません。

IoT バックエンドの開発プロジェクトの事例になりますが、Java の実行ランタイムを使ったサーバーレスで作っていたものを、本番投入1ヶ月前に Node.js/TypeScript へ切り替えるという事態がありました。

この時でさえ、Lambda の実行ランタイムを Java から Node.js へ切り替え、プログラムは再実装するものの周辺システムは変更ありませんでした。スケールや監視でさえ統合済みなので何も設定する必要はありません。
ホントにプログラムだけを実装しなおしただけになります。

もしインスタンスやコンテナーベースだとしたら、OS やミドルウェアからと、全部やり直しになります。そしてそれに対応できる人材はいたでしょうか。。。

ホントにプログラムだけに集中できました。
プロジェクトは危機的状況ですが、開発者としてコードだけに専念できるのは、とても楽しいことではないでしょうか。

サーバーレス環境は構成済み&疎結合、手軽に切替えて使う楽しさがある!
必要時に最適なものへ切替え、それでも “コードに専念” を楽しみましょう♪

ピタゴラ装置を組み立てる、楽しみ


クラウドには多様な機能があり、クラウド自体もたくさんあり、サービス(SaaS)も含めると無数に機能があるといえます。
サーバレスで開発するときに、これらの機能を組み合わせて作っていきますが、あるいはピタゴラ装置を組み立てているとも言えます。(もうこの時点で楽しい、とも思えてしまいますが)

ここでの「機能を組み合わせる」は、Lambda などの処理ロジックの中で多数の機能を呼び出すのではなく、1つの Lambda が 1つの機能を担い、次の機能へ処理を渡していくような流れを想定しています。


これは、私たちがハッカソンで作った「ラップ、タップ、アップ 🎶」というアプリの例ですが「通知」の機能が DynamoDB の後ろに来ています。

多くの場合「登録の Lambda」処理で一緒に通知を行うのではないでしょうか。
しかしながら、ここでは DynamoDB Streams という機能を使って、DynamoDB のレコードの変化を受けて処理を動かすようにしています。

これにより「登録の Lambda」は DynamoDB へ登録するだけの処理となり非常にシンプルになり
ます。

そして「通知の Lambda」も通知が必要かを判断してFirebase Cloud Messagingを呼び出すだけのシンプル実装です。

また「TTL/削除の Lambda」は DynamoDB の TTL(Time To Live) の機能を使い、レコードの削除を自動的に行うようにしています。レコードが削除されると DynamoDB Streams が動きますので、そこからSkyWayの SFU ルーム削除を呼び出す Lambda 処理が行われます。

一見複雑なアーキテクチャになっているようでいて、1つ1つの処理はシンプルになっているので作りやすくメンテもしやすいのではないでしょうか。

まとめ


以上、発表の主旨とサマリーになります。

エゴサ

まとめ、参加録、フィードバック、いろいろな記事ありがとうございます 😆🙏

デブサミ2019【15-B-6】サーバーレスで最高に楽しめるアプリ開発 #devsumiB - Togetter
たくさんのツイートありがとうございます!!

Developers Summit 2019に参加した感想など - cats cats cats
ラップアプリのアーキテクチャを中心に所感交え書いてくださりました。ありがとうございます!!

初心者がデブサミに参加した感想をまとめたらこうなる - Qiita
ピタゴラとコールドスタートにフォーカスを与え所感交えて書いてくださりました。
またDependabotの補足も入れてくださり、ありがとうございます!!

デブサミ2019メモリンク集~Share my fun~ - Qiita
感動を表現した形のまとめがFun!。ありがとうございます!!

Developers Summit 2019に参加してきました - 御成門プログラマーの日記
要点をまとめ、重要部分にフォーカスしてくださりました。ありがとうございます!!

できる限り探してまとめさせていただきました。
もし入ってなかったり、新たに投稿いただいたなどありましたら Twitter@lulznekoへ DM やメンションいただけたら幸いです。


デブサミで発表させていただくのははじめてで、とても良い経験をさせていただきました。
話始めるまでは緊張があったのですが、不思議なことに話始めると緊張は完全に抜けており、会場の皆さまの真摯な目にしっかり応えていきたい、自分の伝えられるものをすべてをお伝えしたいという気持ちが高まり話をすることができました。

これは会場の空気を作ってくださった聴講者の皆さま、安心して発表に臨めるよう支援してくださったスタッフ・運営の方々のおかげです。ありがとうございます。

AWS Lambda 登場以来、サーバーレスに特化しサーバーレスで開発し続けてきたなかで感じていた「サーバレス開発の楽しさ」については、お伝えすることができたのではないかと思っていますが、やはり『サーバーレスで最高に楽しめる』と銘打ったからにはもう少し弾けて話したほうが良かったかなと少し反省。

最後になりますが、セッションにご参加いただいた皆さま、万事支援してくださったスタッフの皆さま、そして貴重な機会を作っていただいた運営の皆さまに感謝です! ありがとうございす!!

JAWS DAYS 2019 にて頂いた QA まとめ

JAWS DAYS 2019 で『AWS x JAMStack で構築・運用するサーバーレスな Web Front』のお話をした後に頂きました QA をまとめます。

頂いた質問は要点のみを一般化して書いている部分がります。背景などが入っていないので若干わかりにくい部分がありますが、ご了承ください。

シリーズの記事

発表資料と Togetter

2019/02/23(土) JAWS DAYS 2019 <7> 15:10~ #jawsug #jawsdays - Togetter
たくさんのツイートありがとうございます!!

1. DynamoDB の Attribute を変えたい場合に、どうやっているのか?

発表の QA タイムで@yoshidashingoさんに、頂いた質問になります。
AWS Serverless Hero直々の質問に緊張し、質問の要点を上手く汲み取れず、しっかり回答を返せませんでした。すみません。QA 対応力を磨かねば。
(ところで振り返ると、これって「この分野はあんまり詳しくないんですが」事案ではないでしょうか💦)

この QA については、本記事投稿時追記の形で、QA を振り返り整理します。

質問の主旨としては、このセクションのタイトルにした通り「DynamoDB の Attribute を変えたい場合に、どうやっているのか?」の質問と改めて整理しました。

DynamoDB でテーブル作成後に変えられないものは下記になります。(他にもテーブル名や暗号化タイプなどありますが質問のスコープとして)

  • 主キーの構成と型 (パーティションキー、ソートキー)
  • Attribute の名前と型(ただし Attribute の追加はいつでも自由にできる)

主キーはどうにもならないので、テーブルの作り直しになります。

Attribute の名前と型、こちらは変えたいとなるとどうにもなりませんが、Attribute は後から追加できるので新しく Attribute を足して、そちらを使う手も取れそうです。
しかし、既存データを新しい Attribute に移動するのか、またはプログラムでカバーするのかが出てきます。また混ざった状態が発生すると、後々困りそうです。

質問の前提となる事象がわかったら、もう少し踏み込めそうですがざっくりこんな感じの回答になります。

発表時に「あまり大きなものを作ってないので」と回答しましたが、マイクロサービスで作っているので、個々のシステムは小さく、また変化もあまりないので上手く想定できなかったのもあったかもしれません。
それでも Attribute はいつでも自由に足せるので、キレイではないものの逃げ方もあるような 🤔
「ディスカスしましょう」とおっしゃっていたので、このあたりの逃げ方含め議論したかったのかな。

※ Serverless Framework との質問でしたが、DynamoDB の定義は Serverless Framework の構成ファイルserverless.ymlに書きます。しかし CloudFormation のパートになるので、Serverless Framework 固有より、CloudFormation での管理になることと、むしろ DynamoDB そのものの話になるかと思い Serverless Framework は外しました。

参考情報

2. WordPress の静的化に JAMStack は有効なの?


何件か質問をいただきました。

WordPress へ投降者以外は直接アクセスできないようにしたり、投稿通知をするための仕組みを作ってあげる必要はありますが、WordPress を使った既存の運用は残したまま、まったく新しいサイトへ生まれ変わらせることができます。

それにより、セキュリティ問題やバージョンアップ対応の負担を減らすことはできますが、この場合でもセキュリティ問題は内部からの攻撃は避けられません。脅威はインターネット側だけにあるとは限らないこと注意が必要です。

そして静的化するのでパフォーマンスは、とてつもなく向上します。
まさに今日お話ししました、高パフォーマンス、セキュリティただし局所化、スケーリング、運用の軽減が手に入ります。

発表資料ではGridsomeを使ったアーキテクチャ図になっていますが、まだまだ開発中なのでGatsbyJSを使うのが現実的です。

またカスタム API を持たず、WordPress のコンテンツを新しいサイトとして配信するだけならNetlifyに配置するのも手です。

GatsbyJS で WordPress 移行は、多くの情報があるので取り組みやすいです。
私も機会があったらブログとかを書きます。

3. SSR(Server Side Rendering) との違いは何か?

SSR はブラウザからのリクエストを受けて、サーバー側で HTML を生成してレスポンスする形になります。
これはリクエストを受けてから処理を行うので静的サイトを作る SSG(Static Site Generator) より、以下の点で不利です。

  • パフォーマンス、これは HTML 生成処理がある、また DB アクセスすることもあるかもしれません
  • セキュリティ、仮に HTML だけを返すとしても AP サーバが存在するので攻撃対象になります
  • スケーラビリティ、AP サーバをスケールするのは大変です

ただし、開発者フレンドリーは、JAMStack としては良いとしていますが、一概に言えないかもしれません。Web API から取得したデータを JavaScript で HTML を変化させるのは開発者によっては苦痛かもしれない。
私はVue.jsNuxt.jsが気に入っていて、JavaScript で値を設定するのは、楽しいです。


そして SEO の観点でお話ししました通り、SEO のためのヘッダー出力は HTML である必要があります。
自分がコンテンツの発信量をコントロールできている場合は SSG で問題ないのですが、リアルタイムで大量のコンテンツが変化していくものには SSR が必要となります。

SSG では CI などを使ってビルドを回す必要があります。これは遅い処理になります。リアルタイムでユーザーを待たせることができないくらい時間がかかり、また大量に受け付けることができないものになります。

この場面においては SSR が必要となります。
それ以外で SSR 必須、または SSR が良いシーンは今のところ浮かばないです。もっと考えてみます。

4. SPA(Single Page Application) はどうなるのか?

これは、SSG が生成した HTML の形式になるので、ツールによります。

ブログツールのHexoは SSG で MPA(Multiple Page Application) です。

私たちが作ったラップ・バトルはNuxt.jsで SSG & SPA で動かしています。
Nuxt.jsは SSR もできるので、設定で指定します。

ツールの考え方とかもあるので一概に何とも言えないところがあります。
ただし高パフォーマンスの観点で考えると、ページの先読みやキャッシュなどが重要になっきます。そして、これらも SSG がどのような機能を持っているかによります。

その点で、私たちはGridsomeが気に入っています。
まだ開発中なので、普通に使うにはGatsbyJSが良いかもしれません。
また、アプリ開発用途でしたら、Nuxt.jsをオススメします。

5. JAMstack でも Lambda や DynamoDB は必須なのか?


“俺の満漢全席” を想定されての質問と考えます。
こちらは JAMStack で作ったアプリ全体像としてのアーキテクチャ図になります。

JAMStack の要件はざっくり言うと「HTML を事前ビルドして CDN に置くこと」なので、Lambda や DynamoDB は JAMStack とは関係ないものになります。


JAMStack の要件だけの図としては “満漢ミニ席” または “WordPress リプレース席” をイメージしていただけるとよいです。
“満漢ミニ席” では、ブログなどの情報発信サイトをイメージしていて、記事を Markdown などのファイルに書き、それを HTML として出力、CDN へ配置する形になっています。
ここには Lambda や DynamoDB は登場しません。純粋にウェブサイトだけになります。

6. “俺の満漢全席” で Lambda/DynamoDB は EC2/RDS にしてもよいか?


Lambda/DynamoDB を EC2/RDS へ変えても構いません。JAMStack の要件としては「再利用可能な API」なので、Web API 提供できれば大丈夫です。

ですが、せっかくなのでサーバーレスで作ってほしいです。

JAMStack は SSG を使うことで、HTML の生成を事前に行います。
そして CDN に配置するだけで運用するので、言わばフロントエンドのサーバーレスともいえるでしょう。

Web API をサーバーレスで作ってきても、フロントエンドで SSR するからインスタンスが欲しいとなって、全体でサーバーレスになれなかったケースなどもあり、フロントエンドのサーバーレス化も重要だと思ったことがあります。

CDN に配置するだけのことをサーバーレスと言うのは、ちょっと苦しいですが、全体をサーバーレスで作りたい撮った時に「JAMStack で、フロントもサーバーレスで」って言いたいのもあります。

最後のまとめ「名前が付き、認識されることで、伝わる」はまさにそんな思いからになります。
むしろ「JAMStack で、フロントもサーバーレスで」って書いたほうが良かったですね。


質問いただき、ありがとうございました。

QA や議論ができ、とても楽しかったです。そしてお話しいただくことで気付きを得たり、考えの整理にもつながり、とても勉強になりました。

できる限り思い出して書きましたが、もし入ってなかったり、別途気になることなどがありましたら Twitter@lulznekoへ DM やメンションいただけたら幸いです。

発表者は、その日何をしていたのか - 発表の舞台裏 JAWS DAYS 2019 編


新しい朝が来た希望の朝だ、発表の朝だ!

JAWS DAYS での発表の朝を迎えて、発表者 lulzneko は絶望していた。
なんと発表資料が完成していないのです 😱


2019年2月23日に開催された JAWS DAYS 2019 で『AWS x JAMStack で構築・運用するサーバーレスな Web Front』と題して JAMStack にまつわる発表をしました。その発表の舞台裏ということで、発表者が当日何をしていたのかを綴ります。

シリーズの記事

JAWS DAYS 概要

発表したイベントJAWS DAYS 2019ですが、AWS のユーザーコミュニティJAWS-UG主催、後援 アマゾン ウェブ サービス ジャパン株式会社さん で 行われる JAWS-UG 最大のイベントです。

場所は TOC五反田メッセで、さまざまなイベントや展示会などが開催される場所です。

会場入り

ストーリーとスライドの配置は完成していて、そこに載せる図AWS における JAMStack の配置の章で使うものが間に合ってなかったレベルなのですが、慌てて PowerPoint を操作する朝から始まりました。
なんか、前回のデブサミ舞台裏でも同じことを書いた気がします。

なお、前日の 22日には発表用資料をうっかり消し飛ばす事故を起こしました。
慌てるとよくないことがあるので、急ぎつつも作業ミスをしないのが大事です。

急いでスライドを完成させ、所用を済ませと、あわただしく過ごして午後一の会場入りをしました。
資料の都合というより所用があって午前入りできなかったのですが、午前中のセッションも聴きたかった。

会場である TOC五反田メッセは、本館とは別の建物になります。
“TOC” だけで考えていると、うっかり本館へ行ってしまい、結構な回り道を歩くことになります。
そうです、うっかり本館へ行ってしまいました。微妙な場所からの移動だったのでタクシーさんに乗せてもらったのですが “メッセ” が伝わってなかったようで、がっつり本館へ。あまり東京の道に慣れてないとのことでしたので、結構な周り道を徒歩で堪能させていただきました。

受付

無事会場入りできたので次は受付です。

イベント開催用の建物なので、入ってすぐに受付になります。
手前に参加者の受付があり、少し進んだところに発表者の受付があります。
クロークもあるので、モコモコのジャケットを預けられたのが嬉しいです。

受付で Doorkeeper のチェックインをします。QR コードを表示して読み取ってもらいます。
続いて自分の名前が書かれてるスピーカーパスをもらい、印刷したアイコンの切り紙を差し込みます。(写真では名前部分が隠れてますが、当日はアイコン画像を端において名前は見えるようにしています)

受付が終わると、発表時間までフリーなのでセッションを楽しんだり、控室で作業したりできます。

発表 10分前

前の発表が終わり、落ち着いたところで演台へ近づき発表準備に入ります。

進行の方から名前等の最終確認を受けます。

そして、電源の確認。
今回はちゃんと持っていきました!(持って帰るのを忘れました💦)

発表者サポートは、進行の方が残り時間をボードで教えてくれます。
10分、5分、3分。しっかり出してくれるので助かります。

マイクはワイヤードで、演台にセットされています。持っているほうが安定するので、外して持つようにしました。
会場は各セッションごとの個室ではなく、会場の後ろ側が空いている&壁が天井までつながっていない仕様のため、マイクの音が小さめでレシーバーで聞くようになっています。会場の後ろのほうで聞いていると音があまりしないので、話すときにどんな感じか心配しましたが話している分には側のスピーカーから聞こえるので違和感はなかったです。

プロジェクターが大きく、普段は投影画像を直接指さすタイプなのですが、さすがに届かない感じです。そろそろマイ・レーザーポインターを用意したほうが良いと思いつつ、準備完了。

発表用スライドの URL をツイート。

発表

いざ、発表!
ご清聴ありがとうございました!!

たくさんのツイートありがとうございます!!
2019/02/23(土) JAWS DAYS 2019 <7> 15:10~ #jawsug #jawsdays - Togetter

@kondoyukoさんに、グラレコを作っていただきました。ありがとうございます!

※ QA は後ほどまとめます。

懇親会まで、徘徊

Ask the Speaker はないので終了。
発表用スライドの URL を再度ツイート。

エゴサして、Like、RT、Follow-…

回れてなかった出展ブースを巡り、スタンプラリー
すべて回ったはずなのに、スタンプが1つ足りず。。。どこが足りないのかはわからない仕様なので諦める&配布終了に間に合わず。残念。
(次の日になったらアプリで表示できなくなったのでキャプチャできず)

懇親会

すごい人数でした。🍻 楽しかったです!


以上、発表者の一日でした。
なんとか無事発表を終えることができました。

次回は、2019年3月9日(土)『【CTOって本当にかけるの!?】ベンチャー6社のCTOチームと競う新規サービス立ち上げハッカソン』でハックしに行きます。
2/25日現在、まだまだ枠がある(8/30人)ようなので、よかったら一緒にハッカソンしましょう。

また、ちょっと来て話をしてよ、といったようなことなどありましたら、Twitter DM/メンションを@lulznekoへ気軽にいただければ幸いです。
これまでの発表歴は、こちら [Slides | Riotz.works]https://riotz.works/slidesになります。


聴きに来てくださり、ありがとうございました。
スタッフの皆さま、支援ありがとうございました。

そして、ポエム的なものをここまで読んでくださり、ありがとうございます。

デブサミ 2019 Ask the Speaker にて頂いた QA まとめ

Developers Summit 2019 で『サーバーレスで最高に楽しめるアプリ開発』のお話をした後の Ask the Speaker で頂きました QA をまとめます。

頂いた質問は要点のみを一般化して書いています。背景などが入っていないので若干わかりにくい部分がありますが、ご了承ください。

シリーズの記事

発表資料と Togetter

デブサミ2019【15-B-6】サーバーレスで最高に楽しめるアプリ開発 #devsumiB - Togetter
たくさんのツイートありがとうございます!!

1. ピタゴラ装置式で障害が発生したら、どのように追跡するか?


たとえば IoT プラットフォームの例では、AWS Lambda を細かく分けていますし、いくつかのサブシステムや AWS アカウントをまたがって処理を行っていたりします。

また入力ソースがバッチとウェブがあり、途中から同じ処理フローになっていきます。

障害が発生すると、結局のところログを洗っていくしかないのは変わらずで。分散されているので地道に追いかけています。

開発メンバーのひとりが、トレースID をヘッダーにつけてリレーする方式を導入を進めてくれているため、導入されている範囲は比較的探しやすいです。

その方法は以下となります。

  • リクエストを最初に受けた場所は、次のリクエストを投げるときにTRACE_IDというヘッダーに UUID をつけて送る (※TRACE_IDは本記事用の仮名)
  • 中間の処理でもTRACE_IDがなかったら、そこからTRACE_IDをつけ始める
  • TRACE_IDを受け取った場合は、その値をリレーして使っていく(新たに発行しない)

マイクロサービスのトレーシング用ライブラリや基盤もあります。いまちょっと名前が思い出せないです。すみません。まだ、しっかり調査できてないので導入できてないです。

※ 本記事投稿時追記
マイクロサービスのトレーシングはZipkinという分散トレーシングシステムを思い出して話していました。名前がすぐに出てこないとは💦
同様のプロダクトやサービスがあり、今後調べていきたいと考えています。

2. ラップ・アプリのモバイル通知が Amazon SNS でないのは?


ラップ・アプリは Web API を AWS に構築しています。
AWS を使っているので Amazon SNS(Simple Notification Service) を使ってモバイル通知をすれば、ワンストップになるので良いのではないかとも考えられます。

これについては、ざっくり行ってしまうと「普段から使っていたから」が一番大きい理由になります。

これは、ハッカソンという時間が限られた場で開発をするので、使い慣れているものを使うのが一番ということになります。

では、なぜ普段使いだったのか(普段 AWS なのだから、SNS が普段使いでもよいはずで)

モバイル通知を必要としたころの調べで、FCM(Firebase Cloud Messaging) のほうが手軽に扱えて、サポートするモバイルデバイスが広かったので FCM を使い、その後も使い続けているといった理由になります。

今なら Amazon SNS でも変わらないのかな。いずれ調べてみたます。

3. IoT プラットフォームでファイル分割処理場をしてる理由は?


開発当時 AWS Lambda が 5分しか稼働できなかったため、ファイルを分割しながら DynamoDB へ投入しているとタイムアウトしてしまったためになります。

そのためいかに高速に処理を行えるようにするかを考え「ファイル分割だけ」をすることが高速化につながったので、ファイル分割を入れています。

高速化のために AWS Lambda のローカルストレージを使ったりとさまざまな工夫が入っています。

2019年2月現在は 15分まで稼働できるので、このシステムではファイル分割をしなくても処理しきれるかもしれません。

4. IoT プラットフォームの DymemoDB はコスト高ではないか?


たしかに DynamoDB を 3つ使っていて、データの内容物としてはおぼ同じものになり、ムダになっているように見えます。

まず DynamoDB のストレージ料金は、高額ではありません。
データの複製を大量に持ったとしても、ストレージについては気にしなくてもよいかもしれません。

ストレージ料金に対して Read/Write のキャパシティが高額です。
このシステムはバッチ処理で一時的に大量データを読み書きする必要があるため、とくに1つめの DynamoDB のキャパシティは高く設定しています。

それでも何百ドルとまでは行っていないはずなので、1つの DynamoDB にして処理ロジックを複雑にさせるより、複数配置するほうを選んでいます。

※ 本記事投稿時追記
2019年2月東京リージョンのストレージ単価は0.285 USD/GB
10GB のデータベースで約3ドル、超大規模デモない限りロジックの簡易さを求めてもよいのではないでしょうか。

Read/Write キャパシティについては、オンデマンドキャパシティモードも出たので、状況に応じて変わってきます。

Amazon DynamoDB 料金
https://aws.amazon.com/jp/dynamodb/pricing/

AWS Simple Monthly Calculator (簡易見積ツール)
https://calculator.s3.amazonaws.com/index.html?lng=ja_JP

5. Amazon SNS で処理を分岐するメリットと活用方法について


IoT プラットフォームの例では、Amazon SNS で本処理と Redshift へデータを渡すのを分けています。

スライドの図では処理の流れを示したかったので矢印が Amazon SNS → DynamoDB の用になっていますが、実際の流れとしては Amazon SNS へ Subscribe しているので矢印が逆になります。

処理を分岐しているというより、データの公開場所を用意したので、欲しい人は見に来てくださいという形になります。

この形のメリットはデータを欲しくなった人が増えた時に、Amazon SNS の Subscribe を追加するだけで追加でき、ロジックを変更しなくてよいものになります。

6. Amazon SNS でウェブの処理を分岐できますか?


Amazon SNS の Subscribe で動作するのは非同期処理になります。

ウェブのリクエストが Amazon SNS の先の処理結果を必要とせず、何かしらのデータを Amazon SNS に公開して、ウェブのレスポンスを返せる場合は、処理分岐として利用可能です。

プログラミングの if文のような条件分岐としては利用できません。
Amazon SNS はデータの公開場所を作っておき、そこにデータを置く人、データをもらう人、それぞれがそれぞれのタイミングで動作するイメージになります。


Ask the Speaker へ来てくださり、ありがとうございました。

QA や議論ができ、とても楽しかったです。そしてお話しいただくことで気付きを得たり、考えの整理にもつながり、とても勉強になりました。

できる限り思い出して書きましたが、もし入ってなかったり、別途気になることなどがありましたら Twitter@lulznekoへ DM やメンションいただけたら幸いです。

発表者は、その日何をしていたのか - 発表の舞台裏 DevSumi 2019 編


新しい朝が来た希望の朝だ、発表の朝だ!

デブサミでの発表の朝を迎えて、発表者 lulzneko は絶望していた。
なんと発表資料が完成していないのです 😱


2019年2月14日~15日に開催された Developers Summit 2019(通称:「デブサミ」)で、『サーバーレスで最高に楽しめるアプリ開発』と題してサーバーレスにまつわる発表をしました。その発表の舞台裏ということで、発表者が当日何をしていたのかを綴ります。

シリーズの記事

デブサミ概要

発表したイベントデブサミですが、技術書籍で定評のある翔泳社さんが開催している “技術者コミュニティとの連携から生まれた総合ITコンファレンス” です。

今回はDevelopers Summit 2019 冬のイベントで、ホテル雅叙園東京で開催されました。よく結婚式などで使われ、建物内に滝と庭園があるすごい場所です。

会場入り

ストーリーとスライドの配置は完成していて、そこに載せる図ピタゴラ装置を組み立てる 楽しみの章で使うものが間に合ってなかったというレベルなのですが、慌てて PowerPoint を操作する朝から始まりました。

lulzneko は遅筆で資料の一部が、間に合ってないことが結構あったりします。
今回はデブサミの次週に JAWS DAYS での発表もあるため、早めに着手したのですがギリってしまった。
あまり本質的でないところとかでも、気になってしまったり、こだわったりしてしまうのが原因なのですが。。。
スライドや文章、図が早く作れる方はうらやましいです。

急いでスライドを完成させ、所用を済ませと、あわただしく過ごして午後一の会場入りをしました。
なおデブサミの運営さんからは、”講演開始50分前までにご到着ください。” とのことですが、やはりセッションを見たいので早く到着するに越したことはないですね。
(資料の都合というより所用があって午前入りできなかったのですが、午前中のセッションも聴きたかった)

会場である雅叙園は実はエントランスとは別の裏道があります。
目黒駅を出て雅叙園に向かう、あのヤバい坂に差し掛かる手前で左に曲がります。住宅地のような感じもある道ですが、気にせず進むと右にアマゾンジャパンさんのオフィスへ行く道が出てきます。
実はこれが裏道で、アマゾンジャパンさんのオフィスへ入り、すぐに右へ行くとなが~いエスカレーターが出てきます。これを降りると、エントランスから入って左手に見えてる庭園へ出ることができます。
あのヤバい坂は急で長距離なだけでなく、車もバシバシ通るので裏道(こっちも車は結構通るのですが)を使いたいところ、もちろん使わせてもらいました。(目黒駅に帰る場合はエスカレーターで登れるので、裏道のが断然いいですね)

受付

無事会場入りできたので次は受付です。

雅叙園は結婚式などでも使われる素敵な場所で、エントランスを入ってすぐに素晴らしい庭園とお洒落なレストラン街があります。

はじめて来ると、IT イベントはやってなさそうな雰囲気に焦りますが、気にせず奥まで進むと、デブサミの看板のあるエスカレーターが出てくるのでビビらずに進むのが大事です。

エスカレーターを上がり2階へ着くと受付がありますが、発表者は3階まであがり、発表者受付に進みます。
こちらも “3F控室前の受付へお越しください。” とメールの案内にあります。

受付で、自分の名前を発表時間、lulzneko の場合ですと「15-B-6 サーバーレスで最高に楽しめるアプリ開発」といった感じで伝え、名刺1枚を渡します。

スピーカーパスをもらって、自分の名前を書きます。
せっかくなのですが名前を書いても、ぱっと見でわからないので印刷したアイコンの切り紙を持っていて、それも差し込んでいます。

受付が終わると、”講演開始30分前” までには控室にいるようにとの説明を受けます。

あとは時間までフリーなのでセッションを楽しんだり、控室で作業したりできます。
セッションは事前登録なしでもスピーカーパスで入ることができます。

ただし lulzneko は、リハーサルに参加してなかったので、流れの確認と接続チェックがあるので、まずは控室入りとなりました。

※ 発表者受付では入場者バッグは配布されていませんでしたが、2階の受付でスピーカーパスを見せたらもらえました♪

控室 & 流れの確認

セッション用に使っているのと同じ規模の部屋になります。

長机に椅子、電源、コーヒー、お茶、スナック、お弁当が用意されています。
電源が豊富に用意されているのがありがたいです(ACアダプター忘れましたが)。発表前に少し手直ししたり、作業したりすることがあり、電源がないとバッテリーの心配が出たりするので重要です。

スタッフの方より名前を呼ばれ、流れの確認に入ります。
スピーカー事前確認フォームで入力した内容を元に、会社名や名前、タイトルを確認します。進行の方が始まりに名前を呼んでくださるためですね。

続いて機材の確認で PC だけ、音声や映像の再生は不要、スマホを使うが接続の必要なしなどを確認し、ディスプレイへの接続チェックをします。
VAIO は HDMI、VGA どちらもいけるほか、接続問題もほぼなく助かってます。一度だけ HDMI はつながらなかったことがあったのですが、ケーブルが長すぎたと思われます。

続いて、バックアップの確認になります。
こちらも事前フォームで PDF を提出したものの確認になります。”必ず2/12(火)までにバックアップデーターを提供する。” こと案内があったのですが、当日の午前中に提出でした 🙇

PDF を提出はしているのですが、実は発表資料はウェブアプリでできています。(ラップのアプリを埋め込みで動かしたのは、この仕掛けだったりします)

発表用のバックアップとしては、ウェブアプリが必要なので Google Chrome でプレゼン URL へアクセスしてもらいました。
その際に URL をうまくお伝えできずに、テキストファイルを作って USB メモリーへコピーしたのですが、スタッフさんより「USB メモリー を PC へ接続して大丈夫ですか?」との確認があり、きちんとされてるなぁと。

そして電源の確認。
忘れてしまったことを素直に白状し、使わないようにしてバッテリーが大丈夫なこと説明しました。
スタッフさんを、とても悲しい表情にさせてしまいました。すみません 🙏

発表者の移動動線

最後に、発表時の流れの説明を受けます。
受付時に以下のようなカードをもらっており、こちらの説明です。

雅叙園は結婚式などでも使われており、そのための裏動線が用意されているとのことです。すごい!

控室は図の「C会場 Ask the Speaker」の上の部屋になります。
その部屋のエスカレーター側入り口とは別の裏口から出て、エレベーターへ回ります。
そして2階に行き、各会場へ入るという流れになります。

確かにデブサミ級のイベントになると、参加人数も多いですし、入り口で事前登録のチェックなどをしているので、発表者が入り口から入ってくると都合が悪そうです。

このような観点からも会場選びとかされているのでしょうね。ザ・プリンス パークタワー東京 が IT系イベントで使われているのも、もしかしたら?

なお Ask the Speaker の受ける場合は、発表終了後に退出される参加者さんへ突して所定位置へ移動するとの説明を受けます。スタッフさんから「私がお客様を掻き分けて進むので、しっかり付いてきてください」とのことです。

まぁ、確かにメイン動線へ戻るためのルートはなさそうですし、早く Ask 席へ移動すること、またスタッフさんを次の発表者につけるためにも突るしかないのでしょう。

以上、説明を受けてフリーです。
コーヒーを堪能して心を落ち着け、セッションとブースへ!

発表 30分前

控室に待機し、発表準備に入ります。
スタッフさんから名前を呼ばれ、先ほど説明を受けた裏動線で移動開始です。

「B会場なので厨房を通ります。気を付けてください。」
「みなさま、ここを通る時は楽しそうにしてます。やっぱり珍しいんですかね。」
「昨日は厨房でケーキを見ていたら食べたくなって買いました。1階で売って、とてもおいしいですよ。」
「こちらで少々お待ちください。」

と、適切なナビを受けて会場裏に到着です。

倉庫のような場所の丸椅子で少々待機。30分前に移動してるとはいえ、20分の休憩があるので直前の発表の、ほぼ終了時点で待機場所到着です。

自分の資料を見直す時間もなく莫大な拍手が聞こえ「入ります。どうぞ!」の案内。

正面のすぐ横から入ってセッティング。
進行の方から名前等の最終確認を受け、発表用の「雅叙園ウォーター(秩父源流水)」をもらいます。

そして、電源の確認。
また進行のスタッフさんを、とても悲しい表情にさせてしまいました。すみません 🙏

発表者ツールとしては、まず演台の下に正面投影用と同じ内容を表示するディスプレイがあります。
こちらへ事前に映しておき、切り替えたらすぐに表示されるようになっています。すごい。
(デモのときに QRコードをスマホで撮るためにしゃがんだのが、このディスプレイです)

客席正面の真ん中に大きなカウントダウン時計があります。演台の手元にもカウントダウン時計があります。
正面のは、とても大きく見やすくて助かりました。(手元のはなぜか動いてなかった)

マイクはワイヤレスで、ハンドマイクとピンマイクがあります。
持っているほうが安定するので、ハンドを選びました。

レーザーポインターもあります。
普段は投影画像を直接指さすのですが、さすがに届かないのでお借りしました。

発表用スライドの URL をツイート。

発表

いざ、発表!
ご清聴ありがとうございました!!

たくさんのツイートありがとうございます!!
デブサミ2019【15-B-6】サーバーレスで最高に楽しめるアプリ開発 #devsumiB - Togetter

Ask the Speaker

お片づけをして、Ask 席へ向かって突ります。
スマホの片づけとかあったので、お待たせしてしまいました。すみません。

10名ぐらいの方に来ていただきました。ありがとうございます!!
いただきました質問はできる限り思い出してメモりましたので、別途まとめを書きます。

[2019.2.23 追記] こちら『デブサミ 2019 Ask the Speaker で 頂いた QA まとめ』にかきました。

何か気になることなどQAや、またフィードバックなどありましたら、Twitter@lulznekoへ DM をいただければと。オープンになっているので、とくにデブサミに限らず気軽にいただければと。

おわり

発表用スライドの URL を再度ツイート。

これまでは発表前だけだったのですが、あるTwitter の 投票で、発表後にスライドを共有してほしいというのが1番だったので再度ツイートするようにしました。遅くなってしまったので、お片づけ時にツイートすべきでした。反省。
(発表前は2番だけど、発表時に手元へあるといいこともあるので)

エゴサして、Like、RT、Follow-、バッテリー切れ…


以上、発表者の一日でした。

色々しでかし気味なヤバい一日でしたが、無事発表を終えることができました。

いろいろなイベントで話をする機会をいただいておりますが、スタッフさんとの濃密なやり取りや、裏動線を使った移動などははじめてで、これはぜひ伝えたいなと思い書いた次第です。

文才があったら発表者目線な読み物にしたかったのですが、ムリかったので淡々と描く形になりました。
発表者サイドではありますが、舞台裏がどうなっていたのか少しでも伝わりましたら幸いです。

次回は、2019年2月23日(土) 15:10~JAWS DAYS 2019で『AWS x JAMStack で構築・運用するサーバーレスなWeb Front』のお話をします。 もしよろしければ、お越しください。

また、ちょっと来て話をしてよ、といったようなことなどありましたら、Twitter DM を@lulznekoへ気軽にいただければ幸いです。
これまでの発表歴はこちら [[Slides | Riotz.works]https://riotz.works/slides](https://riotz.works/slides/になります。


聴きに来てくださり、ありがとうございました。
スタッフの皆さま、支援ありがとうございました。

そして、ここまで読んでくださり、ありがとうございます。

Riots.works での JAMStack の利用

最近注目を集め始めている “JAMStack”、より良いパフォーマンス、より高いセキュリティ、より安価で簡単なスケーリング、より良質な開発者エクスペリエンスを提供するアーキテクチャ。

Riotz.works でも注目しており、実際に活用しています。今回は、この JAMStack を Riotz.works でどのように使っているかをご紹介します。

Riotz.works 公式ウェブサイト

公式ウェブサイトのトップページhttps://riotz.works、Works ページ、Engineers ページがGridsomeで JAMStack なサイト作りをしています。

Gridsomeは 2019年1月現在バージョン 0.4.5 で速いペースで開発が行われておりますが、必要な機能が未実装だったり、実行環境によってはさまざまな準備や設定が必要だったりします。
StaticGenでは 30位あたりになります。

数あるサイト・ジェネレーターからGridsomeを選んだのは、まずは Node.js で作られていること念頭に置きました。
これは Riotz.works では Node.js、主に TypeScript で開発を行っているため、スキルセットや開発環境を合わせたかったのがあります。

続いてVue.jsベースであることを選びました。
こちらも開発がVue.jsベースで行っているので合わせたかったものになります。

そうすると、比較的メジャーと思われるGatsbyJSHexoなどが落ちてしまいます。
GatsbyJSは非常に興味深いのですが、いつかは使ってみたいと思っていますが、今回はVue.jsベースとしました。

選択肢としてはNuxt.jsVuePressGridsome、VueWebsite になります。

Nuxt.jsはアプリ作成で使っていますが、ウェブサイトやブログ構築よりアプリ向けに感じます。
そうなるとVue.js公式であるVuePressが最有力になりそうです。

もうひとつのGridsomも調べたところ、“highly inspired by Gatsby.js”とあり、またVue.jsベースであることが、まさに私たちの考えと一致するものでした。

そしてデータソースを GraphQL で扱えるところが魅力的です。
入力ソースは基本的に Markdown を使いたいと考えていますが、エンジニアによっては CMS を使いたいケースもあるでしょう。このような複数のソースを GraphQL で扱えるのが助かります。

このような経緯から Riotz.works 公式ウェブサイトはGridsomで構築することにしました。

ただし、これまでの開発経緯から Articles と Slides はGridsomとは異なる技術を使っています。
リンクを踏むとヘッダーが異なるのはこのためです。Gridsomへ意向を考えてはいますが、なかなか着手できてない状況です。。

Riotz.works Articles ページ

Articlesページは、Hexoで作られた JAMStack なサイトです。

この Articles こそGridsomが活用できる場所ではあるのですが、Gridsomが登場する以前にHexoで作ったものになり、いずれはGridsomへ移行したいと考えてはいますが、Gridsomはまだ初期開発中で Category や Tags などのページを自前で作る必要があり、作りこみができてないです。(いずれ公式でサポートされるとは思うので待ちたいのもあり。。)

HexoStaticGenでもトップ5に入る人気のサイト・ジェネレーターです。

記事は Markdown で書けるので、エンジニア・フレンドリーといえるのではないでしょうか。
一方で表現力は落ちてしまう点がありますが、最後は HTML を直接書いて埋め込めるので、どうしても Markdown で表現しきれない部分は HTML でカバーできます。(あまりやりたくないので奥の手という感じですが)

ブログサイトをとても手軽に作ることができ、テーマも多数用意されているので好みのデザインにすることも簡単ですし、各種 Plugin もあるので簡単に拡張することもできます。

日本語の情報も多いので、比較的簡単にやりたいことや、困りごとを解決できます。

JAMStack なブログサイトをつくり始めるには、よい入口と言えるでしょう。

Riotz.works Slides ページ

[Slides](https://riotz.works/slides/ページは、静的サイトではありますが完全に手組の HTML で、”構築済みの HTML” とはなっておらず、アクセスを受けてから JavaScript で HTML を構築しているので JAMStack なサイトではありません。

こちらは、Markdown ファイルをソースとしたプレゼンスライドを作れるremark.jsを使っています。

仕組みとしては事前に用意された Markdown ファイルを、スライド形式の HTML に変換して表示なので、JAMStack とは相性が良く、JAMStack なスライドシステムがあったら使いたいと考えています。

Markdown からスライドを作るライブラリとしてはreveal.jsremark.jsぐらいで、どちらも事前構築の HTML には対応しておらず、現時点では現状のままか、時間を作って自前開発をしたいところです。

JAMStack なスライドシステムがあったら使いたいと考えていますが、現時点ではなさそうなので、しばらくは現状のままでしょう。

スライドシステムについては時間を作って自前開発にチャレンジしたいとも思っています。
ソースは Markdown で書きたいのがありますし、カジュアルな勉強会ではリアルタイムなフィードバック機能を動かしてみたいなど、いろいろとやってみたいことがあります。

ラップ、タップ、アップ 🎶

最後にハッカソンで作ったラップ、タップ、アップ 🎶ですが、こちらも JAMStack なアプリです。

技術としてはNuxt.jsを使っていて SPA で静的サイトとして生成、ホスティングしています。(SSR、サーバサイドレンダリングにすると JAMStack ではなくなります)
これにより基本的な画面は “構築済みの HTML” となり、CDN に配置した際のメリットを出せます。

ラップ対戦のルーム作成はクライアントサイドのJavaScript から Web API を呼出しています。
また動画の中継と配信も JavaScript のライブラリからサービスを呼び出しています。

ハッカソンの 24時間という限られた時間の中で、フロントエンドとサーバサイドを分離し HTML をツールを使って生成する JAMStack のアーキテクチャがまさに活かせた瞬間といえるのではないでしょうか。

サーバサイドの機能が Web API 形式で提供されているため、ロジックの変更や UI の変更といったものが相互に依存せず最小限の修正で組み込みできました。


JAMStack は公式ウェブサイトのような完全な静的サイトのほか、ブログやアナウンスなどのニュースといった緩やかな更新が発生するサイト、そしてアプリといったさまざまなサイトが実現でき、Riotz.works の中でも多様な使い方をしています。

とくにラップ、タップ、アップ 🎶のような、サイト・ジェネレーターで静的ホスティングなサイトを作っていて、Web API を呼び出しているようなケースは意外とあったりするのではないでしょうか。

実は JAMStack なサイトを作っていたけど、JAMStack のキーワードが知られてなく、そんな名前がついていたんだというケースがいろいろありそうです。(実はラップ、タップ、アップ 🎶作成時点では JAMStack の言葉は知らなかったです)

ただ、これだけ JAMStack な サイトと書いてきましたが 実はホスティングが GitHub Pages で、JAMStack ベスト プラクティスの CDN に 乗ってなかったりも。。

これまでの経緯から GitHub Pages を使ってて、またカスタムドメインを使っているほか、4サイト(リポジトリ)がのっかっているので一斉に引っ越しする必要があり、作業時間を作るのに苦慮しているためです。