不知不觉距资料集首次发布已经整整一年了，又到了这个闷热的季节，又在依赖单调的体力劳动对抗午后昏沉的睡意。
其实我一直在犹豫，做这样一个东西有没有意义，记得去年发布时倒也热闹了几天，然后便没有了下文，自己使用时才发现居然漏了十篇未翻，代码风格也不够统一，自己的译文现在看来已十分业余，然而从来都没有人提及……其境遇便可想而知。谁的机子里没有几百本电子书呢？只为满足一种心理。
虽然如此还是不甘心，在加西同学的帮助下总算完成了。我没有精力统稿，只能简单地检查一下代码；如果你在使用时发现问题，请在此回复或邮件联系。其实要做的还有很多：内容同步更新、二级链接翻译、挑选天体照片、星座图片统一……以后再说吧，版本号总是可以往上加的
记得在高中物理中有这样一道习题，“一条速度为v的小船要过河，所需的最短时间和最短路程分别是多少，设水速为c，河宽为D”，答案很简单：最短时间不要求靠岸的位置，船头正对河岸即可；最短路程显然就是垂直距离（要求v>a），典型的速度矢量合成；而对v小于a的情况讨论则是学科竞赛的要求了，问题等效于已知三角形的两条边求使其中短边所对角最小的三角形，这个干净的几何解法让我对物理学的优美有了直观而深刻的印象。后来上了大学，在高等数学中（同济第四版）又见到同样的情景，求的是船头始终指向对岸目的地时的航线轨迹，因为船只位置在变，船头方向也在一直调整，据此建立微分方程组，不难解出迹线方程，不久后接触了数学建模，便不再囿于那些过于简化的题设了……
现实生活中的行船从来不是课本中所描述的那样简单，码头的位置是固定的，航向可以随时改变，水流的速度与河岸距离有关……这时再问同一个问题:“小船怎样过河时间最短？”，没人能轻易给出答案。
设码头在正对岸，这是个变分问题，但不能用常规办法求解，我在这里卡住很久，直到最近才在近藤次郎的《数学模型》一书中发现了解法，数值解；用的是前苏联数学家庞特里亚金1956年发表的最大值原理，该原理广泛应用于宇宙航行的轨道计算，但是同其它近代数学的进展一样，没有一个简单直观的表述，有兴趣的朋友请自行查阅。得出的航行轨迹如右图所示(图中两条线代表两种不同的控制方式)。最少燃料策略则与最短时间策略稍有不同，虽然都出乎我的意料，倒也不难理解，在水流较缓的岸边逆流而上调整航线，在水流湍急的河心顺流直下争取时间。
几年的困扰至此总算告一段落，现在我倒想听听内河船长们的经验，也许会有更多的选择
仔细想想，如此循序渐进的教法无非是要回避困难问题所带来的挫败，但这样建立起来的自信在现实面前不堪一击，没有探索的动力，没有发现的乐趣，什么样的孩子会喜欢这样的学习？社会期待创造力，而好学生往往只是听话而已。记得在William F.Lucas在《微分方程模型》(国防科大应用数学模型丛书)中曾说：“本章的目的是教你如何解决问题，而不是显示有人能够做什么！”
要在博客统计排名最权威的Technorati 上claim自己的blog有两个途径，其一是提交用户名密码让爬虫登录，我一向不相信网络，虽然这样的大站信用很好，但中间传输过程难保不出问题，数据包侦听、会话劫持……另一种方法是写一篇新日至，其中包含如下链接 ：Technorati Profile ，这倒是简单，只是这篇日志未免单薄了些。
7月6日补记：
早上收到宋同学的来信，公共帐号使用Python脚本自动登录Eyou网关的问题终于解决了，这下再不用担心写blog时突然掉线了，感谢Elias同学的无私奉献，我也由此见识到Python的简洁与强大。其实最早是在AAS的招聘要求中注意到这个语言，包括夏威夷在内的各大观测站和实验室的技术岗位都要求有C/C++，Python以及Linux脚本的编程经验；后来又在GaoMiao那里听说豆瓣就是完全用Python实现，而NASA和Google也在使用这个语言；这样，即使是出于职业规划的考虑，我也有必要熟悉一下这门新兴的脚本语言。
很久没有写过这类文章了，感谢《天堂电影院》给我重新提笔的冲动……
认识一个人，通常只能看到近况，要在平日的交往中熟悉他的品性，在他朋友的述说中获悉他的过往，那些零碎的场景不分大小轻重先后次序，杂乱地堆积到姓名之下，等待检阅解读；某一天忽然找到线索将它们一一连缀拼合，便能理解一个同自己一样真实而丰富的生命。电影让我们看到陌生人的故事，顺序没有关系，无非是插补倒叙，只要铺垫一份同样的愿望与情结，一切都可以理解了。导演剪辑版不一定有新奇的叙事节奏，理想的故事情节，关键在于他想让我们看到什么，他想通过镜头讲述什么……在这部影片中导演注意力显然不在叙事手法或者悲喜结局，令他难以取舍的是那些温暖人心的场景，尤其是在融入了个人感情之后，生命中的哪一段是可以割舍的呢？他希望我们看到的，正是他从Alfredo留下的那盘胶片中所看到的，人世间的温情！结尾处的重逢确实在现实中难以发生，但这毕竟是电影，生命写下的遗憾既以无法弥补，命运缔结的误会也没有机会消除，那么至少可以借荧幕上相互谅解的目光唤起世间的暖意，冰释天地的无情吧！
每个人都有环境家庭所预设的轨道，按部就班自能阅尽世间风情，与其他人仅在某一刻相望相闻，随后便永远错身；但若企慕他人迹线两侧的景致，不免要离开路灯的指引，跃身至茫茫的黑暗中开始一段全新的旅行。两条直线相交时自是亲密无间，热恋之中的眷侣不顾条件后果只求厮守，但时间不会停滞，谁也无法于此停留脚步，当终于要共同面对现实生活时，才发现他们还没有能力担负爱的责任，《伤逝》想说的不就是这一点么？交汇之后的渐行渐远……为生计所迫而无奈分飞与因缘聚散久别重逢，前者的幻想已破灭而后者的初梦仍可怀念，同样的无奈中有着不同的滋味， 过来人掂一掂，“相濡以沫不若相忘于江湖” ，于是Alfredo让Toto离开。徐志摩也曾劝导别人“你有你的/我有我的/方向/你记得也好/最好你忘掉/这交汇时互放的光亮”，但他却始终无法说服自己忘却林徽因的身影……或许，只有志趣相投、彼此尊重、愿为对方坚持自己的人才能并肩徐行，携手一生，就像两条平行线，永远留有距离与空间……
最后被爆破的旧电影院，其实从来没有荒芜过，众人的记忆一直都在那里栖居，只要建筑依然耸立，每个人都能在其中找回过去，就好像模糊的往事又被老朋友提起，然而当熟悉的场景变迁，昔日的面孔都远去，连记忆也悄悄叛离，生命的痕迹又能铭刻在哪里？只有在温情中延续……
在这个信息暴涨的时代，在庞大的数据库中寻找自己所需要资料已成为研究者每日必做的功课，而资料一旦脱离了数据库，下载到本地之后，管理检索就更见困难了。
之前我一直用Biblioscape管理目录，它分类清晰，支持中文，附件管理也很方便，有意思的是，作为一块美国公司的软件，它用一副中国传统山水画作为版权页面的LOGO。但是最近开始用Latex写论文，发现6.x版本不能导出BibTex格式，最新的7.0中已解决此问题，但汉字仍采用GB2312编码，不支持UTF-8，据说要等到8.0时才会支持，于是开始寻找替代品……
EndNote也有很多人使用，对Word支持较好，但不能导出BibTex，更新倒是很快，半年一个版本，但直到本月13日发行的的X1版才支持Biblioscape三年前就有的自建分类功能，它最吸引人的地方无非是支持众多期刊的引用格式输出，但是每个研究者能用到的不过其中屈指可数的几个，只要能导出BibTex，去期刊官方网站下个bst格式模版就可以随意转换了，从几百种没有听过的期刊名中翻检自己天天要用的那一个很爽么？Reference Manager曾经很有很有竞争力，但1999年被ISI收购并与EndNote合并之后，更新几乎停滞，至今还不支持中文；而创立于1980年的第三大管理软件Procite的下场更惨，被ISI收购之后就没有再更新过！
（详细的状况可以比较
耶鲁大学图书馆98年的横向评测
韦恩州立大学图书馆03年的评测
再看看Thomson公司现在官方的对比
这三个软件的境遇便不言而喻了。)