你们感受下........... 不服!!!来战!!!
之前Lady我一直在犹豫要不要弄一个在NVIDIA Xavier上安装SSD的教程。...但既然Jetsonhacks早就出了相关教程,我就不啰嗦了,先上他的视频: Lady要特别强调在安装过程中的这个细节: ?...因为这里连接了一根线,如果你打开的方向错误(比如从另外一边打开),那势必这根线可能会被你扯断——后果可能会导致零件损坏,从而影响质保! ? 视频中用的SSD卡: ? ?
本文是吴恩达《机器学习》视频笔记第62篇,对应第6周第4个视频。...那,如果在使用机器学习算法时效果不理想,那能够搞明白到底是偏差太大还是方差太大抑或两者都太大那就显得比较重要了。这样就能够有针对性的改进我们的算法了。 本节视频将讨论偏差和方差问题。...偏差/方差 下图所示,从左至右依次是欠拟合、合适、过拟合。 ? 利用上节介绍的交叉验证集。计算训练误差和验证集的误差。我们看看多项式的最高次幂和误差之间的关系曲线是怎样的。...高偏差还是高方差? 当你算法未达到预期的时候,到底是出现了高偏差还是高方差呢? 还是来看一下d和误差的关系曲线,如下图。 ? 一般情况下,左侧一端对应的是高偏差、另一边对应的是高方差。...事很简单,就是对比训练误差和验证误差的大小关系就大致能判断出模型是欠拟合还是过拟合,然后就可以采取对应的措施(例如多项式拟合,就可以通过不断尝试找到合适的d)。
线性一致性的精确定义很精妙,本节余下部分会进行详细探讨。但其基本思想是,一个系统对外表现的像所有数据只有一个副本,作用于数据上的操作都可以原子地完成。...这样是合法的,并且说明数据库先处理了 D(设置 x = 0)的写请求、接着处理了 A 的写请求,最后是 B 的读请求。...之前提到的获取体育赛事决赛比分不是一个能凸显其重要性的例子:在该情况下延迟几分钟得到比赛结果可能并不会引起什么实质性损害。然而,在某些领域里,线性一致性是系统能够正常工作的重要依赖。...不论使用什么方式实现锁,都必须满足线性一致性:所有节点必须就某节点拥有锁达成一致,否则这样的锁服务是不能用的。...然而,这种说法极具误导性,因为网络分区是一种故障类型,而不是一种可以取舍的选项:不管你喜欢还是不喜欢,它都在那。当然,也有人理解为用单机系统可以规避,但我们当下讨论的前提是分布式系统。
private Integer productStatus;//商品状态(0正常,1下架) } 有一个商品类,productStatus是其状态,0是上架,1是下架。...其实是类目名,如果这个vo也直接定义变量name,到时候会搞不清楚到底是商品的name还是类目的name。...六、dto的使用: dto全称是data transfer object,中文意思为数据传输对象。那么dto有什么作用?什么时候该用dto?如何使用呢?...但是这样不好,感觉就是污染了这个与数据表对应的实体类,我们还是要让实体类与数据表 一 一对应,所以class类不能增加这个字段。...七、异常处理: 平时我们用异常可能直接throw一个exception就完事了,但是这样不好,因为这样抛出去自己也看不懂是什么异常,所以可以像下面这样处理: 自定义一个异常类继承RuntimeException
像 json序列化/反序列化一样,同名属性尽可能映射(比如 int? 到 enum) 3. 增加 HigLabo.Mapper的PostAction概念 4....内部Mapper都是泛型的,但使用时传入的source很可能是 object,所以都是使用 反射创建泛型化的Mapper实例,然后建立TypePair的对应关系,这样就解偶了泛型 2....如果能像 AutoMapper 那样提前注册所有映射关系,速度优化的手段会更多,估计这也是 TinyMapper 转成提前注册的原因吧。...当然我还是觉得只要不是数量级的差距,都不太重要。 4....我的潜意识里 SimpleMapper 就为解决当前项目的问题,比如从数据库中读出来对象,映射成Dto后,就不会被再使用了,所以SimpleMapper默认是浅拷贝。
代码是工程师能力和修养的体现,有的人,即使用了stream,用了lambda,代码也依然写的像屎一样。 不信,我们来参观一下一段美妙的代码。好家伙,filter里面竟然带着潇洒的逻辑。...dto; }); } 在实际的业务代码中,这样的赋值拷贝还有转换逻辑通常非常的长,我们可以尝试把dto的创建过程给独立开来。...这样的转换代码还是有点丑。...但是注意,很多开发人员是没有这样的意识的。既然api提供了这样的函数,它在逻辑上又讲得通,那你是阻挡不住别人这么用的。 并行流还有一个滥用问题,就是在迭代中执行了耗时非常长的IO任务。...我的做法是一刀切,直接禁止。虽然残忍了一些,但它避免了问题。 总结 Java8加入的Stream功能非常棒,我们不需要再羡慕其他语言,写起代码来也更加行云流水。
例如,典型的业务系统都需要: 接收request,响应response; 做业务逻辑处理,像校验参数,状态流转,业务计算等等; 和外部系统有联动,像数据库,微服务,搜索引擎等; 正是有这样的共性存在,才会有很多普适的架构思想出现...这些应用架构思想虽然很好,但我们很多同学还是“不讲Co德,明白了很多道理,可还是过不好这一生”。问题就在于缺乏实践和指导。COLA的意义就在于,他不仅是思想,还提供了可落地的实践。...API 是 Client SDK dto 服务对外的DTO 是 你可能会有疑问,为什么Domain的model是可选的?...最直接的方式,无外乎就是RPC调用商品和库存服务,拿到DTO直接使用就完了。 然而,商品域吐出的是一个大而全的DTO(可能包含几十个字段),而在下单这个阶段,订单所需要的可能只是其中几个字段而已。...更合适的做法,应该是在订单域中,使用gateway对商品域和库存域的依赖进行解耦。
跨语言通常有二种做法, 一是将其它语言转换成某种主流的通用语言,比如:delphi.net以前就是先将delphi转换成c#,然后再编译成IL,从而实现delphi在.net上的运行(好久没关注delphi...了,不知道现在还是不是这种机制) 二是先定义一种规范文件(可以简单的理解为『母版』),然后由特定的编译器,将『母版』直接编译成目标语言的源代码。...,大家可以打开看看,演示了主要用法,但我觉得还是有些小复杂,初学者一眼看上去有些乱,我按服务开发的常规场景,自己弄了二个小demo: 首先定义要传输的dto对象 dto.thrift namespace.../用于检测client-server之间通讯是否正常 string ping(), list getPersonList(1:dto.QueryParameter...java service.thrift 这样就把二个thrift【母版】文件生成了对应的java代码,生成的源文件会存放在当前工作目录的gen-java下,如果把-gen java换成-gen csharp
1.是throw还是try-catch 这个是一个对刚接触编程开发的人来说,经常面临但又选择不好的问题。 由于我们开发的项目可不是像写Demo一样轻松,这里可能会有很多层次结构。...我们要在具体哪一层的什么位置是使用try-catch这个异常呢,还是把异常throw到上一层呢?这里,我们首先要知道一件事,那就是try-catch和throw分别会发生什么情况呢?...图-1 try-catch测试结果 2.是使用受检的异常还是非受检的异常 首先我们要了解什么是受检异常和非受检异常,不过这里顾名思义,受检即接受检查。...在RuntimeException中则没有这样的限制。...,在此多说一句,AddressErrorCode错误码类存放了可能出现的错误码,更合理的做法是把他放到配置文件中进行管理。
在 Java 中,Lambda 表达式的格式是像下面这样 // 无参数,无返回值 () -> log.info("Lambda") // 有参数,有返回值 (int a, int b) -> { a...其实不止这两个,只要是在某个函数式接口中声明了这样的方法:两个参数,参数类型是 int或者泛型,并且返回值是 int或者泛型的,都可以完美接收。...而用函数式方式,是这样的。...functionDateFormat.run(LocalDateTime.now(),"yyyy-MM-dd HH:mm:ss"); 复制代码 而其实我可以不专门在外面定义 DateFormat这个方法,而是像下面这样...用于将一个类型转换成另外一个类型正合适,这也是 map的初衷所在,用于改变当前元素的类型,例如将 Integer 转为 String类型,将 DAO 实体类型,转换为 DTO 实例类型。
这其中尤其是@Data这个注解,会附带相当多的方法。 默认情况下,由于Jacoco不会区分Lombok生成的代码和正常的源代码。结果,在引入Lombok后就会发现,覆盖率通常会低得让人匪夷所思。...既然使用了Lombok,一个默认的前提就是Lombok是正确可靠的,为这些自动生成的代码进行单元测试不是一件高优先级的事情,还是放过已经996的码农和他们的头发吧,要爱护那些愿意写单元测试的好同志。...第二种方案也不可取,这会引入一个非常不好的开始,因为破窗效应,马上质量门禁也没有意义了。千万个教训告诉我们,千万不要去考验人性。...两种选择都没有意义,也都不可取,于是马上就有人想到了第三种方法 3 手工排除Bean 无论是Jacoco还是Sonar,都提供了exclude的方式,通过配置项来指定统计时排除某些特定的包或者类。...发布说明可以参见 https://github.com/jacoco/jacoco/pull/513 具体做法是,在项目的根目录下新建一个名字为lombok.config的文件,里面有如下的内容, config.stopBubbling
你不管看别人的程序也好,自己写程序练习也好,那必须要复杂,复杂到你不用设计模式就做不下去,这才能起到学习设计模式的作用。 这就是你为什么读了很多设计模式的书籍,却还是用不好设计模式的原因之一。...大多数书籍里面的例子都非常简单,比如形状啊、猫和狗啊什么的。当然,这样的例子可以帮助你快速理解设计模式的原理,但是现实情况是比这些例子复杂的多的多的真实情况。 问题2:用设计模式一定有很大的作用吗?...辩证的看问题,任何事物都有两面,有好的一面,也有不好的一面。设计模式也一样。不过,设计模式好的一面比不好的一面要大。 有一句话说的是,“历史在发生时未被发现,在发现时已被重组”。...),DO是领域对象(Domain Object),DTO是数据传输对象(Data Transfer Object),VO是视图对象(View Object)。...这四个对象分别隶属于不同的层,分层的目的之一是隔离关注点,这样每一层“只负责自己关心的事情”。 比如在DDD分层结构中,一般会分为基础层、领域层、应用层、用户接口层。
数据传输对象(Data Transfer Object,DTO) DTO是只包含属性和集合的对象或对象图。一个真正的DTO没有任何行为,而且几乎是不可变的。...虽然可以通过扩展让实体承担数据模型的角色,但在应用业务逻辑之前,将实体映射到单独的数据模型或DTO是更为常见的做法。...要访问它的唯一方法是将该对象转换成IDataErrorInfovariable。...这样做的原因如下: 验证规则涉及多个属性 验证规则涉及子对象 验证规则不会被其他类或属性重用 命令式验证的一个缺点是它只存在于服务器端,无法像使用基于属性的验证一样自动与UI共享验证逻辑。...理论上的验证接口 我认为.NET的验证接口应该看起来像这样: public interface IValidatable{ /// This forces the object to be completely
switch的控制,这是为了安全起见吧;但是简单的业务逻辑就会被我们下意识的认为不需要使用完整的DomainModel结构,还是使用传统的分层架构上层依赖下层,Business Layer直接依赖DataAccess...Layer,其实这个时候Business Object已经不在是遵循“单一职责”原则了,这样时间一长又慢慢的回到了以前肢解Object的困境; 这篇文章是讲解如何在Query端实践DDD,如何运用DDD...) 由于我们缺乏领域模型,所以导致我们的业务逻辑、规则随波逐流,无家可归,时间久了就搞不清到底这块业务逻辑是哪里的;我们现有的Domain Model是一个数据映射对象用来传递数据用的,严格意义是一个DTO...,或者并没有发挥其的核心作用;我们需要加入应用层来协调DomainModel的工作; 4.从数据扁平结构转换成OO体系结构(使用OO丰富代码结构) 当我们使用DTO对象成功将数据从数据源获取之后,就需要一个对象化的过程...注意:创建实体不像创建数据DTO那么简单; 3.规约、规约工厂: 对业务规则进行对象化,将原本淹没在杂乱无章代码中的核心业务规则提取出来统一管理;这可以很好的像规则配置化(专业称:规则外挂);注意:这可以和我们的业务开关进行合并
新功能介绍 Bug 修复 当项目的 context-path 配置为/的时候,之前处理的不好,会增加一个/。然后就导致去判断加解密 uri 的时候出现两个//。...GET 请求参数解密支持 在 1.2 之前的版本只支持 Post 请求体数据的解密操作,也就是说加密的数据必须在请求体里面才能被正常解密,如下: @Decrypt @PostMapping("/save...") public UserDto save(@RequestBody UserDto dto) { System.err.println(dto.getId() + "\t" + dto.getName...()); return dto; } 客户端提交的数据是加密的内容,到达接口层后 UserDto 已经是自动解密好了的数据。...这次干脆还是发布到 Maven 中央仓库得了,方便使用。
就在今年 Java 25周岁了,可能比在座的各位中的一些少年年龄还大,但令人遗憾的是,竟然没有我大,不禁感叹,Java 还是太小了。(难道我会说是因为我老了?) ?...在 Java 中,Lambda 表达式的格式是像下面这样 // 无参数,无返回值 () -> log.info("Lambda") // 有参数,有返回值 (int a, int b) -> { a...而用函数式方式,是这样的。...用于将一个类型转换成另外一个类型正合适,这也是 map的初衷所在,用于改变当前元素的类型,例如将 Integer 转为 String类型,将 DAO 实体类型,转换为 DTO 实例类型。...new UserDto(); BeanUtils.copyProperties(user, dto); //其他额外处理 return dto; } mapToInt 将元素转换成
消息包含动作和数据,而不是像 DTO 那样只包含数据本身。因此,我们可以在消息中携带特定域的动作,使后端更容易识别每个动作,并有一个相应的域实现。...在这个阶段,CQRS 中的 C 出现了,消息就是一种命令。然而,可扩展性问题仍未得到解决。 另外,虽然我们简化了 DTO,改为使用消息进行通信,但在读路径上我们仍然需要 DTO。还是以社交媒体为例。...这样一来,在读路径上,应用服务的实现变得更加简单。应用服务会成为一个很薄的读取层,只负责分页、排序等工作。发出请求后,客户端很容易从数据库中检索到 DTO。...因此,完整的解决方案是这样的: 左边的写路径和右边的读路径已经在 CQS 部分介绍过了。唯一的区别是增加了 Eventually,负责将写路径使用的数据库转换为读路径使用的数据库。...在数据写入主节点后,Redis 会立即在后台将数据发送到的副本中。 消息队列加工作者。这是异步数据复制的一种常见做法。在写入数据库时,会创建一个事件并发送到消息队列,然后由工作者处理。
,就是足够灵活了; 使用Map去接收请求传参时,不管是URL链接上的key、value值,还是通过Body传递的Json串,都能直接转换成Map,不管是有多复杂的Json串...;如果给你提供的RPC服务接口中采用的是Map传参,那就意味着,你在没有拿到详细的文档之前,是根本无法去做客户端调用的; 使用麻烦 存取值异常的麻烦,不管是客户端调用之前,还是服务端接收之后;赋值和取值的过程非常繁琐...、乱的问题 讨论的过程,还有人提到另一个问题,当所有的交互用对象传输,那岂不是要创建很多不同的对象;这同样也是体力活、还让项目变的更乱; 当不使用Map,实体类变多,这个是必然的;如果你不好好的管理,...确实会造成乱的问题,但是这些问题,只要稍微用点点心思,就不会成为问题了; 对象创建的体力活 很多交互DTO对象对象和数据库PO对象结构是相差无几的,所以必要的时候可以使出CV大法;并做一些简单的调整,就可以直接使用了...; Json转对象 安装JsonFormatPlus插件,就能轻松将Json格式的数据转换成实体对象; 完善项目结构 实体多导致项目乱,更多是因为目录不清晰、对象命名不规范导致的,正确的做法应该是对各个模块
点击上方“芋道源码”,选择“设为星标” 管她前浪,还是后浪? 能浪的浪,才是好浪! 每天 10:33 更新文章,每天掉亿点点头发......唯一的区别是在写路径上用消息代替了 DTO。消息包含动作和数据,而不是像 DTO 那样只包含数据本身。因此,我们可以在消息中携带特定域的动作,使后端更容易识别每个动作,并有一个相应的域实现。...在这个阶段,CQRS 中的 C 出现了,消息就是一种命令。然而,可扩展性问题仍未得到解决。 另外,虽然我们简化了 DTO,改为使用消息进行通信,但在读路径上我们仍然需要 DTO。还是以社交媒体为例。...这样一来,在读路径上,应用服务的实现变得更加简单。应用服务会成为一个很薄的读取层,只负责分页、排序等工作。发出请求后,客户端很容易从数据库中检索到 DTO。...因此,完整的解决方案是这样的: 左边的写路径和右边的读路径已经在 CQS 部分介绍过了。唯一的区别是增加了 Eventually,负责将写路径使用的数据库转换为读路径使用的数据库。
领取专属 10元无门槛券
手把手带您无忧上云