前言

如果你想开发一个js应用,甭管多简单,都要先创建整个宇宙

来看看我们的Javascript小宇宙:

  1. 确定如何根据需求、功能划分模块,如何将代码分成多个文件开发,合成一个发布
  2. 保证上一条的同时,使用 Coffeescript、SCSS/LESS 等技术
  3. 保证上2条的同时,想想怎么在浏览器的刷新后一切都最新
  4. 保证上3条的同时,想想怎么在开发、测试、生产、预发布环境中都OK
  5. 保证上4条的同时,进行TDD式的开发
  6. …这还是js, 我们还没有涉及到HTML

 

Grunt 可以将创建小宇宙的工作变得轻松很多。

初识 grunt

以一个jQuery插件的开发为例。 开始之前,让我们先安装Grunt.

首先需要Nodejs环境,这里假设你已经安装好了NodejsNPM.

然后安装 grunt :

npm install grunt

命令行方式更适合前端开发。这里我都用命令行来进行操作,windows用户推荐用git-shell或者powershell.

第一招:快速搭建脚手架

Grunt 已经安装好了,第一步就是利用grunt快速搭建脚手架出来。所谓的脚手架,就是指包含了目录结构和初始的一些功能,测试文件的一个环境。我们来搭建一个jquery插件的脚手架:

grunt init:jquery

这时grunt会问你一些问题,比如项目名称, git地址,作者等等,比如:
查看更多

大部分的情况下我们都处于移动状态,手机这种轻便、必备的终端工具使我们在千奇百怪的环境中也能完成一些微任务。同时随着无线网络带宽的增加,手机上网速度越来越快,使得手机等移动设备的上网体验越来越流畅。根据互联网数据中心IDC 的数据显示,到2015年人们通过移动设备访问Web的数量将超过PC访问。

无论是学生、上班族还是商人,利用好这些时间碎片,对于每一个人都具有重要的意义。WAPAPP在这种环境下充满了无限价值。

        Wap一般通过手机浏览器便能被访问,作为缩小版浏览的网页,相对于PC端网页内容的多而全,它则显示了少而精的优势。除此之外,相对于当下风靡的APP客户端,Wap还有以下优势:

1、快速更新迭代产品:

互联网产品的更新迭代速度惊人,在Wap平台,产品更新、设计、开发完成后只需发布到线上服务器,用户通过浏览器访问WAP,就能看到最新修改的网页;更新迭代的成本较客户端(Android/IOS)都低,速度也更快。

2、支持跨平台,无安装成本:

 WAP的访问只要求手机有上网浏览功能即可,一个浏览器就满足了任何需求,不用区分设备平台是Mobile Phone、Android还是iOS等。同样WAP不像客户端需要下载安装,只要在浏览器输入对应的网址就能查看。

        不过wap的劣势也是显而易见的:在HTML5&CSS3&JS的配合下,虽然目前已经可以实现一些复杂的功能和交互,但是对一些相对复杂的功能和交互的实现还是不如客户端,因此用户体验较之客户端差。这也是目前很多应用(比如Facebook、Lofter等应用)选择转做Native APP的原因,这部分应用的年轻用户对设计体验的要求是比较苛刻的,这与b2b等交易网站对交易流程使用的流畅性的追求是不同的,对他们(商人)来说首先关注的是用户浏览是否顺畅,交易成功的数量,其次才是优美的界面,绚丽的动画。

         互联网是个唯快不破的行业,阿里巴巴无线业务从整体成本上考虑,将HTML5擅长的对一些数据量不大,动画少的页面的优势,用来快速处理资讯、登陆等页面。目前阿里巴巴的生意经、论坛、资讯、登陆等模块都是直接嵌入Wap页面,解决内嵌页面的适配尺寸则依据客户端测试同学对APP用户的手机分辨率的测试结果:

         根据最新一期的手机客户端适配分辨率分布测试结果显示,Android用户使用最多的分辨率是480×800、320×480,加上iOS平台320×480、640×960、640×1136三个尺寸,共需要适配三个尺寸:320×480,480×800,640×960。这种适配利用的是当下比较流行的web响应式设计,嵌入到APP里面,能通过代码解析后与Native app 及手机系统进行交互,完成页面逻辑、内容的打通。

         我们从这三个尺寸的设计中得出以下适配的使用规范:

          

        整理规范不仅是一种设计总结,也是方便后续及其他设计师设计参考的依据。

         以上是我做阿里无线的一些设计小结,欢迎其他在客户端有设计、使用经验的你来分享一下你的体会。

         最后很感谢一起合作的无线小组,你们给了我很多帮助和建议,谢谢:)

 

PM培训的答疑课小结

原文出自独占神话

这期PM培训的最后一次课安排的是答疑,回答了一些同学们普遍关心的问题。对学员们和讲师的讨论,我做了些小结如下:

一. 项目失控怎么办?

产生这种情况说明项目管理已经存在大的问题了。要做到的是提前预知,避免这种情况的出现。
万一出现了,首先要深入了解原因。多问自己问题,是人的原因吗?因为开发是新人?负面情绪引发懈怠?还是沟通不畅? 再看如何解决。两个方向,项目内搞定或者项目外搞定。项目内可以搞定吗?回答这个问题的关键是找关键路径。看从非关键路径是否可以抽调资源到关键路径上。这是要注意关键路径的变化。如果没法解决,项目外解决。项目外也就是看项目管理三角形,在资源、时间、范围上找解决方法。

二. PM如何建立威信?

其实PM需要建立的不是威信,而是信任。这里提到一个非常有趣的概念,Johari Windows。乔哈里之窗能够用来展现、提高个人与组织的自我意识,也可以用来改变整个组织的动态信息沟通系统。
乔哈里之窗把人的内心世界比作一个四格的窗口:
The Open Arena:开放区,自己和他人都知道的领域。
The Hidden Facade:隐藏区,自己知道别人不知道的领域。
The Blind Spot:盲区,别人知道但自己不知道的领域。
The Closed Area:封闭区,双方都不了解的领域。
真正有效的沟通,只能在公开区内进行。因为在此区域内,双方交流的主题是共知的,沟通效果是会令双方满意的。实际沟通中,很多情况下信息不对等,处于封闭区,导致沟通无效。要使得沟通更有效,需要增强信息的真实度、透明度,进而扩大开放区。扩大开放区的方式可以经由自我坦诚,或经由反馈。

三. 遇到能力强但固执的项目成员怎么办?

1. 识别出其固执的原因。
2. 和其身边的朋友多沟通,对其个性和行事风格等更多了解。
3. 使其承担责任,成为某个课题的owner,自我价值实现。
4. 多搞团建,和团队融合。
5. 不能被团队认可,请出项目组。

四. 跨团队的资源如何协调?

1. 要清楚的认识到,我们不是去要资源,而是要取得一致目标。是我们大家一起要把这个事情做出来。讲讲清楚要做什么,得到认可,把事情变成大家的事情,而不是变成对立。
2. 要有结果,要及时反馈。

五. PM要对技术方案负责吗?

PM对技术方案影响越少越好,要认清PM的职责,是带领团队在竞争中取胜。要识别出可以对技术方案或业务拍板的关键人物,他们去负责。
这里又涉及到PM正确的心态应该是怎样的,一是善假于力,融会贯通。对人,要知人善任,了解团队,了解成员的长处短处。对事,项目管理各个环节都要融汇进去。二是正向关注,助人自助。对人,给人机会,也要慎重淘汰。对事,接受挑战,积极正向。

原文

在项目的交互或视觉评审中,前端同学常常会对一些交互效果质疑,提出这样做不好那样做不好。主要原因是这些效果通常会产生一系列的浏览器重绘和重排,需要付出高昂的性能代价。那么,什么是浏览器的重绘和重排呢?二者何时发生以及如何权衡?如何在具体的开发过程中将重绘和重排引发的性能问题考虑进去?本文期待可以部分解释以上三个问题。

浏览器从下载文档到显示页面的过程是个复杂的过程,这里包含了重绘和重排。各家浏览器引擎的工作原理略有差别,但也有一定规则。简单讲,通常在文档初次加载时,浏览器引擎会解析HTML文档来构建DOM树,之后根据DOM元素的几何属性构建一棵用于渲染的树。渲染树的每个节点都有大小和边距等属性,类似于盒子模型(由于隐藏元素不需要显示,渲染树中并不包含DOM树中隐藏的元素)。当渲染树构建完成后,浏览器就可以将元素放置到正确的位置了,再根据渲染树节点的样式属性绘制出页面。由于浏览器的流布局,对渲染树的计算通常只需要遍历一次就可以完成。但table及其内部元素除外,它可能需要多次计算才能确定好其在渲染树中节点的属性,通常要花3倍于同等元素的时间。这也是为什么我们要避免使用table做布局的一个原因。

重绘是一个元素外观的改变所触发的浏览器行为,例如改变vidibility、outline、背景色等属性。浏览器会根据元素的新属性重新绘制,使元素呈现新的外观。重绘不会带来重新布局,并不一定伴随重排。

重排是更明显的一种改变,可以理解为渲染树需要重新计算。下面是常见的触发重排的操作:

1. DOM元素的几何属性变化。
当DOM元素的几何属性变化时,渲染树中的相关节点就会失效,浏览器会根据DOM元素的变化重建构建渲染树中失效的节点。之后,会根据新的渲染树重新绘制这部分页面。而且,当前元素的重排也许会带来相关元素的重排。例如,容器节点的渲染树改变时,会触发子节点的重新计算,也会触发其后续兄弟节点的重排,祖先节点需要重新计算子节点的尺寸也会产生重排。最后,每个元素都将发生重绘。可见,重排一定会引起浏览器的重绘,一个元素的重排通常会带来一系列的反应,甚至触发整个文档的重排和重绘,性能代价是高昂的。

2.DOM树的结构变化。
当DOM树的结构变化时,例如节点的增减、移动等,也会触发重排。浏览器引擎布局的过程,类似于树的前序遍历,是一个从上到下从左到右的过程。通常在这个过程中,当前元素不会再影响其前面已经遍历过的元素。所以,如果在body最前面插入一个元素,会导致整个文档的重新渲染,而在其后插入一个元素,则不会影响到前面的元素。
查看更多