lulzneko
プレゼンテーション

Shiftup! JP_Getshifter Vol3！ にて「JAMstack なサーバーレス・ウェブフロント」について発表をしました

2019年4月3日に開催された「Shiftup! JP_Getshifter Vol3！はじめてのスタティックサイトジェネレーター」で『JAMstack で構築・運用するサーバーレスなウェブフロント』と題して、JAMstack の世界について発表をしました。そのサマリーです。

シリーズの記事

Shiftup! JP_Getshifter Vol3！はじめてのスタティックサイトジェネレーター 概要

発表したイベントShiftup! JP_Getshifter Vol3！はじめてのスタティックサイトジェネレーターは、サーバーレスな WordPress ホスティングShifterのユーザーコミュニティの勉強会です。

会場は決済サービスのStripeさん。原宿は竹下口交差点のステキなロケーション＆最高な眺めのオフィスで、お隣の東郷神社の桜がとてもキレイでした。

発表させていただくことになった経緯は、JAWS DAYS 2019で『AWS x JAMstack で構築・運用する サーバーレスな Web Front』の発表をした際に、Seiji Akatsuka(@seijiakatsuka)さんが聴いてくださっており、再演として本イベントに誘っていただいたのがきっかけです。

実は Shifter さんとは、この JAWS DAYS 2019 よりも前にも縁がありまして、Serverlessconf Tokyo 2017で『Java チームが選択した TypeScript による AWS Lambda 開発』で発表した際にスポンサーをされていて出展ブースでお話をさせていただいたことがありました。
WordPress をサーバーレスで動作させるというコンセプトに感嘆し、エンジニアとしてその技術に興味を持っていろいろと聞かせてもらっというのがあり、まさかの２年越しの再縁で発表の機会をいただくとは。

Serverlessconf Tokyo 2017 での発表『Java チームが選択した TypeScript による AWS Lambda 開発』の資料はこちらになります。

今回のイベントでは JAMstack で フロント系の発表をしましたが、本業はサーバーレスなサーバーサイド エンジニア を しています。こんなことをやっているんだという感じで眺めていただけましたら幸いです。

発表資料

『JAMstack で構築・運用するサーバーレスなウェブフロント』の発表資料はこちらになります。

サマリー

発表の主旨は「スタティック・サイト・ジェネレーターの世界、JAMstack を知ろう」です。
JAWS DAYS の発表資料を流用していますが、勉強会のテーマは「はじめてのスタティックサイトジェネレーター」なので、話の内容としてはスタティック・サイト・ジェネレーターが作り出している世界である JAMstack という概念を知ってもらいたいになります。よりスタティック・サイト・ジェネレーターを活用してほしい、そして JAMstack という用語を広めてほしいという思いになります。

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

  1. JAMstack とは
  2. AWS のサービスと JAMstack の対応
  3. JAMstack の可能性

JAMstack とは


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

JAMstack の定義

  • JavaScript of client side で、Web API の利用や画面の変更はクライアントで行う
  • APIs of resusable で、データの提供は再利用可能な Web API で行う
  • Markup of prebuilt で、Markup = HTML は事前に構築して CDN に配置する

JavaScript と API はわかりやすいですが「事前に構築した HTML」はちょっとピンと来ないかもしれません。
この事前に構築するため、本イベントのテーマであるスタティック・サイト・ジェネレーターが重要な役割を担います。

スタティック・サイト・ジェネレーターを使うことで、ウェブサイトの構成を HTML として生成できます。これの反対は、サーバー サイド レンダリング で ブラウザからのリクエストを受けてから サーバー側で HTML テンプレート を 使って 動的な値を埋め込みして HTML を 作り出す方法になります。WordPress が まさにそうです。

WordPress をはじめ、リクエストのたびにサーバーで HTML を作っているとパフォーマンスが悪いです。それをスケールさせるには大変な努力が必要です。よく「WordPress を複数台でスケールさせるには」みたいな話が出ますが、結構大変ですよね。。。

またリクエストを受けて処理する部分があるので攻撃にさらされることにもなります。WordPress でしたら WordPress 自体のセキュリティもあれば、PHP のセキュリティ、ウェブサーバーに、管理画面の保護と考えることがたくさんあります。

では逆に DB のコンテンツすべてを HTML に書きだしてしまって、CDN に配置してしまったらどうでしょうか。それが JAMstack の考えになりスタティック・サイト・ジェネレーターがやってくれることになります。
すでに HTML なので、リクエストを受けるたびに HTML を生成する必要もなく、また CDN が利用者に近いところから配信してくれるので非常にパフォーマンスが良いです。静的な HTML なので攻撃する箇所がありません。
(厳密にいうと、攻撃対象に CDN がありますが責任の範囲外なので)

つまりスライドに上がっているメリットが享受できることになります。

では、JAMstack なサイトを作るためのスタティック・サイト・ジェネレーターはどう入手するのかというと、StaticGenhttps://www.staticgen.comのサイトにたくさんそろっています。
オススメとしては以下でしょうか（すごく個人的な主観です）

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

AWS のサービスと JAMstack の対応

JAMstack の定義、ベストプラクティスは AWS のサービスがカバーしてくれるので、本格的なサービスを作る時は AWS を使うとよいでしょう。本イベントはウェブサイトがターゲットとなるのでちょっとオーバースペック気味ですが、全体感をとらえるイメージで見ていただけばと。


自前の Web API も含めたフル構成のイメージになります。
スタティック・サイト・ジェネレーターは Nuxt.js で動的な Web API のデータを利用する形になっています。
ウェブサイトではなく動的な要素をたくさん使うサービスやアプリを作る時には Nuxt.js を使うと作りやすいです。


情報発信するためのウェブサイトのイメージになります。
ローカルにあるマークダウンのファイルを記事としたブログなどのサイトを作る感じなります。配置場所は AWS の CDN である CloudFront になっていますが、Netlify や GitHub Pages などを使うと手軽に作れます。


WordPress で記事を管理しつつ新しいウェブサイトを作ったり、既存の WordPress サイトを JAMstack としてリニューアルするイメージになります。

Shifter のミニ版を自前で作る感じになります。ただし、大事なのが WordPress をどう守るか。
このパターンだと結局 WordPress の運用は残るので、運用の負担は発生しますし攻撃を受けないようにしなければならない。仮に内部ネットワークに持って行けたとしても、内部犯もあるのでセキュリティ確保は必要です。

そうなると、Shifter を使わせてもらうのが楽で良いでしょう。フリープランもありますし。
既存で WordPress を持ってしまっていて、それでもリニューアルして静的サイト化したいというケースでは、ありです。

JAMstack の可能性

一番向いているのは「情報発信サイト」で、もうひとつが「ウェブアプリのフレーム」です。
ウェブアプリのフレームですが、たとえば私たちが作ったラップ・バトルの『ラップ、タップ、アップ 🎶』は Nuxt.js で作っており、動画を扱う部分がクライアントサイドの JavaScript であとは静的なHTMLでできています。
このようにサービスと組み合わせると多くのケースで JAMstack なサイトが対応できます。

一方で「SEO 重視で CGM(Consumer Generated Media) や変化の激しいコンテンツ」には向かないです。
JAMstack は HTML を 事前ビルドするので、変化の激しいコンテンツには処理が追い付かず向きません。
そうなるとフレームだけ JAMstack にしコンテンツは Web API 経由になりますが、SEO 関連のヘッダーは HTML である必要があります。HTML にするには JAMstack のように事前ビルドするか サーバー サイド レンダリング、サーバ側で HTML テンプレートに値を埋め込んで HTML を 生成して返す形が必要となります。

まとめ

QA

ブログのコメント機能のようなものは API 経由になりますか？

はい。クライアントサイドの JavaScript から API 経由で実現します。

※ 本記事投稿時追記
発表資料で引用した The JAM Stack でも API Economy として紹介されています。会場提供してくださった Stripe さんも入っています。

JAMstack はサイトをいかに安全で高速に配信するかという点にフォーカスしていますが、動的なものを持ってはいけないということではなく、静的化できるものは可能な限り事前ビルドして CDN に配置し、動的なものはクライアントサイドのJavaScript でサービスを使いましょうということになります。

再利用可能な API が REST になっていますが、GraphQL はどうでしょうか？

「再利用可能な API」でしたら REST に限らず GraphQL を使うこともできます。
今回の発表で「REST API」と私が話をしたのは、普段 REST を使っているから出てきたもので、再利用可能な API でしたら GraphQL や他の方法でも OK です。

エゴサ

いろいろな記事ありがとうございます🙏　とても嬉しいです😆

4/3 Shifterミートアップ はじめてのスタティックサイト ジェネレーター まとめ - Togetter
共感いただけたり、的確なコメント、フィードバックさまざまなツイートをいただき嬉しいです！！

gridsomeのススメとShifterの可能性について – Photosynthesic blog
発表者の青空俯角 / mimi(@miminari)さんのブログです。
“先生” とつけられてしまうと気恥ずかしいです💦
記事中の「Shifter アップデートからの話」は次の記事で書きます。
まとめていただきありがとうございます！！

JAMstackとスタティックサイト サイトジェネレーターに酔いしれた一夜 JP_Getshifterミートアップレポート | デジタルキューブ
運営のSeiji Akatsuka(@seijiakatsuka)さんの記事です。
全体のまとめ、写真ありがとうございます！
そして素晴らしいイベントで発表する機会をいただき、ありがとうございます！！

こちらは JAWS DAYS で JAMstack について発表した際に、グラレコを描いていただいたツイートになります。本イベントではないのですが、話の内容を２ページでキレイにまとめて下さり とても分かりやすいので、この記事にも入れさせていただきました。ステキなグラレコ、ありがとうございます！

このグラレコを描いてくだった近藤佑子🐱技術書典6 か66(@kondoyuko)さん、2019年月14日の技術書典６でこれからはじめる 静的サイトホスティング、各種クラウドサービスを活用した静的サイトホスティングの入門書（GitHub Pages、Firebase、Netlify、Amazon S3）を頒布されるそうです。いろんなホスティングのパターンがあるのでおもしろそうです。

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

いろいろなイベントで発表させていただいてきたのですが、勉強会での発表ははじめててでドキドキでした。
しかも普段開発で使っている Serverless Framework のメンテナーにしてサーバーレスの神のひとりhorike takahiro(@horike37)さん、発表後に知りましたが関西の AWS 他各種イベントのオーガナイザーhiroramos☁️CPC☄️💫🌎(@hiro_baila)さん、発表者の青空俯角 / mimi(@miminari)さんも WordCamp Tokyo 2019 の実行委員長とすごい人たちが集っている会であり緊張ものでした💦

とはいえ発表中はKOGA Hiromichi(@digitalcube)さんの絶妙なツッコミやフォローが入るライブ感ある感じでとても楽しめました。ありがとうございます。

イベントにご参加いただいた皆さま、貴重な機会を作っていただいた運営の皆さまに感謝です！ ありがとうございす！！

IT カンファレンスなどの大きいイベントも楽しいですが、小規模な勉強会ではテーマを絞って話をしたり、発表者とディスカスしたりできます。この記事やツイートが勉強会への参加のきっかけとなりましたら幸いです。

Author:lulzneko

lulzneko
レポート

Shiftup! JP_Getshifter Vol3！ 参加レポート

2019年4月3日に開催された「Shiftup! JP_Getshifter Vol3！はじめてのスタティックサイトジェネレーター」に参加したのでレポートです。

私も「JAMstack で構築・運用するサーバーレスなWeb Front」で発表をさせていただきましたが発表レポートの記事は別途。

当日の様子まとめ
4/3 Shifterミートアップ はじめてのスタティックサイト ジェネレーター まとめ - Togetter

シリーズの記事

Shiftup! JP_Getshifter Vol3！はじめてのスタティックサイトジェネレーター 概要

今回参加したShiftup! JP_Getshifter Vol3！はじめてのスタティックサイトジェネレーターは、サーバーレスな WordPress ホスティングShifterのユーザーコミュニティの勉強会です。

Shifter の紹介やユーザーさんの話ほか、クラウドやサーバーレス、スタティックサイトジェネレーターなどに携わる人の話が聞けるイベントです。

会場は決済サービスの Stripe さん。
竹下通りと明治通りがつながる竹下口にあるステキなロケーション＆最高な眺めのオフィスでした。(写真撮るのを忘れてしまった)
竹下口のバーガーキング(現ロッテリア)でバイトしてた懐かしい思いでの道を通りつつ会場入りです。

参加者が集まるまで、緩い感じ交流タイムから始まります。

主催者のKOGA Hiromichi(@digitalcube)さん、Seiji Akatsuka(@seijiakatsuka)さんにご挨拶 ＆ 登壇者の青空俯角 / mimi(@miminari)さんさんとお話させていただきつつ、資料の事前アップが終わってなかったので〆の作業をしちゃいます。

徐々に集まってきた参加者さんと名刺を交えて、しばしご歓談。
今回は「発表者の～」と言いながら名刺を出しているので覚えていただける率は非常に高いですが、確かにこのような場面では先日受けた心に刺さる名刺のつくり方セミナーを活かした名刺づくりなり交換の仕方が大事になるなぁとさっそく実感。

Serverless Static Site Generator「Shifter」のデモを含めた、基本的な使い方の紹介

KOGA Hiromichi(@digitalcube)さん、Seiji Akatsuka(@seijiakatsuka)さんによるオープニングセッションです。

まずは本イベント Shiftup! の紹介
「ビール大事！たまに仕事」とのことで、さすが Happy Beer Taster を名乗っておられるKOGA Hiromichi(@digitalcube)さんさん。本イベントも会場入りしてすぐにビールが渡されるぐらいおもしろいポリシーです。

イベントの主旨

  • コラボレーターとの交流
    デザイナー、エンジニア、パブリッシャー、ビジネス、マーケターと幅広く多様なユーザーおよびユーザー間の交流が目的。
  • 情報共有
    利用の仕方、メリット、注意ポイント、アップデート情報などを共有する。
  • ディスカッション・課題解決
    スタティックサイト？JAMstack？サーバーレス？などの旬の情報から、Shifter の改善、機能リクエストなど。Shifter はコミュニティドリブンで機能が追加されている。

Shifter の紹介
“静的サイトジェネレーターとサーバーレスアーキテクチャを世界でもっとも人気のあるCMSと組み合わせたWordPressホスティングソリューション”

コンセプト
“JAMstack にヒントを得て WordPress でやることを考えた” とのこと。
とうの JAMstack の人たちから、WordPress は JAMstack ではないといわれているが、それを実現してるのが Shifter。このコンセプトはおもしろいです。

なぜ、このようなサービスを提供しているのかというと “価値あることだけに集中する！” ため。
WordPress はツールであり、WordPress 自体を使いたくて使っているわけではない。WordPress を使って価値あることをやりたくて使っているとのこと。

まさにその通りですね。ブログをはじめ情報発信としてのウェブサイトなどを作ることが目的であり、そのために WordPress を使う。
WordPress で作られているサイトもたくさんあります。それをサービスとして提供してくれて安全に管理しておいてくれる。とてもありがたいことです。

ブログサイト作りたくてレンタルサーバで WordPress を構築しているケースとかを見ると、ちゃんとパッチあてしているかなとか、不安になりますが Shifter なら安全に管理してくれているのと、記事投入後は静的サイトとして配置しておいてくれるのでとても安心です。

WordPress 立てるときは、Shifter が使えるか考えてみるのも手です。無料プランもありますし、コミュニティ向けのサポートも開始したとのことです。

アップデート

この Shifter Webhooks はエンタープライズ向けがターゲットとの話でした。
配置できる場所がクラウドのようなので、アクセス制限をかけるのはちょっと手間かなという印象がありましたが、機能が拡充してきたら色々使えそうです。

こちらについては懇親会の時間に色々と話をさせてもらいました。
別の記事でまとめます。

そういえばカスタムドメインは Personal プランからだけど Webhooks 使ってNetlifyにデプロイしたらカスタムドメインがフリーで使えたり？🤔

関連イベントのお知らせ

こんなに簡単 Gridsome！

発表者:青空俯角 / mimi(@miminari)さん

ドキュメントの構成からして初学者への優しさに溢れている。

  • Vue.js のような簡単さ、敷居の低さがよい
  • GetStartedが１ページ、コマンドが簡単で使うことができる
  • とりあえず試すができる

確かに Vue.js、VuePress、Nuxt.js、Gridsome をはじめ、各 Plugin やツールなど Vue.js 関係のドキュメントはよく整備されていて勉強しやすいです。発表を聞いて、あらためて気づきなおしました。Vue.js いいですよね。

GraphQL の入門にぴったり。

  • ２ステップで簡単 GraphyQL を使い始めることができる
  • 聞いたことはあるが、使ったことがないが、簡単に使い始めることができる

Gridsome は内部的に GraphQL を使っていて、各種ソースを GraphQL で取り出すので、クライアント作りまでいかずに手軽に試せるのと、ツールが付属しているので試行錯誤も簡単にできるのが良いです。

“聞いたことはあるが、使ったことがない” は意外とそうで、私は普段 REST で API を作っていて、次は GraphQL にしたいなぁと思いつつもなかなか着手できてないところがあります。それを Gridsome 使うことで、ちょっとした利用ができ勉強のとっかかりになるが良いです。

５分間インストールならぬ５分間デプロイ。

  • 既存の WordPress のサイト URL があれば、Netlify にコピーサイトが５分で作れる
  • サクッとデモ

Gridsome で WordPress をリニューアル。良いですよね。
実際にデモで動くのを見せてもらうと、いい感じです。今度しっかり試してみます。

関連イベントのお知らせ
WordCamp Tokyo 2019 11/1-2＠新宿
発表者の青空俯角 / mimi(@miminari)さんが実行委員長を担当

はじめてのスタティックサイト ジェネレーター GatsbyとSurgeでHello World! スタティックサイト ホスティングって？

発表者:Seiji Akatsuka(@seijiakatsuka)さん

発表資料

数ある静的サイトジェネレーターから Gatsby で Hello World を紹介。
青空俯角 / mimi(@miminari)さんセッションの「こんなに簡単 Gridsome！」の Gridsome は Gatsby にインスパイアされて Vue.js ベースで作っているもので、基本となるフレームワークが React か Vue.js かで、方向性は同じになるのですが、改め両方が詳細されるセッションのラインナップがすごくよかったです。

  • 静的サイトジェネレーターの振り返り
  • さまざまなサービスやツールがあり、組み合わせて使うことができる
  • Shifter はすべてをカバーしてる、オールインワン

Shifter が提供するもの。

とても楽しい勉強会でした。

主催者のKOGA Hiromichi(@digitalcube)さんの絶妙なトーク＆ツッコミとSeiji Akatsuka(@seijiakatsuka)さんの冷静な対応のペアがとてもおもしろかったです。

Shifter はとても興味を持っていたサービスで、調べようと思っていたところにちょうど勉強ようと考えていたところに、一気に学べる機会を持ててよかったです。

また Shifter のコミュニティはもとより、サーバーレスのコミュニティ、WordPress のコミュニティ、そして会場を課してくださった Stripe さんと多くのコミュニティやサービスの方々とたくさんお話する機会が得られ嬉しいです。

最近は勉強会になかなか出られてなかったのですが、しっかり時間を作って参加できるようにしてこうと強く思った勉強会でした。
ありがとうございました！

Author:lulzneko

lulzneko
ふりかえり

ブログメンティ始まる

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

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

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

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

ブログ メンティー

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

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

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

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

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

目標設定と現在の状況

カック@kakakakakkuさんとのお話で設定したこと。
「ブログを書く目標設定: 週１回を必達、週２回を目標とします」
⇒ “基本的にノルマは「技術系記事」とします”、“週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

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

Author:lulzneko

共有：
lulzneko
レポート

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

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

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

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

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

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

主な内容

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

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

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

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

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

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

お二人の名刺の歴史。

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

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

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

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

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

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

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

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

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

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

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

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

Riotz.works の名刺

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

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

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

名刺管理って

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

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

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

結局。会社名刺のアカウントに追加されるので、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！

Author:lulzneko

共有：
lulzneko
開発

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

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

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

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

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

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

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

以下のコード例ではokメソッドはthis.templateでthisを使っているので問題ありません。一方で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-methodはclass-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 にしたngStaticはAction.ngStaticに追加されています。

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

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

現在の状況

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

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

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

参考情報

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

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

Author:lulzneko

lulzneko
開発

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 に存在する値との整合性、入力データ間の整合性などはしてくれません。こちらはこちらで必要なことは別途実装する必要があります。)

その「型チェック」ですが色々なやり方があります。各リクエストパラメーターごとにチェックの関数を呼び出したり、リクエストパラメーターに対応するクラスを定義してデコレーター(アノテーション)を付けたり。ｚ
今回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"
  }
}

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

ただしデータの階層が深い場合は、このデータ構造が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を使わせてもらおうかな。

Author:lulzneko

lulzneko
プルリク / OSS-Friday

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
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ブランチがあることと、パッチ１個という感じで継続的にコントリビュートしていわけではないので、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.jsonのinstallをsetupに戻す
  • 開発環境のセットアップが１回で行える機能は残す

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

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

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

修正できたら、コミット＆プッシュ！

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 にリリースの返事。１時間していないという。Grant Zietsmanさん、ありがとうございます！

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

Author:lulzneko

lulzneko
ハッカソン

CTO vs Hackers ハッカソン戦記

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

ハッカソン概要

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

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

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

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

当日の進行

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

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

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

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

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

開発開始！
11:00 ～ 17:30 の 6.5時間１本勝負！！

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

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

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

開発！

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

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

アプリ概要

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

開発対象と主担当

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

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

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

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

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

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

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

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

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

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

会場の風景

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

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

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

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

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

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

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

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

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

熱い１日、ありがとうございました！！

Author:lulzneko

共有：
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で購入したドメインは、１ドメインにつき 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に送信元の設定をして、転送設定した際に作ったアカウントのメールから送信できるようにします。

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

共有：
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 を中心に、選りすぐりの技術を集めた素晴らしいアーキテクチャをご紹介したい。

満漢全席なイベントに、１つのコース料理としての満漢全席の皿（アーキテクチャ）を詰め込みお伝えしたい、そんな思いから『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」として、サーバレス界隈、フロントエンド界隈の盛り上がりに貢献できたら嬉しいです。

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

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

JAMstack とは

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


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

JAMstack の定義

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

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

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

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

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

AWS における JAMstack の配置

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

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


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


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

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

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

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

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

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

JAMstack の可能性

一番向いているのは「情報発信サイト」です。
公式サイト、ブログ、ドキュメントなど、特定管理下で情報を追加していくようなユースケースはとても相性が良いです。
GatsbyJS、Hexo、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