9t

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 简单参数验证 使用spring mvc，可以使用默认提供的注解进行参数验证，下面我们用一个简单的示例列进行说明 实体类Passenger中的NotEmpty要加在field上，所以要使用 @get :NotEmpty import java.time.LocalDateTime import javax.validation.constraints.NotEmpty data class Passenger(val id: Int, //较验参数非空字符串 @get:NotEmpty(message = "用户名不能为空") val name: String, var birthday: LocalDateTime ) 添加一个CommonResult来返回操作状态 data class CommonResult<T>( var data: T?, var succes: Boolean, var msg: String ){ constructor():this(null,false,"") } Action上要使用@Valid启用验证，否则是不生效的，下面这段我们没有加，就会不生效 @PostMapping("p/add") fun addPassenger(@RequestBody p:Passenger

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 这节主要介绍下集成spring 1.修改上一节中的AppleConverter，给@Mapper添加componentModel字段赋值为spring @Mapper(componentModel = "spring") abstract class AppleConverter {} 2.这么easy就可以使用了 @RestController class MyController{ @Autowired lateinit var appleConverter: AppleConverter @GetMapping("/hello") fun sayHello():String{ val apple = Apple(1,"my apple",true) println(apple) val appleDto = appleConverter.convertToDto(apple) println(appleDto) val appleModel = appleConverter.convertToModel(appleDto) println(appleModel) return "hello" } } 3.访问一下输出，跟我们期待的效果一样 Apple(appleId=1, appleName=my

在上一篇文章 《搭建高可用MongoDB集群（一）——配置MongoDB》 提到了几个问题还没有解决。 主节点挂了能否自动切换连接？目前需要手工切换。 主节点的读写压力过大如何解决？ 从节点每个上面的数据都是对数据库全量拷贝，从节点压力会不会过大？ 数据压力大到机器支撑不了的时候能否做到自动扩展？ 这篇文章看完这些问题就可以搞定了。NoSQL的产生就是为了解决大数据量、高扩展性、高性能、灵活数据模型、高可用性。但是光通过主从模式的架构远远达不到上面几点，由此MongoDB设计了副本集和分片的功能。这篇文章主要介绍 副本集 ： mongoDB官方已经 不建议使用主从模式 了，替代方案是采用副本集的模式， 点击查看 ，如图： 那什么是副本集呢？打魔兽世界总说打副本，其实这两个概念差不多一个意思。游戏里的副本是指玩家集中在高峰时间去一个场景打怪，会出现玩家暴多怪物少的情况，游戏开发商为了保证玩家的体验度，就为每一批玩家单独开放一个同样的空间同样的数量的怪物，这一个复制的场景就是一个副本，不管有多少个玩家各自在各自的副本里玩不会互相影响。 mongoDB的副本也是这个，主从模式其实就是一个单副本的应用，没有很好的扩展性和容错性。而副本集具有多个副本保证了容错性，就算一个副本挂掉了还有很多副本存在，并且解决了上面第一个问题“主节点挂掉了，整个集群内会自动切换”

写在前面 之前两篇文章是去年调研和自研规则引擎的存货，今天是最后一篇，后记。 有人会问，标题不是写的动手撸吗？哪里体现撸了？ 其实撸起来一个引擎并不复杂，为了体现架构思想，调研心得和设计思想反而更重要，相信优秀如你写代码没有任何压力的。 那我就和大家聊聊业务背景和引擎要求。 设计思想 场景 比如[券表]，对于字段属性有一定的规则要求，比如券的互斥属性需要做一定的校验，比如change-config是个json，需要进行解析之后和detail信息做规则校验，等其他的一些规则。 梳理出来的需要主要设计到字段属性的处理，而没有涉及到复杂的流程，数据问题的处理。 核心 定义规则； 确定规则边界； 规则 字段规则，涉及到字段长度，某些信息(地理围栏信息)需要逆向校验是否准确。 流程规则，需要根据不同参数规则进行不同分支流程。 变更频繁，某些业务场景存在每个月规则变化的需求。 举例 字段规则，比如实体字段长度，地理围栏信息。 流程规则，不同来源数据进行不同的规则校验。 校验 规则：业务实体信息校验，采用字段校验规则。 校验：需要配置对应字段的规则，比如名称字段长度，地址位置和经纬度是否一致。 方案调研 硬编码：适用于规则不易变场景。 优点 逻辑简单，易于理解，开发效率高，编码可以由编译器保证。 缺点 迭代成本高可维护性差，规则变更需要发版，上线周期较长，如果代码繁杂需要原RD介入。

本教程介绍如何使用Liquid侧链的c-lightning来创建闪电支付通道。使用这些支付通道，用户可以实时、私有地交易Liquid-BTC。 Liquid网络包含有对私密交易和资产发行的支持，因此用户可以使用闪电支付通道交易任何在Liquid网络上发行的资产，例如通证化的发币、加密资产等等。另外，对链上BTC和支付通道L-BTC的兑换的支持工作也在进行中。 使用Liquid网络上的c-lightning和比特币主网上流程一样，因此如果你熟悉哪些步骤的话，这个教程就会很容易 —— 虽然本来就是件容易的事。 1、软件安装 首先我们需要一个同步的比特币节点和一个同步的Elements节点，才能在Liquid侧链上开启闪电支付通道。你可以参考以下链接安装bitcoin节点软件和elements节点软件： bitcoin core： https://elementsproject.org/elements-code-tutorial/installing-bitcoin elements： https://elementsproject.org/elements-code-tutorial/installing-elements 一旦两个节点都完成同步，安装了必须的依赖： ~$ sudo apt-get install -y \ autoconf automake build