好久没更新了，过完年之后就一直忙着写毕业论文，没什么时间来更新博客，甚至开源的项目有一些 issue 也拖了一个多月才处理。写论文真的是一件特别消耗精力的事，无穷无尽、机械重复的工作。现在已经基本上写好了，感觉自己的血槽都快空了，又有时间可以快乐写代码啦！

这期间虽然很忙，但每天还是会看一些文章，也有简单地记录，接下来应该会保持每周的更新啦！

文章

Estimating Square Roots in Your Head

一个简单估算平方根的方法，简单到甚至可以在脑海里就完成所有的计算。

这个算法是这样的：

假设要计算$n=33$的平方根，我们需要先找到一个数$g$，这个数的平方接近于33，例如我们选择$g=6$（因为$6^2=36$），然后我们需要计算$b=n/g=33/6=5.5$，则我们通过下面这个公式来估算33的平方根： $$ \sqrt{n}\approx\frac{g+b}{2} $$ 所以33的平方根就约等于5.75，和实际值的误差小于0.1%： $$ \sqrt{33}=5.74456264654\cdots\approx\frac{6+5.5}{2}=5.75 $$ 文中详细解释了这种估算方法的原理，感兴趣的可以到原文查看详细的解释。

Forking Chrome to render in a terminal

🔗Github 仓库：https://github.com/fathyb/carbonyl

可以先看作者的前一篇文章：Forking Chrome to turn HTML into SVG，这篇文章基于前一篇文章的基础，实现了在终端中使用 Chrome 来浏览网页。原理就是使用 ▄ (U+2584)符号来渲染页面，为其设置不同的前景色、背景色，并在对应的位置绘制该字符，来呈现原始网页，所以使用起来网页像是打了马赛克一样，但确实是在终端中可以使用的 Chrome 浏览器。

这篇博客给了完整的实现思路分析，也给出了演示视频，甚至可以在 Terminal 里面看 YouTube 视频，还挺 Cool 的，Github 仓库中作者 Release 了编译好的二进制文件，可以直接下载下来体验一下，支持 Linux 和 macOS。

例如我的博客在 Terminal 下看起来就是这个样子的：

The Guide To Responsive Design In 2023 and Beyond

这篇文章是对于响应式设计的思考，作者认为响应式设计不应该只是简单设置固定宽度的断点，而是要适应几乎任何设备尺寸。文中提到使用了例如 Bootstrap 等框架来构建响应式网站可能会局限开发者的思维，让开发者只思考三个断点：手机、平板和PC，但现实世界的情况下，并不只有这三种屏幕尺寸，因此，作者认为应该让容器和元素根据可用空间自动调整大小，而这就意味着需要考虑：Container queries、Wrapping、Element Sizing、Font sizes、Spacing、Available space 和 Logical properties 等。作者举例详细说明了应该怎么实现响应式设计。另外，作者认为除了响应式设计，还应该用户偏好，例如颜色模式、语言方向、交互方式等。

很有收获的一篇文章，另外也学到了 clamp() 这个 CSS 函数。

工具

用于生成 9-Patch 边框 CSS 代码的工具

链接：https://maxbittker.github.io/broider/

9-Patch 是 Android 上用于在不同屏幕尺寸和密度上实现可伸缩UI元素的技术，为图片指定可拉伸的 4 个边缘，然后这 4 个边缘的中心区域就可以根据需要进行拉伸或缩放，可以用于创建消息气泡。

这款工具则是用于生成 9-Patch 边框的 CSS 代码，生成的效果见下面的 CodePen，有时候拿来做一些特定的网页效果还不错：

See the Pen Border by LGiki (@lgiki-the-bold) on CodePen.

网站

全球 IMAX 及其他系统影厅分布

刷即刻刷到的一份在线文档，整理了 IMAX、CGS中国巨幕、DOLBY、CINITY 等各种影厅在全球的分布情况，详细到荧幕宽度、荧幕高度、座位数、开业时间、放映系统等数据全都有，真的很佩服这份文档的维护者们，整理这么一份表格真的很不容易。

Layoffs.fyi - Tech Layoff Tracker and Startup Layoff Lists

一个监测科技公司裁员的网站，看起来很可怕QAQ！

151 Illusions & Visual Phenomena with explanations

这个网站收集了 151 个视错觉图像 / 动画，并且每个视错觉图像 / 动画都配备了详细的解释。

纪录片

克拉克森的农场 第二季

期待了好久的纪录片终于上线了，特别喜欢看这种真实记录田园生活的纪录片，曾经也梦想过老了以后可以一人一狗一农田，日出而作，日落而息，但真的看到农场里的农民如何辛勤劳作、如何面对多变的天气之后，才会明白种田没有想象中的那么容易，也没有想象中的那么悠闲。需要面对很多很多的细碎繁琐的事情，并且天气真的是一点都不会在乎你的农作物，很推荐的一部纪录片，看完觉得很放松。

过年好！🧨🎇🎉

新的一年，希望大家都健健康康、平平安安、顺顺利利、红红火火！

最近的天气真的好冷好冷，敲代码的时候手都是冰冰凉凉的，特别生硬哈哈哈~

Anyway，这是这一周看到的东西啦！加入了更多丰富的东西，希望你会喜欢。

文章

Git Commands You Probably Do Not Need

学到了一些不太常用但还蛮有趣的 Git 指令，摘录了一部分。

Empty Commit：--allow-empty

空提交可以用于在不更改任何东西的时候重新触发一次 CI/CD 的构建，用法：

git commit --allow-empty -m "Initial commit"

Commit ranking

查看谁向存储库提交最多：

git shortlog -s -n --no-merges

输出结果：

567  Martin Øinæs Myrseth <myrseth@gmail.com>
322  Martin Øinæs Myrseth <mmyrseth@cisco.com>
142  Martin Myrseth <mm@myme.no>
 14  Martin Myrseth <myrseth@gmail.com>
  4  Martin Øinæs Myrseth <mm@myme.no>
  3  Martin Myrseth <myme@map>
  2  Martin Øinæs Myrseth <myme@Tuple.localdomain>
  2  Martin Øinæs Myrseth <myme@map.localdomain>

文中还有很多其他有趣的 Git 指令和例子，可以点击原文链接查看。

Bitwarden design flaw: Server side iterations

Bitwarden 通过单一的主密码来保护用户数据，Bitwarden 的服务器不应该知道用户的主密码，所以会派生出两个不同的值：

• 主密码的 Hash，用于验证用户是否被允许登陆
• 用于加密 / 解密数据的密钥

Bitwarden 的数据会受到 200,001 次的 PBKDF2 迭代：100,001 次在客户端、100,000 次在服务端。但是在 Bitwarden 安全白皮书中，服务端的 100,000 次 PBKDF2 迭代仅仅用于主密码的 Hash，而不是加解密数据的密钥。即：对于主密码 Hash 确实会经过 200,001 次 PBKDF2 迭代，但是对于加解密数据的密钥，只会经过 100,000 次 PBKDF2 迭代。

这就导致了一个问题，假设攻击者得到了你的 Bitwarden 数据副本并尝试对其进行解密，这时候，对于主密码 Hash 的爆破会很慢，因为主密码的 Hash 有 200,001 次的 PBKDF2 迭代，每一次计算都需要时间。但对于每次猜测，只需要派生出一个加解密密钥，并检查这个密钥是否可以解密数据就可以大大减少爆破需要的时间，因为加解密密钥只经过了 100,000 次 PBKDF2 迭代。

同时还有另一个问题，Bitwarden 所使用的迭代次数其实远低于 OWASP 推荐的迭代次数（OWASP，Open Web Application Security Project，是一个关注应用程序安全的基金会：https://owasp.org/，里面有一份关于应用程序安全的 Cheat Sheet 写得蛮详细的，有挺多有价值的信息：https://cheatsheetseries.owasp.org/）

如果你也在使用 Bitwarden 管理你的密码，可以到 https://vault.bitwarden.com/#/settings/security/security-keys 把迭代次数设置为 600,000 来提高安全性，这是 OWASP 推荐的迭代次数，对于大部分主流硬件，这个迭代次数都不会让用户感受到明显的卡顿。

工具

Spotify 推出的播客名称生成工具

🔗链接：https://podcast-name-generator.spotify.com/

逛 Product Hunt 时候发现 Spotify 推出了一款英文播客名称生成工具，点击页面上的按钮可以得到一个随机生成的英文播客名称 + 一段简短的介绍，页面的设计很有 Spotify 的味道，还蛮好看的，一些随机生成的英文播客名称也挺有趣的。

想起了另一个中文播客名称生成工具：https://get-podcast-name.vercel.app/

网站

Distill

本科时候发现的一个网站，通过动画和一些有趣的用户交互来介绍机器学习相关的知识，文章的质量都很高，让用户和文章中提到的内容进行交互或者是展示一个清晰易懂的动画，真的很大提升了用户体验，可以更容易理解作者想表达的意思。

但今天想起来的时候才发现网站已经无限期暂停更新了…希望未来还能再看到这个网站更新。 类似的，还有这个网站 https://ciechanow.ski/ 也有很多可以交互的有趣文章，例如这个网站上的 Sound、Mechanical Watch 这两篇文章都很有趣。

Wonders of Street View

一个随机展示奇特 Google 街景的网站，例如鲨鱼从天而降砸穿房顶、岩浆湖…

AI

MusicLM: Generating Music From Text

论文🔗：https://arxiv.org/abs/2301.11325

从接触到 Disco Diffusion 开始，就一直在想着 AI 生成音乐应该也不远了，果然，Google 团队就做出来了这个 MusicLM，可以通过文字描述，让 AI 来生成音乐，并且提供了多种不同的生成模式。在论文主页上可以收听用 MusicLM 生成的音乐样本，听起来感觉都还不错。

The Adventure of Penelope the Porcupine and the Land of Whimsy

用 ChatGPT 和 Midjourney 完成的一本儿童读物，看下来感觉还挺不错的，配的插图也都很精美，AI 在一定程度上真的已经能够取代一些人类的工作了。

小时候经常能在书店或者是学校旁的小商店看到一些廉价的儿童读物，有一些书里甚至会有一些离谱的文字错误、插图也不是十分精美，如果写一些脚本实现 AI 制作儿童读物、绘本的全流程，说不定可以量产这类儿童读物，并且质量也不差。

前端

:in-range 和 :out-of-range CSS 伪类

才知道原来 input 标签有 :in-range 和 :out-of-range 这两个 CSS 伪类，当 input 标签指定了 min 和 max 属性的时候，这两个伪类分别对应当用户输入的值在范围内和不在范围内，通过这两个伪类就可以在不借助 JavaScript 的情况下做出一个能根据用户输入内容是否合法自动改变样式的输入框，还挺好用的。

MDN 文档：

• https://developer.mozilla.org/en-US/docs/Web/CSS/:in-range
• https://developer.mozilla.org/en-US/docs/Web/CSS/:out-of-range

Can I Use 链接：https://caniuse.com/css-in-out-of-range

下面这个例子我把 min 设置为了 1，把 max 设置为了 10，因此，当你输入 1 的时候，输入框的背景色应该呈现绿色，当你输入 11 的时候，输入框将会自动变更为红色，Try it~

See the Pen in-range and out-of-range by LGiki (@lgiki-the-bold) on CodePen.

新的一年，想做一些有趣的新尝试，其中一个想法就是把每周阅读的一些有趣的文章记录并分享出来，类似于 Newsletter 的形式。

我每天打开电脑的第一件事就是看看 HackerNews，看到一些有趣的项目、文章会做一些记录，正好适合用来分享。

新的一年快到啦，提前祝大家新年快乐啦！🐰🧧🎉🎇

文章

For your next side project, make a browser extension

这篇文章的作者是浏览器插件 Twemex 的开发者，这个浏览器插件的功能是增强 Twitter 的搜索体验，安装好这个插件之后可以很方便地直接输入关键字来搜索某个用户历史发送过的推文、搜索你关注的人的推文，而不用去记忆 Twitter 搜索框的搜索语法。

这个浏览器插件最初只是作者为了满足自己的需求所开发的，因为他发现 Twitter 的搜索功能其实提供了很丰富的搜索指令，例如在关键词前面加上 from:xxx 就可以指定只搜索来自 xxx 的推文，但是 Twitter 并没有很明显地在搜索页面上告诉用户可以这么使用，也没有提供一个很方便的 UI，大多数用户并不知道这个功能，而作者自己平时在发表推文的时候，经常会使用这些高级搜索指令来搜索自己过往所发送的相关推文，于是他就开发了这么一个小插件。

但一开始他并没有进行什么推广，相反的，他只是偶尔会在自己的 Twitter 上分享这个插件的截图，然后就有人好奇地问他：我能否也使用这个插件。于是作者开始和这些用户沟通交流，了解他们的需求，逐步完善了自己所使用的这个插件，并通过 Twitter 召集了 100 多个感兴趣的用户，让他们成为首批测试人员，同时通过 Twitter 的 DM (Direct Messages) 和这些用户保持持续的沟通（作者这里提到，因为 DM 的非正式性，不需要像邮件、电话等联系方式那样每次都得写很正式的回复，这让他觉得很轻松，他可以通过 DM 同时处理好多人的问题）。

用户多起来之后，作者开始考虑优化这个插件的用户体验，他最先从 UI 开始润色，让插件使用起来像是 Twitter 原生就提供的功能一样，这样用户使用起来会觉得这个插件就应该是 Twitter 的一部分，减少插件被用户禁用、卸载的概率。

一年后，这个浏览器插件已经拥有超过 20k 的用户了，甚至有很多用户表示愿意为这个插件支付 5$ 每月的费用。后来一家专注构建 Twitter 相关产品的团队联系作者，收购了这个插件。

作者认为，从浏览器插件开始做自己的 Side Project 是一个不错的主意：

• 从 0 开始要创造出一个变革性的软件很困难，就算你想到了一个能改变世界的 idea，通常也需要冒很大的风险，付出巨大的努力才能成功。相反的，对现有软件的改进的想法却很容易想到，每个人或多或少都会抱怨自己日常所使用的软件有这样或那样的不足，这些抱怨汇集起来就足够形成一个插件的原始想法。

• 不需要投入太多的成本（作者称为"Easy operations"，但我理解为不需要投入太多的成本），浏览器插件的开发通常不需要有自己的服务器，也不需要考虑用户数据的存储。大多数时候，对某个现有产品的改进只需要利用现有产品提供的服务就足够了，基本上不需要部署服务器来存储数据，这就不用考虑很多很复杂的系统架构问题，也不需要考虑成本问题，只需要专注于插件功能的开发。

• 容易成长。相比于构建大型软件，构建浏览器插件可以很快速地从一个简单的想法、操作开始，很容易就能成长壮大。（类似于，有创意、有想法的时候先快速做一个MVP 出来验证自己的想法，验证成功之后再考虑后续的发展、壮大，能规避一些不必要的风险，也能快速验证自己的想法是否可靠）

但同时，浏览器插件也存在一些风险：

• 平台风险
  • 如果 Twitter 不喜欢，Twitter 随时可以让这个插件无法正常工作
  • Twitter 每天都在发生变化，插件需要不断进行修改来适应 Twitter 的变化
• Chrome 插件平台存在一些问题
  • Chrome 插件平台依赖于人工审查，人工审查具有很大的不确定性（审核时间的快慢、审核能否通过）
  • 我之前在博客里面提到的 Google 对于浏览器插件规范 Manifest V3 的推动，限制了浏览器插件的权限，导致浏览器插件能做的事变少了

我的一些想法：

• 作者的这个插件最初只是自用，也没有进行宣传，反而是在自己的社交媒体上发表推文而积累到用户的，作者的 Twitter 有 8k followers，平时多分享、多写一些有价值的东西，经营一个自己的社交账号真的蛮重要的，这些关注随时都可能给自己带来意想不到的惊喜
• 找准用户的痛点很重要，多和自己的用户沟通

The internet wants to be fragmented

这篇文章讲的是世界互联网正在变得越来越碎片化。

作者提到一个现象是 Facebook 和 Twitter 这类中心化的平台似乎越来越不受年轻人的喜爱，相反，Tiktok、YouTube、Snapchat、Instagram、WhatsApp、Signal、Discord 等 App 正在年轻人之间变得越来越流行。

Facebook 和 Twitter 的共同点是：中心化，平台上的内容会受管理者喜好的影响，例如 Elon Musk 可以随意 ban 掉批评他的记者的 Twitter 账户，言论并不总是自由的。

相反的，例如，TikTok 和 YouTube 更类似于电视、广播和传统的单向推送媒体，内容纯粹由算法驱动，而不是基于用户分享所驱动；Snapchat 和 Instagram 也更侧重于人与人之间的互动，而不是公共讨论，以及，即时通讯 App 也正在变得越来越流行。（我的理解：人们越来越趋向于使用一些更小尺度、更小众的社交媒体，在这样的社交媒体上人与人之间的联系更紧密，也更容易找到自己喜欢看的东西）

这些越来越流行的平台的共同点是碎片化 (fragmentation)，人们受够了中心化平台的各种争议、漫骂以及监管，转而走向更小的群体组织，例如可能是小众爱好的群体、志同道合的群体等，大家聚在一起，可以在这样的小众社区里互相分享自己的观点，大家都能看到自己想看的内容，如果哪天觉得不喜欢了，就可以随时转移到其他小社区里面。

现在的 Twitter 就像是一个城市的中心广场，而这些 app 就像一个个的小城镇。这反而回到了互联网最初的本质，是碎片化的，大家可以随时把自己的所知道的信息共享出来，不喜欢了也可以随时换到另一个地方。Disagreement in society is necessary for progress, but it’s most constructive when it’s mediated by bonds of trust and affinity and semi-privacy. Our boundaries will always rub up against each other, but we need some boundaries.

很喜欢题图中的一段话：

15 years ago, the internet was an escape from the real world. Now the real world is an escape from the internet.

We invested 10% to pay back tech debt; Here’s what happened

这篇文章，作者讲述了他们团队花费 10% 的时间用于偿还技术债的故事。

任何一个维护过一段时间的软件系统，都会随着时间的增加逐渐变得"腐烂"，这种现象被称为 bit rot 或 software entropy，具体表现有：

• MTBF (mean time between failure) 下降：软件的失败次数变得更加频繁
• LT (lead time) 增加：implementation, review, deploy 和 release 所需的时间，会随着时间的增加而不断增加
• 效率下降：$\frac{价值}{付出}$ 的比例不断降低
• TTR (time to repair or remedy) 增加：修复软件中的缺陷并确保它不会再次发生所需要的时间变长
• TTFC (time to first commit) 增加：用于衡量新人加入代码库的效率的指标之一

而引起这些问题的原因一般是：

• 外部：runtime、操作系统、依赖可能随着时间不断发生着变化，开发者需要不断适应这些变化
• 内部：错误、config drift、技术债务
• 混合：需求的变化速度过快

作者的团队有开发并维护着两个大型的全栈应用程序，每个应用程序都有 +180K SLOC，但项目的领导并不关心代码质量，往往偷工减料，跳过测试，只要能按时交付即可，这让这些程序变得摇摇欲坠。

最终项目的开发者和管理层沟通，确定花 10% 的时间专门用于解决技术债务。从此，每隔一周，程序员们就会举行一次 “Tech Debt Friday” 活动，在这一天里，不能做一些常规的需求，而是专门用于处理技术债务。

随着时间推移，这项 “Tech Debt Friday” 活动对作者所在团队的回报是巨大的：

1. 他们很快偿还了技术债务，通常不会超过 10 天
2. 他们可以一起调查代码库，并了解代码的历史，而不用按照某种固定的流程
3. 可以有时间整理文档，标注一些不会重构或删除的内容
4. 可以做一些更有意义的事情，例如改进测试、linting 或者是 CI/CD 管道，来防止错误或者降低错误成本
5. 通过团队成员直接的协作处理好技术债之后，他们能够更快地完成他们日常的常规工作，因为他们在处理技术债的时候，对代码有了更集体性的理解
6. 代码的设计和架构变得更加清晰，使得他们能够在时间紧急的时刻做出更好的判断
7. 这种管理层对开发者的提供的自由和信任提升了团队精神
8. 公司的其他团队也开始试验 “Tech Debt Friday”

20 Things I’ve Learned in my 20 Years as a Software Engineer

1. I still don’t know very much

   在软件领域，无论往哪个方向看，都有广阔的知识远景，并且在日益扩大。

   这意味着不同的人在相同的职业生涯中度过数十年，仍可能产生巨大的知识差距。

   越早意识到这一点，就能越早开始乐于向他人学习和教导其他人。

2. The hardest part of software is building the right thing

   你可以设计出世界上技术最令人印象深刻的东西，但却没有人愿意使用它。

   设计软件主要是一种倾听的活动，我们需要成为软件工程师、心理学家和人类学家。

   在软件设计过程中的投资，无论是通过专门的用户体验团队还是通过简单的自学，都将带来巨大的回报。

3. The best software engineers think like designers

   伟大的工程师会深入思考他们代码的用户体验问题。把用户的需求放在心上，是好的用户体验的核心。

4. The best code is no code, or code you don’t have to maintain

5. Software is a means to an end

   任何软件工程师的主要工作都是交付价值。

6. Sometimes you have to stop sharpening the saw, and just start cutting shit

   有些人倾向于跳进问题中，直接开始写代码。

   另一些人则倾向于研究，并陷入分析瘫痪。

   在这些情况下，为自己设定一个期限，然后就开始探索解决方案。当你开始解决问题时，你会很快学到更多东西，这将引导你迭代出一个更好的解决方案。

7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system

8. Every system eventually sucks, get over it

9. Nobody asks “why” enough

10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers

11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be

    对自己的工具或者如何构建软件没有任何意见的工程师是很让人担心的。作者说他宁愿有人给他一些"我不同意"的意见，也不想要有人和他说"我没有意见"。积极寻找别人如何使用与你不同的工具和技术来完成任务，能很快提高你的技术水平。

12. People don’t really want innovation

    人们经常谈论创新，但他们通常寻找的是廉价的胜利和新奇感。

    如果你真正进行创新，并且改变人们做事的方式，预计会有大量的负面反馈。

    如果你相信你正在做的事情，并且知道它将真正改善一些事情，那么请做好准备迎接一场漫长的战斗。

13. Your data is the most important part of your system

    系统中的数据可能会比代码还更长寿，花时间和经历保持数据的有序和规整，从长远来看会有很好的回报。

14. Look for technological sharks

15. Don’t mistake humility for ignorance

16. Software engineers should write regularly

    软件工程师应该定期写博客、写日记、写文档，做任何需要保持书面沟通技巧的事情。

    写作可以帮助思考问题，并帮助自己更有效地与团队和未来的自己沟通。

    良好的书面沟通技巧是任何软件工程师都需要掌握的最重要的技能之一。

17. Keep your processes as lean as possible

18. Software engineers, like all humans, need to feel ownership

19. Interviews are almost worthless for telling how good of a team member someone will be

    面试的最好只是用于了解某人是谁，以及他们对某个专业领域的兴趣如何。试图弄清楚他们将来会是一个多么好的团队成员是没用的，因为没有人会在面试的时候告诉你：他们不可靠、滥用职权、华而不实，或者从不按时出席会议。

20. Always strive to build a smaller system

视频

PaperPaul YouTube Channel

发现一个立体折纸爱好者的 Youtube Channel 叫 PaperPaul，里面有个视频展示了很多他喜欢的立体折纸作品，都设计得十分巧妙：