前者在某个大神主题中翻到，一句代码： 1共 {{ len (where .Site.RegularPages "Section" "posts") }} 篇文章 总字数没有现成参数，官方手册看到 .Scratch.Add 瞎折腾完成: 1{{$scratch := newScratch}} 2{{ range (where .Site.Pages "Kind" "page" )}} 3 {{$scratch.Add "total" .WordCount}} 4{{ end }} 新建了个参数累加所有文章的 .WordCount 字数，一般放 footer …

效果见文章底部，这些图片非手动一张张插入，文章头部一句 path: 2004gd 搞定！

直接看代码：

1{{ if .Params.path }}
2    {{$Path := .Params.path}}
3    {{- range (readDir (printf "%s%s" "./static/images/" $Path )) -}}<img loading='lazy' src="{{(printf "/images/%s/%s" $Path .Name ) | absURL}}" />{{- end -}}
4{{ end …

总有那么一瞬间特别特别想发一张照片，但不是以文章形式发布。

实现思路是程序自动遍历指定文件夹内的图片，并展示在一个页面上。有了思路，剩下的就是看文档、看文档、看文档，此功能利用 Hugo 的 readDir function 函数达成。

日常更新把图片丢到 static/photos 中即可（搭配 Github Action 自动化部署更香）：

1static
2└── photos
3    ├── 落樱缤纷.jpeg
4    ├── 想象中的自由.jpeg
5    └── 儿时登过顶的狮子山.jpeg

全站 Site

网址：.Site.BaseURL

标题：.Site.Title，示例：

1<a href="{{ $.Site.BaseURL }}">{{ $.Site.Title }}</a>

副标题：.Site.Params.description

关键词：.Site.Params.keywords

头部菜单：

1{{ range $.Site.Menus.main }}
2	<li><a href="{{ .URL }}">{{ .Name }}</a></li>
3{{ end }}

目前发文是直接在 Github 前端进行，Hugo 的构建交给 Github Actions 实现自动化部署。因此，产生个需求，文章里改个错别字什么的，能不能一键直达 GIthub 编辑页面？

1
2# Github 编辑页面链接
3https://github.com/tfnick/blog/edit/master/content/posts/coding/hugo-themes.md

起因，想给文章插入的 img 图片添加 loading='lazy'，果然有爱折腾的，看（这里），官方说明 #render-hook-templates，Hugo v0.62+

简单说能对md内的链接（link）和图像（image）自定义渲染，比如实现以上需求，只需在主题新建 layouts/_default/_markup/render-image.html

Docker实践指南

背景 互联网公司的技术团队管理通常分为2个方向：技术管理和团队管理，互联网公司的技术TL与传统软件公司的PM还是有很大的区别，传统软件公司的PM更多注重于对项目的管理包括项目任务拆解、项目进度以及风险等。对于多数互联网公司而言，技术TL更多的职责不再局限于项目角度，而是对业务与技术都要有深入的了解，就像黑夜里的灯塔，能够引导和修正团队成员前进的航向。综合技术和业务角度去深度思考问题，具备一定的前瞻性，并在技术领域投入持续的学习热情，向团队成员传道，补齐短板，提高整个团队的战斗力。 技术TL职责不仅需要制定日常规范，包括开发规范、流程规范等，推动规范的落地，以公有的强制约定来避免不必要的内耗，另外一多半的时间可能花在了开发任务分解分 …

前言 “架构制图”这词乍一听似乎有些晦涩，但如果提起“工程制图”，相信绝大部分工科背景的程序员们都不会陌生，甚至还能共同感慨下那些年一起伏在宿舍左手圆规，右手直尺，徒手作图到深夜的日子。 软件工程也是工程，因此传统工程制图的一些基本理论，在软件行业同样适用。但另一方面，软件与实体制造业之间还是有着本质区别，所以在制图方面的需求和方式也大相径庭，无法直接套用。作为软件行业的从业者，你可以完全不懂工程制图，但你不得不懂架构制图 —— 这是任何程序员职业生涯的的必修课。 本文在后半段将介绍如何用图去描述（describe）和传达（communicate）你的架构设计。值得强调的是，本文并不会侧重于单一的方法和工具，而是更希望关注那些优秀方 …

需要对接第三方的场景 第一类：自己需要做一件事情，但是纯靠自己要动用很多资源（产品、设计、开发、测试等），还要花较长的时间。如果恰好市面上有成熟的解决方案，我们完全可以把专业的活交给专业的人，利用他们的能力来解决自己的问题，同时让对方获得他们想要的，达到双赢。 举个例子，新启动一个电商平台，为了方便用户支付。一般会对接微信和支付宝，还要支持各家的银行卡做支付。这多家银行，一家家的对接、一家家的谈费率、一家家的联调、一家家的结算，想想都可怕。 如果此时正好有一家这样的公司，他们已经和这些银行最好了对接，并且提供标准化的接口，也支持后台去查流水记录。那完全就可以直接和他们合作，对接这家的系统。 第二类：自己不具备第三方的能力或者需要为第 …