I've spent the last few weeks working on three new free themes for IndieWeb blogging: Indiepaper, Newsprint, and brennan.jp.net, all of which centre around giving people a place to call their own on the internet.
When your partner's game experience is broken, you build them something better. A 48-hour journey through 3D dice, iOS Safari bugs, and the UX of joy.
Build a link blog without a backend using Hugo and markdown. Track reading, articles, and activities with yearly detail pages and RSS filtering.
How this blog is built: Hugo static site generator, GitHub Actions deployment, Cloudflare caching, and R2 storage. Simple, stable, and cost-free.
Hugo(Pagermod)で記事にGitのコミット履歴から最終更新日を付与する
Host Google Fonts locally in Hugo without CDN dependency. Download woff2 files, configure CSS, and improve performance while maintaining GDPR compliance.
Die Normbox war ebenfalls eine auf dem Gateway-IV Mailboxsystem basierende Mailbox aus Berlin. Sie wurde vom Admin Garfield und Hugo lange Jahre betrieben.
Running a Hugo-based personal notes site as a Docker container on a Synology NAS, with DSM Container Manager handling the build and serving.
タイトルの通りです。 インプット・アウトプットを色々見直そうと思った一環なのですが、 しばらく触っていなかった Hugo (Static Site Generator) のテンプレートをあれこれ見直していたら、 なんだかよく分からない機能があれこれ増えていて、あるいはすっかり忘れてしまった機能もあったりしたので、改めて調べてみた記録です。 Hugo めっちゃ軽くて、 markdown や黒い画面とか触る人にはめっちゃおすすめな Static Site Generator なので、 使いたいけどよく分からない人は、こちらをさくっと読んでどんどん使っていったらいいと思います。 ページにどのような種類(Kind)があるか? まずページの種類を把握しないことにはなんともならないので、どういったものがあるか調べます。 Home Page トップページ トップページも結局リストなので、対応記事は存在しない Regular Pages 通常ページ、詳細ページ content/ 以下にある記事( sample.md とか tech/20200128.md とか)が1対1に紐づいて表示される Section List Pages セクション一覧ページ(カテゴリーとは異なる) content/ 以下にディレクトリを作ると、それがセクションとなる つまり2つ以上のセクションにまたがった記事は存在しない content/xxx/_index.md を作ることで、セクション一覧用の記事を作ることができる Taxonomy Terms Pages タクソノミー一覧ページ タクソノミーに属する記事一覧ページ いわゆるタグ一覧ページ、カテゴリー一覧ページ リストの対象が記事ではなく、タクソノミー自体の一覧 Taxonomy List Pages タクソノミーに属する記事一覧ページ タクソノミー一覧ページ いわゆるタグに属する記事一覧、カテゴリーに属する記事一覧がそれに相当する ちなみに categories, tags のタクソノミーは最初からある 2/13 追記: taxonomy と taxonomyTerm の説明が逆になっていたので修正(すみません・・・) ああ、この辺過去に理解したつもりだったけどすっかり忘れてました・・・。 特に セクションとカテゴリーを混同しやすい ので注意が必要かもしれません。 カテゴリーもタグと同じく複数のカテゴリーに属することができるので、どこか必ず一つにのみ属するものが必要なのであれば、セクションを活用すべきですね。
I set up a CI/CD pipeline to test my website for markup and rendering issues. It proved to be so useful that I can not imagine going back.
Migrating a Hugo blog from paid shared hosting to GitHub Pages with a custom domain and CDN, dropping the monthly bill from 30 dollars to zero.
After many years of running my site on Wordpress, I just migrated this site to Hugo. The migration was quite simple, this post outlines the main steps and offers a few helpful resources.
軽い気持ちで v0.17 あたりから最新にアップデートしたら 先日思わぬところではまったのでメモ。 (ちょうど Hugo 使ったものが直近で必要だったので焦りました・・・) 起きている事象 v0.19 以上の Hugo を利用して hugo server --buildDrafts などでページを見ていると、 詳細ページだけが確認できず ‘404 page not found’ になってしまう。 結論 各記事の上の frontmatter 内にある、 layout を削除すると正しく動作するようになります。 frontmatter から layout の記述を削除して 表示確認してから追加すると、 hugo server 動作中なら認識するけど、 落としてからまた hugo server 立ち上げると再び not found になってしまう・・・。 細かいこと Hugo ではコンテンツを content directory に格納し、 layout ごとに sub directory を作って格納します。 (誰かに突っ込まれる前に追記) layout ごとではなく section ですね、失礼しました。 詳しくはこっちに書いてあります。 Content organization Hugo assumes that the same structure that works to organize your source content is used to organize … gohugo.io
The art of getting rediscovered late in life—including how legendary acoustic guitarist John Fahey bounced back thanks to a 1994 Spin magazine feature.
Github から生成されるページって、バランスとかが良くてなんだかんだですごく読みやすいんですよ。 一方で自分のブログは、中身を WordPress から Hugo に変えて データベースの管理をしなくなって済んだところはすっきりしたものの、 当時そこ以外に時間をかけたくなく、見た目は古いままで移行したので、 自分で読んでてちょっと読みづらかったんですよね。 そこで、見た目をばっさり切り捨てつつ、以下を導入しました。 GitHub - sindresorhus/github-markdown-css: The minimal amount of CSS to replicate the GitHub Markdown style The minimal amount of CSS to replicate the GitHub Markdown style - sindresorhus/github-markdown-css github.com これをベースにして、メインコンテンツ幅やリンクの横並びの調整など、 本当に最小限の調整を行っただけなのですが、 時間かけずにいい感じになったので、しばらくこのままで行こうと思います。 本当に大事じゃないところに時間かけないの、大事だと思います。 ついでにトップページと一覧ページを分けました。 現状 Hugo を利用してブログ書いてるときに困る点、やってない点といえば、 画像の加工がめんどくさい 投稿してから追記した場合の日付管理(Hugo で .Lastmod を使う?) 古すぎますよ、という警告文表示(Static Site なので Hugo だけでは難しい?) ぐらいになったかと思います。
ちょっとしたメモも気軽に残せるので、WordPress から Hugo (というか Static Site Generator)に移行して本当に良かったですね。 Hugo の URL のカスタマイズに関して、ちょっと勘違いしてたのでメモっておきます。 Hugo で URL の設定が有効になる順番 各記事の content/post/foobar.md, frontmatter 内にある url = “/archives/foobar/” などの記述 config.toml 内にある permalinks の設定 まず WordPress から Hugo に移設した時点で、移設された記事には url = “/archives/1003” などのように 元々の URL がこちらの url の値に入ってくれるので、 こちらを元に移設前と同じ URL で問題なく表示してくれます。 ちなみに frontmatter というのは、記事の上にあるメタ情報一式がある部分のことです。(プラス3つの行で挟まれた部分のこと) うちのブログの場合は、元が WordPress の post テーブルに紐付いた形の連番になっていたので、 この /archives/1003 の数字の部分がけっこうな歯抜けになってました。 これをそのまま踏襲するのはちょっと考えにくかったため、 (それと1日に何記事も書くことはないというのもあって、) 新たに書いた記事からは /archives/yyyymmdd/ といった日付8桁になるように URL のルールを設けました。 こういった場合、大元の設定ファイルにきちんとパーマリンクの設定項目があるので、 そちらに沿ってルールを記載することで適切にパブリッシュされます。 URL management Control the structure and appearance of URLs through front matter entries and settings in your … gohugo.io
RSS の URL が変わってしまったので、一時的に元の URL に静的な RSS の XML ファイルをおいてますが、 => 置いたけどダメでした・・・ この記事以降の更新は反映されないので、以下より再取得していただければと思います。 ばうあーろぐ girigiribauer.com 例によって書いてない期間がどんどん開いていきますが、今は管理画面からではなく、Vim から記事を書いているのでだいぶ気分的にラクです。 さて、決して WordPress をディスるわけではないのですが、以下の点を何とかしたいなーと思ってました。 (たいして書かないのに)管理画面を晒し続けるセキュリティ面でのリスク 投稿するまでの心理的障壁 設置元サーバの整理 1.は巷でよく言われているのですが、個人ブログで表から見えるところに管理画面を置く必要性がどこまであるのか、最近かなり疑問に思えてきました。 しかも、たいして書かないのにずっとメンテナンスコストはかかるわけですよ。 2.もそれに付随するといえばそうなんですが、当然管理画面が表にあれば、ログインしてから記事を書くことになるわけです。もうなんだかブラウザ開いてログインして記事書いて・・・それすらも面倒になってきたんです。 3.が最後の決定打でした。 設置元のサーバを掃除して CentOS7 に変えつつ、プロビジョニングツールも併せて導入したかったのですが、 この個人ブログの整理をしてどこか別のサーバに退避する必要があり、 一応空きサーバはあったのでそちらにそのまま持って行っても良かったものの、 どうせ整理するなら Github Pages を利用してそっちで公開してもらおう、と思い立ったのでした。 もちろん Github Pages を利用すれば、そちらが落ちれば閲覧できなくなるリスクはあるものの、 めったにないし、あっても別に構わないので Github Pages を利用することに決めました。 上記の1~2から、もう**静的サイトジェネレータ(Static Site Generator)**の何らかを使うことはほぼ決まっていたのですが、 どうせ使うなら Hugo がいいなー Golang がいいなーと思い、WordPress から Hugo への移設を検討し始めました。 移設の条件 あれこれついでにやり始めると、例のごとく終わらずにほったらかしになってしまうので、移設の条件を定めました。 URL は可能な限りそのまま HTML/CSS/JavaSCript は極力いじらない(沼) Github ですべて管理 見た目いじらない、重要ですね。 気になるところは色々あれど、見た目やら構造やらをいじり始めるとキリが無いので今回は触りません。 あと必要最低限として URL は変えたくはないので、極力そのままで。