UCD大社区文章的收录原则 | 12 Sep 2008

22:29 富国租地种粮：食品安全还是新殖民主义？ » 中外对话新鲜出炉

资本丰厚却面临粮食危机的国家开动脑筋，在别国租地种粮。这究竟是一种“双赢”的想法，还是一种剥削的方法？哈维尔·布拉斯、安德鲁·英格兰报道。

沙特阿拉伯没有永久性的河流或湖泊，降雨量很少而且不稳定。要种植谷物只有经过昂贵的工程才行，而这会耗光地下水。在奶牛场里也必须用风扇和不断喷出水雾的机械来降温。简而言之，这决不是一个适合大规模农业的国家。

但情况将会有所变化。由于石油繁荣所带来的巨大收益，同时也出于对食品安全的关注，沙特正在全球寻找肥沃的土地，官员们已经前往苏丹、乌克兰、巴基斯坦和泰国进行考察。

他们的计划是在海外设立大型项目，种植玉米、小麦和水稻等粮食，逐渐还会吸引私人企业参加。沙特官员说，某国一旦被选中，每一个项目就会使用超过10万公顷——相当于10个曼哈顿岛的面积，生产的大部分粮食都会回销到本国。

然而沙特的计划并不是唯一的，它们反映了那些资本丰厚、食品主要依赖进口的国家对这类项目与日俱增的兴趣。阿联酋把目光投向哈萨克斯坦和苏丹，利比亚希望在乌克兰租地，韩国则瞄准了蒙古。就连中国（耕地充足但水不够用）也开始寻求在东南亚进行农业投资。

“这是全球粮食危机中的一个新动向，”华盛顿国际粮食政策研究所(IFPRI)所长约阿希姆·冯·布劳恩说，“今天的主导力量就是粮食供应安全。”

粮食出口国的贸易限制（如印度控制大米出口，乌克兰停止小麦外运，阿根廷向大豆出口征收重税）给进口国敲响了警钟，它们意识到对国际粮食市场的依赖将使它们变得更加脆弱，不仅是在价格的突然上涨面前，更致命的在于供应的中断。

于是，自从70年代以来，粮食安全第一次占据了政治议事日程的首要地位。“粮食危机给所有国家敲响了警钟，必须寻找地方来保障农产品供应安全。”沙特农业副部长阿卜杜拉·阿尔欧巴德说。

冯·布劳恩在接受《金融时报》采访时，也发表了和无数官员们同样的观点。他说，对国际粮食市场的信心正在丧失。自从九十年代初农产品贸易猛增以来，第一次有许多人开始怀疑依靠农业进口的正确性。“进口国很紧张，它们已经意识到最好还是在潜在的农业出口国拥有利益。”冯·布劳恩说。

全球粮食消费量不断增长，很大一个原因在于新型经济国家肉类膳食的需求，诸如沙特等国家在养活不断增多的人口上面临的挑战一年大似一年。粮食价格已经从今年初的最高峰有所回落，但仍然是过去十年的平均价格的三倍。

每一个海外农业投资的计划背后绝对都存在粮食安全的因素。最近，阿联酋总统谢赫哈里发·本·扎耶德在访问中亚的过程中指出必须锁定供应。他说：“阿联酋准备在哈萨克斯坦进行一些项目，作为确保本国稳定粮食来源的措施之一。”

对于那些耕地和水源丰富但缺乏资金的国家来说，这样的计划也很有意义。比如，尽管拥有世界上最肥沃的土壤和丰沛的降雨，乌克兰每公顷的小麦产量还不到3，000公斤。相比之下，美国每公顷产量可以高达6，500公斤，而且还不是在最好的条件下。但是，只要有更多的农业机械、多多增加肥料、改善技术、改良种子，情况将大有改观。

联合国国际农业发展基金会(IFAD)主席莱纳德·巴治指出，长时间以来，人们都把石油和矿产看得比土地更重要，“但现在拥有水源的肥沃土地已经成为了一种战略资产”。

一些国家已经掌握了这个资源的潜力。比如，苏丹正准备在其农业部门从阿拉伯和亚洲投资集团那里吸收至少10亿美元的投资。投资部正在筹划17个大型项目，总面积达到88万公顷。

埃塞俄比亚总理梅莱斯·泽纳维同样非常热情高涨。近日他在接见了一个沙特农业代表团之后说：“我告诉沙特客人，我国将非常乐于提供千百万公顷的耕地来接纳投资。”

然而这样的交易似乎会让粮食生产国付出沉重的代价。通过秘密双边协定，投资国希望能够绕过所有危机时东道国可能采取的任何潜在贸易限制。

尽管是否能像保护石油设施那样保护大片土地还是一个不确定的问题，对一些决策者来说，这让他们想起了一个噩梦般的场景：外国人把粮食运出肥沃的土地，本国的饥民却只能眼巴巴地看着。还有一些人指出，在一些法制环境较差的国家，正在发生土地抢夺，大多数农民都没有正式的土地证，也无法得到补偿机制的保护。

而农业自由贸易的倡导者们也担心：这些投资国的目的是建立粮食生产的所有权，而不是为国际市场增加供应。美国农业部长爱德华·谢弗表示，他非常关注这些投资是否仅仅是一种“规避国际市场和全球贸易协定”的手段。

欧洲农业官员们补充说，那些最贫困的缺粮国家——如西非国家，将成为最大的受害者：它们无力进行海外投资，而在国际市场缩减、价格上涨面前，它们是最脆弱的。

世界银行和联合国粮农组织(FAO)等多边国际机构最初曾经鼓励农业的海外投资，将其视为增加全球粮食产量的途径，然而它们也在调整之前的支持态度。

从世行行长罗伯特·佐利克的姿态中，可以很清楚地看到这种变化。当初，他把国家主导的农业海外投资说成一种“双赢行动”，而现在世行的一位发言人说：“这种情况可能给某些发展中国家的人民带来切实的益处，但为了实现可持续性，土地的买卖和租赁必须让包括东道国居民、当地社群和投资者的所有方面都受益，而且是切实可见的受益。”

粮农组织总干事雅克·迪乌夫身上也体现出同样的转变。当初，他曾经呼吁：“那些拥有财力资源的国家作为一方，那些拥有土地、水源和人力资源的国家作为另一方，双方达成合作协议。”

但是现在，他警告说这些投资具有“新殖民主义”的危险。“（东道国和投资国之间的）某些谈判已经导致了不平等的国际关系和短期的重商主义农业。”

巴治也认为这里会产生问题。“我们在讨论一些东道国，那里贫困饥荒遍地，我们必须保证当地人民能够从这些投资行动中分享到充分的收益。”

比如，在苏丹（几乎所有海湾投资国的目标），联合国负责应对粮食危机的组织——世界粮食计划署 (WFP)正养活着560万人。如果投资计划硬要继续进行下去的话，苏丹把粮食出口到富国而本国人却在挨饿。

中国官员支持政府为了确保在非洲的石油和金属等商品所采取的扩展政策，但同时他们似乎也注意到了海外农业投资的潜在危险。尽管中国和菲律宾、老挝等签订了农业协定，也在非洲开展了一些小型项目（大多数都是为当地培训农业技术的“示范项目”），但她似乎并没有什么兴趣进行大规模的海外农业投资。

“非洲还有那么多人在挨饿，你忍心把粮食运回中国吗？成本和风险都太高了。”中国农业部农业贸易促进中心副主任谢国力说。

但是，一些中国私人企业正在寻求农业投资，尽管官方说它们的着眼点在中亚而不是非洲。中国政府似乎对哈萨克斯坦等国潜在的冲突非常放心，而中亚的运输成本也较低。

联合国粮农援助官员们同样担心潜在的腐败，因为许多非洲和中亚国家的政治管理都比较无力。

他们建议建立一个类似“采掘行业透明度行动计划”(EITI)的框架机制来管理农业投资，这个机制将强制资源富饶国家公布企业支付的报酬，以及政府从石油、天然气和采矿得到的收益。

官员们说，EITI机制帮助解决了石油和矿产部门的腐败问题。但要建立一个类似的农业机制，需要用好几个月来谈判，但缺粮国家已经迫不及待。就在西方官员们讨论风险和保障的时候，沙特和其它国家似乎已经打算赶在下个种植季节之前租地了。

巴尼·乔普森参与了亚的斯亚贝巴的报道
来源：www.ft.com/
金融时报有限公司2008年版权所有

首页图片*MarS摄

支付宝 + FirefoxDBA notes » 车东在 Google 阅读器中共享的项目

作者：Fenng 发布在 dbanotes.net. | Feed 地址修改为：http://feedproxy.google.com/dbanotes

首先预祝大家中秋节快乐! 在下周，支付宝（中国）网络技术有限公司(Alipay.com)将正式发布针对 Firefox (火狐浏览器) 的支持环境。

可能还有用户记得，支付宝在 2007 年 7 月 31 日发布了一则《关于关闭 Firefox 等浏览器访问支付宝网站权限的通知》，这是出于安全方面的考虑不得不做出痛苦的决定，当时也引起了很多热心用户的关注。很多用户可能忽略了其中的一句话：

我们也会尽快解决 Firefox 与支付宝安全控件的兼容问题...

这是支付宝对 Firefox 用户的承诺。这一年多来，我们一直没有忘记这一承诺，也没有无视来自 Firefox 用户的更强烈呼声，我们一直在努力。可爱的工程师进行了艰苦的技术攻关，解决了众多技术难题。在进行了相对比较长的内部测试之后，我们终于可以宣布支付宝支持 Firefox 了!

功能说明

目前支付宝对 Firefox 支持的说明：

支持 Windows 平台的 Firefox ，支持版本：Firefox 1.5、2.0、3.x；届时还将提供自动安装功能，现在准备尝试的用户可以到 Mozilla 站点上下载支付宝安全控件(AliPay Security Control)(也欢迎广大 Firefox 爱好者在留言中给我们提一些反馈意见)；
目前在 Windows 平台下的 Firefox 下暂时还不提供对安全证书的支持，但是对安全证书的支持已经提上日程；
对 Linux 平台下 Firefox 的支持已经在内部测试中，预期近期内即可发布；

小贴士：对于重度 Linux 用户，网银是个老大难的问题。这里提供一个小窍门：申请一下支付宝的卡通，在 Windows 上一次设置好，每次需要充值或提现的时候就可以再不用特地打开个 Windows 虚拟机了。

此外，支付宝也从淘宝获悉，淘宝的工程师针对 Firefox 的旺旺协议也开发了相关插件。届时，用户能够在 Firefox 下实现完整的购物流程。

更大的想象空间

支付宝对 Firefox 的支持目标远不止于此，这里引用一段来自工程师的话：

在Firefox插件的研发过程中，我们也注意到，类似 ActiveX 的技术是所有的浏览器都支持的。也就是说，"支付宝安全控件"可以在几乎所有的浏览器上实现。但是，ActiveX 的 object 标签只被 IE 所支持，而非 IE 的所有浏览器，却支持相同的插件标准。换句话说，我们目前所开发的 Firefox 插件，未做任何修改，就可以较正常运行在苹果的 Safari，和 Google 的 Chrome 浏览器上。经过分析发现，除了接口方案稍有区别，其大体的结构，还有页面的Embed 标签等都是兼容的，相信经过后续的改进，为 Firefox 所开发的安全控件和所修改的页面，只花很小的代价就可以运行在苹果和谷歌的浏览器上，为支付宝赢得更多的关注和更多的客户。

这是支付宝的一小步，也是支付宝的一大步，相信也是中国电子商务的一个进步!

--EOF--

(本文首发在支付志，倒也不算转贴)

相关文章|Related Articles

浏览器, Opera or Maxthon or Firefox ? - Oct 10, 2006
闲聊 Firefox 中一键上传图片到 Flickr - Oct 14, 2006
Firefox 2.0 正式发布 - Oct 25, 2006
关于手机话费充值的方法 - Jan 6, 2007

评论数量(5)|Add Comments

本文网址：http://www.dbanotes.net/opensource/alipay_support_firefox.html
最近作者还说了什么? Follow Twitter / Fenng

DBA notes 理念: 用最简约的技术取得最大的收益!

杂谈：用户的搜索意图(intention of SE users)搜索引擎研究 » 车东在 Google 阅读器中共享的项目

搜索引擎早已经成为互联网上的最大的应用之一了，可是新闻媒体已经研究人员很难拿到相关的数据来对它进行深入的研究。之所以不知庐山真面目，只缘看不到真正的有价值的数据及其分析。在搜索引擎领域，用户的搜索意图分析是一个关键领域，主要研究的方向是用户输入的关键词的真正意图。就拿最常见的搜索关键词：木乃伊3 下载，这个搜索的意图非常明显，用户就是要找到能下载木乃伊3的一个网址。另外例如像n73这样的搜索词，就是一个手机的型号，可以补全到nokia n73。用户的搜索意图的分析的方法相对不固定，比较成功的有中心词分析、历史搜索关键词、语义分析、语境分析、点击统计分析等手段。那么互联网上的用户在搜索引擎上到底的意图是干什么呢？下面给出一个详细的分析结果，供相关人士参考： 32% 直接搜索网站31% 资源和下载型16% 信息型4% 财经股票类4% 商业相关（B2C，C2C，以及有可能产生消费的流量）13% 色情类这个结果可能令人意外，最大的两类竟然是直接搜索网站的！对，是的，大量的用户在搜索引擎里直接输入一个网站的名字，例如“校内网”、“优酷”等。也有用户更直接，输入：vagaa等英文缩写，甚至还有会在搜索引擎里输入这个搜索引擎的名字这样的情况。然而这个一点也不意外，能记住超过10个以上域名的网民的数量还属于少数，而且以后也会是少数，在这样的情况下，搜索引擎的第一大的作用就是“搜索导航”。关于资源下载类，也许你会理解为什么xunlei和vagaa这样的网站的市场会这么大，也怪不得迅雷的流量实际上超过了任何一家门户网站。关于信息类，资讯，新闻，问答等为主，这部分并非传统我们想像的那么大，但是像百度这样的搜索引擎+社区内容就很容易将这部分的流量留在百度，因为可以丰富这部分的内容后增强搜索的体验，从而形成一个搜索质量改善的闭环。其他的几类无需多说，不过随着股市热潮的推却，金融相关的搜索也在迅速降温，但是一定会有新的社会热点替代这块。 ...

08:15 AUTO_INCREMENT and MERGE TABLES » MySQL Performance Blog

How would you expect AUTO_INCREMENT to work with MERGE tables ? Assuming INSERT_METHOD=LAST is used I would expect it to work same as in case insertion happens to the last table... which does not seems to be the case. Alternatively I would expect AUTO_INCREMENT to be based off the maximum value across all tables, respecting AUTO_INCREMENT set for the Merge Table itself. Neither of these expectations really true:

PLAIN TEXT

SQL:

mysql> CREATE TABLE a1(i int UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY);
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE a2 LIKE a1;
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO a1 VALUES(2);
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO a2 VALUES(1);
Query OK, 1 row affected (0.00 sec)
mysql> CREATE TABLE am(i int UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY) type=merge union(a1,a2) insert_method=last;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> INSERT INTO am VALUES(NULL);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM am;
+---+
| i |
+---+
| 1 |
| 2 |
| 3 |
+---+
3 rows IN SET (0.00 sec)

So you can see merge table behaves quite smart. Even though the maximum value in table a2 was 1 it finds out what other subtable had value 2 and assigns the value 3 to the new row.

Let us see how stable merge table auto_increment values are by truncating the table we just inserted data to:

PLAIN TEXT

SQL:

mysql> TRUNCATE TABLE a2;
ERROR 1105 (HY000): MyISAM TABLE 'a2' IS IN USE (most likely BY a MERGE TABLE). Try FLUSH TABLES.
mysql> FLUSH TABLES;
Query OK, 0 rows affected (0.01 sec)
mysql> TRUNCATE TABLE a2;
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO am VALUES(NULL);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM am;
+---+
| i |
+---+
| 2 |
| 3 |
+---+
2 rows IN SET (0.00 sec)

As you see newly inserted row got value 3, which is maximum value which remained in the table plus 1. So auto_increment values are reusable just as with old ISAM tables. Such behavior does not only corresponds to TRUNCATE - deleting last row will cause auto_increment value to be reused too.

Can you use AUTO_INCREMENT clause in CREATE TABLE to get different auto_increment values ? I guess not:

PLAIN TEXT

SQL:

mysql> ALTER TABLE am AUTO_INCREMENT=1000;
Query OK, 0 rows affected (0.00 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> SHOW CREATE TABLE am;
+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| TABLE | CREATE TABLE |
+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| am | CREATE TABLE `am` (
`i` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`i`)
) ENGINE=MRG_MyISAM DEFAULT CHARSET=utf8 INSERT_METHOD=LAST UNION=(`a1`,`a2`) |
+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

As you can see Merge table does not even stores auto_increment value (and of course does it without any warnings)

Neither setting auto_increment value for underlying MyISAM tables works:

PLAIN TEXT

SQL:

mysql> ALTER TABLE a1 AUTO_INCREMENT=100;
Query OK, 1 row affected (0.00 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> ALTER TABLE a2 AUTO_INCREMENT=100;
Query OK, 1 row affected (0.00 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> INSERT INTO am VALUES(NULL);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM am;
+---+
| i |
+---+
| 2 |
| 3 |
| 4 |
+---+
3 rows IN SET (0.00 sec)

So for bad or for good you should remember auto_increment for Merge Tables works differently from both MyISAM and Innodb tables and being similar to what ISAM tables used to have. As the side effect of this - if you're using auto_increment columns inserting into Merge Table and in the last table directly will have different results.

Another thing I should remind you should be very careful while running ALTER TABLE for underlying tables. Unlike with TRUNCATE TABLE there is no warning displayed but the MERGE TABLE may continue having old file descriptors open not seeing changes done to original table:

PLAIN TEXT

SQL:

mysql> SELECT * FROM am;
+-----+
| i |
+-----+
| 2 |
| 3 |
| 5 |
| 10 |
| 100 |
| 101 |
| 102 |
| 103 |
| 104 |
| 105 |
+-----+
10 rows IN SET (0.01 sec)
mysql> ALTER TABLE a2 AUTO_INCREMENT=5000;
Query OK, 9 rows affected (0.00 sec)
Records: 9 Duplicates: 0 Warnings: 0
mysql> DELETE FROM a2 WHERE i>2;
Query OK, 9 rows affected (0.00 sec)
mysql> SELECT * FROM am;
+-----+
| i |
+-----+
| 2 |
| 3 |
| 5 |
| 10 |
| 100 |
| 101 |
| 102 |
| 103 |
| 104 |
| 105 |
+-----+
10 rows IN SET (0.00 sec)
mysql> SELECT * FROM a2;
Empty SET (0.00 sec)
mysql> FLUSH TABLES;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM am;
+---+
| i |
+---+
| 2 |
+---+
1 row IN SET (0.00 sec)

As you can see delete is invisible in the merge table after we did alter table until we have run flush tables.

I've done my tests with MySQL 5.0.62.

Entry posted by peter | No comment

Add to: | | | |

07:24 Can you Trust CHECK TABLE ? » MySQL Performance Blog

Take a look at this:

PLAIN TEXT

SQL:

mysql> repair TABLE a3;
+---------+--------+----------+----------+
| TABLE | Op | Msg_type | Msg_text |
+---------+--------+----------+----------+
| test.a3 | repair | STATUS | OK |
+---------+--------+----------+----------+
1 row IN SET (0.10 sec)
mysql> SELECT * FROM a3 ORDER BY i;
+------------+
| i |
+------------+
| 2147483648 |
| 11 |
| 13 |
| 14 |
| 2147483647 |
+------------+
5 rows IN SET (0.00 sec)

The sort order is obviously wrong while CHECK TABLE is not reporting any error

Why ? Because CHECK TABLE only looks at MyISAM data and Index files and it does not compare information in these to table definition (.frm file)

In this particular case I replaced .frm file for the table from different one changing INT to UNSIGNED INT to see what effect it will give - as you can see you get quite funny table which is considered OK by CHECK TABLE, which does store values larger than max signed int but which sorts them as unsigned ints. Quite fun.

I hope the task of fixing this is somewhere on MySQL roadmap

Entry posted by peter | 5 comments

Add to: | | | |

04:03 飓风来袭，中秋快乐 » 大学小容>善用网络，助益成长！

周一的时候知道新的飓风IKE已经形成，趋势图看来指向我们这里。周二看的时候又调整到了另外一边，周三则又调整回来。今天早上呢，飓风的趋势继续朝我们这里调整，电视里已经开始报道组织撤离的消息。

Hurricane Ike

View SlideShare presentation or Upload your own. (tags: ike hurricane)

上面是来自本地报纸Chron网站上的互动飓风观测图的截图。请看最后一张slide，小容标出自己现在所处的位置。

当然，小容不会在飓风来袭的时候继续留在现场报道飓风：）再过几个小时，傍晚时分就准备和朋友一起撤离，去飓风影响区域外的地方躲躲。

在这里的第一个中秋节将在异乡过了，其实这里也是异乡。算起来，即使是呆了十几年的福州，也还算是异乡吧。祝愿在建阳老家的母亲、父亲、姐姐以及哥哥全家节日快乐。

祝愿大家中秋节快乐。每年多花些时间在家人在一起，也为家人多拍摄些数码相片，以及视频片段，记录下你的亲人的音容笑貌，为他们备份下当下的生活，留下美好的回忆。

其实这些举手之劳的事情，小容过去没有做很多，现在已经开始后悔。

00:44 UCD大社区文章的收录原则 » UCDChina.com

自从我们开放投稿以来，不断地能收到很多朋友的文章，尤其是UCD大社区上线之后。相信被收录的文章都能从中获得一定的访问量和关注。首先感谢各位的支持和关注。

对于未被收录的文章，我们无法一一回信，具体的收录原则可查看以下几点：

1 原创内容。如果你不是文章作者，请提供原始链接。
2 观点鲜明，言之有悟。你不一定要有华丽的文笔，逻辑也不需要非常缜密，但如果类似观点已经在其他文章中已经出现，将不收录。
3 观点不明显错误。对于一些有争议的话题可以发表你的看法，收录不一定是我们认同你的观点，但如果观点明显错误，概不收录。
4 对以下人群有帮助：产品经理、产品策划、需求分析师、信息架构师、交互设计师、用户研究员、视觉设计师等和产品相关的人员。对于偏技术类的文章我们暂时不考虑收录。
5 内容丰满。虽然我们不需要每篇文章像论文一样洋洋洒洒、动辄上万，但也请保证文章字数足够清楚地表达你的观点。
6 健康不反动。

接下来我们将：
1 更加严格地对文章质量进行把关。建议不要为流量写博客，欢迎大家参与话题的讨论，对于过于“水”的文章，我们不予收录。
2 抬高“产品市场”和“设计思想”的门槛。设计师需要有务实的心态，对于行业内的一些动态，“指手画脚”之前请三思，我们欢迎你拿数据和证据说话，对于凭空臆想的观点我们不予苟同。

希望我们收录的文章，沉淀下来之后都能像一本好书，一段时间再去翻阅都会有新的收获。
再次感谢所有文章的作者。

文章提交入口在UCD大社区的右侧：我来发布信息

ps：在我们这里发布的招聘信息基本上都会通过审核。如果我们认为好的公司和好的团队，会在网站首页的“信息快递”里友情推荐。

转载请注明出自UCDChina.com，谢谢。

No Related Posts

	九月 2008
一	二	三	四	五	六	日
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30