猫窝私语 — Makumo's Blog

玛酷猫的温馨小窝,记录生活点点滴滴。

@玛酷猫17 年前

11/13
13:43
他山之石

阿江: 网站要专业,更要简单

不知道多久以前,上网是被作为一门技术来看待的,甚至曾经有人把上网和开车一起看成21世纪必须掌握的两门技术之一,internet是神秘的,是高科技。但现在不同了,网络不再是工具,而变成了玩具,男的女的老的少的,懂电脑的不懂电脑的,有文化的没文化的,会打字的不会打字的,统统都来上网了,任何一个人过来,你只要告诉他哪个是电源开关,点哪个图标上网,点哪个图标聊天就行了。

于是,网络不再属于少数“精英”,而开始属于多数“菜鸟”。

菜鸟,这不是歧视,因为让所有的人去学习网络技术,就像让所有的中国人去学习英语一样是不切实际的。所以,除非他们对技术感兴趣,否则我们就应当让网民们不需要学习就可以使用互联网。

为什么网址站会成为千千万万电脑的首页?因为她让上网变得只需要点击,打开电脑,点IE,hao123就出来了,然后想看新闻看新闻,想看股票看股票,想看天气看天气,想查车票查车票,想玩游戏玩游戏,想听歌就听歌,只要会点鼠标就行了。很多人,网龄很长,却根本不知道什么叫“输入网址”,那些带着斜杠、点点和字母的东西对很多中国人来说还是很要命的。

说到字母,现在英文的或者长的域名,在普通网民圈儿里是很难混的。很早以前,有个网友,她的个人主页域名(当时还是二级域名)主词是rosestory,直译是玫瑰故事?对懂英文的人来说,还挺有意境的,但是,对不懂英文的人来说,这么长的域名可要了命了,记住的可能性基本是零。

说到域名好不好记,典型的就是百度,很多不怎么会输网址的人也会输baidu.com,而要让他们输google.com,那可是相当困难了。而且,人们记住的是“百度”,.com是没人去记的,只是见多了就想着那么写才像是网址,所以这么说来,google虽然用上了更短的g.cn,普通网民照样记不住。(另外,百度的mp3搜索、知道、贴吧,这些都是充分迎合菜鸟级的网民而获得成功的,具体就不细说了,否则满篇都说他了,跟百度枪文似的。)

还是说回域名来,我的免费统计用51.La的域名,当时犹豫很久,最后还是用了,毕竟.com里能注到的短域名实在不多,而如果用含有stat那样的英文单词的域名,又很担心英文不好的站长们记不住,还不如51.La这样的拼音名好记呢。但是大大的问题就是这个La后缀,在很多人看来,后面没有.com就不像是网址,当有人求助“怎样知道网站的访问量”,别人给回“51.La”,可能问的人根本就不知道回的人是在说啥。有人要问,站长都知道有La这个后缀吧?非也,很多站长都是在搞明白了51.La之后才知道了La这个后缀。为了让人记住这个后缀,我不得不在Logo和网站名称中充分体现.La的存在,但即便如此,很多新站长还是要经过一小段时间的迷茫才能接受,从这种意义上说,相对于“阿江统计”,“51.La”并不便于对新站长认知“统计”进行启蒙。

在迎合普通网民的战斗中,英文败给拼音,而拼音又败给数字,因为懂拼音的人虽然比懂英文的多,但还是有很多人不懂拼音,并且南方因为方言和普通话差别大,懂拼音的人也常会拼错,数字则不同,人人都懂,而且数字还有易听易记的特点。于是,xxx123之类的曾经被站长们看不起的域名大行其道,风靡一时;QQ战胜了电子信箱,成为普通网民的主要沟通工具。

有一个现象,站长类论坛里很少出现的,其他论坛出现的多,就是常常会有人问如何上传图片,甚至很多论坛的置顶帖子里都会有一个教人上传图片的教程,即便如此,还是很多人传不了,会出现很多类似《到底怎样上图啊》、《终于学会上图了》之类的帖子来。由此可见现在网络中上传图片的功能仍然不太适合普通网民使用,不知道这要等多久之后可以有所改观。

我们看音乐站。以前的音乐站,进入之后首页是几张新专辑的图片、介绍,然后就是歌手分类列表。访问者打开网站,先找到自己喜欢的歌手,再点开专辑列表,再点开专辑找到要听的歌。现在的音乐站变了,首页罗列了几百上千首时下最热门的歌曲,点一下就能听。这就是变化,实际上,现在大多数网民要的就是这种的,打开首页直接选几首热门的歌就开听了。

再说说网络游戏。很早以前是江湖,基于文字的角色扮演网络武侠游戏,后来被传奇之类的客户端游戏取代了,原因很简单,前者太抽象了,什么都是文字,送朵献花扔个炸弹都是靠点按钮的,像在控制一个机器,而结果也只是屏幕上的一行字,“×××向×××投掷炸弹,×××生命值减少×××”。而到了传奇,这些就都直观多了,谁站在谁的哪个方向、长啥德性都一目了然,扔个暗器过去就能看到血溅梅花的效果。再看现在,WEB游戏又有取而代之的趋势了,WEB游戏优势明显的很,不用下客户端,不用升级,不需要老板键,一切就像浏览网页一样简单,如此之低的门槛,恐怕网络游戏更大范围的风暴来临也不足为怪了。怎样看管好你的孩子,或者你的父母怎样看管好你,将会是更大的问题了。

还有就是个人主页的变化,以前网民上网两件大事,一是申请免费信箱,二就是申请免费主页,做一个个人主页才表示自己上网了,见人不但要留信箱,还要留主页。虽然有主页,但并不把自己当站长看的,因为拥有主页只能说明你是一个老鸟网民,还照样是网民的身份。现在的新网民上网还有类似的事情做,但是多数已不再是个人主页,而是用免费博客、QQ空间、51空间之类的,并且这个群体要比原来个人主页的群体还要大,原因就是门槛降低了,不需要研究技术就可以掌握了。

网络,现在对多数普通网民来说就是一个消遣的场所,其实我个人很希望网民们能像以前的老网民那样有耐心,仔细的研究、品味一下网络里很多优秀的东西,这样的网民当然总量肯定还有不少,但是比例小多了,要把他们找出来太难,要把他们聚集在一起更难。

好像越说越乱,举的例子都不一定恰当,但结论是显而易见的,就是:

作为站长,我们要尽量减少访问者需要“学习掌握”的东西,最好是访问者一进来就知道要怎么做,并且很乐意去做。

我们应当追求“专业”,但更应当追求“简单”,因为网络早已经平民化了。

阿江: 网站要专业,更要简单

@玛酷猫17 年前

11/13
01:01
WordPress 建站日志

WP的代码高亮提示插件

今天无意翻阅以前发的文章,发现原来使用的高亮插件coolcode版面乱掉了,试着调了一会CSS,效果依旧不是很理想,无奈只有放弃。(后来才发现是定了首行缩进的缘故,不过考虑到coolcode修改经常标签丢失,也还是放弃了)

在网上搜索了下,先用的是[name]Syntax Highlighter,http://code.google.com/p/syntaxhighlighter/[/name],页面显示还是很漂亮的,不过可能是纯JS的缘故,我这显示总是用一种滞后。页面打开后,显示的是普通的代码,代码比较长,页面版面变形厉害,等页面输出完毕后,代码部分才变成需要的高亮样式,感觉比较难受,而且个人喜欢使用禁用JS的火狐上网,看自己页面效果全无。只有先放一边了。

下载[name]iG Syntax Hiliter,http://blog.igeek.info/still-fresh/2006/02/25/code-for-fun/[/name],启用的时候不同的提示严重错误,无法启动,错误代码是:路径/geshi.php不存在,一头雾水,在服务器上查了下,文件的确在那,头晕中。

[name]Highlight Source Pro,http://blog.kno.at/tools/highlight-source-pro[/name]和[name]WP-Syntax,http://wordpress.org/extend/plugins/wp-syntax/[/name]有点类似,使用pre标签,每行代码短还好,代码一长,滚动条就出来了,有点破坏整体风格,虽然有些人可能喜欢滚动条。

暂时先用着WP-Syntax了,毕竟用到代码的地方并不是很多,有空再去网上找找其他的高亮插件了。

WP的代码高亮提示插件

@玛酷猫17 年前

11/12
15:06
数据库

优化SQL Server的内存占用之执行缓存

(转载以便日后查找,原作者实在没找到是谁,不过还是很感谢作者)

在论坛上常见有朋友抱怨,说SQL Server太吃内存了。这里笔者根据经验简单介绍一下内存相关的调优知识。首先说明一下SQL Server内存占用由哪几部分组成。SQL Server占用的内存主要由三部分组成:数据缓存(Data Buffer)、执行缓存(Procedure Cache)、以及SQL Server引擎程序。SQL Server引擎程序所占用缓存一般相对变化不大,则我们进行内存调优的主要着眼点在数据缓存和执行缓存的控制上。本文主要介绍一下执行缓存的调优。数据缓存的调优将在另外的文章中介绍。

对于减少执行缓存的占用,主要可以通过使用参数化查询减少内存占用。

1、使用参数化查询减少执行缓存占用

我们通过如下例子来说明一下使用参数化查询对缓存占用的影响。为方便试验,我们使用了一台没有其它负载的SQL Server进行如下实验。下面的脚本循环执行一个简单的查询,共执行10000次。
  首先,我们清空一下SQL Server已经占用的缓存:

dbcc freeproccache

  然后,执行脚本:

DECLARE @t datetime
SET @t = getdate()
SET NOCOUNT ON
DECLARE @i INT, @count INT, @sql nvarchar(4000)
SET @i = 20000
WHILE @i <= 30000
BEGIN
    SET @sql = 'SELECT @count=count(*) FROM P_Order WHERE MobileNo = ' + cast( @i as varchar(10) )
    EXEC sp_executesql @sql ,N'@count INT OUTPUT', @count OUTPUT
    SET @i = @i + 1
END
PRINT DATEDIFF( second, @t, current_timestamp )

输出:
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。
11

使用了11秒完成10000次查询。

我们看一下SQL Server缓存中所占用的查询计划:

Select Count(*) CNT,sum(size_in_bytes) TotalSize From sys.dm_exec_cached_plans

查询结果:共有2628条执行计划缓存在SQL Server中。它们所占用的缓存达到:
92172288字节 = 90012KB = 87 MB。
Read More →

优化SQL Server的内存占用之执行缓存

@玛酷猫17 年前

11/11
21:22
心情点滴 建站日志

单身同胞们节日快乐

也不知道是哪年,“光棍节”悄然诞生,据说是诞生于网络,不过已经无从考证。中午和一帮“光棍”杀向酒店,要了几个菜,海吃海喝了一通。中午的盒饭适量太差,很久没有改善伙食了,趁着这个机会好好满足下,O(∩_∩)O

下班顺便理了个发,很久没又修理头发了,早上起来一照镜子差点吓一跳,-_-!

晚上把小窝模板调整了下,首先是把备案号加上,昨天都忘了加了,幸好没被查到,要不铁定关站处理。字体调成13像素,毕竟在19’上面看12像素字还是很难受的,调完感觉13字也小了点,先凑合着看了,不行再调大1个像素。分类和标签挪到了文章上面,醒目了些。总感觉文章底部经常被忽略。

先去洗个澡,清理下碎头发,回来把边栏处理下,基本搞定,后面就慢慢调细节啦,明天去找人做个头图片O(∩_∩)O

光棍节最流行歌曲:单身情歌
[audio:http://love.hinews.cn/mt071229ab/2008/by_qrjzt03020080213danshenqingge.mp3]

附上光棍节庆祝方式[转自百度百科]
Read More →

单身同胞们节日快乐

@玛酷猫17 年前

11/10
23:26
心情点滴 建站日志

小窝重新装修

重新装潢了下小窝,铺了下地板,换了新的墙纸,加了新的灯饰,顺便掏了个壁橱,不过幸好没掏到隔壁去O(∩_∩)O~~

升级到最新的2.6.3,我原来的版本太低了。。。按照说法升级后,直接白屏,不管输入wp-adminupgrade.php还是wp-admininstall.php还是后台登陆亦或是首页。无奈只有把服务器上程序删除了,把2.6.2程序传到服务器上,upgrade更新数据库后,终于可以进后台了。菜单模式变了,一时好不习惯,上面硕大个提示:“主题损坏,还原为默认主题。”我把文件都删了,不提示才怪。-_-!想想原来的K2主题本来就修改了一些代码,这回八成不兼容了,在网上寻觅了一番,看到 [name]inove,MG12,http://www.neoease.com/inove/[/name] 的一款主题十分喜欢,就拿来先用了。不过感觉头部有点不协调,右侧的内容还是默认的,明天再慢慢调了,今天不早了,先睡觉了。

小窝重新装修

@玛酷猫17 年前

11/6
22:57
心情点滴

写在深秋

转眼半年即逝,一直都没有来料理自己的小窝,如今小窝变得破旧不堪、蛛蛛网遍布了……每每想写点东西,总是心情烦躁,静不下来,落笔几个字就关掉页面去看电视了。

大半年前离开原来的工作单位,压抑的许久的心情也得到了放松,在家里无忧无虑的待了一段时间。可在随后的寻找工作期间又渐渐迷茫起来。总是想换一个环境,换一个行业,多学一种技能,几次碰壁失利后才慢慢发现自己的想法是多么的幼稚,在如此严峻的就业环境下,一旦你给自己画好了圈子,你就很难在跳出这个圈子,现在想想毕业的时候,就业指导老师反复挂在嘴边的“先就业后择业”,感觉是那么的空洞。就像高考前班主任一再强调只要考上大学,前途怎么怎么样呀,人生怎么怎么样呀,遇上了扩招泛滥大潮,一切话语还不是如此无力,前两年有句笑话,说是从天桥上扔块砖头,砸到十个有八个是大学生,如今已升级成研究生了,虽然多少有点夸张,不过现状也差不了多少了。不过几次面试后也发现自己原来也像井底之蛙,自己以前学到的东西是多么肤浅,于是乎,依旧做回了自己老本行,夏天刚刚结束,加入了一家新的公司,工作虽然辛苦点,但相比之前也充实了些,当然新收获也是有的。

半年来股市一泄千里,被打回了原形,年初朋友还劝我进去试试,说不行还有点收获,当时也比较心动,账户也开好了,可是窘于没有多余的闲钱,也就是远处观望下而已。现在想想有些庆幸,也有些遗憾,庆幸的是自己没有太多影响,遗憾的是没有坐一坐这股市过山车,可能以后也难遇到了。

我总觉得想到了就该去试一试,去做一做,即便是浅尝即止。人生苦短,及时行乐。错过了就难以在得到了,就像某位电台NJ再一次节目中说道:一次偶然的机会收到家乡寄来的枇杷,吃起来却完全不是儿时记忆里的那种味道,回到家乡,重新吃起枇杷,才发现味道还是那时的味道,只不过人已经不是那时的人,不禁惆怅万分。前不久偶然遇到一小学同学,把我加入了小学同学群,看着群里的人名,已经大多没有了印象,突然间才发现,不仅仅是小学同学,中学、大学同学也有许多人断了联系。用手机群发了条问候短信给号码本里那些许久没有联系的朋友,看着一条条的回复,不禁有些感动。

今天删除了两百多条垃圾评论,年前再找个时间把小窝翻新一下,好像现在WP都出到2.7了,看来还是要坚持写下去,看着以前的足迹,才真真感觉到:我来过,我做过。

You Are Not Alone
[audio:http://learning.sohu.com/zt/freshenglish/sep17/songs.mp3]

写在深秋

@玛酷猫18 年前

06/30
22:12
动漫

MADA MADA DANE(まだまだだな)

等全国大赛等的不耐烦了,又把《网球王子》翻了出来,重头看了一遍,又听到龙马经常挂在嘴边的“まだまだだな”。总觉得前面比后面画的要好,夸张的部分比较少,后面全都是超级大绝招,出招放招绚丽得一塌糊涂,看多了也就视觉疲劳。不过穿插在比赛中的Q版网球王子和搞笑版还是蛮好玩的,尤其是Q版的,送张Q版图片上来,^_^!

(喝着可乐、吃着暴米花、看动画片还是蛮安逸呀!)

MADA MADA DANE(まだまだだな)

@玛酷猫18 年前

06/27
21:21
前端 他山之石

Web 前端优化最佳实践之内容篇[转]

(朋友发给我的,觉得很不错就转到这来了,方便随时查看。)

Yahoo! 的 Exceptional Performance team 在 Web 前端方面作出了卓越的贡献。广为人知的优化规则也由 13 条到 14 条,再到 20 条,乃至现在的 34 条–真是与时俱进啊。最新的 34 条也针对不同的角度做了分类。

面向内容的优化规则目前有 10 条。

1. 尽量减少 HTTP 请求 (Make Fewer HTTP Requests)

作为第一条,可能也是最重要的一条。根据 Yahoo! 研究团队的数据分析,有很大一部分用户访问会因为这一条而取得最大受益。有几种常见的方法能切实减少 HTTP 请求:
    * 1) 合并文件,比如把多个 CSS 文件合成一个;
    * 2) CSS Sprites 利用 CSS background 相关元素进行背景图绝对定位;参见:CSS Sprites: Image Slicing’s Kiss of Death
    * 3) 图像地图
    * 4) 内联图象 使用 data: URL scheme 在实际的页面嵌入图像数据.

2. 减少 DNS 查找 (Reduce DNS Lookups)

必须明确的一点,DNS 查找的开销是很大的。另外,我倒是觉得这是 Yahoo! 所有站点的通病,Yahoo!主站点可能还不够明显,一些分站点,存在明显的类似问题。对于国内站点来说,如果过多的使用了站外的 Widget ,也很容易引起过多的 DNS 查找问题。

3. 避免重定向 (Avoid Redirects)

不是绝对的避免,尽量减少。另外,应该注意一些不必要的重定向。比如对 Web 站点子目录的后面添加个 / (Slash) ,就能有效避免一次重定向。http://www.dbanotes.net/arch 与 http://www.dbanotes.net/arch/ 二者之间是有差异的。如果是 Apache 服务器,通过配置 Alias 或mod_rewrite 或是 DirectorySlash 能够消除这个问题。

4. 使得 Ajax 可缓存 (Make Ajax Cacheable)

响应时间对 Ajax 来说至关重要,否则用户体验绝对好不到哪里去。提高响应时间的有效手段就是 Cache 。其它的一些优化规则对这一条也是有效的。

5. 延迟载入组件 (Post-load Components)

6. 预载入组件 (Preload Components)

上面两条严格说来,都是属于异步这个思想灵活运用的事儿。

7. 减少 DOM 元素数量 (Reduce the Number of DOM Elements)

8. 切分组件到多个域 (Split Components Across Domains)

主要的目的是提高页面组件并行下载能力。但不要跨太多域名,否则就和第二条有些冲突了。

9. 最小化 iframe 的数量 (Minimize the Number of iframes)

熟悉 SEO 的朋友知道 iframe 是 SEO 的大忌。针对前端优化来说 iframe 有其好处,也有其弊端,一分为二看问题吧。

10. 杜绝 http 404 错误 (No 404s)

对页面链接的充分测试加上对 Web 服务器 error 日志的不断跟踪能有效减少 404 错误,亦能提升用户体验。值得一提的是,CSS 与 Java Script 引起的 404 错误因为定位稍稍”难”一点而往往容易被忽略。

这是内容篇的 10 条。应该说具体引导性的内容还不够详细。逐渐会根据自己的理解补充上来。

Web 前端优化最佳实践之内容篇[转]

@玛酷猫18 年前

06/21
21:52
心情点滴

郁闷的一天。。。

今天轮排到值班,向往常一样来到公司,结果忘了今天周末,等了快一个小时开门的才来=。=!

中午去吃饭,吃完付完钱就急急忙忙走了,到办公事才发现没拿找零=。=!

下午下班准备回家,外面却下起了大雨,等的稍微小点就往家赶,虽然雨小,不过到家了衣服也湿透了,到家还没有10分钟,雨停了=。=!

晚上上网ADSL死活拨不上号,只有无聊的去看全是广告的电视=。=!

不过晚上吃了一大碗鸡汤面,还是很舒服的。

看来有首歌唱的真不错,“最近比较烦”

[audio:http://www.yingshan.gov.cn/xxbbs/UploadFile/200513120943168.mp3]

郁闷的一天。。。

@玛酷猫18 年前

06/18
09:30
他山之石

网站SEO并非一定需要静态化。

在国内,很多“SEO专家”给客户网站的第一诊断结果就是要页面静态化。这倒不是因为动态页面就做不了SEO,而是相对静态页面而言,动态页面的SEO更加难做,受“SEO专家”的技术能力所限而已。

对于搜索引擎而言,在主观上对静态页面和动态页面并没有特殊的好恶,只是很多动态页面的参数机制不利于搜索引擎收录,而静态页面更容易收录而已。此外,页面静态化在一定程度上也提高了页面访问速度和系统性能及稳定性——这使得在搜索引擎优化上面,为使得效果更加明显,问题简单快速解决,大家对站点的静态化趋之若骛。

然而对于一些大型网站,静态化带来的问题和后续成本也是不容忽视的:

由于生成的文件数量较多,存储需要考虑文件、文件夹的数量问题和磁盘空间容量的问题———需要大量的服务器设备;

程序将频繁地读写站点中较大区域内容,考虑磁盘损伤问题及其带来的事故防范与恢复——硬件损耗要更新、站点备份要到位;

页面维护的复杂性和大工作量,及带来的页面维护及时性问题——需要一整套站点更新制度和专业的站点维护人员;

站点静态化,增加了更新维护难度和网站管理人员工作强度,增加了硬件设备需求和损耗速度,增加了站点潜在的访问冲突和故障概率。对于一个大型网站而言,这都是必须考虑的问题。

对于SEO优化,我们不需要真正静态化,只需要假装就可以了。动态页面也一样能够做好SEO优化。

目前大多数搜索引擎基本都能收录动态页面,使用动态页面的站点数也远远大于静态页面的站点数。

许多大型网站虽然网址的后缀为。htm,但其实还是动态页面,只是用了URL Rewrite的方式“欺骗”搜索引擎,真正完全静态的没有发现几个。

目前对于一个动态网站,实施相对静态化的做法基本有如下几种:

1. 伪静态,URL Rewrite方式。

2. 类似蜘蛛的方法,动态站点也存在,只是通过一个程序去抓取整个站点并保存发布为需要访问的静态站点。

不论是真静态页面还是伪静态页面,在方便搜索引擎收录这一点上,效果都是一样的。既然如此,为什么不使用效率更高的“相对静态化”的方法,以避免真正静态化所产生的诸多问题呢?

在页面更新维护问题上,即使是伪静态,也带来了不少维护的复杂性和工作量。目前较为可取的更新方式有:

触发式更新:当维护人员在后台更改某些信息后,系统自动或提供手动更新相应显示页面。

独立、分片式更新:更新与维护分开,页面划分为不同的区,根据一定的规则对于区进行更新。区之间的整合与分离,有的是采用活动域,有的是采用SSI(Server Side Include)。

对于独立、分片式更新,应当是大型网站相对静态化后较为理想的更新维护模式:

1. 将各页面定义分区、编号,给定存储规则和更新规则,更新规则分为“依据数据变更更新”和“周期更新”。

2. 对于各区采用优先级的方式,并提供手工触发的即时更新,以保证部分信息的更新时间需要。

3. 静态页面替换动态页面,同时保留动态页面,并在静态页面未生成完毕时采用动态页面代替。

静态化对于网站SEO来说,应当只是一个信号,告诉搜索引擎我的站点很好收录,然后带领搜索引擎尽可能多的“浏览”站点内的内容。只要能够方便浏览和收录,不论是静态页面还是动态页面,搜索引擎都会一视同仁的去收录。

对于小网站而言,站点静态化或许是解决网站收录量的一个简便的办法,而对于大网站来说,则要认真考虑了,是不是真的有必要去做静态化,还是做一下“相对静态化”就够了。

网站SEO并非一定需要静态化。