游戏人生

颂山川,吟古道,偏失半点笔墨;言世事,问苍生,更差一声长嗟。

多方比较之后,决定选用python框架django做web开发,选用python而不是php或者asp之类的原因主要是三点:

  • 操作系统喜好决定了我不会选择asp。相比windows,更喜欢linux;
  • php的类C语法打动了我,兼之历史悠久,与mysql的结合也很好,只是我总觉得php离我心中的编程感觉远了点;
  • python缩进在有代码洁癖的我看来很优雅,而且python用途更广泛。

这一次使用nginx+django的过程中,解决了之前的一些问题:比如关于URI(尤其是静态文件的URI)解析的问题。按照django官方文档的说法:Django itself doesn’t serve static (media) files, such as images, style sheets, or video. It leaves that job to whichever Web server you choose. django只针对开发过程提供django.views.static.serve()视图,产品配置则须由web server完成。这个问题包括使用django的admin应用需要面对的admin的media URI解析问题,期间又对nginx配置熟悉了一些。

另一个问题正是关于nginx的,这次把django、php、trac都放在一个虚拟主机下,非常有创意,但绝非有意为之的一个结果是:django和php虽然都使用nginx+fastcgi,但django使用socket方式,而php使用host方式;trac则使用nginx对apache作反向代理。如此混搭的方式,与其说是为了实验各种实现,不如说我尚未找到统一的方案,尤其是针对trac的nginx+fastcgi socket的配置方案。

第三个问题是针对开发和产品采用不同配置带来的问题。这篇文章通过判断当前主机的名称决定使用哪种配置。方法简单有效,只是当开发主机与产品主机相同时需要动动脑筋;相比之下,我觉得这篇文章介绍的方法更加通用。

由于涉及项目具体配置,有必要对本文提到的项目名称和目录进行说明,参考时请注意作相应修改:

  • 项目名称:fox
  • 项目位置:/home/yulefox/fox
  • 开发用配置文件:/home/yulefox/fox/settings/development.py
  • 产品用配置文件:/home/yulefox/fox/settings/production.py

项目fox创建时,django在项目目录/home/yulefox/fox下生成对应的配置文件settings.py。为了能够针对开发及产品使用不同的配置文件并便于管理,我们将其移至新建目录settings下并重命名为development.py,并在该目录中创建名为__init__.py的空文件以保证该目录可作为包使用。此时当我们使用python manager.py runserver命令运行开发服务器时,得到以下结果:

            Validating models...
            0 errors found

            Django version 1.2, using settings 'fox.settings'
            Development server is running at http://127.0.0.1:8000/
            Quit the server with CONTROL-C.

我们注意到,django并没有使用我们修改后的配置fox.settings.development。这是由于项目中的manager.py导入的配置没有改变,将manager.py中的settings替换为settings.development后,再次运行得到以下结果:

            Validating models...
            0 errors found

            Django version 1.2, using settings 'settings.development'
            Development server is running at http://127.0.0.1:8000/
            Quit the server with CONTROL-C.

结果证实修改生效,不幸的是,这并不是终点,因为当我们打开http://127.0.0.1:8000/时,我们看到了以下错误信息:

            ImportError at /

            No module named fox.urls

容易想见,这应该正是因为修改配置文件目录的问题,我们可以通过在python manager.py shell中输出sys.path的结果来印证这一点,输出中包含了项目目录/home/yulefox/fox而非项目的父目录/home/yulefox,显然,项目fox中不再有一个名为fox.urls的model,python为我们提供了一个名为PYTHONPATH的环境变量,我们可以通过设置该环境变量因应配置文件目录的变化:export PYTHONPATH=/home/yulefox

另外,我们可以无需修改manager.py和使用python manager.py runserver解决本文提到的配置问题。django提供了环境变量DJANGO_SETTINGS_MODULE以设置所使用的配置文件,如本文中:export DJANGO_SETTINGS_MODULE=fox.settings.development。这种情况下,我们需要使用django-admin.py runserver启动服务器。

上面介绍的开发配置方式同样适用于产品配置方式,我们只需在settings包中添加并配置production.py即可。在Apache中,我们可以直接在虚拟主机配置文件中使用SetEnv DJANGO_SETTINGS_MODULE fox.settings.production完成对环境变量的配置;而在Nginx中,如果使用fastcgi,则可以使用manage.py runfcgi --pythonpath=/home/yulefox/fox --settings=fox.settings.production来完成配置;wcgi等实现方式需要读者自行完成。

之前在搭建web服务器的时侯,都是使用眼下主流的apache。这次在机器升级(两次升级都以失败告终,所以准确的说,是重装)到ubuntu 10.04之后,打算赶个时髦,用nginx做服务器,由于对nginx和fastcgi都不熟,搞了两个晚上,到现在还只是配置php成功,trac还没有搞定。

中间几次想放弃,继续投奔apache,并且把主要精力先放在内容实现上。最后还是决定享受这段自虐,就当是对服务器熟悉的一个过程。无论是服务器还是脚本,除参考别人的经验外,自己的实践是少不了的。如果是为了方便的话,apache虽显臃肿,但由于历史悠久,文档丰富,支持者众,用起来最方便;如果想折腾的话,怎么着都是你自己受罪,就无所谓了。

总结了一下,对于初次尝试nginx(尤其是对这一块不甚了解)的同学来讲,还是从最简单的静态页面支持开始,逐渐深入掌握其它服务器配置,想一步到位的搞定所有问题几乎是不现实的,一步步的做反倒是最快的方法。在这一点上,我刚开始的时候就有点冒进,以为自己对apache搭建虚拟主机有了点经验,上手nginx也会很简单,前面搞了几个小时都可耻的失败了,撞墙后从头再来:

o localhost默认欢迎页面;

o 局域网IP和虚拟主机默认欢迎页面;

o 虚拟主机指定文档目录(支持静态页面);

o 虚拟主机php服务器配置。

现在还有trac、svn等问题未解决,所以在平稳过渡到nginx之前,还是继续使用apache作web server。使用nginx对apache进行反向代理,apache改用8080端口,nginx使用默认80端口。


最后附上一份虚拟主机配置:

#! /usr/bin/perl

server {
    listen       80;
    server_name  km.fox.com;
    root         /home/fox/yulefox/km;
    index        index.html;

    location / {
        proxy_pass      http://192.168.1.100:8080;
        proxy_redirect  default;
    }
}

server {
    listen       80;
    server_name  www.fox.com;

    location / {
        root   /home/fox/yulefox/web;
        index  index.php;
    }

    location ~ \.php$ {
        include        /etc/nginx/fastcgi_params;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_param  SCRIPT_FILENAME /home/fox/yulefox/web$fastcgi_script_name;
    }
}

WeBwArE

以前用QQ音乐听歌,将自己喜欢听的音乐分成几个列表,根据自己的心情选择列表来听。

后来用谷歌音乐或者百度音乐,但每次找歌是个麻烦事,而且没有QQ音乐的本地缓存机制。慢慢的就只用rhythmbox听那么几首歌,听腻了就干脆连rhythmbox都懒得开了。

试了一下豆瓣电台,有点符合我心目中的要求:

o 速度很快,没有缓冲。不知道是豆瓣的服务器技术NB,还是她的服务器负载强大;

o 不用自已选歌。选择几个自己喜欢的歌手,剩下的事情都交给电台了,豆瓣采用的智能算法估计和谷歌音乐都是基于同样的原理,但豆瓣不摆在面上,并且实实在在的把技术用到用户体验上,你只要知道结果就行了;

o 不知道下一首歌是什么。对于我来说,这是一个天大的优点;

o 界面简洁。我使用FireFox,没有插件的安装,打开就可以听,除去音量条,就剩4个按键。

隐约中有个感觉:豆瓣虽然越来越强大,但对于所拥有资源的整合能力有点差,各产品之前的聚合交互不够,图书、音乐、电影、小组……各自为战。

如果说目前鱼龙混杂的互联网行业中,有哪些公司的产品是工作、生活中的必需品的话,除了Google,豆瓣算一个。现在上网四件事:

o 搜索:Google

o 邮件:Google

o RSS+资讯:Google

o 音乐:豆瓣

或许,豆瓣就是那个互联网领域最早能够打败腾讯的公司

以周文蓬的一曲《不会说话的爱情》欢送G.cn。

绣花绣得累了
牛羊也下山咯
我们烧自己的房子和身体
生起火来

解开你红肚带
洒一床雪花白
普天下所有的水
都在你的眼中荡开

没有窗亮着灯
没有人在途中
我们的木床唱起歌说幸福它走了

我最亲爱的妹哟
我最亲爱的姐
我最可怜的皇后
我屋旁的小白菜

日子快到头了
果子也熟透了
我们最后一次收割对方
从此仇深似海

你去你的未来
我去我的未来
我们只能在彼此的梦境里
虚幻地徘徊

徘徊在你的未来
徘徊在我的未来
徘徊在水里火里汤里
冒着热气期待

期待更美的人到来
期待更好的人到来
期待我们的灵魂附体
重新回来
重新回来
重新

抱歉,我的确不想做标题党,但谷歌这次真的灰常灰常的悲剧。

谷歌音乐终于可以在服务器保存列表了,听歌不用每次添加,也不用下载到本地了。这是一个喜剧,对吧?

然而……

谷歌音乐登录界面

注意哦,没有Google ID,那是Windows Live ID哦!

悲剧啊!

让我想起一句话,这里稍加篡改:谷歌就像一个被闲置的漱口盅,初来中国时是一部洗具,活到现在,生生的被冷落成一部杯具!

时常写一些文档,希望这些文档在公司和家里都可以用,使用网络硬盘或者移动U盘来回复制都不方便。

最后觉得还是GoogleDocs方便,打开速度比Word快,编辑和显示比Notepad好。更重要的是,不用来回复制了。

而这样也便于随时记录一些东西,可以保持思维的连续久而久之,可以整理出很多清晰的思路,形成生产力:-)。

GoogleDocs自身提供了Full-screen mode(Ctrl+Shift+F),与浏览器提供的Full-screen mode(F11)结合使用,可以提供强大的全屏功能,可以让你将心思全部花在写文档上,不用去理会各种IM和Web等容易分心的内容,解决了在线编辑的各种弊病。

下图是整屏的截屏,还是比较清爽的,不是吗?

google_docs_edit_ui

鉴于CSS(Edit->Edit CSS)的强大,GoogleDocs为用户提供了容易使用的模板功能。对于有自己喜好风格的用户,简单的几行CSS就可以将文档格式梳理的很漂亮。简单的文档风格还可以设置为默认模板(Format->Document settings)。

google_docs_css_edit

google_docs_document_styles

这只是我所在意的关于GoogleDocs的Document的几点。至于GoogleDocs对Office的Word、Excel、PowerPoint及Pdf格式等的支持,这里就不一一给出了。对于我来说,一个在线的文本编辑正是我想要的。

唯一不足的是,GoogleDocs的快捷键还不够丰富。如果有一天能够完美支持Vim或者Emacs习惯的编辑,甚至是直接编辑代码、编译程序、运行调试……就堪称完美了。

令人期待的Chrome OS是不是可以令这一目标实现呢?

这几日额外做的一点事情就是在Cygwin下将整理的一些代码封装成一个静态库,搭建公共环境,并通过SVN管理代码,在这个过程中确立一个必要的统一编程风格,为后续工作做准备。

我一般只是用浏览器浏览网页,很少在线看视频之类的,平时用Chrome的时间居多,Chrome的书签、页面元素审查和下载管理是我最常使用的功能,Chrome的进程拖拽模式也比较舒服。

但Chrome一直有几个软肋:

o 不(被)支持电子银行;

o 不(被)支持金山词霸(连谷歌金山词霸都不支持,真是极大的一个讽刺,谷歌和金山的工程师们任重道远啊);

o 很多花哨的网络应用在UI上(被)支持都不够好;

o 另一点不爽的是:像cygwin下很多文本文件没有后缀名,可以用IE打开,却无法直接拖到Chrome里面打开。

而IE一直是(被)支持的(毕竟是占有率第一的浏览器),但我不喜欢IE(纯属个人情愫):

o 6.0的时候缺点海了去了;

o 7.0不支持我常用的动态缩放(放大后不能动态调整文本,水平滚动条影响阅读);

o 我更喜欢Google和它的产品,Google给我的感觉就是:不把用户当弱智。

现在8.0支持动态缩放了,我还是会安装一下。当然8.0有一个加速器,做的感觉还是比较人性化,而且明显是针对中国市场和Google系进行对抗,别忘了,MS有一个Live系。

——————————-

随便写了一点,主要是因为: Windows 版 Chrome Dev 升级 4.0.201.1,增加书签同步功能!


fox

原由 yulefox 上載

决定以后什么头像啊、Logo啊,就全部使用这个图片了。

使用flickr管理图片还是蛮方便的,终于知道为什么那么多人选择flickr而不是picasa了。

大成网前两天发了一篇以《文化部今日通过魔兽世界—巫妖王之怒审批》为题的新闻,太扯蛋了,关心WOW的同学都知道,这次审批的是TBC,不是WLK。

如果编辑是真不懂,这职业素质也太差了;

如果编辑是装不懂,这职业素质还是太差了。

就算是你妈没喊你回家吃饭,也不要欺骗大家的感情吧。

正像有人说的:如果你文笔很好,请不要做记者;如果你有正义感,请不要做记者;如果你不想变成一只枪手,请不要做记者;如果你禁的住诱惑,请不要做记者;如果你不会撒谎,请不要做记者……如果你不具备上述条件,请你做记者。

果然,我看好你哦。


@李开复把自己用了很久的iPhone丢了(丢给他女儿了),改用GPhone了。

虽然一起很喜欢Apple的产品,却没有任何一样Apple的产品,也没有关注过Apple的开发平台。

当然,即使一直在用Google的产品,却也没有关注过Google的开源项目。

看过很多GPhone效果图觉得还不错。我看好Android。

Web 1.0和Web 2.0的区别是什么?

依我的亲身体会来说,那就是Web 2.0的普及速度比Web 1.0要快的多的多,Web 2.0的互动力度比Web 1.0要大的多的多。

我第一次上网(2001年)距WWW出现晚了12年(这还不考虑1969年出现的互联网的前身ARPANET);

我第一次应用Web 2.0(2004年在红袖添香网站发文章,写日记,可惜的是,现在连密码都记不起来了,如果这不算的话,那么2006年开始在搜狐和讯CSDN开始写blog应该算了)距Web 2.0概念的提出晚了7年。

刚大学读书那会儿挺傻的,以前没用过计算机,更没有上过网。依我们高中老师和我被熏陶出来的价值观:上网、聊天、打游戏都是坏孩子做的事情,我不是好孩子,但也绝对不想做一眼就被看穿的坏孩子。

因此即使跑网吧上网(寝室还没有电脑)也是去敲C代码(有同学为证)。

1. 2001年10月,第一次上网(一直在敲代码);

2. 2001年10月,有了第一个QQ号码(一直在用);

3. 2001年10月,有了第一个邮箱(好像是Yahoo!?,显然没有在用了);

4. 2002年10月,自己学着做网页(当时名噪一时的网页三剑客);

5. 2004年10月,在红袖添香网站发文章,写日记;

6. 2005年10月,拥有GMail账号(yulefox);

7. 2006年02月,开始在搜狐写blog(2007年11月止);

8. 2006年06月,开始在和讯写blog(该年7月底止);

9. 2006年12月,开始在CSDN写blog(2007年7月止);

10. 2007年12月,开始在C++博客写blog(2008年7月止);

11. 2007年12月,开始大规模使用Google应用,生活、学习、工作,无处不在,个人全面进入Web 2.0时代;

12. 2008年10月,申请第一个域名(http://www.yulefox.com/);

13. 2008年11月,拥有Twitter、饭否、叽歪等SNS账号(六度分隔理论);

14. 2009年07月,开始有意识的主动关注互联网发展,而不仅仅是加入成熟应用。

当然,我对于互联网领域(尤其是Web 2.0)的大多数的关注,源于对朋友的关注(尤其是Fallhunter),而这,似乎正是Web 2.0(更确切的说是SNS)的本质所在。

Web 1.0时代,对于互联网用户,有一个很传统的名词叫『受众』,很好的表达了用户是在被动的接受信息。虽然这种被动相比传统媒体有了更大的自主性,比如我们有搜索引擎可以使用。表面上看,这似乎给了读者更多选择的权利,但每个页面中,却有看更多的信息是我们本来没有意愿去关注而延伸阅读下去的。这种方式极大程度上满足了信息提供者的商业/非商业诉求,却强加给读者太多不必要的成本。哪怕是搜索引擎也丝毫没有减少(甚至是加剧了)这种成本的扩散。

后来的BBS、IM(包括各种群功能)、社区虽然在针对性、专业性和交互性上有了很大提升,却依然没有避免各种『噪音』对用户的烦扰,我们最后甚至会极力反对IM中提供的群功能

现在的Atom、RSS、Twitter给我们提供了更友好的选择。用户可以随心所欲的订阅自己关心的信息,可以畅所欲言的发表自己的观点,『基本』不会打扰到这个世界本来的『清静』,因为其它用户也有同样的权利。在Web 2.0的世界中,你既是信息的受众,也是信息的主宰。之所以说是『基本』,是因为即使是爱好取舍再接近的两个人,你也无法保证你所写的每一篇文章,说的每一句话,对方都会需要。然而,目前我们暂时不只有选择/不选择源的权利,还无法智能的判定每一条信息是否是受众所需要的。

不管怎样:

Web 1.0将地球变成了地球村,却没有考虑你是否能与周围的邻居友好的相处;

Web 2.0将地球村变回了地球,六度分隔理论在还你同一个世界的时候,并没有忘记你周围需要有哪些邻居,虽然不是总是。


PS: 推荐一下,friendfeed,将Web 2.0一网打尽。