nullTao | 净空无道 | Blog

看图说话：耿氏凉面

nulltao@gmail.com (Wei Geng) — Sat, 06 Sep 2008 00:30:10 +0800

今日晚饭：炸酱凉面，做法简单，口味独特，实乃耿氏厨艺精髓之体现。

五花肉糜、四川甜面酱、香菇丁、葱花熬得如此炸酱，可惜南京找不到六必居的干黄酱买，口味大打折扣……虽然还是那么好吃。想起来小时候帮厨的时候用水去化那个像便便一样的美味的干黄酱的情景了。

配上黄瓜丝，清脆可口，不过偷懒，没有自己手擀面，市场上买得机制手工面，聊胜于无。

右上角是室友赞助的干瘪小葱（买了块一个星期了）拌老豆腐，撒花～～～～～

顺便翻出来上个星期的芝麻酱凉面配剁椒木耳：

开拌前的：调好的芝麻酱一小碗，陈醋蒜泥一小碗，过水凉面一晚，黄瓜丝半根。

拌好的样子，不过芝麻酱的颜色很浅，看得不是很清楚。

剁椒木耳，木耳香脆，陈醋微酸，配上剁椒蒜泥，简单美味。

看图说话：Google 大爱

nulltao@gmail.com (Wei Geng) — Sat, 06 Sep 2008 00:19:13 +0800

近三天 Google 颇为奇怪，RSS Reader 速度爆慢不说，还经常动不动就自己转向 Chrome 的一个介绍幻灯片的网站，难道 Google 知道偶不会这么快就用他的 Chrome，就用这种方式强迫我？

问了其他的几个用 RSS Reader 的朋友，都木有这种问题，怪哉。

RSS Reader 自动跳转……仔细看地址栏、Tab 标签标题和状态栏……

跳转后的 Slides，真丑……

一个 # 不够，那么就多来几个吧

nulltao@gmail.com (Wei Geng) — Wed, 03 Sep 2008 15:15:11 +0800

网页中经常要做的一件事情就是让一个链接来执行一个 JavaScript 脚本，例如：< href="#" onClick="some_js_here();">Some text</a>，不过这样的副作用是因为有 href="#"。所以导致点击完后页面会滚动到最上面。

以前用的几种解决方案：

不写 href，这样会导致很多浏览器不会把 a 标签按照你预期的方式渲染；
在href 里面直接写 JavaScript 脚本，这样不完全符合 W3C 的规范。

其实要解决这个问题，不让浏览器把页面滚动到最上面，很简单，href="" 里面多写几个 # 就行了，我一般用 6 个比较保险，这个方法适用于 IE5、IE6、IE7、FF2、FF3。虽然不知道为什么但是很好用。猜测是因为 # 表示进行页内书签的跳转，但是多个 # 浏览器就不知道什么意思了，干脆罢工好了，哈哈。

加入了原创博客联盟

nulltao@gmail.com (Wei Geng) — Thu, 28 Aug 2008 18:40:33 +0800

地图聚合的数据格式前三名：KML、GeoRSS 和 GeoJSON

nulltao@gmail.com (Wei Geng) — Thu, 28 Aug 2008 18:34:37 +0800

原文地址：3 Top Data Formats for Map Mashups: KML, GeoRSS and GeoJSON。

随着地图聚合给最终用户提供的一系列更广泛的工具和应用程序，它在完善程度和功能性两方面逐渐走向成熟。因此，我们需要一些预定义好的方法在传统的地理空间数据和新一代的地图聚合之间交换、发布这些地理空间数据，并且使用一种对 web 友好的方式使用这些数据。

为了满足这种需求，出现了一些新的地理空间数据格式，这能够让更大范围的用户和开发者来聚合地理相关的信息。下面是当前可供从事地理信息聚合的开发者使用的三种主要数据格式的一个概括：

KML

你知道 Google 地球的前身，那个流行的名为 Keyhole 的三维地球浏览器吗？如果你知道，那么这个基于 XML 的，Google 地球自己的文件格式被叫做 KML，意为 Keyhole 标记语言，就不值得惊讶了。在地理空间相关的网站上，KML 无处不在，KML 支持从类似 Google 地图、微软的虚拟地球这样商业化的地图 API 和 OpenLayers 这样开源的地图 API 中导入、导出数据。今年早些时候，Google 把 KML 作为一种开放标准发布，并且被开放地理空间联盟 (OGC) 采用。你可以研读最新的 KML 规范 (当前是 2.2 版) 或者学习如何让 KML 与 Google 地图 API、虚拟地球或者 OpenLayers 集成。

GeoRSS

GeoRSS 提供了一种在 RSS (或者 Atom) 种子里通过特定的编码来包含地理参考信息的方法。GeoRSS 站点上说：

RSS 和 Atom 作为一种发布、共享信息的方法，正在逐渐流行起来，因此，使用互操作的方式描述位置信息，来让程序能够请求、聚合、共享、地图化地理标记过的种子变得益发重要。

嵌入 GeoRSS 非常简单，仅仅在每个条目中增加一个类似 <georss:point>45.256 -71.92</georss:point> 这样的元素就行了，这里使用的是简易GeoRSS 格式，如果要需要复杂完整的编码格式，可以选择支持更多的特性的 GeoRSS-GML 格式。这两种 GeoRSS 格式都支持基本的地理特征 (点、线、边框和多边形)。和 KML 一样，商业化的地图 API 和开源地图 API 都支持 GeoRSS，并且主要作为导入数据的格式使用。 GeoRSS 许诺对整合内容的会有更好的支持。

GeoJSON

GeoJSON 是基于 JavaScript 对象表示法 (JSON)的一种新的数据格式，用来对大量的地理特征进行编码，支持的地理特征有点、线、多边形、多多边形和地理信息集合。

{ "type": "Point", "coordinates": [43.542, -118.454] }

GeoJSON 可以被 JavaScript 简单、快速的解析，而且 GeoJSON 还提供了一个可以很容易的进行交换的轻量级数据格式。自从 GeoJSON 正式发表 1.0 版后，GeoJSON 的魅力逐渐增加，得到了包括 FireEagle 和 OpenLayers 在内的一些流行的 API 的支持 (但是不确定将来是否能够得到类似 Google 地图或者虚拟地球这样的商业 API 的支持)。

注意 GeoRSS 和 GeoJSON 都采用创作共用授权协议授权。

我们饶有兴趣的看着这些格式如何发展，而且很想知道类似 GeoRSS 和 GeoJSON 这样的格式能否得到地图 API 和地图聚合开发者的采用。

解决 propel-convert-xml-schema 把 null 默认值处理为字符串的问题

nulltao@gmail.com (Wei Geng) — Thu, 21 Aug 2008 11:32:56 +0800

通过 propel-convert-xml-schema 把 xml schema 转化成 PHP 代码的时候，如果一个字符型字段不能为空且没有明确输入默认值，例如：

<column name="username" type="VARCHAR" size="128" required="true" default=""/>

生成的 PHP 代码中该字段的默认值是 'null' 而不是 null，导致页面输入框的默认值不是空值，而是一个字符串的 null，很恼火。因为要么在页面中每个字段都对 'null' 做特殊处理，要么修改生成的 PHP 类文件，但是一旦重新执行 propel-convert-xml-schema 就会重新覆盖。

解决办法：修改 propel-generator/classes/propel/phing/PropelCreoleTransformTask.php 文件（对于 Symfony 来说，就是 symfony/vendor/propel-generator/classes/propel/phing/PropelCreoleTransformTask.php）。应用如下 patch：

507,510c507
< //$node->setAttribute("default", iconv($this->dbEncoding, 'utf-8', $defValue));
< if(!empty($defValue)) {
< $node->setAttribute("default", iconv($this->dbEncoding, 'utf-8', $defValue));
< }
---
> $node->setAttribute("default", iconv($this->dbEncoding, 'utf-8', $defValue));

参见：#2045 (propel-convert-xml-schema generate null text as default values) - symfony - Trac。

下载：PropelCreoleTransformTask.7z。

在 Symfony 中结合使用 Structures/DataGrid、sfSmartView、Propel

nulltao@gmail.com (Wei Geng) — Mon, 18 Aug 2008 00:15:50 +0800

今天需要在 symfony 中使用 datagrid 型控件对一个分页+排序的表格进行展示。但是 sfDataGrid 写得实在是太糟糕了，没有找到其他的比较好的 plugin。

PEAR 中的 Structures/DataGrid 倒是不错。但是两个问题：无法和现在偶使用的 sfSmartyView 直接结合，因为在 $datagrid->fill($smarty); 的时候，symfony 还没有生成 view instance，除非直接获取生成的 HTML_TABLE 或者类似的结果，这样不利于 MVC 的分离和对具体样式的控制；二是现有的 datasource 无法和 symfony 使用的 propel 直接结合，如果采用检索全部结果再传递给 Structures/DataGrid 进行分页处理，那么效率非常低下。

于是自己写一个 datasource，并且使用了一点技巧解决和 sfSmartyView 结合的问题。

Structures_DataGrid_DataSource_Propel 类的定义：

class Structures_DataGrid_DataSource_Propel extends Structures_DataGrid_DataSource {
protected $criteria = null;
protected $con = null;
protected $object = null;
function __construct($object, $criteria, $con = null) {
parent::Structures_DataGrid_DataSource();
$this->object = new $object();
$this->criteria = $criteria;
$this->con = $con;
}
function count() {
//TODO: this is not a good way, due to MySQL Bug #21787
$this->criteria->setLimit(0);
$this->criteria->setOffset(0);
$result = $this->object->doCount($this->criteria);
return $result;
}
function sort($sortSpec, $sortDir = 'ASC') {
switch (strtolower($sortDir)) {
case 'asc' :
$this->criteria->addAscendingOrderByColumn($sortSpec);
break;
case 'desc' :
$this->criteria->addDescendingOrderByColumn($sortSpec);
break;
default :
return PEAR::raiseError("Sorting dir must be ASC or DESC!");
}
return true;
}
function fetch($offset = 0, $len = null) {
$c = $this->criteria;
$c->setOffset($offset);
if (! is_null($len)) {
$c->setLimit($len);
}
$objects = $this->object->doSelect($c);
$result = array ();
foreach ($objects as $object) {
$result[] = $object->toArray(BasePeer::TYPE_COLNAME);
}
return $result;
}
}

action 中的代码段：

public function execute() {
// get data source
$c = new Criteria();
$datasource = new Structures_DataGrid_DataSource_Propel('SysUiaAccountPeer', $c);
// setup datagrid
$datagrid = & new Structures_DataGrid(10);
$datagrid->bindDataSource($datasource);
$datagrid->setDefaultSort(array (
SysUiaAccountPeer::USERNAME=>"DESC"
));
$datagrid->addColumn(new Structures_DataGrid_Column('用户名', SysUiaAccountPeer::USERNAME, SysUiaAccountPeer::USERNAME, array (), ' ', ''));
// add more columns here
// use a tip to get output using smarty
$smarty = $datagrid->setRenderer('smarty');
// set pager params
$pager = $smarty->smartyGetPaging(array (
'prevImg'=>"上一页", 'nextImg'=>"下一页", 'separator'=>"|", 'delta'=>"5", 'clearIfVoid'=>true, 'spacesBeforeSeparator'=>"1", 'spacesAfterSeparator'=>"1", 'firstPageText'=>'第一页', 'lastPageText'=>'最后页'
), $smarty);
$this->dg = $datagrid->getOutput();
$this->pager = $pager;
return sfView::SUCCESS;
}

模板中的处理：

<table>
<tr>
{section name=col loop=$dg.columnSet}
<th{$dg.columnSet[col].attributes}>
{if $dg.columnSet[col].link != ""} <a href="{$dg.columnSet[col].link}">{$dg.columnSet[col].label}</a>
{if
$dg.columnSet[col].name == $smarty.request.orderBy} {if
$smarty.request.direction == "ASC"}↑{elseif
$smarty.request.direction == "DESC"}↓{/if} {/if} {else}
{$dg.columnSet[col].label} {/if}</th>
{/section}
</tr>
{section name=row loop=$dg.recordSet}
<tr {if $smarty.section.row.iteration is even}bgcolor="#EEEEEE"{/if}>
{section name=col loop=$dg.recordSet[row]}
<td{$columnSet[col].attributes}>{$dg.recordSet[row][col]}</td>
{/section}
</tr>
{/section}
<tr>
<td colspan="...">{$pager}</td>
</tr>
</table>

MySQL 对于 COUNT(*) 和 LIMIT 同时使用的 BUG

nulltao@gmail.com (Wei Geng) — Sun, 17 Aug 2008 23:53:05 +0800

对一个有 29 条记录的表进行如下操作：

SELECT COUNT( sys_uia_account.ID ) FROM sys_uia_account
结果 29
SELECT COUNT( sys_uia_account.ID ) FROM sys_uia_account LIMIT 10
结果 29
SELECT COUNT( sys_uia_account.ID ) FROM sys_uia_account LIMIT 10 , 10
没有结果

看来以后使用 COUNT(*) 的时候不能同时使用 LIMIT offset, row_count 这种表达方式了。

PS：如果统计全表记录，使用下面的方法会更加快捷：

SELECT SQL_CALC_FOUND_ROWS *
FROM sys_uia_account;
SELECT FOUND_ROWS( ) ;

唯一需要注意的就是，这两个查询必须在一起进行，因为 SQL_CALC_FOUND_ROWS 不对结果进行任何缓存。

MySQL 中用 GKB 来让 UTF-8 字段中的中文按照拼音排序

nulltao@gmail.com (Wei Geng) — Sat, 16 Aug 2008 15:39:24 +0800

UTF-8 中的中文不是按照拼音排序的，因此对于使用 UTF-8 编码集的字段就无法按照拼音进行排序，最简单的解决方法就是转成 GBK 编码。

实例代码：

SELECT *
FROM `test`
ORDER BY CONVERT( `test`.`name`
USING GBK )
LIMIT 0 , 30

数据库表结构：

CREATE TABLE IF NOT EXISTS `test` (
`id` int(3) NOT NULL AUTO_INCREMENT,
`name` varchar(10) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=1 ;

测试环境：Windows 2003 Standard Edition，MySQL 5.1.22-rc-community。

对于偶正在使用的 Symfony 框架，因为使用了 propel 做 ORM，比较难直接操作SQL，除非使用 RAW SQL，而且使用 RAW SQL会导致很多高级特性无法使用，解决方式：

$criteria->addAscendingOrderByColumn('CONVERT(' . TestPeer::NAME . ' USING GBK)');

胡言乱语之奥运会

nulltao@gmail.com (Wei Geng) — Fri, 08 Aug 2008 13:07:49 +0800

在偶看来，奥运会就是一群没有大脑的国人庆祝自己纳的税被浪费掉还欢呼鼓掌发自肺腑的庆祝的脑残盛会。
本来说不看开幕式的，不过想想还是看看吧。看看张艺谋这次是怎么糟蹋中国文化的。

让 Firefox3 支持 Flash

nulltao@gmail.com (Wei Geng) — Wed, 18 Jun 2008 11:49:37 +0800

Firefox3 在 beta 和 RC 阶段对 Flash 支持的不好是臭名昭著，用 Google 随便搜索 Firefox3+Flash 看看结果就知道了。

Beata 和 RC 不支持吧。还能说是 bug，今天正式版发布，居然还是不支持，这就说不过去啦。用 Firefox 内嵌的 addons 管理机制安装 Flash 从来就木有成功过。

最后用如下方法才安装成功：

下载 Adobe 官方的 FLash 卸载程序；
下载 Adobe 官方的 Flash 安装程序；
关闭 Firefox；
运行卸载程序，再运行安装程序；
如果有必须要，则重建 Firefox 插件数据库。

最后一步不是必需的，至少偶就木有用到。

现在终于能够看到满屏的 Flash 了……下一步，安装 flashblock 插件屏幕它们～hiahia～～

参考：FIrefox 3 and Flash pluggins 。

做好准备迎接新的平台大战。Google Gears 直指微软领地

nulltao@gmail.com (Wei Geng) — Mon, 16 Jun 2008 11:06:36 +0800

原文：Get Ready For A New Platform War. Google Gears Drives Straight At Microsoft’s Profits.。

Google 在去年五月发布了 Gears，之后的一年里 Gears 被认为是一个小众产品，只会有很少开发者和用户用它来开发能够离线访问的 web 程序。兴许你还能回想起当年的争论：在到处都有网络连接的情况下，究竟谁需要离线访问功能，而且还没有足够的程序支持，等等。不到一年的时间，就在几周前，Google 亮出了他的王牌：Gears 助力 MySpace 加速邮件系统。其实 Google 早就加入了这场提供新 web API 的比赛，但是居然一年了都没有人注意到。

将来的浏览器很可能会变成运行所有程序的虚拟机。在这种情况下，操作系统会变的透明，就像 Adobe 所作的，它的 Flash 技术是现在使用的最普遍、最统一的 web 虚拟机，而微软则要自保（它的利润的来源）了。Google 不隐瞒他们想瞄准并且攻击微软的野心，他们知道，要做到这点的最好方法就是上移一层把操作系统架空，让浏览器成为标准且强劲的应用程序虚拟机。

很难在一片评论里表达清楚 Gears 如何改变并且增加 web 程序的功能。以前使用基于浏览器的 Javascript 脚本，MySpace 中的一些类似邮件列表和排序、根据好友列表过滤这样的功能会让人感觉很慢，而当浏览器向服务器发送多个请求时，进度条还可能会定住，沙漏图标在不停的旋转。而现在，安装 Gears 只要在确认框点击一下并且等待几秒钟，安装之后，以前让用户抓狂的那些功能现在感觉起来就好象是浏览器自带功能一样。Google 给我们秀了一把 Gears 与 MySpace 集成后的能力，这唤醒了大部分人关注他真正的意图：不再仅是离线浏览，而是直接针对 Adobe 和微软所采取的行动。

截至目前为止，Google 拥有一系列共计 28 个基于 web 的程序, 这些程序在全世界有数百万的用户。Google 开发 web 程序的技术都是基于标准的 HTML、CSS 和 Javascript。选择 Ajax 仅仅是因为这是最好的解决方案，但是 Google 还要做更多以面对现实，那就是每个类似的 web 开发技术体系都是被一个直接的竞争者所开发、控制。Google 对开源浏览器 Firefox 的开发给予了强大的支持，并且支持开放 web 标准作为他们的技术体系之选。Google 这么做是因为他们的 web 程序都依赖于开放标准，Firefox 的失败会导致 Internet Explorer 复生并且把 web 的控制权拱手让给微软。

以前，只用基于浏览器的 Javascript 来支持 web 程序对 Google 来说不是个问题。直到竞争者领先一步发布了他们自己的第二代 web 平台，分别是 Flex/AIR 和 Silverlight，情况才发生了变化。基于 web 的程序在有了类桌面的界面和功能后能够做什么，从这一方面开说，微软和 Adobe 已经超前了一大步。用不了多久，大大小小的竞争者就会使用竞争性技术平台创建竞争性程序，那会使 Google 的产品看起来像是还停留在上个世纪九十年代的样子。

留给 Google 的选择现在很明了了：要么放弃使用基于浏览器的 Javascript 和开放标准进行开发，转而接受新技术中的一种，要么继续坚持使用核心 web 技术并且发展这些技术直到成为可行的替代技术。Google 的问题是，新标准和预期的浏览器功能很快就会带来富 web 技术，但是开发那些标准的进度却如此缓慢，以至于很可能需要几年时间才能看到那些标准被广泛的应用。新的 HTML 标准，HTML5，特别关注扩展本地浏览器对 web 程序的支持能力，在不用附加私有运行时的情况下。Google web API 的基础就是这些同样的功能以及其他的附加功能。

由于标准开发的极其缓慢，导致通向更快更好，而且仍旧免费开放的 web 程序之路被堵死了，所以 Google 决定通过 Gears 自己进入这个市场。想法其实很简单：把明天的 web 技术带到今天的浏览器里。这些特定的功能大部分都来自新的 HTML5 规范，但是标准制定小组已经在上面花费了好几年。不想再等这个小组完成规范，Google 自己通过件对浏览器进行扩展，实现了这些功能并且达到了那个小组能达到的最高水平。他们宁愿在短期内抛弃标准（原话是“以后再考虑实现”）也要把他们的 web 程序带到能够对抗 Flash 和 Silverlight 的下一代标准。

Gears 有一个 30 人左右的小组开发，这个小组是 Google 内部开源小组的一部分。这个小组由 Vic Gundotra 带领，再一次讽刺的转变过程中，他由微软的传教士成为 Google 的高级开发者。这个一小组开发者着手进行开发，并且保持 Google 对 Javascript 和开放浏览器虚拟机的兴趣。理论上，他们看起来很可能被大组织或者微软和 Adobe 正在投入各自平台的预算所超过。为了改变这个状况，他们把 Gears 从 Google 中分离出来（字面上也是——现在这个项目名称就只是“Gears”）并且在开源协议下发布源代码。

第一个发行版将只关注于 HTML5 里面提议的新功能中他们认为最重要的功能：基于客户端的结构化数据和对象存储。由于选择了首先实现客户端存储，所以下一年里 Gears 会被构架成一个离线应用程序解决方案，由于其他的竞争者好像都没有注意到这个这么巨大目标，所以如果他们不是有意而为之，那么肯定会发展的很好。Google 本来有可能开发他们自己的浏览器，某些博客里的推测和谣言也都指出了这一点，但是浏览器市场竞争激烈，却平淡乏味，而且通常会失败。另外，即使他们开发了自己的新浏览器，他们还要驱使用户接受这个新浏览器，在决定性的市场聚集起来之前只能等待，就是这样，市场上还会有 70% 或者 80% 甚至 90% 的人不使用 Google 的浏览器，却想使用 Google 的程序。

这种情况下，可选的捷径就是跳过浏览器直接在上面增加一层——Google 自己的 web 层。所有常用浏览器都提供了让开发者扩展功能的机制，这样一来，Google 要做的就是对每个浏览器开发对应的插件。这能让新的 web API 能够适应所有的桌面而不需要用户去适应，最重要的，这比起进入浏览器市场来说见效快而且痛苦少。现在可以让浏览器来做所有无聊的事情：渲染 HTML、显示界面、用户选项等等，与此同时 Google 却在改变现状，埋头向前冲。

现在 Gears 支持大量完整的新功能，有一些新功能是和微软、Adobe 他们的下一代 web API 相同的，而其他的则是 Google 自己创造出来的。现在函数调用已经对开发者开放了，包括后台处理（不会再有沙漏出现）、客户端图像处理、位置感知、更好的文件上传功能，还有浏览器内本地数据库。

要让新 API 和开发平台的应用被采用需要两方面的支持，一方面是用户的支持，因为这需要用户安装新的插件；另一方面是开发者的支持，使用 Gears 不会让开发变得更容易，这是因为这和开发其他的使用基于浏览器的 Javascript 的程序没有区别，Gears 只是给开发者提供了一系列更多的可以在浏览器内实现的功能而已。Javascript 和 web 开发者不需要学习任何新知识，用户也要做的也只是安装一个插件（与浏览器绑定的交易肯定会发生，所以这一步都可以忽略了）。Flash 花了 5 到 6 年才足够普及，能够让开发者有信心专注于使用 Flash 开发，不过有了 Google 的支持，Gears 可能只需要用一半甚至更小的时间就能做到。

在这场竞赛中，Google 没有任何损失反而赢得盆满钵丰，Google 一下子就启动了这个新 web API 的基于标准且开源的替代方案。与其他的竞争对手不一样，Google 没有兴趣控制这个平台或者直接用来盈利。相反他们却在试图维持现状：大部分程序使用浏览器里的 Javascript 开发，如果有更多需求那就使用 Flash 或者类似的技术。

上一次平台大战结束了很久了，但是每次你都能看到类似的技术经验：大公司失败，小公司成功。给这个平衡增加点开源的砝码，结果还是没有一个单独的公司能够占优势。有这么多大公司的加入，而且如此的利益攸关，我们肯定要亲眼见证一场漫长的持久战。只有时间能够告诉我们 Google 的做法能不能带领 web 向前发展。

本文是 Nik Cubrilovic 写的下一代 web 系列中的一篇，在这阅读其他同系列文章。