By 老猫 | 3月 25, 2011 - 1:26 下午 - Posted in 网站建设

       
       有些迷糊,把网络上学到的东西.摘抄总结到此,只用作自己参阅,如果大家用得着.记得常来看看
       寻找 niche 和建站注意事项:
       先从大方向入手,慢慢的细分,直到找到适合我们的 niche
       1.在我们选择产品时,它的热度和利润是同等重要的
       2.NICHE的寻找必须要靠经验的积累,一定要在实践中,创新与摸索!
       3.寻找一个合适域名!一般来说:com优先,在com 没有适合的情况下,选择net或是org 后缀,info也是不错的选择
       4.使用独立IP,选择了WORDPRESS搭建网站后,我们便可以选择联盟了,如 googleadsense+amazon 的组合进行搭配,当然, googleadsense+clickbank 也是不错的选择.
       5.外链
一般来说,英文外链分为以下几种:
        1.友情链接 (一般来说,对于国人是用不着的)
        2.Web2.0 网站
        3.书签提交
        4.留言板Spam
        5. 目录提交
        6.博客网络
        7.论坛profile
        8.博客评论
        9.文章目录提交

       一般来说,我们做的外链,应该是描文本形式,而非直接的网站地址形式,例如,我们的网站是:delld600.net,我们优化的关键词是:dell d600。那么,我们应该做的链接应该是包含delld600 的描文本链接,而非delld600.net!试想,一个想要购买 dell d600 的人,怎么会去搜索delld600.net 呢?

       其实,对于外链资源,我们应该给自己进行准备,整理出自己的资源列表,并分类处理好,这是非常好的习惯,也是非常重要的,至于怎么样去分类,个人有个人的选择,这里就不再啰嗦!一般来说,我喜欢利用与站点内容相关的外链资源,这就是为什么,我说我们最好能整理出自己的一套列表,这样,我们在进行外链建设时,就不会出现,一时之间毫无头绪,或者是拿着工具乱轰的局面!

       对于新手来说,一开始手动进行外链的建设是很有必要的,只要这样,你才会很清楚,哪些是好做的,哪些是不好做的!高质量的外链往往是具有相关性的,很多情况时,大家对NOFOLLOW 都是嗤之以鼻,其实不然,既然是做英文,也就不止谷歌一家搜索引擎,其实大部分搜索引擎是并不承认的,所以对于NOFOLLOW 的链接,也是有必要去建设的!大多情况下,只有稳定的链接,才能算是有质量的链接,试想一个链接,加上去,没过几天就没了,搜索引擎会怎么去判断这个链接的好坏呢?

       最后提到一点,对于外链的建设,我们一定要有自己的计划,绝对不能出现三天打鱼两天晒网的情况,只有这样,我们的网站,才更有机会获取好的排名,并保持稳定!

By 老猫 | 3月 24, 2011 - 11:02 下午 - Posted in 心灵漫步

       
       就算岁月怎么流逝,命运如何安排,都无法磨灭爱的印迹,她就在那里。永远。。。

By 老猫 | 3月 9, 2011 - 12:37 下午 - Posted in Google

       
       数据存储区查询将返回零个或多个单一类别的实体。它也可以只是返回查询所得的实体的键。查询不仅可以根据条件(必须匹配实体属性的值)进行过滤,还可以根据属性值对返回的实体进行排序。查询也可以通过键来进行筛选和排序。

       在传统的关系型数据库中,查询会实时地根据数据表(由开发人员决定如何对其进行存储)进行计划和执行。开发人员还可以让数据库在指定的列上创建和维护索引以提高相关查询的执行速度。

       App Engine的做法与此大不相同。在App Engine中,每个查询都有一个与之对应的由数据存储区维护的索引。当应用程序执行查询时,数据存储区将会找出该查询的索引,扫描并找到第一个与之匹配的行,然后逐行返回索引中的实体,直到发现与查询不匹配的行为止。

       当然了,这需要App Engine预先掌握应用程序将要执行哪个查询才行。虽然它无须预先知道具体的筛选条件,不过却需要知道查询中实体的类别、用于筛选或排序的属性、筛选器的操作符以及排列顺序等。

       默认情况下,App Engine会根据各类实体的既有属性为简单查询提供一组索引。为了执行更复杂的查询,应用程序必须在其配置文件中添加索引声明。当你在本地计算机上利用App Engine SDK所提供的那个开发版Web服务器测试应用程序时,App Engine SDK会监视所执行的查询并帮你生成一份配置文件。在你上传应用程序的时候,数据存储区就会自动地为测试时执行过的每条查询生成索引,你也可以手工编辑索引配置文件。

       当应用程序创建了新实体或是更新了现有实体时,数据存储区会更新相应的索引。这也就使得查询变得非常快(每个查询都是一个简单的表扫描译注1),而实体的更新操作则反之(一个小小的修改就可能会使很多表译注2都需要更新)。事实上,基于索引的查询性能并不受数据存储区中实体数量的影响,而只会受到结果集大小的影响。

       索引是值得关注的,因为它们会占用空间,而且会增加实体更新操作所需的时间。我们将在第5章中详细讨论索引。

       译注1: 其实这里用“索引扫描”来比喻会更加贴切(我不知道GAE中索引的具体组织形式,虽然本书有所提及,但我始终认为G公司应该不会把索引做得如此简单,毕竟系统IO的速度在那摆着)。

       译注2: 这里指定的应该是“索引”或“索引表”。同上,索引和表这两个概念也不一样。
Read The Full Story…

By 老猫 | - 12:30 下午 - Posted in Google

       
       App Engine应用程序将其数据保存为一个或多个数据存储区实体(entity)。实体拥有一个或多个属性(property),每个属性都有一个名字和一个值,这个值可以是任何一种基本值类型。每个实体都有一个命名类别(kind),它用于在查询中对实体进行分类。乍一看上去,这跟关系型数据库没什么不同:同一类别的实体就像是表中的行,而属性就像是列(字段)。实际上,实体和行之间有两个显著的区别:第一,同类别的两个实体无须拥有相同的属性;第二,两个实体的同名属性可以拥有不同类型的值。这样,数据存储区实体就成“无架构”的了。你很快就会看到,这种设计既提供了强大的灵活性,同时也带来了一些维护上的问题。

       实体跟表行之间的另一个区别在于:实体中的某个属性可以拥有多个值。这个功能有点诡异,不过当你弄明白之后就会发现它的作用其实非常大。每个数据存储区实体都有一个唯一键,它既可以由应用程序提供,也可以由App Engine 生成(随你高兴)。跟关系型数据库不同,这个键不是“字段”也不是属性,而是实体的一个独立元素。如果知道实体的键,就能够快速地将其取出来,还可以执行基于键值的查询。

       实体的键在其创建之后就不能修改了,其类别也一样。App Engine通过实体的类别和键去判断它究竟存储在一大堆服务器中的什么位置(不过,键和类别都不能保证某两个实体会存储在同一台服务器上)。

By 老猫 | - 12:27 下午 - Posted in Google

       
       大部分Web应用程序都需要在处理请求的时候存储信息,以便在处理后续请求时能够直接使用。小网站通常都有这样的服务器布置:一台用于整个网站的数据库服务器,以及一台或几台连接到数据库服务器上的Web服务器(存储或检索数据)。使用单个中心数据库服务器可以让网站仅有一份标准数据,这样用户在访问不同服务器时也就可以看到一致且最新的信息了。不过,中心服务器在达到其并发连接上限时是很难扩展的。

       过去十年中,Web应用程序最为常用的数据存储系统是关系型数据库,由行和列组成的表赋予了它空间上的高效性和简洁性,它还拥有索引以及用于执行查询的原生计算功能,尤其是“连接”查询,它能够将多个相关的记录当做一个可查询单元来处理。其他的数据存储系统还有层次数据存储(文件系统、XML数据库)和对象数据库等。每种数据库都各有优劣,对于某个应用程序而言,究竟哪种最适合,这取决于应用程序数据的本质及其访问方式。此外,每种数据库都有自己的一套技术用于处理“服务器不能与时俱进”的问题。

       GAE的数据库系统看上去非常像一个对象数据库。它与能进行连接查询的关系型数据库不同,如果你在开发Web应用程序时用惯了关系型数据库(就像我这样的),那就有必要改变一下对应用程序数据的思考方式了。跟运行时环境一样,App Engine数据存储区的设计目标也是“抽象”的,它让App Engine去处理应用程序在分布和扩展等方面的细节问题,这样你的代码就可以专注于其他事情了。

By 老猫 | - 12:24 下午 - Posted in Google

       
       大部分网站都有那种“需要发送给浏览器但却不会因为日常操作而发生变化”的资源。用于描绘网站外观的图片和CSS文件、在浏览器中运行的JavaScript代码、不含动态组件的HTML网页文件等都属于这样的资源,人们将之统称为静态文件(static file)。由于发送这些文件时不会用到应用程序代码,因此没有必要把它们放到应用程序服务器上,实际上,那样的做法是很低效的。

       为此,App Engine另外提供了一组服务器专门用来发送静态文件。为了处理对静态资源的请求,这些服务器专门对内部架构和网络技术进行了优化。对客户端而言,静态文件跟应用程序所提供的其他资源没什么两样。

       你可以在上传应用程序代码的时候上传静态文件。在静态文件的处理方式上,你可以进行许多方面的配置,比如内容类型、静态文件的URL等;此外,为了降低流量并提高页面呈现速度,还可以指定浏览器对这些文件副本的缓存时间。

By 老猫 | - 11:46 上午 - Posted in Google

       
       App Engine会对Web请求作出响应。当客户端(一般就是用户的Web浏览器)通过一个HTTP请求(比如获取某个指定URL的网页)联系应用程序时,Web请求就开始了。当App Engine接收到请求时,会根据其地址中的域名确定具体的应用程序,这个域名可以是一个.a p p s p o t.c o m子域名(任何应用程序都可以免费使用),也可以是你自己注册并设置到Apps的自定义域名的某个子域名。App Engine会从许多可用服务器中选出一个来处理该请求,选择的依据是看哪个服务器最可能作出快速响应。然后,它将使用该HTTP请求中的内容去调用应用程序,并接收来自应用程序的响应数据,跟着再将响应返回给客户端。

       从应用程序的角度来看,运行时环境在请求处理器(request handler)启动时出现,并在其结束时消失。App Engine提供了至少两种用于持久化请求之间存储数据的方式(稍后再讨论),不过它们都不是在运行时环境内部实现的。由于不会在运行时环境内部保留请求与请求之间的状态(其实本来就不想保留),因此App Engine可以将流量分布到多个服务器上去,这样它就可以同等对待每一个请求了,而无须关心到底一次处理了多大的流量。

       从传统意义上来讲,应用程序代码是不能访问其所在的服务器的。虽然应用程序能够通过文件系统读取其自己的文件,不过却不能写文件,而且也不能读取属于其他应用程序的文件。虽然应用程序可以通过App Engine看到环境变量集,不过对这些变量所作出的修改操作不能在请求与请求之间持久化。应用程序不能访问服务器硬件中的网络设备, 但是可以通过相关服务来完成网络操作。
Read The Full Story…