nginx模块开发
这篇讲的是作者从零开始，完成自己第一个Nginx模块的实践记录。作者在实际工作中遇到了需要定制Nginx功能的需求，于是着手学习模块开发。他从梳理Nginx模块的代码结构与编译机制入手，阅读官方文档与核心源码，最终将一个基础的计数器模块从构想变为现实。 文章没有停留在理论，而是重点分享了“如何让代码跑起来”的关键步骤：如何配置编译参数、如何定义模块的配置项和处理函数、如何在模块中与Nginx的内存池和事件模型交互。这些细节是新手最容易卡壳的地方。 Nginx的高性能背后是一套严谨而独特的C语言框架，其模块开发并非简单调用API。作者通过这个最小化的实践，揭示了编写Nginx模块的核心思路——遵循其特定的数据结构与生命周期，将功能逻辑“嵌入”到请求处理的流程中。这个从无到有的过程，为理解Nginx内部工作原理和后续进行更复杂的开发打下了切实的基础。
iPhone下的libcurl with SSL for iOS
这篇讲的是作者在开发首个iPhone应用时，如何解决移动端网络请求中SSL加密连接的具体实践。作者从项目需求出发，选择了libcurl作为网络库，但发现在iOS平台上默认配置并不支持SSL功能。文章详细梳理了针对iOS环境重新编译和集成libcurl的过程，核心是通过交叉编译工具链生成适配ARM架构的静态库，并正确处理OpenSSL依赖的链接。其中提到了Xcode工程配置中容易遗漏的链接器标志设置和头文件路径管理等关键细节，对于同样需要在该平台使用libcurl的开发者，提供了从环境搭建到最终调用的完整实施路径。
FlashCookie
这篇讲的是如何利用Flash绕过浏览器对Cookie的清理限制，实现用户数据的持久化存储。文章从实际场景出发——普通Cookie会被浏览器轻易清除，导致用户偏好或登录状态无法长期保留。作者引入了FlashCookie这一方案，它利用Flash在用户本地文件系统中存储数据，完全独立于浏览器的Cookie管理机制，因此即使用户清空浏览器缓存，这些数据依然存在。文章还对比了普通Cookie与FlashCookie在持久性、容量以及管理方式上的关键差异：普通Cookie通常只有几KB且易清除，而FlashCookie可以达到上百KB，并且能静默保存。这种方案尤其适用于需要跨会话跟踪用户行为的广告或分析场景。不过随着Flash技术的逐渐淘汰，这种思路也演变为对HTML5本地存储等现代技术的借鉴，为处理客户端数据持久性问题提供了另一种视角。
[演讲稿]OAuth1.0协议
这篇讲的是OAuth1.0协议本身。作为OAuth标准的“开山之作”，这份演讲稿深入剖析了它如何解决一个核心痛点：让第三方应用在不获取用户密码的前提下，安全地获取对用户资源的有限访问权限。 内容从协议的诞生背景切入，详细拆解了其“委托授权”的核心设计原则。最值得玩味的是它的流程设计，尤其是那个要求所有请求都必须携带数字签名的机制。这个签名过程虽然极大地增强了安全性，有效防止了请求被篡改和重放攻击，但也导致了实现起来相当繁琐，客户端和服务端都需要处理复杂的签名逻辑。 因此，讲解中自然也会将它与更主流的OAuth2.0进行对比。一个关键区别在于，OAuth1.0强制使用签名，而OAuth2.0则完全依赖TLS（HTTPS）来保证传输安全，从而大大简化了流程。这使得OAuth2.0在移动和Web应用中更为流行，但OAuth1.0那种对客户端密钥和请求签名的严格校验，在某些对安全性要求极高、系统架构相对传统的场景下，依然有其不可替代的价值。
在sae中利用SaeFetchurl进行豆瓣的OAuth授权
这篇讲的是如何在新浪SAE平台上实现豆瓣“我说”功能的同步。作者从实际需求出发——需要在SAE环境中自动化处理内容同步，核心挑战在于如何安全、可靠地完成豆瓣的OAuth授权流程。文章的关键方案是利用SAE自带的SaeFetchurl工具，它模拟浏览器行为来处理OAuth的重定向和令牌获取，巧妙地绕过了服务器环境下直接跳转授权的限制。 具体实现中，作者详细拆解了授权流程：从构造授权链接、引导用户跳转，到回调处理、使用access_token调用豆瓣API。特别值得注意的是对SaeFetchurl的运用，它不仅承担了HTTP请求的功能，更在保持会话（Session）状态和处理复杂的多步授权中扮演了关键角色。最终，这套方案成功实现了在SAE的PHP环境中自动化完成授权，使得后续的“我说”内容同步得以稳定运行。 对于同样在受限云环境中需要对接第三方OAuth服务的开发者来说，这个利用平台内置工具解决特定痛点的思路，提供了非常实用的参考。
OAuth 1.0a与1.0协议的改进…
这篇文章解析了OAuth 1.0a与1.0的核心差异与改进动机。作者从OAuth 1.0在实际部署中暴露的安全风险出发，指出其最大缺陷在于未对回调URL进行严格验证，这使得攻击者可以发起CSRF攻击，窃取用户授权令牌。OAuth 1.0a的关键改进正是针对这一漏洞，强制要求在请求中包含一个由客户端生成的临时验证码（oauth_verifier），并在用户授权后由服务端校验，从而确保回调请求的真实性。文章不仅解释了这一安全机制的技术原理，还对比了1.0与1.0a在签名计算、流程复杂度上的不同。对于开发者而言，理解这个演变至关重要——它直接关系到应用授权过程是否可靠。文章最后也明确指出，在当今的安全环境下，任何新系统都不应再采用原始的1.0协议，升级到1.0a或更新的标准（如OAuth 2.0）是保障用户安全的必要步骤。
神奇的两次按位非运算符
这篇讲的是JavaScript中一个相当冷门但巧妙的取整技巧：对一个数字连续使用两次按位非运算符 `~~`，其效果在大多数情况下等同于 `Math.floor`。 作者从James Padolsey的博客中引出了这个知识点，并直接进行了关键对比。虽然表面上看两者都是向下取整，但核心差异在于底层处理的数据范围。按位非运算符会将操作数先转换为32位整数，这意味着它对超过32位整数范围的大数和负数会产生与`Math.floor`不同的结果。例如，`~~1.99` 会得到 `1`，而 `~~3000000000.5` 会得到一个意想不到的负值，因为数值在按位运算中被截断了。`Math.floor` 则稳健地处理IEEE 754标准的64位浮点数。 因此，两者的适用场景泾渭分明。`Math.floor` 是通用、可预测的数学函数首选。而 `~~` 的优势则在于其极致的简洁和执行速度，它本质上是一个位运算，对于性能敏感且数值已知在安全范围内的场景（如数组索引、简单的像素坐标计算），可以成为一个非常高效的替代方案。这个小技巧虽然不常用，但它揭示了JavaScript在数字处理和类型转换上的一些底层特性，为理解语言灵活性提供了又一个有趣的视角。
深入理解OAuth与豆瓣OAuth test
这篇讲的是OAuth协议的原理及其在豆瓣开放平台的实际应用。作者从“OAuth为何成为互联网标配”这个现象切入，没有停留在枯燥的规范解读上，而是以豆瓣的API测试为具体案例，带读者走了一遍从创建应用、获取令牌到调用接口的完整流程。文章亮点在于结合了豆瓣平台的实际特点，详细拆解了请求令牌、用户授权、访问令牌等关键步骤中参数的含义与作用，并指出了诸如回调地址设置、权限范围选择等容易踩坑的实践细节。 更重要的是，它揭示了OAuth授权流程背后的核心思想——如何在不暴露用户密码的前提下，安全地让第三方应用有限地访问资源。通过对豆瓣实现的分析，文章也间接对比了OAuth 1.0与2.0在安全性与易用性上的不同取向。对于开发者来说，这篇内容不仅能帮助理解OAuth的“道”，也能通过豆瓣这个真实案例掌握其“术”，在对接其他遵循OAuth标准的平台时会更有头绪。
include_path+__autoload与数组+__autoload的比较
这篇讲的是作者从PHP的__autoload机制出发，比较了两种类加载策略：依赖include_path的传统方式和基于数组缓存的新兴方法。文章先回顾了include_path的原理——PHP通过配置的目录路径自动搜索类文件，虽然配置简单，但在大型项目中频繁的文件系统查找可能带来性能损耗。随后，作者提出了一种替代方案：维护一个关联数组，将类名映射到确切的文件路径，从而在__autoload函数中直接加载，减少了运行时的目录遍历。关键差异在于效率和可维护性：数组缓存显著降低了IO开销，加速了类加载，尤其适合类文件众多的复杂应用；而include_path的自动化在小型项目中更省心，无需额外管理映射。文章结合了代码示例和实际场景分析，指出数组缓存虽然需要开发者手动更新映射关系，但在高性能需求下能带来明显优化。最后，作者建议根据项目规模灵活选择，为PHP开发者优化自动加载提供了清晰思路。
在编译php-fpm0.6的时候需要注意的一些问题
这篇讲的是PHP-FPM 0.6版本编译时容易踩的坑。作者指出，虽然php-fpm 0.6早已发布，并且在应对如fix_pathinfo这类漏洞时比0.5系列更有优势，但不少开发者可能仍停留在旧版本。文章从实际编译经验出发，提醒大家升级到0.6时需要留意的特定问题。 具体来说，编译过程中可能会遇到配置参数的变化、依赖库版本不匹配，或是与现有PHP扩展的兼容性问题。作者通过梳理这些常见的“坑点”，帮助读者提前规避，确保平滑升级。对于仍在使用PHP-FPM 0.5，或计划尝试新版本的运维和开发人员来说，这些细节经验可以避免不必要的排错时间。
我们来做一个会呼吸的菜单吧!!
这篇讲的是前端如何实现一个带有呼吸动画效果的菜单组件。作者从日常浏览中获得灵感，决定尝试分享自己动手实现的思路。 文章聚焦于一个具体的交互设计：“会呼吸的菜单”。作者没有直接套用现有案例，而是记录了自己从观察、构思到编码的完整过程。核心实现围绕 CSS3 动画或 JavaScript 定时控制，通过周期性调整菜单项（比如背景透明度、边框阴影或尺寸）的样式属性，模拟出类似呼吸的起伏律动感。 巧妙之处在于将静态的导航元素动态化，为页面增添了生命力。这种微交互不涉及复杂框架，主要依赖对动画细节（如缓动函数、周期节奏）的精准把控，是提升界面亲和力的轻量级方案。 如果你正在寻找为常规组件注入一点灵动感的实践方法，这个小而美的案例展示了一个可行的起点。
使用PHP将大文件导入到数据库中..
这篇讲的是一个相当实际的场景：如何用PHP把170万行的txt文件数据可靠地导入数据库。作者没有直接给出一个简单的`file_get_contents`或暴力循环方案，而是直面了大文件处理的核心矛盾——内存占用与执行时间。 他选择的方案核心是“分块处理”与“事务控制”。作者没有试图一次性将文件读入内存，而是利用了PHP的文件指针和行读取特性，边读边处理，极大地降低了内存峰值。在数据库操作端，他没有选择逐行插入，而是采用了批量插入的策略，并用事务包裹，确保了在提升效率的同时，要么全部成功，要么全部回滚，保障了数据的一致性。 文章里详细展示了如何控制每批插入的数量（比如1000条），以及在出错时如何处理和记录。最终效果是，这套方法在有限的服务器资源下，稳定、快速地完成了海量数据的导入，避免了常见的内存溢出和执行超时问题。对于经常需要处理类似ETL任务的开发者来说，这是一个既基础又关键的实践范例。
jQuery中getJSON跨域原理详解
这篇讲的是作者在开发一个浏览器工具时，为了实现“获取页面短网址”功能，深入剖析了jQuery中getJSON方法实现跨域请求的原理。 文章并没有停留在API的简单调用层面，而是直接点出了Web安全的同源策略这一根本限制。接着，它解释了getJSON背后实际依赖的JSONP技术是如何巧妙地绕过这一限制的：通过动态创建