月度归档:2005年12月

开始有些熟悉VIM了

    这两天有看一些VIM,还做了一些相关的设定,感觉我已经开始习惯VIM了。
    VIM默认是wrap模式的。我主要用VIM看代码,代码wrap后就几乎没法看了。set nowrap设置成不进行主动换行模式。
    vim在默认情况下底部的滚动条是不显示的。在自动换行的时候这倒没什么关系,现在被我该成了非自动换行模式,这个问题就变得尤为突出了。修改设定文件,set guioptions+=b,添加底部滚动条。
    vim中的tab和自动缩进都是8字符,相对我的习惯来说这实在是有些夸张。修改配置文件,将自动缩进都改成4。set ts=4;set sw=4。
    vim的默认字体实在是难看,还是换成比较常用的Courier New吧。set gfn=Courier_New:h10。配置文件中如果带了空格将无法解析,需要将空格替换成“_”。
    vim的语法高亮也是个问题。不知道是不是linux的习惯,在语法高亮都喜欢用粉红色,以前的那个jedit也是这样。不知道是不是大多数人都习惯这样,反正我是习惯不了。将默认的配色文件都试验了一下,没有哪个比较满意的。darkblue还不错,不过里面还是有用到粉色。还是自己动手修改一下吧。在\Vim\vim64\colors下找到darkblue,修改PreProc的颜色为00ff00(深绿色)。
    基本设定差不多了,然后还去找了几个插件。我还是比较习惯IDE,用vim来直接写代码的机会应该不多,不过找插件对我来说差不多是必须备行动了。以后偶尔要用到也说不定啊。
    安装了taglist.vim和intellisense.vim。
    差不多就这个样子了。看网上不少有人帖自己的vim配置文件,我也学学,帖了玩玩。
    用vim带的2html功能转的。呵呵,大家正好可以看一下我使用的配色方案。
 

set nocompatible
source $VIMRUNTIME/vimrc_example.vim
source $VIMRUNTIME/mswin.vim
behave mswin
let Tlist_Ctags_Cmd = 'D:\Program Files\Vim\vim64\ctags.exe'
set autochdir
set nois
set tags=tags
set nowrap
set guioptions+=b
set ts=4
set sw=4
set gfn=Courier_New:h10
colors vxdarkblue
………vim自带的这一部分就不帖了
endfunction

vim

    最近忽然又有些想玩玩Linux了。
    我总是觉得做JAVA开发如果不懂Linux,实在有些说不过去。
    以前就在论坛听人说suse不错,朋友也说这东西好像不错的样子。
    呵呵,3.6G。慢慢下。只要不要再象上次一样下了一半就挂了就好。
 
    昨天去下了个号称地球上第二强的编辑器,Vim(最强的是emacs)。Vim好像不算太糟糕的样子。有中文界面,而且还可以下到中文的使用手册。
    其实我对编辑器的要求很低。启动速度快,有查找功能和语法高亮就差不多够了。只是最近忽然想BT一下,也当是熟悉Linux下的工作环境吧。(为什么不用emacs?我还不够BT
    最初是用NoteXpad。这东西功能和windows的Notepad差不多,主要是多了个工具栏,使用起来比较方便一点。NoteXpad号称全汇编写的。不过好像汇编不太值钱,程序的问题还不少。估计没有使用内存映射,打开稍大点的东西就有点吃力。还好,一般没谁会起用写字板打开太大的文件。
    NoteXpad最初的版本不带语法高亮,在后来的版本中加入了语法高亮,不过bug比较严重。不是几乎,而是根本就没法使用。
    后来朋友推荐用Notepad++。这东西很早就见过,不过当时没太注意。这东西用C++开发的,启动速度还不错,而且语法高亮的默认配色方案比较适合我的胃口。NotepadX就这样逐渐的被我给淘汰掉了。
    现在是Vim。Vim强归强,但对于象我这样习惯了windows下开发的人来说多少还是有些不习惯的。打算先看看手册,将Vim配置得符合点我的习惯再说吧。
    Vim,有些期待。直接在编辑器里写些简单的脚本,实现文本的格式化。我还是有这样的需要的。

appfuse generator的编码规范

一些IDE生成的注释没有删除就把东西发布出来,这我都可以原谅。但代码居然连最基本的缩进都没做。你写代码的时候不愿意话时间去规范代码也就算了,难道你连给代码做个格式化都不愿意?
真为appfuse generator感到汗。

Ruby vs Java? and appfuse

    《新技术倍出 谁最可能挑战Java开发优势》,感觉挺恶俗的一个名字。不过既然要圈钱就得制造点事端,制造点热点。一个东西不管好不好,有人理就是好事。

    JAVA,为什么又是JAVA不是PHP、ASP。因为JAVA红,俗话说人红事多。现在的新人为了吸引眼球总得拉个大腕作幌子,就象前一阵子天涯上的猫人。JAVA,因为JAVA红。

    又是Ruby,又在CSDN上看到关于Ruby的帖子。我一直都承认我对脚本语言是存在偏见的,而且固执己见。

    Ruby可能流行吗?可能。 Ruby能挑战Java吗?表示怀疑。

    JAVA其实可以更简单,JAVA目前的这个局面更多的是因为厂商利益。在Ruby开始威胁到JAVA的时候,JAVA可以变得简单起来。而且在提供方便性将在一定程度的限制功能。有时候,一个东西完善的过程,也是一个复杂化的过程。我觉得Ruby应当是这样的一个东西。最重要的一点,Ruby的定位和JAVA不一样。JAVA定位相对比较高一些。要抢底盘也是抢PHP的,JAVA受到的威胁相对要小一些。

    又想到了APPFUSE。APPFUSE一个不错的集成框架。而且自身带的代码生成器使用也很方便。只要写完VO并为VO写上XDoclet的标注后,直接运行ant命令就可以自动完成数据库的部署并将包括表示层的所有相关代码生成。完全一站式的代码生成。

    既然APPFUSE如此完美为什么没有广泛的流行起来?

    Appfuse基于脚本的代码生成,对细节封装得不够(或者说隐藏吧)。虽然完全按照Appfuse的预定流程来作很方便,可以实现对开发细节的隐藏,但在大多数情况下大家都需要对框架进行扩展来实现自己的需求。既然要扩展,你就必须要了解框架的具体实现细节,而appfuse使用的技术N多。如果要熟悉还是得花些时间的。

    说到这里可能很多人要说到JAVA的复杂性了。对,JAVA很复杂,但同样也可以很简单。虽然技术多,但并不不代表你要了解的东西要很多。技术是用来简化开发的,如果一个新技术的出现反而使开发复杂化了,那这个技术是不值得采用的。在appfuse中采用的新技术都是有其价值的。appfuse缺的是文档。不光是appfuse的文档,还有appfuse所采用的技术的相关文档。这些文档不需要很复杂,只要那么一两页纸告诉框架的使用者这些技术是用来作什么的。对于这些技术只介绍必要部分,暂时用不着的都不用讲,尽量简化(隐藏)框架的复杂性。

    appfuse中大量的使用了ant脚本来实现自动化。但也正是由于过于依赖这些脚本,导致框架和IDE的结合不是很好。到目前我还不是很清楚怎么用IDE对appfuse进行调试。虽然这很可能是因为我对appfuse的研究不够,但对于一个以方便为目的的框架,不应该将和IDE的整合交给框架的使用者去作。

    还有就是appfuse的那个权限系统实在是让人有些不爽。不同系统对权限系统的要求都不一样。权限系统这一块本该是可以灵活配置的,可以很方便的从系统中移除,自己实现。但appfuse的权限系统和框架绑这么紧,要分出去多少还得话些时间。

    说了这么多appfuse的“坏话”,不过还是希望appfuse能快速成熟起来。对appfuse来说功能不是问题,最大的问题是人性化,JAVA也是这样。

 

PS:最近看到appfuse有个代码生成器的子项目appfuse generator。用Velocity替代xdoclet作为模版生成引擎。刚开始研究,还不清楚和appfuse里面集成的代码生成器相比有什么优势。

新版本的appfuse集成了一个缓存系统,有时间可以研究一下。

eXtremetable

    翻页天天写,忽然想,是不是该将翻页写成个jsp的标签。标签这东西从来就没写过,虽说写起来应当也不会难,但以懒人的原则出发,如果有现成的当然就用现成的了。
    DisplayTag,一个不错的翻页标签。可以说DisplayTag什么都好,就是性能很是个问题。DisplayTag每次查询都是将所有纪录都进行一次查询,这样对付小数据量的查询还可以,数据量一大就差不多可以挂掉了。
    ValueList也是一个比较常用的翻页标签。看了一下demo,感觉功能不错,就是默认的风格比较土。当然土不是问题了,只要稍微修饰一下就可以了。ValueList功能强是强,只是有些太强了。ValueList提供了从数据库提取数据到界面显示的全部流程。这样必将导致ValueList使用的复杂性,而且我更喜欢拥有更多一些的控制权。
    然后看到有人说eXtremeTable不错。看了一下demo感觉还不错,界面还挺漂亮的,而且可以在翻页的时候只取出当页的数据。不过问题还是有的(看来完美的东西都是不存在的)。翻页的风格无法修改,且翻页功能比较弱。只能实现 上一页、下一页、第一页、最后一页 这样的简单翻页,如果页数过多的话使用起来将很不方便。
    到官方论坛去看了一下,果然有人和我有相同的需求。不过作者暂时还不打算实现该功能。作者说该功能的需求比较小,还有更多更重要的特性要添加。不过作者也说了,如果需要可以自己对标签进行扩展。eXtremetable相比其他的翻页标签来说更关注的不是功能的实现,而是一个良好的扩展性。所以即使自己对eXtremetable进行扩展应当也不会是一件很麻烦的事情。
    今天在IBM中国看一个关于代码生成器的网站http://www.codegeneration.net/,里面有很多关于代码生成器的东西很全。如果你是一个代码生成器的编写者,在这里你可以找到很多关于代码生成器的知识。如果你只是想找个代码生成器用用,这里也不会让你失望,在里面你可以找到各式各样的代码生成器。

OOP程序设计实践

·简介(开发中)

前言
    phoenix,浴火重生的凤凰。和她的名字一样,这个版本的热键助手是一个全新的热键助手。虽然她“长得”和以前的版本差不多不过她已经实现了程序的全部重写。
    应当说phoenix版本是“热键助手”的降级版。在以前开发“热键助手”的时候,按照自己的喜好加了很多功能。然而在实现了这些功能以后,却发现真正使用这些功能的人其实并不多。这次开发的出发点是实现基本的功能,在用户需要时再根据具体情况添加。
OOP
    其实这次重写“热键助手”主要是对OOP的实践。在以前写程序的时候总是喜欢把不同的功能放到不同的单元中,把不同的功能放到不同的函数中……。当时感觉这样写程序就已经很帅了,但始终感觉没有摸到OOP的门。然而就在最近开始有点OOP的感觉了,于是决定将“热键助手”进行一次重写。
    重写的过程中问题还是不少的。
    在设计的过程中颗粒细度始终很难把握。因为是初次使用OOP的思想来做程序,在划分模块的时候经常“狠不下心”,老是希望把颗粒划分得比较细,舍不得将颗粒画粗点。不过根据XP的说法,不应当在程序设计的初期把程序设计得太“完美”,因为你的能力会在设计的过程中提高的嘛。一些东西以后做也许会做得更好,而且现在计划的很多东西在以后可能会变得毫无用处,为什么要浪费这么多的时间来做一些无意义的事呢?而且只要前期的设计不要做的实在太烂,在后期还可以比较方便的使用重构来改善程序结构以适应需求的变化。
程序具体结构(还没完成)
    下图就是程序的类图,因为还没真正完成所以在最终实现的时候应当还会做写修改。
    下面还是对程序的结构进行一些讲解吧。(其实类图提供的信息已经蛮详细了)
    TvxShortCut类对热键(TvxShortCut)进行统一管理管理。在TvxShortCut有一个TvxSettingMgr的引用,通过她来进行对设置文件的操作。TvxShortCut应当是一个抽象类(目前还不是),因为她没有和界面打交道的代码,她的界面相关部分将在子类中实现。
    TvxSettingMgr用于实现配置部分的功能。其实可以将其设计成一个接口。其具体实现可以由TvxXMLSettingMgr等实体类来实现。不过目前还没有采用其他配置方式的想法,所以先这样做吧,等到有必要的时候再考虑重构。
    TvxShortCut用于实现热键的注册和卸载等功能。TvxShortCut应用TvxScript执行热键操作。
    TvxScript对脚本进行分析,并调用TActionFactory来构造一个TvxAction接口的类来执行具体的脚本。(我觉得TvxScript这个类好像有点小问题,但具体怎么改还想不到,所以先这样用吧)
    TvxAction执行热键的具体操作。这是一个抽象类,她的具体实现在她的子类里实现。
    TvxMenuAction类,实现了IvxMenuInterface接口的Action类,可以将其添加到Menu上。这也是一个抽象类。
    TvxOpenFile类,TvxMenuAction的子类,用于具体实现打开文件的操作。
    IvxMenuInterface接口,添加到Menu的接口。
    TvxSubMenu类,有子菜单的菜单项目(分隔符也算到这里面,反正是和Action无管的菜单项)。
    TvxMenuMgr,具体将实现了IvxMenuInterface类的接口添加到菜单上。

    差不多就这样了。因为我也是OOP的菜鸟,设计方面还是很菜,而且自我感觉上面的类图还有不少问题,如果大家有什么好的建议欢迎指出来。
   

点击察看大图

类图(点击察看大图)

备注
    在设计的时候我也一直在象,我是不是将问题复杂化了。不过OOP的第一步始终要走出去的,所以就算是再硬的核桃也要将其砸扁。
    顺便祈祷这个程序可千万别夭折了,就算是再烂也还是写完先。(在接下来的一段时间里工作会很忙,不知道什么时候可以将程序写完)。

 

发表于 @ 2004年10月

//——————————————————————–

PS:

    很久以前的东西了。最初是放在我的个人主页上的,不过我的主页空间到期后就没有继续维护了(两年过得可真快啊)。这篇文章在CSDN也有,不过CSDN的blog在发完这个文章后就已经没有进行维护了。CSDN的blog上总共也就只有这一篇文章,差不多也算是废了。想想我还是很少写技术文章的(妖言惑众还是比较多的),这个文章虽然说写得不怎么样,但多少还是有点回忆吧。OOP走火入魔的回忆,当然这个走火入魔更多的带有一些刻意。 爱爱过才知情深,醉过才知酒浓。只有有过走火入魔的经历才能将问题看得更透彻。

    程序也早就完工了,不过最后的结构和上面的类图有些不同。

    程序的最新版本和以前的发布版本相比有些小改动,而且修正了一些内存泄露问题。只是中文版的程序在一次意外硬盘灾难中丢失了。E文版的还有,不过帮助只E文化了一半。现在程序的帮助还是一半E文,一半中文的。是否考虑那天将剩下的帮助也E文化后发布个E文版的?

    不知道怎么将MSN上传的图片插入到blog里,而且上传的图片会显示在“我的图片”里,不是很美观。所以文章中的图片是在网上拉的别人家,图片什么时候实效我就不清楚了。

打算再玩一个月的Delphi

    总是觉得JAVA实在是有些枯燥。面对JAVA,你需要不短的去熟悉那些所谓的新技术和那些所谓的框架。一通百通?通了有个鸟用。熟悉很多时候不是通不通的问题,差不多是纯粹的苦力活。反正我是试图慢慢的让自己专注起来,不再去过多的关注那些所谓的新技术,把关注的焦点放到框架的整合上面。
    APPFUSE是个不错的东西,他引入了不少新技术,而且做了一个还算不错的整合,而且还提供了一个简单的代码生成器。不过如果直接使用APPFUSE进行开发还是会存在一些问题的。比如在APPFUSE中的权限控制部分和框架整合的过于紧密。但对公司目前的项目来说APPFUSE带的权限控制模块还不是很符合要求。在页面的表现部分,APPFUSE是用CSS对页面进行装饰来实现表现层和功能的分开。技术是不错,不过着对CSS的要求有点高。要实现所有页面都使用CSS进行装饰技术难度有多少?呵,我对CSS不熟不好估计,而且我从来都对脚本语言存在着一些偏见。表现层这一块肯定是要进行剥离的。除此之外APPFUSE在一些问题的处理上本来就不是很好,需要进行部分的修改。
    APPFUSE带了一个代码生成器,还算是简单实用的。不过在我看来从VO提供的信息毕竟不够完备,如果从VO开始实现一个完备的代码生成过程似乎还存在着一些问题。在我看来,进行代码的生成最好的办法就是从自定义的XML文档开始。因为文档是自己定义的,所以需要哪些信息你可以自由的进行添加。
    代码生成器,在以前玩python的时候写过一个简单的。完成了从配置文件生成VO、文档、以及数据库安装脚本。再由XDOCLET生成hibernate的配置文件。不过由于在开发的过程中遇到了点小问题,加上对python的兴趣减退(开发这个主要是为了玩python)就没继续开发了。
    代码生成器的理想情况是可以由模版生成页面,数据库脚本在生成后可以选择自动安装。程序的相关代码也是完备可以用的。程序的相关配置文件也是要全部配置好的。总之就是写好配置文件,然后你就不用动手了。呵呵,听上去似乎有些恐怖。不过对于简单的添加删除操作来说,编程本来就是一个体力活而不是技术活。
    YY了这么多东西,不过就目前而言我还有几个简单的问题都没有处理完。比如spring和hibernate整合的事物控制。hibernate的那几个对应关系等(感觉对应关系的处理不会很难,但一旦没处理好,很容易出性能问题)。
    虽然JAVA方面还有怎么多问题没有解决,但我还是打算先再玩一个月的Delphi了。在公司一天到晚的对着JAVA难免有些厌烦。况且我本来就更倾向于Delphi。如果从刚接触Delphi开始算起已经有超过4年的时间了。虽然Delphi已经有日暮西山,虽然Delphi已经开始win32向.net转变,不过我依然喜欢用delphi进行win32下的开发。不知道是不是用久了就成了一种习惯?
    呵,虽然delphi玩了蛮久的,不过在工作中用delphi开发的时间却不算长。
    不管怎么说,再玩一个月的Delphi,把那些该解决的问题解决(本来早就该解决了的,计划不如变化啊)。