[译]3D为互联网准备好了么?

原文:Is 3D Finally Ready for the Web? 作者:Sixto Ortiz Jr. 来源:Computer archive, Volume 43, Issue 1 (January 2010) table of contents, Pages: 14-16, 2010 Introduction 介绍 最初的互联网是以一个简陋的鼠标点击环境开始的,但如今,互联网上已经到处是各种眼花缭乱的页面,充满着各种丰富的应用程序,有的用来娱乐,有的用来提高生产率,等等等等。用户可以在互联网上完成各式各样的任务,不管是购买商品,还是与全世界的用户实时交互。然而,一个关键的元素却迟迟没有在互联网上打上自己的烙印——3D。 在今天,3D的在线应用主要是游戏和虚拟世界,这些都需要强大的电脑和特殊的软件来支撑。然而,商业,工程企业和其他一些用户同样也需要3D,他们同样也需要3D所带来的真实感和更多细节。用户希望他们能够在浏览器中获得和在PC中一样的体验。并且由于3D技术在电影、游戏和其他各种娱乐行业中的广泛应用,消费者已经对它习以为常。因此,对于互联网上更多且更易于访问的3D内容的需求变得越来越强烈。况且更好的浏览器体验同时也意味着更多潜在的收入。 然而,互联网3D还处于一种很不成熟的状态,因为很难在典型的PC和浏览器上广泛使用这种复杂的技术。事实上,一般浏览器也无法承载复杂的3D内容,更无法提供高帧率或全屏的图形效果。并且,在实时的合作程序和其他应用程序中包含3D让本来已经很繁琐的开发过程会变得更加复杂。 尽管如此,现在是有一些组织在为网络3D技术而努力工作的。他们尝试将浏览器转为一种更为强大的计算平台,以在该平台上获得如PC上一样的体验,例如3D内容的展示。这些工作将会为网络衍生出更多的应用程序,包括产品建模,展示和配置;3D在线会议和工人协作;对于手术或机械过程的模拟;虚拟旅游;增强现实等等。 不管怎样,在互联网3D技术变得可依赖和成为主流之前,仍然有重重的困难需要克服。 3D on the web 网络上的3D 早期的网络是没有图形界面的,直到NCSA(美国国家超计算应用程序中心)在1993年发布了Mosaic,这是首个可以同时展示图片和文字的浏览器。 当前在互联网上,已经有一些为3D服务的技术在使用,他们基本使用同样的方式工作,但是使用不同的文件格式。 VRML和X3D 网络3D开始于1994年,在这一年,VRML组织发布了虚拟现实标记语言(Virtual Reality Markup Language)。然而,VRML从未流行过,因为它限制开发者只可以写3D相关的内容。为了创建完整的引人注目的应用程序,开发者必须能够同时开发3D,2D,视频和音频。在处理器和软件能够支持图形之前,VRML表现还是不错的,因为它能支持图形。但是VRML太慢,并且没有能力渲染复杂高仿真的模型和场景。 在1997年,Web3D联盟推出了X3D,它是一种基于XML的文件格式,同时也是VRML的扩展,以用来表现3D图形。X3D同样也没有流行过。游戏和3D开发人员广泛忽视了X3D,X3D只被极少数的商业工具所支持。 其他方法 3D工业论坛于2003年推出的Universal 3D技术,是一种压缩的3D图形文件格式。然而,它的推崇者也只是推动Universal 3D使其成为了一种主要使用在制造业或建筑业相关应用程序的文件格式。 开源的网络3D标记语言(3DMLW,3D Markup Language for Web)是一种基于XML的文件格式,它用于创建网络上的3D和2D内容。3DMLW由3D Technologies R&D于2009年推出,它可以通过插件工作在大多数流行的浏览器中。 [...]

[译] Top 5 Ways to Make Your Site More Fun | 五大法宝让你的网站/产品更具趣味性

又翻译了一篇关于SNS的文章:-) 原地址:http://mashable.com/2010/04/07/funware-game-mechanics/ 原作者:Gabe Zichermann是《游戏式营销》(Wiley出版社,已出版)和《趣味件(Funware)实战》(Manning出版社,预计2010年第三季度出版)的作者。同时他也是新兴的专业移动社区网络公司beamME的CEO,我们可以在funwareblog.com上看到很多他关于游戏和世界的想法的文章。 翻译:阿木 amourguo(at)gmail.com Just like sex, fun sells. The early proof of that can be seen in the amazing success of location-based networks such as Gowalla(), MyTown and Foursquare(), and in the breakthrough marketing efforts of major brands like Nike, Coke and Chase. Even finance made fun can be a winner — [...]

[译] Saying Yes to NoSQL | 拥抱NoSQL数据库

原地址:http://about.digg.com/node/564 原作者:John Quinn Digg, Twitter 翻译:阿木 amourguo(at)gmail.com The last six months have been exciting for Digg’s engineering team. We’re working on a soup-to-nuts rewrite. Not only are we rewriting all our application code, but we’re also rolling out a new client and server architecture. And if that doesn’t sound like a big enough challenge, we’re [...]

[译] Google的C++风格参考指南(一)──头文件

译者的话: 在一个开发团队中,很重要的一点是要遵循一个统一的风格,这样才能便于相互之间在代码上进行快速的交流和理解。反之,如果团队中的每个人只是按照自 己的个性去写属于个人风格的代码,这必然会造成项目代码的五花八门,互相之间难以沟通,整个项目的代码质量低下,BUG率攀高,软件的可维护率也极差。长 此以往,国将不国,团队将不团队,最终软件极有可能以一种极其混乱的状态收尾,这真是一个悲剧。 每一个C++程序员都有自己的编程风格,虽然大家的风格迥异,但也一定有一些共通的地方。我希望能找到一个对于C++风格的归纳和总结,这样在以后 我的工作中,对我自己,甚至对我工作的团队,当然也对于正在阅读的你,能够有一个帮助和参考。所以,我决定翻译Google的这篇C++风格参考指南。当 然,真正促使我去翻译这篇文章的原因是,我是一个C++技术和简洁代码风格的狂热追捧者。 注意,这只是一篇参考,它是Google的C++风格,你并不一定严格的遵循所有的规则,永远记住很重要的一点,风格永远跟着你的团队走。 本人能力有限,所以不一定每个地方都翻译的准确,另外一些不太好翻译的专业名词首次出现时,我会标注英文原文。 原文:Google C++ Style Guide 背景 (Background) C++是很多Google开源项目所使用的开发语言。正如每一个C++程序员所熟知的,C++有很多强大的功 能,但功能强大也同时意味着复杂性(complexity),使得代码bug率更高且难以阅读和维护。 这篇参考指南 (guide)的目的在于,通过详细描述应该做的(dos)和不应该做的(don’ts),来控制我们撰写C++代码时的复杂性。这些规则令程序员在高效 利用C++语言特性的同时,还能让手工写出的所有代码(code base)易于管理。 风格(style),或者可 读性(readability),我们把它称作为“用来管理我们C++代码的常用惯例(convention)”。不过用“风格”这个术语有些不当,因为 这些惯例并不只是指代码源文件的格式。 让代码可管理,一种方式是加强代码的一致性(consistency)。令任何一个程序员能够快速的理解另一个程序员所写的代码是非常重要的。如果 代码保持统一的风格并且遵循惯例,我们可以更加轻松的使用“模式匹配”(pattern- matching)推断出,不同的符号分别代表什么。创造这种代码公共性(common)需要习语(idiom)和模式(pattern),使得代码易于 理解。在某些情况下,也许有好的理由来改变某些风格规定,但为了获得一致性,不管怎样我们还是得保持风格。 这篇参考指南所关注的另一点是C++的功能膨胀问题。C++是一个有很多高级特性的庞大语言。在某些情况下,我们限制甚至禁止使用一些特性。这样做 是为了保持代码的简洁,并避免因使用这些特性而带来各种常见的错误和问题。指南里会列出这些特性,并解释为何限制使用它们。 Google 所开发的开源项目遵守这篇参考指南里所列出的规定。 注意,这篇指南不是C++教程,我们认为所有正在阅读的同志们都是熟悉C++的。 头文件(Header Files) 一般而言,每个.cc文件都有一个关联.h文件。但也有一些例外,比如用于单元测试(unit test)的.cc文件或者只包括一个main()函数的小型.cc文件。 正确的使用头文件可以让代码的可读性、规模(scale)和性能(performance)得到很大的改观。 接下来介绍的一些规则将会引导你越过使用头文件时的各种陷阱。 #define防护(The #define Guard) 所有的头文件都应该使用#define防护来防止多重包含(multiple inclusion),格式是 1<PROJECT>_<PATH>_<FILE>_H_ 为了保证唯一性(uniqueness),该格式应该基于源文件在整个项目中的路径。比如说,项目foo中的头文件foo/src/bar/baz.h应该用如下的格式: 123456#ifndef  FOO_BAR_BAZ_H_ #define FOO_BAR_BAZ_H_ … #endif //  FOO_BAR_BAZ_H_ 头文件依赖(Header [...]