之前参与过一次讨论，确实不只是 Ramdom 那么简单。主要是不能确定抽奖总次数（总人数）。
一般简单的需求只是提出了中奖概率：一等奖中奖率 1%，二等 3%，三等 5%，为了方便讨论，姑且再简单化每个奖项奖品数量为 1 。
然后大多数人一上来的写法就是 random1~100 ，然后得出指定的一个或者多个的数，来做中奖判断。
实际上这种简单模型，只遵循了理论上的中奖率，没有符合到实际需求。因为中奖变得“先到先得”更为重要了（可以写个模拟抽奖 demo 测试一下），但实际上一场抽奖活动更多的是希望吸引更多的人流，并不想活动开了半天大奖全部抽完。
所以当时我盲猜两种做法：1 极度调低实际的中奖率，配合活动结束时间稍微调整让奖品都能送出； 2 也是要配合活动时间定时定量动态调整奖品中奖率。

我理解的提议是：不能 new 定义的父类，只能 new 其子类。那就在父类的构造函数直接抛错？（子类不调用父类构造函数）

我上一个项目就是这么搞优化的

但并不是随便找个项目就能这么做，是刻意的，以教学为目标的 github 项目

还有一个建议是，与其耗时间证明那么多，不如同时般地，花更多精力着手开发新功能，新界面，然后走一条防抄袭的路。东西可以抄，但思想抄不了。

markdown 的发明，只是创立和统一了一种新写法，可惜没有把渲染也统一起来。。。

@leonkfd 不是那个自动刷新频率。我说的是指多久变化一次。
比如早上打开看到了这句诗，这个壁纸，稍微欣赏了一下后，可以一早上打开都是这个内容，然后到了下午（或者一段时间后），再打开就变化了。
其实是参照了 win10 的锁屏，如果不喜欢壁纸甚至可以手动点一下切换。
其实使用这个机制的话，也有效缓解一下图片服务器不稳定，配合本地做一下缓存几条数据（图片或诗）。现在选随机图每次打开几乎都是看到彩虹壁纸~
以上仅提出参考

建议类似随机壁纸，随机古诗这种，可以设置一天（或一定时间）才更一次。古诗如果能点击弹窗看到解释更好了（虽然见到有交互时间设置但不知如何配合实现）

随机图库还是慢了些

R9000p ，裸机 2.5KG ，出行带个 PD 充头

没有其他人有同样的情况？

大学四年的一个总结是：只要是玩电子的，都很烧钱。

我觉得定期关机或者重启一下，是个好习惯

这边厢喊招不到人，那边厢面试了很多家没找到合适~

我看到的一个重点是，这种上万的电子产品，在保修期内正常使用居然也会出现这种问题，让我入手 MBP 的意愿又谈了~

即使这个月发布了，理性消费的应该也要等市场反馈产品情况。也就是说你可能要等到春节附近（狗头

你们都拿来干嘛用？

建议折现

像阿里这样的大厂不会维护 centos?