本文完全是开发牢骚。。
起因是这样的，去年（15年）8月随手注册了一个公众号，想用来做B站提醒服务用，结果后来就被我放置PLAY了。。因为觉得自己VPS简单部署一下python脚本就好了，要添加直播啊，视频更新啊，视频增加分P了啊，或者新番更新之类的就ssh上去手动加一下，期间甚至无聊建了个超级简单的index页面来操作（后来觉得页面的设计审美过不了自己那一关就弃用了）。。。
然后前几周在B站看了一个Up的系列视频，久违了笑抽了，推荐给朋友，笑抽传染+1。。。因为这个Up的视频几个月更新一话，所以就自己添加了提醒，给朋友说了这个功能，他也想要接受邮件提醒，于是想起了那个冰封多一年的公众号，于是上去看了一眼后台。。。。我屮艸芔茻，怎么这么多人关注了。。。这可是一个完全空白的订阅号啊，不会回复不会发东西的。。。于是乎，我觉得，还是花点时间把服务搭起来吧。。虽然觉得是个很小众的需求。。不过反正核心python脚本早就写好了。。
说起来公众号申请什么的还是很容易的，几乎没门槛，开发也是，几乎不需要参考任何别人封装好的东西，唯一最大的门槛就是，妈蛋个人申请的公众号只能是订阅号，而且这个订阅号不可以申请认证，这就导致了，功能权限什么的少到想好好把玩一下都没办法，垃圾微信！！（领导：喂，那你明天不用上班了！）
开发之初我yy的功能是用户发送订阅，后台检测到更新时就发条微信给用户，而且可以给用户打上不同的标签，赋予不同的交互权限；提供菜单操作，优化交互流程。。
经过研究一番权限，发现唯一的功能就是，用户发消息，你五秒内回复他，其他你什么都干不了。想要随时提醒？想多了。。没认证的公众号自定义菜单开了开发者模式是不能用的，用户标签权限不足。。。
所以最后就还是变成了我以前自己用的模式，添加订阅，然后邮件提醒。。
调研了一下，发现了一个很轻松的开发方法：
后台用的框架是flask，因为这个简单，而且有个debug模式，测试极度方便，代码改了可以实时生效，不用重启进程，然后配上本地sublime text加一个ftp插件；开发别提有多爽了，本地编辑的代码按一下cmd+s保存，发条微信去看看，就已经生效了！根本不需要ssh登陆服务器。
好景不长，没一会就发现这种开发模式的问题了，出了BUG，服务器不会响应，还是需要ssh上后台看log，于是想起python的装饰器这一神器，写个装饰器：
def SendError(fn): def wraper(*args, **kvargs): try: return fn(*args, **kvargs) except Exception,e: if DEBUG_MODE == True: return traceback.format_exc() else: return u"后台貌似出现异常了。。。" return wraper测试阶段把DEBUG_MODE设置为True就可以了，一旦代码写错，发送微信请求后会自动把错误信息作为回复发送回来，每一个刚写的函数出了错，开头@一下这个装饰器就可以了。
@SendError def test(user_id): xxxxxxxx享受这开发的便利，爽没一阵子，又发现问题了：直接运行一个开了debug模式的flask文件，因为只有一个进程接受请求，而且是堵塞的；本来想着测试开发嘛，单线程堵塞都不是问题，大不了写错了我干掉重启进程就好，但是后来发现这种模式下会有一些迷之BUG，总之就是你要运行了某些很简单很朴素的代码，进程就会堵调，大概底层死循环之类的，google了一下，github上给出了算是官方的解决办法：部署到apache即可解BUG！！
于是捣鼓了好多天的apache，权限，配置文件之类的简直神烦，最后总算部署好了，发现一个问题：flask的debug模式用不了了。。我要便捷开发啊！！
搜了一下，发现下面这个启动方案：
from werkzeug.debug import DebuggedApplication application = DebuggedApplication(app,True)但是呢，1分钟后我就发现问题了，apache是一个多线程来接受请求的，我修改代码后，妈个蛋居然只有部分线程修改了，也就是说，比如原本我发送a，后台回复b，我改成让它回复c，这下好了，我不断地发送a，有时返回是b，有时是c。。。
我需要一个代码修改后马上生效的方案，想了五分钟，想到一个累死服务器的方案，写一个shell脚本，每隔一秒检测一下本地所有py后缀脚本，一旦修改就运行service apache2 restart！！！而检查本地所有文件的修改也有很简单的解决方案：cat *.py | md5sum，直接算所有py文件的md5来检测修改。。
问题终于彻底解决了，即便后来因为apache实在内存消耗大户，改成nginx，也只要修改一下变成重新加载uwsgi的ini文件而已。。
愉快的开发环境搭好，接下来处理的逻辑即便太复杂，也可以享受到开发的乐趣了，比如用户请求订阅的格式解析和检验（检验部分占据了绝大部分代码量，写到我都觉得可以去做测试了。。），邮件验证，多人订阅相同内容但是设置了不同的过滤条件下如何避免重复提醒之类的。。。
唯一的感受就是：多人使用的服务和自用的差别还是很大的TAT。。。
后来还很无聊学别人接入了图灵机器人，总的来讲这个免费版的机器人，在百科知识和简单的上下文处理上还是做得不错的，比如之前有个同事中午玩网游需要答选择题，问题诸如『中国最大的湖是...』之类的，然后基本上直接开着公众号语音输入就可以得到回复了，感觉还是很方便的。。
当然不是给这个机器人打广告的，因为百科以外的问答，比如聊天之类的还是比较烂的（谁特么会跟你的公众号聊天呢？），一个很好地例子就是一个师弟不知道发什么神经调教了机器人半天（我有一个智障师弟系列），终于让机器人骂脏话了。。刚刚看了一下，原来不骂脏话是付费升级功能：
当然还准别实施一些别的脑洞来玩，比如最近搞了个树莓派pi3，准备把这个公众号服务部署上去，然后通过公众号发送消息来开关我房间的空调之类的。。
建了个订阅号来玩（开发篇）。。。-雅安空调维修技术培训学校
