web开发
web开发技术记录
最疯狂的设计稿 [原创]
单位项目的一个小flash的图标设计稿（有用的只有那几个图标），图层结构可以让人完全崩溃。
设计稿样式（点击查看大图，下同）
图层结构
没办法，整理吧，刚刚整理好这个让人吐血的图层结构，伟大的设计师又传过来一份图层结构类似的稿子——他又修改了……这种设计稿，足以让圣人崩溃……无法置评。
不明白为什么那么多图层，要达到这样的效果几个图层就够了。
回sommer:早在几年前，大型门户网站的职位中就已经有了页面工程师和设计师的区别。近几年随着web标准的推广，前端程序员就越来越显得重要，如果只是针对IE也许还好说，有时一个页面的开发要求兼容IE 6/7、firefox、opera和safari五种浏览器甚至更多。这样的开发，别说学习美术出身的设计师，就是后台程序员也一样搞不定。当然，上面那个没有这么BT，它是一个网站的导航，是flash，并且有很复杂的交互和程序生成的特效，是必须由程序员完成的，这种东西一般是设计师给出设计稿，由程序员来完成开发，由于在里面使用图标、多态图标的规格限制都很严格，所以只能由程序员根据需要来对设计图进行调整以获得需要的素材。
疑惑一下，美工和程序之间的配合：美工给出源文件至程序员...相关的截图等操作、甚至是基本的html档都是由程序员来完成？
IE 即将强制升级？ [转贴]
华军资讯消息：微软将强制升级浏览器至IE 7
如果这是真的，那么，微软又为我们做了一件好事。也许半年后，我们在做web UI开发的时候，就不用把该死的IE 6作为主要兼容对象来考虑了。当然，在一段时间内，我们仍然是需要考虑IE 6下的页面可用的（只是不必考虑完美的外观）。希望这次微软的更新能够执行彻底。
这则消息也可能造成很多盗版windows用户忧虑，众所周知，IE 7安装的时候是要对windows进行正版验证的。被验证确定为盗版windows系统的用户，将会出现盗版提示，并在一段时间后无法继续使用系统，除非用正版序列号激活。
惊闻！Sun日前宣布收购Mysql [转贴]
——LAMP能否继续往日风光？
Sun公司(NASDAQ: JAVA) 日前发表声明称，出资10亿$收购Mysql AB，希望能够籍此在数据库市场分得一大杯羹。现如今，已经有相当一部分大公司使用mysql，比如Facebook, Google, Nokia, Baidu and China Mobile，mysql作为一个open source databases，取得这样的成绩实属不易。Sun的这一收购行为，不仅能在数据库市场同oracle,microsoft以及ibm形成有力竞争，更能和它的其它开源产品一起，巩固Sun在开源世界的地位。
原文地址：http://www.ooso.net/index.php/archives/377 找了半天没找到这个博客的trackback地址，无法回ping，只好加一个链接，对不住原博主了。
Google 染毒？ [原创]
——还是卡巴斯基误报？
从今天早上到单位后开始，卡巴斯基就总报告病毒，仔细看了一下，竟然是从sb.google.com上出现的。不知道是卡巴误报还是google染毒。
符合Web标准的web UI [原创]
——来源、谬误与个人理解
序
我从2004年末开始接触web标准，2005年5月正式采取完全的web标准方式的网页制作，2005年8月，第一个符合web标准的网站UI开发工作完成。直至今日，经历了无数的艰辛，也有过许多的困惑。所幸，我的瑞典籍的Project Leader是一个很有经验的人，他告诉了我很多关于web标准国内并不了解的东西，我这几年技术方面的成长离不开他的支持和引导，感谢Andreas Liljefilt！在这里，我把它们告诉大家，也希望能有更多的人来讨论。
Chaper 1 什么是web标准？Div+css的谬误。
提到web标准，就不得不先说一说国内业界非常流行的一个词——Div+css。这个词在国内简直是一个潮流，不仅互联网上一直在提，大量的教程中使用这个词，就连一些出版的书籍也是用了这个概念。然而，甚少人知道的是，这个概念本身是错误的。有好事的朋友不妨去google搜索一下（先调整到英文界面，这样可以强制让它搜索google.com而不是google.cn），"div+css"这样一个关键字是根本找不到任何一个英文网页，全部都是中文的。没错，其实所谓的div+css就是一个中国特有的理解和概念。我甚至不知道这个词是谁先提出来的，然而，它对web标准中xhtml/css的网页构建方法的理解几乎是完全错误的。
回归正题，web标准究竟是什么？Web标准是w3c组织规定的各种web上所使用的语言的标准和规范的集合。
我们目前究竟接触到了web标准的多少？打开 w3c的官方网站，我们在左侧可以看到如下列表：
# Accessibility # Amaya # CC/PP # Compound Document Formats (CDF) # CSS # CSS Validator # Databinding # DOM # Efficient XML Interchange # eGovernment # GRDDL # Health Care and Life Sciences # HTML # HTML Tidy # HTML Validator # HTTP # Incubator # InkML # Internationalization # Jigsaw # Libwww # MathML # Mobile Web Initiative (W3C-MWI) # Multimodal Interaction # OWL # Patent Policy # PICS # PNG # POWDER # Privacy and P3P # RDF # Rich Web Clients # Rules # Security # Semantic Web # Service Modeling Language (SML) # SMIL # SOAP/XMLP # SPARQL # Style # SVG # Timed Text # URI/URL # Validators # Voice # Ubiquitous Web Applications # WAI # Web API # Web Application Formats # Web Architecture (TAG) # WebCGM # Web Services # WS-Addressing # WS-CDL # WSDL # WS-Policy # XForms # XHTML # XHTML2 # XLink # XML # XML Base # XML Encryption # XML Key Management # XML Processing # XML Query # XML Schema # XML Signature # XPath # XPointer # XSL and XSLT
全看下来后是不是觉得很晕？没错，这个就是web标准目前的全部技术规范。web标准包含了这么多的内容，而我们目前所说的div+css只是其中xhtml/css实现方式的不完整的一部分而已。
* 为什么是xhtml/css？
其他的部分，我不想说的太多，第一是因为我也没办法全都弄懂，第二是其中有一大半浏览器支持不完全甚至根本就不支持。XML是web标准中对网页实现的最终目标。也就是web页面数据化和语义化，然而由于浏览器的支持不完善和兼容问题，目前优秀、兼容性强的纯xml网站只是停留在幻想里而已。因此，现在主流的网页实现方式就是xhtml/css。首先，xhtml与html大部分兼容，并且可以让目前大多数的浏览器直接阅读。css主流的几大浏览器也支持的非常完善。再加上ECMAScript(不说Javascript的原因是Javascript的概念中包含了很多与标准不同的浏览器私有定义)，已经足够实现web UI布局的大部分需要了。
Chapter 2 web标准真的是要完全不用表格？
好像是在2005年的时候，一篇叫做《把表格从你的网页中扔出去》（找不到文章的链接了，但确实有这篇文章）的在线文章，似乎给了人们一个错觉，要符合标准，那么表格在网页中就完全不能使用了。必须用div来代替。也许div+css这个概念就是这样被想当然的创造出来的（源自表格布局）。但事实上，web标准并不是完全不允许使用表格。而是要求摒弃使用表格来布局的做法。同时，也不再使用布局这个概念。而是提倡结构与表现分离。这时，就有一些人会产生一个疑惑，如果说xhtml代表结构，css用来控制表现，那么，布局该如何解决？相信现在接触web标准的朋友不会再有这个疑惑了吧？结构和表现结合起来就形成了布局。既然不能用表格来做布局了，那么表格还有什么用呢？似乎很多人忘了表格在html中的原始定义——展现结构化数据表格。举个例子，某学校班级的期中考试成绩表，这种数据，就是一个非常明显的表格。web标准中绝对没有要求你用div来模拟表格，那是非常蠢的做法。这几天在经典论坛上还看到有人产生这样的疑惑，表格形式的格式化数据，用表格比用div要方便的多，他们搞不懂为什么一定要用div来表现表格，现在我告诉你答案了，该用表格展现数据的时候就要用表格。
Chapter 3 为什么要用web标准？怎么样才算是符合web标准？
很多人会说例如兼容性好、代码易懂、代码量小、结构合理、甚至有人说使用标准可以实现比表格更丰富的样式等各种理由来支持web标准，而web标准也的确具有这些优点，然而，这些却并非web标准真正要做的。
并非把表格换成div就是符合web标准了。也并非使用xhtml和css就是符合web标准。甚至就算你的代码能够通过w3c的验证，也很难说它就完全符合web标准。事实上，web标准的最终目标不是为了让人容易看懂网页如果仅仅是为了让人容易看懂，那么表格布局已经足够了。它的最终目标是为了让计算机能够读懂网页。看下面几个例子：
表格布局的一段代码
<table width="50%"> <tr> <td width="30%"></td> <td width="30%"><font size="3">web</font>标准的概念</td> <td width="40%">如何实现<b>标准化制作</b></td> </tr> <tr> <td colspan="3"> <font color="red"><font size="3">web</font>标准在网页中的使用</font> </td> </table>
web标准（XHTML/CSS）实现的一段代码
<h3><span>web</span>标准的概念</h3> <h3>如何实现<em>标准化制作</em></h3> <h3 class="important"><span>web</span>标准在网页中的使用</h3>
web标准(XML)实现的另一段代码
<articles>
<articletitle>web标准的概念</articletitle>
<articletitle em="4" emlegth="3">如何实现标准化制作</articletitle>
<articletitle level="important">web标准在网页中的使用</articletitle>
<articles>
看过以上几段代码后，我们先来分析一下。第一段是表格布局的代码，它把整块分成了两行，第一行用了三列，第一列是空的用于缩进，后面两列分别放了两篇文章的标题。其中的英文文字采用了不同于中文的字号。第二篇文章的标题上还有一部分是加粗强调的。第二行则是一篇文章的标题占用了整行，并且以红色显示文章标题。在页面展现出来之后，我们能够明白下面的信息：第一篇文章是普通文章，第二篇文章中有一个概念是很重要的。而第三篇文章则非常重要。然而，在代码中我们却很难看出这一点。因为没有人说过加粗就一定是强调。也没有人告诉我们红色就一定表示重要（如果是在暗红色背景下，它甚至表示不重要，光看代码是不知道页面展现出来是什么样子的，是否重要自然无从判断），在这段代码中甚至没有告诉我们，这几段文字是文章标题。
第二段代码就要清楚的多了，首先，h3标签告诉我们，它是一个标题。span标签完全没有含义，会被分析器忽略掉。而em标签则表示强调。程序很容易明白它究竟是什么。最后一行指定的的类important则可以告诉分析器，这篇文章十分重要。
最后，我们再看第三段中的XML代码，首先，articletitle已经明明白白的告诉我们，它是文章标题，多余的信息没有了。事实上多数情况下是否强调一段文字中某一个部分对于分析器来说并不重要。因此，加粗强调被放到了属性里面。最后一条，level属性非常明白告诉分析器，这个属性定义的是文章的级别。而它的属性important则告诉分析器，它的级别是重要。将来采用这种结构，我们的网络将会更加智能，而搜索引擎的搜索结果也将会更加准确。当然，好处远远不只是这些。
直到现在为止，第三段代码要想真正完美实现并且兼容，仍然只能停留在我们的梦想里。
Chapter 4 web标准的局限
web标准并没有有些人说的那么天花乱坠无所不能。正如很多在学习web标准开发的朋友所体会到的那样，如果想要开发的产品完全符合web标准，它的局限性其实很大。举例来说，如果按照web标准的建议不使用空结构块(如空div)、不使用无意义块（如仅作为装饰边角的图片）、不做无意义的DOM结构嵌套，那么想实现一个可拉伸大小的园角块都是非常困难的。目前网上流行的几种做法都不符合这个要求。这就是为什么欧美的许多网站往往结构以方块为主并且非常干净简练，一个原因是他们习惯这样的风格，但更重要的原因是为了UI的可用性和符合标准而在牺牲了美观，因为网站的DOM结构越复杂，互动表现越复杂，触发BUG的可能性就越大，兼容性也越难调整，此外，这些效果往往还不能完善。有兴趣的朋友不妨仔细看看一直被设计人员称道的大多数韩国网站，这种类型的网站和欧美的主流风格正好完全相背，走了另一个极端，以界面华丽花哨著称，因此特别能获得美术出身的朋友的青睐，在使用过程中总会出现各种各样的小问题。在 FF下也没有几个可以完美表现的。此外，这类网站在中国也是行不通的。大家不妨想想，究竟有哪个模仿韩国的网站能够获得比较高的知名度的？原因嘛，第一是它们经常造成浏览器速度过慢，第二是在网络条件不好的情况下下载经常很慢，第三，对服务器的负载压力非常大，很容易提高服务器的投入成本，最后，带来高带宽成本。
Chapter 5 web标准的背后，企业该如何适应web标准？
web标准有诸多好处，也带来了美好的前景，应当普及和推广。然而，盲目地追随标准，却可能造成整个项目的失败。要知道，web标准并非孤立的产生，而是于整个软件工程和web项目管理的发展有关。下面，我们来看一下，在适应web标准的过程中，究竟有哪些问题会造成项目失败。
- 1. 对标准的理解错误
- 前面说了，国内其实大多数企业和开发人员并不了解web标准。甚至有很多连web标准这个概念都不知道。反而对div+css这个被人错误解释出来的怪胎耳熟能详。设计师在进行设计的时候，往往天马行空的去做设计，完全没有任何章法可言，同样的内容，甚至在首页是三个字的标题，到了二级栏目页就会变成五个字，从根本上破坏了结构的可重用性。而UI程序员（请原谅我使用这个词语，因为发展到现在的web标准网页开发已经不是美术出身的设计师能够完全掌握的了）为了适应设计师的设计，只好拼命叠加各种奇怪的DOM结构，结果使本来用十行html代码就能写出来的页面最后用了三十行甚至更多，结构也一片混乱。css就更不用说了，不仅乱，而且乱的毫无章法。这种开发的方式经常造成最后只要设计上修改一点，就要对代码作非常大的改动，甚至整个开发流程从头做一遍，根本没有做到web标准中宣传的改版成本小，正好相反，改版成本有时会被无限提高。而混乱的结构和样式也会引发浏览器更多的BUG，让UI程序员不得不花更多的精力去写hack。从而进一步提高开发成本。
- 2. 没有任何规划，上手就做
- 在早期，由于表格布局的完全可视化编辑，使网页开发是可以完全不需要规划，一边做一边修改的。而我们大多数企业目前的开发流程也是如此。往往网站开发接近完成，策划人员还没有完全确定网站要展示的内容和提供的功能。但欧美许多公司的做法却是先做一份十分完善的策划和需求描述，然后建立用例模型、分析网站需求、建立逻辑模型，规划UI模块、规划功能模块、定义UI和功能模块的接口（大多数情况下这个接口就是我们现在经常使用的各种模板标签，事实上在欧洲比较完善的团队，这些标签在开始设计前就已经规定好了）、定义 flash应用程序的数据接口（一般情况下是XML文档）、定义内容框架（以便设计师在设计网站时了解网站的每个页面上究竟应该放些什么），这一大堆的各种文档几乎可以让任何两个不同的团队做出功能一模一样的两个网站来，除了美术设计不同。我就见过一份不过二十多个模板的策划案，仅仅是涉及UI设计和开发的策划和分析文档打印出来有300多页，密密麻麻的几十万字！为什么要说中国和欧美企业的开发过程的不同呢？原因很简单。中国的流程随意性更大，而欧美的流程则更加系统。然而web标准在设计的时候却是以欧美的设计流程为主。这就是我上面说的，没有任何规划，上手就做经常会造成项目失败的原因。一个边策划边构建的开发流程，采用了一份为完善的系统工程要求订制的标准，不失败才是奇迹！
- 3. 主导人员角色错误，外行管理内行
- 这几乎是中国百分之八十项目失败的主要原因！对比东西方的管理，会发现一个奇怪的现象，在西方一个项目是由专业的项目经理主导，而东方则是谁职位最高就由谁主导。总经理、部门行政经理甚至市场人员干预网站开发进程在中国屡见不鲜，甚至有向非web专业市场人员主导项目管理的倾向。在一个web开发团队中，有时起主导作用的项目经理或者策划人员并非专业的项目经理或者web策划人员，最夸张的，我目前在做的项目竟然是以设计师的设计稿为主导，设计成什么样子，就必须作成什么样子，并且整个网站的设计稿完全没有任何关于互动方面的说明（其实是绘图师，他们对web的结构和技术限制是完全懂的）。而我认识的很多朋友也都因为上级在开发进程中的胡乱干预（注意，是开发进程中，而不是策划过程）叫苦连天，甚至有时会造成整个项目必须彻底推翻重来的尴尬境地。不断延期或者推翻重来的项目开发过程，无限翻倍的项目成本，造成项目失败也就不怎么新鲜了。似乎这一点与web标准并没有关系，然而，在web标准化开发要求的团队和流程里，第一点要求就是项目经理和策划人员必须专业并且其技能范围符合项目规模！事实上这也是任何项目管理的必要条件。
那么，企业和开发人员究竟该如何适应web标准？以下几点注意事项仅供参考：
- 完善的前期策划和分析
- 完善的前期逻辑模型以及项目规范性文档的制定
- 尽可能将行政性干预移到策划阶段（按照国内的情况，做到这一点可能很困难）
- 尽可能向后兼容，在项目规范性文档制定阶段对网站进行完善的模块化规范（主要是为了提高网站模块代码的可重用性以及最大程度上降低改版成本）。
- 尽可能简化UI代码的DOM结构，以降低维护成本
- 在设计和开发过程中首先保证UI的可用性，在此基础上保证其美观（好用第一，好看第二）。
- 项目阶段明确，要让单位的高层明白，在项目的alpha期之前是不可能有能让他们看的懂用的通的完善网站出现的。
- 项目团队主要成员必须要用专业人员，并且要让这些人员有足够的决定权（如果项目负责人无法主导项目走向，项目就必然产生缺陷甚至失败）。
这篇文章到这里已经结束了，我不知道这篇文章究竟会不会让那些一意孤行的BOSS们看到，更不指望能给他们带来多少影响。如果哪个BOSS看到了，希望你考虑一下你的投资和钞票。我所说的这一切，不仅仅是为了减轻开发人员的负担，更是为了让开发人员能够实现一个赚钱的项目，从而在这个赚钱的项目中获得更多的金钱和良好的心情。而能够决定这一切的，并非开发和设计人员。
说的非常好！
很多事情，国内在模仿，模仿表皮！
非常好
博客怎样赚钱？ [原创]
——一个奇怪的想法
下班前，在群里毒素咖啡告诉我他看到一个博客，日志36篇，评论竟然高达75137篇。突然在想，其实这样的博客也能赚钱的，如果在上面挂一个IP记录系统，一个用户行为分析系统和一个评论内容分析系统，得到的数据就是AntiSpam的最好数据来源，很棒的钓鱼网站啊……如果有哪个公司在开发公共AntiSpam系统，并且看到这篇文章的话，向你们推荐一下这个博客：去搜索一下websung’s blog。
很好的BLOG，
我的：http://blog.sina.com.cn/hustboy
关于搜索引擎质量 [原创]
今天在研究各搜索引擎收录质量的时候，以自己的博客为目标，查询各个搜索引擎的收录情况，结果如下：
Google: 518条
Baidu: 254条
Yahoo中文: 585条
LiveSearch: 52条
再看我博客本身的统计数据：
全部 Weblog 记录共199条，包括所有的友情链接等记录。其中真正的weblog记录，信手涂鸦有115条，老婆的博客“宣”言有37条，共142条记录。每条记录都有评论页面和Trackback页面，两个博客分页共16页，20个类别共39个页面，26个月份共29个页面，加上四个个人简历页面，一个按月索引页面，一个分类索引页面，两个留言本页面，此外，英文博客有11条记录，都只有引用页面，2个分页，4个分类，4个月份页面。共142×3+16+39+29+4+4+11×2+4+4=548个页面，考虑到新增记录被收录和索引的延迟，那么真正可以被索引到的页面应该有大约530个。这样算来，数字和计算出的应被收录页面数最接近的是Google，其次是Yahoo。百度可能是对页面内容重复较多的记录进行了缩减，居第三，微软的Live Search在一年多的时间内仅收录了52条，无论怎么计算，它都没有索引完全。我的robot.txt并没有禁止任何页面被索引。在索引数字上，Google胜出，它的收录范围基本上涵盖了我博客域名下包含的可抓取内容的全部，遗漏也在可接受的范围内。Yahoo收录最全，但存在很多冗余记录（估计是过时记录）。因此我认为它不如Google，百度对索引页面大批量删除的做法明显很有问题，但它还是可以搜索到我博客的全部内容的。最成问题的是Live Search，在这个被Windows Vista做为默认web搜索引擎的搜索引擎中，抓取一个网站的内容仅占全站的十分之一，这个数字实在让人心寒，
此外，还注意到在各个搜索引擎的搜索结果中，Google，Yahoo和LiveSearch都把首页，也就是blog.icebirds.net这个网址放在了搜索结果的第一条中。而百度的搜索结果中，一直翻到第十页也没看到索引首页的那条记录，不知道它在搞什么。这样的搜索结果，难怪那么多人说百度的搜索结果质量非常的低……
突然想到（一） [原创]
——Flash与OOP
早在2000年接触Flash的时候，就觉得它的库元件和拖到舞台中的实例，与OOP中的类与对象的关系非常的像。甚至可以说完全一致。那时总是在想，能否方便的在代码中直接吧元件当作类，实例当作对象来操作呢？只是在AS 1时代，一直没能实现这种想法，慢慢的就遗忘了。
学习研究AS 3也有一段时间了，今天突然想到，当初的想法，在AS 3中，不是就这样实现了吗？AS 3中舞台上每一个元件，都是MovieClip类的一个实例，库中的元件也可以和类绑定在一起，也是对类的继承。原来，当初以为不会实现了的想法，在不知不觉间，已经成为了现实，并且使用的如此简单……
（PS：刚刚概念有些错误，一时头脑发昏把库元件和系统内置类的关系说成了多态，事实上它们的关系应该说是继承。库中的元件可以绑定我们写的外部类，事实上就是对display包下类的继承。）
Feedsky 出问题了 [原创]
昨天刚刚把我的feed发布到feedsky，没想到今天就Crash了。还连累我的侧边拦打不开。最后没办法，只好紧急借用aw博客上的链接按钮，重新改掉了订阅区才好了。去feedsky上看看，昨天完全没有数据。而就在昨天，还自己订阅了一次。不管怎么说也应该有一个数据的。希望它不会总出问题。
G点CN和AS3中文版语言参考 [原创]
——google的新域名
刚刚看到aw的博客上发表了一篇新文章，说google启用新域名g.cn，AW很能灰色的恶搞啊，把它说成是“G点CN”，很容易引起误会的说法啊。不知道google的人看到这个会是什么感想。
Flash CS3 发布也有很长一段时间了，AS 3的发布更是已经超过了一年，不知道为什么，这次Adobe一直没有做AS 3的离线语言参考，这对我的习惯是一个严重打击，以前总是习惯于一边开着PDF版本的语言参考，一边写代码，现在，一切都变了样，不得不开着一个浏览器窗口去浏览这份语言参考。虽然网上有网友整理的chm版的LR，但还是觉得不习惯。做了一年多的web UI开发，现在转回AS开发，突然发现我习惯的一切都变了样，SEPY将近一年没有更新，Flash Develop脚踏两只船，.net和Java一齐上阵，一时间还真难以适应。用惯了ubuntu，却发现在ubuntu上没有非常合适的AS 3编辑器和编译器，只能重新适应一套新的语言haXe，在没有代码提示、代码高亮的条件下作业。代码编辑器除了gedit，就是vim了，突然发现自己对代码高亮和代码提示非常依赖，看来这不是什么好事啊。
