2006年02月13日

个人四金在工资中的构成:(假如工资600元/月)
养老保险金=工资×6% + 工资×25.5% =600×6%+600×25.5%=36+153=189
医疗保险金=工资×1% + 工资×5.5% =600×1%+600×5.5%=6+33=39
失业保险金=工资×1% + 工资×1% =600×1%+600×1%=6+6=12
住房公积金=工资×7% + 工资×7% =600×7%+600×7%=42+42=84
除去四金后的工资=工资-所有的个人交纳相加的和


            个人交纳比例 单位交纳比例
养老金        6%           25.5%
失业保险金   1%              1%
医疗保险金   1%              5.5%
住房公积金   7%               7%

2006年01月19日

今天看到了博客园的这篇文章:细节-质量-态度
摘一段如下:

来看看一个TextBox可能涉及到的测试项,下面所列出的测试项,在实际项目中数目还会有更多,有几条也可以合为一个
,但一般的项目都会涉及到:
1.      是否必输
2.      输入长度限制是否正确
3.      特殊输入类型的检查是否正确
   l         数字 :位数正确吗?
   l         Email:是否有效
   l         货币:小数位,四舍五入正确吗?货币类型?
   l         电话:格式化正确吗?
   l         小数:小数位数正确吗?
   l         名字:如果是老外的名字,首字母大写
4.      Tab键顺序正确吗?
5.      颜色表示正确吗?(有可能分为必输项,非必输项,当前输入项)
6.      文本框长度和数据库中长度对应吗?
7.      输入的长度不足时是否自动补位?
8.      初始化时焦点的设置正确吗?
9.      初始化时Enable属性设置正确吗?
10.  初始化时的内容正确吗?
11.  当界面上进行其他操作时,文本的Enable属性设置
12.  文本框命名
13.  如果有回车替换Tab,是否正确
14.  是否可以多行
15.  字体设置正确吗?
16.  Text属性时对空格的控制(Trim)正确吗?

但是大家可以算算这样一个界面,只有5TextBox,但是在TextBox处理上隐含了多少个bug50个?太多了,取一半,25个。
现在把添,删,查,改加上,再算算,这样一个简单的单表维护界面上就隐含了多少个
bug,保守点也30个!要达到50也不是没有可能的。
如果我们再加上一些其他的
CheckBoxComboBoxListBox什么的,编辑查看附件,发送什么的附加功能,测试点会膨胀到什么程度?

这个问题在数据库操作的企业应用软件中特别普遍。我们的软件在开始阶段出现的也大多是这类问题。如果有一个问题没有测试出来而在用户那里出现了,这时程序员会推卸责任,测试人员觉得冤枉,总之这种低级错误让人不爽。

问题在哪呢?是在于对细节的态度吗?

关于细节的重性,我们已经非常重视了。但人总有疏忽的时候,不能指望一个人总是不犯错。

问题在于没有一个良好的机制,一个注重细节检查的机制。让自动化的、预先检查的机制,来代替成本非常之高的人工检查。

一个很好的、行之有效的解决办法,就是“验证控件”。把原来程序员要单独的、一个一个去检查的控件,封装成一套完整的、带验证方法的控件,把保贵的程序员的精力解放出来。

比如,我们可以做字符串控件,有个最长值的属性;可以做数值控件,只能录入数值,这样程序员取得的值直接是数值而不用再手工转换;数值控件也有很多种,整数的,小数的等等;email控件、phone控件、日期控件等等。

做控件的时间是可控的、很少的;而在有繁杂界面的企业应用中,一套这样的控件可以节省的测试人工成本、避免出错的带来的经济损失是非常有用的,收益是永久的。一套控件可以用在其它的案例中,收益更是长久的。

我看到过的一些web framework,无不把控件的值校验功能放在核心层面,这样做也已经证明是非常成功的。哪些?Ruby on Rails!TurboGears!Java下的一些大的筐架。

.Net下面为什么没有?等着你自己来做呢。微软可没有这个经验。看了原文后面的评论,感觉还是有很多还没有意识这个问题的根本。还在争论什么面向对象编程、面向过程编程,希望多“想些实际问题,少谈些主义”。能解决问题的方法,就是好方法。

再补充一点:不能把所有的事情都丢给测试 人员。测试人员的时间、精力也一样是有限的,测试本身也不是万能的。如果软件质量不好,统统怪测试人员,那样一方面解决不了根本问题,程序员该犯的错还是会继续犯;一方面还会在公司内部造成测试与开发的对立,测试永远低开发一等,这样不利于良好的团队合作精神的养成。

我是项目经理,我一向的观点是,不能把保证软件质量的担子全部落到最后测试的身上。软件质量的责任是整个小组中每一个人都应该承担的,每一个环节都应该重视的。

2006年01月18日

车东这儿看到的:


一定得选最好的托管中心
全套Cisco的网络设备加SUN的服务器
建就建最酷的用户体验
免费注册帐户
每个帐户存储空间最少也得两个G
什么AJAX呀、Tag呀、Rss呀
能给他整地全部给他整上
社区附带一个VIP区,有牛人7×24小时蹲点帮你解惑
Blog上常驻一个叫Keso的家伙
留小辫儿,特大牛的那种
只要一打开页面,甭管有事没事都得用Skype跟人家说
“你丫赶紧给我注册!”
一口地道的京片子
倍儿有面子
网站里还要建一个wiki系统
全部翻译自维基百科
每天翻译量起码百兆计算吧
再建一个站内搜索
支持所有内容全文检索
文本呀、RSS呀、Blog呀,你要搜什么我给你找出什么
就是一个字——快
全站搜一次才用0.00001秒
在这里注册用户的不是CEO就是网络精英
你要是分不清Blog和WebLog
你都不好意思去TrackBack人家
你说这样的网站,VC会投多少?
我觉得怎么着也得两千万美金吧?
两千万美金?那是成本
四千万美金起
你别嫌贵,我还挑东家呢
你得研究VC的投资心理
能掏起两千万的主儿
根本不在乎再掏两千万
什么叫Blogger,你知道吗?
Blogger挑服务商都用最2.0的,不用最好的
所以,我们做web2.0的口号就是:
不求最好,但求最2!

桃花坞里桃花庵,桃花庵下桃花仙。
桃花仙人种桃树,又摘桃花换酒钱。
酒醒只在花前坐,酒醉还来花下眠。
半醉半醒日复日,花落花开年复年。
但愿老死花酒间,不愿鞠躬车马前。
车尘马足显者事,酒盏花枝隐士缘。
若将显者比隐士,一在平地一在天。
若将花酒比车马,彼何碌碌我何闲。
别人笑我太疯癫,我笑他人看不穿。
不见五陵豪杰墓,无花无酒锄作田。


 


从这个听相声的QQ群里看到的。以前老记不全。


一群喜欢相声的人在里玩得可欢了。群号:207184309

走过了delphibbs,
走过了codelphi
走过了csdn


也走过了delphi/C++ builder
走过了Borland
身边的人们纷纷走向了不同的地方


身后
小草繁茂
绿树荫荫
凡花点点


 


我诌了点了上面的东西。也算是曾经的一段岁月的回忆吧。


写于韩磊在忆CoDelphi一文的尾巴后面。不过,不小心把自己的blog地址写错了。


其中谈到了大鱼儿,我记得这家伙是在搞codelphi.net的blog系统时知道的,那时也用的是.Text的系统,还和博客堂开心就好为了汉化版.Text抄袭问题打过嘴架,现在还不忘记寒开心MVP一把(”至于所谓的MVP,那是什么玩意?”)。


咳,都是曾经年少啊!

几天以来,CherryPy的2.2.0beta一直在更新,但是Kevin Dangoor一直没有出新的egg版本,ez_setup.py又不会自动装上2.2的,所以新的TurboGears总是用不了。


今年下午有点空,想继续做自己的todo小项目,就想着自己build它的egg。


看了install_tools的文档,还是没有看明白,我觉着写得就不算很清楚。那个build的命令就是不成功。


后来在CherryPy的svn目录下面,看到了一个make-sdist文件,没有扩展,凭直觉应该是一个linux下的脚本,打开看了一下:


rm MANIFEST
python setup.py sdist –formats=gztar


这个python setup.py sdist –formats=gztar 会不会可以用呢?


试了一下,真的开始了打包。不过,最后却没有成功,为什么?提示说没有tar这个程序。原来如此。我手工把压缩成zip包,再改成egg后缀。


easy_install XX.egg一通安装,没有报错。不会这么简单吧?


打开安装之后的文件夹一看。果然问题多多。除了目录又包了一层外,少了一个egg-info的目录,包信息不对头。没有关系,对照着cherrypy.2.1.1.egg的目录改。



  1. 先把老的egg-info目录完全复制过来,再拷贝新的PKG-INFO文件过来替换老了,就是这个文件里面写着重要的版本信息。其它的文件没有关系。
  2. 再把包了一层的cherrypy模块目录移上层,也就是移出来。
  3. 最后,删除不必要的目录。

不放心的话,到easy-install.pth文件中检查一下注册的入口是不是这样的:


c:\python24\lib\site-packages\cherrypy-2.2.0beta.egg


再运行我的todo,一切正常。


不过这是土法。正当的法子是什么,我还是不清楚。文档里面没有讲清楚。

实际的业务系统是一个动态的系统,会有动态的人员、岗位设置,是根本不可能用脚本解决的。


一开始根本就没有考虑到这一块的问题。现在发现在脚本中根本无法定义权限。并且权限根本是不可以在脚本中定义的。


在一开始的设计中,就要考虑到权限。实现上并不高深,最简单的令牌机制就可以解决了。调用某功能时,先检查一下有没有此令牌。给权限的过程,就是一个给令牌的过程。


以前的那个系统的权限功能,真叫一个烂字!后来基本上推翻了又重写。这个“平台”估计是一样的命运,一定会返工作大幅的修改的。


光是实现一个O/R map机制,一个UI,再一个弱弱的工作流系统,就做了2年半。


NND说了N年的分层,现在才想到必须要做。一帮撞了墙才知道路子不对的人。


算了,不说了。技术的事不管了,市场销售多跑些。找一些做不了的项目回来,再挑明。现在还不是时候。上面的人都知道是怎么回事,都不愿讲,因为有XX在上面顶着。现在只是把我放在这儿当枪使。

2006年01月16日

软件开发人员一向有做大而全、赶英超美的习惯,号称我们要做一个比XX软件先进多少的系统,从架构、功能、界面各方面打败它。然后就开始西里华拉的写代码了。


做出来了一看,问题多多。最大的问题是,我们做这个系统到底是为了什么?就是为了“超过XX软件”吗?老板钱多的烧得慌。


我们的系统要解决什么问题?不知道,XX软件有什么我们就做什么。


架构师回答不上来。只是不断的说,在XX功能上,我们要比他们强;在XX功能上,我们很灵活,可以自定义;在XX功能上,现在比他们弱,但是再有半年,一定比它强。。。


一切都停留在软件的模仿和抄袭上。而忽略了软件的主体:用户的需求,用户的体验。


以这种赶英超美的心态做软件,是做不好的。与XX软件的区别,不在架构,不在技术,不在界面,不在功能,只在用户的使用细节上。


我们没有详细的、亲自的分析过用户的需求,不知道用户到底需要什么样的用户体验,甚至软件的设计者自己都不曾经使用过自己写的软件超过一天。所有的需求都是copy过来的,并且走样了。


细节,统统被忽略了。就是这点区别,我们与XX软件的差距何止5年?


举个实例:我们也有自己做的一堆UI控件,很漂亮,很cool。但是有个细节就没有注意到,数字控件不能输入全角的数字、不会自动的把全角的句号转换成小数点。考虑到我们的用户群都不是电脑使用水平很高的,都是年纪比较大的,全角半角分得不是很清,界面上很多地方要输入汉字,再要输入数字时就要切换。用户一天可能有上百张单据要录入,非常麻烦。


这个用户体验有两种办法解决。一种办法是遇山开路,输入的全角数字自动的转成半角的,在全角状态下把打的“。”句号自动转成小数点。


还有一个更好的解决办法,微软老早就注意到了,就是在指定的控件上打开、关闭输入法。用过office的用户特别是access的用户应该深有体会,在录入数字的地方,自动把输入法关掉,在录入文字的地方,再把输入法打开。这个用户体验一下子就好起来了。


XX软件采用的是第一种办法,也够了。


细节非常重要。一定要引起设计者的充分重视。用户眼中的“好用”,不一定就是设计者眼中的“cool”。用户总在说我们的软件不好用,并不是因为什么很了不得的、石破天惊的、神密莫测的原因,原因就在于这些细节,我们没有考虑到。

记下软件开发过程中出现的问题,解决方法,及经验教训。


动态的树形控件折叠效果


 


有一个自家人做的格子控件,外加一个树,用来操作目录的层级。如果有下一级,那么这一级的最前面就会出现一个+号按钮,点它就会在当前级格子的下面增加格子显示下一级的所有内容。再点这个+号按钮,就会删除下级格子,只显示上级。



关键就是在这个展开、折叠效果上,他们过度设计,把这个界面动作搞成动态的了,有个动画的展开、折叠效果。这只是其一。



其二,折叠时,会从打开的最下一层开始折叠。比如最下一层是第5层,这时想把它折叠成只显示第一层,这会老大会先折叠第5层,再折叠第4层,再一直下去,直到第一层。



想法太简单直白了,只会一层层搞。并且那个变态的、完全多余的动画效果,加剧了它的可笑程度,如果你先把所有的目录层级全部展开,光标定位到最后一个并且是最下层的记录,再点“全部折叠”按钮,你会看见,动画片开始了:先折叠最后一个记录的,从它的最下层开始折叠,再是倒数第二个,从最下层,再….不想再说了。



最有效率的办法就是在内存中直接只显示第一层内容,清空原来的DC,再把新的画上去。结了。搞那么多飞机,一层层的折叠!?还动画?



如果有100个记录,每个下面有5级,这个过程就要持续很长一段时间。界面没有反映,用户在那里只能看动画片。



算是开了眼了,没有见过这么愚蠢的。这个程序员可是有5年经验的C++程序员啊!



总结:再怎么会玩弄技巧程序员,不会高效的解决真正的问题,那这个人也不是一个合格的人。

2006年01月12日

这里看到的。


egoSurf就是这样一个简单而又好玩的工具,只要输入你的名字和你 Blog的地址,就可以知道你各个搜索引擎上的名气究竟如何。egoSurf的原理是在搜索引擎中搜索你的名字,然后查找属于你Blog的内容在搜索结果中的排名。egoSurf还支持搜索结果的RSS输出,可以给热衷ego surfing的Blogger一个更方便的途径。


看了一下,我的pynux排在google的465位。


那一段图片链接发不上来。删掉了这篇文章才发成功。