关于进化

以下为个人理解和读书笔记

  • 生物进化在尺寸、速度和能源消耗方面有计算机模拟无可比拟的优势,条件适合,一小时内可以产生出十亿个副本。

  • 核糖核酸统一了信息和机体,既是表现形式,又是内在成因。既要充当信使,本身又是信息。既要担当起与世界互动的责任,又要完成延续世界的重任,把信息传递给下一代。本身又极为紧凑。人工进化正可以由此展开。

  • 定向进化是另一种监督式学习,选择由培育者引导。

  • 对个体而言最好的,对物种而言却不一定。

  • 进化是一种计算。

  • 弱学习

  • 生物DNA无法将自己的代码向其他生物体“广而告之”。

  • 达尔文系统缺陷在于无法把已获得的有利的知识和变化引入到遗传和进化中。只能通过死亡等消除不利变化。

  • 非达尔文进化系统,拉马克进化-获得性遗传,有用的变异能更快的进入基因序列。

  • 拉马克系统缺陷在于对于一个有利的变化,需要回溯基因构成,像质因数分解一样难度极高。是一种不可能存在的生物解密方案。但是在计算机进化中可以通过“表里如一”的自复制实现。(地球上的生命已经通过了自复制分子这个阶段?与系统复杂性相关?)

  • 拉马克系统允许个体在世时所获的信息可以参与进化。

  • 蚁群算法,单只蚂蚁毕生学习所得成为蚁群信息遗产的一部分。

  • 投入“传播”的信息量非常少,范围非常小,信号非常弱。弱传播。

  • 人类的学习(知识文化传递)就是一种对没有拉马克进化-获得性遗传的弥补?

  • 并行系统是水平的、并发的、错综复杂的因果网络,非线性特征,没有清晰的步骤可循,事件此起彼伏。为其编程很困难。

  • 电网,电话网,计算机网络,金融网络都是并行系统。

  • 人类个体无法掌握充分利用并行处理能力的方法。超出我们的掌控能力。

  • 人类应该只编写那些小而精,快而准的个体程序,注入自然进化来进行并行。

  • 程序过于庞大无法完整测试和保证没有缺陷。而进化出来的东西在成长环境里有足够多的测试。

  • 程序过于庞大,仅仅维护程序、保持正常运行本身将会成为一个主要负担。(程序员24小时待命)

  • 人工进化可以进化出更完美的东西,进化能看护我们无法看护的世界。

  • 进化的代价就是失控。我们放弃了某些控制。

  • 与其正确,不如灵活,不如耐久。蚂蚁对身处的世界茫然无知。

  • 舍控制取力量。

技术面试指南

面试流程

通常我们的面试分为一次电话面试和一次现场面试。在少数难以决定的时候会多增加一轮电话或现场面试。

面试中的沟通问题

尊重候选人,平等交流:让候选人自我介绍前,先介绍自己和公司;交流的时候双方处于平等的地位,耐心听完对方的话;在面试过程中不要有驳倒候选人的意图。无论是电话面试还是现场面试都应该做到守时。我们在考察别人的时候,别人也在考察我们。

把握好面试节奏:面试从双方的自我介绍开始,然后开始从候选人过去的职位和做过的项目开始谈起,这些都应该是候选人熟悉的内容,为后面更难的技术问题建立良好的沟通氛围。

不要只求答案正确,要本着一起讨论的方式让候选人充分说明解题思路;不要不断地变换问题,每个问题点到即止。对一个问题要一层层深入,直到候选人回答不了或完整解答为止,这样才能知道候选人思考达到的深度在哪里。

面试的重点是考察候选人解决办法的思路。可以从一个简单的问题开始,候选人给出回答后,在上一个问题基础上做些变化进一步加大难度,考察候选人思路是否灵活;也可以从一个困难的问题开始,考察候选人分解复杂问题的能力,在长时间没有进展时应该给出一些提示。同时也要注意考察候选人在遇到困难时是否会问合适的问题。

给候选人对你提问的机会:我们要通过面试了解候选人,候选人也需要在这个过程中了解我们。在面试结束前应该给候选人提出对我们的团队、产品、面试过程、职位需求等方面问题的机会。一来解答对方的疑问,二来也可以看出他对新工作的期待程度和热情高低。

每一次面试,并不仅仅是一次壮大团队的机会。哪怕最后没有招来新同事,也可以多让一个人知道我们的公司和产品。我们的用户群和我们招聘的目标人群是重叠的,我们接触的每个人都可能传播我们的形象和品牌。

面试中需要考察的问题

对不同的技术职位下面的几个方面有不同的权重,但都应该基本覆盖到:

  • 基础知识:基本的数据结构和算法;
  • 排序、二分查找等经典算法在现实中的应用;
  • 对概率的基本理解;
  • 对时间和空间复杂度的理解;
  • 所招聘职位相关的专业问题(iOS、Android、后端架构等)。

面试中应避免的问题

  • 与技术和实际工作无关的智力题,比如过去曾很流行的和海盗、金币、球相关的一类问题。因为在面试中能比较快回答出这类问题的通常是曾在网上看到过答案的人,并且这类问题对预测候选人在实际工作中的表现几乎没有参考价值。
  • 网上常见的所谓 Microsoft、Google 面试题等,原因同上。
  • 非技术的假设性问题:假如现在要赶活;假如有两件事情摆在你面前;假如老板故意刁难你;假如有一个不好合作的同事。

转自:http://open.leancloud.cn/tech-interview-guide.html

代码分支管理指南

介绍

这是我们团队的 Git 分支管理规范。每个人对工具的使用往往各有偏好,各种方法各有利弊,无所谓对错。但涉及团队协作的方面需要有一些一致的规范,所以请大家务必遵守。

除了一致性之外,这个规范的目的是以下几点:

  • 确保可以轻易确定特定时间发布或运行的版本。在新发布的程序存在重大缺陷时,可以尽快 rollback 到上一个稳定版本。
  • 在需要修复紧急 bug 并尽快发布时,可以只发布必要的 bugfix 而不同时发布还不应发布的其他改动。

branch 和 tag

每个官方的 repo(leancloud/ 下的都是官方 repo)有且仅有以下的 branch 和 tag。

Branch: master release。其中 master 对应目前的开发分支,所有的 pull request 都应该发到这个分支。release 是当前发布的分支,在这个分支只能增加从 master cherrypick 过来的 commit。详见本文后面的说明。

Tag: 对应每个发布版本的 tag。SDK 和应用程序的 tag 遵照 <major>.<minor>.<patch> 的命名,如 2.5.1;服务端程序的 tag 以发布的日期命名,如 2014.11.13,如果有 bugfix,则在后面增加小写字母,如 2014.11.13 后是 2014.11.13a,然后是 2014.11.13b

目前还有部分 repo 包含多个独立部署的项目(如 uluru-platform)。在这样的 repo 打 tag 时需要附上项目名做前缀,如 bigquery-2.5.1。但我们需要逐步把这些项目拆分到独立的 repo。

发布新版流程

  • 确保所有要发布的 pull request 都已经 merge 到 master
  • 使用 master branch 的代码进行测试,如果发现 bug,把对应的 bugfix merge 到 master
  • 删除旧的 release branch,并从当前的 master 创建新的 release branch;
  • 在 Jenkins 上从releasebranch 发起新的 build 并发布;
  • 发布完成后在当前的 release branch 打上对应版本的 tag。

Bugfix 流程

这里的 bugfix 指的是修复已经发布的程序(release branch)中的缺陷。master 里的 bug 请直接 merge bugfix 到 master

  • 如果此缺陷在master中还存在,请先 merge bugfix 到master ,否则跳到下一步;
  • releasebranch 从mastercherrypick 修复该缺陷的一个或多个 commit;
  • 在 Jenkins 上发布当前releasebranch;
  • 发布完成后在当前的releasebranch 打上递增的 tag。比如,如果上一个 tag 是2.5.1 ,这个 tag 应该是2.5.2 ;如果上一个是2014.11.13 ,这个就是2014.11.13a

其他

并不是每个 bug 都有专门发布 bugfix 版的必要,对于不紧急的 bug,可以在master里 fix 后随下一个版本发布。

在一个官方 repo 下只应该有以上说的 branch 和 tag,在开发过程中使用到的 feature branch 等请都放在个人的 fork,一律通过向master发 pull request 的方式给官方 repo 提交代码。

转自http://open.leancloud.cn/git-branch-guide.html

工作的评价和反馈机制

评价和反馈

我们在每个季度结束时会进行一次 performance review,即工作的评价和反馈。流程一定程度上借鉴了 Google 的 performance review, 但有不少简化和修改,以避免给大家造成额外的负担,毕竟我们的主要精力应该放在改进产品而不是处理内部流程上。

这个流程分为两部分。

自我评价及工作反馈

在季度结束时,每个同事会收到一个 Google Docs 表格,包含以下几个问题。除了第一个问题外,其他内容都会对其他同事保密,只有自己的主管和 HR 可以看到。

自我评价

  • 请列出过去一个季度你参与的工作、承担的职责、完成的具体内容,并陈述工作实际产生的价值。请尽可能详尽。如果有在自- 己日常职责之外的贡献,也请单独列出。(这部分内容将对所有人公开)
  • 针对以上列出的工作请给出对自己工作的评价。请总结得失以及原因。有哪些地方有改进的空间?
  • 针对上面的问题和需要做的改进,请列出在下个季度的具体改进计划。

工作反馈

  • 公司在哪些方面给你提供更多资源或支持可以让你工作得更好?
  • 对于你的主管或管理团队的工作有哪些反馈和建议?
  • 对于团队建设、公司文化有哪些反馈和建议?

主管评价

每个担任 people manager 的同事会收到下属的自我评价和工作反馈。每个 manager 会为每位下属写主管评价和反馈,同时打出本季度的绩效得分。绩效分数在 0.0 至 2.0 之间,其中 1.0 表示工作达到期望,低于 1.0 表示低于期望,高于 1.0 表示高于期望。这里的「期望」和每个人的职能、级别和薪酬相关。

对薪酬的影响

绩效分数对薪酬的影响体现在年终奖上。我们的年终奖计算公式为:

年终奖 = 本年度累计实际工资 * 15% * 年度个人绩效 * 年度公司绩效

其中的年度个人绩效即为个人各季度绩效分数的平均数。年度公司绩效由管理团队在年末评定。

结语

我们的 performance review 首要目的是为每个人提供一个总结工作并听取反馈,明确得失以便改进的机会;次要目的是通过浮动的年终奖让做出更多贡献的同事能得到更高回报,做到相对的公平。希望每个人都以坦诚、认真、实事求是的态度对待这项工作。

转自http://open.leancloud.cn/perf-review.html

git commit emoji

commit 格式

git commit 时,提交信息遵循以下格式:

1
2
3
4
5
:emoji1: :emoji2: 主题

提交信息主体

Ref <###>

初次提交示例:

1
git commit -m ":tada: Initialize Repo"

emoji 指南

emoji emoji 代码 commit 说明
🎨 (调色板) :art: 改进代码结构/代码格式
⚡ (闪电)🐎 (赛马) :zap:``:racehorse: 提升性能
🔥 (火焰) :fire: 移除代码或文件
🐛 (bug) :bug: 修复 bug
🚑 (急救车) :ambulance: 重要补丁
✨ (火花) :sparkles: 引入新功能
📝 (备忘录) :memo: 撰写文档
🚀 (火箭) :rocket: 部署功能
💄 (口红) :lipstick: 更新 UI 和样式文件
🎉 (庆祝) :tada: 初次提交
✅ (白色复选框) :white_check_mark: 增加测试
🔒 (锁) :lock: 修复安全问题
🍎 (苹果) :apple: 修复 macOS 下的问题
🐧 (企鹅) :penguin: 修复 Linux 下的问题
🏁 (旗帜) :checked_flag: 修复 Windows 下的问题
🔖 (书签) :bookmark: 发行/版本标签
🚨 (警车灯) :rotating_light: 移除 linter 警告
🚧 (施工) :construction: 工作进行中
💚 (绿心) :green_heart: 修复 CI 构建问题
⬇️ (下降箭头) :arrow_down: 降级依赖
⬆️ (上升箭头) :arrow_up: 升级依赖
👷 (工人) :construction_worker: 添加 CI 构建系统
📈 (上升趋势图) :chart_with_upwards_trend: 添加分析或跟踪代码
🔨 (锤子) :hammer: 重大重构
➖ (减号) :heavy_minus_sign: 减少一个依赖
🐳 (鲸鱼) :whale: Docker 相关工作
➕ (加号) :heavy_plug_sign: 增加一个依赖
🔧 (扳手) :wrench: 修改配置文件
🌐 (地球) :globe_with_meridians: 国际化与本地化
✏️ (铅笔) :pencil2: 修复 typo

参考