Facebook如何管代码

【原文首发于《FrameThink》(英文版,需翻墙),感谢老崔的推荐(译文在此),推荐者说:“看完之后终于明白为什么优秀的工程师都去了或想去facebook,因为那里是工程师们的天堂。】

我对facebook的运转着迷,这是一个很独特的环境,不容易被复制(他们的体系并不适合所有的公司,即使他们努力尝试过)。下面是我和facebook的朋友们关于他们如何开发和管理项目的记录。

现在距离我收集的这些信息又过去6个月了,我相信facebook肯定又对他们的项目开发实践进行了改进。所以这些记录可能会有点过时。同时facebook的工程师驱动文化也越来越为大众所知。非常感谢那些帮助我整理这篇文章的facebook的朋友们。

记录:

    • 截止到2010年6月,facebook有将近2000名员工,10个月前只有1100名,一年之间差不多翻了一番。
    • 两个最大的部门是工程师和运维,每个部门大概都是400-500人。这两个部门人数大约占了公司的一半。
    • 产品经理与工程师的比例大约为1-7到1-10。
    • 每个工程师入职时,都要接收4-6周的培训,通过修补bugs和听高级开发工程师的课程来熟悉facebook。
    • 培训结束后,每个工程师都可以接触线上的数据库(更大的权力意味着更大的责任,也有一份”勿做清单”,不然可能会被开,比如共享用户的隐私数据)。
    • 有非常牢靠的安全体系,以免有人不小心/故意做了些不好的事。
    • 每个工程师可以修改facebook的任何代码,随时可以迁入。
    • 浓厚的工程师驱动文化。”产品经理基本可以被忽略”,这是facebook一名员工的话。工程师可以修改流程的细节,重新安排工作任务,随时植入自己的想法。
    • 在每月的跨部门会议上,由工程师来汇报工作进度,市场部和产品经理会出席会议,也可以做些简短的发言,但如果说得太多,很可能就会被打小报告。他们确实想让工程师来主导产品的开发,对自己的产品负责。
    • 项目需要的资源都是自愿的。
    • 一个产品经理把工程师们召集到一起,让他们对他的想法产生兴趣。
    • 工程师们决定开发那些让他们感兴趣的特性。
    • 工程师跟他们的经理说:”我下周想开发这5个新特性”。
    • 经理会让工程师独立开发,可能有时会让他优先完成一些特性。

facebook

  • 工程师独立完成所有的特性——前端/后端/数据库,等等所有相关的部分。如果需要得到设计人员的帮助,需要先让设计人员对你的想法产生兴趣。其他如架构之类的也一样。但总体来说,工程师要独立完成所有的任务。
  • 对于某个特性是否值得开发的争论,通常是这么解决的:花一个星期的时间完成他,并在小部分人群中(如1%)进行测试。
  • 工程师常常希望解决难题,这能获得声望和尊敬。他们很难对前端项目或UI设计产生太大的兴趣。这跟其他公司可能正好相反。在facebook,后端任务,比如新的feed算法,广告投放算法,memcache优化等等,是工程师真正感兴趣的。
  • 所有的代码修改都要进行审核(通过一个或多个工程师),但News Feed是个例外,因为太重要了,Zuckerberg会亲自review。
  • 所有的修改至少要被一个人审核,而且这个系统可以让任何人很方便地审核其他人的代码,即使你没有邀请他
  • 工程师负责测试,代码修复,和维护自己的项目。
  • 每个办公室或通过VPN连接的员工会使用下一版的facebook,这个版本的facebook会经常更新,通常比公开的早1-12小时。所有的员工被强烈建议提交bugs,而且通常会很快被修复。
  • 很奇怪只有很少的QA或自动测试——”大部分工程师都能写出基本没有bug的代码,只是在其他公司他们不需要这么做。如果有QA部门,他们只要把代码写完,扔给他们就行了”
  • [针对上一条]我们有自动测试,代码发布前必须要通过测试。我们不相信”所有的工程师都能写出没有bug的代码”,毕竟这是一个商业公司。
  • 很奇怪,缺少产品经理的影响和控制——产品经理是很独立的和自由的。产生影响力的关键是与工程师和工程师的领导们们搞好关系。需要大致了解技术,不要提一些愚蠢的想法。
  • 所有提交的代码每周二打包一次。
  • 只要多一分努力,终于一天会发生改变。
  • 星期二的代码发布,需要所有的提交过代码的工程师在场。
  • 代码打包前,工程师必须在一个特殊的IRC channel上。
  • 运维执行打包过程。
  • facebook有大约60000台服务器
  • 有9个代码发布级别
  • 最小的级别只有6台服务器
  • 星期二的代码发布会先发布到6台服务器上,运维组会检测这6台服务器的反应,保证代码正常工作,然后再提交到下一级
  • 如果发布出现了一些问题(如报错等等),那么就停止下一级的部署,提交出错代码的工程师负责修复问题,然后从头继续发布。
  • 所以一次发布可能会经历几次重复:1-2-3-fix. 回到1. 1-2-3-4-5-fix. 回到1. 1-2-3-4-5-6-7-8-9
  • 运维组是受过严格训练,倍受尊敬,而且有商业意识的。他们的工作包括分析错误日志,负载和内存状态等等。还包括用户行为。
  • 代码发布期间,运维组使用IRC-based页面系统,可以通过facebook/email/irc/im/sms ping每一个工程师,如果需要他们注意的话。对运维组不做回应是一件很羞愧的事。
  • 代码一旦发布到第9级,并且稳定运行,就算发布成功了。
  • 如果一个特性没有按时完成,也没什么大不了的,下次完成时一并发布即可。
  • 如果被svn-blamed,public shamed或工作经常疏忽就很可能被开除。”这是一个高效的文化”。不够高效或者不够聪明的员工会被剔除。管理层会在6个月的时间里观察你表现,如果不合格,只能说再见。每一级都是这个待遇,即使是C级别和VP级别,如果不够高效,也会被开除。
  • 被责骂不会导致解雇。我们特别尊重别人,原谅别人。大部分高级工程师都或多或少犯过一些严重的错误,包括我。但没有人因此被解雇。
  • 我也没有遇到过因为上面提到过的犯错误而被解雇。有些人犯了错,他们会非常努力地去修复,也让其他人得到了学习。
Advertisements

facebook与人人网的网站后台架构对比

要问时下什么类型的站点人气最旺?答案当属SNS网站。短短几年的时间,SNS便迅速确立了Web 2.0核心的地位。用户的增长量之快更是让人咂舌,而Facebook访问量首次超越Google的消息也让人觉得SNS的前途不可限量。当然,面对庞大 且繁琐的数据量、面对应用的高复杂度及用户体验,大型SNS站点的后台架构成为了近期受关注的重点之一。

在连续报道了《世界最大的PHP站点 Facebook后台技术探秘》及《专访人人网黄晶:SNS网站后台架构探秘》之 后,除了看到SNS网站后台的独特风景之外,我们也看到了作为国内外SNS站点的代表,Facebook和人人网在后台技术应用上还是有很多不同的地方, 当然,造成这种不同的原因有很多。这里我们将对比Facebook和人人网的后台架构,在找出这些差异的同时,我们也能够看出,跟国外相比,国内SNS网 站的后台技术差距还有多大?差距在哪里?

  后台语言的选择

作为一个大型站点,后台语言的选择意味着不同的架构路线、以及不同的开发框架。考虑到SNS网站后台架构的复杂性,可选择的语言并不 多,Facebook作为一个大型LAMP网站,选择了PHP;而人人网则使用Java。当然,PHP和Java各具优势,PHP+MySQL的黄金搭档 被无数站点所使用;在评价Java的优势时,黄晶老师说道,“而当项目日渐复杂的时候,Java则能通过其良好的OO特性,保持非常好的模块性,也有益于 网站重构。”

后台语言的选择有很多因素,选择哪种语言也并不重要,关键是要适合相应的生产环境,这里比较PHP与Java的优劣并没有太大的意义。但要说明 的是,每种语言都有它的劣势,如何进行有效的优化才是开发者们需要思考的,就像Facebook为PHP量身打造了HipHop那样。

  数据库

在后台架构中,数据库一直是我们关心的重点。曾经日壮山河的关系型数据库,在NoSQL运动下,仿佛显得日薄西山,这句话用在SNS站点中再合适不过了。没错,由于SNS站点的高复杂性,其对数据库的要求非常高,高性能、可扩展性以及可用性,缺一不可。

Facebook并不是一个传统意义上的LAMP站点,MySQL也主要作为一个Key-value的持久性存储使用,而它的存储系统则是 NoSQL运动的一个重要组成部分——Cassandra,它的特点也正是SNS站点所需求的,尽管很多人认为NoSQL还不够成熟,缺乏可靠性,但 Facebook的成功却是一个活生生的例子。

facebook架构图
Facebook数据库架构图,请点击原图查看

通过黄晶老师的介绍我们了解到,其实人人网也不只是在使用MySQL。Nuclear是人人网团队自主研发的分布式KV存储系统,目前已经在逐步的试用。关于Nuclear的详细介绍,可以参考人人网UGC团队博客的介绍:http://ugc.renren.com/2010/01/21/ugc-nuclear-guide-use/

从中我们不难看出,关系型数据库已经不能满足大型SNS站点的需求,在外国大胆使用NoSQL的同时(包括Facebook、Twitter 等),国内对NoSQL的使用还是显得比较谨慎,技术水平的差距,在这点上确实有所体现。从长远角度讲,特别是在SNS领域,NoSQL必将会逐步代替传 统的关系型数据库。

  缓存

缓存技术在后台架构中扮演着重要的角色。对于SNS站点来说,仅仅依靠数据库、Web服务器等软件的自身缓存机制是绝对不能满足要求的。 Memcached是人人网和Facebook都用到的一个分布式内存缓存系统,其已成为互联网最有名气的软件之一了。当然,缓存的手段是多种多样的,仅 仅保证日常后台的稳定运行也是不够的。面对一些突发事件,缓存机制更是尤为重要,特别是在数据库服务器与Web服务器上。

  图片存储架构

图片会给Web服务器带来不小的压力,特别是Facebook处理的图片量(每个月超过30亿张照片被上传),非常惊人!对此,Facebook专门开发了一套图片存储架构——Haystack。

相比于Facebook,人人网并没有一套完整的图片存储架构体系。当然,作为人人网的用户,能够感觉到进行上传图片等一些操作,还是很流畅 的。说明以目前的人人网图片处理技术,能够满足目前用户的需求,以及后台的流畅运行。但架构总要着眼于未来,开发一套完整的、高效的架构体系,才是最佳的 解决方案。

  SNS后台技术未来发展趋势

相比于其他类型的站点,SNS网站后台架构更为复杂。关于SNS后台技术未来发展趋势问题,黄晶也表示,鉴于SNS网站的一些业务特点,在后台 技术中,人人网最关注的仍然是高性能,可扩展性,高可用性,所以SNS网站架构中特别需要一个能灵活应对业务变化的一套健壮的分布式系统。

在对比过人人网与Facebook的后台架构之后,我们不难看出,除了整体架构的系统性能之外,对于其中每个细节的把握,更是我们国内架构师们需要仔细思考的,这同时也需要我们的技术人员提高自身能力、敢于使用先进的技术及应用、更要勇于创新。

Facebook 架构学习

设计原则

  • 尽可能的使用开源软件,并且在需要优化的时候进行优化
  • Unix 哲学。包括,模块化原则;整合化原则;清晰化原则等
  • 任何组件具备扩展性
  • 最小化故障影响
  • 简化,简化,简化!

架构概览

Facebook 是 LAMP 的坚定支持者,也差不多是用 LAMP (或许用 LAM2P 更适合) 实现的最大的动态站点。

Facebook Arch Overview.png

基础组件加上服务,中间用自己实现的一些工具进行粘合。其中关于运维细节的事情基本不会说出来的,这是很多公司的软实力所在。

PHP 经验

参见《Facebook 的 PHP 性能与扩展性》

MySQL 经验

    • 主要用于做 Key-Value 类型的存储操作,数据随机分布在多台逻辑实例上,访问多数基于全局 ID 。
    • 逻辑实例分散在多台物理主机上(超过1800台),负载均衡在物理层进行。
    • 不做读复制。
    • 尽量不做逻辑数据迁移(成本太高)。
    • 不做 JOIN 操作 (豆瓣在 QCon 上也阐述了这一点)。数据是随机分布的,关联操作反而带来了极大的复杂度。
    • 对于数据访问,主要的操作集中在最新的数据上,针对这部分做优化,旧的数据进行归档。
    • 在中心 DB 绝不存储非静态数据。
    • 使用服务或者 Memcached 进行全局查询。

 

 

Memcached 经验

参见我以前的笔记:Facebook 的 Memcached 扩展经验。Facebook 对 Memcached 做了不小的改进。另外,顺便说一下,前两天 Memcached 刚在 1.2.7 发布几天之后又发布了新版本 1.2.8,修正了一些问题。

一个比较有价值的是关于个人页面数据的获取的描述。这个就完全是需要做单页面 Benchmark 的细致活儿了,可能还需要产品经理能够理解工程师的”抵抗”。

  • 获取个人信息数据:通过Cache,隐性通过用户所在的 DB 获取(基于 User-ID 获知 DB)
  • 获取朋友连接信息:通过Cache,否则的话通过DB(基于 User-ID 获知 DB)
  • 并行抓取每个朋友的 10个照片相册 ID ,从Cache抓取,如果失效,再从 DB 抓取(基于相册 ID)
  • 并行抓取最近相册中的照片数据
  • 运行PHP 把整个业务逻辑跑出来
  • 返回数据给用户

然后是对 Facebook 非 LAMP 体系的东西做了一番介绍,基本上也开源了。最后参考两个架构图。

Facebook NewsFeed 的架构示意图

Facebook_NewsFeed_Arch.png

Facebook 搜索功能的架构示意图

Facebook_Search_Arch.png

管中窥豹,盲人摸象而已。

Facebook 如何发布代码 (How Facebook Ships Code 译文)

按:这篇 How Facebook Ships Code 提供了大量的细节信息,之前已经有朋友提供了一个翻译版本,阅读之后发现有些许错误,并且原文有更新,所以基于前面的翻译版本我重新翻译了一个(完整的)版本。一并谢过。希望这个版本对大家也有所参考。

我对 Facebook 的运作方式着迷。这是个非常独特的环境,很难被复制(这个方式并不适合所有的公司,即使有些公司尝试过这么做)。下面这些笔记来自我和Facebook的许多朋友的交谈,关于他们开发、运维与软件发布等方面。

好像很多人都对 Facebook 感兴趣… 这家公司的工程师驱动文化(Developer-driven culture)已经被公众大加研究,并且其它其它公司也在探求是否/如何实现工程师驱动文化。Facebook 的内部流程实在够神秘,当然,工程师团队也会发布一些关于新功能以及部分内部系统公开备忘,不过这些大多数是”说明”类的文章(What),而非讲述”机制”(How)… 所以,外部人员很难明白 Facebook 的创新以及如何比其它公司做到更有效的对服务进行优化。我作为外部人员尝试深入理解 Facebook 的运作,汇集了几个月来的这些观察信息。出于对信息来源的隐私保护,我去掉了特定功能/产品的名字。我又等了6个月以后才发布这些记录,所以,有些信息肯定过时了。我希望发布这些信息会有助于了解 Facebook 的管理机制如何在组织中进行决策的推行而非逐步陷入混轮…很难说这与 Facebook 的成败或是 Facebook 的产品协作相关。我相信很多面向消费者的互联网公司会从 Facebook 这个案例受益。

*非常*感谢那些帮助我整理这篇文章的 Facebook 内部的朋友们。也要感谢项 epriest 和fryfrog 这样的朋友,他们协助我进行对本文进行校正、编辑。

记录:

  • 截止到2010年6月,Facebook有将近2000名员工,10个月前只有大约1100人,一年之间差不多翻了一番!
  • 工程部和运维部是两个最大的部门,每个大概都有 400-500人。这两个部门人数大约占了公司的一半。
  • 产品经理(PM)与工程师的比例大约为1-7到1-10。
  • 每个工程师入职时,都要接受 4 到 6 周的 “Boot Camp” 培训,通过修复Bug 和听更资深的工程师的课程来熟悉 Facebook 系统。每次 Boot Camp 大约有 10% 的人无法完成课程而被淘汰。
  • 培训结束后,每个工程师都可以访问线上的数据库【标准课程”能力越大,责任越大” ( “with great power comes great responsibility”) 对此有阐释,另有一份明晰的”不可触犯的天条”,比如共享用户的隐私数据】。
  • [修改, 感谢 fryfrog] “Facebook 有非常牢靠的安全保障,以免有人(你可以想象内部有人有这个权限的)不小心/故意做了些糟糕的的事。如果你已经”成为”了需要别人支持的人,事由将被记录,并且有谨慎的审计。这里不允许钻空子。
  • 任何工程师都可以修改Facebook的代码库,签入(Check-in)代码。
  • 浓厚的工程师驱动文化。”产品经理基本可以被忽略”,这是Facebook一名员工的话。工程师可以修改流程的细节,重新安排工作任务,随时植入自己的想法。[评论] “本文的作者是一个产品经理,所以这个论断引起里我的注意。你看完整篇文章后会发现,很显然,Facebook 的文化实际上是拥抱产品经理的实践的,所以,不是产品经理的角色被忽略,而是,这家公司的文化看上去是想让”每个人”感受到对产品的责任”。
  • 在每月的跨部门会议上,由工程师来汇报工作进度,市场部和产品经理会出席会议,也可以做些简短的发言,但如果长篇大论的话,将如实反馈给他们的主管,”产品人员在上次会议说的太多”。他们确实想让工程师来主导产品的开发,对自己的产品负责。
  • 项目需要的资源都是自发征集的:
  • 某个产品经理把工程师们召集起来,让他们对自己的想法产生兴趣。
  • 工程师们决定开发那些让他们感兴趣的特性。
  • 工程师跟他们的经理说:”我下周想开发这5个新特性”。
  • 经理会让工程师独立开发,可能有时会让他优先完成一些特性。
  • 工程师独立完成所有的特性 — 前端 JavaScript/后端数据库,等等所有相关的部分。如果需要得到设计人员的帮助,需要先让设计人员对你的想法产生兴趣(专职的设计师很少)。请架构师帮忙也是如此。但总体来说,工程师要独立完成所有的任务。
  • 对于某个特性是否值得开发的争执,通常是这么解决的:花一个星期的时间实现,并在小部分用户中(如1%的内华达的用户)进行测试。
  • 工程师通常乐衷致力于架构、扩展性以及解决”难题”,那样能获得声望和尊敬。他们很难对前端项目或用户界面产生太大的兴趣。这跟其他业务为导向的公司可能正好相反,那些公司人人都想做客户能直接接触到的东西,然后会指着某个特定的用户体验说,”那是我做的”。在 Facebook,后端的东西,比如 News Feed 算法、广告投放算法、Memcache 优化等等,是工程师真正倾慕的项目。
  • News Feed 因为太重要了,扎克会亲自审查任何变动。这是个特例。
  • [更正, 感谢 epriest ]”所有的代码变更都要经过强制性的代码审查(比如一个或者多个工程师)。我相信这篇文章只是说 扎克并不自己审查每一个变更”。
  • [更正, 感谢 fryfrog ]”所有的修改至少要被一个人审查,而且这个系统可以让任何人很方便地审核其他人的代码,即使你没有邀请他。提交未经审查的代码,将被视为恶意行为”。
  • 工程师负责测试、Bug 修复以及启动对自己项目的维护。有单元测试和集成测试的框架可用,但很少使用。
  • [更正, 感谢 fryfrog ] “补充一下,我们是有 QA 的,只是没有正式的 QA 组而已。每个办公室或通过VPN连接的员工会使用下一版的 Facebook,这个版本的 Facebook 会经常更新,通常比公开的早 1-12 小时。所有的员工被强烈建议提交 Bug,而且通常会很快被修复”。
  • 回复:很奇怪只有很少的 QA 或自动测试 — “大部分工程师都能写出基本没有bug的代码,只是在其他公司他们不需要这么做。如果有 QA 部门,他们只要把代码写完,扔给他们就行了” [编辑:请注意这是很主观的,我选择包括这部分内容是因为这和那些其它公司的标准开发实践完全相反]
  • 回复:很奇怪,缺少产品经理的影响和控制 — 产品经理是很独立的和自由的。产生影响力的关键是与工程师和工程师的管理者搞好关系。需要大致了解技术,不要提一些愚蠢的想法。
  • 默认情况下,所有提交的代码每打包一次(周二)。
  • 只要多一分努力,终于一天会发生改变。
  • 星期二的代码发布,需要所有提交过代码的工程师在场。
  • 发布开始前,工程师必须在一个特定的 IRC 频道上候命,否则将会被公开问责。
  • 运维团队通过逐步滚动的方式进行代码发布:
  • Facebook 有大约 60000 台服务器。
  • 有9个代码发布级别。
  • [更正 感谢 eriest] “九个级别并非同轴的(concentric)。有三个同轴的阶段(p1=内部发布, p2=小范围外部发布, p3=完整的外部发布),其余六个阶段是辅助层,比如内部工具、视频上传主机等等”。
  • 最小的级别只有6台服务器。
  • 比如,星期二的代码发布会先发布到 6 台服务器上(第一级),运维组会观测这 6 台服务器,保证代码正常工作,然后再提交到下一级。
  • 如果发布出现了问题(如报错等等),那么就停止下一级的部署,提交出错代码的工程师负责修复问题,然后从头继续发布。
  • 所以一次发布可能会经历几次重复:1-2-3-修复,回到 1, 1-2-3-4-5-修复, 回到1, 1-2-3-4-5-6-7-8-9。
  • 运维团队受过严格训练,很受尊敬,而且极具有业务意识。他们的工作指标不止包括分析错误日志,负载和内存使用状态等等,还包括用户行为。比如,如果一个新的发布导致一定比例的用户对 Facebook 功能进行声讨,运维团队将查看相关指标,可能基于他们的调查停掉该次发布。
  • 在发布过程中,运维组使用基于 IRC 的通知系统,可以通过 Facebook、Email、IRC、IMSMS 通知每一个工程师,如果需要他们注意的话。对运维组不做回应会被公开问责。
  • 代码一旦发布到第9级,并且稳定运行,本周的发布宣告结束 。
  • 如果一个特性没有按时完成,也没什么大不了的(除非外部依赖严重),下次完成时一并发布即可。
  • 如果被 SVN-blamed(应该指没按照规范提交代码会受到的惩罚)、公开问责(Public shamed, 示众?还是通告批评?)或工作经常疏忽就很可能被开除。”这是一个高效的文化”。不够高效或者不够聪明的员工会被剔除。管理层会在 6 个月的时间里观察你表现,”你不能适应这种文化,只能说再见”。每一级都是这个待遇,即使是 C 级别和 VP 级别,如果不够高效,也会被开除。
  • [更正, 感谢 epriest ] “人们不会因为导致 Bug 而被解雇,只有在发布他们的代码时导致问题,而他们恰恰又不在场(也找不到其他可以替代的人)”。
  • [更正, 感谢 epriest] “被问责不会导致解雇。我们特别尊重别人,原谅别人。大部分高级工程师都或多或少犯过一些严重的错误,包括我。但没有人因此被解雇”。
  • [更正, 感谢 fryfrog] “我也没有遇到过因为上面提到过的犯错而被解雇。我知道有人不小心将整个网站宕掉过。一旦有人犯错,他们会竭尽全力修复问题,也让其他人得到了教训。就我来看,这种公然蒙羞与被解雇的恐惧相比更为奏效”。

分析 Facebook 的研发文化如何随着时间演化是件非常有趣的事。特别是当公司发展壮大到数千员工的时候,这种文化是否还能够延续?

你觉得如何?在你公司里,”开发者驱动(developer-driven)文化” 将会可行么?

 

译者后记:很多时候是管中窥豹也是非常有趣的,而且,应该细致一点儿。另外,或许我们更应该关注为什么 Facebook 能够形成这样的文化。你说呢?

译者后记续:Facebook 能形成工程师主导的文化,应该和 Facebook 的产品形态有很大关系。毕竟 Facebook 人人都会用 Facebook … 换言之,如果是 Amazon / eBay 这样面向商业的用户的公司,业务逻辑会让工程师陷入五里雾中。

[转自51cto]21个免费UI

来自51CTO的文章,本文将介绍一些UI界面与设计使用的元素、软件和网站。内容很丰富,适合用户体验设计师、界面设计师、产品设计师、JS前段开发、手机产品设计以及iPad和平板电脑产品设计等使用。

Lumzy

官方地址:http://www.lumzy.com/

Lumzy是一个网站应用和原型界面制作工具。使用Lumzy,您可以轻松创建UI模型并即时发送到客户电脑中。 Lumzy还具有团队协作编辑工具。

Lumzy

Mockingbird

官方地址:https://gomockingbird.com/

Mockingbird(中文名:百舌鸟)是一个在线工具,它使您轻松地创建UI界面模型,预览UI,并可以共享你的版面编排效果图。

Mockingbird

The Pencil Project

官方地址:http://pencil.evolus.vn/en-US/Home.aspx

为设计图表和用户界面图形原型开发的一个自由和开源工具。

The Pencil Project

Dojo

官方地址:http://dojotoolkit.org/

Dojo提供了强大的性能并节省您的时间。这是适合经验丰富前端开发者的JS开发工具包。

Dojo

Mocklinkr

官方地址:http://www.mocklinkr.com/

自定义排版托管工具Mocklinkr,让你不用再担心没有漂亮版面

Mocklinkr

MockFlow

官方地址:http://www.mockflow.com/signup/

MockFlow是一个在线工具,用户界面设计和协作版面编排工具。

MockFlow

Serena Prototype Composer

官方地址:http://www.serena.com/products/prototype-composer/index.html

Serena Prototype Composer是制作流程图,模拟程序流程和用户界面设计程序。

Serena Prototype Composer

Cacoo

官方地址:http://cacoo.com/

Cocoo是一个用户友好的在线绘图工具,允许你创建一个如网站地图,线框,UML和网络图图等。 Cacoo可以免费使用。

Cacoo

DENIM

官方地址:http://dub.washington.edu:2007/denim/

一个早期非正式的网站和用户界面设计工具

DENIM

Hot Gloo

官方地址:http://www.hotgloo.com/

网上应用线框

Hot Glo

User Interface Design Framework

官方地址:http://www.webalys.com/design-interface-application-framework.php

一个免费提供网页设计师使用的用户界面设计工具。

User Interface Design Framework

Pattern Tap

官方地址:http://patterntap.com/

可以寻找一些设计资源与模式等。

Pattern Tap

User Interface Design Patterns

官方地址:http://ui-patterns.com/

提供一些热门的用户UI界面设计模式参考图,分类很详细,如果设计网站或UI界面可以上去找一些资源,很不错。

User Interface Design Patterns

Patternry

官方地址:http://patternry.com/

Patternry是用户界面设计模式库的目的是帮助解决常见的接口设计问题。

Patternry

Mephobox

官方地址:http://box.mepholio.com/

UI设计界面资源欣赏参考网站。

Mephobox

Android Asset Studio

官方地址:http://android-ui-utils.googlecode.com/hg/asset-studio/dist/icons-launcher.html

可以在线生成图表,只需要输入参数即可

Android Asset Studio

Mobility

官方地址:http://www.fullcreative.com/2010/10/mobility-a-free-set-of-mobile-ui-design-elements/

移动用户界面设计使用,可以输入参数进行测试,很方便

Mobility

Android UI Elements Set

官方地址:http://www.webdesignshock.com/freebies/free-photoshop-android-interface-gui/

可以自由设定Android操作系统的用户界面元素。

Android UI Elements Set

OSX Leopard GUI Set

官方地址:http://www.tutorialshock.com/freebie/mac-osx-leopard-gui-set/

该软件包含一些常用的Photoshop原文件和PNG文件,这些元素都是用来设计GUI界面的素材,通过该软件你可以快速制作出一些出色的界面

ALL In One Web Elements Kit

官方地址:http://bestblogbox.com/freebies/all-in-one-web-elements-kit/

网页布局元素大集合,PSD文件。

ALL In One Web Elements Ki

iPad GUI Set

官方地址:http://www.teehanlax.com/blog/2010/02/01/ipad-gui-psd/

iPad平板电脑上设计布局用的元素集合。

iPad GUI Set

本文转载自: 51CTO

 

this isn’t a Hello World blog

好吧,终于还是挥挥小手告别Spaces啦,转眼5年后又回到WP,发现现在竟然是中文了。先用着吧。

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!