1 月 19
Luke Fan梦想园 互联网, 梦想园, 梦想园
现在，有越来越多的应用，或服务商，都在做、或是想做图片服务了。几个月之前，还不是这个样子的。那个时候由于图片圈子的老大，Flickr那半死不活的生存状态，使得很多希望去做图像的团队，都望而却步了。更是有一些做图像的团队，被投资人扫地出门。
这一切，随着instagram的成功，而发生了翻天覆地的变化。又有很多的人开始想来做图片的相关应用了。
为什么会出现这样的故事呢？
- 需要图片来修饰网站或其他视觉界面
- 需要图片来增强文字或其他内容的说服力和表现力
- 需要图片来辨认地标建筑或联系人
-
- 不同用途的图片，被分门别类的存放在不同的网站中
- 一张图片，特别是照片，如果想要用于不同的用途，这将非常困难。比如，想要把一张照片上的人像抠出来，作为联系人的头像来用，现在Google倒是提供了类似的功能，遗憾的是Picasaweb的网站被墙了，我们很难访问到了。如果有人想要将某张照片中的一部分抠出来作为网站上图标来使用，那就需要专业人士来帮忙了。
- 这些照片被利用的过程没有被记录下来，很多人需要重复的去处理同一张照片，做同样的事情。
- 我们处在一个最不适合做图片服务的地区，要为那些最不适合享受这项服务的用户群体来提供图片服务。
- 天朝的网络布局非常不合理，很多资源访问起来的速度，比在国外网站上还慢。
- 本来一个大型IDC机房就能够解决的问题，现在却必须要建立一大堆的CDN才能完成。图片服务上的内容，还是动态的，不那么容易进行CDN分发。
- 网络上流行一句话，叫做有图有真相。但是通常，人们自己并不知道他们是否具备了了解某些特定真相所需的智慧，很多真相在公布之前，还需要先由有关部门来判断一下，如果不是那么容易理解的，那就还是不要公布了，免得大家理解出了偏差。
图片服务，说白了就是做三件事情：原始素材的保存和整理；图片的检索和发现；图片的再利用。
在这个过程中，应该考虑几个问题。
在进行自有图片的保存和组织的时候，内容是以图片所有者为中心聚集起来的。然后再以图片所有者的事件和时间、地点为辅助标记进行组合。最后，如果有可能的话，才会有图片所有者或其他人添加的标记，或者是自动人脸识别，以及其他机器识别所辨认出的可识别内容。这主要是因为，我们现在都是使用的数码相机，在一次旅游或其他什么活动的过程中，总是会产生大量的照片，但是，会被做标记的，可能只是很少的一部分。而计算机的智能图片识别系统，现在也还很难让人满意的识别出照片上的各种东西。这些内容会随着图片所有者自身的社交关系图来流转。
图片的检索和发现，是一个很麻烦的问题。用户在检索的时候，输入的总是一些文字信息。将其所想象的图片需求，用文字表达出来，这本身就是一件非常困难的事情。大家除了能够依靠社交关系，看到一些好友或好友的好友的图片之外，想要自己去找到所需的一些图片，这对于现有的系统来说还是一种艰巨的挑战。
图片的再利用，也就是图片所有者，或其他得到允许的人，对于这些图片的再次利用。将这些图片，进行再加工，并根据需要发布到各种平台上去。比如，转帖到自己的博客中去，或发布到微博，或作为网站资源，粘贴到其他网站，也可以是再去印刷、做其他用途等等。
图片服务，应该还是会有很多种，能够在这块市场上成功的机会的。关键是要认真的研究，自己到底是要为什么人，或什么应用模式来服务。另外，在这个地方，图片服务，真的不太适合那些创业小团队来做，启动成本太高。
这是图片故事的第一篇，下面还想说说我设想的一些图片服务模式。
1 月 07
Luke Fan杂谈, 随笔 框架, 程序员
随着社会的进步，高楼大厦林立于市区，社会分工也越来越详细了。不论是游船还是后面的大厦，都不是一个人、一个团队、一个公司，甚至是一个行业可以完成的。越来越多的标准件被应用到了这些东西的建造和运维之中。
同样，随着软件应用的规模不断的扩大，一个人或一个团队从头开始编写完整的程序已经变得越来越难了，而且这样做也非常的不经济。于是有一种东西就进入了程序员们的世界，那就是框架，各种各样的框架。
框架通常是一个很庞大的代码库，由一个公司或一些团队完成。使用特定的语言编写，可以在特定的领域中解决一定的问题。其他程序员使用这些框架，在框架相应的领域中，可以更简单的，更直观的解决和处理该框架所涵盖的问题。
框架设计的目的，通常有这么几点：
对复杂的底层进行封装，使得这一部分可以完全对程序员透明，程序员可以通过这些框架，直接使用底层的功能，而不需要了解底层的细节。
对复杂的业务逻辑进行封装，使得程序员可以使用更加接近自然语言的方式，来构建全新的业务逻辑，满足复杂的企业需求。
对一些容易出错的内容进行封装，让程序员能够按照特定的规范来调用其他的模块、或使不同程序员或团队写出来的代码可以更好的协同工作。
对于不同工种与工序进行划分，便于不同的工种和工序之间进行并行工作和协作。尽可能的对参与同一项目的不同工种和工序进行分割和隔离。使得这些工种和工序，可以独立的进行修改和调整，尽量少的影响到其他的相关环节。对于现在的应用来说，美工和程序员之间的这种协调就是非常常见的，而且这也让很多团队感到非常的头疼。很多框架就是解决类似问题的，可以让美工修改资源的时候，尽量不影响代码。让程序员修改的代码的时候也可以尽可能少的影响美工的工作。另外一个经常和程序员打交道的就是策划了，如果让程序去适应复杂多变的策划，也是很多程序框架试图解决的问题。
对同一类型或有相同使用背景的应用进行规范化，并利于这些应用进行统一的展示、安装、卸载以及信息通讯的框架，很多portal框架都是这么做的，这种框架应用的成功体现就是AppStore了。
既然框架这么好，能够解决这么多的问题。那么为什么本文的标题不是“框架之美”，而是“程序员与框架之间的战斗”呢？
通常一个程序员接触框架的过程是这样的：
接到一个困难的工作，使用原来的手段无法完成或很难在可以接受的时间内，提交满足需要的成果。于是必须使用一个框架了。为了框架而框架的情况是存在的，但是这里不推荐那么做。这个时候，程序员会去网上搜索，去搜寻各种信息，并在浩如烟海的框架中选择一个他认为最适合的框架来使用。悲剧的是，有时候这种选择并不是由技术人员，在清醒的状态下做出的，J2EE就是这么一个看上去很美的错误。
选择了框架之后，并不是马上就能够开始干活儿的，框架虽然对很多东西进行了封装，使其尽可能的变得简单。但不可否认，通常的框架本身也还是很复杂的。要想熟练的使用框架来完成所需要的工作，还是需要有一定的学习过程的。
在学习之后，就是使用框架来解决问题。这个时候，可能就会发现，当初选择的框架并不那么好用，并不是那么贴近自己的应用需要。这种情况通常是由四方面的原因造成的：
第一：对于框架的学习不够彻底和深入，那些适合本次应用的功能没有被发现，以现在框架的复杂程度、同类框架的数量和文档的粗糙程度来看，这很正常；
第二：设计框架的人和当前的程序员在编程习惯方面不是非常相符，使用框架的程序员又非常的固执，众所周知，程序员通常都是很固执的，甚至有些还很偏执；
第三：框架设计的时候，所考虑的覆盖范围，和现在所需要实现的应用有些偏差，或者是框架已经跟不上时代的进步，不能适应当前的情况了；
第四：程序员过于的完美主义，这也是程序员，特别是成功程序员比较典型的一种性格特征。
有些应用还有可能会因为使用了过度的框架和不合适的框架，而变得面目全非。
于是下一个阶段就是对框架进行改造。对于商业框架就提意见，希望能够得到修改。对于开源框架，那就简单了，直接可以进行修改。
然后，程序员会继续使用这些用起来越来越得心应手的框架，去做各种合适或者不合适的事情。经过了不断的修改和调整之后，一个个历史悠久的、有生命力的框架也都向着越来越全面化的方向发展。这个时候，他们就忘记了，框架其实是为了实现某些特定功能而设计的。
即使再全能的框架，也总有一些不适合去实现的功能。不过程序员们是执着的，当他们对一个框架的喜好程度发展到热爱甚至是痴迷的时候，他们是不理智的，甚至是不可理喻的。爱情使人变成白痴，这句话用在这里也是合适的。毕竟一个框架，日夜陪伴着程序员，程序员们学习和了解框架；使用框架攻克难关，完成任务；这些框架还会为程序员做出各种各样的改变，以实用程序员的习惯。这种过程其实和恋爱中的男女相处的过程很像的，那么程序员对于框架产生出一些超出友谊的感情也是很正常的。于是就会出现这样一种情况，一些程序员会使用他们所钟爱的框架，去完成一些该框架本身完全不适合的工作。
即使这看起来很不协调，但是程序员们也会坚持去这样做的。
最终，很多程序员会选择抛弃框架，或者不得不抛弃以前那些笨重的框架，重新去选择一些轻量级的东西，甚至干脆自己开发框架来使用。但是这些框架最终也逃脱不了上面那些框架的命运，会变得越来越庞大的，最终再被抛弃。毕竟维护一个框架的成本也是很高的。有些公司由于一个框架而得到了成功，最终也由于那个框架，走向了消亡。框架是很难与时俱进的，通常情况下，框架是只能做加法，很难做减法的。毕竟框架的升级是需要考虑向下兼容性问题的，如果从框架中做了减法，那么就意味着以前的应用，在升级使用新框架的时候，有一部分无法正常工作。
现在还有很多高级程序员，更喜欢裸奔。
这就是战斗了，裸奔和框架之间的战斗。框架和框架之间的战斗。那么程序员们到底应该如何面对框架呢？特别是在自己也开发了框架，或者至少是自己对现已有框架非常熟悉，并且熟悉到分不清自我的情况下，应该如何面对其他框架呢？
建议大家，在需要的时候，选择需要的框架。框架的使用也是有成本的，请选择成本最优的方式，来判断是否需要使用框架，以及应该使用什么样的框架。如果是一个周期很长，即使使用了框架也需要进行大量工作的任务，那么就千万不要去选择那些不了解、不熟悉或学习成本很高的框架。因为，所有框架都有一个特性，那就是易学难精。如果有些框架不需要很深入的了解，就能够很好的完成当前的应用，那么请毫不犹豫的选择使用这些框架。毕竟这样可以使应用的开发周期极大的缩短。尽量不要去选择那些包打天下、包治百病的框架，这种东西通常是很臃肿的，而且这种东西一旦遇到了不擅长的领域，会让大家非常难以取舍。不要去选择那些很难进行调整和修改的框架，这种东西很可能会因为一点点的不契合，就让你不得不放弃它，但这个时候随着框架一起被放弃掉的，很可能是整个团队在该框架上付出的巨大努力和海量代码。在选择框架的时候，首先要确定这个框架还有人维护，还有很多人在用，网上有足够多的资源，能够帮助你和你的团队度过开始的学习期，也能够在遇到困难的时候，很容易的找到网上的先辈们来帮忙。如果团队中的大部分人都熟悉一个框架，那么即使现在的框架并不是完全适合当前的需要，最好也是直接在现有框架的基础上进行小的调整，而不是去找个新的来。实际上完全符合需要的情况基本上是不存在的。当然，如果实在是相差太远的话，那也就不要太坚持，有时候换一个会更好一些的。
程序员与框架之间的战斗，归根结底还是一个度的把握问题。到底能不能将这个度把握好，做出正确的判断和取舍，决定了程序员是不是能够战胜框架，征服框架，并和框架一起再去战胜应用。希望以后大家能够在和框架的战斗中得到美妙的享受。就像男人和女人的战斗一样。
1 月 04
Luke Fan杂谈, 随笔 微博, 社区
使用互联网的时间越来越长，中间沧海变桑田，发生了很多的变化。很多以前能用的服务，后来不能用了。有些后来又开放了，但是最后还是被关闭了。
这导致了我在四处注册了各种各样的信息发布服务。每个地方，都有那么三五个人在关注我，为了将推送的信息发布到所有地方，我也费了不少的劲，中间使用过ping.fm，后来这个东西也被墙了。还用过weiboto.com，这个东西总是时灵，时不灵，而且gtalk机器人的故障率很高。我喜欢在gtalk里面发送东西，但是现在主要的推送出口切客网，还没有gtalk机器人的功能，实在是让我失望，希望他们能够尽快的补上吧。
我现在的信息发布路径，见下图：
当我发布一条信息的时候，首先要分类，看看是一条什么样的信息。然后按照各自的分支，尽可能发送到所有的地方。
现在，比较遗憾的是，所有这些信息，推送出去之后的回复和反馈，没法在一个地方收集起来，统一处理。另外，就是我的人间账户，已经很长时间没有去了。现在切客还无法同步到人间。
我也不想把事情搞得这么复杂，有些东西确实是历史遗留问题，没有办法啊。
信息发布路径以后可能还会发生变化，谁知道以后会怎么样呢。
如果有人也要设计信息发布路径，建议大家尽量采用那些可靠的大公司服务作为核心节点，尽量把信息发送路径设计成星形，有些实在到达不了的，再设计链型。这样能够最大的避免信息漏发和重发之类的事情。
1 月 04
Luke Fan杂谈
DSC_0005
原由 Luke Fan 上載
儿子在不断的长大，现在已经快5岁了。
随着他活动能力的增强，家里的混乱程度也在随之上升。
过元旦这几天，儿子在发烧，我们什么地方都没去成。虽然生病了，但是他的活动能力并没有明显的下降。
晚上好不容易安静一会儿，被我拍了下来。
这是泡在他专用的实木洗脚盆里面，捧着一杯热水，穿着棉衣正在发汗呢。
截止到这篇文博客发布，烧已经退了，就是还有些咳嗽，估计这个礼拜的幼儿园又去不了了。
12 月 24
Luke Fan杂谈 AppStore, Bambook, 开放平台
-
Bambook的架构
作为老牌电子阅读服务提供商，盛大今年新发布的电子阅读器，Bambook的体系架构和传统的电子阅读器是有很大差异的。
传统的电子阅读器，大概可以分为两种架构：
第一种：封闭的内容服务体系，这种架构有自己的内容分发服务器，独立的、只能连接自己服务器的PC端软件，以及只能连接自己服务器的电子阅读器；
第二种：裸设备体系，这种架构只提供电子阅读器，内容和所有其他服务，靠用户自己处理。
Bambook提供的则是一套开放的内容服务体系：
有专门为Bambook提供内容支撑的云中书城服务器集群；
有开放的，可以扩展各种插件的PC端软件；
还有开放的，可以进行订制开发的Bambook电子阅读器；
最神奇的是，bambook还为那些插件提供了一个开放的认证和计费服务体系。
那些开发插件的人或公司，完全可以通过为bambook开发插件，运营插件以及插件相关的内容，来赚取利润，自给自足。那些做得好的，受欢迎的插件作者，甚至可以靠此创业。
-
Bambook上的内容
Bambook上的内容，本身就是非常丰富的。现在云中书城中已经有近400万本各类图书，还有一百多万人，在为云中书城下的各个文学站点写作内容，他们每天更新1亿字。云中书城下的各个文学站点，目前已经累计了超过一亿个读者。
一百万人写，一亿人读，这就是互联网神奇的地方。通过互联网，通过云中书城，这一百万作者找到了他们的读者；而这一亿读者，也找到了他们所喜欢的内容。通过云中书城下各个文学站点近十年的发展，盛大认识到一个问题，人的阅读需要总是千差万别的，一亿人，就会有一亿种不同的阅读需要。即使准备再多的内容，也不可能覆盖所有种类的内容，更不可能满足所有人的阅读需要。
-
开放的内容平台
想要容纳所有的内容，并满足所有人的阅读需要，这是不现实的，是不可能完成的任务。但是尽量囊括更多的内容，尽可能满足更多人的阅读需求，这还是一个可以追寻的目标。
要想向着这个远大的目标前进，单靠一家公司肯定是不行的。
只有将平台开放，让任何一个愿意提供内容的公司、团队或个人，都能够很简单的将他们的内容通过Bambook输出出去，这才是解决问题的方法。
Bambook首先将PC客户端开放出来，现在已经有了大批的插件，可以让人们阅读到不同的内容，阅读到那些云中书城中现在还不包含的内容。
-
无限的插件，等于无限的内容
下面来看看都有哪些插件，可以让大家阅读到更多的内容。
首先就是Bambook Google Reader 同步工具
自动将 Google Reader 上订阅的内容生成电子书并下载到 Bambook 上。
1. 所有功能一键式操作
2. 支持全文内容下载、支持图片下载
3. 支持使用 Wifi 连接 Bambook
4. 支持按分类或订阅频道分别生成电子书
5. 可将加星标、喜欢、共享等内容生成单独的收藏集
6. 支持 https 加密
Google Reader是一个非常有趣的应用，提供了一种简单的进行RSS订阅内容整合的方式。现在，通过这个插件，可以直接将Google Reader上订阅的内容，导入到Bambook中。
对于那些喜欢漫画的朋友，下面这个插件肯定是非常棒的：
锦书搜漫是一个可以直接将互联网上的漫画，打包下载，再根据bambook的特性进行优化之后，将其传入bambook中的工具。大家使用这个工具，就可以直接在bambook上看漫画了。
作者：焦常云 来自 个人参赛选手
这个作者自己写的简介非常有趣，在这里和大家分享一下：
作者介绍
成家的男人，追求立业中…… QQ 1643239584
有兴趣的人，也可以直接联系这位作者，看看能不能有一些不一样的收获。
这位作者还开发了另外几个插件：
锦书读博
一个可以将博客同步到bambook上进行阅读的工具 |
爱电影爱英语
跟着好莱坞电影、热门美剧的字幕一起学英语吧！程序能把多语种(中英)字幕，按照时间重新排列，达到一行英文一行中文的效果，让您方便的从字幕中学习英语，借助BB朗读练习听力更是给力
|
现在还有很多其他插件，可以整合其他的各种内容，例如：
这只是其中的很少一部分，还有更多的插件在不断的被开发出来，即使已经可以下载的插件，也在不断的更新之中。
那些已经有了bambook的朋友，可以去云梯软件中下载这些插件。至于还没买的bambook的人，可以直接点击本站左上角的bambook购买链接，去买一只。
-
将有限的生命，投入无限的阅读中去
自古以来，就有很多人博览群书。但是好像从来也没有听说过有人阅尽群书的。现在这个信息爆炸的时代更是如此了。
要加快节奏，bambook可以帮助大家，将生活中的各种碎片时间都利用起来，阅读那些有价值的内容。有些内容可以逾越身心，也有些则可以让读的人得到知识。不论是为了什么而阅读，在bambook上应该都能够找到适合的东西。生产内容、分发内容、过滤内容、重新组织内容、阅读内容，在bambook这样的一个开放的内容平台上，是一个全社会产生和组织内容，满足绝大多数人的阅读需要的过程。
我为人人、人人为我。
12 月 15
Luke Fan杂谈
DSC_0007
原由 Luke Fan 上載
据说今年北京一直都没有下雪。
我预计明天晚上坐火车回北京的，结果今天居然在上海赶上了一场雪，实在是幸运啊。
分享一张照片在这里，这个牌子好像也就是这几天竖起来的，这是我在离开上海盛大创新院，前往盛大设在北京的多媒体创新院前，在新树起来的创新院招牌前照的雪景。
RSS
![Image(5)[4]](https://lukefan.com/wp-content/uploads/2011/01/Image54.jpg "Image(5)[4]")
