准备开始写了啊，准备彻底了解 Java 的同学可以期待一下

#web https://vertx.io/docs/vertx-service-proxy/java/

给人的感觉就是 Vertx 可以利用 Event bus 集成外部服务，然后 Proxy 可以消除 boilerplate code

// 下面是 C++ alike 语法

const String vActionHandlerArg0 = "action";
fun DeliverOptions.addActionHandler(name: String) = this.addHandler(vActionHandlerArg0, name)

const String vDbServiceID = "database-service";
auto sendToDb = vertx.eventBus()::send.curried(vDbServiceID);

Json message();

message["collection"] = "users";
message["document"] = jsonObject("name".to("tim"));

DeliverOptions deliveryopts = new DeliverOptions()
.addActionHandler("save");

sendToDb(message, deliveryopts, [](result) {
if (!result.succeed()) { ...; return; }
// else
});

这里 deliverOptions 的 actionHandler 假设了某个 receiver（面向对象术语，但这里是说消息队列的监听者）有这个 handler
并且要求这些 Handler 去 handler 这个 message；这里 save Handler 会存储信息到数据库

你也可以理解为一个动态派发的 Java 方法；当然 Ruby 元编程里的 method_missing 和 define_method 更好理解一些

Json newlover = jsonObject("name" to "Jack", "lover" to "Rose");

DeliveryOptions methodSave = new DeliveryOptions().addActionHandler("save");
vertx.eventBus()::send.curried

—

("databaseService") . (methodSave) (jsonMap("collection" to "lovers", "document" to newlover))   

databaseService . save (collection = "lovers", document = newlover);

不过区别在于它是通过 Vertx 的 Message 队列派发的；不是通过反射也不是能直接 invokevirtual 的对象

有的时候就想；能不能把这种 call service (using vertx messageque) 的东西做成『抽象类』的形式（面向侧面编程；AOP）
因为不断定义操作；感觉很垃圾

我们想想，如果不使用 Annotation Processor 这种搞基一点的技巧（实际上已经不算是技巧了，因为很多人连 Visitor Pattern 都懒得写...）
Reflect API + Annotated Element 会怎么样呢？

abstract class VertxServiceInterface {
  abstract VertxServiceInterface(EventBus bus, String address);
}

@ServiceInterface
abstract class DatabaseService extends VertxServiceInterface {
...
}

然后数据库服务会有一个 action: save

public AsyncResult save(String collection, Json document);

想想是『弄一个 Function<AsyncResult> 参数好呢，还是直接返回 AsyncResult 好呢』
我觉得还是直接返回好，怎么看和 GC 性能什么的也没有关系；何况这种优化都做得你怎么不去用 C++

然后实际使用的时候就直接

static DatabaseService DB = new DatabaseService(vertx.eventBus(), "postgres-database-service");
...
val saveToUsers = DB::save.curried("users")
DB.saveToUsers(jsonOf("name" to "duangsuse", "feat" to "funny"));

函数式风格写多了抽提控制不住了

— 那实际上呢？

Vertx-service-proxy 是这么弄的（我给翻译成 Kotlin 了，要不然很长感觉很垃圾）

interface SomeDatabaseServiceFactory {

fun create(Vertx vertx): SomeDatabaseService = SomeDatabaseServiceImpl(vertx)
fun createProxy(Vertx vertx, String address): SomeDatabaseService = SomeDatabaseServiceVertxEBProxy(vertx, address)


}

@ProxyGen interface SomeDatabaseService {
// 俩创建自己（constructor）和 Proxy 的接口

companion object: SomeDatabaseServiceFactory

fun save(String collection, JsonObject document, Handler<AsyncResult<Void>> resultHandler)
}

这让我想起了 Perl，<> m!! ~= //....

自以为理解了递归，可是发现其实我连计算机科学里的子程序递归都没有彻底分析过，我无法允许有隐式的知识存在。
前几天才被数学老师打了脸，我之前幼稚地以为『数学老师讲的都不好，所以他们不如我擅长『当老师』』
谁知人家弄了个 PPT 动画图示出来... 我发现和我的直觉正好相反（我的思路正确，但是操作，递归顺序弄反了）

... 不得不说，Hannoi 塔问题我之前自己尝试解过，很可惜，到昨天我才结束了对递归不理解的尴尬情况..

#web #dev #Kotlin 插播一条消息

内存区域限制技能 get ✅

#Algorithrm https://sourceforge.net/p/jedit/svn/HEAD/tree/jEdit/trunk/org/gjt/sp/jedit/textarea/TextArea.java

https://ice1000.org/2018/04/27/CodeEditor/ #blog #fix

看完查找资料后，修复了我对一个单词的误解：

efficient 不是『足够』的意思，是『有效率』的意思
effective 是有效的意思

Trumeet/FlarumSDK 1+ 理解

快速阅览：

这是一个使用 Gson / OkHttp 的 Flarum JsonAPI 客户端程序

+ 它有一些客户端实例状态

Flarum API base URL

Task Executor, OkHttp Client, Gson 实例
身份验证 Token: interface TokenGetter { String getToken(); }


+ RequestBuilder 按照 base url, method, body, authentation, filters, page(*20 item/perpage) 和 json converter 生成 OkHttp 的 Request
+ internal.parser.jsonapi.Parser 将 Raw JSON Response 作为 JsonAPI 返回对象解析，返回 APIJSONObject 将被各种对象解析器 internal.parser.ObjectParser.JsonConverter<T> 读取到 Java 对象
+ Result<T> 给 T 结果附加了 OkHttp 的 raw response 和 raw api json object 以及 ID（目前为 0）
+ internal.parser.ObjectParser 定义了将 JSON 对象解析为 Java 对象的接口和辅助函数
+ internal.parser.converter. 定义了一些辅助这种转换器编写的基类
+ internal.parser.ContentParser 是空的 fallback JsonDeserializer<Content> (也是空的) 实现，如果不能作为 Api Json 解析，结果就是无意义的值
+ internal.parser.OkHttpUtils 是放错地方的 OkHttp Client API Call 请求封装，它支持同步使用 execute(request, apiManager, converters) 和异步使用 enqueue(request, apiManager, converters)

逻辑就是给原处理程序加上先判断 HTTP Status 成功、JSONAPIObject 解析成功且访问不包含错误、再转换为目标 Result<T> 的过程

+ internal.platform.Platform 是从 Square Inc 复制修改的逻辑，实际上就是弄一个 Executor... 本来目的是给 OkHttp 异步请求分配合适的执行者，可实际上它只能找到有 android.os.Build 的 Android 平台和创建利用 android.os.Looper 和 android.os.Handler Executor 的(post 到 mainloop 去执行)，否则默认就是新建 Thread 去执行，而且处理的地方也不在这里，在它的 Caller 那里...
这个类要是弄的好一点要使用 enum with constructor calls、java.util.Function、java.util.concurrent.Executors、java.util.concurrent.ForkJoinPool

人生苦短，写点文字吧

https://github.com/duangsuse-valid-projects/Java-You-Dont-Know

过一周天这里甚至会重写我之前写的 Ruby 入门...
将会讲一些有趣的问题

啥时候我能学点前端就好了，你看这 OpenGraph 好看的

没时间写内容了，看来得两个星期，解析组合子的事情也要推后了，好无聊啊，打字又变慢了

排版测试