知识共享许可协议

Windows平台开发必备工具

每个开发者都有自己喜爱的应用工具,本文分门别类为大家介绍几个陪伴多年的依依不舍软件。希望大家喜欢。如果你有更好的,也请发邮件告诉我。

文本编辑器

Notepad++(★★★★)

Windows下Notepad每个人都知道,这里要说的是NOTEPAD++,经过多次升级之后性能和稳定性都非常不错。作为开源编辑器中的老资格,功能简单,插件丰富。个人非常喜欢Notepad++。

Notepad++

Notepad++

Sublime Text(★★★★)

Sublime Tex好像是近些年来的后起之秀。很多忠实的粉丝用户这个跨平台的GUI编辑器。功能很多,插件也很丰富。唯一不爽的就是需要购买之后才能拜托那个保存时候跳出来的提醒。 Sublime Text

阅读全部

一种雪碧图自动化方案的设想

制作“雪碧图”一般是前端优化的重要一步,主要作用当然就是减少HTTP请求数。但是由于传统方法的雪碧图制作和维护成本都极高,加之现代浏览器支持的并发数也不断提高,所以很多人开始质疑做这项工作的必要性。但并发支持度变高,并不代表无限支持,网页首屏需要加载十几张图片资源还是很常见,再算上js、css以及一些数据的ajax请求,HTTP数上五十也是轻轻松,于是,用户体验就不那么好了。所以,这个工作不能省,但是开发成本又不得不考虑,于是,“雪碧图自动化”是自然而然就会产生的想法。

先看下雪碧图的发展历史:

阅读全部

玩转AMD - Loader

不用 RequireJS 的理由

理由很简单,因为太大了。RequireJS 经过语法压缩和 GZip 后,体积超过了 6k。RequireJS 最新版本已经降到了 6.1k,在 2012 年底时候的版本是接近 7k。由于下面的一些期望,让我们觉得这个体积比较大:

  • 在移动环境上应用
  • 在 baidu 搜索页面上用

既然这个体积比较大,那多少合适呢。当时我们拍了脑袋,一个 Loader,各种流转与依赖处理,两种 require,URL 查询,再加上异步的插件机制,就算看起来比较复杂,GZip 后 3k 应该没问题。开发时间我们规划了一个月,主要还是为编写测试用例留出一些时间。

后来…后来,事情远远超出了想象。我们开发了 AMD Loader: ESL,包括前前后后的一些改进和 new feature,开发过程持续了一年半多。现在虽然是一个特性稳定版本,但是仍未结束,可预见的未来还有 shim 的支持需要添加。至于体积,我们也没控制住,在每个我们觉得无法或缺的 feature 中,它的体积最终是 3.4k。如果你觉得所有的错误信息你都不需要,那么可以选择 min 版本,体积是 3.1k,超过最初的梦想并不太多。可见男人的承诺多半不靠谱。

阅读全部

玩转AMD - 应用实践

设计思路 篇中,已经对 AMD 在设计上的一些考虑做了比较详细的论述。所以这一篇只会提一些建议,引用一些 设计思路 篇中的结论,不会再详细描述为什么。

本篇提出的所有建议,都是针对于开发时就使用 AMD 的玩法。据我所知,有一些团队在开发时按照 CommonJS 的方式编写模块,通过开发时工具监听文件变化实时编译,上线前通过工具构建,AMD 纯粹被当作模块包装来用。本篇提出的建议不涵盖这种应用场景。

部分建议有一定的重叠,或者理由是相同的。举一反三能力较强的阅读者可能会觉得我很罗嗦,见谅。

阅读全部

玩转AMD - 设计思路

AMD 的全称是 Asynchronous Module Definition。顾名思义,这是一种定义模块的方式,并且是异步的。在其 Spec 的第一段描述中,就强调了特别适合浏览器环境。

The Asynchronous Module Definition (AMD) API specifies a mechanism for defining modules such that the module and its dependencies can be asynchronously loaded. This is particularly well suited for the browser environment where synchronous loading of modules incurs performance, usability, debugging, and cross-domain access problems.

我觉得,AMD 适合浏览器环境开发的主要特性有下面几点:

阅读全部

实战响应式图片

原文:Responsive Images in Practice

作者:Eric Portis

译者注:感谢米粽我佛山人otakustay为译文提出的宝贵意见。


魔鬼因一切我们享受的东西而惩罚我们。

—阿尔伯特·爱因斯坦

图片已经占了 Web 内容的 62%,而且我们每天都在制造更多。如果所有图片内容都能被好好加以利用那的确很赞。但是对小屏或低分辨率屏来说,其中大部分数据都被浪费了

为什么?尽管 Web 设计初衷是让所有人能通过任何途径来访问,但直到最近,设备的碎片化才迫使业界全面转向了响应式设计。我们在进行响应式设计时,内容可以优雅且高效地流入任何设备。这说的是除了位图以外的所有内容。位图是固定分辨率的。而且他们的容器——敬爱的 img 和它那孤零零的 src——没有任何适配能力可言。

设计师们面临这样一个苏菲的选择1:让页面在有些情况下变模糊,还是在所有情况下变慢。大多数人倾向于后者,给所有人发送能适配最大、最高分辨率屏幕的图片。浪费啊。

但是!经过三年的辩论,我们有了一些新的标记来解决响应式图片这个问题:

阅读全部