ブログメンティ始まる

2019年4月1日、エイプリルフールであり新年度ながら新元号発表の日でもあり、年度末年度始な仕事を含め大忙しな日。
ご多忙な世間に負けず追い込まれていますが、カックさんにブログのメンターについていただいたお話。

ブログ メンター カックさん

カック @kakakakakku さん。
IT 関連のブロガーにして、ブログを書きたい人のメンターをされている方。
@lulzneko アカウントで活動を始める前から、情報収集の ROM アカウントでフォローさせていただいて、アウトプットの習慣をはじめたくさんの記事や登壇資料で勉強させていただいていた。

サーバーレス ヒーロー からの絶大の信頼も。

ブログ メンティー

今回、ブログ メンティを募集されているツイートを見て、思い切って応募し、メンターとしてついていただけることになりました。

実は @lulzneko は、いろいろなイベントで発表をさせていただく機会に恵まれているのですが、すごく引っ込み思案で、人見知りで。Twitter でリプも DM も手が震えるぐらい緊張して、緊張して、結局何もかけなかったりというタイプなのです。(Tw で反応薄そうなのも、悩みすぎで数日たってもう書くタイミングでないとか多くて。すみません💦)

それでも、自分が好きなITな話はたくさんしたくて。「だったら話せば?」と言われて思い切ったのが去年。思い切って話して、もっとたくさんのことをお話ししたくて、今年は「書いてみたら?」を思い切ったところでした。
そんな折に カック さんがメンティーの募集をされていて、思い切って応募し始まりです。(応募したくせにDMできょどってる)

さっそく始まった中で、まだ震え震え DM してる中「返事は無理にしなくても大丈夫です!ROM オッケー!気軽にいきましょ」と踏み出しやすいメッセージをいただきました。ありがとうございます。

調べたり、考えてたり、そういったことを発信していきたい。そんな年度初めであり、実践していきたいと思います。

目標設定と現在の状況

カック @kakakakakku さんとのお話で設定したこと。
「ブログを書く目標設定: 週1回を必達、週2回を目標とします」
⇒ “基本的にノルマは「技術系記事」とします”、“週1も了解です” とのこと

この記事はカウント外として、ITに関する技術系でしっかり書いていきたいと思います。

現在の状況。隔週でアップデートし、次からはグラフ化したいけどExcel。。。

  • 週間 PV
    • Riotz.works 全体 232
    • Riotz Articles 82
    • lulzneko の記事 78
  • はてブ総数 (https://hatebu-checker.net/url/ を利用)
    • Riotz.works 全体 29
    • Riotz Articles 10
    • lulzneko の記事 10
  • Twitter フォロワー数
    • lulzneko 158

しっかり教わり、ブラッシュアップして発信できるよう頑張りますので、生暖かい目線でお付き合いいただければと思います。

共有:

心に刺さる名刺のつくり方セミナー 〜東京編〜 参加レポート

2019年3月30日に開催された「心に刺さる名刺のつくり方セミナー 〜東京編〜」に参加したのでレポートです。

心に刺さる名刺のつくり方セミナー 〜東京編〜 概要

今回参加した 心に刺さる名刺のつくり方セミナー 〜東京編〜 は、ストーリージェニックな名刺デザイナーの「上司ニシグチ @a_design_link さん」と、ズルい名刺専門デザイナーの「くわたぽてと @potato_kuwata さん」が開催するイベントです。

大阪で開催され大人気だったイベントを、今回は東京での出張開催となりました。
たまたま ストーリージェニックな名刺の作り方 〜フォトグラファー 宇野さん編〜 の記事を TL で見かけ、興味を持っていたところでの東京開催となり参加させてもらいました。(チケットが一瞬で売り切れたのには焦りました。購入が間に合ってよかった💦)

基本的にはデザイナーさん、クリエイターさん向けのイベントですが「フリーランスとセルフブランディング」というキーワードから Riotz.works というブランディングに活かしていけたらという思いから参加しました。あとは Web系、フロント系のエンジニアさんに会えるチャンスがあったらラッキーかなぁと(SPAJAM 2019 応募のチーム作り)

主な内容

開場早々に名刺交換会が始まっており、到着早々に名刺交換というハードルの高いミッションが待っていました💦
会場は約60人の満席。最初のアンケートでクリエイターさんデザイナーさんが9割という感じです。高校生のデザイナーさんから業務で携わっている方と幅広く集っている感じです。この内容でエンジニア、しかもフロント系ですらない人が来るってのも珍しいかもしれません。

上司ニシグチさん&くわたぽてとさんの自己紹介

お二人とも大阪の人。
デザイン振興会のイベントで出会って意気投合して組んで活動されているのだとか。10歳年が離れているとのことですが、とても仲良く息の合った感じでした。いいなぁ。

上司ニシグチさんは、名刺専業ではないが ストーリージェニックな名刺の作り方 としてご活躍。
くわたぽてとさんは、名刺専業 大阪のズルい名刺専門デザイン事務所 ヤオヤ 屋さん。

お二人とも朗らかで楽しくて漫才をしているかのような感じでお話されており、楽しくて聞き入るのですが、うっかりすると楽しい思い出だけで、大事な内容が頭に残らない危険がはらむ予感の幕開けです。
(参加者が笑いはするけど、流石にツッコミまではないのですが、大阪でやった会ではどうだったんだろう。ドッカンドッカンいってる感じだったのだろうか)

名刺への愛を語る(名刺についての考え方)

お二人の名刺の歴史。

くわたぽてとさん
最初は一般的な名刺の形から入り、ビックリマンのシールのような形にしてみたところ反響が。「口下手でも心に刺さる名刺」という観点に気づき方向性を持つことに。3枚目で「くわたぽてと」になり、さらに4枚目で名刺は名刺入れから出すのひっくり返して自分で取ってもらう形に。
SNS 時代において名刺は連絡先を記載するのではなく、人の心に残ることが大事。

上司ニシグチさん
ガム、ファミコンカセット、タバコとガワから入っていった。手作りでカッターに手折り。すごい。
4枚目で電車の中吊り広告風にして自分を表現するキーワードを入れる形に。

“おもしろい名刺を持っていると、相手が話をしてくれる。口下手でも自分で話をしなくてよい”そして“名刺入れから名刺を出すを、ポテチの箱からとってもらうに逆転するだけでも話題に”と。
確かにその通りですね。私も初対面の人と話をするのが苦手なので、その観点からも名刺を考えていくって大事。IT エンジニアでは懇親会で困るなら登壇すればよいといわれているのと同じですね。

そして“SNS の時代だから連絡や話は SNS でする。名刺は SNS への導線”、“名刺は一番読んでもらえる媒体。知ってほしい情報を載せるべき”は、なるほど!と。
名刺はもらった時にすぐにしまわない(という慣習だ)から、またとりあえず目を通すし。そこに使いもしない電話番号が載ってるだけよりも、他の情報を載せているほうが意味ありますね。

名刺おそるべし。深いな。。

セルフブランディングの考え方 ⇒ クリエイターとして & 心に刺さる名刺のつくり方

デザイン論、お客さまとのコミュニケーション、価格の決め方、アイデアの出し方、これまでの作品など。QA を交えて。(※ 有料セミナーなのでちょっとだけ)

デザイン、これ実態は SNS、そこへの導線がメッセージ。“名刺はラブレター”。

ヒアリングはどうするか、これはシステムを作るうえでもどうするか悩ましいところ。結局のところ「自分が欲しいものは自分ではわかっていない」をサポートし引き出していくのが大事なんだよなぁ。

値下げはしないとのこと。大阪は値切りのイメージ(勝手にそう思ってる)けど、相談されても受けないとのこと。“自分でブランドを下げてしまうし、正規で購入いただいたお客さまに失礼”。まさに“人を見て値段を決めなない”ですね。
これはデザインの仕事にかかわらず共通でしょうし、企業勤めにだって大事なポリシー。

最後に名刺交換&交流会。
名刺のセミナーでありデザインのセミナーだけあって、みなさまステキな名刺を交換させていただきました。ありがとうございます。

とても勉強になりました。クリエイターさん向けとはいえ、エンジニアも個人開発などに手を出せばクリエイターに仲間入り。その視点で考えるとすべてが身になるとても良い時間でした。

Riotz.works の名刺

せっかくなので、私 @lulzneko / ラルズネコ の名刺と、仲間の @lopburny / ロップバーニー と [@javaponny / ジャバポニー](https://twitter.com/javaponny。
表面のベースは一緒、裏面が各々の SNS アイコン キャラクターになっています。
ITイベントで発表などの活動をするための名刺で、会社とは別のものになります。(なので名前がない💦)

今日のセミナーからすると「誰に何を伝えたいか」ができてない。それっぽく並んでるだけなので要見直しですね。。絵心もなくデザインもできない私が作ったものなので、ここらが頑張りの限界っぽいですが、せめて裏の写真の余白に何か入れようかな。最近は「サーバーレスなサーバーサイドのエンジニア」なフレーズが気に入っているから、あともう1つ「何をご提供できるか」を添えてって感じでしょうか。

そう考えると、大学のゼミの仲間たちの名刺は凄く考えられていすごいなと思い起こされる。

名刺管理って

そういえば名刺管理って皆さんどうしているのでしょう。
私は Eight - https://8card.net を使っています。
TV CM の名刺クラウドをやっている Sansan の個人向けサービスです。

セミナーでの通り、SNS にたどりつければいいから管理はあまりしていないのかな。
会社でも電話自体使うこともなくなってきたし、覚える、思い出してもらえるツールという位置づけになってきたというのもあるよなぁと。

Eight さんは、認識精度がよく日経と連携してニュースが見られて良いです。ただし Riotz.works 名刺のように2つの名刺がある場合に管理できないのがちょっと不便。
複数持ってる人ってあまりいないのかなとも思いますが、兼業もあるだろうしなぁ。

結局。会社名刺のアカウントに追加されるので、Riotz.works 名刺で交換しても、相手には後日交換した覚えのない名刺が通知されていたりします。

さりとて Riotz.works 名刺を追加すると転職した通知が流れてしまうので、それはそれで混乱させてしまうし。
実際に企業勤め+起業された方が、起業した会社の名刺を追加したとので転職通知になり問い合わせが殺到したとのことで元の名刺を追加しなおして再転職通知をされてました。

SNS 時代に合わせた、良い名刺管理方法があるとよいのですが。


IT 関連のイベントやセミナーではない場所、しかも参加者で名刺交換会ありということで、ちょっと緊張しましたがとても楽しい会でした。

自分メモとして、スライド写真も交えしっかり記録しておきたいところなのですが、有料セミナーなのでブログとしては、ちょっとだけ。とはいえ、どっかには残しておきたいので管理の仕組みを作ることを考えねば。

上司ニシグチ @a_design_link さん、くわたぽてと @potato_kuwata さん素晴らしいセミナーをありがとうございます!

参加者の皆さん、名刺交換ありがとうございます!!
QA やツイートに名刺交換時のお話しなど勉強させていただきました。ご一緒できてよかったです。


次回は、2019年4月3日(水) 18:30~ Shiftup! JP_Getshifter Vol3!はじめてのスタティックサイトジェネレーター で『JAMStack で構築・運用するサーバーレスなウェブフロント』のお話をします。 もしよろしければ、お越しください。

サーバーレスWordPressのShifterさんに、Gatsby、Gridsome の話もある勉強会です。
自前のブログを作ってみたい方、ウェブフロントに携わってみたい方にはおススメ!

  • Serverless Static Site Generator「Shifter」のデモ&紹介
  • GatsbyとSurgeでHello World! スタティックサイト ホスティングって?
  • JAMStack で構築・運用するサーバーレスなウェブフロント
  • こんなに簡単Gridsome!
共有:

TSLint の prefer-function-over-method ルールについて悩む

コーディングをしていく上で良いお作法でできるようにしたり、チーム開発でスタイルを合わせたりするために Lint 系のツールを使います。今回 TypeScript で開発をしていて、TSLint のルールを厳しくしたところチェックに引っかかったところが出たのですが、ルールの意図を汲み取れず悩み中の備忘録。

環境
開発者の環境は以下となります。

  • Windows 10 64bit + WSL Ubuntu 18.04.1 LTS
  • Visual Studio Code
  • Node.js 8.10.0
  • Yarn 1.13.0
  • TypeScript 3.3.4000
  • TSLint 5.14.0

TSLint 概要

TSLint はTypeScript コードの読みやすさや保守性を維持するための静的分析ツールです。
不具合を起こしやすいコードを指摘したり、コーディングスタイルをそろえるためのチェックなどをしてくれます。

TSLintTypeScript に特化してチェックしてくれるのですが、最近では TypeScript 開発チームのロードマップESLint、JavaScript/ECMAScript 用の Lint をサポートしていくことが発表され、ESLint からも TypeScriptESLint 対応への歓迎とチームメンバーが開始した typescript-eslint プロジェクト についての記事が公開されます。

今後は ESLint を使っていくことになるかと思いますが、安定するまでは TSLint を使っていくのかなと思います。
TSLint プロジェクトでも、移行に関するイッシュー Roadmap: TSLint -> ESLint · Issue #4534 · palantir/tslint が上がっており、一時的にはオーバーラップする期間が発生して、一時的には両方のツールを使うことが推奨されています。

新しいプロジェクトの typescript-eslint を使う方法については、@typescript-eslint ことはじめ - teppeis blog さんが詳しいです。

prefer-function-over-method ルールと発生した事象

今回悩みの種となったのが、TSLintprefer-function-over-method ルールになります。

TypeScript でクラスメソッドを作った時に this を使わなかった場合に Class method does not use 'this'. Use a function instead. という指摘をしてくれます。

以下のコード例では ok メソッドは this.templatethis を使っているので問題ありません。一方で ng メソッドは this を使っていないので prefer-function-over-method ルール違反となります。

1
2
3
4
5
6
7
8
9
10
11
12
export class Action {

private readonly template = 'Hello %s !!';

public ok(name: string): void {
console.debug(this.template, name);
}

public ng(message: string): void {
console.debug(message);
}
}

まぁ、確かに ng メソッドのほうは内部状態を触っていないので static なりにしたほうがよさそうです。

悩み事

ここで気になって悩んでいるのが “static にすべき” ではなく、”function にすべき” とメッセージが出ている点です。

つまり、下記のような修正ではなく (必要箇所のみ抜粋)

1
2
3
4
5
export class Action {
public static ng(message: string): void {
console.debug(message);
}
}

このようにする (必要箇所のみ抜粋)

1
2
3
4
5
export class Action {
public ng = (message: string): void => {
console.debug(message);
}
}

ルールの名前も prefer function over method だから、メソッドより関数を優先して使いましょうということなんですよね。。。

クラスの中に関数を書いても文法上問題はないわけですが、どうして static ではなく関数なのかなと。せっかくなので理解しておきたいのですが、prefer-function-over-method は Rationale、論拠の項目が書かれてないのです。

たとえば only-arrow-functions ルール「JavaScript の伝統的な関数定義ではなく、アロー関数を使いましょう」ですが、以下のように書かれています。

Rationale
Traditional functions don’t bind lexical scope, which can lead to unexpected behavior when accessing ‘this’.

this へアクセスしたときに予期しない動作を引き起こす可能性があるから、といった説明がされています。
この文章だけだとわかりにくいかもしれませんが、これをもとに調べることもできます。

しかしながら、prefer-function-over-method は Rationale が書かれていない以上、どのように扱うのが望ましいのかゼロから調べるしかないわけです。

  • ルールに従い関数に修正する
  • ルールの修正方針とは異なるが static にする (これでも指摘はなくなる)
  • ルールがプロジェクトにマッチしないので無効化する

ESLint では、どうなる?

この疑問をつぶやいたときに、お仕事チームの仲間が ESLint の情報で応えてくれました!(ありがとうございます)

typescript-eslint/ROADMAP.md at master · typescript-eslint/typescript-eslint に TSLint と ESLint の対応表があるとのことで、prefer-function-over-methodclass-methods-use-this にあたるとのこと。

では、ESLint の class-methods-use-this はどうなっているかというと「static メソッドにすること」。
メソッドと関数が混在するよりも、メソッドに統一して static と分けて実装するとのことで、わかりやすいです。

しかしながら、こちらも論拠は書かれてませんでした。
「関数を使う」という選択肢がなければ、そうだよねってことで static メソッドにするのですが、今回は関数が使えることを知ってしまったので「static と関数のどちらにすべきか」という疑問が生じてしまいました。困った。

TypeScript のコンパイル後を確認する

Lint ルールに明確な論拠がないので、出力された JavaScript/ECMAScript を見て考えたいと思います。
TypeScript のソース。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
export class Action {

private readonly template = 'Hello %s !!';

public ok(name: string): void {
console.debug(this.template, name);
}

public ng(message: string): void {
console.debug(message);
}

public ngFunction = (message: string): void => {
console.debug(message);
}

public static ngStatic(message: string): void {
console.debug(message);
}
}

コンパイルされた結果。
※ ターゲットはクラス構文が導入されていない ES5 にしています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
var Action = (function () {
function Action() {
this.template = 'Hello %s !!';
this.ngFunction = function (message) {
console.debug(message);
};
}
Action.prototype.ok = function (name) {
console.debug(this.template, name);
};
Action.prototype.ng = function (message) {
console.debug(message);
};
Action.ngStatic = function (message) {
console.debug(message);
};
return Action;
}());
exports.Action = Action;

結果を見ると指摘のあった ng メソッドは Action.prototype.ng に関数として追加されています。
TSLint の prefer-function-over-method にしたがって関数に修正した ngFunction はコンストラクター内で this.ngFunction に追加されています。
ESLint の class-methods-use-this にしたがって static にした ngStaticAction.ngStatic に追加されています。

こうしてみると以下の順が良さそうです。

static にすればクラスレベルで追加されるので効率が良いでしょう。
メソッドと関数の違いについてですが、関数にすると各インスタンスに関数が追加されています。それに対してメソッドは prototype に追加しています。とくに理由がなければ prototype に追加したほうが良い(はずだったと記憶)。
この辺の裏付けができていないのと、クラウス構文が入ってからも変わりがないのかはわからないので、決定打とはならないですが説明の方針としては1つ線が引けそうです。

現在の状況

この記事を書いている時点での対応は以下としました。

  • static にできる場合は、static メソッドにする
  • static にできない場合は、ルールを無効化してメソッドにする

今回、継承して実装するメソッドが一部指摘されていました。
簡易フレームワーク的な作りになっていて、親クラスから決められた abstract メソッドを実装するようになっており、その部分が引数だけで this を使わないで完結できるような処理になったりもします。
この部分は // tslint:disable-next-line: prefer-function-over-method でルールを無効化してメソッドのままとしました。

参考情報


Lint 系のツールはコードに対して指針を与えるので、やはり論拠が欲しいところですね。
とくにいくつかの選択肢が出てきてしまうと、いろいろと考えてしまいます。

今回は残念ながら TypeScript力というか、JavaScript/ECMAScript力がたりなくて明確な根拠を持って指針化できませんでしたが、考え方は整理できたように思います。
裏付けをとるのは、ちょっと難しいかな。。

Validate TypeScript による入力データ検証を試す

Web API で リクエスト パラメーターなりボディでクライアントからデータを受け取るケースがあります。
その際にリクエストを受け付けてよいか入力データの検証(入力チェックとか呼んだりも)しますが、最近 Validate TypeScript というライブラリを試してみたので ご紹介。

環境
開発者の環境は以下となります。

  • Windows 10 64bit + WSL Ubuntu 18.04.1 LTS
  • Visual Studio Code
  • Node.js 8.10.0
  • Yarn 1.13.0
  • TypeScript 3.3.4000
  • validate-typescript 4.0.1

Validate TypeScript 概要

Validate Typescript - https://github.com/Grant-Zietsman/validate-typescript はスキーマベースのバリデーターで、JSON などのオブジェクトの値や型をチェックすることができる Node.js のライブラリです。MIT ライセンスの元 OSS で公開されています。
豊富な検証ルールをあらかじめ備えているほか、自分で拡張した検証ルールを使うこともできます。

Web API をはじめ、ウェブでリクエストを受け取る機能を作った場合に、クライアントからリクエストしてきた内容を受け入れてよいかチェックする必要があります。
たとえばメールのアドレスは半角の英数字から始まり@が間にあって、ドメイン名のルールが(実際にはもっと複雑)などと形式があっているかチェックする必要があります。他にもドロップダウンから選択したデータが選択できる範囲の値であるか(不正データを送ってきてないか)や、必須入力ではないけど送ってきたら数値である必要がある、などと単純な型チェックだけでもいろいろとやることがあります。

Validate Typescript は、その「型チェック」を支援してくるライブラリになります。(逆に言うとメールアドレスが存在するかのチェックや、DB に存在する値との整合性、入力データ間の整合性などはしてくれません。こちらはこちらで必要なことは別途実装する必要があります。)

その「型チェック」ですが色々なやり方があります。各リクエストパラメーターごとにチェックの関数を呼び出したり、リクエストパラメーターに対応するクラスを定義してデコレーター(アノテーション)を付けたり。z
今回 Validate Typescript に着目したのは “スキーマベース” という点で、スキーマをコード内のオブジェクトで渡せるところが良いと思い使ってみることにしました。

こちらのライブラリを使おうとしたところ、インストールエラーが出てしまってプルリクを出して直してもらったことがありました。詳しくは「Validate Typescript に インストールエラーの修正についてのプルリクを送る」の記事になります。こうしてプルリクで改修や機能の提案できるのが OSS のよいところですね。

Validate TypeScript のインストールとサンプルコード

インストールは Node.js プロジェクトで NPM パッケージとして導入します。
yarn add validate-typescript
(npm の場合は npm install validate-typescript)

公式のサンプルコード 抜粋(一部修正)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
import { Alias, Email, ID, Optional, Options, RegEx, Type, validate } from 'validate-typescript';
import { AssertionError, ValidatorError } from 'validate-typescript/lib/errors';

const zaPhoneNumber = (): string => Alias(RegEx(/^((\+27|0)\d{9})$/), zaPhoneNumber.name);

class CustomMessage {
public message!: string;
}

const schema = {
id: ID(),
children: [ID()],
username: Type(String),
email: Email(),
gmail: RegEx(/.+@gmail.com/),
phone: zaPhoneNumber(),
gender: Options(['m', 'f', 'o']),
married: Type(Boolean),
names: {
first: Type(String),
middle: Optional(Type(String)),
last: Type(String)
},
message: Type(CustomMessage)
}

const data = {
id: '17s',
children: [1, 2, '3s'],
username: 'solomon',
email: 'solomon@validate-typescript.com',
gmail: 'solomon@gmail.com',
phone: '+27824392186',
gender: 'm',
married: true,
names: {
first: 'Solomon',
last: 1
},
message: Object.assign(new CustomMessage(), { message: 'Sawubona Mhlaba' })
};

try {
const input = validate(schema, data);
console.debug(input); // no validation error
} catch (error) {
console.debug(JSON.stringify(error)); // validation error

const violations: ValidatorError[] = [];
JSON.parse(JSON.stringify(error), (key: string, values: ValidatorError[]) => {
if (key === 'child_errors') {
Array.prototype.push.apply(violations, values.filter((value: ValidatorError) => value.property ? value : undefined));
}
return values;
});

for (const violation of violations) {
console.debug('%s=%s %s', violation.property, violation.value, (violation.child_error as AssertionError).details);
}
}

前半の zaPhoneNumber はカスタムの入力検証で南アフリカ共和国の +27 または 0 始まりの電話番号チェックです。
CustomMessage はデータ構造の一部をクラスとして表現し、オブジェクトリテラルとの複合を試している感じでしょうか。

const schema が本題の入力検証でチェックするデータスキーマです。
データとして受けとるキー: 入力検証のルール という形式で記述します。
たとえば id: ID() は入力データ id というキーに ID() の形式(実態は数値)になっているかをチェックするといった具合です。
Type(String) のような単純な型チェックや、Email() などの組み込み型、RegEx() による正規表現のチェックなどがあります。
また必須ではないが受け取った場合はチェックするの Optional() に、来た場合のチェックを引数にルールを入れる。
具体的な値の選択肢である Options() などもあります。
ひととおりのチェックルールはまかなえています。

サンプルでは const data で入力データを記述していますが、実際には Web API などを作っているフレームワークなりの入力を受けて、validate(schema, data); を実行します。
入力検証が通ると value が戻り値で返ってきますが、問題がある場合はエラーがスローされてくるので呼び出すだけでもよいかもしれません。

問題があった場合のエラーの受け取りですが、ValidatorError と AssertionError の再帰構造となっているようです。
入力データの構造が深くなると、それに合わせて child_errors という形でエラーも深くなるようになっています。
必要な部分だけを抜粋すると以下のような構造になります。下記は id の値が数値でなかった場合のエラーです。

1
2
3
4
5
6
7
8
9
10
11
12
{
"message": "Validate TypeScript",
"validator": "ID",
"property": ".id",
"value": "17-error",
"child_error": {
"message": "Validate TypeScript",
"value": "17-error",
"converter": "toInt",
"details": "could not be converted to an integer"
}
}

propertyvalue で、キーと受け取った値がわかります。(キーの先頭にドットがついてますが)
child_errordetails にエラーメッセージが入っています。英語ですが、そのまま使えそうな感じです。

ただしデータの階層が深い場合は、このデータ構造が child_errors という形で深く連なっていくので、そのままでは扱いにくいです。
そのためサンプルに加えて以下のようなコードを追加してフラットに変換しています。

1
2
3
4
5
6
7
const violations: ValidatorError[] = [];
JSON.parse(JSON.stringify(error), (key: string, values: ValidatorError[]) => {
if (key === 'child_errors') {
Array.prototype.push.apply(violations, values.filter((value: ValidatorError) => value.property ? value : undefined));
}
return values;
});

JSON をパースする際に reviver 関数 を使って child_errors から property が存在する場合に、その値を取得して配列で保持するようにしています。
reviver 関数 は JSON をパースする際に値を変換することができるのですが、再帰構造から必要なものだけをうまく引き出せなかったので、横から取り出すようにしました。
これで具体的な入力検証エラーの部分だけを取り出せるたので、必要に応じてレスポンスするためのオブジェクトに詰めなおすことができます。


シンプルなスキーマで、その場に書けるのでコーディングがしやすくきになるらいぶらりなのですが、入力検証エラー時の構造体がちょっと扱いにくいのと、エラーの型定義がサブモジュールのインポートになってしまうため、TSLintを厳しくしていると怒られるという点があり気になりました。

入力検証は似て非なるデータ構造のチェックになり、クラスのデコレータベースは使いにくいと思っているので、スキーマベースという点が気に入っているのですが、エラーのデータ構造がちょっと気になります。
とくに同じキー child_errors に入っていて property があるかないかで、末端のエラーが情報か、中間のコンテナーかを判別しないといけないのが、あとからコードを見た時に何をしたいのか分かりにくいだろうなぁと。

もう少し使いやすいものを探してみつつ、時間切れとなったら Validate Typescript を使わせてもらおうかな。

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 が起動してマスターメンテしていました。これは便利。
またローカルサーバとのインテグレーションには ngrok https://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 がリストされているのが 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 で発表させていただくのははじめてで、とても良い経験をさせていただきました。
オープンな会場と小さめのマイクの音に、いつもの雰囲気が違うので上手く話ができるのか不安と緊張が入り混じった感じで発表に入りました。出だしで噛んでしまったところから吹っ切れた感もでて、勘が戻ってきて話ができたと思います。

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

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