不要自己造轮子

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);