这是fengyqf的博客
根据用户记录，按一定时间周期，计算用户留存量、留存率。
留存率 = 留存量 / 初始量 * 100%
从某一个时间段作为起点，作为初始用户，一年后这些用户还有多少，两年后还有多少… 以此即可做计算。这里有个问题，就是这个起点的用户，是否也是从更早以前即存在、并留存到现在的；如果把本身即是“留存”而来的，留存率是不准确的。所以，通常要以用户首次出现开始计算。
简单来说，就是从新用户开始，计算其N一个时间段后留存；而每个时间段，都有新用户，所以这是个斜三角形的表。
已有原始数据表，包含了每个客户的销售记录，包括销售时[……]
问题：有两张表 users, addrs，需要从users表中删除一些行，条件为在“addrs”表中没有对应id的行。
事实上很简单，只是个left join查询，SELECT a.*,'|' s,b.* FROM users a LEFT JOIN addrs b ON a.id=b.id;，预览如下：
然而，postgres本身不支持 DELETE … LEFT JOIN … 这样的语句，这点不像MySQL那样方便。
有一个曲线救国方法：
把上面LEFT JOIN的结果表视为一张中间表，把原users表、按主键 inner join[……]
先上代码
regexp_replace("source_html",'\s*(<[^>]+>|<script.+?<\/script>|<style.+?<\/style>)\s*','','gi')
作用，使用regexp_replace函数，清理html标签，也包括整个<script>…</script>, <style>…</style>的代码块。[……]
这也是一篇草稿了好几年的文章，一时半会儿也不大可能继续完善了
wordpress本身安全性，可以通过安装一些插件实现，
防垃圾评论
禁用xmlrpc协议的一些api，减少针对 xmlrpc.php 的攻击。其中：
Security Settings: 4个选项全部启用，尤其第一个默认未开启”Disable JSON REST API” 推荐打开，
防止暴力登录尝试。推荐允许重试4次，把拦截时间设置成60分钟或更长时间
管理[……]
从字符串解析HTML文档，返回根节点
lxml.etree.HTML(text, parser=None, base_url=None)
Parses an HTML document from a string constant. Returns the root node (or the result returned by a parser target). This function can be used to embed “HTML literals” in Python code.
To override the parser with a diff[……]
使用MySQL做数据，有时会隐约感觉到一些语句执行速度极其慢，而理论上应该是很快的。通常使用phpMyAdmin作为客户端，在表结构页里可以方便的看到索引状态，对基数cardinalyty一知半解，隐约理解为惟一值个数。
但前两天写一条查询语句执行速度非常非常慢，看到一个索引的基数竟然是空的，而且明明应该有很多值。猜测MySQL出bug了，于是删除并重建了索引，基数正常了，语句也飞快跑完。于是稍多留意了一下索引基数。同一天，看到一个基数为1的索引，也是很多惟一值的字段，这也不正常。因为是MyISAM表，直接打包了对应的.frm, .MYD, MYI 三个文件，保留一个现场，[……]
这只是个无聊的小把戏。
最近又看到关于qwerty键盘布局的讨论，有提到好的键盘布局标准之一：把连续的按键分散在左右两手上，这样第一只手击键的同时，第二只手可以提前做好准备，提高效率。
于是从网上找了一批古典英文小说的txt电子版，写了个傻傻的脚本，统计其中连续两个字母的频次（忽略大小写），其中频度最高的前30项如下表。这30项共计占总频次的43.3%.
如前述，“是否可以把连续击键分散在两只手上”，即表格最后一列。从结果上看，分散与否各15项，所以qwerty在这个标准上优势似乎并不明显。
当然，这并不能证明qwerty键盘是不合理的；毕竟评估因素非常多。[……]
FireFox 扩展Adblock Plus
使用原则：只阻止过于反感的广告，其他广告一律放行；亦即，自带的过滤列表一律不激活。
创建和编辑您的过滤列表
//pos.baidu.com/ //static.mediav.com/js/
[……]
MySQL的缺陷/Bug/异常/陷阱/注意事项
这里只是个记录，踩过的坑
REGEXP 对中文的错误识别，如下语句，结果竟然是1，在 MySQL 5.5.53, MariaDB 5.5.60, MySQL 5.7.24 下测试结果一致.
SELECT '区中医院' regexp '[一二三四五六七八九十〇]{6,}' as mt
这个问题是在utf8-general-ci 数据表上做regexp匹配连续的数字汉字时发现，暂时没测试否与字符集的选择相关，猜测是regexp本身行为对宽字符集支持的问题。
已确认 MySQL 8.0.4 以后解决了该[……]