归档 2011

最后更新于 .

前言:

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

昨天突发奇想,当我用vim读文档,看代码的时候,如果有一段我觉得特别好,想要分享给大家,有没有快捷点的方式呢? 所以需求也就来了,在Vim里面分享内容~而目前用的最广的,自然是微博~(由于笔者只用腾讯微博,所以只实现了腾讯微博……)

细化一下功能:

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

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

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

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

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

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

一. 环境依赖

  1. python ...

最后更新于 .

接着回归简单,向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 ...

最后更新于 .

前言:这是我最近在公司内部分享的一篇文章,大家反响比较强烈,所以也分享到博客里来。 一转眼,来公司已经三年多了。 这三年里,所属部门在变,地理位置在变,技术也日新月异,但是有很多设计原则却是一直不曾改变的,而这次就是我用自身的实践来谈谈我对其中的一个的理解---有损服务。 记得当年qwang用一个很形象的比喻来解释有损(原话记不太清楚了): 比如一个人在沙漠里迷失了寻找水源,那么在他还能走的时候,就尽量走;实在走不动了,用爬的;最后爬也爬不了了,起码要保证自己活着。 所以我们从这个比喻中起码可以获得如下几个信息:

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

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

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

想当年,苍井空还是处女,玛利亚还姓圣母。好吧,扯远了,想当年第一款国民级应用《QQ农场》横空出世,其空前的火爆导致空间个人中心应用列表的农场图标变得如此重要。 然而由于各种网络等各种原因,这个列表的展现总是会有一定的失败率,而且只要稍微失败就会招来大批用户的投诉。 我们分析一下这个模块的功能:

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

于是优化开始了……

Step1. 应用信息本地cache

由于应用列表第一个要获取的就是应用自身的信息 ...

最后更新于 .

我这几天在微博上写了一句话: 回归简单,即便开始反而会变得更加复杂。 回想起当年刚用Django写素材管理系统还历历在目,最近却已经逐渐脱离Django了。 成长总是分阶段的吧,勇敢的抛弃一些东西,接纳新的东西,也许就是成长了。 至于原因呢,也是我一直在总结的,大家可以一起看一下。 Django适合做中型项目,但却不适合小型和大型项目 为什么这么说呢?

  • 对于中型项目来说,Django可以说提供了你需要用到的一切,session,orm,admin等等,只要你按照Django规定的思路来,你会发现开发和维护是如此顺手。
  • 但是如果是小型项目呢? 我可能不需要session,我也不需要数据库,但是我却要为Django那些繁琐的东西配置半天。当我被这些繁琐而无用的东西搞晕的时候,我感觉更像是在搭积木,而不是在创造一个伟大的东西。
  • 而对于大型项目来说,Django默认带的组件又满足不了需求,甚至连架构都可能要被替换,所以Django所自带的很多特性都将无法使用。 由于工作的关系,在大型项目中,有一类不得不说的服务,那就是SNS应用。 SNS应用的特点是什么?注册用户量极大,活跃很少。大批的用户蜂拥进入可能只是看一眼就再没回来,但是你的数据却因为这些无用的用户变得庞大无比。进而导致Django默认的那些Model,admin全部都形同虚设,Django的那些所谓的优势荡然无存。 博友反馈这里没说清楚,我再描述一下:
    1. 互联网的数据模型与关系数据模型不匹配。互联网数据更适合NoSQL,所以Admin对关系(外键、关联)的处理就没有任何用处了,而直接展示一个blob字段也并没有比用sql语句直观多少。(BTW ...

最后更新于 .

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

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

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

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

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

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

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

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

command! -nargs=0 CountCharsAll         :%s ...

最后更新于 .

这次QCon在杭州举办,有幸作为腾讯开放平台部派出的讲师参加,对外分享了《腾讯开放平台的OpenAPI设计》,演讲的ppt已经由InfoQ在网上公布,文章末尾会贴出下载链接,有兴趣的朋友可以看看。

这几天也有很多思索和感悟,今天就和大家分享一下。

一. 切身的感觉到公司实在是 “做得多,说的少”,外界对腾讯的了解太少

“多做少说”当然好,毕竟是多干实事。

但是真的是想象中的那么好吗? 我引用孔子的一个故事: 鲁国之法:鲁人为人臣妾於诸侯,有能赎之者,取其金於府。子贡赎鲁人於诸侯,来而让,不取其金。孔子曰:“赐失之矣。自今以往,鲁人不赎人矣。”取其金,则无损於行;不取其金,则不复赎人矣。 什么意思?就是如果大家都把“多做少说”作为标杆,那么“多做多说”是不是反而会受到鄙视,进而会不会“多做”都收到影响? 所以虽然并非我所能控制,但是后续我也一定会做出努力,让公司对外的分享更开放一些。

二. 技术不在于有多强,而在于是否契合业务

大会上包括ebay,百度,阿里,腾讯都分享了自己的技术经验。对比了一下,其实对于这种海量服务的处理模式都差不多,无非是异步化,分布式,NoSQL等等。 但是不是我们看到这些牛B的技术就忘了那些基础的MySQL,Apache呢? 我看未必 ...

最后更新于 .

C++的模板其实是个挺纠结的东西,用的不好的话,编译的一堆错误够你调到崩溃,但要是用的好呢,又确实非常方便,我们来看看

一.获取数组长度

比如

int arr[10];

怎么获取 arr 的长度呢? 最简单的代码:

uint32_t count = sizeof(arr) / sizeof(arr[0]);

但是这样也带来一个问题,万一是个新手程序员:

int *p = arr;
uint32_t count = sizeof(p) / sizeof(p[0]);

就有问题了…… 那么有没有办法,有一种安全的方法,当发现传入的是指针的时候,自动编译报错呢? 有的,模板里面可以推导出数组的长度。 所以我们可以使用如下代码

template <typename T, size_t N> 
size_t arrarysize(T (&array)[N]) { return ...

最后更新于 .

前不久糗百改版,所以原有的qiushibaike.vim插件用起来会有一些问题,今天有时间就修改了一下. 如图:

1

下载地址: http://www.vim.org/scripts/script.php?script_id=3083 有不清楚的朋友可以到 用Vim(gvim)看糗事百科查看说明。

最后更新于 .

用C++越久,越是觉得C++太多陷阱,真是防不胜防。 我们看这样一段代码:

#include <stdio.h>
using namespace std;
class C
{
public:
    C(int a) {
        printf("%d\n", __LINE__);
    }
    virtual ~C() {}
    
};
int main(int argc, char **argv)
{
    C x1(1);
    return 0;
}

编译执行正常,结果是:

7

然后我们改一下,把构造函数变成无参数的:

#include <stdio.h>
using namespace std;
class C
{
public:
    C() {
        printf("%d\n", __LINE__);
    }
    virtual ...

最后更新于 .

各位C、C++开发的朋友们,有没有想过小小的printf也会有陷阱呢?这篇文章,我们就深入来探究一下(代码均在suse10 32位系统下编译测试通过)。 废话不多说,直接上代码:

int64_t a = 1;
printf("%d\n", a); 

结果是多少呢?当然是1,你可能会说。 我们来看一下结果:

1

果然是1!但是你会不会以为是 a 首先被自动转化成了 int 类型,然后输入为 1的呢? 如果真这么简单,本文到此也该结束了。我们换一个写法:

int64_t a = 1;
int b = 2;
printf("%d, %d\n", a, b);

这次的结果是多少呢?1 和 2?真的吗?我们来看一下结果:

1, 0 ...

每月存档

去年

2010

明年

2012