@zictos 我在考虑到底要不要去 12315 杠到底, 主要是 400 块钱的东西, 浪费太多时间也不值得,我买的时候最高价, 399, 现在已经只值 200 多了, 花时间折腾, 还不够我的时间成本, 越想心底越不平, 越想越生气, 我还是要去投诉, 我看京东后面怎么处理!

@zictos 有点无语, 京东天天吹自己的售后, 结果出了问题相互踢皮球. 我掏钱让罗技售后给我维修他们也不维修, 真他妈无语, 罗技这个辣鸡品牌, 不知道怎么做到这么大的!

@op351 可以的, 我最开始提交他们就直接同意了, 然后派人收走了我的鼠标. 我当时一共买了 2 个 G603, 我看后面另外一个的微动会不会坏. 他们给我寄回来的时候还换掉了我的电池, 给我随便换了给不知道什么牌子的垃圾电池!

@zictos 我真正生气的是第一次申请售后, 他们也没说什么, 直接同意了, 我拍了 4 张照片. 结果我等了一周, 竟然原封不动的给我退回来了, 我今天用的时候才发现, 还是有问题, 耽搁我的时间, 我只能去找其它组的同事借用. 结果我打电话给客服, 他们说售后检测没啥问题, 我说还是滚轮回滚, 售后客服让我重新申请售后, 结果我重新申请的时候, 客服大概 2 个小时后给我回电, 说我标签损坏, 无法维修, 让我找罗技的售后, 我打了罗技的全国电话, 他们给我了深圳维修点的电话, 我打电话过去, 客户告诉我, 我这个标签损坏, 而且是电池漏液导致的, 可能主板坏了, 他们连维修都不肯给我维修, 让我自己更新下驱动, 没法维修. 我想说你们官方的电池, 放在电池仓我正常环境使用, 然后漏液腐蚀了标签, 为什么我需要自己负责. 回头想一想, 可能真只能自然倒霉, 扔掉算了, 罗技一生黑, 不会再买任何罗技产品了, 网上有滚轮回滚的人实在太多了, 搞不懂罗技用的什么垃圾微动, 又不是几十块钱的东西, 质量差成这样!

@JamesR 主要是决定不爽, 几百块的鼠标换一个我也不心疼, 就是非常不爽京东售后的态度, 而且忽悠我寄回去, 我寄送的时候就拍过照片了, 它们如果直接告诉我标签坏了不能维修, 我就认了, 买个新的, 但售后完全实在忽悠我, 让我一周没有鼠标用. 就是向找个地方投诉他们! 想想自能自认倒霉, 第一次被京东售后坑, 在京东购买了快 15W 的电子产品了, 几乎没怎么退换过货物, 结果售后竟然如此不靠谱, 想想有点生气.

2720QM(可以购买)+2520DR(不推荐购买)+小米 34 曲面(不推荐)+iMac 27(不推荐)

我手头没有 Mac, 不过建议你去这个插件的 GiHub 仓库浏览器一圈. 还有写代码使用背景图片不会严重干扰注意力吗? 表示疑惑!

一般, 有些坑, 除非你的后端业务非常大而且复杂, 协作人员多, 否则自己从头到尾搭建反而简单一些. 不过这种 Admin Template 对没啥要求的后端业务系统, 也没啥坏处!

换主题, 但是每个主题也有一个自己的高亮颜色, 为了可访问性, 必须要一个高亮颜色!

@gowk 我啥都做, 什么技术合适用什么, Android/iOS//Java/Python DL/ 微信小程序, 看公司的需求, 什么乱七八糟都要学一点. 不过终究还是在.NET 技术栈花的时间最近. 我在做的属于传统行业, 业务逻辑复杂, 但并发有限, 项目需要常年维护, 我现在做的项目已经开发了快 15 年了, NET 还是有很多存量应用, 主要是 Core 出来后, 原来想要转型的项目现在也没有动力了.

@frank1256 凡事都有代价, 没有银弹, 学习一门技术, 重要的是理解它解决了什么问题, 带来了什么问题, 这样才能在项目中合理使用, DDD 适合业务特别复杂, 模型众多, 模型行为丰富, 重行为而非重数据的项目. 很多互联网公司的业务一点也不复杂, 只是规模庞大罢了, 那些项目用 DDD 可能没啥好处, 反而为了追求极致的性能, 使用事务脚本, 甚至裸写 SQL 这样反而更加合适.

@frank1256 DDD 的好处是通用语言可以保持业务一致性(这个就是第一道门槛, 越复杂的项目中, 很多术语大家没有天然形成共识, 是需要需求方, 业务专家, 开发者多方探讨, 最终达到一致性的: 说人话就是对同一个概念大家表述的是同一个东西, 这一点小项目看不出来啥优点, 但项目越复杂, 概念就会越不清晰). 子域(领域上下文)会强迫你思考如何将不相关的业务的实体分离到不同上下文, 这样你就没办法使用强一致性的方式直接操作这个对象, 而是必须去思考如何平衡 CAP. 另外他也会让你逐步学会思考使用关系模型(E-R)构建的面向对象模型是否合理, 如果你一开始就是使用的 MongoDB 这种数据库, 你就会更加深入理解对象的相互引用关系(引用即依赖, 依赖是重度耦合, 会带来很多问题). 这个话题太大, 不是几句话就可以说的清楚的....

@frank1256 可以多多交流, 我现在按照 DDD 这套写了也快 5 年了, 蒙蔽的地方还是很多, 但目前刚好能 HOLD 住现在的项目的复杂度. 如果你的项目不是长期维护, 使用 DDD 写是不值得的.

回到面向对象最初的初衷, 而不是将面向对象写成流程处理模式的事务脚本.
如果你的业务 CURD 能 hold 住用 CURD 的事务脚本模式也没啥问题!
DDD 需要较高的成本, 而且再没有任何基础设施的情况下, 很容易写偏.
不过它的战略模式还是很有用的, 对大部分项目都有一定的参考价值.
我们使用 DDD 写过几个项目了, 框架使用的是 ABP, 团队也在自己重现构建内部 DDD 框架.
主要是团队的人都习惯了强事务一致性的事务脚本, 将多个模型的操作糅合到一个 Service, 导致 Service 变成了大杂烩, 越来越难以维护, 最终不得不研究使用 DDD 做切分, 后来又不得不上 CQRS, 前期阻力比较大, 现在再稳定维护期后, 大家就很爽, 添加功能也变得比原来容易多了.

如果有大量的字典类型的需要处理的, 可以使用 easydict, 最好还是将数据清洗一下, 这样效率高一点
import json
from easydict import EasyDict;

genre_movie = '{"genres":[{"id":28,"name":"动作"},{"id":12,"name":"冒险"},{"id":16,"name":"动画"},{"id":35,"name":"喜剧"},{"id":80,"name":"犯罪"},{"id":99,"name":"纪录"},{"id":18,"name":"剧情"},{"id":10751,"name":"家庭"},{"id":14,"name":"奇幻"},{"id":36,"name":"历史"},{"id":27,"name":"恐怖"},{"id":10402,"name":"音乐"},{"id":9648,"name":"悬疑"},{"id":10749,"name":"爱情"},{"id":878,"name":"科幻"},{"id":10770,"name":"电视电影"},{"id":53,"name":"惊悚"},{"id":10752,"name":"战争"},{"id":37,"name":"西部"}]}'

movies=EasyDict(json.loads(genre_movie)).genres
genre_ids = [80, 9648, 53]
genre_names = [movie.name for movie in movies if movie.id in genre_ids]
print(genre_names)

机器学习本质上就是拟合分布, 你需要保证你需要预测的数据符合分布. 因此机器学习只能预测共性, 没法预测它没学到的未知的东西, 而测量恰好就是未知数据! 我之前也研究过给雷达点云按照历史数据预测不存在的点来尝试补齐物体的轮廓, 后面发现效果不好, 没啥用, 纯粹属于浪费时间和算力!

@ray5173 你要补上的目的是什么干什么? 机器学习又不是什么魔法, 这种拟合出来的数据没啥用

你最好将数据先全部先备份,数据库以页为存储, 索引和页数据都在页上, 我怀疑物理某些页在磁盘扇区上物理损坏了.

@theklf4 做旁路有太浪费了, 有啥大的毛病没有?