防止装箱落实到底,只做一半也是失败

<p>.NET提供struct类型,正确使用可以减少对象数量,从而降低GC压力,提高性能。不过有时候我会发现,某些同学有这方面的意识,但是有时候一疏忽一偷懒,就没有得到相应的效果了。这里举一个真实的例子:假设我们要将一对int作为字典的键,用于映射到某些数据,那么你会怎么做?当然我们可以直接使用Tuple<int, int>,但这样就可能产生大量的对象。于是我们打算使用自定义的值类型:</p><div style="page-break-after: always;"><span style="display: none;"><!--more-->& nbsp ;</span></div><pre class="brush:csharp;">private struct MyKey { private readonly int _a; private readonly int _b; public MyKey(int a, int b) { _a = a; _b = b; }}</pre><p>这么做正确吗?假如你做一下测试,会发现它已经可以“正确使用”了,但实际上还是错误的。我们用它来做字典的键,会依赖GetHashCodeEquals两个方法,由于MyKey没有提供这两个方法,就会自动使用System.ValueType里的实现,这便引起了装箱。</p><p>好吧,那么我们就来实现一下:</p><pre class="brush:csharp;">private struct MyKey { // ... public override int GetHashCode() { // ... } public override bool Equals(object that) { // ... }}</pre><p>那么现在呢?可能现在您就会比较容易意识到,即便GetHashCode已经没有问题了,但是Equals方法还是会引起装箱,因为that参数依然是object类型。</p><p>怎么破?当然有办法,因为像HashSet<T>或是Dictionary<TKey, TValue>集合其实都不会直接调用GetHashCodeEquals方法,都是通过一个IEqualityComparer<T>对象来委托调用的:</p><pre class="brush:csharp;">public interface IEqualityComparer<in T> { bool Equals(T x, T y); int GetHashCode(T obj);}</pre><p>假如在创建集合的时候没有提供比较器,则会使用默认的EqualityComparer<T>.Default对象,它的构造方法是这样的:</p><pre class="brush:csharp;">private static EqualityComparer<T> CreateComparer<T>() { Contract.Ensures(Contract.Result<EqualityComparer<T>>() != null); RuntimeType t = (RuntimeType)typeof(T); // Specialize type byte for performance reasons if (t == typeof(byte)) { return (EqualityComparer<T>)(object)(new ByteEqualityComparer()); } // If T implements IEquatable<T> return a GenericEqualityComparer<T> if (typeof(IEquatable<T>).IsAssignableFrom(t)) { return (EqualityComparer<T>)RuntimeTypeHandle.CreateInstanceForAnotherGenericParameter( (RuntimeType)typeof(GenericEqualityComparer<int>), t); } // If T is a Nullable<U> where U implements IEquatable<U> return a NullableEqualityComparer<U> if (t.IsGenericType && t.GetGenericTypeDefinition() == typeof(Nullable<>)) { RuntimeType u = (RuntimeType)t.GetGenericArguments()[0]; if (typeof(IEquatable<>).MakeGenericType(u).IsAssignableFrom(u)) { return (EqualityComparer<T>)RuntimeTypeHandle.CreateInstanceForAnotherGenericParameter( (RuntimeType)typeof(NullableEqualityComparer<int>), u); } } // If T is an int-based Enum, return an EnumEqualityComparer<T> // See the METHOD__JIT_HELPERS__UNSAFE_ENUM_CAST and METHOD__JIT_HELPERS__UNSAFE_ENUM_CAST_LONG cases in getILIntrinsicImplementation if (t.IsEnum && Enum.GetUnderlyingType(t) == typeof(int)) { return (EqualityComparer<T>)RuntimeTypeHandle.CreateInstanceForAnotherGenericParameter( (RuntimeType)typeof(EnumEqualityComparer<int>), t); } // Otherwise return an ObjectEqualityComparer<T> return new ObjectEqualityComparer<T>();}</pre><p>可以看出,根据不同的情况它会使用各式不同的比较器。其中最适合我们的自然就是实现IEquatable<T>接口的分支了。于是我们可以这么做:</p><pre class="brush:csharp;">struct MyKey : IEquatable<MyKey> { // ... public bool Equals(MyKey that) { // ... }}</pre><p> </p><p>这才是最终符合我们要求的做法</p>

阅读剩余部分 -

房产电商3.0的时代真的到来了?

<p>最近看了一篇文章, 关于新浪乐居跟E信通合作的报道...然后鼓吹房产3.0的时代到来了...我不知道这个1.0、2.0、3.0你们是怎么定义的,我觉得改革,应该是全面的,针对消费者的改革、管理改革、市场改革等多元化革新。然后我看了关于E信通介绍自己的产品亮点,简直亮瞎了……</p>

阅读剩余部分 -

互联网产品经理职能与职责

前言 :

由于每次都会被人问,产品经理是什么岗位 ?产品经理都做什么东西?之类的问题。于是,我决定写一篇大体说得过去的,关于互联网产品人的职能与职责概述。如果有些的不对的或者需要补充的,欢迎来搞 !!

正文: 首先我们先列一个提纲吧,由浅入深。

  1. 产品经理在公司中是什么岗位
  2. 产品经理在项目中担任什么角色
  3. 产品经理都需要储备哪些专业知识
  4. 产品经理需要把控什么
  5. 产品经理作业流程是什么

列出这么浅显易懂的问题之后,再来一一作答就感觉调理清晰多了。

A1: 首先来说第一个问题,产品经理是什么岗位; 首先要说下,产品经理在没有来到互联网的时候多用于实业上,那被搬到互联网上也不难理解,其实产品经理就是一个 - 策划产品需求、跟进制作产品、管控产品质量以及后续规划产品迭代的一个重要岗位;任何实业也好,互联网产品也好,功能也好,从滋生到面向市场大众,这个过程以及结果的背后,都离不开产品经理。

A2:产品经理在项目中担任什么角色;前一段在谷歌小组,一个国外产品人写了这样一篇文章(大概意思说下,E文太差),说产品经理的再项目中,在团队中的职能重心是什么,其实看到这个问题的时候我也在想,因为我理解应该是策划跟执行,之后他告诉我们说,一个合格的产品经理人在项目中,重心在于管理。我细想了一下,觉得有道理,确实在一个项目中,产品经理收集策划出所有需求以后就是分配执行这个开始我的理解也是没错的,但是忽略了对于产品的管理层,产品经理,再怎么说也是个经理,经理级别的重心应该是管理。 那都管理些什么呢? 文中大概说到几点,首先,是人员管理;其次,是产品管理; 人员管理主要是协调、沟通、执行, 那产品管理什么呢? 产品质量、产品市场、数据管理、收益管理; 这么说就明白了,一个好的产品经理人,重要的不单单是重视内部协作,更重要的是应该把精力放在产品思想上,产品策略上,这是产品战略层的需求,也是为了配合运营而做的基础动作。

A3:产品经理应该储备哪些知识;

  • a - 领域常识; 每个人都有自己喜欢的领域以及有独特见解的领域,在这个领域中你才能发挥自己的特长,才能创造你应该能够创造的价值,没有任何一个人是可以多领域并且都做的很出色的。所以,发觉自己的领域,找一个合适自己领域的企业做产品经理,深度理解这个领域的规则,才会活的开心,活的如鱼得水,也能做出更好的产品。
  • b - 多结善缘;我说,朋友是我的眼,帮助我开阔视野,甚至出谋划策,古人说三个臭皮匠顶个诸葛亮,三人行必有我师焉等,一个人的精力是有限的,当你专一在你的领域的时候,你可能忽略了很多其他对你有帮助的领域里的信息,这个时候如何获得信息,朋友无疑是你的葵花宝典。
  • c - 倾听; 不会倾听的产品经理人不是个好木匠,需求需要倾听,协调需要倾听,管理需要倾听,因为你的产品是给大众的,而不是你自己。
  • d - 筛选; 要学会过滤哪些是有用的,哪些是没用的数据,要学会采集需求的时候有针对性,有唯一性。
  • e - 嗅觉; 对市场的嗅觉,是考核产品经理人最重要的环节。 如果你没有这个,那可能你不合适做产品经理,需要从新给自己的职场做规划了。
  • f - 专业; 你要拥有的专业绝对不止谈天说地,交交朋友这么简单。 你需要理解如何开发,如何展示,如何运营,这样才能更好的做出可以实行的需求文档,而不是做出来让人喷死你。我这里就不多举例说明了,相信很多产品经理会被问到类似的问题,一旦需求有一些变动,你自己感觉是一点,但是技术会告诉你有多少代码需要重构,前端会告诉你,前端布局有多大量的更改。在没有足够多的专业知识之前,尽量虚心请教,制定靠谱的方案,这里不是妥协,是曲线救国。当然为了避免这样问题发生,你可以平时多做一些储备,比如学习下编程、看看什么是 OOP OOD思想、了解下MVC架构、CSS、数据库设计、分布式部署、服务器安全、UI、UE设计等。丰富自己的路是艰辛的,如果你有项目经理,可以先从跟他学习开始。
  • g - 其他; 这里的其他有很多,比如心理学,如何跟一个傻逼相处,产品经理的B格如何提升,之类的只是还是需要普及的,那其实蛮多的,也是根据兴趣,根据自己做的领域去深度学习,在产品经理的人生中最,是要比其他人多付出努力的,郭德纲说,相声门槛低,会说中国话就成,大家挤破头的学相声,入门一段时间了,才发现,门槛在里面。形象的比喻来说,入门在山脚,门槛在山腰。 产品经理也是一样,入门虽易,做好甚难,且行且珍惜。

A4:产品经理需要把控什么; 这里只给关键字,与项目经理一样, 质量! 时间! 需求! 市场! 数据

A5: 产品经理的作业流程是什么; 这个问题比较概念化,因为每个团队也好公司也好的结构是不一样的,所以不太好解答,但是我想步骤是类似的;

a - 分析市场
b - 制定需求
c - 开发产品
d - 数据分析
e - 产品迭代

产品经理要做的只是其中的某些环节,但是流程上是要全程跟进的。因为产品就是产品经理人的心血。从开始,到灭亡。生死权一大部分在你手里,只要你玩的好,就能玩出精彩。

尾言:有人问,如何PK程序员跟设计师,我感觉这就是本事,产品经理人也是一个热衷于讲故事的人,他(她)要有感染力,要有亲和力,要霸气,要合群。 为人处世在当下的企业环境下是必须品,你除了要有过硬的专业知识,懂得中间流程,善于举例讲故事,还要会拿出实实在在的数据叫板他们,直到说到他们心服口服为止。在工作上让他们折服,也是挺好的事情,在生活中,也要懂得体谅他们,为他们着想。 记得以前我带我的团队的时候,加班的晚餐都是我买好送到每个人桌上,项目成了多给大家一些。在企业中你要懂得照顾; 他们,为他们减压,为他们争取利益,才能更好的共事。当然 这就是个建议。

网页PR(Page Rank)值

<p>网页的“Page rank”技术是google的专利,它是搜索引擎根据网页的title, 关键字密度,关键字格式,关键字在文章中的位置,页面的站内链接,站外链接等因素计算得出的网页等级评定分值。搜索引擎根据该分值的高低来确定网页在SERPs(搜索结果页面)中的显示顺序。</p><div style="page-break-after: always;"><span style="display: none;"><!--more-->& nbsp ;</span></div><p>
   Google提供了一个工具栏,可以显示某个具体页面的分值大小,不过时效性太差,通常要推迟一两个月才更新(新闻网站和大网站等有部分例外),所以只能做为网页SEO的参考。一般来讲,被pagerank值高的网页所指向的页面,得到的pagerank分也高。(具体计算公式网上有,这里不公布),所以SEO界极力推荐与权威网站和高分值的页面做链接。
 
   Google显示排名还与一个因素有关,即网页的"Bad rank"值,"Bad rank"值越高,对排名越不利。一般认为:该值可能与“网站(网页)的死链接数目”,网站(网页)的不规范代码数目,页面的排版格式错误,特别是“与作弊网站是否链接”等因素有关。许多对搜索引擎不友好的因素可以通过相关工具查出并解决。值的一提的是“链接作弊网站“这个因素。
 
   如果某个页面(网站)被认为是作弊页面(网站),Google就会给该页面(网站)一个很高的"bad rank"值,同时,google还会从这个页面出发,寻找所有“链向”该页面(网站)的网页(网站),给出一个较高的"bad rank 值"。这个分值的计算公式很有可能与"page rank"分值不一样,因为Google为了保证搜索结果的公正性,肯定会狠狠打击作弊网站,也就是说,尽管这个值有自己的计算公式,它的影响力可能大于"10个好网站带来的pagerank总和”所产生的影响力。
 
  由此可见,用大规模的链接来提高网页的排名风险很大,如果所链向的网页有几个被认为是做弊网站,自己的“bag rank”值就会大幅度增加,对排名非常不利。应当尽量避免……
 </p>

阅读剩余部分 -

关于设计的七宗罪

<p>一个设计项目需要准备,要遵循惯例,考虑设计原理,分析基本情况,这样就能避免错误!</p><p>在任何一个设计项目中,总有些易犯的错误。这些错误阻碍设计进程甚至让项目偏离轨道。大多数有经验的设计师能够察觉警告信号从而避免错误。</p><p>下面提到的设计七宗罪也有其苗头可寻。它们比你一般的错误都严重,如果你不保持警惕,它们会毁了你的设计,所以,保持警觉,当心陷阱。</p><div style="page-break-after: always;"><span style="display: none;"><!--more-->& nbsp ;</span></div><p>当心等着终结设计项目的死神!</p><p>第一宗罪:爱欲</p><p>第一宗罪是爱欲。你也许对这很熟悉,对他人作品过分的爱慕会毁坏你自己的作品。</p><p>犯了这种错误的人,会深深为同行的设计着迷,更关注在设计中向他们致意而忽视了个人风格的表达。欣赏他人的网络杰作是一回事,但你的作品应看上去是你自己的,而不是别人的。</p><p>开始一个新项目前,放空你的大脑,这样你就不大可能去模仿他人的作品。如果在你起步时,有抄袭的冲动,那么重新开始,再试一次。尽量保持你作品的原创性。</p><p>控制住那些过分爱慕的冲动。</p><p>第二宗罪:饕餮</p><p>这种错误很容易发现。设计饕餮就是在一个网站上放太多东西的冲动。犯错者也许只是过分投入的人,他们塞入大量无用设计元素使网站信息混乱。一旦你越过了这条线,整个项目就被拖累了。你必须在设计元素和设计理念之间的保持平衡。</p><p>当然,某些客户会要求你挤入更多超过设计看似能容纳的概念。在这种情况下,退回来,寻找巧妙而有创意的方法将它们融入进去。如果用户处理的信息过多,他们接收的信息就非常少。</p><p>如果你冒险犯下此错,就让其他人来检视你的作品。你可能需要削减大量内容来防止网站信息过度刺激用户。</p><p>你的设计已经满了,放下果酱饼。</p><p>第三宗罪:贪婪</p><p>这是另一种容易犯的错。很明显,当考虑金钱优先于设计时,设计师往往交不出好作品。</p><p>也许自由设计师手上有太多设计要忙,使他们无法全心投入于任何一项任务。又或者他们可能经济困难。无论什么原因,当金钱占了上风,设计就变差了。</p><p>设计师应以你创造的每个设计为傲。不要交出不合格的作品。我们是艺术家,这是我们的手艺。当支票开始蒙蔽你的判断,回头想想为什么你最初对这个项目感到兴奋。</p><p>贪婪是强大的动力,但永远不是灵感。重燃斗志的另一个方法是推开信封,挑战下你自己的创造力。</p><p>这与金钱无关!</p><p>第四宗罪:懒惰</p><p>懒惰是设计行业难以摆脱的原罪。当一个设计师在他们的设计中一遍又一遍重复使用样式或元素组合时,他们就犯了懒惰之错。在设计中变得懒惰几乎不可原谅,可能再没有方法去挽回一个人的设计名誉。</p><p>一个设计师应尽力让每一个网站独特。如果你发现自己变得懒惰或设计重复,去寻找新的灵感之源。不同的风格和影响会令你的作品起死回生,将你推向激动人心的新方向。</p><p>懒惰有害!</p><p>第五宗罪:愤怒</p><p>在项目中,不要让愤怒击垮你。愤怒不是体现在工作中,而是出于你的言行。看看你的内心,不要越界。设计师的愤怒是自我毁灭,会在无关紧要的细节上与客户挑起没完没了的不必要的争端。</p><p>当然,你以自己的作品为傲,但终究是客户做决定,而你必须尊重这一点。没有必要辩解或激怒客户。</p><p>大吵一架只会让整个项目陷入困局。在回应客户的挑衅时,好好想想你的意图,这样你就不会破坏关系或使项目脱轨。</p><p>不冷静绝不是解决问题的方法。</p><p>第六宗罪:妒忌</p><p>设计上的妒忌是一个人对于他人设计模型成功的过分着迷。</p><p>要夺取其他设计师享有的名气,你会不惜牺牲自己的风格,选择同样的方向设计自己的作品,。其实,有许多方法可以不通过直白地抄袭他人的方法或风格来借鉴你欣赏的作品。</p><p>设计妒忌是有害的,这让你在同行中丧失信誉。有许多方法可以抑制抄袭他人作品的冲动。找出作品中吸引你的核心理念,提取它成为新的设计。</p><p>你也可以用类似的方式表达网站背后的基本信息;这并不是抄袭,而是对已有模型进行新的演绎。</p><p>“我想得到他拥有的。”</p><p>第七宗罪:傲慢</p><p>考虑到设计师对作品的骄傲,这是很容易犯的错。正如提到的,骄傲保证了质量,但太多则令你偏离轨道。</p><p>当设计师对项目的理解被不断膨胀的自命不凡蒙蔽时,这就是傲慢。设计只展现设计师的理念,而不是客户的任务需求。用户看到的是遍布设计师印记的作品,而忽视了产品信息。</p><p>设计师最好是无名氏。用户应意识到他们所浏览的网站背后设计师的存在,但你应留意不要在你的设计上留下过多的个人印记。骄傲是好的,但和所有事情一样,过犹不及。控制它是你的责任。</p><p>过犹不及</p><p>结语</p><p>当你察觉到这设计中的七宗罪,设计项目推进就更容易。</p>

阅读剩余部分 -

JavaScript富应用MVC MVVM框架

<h3>对框架的挑选 Ember.js、Backbone.js、Knockout.js、Spine.js、Batman.js , Angular.js</h3><p>1. 轻量级的应用选择哪一个会比较好?
2. 那一个比较简单,容易上手
3. 哪一个开发周期最短?</p><div style="page-break-after: always;"><span style="display: none;"><!--more-->& nbsp ;</span></div><p><span> </span>具体可以看   (英) Rich JavaScript Applications – the Seven Frameworks</p><p>                        Web前端开发:为何选择MVVM而非MVC</p><p>由于工作关系~一直没时间细细研究下这些框架的源码~ 早期就看过Backbone.js与EXT4的MVC</p><p>最近开始研究业界小有名气司徒正美的mvvm框架avalon</p><p>为什么放着Angular,Ember不去分析,而去研究avalon呢, 看了http://rubylouvre.github.io/mvvm/</p><p>其实作者就是基于Angular,Ember,knockout这种成熟的框架中,演化出来的avalon,所以avalon我不说媲美这些框架,但是从研究的角度入手,我觉得未必不可</p><p>核心的功能avalon都能够完成,只是组件不够多,毕竟是个人行为的 ,  avalon 源码分析目录 , 博主已经开始研究angular,尽量同步推出源码分析</p><p> </p><p>对比:</p><ol> <li>angular是找大而面的道路,因此体积非常庞大,1.6-1.7万行;</li> <li>avalon旨在提供一种远离DOM操作的前端开发体验,0.6.3只有2420行,min只有29kb。</li> <li>avalon 从angular抄来了不少好东西,如{{}}插值表达式,ms-model(通过事件实现双向同步),ms-controller(为了 VierModel指定作用域范围),但都做了增强,{{aaa|html}添加html过滤器就能输出innerHTML,ms-model可以通过 data-observe来开关双向同步,ms-controller拥有孪生兄弟ms-important。</li> <li>avalon的$watch与ms-bind方法提供比angular强大得多回调功能。</li> <li>avalon拥有像knockout, emberjs那样的计算属性, angular没有。</li> <li>avalon与angular都拥有监控数组,但avalon的监控数组像knockout那样拥有大量好用的方法,能自动同步页面,angular的则相当弱。</li> <li>avalon 与angular都拥有定义UI的功能(将一个元素变成一个UI组件),angular是使用自定义标签,avalon是使用ms-ui属性,但自定义标 签在旧式IE并不好使,并且可能随着浏览器的升级,浏览器会添加一个与你一模一样的新标签。avalon则安全多了,并且拥有12UI组件可做参考,实现 起来非常简单。</li> <li>avalon是采取边扫描边转换绑定的策略,用户打开页面后立即能看到效果,angular是要全部扫描后才转换绑定,因此用户可能看到一些奇异的模板。</li> <li>avalon是通过define方法来定义ViewModel,并有scan方法指定作用的元素与ViewModel。angular要求用户将xxxxCtrl函数暴露到全局作用域下,框架自己去取去组装。</li> <li>avalon在ViewModel有个$json,就是ViewModel对应的纯数据的Model(ViewModel每次被操作,都会自动同步View与Model的),我们可以直接将它放到AJAX中使用。angular没有独立的Model,需要自己转换。</li> <li>avalon是使用Object.defineProperty与VBS实现ViewModel,angular则是将整个xxxxCtrl函数进行编译,转换一大堆getter, setter从而实现双向绑定,因此angular的体积是相当庞大的。</li> <li>avalon的绑定值可是ViewModel的属性或数组或表达式, angular则允许用户在视图定义新变量,新对象,这是个不好的特征,会让页面非常难维护。</li> <li>avalon的绑定已经强大到让用户完全脱离DOM写业务,顶多是取一下表单元素的checked, disabled等状态值,angular还是传统的思路,只是在1.0后添加数据绑定机制。</li></ol><p>其实说了一堆,并非是说angular不够好avalon超过angular,正如作者所说angular是找大而面的道路,因此体积非常庞大,就跟EXT一样想什么都想揽着.</p><p> </p><h1>各个框架的技术速览</h1><p>Backbone</p><ul> <li>作者:Jeremy Ashkenas and DocumentCloud</li> <li>内容: <ul> <li>Model-View模式,MIT 许可</li> <li>最小的类库——仅仅一个文件,800行代码!</li> <li>很专一的功能——仅仅提供REST持久化模型以及简单的路由和回调,这样就可以让你知道什么时候去渲染实体(需要自己设置渲染机制)</li> <li>最著名的,被许多大牌网站使用(或许是因为它小而易于被接受)</li> </ul> </li> <li>优点:</li> <li>它很小,你可以在使用之前通过读源代码来弄懂它。</li> <li>对你的服务端架构和文件结构都没有影响,可以只在页面的一小部分起作用,并不需要考虑整个页面。</li> <li>Jeremy就像一个禅宗大师,对所有的问题都很有观点。他就像一个大人指导着一群吵闹的孩子。</li> <li>项目地址:GitHub官网</li> <li>发布时间:两年前</li></ul><p>Meteor</p><ul> <li>作者:Meteor开发团队,他们刚刚获得了1120万美元的融资所以可以全职开发Meteor</li> <li>内容: <ul> <li>这是一个来自未来世界的令人惊讶的框架,它拥有你所没有见过的东西(可能除了Derby)</li> <li>在服务端(Node.js + Mongo)和客户端使用相同的代码,使二者(包括数据库)连通起来.通过WebSockets来同步服务端和所有的客户端。</li> <li>当修改代码时就可以“实时部署”——客户端会快速更新而不会丢失他们的内容。</li> <li>如果提供视频观看会更加合适【演示】</li> <li>和其他的人一样,我真心希望这个项目会成功——WEB开发需要一些像这样有激情的项目来向前推进。</li> </ul> </li> <li>优点:当你收购了web开发的一些陈规旧俗,Meteor可以让你走在前沿。</li> <li>项目地址: GitHub,官网</li> <li>发布时间:仍是早期版本,目前我不知道有哪些网站正式使用Meteor。但是它的核心团队正在认真地做着这个项目。</li></ul><p>Ember</p><ul> <li>作者: Yehuda Katz (Rails和Jquery的先前开发者),Ember团队已经 Yehuda 的伙伴Tilede</li> <li>内容: <ul> <li>它包含建立一个"强大的Web应用"的一切,采用的是MIT许可</li> <li>在所有的框架中是功能最强大,当然库的大小也很大.</li> <li>它的着眼点在于怎样把怎样把一个页面分解成一个个有层次的控件,然后通过一个有状态的路由系统来连接起来.</li> <li>正在开发更加精细的数据接入类库(Ember.Data)</li> <li>会在运行时对所有的页面控制,因此对于使用了很多内容的部分(如silverlight,ajax,flash)可能不合适.</li> <li>文件结构和URL都是固定的,但是可以被重写.</li> <li>其设计灵感来自Rails和Cocoa</li> <li>使用:它为Rails提供工程模版(你也可以通过手动配置来使它应用在别的服务端技术上)</li> </ul> </li> <li>优点:常见的问题应该有常见的解决方法--Ember提供了所有的常见解决方案,你只需要考虑对你的应用程序来说那个是适用的.</li> <li>项目地址GitHub,官网;</li> <li>开始时间: 仍然不是1.0的发布版本,不过很快会发布,API到时候也会发布(*译者注:已经发布1.0的pre版本)</li></ul><p>AngularJS</p><ul> <li>作者:google的开发者,主要是他们内部使用,并且采用MIT协议</li> <li>内容: <ul> <li>MVW(Model-View-Whatever )模式</li> <li>基于DOM的模版声明式绑定.</li> <li>内置基础的url路由和数据序列号</li> <li>工具:他们实现了一个可以让你在调试时监视你的数据模型的chrome的调试插件,以及一个针对Jasmine 测试框架的插件</li> </ul> </li> <li>优点:</li> <li>按照他们所宣传的,这是一个未来浏览器会原生支持的框架,所以我们应该现在就用这种方式来编程。</li> <li>对服务器端的架构和文件结构没有影响,可以用在不需要对整个页面控制的小部分。</li> <li>项目地址: GitHub,官网</li> <li>开始时间:已发布(曾在google使用过)</li></ul><p>Knockout</p><ul> <li>作者: Knockout团队和社区(包括我在内目前核心团队有三个成员)</li> <li>内容: <ul> <li>Model-View-ViewModel (MVVM) in JavaScript, MIT licensed</li> <li>关注与富UI:基于DOM的声明式绑定,拥有自动依赖检测的"观察者“模型</li> <li>不强制绑定URL路由和数据——和其他第三方库结合(例如使用Sammy.js做路由,采用ajax方式存储数据)。</li> <li>着重关注于易用性,有大量的文档和交互的例子</li> </ul> </li> <li>特点:</li> <li>专注于UI,支持IE6</li> <li>对服务器架构和文件系统没有影响。可以用在不需要对整个页面控制的小部分。</li> <li>项目地址: GitHub,官网</li> <li>开始时间: 发布将近两年</li></ul><p>Spine</p><ul> <li>作者: Alex MacCaw</li> <li>内容: <ul> <li>MVC in JavaScript, MIT license</li> <li>最初作为O’Reilly一本书的示例代码,最终演变为一个开源代码工程</li> <li>是Backbone的一个克隆版本(就像名字那样)(译者注:Spine和Backbone都有脊柱的意思)</li> </ul> </li> <li>特点:你希望用不同的方式来使用Backbone二者不同可以参看这里</li> <li>项目地址: GitHub,官网</li> <li>开始时间: 已经发布1.0.0版本</li></ul><p>Batman</p><ul> <li>作者:Shopify团队(一个电子商务平台公司)</li> <li>内容: <ul> <li>支持Javascript的MVC架构,几乎是为Rails+CoffeeScript开发者设计的。MIT 许可</li> <li>定制性最强的一个框架,你必须按照它的约定(例如文件结构和URL路径),否则,就像它”高傲“的作者们所说的:“不遵循约定就别用”。 全栈式的框架,拥有丰富的模型,视图和控制器及路由。当然也有观察模式的机理。 *基于DOM的模版</li> </ul> </li> <li>特点: 如果你使用Rails和CoffeeScript,你会得心应手……</li> <li>项目地址: GitHub,官网</li> <li>开始时间:目前是0.9版,预计在未来几个月内发布1.0版本。</li></ul><p>CanJS</p><ul> <li>作者:bitovi团队(一个js咨询培训公司)</li> <li>内容: <ul> <li>MVC in JavaScript, MIT licensed</li> <li>REST-persistable模型,基础的路由,基于字符串的模版。</li> <li>并不很出名(我在上周前还不知道它),尽管它是一个很老的javascript mvc项目的重新开放。</li> </ul> </li> <li>特点:致力于构建一个轻量的,提供上述所有框架都具有功能特性的最好的框架。</li> <li>项目地址: GitHub,官网</li></ul><p>总结</p><p>如果你在考虑究竟那个是最适合你的项目,我觉得应该考虑两个方面:</p><ul> <li> <p>应用范围: 你希望一个框架或者类库能够帮助你做多少东西?你是希望有一个可以让你从0开始全程都为你提供架构帮助的全能框架,还是希望自己定制模式和类库?不管选择那种,对不同的项目和团队都是有价值的。</p> </li> <li> <p>设计美学:你是否看过这些框架并且想自己构建一个小型的类库?你喜欢这样做吗?不要根据局限与描述或者功能列表去选择。忽略你自己的编码习惯就像仅仅根据小说的目录去买书或者是根据个人简历和履历来选择配偶。</p> </li></ul><p>除了不同的地方,我可以肯定上述这些技术都遵循的一个功能:模型和视图分离。这是一种在20年钱就已经存在的经典设计模式。即使你在构建最简单的web应用界面你也能从这种模式中受益。<span> </span></p>

阅读剩余部分 -

如何让你的APP变快

<p>大家都知道不管网页还是移动APP,响应速度都是最重要的体验指标之一,并且移动应用的网络环境不稳定,速度的体验显得尤为重要。其实速度优化不仅是程序员的事,设计,也能够让APP变得更快。</p><div style="page-break-after: always;"><span style="display: none;"><!--more-->& nbsp ;</span></div><h3>1.后台执行</h3><p>这是一条很通用,也容易理解的方法。用户不会愿意盯着进度条傻傻地等待,除了“取消”没有其他选择。在系统处理一些网络任务的时候,完全可以允许用户做一些其他的事情。各大平台的发微博,都采用了后台执行。云阅读的离线下载也采用后台执行。</p><p></p><p>而微博的看长图(或视频),是个反例。网络不给力时,要么等待1分钟让图加载完,要不就只好放弃看图。为什么不能让图加载的同时,用户可以看其他微博呢?</p><p></p><h3>2.在载入前显示内容</h3><p>客户端与web的一个不同点,客户端的显示内容包括本地数据和网络数据两部分。在设计界面时,将更多的信息放在本地,在网络数据未载入时即显示本地 数据,让用户产生一种“已经载入一半了”的错觉,即使最终的耗时一样,心理感受也会更快。当然把数据过多地写在本地,会牺牲一些灵活性,需要根据具体情况 考虑。</p><p></p><p>如App Store的详情页,在详细信息载入前,已有信息先显示。</p><h3>3.充分利用好缓存</h3><p>缓存可以把网络数据保存在本地,下次打开时无需要再次向网络请求,减少流量并减少等待时间。在设计时,可以先显示缓存内容,同时后台到网络上拉取新 内容,若有新内容立即替换或下次访问时替换。但缓存使用也要注意“度”,过大的缓存文件占用太多的系统空间,会让用户一怒之下卸载APP。</p><h3>4.界面先行,网络交互随后</h3><p>对于一些数据量很小,且失败可能性较小的网络交互,用户并不需要明确知道APP在干这些事情,也能够顺畅地使用APP,那么就可以“把一些事实掩盖起来”,即界面上听话地、迅速地完成任务(心智模型),程序后台默默地继续执行任务(实现模型)。</p><p>最常用的比如QQ、微信、易信等聊天界面。点击发送后,消息立即”飞”到聊天上下文中,其实对方还没收到。但这样的设计让沟通的过程更顺畅,没有“正在发送 – 发送成功”各种过程的干扰。</p><p>5.预测用户行为,提前开始任务</p><p>不知道大家使用淘宝有没有这样的习惯,在搜索结果列表,将所有感兴趣的结果都打开为新标签页,然后一个个地看,没兴趣的就关闭。这样做的好处是,在我浏览商品详情页的时候,每个页面都是载入完全了,否则我点开一个看一个,每个都要等待加载完,就会大大降低效率。</p><p>那么能否通过设计,来满足类似使用场景呢?应该是可以的,那就是预测用户的行为,提前开始任务。</p><p>策略类似这样:用户在某个界面停留的时候,预测下一步可能做ABC三个任务,系统于是把这些任务都提前做完。当用户做出选择比如A时,界面可以迅速响应,并且同时把BC两个任务从内存中清空掉以节省资源。(当然这招也有限制:1,只适用于免费的网络。2,预加载不能影响系统的性能)</p><p>后台自动加载新内容:并在刷新按钮上显示“NEW”,此时当用户再刷新,内容立即呈现。</p><p></p><p>再比如Chrome在下载前询问是否保存,在用户决定之就已经开始下载,节省了不少时间。如果用户放弃,已下载内容会自动删除。</p><p>那么,用这个思路:</p><p>● 写微博插入照片后,能否自动上传,而不必等用户点击了“发送”才上传?
● 看微博时定位到某条微博,是否应该自动加载大图或视频?
● 音乐应用在当前歌曲快播放完时,是否应该下载下一首歌,以免切歌的时候会卡一会儿?</p><h3>6.使用动效来掩护载入过程</h3><p>优秀的动效设计,让产品更好用且让人眼前一亮。其实,动效还有另一大用处,吸引用户的注意,让本来枯燥的等待载入的过程,变成愉悦欣赏的过程。</p><p>实例:</p><p></p>

阅读剩余部分 -

UE、UI、UCD、UED、UID、UX

<p>字面释义:</p><p>UE (User Experience) : 用户体验</p><p>UI (User Interface) : 用户界面</p><p>UCD (User-Centered Design) :以用户为中心的设计</p><p>UED (User-Experience Design) :用户体验设计</p><div style="page-break-after: always;"><span style="display: none;"><!--more-->& nbsp ;</span></div><p> </p><p> </p><p>UI(User Interface)即用户界面,也称人机界面。是指用户和某些系统进行交互方法的集合,这些系统不单单指电脑程序,还包括某种特定的机器,设备,复杂的工具等。</p><p>
软件设计可分为两个部分:编码设计与UI设计。编码设计大家都很熟悉,但是 UI设计还是一个很陌生的词,即使一些专门从事网站与多媒体设计的人也不完全理解UI的意思。UI的本意是用户界面,是英文User和 interface的缩写。从字面上看是用户与界面2个组成部分,但实际上还包括用户与界面之间的交互关系。</p><p>
界面设计。在漫长的软件发展中,界面设计工作一直没有被重视起来。做界面设计的人也被贬义的称为“美工”。其实软件界面设计就像工业产品中的工业 造型设计一样,是产品的重要买点。一个友好美观的界面会给人带来舒适的视觉享受,拉近人与电脑的距离,为商家创造卖点。界面设计不是单纯的美术绘画,他需 要定位使用者、使用环境、使用方式并且为最终用户而设计,是纯粹的科学性的艺术设计。检验一个界面的标准即不是某个项目开发组领导的意见也不是项目成员投 票的结果,而是最终用户的感受。所以界面设计要和用户研究紧密结合,是一个不断为最终用户设计满意视觉效果的过程。</p><p> </p><p>交互设计(Interaction Design) 作为一门关注交互体验的新学科在二十世纪八十年代产生了,它由IDEO的一位创始人比尔•莫格里奇在1984年一次设计会议上提出,他一开始给它命名为“ 软面(Soft Face)”,由于这个名字容易让人想起和当时流行的玩具“椰菜娃娃(Cabbage Patch doll)”,他后来把它更名为“Interaction Design”――交互设计。</p><p> </p><p>UED是进行产品策划的主力之一,他们用自己的知识、经验、设计能力拿出设计方案。ED不只是互联网专家,还是行业专家。能够用自己的互联网知识来设计出行业专家想实现的操作,而付诸以商业营销。</p><p>简单的说,在进行产品设计时从用户的需求和用户的感受出发,围绕用户为中心设计产品,而不是让用户去适应产品,无论产品的使用流程、产品的信息架构、人机交互方式等,都需要考虑用户的使用习惯、预期的交互方式、视觉感受等方面。</p><p>
衡量一个好的以用户为中心的产品设计,可以有以下几个纬度:产品在特定使用环境下为特定用户用于特定用途时所具有的有效性 (effectiveness)、效率(efficiency)和用户主观满意度(satisfaction),延伸开来还包括对特定用户而言,产品的易 学程度、对用户的吸引程度、用户在体验产品前后时的整体心理感受等。</p><p>
UCD是将来公司开展网络服务所必须的,所以UCD职位也将是一种趋势。</p><p>用户体验(User Experience,简称UE)是一种纯主观的在用户使用一个产品(服务)的过程中建立起来的心理感受。因为它是纯主观的,就带有一定的不确定因素。个 体差异也决定了每个用户的真实体验是无法通过其他途径来完全模拟或再现的。但是对于一个界定明确的用户群体来讲,其用户体验的共性是能够经由良好设计的实 验来认识到。</p><p>
用户体验主要是来自用户和人机界面的交互过程。在早期的软件设计过程中,人机界面被看做仅仅是一层包裹于功能核心之外的“包装”而没有得到足够的 重视。其结果就是对人机界面的开发是独立于功能核心的开发,而且往往是在整个开发过程的尾声部分才开始的。这种方式极大地限制了对人机交互的设计,其结果 带有很大的风险性。因为在最后阶段再修改功能核心的设计代价巨大,牺牲人机交互界面便是唯一的出路。这种带有猜测性和赌博性的开发几乎是难以获得令人满意 的用户体验。至于客户服务,从广义上说也是用户体验的一部分,因为它是同产品自身的设计分不开的。客户服务更多的是对人员素质的要求,而已经难以改变已经 完成并投入市场的产品了。但是一个好的设计可以减少用户对客户服务的需要,从而减少公司在客户服务方面的投入,也降低由于客户服务质量引发用户流失的机 率。</p><p> </p><p>交互设计是一门特别关注以下内容的学科:
1、定义与产品的行为和使用密切相关的产品形式。
2、预测产品的使用如何影响产品与用户的关系,以及用户对产品的理解。
3、探索产品、人和物质、文化、历史之间的对话。</p><p>
交互设计从“目标导向”的角度解决产品设计:
1、要形成对人们希望的产品使用方式,以及人们为什么想用那个这种产品等问题的见解。
2、尊重用户及其目标。
3、对于产品特征与使用属性,要有一个完全的形态,而不能太简单。
4、展望未来,要看到产品可能的样子,它们并不必然就像当前这样。</p><p> </p><p>UDC需要学习的课程</p><p>•人机交互的认知心理学、工程心理学基础
•人的因素、人类工效学基础
•人机交互的研究方法
•用户调查和研究方法
•可用性工程与评估方法
•软件中的交互设计
•软件产品的界面视觉设计原则、标准及经验分析
•以用户为中心的界面设计与开发过程
•界面设计与评估案例分析
•人机交互界面的编程实现
•人机工程项目管理
•人机交互技术的最新进展</p>

阅读剩余部分 -

随机文章

最近回复

分类

其它

友情连接

推广链接