如果初创公司，氛围比较开放自由的话，可以和领导商量一下。

不过一般公司都是批量采购，不好为你单独采购一个型号。
为了效率和健康可以不和公司计较，只要公司允许使用私人设备，就可以放弃公司的，用自己的。

当然要小心叫 Trace 的 HR。

一定要提前看好哪些设施开放，哪些不开放，最好赶开放设施多的时候去。

可以提前下他们的 App，有地图，也有一些互动的功能（比如购买自己游玩的时候被自动拍下来的照片）。

前一天可以住在附近几个地铁站的 AirBnb （或者有钱住迪士尼的四星级和五星级也行），如果怕赶地铁人多可以提前买好日票，第一次刷才开始计时。
早晨开门前早点去，占个好位置，到点开放马上跑（对，一定要研究好路线死命跑）去领 FastPass，领 FP 是在各个项目的入口附近，地图上有。

提前规划好 FastPass，比如一开门马上跑去领热门项目的 FastPass，首推飞跃地平线和 Tron。
领完 FastPass 马上去不是最热门但也不错的项目直接排队进，比如加勒比海盗。
这样可以差不多保证一天不需要排多长时间的队就可以玩到尽可能多的项目。

网红大鸡腿有营业时间，可能也限量，最好尽早去排队买。

花车游街上午一次，下午一次，算好时间，入门拿的地图上有游街路线，提前去沿线找个好位置等着。

玩 Tron 需要寄存包，但是有 FP 没法寄存，所以可以在门口附近找个寄存点先寄存包，再去。

晚上的烟火表演，要提前看好有没有，平安夜有特殊节目。

里面有接饮用水的地方，可以带杯子去，零食不是完全不能带，我记得是必须是包装完好的品牌零食。

项目特别多，有游乐项目，也有表演，一天肯定不够。

请问社保方面是怎么处理的呢？

JavaEE 的时代有很多单实例大型系统，但是五年前就开始兴起的微服务让“大型系统”式的设计没那么必要了，每一个微服务只需要考虑自己专注的这一小块就可以了，所以，服务端用什么语言真的没啥大关系，而且选什么技术栈完全看各个技术栈在当前需求场景下的综合 ROI，不是说觉得某一门语言好就从头到脚全用这一门语言。

不过现在 The hype cycle 的峰值被舆论大幅拉升，以及很多人面向简历编程，Java 最终没落肯定不是因为自己不够好，而是因为无力逆转潮流。

树莓派官方已经发布 Buster 的 Raspbian 了。

公司机器上跑的东西不依赖机器环境，所以这么多年也没所谓用什么发行版，偶尔想用用新版的 OpenSSL 会编译一个。

个人还是在用 Arch ……

https://micro-frontends.org/
你要的前端微服务来了，这货在 GitHub Trending 上还挺靠前的。

系统架构思想其实是独立于和语言、技术栈、框架的，所以只要脑洞够大，没准一些“后端思想”也是可以直接在前端项目中使用的。

数据模型大部分为关系模型就用关系型数据库，数据模型大部分为文档型就用文档型数据库，现在大型业务都不是在一个服务上独立做的，涉及到事务也是平台级别的事务，所以按照数据操作的最小粒度来将不同模式的数据模型拆开，可能是比较好的方式。

像学校、老师、班级、学生这种模型就是典型的关系模型，最好使用关系型数据库；学生学习记录会包含学生、课程等当时的状态快照，所以适合使用文档型数据库；然后在平台级别学生和学生学习记录之间又是关系模型。

又比如正常的业务逻辑使用常用的关系型数据库，涉及到搜索的部分用特殊的数据库（数据存储、搜索引擎方案） Elasticsearch。有的公司是同一份数据同时存在多种数据库里，增加了保障一致性的复杂度，获得了最佳综合性能。

听说过一句话：“柠檬羡慕猕猴桃的甜，猕猴桃羡慕柠檬的酸。”

后端大多数也都是 CRUD 操作，很多人做了 5 年开发架构问题都是靠框架解决的，有机会且有能力解决高难技术问题的毕竟还是一小部分人。

个人觉得这个和自己的眼界与职业规划是有关系的，前端虽然不大会涉及到分布式、微服务等技术，但也有前端自己特有的同样看起来很“高端”的技术，比如 Webassembly、Web Components、Web Workers、Web GPU
、响应式布局、SPA、PWA 等等，而且前端工作的成果通常是肉眼可见，而且能直接对用户产生影响的，前端还会涉及到一部分 UE 的技能，比如 Contrast Ratio。

作为技术人员如果能了解到不同技术栈的知识，对于提升解决问题的能力是非常有帮助的，所以对后端好奇的话不如学一学后端知识，Native 开发、大数据、AI 都可以看一看。

自己学一学，花不了多长时间，然后就能对 Node.js 有一个大概的了解了。

前端用 JS，服务端 Node.js 用 JS，用 MongoDB 的话数据库也是用 JS，手机端可以用 React Native 是用 JS，PC 端可以用 Election 也是 JS。然后在创业公司爆炸增长的时代，业务量没那么大，每一个岗位雇佣专人成本较高，所以出现了“全栈”岗位，一人 JS 一门语言搞定所有岗位。

浏览器前端开发人员是一个非常大的群体，这个群体所有人都能熟练使用 JS，所以学习 Node.js 很快，Node.js 是靠着 JS 技术栈爆炸式增长起来的，TS 也是靠着 JS 增长的。

现代的前端开发都是使用各种复杂框架，很多都有独立的语言特性、文件结构，需要使用基于 Node.js 的大量工具进行编译和处理，即便不在后端技术使用 Node.js ，Node.js 已经是 Web 开发必不可少的工具平台了。

技术方面有一个“ The Hype Cycle ”的概念，不用盲从舆论，亲身了解和体验，在适当的地方使用最适合的技术栈就可以了。

国产应用流氓，所以中国市场上的所有安卓系统全部都自带杀后台功能，这个不是说系统本身就这样，而是被中国的应用生态逼出来的，以前用 Google 亲儿子的时候没有杀后台功能，所以用国产应用掉电特别严重，用全海外应用续航可以到一天半，装个淘宝啥的续航就只有 4 个小时了。

我用三星国行，有一个只有大陆行货特有的功能叫“智能管理器”，可以调节杀后台杀哪些应用、放过哪些应用，然后 Android P 如果各大厂商能把 AI 电源管理利用起来的话效果应该可以更好。

返回状态按照数据层分级，HTTP 层的状态用 HTTP 层状态码来表示，业务层的状态用业务状态码来表示，比如客户端 abc 参数传错了，这在 HTTP 层看来是“客户端错误”，所以应该返回 400 的 HTTP 状态吗，但同时在业务上来说是 abc 参数错误，所以同时返回 Body 应该用业务状态码或者错误信息告诉客户端究竟是哪里错了。

REST 风格是以资源为中心的，简化接口复杂度，将部分功能降级交由 HTTP 层来表示，对于资源找不到的情况，应该按照 HTTP 的 Not found 状态来表示，即 404 状态码。

REST 设计风格不是说客户端和服务器一方使用的，而是双方都使用的，客户端不管使用什么语言，都应该选用 REST 友好的请求框架来与服务器的 REST 接口通信，否则就不要使用 REST 风格了，不完全按照 REST 的思想来设计不能享受 REST 带来的好处，甚至可能会适得其反。

然后从系统可靠性上来看，不管服务端用的到底是不是 REST 设计风格，客户端都应该对所有 HTTP 层的异常做妥善处理，不是抛错误了事，而是应该处理所有错误情况；而在应用 REST 设计风格的时候，要习惯将 404、403、401 等作为“正常”状态来妥善处理，提升系统高可靠性以及用户友好程度。

最后建议整个开发团队科普一下 HTTP Status Code 标准： https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
表示“成功”的状态是整个 2 段，不只有 200。

没做过，但可以提供一个大概思路：

看一下 MacOS 的屏幕镜像开关支持什么语言开发，用相应的语言开发屏幕镜像开关的接口，然后用 N-API 之类的绑定 JS 接口，再用 Node.js 调用。

大学时候的老师说过一句话对我影响特别深：“一个技术人员的优秀不在于会多少语言、库、框架，在于是否可以解决问题。”
工作几年的感受是，用到的大学课程里学的知识基本上就只有计算机组成原理、计算机网络、离散数学、数据结构与算法、操作系统、C 语言（了解程序较底层原理，又不像汇编那样无人性），我的意思是说，大学的时候也学了几种高级编程语言以及一些框架和库，但工作后发现学校里学的很多都被新技术取代了。为什么前面几种基础课程反而用到一些了呢？个人认为那几种基础课程教的更多的是思想，而思想是跨语言、框架、库的，且永不会完全过时的。

所以大学里可以教框架，但是除非是定向培养的情况（如外包公司合作），建议侧重教框架思想，工程上出现了什么问题，以及框架是如何解决问题的，这样学生们掌握的就不是框架的用法了，而是解决问题的思想了。

网络协议的层位不是固定死的，而是相对相邻层的，一般说 HTTP 协议可以基于 TCP 协议运行，但如果有能力在 UDP 协议上模拟出一个 TCP 协议，那么这个模拟的 TCP 协议上理论上也是可以跑 HTTP 协议的。

用 UDP 跑 TCP 的案例已经出现过很多个了，比如科-学#上%网用的一些如 unʇdɔʞ(倒着看)，还有ʎɐɹՇꓥ(倒着看)等工具都比较成熟地利用了 UDP 协议。

QUIC 可能比 UDP 模拟 TCP 再跑 HTTP 的方式更加直接，以后的发展潜力也是挺高的。

QUIC 啥时候普及可以参考 HTTP2 的普及情况如何，估计得很多年。

不如试试在内部判断分流？

ele.onclick = ()=>{
if(xxx) _funcA() else _funcB();
};

程序员月薪区间很大，最高的能达到 5、6 万，最低能到 2、3 千，赚的多的都是能快速自学技术不需要别人教的，最起码得能流畅阅读英文技术文档，高等数学基础也得扎实，否则入行就很有可能成为那群挣钱少的人。

上能接本的专科，然后升本，先搞个学士学位出来，否则还是别入这行了。

要是想做些强交互弱功能的可视化工具的话，JS、HTML、CSS 可能是最方便快捷的。

但如果想要应用更广泛更全能的话，Python 最合适，批处理、科学计算、服务器、硬件、爬虫、人工智能、原生 UI （ Qt ）等等都可以用。

Manjaro 是基于 Arch 的，牺牲一些定制性换取易用性，挺有发展前景的。不过我还是喜欢用 Arch，折腾惯了。

桌面环境推荐 Gnome，比较简洁，又不失美观，适合高效办公。
终端模拟器推荐 Guake，一键切换显示与隐藏，适合重度命令行用户；环境不适合 Guake 也可以用 Terminator，功能强大，与 Mac 上的 iTerm2 相似。
用过 Ubuntu 喜欢用 Synaptic 包管理器的，在 Arch 下可以考虑 Octopi。
Gnome 自带的磁盘空间分析工具 Baobab 挺好用的，直观了解哪里在占用大量磁盘空间。
Shell 推荐 Zsh 搭配 Oh my zsh 配置包，效率神器，我自己也在此基础上做了个 idlebox 工具箱，集成了日常使用的脚本。
Arch 系的系统想用 AUR 的话，以前流行的 yaourt 因为安全风险不推荐使用了（不知道现在怎样了），推荐 yay，很现代化的软件包管理器。
远程传输文件，如果操作比较碎，用 SSH 或 rsync 会比较麻烦，可以用 FileZilla，这个是跨平台的，官方还提供 FTP Server 端可以自己快速搭建一个 FTP 服务器用。
压缩推荐 p7zip，支持所有主流压缩格式。

所有计算机问题都可以用两个思想来解决：分层和解耦。
分层可以将整体复杂度分解到每个层中，使得每个层的复杂度相比以前的整体复杂度要低。
解耦可以将问题和风险封锁在一个模块内，提升解决问题的效率，降低风险的影响范围。

不过也要辩证去看，因为很多问题的解决方案都只是权衡之计，解决了一方面问题又出现了另一方面问题，最合理的方式是从实际出发，平衡各方面，选取最适合当前情况的方案。