作为弱鸡菜鸟且看不懂昨天自己写的代码的人来说, 外键什么的肯定是能加就加.

就比如用 final, const, private, 尽量全参构造器不用无参构造器 等的原因是一样的.

毕竟不是那些可以背诵 mysql 源码和默写 jvm 优化的那些大神.

但是有一点不明白了,该用外键的时候都不用了, 都不在乎数据对不对了,直接上 NoSQL 不是更爽? 直接 ES 一波梭不爽?

SQL 都是上世纪无用技能了, 还用啥 SQL 啊.

就像那些 post 接万物, http status code 不用,非要写一个 msg 里面是状态码的大神一样, 我们这些菜鸡还真是理解不了呢

用 google photo

什么时候 刀剑神域 中的 NerveGear 实现了, 再说元宇宙的事情. 之前都是太监上青楼

@sujin190 有影响的 https://pytorch.org/docs/stable/notes/randomness.html 但是应该不会影响最终性能(89 -> 88 这种区别)

@passMeBy paddleOCR 的小模型还挺快的,我这边一般都是一张文档 3 秒(CPU), 大模型和小模型精度在我的使用场景下基本没差...

@passMeBy 这个我就不太清楚了, CNN 的那个是原来做实验的时候要把 CNN 设置一个随机数定死(具体忘记了),然后才能让跑分一致,但是那个一般不会影响特别大. cnocr 现在好像是 pytorch 了,当时用的时候因为是 mxnet 转 onnx 不好用就放弃了. 上面说的 paddleOCR 是比较好的方案,虽然也有坑. 现在感觉就是生产环境 onnx 天下第一,paddlepaddle 框架的话,除了脏话没啥想说的

cnn 的快速实现结果是可能不稳定的, 好像是有办法关闭, 但是那种应该是不影响到性能

也有可能是一个是 cpu 一个是 gpu 再加上导致不一样, 但是也不至于到影响精度的程度.....

感觉图像被压缩的可能性更大一点....

特斯拉的自动驾驶就是花架子, 应该说现阶段所有的自动驾驶都是花架子,有 acc 和车道居中就够了. Tesla 的优势不是好开么.....

如果照着漫画拍,还是不要看了,漫画结局就是类似于: 我不想要大圆满但是我也想不出别的好的结局,那大家(读者)就都不要好过吧! 这种结局.

现在看动画的希望就是希望结局改了

1. 没有
2. 不应该这么用
3. 实体类直接交给 service 处理对应业务就行了, controller 不应该在这里处理东西
4. 确实会有只需要实体类中的部分值进行某个业务的(如创建), 这个地方有一些解决方案,比如持久化的和前台的不是一个,一对多,再转换. 持久化类进行继承(有弊端也有好处)

这种的意义是啥, 就像 ++i+++=++i++, 没有任何意义

有能力,没牵挂就赶紧跑啊!!!

其实吧,大部分人其实都不明白,或者说没有真正明白 996 什么的是什么. 亦或者说是一种利己主义和明哲保身,很多东西的不透明和选择性执行造成了工薪阶层的高风险成本. 这种环境下,不主动不拒绝拼命干一阵然后赶紧跑(或者被赶跑)成了最优解,毕竟主动拒绝看长远都需要稳定和保障,而这两样...

以后交流全在 im 上呗，有记录有时间，做没做会不会，一目了然啊

为什么听你们说这么简单，我 PayPal 弄个香港和美区账号费了好大劲……比如手机号和风控

混动，雅阁啊………

就我看来, 大部分类似于蔚来的车厂, 造车的思路就是智能手机装四个轮子. 车子首先是好开, 其实都是次要的.

特斯拉不管有什么问题, 至少他是一辆好开的车.

大部分传统车企的电动和那些新势力大部分不太一样, 他们至少是在造车(不管是因为他们想明白了的原因还是因为他们没想明白的原因)

要是没办法只能买电车,然后买了 model3, 动能回收我肯定不想开, 单踏板觉得不管怎么想都不安全. 就想改写 final 的变量没写 final,看着没啥跑着也很好,但是不知道什么时候哪个小伙子就给你改了代码

虽然 model3 没 crbs 各种负面新闻, 看着也廉价.... 但是奈何对手不行,那个价位的电车还是它牛逼啊....真的是同行衬托....如果不是电车,那个价位可以来个小点的油车,应该选择还是很多的(考虑安全性的情况下)