v-form (Vuetify) の submit イベントによってページがリロードされないようにする

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


リロードされる原因

この問題、実は 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 をブロックする項目が2つ以上ある場合:暗黙の submit は動作しない
  • 暗黙の submit をブロックする項目が1つある場合: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 特有のバグや癖だと思ってハマることもあるかと思い、記事にしてみました。
最後まで読んでいただきありがとうございました。

CloudNative Days Tokyo 2019 にて「サーバレス・ネイティブ が お伝えする、フルサーバレス開発の魅力」の発表をしました

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

“CloudNative Days” 概要

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

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

発表資料

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

サマリー

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

  • アイデアを即、形にできる 魅力
  • アプリの開発に専念できる 魅力
  • ピタゴラ装置を組み立てる 魅力
  • 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年7月現在、Lambda の起動が高速化され Java ランタイムのコールドスタートでも1秒ぐらいで起動しています。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 のセッションが多い構成の中、「サーバレス・ネイティブ」だの「フルサーバレス」というかなりイキり気味のセッションを採用いただけ、そして当日も空いているのが数えられるくらいの数席を、満席でのご参加いただきありがとうございます!

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

共有:

Vuetify 2.0 で追加された v-banner を使ってユーザーのアクションを促すボタン付きバナーを作る

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

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

コンポーネント優先度ユーザーアクション
Snackbar任意。Snackbar は自動で表示されなくなる。
Banner任意。Banner はユーザーによって非表示ボタンが押されるか、Banner を出す原因となった状態が解決されるまで表示される
Dialog必須。Dialog はユーザーが提示されたアクションを実行するか閉じるまでアプリの使用をブロックする。

※ 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 とメッセージの行数を指定、メッセージとボタンに加えてアイコンを表示することができます。下記、一般的に使われそうな用例を2つ紹介します。

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 がリリースされて間もないので、いきなり更新すると色々問題もあったりするみたいですが、そのうち改善されることを期待しています。これからのアップデートも楽しみですね!

OpenAPI (Swagger) を利用して効率よく WebAPI の仕様を管理する

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 定義ファイルをホスティングする必要があります。例えば、以下のような構成にすることができます。

項目内容
Swagger UIhttps://docs.sample-api.dev/swagger-ui/index.html
API 定義ファイルhttps://docs.sample-api.dev/api-definitions/{Gitブランチ名}/sample.yml

クエリパラメータに 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 の使い方について具体的に紹介していきたいと思いますので、まだ使ったことないよー!という方がいましたら、是非試してみてください。

勤怠を自動化する技術 LT Nightで、Web-NFC の PWA について LT しました

2019年7月19日に開催された「勤怠を自動化する技術 - LT Night」で LT & 新作アプリのデモをしました。発表のサマリーです。

イベントの説明にあります通り、すべてはココから始まりました。

見かけた際に即 Like し、RT。開催されるだろうかと、ワクワクしてました。勤怠時間の管理については言いたいこともあれば、やってみたいこともある!そう思いながら日々過ごしてたら、ほんとに開催されました「勤怠を自動化する技術」LT Night - connpass

即刻、参加に申し込むも絶望的な順位(皆さん、早!)。どうしても参加したかったので、空いていた LT 枠に切り替えました。もともと勤怠の時間管理のためにアプリを作るつもりでしが、LT 枠のために前倒し。かなり無茶なスケジュールでの参戦となりましたが、結果として発表できてよかったです。素晴らしい機会に感謝です。ありがとうございます!

発表資料

『Web-NFC の PWA で 簡単タイムレコーダー「ツカエタルヒの記録」』の発表資料はこちらになります。

サマリー

以下の内容で構成しました。

  • 私の現在の勤怠管理
  • 「ツカエタルヒの記録」紹介

私の現在の勤怠管理

簡単に言ってしまうと、毎日 Excel に手入力して、翌月初に上司のサインをもらうという仕組みです。ただし途中で「印刷、サイン、PDF化」が繰り返されるのでかなり大変。もちろん、人手によっているのでトラブルが多発します。

これは、話しててヤバいなと思いつつ、参加者さんからもヤバい旨のツイートがありました💦

「ツカエタルヒの記録」紹介

流石に Excel 管理の仕組み自体は変えられないので、毎日の手入力を支援するツールを自作しました。(本 LT に向けて、3日間の夜なべ仕事だったので、公開に向けてはリファクタリングしないとなので、公開は今しばらくお待ちください。)

Web NFC APIを使った PWA です。PWA なので、ブラウザで動作し、またアプリとしてインストールすることもできます。

市販の NFC Tag へアプリで使うデータを書き込むことで、スマホをかざした際に出退勤の時刻を記録します。(Suica などの FeliCa 系は読み書きできません)

せっかくなので「ログインボーナス」「月曜日ボーナス」機能も導入しました。今回のデモ用にはるるてあ (@k_r_r_l_l_)さんの「肯定ペンギン」を使わせていただきました。(アプリ公開に当たっては何か別のにしないとですかね。”イラストのアイコン・ヘッダー使用はご自由にどうぞ。画像の商用利用はお控えください。 -るるてあ (@k_r_r_l_l_) / Twitter“ なので大丈夫な気もしますが使わせていただくとなると確認はしないと)

Web NFC は 2019年7月現在、Android の Chrome のみ対応しており iPhone では利用できません。その場合は画面右上の [⏰] アイコンから記録できます(それ以前にアプリを使っていただくことはなさそうですが)

今後としては、まずはリファクタリングして公開を急ぎます。また現在はブラウザのローカルストレージにしかデータを保存していないので、Google スプレッドシートへ保管するようにしたいです。これがないと Excel へ転記するのが大変。また、今回のイベントの会場&懇親会の提供をしてくださった Freee さんの人事労務API 概要 | freee Developers Communityなどにも対応してみたいです。

なお「ツカエタルヒ」は上日(ジョウジツ)とは - コトバンクの “日本古代の律令官人の出勤日数。〈つかえたるひ〉ともよむ。” から付けました。なんと出勤日数の管理および評価は平安時代から変わってなさそうな感じ。(しかも夜の会議と称した酒盛りとか、日勤15の夜勤5で20時間労働のブラック -平安貴族のお仕事、実はかなりブラックな労働環境だった? - ZAK女 - ZAKZAKとか、1000年以上も同じことを!?ヤバい)

所感

ログインボーナスについて

ログインボーナスについては、ぜひ拡張を続けて何かおもしろいことができたらと思います。

スポンサーセッションの勤怠打刻の基礎知識で勉強させて頂いた通り、勤怠管理の仕組み自体を作るのは法律の知識をはじめ、さまざまな勤務形態に対応する必要があります。その部分はやはり専門の SaaS にお任せするのがよいでしょう。

一方でクライアント部分は、もっと自由な発想があってもよいと思います。むしろ、そこが足りてないから入力するのを嫌がられたりするわけです。その嫌われに対処するには、大きく2つあると思っています。

1つは完全に透過してしまい意識させないこと。これは入館ゲート(駅の改札みたいなやつ)を使ったり、GPS や WiFi 使ったりと、まさに自動化する仕組みです。もっとも、今回の会場の Freee さんみたいにオフィスに卓球台があったり、バーのある会社さんもあったりと最近は「会社にいる=仕事している」とは限らない状況もあるので難しいところです。

もう1つは、楽しくすること。使いたくすること。そのためにログインボーナスを作ってみました。効果があるか、まだ何とも言えないですが。また画像が出るだけでは楽しくないので、もっと何か良い仕組みを考えたいと思います。ここはクライアント部分だけで作れるので、アイデアの出しどころですし、作りがいのあるところだと思います。

ハッカソン、ワークショップについて

今回さまざまな発表を聞かせていただく中で、皆さん色々なものを作っているなぁと思いました。

せっかく今回のように色々なものを作る人が集まるのだったらハッカソンとかにしてもおもしろいだろうなぁと。

次回移行も Freee さんが開催してくださるかはわかりませんが、せっかく API を公開されているので、ワークショップにしたり、API 利用を前提としてのハッカソンなどがあると盛り上がりそうです。


いろいろなイベントで発表させていただいてきたのですが、LT は初めてで時間の制約を気にして緊張しました。限られた時間の中で精一杯話すのはとても楽しく、また次の機会に LT できたらと思います。

「勤怠を自動化する技術」ならぬ「勤怠を楽しくする技術」については、あと2つほどネタがあるので、ぜひ第2回、3回と会が連なり、そしてハッカソンなりと盛り上がると嬉しいです。

Git で管理しているファイルの変更追跡を一時的に無視したい

Git を使って開発しているプロジェクトで、トラブル対応や機能のテストのために一時的に変更を加えた状態で作業をしたい、ただし一時的な変更なのでコミットしたくないといったことがあります。このような場合に skip-worktree を使うと、変更の追跡を一時的に無視できます。

特定のオプションを有効にしている場合に発生する問題への対応のために設定ファイルを変更している、しかしオプションはコミットしない。そうそうあることでもないですが、このようなパターンで一部変更しながらもコミットしたくないというケースがあります。そして慎重に作業を進めつつも、うっかりコミットして面倒なことに。。。

最初からコミットするつもりがない変更については明示的に外してしまうのも手です。

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

  • Windows 10 64bit + WSL Ubuntu 18.04.1 LTS
  • Git 2.17.1 (WSL Ubuntu 18.04.1 LTS)

参考情報

git update-index –skip-worktree で無視

指定するパスを Git の変更追跡から無視する設定がgit update-index --skip-worktree <path>です。

このオプションを指定すると変更追跡から無視されるので、ファイルを更新しても Git の変更に乗りません。たとえば変更したファイルconfig.jsonがあったとします。Git で状態を見ると以下のようになります。

1
2
3
4
5
6
7
8
9
10
11
$ git status
ブランチ master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

modified: config.json

no changes added to commit (use "git add" and/or "git commit -a")

そこで変更追跡から無視して再度確認してみます。変更対象に入っていないことがわかります。

1
2
3
4
5
6
$ git update-index --skip-worktree config.json
$ git status
ブランチ master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

またskip-worktree設定しているファイルは以下のコマンドから確認できます。

1
2
$ git ls-files -v | grep ^S
S config.json

これにより誤りコミットを避けることができます。

変更管理対象に戻す

戻すためのオプションは--no-skip-worktreeです。最初にnoが入っています。

1
2
3
4
5
6
7
8
9
10
11
12
$ git update-index --no-skip-worktree config.json
$ git status
ブランチ master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

modified: config.json

no changes added to commit (use "git add" and/or "git commit -a")

リモートで更新された場合

変更追跡から無視している状態で、そのファイルがリモートで更新されたらどうなるでしょうか。

もし、まだ変更していない場合(無視する設定だけした)は、リモートの更新をマージできます。これは通常の Git 管理と変わらず特別なことは何もありません。

変更してた場合、残念ながらマージできません。いったん--no-skip-worktreeして、変更を stash するか、何らかの対応をします。


ちょっと変更をキープしながら、作業をしなければならない時などに便利です。

ただしリモートで変更されてしまうと結構手間なので、長期にわたって使うものではないかもしれません。なにしろローカルの変更があるのでマージできないというエラーが出るのにgit statusnothing to commit, working tree cleanって、無視設定したことを忘れてると混乱しますから。

AWS WAF を使用して IP ホワイトリストによるアクセス制限を行う方法

前回の記事では AWS 上に静的サイトをホスティングする構成について紹介しました。この記事では、CloudFront のディストリビューションに AWS WAF で作成した Web ACL を関連付け、IP ホワイトリストによるアクセス制限を行う方法についてお伝えしたいと思います。

例えば以下のようなコンテンツで、サイトを外部に公開したくない場合において有効です。

  • WebAPIの仕様、開発ドキュメント ※ Swagger UI など
  • 社内向けサイト
  • 開発中のウェブアプリ

この記事で紹介する構成



  • CloudFront のディストリビューションに AWS WAF を使用してアクセス制限をかけます。
  • クライアントによる S3 バケットへの直アクセスはできません。
  • AWS WAF は Origin の種類に関係なく関連付けることができます。

設定の手順

以下の一連の作業を行う必要があります。
まず、AWS WAF のコンソールを開き、「Go to AWS WAF」 を選択します。

Create web ACL を選択すると以下の画面が表示されます。

  • Web ACL name を入力します。
  • Region については、「Global(CloudFront)」を指定します。

※ AWS resources to associate で関連付ける AWS リソースを指定することができます。ここですでに作成済みの CloudFront ディストリビューションを指定しても OK ですが、この記事では別途 CloudFront のコンソールから指定することにします。

「Next」をクリックして次の設定に移ります。

ここでは「IP match conditions」を選択します。

ここで許可したい IP アドレスを登録します。名前・IP Version・Address を入力して、「Add IP address or range」をクリックします。複数のIPアドレスを登録することもできますので、許可したい IP アドレスがたくさんある場合はどんどん入れていきましょう。

登録が終わったら、画面下の「Next」をクリックします。

ルールの名前、Rule type、条件(Condition)を指定します。

先程作成した IP アドレスのリストが反映されていることを確認し、「Create」をクリックします。

作成したルールの Action は「Allow」を選択、Default action は「Block all requests that don’t match any rules」を選択します。これでこのルールにマッチしなかった IP アドレスはブロックする挙動になります。

準備ができたら「Review and create」をクリック、問題なければ「Confirm and create」します!

先程 AWS resources to associate を設定しておいた場合、このまましばらくすると反映されるようになります。AWS WAF のコンソールではなく CloudFront のコンソールで設定する場合は、ディストリビューションの設定にて「General」タブを選択、以下の場所から設定することができます。

修正してしばらくすると適用されます。WAFによってアクセスがブロックされた場合、以下のようなエラー画面が表示されます。

Web ACL のコンソールを見ると、どのようなリクエストがあったか確認することができます。便利ですね!

アクセスログを取得したい場合は Web ACL のコンソールから Logging タブを選択して有効化することもできますが、この記事では割愛させていただきます。

AWS WAF で作成する項目として 許可する IP アドレスのリスト・ルール・Web ACL の3点を押さえておくと分かりやすいと思います。Web ACL を削除する時、この順番で消していかないとエラーになりますのでご参考ください。

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

AWS WAF は、ALB(アプリケーションロードバランサー)と API Gateway にも関連付けることができます。ただし、その場合は Web ACL のリージョンを指定する必要があります。

IP アドレス制限のみならず、色んなルールを設定することができますので、是非試してみてください。

Go_SaaS 三種の神器オンボーディングセミナー 1 〜東京〜 参加レポート

2019年7月8日に開催された「#Go_SaaS 三種の神器 オンボーディングセミナー#1(東京)」に参加したのでレポートします。

今回参加したのは、日本における SaaS ビジネス、サブスクリプションビジネスを推進し ISV や Startup の支援を目的とした「Go_SaaS 三種の神器」というセミナーです。

このセミナーは ID 管理サービスの Auth0、決済サービスの Stripe、CI/CD サービスの CircleCI を、SaaS/サブスクリプション型のビジネス開発における三種の神器として、サービスの概要紹介とユーザー事例を紹介する半日のセミナーです。また SaaS 型サービス構築の考え方についてから始まるので、まさにサービス開発、新ビジネス開発に向けてパッケージングされたセミナーといえます。

主な内容

  • AWS ジャパンから見た SaaS 化における課題、及び、今後の展望 (岡崎 貴紀氏 - AWSジャパン ISV/SaaS パートナー部 部長)

  • 「Go_SaaS 三種の神器」が目指す新たな日本のSaaS促進支援の形 (小島 英揮氏 - Still Day One 合同会社 代表社員)

  • SaaS 三種の神器 - ID管理・CI/CD・決済

    • 藤田 純氏 - Auth0 株式会社 カントリーマネージャー
    • 森本 健介氏 - CircleCI カントリーマネージャー
    • ダニエル ヘフェルナン氏 - Stripe Japan 代表取締役
  • ユーザー事例紹介 - 三種の神器を活用したストレスフリーSaaS運用環境

    • Shifter 開発の舞台裏 (小賀 浩通氏 - Digital Cube 代表取締役社長)
    • SaaS化にあたり直面した課題 (Jeremy Hall, PhD氏 - AppSocially株式会社 VP of Engineering)

AWS ジャパンから見た Saa S化における課題、及び、今後の展望

まずは AWS の ISV/SaaS パートナー部長の岡崎さんから、ソフトウェア開発および SaaS の現状について。

国内の SaaS 市場の成長率は 15%、それに対してソフトウェア市場は 4.6%。また SaaS の利益率は 76% と、市場の拡大および利益への貢献度が高まっているとのこと。つまり SaaS 開発は収益性を向上させることができる。とはいえ最小限に稼働するレベルの SaaS を作るにしても3ヶ月~2年の開発期間が必要となる。よって既存の SaaS と組み合わせて構築していくことが必要となってくる。

AWS では、その SaaS 開発を支援するプログラムも用意しているので活用してほしいとのこと。

SaaS化が求められる市場の潮流と本取り組みへの期待

ソフトウェアを提供するには SaaS にするのが良いよというお話でした。現在はそういった流れなので新規で作るなら当然 SaaS 型になっていくだろうなというのは感じますし、AWS でそのための支援プログラムがあるというのがよいです。

「Go_SaaS 三種の神器」が目指す新たな日本の SaaS 促進支援の形

続いて Still Day One の小島さんより。小島さんは富士通から Adobe、AWS を経て現在は6社のサービスでアドバイザーをされているとのこと。まさに SaaS ビジネスのプロで、今回 SaaS をよく知っているほか、AWS と三種の神器(Auth0, CircleCI, Stripe) をつなぐことができる人物ということで本プログラムの進行を担当されているとのこと。

改めて SaaS/サブスクリプションビジネスの凄さについて説明。2019年時点で SaaS/サブスクリプションビジネスは3兆円規模で、年率40%以上で成長している。非常に魅力的なビジネスであるが、既存のパッケージ販売から転換するには大きな壁がある。たとえばファイナンスの壁では Adobe が SaaS 転換した際に、売り上げが落ちることを周到に説明する必要があったことなどがわかりやすい。実際に SaaS 転換後、大きく売り上げが落ち込んだ。現在は素晴らしい業績になっている。
組織文化としても大きく変わる。カスタマーサポートについては極端な例になるが売り切り製品の場合は小さくしたい、やめてしまいたい。販売後はコストになってしまうから。一方で SaaS は使い続けてもらう、解約されないようにするためフィードバックループを回す。顧客のビジネスにメリットをもたらす必要があるのでカスタマーサクセスが重要になってくる。営業よりもカスタマーサクセスの方が売り上げを叩きだすケース多い。
開発も大きく変わってくる。フィードバックループを回すために DevOps の体制が必要になってくるし、クラウドの活用が重要になってくる。SaaS の上に SaaS を作るようなイメージ、既存 SaaS と連携して開発する。

そうした壁もあるが、ビジネスとして美味しく魅力的である。サブスクリプションは売り切りでない。10件売って、次に10件売れば、20件の利益。売り切りは、10件は10件。
では、どのように転換していくかというと、まずは BYOL、ライセンス型のソフトウェアを EC2(AMI) に組み込んでライセンスだけをサブスクリプションとして売る。このサブスクリプションも月額固定でよいし、請求書ベースでも構わない。次にシングルテナントの SaaS にする。徐々に DevOps に向けて体制を変えデプロイを自動化できるようにしていく。ライセンスもライセンスコードの発行から利用ユーザーの ID ベースに移していく。そうなると課金モデルも変わってくる。月の途中で利用者数が変わってくる。
これらを新規で作ると大変であり、また問題を発生させかねない。ムリに作ろうとするとセキュリティ・インシデントとなる。ここは既存のサービスを使っていく。

構築したサービス利用の顧客決済についてはクレジットカードの導入は必須。B2B では請求書でないとダメや「できない」といわれることもあるが現実はできる。そうでなければ AWS がこれだけ使われるわけがない。
クレジットカード決済にすることでキャッシュフローが改善される。SaaS の利用料を月末で〆るとして、翌週には入金される。一方で AWS の利用料も月末で〆られるが引き落としは翌月。入金されてから出金の形なる。これが請求書だと逆になる。AWS の利用料が引き落とされ、それから請求書の支払いが1ヶ月、2ヶ月遅れで入金されてくる。売り上げが上がっているようで、キャッシュフローは赤字になっている。

「Go_SaaS 三種の神器」が目指す新たな日本の SaaS 促進支援の形

自社製品を SaaS 化するにあたってという観点から、とても勉強になりました。とくに売り上げが積み重ねとなるという考え方は、言われてみればその通りですが見落としてました。もちろん解約というリスクがありますが、前月の売り上げが次月にスライドして、次月の売り上げが重なるのは素晴らしいビジネスです。またキャッシュフローの改善は盲点でした。

ユーザー事例紹介: Shifter 開発の舞台裏

以前、JAMStack について発表させていただいた Shifter さん、偶然にも SaaS のユーザー事例として小賀さんが Shifter の開発についてお話されてました。

小島さんの既存パッケージソフトウェアを SaaS 化する話が、まさに Shifter がたどってきた道でした。
Shifter の元になる AMIMOTO という WordPress のパッケージがあり、当初は EC2(AMI) として提供していた。それをシングルテナントの SaaS として影響を開始。最終的にマルチテナントの SaaS、Shifter へと。商品から体験へ、ユーザーの価値観が変わってきている。

アーキテクチャはサーバーレスで作られていて、CircleCI と Stripe を使っている。ID 管理は Cognito を使っているが、ここは Auth0 に切り替えるとよいのかもしれない。検討していく。

CI/CD について、Jenkins が良いのではという話はよく聞く。カスタマイズなどができてよいのかもしれないが、いわゆる「Jenkins おじさん問題」がある。Jenkins を保守運用して管理する人が必要となってしまう。CircleCI を使うことで本業に集中できる。

また Stripe については、決済の仕組みを自前で開発したら恐ろしいことになるだろう。PCI DSS などの認証をとるのはとても大変。多通貨、多国籍、柔軟な定期決済と対応するものも多く、不正使用、不正請求などへの対処も必要となってくる。ここはサービスを利用することが重要。また小島さんが話していた通り、キャッシュフローの改善も重要。

その他、モニタリング、UI開発、サポートデスク、CRM とさまざまな SaaS を使っている。

Shifter 開発の舞台裏 三種の神器編

SaaS 開発の歴史をお話してくださり、開発のリアルをすごく感じました。「SaaS 提供者こそ SaaS を使い倒そう!」というメッセージがカッコよかったです!

AppSocially スタートアップの武器となるSaaS

発表が英語だったためレポートを書けず。。。すみません。

SaaS 三種の神器 - ID管理・CI/CD・決済

三種の神器の各サービス紹介の資料です。

Auth0がB2B SaaS企業に必要な理由

SaaSビジネスに必須のCI/CD by CircleCI

Stripe SaaSを支える決済機能のコツ


SaaS/サブスクリプション型のビジネスを始めるにあたって、最初に必要な知識や考え方をいっぺんに勉強できる素晴らしいセミナーでした。とくにユーザー事例として実際に SaaS を構築されている方々のお話もあり、そして SaaS を構築する上でも SaaS を組み合わせていくとよいというのが響きました。

スタートダッシュや知識のベースアップとして、こちらのセミナーを受け、そのうえで深堀したいサービスのセミナーやミートアップなどのイベントにつなげていくとよいのではないでしょうか。

「プレゼンドリル 伝えかた・話しかた」、勉強会、LT、イベント登壇のおともにしたいドリル

プレゼンテーション(プレゼン)というと大勢の人前で話をするイメージがありますが、プレゼンの本質は「人にわかりやすく伝えること」。そこには人の多さは関係ありません。人に何かを伝えアクションにつなげてもらう、そんなプレゼンの原点をシンプルに思い起こさせてくれる、そしてプレゼンの機会があるたびに毎回ふりかえりたくなる、そんなドリルを紹介します。

紹介する書籍はこちら、「プレゼンドリル 伝えかた・話しかた」

著者は日本マイクロソフトのエバンジェリスト、西脇 資哲(@waki) さん
マイクロソフトのイベントなどでプレゼン&デモをされているのをはじめ、多数のイベントで登壇されている IT 界のスーパーエバンジェリストのひとりです。

西脇さんは、多くのプレゼンやエバンジェリストに関する書籍を出していますが、今回は小学生向けに出版されました。もともと SSH(スーパーサイエンススクール) という取り組みをされており、筑波大学附属駒場中高や立命館小学校でプレゼンの授業をし、その中から本書ができたとのことです。

今回こちらの書籍を取り上げたのはプレゼン力を高めるためですが「小学生向け」というのが気に入り選びました。プレゼン(に限らないですが)は、話す内容をわかりやすく、極端に言えば小学生に伝わるように話せるとよいとも言われます。そのような中でスーパーエバンジェリストのひとり、西脇さんが本書を出されたということで即買いしました。

IT に携わる方が小学生に向けて作られたプレゼンのドリル。ページ構成こそ確かに小学生向けですが、その内容は大人にも満足できる書籍でした。勉強会での発表や、LT、イベント登壇とプレゼンに向けて、またはプレゼンの機会とまでいかなくとも日々の活動で説明を充実させるために、敢えて小学生向けのドリルでプレゼン力の強化を図るのもいかがでしょうか。

主な内容(目次より抜粋)

  • はじめに―プレゼンテーションとは「伝える」こと!
  • ドリルの使いかた
  • ドリルの注意点
  • 第1章 「伝える」方法を学ぼう
  • 第2章 シナリオを作る
  • 第3章 スライドを説明するトレーニング
  • 第4章 かっこよく話す基本テクニックと裏技
  • 第5章 実践!プレゼンテーションの手引き
  • 模範解答集
  • 保護者のみなさんへ

アイデアを「誰に」「何を」「どうやって」で整理し、自分の意見や考えを加えて広げよう

まずは、泣いている赤ちゃんや、天気予報などの絵をもとに「誰に」「何を」「どうやって」で説明できるように整理するトレーニングから始まります。プレゼンをはじめ、説明をするときに文章だけで考えていると、いつの間にか話が複雑になり最終的にわかりにくい話になってしまうことがあります。このトレーニングは何を話をしたいのか改めて整理するのによいです。

そこから伝えたいことを広げ、事実の説明だけでなく自分の意見や考えを入れるトレーニングに発展します。技術について話をする際に、意外とありがちなのが技術に関する事実や調査の結果にフォーカスしてしまい、最終的な考えや意見が入らなくなってしまうこと。もちろん客観的な事実がないと困りますが、調べればわかることだけで構成されていると少し物足りなくもあります。やはり、その技術に対する主張も聞きたいものです。

たとえば、こちらの写真を見て「お寿司です」以上、はさすがにないと思いますが、どういった説明に意見を加えますか?(実際にドリルにも寿司の問題は入っています)

子供向けとして使うのでしたら説明の仕方の基礎としてしっかりしていますし、プレゼンや登壇の準備として読み直してみるならアイデアの整理と拡大として活用できるのではないでしょうか。とくに2章は1回やったとしても、また新たな考えや意見が浮かぶでしょうし、敢えて違う意見を考えたり、アンチ側としてロールを変えてみるなど色々と使えます。

話のカッコよさ、それは修飾

名詞をただ置くだけではなく修飾をする。ちょっと付けるだけでイメージがだいぶ変わります。しかしながらボキャブラリが必要ですし、イメージを膨らまさないと文章を修飾するのも簡単ではありません。

それをトレーニングする「第4章 かっこよく話す基本テクニックと裏技」は、このドリルの中でとても好きな章です。「ライオン」や「子猫」などの絵から始まり、色のイメージ、比喩、事実に対する意見付け、スライドのつなぎ(ブリッジ)と、話をカッコよくする手法について次々とトレーニングします。ひとりでやるのもいいですが、みんなで意見交換しながらボキャブラリやアイデアを増やすのもよいでしょう。

またスライドのつなぎ(ブリッジ)についても、しっかりと学べる点がよいです。ここはついつい「えっと」や「それで」とかでつないでしまいがちなところを、きちんと考える練習となります。練習なきところに本番の成功はないので、キッチリと練習して身につけたいところです。

模範解答集を見て、思考をもっと柔らかく

「P.69 問題 39 - かっこいいかざりを考えてみよう」では子猫の絵をもとに、かっこいいかざり言葉を考えます。以下は問題をイメージするための写真で問題集の絵とは異なりますが、かっこいいかざり言葉いかがでしょうか?

こちらの模範解答は以下となっています。

ぬいぐるみのような
かわいい
モフモフした
思わず抱きしめたくなる
[問題 39 の解答例 - P.119 より抜粋]

いかがでしょうか。「かわいい」などは浮かびますが、ぬいぐるみや抱きしめたくなるなど、すぐには出てこないかもしれません。「モフモフ」はネットなどで使っているので浮かぶかもしれませんが、プレゼンを作るという思考回路の中で、このような柔軟な発想は出てきますでしょうか。

模範解答集をうまく活用することで、柔軟な思考を広げることにもなるでしょう。大人が読むからこそ、むしろ模範回答集が重要な章ともいえるのではないでしょうか。

まとめ

とても分かりやすく、それでいて実践的な書籍だと思います。

アイデアを広げるための1ページをドーンと使った演習をパラパラっと眺めながら、いろいろな想像の羽を広げることができます。IT 関連のプレゼン作りとなると、どうしても技術やロジックなど論理的になりがちです。そういった中で、ドリルに目を通すことで思考を柔らかくし表現力を高めることができるのではないでしょうか。

プレゼンのテクニックであったり、資料作りのための技術も大事ですが「人にわかりやすく伝えること」にフォーカスを戻すことも重要です。より多くの人に理解してもらう、そしてアクションにつなげてもらう、そんなプレゼンの原点に、いつでも立ち返ることができる素晴らしいドリルです。


前回の「ドリルの王様 1,2年のたのしいプログラミング」、自然とプログラミング的思考が身につく問題集に続き、またも小学生向けのドリルの紹介でした。

子供向けであることから逆にシンプルでわかりやすいというのがあるのではないでしょうか。(とはいえ、ひらがなの多さや文字の大きさには閉口するところもありますが)

このようなプレゼンの授業があるというのは、素晴らしいし、何よりうらやましいですね。プログラミングも見様見真似の写経で覚え、プレゼンはイベント登壇者さんを凝視し技を盗む。ちゃんと教えてもらうことができたら、もっと幅が広がったのかな。それとも逆にやらなくなったのか。いろいろと思うところはありますが、なによりも日々勉強にアウトプット。アウトプットを続け、改良していくことですね。

共有:

OSS-Friday 活動 - 2019年6月まとめ

普段お世話になっている OSS プロダクト、日常で OSS 活動をしていないと貢献する機会をつい逃しがち。なので毎週金曜日は少しでも OSS 活動へ意識を向ける習慣 OSS-Friday として位置付けるようにしています。2019年6月の OSS 活動についてサマリーします。

OSS-Friday 参考情報

サマリー

OSS-Friday のページで GitHub のアカウント連携すると自分のページが作られます。

このページの中に GitHub での「過去3ヶ月間&過去1,000イベント」から金曜日の活動をサマリーしたものがあります。以下、そちらから抜粋。

June 07, 2019

June 14, 2019

June 21, 2019

June 28, 2019

2019年6月の OSS-Friday 活動は12件でした!
以降、プルリクエストを出した背景など。

hexojs/hexo-theme-landscape #136, #137, #138

最初の2つ #136, #137 は、ブログメンターのカック@ブロガー / k9u (@kakakakakku)さんにメンタリングをしていただいている中から「Google+ は終了したのにテンプレートに残っているよね」との指摘からプルリクを出したものになります。

記事のシェアに Google+ があったほか、OGP にも Google+ がありました。Google+ という観点では1つですが、コードでは異なる範囲になるのでプルリクは2つに分けて出しました。

3つ目の #138 は、Customizable Banner Image · Issue #106 · hexojs/hexo-theme-landscapeを解決するためのプルリクです。デフォルトのブログトップ画像が CSS にハードコードされており、実際に自分のサイトを開くにあったり CSS を編集してパスを変えるか、画像を上書きする必要がありました。それを設定ファイルからパスを指定できるようにしました。

zefman/gridsome-source-instagram #1

こちらは、2019年6月1日の「初夏のJavaScript祭 in メンバーズキャリア」でGridsomeのデモアプリを作る際に、Instagram の写真を取得する Pluginzefman/gridsome-source-instagramを使わせてもらいました。設定する際に typo を見つけたので修正のプルリクを出したものになります。

関連コンテンツ

Readify/httpstatus #63, #64, #65, #66, #67

HTTP Status を返してくれるサービス httpstat.us を紹介する記事を書いた際に、いくつかの JSON レスポンスが期待値と異なったので修正するプルリクを出しました。

C# でできているとのことで、自分のスキルセットにないので若干ひるんだところもありましたが、コードがシンプルでわかりやすく作られていたのでプルリクを出すことができました。

合わせて、いくつかの HTTP Status に対応するプルリクも出しました。

関連コンテンツ

hexo-browsersync #34

これは切実に困っている問題に対するワークアラウンドになります。残念ながら根本解決することはできていないのですが、このプルリクによって暫定対処はできます。暫定対処のプルリクのためかマージいただけておらず、入ってくれると助かるのだけど。。。

この Plugin の機能は、Hexo でブログ記事の下書きをする際に、ブラウザを自動リロードしてくれるものです。しかしながら、コンテンツが長い場合にリロードできないという問題があります。トップページで5記事+サイドバーありは、ほぼエラーとなりリロードできず。単記事のページで文章が短いうちはリロードできるといったレベルです。おそらく、こちらProblem with long pages · Issue #15 · hexojs/hexo-browsersyncとも関連してると思われます。

問題の原因ですが、この Plugin は</body>タグの後にリロード用のスニペットを注入するのですが、コンテンツが長いと</body>へたどり着く前に切れてしまい、スニペットが注入できないことです。

解決に当たっては色々と試さないと分からないことが多いので、まずは</body>以外にスニペットを注入できるようにするオプションを導入し<body>と、開始タグへも注入させられるようにしました。これによりコンテンツが長くて切れてしまっても注入箇所は残るので Plugin は動作できるというものです。

Plugin が使っているBrowsersyncも、タグを変更できるオプションsnippetOptions - Browsersync optionsが用意されているので、そのような形として、こちらの Plugin にもあってもいいのかなと思います。

hexojs/hexo-generator-tag #22, hexojs/hexo-generator-category #23

それぞれ Issues へ上がっていたものに対応するプルリクです。

ブログのタグとカテゴリーの一覧表示のページでorder_byオプションを設定したいというものです。正直あまり用途が浮かばず、対応する必要があるのかなとは思ったのですが “like hexo-generator-archive and hexo-generator-index” とコメントされており、確かにアーカイブの一覧などではorder_byの設定ができます。デフォルトで導入されている Plugin 間で対応の差があるのもいかがと思いプルリクを作りました。


6月は Readify/httpstatus の新しい HTTP Status 対応があったので多くのプルリクが出せましたが、実際には1件出すのが精いっぱい、週によってはプルリクを出すことさえ難しいかなというのが正直な感想です。

それでも Issues を眺めたり、コメントを返したりと、まずは日頃お世話になっている OSS へ意識を向けることができればよいのではないでしょうか。

🚲 Let’s enjoyOSS-Friday!!

共有: