B面的人生
磁带的B面,有着另一种人生的响起-
该插件没有有效的标题
Posted on 四月 13th, 2012 No comments经常会出现这样一条提示
插件 已被禁用,因为发生了错误:该插件没有有效的标题。
The plugin has been deactivated due to an error: The plugin does not have a valid header.之前在网上查了好久,也没有相关的信息,今天心血来潮,决定彻底解决这个问题,先查了一下网上的信息,尝试了都没有用,既不是目录嵌套,也不是文件损坏。跑到数据库里面查看了一下,wp-options表里面的active_plugins有一条数据i:0;N;非常的奇怪这条数据是怎么来的。
于是我清空数据库里面的信息,刷新页面一切都是OK。但是重新访问plugins页面依然会出错。数据库里面的数据会变成a:1:{i:0;N;},搞不清楚到底是怎么来的。
没有办法,只好调代码了,在plugin.php和functions.php中纠结跳转了很久以后,我发现数据肯定是update_option里面,于是决定在里面把堆栈给打印出来看到底是谁在调用这个函数更新数据库,结果发现是主题tango里面的custom.php被wordpress当做插件。但是custom.php里面并没有作为一个插件所需要的header信息,由于这个文件并不属于插件系统,所以虽然我清空了信息,但每次程序重新执行就会更新数据库,于是就一直会出现这些信息。
个人实在是太懒了,决定换一个主题,这样就避免这个问题了。debug_print_backtrace是个好函数,不能用调试器的时候,这个函数帮助很大
-
关于产品的随想
Posted on 四月 13th, 2012 No comments其实这个吐槽还是用e72的时候的产生的
虽然说E72已经跟不上潮流了,但还是有一些应用了,好像是QQ通讯录,总之是腾讯的一款应用,那天很想提一些意见和反馈bug,点击反馈意见以后跳出了自带浏览器,用的浏览器也就算了,还要输入QQ和密码才能进入意见表单,考虑到我那个复杂的QQ密码,我当场就咔嚓了页面。不过后来想了一下还是重新打开了页面登录进去,但那个意见反馈的表单实在设计有问题,好像只有一行,我很憋屈的输出了一堆内容以后还是忍不住骂人了,实在想不通这样的反馈是要给用户造成了多大的门槛?很多软件的反馈直接坐在软件内,只需要用户填写内容就可以提交上去,这样不是更加简单方便
如此看来,简单,确实是非常的重要,产品上的简洁是一种引导,很多软件和网站的简单使得其反而成功了,这样的例子不可胜数,简单的如豆瓣,v2ex,总是让人津津乐道。复杂的功能往往让用户产生了困惑,迷糊了目的,对于产品经理本身来说也消耗了大量的精力和时间来调控掌握,复杂的东西总是容易让人犯迷糊,就像大公司需要更多的注重管理。技术上的简洁,想必大家都不会怀疑了,不管是接口还是代码,或者说文档,我们关注的还是我们的目的,简洁扼要的达成目的应该是我们所想做的。
从获取用户反馈的角度来说,腾讯的反馈页面就直接给用户制造了很高的门槛,会挡住多少信息进去?!产品经理为了获取用户的反馈需要做出很多努力,而这样的反馈页面却是阻止用户反馈。其实说起来,QQ通讯录的软件本身还是不错的,腾讯产品的用户体验在国内也是一流了,但也还是会遇到各种问题,对于用户反馈制造如此之高的门槛,我实在是想不通产品是如何考虑的,即便这个功能如此细枝末节,也还是让人觉得很受不了。技术做了这些年,越发产品比技术更为重要,技术只是工具,产品决定了刀子该怎么弄。从上面的角度来考虑,也是复杂了导致功能难以管理到位。
想起很久以前一次对 @livid 的抱怨,那是我在e72用uc上v2ex时没有显示针对手机优化的页面, @livid 很主动的问我ua是什么,当时我很不然的说ua应该网上都有,在那时我的想法恐怕是这些应该是@livid应该去搜集处理的,现在想来,对于v2ex这样一个个人站点来说,并没有义务去非如此不可,而且也很难面面俱到,而且 @livid 也很客气的询问我的ua了,我那样的态度不管怎样都是不对的,虽然我事后总觉得有些不太好,现在想起来总觉得那时的态度真是很恶劣,在这里给 @livid说一声对不起了。
-
SecureCRT配置文件转putty
Posted on 十一月 26th, 2010 No commentsSecureCRT挺好用的,但是需要配置,今年过来工作觉得配置起来挺麻烦的,又觉得减少使用盗版是我的责任,于是就开始用Putty这个小巧方便的工具,但是同事都使用的是SecureCRT,主管共享了一份所有机器的SecureCrt的配置,我却由于使用Putty而无法使用……
心里很不爽,于是用Python写了一个脚本转换SecureCrt的配置文件为Putty的配置文件,Putty建议使用Puttycn这个项目,配置文件也可以绿色化,http://code.google.com/p/puttycn/
二话不说,上脚本:
注意Putty的配置文件使用的是\n为换行符,\r\n会导致Putty出错,而Python会根据操作系统写,哪怕指定了\n为换行符也没办法:(
建议使用Cygwin来跑这个脚本就不会有什么问题了,另外Putty的配置文件名好像也不能有非ASCII码
1234567891011121314151617181920212223242526272829303132333435363738394041#!/bin/env python# -*- coding: utf-8 -*-#notice: putty的配置文件要求是lf结尾的,因此不能直接在win下面用import os#此处使用一个配置好的为模板,只需要替换ip即可使用san = open("D:\green\putty\sessions\san")data = []i = 0for line in san:data.append(line.strip())#print data#得到文件列表for root, dirs, files in os.walk('D:\machine'):printfor item in files:print itempath = 'D:\\machine\\' + item;f = open(path);ip = "";for line in f:td = line.split('=');if line.find("Hostname") != -1:#get ipip = td[1].strip();print iptpath = "xen-" + item.split('.')[0].split('xen-')[1]#replace iptp = "D:\\green\\putty\\sessions\\" + tpath#new configure filenewfile = open(tp, "w");for lt in data:if lt.find('HostName') != -1:lt = "HostName\\" + ip + "\\"newfile.write(lt + '\n')newfile.close(); -
PHP5中的unicode_encode
Posted on 七月 31st, 2009 1 comment最近写的一个脚本涉及到了unicode的编码,但是PHP6之前的PHP都没有原生的支持,因此只能自己手写了。网上找了很多这个函数,但是版本都一样,无非是抄来抄去的。抄也就罢了,问题是这段代码还有一个比较严重的bug:对于某些汉字来说,这个函数的编码会出问题,比如“不”的编码为%u4E0D,这个函数出来的是%u4ed,原因就在于后面那个的字节的数据为d,导致转换后生成的不完全……其实只要加一个判断条件就OK了
附上完美的unicode_encode函数
1234567891011121314151617181920212223242526272829303132333435/*** @description 返回字符串的unicode编码* @param string $str* @return string encoding*/function unicode_encode($str){$str =iconv('UTF-8', 'UCS-2', $str);$len = strlen($str);$newstr = '';for($i = 0; $i < $len - 1; $i = $i + 2){$c = $str[$i];$c2 = $str[$i+1];if (ord($c) > 0){//tow byte$s = base_convert(ord($c), 10, 16);if(hexdec($s) > 0xF)$newstr .='%u'.$s;else$newstr .='%u'.'0'.$s;$s = base_convert(ord($c2), 10, 16);if(hexdec($s) > 0xF)$newstr .=$s;else$newstr .='0'.$s;}else{$newstr .= $c2;}}return $newstr;} -
wordpress插件中向javascript文件传递参数
Posted on 六月 22nd, 2009 No comments在WordPress digg comment插件的javascript文件中需要一些用户在后台设置的参数,但是出于简化的目的我把js文件分离成了一个单独的文件,这样的话对js文件传递参数就成了一个头疼的问题。一直以来我使用一个很笨的方法,将要使用到的值直接写到html文件的head中,直到前一阵子看到了wp_localize_script函数,才发现有这么一个简单的方法可以帮助我们方便的传递参数。函数原型为:
1wp_localize_script( $handle, $object_name, $l10n )handle就来自于wp_enqueue_script或者wp_register_script注册脚本的时候的名字,参考我的前一篇日志《WordPress插件中加载javascript和css文件》。$object在实际过程中如下使用即可:
1234567wp_register_script('digg_script', $url, array('jquery'), '1.0', TRUE);wp_enqueue_script('digg_script');wp_localize_script('digg_script', 'WPDiggComment', array('cmt_digg_vote_up' => get_option('cmt_digg_vote_up'),'cmt_digg_vote_down' => get_option('cmt_digg_vote_down'),'siteurl' => get_option('siteurl')));在js文件中使用如下方法获取值:
123cmt_digg_vote_up = WPDiggComment.cmt_digg_vote_up;cmt_digg_vote_down = WPDiggComment.cmt_digg_vote_down;siteurl = WPDiggComment.siteurl;使用了wp_localize_script函数后就可以放弃那个丑陋的方法了。
-
WordPress插件中加载javascript和css文件
Posted on 六月 17th, 2009 1 comment在写WordPress digg comment插件的时候,需要加载外部CSS和JavaScript,但是网上给的资料并不是很完全,或者很正确,以至于在插件中我使用了很多取巧和硬编码。在WordPress 2.8出来后,插件出现了兼容性的问题,原因在于引入JS文件的时候出现了问题。
WordPress中如果要引入script有两个相关函数:
1wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false );wp_register_script函数的作用是注册要调用的脚本,而且可以设置脚本所依赖的框架(必须是WordPress默认注册的框架)。
handle是一个惟一的名字,如果以后再要引用这个脚本,则必须使用这个名字。唯一的参数。
src是脚本文件的绝对路径,这个参数也是必须置顶的。
deps是一个数组,表明你的脚本需要依赖哪些库,比如jquery,prototype等。此为可选参数
ver是一个字符串,标明脚本的版本。也是可选的。
in_footer是WordPress2.8里面才添加的参数,默认为FALSE,链接放在head里面。如果为TRUE的话,那么脚本链接将添加在页面的底部,如果脚本比较大的话,能够加快页面的加载速度,提高用户的浏览体验。
举一个例子为:
1wp_register_script( 'digg_cmt_js', WP_PLUGIN_URL. 'digg-comment/js/script.js', array('jquery'), '1.0');wp_register_script函数只注册脚本,在运行的时候并不会让脚本装载到页面。我们还需要wp_enqueue_script函数:
1wp_enqueue_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false );wp_enqueue_script函数除了src参数为可选外,其它的参数都是一样的。如果提供了src参数的话,则会自动为你自动注册该脚本,相当于先调用了wp_register_script。
1wp_enqueue_script( 'digg_cmt_js');这样就可以在加载的队列里面加入该脚本了。由于wp_enqueue_script会自动注册,上面两条语句可以合做一条:
12wp_enqueue_script( 'digg_cmt_js', WP_PLUGIN_URL. 'digg-comment/js/script.js',array('jquery'), '1.0');在合适的时候调用这些函数就是一个最关键的问题了,在WordPress 2.7.1中注册到wp_head中可以执行,但是在2.8里面就无法正常运行了。查阅了文档发现对于脚本来说应该注册到wp_print_scripts才能够确保执行。
代码如下:
12345678class digg_comment {function add_jsfile() {wp_register_script( 'digg_cmt_js', WP_PLUGIN_URL. 'digg-comment/js/script.js', array('jquery'), '1.0');wp_enqueue_script( 'digg_cmt_js');}}$cmt_digg = new digg_comment();add_action('wp_print_scripts', array(&$cmt_digg, 'add_jsfile'));这样在页面就可以正常加载js文件了。对于css文件来说,与js文件完全类似,只不过函数名称稍微变化一下,没有依赖的框架而已。举例就不多说了:
12345678class digg_comment {function add_cssfile() {wp_register_style( 'digg_cmt_css', WP_PLUGIN_URL. 'digg-comment/js/script.js', array('jquery'), '1.0');wp_enqueue_style( 'digg_cmt_css');}}$cmt_digg = new digg_comment();add_action('wp_print_styles', array(&$cmt_digg, 'add_cssfile'));此外还有一种笨办法可以使页面加载文件,那就是在wp_head文件里面直接echo了,如下:
123456function echo_js() {echo "<script src="url-to-your-js-file.js" type="text/javascript"></script>";echo "<link href="url-to-your-css-file.css" type="text/css"/>";echo "<style type="text/css">.btn{border-width:1px}</style>"}add_action('wp_head', echo_js);最后这种方法还是不推荐的,能够选用前面的方法还是选用前面的方法兼容性更好。
-
Google为firebug发布page speed扩展
Posted on 六月 5th, 2009 No commentsFirebug俨然已经成为了Firefox上绝对的杀手级应用,虽然说Firefox的扩展数量是如此的巨大,但是能够像firebug一样有那么多扩展的恐怕不多。据我所知知名的就有如下的产品
Yahoo出的YSlow:知名的Web前端调试利器,对于前端的调试十分的有帮助。yahoo的作者有出《高性能网站建设指南》一书。
Firecookies:非常方便且好用的cookies的管理工具,用了这个后可以把其他的都放弃了。
Firephp:Firephp可以让你很方便的使用简单的php的函数来调用firebug的控制台。
Firecss:印象中是水木上的一个人开发的,可以将使用了的css都dump下来,从而去掉没用使用的css。需要的话似乎要去水木上找了,我也不记得具体是哪里找到的这个插件。
codeburner:可以显示html,DOM,CSS的属性的参考,及浏览器的支持情况。
昨天在Google的官方博客,Richard Rabbat和Bryan McQuade 介绍了一个叫做Page Speed的新工具。

Page Speed是一个Firebug的扩展,用来提升web的访问速度和用户体验。在文章里面写道:Page Speed is a tool we’ve been using internally to improve the performance of our web pages — it’s a Firefox Add-on integrated with Firebug. When you run Page Speed, you get immediate suggestions on how you can change your web pages to improve their speed. For example, Page Speed automatically optimizes images for you, giving you a compressed image that you can use immediately on your web site. It also identifies issues such as JavaScript and CSS loaded by your page that wasn’t actually used to display the page, which can help reduce time your users spend waiting for the page to download and display.
这个描述倒是会让人觉得Page Speed和YSlow有得一个比较,今天去看了一下YSlow有更新到了2.0beta了,界面和功能又增强了不少。虽然Yahoo的坏消息一直不断的传来,但是Yahoo的工作人员还是很尽心尽力的工作啊。
Page Speed比较明显的功能有如下:
- Minify JavaScript:能够Minifying到本地硬盘供参考
- Optimize images:优化后的图片也保存到了本地硬盘上
- Use efficient CSS selectors:将低效率的css选择器给列出来,在我现在的皮肤tango上,有很多三层以上的选择器被认为是低效率的,囧
- Remove unused CSS:列出没有被当前页面所使用的css,不过单独而言,我觉得可能firecss的dump功能更加的方便。Page Speed还没有提供这个功能。
其他的功能似乎YSlow也包含了,总之这是一个非常有用的工具。越来越看好firebug,希望Firefox3.5能够早日出来。
-
Google Code账号恢复了
Posted on 六月 5th, 2009 3 comments上次说我的Google Code账号被封了以后,邮件地址联系不上Google Code的管理员。拖aw联系Google的朋友,但是由于属于不同的部门无法沟通,拖延了很多天都没有解决这个问题。
前几天在Google Groups里面搜索到了Google Code 的官方group,于是在里面狠狠的抱怨了一通,第二天就收到了管理员的回复:
Sorry for the inconvenience, it seems we banned you because the
project hustjudge appeared to be distributing RAR archives without any
source. This is a very common pattern from spammers or people abusing
our service just to use it for file sharing.I inspected those archives more closely and they do include source code.
Your ban has been removed on both you and the project.
Thanks for your patience.
Nathan
see full version->http://groups.google.com/group/google-code-hosting/browse_thread/thread/bd6dfad35a42e01f?hl=en
自我反省没有什么违法的东西,果然是被误杀了,还好很快的给我恢复了,我也就没有什么别的可说的。只是仍然很不爽的是,在ban我之前没有给我任何mail什么的警告。
我在Google Code上面的Project:hustjudge judge-proxy hustoj douban4hust digg-comm-base
-
账号被Google Code给ban了
Posted on 五月 26th, 2009 No comments这一段时间上网不是很方便,经常忘记更新一下svn里面的代码,今天趁着时间比较空闲把几个项目都update一下。然后跑到Google Code上面去看看,没想到居然被重定向到了http://code.google.com/hosting/noAccess页面!(注意,无法直接访问这个页面)
以为自己输错了project,于是又检查了一道,发现并没有任何错误,换了一个浏览器登录,发现居然可以完全正常的浏览。当时就震惊了,为什么我的账户无法访问Google Code呢?看来Google Code是把我的账号给ban了!没有任何提醒与警告,就这样将我的账号给ban了,实在是想不通究竟是为何!
可怜的我在Google Code上创了两三个项目,还和人一同开发好几个project!现在我的账号完全没有办法访问了,这些project我都没有办法正常的参与了,不知道Google的工程师在这个功能上是怎么想的,居然连任何提醒或警告都不给一个就直接给ban了。
实在在这个页面上没有找到任何有帮助的信息,用Gmail发了一封邮件到google-code-hosting@googlegroups.com去询问究竟怎么一回事,结果系统给了我一封退信:
We’re writing to let you know that the group that you tried to contact google-code-hosting) either doesn’t exist, or you don’t have permission to ost to it.
这下我也没有什么办法了,只能够向再次向Google求助!通过搜索看到有人在博客中写道由于把图片放在Google Code里面,导致流量过大被ban了,但是想了想自己也没有做这么挫的事情,就更加的没有想法了。被Google封得真是郁闷,连原因都不知道!
托朋友找Google的人问究竟是怎么一回事,希望能够尽早得到答复……
-
我的博客历史
Posted on 五月 19th, 2009 4 comments确切的来说,我的第一家博客服务提供商已经从记忆中淡忘。博客中国,歪酷,博客大巴……或许还曾经考虑过其他的,但是最终我还是选择了自己去购买空间,购买域名。
我的第一个独立博客使用的还是exblog,一个非常国人开发的简陋的程序,现在似乎还在不稳定的开发中,选择它主要是因为它一个类似当时hotmail或者说msn spaces的主题,而当时的我很喜欢那个风格。主机空间是在512j买的,当时的域名还是www.newsfree.cn,也是在512j一起买的。那的确是我开博的第一个阶段,大概是高二到高三那一段时间,大约是2005年到2006年,似乎属于比较早开独立博客的人了。
在第一阶段曾经写了很多乱七八糟的东西,技术的,心情的,确实非常的混杂,和现在的很多技术博客一样,技术和心情都有。exblog的程序实在不怎么好用,所以不久后我就选择了使用WordPress作为我的第二个博客程序,并一直使用到现在。曾经我的博客上发布了相当一部分关于高中竞赛的知识,freepascal,Lazarus,gdb等等,直到现在还有为数不少的人通过搜索引擎找到我的博客,并向我寻求帮助。
时间不知道过去了多久,我开始对原来的空间和域名不满意,于是在梦游购买了空间,在万网的一个核心代理服务提供商那里购买了域名www.missway.cn,并一直使用到现在。不过正如域名所蕴含的意味,我的博客开始逐渐偏离了技术,走向了自我低吟与反思的一个小空间。在我大一转系后这种趋向更加明显,再也没有回到技术的道路。虽然这些年技术一直在持续的做,但是写的却全部是读书与生活,对生命的感触与思考。
出于对id的保护,在之后不久注册了www.freefcw.cn这个域名,以及几个其他当时尚未有人注册但是我很喜欢的域名。其实一直耿耿于怀没有一开始就想到一个好的域名,这样就不必为切换域名而带来烦恼了,freefcw其实也只是权宜之计,可没想到这样一用就是5年了…… www.newsfree.cn这个域名我用了两年后没有再续费,现在被人抢注用来做垃圾站,心里感觉总不是一个滋味。有时候从硬盘里面还会翻出当年青涩时期写的GDB不完全手册,扉页上赫然写着我的博客依旧是那个已经废弃的域名。
WordPress的创始人购买了ma.tt作为自己博客的域名,很羡慕,而我还在为没有一个合适的域名而烦恼。一个良好的域名应该脱离网站的内容,因为内容是可变的,人的思想是不断变化的,关注的内容也在变化,现在感兴趣的是技术,说不定下一阶段就是金融,或者其他的,一个有倾向的域名将和内容失去关联而丧失其意义。www.freefcw.cn这个域名适合任意内容,因为它不带有任何色彩与背景,而missway.cn就不是很适合写技术文字。ma.tt这样的域名适合任何东西,特别是一个包含众多内容的博客。
时间又过去了两年,这其中技术我依旧还在做,但是却没有作任何的记录和反思,这实在是有一些遗憾。一直很想重新开始写技术博客,但是却一直懒得动手,近些日子又重新开始把一些计划的事情坐下来,比如将豆瓣上正在读的书减少到10本以下。
不管怎样,假设一个博客是简单的,现在的WordPress只需要按一个按钮就能够安装好一个博客。而持续的写博客则是需要恒心和毅力的事情,而写好一个博客则更加需要博主的努力了。希望这个博客能够稳定的持续下去。
关于博客标题:B面的人生,还记得卡带有AB两面,如果说A面是missway.cn的话,那么B面就是这里了。



