我喜欢爬山，喜欢一个人爬山的感觉，在爬山的过程中试探着自己身体的极限。
山是神秘的，你不知道密林的背后有什么，想象着山的背后是什么。我总相信在下一个路口能看到别样的风景。在山顶远眺，犹如局外人一样俯瞰这平日生活的俗世。
自从到了杭州后，每年都有去一次黄山，今年已经是第五次了。也不是对黄山有什么特别的感情，只是一路看过来，杭州周边实在没有什么比黄山更值得去的地方了。
和相爱的人一起旅行本是一件幸福的事，却因为一些工作上的事搞的有些心不在焉，黄山的奇秀开始变的普通。忽然间对黄山已经有些厌倦了，除特别的原因外，至少在最近几年我是不会再去黄山了。
下次可能会去泰山。虽然对泰山无感，虽然泰山有些远，虽然泰山有些矮（黄山海拔18xx，泰山海拔15xx）。
在狮子峰北一座平顶的山峰上，有一巧石，如猴蹲坐，静观云海起伏，人称“猴子观海”。有诗曰： 猴子观海“灵猴观海不知年，万顷红云镶碧天。坐看人间兴废事，几经沧海变桑田。”（感觉这诗烂了点）当云雾消散后，石猴又如在远眺太平县境（即今黄山市所属黄山区）的绿野平畴，故亦名“猴子望太平”。
受国内的网络环境限制，直接使用python官方的pypi源速度不稳定还经常抽风。对公司来说，搭建一个自己的pypi镜像非常有必要。
| 方案 | 优点 | 缺点 |
|---|---|---|
| PyPiImplementations | 功能强大，提供用户注册、包管理等各项功能。 | 配置复杂，需对pypi源进行全量同步。全量同步速度慢，且经常失败。 |
| PyPiImplementations Simple repository with fallback using Apache | 配置相对简单。可通过ftp等方式实现私有包的管理。增加反向代理缓存后可实现官方pypi源的加速。 | 部分python包只是在pypi上放了一个链接，真正的包放在自己的服务器上（极少数包），对这类包无法通过反向代理进行加速。 权限管理功能稍弱。 私有包需要通过ftp等方式进行管理。 注：私有包管理的问题可通过安装web版的文件管理工具来规避。 |
考虑到部门内部pypi镜像的需求简单，不需涉及太多权限功能方面的工作，建议使用“Simple repository with fallback using Apache”方案。
“Simple repository with fallback using Apache”中只是将本地无法处理的pypi请求直接转发到官方pypi源。在对官方源进行同步时无法实现对官方pypi源进行加速。为解决该问题，需要对官网的请求进行反向代理并缓存。
关于反向代理的支持请参考：代理、反向代理知识普及squid apache-mod_proxy lighttpd nginx
squid是老牌的反向代理服务器，但在实际使用过程中发现squid太过强大的功能导致配置复杂，不推荐使用。
nginx发展迅速的新兴服务器，对反向代理提供良好的支持，并被多家大型网站使用。最重要的是nginx的配置比squid要容易太多。
proxy_cache_path /var/lib/nginx/cache/ levels=1:1:2 inactive=24000h keys_zone=cache:100m;
server {
listen 8000 default;
server_name localhost;
access_log /var/log/nginx/localhost.access.log;
#中间省略部分默认配置
location /pypi {
proxy_pass http://pypi.python.org/simple;
proxy_cache cache;
proxy_cache_valid any 2400h;
}
location /packages {
proxy_pass http://pypi.python.org/packages;
proxy_cache cache;
proxy_cache_valid any 24000h;
}
}
最后我的意见是:
google 20%业余时间这个想法非常的棒，很有借鉴意义。如果条件允许，公司都应当有些试探性的“非正式项目”。项目来自民间，项目的发起人可利用自己的影响力、 人脉来吸引团队成员（注：团队成员主要出于兴趣，而非领导的强权）。作为“非正式项目”，以不影响正式项目为前提，不过分强调项目产出。项目“万一”成 功，需要有相关的奖励。
一大早发现自己的博客访问不了，这才想起前段时间webfaction有发送邮件说要换IP。
切换服务器后感觉速度快了不少。当然，也不知道是否是心理作用。
利用twitter/bootstrap，项目的基础模板算是顺利搞定。接下来开始处理用户中心。
用户中心主要包括用户登陆、注册以及头像等个人信息维护。此前，用户的注册管理我一直使用django-registration。只是这个APP有些不思进取，09年发布了0.8alpha版后就一直没什么动静。这次决定尝试另外一个用户模块组件django-userena。
相比django-registration，django-userena的功能要完善的多。除基础的登陆注册模块外django-userena甚至还带了站内消息功能。django-userena的易用性方面也做的非常的不错。django-userena自带了默认模板，并有提供一个完整的演示项目，让你可以轻松上手。这里有个官方的在线demo，感兴趣可以去看看。
我们自然是希望所有的APP不用做任何修改，拿来就能用了。不过事与愿违，在整合的过程中多多少少都会遇到一些问题。django-userena默认的模板在项目中显示的非常难看。我们需要重写django-userena的默认模板，并且用django-bootstrap来生成form。
forms.py
#为原始form添加BootstrapMixin
from bootstrap.forms import BootstrapMixin
class BsAuthenticationForm(AuthenticationForm, BootstrapMixin):
def __init__(self, *args, **kw):
super(BsAuthenticationForm, self).__init__(*args, **kw)
self.__bootstrap__()
urls.py
#重写urls，指定使用的form
from django.conf.urls.defaults import *
from userena import views as userena_views
from profiles.forms import BsSignupForm, BsAuthenticationForm
urlpatterns = patterns('',
url(r'^signup/
同django-admin一样，django-userena也无法使用中文进行注册。对于一个中文网站而言，不能使用中文注册ID似乎有些太不合理的。
django-userena使用正则表达式对用户名进行校验，重写注册form修改认证规则即可取消该限制。
USERNAME_RE = r'^\S+
, userena_views.signup,
{'signup_form': BsSignupForm}, name='userena_signup'),
url(r'^signin/
同django-admin一样，django-userena也无法使用中文进行注册。对于一个中文网站而言，不能使用中文注册ID似乎有些太不合理的。
django-userena使用正则表达式对用户名进行校验，重写注册form修改认证规则即可取消该限制。
USERNAME_RE = r'^\S+$'
attrs_dict = {'class': 'required'}
class BsSignupForm(SignupForm, BootstrapMixin):
username = forms.RegexField(regex=USERNAME_RE,
max_length=30,
widget=forms.TextInput(attrs=attrs_dict),
label=_("Username"),
error_messages={'invalid': _('Username must contain only letters, numbers, dots and underscores.')})
def __init__(self, *args, **kw):
super(BsSignupForm, self).__init__(*args, **kw)
self.__bootstrap__()
项目地址：https://github.com/vicalloy/timeline-site
感兴趣的朋友就过去关注下吧。
目前还只有一个项目框架，并对基础的模板做了一些调整。因为是自己一个人写，且没人督促，所以项目前期的重构会比较频繁，且项目进度不可控。
下面就是刚的工作成功，一个简单的首页框架。
没心情干什么正事，又不想太过无聊，于是只好写日志了。
2011年是忙碌的一年，前半年忙到把不少负面情绪都带到了工作中，到下半年才开始逐渐好转。2011年不算糟，却也不能让自己满意。或许是自己有些太过急功近利，有着太多的期望。
对2012的期望很简单， “少写些代码”。
这里的“少写些代码”和写代码写多少并无多少实际关系。我希望在这一年中，除coding外能多接触、多做些“有趣”的事。
人们很容易将“善于做的事 ” 同“喜欢做的事”混到一起，以为自己擅长的就是自己喜欢的。在很长的一段时间内，我认为自己喜欢的是编程，并以成为构架师为目标。在去年我开始了解到，我真正的兴趣和技术并无太大关系，我感兴趣的是如何做出让广大用户欢迎的软件产品。就如@Livid说的一样，技术只是做出优秀产品的因素之一，而且并不是唯一（忘了原话是怎么说的）。我业余时间写的那些小东西（虽不够成功）也多出于问题的解决而非技术的探索。
心怀希望，直面世间的无奈。
前些天在日志里说想做个timeline相关的网站。由于最近的琐事较多，也是出于惰性，迟迟没有动手。想最近还是先将项目启动好了，然后在blog上记录项目的过程。记录的过程，一方面是方便日后的总结，令一方面多少也有些督促作用。
很早以前就想做一张古今中外的大事年表，看中国历史上的同时期国外都发生了些什么事。对于普通的文字列表而言，timeline的展现方式无疑要直观很多。在寻找timeline工具的时候没有发现好用的。到了现在，已经出现不少在线timeline工具了，不过中文的还没有，既然如此那就自己做一个吧。
timeline功能有些过于单一，可发掘的余地不会太大。不过换个角度看，做一个有价值的小众服务也不错。
这会是一个类似维基百科的网站。大家可以在上面察看、制作自己感兴趣的timeline。网站支持多人协作，可以多人共同维护一个timeline。timeline支持评论。用户可以将自己感兴趣的timeline做个列表（类似豆瓣的豆单）。如果用户活跃的话甚至可以考虑增加小组的功能。
网站创建初期最需要的是基础内容以及第一批核心用户。内容方面会自己做几个timeline并进行社会化分享。针对目标人群的不同会将timeline分为明星偶像、社会化事件、历史、技术类（如js的演化）。然后看目标人群的接受程度再做适当的调整。
服务端采用django。UI方面采用twitter出品的bootstrap。
除此之外令一个重要的问题是如何实现timeline的展示。网上不少timeline的js实现。经过调查后决定采用timeglider。下面是入围JS库的介绍。
既然此类网站已经有了，必要的参考自然少不了。
古老的帝国在惯性的作用下看似平稳的正常运行。当时的人们应当无法预知，此时的帝国即将走到它的尽头。
《万历十五年》是本有意思的书，回顾历史，看明朝是如何轰然倒下，看当时社会精英们的努力与挣扎，看中国如何一步步走成现在的样子。
团队中应当有个红脸。永远是激情澎湃，自信满满，有打倒一切困难的决心。所有问题在他看来都不是问题。他是团队的精神支柱，让团队在逆境中看到希望。
团队中也应当有个黑脸。他是不时给大家泼点冷水，给人以反思，让团队不至于太过自我感觉良好而迷失。
只是红脸在催眠别人的时候也催眠着自己，明明是死胡同却视而不见，义无反顾的撞上去。
黑脸的抱怨一不小心也容易变成纯粹的抱怨。抱怨到让人心灰意懒，连抱怨都懒得抱怨。