还是会用 radare2 的 （ #reveng

#Postgres #SQL

可以得出一个链表每项后代的方法。这里也用到数组作为中间状态避免链表里的环导致无法结束迭代 #Pg好玩

目前，GeekSpec 的 Kotlin/Spring 代码生成器已经可以勉强正常工作，不过不是所有特性都测试到了，目前借助强大的 IDEAc 它的效果很好，一 瞬 生 成了之前我要写到手软的代码，大家可以来体验一下（虽然一点都不 production ready，有点像那种小脚本

顺便祝大家新春快乐，CCTV 的春晚不知看了没有。 🐷

目前的版本它的作用就是把这种 GeekSpec 代码：

searchUser(type:String?{username,nickname,bio}, kw-path:String, sort:String?{created,followers}) -> array:GeekUser
  = user/search/{kw}

翻译成 Kotlin + Spring Controller bind 的控制器接口

@GetMapping("user/search/{kw}")
@ResponseBody
fun searchUser(@RequestParam("type") type: String/* Maybe username or nickname or bio */, @PathVariable("kw") kw: String, @RequestParam("sort") sort: String/* Maybe created or followers */): List<GeekUser> {
  TODO()
}

目前仍然有不少小瑕疵正在修改

其实也不能算是 Visitor Pattern，因为 ES 是 Duck Typing 的语言... 只是简单模式匹配处理一下就好 #JavaScript

目前已经可以用了，明天测试一下工作效果

（因为我的 Throws 上面已经有了，这里转发个大佬的（

当作自己的祝福喽（因为人类的本质是...

祝大家新年快乐

作为对比，Swagger 代码：

https://github.com/GoliGoliTV/api-document#simplified-guides-on-openapi-specification

  /users:
    get:
      summary: Returns a list of users.
      description: Optional extended description in CommonMark or HTML.
      responses:
        "200": # status code
          description: A JSON array of user names
          content:
            application/json:
              schema:
                type: array
                items:
                  type: string

在 VSCode 上，可以有自动补齐（估计是类似 XML 的 Spec 文件）

GeekSpec 的主要区别是它完全只是为简化 GeekApk 开发设计的，它单单是为了解决类似 GeekApk 一样代码繁复的问题，而不是如何让自己对 80% 的项目可用的问题

所以它可以写得这么简洁，而又能生成真正对开发有效果的 boilerplate code：

getAllUsers() -> array:string = /users

利用目前可用的 Kotlin Spring Codegen，它可以生成这种代码：

@GetMapping("/users")
@ResponseBody
fun getAllUsers(): List<String> {
  TODO()
}

它省掉了上面 Swagger 文档的很多信息，比如 Content-Type、status code、description 等等，但是，它真的非常适合用来进行 API 设计，因为你可以把心思全用在枚举和思考上，而不是去辨识 YAML 二维文法结构

因为我太垃圾（因为我是熬夜写的 PEG 语法）的缘故，它没有在语言层面上支持注释和文档，不过 GeekApk 以后如果要重写，GeekSpec 自然也会跟着重写的。那时候，可能 GeekApk 服务端将完全使用 Project Template 和 GeekSpec （那时应该支持利用宏系统和预处理器实现接口逻辑编写了）语言重写


请允许我飘一会，理解一下吧，因为熬夜的成品真的是... 血汗码啊（Maybe

所以，单单对 GeekApk 和类似 GeekApk 的项目来说，使用 GeekSpec（如果你了解 Visitor Pattern，或者尝试写过图遍历算法诸如解释器的话）可以大大减少 Boilerplate code （这里包括部分 Swagger OpenAPI Spec）对你编程效率的影响，因为一切都将可以被自动生成。

自动生成，不需要再一遍一遍 Check，不需要再一次一次进行重复相同的击键，利用 GeekSpec 和拥有 JSON 解析功能的语言和 GeekSpec 解析器和类似 IDEA 的好开发工具，就可以快速编写 Codegen 程序，解决繁复的接口定义！

instance:

https://github.com/GoliGoliTV/api-document 使用 GeekSpec 梗概：

# Sample API
# description
# version: 0.1.9

# Servers
# http://api.example.com/v1: Optional server description, e.g. Main (production) server
# http://staging-api.example.com: Optional server description, e.g. Internal staging server for testing

# SecuritySchemes
# bearerAuth: JWT(bearer, http)
# schema: User(id: Int, name: String)

# Schemas
# User(id: Int, name: String)

# Returns a list of users.
getAllUsers() -> array:string
= /users


# Returns a user by ID.
getUserById(userId-path:Int) -> object:User
= /users/{userId}

# Creates a user.
POST@createUser(user-body:userNameObject)
= /users

其实狗利狗利的问题也是没有募集到几个稍微有点常识的程序员 🐸 #MoHa #Statement

如果去看看他们的『项目主页』（@ GitHub，就会发现，很多项目都只是一个空壳，根本没有一点业务代码

如果说高代码质量、消息队列、Server side push、完全全栈自动化集成测试、OAuth 和社会化登录、使用图数据库、真正的 RESTful（其实这个也不算） 算是稍微复杂一点的需求，基本的 endpoints 定义和 RDBMS 的 Query Validate 逻辑算是简单一点的需求（对于 MVC 应用）


那么苟利苟利做得还不够好啊，因为它的公开源里，

只有两 - 个项目，是真正能用的。

如果没有那两个项目的开发者（都是一个人）
苟利苟利可能复活吗？其实完全看这一个人。

实际上 GeekApk 真的还没有 GoliGoliTV 惨（

至少开始 GeekApk 得到了一个大佬的帮助，虽然那个大佬现在已经走了（

至少，虽然我被 @drakeet 喷过 GA 是『幼稚和空壳』的代码和定义，但它的确没有 GoliGoli 现在的状态更空壳 — 虽然开始 GA 的确很空壳，但我一直为它写文档，而且设计理念还一直在我的脑海里

曾经我可能的确不是 GeekApk 的后端，但我的确为它写过前端，而且，它的基本设计理念、模型、接口、界面交互我都有仔细想过，而不是单单讨论要不要商业化的东西 — 东西都没有，你想做什么？崇才科技都有『自主』开发的课表软件啊？

并且，现在 github:duangsuse/GeekApk 的服务器，就是基于我『幼稚和空壳』的 API 接口枚举文档修改而来的（其实这么说对 drakeet 可能有点过分，我不知道他是不是没有时间看别的部分，然后只看到了我写的真正是空壳的项目，不知道我还写过 HTML 和这些有意义的文档），值得注意的是它使用了 XeTeX 而不是 Markdown 进行排版，这至少可以证明我乐意去接受一些新东西，而且不害怕看起来复杂的东西。也是现在 GeekApk 能有机会重启开发的原因。

明天会回老家，并在那里待几天。 #life

#GeekApk #GitHub #Dev 百提交留念（

测试持续集成已经上线，但是还没有 DevOps 自动部署，因为目前没有服务提供商，而且业务逻辑实现覆盖率很低、接口测试正在编写中...

🤔 GeekSpec 对 GeekApk Spring 的工程有多大的辅助作用呢？自 Spec 文件写完之后，自动生成解决了 300 多行模板代码的编写任务，从写完 7:34 到完成任务合并主分支 8:08 只花费了半个小时左右，可谓是一瞬生成了（