最常见公司财务术语

January 15, 2013

very useful

  • Share/Bookmark
0

Python: read a file line by line

November 30, 2011

1. Read all lines in together

f = open('myfile.txt')
lines = f.readlines()
f.close()

for line in lines:
print line,

2. Read one line once a time

f = open('myfile.txt')
line = f.readline()
while line:
print line,
line = f.readline()
f.close()

3. Use a file iterator, the most efficient way:

f = open('myfile.txt')
for line in iter(f):
print line,
f.close()

  • Share/Bookmark
1

Sending patches through your GMail account with Git

May 25, 2010

Configuring git send-email to use Gmail SMTP

If you dont have the command git-send-email command then install it using apt-get install git-send-email

Then, add the correct configuration variables with the following:

$ git config –global sendemail.smtpserver smtp.gmail.com
$ git config –global sendemail.smtpserverport 587
$ git config –global sendemail.smtpencryption tls
$ git config –global sendemail.smtpuser your_email@gmail.com

Now it’s ready: the command git send-email patch-name will ask you for some info about the email sender (you can change the From: field) and recipient, your Gmail password and then it will send the email.

Optionally, it is possible to skip the password prompt by adding it to the configuration with:

$ git config –global sendemail.smtppass your_password

Thats it.

  • Share/Bookmark
63

热烈庆祝struggleyb同学通过硕士论文答辩

May 22, 2010

感谢老师,感谢同学,谢谢!

海报

海报


答辩

答辩


决议

决议


合影

合影

  • Share/Bookmark
116

两个你可能不知道的scm命令

April 26, 2010

bisect和blame,两个命令一般都是在出现bug的时候使用。

  • git bisect (hg, svn支持)

    发现本来挺好的程序,合并别人的修改之后,居然出现了bug,这个时候,我们有两种方法去除bug:

    1. 调试最终程序,尝试直接找到问题所在。

      如果是程序崩溃、空指针等这些明显问题,还好办,如果是复杂逻辑问题,那得花费大量时间了…

    2. 在合并来的多个commit中,逐个搜索,找到出引入bug的commit,之后通过commit的修改内容定位bug代码

      这样子,将问题定位到一个commit,可以从commit的修改本身着手,从而能够很大程度上简化bug查找过程

    如何定位来自对方的哪个commit造成了bug?(当然,bug可能在对方的代码中并不存在,是合并后代码共同作用的结果。)如何找出是哪个commit造成的合并结果,也是同样麻烦。
    学计算机的人都知道二分搜索,加快查找速度,git bisect做的正是此事。(注意这个命令的名字,非常贴切: bisect=BInary SEarch CommiT)通过使用bisect start 设置好二分的界限,之后bisect将本地代码的状态滚动到中间的某个commit,之后,我们验证当前代码库是否有bug存在,使用bisect good/bad标志当前commit。bisect接收到指令之后,会继续在剩下的区间进行二分查找。
    这命令我本身也没有使用过,第一见到其描述是在《Beautiful Code》中的一章,之后在git、hg和svn中都发现了类似的东西。感觉在处理较大规模、开发并行度较高、提交比较频繁的项目中,处理bug,可能有用。

  • git blame (hg, svn支持)

    当你明确知道某个bug来自某行代码的时候,想知道这行代码是谁写的,然后找到该人去泄愤一下,blame正是泄愤证据的最有利提供者。blame明确输出,某行代码是某人在某个commit中写的。这命令名字取的非常到位,找到谁是可以blame的人,哈哈

  • Share/Bookmark
64

CGI和FastCGI的性能区别

November 15, 2009

首先介绍一下我机器的配置:

byang@byang-desktop:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.60GHz
stepping        : 9
cpu MHz         : 2600.247
cache size      : 512 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts cid xtpr
bogomips        : 5200.49
clflush size    : 64

我在机器上架设了lighttpd并且配置了CGI和FastCGI支持,然后使用apache的benchmark工具ab分别测试了静态html文件,cgi脚本和fastcgi脚本的吞吐率。测试命令:

byang@byang-desktop:~$ ab -c 50 -n 5000 http://127.0.0.1/test.cgi

Static HTML file:

Server Software:        lighttpd/1.4.19
Server Hostname:        127.0.0.1
Server Port:            80

Document Path:          /
Document Length:        3569 bytes

Concurrency Level:      50
Time taken for tests:   2.070 seconds
Complete requests:      5000
Failed requests:        0
Write errors:           0
Total transferred:      19135000 bytes
HTML transferred:       17845000 bytes
Requests per second:    2415.29 [#/sec] (mean)
Time per request:       20.701 [ms] (mean)
Time per request:       0.414 [ms] (mean, across all concurrent requests)
Transfer rate:          9026.69 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        8   10   1.1     10      19
Processing:     3   10   1.2     10      20
Waiting:        1    6   3.1      5      19
Total:         14   21   1.2     20      28

Percentage of the requests served within a certain time (ms)
  50%     20
  66%     21
  75%     21
  80%     21
  90%     21
  95%     21
  98%     27
  99%     28
 100%     28 (longest request)

CGI:

Server Software:        lighttpd/1.4.19
Server Hostname:        127.0.0.1
Server Port:            80

Document Path:          /test.cgi
Document Length:        22 bytes

Concurrency Level:      50
Time taken for tests:   9.376 seconds
Complete requests:      5000
Failed requests:        0
Write errors:           0
Total transferred:      840000 bytes
HTML transferred:       110000 bytes
Requests per second:    533.29 [#/sec] (mean)
Time per request:       93.758 [ms] (mean)
Time per request:       1.875 [ms] (mean, across all concurrent requests)
Transfer rate:          87.49 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.6      0       9
Processing:    33   94   9.1     93     137
Waiting:       31   93   9.1     93     136
Total:         40   94   9.1     93     137

Percentage of the requests served within a certain time (ms)
  50%     93
  66%     97
  75%    100
  80%    101
  90%    104
  95%    109
  98%    117
  99%    121
 100%    137 (longest request)

FastCGI:

Server Software:        lighttpd/1.4.19
Server Hostname:        127.0.0.1
Server Port:            80

Document Path:          /test.fcgi
Document Length:        731 bytes

Concurrency Level:      50
Time taken for tests:   2.308 seconds
Complete requests:      5000
Failed requests:        0
Write errors:           0
Total transferred:      4385000 bytes
HTML transferred:       3655000 bytes
Requests per second:    2166.07 [#/sec] (mean)
Time per request:       23.083 [ms] (mean)
Time per request:       0.462 [ms] (mean, across all concurrent requests)
Transfer rate:          1855.12 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.6      0      18
Processing:     5   23   4.8     22      46
Waiting:        1   22   5.0     22      46
Total:          9   23   4.6     23      46

Percentage of the requests served within a certain time (ms)
  50%     23
  66%     25
  75%     26
  80%     27
  90%     28
  95%     30
  98%     34
  99%     40
 100%     46 (longest request)

注意看,三种文件的Requests per second的数值

Static HTML:  2415.29 
CGI:             533.29
FastCGI:       2166.07 

可以看到,FastCGI的性能几乎是CGI的4倍。同时,对于一台普通的PC机器,其采用Lighttpd+FastCGI的性能还是相当可观的。

  • Share/Bookmark
72

GPA计算

November 6, 2009
Tags:

找工作时候,很多外企需要学生添写GPA,好不容易找到了一个很好的计算GPA的软件,放在自己blog希望将来谁需要可以直接过来下载

并且,附上自己的GPA,以免将来重复计算:
本科:3.7
硕士:3.6

话说,这两个分数可是用软件“改进GPA4.0算法”计算的来的,咱分数不是特别高的,还是改进算法算出来的GPA看着舒心 ^_^

  • Share/Bookmark
120

%iowait并不能反应磁盘瓶颈

October 27, 2009

iowait实际测量的是cpu时间:
%iowait = (cpu idle time)/(all cpu time)

这个文章说的很明白,高速cpu会造成很高的iowait值,但这并不代表磁盘是系统的瓶颈。唯一能说明磁盘是系统瓶颈的方法,就是很高的read/write时间,一般来说超过20ms,就代表了不太正常的磁盘性能。为什么是20ms呢?一般来说,一次读写就是一次寻到+一次旋转延迟+数据传输的时间。由于,现代硬盘数据传输就是几微秒或者几十微秒的事情,远远小于寻道时间2~20ms和旋转延迟4~8ms,所以只计算这两个时间就差不多了,也就是15~20ms。只要大于20ms,就必须考虑是否交给磁盘读写的次数太多,导致磁盘性能降低了。

作者的文章以AIX系统为例,使用其工具filemon来检测磁盘每次读写平均耗时。在Linux下,可以通过iostat命令还查看磁盘性能。其中的svctm一项,反应了磁盘的负载情况,如果该项大于15ms,并且util%接近100%,那就说明,磁盘现在是整个系统性能的瓶颈了…

  • Share/Bookmark
90

南开大学本科生选课系统,研究生选课系统

October 25, 2009

非常无奈,每次都要搜索才能找到这两个重要的东西,记录在此。
南开大学本科生选课系统: http://222.30.32.10
南开大学研究生选课系统: http://202.113.28.116

  • Share/Bookmark
161

单词选择问题

October 7, 2009

从n个单词中选最大数量的单词(cardinalality of subset of these n words)放到k行中,每行长度为L,但是单词的顺序不能变。知道每个单词的长度l_{i}。 设计一个算法,要求复杂度和L 无关。

乍一看,如果将每行长度L看作背包问题的容量,每个单词的长度看作物品的重量,每个单词的value都是1,貌似排列每一行都是一个背包问题。但是,一个所有物品value都为1的背包问题,已经不再是一个NPC问题了。可以用贪心算法解决,呵呵…而这一点正是,这个题目的关键…
将所有单词按照顺序编号1-n,当计算前k个单词放在一行最多能放多少个的时候,可以通过一个贪心遍历完成:

如果当前行剩余的长度能存放当前单词,则放下;
如果不能,则
     找到当前行最长的单词和当前单词比较,留下较短的

我们可以通过使用最大堆来保存已放在当前行的元素的长度,来加快程序寻找最长单词的过程。有了在O(n*lgn)时间能完成的,放置一行单词的算法之后,我们可以在此基础上,作动态规划,完成这个题目。

dp(k,n) = Max(for every j, 1<j<n){
                         dp(k-1, n-j)+m (m 是j个单词中能放在当前行的数目)
                }

dp产生的子问题数目是n*k个,每个问题的选择数目是n个,所以总体复杂度n*n*k.

  • Share/Bookmark
285