Post Switch插件发布

本人终于发布了首个WordPress个人制作插件Post Switch,该插件可以很方便的切换正在编辑的文章。主要是本人发现在WordPress后台修改同一分类下面的文章时,需要不断切换到“所有文章”界面再切换回“修改文章”界面,颇为不便,于是就想在“修改文章”界面添加一个选项栏可以选择同一个分类下面的任意文章进行切换。写完插件用起来个人感觉也还不错,至少目前满足了个人需求。

post-switch 显示

插件使用后的“编辑文章”界面,增加了Post Switch功能块

post-switch screenshot 2

Post Switch功能块,上面可以选择分类,下面可以选择文章进行切换

取英文名倒是费了些神,写英文的说明文档也很痛苦,说明本人英文还需要加强。插件项目的托管使用了Github,于是也捎带熟悉了Git的使用,感觉确实很好用。无奈WordPress官方却使用SVN,怎么把这两个结合起来还需要继续研究。同时后续准备加强分类的选项,除了文章所属分类外还准备显示分类的父分类,这样能够进行编辑切换的文章就更多更容易查找了。

WordPress官方提交插件的地址也十分难找,居然在个人管理界面里面都没有,这里也顺便给出吧:插件提交地址

Post Switch插件下载:

Github项目地址

WordPress官方地址

filter的使用

WordPress开发中action与filter的使用是一个重要的部分,相比action来说filter这个概念更难理解,如果能够完全理解filter,action就根本不是问题。本人也是在开发主题的过程中终于完全理解,于是立即记录分享一下。

filter概念就如名字表示的那样用于过滤输出的内容,相关API很简单,基本就是add_filterapply_filters两个函数。add_filter用于向filter的tag上注册函数,apply_filters则是触发filter的tag从而运行注册在其上的所有函数。

开始本人不理解为何开发需要使用filter时不需要使用apply_filters进行触发反而只在使用add_filter注册函数,如果你也有相同的疑问,那么看下面这个本人碰到的实际例子:

现在需要根据主题设置修改body上class属性的内容,于是可以定义一个函数注册到tag名为body_class的filter上:

function theme_layout_classes( $existing_classes ){
$options = get_theme_options(); //get_theme_options函数可以获得相应主题设置
$current_layout = $options[‘theme_layout’]; //这里得到相应主题使用的布局设置
return array_merge( $existing_classes, $current_layout );//返回增加了设置的class内容
}
add_filter( ‘body_class’, ‘theme_layout_classes’ );//将我们定义的函数注册到tag名为body_class的filter上

这样当调用body_class()函数时(该函数通常在header.php中使用用于输出body的class内容:<body <?php body_class(); ?>>)就会调用我们定义的这个函数,从而将原定输出的class内容加上$current_layout 。

但如果现在需要在显示page时根据page的特殊布局设置覆盖主题的默认布局设置,我们应该如何处理呢?

由于已经把主题设置的class内容加进去了,再使用filter把内容减去就比较困难。实际上解决方法应是将新增的内容进行整体替换,于是我们修改函数theme_layout_classes为:

function theme_layout_classes( $existing_classes ){
$options = get_theme_options(); //get_theme_options函数可以获得相应主题设置
$current_layout = $options[‘theme_layout’]; //这里得到相应主题使用的布局设置
$classes = apply_filters( ‘theme_layout_classes’, $current_layout ); //这里实际我们定义了一个新的filter tag
return array_merge( $existing_classes, $classes );//返回增加了的内容
}
add_filter( ‘body_class’, ‘theme_layout_classes’ );//将我们定义的函数注册到tag名为body_class的filter上

可以看到我们通过apply_filters实际定义了一个新的filter tag,这样我们只要将新函数注册到这个tag上就能够整体替换新增的内容。
于是我们再注册一个函数:

function page_layout_classes( $existing_classes ) {
global $post;
$current_page_layout = esc_attr(get_post_meta($post->ID, ‘page_layout’, true));//获得page的特殊布局设置
if (! empty($current_page_layout) ){ //如果存在特殊设置,则返回这个内容
return $current_page_layout;
}else{
return $existing_classes; //否则还是返回原有内容
}
}
add_filter( ‘theme_layout_classes’, ‘page_layout_classes’ );//将这个函数注册到我们定义的theme_layout_classes上,以实现替换新增内容的功能

这样在调用theme_layout_classes时又会因为apply_filters( 'theme_layout_classes', $current_layout );触发调用page_layout_classes函数,注意page_layout_classes函数第一个参数$existing_classes这里会被赋值为$current_layout,于是就能用page的特殊设置覆盖主题的默认设置。

通过这个例子我们知道产生之前疑问的关键是调用函数body_class()时实际上里面就有调用apply_filters( 'body_class')进行filter的触发(出自get_body_class:wp-includes/post-template.php),当然我们不需要再进行触发,只需要使用add_filter将我们的函数注册即可。

华为合作K-V存储系统项目纪实(1)

本来觉得这个博客应该只关注于web技术,只讨论些wordpress,各种前端技术,乃至互联网公司发展方式的问题。但转念想来此博客关注度又不高,便违背SEO专注的精神也不会有啥流量损失。何况一个人还是把技术问题分在几个博客说也未免太夸张,这个博客既然是技术博客,自然应该什么技术问题都可以在这里畅所欲言。

于是决定把自己种种技术相关的文章都搬迁到这里,以丰富这个站点的内容,而关键的是要开始记录自己至今参加的第一个需要编码的多人合作项目历程。希望能够坚持每周写一篇,把从需求到设计到最后编码遇到的种种问题与思考都记录下来。

项目组由一个博士,一个准博士,包括本人在内的三个硕士组成。准博士算是项目负责人,但是具体经验不足,还是需要博士进行辅助。发过来的项目要求只有简单几句,概括说来就是实现一个key-value存储系统,key为两种定长,value只有8字节整数。总规模可以达到20亿条记录,10次找key只准1次io,最多利用总数据量5%的缓存。

这要求很是古怪,目前kv存储系统设计都会大量利用内存来做缓存,甚至很多都是所谓“内存数据库”。这里却对内存使用要求如此严格,但又要达到寻找key时90%的命中率,简直是不可能完成的任务。而且对性能还没有提成明确要求,已经可想见最终要求之苛刻。

调研从系统与测试方面进行,选择了最简单的hashdb与同样以节约内存闻名的tokyo cabinet,hashdb不到500行代码,自然只是大概学习一下。而就资料来看tokyo cabinet也只是面对千万级别的设计,在到达上亿数据时性能会急剧下降。

而后发现使用在工业环境的tokyo cabinet其实现居然如此简单,而且只能将数据存在一个文件中,很明显限制了最大存储的数据量,这彻底颠覆了本人对其的印象。测试下来自然性能也没传说中的那么牛,而且明显到达上亿级别测试结果不会好,一时全组陷入沮丧当中。

后来再多方考察使用TC做后端存储的flare等设计思路,才突然想到不应该将TC看成一个完整的系统,而应该视为一个最底层的存储引擎。这个引擎足够简单,但是足够好用,你可以在上面开发更多东西。一个文件并非对应一个TC数据库管理系统,而是只对应一个数据库,甚至一个表,比如可以将20亿数据拆分成几个TC数据库来存,这样就能存储在多个文件中(就是说DBA还得弄分片分表,TC使用类似innobase的file_per_table设置),也就可以扩展最大存储数据量了。当然性能如何,能否满足本项目苛刻的要求又是另一个话题,但是工业环境下是可以这样使用TC的。所以工业环境下使用软件不应该被限制住思维,一个不够,多搞几个,完成任务就行。

回到项目上,显然TC的hash引擎设计使用mmap来进行性能优化不适合本项目,再看B+树引擎设计也同一般B+树类似,没看出特色来,所以架构设计方面仍然是一筹莫展,只期待下周的需求讨论华为方能够更明确设计目的与要求。老师自然不满意这种简单的设计,要求我们看看更先进的系统,但是能用的kv系统真的不多,Berkerly DB算是最大而全的吧,可以了解一下架构设计,但对项目感觉帮助不大。

说到需求讨论,本人准备了各种问题,从系统基于的设备到可靠性与可扩展性要求乃至是否并发访问,结果博士来了句“问这些不相关的干什么,其实对方真正只是要一个能够管理大数据量而同时节省内存的算法而已”,仔细一看发过来的需求,还真是如此。所以项目需求最需要明确的是这个系统是用来干什么的,如果是一个为了算法测试用的原型系统,考虑那么多工程问题干什么呢?也许是本人太想鼓捣个工业环境用的系统玩玩了吧,以致忽略了对方提出项目的真实目的。所以需求明确是最必要的,而问出系统使用验收的环境是更关键的。

读浪潮之巅想到的

这是本人2011年10月的一篇读书笔记,当时对互联网的理解自然有限,倒是能结合这篇做个比较。

读《浪潮之巅》帮助我梳理整个计算机发展的规矩,只要读这种梳理路线的书就会有n多想法被串在一起,许多当时觉得有记录必要但却慢慢淡忘的思想也逐渐浮出,真心希望自己能多碰到些这种书。

1.作者从google出来却放弃去百度而选择了腾讯,这说明了一个态度:1.百度搜索霸主地位已经成熟,根据规律,其在搜索上的发展必然停止,而需要寻找新的盈利点。所以作者的搜索技术在百度是发挥不了作用的。2.作者认为百度找不到新的盈利点,他否定了百度作为技术公司的身份,认为其仅是一个互联网公司,存在转型困难的问题。这也是有一定道理的,尽管目前百度仍然是三巨头中最强调技术的公司,但百度盈利模式却放弃了技术路线,竞价排名让人工代替了自动化技术,这种矛盾性让作者从中看出公司基因的问题。3.作者说腾讯和淘宝将逐渐蚕食百度的搜索份额,但这与他所说的霸主规律相矛盾,显然这只是作者的一厢情愿。由1的证据完全可以推翻3的说法。

2.目前腾讯的主攻发展方向是霸占桌面,以此继续巩固扩大自己的im优势。显然腾讯调整了原来希望霸占操作系统的心思,因为仔细分析就能发现那个其实迟早要被浏览器霸占,而浏览器大战腾讯tt没有丝毫转化优势,于是干脆放弃改为霸占用户的片段时间(即桌面)为此推出Q+并改变了webQQ的发展方向。由需要探索需要服务定制的一站式服务系统,改为一目了然扁平的桌面。

原来总是不解为啥q+或webQQ桌面上要默认放那么多应用,现在更是推出常用网站功能,一打开满屏幕各种大众网站密密麻麻。其实这既是跟其战略制定相符合,而战略制定更是和中国用户习惯相适应。这点听了周鸿祎的分析才真正弄明白,中国大多数用户尤其是使用qq客户端的都是没有细分能力的,他们不喜欢探索更讨厌定制。即使给他们一站式服务系统,他们也搞不懂到底怎么用。而让他们用的最好的方法就是推送,他们不是懒得考虑自己需要什么吗,那就一股脑都给他们。所以腾讯放弃了系统,选择了桌面;放弃了分类,选择了扁平。

3.腾讯微博明显干不过新浪微博,但腾讯还是在搞;腾讯朋友更是彻底失败,但还是反复在搞,目前甚至不惜使用最后绝招与im绑定。显然这是需找新盈利模式的无奈,目前世界成功模式有搜索,电子商务,web2.0社交平台(facebook,或twitter),前面俩个腾讯也在积极的做,但由于霸主规律,基本无望。社交方面腾讯是霸主,更有优势,但转向web2.0平台却不那么容易。好不容易在3Q大战后意识到不做成平台不行了,全力去促成,无奈目前两种平台都弄不起来。

4.比腾讯朋友更有用户基础的Qzone也在改版,而且极其诡异的同时向两个方向努力,一方面是向社交平台转变,这当然是弥补腾讯朋友失败的无奈之举;一方面又得适应博客先轻博客转型的世界潮流,而问题在于信息爆炸的社交平台与小资情调信息极少的轻博客从设计本质上就是矛盾的。腾讯朋友的失败其实也是虚拟关系的qq号网络和真实信息的社交网络两者设计本质矛盾的产物。现在的腾讯其实在痛苦的转型期,所以才弄出桌面战略以此来进一步弥补平台的问题,既然平台建不出来,只好把im也往平台转。第一入口浏览器不成,只好选第二入口桌面。我原来也只想到了第二入口桌面,觉得以后肯定会有越来越多的公司抢这个,却没有想到浏览器,再看google的思路,发现确实有境界理解上的差距啊!

5.腾讯这几条线都没有放弃,社交网络甚至采取得是齐头并进的模式,看来战略仍然是不断模仿直至对方找不到盈利来源拖垮为止。无奈新浪不吃这套,而且大有反抢qq社交关系的架势。微博本就很容易使用,和qq一样可以是虚拟身份也可以是真实身份(这点在中国很关键),而且最关键的是脱离平台限制,完全可以想象qq的危险境地。所幸对手是新浪,没啥创新能力与技术储备,否则其放弃平台专做统一接口,那将是对qq一次毁灭的打击。

tag与category的使用与自定义标签的设计

WordPress中存在两种类型的分类:一种是tag,另一种是category。这两种分类的区别在于: category通常是有层次的,而tag是平行平等的。

一些著名博客如Smashing Magzine以及Nettut+是如何安排使用tag和category的呢?

最新Smashing Magzine主题是轻博客类型,完全放弃有层次的category,而全部采用平等的tag。

而传统博客类型的Nettut+基本采用category,其URL结构为/articles/javascript或是/tutorials/ 。tag用来标记类型如video或tips,该主题甚至可以结合两者进行查询。

WordPress中可以使用函数register_taxonomy注册自定义标签,区分是category类型还是tag类型的关键就是参数hierarchical。

如何设置TPLink无线路由器使得电信IPTV可以同时上网

一下午就想解决TPLink无线路由器与电信的iptv同时上网的问题,无奈没有成功。感觉思路是正确的,但是配置上TPlink软件功能不全。思路如下:

电信约定的方法是:Modem是做桥接设备的,上网需要终端、计算机分别pppoe拨号(一条线路支持多次拨号)。

我们一般用的时候,希望Modem自己PPPoe拨号,这样计算机可以直接连上网口(或者通过wifi)就可以上网了,当然ITV的终端也可以这样(事实上,电信一般也是让机顶盒自己拨号的)。

综合上述情况,可以这样做:

  1. 将Modem设置成自主PPPoe拨号,并支持DHCP,这样计算机可以通过有线,或无线的方式上网。IPTV采用网线连接MOdem,需要设置成DHCP的方式。 DNS可能需要自己设。(此方法不知为何总是不成功,实际电信的IPTV必须专线自主PPPoe拨号,所以不能使用DHCP方式 new!2013-02-14更新
  2. 也可以将iTV机顶盒设置成PPPOE拨号,需要将对应MODEM端口设置成桥接方式(不懂啥意思)
    又经过一天的实验与奋战终于搞定了。实际原因在于两个终端都要进行拨号,所以不能使用集线器连接而应该采用交换机进行连接。TCL弱电箱中提供了一个三口集线器,一个四口集线器以及一个所谓IP共享器(其实就是一个路由器,IN口即WAN口,其余OUT口都是LAN口)。解决方法即把IP共享器用作交换机,全部使用OUT口(这步是关键),入口线还是接集线器,但是跳一条线从集线器到IP共享器的OUT1口,TPLink无线路由器的WAN口接OUT2口,IPTV接OUT3口,这样就能同时PPPOE拨号,于是就都可以上网啦。new!2013-02-14更新

2012互联网哲思

HTML5从09年就开始预热,今年终于正式火起来,但是显然仍处在上升期,因为智能机时代还没有完全到来。而一旦智能机时代到来,国内的互联网巨头们就未必能够继续嚣张。因为他们都是做应用起家,虽然均在11年开始平台化建设,但到现在状况仍不理想。反观世界巨头们微软,google,facebook,无不在平台化建设上越行越远,甚至苹果也在平台化上付出了很多。

百度老早就学google的igoogle弄自定义web桌面,无奈当时它缺少最重要的类似GAE的平台。终于今年百度发现这个问题,又回来亡羊补牢做BAE,但是google早就继续大步前进开始搞ChromeOS了,而百度在经历自定义桌面失败后只好弄出新的搜索界面,即直接在搜索界面上加上自定义应用。

百度这个思路还行,但是问题不少,一是BAE知名度还太小,甚至不如新浪微博的SAE,这就导致应用不足;二是稍牛逼的应用都不会傻到给百度送流量,它们不需要用流量来换名气;三是最大问题,即在百度上放应用没本质好处,如果百度能够提供些其特有的数据还好说,无奈百度提供的api都与其空间相关,如果提供贴吧api估计还有效果,但百度空间不过是个博客平台而已,不成气候。这些问题最终导致百度平台缺乏优质应用,自然平台建设任重道远。

(百度的最新开放路线 http://news.csdn.net/a/20120323/313489.html 百度宣称将开发其有价值搜索、贴吧、知道、百科服务的api,但至少也要等到2012年10月以后。确实正如之前的分析,这些api不出来就无法构成平台,这些都是早都该发布的api 最新于2012-3-27修改!

但百度也不靠这个吃饭,毕竟只要一日中文搜索技术没有新突破,它就不担心会有挑战者出现。而腾讯就不同,交友社区很容易出现挑战者,其原先歪打正着攀网游的大腿让其一跃成为巨头之一,但之后新的增长点就需要新的思路。

说腾讯是中国的facebook其实是很正确的,两者都是做完聊天做博客社交,做完博客社交做游戏。但是不同的是期间facebook一直在做平台,而现在引入timeline系统之后,它可以除游戏外,继续做视频,音乐,阅读等等方面与社交的结合。但是腾讯就明显不行,各个应用之间有点一盘散沙的状态,倒是和google有点类似。可是google有gmail这个平台可以来进行整合,最近又弄出一个G+的大平台。所以腾讯目前思路也是尽快完善Q+平台来整合自己的分散资源,给出一站式体验。原来总是以为腾讯会学google弄出一个云操作系统,但其很聪明的提出占领桌面的思路,等于是在操作系统上面一层来做入口,确实蛮有创意,所以360很快就学习过来,都是明智之举。

无奈它们都忽略了未来不是pc的天下而是平板电脑和智能机的天下,而且智能电视系统也会分一杯羹。所以这个占领桌面战略能否顺利实施还真是吃不准,毕竟苹果与google都不是傻子,它们也都想占领桌面。特别是google的android系统,完全就是为推自己的应用而生。google甚至还弄出chrome要继续占领浏览器入口,看架势是完全就不准备给他人机会。

所以腾讯还是应该继续学facebook做web平台,webQQ就是很正确的选择。第一步应该继续整合webQQ与Qzone资源,并接下来一个个应用进行整合,什么腾讯视频,QQ音乐,搜搜等等,虽然还是Q+战略,但是个人认为重心应该放在web端的展示,而不是pc的壳中。应该让用户快点适宜web端,而不是适宜pc的壳,否则他们可能会很难适宜未来的种种壳。

最后回到开始的话题HTML5,这个技术目前还不算成熟,而且最终其结果也就是另一个flash而已。大家寄希望于其能够打破google和苹果在操作系统层的垄断,但是前面已经提到google早就把触手伸向浏览器层,所以其最好的结果也就是创造一个类似facebook的平台。但创造facebook平台其实与用什么技术没啥相关性,反而是思路与决策的问题。只要思路决策好,苹果app不照样能做平台,大不了针对不同系统做各自的客户端。当然HTML5有希望解决这个重复做客户端的麻烦,但是有微软IE在,这个任务也是一样任重道远,即使撇开其不谈,目前css3各种前缀也够让人心烦的了。

来自苹果ui交互设计师关于开发工具的创新思维

这是来自苹果公司的UI交互设计师Bret Victor的讲座。该讲座的真正目的正如讲座题目所示Bret Victor – Inventing on Principle,并不是讲这些演示中的工具设计或是设计思路,而是借此阐述作者关于人生,关于设计更本质的思考,也可以说是哲学层面的思考。但是本人目前没有这个能力,也并不想刻意去拔高自己的思路,反而就想谈谈这些创新的工具设计与设计思路来。

演示中第一与第二个的工具设计完全可以用到html5的开发工具设计之中。介于目前html5正是火热,特别是基于canvas的开发,无奈用js来写画面有很多绘图代码而且不能实时反馈,但如果使用类似flash的代码生产工具,又容易导致代码冗余。看完此演示,发现如果真能实现这种工具,那么就应该是目前最适合html5开发的工具吧,但是如果是大型项目也依旧无能为力吧。毕竟目前就是网页制作也没有完全实时的工具,firebug虽然能够实时修改样式,但是实时构建还是很困难。

第三个用于算法演示的工具也很有意思,对于一个给定的输入能够在coding的时候看到反馈,还是蛮方便的。但是如果是稍微复杂一点的算法设计,应该就没有这么容易进行反馈,比如递归类型的。而且其实算法设计一个困难的部分也在于选择某些输入,该工具对这个也起不到什么作用。

最后一个给人感觉更像一个广告,和前面的演示效果不在一个数量级上。除了是个ios应用之外,真没有什么特别之处,比起来还不如微软的PowerPoint制作这种动画来得方便。在用户体验方面也没有什么特别之处,制作完成后想看效果仍然需要一个类似编译的过程,于是感觉和前面演示的主题有冲突,说不是广告还真难以令人信服。

wp_enqueue_script与wp_enqueue_style相关函数的使用

很多主题都未使用WP系统提供的api来引用额外脚本与样式表,而是在前端页面代码中加入或是在某些函数中输出。就最终结果来讲其实影响不大(当然如果使用wp_minify这个插件来进行站点性能优化,可能会出现某些js代码或样式表遗漏的状况),但这会给代码管理上带来困难,特别是当你需要修改这些外部引用代码位置的时候。

其实WP提供了wp_register_style,wp_register_script,wp_enqueue_style,wp_enqueue_script四个函数来简化额外样式表与JS代码脚本的引用。

前面两个用于向WP注册引用信息,后面两个用于真正插入样式或脚本。实现待补充。

特别需要注意的是wp_enqueue_script使用时必须在调用wp_header函数之前,否则注册时wp_register_script是否在尾部加入的参数设置不会起到效果,甚至会影响wp_enqueue_style的插入地点,变为一律在最后调用函数的位置处插入脚本与样式表,这对样式来说问题就比较大咯。

制作Bookmarklet书签

基本模板就是这样,主要是javascript:起了作用,导致代码执行。

javascript:(function(){

if(window.bookmarklet!=undefined){bookmarklet();}
else{document.body.appendChild(document.createElement('script')).src='http://YOURURL/bookmarklets.js';}

})();
本站总访问量