We often recommend to set lighttpd in front of apache to handle http requests (more about http://www.mysqlperformanceblog.com/2006/05/21/speedup-your-lamp-stack-with-lighttpd/ ) , redirect dynamic requests to apache and handle static files by itself. I just gathered step-by-step instruction how to do that in 10 minutes, as it may be not so obvious.

• Of course you need lighttpd by itself, it's available on http://www.lighttpd.net/download
• You may want pcre-devel packet, which allows to use regular expressions in lighttpd.conf. For CentOS boxes we just run yum install pcre-devel
• Take sample config file lighttpd-1.4.XX/doc/lighttpd.conf and put to /etc/lighttpd/lighttpd.conf
• Create directory to store log files, e.g. /var/log/lighttpd. Despite it looks simple, lighttpd may just die trying to create files in non-existing directory.
• Set server.document-root = "/www/html/htdocs" to point to actual directory with web documents
• Uncomment next lines in lighttpd.conf
  PLAIN TEXT
  CODE:

  1. server.modules              =  (
  2. ...
  3.    "mod_auth",
  4.    "mod_status",
  5.    "mod_proxy",
  6. ...
  7. )

  mod_status is useful to show additional information from lighttpd
  mod_auth to protect mod_status from unauthorized access
  and mod_proxy is proxy by itself

• to enable status uncomment or add status.status-url = "/server-status" to lighttpd.conf
• to protect access to /server-status put next lines to lighttpd.conf
  PLAIN TEXT
  CODE:

  1. auth.backend = "htpasswd"
  2. auth.backend.htpasswd.userfile = "/var/www/.htpasswd"
  3.  
  4. auth.require = ( "/server-status" =>
  5.  (
  6.  "method"  => "basic",
  7.  "realm"   => "status",
  8.  "require" => "valid-user"
  9.  )
  10. )

  It enables htpasswd file based authentication, you can just manage this file with htpasswd utility from apache.

• and finally make changes related to proxy
  1. Move apache from 80 port to another, e.g. 8080 or pick your own.
  You need to change Listen and VirtualHost directives in httpd.cong
  and meantime set KeepAlive Off, as we want apache only handling dynamic pages.
  2. put next lines to lighttpd.conf:
  PLAIN TEXT
  CODE:

  1. $HTTP["url"] !~ "\.(js|css|gif|jpg|png|ico|txt|swf|html|htm)$" {
  2.      proxy.server  = ( "" => (
  3.      ( "host" => "127.0.0.1", "port" => 8080 )
  4.       )
  5.     )
  6. }

  This actually directs lighttpd to redirect all requests, besides one ending js|css|gif|jpg|png|ico|txt|swf|html|htm (you can add your own static pages), to apache listening on 8080 port

• Final step to add lighttpd to list of services (actual only for RedHat / CentOS)
  cp /doc/rc.lighttpd.redhat /etc/init.d/lighttpd

  fix path
  lighttpd="/usr/local/lighttpd/sbin/lighttpd"

  and add script to autostart
  chkconfig --add lighttpd
chkconfig --level 2345 lighttpd on

That's all. For complex apache setups and VirtualHosts it may be trickier, but work just fine for simple cases.

---

Entry posted by Vadim | 3 comments

Add to: | | | |

Web developers can be divided into two camps: Server-side programmers work in languages ranging from Java to PHP to Ruby, and their programs execute on one or more Web servers, typically communicating with a relational database server. Client-side developers, by contrast, work mainly in JavaScript, HTML, and CSS, displaying and manipulating data within a Web browser, while retrieving and storing that data on the server. While client-side programs are the ones that users see and use most frequently, it sometimes seems as though server-side programmers have all of the nifty toys, helping them to develop, benchmark, test, and deploy applications.

Over the last few years, there has been effort to catch up. This is particularly true in the wake of the growth of Ajax ("asynchronous JavaScript and XML"), a technique for developing Web applications that are richer, and more desktop-like, than previous generations of Web applications. A number of open-source JavaScript libraries, such as Prototype, jQuery, and Dojo, have become quite popular, handling issues such as cross-browser compatibility, back-end server communication, and data manipulation. If you are writing a client-side application without a JavaScript library, then you are probably spending too much time testing and debugging, and not enough time developing new features.

People have occasionally expressed interest in having an even richer development (and deployment) environment for client-side Web applications. Steve Yegge, a Google developer and prolific blogger, wrote last year about his "Rhino on Rails" project, an attempt to port Ruby on Rails to the "Rhino" JavaScript engine. This project is not yet public, but interest in Yegge's work indicates that people are looking for a full framework for client-side applications, rather than libraries that provide widgets and some extra JavaScript functionality.

One exciting possibility on this front is SproutCore, a new JavaScript framework. SproutCore is not new, but it has gained a great deal of public attention in the last week, since Apple announced that its new MobileMe (formerly .Mac) service uses it, and that it's possible to connect SproutCore applications with desktop Cocoa applications for OS X. SproutCore is written in Ruby, and is installed most easily using the Ruby "gems" system.

The difference between SproutCore and other JavaScript frameworks is the fact that SproutCore is a full-fledged application framework, rather than functions and objects that can be integrated into individual pages. The demos of SproutCore show that it not only has some nice-looking widgets and controllers, but that they are relatively easy to integrate into HTML pages. Like Rails and Django, SproutCore is based on the model-view-controller ("MVC") paradigm that has become pervasive among Web developers, making it easy to create nice-looking Web applications.

Rails developers will find SproutCore's command-line generators and interfaces to be quite familiar. The software is distributed under the MIT license, meaning that the software itself is open source, but that it can be repurposed and used inside of proprietary software.

SproutCore is merely a beginning; it still doesn't have all of the things that a client-side developer might want, or all of the debugging support that we might expect in a server-side framework. However, the fact that Apple has already adopted SproutCore ensures that it will continue to be maintained, at least for the near future. It remains to be seen how the various JavaScript frameworks react to SproutCore, and how the server-side Web application frameworks work to incorporate it (or not) as a default.

Related Activities Comments (4) Post a Comment Ask a Question

Related Software jquery (1 alternative, 1 review) ruby (4 alternatives, post review) javascript (add alternative, post review)

Related Blog Posts Book Review: Deploying Rails Applications (post comment) Create Rich Reports With Ruport (post comment) Check Your Site With Tarantula (2 comments)

dbanotes posted a photo:

缺乏定义良好的、用于处理文件系统操作的库，这一直是 C++ 语言存在的一个问题。过去，程序员必须使用本机 API 来解决此问题。通过本文您将了解一个提供安全、可移植且易用的 C++ 接口来促进文件系统操作的库：Boost Filesystem Library。

发表者：Google（谷歌）研究员 吴军

1828 年、1835 年和 1842 年在美国加州圣地亚哥、旧金山和洛杉矶先后发现了金矿，并从此开始了美国西部的淘金热。到第二次世界大战前，加州黄金产量达到高峰，每年四十吨，接近于全世界有史以来黄金总量的千分之一。旧金山也因此而得名。但是，从对世界经济的影响和对人类进步的贡献来看，加州的淘金热远比不了二战后在旧金山湾区掀起的科技淘金浪潮。只是，这一次浪潮的核心元素不是地球上储量稀有的金子，而是储量第二大的元素，即土壤、沙子和玻璃的主要成分“硅”。它是半导体工业的核心元素。旧金山湾区从领导世界半导体工业开始，扩大到整个科技工业。从此，这里有了一个新的名称 — 硅谷。

硅谷对外面很多人来讲是一个神秘而令人向往的地方。我在写这一章以前问过很多没有到过硅谷的人，“你觉得硅谷是个什么样的地方？”大部分人觉得，硅谷是科技之都、创新的地方、发财的地方，国际多元化的社区，气候最好的地方（注：硅谷地区确实四季如春）等等，也有个别人讲，硅谷是冒险家的乐园。这些看法都正确，而且在很多书里和媒体中一直是这样介绍硅谷的，因此我们不必在此赘述了。这里，我只想介绍一下硅谷的另一面，使读者对这个神奇的地方有个全面的了解。

1. 成王败寇

在过去的五十年里，美国百分之三、四十的风险投资投到了只占国土面积万分之五的硅谷地区，并且让硅谷创造了无数的神话。在这里，大约每十天便有一家公司上市。美国前一百强的公司中，硅谷占了四成，包括 IT 领域的领军公司惠普、英特尔、苹果、太阳、思科、雅虎、Google（谷歌）和现在很红的 YouTube、Facebook ，以及生物领域的基因科技（Genentech）。当然世界上最大的风险投机公司 KPCB、红杉风投和很多大的投资公司也在硅谷。硅谷还拥有世界上顶级专业数量排名前两名的大学斯坦福大学和伯克利加大（UC Berkeley）。

硅谷的气候属地中海式气候、四季如春，是世界上最宜居住的地方之一。全球只有五个不大的地区有这样好的气候。同时硅谷是世界上文化最多元化的地区，是世界上各种族人民相处最和睦的地区，其中第一和第二代移民占人口的一半以上。正是靠各民族人民的聪明智慧和勤劳勇敢，硅谷地区几十年来是世界上经济成长最快的地方。加州占美国经济总量（GDP）的六分之一，其中大部分来自于硅谷。2005 年，硅谷明星公司谷歌的员工贡献了全加州税收增幅的八分之一。我们可以毫不夸张地讲，硅谷是世界上最富传奇色彩的科技之都，对世界科技和经济的发展做出了无与伦比的贡献。

正是由于硅谷在科技领域的成功，也造就了无数百万富翁甚至亿万富翁。一些年轻人在短短几年间就做出了他们前辈一辈子没有完成的发明创造 — 从集成电路、个人微机、以太网、Unix 操作系统、磁盘阵列、鼠标、图形工作站到网络浏览器（Web Browser）、关系型数据库、视窗软件、Java 程序语言、全电动力跑车等等。作为回报，他们聚集的财富超过欧美一些名门望族几代人的积累。在去年美国富豪榜上，前五位（共有六人，其中第五名是并列的）有一半来自于硅谷。很多人津津乐道好莱坞比佛利山庄的豪宅，其实无论在规模和价值上，它们与硅谷旁边的 Atherton 的豪宅相比都是小巫见大巫。

无数的图书、报纸、电视和今天的互联网，讲述着这样一个关于硅谷的故事：“有两、三个缀学的大学生（最好是斯坦福的），有一天在车库里甚至是不经意发明了一个什么东东，马上来了几个（没头没脑的）风投资本家，随手给了他们几百万美元。两年后，这几个年轻人办起的 burnmoney.com 公司就上市了，华尔街欣喜若狂，也不管它有没有盈利，当天就把它的股价炒了三倍，这几个创始人一夜之间成了亿万富翁，跟着他们喝汤的员工们也个个成为了百万富翁。接下来，他们盖起百万千万的豪宅、开上保时捷甚至法拉利的跑车。每个人又甩手给母校盖了栋大楼，于是张三李四王五的大楼就到处都是了。”我不能说这种宣传的事没有发生过。事实上，它还不止一次发生过，只是这种的几率比中六合彩大奖的概率大不了多少，但绝对比被汽车撞死的概率小很多。（事实上，世界上死于交通事故的人数高达一百二十万，但靠创业发财的可没有这么多。）在硅谷，赶上上述这样机会的人，被称作中了“硅谷六合彩”（Silicon Valley Lottery）的幸运儿。虽然事情发生的可能性很小，但是榜样的力量是无穷的，这种故事的新闻效应很大。媒体和华尔街乐于塑造出一个个传奇人物和公司。二三十年前年轻人的偶像是乔布斯，后来是 Netscape 的吉姆.克拉克（Jim Clark）和雅虎的杨致远和费罗。这十年是谷歌的佩奇和布林，以后可能是 Facebook 的马克∙祖克伯格（Marc ZuckerBerg）。这些成功人士的传奇点燃了年轻人心中创业的梦想，就如同好莱坞的明星带给了无数少男少女的明星梦一样。这正是风险投资资本家和华尔街所希望的。只有越来越多的人加入这种创业的游戏，投资者才能有好的项目投资。

我的周围便聚集着许许多多憧憬着创业成功又无所畏惧的年轻人。他们朝气蓬勃又聪明肯干。由于种种原因，我时常需要认真地倾听他们创业的计划。坦率地将，我对这些沉溺于创业梦想的人泼凉水的时候多于鼓励的时候。虽然我知道他们更需要鼓励，但是在硅谷这个环境中，他们已经得到了无数的鼓励。因此，我觉得不必要的客套和言不由衷的鼓励可能会促使他们更加飘飘然，这样他们不仅血本全无，而且会失去赖以生存的条件。毕竟，硅谷的竞争太残酷了，成功的机会太低了。我有时会开玩笑地说“如果你不相信这辈子会被汽车撞死，为什么相信能中硅谷大奖？后者的可能性更小。”他们会开玩笑地说：“也许是利令智昏吧。”

我们不妨看看创业成功的可能性。据统计，即使是在网络泡沫高峰、创业最容易的 2000 年，创业的小公司（Startups）最终能成功的或者上市或者被收购的，不过百分之二到三而已。绝大多数都夭折了，这些创业者也就默默无闻了。人们从来就是只记得住英雄的名字。网络泡沫破碎以后，我在谷歌面试过很多创业者(他们有一个好听的名字叫某某公司的创始人)，他们不乏很聪明、专业知识扎实，又很有干劲的人，这些优点远远不能保证他们能成为成功的企业家。但是，其中很多人不适合创业。

一个小公司要想成功，有很多因素必须同时具备。

• 首先，创始人很重要。任何梦想家都不足以成事，因为所有的成功者都是实干家。看过《三国演义》的人都知道，书中有两类聪明人，一类是曹操、司马懿那样的领袖人物，另一类是出点子的谋臣，像郭嘉、诸葛亮。办公司需要的是前一种人。创业者还必须精力过人，因为他们必须能熬得住几年每天在简陋的车库里工作 16-20 小时的苦日子。他们又必须是多面手，因为在创业初期他们必须干所有的脏活。著名的语音技术公司 Nuance 的共同创始人麦克.科恩（Mike Cohen）博士跟我讲，创业是一件极麻烦的事，创办一家公司的初期，小到安装一个传真机这种杂事都得自己干。成功的创业者必须有一个小而精的好团队，里面每个人都得不计较个人得失，同甘共苦，否则成则争功，败则互相推诿。在技术上，他们必须有自己的金刚钻，他们的技术必须是不容易被别人学会和模仿的。如果看到雅虎挣钱，就去搞网站，那基本上可以肯定是要失败的。

• 但是光有好的团体和技术又远远不够，他们有商业头脑而且必须找到一个能盈利的商业模型（Business Model）。Ebay 和谷歌的成功很重要地在于它们很早就找到的好的商业模型。但是找到一个好的商业模型有时比发明一项技术更难，即使最有经验的风险投资专家在这上面也经常栽跟头。成功投资谷歌、太阳和 Ebay 等公司的风投之王 KPCB 也在毫无市场前景的、很酷的产品“Segway”上浪费了几千万。（我在后面的章节中会说明为什么 Segway 没有出路。）我一直不看好 Web 2.0 的原因也是它们至今没有好的商业模型。

• 再接下来是判断力和执行力。通常，办起一个公司并不难，把它从小做到大，并且做到盈利就不容易。在这个过程中有很多路要走，不免要遇到数不清的岔路，任何一次错误的选择都可能使原本看上去不错的公司运营不下去而关门大吉，因为小公司对抗大公司时是不能有任何一次失误的。执行力是保证正确的决定能够最终实现的因素。判断力和执行力很大程度上来自于经验。创业的年轻人天生具有非凡的判断力和执行力不容易，为了保证一个起步良好的公司能够成功，一般风险投资家在投资的同时，要为公司寻找一位专业的 CEO ，就是这个目的。

• 真正具备这些条件已经很不容易了。而一个初创公司的成功很大程度上还要看外部环境好不好，很多很有前途的公司因为创办的时机不对，也会随着经济大环境的衰退而夭折。比如 2000 年成立的公司就鲜有成功的。这样，能生存下来的公司就凤毛麟角了。

• 最后，也是最重要的，创业者必须有好运气。世界上最大的防火墙公司 Netscreen 共同创始人柯岩博士对我讲，创业成功的关键是要有运气。

当一个小公司成功上市后，股票能涨上去的又只有百分之二到三。大部分公司上市后股价平平，甚至不如上市价（即在中国常说的原始股价）。远的不说，就说最近两年中国在美国上市的两家很不错的半导体公司，中星微电子和展讯现在的价钱都不到上市时的一半。就连世界上最大的私募基金（Private Equity）公司黑石（BlackStone），上市半年后的股价也只有上市时的一半（用中国股民的话讲叫跌穿发行价）。更糟糕的情况是上市不久因无法持续盈利或者达不到预期盈利，就不得不再下市，或者被私募基金买掉。比如著名的硬盘制造商 Seagate 和美国最大的网上旅行社 Orbitz.com。其实，中国现在如日中天的网易公司，也曾经被 Nasdaq 勒令下市。根据美国证监会的规定，一个公司上市后员工（包括创始人自己）的股票在 180 天以后才能卖。因此，一个公司上市 180 天后，股价会大跌，因为员工能卖股票使得该公司股票可能供大于求。因此，通过创业成功能发大财的人终究是极少数。

创业的过程本身是异乎寻常的艰辛。即使最后成功了，回首起来也是险情不断。一位非常成功的创业者和我们讲，他和他的合伙人在前一家公司挣到了不小的一笔钱，就创办了自己的公司。很快，两人上百万的积蓄就烧完了，他们艰难到用信用卡买设备，每月勉强支付出信用卡的利息。他们的运气很好，在这个时候找到了风险投资，融资几千万，但是，仅仅一年又烧得差不多了。好在当时两家垄断性跨国公司不惜成本地相互竞争，使他们渔翁得利，得以以一个很好的价钱（十几亿美元）被其中一家收购。但是，回想起来，成败就在一线之间。

硅谷汇集了美国三、四成的风险投资，每天硅谷都有成百上千的公司成立，但同时又有成百上千的公司关门。对于那些失败的公司，大家并不关心，甚至无人知道它们的存在。即使很多曾经辉煌过的公司，像网景公司、SGI 公司，人们很快也就忘却了它们。在这些成千上万家硅谷的公司中，最终创造出了一些像思科、谷歌那样的传奇故事。仿佛间在硅谷办一个公司就能成一个。岂不知，一将功成万骨枯，无数失败的公司在为少数几个成功者做分母。

上面这些问题是每个科技创业者在决定辞职或者退学创业前必须认真考虑的。

《纽约时报》报道了20世纪早期的一位被人遗忘的互联网先驱、比利时人Paul Otlet。1934年，Otlet粗略的勾画了一个全球计算机网络的草图（他称之为电子望远镜），允许人们浏览和搜索数百万链接起来的文档、图像、音频和视频文件。他描绘了人们如何使用这个设备向其他人发送信息，共享文件甚至是组建一个在线社区。他把这一切叫做“réseau”，翻译过来就是“网络（network）”，或者是“环球网（Web）”。Tim Berners-Lee在1991年发布了第一个浏览器，但早在半个世纪之前，Otlet就描述了网络化的世界。虽然他设想的原始网络更像是是索引卡和电报机的拼凑，但无疑预言了当今世界的超链接结构。《连线》杂志的前编辑Kevin Kelly说，“这是超文本的蒸汽朋克版”。Otlet构想的网络机器的一个想法是在文档中加入符号，今天看来显而易见的概念在1934年绝对是巨大的突破，超链接是上个世纪未得到公允评价的最伟大发明之一。

Ruby on Rails is, of course, one of the hottest open-source technologies being used today. It shouldn't surprise anyone to find that the number of books about the Ruby language, and about Web development using Rails, has soared over the last year. I must have at least 25 books on these subjects, and many more PDFs on my hard disk. And that, of course, ignores the many blogs, podcasts, and screencasts that Ruby programmers are creating on what seems like an increasingly frequent basis.

While many of these books tell you how to write Rails applications, very few of them tell you how to deploy them for real-world usage. That is, once you have written your amazing application, using features from ActiveRecord to RJS, how do you put it onto a production server? How do you manage updates from your development environment to that production server with minimal downtime? How do you monitor your server for problems? And finally, what happens when your application becomes extremely popular, and you have to move from a single server to a cluster?

These are the sorts of questions that the book Deploying Rails Applications, published recently by the Pragmatic Programmers, tries to answer. The authors -- Ezra Zygmuntowicz, Bruce Tate, and Clinton Begin -- are experienced Rails developers, with Zygmuntowicz known not only for his Rails-related blog and contributions to Merb, but also for EngineYard, a Rails hosting company.

I found this book to be a good introduction to the topics that a Rails developer will need to know when pushing applications to the real world. The book is not aimed at advanced users, although there were certainly things that I learned about Rails deployment from reading the book.

Perhaps my favorite chapters were the ones having to do with software and procedures that aren't well documented elsewhere. For example, Capistrano is given a chapter of its own, introducing users to the de facto standard among Rails users for deploying new versions of an application.

An entire chapter describes how to work with Windows, either as an individual development system or for deployment. Throughout the book, the authors stress good security practices, reminding readers to use secure programs, such as SSH, instead of insecure alternatives, such as telnet. Finally, while the book describes several different HTTP servers, it goes into extensive detail on the use of Mongrel, a Ruby-C hybrid that has become quite popular in the Rails community.

Deploying Rails is written well, and contains numerous examples of both code and configuration files. It includes many tips that readers will want to use in their production Web sites. Perhaps my only disappointment with the book is that it is so thin, and that it is aimed at relative beginners. The section on benchmarking and performance tuning provided a good introduction to the subject, but left me wanting some more practical examples.

That said, Deploying Rails Applications is a good book for beginning Rails programmers to have around as they begin to write and deploy applications. It contains many useful tips and pieces of advice, as well as strategies for monitoring your applications once they are already in use.

Related Activities Comments (0) Post a Comment Ask a Question

Related Software rails (1 alternative, post review)

Related Blog Posts SproutCore Raises the Bar for Client-Side Programming (4 comments) Create Rich Reports With Ruport (post comment) Check Your Site With Tarantula (2 comments)