如何通过互联网出版一本小书
这篇讲的是作者如何将一篇“写一本书”的愿望清单落地，并分享其中关于工具、渠道与心态的完整实践经验。 工具上，他推荐技术作者使用GitBook，因为它支持Markdown、能一键生成多种电子书格式，并可拖拽调整章节。他也坦诚提到了早期版本在中文支持上遇到的小坑，建议可搭配其他编辑器使用。 分发渠道部分对比详细：自建页面如SelfStore流程简单但需自行推广；百度阅读自带编辑器且支持版权控制，但平台流量有限；多看、亚马逊等主流平台则需通过BookDNA等代理上架，作者指出这类代理虽能扩大覆盖面，但存在收益反馈滞后和版权授权的风险。 最重要的是心得：他发现2-3万字聚焦细分领域的“小书”同样有出版机会，这打破了必须靠篇幅“凑数”的传统观念。作者鼓励技术人员从经营系列博文开始，逐步积累，未来无论是自出版还是联系出版社，都会更为从容。这为许多想系统化整理知识但畏惧“出书”工程量的人，提供了一条清晰的轻量路径。
互联网公司和软件工程那些事
这篇从作者在新浪的一次通宵加班经历讲起，具体描绘了当年大型项目开发时，团队如何在高强度工作中依然面临延期困境。由此，他开始了对软件工程的长期思考。 作者的核心发现是，延期问题的根源往往在于需求定义的粗糙。在他后来负责新浪云计算项目时，通过将需求分解到技术实现级别，做到了以小时为单位的精准排期，将延期控制在极小范围内。这揭示了互联网时代需求与开发关系的本质变化。 在质量控制方面，文章分享了两个生动实践：一是为降低技术门槛而设计的LazyPHP框架，二是通过资源配额实现代码优化的新浪云平台策略。同时强调，单元测试、编码规则等硬性指标必须集成到发布系统中，形成自动化约束。 最终，作者提出了一个前瞻性观点：传统的“软件工程”概念已经过时。他主张未来会走向“产品工程”，即以产品为核心、以天为周期的全流程迭代，并认为大型技术团队将分化为平台支撑与业务实现两类角色。文章融合了个人实战经验与行业趋势洞察，对互联网时代的技术管理方式提出了独到反思。
程序人生的四个象限和两条主线
作者从自己的创业经历和与程序员们的交流出发，发现大多数技术人员的职业路径其实存在共通的模式。文章借用《穷爸爸富爸爸》的四个象限框架，解读了程序员可能处的不同阶段：从风险最小的E象限（雇员），到追求自由与收益的S象限（自由职业/小企业主），再到以规模化为目标的B象限（创业或成为上市CTO），以及最终追求财务自由的I象限（投资者）。 但真正驱动前进的，是个人成长。作者重点剖析了两条核心成长主线：技术线和管理线。选择技术线，关键在于看准并长期投入一个有潜力的技术方向。作者以自身从PHP开发受益的经历为例，强调了观察技术潮流（如多屏时代对API和云存储的需求）以及投资新兴或细分市场（如早期学习iOS、或结合安全深耕PHP）的重要性。 而管理线则更像一场持续的升级游戏，title和阶段性成果至关重要。作者直言，在利用关系普遍的职场，必须主动为自己规划。通过有策略的跳槽（间隔2-3年）来争取更好的空间、资源和职级，是实现从工程师到CTO跃迁的常见路径。文章最后以身边同事的案例，点出了自我规划的现实必要性。
做产品到底要不要听用户反馈？
从一句关于乔布斯是否听用户的玩笑话出发，这篇文章直击产品经理的老问题：到底要不要听用户反馈？作者的观点很犀利——要听，但只听“事实”，不接受“建议”。 他把用户反馈清晰地分为两类：一类是客观事实，比如“登录功能出错了”；另一类是用户主观给出的解决方案，比如“为什么不这样收费呢”。作者的核心逻辑是，反馈事实是用户的权利，而判断问题、设计方案是产品经理的专业职责，两者不可混淆。他强调，绝大多数用户并不了解产品背后的战略和数据，他们的“建议”往往并不可靠。 不过，作者并非完全拒绝倾听。他指出，在扔掉那些“建议”之前，必须深挖其背后隐藏的事实：用户究竟遇到了什么场景？现有功能为何失效？这些挖掘往往能直接指向产品的设计缺陷。这个原则同样适用于来自老板或资深同事的建议——对结果负责的，始终是产品经理自己。 这篇文章为产品决策提供了一个清晰的过滤框架：专注于识别真实问题，同时勇敢捍卫自己的专业判断权。
从WordPress看开源平台的发展
这篇讲的是开源平台如何从技术理想走向商业现实的深度思考。作者从一组惊人数据切入：全球六分之一的网站基于WordPress搭建，其在头部网站中的渗透率甚至超过了Facebook这类中心化开放平台。 文章的核心观点犀利：开源平台（如WordPress）的价值不仅在于像传统开放平台那样“释放控制权”，更在于“释放所有权”——即使开发公司消失，用户依然能安全使用。这种模式通过构建可持续的多方受益生态来实现商业价值：WordPress严格区分核心代码与插件版权，允许开发者自由选择授权并盈利，而官方则通过托管、安全等增值服务变现，形成了缓慢但稳固的增长飞轮。 更巧妙的是对用户行为的引导。WordPress并未强硬禁止修改代码，而是提供“一键升级”的极致体验——这实则激励开发者将个性化改动封装为插件，一举实现了优秀的用户体验、核心代码稳定性和生态繁荣的三重目标。 文章最终跳出了代码细节，揭示了开源项目成功的关键在于艺术地平衡多方利益，实现真正的共赢。对于想理解开源生态运作逻辑的读者，这提供了一个从实践到哲学的观察样本。
TeamToy完全使用手册
这是一份姗姗来迟的TeamToy使用手册，作者从理念到实操完整梳理了这个为创新团队打造的效率工具。TeamToy的核心理念是“以事为核心”而非“以人为核心”，它将TODO列表设为默认界面，旨在提升团队效率而非增加干扰。文章详细阐述了其产品结构：核心功能聚焦于任务与多层次沟通，而插件体系则为项目管理、Bug追踪及各类服务整合提供了扩展空间。 技术上，TeamToy实现了全功能的接口化，并保持敏捷的更新节奏。它采用对非商业用户友好的GPL2开源协议，并强调用户可以完全自主掌控数据与部署。安装部分提供了清晰的路径：非技术团队可通过云商店快速部署，而自建服务器则需满足PHP、MySQL等特定环境要求，文中对配置文件修改等关键步骤给出了明确指引。 文章的后半部分转入“最佳实践”，以添加团队成员等操作为例，提供了具体、分步骤的图解说明。作者旨在帮助团队负责人快速建立自上而下的理解，避开常见问题，顺利启动并运用这个工具来优化协作流程。
一路读来 – 那些曾改变我思维轨迹的书
作者在新年假期整理了一份改变自己思维轨迹的书单，从学习方法、软件开发、设计思维延伸到商业与人生。这份清单的核心脉络，是一位技术人如何通过阅读构建起跨领域的认知框架。 起点是高中读的《学习的革命》，它引发了作者对传统教育的质疑。到了大学阶段，《程序员修炼之道》与《敏捷软件开发》将敏捷开发从理念落地为具体实践，确立了实用主义的工作方式。而《交互设计之路》和《设计中的设计》则引导他将视角从纯技术转向用户心智和产品体验，认识到设计是产品不可分割的一部分。 思维的拓展不止于技术本身。《富爸爸，穷爸爸》重塑了他的财富观，强调资产与事业的构建；《精益创业》则将敏捷思想扩大为完整的产品制造方法论，其“验证认知”和MVP理念极具工具价值。此外，《引爆点》解析了产品流行的机制，《日本漫画为什么有趣》训练了他从符号本质看事物的能力。最后，书单以《生命之光》收束，指向对身心平衡与生活细节的珍视。 这并非一份简单的书目罗列，而是一位创作者思维演进的连续体。作者通过定期重读，不断校准和深化自己在技术、商业与生活层面的思考。
从精益开发到精益创业
这篇讲的是《精益创业》如何为陷入困境的产品开发指明一条实用路径。 作者从当下创业热潮与众多产品“叫好不叫座”的矛盾现象切入，直指问题核心：无论是过于关注技术实现的工程师，还是精心打磨细节的产品经理，都可能陷入“会跳舞的熊”的陷阱——产品功能齐全，却唯独缺少用户愿意使用的理由。在移动互联网这个需求剧烈变动的领域，传统经验频繁失效。 文章推荐的《精益创业》方法论恰好回应了这一痛点。它本质上是将敏捷开发的思想从单纯的代码编写，扩展到了整个产品流程。其精髓在于建立一个“构建-测量-学习”的快速迭代循环：先用最小可用产品验证核心商业假设，再通过“创新核算”用同期群等数据方式精确衡量增长。一个功能的增减，都必须服务于假设验证或增长目标，而非主观臆断。 作者结合自身项目实践分享了成效：团队用两个月开发出最小可用版本，通过数据验证了用户支付意愿，并利用A/B测试优化了客单价。这证明，将方法论融入日常工作，才能真正应对不确定性，让产品从“设计”走向“验证”，最终走向成功。
做云这三年
这篇讲的是新浪云计算负责人对自己负责云业务三年历程的回顾与思考。文章从作者早年自己折腾服务器的痛苦经历切入，引出了新浪云选择从PaaS平台（SAE）起步的缘由。 作者坦言，PaaS虽然为开发者带来了极高的性价比（例如微盘日均成本不足800元），但也是一把“双刃剑”。严格的平台规则带来了高性能，却也让大量既有应用迁移困难，并且由于“太省钱”导致市场难以支撑。面对这一困境，团队随后转向了兼容性更强的IaaS（SWS），并迅速通过拥抱开源（如OpenStack）打开了局面。 然而，故事的精彩之处在于，团队并未止步于单纯地售卖虚拟机。他们将PaaS的性价比优势与IaaS的兼容性优势结合，推出了混合云方案，有效降低了企业客户的总体成本。文章最具启发性的部分，可能是对“另类SaaS”——云商店的探索。团队巧妙地将标准PHP应用与隔离的云空间打包，通过三方模式（软件商、平台、用户）平衡了数据安全、业务可控性与应用丰富度等问题，为SaaS在国内的落地提供了一种务实思路。 文章最后，作者带着欣慰的口吻提到，看到SAE上诞生的各种创意应用、被高校用于教学，甚至成为内部效率工具时，深信他们的工作“改变了世界，也许就那么一点点”。这三年，是从技术理想走向解决真实商业问题的一段扎实旅程。
tabIndent.js让你在Textarea中也能用Tab键
不少人都习惯在代码编辑器里用Tab键来缩进，但在网页表单的Textarea中按下这个键，焦点往往直接跳到了下一个输入框，这个习惯性的操作反而成了麻烦。 这篇介绍了一个小巧的JavaScript库——tabIndent.js，它正是为了解决这个具体痛点。作者的方案很直接：在页面中引入这个脚本，然后调用`tabIndent.renderAll()`一行代码，就能为所有class为“tabindent”的Textarea启用Tab键缩进功能。它将原本用于切换焦点的按键，还原成了开发者更熟悉的代码缩进行为。 对于需要快速搭建网页代码编辑器、或者希望统一用户输入体验的开发者来说，这提供了一个轻量且即插即用的解决方案。文章末尾也提供了GitHub仓库链接，方便读者进一步了解和获取源码。
我是产品经理我需不需要学技术？
这篇讲的是产品经理是否需要学技术，以及应该怎么学。作者以自身从技术转产品的经历出发，认为PM确实需要懂技术——这不仅能帮你抓住AR、无线充电等前沿机会，也能让你和开发沟通时不再“被当猴子”。 不过，PM不必（也很难）精通编程细节。作者提出的学习方法核心是：关注技术的原理、边界和成本。比如，了解无线充电或文件传输的基本原理，能让你建立整体认知；关注iOS早期应用数据隔离的“边界”，才能明白为何需要开发专属组件；而避开拖拽效果这类“细节黑洞”，或不盲目依赖不成熟的开源方案，才能有效评估开发时间。文章还提到，像PhoneGap这类技术正在降低多端开发成本。 总的来说，作者主张PM应从产品视角理解技术，把握其能做什么、受什么限制、要花多少代价，从而做出更明智的产品决策。
网盘背后的数据消费需求
这篇讲的是网盘这类我们习以为常的服务，背后其实涌动着一套复杂的数据消费需求。作者从日常使用网盘上传、分享文件的体验出发，拆解了用户行为背后更深层的动机——我们不再仅仅满足于“存储”，而是在“使用”数据的过程中，催生了对即时访问、无缝协同、智能管理乃至数据资产化的期待。 文章剖析了这种消费需求如何反过来驱动网盘产品和技术架构的演变，比如从单纯的存储空间竞争，转向对文件预览速度、多端同步效率、版本控制精度乃至数据安全合规性的全面比拼。它点出了一个关键转变：网盘的核心价值正从“数据的仓库”向“数据的中枢”迁移，如何高效、安全地满足用户在不同场景下对数据的“消费”需求，成了新的技术赛点。 对于技术人来说，这提供了一个有趣的视角——后端架构的复杂设计和优化，最终都是为了支撑前端看似简单流畅的数据交互体验。
一个简单的基于PhoneGap的开源微博客户端
这篇讲的是如何用PhoneGap这类跨平台框架突破其自身局限，构建一个完整的开源微博客户端。作者从一个常见的质疑出发——有人说PhoneGap只能做简单应用，无法胜任微博客户端这类复杂需求——然后点出了核心矛盾：仅仅依赖PhoneGap的标准API，确实搞不定像OAuth认证这种流程，页面跳转容易“迷路”。 但作者随即给出了关键解法：别忘了PhoneGap的插件系统。他指路到GitHub上的插件库，明确指出那里已经有现成的、成熟的OAuth2插件（例如Facebook登录插件），这直接解决了认证难题。为了验证这个思路，作者实际动手做出了一个可用的开源微博客户端。这个案例不仅反驳了最初的质疑，更清晰地展示了一种开发范式：当框架标准能力不足时，通过其强大的扩展生态来补足，依然能驾驭复杂应用。
PhoneGap开发不可或缺的五件装备
这篇针对PhoneGap开发者的文章，系统梳理了五款能显著提升工作效率的核心工具，从轻量级的JQuery兼容库切入，深入对比了JQ.mobi与Zepto等库的关键差异。
5分钟搞定你的Rest Server
作者在开发了多个Rest Server后，对重复进行数据表增删改查、输入输出过滤这类机械性工作感到厌倦，因此思考并实践了一套高效构建Rest Server的方法。这篇文章正是针对这一普遍痛点，给出了一个能在5分钟内快速搭建起一个完整Rest Server的解决方案。 核心思路是通过模板化和自动化，将繁琐的数据库操作、API定义等流程封装起来，让开发者只需关注业务逻辑本身。文章分享了从零开始的具体步骤，展示了如何快速生成一个具备完整CRUD功能的RESTful接口服务，极大地解放了生产力。如果你也苦于在重复的样板代码中打转，这篇经验之谈提供了一个让开发回归创造性工作的有效路径。
PhoneGap应用开发的那些坑爹事儿
这篇谈的是PhoneGap（或类似的Cordova框架）开发中那些令人头疼的“坑”。作者从亲身实践出发，揭示了在这条看似美好的混合应用开发道路上，开发者可能遇到的典型问题。 文章重点剖析了几个核心痛点：比如设备原生API调用时常失败或不稳定、应用性能容易出现卡顿、以及不同平台下插件兼容性差异巨大等。作者指出，这些问题的根因往往在于PhoneGap的桥接机制本身、对底层设备能力的封装局限，以及插件生态的良莠不齐，导致开发者需要投入大量精力去处理各种平台特定的诡异行为。 针对这些挑战，作者也分享了应对思路，例如如何更严谨地调试JavaScript与原生的交互、何时该放弃混合方案转向原生开发，以及如何选择和评估可靠的第三方插件。对于从事混合应用开发的工程师们来说，这篇文章能帮你提前预见并避开一些弯路。
微博应用那点事
这位作者从新浪微博开放API开始，陆续开发了12个应用，累计用户数达到40至50万。文章正是基于这长达一年半的实战经历，对在微博平台做应用的得失进行了一次系统性的复盘。 内容聚焦于作者个人在开发、运营这些应用过程中的具体经验与教训。虽然摘要里并未罗列每条教训，但从标题“那点事”和作者积累的体量来看，其中很可能涵盖了从技术实现、用户增长到产品运营的多个层面。文章试图将这段较长周期内分散的实践，提炼成可供其他开发者参考的、更具普遍性的认知。 对于有志于在开放平台进行应用开发的读者，这篇文章的价值或许在于它并非纸上谈兵，而是源于大量真实项目沉淀后，对成功路径与常见陷阱的直观总结。
为体验设计，为传播而设计
这篇讲的是产品开发中一个常被割裂的议题：如何让“体验设计”和“传播设计”真正协同。作者从传统产品流程中设计部门与市场部门容易脱节的现象出发，指出核心问题——产品体验本身若缺乏传播基因，就很难在用户心智中形成涟漪。文章的核心观点在于，优秀的设计不应只在体验闭环内自证价值，而应从源头就植入可被讲述、分享的“钩子”。这意味着设计师在打磨细节时，需要同步思考：用户会在什么场景下主动谈论这个功能？它的核心价值能否被一句话概括？通过具体的案例，作者展示了如何将传播思维前置到体验设计中，比如在交互中埋入自然的社交触点、让数据可视化结果本身具备分享吸引力。这种双向融合的思路，最终能降低产品的“解释成本”，让好体验自己会说话，从而实现增长。
原型: 新浪微博客户端
这篇文章记录了作者利用端午假期进行的一次交互设计实践。他重新翻阅了《交互设计之路》，并尝试运用书中的“目标、角色和场景”分析工具，从零开始设计一个新浪微博客户端原型。 作者没有直接跳进界面设计，而是首先明确了工具的核心：理解不同用户在具体情境下想达成的目标。例如，一个普通浏览者、一个重度发布者，或者一个信息监控者，他们的核心路径和需求差异很大。通过拆解这些场景，设计决策便有了依据——导航如何组织、信息如何呈现、互动按钮放在哪里，都服务于预设的用户目标和使用情境。 整个过程更像是一次设计方法的刻意练习。重点不在于原型本身有多完美，而在于展示如何将理论框架转化为具体的设计思考。对于想系统性地打磨交互设计思维的读者，看作者如何一步步应用这些经典工具来约束和引导自己的创意，本身就是一次很有启发的推演。
如何将AIR应用打包成exe
这篇讲的是如何解决 AIR 应用在分发时遇到的安装难题。作者从实际场景出发，指出很多下载站对 AIR 格式的应用不太友好，根源在于用户下载后常常不知道该如何安装和运行，导致体验不佳。 文章的核心方案是利用从 AIR 2.0 版本开始就已支持的打包功能，将应用直接生成为一个标准的 Windows 可执行文件（.exe）。这意味着，最终用户拿到的是一个无需任何前置环境或复杂安装步骤的独立程序，双击即可运行。 这个方法从根本上绕开了 AIR 运行时带来的安装门槛问题。对于开发者而言，这显著降低了应用的分发成本；对于下载站和普通用户来说，则获得了一个更通用、更友好的交付格式，提升了软件的可获取性和初次使用体验。