Chat 三人行

解析文件并入库（MySQL），是工作中最常见的需求，也算的上是职场必备技能之一。现假定需要从一个大文件中解析数据，并将其以最快速度完成入库操作，你能想到的最佳方案是什么？应该如何演进，一步步对效率进行提升？ 本 Chat 将对其进行比较全面的剖析，所涉及内容如下： 1. 问题剖析，核心组件及其职责； 2. 基于 Spring Boot 工程搭建； 3. 基于 Stream 的文件读取能有多快； 简单的字符串解析，效率如何； 4. 数据入库的瓶颈在哪，事务、批量、还是 SQL； 5. 多线程如何提升效率。

Malte Ubl 在 Google 负责 JavaScript 基础架构搭建并担任 AMP 项目负责人。本文根据他在澳大利亚 JSConf 的分享整理而成。Malte 构建了 Google 的 JavaScript 框架，该框架的应用范围包括照片、Google+，Google Drive，Google Play，乃至搜索引擎。该框架和 React 类似，但是没有开源，是 Google 内部使用的 JS 框架。 Malte 通过构建 JS 框架，总结了超大型应用具有的一些共性问题。超大型系统可能会涉及数十，甚至上百个开发者，我们需要把人的因素和人际问题考虑进去。另外，这类系统的背景信息以及很多部分可能都是你和你的团队所不知道或不理解的，这时应该怎么办？本文讨论的正是这些你在构建超大型应用前需要考虑的问题。 另外，在本文中 Malte 还会谈到事业方面的建议。高级工程师意味着什么？可能意味着能够解决所有别人扔过来的问题，也可能意味着了解自己的工具、知道自己的领域。Malte 工作的重要部分，是让他团队的初级工程师成长为高级工程师。文中他将会告诉想要成为高级工程师的你，到底需要做些什么。 ------ 作者：Malte Ubl 在 Google 负责 JavaScript 基础架构搭建，并担任 AMP 项目负责人。

随着就业市场对 JavaScript 开发者的需求不断递增，JS 开发者迎来了一个美好的时代。相关框架和库如雨后春笋般汹涌而出，让生活在这个时代的我们倍感幸运——特别是还有那么多开源的好项目。于是我们在日常工作中把大量的时间和精力花在与 JavaScript 相关的任务上。 但每天花费你大量时间和精力的 JavaScript 任务很有可能会在不知不觉间，为你和你的未来造成灾难。我自己就曾因为文中提到的一些习惯受苦，所以我的目标是让你不再犯类似的错误，避免你深陷苦海。 下面就是初中级 JavaScript 开发者最可能有的 8 个自毁前程的习惯。 ------- 作者：jsmanifest TeleMedicine 前端开发负责人。个人网站：https://jsmanifest。

Social Capital 是 Paypal 创始人 Peter Thiel 参与合伙的一家风险投资公司。本文作者 Jonathan Hsu 是该公司早期合伙人之一，离开 Social Capital 后，他创办了风险投资公司 Tribe Capital。除此之外，他也是一位热爱音乐的数据科学家。 ------ 在 Social Capital，我们对潜在投资的尽职调查投入了很大精力，并积累了很多经验。我将通过接下来的一系列文章来讲一讲我们是如何通过量化手段来评估产品/市场契合度（PMF）的。为了时刻了解增长情况和不断变化 PMF，我们投资的很多公司都把这些概念作为他们工作流程的一部分。 尽职调查的目的是帮助我们理解现状和未来可能发生的情况，同时也为创业者提供指引。虽然每家公司都是不同的，但我们有一些标准化的方法可以帮你检验核心牵引指标，我们也愿意将这些分享给你，希望这些经验可以帮助你加深对自己业务的理解。 本系列文章会覆盖以下主题： - 用户增长核算 - 收入增长核算 - 收入方向同类群组生命周期价值（LTV） - 参与度方向同类群组生命周期价值（LTV） - 参与深度与收入质量 - 结语：8 球法和创业 GAAP 原则

>「所谓忠告就是一部自传，别无他物。」——詹姆斯 · 阿尔图切尔 把过去的想法和轶事重新拿出来写成书或者文章是很简单的。但是把你遇到的困境，以一种与他人相关的方式说出来，则是一件更加困难但却有益的事。我想做的，就是以这样的方式讲讲**我的故事**。 我仍然处在「正在进行时」，但是我已经取得了很多让我为之骄傲的成就：我写了几本书、找到了我热爱的事业、我在上千人面前演讲，我还为喜欢我作品的人建立了一个平台。我可以轻松把我经历中不符合大牛身份的部分粉饰过去，就像那些在一夜之间成名的牛人所分享的通往成功的「3 个小诀窍」，但这对你没有好处。 成功和小花招、小诀窍，甚至短期策略都没有关系。成功的真谛在于枯燥但有效的理念，比如努力、耐心，以及重复。这个你已经知道了，但有时候你需要有人为你拨开窗帘，把这个过程展示给你看。 在这篇文章中，我将把我从破产到获得成功的 5 年经历分步骤讲给你听，包括我遇到的挫折、产生的困惑，以及我从中吸取的宝贵经验。 现在的我仍然没有停止脚步，我还要做得更好。成功地提升自己并不是终点，而是一种持续演进的状态。只要我还活着，我就会一直追逐自己的目标，因为这才是生命最好的状态。 PS：此文曾获得 4000 多次点赞，别错过 ------ 作者：Ayodeji Awosika Medium 资深博主。一个热爱写作的人，出版了 [*The Destiny Formula*](https://www.amazon.com/Destiny-Formula-Purpose-Strengths-Successful-ebook/dp/B019ZJG6JU/ref=sr_1_3?keywords=Ayodeji+Awosika&qid=1560324656&s=gateway&sr=8-3), [*You 2.0*](https://www.amazon.com/You-2-0-Reinvent-Yourself-Transformation-ebook/dp/B06XY3GFDS/ref=sr_1_1?keywords=Ayodeji+Awosika&qid=1560324386&s=gateway&sr=8-1) 等书，个人网站：<http://ayotheauthor.com>

作为一个程序员，写代码是你工作中最重要的部分。在你的编程生涯中，你需要跟各种各样的代码需求打交道。每次需求都会迫使你做出艰难的决定。这都没有问题。作为一个程序员，这是所有人对你的期待：写代码。然而，这里有一个问题：你应该写出所有这些代码吗？ > 知道何时不写代码大概是一个程序员能学到的最重要的技能。——《编写可读代码的艺术》 编程的艺术就是解决问题的艺术。作为程序员当我们面临一个待解决的新问题时，我们会很兴奋。这些都没问题，因为我们是程序员，我们也爱写代码。 然而，对写代码过于兴奋会让我们变得盲目。我们会忽略一些重要的问题，于是就会产生我们不得不在未来解决的更严重的问题。 你编写的每行代码都是： - 需要被其他程序员阅读和理解的代码 - 需要经过测试和调试的代码 - 会增加你的软件- 中的缺陷的代码 - 极有可能会在未来引入新 bug 的代码 **那么，你如何知道何时不写代码吗？** Ps：这篇文章曾获 4300+ 赞 ------ 作者：Hüseyin Polat Yürük Medium 资深博主。一直在思考的开发者。创业者。持续写作的程序员。充满好奇心的学习者。乐于助人。简单的原则：一直向前 [http://huseyinpolatyuruk.com](http://huseyinpolatyuruk.com/)

你最近可能时不时的被 ACT 刷屏，那 ACT 是什么呢？ACT 是 Agile Coach Toolbox 的简称。ACT 核心解决两个问题： - 服务转型中的企业，有效落地敏捷实践；（如何快速止血，快速达到60分的及格成绩） - 服务成长中的教练，快速提升实战技能。（敏捷教练的成长体系是什么，让更多的敏捷教练成为大师） ACT 设计出了一套战术手册（Framework of Activity Conducting Tactics），这本手册关注敏捷教练具体可实施的做法和行动。但对于 ACT 的价值观以及原则的讲解部分，我们还是不够鲜明与明确。换句话说，ACT 所坚持的原则与价值观有哪些独特之处？它和 Scrum 与 Kanban 之类的框架或理论到底有何区别？为什么这些观点 ACT 认为要坚持的？ ACT Group Leader 们愿意借助 GitChat 平台，正式发布 ACT 敏捷教练战术手册，并揭露 ACT 背后的故事。本次分享也是 ACT Group Leader 们的全面站台之旅： - **巩敏杰**：敏捷教练，培训师，咨询顾问，10+ 年 IT 从业经历，敏捷、精益思想倡导者与实践者，终身学习，善于与团队共同成长与进化。 - **林伟丹**：资深敏捷顾问，学习者、探索者、志愿者。曾任某大型金融集团研发管理部负责人、质量技术人才发展管理委员会会长，多年负责研发管理体系、敏捷教练服务与 DevOps 工具链建设，主导 8000 人规模组织转型。 - **刘伯英**：EPG team leader，十余年软件研发、研发管理和过程改进经验，致力于寻求更有效的方式，推进所在公司的敏捷转型工作。 - **刘小林**：敏捷咨询顾问，十余年软件测试、测试管理、自动化测试、敏捷实践及培训经验。曾任顺丰科技过程改进负责人，主导建立顺丰科技极速研发模型 SFPD。 - **尹学罡**：引导师，敏捷教练，团队角色顾问。10余年软件行业经验，写代码，带团队，推变革。理念是标尺，践行出真知。 - **麦宇安**：敏捷技术实践顾问，编程爱好者，参与过道富、平安、顺丰、移动等企业的敏捷转型。 - **孟繁强**：资深精益敏捷教练，埃里克森专业教练。长期致力于引导和教练技术、产品创新思维、精益及敏捷思想的实践与推广。曾经和正在为多家大型组织提供敏捷转型服务。 - **欧兰辉**：老程序员，中年咨询教练，新手画师。相信影响力驱动变革，游戏化改变人生。一边学习一边践行，一边践行一边改进。 - **王磊**：敏捷教练，10 多年的软件开发、项目管理、敏捷项目实施经验。专注于敏捷转型相关的培训和团队辅导工作，喜欢用系统思考和团队一起探索新的可能。 - **王宇**：敏捷教练，97 年参加工作，01 年接触极限编程，07 年全面敏捷践行，12 年接触专业教练，12 年开始专职敏捷教练与咨询师生涯，平安，招行长期敏捷咨询顾问。 本次分享，包括但不限于以下内容： - 为什么 ACT 拥有这样的价值观？ - 犀利观点 over 模糊词汇 - 关注状态 over 遵循过程 - 实战效果 over 方法导向 - 挑战自我 over 执行要求 - ACT 有哪些不同于其他敏捷概念的观点或原则： - 强调领导力小组，而不是对自组织的执着； - 强调事前的准备，而不是明确的会议议程； - 强调与领导沟通，而不是封闭在团队之中； - 强调观点的反馈，而不是强调理论的正确； - 如何开始 CPAC 的认证过程？手册中内容及例子有哪些？如何获得手册？ - 近期交流活动中反馈问题的解答。 请参考：[《也聊一下敏捷教练》](http://gitbook.cn/gitchat/activity/58d7bc5b4307c1e066abcb68)、[《远离敏捷状态的 Scrum 框架》](http://gitbook.cn/gitchat/activity/5a423b5375267d3b3371aad2)、[《关于 ACT 你应该知道的背景和它尝试解决的问题》](https://www.jianshu.com/p/76d8b38d4dee)。 **交流结束后，我们将把 3 本敏捷教练实战手册送给 3 位幸运读者。**

用户故事拆分一般被认为是敏捷实施的入门实践——没有用户故事拆分，就没有真正意义上的迭代，当然也就没法做到敏捷方法所倡导的快速反馈、快速学习和快速价值交付能力。 INVEST 原则常常被看做是用户故事拆分的基本要求。但是，不少敏捷团队在如何获得 INVEST 原则所要求的用户故事方面仍然感到困惑。一些常见的后果是：用户故事拆不开，没法在一个迭代内完成。拆开了的用户故事，支离破碎，很难被管理。用户故事变成了内部的技术需求，不能做到端到端，成了只有研发团队关心的“故事”，等等。 存在一些比较流行的用户故事拆分原则。但是，在过去几年中，我们突然发现自己好像早已忘记了用户故事拆分这个实践的存在。当我们进行需求澄清的时候，通常是一个实例化需求工作坊结束，完全符合 INVEST 原则的用户故事就已经在那儿了。 我们将通过本场 Chat 来分享我们的一些经验，也希望帮助仍然纠结于怎么写出小的用户故事的敏捷团队，能通过更小的代价和更有序的方法来获得高质量的用户故事。 ------ 作者/分享人： - 吴穹，资深创新管理顾问，精益看板专家。 - 张刚，资深架构师、敏捷顾问，专注于领域驱动设计、微服务、实例化需求等在企业的落地实施。 - 雷晓宝，工程实践顾问，专注企业软件设计、测试自动化，开发生产力等领域。

在传统团队实施敏捷转型的时候，最经常采用的两种方法就是Scrum和Kanban。然而，由于两种方法各有千秋，两派的专家们又经常会在各种场合争执不下，所以很多时候让刚做转型的团队不知道该如何选择。其实，在具体实施的时候，很多时候需要根据组织和团队的特点，具体情况具体分析，采用合适的实践来解决具体的问题。在这种情况下，就需要把Scrum和kanban结合。 本场三人行，将会由多位经验丰富的敏捷转型实施顾问、教练、培训师一起来和大家聊聊，内容包括但不限于以下内容： - Scrum - 本质 - 优点 - 单独实施可能出现的问题 - Kanban - 本质 - 优点 - 单独实施可能出现的问题 - 为什么要结合这两种方法？ - 两种方法如何结合？ - 结合之后可能产生的效果 - 实际案例分析 交流形式： - 正式交流：( 20min 圆桌讨论 + 10min Q&A ) × 3 - 自由交流：30min ------ 作者/分享人： - **[吴穹](http://gitbook.cn/m/mazi/author/585283cdc07767eb0faa02c6)**，资深创新管理顾问，精益看板专家。 - **[申健](http://gitbook.cn/m/mazi/author/5862fefee3ddda0512a1fe83)**，资深敏捷顾问，首位Scrum联盟认证CTC教练。 - **[王宇](http://gitbook.cn/m/mazi/author/58b611baea57cd1875921799)**，资深敏捷顾问，共创式教练。 - 侯伯薇，敏捷顾问，管理3.0及CIPT认证培训师。 **实录提要：** - Scrum 的站会和看板的站会具体有什么区别，或者说有什么建议和注意事项？ - 使用两者后到底给团队和组织带来哪些不同变化和影响呢？ - 跨职能部门之间的短期项目协作用什么样的方式呢？ - wip 的数量有没有推荐的计算方式？ - 如何在面对面沟通受限的情况下，通过看板和其他辅助工具/技巧/方法来确保沟通的有效性和工作的可视化？ - ScrumBan 跟用户故事地图怎么结合一下呢？ - 根据具体项目介绍下 Scrum 和 Kanban 在实际运用的区别。 - 忽视技术实践：能否举例？ - 为什么 Kanban 难以进行建模，如持续交付流水线、TDD 和重构过程、模块化设计等？ - 感觉项目管理就是一项细活，对基本的需求能否能实现有所了解就行了吗？ - Scrum 团队对于交付文档是如何看待的？ - 如何避免小瀑布？ - 如果做到进一步，一天一个迭代，是不是会更逼着团队去自己想办法去优化？

听说：分布式架构的第一原则是“不要分布式”。那么，微服务架构的第一原则，是不是不要“微服务”呢？ - 在什么情况下，我们必须做架构拆分，并且将之拆分为一个一个的微服务？在什么情况下，又可以停下拆分的动作了呢？ - 在拆分的过程中，那些牵扯不清的部分，如何梳理？如何斩断？ - 数据库、API、消息队列、Web页面等诸多部分，应该如何妥善的处理？有没有成熟的经验可供参考？有没有已知的陷阱，可以提前预防？ 在本场Chat中，由庄表伟提供实际案例，由王渊命、肖德时共同分析、诊断，希望能够通过更加贴近实际的讨论，给大家带来更多的启发。 **实录提要：** - 监控系统如何监控自己？ - 阿里云推出了容器服务，采用他们容器服务是不是会降低微服务的门槛？ - 微服务接口的版本如何控制冗余比较好？ - 微服务中所有前后端交互是否都要走 API gateway ？ - 微服务之间是否会存在依赖关系？如何管理？ - Gitlab 后端采用的网络文件系统选型时有考虑过 glusterfs 吗？ - 什么的样的场景适合微服务？ ------ **作者/分享人：** 庄表伟，华为公司内源社区平台架构师，开源社理事。发起过的Chat包括[“我的架构感悟：从美国宪法学习架构设计原则”](http://gitbook.cn/m/mazi/activity/587778c802f36ffb098b0383)、[“如何实践Code Review？”](http://gitbook.cn/m/mazi/activity/584766374b79bc032f0e23c6)，以及[“聊聊代码提交那些事”](http://gitbook.cn/m/mazi/activity/5822b78e6a0b83c75c8dec8d)。 王渊命，QingCloud 容器平台负责人，前新浪微博架构师。发起过的Chat有[“etcd v2/v3 架构与实现解析”](http://gitbook.cn/m/mazi/activity/5829c82c9b3cc37401d4fb00)和[“基础设施服务的微服务化”](http://gitbook.cn/m/mazi/activity/58639d7595c29fc15b3abe1b)。 肖德时，曾任Redhat Engineering Service部门内部工具组Team Leader，是国内第一代 Docker 代码贡献者。发起过的Chat有[“运维达尔文：SRE的自动化演进”](http://gitbook.cn/m/mazi/activity/587321834fb087d9389a37d2)

软件测试在国内也是飞速发展的一个职业，俗话都说程序员很早就退休了，那么测试人员的职业发展会有哪些呢？本场Chat的主要内容包括： 1. 所谓软件测试技术到底包括什么？ 2. 为什么说测试液需要开发技能，测试策略和开发技能到底哪个重要？ 3. 测试前移，无专职测试，内测、灰度发布，测试开发等会是软件测试未来的发展趋势吗？ 4. 软件测试到底能够做到几岁？ 5. 软件测试人员职业应该怎么规划？ 6. 2017年你应该怎么提升自己？ ------ **实录提要：** - 如何去权衡成本与测试范围，测试强度？ - 如何以小成本来保证服务上线时的稳定性？ - 对于开发技能不高的我们难道最后只能转做产品或运维了吗？ - 测试策略经常被提到，但是什么才是测试策论，详细内容有哪些？ - 自动化测试的标准是什么？ - 自动化测试的最大价值体现在哪些方面？ ------ **作者/分享人：** 陈晔，伪 90 后，QCon ， GMTC 全球技术大会测试讲师。《大话移动 App 测试》系列丛书作者。目前在互联网金融行业奋斗，自媒体人。发起过的Chat有[“大话软件测试行业面试”](http://gitbook.cn/m/mazi/activity/587255462d6617b47d0cc511)和[“移动无线应用基础平台从0到1建设怎么做”](http://gitbook.cn/m/mazi/activity/5837a468a8f7f84532595ad3)。 梅子，10年网络安全产品经验。10年里职位基本都是测试，但做得杂。目前做产品经理了，但测试还是我的喜好。著有《测试架构师修炼之道》。发起过的Chat包括[“为什么我说测试策略才是测试的核心”](http://gitbook.cn/m/mazi/activity/589cff25b38f84e02fa645ee)、[“一张涂鸦搞定探索式测试”](http://gitbook.cn/m/mazi/activity/58627ccea1b142f653e24dd8)等。