HTC G7的576M Ram真的不够用，有些应用不能移到sd卡上，应用管理中”移到SD卡“这个选项是暗的。下文这个办法可以缓解一下这个问题：
安装好 HTC SYNC （主要目的是安装驱动程序），找一个android sdk 装好。
1、将手机与电脑用HTC SYNC方式连接
2、在电脑端，打开cmd，win7用户用管理员身份运行；
3、输入命令
adb devices （确认电话是否连接好）
adb shell
pm setInstallLocation 2
reboot
以上命令区分大小写
做好这些，很多原来不能移的应用就可以移了。不过还是有的应用不能移。
用了amazon的aws EC2做了反向代理。解决google的App engine被墙的问题。纯云计算啊!被逼体验高科技。不过还是要赞一下amazon易用，从决定要搞到完成只用了一个晚上和半个上午，大概5个小时。
amazon云计算平台aws EC2有一年免费期，先用一年，明年再看。
server {
listen 80;
server_name www.makenotes.net;
# access_log /var/log/nginx/ihfs_ghs_proxy.access.log;
location / {
proxy_redirect off;
proxy_set_header Host $host;
proxy_pass http://ghs.google.com;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect false; }
}
Trac的version维护中，日期的格式要和OS中的LANG设置匹配，否则报日期格式错误。通常是设置为export LANG=en_US.UTF-8比较好，这样应该没有问题。（猜想和trac Repository 建立是采用的LANG相关，因为系统重装后就会有问题）
另： Linux记录系统默认使用语言的文件是/etc/sysconfig/i18n，这里可以设置缺省的LANG变量
刚买回来G7不能用GPRS上网，搜了好多帖子，都是指导设置无线网络和设置->移动网络设置->接入点名称，按照指引设置了
1.名称：cmwap（此项可任意输入）
2.APN：cmwap（接入点名称）
3.代理：10.0.0.172
4.端口：80
5.用户名：（空）
6.密码：（空）
7.服务器：（空）
8.MMSC：（空）
9.彩信代理：（空）
10.彩信端口：（空）
11.彩信协议：WAP 2.0
12.MCC:460
13.MNC:00（此项为默认，勿修改）
14.APN类型：（空）
然后，按MENU 选择 “保存”。就会自动退出，出现一个接入点的设置，此点可以选择，右边有个点。
但是还是连不上，后来又查到一个，上面写了：
进入电话拨号状态，输入： *#*#4636#*#* ，输入完毕会自动呼出手机信息设置。点击左下角的切换DNS检查按钮，使按钮旁边显示：0.0.0.0 allowed。（原来显示是 0.0.0.0 not allowed）
作了这个步骤，然后GPRS就通了 ：）
后来发现还是不通的，又增加了一个接入点 cmnet，才真正通了。
1.名称：cmnet（此项可任意输入）
2.APN：cmnet（接入点名称）
3.代理：（空）
4.端口：（空）
5.用户名：（空）
6.密码：（空）
7.服务器：（空）
8.MMSC：（空）
9.彩信代理：（空）
10.彩信端口：（空）
11.彩信协议：WAP 2.0
12.MCC:460
13.MNC:00（此项为默认，勿修改）
14.APN类型：（空）
一块Swatch的手表坏了，用了两年不到。送去维修，说是人为破坏，要维修的话要送到瑞士去，运费由我承担！我在中国买的，承诺的两年保修，我送到你的维修点，你修不了，运费要我承担，这就是敲诈。我的目标很明确，维修，就是我把坏的表给你，你修好后把好的表还给我。
你在中国卖货，不在中国建立售后支持体系，这已经问题很大了，寄来寄去要耽误我的时间，这还不算，因为你售后服务不健全，产生的额外成本还由消费者来承担？你的手表售价中已经包含了售后服务的钱啦，运费要400块，你还不说要把瑞士的维修中心搬过来，每年租金2000W，也要我来付，真是岂有此理。
Facebook 成了开放平台，Twitter也成为了开放平台，Taobao也成了开放平台，新浪围脖也开放了，腾讯也马上就开了。这个大潮涌了过来，每个公司都作开放平台吗？特别是中小企业。
作开放平台需要很大的投入，都一窝蜂的开发平台，内容和应用谁来做？平台，市场上也就能容纳不多的几个吧。
别人开放了，在他的平台上去获得自己的收益，openID获得他们的用户，APP去做推广，挣现金。
基于他人的平台是会受制于人的，但是在中国做互联网不是都受制于ISP吗，要拔你的网线你敢放个屁吗，难道还要自己铺线路？做短信完全受制于移动，但是有多少公司是因为这个起家了？所以这个也是伪命题，没有什么是不受制于人的。
自己做不了，就不要做，利用别人也挺好。我挖不到金子，卖牛仔裤、帐篷不也能挣钱嘛。
一直使用http://www.you8g.com/的免费反向代理服务，最近时间http://www.you8g.com/极不稳定。在GAE论坛http://gaebbs.xibu.biz/上找到个类似的代理服务：http://app.chinasb.org/，也是免费的。具体设置方法和you8g相同。更换后不到十分钟时间即可访问。如果需要类似代理的可以前往加入。
在代理后的新版的msn也需要设置winhttp的proxy，就像windows update和mse的更新一样，用netsh winhttp set proxy 命令，参看
遇到的问题换了环境，代理换了，登陆时出现错误 80048439或者80048406，检测互联网都是通的，主要端口显示各黄色的感叹号警告。修复后提示你要设置防火墙，检测状态互联网通windows live服务不通。
设置了代理就正常了，应该说windows 的检测和建议都不是很正确，网络上也没有什么有价值的信息。
还可以用命令 netsh winhttp import proxy source=ie 这样可以直接导入IE的代理设置，比较方便。
3Q之争最火热的时候，我当时的看法是“360杯具了” “疯狂的360，离死不远了”，现在回头再想的话，这里漏掉了一个在天朝最为重要的力量，不考虑这个力量，任何模型都是脆弱的，不堪一评。
Thu, Mar 14, 2002; by Dave Winer.
原文链接: http://www.xmlrpc.com/metaWeblogApi
Document status 
This document was updated on 8/8/03, to incorporate all the RFCs related to the MetaWeblog API. The earlier version of the document is archived here. It has been reviewed by members of the MetaWeblog API mail list, and feedback has been incorporated.
On 8/24/03, I posted a last call for comments, and received several and incorporated some.
As of 8/26/03, this document is deployable. There may be changes, but they will be clearly documented, and will only clarify the spec, in no way will they change the format or protocol. It is now safe to deploy applications based on this spec.
What is the MetaWeblog API?
The MetaWeblog API (MWA) is a programming interface that allows external programs to get and set the text and attributes of weblog posts. It builds on the popular XML-RPC communication protocol, with implementations available in many popular programming environments.
Relationship between MetaWeblog API and the Blogger API
The MetaWeblog API is designed to enhance the Blogger API, which was limited in that it could only get and set the text of weblog posts. By the time MWA was introduced, in spring 2002, many weblog tools had more data stored with each post, and without an API that understood the extra data, content creation and editing tools could not access the data.
At the time of this writing, summer 2003, most popular weblog tools and editors support both the Blogger API and the MetaWeblog API.
Relationship between MetaWeblog API and RSS 2.0
The MetaWeblog API uses an XML-RPC struct to represent a weblog post. Rather than invent a new vocabulary for the metadata of a weblog post, we use the vocabulary for an item in RSS 2.0. So you can refer to a post's title, link and description; or its author, comments, enclosure, guid, etc using the already-familiar names given to those elements in RSS 2.0. Further since RSS 2.0 is extensible, so is the MetaWeblog API. We have designed conventions for representing attributes and namespaces in MWA.
Basic entry-points
There are three basic entry-points in the API:
metaWeblog.newPost (blogid, username, password, struct, publish) returns string
metaWeblog.editPost (postid, username, password, struct, publish) returns true
metaWeblog.getPost (postid, username, password) returns struct
The blogid, username, password and publish params are as in the Blogger API. newPost returns a string representation of the post id, again as defined by the Blogger API. The struct is where the juice is.
The struct
In newPost and editPost, content is not a string, as it is in the Blogger API, it's a struct. The defined members of struct are the elements of <item> in RSS 2.0, providing a rich variety of item-level metadata, with well-understood applications.
The three basic elements are title, link and description. For blogging tools that don't support titles and links, the description element holds what the Blogger API refers to as "content."
Where an element has attributes, for example, enclosure, pass a struct with sub-elements whose names match the names of the attributes according to the RSS 2.0 spec, url, length and type.
For the source element, pass a struct with sub-elements, url and name.
For categories, pass an array of strings of names of categories that the post belongs to, named categories. On the server side, it's not an error if the category doesn't exist, only record categories for ones that do exist.
In getPost, the returned value is a struct, as with the Blogger API, but it contains extra elements corresponding to the struct passed to newPost and editPost.
The server must ignore all elements that it doesn't understand.
In a call to metaWeblog.newPost or metaWeblog.editPost, if the struct contains a boolean named flNotOnHomePage, then the post does not appear on the home page, and only appears on the specified category pages.
Request and response
Here's an example of a request and a response.
Here's the post that this request is getting info about.
metaWeblog.newMediaObject
metaWeblog.newMediaObject (blogid, username, password, struct) returns struct
The blogid, username and password params are as in the Blogger API.
The struct must contain at least three elements, name, type and bits.
name is a string, it may be used to determine the name of the file that stores the object, or to display it in a list of objects. It determines how the weblog refers to the object. If the name is the same as an existing object stored in the weblog, it may replace the existing object.
type is a string, it indicates the type of the object, it's a standard MIME type, like audio/mpeg or image/jpeg or video/quicktime.
bits is a base64-encoded binary value containing the content of the object.
The struct may contain other elements, which may or may not be stored by the content management system.
If newMediaObject fails, it throws an error. If it succeeds, it returns a struct, which must contain at least one element, url, which is the url through which the object can be accessed. It must be either an FTP or HTTP url.
metaWeblog.getCategories
metaWeblog.getCategories (blogid, username, password) returns struct
The struct returned contains one struct for each category, containing the following elements: description, htmlUrl and rssUrl.
This entry-point allows editing tools to offer category-routing as a feature.
metaWeblog.getRecentPosts
metaWeblog.getRecentPosts (blogid, username, password, numberOfPosts) returns array of structs
Each struct represents a recent weblog post, containing the same information that a call to metaWeblog.getPost would return.
If numberOfPosts is 1, you get the most recent post. If it's 2 you also get the second most recent post, as the second array element. If numberOfPosts is greater than the number of posts in the weblog you get all the posts in the weblog.
Transmitting elements with attributes
The members of the struct passed in newPost and editPost come from the elements of items in RSS 2.0. The most commonly used core elements have no attributes, so it's clear how to include them in the struct. However, some elements, such as source, enclosure and category, may have attributes and a value. Here are a simple set of rules for elements that have attributes and a value. Note that these rules do not apply to enclosure and source, which are provided for specifically above.
1. If an element has attributes, then represent the element with a struct, and include the attributes as sub-elements of the struct.
2. If an element has both attributes and a value, make the element a struct, include the attributes as sub-elements, and create a sub-element for the value with the name _value. Note that this means that no element can be passed through the API that has an attribute whose name is _value.
Transmitting elements from namespaces
RSS 2.0 allows for the use of namespaces. If you wish to transmit an element that is part of a namespace include a sub-struct in the struct passed to newPost and editPost whose name is the URL that specifies the namespace. The sub-element(s) of the struct are the value(s) from the namespace that you wish to transmit.
Comments
The Blogger API provides a parameter called appkey that allows vendors to assign a key to developers so they can track and possibly limit usage of the API for certain tools. The MetaWeblog API doesn't specifically provide a parameter for an appkey. Applications that wish to transmit an appkey should add an element to the struct called appkey and set its value to the appkey that should be associated with the call.
Applications should use the fault-response scheme defined by XML-RPC. For example, trying to create, get, or edit a post without a valid username-password should generate a fault. Client applications should display the error string, as appropriate, to the user, for example, in a dialog, or in a server log.
Thanks
Thanks to Michael Bernstein for help editing this spec in summer 2003.
References
RSS 2.0; Dave Winer; 9/02.
RFC: MetaWeblog API; Dave Winer; 3/02.
Blogger API; Evan Williams; 8/01.
ManilaRPC; Andre Radke, Brent Simmons, Dave Winer; 1999.
XML-RPC; Dave Winer; 1998
