yo2某瓜 on 12月 1st, 2010
=============================================================
手机电子书利大于弊
=============================================================
-------------------------------------------------------------
1 反
-------------------------------------------------------------
1.1 手机电子书多为快餐文化,其消遣意义大于实际用途
质素良莠不齐,相对传统书籍来说有价值的较少
1.1.1 據日本市調機構Impress R&D統計,日本電子書市場規模逐年成長,至2009年達574億日圓,手機用電子書達513億日圓,
而支撐手機用電子書成長的種類為漫畫,
市場規模達428億日圓,比重佔83.4%,遠超過分別為44、41億日圓的言情小說及照片。
1.2 上述手机阅读的形式使人养成浅层阅读的习惯
1.2.1 浅阅读导致浅思考。浅阅读那种浅尝辄止,不求甚解的阅读方式,难以令读者养成深入思考的习惯。正确的读书方式对人的思维有很大的影响。
1.3 盗版问题冲击传统出版业,使正规出版的书籍收到限制,有价值的书籍因为电子书的盗版问题而遭到损失,
这是一种“劣币驱逐良币”的现象,这种现象对于社会文化的推动是很不利的
1.3.1 2009年市场规模为19356亿日元,时隔21年跌破2万亿日元。近年来日本出版业颇不景气,图书杂志发行量连年下降,
破产倒闭的出版社越来越多,不少出版社经营举步维艰。
这与年轻人不爱读书有关,也有电子书籍争夺读者的因素,随着时间的推移,
电子书对传统图书市场的冲击会越来越大
1.4 手机阅读侵占了人们本来的交际时间,沉迷于手机书籍使人变宅
1.5 手機並非最好的電子書終端,因為顯示幕太小,长期使用不利于用眼卫生
-------------------------------------------------------------
2 正
-------------------------------------------------------------
2.1 移动设备的便利使阅读更加随时随地,从而使阅读面更加广泛
2.1.1 只要買一個終端,一般家庭可以不要書架,既能滿足讀書的需要,充實精神生活,又節約木材紙張,保護環境
2.2 手机书籍内容丰富,种类多样,为传统书籍不能比

人生的真莫道不消魂相就是一场病

天,得知有个朋友的病一直没有好,各种药物都不能完全治愈。病程变得极为漫长,消磨着人的意志。她的各种状况都不是很好。

我知道了这个消息,情绪变得很低落。

我本来不想在Blog里写这个事,我不确定她是否愿意我谈到她。但是,晚上我睡不着,起床对着电脑,思绪不宁,我就随便写一点我的感受吧。

有很多时候,我们觉得,人生似乎还是很美好的。天是蓝的,花是香的,即使有不愉快的事情,你也可以做一下深呼吸。

但是,如果一旦生了恶性的疾病,一切就都不一样了。

首先,国内学术界一片腐佳节又重阳,很难找到有真才实学的医生;其次,中国社会道德沦丧,有责任心和医德高尚的医生极其稀少;再次,中国的社会保障极不完善,一场重病会让病人倾家荡产,医院也普遍拒绝救治付不起医疗费的病人;最后,中国经济是畸形的经济,失业问题非常严重,就算最终治愈了,将来的生活来源也成问题。

总之,普通人如果生重病,那简直就是一场噩梦了。有一个农民工得了白血病,因为无钱治疗,只有回四川老家等死。对于他来说,这个国家就是人间地狱。

我要说,在中国,人生的真莫道不消魂相就是一场病。

虽然我现在可以坐在这里写写Blog,用某人的话说“写得很起劲”。但是谁知道,我什么时候会生病呢。

所以不要被假象蒙蔽了,对这个国家的大多数人来说,或迟或早,总要遭遇悲惨的生活。

(完)

 
原文:http://sumandeng.spaces.live.com/blog/cns!54107D687F0B8E2F!916.entry?wa=wsignin1.0&sa=866735790

经过查找资料,原因如下(由于源文是一篇英文,有些地方写的我不是特别清楚,原文见http://groups.google.com/group /microsoft.public.sqlserver.server/msg/ad37d8aec76e2b8f?hl=en&lr=& amp;ie=UTF-8&oe=UTF- 8)

在SQL Server中有一个叫做 “Parameter sniffing”的特性。SQL Server在存储过程执行之前都会制定一个执行计划。在上面的例子中,SQL在编译的时候并不知道@thedate的值是多少,所以它在执行执行计划的时候就要进行大量的猜测。假设传递给@thedate的参数大部分都是非空字符串,而FACT表中有40%的thedate字段都是null,那么SQL Server就会选择全表扫描而不是索引扫描来对参数@thedate制定执行计划。全表扫描是在参数为空或为0的时候最好的执行计划。但是全表扫描严重影响了性能。

假设你第一次使用了Exec pro_ImAnalysis_daily @thedate=’20080312’那么SQL Server就会使用20080312这个值作为下次参数@thedate的执行计划的参考值,而不会进行全表扫描了,但是如果使用@thedate=null,则下次执行计划就要根据全表扫描进行了。

有两种方式能够避免出现“Parameter sniffing”问题:

<!--(1)通过使用declare声明的变量来代替参数:使用set @variable=@thedate的方式,将出现@thedate的sql语句全部用@variable来代替。

<!--(2) 将受影响的sql语句隐藏起来,比如:

<!-- a) 将受影响的sql语句放到某个子存储过程中,比如我们在@thedate设置成为今天后再调用一个字存储过程将@thedate作为参数传入就可以了。

<!-- b) 使用sp_executesql来执行受影响的sql。执行计划不会被执行,除非sp_executesql语句执行完。

<!-- c) 使用动态sql(”EXEC(@sql)”来执行受影响的sql。

采用(1)的方法改造例子中的存储过程,如下:

ALTER PROCEDURE [dbo].[pro_ImAnalysis_daily]

@var_thedate VARCHAR(30)

AS

BEGIN

declare @THEDATE VARCHAR(30)

IF @var_thedate IS NULL

BEGIN

SET @var_thedate=CONVERT(VARCHAR(30),GETDATE()-1,112);

END

SET @THEDATE=@var_thedate;

DELETE FROM RPT_IM_USERINFO_DAILY WHERE THEDATE=@THEDATE;

INSERT RPT_IM_USERINFO_DAILY (THEDATE,ALLUSER,NEWUSER)

SELECT AA.THEDATE,ALLUSER,NEWUSER

FROM

( ( SELECT THEDATE,COUNT(DISTINCT USERID) ALLUSER

FROM FACT

WHERE THEDATE=@THEDATE

GROUP BY THEDATE

) AA

LEFT JOIN

(SELECT THEDATE,COUNT(DISTINCT USERID) NEWUSER

FROM FACT T1

WHERE NOT EXISTS(

SELECT 1

FROM FACT T2

WHERE T2.THEDATE<@THEDATE

AND T1.USERID=T2.USERID)

AND T1.THEDATE=@THEDATE

GROUP BY THEDATE

) BB

ON AA.THEDATE=BB.THEDATE);

GO

Tags:

on 07月 30th, 2009

两种写法

SELECT ID,NEWID() AS N INTO #TMP FROM AAA
SELECT *  FROM AAA A WHERE ID IN
(SELECT TOP 2 B.ID FROM AAA B INNER JOIN
#TMP C
ON B.ID=C.ID
WHERE A.AA1=B.AA1 ORDER BY N) ORDER BY AA1
DROP TABLE #TMP


SELECT *  FROM AAA A WHERE ID IN
(SELECT TOP 2 B.ID FROM AAA B INNER JOIN
(SELECT ID,NEWID() AS N FROM AAA) C
ON B.ID=C.ID
WHERE A.AA1=B.AA1 ORDER BY N) ORDER BY AA1

照理说两种写法的效果是一样的,但实际第二种写法的结果是不可预料的,奇怪,很奇怪

想重新用用这blog。。。发现链接都不见了  :oops:

on 03月 11th, 2009

http://topic.csdn.net/u/20090304/09/308661be-e83a-4575-8b73-5473dbeba344.html

 

Read the rest of this entry »

Tags:

 

最近看到一个汽车对冰淇淋过敏的小故事(原文在此),转述如下:
某汽车公司收到投诉信,用户抱怨说他每晚都从家里开车去商店买冰淇淋。如果买的是香草冰淇淋,则回家时汽车就无法发动;如果买其它口味的冰淇淋,则汽车可以正常发动。天天如此。该用户怀疑这汽车是否对香草冰淇淋过敏。
汽车公司的头头觉得这太过诡异,不过还是派了一个工程师去该用户家调查原因。第一天,工程师和用户一起去买冰淇淋。在店里,工程师要求买香草口味,结果出来后,汽车果然不能发动。此后几天,工程师每次都和用户一起去买,每次都由工程师临时决定买什么口味。果不其然,凡是买了香草口味,汽车就无法发动;反之则可以。(由于是工程师临时决定购买的类型,可以排除用户搞恶作剧的可能)
这个工程师是一个理性的人,也不信神,当然不会相信汽车过敏这一说。但是他觉得有更深层的原因在起作用。此后,他每天晚上和该用户一起去买冰淇淋,每次他都详细记录往返的时间、途中踩油门和刹车次数、使用的汽油型号等各种信息。许多天后,他终于发现规律:凡是买香草口味的,在商店里面花的时间少(因为这个口味受欢迎,摆放的货架靠门口)。
于是问题就转化为:停车的时间短导致汽车不能正常发动。然后,工程师就轻易找到了原因(当停车时间太短,发动机依然很热而无法驱散气阻)。
这个故事给我们几个启发:
1、不要拒绝接受貌似很诡异、很离奇、很不可能的现象。我手下的很多程序员都曾经抱怨测试提交的某个bug太怪异,对这些bug不予承认。你想一想自己是否也有类似情况?
2、要善于从一些细节发现规律,从而查出问题的根源。如果你是这个工程师,你能否通过细致的观察而发现其中的规律?


转载请以超链接形式注明作者编程随想和本文原始地址:
http://program-think.blogspot.com/2009/02/from-surface-to-essence.html
on 02月 1st, 2009

好开心,哇哈哈  :mrgreen:

兮兮我爱死你了

Tags:

on 01月 31st, 2009

都在赶。重要的是,手机快没钱了,又没网络,联络不上某R

心疼。

很疼。

很想和你一起和你看这夜景,看海,看这里的一切。

没有你,有什么意思。

on 01月 9th, 2009

只是一点点的工作问题就弄得我这么的神经质,控制不了自己去想那问题,以为能想出个解决办法明天就不用加班,然后.....好像脸色都变得很可怕。

亲爱的,对不起。真的不是故意的,只是我当时脑袋一片空白。

十分懊悔,为什么遇到问题时候就不能冷静点呢。这样连自己都觉得自己很不可靠。。。

亲爱的,对不起。。。让你受冷落了。。。