NetBeans的字体设置补充&近期开发整理

曾建凯 发布于 2010/09/16 07:50
阅读 2K+
收藏 2

NetBeans字体设置补充

由于近期在用别人的电脑干活(我发现日本的笔记本质量确实过硬,同样2、3年的时间,15寸的宽屏,电池居然还能维持3个小时,国内买的本本,电池的损耗是最快的,别说你不知道笔记本电池是损耗品啊?),他的系统是Vista(香港繁体),默认编码是ms950的,居然发现过去的NetBeans设置的字体无效,改了半天,最后发现,问题的关键在于ms950。

打开fontconfig.properties文件,搜索一下ms950,就发现问题的真相了(初始的字体设置,参照此帖:NetBeans字体设置),所有和ms950相关的字体设置,都被设置成了PMingLiU,这个字体本身不算难看,但进入Java的Swing的界面,就显得特别别扭,只要将所有基于ms950的字体进行相应的设置(sansserif,monospaced这些),于是字体的问题就迎刃而解。

经过这次,可以很明显发现,这个fontconfig.properties,是根据当前系统的默认编码进行选择的(其实这个问题早该发现),经过此番调整,jre的字体问题基本上不会再碰到太大的问题了(包括基于jre的软件,比如SmartSVN,Idea除外,这是个特例独行的家伙)。

网站CSS全局字体设定

这也是ms950惹得祸,常规网站的字体设置,我们总是习惯用如下的设置:

body,table,input,textarea,select {font-size:10pt;font-family:Verdana,sans-serif;}

不过由于编码不同,不同系统的默认Sans-serif的字体的设置都不一样,Ubuntu还好些,有一个字体设置的界面定义(其实Ubuntu的字体设置,是比较根本性的设置),Windows虽然也能让你设置字体,但你只能改改界面上的字体,却没法对系统默认的sans字体进行修改。于是乎,使用上述字体设置,在ms950下面,就会看到极其扭曲的字体,字体字号大些可能还能看清,12px的,完全就扭成一团去了,英文更甚,要离屏幕很近很近才能辨识出。

所以,如果你是做网站的,做中文简体网站的,请注意你的CSS设置:

 

body,table,input,textarea,select {font-size:10pt;font-family:Verdana,Simsun,sans-serif;}

 

Simsun就是宋体,这样就能避免发生使用了系统底层默认设置的sans-serif字体进行渲染了。

其实这个问题不但关联网站,还关联到软件,有些软件界面,你看到极其扭曲的字体,也是因为使用了默认的sans-serif造成的。

另:OSChina仍有局部的页面会出现字体扭曲的状况,比如发博客(个人空间)这个页面,仍未设置Simsun。

关于PHP IDE

我个人开发PHP,还是习惯使用IDE,因为可以迅速提示一些自己写的Library的一些方法和属性,最早的时候,一直用Zend Studio 6.0,当时来说,这个编辑器确实提示迅速。但是随着6.1,7.0,7.1的发布,不但bug重重,而且受限于eclipse这个不太稳定的IDE。还有一个极其致命的短板是,集成于Zend Studio的js解析器极其落后和弱智,在编辑内嵌在HTML中的js的时,语法着色完全不能用,经常是一大片黑色的代码,而且自动完成还会异常,尤其是你写一个闭包函数,他会完全没法正确提示。

这三年PHP开发过程,也是对PHP IDE进行大甄选的一个过程,所有能找到的的PHP IDE,我都用过,最夸张的时候一台机器同时装了7个以上的PHP IDE,我这人就是这样,对自己用的东西十分较真,不测试出个丁丑寅卯誓不罢休。中间的测试过程就休提也罢,只说最终的测试结果(以下排名只依照个人习惯排列)。

1、NetBeans PHP IDE(nb版本6.5以上)

2、PHP Desinger 7.1+

3、vs.php / Komodo IDE 并列

4、NuSphere PhpED

5、.....

6、非IDE的:Notepad++、Ultraeditor、UeStuido

7、其他,乱七八糟的IDE

8、最后一名,Zend Studio

NetBeans PHP IDE缘何能排于前列呢?最客观的考核标准是,这三年来,我用nb写的php的代码数量最多。从技术指标上讲,nb的稳定性是最高的,虽然很多人都抱怨nb开起来很卡,很慢,但我在2G以上环境使用nb一直都很稳定,尤其是写PHP、HTML、CSS和JS,可以说,NB陪我度过了无数黑暗的日子(半夜),他伴我度过了无数从漆黑转向光明的日子(半夜到天亮?)。而且,和下面的IDE进行比较,nb的配置自由度是最高的,语法提示的密度也相当适合(不像PHP Designer,提示的频密程度已经让我觉得烦了),关键的关键是,类似""这种自动提示,但你删除第一个",他会自动删除后面跟着的"(但中间为空字符),这会让你少按很多很多次键盘。

当然,相对来说,如果要评价对PHP语法的理解能力,最好的莫过于PHP Designer,假定一个MVC的开发环境,有以下的一个继承链条:

IndexController  < __Application < ActionController

NetBeans最多最多,只能理解到IndexController这一层,所有之前的类的方法、属性,都能正常提示。但到了view层面,你就完全抓虾了,他实在无能为力了。这点来说PHP Designer却是做的很完善的,即便到了View层面,他一样能告诉你,$this->p提示出$this->params,也许PHP Desginer也不过是对所有出现的属性做了一个临时全局性记录,但聊胜于无。

还有一项我个人设定的评比指标,就是在低平台的运作,大家可以忽略不计,比如移动本的Atom(因为我的笔记本坏了,所以长期拿着一个移动本到处招摇撞骗的,有时候要改改代码),最好的当然是非IDE的诸位,但是netbeans和php designer以及php ed照样能运行,提示也照出不误。

PHP Designer,别看Designer,就以为是和设计有关的东东,其实他旨在让你更加轻松的编写你的PHP代码。他首先是一款基于非常强大的HTML、JS、CSS IDE,这方面功能做的十分完善。

在HTML方面,他是目前为止,对HTML编码准备的最完善的,比如你输入<script,后面一切皆有提示,自动闭合标签,自动提示出标签属性名,进入自动提示出标签属性值,这一点上,已经完完全全的胜出于他的前辈DreamWeaver,绝对是过之而无不及。

在CSS方面,该有的提示都有,这个就不必说了。

在JS方面,他能够选定你当前的库,比如jQuery、Mootools、Prototype,等,在编写JS的时,会有比较充足的提示。官方的视频里,是允许开发者自己设定js Library的,不过似乎我怎么也弄不成功。

PHP方面,他的提示非常全面,方法、属性,这些都无须多讲了。最值得一提的是,在编写混合编码时(混合php、html、CSS、js),他会自动高亮你当前编写的编码块,其他非关联的代码块会变成灰色。这一点能十分有效的集中你的注意力。

虽然PHP Designer拥有种种优点,但他有一个使用前提,即你必须对他十分了解,而且要做一定的配置调整(比如关闭其他无关的js提示,调整提示的时间频率)。而他的自动提示方面,除了提示频率过高以外,还存在常常多完成一个括号,这玩意常常会让你多按几下键盘。值的一提的是php Designer自动带有中文语言,而且不是那种老外翻译的十分蹩脚的那种。php Designer属于商业软件,需要破解的朋友,可以与我联系。

vs.PHP,这个家伙基于微软的vstudio,可以说既集成了他的好处,也集成了他的缺点。文件编码在windows XP上,一直是vs的一个诟病。他也做了足够多的语法提示,也能动态的分析你的类库。但是由于我极其不喜欢VS的花括号的格式(老习惯一直改不了),还有vs的HTML编辑器,一直给我太硬的感觉,不太好用。而vs的CSS、JS,一直以来都做得不太好。

有一点值得称道的是,vs.php可以使用vs 2008的js提示,不过我一直觉得这玩意也是个蹩脚的设定,在html代码,或者js的首行,通过用户注释一段js提示的文件入口,他会自动加载该文件,并在你编写js的时候,给予你足够多的提示。之所以说他蹩脚,因为他能很好的工作与aspx,却无法很好的在其他语言上工作(微软总是屏蔽技术实现细节,只告诉你个使用方法),而且,vs会缓存所有的提示,这意味着,你需要手动去修改vs的项目设定文件,这是很痛苦的事情。而且但你修改完毕,他又会重新缓存。

vs.php也是商业授权软件,一直以来我都找不到最新版本的破解,所以无法对最新版本进行测试。

Komodo IDE,这也是个商业授权软件,但他做的十分开放,拥有完善的IDE接口,你可以自己扩展。多的就不说了,他有很多用户自己开发的插件,针对性十分强,其中有一套模仿mac下的textmate的html输入提示,只能在windows下运行(个人觉得此插件比ZenCode实用多了)。

PhpED,也是一个十分优秀的PHP IDE,他拥有性能测试,能对单个脚本文件进行性能测试,同时也能嵌入到web访问中,这个对于早期刚开始写php代码的人,有很大的帮助(虽然用xdebug也能做同样的事情,但你需要对xdebug进行设置,还得有适合的工具,这对初学者是十分痛苦的),他也拥有类似php designer的代码块高亮。不过他对于js方面的提示就有些乏善可陈了。HTML编辑器方面,他也在努力模仿DreamWeaver,不过需要商业授权才能用到最新版本的功能,对于一个写了10年HTML的人,那点预览和提示,也可有可无了。

总体来说,如果新接触PHP的人,PhpEd,PHP Designer会比较适合,但你对PHP有足够多的熟悉和了解,又需要一个更简易、更趁手的IDE时,Netbeans和Komodo会是更好的选择。

非IDE的几个软件中,我测试过EditPlus,Notepad++,Ultraedit,不过他们都无法对$进行双击选定,据说Editplus配置能解决此问题。Notepad++通过插件能实现引号、括号的自动完成。

不过,终归来说,我的目的还是需要一个晚上的php ide。因为你试想,在你打开一个诸如Dz的论坛,ucenter home的代码,或者你从SVN中checkout一个工作团队写好的代码时,编辑器已经自动完成了对常用函数、类库的代码收集了,你说需要的,只是在适当的位置加入你的代码即可。综合各方面因素,推荐度最高,还是netbeans,除了他的容量比较大以外,拥有良好的php library的分析能力,适当的自动提示,完善的自动完成,对js和HTML的高亮十分完善,同时,还支持一定范围的语法错误检查,这不正是你梦寐以求的IDE吗?

PHP语无伦次

我一直在坚持用自己的MVC框架写PHP的代码,而且我也一直有做性能监测,该框架已经从最初只适应PHP 5.3以前版本,转为只适用于PHP 5.3之后的版本。并且中间的文件加载机制(autoload)、ORM部分,做了大量的改动,尤其是关于OOP化方面,过去取出一个数据只是用Array持有数据,现在已经彻底转换为一个类的实例。

这个过程中,一直对PHP进行Object化的性能有些忐忑。因为根据早期自己做的测试,array的操作是PHP中性能最好的。而一个类的实例,尤其是类似Ruby on Rails那种开发模式,每个实例都持有继承回来的方法和属性,每个实例初始化,都会执行一定的方法,他自然不如php原生的array那么简易、明了。

在确定选择只对PHP 5.3适用以后,我对php 5.3的许多新事物(其实php 5.x开始就有了)做了许多测试,其中尤其是对ArrayObject和FixArray进行测试。根据当时的测试结果,ArrayObject在PHP 5.3的性能和原生的array的性能持平,毫无二致。可是fixArray,却没有PHP传说中的那么神,尤其是在fixArray中存储复杂结构的内容,性能会降低,内存开销会更大。fixArray只在存储php常规类型的变量的时候,比传统array要高。

不过终归来说,这些测试也只是在开发环境进行的,虽然新框架已经具体做过一些项目,但大规模的发布模式下的性能测试还从未进行过。昨天一个项目发布,我特意的加上了从index.php请求的入口记录下启动时间,并到Session Close过程之间的时间进行统计。我惊讶的发现,运行时间竟然比php 5.3以前的框架版本的运行时间缩短了许多(非使用opcode cache的模式下运行)。这是一个很不错的结果,让我马上联想到,PHP 5.3曾声称对GC回收,尤其是对Object的回收进行调整与优化,对于Object的存放空间也进行过调整,看来这种优化不是空穴来风。

其实,国内的PHP社区一直在争论,PHP是否应该使用框架,现在我有更明确的答案了,在PHP 5.3以前,你需要对Object的资源回收做特别的处理。但在PHP 5.3以后,框架,已经是优化你的代码规范的不二选择。

国内现在正流行nginx+phpfpm运行模式,个人认为,这是一种十分不注意原创和研究的精神导致,phpfpm在IO方面的性能如何,这还没有全面的测试结果。而nginx也只不过是一个非常强大的porxy。但是,在Linux 2.6内核基础上,lighttpd有更多针对IO、文件目录结构的优化和缓存,这是fastcgi的依赖基础。

不要人云亦云,做好基础测试才是根本。

加载中
0
赵开锦
赵开锦

你的mvc是什么样的?能不能开源下让大家看看,谢谢?

0
G.
G.

我也是在学习PHP的.

楼主能不能多谈一谈你的PHP框架方面的话题.

网上有很多框架,可惜用起来差不多, 但又有很多细节不一样, 所以至今并没有选择网的上框架.

我觉得还是自己写的东西用起来比较方便, 尽管我写的东西很差,很不完善.

希望楼主能多多谈一些PHP开发中的经验!

谢谢!

0
曾建凯
曾建凯

我鼓励自己写框架,一套框架等于一套开发规范和流程,别人的,可以学习,但不是真的非要用别人的。很多功能可以自己慢慢升级。

目前来说,php 5.3有一些值得关注的新课题:

1、__autoload加载机制,这个其实从很早就有,一直不受到重视。这个能有效的缓解IO的压力,比起手动调用include有效的得多。我的新版本全部统一使用__autoload,比如加载controller、Model,代码量立刻减少1/3。

2、几个标准的SPL class和interface,PHP的interface其实没有真的起到约束的功能,但是他却是在PHP层面和PHP内核之间的一个语法糖,一定要好好用心测试和研究。

3、PHP的反射类,关键时刻的一下能让你解决很多问题。不过不要滥用,性能未经过测试。

4、phar打包,这个类似java的jar,很有趣,他支持md5不可逆打包,值得研究(我只是初步测试过,还没全面研究)。

5、namespace,新版本的框架已经在缓慢的重构中,其中就调用了namespace的特性,因为他的调用模式其实是和文件存放的path吻合的,比如My/First,那么在IO存放中,则是/app/anypath/My/Frist.php,这有助于推进文件存放的规范。过去的Pear标准,是使用_表示io路径中的path slash的,这个东西,对于那些不熟悉php的人来说,真的是一个噩梦。(这种命名方法的改变,也有助于推进对__autoload更好的规范,以前是根据_进行判断的).

6、差点漏了最关键的,PHP Class的各种Magic方法(包括SPL Interface),别小看他,实际开发用处可大了。

作为一个框架,尤其是Web框架,有以下几个问题,是首先需要解决的:

1、dispatch思路,这里要讲究灵活性,要能主动控制MVC的router是不是启动。

2、router的算法,这是关键的关键,这个算法我优化了1年多,最终版本十分满意,正则不要烂用,要先用字符串的算法将算法的复杂度分解了,但是正则必然需要使用0-1次。router配置必须简便。(这个不是必须的)

3、Session控制机制,别说你还十分喜欢传统的io模式,那个不行,全局掌控能力太弱了,比如要查当前有多少会话在活跃中,完全没辙。当然你可以每个会话再起一个表记录,既然如此,为何不控制了Sesssion呢?

4、HTML的控件的封装,这个需求度最高,也是最考验基本功的,尤其是,如果你希望你的框架能给不同的人使用,你得考虑其普遍的接受程度。比如一个后台程序员,关心什么(字段,值限制),一个前台工作人员关心什么(具体input标签的id,样式可否覆盖)。

5、ORM,这个完全看你自己的需要,ORM封装需要很丰富的经验支撑,同时很大的魄力,你需要对PHP现存的主要的几个数据驱动都比较熟悉。最起码你得了解PDO和MySQLi,PDO是PHP的标准数据库接口,对应各个数据库都有实现。MySQLi是mysql原生的驱动。每个数据库在php都有原生驱动,比如oralce,sqlite等。PDO在对个别数据库,比如oracle的lob对象的支持有内存溢出的问题。

数据驱动层,数据映射层,最起码得分开两层。而我目前版本的MVC的ORM分得比较细,

数据驱动抽象接口,数据驱动适配器实体,数据映射层,数据单元实体(数据结构实体)。这个其实也是老三层结构的实现原理,不过根据实践经验总结,我觉得这个分层还是会将各部分的逻辑搞混。我已经有一套更新,更符合php语法特性的设计。

6、是不是使用模板,看个人需要。我一直计划自己设计一套半状态机的PHP模板,不过实际用处不大。但有时候写php的标签也着实写的窝火。我是不推荐使用模板引擎的,我比较欣赏RoR的view层的实现,layout -> view -> widget的实现思路,这套方法极其灵活,包括我自己的框架,从最初也是用这种模式至今。大layout的切换,view不变,view变化,大layout不变,利用view层,调用不同的widget,在view做多一层widget router,也可以基于url做一层controller内的router,灵活多变。

7、要熟悉各大版本的httpd,lighttpd nginx apache IIS,都要有实际部署的解决方案。url rerwite,我一般都是使用当存在真实目录或者文件,则采用直接访问该目录文件,否则全部转发index.php,实际上这种方式的性能也是最高的。基于url $_GET的rewrite,性能还是有损耗。

底层开发要注意性能,不要过分优雅,要为上层应用预留足够多的性能空间。毕竟php是即时执行的,如果你的library都耗费大量内存和性能,你不可能指望你的框架跑起来有多快(上层应用开发者所使用的性能往往是底层的3-5倍)。

监控代码运行时间,应该客观的从index.php第一行就开始,因为这中间包括了对io引用的性能,他能反映你的框架的整体运行状况。国内某框架,自欺欺人,把底层library全加载了,才开始算时间,鄙视之。

0
曾建凯
曾建凯

补充说,你的设计思路中,必须有两点是时刻要去考虑着的:

1、允许用户通过继承即可迅速重建一个基础,比如核心class,ActionController,你不能指望你今天封装的代码能家天下,别人有权力对他进行改进(能继承和重载,就能避免直接修改你的代码)

2、一定一定要考虑重用性,最初一直忽略了这个问题,一味的考虑性能,结果造成同类型的代码大量存在,实际上真的实现了Model和Widget重用,只不过多用了10-20%的性能。

实现数据层的分离,好处在于,接口不变,无论你的驱动怎么变,都不用修改上层的代码,分离的越细,越容易控制数据库控制的粒度越细(数据库不必具备事务,你的ORM层具备也足矣)。

0
G.
G.

哇,你提到的问题我很多都没有涉及到,这个得好好,慢慢的消化!

谢谢  曾建凯 分享经验!

0
曾建凯
曾建凯

框架我一直自己闷头写了很久了,也希望能分享一些经验。

0
G.
G.

东西太多了, 我得消化几天.

希望以后能多多向你请教!

0
曾建凯
曾建凯

呵呵,多交流多交流

0
子风

这个回复比博文内容更有价值啊。

收下了。慢慢品味。

谢谢分享! 

返回顶部
顶部