通过使用Chrome的开发者工具来学习JavaScript
这篇讲的是如何用Chrome开发者工具“看透”JavaScript的两个核心概念：闭包和内部属性。
作者从闭包这个经典话题切入，指出闭包的本质是函数持有外部作用域的变量，除了调用函数本身，外界无法访问。但Chrome的开发者工具让这种“隐藏”关系变得透明——在监控面板中展开函数，你能直接看到其下的 `
本机暂存
最新文章
采集自各技术站点的近期文章。
成长的财富，我做产品经理社区组织的这3年。
这篇讲的是PMCAFF创始人回顾自己从2008年到2012年，如何从一个学习者开始，一步步构建起一个有影响力的产品经理社区的三年历程。文章并非泛泛而谈，而是像一部编年史，记录了从零散QQ群到正式组织，从“蹭场地”的草根聚会到走进阿里、百度举办活动，再到尝试提供招聘服务、思考社区商业模式的全过程。 作者没有回避其中的窘迫与挣扎，比如早期缺乏经费、大公司初期不认可、组织者精力有限、以及草根社区在商业化与公益属性间的平衡困惑。他分享了许多具体的观察与发现，例如社区用户70%是渴望学习但基础一般的小白，30%是已积累资历的“潜水”者；又如，很多热情难以持续，需要机制来保障驱动力。 这篇文章最动人的地方在于它的坦诚与反思。它揭示了一个社区运营者真实的成长路径——不仅是帮助他人，更是自己获得了组织能力、人脉资源与行业认知的巨大“财富”。最后作者提到PMCAFF或许会走向更核心的资源对接网络，这为社区的未来留下了想象空间。
本机暂存
用户成长体系漫谈
这篇讲的是如何为网站设计用户成长体系。作者从几个国内典型网站出发，拆解了它们各自的成长体系设计思路与背后的逻辑。 文章对比了微博、QQ、豆瓣、知乎等平台的做法。比如，微博的成长体系紧密围绕其媒体战略，通过粉丝量、V认证和勋章来塑造和展示“牛人”，核心是满足用户的自我营销需求。腾讯QQ则依靠在线时长累积成长值，并结合虚拟币（Q币）消费，驱动力更多源于用户在社交圈中的虚拟身份满足感。相比之下，豆瓣的成长体系最为“隐藏”，它通过“小豆”和内容推荐，让用户在兴趣参与中自然体现价值，而非刻意追求等级，这体现了其产品气质。 作者指出，没有普适的公式，成长体系必须服务于产品定位。淘宝的等级与积分直接绑定交易，是电商驱动交易的典型；而知乎通过邀请码的稀缺性和基于专业认可的“关注”，构建了高质量社区的门槛。这些案例共同揭示了一个核心：好的成长体系，是将平台的商业目标与用户的核心价值感巧妙融合，无论是社交荣耀、内容贡献还是实际利益。
本机暂存
在熟练使用2B铅笔前，请不要打开Axure
这篇文章提醒产品经理和设计师，别让Axure成了思考的“捷径”。作者观察到，不少同行一上来就直奔Axure软件，沉迷于构建精细的交互原型，却往往跳过了用户故事、功能规格等更根本的前期构思，陷入了“无Axure不设计”的误区。 文章犀利地指出了几种典型的“Axure痴迷”症状：比如用Axure替代产品需求文档（PRD）、以实现复杂交互细节为成就感来源，或者很少使用铅笔和白板进行最直接的沟通。作者引用《用户体验的要素》理论指出，产品设计有不同的战略、范围、结构、框架和表现层级。Axure的核心价值在于“框架层”的交互界面设计，但如果在“结构层”甚至更早的阶段就过度使用它，就容易忽视对问题本身的定义和逻辑梳理。 作者的核心观点是，工具应服务于思维，而非束缚思维。他倡导在原型软件之外，回归到“2B铅笔”——即最原始、最低成本的草图和白板沟通。这种方式能帮助团队在初期更自由、更专注地探讨方案本质，避免过早陷入细节泥潭，从而提升整体产品设计的效率和质量。
本机暂存
“剥”出来的用户角色
这篇文章讲的是如何系统性地构建产品设计中的“用户角色模型”。作者从自己在活动页面和移动端游戏的实践经验出发，指出角色模型是设计决策的“指路灯”。创建过程就像剥洋葱，需要层层深入，先洞察用户的“灵魂”（目标、观点与行为），再为其披上人口统计学的“外衣”。 文章重点介绍了三种构建方法：定性人物角色、经定量验证的定性人物角色以及定量人物角色，并以阿里巴巴中文站交易线的项目为案例。过程中会遇到如何利用数据细分、设计问卷、进行交叉表分析等一系列常见问题，文中都给出了具体思路，例如按交易流程设计问卷维度、通过行为与观点矩阵细分用户群体。 除了方法论，文章还强调了几个关键的分析专题：结合交易记录与财务数据的CRM分析、寻找行为模式的网站流量分析，以及通过统计检验的定量验证方法。这些步骤共同确保最终形成的角色模型不是空洞的画像，而是能真正指导功能开发与交互设计的实用工具。
本机暂存
移动终端开发必备知识
这篇讲的是随着移动设备激增，如何高效开发调试WebAPP。文章从厘清基础概念入手，解释了CSS像素与设备像素的区别，以及PPI/DPI如何决定屏幕的默认缩放比例，这对于理解页面在不同手机上的显示差异至关重要。 核心内容对比了三种应对安卓设备碎片化的开发方案：“简单粗暴”方案虽省事但会导致高密度屏幕失真；“极致完美”方案通过device-dpi和媒体查询实现精准适配，但需为每种分辨率编写代码；作者推荐的“合理折中”方案则针对安卓市场主流（高密度设备）进行设计，用一套代码实现大部分设备的最优显示，在效果与成本间取得了平衡。 文章还分享了实战调试技巧，重点介绍了weinre工具的使用步骤，让开发者能在电脑上远程调试手机页面，并提及了AVD模拟器、手机抓包与配host等实用方法，覆盖了从布局认知到问题排查的全流程。
本机暂存
做云这三年
这篇讲的是新浪云计算负责人对自己负责云业务三年历程的回顾与思考。文章从作者早年自己折腾服务器的痛苦经历切入，引出了新浪云选择从PaaS平台（SAE）起步的缘由。 作者坦言，PaaS虽然为开发者带来了极高的性价比（例如微盘日均成本不足800元），但也是一把“双刃剑”。严格的平台规则带来了高性能，却也让大量既有应用迁移困难，并且由于“太省钱”导致市场难以支撑。面对这一困境，团队随后转向了兼容性更强的IaaS（SWS），并迅速通过拥抱开源（如OpenStack）打开了局面。 然而，故事的精彩之处在于，团队并未止步于单纯地售卖虚拟机。他们将PaaS的性价比优势与IaaS的兼容性优势结合，推出了混合云方案，有效降低了企业客户的总体成本。文章最具启发性的部分，可能是对“另类SaaS”——云商店的探索。团队巧妙地将标准PHP应用与隔离的云空间打包，通过三方模式（软件商、平台、用户）平衡了数据安全、业务可控性与应用丰富度等问题，为SaaS在国内的落地提供了一种务实思路。 文章最后，作者带着欣慰的口吻提到，看到SAE上诞生的各种创意应用、被高校用于教学，甚至成为内部效率工具时，深信他们的工作“改变了世界，也许就那么一点点”。这三年，是从技术理想走向解决真实商业问题的一段扎实旅程。
本机暂存
IE10 CSS hack
这篇讲的是Windows 8普及后，开发者发现不少网页在IE10中显示异常，一部分是旧版IE的CSS hack遗留问题，另一些则是新出现的兼容性问题。由于IE10不再支持条件注释，作者整理了几种针对IE10的CSS Hack方法。 首先是结合IE私有条件编译和JavaScript，在页面中为html元素添加“ie10”类名，从而通过选择器应用特定样式。另一种是利用IE10支持的“-ms-high-contrast”媒体查询特性，直接编写仅对该浏览器生效的CSS规则，不过这种方法也可能被未来版本继承。文章还提到了利用“min-width:0\0”这种hack同时覆盖IE9和IE10，但区分度不高。 作者在最后坦言，为IE专门编写hack是一件无奈的事情，这些方法都存在未来失效的风险，但它们确实是解决当前兼容性问题的实用技巧。
本机暂存
用pigz代替gzip
这篇讲的是一个名为pigz的并行压缩工具，作者通过实际测试，展示了它相比传统gzip在现代多核处理器上的巨大性能优势。 pigz的核心是利用多线程并发执行gzip算法。文章用两组大文件（约2.3GB和5.2GB）的压缩解压测试数据做了直观对比。结果显示，pigz在默认线程数下，压缩速度可达gzip的5.3倍。例如，压缩那个5.2GB的文件，pigz默认配置耗时1分12秒，而gzip则需要超过6分钟。解压缩同样快了一倍以上。虽然pigz会消耗更多CPU资源，但压缩比与gzip相当。 文章还深入分析了线程数与性能的关系。实测表明，从4线程增加到8线程能带来约41%的速度提升，但从8线程增加到16线程提升降至28%左右，而32线程对比16线程仅提升3%，存在明显的边际效益递减。 因此，结论很明确：在需要快速压缩大文件、且能接受短时间高CPU负载的场景下，pigz是一个能极大提升工作效率的替代方案。
本机暂存
关于《代码大全2e》
这篇讲的是一位普通程序员与《代码大全2e》长达两年的“纠葛”。作者坦言，自己是从“著名程序员”的推荐中买下了这本砖头，期望它能照亮“码农”迷茫的职业道路。然而，这本书他读了两年仍未读完，甚至直接用了“难看”来形容阅读体验。 所谓“难看”，一方面在于开篇就用三十多页探讨软件构建的重要性和隐喻，被作者戏称为“前戏过长”，足以消磨大部分读者的兴趣。另一方面，书中关于“程序=算法+数据结构”、管理复杂性等论述，在他看来又“太合乎常识”，读来仿佛不断在印证自己的既有认知，缺乏新奇感。 那么这本书到底值不值得看？作者给出了非常个人化且纠结的结论：对于那些知道正确方法却总找借口不用的人，看书是浪费时间；对于已经践行的读者，看书可能只是不断获得共鸣却收获有限。他最终坦承，自己坚持读下去的理由略显“可悲”——不甘心浪费买书的钱，以及一种要批评或称赞都得先读完的自尊。 在他看来，《代码大全》系统性地阐述了编码实践，这一点在众多编程书中绝无仅有，但它大概不会成为你书架上的经典。如果非要推荐一本编程书，它或许也不是首选。这篇文章的价值，恰在于这种来自一线码农的、毫不掩饰的真实阅读反馈。
本机暂存
PHP中return的用法
这篇讲的是PHP中`return`语句一个常被忽略的实用技巧。作者在研究Yii框架的配置文件时，注意到一个直接在脚本文件顶层返回数组的写法，这让他重新查阅了PHP官方文档。 原来，`return`不仅可以终止函数执行，当在全局作用域（即脚本文件的顶层）调用时，它能立即终止整个脚本文件的执行。更重要的是，如果该脚本是被`include`或`require`引入的，`return`后面的值会直接作为引入语句的返回值。 这个特性带来了一种更清晰、更直接的配置管理模式。对比传统的写法——在配置文件中定义一个全局数组变量，然后在其他地方通过`global`关键字去访问——新方式只需一行`$config = require('./config.php');`，就能直接获得配置数组。 这种做法避免了全局变量的污染，让数据的流向在引入那一刻就变得明确无误，代码也更为整洁。对于需要集中管理配置项的应用来说，这无疑是一个值得借鉴的实践。
本机暂存
两个精彩的比喻：吞吐量和延迟、信号量和互斥锁
这篇文章通过两个极其形象的比喻，澄清了计算机领域两对容易混淆的概念：吞吐量与延迟、信号量与互斥锁。 对于吞吐量和延迟，作者用ATM取钱打比方。一个人完成取款的时间是延迟，而整个银行每分钟能服务的人数是吞吐量。比喻生动地说明，增加ATM机数量（提高并行度）可以在延迟不变的情况下大幅提升吞吐量；而取钱后填写问卷（增加串行步骤）则会显著增加延迟，但吞吐量可能保持不变。这清晰地揭示了两者的核心区别：延迟衡量单个任务的体验，吞吐量衡量系统的整体产能。 关于信号量和互斥锁，作者改进了常见的“钥匙”比喻。互斥锁是独占的钥匙，拿到的人拥有唯一打开权。信号量则是一个大公共厕所门口的“可用/已满”指示牌，它代表的是可并发进入的资源数。文章特别指出了原比喻的不足，并用改进后的“牌子”比喻说清了关键差异：二元信号量的牌子（状态标志）可以被任何人翻动，而互斥锁的钥匙只能由拥有者打开。这个细微差别，正对应了状态协作与资源独占的不同使用场景。
本机暂存
tabIndent.js让你在Textarea中也能用Tab键
不少人都习惯在代码编辑器里用Tab键来缩进，但在网页表单的Textarea中按下这个键，焦点往往直接跳到了下一个输入框，这个习惯性的操作反而成了麻烦。 这篇介绍了一个小巧的JavaScript库——tabIndent.js，它正是为了解决这个具体痛点。作者的方案很直接：在页面中引入这个脚本，然后调用`tabIndent.renderAll()`一行代码，就能为所有class为“tabindent”的Textarea启用Tab键缩进功能。它将原本用于切换焦点的按键，还原成了开发者更熟悉的代码缩进行为。 对于需要快速搭建网页代码编辑器、或者希望统一用户输入体验的开发者来说，这提供了一个轻量且即插即用的解决方案。文章末尾也提供了GitHub仓库链接，方便读者进一步了解和获取源码。
本机暂存
我是产品经理我需不需要学技术？
这篇讲的是产品经理是否需要学技术，以及应该怎么学。作者以自身从技术转产品的经历出发，认为PM确实需要懂技术——这不仅能帮你抓住AR、无线充电等前沿机会，也能让你和开发沟通时不再“被当猴子”。 不过，PM不必（也很难）精通编程细节。作者提出的学习方法核心是：关注技术的原理、边界和成本。比如，了解无线充电或文件传输的基本原理，能让你建立整体认知；关注iOS早期应用数据隔离的“边界”，才能明白为何需要开发专属组件；而避开拖拽效果这类“细节黑洞”，或不盲目依赖不成熟的开源方案，才能有效评估开发时间。文章还提到，像PhoneGap这类技术正在降低多端开发成本。 总的来说，作者主张PM应从产品视角理解技术，把握其能做什么、受什么限制、要花多少代价，从而做出更明智的产品决策。
本机暂存
PHP业务逻辑层和数据访问层设计
这篇讲的是PHP项目中如何合理设计业务逻辑层与数据访问层。作者从面向对象的基本原则出发，探讨了在MVC架构下，模型（Model）层究竟该承担什么职责。 文章指出，项目规模和复杂度决定了分层的必要性。对于业务简单、数据库固定的小项目，采用表模块或活动记录模式将业务逻辑与数据访问合并，反而更高效。但随着需求膨胀，就需要清晰划分：业务逻辑层应基于“领域模型”来实现，专注于对象属性与行为的描述；数据访问层则为业务层提供数据支持。 在数据访问层的具体模式选择上，作者对比了表数据入口、行数据入口、活动记录和数据映射器等经典方案。考虑到PHP语言特性（如灵活的数组操作、开发者对SQL的偏好）以及多数项目数据库变动少的现实，作者认为“表数据入口”模式是更务实的选择。最终结论是，理想的PHP应用架构是：用领域模型构建业务逻辑，通过表数据入口模式实现数据访问层，让开发能更专注于领域行为本身。
本机暂存
如何在XP下查看系统开机时间及系统运行时长
这篇讲的是如何在Windows XP下快速查看系统启动时间，解决上班族对是否“早退”的小纠结。作者从三个实用角度出发，介绍了无需登录考勤系统就能自查的方法。 最简单的是在命令行运行`systeminfo`，系统摘要里直接显示启动时间。如果该命令不可用，`net statistics WORKSTATION`的第一行同样能提供准确的统计时间。对于需要更详细记录的用户，微软的`Uptime`工具可以生成完整的系统开关机日志。 文章也客观对比了各方法的差异。`systeminfo`和`net statistics`是系统自带、方便快捷；`Uptime`功能更强，但依赖于Event Log服务，其准确性受服务状态和系统权限影响。此外，文章还贴心地补充了`systeminfo`命令缺失时的修复步骤，比如检查系统路径或从别处拷贝，确保方法真正可用。对于仍在使用XP的用户，这些命令行技巧是高效掌握系统状态的便捷途径。
本机暂存
Windows tasklist命令使用说明
这篇讲的是Windows中一个强大但常被忽视的命令行工具——tasklist。 它解决了在图形化任务管理器中无法直接查看进程关联服务的痛点。文章系统梳理了tasklist的多种用法，从基础的本机进程列表，到通过特定参数（如/s、/u、/p）查看远程系统进程，实用性很强。 特别值得注意的是，它用/svc参数可以直接显示每个进程（尤其是像svchost.exe这样承载多项服务的进程）所对应的具体服务，这对于排查系统问题非常有帮助。此外，文章还演示了如何调用指定DLL模块的进程、使用筛选器精确查找特定状态进程（例如正在运行的非SYSTEM进程），以及输出为表格、列表或CSV格式以便进一步分析。 最后，文章自然地带出了它的“孪生兄弟”taskkill，形成了一个“查找-终止”的完整操作闭环，让读者不仅知道如何看，还知道下一步如何处理进程。
本机暂存
用Bloom Filter的方式统计网络流量
作者从网站面临爬虫攻击和恶意访问的现实问题出发，想要高效统计每个IP的日访问量以识别机器人。传统的Map计数法可能消耗数百兆内存，而文章介绍了一种基于Bloom Filter思想的变体算法，可以在极低的内存占用（O(1)空间复杂度）下完成计数。 这个方案的核心是使用一个二维数组和多个独立的哈希函数。每次访问到来时，不是增加所有对应位置的计数器，而是只增加这m个计数器中值最小的那一个。这种方法巧妙地将Bloom Filter的“是否存在”判断，扩展为了“计数”的近似统计。当然，它继承了Bloom Filter可能存在的假阳性特点——可能误判某些低频IP为机器人，但可以通过调整数组大小和哈希函数数量来控制误差率。 文章还由此类比了《编程之美》中一个经典的微软面试题，并进一步提出了扩展问题：如果要统计的不是访问次数，而是IP的入/出流量，该如何设计算法？这为读者提供了更广阔的思考空间。
本机暂存
基数估计算法概览
这篇讲的是如何在海量数据中，高效估算不同元素的个数——也就是基数估计。 文章从一个经典场景切入：面对一个大到无法放入内存、且含有大量重复项的数据集，怎样才能快速知道里面有多少不同的数据项？作者首先介绍了一种直观但粗糙的思路：通过哈希将数据映射成均匀分布的随机数，再利用集合中的最小值来反推基数。这个方法虽然简单，但准确度不稳定。 真正的突破来自概率算法。文章重点介绍了Flajolet等学者发展的方法：通过一个良好的哈希函数，将任意数据转化为均匀分布的序列。算法巧妙的观察点在于，考察每个哈希值的二进制表示前导零的长度。在均匀分布下，最长前导零的长度与集合基数存在明确的统计关系。这避免了直接存储所有元素，只需记录一个极小的状态信息。 从最初的Probabilistic Counting，到LogLog，再到近似最优的HyperLogLog算法，文章勾勒出这类算法的发展脉络。HyperLogLog通过分桶统计和调和平均数，极大地提升了估计精度，并已成为Redis等系统中处理UV统计等场景的标准方案。 对于任何需要在大规模数据流上进行实时去重计数的工程师来说，理解这些算法的原理与取舍都非常有价值。
本机暂存
国内团购网前端严重安全漏洞– 以满座网为案例分析
这篇讲的是作者以满座网为例，深入剖析了一个典型的前端安全漏洞。文章从日常技术排查出发，演示了如何利用浏览器开发工具（Firebug）和简单的jQuery命令，绕过团购页面对商品购买数量的前端限制。 作者发现，尽管网站前端代码设置了最多999件的购买上限，但这一限制仅存在于客户端。通过修改本地参数，理论上可以提交极大数量的订单。这个漏洞的根源在于“前端不信任后端，后端不信任前端”这一基本安全原则被忽视。仅依赖前端进行关键业务逻辑校验（如数量、价格），而缺乏后端的有效复核，为系统留下了风险。 案例的警示意义很直接：在Web 2.0时代，JavaScript和Ajax的便利不应以牺牲安全性为代价。对于涉及交易的系统，任何关键数据都必须在服务端进行严格校验。文章也借此提醒开发者，构建可靠的应用需要将安全成本纳入整体规划，不能心存侥幸。
本机暂存