因 COVID-19 漫延各自居家，也更有闲时，便拣起一本关于算法的书籍来研究。本不是科班出身，算法方面自然是自己的薄弱环节。平时用各种 SDK，只大概听说了些算法，仅能就自己如何选择哪种实现而作为参考。
如今阅读的是一本入门的书籍，名为 《算法图解》，英文版书名是 《Grokking Algorithms》。 该书图文并茂，十分适合初学者，关于排序最基本莫过于冒泡与选择排序。该书并未提及冒泡，而是直接从选择排序切入，在阅读本书之前我就一直对这两咱排序方式傻傻不分。一直以为头脑中的选择排序就是冒泡排序，那就来看下什么是真正的冒泡排序。 Read More
前面从无到有或是分别以 Docker Desktop, Minikube, kind 来搭建过 Kubernetes 集群。而如今各大云服务提供商基本都推出了各自的 Kubernetes 服务，例如：- Google GKE - Google Kubernetes Engine
- Amazon EKS - Amazon Elastic Kubernetes Service
- Microsoft AKS - Azure Kubernetes Service
- IBM Cloud Kubernetes Service
- Alibaba Cloud Container Service
所以对 Kubernetes 的进一步学习过程中何不一跃而直上云霄，直接尝试 AWS 的 EKS 如何搭建。EKS 是在 2018 年 6 月份正式推出，见 Amazon Elastic Container Service for Kubernetes Now Generally Available。EKS 在 AWS 上是与 ECS 并列的服务，它们的功能也比较类似，都是伸缩性的容器服务，ECS 配置管理更分散，EKS 本身就是一个集群管理工具。它们也有些共同的东西，如 Auto Scaling Groups, Launch Templates。
现在用 Terraform 脚本来演示一下如何创建一个 EKS 集群，并启动三个 EC2 Worker 节点(EKS 也支持 Fargate Worker 节点)，并部署一个应用。Terraform 脚本将会列出完成该任务的基本要素，也将会看看背后发生了什么。 Read More- 在 Kubernetes 学习笔记(一) - 初上手 中一上手就尝试了最原始级的安装 Kubernetes 的方式，花了不少时间，好处是能更好的理解 Kubernete 的组成以及各节点是如何协同工作的。从《Kubernetes in Action》第二版中了解了几种简单的方法，为什么要把以下几种方式列出来呢？为了让看到上篇的同学们不至于对 Kubernetes 的安装过程望而却步。下面的前两种方式都是创立的单节点的 Kubernetes 集群。
一：启用 Docker Desktop 的 Kubernetes 特性
Docker Desktop 的 Community 版本从 18.06.0-ce-mac70 2018-07-25 开始加入了对 Kubernetes 的支持，在 2018-11-19 后，Docker Desktop 开始用 2.0.0.0 这样的版本。当前的 Docker Desktop Community 版是 2.2.0.4，所带的 Kubernetes 是 v1.15.5，要启用它只要进到它的Preferences..., Read More 
在进行数据流处理过程中，需要一个高效苗条的流处理组件，比如对输入流能进行分组(窗口)，能进行流量控制(Back Pressure - 背压)，这也就涉及到响应式编程，流处理框架。这方面如果直接基于 Akka actor 来构建 Akka ActorSystem 也是比较复杂，依赖的组件也不少。还有构筑在 Akka actor 之上的 Akka Streams，再往上的 Flink Streaming，它们都有像滑动，滚动窗口的概念，但是依赖更不得了。一个基本的 Flink Streaming 的项目会依赖到 45 M 以上的第三方组件，如果用它来写一个数据流处理的共享组件，那真是要命。Spring 5 也开始带上了自己的 Reactive-Streams 实现 Spring Reactor, 想要把它从 Spring 中单独抽离出也非易事。Flink Streaming 组件依赖：org.apache.fling:flink-streaming-java_2.12:1.80, 会依赖于其他诸如 akka-stream, akka-actor, flink-core, flink-clients, scala-library 等非常多的东西
而另一个著名的响应式框架 RxJava 2 就清爽多了，完全没有第三方依赖，要说有也就是定义了四个接口的 reactive-streams(2 KB 大小)，就自身那个 rxjava-2.2.9.jar 包只有 2.3 M，这才叫轻量级。因为它设计来是能被应用于 Android 客户端应用的，Andriod 上的 rxandriod-1.2.1.aar 只有 9 K。所以 RxJava 2.x 太适合用来写一些小的共享组件了。 Read More
在 Spring 中应用 ServiceLocator 方式来获取 Spring Bean 的介绍参考了那么多，其实还是数官方的 ServiceLocatorFactoryBean JavaDoc 文档最言简意该了。Spring 的 ServiceLocator 仿佛用处不大，说到底就是类似于下方找寻某个 Spring Bean 一样：
ApplicationContext context = ...; Service service = context.getBean(ServiceImpl.class); Service service = context.getBean("myService");
只是有了 ServiceLocatorFactoryBean(它本质上就是一个 FactoryBean) 后我们不需要直接与 ApplicationContext 打交道，且多个的 Spring Bean 可以从相关的一个 FactoryBean 获得。下面用两个例子来演示(代码中刨去了 package 和 import 部分的代码)
一：实现类只有一个 Spring Bean 时
接口类 Parser(我们要定位就是它的实现类) Read More
许久没记录笔记了，这回来重新熟悉一下 Spring 中 FactoryBean 的使用，顾名思义，它是用来获得相应 Bean 的工厂的。它与另一个 Spring 中的接口 BeanFactory 的作用不一样的，不能多说了。FactoryBean 和 BeanFactory 都是在
org.springframework.beans.factory包中，谁能一看类名搞清楚它们的差别？- FactoryBean: 用于创建某个特定的 Spring bean 的工厂类
- BeanFactory: Spring 上下文的最顶层接口，如
ApplicationContext就继承了该接口，它可称之为所有 Spring bean 的工厂
这儿说的是第一个 FactoryBean, 它的接口声明是
1public interface FactoryBean<T> { 2 T getObject() throws Exception; 3 Class<?> getObjectType(); 4 boolean isSingleton(); 5}它最终的效果是，Spring 容器中注册一个名称为 abcFactoryBean 的
AbcFactoryBean实例，通后名称abcFactoryBean获得的实际上是相应AbcFactoryBean.getObject()返回的对象，类型为getObjectType(),isSingleton()是否是单例。 Read More本文记录 SpringBoot 与 Logback 是如何工作的，即观察 SpringBoot 中 Logback 是怎么一步一步初始化的。用以测试的 SpringBoot 版本是 1.5.16, 而非最新的 SpringBoot 2。关于 SpringBoot 日志的官方文档在 Logging, 但不太详细或透彻。本文也不承诺说就理解得更有深度，只是为官方文档提供更多方面的参考。
SpringBoot 默认使用 Slf4J + Logback 来记录日志，对于一个基本的依赖于
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>的 Spring Boot 项目，上面组件依赖了 spring-boot-starter-logging 组件，而该组件又引入了以下几个依赖
- logback-classic: 依赖了 Slf4J
- jcl-over-slf4j
- jul-to-slf4j
- log4j-over-slf4j
相当于把其他的日志框架全桥接到了 Slf4J + Logback 上去了。 Read More
本站已启用新域名 yanbin.blog, 博客链接已更新为 https://yanbin.blog, 完全脱离了主流域名后缀了。其实也是不得已而为之，毕竟 unmi.cc 相伴多年。在接下来的一个多月里新老域名都同时有效，已作 301 重定向，希望搜索引擎能尽快切换过来。届时 unmi.cc 将会失效，也许是一个月，也许是永远，又将为互联网创建不少死链接。
本站自 2010 年独立创建以来，一直用的就是 unmi.cc 这个域名，从 bloghost.cn 上购买的。由于后来域名都是在 GoDaddy 管理的，所以想着域名 unmi.cc 转到一块进行管理。同时也是为了防备着国内互联网公司不光在主机服务上设限制，也可能会在域名上作起文章来。
于是试图联系 bloghost.cn, 于是便是中国特色了，假若要从 bloghost.cn 买新服务，他们还算和气，但想从他们那儿转出域名，没门。看他们的网站还号称专业
别一不小心反而给他们做了个广告，其实是真不值得信赖的。他们网站上的联系方式只有 E-mail 和几个 IM 聊天号，没有电话 Read More
在命名本文的标题都敲打了几分钟时间，问题很简单，然而用简短的一个标题完全描述出来却有点费事。在 Spring MVC 项目结合 Springfox 来生成 Swagger API 文档时，如果一个资源操作因为请求参数的不同而映射到多个 controller 方法，那么 Swagger 可能只能生成某一个 API 条目，其余都被忽略。至于为什么说是 "可能", 可能正好未遵循命名规范而躲过了这一劫。由此引出我们的问题
我们这里用了资源操作一词，它包含了两部分信息: 资源与操作，比如/users/{userId}是资源，而发生在其上的 HTTP 各种方法，如 POST, GET, PUT, DELETE 等就是操作。而 Spring MVC 中允许我们针对不同的查询参数把相同的资源操作映射到不同的 controller 方法上，也是为了保持逻辑上更为清晰。
比如下面的例子路由配置的例子GET /users/{userId} UserController.getUserInfo //默认
看到上面资源与操作完全相同，仅仅因为 source 查询参数的不同而映射到三个 controller 方法。用代码体现如下图 Read More
GET /users/{userId} UserController.getUserInfo //当有 ?source=file 时
GET /users/{userId} CloudUserController.getUserInfoFromCloud //当有 ?source=cloud 时
Scala 有一个自身类型(self-type) 的东西，由来已久，居然今天才发现。如果一个类或 trait 指明了 self-type 类型(包括类和特质)，它的子类型或是对象也必须是相应的类型。它产生的效果与继承(或 mixin) 颇有几分相似。self-type 的语法是this 的别名: 某一类型(class 或 trait), 直接看一个例子：1class User(val name: String) 2 3trait Tweeter { 4 this: User => //这个表示 Tweeter 本身也必须是一个 User，它的子类型必须想办法符合这一要求 5 def tweet(tweetText: String) = { 6 println(s"$name: $tweetText") 7 } 8} 9 10class VerifiedTweeter(val username: String) 11 extends User(username) with Tweeter { //Tweeter 要求这个类必须是一个 User, 所以需要继承自 User 类 12} 13 14val v = new VerifiedTweeter("Yanbin") 15v.tweet("Hello")
上面this: User =>中的this只是一个别名，可以是self或任何有效标识(如abc: User)，这里使用this等于未指定别名，与原本的 this 重叠了。如果声明为非this的话则可以这么用 Read More