网络文章@202310

每个人每天都只有24小时，希望我的选择真的是我的选择 | 枫言枫语

可是人生并不是一个与外部竞争的游戏啊。英国纽卡斯尔大学的行为科学教授 Daniel Nettle (丹尼尔·列托)在 2005 年出版的 Happiness: The Science Behind Your Smile （简体译为《追究幸福：微笑中的科学》）提出的观点我十分认同：幸福并不主要产生于这个世界，而是来自于对待这个世界的方式。

也就是说，通过向外的追寻，比较，竞争，我们再怎么努力也追不到真正的幸福。刷短视频可以满足一时的娱乐放松，但无限刷短视频刷不来真正的快乐。在多巴胺的刺激下，我们“想要”更多不确定的内容，“想要”看看下一个短视频是什么，但“想要”不等于喜爱。

有一次我跟朋友聊天，我提到冥想与前面几本书。他说这几部作品的逻辑都源自佛教，并推荐我阅读斯里兰卡德宝法师(Henepola Gunaratana)的作品: Mindfulness in Plain English（简体译为《观呼吸》）。这是一本针对禅修方法的指南，冥想是其中一种。有些人可能是抱着“学习放松的方法”的想法来学习正念，但在佛教禅修当中，冥想并不仅仅是放松，放松只是它带来的副作用之一罢了。德宝法师的这本书，书如其名，In Plain English，非常平易近人，是学习冥想的人非常适合的读物。

现代社会因为科技的发展带动经济、政治、文化的社会变革，在我们有生之年的观测窗口，可见变化速率呈上升趋势。这种巨变随着全球化的进展让全世界多数国家都面对相似的问题。东亚国家的发展时间比西方国家更短，于是产生的“压缩的现代性”问题更加突出。

个体处于巨变当中，一方面要面临“传统规范”与“自由新世界”的拉扯，渴望自由的同时又期望获得传统的保护；另一方面要面对个人内心的发展，在浪潮汹涌的现代向内探索，寻找坚实的立足点。

带着几万年前就定型的大脑与身体，我们要穿越现代社会种种诱惑与陷阱，要排除外部世界的强大势力加持下的欲望施加（尤其是来自消费社会的外部势力），要从自己的内心寻得出自己真正想要的人生。

这并不容易，但可以做到。

首先要从随波逐流中抽离出来反观自己，哪怕最终作出的选择结果是一样的，但随大流的选择和自己仔细思考过后的选择，其主动性却截然不同。然后要在向内探索的过程中，通过训练与实践，逐步建立“我的想法能行”的自信心，慢慢具备探索未知世界的勇气。最后在勇敢的试错中，弯弯曲曲地走出属于自己的人生道路。

人生是自己的。每个人每天都只有24小时。

选择做什么是我的选择，但我希望确保真的是我的选择。

The limited value of a computer science education - thoughts from the red planet - thoughts from the red planet — 计算机科学教育的有限价值 - 来自红色星球的思想 - 来自红色星球的思想

Of course there are some fields for which having a computer science education is much more relevant on a daily basis – distributed systems is one that comes to mind. But even in that field, the vast majority of your work is forming good abstractions and avoiding complexity – those two crucial skills that you don't learn in a computer science education. The benefits of a computer science education are limited to the value you get out of a small percentage of situations. For me those situations were very high value, but most programmers don't even run into them.

当然，在某些领域，计算机科学教育在日常工作中更为重要——分布式系统是我想到的一个。但即使在这个领域，你的绝大多数工作都是形成良好的抽象和避免复杂性——这是你在计算机科学教育中没有学到的两项关键技能。计算机科学教育的好处仅限于您从一小部分情况下获得的价值。对我来说，这些情况非常有价值，但大多数程序员甚至没有遇到过它们。

In my experience, the only way to become a good programmer is to do it… a lot. Reading books and taking classes won't make you a better programmer – they might provide some guidance, but real improvement will come from the grueling hours you put into real projects. I could read books all day about how to execute a perfect barrel roll, but it will all be meaningless until I put on a parachute and get in the cockpit. Programming is the same way.

根据我的经验，成为一名优秀程序员的唯一方法就是这样做……好多。读书和上课不会让你成为一个更好的程序员——它们可能会提供一些指导，但真正的进步将来自你在实际项目中投入的艰苦时间。我可以整天阅读有关如何执行完美桶滚的书籍，但在我戴上降落伞并进入驾驶舱之前，这一切都毫无意义。编程也是同样的方式。

Overall I have mixed feelings about the value of a computer science education, mostly because of the personal benefit I have gotten from mine. For most cases though, I think it is severely overvalued. It's very strange to observe an industry with major talent shortages, and then to know perfectly good self-taught programmers get prematurely rejected in interviews because they don't have a computer science background. I hope to see the industry improve in this respect, but in the meantime I'm happy to exploit this imbalance as a competitive advantage.

总的来说，我对计算机科学教育的价值有着复杂的感觉，主要是因为我从我那里得到了个人利益。但在大多数情况下，我认为它被严重高估了。观察一个人才严重短缺的行业，然后知道完全优秀的自学成才的程序员在面试中过早被拒绝，因为他们没有计算机科学背景，这是非常奇怪的。我希望看到行业在这方面有所改善，但与此同时，我很高兴利用这种不平衡作为竞争优势。

How becoming a pilot made me a better programmer - thoughts from the red planet - thoughts from the red planet — 成为一名飞行员如何让我成为一名更好的程序员 - 来自红色星球的想法 - 来自红色星球的想法

In software I don't think anything is treated more like a black box than the database. Programmers want to store and retrieve data using the database interface and then leave it to the ops guys to get it running robustly. However, a database's interface only tells a small part of what it means to use that database, and there's a lot of crucial information it doesn't tell you. Which queries will run efficiently? Which queries will consume large amounts of resources? What happens if there are hardware failures? If one application has a bug that triggers an accidental denial-of-service attack on the database, what will happen to other applications? Will just the one application fail, or will it trigger a larger cascading failure? If the database is distributed, how is data partitioned among nodes? What happens when there is data skew?

在软件中，我认为任何东西都比数据库更像黑匣子。程序员希望使用数据库接口存储和检索数据，然后将其留给运维人员以使其稳健运行。但是，数据库的界面只告诉了使用该数据库的一小部分含义，并且有很多关键信息没有告诉您。哪些查询将高效运行？哪些查询会消耗大量资源？如果出现硬件故障会怎样？如果一个应用程序存在触发对数据库的意外拒绝服务攻击的错误，那么其他应用程序会发生什么情况？只会一个应用程序失败，还是会触发更大的级联故障？如果数据库是分布式的，如何在节点之间对数据进行分区？当存在数据倾斜时会发生什么？

Understanding the answers to these questions is critical to architecting robust systems, and you need to know how the database works to answer them effectively. When you understand the mechanisms underlying the databases you use, you understand their limits and failure modes much better, and you can use this knowledge to architect better systems.

了解这些问题的答案对于构建健壮的系统至关重要，您需要了解数据库如何工作以有效地回答这些问题。当您了解所使用的数据库的基础机制时，您就会更好地理解它们的限制和故障模式，并且您可以使用这些知识来构建更好的系统。

There's an even bigger reason to understand how your tools work. Too many programmers treat their tools like LEGO DUPLO pieces and limit solutions to how those tools can be used and combined. But when you understand how your tools work, then you can reason in terms of what would be the ideal solution if ideal tools existed. Software becomes clay instead of LEGOs. Something I've found repeatedly in my career is the languages, databases, and other tools we use are so far removed from ideal that the opportunities for fundamental innovation are constant. Thinking this way led me directly to creating Storm, Cascalog, and ElephantDB, all of which gave myself and my team huge leverage. Even when constructing the ideal tools yourself isn't practical, knowing what would be ideal is hugely helpful when evaluating possible solutions.

了解您的工具如何工作还有一个更大的原因。太多的程序员将他们的工具视为乐高得宝碎片，并将解决方案限制为如何使用和组合这些工具。但是，当您了解工具的工作原理时，您可以推断如果存在理想的工具，那么理想的解决方案是什么。软件变成了粘土而不是乐高。在我的职业生涯中，我反复发现，我们使用的语言、数据库和其他工具与理想相去甚远，以至于基础创新的机会是不断的。这种想法促使我直接创建了Storm，Cascalog和ElephantDB，所有这些都给了我自己和我的团队巨大的影响力。即使自己构建理想的工具并不切实际，在评估可能的解决方案时，了解什么是理想的工具也非常有帮助。

I'm a big fan of Martin Thompson's term "mechanical sympathy". The kind of high performance work he's known for is absolutely impossible without a deep understanding of implementation. And performance optimization in general is much easier the more you understand the implementation of your dependencies.

我是马丁·汤普森（Martin Thompson）的“机械同情”一词的忠实粉丝。如果没有对实施的深刻理解，他所熟知的那种高性能工作是绝对不可能完成的。一般来说，您越了解依赖项的实现，性能优化就越容易。

If you read my last post about the limited value of computer science educations, you might think I'm contradicting myself by arguing for understanding the internals of your dependencies. After all, that's a major focus of a computer science education. My answer is I advocate for a computer science education for programmers to the same extent I advocate for an aeronautical engineering degree for pilots. The degrees are relevant, useful, and helpful, but on their own do little to make you a good programmer or a good pilot. You can learn how your tools work, oftentimes much more effectively, in the trenches as opposed to on a whiteboard. Where abstract education pays its dividends is when you push the boundaries of your field. The deep problem solving and algorithm skills I gained from my computer science education helped me greatly in that regard, and if I were a test pilot I imagine a formal aeronautical engineering education would be essential.

如果你读过我上一篇关于计算机科学教育价值有限的文章，你可能会认为我主张理解你的依赖的内部结构是在自相矛盾。毕竟，这是计算机科学教育的一个主要焦点。我的回答是，我提倡对程序员进行计算机科学教育，就像我主张为飞行员提供航空工程学位一样。这些学位是相关的、有用的和有用的，但就它们本身并不能让你成为一个好的程序员或一个好的飞行员。您可以了解工具的工作原理，通常更有效，在战壕中而不是在白板上。抽象教育的红利在于你突破你的领域的界限。我从计算机科学教育中获得的深层次的问题解决和算法技能在这方面帮助了我很大，如果我是一名试飞员，我想正规的航空工程教育是必不可少的。

When I construct software now, I don't consider any part of what I build to be robust unless I can verify it with measurements in production. I've seen way too many crazy things happen in production to believe testing is sufficient to making software robust. Monitoring is critical to finding how the expectation of production behavior differs from the reality. Making the expected properties of software measurable is not always easy, and it often has major effects on software design. For this reason I account for it in all stages of the development process.

当我现在构建软件时，我不认为我构建的任何部分都是健壮的，除非我可以通过生产中的测量来验证它。我见过太多疯狂的事情发生在生产中，以至于相信测试足以使软件健壮。监控对于发现生产行为的期望与现实有何不同至关重要。使软件的预期属性可测量并不总是那么容易，它通常会对软件设计产生重大影响。出于这个原因，我在开发过程的所有阶段都考虑到了这一点。

This can be captured as a general philosophy of life: consistently find ways to get outside your comfort zone and do things that challenge and frustrate you. Besides learning new things, you'll become better at everything you do because of the surprising overlaps of knowledge. The most extreme example of this for me happened three years ago when I did standup comedy for three months straight. The lessons I learned from standup have been invaluable in improving my skill as a technical speaker. And surprisingly, it's helped me become a better writer as well.

这可以概括为一种一般的人生哲学：始终如一地想办法走出你的舒适区，做一些挑战和挫败你的事情。除了学习新事物之外，由于知识的惊人重叠，您所做的一切都会变得更好。对我来说，最极端的例子发生在三年前，当时我连续三个月做单口喜剧。我从站立中学到的经验教训对于提高我作为技术演讲者的技能非常宝贵。令人惊讶的是，它也帮助我成为一名更好的作家。

Recipe for a great programmer - thoughts from the red planet - thoughts from the red planet — 一个伟大程序员的秘诀 - 来自红色星球的想法 - 来自红色星球的想法 

- Pick an editor 选择一个编辑器
- Choose a project beyond current capabilities. Good ways to push boundaries:
    选择一个超出当前功能的项目。突破界限的好方法：
    - Unfamiliar domain (e.g. large scale data processing, UI programming, high performance computing, games)
        不熟悉的领域（例如大规模数据处理、UI 编程、高性能计算、游戏）
    - Exotic programming language
        异国情调的编程语言
    - Larger in scope than any project before
        范围比之前的任何项目都大

When stuck:  卡住时：
    Paste stack traces into Google
    将堆栈跟踪粘贴到谷歌中
    Find appropriate mailing list to get guidance
    查找合适的邮件列表以获取指导
    Realize that real learning happens when you are stuck, uncomfortable, and/or frustrated
    意识到真正的学习发生在你陷入困境、不舒服和/或沮丧的时候
    Seek out books, classes, or other resources AFTER you have a good understanding of your deficiencies
    在你对自己的不足有很好的了解之后，寻找书籍、课程或其他资源

Is sequential IO dead in the era of the NVMe drive? — Jack Vanlightly — 在 NVMe 驱动器时代，顺序 IO 是否已经死亡？- 杰克·范莱特利

顺序IO在SSD上面依然有效，不过这种有效只是针对SSD GC的某种优化，可以让GC负载更小一些。

纯粹从设计角度上来看，看上去顺序IO其实是没啥必要了。你看这个DB为了顺序IO设计出来的LSM，带来了多少写放大，可能还不如BTree来的实在。

Buying the seller — 购买卖家

This in-person encounter made me reflect on modern commerce. How impersonal it is most of the time. Which is probably more efficient, and, as an introvert, preferable much of the time. I usually would rather deal with a web form than a salesperson, but it's different when you can establish a connection to someone actually running the show.

这次面对面的相遇让我反思了现代商业。大多数时候它是多么没有人情味。哪个可能更有效率，而且，作为一个内向的人，大多数时候更可取。我通常更愿意处理网络表单而不是销售人员，但是当您可以与实际运行节目的人建立联系时，情况就不同了。

This is one of those unique advantages available to small and medium-sized businesses, and any type of startup. You can far more easily cultivate and maintain these personal connections. Make the exceptions when that's needed. Be available when it matters. And by doing so, you allow your customers to buy the seller rather than just the product or service. That's a powerful advantage, especially in commodity markets (like payment processing or podcast hosting!).

这是中小型企业和任何类型的初创公司可获得的独特优势之一。您可以更轻松地培养和维护这些人际关系。在需要时例外。在关键时刻随时待命。通过这样做，您可以让您的客户购买卖家，而不仅仅是产品或服务。这是一个强大的优势，尤其是在商品市场（如支付处理或播客托管！

This also represents an opportunity for buyers to directly vote with their wallet for what they'd like to see more of in this world. I'd like to see more businesses run by people like Tom or Bryan, so I've voted for their success with my dollars. It feels good.

这也为买家提供了一个机会，可以直接用他们的钱包投票选出他们希望在这个世界上看到更多的东西。我希望看到更多像汤姆或布莱恩这样的人经营的企业，所以我用我的钱投票支持他们的成功。感觉很好。

投资中的节奏与结构

所以生活中的诸多烦恼，很多是因为我们误判了问题的节奏性和结构性，进而做出错误的行为：该面对的时候没有面对，该坚持的时候没有坚持。

工业革命能不能继续下去？今天看来很简单的问题，当年却受到社会广泛质疑。27 年里，瓦特一步步改良他的蒸汽机，但整个社会层面的质疑从来没有停止过。1781 年，蒸汽机的效率大幅提升，依然有知名化学家质疑能源消耗太大、效率太低。所以如果我们回顾科技发展史，革命性产品从来不是想象中的灵光一现或万众瞩目。科技发展史从来都是以年为单位的日拱一卒。

如果我们在场的创业者、投资人生活在那个时代，都把时间精力花在追逐蒸汽机每天的改良上，我们注定是焦虑的，就像我们今天专注在大模型的进展上一样。因为回头来看，这些都是节奏性问题，我们真正应该花时间的是思考这些科技带给整个社会的结构性改变。

退回 1763 年，你是创业者，你是投资人，你真的需要关注蒸汽机有什么进展吗？真的需要关注效率和能耗问题吗？这些问题真的重要吗？今天在场的每一个人真正应该花时间去思考：我是纺织业的人，还是零售行业的人。在巨大的浪潮里，社会的结构性机会到底是什么？

所以太多人强调科技的节奏性问题，而忽略了社会的结构性变化。

What scientists must know about hardware to write fast code 科学家必须了解有关硬件的知识才能编写快速代码

挺好的内容，就是没有时间看：)不过好像新东西也不是很多的那种。

We tried that, didn’t work — 我们尝试过，但没有成功

In our quest for making programming simpler, faster, and prettier, no logical fallacy provides as much of an obstacle as “we tried that, didn’t work”. The fallacy that past failed attempts dictates the scope of what's possible.

在我们追求让编程更简单、更快、更漂亮的过程中，没有什么逻辑谬误能像“我们尝试过，但没有成功”那样成为最大的障碍。过去失败的尝试决定了可能性的范围，这是一个谬论。

That just because someone, somewhere, one time attempted something similar and failed, nobody else should try. That lowering our collective ambition to whatever was unachievable by others is somehow good.

仅仅因为某人在某个地方曾经尝试过类似的事情但失败了，那么其他人就不应该尝试。将我们的集体野心降低到其他人无法实现的目标上，这在某种程度上是件好事。

There would be no human progress if we all quit trying after any unsuccessful attempt.

如果我们在任何不成功的尝试之后都放弃尝试，就不会有人类进步。

This fallacy is bad enough when it talks about what hasn’t yet successfully been achieved, but it’s downright bewildering when it’s trotted out to refute the reality of what’s already been proven possible.

当它谈论尚未成功实现的事情时，这种谬论已经够糟糕的了，但当它被用来反驳已经被证明可能的现实时，它就完全令人困惑了。

That's how progress usually happens! By someone doing something different than whoever went before them in pursuit of the same goal. But instead of recognizing that, and perhaps becoming just a bit curious at how it was done, the "we tried that, didn't work" fallacy sucks people into the small world of "can't".

进步通常就是这样发生的！一个人为了追求同一目标而做一些与之前的人不同的事情。但是，“我们尝试过，但没有成功”的谬论并没有认识到这一点，也许只是对它是如何做到的感到有点好奇，而是将人们带入了“不能”的小世界。

Making programming better requires a willingness to test your priors. To question your assumptions. To recognize the half-life of facts. Yes, how we built HEY wasn't feasible prior to 2020, before import maps opened the door. So if your mental model of the web is soaked in the possibilities of 2010-2020, I understand your skepticism, but please don't let it restrict your ability to appreciate the progress happening now.

让编程变得更好需要愿意测试你的先验知识。质疑你的假设。认识事实的半衰期。是的，在 2020 年之前，在导入地图打开大门之前，我们构建 HEY 的方式是不可行的。因此，如果您对网络的心理模型沉浸在 2010-2020 年的可能性中，我理解您的怀疑，但请不要让它限制您欣赏现在正在发生的进步的能力。

How to speed up range joins joins in Snowflake by 300x — 如何将 Snowflake 中的范围连接速度加快 300 倍

大概看懂了意思，就是如果是范围连接的话：

  1. 将范围首先映射成为一个unique id
  2. 然后在范围连接之前，首先使用unique id来做等值连接
  3. 等值连接完成之后其实就可以排除了大部分数据，之后的范围连接就比较快
  4. 这里的假设就是等值连接比范围连接要快。

Surprising Scalability of Multitenancy - Marc's Blog — 多租户令人惊讶的可扩展性 - Marc 的博客

When most folks talk about the economics of cloud systems, their focus is on automatically scaling for long-term seasonality: changes on the order of days (_fewer people buy things at night_), weeks (_fewer people visit the resort on weekdays_), seasons, and holidays. Scaling for this kind of seasonality is useful and important, but there's another factor that can be even more important and is often overlooked: short-term peak-to-average. Roughly speaking, the cost of a system scales with its (short-term1) peak traffic, but for most applications the value the system generates scales with the (long-term) average traffic.

当大多数人谈论云系统的经济性时，他们的重点是针对长期季节性的自动扩展：按天（晚上买东西的人减少）、周（工作日访问度假村的人减少）、季节变化和假期。针对这种季节性进行调整是有用且重要的，但还有另一个因素可能更重要且经常被忽视：短期峰值与平均值。粗略地说，系统的成本随其（短期 1 ）峰值流量而变化，但对于大多数应用程序来说，系统产生的价值随（长期）平均流量而变化。

The gap between "paying for peak" and "earning on average" is critical to understand how the economics of large-scale cloud systems differ from traditional single-tenant systems. “支付高峰费用”和“平均收入”之间的差距对于理解大规模云系统的经济性与传统单租户系统有何不同至关重要。

It's important because multi-tenancy (i.e. running a lot of different workloads on the same system) very effectively reduces the peak-to-average ratio that the overall system sees. This is highly beneficial for two reasons. The first-order reason is that it improves the economics of the underlying system, by bringing costs (proportional to peak) closer to value (proportional to average). The second-order benefit, and the one that is most directly beneficial to cloud customers, is that it allows individual workloads to have higher peaks without breaking the economics of the system.

这很重要，因为多租户（即在同一系统上运行许多不同的工作负载）非常有效地降低了整个系统的峰值与平均比率。由于两个原因，这是非常有益的。第一个原因是它通过使成本（与峰值成比例）更接近价值（与平均值成比例）来改善基础系统的经济性。第二个好处，也是对云客户最直接有利的好处，是它允许单个工作负载拥有更高的峰值，而不会破坏系统的经济性。

Most people would call that scalability.

大多数人会称之为可扩展性。

Andy makes a lot of interesting point here, but the key one has got to do with the difference between the per object heat distribution, the per aggregate heat distribution, and the system-wide heat distribution.

安迪在这里提出了很多有趣的观点，但关键的一点与每个对象的热量分布、每个聚合的热量分布和系统范围的热量分布之间的差异有关。

Scale allows us to deliver performance for customers that would otherwise be prohibitive to build.

规模使我们能够为客户提供原本难以实现的性能。

Here, Andy is talking about that second-order benefit. By spreading customers workloads over large numbers of storage devices, S3 is able to support individual workloads with peak-to-average ratios that would be prohibitively expensive in any other architecture. Importantly, this happens without increasing the peak-to-average of the overall system, and so comes without additional cost to customers or the operator.

在这里，安迪谈论的是二阶效益。通过将客户工作负载分散到大量存储设备上，S3 能够以峰值平均比支持单个工作负载，而这在任何其他架构中都极其昂贵。重要的是，这种情况的发生不会增加整个系统的峰均比，因此不会给客户或运营商带来额外成本。

On the future of cloud services and BYOC — Jack Vanlightly

下面是ChatGPT的总结内容，我觉得写的挺好的。BYOC安全性和可控性相比SaaS要好点，但是这种安全性本质上还是比较低的，BYOC上的代码其实可以做许多事情。BYOC的运行成本，网络复杂性，以及计费方式其实都比SaaS要复杂许多，感觉对于中小客户来说，SaaS应该是更好的选择。对于大客户，如果运行服务的公司足够reliable的话，那么其实选择SaaS本身没有什么安全问题。

下面是对这篇文章的总结

BYOC（Bring Your Own Cloud）的概念

BYOC的承诺和挑战

BYOC的安全性

BYOC的网络复杂性和成本

BYOC的成本承诺

以下是一些关于SaaS相对于BYOC的优势的讨论：

安全性

运营效率

责任边界的明确性

网络复杂性和成本

成本和计费

枫影夜读 #186 胡安焉 – 《我在北京送快递》 | 枫言枫语

胡安焉过去从事的工作虽无文字表达的需求，但也有些工作有大量的空余时间，比如他开服装店的时候，闲下来的时间他做了大量阅读，后来赋闲在家，亦拿起笔来多有创作。是以作者文笔流畅，在书中时有精辟见解，颇为好读，更时有收获。虽然作者自觉本作更侧重“记录”而非“严肃创作”，但有时这种随笔写作反而更显真实。而作者多年来在社会中摸爬滚打，写下之文字平淡间透着辛酸，令人感慨世间不易的同时亦觉无可奈何。

比如在德邦物流，面试完的人，男的会被安排三天无薪倒包工作，女的则去打包。这是作者所在组最繁重的工作，作者以为：

“只有在工作强度最大的岗位上，双方才能看清彼此是否合适，从而减少因为误解而产生的没合作多久就‘分手’的情况。”

此见足显作者多年江湖经验。

又比如有一位身材瘦小的女孩被送来试工，其实这样的人不太适合这份工作，手脚慢还会拖累全组。组长叮嘱大家不要帮她。

“越是她这样弱不禁风的人，我们越不能帮，因为帮她无异于误导她，令她以为自己可以胜任。必须让她吃足苦头，若最后她还是觉得自己能干，那才是真的能干。”

这些经验与道理无疑同“理想世界人人平等”，或象牙塔中崇尚的互帮互助格格不入。但这才是这个纷繁复杂的世界真实运作的方式。无论在哪一个岗位上，强行“帮助”不适合这个环境的人，也许在经济上行阶段，世界尚有余力可以“包容”，可一旦潮水退去，裸泳者终将醒目无比。

云风的 BLOG: 桌面游戏的分类

所有在桌面玩的游戏都算作桌面游戏。几乎所有的人都玩过，比如象棋、围棋、扑克。如果不计这些传统的抽象游戏，我玩现代桌面游戏已经有十多年了。过去，是和朋友一起玩，而最近几年，更多的是和家人（小孩）一起玩。和许多不玩现代桌游的人想象的不一样，虽然电子游戏脱胎于桌面游戏，但桌面游戏却并没有被淘汰，反而一直在推陈出新，每年都有许多新的佳作面世。

玩桌游这么些年，我发现桌游其实可以分出几个子类。像我这些各种桌游都玩的玩家很多，但有相当一部分人专注于特别一个子类，对其它类的桌游兴趣不大。有时，隐隐觉得不同子类之间还有一些鄙视链存在。

我们很多时候提到桌游，并不指大多数人都会玩的棋牌（象棋、扑克、麻将等）。其实，这些的确和在桌游店里玩到的桌游有很大的不同，它们历史悠久，早已没有知识版权的保护。这类棋牌游戏可算作桌面游戏的一个大的子类，即抽象类桌游。可以说，人人都是桌游玩家，想在身边找出一个从没玩过棋牌的人恐怕很难。但也不是所有抽象类游戏都是古老的棋牌，也有很多近年类的新作相当有趣。比如我很喜欢的 Azul （花砖物语）就在家经常开。

我们还可以把专门为 6 岁以下儿童玩的桌游归为另一个子类，儿童类桌游。如果成人玩这些游戏的话，恐怕会因为缺乏挑战而索然无味。我家娃还小的时候，我有几年特别关注这类游戏，想带着娃玩。如果娃太小的话，多半只能玩玩物理类的游戏、敲砖块、搭积木之类。现在娃大了，这些游戏早就束之高阁。一些供成人玩的著名桌游有时也会把规则裁剪掉，出一些儿童版本：卡坦岛、卡卡颂、石器时代这些都有儿童版。

当娃大一点，在家就有很多游戏可以选择了。这类游戏往往会贴上家庭游戏的标签。另一种是朋友聚会活跃气氛的聚会类游戏。在 boardgamegeek 上，家庭游戏和聚会游戏是两个大的分类。我觉得没必要分开。风靡一时的狼人杀、三国杀、剧本杀等一系列杀就是聚会游戏的典型。酒吧里的骰子游戏（同时也是一种抽象类游戏）也是这类游戏中最为普及的。说起杀人类游戏，我最喜欢的是抵抗组织：阿瓦隆，规则严谨，玩起来颇有策略性。

另一个大的子类是（卡牌）构筑类游戏。最著名的就是万智牌。这类游戏通常需要玩家在当局游戏外（购买）收集卡牌，构筑自己的牌库，然后再和对手玩游戏。也有一些不和对手玩，而是单人或协作性质的。也未必是卡牌的形式，像战锤系列，就需要玩家在游戏外收集大量的军队模型。这类游戏颇有深度，单款游戏就可以玩上数年甚至十年以上。

还有一个小众的群体是兵棋。它有通常包括设计好的地图、推演用的抽象棋子、以及整套推演规则。通过回合制进行战争模拟。它现在甚至在真实战争中实战应用，而不仅仅停留在桌游游戏中。兵棋玩起来繁杂，入坑不易，如果桌游有鄙视链的话，这算是鄙视链顶端的存在。现在也有一些对兵棋轻量化的改良，例如战争之道 Battle Lore 我就挺喜欢的。

最接近大部分电脑游戏的桌游是 RPG 。为了和电脑游戏区分开，现在通常把桌面上进行的称为 TRPG 。这种游戏往往是围绕一个故事主题展开，玩家按故事背景设计规则，扮演故事中的角色。这类玩家把玩游戏称为跑团。但我觉得还有许多桌游也可以归到这个子类中。例如，瘟疫危机的传承版，也可以一组人长期玩下去（可以连续玩上十多盘，持续几个月时间）；近年来还有像魔镇惊魂 Arkham horror 这样的组队一起玩的主题游戏也可以归为此类。

剩下的就是花样繁多的策略类桌游了。也有人称它们为德式桌游，欧式桌游等。它们的特点就是单局几十分钟到数小时，每局游戏之间相互独立，需要使用策略来玩。大部分属于对抗性游戏，参与的玩家之间有胜有负。也有一部分游戏是相互协作性质的，共同达成目标。如果不想和人打交道，或找不到玩友，也有不少游戏设计有单人模式，一个人就可以挑战系统。关于这部分桌游，五花八门，往下还可以再细分更多分类。等下次再从桌游的游戏机制方面展开来谈。

如果高效学习有什么秘诀的话，那就都在这里了：)

不要完美主义

仔细想，这种“完美主义害死人”的例子特别多。我看到过很多同学，其实是在学习的路上，被自己的“完美主义”逼得“放弃了”——由于学习中有一点没有做好，遭受到了一点点挫折，最终就放弃了整个学习计划。每个人都一定要接受自己的不完美。想开一点：我们都不是小升初考了满分，才能上初中的；也不是中考考了满分，才能读高中的；更不是高考考了满分，才能念大学的；将来也不会是大学所有科目都是满分，才能出来工作。不完美其实是常态，根本不会影响我们学习更多更深入的内容。但是在自学过程中，很多同学却要求自己在自己制定的每一步计划中都达到“完美”，才进行下一步。最终结果，通常都是“放弃”。

不要过度“学习路径依赖”，学习要冲着自己的目标去。

现在信息太发达了，对于大多数领域的知识，网上会有很多所谓的“学习路径”。我不是说这些学习路径没有用，但是不能“过度”依赖这些所谓的学习路径。

比如，很多同学想学机器学习，大多数学习路径都会告诉你，机器学习需要数学基础。于是，很多同学就转而学习数学去了，非要先把数学学好再去学机器学习。可是发现数学怎么也学不好（在这里，可能完美主义的毛病又犯了），而机器学习却一点儿都没学。最终放弃了机器学习，非常可惜。其实，如果真正去接触机器学习，就会发现，至少在入门阶段，机器学习对数学的要求没有那么高。正因为如此，我一直建议：只要你在本科接触过高数，线数，概率这些科目的基础概念，想学机器学习，就去直接学习机器学习。学习过程中发现自己的数学不够用，再回头补数学。在这种情况下，数学学习得也更有目标性，其实效果更好。在这里，我忍不住要打一个我的课程广告，入门机器学习不妨尝试我在慕课网的《Python3入门机器学习》，学过的同学都说好：)

不要迷信权威的“好”教材。

不是说权威教材不好，而是每一本教材都有其预设的读者群，如果你不在这个预设的读者群的范畴里，教材再好也没用。最简单的例子：再好的高数教材，对于小学生来说，都是一堆废纸。

我经常举的一个例子是《算法导论》。我个人建议如果你是研究生或者博士生，已经有了一定的算法底子，才应该去阅读《算法导论》。但是对大多数本科同学，尤其是第一次接触算法的同学，《算法导论》实在不是一个好的教材。但很可惜，很多同学在学习中有上面的两个毛病，既过度路径依赖，别人说《算法导论》好，学习算法要走学《算法导论》这个路径，自己就不探索其他更适合自己的学习路径了，一头扎进《算法导论》里；同时还“完美主义”的倾向，对于《算法导论》的前几章，学习的事无巨细，但其实接触了很多在初学算法时没必要学习的内容。最后终于觉得自己学不下去了，放弃了对“算法”整个学科的学习。认为算法太难了。

诚然，算法不容易，但是，一上来就抱着《算法导论》啃，实在是选择了一条完全没必要的，更难的，甚至可能是根本走不通的路。对于一个领域的学习，了解市面上有什么好的教材是必要的，单也不能迷信权威教材。每个人必须要去探索学习如何寻找适合自己的学习材料。

不要看不起“薄薄”的“傻”教材，这些你看不起的学习材料，可能是你入门某个领域的关键。

很多同学问我最初学习算法的是什么教材，我告诉他们是这本教材：《算法设计与分析基础》。在这里，我完全没有推荐这本教材的意思。事实上，现在我有点儿“鄙视”这本教材。因为我在学习它的过程中，发现这本教材有很多错误（帮助它纠正错误其实也提高了我的水平：）当然，现在这本书的版本可能也和我当时学习的版本不同了，大部分错误应该已经纠正了。)但它确实是我的一本很重要的算法启蒙教材。关键原因是，它够薄。

在大多数时候，如果有人问我教材推荐，基本上我的回答都是，如果是入门水平：随便找一本在京东，亚马逊，豆瓣上，评分不太差的“薄”的教材，就ok了。在这里，关键字是够“薄”。因为“薄”的教材能让你以最快的速度看完，对整个学科有一个全盘的认识：这个领域是做什么的？解决什么问题了？整体解决问题的思路是怎样？解决问题的方法大致是怎样划分的？一些最基础的方法具体是怎样的。这些在初学阶段是至关重要！是让你全盘把握整个领域脉络的。虽然通过这么一本薄薄的教材，你的脉络把握肯定不够全面细致，但比没有强太多！我看过不少同学，一上来学习《算法导论》，关于复杂度分析的笔记做了好几页，然后就放弃了，可是连什么是动态规划都不知道。这样完全没有对“算法”这个领域有全面的认识，甚至可以说根本没有学过“算法”！先用薄教材入门，再找“厚”教材，细细体会其中的细节，是我百试不爽的学习方法。

不要迷信单一教材

很多同学非要我推荐一本具体的“薄”教材入门，说实话，很多时候让我有点儿哭笑不得。因为我随便推荐一本，我确实不敢保证它是“最好的”，“最适合你的”，但是各个领域那么多教材，我又不可能都一一看过，一一比较过。最最重要的是，我的学习经验告诉我，在大多数情况下，学习不是一本固定教材可以搞定的。非要找到一本“最适合自己的”教材，然后就一头扎进去，其实是不科学的。我印象很深刻，我读本科的时候，那会儿申请了一个项目，要做一个网站（那时候服务端都用ASP.NET），我一口气从图书馆借了10本ASP.NET的教材，然后以一本最薄的书为主干去看，发现这本书介绍不清楚的概念，马上就从其他书里找答案。通常不同的作者对同一个事物从不同的角度做解读，是能够帮助你更深刻的认识一个概念的。基本上一个月的时间，我就从一个完全的网站搭建小白，做出了这个项目需要的那个网站。这个习惯我一直延续，研究生的时候，对什么领域感兴趣了，第一件事就是到图书馆，借十本相关书籍回来翻看。

但是，大多数同学喜欢仅仅扎进一本书里，一旦选定了自己的学习材料，就对其他材料充耳不闻，甚至是排斥的心理。这种做法，一方面又是“完美主义”的表现——非要把这本教材学透；另一方面，其实也是“犯懒”的表现，不愿意多翻翻，多看看，自己多比较比较，自己去寻找最适合自己的材料，一味地盲目相信所谓“大神”的推荐，殊不知，这些推荐，不一定是更适合自己的材料；更何况，还有很多大神，明明是靠不出名的“薄”教材入的门，但给别人做推荐的时候，就突然变成自己是算法奇才，自幼阅读《算法导论》而所成的神话了：)