表字段, 是 拆分 vs 合并.

要思考: 字段是频繁读 vs 频繁写.

多读少写(写一次不变更) 和 频繁写的数据, 显然不适合放在一起.

顺便, 有些表字段, 是要加锁的(事务), 大量表字段, 是不需要的. 同上.

要搞清楚设计的本质目的是什么. 你就知道该不该放一起.

POS 机设备, 是有自毁机制.

如果是卖非联网客户端软件的, 怎么防破解, 都是徒劳的. 用户要破解你, 多半是定价不合理.

如果设备软件可以联网, 改成服务端联网检测 license 有效期就好了. 只有服务端检测, 才能低成本解决盗版问题.

防盗版, 从硬件上思考, 是徒劳的.

联网检测, 连 Windows 都是这样, 你还想啥? 没有人比微软更懂防盗版, 笑....

https://github.com/better-dart/toolbox

可以参考这个目录结构.

是使用 GetX Cli 生成的默认结构, 稍作改良.

https://github.com/jonataslaw/get_cli

GetX Cli 生成的项目模板结构, 挺合理的.

@buyan3303 python 能学会, dart + flutter 自然也能学会, 这是和 javascript 一个难度的东西.

Qt 不要碰, 生态和工具链全面过时, 无人问津的东西.

你现在干事情, 就好比在 2022 年, 问大家, 怎么安装 win XP 系统一样.

你要做的就是: 不要装 XP. 更好 /更简单的方案, 多得是.

flutter 很简单. 官方文档, github 的案例多的很. 可能你去 GitHub 扒拉个项目代码, 就满足你的需求了.

照着改就像了. 大多数 flutter app, 基本都集成了 sqlite.

这是 rust 学习者的常态. 跟 C++ 一样. 都是暴露设计复杂度给所有人.

rust 和 c++ 都是功能 强大性 vs 易用性, 平衡失败的典型案例.

c++ 经常是为了敲个钉子, 先要发明个锤子, 然后发现没有车床, 就造了个车床, 之后就忘了自己要干什么...

rust 对 c++, 是用复杂对抗复杂. 本身从理念上, 并没有进步.

平衡性, 过去(现在不是)做的好的是 go 和 python. 未来看, 可能是 zig.

rust 只是: 群众, 对当前一个能打的没有的现状的妥协. 比起 c++, rust 虽然难以下咽, 但咽下去了, 还是香的.

吐槽之余, 可以看看 zig 的设计. zig 的平衡性做的非常好.

基本用了很少的语法特性(1 周掌握), 实现了 rust 绝大多数需求点.

简单易学+性能出色. 语法设计也很有美感.

rust 这种"符号学大师", 是典型不懂 "减法原则".

不知道你从哪里听到用 python + QT 的方案写 GUI. 这种过时的不能再过时的方案.

没人回答你, 是因为没人用这个过时方案. (这感觉就像: 大家都在用 iPhone, 你非要用诺基亚板砖)

既然是非程序员, 你应该学习 dart + flutter 来写 GUI.

sqlite3 只是个文件数据库, 所有语言, 都有现成的库操作. 非常简单.

flutter 也很简单. 你有闲工夫看过时的 Qt 文档的功夫, 用 flutter 已经写完了.

另外不要滥用 celery, 这东西, 本身是个调度器, 做定时任务用还行.

常规的 MQ 需求, 踢开 celery, 直接写业务代码, 操作 rabbitmq/kafka 就好.

当然, 如果是维护的不值钱代码, 当我没说.

应该没有什么队列产品, 满足你这奇怪的需求. 不只是 celery.

队列, 只是管道, 是无状态的.

你想改 task 状态, 是业务需求. 需要自己单独设计方案.

给个思路:

1. task 数据包内, 定义 task_type 字段.
2. redis, 根据 task_type, 动态调整优先级 level 值.
3. 定义第一级 MQ 管道 + task worker, 此 worker 主要做调度器. 收到 task 时, 根据 task_type, 查询 redis, 判断实时优先级, 进而决定:
- 立即执行
- 转发到另一个队列中, 等待其他 task worker 处理.
- 忽略丢弃
4. 次一级的 MQ + task worker, 无脑执行.


celery, 可以是个管道链. 其他消息队列, 都可按照此思路设计业务.

@yunyuyuan UI 层确实是 html/js/css 的主战场.

既然已经接受了 html 方案. 就不应该继续使用 python + eel 这种优点全无的方案.

flutter(上手更简单), rust + tauri 和 go + wails 都是更好的选择.


> PS:


flutter 和 tauri, 我都有写产品实践.

flutter 写 mobile app 体验一流.
tauri 可以快速把一个 前端(vue/react) 项目, 直接转换成 desktop app, 基本一行代码都不改.

各有优势. tauri 的优势是可以无痛复用整个前端生态, web 有的, 都可以复用. 这比 flutter 有天然优势.
flutter 另起炉灶, 基本在复刻 web 生态的路上. 任重道远.

总之, 当下时间节点, UI/GUI 方案, 都有很成熟可靠的方案.

不要浪费时间在没有任何优势的方案上. 可能你的产品还没写完, 项目就先死了.

如果这个方案, 都能接受的.

相信 flutter web 的加载速度, 也能接受.

起码 flutter web 会持续优化加载速度. 而这种方案, 可能就别想了.

PS:

rust 生态, tauri + vue, 写桌面版, 也是一个很好的方案.

python 不适合这种场景, 就别瞎浪费时间了.

有这功夫, 又学会一门语言了(dart+flutter).

简单看了一下源码, 跟踪了一下依赖包.

https://github.com/justpy-org/justpy/blob/master/justpy/htmlcomponents.py#L76

干了很多脏活累活, 这种包, 后续维护下去, 苦不堪言.

可能最终都会是不堪重负, 不了了之.

GUI 的方案已经很多了, 没必要用 python 写.

web 系的方案, 成熟可靠. 实在讨厌 web, 还有 flutter + dart 可以选择.

dart 语法非常简单, python 开发者基本不用学. 上手写就行了.

这些小众方案, 往往浪费很多时间研究, 最终发现都是不满足需求.

substrate 是区块链脚手架框架, substrate 的价值自然毋庸置疑.

但是, 如果你问了这个问题, 大概率当前的水平, 学了, 直接收益也不大(找不到对应工作).

substrate 对标的岗位, 要求很高.

对技能的广泛度和深度, 而这些, 和 substrate 本身无关. (是工程师的基本素养)

我向来不鼓励任何人参与知识付费的方式来学编程(懒人 + 缺乏主观能动性 = 水平不会高).

等你彻底放下: 偷懒(走捷径)思维, 才有可能成为一个更好的程序员.

cargo_modules 指的是本项目自身的模块.

cargo-modules 包名, 在包模块导入时, rust 会自动转成 cargo_modules 方式来导入(约定规范).

社区主流包命名风格是 - 模式, 导入是 _ 模式. (自动转换)

要习惯这个约定.