不要什么词频,不要什么云图,只要一个结果

上一次说过: 利用类词频来做表单字段自动关联选择优化  ,很久以前还讲过:像API一样地通过Dell设备SN号自动获取准确的设备型号 。这些东西的。发现前面那个思路不对,以前的思路是从已有的库内分析得到结果。那么,问题来了,库内分析可能会带来的影响:

1、对自身服务器查询的压力;2、精准度实在不怎么样;3、实现难度相对大

现在反过来,通过互联网“库外”查询来获得你想要的东西。“趴一趴”是不是也很有趣。结果同之前的方式跟目前爬取互联网数据分析的结果对比:

1、不触发对自身服务器的查询;2、精准度大大提高了;3、实现更是简单了

继续阅读不要什么词频,不要什么云图,只要一个结果

得一8GB内存服务器便肆无忌惮使用redis缓存

开始把软件部署到新的设备中。主要是看上CPU和磁盘IOPS都比之前使用的辣鸡设备强很多。尤其是磁盘,有了Raid10的支持。稍微测试了一下比原来的性能高3~4倍甚至更多。而且整个软件好像并没有做线程的设计,再感觉Python对CPU的要求又比较高。不知道是不是程序哪里的问题,反正,并没有预期的运行快。早在年初便想聊聊django cache的了。无奈,直到现在才稍微能写得出手,都是因为你笨啊。 继续阅读得一8GB内存服务器便肆无忌惮使用redis缓存

JavaScript 排序导致的错误

标题有点low,因为他们通常会用xxx引发的血案来命名。哈哈~1千600个瞧不起。自己选择的路,不管有多长也要跪完。背景:单台设备信息上架录入系统的时候不允许保存不连续的U位信息。因此,需要一个严格验证表单是U位信息是否连续的功能(放在前端,保证后台收到的表单数据U位永远都是连续,另外,前端直接提示,方便用户直接更正)。 继续阅读JavaScript 排序导致的错误

您已花光您今年的所有人缘

因为某种原因,有时候真的会忽略或错过太多太多不应该忽略和错过的事物。当然,这根本大家都不想要的结果。比如,“浪费”时间在你并不很专业的事情上,(每次隔壁在开会,我都觉得批评的那个人就是我,哦赫赫)欲或者是中了王者之毒(当然,这才是真的浪费,因为你并不是真正的王者呀,啊哈哈)什么的。【摊手】+【耸肩】我还能怎么办呢? 继续阅读您已花光您今年的所有人缘

像API一样地通过Dell设备SN号自动获取准确的设备型号

标题有点长哈,首先感谢实习生小x提供爬取的代码。由此可见一个人战斗的效率实在低得可怜啊。什么需求分析、后台前端都一个在make。当然,该抄的抄,改粘贴的地方粘贴。但还是一样令人心力绞碎啊。 继续阅读像API一样地通过Dell设备SN号自动获取准确的设备型号

从维持不断篇到差点断篇,这个月发生了什么

标题有点长也有点有趣哈,这里想要说明的并不是喝酒断片,当然,近期的喜酒也没少喝。从博客后台的数据显示,最后一次更新文章都是在上个月的21号了.原本以为一天就可以更新几篇垃圾文章的我到目前已是一个月更新一次甚至如标题所言要维持不断篇而书写了。 继续阅读从维持不断篇到差点断篇,这个月发生了什么