订一张，谢谢

保修要换回原厂条的吧

心态不合适

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

@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 的路过

@falcon05 真的…口袋是第一个接触的有存档功能的游戏，这样玩了好几个月以后发现怎么存档的时候简直感动😂

我觉得面试过程中 hr 起的作用上限非常低，即使 hr 好上天，也不会成为我看一家公司的关键因素，所以可能还是注意不犯错误为主（打比方的话 hr 的得分范围可能是负一百到正十，别的面试官尤其是 leader、老板可能是负一百到正一百）

所以我觉得不如着手面试官培训，面试流程标准化和优化？因为真的非常多负责面试的人并没有关于人力资源方面的系统了解和思考，一般大家聊的也都是去面试的经验而不是做面试官的经验

@tachikomachann 我玩日文版的时候都不知道这个游戏可以存档的，不如说不知道游戏存档这个概念，一直在玩出门到小刚小霞

@0xABCD 要干掉的功能不是独立一个分支？的话没救了只能手动

独立的话，revert merge commit 一个应该就好了吧
就算不行，也可以这样手动生成：
1. 在 master 分支被合并之前的最新分支记个 branch 叫 tmp （或者 copy 下 hash 也可以）
2. checkout 不要的那个 feature branch，rebase 到 tmp，用 squash 压缩成一个，过程要解决的冲突应该和 merge 是一样的，原样解决
3. revert 刚刚 rebase 形成的一个 commit
4. 你应该还在 feature branch，checkout 最新 master，Cherry pick 你在 feature branch 刚才 revert 形成的 commit

不管我的做法对不对或者你看没看懂，劝你不要改变已经被 push 的历史，除非你和你的团队所有人都明白这里面的道理

你把 master 搞定以后别的分支 merge master 不就好了

用伪代码写的话是
declaration-binding.func = new function({ [[call]]() { execute code } })

你的理解里的这个大 F 是哪里冒出来的？
令 func 为一个 function，其[[call]]内部方法启动（相应）代码的执行过程

这更多是一个中学英语的问题