同意, 我经常用这个题目, 实际情况是 10 个有 9 个只能到双重循环, 剩下一个能进一步到使用集合之类的数据结构.
大多数人对算法复杂度都没有概念, 经常提出一些奇奇怪怪的优化方案, 比如使用 Steam 流, 用 ForEach, 两个列表先排序等等, 当然这里是小公司, 对于大厂人员, 素质想来会高一点吧
@
Scarb 好像有点理解了, 所有的消息会广播给所有的消费组, 但是组内会直接拉取全部并过滤, 所以如果我想要的是一部分消费 t1, 一部分消费 t2, 搞两个消费组就行, 我之前以为消息只回传一次, 一边消费完了就没有了, 其实如果新建消费组订阅的话, 消费位点会从 0 开始, 这样理解对吧
@
onepunch 我就是按文档写的呀, 按我的理解, 我生产了一条 tag=t1 的消息, 然后我订阅 tag=t2 的消息, 这个消息不应该被消费者收到, 我也确实没有收到, 但是这条消息同时也应该留在队列里面, 不应该是被消费的状态, 但是我这里确实显示被消费了, 所以百思不得其解
经过几天研究, 可能搞定了, 主要还是靠 pmset -g log 分析日志, 看 WakeRequest 都是些什么东西
一开始是 CSPNEvaluation, 反正是跟 PowerNap 有关的, 想办法改配置文件禁用掉了, 不行
后来是一些 Scheduled power events, 用 sudo pmset schedule cancelall 全部取消掉, 还是不行
再后来发现第二天所有的计划任务又重新冒出来了, google 之后, 先全部 cancel 掉, 然后 sudo chflags schg /Library/Preferences/SystemConfiguration/com.apple.AutoWake.plist 把配置文件设为只读, 貌似可以了
现在过去 2 天都没有半夜耗电的毛病了, 感觉差不多应该是好了, 真是艰难啊
昨天晚上观察了一下, 问题依旧, 早上起来只剩 50%电, 观察活动监视器的能耗没有结论, 因为这个就像是普通的唤醒电脑的样子, 都是一些正常的 APP 的待机能耗使用, 整个看上去就像是半夜 2 点电脑被唤醒打开, 然后 APP 正常待机工作的感觉, 但是实际上是全程不插电, 没有任何外接, 合盖的情况下发生的, 完全搞不懂了, 看日志的话, 只能看到是 0 点的时候进入睡眠, 但是只计划睡眠 2 个小时, 然后两个小时后 DarkWake from Deep Idle, 时间是 6 小时, 反正搞不懂这些计划安排是怎么来的, 头大
2024-07-18 00:15:12 +0800 Sleep Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=disabled Using Batt (Charge:97%) 6422 secs
2024-07-18 00:15:14 +0800 Wake Requests [*process=powerd request=CSPNEvaluation deltaSecs=6459 wakeAt=2024-07-18 02:02:53] [process=powerd request=UserWake deltaSecs=23163 wakeAt=2024-07-18 06:41:17 info="com.apple.alarm.user-invisible-com.apple.calaccessd.travelEngine.periodicRefreshTimer,480"]
2024-07-18 00:15:14 +0800 PM Client Acks Delays to Sleep notifications: [com.apple.bluetooth.sleep is slow(1555 ms)] [com.apple.apsd is slow(2025 ms)]
2024-07-18 02:02:13 +0800 Assertions PID 128(powerd) Created InternalPreventSleep "Holding in darkwake for up to 20 seconds to query model for inactivity prediction" 00:00:00 id:0x0xd0000972d [System: DeclUser SRPrevSleep kCPU kDisp]
2024-07-18 02:02:13 +0800 Assertions PID 128(powerd) Released InternalPreventSleep "Holding in darkwake for up to 20 seconds to query model for inactivity prediction" 00:00:00 id:0x0xd0000972d [System: DeclUser kDisp]
2024-07-18 02:02:13 +0800 Assertions PID 318(mDNSResponder) Created MaintenanceWake "mDNSResponder:maintenance" 00:00:00 id:0x0xd0000972f [System: DeclUser kDisp]
2024-07-18 02:02:13 +0800 Assertions PID 318(mDNSResponder) Released MaintenanceWake "mDNSResponder:maintenance" 00:00:00 id:0x0xd0000972f [System: DeclUser kDisp]
2024-07-18 02:02:14 +0800 DarkWake DarkWake from Deep Idle [CDN] : due to EC.SleepTimer/SleepTimer Using BATT (Charge:97%) 21039 secs
2024-07-18 02:02:14 +0800 HibernateStats hibmode=3 standbydelaylow=10800 standbydelayhigh=86400 1704
2024-07-18 02:02:14 +0800 WakeTime WakeTime: 1.516 sec
2024-07-18 02:02:15 +0800 Kernel Client Acks Delays to Sleep notifications: [AppleIntelFramebuffer driver is slow(msg: SetState to 1)(988 ms)] [powerd is slow(17629 ms)] [UPSB driver is slow(msg: SetState to 2)(936 ms)] [UPSB driver is slow(msg: SetState to 2)(935 ms)] [AppleHPMIECS driver is slow(msg: WillChangeState to 2)(1094 ms)] [AppleHPMIECS driver is slow(msg: WillChangeState to 2)(1097 ms)] [AppleUSBVHCIBCE driver is slow(msg: SetState to 1)(318 ms)] [RP01 driver is slow(msg: SetState to 0)(1009 ms)]
2024-07-18 02:02:15 +0800 Kernel Client Acks Delays to Wake notifications: [RP17 driver is slow(msg: SetState to 2)(316 ms)] [UPSB driver is slow(msg: SetState to 2)(948 ms)] [UPSB driver is slow(msg: SetState to 2)(948 ms)] [ADIO driver is slow(msg: SetState to 2)(627 ms)] [ATY,Boa driver is slow(msg: SetState to 1)(366 ms)] [UPSB driver is slow(msg: SetState to 2)(942 ms)] [UPSB driver is slow(msg: SetState to 2)(962 ms)] [AppleHPMIECS driver is slow(msg: WillChangeState to 2)(1113 ms)] [AppleHPMIECS driver is slow(msg: WillChangeState to 2)(1118 ms)] [AppleIntelFramebuffer driver is slow(msg: SetState to 0)(352 ms)] [ATY,Boa driver is slow(msg: SetState to 0)(344 ms)] [AppleUSBVHCIBCE driver is slow(msg: SetState to 1)(324 ms)] [RP01 driver is slow(msg: SetState to 0)(1015 ms)] [RP17 driver is slow(msg: SetState to 2)(313 ms)] [UPSB driver is slow(msg: SetState to 2)(941 ms)] [UPSB driver is slow(msg: SetState to 2)(941 ms)] [ADIO driver is slow(msg: SetState to 2)(620 ms)] [ATY,Boa driver is slow(msg: SetState to 1)(371 ms)]
我没有接任何外设显示器之类的, 和这些无关, tcpkeepalive,powernap 原先设定是 1, 感觉关系应该不大, 1 代表接电源才启用, 我这个是没接电源就耗电的, 反正这两个先设成 0 试试
倒是那个音频的东西是有可能的, 通过 pmset -g assertions 能看到 PreventUserIdleSystemSleep 是 1, 是由火狐进程触发的 BuiltInSpeakerDevice 的 preventuseridlesleep, 退出火狐就没了, 还有之前也装过 blackhole 的虚拟声卡, 现在我也卸了
该做的都做了, 就看会不会复发了
https://en.wikipedia.org/wiki/Rounding可选的舍入方式有 6 种, 常说的四舍五入对应 infinity 这种, 在 c#里面也叫 AwayFromZero, 但是这个会有统计学误差, 所以另一种常见的舍入方式是 even, c#里叫 ToEven, Java 里叫 HalfEven, 也就是上面有人提到的银行家舍入
不同的语言, 不同的函数使用的舍入规则都是不一样, 比如 toFixed 和 Math.round 用的就是不一样的, MySQL 的 decimal 和 float 规则不一样, 如果追求 100%精确的话就得去看文档他们用的到底是哪一种方案, 或者 Java/c#这种可以有选项让你控制使用哪一种舍入规则
之前有段时间研究过数独, 如果像第五版里说的用类似穷举的方法解数独没有问题, 可以解出来, 顶多一些难题要花费好几秒钟, 但是即使是一些简单的题, 没有经过优化, 计算机最终的步骤数都在千到万这个级别, 这样出结果没有问题, 但是要输出可以给人看的步骤太粗犷了一点.
说白了, 这里的穷举只是相当于应用了基本的唯一余数技巧和候选数加回溯的算法, 要真的生成可以给人看的步骤, 需要实现人所用的技巧, 比如
https://hodoku.sourceforge.net/en/techniques.php 这里列出的几十种从简单到复杂的解题技巧, 但是这样算法逻辑就会大大复杂了
不过这个 HoDoKu 是开源的, 可以用他的 C#算法复刻一遍转成文字再输出, 大概可以
个人理解: 敏捷里面, 快速迭代是最核心的价值, 2 周是一个合适的时间, 超出这个时间, 团队整体就会效率低下, 因为大家需要在一个不长不短的时间节点收到反馈, 互相沟通, 改进方案, 重启下一个迭代
所以估算任务也需要确保所有任务的点数在 2 周范围内完成, 如果超出, 就需要拆分任务到 2 周之内, 分解任务是确保估算准确的核心
虽然理论上故事点不该和天数挂钩, 但是确实事实上一定会挂钩, 只不过不同团队标准不一样罢了, 比如我会定每天的人力为 3 点, 一周 15 点, 2 周 30 点, 我会确保所有分解后任务在 15 点以下.
所以如果我估算一个任务 3 点, 意味着要 1 天做完, 估算 10 点, 大概 3 天做完, 15 点一周做完.
估算故事点的难点在于不同团队的任务是不一样的, 如果是维护型的任务或者 CRUD 之类的, 很好估算, 因为有参照, 但是复杂的任务, 非功能性需求, 或者探索性的任务是不好估算的,
这个时候给出的估算基本上就是纯凭经验, 相当于只是给一个截止日期, 想要准确的话就要 leader 参与分析, 给出他的估算, 最后决定, 不知道这算不算"背对背专家估计"
总之敏捷的核心我认为还是在快速迭代中去应对"变化", 即使我个人认同敏捷宣言中的各项价值观, 但是保不齐就是有人更喜欢文档,流程,计划,工具这些, 所以如何和这些人和谐相处合作, 也算是"敏捷"的一部分
@
MoYi123 大哥, 能详细说一下这个方案吗? 是不是要换 ES, MySQL 能搞么
要不用解构的方式导出本地变量计算, 算完再导回 dict
A, B, C, D, E, F, G, H, I, J, K, L = dict.values()
A = B + C
D = E - F
G = H * I
J = K / L
dict = {"A": A, "B": B, "C": C, "D": D, "E": E, "F": F, "G": G, "H": H, "I": I, "J": J, "K": K, "L": L}
我大概能理解 OP 的思路, 很多年前我做一个 C#的项目的时候, 那时候是架构师自己搭的框架, 思路就是所有的 Service 放到一个静态类里面, 比如叫 ApplicationServiceManager, 简称 ASM, 任何时候要用的时候直接 ASM.UserService.GetUser()就行, 其实用起来也挺爽的, 要用的是时候直接 ASM 点 XXX 出来所有的 Service, 当时架构找呢么解决初始化和循环依赖的我已经忘了, 但是至少这条路是可行的
但是我还是觉得这套思路和现行的 Spring 体系不太搭, 就像楼上说的, 现在只要用 lombok 配合构造器注入, 几乎是无感的引入需要的 Service, 感觉挺简洁的, 那套集中式的 Service 管理感觉要自己在底层架构引入很多额外的约定和设计才能做出来, 感觉也比较重, 也不利于代码维护和单元测试
总之相比之下我还是偏向普通 Spring 的注入体系
有闲心的话, 造一个代码生成器, 比如我正好为了练习 python, 就写一个代码生成器, 定义好基础类的字段, 一键生成实体类, 数据库脚本, dao/service/view/page 等等, 再配上 copilot, 写 crud 直接起飞, 节约下来的时间摸鱼, 或者改进这个代码生成器, 增加各种选项和分支.