加油！ #life #dev

#code #Haskell #TeX https://github.com/ThoughtWorksInc/DeepDarkFantasy/blob/master/DDF/Sam/Xor.lhs

#statement #TeX 顺便说一下，其实 #Microsoft Office Word 系列排版也很好的，TeX 某些扩展包可能排起来都有数学公式渲染问题，我上次那个 foo.pdf 的根号就不对

（吐槽，即使在与理论系的巨佬们差距如此之大的情况下也要如此逞强吗？
（回复，巨佬尽管是巨佬，可能几年前也不过是菜鸡，我和巨佬之间... 还差几年的努力

#Docker #Java #sysadmin

自我感觉良好（

#PL #Java 哦，又想起这件事，这个 Java 8 OpenJDK/Oracle JDK 的泛型（Generics aka. Parametric Polymorphism 也即参型多态）实现的确是基于擦除法实现的，换句话说泛型在 Java 8 里就只是提供自动类型转换和类型检查的语法糖，运行时 checkcast 还是照样得检查类型（也可能不用，因为类型系统确保了 interface Map<K, V> 的 V get(K) 方法返回的肯定是 V 类型的值，因为 void put(K, V) 方法有类型限制，所以拿到的肯定是符合限制的对象，静态强类型系统设计的一个很突出的特点就是可以完成执行效率的优化，消除不需要的类型检查），包括 18 年的 Oracle HotSpot(目前『官方』 JDK 的默认虚拟机) 25.x 和 Dalvik 1.1 （Android 上 Java 应用的运行时，当然不是 JVM，这里用作对比）都没有真泛型支持，虚拟机上基本可以说是没做什么改动，Dalvik 这清奇平台我不熟悉（我目前不常接触 Android 开发，实际上我工程的时候都很少很少很少，当然我不是不能学），HotSpot/JRockit/J9 之类的是随着新的 JVM 标准改了，就是 JVM 们支持 Signatures classField (ObjectWeb.ASM Parser) 部分，反射用的元数据也是从那拿到的（Java 1.8 之后大概 Sun javac 是会保存元数据的（可以拿 javap <className> 指令查看类元数据），显而易见地），这位老哥可能是对泛型擦除这个术语产生了误会（原意就是字面意思，编译完成后泛型被『擦除』了，在那部分字节码里不存在，也即和没有使用泛型的字节码一样），当然我后面也说了。

当然泛型这个不难理解，就拿 List<T> 说，比如我们有 LinkedList （我不理论系，所以不懂 CoinductiveList 这些东西，也不知道啥是规约...）（破真）

data class LinkedList(val obj: Any?, val next: LinkedList?)

显然我们可以给这个对象添加一堆操作比如 T get(int)、void set(int, T) 什么的
然后如果我们放 String，结果 get() 返回的是 Any，就得强制暴力转换（as String），非常的不爽，这时可以理解为 LinkedList<*, *>
这样又 checked 又可以避免强制转型，多好

C++ 就是 template<typename T, typename R> （这里 template 和前端的模板差不多，自动生成代码的意思）实现的泛型，当然 C++ 比 C 多少还是高级很多（

高级一点的话就必须得学习泛型的 variance （型变性，说白了就是填的泛型参数和 subtype （子类型）之间的关系） @imKiva 那有一篇博文，推荐阅读，当然我不直接给链接（跑）

当然因为 Java 的泛型是虚泛型所以也会有一些诸如语言和字节码层面方法重载（overloading）的问题什么的，比较麻烦，JVM 的书可能都会讲关于虚泛型的事情

据说有些 JVM 开发者是持极端反对虚泛型（就是擦除法实现的泛型）的态度的（比如，吐槽性能不如 CLI 系的真实泛型好），目前 Kotlin 的 inline reified generics 特性好像是给了 JVM 应用们一个『方法反射真泛型』的机会，当然我后面也有举例子（当然也可以利用 companion object 的 operator invoke() 伪造类 constructor 的真泛型，这个小 hack 当然是从 ice1k 的博客上看到的，某次成都线下 Kotlin 同好讨论会 ）

Wiki: Java 的泛型特性

TypeArguments:
< TypeArgument {TypeArgument} >
TypeArgument:
[WildcardIndicator] ReferenceTypeSignature
*

这只是递归下去了... 压根没有回溯回来，我当时设计的是想要副作用打印路径的说，要回溯的话得传当前路径，设计返回值

好像的确回溯了... 但是层次做的不对没有考虑到...

简单学习 #Docker
一个新命令：COPY [--from=int] <src> <dst>

试了试 SysRq 的 E-I-S-U-B 键，好用的很，重启靠它了（x
S-U 按完看了下 dmesg，报了几个 Ext 错误，慌的一笔（怕挂硬盘... 以前电脑硬盘就挂过一次......
不知道紧急同步（S）挂载（U）会不会伤硬盘.....

太高产了，一早上又整了几个 Docker image： https://github.com/Trumeet/Bup-Docker

GitHub released "Pin issue" feature

#sysadmin 我也偶尔使用，表示对于一个进程使用私有集合大小达到系统无法接受的程度后系统依然为其分配内存并且还使用外挂的 swap 分配非常低性能的页面表示不解...

以前我 Fedora fork 炸弹都是不生效的（达到 limit 限制后会直接被杀掉）
现在 Firefox 都偶尔导致整个系统看起来卡死

#Project #Android #Java #Docker #Build

#Docker #learn #blog 这里我快速的给还没有看的大家写一个快速知识获取笔记（就是我之前偶尔写的阅读笔记）：

+ Trumeet 这么做是为了让 Docker 构建（like CI Build）程序（like Java/Gradle）时更省内存资源和减小 Docker 镜像大小

»» 优化前

FROM openjdk:8u171-jdk-alpine3.8

ADD . /app
WORKDIR /app

RUN apk add maven \
&& mvn clean package \
&& apk del maven \
&& mv target/final.jar / \
&& cd / \
&& rm -rf /app \
&& rm -rf /root/.m2

ENTRYPOINT java -jar /final.jar

»» 优化后
FROM openjdk:8u171-jdk-alpine3.8 as builder

ADD . /app
WORKDIR /app

RUN apk add maven \
&& mvn clean package \
&& apk del maven \
&& mv target/final.jar /
# 删了后面几条 rm -rf 命令

FROM openjdk:8u181-jre-alpine3.8 as environment
WORKDIR /
COPY --from=builder /final.jar .
ENTRYPOINT java -jar /final.jar

我们总结一下，就是把 JRE 和 JDK 分开，首先 JDK builder 生成 JAR 文件，然后 COPY --from=builder /final.jar . 拷贝 artifacts 到 runtime 环境，然后 entrypoint 执行 java -jar final.jar


+ 多阶段构建是 Docker 17.05 的新增功能，它可以在一个 Dockerfile 中使用多个 FROM 语句，以创建多个 Stages
+ 每个阶段间独立，使用 COPY --from <stage> <dst> 来获取其它阶段的文件


Trumeet 的意思就是，分阶段『构建、运行』可以省内存和镜像大小，原理就是首先『做菜』

需要锅（构建工具链）、调料（构建配置）、菜（源代码）什么的

然后上菜（COPY 复制 JAR 包部署），这时锅什么的都不需要了，只存在『享用』菜品的开销，它把『做菜并品尝』的系统资源平摊到『做菜』和『品尝』两个部分，各有各的环境和需要的器材，可以达到省体积和内存的效果

+ docker build --target build1 . 是可以用的，猜猜它做什么
+ COPY --from=0 /demo/hi-1.txt /demo 也是可以用的，猜猜 0 和使用名字的版本有什么区别
+ docker save <tag> > docker.tar 猜猜是做什么 // 重新构建并保存（Save）

分段构建并不能节省内存使用吧。而且不仅仅能节省空间，同时也能节省了 image 的layer（优化前比优化后少了 RUN 的那个 layer）

#learn #reveng #backend 之前说的那个教程

重写了这个