之前 iOS 版本不给麦克风权限就退程序的时候换成百度了。
虽然不喜欢百度这公司，不过高德地图这行为实在是太恶心。

排队这事虽说也是怀旧体验的一部分，但很多人还是受不了。再说现在也是月卡，有的只要排上了就直接弄个挂机宏根本不下线，公会很多人都这么干。

- 简单的说就是你得设计一个算法，将这 40 亿的数字唯一映射到 40 亿 bit 上。
- 也就是一个特化过的无冲突 hash 算法，给每个数字分配了一个 index。
- 实际上你这个算法在做的就是压缩数据
- 本质上是你先把数据集合做一遍压缩，并且把你的目标数据也压缩一下，然后在压缩过的数据集合里找你这个目标数据。
然而这个压缩过程必须是无损的，否则会有概率误判。除非你的数据集合特征非常良好，不然设计不出来无损压缩算法，也就没办法真正准确判断是否存在。
但是，你既然都能无损压缩了，最开始为啥非得存储这没压缩过的原始数据来着？一般来说这种情况下存储原始数据无非是用空间换时间，可你也根本没换出来。
这种东西看看扩展一下思路就可以了，多数都跟国内数学教材一样，为了解释一个概念编造几道例题。但这些例题都是特化过的，没必要纠结它们究竟有用没用。

预设好的问题总会有刷题的，最好的办法就是你自己去学。
比如你主招后端，就自己去学学。遇到问题记下来，推人可以简单问问。
能给小白讲清楚技术问题还是很考验功底的。

然后等你自己学成了，记得好工作给自己留着。

今年年景不好，未来几年都不会好到哪去，最好做好心理准备。
实在不行就继续回去读书吧

主要还是你热身不够导致的。
你先去买本解剖教科书，或者 App。看一下肩部关节和韧带。你会发现其实肩部运动说的是一大套好几个关节的联合运动。单说盂肱关节的话，运动角度有限，你的关节弹响很可能也发生在这里。一般来说现代人很少做肩关节上举的动作，长时间只在有限范围内活动，关节滑液分泌的也不够，很容易发生各种问题。特别是你去健身的时候不注意热身，这个关节就更容易出问题了。
建议你继续去做运动，但在练肩的时候多注意热身。练肩袖肌群的动作，在轻负重多做几组。等到感觉肩部活动开了，弹响情况减少，同时也不疼的时候再正式开始训练。我是在做侧平举类动作的时候左肩就会疼，但一般先做半小时徒手，或者 3kg 哑铃的肩袖练习以后，关节滑液多了就没问题了。
我一般常用的动作有两个，一个是侧平举，肘关节 90 度和大臂成 L 形，然后以大臂为轴旋转。实际上就是招财猫那个动作，但是下放的时候不要放的太深，小臂垂直地面就不太好了。
另外一个是大臂下垂的 L，小臂外展。同样角度要你自己适应，不要太大。
你自己去找肩袖练习动作也可以，一般我都用这些动作热身。但是重量和次数一定要掌握好，切记你做这些动作只是为了热身，肩袖肌群疲劳会很影响你做肩部动作的稳定性，容易受伤。另外推胸动作对肩部的压力也很大，练的时候注意角度。

外企，一般来说四级过就可以，六级过了也行，五百六百那种高分优先考虑。四六级口语没用。
然后就是电话面试的时候考察口语，不过就免谈。
当然四六级成绩都不写的简历就筛出去了，电话面试都不会有。

@daijinming 你自己试一下不就完了，这玩意是自带的功能，第一级菜单就是
本地服务器
所有服务器
你还问我能不能监控多台服务器？

最简单的就是自带的那个 Server Manager 了吧。
Prometheus 也支持 Windows。

Gitflow 实际应用的时候还是直接用集成的解决方案比较好，虽说单纯用 Git 也能做，但是比较麻烦。
目前个人体验比较好的就是 Jira+Bitbucket，在 issue 上可以一键开 branch，source tree 弄下来就能开发，后续的 MR，Review 也很方便。
Gitlab 也有这功能，但是它自带的 issue 管理比较弱。如果觉得够用的话也可以试试。

飞利浦是旋转式，不太适合比较浓密粗硬的胡子
博朗和松下都是往复式，刮的比较干净，但不如旋转式刀头用着舒服。
这几种电动的直接买旗舰款就可以了。
最舒服方便快捷的就是手动，吉列锋隐加妮维雅的剃须泡先买来试试，习惯以后可以买兼容的刀架，有木质手工的。

devops 这东西是纯坑，跟当年的全栈差不多。你既要懂一些开发，会写代码，明白项目需求，构建测试流程；还得有办法修好那些乱七八糟的网络系统问题。搞到最后你就是给整个团队擦屁股的人。开发完不成功能找你帮忙写代码做需求，哪天服务器崩了你得 7x24 滚回来修。
就算是 k8s，照着文档跑一套起来很容易，但是你作为运维，这东西崩了你得有办法修好。这就不仅仅是 k8s 本身的问题了，操作系统，网络基础积累不够你可能都不知道哪里坏了。

个人意见，你如果有心学习不管是前端开发还是运维，都能学到不少。计算机相关的所有技术都不是凭空造出来的，就算是前端开发，MVVM，工程化等等实践也全部都是几年十几年前就做过的东西了。你可以对比一下这些概念在这十几二十年里面有什么发展，多深入了解总结一下就能有不少收获。更不说浏览器本身就是一个极其复杂的项目，布局渲染 v8 都够你好好学习的了，不存在什么“应用层比较靠上”的问题。

写大文件可以 File Mapping，很容易。
但是不建议做成 CSV，这东西不是一个非常标准的规范，总有各种各样的问题。
如果你导出的数据只是内部使用，可以直接导出到 Sqlite 或者 Access 数据库。
这种的 Excel 也能直接用

大多数软件开发的技术并不值钱。
虽说开发健壮稳定可扩展的软件对技术要求很高，但很多时候企业考虑的是如何活下来。你可以说花时间做一个特别牛逼的系统，可还没做出来公司就拖倒闭了，这种系统半毛钱价值都没有。
做技术的总有一种错觉，以为技术可以解决一切问题，技术牛逼了什么都有了。但对于大多数公司来说，销售才是核心竞争力。你东西做的再好，卖不出去也是垃圾。
毕竟大多数公司造的又不是火箭，大多数 IT 的技术也不是除了你以外别人做不出来的东西。

@dcoder 性能问题只要你做聚合就都会有的，用不用 GraphQL 都一样，也不用期待 GraphQL 能解决本应该用其它方法解决的问题。
其实自己做一个聚合查询的接口也可以，但要自己设计 API，Parser，配套的辅助工具，再给前端后端讲清楚接口。
GraphQL 实际上做的就是这些事，省了你自己设计这 API 的时间。基本上是和 Swagger 类似的地位，也没人指望 Swagger 能解决端口的性能问题吧。

Type C 的 PD 协议分好多种，想要达到最高的充电效率，你的线材，充电头必须的全部达到标准才行。
你用的充电头功率不够，或者线材比较劣质，哪怕你的设备支持更高等级的标准实际使用的时候也会降级。笔记本的话会插着电源使用也一直掉电，或者干脆充不进去。
你买个 65w 的充电头，支持 5A 的线材，足以应付绝大多数使用 Type C 的设备了，不管是笔记本手机还是 Switch。

不管是什么技术，总有个适用范围。没什么东西是万能的。
GraphQL 的语法也好，ElasticSearch 的 Query 语法也好，SQL 也好，本质上都是一个用来 Query 较复杂结构的 DSL。你如果把整套 Graph QL 抽象为接口，那么你认为你是在前端写 SQL 也没有问题。
但 GraphQL 主要是用来解决 API 设计问题的，至于怎么优化查询并不是它的重点。SQL 本质上也是一样，这种语言是设计用来查询关系型数据的，怎么优化是 DBMS 的事。
REST 接口实现简单，也没什么复杂的心智负担。但如果你需要做成 REST 的东西比较多的话，前端免不了做一堆的 Promise 来回的查。而且这种多次查询后台也没法做优化。
你给每个需求写个 API 可以做到细致的优化，但是前后端很难同时开始工作，你得先定好接口，Mock，或者上 Swagger。而且这种写法扩展性有限，新增需求很多时候你就得新弄个 API。
GraphQL 和 ElasticSearch 的 Query 比较类似，优点不在于优化性能，而在于更大程度上去释放系统的可扩展性。比如你要做个类似 Kibana 的工具，绘制的图像各个轴可以自定义 model 和 field，但不涉及特别复杂的计算聚合和优化。那么类似的东西就是最好的选择。
真正使用的时候还是要根据自己项目的特点去选择合适的技术，不是看什么新就用什么。GraphQL 也有一大堆的缺点，但是你的需求如果可以正好避开这些缺点，同时它擅长的东西也是你想要的，那么没什么理由不用它。