2016.07.25
今日的任务
1 编写投放端性能监控配置管理的页面的后台api接口(大概完成了30%的编写,预计天可以完成后台cgi的编写与自测)
2 继续完善http2 的分享文档, 搭建http2性能演示网站
总结
今天终于从sublime编辑器转换到phpstorm IDE上面去编码了, 果然对于我这种编码经验不是很丰富的人来说, 一开始尝试使用一个合适编辑器会很大的调提高编码效率
用欲善其事,必先利其器 这话还是有道理的
2016.08.01
今日任务:
1 继续确定和对接实验系统的前端优化的方案
2 推进 投放端性能监控上报系统的测试与上线
3 感谢eshion和walker帮忙解决了数据库中文乱码的问题
4 熟悉实验系统的前端 代码框架, 分析需求需要改动的地方
5 配置好实验系统的开发环境
6 构思新的分页方案
遇到的问题:
解决php后台的中文乱码的问题,这个问题其实以前做开发的时候也遇到过,不过由于建表sql语句的疏忽, 没有设置utf8的编码格式导致出现问题.这种问题以后不能再出现了
关于实验系统前端页面优化的分页问题:
背景:
由于实验系统的查询数据量是随着用户勾选的维度而变化的,所以可能会一下子返回量很大的数据, 但是前端页面插入dom元素肯定是有限制的, 不可能无限制的插入量很大的数据, 所以分页的问题是需要我们去解决的
初期的方案:
第一次查询（前端点击『查询』按钮的时候）前端会请求两次cgi 一次请求全量 一次请求分页。 以后在翻页的时候，只请求分页,这是传统的分页方案
遇到的问题:
实验系统的数据格式比较特殊, 需要每一天的数据不能被 分割, 所以我们在初期的方案加入改进: 具体的内容就是给用户一个 每页显示数量 的下拉选择框,当用户的数据被分割之后,用户可以勾选更大的每页显示条数 来把一整天的数据显示完整
还有问题:
当用户更改了每页的显示条数的时候,一般的前端方案都是重新从第一页开始重新显示,但是我们这里的目的是 让用户可以查看一天完整的数据, 显然是不能从第一页重新开始显示的,一方面体验太差, 另外一方面你不能保证那一天的数据是否被分割了
又是一个方案:
前端上传的分页参数为 index ,length两个参数, index 是查询结果的起始位置, length是 偏移量, 这样就不用从第一页开始重新显示了, 直接从用户浏览的那一页开始显示, 同时 由于选择了更大的 每页显示条数, 正常情况下可以把那一整天的数据显示完整
问题:
看起来上面的方案是解决了 一天的数据被 分割的问题, 但是随后带来的是 此页面前面的数据分页被打乱的情况, 比如说 你当前的页面显示500~600的数据, 然后你改为每页显示150条, 即显示500~650的数据, ,那么,前面的500条数据就不好分页了,因为不是150的整数倍了
暂时的处理:
为了解决上面的问题, 我先打算先做表头冻结的功能, 因为前期数据量不是特别大的情况下, 使用表头冻结是可以满足用户正常查看table的,分页的方案可以在后面的实验推进,不过需要更多的实验保证效率.
这是我晚上构思的一种 分页方案:
1 为了保证一天的数据不会被分割, 我们需要一个 table容器, 这个容器有一个最大的容量 ,比如最大的可以显示1000条数据
2 从后台请求全量的数据, 前端去遍历 全量的数据, 比如每天的数据有300条, 不断的往第一个容器里面填充数据, 当填充到第四天的数据之后, 我们发现第四天数据被分割了,只能在第一个容器中插入100条数据,, 那么我们撤回第四天的数据 第一个容器就让它显示900条共三天的数据
3 第四天的数据开始填充第 2 个table容器, 以此类推,在遍历的过程中我们也可以做一些表格数据的本地计算,比如计算每条数据的ctr Δctr Δctr±α等等 (原本的数据就要计算这些,遍历数据是少不了的, 所以我们刚刚好可以利用这个遍历的过程,做好数据的分页)
4 把全量数据全部遍历之后, 我们的本地分页也就做完了,然后就可以初始化分页的组件了, 由于数据全部缓存在内存中, 我们的分页不需要请求后台, 可以做到极快的响应
2016.08.10
HI All
今日开发任务
1 根据eshion的cr评论,修改性能监控上报系统的的php代码规范
2 修复 实验系统的table 数字过长溢出单元格
3 切换 实验系统的新老 cgi接口
4 修复 实验系统 任何维度不选则查询失败的情况
5 新增 实验系统读取 url , 自动勾选 查询维度的功能, 避免每次都要重新选择维度
6 新增 打开性能监控上报展示首页, 自动选择第一个配置 的数据 进行展示
今天时间有限, 早上和leonnliu 聊了在实习期间的一些收获和感触, 发觉在后面的时间里,不仅仅要做好需求, 同时也要去更多的了解 业务本身, 了解广告的一些概念, 帮助以后去更好的去沟通和理解需求
在 下午的周会上面, kirk分享了rudex源码分享:
以前听说过一直没有机会接触,今天可以趁着这个机会去了解以下的几个概念:
Actions、Reducers 和 Store:
action 可以理解为应用向 store 传递的数据信息（一般为用户交互信息）。在实际应用中，传递的信息可以约定一个固定的数据格式，
为了便于测试和易于扩展，Redux 引入了 Action Creator:
function addTodo(text) {
return {
type: ADD_TODO,
text,
}
}
store.dispatch(addTodo(text)):
dispatch(action) 是一个同步的过程：执行 reducer 更新 state -> 调用 store 的监听处理函数。如果需要在 dispatch 时执行一些异步操作（fetch action data），可以通过引入 Middleware 解决。
reducer :
reducer 实际上就是一个函数：(previousState, action) => newState。用来执行根据指定 action 来更新 state 的逻辑。通过 combineReducers(reducers) 可以把多个 reducer 合并成一个 root reducer。
reducer 不存储 state, reducer 函数逻辑中不应该直接改变 state 对象, 而是返回新的 state 对象（可以考虑使用 immutable-js）。
store 是一个单一对象：
管理应用的 state
通过 store.getState() 可以获取 state
通过 store.dispatch(action) 来触发 state 更新
通过 store.subscribe(listener) 来注册 state 变化监听器
通过 createStore(reducer, [initialState]) 创建
在 Redux 应用中，只允许有一个 store 对象，可以通过 combineReducers(reducers) 来实现对 state 管理的逻辑划分（多个 reducer）。
关于 redux ,现在的理解还是概念性的, 具体的还是需要自己去写demo,多实践
实习日报
2016.08.12
今日主要任务
1 排查昨天晚上遇到的数据库读取错误的, 最后发现不是代码的问题,而是DI那边出现连接错误, 在排查问题的过程中,我也顺着 代码的路径一步步的找到tcp的连接源代码, 也清楚的理解了一个数据库的查询时经过哪些的流程的, 为以后排查错误累计经验
2 根据cr评论 修改监控上报系统的 代码, 同时,修改后台的接口, 增加 从数据库拉取配置的开关, 这样前端或者上报cgi 可以自由选择 从何处拉取配置, 提高稳定性
3 熟悉wp和官网的需求
4 发布测试的邮件,邀请组内的成员来体验测试 报表系统
总结 :
发生昨晚的数据库连接错误的时候, 我一直怀疑是自己的代码问题, 后来花了好几个小时去排查问题, 最终发现是DI的问题, 在DI抛出 错误码时,php后台应该吧数据透传到前台来,,前台需要做响应的错误处理, 这是用户体验很重要的一个环节, 包括在开发的软件中, 需要模拟各种出错的问题或者是低网速的条件, 然后测试程序的稳定性和体验