Flutter + Firebase 开发流水账

上个学期的时候,因为疫情的缘故,我所在的学校为了控制食堂的人流量,引入了一款预约饭点的第三方移动应用。简单地说,这款应用的功能就是在完成身份验证后,让用户选取取餐的地点和时间,软件在点单完成后发送确认邮件,然后用户凭确认邮件去食堂取餐。可以说,业务并不复杂,实现得好应该也不难,但是不知为何这个APP设计得就很烂,用户体验特别差,预约步骤特别麻烦,每次需要:

指纹解锁APP -> 等待APP跳转到下一个界面 -> 点击“Start an order” -> 等待APP跳转到下一个界面 -> 选择预约地点 -> 等待APP加载数据 -> 选择日期时间 -> 等待APP加载数据 -> 将早饭/中饭/晚饭加入购物车 -> 等待APP跳转到下一个界面 -> 结算购物车 -> 等待确认邮件

整个流程下来如果运气好那么要30-45秒,如果运气不好,刚好处在点餐高峰期,应用后端便会不堪重负,前端数据永远加载不出来,然后应用直接崩溃挂掉。这款应用还会经常莫名其妙地闪退,或者出现整个界面失去响应,导致用户只能强制关闭。而且到了食堂要掏出手机,翻出那封可能早已经被其他邮件所淹没的确认邮件,给食堂门口那几位生无可恋的工作人员肉眼检票。刚开始大家还比较遵守规矩,会按照下单的时间和地点去食堂取饭,但到了学期中大家都被搞疲了,于是出现了五花八门各式蒙混工作人员的手段,有修图改确认邮件时间的,也有使用过期的邮件截图欺负食堂大妈眼神不好的,更有直接闯卡的。总而言之,这款应用不光使用体验巨差,也根本达不到原来控制人流量的设计目标。

寒假的时候闲来无事,就和另外两位CS系的同学,用Flutter和Firebase替学校的Dining Service开发了一款更加简单易用的预约软件,准备在春天投放使用,改善一下大家的预约订餐体验。比起原有的APP,新开发的APP主要有以下一些方面的改进:

  • 改用Google Account一次验证登录用户,省去了每次解锁APP的流程
  • 日期、地点和时间选择全部放在同一界面上,前端数据实时刷新,方便用户一键预约
  • 在就餐地点部署PROX读卡设备,用户点单后可以直接刷卡进入
  • 新增历史订单查看和取消功能

这个项目前前后后,断断续续大概折腾了一个月,最近总算是弄完了。这几天刚好有空,就胡乱写点东西记录记录开发过程,假装一下博客还在更新。

Continued reading >

Mapping Qing Relay Stations

The beta stage site is here.

During the Qing dynasty, the large network of postal and military stations, connecting the ruling kernel with China proper, Manchuria, Mongolia, Sinkiang, and Tibet, were venues of information and military logistics for monitoring the empire, and also routes which officials, scholars, merchants traveled. My recent project has been one of retracing these routes and transforming them into GIS databases. I will give a very brief technical overview of the backstage process here, and more blogs concerning specific routes will be posted in the coming months(most likely in Chinese).

Data Aggregation

The main primary source that I used was The Jiaqing Administrative Code of the Qing Dynasty (Jiaqing Huidian 嘉慶會典). My initial plan was to extract the information using OCR and then geocoding the raw data with a Google API. However, most of the OCR software that I tried was quite abysmal at discerning Chinese characters that were oriented vertically. I tinkered around a lot with various software parameters and have even thought of writing my own OCR specialized for this purpose but to no avail. In the end, I decided that for my data size, it was faster to have a flawed OCRed result and then eyeball the data for corrections. Geocoding was also pretty challenging: the Google API could only identify place names that had not changed since the Qing period and I had to do a lot of textual research in travel logs and gazettes to uncover the present-day location. For anyone interested, Xiao fang hu zhai yu di cong chao (小方壺齋輿地叢鈔) is a good source to look into.

Continued reading >

A Cheap World War II Visualization

I have always been interested in how history can talk to the quantitative, so as part of a small data science project, I thought it was a good idea to put together a visualization of World War II using R. It would be a sorry state of affairs if I had to salvage WWII data from library archives and digitize them, but fortunately, there are already enough interesting WWII data sources floating around the Internet that can be made good use of:

  1. Wikidata & DBpedia: These two queryable databases have structured data of WWII battles compiled from Wikipedia, mostly from Wikipedia infoboxes.
  2. Naval History and Heritage Command: Almost all of the losses of the Imperial Japanese Navy during World War II can be found here, including both commercial shipping and naval vessels.
  3. Wikipedia: Wikipedia also has many WWII info lists that can be used.
  4. Data.World: Data of all the bombs dropped by the Allies since WWI.

Out of these data, we can make a very simple (i.e. cheap) visualization of WWII. 

Continued reading >

RMQ-ST

无趣的RMQ-ST 模板。

[BZOJ1003] 物流运输

水一发dp+spfa