呃... 然后说一下 被各种运维大佬和网路大佬吊打是什么意思。

前天解决了 ArchLinux 环境的问题，这么说可以正常开始编程了，可是想先确保下科学上网的问题（虽然我科学上网主要是为了 Telegram，Wikipedia 不知道用 Hosts 解决 DNS 污染后能不能访问）。

这个『网』是什么呢... 我真的还不知道。`iptables` 也不会用，然后 ip 和 socket 也不了解，netcat 和 shell 也不会。
只懂个 HTTP 抽象算什么，又没有到写并发 HTTP 服务器的水平，也不会用 OpenSSL 之类的库，不了解密码学。

之前有大佬分享了个 SSR(ShadowSocksR，原项目的分叉)的服务出来

然后我找了好久的 SSR（我不打算用 electorn-ssr，因为它太低效能了，我这电脑运行不起，即使它应该有单独配置 headless 模式的），首先我看了 GitHub 组织 shadowsocksr-backup 的，但好一会（我看 commit 记录）才发现他们 的 SSR 源是严重过时的（2015 的... 而且开始的时候我用里面的脚本，但那脚本是启动 tunnel 服务端的... 误会了好久）

后来发现 shadowsocksr-rm 里的备份新很多，但是不支持我要连接管道服务的协议 auth_chain_b（它还只是支持早期的 auth_chain_a，据说这个协议特征很明确容易被 GFW 检测）

后来我通过 GitHub code search 找到了一些可以用的客户端（最早是找到并且移植了一个支持 auth_chain_b 的 auth_chain.py ），可惜他们的软件质量存在着问题，而且最终我还是没能连接上 SSR...（开 -vv 发现是持续 Connection Refused）（是连套接字都无法打开么）

自己配置和用 Electorn-SSR 有啥区别...

（之前我还由于软件错误提示做的不到位的原因，误解了不支持 protocol 为不支持 obfuscation，修改了 shell.py 前端 argparse 的 cmdline argument 解析模式... 我以为是 argparse 不能区分 -o <obfs> 和 -O <protocol> 的问题）

于是我就检查了 obfsplugin/auth_chain.py 的代码，然后看到好像的确是

虽然我没有也可能会在很长一段时间里不能做到类似 ShdowSocks 这种程度，但我也不得不吐槽，他们的代码逻辑细节也的确有点可以改进的地方，比如说，没有处理 config file 有默认值的情况、没有正确处理 config file 缺少『必要信息』的情况，但是最重要的是，我在 tcp_relay.py 里看到了大量 self._config["is_multi_user"] == 0 这种低语义明确性低健壮性的代码...

不过我看到了 shell.py 里一个基于状态机的 class JSFormat 类非常可圈可点（虽然这种模式我之前也用过，而且显式编号的状态有点直了）

有时候我会感觉，其实做的真的是太菜了... 和我所见的人也不过是方向的区别而已，但我离实际工程还很远。只是因为身边的人看起来也就那样，我就以为世界就那样。

像纯纯写作、Dir 那样的应用，都可以认为其中还是有一些复杂一点的逻辑的。
但是纯纯写作不需要自己给文字编辑存储结构建模，也不需要自己写渲染算法，只用 extends 给 android.widget.EditText 之类的东西扩展，写点根据情况模式匹配的启发式算法就可以了。

Dir 的扫描算法可以用 C 写，也可以并发搜索，但整个应用也就这核心的一点是『有一点点复杂』而已了，而且 C API 虽然封装因为范式的原因有限，但总体来说并不复杂，就是使用系统提供的 fstat 操作而已。

我想要的是类似 Rikka 的 Riru 的那种复杂性，虽然 Riru 的工程主要集中在其 headless 部分，但它做的事情，据说是替换系统的 JNI dynamic-link 函数，而且还是扫内存（其实 Riru 本身不做这个工作，它只是解决 jniRegisterNativeMethods 注册的 native 方法替换而已，扫内存替换 dl module 的工作是 xhook 库在做，它暴露 xhook_regiter(char **path_regex, char *name, void *new_func, void *save_old) 接口来做到 JNI 替换，库本身的 entry 是 __attribute((constructor)) 标记的函数）

所谓工程，是理论和实践结合的中大型软件工程项目。目前虽然我的方向很杂乱，但都是些不花时间的东西。
不花时间实际上做不出什么好事请（虽然有些人为了做一两个好事情，就花了自己一两年的时间...），虽然这利于尝试但是不能作为实际的训练来看。

说到『开发』，其实我崇敬的是那种既有理论基础又写了很多软件模块的项目。
比如说 GNU Coreutils（里面一大堆东西就是使用都不容易啊，UNIX 的哲学方便组合，但缺乏明确性、对于输入数据可能做太多的变通，总之就是虽好，但存在美中不足...）
比如说 ShadowSocks
比如说 DHT 网络的实现
哪怕是前端写的 electron-ssr 和 templet.js, md5 digest 算法

我现在有能力了，这很不错。我能理解很多范式，比如结构化编程/函数式/面向对象/描述式/反射/泛型/模块化编程、我能写各种列表处理、图处理和关系、矩阵处理、顺序异步回调并发、流、状态机、函数曲线，我见过很多数据结构，看过很多应用的模式，我能理解很多常见的技术，比如 HTTP/CSS/HTML/Maven/Gradle/Qt/分布式/机器学习 但我根本没有能证明和优化自己的实践经验，太缺乏了。

那么... 继续努力吧。

大概是这样...

那么 SSR 的事情就暂时不考虑
先得完成 CoolApkFeedPreview，不过这个东西依赖我要自写的模板引擎先...
然后就是那个勤奋版本的 Pomodoro 了（强制安排时间

dvorak 键盘布局的确是非常棒的，但我决定咸鱼一下，暂时不学它

这个暑假，我想先做到：

+ Quick hack 不能忘
+ 理论随便想随便写点...
+ C 系的 CMake/NDKBuild/Makefile/Autoconf 项目管理学一下
+ Maven/Gradle 多写一点，写一些 Gradle 插件 task
+ 熟悉 C++14 和 C11（预处理指令、__attribute、CFLAGS / CXXFLAGS 什么的）
+ 多写点 Java
+ 学习 ES6 和 webpack

很希望也能同时弄出 Firefox 插件和 Chrome 插件，不过就需要正确的项目管理了... 我想想

因为项目依赖一个 md5 digest 模块，希望能使用 WebPack 配置打包成一个脚本。

项目本身需要做的只是在 coolapk.com/.../<id> 页面上注入一个 page script 而已（没有更多特性的打算）
此外，还可以利用 content script 交互拿到登录信息（可选）、利用 config page 设置酷安 token 生成选项和登录信息

项目的 greasy 脚本不应该依赖 WebExtension 扩展部分的环境来运行，而需要可以在完全独立的情况下单独扩展。

终极目标是 bring back 酷安网页版（虽然可能没有人用，笑）

所以兼容性应该很好

#Kotlin #OOP #Question

可是我不擅长设计模式啊... Adapter 给人的感觉就是接受数据，然后提供对应操作的。比如 NumericAdapter 可能接受 LongNumber 和 StringNumber 状态实例，提供 plus / minus 等操作...

至于这个 Polymorphism，中文名即为多态。含义就只是『不同的东西用一个名字』而已，比如面向对象的方法重载(overloading)就属于特殊多态(ad-hoc polymorphism) 的一种

面向对象的多态有子类型多态、类型转换多态、函数重载、参数化类型等等（虽然我不知道那些是什么，2333)

大家在使用 JavaEE 的 Beans 特性的时候应该可以注意到 BeanManager 要拿一个 Bean 组件的实例（getBeans&resolve），得提供它的参数化类型（getRawType、getActualTypeParameters），可能 kotlinx.serialization 的那个也是一个用。

所以这个 ktx 的多态支持是什么呢...

等等，我看下....

我也是... 完全没有注意到它要干什么，可能的确是要运行时生成子类实现吧？

既然出现了 Animation ，一般认为都是关于前端的事情吧，可是这明明是序列化，对数据表示方式的变换（所以它只是一个用例啊...）。

我只知道，如果开发者写一个 class UserPhotoInptMedia(): InputMedia() 就可以直接在代码里访问到 companion object 里的 module 了，或许是这么用：

val buffer = InputMedia.module.serialize(mike.getAvatar() as UserPhotoInputMedia)

SerializersModule 可能是一个类的构造器，接受一个 SerializersModule.() -> Unit 吧... 这是 Kotlin DSL 的经典『初始化器』模式，和 Groovy 那个一个暖样。

关键在于 polymorphic 方法，它可能要反射这个 KClass<InputMedia>... 然后为下面初始化 Block 里的语句做 self 的依赖数据。

InputMediaAnimation::class with InputMediaAnimation.serializer() （ with 是 Kotlin 的 infix 方法 ）这明显是反映了一个 Mapping 的数据结构，利用副作用把每个子类型多态子类映射到它的 Serializer<in T>, 这么一看就联系起来了，整个 serializer 架构的 context 就是某个作用域的 Map<KClass<*>, Map<KClass<*>, Serializer<*>> 大概（没法类型安全，所以只能使用 * ）

然后目标是把 Person 的许多子类比如 Teacher / Boss / Developer / Police 给指定不同的 Serializer<T> 实例，进行序列化的多态。本来就不应该乱用设计模式的... 原来的方法可能要你专门去提供一个 Type 来拿 Serializer<T> 比如

InputMedia.module.serializeToStandareOut(mike.photos.getFirst(), PolymorphismTypeAdapter(PhotoMedia::class)) 这种，Runtime 的那个用 Java 的反射元编程依赖输入对象自动创造 TypeAdapter 的就太魔法了。开始手动去指定子类型的 serializer 实例也好，但是不如这么做明确...

不过也有会这么干的：

interface DecidableSerizer<T> { fun getSerializer(): Serializer<T> }

然后每个接口实现都可以 `override fun getSerializer() = my_serializer`，不过这样就不 DSL 了。
（刚才 Doge 酱的 MTProto 不稳定，所以没发出来）

总是觉得 StateMachine 模型会好很多，状态机好魔法啊，状态、状态转换图、切换状态、状态变迁、同步信号、异步信号...

看看这个 class JSFormat https://github.com/aiastia/testssr/blob/dev/shadowsocks/shell.py#L436 好高端的样子，文本处理就应该用状态 🐔

状态机的确是一个很通用的模型（程序计数器也可以理解为基于 counter 的特殊状态机），而且非常有用，尤其是针对 GUI 程序的设计（比如某种状态下，接受到某个信号应该做什么、再切换到什么状态），推荐了解一下。

...其实不管怎么样，从仅仅是不强调思路清晰而已到复制粘贴代码是一件很可怕的事情，D(o not)R(epeat)Y(ourself) 原则啊，机器人才复制呢。推荐你写一个 Gradle task 从某种 input file 生成代码填进到 outputs.file 里... 之前大佬应该也听说过苏上个暑假写 GeekApk （虽然最后没有完成...）的时候，一大堆接口 mapping 都不是靠复制粘贴得来的... Kotlin 代码生成程序还算是简单的，我根本不会写 LLVM 编译器

我在写这个，目前已经完成了

写的时候很是感叹空纸上谈兵和实践果然还是不一样啊 #Lua #dev

我之前在学校里看了《Lua 设计与实现》里类似这些的代码，自以为很了解并且能写出更好看的代码，
可还没有两秒钟就被自己的愚蠢打脸了... 我有一个优化没看见

其实这些数据依赖、数据操作的模拟分析和回溯，又有多么简单呢。它们的复杂性需要大量的实践经验去填补。

想到要写只是一会的事情，刚准备写的时候冷汗直冒... 原来我其实一直都没有彻底理解 而已
我靠的大部分是记忆，不是抽丝剥茧。

不过还好，我还是最终通过自己勉强有一点的直觉想到了该怎么写... 并且在三十分钟内完成了总体的程序，之后一直在调试。

第一次我把 {__newindex=mkmember } 写错为 {__newindex, mkmember} 导致莫名其妙 bug 的出现，花了我好长时间...
第二次我不知道 __newindex 对应的 rawset, 上网查了第一次
第三次我写 local helper=function()... 但不知为何错误，改成了 local function helper()...
我也修改了不少次递归查找的函数。

最后我还是证明了开始写的程序，总体逻辑是正确的。
代码一共 80 多行，不多，但是我已经开始从理论走向编程。

我准备将它整理，添加一个非 Prototype 的方式（call super 链）
并且附上 LinkIterable, InvocationChain 的实现，
顺便加一个 Lua C 函数编写的简易示范发上 essay.

想要试用的同学：

require 'oop'
animal = inherit.class()
animal.ctor = function(o, id) o.name= id end
function animal:describe() print("我叫" .. self.name) end
cat = inherit.class(animal)
cat.ctor = function(o, id) o.name= "猫" .. id end
meo = cat.new('喵喵')
meo:describe()

说起来，因为有这个小号的原因
我知道 drakeet 曾经研究的反破解也的确是取得了一些进步，至少他都知道我能找到『黑箱』里的符号了
当然，作为 C 开发者我也是知道怎么办的，CC -fvisibility=hidden, __attribute__((visibility("hidden"))), static, LD --exclude-symbols, strip -K Java_io_Main_digest 都可以

可惜 drakeet 虽然的确是从我曾经的逆向工程经验里学到了很多应对经验了... 我觉得这很不错
这和『无懈可击』还是蛮不一样的。

我在编译原理上也有进步，实际上，他改进之后的『反破解』，也未必是真的无懈可击... 他依然是并没有给出破解动态调试的方法，进步了，在添加无用代码混淆视听了，但是这对基于关键方法断点的动态调试手段没有本质上的改善。用『空白字符』『不可打印的字符』也是没有用处的，他们都不是本质。本质仅仅是引用，写过 Haskell、LLVM IR 用过惰性求值你就知道。

弄了半天我才知道之前 -assumenosideeffects kotlin.Intrinsics 的原因居然是为了反破解（可惜现在大部分猴子好像还没有自动代码重构的能力...）
不过有一件事情不一定知道：side effect 死代码消除是 ProGuard 优化代码的手段（之前是不是只把这个玩意当成混淆器呢？），你以为它是说删除 Intrinsics 调用，可实际上它是说删除『返回值没有被使用的』Intrinsics 调用，结果正常只是因为 Intrinsics 对象的方法只是使用副作用(side effects) 而已，这也是我琢磨一会后猜的。

这是(猴子/老鼠)和猫不一样的地方。
猴子总比你知道多一点、深一层，猴子编程的同时训练自己的记忆不靠 StackOverflow。
因为猴子不怕失败，不会浅尝辄止，猴子向往的是背后的东西，只把使用层面当配菜慢慢品尝。

猴子还是老鼠... 可是如果站到了更高的层次，如果已经是程序设计者，还是不一样的吧。

简而言之，我看了一部分后觉得他维护的果然还是变勤快了。
而且内容质量看起来也是高了不少，虽然还算是意料之中，分享的大部分还是停留在使用层面...

两个看到了想说什么的：

1. native 中不依赖 PackageManager 和 signature API 进行签名验证的方法
猜测：
a. 手动算 file 再算 dex hash 和长度什么的，总之就是利用文件系统
b. 找几个应用类算代码 hash 校验，不过实际上这也不叫签名验证
c. JNI 是否 Android 有提供验证的方法
d. 检查重新打包时一切可能发生改变的东西，比如安装包大小？APK 的路径完全可以用 native 的系统 API 得到，不依赖 Java API。

drakeet 早就说过他可以，不过具体怎么办恕我无才，我就猜不出了，而且我不打算再去当甚么猴子，当成迷吧。
但是，如果还有下一次，恐怕我会当成迷的东西真的会少很多。

2. Kotlin 里使用 Number.dp 扩展属性而不是 Number.dp()

开始我套了一下：JavaScript 里 String.prototype.bold 是不是也得变成『accessor』呢
后来自认为是 DSL 方便点而已。 10.dp 不是比 10.dp() 好看么，虽然在符合直觉上有争论（显然第二个语义上有 10.makeAs(dp) 的意思，第一个则从表述上取胜）。

至于 Android 和 Java 开发/日常部分我不熟悉也就不看了，关于逆向和代码保护的标题我看了，也就是防猴不防人。

没做 OCR 的原因是机器太卡了...