22:31 Korn Shell 脚本入门 (341 Bytes) » developerWorks 中国 : 技术文章 , 教程 AIX

所有的 UNIX 用户都应该了解如何使用 Korn Shell 脚本。通过编写 Shell 脚本，可以让您实现许多任务的自动化，并可以为您节约大量的时间。初看起来，它似乎令人生畏，但只要遵循正确的指导，您就可以熟练地使用它。本文将指导您编写自己的 Korn Shell 脚本。

21:30 体验基于OpenSolaris的Web/企业应用（8.30 杭州） [Flickr] (1115 Bytes) » DBA notes

Fenng(dbanotes) posted a photo:

本次杭州OpenSolaris/OpenSource User Group的活动主题是“体验基于OpenSolaris的Web/企业应用”，主要分享嘉宾为Unix-Center.net社区积极分子黄立伟和知名博客dbanotes.net 博主冯大辉，分享的主题分别为“我的OpenSolaris学习路程”和“设计可扩展的面向互联网应用的MySQL数据库”等。届时来自Sun的 OpenSolaris工程师和推广人也会到现场，与大家一起讨论。OSUG是一个开发交流的场所，我们期望与会者都能够畅所欲言，与他人分享自己的点滴心得，形成一个“知识共享”的氛围。

【活动信息】

21:10 体验基于OpenSolaris的Web/企业应用（8.30 杭州） (1115 Bytes) » Uploads from Fenng(dbanotes)

Fenng(dbanotes) posted a photo:

本次杭州OpenSolaris/OpenSource User Group的活动主题是“体验基于OpenSolaris的Web/企业应用”，主要分享嘉宾为Unix-Center.net社区积极分子黄立伟和知名博客dbanotes.net 博主冯大辉，分享的主题分别为“我的OpenSolaris学习路程”和“设计可扩展的面向互联网应用的MySQL数据库”等。届时来自Sun的 OpenSolaris工程师和推广人也会到现场，与大家一起讨论。OSUG是一个开发交流的场所，我们期望与会者都能够畅所欲言，与他人分享自己的点滴心得，形成一个“知识共享”的氛围。

【活动信息】

21:07 《纽约时报》列出的奖牌榜 [Flickr] (390 Bytes) » 车东[Blog^2]

车东@FlickR posted a photo:

截止到8月17日上午11点整

20:54 Curl Functions for MySQL, v 0.1 released! (1171 Bytes) » Fenng's shared items in Google Reader

Shared by Pahud
mysql的UDF真有意思

I was looking for an example of how to write a MySQL UDF for my upcoming book "Writing Web Applications in Perl, Memcached, MySQL and Apache", and decided using Curl would be fun. Maybe there are some philosophical issues of why not to do it. But I can do it, and I did do it. So be it ;) Once I started the idea, I had to at least finish it. I hate not finishing something.

The single function is http_get(). It's very simple -- it just fetches a url (doesn't yet take the "http" part, it's _that_ simple). This severely needs to be fleshed out.

So, the proof in the pudding is at: http://patg.net/http_get.txt

A Launchpad project: https://launchpad.net/curludfs

Code: http://patg.net/downloads/curl_functions_mysql-0.1.tar.gz

I'd entertain anyone wanting to contribute!

19:49 有线电视的弹窗广告 (331 Bytes) » Uploads from Fenng(dbanotes)

Fenng(dbanotes) posted a photo:

18:23 Why Python? (3974 Bytes) » Fenng's shared items in Google Reader

Shared by Fenng
Sohu 的技术一瞥

去年10月份，我做了一个决定——用 python 来构建搜狐的新一代WebMail系统，替代以前的 java 代码。不得不说这相当冒险，但不管怎么样，它现在运行的还不错，从程序的角度来看，好像代码前途还挺光明。据我自己估计，论部署规模/管理的数据容量/每日登录用户数，在国内 python 开发的网站里，应该是排名第一。 :)

在进入搜狐之前，我的 python 经验十分有限。就是会做做 base64.decodestring；学习 pymsnt 的时候接触了一下 twisted；以及，也是比较搞笑的一点，我用 python 最熟的地方居然是 windows 下的开发——访问注册表，用wxPython写界面，用ctypes访问DLL...

搜狐邮件中心开发以前是分成两个小组，一拨C/C++程序员，一拨Java程序员，技术上两者间没什么共同语言。因此我力主引入 python，是想弥合双方的技术范围，让每个程序员，都可能尽多的去接触 E-Mail 的所有业务领域。

一开始是 Twisted 应用，某 java 程序员用它实现了一套监控系统，实时注册IP黑名单系统；MTA 那里则是用它来做 tcptable 查找表的接口。

后来 MTA 那里更夸张的用 pymilter 粘合postfix 和过滤系统，直到我们的某供应商提供了 API 后才不得不改回 C

虽然计划增加 Python 的应用范围，但在规划 AjaxMail 的时候，一开始的确是打算沿用 Java 开发的。原因是三点：
A. 不管 Python 有多少优点，但都绝不应该抛弃以前的旧代码
B. 现有WEB开发人员的知识结构完全是基于Java的
C. 不管 Python 在语言方面有多少优点，但由于主要的业务逻辑都在 Javascript 上，后台究竟用什么语言开发反而是无所谓了。换句话说，Python带来的好处不明显，但风险是极高的

转折点出现在 10 月，两个主力 Java 程序员离开了团队，一个去了微软，一个去了新加坡。我的选择就变成：
1. 招Java程序员，从0开始熟悉现有的代码，学习邮件业务，然后摸索着前进
2. 依赖以前的关系，找几个邮件系统很熟悉的C程序员，用Python或者PHP(类似的事情我在04年干过一次，用PHP替换了eyou.com的CGI)或者什么什么开发，但肯定不是JAVA。

还有一点，我自认永远也不会太深入Java，不可能带着程序员在这条道路上走远。

说起来有点儿造化弄人，我心里确实想全面铺开Python，但理智上还是选择保守，可现实把我推向自己真正想去的地方。

关于这个选择我想更重要的是：万一不得已重头再来，怎样才能尽可能的降低风险呢？
1. 经验。我在这个领域8年了，技术上能做到什么样子还是有把握的。
2. 人才。如果不是因为有一个很得力的程序员，俺就要被迫亲自操刀了；虽然走了两个人，但配了一对更好的组合。
3. 信心。把自己的信心带给团队所有人，消除大家的不确定性。
4. 兼容。代码虽然有变化，但数据格式基本没有变，老的Java代码仍然还是可以使用——我想它应该至少还有半年的生命期。

To be, or not to be. 不管怎么选择，都要事先准备好面对接下来的挑战。

延伸阅读：lighttpd 2.0

13:50 Video: John Halamka on healthcare and open source (1590 Bytes) » Red Hat Magazine

Download this video: [Ogg Theora]

John Halamka, CIO of Harvard Medical School and Beth Israel Deaconess Medical Center, was one of the keynote speakers at this summer’s Red Hat Summit. In this video, he explains how open source is critical to the healthcare industry and talks a little about his implanted RFID chip. Learn more about how Beth Israel saved $200,000 and reduced downtime to nearly zero.

13:36 Curl Functions for MySQL, v 0.1 released! (1097 Bytes) » Fenng's shared items in Google Reader

I was looking for an example of how to write a MySQL UDF for my upcoming book "Writing Web Applications in Perl, Memcached, MySQL and Apache", and decided using Curl would be fun. Maybe there are some philosophical issues of why not to do it. But I can do it, and I did do it. So be it ;) Once I started the idea, I had to at least finish it. I hate not finishing something.

The single function is http_get(). It's very simple -- it just fetches a url (doesn't yet take the "http" part, it's _that_ simple). This severely needs to be fleshed out.

So, the proof in the pudding is at: http://patg.net/http_get.txt

A Launchpad project: https://launchpad.net/curludfs

Code: http://patg.net/downloads/curl_functions_mysql-0.1.tar.gz

I'd entertain anyone wanting to contribute!

11:31 Oracle中实现圆周率计算（三） (676 Bytes) » yangtingkun

今天两个同事用JAVA实现圆周率一百位小数的实现。一个同事问我要不要试试，由于很长时间没有写过JAVA代码，而且本身JAVA的水平就很差，于是打算用ORACLE实现。这篇给出一个真正的算法。Oracle中实现圆周率计算（一）：http://yangtingkun.itpub.net/post/468/468799Oracle中实现圆周率计算（二）：http://yangtingkun.itpub.net/post/468/468870上一篇文章提到，Oracle的NUMBER类型精度只有38位，因此想要确保100位的精度就无法直接使用Oracle的NUMBER类型来实现了。如果在Oracle希望实现这个功能，那么最简单的办法莫过于使用JAVA存储过程...

08:28 再说刘翔退赛 (3636 Bytes) » 存储部落

这两天关于刘翔退赛，大家有很多评论。有支持的，也有批评，而且现在已经发展到了支持和批评的双方开始相互攻击了。

也许换作另外一个人退出比赛，大家都不会有这样的评论。但正因为他是刘翔，是代表着中国人田径梦想的刘翔，几年来国人给他了太多太多的期盼，同时也因为“出镜率”太高，所以他早已经不是一个普通的运动员，他是一个代表着中国人梦想的公众人物。他的一言一行，一举一动不就能象一个普通人那样随意。普通人可以勾三搭四，试问哪个公众人物敢？

这就是公众人物与普通人的区别！

很多人并非在批评他的退赛，而是批评他的退赛方式，普通运动员可以这样，而他不可以。

前几天还传出他试跑的成绩不错，一再地给大家更多的希望，到了赛场上却突然伤势严重。难道中国的队医真的弱到临到上场了还不能判断出他可不可以参加比赛？如果真的不行可以提前退赛，不要把大家的希望提到了最高点，然后再突然的摔下去，这种做法太不负责任。

不管到底是什么原因，即使退赛，也要正面地给大家一个交代，难道真的不能走110米，哪怕是很多人搀扶着！就这样什么也不说，头也不回的走下去，到现在也没有给大家一个正面的答复，让人觉得真的很失望。

没人会强迫他怎么样，也没有人有权利强迫他怎么样。但是作为一个负责任的人，一个承担着很多人梦想和期盼的公众人物，作为一个爷们，做事情一定要有担当！答应的事情却没有完成，是不是应该正面地说声对不起！

我想任何一个普通人都会说的。

08:12 Why Python? (3903 Bytes) » Fenng's shared items in Google Reader

去年10月份，我做了一个决定——用 python 来构建搜狐的新一代WebMail系统，替代以前的 java 代码。不得不说这相当冒险，但不管怎么样，它现在运行的还不错，从程序的角度来看，好像代码前途还挺光明。据我自己估计，论部署规模/管理的数据容量/每日登录用户数，在国内 python 开发的网站里，应该是排名第一。 :)

在进入搜狐之前，我的 python 经验十分有限。就是会做做 base64.decodestring；学习 pymsnt 的时候接触了一下 twisted；以及，也是比较搞笑的一点，我用 python 最熟的地方居然是 windows 下的开发——访问注册表，用wxPython写界面，用ctypes访问DLL...

搜狐邮件中心开发以前是分成两个小组，一拨C/C++程序员，一拨Java程序员，技术上两者间没什么共同语言。因此我力主引入 python，是想弥合双方的技术范围，让每个程序员，都可能尽多的去接触 E-Mail 的所有业务领域。

一开始是 Twisted 应用，某 java 程序员用它实现了一套监控系统，实时注册IP黑名单系统；MTA 那里则是用它来做 tcptable 查找表的接口。

后来 MTA 那里更夸张的用 pymilter 粘合postfix 和过滤系统，直到我们的某供应商提供了 API 后才不得不改回 C

虽然计划增加 Python 的应用范围，但在规划 AjaxMail 的时候，一开始的确是打算沿用 Java 开发的。原因是三点：
A. 不管 Python 有多少优点，但都绝不应该抛弃以前的旧代码
B. 现有WEB开发人员的知识结构完全是基于Java的
C. 不管 Python 在语言方面有多少优点，但由于主要的业务逻辑都在 Javascript 上，后台究竟用什么语言开发反而是无所谓了。换句话说，Python带来的好处不明显，但风险是极高的

转折点出现在 10 月，两个主力 Java 程序员离开了团队，一个去了微软，一个去了新加坡。我的选择就变成：
1. 招Java程序员，从0开始熟悉现有的代码，学习邮件业务，然后摸索着前进
2. 依赖以前的关系，找几个邮件系统很熟悉的C程序员，用Python或者PHP(类似的事情我在04年干过一次，用PHP替换了eyou.com的CGI)或者什么什么开发，但肯定不是JAVA。

还有一点，我自认永远也不会太深入Java，不可能带着程序员在这条道路上走远。

说起来有点儿造化弄人，我心里确实想全面铺开Python，但理智上还是选择保守，可现实把我推向自己真正想去的地方。

关于这个选择我想更重要的是：万一不得已重头再来，怎样才能尽可能的降低风险呢？
1. 经验。我在这个领域8年了，技术上能做到什么样子还是有把握的。
2. 人才。如果不是因为有一个很得力的程序员，俺就要被迫亲自操刀了；虽然走了两个人，但配了一对更好的组合。
3. 信心。把自己的信心带给团队所有人，消除大家的不确定性。
4. 兼容。代码虽然有变化，但数据格式基本没有变，老的Java代码仍然还是可以使用——我想它应该至少还有半年的生命期。

To be, or not to be. 不管怎么选择，都要事先准备好面对接下来的挑战。

延伸阅读：lighttpd 2.0

04:10 Miscellaneous (1 Bytes) » Oracle Scratchpad

03:01 使用过order by rowid排序吗 (10268 Bytes) » DBA@Taobao

前天协助SA排错时，通过tbsql sql发现了使用oreder by rowid做排序的sql，我很好奇这种写法，为什么业务逻辑会通过rowid来排序来实现，常常这种疑惑浪费了我很多时间。
先确认两个问题：
1.为什么会使用rowid来排序
2.一个普通的分页sql，物理读排在第一，为什么每次需要消耗356个的物理读

Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----
5,043,897 14,149 356.5 7.7 744.89 53095.33 2800676544
SQL> select/*+ordered use_nl(t1 t2)*/ *
9 from (select rid, rownum as linenum
10 from (select rowid as rid
11 from auc_table
12 where username = 'abc123456789'
13 and approve_status in (0, 1, -9)
14 and ends > SYSDATE
15 order by starts asc,rowid )
16 where rownum <= 100) t1,
17 auc_table t2
18 where t1.linenum >= 1
19 and t1.rid = t2.rowid;

引江枫的论断：

oracle9204版本有这个问题：因为不稳定的排序，同样值的记录的位置在排序后不是固定的。假设两条记录，1，a和1，b，按1排序，那么在第一页的时候，可能最后一条是 1 ,a，翻到第二页，本来第一条应该是1,b的但是因为排序不稳定，可能第一条还是1，a，这样1,b就没有显示出来了

通过讨论可以确认，使用rowid是为了保证分页取数据显示正常，以防不稳定的排序导致有些记录漏掉显示，有些却显示不了，如果我们能保证每次分页都能取到正确的数据，那不就可以去掉order by rowid。
1.统计username所占的索引块数。

select count(*)
from auc_table
where username = 'abc123456789'and approve_status in (0, 1, -9)and ends > SYSDATE;
1 row selected.

Execution Plan
--------------------------------------------------------
   SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=45)
0 SORT (AGGREGATE)
1 INDEX (RANGE SCAN) OF 'IDX_auc_USERNAME' (NON-UNIQUE) (Cost=4 Card=5 Bytes=225)
Statistics
----------------------------------------------------------
   0 recursive calls
   0 db block gets
   5055 consistent gets --差不多我们可以推断这个用户的索引占用了5000个左右的块。
   0 physical reads
   0 redo size
   493 bytes sent via SQL*Net to client
   656 bytes received via SQL*Net from client
   2 SQL*Net roundtrips to/from client
   0 sorts (memory)
   0 sorts (disk)
1 rows processed

从上面的结果我们可以看出，这个id占用索引块大概在5000个左右，而且走的索引扫描，没有回表。
order by rowid是为了避免不稳定的排序带来分页sql取值丢失的问题, 如果我们只根据索引来取数据的话，索引中的数据相对位置是不变的，这样是不需要排序，也就没有排序稳不稳定的问题，我们要做的就是根据分页在索引中从头到尾一直把数据取出来而已，没必要通过rowid大小来保证取数据的正确性。
去掉order by rowid排序，性能会有多大的提高呢，我们来对比一下性能。
1.使用order by rowid排序，取第一页

SQL> select/*+ordered use_nl(t1 t2)*/ *
9 from (select rid, rownum as linenum
10 from (select rowid as rid
11 from auc_table
12 where username = 'abc123456789'
13 and approve_status in (0, 1, -9)
14 and ends > SYSDATE
15 order by starts asc,rowid )
16 where rownum <= 100) t1,
17 auc_table t2
18 where t1.linenum >= 1
19 and t1.rid = t2.rowid;

100 rows selected.
Execution Plan
-----------------------------------------------------
   SELECT STATEMENT Optimizer=CHOOSE (Cost=23 Card=5 Bytes=1875 )
   0 NESTED LOOPS (Cost=23 Card=5 Bytes=1875)
   1 VIEW (Cost=18 Card=5 Bytes=100)
   2 COUNT (STOPKEY)
   3 VIEW (Cost=18 Card=5 Bytes=35)
   4 SORT (ORDER BY STOPKEY) (Cost=18 Card=5 Bytes=290)
   5 INDEX (RANGE SCAN) OF 'IDX_auc_USERNAME' (NON-UNIQUE) (Cost=4 Card=5 Bytes=290)
   1 TABLE ACCESS (BY USER ROWID) OF 'auc_table' (Cost =1 Card=1 Bytes=355)

Statistics
----------------------------------------------------------
   0 recursive calls
   0 db block gets
   5161 consistent gets =5055（索引块）+100（行块），如果加上rowid排序的话，应该是把这个username全部数据都要扫描一遍，在排序
   62 physical reads
   0 redo size
14132 bytes sent via SQL*Net to client
   722 bytes received via SQL*Net from client
   8 SQL*Net roundtrips to/from client
   1 sorts (memory)
   0 sorts (disk)
   100 rows processed

2.去掉order by rowid排序,也是只取第一页:

SQL> select/*+ordered use_nl(t1 t2)*/ *
9 from (select rid, rownum as linenum
10 from (select rowid as rid
11 from auc_table
12 where username = 'abc123456789'
13 and approve_status in (0, 1, -9)
14 and ends > SYSDATE
15 order by starts asc )
16 where rownum <= 100) t1,
17 auc_table t2
18 where t1.linenum >= 1
19 and t1.rid = t2.rowid;

100 rows selected.
Execution Plan
----------------------------------------------------------
   SELECT STATEMENT Optimizer=CHOOSE (Cost=7 Card=5 Bytes=1875)
   0 NESTED LOOPS (Cost=7 Card=5 Bytes=1875)
   1 VIEW (Cost=2 Card=5 Bytes=100)
   2 COUNT (STOPKEY)
   3 VIEW (Cost=2 Card=5 Bytes=35)
   4 INDEX (RANGE SCAN) OF 'IDX_auc_USERNAME'
   (NON-UNIQUE) (Cost=4 Card=5 Bytes=290)
   1 TABLE ACCESS (BY USER ROWID) OF 'auc_table' (Cost =1 Card=1 Bytes=355)

Statistics
----------------------------------------------------------
   0 recursive calls
   0 db block gets
   926 consistent gets --应该是只取到前面100条的数据就退出了，实际上这个逻辑还是有点大，我以为只用100多一点就够
   44 physical reads
   0 redo size
   13963 bytes sent via SQL*Net to client
   722 bytes received via SQL*Net from client
   8 SQL*Net roundtrips to/from client
   0 sorts (memory)
   0 sorts (disk)
   100 rows processed

同样的功能，不同的实现方式性能相差还是很大的，对于我们这种业务量及其繁忙的系统，7.7%的物理读，如果能优化下来，也是相当可观的。

23:58 几条经典的 CSS Tips » Fenng's shared items in Google Reader