非对称不是这个意思……
每次加密结果不一样的是用了随机 iv 的加密方式,例如对称的 AES。
而以 RSA 的使用场景(签名、交换对称加密的 key 等),并不需要随机 iv。
用半衰期模型最高效
假设一个词被搜索,它的热度 + 1,然后这个热度就像放射性物质一样,随着时间指数衰减。
所以换个思路,你不要记录热度,而是记录热度衰减到 1 时的时间戳。
那你只要在词被搜索时,更新它热度衰减到 1 的时间戳,最后按照这个时间戳排序就好了。
举个例子:
半衰期一周
这时 A 比 B 热度更高。
假如 2 周后
2**1
= 2,如果又被搜索了 2 次,更新它的时间戳为 log2(2+2) = log2(4) 周后2**0
= 1,如果又被搜索了 4 次,更新它的时间戳为 log2(1+4) = log2(5) 周后这时 B 比 A 热度更高。
半衰期模型缺点是你只能预设一个固定的半衰期,如果修改了这个长度,在过渡阶段,排序会不太准确。 过渡时期,取数据时可以多取一部分,再按新逻辑进行重排一下,过了过渡时期就好。
是连续的。而链表小的没数组快,大的不如存 redis,其实并无实用意义
React 现在是有点臃肿了。如果只是做个绑定,CDN 纯引个 VueJS 也比较简单
按标准实现的浏览器会把请求中的 Origin 替换掉
凡用 token 验证的,都不需要 CSRF
另外由于大部分浏览器支持 Origin,现在服务器验证 Origin 对不对就可以了,也不用 CSRF token 了
同占座
YAML 本身不搞 ERB 的 Rails 的配置文件其实是先 ERB 了再 YAML 的
本来就有……
npm 只敢在虚拟环境用,太多木马了
好可怕…… 幸好我早就改用 post-css 了,而且不用 bootstrap 了,而且不是用 gem 的 bootstrap 了
这就不需要 .seconds
了吧...
(1..200).step 8
1.upto 200, step: 8
可以简单点: a.sort_by{|(x, y)| [x, -y]}
你可以 ri String.format
看看为什么
def f n
[*(1..n), *(1...n).reverse_each].cycle {|n| puts '*' * n }
end
不能。你的例子可以 .map &:succ
嗯嗯其实 lateral join 很快的
Rubinius 是碰到 second system syndrome 了。。。 mjit 只是从无到有的一个 baseline jit, 后面还有很多优化可以继续做。
自己统计
SecureRandom.rand 4294967295
不过不保证唯一
真的需要 random 么?不需要的话数据库 int id
如果反过来用 React 实现 Turbolinks 呢……?
这个场景,一直感觉没什么用的 wide column store 好像很适合: https://db-engines.com/en/article/Wide+Column+Stores
sl_tables 在这些数据库里对应的概念是 column family.
Pg 最多只支持到 1600 个列,传统来说要在上面实现一个 BigTable 就只能 EAV 模式了,有 jsonb 后各种完美了。
想起了 Cassandra 的 column family 和 column …… 就是 CQL 没有 pg 的 SQL 好用
表 B 的 m 从表 A 的 n 中消耗
不懂什么意思,能换个方式阐述吗?
微服务满天飞有好多原因:一是部门变多需要分蛋糕的政治决定,二是产品找不着方向要乱做一通增加了复杂性,三是架构师需要先把问题搞复杂再摇身一变成为大救星…… 但是每个服务都要把重复的事情做一遍,极大的降低了效率。
既然伴随公司成长这些折腾难以避免,不如用统一框架和标准搞一套基础设施,所以 ServiceMesh 就出来了 —— 但这和购买云服务差别大么?云服务知道哪些基础设施价值最大,所以才提供这些服务呀,例如自动扩容,消息队列,配置管理…… 而剩下的你用 ServiceMesh 能做的事情,价值都不大
python 里就是正则表达式难用...
用大括号代替缩进:
from __future__ import braces
特征太多了,你要按着 metasploit 做一遍……
充满了豆知识 🤦♀️🤦♂️
def kai_encode num
num.to_s(32).tr('0-9a-v', '1-9a-km-x').ljust 48, '1'
end
Ruby Quiz 没继续下去可惜了