Vimer

给大家拜个晚年

Dante — Sun, 29 Jan 2012 23:54:49 +0800

从老家回来第一天，特向各位博友拜个晚年~
祝福大家新年快乐，龙年大吉！
家庭幸福美满，事业蒸蒸日上！
心想事成，万事如意！

关于libcurl不发包的bug定位

Dante — Wed, 11 Jan 2012 10:05:40 +0800

前几天同事的程序有个很奇怪的bug，跟大家分享一下。
描述如下：一个http接口在测试环境下能够正常访问，在外网环境下就会直接超时，并且超时的消耗是建是0ms。
我strace了一下，libcurl在测试环境能正常发包，在外网环境却总是直接返回，连连接都没有尝试建立。

仔细研究了他的代码，发现并没有什么不合理之处，一筹莫展时发现有如下代码：

1 2	curl_easy_setopt(curl, CURLOPT_TIMEOUT_MS, (int)(timeout_sec1000)); curl_easy_setopt(curl, CURLOPT_CONNECTTIMEOUT_MS, (int)(timeout_sec1000));

突然想起之前有文章说curl只支持秒级的超时时间，而我们外网的超时配置的是0.5秒。
把超时时间改成1秒之后，果然一切正常了。

google上搜了一下，在如下链接找到了答案:
http://stackoverflow.com/questions/1856473/why-would-curl-ignore-curlopt-timeout-ms-but-honor-curlopt-timeout

The version of curl I am using (7.15.5) doesn't support CURLOPT_TIMEOUT_MS. According to Greg I need at least 7.16.2.

看了一下外网curl的版本:

user_00@RS_Server_appsupport:~> curl --version
curl 7.15.1 (x86_64-suse-linux) libcurl/7.15.1 OpenSSL/0.9.8a zlib/1.2.3 libidn/0.6.0
Protocols: tftp ftp gopher telnet dict ldap http file https ftps 
Features: IDN IPv6 Largefile NTLM SSL libz

果然是低于7.16.2。

问题到这里算是解决了，但是还有一个很奇怪的地方，就是我们测试环境的curl版本也是7.15.1，但是配置0.5秒用起来却没有任何问题。当然唯一不同的是，外网是64位，测试环境是是32位而已。

$ curl --version
curl 7.15.1 (i686-suse-linux) libcurl/7.15.1 OpenSSL/0.9.8a zlib/1.2.3 libidn/0.6.0
Protocols: tftp ftp gopher telnet dict ldap http file https ftps 
Features: IDN IPv6 Largefile NTLM SSL libz

但是不管怎样，以后在curl中使用小于一秒的超时时，还是多加小心为妙。

最近的一些技术整理(20120109)

Dante — Mon, 09 Jan 2012 20:41:19 +0800

前段时间一直没写博客，昨天更新了一篇，今天突然又来了兴致，那就再更新一篇吧（所以说啊，治疗拖延症最好的方法就是现在开始做）

这篇还是一些技术的整理，主要是用于备忘，大家如果觉得太简单就一笑而过啦~

一. python通过图片内容判断图片类型

前段时间写了一个小站练手，http://xiangshuguo.com，一个支持自由上传的图片小站。

因为要限制上传图片的格式，所以要做文件类型检测，代码如下:

def get_image_type(pd, is_path=True):
    '''
    获取图片的类型，支持传入路径和文件内容
    '''
    if is_path:
        f = file(pd, 'rb')
        data = f.read(10).encode('hex')
    else:
        data = pd.encode('hex')
 
    ftype = None
 
    if data.startswith('ffd8'):
        ftype = 'jpeg'
    if data.startswith('424d'):
        ftype = 'bmp'
    if data.startswith('474946'):
        ftype = 'gif'
    elif data.startswith('89504e470d0a1a0a'):
        ftype = 'png'
 
    return ftype

二. stringstream使用陷阱（1）
我直接举一个例子吧

stringstream ss;
int x;
 
ss << "190";
ss >> x;
 
cout << x;

这个代码是没有问题的，结果会是:

如下的代码:

stringstream ss;
string x;
 
ss << "190";
ss >> x;
 
cout << x;

也是没有问题的，输出也是：

然而这样的代码：

stringstream ss;
string x;
 
ss << "x y z";
ss >> x;
 
cout << x;

输出将会是:

好吧，看了文档才发现，当 stringstream将数据导出到一个字符串变量时，它会用空格分割。
但说实话，同一个操作符，意义却不一样，这真挺让人纠结。。

三. stringstream使用陷阱（2）
如果你习惯了C分割的atoi直接将空字符串转成0，那么用stringstream时，千万不要做这种事情，因为如下代码：

stringstream ss;
int x;
ss << "";
ss >> x;
cout << x;

输出将并不一定是0。

四. MySQL多库表的查询方法
腾讯内部使用MySQL数据库都是分库表的，所以在mysql中想手工查询个数据都会变得非常困难，所以这里放个简单的模板，要用的时候，只要用vim对应生成一下就可以了

SELECT * FROM(
SELECT * FROM db_app_right0.tb_app_right0
UNION
SELECT * FROM db_app_right0.tb_app_right1
)AS t  INTO OUTFILE '/tmp/mx';

五. MySQL安全删除数据的做法
这个其实是来自公司DBA的建议啦，这里分享一下

关于delete，我这里建议你们做任何的delete操作之前先执行如下备份语句：

1 2	CREATE backup.tablename AS SELECT * FROM dbname.tablename WHERE id = 90000; DELETE FROM dbname.tablename WHERE id = 90000;

恢复语句：

1	insert into dbname.tablename select * from backup.tablename;

还有一个习惯, 如果确信自己删的数据只有一条加个 limit 1

OK，就这样

搭建nginx+wordpress调试环境

Dante — Sun, 08 Jan 2012 21:40:47 +0800

几年之前刚玩wordpress的时候，还是用apache+wordpress，而后来虽然自己成了nginx粉，却也只是用来做nginx+python的开发，没有把nginx+php配合起来。这次趁这要搭建wordpress的调试环境，所以重新梳理了一遍。
PS：网上很多盛传的版本，基本都不太准，我这里算是亲身试验了，给大家个准的
PS2：这次就在windows下来搞了，其实在linux也是一样

OK，我们正式开始

一. php安装部署

到php windows下载页面下载zip包，而不是安装包
解压，我是解压到 D:\program\php5
重命名php.ini-production为php.ini
修改php.ini

将如下代码去掉注释来支持mysql

1	extension=php_mysql.dll

将如下代码去掉注释，来指明ext的路径

1	extension_dir = "ext"

二. mysql安装部署

到http://www.mysql.com/downloads/mysql/下载windows版MySQL Community Server
安装，并启动服务（默认是随机启动，否则请 net start mysql）

三. nginx安装部署

到 http://www.nginx.org/下载最新的nginx
解压，我是解压到 D:\program\nginx
可以新建如下三个bat脚本，可以快速的实现nginx在windows下的启动、停止、重载，放在与nginx.exe的统计目录即可

start.bat

1
2
3

%~d0
cd "%~dp0"
start nginx.exe

stop.bat

1
2
3

%~d0
cd "%~dp0"
start nginx.exe -s stop

reloat.bat

1
2
3

%~d0
cd "%~dp0"
start nginx.exe -s reload

四. wordpress安装部署

到 http://cn.wordpress.org/ 下载wordpress最新版
解压，我是解压到D:\www\wp
在 D:\www\wp 目录下新建如下脚本

start.bat

1	D:/program/php5/php-cgi.exe -b 127.0.0.1:1998 -c D:/program/php5/php.ini

1 2	set wscriptObj = CreateObject("Wscript.Shell") wscriptObj.run "start.bat",0

其中，start.bat可以能够启动fastcgi服务，但是会有一个dos窗口。如果用start.vbs的方式启动，就可以隐藏掉dos窗口。

五. 配置nginx

修改nginx.conf，新建server配置如下

server {
    listen       80;
    server_name  wp.qq.com;
 
    root         D:/www/wp;
 
    rewrite /wp-admin$ $scheme://$host$uri/ permanent;
 
    location / {
        fastcgi_pass   127.0.0.1:1998;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
 
    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
            expires max;
            log_not_found off;
    }
}

其中如下两项，你可能和我设置的不一样，自行修改就可以了

1 2	root D:/www/wp; fastcgi_pass 127.0.0.1:1998;

而对于如下的静态化的配置，则一定要配置上，之前就是在这里调试了半天。。

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
        expires max;
        log_not_found off;
}

重启nginx，OK！

OK，访问 127.0.0.1，看下是否出现了wordpress的安装界面？哈哈，搞定！

用Vim(gVim)发腾讯微博-weibo.vim

Dante — Thu, 08 Dec 2011 18:40:56 +0800

前言：

好久没写Vim插件了，这次给Vimer们带来个好福利！-- 用Vim（gVim）发腾讯微博
昨晚折腾了大半夜，总算成功实现！~~ 当然，代价就是今天头痛的厉害……

昨天突发奇想，当我用vim读文档，看代码的时候，如果有一段我觉得特别好，想要分享给大家，有没有快捷点的方式呢？

所以需求也就来了，在Vim里面分享内容~而目前用的最广的，自然是微博~（由于笔者只用腾讯微博，所以只实现了腾讯微博……）

细化一下功能:

分享文章中的一段文字，并支持评论
直接发送微博

如果你读这篇文章比较早，应该还能看到页面右侧的微博里有这条微博：

花了一晚上，终于把用vim发腾讯微博给折腾出来了，明天写博客跟大家分享，敬请期待！ 来自weibo.vim

在正式开始介绍之前，声明一下:

文中所使用的QQ登录的API均为对外公开的API，不存在任何使用保密API的问题
笔者是用 vimer.cn 来申请了 QQ登录，但是access_token在生成之后，笔者不会对这个信息做任何保存，如果有所怀疑，请不要使用。
weibo.vim插件本身不会主动发起任何发送微博的操作

OK，废话不多说，开始介绍吧

一. 环境依赖

python

二. 安装

去 http://www.vim.org/scripts/script.php?script_id=3839 下载 weibo.vim
将 weibo.vim 放在 plugin目录

三. 配置
目前支持的配置如下:

g:weibo_access_token oauth2.0的access_token，是由QQ登录提供的授权token，貌似过期时间是1个月。后面会写出获取这个token的方法。
g:weibo_access_token 签名档，默认值是“来自weibo.vim”，如果不喜欢可以配置为空

在_vimrc中配置:

1	let g:weibo_access_token = '第四步会生成的access_token'

四. 生成access_token

点击如下链接:

生成access_token

在进行QQ登录之后，会跳转到类似如下链接:

http://www.vimer.cn/#access_token=4E6421B8719124324217AF48E085F&expires_in=7776000

其中access_token=后面的即要获取的access_token。

将其配置到第二步的g:weibo_access_token中。

如果在使用中，提示 access_token 过期的话，只要按照上面的步骤重新申请一遍即可。

五. 命令

分享选中的的文字

选中要分享的文字后，按下 “,at”，如果不需要写评论，则直接回车；如果需要评论，则输入空格后，输入评论，回车。

直接发送微博

在normal模式下，直接按下 “,at”，输入空格后，输入文字，回车。

OK，就是这样，enjoy it！

最后再贴一下下载地址:
http://www.vim.org/scripts/script.php?script_id=3839

bottle做web开发的物理设计

Dante — Tue, 06 Dec 2011 00:44:59 +0800

接着回归简单，向Django说再见，继续来聊用bottle做web开发。

其实上一篇文章已经讲的比较清楚了，这一次主要从另一个角度来分享一下：物理设计

干脆直接贴出来吧：

bottle_site_tpl/
|~conf/
|~depend/
| |+autumn/
| |+jinja2/
| |+wtforms/
| |-__init__.py
| `-bottle.py
|~log/
| `-site.log
|~module/
| |-__init__.py
| |-forms.py
| |-models.py
| |-mysession.py
| `-web_func.py
|+static/
|~views/
| `-test.html
|~web/
| |-__init__.py
| `-test.py
|-myapp.py
`-setting.py

可以看出，最外层有两个文件，分别是setting.py 和 myapp.py。
setting.py（很像django吧，哈哈），顾名思义，是各种配置项，包括log目录和等级，模板目录，静态文件目录等。
而myapp.py的代码如下:

import setting
 
from bottle import debug, run
 
from web import app
 
if __name__ == '__main__':
    debug(True)
    run(app, host="0.0.0.0", port=80, reloader=True)

相当于一个启动器，通过执行 python myapp.py 可启动整个网站。（当然，也可以和uwsgi结合）

接着我们进入第二级目录，从web目录开始:
web目录用来存放Bottle的各个实例，构成了网站的主框架。

其中的__init__.py代码如下:

#!/usr/bin/python
# -*- coding: utf-8 -*-
 
from bottle import Bottle
from bottle import debug, run
from bottle import redirect, abort, static_file
from bottle import jinja2_template as template
from bottle import request, response, local
from bottle import TEMPLATE_PATH
 
from mysession import get_session_info, set_session_info
from mysession import deco_session_check
 
from setting import CUSTOM_TPL_PATH
TEMPLATE_PATH.insert(0, CUSTOM_TPL_PATH)
 
app = Bottle()
 
app.mount('/test', __import__('test').app)
 
if __name__ == '__main__':
    debug(True)
    run(app, host="0.0.0.0",reloader=True)

可见 web.__init__.py 是统一管理web相关资源的入口，会mount各个模块，而对于test.py，则是各个模块对应的实现。

depend 目录是存放各个依赖的模块，这样做会更容易管理。
module 是开发中较为独立的模块，比如models.py是模型，forms.py是表单等等
views 是模板目录
static 是静态文件目录
log 是日志目录

OK，整个就是这样了。
按照这样来做了之后，整个模块的划分就清晰了很多，可扩展性也好了很多。
当然，这只是我一家之言，如果有朋友有更好的物理设计，也欢迎告知。

惯例，代码放在这里：
http://code.google.com/p/vimercode/source/browse/#svn%2Ftrunk%2Fbottle_site_tpl

有损服务-不完美主义者的胜利

Dante — Tue, 22 Nov 2011 18:54:03 +0800

前言：这是我最近在公司内部分享的一篇文章，大家反响比较强烈，所以也分享到博客里来。

一转眼，来公司已经三年多了。

这三年里，所属部门在变，地理位置在变，技术也日新月异，但是有很多设计原则却是一直不曾改变的，而这次就是我用自身的实践来谈谈我对其中的一个的理解---有损服务。

记得当年qwang用一个很形象的比喻来解释有损（原话记不太清楚了）：

比如一个人在沙漠里迷失了寻找水源，那么在他还能走的时候，就尽量走；实在走不动了，用爬的；最后爬也爬不了了，起码要保证自己活着。

所以我们从这个比喻中起码可以获得如下几个信息：

问题时，优先保证关键功能
非关键功能不可以影响关键功能
在条件允许的情况下，损失越少越好

接下来就从自己印象比较深刻的有损服务项目讲起吧。

一、空间应用列表有损服务优化

想当年，苍井空还是处女，玛利亚还姓圣母。好吧，扯远了，想当年第一款国民级应用《QQ农场》横空出世，其空前的火爆导致空间个人中心应用列表的农场图标变得如此重要。

然而由于各种网络等各种原因，这个列表的展现总是会有一定的失败率，而且只要稍微失败就会招来大批用户的投诉。

我们分析一下这个模块的功能：

正常功能：正常展示用户已经安装的应用列表
关键功能：正常展示用户最关心的基础应用（如日志）、火爆游戏（农场）等的应用列表

于是优化开始了……

Step1. 应用信息本地cache

由于应用列表第一个要获取的就是应用自身的信息（包括URL，名称等），而这部分数据本身又是较为固定的，所以就直接cache在了webserver本地。一旦当网络拉取应用信息失败时，就会使用本地的存储。

这样做了之后，其实严格来说体验上并没有任何损失，但这才是第一步。

Step2. 忽略过滤已安装应用列表失败

接着我们发现过滤已安装应用列表接口也存在一定的失败，之前采取了简单而粗暴的方式，一旦报错则直接返回。

然而后来我们考虑到，如果这个时候我们返回一个默认应用列表，同时在这个默认列表中加入那些平台基础应用和火爆应用（农场），是不是体验会更好呢？

再然后我们尝试了，确实证明了这样带来的效果更好。对比一下：一个是想玩农场找不到入口；一个是没装过农场，但是看到了农场的应用图标。高下立分。

这是体验的第一次降级，我们尝到了甜头。

Step3. 前台协助

但是我们很快发现，只有上面的方案是不行的。

CGI在调用后端接口时，如果接口超时，很可能会导致CGI超时，而前台JS此时很可能还没有等到CGI的默认应用列表返回就已经向用户报错了。
由于网络问题、webserver异常等原因，CGI没有接收到请求，也会导致默认应用列表获取失败。

所以我们马上联系前台同学优化了两个逻辑：

JS调用CGI的等待超时，与CGI调用后台接口的超时对应
一旦CGI超时返回，则在前台也会存储有一份默认的应用列表，直接展示给用户

在这里，我们把有损的设计从后台延伸到了前台，并再次证明好的设计一定是前后台共同实现的~再次感谢当年鼎力相助的晓晓同学~

Step4. 闭环

然而，有损服务毕竟是对体验有影响的，此时如果不对用户做好提示和限制，就会导致用户使用很多功能报错，反而还会增加投诉的数量。

比如用户如果在有损的情况下去编辑应用列表，或者添加应用都会报错，如果没有限制又没有合适的提示，用户很可能会认为自己数据丢失，招来投诉。

所以我们又做了几件事：

有损时优化对用户的提示，告知数据可能不准确
限制写操作，如编辑，添加应用，都被禁止，并明确提示原因

OK，到了这里，应用列表的整个有损服务优化就基本告一段落了。虽然后来我们优化了server，提高了成功率，但这里的有损逻辑却被永远的保存了下来，毕竟，什么样的系统能完全没有错误呢？

也正因为有这个项目的铺垫，为我后来做OpenAPI设计时的有损奠定了根基。

二、OpenAPI有损服务优化

OpenAPI是平台与应用之间沟通的桥梁，因此对可用性的要求极高，因此当部分功能出现问题时，保证有损服务，也就是必然的事情。

先来简单看一下OpenAPI的架构图吧(这个之前在QCon已经分享，所以不算泄密~)：

当请求进入OpenAPI接口机的时候，接口机会根据参数、URL分别将请求转发到对应的业务CGI，之后再经由接口机返回给调用方。

所以我们再次开始有损优化之旅：

Step1. 业务之间互相屏蔽

从描述可以看出，由于不同业务的CGI都挂载在接口机上，所以一旦某一个业务出现问题时，势必会影响到其他业务。

所以我们对每个业务都分配了单独的L5 ID，当失败量或者超时量太高时，webserver的IP分配就会失败，从而保证业务之间不会受到相互影响。

Step2. CGI运行最长超时设置

刚才提到OpenAPI对性能的要求极高，所以要求CGI都能尽快的返回，否则就会被Step1里面的技术打击到。

但是具体怎么做呢？

我们将有损服务具体化为一个CGI设计原则：

在能容忍的最长时间内，将最重要的事做完

比如下图：

当我们执行到3的时候，发现CGI的运行时间已经太长了（比如超过1秒），那么为了避免其他请求被堵死，我们就直接直接返回给调用方了。

这个时候虽然数据不是完整的（丢了4的数据），但是我们在数据完整和快速响应之间做了一个平衡。

这样就保证了在服务出现问题的时候，大部分的应用还是可以正常使用，只是体验上稍微差一点。

Step3. 智能调整最长超时时间-EMA算法

但是我们很快发现，仅仅做到这里还是不够的，我们刚才提到了能容忍的最长响应时间，但是这个最长响应时间的值怎么指定呢？

如果指定的很长，比如1秒，那么一旦出现问题的时候，相当于每个进程每秒钟只能处理一个请求，根本没有达到我们预期的容灾的效果。

但如果指定的很短，比如20毫秒，那么一旦出现一次偶然的网络波动，即使很快会恢复也会导致我们的OpenAPI大面积失败。

这两种设置方法都不完美，那么还有什么办法呢？

那就是EMA算法，公司之前将预测股票走势的EMA算法引入来预测CGI运行时间的变化，而EMA的一个核心原则就是：

当CGI运行时间越短的时候，给CGI设置的最长超时时间越长；当CGI运行时间越长的时候，给CGI设置的最长超时时间越短。

如下图所示：

可以看出平均响应时间和动态超时时间基本是沿响应时间上限对称的关系，很直观的描述了这两者之间的关系。

所以到此为止，有损服务才能真正的发挥作用。

以上就是我在腾讯这三年里对有损服务的一些理解和实践，希望能对大家有所帮助，也更希望是抛砖引玉，和大家碰撞出更多更好的火花。

回归简单，向Django说再见

Dante — Tue, 15 Nov 2011 20:35:44 +0800

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

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

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

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

对于中型项目来说，Django可以说提供了你需要用到的一切，session，orm，admin等等，只要你按照Django规定的思路来，你会发现开发和维护是如此顺手。
但是如果是小型项目呢？
我可能不需要session，我也不需要数据库，但是我却要为Django那些繁琐的东西配置半天。当我被这些繁琐而无用的东西搞晕的时候，我感觉更像是在搭积木，而不是在创造一个伟大的东西。
而对于大型项目来说，Django默认带的组件又满足不了需求，甚至连架构都可能要被替换，所以Django所自带的很多特性都将无法使用。

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

博友反馈这里没说清楚，我再描述一下:
1. 互联网的数据模型与关系数据模型不匹配。互联网数据更适合NoSQL，所以Admin对关系（外键、关联）的处理就没有任何用处了，而直接展示一个blob字段也并没有比用sql语句直观多少。（BTW，当数据量很大的时候，那种外键的下拉框慢得要死）
2. Django并没有过多的考虑大数据量的问题，只支持了分库，不支持分表，Model的using语法也实在是丑陋。而且分库分表之后，Django的admin完全无法使用。再者在大用户量下 session 等机制都成为瓶颈。

这可是说是Django的定位，也可以说是Django的尴尬，所以必然要有其他框架来弥补这些缺陷。

所以我在很早便开始了尝试:

web框架

web.py，Flask，都用了一下，感觉还是不够简单，而终于，我发现了bottle。
bottle真的是个非常小巧的框架，只有一个文件，3000多行，代码我也基本上都读了一遍。

ORM我选用了简单的autumn，因为并不会用到复杂的关系数据。

模板

模板使用 jinja2，本身贴近django模板的语法，用起来也很熟悉。

form类

form类使用 WTForms。

一切看起来都很美好，似乎该有的功能都有了，但是如果真的如此简单，就不会有文章开头那段话了。
要使他们协作起来是件麻烦的事情，最麻烦的就是unicode的问题。
本着输入的最开始就要转成unicode，输出之前才转成bytes的原则，在使用这些类的时候有一下几点要遵循:

autumn在连接MySQL的时候，一定要用 use_unicode=True，这样从MySQL获取的数据才默认是unicode的

autumn_db.conn.connect(
DATABASE['engine'],
db=DATABASE['db'],
user=DATABASE['user'],
passwd=DATABASE['passwd'],
host=DATABASE['host'],
port=DATABASE['port'],
use_unicode=True
)

使用WTForms的时候，要使用 form = RegForm(obj=request.forms) 的方式（bottle要使用0.10），这样才能form的数据才会默认就是unicode
autumn的Model传入的参数必须是unicode，而仅仅如此还是不行的，由于MySQLdb的bug（我个人认为），要求excute函数传入的values必须是bytes类型，而sqlite3则要求传入unicode，所以我们要改一下autumn的代码，在query.py的190行增加代码：

#Add-Begin by dantezhu in 2011-11-14 12:17:10
    if db.conn.dbtype == 'mysql':
        values = [it.encode('utf8') if isinstance(it, unicode) else it for it in values]
#Add-End

并在connection.py第6行增加如下代码:

1
2
3

#Add-Begin by dantezhu in 2011-12-16 01:56:34
        self.dbtype = dbtype
#Add-End

OK，到此为止大功告成！
所有的组件都是我们可拆卸的，如果网站够简单，可以只有一个bottle；如果网站太复杂，我们可以任意的添加自己需要的模块，而且它们是真正做事的。

这还只是个开始，有新的想法会再和大家分享。

vim(gVim)统计字节、字符数

Dante — Wed, 02 Nov 2011 19:51:50 +0800

前段时间在做文件扫描的时候，有一些关于字节、字符数统计的需求，考虑到有同学也可能用的到，所以整理一下记录在这里。

1.统计当前字符之前的所有字节数

1	command! -nargs=0 CountBytesBack :normal mxvgg"ay`x:echo strlen(@a)<CR>

2.统计当前字符之后的所有字节数

1	command! -nargs=0 CountBytesForward :normal mxv$G"ay`x:echo strlen(@a)<CR>

3.统计当前文件所有字节数

1	command! -nargs=0 CountBytesAll :normal mxggVG"ay`x:echo strlen(@a)<CR>

4.统计当前文件所有字符数

1	command! -nargs=0 CountCharsAll :%s/./&/gn\|noh

5.统计当前文件所有单词数

1	command! -nargs=0 CountWordsAll :%s/\i\+/&/gn\|noh

统计当前字符前、后的字符数，暂时没有比较好的实现，因为vim的s命令都是基于行的，如果有朋友有解决方案，欢迎不吝告知~~多谢~

感谢依云的帮助，vim确实已经帮忙考虑到了这一点，具体方法如下:

选择需要统计的文本
按下 g<C-g>

即会显示需要的统计信息。如果想到对信息进行解析，可以通过:redir命令传到变量中

QCon杭州后记

Dante — Sun, 23 Oct 2011 02:12:25 +0800

这次QCon在杭州举办，有幸作为腾讯开放平台部派出的讲师参加，对外分享了《腾讯开放平台的OpenAPI设计》，演讲的ppt已经由InfoQ在网上公布，文章末尾会贴出下载链接，有兴趣的朋友可以看看。
这几天也有很多思索和感悟，今天就和大家分享一下。

一. 切身的感觉到公司实在是 “做得多，说的少”，外界对腾讯的了解太少
“多做少说”当然好，毕竟是多干实事。但是真的是想象中的那么好吗？
我引用孔子的一个故事：

鲁国之法：鲁人为人臣妾於诸侯，有能赎之者，取其金於府。子贡赎鲁人於诸侯，来而让，不取其金。孔子曰：“赐失之矣。自今以往，鲁人不赎人矣。”取其金，则无损於行；不取其金，则不复赎人矣。

什么意思？就是如果大家都把“多做少说”作为标杆，那么“多做多说”是不是反而会受到鄙视，进而会不会“多做”都收到影响？
所以虽然并非我所能控制，但是后续我也一定会做出努力，让公司对外的分享更开放一些。

二. 技术不在于有多强，而在于是否契合业务
大会上包括ebay，百度，阿里，腾讯都分享了自己的技术经验。对比了一下，其实对于这种海量服务的处理模式都差不多，无非是异步化，分布式，NoSQL等等。
但是不是我们看到这些牛B的技术就忘了那些基础的MySQL，Apache呢？
我看未必，所以QCon在这一点上也权衡的非常好，有人讲mongodb，也有人讲MySQL的36条军规，无所谓谁强谁弱，九节鞭还是流星锤更多的还是看你用在什么场合。

三. 保持好奇心
前面一点说到技术要契合业务，但这并不代表我们就该只关注自己负责业务相关的技术。
一个真正的程序员应该保持好奇心，及时的试用自己关注圈里的新技术，其实本身也是一种乐趣。
比如大会上html5相关的几门课《HTML5打造实时聊天系统》，《HTML5打造视频控制器》等，都是些很好的新技术，虽然目前还没有看到商用化的产品，但是那些顶级的程序员们仍在乐此不疲的探索，不是吗？

四. 语言的受重视程度
java在国内互联网公司的地位的确不容小觑，QCon单独开了几门课来介绍jvm的调优相关，而无论是python还是php或者ruby可都是没有享受到这种待遇。
当然，这也确实和国内这几家大型互联网公司的语言选择有关，包括阿里在内的很多公司都使用java来做后台服务，不过腾讯不太一样，是用C/C++。
所以有朋友如果致力于加入互联网行业的话，语言这门工具还是得选的趁手才行。

五. 程序员的双手也是艺术家的双手
有幸看到 Guillermo Rauch 的分享《HTML5 WebSockets的今天》的同学应该都被其现场行云流水的代码编写所折服（他也是用vi，不过并没怎么定制化，否则一定可以更快，起码加个xml.vim，让标签自动闭合嘛），所以就想到我一直在想的一个问题---程序员的出路是什么？
是不是一定要转型，转管理，转产品，转顾问，转编辑？
我不认为如此，编码是一门艺术，既然是艺术，就是本身可以创作一辈子的东西，何必转行？（当然，这只是针对那些想写代码但是又迷茫的朋友，如果个人兴趣爱好原因自然是遵从内心选择。）
搞音乐的最后就一定要混成文艺部长？不见得吧？

好了，思考的几点就这么多，下面是我分享的ppt，大家有兴趣可以看一下。

开放平台的OpenAPI设计