简单码两句。

主要是解决了对于Android多线程机制默认操作的疑惑。

学过Android开发的大概大部分知道，Android的前台线程是UI线程。但是根据开发组的意图来看，这个线程应该是空闲率越高越好。如果学过计算机网络的话，这点可以很轻松的理解，越高的资源占用率意味着越大的延迟，只有当占用率尽可能低的时候，才能满足快速、及时响应的需求。

而多线程在解决了线程占用率问题（通过将大部分高时延的任务下放到后台线程完成，这些线程的响应实验要求相对较小）的同时，也带来了同步问题。Android解决同步问题的方法非常简单粗暴，“谁创建，谁拥有”。换个说法，只有创建线程不安全对象的线程本身才具有修改线程数据的权利。

那么，如果外界有修改线程不安全对象数据的需求的话，那么就必须由所有者线程主动提供一个入口，以所有者线程的身份对资源进行操作。Android为这个理论提供的时间就是Message, MessageQueue, Looper, Handler四件套。四件套的具体功能就不做赘述了，网上到处都是，而其中最为关键的，也是最常见到的组件之一，就是Handler。作为外部线程来说，调用Handler的各类message方法可以向所有者线程发送申请以修改资源；作为所有者线程来说，实现handleMessage方法可以从外部接收，并且自定义地处理请求。

然后困惑之处就在于，按照书上的方法，只要实现一个Handler类就能完成对这种资源的访问。四个组件既然是一套，那为什么只要四分之一就能完成功能呢？最重要的绑定线程的工作，又是在何处完成？

带着这个疑问，去网上转了一圈，最后在官方文档找到了答案（ https://developer.android.com/reference/kotlin/android/os/Handler ）。其中的奥妙就在于，我们的确只需要实现Handler就行了，在Handler类实体化的时候，内部就定义了一系列的操作，包括创建四件套中除Message外的其他两件（Message在四件套中主要作为数据型，而非逻辑型组件，只用于传递Handler请求）。根据书上所说，Looper类的构造器甚至还是私有的，一看就是不希望别人去动的那种。在IDE中多按几次ctrl看看源码，就能发现Handler的无参构造器会调用Looper.myLooper()方法，继续刨的话可以看见，Looper对象已经被ThreadLocal作为线程私有变量保管得好好的了。

总而言之，在日常使用Android Handler的时候，只要实现这个类就行了，其他工作其实是已经由Android框架本身完成了的，放心大胆使用即可。

在CentOS 8上配置Kubernetes。

步骤可以大致简述如下：

1. 如果在国内，换源
2. 安装Docker（需要手动添加repo）
3. 安装Kubernetes配置工具Kubeadm，会自动顺带完成其他Kubernetes配件的安装（也需要手动添加repo）
4. 决定一个CNI（容器网络接口）组件
5. 使用kubeadm init初始化集群，记得带上CNI可能会需要指定的参数（至少Flannel和Calico在默认情况下是要求手动显式指定默认的CIDR的）
6. 使用kubectl apply（更新）或者kubectl apply（重置）安装对应CNI组件的Pod
7. 使用kubectl taint nodes --all node-role.kubernetes.io/master-取消集群master节点的“特殊地位”，允许在master节点上部署应用容器 Google传统艺能

然后关于Kubernetes的镜像，默认用的是Google的GCR仓库，显然在国内是访问不到的，在拉取镜像的时候会报超时错误。网上有不少的解决方法，比如建立私有仓库，换源，但是要么太复杂，要么说的含糊不清。还是弄个透明代理最爽了

参考：https://coreos.com/flannel/docs/latest/kubernetes.html

最近在研究编码参数的时候，随手点开了某番剧的MediaInfo作为参考。结果一看，虽然MediaInfo上显示是AVC（H.264的一种）编码，但是居然没有编码参数Encode Settings？

然后很是疑惑，遂到网上寻找隐藏H.264编码参数的方法。H.264的没找到，不过H.265的好像倒是有。

http://forum.doom9.org/archive/index.php/t-171681.html
这里有一群外国人讨论过这个问题，从中能够获取的信息之一是，x264编码器的开发者们本意似乎是希望编码参数跟随视频一同流传的，从某种程度上还能方便大家相互学习参数的调整。也就是说，AVC编码的视频本身没有携带编码参数是一种不正常的现象（视频编码程序本身并没有提供这种功能）。

然后仔细对比了一下MediaInfo里的参数，也没有发现什么猫腻。

不过后来用WinHex查看了一下文件头，发现这个文件的类型是ftypmp42，和常见的自带编码参数的ftypavc1有区别。说不定是因为数据流版本太老，所以不支持记录编码参数？（问题是，上个世纪的DV编码格式都能记录编码参数的啊）

难道是，失传已久的S级记忆消除秘术？

坑+1

Haskell家的软件简直是巨坑，我就说之前怎么只要编译和GPU有关的代码就失败= =

这次编译darknet终于发现，是Leksah的头文件和Windows SDK的头文件有重定义冲突，把Leksah的路径从PATH里去掉，问题就解决了

具体报啥错我忘了，反正是一个x开头的头文件有重定义

11区的艺术创作者每次都能整出些新活= =

在「変好き」作品第一集的ED后，放出了这么一个玩意：

真是炫酷.jpg

话说音频产业的美术还真是有点东西，不论是上次学到的那个Spectrogram频谱图，还是这次见到的这个。

在某度上搜索一番，竟然还没有发现任何人提到过这个图形，不论是中文还是英文。在某404网站上操作一番之后，得出结论：这玩意的名字叫做Goniometer。中文译名为测角仪，但是回到某度上来搜的话，还真就只有一点点测角仪相关的页面= =

简要叙述的话，这个图像表达的是双声道间的波性一致性。以垂直线为Mono，也就是单声道效果，顺时针45°为右声道R，逆时针45°为左声道L，（水平的+S和-S是啥意思我还不清楚），就可以作出一幅声道测角图。很显然，将L和R作为这个二维平面的笛卡尔坐标系的xy两个坐标轴的话，按照实时信号进行散点作图的话，可以发现若是左右声道信号强弱、相位完全一致的话，只会在Mono线上出现点，也就是传统的单声道效果；反之可能出现（椭）圆形的区域，暗示着在这些时间点左右声道的信号是不一致的。就上图而言的话，在实际使用耳机进行收听后，可以感觉出当时的音源更加偏向于左耳方向。

在Reaper里，可以找到在FX菜单的JS列表中，有一个Goniometer插件。将上述番剧的对应时间段的音频裁剪并放入Reaper中播放，观察可以发现两者在同一时刻的图像是基本一致的。

至于作图原理，我现在也不清楚。。等有时间了来学习一下，自己写一个玩玩吧（坑+1）