GitHub のマイページのトップに生えている草のデザインで、いろいろなものを可視化できる Web Components, weed365 を作りました。 例えば、東京における Covid-19 の感染者数はこのように表示できます。 <weed-365 date="2021-05-14" kusas='{ ... // 中略 "2021-05-03": 592, "2021-05-04": 530, "2021-05-05": 604, "2021-05-06": 589, "2021-05-07": 598, "2021-05-08": 496, "2021-05-09": 431, "2021-05-10": 405, "2021-05-11": 363, "2021-05-12": 254, }' ></weed-365> <weed-365 date="2021-05-15" ku

OGP は「環境を考慮しよう！」という画像です。 NextJS へ環境変数をセットする時、デプロイを考慮した上で.env を使いたい・ビルド時と起動時の環境変数がある・サーバーとブラウザでの環境変数があるといった風にややこしい点があり、自分はよく調べ直しています。 基本的には以下の 3 つの公式ドキュメントを見ればいいのですが、 Environment Variables Environment Variables(basic-features) Runtime Configuration 整備されたのが最近なので古い情報が定着していたり、ここに書いていない細かい挙動なんかもあったりするので、まとめて行こうと思います。 .env.* を使って読み込める Environment Variables にもある通り、.env.* を使うことで環境変数を読み込めます。 設定ファイルに環境変数を書い

前に書いた ESLint と Prettier の共存設定とその根拠について が公式推奨が変わったことにより一部間違った情報になっているのでその訂正記事です。 該当記事に書いた内容は Prettier と ESLint の関係を読み解く上で役立つ情報だと思うので、警告とこのページへのリンクを書いた上でそのまま残しておきます。 (追記) この記事の内容も間違った内容を書いていました。なので一度大幅な訂正をしています。prettier-eslint も推奨ではありません。 変更点の要約 Prettier と ESLint の組み合わせについて公式 の推奨方法が変わりました。 きっといつかこの情報も古くなるので直リンクではなく、ドキュメントの GitHub のリンクを貼っておきます。 ドキュメント自体のリンクはこちらです。 新しいドキュメントを要約すると、 Linter と Formatter

はてブにおけるネガティブなコメントやそれが引き起こす炎上から自分を守るための、そのプロテクト機能をこのブログに実装した話です。 燃えたくないけど読まれたい 私はこのブログを運用する上で 「燃えたくないけど読まれたい」という気持ちを持っています。 ブログを書くからにはやっぱり反応は欲しいし、たくさんの人に見られたいというのが率直な感想です。 そのため、燃えるのを防ぐためにも誰かを煽ったり傷つけたりせずに、健全に運営して行こうというのを意識して運営しており、特にその投稿が誰かを傷つけないか・誤った情報を断定的に発信していないかといった自浄的なチェックをしています。 ただ、どうしても燃えやすい話題もあったり、意図せずに燃えるパターンも見たりはしているので、それについてどう言及して行こうかと言うのを悩んでいました。 そこで炎上プロテクト機能をブログに組み込んでみることにしました。 はてブのコメント

Vercel での環境変数周りでのあれこれ、ずっと苦しみ続けていたので自分なりのプラクティスをメモします。 辛さの原因は Vercel のアップデートのスピードが早く正しい情報にアクセスし辛いことが一因としてあるので、それをなくせたら良いなと思っています。 もしこのドキュメントが古くなっていたら Issues などからお知らせていただけると幸いです。 Next.js を前提とした解説になりますが、 Next.js の環境変数周りについては解説を省きます。 Vercel での環境変数周りがややこしいのは Next.js に起因しているものもあるとは思うのですが、話が長くなるので別の記事にて補足したいと思います。 (ビルド時・サーバー・クライアントで見える・渡せる環境変数や方法が変わる話) やりたいこと: フロント側から環境変数別にエンドポイントを切り替える Vercel は プレビュー環境と

Gatsby製サイトをNetlifyにデプロイする前に見ておきたい設定2つ（ビルドと表示）2020-08-03 12:00 Netlify にはビルド時のキャッシュと HTTP のキャッシュをユーザー側で設定できる口があります。 このキャッシュの設定をすることで、ビルドや表示が早くなり良いこと尽くしなのでこれを気に見ていきましょう。 ビルド高速化 Netlify ではビルドを回すとソースコードを見て 0 からビルドします。 そのためキャッシュが使える手元でのビルドに比べて時間がかかります。 特に gatsby-image は致命的で、画像から圧縮・Traced SVG の作成・サムネイル化・各種デバイス向けの最適な画像出力を行うため、画像が絡むサイトのビルド時間はとても長くなります。 このブログもそういった画像をつかったブログですが、現在 20 記事あるサイトでのビルドで約 10 分かかっ

No Class CSS Museumという No-Class CSS フレームワーク比較サイトを作りました。 簡単な demo 用のコードに何かスタイル当てたいけど、そんなに時間かけたくないしそもそもデザインセンスないしどうしようかなってときに No-Class CSS フレームワークが便利です。 たとえば昨日公開したFirebase の存在をフロントエンドから隠蔽するためにのデモサイトもそういった No-Class CSS フレームワークであるnew.cssを使いました。 これは CSS ファイルを読み込んだだけ(タグにクラスを割り振ったりしていない)なのですが、それだけでいい感じにスタイルが当たってちょっと感動しました。 以前の記事であるブログの 1 ヶ月を振り返るに書いた通り、このブログは書いた内容のサンプルコードやデモをどんどん公開していく方針で運営しています。 ただ、なにもスタ

css-loader と style-loaderを間違えない ~css-loaderを使わずにcssを使ってみる~2020-06-26 css-loader と style-loader どっちがどっちかってたまになるので、そうならないための備忘です。 これらは webpack の loader であり、JS で構築されるアプリケーション内で CSS を扱うために利用されます。 最近は CSS in JS の利用も増え、CSS ファイルを読み込む機会は減ってはきているものの、reset.css を読み込んだり、UI ライブラリが提供するグローバルな CSS を読み込んだりと CSS を直接 JS に import する機会はまだまだ多いと思います。 そして 1 ファイルでも CSS を読み込むなら loader にその設定が必要となるので、まだまだお世話になり続けるでしょう。 そんな利用

そういえば Babel をちゃんと勉強したことなかったなと思ってちゃんと勉強してみたって言う話です。 つまり Babel をノリで使ってたことになるのですが、自分がプログラミングを始めたときは @babel/preset-env がすでに存在しており、それを使っているだけで全てを倒せていたので勉強する必要がなかったという事情があります。 ただ、流石に知らないと言ってもネットサーフィンしているとなんらかの情報のインプットはされるので、 Babel は ES6 -> ES5 に変換する（これは間違った理解） Babel は AST 操作によって変換する Babel は parse -> traverse -> generate して変換する みたいな順番で少しずつ解像度を上げながら理解はしていました。 最後の、「Babel が parse -> traverse -> generate して変