这是程序自动创建的分类。

Thinkpad X200拆机及清灰

[| 不指定 2012/05/05 15:59]
    又到夏天了,电脑底面的温度直线上升,准备清一下灰尘,之前清过一次,用清洁气吹了下,但没有合适的工具,拧不开风扇,只能从散热器外侧向内侧吹,效果不好,吹过一次后还变响了,这次有了全套螺丝刀,准备彻底清洁一下。

   底面的螺丝很顺利,很快都拧开了,取下键盘和掌托,然后把屏幕的螺丝拧开,把屏幕下的u型塑料拿下来,开始准备拆主板,主板弄不下来,被无线网卡压住了,于是就开始拆无线网卡,结果悲剧发生了,拧下第一个螺丝后,第二个螺丝拧了几下没拧下来,因为选的十字螺丝刀头的尺寸大了点,又拧了几下,结果拧花了,鸭梨很大,搞了半天搞不下来,只能先将旁边的声卡/sd模块拆下来,腾出地方,捣鼓了半天搞不定,于是决定先搞个小刀把螺丝划出一个沟再拧,找不到小刀,去小区门口5角钱买了个,回来发现螺丝拧起来跟豆腐一样,用小刀划起来还挺硬,把小刀刀头都划平了,勉强在右边划了一个小沟,左边划了几个痕迹,螺丝刀还是吃不上力气,到了吃饭的日子,于是先吃了饭,吃完饭想起来指甲刀,指甲刀一般比较厉害,用指甲刀剪了几下左边,果然剪出一个凹槽,还是不好用力,但指甲刀也无能为力了,蛋疼,期间还试过用核桃夹夹住螺丝刀拧、用螺丝刀顶着侧边的凹槽用核桃夹敲等方法,都纹丝不动。搞了很久耐心快到极限了,之前屏幕还和主板上的无线网卡有信号线连接,现在把信号线拔掉,屏幕取下,然后换了一个稍小一点的一字螺丝刀大力拧了几下,期待奇迹的发生,结果发现螺丝真的动了。赶紧又拧了几下,终于拧下来了。

    主板取下后直接就开始拆散热器了,发现cpu上的三个大螺丝是用弹簧压的,估计防止力度过大把cpu压坏,之前以为铜散热器下有空间,里面是很多灰尘,结果拆下来后发现铜散热器直接是整个和cpu/gpu接触的,没有缝隙,cpu上是导热硅脂,gpu上是导热海绵(不知道是不是这么叫,不过样子挺像),由于手头没有新的,所以不能重涂了,怕灰尘进去,急忙又把散热器拧上了。
    然后拧风扇和散热器之间的三个螺丝,上次就是在拧三个螺丝中的一个的时候拧不下来放弃的,这次有了合适的螺丝刀,很快拧下来了,把风扇和散热器分离后,散热器内侧的景象展现在眼前,怪不得之前吹的没效果,原来散热器和风扇之间的那个界面上覆盖了一层黑乎乎毛毛的东西,把散热器的缝隙塞住了一半,急忙把脏东西清理出来,用清洁气吹了一下,干净了。

    然后开始拧螺丝,比较顺利,无线网卡右侧那个螺丝用旁边预留槽的螺丝替换了,发现那个位置的四个螺丝都跟豆腐一样,稍微一拧就花了,别的地方都还好,看来thinkpad也开始偷工减料了,我的还是08年的tp,现在出的估计更没法用了。

    拧好后用鲁大师看了看,貌似效果不错,不过压力压一会后还是比较烫,但平时使用时底座温度降下来了,爽。


Tags: ,
    现在主流搜索引擎都支持ping功能了,每当网站更新时可以主动向搜索引擎发一个xml格式信息,称之为”ping“,通知搜索引擎来抓取,对于收录是非常有好处的。
    之前一直懒得搞,今天弄了一下。
    参照百度站长工具里提供的格式,搞了一个,试试是否好用呢。

    添加了baidu和google的ping地址:

    http://ping.baidu.com/ping/RPC2
    http://blogsearch.google.com/ping/RPC2
Tags:
    今天用nginx作为trac的反代,发现一个问题,就是登入登出跳转的时候是白页,看了下网页相应内容,发现相应的location是空的。查了一下发现是只单纯用了proxy_pass,没有使用proxy_redirect.
    假设前端url是example.com。后端server域名是in.com,那么后端server在返回refresh或location的时候,host为in.com,显然这个信息直接返回给客户端是不行的,需要nginx做转换,这时可以设置:
    proxy_redirect http://in.com  /
    nginx会将host及port部分替换成自身的server_name及listen port。不过这种配置对server_name有多个值的情况下支持不好。
我们可以用nginx内部变量来解决这一问题:
    proxy_redirect http://in.com http://$host:$server_port


    搞定

    如果不设定的话,proxy_redirect默认是default属性,官网例子是这样介绍default的:
引用
location /one/ {
  proxy_pass       http://upstream:port/two/;
  proxy_redirect   default;
}

location /one/ {
  proxy_pass       http://upstream:port/two/;
  proxy_redirect   http://upstream:port/two/   /one/;
}


  
    我试了下,location /{}规则时似乎不太正常,会导致location为空。这个有待详细考证
之前安装了redmine,确实功能多、使用简单,但ror架构实在是吃内存,小vps根本hold不住,于是还是选用python写的trac。丰富的插件使trac只要配置得当,功能还是很强大的。

首先安装setuptools。这个可以用apt或yum安装,也是一个类似于apt的包管理器,是针对python的。安装后可使用easy_install命令
然后配置PYTHONPATH,使用easy_install默认是安装到系统路径下的。需要root权限。不推荐使用这种方式,这样会把文件放到用户不可控的位置,为以后的升级备份带来困难。所以就需要--install-dir参数(使用--prefix参数无效,不知为何),但单纯使用该参数会报指定目录不在PYTHONPATH里。这是easy_install会推荐去看一个网页,我看了下,讲的几个方法都很繁琐,也没什么理由。其实只需要export PYTHONPATH=${PYTHONPATH}:your_dir即可。在.bash_profile里设置一下,避免每次都要手动。
这里建议在.bash_profile里设置一下alias easy_install='easy_install --install-dir=your_dir',这样就不用每次安装时都手动输入一大坨地址了。
设置完后source .bash_profile生效一下。
然后开始安装,先执行:easy_install Babel==0.9.5   这个一定要装,否则安装后的trac没有中文。
然后easy_install Trac
ok,trac的安装就完成了。

现在需要建立项目,trac需要为每个项目建立一个实例。这时在your_dir里找到trac-admin,这个是用来管理项目实例的工具。
运行:trac-admin your_proj_dir initenv
会提示项目名和使用的数据源。
在数据源那里我使用官方推荐的:mysql://name:password@localhost:3306/test报错:trac TypeError: unsupported operand type(s) for /: 'int' and 'NoneType'   看了下代码,是数据库没有配成utf8字符集导致的。配了一下,ok了
建立数据库时要使用:CREATE DATABASE IF NOT EXISTS test default charset utf8 COLLATE utf8_general_ci;
建好项目后就可以登陆进行进一步设置了。
首先配置用户具有admin权限:
trac-admin your_proj_dir permission add user TRAC_ADMIN
然后指定使用web auth进行用户验证:
./tracd --port 8000 --auth="*,/your_dir/user.htdigest,trac" /your_dir
user.htdigest文件是用户名密码文件,需要自己生成,比较麻烦,反正也是临时使用,这里贴个成品:

user:trac:fb05f80adf782a74f48a5acdc71dba65
这个的文件名和密码分别是“user”,“password”
启动后进入控制台
进入管理,插件,开启TracAccountManager 0.3.2
修改trac.ini,
[components]下添加trac.web.auth.loginmodule = disabled
然后在account配置里SessionStore选一个1,(为啥不知道),但不开这个就不能注册
然后手动添加管理员账户
然后可以用./tracd --port 8000  /your_dir   启动了。
用permission add给刚才添加的用户加上管理员权限。然后ok了。可以使用web登陆了

然后添加git支持:
easy_install http://github.com/hvr/trac-git-plugin/tarball/master
暂时没找到支持远程git的方法

Tags: ,
    前几天把一个函数的返回值由int改为size_t了。当时心想就是改个类型的问题,逻辑没啥要动的。反正都是算数。
编译器什么也没报。似乎没什么问题。
    后来凑巧又改了一下另外一个程序的相同函数,结果编译的时候报了error,说试图转换-1到unsigned。一检查,果然程序中的异常分支返回了-1.急忙改了过来。
    所以在返回值是size_t类型的函数中,异常处理要注意。(主要是c程序,因为没有异常)
Tags:

为nginx生成自签名ssl证书

[| 不指定 2012/03/03 00:00]
    今天要搭一个ssl加密的站点,由于是自用,所以就准备自签发一张证书。之前搞过几次,比较复杂,早忘光了。找到一篇不错的文章,留下备份。
http://blog.duyao.de/posts/to-generate-an-ssl-certificate-for-nginx-in-linux.html

这里说下Linux 系统怎么通过openssl命令生成 证书。

首先执行如下命令生成一个key

openssl genrsa -des3 -out ssl.key 1024
然后他会要求你输入这个key文件的密码。不推荐输入。因为以后要给nginx使用。每次reload nginx配置时候都要你验证这个PAM密码的。

由于生成时候必须输入密码。你可以输入后 再删掉。

mv ssl.key xxx.key
openssl rsa -in xxx.key -out ssl.key
rm xxx.key
然后根据这个key文件生成证书请求文件

openssl req -new -key ssl.key -out ssl.csr
以上命令生成时候要填很多东西 一个个看着写吧(可以随便,毕竟这是自己生成的证书)

最后根据这2个文件生成crt证书文件

openssl x509 -req -days 365 -in ssl.csr -signkey ssl.key -out ssl.crt
这里365是证书有效期 推荐3650哈哈。这个大家随意。最后使用到的文件是key和crt文件。

如果需要用pfx 可以用以下命令生成

openssl pkcs12 -export -inkey ssl.key -in ssl.crt -out ssl.pfx
在需要使用证书的nginx配置文件的server节点里加入以下配置就可以了。

ssl on;
ssl_certificate /home/ssl.crt;
ssl_certificate_key /home/ssl.key;
ssl_session_timeout 5m;
ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;
然后重启nginx就大功告成了
Tags: ,

strncpy和snprintf

[| 不指定 2012/02/29 19:06]
    之前用strncpy总是感觉比较恶,老是要考虑最后\0的问题,今天仔细看了下,发现如果源串长度大于等于最大长度的话,strncpy会直接拷贝最大长度,不在后面加\0,也就是说在用一个字符串覆盖另一个字符串一部分的时候用strncpy是很不错的,但全覆盖的话比较麻烦,很容易出bug。
    而snprintf会拷贝最大长度-1的字符数,并在后面加\0,使用一个字符串覆盖另一个时很不错。
    看了一下资料,发现snprintf的效率也要高于strncpy。
    日常字符串拷贝还是推荐snprintf。
Tags: ,

Soso Spider 不支持base属性

[| 不指定 2011/10/27 19:17]
    今天博客新迁移,由于对静态化url的改动非常大,难免有遗漏的地方,所以非常关注access日志,看看爬虫们遇到了哪些困扰。

    在看日志的时候发现一个有意思的现象,google和百度的蜘蛛今天很不活跃,对于站点的大规模改变似乎并不感兴趣,对css,js不屑一顾,而soso的spider非常活跃,把每个链接都详细爬了一遍,但发现一个问题:

     新博客的url是采用base设置+相对url的模式,soso的spider似乎并不识别base标签,直接把相对url附加到当前url之后进行抓取,导致了很多404请求。查了一下,base属性是html标准属性,soso不支持这个属性应该算是个bug了。




Tags: , , ,

HTTP请求返回码204

[| 不指定 2011/10/27 18:49]
    今天测试lighttpd是否支持delete请求,发现webdav模块可以实现此功能。不过发现http返回码是204,查了一下,原来此状态码的意思是说请求成功了,但是没有结果返回来。搜到鸟哥一篇文章,讲的很不错,转载一下:


http://www.laruence.com/2011/01/20/1844.html

之前和人讨论过这个问题,,, 今天感冒在家休息, 就回忆了一下, 整理如下.

我们很多的应用在使用Ajax的时候, 大多数情况都是询问型操作, 比如提交数据, 则Ajax只是期待服务器返回:

{status: 0, message:""} //status 0代表成功, 非零的时候, message中包含出错信息.
我们知道HTTP的状态码, 2xx都是表示成功, 而HTTP的204(No Content)响应, 就表示执行成功, 但是没有数据, 浏览器不用刷新页面.也不用导向新的页面.

在HTTP RFC 2616中关于204的描述如下:

引用
If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent’s active view.


类似的还有205 Reset Content, 表示执行成功, 重置页面(Form表单).

引用
The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action.


于是, 当有一些服务, 只是返回成功与否的时候, 可以尝试使用HTTP的状态码来作为返回信息, 而省掉多余的数据传输, 比如REST中的DELETE和如上所述的查询式Ajax请求.

最后说说205, 205的意思是在接受了浏览器POST请求以后处理成功以后, 告诉浏览器, 执行成功了, 请清空用户填写的Form表单, 方便用户再次填写,

总的来说, 204适合多次对一个Item进行更新, 而205则适合多次提交一个系列的Item.

但, 请注意, 目前还没有一个浏览器支持205, 大部分的浏览器, 都会把205当做204或者200同样对待.
Tags: , , , ,
最近又看了几个vps,总感觉为啥相同配置,相同线路,人家跑wp,我跑自制小博客。人家都比我快得多。

之前一直想当然,认为是网络问题之类的。由于今天考虑到了博客迁移,所以这个问题就提上日程了。于是打开chrome调试工具,看了下时间。

一看不要紧,终于找到瓶颈了。。

首先是jquery.js,最早用本机,后来嫌大,用了google提供的,由于最近和谐,google的连接速度非常慢,导致页面一直卡在下载jquery.js上。
由于是静态文件,比较大的体积,且seo无关,这就需要考虑把文件放在一个网络连接比较快的地方,显然放到国内是值得考虑的。
首先试了一下一款云存储产品,发现速度倒是很快,但是无法开启gzip,这个无法忍受。转而考虑比较专业的web托管,一想,sae就是专门干这个的,直接放到sae上最好。于是在sae上申请了个应用,吧jquery.js和几个比较大的图片移过去了。立竿见影,速度提升极大。

再看,发现google的统计代码加载也很慢,反正我也不怎么看google的统计,注释掉。

再访问,飞一般的速度~~~~~~
分页: 1/23 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]