博客榜—查看频道“Indigo 的数字镜像”

总排名： 2350

Indigo 的数字镜像

Digital Updating ...

作者：indigo
RSS地址： http://feeds.feedburner.com/indigo_blog
共有10篇文章被收藏推荐

鲜果类别： IT.科技

indigo 的频道收录于2007-04-07

报错

最新文章

精华文章

54位订阅者

还没有评论

▶ 小思宇的满月历程 :) 2009-01-02 23:32

给小宝宝最好的礼物就是留下成长的记忆，爸爸把小思宇出生一个月的成长历程都用照片和视频记录下来，作为第一份新年礼物送给他，希望他开心健康的成长小思宇的满月照片才刚满月就拿着PS3的手柄不放，看来以后和爸爸一样要当 OTAKU 啦更多小思宇的满月照片小思宇从出生到满月的视频...

▶ 简单法则 - The Laws of Simplicity 2008-12-26 01:35

“简单（Simple）”是个有诱惑力的词汇，很多情况下，它是一种梦寐以求的境界。前田约翰（John...

“简单（Simple）”是个有诱惑力的词汇，很多情况下，它是一种梦寐以求的境界。前田约翰（John Maeda）常被人称为“简单大师”，他是麻省理工学院美学与计算小组实体语言实验室的总监，这位数字媒体界传奇性的艺术家与设计师，擅长将电脑程序的计算性与艺术优雅的表现作完美的结合（似乎这个时代更需要能够把技术与艺术完美结合的人才，感性之上的理性，就像 Apple 的大神 Steve Jobs）。他的这本《简单法则》（The Laws of Simplicity）阐述了通往“简单”之路的简易之法，“简单”是一种商业思维，设计的哲学，技术创新的原则，同时也是生活的美学。

下面每一条法则都从一些书籍里面得到了启发，indigo 把 John Maeda 的推荐整理成了一个“豆列（简单法则参考书）”，并且顺序是一一对应的，感兴趣的话可以再深度阅读一下。

简单的 10 条法则（引用 John Maeda 的原文）

1. 减少（REDUCE）：达到简单最简单的方法，就是用心割舍

2. 组织（ORGANIZE）：将事物有条有理地呈现，能使“多”显得少

3. 时间（TIME）：节省时间会让人感觉简单

4. 学习（LEARN）：好的设计，能够运用上人类本身觉得熟悉的东西

5. 差异（DIFFERENCE）：没有复杂，简单就失去价值

6. 环境（CONTEXT）：简单地周边事物绝非无关紧要

7. 情感（EMOTION）：对于简单的设计，赋予的感情越多越好

8. 信任（TRUST）：简单需要通过信任来换取

9. 失败（FAILURE）：有些事物不可能简单

10.单一（THE ONE）：简单就是减少明显的，增加有意义的

简单的 3 个要点

远离（AWAY）：只要挪得远远的，多就会显得少

开放（OPEN）：开放会简化复杂

能源（POWER）：少用，会得到更多

John Maeda 将“简单哲学”分为 3 个层次，并依照“基本、中度和深度”划分成 3 组渐进法则。其中“基本法则”（1－3）可以马上应用到各种产品设计的构思里面去；而“中度法则”（4-6）的含义比较微妙，“深度法则”涉及到了一些还未成熟的思想领域。最后一条（10）法则是对整套概念的单一解释。

我们可以把“简单”当作一种事物的衡量标准，记得上学的时候，只要解题的答案过于复杂，或者推导的公式看上去怪怪的，那么思路或者答案一定就是错的，最经典的质能方程 E=MC2 看上去妙不可言。

简单的商业模式永远都比那些复杂的成功率高（如果你的商业计划书用几十页纸都讲不清楚，最好考虑换个思路）；技术的发展也永远都是以简单为目标，通过各种方法来简化和隐藏复杂。电脑从庞然大物变成了小巧简单的手持设备，Apple 坚持的理念让这些电子设备平易近人，简单的设计让我们更有理由去爱它拥有它；笨重复杂的软件安装方式也正悄然远去，用浏览器接入 Google 的“云服务”就可以完成很多工作了，将复杂的细节挪得远远的，多就会显得少，记得一句广告语“科技让人更轻松”，应该就是这样体现出来的。

管理大师汤姆·彼得斯（Tom Peters）在《Tom Peters Essentials - Design》一书中反复强调”美丽的系统“都是简单的，裁剪掉一切不需要的东西，让它变得优雅、苗条，才会美丽。虽然这些说起来都很空泛，但是把简单作为你的设计准则和生活哲学，一定会受益匪浅！

如果希望看到更多 John Maeda 对简单的理解，请访问他的 Blog － lawsofsimplicity.com

▶ 超易用的开源项目管理系统 - Redmine 2008-12-21 09:35

协作对于一个团队来说至关重要，尤其是产品开发的团队，项目化的管理方式已经深入人心，MS Project 所有做过项目管理的人都应该了解，但是每天面对一张静态的甘特图来分配资源、调整进度的做法已经不合时宜了，在 Web 服务盛行的时代，以沟通为核心概念的小型团队项目管理服务 Basecamp...

协作对于一个团队来说至关重要，尤其是产品开发的团队，项目化的管理方式已经深入人心，MS Project 所有做过项目管理的人都应该了解，但是每天面对一张静态的甘特图来分配资源、调整进度的做法已经不合时宜了，在 Web 服务盛行的时代，以沟通为核心概念的小型团队项目管理服务 Basecamp 取得了成功，同时还捧红了 Ruby on Rails 框架。

沟通与共享是现代项目管理的核心，这种 Web 形式的项目管理系统通过“项目（Project）”的形式把成员、任务（问题）、文档、讨论以及各种形式的资源组织在一起，大家参与更新任务、文档等内容来推动项目的进度，同时系统利用时间线索（Timeline）和各种动态的报表（Report）形式来自动给成员汇报项目进度。

在技术开发领域，Bug 追踪、Wiki 和版本控制的集成对于项目管理系统来说必不可少，当然能够实现这些功能的系统也有很多，例如：

Trac：基于 Python 的开源程序，应该是最早将 Ticket 与项目结合起来的开发管理系统，支持 Wiki、Timeline、Report 和项目模块分级与里程碑定义，还能够绑定查看SVN内容，简单易用，但是团队开发速度太慢，很多功能确实，无法进行权限分配、多项目管理，配置不够灵活，实在有些遗憾
Jira + Confluence：基于 Java 的 Bug 追踪和企业 Wiki 系统，需要购买，而且很贵，Jira 的 Bug 和事务流管理能力很强大，Confluence 应该是目前最好的企业 Wiki 系统，扩展性强，但是某些操作和体验显得有些跟不上时代
ActiveCollab：基于 PHP 的 Web 项目管理程序，曾经是开源版本的，后来给商业化了，需要购买，Trac 与 Basecamp 的模仿者，安装和使用简单
还有许多 SaaS 方式的在线项目管理服务，例如：Comindwork、LiquidPlanner 、MyQuire、ProjectSpaces、Huddle、PlanHQ、Goplan 等，不过介于中国的出口带宽情况和用户心态问题，将重要的项目数据放在遥远的第三方目前来说还是有些不现实的…

啰嗦了很多，下面介绍主角 Redmine，一个 Trac ＋ Basecamp 的混合体，吸取了两个系统的有点，基于 Ruby on Rails 框架开发，开放源代码，可以跨平台部署，indigo 觉得它应该是小型开发团队项目管理的首选系统。

多项目和子项目支持
可配置的用户角色控制
可配置的问题追踪系统
自动日历和甘特图绘制
支持 Blog 形式的新闻发布、Wiki 形式的文档撰写和文件管理
RSS 输出和邮件通知
每个项目可以配置独立的 Wiki 和论坛模块
简单的任务时间跟踪机制
用户、项目、问题支持自定义属性
支持多种版本控制系统的绑定（SVN、CVS、Git、Mercurial 和 Darcs）
支持多 LDAP 用户认证
支持用户自注册和用户激活
多语言支持（已经内置了zh简体中文）
多数据库支持（MySQL、SQLite、PostgreSQL）
外观模版化定制（可以使用 Basecamp 的主题，感觉上就像是自己架设的 Basecamp 服务）

Redmine 的官方网站：http://www.redmine.org/

Redmine 的官方 demo 站点：http://demo.redmine.org/

更详细的功能说明请看官方网站的特性列表，如果还有哪些不能满足你的需求，可以在这里提出功能请求

Redmine 的部署比较简单，没有 Trac 那么多的依赖项，indigo 在 Mac OSX 10.5 下面安装好 ROR 2.1.2 的框架，配置 Redmine 到它的 demo 环境，使用 SQLite3 数据库连接，利用 Ruby 自带的 WEBrick 服务器就可以运行了。当然这只是简单的测试运营，要在真实环境中使用，还需要找一台服务器（推荐 Ubuntu）并且使用 MySQL 作为数据库。

安装参考：在 Ubuntu 8.10 中安装 Redmine 系统－ by indigo

▶ 如何搭建下一代 Web 应用 2008-12-16 11:53

时过境迁，搭建 Web 应用连“轮子”都要自己做的时代已经过去了，如果你需要构架一套小型或者是中型的 Web...

时过境迁，搭建 Web 应用连“轮子”都要自己做的时代已经过去了，如果你需要构架一套小型或者是中型的 Web 站点，现在已经不需要为服务器、机架、托管和安装系统而操心，选择一家优秀的网格托管技术提供商，再搭配一个构架在“云端”的虚拟存储服务（如果有大量数据存储的需求），挑选你自己最擅长的 Web 应用开发技术和前端呈现技术，最后再实现当下流行的各种 Widget 和 Social 接口，就能将自己的 Web 服务武装到牙齿了，而且噱头十足。

Dion Hinchcliffe 先生在他的《Tips for Building Next Generation Web 2.0 Applications》一文中为这些应用架构做了清晰的总结，indigo 将他的图稍作了一些更加概括性的调整。

新一代 Web 服务的四层架构：基础层、应用层、分布层和社会层

next-generation-web-infrastructure

1. 基础层（3rd Party Web Infrastructure）

除非你有自己的机房或者数据中心，不然我们的数据就都是交给第三方托管的。按照旧有的托管概念，选择服务商，托管设备，所有的应用逻辑都在这些设备里面完成，计算、存储、数据库全部自己解决，需要大量的设备和维护人员，现在这些基础的逻辑服务可以完全交给不同的第三方公司通过网格托管（Grid Hosting）和云计算（Cloud Computing）服务来帮你实现。

我们可以把基础层想象成那些第三方已经实现好的程序模块，它们更像是操作系统提供给我的系统功能一样，程序运行空间、磁盘读写服务、CPU 调用接口和各种 IO 服务。

通过传统的网格托管，例如 3Tera 的 AppLogic，还有 MediaTemple 的 Grid-Service，在一定程度上不用为系统的分布式和访问负载担心，直接想服务提供商购买额外的负载能力就行。OpenID 可以实现统一的身份验证，现在 Google 和 Yahoo 的帐户都能进行这种认证；Amazon 的云计算服务 S3、SimpleDB 和 EC2 分别提供了虚拟的存储、数据库和应用计算托管的服务，还有 Google 最近推出的 AppEngine，你只需要将程序代码部署到这个 Web 应用容器之中，就能够使用 Google 完善的分布式网络架构了（感觉这是 Google 最伟大的一个项目了）。所以说，现在搭建一个 Web 服务最核心的技术需求已经能够完全在这些第三方的平台中完成。当然，像第三方的搜索服务（Google Coop）、地图服务（Google Maps）、消息队列服务（Amazon SQS）、即时通讯服务（Google Talk），我们也都能够将其作为基础功能整合成为自己服务的一部分。

2. 应用层（Application）

Web 服务的业务逻辑和实现方法都在应用层解决，它们在基础层提供的虚拟程序空间里面运行。套用最经典的程序开发模型——文档视图模式（MVC），应用层就是要来实现 Web 服务的数据模块（Model）、控制模块（Controller）和呈现模块（View）。

Ruby 和 Python 这两个小巧灵活的动态语言现在成了实现新一代 Web 应用的新宠，很多出色的 Web 应用都通过 Ruby on Rails 框架来实现（例如 Twitter 和 37Signals 的所有服务），同时 Python ＋ Django 则成为了 Google AppEngine 的首选开发框架，在这种新构架之下，编程语言的开发效率，灵活性和运行平台的支持度成为了关键因素，我们需要实现的更像是基础服务的粘合剂，通过快速的组装来提供应用，而不用去考虑语言的执行效率和语言自身有多么完美。

在数据端，MySQL 仍然是 Web 应用的主流数据库系统，但现在很多复杂的业务都被基础层所封装，Rails 和 Django 框架中的数据对象模型正在被广泛采用，提高开发效率并简化查询方式是大家使用的主要动力，当然还有像 SimpleDB 和 AppEngine 这种虚拟服务的推动作用。

在用户前端，浏览器是绝对的标准和主流，因此支持好 HTML，Javascript 和 Web 标准就不会有任何访问的障碍和方向性的选择错误，如果还需要更酷的效果，Adobe 的 Flash 会是个不错的选择，至于 Microsoft 的 Silverlight 嘛，革命尚未成功，同志还需要努力。

3. 分布层（Distribution）

新的 Web 站点和服务将不再是信息的孤岛，对外暴露自己的数据显得尤为重要，Web 应用就像生物组织内的细胞，它们获取来自外界的能量，同时也产生能量输送给整个生物体。分布层就像 Web 服务的接口，其他的 Web 服务可以通过这些标准接口接入进来，自己的内容也可以输出给其他服务。

有一点需要牢记，想让自己的服务在今后的互联网中有立足之地，开放你的接口吧，不管是 REST 流的还是 SOAP 派的，因为除了人在访问你的网站之外，还有大量的机器和服务程序对你的应用感兴趣，让自己的服务成为别人业务逻辑的一部分之后，基本算是成功了（看看 flickr 是如何开放成为全球最大的照片托管服务的）。那些开放的 APIs 是被动的等着来访问，你还需要主动出击，通过 RSS、ATOM 和 Ping 这种特性来通知其他服务你更新了内容。

各种页面嵌入的 Widgets 和电脑桌面与手持设备使用的 Gadgets 也是输出服务内容必备选项，Widget 的形式更容易被其他的 Web 服务整合，例如 iGoogle 和 Blog 的 Sidebar 上。让数据能够更加方便的输出，同时也提供给第三方数据输入的机会，这是在“分布层”应该做的最重要的事情。

4. 社会层（Social）

无论什么样的 Web 应用，最终都需要有人的参与，人与人之间的行为相互影响，自然就形成了社会效应，不管参与人数的多少还是服务规模的大小，在这个架构的最上层，就是要平滑的实现 Web 用户之间的信息流通，所以我们称其为“社会层”。

经过多年的进化，社会化的标配应用形式已经成型，Blog（文字的、图片的和视频的都算），论坛和各种 Wiki 形式的内容分享，它们像网站的内容骨架，无论何时都可以考虑使用这几种应用形式。现在还多了 twitter 方式的 MicroBlog 和 facebook 形式的 WebIM，也许今后会成为网站标配的一部分。

Social 的思想已经深入人心，只要有用户登录和身份的网站就会好友关系（Friends List），好在 Google 已经为大家准备好了 OpenSocial 标准和 FriendConnect 服务，还有 facebook 的 Connect 服务，这两个公司致力于维护用户身份的唯一和好友关系的统一，无论在哪个网站上登录，你就是你，你的朋友也都是那些老朋友，不用重复填写档案信息，也不用重复添加好友，很理想，很完美主义 …

不管是 Google 帮还是 facebook 派，或者始终特立独行，社会性的 Web 服务都需要有好友关系、用户档案（Profile）和用户活动流（Activity Stream），在还没有行业标准的情况下，可以使用 Google 的 OpenSocial 格式来输出和提供接口。这些用户的数据会被订阅，被聚合网站读取，或者被其他的服务分享，拥有这些数据的人就会更乐于推荐和使用你的服务，所以让用户的数据在不同的服务之间流动起来，这个才是网站社会化的精髓所在。

除了技术架构之外…

当然，构建优秀的 Web 应用，只靠清晰的技术架构是远远不够的，你需要对 Web 2.0 有深刻的理解，熟悉 Web 2.0 的编程思想、知道如何激发网络效应、利用好集体智慧，还需要拥有优秀的团队，适合新网络应用的产品开发方法和简单易行的处事方法（Getting Real 一些比较好），最后还需要一点点运气和机会。

这篇文章是根据 Dion Hinchcliffe 先生在 Web 2.0 Expo ‘08 大会上的关于 “Building Next-generation Web 2.0 Applications” 议题的整理。大家对下一代 Web 应用架构有什么建议或者想法，都可以在这里留言交流