语言的价值

编程语言对一个程序员有多重要？看看那些招聘广告吧，有那么多赤裸裸的招聘会某种语言的程序员的广告，这无异是将程序员的价值与编程语言挂钩了，这也使得不少人在选择编程语言时会关注什么语言最火或者什么语言最赚钱，而忽视了工作内容所体现的价值。就web开发来说，为求开发迅速，像PHP这样的脚本语言是多数网站的选择，所以PHP程序员遍地都是。但是，招聘web开发人员显然不仅仅要求会个PHP语言就行的，而是要求能解决web开发中的各种问题，而这些问题和语言的关系是不大的。有能力的程序员不会过多的纠结于编程语言、使用的框架等这样低层次的问题。

但是，语言在一定程度上也和程序员的身份有了对接。还是就web开发，如是C/C++程序员，那他可能是做后端的，并且很可能解决着大流量高并发的应用；如是PHP程序员，那他接触的可能就是LAMP那一套东西；如是JavaScript程序员，那他应该也会HTML和CSS，是个做前端的。而就领域来说，如果你是个中高手，是根本不需要care语言的，学习一门语言并不是很困难的事情，并且有远见的公司是不会只拿语言来卡住人才的。

话又说回来，语言也确实会影响程序员的境界，因为一种语言所形成的社区和文化会左右程序员对编程各方面的认识。像Java社区，关注点会在OO、模式、敏捷开发、各种框架、各种库、各种新技术上，所以无论是语言本身还是社区的技术都在进步；反观C/C++社区，语言一直那个样子，能用上手的高质量的库也不多，所以，像apache、nginx、mysql这样的大型软件，都是自己封装了一套基础库和功能，而在Java社区因为有着丰富的高质量的库，根本不必为一些基础功能重复造轮子。至于PHP社区，能看到的也就是关于语言方面的基础问题，而语言出身是过程式后来引入OO特性，使得社区的编码风格也迥异，代码质量参差不齐。

语言的特点

面向过程与面向对象。现在面向过程的应用主要就是C了，也有些C++的，因为程序员想用C++的标准库，但代码风格还是C的。C语言作为高级语言中的低级语言，对程序员是有着很高的编程要求，而过程式代码在大型应用中很难被驾驭，那种优良的模块化设计构想往往会被淹没在语言的细枝末节上。知名的Tokyo cabinet，作者因为无法忍受C语言的种种限制，便使用C++重写了一遍，结果是换来了更清晰的代码组织和下降的性能。

静态类型与动态类型。脚本语言很受web开发欢迎的一个重要原因是，脚本语言无类型或者是弱类型，这使得脚本语言的变量使用要比静态语言少些代码，不需要声明变量直接使用，不需要关注类型转换的问题等等。但它也带来一些问题，你可能会使用了错误的类型信息造成潜在或难以察觉的bug，因此我之前就职的公司的PHP编码规范就要求变量名以类型名做前缀，使得变量名既难看又增加了长度，但这种要求对代码的阅读性等方面却又有不少帮助。而Ruby语言，在类型方面是介于无类型和强类型之间的“鸭子类型”，这使得因为类型问题引发的bug会更容易在测试中发现，这种特性总是被作为语言得意的资本被提及。

应用的场景。像C/C++这样的古董能活着，还是有大量的应用对性能及稳定性有着高要求，而C/C++在这方面显然要好于虚拟机及被解析成C的脚本语言。Java呢，它的全面性在一定程度上既代替C/C++又能代替脚本语言，但它性能及稳定性不及C/C++，灵活性不及脚本语言，所以能在企业应用中活的很好却在互联网应用中处境略显尴尬。像PHP、Ruby、Python等脚本语言，因为有着丰富的库，也或许会有强悍的框架，更因为高的开发效率，成为多数web应用的首选，但他们应对复杂的商业系统就败下阵来。

语言的应用

就做网站来说，使用纯C/C++、纯Java、纯脚本语言都能独立把网站搭起来，但他们的成本是不一样的。从用人单位的角度来说，选择一门流行度高并能高快好省的满足需求的语言是最好的，所以，PHP能成为web开发的大众语言，而像Ruby和Python，尽管他们或许比PHP更优秀，但因为大街上会Ruby和Python的并不是一大把一大把，并且其学习成本相对也要高于PHP，所以使用小众的语言有时并不是很好的选择。这也使得一些人变得很纠结，因为他们在使用了多种语言之后，真的是深深的爱上一种语言。我知道的一个Ruby fans，就是找工作时就只瞅准了Ruby开发，其他语言的开发工作都不予考虑，这无疑会缩小他的求职圈子。

也可以看到的是，语言的流行度也和语言的推广度及认知度有关系。像Ruby，如果没有Ruby on Rails，这个出生于上世纪90年代的语言或许永远不会被广泛传播，而随着像Twitter等ROR应用案例的增多又促进语言在库、性能等方面的发展，使得它有更广泛的应用前景。像Python，国内能叫的上号的案例就是豆瓣了，豆瓣的成功应用也会促进Python在国内的推广。至于Java，国内知名的应用要数校内和淘宝了，但Java作为前端开发还是略显笨重，更适合后端应用，随着JVM的不断改进，有越来越多大型的基础性服务使用Java，像Cassandra、Hadoop，尽管他们的单机性能比不上C/C++，但在大型的分布式系统中，这种单机性能就不是特别重要了。

北京城的高楼里有着许许多多怀揣梦想的创业团队，他们有的对技术并不热衷，使用着最大众的语言实现他们的Idea，他们有的对技术很有热情，使用着最潮最酷的语言和技术在谱写理想。通过使用的语言使用的技术，也可以窥看出一个团队的技术水准，而技术水平的高低，有时也可以决定产品的成败。

语言的选择

程序员因为工作的需要，可能平时也就使用一到两种同类型的编程语言，而程序员的私心又使得其可能业余时间鼓弄别的语言，并当机会来临的时候能使用上它。但多数公司通常会选择固定的几种开发语言，并且当选定后，很难会引入新的语言，这自然会使一些对语言有情结的人有些沮丧。就像程序员会热衷模式、重构来提高代码质量，同样也希望能使用最优美的语言表达想法。我想，Rails火了以后，很多人都会鼓弄它并有人爱上了它，但把它在公司里推广应用多是很困难的，所以一些Ruby fans在写PHP时可能还在咒骂这门语言的糟糕。

关于语言，我没有太多的情结。从写C语言的hello world到现在，我使用过的并能开发出应用的语言有C、C++、PHP、Java、C#、JavaScript、Ruby（我曾买过一本Python的书，不过只是写过hello world后因为精力有限就放弃了）。我现在的工作语言是Java，也看些PHP项目的代码，业余时间也研究C/C++的开源软件并写些代码。程序员会多种语言是很正常并很有必要的，了解不同语言的特点能提升对语言的认知，并可以根据需要在开发中使用最合适的语言。也很重要的是，如果你需要借鉴使用你并不熟悉的语言编写的开源软件，以至于需要深入分析代码，能读懂那门语言就是必要的了。

对于语言的选择，我是觉得程序员应该掌握三种语言：C、Java和一种脚本语言。为什么是这样，其实我也无需过多解释。当然，总会有新兴的语言特性出现，也总会有新兴的语言出现，不故步自封，多吸收些新鲜事物总是好的。

安装

1、下载subversion-1.6.9.tar.gz和subversion-deps-1.6.9.tar.gz。

2、将上面的两个压缩包都解压到subversion-1.6.9，cd到subversion-1.6.9执行./configure –prefix=/path/to/svn、make、make install，则svn安装完成。

配置

1、执行/path/to/svn/bin/svnadmin create /path/to/svnroot，则建立仓库。

2、cd到/path/to/svnroot/conf，编辑svnserve.conf，将第12行的anon-access = read、13行的auth-access = write、20行的password-db = passwd注释去掉。注意去掉##注释的同时要把前头的空格也去掉。再编辑passwd，可以添加用户或者最简单的把[users]下面的注释去掉，注意也要去掉前头的空格。

使用

1、cd到/path/to/svn/bin，执行./svnserve –d则运行了svn服务器。

2、为方便使用svn命令，可以在.bashrc中添加：alias svn=/path/to/svn/bin /svn。接下来就是svn命令的一系列操作了。

3、客户端使用上，我当前的需求只是在eclipse中提交代码，使用上也很简单。需要配置的仓库地址是：svn://ip/path/to/svnroot，ip后跟的路径是绝对路径。

http://highscalability.com/blog/2007/12/7/synchronizing-databases-in-different-geographic-locations.html

翻出很久之前的一篇文章，该文提出了跨地域同步数据的问题。就Mysql来说，如果数据需要在两个地域传输，使用双主复制模式是较为简单的方法。如果mysql能支持多主复制模式，多地域的数据复制或许就解决了。但多主复制很难搞，这种多点并发复制很难自动化的处理提交冲突的问题。

2、LinkedIn Search: A Look Beneath the Hood

http://thenoisychannel.com/2010/01/31/linkedin-search-a-look-beneath-the-hood/#

这篇揭示LinkedIn的检索系统PPT很不错，尽管我对检索了解不多。对检索结果，LinkedIn没有采用通常的cache方式，而是重新计算。Cache检索结果的好处是提高性能，但无法保证cache数据的真实性，而LinkedIn期望每一次的检索结果都是准确的数据。LinkedIn采用数据库分区、大内存缓存DB数据的方式提高DB查询效率，以至于像双向好友关系也是实时查询的。LinkedIn对Lucene打的实时检索补丁，也很值得研究。

3、HipHop for PHP: Move Fast

http://developers.facebook.com/news.php?blog=1&story=358

Facebook爆出的HipHop对PHP社区绝对是爆炸性的消息，如果它开源的话，估计会被众多公司研究和采用。HipHop原理是将PHP代码翻译成C++代码，再编译成二进制程序执行。这一方式和LiteXml类似，都是为了克服脚本语言解释过程的低性能，而在生产环境迂回成编译性程序执行。不过，HipHop会因为C++语言的限制而失掉一些PHP语法功能，尽管不是很重要的说。我倒是很期望PHP能做成虚拟机，不失开发效率，也一样能提高解释执行的性能。

4、HOW FARMVILLE SCALES TO HARVEST 75 MILLION PLAYERS A MONTH

http://highscalability.com/blog/2010/2/8/how-farmville-scales-to-harvest-75-million-players-a-month.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+HighScalability+(High+Scalability)&utm_content=Google+Reader

该文分享了一个social game的技术经验，但没有什么太细节的东西。只有最后大众化的LESSONS LEARNED可以汇总下：

1）对于写多读少的social game，采用in-memory架构，异步提交数据是王道。

2）系统内的组件间低耦合，即便某个组件挂掉，也不会完全影响整个系统的使用。当系统出现性能等问题时，可以关闭一些不必要的功能来缓解问题。

3）缓存Facebook的数据。

4）对新功能做好性能预估及应对方案。

5）抽样部分数据来做分析。

5、When should you store serialized objects in the database?

http://www.mysqlperformanceblog.com/2010/01/21/when-should-you-store-serialized-objects-in-the-database/

Peter的文章总会跟来一堆人的争论。Peter反对在mysql中使用无模式的blob字段，它给出的理由主要有：

1）查询时需要获取整个数据，即便只需要其中部分。

3）blob字段在更新时需要复制的数据更大，并且非定长会造成数据碎片。

3）如MIN, MAX, AVG函数不能使用。

4）blob字段内容没有类型约束检查，需要程序保证，这可能带来潜在的问题。

以用户信息这样的数据类型来说，它的典型特点是：1）一个id对应着一堆属性信息。2）需要针对属性字段做查询条件。这种情况的最简单的做法是，建立一张多属性的schema表和一堆属性索引，但这会带来属性查询的低性能。所以，像FriendFeed、Twitter等，是将属性数据和索引分开。在此基础上，问题只是属性数据的存储是要还是不要schema。如果要schema，peter提到的问题都不是问题，但也带来新的问题：1）属性增加需要修改表结构，这是很折腾人的事情。2）如果属性很多，表结构需要的列数会很多，一个解决方法是，可以将属性分成几类分别存储。实际上，如果在mysql前面有cache（或者Mysql自己的cache够大）来缓存主用户信息，而更新又不是很频繁，blob存储是没什么太大问题的。