本周工作任务:
1 投放端-lbs定向: 调整用户自定义地点的半径为 0.2km-25km
2 投放端-lbs定向: 调整用户 lbs 地址的个数限制 至 400
3 投放段-lbs定向: 用户批量导入地址功能
4 上报系统修复下载报表的 bug(Hermes 的查询2000行以上就容易无结果返回)
工作进展:
目前只完成了 atals_v2版本的开发,
前面的两个调整半径和打点数量限制功能比较简单,只需要修改 代码中的参数, 而批量上传地址主要分两块的功能:
1 用户上传地址文件, 后端批量解析,并返回成功与失败的地址数据
2 获取到解析的结果之后渲染结果到界面, 调用批量上传的接口
开发的总结:
1 IE 浏览器 input 标签需要 用户手动去触发 , 原本代码是一个 a 标签的点击,然后触发 input 标签的点击事件, input 标签绑定 onchange 事件 调用上传的方法, 这种方式在 在 ie 里面会出现 script 拒绝访问的错误, 这是 ie 浏览器的安全限制问题,后来感谢 Walker 指出这个问题, 并给出解决的方案, 就是使用 label 标签的 for 属性,将 label 的点击事件转移到 input 上面呢
2 发现一个旧版系统遗留的 bug , 自己就自己改了, 后来找 lioneli 对了一下, 发现自己修改的还是不够完美的(遇到问题或者 bug 需要找相关的同事确认一下, 不要自己不闷声的就去改代码)
3 遇到一个用户体验的小问题,在用户批量上传的时候, 如果点数超过最大的限制, 我是直接不在地图上显示这些点, 还是把这些点打上去, 然后设置这些点的状态为未选中
结论: 和同事讨论一下, 不要让用户做太多没有必要的选择,决定不把多出来的点打上去, 直接显示用户上传成功了多少个即可,而且, 上面的情况目前是不会出现的, 因为在调用批量上传的时候, 后端就就会确认有没有超过限制 , 返回给前端的的状态有两种, 一种是 全部上传成功的地址json 地址包, 另外一种:超过最大的限制直接返回对应的原因, 前端只需要把信息展示出来即可
4 在刚刚开始开发的过程中, 找到需求对应的模块,就开始开发了, 依旧感谢 walker 作为导师尽职尽责,一次次的来考我投放流程的代码加载逻辑, 最后还耐心的亲自演示,这样子做很有道理, 首先,对应我来说,开发一个需求不仅仅是把功能做好,更重要的是借助做这个需求的过程去熟悉 代码的架构,
而在下次的开发中就不需要分配那么多的时间去熟悉系统了, 同时, 对系统没有一个大局观是很危险的, 可能 代码在这个模块中有但是被其他组件引用之后就出 bug 了,
5 上报系统本周在测试环境测试修改过的上报 cgi, 由于使用了 php 的文件缓存, 从 缓存中读取配置比原先的 xml 配置还要快,本周应该会上预发布和线上环境
6 上报系统中对 Hermes 的依赖 : Hermes 对对用一次查询有10000行数据的限制, 而这个量对上报系统来说是远远不够的 为了解决这个问题,目前主要考虑 在后端细分查询的条件, 减少单次查询的量, 牺牲一定的运行速度, 但是要保证数据能显示出来,当然这是目前的方案, 长远的机会还需要和 eshion 从长计议
outshine 09:29:57
Hi,all:
在和导师walker商量之后, 以后每周一份周报, 来做工作汇总和技术沉淀总结
本周主要工作任务:
1 投放端-lbs定向: 调整用户自定义地点的半径为 0.2km-25km
2 投放端-lbs定向: 调整用户 lbs 地址的个数限制 至 400
3 投放段-lbs定向: 用户批量导入地址功能
4 上报系统修复下载报表的 bug (Hermes 的查询2000行以上就容易无结果返回)
5 修复了上报系统的遗留bug
工作进展:
前面的两个调整半径和打点数量限制功能比较简单,只需要修改 代码中的参数, 而批量上传地址主要分两块的功能:
1 用户上传地址文件, 后端批量解析,并返回成功与失败的地址数据
2 获取到解析的结果之后渲染结果到界面, 调用批量上传的接口(需要处理各种返回边界的情况)
目前只完成了 atals_v2版本的开发
开发的总结:
1 IE 浏览器 input 标签需要 用户手动去触发 , 原本代码是一个 a 标签的点击,然后触发 input 标签的点击事件, input 标签绑定 onchange 事件 调用上传的方法, 这种方式在 在 ie 里面会出现 script 拒绝访问的错误, 这是 ie 浏览器的安全限制问题,后来感谢 Walker 指出这个问题, 并给出解决的方案, 就是使用 label 标签的 for 属性,将 label 的点击事件转移到 input 上面呢
2 发现一个旧版系统遗留的 bug , 自己就自己改了, 后来找 lioneli 对了一下, 发现自己修改的还是不够完美的(遇到问题或者 bug 需要找相关的同事确认一下, 不要自己不闷声的就去改代码)
3 遇到一个用户体验的小问题,在用户批量上传的时候, 如果点数超过最大的限制, 是直接不在地图上显示这些点, 还是把这些点打上去, 然后设置这些点的状态为未选中?
结论 : 和同事讨论一下, 不要让用户做太多没有必要的选择,决定不把多出来的点打上去, 直接显示用户上传成功了多少个即可,而且,. 而且上面的情况目前是不会出现的, 因为在调用批量上传的时候, 后端就就会确认有没有超过限制 , 返回给前端的的状态有两种, 一种是 全部上传成功的地址json 地址包, 另一种情况 , :超过最大的限制, 直接返回失败及其 对应的原因, 前端只需要把信息展示出来即可
4 在刚刚开始开发的过程中, 找到需求对应的模块,就开始开发了, 依旧感谢 walker 作为导师尽职尽责,一次次的来考我投放流程的代码加载逻辑, 最后还耐心的亲自演示,这样子做很有道理, 首先,对应我来说,开发一个需求不仅仅是把功能做好,
更重要的是借助做这个需求的过程去熟悉 代码的架构和 开发的流程.
而在下次的开发中就不需要分配那么多的时间去熟悉系统了, 同时, 对系统没有一个大局观是很危险的, 可能 代码在这个模块中有用, 但是被其他组件引用之后就出 bug 了,
5 上报系统在测试环境测试上报 cgi, 由于使用了 php 的文件缓存, 从 缓存中读取配置比原先的 xml 配置还要快,下周会上预发布和线上环境
6 上报系统中对 Hermes 的依赖 : Hermes 一次查询有10000行数据的限制, 而这个量对上报系统来说是远远不够的 为了解决这个问题,目前主要考虑 在后端细分查询的条件, 减少单次查询的量, 牺牲一定的运行速度, 但是要保证数据能显示出来,当然这是暂时的方案, 长远的机会还需要 从长计议