足足一万两千行

作为对比，EditText 在渲染器已经完成的情况下只写了 192 行

外加 Editor.java 就两万行+ 了

实际上 View 的实现才是最大的... 1.2M，GitHub 的 highlighter 都拒绝工作了

有时候就想给自己的 Kirin620 手机适配一个 Lineage L

设备树又不知道，想来其实是挑选驱动的事情

晚上睡觉前给 Crystal 写一个 FreeType 绑定，然后用绑定生成一个“你好世界”图片

这里有一个 Crystal 半「官方」的 png 读写库，感觉语法和 Java 的 ImageIO 一样好看

https://github.com/stumpycr/stumpy_png

而且我看到有参与 Crystal 编译器实现的人也加入了开发

它的 API 可谓是优雅至极

require "stumpy_png"
include StumpyPNG

canvas = Canvas.new(256, 256)

(0..255).each do |x|
  (0..255).each do |y|
    color = RGBA.from_rgb_n(x, y, 255, 8) # Alpha, Bit depth
    canvas[x, y] = color
  end
end

StumpyPNG.write(canvas, "rainbow.png")

#kotlin #PL Kotlin EBNF
http://kotlinlang.org/docs/reference/grammar.html#functionLiteral

有一点出乎我的意料：drakeet 还写过后端应用
不过也在情理之中，因为后端不难，其实很多东西就看学不学，难往往是一时的

他对 GeekApk 的批评，我觉得还是有点道理，那时侯 GeekApk 还是模型阶段什么都没有，现在看来 Rebase API 设计更符合 OpenAPI 标准一些，GeekApk API 其实很久以后都不符合 OpenAPI v3，首要分子是基于 Cookie 和直接的密码认证过程

Rebase 一开始就很符合 OpenAPI 标准，服气，总共修改了一个月，到彻底能用写了三四天

不过也是以前的事情了，GeekApk 现在已经转向静态方面，而且有完善的文档，我也遇见了 Swagger 和某 API 文档生成工具，如果 GeekApk API 要重新设计，文档不会像以前那样难看的

https://gist.github.com/duangsuse/477268739e5825645cdcfe0e2842d39e Gekyll
https://gist.github.com/duangsuse/335d87276bfb8ca3a4d00c0d0eb71f3f SpecShort
https://gist.github.com/duangsuse/1fd23dbdbe37326289f97919b1623d43 Spec

这麽看我还是觉得 GeekApk 创建初期的 Times gem 的 API 好一些，可惜后来出了点 encoding 的问题没能继续下去
虽然身份验证十分愚蠢 🙈（这时候就要感谢 Gitea 使我不需考虑验证了，GeekApk 长的文档里也都解释了为什么不用 JWT 之类的

GET /api/version -> version

GET /api/ -> num_posts
GET /api/<nth>/ -> Post
GET /api/<nth>/views -> num_views
GET /api/<nth>/comments/ -> [Comment
POST /api/<nth>/comment/<author> body=<text> -> new_len
GET /api/<nth>/comments/len -> num_comments

DELETE /api/pop/ (auth) -> new_len
POST /api/<author>/ body=<text> (auth) -> new_len

#long #android

#life #dev

这的确是这麽讲的

于是我就去试了一下

https://t.me/dsuses/83

https://gist.github.com/duangsuse/8b343e8ebe8f625ff74cf3472b94720b

这个可能是 GeekAPk 历史上最长的文档，比最近的那个还长

Drakeet 把他的服务程序闭源了，那我就写一个服务程序 🌚
ImageIO 什么的... 试一下就可以了，FreeType 绑定先不写，Gekyll 完成再说