作者因为吸毒贩毒入狱，幸运地转到了一个较好的监狱，使得他可以把更多的时间花在自己身上，然后他重新学习编程，还找到了工作，文章叙述了他的故事。

监狱的特点是，它有自己的亚文化、自己的行话、自己的道德观。

这种思维模式被严格执行到每一个生活在监狱里的人身上，在这样的消极氛围中度过几年，任何人都会有所改变。

Source

我之前已经接受了我的命运，因为当你被判 10 年以上刑期时，你必须接受命运，否则你就会发疯，不断思考你本可以做什么不同的事情，或者你本可以在生活中做什么。

Source

我认为这突出了一个事实，那就是你不能抓住别人不给你的机会…

Source

作者重读了一遍很早以前买的《Mac 编程傻瓜》，多年回头看，发现里面依然有各种问题，但是最终他还是按照书里的内容完成了一个程序。

因此，我把 Mac编程傻瓜 放在书架上，以提醒自己。挫折、困惑和坚持。兴奋、创造、个人计算。

这也提醒我，永远不要把自己看得太重，因为无论我在过去 25 年里学到了多少东西，这句话永远都是真理：我第一次学习编程是从一本傻瓜的书中。

Source

作者认为注释是重要的，并且对注释进行了分类。

之前在 Weekly#11 中分享的 文学编程 也是类似的观点，要反转代码和文档/注释的关系，让文档变成主角。

Weekly#12 中也分享过类似的话: we can say that writing code is sharing the experience of understanding the requirements/implementation.

总而言之就是要提高代码的可读性，为以后读代码的人着想（这个人很可能也是自己），提供多一些信息，减少别人阅读代码的认知负担。

编写注释对于生成良好的代码至关重要，因为这样的代码从长远来看是可维护的，而且在修改和调试过程中，其他人和作者都可以理解。

并非每个人都这么认为。许多人认为，如果代码足够扎实，注释是没有用的。

他们的想法是，如果一切都设计得很好，代码本身就能记录代码在做什么，因此代码注释是多余的。

我不同意这种观点，主要有两个原因：

1.许多注释并不解释代码在做什么。它们解释的是你无法从代码所做的事情中理解的东西。

通常，这些缺失的信息是代码为什么要做某个动作，或者为什么要做一些显而易见的事情，而不是其他感觉更自然的事情。

2.虽然逐行记录代码在做什么一般不会有什么用处，因为只要读一读就能理解， 但编写可读代码的一个关键目标是降低读者在阅读代码时的工作量和需要考虑的细节数量。

因此，对我来说，注释可以成为降低读者认知负荷的工具。

Source

FUNCTION COMMENTS

函数注释的目的首先是防止读者阅读代码。相反，在阅读注释后，应该可以将某些代码视为一个黑盒子，应该遵守某些规则。

DESIGN COMMENTS

函数注释 "通常位于函数的开头，而 "设计注释 "通常位于文件的开头。设计注释基本上说明了某段代码如何以及为何使用某些算法、技术、技巧和实现方式。它是对代码中实现内容的高层次概述。

WHY COMMENTS

为什么注释要解释代码做某些事情的原因，即使代码正在做的事情非常清楚。

TEACHER COMMENTS

教师评论并不试图解释代码本身或我们应该注意的某些副作用。相反，他们教授的是代码运行的领域（例如数学、计算机图形学、网络、统计学、复杂数据结构），这可能是读者技能范围之外的领域，或者只是因为细节太多而无法从记忆中回忆起所有细节。

CHECKLIST COMMENTS

有时由于语言限制、设计问题，或者仅仅是由于系统中自然产生的复杂性，不可能将某个概念或界面集中在一块，因此代码中有些地方会告诉你要记住在代码的其他地方做事情。

GUIDE COMMENT

引导注释的作用只有一个：照看读者，帮助读者处理源代码中的内容，提供明确的分工、节奏，并介绍您将要阅读的内容。指南注释存在的唯一理由就是降低程序员阅读代码时的认知负荷。

TRIVIAL COMMENTS

琐碎注释是指阅读注释的认知负荷与阅读相关代码的认知负荷相同或更高的指导性注释。

DEBT COMMENTS

债务注释是硬编码在源代码本身中的技术债务声明。FIXME、TODO、XXX、"This is a hack" 等都是债务注释。一般来说，这些注释并不是很好，我尽量避免使用它们，但这并不总是可能的，有时与其永远忘记某个问题，我更愿意在源代码中加入一个节点。

BACKUP COMMENTS

备份注释是指开发人员对某些代码块甚至整个函数的旧版本进行注释，因为她或他对新版本中操作的变更缺乏安全感。

注释就像是橡皮鸭调试，只不过你不是在和橡皮鸭对话，而是在和代码的未来读者对话，他们比橡皮鸭更可怕，而且会使用 Twitter。

Source

你可能认为写注释是一种不太高尚的工作形式。毕竟你会编码！

但是，请考虑一下：代码是一组语句和函数调用，或者不管你的编程范式是什么。

老实说，如果代码不好，这些语句有时并没有什么意义。

注释要求始终有一定的设计过程，并从更深的意义上理解你正在编写的代码。

此外，为了写出好的注释，你必须提高自己的写作技巧。同样的写作技巧也有助于你撰写电子邮件、文档、设计文件、博文和提交信息。

我之所以写代码，是因为我有一种分享和交流的迫切感。我喜欢写注释，就像我喜欢写代码一样。

Source

作者例举了一些应该摒弃的命名，像是普朗克常数，这种以发现者的名字命名的，如果对于相关领域不熟悉，就不知道是什么。

更好的是用几个名词和形容词描述清楚，通过名字就让人知道大概是什么东西。

一个好的名称应能传达一个基本概念的精髓，通常是通过几个精心挑选的名词和形容词。

例如，广度优先搜索和深度优先搜索的信息量非常大。

如果我们称它们为 "Zuse's method" 和 "Tremaux approch"，除非我已经是一名科学历史学家，对每位发明者的各自领域了如指掌，否则根本无法表达出这两种方法的任何信息。

Source

编程中也需要注意良好的命名，还是那句经典名言：

There are only two hard things in Computer Science: cache invalidation and naming things.

在自测的时候，往往需要造数据，无论是接口的，还是页面上输入的。

但是为了偷懒，我测试时，输入的更多的一些无意义的内容，例如名字我会图方便，输入 1111 等。

问题是，这些随便输入的数据，当需要去调试的时候，容易让你分不清是什么，那么多个 1111，什么是名字，什么是地址，什么是备注？

所以，对待测试数据，也应该像代码一样认真对待，注释，文档也是如此。

什么是代码，什么是数据，是用户输入的数据？是运行时生成的数据？应该一目了然。

你在测试，你在调试。你最不希望的就是在查看日志、错误信息或正在试用的用户界面时分不清什么是什么。

数据应该在你看第一眼就能告诉你，你看到的是自己输入的数据，还是默认值，或是系统中漂浮的其他东西。

Source

一个抽象概念的好坏，取决于它能否掩盖其背后的复杂性。想想真正伟大的抽象，比如 TCP。

尽管 TCP 建立在不可靠的 IP 协议之上，但它能帮助我们假装拥有可靠的通信渠道。

它承担了纠错、重传和数据包排序的复杂性，使我们不必如此。

这就是伟大抽象的标志。它让我们在操作时，仿佛底层的复杂性根本不存在。

我们利用它的好处，而抽象则让我们看不到、想不到那些困难的东西。

但是，那些糟糕的抽象呢–或许更准确地说，那些伪装成抽象的间接层呢？

这些“抽象”并没有隐藏任何复杂性：它们往往只是增加了一层，而这一层的意义完全来自于它应该抽象的东西。

想一想函数上的一层薄薄的包装，它没有增加任何行为，却增加了一层额外的导航层。

有句名言："所有的抽象概念都会泄露"这是真的。无论多好的抽象，最终都会遇到需要了解底层实现细节的情况。

下一次当你使用抽象概念时，请扪心自问：这样做真的能简化系统吗？还是只是多了一层间接？

明智地使用抽象，记住–如果你没有真正隐藏复杂性，你只是在增加复杂性。

在《无责任机器》中，丹·戴维斯认为，组织形成了“责任沉没”，这些组织吸收或模糊决策的后果，以至于没有人能对此直接负责。

举个例子：

一家酒店公司的高层决定减少清洁人员的数量，因为这能改善某个资产负债表上的数字。

后来，当你试图办理入住时，房间还没准备好，接待员也无法告诉你何时能入住；

他们可以提供一张代金券，但你需要的是一个房间。

没有人可以投诉，也无法与那个遥远的领导沟通，告诉他们你的计划被搁置了。

责任被吞没在一个空洞中，永远消失。

Source

如果把这两个框架结合起来，就可以得出这样的结论：要对某件事负责，你就必须拥有改变它的权力和理解你这样做的目的是什么。

Source

如果以后都是人工智能做的决定，那出了问题，找谁去问责呢？

保持善良是内心的一种看世界的状态或角度。

保持善良是一种看世界的心态吧，友好待人，多些宽容，多些换位思考，多些理解。

但保持善良也不是任人欺负，想起王尔德《忠实的朋友》的故事，汉斯老实得被磨面师害死了，太不值得了。

之前看得一篇关于开源的文章 (Setting expectations for open source participation) 也有类似的观点，就是保持善意：

当你把应该被视为善举的行为扩大到所有行为时，就会产生一个有趣的效果，那就是当事情没有发生时，没有人再有理由生气或沮丧。

虽然您仍然有权期望受到善待（这是您对他人的善意所应作出的反应），但一旦您放弃了对即将发生的事情的任何预设，事情对每个人的压力都会大大降低。

而当压力减少时，人们往往会有更多的动力去帮助别人，因为整个局面对所有参与者来说都会变得更加愉快。

Source.

“更多”图标意味着选项更多，但又不会占用额外空间。

它们充当导航指南，让用户放心的轻点一下，即可获得更多功能。

... 有横向的和纵向的。

• 横向排列相对于纵向，给人的感觉更积极
• 横向占据空间比纵向多，有的时候空间比较少的时候，可以考虑用纵向
• 横向可以用于主要页面的更多，纵向可以用于次要页面的更多，形成主次
• 考虑页面的清晰/简介，是否和其他类似元素存在重叠，决定使用什么元素

手机上的一些单手操作例子。

现在手机上的单手操作都是类似的，用户已经形成了习惯，如果自己实现的时候，要注意保持用户交互的一致性，避免增加用户的认知成本。

一个使用技巧，设置 border-radius: inherit; 让内部元素继承圆角，这样 background 就不会溢出了。

比在父元素使用 overflow: hidden; 要好，能避免一些 overflow 裁切的问题。

<style>
.Card {
  max-width: 20rem;
  border: 2px solid black;
  border-radius: 2rem;
}

.Inner {
  padding: 1rem;
  background-color: pink;
}
</style>
<div class="Card">
  <div class="Inner">Some content</div>
</div

<style>
.Card {
  max-width: 20rem;
  border: 2px solid black;
  border-radius: 2rem;
}

.Inner {
  padding: 1rem;
  background-color: pink;
  /** 设置内部元素，继承圆角 */
  border-radius: inherit;
}
</style>
<div class="Card">
  <div class="Inner">Some content</div>
</div

书里的目录包括章节和页码，章节和页码之间一般会用 "…." 去填充空白，方便读者对应章节和页码。

文章讲述了如何实现这样的目录，同时考虑页面的响应性。

| <--                max available width              --> | .page ↴
  ┌─[ .chapter ]────────────────────────────────────────────┐ ┌─────┐
  │ ┌─[ text ]───────────────────────────────────────────── │ │     │
  │ │ "The first line of my very very verrrrry long chapter │ │     │
  │ └────────────────────────────────────────────────────── │ │     │
  │ ──────────────────┐ ┌─[ .chapter::after ]───────────────┐ │     │
  │  title overflows" │ │ free space for the dot leaders    │ │ 123 │
  │ ──────────────────┘ │ (overflow limits to .chapter box) │ │     │
  └─────────────────────┊───────────────────────────────────┊ └─────┘
                        ┊       »invisible dots land«       ┊
                        └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘

一个用来制作原型的应用，组件都是手绘风格的，它的理念是：

Focus on the idea. Don't waste time on style and layout.

因为是手绘风格，所以你可以不用那么注重低保真，而是把注意力放在想法表达上。