这是 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 方式来导入(约定规范).
社区主流包命名风格是 - 模式, 导入是 _ 模式. (自动转换)
要习惯这个约定.
买手柄 🎮 + 电视 📺 / 投影仪 or 大屏显示器+ 电脑 🖥, 才是更舒服的.
我的 NS, 就当成主机模式在使用. 这么小的屏, 玩啥都降体验.
躺在床上, 拿着手柄 🎮 操作, 才是正确打开方式. ns 都嫌沉.
手柄, 也适合和女朋友 /老婆 一起玩, 你拿个 deck, 自己玩, 不怕家庭不和谐吗?
@
aijam 68L, 已经给出了答案.
跑了一下示例数据, 没啥问题.
你这运营数据有点意思.
你可能需要使用 python + pandas 之类的工具, 来写个统计+计算脚本, 可能很快.
提供一个粗糙的思路:
1. 2 组数据, 先排序(小<大).
2. 数组 2 数据, 计算一些特征值(暂存):
重复值先 count 计数, 并 sum() 部分值.
计算数组 2 的 均值, 众数. 并作为后续遍历的结束条件.
3. 因为数组 1, 是由 数组 2 构造的. 比如 17.76, 必然由 < 17.76 的数组合成(废话). 遍历时, 可以剔除 > 17.76 的值.
结合 二分法 + 遍历, 应该不需要完全遍历.
数组 1 排在前面的计算结果, 也是 后面的值的一部分.
按照这个思路, 应该可以写一个能用的算法. 哈哈
1. 家里有矿, 可以辞职待业(半年-1 年), 学技术: go, rust 都可.
2. 家里没矿, 找个厂, 先干着. 宁闲勿忙, 空闲之余, 跳 1 学技术.
3. 学好英语, 有精力就考个雅思 /托福. 英语好, 任意工龄, 薪资都可翻倍. 翻不了, 来找我.
3. 学好英语, 有精力就考个雅思 /托福. 英语好, 任意工龄, 薪资都可翻倍. 翻不了, 来找我.
3. 学好英语, 有精力就考个雅思 /托福. 英语好, 任意工龄, 薪资都可翻倍. 翻不了, 来找我.
不用在意经济周期, 既然是周期, 就会过去.
实力够了, 穿越牛熊, 都很自然.
不要向下看, 向下, 深不见底. 力争上游.
6L 正解.
以上其他 L, 扯淡.
鉴于提问在 go 标签下, go 的 Context, 主要有 2 种用法.
1. 用于替代全局变量, 更安全的透传"偏全局的"参数. 常用于: web 的 http Ctx, 携带 http 请求参数, 并在透传中, 注入新的参数, 向下传.
2. 并发控制. 更优雅的控制 Goroutine 退出. 常用于: db/redis/mq/rpc 等中间件 client 的退出管理.
多看一些 web framework 源码, 在 graceful shutdown 处, 都可看到 context 的典型用法.
其他语言, python 的 django http request 的源码, 也有类似设计.
Context, 是一种设计范式. 至于是要在 main 全局定义, 还是局部定义, 是具体业务场景决定的. 具体问题, 具体分析.
我给出的 2 种用法, 就存在 main 全局定义的 ctx, 也存在定义在局部的 ctx.
PS:
不懂, 就不要强答, 误人子弟.
写代码, 不是八股文. 要搞清楚本质.
错的答案, 比不回答. 更糟糕.
你这个型号可以刷 openwrt 哇?
我的主路由器是 Linksys MX5300, 目前刷不了 openwrt, 最近想搞个旁路由刷梯子.
看有推荐 R2s, R4s, GL.iNet MT1300.
tb 搜了下有 R5S. 跟你这价格差不多. 不过内存要大一些.
https://www.v2ex.com/t/753015鉴于我过去哪个 华硕八爪鱼, 刷梅林, 512MB 内存, 感觉很不稳定.
你这个刷固件后, 梯子稳定吗?