歸檔 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