‍‍今天完成的事情：

1.完成sendcloud的测试demo

（1）就是找到报错的地方后，把这个信息填进去。

这儿是生产API_KEY.很明显的生成标记，所以就点了。

完后想了想，可能是第一次注册时生成的没注意到，而它不会发送到邮箱，所以生成后我们没保存，在这次要用的时候就找不到，需要手动生成一下，然后保存起来，等下次用的时候输入保存的就OK。若是我忘记保存，应该下次哦你给的时候还需要再次生成一次。

（2）demo代码

输出了四条语句，result,statuscode,message,info

结果，状态码，信息，发送的信息。很清晰的传递过程。

（3）收到信息

给163发送，然后给一个qq邮箱抄送，给一个qq邮箱密送。所以这里有三个收件人，这里点开，可以看到那两个QQ邮箱地址。并且去看了那两个邮箱里的收件箱，不过qq邮箱的是在垃圾箱里面（这个需要注意一下）。

然后再回过头看一遍传递的参数。就会更加清楚。

2.重温log4j，收获颇多

用的缺省的log4j环境输出日志。了解来源，才会运用起来更加熟练。

不过前面的0，1，1代表什么不是很清楚。后经过测试好像是时间。输出第一条和第二条之间差1ms（不是很精确的说法），就这个意思。但是还是不太确定。

明天计划的事情：

看看阿里云和金山云的API，搞一搞图片

遇到的问题：

和昨天犯的错差不多，就是某些参数找不到。

其实就是昨天看的那个api_user，还要自动生成一个api_key。结果昨天只注意了发信域名，旁边的愣是找不到。

主要原因还是考虑问题的思想不到位，昨天是不知道怎么去排查错误的根本原因，上下文追寻对象方法的调用就可以找到出错的地方；今天是找到哪里出错了，但到寻找办法的时候怎么也找不到。

就好比说今天报的API_USER为空，也找的它的配置文件是null，但是不知道如果填的话填什么，正确的在哪里。然后在邮件文档里看解释就是api_user就是API_USER。联想到昨天的APPID是注册完以后在管理中心可以看到的，但是这个注册完好像没有看到信息。其实它就在那里，所以思考问题的能力还是和敲代码一样要多联系。

收获：

1.在应用程序中添加日志记录总的来说基于三个目的：

（1）监视代码中变量的变化情况，周期性的记录到文件中供其他应用进行统计分析工作

（2）跟踪代码运行时轨迹，作为日后审计的依据

（3）担当集成开发环境中的调试器的作用，向文件或控制台打印代码的调试信息。

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍最普通的做法就是在代码中嵌入许多的打印语句，这些打印语句可以输出到控制台或文件中，比较好的做法就是构造一个日志操作类来封装此类操作，而不是让一系列的打印语句充斥了代码的主体。‍‍‍‍‍‍‍‍

‍‍‍‍‍‍‍‍2.Log4j是Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件、甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。‍‍‍‍‍‍‍‍‍‍

‍‍‍‍‍‍‍‍