#GeekApk 打算重构，不过这几天我肯定要先讲点东西休息一会... 过几天才继续

当然的确还没有写完，目前我们这个 API 来说其实是基于『古老』的 JsonRPC 技术，就软件开发模式来说是瀑布模式，测试来说是瞎测试，黑盒验收。

我的希望是这个版本我们只和我挑几个参加过 GeekApk 内部组的志愿者内部消化了，然后正式的得全部按 JavaEE 的标准用 Java 8 重写，主要还是想让它先『符合标准』一点... 顺便我练练手


到时候正式上线的肯定是有推送功能（当然这个其实是很 trivial 的功能）和 RESTful API 的服务



咳咳... 那本 # Countinuous Enterprise Development in Java 讲的 GeekSeek 例子好后端服务部分像最『难』的就是 SMTP 和 Picket Link、Agorava Twitter OAuth 应用接入了...

然而其实呢，我觉得都是经验之谈

当然这次也依然有好玩的（不模式化的东西），就是后来几个 reversion 会加入一种类似 SQL 的语言用于查询 GeekApk 服务的数据，基于我之前的一个 Lime 解释器的改版（lime 都不能被称为 Lisp 方言，因为它根本没有完整实现 lambda 演算... 它的 dynamic scoping 有问题，但改版里绝对是正常的 dynamic scoping），可以用来批量查询一些东西和进行服务端数据处理，来减少数据交换量。

比如（一个不好但是有意思的例子，因为 GeekApk 是非常经典的 RDBMS 应用程序，它不用 NoSQL、不考虑性能和分布式问题、不专门使用图来抽象关系），查询 UID 0 的所有朋友的朋友中也和它是朋友的部分（正式版的 GeekApk 的 UID 肯定不会是数字，开始我们这么设计主要是考虑到性能问题，后来我决定改了，直接将用户名作为用户 ID 而不是 UID 数字加额外的限制）

查询：
  用户（uid = 0）
    的｛所有跟随者｝
      的｛所有跟随者｝

  并且，与｛它的所有跟随者｝取交集

（没错，这个例子就是上面那本书上的，别急着喷。

我们翻译成 SQL （这些都是有效的 SQLite 代码，不信自己 execute）

首先准备

BEGIN TRANSACTION;

CREATE TABLE follow_rel (follower Text, followee Text);

INSERT INTO follow_rel VALUES ("duangsuse", "rachel");
INSERT INTO follow_rel VALUES ("rachel", "pandecheng");
INSERT INTO follow_rel VALUES ("pandecheng", "duangsuse");

COMMIT;

我们现在知道 duangsuse follow 了 rachel，rachel follow 了 pandecheng，pandecheng follow 了 duangsuse，正好符合这个情况。然后查询

SELECT followee FROM follow_rel WHERE
follower IN (SELECT followee FROM follow_rel
WHERE follower = "duangsuse");

通过这一句我们就查询到了『你关注的人所关注的人』（我好像有点头疼了，因为我描述问题不是很清楚... 这里就按这个规范说了

「关注你的」的话，再得求个 JOIN 集。（其实是另外一种方法，这里有个很好的教程，因为 RDBMS 对关系的抽象我有点迷乱了...

forAll you.following {
  followee ->

  forAll followee.following {
    hisFollowee ->
      if (hisFollowee == you) result.add(followee);
  } // or if (followee.isFollowing(you)) result.add(followee);
}

（好吧，好像不是书上说的，因为我的关系抽象方式不一样，不需要 JOIN 子句... Subquery 足矣）

SELECT * FROM (SELECT followee FROM follow_rel WHERE
follower IN (SELECT followee FROM follow_rel
WHERE follower = "duangsuse")) WHERE followee = "duangsuse";

我这里不知道为什么没结果，中间 FROM 那个子句的结果是 pandecheng，看来我 RDBMS 还要学习一下。

顺便科普 JOIN 是怎么用的 #SQL

SELECT a1, a2, b1, b2
FROM A
INNER JOIN B on B.f = A.f;

Suppose you have two tables: A and B.

A has a1, a2, and f columns. B has b1, b2, and f column. The A table links to the B table using a foreign key column named f.

the INNER JOIN clause returns rows from the A table that has the corresponding row in B table.

举个栗子，假设我们有个 RDBMS 应用程序比较有特色，把管理员用户和普通用户放在了两个表（users, admins）里，而用户和管理员都可以『拥有』『文章』（post）

我想知道有哪些人拥有相同的文章

SELECT *
FROM admin_post_ownership
INNER JOIN user_post_ownership ON admin_post_ownership.owner = admin_post_ownership.owner

（其实这个栗子非常的不好，而且不能体现平时 JOIN 的用途，因为我还不是特别熟悉 RDBMS 那套）（算了，别太在意 #Web

我们这里不管什么几何复杂度什么的... 你们知道为什么图数据库能用的原因就是了（


上面的东西用 GeekApk QCL 来写就是

((<< filter flatten) (# (u) (eq? (user/name u) "duangsuse"))
  (map user-followers
    (user-followers "duangsuse")))

或者说用一种不像 Java 也不像 Kotlin 的语言：

User("duangsuse").followers.map(User::followers).flatten().filter { it.id == "duangsuse" }

最近写的东西越写越感觉 Low... 算了，这几天说说，说完了弄 GeekApk，反正我也就是写点代码... 做点工程... 工程是实际的，反正那些东西现在也都基本理解，慢慢来///... (((

#SQL #Postgres 这个就比较艺术了，平时他们都 ORM 的，SQL 可能都不会写... #Web

花了我几个小时写的 #Pg好玩

#CSharp #FP emmm... 这个就比较有意思了

求求你出 record type

#Parse #PL #GNU #backend

Bison 3.3 释出，修复了 31 年历史的 bug

自动生成语法分析器的 GNU Bison 项目释出了 3.3 版本（以及迅速释出了 3.3.1 版本）。主要新特性包括：移除对已经停止维护的 DJGPP 的支持，新的选项 --update 替代弃用的功能，预期冲突数注释规则成为可能，可重寻址，大幅修改了符号声明语法，Autoconf 2.69，Automake 1.16.1，Flex 2.6.4，Gettext 0.19.8.1 和Gnulib v0.1-2382-g34881aff4，修复了一些 bug ，其中一个至少有 31 年历史。Media

https://www.solidot.org/story?sid=59456

刷机：从入门到锁回 Bootloader

#Haha #Android

太真实了

#SYSadmin #ANdoird #Haha 2333333... 🙈

我干嘛脑残在根目录 rm -rf 啊啊啊啊
想删掉 data 内除了 media 的所有东西 删成了所有目录除了 media 的所有东西

#Haha #Recommend

「健康刷机忠告」
抵制不良 ROM，拒绝盗版 ROM.
注意自我保护，谨防受骗上当。
适度折腾益脑，过度刷机伤身。
合理安排时间，享受健康生活。

#Android 核电，总算加搜索替换了...