从两台洗衣机看生活中的经济

        最近几年随着毕业后生活中心从学校转向工作，经济上已经完全独立，并且逐渐有理性的经济意识。不止有空看看五常的宏观调控算学经济，拜读凯恩斯的大作算学经济，在生活中的消费行为是更有效的学习方法。以前租房子，房东的洗衣机是最简单的那种，除了转动什么都不会，每次洗衣耗时耗力。平时懒得用，一到周末就是洗衣日，一大堆衣服要洗上半天多。如果去户外露营或旅游，回来后的要洗衣服更多，实在是不堪重负。而且有些比较好的衣服和冬季的大衣羽绒服，小洗衣机基本洗不了，得拿到洗衣店去洗。前些日子和MM商量打算买个洗衣机，把宝贵的周末休息时间从洗衣中解脱出来。到网上，商店转了些日子，大概了解一下现在的行情。一般国内的品牌主要是低等和中等，国外的品牌是中等和高等。鉴于以前买大件电器的经验觉得国内品牌售后一般不太好，所以决定限定在国外品牌。首先排除日货，否则在主观情绪上接受不了。其次排除韩货，觉得韩货不以质量为重。这样可选范围基本限制在几个欧美品牌。到网上调查了一下，西门子的口碑很好，于是决定买西门子的。在调查发现和另一个被西门子刚收并的品牌博世已经进入国内洗衣机市场，并且在产品完全和西门子一模一样的基础上平均便宜200元左右，这样我们决定买博世的。
       博士品牌洗衣机的也有很多款型，从2000多到5000多不等。MM买大件东西经常持在价钱不离谱基础上尽量一步到位的原则，提议买功能最多，效率最高的。最高等级的是滚筒洗衣干衣机，型号WVT52458TI，具备最高转速，最多功能，可以干衣，价格大概5300。我虽然认同这个品牌，但觉得干衣用处不大，而且比非干衣大概贵800元，但也想不出什么理由说服MM，于是就接受了MM的意见买了这款。买回家到现在大概半年，对机器还是很满意的，无论噪音，功能人性化，服务质量都让我们无可挑剔。但美中不足的是干衣功能基本用不到，而且总觉得价钱贵了些。前不久父母也想买个洗衣机，听了我们当初买的思路，决定买博世的，把家里用了十几年的老双缸换掉。但他们觉得我们买的很多功能不重要，而且效率不重要，所以选择了3100元的款型，回来用了几个星期感觉很满意。
       以前我买洗衣机时还在犹豫，既然房东提供了洗衣机，是否还有必要再买一个好的。因此在考虑买新的的时候总把价格因素考虑在前面。包括旧的方法的水电，需要 花多少钱给洗衣店等等。一下花了5000元买了洗衣机总在计算够送多少趟洗衣店才能抵回来。今天和父母讨论他们用了一个月的感受，忽然觉得买的并不亏，因为我之前忘了算进去另一个重要的因素：时间。新的洗衣机是全自动，把衣服放进去，设定好程序，剩下的等着它叫你晾晒，或者使用干衣功能等着叫你穿就好了，基本不需要人工额外操作和值守。我估算一下买新洗衣机之后，大概我和MM每周共平均少花6小时用于洗衣，一年也就是300小时，合13天。按每月我和MM纯收入12000元计算，13天大概收入5000多元。也就是说一年用于洗衣的时间节省出来时间能买一个全新最高档次的洗衣机。如果算做是一种投资的花，如果不考虑折旧，本金是5000多元，一年回本，此后每年的收益是约100％。随着损耗维护费用逐渐增加，直到它彻地不能工作。当然，并非说我们不把这些时间用于洗衣，可以每年多挣5000多元，但我们可以用节省的时间学习，娱乐，陪父母，做更多有意义的事情。虽然不能直接增加收入，但可以明显提高生活质量，周末可以用更多时间享受生活的快乐，所以还是很值得的。
       生活的经济和市场的经济很大的差异在于非可度量价值，比如体验，比如心情，比如时间和机会。很多价值是很难为货币所衡量，而又是生活的重要组成部分。钱在狭义上对生活而言无非是维持生活的工具，但适当的调整钱与生活这个天平的发码，可以换来更美好的生活，也许就是大家讲的生活质量吧。所以理财也好，经营也好，只是用钱来满足并平衡自己的欲望。知道什么是自己最想要的，也许会觉得生活更有意义。

一次成功的项目管理实践

        月初参加公司给安排的项目管理课程。做软件的嘛，做方案的嘛，早晚要接触到项目管理。想必听听对工作有用。没想到今天第一次从中受益，并非是当项目经理，而是作为项目成员给自己加分。记的项目管理第一节课，老师就说，项目管理绝不仅及是用在软件开发，或者工程管理。生活中无处不是项目，买个房买个车，出去玩一趟都是项目管理实践的机会。现在想起来说得太对了！
        事情从上周说起。周四上午10点我接到Leader给的任务，负责编写一个小模块，用于加载配置数据。需要开发的只是一个类，其中有一个主要的方法load()负责用磁盘上的配置数据在内存中构建一个结构化的数据对象。本来Leader已经基本作好了的一个版本，只是现在由于需求变化，需要改变配置数据的格式和内存对象的构造规则。因此我基本上要重新写load()中的逻辑来符合新的需求，并且要考虑为以后需求变更提供一些可扩展性。配置数据放在一个三层XML中。我需要读取，解析，然后放到一个对应的三层的Map结构中，就是一个Map套Map一共三层的多叉树。我管每个Common叫“不定式”，三层一共三个一元不定式，三个一元两两配对形成三个二元不定式，三个一元同时叠加形成一个三元不定式。一共7个不定式需要在各级循环逻辑中处理。看来这个XML的确比较复杂，更麻烦的是受外界条件限制不能为它定义Schema。
         按照通常的软件开发习惯，首先分析边界条件。比如什么情况Common覆盖Special，什么情况补充Special。 然后写测试用的XML，包括一些测试边界的数据。最后把逻辑流程写到纸上，并标识测试的观察点和异常情况。由于考虑扩展性和最大程度减少数据冗余，逻辑做得比较麻烦。先要把所有Special的数据加载成对象，然后用Common数据来根据情况修改所覆盖Special数据。经过两个小时，设计做好了。用大脑模拟运行几次，没有问题，去和Leader讨论。Leader听我讲了思路，首先对我的设计表示认可，认为能想到的各种情况都考虑到了。但同时他也提出顾虑，主要是这个逻辑写起来会很麻烦，费时间，其次以后别人阅读不容易理解，而且后期超出对目前弹性范围的需求变更的修改会比较困难。讨论了一阵子，发现也没什么更好的办法，因此决定先做做看。这时已经是周四下午4点多了。
        既然设计已经通过认可，我开始着手写逻辑。解析XML是使用JDOM和XPath。开始写发现这个东西比较烦，层层嵌套，层层拆分。代码编写进度比较慢，稍不留神就迷失在嵌套的从林中。到了晚上9点下班，已经处理完一个一元不定式。回家继续努力，到半夜快2点的时候，终于把这个load()写完了。
       第二天早晨，强打着精神来到公司，继续对这个类其他方法编码。到了中午开发部分一切已经搞定，开始测试。由于前期设计工作作得充分，测试并没有太痛苦。因为逻辑做得完善，所以自己思路还是很清楚的。通过第一轮测试发现Common和Special的优先关系都反了。通过Debug跟踪代码发现自己对xPath的//理解有错误，于是反复修改测试。到下午4点半一切搞定，所有测试数据和边界条件都符合设计。上交代码和测试数据，下班回家。离开公司前Leader让我手机一直开机，发现问题随时需要我修改。但我对自己的作业是信心十足的。实际也证明，一个周末我的手机一直安安静静。
       这周一早晨来到公司，第一件事情就是问Leader，我那部分与其他部分合的怎么样。Leader很心疼的看着我说，上周我交的代码很不错，但现在需求变更，需要把配置数据再增加一层。当时感觉自己一阵眩晕。三层已经让自己很困扰了，好不容易解决又弄出个第四层来。三层的时候最复杂情况是遍历三层原数据再累加遍历三层构造一半儿的多叉树对象，一共是6层循环。现在源数据加到第四层，逻辑就是8层循环，代码量也会相应大很多。此外的变更是以前Common用于填充所有叶子，现在改成只填写存在的叶子，因此要增加判断逻辑。更要命的是必须尽快做完，顶多给2天时间。因为我的模块需要被其他业务Pipeline调用，而目前其他业务模块基本都做完了，就等着我们这块完成之后做单元测试。Leader看我为难的样子给我出了个主意，把我以前的设计方案推倒，重新设计配置文件的格式，并且重新构建数据模型。颠倒数据装载顺序，先读取不定式，然后读取相对special的数据，但这种方式依赖每个XML元素中子元素的顺序。按他的建议，我前期做的工作除了让自己对这各模块的业务熟悉之外，其他工作基本都要被抛弃，而且新的思路对增加了XML文件中数据有序的约束，降低了灵活性。好处是如果以后别人读我的代码或修改我的代码会比较容易，而且总体使用时间会比继续按我第一版的时间少。的确他说的有一定道理，降低扩展性，减少初期开发时间，如果没有更多需求变更的确这种方案比较经济。这时我必须做一个决定：继续 在我第一版基础上修改，或是推倒重新做第二版。
        正在为难的时候想起了项目管理课程中讨论过的一个话题：是否完全依照客户意愿在项目进行期修改需求会直接影响项目验收效果。往往通过讨价还价尽量减少需求变更会对验收有利。分析当前的情况，包括了两种变更：业务需求变更和数据结构／算法变更。前一种变更看来是无法免除的，因为这本来就是个潜在变更，而我做是前期我们做需求分析时没有考虑到。第二种变更完全是客户（也就是我的Leader）应对第一种需求的一种策略，目的无非是解决第一个需求。我推想，如果我能把第一个需求解决，他也不会非要求我再按照他的设计重新开发，但风险是我必须按期完成对需求变更导致的开发。寻思良久，我还是决定铤而走险，用一天时间继续按第一版方案修改。如果到明天早晨我不能交付代码，那我就彻底放弃第一版进而开发第二版，并且必须在后天早晨之前完成。后面的事情可想而知，从上午一直工作到半夜，疯狂的工作，舍弃一切没必要的代码，比如调试部分及必要的注释。第二天早晨再到公司虽然晚了一些（早晨实在困的起不来），但心情轻松了许多，而且顺利的通过了他的测试。虽然我告诉他我没有按他的要求完成变更的第二部分，但已经完成了第一部分。如果他坚持认为必须完成第二部分，我会在第二天早晨提交给他第二版。他想了想，似乎也意识到相比之下重要的是尽快交付这个模块，于是对我的工作表示认可。我不但提前完成了任务，还可以让自己后面几天轻松的等着别人的进度。
       这是我第一次在工作中有意识的利用项目管理的知识，和从中尝到甜头。和以往抱着不加思索的满足客户需求的态度相比，适当的策略及技巧在满足客户需求的同时让自己更多的获利，对客户和自己双方达到共赢。看来项目经理的课程远不仅对做“项目经理”这一职务有用，而且为参加项目的成员相互协作提供方法指导。

Eclipse中的Java API DOC

说实话，Eclipse到现在还不能说处处比VS强，就拿联机帮助来说，到现在也没能作得像MSDN一样随心所欲的找到你要找的类，方法，更不用说例子代码。虽说CHM和HTML版本的Java API DOC，从无论SE还是EE甚至Jakarta能准备的 都准备了，但有时候在客户现场开发没有Google，遇到有些不常用的第三方包还是抓耳挠腮的找不到帮助。在这里整理一下常用的Eclipse中使用Java API DOC方法，希望能找到更完美的方案。常用的方法三种，一种是填加一个插件，用Elipse自带的Help Server发布DOC。另一种是用Eclipse自带的热键唤起一个浏览器。还有一种是用DocJar。
Eclipse自带插件的方式参考老俞的帖子《将Java Document或其它文档集成到Eclipse中》吧。加好之后在Eclipse里用F1就能把Help调出来，很拉风哟。比如把光标放在String上，点F1，相应的help就列出来了。但这种方式不爽的的是不能方便的搜索，比如我想找个叫S?ring的类，用它的Search找不到。





另一种好玩的方式就是Eclipse自带的热键Shift+F2。在Eclipse里写代码时遇到看不懂的方法或类，选中它，点一下Shift+F2，会弹出来一个浏览器窗口，并且显示你指定的东东。这东西的好处是配起来比上面的方式简单得多。我习惯在把常用的第三方类库在Eclipse中设置为Libraries，然后为Libraries中需要用Java API DOC的包指定DOC位置。



同样你需要为JDK指定Java API DOC。



但同样搜索的问题还是不能很好解决。


第三种方式是用DocJar。网上使用文章不少，我就不废话了。但不爽的是用的时候必须联网。搜索可以支持模糊查询了，但效果并不好。


有上面三种工具，基本JavaDoc的大部分查询问题能解决了。但实例代码还不能和Eclipse集成来查询。期待着。。。

学会游泳，给自己鼓掌！（2）

酒店游泳池不宽，10米不到。练了一个星期，已经可以一猛子扎到对岸。而且手脚逐渐协调，大概7，8下就够了。但是还不会换气，不会脑袋露在水面上，而且不能游更远。这次出差任务马上就结束了，回到家没有地方那么方便的游泳，但总觉得一搁下很快会忘掉。MM也一直想游泳，只是我总找借口推辞不去。通过一周的练习，我已经对游泳兴趣昂然，于是俩人高高兴兴的去东单游泳馆办了个游泳卡，而且买了泳镜，泳帽，鼻夹这些标准用具。游泳卡是480块钱30次，一次两个小时，不记名的，能用到明年二月。每次两个人去，一共15次，怎么也得好好利用这张卡，游出个样子来。算了一下，从8月开始每周游一次，能游到11月。
第一次去东单游泳馆这种正规的游泳池，站到池边，觉得泳道好长。虽然是游泳馆外是炎热的夏天，但游泳池里人不多，不像是小时候夏天去的陶然亭游泳池，露天的，人多得简直就是煮饺子。游泳馆的泳池是标准大小，而且有浪线分泳道，最两边的是浅水区，大概一米四左右，正适合我这样初学乍练的。深水区据说2米到2米4，乖乖，我下去肯定上不来了。虽说泳池中间几个泳道人不多，但浅水区人还是比较多的，看来不少像我这样的新手。迫不及待的下到池里，戴上泳镜，开始复习之前的成果。让自己惊奇的是居然前进的速度比在酒店快了些。而且戴上泳镜，在憋住气的情况下，可以把半个脑袋露出来。但是还是不能呼吸，因为嘴和鼻子还不能露到水面上。再看MM游的真让我羡慕，头可以露在水面上，象青蛙一样轻松，优雅的漂着。MM看我在水里扑腾了几下，立刻让我停下来，说我的动作实在不标准，得从基本漂浮练起。看来之前练的不正规，于是虚心求教。
TBD

powered by performancing firefox

学会游泳，给自己鼓掌！(1)

要说别人不会游泳是没条件，俺怎么也不该不会。小学六年加初中三年都在有游泳池的学校念书，楞是没学会。幸亏九年的体育课一直没要求游泳考试。也许反过来说当初要是逼到不学会不能毕业，估计也早就学会了。不管怎么说，初中毕业后就给自己下了个结论：这辈子学不会游泳。就像有人一辈子不能吃猪肉，有人一辈子不能站在高处往下看一样。算了，不会就不会，淹死的都是会游泳的。就这样十多年就再也没想过自己还回去学游泳。以前做学生，总有的是运动的机会。现在工作了，从早到晚在充满毒气的鸽子笼里，缺少运动，身体素质越来越不如以前。夏天是自己最不愿意运动的季节了，主要是怕热。但总不运动也不挺说不过去，只好硬着头皮去学游泳。

这个夏天第一次游泳是出差的时候看见酒店有游泳池。酒店的健身费是包含在房费里的，如果不去游总觉得比较亏。何况酒店的室内游泳池人很少，水温不错，而且还有一起来出差的同事好为人师，难得学游泳的好机会。

第一次下水大概是5月中在南京的酒店里，虽然能憋会儿气，但不得要领，只是在水里瞎扑腾一阵子。看着同事轻松的在水上飘来飘去，很是羡慕。而自己努力扑腾半天，站起来一看，基本没前进。自己瞎扑腾总不是办法，虚心求教，先从最简单的蛙泳学起。在岸上仔细看同事游泳的动作，然后模仿配合，逐渐把生硬的记忆变成比较熟练的动作，然后开始下水实践。闭上眼把自己钻到水里，让自己漂起来，然后凭记忆划水。作了几次，果然发现自己可以在水中前进了。有了成功的开始，就越来越有兴趣游。练了一个星期，基本可以十几步游到十米左右远的池对岸。虽然游泳时不能把头露出水面，而且只能凭触觉知道是否到对岸，但这些成绩已经让自己很满足。看同事轻松的四步就能游到对岸，还是怎么也想不明白自己什么地方弄得不对。

TBC。。。

我认为理想的Bog 续

上一篇说的是自己选Blog的标准，这一篇是说对Blog Server的理解和理想。

所谓理解是说对Blog文化的认识。我理解的Blog文化，是提倡共享精神，Cyber文化应该不是用货币单位来衡量，而是相互无私的交换。所以Blog提倡的是人人都把自己私有的信息拿出来交换。限制交换的原因有很多，包括个人的私心和技术的限制。Blog的主旨是尽量减小信息传播的障碍，并通过更丰富的信息来鼓励使用者减少信息私有的观念。所以和Blog紧密关联的词语，应该是原创，跨终端，多媒体，解中心。在内容管理中有一个重要的陈述是，人类社会80％的信息是非持久的，持久信息中80％的是非结构化的。Blog应该是提供最便捷的对信息持久化，结构化的平台。按照这个标准，现在的Blog Server都离这个标准差得很远。

首先，现在的Blog想当大部分内容是非原创的，是引用的。当然，有人会在它的Blog上注明是引用，有的就是直接贴过来成为自己的Blog。经常Google某个关键字，会找到N多一样内容的Blog。似乎被转的越多，越表示这篇有价值。但是从信息本身来说，复制的信息是几乎没有价值的。所以理想的Blog文化主流应该是原创的内容，而非环顾四周都是FAKE。

第二，跨终端。Blog本身的主旨就是消除信息发布的障碍，但Blog本身还没解决自己发布的障碍。主要包括两种障碍。第一是Blog Server缺少规范。虽然RSS提供了Blog整合，但对绝大部分Blog的发布还停留在比较原始的阶段，理想的，通用的Blog离线编写工具远没有Blog Server令人满意。而且离线编辑目前基本只停留在电脑终端，能支持通过移动终端发布Blog目前还非常罕见。如果Blog Server能支持从手机终端编写和接受Blog，可想而知Blog会更加丰富。

第三，多媒体。目前绝大部分Blog是以支持文本为主，通过链接方式支持其他媒体文件。媒体文件需要事先存在在互联网上。这在事实上限制了很多信息发布的手段。现在手机不支持照相的已经很少了，图片作为信息表现手段越来越受到重视。文字只能传输口头语言信息中的一部分，而传递图片正是口头语言无法实现的。Web的优势正是提供多种信息表示手段的聚合，并建立各种信息表示方式之间的连系。比如一篇帖子除了有文字，还可以有图片，有一小段录像或Flash，有背景声音等等。这是其他任何信息传递渠道无法具有的优势。而目前Blog只是非常简化的Web，以文字为主，加上不太方便的图片。

第四，解中心。我不知道这个称呼是不是得到共识，因为更通用的说法是decentre。Web 2.0的一个中心思想是把单项的信息推拉变成双向的信息互动。但现在Blog似乎成了BSP挣钱的工具。

发发牢骚而以。

我认为的理想的Blog

上一篇提到我对现在绝大部分Blog Server的不满，有什么不满呢？仔细总结一下在这里列出来。

1。速度。用过一些注册量比较大的Blog Server，比如Blogcn，速度有时候实在难以恭维。写好了Blog发布之后有时候一两个小时都看不到更新的Blog。好想赶快把新出炉的Blog和大家分享，但不得不忍受慢慢腾腾的BSP，实在是折磨。

2。稳定性。有些颇有名气的Blog Server，比如BlogDriver，可能是访问量太大，或者受到某些运营限制，有时候无法从某些主机访问。因为公司的网络是通过连到美国的服务器来接入Internet，所以这些受地区限制的BSP就不在考虑范围之内了。

3。离线能力。经历了太多次辛辛苦苦在自己Blog的编辑器上洋洋洒洒写了好几个小时的帖子，结果一提交，所有的内容都丢失。这实在太打击自己使用Blog的积极性。现在国内使用标准的BlogServer API的并不多，而且好用的Blog离线编辑客户端也不多。Firefox的Performancing对FF版本支持实在太慢，幸亏遇到了Zoundry，总算各方面还可以接受。因此和Zoundry不能兼容的Blogserver也就不在我考虑范围之内了。

4。Look and Feel。有些Blog Server提供的模板比较简单，或者说得自己填加模板。比如Matrix以前的BlogServer使用MT。不知道什么原因，我的模板一直不好使，自己Blog的只能是最基本的文字，而没有丝毫装饰。而有些Blog Server虽然提供了丰富的模板，但似乎BSP更多关心的是在你的Blog上强行放上不让你欢迎的广告。有些Blog则对Look & Feel限制的比较死，可以DIY的范围很小，比如M$的spaces.live，连模板都没法改。对这些Blog Server，我是不会选的。

5。自己的二级域名。连个二级域名都不给的Blog Server也太土了吧。新浪这种吝啬的BSP，免谈！

归并这些考虑，可选的Blog Server就的确不多了。希望我的新家，能接受的住我的考验。

献给新家的第一贴

好久没写Blog，总给自己找的理由是找不到好的Blog Server。要不支持中文不好，要不太慢，要不贴图片麻烦。反正一直没有顺心如意的。终于今天发现了这个工具：Zoundry。受网上不少介绍Zoundry文章的诱惑，终于摸索出了一个让自己颇为满意的方法：用Blogger.com做Blog Server发布blog，并用sitesled作为页面发布的服务器。花了一个晚上，终于把这三个整合在一起了。不敢私藏这几个小时的成果，分享给大家。

首先介绍一下完成主要使用的三个工具：Zoundry，blogger,com和sitesled.com。

Zoundry是一个Blog的离线编辑工具。可以写文章，使用HTML进行排版，以及在文章中插入图片。下面这张图就是我在用Zoundry写这篇东西时候的截图。网上有很多使用介绍文章。 后面我将针对这个方案的设置。

blogger.com是一个非常有名的Blogger Server，更准确说是一个标准的BSP。自从被Google收购后已经成为整个Google产品家族的一员，并且有了中文界面。所谓爱屋及乌，喜欢Google，自然要用Blogger。但是blogger.com有一个很不方便的地方是所有在它上面保存的Blog，发布的域名不是Blogger.com，而是blogspot.com。而这个网站由于众所周知的原因在国内绝大部分用户是无法访问的。所以想使用Blogger.com，只能通过一些变通的方法。还好，通过在网上搜索，找到了一个移花接木的网站，也就是下面介绍的sitesled。

sitesled.com是一个比较有名的共享空间。大概每个帐户给100M的空间可以自由使用，并且可以通过FTP方式存取文件，以及用Web方式发布你在空间中保存的网页。

下面说编写Blog的方法。首先在Blogger和Sitesled中注册帐号及下载安装Zoundry就不必说了。

比如我在两个网站注册的帐户都是goblinize，密码是123456。这样我分别的得到的两个网址：http://goblinize.blogspot.com和htttp://goblinize.sitesled.com。需要说明的是在blogger登陆后在控制台的"设置"->"发布"要选择用FTP发布。服务器是"ftp.sitesled.com"，Blog URL是"http://goblinize.sitesled.com/"，FTP路径是"/"，Blog文件名是index.html。

打开Zoundry，在工具栏的"工具"－》"设置"中选"Blog帐户"，选"创建帐户"。按照向导，先输入Blog URL：htttp://goblinize.blogger.com，也就是我blog原本发布的地址。然后输入帐户信息。帐户名称随便写，只是为了在Zoundry中使用。我输入的是"头发乱了@blogger"。帐户类型选blogger。用户名和密码我填入的是goblinize和123456。完成后在用户设置窗口再左面树选择媒体库，填入FTP媒体库的地址。比如我的地址是ftp.sitesled.com，用户名是goblinize，密码是123456，URL是http://goblinize.sitesled.com/，根路径是/。设好之后点一下"测试设置"，确定可以使用。然后就可以用Zoundry编写自己的Blog了。写好之后点工具栏的"发布"，如果顺利能看到一个成功提示。这时用FTP客户端连到你的sitesled上面，应该看到有一些对应文件放到了你的根目录下。访问一下http://goblinize.sitesled.com/，能看到你的页面已经成功的发布好了。

一些小缺陷:

1。Blogger.com本身不支持分类，因此如果Blog比较多也只能都混在一起。还没有什么好方法。
2。Sitesled.com本身支持中文名文件上传。比如你需要传一个中文文件名的图片。但是Blogger.com不支持中文名图片的发布。因此只能在你本地编写Blog的时候把图片名都修改为英文名。
3。字符问题。在使用Blogger.com中的许多模板时，如果发布的Blog标题是中文，会遇到发布的Blog在IE中浏览，看不到任何内容，是空白一片。而在FF中则可以。在IE或FF中查看原代码，却能看到所有的代码内容。这是因为Blogger.com中有些模板有一个小缺陷。在Blogger.com中打开模板编辑能看到比较靠前的地方有一行title。后面紧跟的一行是BlogMetaData。把这两行换一下次序再重新发布试试应该就可以解决了。这个问题主要是IE遇到中文的Title，就把当前的页面编码自动专成了GB2312。而后面文章需要使用UTF8，所以就无法显示。调换次序之后HTML代码会显示的告诉浏览器使用UTF8，因此可以正常显示了。

刚开始使用这种方法写Blog，肯定还会遇到各种奇怪的问题，希望能和使用类似方法的朋友交流。感谢Matrix上的兄弟们给我的帮助。让我顺利的发布新家的第一个Blog。我又可以轻松的一边写Blog，一边儿品尝我最爱的Hoegaarden了。Cheers～