冬天温泉的小庭院

要为了给 WSL 的 Ubuntu 设置代理，需要进行以下步骤。

系统的全局代理设置

在 ~/.bashrc 文件中追加如下系统变量。

1
2
3
4

export http_proxy="<proxy_url>:<port>"
export https_proxy="<proxy_url>:<port>"
export HTTP_PROXY="<proxy_url>:<port>"
export HTTPS_PROXY="<proxy_url>:<port>"

之后 wget、curl 等工具应该就可以使用了。

apt 的设置代理

在 /etc/apt/apt.conf 文件中追加如下设置。

1
2

Acquire::http::Proxy "<proxy_url>:<port>";
Acquire::https::Proxy "<proxy_url>:<port>";

不要忘了每行后的分号。

（Option）docker 的代理设置

通过 curl -fsSL https://get.docker.com/ | sh 安装 docker。

在 /etc/systemd/systemd/docker.service.d/http-proxy.conf 文件中追加如下设置。

1
2
3
4

[Service]
Environment="HTTP_PROXY=<proxy_url>:<port>"
Environment="HTTPS_PROXY=<proxy_url>:<port>"
Environment="NO_PROXY=localhost,127.0.0.1"

之后在 docker 里面就可以使用 apt update 等命令了。

之前部署的博客服务 Heroku，它在今年11月28日起就不在提供免费的 Heroku Dynos了，虽然它之后还发布消息说提供了一个 eco plan 跟 mini plan–但是还得花钱–总之就是它不会提供免费的 dyno 了。对于像几乎没啥流量的网站（没错说的就是现在看到的这个网站）得给换另一个地方，要不然就要自己买 VPS 搭建服务了。还好找了一圈发现还有 Vercel 提供免费的额度使用，在迁移到 Vercel 的同时顺便升级了一下 hexo 跟使用的主题 theme-next。主题的配置文件还挺老了升级的时候还花了不少时间。

迁移过程还是挺顺利的，

• 注册账号
• 关联相关Git库，支持从Github的私有库进行部署
• 配置项目，它自动识别出来是 hexo，直接用它提供的默认配置即可
• 完毕
• (option)使用自己的域名的话在 Domains 配置即可，并且还自动配置 https

而部署到 Heroku 的话，

• 安装它的 CLI 工具
• 在命令行中敲命令
• (option)绑定自定义域名还算是方便但免费的 dyno 是不支持开启 https

跟 Vercel 提供的服务相比这简直就是上个世纪的东西。

后知后觉 next.js 也是由 Vercel 开发的。

另外还可以选择 Render，部署方式跟 Vercel 一样简单，免费的额度也够用了。

最後に、Heroku さん、お疲れ様でした。

Caddy 是一个用 go 语言写的代理服务，类似 Nginx 但是从配置文件来说比 NGX 要方便不少，并且自带 https 的支持以及到期自动续期。
话不多说用 SpringBoot 的项目来举个如何部署项目的例子。

• 上 Caddy 的官网 下载 编译好的二进制文件，注意选择部署的机器。
  想自己编译的话也可以从 Github 把代码下回来自己编译。
• 下载回来的文件「caddy」放到服务器上，然后设置该文件权限为「744」chmod 744 ./caddy。运行 ./caddy help 确认该文件可执行。
• 在「caddy」的同目录下生成配置文件「Caddyfile」（该配置文件所在目录可按需求修改，为了方便部署这次是在同目录下生成）。
  文件内容根据下面给出的注释进行修改。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

  { # 全局配置，关闭 admin endpoint admin off } # 需要部署的端口号，支持域名。不需要用默认的HTTPS的证书的话需要单独配置HTTPS证书 :8300 { # 前端编译后代码所在目录，这里 SpringBoot 使用的是前后端分离的方式 root * /home/www-user/opt/springboot-vue-dist # 代理前端所有「/api」的请求 handle_path /api/* { # 「apicontext」是 SpringBoot 项目的 context-path rewrite * /apicontext/{path} # 需要代理到的IP以及端口号 reverse_proxy http://localhost:8080 } # 开启压缩 encode gzip # 固定写法（？？） file_server }

• 运行 ./caddy adapt --config ./Caddyfile 查看配置文件是否有问题。
• 运行 ./caddy start --config ./Caddyfile 让其在后台运行。
• 其他命令请参照官方文档。

EOL

下载树莓派版本的ubuntu

https://ubuntu.com/download/raspberry-pi

我推荐选择 Server 版本，树莓派2 的话只能用 32 位的版本。如果要用 Desktop 版的话当前的 21.04 只支持 树莓派4 跟 400。

烧录 img 到 SD 卡

参考 Installing operating system images 这篇文章，windows下的话是用这三个软件 balenaEtcher（有免安装版本）、Win32DiskImager、Upswift imgFlasher 即可。

启动前的设置

烧录好的SD卡的卷名为 system-boot。

需要设置wifi连接的话在这里面找到名为 network-config 的文件，在最下方添加如下内容。

1
2
3
4
5
6
7
8
9
10
11
12

wifis:
  wlan0:
    dhcp4: true
    optional: true
    #addresses: [192.168.1.XX/24] #设定的IP
    #gateway4: 192.168.1.1 #网关地址
    #nameservers:
    #  addresses: [192.168.1.1] #网关地址相同
    #  search: []
    access-points:
      "WIFI名":
        password: "wifi密码"

注意缩进。

登录的用户名密码在 user-data 文件中查看，默认都为 ubuntu。
第一次登录后提示需要修改密码，对密码强度有要求。
如果不想更改，把 23 行附近的 expire 改成 false。

1
2

chpasswd:
  expire: false

使用前的设置

• 计算机名的修改在 /etc/hostname 文件中，修改后用 hostnamectl 命令查看输出的第一行。
• 通过命令 sudo timedatectl set-timezone Asia/Shanghai 修改时区，其他时区的话修改对应的城市即可。
• 运行 sudo apt update && sudo apt upgrade -y 进行升级。
• 运行 sudo shutdown -r now 重启。

把 hexo 更新到最新版（3.9.0）之后，在运行 hexo deploy --generate 发现无法部署，控制台提示如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

!     ERROR: Application not supported by 'heroku/nodejs' buildpack
!     
!     The 'heroku/nodejs' buildpack is set on this application, but was
!     unable to detect a Node.js codebase.
!         
!     A Node.js app on Heroku requires a 'package.json' at the root of
!     the directory structure.
!     
!     If you are trying to deploy a Node.js application, ensure that this
!     file is present at the top level directory. This directory has the
!     following files:
!     
!     index.php
!     Procfile
!     public/
!         
!     If you are trying to deploy an application written in another
!     language, you need to change the list of buildpacks set on your
!     Heroku app using the 'heroku buildpacks' command.
!         
!     For more information, refer to the following documentation:
!     https://devcenter.heroku.com/articles/buildpacks
!     https://devcenter.heroku.com/articles/nodejs-support#activation
      More info: https://devcenter.heroku.com/articles/buildpacks#detection-failure
!     Push failed

然后看了一下 .deploy_heroku 文件夹里的 Procfile 文件，这是已经从原来的 nodeje 项目变成了 nginx 的了？？这跟之前运行时环境不一样，造成了部署无法成功。

看了控制台出现的那两链接，以及 stackoverflow 的回答，需要把原来的 buildpack 给删掉，之后再部署就行了。那么就好办了

1
2

heroku buildpacks:remove heroku/nodejs -a APP
hexo deploy --generate

结束。

因为需要修照片用，手上 2010 年 11 月买的戴尔 Inspiron 14R 5420 现在来看实在是太为难它了，而在之前配的吃鸡电脑因为各种原因留在国内，因此在某次发了工资之后就开始研究买啥电脑了。

因为住的地方比国内要小不少，本着节省空间来考虑打算买台游戏本来着，看了一圈发现要来个 1070 显卡的都要 1w3 左右（Orz。在发出人类科技或许被智子封锁了的感叹后，无意中开始看起了 imac –反正修图都是丢到 lightroom 跟 photeshot 里用 Mac 也没什么不妥，然后在看 B 站时无意看到翼王的 Mac Pro 2009 款改造的视频后，本着看看的原则上雅虎日拍搜索了一下，这配置一般的 Mac Pro 都不算贵啊，要不直接来台 Mac Pro 好了。花了点时间了解各种型号的差别，直接就买了这台双 CPU 款的 Mac Pro 2010。

稍微介绍一下 java 处理 log 的东西

特别是 slf4j 的种类太多，或许也没有人能很好的说明各自用处。产生混乱的原因有七成是由 slf4j 造成的。这种混乱的局面进行了简单整理。主要分为三个类型的 jar。

1、 接口（Interface）

主要有这些

• commons-logging
• slf4j

他们也就只提供了接口的功能，并没实现 log 的输出功能。
接口要是太老的话，自己提供的功能也会有不足的地方。这些 jar 虽然含有有 log 输出的功能，但只是简单的实现。

2、 适配器(Adapter)

主要有这些

• jcl-over-slf4j.XXX.jar（把 commons-logging 的处理交给 slf4j 来处理）
• jul-to-slf4j.XXX.jar（把 java.util.logging 的处理交给 slf4j 来处理）
• log4j-over-slf4j.XXX.jar（把 log4j 的处理交给 slf4j 来处理）

适配器的作用是，代理各接口与实际处理 logger 的任务。从外部看起来都是相同的方法，但是内部却是各自来实现自己的功能。除了处理 log 之外，也有『slf4j-jdk14』这样的兼容不同 JDK 版本来处理的适配器。正因为有了适配器，即使在 commons-logging、log4j 中追加了 slf4j 的时候也能进行工作。

适配器通过设置文件来进行适配，log4j.jar 不存在的时候会读取 log4j.xml 文件。适配器是很认真的来工作的。但是因为有了适配器来进行各种处理，这也是造成了 jar 文件混乱而使得 log 的输出复杂的原因。

另外，「jul」是「java.util.logging」の简称，「jcl」是「Jakarta Commons Logging」的简称而不是「Java Class Library」的简称。这些简称的理解困难也是造成 log 的输出复杂的原因之一。

JAVA 8 开始对 time 添加了不少东西，最常见的就是 LocalDate 这样的东西，其实还是多了点其他好玩的东西，比如说 java.time.format.FormatStyle 这个类。下面的代码中让我们来用 Local(语言, 国家) 之后格式化时间看看输出内容都有些什么。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public class FormatStyleTest {
    public static void main(String[] args) {
        LocalDate ld = LocalDate.now();
        Arrays.asList(FormatStyle.FULL, FormatStyle.LONG, FormatStyle.MEDIUM, FormatStyle.SHORT)
              .forEach(formatStyle -> {
                  System.out.println(String.format("--- FormatStyle.%s ---",
                                                   formatStyle.toString()));
                  DateTimeFormatter dtf = DateTimeFormatter.ofLocalizedDate(formatStyle);
                  Arrays.asList(new String[]{"zh", "CN"},
                                new String[]{"zh", "HK"},
                                new String[]{"zh", "TW"},
                                new String[]{"en", "US"},
                                new String[]{"en", "UK"},
                                new String[]{"ja", "JP"})
                        .forEach(strs -> {
                            Locale locale = new Locale(strs[0], strs[1]);
                            System.out.println(String.format("%s %s -> %s",
                                                             strs[0],
                                                             strs[1],
                                                             ld.format(dtf.withLocale(locale))));
                        });
              });

    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

--- FormatStyle.FULL ---
zh CN -> 2018年7月23日 星期一
zh HK -> 2018年07月23日 星期一
zh TW -> 2018年7月23日 星期一
en US -> Monday, July 23, 2018
en UK -> Monday, July 23, 2018
ja JP -> 2018年7月23日
--- FormatStyle.LONG ---
zh CN -> 2018年7月23日
zh HK -> 2018年07月23日 星期一
zh TW -> 2018年7月23日
en US -> July 23, 2018
en UK -> July 23, 2018
ja JP -> 2018/07/23
--- FormatStyle.MEDIUM ---
zh CN -> 2018-7-23
zh HK -> 2018年7月23日
zh TW -> 2018/7/23
en US -> Jul 23, 2018
en UK -> Jul 23, 2018
ja JP -> 2018/07/23
--- FormatStyle.SHORT ---
zh CN -> 18-7-23
zh HK -> 18年7月23日
zh TW -> 2018/7/23
en US -> 7/23/18
en UK -> 7/23/18
ja JP -> 18/07/23

即使是华语圈，出来的结果基本来说都不一样的，而 en US 跟 en UK 都是一样的。

顺便说一句，java 中格式化时间还是有点麻烦。

via java.time.format.FormatStyle を確認

在甲骨文的官网上，java 10 已经没有运行在 Linux ARM 的版本了，而要想在树莓派中运行最新的 java 的话只能下载 java 8。本想从 openjdk 看看有没有可用的版本，结果迷失在各种连接中找不到下载的地址，这。。。

不过现在已经有人给树莓派可用的 java 10 的版本，是一个叫 bellsoft 的给编译的，下载地址在https://github.com/bell-sw/Liberica/releases 这上面。

在树莓派中运行如下命令即可食用

1
2

wget https://github.com/bell-sw/Liberica/releases/download/10.0.1/bellsoft-jdk10.0.1-linux-arm32-vfp-hflt.tar.gz
tar -zxvf bellsoft-jdk10.0.1-linux-arm32-vfp-hflt.tar.gz

别忘了把 java 命令加到 path 中

1

export PATH="jdk-10/bin:$PATH"

使用 java.time.LocalDate 计算从生日起到现在年龄的方法。

1
2
3
4
5
6
7
8
9
10
11
12

public int getAge(int year, int month, int day) {

    // 生日
    LocalDate birthday = LocalDate.of(year, month, day);

    // 当前日期
    LocalDate today = LocalDate.now();

    long duration = ChronoUnit.YEARS.between(birthday, today);

    return (int)duration;
}