前几天还在为 pytorch 如何部署以及如何融入到图像处理流程中苦恼，没想到图片分类这边在短短几小时内给调试过了，并迅速融入到整个图片处理流程当中。

其实这也很容易理解，以图搜图的图像识别需要多次经过专用算法：

1. 特征值提取：通过 pytorch 调用模型提取特征值并存储起来。
2. 计算特征值：由于特征值的量级比较大，并且又不是简单的数值或字符串匹配，而是调用专门的算法。

虽然可以将图库图片在后台预先处理（这里可以与业务流程分类），但是用户上传还是需要在业务流程中在进行特征值提取以及特征值相似度计算，在没有足够算力的情况下，这个过程非常影响使用体验。相反标签搜索仅仅是数据搜索匹配问题，一下子就将一个看似复杂的算法问题转换成一般意义上的业务数据处理问题。

这里就简单介绍一下基于 deepdanbooru 的图片分类以及衍生出来的标使用标签进行与管理的问题

事实上这篇文章属于一个大的分类，属于个人的一个愿景。

我一直在寻找属于自己的知识管理方式，其实说起来也非常简单，满足两个基本需求：

1. 快速找到需要的内容，包括自己总结过的结构化与非结构化数据。
2. 组成知识网络，根据某一个关键点找到关联的知识。

经过较长时间的实践，试过了很多软件，都感觉要将自己的一套归类总结逻辑迁移去出去并被迫改变，同时又没有很好的编程接口。最终对于知识总结和录入方式选择为 Obsidian ，输出结构化 markdown 文本后通过编程完成解析和选择输出模板，同时完成知识提取和展示。

在非结构化数据管理上图像管理也是一个大难题，图像与文本不同，逻辑上的管理还停留在 TAG 或 mate dta （元数据）的层面，这最大的问题是做图片标签和分类以及元数据管理。这完全是重复性体力劳动，再加上图片存量相当大，对于个人来说几乎是不可能完成的。逻辑分类其实是倾向于准确的逻辑分析归纳式管理，目前似乎只有机器学习通过已有模型来实现。关于这点还在探索中。

图像管理上还有一条路就是以图搜图，以图搜图更像是基于观感上的，图像结构上的图片比较。对于图像风格比对也仅仅是看过文章说明，没有见到过可用的产品或开源项目。这里简单描述一下最近对于结构上以图搜图的探索和时间结果。

这里所描述的资源管理是指API管理，或者接口管理。最初的目是实现一个基于角色权限的细粒度访问控制，同时具备自上而下与自下而上的两种配置与管理方式。

在实际的权限管理中，受特别是后端的权限管理有非常大的不透明性。除了开发者本身，在接口这个粒度上几乎没有人能完全知道系统中，甚至功能点中到底有哪些接口。所以更实际的方式是采用白名单管理，不做配置就没有权限。这种基于白名单或者黑名单的管理方式我称作为自上而下的权限管理。这种方式的缺点就是基于人工的有限配置带来的规模限制与精确控制的限制。

春节假期下了几天雨，体感又潮湿又阴冷。无意间在图片收藏里看到这张。

在2022年新年伊始回想起2021年的经历，发现竟然没有什么值得关注的事情。整个2021年基本在埋头工作，这其中有不少内容是在对之前期望和目标以及一些执行方法的实践。就如同最近看到一本关于知识管理的书里面说的3W理论，即先问why（为什么），接下来how（如何），最后才是what（什么）。在现实中大多是直接what，直接得出结论。这也许是当今这个知识与内容高度泛滥的年代我们被迫养成的习惯，快速得出一个结论并快速执行。就好像看到电商网站不厌其烦给推送商品，我们要做的就是立刻决定买还是不买，很多时候甚至忽略了购物的本质。而现在的网络环境又有非常明显的自动归类与转借概念的现象出现，大多数时候我们只是在一个给定的范围内选择，在范围之外又出现大量的新生概念与转借的“名词”。这样层层间隔让人将很多行为自动归类到一些概念上去，这样进一步加速自我思考与行为的自动归类。加剧了不经思考被各类概念裹挟的被动选择，再加上社会分工越来越精细，接触的信息越来越固定化，想要遇事多思考摆脱信息茧房越来越困难。

低代码这个概念不知道是什么时候出现的，不过在我印象中类似的说法似乎已经有很久的历史。

对我来说真正开始思考是在大概三年前开发一款相对复杂的流程审批系统开始的，当时需要设计在一个较大的组织架构中多角色与用户的流程审批功能。在最终选择使用activiti6做底层实现后开始了符合实际业务场景的改造，这主要包括流程设计器对接外部的角色与用户系统，流程设计器的节点对接外部接口调用（比如通知），流程跳转节点与内置表单组合后支持表达式的判断。而后端代码增加了动态的节点权限赋值，任意节点取消，运行中的流程图修改，主业务异常后的流程数据补偿等。

等上线后发现实际业务和流程有非常强的耦合。业务上线是先各方面定下一个业务流程，有些流程可能非常长非常多的审批人员，或是复杂的节点逻辑。随后前后端开发人员实现，并按照业务绘制流程图，发布流程图，业务上线后在配置中选择与最新的流程图编码（编码一致，版本可升级）绑定。运行一段时间后我发现业务流程虽然支持绘制流程图进行版本升级，进而变更流程执行逻辑，但是实际这样用的场景非常少，因为流程的变更需要具体业务代码的支持。而很多业务模块在设计中有非常强的上下文依赖关系，无论是框架还是上下游接口都无法支持调整顺序。导致最终这个流程编辑功能如果要变更必须伴随着业务系统的变更，也只有对外部系统的调用是达到预期的。

那时候开始我就在考虑，是否可以从业务节点的“原子化”封装与上下游接口的统一来达到业务节点的执行顺序变更。非常直接的思考就是，如果一个业务能封装与拆分的足够好，理论上是可以任意组装的（当然跑起来能不能符合业务流程是另外的问题）。

这里就简单聊一下近期接触的“低代码”平台原理与实现方式，并说一下我个人最近针对低代码的探索。

这里需要构建一套文本处理系统，当然了构建系统从来就不是一蹴而就的，必须要面对客观环境与实际的需求，系统将来是什么样这谁也不敢保证。但是系统本身就是对客观与现实世界的抽象与归纳，对于系统的构建和设计从一开始又不能拘泥于当前环境。总是说了那么多就一句话，功能可以没有，但是设计一定要到位。

这里简单介绍一下我的选型路线，包括前端和后端，移动端目前又处在一个选择的路口。因为Flutter2的发布，以及明确的跨平台方向。桌面是否有能力挑战Electron这是我非常关心的，不可否认的是Electron是现在开发桌面应用的首选了，但是我对其运行方式一直不是很满意，因为大量的基于其开发的PC软件给我非常不好的使用体验，包括印象笔记，和大量的PC端音乐播放软件，这里特别要说网易云，最近的它的启动似乎越来越慢了。移动端在熟悉Flutter2前，先用响应式前端凑凑数。

个人数据的问题自从进入互联网时代几乎成了困扰每个人的问题。

当时刚工作的时候几乎对任何事物都存在非常强烈的好奇，想把接触到的一切东西都存起来。存的东西非常的杂乱，比如各种漫画，番剧，剧集，电影以及各种大量的二次作品，当然还有一个最主要的原因是网络环境非常的糟糕，也就是所谓的“小水管”，在线看视频都要缓冲好久，下载资源即便是迅雷也是常年几十KB（当然这不排除是资源本身就非常偏门）。相对的在线观看最多的还是看二次创作的作品，影视作品更多的还是下载之后再看。

2020年现在回忆起来从各个方面来说都是不平凡的一年，这年改变了我之前心里最大的关于未来的不确定预期。

从19年开始显得尤为明显的是整个互联网行业伴随着整体经济的增长速度放缓，各个细分领域的业务增长红利都渐渐失去。表现出来就是整体投资变少了，之前红红火火的创业仿佛突然没有了，大部分小型的创业公司都难以熬过一到两年。社交媒体上也弥漫着各类业务萎缩，员工福利与薪资的各种抱怨，以及某些行业大佬宣扬的今年是以往最差的一年，也是未来最好的一年。

不知道从什么时候开始对现在每个季度的新番开始渐渐失去兴趣了（和上图没关系）。

回想起来最近追番感觉非常不错的是19年的1月，那时候的《灵能百分百》、《玛娜利亚》和《烟草》真正的让我非常期待下一周的到来。即便是回来补的《天使降临我身边》和《荒野的寿飞行队》都给我带来的非常好的观感。另外《飞行队》比较奇妙，我暂时把它归为军武题材。虽然表现形式上非常不错，但是似乎这感觉总不是很对的样子…

随后到来四月本来最期待的《Carole&Tuesday》和《皿三昧》也由于各种原因没有追下来，再加上《水果篮子》以及《鬼灭》刚开始给我不好的观感，其实四月我似乎都没有追什么新番的样子，就这样一直到来七月。而七月随便看了看《埃尔梅罗二世》以及《一方》就这样来到了八月。

Time Capsule

一、我的水果笔记本

2014年入了当年的新Mac，记得这貌似是难得的屏幕下面没有印制文字的版本。用了4四年到了2018年几乎也没有出现什么问题，所以每次看到设置项中的时间机器选项虽然觉得非常必要，但是也没有真正想过来一次备份。说道Mac的好处其实有很大一部分是水果全家桶的功劳，Mac也同样的有非常高的一致性，虽然这点没有iOS来的高。对于开发者来说其固态硬盘和Unix环境真的是让人很难拒绝，而我还有自己的需求那就是文字。

说真的我第一次在益田的水果店看到Mac屏幕的时候真的给我很大的冲击，虽然一开始键位并不是很舒服但是那种打字的感觉和字体渲染效果让我非常着迷。之后我的大部分文字工作都在Mac上完成，包括了很多很多内容。