@shyrock 是写代码写久了还是心理阴暗负能量压身，偷换概念这种事情做得真是信手拈来毫不费力了，在您看来贴这些图就是诈骗，冒昧的问一句，您看的世界如果是一个除了自己别人都是个渣，都是诈骗犯的世界，就不允许别人发图片招嫖了么？

哦，对了，我看美女图从来不回谢谢 LZ ， 1024 。在我的世界看来，我喜欢美女妹子我就直接去追，不会再网上瞎比，也不会看到任何美女图都觉得跟自己在 1024 上看到的那些一样自行脑补，那样的人生显得有点 low ，会让我怀疑自己是否是个正常人的。

@shyrock 你是在微信里见过招嫖广告是什么样么？还是半夜在酒店捡过小卡片？一个简单招人的帖子罢了，其实现在 JD 确实真难写，列一堆硬性要求吧，然后薪资面议吧，有人说太死板，不活泼。写活泼点开个玩笑，然后给个薪水范围吧，还有人严肃得跟广电总局审片员对着屏幕开始喷起来了，似乎觉得自己一直都是站在人生智力情商巅峰上在嘲笑别人。

@cheerzeng 如果你想借助这个cache来完成你想做的事情，其实会比较累，首先用户填写的数据需要提交到服务端，再由view缓存起来，然后你需要再在模板里用{% load cache %}之类的标记来加载这些缓存数据。

@cheerzeng 你只是想知道django怎么在view里使用cache吗？那看官方文档就好了。

https://docs.djangoproject.com/en/1.8/topics/cache/#the-per-view-cache

跟django,cache都没关系

预览页面要么用modal窗口,要么用js的cookie存储表单数据在预览页面显示

是的，首先Django这里叫MVT。
Model,View,Template，比较常见的模式是在Model中除了进行数据模型定义之外还会写上关于数据库操作的代码，View作为接收页面参数，调用Model的方法以及决定如何渲染页面，Template就不用讲了。

我个人的一些经验是，在MVT之外，会实现一个类似于Controller的层，用来封装所有底层业务操作，包括通用函数，数据库操作，业务数据计算处理等等，Model就只单纯做模型定义的事情，View就只做数据收发和对Controller的调用。

根据我一年多的观察实验，我和一个综合水平差不多的同事，他用pycharm，我用submile text，在生产效率上没有什么区别。

对他来说好处是编码过程更轻松自由点，包括自动补全，语法提示什么的，甚至是很好的git集成，坏处是时常交流时需要去回忆某个模块某个功能在哪里，和其他包之间的依赖关系是怎么样的。

对我来说好处是编辑器响应速度快，能比较清晰的时时刻刻厘清包之间的关系，创建一个test code用于验证想法只需要1秒就可以新建一个文件，坏处是会比较费脑子，即使有一点模块内的语法提示和简陋ctags,还是觉得有时候比较费劲。

事实上，我偶尔帮别人调试代码用用pycharm，还是觉得用着挺爽的，但是就是用不长久，因为我觉得它带来的那些优势并不足以提高我太多的工作效率，事实上，我一天能写200，300行有效代码就谢天谢地了，大多数时候还是静静的发呆，画图，考虑怎么设计，这个时候pycharm并帮不上太多的忙。

支付功能最简单的逻辑（抛开ping++不提）

1:用户在你的系统里做某个操作得到一个订单(订单编号按照自定义规则生成，需要唯一标识）

2:参看第三方支付的 sdk，每家标准不同，当用户创建完订单开始支付时，服务端内部(django）需要用sdk向第三方支付平台发起支付申请(可以把刚才创建的的订单编号传过去，还包括一堆 有的没的参数，包括支付结果的回调地址，根据sdk需要来）

3:带着参数redirect到第三方支付页面(也有别的情况，例如微信支付就是拿着prepayid之类的丢给浏览器js继续处理)，总之这一步就开始让用户进行支付的操作了

4:支付完成，两种支付通知方式：
1:第三方支付发起同步跳转请求到你的web服务上,带着参数将支付结果告诉你的某个接口，你进行解密后拿到支付是否成功的信息，对你的数据进行操作。
2:异步通知，第三方支付会在它后台向你的异步通知请求接口发起支付结果请求，如果因为网络问题，一次没访问到，会多访问几次,如果n次之后还没有访问到，不再请求，你需要手工查询进行处理。

支付结果通知建议同步和异步两种都做，当然每一个方式都需要先检查一遍订单是否已经做过已付款的操作。

这就是最简单的逻辑了。

def ChineseZodiac(year):
return u'猴鸡狗猪鼠牛虎兔龙蛇马羊'[year%12]

python可以么

看这些变量命名也真是醉了

你们其实误解lz的意思了吧，他可能只是想在猪八戒之类的威客上花3-5k找人做一个网站。

两个做法

1:如果对价格实时性要求较高可以在view里接受页面提交的计价类型，对model里进行查询,页面select时发起ajax请求

2:在view时将两种计费方式都render到页面上,可以存储到隐藏域或者js变量里,然后在select时分别显示这两个值

一般情况下建议第二种，性能好一些。

我的建议是 提升commit频率，认真codereview

以前去看雪都是看逆向工程那一块。

三五个月几百万的没见到，认识的做安全的年入百万的有，但是不是做黑产，正经做点咨询收收保护，不，是咨询费，不用时刻担心自己会进去。

目录式url结构？你是指restful？组合条件查询这块我的经验还是用get加参数吧，在view层把参数收集过滤下，组合一个查询tuple丢给django orm的filter，具体的你可以看看django源码对于搜索这块接受的参数。

对自己好点，有些时候不用强行参照别人的做法。

看起来不错，最近发觉很多初创公司都在尝试用django,tornado或者flask构建web，真是一件值得欣慰的事情。

《python参考手册》 第四版

print websocket.__name__试试呢