易栈网-膘叔

新年了，这回可是真正的农历新年。
小时候每年的盼望到现在却变成了休假的代名词，但也只有这个日子，才会给自己一个理由回家。和家人一起团聚。
今年没有回家，主要还是因为小家伙太小，怕经不起折腾，而且这段时间温度骤降，怕他引起感冒等。
希望父母和亲人们身体健康，万事如意。
朋友们新年工作顺利，闷声发大财。

再祝福一下：牛年，牛气象。

虽然，我写页面代码都是editplus写的，从来不用DW或者其他所见所得编辑器，但并不代码我的CSS就写的特别好，其实我一直很有疑问。CSs是否就是王道？

然后我看到这篇文章，觉得也是我心里想的东西。就贴出来了。。。

其实去年年底，jQuery 1.3尚未发布的时候就已经盘算着将中文文档以xml的形式发布了。这样有个好处，就是页面结构可以用xsl随便换。各位同学想做不同的发行版可以随便换 着玩~实际上我现在愈发觉得css的局限性了，很多时候所谓的css为了后期维护方便，可以任意修改布局而无需动页面结构之类的话语已经觉得难以置信了。 我就不信有多少同学遇到过改版的时候只改css而不改html的。当然也有可能是我的局限性而非css的局限性。

所谓的圣杯布局和双飞翼布局确实在很大程度上能解决布局(Layout)上的问题，但别忘了，开发工作可不只是布局，还有排版(Typography)，数据结构和页面表现结构交织在一起的时候，想崩溃都觉得老板会从地域里拖你起来。

xml+xslt这种手段其实我几年前就看到过，当时也曾为之心动，无奈当时技术水平有限无法体会其中精妙。然借此jQuery 1.3文档大改之际便又萌发了尝试的冲动。

xml+xslt好吗？很好！居然ie 5就开始支持了，ie 6支持的程度也很不错，基本上没有遇到什么兼容性问题，比起万恶的ie6对css的支持度好多了。目前我除了发现document()函数在ie中表现的跟其他浏览器不一致之外，以及Firefox居然不支持disable-output-escaping=”yes”，并且争论长达7年多尚未有解决的迹象。除此之外似乎没发现更多问题。

实际上让一部分处理页面的逻辑放到了前端来做，后台只负责输出数据，这种数据（XML），结构(XSLT)，表现(CSS)，行为(JS)4者相对 分离的状态是十分有利于这个前端产业工业化发展的。随着前端工种的进一步细分，我觉得这里大有可挖。好处显而易见，如果要大面积改版（即便是小范围），由 于后台只负责输出数据而没有HTML格式，高度分离的情况下，基本上只需要前端小组改一下即可。即便是对后台语言完全不了解都可以（我承认这不好）。
此外，xslt支持include/import等语句，包括上面提到的document()，可以很方便的实现页面各个部分的模块化。

但随之带来的问题也显而易见，数据过于结构化，页面内容轻易被人抓取而后分析（都不用分析……直接解析……）
此外，很多pda，手机之类的可能对xslt无法解析，但我估计屏幕阅读器应该没问题，因为很多屏幕阅读器都是基于现有浏览器的，也就是说现有浏览器支持，他也就支持。
还有上面提到的模块化问题，一不小心就可能导致连接数过多。每个模块的粒度得把握好。

解决这些问题的一个简单途径是，xml+xslt在服务器端解析生成。服务器端可以通过检测浏览器来判断直接输出xml+xslt还是输出生成的页面。这对于pda和手机之类的能提高很大兼容性。而对于一般浏览器又无需消耗服务器资源。
网上有篇流传甚广的文章XML在B/S架构开发中的应用，正是描述了此类情景。我考据下来可能是原著地址（我找到个更早的地址但上面的写的作者也是他，请宽恕我的网络考古情结）。

其中也提到了http://xml.apache.org/cocoon/ 似乎可以直接使用，没深究。

好了，得回到正题了。jQuer现在弄了个专门是放api的地址:http://api.jquery.com。 说实话，我一直很不喜欢他现在弄的样子，当我需要在不同的方法之间切换的时候很不方便。有喜欢的可以自己尝试。另外，分析代码发现原来这个api也是从 wiki里扣出来的xml进行解析得来的。另有air版，喜欢的可以自己下。扣的程序是Python 2.4写的，遗憾我这里只有Py3k环境，执行失败，且自己道行过浅，无法改成3.0版以供自己用。忘有此能力的同学能帮我改一下，可直接从jq的svn 里拿到，点击下载。没有达人帮忙其实也没事，见到还有地址可以在线生成，前面在线生成的地址如果不加参数则可以直接查看这个生成器的文档。用urllib.request.urlretrieve(url,path)直接下载真的是很惬意的事情，Python真的是很强悍啊……
我随便写了个xslt，可以直接浏览jQuery 的英文文档。暂不提供下载，喜欢的就自己另存为吧……不喜欢的就自己写一套吧……
暂时计划是将中文文档转换成xml（这步已经在前天完成，转的我残念……请原谅我能力有限只能用这么离奇的办法转 格式……）。不过之前写这个的时候还没有看到上面那个wiki2xml生成器（其实早就见过了，被我无视了而已……），所以对应的标签以及格式还不是很对 上号。改天整整。另外，单个xml拆分成散件的xml的py脚本也写完了，实验成功，现在生成chm版的文档只差单文件xml的校对和chm文件的目录以 及索引之类的编辑工作了。不用太期待……一揪回家了……新年饭局又多……饿……大半夜的吐槽可真不好……睡去了……
原文：http://shawphy.com/2009/01/about-jquery-xml-doc.html

————————END————————

到底什么是最好，什么是最方便？我也一直很犹豫，也很苦恼。。

看到这篇文章，就随手转贴了一下，因为我自己也在使用这样的功能，而且，现在的网站几乎都有google的广告。所以从yahoo的14条军规来说，这并不违反这个规则：使用CDN，尽量不要有超过4个域名的链接。所以你想呀，有一些google广告和yahoo的统计再加上1至2个其他的链接，肯定是没有超过4个域名了。CDN，有现成的，使用了，也算是完成了14条军规中的一些了。不是吗？所以。。。。。。

原文：http://shawphy.com/2009/01/why-google-cdn.html

自从之前jQuery 1.3版起，就已经没有提供pack版了，而我也十分赞成使用Google CDN进行代码托管。

这样做有以下几个好处：
1，更小下载量。
都知道jQuery 1.3 pack后有38k之多，如果当然可以删除版权注释以获得更小的代码，遗憾的是这不仅无耻且只节约1个k都不到。而同样利用Google APIs 提供的GZip过的Min版，只有18k，对用户来说下载量更小。

2，减轻服务器压力。
虽然现代浏览器都有了缓存，但以前我看到过资料说某大型网站发现他们70%的访客缓存都是空的（哪位同学能帮忙找到资料请下面留言，不胜感激~）。所以，让Google为我们提供服务，而不用自己操心自己的流量~少个库可以少个连接数，何乐而不为。

3，多个网站共享缓存。
如果用户访问的多家网站都使用Google提供的jQuery，那么对于用户来说，只需要缓存一次后即可只读取缓存中的数据！而不是每个网站都要重新下载一份。对此进一步加快用户访问速度。

4，更快执行速度。
jQuery 1.3.1发布的发布信息中， 为jQuery不提供pack版给出了官方的解释。除了不易debug，在Adobe AIR和Caja-capable等环境下无法使用之外，更重要的是因为执行速度问题。随着jQuery逐渐变“胖”，用pack压缩后在浏览器端“解压 缩”所需要的资源越来越大。想象一个超大的字符串多次replace后再eval的情景……这不比直接读取一个不需要解压缩的min版来得快。John给 出了一些数据，有兴趣的同学可以看看。

反对的声音：
“不安全”、“没安全感”、“放别人的机器太危险了”、“他们服务器倒了呢？”、“以前刚开始的时候就down过”

我认为（晕……怎么我觉得我在写四六级作文……）Google服务器down的几率与我们自己服务器down的几率不会有显著性差异（抱歉，我又空 口无凭说话了……不过如果哪位同学能给出数据来拒绝我的零假设，认可备选假设的，欢迎提供，再次不胜感激~）。所以就放他们那边吧，挺安全的。

另外我还听到关于不能让整个世界为着Google转，Google阴谋论，Google威胁论的声音。实际上Google确实正朝这个方向发展，让 整个互联网围着他转。可以看他提供的一些服务，什么云计算，什么App Engine之类的，都企图让人们的应用都建立在Google至上，当Google成为了空气的时候，他已经无处不在了。这点来说，值得担忧。

虽然我的google adsense广告几乎没有人点，但是今天看到adsense小组说的重复投放的事情，还是有必要转帖一下，帮助其他人，免得重复 。。。

AdSense中文小组告诉我们：

自从我们发布了服务 器端广告设置这个功能以后，大家修改代码就更加方便了。Google AdSense代码投放的最好办法是直接通过帐户获取代码并嵌入到要投放的网站页面源代码中，但是我们发现有一些网站调整了AdSense广告代码的展 示。比如在一部分文学网站和一些内容管理系统中有类似于此的AdSense代码投放方式：

该种广告投放方式会导致一个广告位对系统产生多次广告查询，浏览器会多次处理这些请求，这样会影响用户体验。为了避免出现该问题，我们建议您按照以下方式修改广告代码：
1. 直接粘贴您的AdSense代码到页面源代码中
2. 通过iframe调用广告代码，但是一个页面只能嵌入一个iframe单元

AdSense 产品部门正在对广告后台进行一些调整以提升广告投放的准确性，如果您在使用类似上述原理的方式投放Google AdSense广告，那么接下来的这些调整可能会影响到您网站的广告投放。我们建议您尽快按照上述符合要求的方式投放AdSense广告，以避免接下来的 调整影响到您网站的AdSense广告投放。

我们注意到大家采用该方式以解决页面内容下载过慢的问题，但是从我们目前的数据和发布商反馈来看，AdSense广告在本地区的投放是不会影响页面内容下载的。

我们会通过系统邮件通知一部分以该方式投放代码的发布商，也希望大家相互转告，尽快实现代码的更换，以避免接下来的产品调整影响您网站的广告展示。如果您对此还有疑问，也欢迎通过支持链接和我们联系。

文章来自:cnbeta.com

新闻来源:岁月如歌
JavaScript游戏一段时间内将还只是开发者们的“玩物”，要真正转换为商业应用，可能还有一段漫长的路要走。但是，当Super Mario跳跃在Web网页上时，这昭示着JavaScript的时代已经到来了。JavaScript能做什么？2008年的答案是：JavaScript连游戏都能做！

乔布斯说：“活着就是为了改变世界，难道还有其它原因吗？” 2008年，在Web前端开发界，无论国外还是国内，都发生了不少事情，有哪些是改变世界或即将改变世界的大事件呢？

JavaScript游戏
2008年4月9日，Dion Almaer发现了一款非常经典的JavaScript游戏：Super Mario. 这款游戏由Jacob Seidelin开发，大小仅14k.


(Super Mario JavaScript版本： http://jsmario.com.ar/)

不少Web开发者们大跌眼镜：这真的是用JavaScript开发出来的？答案是肯定的。这款游戏利用了Canvas元素（IE中用HTML模拟），图像 存储在加密的字符串中，还用base64存储了MIDI背景音乐。除了这些技巧，其它代码就是我们熟悉的HTML、CSS和JavaScript.

Super Mario JavaScript版本的横空出世（之前也出现过用JavaScript写的游戏，但没有像Super Mario一样引起大家的关注），激起了一股用JavaScript编写游戏的热潮：

许多经典的游戏都有了JavaScript版本：Pac-Man（经典的吃豆子游戏）， Space Invaders（太空入侵者），Spacius（百玩不厌的雷电）等等。

甚至还出现了一些比较复杂的角色扮演游戏：Andrew Wooldridge创造的Tombs of Asciiroth 和 CanvasQuest，Pierre Chassaing创造的ProtoRPG等。

伴随JavaScript游戏的热潮，还出现了不少专门用于游戏开发的JavaScript库。最突出的是GameJS（基于Canvas的一个2D游戏开发库） 和 GameQuery（这是jQuery的一个插件）。

除了用Canvas构建2D游戏，用JavaScript还可以构建3D游戏，还出现了非常出色的Processing.js，以及JavaScript PlotTool绘图工具等等。

感慨：JavaScript游戏一段时间内将还只是开发者们的“玩物”，要真正转换为商业应用，可能还有一段漫长的路要走。但是，当Super Mario跳跃在Web网页上时，这昭示着JavaScript的时代已经到来了。JavaScript能做什么？2008年的答案是：JavaScript连游戏都能做！
大放异彩的jQuery
2008年，无论对于jQuery的作者John Resig还是jQuery库本身来说，都是非常棒的一年。jQuery首页上有一行很明显的加粗文字：

jQuery is designed to change the way that you write JavaScript.
jQuery设计成可以改变你书写JavaScript的方式。

jQuery用数据和事实证明了它的魅力。一定程度上，甚至可以毫不夸张地说：jQuery改变了Web前端开发界。下面是用Google Trends统计的常用JavaScript库在2008年的搜索量曲线图：


2008年9月份，jQuery团队战绩斐然：Microsoft和Nokia正式将jQuery集成进他们的应用程序开发平台。此外，Google的部 分应用里，也早就采纳了jQuery. 从jQuery的首页上还可以看出，DELL, Bank of America, Digg, Technorati, Mozzila等站点都在使用jQuery.

当然，除了jQuery，其它JavaScript在2008年也都有可圈可点的发展。YUI3的Preview版本，是我见过的最具有发展潜力的框架。 ExtJS在国内的普及也非常迅猛，JavaEye社区里，ExtJS一定程度上成了Ajax的代名词，各种有关ExtJS的技术文章和书籍非常多（遗憾 的是书籍的质量不高）。Prototype不温不火。Mootools则在低调中用其优雅的代码吸引了不少忠实用户。

感慨：上面提到的每个JavaScript库都是非常优秀的，掌握任何一个，对于我们的日常工作来说，都绰绰有余了。 只是对于2008年来说，jQuery的表现太突出了，连我这个天天工作用YUI的人，在2008年，都不得不为jQuery鼓掌，为John Resig喝彩！各种JavaScript库的争奇斗艳，这是JavaScript时代已经到来的另一个标志。
蹒跚起步的网页工业化
2008年，如果你是一名Web前端开发工程师，却没有听说过“栅格”两个字，那你一定是工作太忙太专心了。2008年10月份，在淘宝UED博客，出现了一篇“960的秘密”，揭开了网页栅格系统在国内的研究小热潮。


伴随着栅格系统的争论，国内的前端技术博客里还出现不少对CSS框架和布局的探讨。这一切，所要解决的是以下两个问题：

1. 网页的规范性。随着站点的成长，页面会以几何级数的速度增加。面对成千上万个网页，如何保持风格的一致性是一个不小的挑战。
2. 网页的工业化产出。在遵守规范和保证质量的基础上，如何让页面制作容易，如何让运营人员能批量制造页面，这是目前许多大型站点面临的另一个问题。

国内站点中，淘宝、百度有啊、网易等站点的已逐步采用栅格系统。淘宝的首页和频道目前已经全部栅格化，同时尝试性开发了TMS（模板管理系统）来解决网页的工业化产出问题。

感慨：网页的高质量工业化产出，在国内很多公司才刚起步。2009年，我相信工业化将依旧是Web前端开发界的关键词。
这些也很出色

1. 渐进增强。2008年10月份，Aaron Gustafson在ALA网站上发表了一系列有关渐进增强的文章，探讨的核心问题是：JavaScript应该做什么以及Web前端开发的技术流程。 JavaScript游戏让我们看到了JavaScript的魔力，Aaron提醒我们不能滥用JavaScript，我们要仔细考虑 JavaScript的使用场景。可用性，无侵入性，可访问性等等，这些理念是每一个前端开发工程师需要好好思考的。
2. D2（前端技术论坛）。 2008年，在北京和上海分别举办了两届D2，这是国内前端开发工程师们的两场盛会。前端工程师，这个新生的职位逐步被国内各大公司接受。D2的意义在于，我们聚集在一起，发出了自己的声音！
3. Google Chrome的诞生。 2008年，Chrome， JS V8引擎，Google迫使各大浏览器厂商开始比拼JavaScript引擎速度，这是JavaScript时代已经到来的另一个标志。Google和 Mozzila的努力，在年末的时候带来鼓舞人心的统计结果：IE的使用率跌破70%. 万恶的IE6，早点灭亡吧。2009年，Google的号角和淘宝网即将掀起的 NO IE6 活动，将加速IE6的灭亡。

最后，用两句话来结束本文：

2008年，我们努力改变世界！
2009年，我们继续改变世界，同时世界将开始为我们而改变！