ブログで使っている 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: 20pxheight: 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 なサイトを作るためのスタティック・サイト・ジェネレーターはどう入手するのかというと、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 について発表した際に、グラレコを描いていただいたツイートになります。本イベントではないのですが、話の内容を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 さんと多くのコミュニティやサービスの方々とたくさんお話する機会が得られ嬉しいです。

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

ブログメンティ始まる

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を使わせてもらおうかな。