ブログメンタリングを受けて学んだことと振り返り

この度、カックさん(@kakakakakku)のブログメンタリングを受け、3ヶ月間メンティーとして活動させていただき、卒業しました。この記事ではメンタリングの振り返りと学びについて共有したいと思います。

ブログメンタリングについて知りたい方は、是非こちらの記事を一度読んでください。

また、私がカックさんを知るきっかけになった「Trello があるので眠れない」の Podcast も合わせて聞いてみてください。私は、ある日徹夜作業で疲れ果てていた時に、この Podcast を聞いて元気づけられ、またブログメンタリングに申し込む決心をするようになりました。

なぜブログメンタリングを受けようと思ったか

私は仕事でのコミュニケーションにおいて何かを主張したり説明することが得意ではありませんでした。しかしあることをきっかけに「人に何かを伝える、教える」ことに興味を持つようになり、そこで、先ずは自分が持っている知識を人にできるだけ分かりやすく伝える姿勢とスキルを持つべきと考え、ブログメンタリングに応募しました。

ブログメンタリングで学んだこと

技術ブログを書く・運用していく上で役に立つ知識とノウハウは、#ブログメンタリングという Twitter ハッシュタグでカックさんが投稿してくれるので、検索して知ることができます。一方、実際にメンタリングを受けてみると、さらに一歩踏み込んだ経験と気づきがあったので、個人的に学びが多かった点について共有してみたいと思います。

自分をマネージメントする

メンタリング中はブログの更新本数のノルマが課せられますが、それに加えて公開する時期(平日/週末)や記事のジャンル(小ネタ/書評など)についても目標を設定してチャレンジすることになります。

ここで一つ感じたのは、例えば「平日の方が多く読まれるので、週の早めにブログを更新すると良い」ということを知りながらも、そのように実践して結果を残すためには自分をマネージメントする必要があることです。時間の使い方をきちんと工夫した上で、計画を立ててコツコツ行動していくことが重要です。

すると、更新本数のノルマをクリアするために、週の初め or 終わりに自分の予定をオーガナイズする作業が欠かせません。「ブログ」を生活の中心に置くことで、仕事もプライベートもより計画的になります👍

ブロガー同士の繋がりも重要

個人的には多く反省点が残る点ですが、メンティー同士または同じブロガー同士で記事を共有したり感想を書いて伝えることも重要です。キーワード検索による流入はあれど、SNS で拡散したりブックマークされたりと、ブログへのタッチポイントは他にも多くあります。他の人に共有してもらったりコメントをもらうことで、記事を書くモチベーションも上がります。つまり、人にしてほしいことはまず自分からしてみることです🙌

すでに知っている知識でも記事にしてアウトプットすること

ブログを更新するために、毎回新しい技術や知識をインプットすることは大変です。もちろん必要なことではありますが、余裕を持ってブログを書いていけるようになるまでは、新しいことやネタのユニークさにこだわるよりも、すでに知っている知識を継続的にまとめていく方が良いかもしれません。

一度記事にしておくと、以降、その内容についてとっさに誰かに聞かれても、すぐに回答が出てくるようになります。また自分の記事を引用して説明できるのも面白いですね。理解が曖昧だったところを勉強し直せるチャンスでもあります💪

成果

メンタリング期間中にリモートワークをすることになり、ほぼ活字のみで仕事のコミュニケーションを取るようになりましたが、週1でブログを書いていたおかげで、技術的なコンテキストでもさほどストレスなく書けている自分に驚いています。まだまだなので、上手く書けているかどうかは別ですが、文章を書くことへの抵抗や不安はかなり軽減されたことを実感しています。

メンタリング期間中に書いた記事の数


  • 13週間のメンタリング期間中、14 記事を更新
  • 基本的に週1のノルマを継続、1度だけ週2のノルマにチャンレンジ

週間PV数の推移

※ lopburny が書いた記事のページのみ集計

なんと、メンタリングは終了しましたが 14 週目となる現在、週間 PV が 600 件を超えました。メンタリング3ヶ月目の目標の一つに週間 PV 500 というのもあったので、ちょっと悔しいですね😂

所感

当初、最長3ヶ月までメンタリングを受けられると聞いて、ならば2ヶ月で卒業するつもりでがんばろうと意気揚々としていましたが、やっぱりフルで3ヶ月受けることに^^;

というのも、メンタリング期間中はとても学びが多く、ブログを中心として生きていた、とても濃い日々でした。だんだん可能な限り続けて成果を出したいという気持ちに変わっていき、延長をお願いすることに。これからもメンタリングでの学びをちゃんと活かしていけるように、続けて活動していきます。

今後もメンタリングで教えていただいた課題に取り組みながら、楽しくアウトプットしていきたいと思います!!

Web API のモックサーバーとしても活躍、jsonbox.io

jsonbox.io という HTTP ベースで JSON ストレージを扱えるフリーのサービスがあります。
公式ではスモールプロジェクトや、プロトタイピング、ハッカソンなどで最適とありますが、もうひとつ JAMStack 開発時の Web API のモックとしても活用できるのでご紹介。

JAMStack でフロント開発をしている際は、フロント担当と Web API 担当に分かれて開発をします。もちろん双方を同時に担当してもよいのですが、多くのケースでは担当が分かれることでしょう。

そうなるとフロントエンドから呼び出したい Web API はフロントエンド側でモック実装するなり、モックサーバーを用意するなどの必要があります。モック実装すると本質的でないコードをソース管理することになりますし、モックサーバーを用意するには手間が発生します。

そんな時にjsonbox.ioを使うと、手軽な Web API モックサーバーとして利用することもできます。

jsonbox.io の利用方法

まず jsonbox.io のトップページ、https://jsonbox.ioへブラウザでアクセスします。
するとトップページにhttps://jsonbox.io/box_b68kwaff800864XXXXのような URL が表示されます。これはリロードするたびに毎回変わります。これが JSON ストレージの URL になりますので控えておきます。

このbox_b68kwaff800864XXXXの文字列はBOX_IDと呼ばれ、JSON ストレージの ID です。jsonbox.io のトップページで生成されたものを使うほか、20文字以上の英数字とアンダーバー(_)を使って自分で生成することもできます。事前に設定する必要はなくレコードを作るときに指定したものが、そのまま使われます。

ここからはjsonbox/README.mdをベースに紹介します。

レコードの作成

HTTP POST で作成したいレコードの JSON をリクエストします。

1
2
3
curl -X POST 'https://jsonbox.io/demobox_6d9e326c183fde7b' \
-H 'content-type: application/json' \
-d '{"name": "Jon Snow", "age": 25}'

以下のようなレスポンスが返り_id_createdOnが自動生成されていることがわかります。

1
{"_id":"5d776a25fd6d3d6cb1d45c51","name":"Jon Snow","age":25,"_createdOn":"2019-09-10T09:17:25.607Z"}

複数のレコード同時に作成するには-dで渡すデータを配列にします。

1
2
3
curl -X POST 'https://jsonbox.io/demobox_6d9e326c183fde7b' \
-H 'content-type: application/json' \
-d '[{"name": "Daenerys Targaryen", "age": 25}, {"name": "Arya Stark", "age": 16}]'

また URL をjsonbox.io/${BOX_ID}/${COLLECTION}のようにしてグループレコードも作れます。

1
2
3
curl -X POST 'https://jsonbox.io/demobox_6d9e326c183fde7b/users' \
-H 'content-type: application/json' \
-d '[{"name": "Daenerys Targaryen", "age": 25}, {"name": "Arya Stark", "age": 16}]'

レコードの取得

HTTP GET リクエストでレコードが取得できます。pathname によって返る範囲が変わります。

BOX_IDまでの場合、グループレコードを含めた、全レコードが返ります。

1
curl -X GET 'https://jsonbox.io/demobox_6d9e326c183fde7b'

BOX_IDに加えCOLLECTIONも指定することで、そのCOLLECTIONに含まれるグループレコードが返ります。

1
curl -X GET 'https://jsonbox.io/demobox_6d9e326c183fde7b/users'

BOX_IDに加えRECORD_ID、レコードを作成したとき or リスト取得した際に返ってきた_idの値を指定すると、その ID の1レコードが返ります。

1
curl -X GET 'https://jsonbox.io/demobox_6d9e326c183fde7b/5d776a25fd6d3d6cb1d45c51'

またソートやリミット、クエリーなど柔軟な取得方法も備えています。今回は JSON モックサーバーとしての用途を想定していますので簡単な CRUD 処理ができれば十分ですが、アプリなどで実際に使う場合には必要でしょう。詳しくはRead - jsonbox/README.mdをご参照ください。

レコードの更新

HTTP PUT リクエストをRECORD_IDまで指定した URL でレコードを更新します。
PATCH と、バルク更新はサポートされていません。

1
2
3
curl -X PUT 'https://jsonbox.io/demobox_6d9e326c183fde7b/5d776b75fd6d3d6cb1d45c53' \
-H 'content-type: application/json' \
-d '{"name": "Arya Stark", "age": 18}'

レコードの削除

HTTP DELETE リクエストをRECORD_IDまで指定した URL でレコードを更新します。
またクエリーを使用して複数のレコード削除も可能です。

1
curl -X DELETE 'https://jsonbox.io/demobox_6d9e326c183fde7b/5d776b75fd6d3d6cb1d45c53'

制約

フリーで利用できますが、不正利用や乱用を防ぐ(= avoid abuse)ために以下の制限を課しているとのことです。

  • リクエストのボディは 10KB まで
  • 一度に扱えるレコードは 1,000件まで
  • レコード数は 5,000件までを目安に

3つ目のレコード数ほか、高負荷をかけないなどマナーを守りたいですね。これだけの素晴らしいサービスを無償で提供してくださっており、また “小規模向けなのでフリーとしています” とのことです。

原文は以下。

There is no limit on the number of records you store in a box, but please don’t abuse the API by storing large datasets of more than 5000 records. This is meant for small projects and that’s why it is offered FREE of cost. -Limitations


単純な CRUD 処理は REST の Web API として簡単に操作できます。
グループレコードの機能があるので、単純な JSON モックサーバーとしては十分でしょう。

またクエリーやskiplimitを使ったページネーション等の高度な機能もあるので、公式で謳っている通りスモールプロジェクトや、プロトタイピング、ハッカソンでも十分な能力を発揮してくれそうです。

Web アプリのセキュリティ基礎知識を学習できる『体系的に学ぶ 安全なWebアプリケーションの作り方』を読んだ

Web 開発者として仕事をしていく中で、意外にセキュリティ周りの知識が不足していたり、要件やスケジュールの都合でセキュリティへのケアを最優先して取り組むことが難しいと思うような場合があります。

特に最近は各種 Web フレームワークやクラウド開発が多くなってきており、気がつかないままカバーされている領域も多いため、一度基本から知識を整理したいと思い、2018年6月に第2版が発売された『体系的に学ぶ 安全なWebアプリケーションの作り方』を購入して読むことにしました。

目次

1)Webアプリケーションの脆弱性とは

2)実習環境のセットアップ

3)Webセキュリティの基礎 ~HTTP、セッション管理、同一オリジンポリシー、CORS


  • HTTP通信の仕組み
  • ステートレスな HTTP 認証
  • クッキー、セッション管理、同一オリジンポリシー、CORS 等の知識

4)Webアプリケーションの機能別に見るセキュリティバグ


  • 機能別に発生しやすい脆弱性のパターンと対応方法
    • XSS(基礎・発展編)
    • エラーメッセージの情報漏えい
    • SQLインジェクション
    • CSRF
    • クリックジャッキング
    • オープンリダイレクト
    • メール送信、ファイルアクセス、JavaScript、WebAPIの問題など

5)代表的なセキュリティ機能

6)文字コードとセキュリティ

7)脆弱性診断入門

8)Webサイトの安全性を高めるために


  • アプリ以外の側面でも考慮すべきセキュリティ施策

9)安全なWebアプリケーションのための開発マネジメント


全体的にかなり量が多いので一度で読み切るのは大変ですが、簡単に読むならば、まずは 「1章:Webアプリケーションの脆弱性とは」と「3章:Webセキュリティの基礎 ~HTTP、セッション管理、同一オリジンポリシー、CORS」の内容を熟読した上で、実際に開発を進めながら 4章以降を読んでいく流れが良さそうです。

また「4章:Webアプリケーションの機能別に見るセキュリティバグ」においては、提供されているサンプルを利用するか、自分で擬似的に環境を作って実際に脆弱性を経験してみることをおすすめします。色んな脆弱性が網羅されているので、一通り内容を押さえておくと、実際に現場で役に立つ知識として活かせると思います。

Webアプリケーションの脆弱性とは

まず「1章:Webアプリケーションの脆弱性とは」を読むことで、脆弱性の定義、原因、分類、影響について概要的に理解することができます。アプリの安全性を確保する要素を大きくセキュリティバグ(脆弱性)とセキュリティ機能に分類し、それぞれに対するアプローチについて説明されています。

HTTP通信の基本的な仕組みを学習する

「3章:Webセキュリティの基礎 」では、基礎から HTTP の仕組みを理解することができます。クライアントとサーバー間の通信が対話形式で記述されていることもあり、非常に分かりやすいです。

様々なセキュリティバグ(脆弱性)パターンと対応方法を学習する

PHP 及び JavaScript で書かれたサンプルコードを用いて色んな攻撃の手法が紹介されており、具体的な対応方法を知ることができます。

代表的な Web アプリケーションの脆弱性としてよく知られている XSS(クロスサイト・スクリプティング)については、基礎編と発展編で別れて紹介されています。他にも SQL インジェクション、CSRF、オープンリダイレクト等、実際に脆弱性診断の結果レポートによく出てくるような内容が網羅されているので、個人的には一番興味深く読めた章でした。

セキュリティ機能を学習する

パスワードの保存方法とハッシュの仕組みについて改めて体系的に知識をインプットできたり、ログイン画面やパスワードリセット機能の実装に必要なノウハウを知ることができます。

最近はサードパーティの認証・認可サービスにお任せするケースも多いと思いますが、多種多様な要件に応えたりトラブルシューティングできるようにするためには、この章で紹介されているセキュリティ機能の仕組みについてちゃんと理解しておく必要がありそうです。

その他、アプリ以外の側面でも考慮すべきセキュリティ施策


  • サーバーの運用
  • ネットワーク経路
  • フィッシング
  • TLS の中間者攻撃
  • マルウェア対策

など、幅広い領域において必要となるセキュリティ施策について学習できます。技術的な部分のみならず、Web アプリをめぐる各関係者が持つ責任と範囲の考え方についても触れられており、とても参考になります。

まとめ


  • Web アプリケーションを開発する上で必要となるセキュリティの基礎知識が学べる
  • 様々な脆弱性が網羅的に紹介されており、脆弱性だけでなくセキュリティ機能・サーバー運用に至るまで一気通貫して学習できる
  • 量が多いので一度にすべて読み込むのは大変だが、4章は時間をかけてでも一通り読んでおくと良い

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

冒頭にも書きましたが、最近は多くの Web アプリが開発フレームワークやクラウドサービスに依存するようになり、知らないうちに色々カバーされていることが多いので、個人的にはそういうのが当たり前のような感覚になっていることもありました。今回の記事をきっかけに改めて基礎から体系的に学習できたので、日頃の仕事にも活かしていきたいと思います。

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

Netlify へ CLI デプロイで、CI/CD する

静的なサイトを手軽にホスティングしてくれる Netlify。独自のデプロイの仕組みに加えで CLI からもデプロイできます。CLI からデプロイすることで CI を使って継続的結合・デプロイが行えるようになります。Netlify の CLI デプロイについて解説します。

Netlify は、独自のデプロイの仕組みを持っているのでウェブコンソールからの設定や netlify.toml を用意することで、連携している GitHub などのソース変更から自動的にデプロイしてくれます。通常は自動デプロイがよいのですが、初期コードの投入などで Git にプッシュせず CLI から直接デプロイしたいこともあります。また CircleCI などの CI/CD サービスを使っている場合にも、CLI からのデプロイは必要となります。

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

  • Windows 10 64bit + WSL Ubuntu 18.04.1 LTS
  • Node.js 12.10.0
  • netlify-cli 2.15.0

Netlify CLI 2.0

Node.js ベースで新しく作られたNetlify 公式の CLIです。Go ベースの CLIもあり、現在もサポートされていますが、Node.js ベースがアクティブとのことです。

マニュアル・デプロイ

デプロイするプロジェクトに netlify-cli をインストールし実行します。
※ 公式ドキュメントではグローバルにインストールしていますが、グローバル汚染避けたいので個別にインストールしています。またnpxするには重いのでプロジェクトごとに入れるのが良いでしょう。

デプロイするディレクトリを指定する場合は-d [DIR]で指定します。下記例ではdistディレクトリをデプロイします。

1
2
3
4
5
$ yarn install netlify-cli

$ yarn netlify deploy -d dist
Logging into your Netlify account...
Opening https://app.netlify.com/authorize?response_type=ticket&ticket=4c8c9c402pe530d68dkd61d09adbXXXX

デプロイを実行するとブラウザが表示され、CLI アクセスの認可を求められます。CLI で、デプロイを認める場合は [Authorize] をクリックします。

認可すると処理が続き、Netlify 上のサイトとの関連付けを聞かれます。
今回は、すでに Netlify にサイトが作られている前提でLink this directory to an existing siteを選択しました。

1
2
3
? What would you like to do? (Use arrow keys)
❯ Link this directory to an existing site
+ Create & configure a new site

既存のサイトを指定する方法を聞かれます。今回はChoose from a list of your recently updated sitesでリストから選択しました。

1
2
3
4
5
? How do you want to link this folder to a site? (Use arrow keys)
Use current git remote origin
Search by full or partial site name
❯ Choose from a list of your recently updated sites
Enter a site ID

サイトを選択とするとデプロイが開始するのですが、たまに失敗するケースがあります。
法則性が読めないので何とも言えないのですが、失敗したらデプロイのコマンドを再実行すると成功します。再実行時は、先ほどの設定が保存されているので認可やサイト選択は省略されます。

デプロイが成功するとLive Draft URLが出力されます。
その URL にアクセスするとデプロイされたサイトが表示されます。

なおプロダクションとしてデプロイしたい場合は、コマンドライン引数に--prodを渡します。
e.g.yarn netlify deploy --prod -d dist

ここまでで設定した内容は、以下に保存されています。
※ 不要になった場合は安全のために削除しておきましょう。

  • 認可情報:~/.netlify/config.json
  • サイト情報:.netlify/state.json(プロジェクトのディレクトリ))

自動デプロイのための設定

マニュアル・デプロイの方法はブラウザで認証認可が必要となるため CI/CD では利用できません。
CI/CD で使う場合は、自動デプロイできるように設定します。

Netlify の Personal access tokens のページを表示し、[New access token] をクリックします。
https://app.netlify.com/user/applications#personal-access-tokens

Create a new personal access token 画面が表示されるので、[Description of your token] にトークンの説明となる文字列を入力し [Generate token] をクリックします。今回はテスト用に [deploy-via-cli] としました。

アクセストークンが生成されるので控えておきます。

続いて、デプロイするサイトの設定を表示し、[API ID] を控えておきます。

デプロイするプロジェクトに netlify-cli をインストールしておき、以下のコマンドでデプロイします。

  • --prodで、プロダクションのデプロイ
  • -d [DIR]で、デプロイするディレクトリを指定
  • -a [AUTH_TOKEN]で、パーソナルトークンを指定
  • -s [SITE_ID]で、デプロイするサイトの APP ID を指定
    1
    $ yarn netlify deploy --prod -d dist -a [AUTH_TOKEN] -s [SITE_ID]

この場合だと package.jsonなりに [AUTH_TOKEN] を書かなければなりません。環境変数を使う形にします。
CI/CD サービスで環境変数を設定できるので、そちらに設定します。
※ 環境変数名を ${NETLIFY_AUTH_TOKEN} と ${NETLIFY_SITE_ID} にした場合は、それぞれ-a-sのオプション指定は省略できます

1
$ yarn netlify deploy --prod -d dist -a ${NETLIFY_AUTH_TOKEN} -s ${NETLIFY_SITE_ID}

手軽にホスティングできながらも、本格的な CI/CD にも対応できる Netlify、素晴らしいですね。

ただし、個人に紐づくアクセストークンを使うので CI などに設定する場合は、その人がプロジェクトから離れた場合の引継ぎなどを忘れないようにしましょう。GitHub などはリポジトリでトークンが作れるので、今後そのようになると嬉しいです。

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 上に埋め込むためのプラグインなどもありますので、各現場の環境に合わせた使い方を工夫してみてはいかがでしょうか。

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