GTD时间管理作品总结

GTD时间管理项目接近尾声。

前端后台通用代码兼容 GTD 时间管理项目的PC端开发其实是从寒假开始。随着底层数据库的粗略确定,后台服务器的通用功能 C 代码(譬如网络数据的打包和解压)在组员的帮助下完成了。对,是C代码,因为一开始是后台服务器决定使用纯C编写。现在想起来,那时太固执了,这就好像,别人扛枪拉炮攻占我们的地盘了,我们放着原子弹不用,还吵着要提着扁担锄头跟敌人死磕。最后改为了C/C++ ,编译器也相应改为 g++ 。

另外,那个时候,我还很自信,小看了未来将要遇到的问题。

数据库设计,本末倒置 粗略确定!不知道浪费了多少编译连接调试的时间。现在看来,在动手开始一个项目之前,底层数据模式是需要首要考虑和确定的,当初自己犯下的错误就是本末倒置,更多的去考虑界面,虽在界面折腾了一段时间,还是有些许的收获,但衡量一下,是点芝麻丢瓜的赔本买卖。我不是说其他的不重要,但代码就是跟着数据走的,数据是软件的灵魂。

linux网络编程 在后台服务器网络编程上我琢磨了好长的时间。首先想到的是手动自己写一个最简易的功能模块,对网络数据进行收发。自己也确实是实践了,但最后没有采用,因为潜在未知的问题一直在困扰我(微博上的讨论:这里)。首先,GTD 时间管理项目不属于大工程,完成一个网络库工作量大,能考虑的和可能要考虑的问题多,得不偿失;互联网上流传着很多成熟稳定适用于 C/S 开发的网络库,衣来伸手饭来张口。

进行简单的测试过后,最终敲定使用 libevent 网络库:通过注册事件完成网络事务。

再来一次 发现数据库需要重新改写确定,于是和 @国东 再一次商讨了 GTD 时间管理项目后台数据库,确定下来之后,放心的在原有的基础上重新设计,重新做一遍。血淋淋的教训啊,重做的过程中,偶尔骂自己:「怎么会写出这么恶心的代码?」

确定DBMS和数据持久化 在数据库管理系统上,后台选用的是 mysql ; PC 前端一开始选用简单文件读写,但一来它很容易被用户更改,这是潜在的问题;二来,不方便进行数据更新。所以,选用了轻量级的 SQLite。

因为要对数据库进行添加/修改/删除等等操作,势必需要有可执行的 SQL 语句。一开是方法是到处生成raw SQL语句,然后交由数据库操作接口执行,缺乏数据持久性。当对数据库表修改的时候,势必要对raw SQL生成器作大量的修改。于是便有了 【译】Simple MySQL ORM for C。但这仍然有一个缺点,因为前端使用的是 SQLite ,Simple MySQL ORM for C 是为 MySQL 而生的,无法使用到前端中。最好是该用 LiteSQL ,不然学习的成本很大。

数据同步策略 最后一个较为棘手的问题:同步问题。在 CSDN 上发起的讨论:讨论:印象笔记的同步策略是怎么样的?

需要考虑三个部分,分别是用户新增、修改和删除。

其中「修改」可以用时间戳的方法解决(没错,因为数据库表需要添加 timestamp <时间戳>字段,所以上面提到的「raw SQL」需要进行大量的修改)。新增和删除则可以通过记录用户的操作来实现,譬如:用户新添/删除一个数据,则记录他的操作:

[user_id]:[data_item_id]:[datetime]:[operation]

当前端提出同步请求的时候,则对此用户的操作集进行分析,即可得到用户新增/删除的数据项。

我们团队成果 @卓升 负责移动安卓前端,已经做完而且上架:这里;@国东 和 @曼云 、@华娜 合作完成 GTD 时间管理项目 web 端:这里

最后 好记性不如烂笔头,鄙人需要写下在写程序过程中需要注意的问题,我甚至觉得这是程序员可以有的素养:

  • 交流。和同学网友社区提出自己的问题,给出自己的想法。

  • 集中火力。遇到瓶颈,集中弹药火力攻坚。

  • 结对编程。能大大提高编程效率,道不同不相为谋,最好与技术方向一致的伙伴结伴编程。

  • 勿重复发明轮子。很容易能再互联网上找到一些成熟的框架或者工具以及相关的文档,提取扼要部分,嵌入自己的作品当中。

技术总结 如果觉得上面说的太务虚,那接下来是GTD时间管理项目PC前端和对应的后台服务器开发的技术总结。

MFC界面开发:

linux网络编程:

数据库实践:

其他:

是为 GTD 时间管理总结。

捣乱 2013-4-1

daoluan.net

01 April 2013

disqus 可能被墙~