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] が フォークした自分のリポジトリ&作業ブランチになっていることを確認
  • プルリクのタイトルと内容を記入

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

一晩でマージされた!

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


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

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

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

Author: lulzneko

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 が 起動してマスターメンテしていました。これは便利。
またローカルサーバとのインテグレーションには ngrok https://ngrok.com を 使ったとのこと。こちらはローカルのポートをウェブサービスとして公開できるようにします。

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

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

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

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


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

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

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

会場 の 風景

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

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

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

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

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

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

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


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

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

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

Author: lulzneko

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 が そのままつけるのがありがたいです。

Author: lulzneko

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 します)

サーバーレスを専門でやっているので「フロントもサーバーレスで」というキーワードを使うこともあるのですが、今一つ伝わりにくかった。どうしたら伝わるのか、何か共通のキーワードはないのか、そう思っているさなかに 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 が リストされているのが StaticGen https://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/Maven pom.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 で 発表させていただくのは初めてで、とても良い経験をさせていただきました。
オープンな会場と小さめのマイクの音に、いつもの雰囲気が違うので上手く話ができるのか不安と緊張が入り混じった感じで発表に入りました。出だしで噛んでしまったところから吹っ切れた感もでて、勘が戻ってきて話ができたと思います。

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

Author: lulzneko

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

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

Author: lulzneko

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 を使った既存の運用は残したまま、全く新しいサイトへ生まれ変わらせることができます。

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

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

ただし、コメント機能が使えなくなります。静的サイトになってしまうので仕方がないものになります。
私たちは Disqus というサービスを使ってコメント欄を設置しています。広告が出たりするので、もしかしたらサイトのブランディングと合わないかもしれません。

発表資料では 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 や メンションいただけたら幸いです。

Author: lulzneko

発表者は、その日何をしていたのか - 発表の舞台裏 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 の 配置 の章で使うものが 間に合ってなかったというレベルなのですが、慌てて Power Point を 操作する朝から始まりました。
なんか、前回 の デブサミ舞台裏 でも同じことを書いた気がします。

なお、前日の 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 に なります。


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

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

Author: lulzneko

デブサミ 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 や メンションいただけたら幸いです。

Author: lulzneko

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


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

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


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

シリーズの記事

デブサミ概要

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

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

会場入り

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

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 に なります。


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

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

Author: lulzneko

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 ページは、静的サイトではありますが完全に手組の 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サイト(リポジトリ)が のっかっているので一斉に引っ越しする必要があり、作業時間を作るのに苦慮しているためです。

Author: lulzneko