把 lua 的 gc 移到独立线程
这篇讲的是如何将 Lua 的垃圾回收（GC）机制从主线程剥离，放到独立线程中运行的技术方案。 作者首先剖析了 Lua 现有 GC 工作机制的细节，指出了其核心痛点：GC 的标记、清除等阶段会与业务代码共享同一个执行线程，不可避免地导致不可预测的长时间停顿，这对于延迟敏感的应用（如游戏、实时服务）是个棘手问题。 文章的核心思路是实现一个“GC 线程”，让它与主线程并行工作。难点在于如何让 GC 线程安全地遍历和清理仍被主线程使用的对象。作者从 Lua 源码出发，阐述了实现的关键点，包括设计一套轻量级的屏障（barrier）机制来记录对象修改、协调两个线程间的对象图访问，以及处理字符串等特殊对象的清理逻辑。 经过改造后，GC 工作主要转至后台，主线程仅需付出很小的屏障开销，从而大幅降低了 GC 引起的峰值停顿。文章不仅给出了清晰的实现路径，也坦诚讨论了并行 GC 带来的额外内存占用等权衡，为需要进行类似优化的开发者提供了扎实的参考。
如何与异地的开发人员沟通
这篇讲的是资深产品专家 Marty Cagan 对远程协作的洞察，尤其针对开发团队分布在不同时区的常见挑战。作者从产品管理和工程实践结合的视角出发，指出沟通的核心障碍往往不是技术，而是时差、文化差异和信任缺失。文章节选自经典著作《启示录》，分享了建立有效远程协作流程的具体方法，比如如何安排异步沟通、确保需求对齐，以及管理团队期望。 另一个高频痛点是当程序员提出“我想重写代码”时该如何应对。文章没有简单评判，而是引导读者思考代码重写背后的真正驱动力——是技术债务、架构缺陷，还是业务需求发生了根本变化？作者提供了一套决策框架，帮助技术管理者平衡短期交付压力与长期系统健康度，避免陷入情绪化的对抗或无原则的妥协。 这些经验源于作者在网景、eBay等一线公司的实战总结，将抽象的管理原则转化为了团队可操作的沟通习惯和决策依据。
Git安装使用手记
这篇讲的是作者在 Windows 环境下从零开始安装配置 Git 的完整实践记录。文章没有停留在基础的下载安装步骤，而是重点分享了几个新手容易栽跟头的“坑”。比如，安装后执行 `git` 命令提示“不是内部或外部命令”，作者指出这是由于环境变量 PATH 未正确配置，并详细演示了如何手动添加 `Git\cmd` 路径来解决。对于初次接触版本控制的开发者，文章还澄清了关于 SSH 密钥的常见疑惑，解释了在只有个人项目的场景下，并非必须配置 SSH，使用 HTTPS 方式克隆同样方便。 在实际使用部分，作者着重对比了 `git add .` 与 `git add *` 的区别，通过一个具体案例说明后者可能意外将不想要的文件（如 `debug.log`）加入暂存区，强调了明确指定文件的重要性。文章还介绍了如何设置用户信息、配置别名以简化常用命令（例如 `git st` 代表 `git status`），这些细节能有效提升日常工作效率。整体来看，这更像是一篇为 Windows 用户量身定制的 Git 避坑指南，把安装配置和初期使用中可能遇到的典型问题都梳理了一遍，对刚上手 Git 的开发者来说，能避免不少无谓的挫折。
为何改用Git
这篇讲的是版本控制工具选型背后的实战思考。作者从团队此前使用 SVN 的工作痛点出发——比如集中式架构下的单点故障风险、离线工作困难、分支合并的繁琐流程，详细对比了迁移到 Git 后带来的根本性改变。 文章重点剖析了 Git 分布式设计的核心优势：本地仓库使得提交、分支操作完全脱离网络限制，大幅提升了开发灵活性；而灵活的分支模型与非线性工作流，则彻底解决了并行开发中的代码集成难题。作者还结合真实项目经验，指出 Git 在合并效率、历史追踪以及跨团队协作场景中的显著提升，并坦诚讨论了初期学习曲线与工作流迁移的适应成本。 最终结论清晰明确：对于需要高效协作、频繁迭代的现代软件团队，Git 在灵活性、性能和可靠性上的综合优势，使其成为更适配的版本控制方案。文章通过具体场景的利弊分析，为技术团队的工具决策提供了扎实的参考依据。
谈谈阿里巴巴的企业文化
这篇文章聚焦于阿里巴巴企业文化中“拥抱变化”这一核心特质的落地实践。作者没有停留在口号层面，而是深入剖析了这一理念如何渗透到技术团队的日常运作与决策中。 具体来说，文章揭示了在快速迭代的互联网环境下，“拥抱变化”意味着什么。它不是被动的接受，而是一种主动的能力，体现在对架构的持续重构、对工具链的不断优化，以及面对业务不确定性时保持技术敏捷性的方法论中。文章通过具体案例说明了这种文化如何塑造了工程师的思维习惯和解决问题的方式，避免了组织僵化。 对于技术读者而言，其启发在于：技术管理的本质不仅是管理代码和系统，更是管理人面对变化的心态和能力。如何在自身团队中培育一种既稳定可靠又灵活应变的工程文化，是比单纯追求技术栈先进性更根本的挑战。
GDB的两个技巧
这篇讲的是两个提升GDB调试效率的实用技巧。作者从日常调试中常见的痛点出发，没有停留在基础命令介绍，而是聚焦于两个能显著简化操作、提高排查速度的进阶用法。 第一个技巧涉及如何更高效地处理多线程调试。文章指出，在复杂的线程环境中，仅靠基本的 `thread apply all` 命令有时不够灵活。作者推荐了一种结合条件断点与线程筛选的组合技，能够精准地将断点作用于特定线程，避免在无关上下文中浪费时间。这特别适用于只关心某个线程特定状态下的变量或调用栈的场景。 第二个技巧围绕自动化调试步骤展开。作者分享了利用GDB的钩子（hook）命令，在特定操作（如 `next` 或 `step`）后自动执行预设的命令列表。例如，可以在每次单步执行后自动打印关键变量的值，从而省去手动输入的重复劳动，让调试流程更连贯。 这两个技巧的共同点在于，它们都旨在将调试者的注意力从重复、繁琐的命令操作中解放出来，更专注于逻辑分析本身。文章通过具体的命令示例和适用场景说明，让读者能立即上手尝试。
锈规作图续篇：单用一个只能画单位圆的圆规如何作线段中点
这篇文章接着一篇更早的博文，探讨了一个经典的几何谜题：如何只用一个被卡住的、只能画单位圆的“生锈”圆规，作出给定线段的中点。 作者从1983年D. Pedoe教授最初提出的“锈规作图”问题讲起——即如何用这种受限工具构造等边三角形。这不仅仅是趣味数学，其背后是严谨的理论挑战。文章重点介绍了我国学者侯晓荣等人在1987年取得的突破：他们运用复平面理论，不仅解决了这一问题，还得到一系列一般性的结论，并将成果《锈规作图论》发表在《中国科学技术大学学报》上。 续篇的焦点转向另一个经典任务：作线段中点。这看起来比构造等边三角形更基础，但在“只能画单位圆”的严格限制下，其构造步骤却可能蕴含着不同的巧妙思路与理论工具。文章将带你回顾那段研究历程，并展示如何用这个看似“功能残缺”的工具，完成一个基本的几何操作。
关于HBase的一些零碎事
这篇讲的是Facebook如何用HBase搭建实时消息系统，以及这个案例如何推动了HBase技术的持续升温。文章从Facebook的实际应用出发，揭示了HBase作为基于Hadoop的面向列存储数据库，在应对海量、高并发数据写入时的独特优势。核心点在于HBase的列式结构和分布式架构，使其能够高效处理像消息这类需要快速写入、随机查询的非结构化数据，完美匹配了Facebook消息系统对低延迟和高吞吐量的苛刻要求。作者通过这个知名案例，向读者传递了一个明确的信号：当业务场景涉及超大规模数据且需要实时读写时，HBase是一个值得深入评估的坚实选项，而不仅仅是停留在理论层面的数据库技术。
一个空格引发的惨剧
这篇文章讲的是一个因代码中多了一个空格而导致可能删除整个系统目录的灾难性故事。作者从个人经历出发，引出了开源项目 bumblebee（一个将 NVIDIA Optimus 技术移植到 Linux 的项目）安装脚本中的一个真实 bug。 这个 bug 的全部内容，就是一行 `rm -rf` 命令中，本应删除 `/usr/lib` 下特定文件的路径，因为一个空格变成了删除 `/usr` 和 `/lib` 两个独立目录——极有可能导致系统完全瘫痪。文章展示了这个 bug 的修复 diff，视觉冲击力极强，生动诠释了为何“测试程序是一种懦夫的行为”。 比 bug 本身更精彩的是，文章后续收录了全世界程序员围绕这个 commit 在 GitHub 上展开的欢乐 code review。评论中充斥着各种夸张的梗图和讽刺，将一次严重的线上事故变成了全球开发者的集体狂欢，既是对疏忽的嘲讽，也是对严谨编码的另类呼唤。
Perl 自动化之网页处理 WordPress 自动登陆查看
这篇讲的是如何用Perl高效实现网页自动化，特别是针对WordPress这类网站的登录与数据获取。作者从自己早年处理HTTP请求时感觉“有点乱”的经验出发，分享了如何化繁为简。 他梳理出一条清晰的技术路径：首先掌握LWP::UserAgent模块发送请求，然后理解HTTP::Request、HTTP::Response等核心部件的作用，最后也是最关键的一步，是利用Web::Scraper模块来解析和提取网页内容。作者强调，Perl生态中的这些模块非常“给力”，特别是Web::Scraper，是他眼中完成此类任务“不二的选择”。 整篇文章的价值在于，它将网页自动化的常见任务拆解成了几个具体、可操作的步骤，并指明了各个步骤下最优的Perl模块工具。对于需要从编程层面处理网站交互的开发者来说，这提供了一套直接可用的实战思路和模块选型指南。
使用 Perl 实现 HTTP 代理
这篇讲的是在受限内网环境下快速搭建代理通道的轻量方案。作者面对一台没有外网权限的开发服务器，而内网段中恰好存在一台可联网的“跳板机”。由于不想复杂化网络配置（比如修改路由或部署 Squid），他选择用 Perl 手写了一个基础的 HTTP 代理服务。 核心思路很直接：在能联网的那台机器上运行这个 Perl 代理，内网服务器通过它中转请求，从而访问外部资源。文章聚焦于解决这一具体限制，展示了一个“最小可行”的实现。虽然实现简单，但清晰地指出了在特定网络策略下，利用身边已有工具快速打通链路的方法。 这种方案特别适合临时或轻量的开发调试场景。当标准网络设备配置流程耗时较长，或者你只需要为一两台机器解决临时访问需求时，这样一个由脚本驱动的临时代理，就成了一个灵活且易于部署的实用选择。
Perl 的线程中的锁
这篇文章聚焦于Perl线程中一个关键但容易棘手的主题——锁机制。作者原计划同时撰写锁与共享变量，但在准备过程中发现锁本身的内容已足够丰富，因此决定将其拆分为独立的篇章，这为读者提供了一个更为深入和专注的视角。 文章开篇对比了在Linux环境下线程与进程的主要区别，指出共享变量是核心差异之一。线程虽然更高效、资源占用更少，但也因共享内存而更容易引发并发问题，这自然引出了锁机制的重要性。随后，作者通过具体示例切入，旨在直白地展示Perl中如何处理锁以及可能遇到的相关问题。 整篇文章的脉络清晰，从背景对比到具体实现，逐步深入。它并未停留在概念罗列，而是准备通过实例来剖析锁的实际应用与潜在陷阱，为那些在多线程编程中遇到同步难题的开发者提供了切实的参考。
Perl 的线程中的共享
这篇讲的是 Perl 多线程编程中一个非常实用且核心的特性——变量共享。作者从进程与线程的根本区别切入，清晰地指出线程因为不额外创建独立的地址空间和控制块，所以内存占用更轻巧，但它能直接共享主进程的内存环境。 文章重点剖析了在线程中如何安全有效地使用共享变量。作者没有停留在概念层面，而是直接展示了 Perl 中使用 `threads::shared` 模块实现变量共享的具体方法，并解释了其背后的原理。这就像为并发操作提供了一个公共的“白板”，让不同线程能直接读写同一份数据。 当然，共享也意味着需要谨慎。文章也指出了由此可能引入的竞争条件问题，并隐含地说明了为什么在修改共享变量时需要配合锁机制。对于想在 Perl 中利用多线程提升程序性能，特别是进行任务分发或数据聚合的开发者来说，这篇文章提供了理解共享模型和潜在风险的扎实起点。
使用YUI 3开发Web应用的诀窍
这篇讲的是在YUI 3中，如何优雅地处理UI组件与内部数据模型同步时可能产生的事件冲突。作者从一个具体场景切入：当你通过代码设置文本框的值，并希望区分这次变更究竟是来自程序逻辑还是用户手动输入。 文章给出的方案非常直接且巧妙：在调用 `set` 函数时，利用其可选的第三个参数，将一个包含来源标识（如 `{source: 'UI'}`）的对象注入到属性变更事件的事件对象（event facade）中。这样一来，在监听 `valueChange` 事件时，就能从事件对象里清晰地判断出变更的源头。文中还附上了关键的事件绑定代码片段，展示了如何设置监听器。 这个技巧直接解决了数据绑定框架中的经典难题，为开发者提供了一种清晰的事件溯源思路，确保UI交互逻辑与数据操作逻辑能被准确区分和处理。
常用统计图说明
这篇讲的是作者在使用SAS作图时，被主管指出数据图形的表达方式存在问题后，进行的一次系统性学习梳理。文章没有直接展示成品图表，而是聚焦于SAS中8种基础统计图形的原理与适用场景。 作者从实际工作中遇到的“表达不准确”这一痛点出发，详细拆解了SAS支持的各种图形类型。虽然是一篇知识梳理，但背后指向的是数据分析中一个关键问题：如何选择正确的视觉形式来准确传达数据洞见，而不只是生成一个“能看”的图。文章强调，掌握每种图形的特性，才能在分析结果时做出更有效的表达选择。 对于使用SAS或其他统计软件进行数据分析和可视化的读者来说，这份总结相当于一份快速查阅的图形选择指南，能帮助你根据数据类型和表达目的，找到最匹配的图形工具。
最近遇到的问题整理(linux下创建线程内存泄漏,php的json_encode等)
这篇文章是作者近期在开发运维中遇到的几个实际问题的复盘与整理，核心聚焦于两个典型技术坑点的排查与解决。 第一个问题是关于Linux下创建线程时发生的内存泄漏。作者没有停留在表面，而是深入分析了根因，发现是由于线程属性设置不当导致的。文章详细说明了正确的创建方式，比如如何通过`pthread_attr_setstacksize`来合理分配栈空间，从而避免资源无谓的消耗。 第二个常见于PHP开发中。作者指出，当使用`json_encode`处理包含非UTF-8编码字符（如GBK）的字符串时，很容易因编码转换问题导致输出不符合预期甚至报错。文章给出了明确的解决方案，即先用`mb_convert_encoding`统一转码为UTF-8，再进行JSON序列化，这个细节对许多开发者都有实用价值。 此外，作者也一并解释了近期博客RSS/Atom订阅源（feeds）更新延迟的后台原因，让读者了解问题全貌。 整体来看，这篇不是空泛的理论，而是来自一线的问题诊断手册，涵盖了从系统编程到Web开发的具体陷阱及其修复路径，对遇到类似状况的工程师有直接的参考价值。
Erlang linkin driver用port_control方式时的一些经验分享
这篇讲的是作者在使用 Erlang Linked-In Driver 进行 Erlang 与 C 语言交互时，聚焦于 `port_control` 调用路径上的实战经验。核心问题是，当需要通过此机制传递复杂的数据结构时，如何高效且正确地完成数据的序列化与反序列化。 作者遇到的具体困境是，C 端代码在直接处理 Erlang 的外部术语格式（ETF）时，对复杂结构（如嵌套列表、元组）的构造与解析容易出错且效率不高。根因在于对 Erlang VM 与 C 之间数据传递的底层协议理解不够清晰，导致了序列化策略的偏差。 文章的解决思路是，分享了一种更为可靠和清晰的数据封装方法。作者没有选择完全依赖 ETF 进行复杂对象传递，而是在 C 端设计了一套与之匹配的序列化协议，将复杂数据结构“拍平”为更易于 C 语言操作的基础类型（如字节数组、长整型数组），再通过 `port_control` 进行高效传输。Erlang 端则对应进行解包。这种重新设计显著提升了代码的健壮性与维护性，避免了因格式解析错误导致的崩溃或数据错乱。 对于正在面临类似跨语言通信与数据结构映射难题的开发者，这篇文章提供了从踩坑到优化路径的一手参考。
HIVE中UDTF编写和使用
这篇讲的是 Hive 中一个非常实用但相对进阶的知识点：如何编写和使用 UDTF（用户自定义表生成函数）。文章开宗明义地介绍了 UDTF 的作用——它能够处理一行输入、生成多行输出，这是普通 UDF 无法做到的。 作者从基础概念切入，详细阐述了 UDTF 的核心应用场景，例如将复杂的 JSON 数组或 Map 结构“炸开”成多行记录。文章没有停留在理论，而是聚焦于实践：重点讲解了实现一个自定义 UDTF 所需的关键步骤，包括如何继承 `GenericUDTF` 类、实现 `initialize()`、`process()` 和 `close()` 方法，并特别强调了输出行的构造方法。 对于开发者而言，文中关于如何处理复杂数据类型（如 Struct 和 Array）的输入输出，以及如何通过 `forward()` 方法逐行发送结果的说明，是立刻可以用于解决实际问题的干货。文章也指出了在聚合操作中使用 UDTF 时需要配合 `LATERAL VIEW` 的正确语法。 整篇内容非常扎实，它把一个看似复杂的组件拆解得清晰明了，非常适合那些已经掌握 Hive 基础，但需要处理半结构化数据或进行复杂数据转换的开发者参考。
使用gcov完成代码覆盖率的测试
代码覆盖率测试是保障软件质量的重要环节，尤其对于使用GCC工具链的开发者而言。这篇文章深入介绍了GNU工具集中的gcov——一款免费且实用的代码覆盖率工具。作者从gcov的基本原理入手，逐步展开其使用方法，并着重分析了在实际项目集成中可能遇到的痛点，比如编译选项的影响、覆盖率数据的采集与解读等常见问题，并提供了清晰的解决思路。 文中还特别指出，gcov可以与lcov等前端工具结合，生成结构清晰、可视化的HTML格式测试报告，使覆盖率数据一目了然，便于团队跟踪与评审。对于希望以较低成本、较高效率将代码覆盖率测试融入开发流程的团队，这篇文章提供了一套从基础操作到问题排查的完整实践参考。
再谈“我是怎么招聘程序员的”
这篇是作者在近期进行了大量招聘、结合新的面试题讨论和身边案例后，对自己早年关于如何招聘程序员的观点进行的一次深化与补充。 文章核心聚焦于面试官的认知与方法。作者尖锐地指出，许多面试官未能区分操作、知识、经验与能力这四个层次。比如，能通过查阅手册完成的操作技能，只是“知其然”；而理解背后的原理才是“知其所以然”的知识。更重要的是，能力——体现为态度、思路、方法和风格——才是长期发展的关键，知识和经验只是其必要条件。 作者进一步批判了肤浅使用算法题和智力题的现象。他认为，解难题的重点不应是答案本身，而是通过此过程观察应聘者如何分解问题、应用知识、进行思考和沟通。面试应模拟真实工作场景中的持续挑战，例如在需求不断变化下如何维护代码质量或进行系统设计。 因此，作者呼吁面试官将应聘者视为未来的同事，采用讨论而非审问的互动方式。这样不仅能营造更自然的面试氛围，更能让面试官评估应聘者的真实能力与协作潜力，从而做出更准确的判断。