就教育而言，内容始终是个宝贵资源，随着平台课程增多，如何备份就是个摆上日程的问题了，当课程还少的时候，采用定人定期备份的方式也觉得尚可接受，可手动备份的缺陷太多
这类工作让代码来做再合适不过了，所以我写了个备份Open edx课程的工具，已经上传到github和pypi，直接安装就可使用
当前版本只支持python2
建议采用virtualenv来管理环境（virtualenv -p /usr/bin/python2 env）,使用centos的同学最好采用以上建议，其他操作系统的其他同学可以无视
我们先来看下如何使用，十分简单，首先安装它：pip install course_backup
安装完成后，执行course_backup --help会看到参数提示
首先你需要登录studio，查看你的cookies中sessionid和csrftoken字段，然后填入配置文件，默认的配置文件为~/.backup_course.ini,当然你也可以自己指定它
我的配置文件为(cat ~/.backup_course.ini):
|
|
填好配置文件后就可以启动备份任务啦
course_backup –start
course_backup –start –night
course_backup –start –config_file ./my_config_file.ini
course_backup –start –courses_data_path /tmp/data
course_backup –start –night –interval_days 7 –courses_data_path /tmp/data
每七天备份一次，滚动周期为3周（超过3周的文件将自动删除）
这个自己写的工具从使用来看倒是挺顺手的。不过设计的时候，有一点始终让我左右为难：是提供一体化的解决方案好，还是让工具只专注在一件事（诸如只下载课程），然后把它和其他linux工具组合起来使用
《Unix编程艺术》里建议说
do one thing，and do well
这也是Unix哲学提倡的。
陷入到实际项目中，什么叫one thing呢？就很让人头疼，在这里我可能觉得backup courses整件事就是one thing，而其他人可能觉得download course是one thing，other thing可以通过组合其他工具，这样最终完成backup courses，诸如：
如果你真的这样做，你可能会发现，实际上我们只是把编程的任务从python移交到bash脚本里。
在bash里写逻辑是我极不情愿做的一件事，相比于shell里那些好用的工具（vim/grep/find/sed…），bash的语法简直丑哭。所以就我而言我会选择尽可能用python把逻辑写到course_backup里，对外暴露出配置选项，那么我的one thing粒度可能大一些
即便如此我对一些东西是不是应该包含在工具内还是犹豫不决，即便现在也是，诸如定时任务功能是应该用系统的cron来做还是采用python的定时任务模块来写到工具内部，写在外部的好处是：
而混杂在工具里，就是这个工具不得不是一个常驻进程，同时为了追求灵活的配置参数，解析参数的代码也会很长，而这些本不是核心代码，不过是重造了一个丑陋的车轮
可把定时功能混和在工具里，也有好处
当然你可以说这是我对目标用户的定位不够清晰。这又是另一种度的问题了。工程问题也许就许多这一类各种因素都需要权衡的问题
关于one thing的粒度，我一直拿捏不好，不知道别人是不是也有这个疑惑。我的自我安慰是这是一件需要权衡的事，也许还包含武断/拖鞋的/拍脑袋的过程，也许我们会把它称为直觉，无论用哪个词，指的似乎都是非理性的判断过程
这可能也是《Unix编程艺术》书名中艺术的所指吧
我并不是说我不喜欢do one thing，and do well这个建议，相反，它可能是我最喜欢的几个编程箴言之一，它优美而非线性，需要我们不断打磨练习和试错。在我读过的所有计算机的书里，《Unix编程艺术》和《代码大全》可能是我最喜欢的两本实践类指导书籍，我把他们看做best practice。
付诸直觉的事，尤其是在各种特质中做折衷选择的事，决策者肯定都会有足够的理由为自己辩护，最后我们能说的可能只有
Talk is cheap， show me your code
就教育而言，内容始终是个宝贵资源，随着平台课程增多，如何备份就是个摆上日程的问题了，当课程还少的时候，采用定人定期备份的方式也觉得尚可接受，可手动备份的缺陷太多
这类工作让代码来做再合适不过了，所以我写了个备份Open edx课程的工具，已经上传到github和pypi，直接安装就可使用
当前版本只支持python2
建议采用virtualenv来管理环境（virtualenv -p /usr/bin/python2 env）,使用centos的同学最好采用以上建议，其他操作系统的其他同学可以无视
我们先来看下如何使用，十分简单，首先安装它：pip install course_backup
安装完成后，执行course_backup --help会看到参数提示
首先你需要登录studio，查看你的cookies中sessionid和csrftoken字段，然后填入配置文件，默认的配置文件为~/.backup_course.ini,当然你也可以自己指定它
我的配置文件为(cat ~/.backup_course.ini):
|
|
填好配置文件后就可以启动备份任务啦
course_backup –start
course_backup –start –night
course_backup –start –config_file ./my_config_file.ini
course_backup –start –courses_data_path /tmp/data
course_backup –start –night –interval_days 7 –courses_data_path /tmp/data
每七天备份一次，滚动周期为3周（超过3周的文件将自动删除）
这个自己写的工具从使用来看倒是挺顺手的。不过设计的时候，有一点始终让我左右为难：是提供一体化的解决方案好，还是让工具只专注在一件事（诸如只下载课程），然后把它和其他linux工具组合起来使用
《Unix编程艺术》里建议说
do one thing，and do well
这也是Unix哲学提倡的。
陷入到实际项目中，什么叫one thing呢？就很让人头疼，在这里我可能觉得backup courses整件事就是one thing，而其他人可能觉得download course是one thing，other thing可以通过组合其他工具，这样最终完成backup courses，诸如：
如果你真的这样做，你可能会发现，实际上我们只是把编程的任务从python移交到bash脚本里。
在bash里写逻辑是我极不情愿做的一件事，相比于shell里那些好用的工具（vim/grep/find/sed…），bash的语法简直丑哭。所以就我而言我会选择尽可能用python把逻辑写到course_backup里，对外暴露出配置选项，那么我的one thing粒度可能大一些
即便如此我对一些东西是不是应该包含在工具内还是犹豫不决，即便现在也是，诸如定时任务功能是应该用系统的cron来做还是采用python的定时任务模块来写到工具内部，写在外部的好处是：
而混杂在工具里，就是这个工具不得不是一个常驻进程，同时为了追求灵活的配置参数，解析参数的代码也会很长，而这些本不是核心代码，不过是重造了一个丑陋的车轮
可把定时功能混和在工具里，也有好处
当然你可以说这是我对目标用户的定位不够清晰。这又是另一种度的问题了。工程问题也许就许多这一类各种因素都需要权衡的问题
关于one thing的粒度，我一直拿捏不好，不知道别人是不是也有这个疑惑。我的自我安慰是这是一件需要权衡的事，也许还包含武断/拖鞋的/拍脑袋的过程，也许我们会把它称为直觉，无论用哪个词，指的似乎都是非理性的判断过程
这可能也是《Unix编程艺术》书名中艺术的所指吧
我并不是说我不喜欢do one thing，and do well这个建议，相反，它可能是我最喜欢的几个编程箴言之一，它优美而非线性，需要我们不断打磨练习和试错。在我读过的所有计算机的书里，《Unix编程艺术》和《代码大全》可能是我最喜欢的两本实践类指导书籍，我把他们看做best practice。
付诸直觉的事，尤其是在各种特质中做折衷选择的事，决策者肯定都会有足够的理由为自己辩护，最后我们能说的可能只有
Talk is cheap， show me your code