刘钢 – 我是UED

其实更多的时候需要前端人员、后端人员去提高安全意识

Web性能优化最佳实践中最重要的一条是减少HTTP 请求，它也是YSlow中比重最大的一条规 则。减少HTTP请求的方案主要有合并JavaScript和CSS文件、CSS Sprites、图像映射 （Image Map）和使用Data URI来编码图片。CSS Sprites和图像映射现在已经随处可见了，但由于IE6和IE7不支持Data URI以及性能问题，这项技术尚未大量使用。目前大部分网页中的JavaScript和CSS文件数量和开发时一致，少量的网页会根据实际情况采取本地合 并，这些合并中相当多的是有选择地手动完成，每次新的合并都需要重新在本地完成并上传到服务器，比较的随意和繁琐，同样文件的压缩也有类似的情况。而利用 服务端的合并和压缩，我们就可以按照开发的逻辑尽可能让文件的颗粒度变小，利用网页中URL的规则来自动实现文件的合并和压缩，这会相当的灵活和高效。

YUI Combo Handler

2008年7 月YUI Team宣布在YAHOO! CDN上对YUI JavaScript组件提供Combo Handler服务。Combo Handler是Yahoo!开发的一个Apache模块，它实现了开发人员简单方便地通过URL来合并JavaScript和CSS文件，从而大大减少 文件请求数。比如在页面上使用YUI2的Rich Text Editor组件需要引入多个JavaScript文件，常用方式如下：
阅读全文…

快要可以报名了~前端们关注下

日程安排

• 举办时间： 2010年07月17日(星期六)
• 举办地点： 北京航空航天大学新主楼会议中心 （地图）
• 报名地址： 距离报名还有1天5时13分39秒。
• 报名截止： 2010年06月17日 0点0分0秒

引言

最常见的闭包 (Closure) 范式大家都很熟悉了：

(function() {
// ...
})();

很简单，大家都在用。但是，我们需要了解更多。
首先，闭包是一个匿名函数 (Anonymous function), 即是 (function() {}) 这部分。之所以要给 function 添加括弧是为了让它形成一个表达式 (expression), 有了表达式，并且确定它的类型是个函数 (Function 实例), 就可以直接调用它。所以，后面的一对括弧是可以工作的，它的意义是：我要调用 (call) 这个函数。

既然是函数调用，那就可以像一般的函数那样，在调用时传入参数。这就是本次讨论的话题。

传入 window 参数

(function(win) {
// ...
})(window);

这样做最直观的好处是书写便利：少写几个字。你可以在闭包内任何地方使用 win, 它都会指向 window 对象。另外，它有利于压缩减少最终代码的体积，经过压缩后 (如 Google Closure Complier), 所有的 win 都会被替换成形如 a 这样的简单变量。win 用得越多，减少的字节数也越多。

不过，便利的同时也会带来陷阱。在 IE 上，window 总是指向当前窗口对象，这个没有问题，但是在某些场景下，使用闭包内的 win 变量会导致拒绝访问错误 (Access denied). 重现方式大致是这样的：当页面引用其他域名的脚本，并且该脚本调用了闭包内的 window.document, 而且这个闭包代码是来自另一个域名的脚本。在这种情况下，使用 win 会保持对 window 最早的引用，通过另一个域的脚本访问 win 会导致 IE 认为脚本产生了跨越冲突，从而拒绝了对 win.document 的访问。解决办法是不使用形参 win, 而是直接使用 window. 需要说明的是，给闭包传入 document 也会导致 IE 出现同样的问题。

传入 undefined

其实把 undefined 作为形参就，实参就可以不用传了，因为 JavaScript 中访问未传入的参数就会得到 undefined. 因此，你可以这样写：

(function(undefined) {
// ...
})();

和上面的讨论一样，你可以在闭包内任何地方使用 undefined, 可以少写几个字（如果把 undefined 换成更短的名字），也可以在减少压缩后体积。

另一个的优势是，你可以认为它是个变量，把它当变量来使用，它的值恒等于 (===) 真正的 undefined. 当外部代码意外地定义了 undefined 的时候——不常见，但确实可能会发生——你可以正常地使用真正的 undefined, 而不会被外部的 undefined 意外影响. 这是由 JavaScript 作用域规则决定的。
无论是否使用这个 undefined 参数，都应该避免使用 undefined 的字符串常量，如：

if(typeof myVar === 'undefined') {
// bad part...
}

因为如果你把字符串写错了，机器不会告诉你，而且会产生一个难以检查出来的bug. 幸运的是，对于 JavaScript 来说，JsLint 可以帮你做这个校验。当 myVar 已定义的时候（通过形参或 var 声明），上面的代码改成这样会更易于调试：

if(myVar === undefined) {
// good part...
}

结论

从上面两个例子来看，我们建议不要传入 window, 但是可以安全地使用第二种方式 (写 undefined 形参)；我们还要尽量避免使用字符串常量。
最后，最重要的是，这只是两个特定对象和类型的讨论，举一反三，你会更了解 JavaScript

转自阿里UED：http://ued.alipay.com/2010/05/using-window-and-undefined-as-parameter-in-closure/

今天很荣幸的第三次的参加了WEB标准化交流会
地点是在在北京航空航天大学的第八会议室，这次交流会改变了以往的圆桌讨论方式,改为分享的方式,今天的两场分享都很精彩 第一场是微软的IE9分享,第二场是周爱民老师的前端架构实战

WEB标准化交流会让我认识了不少新朋友、今天更巧的是遇到了一年前项目合作过的同事：）

IE9的分享 重点在于IE系列终于迈向标准化 并且将GPU引入浏览器引擎，对于渲染速度和性能大大提升，同时透露出XP下无论哪个浏览器都是无法使用GPU加速的，虽然不知道这个说法的可信性，但是这次IE的预览，还是有一些收获的，至少让我们看到了浏览器越来越标准，当然更重要的是kill IE6！

第二场爱民老师的分享让我比较有收获，几个方面吧

1.解决问题的思路-共性、本质，找到问题的根源
现场的例子：以为运营说需要在这里加一个按钮，他的需求真的是要多加一个按钮么？实际上可能是觉得原来按钮的位置并不合适
2.系统框架、框架、库、应用的概念
说实话，听的确实有些模糊，不过两个例子很精彩，由浅入深的，讲解了是如何一步一步的抽象出最终的系统框架。
从我的理解，库是相互没有依赖关系的，框架是来将库进行一个抽象关联，而系统框架，是更本质的抽象出了某一类业务的底层逻辑包括一些必须的数据和逻辑关联

给我印象比较深的一张图片如下：

当我们更多的关注于插件机制、组建机制、消息机制的时候、我们更应该从需求变更、版本升级、产品整合的视角来看待他们的本质

而我的观点是-人人都是”架构”师

为什么这么说呢?哈,首先我所说的架构是加了引号的

我理解的”架构”呢,更贴近我们的生活,工作,架构可大可小,”系统架构师”可能我们确实需要很多积累、天赋，而我们要把架构的意识引入到我们的日常生活中来

几个例子：
1.职业规划 是不是架构？
2.当我们保存站点文件，站点文件的目录是不是架构？
3.CSS的reset、grid、form等算不算架构呢？
4.我们经常用js写的weiget又算不算架构呢？
……
我相信在我们的生活、工作中、架构无所不在-人人都是”架构”师