记忆力是越来越靠不住了，开始依赖于各种各样的工具，最近慢慢发现手机是个不错的工具，最大的好处是不需要额外带什么东西就可以随时随地记录一些记事安排，便于查看，并可以设置闹钟提醒。但缺点就是输入文字不方便，也许有些人就是因为这个原因而拒绝使用手机的记事功能。
不过这个世界是没有完美存在的， 我发现当我接受输入慢的缺陷，尝试去用它以后，就慢慢得到了记事带来的好处，而且很多时候记事并不需要太多的文字，只几个字而已，输入慢带来的不便逐渐被我忍受了（人的适应能力是很强的）。同时一些额外的工具（比如和Goolge Calendar的同步）也使得输入更为方便，比如可以在Goolge Calendar里一次输入多个事件，再同步到手机上。
所以，我想写下来的一条就是，在你不能发现完美的解决方案之前，选择一个能够解决问题的不完美方案 ，Just try。。。
很早就开始用Google手机地图了，不过最近发现这个Google手机地图升级了，由于是客户端版本，所以要重新安装一下了。之所以想升级到这个新版本，是因为这个新版本终于终于支持了“我的位置”这个功能，可以定位你当前的位置（应该是依据基站信息，它的定位结果就是一个位置加一个半径，我这里半径是2.5公里左右，呵呵），定位速度挺慢的，通常都要1分钟左右才定位到，这个比较奇怪，不就是和基站交互一个位置信息吗，难道还是怎么算出来的？）
安装的话，可以用手机浏览器到http://www.google.cn/gmm就可以了，很方便的（我的S60的版本大概450K左右）。这个版本的其他特点：
当然最好是开通GPRS套餐之后再用Google手机地图，否则费用也是个问题的。
最近经常看到这个词，一向英语比较缺乏自信的我用百度词典和金山词霸都不能查到这个词的意思，还好我们有强大的百科全书Wikipedia，它给出了下面这个定义：
In technology, a mashup is a web application that combines data from more than one source into a single integrated tool; an example is the use of cartographic data from Google Maps to add location information to real-estate data, thereby creating a new and distinct web service that was not originally provided by either source.
这段定义里是以Google Maps来作为例子的，因为Google Maps实在算是mashup的最普遍的一个source来源的，大量的web站点现在都集成了Google Maps提供某种地理位置服务，也许Google Maps可以算是mashup的最大推动力（就像Gmail之于Ajax）。
技术上讲，mashup背后通常依赖于某种API来从数据源获取数据（也许RSS也可以算做一种API），大量的网站都是依赖于这些API来获取自身难以提供的数据，当然仅仅是嵌入或是显示这些数据是不能算做mashup的，比如嵌入一张来自flickr的照片，或是youtube的视频当然不能算做一个mashup。 mashup的核心在于需要通过数据源来创造新的价值，从技术上看，这里的另一个重要工具应该就是Javascript/Ajax了，很多用户对数据的加工都是通过Javascript来实现的。
所以，想学习mashup开发的，Javascript是无论如何也绕不过去的， 至少在现在。不知道Google的Mashup Editor出来以后能否简化这些开发。
之前使用过Google Translate的印象都不是很好，最近在用Wordpress的slug翻译的插件时，又有机会发现Google translate的翻译质量已经有了不小的进步，一些比较简单的文章翻译的像模像样了，对我这种英文看起来CPU占用率很高的人还是有些帮助的，而且现在Google translate在显示翻译后的Web页面时，将鼠标停在翻译后的语句上就可以看到弹出的原文，很不错的对照。
于是就按照这里的网页指示将Google translate加入到Firefox的bookmark中了，以后看到想翻译的网页，点一下这个书签（实际上是一段Javascript代码）就可以立刻调出Google translate翻译了。
更进一步，我不想每次都打开bookmark toolbar（会占据宝贵的屏幕空间），于是在firefox的toolbar customize中折腾一番，发现bookmark item是可以直接拖放到navigation toolbar中的，也就是将两个工具条合一了，这样就节省了屏幕空间，还可以很方便的调用Google translate，终于满意了。; )
我在Windows下也是使用Firefox居多的，最近却遇到一个很不爽的问题，Firefox下剪贴板不能用了，Ctrl-C/Ctrl-V都不好使了，还好有Google，找到了解决方法，原因可能是中了个木马，在注册表里删除相关的表项就可以了。
回忆了一下搜索过程，开始我用“firefox clipboard”来搜，找到的大部分都是介绍如何在firefox下使用剪贴板的文章（比如在Javascript中操作剪贴板什么的），想了一想，换用“firefox clipboard error”来搜，仍然找不到有用的信息。又换了一些关键词，直到换成“firefox clipboard not working”时终于在第一条返回了我要的信息（上面那个链接），我要记住以后遇到类似的问题，记得用“not working”，不错，又学了一招。
掌握描述一些常见问题的搜索关键词，对于有效使用搜索引擎找到解答是如此的关键，我把我知道的一些晒一下：
Gcalcli是一个python编写的Google calendar的命令行客户端，重度的Google日历使用者可能会比较喜欢，因为命令行的好处是用起来比较快，且可以批处理，多快好省，下面记述在Ubuntu下的安装及使用步骤。
下载Gcalcli
因为有一些依赖的库，所以下载涉及好几个部分：
后面两个模块是可以apt-get的，不过我发现Ubuntu 7.10下apt-get的这些模块不够新，会导致运行出错，还是直接从上面的网址下载比较好。
修改Gcalcli源码
如果你在google 日历中也使用中文信息的话，需要注释掉gcalcli代码中前面的两行，否则中文会乱码：
sys.stdout = codecs.getwriter(locale.getpreferredencoding())(sys.stdout)
sys.stdin = codecs.getreader(locale.getpreferredencoding())(sys.stdin)
如果不想每次都敲google帐号名和密码，可以修改代码中的__username__和__password__，这样以后就不用输入这些信息了（虽然有点不安全，但方便要紧）。如果不改的话，则每次在使用gcalcli时都要加入 --user --pw 这样的参数。
命令行使用
Slug就是一个帖子的缩略标题，常用来作为URL的一部分（在Wordpress中，这是可设置的），在后台发帖子的时候就可以看到一个Post Slug的设置，如果不填的话，Wordpress会自动将帖子的标题（Title）转换为Slug，所谓的转换就是转到URL格式，比如“test blog"就会被转成"test-blog"，空格被替换了，这才能作为合法的URL，当然如果有多个帖子的Slug恰好相同的话，没有关系，Wordpress会自动在后面加-1,-2之类的数字，反正保证每一贴都不同，这也是为了做URL方便。
但如果标题是中文，Wordpress就不那么智能了，Slug就可能会自动变成了一堆"%230"之类的外星语，煞是难看，于是就有人想干吗不用拼音呢？起码比外星语好读一些，更有甚者会想，应该将title翻译成英文，再转换为Slug不就更漂亮了吗？ 但是所有这些Wordpress都不会替我们做，于是各路神仙开发了不少Wordpress插件，来完成这样的理想，其中的一个神仙开发了wp-slug，这个插件实现了上面的想法（翻译是找的Google translate），先翻译，翻译不成就转拼音，最后成Slug，这样就不用每次费劲脑汁的想那个Slug了。
对于已经有大量帖子的人（比如我），也是有办法的，另一个神仙实现了一个批量Slug转换插件，但是这个插件只是调用了Google Translate，而没有实现拼音的转换，不过这个插件是直接修改数据库的，所以一定要小心使用，用完了禁用插件。
我测试的结果是两个插件都可以工作，但是Google似乎对这种来自“机器人”的翻译请求有限制，如果请求过频繁，就会封ip一段时间（对那个批量转换插件尤其不利），所以经常会遇到翻译不成功的情况，真是晕。
不能免俗，也稍微研究一下搜索引擎，毕竟已成了我的blog的第一大访问来源，总要研究一下它们的兴趣爱好，更好的为它们服务。
我看中的收录速度主要是指从发帖到收录到搜索引擎的间隔，一般某个帖子被收录有两种情况：
虽然两种收录都包含了新发的帖子内容，但后一种情况下，将来被用户搜索命中的概率要高很多，这是因为单独的帖子通常包含有意义的Title，首页则没有，而Title在搜索时的权重非常大，因此后面一种收录情况的意义更大，但搜索引擎通常收录首页要快的多，而收录帖子所在的单独一页要慢一些。
我实际的观察结果是：两种收录都是Google快于百度，Google收录首页的速度快的惊人，一般是两三个小时搞定，而百度则要两三天。 对于单独页面的收录，Google约要一个周，而百度约两周。
当然这些数据是和每个网站相关的，我的数据来自于同一个网站，所以才有一些对比性，另外Google的惊人首页收录速度我认为是和Wordpress的Ping服务有关（Ping是指在新贴发出之后，自动通知相关搜索引擎，因此有点象TCP/IP网络中的”ping“服务）。
刚用上Google Analytics那会，每天都去看统计数据，也是Google做的好，里面数据翔实丰富，很有看头，渐渐的，发现每次去看Web页面还是挺费事，也试用过基于Adobe AIR的客户端，可能是客户端优化的不是很好，使用体验和直接Web浏览差不多。
后来发现Google Analytics可以提供Email报表功能，可以按照预定的周期（比如每天，每周等）发送各种类型的报表，诸如Dashboard，Traffic Sources，Visitors等报表，都可以直接发送到设置好的邮箱中，报表也可以选择格式，比如文本、Excel（Google居然支持这个）、PDF等，我自然是选择了PDF。
在阅读我的报表时发现PDF中的中文都是乱码（OMG，又是中文。。。） ，很是沮丧，这样一来，诸如搜索关键词等重要的信息就看不到了。垂头丧气之际，发现Gmail对于PDF附件，有一个View as html的选项，点这个来看PDF，中文就好了，实乃意外之喜。
以Google在业界的地位，加上手机操作系统这样的热门领域，Google的手机操作系统Android想不火都不行，喜欢品尝新鲜的我自然也来尝试一下了。
Android是什么
简单的说，Android是操作系统，不过这个等于是废话，更准确一点，Android是基于Linux/Java组合的操作系统，Linux几乎是众望所归，但在Java的选择上，多少有些出乎意料，Java成了Android世界的唯一官方语言（连C/C++都被暂时抛到一边了，以后也许会支持），而且Google非常“意外”（或者说野心也好）的抛弃了Sun的J2ME（Java对应移动设备的版本），而是完全实现了新的类库和应用程序框架，甚至连虚拟机也不放过，搞了自己的Java虚拟机，这一定令Sun相当的不爽，不知会不会再兴起一场波澜（当年的Sun大战 Microsoft还记忆尤新）。
不过看过Android的应用程序结构之后，也大概能明白Google的苦心了，Android应用程序在很多方面确实和J2ME有很大的差异，下面是我印象深刻的几点。
组件化
Android下，应用程序更像是一个个的组件，它们提供了对外的标准服务，也同时使用其它应用程序提供的服务，应用程序可能因为服务而被其它程序随时唤起运行，应用程序的边界已经变得模糊了。很多应用程序不提供退出选项，它们会在“适当”的时候由操作系统关闭。
Web化
Web是Google的实力所在，Google也把Web中的强势带入了Android，看看Android模拟器上那个大大的Back按钮，就可以感觉到这种趋势了，在Android下，与其说用户在使用不同的应用程序，不如说是用户在“浏览”Android的不同的“页面”，虽然我们看不到URL，但并不影响我们使用Back按钮感受如浏览器一般的体验。
炫目的界面
在UI上，J2ME与Android似乎不在一个层面，Google为Android配备了比J2ME丰富太多的UI，可以很明显的感觉到在UI上，Android的对手是iPhone而不是J2ME（虽然看起来在UI上，iPhone很难超越）。
试用
从Google的网站上可以很容易的下载Android的SDK和Eclipse插件ADT，有了这两个东西，理论上我们已经使用Eclipse开始Android开发了，我本想写详细的过程，不过发现没这个必要了，因为这篇文章已经解释的很清楚了。
我在Ubuntu下的测试发现，必须将Eclipse切换到Sun的jre才可以正常使用Eclipse/ADT（Ubuntu下我的Eclipse原来是用的gcj），否则连Android自带的例子程序都跑不起来，这一点是Google的文档中没有提到的。