神马？用excel来做项目管理？
这篇讲的是如何用Excel这个大多数人熟悉的工具，来应对项目管理的挑战。作者没有一上来就否定Excel，而是从它的核心优势出发——灵活、门槛低、公式和透视表功能强大。文章具体演示了如何用Excel搭建一个轻量级的项目管理看板，比如利用甘特图视图跟踪任务时间线，通过条件格式自动标红延期任务，以及用数据透视表生成团队的工作量分析报告。 它没有回避Excel的短板，比如缺乏多人实时协作和复杂流程自动化，但作者的结论很有启发：对于小型项目、个人任务管理，或者作为专业工具之前的过渡方案，Excel其实是一个被严重低估的“瑞士军刀”。文章最后还提供了一个可直接下载使用的模板，让读者能立刻上手实践。对于那些被专业项目管理软件“吓退”或预算有限的读者来说，这提供了一条务实且高效的路径。
打工仔，天下不是我们的
这篇讲的是一个职场人从“易中天品三国”里对关羽遭遇的感慨，延伸到对现代“打工人”处境的观察。作者听易中天分析关羽被孙权诛杀的结局，认为关羽虽勇，但错把蜀汉集团的平台当成了自家天下，这种“位高而忘其本”的心态最终酿成悲剧。这让人联想到当下许多技术人、职场人可能存在的类似错觉——在岗位上贡献卓著，便容易将公司的业务成果与个人的归属感深度绑定，甚至产生“天下是我的”的幻觉。 文章的核心观点在于点破这种“错觉”的风险：平台与个人是相互成就的关系，但本质不同。公司的战略、资本与资源构成了“天下”，而个人的能力、贡献是立足其间的资本。当环境变化或角色不再匹配时，这种归属感可能瞬间瓦解。作者并非鼓励冷漠，而是提醒一种清醒：认清自己在体系中的位置与价值交换关系，才能更好地规划职业路径，避免因情感过度依附而陷入被动。这种视角对于身处快速变化行业中的技术人来说，或许能带来一丝冷静的启发。
如何面试程序员？
这篇讲的是面试程序员时如何设计问题才能精准评估候选人的能力。作者从实际招聘经验出发，分享了选择面试问题的核心策略。文章指出，有效的面试问题应覆盖技术深度、编码实践和软技能等维度，比如通过算法题测试逻辑思维，用系统设计评估架构视野，借助行为问题考察团队协作能力。作者强调，避免脱离实际的刁钻问题，而是聚焦工作场景中的真实挑战，如调试复杂故障或优化性能瓶颈。 文章对比了不同面试方法的优缺点，例如纯理论问答与实战编码测试的差异，指出前者可能遗漏应用能力，后者则能更直接地反映编码质量。通过具体案例，比如一个候选人如何通过设计分布式系统问题
在python中获取当前位置所在的行号和函数名
作者从一个实际困扰出发，探讨了在Python中如何动态获取代码当前执行的行号和所在的函数名。这是一个在调试、日志记录或实现元编程时非常实际的需求。 文章的核心是介绍几种具体的实现思路。常见方法包括利用`inspect`模块和`sys._getframe()`。作者应该会对比这两种方式的异同：`inspect`提供的是更高层的、面向对象的接口，而`sys._getframe()`则更底层，直接操作栈帧，性能可能略有优势。 此外，文章可能还会涉及在异步代码或装饰器中如何正确获取这些信息，因为这类场景下栈帧的结构会变得复杂。对于想编写更智能的日志装饰器、实现自动化调试工具，或者单纯对Python运行时机制感兴趣的读者来说，这些从实战中总结出的技巧和细节比较实用。
程序员阿士顿的故事
这篇文章源自 Stack Exchange 上一个看似简单的问题：“作为新手程序员，如何给技术出身的老板留下好印象？” 没想到，传奇博主 Joel Spolsky（《软件随想录》作者）给出了一个意想不到的回答。他没有罗列技巧，而是讲了一个关于程序员阿士顿的悲剧故事。 故事里的阿士顿技术能力很强，总能解决棘手的难题。但他也特立独行：无视编码规范，拒绝写注释，认为自己的代码无需他人维护，甚至对团队协作的流程嗤之以鼻。他以为凭借技术硬实力就能赢得尊重，结果却在一次自以为是的“优化”中搞崩了关键系统，最终被解雇。 Joel 通过这个故事想传递一个核心观点：给老板或团队留下好印象，远不止于炫技。理解业务目标、遵循团队规范、有效沟通，以及为结果负责的态度，这些“软技能”与编码能力同等重要。对于新手程序员来说，阿士顿的故事是一个及时的警示——真正的专业，是在融入团队的同时解决问题，而非制造新的问题。
mac下的tree命令
mac用户常常会遇到的一个小麻烦：系统默认并没有安装`tree`这个方便查看目录结构的命令。作者在自己的Mac上也碰到了这个问题，于是分享了一个颇具巧思的“流氓”级解决办法。 文章没有推荐复杂的安装方式，而是直接给出了一条组合命令：`find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'`。它的核心思路是利用`find`命令列出所有文件路径，再通过`sed`进行字符串替换，用管道符`|`和下划线模拟出树状结构的视觉效果。这个方案虽然原始，但胜在无需额外安装，完全依赖系统自带的工具，对临时需求来说堪称一个“即插即用”的技巧。 对于不常使用或不想折腾环境配置的开发者，这篇文章提供了一个立刻就能上手的替代方案，下次在Mac终端里想看目录树时，这个小技巧就能派上用场了。
让vim不在文件末尾添加空行
这篇讲的是解决Vim与其他编辑器混合使用时常见的一个兼容性问题。作者从实际开发场景出发，指出Vim会在保存文件时，尤其是在Windows与Unix系统间转换时，静默地在文件末尾追加换行符（如“\\n”或“\\r\\n”）。这虽然符合POSIX标准，却会导致版本控制系统频繁记录无意义的差异，或引发脚本解析异常。 文章的核心在于提供具体的配置方案。通过在Vim的配置文件（.vimrc）中设置`set nofixeol`和`set binary`，可以精确控制Vim的文件结尾处理行为，避免其强制添加换行符。作者不仅给出了命令，还解释了相关配置选项（如`eol`、`fixeol`）的作用，帮助读者理解底层机制。 最终，这个小调整能确保文件格式在不同编辑器间保持一致，让协作与版本管理更加干净。对于经常面临多工具链环境的开发者来说，这是一个能切实提升工作效率的实用技巧。
方法论
这篇讲的是作者从对“成功者恒成功，失意者总失意”这一现象的观察出发，试图提炼出一套可操作的成功方法论。文章并非空谈理论，而是通过与朋友“小花”的讨论和实际案例，将方法论拆解为三个具体可实践的要素。 首先是心态层面，即“有信心”，坚信任何问题都存在解决方案。其次是能力层面，需要“有智慧”，能够洞察并找到那个可行的方法。最后是执行层面，则依赖于“有天赋和耐心”，去将方法真正落地和坚持。作者特别提到，会用自己和小花的真实例子来逐一印证这三点。 整篇文章的论述朴素但直指核心，将看似玄学的“运气”或“命运”，解构成了信心、智慧与执行力这三个可修炼的维度，为读者提供了一个思考和改进自身行事路径的清晰框架。
快餐式的Google Reader
这篇讲的是作者时隔许久再次提笔，借对一个经典工具的回忆，来探讨如今我们信息获取方式的变迁。文章从个人对 Google Reader 的怀念切入，这个昔日信息聚合领域的标杆产品，其关闭常被视为一种“快餐式”信息消费时代的终结。 作者的核心观点在于，Google Reader 所代表的 RSS 订阅模式，赋予了用户主动筛选、定制信息流的掌控力。与如今被算法推荐包围的“信息投喂”相比，这种主动订阅、按自己节奏阅读的方式，更像是一场需要自己规划菜单的正餐，而非被快速推送、消化的快餐。文章敏锐地指出，虽然工具形态变了，但背后关于信息获取效率与深度、被动接受与主动选择的张力始终存在。 文章没有停留在单纯的怀旧，而是将这个经典案例作为一个观察点，启发读者思考：在便捷的算法时代，我们是否正在不自觉地让渡自己信息食谱的决定权？这种看似高效的“快餐”，长期来看，又会如何塑造我们的思维与视野？
为什么在多线程程序中要慎用volatile关键字？
这篇讲的是在多核时代，程序员为何对volatile关键字需保持警惕。作者从volatile的“可见性”保证出发，指出一个常见误区：许多人认为它能解决线程间的数据同步，但在多线程环境下，它无法保证复合操作的原子性。 文章深入剖析了根本原因：volatile仅确保单个读写操作的即时性，但像i++这类自增操作，在机器码层面包含读取、修改、写回三步，中间仍可能被其他线程打断。这会导致数据竞争与结果不确定。 作者接着对比了volatile与synchronized、Lock等同步机制。volatile轻量、无锁，适合状态标志；而涉及复杂条件判断或需要原子性时，必须使用锁。通过具体代码示例，文章清晰地展示了volatile在计数器等场景下的“坑”，并给出了正确使用同步器的解决方案。 核心结论是：volatile是优化工具而非通用同步方案。在多线程编程中，必须明确区分“可见性”与“原子性”需求，对volatile的使用场景保持清醒认识，才能写出既高效又正确的并发代码。
瑞典Ericsson总部Master Thesis面试回忆录
这篇讲的是作者在瑞典爱立信总部申请并参加硕士毕业设计面试的完整经历。文章从时间线出发，回顾了去年四月申请、六月开始的毕设与暑期实习机会的过程，最终拿到了爱立信总部的毕设录用通知。 作者详细描述了前往位于斯德哥尔摩科技园区（Kista）爱立信总部的面试现场情况，并基于自身经验给出了一个关键洞察：相比暑期实习，毕业设计岗位对外国学生的难度可能更低。因为瑞典本土学生会大量竞争有限的实习名额，而许多本地小公司也倾向于优先考虑本国申请者。因此，作者建议低年级同学可以策略性地优先申请六月开始的毕设项目，完成后再返校修读剩余课程。 文章不仅分享了具体的申请节点与面试场景，更点出了在瑞典求职市场中，针对国际学生的现实竞争格局与可行的应对思路，对计划北欧留学就业的同学有直接的参考价值。
周会经验一小枚
这篇讲的是作者在团队协作中，如何将周会从一个容易让人疲惫的“例行公事”，转变为真正驱动团队前进的“能量站”。作者从亲身组织周会的经验出发，没有泛泛而谈，而是直指几个常见的痛点：比如会议逐渐变成一人的“独角戏”、讨论散漫缺乏结论、或者总是固定几个人发言。 针对这些问题，作者分享了几条非常具体的实战心得。比如，如何通过提前设定清晰的“会议产出目标”来聚焦讨论；怎样用“轮流主持”或“会前匿名提交议题”的方式，调动每位成员的参与感；以及最重要的，是如何确保会议中产生的行动项被明确记录和跟进，避免“开了会但没改变”。 文章的核心观点在于，一次好的周会，其价值远不止于信息同步。它本质上是一个高效的团队协作机制，关键在于设计和引导。这些源自一线实践的细小经验，对于那些正苦于团队会议效率低下、希望提升协作质感的技术负责人或团队成员来说，提供了一套可以直接借鉴的轻量级优化思路。
技术文化和惨淡命运 ―― 怀念中国雅虎
这篇讲的是作者在离开中国雅虎一年后，对这家公司独特技术文化的回顾与深切怀念。文章从作者个人的职业记忆出发，细腻地勾勒了中国雅虎曾经拥有的开放、纯粹的技术氛围——那是一个工程师文化能够真正驱动产品创新的环境。 作者并未止步于感性的追忆，而是进一步探讨了这种文化为何最终未能抵御现实的冲击，导致了公司“惨淡的命运”。文中很可能触及了具体的技术决策、产品路线或团队故事，用实例说明了技术理想与商业现实之间的复杂博弈。 这篇文章的核心观点在于：一个组织的技术文化不仅决定了它的产品气质，更深刻影响着它的生存轨迹。它让读者看到，技术的纯粹性与商业的必然性之间常常存在张力，而中国雅虎的案例则提供了一个极具参照价值的样本——无论成功与否，那种对技术本身的尊重与执着，始终是值得科技从业者反思的遗产。
Vim(gvim)在recover时支持diff
Vim的自动保存功能（.swp文件）本意是在异常退出时挽救未保存的工作，但再次打开文件时，用户只能面对一个“是否恢复”的简单提示，根本无从知晓恢复后的版本与原本丢失的内容到底有何差别。 这篇介绍的 recover.vim 插件，正是为了填补这个信息差。它的核心思路是在恢复文件时，自动将恢复出的内容与磁盘上可能存在的旧版本（或空文件）进行 diff 对比，让用户能直观地看到每一处被找回的修改。 文章以 Windows 下的 gvim 7.3 为例进行演示：新建一个 C++ 文件并写入内容但不保存，模拟异常情况后，展示 recover.vim 如何激活差异对比界面。这样一来，用户就能在真正合并恢复内容前，清晰判断哪些改动是值得保留的，避免了盲目恢复带来的混乱。对于长期使用 Vim 的开发者而言，这个插件让原本“开盲盒”式的恢复过程变得可控和透明。
闲谈招聘
这篇讲的是一位技术负责人从广州到杭州后，对“招聘难”这件事认知发生反转的真实经历。作者原本常抱怨招聘不易，但亲身在杭州主导招聘一年半、成功引入8名团队成员（其中7人来自他个人渠道）后，才意识到之前的感受可能存在偏差。 文章并没有停留在简单的“招人真累”的感叹上。它具体描述了创始人或技术负责人在业务高压下，如何几乎“化身HR”亲自解决人才问题的困境，以及来自旧同事那句看似玩笑却很现实的质疑——“是不是你们仗着门面大，给人家开很低的薪水哦？” 这句话巧妙点出了招聘背后可能关联的薪资竞争力、团队吸引力等核心问题。 作者的发现或许在于：招聘不仅是HR部门的KPI，更是业务负责人必须持续投入的“隐形工作”。尤其在团队初创或快速扩张期，负责人的个人渠道、行业口碑乃至对薪资策略的反思，都直接影响着团队能否组建成功。这对于正在带队或创业的技术管理者来说，是一个值得对照思考的实在样本。
在盛大观察与感悟着
这篇讲的是一位前盛大员工的内部观察与反思。作者没有选择常规的“东家评论”套路，而是坦诚地指出，在国内评论雇主本身就是一件敏感的事。正因为此，这篇文章的视角显得尤为真实和稀缺。 文章的核心，是作者基于自身在盛大一线岗位的亲身经历，对当时那家如日中天的游戏巨头所进行的冷静观察。它没有停留在表面的八卦或泛泛的管理批评，而是深入到具体的工作场景、团队协作与决策流程中，记录了那些在快速增长光环下不易察觉的细节、矛盾与文化特质。这些观察，最终凝结成作者个人职业与认知上的重要“感悟”。 对于读者而言，这篇文章的价值不在于八卦，而在于它提供了一个珍贵的样本：一家处于巅峰期的互联网公司，其真实的运作肌理是怎样的？高速增长中可能潜伏着哪些组织与文化上的隐患？作者的个人经历与思考，为所有身处或即将进入快速成长型科技公司的从业者，提供了一面可资对照的镜子，启发我们去思考个人成长与组织环境之间复杂而微妙的关系。
以产品线划分组织架构
这篇讲的是技术团队的组织方式如何影响产品交付。作者从前序文章《前端开发是做产品么》引发的讨论出发，进一步探讨了当团队规模扩大后，一种常见的架构困境：如果严格按照前端、后端、测试等技能划分部门，跨职能的协作摩擦会显著增加，导致对产品目标的责任感模糊。 文章的核心方案是转向“以产品线划分组织架构”。具体来说，就是将围绕同一产品或业务线工作的前端、后端、测试、运维等角色，共同组成一个纵向的、端到端负责的小组。这个小组不仅负责开发，也更深度地参与产品设计和决策，对产品最终的成功与否承担更直接的责任。 作者认为，这种组织方式的核心优势在于打破了职能墙，让团队成员从“为功能负责”转变为“为产品负责”，从而能更快速地响应需求、提升整体交付效率与质量。文章从组织设计的角度，为解决大型技术团队的协作效能问题提供了一个清晰的思路。
如何在Myeclipse下安装和使用svn客户端插件
这篇指南详细演示了在MyEclipse这款经典Java IDE中，从零开始集成Subversion（SVN）版本控制客户端的完整流程。作者从开发者常见的需求场景切入——即如何在熟悉的开发环境中直接管理代码版本，避免频繁切换工具。 文章的核心价值在于其详尽的实操步骤。它清晰地说明了如何获取与MyEclipse版本兼容的SVN插件（通常通过Eclipse Marketplace或手动下载），并逐步指导完成安装与重启的关键环节。更进一步，它不仅止于“装好”，还涵盖了插件的配置与基础使用：比如如何将现有项目导入SVN资源库、执行更新（Update）与提交（Commit）操作，以及处理可能出现的冲突。 对于习惯MyEclipse工作流，或需维护使用SVN管理的旧项目的开发者而言，这篇内容直接提供了“一站式”解决方案。它省去了摸索与试错的时间，将版本控制工具无缝嵌入到日常编码环境中，从而提升团队协作与项目管理的效率。
我希望看到什么样的简历
这篇讲的是，一位拥有丰富招聘经验的技术负责人，从自己面试过数百位候选人的视角出发，系统性地分享了他对一份好技术简历的期待。他并非在泛泛而谈格式模板，而是直击核心——简历应如何清晰、有力地证明你的价值。 作者从自己作为招聘者的实际工作流切入：当一份简历摆在面前，他最先关注的是哪些部分？是项目经历中那几句描述工作的关键词，还是你罗列的技术栈？他提到，许多候选人的简历通病是模糊和自夸，例如只写“负责系统优化”，却不说清楚解决了什么具体问题、带来了多少性能提升。相反，一份出色的简历，会让读者立刻看到一个清晰的轮廓：你在什么背景下，用什么技术手段，解决了一个怎样的工程挑战，最终量化结果如何。 文章特别强调了“匹配度”和“诚实”的重要性。简历不是技能词汇的堆砌场，而是为你争取面试机会的“论证文档”。作者建议，与其写“精通多种框架”，不如详细描述你如何用一个框架解决了实际业务痛点。这种基于事实的、具体而微的展示，远比空洞的形容词更有说服力，也更能体现你的技术深度和解决问题的真实能力。对于正在准备求职的工程师而言，这篇文章提供了一个宝贵的内部视角，帮助调整简历的撰写重心，让其从一份“说明书”变成一个有说服力的“故事”。
关于创业，杂感
作者近期频繁接触创业者，从旁观者的视角记录下许多鲜活的感受。他观察到，创业浪潮中浮现出的个体面孔，与其说是商业冒险，不如说是一个时代精神状态的切片。这些选择跳出常规轨道的人，身上往往同时承载着强烈的个人表达欲与对现实机遇的敏锐捕捉。 文章没有提供创业方法论，而是聚焦于“人”本身。作者发现，那些令人印象深刻的故事，内核常常不是商业计划书的精巧，而是个人特质、所处阶段与时代缝隙的一次意外吻合。它让读者看到，创业或许本质是一场在变动中寻找自身坐标的实验，其价值不仅在于结果，更在于过程中个体对时代命题的回应。这对于任何思考职业路径与人生可能性的读者，都提供了一个安静而具体的观察切口。