标签：改变 epo 读取 标题 十分 好用 为我 方法 RoCE
目录
404 Note Found
| 学号 | 姓名 |
|---|---|
| 031602114 | 胡绪佩（组长） |
| 031602543 | 周政演 |
| 031602444 | 庄卉 |
| 081600410 | 胡青元 |
| 031602627 | 刘恺琳 |
| 031602525 | 刘一好 |
| 031602511 | 何家伟 |
| 031602513 | 黄鸿杰 |
| 031602510 | 葛家灿 |
| 031602539 | 翟丹丹 |
| 031602113 | 何宇恒 |
项目宣传视频链接：https://www.bilibili.com/video/av38829275
绪佩： 对备忘录的状态之间改变跳转进行修复改进、对删除备忘录的功能bug修复、现场展示PPT答辩、项目的推进、任务的分工
卉卉： 云服务器云端数据的部署，接口的测试和改进，产品的界面优化建议师，产品界面图标图片制作
家灿： 云服务器云备份，云同步部署，接口测试和改进
青元： 登录注册界面的完善，和云端数据库的对接，协作完成云同步和云备份，引导页的制作
鸿杰： 完成智能提醒天气分析和用户行为分析的功能合并，协作完成备忘录即将到期的通知显示，答辩环节提问回答算分汇总处理。
家伟： 改进和优化短信提醒的时间，内容，对后台运行程序的尝试
一好： 完成语音输入的浮标尝试，PPT制作
宇恒： 完成备忘录详情处添加图片路径处理，添加可以拍照的功能
政演： 针对两个智能进行深度优化,设计实现了基于 LD-Sketch 的云端数据处理框架,并制作ppt上台答辩，博客分工以及撰写
丹丹： 新颖视频的制作
恺琳： 优化生成壁纸的功能，美化壁纸展示的界面，修复生成壁纸的小bug
团队贡献比例：
姓名|贡献度
---|---
绪佩|11%
卉卉|9.5%
家灿|11%
青元|13%
鸿杰|11%
家伟|6.5%
一好|6%
宇恒|6%
政演|11%
丹丹|9%
恺琳|6%
# GitHub 项目链接
https://github.com/heihuifei/Canmory-of-404-Note-Found
燃尽图：
原计划将什么功能做到什么程度
实际做得怎样了
如果没有达成，反思是哪些因素影响的
原计划将什么功能做到什么程度
实际做得怎样了
如果没有达成，反思是哪些因素影响的
原计划将什么功能做到什么程度
实际做得怎样了
如果没有达成，反思是哪些因素影响的
原计划将什么功能做到什么程度
实际做得怎样了
如果没有达成，反思是哪些因素影响的
原计划将什么功能做到什么程度
实际做得怎样了
如果没有达成，反思是哪些因素影响的
原计划将什么功能做到什么程度
实际做得怎样了
如果没有达成，反思是哪些因素影响的
原计划将什么功能做到什么程度
实际做得怎样了
如果没有达成，反思是哪些因素影响的
原计划将什么功能做到什么程度
-将备忘录显示在页面上，并可以选择自己想要的壁纸。
实际做得怎样了
如果没有达成，反思是哪些因素影响的
原计划将什么功能做到什么程度
实际做得怎样了
如果没有达成，反思是哪些因素影响的
原计划将什么功能做到什么程度
实际做得怎样了
如果没有达成，反思是哪些因素影响的
原计划将什么功能做到什么程度
-原计划将备忘录编辑界面增加拍照和上传视频功能
实际做得怎样了
-实际上只做了拍照功能，并没有实现上传视频功能
如果没有达成，反思是哪些因素影响的
记忆罐头APK网盘地址：https://pan.baidu.com/s/1AsbRgRbkdrx6Qz_dnpv_Sw
我们的智能分析是一个基于 LD-Sketch 的云端数据处理框架，用于在云服务器后台上处理从用户传来的数据。将用户的数据项看做流的形式，传到云服务器的sketch上，而不是将数据项存储在数据库中。后端人员只需要设计好用户端的数据采集，存于字符串中，通过thrift将数据从用户端传输到云端，并控制多用户向云端的并发数据传递。并在后端将字符串解析成所需的数据，设置到LD-sketch的阈值大小，通过管道存入LD-sketch中,LD-sketch将自动报出超过阈值的数据项。
智能分析主要用于后台的数据处理，不向用户开放。
线速处理数据
能够高速处理从边缘到云端的数据，LD-sketch原是用于数据中心的高速流量测量，本产品用户端到云端的数据量远远小于数据中心，可以轻松完成线速数据处理。
占用极少空间
尽量减少空间的开销，不使智能分析成为负担。sketch的基本思想是将数据压缩到较小的空间内，在可接受的误差估计下完成数据采集，利用LD-sketch可以大大减少数据存储占用的空间。
通用处理框架
使边缘到云端的数据处理框架具备良好的通用性。我们设计的框架无需针对每一种数据都设计专门的处理方法。每一条数据都以字符串的形式传输，只要在后端设计好字符串的格式处理即可。
简化对接操作
省去数据库处理过程，简化处理流程。我们的数据处理框架中，绕过了数据库，避免数据在数据库中大量的 IO 操作，降低计算开销，同时不需要数据库管理员对数据处理，简化了对接操作。
1. 在早上的答辩中没有听懂基于LD-Sketch的用户行为统计算法可否详细解释一下？
答：感谢提问！我们的智能分析是一个基于 LD-Sketch 的云端数据处理框架，用于在云服务器后台上处理从用户传来的数据。将用户的数据项看做流的形式，传到云服务器的sketch上，而不是将数据项存储在数据库中。后端人员只需要设计好用户端的数据采集，存于字符串中，通过thrift将数据从用户端传输到云端，并控制多用户向云端的并发数据传递。并在后端将字符串解析成所需的数据，设置到LD-sketch的阈值大小，通过管道存入LD-sketch中,LD-sketch将自动报出超过阈值的数据项。
如有兴趣，欢迎讨论 ：）
附：
对于sketch的有关算法，可以查看这篇介绍：https://www.sdnlab.com/22685.html
关于LD-sketch的算法细节，可以查看这篇论文：https://ieeexplore.ieee.org/document/6848076/
2. 是否考虑精简界面的元素数量，给用户更简洁的观感？
答：感谢提问！我们在备忘展示的主界面的未完成、到期未完成、已完成三个列表均可点击使其隐藏。我们认为已经尽可能的精简了界面的元素数量，使其在满足用户需求的情况下尽量简洁。如果有什么好的建议欢迎与我们交流。
3. 应用的功能较多是否考虑做一个用户引导方便新用户了解功能？
答：感谢提问！我们的app在用户第一次安装时会提供一个引导页来介绍特色功能。
1. 对于本项目，在后续的bug修改以及推广方面有哪些想法
答：感谢提问!我们项目组负责开发部分的成员会继续修改bug，bug修改完善后，会投入市场运营，线上线下会同时宣传，争取吸引更多用户的使用。
2. 在以前的课上有提过你们不用语音输入的,现在怎么也支持语音输入了
答：感谢提问!因为我们有多余的时间和足够的能力，多多益善嘛，后续就添加了这个功能。
3. 有没有考虑本项目的某些地方其实产生了重叠从而对项目进行部分的增加或删除
答：感谢提问!目前还没有发现功能严重重叠的现象，但后续在推广过程中会根据用户反馈现象，对功能进行增删改。
1. 你们有没有做过关于界面美观或是逻辑设计的调查或测试？
答：感谢提问！在问卷中我们有这样的选项。
2. 语音输入的结果精度高吗？语音输入功能是调用什么实现的吗？
答：感谢提问！语音输入是调用百度的接口，精度在我们的能力范围确保语音输入的准确度。
3. 如果每一项提示需要填写这么多项的话,会不会太麻烦？让用户体验降低,是否考虑简化(目前个人用来觉得挺好,需要提醒事项多的时候没有测试过,所以不太清楚)
答：感谢提问！我们的备忘录并不是对每个选项都要设置，最简便的方法是语音输入，直接转成备忘录的标题。
1. 为什么没有展示智能分析？仅从口头描述来说，是否仅是上传各app的使用时长给服务器而已呢？
答：感谢提问！
2. 在之前的展示中，你们反复提到软工课没必要做太高大上的技术，为什么这次展示又加了两个“智能”模块呢？
答：感谢提问！这个问题分两点回答。
3. 你们认为最核心的功能是什么呢？为什么？
答：感谢提问！我们认为最核心的功能是锁屏壁纸展示；壁纸展示能够最直观的让用户看到自己定下的备忘录，改变传统的备忘录形式，做到真正的“备忘”。
1. 语音输入的功能很好,请问语音识别的准确率如何?
答：感谢提问！其实之前就有回答过类似的问题，我们使用的是百度语音接口，准确率和使用者的口音和使用环境也有关系，正常使用的时候准确率是很可靠的。
2. 请问有没有打算beta版本之后从哪些方面来进一步完善？
答：感谢提问！优化各个页面的逻辑，使得页面更加人性化。还有就是对用户的APP使用情况进行分析，以提供更好的服务。
3. 请问你们会用什么来吸引用户、留住用户？
答：感谢提问！我们会提供个性化的设置，优美的界面，各种方便实用的功能其实就已经很吸引人了。
1. 仍存在一些bug未解决，演示时，智能读取短信加入待办事项的功能似乎出了问题，找到原因了吗？
答：感谢提问！找到原因了，智能读取短信时数据库读写出了问题。我们已经进行了解决。
2. 待办事项，进行中事项与已完成事项的ui交互逻辑不够友好，事项的相互转移操作不是很明晰，可以再进行优化吗？
答：感谢提问！我们会在后续更新中进行优秀，感谢您的建议。
3. 智能分析功能可以做一些展示吗？
答：感谢提问！我们会再对这方面进行优化，按照计划会在最终演示的时候进行展示。
1. 你们组的人数相对其他组比较多，能否简述一下你们的分工和工作时间？
答：感谢提问！分工已经在ppt很明确的指出了，希望该组组员再看一下；工作时间为每周2、5、6晚上9点至11点，值得一提的是，在本周三前，本组已经大致完成了所有核心功能，并发布了app1.0.0版本，并做了许多改进，如今已经到了1.0.9版本！
2. 为什么会出现现场演示中的错误，之后有无寻找原因并进行修改？
答:感谢提问！会在现场演示中出现错误，一方面是因为前期确实是没有准备好，另一方面是因为没有真正彩排过，没有到实地演练一遍！
3. 你们项目的功能已经十分完善了,能否简述一下后续的制作计划呢？
答：感谢回答！我们项目功能虽然比较完善了，但是还有一些细节处理的不够友好，还有待改进，另外会针对于我们的智能性方面做出更进一步的优化。再者我们将会对我们的产品做一个市场推广并根据用户反馈迭代产品，推广迭代过程还很漫长。后续计划将由pm制定！
| PSP2.1 | header 2 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 50 | 30 |
| · Estimate | ·估计这个任务需要多少时间 | 20 | 30 |
| Development | 开发 | 150 | 120 |
| · Analysis | 需求分析（包括学习新技术） | 60 | 60 |
| · Design Spec | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 80 | 50 |
| · Coding | · 具体编码 | 10 | 20 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | ·测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 10 | 10 |
| · Test Repor | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 0 | 0 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 20 |
| 合计 | 660 | 790 |
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 5 | 5 | 阅读《构建之法》，重点了解了 NABCD 模型 |
| 2 | 0 | 0 | 10 | 15 | 找到了适合团队的原型工具，以及如何并行操作 |
| 3 | 68 | 68 | 6 | 6 | python字符处理复习、爬虫学习 |
| 4 | 78 | 146 | 7 | 13 | java爬虫学习 |
| 5 | 194 | 340 | 6 | 19 | 单元测试设计 |
| 6 | 0 | 340 | 10 | 29 | 需求报告撰写 |
| 7 | 0 | 340 | 5 | 34 | Alpha博客撰写 |
| 7 | 0 | 340 | 3 | 37 | Alpha2博客审查 |
| 7 | 0 | 340 | 3 | 40 | Alpha3博客审查 |
| 7 | 0 | 340 | 2 | 42 | Alpha4博客撰写 |
| 7 | 50 | 390 | 10 | 52 | 构思了随机算法、附加功能算法和具体思路，完成撰写叙述 |
| 7 | 0 | 340 | 2 | 54 | Alpha5博客撰写 |
| 8 | 0 | 340 | 2 | 56 | Alpha6博客撰写 |
| 8 | 0 | 340 | 2 | 58 | Alpha7博客撰写 |
| 8 | 0 | 340 | 2 | 60 | Alpha8博客撰写 |
| 8 | 0 | 340 | 2 | 62 | Alpha9博客撰写 |
| 8 | 0 | 340 | 2 | 64 | Alpha10博客撰写 |
| 9 | 0 | 700 | 4 | 68 | 测试文档撰写 |
| 9 | 0 | 700 | 2 | 70 | Beta1博客撰写 |
| 10 | 300 | 1000 | 2 | 72 | Beta2博客撰写 |
| 10 | 200 | 1200 | 2 | 74 | Beta3博客撰写 |
| 10 | 300 | 1500 | 2 | 76 | Beta4博客撰写 |
| 11 | 300 | 1500 | 2 | 78 | Beta5博客撰写 |
| 12 | 0 | 1500 | 2 | 80 | Beta6博客撰写 |
| 13 | 200 | 1700 | 5 | 85 | 设计实现new idea |
| 14 | 0 | 1700 | 2 | 87 | Beta7博客撰写 |
| 14 | 0 | 1700 | 2 | 89 | Beta总结博客撰写 |
| 14 | 400 | 2100 | 6 | 95 | 完成智能分析 |
组长博客链接：https://www.cnblogs.com/heihuifei/p/10165906.html
标签：改变 epo 读取 标题 十分 好用 为我 方法 RoCE
原文地址：https://www.cnblogs.com/vancasola/p/10165926.html
