多年 apex 用户，之前买了份 Nova 用了一段时间感觉不行还是换回去了

Apex 大改以后有些问题，现在是 Lawnchair 用户，等 apex 修 bug

我是这样看开源的，点开 github 上的 contribution 图表

最好的开源: 第一页的作者都有持续贡献，top contributor 的贡献比例不太大，且这些作者互相的来源地区公司各不相同
其次的：有两三个来源不同的主要贡献者
有风险的：几乎全是 top contributor 的贡献，但这个人还是接受 pr 的，和社区有良好互动

假开源：单个 top contributor 和社区没有有效互动
假开源 type2：虽然有很多持续 contributor，但他们都是同一家公司

阿里的开源项目我没看过几个，不做评论

所以你先练练书面的吧，看看你自己写出来的总结：思维跳跃，脑筋转太慢？？

画画脑图，整理清楚事实、知识、观点、经验等等的关系，写都写不清楚谈何讲的清楚。还有就是是不是真的熟悉了，讲不清楚做的出来的“熟悉”比能讲的清楚的“熟悉”是差一个级别的

中指食指轮流，轻触单击，三指拖放，每天十小时上下几年了，没有茧或者不适

安排两周一周做完和安排一周两周做完都不够好，都需要改进排期的能力，但也都是正常情况

至于工作压力么，其实和排期类似都是和老板沟通清楚就好了，沟通完无法达成一致么就和平分手

放弃沟通不给反馈的情况下老板选择啊一直压你也很正常，他的工作就是发挥每个成员最大的能力

不知道为什么这类帖子里就都是这种阶级斗争的画风，成天和公司和老板勾心斗角不累么，不觉得毫无成就感么？工作虽然只是工作，但为什么不去争取和公司和老板站在同样的立场往同样的目标努力？他知道你和他心是齐的，自然而然和你就是一伙人，请假方便也好大姨夫来了不想干活也好就都是次要问题。而他搞不清楚你在想啥，那怎么管理你就不好说了，你没法指望你的每个领导都是非常擅长管理的领导

搞不定外包就去搞定给外包开工资的人

私钥“加密”，公钥“解密”的过程一般就叫做“签名”，“验签”，目的是证明信息是我发的
“加密”一般是指保护信息不让别人看，应该是公钥加密，私钥解密

题目里的说法，前后两半部分是一回事，后半部分一般不那么说

至于性能问题，对于签名的场景，一般是用信息摘要（也就是哈希）作为签名的信息，而对于加密的场景，一般是用不对称算法（也就是公钥私钥）来保护对称算法的协商过程（也就是双方协商用什么对称算法，并随机生成临时的密钥，并定时轮换等），用对称算法保护实际内容

@ymyqwe 理想肯定是不需要领导自己找性价比高的事情自己安排啦，实际么，看团队成员实际情况咯，有方向也找不对的，有没计划的，有没产出的，也有摸鱼划水的，管理者的工作不就是确保团队往前跑么

把不确定的优化、调研变成确定性的任务，也许不那么浪漫，但对于公司和管理来说肯定是必要的

其实也没有那么难啊，就是拍一下范围，预计时间（避免低效／拖延），产出（你觉得定不出产出的，八成可以定成技术分享完事儿），可能失败的定一下止损（比如你去看性能监控可能发现全是大炮不适合当前项目，那也有个止损方案就是先不做）

公司不是学校，自己业余学肯定是好的，但你作为 leader 安排上班时间学，肯定得有明确的计划，学习有帮助，计划和产出是确保这个帮助落地的手段而已

usb3 干扰蓝牙？

不都不会说不坑你坑谁

我觉得“举全人类之力”这事情本身的难度是超过永生和时间旅行的，别说全人类了，你先试试举全小区之力？

订一张，谢谢

保修要换回原厂条的吧

心态不合适

建议花点时间在职业规划上，尤其是你觉得上一份工作经历并不成功的情况下

@Attan 锻炼的是不一样方向的技术，你可以认为是程序员的不同细分工种

如果你认为中间件技术比业务线厉害，我认为这基本上是误解，类似于觉得做底层的更厉害，做驱动的更更厉害，做操作系统的更更更厉害，所以画电路板的无敌了

设计模式最大的问题就是糟粕（或者说应对主流语言糟粕的方案）和精华混在一起，让大口吃下去的人中毒

在我看来，这种（用一门技术就应该以使用全部特性为荣）的前设就是最大的糟粕。如果你的工程就是缺个类型检查器，那么就把 ts 当类型检查器用就最好，不要去试图解决不存在的问题

利益相关： 业余前端，只在 jQuery 时代用过版本号非常小的 ts

业务需求天天变你都能用日复一日形容了，不建议去做中间件，那个需求几个月也不一定变一次，年复一年了

英语过关的话，外企直接投简历啊
甚至不那么要求英语的外企也是有的