同类岗位在不同公司的职责范围都会有些区别，不只是 DBA 。

比如我们公司就没有 DBA ，开发人员负责设计和调优数据库语句，安全负责人负责审核，运维负责执行。

去网上搜 net::ERR_NAME_NOT_RESOLVED

光看这个错误代码显然是 DNS 解析问题，可能你请求的 URL 有问题，域名没法正常解析，也有可能是你配置的 DNS 服务器有问题。

这种事情需要团队达成共识的，是否可以有彩蛋，以及需要遵循基本的原则是什么，不推荐没经过团队同意在团队的代码里做彩蛋。

代码是公司的，代码甚至产品功能上可以有哪些彩蛋应该是公司决策，比如很多游戏里埋的彩蛋其实都是有公司方面的授意的。

仅在非代码（比如注释、内部文档）的地方做彩蛋，影响至少不会传递给客户，但也要考虑是否会让其他阅读的人产生困扰，比如思路被打断，或者产生误解。

前后端通用的包不少比如 Lodash 、Axios 、Bluebird ，另外因为语言绝大部分特性一样，所以自己写的很多代码可以前后端复用，比如涉及到 API 的各种类。

你熟悉啥，用啥出活就快。

每个技术栈都有擅长的领域和不擅长的领域，看你当前遇到的需求或问题是否是某一个技术栈擅长的，比如涉及到大量 JSON 处理的场景，后端 Node.js 就肯定比 PHP 方便一些，以及 Node.js 的异步非阻塞是开箱即用的，不需要很多工作就能支持高并发。

对于公司来说，Node.js 全栈的优势是一门语言通吃前后端，前后端交集的那一部分不需要重新学，很多设计思想也可以通用。

但任何一个规模较大的项目都不是一门语言可以拿下的，需要用多个技术栈各自发挥特长。

所以你现在熟悉 PHP ，在没有实际遇到不适合 PHP 的需求的时候，好像也没必要硬换技术栈。

@BuErMr #18 看书看博客，有一些技术资讯的网站会经常有各种大牛发文章分享案例。

循序渐进的思路是对的，做原型就什么顺手用什么就好，项目隔一段时间重构一次是正常的，每段时期都会有新的需求局态，根据需求再确定是否要变更选型就好，新技术可以上手做做实验，验证是否符合当下的需求，不符合也没必要硬上，对于还在炒作期的技术还是谨慎些吧，玩玩可以。

微服务其实是拿管理维护成本来换开发运营成本，所以虽然开发运营会比较爽，但还需要考虑服务治理问题，使用服务治理中间件和混沌工程来解决各种微服务特有的问题。

公司里有个微服务拆分的评判标准，就是如果一个微服务尚不具备复用的需要，就不拆，但代码上确保随时可拆，项目服务可以以单服务运行，各个功能模块可以作为逻辑上的微服务工作，像微服务 API 之类的走微服务的实施标准，这样也可以享受一些微服务的好处，又不至于过早面临服务治理问题。

我现在就是中文搜索用必应，英文搜索采用 Google ，政务搜索用百度。

必应怎么说也是正经在国内有搜索业务的，一方面比 Google 更重视国内市场，另一方面比 Google 有更多国内资源。

但确实直观感受，Google 的老牌核心业务的质量在逐年下降，可能他们不进则退了。

用过 Nexus 、Pixel 之后就一直用三星，想支持国产品牌，但广告一直是一个自己无法接受的问题，即便可以关掉。

以前国内消费者是低价为王，所以保证性能压低价格的小米能闯出一片天，但企业不能做赔本买卖，于是就从设备价格转移利润到了广告业务上，这在当时的国内市场是比较合理的策略。
但如今消费水平提高了，价格差距不再痛痒，越来越多的人不再以性价比为首要考虑标准，转而越来越看重使用体验，以前的那种盈利模式可能会逐渐被市场淘汰了。

现在看来，有些手机厂商已经很久没有探索新的 S 曲线了。

@CHEN1016 #5 官方为了推商业服务，基本要废弃 docker-machine 了，不过这个思路是没问题的，都是在虚拟机里跑 linux+docker ，然后在本地远程调用，用 vagrant 也只是把这个过程自动化了。

Docker 的 Windows 和 MacOS 的 Desktop 版本客户端做得很烂，而且夹带不少商业私货，我目前的方案是用 docker-machine 方案，在虚拟机里跑一个精简的 linux ，然后配置 DOCKER_HOST 环境变量使用 linux 里的 Docker daemon 。

@yazoox #82 JS 虽然借助一些引擎能具有很不错的性能了，但保不齐有一些对性能要求极其苛刻的场景，比如专有格式的视频解码，用 JS 写个视频解码器怕不是只能放 PPT ，那么你可以用 C++、Rust 等语言，按照 WebAssembly 标准来写，然后编译成 WebAssembly 字节码的 js 文件，在页面上引入这个 js 文件，然后就可以用原生 JS 来调用解码器对视频进行解码了，性能能做到跟 C++、Rust 编译成的桌面版本软件差不多。

感兴趣可以直接去 MDN 上看相关介绍，https://developer.mozilla.org/zh-CN/docs/WebAssembly

第一阶段：多了解案例，看看其他人、其他行业、其他技术栈都遇到过什么问题，如何解决的；
第二阶段：提炼思路，思考各个问题的本质是什么，而解决方案的思路是什么；
第三阶段：迁移思路，思考一个领域的思路是否可以被用于解决另一个领域相同本质的问题；
第四阶段：创造思路，思考有没有比常见思路更加好的思路来解决问题。

一方面单元测试只是一种手段，有没有必要还是得看你们工作痛点是什么；
另一方面任何方法想要发挥最大效用就得按照核心思想来做，应付的话相当于没用。

比较牛□的是，jQuery 几乎所有功能都能在新的原生 Web API 里找到替代方案，可以去了解一下 You Might Not Need jQuery 。

还不算完，WebWorkers 可以实现一些多线程工作了，以及用 Rust 写 WebAssembly 可以把性能坑也给填了。
另外 WebComponents 有大一统框架组件方案的趋势。

喜欢 Flex 布局可以去了解一下 Bulma 。

这个每个人三观差异，可能答案不一样。

我个人的看法是：
如果你觉得你自己某些方面不够好，那么就去改变；
如果你觉得自己某些方面还不错，那就找个也觉得这些方面不错的人。

有两年没在北京租房了，之前的经验是想省心就自如一把梭，需要稍微讲价格就找链家，需要极致省钱就自己到各个小区找房东直租。

1. 合同仔细看一遍；
2. 付房租不要贪便宜走变相借贷的方式，具体去了解一下蛋壳公寓“暴雷”事件；
3. 如果不是从可靠平台租的话，要验证房东和中介的真实性，比如要看房东的身份证和产权证，以及要看中介的房东委托合同；
4. 不管从什么渠道租，只要有人租就一年一涨价，直到价格高到租不出去了再降价，除非房东不在乎或极个别确实不好出租的房子；
5. 水和电是商用还是民用，取暖费、物业费、网络费包不包；
6. 合同上写清楚，什么情况下租客停止合约不属于违约；
7. 房东可能违约，尽可能在合同上落实房东违约的赔偿。

木头和竹子的菜板通常需要护理，不护理就可能会干裂或发霉，如果一天三顿做一家人的饭可以考虑，做饭频率很低的话就显得麻烦又不实用了。

现在家里主要用的是塑料的，除此之外有个竹子的备用。
塑料的只要挑质量好的、不特意刮一般不会掉渣，即便掉一点点基本也只是原样肠道走一圈。

其实不光前端有这个问题，这个问题后端、应用开发领域也都存在，比如有的人写个简单的表单接口都要搞一套 PO 、VO 、DTO 、DAO……

这十年来发生了很多变化：
首先 Web 技术出现了 HTML5 、CSS3 、ES6 、Node.js ，让 Web 应用有了向更广和更深发展的能力；
有能力就能做些以前想做又做不了的事情，于是随后发生了 Web2.0 到 Web3.0 的变化，人们对前端的需求不只是一个展示内容的页面，而是重视交互和用户体验，同时出现了手机、平板等多种屏幕，以及多种操控方式，更使得前端需求呈爆炸式增长；
需求爆发的同时，还面临着日渐加剧的规模化、生产线化的问题，这才导致了各种框架、工具的出现，目的是为了提高产能、降低成本。


技术选型和架构设计是一门学问，得按照需求选择预期需求下最适合的方案。

工具是用来解决问题的，不是用来制造问题的；你觉得恶心是因为你当前的项目对工具没有需求，没需求就没必要硬用，用俗话来说杀鸡焉用牛刀。

现在前端 Web API 相比 10 年前已经增加了超多特性，不需要借助任何库和框架也能比较方便写一些稍复杂一些的页面了。现在做一个项目的时候，只要需求尚不明确到需要使用框架，基本都会用原生 API 写，顶多为了兼容加个 Babel ，后续有复杂需求导致原生手写麻烦了，再迁移到框架。