硕鼠的博客站

注册了一个点点的域名：http://lukefan.diandian.com ，尝试一下这种新的模式。轻博客，从字面上看，好像是介于博客和微博客之间的一种东西。

也许会很有趣的吧。

希望点点能够成为我信息外发路径上的一点。
可以考虑做一个wordpress的插件，这样的话，就可以直接将我的博客内容转到这边。写博客总是需要动力的，那就是希望能够有人来看。很难做一个应用，就让很多人从不写博客，变成写博客。所以要去争取那些现在就写博客的人。
可以根据各个博客站点的API，将点点，搞成一个信息发布中心，如果能够把回复和点击统计再做掉，那就更完美了。
我从来不认为自己是一个典型用户，但是上面那些至少是我的需求。希望酌情考虑。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

同事们一直和我说，来了上海，如果不去吃一次小杨生煎，那就算是白来了。我在上海住了一年多了，还没去吃过这种东西。生煎倒是吃过一两次，但是每次都会往身上撒好多的油水，实在是非常不爽的经历。

在上海，我尽量避免吃任何包子一类的东西，主要就是上海的包子好像都是有汤的。而且，由于制作工艺的问题，很多包子的侧面很薄，在咬的时候，侧面会突然喷射出很多油水来，让人防不胜防。

近期可能就能够回北京了，在上海生活了这么长的时间，还是决定听从同事们的建议去尝试一次小杨生煎。

坐地铁到南京东路站，然后在谷歌地图的指引下，找到了这家店铺，真的是非常寒酸的门脸儿，门口有一位收银的老奶奶，生煎也是可以直接在门口出货的。我去的时候并不是饭点儿，但还是有那么三五个人在排队的，看来这确实是一种非常受欢迎的当地名吃。其主要的生意都是外卖为主，堂吃的比例应该不高。

我询问了一下，生煎是按份卖的，一份四个。思量着，按照我这个胃口，应该能吃得下两份的吧，再来分小馄饨，也算是将上海的小吃又多尝了一种。但是，门口的收银老奶奶却说我点得太多了，那些是吃不完的。她建议我点六个生煎，也就是一份半（这种情况在北方是不可思议的），再加上一碗牛肉汤。还告诉我，这样是最实惠的了，馄饨很贵的，牛肉汤的味道很好，很多来这里的人都是这么点的。

我从善如流，听从了老奶奶的建议，下面就是她推荐给我的套餐。

在门口领到了那个破唐磁盘子装的生煎，那个盘子真的很破，很多地方的搪瓷都已经刷掉了，盘子边上还写着小杨生煎馆的字样。往里面走，店面非常的小，也就是十张快餐桌上下的样子。我进去的时候居然坐满了，等到一桌的客人吃完，我赶快端着包子坐下。一位服务员老奶奶帮我擦了擦桌子，然后送来了我的牛肉汤。桌子上的那个装醋的小碟子，必须要自己到后面去拿，我去那碟子的时候，看到了很多用食品袋封装的大概只有老式眼药水瓶子大小的醋包。这也印证了我前面关于“这里主要是以外卖为主”的猜测。

吃的过程异常小心，咬开每一个包子之前，先仔细的观察包子的四周，不要让可能破开的地方对着自己，咬一个口子，如果包子没有漏汤的话，就小心的将汤吸出来，如果已经漏了，就将汤倒干净，然后占着醋吃下去。味道还是不错的，这次终于没有撒一身的油水。不容易啊。

这些食物的味道还是不错的，但也没有什么特别值得一说的东西。可能是我吃生煎的方法有些问题，没有吃出最好的味道来吧。下次找个本地人来教导一下，也许我能够喷他一身油水呢。

小杨生煎确实是享誉海内外的一个品牌。我在吃生煎的时候，还遇到一件非常有趣的事情，一位非常有风度的白人女士，走到门口指着门口的招贴广告，对自己的翻译说了些什么。那个招贴广告并不是生煎的宣传，而是一个招聘糕点师的广告。于是那位半吊子翻译，就去和坐在门口的收银老奶奶说，这位女士想要应聘你们的糕点师，你们给多少钱？估计老外说的时候，说到了How much之类的词语，被这位翻译小姐听懂了。门口那位老奶奶被吓到了，完全搞不清状况。于是就问这位女士今年多大年级了？我也是在这个时候才注意到这个事情，我听到那个翻译在问：“How old are you?”，那位白人女士也是一脸困惑的样子，但还是回答了，43岁。门口的收银老奶奶自己不懂英文，也不敢随便的拒绝一位外国友人，于是请来了店里面唯一懂英文的一位工作人员。了解之后才知道，那位外国女士，只是想要买一些生煎，打包带回去吃，她以为指的是生煎的广告，然后让翻译去问价格。结果指的是一个招聘糕点师的广告，翻译的水平也实在是烂了一些，就闹出了这么个笑话。估计这位女士还在困惑呢，为什么买生煎还要问年龄，真实非常奇特的风俗啊。

这就是我快乐的周末生活了。吃到了小杨生煎，还看到了一个很有趣的故事。希望以后回到北京，可以带上海的同事去吃北京的豆汁，我也会很努力的向他们推荐的，不过我自己是绝对不会去吃的。也许他们会喜欢的吧。

有人说距离产生美，但是我要说缺憾才能产生美。特别是IT产业的发展历程过程，这种由缺憾所产生的美，随处可见。而且这些美还会更进一步的影响到产业的发展方向。

1、Web的美

在最早的时候Web方式由于表现形式有限，和用户交互的能力差，被很多要求高交互性能的应用所摒弃。Web方式为了能够更好的吸引眼球，规避交互能力方面的缺陷，在美工上下足了功夫。最后导致了大量普遍人认为Web的应用就应该比普通的桌面应用漂亮，这样一种奇怪的论点。其实就桌面应用的表现能力来说，肯定要比Web应用有更大的渲染空间，但是由于Web产业在前期吸收了大量的美术人才，一个桌面应用所需的美术量通常是要小于网站的，而且网站的更新频率通常也要大于普通的桌面应用，很多网站甚至只更新美工的部分，代码的部分很少改动。这就导致了美术人才更容易在Web应用中找到自己的位置，也就是说他们更加愿意做Web应用。在Web应用的表现能力和交互能力逐步提高到能够满足原来桌面应用的需求时，Web应用的免安装和免维护的特性，一下就压倒了桌面应用。其实真正压倒桌面应用的并不是免安装和免维护，而是在普通人观念中，Web应用肯定要比桌面应用漂亮的这种偏见。不过现在，桌面应用吸收了Web的美术元素之后，又开始卷土重来了，最终这两种应用形式，肯定还是会达到一种平衡的。

2、单键鼠标的故事

这个故事，其中有些部分我也是道听途说来的，不是很精确，知道准确答案的童鞋，可以告知我，我再进行修改。传说微软申请了一个关于鼠标右键的专利，使得他的竞争对手苹果，只能使用单键鼠标，最终却迫使苹果将单键的用户体验做的比双键还要好。并最终发展出了背面是触摸板的鼠标来。而微软的双键模式，最后却限制死了自己的发展。

3、电容屏的故事

最早的手机触摸屏，都是电阻屏幕，电阻屏的优点是定位精确，可以使用笔来进行书写和精确的定位。后来电容屏出现了，电容屏恰恰是定位不那么精确，电阻屏的精度能够达到1个像素，而电容屏是无法达到的，而且由于要使用指腹去触控，所以电容屏的触控精度，通常在一平方厘米左右，本人由于手指较肥大，所以这个精度还要再差一些。微软早期的手机都是电阻屏的，可以精确度用笔点中屏幕中的那些小叉（关闭窗口的按钮）。苹果却采用了电容屏，并专门设计出了一套使用滑动和手势的操作方式。事实证明，最后苹果赢了，采用电容屏的Android也赢了。很多用惯了Windows Mobile的人，看到IPhone之后，会惊呼，边上的scrollbar哪里去了。用上Iphone一段时间之后，他们会发现，根本就不需要这个东西，上下左右，是可以拖动的。电容屏还具备电阻屏所不具备的一个优势，那就是多点触控，电阻屏从原理上就杜绝了多点触控的可能性了。综合来看，更方便、更人性化的操控风格和多点触控，最后征服了大家，使得广大用户放弃了原来的那种精确定位的技术，选择了一种定位精度更差的屏幕触控方式。

类似的故事，应该还有不少。这到底能够说明什么呢？上帝关上了一扇门的时候，在旁边打开了一扇窗？一些现在看来有缺陷的东西，未必不能产生出优秀的应用。甚至这些东西最终还有可能取代那些原来性能比他们更好的东西。关键还是要花心思去做设计，扬长避短。很多技术，不要想着一定要达到什么什么程度，才可以开始应用，也许现在的程度就已经可以包装出不错的应用了呢。

本照片是使用的android的HTC G7，使用camera360软件拍摄而得。