optional

前言 if...else 是所有高级编程语言都有的必备功能。但现实中的代码往往存在着过多的 if...else。虽然 if...else 是必须的，但滥用 if...else 会对代码的可读性、可维护性造成很大伤害，进而危害到整个软件系统。现在软件开发领域出现了很多新技术、新概念，但 if...else 这种基本的程序形式并没有发生太大变化。使用好 if...else 不仅对于现在，而且对于将来，都是十分有意义的。今天我们就来看看如何“干掉”代码中的 if...else，还代码以清爽。 问题一：if...else 过多 问题表现 if...else 过多的代码可以抽象为下面这段代码。其中只列出5个逻辑分支，但实际工作中，能见到一个方法包含10个、20个甚至更多的逻辑分支的情况。另外，if...else 过多通常会伴随着另两个问题：逻辑表达式复杂和 if...else 嵌套过深。对于后两个问题，本文将在下面两节介绍。本节先来讨论 if...else 过多的情况。 1 if (condition1) { 2 3 } else if (condition2) { 4 5 } else if (condition3) { 6 7 } else if (condition4) { 8 9 } else { 10 11 } 通常，if...else 过多的方法，通常可读性和可扩展性都不好

与 Collection 源码比较 List 接口继承自 Collection 接口，从源码来分析List 的定义和两者提供的方法有什么区别。 /** * 有序集合，也称为序列。平时就叫列表。 * 该接口的用户可以精确控制列表中每个元素的插入位置。 * 用户可以通过其整数索引（列表中的位置）访问元素，并在列表中搜索元素。 */ public interface List< E > extends Collection< E > { // Query Operations /** * 返回此列表中的元素个数。 * 如果大于 Integer.MAX_VALUE 就返回 Integer.MAX_VALUE * 和 Collection 没区别 */ int size () ; /** * 如果此列表不包含任何元素就返回 true * 和 Collection 没区别 */ boolean isEmpty () ; /** * 如果此列表包含指定的元素就返回 true * 通常，当且仅当至少包含一个元素 e 满足 (o==null ? e==null: o.equals(e)) 返回 true * @throws ClassCastException 如果指定元素的类型与此列表不兼容就抛出此异常 * @throws NullPointerException 如果指定的元素是

澳大利亚国立大学（澳大利亚）校训：“重要的是弄清事物的本质。” 昨天因为加班耽搁了写文章，在此反思5分钟。。。。 今天要讲的是另一个Springboot核心机制，Spring自带的监控神器Actuator，集成非常简单，使用起来更是简单到爽歪歪，就是简单地rest接口调用查看，在要求不高的监控环境可以使用，如果需要可视化的监控推荐： Grafana 结合 prometheus 。 一 配置Actuator 1 引入Actuator起步依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> <version>2.1.3.RELEASE</version> <optional>true</optional> </dependency> 2 在application.properties中配置相关参数 #设置监控访问的应用根路径，默认是/actuator management.endpoints.web.base-path=/monitor #暴露监控访问接口，默认是/health和/info management.endpoints.web.exposure.include=* #显式屏蔽监控访问接口

在介绍 ReplicationController 之前，我们先思考一下下图所示的场景，Kubernetes集群包含2个Node，每个Node上均运行一个同类型的Pod来做负载均衡，如果其中某个Node被管理员强制关机或者Node意外宕机时，会发生什么呢？ 由于Pod被调度到某个Node后就与Node绑定，当Node宕机后，Node中的所有Pod也都停止运行。 上图所示场景中，Node2被关闭后，相应的Pod-2也会停止，Pod-2并不会重新被调度到Node1。 实际应用场景中，维持稳定的Pod副本数是非常必要的，因此Kubernetes引入了 ReplicationController 。 工作机制 ReplicationController 用于定义指定Pod的副本数，与创建多个Pod相比，它可以保证Pod意外终止后，集群中仍会有指定个数的Pod副本在运行。运行于 kube-controller-manager 组件中的 ReplicationController 控制器（控制器和资源名相同）会监控集群中Pod的副本数： 如果Pod数量已经超出预期，那么ReplicationController将会删除部分Pod，使Pod数量符合预期。 如果Pod数量低于预期，那么ReplicationController将会创建新的Pod，使用Pod数量符合预期。

系统安全绕不开PE文件，PE文件又与恶意样本检测及分析紧密相关。前文作者带领大家逆向分析两个CrackMe程序，包括逆向分析和源码还原。这篇文章主要介绍了PE文件基础知识及恶意样本检测的三种处理知识，手动编写代码实现了提取IAT表、二进制转字符串及获取PE文件时间戳，这是恶意样本分析和溯源至关重要的基础，并且网络上还没见到同时涵盖这三个功能且详细的文章，希望对您有所帮助。术路上哪有享乐，为了提升安全能力，别抱怨，干就对了~ 同时，PE文件基础知识推荐作者另一个安全系列： [网络安全自学篇] PE文件逆向之PE文件解析、PE编辑工具使用和PE结构修改 [网络安全自学篇] PE文件逆向之数字签名解析及Signcode、PEView、010Editor等工具用法 [网络安全自学篇] Windows PE病毒原理、分类及感染方式详解 从2019年7月开始，我来到了一个陌生的专业——网络空间安全。初入安全领域，是非常痛苦和难受的，要学的东西太多、涉及面太广，但好在自己通过分享100篇“网络安全自学”系列文章，艰难前行着。感恩这一年相识、相知、相趣的安全大佬和朋友们，如果写得不好或不足之处，还请大家海涵！ 接下来我将开启新的安全系列，叫“安全攻防进阶篇”，也是免费的100篇文章，作者将更加深入的去研究恶意样本分析、逆向分析、内网渗透、网络攻防实战等

在进行PE文件格式病毒分析的时候，经常要使用到PE文件格式的解析，尤其是对LoadPE形式的病毒的分析，经常要查看PE文件格式的偏移，特地从博客《 PE文件格式的偏移参考 》中转载收录一份，之前在网上也看到比较不错的有关PE文件偏移的博客，但忘了收录。在进行PE文件格式的病毒分析时，还会经常参考这篇博客《 PE文件格式学习笔记 》，博主关于PE文件格式的学习笔记写的不错，其他的参考书籍《加密与解密（第3版）》、《黑客免杀攻防》，顺便提一句《黑客免杀攻防》这本书关于PE文件格式的解析比较不错，但是错误也不少，整体来说这本书对于学习PC上的逆向分析和内核攻防还是很不错的。 Complete PE Offset Reference While there is a lot of data and various parts of the structure are at varying positions there are still a lot of useful fixed and relative offsets that will help when disassembling/examining PE files. Resource information and the such like are omitted - there are good tools

# Logs logs *.log npm-debug.log* yarn-debug.log* yarn-error.log* # Runtime data pids *.pid *.seed *.pid.lock # Directory for instrumented libs generated by jscoverage/JSCover lib-cov # Coverage directory used by tools like istanbul coverage # nyc test coverage .nyc_output # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) .grunt # Bower dependency directory (https://bower.io/) bower_components # node-waf configuration .lock-wscript # Compiled binary addons (https://nodejs.org/api/addons.html) build/Release # Dependency directories node_modules/ jspm_packages/

前言 ​ 最近公司里比较新的项目里面，看到了很多关于java8新特性的用法，由于之前自己对java8的新特性不是很了解也没有去做深入研究，所以最近就系统的去学习了一下，然后总结了一篇文章第一时间和大家分享一下。 ​ ​ 在了解一项新技术之前，我们需要了解我们为什么要去学习它以及它的优点，以下是我总结的： Java8（又称jdk1.8）是java语言开发的一个主要版本，Java8是oracal公司于2014年3月发布，可以看成是自java5以来最具有革命性的版本。 **新特性的优点：**速度更快、代码更少、便于并行、最大化减少空指针异常 函数式编程提供了一种更高层次的抽象化 排序： List<RoleEntity> rolesListSort = rolesList.stream().sorted(Comparator.comparing(RoleEntity::getCreateDate)).collect(Collectors.toList()); Consumer是一个函数式接口 参数是Consumer类型的，Consumer里面的泛型表示泛型的类型要么是Integer,要么是Integer的父类，super表示它及它上面的，也就是父类。 下面这段代码是在Iterable接口里面的默认方法，jdk8之后的新方法，默认方法（默认方法的引入很大程度上是为了保证向后兼容）

你会发现collect是一个归约操作，就像reduce一样可以接受各种做法作为参数，将流中的元素累积成一个汇总结果。 具体的做法是通过定义新的Collector接口来定义的，因此区分Collection、Collector和collect是很重要的。 下面是一些查询的例子，看看你用collect和收集器能够做什么。 对一个交易列表按货币分组，获得该货币的所有交易额总和（返回一个Map<Currency, Integer>）。 将交易列表分成两组：贵的和不贵的（返回一个Map<Boolean, List<Transaction>>）。 创建多级分组，比如按城市对交易分组，然后进一步按照贵或不贵分组（返回一个Map<Boolean, List<Transaction>>）。 Java8之前：用指令式风格对交易按照货币分组 Map<Currency, List<Transaction>> transactionsByCurrencies = new HashMap<>(); for (Transaction transaction : transactions) { Currency currency = transaction.getCurrency(); List<Transaction> transactionsForCurrency =

1. 基本数据结构 　　和pytorch等中的tensor类似，mxnet中的ndarray或者nd，用来操作矩阵或者张量数据。基本操作类似于Numpy， 支持计算，索引等。 创建矩阵 from mxnet import nd #或者 from mxnet import ndarray as nd #创建矩阵 x1 = nd.array([[ 1 , 2 ,], [ 3 , 4 ]]) x2 = nd.random.uniform( 1 , 10 , shape=( 3 , 3 )) # 3 * 3的矩阵 x3 = nd.random.randn( 2 , 3 ) # 2 * 3 的矩阵 x4 = nd.random.randint( 1 , 10 , shape=( 2 , 3 )) # 2 * 3 的矩阵 x5 = nd.ones(shape=( 2 , 2 )) # 2 * 2 的矩阵 x6 = nd.full(shape=( 2 , 3 ), val= 2 ) # 2 * 3 的矩阵, 值为2 print(x1.shape, x1.size, x1.dtype) #( 2 , 2 ) 4 < class ' numpy.float32 ' > 　　操作矩阵 x = nd.random.randn( 2 , 3 ) y = nd.random.randn( 2 , 3 )