建立学习型组织
这篇文章从技术管理者的一个常见困境出发：升任领导后，如何在忙于管理的同时不丢失技术根基？作者余晟通过自身CTO经验，指出核心在于将“个人学习”升级为“组织学习”。 文章提出，技术管理者需要通过宏观视野和关键决策保持技术水准，但这与日常团队管理存在天然矛盾。解法是打造一个“学习型组织”：通过招聘高潜质员工、将技术分享纳入KPI、组织跨团队难题攻关、鼓励前沿探索等一系列机制，在团队内营造开放、互助的学习文化。 如此一来，整个团队便成了管理者的“延伸大脑”。管理者无需单打独斗，只需引导方向并深度追问，就能持续获取技术洞察；团队成员则在此过程中拓宽视野、激发钻研精神。文章最终揭示了一个更深层的视角：卓越的团队本身就是管理者技术能力的最佳放大器，团队的学习力与管理者的技术领导力实为一体两面。
对屌丝要抱有敬畏之心
这篇讲的是作者从亲身经历出发，对社会中努力奋斗的普通人应抱有敬畏之心的观点。文章通过两个故事展开：一个是去哪儿网在上市成为巨头前，其核心高管曾是一名在技术社区活跃的“屌丝”，却因追求被拒而错过缘分；另一个是作者目睹一位辛苦看守电瓶车停车场的收费员，凭借认真负责的态度，后来转型成为业绩出色的房产经纪人，收入远超作者。 作者借这两个“屌丝逆袭”的案例指出，在中国特别是互联网行业的大变迁时代，机遇无处不在。今天看似平凡甚至处于困境的人，明天就可能凭借努力创造出改变生活的产品，或获得更自由的人生选择。因此，他提出，无论你是正在奋斗中的普通人，还是已有所成者，都应对身边每一个认真、偏执的个体保持尊重与敬畏，因为他们蕴藏着不可小觑的潜力。
小股东怎样保护自己的利益
这篇讲的是创业公司里小股东如何自保的实战心法。作者从小股东的尴尬处境切入——身份介于股东和打工者之间，话语权低，但完全放弃权益又极易被“复杂股权架构变更”掏空股份。文章的核心观点是：小股东必须主动行动，通过几个关键策略来对冲信息与权力的不对等。 具体策略包括：一是强化契约意识，任何涉及利益的条款都需法律保障，绝不能因“不好意思”而妥协；二是利用在公司任职的便利，通过非正式渠道（如与财务、人事同事交流）主动拼凑信息，预判风险；三是保持自身的“存在感”，确保个人价值不低于持股比例，避免被边缘化；四是及时评估大股东人品，发现问题尽早友好协商退出；五是永远保留独立创业的能力，作为谈判的底气。 文章也罕见地从大股东视角给出了避免冲突的建议，比如要求小股东现金购股、采用分期授予（vesting）机制、以及及时回购不称职者的股份。这使得讨论更为平衡，对创业双方都有参考意义。最后作者提醒，选择合伙人时需警惕纯粹重利、缺乏理想的商人，因为这决定了公司的底线。
Ruby的多线程应用服务器介绍
这篇讲的是随着Rails 4.0默认开启多线程模式，Ruby Web开发迎来了多线程服务器选型的新阶段。作者对三款主流选择进行了对比分析。 Rainbows和Puma都支持master-worker集群模式，能充分利用多核服务器。Rainbows脱胎于稳定的unicorn，提供了丰富的进程控制信号，适合对稳定性和运维控制要求高的大型应用。Puma的特色在于线程数可根据请求量在设定范围内自动伸缩，且单进程模式更节省内存，对中小型应用更友好。而Zbatery是极简的单进程多线程版本，是三者中最省内存的，适合在VPS上托管多个低流量应用。 作者的性能测试显示两者差异不大，选择更多取决于场景：追求稳定与可管理性选Rainbows，希望节省资源与灵活伸缩则Puma更佳。
对.net系统架构改造的一点经验和教训
这篇文章从作者在CSDN的亲身经历出发，探讨了从Windows .NET架构迁移到Linux平台的实战经验与教训。作者首先指出了一个普遍困境：许多依赖.NET的大型网站面临扩展瓶颈，但“去.NET化”的迁移风险极高，常因技术复杂性和内部团队政治斗争而失败。他以5173网站的失败案例为例，新旧团队并行、利益冲突导致迁移流产。 作者接手CSDN时，也面临.NET团队流失、系统脆弱的两难局面。他的核心方案是采取折衷策略：并非完全抛弃.NET，而是“去Windows化”。具体做法是保留.NET作为应用层，但将数据层、缓存、文件系统等全面迁移至Linux开源方案（如MySQL、Redis、Nginx），并用LVS实现负载均衡。这样既利用了.NET在应用层的开发效率，又通过Linux生态解决了扩展性和成本问题。 两年后的实践证明，这一策略成功实现了团队稳定、改造平顺、业务无影响且支持增强的多重目标。作者由此总结，架构改造远非单纯技术问题，必须妥善处理团队利益、业务平滑过渡与长期投入之间的关系。技术债务的背后，往往是技术被长期低估的管理文化问题。
robbin谈管理：要给下属challenge你的机会
这篇讲的是管理中的服从与挑战。作者从一条关于马化腾深夜提bug、团队火速响应的微博切入，引出了关于职场执行力的深层讨论：这种高效的“听话”是值得称赞的“使命必达”，还是需要警惕的“无原则媚上”？ 文章的核心观点是，一味强调下属无条件服从，对创新和产品成功可能有害。作者指出，当员工只为老板的指令而工作，用户的需求就可能被忽视，产品最终成了“做给老板看的”。他举了乔布斯早期力主iPad用Intel芯片，被下属Tony Fadell强烈反对并最终改变的案例，来说明挑战权威的价值。 作者提倡，管理者应该给下属“challenge你”的机会。这不仅能帮上司纠错、避免决策盲点，更能让下属从被动执行转为主动担责，快速成长。他结合自身经历，分析了上司害怕被挑战的几种心态（如权威被威胁、爱面子等），并总结了下属提出异议后可能出现的几种结果。他认为，绝大多数情况下，开放讨论的结果都好过一言堂，即使最终证明下属是错的，上司承担责任的过程也能建立团队信任。 文章呼吁建立一种更开放、互信的团队氛围，让每个人都为产品和用户负责，而不仅仅是对上级的KPI负责。
Web应用的缓存设计模式
这篇讲的是，作者如何通过一套“反直觉”的缓存设计，让一个日均300万访问的老产品重写后性能飙升。传统思路依赖动态页面静态化和数据库分库分表，但代码复杂度高，维护困难。作者的方案则彻底反转：完全放弃这些，转而深度应用ORM对象缓存。 核心在于改变对数据库性能瓶颈的认知——瓶颈往往在磁盘IO，而非SQL条数。因此，ORM缓存的设计哲学是：目标是减少数据库磁盘IO，而非减少SQL。这需要配合细颗粒度的表设计，故意拆分多表关联为多条主键查询（拥抱“n+1”问题），以便高效利用缓存。 文章通过一个实际案例（将千万级大表的项目迁移到单台MySQL）证明，这套方案能将数据库服务器的IO Wait降至5%以下，且代码复杂度并未显著增加。作者还具体演示了两种实现模式：利用表关联实现透明缓存，以及按列拆表实现大字段的细粒度缓存，后者本质上是SQL与NoSQL的混合架构。 对于追求高性能且希望保持代码可维护性的Web应用，尤其是内容频繁更新的场景，这种以缓存为中心的设计提供了一个极具说服力的替代路径。
textmate常用快捷键备忘
这篇讲的是TextMate编辑器的常用快捷键，堪称一份详尽的备忘录。文章直接按功能模块，列出了从视图切换、文件导航到代码编辑、查找替换等方方面面的高效操作方式。比如用“Cmd + T”快速定位项目文件，用“Cmd + /”一键注释代码，或是利用“Cmd + Option + A”进行多行同步编辑。 它不仅覆盖了通用操作，还特别整理了针对HTML和Rails开发者的Bundle快捷键，例如自动生成标签或在Controller、View、Model间快速跳转。对于列编辑模式这种特殊技巧也做了说明。对于使用TextMate的开发者而言，这篇文章就像一份随时可查的效率手册，把零散的操作技巧系统化地呈现出来，能有效帮助提升日常编码的流畅度。
Git常用命令备忘
这篇讲的是Git的常用命令速查手册。作者把日常开发中最可能用到的Git操作，从基础配置到进阶使用，系统性地整理成了一份清晰的备忘录。 内容从配置用户信息和设置别名开始，快速上手。接着是文件操作的三板斧：用`git add`暂存修改，用`git commit`提交，以及用`git diff`查看差异，文中详细列举了各种diff比较场景。分支管理部分尤为实用，涵盖了创建、切换、合并分支，以及使用`git rebase`整理提交历史的命令。 文章还覆盖了几个非常实用的功能：通过生成和应用补丁在不同环境间同步修改；利用`git stash`临时保存工作进度，专注于紧急任务；以及远程协作的核心命令`git pull`和`git push`，包括如何跟踪远程分支和清理远程仓库。 这份清单的细致程度很高，甚至包含了如何使用`tig`这样的可视化工具，以及设置远程仓库HEAD指向等细节。对于不常使用Git，需要偶尔回顾命令的开发者来说，这份结构化的清单可以作为手边的速查手册，省去反复搜索文档的麻烦。
GitHub 是怎么火起来的
这篇讲的是GitHub的早期发展史与技术传播逻辑。作者从2009年Ruby大会的亲身经历切入，指出GitHub在获得巨额融资引发大众关注前，早已在Ruby社区奠定了坚实基础。 文章的核心观点在于，Git和GitHub的爆发是技术需求驱动社区自然演进的结果。Ruby/Rails框架虽开发高效，但多人协作时面临传统版本控制系统（如CVN/SVN）的冲突痛点。Git的分布式与分支管理特性完美契合了这一场景，使得Ruby社区几乎全员迁移至Git生态。而GitHub正是诞生于这一浪潮，由湾区Ruby开发者为解决Git托管需求而创造。 更深层的传播链条清晰可见：Rails项目率先迁移到GitHub形成示范，社区内包管理工具Gem的全面接入形成网络效应，最终带动了关系紧密的JavaScript与iOS开发社区跟进。作者强调，这种由核心开发者社区向外扩散的“涟漪效应”，是GitHub增长的关键动力，而其高估值则更多源于云计算SaaS平台的商业模式。文章为我们提供了一个观察技术如何通过解决具体痛点、依托社区凝聚力实现指数级增长的经典案例。
大公司的创新思考：基因延伸性创新
这篇讲的是大公司如何在新时代实现创新成功。作者从Scott的“新企业车库”时代论出发，提出了一套更细致的创新分类：基因延伸性创新与颠覆性创新。 作者认为，大公司依靠资源、规模和品牌取得的创新成功，本质上是一种“基因延伸性创新”。公司的“基因”——即其在核心竞争领域长期优化形成的独特优势——既是护城河，也可能成为拓展新领域的障碍。文章拆解了新浪微博和微信的成功案例，指出它们都精准地将母公司在媒体运营和通讯工具上的基因，延伸到了移动互联网新战场。 基因延伸性创新要成功，必须满足两个条件：一是创新方向必须符合公司基因，否则如Google+之于Google、新浪游戏之于新浪都难以成功；二是延伸的新领域必须有足够的市场空间，文章以Apple TV的有限市场想象空间作为反例。而另一种“颠覆性创新”由于会重构游戏规则，往往难以在大公司内部存活，更多由创业公司驱动。 最后，作者也提到通过收购来改变公司基因（如苹果收购NeXT）是大公司实现颠覆性创新的艰难但可能的路径。文章的结论是，未来将是大公司与创业公司各展所长的创新时代，而非一家独大。
晒晒我们的开源项目
这篇讲的是一个13人微型研发团队，如何通过开源项目凝聚力量的故事。团队虽小，却维护着四种不同的技术栈：Ruby、PHP、.NET和Java搜索，自然形成了四个技术小组。 文章没有聚焦某个具体的技术难题，而是从“我们为什么要开源”这个更根本的视角出发。背景很现实：分散的技术栈容易造成信息孤岛和重复造轮子。而他们的核心选择是，以一个开源项目为支点，将分散的技术力量整合起来，共同维护一套核心代码。 文章分享的启示或许在于，开源对于小团队而言，不仅仅是代码的共享。它更是一种强有力的工程实践：通过统一的代码规范、协作流程和公开的代码审查，来强制打破小组壁垒，提升整体代码质量与协作效率。这种“晒”，晒的不仅是项目，更是一种协作模式与团队文化的塑造过程。
robbin谈管理：大公司体制内创新的困境
这篇文章从吴军《浪潮之巅》中提出的“基因决定论”切入，探讨了大公司为何在体制内难以实现颠覆性创新的深层困境。作者指出，摩托罗拉、诺基亚、微软等巨头的转型失败并非偶然，而是源于组织惯性与创新机制之间的根本矛盾。 文章进一步引用杰克·韦尔奇在《Winning》中的观察：管理一条产值5万美元的新生产线，比运营一个销售额5亿美元的成熟企业更困难。他剖析了三个关键原因：新业务缺乏成熟的流程与资源支持、在现有体系中难以获得足够的注意力与容忍度、以及大公司固有的成功路径依赖会扼杀非常规的探索。 这不仅是一个管理问题，更揭示了技术创新生态中普遍存在的结构性挑战。对于技术管理者而言，如何设计独立于母体的创新单元、设置合理的考核周期与容错空间，是比单纯追求技术先进性更复杂的系统工程。
robbin谈管理：坦诚的力量
这篇文章聚焦于团队管理中的一个核心品质：坦诚。作者从自身带队经验出发，直言不讳地指出，对于一个领导者来说，最重要的前提是本人必须做到“坦诚”。 文章的核心论点层层递进：只有对团队坦诚，才能在彼此之间建立起必要的信任；而信任是任何团队形成高效默契的基石。因此，坦诚不仅是对管理者个人性格的基本要求，更应当成为整个团队需要共同营造和维护的氛围。 这篇短文没有堆砌复杂的管理理论，而是用最直白的语言点破了一个常被忽视的真相：许多团队问题，根源或许不在方法论，而在于最基础的信任是否到位。它提醒每一位技术管理者，在关注流程与效率的同时，更需要审视自己和团队是否具备了“坦诚”这一最基础却最有力的协作前提。
robbin谈管理：我敬佩的3位CEO管理者
这篇讲的是作者从自己反复研读的CEO管理经验出发，分享对管理的深度思考。 文章聚焦于作者敬佩的第一位CEO——GE前任掌舵人杰克·韦尔奇。作者提到，韦尔奇在执掌GE的20年间，带领这家庞然大物实现了每年30%的高速增长，市值一度登顶全球第二。尽管作者身处中国互联网行业，但韦尔奇的《自传》和《Winning》却是他反复研读的案头书。最打动作者的，恰恰是一种反差：一个在GE这样巨型传统企业深耕一生的管理者，行事却极其不循规蹈矩，处处敢于打破常规，风格雷厉风行。 作者没有停留在对韦尔奇的泛泛赞誉，而是结合自身经历，提炼出了从这种“打破常规”的管理哲学中学到的具体知识。文章虽然未深入展开后两位管理者，但通过韦尔奇这个鲜活的案例，生动地传递出一个核心观点：真正的管理智慧，有时恰恰体现在对所在组织固有文化与路径的勇敢突破上。这对于身处技术或管理岗位的读者而言，提供了一种审视自身工作环境的启发性视角。
肉饼谈管理:改造团队的经验(2)
这篇讲的是一个技术管理者空降新团队后，度过关键期并开始扩张时的切身体会。 作者延续上篇，指出在通过解决急迫问题、找到根源并建立团队信任后，真正的挑战才刚刚开始：如何从现有核心团队出发，进行人员扩充。文章具体描述了从“维稳”转向“扩张”的心理和策略转变，认为此时管理者面临更复杂的平衡——既要吸纳新鲜血液，又要避免破坏已建立的信任和团队氛围，还要确保新人与团队文化的契合。它强调了这个阶段的招聘与融合，远比最初的“救火”更考验管理者的耐心与眼光。 对于即将带领团队扩张，或刚接手一个稳定团队并计划引入新成员的技术Leader而言，文中的阶段分析和具体困境描述，提供了切实的思考框架。
肉饼谈管理：改造团队的经验(1)
这篇讲的是技术管理者“肉饼”分享自己入职CSDN两年后，如何系统性地完成团队与平台改造的实战经验。 文章具体回顾了作者主导的一系列重工程量工作：将占网站流量90%以上的博客、下载、个人空间等核心产品逐一重写，同时清理了数百个废弃站点与几十个边缘频道，从混乱中梳理出统一的网站风格。更进一步，他建立了完善的社区产品运营体系，为业务发展打下基础。 从这些扎实的产出可以看出，作者的核心思路是通过“重写+清理+体系化建设”这套组合拳，来完成一个老化技术平台的现代化改造。这不仅仅是技术债的偿还，更是将团队能力与产品架构对齐业务目标的系统工程。文章以第一人称娓娓道来，为面临类似挑战的技术管理者提供了清晰的行动路径与可量化的结果参照。
肉饼的自白：You've got to find what you love
这篇讲的是技术社区里一个有趣的身份符号如何形成，并折射出社区文化中的一个朴素道理。作者从自己英文名robbin的由来讲起，这个源于美剧《走遍美国》的名字，因为粗心多拼了一个“b”字母，成了一个美丽的错别字。但正是这个“肉饼”的昵称和ID，伴随着他创办的JavaEye网站，获得了比本名更大的知名度，最终让他选择“将错就错”。 作者并未停留在怀旧或趣事分享上，而是通过这个小小的插曲引出了一个关于热爱与坚持的核心观点。他指出，当你真正热爱你所做的事情，并像他对待“肉饼”这个外号一样，以亲和、开放的心态去拥抱它、经营它时，它就会获得生命力，超越你最初的设定，形成独特的价值和情感连接。这种亲和力，或许正是开源与技术社区文化中，人与人建立联结、共同推动某件事物发展的关键。 文章用个人化的叙事，温和地提醒每一位技术人：在代码与架构之外，找到并坚守你真正热爱的东西，它所回馈的，可能远超预期。
CSDN网站帐号数据库安全性问题
这篇讲的是CSDN用户数据库泄露传闻引发的一场安全质疑。作者从自己结束一天机房工作后的视角切入，面对不断涌入的询问——“CSDN是不是明文保存密码？数据库安全吗？”——决定对这个广受关注的事件做出公开说明。 文章的核心直指一个关键的技术事实与行业痛点：用户密码的存储方式。作者没有回避争议，而是以此为契机，解释了在事件背景下，密码以明文存储所蕴含的巨大风险，以及一个安全的系统应该采用的正确实践。这不仅是一次对传闻的澄清，更是一堂面向广大开发者和用户的安全警示课。 从这篇回应中，读者能获得的启发是双重的：对于普通用户，它提醒了在不同网站使用相同弱密码的潜在危险；对于技术从业者，它则强调了在系统设计之初就贯彻安全规范（如密码加盐哈希存储）的绝对必要性，因为事后补救的代价和信誉损失往往是巨大的。
我来CSDN的这一年
这篇讲的是作者从ITeye（原JavaEye）被CSDN收购后，从上海搬家到北京工作一年的个人回顾。事件背景是IT行业的一次公司并购和个人职业变动，作者面临了生活环境和工作职责的巨大变化，从适应新城市到重新定位角色，整个过程充满了挑战与机遇。 核心观点是，作者在这一年里感到非常充实。在公司大力支持下，他计划并投入时间精力的事情基本