lulzneko
ふりかえり

2019年の振り返り

2019年最後のポスト、１年間の活動を振り返ります。

サマリー

  • 発表: 16回
  • 記事: 61本
  • プルリク: 17本
  • アプリ開発: ４本
  • ハッカソン: ２回
  • Special Topics: ２つ

発表 16回

今年は１月を除いて毎月発表する機会がありました。大きいイベントから勉強会、LT、クローズドの会と多様な場所で話をする機会を頂け、そして多くの出会いに感謝です。ありがとうございます！

去年の６回から、今年は17回と約３倍の発表に臨みました。その中で技術やナレッジを伝えるにあたって話をするのは、私に合った方法なのかなと感じ、引き続き発表の場に立てるよう研鑽して行きたいです。

１つ１つが大きな思い出がありスライド埋め込みやサマリーを書きたいですが、書ききれなそうなのでいくつかをピックアップしてサマリーします。

年初よりデブサミで発表できたのがスゴイ経験になりました。300 席の会場で立ち見という状況、集客率ランキング 15位と多くの方に関心を持っていただけ嬉しいです。これだ多くの方の前で話をしたのは初めてでした。そして多くの方にサーバーレスでの開発の楽しさをお伝えできてよかったです。いつかまたデブサミの場に立ち、今度は満足度ランキングに載れるような良い発表をできるように技術を磨きたいです。

そして JAWS DAYS 2019。普段 AWS を使って開発をしている中で JAWS DAYS を、はじめとするコミュニティで勉強させて頂いているのを何か返したいとのことで、JAMstack というキーワードが注目を集め始めている中、サーバーレスという観点から JAMstack を取り上げて伝えることができ、コミュニティに少しでも貢献できたのかなと。
また、こちらのイベントでは私の活動を大きく変える転換点となりました。

JAWS DAYS 2019 で Shifter のSeiji Akatsuka（@seijiakatsuka）さんに誘われ Shiftup! JP_Getshifter Vol3 で発表します。
これまでカンファレンスでの発表だけだったので、いわゆる勉強会形式での発表は初めてで、とても緊張しました。しかしながら聞いてくださる方がそばにいて、途中休憩や懇親会で発表前後でカジュアルに参加者さんと話ができる(& 🍺 もある) のが新鮮で、また楽しかったです。このカジュアルな時間から Shifter + SSG のアイデアが生み出され、そして公式神対応という流れが発生します。まさに勉強し新たな世界が作られるのを経験させていただきました。ありがとうございます。

そして、その Shiftup! JP_Getshifter Vol3 で様々な出会いが生まれ、Serverless Meetup Tokyo #12、初夏のJavaScript祭 in メンバーズキャリア、WordCamp Tokyo 2019 とつながっていき、今新たなプロジェクトに参画するという大きな変化につながっていきます。人生何があるかわからない。

また初挑戦としては、勤怠を自動化する技術 LT Night で LT にも初挑戦しました。５分、短かっ！見事２分オーバー。すみません。
いろいろ反省する中で、私は話が長いので、もう少し尺の長いものが会うんだろうなぁと思いつつ、一気に話し切る経験は楽しく、また LT に挑戦したいです。

「クローズドな勉強会」が登場するようにもなりました。いろいろな都合により参加者が限られているものですが、話した内容はアウトプット。多くの情報を落とし分かりにくい話にはなってしまいますが、せっかくなので汎化して載せるようにしています。ほぼ作り直しの作業になるので、時間がかかって準備中が取れないものもありますが、可能な限り出したいです。オープンなイベントで話をしたいのはありますが、いろいろな事情があるのでクローズドになるのも仕方なく、そのような場合でも声をかけていただき発表できるのはうれしいので、もしニーズがありましたら声をかけていただけると嬉しいです。

といった発表活動をサマったのが「プロポーザルの書き方を学ぼう- 登壇の技術を勉強する会」。
CfP に、どうやって応募するの、どんな書き方がいいのという話をカンファレンスのオーガナイザーが話をするという面白い勉強会。LT 枠でしたが、後枠が空いてたので 10分いただきトークさせていただきました。ちょうど Riotz.works という活動のサマリーをしたかったので、良い機会になるとともにサークルとしての活動を発信したいという思いもあり、お話しできてよかったです。

そして〆は PWA Night vol.11。もともと PWA 好きで去年の SPAJAM 2018 東京Ｄ予選リアルタイムの競演と参加型観戦で音楽を最高に楽しむ「ラップ､タップ､アップ🎶」、今年の SPAJAM 2019 東京Ａ予選パーソナルニュースの配信と交換によって爆速で仲良くなるアプリ「📰NEWʑ Link」とモバイルアプリのハッカソンなのに PWA で戦ってきました。(去年は予選優秀賞を取れたので PWA はスゴイ！)
が、今年の後半は JAMstack を中心に発信し PWA の発信がなくなっていました。そんな中、改めて PWA を思い起こさせていただきました。JAMstack と PWA は相性が良く、来年はセットでしっかり発信していきたいです。

と、怒涛の発表の１年でした。
ちょっとオーバーペースだったので来年はペース配分を考えながらも、発表は私の情報発信方法の中で自分にとって合うので引き続きしっかりと活動していきたいと思います。
あとは似たような方向性としてはハンズオンを作って開催するとかできたらいいなと。

記事 61本

去年は６本だったので大幅に増えましたが、４月～６月の間カック@技術ブロガー（@kakakakakku）さんに、ブログメンターへついていただいて３ヶ月間で 36本。つまり自力の９ヶ月では 25本でした。メンタリング前の 14本はよいとして、後半の６ヶ月で 11本はまずい。メンタリング前よりペースが落ちてる。。。

ちょうどそのころから、発表を月に２回したり、アプリ作りを伴う LT、Closed イベントへの対応、新規プロジェクトへの参画に、月３本の発表とかなり無茶なスケジュールを詰めてしまいブログに使う時間を次の発表準備に当ててしまったことが敗因です。発表直前まで資料に手入れするタイプなので、発表が続くとなおのこと発表資料へ注力。通常ブログはまだしも、発表しましたブログでサマリーを入れてないのはよくなかった。これは反省点で、来年はバランスをとって活動できるようにしたいです。

発表とブログの両輪があってこそ、技術やナレッジをしっかり伝えることができると思えばこそ、頑張りどころだと。

プルリク 17本

今年は、はじめてプルリクを出すことに挑戦し 17本出すことができました。
もう少し貢献したかったですが、なかなかプルリクを送れそうなシーンを見つけられず難しかったです。引き続き貢献できる機会を狙ってプルリクを送りたいと思います。

アプリ開発 ４本

アプリ名イベント関連資料
ミツカルヘアサロン💇CTO vs Hackers ハッカソンブログ/スライド
📰NEWʑ LinkSPAJAM 2019 東京A予選ブログ/スライド
空鏡ブログメンティーソース/ブログ
ツカエタルヒの記録勤怠を自動化する技術 LT Nightブログ/スライド

アプリ作りの機会を得られたものの、リファクタリングや最終化ができてなくて「空鏡」以外は公開できてないのが残念なところ。
ちゃんと時間を作って仕上げたいです。

ハッカソン ２回

ハッカソンは開発者にとっての総合競技みたいなイメージを持っており、とても好きです。
今年は「CTO vs Hackers ハッカソン」と「SPAJAM 2019 東京A予選」の２つに参加しました。

「CTO vs Hackers ハッカソン」はアイデアソン含めて６時間と短時間のイベントでした。それも現場でチーム編成からなので、かなり緊張と不安がよぎるイベントでしたが、幸いにも「個人が提案する時代に向けたアプリ」という方向性でチームの思いが一致、そして深い理解と共感ができたことから良い開発が行えました。技術スタックも分散しかなりツイていたと思います。順位をつけるイベントではなかったので賞などはありませんでしたが、とても楽しめるハッカソンでした。

「SPAJAM 2019 東京A予選」は、２度目の SPAJAM 挑戦です。
チーム作りに時間をかけられず締め切り当日に Riotz 仲間のlopburny (ロップバーニー)（@lopburny）と相談して２人で出ました。さすがに２人は無謀と思っていましたが、チャンスを前に挑戦しないことは選べずハッカソンへ臨むことに。結果は残せませんでしたが、限られた時間の中で全てを出し切れたと思います。

なお徹夜ハッカソンのお供は#22 「Trello があるので眠れない」 | #omoiyarifm。意識を高く保つには良く(それ、別の意識や)、３回ぐらい聞いてましたｗ

Special Topics ２つ

カック@技術ブロガー（@kakakakakku）さんの、ブログメンター

４月～６月の３ヶ月間ブログのメンターについていただきました。
カックさんの資料やブログメンターの話はよく Twitter で見かけていて、機会があったらうけて見たいと思っていたのでスゴクありがたいです。

ブログのテーマだしから始まり、独自のブログシステムを使っていることからの改修点、ちょっと自分が情けないところとしてはタイポの指摘、記事の内容に関するレビューと方向性の指摘、そして何より技術者としての活動の幅を広げる話などをしてくれます。この期間で多くの勉強をさせていただき、ブログを書くことへの楽しさを知ることができたと思います。

一方でカックさんが一番おっしゃっていた「継続性」について、メンター終了後に続いてないのは大変申し訳なく思うとともに、自分を情けなくも思います。新しいことを始めたり、集中して取り組むことが得意なものの、継続は苦手。ブログメンティーの振り返り記事は書いていたのに、卒業を書いていなかったのは、その不安があったからです(あと直後の３発表＋アプリ１本のスケジュールは入ってたから限界が見えてたのもある)。熱いうちに打てとも言いますが、熱いまま書いても性根は変わらないのであえて年末振り返りまで待つことにしましたが案の定。

ブログの項でも書きましたがスケジュールの不備が大きかったと思う(思いたい)ので、来年はバランスをとってブロギングをしっかりしていきたいです。

Serverless Operationshorike takahiro（@horike37）さんの、共創シフト

サーバーレスコミュニティのオーガナイザーを務めるhorike takahiro（@horike37）さん共創型開発へ参画させていただくことになりました。

horike takahiro（@horike37）さん資料

常々サーバーレスで開発するというのは開発サイクルを軽量に回すことができる、また H/W, OS, M/W などの運用面を最小化して開発に注力できることにメリットがあると感じていました。極端な話、開発面をサポートしアプリの仕様把握やメンテができるところまで一緒に行くことができたら、後はほぼ自分たちでできるのだろうなと。そうしたことを考えている中で私にできることは何かなと考えていました。

そんな折にサーバーレスをフルに活かす開発の手法としての共創型開発に興味と共感をもち、是非にと参加させていただきました。
こちらについては、どこかで発表や記事にしたいと思います。
※ サーバーレス開発支援の導入に興味ある方は Serverless Operationshorike takahiro（@horike37）へご連絡いただくか、私も取り次ぎしますので気軽にご相談ください。

Riotz.works が発足して、ほぼ３年。

１つのカンファレンスで発表することができて技術者としての活動の楽しさを感じ、そして活動を広げきました。
今年は、それが大きな活動につながった年だと言えるでしょう。

そこには多くの方々のつながりがあり、発表を聞いてくださり、ブログを読んでくださった皆さまのおかげです。
ありがとうございます！

引き続き、多くの技術やナレッジの情報を発信してまいります。
良かったところを伸ばし、反省点を見直して次の年へつなげられるよう頑張ります。

今後とも、よろしくお願いいたします。
よいお年を。

Author:lulzneko

共有：
lulzneko
フロントエンド

Shifter Webhooks と Gridsome で作る、最初のウェブサイト on Netlify

本記事はShifter Advent Calendar 2019の 24日目です。

昨日はTai / JOTAKI Taisuke 🍺（@tekapo）さんのShifter-LocalでWordPressテーマ開発環境を作る – わーどぷれすっ!です。Shifter をローカルで動かして開発する方法が紹介されてます。スゴイ！

さぁ、今日は私の出番。アドベントカレンダーのネタや！と思っていたのですが、諸般の事情により時間切れてToro_Unit（山の上のとろゆに）（@Toro_Unit）さん公開の Shifter Webhooks + Gridsome にマル乗っかりさせて頂いた記事になります。(すみません💦)

Shifter と Netlify デプロイ連携について

2019年4月3日に開催されたShiftup! JP_Getshifter Vol3！はじめてのスタティックサイトジェネレーターのイベントへ参加した際に、Shiftup! JP_Getshifter Vol3！ 振り返り、Shifterのヘッドレス CMS 化に思いを馳せるという記事を書きました。

それから１ヶ月ちょっと、何と公式で「Shifter Webhooksで Netlify上のGatsbyサイトにWordPressコンテンツをインポート可能になりました」という神対応がありました。

詳しくは公式のブログを読んでいただくとして、概要としてしては以下になります。
GatsbyJS で作ったプロジェクトを、あらかじめ Netlify へデプロイしておきます。そして Shifter Webhooks に Netlify の BuilhHook を登録します。Shifter からSend webhookすることで Netlify でビルド＆デプロイされます。

Shifter + Gridsome で Netlify へ、デプロイ

Shifter 公式の機能としては「Shifter から Webhook を呼び出す」ものになります。GatsbyJS のコードや方法はサンプルとしての位置づけになります。そうGridsome推しの私としては、やはり Shifter + Gridsome で実現したいところ。

さっそく実装を検討しようとした(どころか時間切れな)ところ、Toro_Unit（山の上のとろゆに）（@Toro_Unit）さんが素晴らしいプロダクトを公開してくださりました！ Shifter 公式の GatsbyJS で解説されていた話を Gridsome 版にポーティングしたものです！！

こちらを使うと、いい感じです！
以上、私のアドベントカレンダー終了です 😇

torounit/gridsome-shifter を使って Shifter + Gridsome on Netlify

とはいえ、さすがに 24日、ここで引くわけにはいかないので、torounit/gridsome-shifterを使わせていただいて、Shifter + Gridsome on Netlify をやってみます。
※ あらかじめ Shifter と GitHub、Netlify へサインアップし、ログインしておきます

Shifter のサイト作成

Shifter の Create new sitehttps://go.getshifter.io/admin/sites/createへアクセスします。
今回は Webhooks を使いますので [Tier 2] の [Select] をクリックします。

注文の確認とサイト名の確認が表示されるのでTier 2であることを確認し、[Site name] を入力します。サイト名が決まったら [Create] をクリックします。

Shifter で、サイトが立ち上がりました！
[CloudFront Domain] をひかえておきます。

続いて [Start WordPress] & [Dashbord] をクリックして記事を投入します。Webhooks を使うために以下の３点を作成しておきます。

GitHub プロジェクトの作成

https://github.com/torounit/gridsome-shifterへアクセスします。
画面右上の [Fork] ボタンをクリックして、自分のアカウントへフォークします。
※ 私の環境だと [Deploy to netlify] ボタンをうまく動作させられなかったのですが、こちらを使うともっと簡単のはず

また、今回のタイミングが悪かっただけと思いますが以下のエラーが発生したため Gridsome のバージョンをあげました。変更する場合はpackage.jsonを直接編集で問題ありません。今回は"gridsome": "^0.7.12"としました。

1
2
3
4
5
12:09:14 AM: Error:
12:09:14 AM: Vue packages version mismatch:
12:09:14 AM: - vue@2.6.10
12:09:14 AM: - vue-server-renderer@2.6.11
12:09:14 AM: This may cause things to work incorrectly. Make sure to use the same version for both.

Netlify でサイト構築

https://app.netlify.com/へアクセスし、[New site from Git] をクリックします。

[GitHub] をクリックします。
※ はじめての Netlify/GitHub 連携になる場合は GitHub のサイトが開き Netlify への認可を求められるので [Authorize netlify] します

リポジトリの一覧が表示されるので、先ほど Fork したリポジトリを選択します。

設定項目は、とくに変更する必要がないので [Deploy site] をクリックします。

ビルドが失敗しますが気にせず [Site settings] をクリックします。
※ この段階ではビルドの Webhook で起動していないためです

画面左のメニューから [Build & deploy] を選択し、下へスクロール Build hooks から [Add build hook] をクリックします。

Build hooks の設定が表示されます。
[Build hook name] 管理しやすい名称を入力し [Save] をクリックします。

ビルド用の Webhook URL が生成されるのでひかえておきます。

Shifter Webhooks を設定！

お待ちかねの Shifter Webhooks を設定します。

Shifter の WordPress ダッシュボードの左メニュー下の [Shifter] から [Webhook] を選択します。
[Webhook URL] に、先ほど取得した Netlify のビルド Webhook URL を入力し [Save Changes] をクリックします。

画面上部のメニューバーから [Shifter] - [Send webhook] をクリックします。

Netlify へ戻るとサイトが公開されていることが確認でき、サイトの URL をクリックすると Shifter で投稿した内容が表示されます。
(画像とかが抜けているのは Publish したけど Generate してないからかもです。これから確認。)


※ メンテナンスのため、画像 URL のサイトはアクセスできません。

まだ最初の連携なので CSS どころか画像も表示できてない状態ですが、これは連携や Gridsome での開発を楽しめるところ。まずは Shifter で記事を投稿し、それが Gridsome を通して Netlify へ公開できるところが素晴らしいです。

そして何よりも、素晴らしいプロジェクトを公開してくださったToro_Unit（山の上のとろゆに）（@Toro_Unit）さんありがとうございます！！

明日は〆でSeiji Akatsuka（@seijiakatsuka）さんの「来年の抱負？」です。楽しみですね♪

では、ハッピーホリデー！！

Author:lulzneko

lulzneko
開発

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
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件までを目安に

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

原文は以下。

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 モックサーバーとしては十分でしょう。

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

Author:lulzneko

lopburny
ふりかえり

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

成果

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

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


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

週間PV数の推移

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

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

所感

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

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

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

Author:lopburny

lopburny
書評

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

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

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

目次

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

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

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


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

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


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

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

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

7）脆弱性診断入門

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


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

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

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

Author:lopburny

lulzneko
開発環境

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 などはリポジトリでトークンが作れるので、今後そのようになると嬉しいです。

Author:lulzneko

lopburny
開発

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 で、startとendまたはfromとtoといった範囲（期間）を指定するパラメータが必要になる場合、まとめてperiodといった一つのパラメータにすることができます。

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

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

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

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

Author:lopburny

lopburny
フロントエンド

デバッグに便利！ブラウザの 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 ファイルはあまり新しい仕組みとは言えないですが、個人的には複数のチームで開発する現場で役に立ったことがあったので、紹介してみました。最後まで読んでいただきありがとうございました。

Author:lopburny

lopburny
フロントエンド

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 ですが、いくつか考慮すべきポイントがあるので記事にしてみました。皆さんの参考になれば幸いです。最後まで読んでいただきありがとうございました。

Author:lopburny

lopburny
フロントエンド

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 にアクセスしてデータを出し入れすることができます。
例えば、以下２つの 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 は２つのタイプのものがあります。

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 から操作することを無効にすることができます。これにより悪意のある第３者によって任意の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 はシンプルながら何かと役に立つ場面が多く、大変便利ですが、いくつが注意点もあります。これについては別記事にて紹介する予定ですので、合わせてチェックしてみてください。

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

Author:lopburny