这是学习笔记的第 1950 篇文章
今天有三点学习的启示，要说启示，必然会有相关的背景故事。
第一个：模糊的标准可以给出示例，共同提高
今天在处理一个业务需求的时候，发现开发同学的需求写得比较详细，但是过程不够专业，从我们的角度来说，提交的脚本应该是可以执行的。但是这位同学提交的是一些文字的描述，从描述和过程来看，他对于里面额数据导入过程不太熟悉，他知道需要使用LOAD DATA命令，但是使用细节不大清楚。
所以保险起见，他加了一些描述:
附件中的数据格式样例如下：
test|2|20170724|144|1|10
数据说明：平台|包ID|时间|事件ID|数1|数2
在这种情况下，如果还是一味要求脚本可执行就有些为难这位开发同学了，所以我做了一个折衷的方式。
操作完成后，我把使用的命令发给了他，然后告知他后续如果有请求就可以按照何种按时来提交了。
命令内容如下：
LOAD DATA LOCAL INFILE 'test_data.log' INTO TABLE test_data FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n' (platform,package_id,cdate,event_id,uniq,num);
Query OK, 2619634 rows affected, 4 warnings (19.10 sec)
Records: 2619834 Deleted: 0 Skipped: 200 Warnings: 4
从这件事情的反应来看，开发同学是能够接受的，同时我们也能够把自己额标准适当降一降，在这种情况下，我们如果一味要求提供可执行的脚本，因为这种一种信息不对等的情况，效果会很不好，既然我们希望开发同学能够提交较为标准的SQL或者命令，我们给出一个模板或者实例，后续也可以作为一个切入点来推广。
第二个：看待事物的本质，找出更适合的方案
今天下午团队内部聊了下周期表的事情，本来从聊这个事情的时候，大家总体是感觉周期表是比较简单，但是如果展开来说，发现周期表的流程和体系是比较庞大的。
周期表是带有时间属性的表，这个时间属性是能够被程序逻辑识别的。我们可以把一张表由普通标转变为周期表，那么我们就需要做两类事情，一类事情是周期表的创建，一类事情是后期表的删除。
周期表的创建可以是批量操作，如果中间因为系统稳定性和可靠性的原因导致任务执行失败，对于整体的任务情况不会产生影响，创建的幅度是建议为3个月以内，这样我们可以相对容易衡量业务的发展情况。我们可以统一配置周期表服务，这样就可以把实现方式统一，通过统一的配置化管理来统筹管理这些周期表，通过周期表预警和自动化工单来满足周期表的变更需求，而对于护具删除需求则可以通过类似crontab的每日执行频率来喊出数据，比如一个数据库test1的表t1需要删除，我们可以把它挪到数据库test2下面，按照这种积累的情况，我们可以适当的删除数据，这个频率可以缩小到以天为单位，这样一来数据就是一种流动的状态，而且是可持续改进的状态，当然整个过程中如果对这些流程不啊清晰，可能会觉得现有的手工操作也能够支持现有需求，但是如果把它作为一种服务，其实通过集成流程就会把这些看起来模糊的问题细化，做到可以衡量的标准。
第二个：找到一种较为合理的学习方式
对于很多技术而言，我们都有自己的一些学习方法，比如博客，图书或者搜索引擎，但是我们其实很容易忽略一个重要资料，那就是官方文档，比如Python学习，我们如果不参考官方文档，通过一些博客文章等，得到的结果是相对碎片，在这里还是建议有更系统的学习，比如对于时间的处理，有哪些可供调用的方法，通过官方文档我们可以得到较为准确的信息，可以通过文档的相关性进行关联学习，这是一种相对体系化的学习方式。
比如可以推荐几个链接：
Python官方文档，2.7版本，可以下载文档。
https://docs.python.org/2.7/download.html
Lua在线文档
https://www.lua.org/ftp/#manuals
MySQL源码文档：
https://dev.mysql.com/doc/dev/mysql-server/latest/
MySQL内核文档:
https://dev.mysql.com/doc/internals/en/