期待寒假它，希望它真的能用...
目前看来好像是稳定发展，写的时候都是体力活

（不过 Spring 果然是重量级框架，和 IDEA 经常弄卡死，看来我得用那些轻量级的东西了... #sysadmin 正在安装

sudo dnf install i3

#PL #PLT #Proof

#game #security #China #tencent 🌚 这个...

不过 J2EE 开始早期那些 XML 配置都不用写了，符合时代潮流，程序员不用切出思维来做 DevOps 一类的事情，爽炸

现在非专业的服务器系统管理，不弄集群不配置磁盘阵列、数据恢复什么的... 都会把一些本来比较 trivial 的事情做得很到位... 比如编译啥啥啥东西...

其实嘛... 我觉得 #sysadmin 像我们这种业余的（其实业余和专业也就是取向不同而已，智商需求都差不多的）好好写点配置步骤指南、配置条目指南就可以了... 有些东西好像没太大价值？

（其实是，因为那些东西几条命令就可以搞定，而他们又要写成博文的形式... 如果直接弄就太短了）

（其实就 UNIX 系的管理员来说，可以是非常的 trivial 也可以不那么 trivial，主要还是看你对这个系统的熟悉程度，知不知道具体结构功能、文件系统里配置们、设备们放在哪里找不找的着
包管理是否了解，权限控制熟不熟悉、Shell 程序熟不熟悉、文本处理工具和各种『脚本语言』诸如 AWK、SED、Perl、BC、APL 还有各种基于 pipe 的 coreutils 工具诸如 sort、shuf、uniq、head、tail，还有 expr 之类的，再至于 Python 会不会，是不是真正的了解 Python（元编程是起码的，当然即使会到『这个层次』已经『了解得深很多了』想和一些无论是理论还是工程方面或者兼而有之的 PL 巨佬讨论恐怕还是显得智商捉鸡吧）

一个『好』的系统管理员其实是很困难的，因为他要『什么都会』『什么都了解』，比方说计算机网络那些东西有些不好学的东西都得了解，如果真的能啥都会真的是很困难的事情

对于一个系统管理员来讲，我觉得好像『会写』Sh/Bash 脚本是一个标杆，但其实嘛，脚本『复杂』与否也是很重要的...

考完试回来看看这个... 其实嘛，有时候我会觉得理论或者说学术、工程或者说实践并非是平级的东西 #tech #dev #CS

有的时候大家或许能感受到，很多理论非常 NB 的大佬工程都很 NB，而且他们从来不把他们 NB 的工程当成什么（举个例子，从 09 年开发到现在的 G'MIC 计算机图形学系统，很多滤镜插件的发布就简单一篇帖子，开发从来没有专门讨论什么或者写什么博文，非常低调）

（说到这里，我现在开始有点不是特别相信 WWW 上会传给大家的知识了，不得不指出，现在如果单单用那些 General Purpose 的 Search Engines（比如 DDG）（百度垃圾，不用说了）

很多知识真的是找不到的，就比如百度上搜索 G'MIC 根本没有多少有价值的中文结果，都非常 trivial，少就不说了，再说说现在一些比较深刻的学科，比方说是嵌入式工程，不看书很多东西不用说百度（因为它是垃圾啊，真是『鲜嫩多汁』），Wikipedia 上可能真的是英文结果都不全的（翻译什么的不用吐嘈了，我觉得喷翻译什么的大概可以自己去翻译，Wikipedia 上都是这么搞的，你行你上这里是真理啊！）

百度搜索 "watchdog" （之前是没有多少结果的，估计这几年年轻人进嵌入式行业大门了，然后好像写了不少博文什么的，百度百科居然也有了）
（没有贬义，我觉得嘛 Internet 这么好的东西又那么蓬勃发展蕴含信息量少是缺点应该尽可能往上面放好东西）


而反过来就不一样了，很多工程师都没有那个技术资本去弄理论


好像就是理论就比工程高那么一点，但其实嘛也不尽然，也有『工程的理论』（软件工程理论，比如说软件工程理论、软件测试理论、软件分析、面向对象什么的）
即使是本来一个领域的『理论科』过去学的话还不是要时间要熟悉一会...（排除那些真正的天才


总之我就是觉得... 呃... 其实系统管理嘛，就像我们平时做的开发一样，有人成天会问怎么『创建对话框』『为什么它提示这个』『阻塞是什么为什么这里不让』，对自己用的程序设计语言狂喷『某某语法怎么怎么难看应该精简一下』

但是也有人痴迷于计算机科学的各种子科，计算机网络、计算机图形学、人工智能、算法和数据结构、电子电路、程序综合、软件工程、，他们甚至是『跨领域』的斜杠青年

但即使是这样，从最开始 Von Neumann 那套到现在信息技术一直在蓬勃发展，即使『水』的东西越来越多，也依然有人默默避过各种网上交流平台上无关紧要的撕逼朝着自己想要的高度脚踏实地去迈进

为这些人点赞。

正是因为在那些 trivial 的工程旁边还有这种真正的魔法存在，计算机科学才显现出她独到的智慧，像数学但比数学更严谨更实用，可以为各种领域服务，解决各种各样奇特的问题，
计算机科学是一门实用的学科，一门真正实用的学科。好用看得见（e.g. 你们看的影视特效啊... 基于机器学习的推荐算法啊... 人工神经网络啊...）

正如虽然我们的身体素质要求开始越来越低，奥林匹克精神和奥运会也仍需坚持一样。这些理论也是未来，不会因为对现在大部分开发者的素质要求越来越低而丧失生命。

hhhhhh 🌝

考试成绩除了英语外的所有科目总分加起来居然只比英语高 1 分... 也是 #NB 了 🙈 #Haha

#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好玩