sivagao
sivagao
找到新工作最简单的方式通过你的个人职场网络。那些认识你的人和你一起共事过的同事，最有资格为你的杰出技术才能和迷人个性背书，通过这些人直接和有HeadCount的HR经理直接联系上是最有效找到新工作机会的方法。不过，你的网络始终是你目前所能看到的一切（从而也限制了你）。如果暂时还不认识你想要的工作机会公司的人，或者你的人际关系不够强。这时候你还是要依赖于你的简历来撬开那家公司的大门。 我不止一次听到过这样的观点：简历对程序员来说根本不重要。这些人认为简历是过去的产物现在我们只需要关注候选人的Github简历就足够了。不过，在我看来，大部分应聘者除了一些简单尝试的小项目或fork别人的项目外，很少在Github上有太多工作。除非你的工作就是围绕开源项目的，所以你的简历是筛选简历的人唯一有的关于你所有信息的一切，通常也是决定你是否能进入下一轮的关键印象。 ### 反模式  大部分我见过的简历都没有把能进入我们团队的个人潜在价值沟通好。相反的，这些简历都多多少少了暴露来一些反模式： 模糊的说明着项目，夹杂着一系列的技术点，流行词汇和所谓的最佳实践。有资格的候选人被拒绝是因为离我的标准还有距离，还有不少候选人根本在简历山筛选上都没有通过。 你的简历上应该把你能够给公司和团队带来的价值阐述表达好（通过你给之前或现在雇主提供的价值说起）。下面我罗列来一些不好的反模式，也给出了相应的改进方案。 ### 技术掌握上 作为软件开发者，和潜在的老板聊聊你熟悉的各种编程语言和技术是很有价值的。对于不少职位，熟练掌握（甚至要精通）某项技术是职业必须项。不过，简单罗列技术名词，而对你掌握如何只字不提就不好了。尽管你的简历不必要成为详细的技术评审。你描述对一项技术的掌握可以给筛选简历的人积极的好感，也为将来的面试官看你简历时提供话题。 ### 反模式：罗列大量技术工具 就像是购物列表似的罗列语言，技术和工具，没有任何上下文来说明你是如何使用的，或者它们根本与你要申请的职位风马牛不相及。 - 例子： 工具：Ruby，JavaScript，jQuery，React，Git，Jira等 - 提升： 给我们的Ruby on Rails 项目体检一系列的移动客户端的API，如来记录各个国家地区的爆米花热狗的价格。通过etags实现缓存，来减少移动设备在消费 API时 60%的API响应时间。领导团队升级到 Rails5。在此之前，实施和验证几个 Rails4 的安全补丁。 - 提升：...
不管何时，你对你的代码仓库进行的任何修改，都会有可能搞砸线上的某些服务。 没人喜欢那样（服务downtime），没人喜欢惹怒用户，更没人喜欢惹怒他的经理。所以说每次发布迭代的新代码到线上都是充满压力的事。 不过，事实上不必每次都那么紧张的。在这篇文章我会反复说明这样的观点： 『你的部署应该变得非常无聊，非常直白，从而毫无压力』 部署产品服务新的主要功能到生产环境： - 应该是像在Hacker News上开始一次关于空格还是Tab的口水战一样简单 - 应该足够简单，以至于新来的员工都能上手 - 应该是防止产生错误的 - 应该是远远在用户看到新代码生效前被反反复复测试验证过的。 这是一篇非常长的（抱歉，但不得已不如此）的关于部署的较高层次的观点文章：协作，安全和节奏。不过文中还是有不少较为底层细节的部分，因为那些很难在语言层面上去抽象，所以不得不撩开袖子去单独解决和说明。我喜欢讨论团队间是如何配合协同，而部署恰恰是最需要和别人（团队）打交道的一件事，我认为你们要时不时花时间去验证下目前团队的一些做法，这很有价值。 这篇文章的内容大部分来自于我在Github长达五年的工作经历和最近一年为大大小小的很多创业公司的建议和咨询的经历（主要集中在提升它们部署流程方面，而它们之前的状况既有『目前还不错的』又有『要紧急救火的』）。特别值得说的是，其中一家叫 Dockbit 的创业公司，它们的产品正是为了在部署时更好协同。所以本文不少来自于我和他们团队城成员的交谈中，这其中有不少我认为是关于部署这个话题很有价值要记录下来与大家分享的。 我非常感谢来自于把不同公司的朋友对此篇文章的不断评审检查和建议（来源于他们自身在部署方面的深刻见解和经验）： Corey Donohoe (Heroku), Jesse Toth (GitHub), Aman Gupta (GitHub), and Paul...
在通过网络部署上云之前，我们网飞是如何编译代码？考虑到之前部分内容已经被讲诉过，这次我们准备分享更多细节。在这篇文章中，我们描述工具和技术用来从源代码到最总部署为线上服务来给全球超过7500w的用户提供电影和电视节目的服务 上述图标对之前博客讲的Spinnaker做了扩展，我们全球的持续交付的平台。如果一行代码需要进入Spinnaker中，这之间还有一系列的步骤用来执行。 - Code is built and tested locally using Nebula - Changes are committed to a central git repository - A Jenkins job executes Nebula, which builds, tests, and...
你们中很多人可能注意到了：在职位列表中，最近有个新类别在不断的如雨后春笋般冒出。 你们可能也注意到了有些工作看起来非常有趣，可能比你能接受上下班通勤范围内发现的工作机会都有趣。我认为每个人都应该有机会做他自己真正感兴趣的工作。如果我创办个公司，我找人的第一考察要素就是候选人是否对我们要做的足够有热情，其他的指标都没有这个重要！ 那么现在的问题是你该如何面试哪些你们梦寐以求的远程工作机会。接下来我们看看一些指导意见和一些你会向可能的远程工作的老板问的问题。 ### 彻底的远程工作 大部分我为之工作和支持过的公司都允许某种程度的远程工作。很明显一些比另一些好，因为远程工作对员工和老板都有一条较为陡峭的学习曲线。 一般而已在职位列表中出现标为远程的工作是指彻底的远程工作。这意味着你可以完全可以飞刀另外的国家去间一个朋友，在一个季度（甚至更少）才见上同事们一面（很显然是除了视频聊天的方式）。有时候你也不一定非要现场见他们。通过类似于Slack/Hipchat，像Skype或Google环聊这样的视频聊天工具，项目灌流工具等，交流沟通工作很容易被完成，对，别忘了还有电话和电子邮件。 ### 找什么样的远程工作 我相信有很多重要的事要注意，我建议你们在下面回复评论~ - 你们现在有多少全职的远程员工？ 好的回答：『我们员工大概有25%在远程工作』 不好的回答：『事实上你会是第一个，我听说把职位设成远程可以吸引更多人。对了，你考虑换城市到我们这吗？』 - 你们和远程员工间是如何沟通的？ 好的回答：『我们通常在网聊，但是通常在站立式早会上会接视频会议。除了小明（Fred）他在船房上网速带宽不高』 不好的回答：『我们使用 XXX 项目管理软件和电邮，大概就这样』 - 每天，你们在公司办公室的员工用 Slack/Hipchat 用的多吗？ 好的回答：『几乎一整天都在用。他们经常坐在旁边不转头聊却在聊天室中发消息~』 不好的回答：『既然他们都在办公室那就没必要用网上聊天了』 - 你们是怎么解决和远程项目成员的协作问题的？ 好的回答：『我们有个大画板，每个人都有个APP可以在在上面图画，其他人都能看到。我们也会让每个人参加项目的视频会议，如果有需要会定期对一些难题进行探讨』 不好的回答：『我们通常不会把人都叫上。在办公室的人会在白板上图画，然后就开始实施项目』...
## 问题 在 Airbnb，数据团队的一大指责就是让让我们基于数据的决策的系统更容易扩展。我们民主化[数据读取权限]()来让所有同事都能借助数据做出好决策，让他们使用[实验]()来正确衡量他们决定的影响力，把从用户倾向数据中得到的洞见加入到数据产品中从而提升我们产品的用户体验。最近，我们开始处理另一类型的难题。随着组织的不断的发展，我们要怎么确保一个人的精彩见解如何有效的传递给需要的人。在内部，我们成这个叫做知识规模化 一开始我们团队成员还不多，在团队内部分享各自发现的调研结果和技巧都很方便。但是随着团队不断扩展，之前的小问题变得越来越严重起来。就拿 小琳（Jennifer）的故事来说，新来的数据科学家想要把一个同事在Airbnb的房东退订这个话题的工作进一步拓展，我们来看看现在是怎么做的： - 小琳问组里的同事之前是否有相关工作的沉淀，然后各种展示 PPT，邮件和 Google 文档被扔过来。 - 之前的工作中的代码都过期了，小琳从之前的代码作者的机器复制或从过期的 Github 链接中拿到到代码。 - 做折腾修改几下之前别人的代码后，小琳却发现现在的结果和之前的图表有些差别，她决定要么要修改偏离代码要么重新开始写新代码 - 经过花了不少时间复现之前的结果，或者干脆放弃，自己从头开搞，她终于完成了自己的工作 - 小琳通过展示，邮件或 Google 文档把自己的工作结果和更多人分享，也开启呢下一个糟糕循环~ 和和其他公司在这个问题上沟通后，这样的例子太常见了。随着组织不断增长扩大，在团队内或跨团队的知识分享消耗呢大量的时间。这样的无效率的无政府的研发环境导致了成本飙高，分析和决策速度也随着降下来。因此，一个更加流式的解决方案可以加开决策的速度，让公司在快速增长的知识库上更加敏捷智能。 ## 解决方案 随着我们眼看上述有问题的流程被一遍遍重复，我们意识到我们能够做的更好。作为一个组织，我们聚集在一起，形成了以下5个关键的原则性信条： - 再现性：不需要代码复制后修改。整个查询，数据转换，可视化和相关文章都应该在每次提交中包括，并且确保和最终结果保持同步。 -...
https://medium.com/airbnb-engineering/data-infrastructure-at-airbnb-8adfb34f169c ## 我们数据平台背后的哲学 在airbnb，我们推崇数据导向的文化，利用数据作为我们市场决定的关键依据。跟踪指标，验证假设通过实验，构建机器学习模型，深挖商业价值，这些都让我们变得更快更明智。 经过许多次的进化步骤，我们现在感到我们的数据基础架构栈变得稳定，可依赖和可以扩展的。所以这看起来是个好机会，来和社区分享我们的经验。在最近几个星期，我们发布了不少博客文章来讲述我们的分发/分布式架构和我们的工具集。因为开源贡献者提供了许多我们现在在用的基础系统，这些让我们也非常乐意于通过开源有用的项目在github来回馈社区，也记录我们这一路学到的东西~ 在我们实施数据基础架构时，一些非正式哲学慢慢形成了： - 借鉴开源社区 - 倾向于标准组件和方法 - 确保它可扩展 - 倾听同事，解决实际问题 - 预留更多资源 ## 基础架构概述  上图是简化的图表来展示我们基础架构中的主要组件 我们系统的原数据主要来自于两个主要的渠道：那些代码中的指令通过kafka来发送书剑 和 生成数据库dump出然后通过Sqoop导入（通过AWS的RDS(类MySQL)在时间恢复点导出） 这些源头数据包含了用户活动事件数据和多维的快照被接着发送到黄金集群（Gold）中（我们用于存储数据和开始跑我们的ETL任务（抽取，转换和加载）在这一步，我们实施业务逻辑，构建汇总表，和实施数据质量检查。 在上图中，有两个分离开的集群代表Gold金和Silver银，它们会在下一博文中详细讲解。抽象解释下这样分离是为了确保计算和存储资源的隔离，这样在遇到灾难等情况可以提供确保恢复的机制。这样的架构让Gold环境下，大部分重要的任务可以在严格确保下运行，SLA服务级别得意确保，从而避免受到资源密集型的热查询的干扰。我们也把Silver环境作为生产环境，但是不那么严格要求和容忍突发的资源密集的查询 要意识到通过设置两个集群我们拥有了隔离的能力，但是它的代价是大数据量的数据复制和复杂动态系统间的数据同步的管理。Gold是我们数据源头，我们从它那边到Silver做全量的复制。在Silver产生的数据不会被复制到Gold下，你可以这样认为这样的单向复制的设计方式让Silver免于成为其他任何东西的父集。 因为我们很多的分析和报告在Silver集群上实施，所以确保新数据被尽快加载到Silver中使用户的任务执行的没有延期是至关重要的。更重要的是，如果我们在Gold集群更新现有的数据，我们必须通知更新事件和同时把更新的变化同步到Silver。这复制优化问题在开源社区目前木有什么好方案，所以我们在接下来的博客中会详细描述为解决这问题构建新的一套工具。 我们在调优HDFS上付出了巨大的努力，对我们的中间源和数据池 - Hive管理的数据表提供更精确的调优。数据仓库的质量和稳健依赖于数据要不可修改和所有的延生可以被重现...
--- title: 【Guide】 写给那些还不想走向技术管理程序员的职业建议 ## categories: Guide 做一辈子程序员是否是一个好的职业选择？或者如果在工程师这个职业阶梯上进一步发展是否必须要走向管理？这是不少工程师在知乎 Quora 表示疑惑的。这是个需要来陈述解决的重要问题，尤其对那些心理上不愿意去管人的工程师们。 好消息是，一直做个好的软件工程师，请求免除做管理的安排，仍然是一个较好的职业选择。但不管怎么样，如果你想要突破那层天花板，你不能仅仅是期望持续多年的技术开发经验就能让你走上职业阶梯顶层。一个关于你职业的大致模型是：你的成就和成长是跟你创造的价值成正比的。 ### 技术能力 + 开发经历 /= 影响力 那些在 Google 呆了10年以上拥有深厚经验的工程师们，常常质疑自己为什么仍然是位高级软件工程师的title。那些职业初期快速职位提升的事情看来已经远去，为什么其他同事可以比自己提升的更高更快？ 工程师，尤其是那些不想做管理的，会犯的一个大错误是：认为技术能力加上工作经历就会提升自己的影响力。他们甚至常常幻想：如果继续做好工作，他们最终将会获得提升。这个想法是错误，下面是两个原因： 首先，你写代码和构建软件的技术能力随着时间趋于稳定。在你职业初期的那些尝试，你会经常犯一些错误。每个小项目都是打磨你编程技能的好机会。但随着时间流逝，你在软件设计上变得熟练，几乎更少的犯错。你早期在职业阶梯上的一次次提升来源于你早期的技术学习。10年后，你可以仍然保持学习 - 你可以选一门新的编程语言，去学习新的酷炫的框架，但是你的进步和提升肯定不会像你职业生涯第一年那样的快。 其次，经历不会简单而直接的变成影响力。如果十年后二十年后，你仍然解决这目前这样规模和这个领域的问题，实际上你并没有在提升能力来创造影响力。如果你没有创造新的价值，为什么会有老板愿意非给同样没有经验的人付更多的薪水？这个事实在任何其他行业和职业也是存在的。 继续保持做目前做的事情（编程）是简单的，容易的，让人舒服的。如果你想把精力花在其他地方，这个选择也是非常合理的，但是就不要期望你的职业也能随着年限而发展。真正重要的不是你工作了多长时间，而是你创造了多少价值。如果想保持在职业上的继续发展，那么就持续找到新的提升你影响力的方法吧。 ### 管理不是提升你影响力的唯一途径和杠杆 拥有良好的职业生涯，转向到管理是一条途径，但不仅仅只有这条。许多工程师成为管理者是因为管理提供了显而易见又真实有效用于提升影响力的杠杆支点。随着团队的成长需要管理者，多年的技术经历对于发展技术管理技能来说是很有用的资产。作为管理者，你影响和改变着你负责的产品和工作。如果你是好的管理者，你就能提升你们团队所有人产出的新价值。如果这新价值超过你作为独立开发者能提供的，那么你的管理就是有价值的。 管理，只是一种职业发展途径。不是每个厉害的工程师都会成为或适合成为一个好的管理者。只要你能找到那些提升你影响力的杠杆支点，你的职业就能继续发展。在很多技术起重要作用的大型公司里，如Google,...
--- title: 【Review】 成为高效工程师 ## categories: Review 首先，作者有本书[The Effective Engineer](https://www.theeffectiveengineer.com/book/sample-chapter)。主要亮点是一手的最新的故事和技巧从硅谷创业公司，很多技巧非常实用和有帮助。譬如顶级的软件技术公司，如 Google, Facebook, Twitter, 和 LinkedIn 这些家喻户晓的; 快速成长的中型独角兽公司，如 Dropbox, Square, Box, Airbnb, 和 Etsy; 还有那些酷炫的初创公司，如 Reddit, Stripe, Instagram, 和 Lyft。 作者的书其实是从他两三年前的博客中抽取的：...
> 本文以后会持续更新，请 Star 本项目~ 本文先后从下面三个方面，整理和讲诉在这个过程中能够帮助我们更有效率和事半功倍的一些好用却不那么被人熟知的工具。 - 探索项目 - 专注项目 - 关注开发者 大致的讲诉逻辑是： - 我们首先要在巨多的开源项目中找到哪些优秀并且我们感兴趣的项目，包括了提供最近流行，历史排行，类似项目和特定领域层面； - 然后我们要专注和学习找到的项目，此时有效率的浏览代码，文章甚至依赖，查看项目信息，在活跃的社区沟通和快速 demo 和尝试试用就变得很重要； - 最后，我们学习开源项目也是为了成为更好的开发者。通过『观察大师，模仿大师，最终成为大师』，所以要定位到那些厉害的程序员和定期关注他们的动态。 > 如果不想看这么多，可以直接看[该项目的首页](https://github.com/github-serendipity/github-serendipity.github.io)，Github Serendipity 会把下文提到的好工具集成进来，帮助开发者快速发现值得关注的好项目~ ## 探索项目 经常的浏览 Github 对于开拓技术眼界，扩宽自己的知识面，更新自己的技术储备非常有帮助。而高效率的找到好的开源项目，定位到热点技术话题的项目，对我们探索学习非常关键。 ###...