「テキスト校正くん」を使って読みやすい文章を書けるようにする

文章を書くときに「この単語は、ひらがな、カタカナ、漢字どれがよいか」や「気づいたら “の” が連なっていた」とったことがあるのではないでしょうか。
気を付けて書いたり、読み返したりしてチェックするかと思いますが人力だけではどうしてもすり抜けてしまいます。定型でできるチェックは自動で行い、人でないと判断できない部分に注力しましょう。

環境
本記事の開発環境は以下となります。

  • Windows 10 64bit + WSL Ubuntu 18.04.1 LTS
  • Visual Studio Code
  • テキスト校正くん

「テキスト校正くん」とは

テキスト校正くん は Visual Studio Code で、文章を自動でチェックしてくる拡張機能です。

テキストや Markdown を入力中にリアルタイムで校正してくれます。公式サイト 文章作成・メール作成に役立つ! VS Codeの拡張機能「テキスト校正くん」を公開 - ICS MEDIA によると以下のようなチェックを行ってくれます。

設定も簡単に行うことができるので、不要なチェックを外すこともできます。Visual Studio Code の拡張機能として容易にインストールでき、設定も手軽なのでテキストチェックの入門として、とてもよいです。

また内部的には textlint を使っているとのことです。さらに「テキスト校正くん」自体も ics-creative/project-japanese-proofreading で MIT ラインセンスのもと公開されています。

インストール

Visual Studio Code を起動して拡張機能(Ctrl + Shift + X) を表示します。
[テキスト校正くん] で検索、[インストール] をクリックします。(再読み込みの必要な場合があります)

さっそくテキスト校正くんで文章をチェックしてみます。
新しいファイルを .txt または .md で作成します。テキスト校正くんはテキストファイルをチェックするため .txt または .md のファイルである必要があります。

青空文庫から「夏目漱石 吾輩は猫である」を拝借してエラーが出るようにしてみました。

エディター部分にリアルタイムで赤線が表示され、カーソルをのせるとエラーの詳細が表示されます。また「問題」のビューに一覧も出るので便利です。

まずは指摘を修正し、それから目視によるチェックをすることで文章の質を上げることができます。

設定

デフォルトの設定でいい感じに校正してくれますが、自分用にカスタマイズしたいこともあります。たとえば「半角括弧を使いたい」や「英単語の後に半角スペースをいれたい」など。
テキスト校正くんは簡単な設定でチェックルールをオフにできます。

Visual Studio Code の設定を開きますが、GUI で設定したほうがわかりやすいので GUI エディターを表示します。
コマンドパレット(Ctrl + Shift + P) から prefui で絞り込み「基本設定: 設定(UI)を開く」を選択します。

設定の GUI エディターから テキスト校正くん で絞り込み、不要なルールのチェックを外して設定をします。

設定もリアルタイムで反映されるので、エディターを並べて探りながら設定することもできます。下図例では「句点(。)と読点(、)」が「生まれたかとんと見当がつかぬ」のピリオドのエラー有無に効いています。


私の文章の書き方が独特ということもあり、当初はかなりチェックが入ってしまっていました。ですが「テキスト校正くん」を入れてからはリアルタイムで指摘してくれるので都度直せますし、漢字の開きなど文章の勉強にもなり助かっています。
(過去記事は、そこまで多くはないのですが指摘が多すぎるので追々直していきたいと思います。。。)

とはいえ、漢字の間違えや誤入力などはチェックできないので最終的な確認は目視が大事なことに変わりはありません。単純なミスを防ぎ本質的なところに注力させてくれる拡張機能になります。

そしてブログメンター Eyes に耐えられる文章力とセルフレビュー力を鍛えたいところです。

ICS MEDIA さんには、こんなに素晴らしい拡張機能を作り、無料の OSS で公開してくださり感謝しかありません。ありがとうございます!

hexo-related-popular-posts にサブパス対応のプルリクを送る

Static Site Generator の Hexo で「人気の記事」を実現する Plugin、hexo-related-popular-posts。ビルド時に Google Analytics からアクセス解析のデータを取得してランキングを作成する素晴らしいアイデアで不可能を可能にしてくれます。
今回こちらの Plugin を使わせていただいたところ、サブパスの URL に対応する機能がなかったのでエンハンスのプルリクエストをだして拡張してもらいました。

tea3/hexo-related-popular-postsHexo の Plugin で、Google Analytics からアクセス解析のデータを取得して各記事のランキングを作成してくれます。

Hexo は Static Site Generator で JAMStack サイトを作ります。JAMStack は静的なサイトで、アクセス解析のようなことはできず、通常は「人気の記事」のような動的な要素が必要なことはできません。

ところが tea3/hexo-related-popular-posts は冒頭に書きました通り Google Analytics と連携することで実現してくれる、最高にスゴイ Plugin です。

詳しくは「ブログで使っている Hexo に人気の記事リストを表示したい!」を、ご参照ください。

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

本ブログに人気の記事リストを導入した際に、順不同でアクセス解析が反映さていない現象に遭遇しました。

正しくないランキングに明らかにアクセスがないであろう「Hello World !!」が入っており不思議だったのと、起動しなおすとランキングが入れ替わる挙動をしました。

※「Hello World !!」の記事は実際にアクセス数 0。さりげなくリンクを貼ってみます。

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

まず hexo-related-popular-posts での動作確認です。アクセス解析したデータが出力されるファイル rankingSheet.txt を確認したところ、PV が 0 でした。

Google Analytics からデータが取れていないことも考えられるので、hexo-related-popular-posts が使っているライブラリ sfarthin/ga-analytics の動作確認したところ、コンソールに正しく表示できました。環境設定に問題はなさそうです。
※ ga-analytics の動作確認については、こちら「Google Analytics に プログラムでアクセスできるようにする」をご参照ください

そうなるとデータを取得した後に何かがあるので、hexo-related-popular-posts のソース確認に入ります。

Visual Studio Code で Hexo プロジェクト配下の node_modules/hexo-related-popular-posts を開きます。

1
2
$ cd node_modules/hexo-related-popular-posts
$ code .

ソースコード 13ファイルとはいえ、何かあたりが欲しいところ。まずは rankingSheet.txt を正しく表示できるところを目標にランキングデータファイル名の設定 rankingSheet を全文検索します。そうすると cache.js がかかりました。

ざっと眺めてみると 33行目に // PV update と、それっぽいコメントがあり、36行目でパスの比較をしてデータモデルを作っているようです。
ここにデバッグ用のコンソール出力を挟んで動作確認をしたところ articles/ 有無でミスマッチしていることがわかりました。

1
2
3
4
5
6
2018/12/29/what-we-did-in-2018/ == articles/2018/12/29/what-we-did-in-2018/
2018/12/31/review-of-2018/ == articles/2018/12/31/review-of-2018/
2019/04/03/take-seminar-on-shiftup-vol3/ == articles/2019/04/03/take-seminar-on-shiftup-vol3/
2019/04/01/k9us-blog-mentoring-to-lulzneko/ == articles/2019/04/01/k9us-blog-mentoring-to-lulzneko/
2019/02/24/summary-of-qa-at-jawsdays2019/ == articles/2019/02/24/summary-of-qa-at-jawsdays2019/
...

この articles/ は、本ブログ URL のトップで riotz.works ドメインのサブパスに配置されているパス名になります。そのサブパスが Google Analytics のデータには含まれていて、Hexo のデータには入っていなかったことからランキングデータが正しく作られなかったようです。

原因が判明したので、サブパスを使っている場合に対応する機能拡張をプルリクします。

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

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

tea3/hexo-related-popular-posts のリポジトリへ行き、画面右上の [Fork] をクリックします。

いい感じにリポジトリがフォークされます。(この画面、スキ)

自分のアカウントにフォークしたリポジトリが作られるので git clone します。
(画面左上のリポジトリのアカウントが自分になっていて、フォーク元が表示されている)

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

プルリクしたい変更を自分のリポジトリに行います。
しっかりやるには作業用ブランチを用意しますが、今回は単発の作業で開発用ブランチもなさそうなので master ブランチに直接変更を加えてしまいます。

変更の方針
原因究明時にほぼ判明しているので難しくないですが、以下となります。

  • cache.js にサブパスの文字列を持ってくる (今回は articles/ になる文字列)
  • Google Analytics とパスマッチする部分で、上記サブパスを利用する

サブパスの文字列は Hexo の設定、プロジェクト直下 _config.yml ファイルの root: /articles/ になります。Hexo 公式ドキュメントでは “root directory” と書かれている、こちら URL - Configuration | Hexo の設定になります。

これを cache.js で使うには hexo.configroot プロパティ、すなわち hexo.config.root を使います。ただし、このままだと /articles/ のように先頭の / でまたミスマッチするので hexo.config.root.slice(1) にして先頭を取り除きます。

ここで取得したサブパスの文字列を判定の if 文で使います。(上記キャプチャの 36行目)

1
2
3
if (hexo.config.root.slice(1) + hexo.locals.cache.posts.data[v].popularPost_tmp_gaData.path == tmp_gaData[w].path) {
// ...
}

このままだと処理がわかりにくいのでリファクタリング。
とくに slice(1) を毎回処理するのはムダなのでファイル上部の変数宣言部に移動します。root の変数名は微妙ですが設定の項目名をそのまま使っているようなので合わせます。

1
2
3
4
5
const root = hexo.config.root.slice(1)

if (root + hexo.locals.cache.posts.data[v].popularPost_tmp_gaData.path == tmp_gaData[w].path) {
// ...
}

テストケースが用意されているのでテストが失敗しないか確認しておきます。
修正が完了したら自分のリポジトリへプッシュします。

プルリクの作成

フォークした自分のリポジトリへ行き、変更がプッシュされていることを確認します。
つづいて画面中ほどの左に [New pull request] のボタンがあるのでクリックします。

プルリク作成画面が表示されるので、以下を確認し [Create pull request] をクリックします。

  • [file changed] から差分の最終確認
  • マージ先の確認(今回は tea3/hexo-related-popular-postsmaster)

プルリク作成画面プルリクの目的と機能についての説明コメントを書き [Create pull request] をクリックします。
今回、作者さんのブログが日本語なので日本語でリクエストを出しても大丈夫だと思いましたが GitHub は英語で書かれているのとクローズされているプルリクも英語でやり取りしていたので英語にしました。(私の英文がヤバげなのは英語がまったくできないので頑張ってくググった成れの果てです💦)

無事プルリクが送られたので、マージされるのを期待して待ちましょう。

Support sub-path URL configuration with popular posts feature by lulzneko · Pull Request #19 · tea3/hexo-related-popular-posts

一晩でマージされた!

プルリクを出して一晩、夕方にはマージしリリースしてくださりました。はやっ!ᴛ ᴇ ᴀ 🍵(@tea0828)さん ありがとうございます!!


プルリクもマージされ人気記事のリストが表示されるようになりました。

プルリクを送る、となるとハードルが高いように感じるかもしれませんが作業そのものとしては難しくはありません。この記事がプルリク作成のきっかけになれば幸いです。

ブログで使っている Hexo に人気の記事リストを表示したい!

ブログによくある「人気の記事」のリストが欲しい。しかしながら本ブログは JAMStack で動的なことができません。ところが、スゴイ Plugin があって静的なサイトなのに「人気の記事」ができてしますのです!!

環境
本記事の開発環境は以下となります。

  • Windows 10 64bit + WSL Ubuntu 18.04.1 LTS
  • OpenSSL 1.1.0g (WSL)
  • Visual Studio Code
  • Node.js 8.10.0
  • npm 5.6.0
  • sfarthin/ga-analytics 0.0.7
  • hexo-related-popular-posts 3.0.4

JAMStack なサイトの強み/弱み

スゴイ Plugin の紹介の前に、少し JAMStack について整理します。

本ブログは Static Site Generator の Hexo を使って静的なサイト、つまり JAMStack として作っています。静的なサイトなのでプログラムを動かせるようなサーバーは持っていません。

JAMStack にすることでパフォーマンスが良く、安全性を高めたサイトを作ることができます。詳しくは本ブログの記事 JAMStack、それは ハイパフォーマンスなウェブフロントを実現するアーキテクチャ をご参照いただければと思います。

メリットがあれば、デメリットもあります。静的なサイトになるので動的なこと、たとえばコメント欄などは実現できません。今回のテーマである「人気の記事」も同様で、実現するには各記事へのアクセスを集計しアクセスが多いものを人気として動的にリストを作る必要があります。つまり JAMStack ができない、動的な機能が必要となります。(なお JAMStack で動的な要素が必要な場合は SaaS などのサービスと連携して実現することが多いです)

この動的なことができない JAMStack ですが、tea3/hexo-related-popular-posts plugin が「人気の記事」を実現してくれます!

作者 ᴛ ᴇ ᴀ 🍵(@tea0828)さん のサイト Hexoブログで関連記事や人気記事を生成するプラグインを作った(node.js製hexo)|おちゃカメラ。 によると、Google Analitycs のページビューを取得して、人気の記事を作るとのことです。確かに Google Analitycs は設置しているケースは多いですし、本ブログでも設定しています。また各ページごとのアクセス数もしっかり取ってくれています。そこに注目して Plugin として実現してしまうのがスゴイ!

そして形態素解析も備えていて、記事本文を分析して「関連する記事」のリストも作ってくれます。また「人気度」「関連度」を組み合わせることもできミックスしてどちらにウェイトを置いてリストを作るかの制御も可能です。

ただし注意点が1つあります。Static Site Generator の Plugin なので「サイト生成時に動作」します。つまりリアルタイムに人気の記事は変化しません。あくまでも「サイト生成時の人気の記事」であることに留意が必要です。とはいえ、きちんと投稿したりサイトメンテをしていれば更新されていくので安心ですし、夜間ビルドを走らせて毎日ビルドしてしまう手もあります。

最高にスゴイ Plugin です。ᴛ ᴇ ᴀ 🍵(@tea0828)さん ありがとうございます!!

インストール

Hexo のプロジェクトディレクトリへ移動して、以下のコマンドを実行します。

1
$ yarn add hexo-related-popular-posts

※ npm を使っている場合は npm install -S hexo-related-popular-posts

人気の記事リストを表示

さっそく Google Analytics からアクセスデータを取得して人気の記事リストの機能を使っていきます。この機能を使うために Google Analytics へ Web API 経由でアクセスできるようにします。
設定方法の詳細については、こちらの記事 Google Analytics に プログラムでアクセスできるようにする をご参照ください。

本記事では以下が用意できているものとして進めます。

sfarthin/ga-analytics で動作確認した google-services.pem を Hexo プロジェクトのルートディレクトリに配置します。

プロジェクトディレクトリ直下の _config.yml に以下を追記します。

  • rankingSheet は人気の記事に使うランキングデータを保存するファイル名
  • pvMeasurementsStartDate は累計アクセス数の計測を開始する日付
  • cache: path: は解析結果のキャッシュファイル
    1
    2
    3
    4
    5
    6
    popularPosts:
    googleAnalyticsAPI:
    rankingSheet: rankingSheet.txt
    pvMeasurementsStartDate: 2005-11-14
    cache:
    path: hexo-popular-related-posts-cached.json

以下のコマンドを実行し Hexo ローカルサーバーを起動します。起動時に Google Analytics へアクセスしランキングシートが生成されます。

1
2
3
4
5
6
$ export GOOGLEAPI_CLIENTID="[サービスアカウントの名前].apps.googleusercontent.com"
$ export GOOGLEAPI_EMAIL="[サービスアカウントのメール]"
$ export GOOGLEAPI_KEY="google-services.pem"
$ export GOOGLEAPI_ANALYTICS_TABLE="ga:[Google Analytics の ビュー ID]"

$ yarn hexo start

_config.ymlrankingSheet で設定したファイルに各記事の PV が出力されていることを確認します。(pvMeasurementsStartDate を設定してない場合 TOTALPV は 0)

人気の記事のウィジェットを作成

Plugin の動作が確認できたので、ブログに人気の記事を配置します。
今回はウェブサイトの右側にあるウィジェットを新たに追加したいと思います。

「最近の投稿」が似ているイメージなので、こちらをベースに作ります。
Google Chrome でサイトを表示し「最近の投稿」を右クリックして [検証] を選択、Chrome DevTools でソースを確認します。

<h3 class="widget-title recent">最近の投稿</h3>widget-title で全文検索します。(※ recent は本ブログのカスタマイズにて追加したもので、素の Hexo landscape テーマには widget-title しかありません)
たくさん見つかりますが各ウィジェットと、そのスタイルです。「最近の投稿」の本体は recent_posts.ejs です。

recent_posts.ejs を参考に /themes/landscape/layout/_widget/popular_posts.ejs を作ります。

1
2
3
4
5
6
7
8
<% if (site.posts.length){ %>
<div class="widget-wrap">
<h3 class="widget-title popular">よく読まれている投稿</h3>
<div class="widget">
<%- popular_posts({ PPMixingRate: 1.0 }) %>
</div>
</div>
<% } %>

<%- popular_posts({ PPMixingRate: 1.0 }) %> が hexo-related-popular-posts で人気の記事を表示するコードになります。
PPMixingRate1.0 は「人気の記事」、0.0 は「関連する記事」になります。

設定の詳細は公式の ヘルパータグの表示オプション - Hexoブログで関連記事や人気記事を生成するプラグインを作った(node.js製hexo)|おちゃカメラ。 を、ご参照ください。

作成した人気の記事のウィジェットを有効化

ウィジェットを追加するにはテーマの設定ファイル _config.yml (/themes/landscape/_config.yml) を更新します。
※ こればかりは Chrome DevTools や全文検索では見つけにくくドキュメント参照 Configuration - hexojs/hexo-theme-landscape: A brand new default theme for Hexo.

widgets: に表示するウィジェットのファイル名を列挙します。
今回は最近の投稿の上に表示したいので - tagcloud- recent_posts の間に - popular_posts(ファイル名 popular_posts.ejs の拡張子 .ejs を除いた名前) を追加します。

作成した人気の記事のウィジェットのスタイル適用

ローカルサーバーを使い動作確認を行うとウィジェットが表示されますが、記事のタイトルが大きいように感じます。これは hexo-related-popular-posts が生成するリストに <h3> タグが入っており若干大きく表示されているのがあります。スタイルを適用してそろえるようにします。
(<h3> タグを取り除くようにカスタマイズもできます - リストのHTMLをカスタマイズ)

先ほどの全文検索で見つかった sidebar-aside.styl(/themes/landscape/source/css/_partial/sidebar-aside.styl) に以下を追加します。
ウィジェットを作った際に <h3 class="widget-title popular">widget-titlepopular を追加して作りました。これにより人気記事のウィジェットにクラスを当てられるようにしています。あとは <h3> タグのフォントサイズを親タグから継承させて完成です。(Riotz.works のサイトではアイコンを入れたりマージンを広げたりしてますが、この辺はお好みで)

1
2
3
.widget-title.popular + div li
h3
font-size: inherit

注意

環境変数に設定した GOOGLEAPI_CLIENTID などの各 ID と google-services.pem をセットで GitHub の Public Repository などへアップしないようにします。Google Analytics のデータにアクセスされてしまうほか、権限設定に誤りがあると不正操作される可能性があります。

関連する記事リストを表示

せっかくなので記事の下に関連する記事のリストも表示します。

デフォルトでタグから関連記事を抽出してくれます。また形態素解析にも対応しており morphologicalAnalysis オプションを追加することで利用可能です。形態素解析を利用する場合はプロジェクトディレクトリ直下の _config.yml に以下を追記します。
※ 除外キーワードなど設定が柔軟に行えます - 記事本文と関連する記事

1
2
3
4
5
6
7
popularPosts:
morphologicalAnalysis:
googleAnalyticsAPI:
rankingSheet: rankingSheet.txt
pvMeasurementsStartDate: 2005-11-14
cache:
path: hexo-popular-related-posts-cached.json

表示する場所は SNS 共有リンクの下にします。こちらは 前回の記事 で改修した場所 /themes/landscape/layout/_partial/article.ejs<footer> タグ内になります。

以下のコードを <footer> タグ内に追記します。(ここでは、キャプチャの46行目)

1
2
3
4
<div class="related-posts">
<h2>関連記事</h2>
<%- popular_posts({ PPMixingRate: 0.0 }, post) %>
</div>

/themes/landscape/source/css/_partial/article.styl を編集して、スタイルを適用します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
.related-posts
clear: both
margin-top: 32px
li
margin-bottom: 4px
a
color: color-link
text-decoration: none
&:before
margin: 0 4px
content: "-"
&:hover
color: color-link
text-decoration: underline

配置やスタイルは全体のデザインや好みがありますので、一例として。
フォントカラーの color: color-link/themes/landscape/source/css/_variables.styl に定義されている値を使っています。

また .article-footer の CSS が効いているので必要に応じて上書きする必要があります。たとえば <a> タグの color は記事のタグで使われているため本文と同じ色に設定されています。そのためリンクっぽくないので上書きしています。

ということで、関連する記事のリストが表示できました!


JAMStack なのに、アクセス解析が必要な「人気の記事」を作ることができました!
hexo-related-popular-posts、Google Analytics を使う着眼点と、それを実現する実装力、素晴らしいです!!

累計アクセスも取得できているので拡張することで、いわゆる「殿堂入り」リストも作れそうです。
また、この Google Analytics と連携して人気の記事を作る手法は他の Static Site Generator にも応用できるので、最近使い始めている Gridsome 版へのポーティングにもチャレンジしてみたいです。

Google Analytics にプログラムでアクセスできるようにする

ウェブサイトのアクセス解析のサービス、Google Analytics。
この Google Analytics はブラウザでアクセスして解析データを見るほかに Web API 経由でデータを取得できます。今回は Google Analytics の Web API へプログラムからアクセスできるようにします。

Google Analytics へプログラムを使ってアクセスすることで、分析サイトを作ったり、必要なデータだけを定期的に取得することなどができます。たとえば週間 PV をチャットに流すといったような使い方が考えられます。
本記事では sfarthin/ga-analytics の CLI でデータを取得するところまでとなりますが、次回ブログ環境で使っている Hexo と組み合わせた話を紹介したいと思います。

環境
本記事の開発環境は以下となります。

  • Windows 10 64bit + WSL Ubuntu 18.04.1 LTS
  • OpenSSL 1.1.0g (WSL)
  • Visual Studio Code
  • Node.js 8.10.0
  • npm 5.6.0
  • sfarthin/ga-analytics 0.0.7

Google Developer Console で Analytics API の準備

まず Google Analytics の Web API を使えるように Google Developer Console へアクセスしてプロジェクトを作成し、認証情報を設定します。

https://console.developers.google.com/ へアクセスし、利用する Google Account でログインします。
はじめて作成する場合は空のダッシュボードから [作成] をクリックしてプロジェクトとを作ります。
また、すでに使っている場合はヘッダーの [プロジェクトの選択] - [新しいプロジェクト] から作ります。

新しいプロジェクト作成ページが表示されるので情報を入力し [作成] をクリックします。
今回は以下としました。実際に使うときには [プロジェクト ID] も設定しておくとよいでしょう。

  • プロジェクト名: analytics-access
  • 場所: 組織無し(変更なし)

プロジェクトが作成され、プロジェクトのダッシュボードが表示されます。(ヘッダーにプロジェクト名が出てる)
Google Analytics へアクセスるための機能を追加するために [+ API とサービスを有効化] をクリックします。

検索ボックスに [Analytics API] を入力して絞り込み [Analytics API] のボックスをクリックします。
※ 似ている名前でアイコンがついている [Google Analytics Reporting API] がありますが違うので注意

Analytics API の説明が表示されるので利用規約 Google APIs Terms of Service を確認し同意できたら [有効にする] をクリックします。

Analytics API の認証情報を作成

Analytics API のダッシュボードが表示され、認証情報の作成を求められます。
[認証情報を作成] をクリックします。

プロジェクトへの認証情報の追加画面が表示されるので、項目を入力し [必要な認証情報] をクリックします。

  • 使用する API: Analytics API
  • API を呼び出す場所: その他の UI (Windows、CLI ツールなど)
  • アクセスするデータの種類: アプリケーション データ

サービスアカウント作成のフォームが表示されるので、項目を入力し [次へ] をクリックします。

  • サービス アカウント名: 任意の文字列 (今回は hexo)
  • サービス アカウント ID: 任意の文字列 (今回は自動で hexo-907、6文字以上必要 )
  • 役割: 役割を選択(変更なし)
  • キーのタイプ: P12

「サービス アカウントに役割が割り当てられていません」と 表示されますが、[役割なしで作成] をクリックします。
※ 役割はなくても Web API にアクセスできますし、コンソールにアクセスする必要はないので役割なしで問題ありません。

サービス アカウントとキーが作成され、秘密鍵のファイルがダウンロードされます。ダウンロードした秘密鍵にはパスワードが設定されています。表示された文字列をひかえておきます。(キャプチャ用に画像はそれっぽく作っています)
ダウンロードが完了したら [閉じる] をクリックします。

認証情報画面が表示されるので [サービス アカウントの管理] をクリックします。

サービスアカウントの情報が表示されるので [メール] と [名前] をひかえておきます。

Google Analytics の認証情報を作成

https://analytics.google.com/analytics/ へアクセス Google Analytics を表示します。
左のメニューから [管理] をクリックし、アクセスしたい [アカウント] - [プロパティ] - [ビュー] を設定します。

アクセスする [ビュー] の [ビューの設定] をクリックします。

[ビュー ID] をひかえ、[ユーザー管理者] をクリックします。

ビューの権限画面から右上の [+] をクリックし、[ユーザーを追加] を選択します。

権限の追加画面に必要な情報を入力し [追加] をクリックします。

  • メールアドレス: ひかえておいたメールの文字列 (今回は hexo-907@analytics-access-237909.iam.gserviceaccount.com)
  • 新規ユーザーにメールで通知する: チェックを外す (チェックしてても問題はありません)
  • 権限: 表示と分析だけチェック(変更なし)

追加されました。

sfarthin/ga-analytics でデータを取得

実際にコマンドからデータを取得してみます。ここでは簡単にデータを取得してくれるライブラリ sfarthin/ga-analytics を使います。 sfarthin/ga-analytics は Analytics API を使って、Google Analytics のデータを取得してくれる Node.js のモジュールです。詳しくは README をご参照ください。

まずはダウンロードした秘密鍵のファイルフォーマットを pem形式に変換します。

1
$ openssl pkcs12 -in [ダウンロードした秘密鍵のファイル] -nocerts -passin pass:[秘密鍵ファイルのパスワード] -nodes -out google-services.pem

Analytics API にアクセスするための情報を環境変数に設定し、ga-analytics を実行します。
引数がない場合はトータルのセッション数が出力されます。セッション数が表示されたらサービス設定等正しく行えています。プログラムでアクセスできる準備ができました!

1
2
3
4
5
6
7
8
9
10
11
12
13
export GOOGLEAPI_CLIENTID="[サービスアカウントの名前].apps.googleusercontent.com"
export GOOGLEAPI_EMAIL="[サービスアカウントのメール]"
export GOOGLEAPI_KEY="google-services.pem"
export GOOGLEAPI_ANALYTICS_TABLE="ga:[Google Analytics の ビュー ID]"

npx ga-analytics
┌────────────────────┐
│ sessions (INTEGER) │
├────────────────────┤
│ 826 │
└────────────────────┘

Total sessions: 826

不要となった場合

以下の2ヵ所から削除します。


Google Analytics からプログラムでデータを取得することができました。
しっかりとした分析を確認したりするには Google Analytics のウェブサイトが素晴らしいので、同じようなダッシュボードはあまり作らないかと思いますが、ちょっとした分析や定型レポートの出力などに使えるかと思います。

次回は、この Google Analytics と Hexo を組み合わせた Plugin の紹介をしたいと思います。

ブログで使っている Hexo の SNS 共有リンクのユーザビリティを高める

本ブログで使っている Hexo のデフォルトのテーマ landscape。記事を SNS で共有するボタンが用意されているのですが、そのボタン群のボックスを出してから使う手順になっています。
ボタン群を直接記事の下に配置することで、手順を減らしてユーザビリティを高めたいと思います。

Hexo の SNS 共有リンクの改修

前回の記事 ブログで使っている Hexo の SNS 共有リンクに「はてなブックマーク」を追加する では、Hexo に「はてなブックマーク(以降、はてブ)」のブックマークを作るボタンを追加しました。

そのとき気になったのが [共有] ボタンをクリックしてから、SNS 共有ボタン群のボックスを出して使う点です。今回は、この部分を改善してユーザビリティを高めたいと思います。

改修ポイントを確認

前回「はてブ」のボタンを追加したのは script.js// Share ブロックでした。
これは article-share-link のクラスが割り当てられた要素、つまり記事下の [共有] をクリックすると SNS シェア用のボックスを表示するスクリプトになります。

今回は、このスクリプトをやめて HTML テンプレートに直接各ボタンを配置するようにします。
修正ターゲットは article-share-link(= [共有] がある場所)になるので、これを全文検索して探します。
※ [共有] のラベル 共有 は i18n 対応で外部化されているので検索対象に適しません

article.ejs<footer> タグ内にありました。(キャプチャでは 36行目)
ここに script.js で作っているボタンを移動してきます。

SNS 共有ボタンを移動

以下のコードを <footer> タグの下に追加し、article-share-link<a> タグを <span> タグに変更します。

1
2
3
4
5
<a href="http://b.hatena.ne.jp/entry/<%- post.permalink %>" class="article-share-hatena" target="_blank" title="このエントリーをはてなブックマークに追加"></a>
<a href="https://twitter.com/intent/tweet?url=<%- post.permalink %>" class="article-share-twitter" target="_blank" title="Twitter"></a>
<a href="https://www.facebook.com/sharer.php?u=<%- post.permalink %>" class="article-share-facebook" target="_blank" title="Facebook"></a>
<a href="http://pinterest.com/pin/create/button/?url=<%- post.permalink %>" class="article-share-pinterest" target="_blank" title="Pinterest"></a>
<span data-url="<%- post.permalink %>" data-id="<%= post._id %>" class="article-share-link"><%= __('share') %></span>

基本的には script.js にあった、タグを JavaScrip の書式から HTML の書式に変更して移動してます。
encodedUrl は HTML 内では文字列連結ができないのと、変数が post.permalink に変わり、HTML テンプレートとして <%- post.permalink %> を使います。すぐ下の [共有] のリンクで使っているのと同じです。

できあがった HTML テンプレートで表示!
残念ながら左に寄ってしまっています。。。

SNS 共有ボタンにスタイルをあてる

移動しただけでは残念ながらレイアウトが崩れてしまいました。スタイルを与えて修正します。
(この辺はサイトのデザインとご相談、1つの例として)

まずアイコン共通のスタイルを修正します。$article-share-link を修正しますが同じ名前で .article-share-link があるので注意です。$ のほうになります。
主な修正点は以下になります。

  • アイコンのボックスが大きいので width: 20px height: 20px で小さく
  • 左に集まってしまっていたのを float: right で右に戻す
  • 並びが窮屈なので margin: 0 0 0 10px で間隔を調整
  • アイコンのフォントが [共有] に対して大きいので font-size: 18px で調整
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    $article-share-link
    width: 20px
    height: 20px
    display: block
    float: right
    position: relative
    color: #999
    text-shadow: 0 1px #fff
    margin: 0 0 0 10px
    &:before
    font-size: 18px
    font-family: font-icon
    font-weight: normal
    absolute-center(@font-size)
    text-align: center
    &:hover
    color: #fff

続いて各アイコンのスタイルを修正します。
カーソルがのったときに背景色が変わるようになっていますが、新しいレイアウトだとアイコンそのものの色を変えたほうがわかりやすいでしょう。
以下 Twitter を例にしますが、すべてのアイコンの定義で同じように修正します。

  • background の行を color: color-twitter !important のようにします
    • 背景色の定義を、フォントの色の定義に変更
    • .article-footer acolor 定義に負けるので、!important で優先
      1
      2
      3
      4
      5
      6
      7
      .article-share-twitter
      @extend $article-share-link
      &:before
      content: "\f099"
      &:hover
      color: color-twitter !important
      text-shadow: 0 1px darken(color-twitter, 20%)

だいぶ良い感じにアイコンが並びました。
float: right を使ったのでアイコンが HTML の定義と逆順に並んでいます。今回はこの順番にしますが、並び順をボックスのときと同じようにするには、HTML の <a> タグの順番を逆順にします。

[共有] のラベルからマウスカーソルスタイルとアイコンを外す

SNS 共有のボックスを開くための [共有] ラベルのスタイルを調整します。今度は .article-share-link. 始まりの方になります。
矢印のアイコンをなくした方がすっきりしたので消しましたが、表示したい場合は &:before 以降を残します。

  • cursor: pointer を削除し、マウスでクリックできる感をなくす
  • &:before 以降を削除し、矢印のアイコンを消す
    1
    2
    3
    .article-share-link
    float: right
    margin-left: 20px

SNS 共有アイコンのボックスを表示するスクリプトを削除する

最後に [共有] ラベルをクリックできないようにします。<a> タグと cursor: pointer のスタイルをなくしているので、一見クリックできない要素に見えますが、クリックすると壊れたボックスが表示されます。
script.js// Share ブロックを削除します。 (キャプチャでは 34行目~86行目、表示の都合により一部折りたたみ)

完成!


SNS 共有アイコンをボックス表示から、記事の下に展開済みで表示するようにできました。

ブログメンティ ふりかえり 1週目 の後に、メンター の カック@ブロガー / k9u(@kakakakakku)さん とお話していた時に「”はてブ”をつけるときにボタンを使う」のがありました。

私が「はてブ」を使っていなかったので、ブックマークを付ける感覚をとらえられずボタンを設置していなかったのですが、確かにサイトを開いてから URL を入力する手順はしなそうです。

Twitter も共有するときにボタンがあれば押す可能性が高まるものの、自分で URL コピーするときは何か書く時で、そうでないときは流す可能性が高まります。ただ Twitter は開いていることが多いので、コピペする率は高いかもしれません。そういったサイトの特性もあることを学びました。

せっかくボタンを設置しましたし、アカウントも開設したので、たくさんのサイトを「はてブ」していきたいと思います。

今回は CSS をいろいろと調整しての修正がありました。
キャプチャや作業紹介がしにくかったので Try & Error の紹介は省略しましたが、CSS を試行錯誤するときは Chrome DevTools で CSS を直接編集するとリアルタイムに画面が変わってわかりやすいので、まずは Chrome DevTools で試してコードに落とすと楽です。

ブログで使っている Hexo の SNS 共有リンクに「はてなブックマーク」を追加する

本ブログは Hexo の Static Site Generator でデフォルトのテーマ landscape をカスタマイズして使っています。landscape のテーマは、記事の最後に SNS へ共有するためのリンクがあります。このリンクボタン群に「はてなブックマーク」を追加します。

[2019.4.12 追記]
本記事の方法で共有ボタンを追加した際に api.shopstyle .com ドメインへリダイレクトしてから「はてなブックマーク」へ戻る挙動が確認されたため、記事を取り下げておりましたが原因が確認できたので再公開します。
原因はコメント欄のサービス Disqus による挙動と思われ、本サイトの Disqus 利用を停止したところリダイレクトは確認されなくなりました。詳細については別途まとめます。
本記事の方法で共有ボタンを追加することに問題はありません。お騒がせし申し訳ありませんでした。

Hexo とは

まず、本ブログで使っている Hexo を紹介します。
Hexo は “A fast, simple & powerful blog framework” を謳うブログサイトを作るためのフレームワーク、というかツールです。公式サイトでは言及していませんが JAMStack なサイトを作るための Static Site Generator です。

Markdown で書いた記事をもとにウェブサイトの HTML を生成し、生成後は静的なサイトとしてデプロイできウェブサーバーだけで運用できます。簡易的なサイトでよければ GitHub Pages が使えますし、NetlifyAWS の S3+CloudFront などでしっかりと運用もできます。
静的サイトなのでコメント機能は持っていませんが Disqus と連携する機能が組み込み済みなので簡単に設置できます。テーマやプラグインが豊富にあり、また日本語での情報も多く使いやすいのが特徴です。

Hexo 同様のツールとしては GatsbyJSVuePressGridsome などがあります。これらは、より高速で、ブラウザキャッシュを効果的に使う仕組みなどもあらかじめ入っているので、新しく立ち上げるサイトの場合はこれらを検討してみるのもよいでしょう。
また StaticGen にたくさんリストされているので、利用している技術スタックや環境などから自分に合ったものを探すのもよいです。

記事の共有リンクに「はてなブックマーク」を追加する

Hexo には記事の下に Twitter、Facebook、Pinterest、Google+ へ記事を共有するためのボタンが用意されています。
ここに「はてなブックマーク(以降、はてブ)」でブックマークを作るボタンを追加ます。ついでにサービス終了となった Google+ のボタンは削除します。

当初、Hexo の Plugin があるかと思ったのですが見当たらなかった、というか Plugin できる場所ではないようなのでテーマを直接修正することにします。

修正する場所を見つけるために Chrome DevTools であたりを付けます。
共有リンクの Google+ を右クリックして、コンテキストメニューから [検証] をクリックします。
すると Chrome DevTools が表示され、右クリックして [検証] した場所、ここでは Google+ ボタンのソースがフォーカスされます。

フォーカスされたソースの前後から検索に適しそうな文字列を探します。
今回はフォーカスされた部分の class="article-share-google" が使えそうです。できれば id 属性を使いたいところですが class="article-share-google" もソース内でかなり限定できそうですし、Twitter なども同じような命名でクラス定義されているようなので「はてブ」の CSS を作る時に使えそうです。

検索用の文字列を決めたのでソースから探します。
今回は普段から開発に使っている Visual Studio Code で全文検索をかけました。

リンクを追加する

script.js の中で article-share-link のクラスが割り当てられている要素をクリックしたときに、SNS シェア用のリンクが入ったボックスを表示する中で作られているようです。

class="article-share-google" を行ごと消して Google+ のボタンを削除します。(キャプチャでは 61行目)

「はてブ」共有用リンクを、今回は Twitter 共有リンクの前に入れます。
以下のコードを追加します。(キャプチャでは 58行目)
※ コードは公式の はてなブックマークボタンの作成・設置について を参考に作りました。 title 属性はサイトに合わせて変更してください。

1
'<a href="http://b.hatena.ne.jp/entry/' + encodedUrl + '" class="article-share-hatena" target="_blank" title="このエントリーをはてなブックマークに追加"></a>',

スタイルを追加する

article.styl.article-share-google が定義されています。
ここに「はてブ」共有リンク用のスタイルを追加します。(キャプチャでは 323行目)

この .article-share-google の下に追加します。(.article-share-google のブロックは削除して大丈夫です)

1
2
3
4
5
6
7
8
9
.article-share-hatena
@extend $article-share-link
&:before
content: "B!"
font-family: Verdana;
font-weight: bold
&:hover
background: #00a4de
text-shadow: 0 1px darken(#00a4de, 20%)

Hexo 内のアイコンは Font Awesome 4 が使われています。しかしながら、このフォントセットには「はてブ」アイコンは入っていません。かわりに公式アイコンを使いたいところですが、スタイルにズレが生じてしまうのでフォントアイコンで乗り切りたいところです。

こちらのサイトさんで良い方法を紹介してくださっていました。素晴らしい情報をありがとうございます!
Font Awesome などアイコンフォントにないはてなブックマークを自力で追加する簡単な方法

色は公式の 素材集 - 株式会社はてな から、アイコンをカラーピックしました。

できあがり


「はてブ」でブックマークを作るボタンを導入することができました!

導入の背景としては、ブログメンティ ふりかえり 1週目 で各 KPI を取得した際に「はてブ」が増えていなかったためです。

なぜ増えていないのか(おそらく以前から)を考えたところ「はてブ」を付けていただけるような記事を作ることはもとより、そもそもボタンを設置していないのが大きかったのではないかと反省し導入しました。

また改修していて気づいたのですが [共有] ボタンを押してから、使いたい SNS のボタンを選ぶ手順も良くないなと。[共有] の右に直接アイコンを並べるようにしたいと思いますが、そのお話は次回。

ウェブサイトのちょっとしたところを修正したい場合に、Chrome DevTools [検証] からの、全文検索は結構使えます。スタイルを手直ししたり、配置を入れ替えたりといったときにおススメです。

ブログメンティふりかえり1週目

カック@ブロガー / k9u(@kakakakakku)さん にブログメンターをしていただいて1週間。さっそく、ふりかえりの記事を書きます。当初は隔週で書きたいと考えていましたが、最初の1週間で圧倒的な影響を受けているので、熱いうちにアウトプットしたく、1週目にしてふりかえりを書きます。

シリーズの記事

ブログ メンティー としての目標設定

技術系記事を以下のペースで公開することを設定しました。(※ このシリーズの記事はカウント外)

  • 週1回を必達とする
  • 週2回を目標として設定する

1週目は以下の記事を書くことができ、目標を達成できました。

Shiftup! のイベントで発表させていただいたので、たくさんの記事を書くことができました。今週は技術記事を書いていく予定です。

各種メトリクスの推移と考察

毎週日曜日に以下のメトリクスを取得しています。
こちらは達成数値のノルマとかではなく、推移を見ていただいています。次回からグラフで表示できるようにします💦

週間 PV


Google Analitycs で取得しています。
全体、ブログ、lulzneko で取得しているのは riotz.works ドメインがブログだけではなくイベントでの発表用の資料やアプリが同居しているのと、メンバー の うさぎ / Riotz.works(@lopburny)javaponny(@javaponny) が書く記事も含まれるため、分類しています。

イベントで発表したため記事の伸びより全体の伸びのが大きくなっています。発表資料にアクセスいただいたのと、記事の埋め込みからもアクセスになるので差が出ています。

トップ5は以下で、こちらがアクセス数の 85% を占めています。
私の記事へもたくさんのアクセスいただきありがとうございます。

Shiftup! イベントや名刺セミナーは直近だったことと、Twitter ハッシュタグなどから来ていただいた方も多かったようです。2位のアドベントカレンダーで書いた記事や、4位の JAMStack 記事が根強く見ていただけているようで、うれしいです!
メンティ始まるは、カック@ブロガー / k9u(@kakakakakku)さん砲です。

アクセスいただき、ありがとうございます。
引き続き、よい発信ができるよう精進します。

はてなブックマーク数


サイト内の合計はてブ数を表示するツール|はてブチェッカー で取得しました。
スタート時から変化なく。
ブログ内にはてなブックマークをつけるためのボタンなどを用意していないのが悪いです。。。このブログは Hexo を使っており、たしか Plugin があったはずなので設置したいと思います。

[2019-04-10 追記]
ブログ で 使っている Hexo の SNS 共有リンク に はてなブックマーク を 追加する を書きました。
Plugin はなかったのでテーマを直接修正する方法で実現しました。

Twitter フォロワー数


フォローいただきありがとうございます。

メンティ始まると Shiftup! イベントでフォローしてくださった方が多かったように感じました。しっかり情報発信してまいりますので、今後ともよろしくお願いいたします。

気づき、学び

「すぐに」「ポジティブに」

カック@ブロガー / k9u(@kakakakakku)さん が、すぐにレスポンスをしてくれ、そしてエネルギーをくれる話し方をしてくれます。
書いた記事のレビューや、相談、チョットしたやり取りといった時に、すぐにレスを返してくれて前向きなコメントをもらえる。これがすごくエネルギーになり次のアクションをする原動力になって、記事を書いたりして DM する。そしてまたすぐに返ってくると、とてもよいサイクルを作ってくれいます。ありがとうございます!!

この「すぐに」「ポジティブに」は、とても素晴らしいエネルギーになるということを身をもって勉強させてもらいました。これは、どのような場面でも役に立ち、よい環境を生み出します。このやり方を身に着けて使えるようになりたいです。

コミュニティへの感謝と貢献

技術について書くには、まったく新しい技術をゼロから全部生み出さない限り、元になる技術や関連する技術があります。そういった技術に対して、コミュニティに感謝し還元することを大事にされていて、それを記事のレビューや会話の中から自然と伝えてくれます。

Hexo を使っている話から「記事を書こう、そして Pull Request を出してみよう」や、Shifter への機能提案の記事では「コミュニティへ投げかけてみよう」など、技術やコミュニティへ貢献する活動を意識することを心がけるようになりました。

これは技術について記事を書くからだけでなく、普段からたくさんの技術に助けられ、また業務でも使わせてもらいと、とにかくお世話になっています。しっかり感謝して貢献していきたいと思います。
そして貢献する方法も発信していき、多くのコントリビューションが生まれる1つのきっかけしたいです。

ターゲットはだれか!?

記事を書くときに「誰に」「何を」を意識するにようなりました。
これまでは、なんとなくはあるものの「ブログを書く」に寄っていたよう思います。
そのためせっかく書いた後も「ブログ書きました。タイトル、URL」とツイートするだけで、何を書いてよいかわからないというか考えつかないようなことが多々ありました。

イベントやセミナーの参加レポートは参加できなかったけどテーマに興味を持っている人への共有。発表の記事では参加した方に話した内容の振り返りや次の発表の機会があったら多くの方に来てもらえるように。などと読んでくださる人に何を伝え、読んだ後にどうなってほしいのか、どうしてほしいのかを持って書くようにということが自然と意識されるようになってきました。まだまだ漠然とした意識なので、これをしっかり持って記事で伝えたいことをメッセージしていけるようにしたいと思います。

ブログ眼

記事のテーマにつながる話をたくさんしてくださります。そのため自然と「これはテーマになるかな?」という感覚を持つようになってきていると思います。
使っているものなら発信する貢献する、たとえば当ブログで使っている Hexo。
使っている技術と同種だったり関連があるものは調べ発信する、たとえば AWS の話から Amplify Console の評判と東京リージョン提供開始について。
使っていなくても導入しそうなら調べ発信する、たとえば誤字からセルフレビュー textlint。
1つ1つに皆さんへ伝える価値を考え、調べ、使い、発信し、貢献するにつなげていくというループに。そのためにブログ眼を鍛えていきたいと思います。


まだまだあるのですが、まずは大きく感じたところを整理しました。
1週間で非常に多くの気付きに学びがあり、カック@ブロガー / k9u(@kakakakakku)さん 凄すぎます!

DM でのやり取りも褒めていただいたりと嬉しくなって油断してると、せっかくの教えが流れていきそうで慌ててまとめを書き、気を引き締め直しです。

“ターゲット” の項ではないですが、本記事のテーマは「ブログメンターの教えお裾分け」です。
何よりのターゲットは私自身の学びの整理ではありますが、教えて頂いている内容はブログを書いている方や書こうと思っている方の参考になると考えています。そのため頂いた教えを微力ながらもお伝えする次第です。

Shiftup! JP_Getshifter Vol3! 振り返り、Shifterのヘッドレス CMS 化に思いを馳せる

2019年4月3日に開催された「Shiftup! JP_Getshifter Vol3!はじめてのスタティックサイトジェネレーター」でディスカスした「Shifter のヘッドレス CMS 化」についてアイデアになります。
WordPress コンテンツ作成管理 + スタティック・サイト・ジェネレーター ウェブ生成 + Shifter 運用管理な構成っていかがでしょう?

シリーズの記事

イントロダクション

Shiftup! JP_Getshifter Vol3! にて Shifter Webhooks の発表がありました。
このは Shifter がサイト生成した際に、Shifter CDN 以外のホスティング環境へデプロイできるようにする機能です。

この機能についてピザ休憩で話をしている際に、Shifter の生成済みウェブサイトを流すのではなく「管理しているコンテンツを任意の CI へ流すことができたらすごいのではないか」という話で盛り上がりました。

発表者 青空俯角 / mimi(@miminari)さん のブログ gridsomeのススメとShifterの可能性について – Photosynthesic blog で言及されている、こちらになります。

ざっくり言うと Shifter の WordPress エディターとコンテンツ管理・運用を利用ターゲットとし、WordPress で作成したコンテンツのソースを任意のスタティック・サイト・ジェネレーターにかけて JAMStack なサイト生成するということができるのではないかという話です。

スタティック・サイト・ジェネレーターを使う場合、コンテンツ管理をヘッドレス CMS というエディターとコンテンツ管理のためだけのサービスを使い、そこからコンテンツを取得してスタティック・サイト・ジェネレーターでサイト生成するという手法があります。
この手法を Shifter で実現すると、とても良いことが起こるのではないかという考えになります。

以下は私の発表で使ったものですが、WordPress の部分を Shifter にして動作させることができたら嬉しいというものになります。(REST で取得するかどうかは別として)

ヘッドレス CMS とは

ここで “ヘッドレス CMS” という概念が急に登場したので、整理しておきます。

JAMStack なブログや記事を配信するサイトを作る際に、その記事のソースをどのように管理するのかという話があります。スタティック・サイト・ジェネレーター自体は記事を管理する機能はなく、特定のソースから JAMStack なサイトを作ることに特化しています。そのため記事のソースを管理する方法が必要となってくるからです。

1つは、ローカルにある Markdown などのファイルをソースとし使う方法になります。
サイトの構成と一緒に記事も管理する方法になります。たとえば、この記事自体は Markdown ファイルとして Git で管理されていて、同じリポジトリ内にサイト生成のテンプレート類も入っています。これを Hexo というツールで JAMStack なサイトとして生成し、GitHub Pages でホスティングしています。

もう1つは、CMS で管理されているソースをもとに JAMStack なサイトを生成する方法です。
この方法で使う CMS はエディター とコンテンツ管理が主体になります。コンテンツの作成と管理に特化していて、ウェブサイトは別で持ってくださいという形です。

このエディターとコンテンツ管理に特化した CMS をヘッドレス CMS と呼びます。
CMS は通常エディターとコンテンツ管理から、ウェブサイトの生成とホスティングまでのすべてを担っています。このウェブサイト生成とホスティングがないものを Headless とし、Headless な CMS、ヘッドレス CMS と呼ばれています。

通常 GUI がないものを Headless と呼ばれますが、ヘッドレス CMS はコマンドラインベースというわけではなく Web UI がちゃんとあります。この場合「ウェブサイト側」がないことを指して Headless と呼ばれるようです。

主なヘッドレス CMS は headlessCMS | Top Content Management Systems for JAMstack sites で見つけることができます。

最近は Contentful が話題になっているようです。(私は Markdown + Git 派なので、ヘッドレス CMS を使ってないです。すみません。。。)

Shifter がヘッドレス CMS 化した場合の世界観

では、Shifter がヘッドレス CMS になると何がうれしいのかということですが、Shifter = WordPress だからです。

WordPress は世界で一番使われている CMS といわれることがあります。最近では note などの新しいサービスが色々登場し、老舗のはてなや技術系のQiita といった人気のサービスもあるとはいえ、なんだかんだで WordPress を使ったり、立ち上げたことがあるのではないか。

その「使っている人が多い」「使ったことがある人も多い」「初心者にも使いやすい」という特性を Shifter は活かすことができます。

そして WordPress のコンテンツ作成力(= エディターと管理) をそのままに、スタティック・サイト・ジェネレーターのウェブサイトの表現力を組み合わせた場合に、すごい相乗効果が得られると考えています。

WordPress のテーマはたくさんあり優れていますが、オリジナルを作ろうとすると途端にハードルが上がります。また、ブログではなくウェブサイトを作ろうとすると、これもまた大変です。この部分をフロント系の得意な技術、つまり任意のスタティック・サイト・ジェネレーターへ転換することができたら、素晴らしいマリアージュが生まれるのではないでしょうか。

では WordPress を自前で立てて、REST API 経由でスタティック・サイト・ジェネレーターへ流したらよいのではないか、まさに発表のときに使った図の構成になります。

しかしながら、この図には欠点があります。WordPressの管理運用をどうするのか。

WordPress を立てて REST 経由でコンテンツを取得すると、WordPress へアクセスできることになり、WordPress を守る必要が出てきます。またバージョンアップなどの管理も必要となります。これは WordPress だけではなく、PHP に、ウェブサーバー、DB、OS とたくさんの管理対象が発生します。

これを Shifter にお願いすることができたら?
完全に管理しておいてくれるので安心であり、管理作業から解放されることになります。

できればスタティック・サイト・ジェネレーターで作ったサイトを Shifter CDN へ返せるとさらによいのですが、そこは難しいようでしたら Netlify や S3 など、CI からデプロイできます。

以上が Shifter がヘッドレス CMS となり、スタティック・サイト・ジェネレーターと組み合わせることの世界観とメリットになります。

まとめ

Shifter がヘッドレス CMS として動作してくれることで以下のようなメリットが生まれます。

  • WordPress による、コンテンツ作成管理力
  • スタティック・サイト・ジェネレーターによる、ウェブサイト表現力
  • Shifter の WordPress マネージドによる、WordPress 管理からの解放

Shifter さん、ぜひ検討してみていただけませんか?
ヘッドレス CMS という表現を使っていますが、生成済みサイトを流すのではなく、単に管理しているコンテンツのソースを流すような仕組みがあればということで、スタティック・サイト・ジェネレーターと組み合わせてステキなことができそうです。

ウェブサイト構築はデザイナーさんやフロントエンドエンジニアさんがやり、記事などのコンテンツを継続的に作っていくのは実務部門やるといったことがあります。そういった時に表現力のあるウェブサイトを作りながらも、WordPress によるコンテンツ管理の運営を発揮できるのではないでしょうか。


Shiftup! JP_Getshifter Vol3! 参加記三部作、最後の記事になります。

ちょうど発表者 青空俯角 / mimi(@miminari)さん と運営の KOGA Hiromichi(@digitalcube)さんSeiji Akatsuka(@seijiakatsuka)さん と Shifter アップデートについての話をして、Gridsome との組み合わせに話が及んで浮かんだアイデアになります。(イントロダクションで青空俯角 / mimi(@miminari)さん記事引用の話)

本記事の主題としては「Shifter さん、ぜひ作ってください」にはなりますが、WordPress の運用部分は発生するものの Gridsome などと WordPress を組み合わせて同様のこともできますし、実際にやったことがある案件で Nuxt.js から WordPress REST API を呼び出してモバイル対応してない既存 WordPress サイトのモバイル対応するというのもやったことがあります。

WordPress とスタティック・サイト・ジェネレーターの組み合わせは、応用力が高いと考えています。
そのためアーキテクチャや考え方などについて発信したく、またヘッドレス CMS + スタティック・サイト・ジェネレーターという JAMStack のアーキテクチャの1つを広めたく書いたものになります。

そして勉強会に参加すると、こういった使い方や新しいアーキテクチャについての議論ができたりします。今回はかなりカジュアルでお話しやすいイベントだったというのもありますが、実際にサービスを展開されている方や発表者さんとディスカスできるのは、とても素晴らしく、よいですね。

どこかでお会いしましたら、いろいろなアイデアについてディスカスしましょう!

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 をサーバーレスで動作させるというコンセプトに感嘆し、エンジニアとしてその技術に興味を持っていろいろと聞かせてもらっというのがあり、まさかの2年越しの再縁で発表の機会をいただくとは。

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

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

発表資料

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

サマリー

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

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

  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 なサイトを作るためのスタティック・サイト・ジェネレーターはどう入手するのかというと、StaticGen https://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 について発表した際に、グラレコを描いていただいたツイートになります。本イベントではないのですが、話の内容を2ページでキレイにまとめて下さり とても分かりやすいので、この記事にも入れさせていただきました。ステキなグラレコ、ありがとうございます!

このグラレコを描いてくだった 近藤佑子🐱技術書典6 か66(@kondoyuko)さん、2019年月14日の 技術書典6これからはじめる 静的サイトホスティング、各種クラウドサービスを活用した静的サイトホスティングの入門書(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 カンファレンスなどの大きいイベントも楽しいですが、小規模な勉強会ではテーマを絞って話をしたり、発表者とディスカスしたりできます。この記事やツイートが勉強会への参加のきっかけとなりましたら幸いです。

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が1ページ、コマンドが簡単で使うことができる
  • とりあえず試すができる

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

GraphQL の入門にぴったり。

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

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

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

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

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

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 さんと多くのコミュニティやサービスの方々とたくさんお話する機会が得られ嬉しいです。

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