疫情之下，全港理发店及发型屋关闭，公元2022年4月的香港街头。。。

关于这个《港珠澳大桥穿梭巴士购票系统》，忍了很久，实在忍无可忍，还是不得不吐个槽。

1. 系统结构极为不合理

　a. 前台抢票系统和账号管理、支付界面，在同一个服务器群组，在大量用户进来抢票的时候，抢到票的用户，却发现再也进不去支付界面，然后14分钟之后，抢到的票即作废。在疯抢无数天以后，抢到了票，又眼光光看着订单失效，那种绝望，可以想见。据我了解，这种情况在抢票的时候已经在不断发生。这对于购票系统、以及用户的身心，都是一个极大的浪费和损害。



　b. 作为一个购票系统，应该考虑到用户量以及购票压力，据此对服务器进行合理规划，在大量的访问需求进来的时候，考虑如何分解压力，同时将不需要直面抢票压力的后台服务，转移到不受影响的服务器去。不说春运抢票、阿里双十一，就算百佳超市的网店，在访问量突发的时候，懒于重新设计原有电商网站的前提下，最简单的缓解方式，就是前置设置一个排队服务器。

　c. 在抢票发生的时候，穿梭巴士的官网网站（非购票页面）还是可以正常访问的，意味着他们是有分开服务器的，可是做架构设计的人想啥去了？

2. 软件设计完全没有考虑到压力问题

　a. 订票界面中，会以秒为单位，不停地去后台查询当日是否有票，如果有空位，即显示绿色，允许你选择该班次，然后可以点击购票按钮。这个设计在压力不大的系统中，可以这样考虑。但是在出现抢票的情况下，一个购票页面，在后台即自行产生每1-2秒一次的远程服务器访问，这不是在对自己的服务器进行DDOS攻击吗？

　b. 更可恶的是，任何一次后台获取信息请求失败，都会导致购票页面程序崩溃，自动跳出到错误页面，对，没有任何的容错能力。所以，如果你要购买3-4张票，你几乎没有可能输入完3-4个人的姓名以及证件号码，往往是输入一个名字页面已经崩溃，你需要重新返回刷新，然后重新输入所有的资料。

　c. 这时候你会发现，系统竟然没有储存购票旅客信息的功能，每一次进入都需要人工输入所有旅客的姓名和证件号码。做软件设计的人，想啥了？

3. 到了3月1日，经过用户大量吐槽甚至投诉，发现系统在不停进行一些改变，或者更像是测试，验证码最开始是数字、然后是字母加数字数字，更有一会是中文，一会是数字计算，最后又回到了数字。竟然在运营平台上进行测试，而不是在测试平台做好系统开发以及测试，在维护窗口一次升级运营平台。基本的平台运营理念都没有了？

4. 更为搞笑的是，购票窗口下面三位数的输入框，如何输入四位数的验证码？谁能通过这个验证？（经过测试，微信版是可以输入四位数的，到电脑网站就只能输入三位数）



好吧，最后来看一下这个技术支持，就是软件开发方——和方科技，从其官网可以看到，它就是开发粤港巴士的售票系统以及运营这个售票系统的，没有别的成功案例。

公元2022年2月22日，星期二，农历正月二十二，22时22分！

外面Omicron肆虐，禁足在家的日子，看完精彩绝伦又充满欢乐的冬奥花滑表演，看了场《悬崖之上》，又看闭幕式，再重温了《智取威虎山》，当年的少年，而今已成奥运冠军。重看影片的对白，禁不住的欢乐：

​大人：你会滑雪吗？
​小苏：滑雪谁不会啊！

​出发前，
​大人：跟紧点，别走丢了！
​出发后，
​大人：跟紧点，别让他跑没影了！
​到了目的地，
​大人：我们都跟你学滑雪吧！
​
​​​

北京冬奥，韩聪隋文静在花样滑冰决赛中成功赢得金牌！在三对俄罗斯超强选手中，生生抢下这枚金牌，实在是太不容易了！特别是后来获得季军、亚军的两组俄罗斯选手成功表演后，压力非常的大，上了高难度也非常容易失误。太不容易了！恭喜恭喜！

后面三图请看具体的评委评分情况，有些有趣的发现。

图7是韩聪隋文静的得分，有动作被扣分，裁判打分非常平均，意见很一致。

图8是亚军的得分，完全没有失误，动作没有扣分，但是评委有两个评委在明显提分，打10分。

图9是季军的得分，动作明显有失误，但是竟然没有扣分！还发现有一个裁判明显不喜欢他们。

至于第四名的俄罗斯选手，失误就比较多了，扣分正常。

疫情期间，在超市中采购的男人，左手拉着巨大的手拉车，右手还推着一辆购物车。

666宿迁舰，属于新调防香港的056A级导弹护卫舰，这天在尖沙咀刚好看到它在波光粼粼中巡航维多利亚港。

疫情肆虐的日子，更是怀念自由呼吸的空气、无拘无束的蓝天！