ISO 8601 形式で特定の期間を指定する方法

WebAPI の GET パラメータとして「開始日時」「終了日時」を指定するような時に使える、ISO 8601 の Time intervals (period of time) フォーマットについて紹介します。

ISO 8601 とは?

日付と時刻を表現するフォーマットを定めた国際規格です。以下のような文字列で表現されます。

  • YYYY-MM-DDThh:mm:ss※末尾にUTC の場合は Z、JSTの場合は +09:00 を指定
  • e.g.2019-09-20T21:29:58+09:00

一般的に公開されている各種サービスの WebAPI で、日付とタイムスタンプのような時刻を表現するフォーマットとして広く使われています。詳細については Wikipedia になってしまいますがこちらを参照してください。

ちなみに、ISO 8601 のオフィシャルな仕様書は有料となっています。気になる方はチェックしてみてください。

ISO 8601 については多くの言語/ライブラリにてサポートされており、ISO 8601 形式での出力やパース、Validation などの機能が備わっています。

ISO 8601 の Time Intervals (period of time) とは?

冒頭で記述したように、「開始日時」「終了日時」がある特定の期間を表現する時に使えるフォーマットです。開始日時と終了日時の間に半角スラッシュ/を挟んで記述します。

  • {開始日時}/{終了日時}
  • e.g.2019-08-20T21:29:58+09:00/2019-09-20T21:29:58+09:00

上記の他にもいくつか表現方法はありますが、実装に用いる言語やライブラリの都合を考えて選択すると良さそうです。

何に使える?

例えば日付の属性を持つデータを検索する WebAPI で、startendまたはfromtoといった範囲(期間)を指定するパラメータが必要になる場合、まとめてperiodといった一つのパラメータにすることができます。

状況によりますが、パラメータの数が減り、「ISO 8601 Time intervals フォーマットで指定してください」と簡単に明記できるため、WebAPI の仕様をよりシンプルに記述することができます。

いかがだったでしょうか。

簡単な内容でしたが、個人的な経験として WebAPI 仕様を書いていく中で指摘されたことがあり、記事にしてみました。

最後まで読んでいただきありがとうございました。

デバッグに便利!ブラウザの HTTP 通信ログをアーカイブして共有・確認できる HTTP Archive File / Viewer の紹介

ブラウザと API サーバーの繋ぎこみや画面遷移を伴う他サービスとの連携をする時、予期せぬエラーが起きたり想定外の挙動をしてデバッグに苦労したという経験をお持ちの方は多いのではないでしょうか。

多くの Web アプリ開発で、API サーバーとの通信がどのように行われているかを把握することは不可欠です。上手く行かない場合、どのようなリクエストが送られたか、どのようなレスポンスが返されたかを確認するために、ブラウザのデベロッパーツール(開発者ツール)を利用したり、Fiddler などのツールを利用してデバックすることが多いと思います。

この記事では、こういった時に役立つ手法として、ブラウザのデベロッパーツールで HTTP 通信をキャプチャしてその内容をアーカイブとして保存する方法と、保存したアーカイブファイル(HARファイル)を閲覧するツールについて紹介します。

HAR ファイルとは?

HTTP Archive (HAR) File と言います。通常、一つの Web ページを閲覧すると、そのページで使われる各種ファイル(CSS や JS、画像など)に加え、XHR (XMLHttpRequest)を利用した非同期通信に至るまで多くの HTTP 通信が行われます。HARファイルは、このような一連の通信内容のキャプチャをまとめてJSON 形式でエクスポートしたものになります。

開発者同士でこの HAR ファイルを共有することで、トラブルシューティングに役立てます。クライアント開発側とサーバー開発側の間で断片的なスニペットを送り合うより効率がよく、情報を網羅的に共有できるといったメリットがあります。

具体的には、デベロッパーツールの Network タブを開き、ページをロードしてみます。
※ Chrome の例です。
※ ページをロードする前に “Preserve log“ にチェックを入れておきます。


この状態で HAR ファイルとしてエクスポートすると、下記のような JSON 形式でに出力されます。


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
{
"log": {
"version": "1.2",
"creator": {
"name": "WebInspector",
"version": "537.36"
},
"pages": [
{
"startedDateTime": "2019-09-14T15:35:52.131Z",
"id": "page_1",
"title": "https://riotz.works/",
"pageTimings": {
"onContentLoad": 1157.8740000004473,
"onLoad": 1449.5640000004641
}
}
],
"entries": [
{
"startedDateTime": "2019-09-14T15:35:52.128Z",
"time": 329.85700000062934,
"request": {
"method": "GET",
"url": "https://riotz.works/",
"httpVersion": "HTTP/1.1",
"headers": [
...

HAR ファイルを取得する方法

HAR ファイル出力は各ブラウザでサポートされており、取得の仕方について大きく異る点はありません。Chrome の場合、前述と同じくデベロッパーツールを開いて Network タブを選択、ログをクリアして “Preserve log“ にチェックを入れ、ページをロードします。

そうすると、ページを構成するファイルのダウンロードや通信が発生していることがわかります。どの項目でもいいので、右クリックして Save all as HAR with content すると保存できます。

HAR ファイルの中身を確認するためのツール

先程作成した HAR ファイルは、JSON 形式となっているので普通にエディタで開いて内容を確認することもできます。しかしそのままでは分かりづらいので、ビューアーのツールを利用することになります。

G Suite Toolbox - HAR Analyzer

G Suite Toolbox は本来 G Suite 関連のトラブルシューティングに使われるツールですが、ブラウザ上で利用でき、UI も使い勝手がよく便利なのでおすすめです。

🔗G Suite Toolbox - HAR Analyzer

HTTP Archive Viewer (Chrome Extension)

こちらは Chrome の拡張機能として利用できるツールです。画面内で文字列検索(Ctrl/Cmd+F)ができないので、前述の HAR Analyzer の方を使いたくなるかもしれません。デベロッパツールの Network タブで見るのと同じような UI と感覚で操作できることが特徴です。

🔗HTTP Archive Viewer

いかがだったでしょうか。

HAR ファイルはあまり新しい仕組みとは言えないですが、個人的には複数のチームで開発する現場で役に立ったことがあったので、紹介してみました。最後まで読んでいただきありがとうございました。

Web Storage (localStorage, sessionStorage) を使用する時の注意点

ブラウザのローカル領域にデータを保存できる便利な仕組みの Web Storage ですが、その使い方についてはいくつが注意点があります。

Web Storage (localStorage, sessionStorage) の詳細について知りたい方は、前回の記事をチェックしてみてください。
この記事では、Web Storage を使用する上で注意した方が良い点について紹介します。

プライベート・シークレットモードでも Web Storage API が使えるか

少し前まで、Safari ではブライベートモードにして localStorage にアクセスするとエラーになる問題がありました。この件に関しては 2019 年現在 Fix されていますが、サポートするプラウザの範囲が広い場合、念のためしっかり確認しておいた方が安心かなと思います。

通常モードからプライベートモードに切り替えた場合(またはその逆)の挙動を確認する

通常モードとプライベートモードを切り替えながらアプリを操作することも想定に入れ、主要機能やユーザー認証後の正常動作が localStorage に依存していないかチェックしておく必要があります。
※例えば、URL 直打ちでの表示・画面遷移・エラーハンドリングなど

各種ブラウザの仕様上、プライベートモードになると localStorage も通常モードとは別の領域となりますので、基本的に localStorage に関しては別ブラウザで開くのと同じ状態になると考えた方が良いですね。

ユーザーに紐づくデータの扱いに注意する

ユーザー情報を含め、アプリの主要機能において localStorage にデータをキャッシュするような仕組みは多く使われています。この時、localStorage に保存するデータは有効期限をつけて管理することができないため、ログイン/ログアウトまたはセッション切れなどの状態変更に伴い、適度にクリーンアップするといった対応が必要になります。

センシティブな情報、機密情報を含めない

前回の記事でも触れていますが、Web Storage は JavaScript の API を利用することになっており、XSS(Cross-Site Scripting) のような脆弱性で任意の JavaScript コードが実行されてしまうと Web Storage の内容が抜かれてしまう可能性があります。よって、個人情報を含む情報・セッショントークンなど、漏れてはいけない情報を格納しないようにすることが望ましいとされています。

その点、WebAPI の認証トークンなど機密性の高い情報についてはhttponly属性をつけた Cookie をサーバー側からセットして回避するようなやり方もあったりします。
httponly属性をつけることで JavaScript から Cookie を操作することができなくなるため

また、JWT(JSON Web Token) のようなステートレスなトークンを保存するケースもあります。上記のようなリスクを十分考慮して、他の手段を検討するか、有効期限をかなり短くするといった工夫が必要になります。

キー名が重複する場合がないか確認する

開発が進むに連れて多数のライブラリを利用することになります。この時、アプリ実装側とライブラリ又はライブラリ同士で同じキーを用いて Web Storage にアクセスすることがまれにあります。

当然ながらキーが同じであれば後から書き込まれた値で上書きされてしまいます。これを 100% 事前に把握することは難しいですが、アプリ側であればキーに prefix をつけたり、ライブラリ導入時は念入りに確認しておくことで、バグが減る結果に繋がることもあるかと思います。

以上、一見便利そうな Web Storage ですが、いくつか考慮すべきポイントがあるので記事にしてみました。皆さんの参考になれば幸いです。最後まで読んでいただきありがとうございました。

Web Storage (localStorage, sessionStorage) の概要と使い方

ウェブアプリケーション開発に、localStorage や sessionStorage といった Web Storage を使うことが多くなってきています。

この記事では、Web Storage についての概要と使い方についてまとめてご紹介します。

Web Storage とは何か

ブラウザのローカル領域に key-value 形式のデータを保存する仕組みです。Web Storage の仕様をサポートするブラウザは Web Storage API が使えるようになっています。JavaScript でこの API を利用することで Web Storage にアクセスすることができます。保存できるデータ型は文字列のみで、オリジンごとに区切られた保存領域(5MBまで)を持ち、異なるオリジンの Web Storage にアクセスすることはできません。

「オリジン」について少し具体的に説明すると、

  • URL のスキーム(e.g.http,https
  • ホスト(e.g.example.com等のドメイン)
  • ポート(e.g.80,443

上記の項目すべてが同じであれば、Web Storage にアクセスしてデータを出し入れすることができます。
例えば、以下2つの URL においては同じオリジンとして Web Storage が共有されます。

1
2
https://example.com/main/index.html
https://example.com/sub/index.html

また、以下についてはドメインが異なる(オリジンが異なる)ため、お互いの Web Storage にアクセスすることはできません。

1
2
https://example1.com/index.html
https://example2.com/index.html

サブドメインでも Web Storage は異なります。

1
2
https://app1.example.com/index.html
https://app2.exapmle.com/index.html

平たく言えば、同じウェブサイト内・アプリ内であれば使えるということになりますね。

Web Storage は、2019年現在、モバイルを含めほとんどのモダンブラウザにてサポートされていますが、正確にはこちらをご参考ください。

実際に Web Storage を使っている様子を確認することもできます。Google Chrome の場合、ディベロッパーツールのコンソールを開き、Application タブ > 左側メニュー Storage から Local Storage または Session Storage をクリックして中身を見ることができます。

ここまでの内容は以下のドキュメントを参考にしていますので、詳細を知りたい方は一度読んでみてください。



localStorage と sessionStorage

Web Storage は2つのタイプのものがあります。

localStorage


  • 保存したデータは削除しない限り永続的に保存される(なくならない)
  • 別タブやウィンドウでも共有される
  • ブラウザを閉じたりもう一度開いたりしてもデータは残る

sessionStorage


  • 保存したデータはブラウザを閉じるまでの間のみ保存される
  • 別タブやウィンドウでも共有されない

用途

どういったユースケースがあるのでしょうか?実際のところ、シンプルかつ便利なゆえに本当に色んな用途で使われていますが、よく見かけるケースとしていくつかピックアップしてみると、以下のようなことが挙げられます。

  • 表示に関する各種設定情報(e.g. お知らせ、通知表示の有無)
  • ユーザーの操作やアクションに関する情報(e.g. お気に入り、閲覧したページ、商品)
  • クライアント側の使用状況をまとめてサーバーに送信するための一時保管(e.g. エラーIDをまとめてログサーバーに送信)
  • サーバーとのデータ不整合を防止するためのバージョン情報

一般的には localStorage を利用するケースが多いと思います。また、すべての場面において使って問題ないわけではありません。いくつか注意点がありますので、これについては別記事で紹介する予定です。ぜひチェックしてみてください。

クライアント側でデータを保存する仕組みということで Cookie と似たような印象を持たれることも多いかもしれません。念のため簡単に触れておきたいと思います。

仕組み

Cookie は、サーバーと HTTP 通信をする度に HTTP ヘッダーに含まれて送信され、サーバー側からセットすることもできます。よって、サーバーとのやり取りに伴う状態を管理する場合に使われることが多いです。(サーバーとのセッション管理等)

一方、Web Storage はサーバーとの通信とは関係なくクライアント側(ブラウザ)でのみデータを保持します。

容量制限

Cookie は 4KB、Web Storage は 5MB です。

JavaScriptによる操作

通常、Cookie も Web Storage も JavaScript で操作することが可能です。

しかし Cookie 場合、httponly 属性をつけることで JavaScript から操作することを無効にすることができます。これにより悪意のある第3者によって任意のJSが実行される(e.g. XSS: Cross Site Scripting)ような場合でも、Cookie の中身を JavaScript 経由で見ることができなくなります。

Web Storage の場合、そのような機能はありません。

他にも、Cookie には様々な属性(domain, path, 有効期限… etc.)が用意されているため、挙動を細かく制御することができます。

基本的な使い方

Web Storage API を利用します。localStorage も sessionStorage も、同じく Storage インタフェースを実装する形になっており、使い方は同じです。

1
2
3
4
5
6
7
8
9
10
11
12
// Storage.setItem(key, value)
// Storage.getItem(key)

localStorage.setItem('dummy_key', 'dummy_value');
const item1 = localStorage.getItem('dummy_key');

console.log(item1); // dummy_value

sessionStorage.setItem('dummy_key', 'dummy_value');
const item2 = sessionStorage.getItem('dummy_key');

console.log(item2); // dummy_value

Web Storage の key と value に使えるデータ型は、文字列のみとなります。配列やオブジェクトのような形でデータを保存したい場合は、一度 JSON 文字列に変更して保存します。

localStorage.setItem('dummy_key_2', JSON.stringify({ name: 'John', age: 20 }));
const item3 = localStorage.getItem('dummy_key_2');

const parsed1 = JSON.parse(item3); // {"name":"John","age":20}

sessionStorage.setItem('dummy_key_2', JSON.stringify({ name: 'John', age: 20 }));
const item4 = sessionStorage.getItem('dummy_key_2');

const parsed2 = JSON.parse(item4); // {"name":"John","age":20}

保存したデータを削除することもできます。

// Storage.removeItem(key)
// Storage.clear()

localStorage.removeItem('dummy_key');
sessionStorage.removeItem('dummy_key');

// すべて削除する
localStorage.clear();
sessionStorage.clear();

いかがだったでしょうか。

Web Storage はシンプルながら何かと役に立つ場面が多く、大変便利ですが、いくつが注意点もあります。これについては別記事にて紹介する予定ですので、合わせてチェックしてみてください。

最後まで読んでいただきありがとうございました。

TypeScript で複数のモジュールをまとめて export, import する

TypeScript を使って Node.js のアプリを開発していると、だんだんモジュールの数が増えていき、export, import 文が長くなったり冗長な感じになったりします。また、プロジェクト全体の共通機能をまとめてモジュール化する仕組みを考えたりと、モジュールの構成をどうするかについては常々悩ましいところがあります。

この記事では、モジュール構成のリファクタリングに使えるre-exportsとそれを import する方法について紹介します。元々は ES Modules の仕様なので、Interface など TypeScript の機能を除き JS でも同じく使える仕組みになります。

※ただし、ES Modules の構文(JS)をそのまま Node.js 上で実行する場合は mjs 拡張子の使用・実験フラグ付きの起動が必要になり、詳細については割愛させていただきます。

export

例えば、以下データモデルの Class または Interface を定義して models ディレクトリ以下に配置します。
index.ts を作成、それらをまとめて export しておきます。

  • models/index.ts
    1
    2
    3
    4
    5
    export * from './User'    // User.ts
    export * from './Book' // Book.ts
    export * from './Contact' // Contact.ts

    // default は使えないので注意

import

必要なモジュールを以下のように適宜 importします。


  • 1モジュールのみ import
    1
    import { User } from './models'

  • 複数のモジュールを import
    1
    2
    3
    4
    import { User, Book } from './models'

    const user: User = { id: 'user_id' }
    const book: Book = { id: 'book_id' }

  • 別名をつけてまとめて import
    1
    2
    3
    4
    5
    import * as Model from './models'

    const user: Model.User = { id: 'user_id' }
    const book: Model.Book = { id: 'book_id' }
    const contact: Model.Contact = { id: 'contact_id' }

公式ドキュメント

公式ドキュメントでこの内容を確認したい場合は、下記をご参考ください。

まとめ

export * from '{PATH}'でまとめて export 、必要に応じて適宜 import することができます。

アプリロジックの機能またはレイヤーごとにモジュールをまとめたり、プロジェクト共通の Util クラスをまとめて外部モジュール化したりと、色んな場面で利用できると思いますので、一度試してみてはいかがでしょうか。

最後まで読んでいただきありがとうございました。

draw.io を利用する3つの方法

システム構成図を書く時、ツール選びに悩むことってありませんか?

システム構成図に限らずとも、情報を分かりやすく表現する手段として、いわゆる「お絵かきツール」はとても需要があるのではないでしょうか。例えば Nulab の Cacoo だったり、MS Visio・Excel・PowerPoint だったりと、人によって・現場によって多種多様だと思いますが、今回はその中でも個人的によく使っている draw.io について紹介し、その使い方について共有したいと思います。

draw.io とは?

システム構成図や図面等の作成に便利なお絵かきツールで、ブラウザ上で動くウェブアプリケーションです。オープンソース化(Apache License 2.0)されており、提供元 JGraph の GitHub リポジトリにてソースコードが公開されています。

公式サイトがあるので、合わせてチェックしてみてください。

作成したデータは XML で出力され、ローカルに保存できるだけでなく、Google Drive・OneDrive・GitHub などと連携して保存することができます。もちろん、PNG、SVG、PDF 等の形式でのエクスポートもサポートされています。簡単ですが個人的な観点で以下まとめてみました。

draw.io のいいところ


  • 単体での利用は、商用利用も含めて無料※公式サイト(Pricing)
  • 会員登録不要
  • 作成したデータの管理は自分次第(クライアントサイドのみで動くため)
    • ローカルに保存するものよし、クラウドサービスに保存するのもよし
    • 気軽にクラウドサービスを利用できない環境では特に便利
  • 図形のパーツが豊富
    • 最新のクラウドサービス(AWS・Azure・GCP)の各種アイコン
    • Material Design のパーツ等

draw.io の不便なところ


  • 複数の人で共同編集できない
  • コメントを書く機能がない
  • 履歴を管理する機能がない
  • 書いた図を共有する仕組みがない(※Plugin などを利用すれば可能)

これらの項目については、Cacoo を使うと非常に便利な形で提供されていますので、気になる方は一度試してみてください。

draw.io を利用する方法

draw.io は様々な形で利用することができます。個人的にはこの点が draw.io を使うようになったポイントになりましたので、紹介させていただきます。

1. ブラウザ上で利用する

最も簡単かつシンプルな方法です。ブラウザでdraw.ioを開くだけなので、他に必要なものは何もないですね。普段私は MacBook Air 13 (Early 2015) を使って Chrome 上で作業しますが、サクサク動いてくれて快適です。

サポートされているブラウザについて、GitHub リポジトリに記載されている内容を引用しておきます。モダンなブラウザであれば問題なさそうですね。

Supported Browsers
draw.io supports IE 11, Chrome 32+, Firefox 38+, Safari 9.1.x, 10.1.x and 11.0.x, Opera 20+, Native Android browser 5.1.x+, the default browser in the current and previous major iOS versions (e.g. 11.2.x and 10.3.x) and Edge 23+.

2. デスクトップアプリを利用する

人によっては「ブラウザよりもデスクトップアプリの方が作業しやすい」ということもあるのではないでしょうか。Slack 等もそうですが、人それぞれの作業スタイルがありますので、Electron ベースで作られているデスクトップアプリを利用するのも良い選択です。こちらもオープンソース化(※drawio-desktop)されています。

下記ページを開くと「draw.io Desktop」とありますので、Windows/Mac/Linux 環境に合わせてダウンロードすることができます。

Chrome App としても提供されていますね。

3. クラウドサービス等と組み合わせて利用する

draw.io 単体ではなく、プラグインとして他のサービスと組み合わせて利用する方法です。

Confluence & Jira app

定番の Atlassian 製ソフトウェア開発ツールとの組み合わせです。Cloud版・Server版の両方に対応しており、多くの現場で導入しやすいのではないかと思います。Confluence の場合、Page 内で図を作成・管理することができ、作成した図を他のページに埋め込むこともできます。

ただし、有料となりますので注意が必要です。先程 draw.io の不便なところとして「書いた図を共有する仕組みがない」と書きましたが、このパターンですとある程度解決します。また、リアルタイムでは無理ですが複数の人が図を更新していくことが可能になります。

料金は2019年8月時点で 10 ユーザーまで 570円、以降 100 ユーザーまで 1 ユーザーあたり 60 円となっていますね。

Confluence の場合、登録を完了すると、スペースのメニューに「draw.io Diagrams」が表示されます。

また、「マクロの選択」にて図の作成と埋め込みの機能が追加されます。

その他

公式サイトによると、以下のサービスとの統合もサポートされています。

他にも、draw.io で作成した図をWordPress や Redmine 上に埋め込むためのプラグインなどもありますので、各現場の環境に合わせた使い方を工夫してみてはいかがでしょうか。

最後まで読んでいただきありがとうございました。

Outlook で、自分のアドレスを常に Cc に入れる

マイクロソフトのメール&スケジュール管理ソフトの Outlook。この Outlook、メールを送る際に自分を Cc なり Bcc に設定しておきたいのですが、設定方法が見つかりません。そう、設定ではなくルール、仕分けルールとして定義する必要があるのです。設定方法について紹介します。

Outlook、主に仕事で使っているます。自分が送ったメールは [送信済みアイテム] にあるので基本的には問題ないのですが、自分で仕分けしていたり、レスがなかったりすると送ったメールがどこ行ったか分からなくなるので、Cc か Bcc で自分宛にも送っておきたいところです。

基本的には一度定義すると Exchange Server に保存されているので、改めて定義する必要がないのですが何かの拍子に消えていたり、設定方法を聞かれたりするので備忘録。

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

  • Windows 10 64bit
  • Office 365

仕分けルールの作成

Outlook を起動し、メール機能(受信トレイ)を表示します。
リボンの [移動グループ] から [ルール] - [仕分けルールと通知の管理] をクリックします。
※ [仕分けルールの作成] からは定義できません

仕分けルールと通知の管理ダイアログから、[新しい仕分けルール] をクリックします。

ウィザードが開始されるので [送信メッセージにルールを適用する] を選択し [次へ] をクリックします。
([仕分けルールと通知の管理] から来ないと、このメニューがないのでハマった。。。)

続いて条件指定の定義選択が表示されます。
何もチェックをつけずに [次へ] をクリックします。

条件なし、すなわち、すべての送信メッセージ。[はい] をクリックします。(わかりにくい。。)

処理の定義選択が表示されます。
[名前/パブリックグループをメッセージの [CC] に追加する]へチェックをします。
ダイアログ下段の [ステップ 2] に表示されている [名前/パブリックグループ] をクリックし、アドレス帳から自分のメールアドレスを選択します。

例外条件の定義選択が表示されます。
自分宛のメールの場合は追加する必要がないので、[[宛先] または [CC] が名前/パブリックグループの場合を除く] にチェックします。
ダイアログ下段の [ステップ 2] に表示されている [名前/パブリックグループ] をクリックし、アドレス帳から自分のメールアドレスを選択します。

最後に [仕分けルールの名前] を入力し [完了] をクリックします。(ここでは Cc: Self としましたが、良いネーミングを考えたい)
※ 下図は [名前/パブリックグループ] になってますが、実際には自分の名前が表示されている状態になります

クライアントサイドのルールであること警告されます。Exchange Server 内で処理されず Outlook のソフトウェアだけで適用されます。とくに問題ありません。
(ウェブアクセス版では、このルールが適用されないのでウェブアクセス版を使う場合は注意が必要です)

無事、追加されました。

メール作成の際には、Cc は空ですが送信時には追加されています。


設定できているもののメール作成画面で表示されないので、ちょっと安心できない & 設定が消えていることに気づきにくい。。。

できれば Bcc がよいのですが、良い設定方法が見つからず、今回の設定を使っています。
(長年慣れ親しんだBecky! Internet Mailが使いたいんだけどなぁ)

共有:

Shiftup! JP_Getshifter Vol5! にて「Shifter + SSG の世界」について発表をしました

2019年8月7日に開催された「Shiftup! JP_Getshifter Vol5 暑気払い!WordPressとJAMstackの夕べ」で『Shifter + SSG(Static Site Generator) が生み出す、新しい WordPress の世界』と題して、WordPress の新しい世界について発表をしました。そのサマリーです。

第3回のイベントShiftup! JP_Getshifter Vol3! で JAMStack な サーバーレス ウェブフロント に ついて発表をした際に、Shifterから SSG(Static Site Generator) でサイト生成できたらよいという話で盛り上がり、Shiftup! JP_Getshifter Vol3! 振り返り、Shifter の HeadlessCMS 化に思いを馳せるという記事を書きました。

そしたら Shifter さんの神対応があり「Shifter Webhooksで Netlify上のGatsbyサイトにWordPressコンテンツをインポート可能になりました - 株式会社デジタルキューブ」というアップデートが即だされました。Shifter スゴイ!

その流れから、Shifter で SSG が使えると何が嬉しいのか、どんな世界が描けるのか、当初考えていたことを整理し発表しました。

シリーズの記事

“Shiftup! JP_Getshifter Vol5 暑気払い!WordPressとJAMstackの夕べ” 概要

発表したイベントShiftup! JP_Getshifter Vol5 暑気払い!WordPressとJAMstackの夕べは、サーバーレスな WordPress ホスティングShifterのユーザーコミュニティの勉強会です。

会場は決済サービスのStripeさん。原宿は竹下口交差点のステキなロケーション&最高な眺めのオフィスです。ちょうど Stripe さんのセッション中に「神宮花火ナイター」の花火が上がり、絶好の眺めとなりました。花火が見えるオフィス、いいなぁ。

発表資料

Shifter + SSG(Static Site Generator) が生み出す、新しい WordPress の世界』の発表資料はこちらになります。(下記、スライド埋め込み)

サマリー

発表の主旨は「Shifter と SSG を使って、WordPress のウェブフロントの新しい考え方を作ろう」です。

おおきく3つのテーマで発表しました。

  1. Shifter が もたらした、新世界
  2. Shifter + SSG が 生み出す、さらなる新世界
  3. Shifter + SSG の 可能性

前半は Shifter の機能やメリットを振り返る内容で、後半から SSG と組み合わせた場合の世界、メリットの話になります。

Shifter が もたらした、新世界

まずは、WordPress と Shifter の違いについてです。WordPress は言わずと知れた世界でもっとも使われている CMS。ウェブサイトの 30% は WordPress と言われているぐらいだそうです。

そんな、すごい WordPress の世界ですが少し困り事も。WordPress サイトの立ち上げまでは、ある程度情報があるし楽しめるところもあります。しかしながら、セキュリティ対策は難しい面もありますし、なにより運用段階での各種バージョンアップ対応が大変。ウェブサイトなので、どうしても不特定多数からアクセスされるのでセキュリテ対策と継続的なバージョンアップは必須です。

そうした中、Shifter は “Serverless WordPress”、”JAMStack WordPress” という形で困り事に対処してくれます。

ひとつは、Serverless WordPress(またはManaged WordPressWordPress SaaS)。
Shifter へサインアップしてサイトを作るだけで WordPress の環境が構築される、そして構築された環境のバージョンアップなどのメンテは Shifter がやってくれる。これにより、どれだけの困り事がなくなるか。

もう1つは、JAMStack WordPress
これも Shifter のスゴイところ。「JAMstack 公式」では、WordPress は JAMSstack ではない “A site built with a server-side CMS like WordPress, Drupal, Joomla, or Squarespace. -JAMStack“ と言っています。しかしながら Shifter は JAMSstack として実現しています。
これによりパフォーマンスとスケーリングを実現し、WordPress として本体をさわる人を限定することでセキュリテ問題を局所化&Serverless WordPressでセキュリティ対策をしています。

Shifter + SSG が 生み出す、さらなる新世界

ここまで「”至れり尽くせり” な WordPress = Shifter」ですが、あと1つ。ウェブフロントの開発を WordPress Theme だけでなく、何とかしたい。JAMSstack の技術にしたいというがあります。

それが Shiftup! JP_Getshifter Vol3! で、参加者の皆さま、Shifter の中の人と、お話しさせていただいた「Shifter の WordPress HeadlessCMS 化に思いを馳せる」であり、神対応していただいたShifter Webhooks + SSGです!

こちらの機能が欲しかったのは、PHP の中に HTML/CSS/JavaScript を書くのが大変、つまり JAMSstack(の “Better Developer Experience”) でない最後の困り事を解決したかった。もし JAMSstack 系の技術だけで WordPress のウェブフロントを作れたらすごいのではないか?そして、その先に?ということです。

Shifter + SSG の 可能性

ウェブフロントの世界では JAMSstack という考えが広まりつつあります。詳しくはJAMStack、それはハイパフォーマンスなウェブフロントを実現するアーキテクチャを、ご参照ください。

一方で JAMSstack なウェブサイトとはいえデータソースは必要です。JAMSstack が、一番得意なのは情報発信サイト。つまり WordPress のような CMS に投稿された情報発信するようなサイト。

CMS といえば?= WordPress、これまでの話の通り WordPress を使うなら Shifter のメリットを生かすとよいでしょう。そして、ウェブフロントをGridsomeGatsbyJSといった SSG を使って作る。これにより、ウェブ・フロントエンドの技術者が WordPress のサイトでありながら、ウェブ・フロントエンドの技術だけウェブサイトを実現できるようになります。新しい世界が作られ、新たな市場が生まれるといっても過言ではないでしょう。

これまでにも WordPress の Theme を SSG 系の技術(の要素技術といったほうが正しいかな)を使って作る方法はありましたが、SSG だけで作るケースは少なかったと思います。それは WordPress の REST API を使う必要があるからです。そうなると結局 WordPress を運用するので、あえて SSG を使うよりも WordPress の技術スタックで作るほうがよいです。

Shifter により WordPress の構築・運用から解放されることで WordPress + SSG が急浮上します。むしろ通常のウェブフロントの開発と同じになります。純粋にウェブフロントだけを管理するようなモデルが生まれるのではないでしょうか。


Shifter + SSG、新しいウェブサイト開発の潮流になるのではないかと思っています。

SSG を使った JAMSstack サイトの開発としては、データの投入として Headless CMS を使うケースがあります。最近は Headless CMS であるContentfulなどの名前を聞くケースが増えてきました。

新しいサービスはもちろんウェルカムなのですが、1つだけ困ることがあります。記事を書く人が「そのサービスを使い倒すことができるか?」です。

個人やエンジニアブログなどでしたらよいのですが、技術系ではない人が使うには難しかったり、情報が少なくて調べられない、知ってる人や使ってる人が少ないなどの問題が出てきます。その点で WordPress は No.1 CMS であり多くの情報や利用者がいます。このアドバンテージを生かしつつ、WordPress の構築・運用からは手離れ、ウェブフロントをモダンな技術で手早く作る。

まだ Shifter Webhooks + SSG も出たばかりですし、これからだと思いますが新しい流れができたら、おもしろいですね。

OpenAPI (Swagger) 3.0 で Bearer トークンの使用を定義する

Bearer トークンを使用して WebAPI 呼び出しをする場合、OpenAPI (Swagger) 3.0 ではどのように記述するのでしょうか。

OpenAPI (Swagger) で WebAPI の仕様を記述する際、HTTP 認証・認可を行うための手段として Basic 認証・Bearer スキーム・API キー等の使用を定義することができます。この記事ではアクセストークン等による Bearer スキームの記述方法について紹介します。

※ OpenAPI (Swagger) については以下の記事で取り上げていますので、合わせてご確認ください。

Bearer スキームとは

HTTP 認証スキームの一つで、WebAPI へアクセスするためのセキュリティトークン(アクセストークン等)をAuthorization: Bearer {トークン}という形で HTTP ヘッダーにセットし、トークンの受け渡しを行う仕組みです。ここでは詳細を割愛させていただきますが、気になる方は以下をご参考ください。


やりたいこと

WebAPI の仕様として Bearer トークンの使用を明記し、Swagger UI の動作に反映させることです。Swagger UI で見ると、以下のように Authorize ボタンが表示されます。

赤枠のボタンをクリックすると以下のダイアログが表示され、Bearer トークンを入力することができます。

トークンを入れて Authorize ボタンをクリックすると、Bearer スキームが指定されている API は Swagger UI 上から Bearer トークン付きでリクエストが送信されます。

Bearer スキームの Authorization ヘッダーがついていますね。

Bearerという文字列も挿入されますので、こちらで入れる必要はありません。

記述方法

ここでは OpenAPI の記述に YAML 形式を使用します。

  1. components.securitySchemesに Bearer スキームを追加します。
    1
    2
    3
    4
    5
    6
    components:  
    securitySchemes:
    Bearer:
    type: http
    scheme: bearer
    description: Credentials or access token for API

2. Bearer スキームを使用する API を指定します。
1
2
3
4
5
6
paths:
/users/me:
get:
# ...
security:
- Bearer: []

※ ルートレベルのsecurityを定義すると、すべての API に適用されます。

1
2
security:
- Bearer: []

記述する場所を分かりやすくするため、簡単な図で表現すると以下のようになります。
OpenAPI Object の詳細はこちらでご確認ください。

ご参考までに、OpenAPI (Swagger) 2 では、ルートレベルにsecurityDefinitionsを定義して各 API に指定します。OpenAPI 3 になって項目が多少変わっていますので注意が必要です。

いかがだったでしょうか。

前回の記事に続き、Swagger UI を利用する便利さをお伝えしたく、WebAPI 呼び出しに Bearer トークンが必要となる場合の API 定義について記事にしてみました。最後まで読んでいただきありがとうございました。

レイアウト微調整に便利な Spacing Helper (Vuetify) を使ってみる

Web UI を実装する時、追加したパーツが思った通りの位置に定まらず、どうしても微調整をしたくなることがあります。

Vuetify のような UI フレームワークを使用している場合、自前で CSS を書き足したり修正するようなカスタマイズは最小限にしておくことが良いと考えられますが、それでも「ここだけなんとかしたい」という場面が出てくると思います。具体的には margin や padding を指定して要素間の間隔を整えたりすることで、例えば以下のように Helper CSS を定義して対応することが多いのではないでしょうか。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
.p-0 {
padding: 0px;
}

.pt-0 {
padding-top: 0px;
}

.pb-0 {
padding-bottom: 0px;
}

.pl-0 {
padding-left: 0px;
}

.pr-0 {
padding-right: 0px;
}

...

しかし、Bootstrap や Material-UI など、最近のメジャーな UI フレームワークには上記のような CSS Helper Class が予め用意されているので、これらを上手く活用することで、作業効率を高めることができ、きれいなレイアウトに仕上げることができます。この記事では、こういった UI フレームワークの一つ、Vuetify の Spacing Helper Class について紹介します。
※ 詳細はVuetify 公式ドキュメントにて確認いただけます。

使い方

微調整を行いたい要素に、下記フォーマットを用いてクラスを指定します。

1
{property}{direction}-{size} // e.g. <p class="mt-1" ...

property

margin か padding のどれかを指定します。

  • m: margin
  • p: padding

direction

direction は指定した property の方向を定めます。

direction方向
ttop(トップ)
bbottom(ボトム)
lleft(左)
rright(右)
xleft と right
ytop と bottom
aleft, right, top, bottom 全てに適用

size

size は property のサイズが 4px 単位で指定されます。0-12の数字が指定できます。
くっつけたい場合は0を指定します。

サンプルコード

以下、Title + Description 構成のリストに使用したサンプルです。各項目にはpy-5を適用して、間隔を広くしています。また description の行にはml-5を適用して、インデントを作ってみました。

See the Pen[Vuetify] Arrange components with spacing helpersby lopburny (ロップバーニー) (@lopburny) onCodePen.

このサンプルは挙動を確認するためのシンプルなものですが、v-layout や v-card など色んなコンポーネントに適用できますので、何かと微調整が必要な場合に使用してみると便利だと思います。

いかがだったでしょうか。

この Spacing Helper については、前述のように Vuetify に限らず色んな UI フレームワークで提供されています。個人的には特にデザインの要件が無い限り自前で CSS を書きたくない人なのでこういう機能を重宝しますが、好き嫌いに関係なく必要に応じて便利な機能を使っていく姿勢が大事だと思います。記事を読んでいただきありがとうございました。