Posts Tagged ‘开发’

社会软件七要素

August 8th, 2009

从“用户创造”到“六度分割”,2004 年开始的 Web 2.0 互联网进化早已告一段落,全球最大的社会网络 facebook 已经在互联网大陆的造山运动中诞生,还有代表地球脉搏的 twitter 正在让全世界人民疯狂,当有十亿地球人接入互联网的时候,我们的网络就不可回避的完全社会化了。社区型应用无所不在,我们的身份,社会关系,生活工作都接入了网络,上个世纪末期还认为是科幻小说中的情节现在都成为了现实。

虽然大家都希望给社会网络(或者社会软件)一个确切的定义,但网络发展如此之快,我们只能够给当下的形态做一些模型化的分析。早在 2004 年,Matt Webb 就根据 Stewart Butterfield 的一份讨论列表整理出了社会软件的 7 个基础特性:身份(identity)、状态(presence)、关系(relationships)、会话(conversations)、群组(groups),声誉(reputation)和分享(sharing),当时他们拿 AIM 作为社会软件的典型例子,用这 7 个特性加以定义

之后 Gene Smith 套用 Peter Morville 的“用户体验蜂巢模型图”,绘制了“社会软件的蜂巢模型图”,给社会软件的七要素做了更加形象的描绘。

社会软件七要素定义

社会软件蜂巢模型

社会软件蜂巢模型

  • 身份(Identity) – 用户在系统中的唯一身份。身份是社会软件的核心,所以它在蜂巢图的中心,你可以用现实社会中的身份进入系统(实名社区),也可以使用虚拟的身份,你在社会网络中的任何活动都会与这个身份相关
  • 状态(Presence) – 状态通常表示在线或者离线,当然也可以表达更详细的信息,在哪里(地理位置)、做什么之类的(twitter 最初就是用来告诉朋友 What are doing 的服务)
  • 关系(Relationships) – 系统中两个用户之间的关系,例如 twitter 中的 follow 关系,flickr 中的朋友、家人,不同的系统对关系有不同的定义和用法
  • 会话(Conversations) – 用户在系统中和其他用户交流的方式,可以是系统消息、即时通讯,或者多人讨论的形式
  • 群组(Groups) – 有人就会有群落,群组是系统中把相同兴趣的用户组织在一起的有效方式
  • 声誉(Reputation) – 声誉是系统给用户的人品或级别定义 (你在社区中是个守法公民,还是垃圾信息制造者)
  • 分享(Sharing) – 系统中用户彼此之间展示和传播的东西,例如相片、视频或者是一个网址

并不是所有的社会软件都具有这 7 个特性,大部分都只有其中的几个。这个蜂巢模型图中引用了几个现实中的例子,并且用颜色的深浅表示了一个特性在系统中的重要性。就像 flickr 更侧重与照片的分享,豆瓣则是音乐、电影和图书的分享;而 twitter 和类似的微博客服务最重要的特性就是即时更新自己的状态变化,并且让朋友知道;当然还有像 facebook 这样功能全面的“社交型网络”,7 个要素全部占满,但是 facebook 最初的目的还是通过实名的方式建立自己的在线身份和好友关系,所以身份和关系是它的核心。

这张模型图并不是设计社会软件的万能药,模型和图表是为了让设计者的思路更加清晰,明确重点,避免遗漏,最大的作用是让大家在交流中有统一的表述方式和共同的认识。

最初在小容的“Peter Morville 的同行们: Louis Rosenfeld, Gene Smith 和 Joshua Porter”一文中了解到了 Gene Smith 和他的 “Social Software Building Blocks”,许多优秀的想法是大家长期交流而沉淀下来的结晶,然后由某些人在适当的时候做了个总结,所有的参与交流者和传播者都是思想的桥梁,我们用 Blog 记录思想,保留每个传播节点的链接,是对每个乐于分享和交流者的尊重。

更多阅读

像 Cocoa 开发专家一样思考

February 24th, 2009

Apple 除了拥有独特的用户社区文化之外,还有一个独特的开发文化,那些优秀产品的诞生之源。想要成为一个优秀的 Mac 或者是 iPhone 的开发者,在熟悉 Objective-C 和 Cocoa 之余,你需要用不同的方式来思考你的软件的设计和代码,Think Different 的思想 需要深入你心。了解一下那些经验丰富的 Cocoa 开发者们的思考方式,这将有助于你成为一名开发的专家。如果你对 Mac 的开发非常陌生,可以看看这篇《成为一名 XCoder》。

和 Unix 社区一样,Mac 的开发也有浓厚的社区文化,在 FreeBSD 架构上脱胎换骨的 Mac OSX 让这种文化更加繁荣,在保持 KISS(Keep It Simple and Stupid)原则的基础上,一名 Cocoa 开发专家的所有的工作焦点都是他的最终用户,而不是代码的优雅算法。他们永远都从简单的、低技术含量的解决方案开始,除非你有一个清晰的理由让他们去使用一个复杂的方法来解决问题。这并不表示他们不注重技术,给用户留下一个深刻的印象才是首要的目标。

如何实现伟大的软件

避免过渡设计 – 不要坐在那里去设计一个可以把所有可能存在的细节都表述清楚的架构方案。你应该做的是,抓住那些确实存在的,用你手边的工具去实现它们。将一部分搞定之后,你会从中学到你所能做的,然后再迭代到下一个部分里面,直至全部完成。

避免盲目设计 – 不要盲目的去实现设计需求中的每一个功能。把那些需求作为一个起点,然后持续的问自己这个问题:“确实有这样做的必要么?”我们最终的目的是开发给人使用的软件,而不是去实现一份写在纸上的漂亮文档。Getting Real 中也提到过相同的观点,文档最终的归属是垃圾桶,那些与你的程序分离的描述是毫无价值的,你只需要记录关键的地方,一些机制、方法和容易忘记的东西,其它的就直接动手去做吧。

为乐趣而过渡设计 – Mac 的开发者们喜欢用那些超越工程师思维的解决方法来实现一些有趣的东西。在不影响软件的整体质量和交付时间的基础上,他们试图给彼此留下深刻的印象,这些锦上添花的过渡设计会给大家带来发自内心的喜悦,同时还能够很好的工作。

优化 – 在你知道你实际要做什么之前就去考虑优化的问题,会妨碍产品的正常开发。让一些部分先工作起来,然后把它们重组成一个相对清晰的设计,这之后再去优化性能。永远从你所知的最简化的方式开始实现,记住简化才是关键,而不是萦绕地的去思考如何优化。

专家写更少的代码 – 有经验的 Cocoa 开发者通过 OSX 的框架(frameworks)来组装需要的东西,在决定自己从轮子开始造车之前,多花些时间去研究如何使用那些内建的方法和类(classes)。自己实现的代码需要花费你宝贵的时间来维护,如果使用了内建的代码,这种事情就永远不会发生。

Frameworks 和 API – 不要凭空的去创造自己的可复用框架,让你的代码在应用程序里面去解决了实际的问题之后,再把它们整理成可以被调用的 API。如果你通过功能的猜测来创建 API,你很有可能会因为错误的设计而无法进行下去。

时刻注重体验,不管是内在的还是外在的

体验无处不在 – 老练的 Cocoa 开发者会把每一个步骤的用户体验都考虑周到。通常新手只认为那些显示在屏幕上的图形才是用户能体验到的地方,但实际上那些设置窗口中文字的用词和大小写,存储在本地的数据文件名,甚至是命令行窗口的消息文字,都是应该考虑到的环节。

用户并不傻,只是他们还有其他的事情要做 – 不要把用户当作专家,但是也不要看扁他们。那些非专家用户通常是不愿意花太多时间像工程师那样思考的聪明人,因此,让你的软件尽量做到的对初级用户友好,而不要用起来像一个专家才能完成的任务。

写优美的代码 – 开发人员的代码阅读体验是非常重要的。现在你是唯一的开发人员,但将来你可能只负责其中的一个版本,或者由其他的人来开发,也有可能是贡献业余时间的自由开发者,当你决定把代码开源之后,所有的情况都表明代码不是为一个人而写的。我们可以把发布拥有优美代码的软件作为一个期望,但至少也应该做到在最后的发布之前把代码整理干净一些,这样不至于让代码看上去越来越丑陋。

如何让软件变得更加优秀

成为用户的拥护者 – 专家们会像画家对自己的作品那样细致审视自己的软件,他们寻找任何可能的机会去改进,而不会对那些瑕疵视而不见。你不需要这样做去影响你的同事或者是合作伙伴,你需要做的就是成为最终用户体验的真正拥护者。

学会观察全貌 – 当审视软件的时候,真正的专家不会单纯的将软件分离成相互独立的部分来看待。用户最终看到的只会是一个整体,一款伟大的软件就像是科学中的艺术品。最高的目标就是满意度,为了达成它,可能需要面对一些非逻辑、和反直观的东西。

接纳反馈 – 经验丰富的开发者不会忽视那些苛刻评论和反馈。感谢那些第一批使用你软件的先锋用户,因为他们会带给你真正有价值的信息。一定不要用个人的情绪来排斥自己不愿意接受的批评。

明确哪些是不需要实现的 – 专家能够鉴别那些没有被采纳但用意良好的反馈,把用户的所有需求都实现出来对你并没有什么帮助。能够让产品成功的一个关键点就是决定那些功能不去实现,这样才能让你专注的将剩下的功能打磨的闪闪发光。

我们建立规则,我们打破规则

“给用户带来真正伟大的东西” - 为了达到这一目标,上述的规则都可以被打破和修改。有一点需要铭记,享受你所做的事情,它会完全反应到你的作品里!

本文翻译整理至 Scott Stevenson 的 《Thinking Like a Cocoa Programmer

如何搭建下一代 Web 应用

December 15th, 2008

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

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

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

next-generation-web-infrastructure

next-generation-web-infrastructure

1. 基础层(3rd Party Web Infrastructure)

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

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

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

2. 应用层(Application)

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

RubyPython 这两个小巧灵活的动态语言现在成了实现新一代 Web 应用的新宠,很多出色的 Web 应用都通过 Ruby on Rails 框架来实现(例如 Twitter37Signals 的所有服务),同时 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 应用架构有什么建议或者想法,都可以在这里留言交流 :)

如果您订阅了 “indigo 的 数字镜像” 或者经常访问,点击这里就可以加入 indigo 的 friend connect,成为小站的一名成员,让 indigo 和大家都认识一下浏览器前面的你

Getting Real 学习笔记:关于编码

July 9th, 2006

小巧的软件:随着代码量的增加,你软件的复杂度也会随之增 加,每一次调整和变动的效果都会叠加,所以让你的程序代码尽可能的保持简洁。那么抵制这种代码复杂化的最好方法就是只做小巧的软件,它也意味着更少的功 能、更少的代码和更少的浪费。小巧的软件让你放弃对未来功能的规划,将重点放在解决现在的问题上。为什么呢?因为你所担心的未来的扩展通常不会立刻到来。 开发小巧的软件会给你带来如下的好处:

  • 容易管理
  • 少量的代码让你的维护变得简单
  • 你可以更灵活的改变功能(代码修改的成本降低)
  • 更少的BUGS和更少的客户支持

让你的开发人员敢于向不合理的功能需求宣战,他们知道如何简单的实现一个合理的功能,用最好的方法。

为快乐而编码:一个快乐的程序员会是一个高产的程序员,选择那些能够让你的团队保持激情的工具,而不要选择那些符合业界标准的陈旧的工具。你的成员需要有趣的、富有挑战的、能够让人感到自豪的,能够在8小时的工作内充分感觉到快乐的方式来工作。就像 37Signals 选择了 Ruby 作为他们的开发语言,他们用最大的热情推动了 Rails 框架的发展(在此之前Ruby还默默无闻)。当然不仅仅是开发语言,一个他们喜欢的平台、应用或者是框架,都能够给他们带来快乐。只有快乐的程序员才会写出简单的、可读的代码,他们拥有清晰的思路和一流的解决方法。

倾听你的代码: 优秀的代码是简洁而清晰的,倾听你的代码,它会告诉你哪里存在缺陷、如何去实现新的功能、以及哪种是更适合你的开发模式。你的新功能真的需要数周的上千行 的编码吗?你的代码会时刻提醒你,注意他的复杂度和膨胀的速度。你应该尽量用简单的方法在一个小时之内实现需要用十小时才能搞定的复杂思路。遵循简单和廉 价的原则,避免那些复杂的实现,留意你的代码,它是你思路的最好监督者。

为你的代码买单: 通常我们理解的债务都是金钱上的,其实也有很多其他的形式,例如你的代码和设计。就像你必须拿出你收入的一部分来纳税一样,在你的代码和实际交付之后,你 也必须花时间在他们的修改和调整上面。那些糟糕的代码和不合理的设计会成为你以后维护的巨大债务,你应该只把时间花在代码的小小调整上,而不是将主要部分 的开发重新来过。所以你需要认真地对待你的每一行代码和任何一个细节上的设计,不要让他们成为你维护的负担。

使用开放的格式: 你应该使用那些开发的协议和方式来封装你的数据,例如RSS或者标准API的形式,不要为了隐藏而使用一些私有的协议,这样对谁都不好。人们可以通过 RSS来按照自己喜欢的方式查看数据的更新,第三方的开发者也能够使用你的标准API来为你写扩展的应用,这样你就可以拥有一个沟通便捷和接口灵活的系 统。千万不要认为RSS只是用作Blog或者是新闻的更新,任何数据的更新同步都可以通过它来实现,还有API,尽量使用标准的格式来封装,例如XML- RPC或者是REST协议。其实你已经有很多成功的例子可以参考了:Google Maps APIFlickr API ,网络上有数以百计的扩展应用是通过他们开发的接口实现的,将你的系统开放给用户和开发者,你将会获得许多意想不到的收获。

999999">学习笔记仅供交流参考,需要了解完整的内容,还请大家购买《Getting Real999999">》的原版:)