python3自2008发布以来，已经历经了快4个年头。python3发布初期的速度慢，第三方开发库少的问题已得到了很好的改善。似乎已经没有太多的理由死抱着python2不放了。
考虑到目前的大多系统还都跑在python2.x上，直接迁移到python3还是有些冒进。最理想的方式是新代码都可实现python2&python3的兼容，日后可以平滑升级。下面的一些资料可以帮助你实现到python3的迁移。
朋友的VPS服务器近期经常出现内存超标的问题。想我的SAE免费资源闲着也是闲着，于是将上面的博客迁移到SAE平台。
SAE商店中的wordpress可以免费安装使用。受SAE平台的限制，SAE版的wordpress有部分功能限制，比如可用的主题也就那么2~3款。另外一个比较大的问题是无法绑定域名。解决该问题的方法之一即是使用反向代理。
我的虚拟主机上用的是apache，下面是相关设置。
httpd.conf
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule wsgi_module modules/mod_wsgi.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
.htaccess
RewriteEngine On
RewriteCond %{HTTP_HOST} ^domain.com$
RewriteRule ^(.*)$ http://domain.sinaapp.com/$1 [P]
花了些工夫将碎片网部署到了SAE，中途遇到各类问题。感觉SAE看上去很美，实际上却并不是太成熟（至少python版如此）。
下面记录下我遇到的一些主要问题以及解决方法。
Django1.4都即将发布了，SAE平台自带的SAE版本依旧为1.2x。为使用django1.3版本，你需上传自己的django。具体做法可参考SAE手册中的runtime.html#virtualenv
最先遇到的是日至模块的问题。错误显示AdminEmailHandler中构造某个类时带了is_mail这个参数，但目标类的构造函数根本就不支持。好在日至模块不是必须。将日至处理模块换成django.utils.log.NullHandler解决问题。
'null’: { 'level’:'DEBUG’, 'class’:'django.utils.log.NullHandler’, },
在index.wsgi中加入
import threading
from django.utils import _threading_local
threading.local = _threading_local.local
SAE默认安装了不少python包，其中包括django-userena。糟糕的是SAE将django-userena的demo项目也加到了python路径，而且加载的优先级比项目代码还高。直接导致os.environ[‘DJANGO_SETTINGS_MODULE’] = ‘settings’找到的是userena的settings文件。最终将settings文件改名为qnotes_settings.py解决该问题。
受国内的网络环境限制，直接使用python官方的pypi源速度不稳定还经常抽风。对公司来说，搭建一个自己的pypi镜像非常有必要。
| 方案 | 优点 | 缺点 |
|---|---|---|
| PyPiImplementations | 功能强大，提供用户注册、包管理等各项功能。 | 配置复杂，需对pypi源进行全量同步。全量同步速度慢，且经常失败。 |
| PyPiImplementations Simple repository with fallback using Apache | 配置相对简单。可通过ftp等方式实现私有包的管理。增加反向代理缓存后可实现官方pypi源的加速。 | 部分python包只是在pypi上放了一个链接，真正的包放在自己的服务器上（极少数包），对这类包无法通过反向代理进行加速。 权限管理功能稍弱。 私有包需要通过ftp等方式进行管理。 注：私有包管理的问题可通过安装web版的文件管理工具来规避。 |
考虑到部门内部pypi镜像的需求简单，不需涉及太多权限功能方面的工作，建议使用“Simple repository with fallback using Apache”方案。
“Simple repository with fallback using Apache”中只是将本地无法处理的pypi请求直接转发到官方pypi源。在对官方源进行同步时无法实现对官方pypi源进行加速。为解决该问题，需要对官网的请求进行反向代理并缓存。
关于反向代理的支持请参考：代理、反向代理知识普及squid apache-mod_proxy lighttpd nginx
squid是老牌的反向代理服务器，但在实际使用过程中发现squid太过强大的功能导致配置复杂，不推荐使用。
nginx发展迅速的新兴服务器，对反向代理提供良好的支持，并被多家大型网站使用。最重要的是nginx的配置比squid要容易太多。
proxy_cache_path /var/lib/nginx/cache/ levels=1:1:2 inactive=24000h keys_zone=cache:100m;
server {
listen 8000 default;
server_name localhost;
access_log /var/log/nginx/localhost.access.log;
#中间省略部分默认配置
location /pypi {
proxy_pass http://pypi.python.org/simple;
proxy_cache cache;
proxy_cache_valid any 2400h;
}
location /packages {
proxy_pass http://pypi.python.org/packages;
proxy_cache cache;
proxy_cache_valid any 24000h;
}
}
利用twitter/bootstrap，项目的基础模板算是顺利搞定。接下来开始处理用户中心。
用户中心主要包括用户登陆、注册以及头像等个人信息维护。此前，用户的注册管理我一直使用django-registration。只是这个APP有些不思进取，09年发布了0.8alpha版后就一直没什么动静。这次决定尝试另外一个用户模块组件django-userena。
相比django-registration，django-userena的功能要完善的多。除基础的登陆注册模块外django-userena甚至还带了站内消息功能。django-userena的易用性方面也做的非常的不错。django-userena自带了默认模板，并有提供一个完整的演示项目，让你可以轻松上手。这里有个官方的在线demo，感兴趣可以去看看。
我们自然是希望所有的APP不用做任何修改，拿来就能用了。不过事与愿违，在整合的过程中多多少少都会遇到一些问题。django-userena默认的模板在项目中显示的非常难看。我们需要重写django-userena的默认模板，并且用django-bootstrap来生成form。
forms.py
#为原始form添加BootstrapMixin
from bootstrap.forms import BootstrapMixin
class BsAuthenticationForm(AuthenticationForm, BootstrapMixin):
def __init__(self, *args, **kw):
super(BsAuthenticationForm, self).__init__(*args, **kw)
self.__bootstrap__()
urls.py
#重写urls，指定使用的form
from django.conf.urls.defaults import *
from userena import views as userena_views
from profiles.forms import BsSignupForm, BsAuthenticationForm
urlpatterns = patterns('',
url(r'^signup/
同django-admin一样，django-userena也无法使用中文进行注册。对于一个中文网站而言，不能使用中文注册ID似乎有些太不合理的。
django-userena使用正则表达式对用户名进行校验，重写注册form修改认证规则即可取消该限制。
USERNAME_RE = r'^\S+
, userena_views.signup,
{'signup_form': BsSignupForm}, name='userena_signup'),
url(r'^signin/
同django-admin一样，django-userena也无法使用中文进行注册。对于一个中文网站而言，不能使用中文注册ID似乎有些太不合理的。
django-userena使用正则表达式对用户名进行校验，重写注册form修改认证规则即可取消该限制。
USERNAME_RE = r'^\S+$'
attrs_dict = {'class': 'required'}
class BsSignupForm(SignupForm, BootstrapMixin):
username = forms.RegexField(regex=USERNAME_RE,
max_length=30,
widget=forms.TextInput(attrs=attrs_dict),
label=_("Username"),
error_messages={'invalid': _('Username must contain only letters, numbers, dots and underscores.')})
def __init__(self, *args, **kw):
super(BsSignupForm, self).__init__(*args, **kw)
self.__bootstrap__()
django提供syncdb命令，用于从models自动生成数据库。但在models结构变化后，syncdb并无法自动实现数据库的更新。South
组件即是为了解决该问题而出现的。
下面简单介绍一下South的一些最常见用法，更详细的使用方法见South的官方手册。
假设我们创建了一个名叫southtut的app
./manage.py schemamigration southtut --initial |
./manage.py migrate southtut |
./manage.py migrate southtut 0001 --fake |
。
./manage.py schemamigration southtut --auto |
./manage.py migrate southtut |
django在一个项目的目录结构划分方面缺乏必要的规范，因此不同人的项目组织形式也千奇百怪，而且也很难说谁的做法就比较好。我根据自己的项目组织习惯，发布了一个项目dj-scaffold。
前些天在reddit上为我的项目dj-scaffold打了个“广告”（见：http://redd.it/kw5d4）。不想评价甚糟，甚至差点被打成负分。其中更也人将这个项目说的一文不值。面对负面声音虽然会有些不爽，但其中的建设性意见还是需要听取的，至于那些纯属个人偏好部分就自动过滤了。
在谈及settings文件如何组织时，coderanger建议参考The Best (and Worst) of Django中的做法。文中的主要观点是开发环境和生产环境的配置都需要放到VCS中进行版本控制。参考文中的做法，我对settings模块做了部分调整。注：代码 https://github.com/vicalloy/dj-scaffold/tree/master/dj_scaffold/conf/prj/sites/settings
为将项目的默认配置和本地配置区分开，最常用的做法是增加一个local_settings.py文件，并在settings文件的最后对该文件进行import。
try:
from local_settings import *
except:
pass
由此引发的问题是你不能对local_settings.py进行版本控制，部署环境的配置万一丢失将难以找回。
针对该问题，建议的解决方案如下
|~settings/
| |-__init__.py
| |-base.py #默认配置信息
| |-dev.py #开发环境的配置
| |-local.sample #本地的扩展配置在dev和production的最后进行import
| |-pre.sample #设置当前使用的配置为生产环境还是开发环境
| `-production.py #生产环境的配置
DJANGO_SETTINGS_MODULE
django的admin脚本提供了settings参数用于指定当前使用的配置文件
django-admin.py shell --settings=settings.dev
在wsgi脚本中则可直接设置需要使用的settings
deploy.wsgi
os.environ['DJANGO_SETTINGS_MODULE'] = settings.production
简化参数
当然，如果每次使用django-admin.py的时候都要带上settings参数还是非常恼人，所以推荐的做法是在pre.py中配置自己所需要使用的配置文件。
SETTINGS = 'production' #dev
Gliffy是一个在线画流程图的工具，或者简单的说Gliffy就是web版的Visio。Gliffy的用户体验非常的好，加打开浏览器就可以使用，使用起来非常的方便。Gliffy同时推出了confluence的插件版本。在安装插件后可在confluence中方便的编辑和插入流程图。
同事对Gliffy甚为垂涎，只是Gliffy还有些小贵。confluence插件版，500用户的许可要卖到2000$。
虽然同事的利诱有些不靠谱，但偶尔干干着方面的事也还算有趣，那就动手吧。
注：下面只是简单的讲解一些关键点，如果你对java一窍不通，那还是罢手吧。
java应用破解的通常做法是：将文件反编译，找到认证部分的处理，直接将认证结果返回true。java的反编译工具推荐Java Decompiler。
Gliffy的jar包比较大，但其中java代码并不是很多。而且Gliffy采用的是仿君子不防小人的做法，里面的java代码并未混淆过。在代码中有个目录非常的扎眼\src\com\gliffy\core\license\。再做些简单的分析我们即可找到真正的关键点SimpleLicenseManager.java。
不得不说Gliffy的命名还是非常规范的。以函数名为线索，很容易就可以找到我们要的函数validLicenseValues。简单粗暴的将函数返回值改为true。打包并重新安装插件。
如果问题就这么解决了，那也未免顺利的有些不太寻常。虽然可以成功安装，但运行的时候抛出一堆的异常。试着进入Gliffy的管理界面，依旧是一堆的异常。虽然我们强制的将认证结果设置为了true，但某些地方还需要获取license的到期日期等信息。由于读不到相关数据，直接出异常了。
既然如此，那我们需要先将license信息写入系统。
把validLicenseValues还原，然后找到设置license的函数installLicense。在函数中注释掉license认证相关的代码，让系统在忽略认证结果的情况下强行写入注册信息。修改后的java文件在执行时还会报getHostedStatus的虚函数错误。按理说这个函数应当会在子类中被重写。不过我们先不管这么多，把它修改为普通函数并直接返回0。
重新打包安装，然后进入Gliffy的管理界面，license信息随便填写，然后保存。保存是成功的，但认证还是失败。修改validLicenseValues函数，重新打包安装。这次由于我们有写入注册信息，因此就不会再出现先前的空指针异常了。
享受Gliffy吧。
注：Gliffy确实是个好东西，如果喜欢，还是尽量说服公司出钱买吧。
由于Django没有象rails一样指定项目的目录结构规范，很多人都对django项目的目录结构要如何组织而感到困惑。为此我又新创建了一个开源项目dj-scaffold（django的脚手架）。这个项目用于自动生成一个标注化的django项目和app。
项目地址：https://github.com/vicalloy/dj-scaffold
已经发布到了pypi，所以你可以用pip或easy_install 来进行安装。
pip install dj-scaffold
easy_install dj-scaffold
dj-scaffold主要提供了两个命令，dj-scaffold.py和lbstartapp。
该脚本用于取代django的startproject命令。使用方式如下：
dj-scaffold.py projectname
在该命令执行后，将创建项目projectname。在项目的scripts目录中提供了脚本create_env.py和env.rc。
项目对应的目录结构如下：
注：文件太多，去掉了部分不重要的文件
dj-scaffold.py projectname
|+docs/ #用于存放项目的相关文档
|+env/ #python虚拟环境，由脚本自动生成
|~requirements/ #第三方依赖包的存放位置
| `-requirements.pip #pip的依赖说明文件
|~scripts/ #系统相关的脚本
| |-create_env.py #创建python虚拟环境（env目录）
| `-env.rc #进入python虚拟环境。同时提供python manger.py的快捷方式$mg。可在任意目录使用$mg。
|~sites/ #Django的项目文件。在settings文件中增加了部分默认配置。如数据库默认使用sqlite，设置项目的模板以及静态文件目录。
| |+media/ #项目静态文件（用户上传）
| |+static/ #项目静态文件（css、js等）
| `+templates/ #项目模板
|+tools/ #一些项目依赖的第三方工具包。如python虚拟环境初始化脚本等。
`~wsgi/ #项目部署用的wsgi文件
`-dj_scaffold.wsgi
lbstartapp作为django的扩展命令提供。将dj_scaffold加到INSTALLED_APPS后即可使用该命令。该命令将生成一个标准的app，相比django自带的startapp，lbstartapp将那些不太常用的app默认目录也都给生成了出来。对应目录结构如下：
|+management/ #命令目录
|+static/ #静态文件目录
|+templates/ #模板目录
|+templatetags/ #tag目录
|-__init__.py
|-admin.py #admin管理后台的models配置文件
|-forms.py
|-models.py
|-settings.py #app自己的settings文件
|-tests.py
|-urls.py #urls配置文件
`-views.py
最初想将haoluobo.com的域名做其他用途，于是创建了子域名vik.haoluobo.com，并将博客挂在blog目录。最终haoluobo.com的域名一直被空了下来。最近想域名空着也是浪费，干脆将博客和知识库切换到haoluobo.com下。
切换后
博客地址为：http://haoluobo.com
知识库地址：/trac/
这时候问题来了。切换域名后，此前老域名上的所有链接都失效了。为了保证原有地址依然有效，我利用mod_rewrite将老地址的链接都转发到新地址。
博客的老地址：/
在 http://vik.haoluobo.com/ apache的静态文件目录www下创建目录blog，并在改目录下添加.htaccess文件
RewriteEngine On
RewriteRule (.*) /$1 [R=301]
知识库的处理类似，
知识库的老地址：http://vik.haoluobo.com/trac/
在www目录下创建trac目录，并在改目录下添加.htaccess文件
RewriteEngine On
RewriteRule (.*) /trac/$1 [R=301]
注：在http协议中，状态码301标示永久重定向，这样搜索引擎就知道你的老地址今后就不用了。