谈谈商业网站运营的6要素
很多事情看起来很复杂,变化万千,繁复无比,但那都是表象,其实都是可以归纳总结,以至摸索出一些通用的道理来的。这些通用的道理就是所谓的“道”了。商业网站运营,虽然是互联网是新技术,感觉很高科技,但一样也可以总结出这样的“道”来。前天晚上和朋友聊了些关于网站运营的话题,根据我这些年浸淫互联网的体会,也把我总结出来的所谓网“道”归纳一下,写在这里,请大家多多指点。
很多事情看起来很复杂,变化万千,繁复无比,但那都是表象,其实都是可以归纳总结,以至摸索出一些通用的道理来的。这些通用的道理就是所谓的“道”了。商业网站运营,虽然是互联网是新技术,感觉很高科技,但一样也可以总结出这样的“道”来。前天晚上和朋友聊了些关于网站运营的话题,根据我这些年浸淫互联网的体会,也把我总结出来的所谓网“道”归纳一下,写在这里,请大家多多指点。
1、定位不明确
网站建设定位是一个网站生存的根本,缺乏定位或者定位不明确的网站,在运营的时候将会迷失方向,在互联网商业的迷雾中乱串,最终以耗尽资源而告终。
在关注与实践中,发现大概核心5个点,有可能决定了一个网络社区发展的好坏,简述如下:
1. 资质
也可理解为定位,也些网站不具备社区的潜质,再怎么发展也无济于事,多是出于:需求没有市场或市场太小;定位相对狭隘,用户根据这个定位不会联想你是社区;不具备太大焦聚的可能。当然还有更多原因。另外定位不是说我是什么,而是你做了什么让别人认为你是什么。
社区作为一种网上生活的再现,黏性非常强,坦率地说在网上收邮件,看资讯的黏性都远远不如人们泡在社区里的时间长。同时,从几个数字看,所有的社区加起来整个访问量和浏览时间已和大的商业网站可以相提并论了。下面有几个深入的体验:
DNS轮循
DNS轮循是指将相同的域名解释到不同的IP,随机使用其中某台主机的技术。但其具有明显的缺点:一旦某个服务器出现故障,即使及时修改了DNS设置,还是要等待足够的时间(刷新时间)才能发挥作用,在此期间,保存了故障服务器地址的客户计算机将不能正常访问服务器。DNS负载均衡采用的是简单的轮循负载算法,不能区分服务器的差异,不能反映服务器的当前运行状态,不能做到为性能较好的服务器多分配请求,甚至会出现客户请求集中在某一台服务器上的情况。
mstsc连接到服务器,每次操作不过几下,服务器就死机重新启动了! 也没在意event,昨天实在受不了了,看下日志,发现了下面的错误报告! 打印机 Tencent Virtual Printer 所需的驱动程序 Tencent Virtual Printer Driver 未知。登录之前,请与管理员联系,安装驱动程序。 看了这个错误报告,我就纳闷了,服务器并没有装腾讯的东西啊! 咋回事呢!!!!!!!! goole了一下,也看到了类似的症状!别人回复说问题原因在客户端,不在服务器! 最后,终于看到了! 是我本地安装了QQ,QQ在2007beta3中就添加了虚拟打印机!!!!!! 把打印机的选项去掉就可以了!! 如图
用了coolcode插件,发现好多含有HTML代码的文章被执行了! 很郁闷的事情,到该插件的官方看了一下,貌似没有被修复! google了一下,找到了方法! 忘记在哪位仁兄的BLOG上看到方法的了!抱歉了啊! 压缩包内的quicktags.js文件直接覆盖到 wp-includes/js/ 下即可,后台添加文章部份就有coolcode的标签了! coolcode.php直接覆盖原来的coolcode.php即可!!其中 Coolcode为3.4 Version….WordPress2.31通过! 其他版本不知道! 大家自己修改! coolcode.php中的貌似316行附近 coolcode.php中的貌似327行附近 coolcode.php中的貌似351行附近 coolcode.php中的貌似82行附近 附件在这里啊,附件在这里!!!!! CCode+JS.rar
今天到公司,NND, 公司网站的cms_session表又坏了,保存不 了session了,登陆不了! 日志查看了一下,N多错误! 靠靠靠! 查了N多资料, 发现这篇BLOG 写的蛮详细的,COPY过来! 最后我解决的方法是 以下是 网友的BLOG详细资料! 我的网站出问题了,访问一看,果然全屏报错,检查mysql日志,错误信息为: 提示说cms的文章表dede_archives被标记有问题,需要修复。于是赶快恢复历史数据,上网查找原因。最终将问题解决。解决方法如下: 找到mysql的安装目录的bin/myisamchk工具,在命令行中输入: 然后myisamchk 工具会帮助你恢复数据表的索引。重新启动mysql,问题解决。 问题分析: 1、错误产生原因,有网友说是频繁查询和更新dede_archives表造成的索引错误,因为我的页面没有静态生成,而是动态页面,因此比较同意这种说法。还有说法为是MYSQL数据库因为某种原因而受到了损坏,如:数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。 问题的编号为145 2、问题解决办法。 当你试图修复一个被破坏的表的问题时,有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立,删除信息所指出的文件并再试一次–这通常是上一次修复操作遗留下来的。 这三种修复方法如下所示: 第一种是最快的,用来修复最普通的问题;而最后一种是最慢的,用来修复一些其它方法所不能修复的问题。 检查和修复MySQL数据文件 如果上面的方法无法修复一个被损坏的表,在你放弃之前,你还可以试试下面这两个技巧: 如果你怀疑表的索引文件(*.MYI)发生了不可修复的错误,甚至是丢失了这个文件,你可以使用数据文件(*.MYD)和数据格式文件(*.frm)重新生成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL服务并连接到这个服务上,使用下面的命令删除表的内容: mysql> DELETE FROM tblName; 在删除表的内容的同时,会建立一个新的索引文件。退出登录并重新关闭服务,然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据文件。最后,使用myisamchk执行标准的修复(上面的第二种方法),根据表的数据的内容和表的格式文件重新生成索引数据。 如果你的表的格式文件(tblName.frm)丢失了或者是发生了不可修复的错误,但是你清楚如何使用相应的CREATE TABLE语句来重新生成这张表,你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题,使用上面的方法重建一个新的)一起使用。首先制作一个数据和索引文件的拷贝,然后删除原来的文件(删除数据目录下有关这个表的所有记录)。 启动MySQL服务并使用当初的CREATE TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了,但是最好你还是执行一下标准的修复(上面的第二种方法)。 3、myisamchk工具介绍(见mysql的官方手册) 可以使用myisamchk实用程序来获得有关数据库表的信息或检查、修复、优化他们。myisamchk适用MyISAM表(对应.MYI和.MYD文件的表)。 调用myisamchk的方法: shell> myisamchk [options] tbl_name … options指定你想让myisamchk做什么。在后面描述它们。还可以通过调用myisamchk –help得到选项列表。 tbl_name是你想要检查或修复的数据库表。如果你不在数据库目录的某处运行myisamchk,你必须指定数据库目录的路径,因为myisamchk不知道你的数据库位于哪儿。实际上,myisamchk不在乎你正在操作的文件是否位于一个数据库目录;你可以将对应于数据库表的文件拷贝到别处并且在那里执行恢复操作。 如果你愿意,可以用myisamchk命令行命名几个表。还可以通过命名索引文件(用“ .MYI”后缀)来指定一个表。它允许你通过使用模式“*.MYI”指定在一个目录所有的表。例如,如果你在数据库目录,可以这样在目录下检查所有的MyISAM表: shell> myisamchk *.MYI 如果你不在数据库目录下,可通过指定到目录的路径检查所有在那里的表: shell> myisamchk [...]
终于有空了,把BLOG从2C-space转到了WordPress,上海下雨了,听SCY说 苏州也下雨了,阴沉沉的天气也影响了心情! 听Gleon说他一个多月没回家了,今天要回家,Scy今天也请假处理自己的事情去了! 空闲的时间我最多,不管是上班还是休息日!但时间弄到哪里去了,我自己也搞不清楚.从6月份到现在自己的技术很少有进步,自己也感觉得到,心里也默默的挂念这事,近日也发现自己努力的去学习了,希望不要跟他们俩拉下的太多! 周四的晚上,听这电脑里的后街男孩的歌,回想以前在大学时,三个人一起在电脑面前,竞赛的模样,再想找找一点照片来怀念一下,而却找不到半张!后悔当初没有出来到什么地方留影纪念了!现在都到了社会,为了自己的事情东奔西跑,少了三个人之间的交流,隔膜越来越深了,或许他们没有注意到,是我自己多情而已! 总说我的空闲时间比他们的多,但是想找点写心情的时间都找不到!有时MSN,QQ上线,看到好久没有打招呼的朋友,想说几句,但是怕花掉太多的时间而放弃了交谈!久而久之,他们总会抱怨点什么,加上他们自己的处境,难免对我产生点误会,我很想解释,….. 哎,算了吧,随他去吧,自己都很难管的了,还去管他们干什么呢! 忙 忙 忙 转换完BLOG,发几句牢骚,大家勿骂,谢谢! BTW:WordPress果然很强大!!!
CNXCT小组的博客 is Stephen Fry proof thanks to caching by WP Super Cache