李谭伟的个人博客

godaddy抢注域名流程

李谭伟 — Sat, 14 Jan 2012 22:31:22 +0800

前天我在GoDaddy提交了一个域名抢注，具体域名我就不透露了，这里主要讨论一下最新的GoDaddy域名抢注提交过程。我的英语不太好，不过看看GoDaddy.com上的问题不大，所以我是边操作边载图的，应该说会写得很详细，让从来没有接触过的人也能看懂操作。

先简单介绍一下国内外的域名抢注商。国外三大最厉害最有名的抢注商是www.pool.com、www.namejet.com和www.snapname.com。有价值的基本被他们消灭，当然价也格不低，最低的起步价也要59美元，而且都要信用卡注册支付。接下来就是比较实惠的两家godaddy.com和name.com，价格都是20美元左右，虽然比不上上面三大抢注商，但传说经常也会有意外之喜。如果不是特别重要特别在乎的域名，我推荐用Godaddy。再说说国内的，主要是金米网（jinmi.com）和拍米网（paimi.com）。如果你在国内抢注商抢注，成功率一般低于国外的。

下面详细介绍一下GoDaddy抢注域名的方法。

一、注册GoDaddy。这一步不多介绍了，就像平常在网站注册会员一样，应该没什么问题。

二、抢注域名。注册后登陆用户，然后点主菜单“Domains”下面的“Domain Backordering”，

看到左边的“Domain Backorders $20.99 /each”，Select Quantity即选择数量，我就只抢注一个域名，所以写上1，Backorder type是两种：Public Registration和 Private Registration。前者是会公开你的域名抢注信息，后者是帮你保密的，当然后者是要加钱的。

然后点“ADD TO CART”，接下来有两个页面都是Godaddy向你推销的另外的产品，我们只是要抢注域名，所以你只要点两次“No Thanks”就OK了。

这里看到右边“Order Summary”，下面可以输入Godaddy的优惠码，这里我提供两个吧！gdbbe994优惠30%，前天亲测可用！gdz183q这个是早上刚收到的，优惠27%，大家自己试吧。看到图片没有？原本20.99美元，现在只要14.69美元，乘以6.3折合人民币93块多，这其中已经包含了一年的域名注册费，很便宜吧！

接下来的就是付钱了。付款方式有很多，Godaddy支持支付宝，我当然选它了，国产的嘛！简单方便呵呵～

点“PLACE ORDER NOW”就跳到支付宝的页面了，接下来的不用我多说了吧？太熟悉不过了。

付好之后，回过来，回到Domain Management。

点击“Buy/Sell”下面的“Backorders and Monitoring”:

点击右侧的“Add Backorders”，然后

下面填写关于你抢注域名的一些信息：

OK，到这里就结束了。

看到“Status”一栏为“Public Backorder Active”就说明已经成功提交了，接下来就是等待，看最后是否能成功抢注到我们所需的域名。

或许这些文章您也喜欢：

删除域名抢注实战 (12)

删除域名抢注实战(12)

5款备受关注的开源 NoSQL 数据库介绍

李谭伟 — Fri, 13 Jan 2012 11:04:21 +0800

随着社会化网站的兴起，传统的关系数据库在应付这类网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL(NoSQL = Not Only SQL )，意即反SQL运动，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于目前铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。

以下是我关注得相对比较多的nosql数据库，希望可以给从事数据库和运维的朋友们带来一些帮助。

1. 集中式缓存系统 memcached

memcached是一套分布式的快取系统，当初是Danga Interactive为了LiveJournal所发展的，但目前被许多软件（如MediaWiki）所使用。这是一套开放源代码软件，以BSD license授权释出。

memcached缺乏认证以及安全管制，这代表应该将memcached服务器放置在防火墙后。
memcached的API使用三十二位元的循环冗余校验（CRC-32）计算键值后，将资料分散在不同的机器上。当表格满了以后，接下来新增的资料会以LRU机制替换掉。由于memcached通常只是当作快取系统使用，所以使用memcached的应用程式在写回较慢的系统时（像是后端的数据库）需要额外的程式码更新memcached内的资料。
memcached具有多种语言的客户端开发包，包括：Perl/PHP/JAVA/C/Python/Ruby/C#/MySQL/

2. 分布式K/V存储方案 Cassandra

Apache Cassandra是一套开源分布式Key-Value存储系统。它最初由Facebook开发，用于储存特别大的数据。Facebook目前在使用此系统。
主要特性：
分布式
基于column的结构化
高伸展性

3. 开源NoSQL系统 Membase

Membase 是 NoSQL 家族的一个新的重量级的成员。

Membase是开源项目，源代码采用了Apache2.0的使用许可。该项目托管在GitHub.Source tarballs上，目前可以下载beta版本的Linux二进制包。该产品主要是由North Scale的memcached核心团队成员开发完成，其中还包括Zynga和NHN这两个主要贡献者的工程师，这两个组织都是很大的在线游戏和社区网络空间的供应商。

Membase容易安装、操作，可以从单节点方便的扩展到集群，而且为memcached（有线协议的兼容性）实现了即插即用功能，在应用方面为开发者和经营者提供了一个比较低的门槛。做为缓存解决方案，Memcached已经在不同类型的领域（特别是大容量的Web应用）有了广泛的使用，其中 Memcached的部分基础代码被直接应用到了Membase服务器的前端。

4. 超高性能 key-value 数据库 Redis

Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类keyvalue存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了Python，Ruby，Erlang，PHP客户端，使用很方便。

性能测试结果：
SET操作每秒钟 110000 次，GET操作每秒钟 81000 次，服务器配置如下：
Linux 2.6, Xeon X3320 2.5Ghz.
stackoverflow 网站使用 Redis 做为缓存服务器。

5. 面向文档的数据库 CouchDB

Apache CouchDB 是一个面向文档的数据库管理系统。它提供以 JSON 作为数据格式的 REST 接口来对其进行操作，并可以通过视图来操纵文档的组织和呈现。 CouchDB 是 Apache 基金会的顶级开源项目。

CouchDB落实到最底层的数据结构就是两类B+Tree 。

或许这些文章您也喜欢：

百万级访问网站前期的技术准备（中） (9)

百万级访问网站前期的技术准备（中）(9)

12306网上订火车票攻略：实用脚本实现半自动化

李谭伟 — Tue, 10 Jan 2012 10:38:08 +0800

12306.cn 可以网上购火车票了，但由于我镇的『国情』决定了春节时分它竟然比电话购票都不靠谱。但是，毕竟它是最方便的，所以在意识到其实这不仅是个技术活、更是一个体力活之后，终于决定博彩众家之长搞这么一个一条龙的轮子……现在放出来也许有点晚了，但是对于赶年前一两天以及回程票的同学还是有点用的，所以还是放出来吧

半原创，借鉴了不少别人的思想和思路，但代码基本上都是重写的。目前实现的功能有：

记录登录的用户名和密码，在打开登录页面后自动填写；

运行需求

您必须准备以下条件之一：

Firefox，最好比较新的版本（6+），并安装 Scriptish 扩展；
Chrome（4以上版本）

注意，如果您以前有安装过类似的脚本（如自动登录、自动查询等等），请先移除它们。

Firefox下的功能介绍

在登录页面，本脚本会加入密码记录功能和自动登录功能：

记录密码后，下次登录直接就会填入，并自动定位到验证码段。需要提醒的是，密码是明文记录在Cookies中的，所以如果不是你自己的电脑，建议不要记录。

填完后，你可以用传统方式登录。不过现在不是有了自动登录了吗？点击自动登录呗。在没有成功登录的情况下，系统会自动反复重试，重试的时候桌面右下角会有弹窗提示正在进行的操作：

登录成功后，也会有提示，并且页面会自动进入查询页面：

进入查询页面后，在查询下面有加一条选项，选项意思简单明了，不需要解释的吧

当没有查询到符合要求的车次时，会自动重试。由于系统按钮有5秒钟的限制，所以不允许设置在6秒内重试。

（上图木有查到，是因为过滤了“仅卧铺”）。

如果查到了，会停止刷新，高亮行，并在桌面右下角弹出提示：

Chrome下的功能介绍

在Chrome下的功能基本上是一致的，以下不再做详细描述。

不过Chrome的桌面提示是需要授权的，所以有提示的界面上会有按钮提示：

“请点击以启用通告”，点击后在浏览器上方点击“允许”，否则通告无法使用。

登录过程的界面提示，内容基本一致，不过就是换个样子：

登录成功后会一样进入：

呃，查询界面一样经典呐：

查询成功时会有声音提示（可以选择开启或关闭），并弹出提示：

小贴士请注意喔：

Chrome下的桌面提示仅在浏览器正常模式下才起效（也就是说你要是把浏览器最小化了，提示看不到的），不知道是不是Chrome都是这样，但我测试的结果是这样……所以一定要注意声音啊
Firefox下的桌面提示是可以在桌面上弹出来的。我这里用的是Scriptish，没有测试GreaseMonkey的兼容性……木有时间啊
很多人说又要用IE去付款，还不是要反复登录的体力活吗？建议用银联在线支付，关联银行卡后用手机即可在Firefox或Chrome下直接付款（值得注意的是，Firefox6以上的版本它的安全控件暂时不支持，可以用我制作的安全控件补丁，点击下载）。

感谢前人：

12306 Auto Query ，Jingqin Lynn
12306 Booking Assistant，Hidden
12306 Auto Login，Kevintop

下载

请选择您需要的版本（根据您的浏览器选择）：

Chrome：http://www.u-tide.com/fish/Service.asmx/Download/44/45/12306_ticket_helper_for_chrome.user.js
Firefox：http://www.u-tide.com/fish/Service.asmx/Download/44/46/12306_ticket_helper_for_firefox.user.js

点击链接后在提示中点击安装或继续即可。

自动登录，遇到人过多或繁忙的时候自动重试，直到登录成功（有点儿抢线的味道）；
自动记录查询信息，一次查询线路后下次再查询自动填入；
自动刷新查询，当没有需要的车次时，自动重新刷新；
支持 Firefox + Scriptish 或 Chrome。
在 Chrome下，查票和登录有右下角提示和声音提示；Firefox下暂不支持声音提示，但有桌面弹窗提示。

随机推荐阅读：

博客搬家到新浪SAE服务器，暂时使用二级域名访问

李谭伟 — Thu, 25 Aug 2011 22:26:47 +0800

博客搬家啦！！

搬到了新浪云计算平台SAE的服务器里面，访问速度有了非常大的改善，同时也会非常的稳定了哦！

由于我的顶级域名没有通过万恶的备案，现在还不能使用顶级国际域名访问，所以大家看到的是sinaapp的二级域名。目前备案已经在办理中，预计一周后就可以使用。备案成功后访问就恢复正常了。

给您带来不便，请您谅解！

李谭伟

2011 08 25

随机推荐阅读：

与技术无关：下棋感悟

李谭伟 — Fri, 15 Apr 2011 09:11:36 +0800

闲暇周末，独自在家，在网上下了几局棋，颇有感悟，想写下来和朋友们一起分享共勉！

先说说棋局：我自认为布局是非常不错的，但是进入中局的时候，一步一步的被攻破，被吃去很多棋子。一直到接近结束的时候知道输已经是定局了，最后均以失败告终！

人说人情如纸张张薄，事事如棋局局新。真是这个道理，至少今天说明了“事事如棋局局新”的道理。这几局棋让我想到了很多事情，我自己遇到的，朋友遇到的。就说说人对自己的打算吧，看看和这棋局是多么雷同！

很多人从小都被人夸很聪明，很漂亮，是个人才，同时从小的确也学习很好，甚至也考上了好的大学。这可以算是布局。

但是大学毕业面对和很多的现实，有就业的压力，人和人的竞争，开始接触社会，面对欺骗、尔虞我诈、等等，自己从小的梦想，从小的抱负，大家夸赞的好儿童、人才在现实的冲击下，慢慢的失去了斗志、也失去了很多优势（或者说别人更有优势！）。这可以算是进入中局。

很多人在中局的洗刷下，败下阵来。当然也有感觉凯旋而归的。

有的人通过面对的这些情况知道了自己在哪些方面不足，虽然败了，但是却收获不少，为了东山再起，在此收拾河山，继续前行！但是有的人却一蹶不振，有的对整个社会充满了怨恨、埋怨我们国家政策不好、埋怨改革开放太乱、有的还埋怨中美货币差导致了物价上涨，不能生活等等云云。。。这就是漫长的中局中很多表现对吧！

结果一阵厮杀，棋确实已成定局了。很多人知道胜券在握了，有的人知道已经无力回天了.慢慢真的“已知天命”！这是向残局过度的阶段吧！

棋局进入到了尾声，有的自动放弃的（认输），有知道已经不可能胜利但是也不可能失败，然后将就过日子的（和棋）。也有经过不断的努力还在继续奋斗，还不知道天命的！其后者一直奋斗，到最后棋局结束.这是残局吧！

象棋真的好像上天赐予我一个检验我心理状态的仪器一样，在不同的时间，不同的情况，我下一局棋。让我悟出很多人生道理。棋子只有这么几颗，谁的棋子从一开始都是一样多的。是好是坏，就看自己怎么把握。有一着不慎满盘皆输的，也有力挽狂澜杀出一条血路最后反败为胜的！一切的一切，需要自己不断总结、学习、思考。

人生如棋、事事如棋，布局并不重要，重要是怎么好好把握。中局失利并不重要，重要的是怎么痛定思痛、组织兵马从头再来然后力挽狂澜。只要中局做好了，残局输了又怎么样？人生是何等精彩！棋有输赢、但是人生却没有，只有是否精彩。

谨此短文与兄弟姐妹们共勉！愿我们都走一盘精彩的棋！

随机推荐阅读：

百万级访问网站前期的技术准备（中）

李谭伟 — Fri, 07 Jan 2011 17:28:57 +0800

七、数据库

几乎所有操作最后都要落到数据库身上，它又最难扩展（存储也挺难）。对于mysql，什么样的表用myisam，什么样的表用innodb，在开发之前要确定。复制策略、分片策略，也要确定。表引擎方面，一般，更新不多、不需要事务的表可以用myisam，需要行锁定、事务支持的，用innodb。myisam的锁表不一定是性能低下的根源，innodb也不一定全是行锁，具体细节要多看相关的文档，熟悉了引擎特性才能用的更好。现代WEB应用越来越复杂了，我们设计表结构时常常设计很多冗余，虽然不符合传统范式，但为了速度考虑还是值得的，要求高的情况下甚至要杜绝联合查询。编程时得多注意数据一致性。

复制策略方面，多主多从结构也最好一开始就设计好，代码直接按照多主多从来编写，用一些小技巧来避免复制延时问题，并且还要解决多数据库数据是否一致，可以自己写或者找现成的运维工具。

分片策略。总会有那么几个表数据量超大，这时分片必不可免。分片有很多策略，从简单的分区到根据热度自动调整，依照具体业务选择一个适合自己的。避免自增ID作为主键，不利于分片。

用存储过程是比较难扩展的，这种情形多发生于传统C/S，特别是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务的模式，是机海作战。方便水平扩展比那点预分析时间和网络传输流量要重要的多的多。

NoSQL。这只是一个概念。实际应用中，网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等，这都不是传统关系数据库所擅长的，于是就产生了很多非关系型数据库，比如Redis/TC&TT/MongoDB/Memcachedb等，在测试中，这些几乎都达到了每秒至少一万次的写操作，内存型的甚至5万以上。例如MongoDB，几句配置就可以组建一个复制+自动分片+failover的环境，文档化的存储也简化了传统设计库结构再开发的模式。很多业务是可以用这类数据库来替代mysql的。

八、缓存。

数据库很脆弱，一定要有缓存在前面挡着，其实我们优化速度，几乎就是优化缓存，能用缓存的地方，就不要再跑到后端数据库那折腾。缓存有持久化缓存、内存缓存，生成静态页面是最容易理解的持久化缓存了，还有很多比如varnish的分块缓存、前面提到的memcachedb等，内存缓存，memcached首当其冲。缓存更新可用被动更新和主动更新。被动更新的好处是设计简单，缓存空了就自动去数据库取数据再把缓存填上，但容易引发雪崩效应，一旦缓存大面积失效，数据库的压力直线上升很可能挂掉。主动缓存可避免这点但是可能引发程序取不到数据的问题。这两者之间如何配合，程序设计要多动脑筋。

九、队列。

用户一个操作很可能引发一系列资源和功能的调动，这些调动如果同时发生，压力无法控制，用户体验也不好，可以把这样一些操作放入队列，由另几个模块去异步执行，例如发送邮件，发送手机短信。开源队列服务器很多，性能要求不高用数据库当做队列也可以，只要保证程序读写队列的接口不变，底层队列服务可随时更换就可以，类似Zend Framework里的Zend_Queue类，java.util.Queue接口等。

十、文件存储。

除了结构化数据，我们经常要存放其他的数据，像图片之类的。这类数据数量繁多、访问量大。典型的就是图片，从用户头像到用户上传的照片，还要生成不同的缩略图尺寸。存储的分布几乎跟数据库扩展一样艰难。不使用专业存储的情况下，基本都是靠自己的NAS。这就涉及到结构。拿图片存储举例，图片是非常容易产生热点的，有些图片上传后就不再有人看，有些可能每天被访问数十万次，而且大量小文件的异步备份也很耗费时间。

为了将来图片走cdn做准备，一开始最好就将图片的域名分开，且不用主域名。很多网站都将cookie设置到了.domain.ltd，如果图片也在这个域名下，很可能因为cookie而造成缓存失效，并且占多余流量，还可能因为浏览器并发线程限制造成访问缓慢。

如果用普通的文件系统存储图片，有一个简单的方法。计算文件的hash值，比如md5，以结果第一位作为第一级目录，这样第一级有16个目录。从0到F，可以把这个字母作为域名，0.yourimg.com到f.yourimg.com（客户端dns压力会增大），还可以扩展到最多16个NAS集群上。第二级可用年月例如，201011，第三级用日，第四级可选，根据上传量，比如am/pm，甚至小时。最终的目录结构可能会是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync备份时可以用脚本只同步某年某日某时的文件，避免计算大量文件带来的开销。当然最好是能用专门的分布式文件系统或更专业点的存储解决方案。

下面，我们要谈谈代码了。

来源：一路凯歌（http://zhiyi.us/）
原文地址：http://zhiyi.us/internet/thinking-twice-before-building-your-site-one.html

或许这些文章您也喜欢：

5款备受关注的开源 NoSQL 数据库介绍 (0)

5款备受关注的开源 NoSQL 数据库介绍(0)

五个免费开源的数据挖掘软件

李谭伟 — Sat, 25 Dec 2010 17:50:19 +0800

最近一段时间，我们网站升级。很多数据结构和URL结构变化很多，让很多数据都失去了监控。很幸运的是看到了这篇文章，提供了5个免费开源的数据挖掘软件，分享给大家。另外Google analytics 也是非常棒的数据挖掘和分析工具，建议大家好好研究这些工具。

Orange

Orange 是一个基于组件的数据挖掘和机器学习软件套装，它的功能即友好，又很强大，快速而又多功能的可视化编程前端，以便浏览数据分析和可视化，基绑定了Python以进行脚本开发。它包含了完整的一系列的组件以进行数据预处理，并提供了数据帐目，过渡，建模，模式评估和勘探的功能。其由C++ 和 Python开发，它的图形库是由跨平台的Qt框架开发。

RapidMiner

RapidMiner, 以前叫 YALE (Yet Another Learning Environment), 其是一个给机器学习和数据挖掘和分析的试验环境，同时用于研究了真实世界数据挖掘。它提供的实验由大量的算子组成，而这些算子由详细的XML 文件记录，并被RapidMiner图形化的用户接口表现出来。RapidMiner为主要的机器学习过程提供了超过500算子，并且，其结合了学习方案和Weka学习环境的属性评估器。它是一个独立的工具可以用来做数据分析，同样也是一个数据挖掘引擎可以用来集成到你的产品中。

Weka

由Java开发的 Weka (Waikato Environment for Knowledge Analysis) 是一个知名机器学机软件，其支持几种经典的数据挖掘任务，显著的数据预处理，集群，分类，回归，虚拟化，以及功能选择。其技术基于假设数据是以一种单个文件或关联的，在那里，每个数据点都被许多属性标注。 Weka 使用Java的数据库链接能力可以访问SQL数据库，并可以处理一个数据库的查询结果。它主要的用户接品是Explorer，也同样支持相同功能的命令行，或是一种基于组件的知识流接口。

JHepWork

为科学家，工程师和学生所设计的 jHepWork 是一个免费的开源数据分析框架，其主要是用开源库来创建一个数据分析环境，并提供了丰富的用户接口，以此来和那些收费的的软件竞争。它主要是为了科学计算用的二维和三维的制图，并包含了用Java实现的数学科学库，随机数，和其它的数据挖掘算法。 jHepWork 是基于一个高级的编程语言 Jython，当然，Java代码同样可以用来调用 jHepWork 的数学和图形库。

KNIME

KNIME (Konstanz Information Miner) 是一个用户友好，智能的，并有丰演的开源的数据集成，数据处理，数据分析和数据勘探平台。它给了用户有能力以可视化的方式创建数据流或数据通道，可选择性地运行一些或全部的分析步骤，并以后面研究结果，模型以及可交互的视图。 KNIME 由Java写成，其基于 Eclipse 并通过插件的方式来提供更多的功能。通过以插件的文件，用户可以为文件，图片，和时间序列加入处理模块，并可以集成到其它各种各样的开源项目中，比如：R语言，Weka， Chemistry Development Kit, 和 LibSVM.

源文：http://www.junauza.com/2010/11/free-data-mining-software.html（墙）

或许这些文章您也喜欢：

[转]基于网站日志数据挖掘的用户访问行为模式可视化研究 (0)

[转]基于网站日志数据挖掘的用户访问行为模式可视化研究(0)

网站初期需要注意的几点技术问题（上）

李谭伟 — Mon, 06 Dec 2010 13:05:38 +0800

对互联网有了解的人都有自己的想法，有人就把想法付诸实现，做个网站然后开始运营。其实从纯网站技术上来说，因为开源模式的发展，现在建一个小网站已经很简单也很便宜。当访问量到达一定数量级的时候成本就开始飙升了，问题也开始显现了。因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而易见的，而还有相当大的一部分成本是因为代码重构、架构重构，甚至底层开发语言更换引起的，最惨的就是数据丢失，辛辛苦苦好几年，一夜回到创业前。

减少成本就是增加利润。很多事情，我们在一开始就可以避免，先打好基础，往后可以省很多精力，少操很多心。

假设你是一个参与创业的技术人员，当前一穷二白，什么都要自己做，自己出钱，初期几十万的资金，做一个应用不是特别复杂的网站，那么就要注意以下几点：

一、开发语言

一般来说，技术人员（程序员）创业都是根据自己技术背景选择自己最熟悉的语言，不过考虑到不可能永远是您一个人写程序，这点还得仔细想想。无论用什么语言，最终代码质量是看管理，所以我们还是从纯语言层面来说实际一点。现在流行的java、php、.net、python、ruby都有自己的优劣，python和ruby，现在人员还是相对难招一些，性能优化也会费些力气，.net平台买不起windows server。java、php用的还是最多。对于初期，应用几乎都是靠前端支撑的网站来说，php的优势稍大一些，入门简单、设计模式简单、写起来快、性能足够等，不过不注重设计模式也是它的劣势，容易变得松散，隐藏bug稍多、难以维护。java的优势在于整套管理流程已经有很多成熟工具来辅助，强类型也能避免一些弱智BUG，大多数JAVA程序员比较注重设计模式，别管实不实际，代码格式看起来还是不错的。这也是个劣势，初学者可能太注重模式而很难解决实际需求。

前端不只是html、css这类。整个负责跟用户交互的部分都是前端，包括处理程序。这类程序还是建议用php，主要原因就是开发迅速、从业人员广泛。至于后端例如行为分析、银行接口、异步消息处理等，随便用什么程序，那个只能是根据不同业务需求来选择不同语言了。

二、代码版本管理

如果开发人员之间的网络速度差不多，就SVN；比较分散例如跨国，就hg。大多数人还是svn的.

假设选了svn，那么有几点考虑。一是采用什么树结构。初期可能只有一条主干，往后就需要建立分支，例如一条开发分支，一条上线分支，再往后，可能要每个小组一个分支。建议一开始人少时选择两条分支，开发和线上，每个功能本地测试无误后提交到开发分支，最后统一测试，可以上线时合并到上线分支。如果喜欢把svn当做移动硬盘用，写一点就commit一次也无所谓，就是合并的时候头大一些，这些人可以自己建个分支甚至建立个本地代码仓库，随便往自己的分支提交，测试完毕后再提交到开发分支上。

部署，可以手工部署也可以自动部署。手工部署相对简单，一般是直接在服务器上svn update，或者找个新目录svn checkout，再把web root给ln -s过去。应用越复杂，部署越复杂，没有什么统一标准，只要别再用ftp上传那种形式就好，一是上传时文件引用不一致错误率增加，二是很容易出现开发人员的版本跟线上版本不一致，导致本来想改个错字结果变成回滚的杯具。如果有多台服务器还是建议自动部署，更换代码的机器从当前服务池中临时撤出，更新完毕后再重新加入。

不管项目多小，养成使用版本管理的好习惯，最起码还可以当做你的备份，我的http://zhiyi.us 虽然就是一个wordpress，可还是svn了，只改动一两句css那也是劳动成果。

三、服务器硬件

别羡慕大客户和有钱人，看看机房散户区，一台服务器孤独的支撑的网站数不清。如果资金稍微充足，建议至少三台的标准配置，分别用作web处理、数据库、备份。web服务器至少要8G内存，双sata raid1，如果经济稍微宽松，或静态文件或图片多，则15k sas raid1+0。数据库至少16G内存，15k sas raid 1+0。备份服务器最好跟数据库服务器同等配置。硬件可以自己买品牌的底板，也就是机箱配主板和硬盘盒，CPU内存硬盘都自己配，也可以上整套品牌，也可以兼容机。三台机器，市场行情6、7万也就配齐了。

web服务器可以既跑程序又当内存缓存，数据库服务器则只跑主数据库（假如是MySQL的话），备份服务器干的活就相对多一些，web配置、缓存配置、数据库配置都要跟前两台一致，这样WEB和数据库任意一台出问题，把备份服务器换个ip就切换上去了。备份策略，可以drbd，可以rsync，或者其他的很多很多的开源备份方案可选择。rsync最简单，放cron里自己跑就行。备份和切换，建议多做测试，选最安全最适合业务的，并且尽可能异地备份。

四、机房

三种机房尽量不要选：联通访问特别慢的电信机房、电信访问特别慢的联通机房、电信联通访问特别慢的移动或铁通机房。那网通机房呢？亲，网通联通N久以前合并改叫联通了。多多寻找，实地参观，多多测试，多方打探，北京、上海、广州等各个主节点城市，还是有很多优质机房的，找个网络质量好，管理严格的机房，特别是管理要严格，千万别网站无法访问了，打个电话过去才知道别人维护时把你网线碰掉了，这比DOS都头疼。自己扯了几根光纤就称为机房的，看您抗风险程度和心理素质了。机房可以说是非常重要，直接关系到网站访问速度，网站访问速度直接关系到用户体验，我可以翻墙看风景，但买个网游vpn才能打开你这个还不怎么知名的网站就有难度了。或许您网站的ajax很出色，可是document怎么也不ready，一些代码永远绝缘于用户。

五、架构

初期架构一般比较简单，web负载均衡+数据库主从+缓存+分布式存储+队列。大方向上也确实就这几样东西，细节上也无数文章都重复过了，按照将来会有N多WEB，N多主从关系，N多缓存，N多xxx设计就行，基本方案都是现成的，只是您比其他人厉害之处就在于设计上考虑到缓存失效时的雪崩效应、主从同步的数据一致性和时间差、队列的稳定性和失败后的重试策略、文件存储的效率和备份方式等等意外情况。缓存总有一天会失效，数据库复制总有一天会断掉，队列总有一天会写不进去，电源总有一天会烧坏。根据墨菲定律，如果不考虑这些，网站早晚会成为茶几。

六、服务器软件

Linux、nginx、php、mysql，几乎是标配，我们除了看名字，还得选版本。Linux发行版众多，只要没特殊要求，就选个用的人最多的，社区最活跃的，配置最方便的，软件包最全最新的，例如debian、ubuntu。至于RHEL之类的嘛，你用只能在RHEL上才能运行的软件么？剩下的nginx、php、mysql、activemq、其他的等等，除非你改过这些软件或你的程序真的不兼容新版本，否则尽量版本越新越好，版本新，意味着新特性增多、BUG减少、性能增加。总有些道听途说的人跟你说老的版本稳定。所谓稳定，是相对于特殊业务来说的，而就一个php写的网站，大多数人都没改过任何服务器软件源代码，绝大多数情况是能平稳的升级到新版本的。类似于jdk5到jdk6，python2到python3这类变动比较大的升级还是比较少见的。看看ChangeLog，看看升级说明，结合自己情况评估一下，越早升级越好，别人家都用php6写程序了这边还php4的逛游呢。优秀的开源程序升级还是很负责任的，看好文档，别怕。

以上这六点准备完毕，现在我们有了运行环境，有了基本架构骨架，有了备份和切换方案，应该开始着手设计开发方面的事情了。开发方面的事情无数，下一篇会先说一些重点。

来源：一路凯歌（http://zhiyi.us/）
原文地址：http://zhiyi.us/internet/thinking-twice-before-building-your-site-one.html

或许这些文章您也喜欢：

亲爱的用户，您真的满意吗？

李谭伟 — Fri, 22 Oct 2010 09:59:18 +0800

从上世纪80年代开始，多样化的产品和服务开始在世界范围内发展起来，替代了早期的以大量的普通日常用品为主的经济和市场环境。在90年代以后电子以及互联网行业开始高速发展起来，各种高科技产品日新月异，在人们的日常生活中无处不在。对于这些巨大的变化，我们需要更加科学的方法对新经济环境下行业、公司以及产品和服务的实际效益进行评测，而不只是考虑传统的大规模生产指标。

所以，在90年代科学家们开始针对在新的经济环境中的不同行业、不同领域、不同产品和服务进行更科学有效的评估，开始重视消费者或用户的反馈，因为无论是企业、行业、部门或者是产品，都是有其直接面对的“顾客”的，而顾客满意度（Customer Satisfaction）成为这些内容的无形资产，可以直接或间接反映出实际效益，所以顾客满意度指数（CSI, Customer Satisfaction Index）也成为一个新的衡量标准。下面简单介绍一下CSI模型：

CSI模型：
CSI模型指的并不是某一个具体的实际的满意度模型，而是一个衡量满意度的一种方法论，是一系列评估顾客满意度的模型集合。对于反映顾客满意度在总体概念上的集合，可以称为“宏观模型”（Macro-Model），比如说价值、感知质量、顾客期望、顾客抱怨行为、品牌/产品印象、顾客忠诚度等等，这些概念都可以是衡量顾客总体满意度的“宏观”指标，在模型中叫做“潜在变量”（LV, Latent Variable）。下图是一个简单的CSI模型举例，单向箭头给出了各概念的关系。

(来源：C. O’Loughlin and G. Coenders, 2002)
针对不同的应用，不同的研究给出了各样的模型结构。比方说在1996年，Woodruff和Gardial提出在产品选择和满意度的关系中把价值的概念作为驱动力，且作为简单的心理反应，形成一种价值链。根据这样一个目的，他们建立了关于顾客价值链到顾客满意度的层级模型。

市场研究的文献中指出对于不同的宏观概念，需要更加细节的因子（或元素）去支撑，因为宏观概念是比较模糊而感性的定义，通常是不能直接计算得出的。所以，每一个宏观概念是可以分解成不同的因子的，称为“微观模型”（Micro-Model），比如说产品的感知质量可以由可靠性、购买后的总体评价、功能需求满足情况等进行衡量，在模型中也叫做“测量变量”（MV, Manifest Variable）。一个简单的微观模型可以表示如下：

（来源：C. O’Loughlin and G. Coenders, 2002）

各国（区域）的顾客满意度指数模型：

从上世纪90年代开始，研究员开始根据对各国（区域）的实际情况收集数据，进行满意度模型的研究和建立。其中比较有名的是瑞典顾客满意度指标（SCSB, Swedish Customer Satisfaction Barometer）、美国顾客满意度指数（ACSI, American Satisfaction Index）和欧洲顾客满意度指数（ECSI, European Customer Satisfaction Index）。这里以ACSI作为例子介绍。

ACSI模型建立的前提包括：1. 满意度是来源于顾客的评价，不能被直接观测，所以是作为潜在变量用多重指标（测量变量）进行衡量的；2. ACSI不仅考虑实际消费经验，更注重对未来前景的预测。具体宏观结构模型如下图：

（来源：Fornell, et al, 1996）

由于ACSI以及各宏观潜变量是不能直接测量，需要根据多个可测量的变量进行计算的，以下表格说明了模型中的测量变量。（来源：Fornell, et al, 1996）

模型的建立：

ACSI模型的建立是基于“结构方程建模”（SEM, Structural Equation Modeling）的方法，建立一个关于各个不同的测量变量和潜在变量的结构关系方程，关于SEM方法，可以参考【5】。也就是说，通过各可测量的因素来得到潜在变量，进而计算出总体顾客满意度。不同的模型是根据不同的实际数据建立起来的。量化的数据是通过调查问卷获取的。模型的结构和关系的确定也是来源于实际数据，通过一些数学算法拟合和估计得出的（如偏最小二乘法PLS等）。如下图所示，模型确定之前，我们先是假设所有潜在变量和测量变量都存在着关系，然后通过实际数据来挑选出有效的变量进行建模的。此外，不同的测量变量是对应不同的问卷的，起初我们是并不确定有效的问卷数量以及内容，常用的确定方法是通过相关性分析，找出与潜在变量最为相关的问卷数据，作为测量变量的来源。这种分析方法也称为验证性因子分析（CFA, Confirmatory Factor Analysis），通过不断的验证模型与数据的相配度来逐步确定模型。详细内容可参考【5】。

（参考：Ref.【2,3】）

模型的特性和效果分析：

科学的满意度模型可以带来好的效果。同样是拿ACSI模型作为例子。ACSI模型中为了对经济产出的测量变得更加精确和全面，并能预测经济利润，为经济政策提供有用信息，成为经济健康程度的指示剂，就必须满足一些标准：精确性、有效性、可靠性、预测性、覆盖性、简易性、诊断性和可比较性。

这些内容在产品满意度评估中也是可以借鉴的，但需要对具体产品特性和所属行业进行改良。所以，在建模的整个过程中，必须在潜在变量/测量变量选取、数据收集、数据处理、算法应用、结论分析和解决方案萃取等方面进行全面而细致的思考，并使得模型在长期的横向（不同产品间、不同行业间）和纵向（不同的时间）积累中得以持续的优化，使得结果更具可比较性。所以，在建模的过程中，我们对每一个环节都需要具体的进行分析调查。

问卷设计：

这里特别提一下问卷设计。问卷是测量变量数据的来源，数据直接决定了模型的有效度，所以在前期定性的时候，问卷的设计就显得十分的重要。应该在模型建立的大结构下，进行必要调整，根据产品本身的具体情况进行设计，而避免使用过于通用的范例。问卷的长短也是由测量变量的数量决定的。对于模型的测量变量，选取尽量精准而相关的问题就已经足够了，因为即使是过多的不十分相关的问题，也可能在分析中被去除掉。这就要求在设计问卷的过程中，根据研究员自身的经验以及实际的情况，来进行筛选。如果问卷中问题冗长，不仅未必能提高分析结果的精确度，也可能造成顾客在回答问题过程中放弃率的增加，以及信度的降低。

另外，在讨论满意度指标的时候，需要提出几个注意点：

1. 根据Oliver在1997年定义：“满意度是消费者（或者用户）的满意情况的反映。它是一个产品或服务提供给消费者在消费相关的满足感上的使人愉悦的级别，包括低于满足感或高于满足感……”。在对产品的用户满意度指标建模的时候，我们的目标人群应该是用户，而不是顾客。因为用户是产品或服务的使用者，而顾客是购买者，顾客未必是产品或服务的直接使用者。所以，在选取目标人群的时候，应该有意识的剔除不合适的“顾客”，这样才能提高数据的信息与噪声比，提高数据的可靠性。

2. 满意度通常有着上水平阀值（超出用户心理满意度的水平）和下水平阀值（低于用户心理满意度的水平）。也就是说，当用户获得“太多的好东西”的时候，用户满意度可能会下降，许多用户是注重下水平阀值而忽略了上水平阀值的。

3. 满意度是一种感觉，虽然在建模的时候，通过各种方法可以尽量的让这种感觉变得可以量化，可以衡量，且使得衡量的更加精确，但这始终是一种相对短期的态度，并且可能随着环境和时间改变的，所以产品的满意度需要不断的根据评测结果给出的建议进行提高，且其模型也要不断优化。

Reference：

【1】Fornell, C. (1992), A National　Customer Satisfaction Barometer, the Swedish Experience, Journal of Marketing 56, 6-21.

【2】Fornell, C., Johnson, M.D., Anderson, E.W., Cha, J., and Bryant, B.E. (1996), The American Customer Satisfaction Index, Nature, Purpose and Findings, Journal of Marketing 60, 7-18.

【3】O’Loughlin C., (2002), Application of the European Customer Satisfaction Index to Postal Services Structural Equation Models versus Partial Least Square, Universitat de Dirona, Departament d’Economia.

【4】Woodruff, R.B. and Gardial, S.F., (1996), Know Your Customer: New Approaches to Understanding Customer Value and Satisfaction, Cambridge, Massachusetts: Blackwell.

【5】Ullman, J.B., (2006), Structural Equation Modeling: Review the Basics and Moving Forward, Journal of Personality Assessment, 87(1), 35-50.

【6】Oliver, R., (1997), Satisfaction: A Behavioral Perspective on the Customer, Boston, McGraw-Hill.

(本文出自Tencent CDC Blog，转载时请注明出处)
文章来源：http://cdc.tencent.com/?p=2987

随机推荐阅读：

聊聊线框图——为线框图多留点时间

李谭伟 — Thu, 30 Sep 2010 11:55:10 +0800

注：heidi写这系列的专业文章，并不说明目前heidi做得有多好，相反，每当我发现自己做得不够好时或者遇到问题时，都喜欢反思并总结，可是由于以前养成的不良习惯，导致我最终写出来的东西总是像专业教程，这也导致会有一些小朋友误认为我是专业人士，其实真的不是这样，我写出来未必是专业文章（有时只不过表现如此），我只是觉得这个话题值得探讨，值得分享，也值得自己继续努力而已。所以，也请不要四处转载。
线框图是交互设计师必不可少的产出物，它在交互设计师的工作中扮演了如此重要的角色，以至于交互设计师经常被认为是个画线框图的，但是无论是设计师本人还是项目组成员，对于线框图存在的意义未必有足够的认识。

项目为何需要线框图？
为什么不缩短周期，直接跳转到视觉设计呢？

对于设计师而言，疑问一样存在：

线框图给我们带来什么价值？
在我们想进行线框图培训时，疑问有：
不就是画个草图吗？还需要学习？

如果大家都把线框图理解成“草图”，那么按照正常逻辑，草图的产出一定是比视觉稿更快而不是更慢才对，但是在很多项目里，为何线框图的时间反而花费得更多？

这往往会引起不解，因为在多数人看来，线框图也就是个没有任何视觉加工过的简单简陋粗暴不美观的草稿，加上我一再声称做线框图的工具是10分钟就可以上手搭建线框图的超白痴工具，而线框图本身就完全无需精雕细琢刻意加工，那么，为何会在线框图阶段停留那么久？其他人都在干嘛？时间都花在哪里？

在我自己回顾过去的项目或者看手里的项目时，我也发现，为何过去的线框图阶段都比较长？而目前在做的项目，由于资源靠自己去安排，自己预安排的资源，比如只有3天，实施过程中发现太紧张，远远不够？
再细想一下，发现也许这三天，我用了1天半就搭建了一个满足基本需求的线框图（从商业需求来讲，这是大家能够预计到的主要的页面），但是在1天半后，我开始进行多种方案的探索与创建，然后发现更多分支流程与异常处理页面，之后，我完全没有为线框图的讨论与确认留下充分的时间！

而，线框图如果做出来不是让大家来争论和确认的，而是仅仅做出来给大家过目一下就移交了，基本上，线框图已经失去了原本存在的价值。

时间都花到了哪里？

并非所有的项目都需要线框图，但是如果需要线框图，那么线框图就需要多留一些时间，不要单纯从最终的线框图产出物的“样子”去评估需要多少资源。

用页面的个数去评估工作量，在视觉设计师也许是适用的——建立在产品视觉风格确定的前提下。
（视觉设计师的资源也需要划分成两段，一段用来做探索，确定产品风格，比如主题色，质感，图文比例与用图风格等，这个阶段也有比较大范围的评审与确认，所以时间上反而会比具体的页面视觉设计来得更长），前端工程师也可以用页面个个数与复杂程度去预估需要多少天，但是对于交互设计师，这比较是个难题。只有交互设计师将需求讨论清楚，自己将页面流程图画好，将各种分支情况考虑清楚，脑子里才会逐渐对需要多少个页面形成概念，哪些页面需要更高的单页面交互设计形成概念，而当他完成这一步，交互的大部分工作都已经做完了，剩下的单纯去设计各个页面，占据了线框图阶段的很少的时间。更多的时间是花在什么上？

讨论——评审——讨论——评审——确认

是的，线框图的作用之一是用来吵架的承载物，交互设计师为线框图确认需要召开很多次评审会（视项目不同而不同），直至大家对线框图达成共识，然后在有的公司，还需要对线框图本身进行可用性测试以发掘更多问题。

80%和20%

交互设计师可能会有20%的精力真正花在线框图本身的制作上，而且他也认为这也许是没有什么技术含量的。剩下的80%的精力，用在：

——需求的了解与讨论，“我认为这个标记出现在搜索结果页，也许并不是合理的场景……”“为什么只针对××会员类型开放这个功能？”在商业初始需求确认后，交互设计师与产品经理是配合最紧密的两个角色，他们需要将商业需求一步步细化，落实到具体的页面与功能的实现上。需求越清楚，以后的阶段就会越高效。这个阶段，交互设计师还需要借助site map，页面流程图（page flow），或者故事板等等工具，来帮助自己和项目组了解产品需求。

有时，工作量绝对不想看起来那么少，产品经理需要把做什么和为什么描述清楚，他们会在“做什么”时也会讲一下“如何做”，但是很多产品经理并不或者被要求不要深入太多解决方案细节，但是交互设计师不一样，必须从宏观到细节，将产品的交互逻辑认认真真仔仔细细思考清楚，细枝末节的东西如果不关心，到了项目进行过程中，还一定会被开发工程师追着补充各种流程中的页面。

——创造性的方案探索与尝试，“如果我这里换一种交互方式，会怎么样？”“还有更好的实现办法吗？”“缩短一步操作会怎么样？”“印象中好像曾经有个网站采用了一种更加高效的方法，我想想看？”所有设计师都有精益求精的“特质”，或者“毛病”，我们需要做这种自我激发的头脑风暴。
从设计来看，设计本身就意味着方案的筛选与确认：也许最后设计师在确认会上只给出了一到两种方案，但是大多数设计师在自己的电脑里或者大脑里尝试过很多方案。

设计本身是一种在期望和限制下进行的探索，并且将探索后的成果实施。交互设计师需要不断围绕需求与期望，进行探索并在逐步的限制中，缩小设计范围。他做的是他应该做的，他不应该将过多的问号传递给视觉设计师，视觉设计师本身也需要进行探索与限制，但是我们更加期望他们的天赋应用到品牌感、质量感、专业感、情感化设计的探索上，而不是分散精力到产品逻辑的思考中去。

——设计方案的评审与确认，正如上图所示，设计师需要分出不少精力，在设计的评审与确认上。他首先从自己的头脑风暴里解脱出来，从若干个方案中筛选一二，然后召集需求方、涉众、其他设计师，进行方案的需求。有时，这样的确认会会召开至少三轮：

第一轮，线框图初审，线框图基本完整后，与需求方以及技术方代表就线框图展开讨论，这是不是商业方也即需求方想要的东西，线框图满足商业期望，确认整体结构、页面上对于内容块的定义，技术方的参与能够就可行性方面给出意见，并且能够根据线框图进行初步的开发资源评估。
第二轮，线框图设计专业评审，让更多的设计师参与讨论，从交互设计层面给予更多意见。这个评审是第一轮评审的补充，在既定的商业需求上就设计本身展开讨论，筛选最佳的方案。
第三轮，线框图终审，设计师在前两轮意见中进行评估，对线框图做一些调整，发起第三轮确认会，商业方代表与设计师代表，技术方代表，以及相关的涉众（比如客服、销售代表）等面前再次宣讲设计方案，告诉大家本次是终审，终审确认后，将会进入视觉设计阶段，到时候将不再做轻易的结构与内容块定义的调整，让大家足够重视并对线框图达成一致。

在这三轮评审中，需要穿插多次小范围的讨论，比如可行性的评估，资源的评估，以及和产品经理反复去讨论需求和需求背后的意义。可以说，线框图的作用之一，就是为了讨论、确认，吵架，然后在一次次迭代与确认中，最终尘埃落定，推动项目进入下一环节。

交互设计师的挑战
挑战绝非在于线框图本身如何专业，或者把线框图做得如何快，而是在于对于需求的把握、挖掘与快速呈现，在于全程中对于各种想法的吸收与管理，在于能不能让大家都快速明白了解设计的原因和背景，并对方案达成一致。

不要让争议、问题带入到真正的实施环节，比如视觉设计，比如开发。
因为从投入产出比来看，把架吵到线框图阶段，是最高效最合适的。

不等于商业需求讨论环节，有很多有创造力的人，却不善于空想，对着商业需求文档，无法让创造力的脑细胞活跃起来，大家都只能对着产品经理的商业方案点头称是，但是到了线框图阶段，具体的产品原型会激发更多的想法，因此这个阶段，最适合进行产品开发过程中的第二次头脑风暴。

不等于视觉设计与开发环节，线框修改起来是非常容易高效的。而且它故意做得如此简陋难看，就是想把最核心的需求呈现给大家，这个产品是这样的，而不是这个产品看起来是这样的。

因为，“看”，“感觉”不可避免会带入很多主观的因素。同样是红色，有人觉得太鲜艳刺眼有人觉得热情澎湃，而恰恰在产品规划初期，我们是不希望过早去关注这些细节，我们需要先解决最核心的问题。视觉稿容易一开始就让大家陷入到各方向的讨论中，有人还在思考产品是不是需要再增加一个功能，或者在争论一个功能是否有足够的价值时，已经有人开始为“黄色”还是“红色”争论得不可开交。

另外，我们必须得承认，在视觉设计阶段，修改的成本非常高，视觉设计师是对每一个像素精雕细琢，产品定位的改变，也许对于他们是“灭顶之灾”，这可能会意味着很多个页面要重新开始设计，当视觉设计已经到了一定的地步时，视觉设计师对“修改”慢慢会变得有点抗拒，谁不喜欢自己生出来的孩子？如果一个视觉设计师不喜欢他生出来的孩子，那他可能不是一个合格的视觉设计师。但是交互设计师是很乐意在线框图上进行任何的可能性的探索，他会更加包容这个阶段涌入的任何想法，因为他明白这个是中间产物，而且看起来就不像“完美”到可以当成自己的孩子。

总结几句：
1. 线框图能够帮我们将需求具体化，从而引入更多的想法，完善产品；
2. 线框图能够帮助我们理清思路，怎么做，如何做有了更加系统化的认识；
3. 线框图制作起来非常容易，因此能够帮助我们在各种方案里评估和筛选；
4. 线框图是用来吵架的，交互设计师需要欢迎吵架包容各种想法，更重要的是对吵架进行管理。
5. 80%的时间并非在做线框图，而是花在需求的了解与讨论、多种设计方案的头脑风暴与尝试，设计的评审与确认上，但是这80%的时间投入让剩下的20%更加高效。
6. 作为交互设计师，在那80%里提升的空间会更大，很多时候，剩下的20%是自然而然的结果。

关于线框图还有很多问题值得讨论的，比如：什么阶段下开始做线框图，线框图制作工具与方法，几种不同的线框图的作用等等，就不过多讨论了。以上的部分也欢迎继续探讨。

原文作者：Heidi格物志
原文连接：http://heidixie.blog.sohu.com/151623325.html

或许这些文章您也喜欢：

交互设计师的专业度表现 (0)

交互设计师的专业度表现(0)

李谭伟的个人博客

godaddy抢注域名流程

或许这些文章您也喜欢：

Related Posts

Recent Comments

5款备受关注的开源 NoSQL 数据库介绍

或许这些文章您也喜欢：

Related Posts

Recent Comments

12306网上订火车票攻略：实用脚本实现半自动化

随机推荐阅读：

Related Posts

Recent Comments

博客搬家到新浪SAE服务器，暂时使用二级域名访问

随机推荐阅读：

Related Posts

Recent Comments

与技术无关：下棋感悟

随机推荐阅读：

Related Posts

Recent Comments

百万级访问网站前期的技术准备（中）

七、数据库

八、缓存。

九、队列。

十、文件存储。

或许这些文章您也喜欢：

Related Posts

Recent Comments

五个免费开源的数据挖掘软件

RapidMiner

Weka

JHepWork

KNIME

或许这些文章您也喜欢：

Related Posts

Recent Comments

网站初期需要注意的几点技术问题（上）

一、开发语言

二、代码版本管理

三、服务器硬件

四、机房

五、架构

六、服务器软件

或许这些文章您也喜欢：

Related Posts

Recent Comments

亲爱的用户，您真的满意吗？

随机推荐阅读：

Related Posts

Recent Comments

聊聊线框图——为线框图多留点时间

或许这些文章您也喜欢：

Related Posts

Recent Comments