不要自己造轮子

Don't repeat yourself

DRY这句话大家可能耳朵都听出茧子了。不过,这个确实是非常重要的一个填坑要诀。

拿正常的开发(非填坑)来说,使用别人造好的轮子可以大大提高效率和开发进度。
我上次用的别人的大轮子是开发微信公众号和小程序的时候,用的wechat这个开源lib。使得集成微信的工作量大大减少,不必看微信那么多的文档和接口。

专门拿填坑来说,使用别人造好的轮子比正常开发要显得还重要一些。当然这里的轮子主要是原来工程中使用的轮子了。尽量使用工程中原来使用的轮子,别自己造,更别使用其他人的轮子。

我见过最常最轮子的方法就是类似于StringUtils和CollectionUtils这种,用来判断empty,用来split等。


- 阅读剩余部分 -

本周开始做搜索功能优化,这边的搜索功能主要用的是ES。代码写好提测给测试同学的时候,测试同学说搜不出东西,我排查了下,是ES的索引的mapping同线上不一致,线上的mapping增加了三个分词插件,分别是ik,NGram,pinyin,搜索的时候对这些插件扩展字段进行的搜索。

现在就是要把测试环境的索引mapping修改成同线上一致的,我采用的是下面的方案:

  1. 新建一个原索引(index)的备份索引(index_bak),这个备份索引采用线上一致的settings和mappings,可以直接将线上的settings和mappings复制到json文件里。

    curl -XPUT 'http://127.0.0.1:9200/index_bak' -d '@create_index_bak.json'

- 阅读剩余部分 -

我转到现在这个海外事业部的时候,这边使用的开发环境和测试环境都是docker。每个开发者都有自己的docker开发环境,自测通过后,部署到测试环境。

但是使用的时候,发现开发环境和测试环境都有一个问题,就是不论是service还是portal的日志,每30分钟就被清空了,我以为是被log4j归档了,看了下归档文件夹,里面有这个日志文件,但是文件为空。

这个问题实实在在困扰我了好久,因为无法追查历史日志,导致测试报问题的时候,只能去重现实时tail日志,非常麻烦。

我一开始以为就是log4j配置的归档时间是每30分钟,但是我看了log4j的配置文件,是1个小时,线上也是这个配置,线上没有这个问题。

后来我怀疑,是不是这个docker本身对某些卷定时操作,但是我看了下docker的启动配置,也没有。

并且,每个人的开发环境和测试的测试环境都有这个问题,很很很很奇怪!

再来后,开发任务紧张,这件事就放下了。

- 阅读剩余部分 -

首先,crontab要执行的任务要有输出日志,表明任务执行过。

然后,另起一个crontab任务,去监控上面的这个日志,比较日志的更新时间,判断任务是否执行,从而提醒。

下面是我在实际生产环境中使用的一个脚本示例:

timestamp() {
  date +"%s"
}
url="http://报警url"

last_mofidy_timestamps="$(stat -c %Y /home/example/example.log)"
echo $last_mofidy_timestamps

current_timestamps="$(timestamp)"
echo $current_timestamps

if (($current_timestamps - $last_mofidy_timestamps > 3600)); then
    curl $url
fi

我的blog使用了cloudflare的https,在typecho里也开始https后,初看一切正常,但是登录后台时,返回302,重定向到了登录页。

我在网上搜索了好久,记录下解决方案。

修改typecho下的这个文件:

config.inc.php

增加如下代码:

define('__TYPECHO_SECURE__', true);