• 谢谢指正,确实是 float,我写错了 😀

  • Tower 的任务也需要做拖动排序,文章里面的这种方案的弊端在于,当数据量比较大的时候,比如一个项目里有几百条任务,然后每天有大量的用户去做任务的拖动操作,这个时候如果你把全量数据都发过来重新排序,就会有大量的数据库写操作,效率会很低。

    我们采用的办法是,设置 position 字段为 float,这样当你拖动一条任务的时候,你只需要发送给服务器这条任务排序以后前后的任务 ID 是什么。

    比如我有如下任务:

    任务1 - position 50.0
    任务2 - position 100.0
    任务3 - position 150.0
    

    我如果把 任务3 拖动到 任务1 和 任务2 中间,只需要设置 任务3 的 position 为 (50.0 + 100.0) / 2 = 75.0 即可。这样每次只会更新一条记录,压力就会小很多。

  • yep

  • 是的

  • Yep

  • 首先 CalendarEvent 上有一个版本号字段,然后用这个 https://github.com/rossta/montrose 批量生成提醒,放进 sidekiq perform_later 里面执行,这里需要注意的是要传入 CalendarEvent 当前的版本号。

    每次更新 CalendarEvent 的时候 update 版本号,并且重新生成发送任务。队列在执行的时候,先判断版本号是否和当前 CalendarEvent 对应的一致,一致才真正的发送通知。

    还有个问题是,重复到什么时候呢?比如按周提醒的事件,创建多少提醒事件呢?Tower 里面是默认创建一整年的,每年 1月1号 重新生成所有 CalendarEvent 的批量事件。

  • Tower 其实体量并不大,只能算是小型 Web 应用,不需要拆分的。新版 Tower 还有一个月左右发布,目前代码总量只有 7347 行,因为是重写,所以很多结构做了精简,用了不少成熟的 gem,实现都很简单,完全不需要什么微服务,engine 之类的东西。

  • 并没有

  • 远程工作可以看成是不用到办公室上班的工作,所以时间还是正常工作时间,不会有考勤。手上基本上不会出现没有任务的情况,没有任务可以做重构,可以做性能优化,可以补充文档,补写测试,妥妥的 full time。

  • 有点悬,我们这次要招募 Ruby On Rails 熟手。