| Water's profileMerlinBlogLists | Help |
|
August 31 项目未动,文档先行专家做项目,和小工不一样的地方就是,万事谋后而动。我从老外那里学到的最好的东西就是:在动手干大项目之前,一定会先把外围的、或者核心的工具准备好,事先想好怎么可持续开发、怎么样维护成本最小,文档计划是什么样的,怎么定义一种很顺当的做项目的套路。能不hard coding的一定不要hard coding,能用工具自动维护的一定要用工具去维护。开发正式产品之前一定先去构造tool chain,等tool chain稳定了才开始动手开搞,所以你会发现老外一开始做项目可能比中国人慢,可是迭代几个版本之后,立刻拉开了和中国人的差距。 举个例子,拿电信里面典型的OM scenario来说,中国人一上来噼里啪啦对着接口和消息字典(通常是ASN.1语法定义)一顿狂写,代码写的又快又好,实现scenaio的速度无与伦比;德国人一上来却不写scenaio代码,而是去构建一个工具小组,先去写一个编译器,自动分析接口和消息字典,自动生成代码可用的消息定义,可能,这项工作做好了、稳定了,中国人那边全部工作已经做完了。但是,接下来事情慢慢就会发生变化:下一版接口变动的时候,消息定义发生变化的时候,中国人不得不深入到那些充满“奇技淫巧”的代码中去改那些变化的部分——德国佬呢,只是简单地重新run一遍tool chain而已,程序主框架几乎没有变动。好比说,德国佬的软件系统是线性维护的,而中国人的软件系统是指数维护的。 当然,随着越来越多的研发中心转移到中国,国人学到了越来越多的工业化开发套路、方法,情况也在慢慢发生变化。西方沉淀了几十年的系统开发精髓也慢慢被国人体会、咀嚼、消化,我们也做得越来越好。(为什么说经验很重要?为什么很多时候我们招人更看重正规企业中得来的工作经验?我们没办法相信你手工作坊+游击战的实力,没办法相信你可能是确实非常强的个人能力,但是我们相信正规可靠的工作经验) 废话少说,来看看django的文档系统。 We've put a lot of effort into making Django's documentation useful, easy to read and as complete as possible. Here are a few tips on how to make the best of it, along with some style guidelines. (Yes, this is documentation about documentation. Rest assured we have no plans to write a document about how to read the document about documentation.) 在开发代码之前,先定义文档系统;在开搞文档之前,先定义文档方面的套路;在让你开始读文档之前,先给出如何读文档的文档——documentation about documentation。。。。。。在RoR已经大行其道的今天,作为后来者的django如何吸引开发者的眼球?如何站到web framework的主流中?当然首先需要让用户及其方便的读文档,千万别因为文档上的挫折感而转投他人怀抱。 (肚子饿了,回头再续。。。) August 28 巨亏Message
今天亏大了,天气异常的热,起床的时候还不觉得,空调吹得我还有点鼻塞。兴高采烈套上短裤,背上本本,出发了。走了不到10分钟,发现TMD巨热,跟前几天走路的感觉不太一样。
走到单位,衣服全湿了,满头大汗,秋老虎,你厉害!
不过挥汗之余,庆幸又坚持了一天,好,好。
August 26 乱逛之一http://too.yupoo.com 这人最让人佩服的地方就是,毅力。 每天都那么不厌其烦的做出无数饭菜(实话,挺专业的),而且,还不厌其烦的拍成照片放出来。。。 八过,看得我那个馋啊。。。 August 23 Qooxdoox releases version 0.6 RC1Message
Qooxdoo (pronounced “cooks-do”) has released version 0.6 RC 1. This framework has come a long way since our first post on it over a year ago. Qooxdoo is a LGPL javascript framework with a rich set of widgets and supports namespaces, events, drag and drop, and layouts. For a quick look, check out the demos (particularily the “at-a-glance demo”), or go straight to the download page. Details on this release:
Does anyone have some real world experience with this framework? Maybe some comparisons to Dojo or some of the commercial toolkits? 一日健身行Message
烈日当空,又若清风徐来,挥汗如雨,又若神清气爽;
徐徐踱步向公司,隆隆急行驰车马;
路况险且急,灰尘杂且高,然渡闹市如旷野,心底无私天地宽也。
体察市井之民情,感慨人生之艰辛;万千杂念心头过,却向闸北一意行。
步行三刻至公司,晨钟数响到班车,众皆目睹衣衫湿,饥肠辘辘我自知。
衣带渐宽终不悔,终不悔。
强身健体,又岂在朝朝暮暮!
(今日步行上班,至公司自我感觉甚好,特资纪念)
August 21 javascript看了几天javascript,觉得有点怪怪的。这东西,正在重走java的路子:客户端的MVC模式、异步 IO概念、Dojo的包机制,还能依稀看到lisp、python之类的影子——动态语言,函数式编程。。。而且,ajax客户端的framework现在满天飞,战国群雄四起,IBM、Adobe蠢蠢欲动,微软那厢立刻搞个express免费,唯恐atlas败下阵来。 LAMP吸引了太多人(特别是自以为技术很好的)的注意力,IE的狂妄自大、协议污染战略搞得天下英雄个个生出逆反心理,加上谷歌的横空出世才造就了ajax的流行。 看了半天django,服务器端没有直接支持ajax的framework,没有RoR那么眩目多彩,不过最近号称把dojo作为official的ajax支持,也算跟上了潮流。 不知道哪位资深架构师可以预测一下未来ajax的模样? 忽发奇想之二Message
大概是去年的时候,公司的一位老杆子走了,临走之前给我们做了个seminar,谈了一些工作的心得体会。
其中比较精辟的一段(之一)大概是,世界上的事情分为两种:科学的和艺术的。
对于打工者来说,科学的东西,也就是俗称的技术,是可以被复制、传承的,也就是说可以被替换的——就算你做到首席科学家、架构师,也是一样。越是大公司,越注重如何做到技术人才的可替换性。不信我们研究一下各自公司的政策、制度、流程——我们公司里,技术是以文档的形式存在的,无论做什么开发,文档是第一位的,从开始写文档到最终release,一路不停有人review上来,不停审核,不停挑战你,不停地让你的先进思想慢慢腐化,渐渐变成俗人也能操作、理解的程式化东西,虽然你最终成了大拿,成了架构师,可是你慢慢也就失去了不可替代性。甚至代码这种我从前认为很“艺术”的东西,公司也规定了严厉的流程,经过多级review,code
reading,相互challenge,最后也慢慢变得同一化、标准化,到后来形成一种思维模式,如果不可迅速被理解、复制、改动,就是写的不好的代码。
当然,公司也就降低了人才流动引发的风险,于是,你离职也就无伤大雅了。
李开复在《做最好的自己》中说,微软有十几个副总裁,盖茨对这些VP的基本要求——同时也是最严厉的要求就是——在任何时刻都必须做到一个副总裁离职了,立刻就有另外一个副总裁作为backup接替工作。
看,就算是这些身居微软VP的家伙,也不能避免互相备份的命运。
还有另外一种,自然就是艺术了。
什么是艺术?弹钢琴的是艺术,写诗歌的是艺术,教书育人也是艺术,成天谈天说地的也是艺术,欣赏是艺术,被欣赏也是艺术,灵气、情感都是艺术。。。。。。所有这些,都是不可复制、不可copy、不可backup的,没有办法做到批量生产、批量复制,就算是双胞胎,做一样的艺术的事情,也会有不一样的结果。所以,如果你的价值在艺术范畴,那就和科学大不一样了。
回到我们亲爱的IT公司里面,什么是艺术呢?管理是艺术(我是指管人),做人是艺术,处理客户关系是艺术。。。。。。这下,该明白为什么我们认为智商低下的、顽固不化的、奸诈狡猾的那些人却得到了比我们更好的回报了吧?
因为他们靠艺术在公司里生存,真的是艺术,换你这个技术天才去却做不来的啦。回想一下各自公司里面的情形:经理们成天琢磨着怎么提高你(技术人员)的科学性、技术性——其实却在降低你的艺术性,换句话说,降低你的不可替代性;销售人员整天忙着用公司的经费去贿赂客户,增进私人感情——其实是在提高自己的艺术性,也就是增强不可替代性;老板从早到晚想着怎么平衡几个部下,大玩特玩权术——其实是降低他们的艺术性,减少自己对特定艺术人士的依赖性。。。。。。
仔细想想那些拼命在大公司打拚的成功人士,他们是怎么走上成功的?有两种典型道路:
1)走管理路线,最终到什么CXO,显然,这是艺术的道路;
2)先走技术路线,做到最精、最好,然后出来自己拉个公司、拉个风投,变成自己搞,或者直接到小公司做个合伙人、CTO之类。这样子实际上是把在大公司积累的科学性转化为大公司之外的艺术性,在第二个地方找
到了第一个地方所没有的不可替代性。
既然微软的副总裁可以相互backup,为什么盖茨对李开复的离职大为光火、要闹上法庭?那决不是因为李开复的科学价值的不可替代性,而是他艺术价值的不可替代性。李开复在华人学子心中有无比的号召力和形象价值,这种艺术价值是微软没办法copy的。 在我们的生活中,什么是科学的,什么是艺术的,确实值得玩味、思考一番。 August 18 w3c技术架构介绍-留个纪念w3c技术架构介绍
作者:阿宏 2006-2-10 9:38:04
图例说明W3C技术架构图描绘了一个两层的模型:万维网体系结构(被标注为“One Web”)建立在互联网(Interner)体系结构之上。图中丰富的Web层显示了W3C关心的领域和发展的技术。 Web体系结构被描绘成一系列的层,每一层都建立在另一层之上。从底至顶依次为:
在顶层包含着六个框,分别与W3C主要的活动组相对应:Web Applications, Mobile, Voice, Web Services, Semantic Web, and Privacy。
一个橙色的横条把这些领域联系在一起:Web Accessibility(Web可访问性), Internationalization(国际化), Mobile Access(移动访问), Device Independence(设备独立), and Quality Assurance(质量保证)。 这个例图展示了万维网的基础框架及 W3C 的工作重点 。 URI、HTTP、XML 和 RDF 的基础支持著五个方面的工作。无障碍网页、国际化、设备无关和质量管理等主题已融入了 W3C 的各项技术之中。 W3C正致力把万维网从最初的设计 (基本的 HTML、URIs 和 HTTP) 转变为未来所需的模式。 W3C 的技术将帮助未来万维网成为信息世界中有高稳定性、可提升和强适应性的基础框架。 From HTML to XHTMLHTML 4.01 is the final HTML version. Future work by the W3C is being done on XHTML, which is based on XML. XML is a
universal markup language that can be used to define specific markup, such as XHTML, or DocBook. XML markup is well-defined by a schema.
XHTML redefines HTML in terms of XML, whileas HTML was based on the older SGML. XML itself is a reformulation of SGML.
Complex fun, huh? XHTML is not a new markup language, but builds on HTML. Moving from valid HTML to XHTML is quite simple.
From HTML to XHTML
Doctypes are a key element of valid web pages.
* The !DOCTYPE processing instruction needs to be present at the beginning of an XHTML document.
* All tags in XHTML are lowercase.
* Attribute values need to be quoted. Shorthand for attributes does no longer work: "checked" is no longer allowed, you
have to use checked="checked" or selected="selected"
* All tags in XHTML need to be closed, whether they contain text like <
td> < /td>
, or whether they don't, such as
< hr />
< br />
< input ... />
< meta ... />
...
* Special encoding, such as the windows encoding, should be changed to UTF-8.
* Presentational markup such as <
b> - and &< i>
-is deprecated and should be replaced with <
strong> - and < em>
乱读之四Message
韦尔奇如何坐上第一CEO宝座?雷吉管了这么多年,离开的时候怎么摆平这些野心勃勃的下属? ---- 其他四个部门的首脑是:约翰·柏林盖姆(John
Burlingame),一个掌握着GE国际业务的物理学家;埃德·胡德(Ed Hood),掌管科技产品和服务部门的工程师;斯坦·戈尔特(Stan
Gault),一个在电器业务中经验丰富的人,掌管着工业部门;以及汤姆·范德史莱斯(Tom
Vanderslice),原为富尔布赖特(Fulbright)学者,掌管能源系统。 [反面解读]
韦尔奇自己画的示意图大概是这个样子:
Reg Jones (CEO)
|
| Al Way (CFO)
-------------------
|----------------------------
|
|
Dave
Dance (Vice Chair)
Jack Packer (Vice Chair)
- Stan
Gault -
John Burlingame
- Jack
Welch
- Ed Hood
- Tom
Vandenslice
- Bob
Frederick
图中下划线者均是公开的候选人,韦尔奇显然位置不利,最糟糕的是,顶头上司Dave
Dance不支持他。为什么雷吉不喜欢两个Vice Chair呢(可以看到这两人均没有被考虑为接班人)?赫赫,很简单,韦尔奇认为:
----
给我带来希望的是,两个副董事长当斯和派克相互之间的关系以及他们和雷吉的关系并不好,这就是雷吉没有选择他们的首要原因。雷吉曾和两个副董事长竞争他前任董事长的位置。
----
原来这两人原来就是雷吉的对手,而且虎视眈眈了这么多年,幸亏雷吉玩平衡也一直玩到最后,把他们玩死了!玩死了之后怎么办?怎么继续压制残余势力?看看韦尔奇自己怎么说:
---
在商业中,没有什么比上司不想让你赢更糟的了。这种事可以在任何一个地方、任何一个层面发生,而且往往比我们以为的发生得更频繁。直到我来为当斯工作之前,这种事还从未发生在我身上。我有了这段经历还能幸存,只是因为我做了自己认为正确的事情。我相信雷吉和制度是公平的。
---
雷吉这样对待他的副手,同样,Dave
Dance也这样对待韦尔奇。当然,后来的岁月中韦尔奇也这样对待他的对手,看起来是亘古不变、中西合璧的不二法则。韦尔奇心知肚明,政治觉悟很高:
---
在所有这些变化的背景下,最重要的其实是雷吉的接班人问题。在这场角逐中,每个人都想出头。我们拼命工作,尽量同别人拉开差距。我始终没有从我的上司当斯那里得到任何消息。我在GE信贷取得的成就并没有得到他的任何积极或消极回应。而且我不知道雷吉的立场。在我的心底,我始终觉得他同我站在一起,但我从来都没有把握。
---
韦尔奇获胜的根本原因还是大老板想让他做,想从两大对手派系之外空降一个继承者。后来韦尔奇也把这招玩得娴熟无比,当然,自传里面没有说的那么明显。
---
多年以来,我一直不知道,其实雷吉在当时已经作了决定—让我做GE下一任CEO。但是有几个董事青睐另外几位候选人,所以雷吉将我们三人同时推为副董事长,这样做也是期望通过一段时间的观察以改变其他董事对我的看法。 在接下来的几个月里,斯坦·戈尔特、汤姆·范德史莱斯、威、杰克·派克和当斯先后离开了GE。而在随后的两年中,柏林盖德、埃德·胡德和我直接向雷吉汇报工作。 这些失意的人们,只好打起铺盖离开了GE。。。。。。
下次,我们再看看那个著名的选拔CEO的“飞机面试”。
August 15 乱读之三Message
现在可以看看韦尔奇阴暗的一面了:-)
--
我的首要工作就是密切关注我的团队。除了一两个人之外,我发现这里的员工都不太符合我的标准。我第一个承认我在那些日子里有了解聘这些人的冲动。但是在多年的实践中,我学会了用很多方法去做这件事。这是我们做过的事情当中最艰苦最困难的事,而且它永远也不会变得容易起来。
--
[反面解读]
这里韦尔奇终于开始暴露他真实的一面了,如何干掉不顺眼的人?如何顺利干掉不顺眼的人?如何巧妙地顺利干掉不顺眼的人?
如何提拔自己人?
这样的问题我们在以权术著称的古老中国会天天碰到,避无可避,impact我们每天的生活。韦尔奇是怎么做的呢?
--
1971年,在我新上任不久,我最终不得不给三位直接向我汇报工作的经理带来坏消息。不过我还是留下了几个老员工。我将我以前主管塑料公司的职位给了汤姆
·菲兹杰拉尔德(Tom
Fitzgerald),一个精力旺盛的爱尔兰人。塑料公司的员工中绝大多数都是工程师,而汤姆则是惟一一个真正的行商。
他和我既是好朋友,又是业务上的精神伴侣。
--
[反面解读]
提示:韦尔奇也是爱尔兰裔,而且被提拔的这个汤姆没有作为工程师的同事经历。
--
我将主管硅业务的经理解职,找来了我以前的同事沃尔特·罗伯(Walt
Robb),他是在伊利诺伊把我招募到公司的博士、研究工程师,后来他离开了实验室,担任了一项小型医学开发业务的运作工作。
--
[反面解读]
提示:沃尔特是将韦尔奇引入GE的人。
--
在薄片制品业务中,我换了经理。空缺的职位由查克·卡尔森(Chuck
Carson)担任,他曾是我的财务主管,后来成为了主管新薄片业务的负责人。
--
[反面解读]
提示:查克以前就是韦尔奇的财务主管,老部下了。。。
--
这时我遇到了一个特别的家伙约翰·欧派(John
Opie),他当时是市场开发部的经理。他35岁,不过他做这项业务已经有12年了。在我遇见他的当天,我给了他第一次“火线提升”,让他当全美销售经理。在会见了他所有“新”的区域销售经理后,我告诉欧派说,如果我是他,我会让这六个家伙都回家。最后,有五个人遭到了辞退。
很显然,这样做不符合常规—非常不符合常规。但是这样做震撼了整个队伍,欧派恰恰利用这一点使整个企业有了活力。工作勤奋又大公无私的欧派逐渐成长为GE最优秀的运营执行官之一,并最终成为我的一名副董事长。 回想韦尔奇是如何坐上第一CEO的宝座的?异曲同工阿,下次再慢慢说。
乱读之二Message
继续看看韦尔奇怎么度过第一个危机:
--
我刚刚得到这份新的工作,新的工厂也破土动工了,这时我们发现我们的PPO产品有着严重的缺陷。在老化性实验中,我们发现超过一段时间以后,PPO
产品在高温下容易变脆,因而容易裂碎。而这是我们在设计中已经考虑要防止的。这样一来,这种产品就不可能成为热水铜管的替代品—而这本来是这种产品最大的潜在市场之一。
我的游说使得自己一下子陷入了职业生涯可能被断送的危险中。这个时刻将永远凝固在我的记忆里。1965年一个寒冬的夜晚,我与加托夫和艾伦·海伊—这位打蝶形领结、发明PPO的GE公司的研发实验室的科学家—来到塞尔扣克的工地上。当时我们穿着外套大衣、戴着手套站在一个大坑的上方,那个坑至少有30英尺深,足够将我们三个人都埋起来。 由于这个新近发现的技术瑕疵和我们前面的这个大坑,我在GE的职业生涯仿佛马上就会一闪即逝。 --
[正面解读]
不可否认,需要一点运气才能度过这样的危机,万一那些科学家、工程师没有找到解决之道,也就断送了韦尔奇的前途。这里,结论就是:总有一些紧急关头,你别无选择,没有任何取巧之道,只有丢命上!
前阵子名噪一时的联想的谢耘,在《修炼中》回想他的第一个职业生涯危机,1994年他负责的TVB芯片已经投产了,忽然发现纽扣电池只能保持数据几天,而不是设计的10年。怎么办?谢耘的解决之道是,带着装有严重缺陷的芯片产品,在客户、公司其他人员、甚至总工程师和其他高层领导都不知情的情况下,抵达美国,销售给客户。因为他们分析出,TVB只会先上一个付费频道,而不会使用全部功能。半年之后再找别的借口换回前期交付的产品。正是这次胆大妄为奠定了他的成就基础,当然,谢耘也坦诚承认,以后的管理生涯中,他再也没有使用、鼓励过这种做法。
可见,韦尔奇的GE价值观并不是绝对的准则,GE的“绝对保持正直”的价值观背后有强大的财务基础、雄厚的企业形象基础、广泛的人脉关系和口碑,大部分企业很难模仿GE的企业文化,自然不能腰杆挺得像韦尔奇那么直了。
我到公司的第一年,有一次顺带帮项目解决了一个blocking的问题,洋洋得意,某天别人发现这个问题并没有解决得很彻底,在邮件列表里面提出来了,这是我第一次被人在公开场合指出过错,结果就充分暴露了我的心理弱点,我居然在邮件列表里面开始否认我做的东西,结果。。。可想而知。这件事情给了我一个终身教训,一定要面对困难,而不是逃避。 乱读之一Message
杰克.韦尔奇 号称全球第一CEO,创造GE的奇迹。本人有幸在学校的时候偶获GE奖学金,并得到GE亚洲VP赠送的杰克韦尔奇自传一本。可惜落灰数年,未曾翻过一页。工作数年后屡遭挫折,反思之余,开始发现这本书的价值。 至此开始乱读系列。 [正面解读] 显然,这段话概括了韦尔奇如何startup的,作为一个纯technical的engineer,如何走上管理、决策之路?四个字,“脱颖而出”——如何做到?仅仅回答老板的问题是不够的,应该给与老板期望之外的东西。不过很多情况下能清楚认识到老板期望之内的东西就已经不简单了。想起台湾职业经理人对大陆青年的忠告,不要去试图challenge你的老板,即使他看起来很愚蠢、很笨猪、很顽固,千万别以为自己够聪明,绝大部分情况下,你自以为比老板聪明是因为你不知道你老板所知道的信息,正是这些信息不对称造成了你的错觉。往往老板看起来不可理解的决策其实有着复杂的背景,你不到那个level是没办法理解的。实际点的做法,就是韦尔奇说的,总是比老板期望的多一些,足矣。 反思我自己的失误,刚工作的时候,急于作出成绩,很多情况下并不去想老板期望什么,盲目做事情,效果不好,还挫伤了信心;觉得做管理的老板不懂技术,水平一般,其实老板上面的story我根本就不清楚;每周开会之前,我不太准备,觉得自己技术好,这些无聊的会议混混就算了,其实每周就这么一次机会在老板面前表现,应该好好应付一下,最起码做了事情要发出声音来,特别是手下人卖力干活,我如果不说,对部下也是不公平的。(看起来我越来越市侩了。。。) 这些人说区别对待的做法会严重影响到团队精神。但在我看来这是不可能的。你可以通过区别对待每个人而建立一支强有力的团队。瞧瞧棒球队是怎么向赢得
20场胜利的投手和打出40记本垒打的击球手们支付薪水的吧。这些运动员所做的贡献很容易估量出来—他们的统计数字摆在你面前—然而他们仍然是球队的成员。 [正面解读]
开始做team
leader的时候,我经常犯这个错误,总是幻想大家一团和气,气氛融洽地把项目做好,以情动人,结果必然是非常失望——人与人肯定是有差别的,不能否认这个客观规律。技术管理就是把正确的人放到正确的地方做正确的事情。情感不能用来做事情,这是深刻的教训。有一次有个出彩的活,我刻意安排我中意的一个部下去做,给他这个机会,却没充分考虑他的学习曲线、性格,导致delay,得不偿失,悔恨不已。
不过每家公司有自己的不同情况,韦尔奇的情况不一定适用于我们:以我们部门为例,预算是总部按照人头拨下来的,这样就导致招人越多越好的倾向,每年各个老板都想尽办法去证明自己需要越来越多的人,这样就有两个问题:1)招不到好的,就滥竽充数,影响了优秀员工的情绪;2)没有突出的奖罚机制,混日子的人越来越多,导致整体实力下降,说是研发中心,其实我自己心里非常清楚,实力不是一般的差、不是一般的弱啊。总有一天,会。。树倒猢狲散的。
August 13 忽发奇想之一很久没有看过东方之子节目,也不知道这个节目还办不办了。今天想到的怪谈是,如果把开播以来所有秀过的精英排一下,看看还有多少保持“清白之身”?相信是个很有意思的结果。 或者换个思路,每年的什么企业家精英评选,也拉出来遛遛,看看能有多少“金身不破”。 不管结果如何,所衍生出去分析、总结、展望,必定更为有趣。 August 08 Ajax pattern精选Message
不做不知道,动起手来才发现有很多讲究,先抄一点大拿的研究成果。
-
display morphing
通过设置元素的innerHTML属性,就把操作DOM的任务交给浏览器了。这比直接操纵DOM更加简单。这样做的问题是如果传入的字符串不正确,会导致很难调试的问题;另外可移植性会受到影响,因为同样的HTML字符串在不同的浏览器上不一定总是生成同样的DOM模型。
决策:
通过classname还是style来更改显示?
多数情况下使用classname更理想,因为不会污染JavaScript代码。在有些情况下必须用style来修改。比如:依赖某个变量的style;动画;多个变量;Prototyping。
-
page rearrangement
添加是通过给已有的元素添加一个子元素来实现的,或者给已有元素的innerHTML
属性添加内容。删除去掉已有元素:$(”container”).removeChild($(”message”));
另外可以把元素保留在页面上,但是通过CSS来使其不可见。可以使用两种属性:visibility和display。前者会保留布局信息,而后者则允许隐藏的元素周围的元素占用其位置。通常使用display属性。
也可以移动元素:
container.removeChild(message);
extraContainer.appendChild(message); 也可以通过CSS属性来布局。这些属性包括top, left, right, bottom。CSS的positioning元素用来指明坐标的原点的意义。
同样可以重叠元素,通过zIndex属性来指定相对的Z轴位置。 决策: 使用哪种positioning style? 通常情况下static就足够了。对于那些自由浮动的元素,考虑使用relative positioning。 如何避免内存泄漏? 需要确保当元素不再使用是,它被解引用。下面是一些指导原则:尽可能的避免全局变量。显式的把引用设成null。避免或消除循环引用(这些对象之间没有外部引用,只是存在相互之间的引用)。测试,测试,测试。 August 07 XML数据岛模式最近正在结合Django和ajax搞一个online的GSM基站控制器消息解码器以及日志分析工具,需要基于一个很大的消息字典来分析消息和日志。做成web方式也是对自己的一个挑战,同时也是尝试一下新的web开发技术。
遇到的一个问题是,如何保存以异步方式从server获取的消息定义?正好看到了这个ajax模式,贴下来做个学习记录。
原文地址:http://ajaxpatterns.org/XML_Data_Island 问题:如何渲染传入的XML并保留数据? 动机:
解决:Retain XML responses as “XML Data Islands”, nodes within the HTML DOM. 严格说来,一个XML数据岛指的是嵌入在标准的XHTML文档中的XML文档,通常在一个xml标签中。最初的页面可能是这样的: <html> 当一个XMLHttpRequest Call获取到了XML消息之后,该消息被保留在标签中,比如通过设置scoreData 元素的innerHTML属性。HTML DOM现在包括了全部的XML。 <html> 从更广泛的意义上来说,该模式以某种形式保留XML消息。同样可以把XML保存到一个Javascript变量中。该模式的关键点在于保留XML消息,并把它当作数据结构来使用,而不是转化成一个自定义的Javascript对象。 该模式的应用在于:
在XML数据岛和HTML之间相互转换 XML数据岛最初是IE独有的功能。从IE5开始,就可以把一个控件和XML文档绑定起来。 <input type=”text” datasrc=”#scoreData” datafld=”player”> Firefox使用的是 eXtensible Binding Language。就算不使用这些浏览器独有的功能,同样可以使用 Browser-Side XSLT来进行转换。 保留XML以备以后使用 可以把保留的XML消息作为浏览器端的缓存。 在最初的页面界面中加载XML 有时候最初的页面加载需要XML文档,虽然可以使用 XMLHttpRequest Call来获取,但是作为把XML作为最初加载页面的一部分速度更快。 实例:
|
|
|