灵感:小说人名生成器

灵感来源:村上春树《我的职业是小说家》

特性:

  1. 根据百家姓生成
  2. 提供情感分析,正派角色不会给一个反派倾向的名字
  3. 提供选项,根据选项来生成名字,【性别,是否爱运动,是否爱看书,是否是特定职业】等等。
  4. 提供提供一个黑名单的机制,用过的不会出现,避免撞衫。(可以将生成的名字做 hash,对比 hash ,如果 hash 存在,则重新生成一个。hash 放在 redis 里。)

科学需要证伪

再上一篇文章中,我提到了,想要去做一个前端的队列。

和几个朋友聊了聊,他们认为这个东西不值得做,因为没有价值。

在我看来不这样认为。

就这样的话题而言,证实很容易。只要实现,并证明可用,就可以完成证实的内容。

但是,更重要的是证伪,需要证明这个东西,虽然可以做出来,但是并不好用。具体的不好用是多么不好用,具体的量化。这样才能算完成了证伪

灵感:P2P 消息队列

灵感来源

今天在 V2ex 和别人讨论我写的《离用户近一点,再近一点》时,提到了队列、3rd API

关于 3rd API 的问题,我可以理解,因为涉及到安全问题,我们需要将 token 放在后端。如果安全问题可以解决,放在前端也不无可能。

关于队列的问题,我就有了想法?为什么不可行?

队列主要问题有三处

  1. 消息通讯
  2. 选举问题
  3. 调度问题

关于消息通讯,可以考虑实现 P2P 网络来链接不同的前端设备;而选举问题,可能需要我去看看拜占庭将军问题,以及了解一些数学相关的东西。其中,老王给我了一个思路,可以看看分布式队列的实现逻辑。

调度问题也可以参考分布式队列。

在搜索的过程中,找到了香港城市大学的教授的研究页面。

https://staff.ie.cuhk.edu.hk/~mhchen/projects/p2p.queuing.html

搜索关键词

peer to peer queue

peer to peer message queue

补充信息

搜索过程中,发现问题被简化了,可能有一些可能可以在前端实现队列的工具,比如 ZeroMQ。