1.RGB模型：是一个通过与亮度有关的红色（Red）、绿色（Green）和蓝色（Blue）的组合来表现色彩，RGB模型基于色彩的相加;2.Lab色彩模式:Lab色彩模式可以说是最大范围的色彩模式，是一种与设备无关的色彩空间.Lab色彩模型用三组数值表示色彩. L：Lightness亮度数值，从0到100。 a：红色和绿色两种原色之间的变化区域，数值从-120到+120 b：黄色到蓝色两种原色之间的变化区域，数值从-120到+1203.YIQ色彩空间:YIQ色彩空间通常被北美的电视系统所采用，属于NTSC（NationalTelevisionStandardsCommittee）系统。4.YUV色彩空间:YUV色彩空间与YIQ色彩空间一样，都是使用于电视系统上，但不一样的是YUV色彩空间被欧洲电视系统所采用，属于PAL（PhaseAlternationLine）系统.5.YCrCb色彩空间:是一种常见的色彩空间。网络上比比皆是的JPEG图片采用的色彩空间正是该空间。它由YUV色彩空间衍生而来。其中，Y仍为亮度，而Cr和Cb则是将U和V做少量调整而得到的，Cr表示红色分量，Cb表示蓝色分量.6.HSI色彩空间:HSI色彩空间是从人的视觉系统出发，用色调（Hue）、色饱和度（Saturation或Chroma）和亮度（Intensity或Brightness）来描述色彩。.7.HSV(色相hue,饱和度saturation,亮度value),也称HSB(B指brightness)是艺术家们常用的，因为与加法减法混色的术语相比，使用色相，饱和度等概念描述色彩更自然直观。8.HSL(色相hue,饱和度saturation,明度lightness/luminance),也称HLS或HSI(I指intensity)与HSV非常相似，仅用“明度”（lightness）替代了“亮度”（brightness）。9.CMY/CMYK色彩系统:彩色印刷或彩色打印的纸张是不能发射光线的，因而印刷机或彩色打印机就只能使用一些能够吸收特定的光波而反射其它光波的油墨或颜料。不知有多少朋友遇到此类问题：在PS里处理好的图，发到论论坛上以后发现图片颜色大变，变得灰蒙蒙，失去了层次，色彩生硬，还有点发青。如果遇到过，那么，你一定要看这个帖子。吉雨、安梦问这个问题，我正好借花献佛把我的朋友西安摄友卓丰的一篇帖子转送给大家，希望对大家有所帮助。首先，先讲一讲预备知识：关于色彩空间。我们知道，显示器是红(R)绿(G)蓝(B)三种颜色来模拟自然界千变万化的颜色，而数码相机拍摄的图像也是RGB三色的信息。如果相机和显示器使用相同的数值来表示同一种颜色，那么我们在相机和显示器上看到的图的颜色应该是一样的。但是，不同厂商所开发的软件的这种颜色的对应关系不尽相同，于是产生了同样的图片在不同环境中颜色变得不一样的情况了。这种颜色与实际值的对应关系就是我要说的第一个名词：色彩空间。目前，最有名的是sRGB和AdobeRGB两种色彩空间。sRGB出现的比较早，是针对显示器仿色而研究的；AdobeRGB是Adobe公司针对印刷的色彩问题研究的。两种色彩空间不尽相同，于是就产生了上面的问题。一般情况下，小DC不存在这个问题，因为它默认的色彩空间就是sRGB。只有高档一点的DC和单反数码为了后期照片的色彩更真实，才默认把色彩空间设置成了AdobeRGB。这样，如果对片子做简单的调色裁剪缩放，那么片子依然保留着AdobeRGB的色彩空间，当我们把这样的片子发到论坛上时，问题就来了。我们一般用IE和其他浏览器来上论坛，而浏览器是不认识Adobe的，他会用sRGB的色彩对应关系来显示图片，于是，我们眼睛里看到的图片颜色就大变了。为了避免这种情况，必须在贴图之前，把图片的色彩空间转换过来。方法1、去除信息法：该方法是通过变换，把图片里的色彩对应关系除掉，让其自动转换为标准的sRGB色彩空间。操作方法：用任意图片处理工具打开图片，将图片另存为BMP格式，颜色选24位真彩色，格式选Windows。保存以后再打开对图片进行处理，此时图片已经被默认转换为sRGB了。这种方法没有什么技巧，可以称为笨办法，适用于任何人，不用急什么理论，参数，只要另存再打开就行了。但是，这个方法会把信息丢失，不仅仅是色彩空间，还有EXIF信息，而且文件大小会成几十倍的增加，不推荐使用。方法2、色彩空间统一法：该方法通过修改相机的色彩空间来达到色彩统一。即把相机的色彩空间设置成sRGB。具体设置方法各项几个不相同，需要看相机的说明。这种方法简单，不用做什么转换，但是，由于sRGB是针对屏幕显示而开发的，因此这样拍出来的照片如果拿出去冲印或打印，颜色有可能会变哦！方法3、色彩空间转换法：相机还是AdobeRGB，保证将来冲洗的质量；在法图前，利用工具将色彩空间由Adobe转换成sRGB，保证发的图颜色不变。
基本思路1.为什么要做组件化？无论前端也好，后端也好，都是整个软件体系的一部分。软件产品也是产品，它的研发过程也必然是有其目的。绝大多数软件产品是追逐利润的，在产品目标确定的情况下，成本有两个途径来优化：减少部署成本，提高开发效率。减少部署成本的方面，业界研究得非常多，比如近几年很流行的“去IOE”，就是很典型的，从一些费用较高的高性能产品迁移到开源的易替换的产品集群，又比如使用Linux+Mono来部署.net应用，避开WindowsServer的费用。提高开发效率这方面，业界研究得更多，主要途径有两点：加快开发速度，减少变更代价。怎样才能加快开发速度呢？如果我们的开发不是重新造轮子，而是每一次做新产品都可以利用已有的东西，那就会好很多。怎样才能减少变更代价呢？如果我们能够理清模块之间的关系，合理分层，每次变更只需要修改其中某个部分，甚至不需要修改代码，仅仅是改变配置就可以，那就更好了。我们先不看软件行业，来看一下制造行业，比如汽车制造业，他们是怎么造汽车的呢？造汽车之前，先设计，把整个汽车分解为不同部件，比如轮子，引擎，车门，座椅等等，分别生产，最后再组装，所以它的制造过程可以较快。如果一辆汽车轮胎被扎破了，需要送去维修，维修的人也没有在每个地方都修一下，而是只把轮胎拆下来修修就好了，这个轮胎要是实在坏得厉害，就干脆换上个新的，整个过程不需要很多时间。席德梅尔出过一款很不错的游戏，叫做《文明》（Civilization），在第三代里面，有一项科技研究成功之后，会让工人工作效率加倍，这项科技的名字就叫做：可替换部件（ReplacementParts）。所以，软件行业也应当引入可替换的部件，一般称为组件。2.早期的前端怎么做组件化的？在服务端，我们有很多组件化的途径，像J2EE的Beans就是一种。组件建造完成之后，需要引入一些机制来让它们可配置，比如说，工作流引擎，规则引擎，这些引擎用配置的方式组织最基础的组件，把它们串联为业务流程。不管使用什么技术、什么语言，服务端的组件化思路基本没有本质差别，大家是有共识的，具体会有服务、流程、规则、模型等几个层次。早期展示层基本以静态为主，服务端把界面生成好，浏览器去拿来展示，所以这个时期，有代码控制的东西几乎全在服务端，有分层的，也有不分的。如果做了分层，大致结构就是下图这样：这个图里，JSP（或者其他什么P，为了举例方便，本文中相关的服务端技术都用Java系的来表示）响应浏览器端的请求，把HTML生成出来，跟相关的JavaScript和CSS一起拿出去展示。注意这里的关键，浏览器端对界面的形态和相关业务逻辑基本都没有控制权，属于别人给什么就展示什么，想要什么要先提申请的尴尬局面。这个时期的Web开发，前端的逻辑是基本可忽略的，所以前端组件化方式大同小异，无论是ASP还是JSP还是其他什么P，都可以自定义标签，把HTML代码和行间逻辑打包成一个标签，然后使用者直接放置在想要的地方，就可以了。在这一时代，所谓的组件化，基本都是taglib这样的思路，把某一块界面包括它的业务逻辑一起打成一个端到端的组件，整个非常独立，直接一大块从界面到逻辑都有，而且逻辑基本上都是在服务端控制，大致结构如下图所示。3.SPA时代，出现了新问题自从Web2.0逐渐流行，Web前端已经不再是纯展示了，它逐渐把以前在C/S里面做的一些东西做到B/S里面来，比如说Google和微软的在线Office，这种复杂度的Web应用如果还用传统那种方式做组件化，很显然是行不通的。我们看看之前这种组件化的方式，本质是什么？是展现层跟业务逻辑层的隔离，后端在处理业务逻辑，前端纯展现。如果现在还这么划分，就变成了前端有界面和逻辑，后端也有逻辑，这就比较乱了。我们知道，纯逻辑的分层组件化还是比较容易的，任何逻辑如果跟展现混起来，就比较麻烦了，所以我们要把分层的点往前推，推到也能把单独的展现层剥离出来。如下图所示，因为实际上HTML、CSS、JavaScript这些都逐渐静态化，所以不再需要把它们放在应用服务器上了，我们可以把它们放在专门的高性能静态服务器上，再进一步发展，就可以是CDN（ContentDeliveryNetwork，内容分发网络）。前端跟后端的通信，基本都是通过AJAX来，也会有一些其他的比如WebSocket之类，总之尽量少刷新了。在这张图里面可以看到，真正的前端已经形成了，它跟应用服务器之间形成了天然的隔离，所以也能够很独立地进行一些发展演进。现在很多Web程序在往SPA（单页面程序，SinglePageApplication）的方向发展，这类系统通常比较类似传统的C/S程序，交互过程比较复杂，因此它的开发过程也会遇到一些困难。那为什么大家要做SPA呢？它有很多明显的好处，最核心的优势就是高效。这个高效体现在两个方面：一是对于用户来说，这种方式做出来的东西体验较好，类似传统桌面程序，对于那些需要频繁操作的行业用户，有很大优势。二是运行的效率较高，之前集成一些菜单功能，可能要用iframe的方式引入，但每个iframe要独立引入一些公共文件，服务器文件传输的压力较大，还要初始化自己的一套内存环境，比较浪费，互相之间也不太方便通信，一般要通过postMessage之类的方式去交互。有了SPA之后，比如一块界面，就可以是一个HTML片段，用AJAX去加载过来处理之后放到界面上。如果有逻辑的JavaScript代码，也可以用require之类的异步加载机制去运行时加载，整体的思路是比较好的。很多人说，就以这样的需求，用jQuery再加一个异步js加载框架，不是很足够了吗？这两个东西用得好的话，也是能够解决一些问题的，但它们处理的并不是最关键的事情。在Web体系中，展现层是很天然的，因为就是HTML和CSS，如果只从文件隔离的角度，也可以做出一种划分的方式，逻辑放在单独的js文件里，html内部尽量不写js，这就是之前比较主流的前端代码划分方式。刚才我们提到，SPA开发的过程中会遇到一些困难，这些困难是因为复杂度大为提升，导致了一些问题，有人把这些困难归结为纯界面的复杂度，比如说，控件更复杂了之类，没有这么简单。问题在于什么呢？我打个比方：我们在电脑上开两个资源管理器窗口，浏览到同一个目录，在一个目录里把某个文件删了，你猜猜另外一个里面会不会刷新？毫无疑问，也会刷新，但是你看看你用的Web页面，如果把整个复杂系统整合成单页的，能保证对一个数据的更新就实时反馈到所有用它的地方吗？怎么做，是不是很头疼？代码组织的复杂度大为提高，所以需要做一些架构方面的提升。4.架构的变更提到架构，我们通常会往设计模式上想。在著名的《设计模式》一书中，刚开始就讲了一种典型的处理客户端开发的场景，那就是MVC。传统的MVC理念我们并不陌生，因为有Struts，所以在Web领域也有比较经典的MVC架构，这里面的V，就负责了整个前端的渲染，而且是服务端的渲染，也就是输出HTML。如下图所示：在SPA时代，这已经不合适了，所以浏览器端形成了自己的MVC等层次，这里的V已经变成客户端渲染了，通常会使用一些客户端的HTML模版去实现，而模型和控制器，也相应地在浏览器端形成了。我们有很多这个层面的框架，比如Backbone，Knockout，Avalon，Angular等，采用了不同的设计思想，有的是MVC，有的是MVP，有的是MVVM，各有其特点。以Angular为例，它推荐使用双向绑定去实现视图和模型的关联，这么一来，如果不同视图绑定在同一模型上，就解决了刚才所说的问题。而模型本身也通过某种机制，跟其他的逻辑模块进行协作。这种方式就是依赖注入。依赖注入的核心理念就是通过配置来实例化所依赖的组件。使用这种模式来设计软件架构，会牺牲一些性能，在跟踪调试的便利性等方面也会有所损失，但换来的是无与伦比的松耦合和可替代性。比如说，这些组件就可以单独测试，然后在用的时候随手引入，毫无压力。对于从事某一领域的企业来说，光这一条就足以吸引他在上面大量投入，把所有不常变动领域模型的业务代码都用此类办法维护起来，这是一种财富。5.MV*框架的基本原理如果我们来设计Angular这么一个前端框架，应当如何入手呢？很显然，逻辑的控制必须使用JavaScript，一个框架，最本质的事情在于它的逻辑处理方式。我们的界面为什么可以多姿多彩？因为有HTML和CSS，注意到这两种东西都是配置式的写法，参照后端的依赖注入，如果把这两者视为跟Spring框架中一些XML等同的配置文件，思路就豁然开朗了。与后端不同的是，充当前端逻辑工具的JavaScript不能做入口，必须挂在HTML里才能运行，所以出现了一个怪异的状况：逻辑要先挂在配置文件（HTML）上，先由另外的容器（浏览器或者Hybird的壳）把配置文件加载起来，然后才能从某个入口开始执行逻辑。好消息是，过了这一步，逻辑层就开始大放异彩了。从这个时候开始，框架就启动了，它要做哪些事情呢？初始化自身（bootstrap）异步加载可能尚未引入的JavaScript代码（require）解析定义在HTML上的规则（templateparser）实例化模型（scope）创建模型和DOM的关联关系（binding,injection）这些是主线流程，还有一些支线，比如：解析url的search字符串，恢复状态（route）加载HTML部件模板（templateurl）部件模板和模型的关联（binding）6.如何做组件化6.1.HTML的组件化SPA的一个典型特征就是部分加载，界面的部件化也是其中比较重要的一环。界面片段在动态请求得到之后，借助模版引擎之类的技术，经过某种转换，放置到主界面相应的地方。所以，从这个角度来看，HTML的组件化非常容易理解，那就是界面的片段化和模板化。6.2.JavaScript的组件化JavaScript这个部分有好几个发展阶段。早期的共享文件，把公共功能的代码提出出来，多个页面共用动态引用，消灭全局变量在某些框架上进一步划分，比如Angular里面又分为provider，service，factory，controllerJavaScript组件化的目标是什么呢，是清晰的职责，松耦合，便于单元测试和重复利用。这里的松耦合不仅体现在js代码之间，也体现在js跟DOM之间的关系，所以像Angular这样的框架会有directive的概念，把DOM操作限制到这类代码中，其他任何js代码不操作DOM。如上图所示，总的原则是先分层次，层内再作切分。这么做的话，不再存在之前那种端到端组件了，使用起来没有原先那么方便，但在另外很多方面比较好。6.3.CSS的组件化这方面，业界也有很多探索，比如LESS，SASS，Stylus等。为什么CSS也要做组件化呢？传统的CSS是一种扁平的文本结构，变更成本较高，比如说想要把结构从松散改紧凑，需要改动很多。如果把实际使用的CSS只当作输出结果，而另外有一种适合变更的方式当作中间过程，这就好多了。比如说，我们把一些东西定义成变量，每个细节元素使用这些变量，当需要整体变更的时候，只需修改这些变量然后重新生成一下就可以了。以上，我们讨论了大致的Web前端开发的组件化思路，后续将阐述组件化之后的协作过程和管控机制。管控平台1.HTML片段我们为什么要管理HTML片段？因为有界面要用它们，当这些片段多了之后，需要有个地方来管理起来，可以检索、预览它们，还能看到大致描述。这应该是整个环节中一个相对很简单的东西，照理说，有目录结构，然后剩下的就是单个的HTML片段文件了，这就可以解决存储和检索的问题了，但我们还要考虑更多。已有的HTML片段，如何被使用呢？这肯定是一种类似include的方式，通过某种特殊标签（不管是前端还是后端的方式）把这些片段引用进来，这时候就有了第一个问题：假设有界面A和界面B同时引用了片段C，在某个开发人员修改片段C内容的时候，他如何得知将会影响到界面A和B呢？一个比较勉强的方式是全项目查找，但这在很多情况下是不够的。如果我们的HTML片段是作为独立的公共库存在的，它已经不能通过项目内查找去解决这一问题了，因为不管A还是B，只要他不处于片段C的项目空间，就无从追寻。这时候很多人会问两个问题：跨项目的界面片段重用，意义在哪里？如果我们的产品是针对一个小领域，它的复杂度根本不需要划分多个项目部分来协作完成。设想场景是面对很大的行业，各项目都是子产品，将来可能是其中若干个联合部署，这时候，保持其中的一致性是非常重要的。比如我们有个基本配置界面，在多个子产品中都要用，如果各自开发一个，其操作风格很可能就是不一致的，给人的印象就是不专业。所以会需要把常见的界面片段都归集起来，供业务方挑选使用。修改C，只提供说明，但是不通知A和B，不实时更新他们的版本，然后自行决定怎样升级，如何？这会有一个问题，每次有小功能升级的时候，代码是最容易同步合并的，所以才会有“持续集成”这个概念，如果是一直伴随升级，总要比隔一个大阶段才升级好，升级成本应尽量分摊到平时，就像农妇养小猪，小猪每天长一点，每天都抱来抱去，不觉得吃力，即使长大了也还能抱得动。现在问题就很明确了，一定要有一种方式来把这个依赖关系管理起来，很显然，已有的版本库是肯定管不了这些的，所以只能在外围做一些处理。我们建立一个管理平台，除了管理实体文件的版本，还管它们之间的关系。具体这个关系如何收集整理，有两种方式：手动配置，代码分析。手动配置是比较土的方式，开发人员每提交一个文件，就去这系统上手动配置它的依赖关系。代码分析的话，要在每次提交文件的时候解析文件的包含规则，找出确切的文件。这两者各有利弊，前者比较笨，但容易做，后者对代码格式的要求比较高，要考虑的情况较多。我们的界面往往不是那么简单，HTML片段也可能有层次的，举例来说：界面A里面包含了片段B，但是片段B自身又包含了片段C，所以这个依赖关系也是有层级的，需要在设计的时候一并考虑。2.JavaScript模块JavaScript代码的管理，比HTML片段的状况好一些，因为业界很多这方面的解决方案。但它们还是没有解决当依赖项产生变更的时候反向通知的问题。所以我们还是得像HTML片段一样，把它们的依赖关系都管理到平台里。于是，每个JavaScript模块都显式配置了自己所依赖的其他模块，通过这种单向关系，形成了一套完整的视图。在JavaScript模块的代码实现中，我们是不提倡直接写依赖关系的。很多通用规范，比如AMD，往往建议我们这样写模块：define(['dep1', 'dep2'], function (dep1, dep2) { var moduleA = function () {}; return moduleA; }); 但我们的系统是面向行业的，比这种通用解决方案要苛刻一些。比如说，如果有一天重构代码，JavaScript模块们调整了目录或者名字，这么写的就痛苦了，他必须把所有影响到的都去调整一遍，这是要搜索替换的。况且，就像上面HTML模板的部分提到的，影响了处于其他项目中依赖它的代码，缺少合适的方式去通知他们修改。所以我们期望的是，在每个编写的JavaScript模块中只存放具体实现，而把依赖关系放在我们的平台上管理，这样，即使当前模块作了改名之类的重构处理，处于外部项目中依赖它的那些代码也不必修改，下一次版本发布的生成过程会自动把这些事情干掉。对应到上面的这段代码，我们需要开发人员做的只是其中的实现，也就是moduleA的那个部分，外面这些依赖的壳子，是会在发布阶段根据已配置的依赖关系自动生成的。如果需要，JavaScript模块还可以细分，比如类似Angular里面那样，把factory，controller和directive分离出来，这会对后续有些处理提供方便。现在我们有必要讨论一下模块的粒度了，我们这里提到的都是基本的粒度，每个JavaScript模块中存放的应该只有一个很具体东西的实现。那么，有个问题，在我们发布的时候，是不是就按照这个粒度发布出去呢？很显然不行，如果这么做，很可能会出现复杂界面一次要用10多个HTTP请求才能加载完它所需要的所有JavaScript代码的情况，所以需要做一些合并。那么，合并的策略是什么？在我们这个平台上，开发人员又是要怎样定义这个合并关系的呢？我们需要在模块之上定义一个更大粒度的组织方式，这个方式与模块的关系，就好比Java里面，jar文件与class的关系。如果开发人员不显式配置，也可以通过全局策略，比如按最下层目录来合并。这个时候，在实际使用这些代码的时候，需要带两个配置信息过去，一个是要动态载入的JavaScript文件（合并之后的），二是每个JavaScript文件中包含的原始模块。3.单元测试如果JavaScript模块都已经被良好有序管理起来，就可以为它们考虑单元测试的事情了。单元测试对于提高基础单元的可靠度，是有非常重要意义的。在我们这个平台里，可以把单元测试跟JavaScript模块关联起来，每个JavaScript模块可以挂一组单元测试代码，这些代码可以在线编写，在线运行。单元测试的本质就是编写模拟代码来调用已有模块，考虑到我们的模块是JavaScript，所以很多思路都倾向于在浏览器端执行它们，对于单个模块的单元测试，这不是个问题。如果要批量执行整个系统的单元测试，那就不一样了。把JavaScript代码先加载到浏览器中，然后再执行，很多时候并不需要这么复杂。我们完全可以在服务端把它们做了。借助Node.js的能力，我们可以在服务端执行JavaScript代码，也就意味着能够把绝大多数JavaScript模块的单元测试在服务端就执行掉。当然，我们为此可能要多做不少事情，比如说，有些库需要移植一份node版的，常见的有AJAX调用等等。注意了，能够在服务端做JavaScript单元测试是有先决条件的，代码的分层必须很良好，除了视图层，其他任何层面都不能操作DOM。所以我们这里主要测试的也正是除了视图层之外的所有JavaScript业务逻辑。至于视图层怎么办？这个真的很难解决，这世界上不是所有东西都能自动做的，只能先把可做的做了，以后再来考虑这些。4.文档和示例管理4.1.文档现在我们有HTML片段和JavaScript模块了，需要给它们多一些描述信息。简单描述显然是不够的，我们还要详细文档。这种详细文档可以通过某种方式生成，也可以由开发人员手动编写。与传统的离线文档不同，在线的文档更实时，并且，每当一个开发人员变更了他的文档之后，不需要经过全量构建，访问者可以实时访问到他的最新版本。熟悉GitHub的朋友们可能早已习惯这种方式，在项目库里面存在一些以md格式结尾的文本文件，使用markdown语法来编写一些说明文档。毫无疑问，这类格式很适合在线协作，所以我们也会在平台上集成这么一种编写文档的方式，无论是针对HTML模板还是JavaScript模块，或者是其他什么类型，甚至还可以用来当博客，就像月影同学的gitpress平台，能直接从GitHub上拉取文本或者HTML文件形成博客。文档除了以集成的形式浏览之外，应当也可以以单独链接的方式发出去，这时候用户就可以像看一个新闻网页一样去浏览。如果再进一步做下去，还可以做电子书的生成，提供打包的离线文档。4.2.示例在编写代码文档的过程中，可能免不了要插入示例，示例有两种形态，一种是纯文本，类似gist这样，一种是可在线运行，类似jsfiddle和jsbin这样。这两种都有各自的优点，所以可以都做，示例的存放可以与文档类似，也应当能通过一个链接独立运行。4.3.幻灯片有时候我们看到一些在线的幻灯片，觉得效果很帅，比如reveal.js，我们的开发人员有时候作代码分析或者走查的时候也不免要写一些演示，如果能把这些东西也随项目管理起来，能在线查看，会是很不错的一件事。所以我们也可以考虑给它们加个存储界面，甚至做个简易的在线编写器。5.项目与目录管理说到现在，我们似乎还遗漏了一点什么。那就是以上提到的这些东西，以什么为组织单位来存储？考虑到我们的这个平台是要管理一整个大产品的全部前端内容的，它里面应该分了很多项目，对应到子产品上，这么一来，很自然地，项目就成了第一级组织单位。项目之下，没有悬念地，只有目录了。对于一个项目而言，它有哪些要做的事情呢？首先要能配置其实体存储位置。前面提到的这么多代码、文档之类，最终都是要实体存储的，怎么存？我们当然可以自己搞一套，在文件系统上做起来，但是还要考虑它们的版本管理，非常麻烦，所以不如直接对接某个版本库，调用它的接口去存取文件，这里配置的就是版本库的路径。其次，要考虑从已有项目复制，类似GitHub里面的fork功能，不过内部处理机制可以略有不同，fork的项目默认未必要有实体文件，只有当产生了修改或者新增操作的时候才创建，剩下的还引用原来的就可以了。我们这里的项目复制功能是为项目化版本而考虑的，经常出现一个产品版本支持多个客户项目的情况，所以可能会用得着这个特性。然后，也要考虑项目的依赖关系。依赖一个项目，意思是需要用到它里面的组件，所以实质是组件的依赖。提供项目依赖这个视图，只是为了未来变更的一些考虑。6.评论管理之前提到，我们整个平台的目的是为了提高大型前端团队的协作能力，协作是离不开交流的。上述的任何功能，都应当带有交流沟通的能力。比如说，如果开发人员A使用了其他人写的一个代码组件a，对其中一些细节有疑问，他应当可以对它进行评论。在他评论的时候，任何参与维护过这个组件的人员都能收到一个提醒，这时候他可以选择过来看看，回复这个疑问。同理，在文档、示例下也可以如此操作。在互联网上有这类产品，用于在任意URL下挂接评论交流系统，比较有名的就是Disqus，我们可以看到很多网站下面挂着它，用于做交流评论，这样用户可以用一个账号在多个网站之间交流。国内也有同类的，比如多说，能够用微博、QQ等账号登录进行交流。从我们这个平台本身看，如果是部署在企业内部作流程提升，引入外部评论系统的可能性就比较小了。因为在企业内部用，一定是希望这个员工的账号信息跟工号挂钩，也能够跟版本服务器账号等模块作集成，权限也便于控制。从另外一个角度讲，某个人员登录这个系统的时候，他可能收到很多消息，来自不同的代码或文档位置，挨个点过去回复也有些麻烦，我们应当给他提供一个全局视图，让他能在一个统一的界面把这些问题都答复掉，如果他需要的话，也是可以点进去到实际的位置。7.用户和权限控制从以上部分我们已经看到，这个系统是一个比较复杂的开发过程管控平台。这样的话，每个使用的人就应当可以登录，然后分配不同的权限等级。未登录用户应当有一些东西的查看权限，但是不能发表评论。已登录的用户根据权限级别，可以控制能否创建、修改项目，创建、修改目录，代码，单元测试，文档等。8.国际化字符串管理一个跨语言区域的Web应用不可避免要跟国际化打交道，这个事情通常是在服务端做，比如通过在界面代码中嵌入类似这样的代码，去获取相应的字符串，替换到界面里来。这个事情是要占用应用服务器资源的，而且国际化本身其实是一个在运行之前就已经确定的事，完全可以把这个过程放在发布阶段就做掉。比如说，我们给每种语言预先就把代码生成多份，只是部署在一起，根据需要的情况来动态加载特定的那一份。有不少客户端的国际化方案，是把资源文件拆细，以页面为单位存储，但这其实是不太合理的。第一个原因就是在Web2.0时代，“页面”这个概念本身就已经弱化了，到了单页应用里，整个应用都只是一个页面，这个时候，资源文件以什么粒度来组织呢？我们提到过，采用MV*框架去做Web应用的架构，有一个目标是做组件化。组件化的意图就是某个组件可以尽可能随心所欲地放在需要的地方用。如果把资源文件的粒度弄小到对应HTML片段和JavaScript模块这一级，灵活性倒是有了，带来的问题就是管理成本增大。做一个行业应用，最重要的就是业务一致性，这包括逻辑的一致性，也包括了术语的一致性。某一个词，可能在多个资源文件中都出现，这就增加了不一致的可能性。所以，应当有一个统一的术语管理平台，一切界面上出现的文字或者提示，都必须来自这个平台。9.静态资源的管理在发布系统的时候，除了需要发布代码，还需要发布图片等静态资源，这些东西也应当被管理起来。静态资源在两种情况下可用：随产品发布，在本平台被引用。比如说有一个图片，在这个平台上作了管理，它可以被配置到某个项目上，在发布的时候导出。这个图片还可以被用链接的方式查看或者下载，如果本平台内部的一个文档或者示例要引用它，也是可以的。10.样式与主题管理在Web系统里，样式和主题是很重要的一环。样式的管理和发布一直是一个比较复杂的话题，早几年一般都是分块写，然后组合合并，最近这些年有LESS，SASS和Stylus这类技术，解决了编写和发布的分离问题。我们看看发布的最大问题是什么？是不同部分的合并。为了追求灵活性，不得不把东西拆得很细，之前HTML片段和JavaScript模块的处理方式都是这样。这么做，我们就需要另外一件事：这些细小的东西，尽可能要覆盖全面。对应到CSS里面，我们要做的是把每种在系统中可能出现的元素、类别都作为单独的规则维护起来，生成一个全局的规则列表。不同项目间，实现可以不同，但规则的名字是固定的，定制只允许修改实现，不允许修改规则。如果要新增之前没有的规则，也必须在全局规则列表里先添加，再作实现。样式规则被管理之后，可以在界面组件上对它作关联，也可以不做。做的好处是发布的时候能只把用到的那些样式规则生成发布出去，如果能接受每次发布全量CSS，那也无所谓。除了规则，也需要考虑一些变量的管理，在CSS中合理使用变量，会大为减轻定制化所导致的工作量。11.一键发布我们引入了这么一堆东西，其实是增加了发布的复杂度。为什么呢？之前不管HTML、JavaScript还是CSS，都是手写出来，最多经过一个minify的工作，就发布了，整个过程很简单，两句脚本搞定。现在可复杂了，先要分析依赖关系，然后提取文件，然后国际化字符串替换，然后合并，然后代码压缩，整个过程很折腾，不给配置管理员一个解释的话，他一定过来砍人。我们有个原则：解决问题的过程中，如果引入了新的问题，要求负责解决原问题的人也一起解决掉。现在为了一些意图，增加了版本发布的复杂度，那也要有个办法再把这事摆平，至少不能比原来复杂。所以我们就要把这些过程都集成到管控平台里，做一个一键发布的过程，把所有的这些操作都集成起来，配置管理员发布版本的时候只要点一下就可以把所有这些事情做掉。甚至说，这些流程还可以配置，能够加减环节。这时候我们做到了跟之前发版本一样方便，能不能多做点什么呢？可以把JavaScript单元测试集成到版本发布阶段。因为我们已经把JavaScript按照职责做了分层，并且把UI部分做了隔离，就可以在浏览器之外把这个单元测试做掉，平时提交代码的时候也可以做，最终在版本发布阶段再全量做一下，也是很有意义的。代码依赖关系管理的另一个目的是什么呢？是最小化发布，既然我们都管理了文件之间的关系，那么，从根出发，显然是能够得出哪些代码文件在本项目中使用的，就可以每次从我们的全量代码库中取得确切需要的一部分来发布。这也是我们整个管控平台带来的优势。12.小结我们这一篇比较复杂，提出了一整套解决大规模前端协作的管控机制。这套理论的本质是在开发和版本发布之间加了一个环节，把Web体系中除了服务之外的一切静态资源都纳入其中，强化了现有主流的一些基于命令行的前端工程化组织模式。相比于传统行业，比如汽车制造，我们这个环节相当于生产流水线的设计，其中一些组件的存储就类似仓储机制，发布就类似出厂过程。这个平台本身还有不少其他的可做的东西，比如甚至可以在上面做界面的可视化定制等，这些是长远的终极目标，在后面的文章里会谈谈一些考虑。
随着百度算法的不断进步，越来越多的站长朋友开始认识到搞友链的重要性，因为新的百度算法相对弱化了外链的作用，提升了对外链相关性的要求，同时更加重视外链平台本身的质量，而友情链接作为一种重要的外链形式，如果运作的很好的话，还可以找到一些高质量的相关性网站平台进行友链，这对于网站的排名提升具有非常重要的作用。友链的推荐作用要明显的大于简单的外链推荐，因为友链在搜索引擎算法中认为是物以类聚人以群分原则的最佳体现形式。然而近年来在外链的疯狂优化下，重视外链忽视友链竟然成了常态，当然现如今随着百度算法的革新，让广大战长朋友们对此有了新的认识，当然友链在数年的发展过程中，却开始出现了很多猫腻，让不少不懂行的站长朋友们很容易中招，让自己绑了别人，而别人却没有帮自己!友链的互惠作用并没有体现出来。第一，网站虽然和你友链，但是却没有给你导入权重，由于不少懂行的站长朋友们能够观测到和你友链网站的源代码，其实在友链区域，有些心怀不轨的站长朋友们虽然乐意和一些权重相对偏低的网站进行友链，这往往会让这些网站受宠若惊，可事实上在导入你的网站链接时，往往对超链接增加了nofollow属性，还有就是通过javascript脚本语言，将导入的链接开启了失效模式，百度蜘蛛读取不了，但是在页面上却能够显示，并能够点击进入友链的网站，这样从表面上和正常的友链并无二致，能够骗取不少站长的信任。第二，网站降权了却依然在友链，有些被降权的网站为了尽快提升自己网站的搜索引擎排名，自然就会想尽快找到一些不降权的网站，且具有相关性的网站进行友链，当然这类网站本身在降权过后，在搜索引擎上的相关收录信息都不会立刻消失，总会在一段时间后才会出现影响，这样的网站就容易对不少做友链的站长朋友产生迷惑。当别人通过工具检查这类刚刚被降权的网站收录情况时，总会显示不错的收录量，网站的首页也非常的具有品牌特征，进行友链是一个不错的选择，可是这样的网站一旦进行，很有可能就让你的网站受到影响。甚至遭遇连带处罚。第三，寻找的友链网站数量不应该多过，现在互联网上有些网站是专门通过和别人友链来进行牟利的，所以网站上的友链数量有一百个以上，整个页面的下半部基本上被友链所占领，由于这样的网站友链数量多，所以自己网站的权重总体上还是不错的，同时也能够获得一定的排名，然而随着友链数量的增多，却不可避免的会让网站友链导出的链接权重会变得更低，也就是说友链的效果并不明显，对于这样的网站，对于站长们来说一定和他们说不。总而言之，友链运作的情况现在有诱惑，同时对于网站的排名也具有非常重要的作用，作为站长朋友们要认识到友链本身的价值，同时还要注意规避进入友链的陷阱，在寻找友链伙伴时，哪怕寻找一些质量比自己略低，但是却具有高成长性的网站，这时候你在帮助了别人的同时，也会随着友链网站不断的进步而在帮助自己!
近日，谷歌官方在GoogleAdSense十周年讲座上发布了移动建站十大原则，由于是PPT形式，所以小生把它整理成文字版的移动网站建站原则(也可以看做是谷歌手机站优化指南)，供广大站长参考。有兴趣的站长也可以对比下百度发布的手机站优化指南，看一看立足于中文本地搜索引擎的百度与有国际视野的谷歌在移动网站优化上有哪些共同点和区别，在此仅总结谷歌发布的移动网站建站原则，当然这份移动建站原则也是偏向于中文站长的。1、简单快捷所谓简单快捷，就是要在手机有限的屏幕上以最简单最实用最快捷的形式展示给用户最需要的东西，让用户方便。谷歌的建议是：优先提供用户最需要的内容和功能减法，减法，减法(解释一下，这一点其实就是在强调手机网站要去掉一切可以去掉的内容、功能、板块、按钮等，只留下最精华的部分，记住是最精华的部分。谷歌举例了淘宝的移动网站)精简文字压缩图片以提升网站加载速度2、简化导航明确的目录结构，避免用户横向滚动页面提供醒目的“后退”和“首页”按钮对于导航的目录结构，谷歌列出了四种常见的手机网站的导航形式，分别是：横条式(谷歌指出，根据手机屏幕尺寸以及统计数据显示，横条最好不要超过7个)大按钮式(这种形式是手机站最常见且应用最多的导航形式)列表式选项式3、拇指操作较大的按钮，降低操作难度适当的空间，避免意外点击(与加宽间距目的一样，都是为了扩大点击范围，防止用户因为按钮较小而误点其它选项或内容而造成的不便。也就是在有限的手机屏幕上再适当给按钮做些留白)间距加宽，扩大点击范围使用颜色和阴影凸显按钮这一点不仅仅是针对搜索引擎的优化设计，更是手机站针对用户体验的人性化设计，在这一点上，谷歌考虑的更周全些。4、一目了然确保内容与屏幕大小一致背景和文字颜色的鲜明反差使用留白空间整齐的排版舒服的字型大小这一点同样是考虑用户体验的问题，如果是第三点是考虑用户手感或者说触感的话，第四点就是考虑用户的观感。5、广泛适应网站能在不同的移动设备上运行移除flash，使用HTML5来实现互动内容和动画根据屏幕方向调整显示很多站长可能不太懂HTML5相关技术以及自适应网页技术，没关系，百度的手机站优化指南有相关知识，还是不明白的话，百度一下，你就知道。6、轻松转化简化注册登录流程减少使用者输入：使用表单、菜单、选择框着重提供有助于转化/注册的信息还是尽可能的给用户提供方便，减少给用户带来的麻烦，节约用户的时间和浏览成本，要知道，时间就是金钱。7、立足本地与用户位置相结合的个人化信息地图、路线、电话、本地信息等在所有提供内容当中，除非用户是找寻通用信息，所以本地化信息是最对用户有帮助的。8、流畅体验允许用户保存搜索、书签、购买等信息尽可能在所有平台提供相同信息和功能(即无论是PC端、平板端还是手机端都保持网站信息的一致性)9、重新定向自动判断移动设备，重新定向相应适合的网站内容(自适应网页技术，根据不同的移动设备和屏幕尺寸，来显示相应的网站内容)让用户可以切换电脑版与移动版网站让用户选择下次访问的版本10、持续改进使用分析工具，了解用户如何使用网站收集用户意见并反复测试，追踪表现移动网站不是移动应用，所以可以持续的改进并调整。
几年前，做app还是土豪和移动开发者的专利。移动开发者使用java或者c++这类开发工具，将一行行代码变成可以被手指轻松触控的应用。土豪们花钱雇佣这些移动开发者，实现自己所想要的功能。制作一个手机app被普遍认为是难度很高的工作。但随着人们对app定制化的要求越来越高，云服务提供商的能力越来越强。国内外的saas企业纷纷推出了在线生成app的功能，不但功能强大、免费使用，而且步骤极其简单。甚至有厂商喊出了“无需编程知识，3分钟搞定app”的口号。使用本文所述的在线自助app制作工具，您可以轻松完成工作，实现梦想。2013年在国内流行app快速创建服务，主要由以下两类组成。无负担完全自建app该类服务以国内的简网app工场为代表，他们的app生成步骤只需3步，分别是填写概括、上传素材、设定风格。如图所示。填写概括上传素材设定风格然后，你就可以下载已经生成完毕的app了。如图所示。app生成完毕这里需要向大家说明的是，简网生成的app运营是在简网的平台上。关于他们这个服务的具体介绍如下：可以免费三分钟制作一款个人或者媒体、论坛等以内容运营为主的app。支持ios和android系统，创建后可立即下载到手机。你可以通过简网提供的后台，在自己的app里原创内容;互联网上发现的感兴趣文章、图片、视频，商品也可以通过“发布到应用”工具，一键轻松转到应用中去。此外，还自带社区功能，支持用户投稿。简单的说，就是一个可以免费制作app的地儿。pc端网站转移动app该类服务以国内的百度siteapp为代表，一看名字就知道这是为站长服务的。以前叫做“百度移动建站服务”。这类服务可以把你的网站飞快的转换成移动app，以方便你的用户在手机和平板电脑上访问你的内容而不用输入网址调用浏览器。他们的app生成只需4步，分别是添加站点、定制效果、验证权限、全局设置。如图所示。添加站点定制效果权限验证高级设置安装成功最近，百度又通过百度联盟在siteapp里加入了广告变现功能。只要在后台生成一个移动版的广告代码，即可嵌入app赚取广告费。让一些想要赚外快的站长眼前一亮。如图所示。先在百度联盟后台生成移动网页广告代码填入百度联盟id赚广告费百度app广告在我手机上的呈现形式自助app制作工具与其他开发方式在建站上的对比wap建站：通过wap网页来输出内容，吧这种技术优点是消耗流量少，缺点就是没有美观的ui以及更好的互动，现在已逐渐过时。html5技术：利用html5和自适应技术，使网站适合在移动设备上浏览。但现阶段html5技术不是中小站长们能驾驭的,技术门槛较高。移动app：开发周期长，同样也需要专业技术人员进行开发，维护费用高。在线自助app制作工具：和上面的几种方式相比几乎不需开发技术，开发成本也可忽略不计，更加灵活、更轻量化和跨平台。总结：通过上述几种常用的网站手机端生成方式，我们可以看出在线自助app制作工具在技术门槛、开发周期、开发及维护成本、美观度、易用性及通用性上都有得天独厚的优势，是站长实现网站移动化的最佳工具。给大家做个表可以看得更清楚些： 移动建站的几种方式对比 技术门槛开发周期维护成本美观度易用性通用性不足wap建站低短低低打开速度快通用性较高上一代技术，淘汰中html5高长高个性可定制易用性较高社交类、资讯新闻、搜索类等工具型网站新技术，门槛高移动app高长高个性可定制作为单独的产品需安装及不同平台需适配推广难在线自助app工具无半小时无自选模板经web端的优化打开速度高，可搜索适合个人站、企业站、新闻类网站对个别flash为主的网站不适用 另外，由于百度siteapp背靠着搜索引擎和百度联盟等优势资源，让站长们在流量和变现上有着意想不到的收获。通过市场上的公开数据以女性时尚资讯类网站七丽女性网为例，在使用了siteapp一个月后，七丽女性网pc流量和移动流量的对比，由最初的15：1上升到10：1，移动流量上涨了33%，同时整站流量也有大幅提升。而太平洋游戏网则通过添加百度移动网盟推广物料使移动变现能力提升了300%，京华时报、中国新闻周刊等重量级媒体也在不断加入siteapp的使用者队伍。随着不断更新改进及模板的添加，百度siteapp将成为众多站长迅速走向移动端的重要途径，站长们将节约大量的宝贵时间去思考运营和赚钱的问题，而不是被技术所限制、被成本所牵绊。
百度欢迎合理的搜索引擎优化，网站优化过度只会适得其反。合理的优化，有利于搜索引擎爬行网站、收录更多的有用的网页、挖掘出更多有价值的信息等;此类网站叫对搜索引擎友好的网站。看过很多SEO(搜索引擎优化的缩写)的文章谈网站如何优化，针对Google优化的文章占多，baidu相对少一些。理论加上实践，我总结了一些经验给大家分享。大家看百度的搜索帮助：http://www.baidu.com/search/guide.html关于给站长的建站建议的部分内容对如何做百度优化来说相当重要。1、网站结构宜简洁明晰，这是针对百度搜索引擎友好站点的基础。2、内容独特，最好原创。如果未被收录的内容对搜索引擎来说也是原创，呵呵。3、网站内容经常性的更新，百度最喜欢有新鲜内容的网站。4、慎用你的友情链接，链向垃圾站点、优化过度的站点，会有连带性惩罚。5、网站最终目标是客户而非搜索引擎;优化网站，内容为王。针对百度目前计算网页排名的算法，总结几点优化细节：1、网页标题、META标签百度比Google更重视网页标题与所搜索关键字的匹配程度。网页的所描述的内容应该用准确的关键字作为网页标题，一个页面可用多个相关的关键字作网页标题，但是网页中至少要出现一两次标题中所示关键字。关键字的匹配程度在相关搜索中竞争因素比重很高。对网页标题、META标签关键字的长度最佳建议：标题≦80，META关键字≦100，META描述≦200。2、动态网页的转换。如果ASP之类制度的网站，网页内容是动态的，带参数访问的，此类网页竞争性很低。百度对于两个以上参数的很少会收录，最多只收录标题而不收录网页内容。此类网页应当把它转换成静态的路径或生成文件名。3、目录、文件名称中包含关键字这一算法仍然很有用。4、网站深度，网站地图。网站历史不长，PR不高的网站，对于超过两三次点击才能到达的页面很难被百度收录。对于这个问题可以制作网站地图来解决。PR本来跟百度没有关系的，但是判断一个网站质量，PR仍然是一个重要的参考。5、交换有价值的友情链接。PR对Google有用，对百度同样也有用。百度和Google同样采用了相类似的PageRank页面级别技术来评价一个网站的权威性。何为有价值的友情链接?比如你要优化QQ表情这个关键字，如果QQ.com跟你做了友情链接，那你网站的QQ表情的竞争力自然不弱。6、搜索引擎蜘蛛人抓取页面时，不支持javascript代码。很多网页带菜单导航，但是搜索引擎不能收录菜单导航所包含的链接。此类网站的结构性就太差了，几乎不能收录多少页。网站的导航一定要用静态链接。不友好表现：·大量采用图片形式，没有可以检索的文本信息;搜索引擎蜘蛛人是基于文本方式来浏览网站的，没有文本就没有内容可抓。·网页没有标题，或者标题中没有包含有效的关键词;没有包含有效的关键词会被认为作弊而遭到降权处理。·网页正文中有效关键词比较少;关键词密度建议值：2%≦密度≦8%·网站导航系统让搜索引擎“看不懂”;比如上面所述第六条。·部分数据库信息对搜索引擎“保密”;·没有其他网站提供链接线索进行比较。没有外部链接，没有提交，搜索引擎自然找不到你。
由于现在互联网行业的告诉发展，随之移动互联网的兴起，众多的智能手机出现，随之而来的便是大量的app应用程序。移动互联网的应用程序无疑是带动交互式用户体验的主要途径。随着人们对移动互联网的不断认识和熟悉，对于交互式用户体验方面也变的要求越来越高，对于网站建设这个行业来说，网站的建设也应该遵循交互式网站建设和交互式用户体验的理念，在网站建设中不断加入交互式网站效果，让网站能够为浏览者提供更加有用和更加舒服的用户体验。在交互式网站建设中，我们应该注意以下几点内容。一、通过网页提示方式，引导用户如何进行注册或者如何进行浏览网页通过使用弹出窗口或者弹出图层的方式，引导用户如何继续进行浏览或者告知用户网站可以为用户提供哪些信息和帮助。如果我们的网站是以交友方式为目的的网站，那么最重要的就是要让网站浏览者在我们的网站上面进行注册。这时可以采用注册引导方式，通过一步一步的点击方便的让用户在我们的网站上面进行注册，这点可以参考新浪微博或者腾讯微博的注册引导方式。当我们的网站进行改版或者部分板块合并之后，为了防止用户找不到合并后的板块的位置，可以采用提示引导的方式，告知用户网站上面的哪些板块被移动了，这样可以防止用户在浏览新版网站的过程中，找不到自己想要的信息而退出网站。二、通过网站信息提示的方式，引导用户信息是否提交成功，判断用户行为，增加用户体验有时在进行网上购物的过程中，在选择好自己所需要购买的商品后，最后一步就是对购物车中的上面记性结算处理。很多的网站在购物车结算这个环节上面做的都很不够细致，作为网站使用者来说，购物车结算这个步骤应该是比较关心和小心的，但是往往很多的购物网站整个网站都做的比较专业和体验度比较高，往往在最后这个步骤上面做的不近情理，在提交完购物车结算之后，如果出现网速比较慢的情况下，往往会不清楚自己到底有没有提交成功，没有任何的提示，有时明明提交成功了也不清楚，这时网站建设的人员可以在这个环节上面增加一个“订单正在提交，请稍候。”这样的字样，单单这样一个简单的小小提示，就能在很大程度上增加了网站的用户体验度。三、网站表单提交页面，应该使用及时提示错误信息，让用户能够马上明确自己所填写的信息是否正确每个网站几乎都有表单提交的页面，在以前的网站中，表单提交往往都是在填写玩一大堆的表单信息后，点击提交按钮，如果所填写的信息出现错误，就会弹出一个对话框，然后再重新返回，重新修改错误信息。如果我们在表单填写的过程中，可以随时的清楚自己所填写的信息是否正确，那岂不是更好的。这时需要网站建设的人员对表单进行ajax表单验证，使用js代码和网站的数据库进行链接比较，然后及时的把错误信息呈现给用户，可以让用户及时的知道自己所填写的信息是否正确。四、通过使用不可点击状态，告知用户该信息是否可以继续浏览或者使用这点可以表现为在发布一些信息的时候，比如文章，心情，状态的时候，如果所发布的信息是空的那么当前的发布按钮就会为灰色或者不可点击的状态。这样当用户在想要发布信息的时候，不用去刻意的告知用户所发布的信息不能为空，而只需要把发布按钮变为不可点击状态就可以了。一方面不会影响页面的整体美观，另一方面还增加了用户感兴趣度，在一定程度上增加了网站的用户体验和交互式网站建设。(内容为空时，按钮为不可点击状态)(内容不为空时，按钮为可点击状态)五、通过自动加载的功能，为用户加载更多的网站内容，而不需要点击下一页或重新刷新页面我们都知道，每个网站都会有分页的页面，以前我们在百度中搜索图片，其搜索结果也会以分页的方式展示给用户，但是现在你再去百度中搜索图片，则不会出现分页的现象，而是把原来的分页改为现在的加载更多。这样做的好处是一方面可以减少用户每次查找图片都要一页一页翻的烦恼，其次是可以方便用户对所需结果第一页中内容和第二页中的内容进行比较，从而增加了网站与用户的交互性也增加了当前页面的用户体验度。想要做好交互式网站建设和用户体验度，就要对所建设的所有网站的每一个页面都要注重起来，网站中的每一个页面都要尽量做到用户体验特别好，在建设每一个网站的时候，都要站在网站浏览者的角度去制作，只有这样才能建设出一个用户体验比较好的网站，才能让自己建设出来的网站更有效果，才能为交互式网站建设奠定下一定的基础。
在搜索引擎不断变更，行业竞争越来越激烈的今天，很多本来排名不错的站长们每天也是不踏实，害怕辛苦得来的排名不翼而飞，那么如何稳定得之不易的排名呢?由于网站能获得不错的排名，就说明网站的一些基础设置、结构、链接、外链、收录等都还不错，不存在什么大问题，这里就不多说，下面主要谈2点稳定网站排名的要素。一、内容质量高内容始终是网站的根本，网站的内容质量一定要高，不要糊弄搜索引擎，更不要糊弄用户。网站前期获得排名，外链占了很大一部分因素，而有了排名之后，用户的选择与投票占主要的因素。千万不要想着有网站排名后就感觉轻松了，然后降低更新内容的质量，复制采集都用上，别高兴太早，用户考核的时间才刚刚到，这个时候将内容质量降低无疑告诉用户，你以后可以不用来了。试想一下，网站关键词刚刚到第五名，终于可以为网站带来流量，引来用户了，结果用户一进来，看到的都是些不咋地的内容，结果怎样?停留时间短、跳出率高，用户直接就会给你一个不合格，这就是相当于搜索引擎刚刚推荐出来的站被用户给否定了，显然用不了多久搜索引擎也会把你否定掉。所以在网站有排名后，一定要继续供应高质量文章，及时的抓住用户，获得用户青睐，机不可失失不再来。就像现在很多的知名博客，前期文章时非常好的获得了大量用户，后面就算文章差一点还是非常多人去看。二、不断满足新的用户需求百度的目的是满足用户需求，保证市场份额，所以你的网站能满足用户需求就能满足搜索引擎的需求，有人说前面说的高质量文章不就是满足了用户需求?的确，用户需求高质量文章，但是需求也是会有改变的。比如一个seo网站，用户的主体需求当然是seo技术文章，但如果某段时间出现大量网站泛解析的情况，用户就需求泛解析相关的文章，如果你的网站没有，用户就会去另一个网站，甚至成为该网站的长期用户。所以，我们需要不断的去发现用户的需求，用户有需求也就是搜索引擎也有需求，而我们就需要去供应这个需求。当然需求也不能与网站主题脱轨。开的是水果店，如果用户需求扫把就卖扫把，如果需求杯具就卖杯具，久而久之，你的店就是杂货铺而不是水果店了，网站也是如此，对用户任何需求的补充都应相关，不能脱离正轨。一般而言，木木seo看来用户需求分为长期需求和短期需求二种，短期需求即当下需求，容易改变，对于判断用户短期需求，简单的方法就是看百度下拉框，百度下拉框反应的是与搜素关键词最相关的最近几天用户搜索排序。而长期需求是行业内稳定的需求，不易改变，当改变是网站内容要几乎完全进行改变。所以这个长期需求应该把握准，相对于下拉框，我们可以看百度相关搜索，相关搜索反应的是长期的用户搜索排序，站长应该根据长期需求确定网页核心，做好网站稳定排名的基石。 写在最后网站排名不易，所以有了排名一定要稳定住，稳定的时间越久，获得的用户就越多，同时流量就越大，网站排名也就会越稳定，一般一直排在前面的站点很稳定就是这个原因，因为用户已经习惯了选择你，你的网站已经获得一大批忠实用户。当然，上面说的2大要素只是比较重要的2个方面，不是唯一。虽说排名不易，但稳定更难，所以需要持之以恒，只有网站真真稳定，你的舒服日子就到了。
随着百度对外链算法的不断调整，外链越来越不好做。有很多人做了外链的效果微乎其微，甚至还被判别为垃圾外链，给网站带来了负面的影响。外链，一个让SEOer头疼的问题，如果能解决外链的问题，而且外链质量还非常高，那么SEO优化之路上会轻松不少。那么如何获得高质量的外链呢?大家别急，请听东东慢慢道来。什么是高质量的外链我们发外链要的是质量而不要是数量，不要为了发外链而发外链，这样的心态永远也发不了高质量的外链。我要以服务用户为质量的角度去发外链，以推广为目的，要形成推广外链，能带来流量的外链。最好事形成转发，这样的外链才是真真的高质量外链。我们如何才能获得高质量的外链呢?1、软文外链软文可以说这是所有外链形式中效果最好的，如果文采不错可以给权重高的网站投稿，一旦审批通过会有大量网站进行转载，因为这些网站权重高、浏览量大，一篇文章被转载几百次都是正常的，如果文章中留有你网站的外链效果很好，软文通过率很低但存活周期时间长。软文要重视质量而不能片面的追求数量，追求数量是SEO人员的常见错误。2、博客做外链博客做外链效果非常好，但是前提是博客权重需要先做上去，这也就是通常所说的“养博客”。如果说你的博客一直保持更新，而且经常发一些原创的东西进去，那么时间长了，这个博客就会拥有一定的权重，此时在上面做外链往往就都是一些权重比较高的外链，比那些在论坛上面发帖顶贴要强很多倍，但是问题的关键在于你是否有这样的一个高权重的博客平台供你发外链。3、友情链接友情链接，因友情而链接。友情链接是双向连接，权重也非常高。你可以找一些质量不错的网站跟你交换友情链接，如果你是新站，那么谁加你啊?有这种想法对吗?这样，你就要平时做seo人脉积累了，你做seo就要跟多点站长交朋友啊，多点沟通互动，帮助别人。那么，你做了个新站，你就可以跟你有交往的seo朋友们交到高质量的友链。4、单向链接获取别人的网站给你做单相连接是最好的高权重连接，如果对方网站导出链接少，那么你的获得权重越高。一般别人不会随便给你做单向链接的，你叫别人给你做单向链接别人就会给你做吗?别人也不是傻，当然不会。那么，我们该如何获得别人的单项连接呢?要有利他之心。例如，你可以找到一些站长，而他们网站的排名不是太理想的，那么你可以联系到他，跟他说你帮助他提升关键词排名，实实在在的帮助他们，然后你说你想他们给你做个单向链接，这样他们也会愿意的。或者你会写模板，帮别人做模板和做一些开源模板，然后也可以带上你的链接。总结垃圾外链太多，会导致网站降权，所以我们做外链外链一定要注重质量，数量是在质量做好的前提下在去提升的。如果说一般外链是seo的子弹，那么高质量外链是seo的原子弹，哪个威力大，可想而知。所以大家看完了东东的这篇文章如果受到启发了，那么从现在开始追求外链的质量。
当出现网站慢的时候我们脑子中要映出几点原因： 1.程序代码执行方面2.大量数据库操作3.域名DNS解析问题4.服务器环境 我也是这么解决的，下面说下解决中的步骤吧。 1.打开访问慢的网站观察下情况，通过火狐的fixfox插件或者IE的元素查看工具，你网站里面加载的信息会一览无遗的展现出来，并且那些元素加载耗时多少秒等等情况，如何解决能，把远程耗时久的js下载到本地，或者直接删除。 2.我看了下页面中有多处连接数据库操作的地方，并且有远程的数据库操作，并且还有多余的数据库连接代码，话不多说，改之. 解决完了发现的确是快点了，但是还是不理想，于是我把页面执行数据库代码放到了数据库中执行没有耗慢的情况。 3.关于域名DNS的情况只是其中一种情况，不要急着找域名商的问题，你可以写个没有数据操作的页面放在同台服务器域名下，看看是不是访问同样慢，如果是才有可能，你还要让你周围的人也看看，最好别是你同公司的人。 4.我来看看服务器的情况吧，是不是CPU使用率过高造成的呢。 a.top 发现cpu使用也不高啊，30%左右，但是发现一个问题，sleeping的进程数比较多。擦，最好别是僵尸进程，现在这样的东西不多了。 b.查看了下timewait的量:发现有mysqld 和httpd的，大部分来自于httpd ；命令netstat-ae|grepTIME_WAIT 如何来解决timewait的量问题呢？ TIME_WAIT解决办法： vi/etc/sysctl.conf 编辑文件，加入以下内容：net.ipv4.tcp_syncookies=1net.ipv4.tcp_tw_reuse=1net.ipv4.tcp_tw_recycle=1net.ipv4.tcp_fin_timeout=30net.ipv4.tcp_keepalive_time=30 保持连接的时间net.ipv4.tcp_max_tw_buckets=100 这个是设置服务器同时保持的time_wait的数目 然后执行/sbin/sysctl-p让参数生效。 设置APACHE的配置文件：Timeout10 与客户端连接超时的时间KeepAliveOn 一次连接可以多次传输，使的一次连接中可以传递多个HTTP请求MaxKeepAliveRequests 50 设置一次连接内，可以进行多少次请求KeepAliveTimeout 15 如果服务器已经完成了一次请求，多长时间一直没有接受到下一次请求就会断开连接 保存重启APACHE设置完已上的操作后:netstat-n|awk'/^tcp/{++S[$NF]}END{for(iinS)printi,S[i]}'你会发现非常成功。 如果还不够满意可以再设置下Ulimit参数cat>>/etc/security/limits.conf
中国互联网举报中心