硕鼠的博客站

现在，有越来越多的应用，或服务商，都在做、或是想做图片服务了。几个月之前，还不是这个样子的。那个时候由于图片圈子的老大，Flickr那半死不活的生存状态，使得很多希望去做图像的团队，都望而却步了。更是有一些做图像的团队，被投资人扫地出门。

这一切，随着instagram的成功，而发生了翻天覆地的变化。又有很多的人开始想来做图片的相关应用了。

为什么会出现这样的故事呢？

图片应用，或图片服务，其天然存在着很多的不同于其他类型应用服务模式的特殊性：
• 图片的容量决定了，图片比普通的文字信息消耗更大的资源，不论是存储还是带宽。
  • 外链被所有的图片网站又爱又恨，没有外链的话，网站的吸引力和黏着度都上不去，打开外链的话，对于带宽又会带来巨大的压力。
• 盈利模式模糊不清，也是图片网站永远的痛，现在常见的收费方式有三种，但是好像都很难达到收支平衡甚至盈利：
  • 免费，这种方式的网站是靠广告收入存活的。
  • 向照片所有者收取存储费用——picasa和flickr都是这么做的。
  • 向照片使用者收费，有些提供高质量广告素材的网站是这么存活的。
• 图片本身的索引和检索，再利用不是很方便
  • 所有主流的搜索引擎都提供了图片搜索功能
  • 但是这些搜索引擎都是按照引用图片的那个网页的内容来进行搜索的
  • 网页描述不一定准确，很多网站为了提高或降低搜索命中率，对seo进行优化，导致图片的搜索的准确性进一步的降低
• 图片的再利用不是很方便
  • 大家需要图片的目的是不一样的：

• 需要图片来修饰网站或其他视觉界面
• 需要图片来增强文字或其他内容的说服力和表现力
• 需要图片来辨认地标建筑或联系人

•  
  • 不同用途的图片，被分门别类的存放在不同的网站中
  • 一张图片，特别是照片，如果想要用于不同的用途，这将非常困难。比如，想要把一张照片上的人像抠出来，作为联系人的头像来用，现在Google倒是提供了类似的功能，遗憾的是Picasaweb的网站被墙了，我们很难访问到了。如果有人想要将某张照片中的一部分抠出来作为网站上图标来使用，那就需要专业人士来帮忙了。
  • 这些照片被利用的过程没有被记录下来，很多人需要重复的去处理同一张照片，做同样的事情。
• 我们处在一个最不适合做图片服务的地区，要为那些最不适合享受这项服务的用户群体来提供图片服务。
  • 天朝的网络布局非常不合理，很多资源访问起来的速度，比在国外网站上还慢。
  • 本来一个大型IDC机房就能够解决的问题，现在却必须要建立一大堆的CDN才能完成。图片服务上的内容，还是动态的，不那么容易进行CDN分发。
  • 网络上流行一句话，叫做有图有真相。但是通常，人们自己并不知道他们是否具备了了解某些特定真相所需的智慧，很多真相在公布之前，还需要先由有关部门来判断一下，如果不是那么容易理解的，那就还是不要公布了，免得大家理解出了偏差。

图片服务，说白了就是做三件事情：原始素材的保存和整理；图片的检索和发现；图片的再利用。

在这个过程中，应该考虑几个问题。

在进行自有图片的保存和组织的时候，内容是以图片所有者为中心聚集起来的。然后再以图片所有者的事件和时间、地点为辅助标记进行组合。最后，如果有可能的话，才会有图片所有者或其他人添加的标记，或者是自动人脸识别，以及其他机器识别所辨认出的可识别内容。这主要是因为，我们现在都是使用的数码相机，在一次旅游或其他什么活动的过程中，总是会产生大量的照片，但是，会被做标记的，可能只是很少的一部分。而计算机的智能图片识别系统，现在也还很难让人满意的识别出照片上的各种东西。这些内容会随着图片所有者自身的社交关系图来流转。

图片的检索和发现，是一个很麻烦的问题。用户在检索的时候，输入的总是一些文字信息。将其所想象的图片需求，用文字表达出来，这本身就是一件非常困难的事情。大家除了能够依靠社交关系，看到一些好友或好友的好友的图片之外，想要自己去找到所需的一些图片，这对于现有的系统来说还是一种艰巨的挑战。

图片的再利用，也就是图片所有者，或其他得到允许的人，对于这些图片的再次利用。将这些图片，进行再加工，并根据需要发布到各种平台上去。比如，转帖到自己的博客中去，或发布到微博，或作为网站资源，粘贴到其他网站，也可以是再去印刷、做其他用途等等。

图片服务，应该还是会有很多种，能够在这块市场上成功的机会的。关键是要认真的研究，自己到底是要为什么人，或什么应用模式来服务。另外，在这个地方，图片服务，真的不太适合那些创业小团队来做，启动成本太高。

这是图片故事的第一篇，下面还想说说我设想的一些图片服务模式。

随着社会的进步，高楼大厦林立于市区，社会分工也越来越详细了。不论是游船还是后面的大厦，都不是一个人、一个团队、一个公司，甚至是一个行业可以完成的。越来越多的标准件被应用到了这些东西的建造和运维之中。

同样，随着软件应用的规模不断的扩大，一个人或一个团队从头开始编写完整的程序已经变得越来越难了，而且这样做也非常的不经济。于是有一种东西就进入了程序员们的世界，那就是框架，各种各样的框架。

框架通常是一个很庞大的代码库，由一个公司或一些团队完成。使用特定的语言编写，可以在特定的领域中解决一定的问题。其他程序员使用这些框架，在框架相应的领域中，可以更简单的，更直观的解决和处理该框架所涵盖的问题。

框架设计的目的，通常有这么几点：

对复杂的底层进行封装，使得这一部分可以完全对程序员透明，程序员可以通过这些框架，直接使用底层的功能，而不需要了解底层的细节。

对复杂的业务逻辑进行封装，使得程序员可以使用更加接近自然语言的方式，来构建全新的业务逻辑，满足复杂的企业需求。

对一些容易出错的内容进行封装，让程序员能够按照特定的规范来调用其他的模块、或使不同程序员或团队写出来的代码可以更好的协同工作。

对于不同工种与工序进行划分，便于不同的工种和工序之间进行并行工作和协作。尽可能的对参与同一项目的不同工种和工序进行分割和隔离。使得这些工种和工序，可以独立的进行修改和调整，尽量少的影响到其他的相关环节。对于现在的应用来说，美工和程序员之间的这种协调就是非常常见的，而且这也让很多团队感到非常的头疼。很多框架就是解决类似问题的，可以让美工修改资源的时候，尽量不影响代码。让程序员修改的代码的时候也可以尽可能少的影响美工的工作。另外一个经常和程序员打交道的就是策划了，如果让程序去适应复杂多变的策划，也是很多程序框架试图解决的问题。

对同一类型或有相同使用背景的应用进行规范化，并利于这些应用进行统一的展示、安装、卸载以及信息通讯的框架，很多portal框架都是这么做的，这种框架应用的成功体现就是AppStore了。

既然框架这么好，能够解决这么多的问题。那么为什么本文的标题不是“框架之美”，而是“程序员与框架之间的战斗”呢？

通常一个程序员接触框架的过程是这样的：

接到一个困难的工作，使用原来的手段无法完成或很难在可以接受的时间内，提交满足需要的成果。于是必须使用一个框架了。为了框架而框架的情况是存在的，但是这里不推荐那么做。这个时候，程序员会去网上搜索，去搜寻各种信息，并在浩如烟海的框架中选择一个他认为最适合的框架来使用。悲剧的是，有时候这种选择并不是由技术人员，在清醒的状态下做出的，J2EE就是这么一个看上去很美的错误。

选择了框架之后，并不是马上就能够开始干活儿的，框架虽然对很多东西进行了封装，使其尽可能的变得简单。但不可否认，通常的框架本身也还是很复杂的。要想熟练的使用框架来完成所需要的工作，还是需要有一定的学习过程的。

在学习之后，就是使用框架来解决问题。这个时候，可能就会发现，当初选择的框架并不那么好用，并不是那么贴近自己的应用需要。这种情况通常是由四方面的原因造成的：

第一：对于框架的学习不够彻底和深入，那些适合本次应用的功能没有被发现，以现在框架的复杂程度、同类框架的数量和文档的粗糙程度来看，这很正常；

第二：设计框架的人和当前的程序员在编程习惯方面不是非常相符，使用框架的程序员又非常的固执，众所周知，程序员通常都是很固执的，甚至有些还很偏执；

第三：框架设计的时候，所考虑的覆盖范围，和现在所需要实现的应用有些偏差，或者是框架已经跟不上时代的进步，不能适应当前的情况了；

第四：程序员过于的完美主义，这也是程序员，特别是成功程序员比较典型的一种性格特征。

有些应用还有可能会因为使用了过度的框架和不合适的框架，而变得面目全非。

于是下一个阶段就是对框架进行改造。对于商业框架就提意见，希望能够得到修改。对于开源框架，那就简单了，直接可以进行修改。

然后，程序员会继续使用这些用起来越来越得心应手的框架，去做各种合适或者不合适的事情。经过了不断的修改和调整之后，一个个历史悠久的、有生命力的框架也都向着越来越全面化的方向发展。这个时候，他们就忘记了，框架其实是为了实现某些特定功能而设计的。

即使再全能的框架，也总有一些不适合去实现的功能。不过程序员们是执着的，当他们对一个框架的喜好程度发展到热爱甚至是痴迷的时候，他们是不理智的，甚至是不可理喻的。爱情使人变成白痴，这句话用在这里也是合适的。毕竟一个框架，日夜陪伴着程序员，程序员们学习和了解框架；使用框架攻克难关，完成任务；这些框架还会为程序员做出各种各样的改变，以实用程序员的习惯。这种过程其实和恋爱中的男女相处的过程很像的，那么程序员对于框架产生出一些超出友谊的感情也是很正常的。于是就会出现这样一种情况，一些程序员会使用他们所钟爱的框架，去完成一些该框架本身完全不适合的工作。

即使这看起来很不协调，但是程序员们也会坚持去这样做的。

最终，很多程序员会选择抛弃框架，或者不得不抛弃以前那些笨重的框架，重新去选择一些轻量级的东西，甚至干脆自己开发框架来使用。但是这些框架最终也逃脱不了上面那些框架的命运，会变得越来越庞大的，最终再被抛弃。毕竟维护一个框架的成本也是很高的。有些公司由于一个框架而得到了成功，最终也由于那个框架，走向了消亡。框架是很难与时俱进的，通常情况下，框架是只能做加法，很难做减法的。毕竟框架的升级是需要考虑向下兼容性问题的，如果从框架中做了减法，那么就意味着以前的应用，在升级使用新框架的时候，有一部分无法正常工作。

现在还有很多高级程序员，更喜欢裸奔。

这就是战斗了，裸奔和框架之间的战斗。框架和框架之间的战斗。那么程序员们到底应该如何面对框架呢？特别是在自己也开发了框架，或者至少是自己对现已有框架非常熟悉，并且熟悉到分不清自我的情况下，应该如何面对其他框架呢？

建议大家，在需要的时候，选择需要的框架。框架的使用也是有成本的，请选择成本最优的方式，来判断是否需要使用框架，以及应该使用什么样的框架。如果是一个周期很长，即使使用了框架也需要进行大量工作的任务，那么就千万不要去选择那些不了解、不熟悉或学习成本很高的框架。因为，所有框架都有一个特性，那就是易学难精。如果有些框架不需要很深入的了解，就能够很好的完成当前的应用，那么请毫不犹豫的选择使用这些框架。毕竟这样可以使应用的开发周期极大的缩短。尽量不要去选择那些包打天下、包治百病的框架，这种东西通常是很臃肿的，而且这种东西一旦遇到了不擅长的领域，会让大家非常难以取舍。不要去选择那些很难进行调整和修改的框架，这种东西很可能会因为一点点的不契合，就让你不得不放弃它，但这个时候随着框架一起被放弃掉的，很可能是整个团队在该框架上付出的巨大努力和海量代码。在选择框架的时候，首先要确定这个框架还有人维护，还有很多人在用，网上有足够多的资源，能够帮助你和你的团队度过开始的学习期，也能够在遇到困难的时候，很容易的找到网上的先辈们来帮忙。如果团队中的大部分人都熟悉一个框架，那么即使现在的框架并不是完全适合当前的需要，最好也是直接在现有框架的基础上进行小的调整，而不是去找个新的来。实际上完全符合需要的情况基本上是不存在的。当然，如果实在是相差太远的话，那也就不要太坚持，有时候换一个会更好一些的。

程序员与框架之间的战斗，归根结底还是一个度的把握问题。到底能不能将这个度把握好，做出正确的判断和取舍，决定了程序员是不是能够战胜框架，征服框架，并和框架一起再去战胜应用。希望以后大家能够在和框架的战斗中得到美妙的享受。就像男人和女人的战斗一样。

使用互联网的时间越来越长，中间沧海变桑田，发生了很多的变化。很多以前能用的服务，后来不能用了。有些后来又开放了，但是最后还是被关闭了。

这导致了我在四处注册了各种各样的信息发布服务。每个地方，都有那么三五个人在关注我，为了将推送的信息发布到所有地方，我也费了不少的劲，中间使用过ping.fm，后来这个东西也被墙了。还用过weiboto.com，这个东西总是时灵，时不灵，而且gtalk机器人的故障率很高。我喜欢在gtalk里面发送东西，但是现在主要的推送出口切客网，还没有gtalk机器人的功能，实在是让我失望，希望他们能够尽快的补上吧。

我现在的信息发布路径，见下图：

当我发布一条信息的时候，首先要分类，看看是一条什么样的信息。然后按照各自的分支，尽可能发送到所有的地方。

现在，比较遗憾的是，所有这些信息，推送出去之后的回复和反馈，没法在一个地方收集起来，统一处理。另外，就是我的人间账户，已经很长时间没有去了。现在切客还无法同步到人间。

我也不想把事情搞得这么复杂，有些东西确实是历史遗留问题，没有办法啊。

信息发布路径以后可能还会发生变化，谁知道以后会怎么样呢。

如果有人也要设计信息发布路径，建议大家尽量采用那些可靠的大公司服务作为核心节点，尽量把信息发送路径设计成星形，有些实在到达不了的，再设计链型。这样能够最大的避免信息漏发和重发之类的事情。