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します。

• １モジュールのみ 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 クラスをまとめて外部モジュール化したりと、色んな場面で利用できると思いますので、一度試してみてはいかがでしょうか。

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

Author:lopburny

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

システム構成図に限らずとも、情報を分かりやすく表現する手段として、いわゆる「お絵かきツール」はとても需要があるのではないでしょうか。例えば 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」が表示されます。

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

その他

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

• G Suite and Google Drive
• Office 365 and One Drive

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

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

Author:lopburny

マイクロソフトのメール＆スケジュール管理ソフトの 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が使いたいんだけどなぁ)

Author:lulzneko

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

第３回のイベント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！ にて「Shifter ＋ SSG の世界」について発表をしました(本記事)
• Shiftup! JP_Getshifter Vol3！ で JAMstack な サーバーレス ウェブフロント に ついて発表をしました
• Shiftup! JP_Getshifter Vol3！ 参加レポート
• Shiftup! JP_Getshifter Vol3！ 振り返り、Shifter の HeadlessCMS 化に思いを馳せる

“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 のウェブフロントの新しい考え方を作ろう」です。

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

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 WordPressやWordPress SaaS)。
Shifter へサインアップしてサイトを作るだけで WordPress の環境が構築される、そして構築された環境のバージョンアップなどのメンテは Shifter がやってくれる。これにより、どれだけの困り事がなくなるか。

もう１つは、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」ですが、あと１つ。ウェブフロントの開発を 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 のメリットを生かすとよいでしょう。そして、ウェブフロントをGridsomeやGatsbyJSといった 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などの名前を聞くケースが増えてきました。

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

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

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

Author:lulzneko

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

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 定義について記事にしてみました。最後まで読んでいただきありがとうございました。

Author:lopburny

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 の方向を定めます。

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 を書きたくない人なのでこういう機能を重宝しますが、好き嫌いに関係なく必要に応じて便利な機能を使っていく姿勢が大事だと思います。記事を読んでいただきありがとうございました。

Author:lopburny

今回は Vuetify でシンプルな入力画面を実装するといった時に遭遇するかもしれない挙動の一つとその対応について紹介します。
v-form の中に一つの v-text-field を配置し、フォーカスを当てた状態で Enter キーを押すとページがリロードされることがあります。
投稿されて1年以上経過しているものですが、以下 Vuetify の GitHub Issue にも Bug Report がありました。

• [Bug Report] v-form with single v-text-input submits on enter
  https://github.com/vuetifyjs/vuetify/issues/3032

• [Bug Report] v-form reloads the page when user press enter while editing v-text-field
  https://github.com/vuetifyjs/vuetify/issues/4302

リロードされる原因

この問題、実は Vuetify に限った話ではなく、前からある Implicit submission （暗黙の submit）という HTML の仕様によるもので、バグということではありません。

具体的にはデフォルトボタンによる submit が適用される場合で、入力中に Enter キーによって submit イベントが発火します。HTML の仕様書を読んでみると多少ややこしい記述にはなっていますが、少し抜粋して要約・補足すると下記のようになります。
🔗https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#implicit-submission

If the form has no submit button, then the implicit submission mechanism must do nothing if the form has more than one field that blocks implicit submission, and must submit the form element from the form element itself otherwise.

form内に submit ボタンがない時、

• 暗黙の submit をブロックする項目が２つ以上ある場合：暗黙の submit は動作しない
• 暗黙の submit をブロックする項目が１つある場合：Form document の URI へ submit する

と定義されています。

For the purpose of the previous paragraph, an element is a field that blocks implicit submission of a form element if it is an input element whose form owner is that form element and whose type attribute is in one of the following states: Text, Search, URL, Telephone, E-mail, Password, Date, Month, Week, Time, Local Date and Time, Number

暗黙の submit をブロックする項目とは、form の中にある input 要素で、type 属性が Text, Search, URL, Telephone, E-mail, Password, Date, Month, Week, Time, Local Date and Time, Number というものです。

つまり、HTMLとしては「一つのテキストフィールドがある」及び「submit ボタン (type="submit") がない」状態では、 Enter キーを押すことで sutmit するのが正しい仕様ということですね。

v-form コンポーネントを使用する場合、ボタンに v-btn を利用するとtype="button"となるため、ブラウザによって暗黙の submit として扱われるようになることが原因となります。

CodePen で再現してみると以下のようになります。
※ Vue.js 2.6, Vuetify 2.0 を使っています。

See the Pen(Vuetify) v-form reload issue sampleby lopburny (ロップバーニー) (@lopburny) onCodePen.

解決方法

以下のように submit イベントを抑えてしまいます。

1
2

<v-form ref="form" @submit.prevent>
  <v-text-field ...

CodePen のサンプルはこちらです。
※ Vue.js の省略記法を使っています。

See the Pen(Vuetify) v-form reload issue sample - resolvedby lopburny (ロップバーニー) (@lopburny) onCodePen.

Vue.js 公式ドキュメントにも、ピンポイントで対応方法が記載されています。

1
2

<!-- submit イベントによってページがリロードされません -->
<form v-on:submit.prevent="onSubmit"></form>

ユーザーに対して明示的に submit ボタンを押してもらうアクションを期待している場合は、これで解決します。
form 要素の submit イベントを抑制し、ボタンを押したときのクリックイベントで対応する形です。

しかし、あえて Enter キーを押した場合に submit イベントを発火したいということもあります。
Vuetify の場合、v-form コンポーネントと各入力要素の rule 属性によるバリデーションを実装することが多いので、このケースはあまりないかと思いますが、一応上記に加え下記のように対応することで実現できます。

1

<v-text-field @keyup.enter="customMethod()"></v-text-field>

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

今回紹介した挙動については、古くからある HTML の仕様なので Vuetify に限らず多くの記事が出ておりますが、
Vuetify 特有のバグや癖だと思ってハマることもあるかと思い、記事にしてみました。
最後まで読んでいただきありがとうございました。

Author:lopburny

2019年7月23日に開催された「CloudNative Days Tokyo 2019」で『サーバレス・ネイティブ が お伝えする、フルサーバレス開発の魅力』と題して、サーバーレスの魅力について発表しました。その発表サマリーです。

“CloudNative Days” 概要

発表したイベントCloudNative Days Tokyo 2019は、元は ContainerDays というイベントで今年の４月から CloudNative Days と名称が変わりました。また今回はOpenStack Days Tokyo 2019との共同開催です。４月の福岡をスタートに、７月の東京、11月の大阪と続きます。

会場は虎ノ門ヒルズフォーラム。はじめて行きました。地下鉄虎ノ門駅から細い歩道なので少し距離がある感じはしますが、新橋にも出られたりといい感じの場所です。

発表資料

『サーバレス・ネイティブ が お伝えする、フルサーバレス開発の魅力』の発表資料はこちらになります。(下記、スライド埋め込み)

サマリー

発表の主旨は「コンテナーもいいけど、サーバーレスもスゴクいいからね。ぜひ！」です。
大きく４つの観点からサーバーレスの魅力をお話しました。

• アイデアを即、形にできる 魅力
• アプリの開発に専念できる 魅力
• ピタゴラ装置を組み立てる 魅力
• JAMstack な サイト管理の 魅力

アイデアを即、形にできる 魅力

モバイルアプリのハッカソンで、ラップバトルの動画中継と配信をするアプリを作ったのを例に、いかに高速でアプリが開発できるかを話しました。

動画の取り扱いとなると、かなり手間がかかるのですがSkyWay - Enterprise Cloud WebRTC Platformを使うことで容易に動画中継と配信を実装できました。

また対戦ルーム管理などは Lambda と DynamoDB で構築しています。Web API を簡単に構築できる基本的な構成になります。「👍」やチャットなどのリアルタイムのコミュニケーションは Fibrebase を使い、マルチクラウドの構成となっています。

クラウドがさまざまな機能を用意してくれ、また SaaS によって必要な機能を組み合わせられるので、24時間という限られた時間でも動画を扱うようなアプリを作ることができます。この高速な開発力はアイデアをすぐに形にできる、サーバーレスの魅力のひとつといえるでしょう。

アプリの開発に専念できる 魅力

IoT 製品のバックエンドを構築した際に、実行ランタイム(= 開発言語) を切り替えるというケースがあったのを例に、その様な事態でもアプリの開発(コーディング)だけに注力できるという話をしました。

このプラットフォーム開発当時、Lambda の Java ランタイムは初期起動(コールドスタート)が遅いという問題がありました。それでも多くの場合、処理が遅いと感じるレベルで大問題にはならないのです。しかしながら私たちの場合はマイクロサービスとして、いくつもの Web API を相互呼出しする形になっていました。そのため初期スタートに当たる確率も高くなり、また初期スタートに当たるとリクエストがタイムアウトしてしまう問題へつながってしまいました。

いくつかあった解決策から実行ランタイムを Java から Node.js へ切り替えるという決断をします。開発言語が Java から JavaScript へ変わるのですが、TypeScript を導入することで Java チームとしても静的型付けによる親和性により切り替えに成功し、問題を解決しました。

実行ランタイムを変えるのはかなりの変更となりますが、AWS では監視やログなどが構成済みのため変更箇所はプログラムの再実装だけになります。ミドルウェアやスケールアウトさせるための仕組みなどを考える必要がないので、アプリ開発に専念できる魅力があります。

※ 補足
2019年７月現在、Lambda の起動が高速化され Java ランタイムのコールドスタートでも１秒ぐらいで起動しています。Java 実装が残っている部分で処理速度の確認があり気づきました。簡易で調べた結果なので、きちんとした検証は必要ですが、かなり改善されたのではないでしょうか。
またサービス提供者が性能を向上させてくれることで、システムのパフォーマンスが自動的によくなるメリットもあるとも言えるでしょう。

ピタゴラ装置を組み立てる 魅力

クラウドの機能や SaaS の機能を組み合わせることを「ピタゴラ装置」に見立てて、お話しました。”ピタゴラ装置は NHK Eテレの番組『ピタゴラスイッチ』に登場するからくり装置 -Wikipedia“ です。最初のきっかけ以降は運動エネルギーを引き継いで流れていくもので、いわゆるドミノの複雑版といった感じです。

サーバーレスのイベント駆動でつながる処理がまさにピタゴラ装置的で、最初のイベントを受けて以降、次々と処理が流れていきます。たとえばラップバトルのピタゴラ装置は以下です。

スマホアプリからルームの作成処理を API Gateway へリクエストします。API Gateway から Lambda が起動し、DynamoDB へルームのデータを登録します。
続いて通知を送るのですが、よくあるのが Lambda で「DB登録 ⇒ 通知」と処理を続けること。しかしイベント駆動で流すので、ここは DynamoDB Streams を使ってデータ登録のイベントから Lambda を起動して通知の処理をします。

このような形でクラウドの機能や SaaS を活用してアプリやシステムを組み立てていきます。これにより実装がシンプルになります。さまざまな機能を組み合わせつつ、シンプルな作りをする。これは楽しくもあり、多くのメリットを享受できる魅力とも言えます。

JAMstack な サイト管理の 魅力

JAMstack、最近 話題になりつつあり、フロントエンドやウェブの開発などで見聞きする機会が多いキーワードです。

サーバーサイドをサーバーレスで構築していても、フロントのためにウェブサーバー(動的な処理ができるサーバー)を用意するケースが多く、どうしてもシステム全体でサーバーレスにできないケースがあり、最近は JAMstack を推進しています。

JAMstack を簡単に言ってしまうと、HTML は事前生成してリクエスト時には動的に生成しない。動的要素はブラウザ(クライアントサイド)の JavaScript で Web API 等を呼び出して作るようにするということです。

これにより、HTML は CDN に配置されウェブサーバーは必要としません。フロントを含めてサーバーレスにできます。サーバーレスであれば JAMstack でなくともよいのですが「フロントもサーバーレスで」というより「JAMstack で」といったほうがわかりやすいので、そのように言っています。

また JAMstack という観点からは、Serverless WordPress のShifterという素晴らしいサービスがあるので紹介します。

利用者としては、Shifter で WordPress を起動してコンテンツを編集。コンテンツの編集が完了したらサイト生成して、コンシューマー向けの静的サイトを作り、そちらへアクセスしてもらいます。これにより WordPress 本体へアクセスされないのでセキュリティを高められますし、静的サイトなので高速です。まさに JAMstack の思想を実現したサービスといえます。

コンテンツ管理はさまざまなサービスがあり、最近では「ヘッドレス CMS」なども登場していますが、やはり WordPress の使いやすいさ、そして認知度の高さは外せません。コンテンツ管理の仕組みが必要な場合は検討したいサービスです。

8/7(水) には、Shifter と Static Site Generator を組み合わせた、WordPress の新しい活用についてお話しますので、良かったらご参加ください。

まとめ

サーバーレスに興味を持っていただけましたら、ぜひ 10月の ServerlessDays Tokyo へお越しください。国内最大のサーバーレスのイベントです。

元が ContainerDays という名前の通り、Docker や Kubernetes のセッションが多い構成の中、「サーバレス・ネイティブ」だの「フルサーバレス」というかなりイキり気味のセッションを採用いただけ、そして当日も空いているのが数えられるくらいの数席を、満席でのご参加いただきありがとうございます！

サーバーレスへの関心につながりましたら幸いです。

Author:lulzneko

先日、Vuetify 2.0 がリリースされ、新しく追加されたコンポーネントの中で個人的にほしかったものを一つ紹介したいと思います。
※ 2.0のリリースで追加された機能とコンポーネントの一覧は、こちら🔗で確認できます。

Banner

Material Design 2 で登場した Banner ですが、ユーザーに「確認してほしい」メッセージと、「やってほしい」アクションのボタンを組み合わせて提示するコンポーネントです。Dialog や Snackbar でも似たようなことは実現できますが、その使い方については以下のように定義されています。

※ Material Design 2 > Banners > Usage 抜粋🔗

Banner は画面に一つのみ表示されるものとして、ユーザーにとって見やすい場所、つまり Top App Bar とコンテンツの間に配置されることが想定されています。Material Design 公式ドキュメントで紹介されている使い方の他にも、重要なメンテナンス予定の告知、アンケートやフィードバックの依頼、キャンペーン等の用途にも応用できるので、結構助かります。わざわざ Dialog を実装するほどでもないし、自動で表示されなくなる Snackbar だとユーザーに気づかれない場合に Banner を使うと便利かなと思います。

VBanner (v-banner)

Vuetify 2.0 のリリースにて VBanner コンポーネントが追加され、Web UI で使えるようになりました。Vuetify では、single-line / two-line / multi-line とメッセージの行数を指定、メッセージとボタンに加えてアイコンを表示することができます。下記、一般的に使われそうな用例を２つ紹介します。

single-line + アクションボタン

画面イメージ

サンプルコード

1
2
3
4
5
6
7
8
9

<v-banner single-line>
  ここにバナーのメッセージが入ります。
  メッセージが長くなれば文末が ... という感じで省略されます。
 
  <template v-slot:actions>
    <v-btn text color="deep-purple">DISMISS</v-btn>
    <v-btn text color="deep-purple">RETRY</v-btn>
  </template>
</v-banner>

アイコン + two-line + アクションボタン

画面イメージ

サンプルコード

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<v-banner two-line>
  <v-avatar slot="icon" color="deep-purple" size="40">
    <v-icon color="white">
      device_unknown
    </v-icon>
  </v-avatar>
 
  デバイスの画面サイズに合わせてメッセージの文字数を確認しておく必要があります。
  通常は 1-2 行が望ましく、簡潔で理解しやすい文章にすることが重要です。
 
  <template v-slot:actions>
    <v-btn text color="deep-purple">LEARN MORE</v-btn>
    <v-btn text color="deep-purple">GOT IT</v-btn>
  </template>
</v-banner>

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

Vuetify の公式ドキュメントには色んな設定値を適用して表示を確認できるPlayground🔗が提供されています。是非試してみてください。

現時点（2019年7月下旬）では Vuetify 2.0 がリリースされて間もないので、いきなり更新すると色々問題もあったりするみたいですが、そのうち改善されることを期待しています。これからのアップデートも楽しみですね！

Author:lopburny

Web 開発の現場でよく耳にする言葉として Swagger というものがあります。アプリケーション開発においてサーバー（WebAPI）とデータの送受信を行う機能は不可欠なものとなっている現在、多くの現場ではそのための設計モデルとして REST (REpresentational State Transfer) という方式が使われています。この記事では、REST API の仕様ドキュメントを記述する手段として OpenAPI (Swagger) というものを紹介し、REST Client 機能を備えたインタラクティブな API 仕様ドキュメントを作成・共有する方法についてお伝えしたいと思います。

OpenAPI (Swagger) とは？

OpenAPI Specification (OAS) といい、REST API の仕様を記述するためのフォーマットです。また Swagger とは、Open API を使用するツールのことで、以下のようなものがあります。

• Swagger Editor
• Swagger UI
• Swagger Codegen

OpenAPI は、元々 Swagger Specification として知られています。REST API を定義するフォーマットの標準化を推進する団体 OpenAPI Initiative (OAI) が結成され、OAI の一員であり Swagger の開発元でもある SmartBear Software により Swagger Specification が寄贈（Donation）されたことで、Open API と言うようになりました。現場では Swagger の方が馴染みがあるので、OpenAPI と言うところはまだ少ないかもしれません。OAS 2.0 は Swagger Specification 2.0 に対応しており、現在（2019年7月）最新バージョンは 3.0 です。

OpenAPI を利用するメリット

OpenAPI を利用すると何が良いのか、いくつかピックアップしてみました。

API 定義のバージョン管理が楽になる

基本的に YAML または JSON で記述するため、Git 等を使用してソースコードと同様に管理することができます。つまり、Word, Excel で記述された仕様書に比べて更新履歴を管理していく努力が削減されます。API 定義ファイルと実装を一緒にコミットすることで仕様と実装が乖離しにくくなるため、より正確かつ最新の情報を共有することができます。

仕様が明確になる

OAS のフォーマットに合わせて宣言的に書いていくことで曖昧な記述がなくなります。またデータの仕様を明記するための各種データ型がサポートされているので、仕様が明確になります。Swagger UI を利用する場合、Markdown で記述された項目の表示もサポートされ、細かい仕様や注意点を分かりやすく表現することができます。

WebAPI の仕様管理を仕組み化することができる

Swagger UI から API 定義ファイルを読み込むことでインタラクティブな Web ドキュメントを作成することができます。別途 REST Client を使うことなく Swagger UI 上で動作確認ができてしまいます。また Swagger Codegen を使ってクライアントライブラリ（SDK）を自動生成することもできますので、WebAPI を叩くクライアント側の実装も楽になります。

Amazon API Gateway を利用する場合、API 定義ファイルをインポートすることで API をデプロイすることができます。逆にソースコードから API 定義ファイルを生成する仕組みもあるので、実に色んな使い方ができます。API 定義ファイルの操作を CI に組み込むことで、仕様書の更新・クライアントSDKの生成と配布・WebAPIのデプロイなどをまとめて自動化することが可能になります。

※ OAS 2 と 3 でフォーマットが異なりますので、サービスによってサポートされる OAS バージョンに注意する必要があります。

OpenAPI 導入イメージ（例）

構成の概要としては、

• API定義ファイルは GitHub で管理
• Swagger UI を SPA（シングルページアプリケーション）として静的サイトホスティング
• CircleCI に連携して API 定義ファイルをアップロード

といったところになります。

※ Swagger UI を自前でホスティングしないで SwaggerHub 等のサービスを利用する方法もありますが、この記事では割愛させていただきます。詳細はこちらをご参考ください。

Open API を利用して API 定義を作成する

YAML または JSON で API 定義を作成します。個人的には宣言的でコメントも書ける YAML の方がオススメです。作成にはどのようなエディタを使っても問題ないですが、編集時にリアルタイムで Swagger UI のプレビューを表示してくれる Swagger Editor が便利です。Validation までしてくれるのでとても助かります。フォーマットの仕様については、こちらをご参考ください。

※ OAS 2 と 3 でフォーマットが異なりますので、Web 等に掲載されているスニペットを参考にする場合は注意が必要です。

引き続き、作成した API 定義を Swagger UI で表示するため、メニューの「File」から「Save as YAML」を選択し、サンプルの API 定義を保存しておきます。

Swagger UI を使用して API 定義ファイルを読み込む

Swagger UI を API 仕様ドキュメントとして活用するためには、Swagger UI (SPA) と API 定義ファイルをホスティングする必要があります。例えば、以下のような構成にすることができます。

クエリパラメータに API 定義ファイルの URL を指定することで読み込まれます。

1

https://docs.sample-api.dev/swagger-ui/index.html?url={API定義ファイルのURL}

また、API 定義ファイルのパスに Git ブランチ名を指定して CI を回すことで、API 定義ファイルそのもののバージョン管理ができるだけでなく、レビュー中のブランチについても仕様の確認が容易にできるような仕組みづくりが可能になります。

Swagger UI を SPA としてホスティングする

Swagger UI の GitHub リポジトリにて、ソースコードをダウンロードして解凍、 dist というディレクトリをまるごと静的サイトホスティングすれば OK です。

このまま他の API 定義を読み込みたい場合は、下の赤枠に URL を入力して右側「Explore」ボタンを押します。各 API の項目を広げて「Try it out」、パラメータを入力して「Execute」することで、Swagger UI 上で API の動作確認ができます。別途 REST Client を使う必要がなく、とても便利です！

静的サイトホスティングについては色んな方法がありますが、AWS 環境であれば別の記事でやり方を紹介しておりますので是非ご参考ください。Swagger UI を用意して社内向けまたは開発パートナー向けにアクセス制限をかけて共有するなど、色んな利用シーンが考えられるのではないでしょうか。

まとめ

• OpenAPI をうまく利用することで、API 仕様の明確化・管理の効率化が図れる
• Swagger UI をインタラクティブな API 仕様ドキュメントとして活用する

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

OAS で API 定義を書いていくと、かえって記述量が増えて疲れるようになったといった意見もありますので、この記事の内容がすべての現場にフィットするとは限りません。ですが、ある程度規模が大きく、人の入れ替わりも多いような現場であれば、仕様ドキュメントの管理をしっかり行いたいということもあるのではないかと思います。今後も OAS と Swagger の使い方について具体的に紹介していきたいと思いますので、まだ使ったことないよー！という方がいましたら、是非試してみてください。

Author:lopburny