ECS 中的消息发布订阅机制
这篇讲的是作者在用Lua实现ECS框架时，如何解决“周期性状态迭代”与“响应式事件处理”之间的矛盾，并最终引入一套完备的消息发布订阅机制。 作者从实践中发现，纯粹的游戏循环难以高效处理复杂外部输入。因此，他最初刻意在ECS中回避事件系统，将内部事件都转化为状态变化。但这并不完全符合游戏混合型业务的本质。 于是，他决定为框架增加消息发布订阅模块。核心实现非常灵活：每条消息都是一个Lua table构成的键值对，例如 `{ type = "mouse", action = "move", x = 100 }`。系统通过 `world:pub` 发布，任何System则通过一个模式（pattern）来订阅感兴趣的消息，比如订阅所有 `type="new"` 的消息，或者只订阅特定实体的状态变化。 巧妙之处在于其性能优化思路。作者没有选择简单的遍历匹配，而是在订阅时建立索引缓存。发布时，先根据消息中的各个条件快速排除不相关的订阅者，大幅减少了比较次数。这种用空间换时间的策略，让消息分发效率更高。文章也探讨了面对复杂条件可能导致的缓存膨胀问题，为后续优化留下了空间。
用户调研之微软产品反应卡片
这篇讲的是微软在2002年推出的一种专门测量产品“合意性”的用户调研方法，叫做“产品反应卡片”。 它的核心操作非常直观：给用户一套包含118个情感词汇的卡片，比如“有吸引力的”、“令人挫败的”、“创新的”等等，让用户在体验产品或设计后，挑选出他们认为最能描述的词语，并解释选择的理由。这个方法跳出了单纯的功能可用性测试，直接捕捉用户对产品的情绪反应和整体感受。 从文章提供的完整词汇列表来看，这118张卡片覆盖了从积极到消极的广泛情感光谱，能帮助团队快速定位设计在用户心中引发的复杂情绪，而不仅仅是“好用”或“不好用”。它非常适合在产品原型或早期设计阶段使用，用来评估设计的方向是否与期望传递的品牌感或体验目标一致。
六大标志性的开源形象概览
这篇文章认为，强大的品牌形象对于开源项目至关重要，它能帮助项目与商业软件竞争，并让人记住和信任。作者从六个标志性的开源吉祥物/Logo出发，讲述了它们背后的故事和品牌塑造的思考。 比如Linux那只憨态可掬的企鹅Tux，灵感竟来自Linus Torvalds被企鹅咬了一口后的喜爱；Firefox Logo中的“火狐”实则是中国的小熊猫，其命名和形象经历过多次变更与专业设计；而GIMP那只名为Wilber的奇幻生物，其物种设定甚至引发了社区长达数十年的热烈讨论。 PostgreSQL的大象Slonik象征着“让人印象深刻”，VLC的橙色交通锥筒则充满了校园趣闻与法兰西风情，甚至会在圣诞节悄悄戴上红帽子。这些案例共同说明，一个设计得当的Logo或吉祥物，能将项目的理念与个性凝聚成符号，成为开源社区宝贵的视觉资产。 文末，作者也热情邀请读者分享自己心中最爱或最令人印象深刻的开源品牌。
使用 gka 一键生成帧动画
这篇介绍了一个名为 gka 的开源工具，旨在解决前端开发者在处理序列帧动画时的手工繁琐问题。传统做法下，从设计师拿到一组图，需要手动重命名文件、计算 CSS keyframes 百分比，若使用合图还得逐帧计算位置数据，一旦设计稿修改，整个过程就变得异常痛苦。 gka 提供了一键式的解决方案。你只需提供图片文件夹路径和前缀，它就能自动完成批量重命名、生成对应的 CSS 动画代码以及预览 HTML 文件。工具的核心优势在于其性能优化，内置了图片压缩、合图模式以及相同帧复用功能，能有效减小最终体积。同时，它支持多种输出模板，灵活性强。 从文中的示例可以看出，运行一条简单的命令后，工具能迅速输出一个包含预览页、CSS 文件和规范图片的整洁文件夹。它把设计师交付的、杂乱的图片序列，高效地转化成了可直接部署的动画代码，显著节省了前端开发者的重复劳动时间。
聊聊设计模式（4）：装饰模式
这篇文章讲的是设计模式中看起来简单却容易把代码搞复杂的“装饰模式”。作者从四个核心角色——抽象构件、具体构件、抽象装饰类、具体装饰类——的定义出发，指出了这个模式的易错点。 随后，文章通过一个代码发布平台迁移的实际案例，清晰展示了为何需要装饰模式。原本只需简单“发布”的代码平台，随着业务发展，需要依次加入构建、测试、日志、安全监测等新功能。如果不断修改原有类，代码会迅速膨胀失控。而装饰模式允许我们像“穿衣服”一样，动态地将新功能（具体装饰类）一层层叠加到核心对象（具体构件）上，既不修改原有代码，又能灵活扩展。 值得注意的是，文章还介绍了 ECMAScript 2017 新增的修饰器语法。它通过 `@` 符号从语言层面简化了传统装饰模式的实现，掩盖了复杂的包装类结构，让代码更直观。作者通过一个“激活”电子狗能力的例子，生动说明了这种新语法如何让装饰逻辑一目了然。 总的来说，这篇文章不仅解析了装饰模式的“是什么”和“怎么用”，更通过场景演进深入浅出地阐释了“为什么用”，帮助开发者理解如何通过组合而非继承来优雅地扩展对象功能。
Python创建单例模式的三种方式
这篇文章聚焦于Python中实现单例模式的常见方案，对比了三种不同的技术路径。作者从实际编码场景出发，展示了如何通过装饰器、基类继承与元类编程这三种方式来确保一个类仅存在唯一实例。 具体来看，三种方法各有特点。使用装饰器时，核心是通过一个外层函数维护一个实例字典，逻辑直观，易于理解。基于基类的方法则重写了对象创建的入口`__new__`方法，通过检查并缓存实例属性来保证唯一性，这种方式更贴近面向对象的直观理解。而利用元类的方式最为“底层”，它重写了`__call__`方法，在类被调用创建对象时进行拦截和控制，其设计思想更具全局性和侵入性。 文章的价值不仅在于展示代码，更在于清晰地勾勒出不同方案的实现逻辑与适用场景。选择装饰器通常更灵活轻量；使用基类则提供了标准的继承约束；而元类方式虽然强大，但也可能增加系统的复杂度。对于开发者而言，理解这些差异有助于在具体项目中权衡简洁性、可读性与架构影响，做出合适的技术选型。
消费领域的挤牙膏效应：沉迷网游后的一点心得
作者以自己近期沉迷一款免费手游的经历为引子，探讨了消费领域中普遍存在的“挤牙膏效应”。文章从对比《聚爆》这类优秀买断制游戏与国内免费游戏内购模式的差异切入，核心观点在于：无论是游戏中的VIP等级设计（从首充60元到累积数万元），还是现实中的摩拜单车押金、付费阅读、轻奢消费等，都依赖于精心设计的“小额消费”来持续吸引并绑定用户。 作者发现，这种模式成功的关键在于，它为那些无力承担巨额消费（如买房）的中间阶层提供了一种可负担的、能够彰显“存在感”的路径。游戏通过累充好礼和可控的战力差距保持用户粘性，社会则通过层出不穷的新潮小额消费维持人们的参与感。但文章也指出，这种模式存在风险：当小额消费带来的新鲜感消退、存在感变得麻木时，无论是游戏还是更广泛的社会消费，都可能面临“断崖式下跌”。最后，文章以幽默口吻自嘲沉迷网游，实则完成了对一种普遍消费心理与模式的冷静观察。
排行榜奖金的发放方法
这篇讲的是游戏《流星庄园》排行榜钻石奖励规则被玩家利用、进而推导出一套更优设计方案的过程。 作者从实际漏洞出发，指出原有设计——在固定名次奖励基础上额外奖励“名次提升”——存在根本矛盾。由于玩家社群能够沟通协作，他们发现与其激烈竞争高名次，不如协调一致地交替升降名次，从而反复“提升”来获取更多系统奖励，甚至在低排名区也能无中生有地获利。 针对此问题，作者提出了一个核心思路是“固定奖金池”的改进方案。新规则将所有预期发放的钻石锁定为一个总量，用于奖励当前排名。同时，引入了一套“超越者”激励机制：每个公会的奖金，会根据本周有多少上周排名低于它的公会反超自己，而被按比例扣除；扣除的这部分奖金，将再奖励给那些成功超越别人的公会。 这个设计的巧妙之处在于，它把总支出控制在预算内，同时让“超越”行为本身能直接获得对家扣除的奖励。如此一来，玩家博弈的焦点从操纵排名变化，转向了在固定规则下进行真实的实力竞争，从而实现了设计初衷。
最可怕的产品经理
这篇文章从产品经理这个角色的演变谈起，探讨了“最可怕的产品经理”这一有趣命题。作者认为，在当今以用户和设计驱动的时代，产品经理肩负着从产品特征、设计实现到用户心理的全链条责任，甚至决定产品的生死。 文章的核心观点聚焦于两种让程序员“闻风丧胆”的产品经理：一种是设计出身，对产品功能和UI要求精确到每一个像素，会逼迫开发100%还原设计稿；另一种则是技术出身，当被告知某功能无法实现时，他们可能直接丢来一段代码问“这样行不行”。这两种产品经理，一种在审美上极致严苛，一种在技术上深不可测，都构成了对开发团队的巨大挑战。 作者以幽默而犀利的笔触指出，这种“可怕”恰恰是产品的幸运——有挑战才有提升，他们会逼迫团队拿出最好的努力。文章最后还点出了产品经理“品位”的重要性，并以一句调侃收尾，提醒从业者持续学习与反思。
产品设计师的前世今生
这是一篇关于设计行业演变的观点文。作者从上世纪五六十年代杂志行业的变革出发，梳理了设计头衔的变迁史——从“艺术指导”到“交互设计师”，再到如今流行的“产品设计师”。 文章的核心观点是，头衔的更迭更多是受市场风向和技术工具的影响，而非设计本质的改变。例如，当Flash技术兴起时，“交互设计师”头衔应运而生；而随着软件产品成为主流，市场便转向了“产品设计师”。作者指出，从Alexey Brodovitch在杂志社的版面设计，到如今在敏捷冲刺中绘制线框图，优秀设计师的核心特质——以用户为中心、有目的、可迭代、善于协作——一脉相承。 文章揭示了一个现象：设计师发明或选择特定头衔，往往是因为这符合当前市场的经济利益和专业细分需求。然而，市场真正需要的从来不是一个时髦的头衔，而是一群关心用户、乐于创造、持续改进的优秀设计师。无论媒介如何从纸张变为软件，为用户打造卓越体验的追求始终未变。
从Java和JavaScript来学习Haskell和Groovy（元编程）
这篇文章深入探讨了四种主流编程语言在元编程领域的不同实现路径。作者首先定义元编程为“用程序写程序”，即运行时动态修改类结构的能力，并从Java的静态限制出发，介绍了其依赖JDK 5注解（如Lombok）和Spring框架（AOP、IoC）扩展元编程的方式；对于Haskell，则聚焦于Template Haskell通过抽象语法树（AST）和QuasiQuotation在编译期生成代码的方法，例如用`[| |]`构造自定义语法片段。 对比动态语言，JavaScript的元编程基于对象自省和eval关键字，以极简性著称——通过prototype和动态属性添加实现灵活扩展；而Groovy则提供了更丰富的特性，如MethodMissing处理未知方法调用、GroovyInterceptable实现AOP拦截、Categories提供类似Objective-C的临时能力注入，以及Magic Package自定义元类（如通过命名规约修改String逻辑）。文章揭示了静态语言与动态语言在元编程灵活性上的核心差异：前者受限于编译期，后者则能自由操纵运行时环境。 最终，作者对比了JavaScript的简洁设计与Groovy的功能多样性，指出语言选择如同工具取舍，关键在于程序员如何平衡需求与偏好。这种跨语言视角帮助读者理解元编程的本质，并为项目技术选型提供了清晰参考。
手机UI设计基础-尺寸&单位
这篇讲的是手机UI设计中让很多新手头疼的尺寸与单位问题。作者从移动端开发和设计的常见困惑出发，系统梳理了iPhone与Android两大平台的核心概念和适配思路。 文章首先厘清了iPhone的分辨率、屏幕尺寸、像素密度（PPI）以及逻辑分辨率（pt）与物理分辨率（px）的关系，并以表格形式清晰列出了从初代iPhone到iPhone 6 Plus的换算规律（如iPhone 6s为1pt=2px）。针对机型众多的适配难题，作者提出了一套实用的工作流：以iPhone 6的750px宽度作为设计基准稿，使用矢量元素设计，标注后同步输出用于切图的@3x资源；开发端则基于此使用自动布局，再向上向下适配更大和更小的屏幕。 对于Android平台，文章介绍了dp、sp、dpi等关键单位，并建议以1080px宽（xxhdpi）作为通用设计尺寸。最后，文章还延伸至移动端Web，指出通过设置viewport代码（如width=device-width），可以让px单位等同于逻辑像素使用，从而在不同设备上实现统一的页面宽度（如640px）。 整篇文章将碎片化的尺寸知识串联成清晰的适配逻辑，不仅解释了“是什么”，更给出了“怎么做”的具体路径，对理清设计与开发协作的流程很有帮助。
如何设计好用的触控手势
这篇文章从儿童和长辈都能轻松上手的触控设备现象切入，探讨了如何设计出既自然又高效的触控手势。 触控手势作为自然用户界面（NUI）的体现，通过模拟现实世界的动作（如滑动、缩放）降低了交互门槛。文章强调，设计时必须考虑用户身处的“移动情景”——注意力分散、操作时间碎片化、任务易中断等复杂环境，这些都对手势的易用性提出了更高要求。 那么，什么才算“好用”的手势？作者总结了几个关键特征：动作简单到可以单手在拥挤交通工具上完成；容易记忆且符合认知习惯；具备实用性，让用户无需多余操作；提供即时反馈，让用户清楚操作状态。 在具体设计上，文章给出了几条核心准则：手势必须符合大多数人的自然习惯；一个应用的手势数量最好控制在5个以内，以降低记忆成本；根据应用类型差异化设计——效率工具适合单手手势，游戏可以适当增加复杂手势以提升乐趣；同时，像《Flappy Bird》那样适度、克制地运用手势，往往能达到最直接有效的效果。最后，提供视觉或震动反馈，并确保操作可逆，能极大增强用户操控的信心与安全感。
小谈矢量网络
这篇讲的是 Figma 团队如何重新思考并改进了诞生三十多年的矢量编辑工具。作者从自身游戏开发背景出发，指出传统基于“路径”的钢笔工具在交互上存在诸多反直觉的限制。为此，Figma 提出了“矢量网络”这一新模型。 与路径的单一链条不同，矢量网络允许任意两点之间自由连接和分割，极大提升了形状编辑的灵活性，甚至对用户而言是“无缝”的体验。文章还分享了其他关键改进：弯曲工具允许直接拖拽曲线而非仅靠控制柄，符合直觉；同时，Figma 的填充算法摒弃了传统复杂的“卷绕数”概念，通过智能识别封闭区域并提供油漆桶工具一键开关，让填充操作变得直观。这篇文章揭示了如何通过底层模型的创新，让基础设计工具变得更自然、更强大。
视觉调整－设计师 vs. 逻辑
这篇讲的是设计中常被忽略的“视觉调整”艺术——当像素完美并不等于眼睛里的完美时，设计师该如何破局。作者从早期过度依赖软件数值对齐的误区出发，揭示了计算机的“理性计算”与人眼“感性感知”之间的关键差异。 文章用四个具体案例拆解了视觉调整的要点：比如播放器图标在几何上居中，视觉重心却需左移；相同色值的填充色与文字，需微调明度才能看起来一致；同样尺寸的方形与圆形，后者需要放大几像素才能视觉等高；全大写字母则需适当缩小，才不会显得突兀。这些调整幅度虽小，却直接影响了设计的整体和谐度。 作者的核心观点在于：优秀的设计师需要超越工具的理性局限，信任并锻炼自己的视觉直觉。这些细微处的打磨，正是“像素级完美”背后的秘密，也是当前AI仍难以模拟的人类判断力所在。
为什么要段首空两格
这篇讲的是“段首空两格”这个看似不起眼的中文排版习惯，背后其实藏着一套完整的设计逻辑。作者从“以用户为中心”的思路出发，梳理了中西方段落分隔的漫长历史——从中国汉代奏章的“需头”传统，到西方中世纪手抄本的首字母放大，再到1919年新式标点符号运动将其规范化，这种缩进最初都是为了让段落划分更清晰、提升阅读节奏。 文章的核心观点很明确：段首空格的两大作用是标记段落停顿和视觉区分。它对比了网络时代的不同选择，指出虽然网页可以靠空行或标题来分段，但一致性的左侧缩进更符合大多数人从左到右的阅读习惯，能优雅地引导视线，增强长文的易读性。尤其对于汉字这种信息密度高的文字，段落分明能有效缓解阅读压迫感。 最后作者给出实用建议：在大多数中文网络内容中，段首空两格依然是很好的分隔方式；但若已有标题或列表等明确结构，也可灵活处理。整篇文章将一个小排版细节，讲成了一次对用户阅读心理和跨文化设计史的洞察。
用户并不是小白，她只是在等待被服务
这篇讲的是互联网产品设计的核心理念。作者开篇就抛出一个犀利的观点：用户从来都不是“小白”或傻瓜，他们只是在等待被服务，渴望享受被服务的过程。 基于这个认知，文章层层递进。作者将产品设计比作一个响应用户需求的“黑盒子”，但强调这个服务必须是正向的、让人愉悦的。为此，设计者需要先以“仆人视角”理解用户感受，再切换“上帝视角”来梳理和取舍需求，这其中逻辑能力至关重要。 文章更进一步探讨了服务中那些微妙的“感觉”。比如，通过一个“递水时是否主动帮忙拧开”的面试题，说明服务意识超越了单纯的逻辑流程。作者还用食堂、高档餐厅和肯德基不同的“劝离”方式作为比喻，形象地展示了如何在产品中礼貌而得体地引导用户行为。 最终，作者认为这种服务意识源于对场景的深刻理解与还原，并上升到了“讲故事”的高度。好的产品本身就是在向用户讲述一个动人的故事，最高境界甚至能传递出“情怀”。整篇文章用生活化的例子解构了产品设计中那些难以言传的体验部分，对从业者如何提升用户同理心很有启发。
为什么我认为架构师需要坚持写代码？
这篇文章从近期技术圈关于“架构师应具备哪些能力”的讨论切入，剖析了架构师的两种类型：一种擅长任务分解、资源整合与项目交付，本质上是在既定框架内填充内容；另一种则具备“技术杠杆”能力，能借助代码与技术方案大幅提升效率或创造新可能，例如通过算法改进用户体验。作者的核心观点是，后者才是能驱动技术变革的关键角色，而这样的架构师必须坚持写代码。 文章进一步指出，不写代码的架构师容易沦为“填格子的人”，难以深入理解技术细节，更无法运用技术力量放大业务价值。在评估架构师能力时，作者提到一种实用的面试方法：让候选人先完成小型代码编写测试，以此作为能力基线，再讨论架构设计。这能有效区分出真正有一线编码经验、能用技术解决问题的候选人，而非仅擅长沟通与流程管理的人。 整体来看，作者强调架构师的价值不仅在于设计蓝图，更在于通过亲手实践保持技术嗅觉，从而找到以技术杠杆撬动更大成果的机会。这对团队如何定义架构师角色、进行人才评估，提供了务实的视角。
简历的重点是抓人
这篇讲的是简历写作的核心心法——“抓人”。作者从经常帮朋友做内推的经历切入，指出一个常见痛点：许多技术过硬、素质优秀的候选人，却因简历过于敷衍而错失机会。在招聘方平均只花2分钟浏览一份简历的背景下，这短暂的“决定命运的2分钟”里，简历是单向沟通的唯一载体，其质量直接决定了能否获得后续展示的机会。 文章将简历比作一个“产品”，建议像产品经理一样反复打磨。它提供了非常具体的“抓人”策略：比如基本资料要精简，使用专业邮箱，附上得体的证件照；个人简介应避免空洞形容词，用事实突出个人价值，甚至主动提及弱点以展示自知之明；而项目经历部分，推荐使用STAR法则（情境、目标、行动、结果）进行结构化描述，但强调“适可而止”，保留悬念以吸引面试官深入探究。 作者的核心观点是，简历的重点不是信息的简单堆砌，而是成功吊起招聘方的兴趣，让人产生“非得和这家伙谈谈不可”的念头。这提醒许多求职者，尤其是技术背景的候选人，不应只埋头于面试准备而轻视了简历这个最重要的敲门砖。
不要对设计师说的话
这篇讲的是设计师与开发者合作时那些看似无害却可能引发矛盾的对话。作者从一线协作经验出发，列举了几句常见的“地雷”发言：比如直接要求“把这个按钮加粗”，或者擅自修改设计稿并说“我能修复”。这些行为的本质，是跳过了对问题本身的讨论，变成了微管理。 文章的核心观点很明确：反馈应聚焦于“是什么”和“为什么”，而非“怎么做”。当你说标题不够突出时，设计师会从视觉层次、系统一致性和整体平衡的角度去优化；反之，一句简单的“加粗”指令，可能破坏精心维护的设计体系。对于开发者无意中修改界面的行为，作者打了一个比方：这就像设计师拿走你即将上线的代码擅自改动，是对专业信任的极大伤害。 作者也指出，设计师对“5像素”这类细节的坚持并非挑剔，而是每一个微小精度的累加，最终定义了产品的质感。而当设计师提出大胆构想时，开发者一句“这不可能”往往过早关闭了对话空间——更有效的做法是说明平台限制，共同寻找替代方案。文章最终指向一种健康的协作文化：用建设性的提问替代生硬的指令，用信任激发彼此的专业判断，共同对产品负责。