Java: userName
Python: user_name
CSharp: UserName

输出: JSON: userName
输出: XML: user-name

允许用户通过 HTTP Header 头控制格式化风格, 在 Web Service 中找个中间件做格式化反序列化和序列化

Python 当然应该使用 Python 自己的变量命名风格, 使用_做单词分割, 至于发送到前端的 json, 当然是找一个支持定义属性转换器的 json 解析库啥. 另外你一定要使用驼峰也不会有啥问题, python 核心库的命名规范本来就不统一, 各种乱七八糟的命名风格, 奇怪的缩写都有, 主要看你们项目的规范要求. 并不会造成什么问题.
我之前写过 Python/C#/Java, 命名规则都是按照语言标准库的形式来, 然后输出格式也按照目标数据格式的消费者的习俗来. 尽量减少阻力和不一致性. 但这样会对性能造成轻微损失.

@zoharSoul ZF 部门, 公共资源交易中心, 还有一些是涉密的, 不方便说.

@seakingii 和你所在的行业有关系, 我们这个行业使用 Linux 才是非主流, 基本清一色 Windows Server 2016, 没有专业运维, 使用 Linux 纯粹是给自己找麻烦!

你这个需求非常简单, 甚至只需要几个小时就能搞定. 但是如果你需要熟练掌握 Linux/Windows 运维, 要学的东西可多了,这个只能日积月累, 因为经验才是运维的核心竞争力. Linux 基础运维使用: 鸟哥的 Linux 私房菜, 过一遍就好了, 然后根据你需要部署的软件去 Google 搜索教程, 也可以先使用百度, 遇到搞不定的再去外网找权威资料.

我只是一个小透明, 主要是 FP16(也比较少),FP32(密集), uint8 很少(transforms 最初需要), 然后就需要大量的累乘和加法了, 因为不同类型的运算耗时也是不同的, 所有只能综合考虑.一般 TOPS 应该是只能做 8 位的定点数运算, 浮点运算需要模拟, 一般 GPU 我感觉都是使用 FLOPS, TOPS 用在于 FPGA, 很少看到混合使用. 另外芯片中不同位长, 不同类型的运算所需要的时间都不相同, 不在同一个标准, 有时候很难定量的去比较实际差异, 你可以 google 搜索一下相关的研究论文.

没有直接的换算关系, 否则就不会出现这么多单位了. 主要看你干什么, 因为不同场景下评估一个芯片的算力使用同一个单位是无法准确对比其真实性能的. 不同类型的任务有时候用的操作类型有时候相差很多, 甚至完全不相干. 在做卷积神经网络训练的时候, 我们做报告都使用 GMACs, 因为主要的就是乘积累加运算.

另外不要在携程中试图依赖确定性的调用顺序, 除非你手动同步, 或者使用链式等待

因为规范并不保证 333, 444, 555 的执行顺序, 它唯一保证的就是 444 总应该在 333 后面, 而 333, 444, 555 的确定性顺序是未定义行为, 我猜想是编译器优化了无返回值的情况, 这样 555 就更快的得到了执行(还没有执行到 444, 当你手动编写了 Promise.resolve()后, 这个执行需要消耗时间, 这个期间, 444 的任务链条可能已经结束了执行, 因此就是你看到的 333, 444, 555, 不过正如楼上所说, 这些对实际开发影响很小. 你如果除了对 what, 还对 why 感兴趣, 也可以自己深入去研究一下

volatile 只是告诉 runtime 执行适合需要插入指令禁止乱序执行和缓存 instance 的引用地址(尽可能每次引用 instance 都需要从内存中去读取最新的值), 你要证明这个其实添麻烦的, 因为本质上是要撞运气, 至于你现在写的这个代码应该是不会存在 partially initialized instance 的, 因为 new DclSingleton()被正常构造完毕前, instance 是不会获得引用的, 除非你的 DclSingleton 是一个需要需要后序初始化的操作.

Java 整个体系没啥大问题, 除了啰嗦了点. 否则也不会成为如今后端的 TOP 1 了, 虽然有历史的进程原因.
1. Servlet 规范是没法抛弃的, 这个本质上就是整个 JAVA 生态的原初理念
2. 字段不应该直接暴露, 这个和有无逻辑毫无关系, 暴露细节违反了面向对象最基础封装特性, 这个几乎没有争议
3. 面向接口编程没啥问题, Java 一些解决方案的复杂化是因为大家都过渡追求复用, 然后过度抽象. 如果你确定一个东西不会更改, 你完全就可以直接 new, 你看你的代码是不是到处都在直接构造 String 这些基本类型. 最佳实践都是人们踩过的坑后慢慢总结出来的, 因此公司项目还是要以规范性为主, 因为你需要和其它人协作, 多人协作一致性是最重要的一条原则.

最快确定一个人是否完整,系统且认真的学习过 JavaScript, 而不是将其当作玩具语言, 到处复制粘贴代码. 面试如果招聘前端, 如果原型都无法解释清楚, 肯定会被我淘汰, 因为这个玩意非常简单, 这个都搞不明白, 说明要么智力有问题, 要么根本没花心思在自己使用的工具上. 实际项目手动使用 prototype 非常少, 但它总是在起作用. 编写兼容库的时候, 会通过补全原型来模拟一些原生方法.

编译器没有获取足够的信息, 并不知道自动给你填充足够的类型.
实在想跳过去可以这么做: ref({} as unknow as ICategoryFormData)

另外我们的项目 Query 和 Command 是分开的, 用了不同的数据库, 大部分时候并不需要复杂的 Join

正常直接使用 EFCore, 有需求的情况下直接在 Context 上直接调用原生 SQL, 我们的项目需要根据场景切换数据库(Oracle/MySql/SQL Server/MongoDB), 而且写 SQL 的时候都会使用 Repository 包一层, 按照实际引用的 Provider 做不同的适配, 如果要追求极致的性能, 我直接用 ADO.ENT 了, 另外简单的项目使用 LinqToDB. Framework 时代用 Dapper 比较多, Core 后基本没用过了

这些哲学问题, 有文字记录以来的贤者都深入思考过, 现在哲学的存在主义也试图回答这个问题. 不同时代, 不同境况的人都试图描绘出自己看到的大象的模样, 就这样争吵了几千年. 存在先于逻辑吗? 也许永远不会有答案, 但对这个问题进行深入思考, 还是有意义的, 至少可用让自己活得没有那么糊涂.

应用层按照功能尽可能的多公开数据, 一个模型就不会有太多 dto, 正常情况下就只会有 CreateEntityDto, UpdateEntityDto 和 EnttityDto, 为了节省带宽按需求获取部分参数, 则在上面包一层 GraphQL, 验证的逻辑安全可以不写到 Dto 上, 而是直接使用 Fluent Validation API 使用代码定义, 而不是总是使用 Atttribute, 即便使用 Atttribute, 也不应该对 Dto 做逻辑校验, 一般只做简单的数据格式校验, 这种情况, 重复写多次 Attribute 并不是什么问题, 另外你也可以给 Dto 分层, 使用继承和泛型组合. C#类型运算太弱了, 几乎等于没有, 没法像 TypeScript 那样领域, TypeScript 的类型运算骚操作太多, 对于 C#这种纯静态语言(不考虑 DLR), 按照 TS 的逻辑写肯定是不大行得通的