博客园_慢热君

2011简单总结

2012-01-21T03:43:00Z

　　今天是农历2011年的倒数第二天(像我这样的农民还是习惯于农历)，最后一天上班，12点放假，明天坐灰机去四川(农民第一次坐灰机)。最后一天上班，工作上简单回顾下2011年所做、所感，给自己作一点客观的评价。

　　 2011年第一个收获是：基本能做事了。所谓能做事，主要有两方面：其一、能够基本完成上面分配下来的任务。做的其实主要是和业务相关的事情。承蒙照顾，自己独立负责一整个业务块的前端任务。因为之前不是我做的，所以做业务，浅显的理解是在已经搭建好的房子上添砖加瓦，并且很多砖瓦都是现成的。不管这个新添加的这些墙壁、屋檐的内部是否搭建得完美还是丑陋，和原来的搭建方式是否统一，新来的同行看到这些是否能够快速明白这个房子、新添加的部件的构建方式，抑或偶尔出点小毛病。总体来说，从外面看这是一栋比较好的房子，能达到需求方的基本需求和一些外延需求。其二、能够主导一些事情把自己业务相关的事情做得更好。相信这一点的重要性，很多工作了的同学特别是工作时间比较长的同学会深有感触。这一点要给予自己肯定，这一年这方面有了起步，但是做得非常不够。简单地讲，是刚刚找到一点ownership的感觉。虽然平时可能有很多想法，但是去将想法完善成方案，权衡方案的可行性，并推动方案的实施，实施后评估方案是否达到预期效果，持续跟进。这才是一个完整的周期。

　　 2011年第二个收获是：找到了些许内心的平静，即功夫熊猫里所谓的inner peace。之前焦虑、浮躁、浅尝辄止有一定程度上的改善。之前的我总是在徘徊，为了学习而学习，想快速学成、快速致富、快速成功。虽然经常听人讲“语言只是工具”，但经常凭借自己仅有的那么一点可怜的知识去评判某门语言的优劣，并在看好某门语言时投入半个月或一个月时间去速成。万物皆有道，“道”听着很玄乎，有点唯心主义，但道确实在很多人的心中(好吧，装B了)。

　　 2011年第三个收获是：掌握了一点点沟通的技巧。这一年，公司请咨询公司给全体员工培训了"高效能人士的七个习惯"，自己看书和讲师培训感觉还是大不一样，收获颇大。以前对于沟通的浅显理解是，沟通不就是讲话嘛，沟通不畅、沟通困难怎么会产生，要办什么事情，说个话不就明白了。这一年在邮件沟通、工作沟通、日常沟通上有些许感悟，不再像个愣头青。

　　谈些不足或做得不够，也是2012年要改善的地方。

　　其一、技术上，从使用者的单一角色向提供者、使用者双重角色转变。更多的做些基础工作、挑战性大的工作。2012年将要重构底层的框架，怎样提供更加的健壮、优雅的底层，怎样设计用户友好的api。大道相通，这需要借鉴其他语言、其他技术。

　　其二、“精于心，精于形”。要做好事情，更要说出来。开始学习分享。敢于分享，乐于分享是一种自信的表现。自信来自于哪里，来自于inner peace，来自于认识的到自己的不足。

　　其三、学习处理人情世故。人是社会的动物、是环境的产物。要积极参加有益活动，认识人，多学习，多交流，多思考。

本文链接

(译)How content delivery networks (CDNs) work

2011-12-03T09:17:00Z

翻译一篇Nicholas C.Zakas的文章，原文在这里。自己看和翻译还是两码事，第一次这么正经的翻译，翻译得比较晦涩，喜欢英文原文的同学可以挪步，也可以选择对照英文阅读。

正文如下：

Content delivery networks (CDNs) are an important part of Internet infrastructure that are frequently used without a full understanding of what’s happening behind the scenes. You’ll hear people saying, “oh, we put that on the CDN” or “make sure static assets go on the CDN,” when they have only a rudimentary idea of what CDNs are and how they work. As with most pieces of technology, CDNs are not magic and actually work in a pretty simple and straightforward manner.

　　内容分发网络(CDN)是互联网基础设施中非常重要的一部分，被人们广泛使用，虽然人们没有对它内部的运行的机制有全面的理解。你可能经常听到人们说，"我把那个放在CDN上了"或"确保静态资源都放在CDN上"，当他们只对CDN和它的工作原理有个基本的了解。和大多数技术一样，CDN没有多少神奇的地方，它实际上的运行其实只是一个相当简单和直接的方式。

When a web browser makes a request for a resource, the first step is to make a DNS request. Making a DNS request is a lot like looking up a phone number in a phone book: the browser gives the domain name and expects to receive an IP address back. With the IP address, the browser can then contact the web server directly for subsequent requests (there are actually multiple layers of DNS caching, but that’s beyond the scope of this post). For your simple blog or small commercial web site, a domain name may have a single IP address; for large web applications, a single domain name may have multiple IP addresses.

当一个web浏览器发送一个资源请求，第一步发送的是一个DNS请求。发送一个DNS请求很像在号码簿上查找一个电话号码：浏览器提供域名，要获得一个IP地址。有了这个IP地址，浏览器就可以在后续资源的请求上直接与web服务器通讯(DNS缓存实际上有很多层，但是这不是这篇文章所要讨论的)。对于你自己的一个简单的博客或是一个很小的商业网站那，一个域名可能只有一个IP地址；但对于大型的web应用，一个域名就可能对应很多的IP地址。

Physics determines how fast one computer can contact another over physical connections, and so attempting to access a server in China from a computer in the United States will take longer than trying to access a U.S. server from within the U.S. To improve user experience and lower transmission costs, large companies set up servers with copies of data in strategic geographic locations around the world. This is called a CDN, and these servers are called edge servers, as they are closest on the company’s network to the end-user.

物理连接上，一台计算机的物理环境决定它连接到其他计算机的速度。所以在美国连接一台在中国的服务器将比连接到一台在美国的服务器所花的时间要长。为了提高用户体验，减少远距离连接所花费的代价，很多大公司在世界范围内设立了很多存放了相同数据服务器。这就叫作CDN，这些服务器叫做边缘服务器，因为它们最贴近最终端用户的网络。

DNS解决方案(DNS resolution)

　　When the browser makes a DNS request for a domain name that is handled by a CDN, there is a slightly different process than with small, one-IP sites. The server handling DNS requests for the domain name looks at the incoming request to determine the best set of servers to handle it. At it’s simplest, the DNS server does a geographic lookup based on the DNS resolver’s IP address and then returns an IP address for an edge serverthat is physically closest to that area. So if I’m making a request and the DNS resolver I’m routed to is Virginia, I’ll be given an IP address for a server on the East coast; if I make the same request through a DNS resolver in California, I’ll be given an IP address for a server on the West coast. You may not end up with a DNS resolver in the same geographic location from where you’re making the request.

当浏览器发送了一个DNS请求，请求一个被CDN处理过的域名，这和它向一个小的、只有一个ip地址的网站域名发送请求在过程上有轻微的差别。服务器处理域名的DNS请求会根据进来的请求决定返回最佳的处理方式。最简单的，DNS服务器基于DNS查找者的IP地址来做一个地理查找，然后返回一个离用户最近的边缘服务器的IP地址。所以，如果DNS解析路由到我的请求是来自弗吉尼亚州，我将得到一个东海岸的服务器的IP地址，如果我在加州通过DNS解析器发送了一个同样的请求，我会得到一个西海岸的服务器的IP地址。你可能不会得到一个和你发送请求地理位置相同的DNS分析结果。

That’s the first step of the process: getting the request to the closest server possible. Keep in mind that companies may optimize their CDNs in other ways as well, for instance, redirecting to a server that is cheaper to run or one that is sitting idle while another is almost at capacity. In any case, the CDN smartly returns the best possible IP address to handle the request.

这是过程的第一步：到最近的服务器得到请求。请记住，公司可能会对他们的CDN进行其他方式的优化，例如，重定向到的服务器运行成本更低或闲置，而其他的几乎满负荷。在任何情况下，CDN返回处理该请求最好的IP地址。

访问内容(Accessing content)

　　Edge servers are proxy caches that work in a manner similar to the browser caches. When a request comes into an edge server, it first checks the cache to see if the content is present. The cache key is the entire URL including query string (just like in a browser). If the content is in cache and the cache entry hasn’t expired, then the content is served directly from the edge server.

边缘服务器的工作方式类似于浏览器缓存的代理缓存。当一个请求到边缘服务器，它首先检查缓存中是否还包含请求的内容。缓存的key是整个URL，包括查询字符串（就像在浏览器中）。如果内容是在缓存中，并该缓存条目没有过期，边缘服务器就会将内容直接送达出去。

　　If, on the other hand, the content is not in the cache or the cache entry has expired, then the edge server makes a request to the origin server to retrieve the information. The origin server is the source of truth for content and is capable of serving all of the content that is available on the CDN. When the edge server receives the response from the origin server, it stores the content in cache based on the HTTP headers of the response.

　　另一方面，如果在请求的内容不在缓存中或缓存已经过期，边缘服务器就会向源服务器发送请求来获得内容。源服务器里内容是最正确的，是内容的最初来源。它可以提供CDN能提供的所有内容。当边缘服务器接收从到源服务器的内容，它将基于响应内容中的HTTP头建立内容的缓存。

Yahoo! created and open sourced the Apache Traffic Server, which is what Yahoo! uses in its CDN for managing this traffic. Reading through the Traffic Server documentation is highly recommended if you’d like to learn more about how cache proxies work.

雅虎创建和开源的Apache Traffic Server，这是雅虎用来管理其网络阻塞在它的CDN中使用的服务器。如果你想了解缓存代理是如何工作的，强力建议通读Apache Traffic Server文档。

举例(Example)

　　For example, Yahoo! serves the YUI library files off of its CDN using a tool called the combo handler. The combo handler takes a request whose query string contains filenames and concatenates the files into a single response. Here’s a sample URL:

例如，雅虎提供的YUI库文件它的CDN使用的工具，称为combo handler。combo handler将请求的查询字符串包含到一个单一的响应的文件名和连接文件。下面是一个示例网址：

　　http://yui.yahooapis.com/combo?3.4.1/build/yui-base/yui-base-min.js&3.4.1/build/array-extras/array-extras-min.js

　　The domain yui.yahooapis.com is part of the Yahoo! CDN and will redirect you to the closest edge server based on your location. This particular request combines two files, yui-base-min.js andarray-extras-min.js, into a single response. The logic to perform this concatenation doesn’t exist on the edge servers, it only exists on the origin server. So if an edge server receives this request and has no content, a request is made to the origin server to retrieve the content. The origin server is running the proprietary combo handler (specified by /combo? in the URL) and so it combines the files and returns the result to the edge server. The edge server can then serve up the appropriate content.

该域名yui.yahooapis.com是雅虎的CDN的一部分，它将根据你的位置帮你重定向到离你最近的边缘服务器。这种特殊的请求将两个文件：yui-base-min.js和array-extras-min.js，合并成一个单一的响应。理论上来说，处理这个串联请求的内容在边缘服务器上不存在，只存在于源服务器。因此，如果一台边缘服务器接收到这个请求但它没有这个内容，它就发送请求到源服务器去检索内容。源服务器上运行着combo handler（在URL中指定成 /combo? 形式），所以它合并文件，并将结果返回到边缘服务器。以后边缘服务器就可以提供适当的内容。

什么是静态(What does static mean?)

　　I frequently get confused looks when I describe systems similar to the combo handler. There is a misconception that CDNs act like FTP repositories, where you simply upload static files so that others can retrieve them. I hope that it’s clear from the previous section that this is not the case. An edge server is a proxy, the origin server is the one that tells the edge server exactly what content should be returned for a particular request. The origin server may be running Java, Ruby, Node.js, or any other type of web server and, therefore, can do anything it wants. The edge server does nothing but make requests and serve content. So the YUI combo handler exists only on the origin server and not on the edge servers.

当我描述一个类似于combo handler的系统时，我经常感到困惑。有人认为的CDN的运行就像FTP库，你只需上传静态文件，其他人就可以拿到他们想要的静态文件，这是一种误解。我希望通过上面的阐述，你能明白，其实不是这样的。边缘服务器只是一个代理，源服务器主宰着边缘服务器到底一个的请求应返回什么样的内容。源服务器可运行Java、Ruby、Node.js或任何其他类型的Web服务，因此，可以做任何它想做的。边缘服务器除了发送请求(到源服务器)、提供内容(给请求)之外，什么也不做。所以YUI combo handler只存在于源服务器上而不是在边缘服务器。

　　If that’s the case, why not serve everything from the CDN? The CDN is a cache, meaning that is has value when it can serve data directly and not need to contact the origin server. If an edge server needs to make a request to the origin server for every request, then it has no value (and in fact, costs more than just making the request to the origin server itself).

　　如果是这样的话，为什么不从CDN提供一切(内容)服务呢？ CDN是一个缓存，这意味着只有直接提供数据而不需要和源服务器交互时才有价值。如果边缘服务器对于每一个请求都需要请求源服务器，那么它有没有价值的（事实上，成本比只是发送请求到源服务器本身还高）。

The reason JavaScript, CSS, images, Flash, audio, and video are frequently served from CDNs is precisely because they don’t change that frequently. That means not only will the same user receive content from cache, but all users will receive the same data from cache. Once the cache is primed with content, all users benefit. A site’s homepage is a poor candidate for edge caching because it’s frequently customized per user and needs to be updated several times throughout the day.

JavaScript，CSS，图像，Flash，音频，和视频一般都使用CDN服务的原因，它们的改动不是很频繁。这意味着不仅相同的用户会从缓存中收到内容，所有用户都将收到从缓存中相同的数据。一旦预先缓存了需要的内容，所有用户受益。网站的主页不需要使用边缘缓存(CDN)，因为它经常需要根据每个用户的需要在一天中更新很多次。

缓存过期(Cache expiration)

　　Yahoo! performance guidelines specify that static assets should have far-future Expires headers. This is for two reasons: first, so the browser will cache the resources for a long time, and second, so the CDN will cache the resources for a long time. Doing so also means you can’t use the same filename twice, because it may be cached in at least two places and users will receive the cached version instead of the new one for quite a while.

雅虎性能准则指定静态的资源应该有一个未来的过期头。这有两个原因：第一，(没有过期头的话)浏览器会在很长一段时间内缓存资源，第二，CDN也将缓存的资源很长一段时间。这样做也意味着你不能两次使用相同的文件名，因为它可能至少在两个地方(CDN/浏览器)被缓存，用户将在相当长一段时间内获得旧的缓存版本而不是新的版本。

There are several ways to work around this. The YUI library uses directories containing the version number of the library to differentiate file versions. It’s also common to append identifiers to the end of a filename, such as an MD5 hash or source control revision. Any of these techniques ensures that users are receiving the most up-to-date version of the file while maintaining far-future Expires headers on all requests.

有几种方法可以解决这个问题。 YUI使用目录来区分文件版本，这些目录包含library的版本号。还有一种常见的方式是在文件名的末尾追加标识符的，如MD5哈希或源代码控制版本。这些技术都确保用户接收到文件是最新版本，同时保持将来所有的请求头到期。

结论(Conclusion )

CDNs are an important part of today’s Internet, and they’re only going to become more important as time goes on. Even now, companies are hard at work trying to figure out ways to move more functionality to edge servers in order to provide users with the fastest possible experience. This includes a technique called Edge Side Includes (ESI) which is designed to serve partial pages from cache. A good understanding of CDNs and how they work is key to unlocking greater performance benefits for users.

CDN是现今互联网的一个重要组成部分，它只是会随着时间的推移变得更加重要。即使现在，公司正在努力试图将更多的功能边缘服务器，以便为用户提供尽可能最快的体验。这包括所谓Edge Side Includes(ESI)，其目的是为从缓存中的提供部分页面。对CDN以及它如何工作的一个深入的理解，是能否为用户带来更大的性能优势的关键。

本文链接

javascript模块化、模块加载器初探

2011-11-27T14:12:00Z

最常见网站的javascript架构可能是这样的：

一个底层框架文件，如jQuery
一个网站业务框架文件，包含整站公用业务模块类(如弹框、ajax封装等)
多个业务文件，包含每个具体页面有关系的业务代码

为了减少一个HTTP请求，我们可能将底层框架文件和网站业务框架文件combo成一个文件，作为一个公用文件引入到每个需要使用javascript的页面中，再在具体的页面中引入和当前页相关业务js文件。为了减少页面加载脚本阻塞现象，我们还可以将脚本文件放在html的body底部进行加载。

这看似是一个很好的javascript架构方案。每个页面最多引用两个js文件，打开首页后，后续页面都可以使用缓存中的combo过的js。如果底层框架改动不太频繁，那么缓存在用户浏览器中的combo过的框架文件能够使用较长的时间。

当网站使用过一段时间后，你可能就会发现一些问题出来了。　　

combo过的框架文件过大。虽然可以使用YUI Compressor或Google Clousure等第三方压缩工具压缩、启用gzip、使用CDN等优化手段优化。但底层框架会随着开源框架升级，公用模块增多，导致combo后的框架文件越来越大。
业务框架改动频繁，导致浏览器缓存作用减小。由于业务的增加，可能公用的业务模块越来越多，导致业务框架频繁修改。代码修改后，浏览器需要重新加载新的框架文件。
团队开发问题。随着团队人数的增加，可能每个人开发一个公用业务模块，造成多人需要对同一个文件进行修改。若使用TFS这种独占式签出的版本管理工具，会对团队的开发效率造成一定影响。

我们再看看使用模块加载器、并对javascript进行过模块化处理的网站的javascript架构：

一个模块加载器文件。如loader.js
多个底层模块(如selector、ua等)，多个业务模块(如dialog、suggest等)
多个页面相关的脚本调用文件

优点体现出来了：

按需加载：只加载当前页面需要的模块和文件，不需加载任何多余文件和代码。大大缩减了代码量
并行加载：很多loader提供了并行加载多个文件的功能，减少了代码加载的时间，优点能做到下载和执行相分离。
利于团队开发：团队中每个人负责开发各自的模块，之间互不影响。
最大限度的利用缓存：模块颗粒化后，每次更新可能只是其中一个小模块，其他未更新的可以利用浏览器中的缓存。

既然javascript模块化、使用模块加载器有这么多的好处，那么我们需要付出哪些努力：

选用或实现loader
底层框架的模块化：我们需要将底层框架按照各自的只能分成不同的模块，分清楚之间的依赖关系
实现业务模块：将原来的业务模块按照loader约定的代码方式进行修改，实现新的业务模块按照loader的方式编写。

本文链接

如何快速成为javascript高手的思考

2011-11-26T16:46:00Z

如何快速成为javascript高手？

之前我拿这个问题问过我的同事，也问过国内的一些javascript高手。

最近，我一直在拿这个问题问自己。之所以会有这个问题，我基于两个前提：第一、我自认为自己不笨；第二、我学习和使用javascript也有一段时间了，并且自己学习还算努力。

思来想去，我觉得我应该先回答下这个问题：如何提高自己的学习效率？

想象一下学校的场景，有一些知识，有的人就是学得比你快。为什么？可能他本来就比你聪明；可能他之前学过的、接触过的东西使他对这个知识有启发；可能他背地里比你花的功夫还多。不管哪一种形式，从旁观者的角度来看，他就是学得比你快，也就认为他的学习效率比你高。

排除第一个答案不讨论。我们来讨论下第二个和第三个答案。

答案二：“他之前学过的、接触过的东西使他对这个知识有启发”，我这里简单的归结为积累，关于积累问题，我上一篇博客程序员的学习和积累有谈到。

答案三：“他背地里比你花的功夫还多”，还有现象本身“他花的功夫比你少，学得比你还好”，关键字都落在了“功夫”二字上。如何下功夫、功夫下在什么地方？这又引出了一个新问题。

关于这个问题，纠结了这么多天，我的回答是：如何下功夫？动手！功夫下在什么地方？和工作有关的地方！

说到这，我又想起了我深受毒害的应试教育。应试教育缺乏的正是动手和实践知识的场所或曰方式。很多时候我总是懒于动手，为什么懒于动手？难道是我真的懒吗？我不承认，我不动手是因为我找不到动手的理由，或是不知道如何动手。拿写一个javascript库或框架为例，为什么我到现在还没有写一个javascript库？首先我找不到写它的理由，现在这么多流行、易用且被广泛使用的javascript库或框架了，有必要再写一个吗？就算我写了，公司会使用它吗？如果没有对其他库或框架的深刻理解和认识，只是把各个库或框架中的一些东西拼凑在一起，甚至不知道其中一个函数实现的内部原理，那能叫我写的吗？其次，我找不到入手的地方。在没有对其他框架有深刻认识，自己能找到其中的缺陷、不足而加以修正和实现之前，我找不到入手的地方。

解释下答案：

功夫下在和工作有关的地方，这需要有强烈的责任心和主人翁意识。我们需要深刻理解这句话，“功夫下在和工作有关的地方”不是说，每天把上司交给自己事情做完、没有bug、达到需求就可以了。而是要做得更好，我想提出3点，也给自己树立目标：

1、用最优的方案实现需求。在自己的已有知识结构、能力、经验上用最好的方式实现需求，在此基础上努力搜寻业界相关的解决方案比较优劣，选出最佳的方案，最终实现需求。

2、关心自己已做完工作，关注业界的相关新思想、新技术、新理念，把已完成的工作，用最新最优的方案予以重构，并在适当的时机在产品上得以实现。

3、关注自己所负责工作的未来，把产品当做自己的孩子，努力将他引向最美好的未来。努力将自己所负责的产品打造成为业界的标杆(特别是自己所负责的部分，那是自己影响圈内的事情)。

动手。如果你知道了功夫该下在什么地方，也自然知道了要动手做什么，动手也会成为快乐的事情。

不知道大家有没有这样的经历，当你有极大的渴望想把某件事情做好的时候，你会花很大的精力去研究怎样把事情做好，为此你会学习很多相关的东西，平时你可能花一周时间也学不会的东西，你花一个上午就学会了，还应用到了你要做到事情中，并且事后你会对所学过的东西印象深刻。

这，就是我对“如何提高学习效率”这个问题的回答。

很抱歉，写到这里我还几乎没有正面回答“如何快速成为javascript高手”这个问题，如果你已经有所收获了，我感到很欣慰。如果没有，再谈谈javascript，因为我目前还不算javascript高手，下面这段算画蛇添足也好，算狗尾续貂也罢。

语言层面：编程语言之间是想通的，至少高级语言是想通的(相对于机器语言和汇编语言)，javascript是一门特殊的语言，既可面向过程、又可面向对象。有人喜欢它弱类型语言的特性，而将其语言本身的特性发挥得淋漓尽致。有人喜欢java这类纯面向对象语言的严谨，而使用一些功能函数将其包装成完全的面向对象，并采用它实现了一些常见设计模式。所以说，真正要精通javascript这门语言本身，需要对其他语言的一些理解(至少是了解)。鉴于目前javascript从业人员的构成，非计算机专业科班出身的同学可能需要努力补补课。

环境层面：javascript运行的环境目前有浏览器端和服务器端，将来可能有机会到嵌入式设备中。目前大部分应用主要集中在浏览器端，而浏览器厂商为了各自利益等各种历史原因造成的javascript运行环境兼容性问题，也是javascript从业人员较为头疼的问题。

业务层面：很多其他语言有功能完善的底层API、工具包，抱歉，javascript暂时没有(浏览器端、nodejs开始有雏形，希望commonJS规范能够一路走好)。所以各种库、框架对于一些基本业务需求都提供了类似但非相同的实现。一个优秀javascript程序员需要辨别各种框架或库中的业务实现，或编写出自己的业务实现。

综上，要在语言、环境、业务三个方面都精通，确实是需要花费很大的功夫。一个人的精力是有限的，其他语言积累几十年的东西，你想一个人在javascript得到实现是不太可能的。术业有专攻，不是说你是javascript高手，javascript的方方面面你都能做到最好。

故，我认为“如何快速成为javascript高手？”，无解。无法快速！

“如何成为javascript高手”，动手，把功夫下在和工作有关的地方上！

运用javascript把工作做得最好，才是javascript高手！

PS：这是本人对自身问题的思考和分析，之所以发到首页来，是希望能给有同样疑惑、同样迷茫的同学带来些思考。分享这篇博文花了4小时的写作时间，如果你有同感，如果你觉得我还算用心，请帮忙右下角推荐一下，这样能给更多的同学带来一点思考和帮助。如果你以为我是javascript高手，只是来学习经验的，却没有半点收获，失望而归，请拍砖。

本文链接

Linux Boot Sequence

2011-11-22T14:04:00Z

Boot Sequence翻译成中文是引导顺序、启动顺序，是学习linux的一个重要的知识点，也是一个基础的知识点，做下笔记。

Linux Boot Sequence：

1、load bios(hardware information)

加载BIOS(硬件信息)，BIOS：Basic Input Output System(基本输入输出系统)，是一组固化到计算机内主板上一个ROM芯片上的程序，它保存着计算机最重要的基本输入输出的程序、系统设置信息、开机后自检程序和系统自启动程序。详见百度百科

2、read MBR's config to find out the OS

读取MBR配置查找需要启动的操作系统，MBR： Master Boot Record(硬盘的主引导记录)，它由三部分组成：主引导程序、硬盘分区表、硬盘有效标志。

3、load the kernel of the OS

加载操作系统的内核。注意这里有个一个选择操作系统的步骤。GRUB(the GRand Unified Bootloader)，是多启动规范的实现，它允许用户可以在计算机内同时拥有多个操作系统，并在计算机启动时选择希望运行的操作系统。GRUB可用于选择操作系统分区上的不同内核，也可用于向这些内核传递启动参数。

4、init process starts...

启动第一个进程init

5、execute /etc/rc.d/sysinit

init进程启动后，会执行/etc/rc.d目录下的sysinit命令

6、start other modules(etc/modules.conf)

加载其他模块，只有这些模块加载之后，网络、光驱等才可以使用。

7、execute the run level scripts

run level: linux内核启动完之后，后续的启动是分层次的。可以分任意层次进行启动，每个层次之间无直接关系，并且各层之间启动的程序不一样。

run level层次：

0) - 系统停机状态 /etc/rc.d/rc0.d/

1) - 单用户工作状态 /etc/rc.d/rc1.d/

2) - 多用户状态(没有NFS) /etc/rc.d/rc2.d/

3) - 多用户状态(有NFS) /etc/rc.d/rc3.d/

4) - 系统未使用 /etc/rc.d/rc4.d/

5) - 图形界面 /etc/rc.d/rc5.d/

6) - 系统正常关闭并重新启动 /etc/rc.d/rc6.d/

8、execute /etc/rc.d/rc.local

运行 /etc/rc.d/rc.local脚本。rc.local脚本主要用于自启动。

9、 execute /bin/login

执行/bin/login，展示系统登录界面。

10、shell started...

我们可以把这个步骤简化分为以下几个步骤：

1、BIOS Initialization

BIOS初始化

2、Boot Loader

1st Stage - small, resides in MBR or boot sector

2nd Stage - loaded from boot partition

3、Kernel initialization

内核初始化

4、init starts and enter desired run level by executing:

初始化启动，通过运行以下命令来执行run level

/etc/rc.d/rc.sysinit

/etc/rc.d/rc and /etc/rc.d/rc?.d/

/etc/rc.d/rc.local

X Display Manager if appropriate

基于BIOS、MBR、GRUB、Kernel、Init、run level六个概念，也有人将这个启动步骤分为这六部。关于Linux的启动，读者只需仔细理解研究这六个概念就可以了。

参考：

　　尚学堂科技轻松愉快LINUX视频教程

红帽RH133官方教程

　　6 Stages of Linux Boot Process

本文链接

程序员的学习和积累

2011-11-22T10:01:00Z

对于一个程序员来说，学习的重要性相信大家都能意识得到。如何才能有效地学习，高效地学习？探讨下这个问题，我认为很有必要。

每个人学习的方法和习惯可能都不尽相同，很多人习惯了在学校的学习方式，特别是很多刚出校门的人。在他们潜意识中，学习只是应付考试的一种手段，考完就一切OK了，全部还给老师了也无所谓，反正考完之后下次不会再考这么课程了(大学尤其如此)。长期的应试教育会让很多人以考试的心态来对待学习，我也是受害者之一，翻翻我硬盘中散落的各种语言编写的"hello world"，各种半成品，它们就像一张张60分、80分的试卷悄无声息地躺在某个昏暗的角落里。

职业生涯的学习一个最大的特点是具有持续性，你需要在某个知识或技能上花费你大部分精力。这时候，应付考试的学习方法已经不再有效了，而知识积累显得尤为重要。如果没有积累，所有的学习的成果都是一张60分的试卷。当你下次使用所学知识的时候，你手头有的就只有那张60分的试卷，你的学习将重新从0开始，由于时间关系或其他原因，你这方面的学习可能在你达到可以考60分的水平时又戛然而止，当你后面又需要使用时，又从0开始学习...如此循环往复，一定时期内，你的水平将永远停留在0-60分中间。

职业生涯学习的另一个特点是，你有机会去教。“The best method to learn is to teach”，你可以将你的所学通过各种形式的分享传授给他人。通过教的方式你不仅能够巩固你所学的知识，更能够推销自己、结交志同道合的朋友。

那么，基于职业生涯学习的特点，应该养成哪些好习惯呢，本人愚见，提出几点：

积累：

1、使用note。比如evernote，one note(个人推荐神器evernote)。作为一名程序员，如果你不使用note的话，显然你已经out了。你可以使用note来在任意时间记录你的想法、学习笔记、分享、待办事项等等任意你想记录的。

2、经营好你自己的资产。你的作品、代码、idea、你搜集到的资料都是你的资产。对其进行分门别类，同步到网络硬盘(注意信息安全)、多备份都是很好的选择。

1、将自己的知识总结成ppt、写出demo。要养成这种意识，当你形成ppt、demo的过程中，你将站在更高的层次去看待你学过的知识、加深你的理解。当然，如果有机会一定要去讲，不管是何种级别的分享，哪怕是自己给自己讲或是讲给自己身边的朋友。

2、写技术博客。博客有很多种，对博客的定位，决定你写什么样的博文。如果你的博文每篇都作为一个研究课题来写，我相信你打造一个精品博客一定是早晚的事情。当然我们可能没有要求这么高，那么博客也可以当note来使用(记录你每天的所学所想)，这样可能有好心的人会指出你博文中的错误，和你探讨相关的技术等等。

最后想谈下自己对技术书籍、博客订阅和技术社区、QQ群一些看法。现在社会的信息非常大，你可以通过很多渠道获得你想要的信息。但是，问题是信息的质量良莠不齐、信息量巨大，如果每天都把时间花在自己熟悉的信息上、每天都参与各种无意义的讨论(如语言之间的优劣)，那么反而学不到东西还会把自己弄得心烦意乱。

技术书籍：技术书籍应该是最严肃的获取信息方式，你可以通过对优秀技术书籍的研读、思考(特别注意思考这个词)，形成你知识的框架，这应该是一个稳固的结构。

技术博客和社区：这里是指订阅业界的博客，参与相关博客社区的技术交流。订阅业界、牛人的博客是获得最新、最前沿的知识和技术的方式，应该每隔一定时间段(如每天、每周2次等)研读这些文章、做好笔记。

QQ群(或其他即时通讯群组)：即时通讯是最直接的技术交流工具。通过这种工具交流技术、扩大职业圈子是一个很好的选择。但是鉴于目前，很多技术群很少谈论技术、或技术含量较低等情况，建议加入后仔细甄别，不要因为大量垃圾信息浪费宝贵的时间。

本文链接

mac下node js安装

2011-11-13T14:27:00Z

一向不喜欢追求刚刚新鲜出炉的事物的我，终于在node js出来一年后开始迈出脚步。

废话少说，先把环境给配置好。google "mac node"，出来几条结果，提供的方法基本一样，遂开始实践之。附google后的安装步骤：

1、安装xcode、git；

2、使用git将node源码拉到本地 git://github.com/ry/node.git

3、./configure

4、make

5、make install

还好之前有装过xcode、git，要不然光下载安装个xcode，今天晚上的时间完全报销(托网络不给力的福)。有了这两个玩意，安装应该轻松搞定。然而却出来几个问题，首先./configure的时候，有几个东西没有: openssl -> not found, library -> not found, fdatasync(2) with c++ -> no。然后make的时候悲催的报错了：build failed: -> task failed(err #1):...。

之后，我又重复了好几遍，都是没有成功，开始怀疑是否是openssl， library rt缺失导致的，准备装openssl神马的，顺便群里面问了句，有朋友建议使用node 0.6.1，然后跑到github上，download了最新版本的源码，重复google上的安装步骤，'build' finished successfully, 'install' finished successfully，搞定！原来是版本问题，当然具体是版本内部的什么问题，这里先不深究了，helloworld先出来再说。

安装成功后，将官网上的helloworld程序copy一份保存为helloworld.js到node安装目录下，

var http = require('http');
http.createServer(function(req, res){
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello World\n');
}).listen(8808, '127.0.0.1');
console.log('Server running at http://127.0.0.1:8808');

运行node helloworld.js，就能在命令窗口中(控制台)下看到"Server running at http://127.0.0.1:8808"的信息，在浏览器中输入localhost:8808，页面不能连接，悲催了，怎么回事。跑到控制台下看，报了一个错：The 'sys' module is now called 'util'. It should have a similar interface.貌似是要实现某个接口，可是不对啊，这可是官方提供的helloworld啊，还能出错。肿么回事？莫非又是版本问题？node -v之，版本为node-v0.6.2 pre，乖乖，0.6.2的最新版本，而我跑的是0.6.1的helloworld，出错了。既然官网目前提供了0.6.1的文档，还是先看看0.6.1吧。

　　好吧，又有重装了。这次吸取教训，从官网上把0.6.1版本驼下来，然后重复以上步骤，make install的时候又出错了，需要删除刚才安装的0.6.2 pre版本，因为它扎用了usr/local/include/node目录，其下的config.h不能重写。乖乖，没有sudo，没有权限，那就sudo拿到管理员权限，重新sudo make install，安装成功了。

　　继续跑node helloworld.js，console正常，并能访问localhost:8808，OK，终于搞定。也算一波三折。

留心一下，如果你的程序中有代码错误，控制台还是会先打印出console信息，然后再给你报出错误信息，比如使用0.6.2 pre版本报的那个错The 'sys' module is now called 'util'. It should have a similar interface，再比如你把res.writeHead携程rs.writeHead。

本文链接

css expression

2011-11-13T06:39:00Z

概述

css expression(css表达式)又称Dynamic properties(动态属性)是早期微软DHTML的产物，以其可以在Css中定义表达式(公式)来达到建立元素间属性之间的联系等作用，从IE5开始得到支持，后因标准、性能、安全性等问题，微软从IE8 beta2标准模式开始，取消对css expression的支持。

使用

微软提供了4个css expression方法：getExpression、recalc、removeExpression、setExpression。有兴趣可以参考msdn。

一般最常用的是直接在css中使用expression，例如：

1 .toTop{
2     top:expression(eval(document.documentElement.scrollTop + document.documentElement.clientHeight - 60)));
3 }

这是一个返回顶部按钮css代码的截取，用css来将元素定位到屏幕底部的位置。

优点

css exprssion技术达到了可以使用表达式或公式来定义css属性的目的，msdn上给出了它的几个优点：减少页面上的代码，使设计师无需学习javascript就能实现一些DHTML的效果。个人认为，减少页面上的代码实际上只是减少了相关javascript的代码，而css expression中的代码本身与js是及其类似，设计师无需学习js就能实现DHTML效果这个优点也很牵强，或曰鸡肋。

缺陷

.不符合web标准
css表达式这种在表现(css)中插入行为(js)代码，有悖于web标准的结构、表现、行为相分离的理念。
.效率低下
一个css表达式会反复执行，甚至执行成百上千次。这会大大消耗计算机的硬件资源，极端情况下会导致浏览器的崩溃。
.带来安全隐患
css表达式暴露了一个脚本执行的上下文，可能带来脚本注入的隐患。

基于以上原因，微软最终从IE8 beta2(标准模式下)开始放弃对css表达式的支持。

实际应用

早期很多开发人员利用css expression实现了许多效果，比如将元素相对鼠标指针进行定位，根据一个定时器来移动元素等等。当然这些效果能够使用js来实现。

虽然css表达式问题很多，但是我们依然能够在网上看到它们的影子，甚至在一些成熟的商业网站上。最常见的一个应用就是悬浮在页面上的某个模块(比如导航、返回顶部)。

我们来看一个常见的返回顶部按钮的代码实现：

html：

<!doctype html>
<html>
    <head>...</head>
    <body>
        <div id="top">...</div>
        ...
        <a href="#top" id="toTopBtn">返回的顶部</a>
    </body>

</html>

css:

#toTopBtn{
    position:fixed;
    bottom:10px;
    right:10px;
    _position:absolute;
    _top:expression(eval(document.documentElement.scrollTop + document.documentElement.clientHeight - 60));
    ...
}

_position和_top是对IE6的hack，因为IE6不支持position:fixed。这里的css表达式的作用是模拟position:fixed，即在将返回顶部按钮固定在页面的底部，不管页面是否滚动、缩放。正是因为css exprssion会执行多次，所以这个按钮元素才会一直定位在页面的底部。当然，我们可以使用javascript来模拟ie6的position:fixed，但细心的同学可能会发现这样一个问题，IE6下的返回顶部按钮会在你滚动页面的时候有较为明显的抖动。而我们使用css expression，这要在css加入以下规则，抖动的现象就会消失：

html{
    _background-image:url(about/blank);
    _background-attachment:fixed;
}

而使用js来模拟的，加上这句css规则也是没有效果的。这也应该是很多成熟商业网站现在还在使用css expression的原因。若有较好的实现方案，欢迎讨论。

但是，根据YSlow提供的网页优化建议：Avoid CSS Expressions，也由于css expression的各种问题，个人不建议使用css表达式。可以和产品人员协商，容忍ie6下这点抖动的瑕疵，或者采用动画来美化这个抖动效果，或者使用另外的一种方式来实现position:fixed，比如：固定页面的高度，让页面内部的内容可滚动，然后将返回顶部按钮绝对定位到底部(采用这种实现方式要慎重，因为或对页面布局和结构造成较大的影响)。

总结

CSS expression作为web时代临时解决方案的产物，在被其创建者无情的抛弃后，我们更应该摈弃这种较为丑陋的代码方式，采用更优的解放方案。

参考

　　About Dynamic Properties

　　Ending Expressions

本文链接

如何以最小成本将你的网站变成ipad应用

2011-09-10T14:10:00Z

.需求诞生和方案评审

.产品设计

.技术实现

.技术细节

.号外

.需求的诞生和方案评审

杜撰一个蛋疼的需求：假设你(web开发者)有一个电影类的网站(内容包含介绍、评论、影院信息等)，你如何用最小的成本将web网站的电影应用做成ipad应用？

首选方案：如果如果你老爸或儿子是ios开发者，成本将最小(不考虑情感成本)，或你爸是李刚、李双江(一分钱不花找人做)，成本也将最小。但是如果你既不是富二代、官二代，也暂时不是富二代、官二代他爹，这种方案可以忽略。

最蛋疼的解决方案：你可以用一个webview将这个网站的页面全部装起来，然后程序图标就算大功告成了。这似乎也是最好的解决方案了，就好比你在自己的ipad上加了一个这个网站的快捷方式，可以直接打开网页到达你需要的页面。

优化方案：如果你稍微勤奋点，你就会在原有的web网站基础上将其改造成一个适合ipad用户使用习惯的web app。于是，方案最终得以敲定。

.产品设计

由于ipad的屏幕足够大，根据ipad用户的使用习惯，用户喜欢在一屏中完成所有的任务而无需切换屏幕(不管你切换屏幕的动画做的是多么炫)。所以该应用的交互设计可以大体进行如下设计：

左侧是电影分类列表，展开一个分类列表，显示一个电影列表，展示电影的基本信息（如：电影海报、主演、导演、年份、国家、类型等）；右侧是若干个tab，每个tab都含有大量的信息。tab1，电影详细信息（剧情、花絮、截图）；tab2，影院信息（附近上映该影片的影院、地图信息）；tab3，电影的评论（也可以对添加自己的评论）。点击每个tab时，显示当前tab。

如果考虑到电影分类足够多，可以考虑三列展示，左中右分别是：分类列表、单个门类电影列表、单个电影详细信息(各种tab)。

.技术实现

毫无疑问，这样的需求和产品设计是需要大量的前端交互的，无他，需要使用大量使用javascript。

第一步：如果勤快点，可以做一个程序的启动动画，在进行启动动画时，加载页面中的电影分类列表和电影列表。当然你就别奢望在启动动画中将每个电影的每个tab中的内容也加载完，否则用户绝对不待见，在电影列表数据足够多的时候，只能将分类列表的内容放在这段时间加载。

第二步：假设启动时只加载了电影列表，那么在用户点击每个分类时，通过发送一个ajax请求，然后将请求回来的数据拼成html插入到页面中展示出来，并将请求的数据缓存起来。

第三步：当用户点击电影列表中的单个电影时，右侧显示有关该电影的各种信息的tab，并显示默认tab(如电影详细信息)，通过ajax技术并缓存请求的数据

第四步：点击其他tab时，显示该tab内容，若数据内容已缓存，使用缓存的数据；若不存在，通过ajax获取。

.技术细节

这里有一些具体的技术细节需要注意：

1、延迟加载

为了减少启动时间，一些静态文件需要进行延迟加载。例如每个tab的样式文件，需要用到的javascript文件。特别是评论tab，这里需要用户进行登录才能发表评论，发表想看、看过等信息，这个模块需要加载的javascript特别多。

2、脚本依赖问题

还以评论tab模块为例：这个模块中有很多javascript模块，如表单脚本、ajax登录注册模块、评论模块。评论时，若用户未登录则需要加载登录注册模块进行登录或注册，而登录注册模块中一些表单验证等脚本依赖表单脚本模块。处理这种模块依赖有很多模块加载器(loader)函数可以借鉴和使用，如YUI Loader， seajs等。

.号外

好吧，我承认，我也成了标题党。此博文是在我做了一个使用了类似技术纯网页web应用产生的一个灵感。为减少篇幅，没有粘贴具体代码，文中涉及的静态文件延迟加载和脚本依赖问题是时下前端探讨较多的技术，可以单独成文。

另外，动态加载在ie6下有个bug，若对a元素点击绑定事件函数中包含静态文件加载的代码，那么会导致静态文件加载不成功，被abord掉了。解决方案，当然，若是ipad应用，就不用考虑这个该死的ie6bug。
本文链接

html5本地存储在手机web app中使用探讨

2011-06-02T12:52:00Z

前段时间参与了一个手机app嵌入webview应用的项目，感触颇多。正如前一篇博文“html5+css3方式实现mobie app的一些瓶颈”所述，存在用web方式实现确实存在很多瓶颈。

最近研究了下竞争对手的一款mobie　app产品，存在一些值得学习和改进的地方：其首页（列表页）将所有的商品信息都请求下来，所以耗时会比较长。但由于是native　app，有程序启动画面和loading图片的存在，再加上手机用户对加载速度有心理预期，所以对用户体验影响不大。由于其对所有商品信息的缓存，用户由首页进入详情页后就可以将缓存的信息先展示给用户（而且缓存的信息刚好占满手机的一屏），其他内容随后加载。这样，用户由首页进入商品页和分类列表页时，给用户的感觉是相当之快。

他们用到的技术也没什么特别，也就是常说的本地存储。个人感觉，客户端做本地存储是相对容易的一件事情。html５的新特性中不是支持了对本地存储的功能吗，对于老版本不支持的本地存储的设备可以不用存储，也能达到优雅降级。故html５本地存储可以一试。

html５提供的本地存储的相关内容可以分为两个部分：客户端数据存储和离线存储。

客户端存储有localStorage, sessionStorage, Client-Side Database三种。localStorage和sessionStorage是简单的键值对存储，类似web中经常用到的cookie，也是通过js设置name和value；不同的是cookie会发送到服务器，并且其数量和大小有相应的限制。Client-Side Database则相对更强大一些，可以在本地进行创建数据库、本地数据库表进行增删查改等操作。

离线存储则是通过manifest文件对本地文件和需要服务器加载的文件进行配置，一般会对静态页、css、js、图片等静态文件进行离线存储类似于用浏览器在本地跑一个静态页面。当然好处是一些不变更的静态文件可以直接放在本地，而不需要从服务器端获取。

回到项目本身，我需要做的是将列表页面的数据缓存下来，然后在商品页预先显示出来，其他的数据再自行加载。这里我们可以通过使用客户端存储技术将所需的数据存储在本地，但问题是读取本地存储的操作是在js中进行的，而js赖以存在的商品页面不是存在本地的，而是需要和服务器建立连接从服务器获取的。而和服务器建立连接所花费的时间正是我们的瓶颈所在，本地存储的所产生的好处（一个html页面中少请求的一些字节）相比于此完全可以忽略不计。

再看看离线存储，我们倒是可以将一些持久化的css、js和图片放在本地通过manifest文件的配置，而无需从服务器端获取。但是也没有达到我们的项目需求。

至此，我看出来一些门道：B/S, C/S两种开发模式虽说有很多相同相似的地方，但其各自优缺点决定了其适合开发何种形式的程序。html作为web开发语言是为B/S开发服务的，即使html５提供了强大的一些特性，也是为web提供的，木有考虑到客户端开发。

不过，html５在制作mobile本地离线应用还是有较强的支持的，canvas、本地数据库对于制作本地应用还是提供相当大的便利。

本文链接