邮政编码在国内使用得越来越少了，以前还有一些做邮编查询的网站现在都看不到了，不过我们的邮编库✉️网站一直都在，而且还在不断更新和扩展。
这里介绍一个我们今年推出的地址邮政编码数据库子栏目，这个站主要特点是海量单位的地址信息及其
祁劲松的博客文章
这是一篇记录我过春节前后与同事商议网站内容和质量问题时候的博客，主要要点如下：
- 内容质量>>内容数量，不再堆积和追求数量
- 别人已有内容，我们再做的意义不大（如中文字典、成语词典），除非有创新
MediaWiki和Drupal都自带了站内搜索功能，我们多年都是直接调用，只在少数情况下尝试其它的，例如✉邮编库网站因为数据量过大，Wiki站的搜索常导致MySQL数据库卡住，后来改用了Sphinx才不再卡住，但搜索结果不尽如意，有一些莫名其妙的不相干结果，估计是没有把Sphinx摸透、没有专门加对中文的分词包吧。
Drupal站也尝试安装过Apache Solr Search，感觉太复杂了，勉强用了一下，没有深入研究。Drupal站还用Views来进行过搜索、安装过Auto Complete，以及直接用SQL语句来进行搜索。
另外，
Drupal里面Views功能很方便、强大，而在PHP程序中调用Views的Page或者Block也很需要，有时还可以起到替代写SQL语句的作用，不过需要带参数变量Block的调用不太常见，以前用过也老是忘记调用办法，昨天又花时间找了一下，现在就记录下面，免得以后又到处去找。
views_embed_view('views_name', 'page_or_block_id', 'variable');
详情请看Drupal官方网站中的API文档：views_embed_view
春节以后网站流量逐步回升，刚刚过去的2019年3月基本恢复到以前正常状态，甚至有些站达到流量新高，不过服务器的资源偶尔也会报警，特别是遇到有大量采集或者攻击的情况时，这很影响用户体验，我们也不得不花费大量时间来排查、屏蔽采集🙁。
前些天遇到“服务器上的所有网站疑似遇到攻击”更是耽误了我们两天的时间来对付，这两天用户访问也受到一定影响。在这个排查过程中，我们发现涌来的峰值流量是我们正常流量的2倍以上，如果我们的服务器配置资源足够的话，那比较小的攻击或者采集是无需采取措施的👌。
最近广告联盟的单价有所回升，我们还拓展
查号吧☎这个网站有很多年历史了，1998年就开始提供长途电话区号查询服务，2008年使用Wiki系统开放用户提交电话号码、曝光骗子，去年开始又增加了一个子栏目：电话号码库📞，我们主动来收集整理企事业单位的固定电话号码（考虑到隐私问题，暂不提供手机号码数据）
前一阵子突然接到法院递送的EMS，打开看是我们公司被北京某图片公司告了，我们一个很多年前的网站上有一幅图片被诉侵犯了该公司的版权。
我们这网站是2009年建的，对方提供的证据截图也显示有一个页面是2009年编辑的，
今年1月份记录了一篇《清除百度MIP缓存，纠正跳转错误》，当时是在百度移动搜索(m.baidu.com或者baidu app)中的搜索结果跳到错误的MIP页面上，通过清除该域名下所有MIP缓存解决的，估计是百度的移动网页索引中哪里出了问题。
时隔一个多月，2月中旬后再次出现百度移动搜索中的搜索结果跳转到错误的网址，而这次不是MIP页面，而是普通的响应式网页页面，在移动搜索结果中显示的网页标题都是对的，就是点击后到了错误的网址，例如统一都跳转到 www.example.com/xxx/node/40933 ，里面的内容明显不匹配，而对应的百度PC搜索(www.b
网站遇到采集者是很常见的事情，因为采集太快太多导致我们服务器负载过高的事情也时有发生，我们一般都是收到网站打开太慢或者服务器负载过高报警的消息后及时进行处理，在apache设置.htaccess上把该屏蔽的屏蔽就可以了，偶尔需要用到ipt
这两年我们新建网站多数都采用了《在Drupal中直接导入、使用数据库》这篇文章中说的办法，而没有用以前新建内容类型、导入到Drupal的Node中的办法，这对于数据量大、改动不大、读取多、写入少的需求很合适。
偶尔遇到需要修改、删除的事情，我们就是到阿里云RDS管理后台，Web界面来操作或者用SQL语句来进行，比以前在Node页面进行编辑要麻烦，但更改量不大的情况下也可以接受。
最近要用的一个新站也是用直接建表方式来搭建的，但内容需要人工来修改完善，而且是长久都需要添加、维护信息的，再用以前导入RDS后台就显得太麻烦了，于是想去找现成的