はてなブックマーク

Jamstack Advent Calendar 2020の3日目の記事です。 最小限の静的サイト https://hatebu.noplan.cc 1リクエスト（最小限） 半年ぐらい前に11tyのドキュメントを読んでから、そのうち試したいなあと思っていたので、以前に作ったサイトを11tyで書き直しました。11tyはシンプルに必要な機能が揃っていて、文字通りの静的サイトジェネレーターの仕事をしてくれる所がよいです。 ドキュメントがわかりやすいので、そっちを読んでもらった方が確実ですが、ドキュメントを読むのが面倒くさい人もいると思うので、やったことをまとめてます。Markdownで書けるブログのテンプレートを作る、とかの方が需要がありそうですが、今回は1ページしかないサイトなのでMarkdownは使ってないです。 そもそも、1ページのために静的サイトジェネレーターってどうなの。 11ty -

AwwwardsやFWAに掲載されているサイトでよく見かける、ゆったりした慣性スクロール。 http://madies.mx http://www.amandabraga.com http://56k.studiovoila.com 見覚えがある人もいると思いますが、スクロールの反応が気持ち遅れて来る、自前の慣性スクロールっぽいやつです。これのやり方の参考が少なく実装に手間取ったので、実装例をまとめました。他にも色々なアプローチがありそうですが、参考のひとつとして。 最初に断っておきますが、かなり邪悪な実装です。ブラウザの本来の機能を上書きする実装の多くは、ユーザーの利益にはならないので、ご利用は計画的に。。 デモ https://codepen.io/nishinoshake/full/dyowbyr 採用する利点と欠点 利点があまり浮かばない・・・ 利点 このスクロールに心地よさを感じ

AWSの料金、ややこしいですよね。 サービスの選択肢が多く構成が柔軟なおかけで、さまざまな要件をカバーできるのは嬉しいのだけど、そのぶん料金体系がややこしいので、やるせない気持ちになります。 この気持ちはなんだろう、この気持ちはなんだろう、と自問しているうちに春になってしまったので、AWSの料金を「ざっくり」計算できるサイトを作り始めました。 ざっくりAWS 公式ツールの存在 Simple Monthly CalculatorというAWSの料金を計算できる公式のツールがあるのですが、悲しいことに名前ほどシンプルではありません。 正確な料金を算出するために入力項目が多いのは仕方がないとは思うのですが、サイトを開いたときの威圧感がすごいので、もう少しさっぱりできないかという気持ちがありました。 なので、公式ツールの敷居が高いと感じる自分のような人向けに、料金を「ざっくり」計算できるサイトを作り

※ 東京リージョン - 110円/ドル - 30.5日 × 24時間 手軽に料金を知りたいときに Fargate | ざっくりAWS 細かい計算方法はいいから料金を知りたいという方は、Webサイトで手軽に算出できるようにしたので使ってみてください。東京リージョン限定ですが、サクッと料金を算出できます。 計算するときに考慮すべき変数 タスクに割り当てたリソースと、タスク数、稼働時間と外部へのデータ転送量で料金が決まります。 他のサービスと連携した場合はそちらでも課金されますが、本筋から外れるので無視します。 vCPU/メモリ Pricing is based on requested vCPU and memory resources for the Task 割り当てるvCPU/メモリのリソースによって料金が変わります。ひとつ注意が必要なのが、vCPUに対するメモリの選択肢が決まっているの

Contentfulを使ってみたくなったので、印象に残った邦画を書き残すブログを作りました。ブログを作って満足してしまったので、記事の中身は（仮）です。Contentfulの考え方に馴染むのに少し時間がかかったので、そこのところの整理がメインの記事です。 ヘッドレスCMSというもの CMSというと、WordPressとMovable Typeぐらいしか知らなかったのですが、最近ヘッドレスCMSという言葉を耳にするようになりました。ヘッドレスCMSは、WordPressのようにテンプレートを表示する部分を持たず、APIでデータを提供することに特化している点が特徴です。 ヘッドレスCMSの選択肢は、こちらのサイトにたくさんありましたが、そのなかで、ContentfulというCMSのサービスが気になったので、Nuxt.jsと組み合わせて簡素なブログを作りました。 headlessCMS | A

nuxt generateの機能は、静的サイト生成とか、単に静的生成といわれることが多いですが、文中で多用するのがツラいので、より短く「SSG(Static Site Generation)」で統一しています。 Nuxt.jsにおけるビルドの選択肢 Nuxt.jsでは、SPA・SSR・SSGの中から、好きなものを選んで開発できます。 初期設定ではSSRで動作するようになっていますが、流れとして自然なのでSPAから順に利点と欠点をまとめました。それぞれのビルドを行うため設定は、ドキュメントにわかりやすく書いてあるので、そちらでご確認ください。 サーバーサイドレンダリング - Nuxt.js SPA（Single Page Application） 利点 実装しやすい サーバーの準備が楽 欠点 初期表示が遅い SEOに不安がある OGをページごとに設定できない SPAは、最もシンプルに実装でき