w6-微信公众平台

先说些不太相关的

最近51cto在办活动,收集一些不错的linux命令,其中我觉得这个很有用,原来大妈在cli里的一些诡异的操作可能是通过这些快捷键实现的,mark一下

命令行日常系快捷键

如下的快捷方式非常有用,能够极大的提升你的工作效率:

CTRL + U - 剪切光标前的内容

CTRL + K - 剪切光标至行末的内容

CTRL + Y - 粘贴

CTRL + E - 移动光标到行末

CTRL + A - 移动光标到行首

ALT + F - 跳向下一个空格

ALT + B - 跳回上一个空格

ALT + Backspace - 删除前一个单词

CTRL + W - 剪切光标后一个单词

Shift + Insert - 向终端内粘贴文本

还找到了一个很作死的命令也很有意思:

$alias cd='rm -rf

不怕死的可以作一作。

gitbook editor

首先安利一个好东西,之前以为没有什么好用的本地gitbook编辑器,各种搜索找了为知笔记和一些别的都不怎么好用,最后拿sublime加markdown插件替代忍了,但用起来也鸡肋得很,一方面markdown插件格式与gitbook格式略有差异,另一方面代码与笔记都是sublime在mac上经常容易切换混乱,影响心情

这次终于搜到了个好东西,居然官网本来就有gitbook编辑器,我之前居然不知道,官网本身似乎也没链接,下了用后,立刻爽歪歪了,而且不只可以与gitbook直接同步,还可以与github本身项目同步,实现互推,只是看来当前版本并不十分完善,在配置互推时候只支持https的REST格式,拼写检查也不包含中文,这大概就是主页上没有主动宣传的原因所在吧。

关于安全

最近入手了《flask web开发》,简单过了遍,对flask即刻有了一定的了解,这本书里面详细的讲明白了flask-wtf怎么用,我准备把表单换用wtf来替换,而且尤其引起我注意的一点是它谈到了web安全,其中提到了表单的csrf攻击,很有意思。

我之前对web的安全只知道sql注入的原理——通过sql语句hack到表单的输入框中执行攻击者的sql条目。而flask等框架默认对'?'替换掉的参数输入部分已经做了过滤,所以不需要担心。

而csrf则是利用cookie则是利用恶意网站获取浏览器中的cookie来对指定网站hack的,而且对自己的网站加个随机数,用hashkey的方式就可以一定程度的防范掉,利用flask-wtf就可以轻松设置。

数据库 2

继续上周的数据库任务,这周是要把db换成mongodb,数据库已经就绪,随时可用。由于对Nosql的结构不是特别了解,估计存储结构不像mysql一样是二维表,所以参考了几篇文章:

Nosql入门知识

NoSQL设计思想

MongoDB数据库设计中6条重要的经验法则

然后知乎上有人说:

把mongodb当成一个大json对象处理,别老想着用了数据库。——王小鹿

说的言简意赅,我一下就get了。

然后,我需要找到python数据和json的关联,也许就是直接写的格式,也许是某个内建函数,或者某个更好地将python数据转成json的工具。

Json概述以及python对json的相关操作

参照 官网的api 简单测试了一下

>>> import json
>>> import pymongo
>>> client = pymongo.MongoClient('172.16.191.163', 27017)
>>> db = client['testdb']
>>> collection = db['testtable']
>>> data1 = {'b':789,'c':456,'a':123}
>>> d1 = json.dumps(data1)
>>> collection.insert_one(d1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pymongo/collection.py", line 463, in insert_one
    common.validate_is_mutable_mapping("document", document)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pymongo/common.py", line 374, in validate_is_mutable_mapping
    "collections.MutableMapping" % (option,))
TypeError: document must be an instance of dict, bson.son.SON, or other type that inherits from collections.MutableMapping
>>> d1
'{"a": 123, "c": 456, "b": 789}'
>>> collection.insert_one(data1)
<pymongo.results.InsertOneResult object at 0x101ea0a00>
>>> db.testtable.find_one({'a':123})
{u'a': 123, u'c': 456, u'_id': ObjectId('564f4515e3465f5d4475e024'), u'b': 789}
>>> db.testtable.find({'a':123})
<pymongo.cursor.Cursor object at 0x10267ef90>
>>> for i in db.testtable.find():
...     i
...
{u'a': 123, u'c': 456, u'_id': ObjectId('564f4515e3465f5d4475e024'), u'b': 789}
{u'a': 123, u'c': 456, u'_id': ObjectId('564f47afe3465f5d4475e025'), u'b': 789}

然后通过客户端即可查看所插入的数据:

屏幕快照 2015-11-21 00.12.56.png

发现原来在数据库层面,是直接用的字典型数据插入的,如果是格式化好的json格式反而会报错。

另外发现很有意思的一点就是,每当我插入一条字典类数据后,我的原字典会多出一个'id'的索引,插入数据居然会对原数据产生影响,有点儿匪夷所思。

>>> data2
{'a': 123, 'c': 456, 'b': 789}
>>> collection.insert_one(data2)
<pymongo.results.InsertOneResult object at 0x101ea0960>
>>> data2
{'a': 123, 'c': 456, 'b': 789, '_id': ObjectId('564f47afe3465f5d4475e025')}

首先测试下直接带入参数是否有问题

>>> d='111'
>>> e='222'
>>> f='333'
>>> data3 = {'d':d,'e':e,'f':f}
>>> data3
{'e': '222', 'd': '111', 'f': '333'}

git项目管理姿势

在oschina上遇到了这篇文章介绍一个成功的 Git 分支模型,感觉很受用,很适合基于docker的版本管理,可以在不影响主项目运行的前提下,在同一平台实现测试。鉴于我的项目很小,所以我打算做出一个develop的主分支,作为开发版本来commit,然后正式的生产上直接用master。

25142840_pKcL.png

微信公众平台

这周任务是微信公众平台,想了很久,感觉很难把wheniwas18包在平台里,不过可以先做个平台账号试下看看。

首先参照微信平台的接入指南,简单了解了下基本的接入方式,将url填上,然后随便填了个token:tokenofwheniwas18,然后获得了个随机加密码:cHh3ulY8VjLY7Rt52oIARdncto8owsx77RoEIW3oY7B,选择了推荐的安全模式。此时提交,提示我验证失败,看来是需要我先在服务器端实现才可以。

应用方向调整

之前一直关注了很多一些微信账号,但从来没有深入的研究,这次轮到自己做才发现没自己想的这么简单,微信账号已经成为目前事实上最流行的paas平台了,很多常用的应用的逻辑可以完全只依靠一个微信公众号就可以简单地实现,完全没有必要非独立的做app。

这次做完www.wheniwas18.com发现这个脑洞需求有点太大了,相比当前的流行应用来讲,技术上虽简单,让人但关注它太复杂,体现在以下几点:

  1. 完整性要求高——按照既定的规则,很容易造成看故事的人由于前文太长没有耐心,不关心逻辑或者脑洞,或者以纯测试和捣乱的心态,随便插一句不合时宜的话,整个逻辑就进行不下去了,最后很难得到一个差不多的故事。
  2. 难以局限范围——本来期望把这个应用的范围之局限在小范围朋友圈内,但目前看来没有什么好的思路来控制。
  3. 名字太冷僻——『那年18』这个本来也不算原著梗,而且即便是原著梗也鲜有人知,然后还要绕半天来解释,这名字看来是起的太随便了,打算换个简单粗暴易理解的名字,不过由于当前微信已经绑定,恐怕很难在通过账号调整。

综上所述,在没有更好想法的情况下打算先观望下大家其他人的想法再坐下一步