2018年12月2日

• 13:40开始PPT，预计14:40写完第一部分， 15:20写完最终初稿
  思路：分阶段
  第一阶段，概览，然后是细分的结果
  细分结果：
  业务架构图，
  初步使用
  第二阶段，概览，细分结果，包括KM学习成果，详细的截图
  Java标准库的系统学习
  建立了一个未来3个月的学习计划
  KM学习成果
  vivo中间件提出的改进
  工作习惯
  书籍阅读
  为了性能验证而写的数据生成器

  写代码过程中累计的库：统计文件，函数

2018年12月1日

• 中午12:30 调试dubbo， 调试完成或者到15:00

• 开始调试ads-security, 15:00（最晚）- 17:00

• 17:00 开始PPT

• 19:00 回

• 治大国如烹小鲜-果真如此也，一步亦不能差，现在，这告诉了我们，健壮性有多么重要

• 一件趣事：凌晨时段的调试，看日志是最容易犯错误的，因为0点一过，选择的日期就会变成前一天的，导致再也收不到日志更新了，这是个愚蠢的设计。

• 加班感想：可测试性，数据样本集足够大（足够挑出各种bug），敏捷性 -- 想办法把它变成清单

  
  
  image.png

• 由于线上部署出现class加载的问题，将所有的工程合并在一起

本周：2018年11月26日 - 2018年11月30日

• 学习spring security，shiro权限管理框架

2018年11月30日

• security记录主要的工作

2018年11月30日

• DMP url跳转问题
• 申请节点
• dubbo修复， vivo 框架
• 会议纪要
• 晚上19:00 PPT
• 标签tag问题
• 落地页freeze sql查询问题
• 落地页篡改相关事项，继续跟进，数据库建立
• dmp接口子page是否应当从0开始
• 确认广告主标签是否存在递归结构 无
• ads-dsp-internla-serivc添加tx manager支持
• 增加测试对接文档
• 验证redirectUploadTag是否会被用到 -- 大概率用不到 -- 不会用到
• 下午14:10 开始布测试环境
• 测试syncAdvertiserTag
• ads-admin shiro dev环境更改成服务器地址

11月29日

• 完成测试剩余需求 （编写+测试 1个小时） -- 更正，一般是3个小时
• 再熟悉广告架构 （）
• tcp协议 （中午：10分钟）
• 完成ppt （晚上21:00-22:30）
• km资料库 （下午）
• 效果数据库架构设计完善 （30分钟）
• 时间预测，从mapper编写到其他预估 精确到半小时

2018年11月28日

• 数据库清洗：1.广告被冻结，但广告主未被冻结， 则相同网址的其他广告应当被冻结--> 这类广告应当输出一个报告列表,virtual_position_id应当为1
• 不同类网页鉴定 -- 基于关键词的过滤
• ~~测试代理 ~~ -- 南京无可用代理
• 测试不同agent --
• 重构security，使用新的checker
• 完成所有效果2.8.0的开发任务
  时间段：0-6 6-20 22-24 基于时间的已完成
  ip：
  中午之前

2018年11月27日

• 建立不同时段访问的保存的结果(能力已具备，待移植到Security）
• 移植security,最大限度丢弃依赖 经证明是不可能的
  -在security中应用新的方法，使用等价替换 --经证明是不可能的
• security新增按按网址查询id列表的功能
• ads dsp task使用新的任务调用

网页的内容保存主要是下面的形式：
html .html, 1.1,2.2
按后缀，使用的代理，使用的proxy，时段分类存储

2018年11月26日

• 加agent

2018年11月25日

• 首先确定一个初步的方案：批量使用nodejs分析文件，如果性能证明有问题，换用Java端粗糙的方式（其实Java端做起来不难，就是需要自己去手动搭建一个库）
• 整理出样本库，哪些应当被下掉，哪些不应当被下掉，在KM上总结资料库。包括EVAL包含恶意代码的。

2018年11月24日

-~~ 移植ads-security到新的工程中，组件拆分，ctr备份到放到task层~~

• 申请git地址
• 配置中心配置更改的测试
• security 篡改修正 ，以及整个security工程的测试 --> 已测试，预计下周一下午14:30发RELEASE版本
• 内容库建设，实现文件系统和Database两种，使用统一的接口（FS已完成，DB的后面再上）
  -~~ 认证接口和时效性功能~~
• 文件接口，class重定义在线升级（无损升级）
• 配置中心的值缓存策略，应当使用异步通知，否则程序使用就很困难。所有的变动都应当异步进行消息通知，这是标准模式。 --> 使用1.3正常接收通知，因此，使用新版的配置中心接口就OK了
• HTML网页内容爬取接口就是一个简单的get
• 财报

2018年11月14日

落地页更加详细的通知信息

2018年11月12日

修复proxy(虽然是小问题，也花了一个上午的时间）

2018年11月11日

TimeRecorder--用于线程计时， 内部可声明多个时间点，report时可选择不同的格式--明天做
使用dup优化代理，探索StackMap（还是没怎么明白该怎么设置StackMap，但是理解更深一层）
更加简便的aop代理设计（避免多次getstatic，但是感觉JIT会优化这些东西的，以后可以不考虑在字节码级别优化，让编译器自己去优化）
下午：去郊外爬山
去药店买验血的试剂回来验

2018年11月10日

现在：2018年11月10日11:06:15，两个小时后，检查是否全部以url方式发送
总结项目中哪些部分在使用数据库，每个部分的使用
总结项目中使用redis的形式
javaagent和探针技术
jmock,easymock,mockito等mock框架

2018年11月9日

RabbitMQ的使用
探索怎么类方法级别的动态代理
字节码技术：cglib(底层使用asm)

Kafka的使用
学习Nginx的使用

2018年11月8日

Hystrix的各种Group或key的设计
Hystrix的使用配置，能够完成哪些应用场景，并写代码测试
昨晚确定的事情：1.封装LoopUtils 2.将最小化依赖提出，使用新版 3.封装TimeLimiter 4.开发点检表增加
学习RateLimiter的使用
学习Ehcache的使用

2018年11月7日

Hystrix部分源码和设计，从简单配置到工业级使用，包括一部分代码。（一个上午的时间）
提出部分上线点检表的内容
沟通：怎么清晰地、扼要地表达自己的意愿
沟通：怎么准确无误地获知对方的意愿
从底层，包括数据库的设计部分，重新梳理整个广告的建模模型。一切都是基于数据库的。分清楚哪些是基本表，哪些是关联表，哪些是衍生表。
确定一个规则：大多数事情应当首先被添加到清单上，然后才去执行。
Hystrix的ThreadPool的设计

2018年11月6日

会议和会议纪要
逆向推理出需要学习的知识
阅读《SOA架构》30%
共同协作上线清单的问题：至少，在我的程序中，需要改一下运行时间才能上线。这种协作的形式是：每个人都往清单里加入一部分内容，然后汇总起来。
了解服务熔断、降级、限流，进行代码的配置和测试(仅完成10%，尝试了解了Hystrix的简单使用）
了解常用的灰度策略
由技术团队维护的一份开发准则列表

知识矩阵

20%这个数字来自于 80-20 原则，系统中20%的代码决定着80%的功能。相应的，其余80%的代码则决定着其余20%的功能，这些功能你可能很少用到。如果你觉得自己需要深入一点，你可以使用 20% + 80% * 20% = 36% ~= 40% ，也就是说，再多深入了解一点其余80%中的20%。
这就要求你只关注那些非常重要的部分而不是所有部分。

项目分析

我们的目标是达成上面知识矩阵所设定的目标，因此，最好的方法是通过一个能够使用到这些技术的项目。
对于项目而言，我们首先要有基础的用户集合，即使应用构建起来，我们也还需要大量的外部访问来验证。
但是，我们无法模拟超大并发量的用户访问。因此，我们可以降低服务的质量，即人为的干预资源来造成大量访问的结果。我们的首要考量是TCP连接的数量，如果我们可以限制一段时间内TCP连接的数量，则就可以模拟任意规模的并发访问。
其次，是项目的需求分析。我们的项目不仅面向（虚拟的）目标用户，也需要满足我们开发人员验证某些设计理念和程序。

假定用户能够忍受的最长服务响应时间是t，则实际上，我们可以计算出最大支持的每秒并发量。假定服务完成的实际时间是s。 如果服务器是单线程的，则并发量是s/t。但是服务器可以多个线程，并且也可以采用分布式完成，这是Nginx需要完成的功能：反向代理。
单台服务器的并发量tps受CPU性能影响较大，每增加一个线程都会造成服务时间的一定下降，尤其是在面临锁的时候。因此，我们需要解决多线程、分布式服务的数据共享的问题。
请求被处理，由Tomcat完成；具体的处理逻辑是基于Spring容器的，因此，Spring容器是整个应用的核心组件；在应用中，我们应当产生适当的log来表明发生的事情，以便追踪某些bug或者查询某些事件；分布式服务通过rpc进行调用，dubbo可以满足这样的需求；而假如服务之间需要进行异步调用，这就是Kafka和RabbitMQ要完成的功能，当然，Kafka由于其吞吐量而著名，因此kafka还有可能用于传输大量的数据，在我们的项目中，我们暂时使用这两个消息组件用作异步通知的。处理通常是面向数据的，因此我们需要数据库作为系统的底层数据支撑，MySQL使我们的选择；但是数据库的访问速度不够快，因此，我们需要使用redis进行缓存访问；如果redis在远程服务器上，我们通常还会缓存少量的数据到本机上，这是Ehcache完成的。
最后，在整个流程中，我们需要进行不断迭代的测试，最后，还要来一个整体的性能测试。我们最终将会得到一个完整的web项目。

我们在设计中会遵循某些基本的策略，遵照流程来模拟每个阶段。

并且，我们可以设定整个设计过程的成员，要记住，这是一个团队在协作，不同的人都处在其中。我们不仅仅学习技术，也学习协作和管理。

我们在每个阶段，会使用清单来确定必须点检的项目。

首先，我们化身为用户，提出我们最原始的需求；
然后，我们化身为产品经理，对这些需求进一步细化，并且提出相应的可能；
然后，我们组建项目团队，包括项目经理，运维，基础架构支持，测试，开发人员。我们一人身兼数职，并在出任这一角色时完全负责自己的责任，这样，我们必须不断地进行个人的自我对抗。

《SOA架构》

SOA的4个特性：1.业务驱动（技术架构） 2.供应商中立 3.企业中心化 4.组合中心化

完整的web项目

账户系统

2018年11月5日（晚上）

2018年11月5日

git的使用和笔记
github的使用方法
《清单革命》--中午 50%, 晚上30分钟 70%， 下班后1个小时100%
应用清单和测试驱动开发
Spring集成测试：简单部分
《Spring的技术内幕》，晚上回去阅读
上传自己单独的jar包到common中，并且表明它是与其他工程无关的，这样一来，就能保持在github和central中包含util包。但是注意，不要包含公司的代码。

本地utils

首先在本地建立一个仓库，通过nexus本地构建即可。
它无需任何线上的仓库支持，因为只需要配置pom的上传地址即可。

《清单革命》

清单能够提高工作效率
清单能够提高团队协作的效率
清单不宜过长，且简单易行