1.起因
自己有两个小孩在一个学校上学，每到拓展选课的时候都比较苦恼。一是学校提供的选课系统总是宕机。据说收到黑客袭击，我怎么也不信有黑客摸准了一个不知名小学的选课时间袭击它的选课服务器；二是总是要门门课切换过来才知道已经选了几个人还有没有空可以选。最要命的是往往又很多课，划上滑下，不容易看清楚，切一个等半天，然后告诉你选满了，内心是在有些崩溃；三是多个孩子在一个学校，时间优先制选课，需要至少俩手机来选课。国家开放二孩政策了学校不知道么？我希望多个家长给一个孩子抢课。
基于此，源于几个已经是家长的粑粑商议一下，为了不让同为家长的兄弟们再受这样的煎熬，我们辛苦下，写个选课的平台吧。于是有了有料子荷项目。
2.技术
还是比较简单的框架，springboot redis mysql嗯几乎没有了，前端还用了一些些bootstrap jquery vue这些常用的。
3.功能设计
整合微信平台。选课没有用app或者小程序这类技术，不是咱不行，而是这些技术很容易失去用户流量，对于天天玩手机的家长来说，为了每年两次的选课安装一个app，用完即删除，小程序看起来不错，但是再用的时候需要再找一次，消息推送不能在服务号内。子荷用公众号或服务号方式整合，让家长使用的时候更有归属感，消息的推送更具官方的意味；
轻量设计。作为一个没有野心的平台，我们想把它设计的没那么入侵性，也就是不要对管理的老师添加太多的麻烦，他只要简单的导导数据，就可以开选了。我们要做的是小而美，不是大而全。要关注的是用户量使用最频繁的功能。但是做到最简单。我们叫它一个平台，其实你也可以当它是一个工具。
高性能选课组件。选课一定会面对高并发，如果处理不好，就会出现脏数据或者并发阻塞。阻塞用户体验差，数据错误则无法挽回，管理上会增加很多困扰。子荷项目使用选课队列加上读写分离的方案，应对高并发使用高速缓存做队列，后台只用单进程消耗队列申请，破解选课拥堵问题。使用交互读取缓存，进程操作数据库的方案，加上同步线程，优化动态显示变化的选课数据与用户交互体验度。
完备统计和汇总。平台提供实时的选课监控，对于课程的余量情况和班级的选课进度进行可视化跟踪，通过可视化的数据，学校也可以得到课程的热门程度，和班级选课的进展情况，用于调整课程资源和发现通知发布渠道的问题。；选课的数据则按班级、课程两个维度汇总便于管理使用；特别对于学生家长的绑定情况做了单独的汇总功能，便于学校敦促家长绑定平台完成选课。
支持“全家”抢课。平台以学生为核心，一个家长可以绑定多个孩子，用一部手机为自己多个孩子完成选课；同样的全家人也可以同时绑定到孩子上，在课程资源紧缺的情况下，谁有空谁就可以完成选课，也可以大家一起抢课。甚至如果家长没有智能手机，老师都可以代为选课。
灵活课程设置和限制。对于课程可以通过简单的设置，决定面向那个年级开设，或者那个年级限制选择多少门，也可以设置学生的选课门数。
支持两种选课模式。平台内置两种选课模式，一种是时间优先制，很容易理解就是先选上的就先选好，排队的，资源有限的情况下谁先进入了队列，谁就先得到课程的名额；还有一种是筛选制，课程设定一定的容量，但是可以超出容量来选课，大家的机会是一样的，后台随机筛选，被筛选掉的学生需要再选一次课；两种模式可以随意切换。
消息推送。平台利用微信做消息推送，对于选课的状态和结果定向反馈。如果进入选课队列，不用你查询，系统就会推送结果给你了。比较省心；对于绑定了多个家长的孩子，如果平台推送消息，所有的家长都会受到。爸爸如果接到妈妈分配的任务说给孩子抢课，结果忘记了，爷爷在家空的，带着眼镜按时给孙子抢到喜爱的课程了，全家都会受到选课成功的通知。：）
4.问题
- 问题1如何筹措支持未来长远开发计划经费；
- 问题2服务运行期间产生的服务器租用费用，短信费用目前都是个人自行承担，实验性质可行，如果真推广了，担负不起了；
- 问题3如何说服小学换用子荷项目替代原有老旧选课平台？这个最关键！
5.未来
- 子荷项目核心仍然是公益项目，标准模块仍然想采用免费的模式推广；
- 但是对于子荷项目的未来，我的目标是想创建一个能够帮助到老师和解放家长的沟通平台。真心不想在微信或qq群里接龙了，我相信老师也不想。
- 经过选课之后，用于沟通的基础已经创建好了，家长的openid已经采集到了，子荷未来一定要设计虚拟的组织结构帮助教师群发消息给家长，通知家长阅读的结果也要很容易反馈到老师。家长也要容易找到历史的通知，作业要求之类的，坚决不要接龙。
- 子荷无论走到那种地步，我不想它变成一个使用很复杂不容理解的平台，我还是希望它是一个刚露尖尖角的子荷，是一个给家长减负，给老师方便的工具。让大家爱上使用它，比它提供了很多听起来很牛的功能要有意义。慢慢来吧。
