Joe主题-顶部大图教程 效果图：{tabs}{tabs-pane label="首页"} {/tabs-pane}{tabs-pane label="文章页"} {/tabs-pane}{/tabs}先给首页顶部加一个大图{mtitle title="第一步"/}修改 index.php 文件，文件目录 Joe主题文件/index.php 下面两个是我推荐的，放在图片地址里即可同步侧边栏博主背景壁纸代码： <?php $this->options->JAside_Author_Image() ?>随机二次元图片API：https://api.ghser.com/random/pc.php{tabs}{tabs-pane label="代码"}<div class="HeaderImg" style="background: url(这里填写你的图片地址) center;background-size:cover;"> <div class="infomation"> <div class="title"><?php $this->options->title(); ?></div> <div class="desctitle"> <span class="motto joe_motto"></span> </div> </div> <section class="HeaderImg_bottom"> <svg class="waves-svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 24 150 28" preserveAspectRatio="none" shape-rendering="auto"> <defs> <path id="gentle-wave" d="M -160 44 c 30 0 58 -18 88 -18 s 58 18 88 18 s 58 -18 88 -18 s 58 18 88 18 v 44 h -352 Z"></path> </defs> <g class="parallax"> <use xlink:href="#gentle-wave" x="48" y="0"></use> <use xlink:href="#gentle-wave" x="48" y="3"></use> <use xlink:href="#gentle-wave" x="48" y="5"></use> <use xlink:href="#gentle-wave" x="48" y="7"></use> </g> </svg> </section> </div>{/tabs-pane}{tabs-pane label="代码位置"} {/tabs-pane}{/tabs}{mtitle title="第二步"/}在后台引入下面的CSS文件{tabs}{tabs-pane label="CSS文件"}https://cdn.yize-api.ltd/css/sudt.css{/tabs-pane}{tabs-pane label="引入位置"} {/tabs-pane}{/tabs}再给文章顶部加一个大图友情提示：文章顶部图显示规则写成了与首页文章列表一样获取，会自动显示文章里的第一张图，文章无图的情况下会自动显示你后台设置的自定义缩略图，在后台图片设置选项添加，或者你也可以更换自己的api图库自行更换图库方法：下面第一行代码中的 <?php echo _getThumbnails($this)[0] ?> 换成自己的图片地址即可{mtitle title="配置方法"/}修改post.php文件，文件目录Joe主题文件/post.php{tabs}{tabs-pane label="代码"}<div class="HeaderImg" style="background: url(<?php echo _getThumbnails($this)[0] ?>) center;background-size:cover;"> <div class="infomation"> <div class="title"><?php $this->title() ?></div> <div class="desctitle"> <div class="item"> <span class="text"><?php $this->date('Y-m-d'); ?></span> <span class="line">/</span> <span class="text"><?php $this->commentsNum('%d'); ?> 评论</span> <span class="line">/</span> <span class="text" id="Joe_Article_Views"><?php _getViews($this); ?> 阅读</span> <span class="line">/</span> <span class="text" id="Joe_Article_Views"><?php _getAgree($this) ?> 点赞</span> </div> </div> </div> <section class="HeaderImg_bottom"> <svg class="waves-svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 24 150 28" preserveAspectRatio="none" shape-rendering="auto"> <defs> <path id="gentle-wave" d="M -160 44 c 30 0 58 -18 88 -18 s 58 18 88 18 s 58 -18 88 -18 s 58 18 88 18 v 44 h -352 Z"></path> </defs> <g class="parallax"> <use xlink:href="#gentle-wave" x="48" y="0"></use> <use xlink:href="#gentle-wave" x="48" y="3"></use> <use xlink:href="#gentle-wave" x="48" y="5"></use> <use xlink:href="#gentle-wave" x="48" y="7"></use> </g> </svg> </section> </div>{/tabs-pane}{tabs-pane label="代码位置"} {/tabs-pane}{/tabs}

简单使用GitHub Actions来实现CI/CD CI：持续集成 (Continuous Integration)CD：持续交付 (Continuous Delivery)CD：持续部署 (Continuous Deployment)GitHub Actions是GitHub提供的持续集成服务GitHub Actions官方文档：https://docs.github.com/en/actionsworkflow：工作流程，指一次持续集成的流程，由一个job或者多个job组成Events：事件，触发流程的钩子（在github中事件为检测仓库特定活动的钩子，例如pull，当事件被触发则自动执行工作流程）Job：任务，任务是工作流程的主体Steps：步骤，每个Job可以包含一个或多个StepActions: 行为，每个Step包含一个或多个ActionRunners: 执行环境，工作流程运行时的服务端，每一个执行环境可以运行一个任务workflow工作流程通过编写workflow文件来描述，workflow文件要使用YAML语言编写，github支持多个workflow（当github发现.github/workflows/目录下有.yml文件时就会执行该文件）在仓库的.github/workflows/目录下创建test.yml，其中要配置字段name：workflow名称，如果省略默认为当前workflow的文件名on：指定触发workflow的条件，一般为事件触发（比如说push）jobs：每一项任务都需要定义个job_id，job中的name为该任务的描述，needs为指定当前任务的运行顺序（依赖关系），runs-on为指定运行时需要的虚拟机环境（这个字段必须填）目前github支持的虚拟机操作系统有ubuntu，windows，macOS，而且github提供的虚拟机是免费使用的这里举个例子（github官方的）name: GitHub Actions Demo on: [push] jobs: Explore-GitHub-Actions: runs-on: ubuntu-latest steps: - run: echo " The job was automatically triggered by a ${{ github.event_name }} event." - run: echo " This job is now running on a ${{ runner.os }} server hosted by GitHub!" - run: echo " The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}." - name: Check out repository code uses: actions/checkout@v2 - run: echo " The ${{ github.repository }} repository has been cloned to the runner." - run: echo " The workflow is now ready to test your code on the runner." - name: List files in the repository run: | ls ${{ github.workspace }} - run: echo " This job's status is ${{ job.status }}."

动态简历源码 最近发现了一个很炫酷的动态简历页面源码下载：隐藏内容，请前往内页查看详情简历内容在dist/resume.js里修改(从2188行开始)

简单使用Hugo搭建网站 Hugo是基于Go语言开发的静态网站生成器，特点就是快安装二进制文件安装（由官方编译完成的二进制文件来安装，推荐使用，用源码容易出现问题）https://github.com/gohugoio/hugo/releases源码安装git clone https://github.com/gohugoio/hugo.git cd hugo go install检查是否安装完成 hugo -v，如果需要支持SASS/SCSS，请添加--tags extended参数，不过在这之前需要CGO的依赖（或者使用hugo_extended版本）如果没安装CGO，请先安装CGO，这里使用的是mingw64，CGO_ENABLED环境变量为1生成站点hugo new site ./www创建文章（默认自动生成md文件到content文件夹中，可选择目录）hugo new post/hallo.md如果没有显示文章的话，请将文章的draft字段改为false，因为这个是草稿，草稿是不会显示在页面上的安装主题git clone https://github.com/miiiku/hugo-theme-kagome.git ./themes/kagome修改config.toml文件baseURL = 'https://blog.tencent-qq.cn' languageCode = 'zh-CN' title = '绎泽小窝' theme = "kagome"启动Hugo服务器hugo server访问http://localhost:1313如果报错，you need the extended version to build SCSS/SASS的话，请使用extended版本部署到github pageshugo --baseUrl="http://yizeblog.github.io/"如果该命令执行成功，会将静态页面生成到public文件夹中，只需要push该文件夹到github上就好了

为什么数据库连接池不采用 IO 多路复用？ 今天我们聊一个不常见的 Java 面试题：为什么数据库连接池不采用 IO 多路复用？这是一个非常好的问题。IO多路复用被视为是非常好的性能助力器。但是一般我们在使用 DB 时，还是经常性采用c3p0`tomcat connection pool等技术来与 DB 连接，哪怕整个程序已经变成以Netty`为核心。这到底是为什么？首先纠正一个常见的误解。IO多路复用听上去好像是多个数据可以共享一个IO（socket连接），实际上并非如此。「IO多路复用不是指多个服务共享一个连接，而仅仅是指多个连接的管理可以在同一进程」。在网络服务中，IO多路复用起的作用是「一次性把多个连接的事件通知业务代码处理」。至于这些事件的处理方式，到底是业务代码循环着处理、丢到队列里，还是交给线程池处理，由业务代码决定。对于使用DB的程序来讲，不管使用多路复用，还是连接池，都要维护一组网络连接，支持并发的查询。为什么并发查询一定要使用多个连接才能完成呢？因为DB一般是使用连接作为Session管理的基本单元。在一个连接中，SQL语句的执行必须是串行、同步的。这是由于对于每一个Session，DB都要维护一组状态来支持查询，比如事务隔离级别，当前Session的变量等。只有单Session内串行执行，才能维护查询的正确性（试想一下一组sql在不断的增减变量，然后这组sql乱序执行会发生什么）。维护这些状态需要耗费内存，同时也会消耗CPU和磁盘IO。这样，限制对DB的连接数，就是在限制对DB资源的消耗。因此，对DB来说，关键是要限制连接的数目。这个要求无论是DB连接池还是NIO的连接管理都能做到。这样问题就绕回来了，为什么DB连接不能放到IO多路复用里一并执行吗？为啥大家都用连接池？答案是，可以用IO多路复用——但是「使用JDBC不行」。JDBC是一个出现了近20年的标准，它的设计核心是BIO（因为199X年时还没有别的IO可以用）：调用者在通过JDBC时执行比如query这样的API，在没有执行完成之前，整个调用线程被卡住。而类似于Mysql Connector/J这样的driver完备的实现了这套语义。当然如果DB Client的协议的连接处理和解析稍微改一下：将IO模式调整为Non-Blocking，这样就可以挂到IO多路复用的内核上（select、epoll、kqueue……）在Non-Blocking实现的基础之上实现数据库协议的编码和解析就可以实现用IO多路复用来访问DB。实际上很多其他语言/框架里都是这么干的。比如 Nodejs，see https://github.com/sidorares/node-mysql2；或者 Vert.X 的 db 客户端https://github.com/mauricio/postgresql-async，不要在意这个名字，它实际上同时支持mysql和postgres）。只不过对于IO多路复用，数据库官方似乎都没做这种支持——他们只支持JDBC、ODBC等等这些标准协议。当然如果DB Client的协议的连接处理和解析稍微改一下：将IO模式调整为Non-Blocking，这样就可以挂到IO多路复用的内核上（select、epoll、kqueue……)在Non-Blocking实现的基础之上实现数据库协议的编码和解析就可以实现用IO多路复用来访问DB。实际上很多其他语言/框架里都是这么干的。比如 Nodejs，see https://github.com/sidorares/node-mysql2；或者 Vert.X 的 db 客户端https://github.com/mauricio/postgresql-async，不要在意这个名字，它实际上同时支持mysql和postgres）。只不过对于IO多路复用，数据库官方似乎都没做这种支持——他们只支持JDBC、ODBC等等这些标准协议。那么为什么基于 IO 多路复用的实现不能成为默认的，官方的，而要成为偏门呢？对于数据库开发者来说。这种用法在整体的用户里占有量非常小，所以也许不值当的花大力气。只需要把协议写清楚（比如https://dev.mysql.com/doc/internals/en/client-server-protocol.html），就可以做实现。那么社区的有兴趣的人自然就可以去做。另外一个原因是体系的支持。简单来讲，如果没有一个大的 Reactive 的运行环境，IO 多路复用的使用会非常受限。IO 多路复用之所以能成立，是需要「整个程序要有一个IO多路复用的驱动代码」——就是 select 那句调用——等待事件来临，一个 blocking 的 API。整个程序必须以这个驱动代码为核心。这样就对整个代码的结构产生重大的影响。这种影响是没法用简单的接口抽象的。Java Web 容器之所以可以使用 NIO 是因为 NIO 可以被封装到容器内部。Web 容器对外暴露的还是传统的多线程形式的Java EE接口。如果 DB 和 Web 容器同时使用 NIO，那么调用的DB连接库与必须与容器有一个约定描述「DB的连接管理如何接入Web容器的NIO的驱动代码」。在 Java 这个大环境下，不同人，不同的容器写的代码不同；又或者，不使用任何常见的容器，而是自己用 NIO 去封装一个。这样是无法形成代码上的约定的。那么多个独立的组件就不能很好的共享 NIO 的驱动代码。上面这个用法假设整个程序应该共享一个 NIO 驱动代码。那么 Web 和 DB 可不可以各用各的呢？也是可以的，但是为了保证这两个 NIO 驱动代码不会相互 block，最好要分开两个线程。这样一来就会打破一般 Web 服务一个请求处理用一个线程的一般做法，会让程序边的更复杂——你的业务代码和DB查询之间必须做跨线程数据交换。相反，连接池的实现就相对独立的多，也简单的多。外界只要配好 DB URL，用户名密码和连接池的容量参数，就可以做到自行管理连接。而Nodejs和Vert.X是完全不同的。他们本质就是Reactive的。他们的NIO的驱动方式是其运行时的基础——所有要在这个基础上开发的代码都必须遵守同样的NIO+异步开发规范，使用同一个NIO的驱动。这样DB与NIO的协作就不成问题了。最后，「有大量场景是需要BIO的DB查询支持的」。批处理数据分析代码都是这样的场景。这样的程序写成NIO就会得不偿失——代码不容易懂，也没有任何效率上的优势。类似于Nodejs这样的运行时在此场景下，反而要利用async或等价的语法来让代码看起来是同步的，这样才容易写。总结一下。DB 访问一般采用连接池这种现象是生态造成的。历史上的 BIO + 连接池的做法经过多年的发展，已经解决了主要的问题。在 Java 的大环境下，这个方案是非常靠谱的，成熟的。而基于 IO 多路复用的方式尽管在性能上可能有优势，但是其对整个程序的代码结构要求过多，过于复杂。当然，如果有特定的需要，希望使用 IO 多路复用管理 DB 连接，是完全可行的。