分类目录
-
近期文章
其他
我的朋友
推荐站点
经典朋友
功能
分类目录归档：理论
HTML5设计原理[转]
转自：http://www.cn-cuckoo.com/2010/10/21/the-design-of-html5-2151.html Jeremy Keith在 Fronteers 2010 上的主题演讲 下载PPT（PDF） 观看视频 今天我想跟大家谈一谈HTML5的设计。主要分两个方面：一方面，当然了，就是HTML5。我可以站在这儿只讲HTML5，但我并不打算这样做，因为如果你想了解HTML5的话，你可以Google，可以看书，甚至可以看规范。 实际上，确实有人会谈到规范的内容。史蒂夫·福克纳（Steve Faulkner）会讲HTML5与可访问性。而保罗·艾里什（Paul Irish）则会讲HTML5提供的各种API。因此，我今天站在这里，不会光讲一讲HTML5就算完事了。 说老实话，在正式开始之前，我想先交待清楚我所说的HTML5到底是什么意思。这话听起来有点搞笑：这会子你一直在说HTML5，难道我们还不知道什么是HTML5吗？大家知道，有一个规范，它的名字叫HTML5。我所说的HTML5，指的就是这个规范。但问题是，有些人所说的HTML5，指的不仅仅是这个规范，还有别的意思。比如说，用HTML5来代指CSS3就是一种常见的叫法。我可不是这样的。我所说的HTML5，不包含CSS3，就是HTML5。 类似的术语问题以前也有过。Ajax本来是一种含义明确的技术，但过了不久，它的含义就变成了“用JavaScript来做一切好玩的东西”。这就是Ajax，对不对？今天，HTML5也面临同样的问题，它本来指的是一个特定的规范，但如今含义却成了“在Web上做一切好玩的事。”我说的不是这种HTML5，不是这种涵盖了最近刚刚出现的各种新东东的HTML5。我说的仅仅是规范本身：HTML5。 刚才已经说了，我今天想要讲的内容不多，也没有打算介绍HTML5都包含什么。今天我要讲的是它的另一方面，即HTML5的设计。换句话说，我要讲的不是规范里都包含什么，而是规范里为什么会包含它们，以及在设计这个规范的时候，设计者们是怎么看待这些东西的。 设计原理 设计原理本质上是一种信念、一种想法、一个概念，是你行动的支柱。不管你是制定规范，还是制造一种有形的物品，或者编写软件，甚至发明编程语言。你都能找到背后的一个或者多个设计原理，多人协作的任何成果都是例证。不仅仅Web开发领域是这样。纵观人类历史，像国家和社会这样大规模的构建活动背后，同样也有设计原理。 就拿美国为例吧，美国的设计原理都写在了《独立宣言》中了。 我们认为这些真理是不言而喻的，人人生而平等，造物主赋予了每个人不可剥夺的权利，包括生存、自由和追求幸福。 这里有一句口号：生存、自由和追求幸福。这是被写进宪法中的核心理念，它关系到我们所有人的一切，也就是我们构建自己社会的原则。 还有一个例子，就是卡尔·马克思（Karl Marx），他的著作在20世纪曾被奉为建设社会主义的圭臬。其基本思想大致可以归结为下面这条设计原理： 各尽所能，各取所需。 这其实就是一种经济体系背后的设计原理。 还有一个例子，比前面两个的历史更久远一些，不过大同小异： 人人为我，我为人人。 这个极为简单的设计原理，是两千年前的拿撒勒犹太人耶稣基督提出来的。而这条原则成为了后来许多宗教的核心教义。原理与实践有时候并不是同步的。 下面是小说中的一个例子。英国小说家乔治·奥威尔（George Orwell）笔下的《动物庄园》，就是在一条设计原理的基础上构建起来的虚拟社会。这条设计原理是： 四条腿的都是好人，两条腿的都是坏蛋！ 《动物庄园》中有意思的是，随着社会的变迁——变得越来越坏，这条设计原理也跟着发生了改变，变成了“四条腿的都是好人，两条腿的就更好了。”最关键的是，即使是在虚构的作品里，设计原理都是存在的。 还有一套虚构的作品是以三条设计原理为基础构建起来的，那就是美国著名小说家艾萨克·阿西莫夫（Issac Asimov）的机器人经典系列。阿西莫夫发明了机器人学这个术语，并提出了机器人学三大法则，然后在这三个简单的设计原理基础上创作了一系列经典作品——大约有50本书。无论作品的情节如何变化，实际上都是从不同的角度来阐释这三大设计原理。我想，在座各位对机器人三大法则都不应该陌生。 机器人不得伤害人类，或袖手旁观人类受伤害。 机器人必须服从人类命令，除非命令违反第一法则。 机器人必须自卫，只要不违背第一和第二法则。 这些恐怕是第一次出现在小说中的针对软件的设计原理了。虽然基于这三个设计原理的软件运行在虚构的机器人的“正电子脑”中，但我想这应该是软件设计原理的事实开端。从此以后，我们才看到大量优秀软件背后的设计原理。 蒂姆·伯纳斯-李（Tim Berners-Lee），Web的发明者，在W3C的网站上发表过一份文档，其中有一个URL给出了他自己的一套设计原理。这些设计原理并不那么容易理解，不仅多，而且随着时时间推移，他还会不断补充、修改和删除。不过我还是觉得把自己认同的设计原理写出来放在某个地方真是个不错的主意。 实际上，CSS的发明人之一伯特·波斯（Bert … 继续阅读
开放平台，你忽悠得了谁？
转自：http://blog.appleap.com/?p=29 2008年被誉为中国互联网界的开放年。这一年中，校内、51、聚友、康盛创想、中国雅虎 等，都跟随facebook的脚步，各自推出独立的开放平台体系；谷歌也在积极推广自己的开放标准，天涯、一起网、MySpace都搭上了 OpenSocial的大篷车，国内也出现了一大批应用开发者和奇矩互动、热酷、Apptz等专业的应用开发公司。 但是，在繁荣的表象背后，有一些现象却值得我们关注：facebook自从2007年7月推出f8开放平台以来，到今年7月24日的f8大会，共吸 引了大约40 万开发人员为其创建了大约2.4万个应用程序，并且这个数字还在飞速增长之中。在中国，以最早推出开放平台的校内网为例，在将近半年的时间中，共吸引了 650名开发者为其创建了852个应用程序（数字来源于AppLeap.com）， 并且最近两个月的时间内应用数量增长缓慢。在美国，一些优秀的应用开发公司能够获得风投的青睐，而中等规模的应用开发者可以靠广告收入养活自己，而在国 内，应用开发者在享受了作品上线后，用户快速增长所带来的短暂狂欢之后，要开始面对昂贵的运营成本，以及缺乏有效营收手段的现实。校内、51开放平台的用 户条款不仅限制多多，而且朝令夕改，让许多应用开发者都感到无所适从，缺乏长期的安全感。最近两个月以来，随着经济形势日益严酷，开放平台似乎也步入了寒 冬的季节。 开放，忽悠了谁，又成就了谁？到底是什么原因导致开放平台没有像预期的那样成为开发者的盛宴？ 来自平台方面的原因 今年7月8日，校内网举办新闻发布会，高调宣布开放平台的推出。在开始的一段时间中，新应用像潮水般涌入，校内网宣称每天提交审核的应用就有200 多个。但是，校内网出台的关于第三方应用程序开发与管理的协议，成了开发者口诛笔伐的焦点。在这份协议的第一版中，规定了第三方应用不得嵌入广告，不能引 导注册其他网站和包含跳出外站的链接，不能涉及招聘和旅游等与校内未来扩展方向相关的领域，甚至还规定了应用的产权也归校内拥有。虽然后来校内网对协议进 行了大规模的修订，去掉了一些明显不合理的条款，但从这件事情上，可以看出国内的平台经营者从一开始并没有完全摆正自己的心态。 从技术角度，对比facebook f8，可以看出国内开放平台在技术细节上的简陋。facebook一直在不断完善技术框架，提供更丰富的标记语言（FBML）和开放更多的API，努力给 应用更多发挥的空间及更紧密的嵌入体验。反观国内，开放技术标准的更新速度缓慢，校内最近一个XNML标签的添加还是在9月14日。举一个小小的例 子，facebook允许iframe型的应用通过代理的形式控制父窗口的尺寸，从而达到与父页面无缝整合的目的，这一点功能，国内任何一个平台目前都没 有提供。facebook提供的开放API共有69个，比51和校内加起来的两倍还要多。或许他们认为这些细节无足轻重，但态度的缺失使细节积少成多，用 户体验的差距就慢慢显露了出来。 来自应用方面的原因 校内开放平台的推出，让无数开发者的热情被点燃，他们的创意和激情终于找到了释放的出口，第一批应用的创意大多取自facebook，还有一些是通 过hack flash源码来实现的。国内应用开发者中有很多是刚刚毕业或在校的大学生，应用上线后用户快速增长所带来的新鲜感过后，就会因为运营压力的增大和收入手 段的匮乏而导致热情迅速冷却，一些应用经常出现无法访问的现象，这在一定程度上影响了校内网的整体用户体验。平台和应用在开放生态链当中本来是共生的关系，伤害了对方，最终也一定会影响到自己。 另一方面，对于国内的应用开发者来说，在当前比较恶劣的经济环境之，像rockyou和slide那样获得风险投资非常困难，实现收入的最重要手段 只能是广告。在广告市场相对比较成熟的美国，基于社交网络的广告联盟有很多，广告客户对于新媒体的尝试热情比较高；而在中国，社交网络对广告主的吸引力还 不足以支撑起一个商业模式，应用只能依靠嵌入adsense广告来赚钱，这种低效的方式远远不能将社交媒体的商业价值最大化，也很难养活得了专业的应用开 发团队。很多开发者把应用开发看成是掘金的手段，缺乏长期运营产品的心态，希望能以最快的速度推广和获取收入，这也导致应用开发的导向过于娱乐化，复制成 本很低且不具有不可替代性。高质量应用的缺失使应用开发者相对平台的整体议价能力非常弱。 中国SNS发展的客观环境 facebook和myspace是美国乃至世界上最主流的两家社交网站，在上网人群中的到达率非常高。在中国，SNS的竞争模式演变成了“群殴 ”，校内网、51、开心网等各占据一个细分市场，但任何一家都还不具备像facebook那样庞大的用户基数和强势的影响力。留给应用开发者的施展舞台本 身就不够广阔，再加上各平台之间对用户群的激烈争夺和相互渗透，使他们没有足够的精力持续投入到开放平台的建设中去。 理想中的平台和应用关系 平台和应用之间，不应该是老板和打工者的关系，而应该是在开放的环境中共同生存和利益共享的关系。作为平台，应该注重于建立和维护良好的开放生态环 … 继续阅读
产品和技术的矛盾，大家是如何解决的？
以下是前一段时间，在UCD讨论组上面，和一些朋友进行的讨论。 现在整理出来和大家分享一下。 ——————————————————————– 无影说： 程序员总是想尽量精简或者是按照自己的程序编写方便来完成一些功能，有时候就是，为了完成功能，并没有考虑到产品设计上，未来可能会发生的变化，等到变 化来临时，又找出借口来说，这个功能会影响XXX，无法做，或者很难做，以此来刁难。 做产品的时候，总是想一开始就做一个大而全的东西，别人有的我要有，别人没有的我也要有，总是先模仿同类的其他网站，这样很难有自己的特色。 程序员做的不是自己想做的，所以他们总是消极怠工，或者是代码考虑不周全，留下了未来的一大堆隐患，或者是本来可以很快完成的任务，他说是很复杂，这个 需要做很久，以此来表达自己的不满和抱怨，反正我又没打算一直干下去。 如果是程序员自己给自己写程序，就不会这样，开发速度很快，考虑也很细致，倾尽自己所能，以表现自己的技术高超。 或许是技术团队，没有一个顶尖的leader来领导程序员？ 或许是没有一个优秀的产品经理来让程序员信服？ 还是有其他一些矛盾？ 好像每个公司，都有一些和程序员的矛盾，这个如何能尽量避免呢？ moneya说： 我想可以让部分关键程序员前期介入，参与产品需求分析和设计。这样的设计也兼顾了 很多实际的条件，更有实现的可能性。程序员的参与度高，对需求的理解也到位些，责 任感、成就感也强吧。 liyi2008说： 是有这样的问题，我们现在的做法是，产品设计阶段就让技术人员参与，然后经过多次和技术人员讨论形成最终的开发文档，技术人员根据开发文档制定开发计划，这样的好处是不会让技术人员觉得产品与我无关，没有体现我的价值，其实技术的前期参与也可以提出很多建设性的建议。 另外，对于不同类型的程序员需要不同的对待，有些程序员在产品开发过程中有非常多的建议和想法，对产品的控制欲望很强，这样的程序员需要我们投入更多的耐心，和他探讨问题，这样的程序员一旦你和他达成一致，他们的开发和合作会非常好。我个人比较喜欢和这样的程序员沟通。还有写程序员非常严格按照你的产品文档开发，对产品本身没有太多的想法，这样就需要我们把文档写的尽量详细，因为如果有考虑不周全的地方，他们也会按文档开发。 总之，遇到这样的问题还是多找自身的问题，充分调动大家的积极性把产品做好才算一个合格的产品经理 张锐说： 同意。做好一个产品不能仅仅是产品经理的事情，产品经理最重要的一个功能就是调度起跟产品有关的人的积极性，让所有人都发挥其最大的力量。所以，我觉得“控制”对产品经理来说至关重要。 设计的前期我觉得要经常和技术人员沟通，可以让一些对设计有兴趣有想法的开发人员加入进来，他们可以从技术可行性上给予帮助。不过有个问题就是，技术人员也许不懂UCD，而且他们经常是从程序的角度去思考和设计产品，这个时候就需要我们去把握和掌控产品设计。 有些程序员对产品设计可以说丝毫兴趣没有，他们只管自己的代码是否漂亮，这些程序员最怕的就是你开发过程中变更需求，这就要求我们前期需求明确，指定完善的开发文档，深入到产品的各个细节。 wangjuea说： 顶一下liyi2008，对于不同的研发，是要有不同的协调方法。 我还有一个个人的小经验，就是不仅要和研发的同学协调好，更应该先和测试的同学搞好关系。在我的工作圈子里，我了解到大多数研发对于产品消极的处理都是与测试team的考核有直接关系。 所以，我平时会和测试、研发同学经常一起沟通，最大的目的就是期望大家在遇到问题的时候首先能一起了解问题，而不是互相推卸责任。 当然，在这个过程中PM要把握测试的纬度和实现的程度。 无影说： 产品、设计、前端工程师、程序员相互之间责任的推卸是一个很严重的问题，随着分工的越细，这种矛盾有些时候就越明显，但是不分工又没有办法达到相对的专业化。身兼多职的人，就会有所抱怨。 和产品打交道最直接的不知道是不是设计师？ 产品 -> 设计师 -> 前端工程师 -> … 继续阅读
转载 – PHP编程规范
一直以来我都是以php函数的风格来写php，所有变量，函数，类都使用小写，单词之间以下划线隔开，一直比较排斥驼峰式的代码规范，个人觉得在大小写字母之间的书写代码，很麻烦，而且PHP自己的函数都是小写，为什么我不用这种格式呢？ 良好的代码书写习惯 + 良好的注释习惯 + PhpDocumentor = 程序说明书 一个团队，必须有整齐的代码书写习惯，如果再配上统一的IDE开发环境，详细的任务编码流程，完善的代码测试（如：SimpleTest），那么整个团队的开发效率将会有很大的提高。 如果你的IDE是Eclipse，那么你可以很方便的进行代码测试，使用SimpleTest参考http://www.guogoul.com/2008/05/19/simpletest_1/
写好代码注释，生成代码说明文档，PhpDocumentor
如何使用PhpDocumentor，参考这篇文章就可以了 http://pkwbim-programming-note.blogspot.com/2008/01/phpdocumentor-0.html 不过，我还是在安装使用的时候，遇到了一点问题。 运行->cmd 进入 php所在目录 d:\php\ 执行go-pear.bat system|local 输入local，然后根据提示，一步一步来，输入yes，然后就是一路“回车” 这样pear就安装好了 之后，就是安装PhpDocumentor了， >pear help (查看pear的命令帮助) >pear help install (查看 install命令的用法) 使用pear来安装，也可以直接下载 http://downloads.sourceforge.net/phpdocu/PhpDocumentor-1.4.2.zip?modtime=1206909537&big_mirror=0 >pear install -o phpdocumentor (安装phpdocumentor) 安装完毕后，进入 D:\php5\PEAR\PhpDocumentor >phpdoc –parseprivate -o HTML:Smarty:PHP -f E:\web\db.php -t E:\web\doc -f参数，指定db.php文件，生成文档 >phpdoc –parseprivate … 继续阅读
关于热门文章的算法
搜索了一下，发现相关的讨论比较少。 这是我找到的几篇文章 http://www.i170.com/Article/1001 http://canque.rssidea.com/popular_article_sort/ 一篇文章一般具有一下属性：评论数C、支持数（顶）D、点击数V、发表了多少天T 假设一个评论5分、一个支持3分、一个点击1分；随着时间的延长，文章的重要程度应该降低。 而且时间也应该有一个范围，比如是100天，超过100天的文章就不用再计算了，即使再热门，也应该忽略了。 最后一篇文章得分：(5C+3D+1V)/T 这个值比较大的，就说明文章比较热门。 这是我的一些想法，希望朋友们指正。