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

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

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

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

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

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

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

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

usb3 干扰蓝牙？

不都不会说不坑你坑谁

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

订一张，谢谢

保修要换回原厂条的吧

心态不合适

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

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

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

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

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

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

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

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

calendar event 是可能和别人共享（会议），可能由别人代为管理（秘书），可能公开给别人的（忙碌状态）
gtd task 主要还是个人管理

至于提醒，那是各自软件的功能和这两者是正交的。这两个是都能设时间提醒，闹钟也能提醒，微信语音提醒也能提醒，slack 可以设一条聊天消息的提醒，印象笔记也能提醒。如果你的需求只有提醒这一条，别的都无所谓，那么任何一种都能用对不对，但如果你的需求更专业，那么就应该用更专业的工具。我的理解是 gtd 偏个人偏事情，可以拆分，拖延，分类等等，而 calendar 偏团队偏时间，我和客户约会时间是否和其他事情冲突，我的同事明天上午是请假、外勤、开会，还是普通上班

@via yaml parser 实现的不好其实不也还是标准太复杂了所以不容易做好么…

@buildblock 知道优缺点才能更好的作出选择，开发快只是一点，可维护性，复杂性还有安全性都应该纳入选择的考量范围

@zhengxiaowai 我同意注释对于配置来说是必须的，因此 JSON 做配置并不明智，但这并不代表这就能成为选择 YAML 的理由，因为市面上常见的配置文件方案里，基本只有 JSON 不支持注释

基本赞同楼主

很多人会说关系好就能聊具体数字，对不起，对我来说，只要是一家公司同事，就是绝对不聊数字，目前我还没有碰到过主动告诉我他的薪资（然后再要求我说之类的）的同事，如果有我一定会躲得远远的，甚至会考虑如实反映给老板

知道别人的薪资对任何人都没有好处，如果你觉得薪水拿少了，公司的薪资结构不合理，你可以出去找机会和／或找老板聊，而不是打听别人拿多少。你还能打听到买彩票中奖的折合月薪一百万呢

有些人在这方面受害妄想严重到我觉得需要心理咨询的程度了。公司的同事也好老板也好 HR 也好，大家的目标应该是一致的（把公司做好），如果你这点信任都做不到，就不该入职，如果你原来信任后来因故不信任了，那应该尝试修复这种信任先，或者修复不了那就找下家。

反正我是没法忍受和我不信任的公司／领导合作的，也忍受不了和满腔负能量的，整体怨天尤人又不做实际行动改善自己处境的人聊天做朋友

1. 开源社区和商业公司的博弈和平衡你也许是没有看到，也许是刻意忽略，即使是大公司，做商业开源并不像你描述的那么容易，没有社区生态那不叫开源，只能说是源代码可下载

2. 不赞同开源难学，即使是特别大型特别困难的项目，开源也一定时降低了学习难度的，从头写难度是 100，有个混乱的开源项目难度也许是 95，有个良好的开源项目难点也许是 70，但如果你只有 5 的实力，可能连这个项目风格好不好，适不适合学习都判断不对

3. 我觉得如果你是真心觉得开源难学难参与，还想自己玩网络协议，那我觉得你可能是学的太少想的太多

正在从 Python2 转型 istio 的路过