那不叫工作，那叫奴隶

最好是自适应，可以减少代码总量。但是难度确实要高很多，实在不行就两套方案吧。

这是 Visual studio code 中 Launch.JSON 文件的配置片段:
{
"name": "Python: Flask (0.11.x or later)",
"type": "python",
"request": "launch",
"module": "flask",
"env": {
//"FLASK_APP": "${workspaceFolder}/microblog.py"
"FLASK_APP": "microblog.py",
"FLASK_DEBUG": "1"
},
"args": [
"run",
//"--no-debugger",
//"--no-reload"
]
},
在上述的片段中，我猜想"FLASK_DEBUG"是关键.
Flask 的官方网站是这么说的:
To switch Flask to the development environment and enable debug mode, set FLASK_ENV:

$ export FLASK_ENV=development
$ flask run
(On Windows, use set instead of export.)

Using the environment variables as described above is recommended. While it is possible to set ENV and DEBUG in your config or code, this is strongly discouraged. They can ’ t be read early by the flask command, and some systems or extensions may have already configured themselves based on a previous value.

原文请参考 http://flask.pocoo.org/docs/1.0/config/

不用讨人喜，讨她一个人喜就行了

我见过一个应用系统有类似的功能，但是是由应用程序实现的。
简单地说就是对于某个表进行写操作之前，把需要写的行 insert 到一个和源表对应的历史表中。

新增一个表，就叫做 EventType，然后用一个关联表表示 Eventtype 和 stage 的关联关系

去看看不是什么坏事，难道不是大多数人都是凑热闹的吗？无论什么大会。

trello 就行。

首先这不是 2 个表，是 3 个表
实现方法有好些，我觉得最简单明了的办法是用这 3 个表的字段建立起一个视图，这个视图包括你需要查询和显示的所有字段。
然后后端代码就查询这个视图就好。

所有提供给别人用的东西，都要优先考虑使用者的感受，然后才是技术实现。
写个后端接口，我觉得首先是要想别人如果要调用这个接口，应该怎么写代码。
想清楚这个，就很容易判断该怎么做了。

I'm a coding fans.

有一个软件叫做 Bluespice，这个是基于 mediawiki 开发的企业 wiki 系统。
我尝试在小部门内部部署了一个实例，正在试用。

这要取决你你手上有什么。
假如要汇总的数据来自一个已经开发完成的 Web 系统，我通常选择服务定时调用。原因是可以用一个集中的界面维护它。
如果只是临时用一下，例如用几个月，脚本也是可以的。脚本的问题是如果你需要交接给别人运维，会有点费劲。并且时间长了不方便记忆，必须借助于文档。
通常我不选择 windows 服务，除非整个系统都是基于 windows 做出来的。

所有的需求都要经过产品经理，开发不应该直接对接任何需求方。
这就是最委婉的方式了。
遇到任何你不想干的事情，都要尝试建立起各种流程，把其他人引入进来。
其实目的很简单，就是一个字:拖。

这个应该是一个初始化的脚本，然后管理这个脚本的版本。