背景

• 参考: 支持离线签到 · Issue #4 · PyConChina/lucky
• 并行签到是必须的,以免造成阻塞
• 最好也能移动端

分析

• 静态的 cvs 样数据, 转换为 JSON 数据加载到网页
• 同样的接口, 就可以将 cvs 静态数据变化为 RESTful 本地服务
• 多种客户端同时签到
• 嘦确保:
  • 识别重复签到
  • 记录首次签到客户端编号
  • 多机或是单机签到数据可快速合并导出为抽奖用数据

方案

建议根据简单优先来考察:

• 单点服务,多点签到:
  • 本地局域网络
  • 启动一个数据服务
  • 其它网页使用无认证 RESTful 接口进行读写签到数据
• 多点服务,多点签到,定期合并
  • 本地局域网络
  • 每个签到客户端,都能启动一个数据服务
  • 通过 UTP 协议,进行快速广播数据变化
  • 根据时间戳,进行签到唯一性识别

背景

根据往年的经验:

• 每年报名/门票 服务系统都不同,导致抽奖人员数据格式不统一
• 每年赞助商的 logo 变化比较大, 已经无法统一进行静态展示

分析

但是,有不变的:

• 现象人员用来抽奖展示的只有: 姓名|邮箱|照片
• logo 永远是尽可能的全部展示/轮播

方案

• 明确最终可用数据格式, 给出一个可以快速定制,清理 csv 格式输入数据的 CLI 工具
• 可以自动完成:
  • 指定有效字段
  • 处理中E混杂
  • 合理截断展示信息
  • 截取/生成 唯一性ID 用以抽奖后导出使用

背景

• 无论使用什么报名/门票系统
• 都没有什么靠谱的离线签到支持
• 而天朝特别是学校的网络,根本不可能支撑的了平滑的网络签到!

分析

• 抽奖的前提是,已知现场到达了多少人,以减少无效抽中机率
• 而签到是基于事先报名/门票,以及少量现场报名
• 所以, 抽奖就是签到的反面,当然可以兼容代码 ;-)

方案

• 相同导入数据, 不同界面
• 保持 赞助商轮播
• 接收唯一 签到码
• 标定到场
• 用专用工具,签到结束后:
  • 导出 cvs 数据备用
  • 转换为 抽奖用数据,加入到页面数据中

背景

抽奖的一般流程:

• 现场抽奖+合影
• 会后针对性通知/提醒
• 追踪奖品使用/回顾报道收集

分析

一般性的问题在:

• 现场中抽情况复杂:
  • 中奖人不在
  • 代领
  • 多人中奖
  • 放弃领取
  • ...etc
• 而现场情景紧张,无法方便的记录下来所有情况
• 导致会后只能根据录像/录音 进行回顾,对比中奖数据,进行后期处置

方案

• 精确厘清所有现场情况
• 定义为最多5种状态的标记
• 对应到5种快捷键
• 在界面/数据上都进行标定
• 事后,可以快速导出为 cvs 数据
  • 以便可以快速导入 Docs 等数据管理文件中进一步使用