gcc的内联汇编取全局变量地址
这篇讲的是在GCC内联汇编中高效访问全局变量地址的实用技巧。作者从一段需要优化的代码出发，其中频繁使用了全局变量，直接硬编码地址或使用冗长的符号引用会让内联汇编变得笨重且难以维护。 文章的核心解法是利用GCC提供的扩展语法，直接在内联汇编模板中引用C语言变量名。例如，通过`"a"(global_var)`或`"m"(global_var)`这样的约束描述符，可以安全地让汇编器在编译时获取变量的地址或值，而无需手动计算偏移量。这不仅保证了代码的可读性与可移植性，还能确保编译器正确处理内存对齐和优化。 实现上有一个巧妙之处：对于需要在汇编指令中直接使用地址的场景（比如`lea`指令），可以将全局变量作为操作数传入，让GCC负责生成正确的地址引用。这种方法避免了硬编码地址带来的风险，尤其当变量可能被链接器重定位时。 文章通过具体代码片段展示了如何声明和使用这些变量，强调了这种方式如何让内联汇编与C代码更自然地结合，最终写出更清晰、更稳健的混合编程代码。
我学编程时犯的最大两个错误
这篇讲述了作者在自学编程过程中因信息过载而犯下的两个典型错误，以及他如何从中吸取教训。作者大学毕业后怀揣创业梦想，但发现自己不会编程，于是听从建议开始自学。他最初泡在Hacker News、Quora和StackOverflow等平台，搜集了大量技术名词，列出一个包含HTML、CSS、PHP、Javascript、Django、Python等二十多项的杂乱清单，试图全部掌握，结果陷入迷茫。 核心错误之一是学习了太多与原型开发无关的技术。实际上，他后来认识到，只需精简到关键工具：用HTML构建网页结构，CSS设计样式，Javascript和jQuery实现动态交互，Python处理数据，以及Django作为Web框架连接一切。这个清单不仅更实用，还帮助他理清了学习路径。 另一个错误是过度依赖阅读而缺少实践。他花时间读了很多编程书籍，却没将知识应用到项目中，导致学得快忘
c关键字－sizeof的种种
这篇技术博客深入探讨了C语言中一个常被误解的关键字——`sizeof`。作者从它作为编译时关键字而非函数或宏的核心身份切入，剖析了其值在编译阶段确定的根本特性。 文章通过一系列经典且易错的示例，直观展示了`sizeof`在不同上下文中的行为差异。例如，它对数组名和指针的计算结果完全不同，这一细节是许多C程序员必须厘清的知识点。同时，文章也详细讲解了`sizeof`对结构体、联合体等复合类型大小的计算规则，包括对齐方式可能带来的影响。 作者的讲解侧重于原理与实践的结合，帮助读者理解编译器是如何思考并计算这些大小的。掌握这些细微之处，能让你在编写涉及内存分配、数据结构布局的代码时，做出更精准的判断，从而避免潜在的内存错误。
C语言的那些个关键字们
作者分享了一次在感冒状态下参加技术面试的真实经历。文章从作者带病前往心仪公司面试开始，描述了因迟到引发的紧张情绪，以及在高压时刻身体出现的意外反应——鼻涕突然停止了。这个细节生动展现了面试者对机会的重视，以及压力如何影响生理状态。作者以幽默的口吻，将个人体验与技术面试的常见挑战相结合，核心观点在于：在技术能力之外，心态管理和应变能力同样决定面试成败。对于读者，尤其是常面临面试的技术人员，这个故事提醒我们，突发状况下保持冷静的重要性，以及如何将压力转化为动力。文章通过这个小插曲，启发读者在技术学习之外，也需培养心理韧性，以更从容地应对职业中的不确定性。
一个简单的例子让你认识测试驱动
这篇讲的是用一个非常具体的例子，带你理解“测试驱动开发”（TDD）到底是什么。 文章没有从理论开始，而是直接模拟了一个开发“用户登录”模块的场景。作者先展示了传统“先写功能代码，再补测试”的思路，并指出了它可能带来的测试遗漏和设计问题。接着，演示了TDD核心的“红-绿-重构”循环：第一步，先写一个最简单的失败测试（红灯），明确一个微小的功能点；第二步，写最少的代码让测试通过（绿灯）；第三步，重构代码以提升设计。通过这个小例子，TDD“测试先行”、“小步前进”、“持续设计”的特点变得非常直观。 文章最巧妙的地方在于，它让读者看到，TDD不仅仅是一种测试技术，更是一种引导你写出高内聚、低耦合、可测试代码的设计工具。当你看到最后那个结构清晰、易于维护的登录模块时，就自然明白了这种开发方式的价值所在。
C++11（及现代C++风格）和快速迭代式开发
这篇讲的是作者在微软亚洲研究院参与英库拼音输入法开发时，全面采用C++11及现代C++风格进行快速迭代式开发的实战经验。项目由自然语言处理组、互联网搜索与挖掘组等多团队协作，作者作为客户端核心开发人员，将大部分精力投入编码实现。 文章从项目背景切入，分享了在实际开发中如何利用C++11的新特性（如lambda表达式、自动类型推导、移动语义等）以及现代C++编程风格（如Herb Sutter提出的Elements of Modern C++ Style）来提升代码简洁性、性能和协作效率。作者结合输入法开发的具体场景，讨论了这些技术如何支持快速迭代，例如通过改进内存管理和并发处理来加速功能开发与测试循环。 对于C++开发者来说，这篇经验文章提供了可借鉴的实践案例，展示了如何将现代语言特性融入日常开发流程，以应对快速变化的产品需求，从而提高整体开发效能和代码质量。
创业并快乐着的六个习惯
这篇分享来自Buffer创始人Joel Gascoigne的创业心路。他回顾了自己从决定创建Buffer，到此前长达一年半的另一段创业旅程，在近2年多的实践中，逐渐提炼出了一套能让自己在创业高压下保持快乐与平衡的规律。 文章并没有谈论复杂的产品策略或融资技巧，而是聚焦于创业者的内在状态。作者发现，快乐并非偶然，而可以通过一些刻意的习惯来培养。这些习惯帮助他应对创业必然伴随的起伏，让过程本身变得可持续。比如，如何设定节奏、处理压力、从日常工作中获取正反馈，这些具体的行动准则构成了文章的核心。 对于技术创业者和开发者来说，这篇文章的价值在于，它跳出了“增长黑客”或“技术架构”的视角，从更本质的“人”的层面提供洞察。它提醒我们，打造一款成功的产品，首先需要构建一个能持续创造、保持健康的自己。文中分享的习惯具体且具有可操作性，能为身处长期项目中的读者提供切实的参照。
聊聊ThoughtWorks面试
这篇分享的是一位应聘者亲历ThoughtWorks面试的全过程与深度思考。文章细致梳理了从技术笔试、一对一技术面、案例讨论到小组情景模拟的完整流程，清晰呈现了每个环节如何考察应聘者的不同维度。 作者特别指出，ThoughtWorks的面试并非单纯考察编码能力或特定技术栈的掌握程度。例如，现场编程题更注重思维过程的清晰与沟通，案例讨论则看重对业务价值的理解与权衡。整个流程被设计成一次综合性的职业能力评估，尤其侧重考察应聘者解决开放性问题的思路、协作沟通能力以及对软件工程价值观的理解。 这种面试设计的底层逻辑，实际上是将未来的工作场景前置，让面试官在真实互动的动态过程中判断候选人是否适合公司的文化与工作模式。对于读者而言，无论是否目标为ThoughtWorks，这篇文章都提供了关于现代技术公司面试趋势的洞察——即对综合思维与软性技能的重视正日益凸显。
敏捷开发者必读书籍
这篇整理了敏捷开发者在工程实践、团队协作与持续改进等不同维度上的核心书单。作者从“工具思维”和“系统思维”两个层面切入，推荐了涵盖估算规划、持续交付、测试驱动开发与团队协作的多部经典。 书中既讲解了《敏捷估算与规划》如何将故事点、燃尽图与发布计划落地，也剖析了《持续交付》中从代码提交到生产部署的完整流水线设计；《测试驱动开发》则通过红绿重构的循环，展示了如何在开发中内置质量防线。针对团队沟通痛点，《敏捷教练》一书提供了具体的引导技巧与反馈模型，而《重构》则从代码层面示范了如何通过小步修改维持系统健康度。 这份书单并非泛泛而谈，而是结合具体技术实践（如依赖管理、验收测试自动化）和团队场景（如远程协作、需求梳理），指明了每本书最能解决的典型问题。对于想在速度与质量间找到平衡的开发者，这些书籍构成了从个人编码到团队工程化升级的清晰路径。
lua metatable使用和源码分析(三)
这篇是“Lua元表源码分析”系列的第三篇，将视角从用户自定义表转向了Lua的基础——数字、字符串等基本类型是如何挂载并使用元表的。作者并没有停留在“数字也有元表”这个结论上，而是带着读者钻进源码，看Lua的实现者如何为这些内建类型维护和查找它们的元表。 文章的核心在于剖析`luaL_getmetafield`等关键函数的实现逻辑。最巧妙的一点在于，Lua并非为每个数字都存储一个元表，而是在`lua_State`或全局状态中，为数字、字符串等不同类型分别维护了一个共享的、静态的默认元表。源码分析揭示了当对数字调用方法时，虚拟机是如何一步步索引到这个全局默认元表，并执行其中定义的`__add`、`__index`等元方法的。这个设计既保证了功能的完整性，又极大地节省了内存。 通过这篇分析，读者不仅能理解“如何用”，更能看清Lua为了保持语言的一致性和性能，在底层做出的精巧权衡。它清晰地展示了，用户定义的元表机制与语言内建的元表机制，是如何在同一套引擎规则下协同工作的。
lua metatable使用和源码分析(二)
作者延续上篇对 Lua 元表 `__index` 的探讨，将镜头推进到 `__add` 这个算术事件上，带你从虚拟机核心 `luaV_execute` 出发，追踪元表调度的具体路径。文章不是简单地罗列用法，而是扎实地潜入底层，展示当代码执行到加法操作时，虚拟机如何一步步检查元方法、完成调度。 这种源码级的剖析让 Lua 的“表”与“元表”之间的魔法变得清晰可循。作者没有停留在概念，而是通过关键函数调用链的梳理，揭示了机制运作的实质。对于想理解语言设计精妙之处，或是需要深度调试的开发者来说，这提供了一份非常具体的实现地图。 读完你会对 Lua 如何优雅地扩展基本运算有更透彻的认识，而不只是停留在“它能这么做”的层面。
lua metatable使用和源码分析(一)
这篇讲的是Lua中元表（metatable）的使用与底层源码实现。作者从元表的核心机制出发，解释了它如何像C++的运算符重载一样，为表这类复合结构赋予自定义行为——例如，当对两个表执行加法时，Lua并非直接报错，而是会检查元表中是否存在名为`__add`的元方法（metamethod），如果找到就调用对应的函数来执行加法逻辑。 文章不仅停留在用法层面，还深入到了源码分析。它会带你看懂Lua虚拟机是如何一步步查找和调用元方法的，让你理解这套机制在内部是如何高效、优雅地实现的。对于想要真正掌握Lua“黑魔法”并看透其设计巧思的开发者来说，这是一个很好的切入点。
创业这件事（1）
这是一篇作者从个人经验出发的创业观察，属于事件复盘/观点类文章。作者以“创业”这个看似宏大却具体到每个人的故事为切口，没有空谈理论，而是聚焦于创业过程中那些真实、细微却决定成败的日常。 文章可能围绕一个核心观点展开：创业并非仅仅是商业模式的搭建或技术的实现，更是对创始人心力、团队协作以及应变能力的持续考验。它通过拆解创业路上可能遇到的典型场景或瞬间，比如最初的愿景如何在执行中不断被修正，或是在资源有限的情况下如何做出关键抉择，来揭示创业背后鲜为人知的复杂性和韧性要求。 作者并未给出标准答案，而是试图还原创业作为一种“实践”的真实质感——它混合了远见、妥协、坚持与学习。这种分享或许能给正在创业路上或有意尝试的读者一个更为冷静和具象的参照，帮助他们重新审视自己对“创业”二字的理解与准备。
有关面试
这篇讲的是作者作为技术面试官，在近期一系列高强度的招聘面试后，沉淀下来的第一手观察与思考。 他没有空谈理论，而是直接从面试现场的细节入手，探讨了几个关键问题：面试的本质究竟是“技术考核”还是“潜力探测”？作为面试官，如何避免陷入仅凭“手速”和“标准答案”来评判候选人的误区？在有限的时间里，是该深挖一个知识点来考察思维深度，还是广泛覆盖以评估知识广度？ 文章将面试形容为一场双向的信息对称博弈。作者特别指出了一个常见盲区：我们往往过度关注候选人“答对了什么”，却忽略了观察他“如何面对不知道的问题”以及“提问时展现了怎样的思考路径”。这些细节，往往比背诵八股文更能揭示一个人的技术素养和成长潜力。 对于正在准备技术面试的候选人，或是同样承担面试职责的技术人员，这篇文章提供了一个跳出常规题库的视角，去重新审视面试中那些容易被量化的标准所掩盖的、更重要的人的维度。
写代码这件事
这篇讲的是一个现场编码演示的完整过程。作者从晚上一场两个小时的实时演示切入，带着两位观众，从屏幕上打出的第一个字符开始，用纯粹的代码逻辑和思考过程，最终实现了199行代码就能完成的付费功能核心。 文章没有聚焦在炫技或复杂架构上，而是完整展现了从0到1的编码“手感”。从最初的构思、基础结构的搭建，到中间遇到的具体问题如何思考与调试，再到最终功能的成型，每一步都清晰可见。这种手把手的展示，把写代码这个抽象的过程变得具体可感，其核心思路与代码组织的巧妙之处都随着敲击声一步步展开。 它不仅演示了一个功能的实现，更像是对“如何从无到有构建一个东西”这一过程的白描。对于想了解真实编码节奏、思考路径，或是对从零开始实现一个小功能感兴趣的读者来说，这份未经修饰的原始记录本身就提供了独特的视角和启发。
为什么有些编程语言会死而有些能活下来？
为什么Java和Python这类语言能长盛不衰，而Google Go这样的新语言却难获广泛接纳？这篇讲的是编程语言在漫长技术演化中的生存法则。 作者从Google推出Go和Dart这两种新语言的尝试出发，探讨了语言生态中一个残酷而现实的问题：语言的“生死”并非完全由技术优劣决定。文章对比了Java、Python等“幸存者”与许多昙花一现的语言，指出成功语言往往具备几个关键特质：极其庞大的现有代码库与开发者惯性（如Java的JVM生态）、解决了一类广泛而根本的问题（如Python的简洁与通用），以及围绕它们形成的、难以撼动的产业与社区护城河。 相比之下，即便像Go这样在并发等特定领域设计出色的语言，也面临着从零开始构建生态、说服开发者学习新范式与工具链的巨大挑战。文章揭示的核心观点是，编程语言的竞争更像是平台和生态的竞争，技术优势只是入场券之一，而网络效应、历史积累和用户习惯才是决定长期生存的更深层力量。
当程序出问题时程序员最喜欢说的20句话
这篇来自技术社区的文章，从一张有趣的图片出发，列举了程序员在程序出问题时最爱说的20句话。文章并非严肃的技术分析，而是精准捕捉了开发者在面对Bug时那些不自觉的口头禅和经典反应——比如习惯性甩锅给硬件、环境，或是低估修复难度。 这些短语背后，其实反映了解决问题时常见的心理防御机制和沟通习惯。例如，“在我机器上是好的”暴露了对运行环境差异的忽视，“应该只是个小问题”则可能掩盖了真正的复杂度。文章将这些程序员圈内耳熟能详的“黑话”集中呈现，既让人会心一笑，也促使我们反思：这些脱口而出的话，是否无意中阻碍了高效的故障排查与团队协作？ 对于技术读者而言，这篇文章像一面镜子，让我们在幽默中看到自己和同行们面对压力时的微妙姿态。它不提供具体的解决方案，却以轻松的方式提醒大家：识别并正视这些本能反应，或许是提升问题处理能力和沟通效率的第一步。
产品的价值
这篇讲的是作者对产品价值的深入反思。最近，作者一直在琢磨如何通过自己的工作最大化价值输出，特别是在产品开发中。文章从个人经历出发，探讨了产品价值的多重维度：不仅仅是功能实现，还包括用户体验的提升、业务指标的优化以及技术创新的贡献。 作者通过具体案例，比如某个功能的迭代过程，分析了如何平衡技术债务与用户需求，指出价值创造的关键在于持续学习和适应。这种思考强调，真正的价值在于解决真实问题
C#的设计缺陷（2）：不能以void作为泛型参数
这篇文章从C#与Java泛型的对比切入，探讨了C#作为“真泛型”语言在语言设计层面的另一项限制：不允许将void作为泛型类型参数。作者指出，.NET的真泛型本是一大优势，但具体到C#编译器的实现与运行时约束，却衍生出这一设计缺口。 文章并未深入剖析其技术成因，而是将C#视为一个既成“产品”，着重分析了这一限制所带来的实际编程后果。它揭示了在试图用泛型统一处理值类型与引用类型（包括表示“无返回值”的void）时，开发者可能遇到的设计困境与代码冗余。 对于关注语言设计权衡与.NET生态实际特性的开发者而言，这提供了一个理解C#泛型边界与当前编程模型局限性的具体案例。
翻译杂思
这篇讲的是作者从2009年半开玩笑地参与《ThoughtWorks文集》翻译开始，如何一脚踏进了图书翻译的河流，并持续沉浸其中的故事。文章没有泛泛而谈翻译理论，而是通过这段个人经历，引出了对技术翻译这一独特工作的真切感悟。 作者分享了从“玩票”到“入行”的心态转变，以及翻译过程中那些不足为外人道的细节——它远不止是语言转换，更像是在两种思维体系间搭建一座既精准又流畅的桥梁。这种沉浸式的工作，迫使译者对技术的理解必须掰开揉碎、再清晰重组，其收获往往超越了单纯的“完成一本书”。 对于从事技术写作、文档翻译，或是任何需要精准传递复杂信息的读者而言，这篇文章提供了一个内行人的视角：它揭示了这项工作背后的耐力、苛刻与独特的成就感。这种源于深度参与和反复锤炼的体会，或许比任何翻译技巧的条目都来得生动。