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

前天解决了 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 程序的设计（比如某种状态下，接受到某个信号应该做什么、再切换到什么状态），推荐了解一下。