标签归档:django

RSS feed of django

最后更新于 .

这几年一直想把wordpress换掉,因为明明最讨厌的语言就是php,自己还用php搭的博客。

之前之所以一直不做,也是因为python下的博客一直不成熟。

直到前段时间发现了这个:django-blog-zinnia

支持python3,支持django2,最关键的居然是支持wordpress导入。

当然,实际操作起来才发现坑不少,好在python比较简单,改起来也很快。

折腾了两天总算搞定了,所有数据完美迁移,另外还把很久之前博客改短url导致链接失效的问题给解决了,美滋滋。

这次之所以花了这么久折腾博客,也是因为自己最近二次创业,感受上和第一次创业有了很多不同,所以也是想找时间分享给大家。

既然内容要更新了,门面当然也得跟着装修一下了,哈哈。

今天先写到这,等过几天开始正式写分享。

最后更新于 .

最近在做游戏服务分层的时候,一直想把mysql的访问独立成一个单独的服务DBGate,原因如下:

  1. 请求收拢到DBGate,可以使DBGate变为无状态的,方便横向扩展
  2. 当请求量或者存储量变大时,mysql需要做分库分表,DBGate可以内部直接处理,外界无感知
  3. 通过restful限制对数据请求的形式,仅支持简单的get/post/patch/put 进行增删改查,并不支持复杂查询。这个也是和游戏业务的特性有关,如果网站等需要复杂查询的业务,对此并不适合
  4. DBGate使用多进程模式,方便控制与mysql之间的链接数,进行mysql访问量阀值保护
  5. 方便在DBGate上进行访问量统计,慢查询统计、权限控制等等一系列逻辑
  6. 目前是使用python,以后要使用其他语言进行mysql操作时,只要进行标准的http请求即可,不会出现不兼容的情况

当然坏处也是有的:

  1. 首当其冲就是单次请求的响应时间变长,毕竟中间加了一层服务,并且还是http格式
  2. 部署上比原来复杂了一些,很多对mysql直接操作的思维需要进行转变,一开始可能会有些不适

不过总的来说,还是利大于弊,所以最终还是决定搭建DBGate

当然,我们不可能去手工挨个写每个库表对应的restful服务,值得庆幸的是django和flask都提供了对应的解决方案,我们一个个介绍.

Flask

参考链接: flask-restless

flask-restless使用方法比较简单,我直接贴一下代码即可:

# -*- coding: utf-8 -*-

import datetime
from flask ...

最后更新于 .

测了一下django、flask、bottle、tornado 框架本身最简单的性能。对django的性能完全无语了。

django、flask、bottle 均使用gunicorn+gevent启动,单进程,并且关闭DEBUG,请求均只返回一个字符串ok。

tornado直接自己启动,其他内容一致。

测试软件为 siege,测试os为cenos6 64位,测试命令为:

siege -c 100 -r 100 -b http://127.0.0.1:5000/

django测试结果为:

Transactions:		       10000 hits
Availability:		      100.00 %
Elapsed time:		       18.51 secs
Data transferred:	        0.02 MB
Response time:		        0.18 secs ...

最后更新于 .

这篇文章写的比较晚,主要也是要真正用起来才会发现,django1.4的这次升级在项目目录结构,配置文件上都有比较多的调整,恰好这次也受这样的困扰,所以就拿出来和大家分享一下。

django1.4增加了一个很重要的目录: static,在之前,django的所有静态文件都是放在media目录下的,但是同时用户在后台主动上传的文件也会放到这里,所以会引起一些不必要的混乱.

而且在之前的版本种,django的admin会霸占/media的路径,导致我之前不得不在配置里面强制修改一下:


ADMIN_MEDIA_PREFIX = '/admin_media/'

或者让网站自己的静态文件路径使用的别的前缀:


MEDIA_URL = '/site_media/'

对应的nginx.conf也要做一些相应的配置,对于之前版本相关的内容,这篇文章就不做赘述了,有兴趣的朋友可以去我之前写的博文看一下: linux下nginx+python+fastcgi部署总结(django版),PS:当时还没用uwsgi,大家将就一下。。

回到我们说的django1.4的变更,增加的static目录用来存放网站需要的静态文件,如css,img等,而/media目录用来存放用户上传的文件,admin使用的静态文件是放到/static/admin下。
这样的调整是要比原来合理很多,但同时nginx.conf的配置也需要做响应的变更,如:


server {
listen 80;
server_name test.com ...

最后更新于 .

之前对bottle做过不少的介绍,也写过一些文章来说明bottle的缺点,最近发现其实之前有些地方说的不太公平,所以趁此机会也来更正一下。


  • bottle是支持类似flask url_for的语法的,具体使用方法在下文介绍

  • bottle的request.query之类的参数默认是str类型,也是有原因的,比如我在给google做代理的时候,编码就不一定是utf8的,如果强制转化utf8就会报错

  • 之前的bug也得到了修正,比如mount('/x',app)之后,/x/和/x都可以访问到

OK,现在正式进入主题,我们来介绍一些bottle的一些高级使用


一. 智能创建url

这部分在bottle的文档上是没有介绍的(其实bottle明明实现了很多贴心的功能,不知道为啥都不写在文档上)。
在Bottle类里,有一个成员函数:


def get_url(self, routename, **kargs):
""" Return a string that matches a named route """
scriptname = request.environ.get('SCRIPT_NAME', '').strip('/') + '/'
location = self.router ...

最后更新于 .

我这几天在微博上写了一句话: 回归简单,即便开始反而会变得更加复杂

回想起当年刚用Django写素材管理系统还历历在目,最近却已经逐渐脱离Django了。
成长总是分阶段的吧,勇敢的抛弃一些东西,接纳新的东西,也许就是成长了。

至于原因呢,也是我一直在总结的,大家可以一起看一下。

Django适合做中型项目,但却不适合小型和大型项目
为什么这么说呢?




  • 对于中型项目来说,Django可以说提供了你需要用到的一切,session,orm,admin等等,只要你按照Django规定的思路来,你会发现开发和维护是如此顺手。


  • 但是如果是小型项目呢?
    我可能不需要session,我也不需要数据库,但是我却要为Django那些繁琐的东西配置半天。当我被这些繁琐而无用的东西搞晕的时候,我感觉更像是在搭积木,而不是在创造一个伟大的东西。


  • 而对于大型项目来说,Django默认带的组件又满足不了需求,甚至连架构都可能要被替换,所以Django所自带的很多特性都将无法使用。

    由于工作的关系,在大型项目中,有一类不得不说的服务,那就是SNS应用。
    SNS应用的特点是什么?注册用户量极大,活跃很少。大批的用户蜂拥进入可能只是看一眼就再没回来,但是你的数据却因为这些无用的用户变得庞大无比。进而导致Django默认的那些Model,admin全部都形同虚设,Django的那些所谓的优势荡然无存。

    博友反馈这里没说清楚,我再描述一下:


    1. 互联网的数据模型与关系数据模型不匹配。互联网数据更适合NoSQL,所以Admin对关系(外键、关联)的处理就没有任何用处了,而直接展示一个blob字段也并没有比用sql语句直观多少。(BTW ...

最后更新于 .

之前的文章已经提到了 django+fastcgi的运行并不如意(web.py+spawn-fcgi却正常很多……),所以特意抽时间研究了一下uwsgi,试了一下,运行的很好,也很快,哈哈。 所以笔者的所有之前用apache+django搭建的项目(如fuload等)都已经替换成了nginx+django+uwsgi。 一.安装uwsgi
  1. http://projects.unbit.it/uwsgi/wiki/WikiStart#Getit 下载最新版本的uwsg。
  2. 解压后,如果没有安装libxml2,又不想安装的话,那么编辑文件 buildconf/default.ini, 把
    xml_implementation = libxml2
    
    改成
    xml_implementation = false
    
  3. 执行编译
    python uwsgiconfig.py --build
    
  4. 执行安装
    python setup.py install
    
这样 ...

最后更新于 .

最近因为项目上的需要开始大量使用nginx,因此也想趁机将以前常用的django+apache的架构换成django+nginx+fastcgi,此文是整个搭建的步骤,主要留作备忘,也希望对大家有所帮助。

注意:虽然本文成功的搭建了django运行fastcgi的实例,但是在实际运行中发现了很多问题,比如程序执行异常,进程在每次请求之后退出之类的。可能是我机器的问题,也可能是程序本身bug,大家如果用来搭建外网环境,请务必多多测试。

一.编译nginx

在网上买了一本《实战nginx-取代Apache的高性能服务器》,写的比较浅,主要是些配置方面的东西,不过却正是目前我所需要的。

由于需要支持https和rewrite,所以除了nginx的源码之外,又下载了 openssl-0.9.8r.tar.gz 和 pcre-8.12.tar.gz,把他们和nginx-1.0.4.tar.gz放到同一个目录。

为了方便编译,笔者写了一个脚本,代码如下:

#!/bin/bash

#=============================================================================
#脚本所在绝对目录
abs_path(){
    local path=$1
    local basename=$( basename ...

最后更新于 .

用php有两个月了,说实话用惯了django,再用php开发真的有点郁闷,简单列一下,并非批评,仅为入门的同学少走弯路:
  1. 取不到post的数据 当url为如下形式:
    xx.com/?mod=x&act=y
    
    而method又为post的时候,post的数据会取不到;必须改成如下形式:
    xx.com?mod=x&act=y
    
  2. 字符串连接 这么写代码是会报错滴:
    echo 1."xx";
    
    必须这么写才行:
    echo 1 ."xx";
    
  3. require之后,不知道自己引入了些什么 这个地方,如果和C或者C++来比确实也没啥问题,关键是python的from x import y 的方式实在是让人赏心悦目,所以忍不住抱怨下。
OK,抱怨完了,言归正传。 其实这些问题都还好,仔细点都能解决,最让我不爽的是php的所有框架(不排除我孤陋寡闻,欢迎大家指教)居然都没有提供一个类似于django的form类。 心灰意冷之时,突然想起来之前看到过一个仿django的php框架,虽然整个框架还有很多问题,不过form类这部分应该完成了吧。 pluf:http://www.pluf.org/ 果然不出所料! 看过我之前博文的朋友应该都知道我把CodeIgniter的db访问类单独拆了出来(参见:抽离CodeIgniter的数据库访问类!),没错,这次我又做了同样的事情。 拆分的方法这里就不详细描述了,其实就是SafeString.php这个文件从别的目录拷贝过来,并且定义了一个pluf_form_inc ...

最后更新于 .

fuload的前端页面的展示之前总是不能让我满意,尤其在日期选择控件这里,或者就是和chrome不兼容,或者就是页面乱掉之类的其他问题。 再试用了多个控件未果之后,突然想起来django的后台就有一个很漂亮的时间控件呀。 所以在网上搜了一下,果然已经有朋友尝试过了,链接如下: http://cnmsdn.com/html/201004/1270535813ID3307.html 我们先按照文中的方法一步步做: 现在forms.py中修改:
from django import forms
from comm_def import rtype_original_keys,rtype2attr
from django.contrib.admin import widgets

class SearchReportShowForm(forms.Form):
    reportid = forms.IntegerField(required=True,label='上报ID')
    begintime = forms.DateTimeField(required=True,label='时间',widget=widgets ...