一切源于我的 iMac 想要配合 MacBook Pro 进行升级, 不是 M1 的话不方便.

如果不是 5k, 一个显示器不够用.

而两个显示器费脖子. 因疫情昨天下午用了一下双显示器, 脖子就疼了.

所以想着三个显示器, 主要盯着前面的.

但是 Mac mini 不支持 3 显示器.

本来我是期待 M1 版本的 iMac 27, 但是可能没有了. 所以想着是现在升级呢还是等等.

@wy315700 感谢.

有些没说清楚, 我的前提是:

1. 雷雳 3 及以上刚需, 2 不行.
2. 希望和笔记本一致, M1 系列.

@Chihaya0824 可能是我用的显示器比较少吧, iMac 的亮度在白天办公时非常有帮助.

我的工位右边和后边都是大窗.

高 PPI 可能因人而异吧, 同事 1080 都能用, 但我都忍不了 2k.

@wazggcd 有点断章取义了吧. 要看情景的呀. 比如我的原话是:

所以, 如果在意减少多种工作间的切换, 那么即便写代码也是值得上 Mac Studio 的.

换言之, 如果本就刻意专注而非兼顾, 那么写代码的确不太能用上.

请不要把 “如果, 那么” 忽略掉.

@agagega M1 和 M1 Pro / Max 的一大区别就是是否带 媒体处理引擎. 从这点来说, 我觉得 M2 可能依然不带 媒体处理引擎, 供非媒体行业工作者.

但更好的显示芯片也能带来多屏协同, 支持 3 台 4k 显示器对普通工作应该也是挺有用的.

@stimw 就是自己想想要不要把 iMac 27 升级, 把自己的想法发出来而已.

无论什么事儿, 想吵都能吵起来. 但同样, 无论什么事儿, 想聊也都能聊开. 就看大家什么态度对待了.

@movq 我的出发点还是 Mac Studio 作为 iMac 27 英寸的替代品, 和 Mac mini 的升级品这点. 没有和 PC 比的意思, 否则会变为生态对比, 操作系统对比等.

做 Web 开发和小程序开发会麻烦, 前后端均需要 (可参考 gRPC Web) 做额外的操作.

不知道我看到的情况和当时有多大差别, 但主要维护者还是对这样的修改有讨论的: https://github.com/denoland/deno/pull/12057#pullrequestreview-753151404

还是一个 API 设计问题吧, 可以讨论.

还需要一个 PHP 运行时, 就麻烦. 能编译为单文件运行就好了.

我常用的一种情况:

在做主要工作.

顺手改了部分代码, 没完成, 暂时不想提交.

我希望顺手的这部分保留, 但现在不要影响主要工作.

如：请求一本 book 的订单信息

前提应该先有 book ID.

1. 根据 book ID 调用 book info.
2. 根据 book ID 调用 bookOrderList 拿到 bookOrderInfo[]

book info 和 bookOrderInfo 分开可以理解, 因为是两个业务, 但 bookOrderInfo 和 bookOrderState 分开就不理解了.

刷新页面并不会执行 beforedestroy 这句话本身没问题, 但和内存泄漏也没关系.

或许面试官是想说异步嵌套, 事件订阅问题?

目前 Deno + React, 核心优势是使用 TypeScript 后 共同的业务类型约束, 相关的运行时类型判断函数也通用.

Google 中文 的确不够好, 必应中文 我用起来也一般吧.

最后选择英文或者特定站点的站内搜索.

@az22c 选择不用 brew 解决. 源代码编译.

如果自驱力都很强, 没有绩效才好.

我能想到的最好的方法就是小团队内的技术经理一天到晚就看代码, 团队内的项目经理一天到晚就看大家的沟通. 每一个加减分的项目都记下来, 到时候将问题项目匿名化让大家根据所有问题进行逐项计分. 坏处就是为了追求绩效的尽量公平而浪费了人.

不知道 AI 是否会感觉被歧视.