Forwarded from dnaugsuz
讲个笑话：文本上直接中文分词 + Naive bayes 朴素贝叶丝分类（如果 Chinese Lexical Analyize 全字典大了就上精简字典什么的... 有并行计算高性能框架的）
短图二维码和 short link 跳转用消息队列慢慢查
行为上算个大体的策略，虽然不得不接收所有消息的
可信用户的选择可以对每个群设置一个基准，连续发送 N 个安全消息的就算可信用户
行为不要老是看维度什么的，又不必要 kNN（何况 ML 领域又不是 kNN 一家独大，kNN 明明是最入门的算法之一，虽然也不只是 kNN 可以接收「多维度」），你反个 spam 比 spammer 还开销，还不如不反
Telegram 的 spammer 一般也就靠二维码、short link、裸消息文字了，二维码的还不能发重复图片，因为会被直接认出来
很多 userbot spammer 就是加能加的群，然后入群慢慢发广告，发几个可能退出可能继续待着
普通用户就算是偶尔刷消息，在广告屏蔽上也不应该予以屏蔽，也可以节省资源来做到更大并发量
非得从 0 开始监督式学习，要大量数据，反而不好，何况这个模型也不好设计（即便我们只是说「用户的行为」，比如说 Telegram 里有些群只在中午交流、有些群是深夜，得为每个群制定标准，这合适吗？）
我觉得没必要为了 anti-spam 去收集用户行为，因为对几乎所有群聊来说，很多 spammer 就是发个广告而已，可以做简单一点，踢出屏蔽随机进攻的 AD userbot 即可
对于误封，可信用户若是不小心被查到（可能是误查）spam，则不踢出群聊，发警告 + restrict 就可以了，等待管理员确认
短图二维码和 short link 跳转用消息队列慢慢查
行为上算个大体的策略，虽然不得不接收所有消息的
onMessage, 可是对可信用户的检查可直接跳过 / 随机抽查 / 添加人工 bot command 允许群友重新审查可信用户的选择可以对每个群设置一个基准，连续发送 N 个安全消息的就算可信用户
行为不要老是看维度什么的，又不必要 kNN（何况 ML 领域又不是 kNN 一家独大，kNN 明明是最入门的算法之一，虽然也不只是 kNN 可以接收「多维度」），你反个 spam 比 spammer 还开销，还不如不反
Telegram 的 spammer 一般也就靠二维码、short link、裸消息文字了，二维码的还不能发重复图片，因为会被直接认出来
很多 userbot spammer 就是加能加的群，然后入群慢慢发广告，发几个可能退出可能继续待着
普通用户就算是偶尔刷消息，在广告屏蔽上也不应该予以屏蔽，也可以节省资源来做到更大并发量
非得从 0 开始监督式学习，要大量数据，反而不好，何况这个模型也不好设计（即便我们只是说「用户的行为」，比如说 Telegram 里有些群只在中午交流、有些群是深夜，得为每个群制定标准，这合适吗？）
我觉得没必要为了 anti-spam 去收集用户行为，因为对几乎所有群聊来说，很多 spammer 就是发个广告而已，可以做简单一点，踢出屏蔽随机进攻的 AD userbot 即可
对于误封，可信用户若是不小心被查到（可能是误查）spam，则不踢出群聊，发警告 + restrict 就可以了，等待管理员确认
自从 @ANTI_SCP_079 事件发生以来，作为项目的发起者，我从未公开发声。一部分原因是，我不想助长恶意捣乱者的兴致，给他们的关注越多，他们就越高兴，而我们说得越多，他们断章取义得就越多；另一部分原因是，我在等待一个草稿原则以及方案的完成，此草稿一定程度上说明了 SCP-079 的初心与思路。
当然这中间有很多人劝我应该说点什么。是的，当有人无端指责我们的时候，我应该说点什么的，当有人利用网络暴力人肉出我们的开发者的时候，我应该说点什么的，当有人聚集起来抵制抹黑所有中文反广告机器人的时候，我应该说点什么的。
但，我怎么说呢？
我该向别人建议的那样心平气和地向所有人做汇报吗？我该像木头人一样对待这种事情丝毫不生气吗？我该一板一眼地念几句公关文字来回应吗？不，不，不，我不想也变得像质疑我们项目的人那样，质疑他们背后的真正目的，我也不想陷入和他们争论的无止境循环，今天我只想说一些肺腑之言。
有人有这种论调：那你们什么额外目的也没有，为了什么？用爱发电吗？你们总得图点什么吧。
对此我想回答：是的，我们就是用爱发电。我不想说 “如果你们这样下去，会把真正做事的开发者的心弄凉的” 这样的话，会有人认为这是威胁论。反而，我想说，正如反对机器人的人士说的那样，“一个机器人倒下去，千千万万个机器人站起来”，即使你把一个开发者的心弄凉了，还有另一个开发者、还有另一群开发者有 “用爱发电” 的心。
所以，即使之前的草稿方案可能经过我们的后续讨论会完全推倒，但我还是选择这么早就把草稿放出来，为的是分享我们的想法，虽然并不成熟、并未实现、可能变化，但是所有人都能看到我们的想法，有心人或批判、或继承，都可以利用其中的一些想法去实现自己的项目。这样假使 SCP-079 项目组倒下了，也会有人去做类似的事情。
抵制中文防广告机器人的人士，你们要明白一点：只要群组仍旧受广告侵袭一天，需要自动化处理中文广告的需求就会存在一天。这点是不会以任何人的意志为转移的。你们当然有自由今天抵制张三，明天抵制李四，但你们得意识到，必须有人做类似的防广告项目。所以充分考虑到你们的透明需求，我们在一开始就选择要开源，如果不信任我们托管的公共服务，任何人都可以根据源码动手搭建自己的服务。我们同样提供完善的搭建指南，确保有一定动手能力的人都可以顺利完成自行搭建的任务。
不过遗憾的是，原方案的主要开发者已经由于抵制 SCP-079 人士的人肉，被迫退出了项目组。我们原本有些起色的进度，陷入了停滞状态，即使其他工作繁忙的开发者能抽出时间接手，我们还要重新考虑原方案，乃至从头规划一个新方案。从我个人角度来看，我不得不说，这是很令人受挫的事情，@ANTI_SCP_079，你把我们的一片好心给糟蹋了。
如果很乐观地讲，SCP-079 项目最终能够完成。我们也会对申请使用机器人的群组进行认真的审核，确保真正负责任的、有意愿的群组去使用它，而不是那些只是盲目地为了图省事的群组。群主及管理在享受机器人带来的便利、节省大量时间的同时，也应该有一定付出，首先自己要花时间去了解机器人运作的机制，并做到和群友之间的良好沟通，让他们知道我们群有什么机器人，如果对封禁有疑问该找谁，今天删了我的表情包是因为什么，明天我发一段俄语被删了又是因为什么——说清楚自己群组做的自定义设置，而不是一味地只推说是什么机器人删除的。如果反广告机器人本身都得不到群主的理解、支持和配合，那么面对一些无中生有的指责，机器人也只能百口莫辨。好的生态需要双方的共同努力，我想这个观点对大部分机器人都适用。
以上就是我个人想说的话。下面我介绍一下原则草稿和方案草稿，事先声明：此草稿并不能作为最终我们采用的方案，并且其中的错误是在所难免的，我们也不希望任何人使用草稿中的纰露之处来继续对项目进行攻击。
— TEAM SCP-079 [origin]
当然这中间有很多人劝我应该说点什么。是的，当有人无端指责我们的时候，我应该说点什么的，当有人利用网络暴力人肉出我们的开发者的时候，我应该说点什么的，当有人聚集起来抵制抹黑所有中文反广告机器人的时候，我应该说点什么的。
但，我怎么说呢？
我该向别人建议的那样心平气和地向所有人做汇报吗？我该像木头人一样对待这种事情丝毫不生气吗？我该一板一眼地念几句公关文字来回应吗？不，不，不，我不想也变得像质疑我们项目的人那样，质疑他们背后的真正目的，我也不想陷入和他们争论的无止境循环，今天我只想说一些肺腑之言。
有人有这种论调：那你们什么额外目的也没有，为了什么？用爱发电吗？你们总得图点什么吧。
对此我想回答：是的，我们就是用爱发电。我不想说 “如果你们这样下去，会把真正做事的开发者的心弄凉的” 这样的话，会有人认为这是威胁论。反而，我想说，正如反对机器人的人士说的那样，“一个机器人倒下去，千千万万个机器人站起来”，即使你把一个开发者的心弄凉了，还有另一个开发者、还有另一群开发者有 “用爱发电” 的心。
所以，即使之前的草稿方案可能经过我们的后续讨论会完全推倒，但我还是选择这么早就把草稿放出来，为的是分享我们的想法，虽然并不成熟、并未实现、可能变化，但是所有人都能看到我们的想法，有心人或批判、或继承，都可以利用其中的一些想法去实现自己的项目。这样假使 SCP-079 项目组倒下了，也会有人去做类似的事情。
抵制中文防广告机器人的人士，你们要明白一点：只要群组仍旧受广告侵袭一天，需要自动化处理中文广告的需求就会存在一天。这点是不会以任何人的意志为转移的。你们当然有自由今天抵制张三，明天抵制李四，但你们得意识到，必须有人做类似的防广告项目。所以充分考虑到你们的透明需求，我们在一开始就选择要开源，如果不信任我们托管的公共服务，任何人都可以根据源码动手搭建自己的服务。我们同样提供完善的搭建指南，确保有一定动手能力的人都可以顺利完成自行搭建的任务。
不过遗憾的是，原方案的主要开发者已经由于抵制 SCP-079 人士的人肉，被迫退出了项目组。我们原本有些起色的进度，陷入了停滞状态，即使其他工作繁忙的开发者能抽出时间接手，我们还要重新考虑原方案，乃至从头规划一个新方案。从我个人角度来看，我不得不说，这是很令人受挫的事情，@ANTI_SCP_079，你把我们的一片好心给糟蹋了。
如果很乐观地讲，SCP-079 项目最终能够完成。我们也会对申请使用机器人的群组进行认真的审核，确保真正负责任的、有意愿的群组去使用它，而不是那些只是盲目地为了图省事的群组。群主及管理在享受机器人带来的便利、节省大量时间的同时，也应该有一定付出，首先自己要花时间去了解机器人运作的机制，并做到和群友之间的良好沟通，让他们知道我们群有什么机器人，如果对封禁有疑问该找谁，今天删了我的表情包是因为什么，明天我发一段俄语被删了又是因为什么——说清楚自己群组做的自定义设置，而不是一味地只推说是什么机器人删除的。如果反广告机器人本身都得不到群主的理解、支持和配合，那么面对一些无中生有的指责，机器人也只能百口莫辨。好的生态需要双方的共同努力，我想这个观点对大部分机器人都适用。
以上就是我个人想说的话。下面我介绍一下原则草稿和方案草稿，事先声明：此草稿并不能作为最终我们采用的方案，并且其中的错误是在所难免的，我们也不希望任何人使用草稿中的纰露之处来继续对项目进行攻击。
— TEAM SCP-079 [origin]
#JavaScript ... 这个问题其实蛮没价值转发到这里的，提个醒。
Forwarded from dnaugsuz
不可以
eval(const ....) 的Forwarded from dnaugsuz
... 其实 const 不应该用作 eval 的字符串，有点这个意思
即使它可以定义变量为不可变
即使它可以定义变量为不可变
Forwarded from dnaugsuz
eval 是有值的，所以你本来可以
或者
const config = eval(env.CONFIG_JS);
或者
const config = fileA_exists? eval(faExpr) : eval(fbExpr);
最好不要滥用动态Forwarded from dnaugsuz
let [a, b] = [1, 2];
const c = eval('a + b'); //c=3Forwarded from dnaugsuz
在不必要的情况下使用
如果不是要动态生成 JavaScript 代码或者要实现插件系统之类的东西，不要用
不能把可以写死的代码写进 eval
比如能够
eval 是坏习惯如果不是要动态生成 JavaScript 代码或者要实现插件系统之类的东西，不要用
eval 和 Function(String) 不能把可以写死的代码写进 eval
比如能够
global['str'] = 1;就不要在非严格模式下（此时变量是顶层对象的属性）
eval(`str = 1`);Dijkstra.kt
4 KB
#Kotlin #Algorithm 本苏又双花了两个小时写了 Dijkstra 算法，发现自己的手速还是 Naive,
foreach (cost, neibor) if (newcost < rs[neibor].cost) rs[neibor] = (newcost, step) 都写不出了
dnaugsuz
讲个笑话：文本上直接中文分词 + Naive bayes 朴素贝叶丝分类（如果 Chinese Lexical Analyize 全字典大了就上精简字典什么的... 有并行计算高性能框架的） 短图二维码和 short link 跳转用消息队列慢慢查 行为上算个大体的策略，虽然不得不接收所有消息的 onMessage, 可是对可信用户的检查可直接跳过 / 随机抽查 / 添加人工 bot command 允许群友重新审查 可信用户的选择可以对每个群设置一个基准，连续发送 N 个安全消息的就算可信用户 行为不要老是看维度什么的，又不必要…
可以分开文本的「类型」，而不是简单地「黑名单」和「白名单」正是使用 Naive Bayes 有趣的地方
Naive Bayes 是文本分类的算法，你可以给被学习的文本指定其类别，然后对新文本进行猜测分类
分类当然可以有很多种，比如广告、清真、色情、政治
只需要数据集足够、分词算法优化就可以了
如果有机会写这种机器人，就叫「NBMAK」吧（Naive Bayes Model AD Killer） 🤔
考虑一下...
Naive Bayes 是文本分类的算法，你可以给被学习的文本指定其类别，然后对新文本进行猜测分类
分类当然可以有很多种，比如广告、清真、色情、政治
只需要数据集足够、分词算法优化就可以了
如果有机会写这种机器人，就叫「NBMAK」吧（Naive Bayes Model AD Killer） 🤔
考虑一下...
duangsuse::Echo
🐴 类个 🍺， #Kotlin 这 typealias 也太蠢萌了吧，和预处理有什么区别？
error: type mismatch: inferred type is Dijkstra.Node<String> but DijN<T> /* = Dijkstra.Node<T> */ was expected🌚👍 请问 Kotlin 大大：这个
T 是什么玩意；真是连预处理模板都不如typealias RouteSelectB<T> = MutableMap<DijN<T>, WNode<T> > // Node : Edge-Node我用的有错吗？为啥
open class Dijkstra<T: Any>
fun backtrace(rs: RouteSelectB<T>) = fun(end: DijN<T>, start: DijN<T>): List<DijN<T>>
T 就成了 T？难道真的是直接强行标识符名字填进去不加解析？我还以为是不能递归展开重写了一遍也没用 infer 失败一堆不好看🤔 Typealias ❌ file-level only & no type variable resolution
🤔 Type argument +
(* -> *) Kinds (Type argument for type variables) ❌ not supported, <GraphB : Map<DijN<T>, Set< WNode<T> >>> not compatible with Map<DijN<T>, Set< WNode<T> >>
🤔 (inner)Subclass ❌ Cannot inherit from Pair<A, B>: it's final....
🤪 Expand typealiases by hand and remove the use of type extraction ✅
error: type inference failed. Expected type mismatch: inferred type is Dijkstra.WNode<String> but Dijkstra.WNode<T> was expected瞬间服气
well done.
Dijkstra.kt
4.7 KB
男人看了流泪，女人看了沉默... 😭 #Kotlin