现在社会发展已经很宽容了，因为已经有一定比例的普通人已经拥有选择工作的权利。
这意味着，这一部分人可以按照自己的兴趣爱好选择工作内容，而这种性质的工作才是马克思主义提倡的，工作是为了体现个人价值，这样的人会在工作中创造价值，而不容易被工作异化。
诚然，天赋能让人更容易在面对开拓性质的领域上获得成就，更容易构建出新的体系，创造出更大的价值。
但这不意味着资质平庸的人就不能创造价值，每个人都可以努力寻找到自己的兴趣爱好所在，然后为此投入足够的时间锤炼相关的领域的技能，并从这个过程中获得取悦自己的成就感，即便这个过程中的产出可能是重复的，对其他人是无价值的。可是我相信只要在这样的方向上投入足够的精力精进，最终一定能够将自己的个人技能与该领域融会贯通，做出真正有价值的产出。
至此才能说对一个人而言，真正宝贵的是时间，因为锤炼技能必不可少的就是投入时间。即便可以花钱聘请对应领域的“教练”针对性培训技能，减少在锤炼技能上花费的时间，但最终想要有所产出，是必须投入时间思考和创作的。
再看资本运作，好的资本运作应该是帮助更多人创造价值，因为资本本身无法创造价值，资本想要得到回报，只能靠压榨其他人的劳动产出的再分配过程获得。国家亦是如此，通过税收等多种再分配手段获得利益。
资本要做的应该是什么呢？最佳的方式应该是投入科研领域这种性质的投资，让具备创造价值潜力的人做开拓性质的探索及产出，这才是发展一个组织产出价值的最佳途径。
所以我认为一个组织是否有发展潜力，最显而易见的是，它内部是否有人投入大量的时间去做开拓性质的工作，另一个不容易看到的是，它内部是否有大量的“教练”在努力提高其他人的技能上限，让组织内的每个人都能在自己感兴趣的领域做出贡献。这两个团队分别对应了科研和教育，虽然我国的科研不是那么好，但幸运的是基础教育做地还算蓝星前茅，前两次基础教育大跃进分别是开国的扫盲和上山下乡，都是大幅提高民众教育水平的政策，虽然这过程损害了很多团队的利益，但对整个组织而言，还算利大于弊。最近的策略上，我比较看好的是针对贫困生的免费师范生政策，长远来看，当教育资源溢出到贫困地区之后，能大幅提高群体的平均受教育水平，从而有更大的基数去选拔出适合做开拓性质工作的科研群体。
就当下的时代而言，很不幸还是资本主义社会占主导，还有太多人必须为了活下去，因为各种原因从事着自己不感兴趣的工作，被迫异化成工作需要的样子。
如果心理上真的长期处于工作使我难过的状态，可以好好想想，真的是生活所迫吗，自己想要的真的是财务自由之后游山玩水式的生活吗。还是说自己根本没有找到兴趣所在，没有找到自己愿意投入一生时间去精进技能的领域？如果自己确实没有能力做开拓性质的工作，又找不到任何能取悦自己的领域，是否愿意转向从事“教练”性质的工作去成就他人呢？
目的不一样，对 wm 的需求也不一样，linux 桌面最大的问题是投入在交互改进的资源明显比不上 osx 、windows 这类的厂商，所以开箱即用和附带的生态体系上，先天就不足。
稍微能拿出手的是定制性和操作交互的准确性，但这个对用户的使用门槛就太高了。
想开箱即用，大多是选择 qt 系还是 gtk 系，enligthenment 是特例它的组件也是自己写的
gnome 系列
kde 系列
Enlightenment
在这些桌面的基础上集成命令行来提高使用效率才是 linux 桌面的正确用法，加上这点才能勉强赶上 osx 的生态，而 windows 在集成上是被吊打的状态
桌面还有另一个异端是分屏和组合键绑定操作，可以达到更高的效率提升，这点上所有平铺式的 wm 都可以做到自定置。
想定制，也可以试试平铺窗口
i3wm
awesomewm
xfce
lxde
xmonad
使用体验上
osx 堪称最佳，手势+分屏+Alfred 已经可以覆盖绝大多数使用场景，略有不足是同一个应用多窗口的切换做不到准确切换，加上分屏切换是堆栈式的，会变换顺序，ctrl 123 和 common tab 混用会打乱分屏的顺序
windows 只能是行业软件最佳，感谢相关生态体系的厂商，和 windows 自己的操作交互并不算好，仅能靠鼠标 + win 123 + ctrl tab 的处理，效率太低了。
linux 下大部分开箱即用都很差，平铺窗口更不用说，但这么差的生态体系下，大多 linux 的应用都喜欢内置一个特性，配置文件+命令行参数。这加起来就可以定制出很多有用的效率组合了。
举个例子，往状态栏增加各种定制的展示图标和快捷入口操作上，linux 下的桌面开发成本是最低的，osx 可以靠 alfred 做到快捷入口，但做不好展示，windows 直接没有这块的支持。
以上，是我使用不同桌面的一点感受，仅供参考。
@
LemonK 有没有资本在面对盈利压力的时候知乎的管理层可能都会做出同样的决策。但在资本的盈利压力催化下，这个转变来得更为突然。
最近两年知乎的一系列操作从侧面佐证了他们整个团队的价值认同已经和用户的价值理念相悖，用户彻底变成流量符号，社区生态也出现割裂了。
资本是如何利用盈利压力绑架产品并杀死产品的，即便知乎如此努力盈利，到现在也没有找到一个合适的盈利模式。
活生生一副失血求生的悲剧，因为没有合适的模式，又拿了过高的资本投资，被迫将产品催熟。
难道知乎不知道疯狂推热门内容，放任各种营销号发布洗稿内容导流到站外，会挤走高产出用户让社区慢性死亡吗。
难道知乎不知道各种内嵌广告，强推各类付费产品，强行降低移动端体验往 app 导流会增加用户跳出率减少用户活跃程度吗。
知乎是知道的，但是他没有退路了
毕竟他也曾为了避免恶意抱团点赞开发过反作弊机器人系统，大幅降权封号维护社区讨论质量
也曾为了维护用户利益，不惜贴钱联合用户起诉站外盗答洗稿的营销号
也曾为了提高社区用户体验努力提高 web 界面的交互易用性，开发各种利于编写答案的编辑器改进
知乎曾经也尽心尽力为用户服务，倾听用户反馈做改进过的
但不幸知乎拿了过高的融资了，他没办法停留在一个以用户价值为中心的社区模式，他需要用户增长，需要提高营收，需要变现满足资本的融资要求。
所以他放下节操了，开始自掘坟墓式往 app 导流，开始放开社区内容审核标准，开始努力证明自己的盈利能力。很不巧这和用户的核心价值是相悖的，所以风评越来越差，不停失血，但又没有找到合适的盈利模式，都沦落到被迫大幅裁员了，下一步就是沦为营销内容的导流基地，空有活跃却无有价值的内容对外输出。
好好想想为什么你们还愿意在 V2EX 停留吧，不就是因为 V2EX 是为数不多还愿意和用户的核心价值站在一起，为了维持讨论质量而努力的社区吗。
至于知乎，为他默哀，中文社区快死绝了，因为我们用户不配拥有好社区。
有专职的人员维护这套基础设施吗？
没有的话，公司愿意为这套基础设施投入人力成本和机器成本吗？
要是都没有，谁来背这套基础设施玩不转的的锅？
做为技术人员，碰到这种新技术能实践，应该感到兴奋才对。选择成本恰当的技术方案应该是架构师头疼的事情，普通开发难道不是恨不得把业界最新方案全用上，好堆简历背景吗。
就是一份数据，数据实体同时记录工作流状态，业务处理的流程同时修改实体对应的数据并提交到数据库。
最直白的工作流描述方式类似这样
状态 1: 响应事件 a,b,c
状态 2: 响应事件 d,e,f
状态 3: 结束
处理的过程无非是，收到对 entity1 发送的事件 x，从数据库中将 entity1 查询出来，进行状态事件表查询，跳转到要执行的业务处理代码，然后服务执行这份代码对 entity1 的数据做处理，处理完后跳转到状态 y 并提交当前 entity1 经过处理后的数据到数据库，等待下一个事件。
接着拆解一下事件的类型：
1.外部服务发送过来的请求
2.其它工作流发送过来的事件
3.延时 /定时触发的事件
可以看出来，需要有不同的协议来适配对应的事件转换：
1.提供服务端对外接口接收外部请求，并转换成事件
2.不做转换
3.提供延时队列服务收发延时任务，并在指定时间发起对应的事件
再看一下收到事件该怎么处理：
1. 根据事件参数中的 entityName, entityID 查出数据
2. 将数据 loaded 到 class 中
3. 调用事件对应的 method，执行对应的业务代码
4. method 之后需要更新下一阶段的状态标识到 class 的字段上
5. 将当前 entity 的所有业务数据连同状态标识一并提交到数据库保存
可以推测一下实现方式：
1.从数据库 load 数据出来
2.使用这份数据去 new 一个 class
3.带着事件参数去 call class.method(params)
4.序列化 class 的数据，提交到数据库
这需要运行的语言支持什么特性？
1. 可以根据字符串类名实例化一个 class
2. 可以根据字符串方法名调用一个 class.method
3. 方便的序列化、反序列化数据，最好是无缝与 json 形式的数据转换
4. 能用简洁的语法描述业务处理
不管原始业务是用什么语言写的，这些业务处理代码都可以在同一套服务进程内运行，因为本质上这就是一个请求-处理-保存数据-返回结果的流程。业务代码与正常的网络请求处理毫无差别。
接着抛开实现细节，以请假审批为例子看看如何使用代码描述一个工作流的处理是易于阅读的。
方式 1
class 请假 {
public 待发起(event, params){
if (event === 发起){添加延时任务通知超时,发出审批通知;next(待审批)}
if (event === 放弃){next(关闭)
}
public 待审批(event, params){
if (event === 同意){更新年假业务数据;next(通过)}
if (event === 超时了){发送超时通知;next(超时)
}
public 超时(event, params){
if (event === 重新发起){修改业务数据;next(待审批)}
if (event === 放弃){更新相关数据;next(关闭)
}
public 通过(event, params){
// 空处理，仅作状态记录，不会再响应其它事件
}
public 关闭(event, params){
// 空处理，仅作状态记录，不会再响应其它事件
}
}
方式 2
class 请假 {
public process(){
待发起:
event = this.event
if (event === 发起) { 更新业务数据;goto 待审批}
if (event === 放弃) {goto 关闭}
待审批:
event = this.event
if (event === 同意) { 更新业务数据;goto 通过}
if (event === 超时了) {goto 超时}
超时:
...
通过:
...
关闭:
...
}
}
@
feather12315 特别新的新手挑几个写好细节设计的文档让他写实现，尽可能调新增业务或者特别简单的 bugfix
带着业务理解 review，我司要求 code review 的目的是为了避免单点，在代码实现的思路上让团队达成一致，至少相关业务开发人员达成一致，review 之后意味着这个模块出了问题，我也可以负责修。这样出了任何问题，review 过的人都可以直接修改代码，而不是推脱这个模块不是我写的，我不需要为此负责。
所以在我司，code review 没有把重点放在语法之类的实现细节上，重点是在代码有没有体现合理的设计思路，代码可读性上。
而且 code review 已经是最后一步了，功夫应该在 code review 之外。
概要设计文档，细节设计文档，都需要有配套的评审，将技术债务尽可能减少。设计文档的评审通常是老带新，老手写概要设计框住业务边界，新手写详细设计明确实现细节，由评审来保证相关人员对业务需求的拆解理解达到一致。
此外就是配套的 CI lint test 等支持，规范代码风格，保证功能满足需求。
实际 review 的时候，会快速看看 test 的覆盖率快速确认对外暴露的调用约定是否合理，边界样例是否覆盖业务需求的要求。其次是看代码结构，可读性如何，再次才是语法细节，有没有不合理的写法，对于不合理的写法通常只有新人的前几个 PR 高标准评审，甚至可能有一个新人三四个老人评审的情况。
这么带几轮下来，大部分团队成员的代码风格和业务拆解都接近一致，基本上出问题都可以让一个人一杆子捅到底层实现去定位和修复。如果发现是代码分层和架构满足不了新增需求可能还有重构的情况。
享受到的收益是：
test 是以业务边界为要求写的，不用担心重构的影响范围过大。
底层模块业务稳定，容易交接，新人上手阅读代码和改代码的成本低。
这么做的问题是，功能迭代速度太慢，一个业务需求从设计到实现拖的周期会很长。还会有不少时间放在重构偿还技术债上。
这种模式只适合核心业务，对于开发周期急迫的任务并不太适合。
永远保持用自动化工具解决问题的思维方式，不管是用软件还是自己写代码造工具，不要让自己在重复的事情上浪费太多时间
保证新特性的 迁移成本+使用成本 < 旧特性的使用成本 是推进改进的最佳方式，而自动化工具是最小化迁移成本的唯一途径
工作习惯好的程序员善于使用脚本自动化自己的重复性工作
验证性业务的脚本，本地提交代码的预处理，业务代码的测试用例，登录堡垒机的脚本，更新工作任务状态的脚本，随手启动一个 mock 接口的 http server，都是很适合用脚本解决的问题
问题是如何满足频繁变更的报表需求。
成本最低的方案其实是用专门的报表基础设施解决这几个问题：
1. 报表计算逻辑的声明
2. 报表同步数据
自己另起服务定制写统计是成本最高的方案，不管你是 rpc 还是定制写计算逻辑。
两个业务其实可以通过数据库解耦。
不管你有多少业务项目：A1 、A2 、A3……
业务项目只负责自己的业务数据读写的约束。
报表业务应该只关注数据库的数据是什么样，如何通过数据库的数据计算出需要的报表，clickhouse 、tableau 、superset 这类开箱即用的报表解决方案不是更合适吗。
做为一个去过较多省份的吃货，我发现的规律是。
城市化+高房租+生活压力大 = 美食荒漠
北京存在这几个缺点
超大城市化意味着大部分食材是标准化的，平民能吃到的也只是标准化的冷鲜食材
高昂的房租意味着不存在低廉的人工，食材加工偏向流水线作业
生活压力过大意味着生活节奏快，大部分人没有时间用钱给好的菜品投票，饭店也没有动力改进，大幅拉低平均菜品质量
卫生文明城市整治，绝杀小摊小贩
北京唯一的特例是有历史积淀，但传统小吃难吃。即便算上驻京办，整体水平也不如其它省会
好吃的城市至少以下特征的一个
历史积淀，存在老城区或城中村，间接保留很多老店，尤其是自有房产的老店，本地菜品的顶梁柱
生活节奏慢，大部分人有时间给好的饭店投票，愿意为好吃的饭店付出等待时间
城区不算大，本地食材到饭桌的周期短，能提供大量新鲜食材，本地人也愿意为好食材付出成本
早餐或夜生活丰富，尤其有夜宵
以上北京除了历史积淀，一个都没沾上，另一个类似的美食荒漠省会是石家庄，同样难吃的饭店居多。
就我吃过的城市而言
第一档是广州及周边佛山顺德等
第二档是西安、南京、乐山、昆明、瑞丽、扬州、泉州
其它的有哈尔滨、成都、武汉、福州、重庆、天津、腾冲、保定、惠州、保山
其它城市不是说没有好吃的，就是太少找的费劲。
如何发掘兴趣方向，培养出有自学能力的孩子才是最费心力的。
有太多人填鸭式的教育把孩子的兴趣爱好都遮盖了，即使现在资讯那么发达了，依然有很多人高考之后还不知道自己对什么感兴趣，也不知道什么值得自己投入精力去奋斗，服从调剂去了一个自己未必感兴趣的专业，毕业之后随大流找一份对口的工作，或者为了生活选择一个热门的领域工作。
孩子感兴趣，从学习中获得正反馈，家庭有条件提供相应的助力，才是合理的教育模式。
我更认可自驱力更强的竞赛式教育方式，能够在中学阶段就找到自己真正感兴趣的领域，并投入自己的精力超前学习相关领域的知识，从中锻炼培养出属于自己的一套研究、学习的方法，这才是受益终身的能力。
考察一下 pulsar 这类的支持订阅多个主体、支持权限的 MQ ？
大部分保险销售员其实是保险公司的客户。
套路无非是卖得出去你就是员工，卖不出去就底薪。
普通人没能力签单，那就先给自己买，保险那么好，不给自己量身定制一套，怎么能更好的销售给别人。
过了几个月还没有成单，不如考虑一下给家人、朋友推荐，你那么熟悉业务，推荐给家人、朋友两全其美。
最后家人收割完，实在没有成单，能招聘新人进来也算业绩。
要是没有成单又没有招聘。过了新人期，也就可以开除掉了。
要是做保险能坚持不给家人、朋友推荐，还能熬过新人期，我就敬你是个英雄。
Select Language