@Oktfolio Java 这种老古董, 不思进取. 谷歌都在逐步放弃, 现在转也是选择 Kotlin, 选择 Java 才是入坑

@billytom 反正那个蓝牙搜索有时候会不靠谱, 特别是外壳全金属的笔记本, 还有就是蓝牙 5.0 的设备更容易搜索到. 微软很多好用的功能做的太不人性化了. 明明 WIFI 我已经设置为专网模式(速度慢, 可能是因为没有设置这个), 这样就近共享就可以和依靠蓝牙的蓝牙分享合并在一起, 在 WIFI 模式下, 使用局域网共享模式分享文件. 搞不懂微软的脑回路.

@anshigm OneDrive 同步代码是不靠谱的, 特别是有 npm 这种辣鸡, 会出现各种诡异的现象, 而且官方也不建议同步代码, 坚果云也是一样, 我为这个事情还专门发邮件咨询过

@njshiyanhz ITX 机箱对我来说太大, 我在考虑是否自己用 3D 打印来搞个机箱. 大部分机箱都给显卡留了位置, 我感觉那个位置完全是浪费, 我不需要显卡的空间, 因此可以将整个机箱的厚度压小, 散热器是个麻烦, 我还没想好怎么搞, 标准水冷和风冷都太大. 可能是我这个需求太小众, 感觉苹果的 Mac 比较符合我的需求, 奈何它只能 ARM, 我需要 X86

将所有重度运算移动到 Web Worker 中去, 不要再浏览器的主线程上做 CPU 重度操作.

@njshiyanhz 我其实是想找一个和 Mac Studio 差不多大的 Windows 主机, 我现在用的台式机我感觉太空旷了, 里面不插显卡, 大部分都是空的, 而且 CPU 的散热风扇太大了. 感觉有很多优化空间! 不过估计是找不到了

@lawler 这个玩意太小了. 我同事还给他安装了一个散热贴. NUC 要不就是你这种小的, 还有就是特别大的那种. 都不符合我的要求, 我大概需要尺寸和 510S 差不多, 但可以厚 2-3 倍, 性能非常强的. 最好没有显卡插槽, 因为我不需要显卡插槽, 有专门的游戏设备.

@lawler 这个玩意我同事有. 风扇呼呼转. 我想要好的大概尺寸 Mac Studio 差不多大, 性能要够强. 辣鸡微信小程序的开发工具实在太卡了. 我现在回家只要边看视频, 边写代码, 电脑就会非常卡.

@lawler Intel 的 UNC 太大了, 我原来买个联想的 510S, 性能太差, 还特别容易发热. 性能和我的笔记本差别不大.

@Kasumi20 你自己写个测试函数试一下不就知道了

没啥好不好, 看团队怎么确定, 我们团队按照:dev/test/staging/prod 来

并不会降为 30HZ, 不知道你怎么得到这个结论的!

@DOLLOR 他想让编译器给他检查流程, 就是这个函数的返回必须必须即有 string 也有 number, 我目前是没想到有什么方法, 因为这个需求本质也是一种类型运算, 需要编译器检测函数返回类型, 然后组合. 但是目前 TS 似乎没有那个类型本身可用进行这种特殊的类型约束, 因为这个约束类型 never 这种, 需要超越类型本身的信息, 做分支流程检测.

@Building C#的 Task 比较复杂, 并不是简单的协程, 既可以多线程, 也可以单线程

使用一个主线程去发送请求(和 MySQL 打交道, 发送异步请求), 关闭同步上下文, 然后在主线程上发送 HTTP 请求, 然后主线程就等待(用 Task.Delay()), 时间到了再次轮询数据库. 在 HTTP 的 IO 的 Task 上附加成功的后续操作, 这个操着会在线程池中获取一个空闲线程, 然后执行. 一开始配置好线程池的物理线程数量和 I/O 线程数量. 你给出来的信息太有限了, 很难给你分析. 另外真个场景我估计瓶颈不在 CPU, 如果后续操作费事很少, 则 CPU 应该一直空闲, 如果你开启了上下文同步, 则可能导致主线程假死!

这个破帖子一看就是骗积分的:
一切都是权衡, 微软官方有出过书籍, 详细讲解过.NET Framework 的命名规则的各种来源, 非常详细, 也说明了各种权衡的利弊. 不学无术就不要想当然的瞎猜.
对于命名规范这种东西, 只有一致性最重要.
另外每个人都有自己的先入为主, 总是感觉自己最初接触的东西才是最自然最舒服的.
有时间去看看这本书: <<Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries>>.
另外这个世界不是围绕你转的, 每个领域都有自己的约定和习俗, 想当然的强迫别人和自己保持一致属于即幼稚还暴戾.

@waiaan 没啥绝对的好处. 很多时候需要在一个目录树打开多个项目, 而这些项目已经存在磁盘的不同位置上, 如果没有工作区就会非常麻烦, 需要移动文件夹,一些项目甚至对绝对目录有依赖, 一旦移动位置, 就直接无法运行了. 工作区加入的原因和讨论在 VSCode 社区有讨论, VSCode 大部分功能的加入都是有公开讨论的. 工作区还可以跨项目配置 VSCode

@waiaan 工作区是一个逻辑分组, 可以将不同位置的不同目录组织在一个工作树中, 而文件夹是做不到这点的, 文件夹必须和物理磁盘的文件树解构保持一致

@shm7 我给朋友找了一个成熟的供应商, 我自己不折腾, 没有那个精力. 我感觉要做到商用精度也不是一个人短时间可以搞出来的.