Category Archives: 月光博客

良好的源代码控制管理十戒

  我还没有见过比源码版本控制这样跨任意编程语言更基本的工具。 这是我们用过的最基本的工具,是很多开发团队的生命线。 那么,为什么我们经常会用错呢? 为什么一些真正的核心,版本控制系统的基础往往知之甚少?   我总结了10个实践 或“戒律” – 这通常是发生故障或错误理解的开始, 是与版本控制产品和编程语言无关的。 我会从Subversion和.NET挑选一些例子,但它们广泛适用于其他技术。   1。 如果还在使用VSS,马上停手   平心而论,在1995年VSS曾是一个伟大的工具。  不过因为有了像Subversion甚至分布式的如Git和Mercurial工具变得黯然失色。 很多年前微软已经明确表明废弃它了!   由于一系列的重大缺陷,VSS曾受到广泛的几乎一致的鄙视, 俗称为微软的源代码破坏系统 。   2。 如果源代码没有处在版本控制,那等于还没有   每天重复此咒语 – “进步的唯一标准是工作代码处在源代码控制中”。 直到你的成果出现在源代码控制里 – 变成源控制库中的项目 – 否则它根本不存在。   当然,你已经把代码做好在本地计算机上的某个地方,但,对其他人来说这不是真的做好了,对吗? 他们不能拿到你的版本,他们不能合并他们的修改,你无法部署它(除非你部署出错 ),一旦发生硬盘损坏你将永久丢失这些文件。   你要保持除非提交否则根本还没有的心态,一大堆的其他良好的运作因为没有提交开始陷入困境。 你应将任务分解成更小的单位,这样你可以原子地提交。 您应频繁地整合,保证自己不受本地硬件故障的影响。   但更重要的是(至少对你的团队领导来说),你证明你实际做了东西。 燃尽图曲线下降或分解列举任务列表是很棒的,但他们真的顺畅吗? 除非这些与工作源码控制中的工作代码关联上,他们才意味着完成。   3。 尽早提交,频繁提交,越快越好   继续上一点,只有这样,才能避免“幽灵代码” … Continue reading

沃尔玛实验室开源项目一览

  众所周知,沃尔玛是世界第一大零售商;但少为人知的是,沃尔玛有一个实验室:WalmartLabs,该实验室在开源项目上有不少贡献,并在GitHub上有主页。这些项目中,大部分都与Node.js和JavaScript有关。   沃尔玛实验室的“关于我们”页面上这样介绍自己:   沃尔玛实验室以创新的方式融合零售、社交和移动技术,为世界上最大的零售商重新定义“商务”的含义。我们是一群业内最聪明的技术专家和商业人才。对于下一代“商务”将会带给全球几十亿人的无限机会,我们感到十分兴奋,并致力于帮助他们节省金钱,更好地生活。   沃尔玛实验室有两位带头人,一位是Jeremy King,是沃尔玛的资深副总,兼全球电子商务首席技术官,他曾在eBay工作7年时间,担任工程和软件开发副总,并带领团队选型并落地了下一代应用平台——“V3”,并领导过交易和欺诈工程团队。他还主导设立了中国和印度的研发中心,也曾是PayPal整合团队的核心成员。另一位是Gibu Thomas,是移动和数字化资深副总。   在GitHub的主页上,显示沃尔玛实验室共有41个项目,有11名成员。下面简单介绍下最活跃的几个项目:   thorax:基于Backbone的应用框架,提供文件系统结构、按需模块加载、模型和集合视图绑定、继承视图和DOM事件、数据加载助手、表单序列号和验证等功能。其中用到Backbone、Underscore、Zepto、Handlebars、Stylus和Lumbar。   hapi:基于Node.js的框架,提供restful的API服务。hapi以配置为核心,提供鉴权需求、输入验证、数据缓存和预加载等功能,并允许使用简单的JSON配置对象。开发人员使用hapi,可以将主要精力放在编写可重用的业务逻辑上,而不是用来做其他方面的琐碎事情。    joi:对象schema验证系统。基于丰富的、描述性的schema,验证JavaScript对象。   hoek:node实用工具。   lout:供hapi服务器使用的文本生成器,为使用路由配置的每个端点提供易于阅读的指南。并允许对输出的完全定制。   helmet:hapi的交互调试控制台。   FakeToe:XML到JSON的转换器。   log:hapi的处理监控工具。   Flod:系统化工具集,用来评测和对比Node.js web服务器框架,允许开发人员对比不同版本的、自己的框架,以及其他人的框架。   catbox:多策略对象缓存服务。   上述这些工具,统归在Blammo项目之下。   MUPD8:基于MapReduce风格的框架,实现MapUpdate框架,用来处理快速或流数据。   Lumbar:js构建工具,使用一个通用的代码库,以及一个平台列表,以产生模块化的、特定于平台的应用。可将其视为以平台为目标的条件化编译器。但它不使用源代码中的变量,而是通过将文件与平台关联达到目的。使用一个json文件lumbar.json来描述项目的元数据。Lumbar能与Backbone配合使用,允许对路由、模型、视图和其他应用代码分组,打包为独立的Javascript和CSS文件,在遇到对应路由时,可以延迟加载。   Lumbar-tester:Lumbar的单元测试插件。   在零售领域,沃尔玛越来越感受到亚马逊给它带来的威胁。在FastCompany一篇名为《沃尔玛:从大卖场巨人到电商创新者》的文章中,记述了沃尔玛面对威胁做出的改变,沃尔玛实验室的成立,就是其中之一。     来源:InfoQ投稿,作者:郑柯,原文链接。 评论《沃尔玛实验室开源项目一览》的内容… 相关文章: 用于展现图表的50种JavaScript库 12306反制浏览器被指“傻大黑粗” 12306订票助手插件拖垮GitHub事件始末 谁是中国移动互联网创新的毁灭者 第三方账号登陆还是自主账号登录 微博:新浪微博 – 腾讯微博 QQ群:121878450月光博客投稿信箱:williamlong.info(at)gmail.comCreated by William Long www.williamlong.info … Continue reading

用于展现图表的50种JavaScript库

  在很多项目中都会有在前端展现数据图表的需求,而在开发过程中,开发者往往会使用一些JavaScript库,从而更有效地达到想要的目标。最近,TechSlide上的一篇文章总结了50种用于展现图表的JavaScript库,并对每种库做了简要的说明。这对于想要选择合适JavaScript库的开发者很有参考意义。   文章作者首推的库是D3,他说到:   它非常让人惊叹,我很喜欢它的简洁性。它的文档非常完备,源代码托管在GitHub上,而且不断会添加新的示例。有一种叫做Tributary的创建D3原型的工具,其中有很多非常棒的示例。这个库非常好,以至于xcharts、nvd3、Rickshaw、Cubism.js、dc.js、xkcd都是基于它构建的。如果你想要做出优秀的自定义数据可视化效果,那么D3可能是你最佳选择,或者对于更简单的图,你可以选择上面所提到的基于D3的库。最后,我强烈推荐阅读Scott Murray关于D3的免费书《Interactive Data Visualization for the Web》和《Dashing D3 tutorials》。   接下来,他列举并简要说明了其它用于展现数据、制作表格和图表的JavaScript库,列在前20位的如下: HighCharts——它非常强大,你可以在JSFiddle中查看和编辑大量示例。它不免费,但拥有很多客户(IBM、NASA、MasterCard等)。它还向下兼容IE 8。 jqPlot——如果你已经在使用jQuery,不想为HighCharts付费,而且情况很简单,不需要D3那样复杂的库,那么jqPlot是很好的选择。 dygraphs——一种开源的JavaScript库,可以做出可交互、可缩放的时间线图表。对于大数据集合非常适用。 Protovis——和D3出自同一支团队之手,是一种免费的开源库。你可以查看这个stackoveflow 页面来了解D3与其的区别。 Flot Charts——与jqPlot一样,Flot是一种针对jQuery的纯JavaScript库,专注于简单的用法、引人注目的外观和交互特性。 Google Chart Tools——强大、免费、易于使用。内容丰富,从最简单的线状图到负责的层级树状图都有,在展示页面中提供了大量设计良好的图表类型。 dc.js——基于D3的JavaScript图表库,拥有本地跨过滤器(crossfilter)的支持,并让你可以高效率地浏览大型多维数据集。 xcharts——基于D3用于构建自定义图表的库。 nvd3——让你可以构建可重用的图表和图表组件,同时具有d3.js的强大功能。 rickshaw——用于创建可交互时间线图表的JavaScript工具。 Cubism.js——用于可视化时间线的D3插件。使用了Cubism构建更好的实时仪表盘,可以从Graphite、Cube和其他源拉取数据。 xkcd——让你可以使用D3在JavaScript中做出XKCD样式的图表。 jQuery Sparklines——一种jQuery插件,可以直接在浏览器中创建小型的内嵌图表。 peity——一种简单的jQuery插件,可以把元素的内容转换成简单的饼图、线图和柱状图。 BonsaiJS——一种轻量级的图形库,拥有直观的图形API和SVG渲染器。 Flotr——为Prototype.js所用的JavaScript图表库。它拥有很多特性,像对负数值的支持、鼠标跟踪、选定支持、缩放支持、事件挂钩、CSS样式支持、在画布(canvas)中包含文字、旋转的标签、渐变颜色、图形标题和子标题、电子表格、CSV数据下载等等。 ProtoChart——物如其名,ProtoChart让你可以使用JavaScript和Prototype创建很漂亮的图表。它是一种开源库。 Flotr2——HumbleSoftware当前正在做的项目,让你可以使用Canvas和JavaScript创建图表。 jQuery-Visualize——HTML的table元素驱动的HTML5 canvas图表。也是针对jQuery的图表插件。 JS Charts——基于JavaScript的图表生成器,只需要很少甚至不需要编码。免费版会有水印,可以通过付费去掉。 … Continue reading

© 2013 . All rights reserved.

预防Web应用程序的漏洞

  如今的Web应用程序可能会包含危险的安全缺陷。这些应用程序的全球化部署使其很容易遭受攻击,这些攻击会发现并恶意探测各种安全漏洞。   Web环境中两个主要的风险在于:注入——也就是SQL注入,它会让黑客更改发往数据库的查询——以及跨站脚本攻击(XSS),它们也是最危险的(Category:OWASP_Top_Ten_Project)。注入攻击会利用有问题代码的应用程序来插入和执行黑客指定的命令,从而能够访问关键的数据和资源。当应用程序将用户提供的数据不加检验或编码就发送到浏览器上时,会产生XSS漏洞。   尽管2009年OWASP(Open Web Application Security Project)的一个报告表明安全方面的投资在增加(Category:OWASP_Security_Spending_Benchmarks),但是NTA Monitor的2010 Web应用安全报名表明Web的安全性跟前一年相比实际在下降。实际上,Web应用的漏洞给公司和组织带来了很多的问题。按照WhiteHat Security最新的Web站点安全性数据报告所示,被评估网站的63%是有漏洞的,每个平均有六个未解决的缺陷。(WhiteHat Website Security Statistics Report)。这些漏洞创建并维持了一个基于攻击窃取数据和资源的地下经济链。   Web应用程序需要有深度防御的措施来避免和减少安全性漏洞。1这种方式假设所有的安全预防措施都可能失败,所以安全性依赖于多层的机制从而能够覆盖其他层的失败。为了减少成功攻击的可能性,软件工程师团队必须做出必要的努力来引入适当的安全性防护措施。要达到这一点必须使用各种技术和工具来确保安全性涵盖软件产品开发生命周期的所有阶段。   软件开发生命周期中的安全性   尽管软件开发的生命周期有多种不同的划分方式,但正如图1所示,它通常包含如下的阶段:初始化、规范和设计、实现(编码)、测试、部署以及停用,这些阶段应用开发人员可以不断地重复迭代。2   尽管开发人员应该在产品的整个生命周期中都关心代码安全性,3但是他们应该特别关注三个关键阶段:1 实现。在编码过程中,软件开发人员必须使用特定应用领域内避免关键漏洞的最佳实践。这种实践的例子包括输入和输出校验、识别恶意字符以及使用参数化的命令。4 尽管这些技术在避免大多数安全漏洞方面很有效,但因为缺乏安全相关的知识,开发人员通常并不使用它们或者使用得不正确。边栏“为什么开发人员不使用安全编码实践?”更详细地讨论了这个问题。 测试。有很多技术可以在测试阶段使用,包括渗透测试(目前最流行的技术)、静态分析、动态分析以及运行时的异常检测。4 问题在于开发人员通常会关注需求功能的测试而忽略安全方面。另外,现有的自动化工具要么在漏洞探测覆盖度方面比较差要么产生太多的误报。 部署。在运行时环境中,会有不同的攻击探测机制。这些机制可以按照不同的级别运行并使用不同的探测方式。它们的使用障碍在于性能开销以及不准确的结果会打乱系统的正常行为。   开发安全的代码   为了编写没有漏洞的安全代码,4 基于Web基础设施的关键业务开发人员就要遵循编码实践,这个实践包括了深度防御的措施,它假设所有的安全性预防措施都会失败。在实现阶段依赖多层的安全机制是特别重要的,使用一个预防或保护措施来避免安全漏洞是不够的。   Web应用程序的特征在于需要三层不同的安全防线:输入校验、热点保护以及输出校验。   输入校验   大多数的安全漏洞是因为目标应用程序没有正确地校验输入数据。1所以,应用程序要考虑到所有恶意的输入直到能证明其合法,这要涵盖不可信环境中的所有数据。   输入校验是第一道防线,总体来讲就是缩小应用程序允许输入的范围,它会直接作用在用户提供的数据上。这种类型的防御要依赖输入参数在一个合法的范围内,或者如果用户提供了超出了范围的值就会停止执行。在Web应用程序中,这首先要标准化输入将其转换到基线字符集和编码。接下来,应用程序必须对标准化的输入使用过滤策略,拒绝那些值在合法范围之外的输入。这种方式能够避免很多Web应用程序中的问题,在执行输入校验时会使用正向模式匹配或正向校验。在这种情况下,开发人员建立规则来识别那些可接受的输入而不是识别有什么输入是不可接受的。尽管开发人员不能预测所有类型的攻击,但他们应该能够说明所有类型的合法输入。   关键问题在于,输入校验通常使用地并不充分,这是因为输入参数的数据域允许存在恶意数据,这是与校验执行相独立的。例如,在SQL注入漏洞中,大多数的SQL语句使用引号作为字符串分隔符,这就意味着黑客可以使用它来执行SQL注入攻击。4但是,在有些情况下,字符串输入域必须允许存在引号值,所以应用程序不能排除所有包含引号的值。   热点防护   为了应对输入校验的局限性,有必要采用第二道防线   任何类型的攻击都是以热点为目标的,热点指的就是应用程序中可能会有某种类型漏洞的代码。通用的输入校验会在应用程序中进行或者在整个Web应用程序上下文中修改输入,与之相比,第二道防线关注于保护重要的热点,例如保护那些真正使用输入域值的代码行。   一个具体的例子就是SQL注入攻击,它们大多数会使用单引号或双引号。有些编程语言提供了对这些字符的转码机制,这样它们就能用在SQL语句中了,但是只能用来在语句中分隔值。4但是这些技术有两个问题。第一,更高级的注入技术,例如联合使用引号和转义字符,可以绕过这些机制。第二,引入转义字符会增加字符串的长度,如果结果字符串的长度超过数据库限制的话,可能会导致数据截断。   正确使用参数化命令是预防注入攻击最有效的方式。1在这种情况下,开发人员定义命令的结构,并使用占位符来代表命令的变量值。稍后,当应用程序将对应的值关联到命令上时,命令解释器会正确地使用它们而不会涉及到命令的结构。   这种技术最著名的用法是数据库的预处理语句,也被称为参数化查询。4 当应用程序创建预处理语句时,语句发送到了数据库端。应用程序使用占位符来表示查询的可变部分,占位符通常会是问号或标签。随后,每次查询执行时,应用程序都要往对应的可变部分绑定值。不管数据的内容是什么,应用程序会一直使用这个表达式作为一个值而并没有SQL代码。因此,不可能修改查询的结构。   为了确保正确使用数据,很多语言允许类型绑定。但是预处理语句本身并不能修复不安全的语句——开发人员必须正确地使用它们。例如,像传统语句一样使用预处理语句——也就是使用字符串拼接来绑定SQL查询——而不是对查询的可变部分使用占位符会导致类似的漏洞。   输出校验 … Continue reading

© 2012 . All rights reserved.

高效代码审查的十个经验

  代码审查(Code Review)是软件开发中常用的手段,和QA测试相比,它更容易发现和架构以及时序相关等较难发现的问题,还可以帮助团队成员提高编程技能,统一编程风格等。   1. 代码审查要求团队有良好的文化   团队需要认识到代码审查是为了提高整个团队的能力,而不是针对个体设置的检查“关卡”。   “A的代码有个bug被B发现,所以A能力不行,B能力更好”,这一类的陷阱很容易被扩散从而影响团队内部的协作,因此需要避免。   另外,代码审查本身可以提高开发者的能力,让其从自身犯过的错误中学习,从他人的思路中学习。如果开发者对这个流程有抵触或者反感,这个目的就达不到。   2. 谨慎的使用审查中问题的发现率作为考评标准   在代码审查中如果发现问题,对于问题的发现者来说这是好事,应该予以鼓励。但对于被发现者,我们不主张使用这个方式予以惩罚。软件开发中bug在所难免,过度苛求本身有悖常理。更糟的是,如果造成参与者怕承担责任,不愿意在审查中指出问题,代码审查就没有任何的价值和意义。   3. 控制每次审查的代码数量   根据smartbear在思科所作的调查,每次审查200行-400行的代码效果最好。每次试图审查的代码过多,发现问题的能力就会下降,具体的比例关系如下图所示:   我们在实践中发现,随着开发平台和开发语言的不同,最优的代码审查量有所不同。但是限制每次审查的数量确实非常必要,因为这个过程是高强度的脑力密集型活动。时间一长,代码在审查者眼里只是字母,无任何逻辑联系,自然不会有太多的产出。   4. 带着问题去进行审查   我们在每次代码审查中,要求审查者利用自身的经验先思考可能会碰到的问题,然后通过审查工作验证这些问题是否已经解决。一个窍门是,从用户可见的功能出发,假设一个比较复杂的使用场景,在代码阅读中验证这个使用场景是否能够正确工作。   使用这个技巧,可以让审查者有代入感,真正的沉浸入代码中,提高效率。大家都知道看武侠小说不容易瞌睡,而看专业书容易瞌睡,原因就是武侠小说更容易产生代入感。   有的研究建议每次树立目标,控制单位时间内审核的代码数量。这个方法在我们的实践中显得很机械和流程化,不如上面的方法效果好。   5. 所有的问题和修改,必须由原作者进行确认   如果在审查中发现问题,务必由原作者进行确认。   这样做有两个目的:   (1)确认问题确实存在,保证问题被解决   (2)让原作者了解问题和不足,帮助其成长   有些时候为了追求效率,有经验的审查者更倾向于直接修改代码乃至重构所有代码,但这样不利于提高团队效率,并且会增加因为重构引入新bug的几率,通常情况下我们不予鼓励。   6.利用代码审查激活个体“能动性”   即使项目进度比较紧张,无法完全的进行代码审查,至少也要进行部分代码的审查,此时随即抽取一些关键部分是个不错的办法。   背后的逻辑是,软件开发是非常有创造性的工作,开发者都有强烈的自我驱动性和自我实现的要求。让开发者知道他写的任何代码都可能被其他人阅读和审察,可以促使开发者集中注意力,尤其是避免将质量糟糕,乃至有低级错误的代码提交给同伴审查。开源软件也很好的利用了这种心态来提高代码质量。   7.在非正式,轻松的环境下进行代码审查   如前所述,代码审查是一个脑力密集型的工作。参与者需要在比较轻松的环境下进行该工作。因此,我们认为像某些实践中建议的那样,以会议的形式进行代码审查效果并不好,不仅因为长时间的会议容易让效率低下,更因为会议上可能出现的争议和思考不利于进行如此复杂的工作。   8.提交代码前自我审查,添加对代码的说明   所有团队成员在提交代码给其他成员审查前,必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外,还可以完成如下的工作:   (1)对代码添加注释,说明本次修改背后的原因,方便其他人进行审查。   (2)修正编码风格,尤其是一些关键数据结构和方法的命名,提高代码的可读性。   (3)从全局审视设计,是否完整的考虑了所有情景。在实现之前做的设计如果存在考虑不周的情况,这个阶段可以很好的进行补救。   我们在实践中发现,即使只有原作者进行代码审查,仍然可以很好的提高代码质量。   9.实现中记录笔记可以很好的提高问题发现率   成员在编码的时候应做随手记录,包括在代码中用注释的方式表示,或者记录简单的个人文档,这样做有几个好处:   (1)避免遗漏。在编码时将考虑到的任何问题都记录下来,在审查阶段再次检查这些问题都确认解决。 … Continue reading

© 2012 . All rights reserved.

可悲的百度算法机制

  最近似乎已经很少看到有关于SEO的相关文章了,这是不是印证了《SEO已死》这篇文章。可能,也许在中国,真正的SEO离死真的并不遥远了。   背景   最近有个朋友频频跟笔者抱怨,网站无法被百度正常收录,几个关键词的排名也是好几个月没有动过了。这位朋友是个专心做内容的家伙,因为时常被我灌输“内容为王”的理念,而他网站的相关行业客户对象一般都是年龄较大的互联网用户,在分享传播和外链上,几乎不能指望靠优秀的内容达成,所以在外链规模上十分有限。   另外,由于曾经因为有意识的购买外链而被搜索引擎惩罚,他也并不太敢于使用链接工厂的那些服务,只是花钱做了十来个所谓百度权重高大7的友链。毕竟行业不是很主流,他觉得也差不多了,其他精力都放在内容上了。   在这样“曲高和寡”  的作风下,有经验的朋友已经猜到了结局:那就百度收录极差,谷歌收录极好。但谷歌带来的流量实在太过坑爹,基本可以无视,甚至360搜索都比谷歌多。   这位老兄憋了两个月,终于忍不住问我:是不是还是要多搞点外链啥的?我看他那副惨样,终于长叹一声:搞吧。   回忆   以上这些事儿,如果发生在两三年前,我的建议肯定是——“酌情并有序地增加外链,避免作弊嫌疑”,如果发生在四五年前,我的建议肯定是——“给我义无反顾地搞外链,外链为皇!”。可是这已经是2012年的事儿了。   在这几年,对于那些平凡的网站来说,想得到百度的稳定排名真的不太容易。   我接触的数十位上海本地站长的一致公认:百度近一两年在排名方面存在严重的欺软怕硬现象。也就是说,普通网站不管是在内在外进行的各种优化都不见得会正常影响排名,甚至仿佛是随机抽取的,你基本得不到任何规律可言。你试试这招也没用,试试那招也没用,或者最多顶个几天用。总结下来,难道真得像百度所说,只要琢磨好《百度站长指南》,并把内功做好就行了?   在我遇到的企业级客户中,这种现象更加普遍。多个企业在没有进行任何黑帽优化的情况下,网站排名经常大幅波动,甚至持续性倒退。而在谷歌这里,却在收录方面得到了明显提升。而对于不少大型网站或者“重要站点”,即使啥都不干,排名与收录都很稳健,即使那网站做的一塌糊涂。   看起来这似乎是好事儿。搜索引擎的游戏规则那么神鬼莫测,是不是说明百度的技术已经真正超过了谷歌,“更懂中文”,能够更多靠内容和其他综合因素来判定结果,毕竟不管怎么说,百度的搜索体验不说最好,但也并不差。   现实   但事实并非如此,百度看似高明的算法变化与不留情面的生杀予夺,只是一件很可笑的事情,因为一切都没有改变。   让我们来2012年10月27日凌晨的一个例子,这是我观察了不少天的一个网站:   上图底部的那家网站是出现在百度搜索“平板电脑”这个关键词的首页自然排名中,排除竞价投放因素,它的自然排名居然仅次于中关村在线的开放接口、百度图片、百度百科,位于第四位。在27日下午再次核实,它依然排在前五,首页10个自然排名除了它全部出自中关村在线、Pconline、百度自有产品、泡泡网。如果这种事发生在类似“卢森堡移民”这一类的冷门领域倒还可以理解,但是在微软Surface、Ipad Mini、Nexus 7二代竞相登场的金秋十月尚能做到这些,这到底是哪一家平板厂商?   讽刺的是,百度居然在搜索结果中该网站标题的下方增加了这么一句话:“百度提示您:该页面可能因黑客侵入而存在安全风险”   点击该信息,显示结果其实就是有大量的电脑管家用户举报它为“欺诈”型网站。对该网站WHOIS用户信息和IP进行了追踪,发现该平板电脑销售网站的持有方是一家深圳的山寨厂。令人惊讶的是,他还不是一家卖数码产品的,而是卖生物制品的公司。根据同IP下反查出的16个网站显示,这家公司主营的产品基本都是女性减肥、美容类产品,例如左旋肉碱、木瓜汤之流。   写到这里,懂行的圈内人都会会心的一笑。   再探   那我们来看看这个网站做的如何。   这个网站做的中规中矩,算不上精致,但也并不难看。但仅就百度官方提供的“SEO建议”中涉及的那几项站内优化要求,我认为测试总分应不会超过70分,甚至堪堪及格。无论是JS位置、ALT信息还是DIV+CSS的要求,都并不是那么无懈可击。实际上,这顶多算是一个Landing Page型的销售页面,根本就没有代码层面SEO的基本思想在里面。   这让文首提到的那位老兄情何以堪,让那些手写sitemap的站长们情何以堪。   那么这家网站是如何做到这些的?而百度又是为何能让这么一个被频频举报为欺诈且没有付过一分钱给自己(这点清廉我们还是相信的)的山寨平板销售网站骑在联想、华为、京东、当当头上?这如果不是策略,难道是技术和算法上的原因?   可悲   我对该网站服务器上的10多个兄弟网站进行了调查,其中居然只有一个PR=0,其他网站PR都有2-3,要知道,这些可都是单页型的销售类网站,甚至不能叫网站,只是一个页面。   谷歌的PR说明不了太大问题,我们看看它的百度反链。   我的老天诶,11万多的百度反链。当然,由于雅虎退出搜索阵线,我没有找到特别好用的外链和锚文本检索工具,这11万中一定也包括很多无效的链接或者文本链接,同时,域名中的英文关键词与品牌标题一致也会增加反链统计数。然而毫无疑问,我们已经找到了答案。收录24,反链11万。   我记得上一个给我类似感觉的网站,叫做“麦包包”,高达65万的反链,连淘宝都甘拜下风。   仔细查看这些反链,我们发现了一位极为高明的SEO外链老手的痕迹,而且几乎都是新闻站的软文。由于软文本身存在被转载的可能,大量增加了domain在文本层面上的曝光几率。这也侧面证明,非锚文本链接对企业主站的意义,也一定程度上证实这样一句话:“只有几个人表扬你,有人会不服;但是成千上万人表扬你,不服也得服。”   百度无疑是服了,这就是百度的算法吗?在这样热门的关键词排名中,在网站被举报欺诈的情况下依然给出这么显赫的排名?这让那些因为相信百度而购买了接近2000元却用着MTK6573芯片的垃圾无售后山寨平板的普通用户作如何想法?   真是可悲,和五年前一样,其实什么都没有变。大道至简,唯“多”不破。   来源:投稿,作者:Shepherd,原文链接。 评论《可悲的百度算法机制》的内容… 相关文章: 为什么说内容营销是营销之王 … Continue reading

© 2012 . All rights reserved.

产品需求背后的用户动机

  在以用户为中心进行产品设计时,产品负责人需要透过简单的需求现象,寻找用户针对这种需求的行为动机是什么,只有这样才能真正达到服务用户的目的。 当我们使用 Foursquare、街旁签到时,这一行为有什么目的? 当我们在知乎上回答问题时,我们的动机是什么? 我们为什么会积极支持 Kickstarter 上的项目? …   用户需求与用户动机   UCD(以用户为中心的设计)方法可以说是当前产品构建时,最流行的一种设计思想。这种方法的核心思路是:用户知道自己想要什么。用户知道自己为什么使用一款产品、很清楚自己想要的功能是什么、自己已有偏好的使用习惯,在进行产品开发时,应该将用户的参与纳入到开发的每一个阶段。围绕用户的需求来进行产品的设计,而不是强迫用户改变他们的使用习惯来适应软件开发者的想法。   对于设计师来说,这不仅要求他们分析和预测用户可能会如何使用产品,更重要的是要在真实的使用环境下、利用实际用户的反馈来对自己的假设进行验证。这无疑是非常有必要的,因为对于产品设计人员来说,弄清新用户使用产品的感受是一件非常困难的事情。   但一个问题是,用户真的知道自己想要什么吗?他们对自己的需求了解到什么程度?   福特汽车创始人 – 亨利福特的一句名言常常被人们作为反面案例引用:“如果听用户的,我们根本造不出汽车来,用户就是需要一匹快马。”苹果已故 CEO Steve Jobs 也有类似的言论。在他们看来,只听从用户反馈的需求,永远无法做出优秀的产品,Digg 的陨落就是一个盲目听从用户反馈的最好反例。这样的观点其实也很容易理解,用户毕竟不是专家,他可能对于某个产品的某个功能有自己的需求和期望,但出于对产品设计细节的不了解,他们的反馈也许并不是该功能的最好实现方式,也不足以作为产品下一步怎么走的直接依据。   产品策划的最根本问题是什么?Axure 中文社区负责人、著名用户体验设计师尹广磊认为,我们不能光谈需求,而应该谈产品的解决方案与用户需求到底有什么关系。用户动机才是在用户需求与解决方案之间建立联系的最有效途径,这也是产品设计人员最重要的任务。就像警察办案一样,有时候看似得到了合理的人证、物证,但还要解释通嫌疑人的犯罪动机,如果犯罪动机解释不通,这个案子可能就不能草草定案。   用户需要一匹快马,我们给他们培养更快的马就行了吗?对于赛马相关行业来说也许如此,但他们这一需求背后的动机是什么?在这个简单的例子里,大多数用户对快马的需求的最根本动机归根到底,只是想要更快的到达目的地而已,而具体通过什么样的工具实现并不重要。在更广泛的产品设计领域,这意味着,我们不该仅仅单纯接受用户的各种功能需求、意见反馈,而应真正从用户的角度出发,去分析其宣称的“需求”背后,到底有什么样的动机。这才可谓真正的“以用户为中心的设计”。回头看看,苹果真的不在乎用户的反馈吗?表面看起来似乎如此,但其之所以被誉以行业创新者的形象,并不仅仅来自于天才的设计灵感,而也在于其从用户的动机、而非从用户直接反馈的需求出发的产品思路。   如何挖掘用户动机   如果用户无法直接反映他们的动机的话,产品开发人员该如何把握他们的反馈呢?MIUI 产品经理许斐认为,虽然用户的动机往往不会直接展现出来,但我们可以依然从他们的行为和反馈中进行推断和验证。   对于 MIUI 来说,用户曾经反映过这样一个问题:是否能够在删除一个应用时,自动用后面的应用图标补上空位。对于这个反馈,该如何处理?最简单的处理方式当然是直接引入这个功能,但这真的是用户想要的吗?   但对于更细致的产品人来说,其首先要做的是分析用户为什么会有这个问题。用户之所以提出这个需求,主要来自于其对于 iOS 系统的使用习惯(在 iOS 上,当用户删除一个应用后,后面的应用图标会自动补上之前的位置,以保持桌面的整齐,而这正是用户所提到的场景),但 Android 上并没有这个特性。对于用户来说,其实际上想要解决的问题是应用图标排列整齐性的问题,他不想在原来的位置留下空隙。   对于实际解决用户的反馈,应在获知用户反馈背后隐藏的动机后进行。对于更方便整理手机桌面的这个动机,用户所要求的 iOS 式方法是否适合直接引入 Android … Continue reading

© 2012 . All rights reserved.

Peter Thiel 谈创业者的产品规划

  PayPal 创始人,Facebook 投资人,对冲基金 Clarium Capital 总裁、风险投资公司 Founder’s Fund 管理合伙人及多家创业公司董事 Peter Thiel 拥有多年成功的创业和投资经验,今年其在斯坦福大学开设了面向创业者的的《创业学》课程,非常值得创业者们学习,本文为其中一段节选。   现今的美国是一个乐观非决定主义主导的国家,人们对未来整体非常看好,但对下一步怎么走的不确定性带来了其存款率、投资率双双低迷的局面。在金融行业,这一特征尤为明显,股票、期货、房地产从根本上来说就是一场随机的游戏,虽然根据不同的投资信息可以提高回报、降低风险,但最终唯一能够确定的是“没有任何事是确定的”。   这一心态同样弥漫到了科技创业领域,由于团队对产品未来的不确定,它们往往具有下面几个特征: 乐于对产品进行达尔文主义的 A/B 测试 小步前进、快速迭代 重视机器学习、数据分析 较少考虑长期规划 重视短期前景   这几个特征本身并没有问题,A/B 测试可以验证哪种方案更优化、快速迭代可以降低长期的失败成本、重视机器学习和数据分析可以提高短期的产品针对性。但一个趋势很明显,在现今的创业者文化中,拥有一个清晰明确的计划往往被大家所忽视,或觉得其不重要。   这是否能够带来真正的成功呢?涅盘重生的苹果公司无疑是这一思维的典型例外。对于苹果来说,每一阶段的精细规划是其成功的关键:手机、平板、笔记本等主要产品线有明显的发展方向,企业策略有清晰的计划,公司有未来几年内明确的发展目标,一切事务都围绕这些目标有计划的推进。   产品规划的价值   乔布斯回到苹果时,其股价为可怜的 3 美元,而到 2003 年,虽然苹果已经拥有很高人气,但金融市场依然不买帐,股价仅仅为 6 美元。之所以有这种现象,是因为固有非决定主义思维的投资者对于历史上的苹果并不看好,无法对其未来建立起确定的积极预期,苹果对自己计划秘而不宣的神秘主义更不会起到任何积极作用。这使得在过去的几年中,苹果的股票一直能够大幅超越人们的预期。   紧随苹果的脚步,像 Airbnb、Pinterest、Dropbox、Path,甚至是 Evernote 这样,拥有良好规划的众多产品相继获得巨大成功。表面上看,它们的成功并不符合数据分析的结果,但这些产品和用户需求之间却仿佛建立了一种独特的心灵感应。优秀的产品规划正是这其中最重要的一环,在这些案例里,这一要素似乎比传统的 A/B 测试、快速迭代更加有效。在当前普遍的非决定主义思潮中,这是否意味着产品规划的重要性终于回归?   规划你的产品   在通常情况下,当一个新创产品获得广泛欢迎后,总会有公司提出收购意向。对自己未来并不确定的产品往往会欣然接受收购,因为其创始的目的主要是获利。一个例子是 … Continue reading

© 2012 . All rights reserved.

店大欺客的Twitter

  Twitter 的成功和其大幅度的开放 API 是密不可分的,凭借这种第三方客户端和工具的多样性使得 Twitter 完成了从小到大的转变,但是,”飞鸟尽,良弓藏;狡兔死,走狗烹“,成功后的 Twitter 已经开始对其开发者下手。   店小迎客的 Twitter   说起 Twitter,除了常年被某墙不待见外, Twitter 比起其他任何服务来说最大的特点就是每个用户都能找到符合自己口味的第三方客户端,几乎可以说“一千个用户的眼中有一千个客户端”。其实这种第三方客户端和工具的多样性在最初并不一定是 Twitter 的本意,受制于初创公司的资源限制,Twitter 当年没有办法添加更多的功能,因此只能向第三方大幅度开放各种 API 接口,让第三方公司和开发者来完成这部分工作,于是才逐渐形成了今天具有百万规模的第三方客户端和服务的 Twitter 生态圈。因此对于 Twitter来说真实情况是“不是我要开放,我只是没办法”。   不管无心插柳也好,还是无力回天也罢,不可否认的是 Twitter 的成功和其大幅度的开放 API 是密不可分的,也正是凭借这种第三方客户端和工具的多样性使得 Twitter 在六年间,从最初只有 50 个用户,仅用于团队和亲朋好友沟通的小玩意,发展到今天 1.4 亿活跃用户、每天 3.4 亿条推文的沟通平台,完成了从一个很 Geek 的玩意向真正 Big Thing 的转变。 … Continue reading

© 2012 . All rights reserved.

互联网项目管理要点

  互联网项目,会定一个计划发布日期,然而这个项目有个隐藏的实际合理发布日期。因为软件开发并不是一个直接添加资源就可以加快速度的过程,所以这个实际合理发布日期是在现实资源合理利用前提下一个客观存在的最可能早的完成时间。项目进展的过程,其实也是发现这个隐藏的合理发布日期的过程。   从管理的角度来讲,当然是尽可能的赶上计划的发布时间,或者尽可能快的完成项目。但是因为多方面因素的影响,项目管理是一个欲速则不达的过程。如果这个计划发布日期早于这个实际合理发布日期,那你越往这个不合理的日期赶,工期内积累的问题就越多导致后期收尾的时候爆发,结果反而可能连合理发布日期都赶不上。借用《让子弹飞》里面的一句话,步子迈得太大了,容易扯着蛋。给项目组定一个个合理的看得见的小目标,步步为营,一步一步朝着看得见的并且合理的每一个小目标前行,每一个小目标的积累,才能最终走向项目的成功。   所以务实的项目经理应该认识到如下几点:   1. 项目组可以以快节奏的步伐在前行,但是项目经理本身一定要清晰的认识到,我们明面上是在赶那个计划发布日期,但是项目组实际的目标应该是那个客观存在的合理发布时间。   2. 随着项目的进行,那个客观存在的合理发布时间会逐渐明朗。它与计划发布时间的差异也逐渐显示出来。此时有些项目经理往往会通过加资源的方法来尝试缩短这个合理发布时间。但是真实的情况是,除非你前期的资源配置不合理,不然在这种情况下加资源,对项目帮助不大。这个地方无须多说,有疑问的人,去看一下《人月神话》就知道了。   3. 项目经理必须有一些坚持。领导或者业务部门经常会有一些压力下来,要求赶那个计划发布时间,同时要求你想尽任何办法去赶上这个计划发布时间。而现实状况下,如果你能够调整一些需求的范围,你还是有戏。不然,你要嘛此时报喜,后期报忧,要嘛此时报忧,后期不忧。掩盖问题往往可以让人开心,但是不代表问题不存在。   4. 项目经理能做好的其实就5点:    a. 控制好了需求;    b. 及早的发现问题,报告出来并解决;    c. 不出现资源空闲的状态;    d. 利用好每个资源去做擅长的事,快速有效的推进各种任务;    e. 不浪费资源去做一些对项目目标总体没有帮助的工作,或者一些后期会推翻的需求。   基于这样的认识下,本文有如下几个要点:   #项目责任感   项目经理应该有这个的责任感,你要为这个项目的任何一件事情负责,因为这个事情会影响到整个项目的工期,而你为整个工期负责。   一个例子,我发现现在的项目有一个紧急的问题需要项目组外的人帮忙解决。于是我把邮件发出去,通知Wendy赶紧处理这件事情。   几天过去了,Wendy还没有处理。我想,我已经把问题说出去了,接下去就是Wendy的事情。   那个问题还是没有解决,我的整个工期受影响了。   事后追究起来,我说,我已经发出邮件了,是Wendy没有及时处理。   Wendy说,我事情那么多,我怎么知道这件事情这么急。   项目工期受影响了,谁的责任?Wendy吗?不,是我自己。   作为一个对整个项目负责的项目经理,没有人会比你更在意项目的进展。让一个不负具体负责的人去帮你推进你的项目,远远不如你自己用心推进来得有效。   #项目经理是打杂的   项目组里面的每个专业成员,他们都有擅长的领域,做他们擅长的事情是他们的快乐。而不属于他们擅长的事情,对他们来说就算是杂事一般。   项目经理一定要有一个这样的意识:   项目经理就是打杂的,帮助项目组成员把杂事处理掉,让他们可以专心的做他们擅长的事情,这样对项目组来说才是高效的。   一个简单的例子,测试人员Tracy在测试某个功能的时候,突然发现她需要一个账号,同时开通这个账号的某些特定的权限,同时她需要一些服务器的信息,比如主机名,某些功能文件夹存放的路径。但是她不清楚这个账号和权限要找谁开通,这些服务器的信息谁有。   Tracy是个喜欢做测试的人,但是她不喜欢跟项目组外的人沟通,特别是还要到其他部门去找人问人。这些对她来说就是杂事,而且她对其他部门的人也不熟,一个一个问明显效率不高。   你可以自己去帮她找到需要的信息,也可以找一个对这方面比较熟的人去解决,但是你绝对不能让她自己去做。   “为什么我的手下不能解决这么简单的问题?如果连这种事情都要我来帮忙的话,那我这个项目经理做来干什么?她当项目经理得了。“这种想法千万是不可取的。   你当这个项目经理的目的并不是管人,指使这人做什么那人做什么。你的目标只是把项目快速推进完成。 … Continue reading

© 2012 . All rights reserved.

也谈凯文.凯利的六点趋势

  近日,《连线》(Wired)的创始主编凯文·凯利(Kevin Kelly)在东西论坛上表示,科技未来将有六个发展趋势,分别为:屏幕化、互动性、分享性、流动性、实时获取和生成性。凯文·凯利表示,这些趋势并不一定在未来一两年内能够达成,但是未来一定会实现。   笔者对未来将会有怎样的趋势,在了解推理过程之前,并不感冒。满屏都是Kevin Kelly(以下简称KK)的六趋势也是一看而过,直到视频出现,想看看他具体是怎么说的,看过之后有了很多的感触,就有了下面的这些文字。   屏幕化,应该是被KK简化掉了的概念。从文字上获取信息是我们与他人沟通的重要方式。文字的载体有甲骨文、竹简、纸张、屏幕,技术上的支持,信息的载体在进步,现在到了从屏幕获取信息的阶段。屏幕是电脑计算结果显示的窗口,所以你不用对出现在屏幕上信息感到惊奇,无论哪种不可思议的信息,其背后都有强大的计算机在支持,而互联网的发展,计算机之间的相互联系,只会让屏幕显示更加让人不可思议的信息。除了屏幕外,计算机展示计算结果的方式还有很多,声音,光、投影、信号、机器等等。   屏幕是我们与计算机沟通的窗口,这就引出互动的概念。我们用刀刻甲骨文和竹简,用毛笔写字,到用键盘敲打文字,到用手势操作屏幕,互动的方式被信息的载体约束。我们知道计算机除了屏幕外还可以通过其他方式展示结果,可以将计算结果投影在物理实体上,比如将一个苹果的产地,重量,卡路里,甜度,新鲜度将这些数据投影在苹果上,你拿苹果吃一口,投影上的数据马上变化更改,吃苹果的动作就成为人机交互的方式。互动的方式有很多,RFID,NFC等,这取决于信息载体。KK太过注重技术,认为我们反馈给计算机,计算机也从我们的行为中获取信息,是双向互动的,双面镜。但是我们是人与人间的沟通,计算机是沟通中的一个工具,一个可以变声的传声筒,使用计算机的何种计算结果是由操作的人决定,我吃了一个苹果,我从计算机看到我摄取了多少卡路里,儿子则从视频中看到老爸偷吃了他的苹果。网站的使用者和设计者对于数据的考察角度不同,互动方式也不同,在屏幕上的行为也不一样。   分享,是KK导入数据流概念的引子,并试图用分享来解释数据流,但分享是个伪概念,对数据流的解释力很有限,而且还给自己惹来麻烦。所有东西都可以分享,也就是所有的东西都要被输入到计算机上,进行分享,这个是针对互联网社会化来说的,每个网民都生产信息上传互联网,这些东西才有可能在网上被分享。在facebook,twitter等发展之前,互联网同样拥有海量的信息,也到上传到网上进行分享,但互联网的发展态势与现在截然不同,这是什么原因,KK没有进一步的解释。所有东西都可以分享,创造众多信息,足够多的信息是数据流形成的前提条件。这里KK谈到的例子,数据化自我,其产生有时间维度和自我两条线索,数据化自我产生大量的数据,这是数据流形成的前提条件,如何形成数据流,桥梁就是分享创造价值,分享这些数据,数据从私人转化为在网络上的数据(限与传播与接收者间的网络),数据获得价值,这些就成为一条数据流。   KK谈到隐私的问题,是分享概念的延伸。你要分享哪些信息,要在哪些范围分享,构成隐私问题的一部分。有人不惜造绯闻,拍私密照以图出名,有人用网名上网,从不透漏真实信息,这些都是个人判断,很难说有个标准。隐私问题除了个人还有网站方面的问题,网站将网民的行为数据肆意使用,进行分析并作为谋利的工具。这是对网民隐私的侵犯。   对称问题是KK对分享概念的自圆其说。分享是相互分享,一方分享多,一方分享少,就形成了不对称,同时分享创造价值,你多分享吧,让他们多了解你,这样你就可以从中获益,于是你分享更多的信息,他们更了解你了,于是就形成了对称。这是KK的逻辑,但真实情况更应该是这样的,若存在大量的非对称,也就是说分享数据的网民,和使用数据的网民数量不对称,分享的多,后果没这么严重,但分享的少,使用的人多,贫瘠的数据量是当前互联网发展的描述吗?   分享是个伪概念,分享是创造和传播,不解释。   流,是对一串关联数据的描述,互联网上的数据可以通过某种共同线索相联系的数据,都可以称为数据流。数据化自我是时间和自我两条线索,网站流,地点流,事件流等等,所有的东西都可以分享,所有的数据都可以成为数据流。所有的数据流都有时间这条线索,不知道为何要如此强调实时特征,时间线索比实时更重要和创新的空间。   平台的导入很唐突,数据流间为何会相交,相交时是随时间流上的一个时间点,还是一个事件一段时间内呢,数据流无所不在,分散在各处的数据流为何可以汇集在一起,平台有何种吸引力能够导入数据流,还是说先有平台,再有数据流?小溪流一样的数据流,流到了一起,就成为了新媒体,成为了平台,跟小溪小河汇集在一起就成了大海,这样的逻辑是有问题的。水汇集的地方称为大海,这是果,原因在于大海地势最低,他拥有汇集小溪小河从高到低流动的河床网络,凭借这个网络,大海能够汇集分散在各处的水,集中在一起成为大海。数据流是无所不在的,他们汇集到平台上是果,那么因是什么,KK没有答案。   所有权和使用权,这个没什么好谈的。所有的东西都信息化,信息的可复制性,让信息的使用价值与所有权相分离,这也是为后面的信息价值兑现方式作铺垫。   互联网的信息如何兑现价值,试图通过所有权来控制使用权是很难行的通了,于是就从获取使用权入手。信息使用权获取方式有容易或困难,如何发挥信息的价值有方法(比如对KK的解读),信息的传播渠道有价值,信息的版权问题。互联网上的行为主体是网民,网民的个人品牌是有价值的,一个信息无法兑现价值,但可以通过相关联的信息兑现,比如一张图价值无法兑现,但可以通过图内的衣服购买链接来兑现,网民可以通过生产补充信息系统完整性的信息,来兑现价值。   没看过KK的作品,只在前几天看过他在TED上的一个演讲,怕会误解其意思,所以每点都重看很多遍,但误解应该是不可避免的,尽管如此,我想主要的点应该偏差也不会太大,总体来说,对于关键点,共享也是他自己觉得最重要的,与其理解有较大的偏差,且有些点没说全,个人感觉这个视频是差强人意的。   来源:sbumblebee投稿,原文链接。   参考新闻:凯文-凯利:未来科技发展六趋势 凯文-凯利(KK)   《连线》(Wired)的创始主编凯文-凯利(Kevin Kelly)近日在东西论坛上表示,科技未来将有六个发展趋势,分别为:屏幕化、互动性、分享性、流动性、实时获取和生成性。   以下为六个趋势的详解:   第一、屏幕化。凯文-凯利表示,未来屏幕将无处不在,充斥人们的生活,未来任何一个平面都有可能变成屏幕。谷歌的新产品(谷歌眼镜)正致力于把屏幕带到任何地方。   未来的现实生活中将有很大一部分都属于数字世界,包括手机、甚至衣服和鞋子都将有数字化植入。目前在数字世界中,人们传播事实的方式已有所变化,这会改变我们对自己,事实与人的看法。   第二、互动性。凯文-凯利表示互动等于生命力。互动越来越强调在形体上变化,越来越符合人类的逻辑。手指操作只是很有限的方法,未来讲话和身体任何部分发出指令都将可以进行控制。同时,屏幕将能够进行眼神捕捉,屏幕将看着我们就像我们看屏幕一样,屏幕可以了解人的想法,并和人产生互动,这是书本做不到的。   第三、分享性。分享的途径为云计算。凯文-凯利表示云并不在远处,我就生活在云中。互联网络越大,云的影响力越大,人们会成为定量化的自我,任何信息都可以被分享,都将被分享,所有的数据流、档案都可以进行分享。目前我们分享程度较低,很多社会还存在审查的问题,我们能再分享路上走多远需拭目以待。   第四、流动性。文件夹和页面将转移到流,流最重要的特点就是“实时性”,如果不是实时的,就不能称为一个流。   目前,微博,Facebook等各种社交网络流都在实时更新,数据都在以流的方式进行流动,我们在完成“数据是一切”的现实。   第五、实时获取。未来我们强调的不是拥有,而只是获取与接入。目前已有很多用户上网并不是买,而只是订购,包括电影、音乐和书,再由电商会分流给原创作者。虽然我们现在有更快的交付行为,但是远不及实时获取快捷。   第六、生成性。当前出现很多副本,复制速度越来越快,在这样能够生成的世界下不能复制的东西是最珍贵的,例如及时性、个性化、原版、无形的培训正成为人们乐于支付的对象。无形价值更为重要。 评论《也谈凯文.凯利的六点趋势》的内容… 找不到相关文章,请发表留言 微博:新浪微博 – 腾讯微博 – 论坛 月光博客投稿信箱:williamlong.info(at)gmail.comCreated by William Long … Continue reading

© 2012 . All rights reserved.

移动互联网真的进入了“拼爹”时代吗?

  年前有专家预测说移动互联网获得用户的成本将大大增加“获取成本远大于PC产品的成本”,“移动互联网进入“拼爹”时代,新用户获取成本将翻倍飙升,没背景没资源的草根创业基本没机会”,这让众多看好移动互联网机会的创业公司和从业者感到畏惧。难道移动互联网的秩序还是PC固定互联网时代的秩序吗?   当时笔者就对“移动互联网用户获取成本远大于PC产品的成本”提出了异议,但没有展开说出自己的论据。现在把笔者的依据罗列一下,希望能够鼓励到正在移动互联网领域奋斗的PM们!   一、移动终端会比PC多很多倍,这是显而易见的,目前尤其处在智能移动终端用户量的快速增长期;   二、移动终端开机时间长,给企业发展新用户提供了更多时间窗口,也为用户使用服务提供了更多时间窗口(比如在界面上向用户展示广告的机会大大增加了);   三、位置信息以及移动终端私隐性等特点带来固定互联网不具备的众多新业务类型;   四、移动终端作为人类服务易得性很强的工具,会让固定互联网上的一些原有业务使用频率大大增加,产生质变, 比如VOIP和IM服务,成为移动VOIP和移动IM之后,用户使用频率将大增,这方面的趋势可能会吃掉全球电信运营商的很大一块业务,最终可能使“基础电信业务沦为一种互联网增值服务”   五、在移动终端是人的工具的同时,人也成为移动终端的工具,即人成为移动终端的智能外设或者说是智能接口, 把外界的人、事、物转换为移动终端可以识别的数据输入到移动终端,通过人这个智能外设,终端和无处不在的人物和事件发生交互,并进行必要的处理,由此,移 动终端可能会对人类的生活方式产生重大影响,尤其是过去看来是线下的人事物,也能被移动互联网来进行处理了——这个意义非常重大。   六、移动终端功能配备更加标准化,为移动互联网业务普适于终端创造了更好的条件,比如移动IM的voice message功能,在智能移动终端的audio标配下,更加容易开展(pc客户端开展voice message业务,就存在某些PC没有麦克风,甚至没有音箱而无法使用的问题)。   移动互联网业务丰富,潜在用户量巨大,只要业务适合,用户获得成本会非常低。移动互联网业务大有可为!   要提醒PM们的一句话是:移动互联网业务比固定互联网业务更容易发展用户,而不是更难,除非是你不顾移动终端的优势特点,仍以固定互联网的思路来设计产品   以上浅见,与业者共勉!   来源:投稿,作者:同淮,作者微博。 评论《移动互联网真的进入了“拼爹”时代吗?》的内容… 找不到相关文章,请发表留言 微博:新浪微博 – 腾讯微博 – 论坛 月光博客投稿信箱:williamlong.info(at)gmail.comCreated by William Long www.williamlong.info from 月光博客 http://www.williamlong.info/archives/3079.html ways to hosting server a the fashion industry … Continue reading