皖南产很好的笋干,做得最多的就是笋干炖肉。上海话又叫“笋拷肉”。这是个双关语,暗含竹板打屁股的意思。一般吓唬小孩就说“再不听话,就请你吃笋拷肉!”。

上月买了个沙锅。看着砂锅,舌尖上产生的第一个回忆,居然是笋干炖肉的味道。所以去带了些笋干回来。

把笋干用温水泡软,揉洗几遍。去超市买一盒肋排。切两块生姜,剥几瓣大蒜,拍松。香葱一撮,切段。

铁锅里油烧到七成热,把大蒜,香葱放进去,略过一下油,稍一变色,就捞出来。然后把肋排放进去,旺火翻几下,以肉表面变色为度。这时候加酱油、料酒、黄酱和玫瑰豆腐乳,再把刚才的大蒜、香葱、还有生姜,都放进去炒几分钟。然后盛入沙锅。

把泡好的笋干也放进沙锅,加水至刚好淹没锅里的菜。小火炖两小时。

在这两小时里,越来越浓的香味会一直考验你的意志。一定要坚持住,炖菜够火候才好吃。

本文原载 2006 年 03 月 21 日旧版博客。

前段时间换了个手机,原来用的杂牌手写机在一次不经意的碰撞中,她的液晶屏就如同她的心一样,彻底的碎裂了。流出了黑色的液体,我猜测这大概是她的眼泪吧。

只见新人笑,不见旧人哭。为了挽回我对她犯下的错误,我决定将她的记忆导出。因为个人洁癖的使用习惯,记忆卡中并没有存放数据。通讯录也存放在了手机内存中。咨询了二十一世纪最有前途的电子商务人才 FT 之后,我认识了 PCSyncManager(点击下载,解压密码:www.xuchao.cn)。他犹如她前世的情人,凭借自己对她的了解,毫无保留的导出了手机中的数据。随后,他毫不犹豫的带着她踏上了去往天堂的航路。

嗯,神父啊,祝他们幸福和谐吧……

一直以来,公司某游戏平台使用 SQL Server 作为数据存储解决方案。为了数据的安全,每天凌晨在本机上做一次备份。但随着时间的推移,原先并没有设计到备份需求的硬件配置,尤其是外部存储这块,已经快不能满足 SQL Server 备份文件日益丰满的身姿。(这句话好像谁说过?)

为了彻底解决这个病痛,我打算为其实施远程异地备份。但查阅无数资料,均找不到较好的解决之道。大部分方案都是在备份目的地建共享目录,新增一个用户并赋权。然后在数据库端写个存储过程,添加数据库维护计划并使用这个存储过程。这样做有太多弊端:对于操作系统来说,很不安全;对于硬件架构设计来说,必须满足同一内网的条件。于是乎,放弃这样的方案。

经过几天的折腾测试,最后我采用了这样的方案。虽然比较老土,但至少 DIY 出来了,也暂时性满足了需求,缓解了阶级矛盾:

1、打开 SQL Server 企业管理器,找到数据库维护计划。

2、添加一个数据库维护计划,为其设置一个优美而和谐的名字,并选择需要操作的数据库对象。

- 阅读剩余部分 -

昨晚,是一个愉快的、有意义的、充实的夜晚;昨晚,对于我的一生来说都是十分重要的一晚;昨晚,虽然是夜晚,但却是明媚、阳光的一晚。这一切,都是因为有了你,feelinglucky

lucky 兄已在 gracecode.com 上面概述了昨夜我们之间发生的故事,这里做一个全面的流水记录。让花花草草都来羡慕我们这天上的一对、地上的一双吧。

昨晚接到一个工单,要给一个客户对帐。我和同事 Henry Xu 分别在 MySQL 和 SQL Server 做了一次查询,结果显示的时间正好相差八小时。Henry 说:“肯定是你 MySQL 的时区有问题,慢了八个小时”。我看看是啊,想起 lucky 的一篇文章,于是到 phpmyadmin 中查询:

SELECT UNIX_TIMESTAMP(); 结果显示的时间戳,通过 PHP 的 date 函数转换出来,确实与那时的北京时间相差八个小时。我继续在 phpmyadmin 中查询:

SELECT NOW(); 这次结果居然是正确的。暂时糊涂了,看看时间,北京时间21点多,一通电话直接找到 lucky。这里插播一则广告,本人专业出售 lucky 手机号码,有需要的 MM 请直接在下面留言,谢谢。

我们一边谈一边查资料,后来在 MySQL 手册上看到:UNIX_TIMESTAMP() 是返回世界协调时 UTC 的时间,不参照本机系统时区。网上也有一种说法:使用 UNIX_TIMESTAMP() 函数是获取不到正确的当地时间的时间戳,除非当前系统时区就在 0 时区。后来 lucky 提示使用 CURRENT_TIMESTAMP() 代替,但是由于我目前的数据库设计习惯,暂时不能接收非时间戳的值。

后面 lucky 就在说服我使用 datetime 的数据库类型。我一边写了一个小脚本:

<?php
$a 
0000000000//从 phpmyadmin 中查询 SELECT UNIX_TIMESTAMP(); 后复制过来的 10 位数字
$b time();
echo 
date('Y-m-d H:i:s'$a) . "<br />" date('Y-m-d H:i:s'$b);
?>
并把这个脚本放到服务器上跑了一下,结果发现两行输出居然是一样的。我纳闷,然后将脚本复制到 Zend Studio 里面,F5…… My god,原来是 Zend Studio 的问题……

下面复制一些与 lucky 的交流记录,谨作这一夜的纪念。

feelinglucky: http://www.modwest.com/help/kb6-256.html
feelinglucky: -_- 我搜索 “mysql 时区”竟然都是我的文章……
wiLdGoose: 是的
feelinglucky: http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html
NOW 是正确的是吧?
用 CURRENT_TIMESTAMP(), CURRENT_TIMESTAMP 看看
Synonyms for NOW()
wiLdGoose: ..........
feelinglucky: CURRENT_TIMESTAMP and CURRENT_TIMESTAMP() are synonyms for NOW().
feelinglucky: http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_current-date
http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_current-timestamp
wiLdGoose: 我知道的
他和 NOW() 一样的
我不要字符串的
我要整数
feelinglucky: Returns the current date and time as a value in 'YYYY-MM-DD HH:MM:SS' or YYYYMMDDHHMMSS.uuuuuu format, depending on whether the function is used in a string or numeric context. The value is expressed in the current time zone.
这个是 NOW() 的,注意最后一句
wiLdGoose: yep
NOW 是对的啊
那 UNIX_TIMESTAMP() 就乱来了?
不根据当前时区了?
feelinglucky: UTC_TIMESTAMP()(v4.1.1) Return the current UTC date and time
是 return UTC 时间
当前 UTC 时间
feelinglucky: 应该用 UNIX_TIMESTAMP
wiLdGoose: http://www.linuxrpm.com/forums/viewtopic.php?t=232
看这个
他的意思是放弃 unix_timestamp
feelinglucky: 这种说法是不对的
wiLdGoose: ?
feelinglucky: 返回 UTC 时间是有用处的,不能更改的
打个比方,两台服务器之间如果跨时区的话,时间保证会统一到 UTC 时间的
CCTV 不是经常说的嘛“格林威治时间 XXX”嫦娥一号升空
wiLdGoose: 是不是 unix_timestamp() 返回的时间和 now() 就是不一样的
先不论格式
feelinglucky: 用 CURRENT_TIMESTAMP 不行吗
wiLdGoose: 那还是一样要改代码
feelinglucky: 至少可以确定它是根据时区选项来的
wiLdGoose: 再说 CURRENT_TIMESTAMP 返回的是 datetime 格式
feelinglucky: :( 搞不懂为什么一定要时间戳
wiLdGoose: i like it
:D
feelinglucky: 你不会吧数据库都用时间戳设计的吧。。。
wiLdGoose: 是的
feelinglucky: 然后用 INT(10) ?
wiLdGoose: 是啊
你喜欢 datetime?
feelinglucky: 天啊
:(
wiLdGoose: 来吧 说服我
我听着
feelinglucky: 这样快不了多少的
直观方面先不说,这个都清楚
然后就是计算问题
比如获得最近一周的所有数据,你怎么办?
在一个表里面
wiLdGoose: 你是不是想说, 用 datetime 类型的数据, 可以直接用mysql的函数比较日期
feelinglucky: 或者获得星期一我要的所有打卡记录
wiLdGoose: 时间戳也有时间戳的好处嘛
datetime的话, 遇到特殊情况, 还是要 strtotime
多不完美
feelinglucky: 如果按照你的,保证会有一个 xxxx < monday and xxxx > monday 这样的 WHERE 条件
想象一下,这个不是日期的比较哦,是整形对整形的比较
wiLdGoose: 是的
feelinglucky: PHP 方面你首先要知道星期一的时间戳,然后再让数据库 WHERE 计算
wiLdGoose: 数字与数字比较, 不是比字符串与字符串比较方便么?
feelinglucky: 相比 MYSQL 一条语句就 OK,哪个完美呢
时间类型不是字符串类型 :(
时间对于用户来看很直观,会“误认为”是字符串,但是在 mysql 内部存储还是长整型的
feelinglucky: 这个亲爱的可以 Google 一下
我以前也这样认为的,和你的做法一样,后来看了 wordpress 的数据库设计方面的一篇文章,谈到日期的数据库设计,才转变回观念来的
退一步讲,就算时间计算比整形的要低,但是毕竟用这个能方便很多
wiLdGoose: 我空了去研究一下, 先去改代码了
feelinglucky: OK,长篇大论留到 Blog 让亲爱的欣赏 :D
wiLdGoose: 好的.
Thx.
wiLdGoose: 我晕死了
feelinglucky: ?
wiLdGoose: 我发现我用php写一个 echo time() 输出都错的
但是php配置文件已经修改的了啊.
[Date]
; Defines the default timezone used by the date functions
date.timezone = PRC
feelinglucky: ?!
ft
wiLdGoose: 我吐血了, 刚才写了一个 test.php
你看看 www.xxxx.com/test.php
feelinglucky: 对的啊
wiLdGoose: 我被忽悠了
feelinglucky: ?
wiLdGoose: 我电话你, ok?
feelinglucky: ok

关于坚持使用时间戳还是转投 datetime 的环抱,我目前还没有想好。花点时间研究一下吧。

另外有一则好消息吧,Perl 5.10.0 终于释出了。

昨天晚上和同事在搞数据库,时不时说起“NULL”这个单词。我们说了大约十多分钟,斜对面一个同事终于忍不住了,他一个箭步漂移到我们面前,问:“NULL 是怎么读的?”。我们异口同声:[ nul ]。答曰:“我记得老师教我们是说 [ nao ]”。我们嗤之以鼻,边打开爱词霸边说:“肯定是 [ nul ]”。

八秒钟后,我们震惊了:在这样一个阴霾却又和谐、愉快的圣诞之夜,我们终于重新认识了“NULL”这个单词的正确读音,原来一直以来我们都把这个单词念错了。

正确读音 mp3 文件下载