2016.6.12

本周完成任务

与业务方及设计方确定现有用户模块的迭代功能 后台开发日常 - 未归类任务
6.6开会总结的工作任务 后台开发日常 - 7.1月开发
部署6.8测试版服务器 后台开发日常 - 部署、运营
6.12号碰头会议 后台开发日常 - 7.1月开发
6.15测试版部署 后台开发日常 - 部署、运营
本周新增任务

JAX-RS研究 5条评论 后台开发日常 - 技术演进
本周周报

本周工作成果总结，说说你对自己点赞或失望的地方。
研究了JAX-RS以及其参考实现jersey框架；完成了目前所用的spring-boot框架与jersey的整合，整合后，两个框架都会有一些特性难以实现。
推进6.17线上正式版的完成，梳理目前版本迭代到发布部署过程中尚未解决的一些问题，其中的重点之一在于项目发布的版本管理以及线上部署环境的版本管理，这两部分应该分开讨论并且分开管理。
整理了目前项目与12要素应用规范实现上的差异，或者说是不足。12要素应用规范是项目代码的规范，使得项目可以不依赖于执行环境进行高拓展性地迭代，所以需要对项目部署的版本进行专门管理，目前尚未实现。项目发布版本管理可以考虑用maven。
有遇到挑战或者困难么？希望团队怎么帮助你？
目前项目虽然在实现业务功能上的弹性技术准备上大体完成，但是面临着两方面的问题：
现有框架在web api层面上的不足：spring web 依托于 spring mvc，难以在内部真正实现rest所提倡的 uri指向唯一的资源。并且难以实现我们所希望的将uri组织成层级结构方便管理的形式。
硬性技术准备上（不依赖于业务功能的技术储备）仍有很大的欠缺，方方面面的问题都很多，需要花费时间精力研究预演解决方案，这也正是目前后台组没有集中精力奔赴双重系统的重要原因，但是留给我们的问题很多，时间所剩不多。
依靠个人独力解决这些问题，总会力有不逮，而且解决方式会陷入偏执，有失偏颇。所以我能做的会将精力集中在梳理项目要预演的一些技术问题，希望后台组能发挥能动性，一起探寻解决方案。
另： 对于此类问题的解决，不要寄期望于公司层面上集中安排时间，如今公司主要压力在于如何打通业务市场，这些问题是独属于后台而对于公司来说是隐形的；而且只有在预见问题的同时尝试解决问题才能最大可能地真正解决问题，而不应等到问题真正成为问题（那时后果已经造成了），或者等到问题已经变质（等问题过了那段新鲜热乎的时间，即使是简单微小的问题，也会滋长难以预料的菌落）再去刮骨疗毒。
下周的工作目标是什么？只许说一个。
促进完成7.1号放箱系统业务功能的同时，推进提升项目的硬性技术储备。
你觉得采取哪些措施，会对你提升工作效率有帮助？
将筷子用到纯熟，就可以省却刀叉。
对于当前建邺2.0项目有什么不清楚的地方（业务、功能、实现、部署...）
线上环境的运行状态。
一坨飞翔， 6月20日