qt: https://bgme.me/@bgme/107535312088996380
试了一下,饼站长说的“通知记录也有总计400条的数目限制”也不对……notifications API 每页 15 条,也是可以翻页,而且没有任何限制,我拿我自己做实验,获取到了 7000+ 通知,直到我刚刚来象的第一条通知都能获取到.
饼站长给出的代码(https://github.com/mastodon/mastodon/blob/afb788218913061a36fad9b14e2e3e34025cc25b/app/lib/feed_manager.rb#L9-L15 )里的 400 应该是别的什么东西.
这么看来,长毛象并不是不适合抽奖,抽奖在技术上不会有任何问题. 我是不是应该去读读饼站长的抽奖脚本的代码,看看 ta 是怎么写的(?
@zero
>试了一下,饼站长说的“通知记录也有总计400条的数目限制”也不对……notifications API 每页 15 条,也是可以翻页,而且没有任何限制,我拿我自己做实验,获取到了 7000+ 通知,直到我刚刚来象的第一条通知都能获取到.
这确实是我搞错了
读完了,抽奖脚本没毛病,并不会对任何人不公平,所有转发者都能获取到,任何人抽奖都可以放心用那个脚本!
我实在是不太明白 ta 为啥前几天突然发那条说长毛象不适合抽奖的嘟,还用了错误的论据来论述,看脚本感觉 ta 也不像是不懂的人啊😯
脚本唯一可以改进的地方是:那个脚本获取了被转发数,当目前获取到的转发者数量不等于被转发数时,就翻页翻到下一页继续获取,直到翻完了所有的通知,nlist.lenth 等于 0 了,才直接 end loop.
实际上,据我观察,从通知里获取到的转发者总数可能是会小于嘟文记录的被转发数的,我猜测原因有二:
1. 有些非长毛象账号的转发会被计数但不会被通知,比如 ovo.st 小组的转发;
2. 可能有些人删号注销后和 ta 有关的通知就都被删掉了,但被转发数没有更新(我猜的,不确定)
所以那个脚本的一个改进思路是:获取嘟文的发嘟时间,循环获取通知时,检测每一页第一条通知的 created_at,如果早于发嘟时间,直接 break.