0%

简介

在 Color 我们希望每个人都和团队有一致的长期利益,而不是把在这里工作看做一份一般的 day job,每个人也都应该分享产品的成功带来的长期价值,所以我们的期权激励计划包括每位全职员工。

无论是薪酬还是期权,绝对的公平都是难以保证的。我们制定这些规则的目的是为了在日常的运转中有一致的 guideline 可以遵循,保证管理团队诚实且相对公平地做出决策。

期权的计算

每位同事的期权数由以下公式算出:

(Function × Experience + Impact) / Risk

其中 Function、Experience、Impact 的含义与薪酬体系一致,但具体数值不同。Risk 代表目前公司面临的风险,在公司发展的不同阶段取值不同,在正常的发展过程中是递增的(代表风险的降低)。

每个同事在入职的第二个月底前可以选择放弃薪酬中的 Choice 部分(详见薪酬体系)交换 20% 的更多期权。

Vesting Schedule

授予的期权分四年授予(vest),在入职满第一年的时候 vest 25%,之后每个月匀速 vest。

员工离职的时候可以选择对已经 vest 的部分行权从而保留股份;对于做出突出贡献的员工,董事会可以免除行权的要求,从而让他/她直接保留已经 vest 的期权。

期权的调整

当一个同事的级别和角色发生变化时,我们会按照上面的公式重新计算(Risk 的取值为发生变化时的取值)。如果结果大于原来已分配的期权,则会分配新的期权补足差额,新分配的期权从变化发生时开始 vest。

也就是说,在公司内成长的速度大于公司本身成长速度的同事将获得更多的期权。

评价和反馈

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

这个流程分为两部分。

自我评价及工作反馈

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

自我评价

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

工作反馈

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

主管评价

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

对薪酬的影响

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

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

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

结语

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

What is Hadoop

Hadoop is built to process large amounts of data from terabytes to petabytes and beyond. With this much data, it’s unlikely that it would fit on a single computer’s hard drive, much less in memory. The beauty of Hadoop is that it is designed to efficiently process huge amounts of data by connecting many commodity computers together to work in parallel. Using the MapReduce model, Hadoop can take a query over a dataset, divide it, and run it in parallel over multiple nodes. Distributing the computation solves the problem of having data that’s too large to fit onto a single machine.

Hapood 跟过去的分布式工具有什么不同?

  1. Hapood可以以处理最简单的流式数据,不用特定的格式、结构.
  2. Hapood有非常好用的API来方便分布式编程。
  3. 可以方便的管理,也有节点宕机自动切换功能。
  4. 更加灵活,因为不受数据结构限制。

HDFS

Hapood Ditribute File System

自我测验

用20个短句描述自己

  1. 20岁,男,170cm,65kg
  2. 良好的审美
  3. 聪明,学东西快
  4. 中国科大本科毕业
  5. 程序员
  6. 语言表达能力一般
  7. 爱打篮球
  8. 爱看书
  9. 腰有毛病
  10. 戴眼镜,头发黑,稍长
  11. 情商一般,不能很好的觉察到对方的情绪变化
  12. 德行好,让人感觉舒服
  13. 喜欢老爸,不喜欢老妈
  14. 家境一般
  15. 积极向上,有事业心
  16. 不善于做决定,有些犹豫
  17. 一家创业公司的CTO和创始人
  18. 不健谈,有时候会让人尴尬

摘要:一份学习计划

技术

  1. RESTful接口设计
  2. 网站高并发处理
  3. 分布式数据库搭建
  4. 多服务器通信
  5. 设计模式、架构的深入学习
  6. 手机通用开发平台的研究

管理

  1. Scrum和实际生产的结合,制定出符合自己的目标。
  2. 团队管理、激励、提高。
  3. 招聘,公司文化宣传。

产品

  1. 用户需求调研、整理需求。
  2. 产品经理相关技能学习。

微博上有人说“好的架构是进化来的,不是设计来的”。的 确如此,其实还可以再加上一句“好的功能也是进化来的,不是 设计来的”。

现在摆在他们面前的问题是用什么办法把一个庞大的网站从PHP语言迁移到Java?而且要求在迁移的过程中,不停止服务,原来系统的bugfix 和功能改进不受影响。亲,你要是架构师,你怎么做?有人的答案是写一个翻译器,如同把中文翻译成英文一样,自动翻译。我只能说你这个想法太超前了,“too young, too simple, sometimesnaive”。当时没有,现在也没有人能做到。他们的大致方案是 给业务分模块,一个模块一个模块地渐进式替换。如用户模块, 老的member.taobao.com继续维护,不添加新功能,新功能在新 的模块上开发,跟老的模块共用一个数据库,开发完毕之后放到 不同的应用集群上,另开一个域名member1.taobao.com,同时再 替换老的功能,替换一个,就把老的模块上的功能关闭一个,逐 渐把用户引导到member1.taobao.com,等所有的功能都替换完之 后,关闭member.taobao.com上。从设计上来看,这个member1的二级域名应该是一个过渡状态,但我们把member域名的代码下线以后,发现很难把member1切换回member,因为有些地方把 链接写死了,于是后来很长时间里我们都是在用member1.taobao. com这样奇怪的域名。

其实在任何时候,开发语言本身都不是系统的瓶颈,业务带来的压力更多的存在于数据和存储方面。前面也说到,MySQL撑 不住之后换为Oracle,Oracle的存储一开始在本机上,后来在NAS 上,NAS撑不住了用EMC的SAN存储,再后来,Oracle的RAC撑 不住了,数据的存储方面就不得不考虑使用小型机。

说到商品详情,这个字段比较恐 怖,有人统计过,淘宝商品详情打印出来平均有5米长,在系统里其实放在哪里都不招人待见。笔者清楚地记得,我来淘宝之后担任项目经理做的第一个项目就是把商品详情从商品表中移出来。它最早与商品的价格、运费等信息放在一个表中,拖慢了整张表的查询速度,而很多时候查询商品信息是不需要查看详情的。于 是在2005年的时候,我把商品详情放在数据库的另外一张表中, 再往后,这个大字段被从数据库中请了出来,先是放入了缓存系 统,到现在是放进了文件系统TFS中。

在某个规模以下采用现有的商业解决方案,达 到某种规模之后,商业的解决方案无法满足,只有自己创造解 决方案了。

此文为Scrum极限编程在worktile工具中的应用规范。需要读者对Scrum极限编程有基本的认识,对worktile有过操作经历。因为worktile并不是专门为scrum设计的工具,所以在很多方面需要我们自己规范自己遵守。此篇文章,结合了worktile自身特点,整理出了一份操作规范。
Read more »

The first five principles are principles of class design. They are:

SRP The Single Responsibility Principle A class should have one, and only one, reason to change.
OCP The Open Closed Principle You should be able to extend a classes behavior, without modifying it.
LSP The Liskov Substitution Principle Derived classes must be substitutable for their base classes.
ISP The Interface Segregation Principle Make fine grained interfaces that are client specific.
DIP The Dependency Inversion Principle Depend on abstractions, not on concretions.

The next six principles are about packages. In this context a package is a binary deliverable like a .jar file, or a dll as opposed to a namespace like a java package or a C++ namespace.

The first three package principles are about package cohesion, they tell us what to put inside packages:

REP The Release Reuse Equivalency Principle The granule of reuse is the granule of release.
CCP The Common Closure Principle Classes that change together are packaged together.
CRP The Common Reuse Principle Classes that are used together are packaged together.

The last three principles are about the couplings between packages, and talk about metrics that evaluate the package structure of a system.

ADP The Acyclic Dependencies Principle The dependency graph of packages must have no cycles.
SDP The Stable Dependencies Principle Depend in the direction of stability.
SAP The Stable Abstractions Principle Abstractness increases with stability.

中文版:

首字母 指代 概念
S 单一功能原则
单一功能原则
认为对象应该仅具有一种单一功能的概念。
O 开闭原则
开闭原则
认为“软件体应该是对于扩展开放的,但是对于修改封闭的”的概念。
L 里氏替换原则
里氏替换原则
认为“程序中的对象应该是可以在不改变程序正确性的前提下被它的子类所替换的”的概念。参考 契约式设计
I 接口隔离原则
接口隔离原则
认为“多个特定客户端接口要好于一个宽泛用途的接口”[5] 的概念。
D 依赖反转原则
依赖反转原则
认为一个方法应该遵从“依赖于抽象而不是一个实例”[5] 的概念。
依赖注入是该原则的一种实现方式。

职责链模式

当客户提交一个请求时,请求沿链传递直至有一个ConcreteHandler对象负责处理它。

典型的例子是UI系统的事件冒泡系统。

命令模式

  • 命令模式允许请求的一方和接收的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否被执行、何时被执行,以及是怎么被执行的。
  • 命令模式使请求本身成为一个对象,这个对象和其他对象一样可以被存储和传递。
  • 命令模式的关键在于引入了抽象命令接口,且发送者针对抽象命令接口编程,只有实现了抽象命令接口的具体命令才能与接收者相关联。

最典型的例子是yii2框架里的Action。

解释器模式

(略)

迭代器模式

  1. 它支持以不同方式遍历一个集合。
  2. 简化了集合的接口
  3. 在同一个集合上,可以同时有多个遍历。

中介者模式

用一个中介对象来封装一系列的对象交互。中介者是的各对象不需要显示地互相引用,从而使其耦合松散,而且可以独立的改变他们之间的交互。

典型的例子:cocos2d-x 中的 cc::Director。
iOS中的Controller其实也是一个中介者。

备忘录模式

在不破坏封装性的前提下,捕获一个对象的内部状态,并在该独享之外保存这个状态,以便以后将对象恢复到之前的状态。

观察者模式

定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动更新。

典型的例子是常见的addEventListener()以及MessageCenter.

状态模式

允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。

在下面的两种情况下均可使用State模式:

  • 一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为。
  • 一个操作中含有庞大的多分支的条件语句,且这些分支依赖于该对象的状态。这个状
    态通常用一个或多个枚举常量表示。通常,有多个操作包含这一相同的条件结构。State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象,这一对象可以不依赖于其他对象而独立变化。

策略模式

定义一系列的算法,把他们一个个封装起来,并且使他们可以相互替换。本模式使得算法可独立于使用它的客户端而变化。

一个典型的例子是cocos2d-x中的Render

模板方法模式

  • 定义一个操作中的算法骨架,而将一些步骤延迟到子类中。TemplateMethod使得子类可以不改变一个算法的结构即可重定义改算法的某些特定步骤。
  • 一个模板方法用一些抽象的操作定义一个算法,而子类将重定义这些操作以提供具体的行为。

访问者模式

表示一个作用于某对象结构中的各元素的操作。他使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。