最担心的事情终于来了,运营终于弄了半点开始的排名赛,甚至还在里面塞了大量的紧急

于是很喜闻乐见的,时间表没法处理这种紧急了,只能显示出排名赛。
而且时间表的逻辑也没考虑到会出现半点开始的排名赛,12:30 开始, 2:30 结束这种也只能识别为 12:00 开始,2:00 结束。
反正这周处理出的时间表基本是处于不可用的状态了。

这个时间表当初是作为 JavaScript 入门随便瞎搞的,只用了原生 js 以及 jQuery,没有用到目前主流的框架。
甚至前端的实现方式还不是用的动态创建元素,而是十分无脑的 html 内容填充。
虽然用 Python 写的后端至今为止也就因为官网大改版重写了一次,没遇到什么大的问题。
目前来说要在时间表的前端部分再修修补补也不太现实了,当初设计时根本就没想太多。
反正我代码写得渣嘛,嗯哼。

Then

基于以上原因,时间表的前端部分大概要进行一次重写。
之前想做的时区转换,紧急过滤,一键生产时间表图片之类的由于当前代码的限制,做起来十分困难。不过重写之后应该会好点了吧。
官网用 list 模拟 table 的实现方式让我挺感兴趣的,而且这样也能跳出合并单元格时不停 colspan rowspan 的怪圈。
半点紧急之类的对应也可以做得相当灵活了,反正肯定比现在的好。重写的时候主要会注意可扩展性之类的。
后端数据目前没有太大问题,所以工作量应该不会太大。
不过什么时候出成品大概是未知数了。咕咕咕。
这周固定时间表就拜托 Swiki 老师了。虽然随机紧急没有什么问题,所以可以继续用。

也许还会考虑优化手机访问时间表时的体验。咕咕咕咕咕咕咕咕咕咕

One more thing

也许有人已经注意到了,昨天傍晚的时候紧急表 稍微中断了一会儿然后 开始使用HTTPS了

这主要是因为在Chrome 62版本以后,非HTTPS不再支持发送桌面通知,也就意味着 我主打的 通知功能废了。
所以我上了HTTPS,就这么简单(
对正常使用应该是没有影响的,不用过分在意。