团队中应当有个红脸。永远是激情澎湃，自信满满，有打倒一切困难的决心。所有问题在他看来都不是问题。他是团队的精神支柱，让团队在逆境中看到希望。
团队中也应当有个黑脸。他是不时给大家泼点冷水，给人以反思，让团队不至于太过自我感觉良好而迷失。
只是红脸在催眠别人的时候也催眠着自己，明明是死胡同却视而不见，义无反顾的撞上去。
黑脸的抱怨一不小心也容易变成纯粹的抱怨。抱怨到让人心灰意懒，连抱怨都懒得抱怨。
团队中的红脸与黑脸
1条回复
最近想做的一些东西
由于长期的挖坑不填，于是想做简单一些的东西，简单到一周之内可以完成。
WP7的虾米电台客户端
虾米的电台很不错，有多种风格的电台可以选择。选择一个自己喜欢的电台然后有啥听啥，比自己选歌来的方便的多。目前虾米有官方的ios、android的客户端，wp7的客户端暂时还没有。虽然手机可以用网页版的虾米，不过网页版无法后台播放将是一个很大的缺陷。
我还没有wp7的手机，想做着东西主要还是想体验一下wp7开发。
timeline在线制作
世界历学的很烂，完全不知道国外的重大历史事件对应到中国的朝代。想做这么一张历史年表，将国内外的大事件都标记在上面。顺带想做一个关于timeline的网站。用户可以制作自己的timeline并进行分享。最好还可以象wiki一样大家共同编辑同一个timeline。
前期会做的很简单，只有简单的创建和展示功能。评论功能直接使用disqus实现。
目前国外网站已经有一些提供在线timeline服务的网站。里面大多网站都面向企业用户提供收费服务。其中比较接近我想法的是xtimeline。
吐槽审美品位
Django数据库迁移组件（South）
django提供syncdb命令，用于从models自动生成数据库。但在models结构变化后，syncdb并无法自动实现数据库的更新。South
组件即是为了解决该问题而出现的。
下面简单介绍一下South的一些最常见用法，更详细的使用方法见South的官方手册。
假设我们创建了一个名叫southtut的app
- 生成初始化数据库的south脚本。允许上述命令后将在对于的app目录下生成 migrations目录，south的数据库迁移脚本即保存在该目录。
./manage.py schemamigration southtut --initial - 在所用south后，syncdb命令不会为使用south托管的app生成数据库。migrate命令用于执行south的数据库迁移脚本， 实现数据库更改。在这里执行的操作是为southtut创建相关的数据库表。不带app名字时，将对project中的所有app进行migrate操 作。
./manage.py migrate southtut - 在很多应用场景中，我们已经用syncdb将数据库给创建好了。这时候运行上面的migrate命令将会提示相关表已经存在，命令执行失败。这 时候我们需要告诉south需要跳过某些migrate操作。上面的命令将告诉south，系统已经执行过了0001号数据库迁移脚本。
./manage.py migrate southtut0001--fake - 接下来我们对models进行了某些改动，修改后增减了某些字段。
- 该命令将自动生成数据库的迁移脚本。在migrations目录下可以看到新增加了文件0002_xxx.py，该文件即是此次models改 动的数据库升级脚本。打开文件后可看到其中有一个类Migration，类中有两个方法forwards和backwards。这两个方法分别实现数据库 升级和会滚时对数据库的操作，具体指令的含义参考south的数据库API。
./manage.py schemamigration southtut --auto - 应用models的改动到数据库
./manage.py migrate southtut
[苍蝇一分钟的生命]向左走，向右走
在豆瓣上看到有朋友给这短片打出五分的高分，还将自己的签名给改了。
第一次看完时有些莫名的压抑。苍蝇在一分钟的生命中完成了所有的TODO-LIST，看似充实却也无趣。生活是一种体验，TODO-LIST只是生活的一部分，而不是全部。
上豆瓣翻看了些影评，发现大家对这短片的看法体现出两个极端，“励志”和“讽刺”。一花一世界，不同的看法折射出不同的人生观。
追寻梦想的同时不要被梦想所束缚，是我在看过短片后写的影评。不知你看过这短片后的体验会是怎样，是向左，还是向右。
追寻梦想的同时不要被梦想所束缚
如果这是一部单纯的励志短篇，我会毫不犹豫的打出低分。
人生或许没有任何意义，但既来之则安之。
生活或许平淡，但未知的未来多少还有少许的期待。
长长的TODO-LIST看似承载着所有的梦想，却是绑架了梦想。
在马不停蹄完成TODO-LIST的同时你是否可曾停下脚步好好欣赏这个世界。
追寻着梦想，不要被梦想所束缚。
在平淡的生活中追寻那偶尔出现的色彩。
附：
- 豆瓣地址
- 在线地址
- 认为是讽刺的影评：我以为是励志，原来是讽刺
- 励志的影评：写下你的梦想 实践你的梦想 【10000小时梦想时间管理法】
肉食者鄙，管理中的上下级矛盾
不少领导喜欢以亲民的姿态出现，但成功的不多。表面上其乐融融，逾越不了上下级关系的事实。上下级的关系决定了某些事情上不可能做到完全的平等。
古人云：”肉食者鄙，未能远谋”，一定程度上也可以理解为上下级间矛盾。
作为领导需要有一定的权威，但权威也常是上下级矛盾的来源。大家都不笨，为什么要听你的？
- 专业方面的权威
- 这里说的专业是一个很泛的概念，其中包括，技术能力、经历、以及管理者的人格魅力。下属认同管理者的看法和决策。
- 职位方面的权威
- 在某些时候专业性权威无法解决问题时就需要动用到职位的权威，即官大一品压死人。需要动用到职位权威，可能是认识不同，惰性，或其他方面的问题。不管是什么问题，职位权威都不应当经常用到。就如《Fate/Zero》中的令咒，虽然可以让对方强制服从，但副作用严重，用多了只能一拍两散。
道家主张的“小国寡民，无为而治”。按照我的理解就是，建立一个简单的规则，然后让各自自由的发挥自己的长处。
- 要实现这个目标首先大方向一致，不然没有达成共识的可能，其他的事也就无从谈起。
- 了解自己优势，知道自己擅长什么，哪些事情可以管，哪些事情需要放权。明确界限，尽量做到不踩线。
- 另外就是自律。说永远比做容易，所以很多管理者都喜欢说。如果无法做大以身做责，则对他人的一切要求也都将变的没有说服力。
收到SAE的开发者证书了
前段时间SAE开始分发python的内测名额，一时手慢，错过机会。不过倒看到SAE可以申请开发者证书。申请资格中写有开源作者可以申请高级开发者证书。由于错过内测名额，所以就有啥拿啥吧。
感觉SAE的这次营销策划想法非常的好。可以花很少的钱就可以做到不错的推广效果，最重要的是还能得到一个皆大欢喜的结果。
PS：
申请一个SAE证书还是有些好处的。申请成高级开发者后，每年可以有￥1800的免费SAE资源可以使用。
完美的团队
37signals的伟大在于，他们本是一个“不求上进”的小公司，却在一定程度上改变了世界。他们创造的ROR在更新了人们对web开发的认识。他们出版的《rework》影响了广大的创业者，很多创业者都希望以37signals为模板来打造自己的团队。
要打造类似37signals的团队不容易，甚至不太现实，但毫无疑问的是37signals是一个迷人的团队。
有时在想一个完美的团队应当是怎么样的。
- 没有管理者，同时每个人都是管理者。
- rework？中提到每个人都得干活。团队本来就小，如果这时还有人专职指手画脚的指挥别人工作，那会是让人非常反感的。 团队的每个成员都应当主动的承担部分管理方面的工作。在重大决策上大家一起讨论达成共识。尽量保证每个重大决策都是团队的决定。
- 每个人都是"全才"，同时也是某方面的专家。
- 每个人都需要对其他人的工作有充分的了解，在相互了解的基础上才能更有效的沟通，才能提出合理的建议。
- 成员间的技能互补，才能更有效的发挥团队的力量。在某些问题无法达成共识的时候，也可以由这方面的专家来做最终的拍板。
GVIM同VIM的区别
从我用vim以来就一直用的是gvim。gvim和vim的功能完全一样，但少量细节上的差别还是让我决定使用gvim。
- 光标 vim下常规模式和插入模式下的光标都一个样，让我非常的不习惯。特别是在括号匹配的时候常让我不知道哪个才是光标。相比而言gvim编辑模式下的竖线光标则要直观的多。
- 颜色 vim只能显示256色，gvim可显示的颜色则要丰富的多，因此gvim的代码高亮会比vim更好看些。
- 菜单 可能是受windows的影响深远，部分时候我还是需要用到gvim的菜单。
合理的组织django的settings文件
django在一个项目的目录结构划分方面缺乏必要的规范，因此不同人的项目组织形式也千奇百怪，而且也很难说谁的做法就比较好。我根据自己的项目组织习惯，发布了一个项目dj-scaffold。
前些天在reddit上为我的项目dj-scaffold打了个“广告”（见：http://redd.it/kw5d4）。不想评价甚糟，甚至差点被打成负分。其中更也人将这个项目说的一文不值。面对负面声音虽然会有些不爽，但其中的建设性意见还是需要听取的，至于那些纯属个人偏好部分就自动过滤了。
在谈及settings文件如何组织时，coderanger建议参考The Best (and Worst) of Django中的做法。文中的主要观点是开发环境和生产环境的配置都需要放到VCS中进行版本控制。参考文中的做法，我对settings模块做了部分调整。注：代码 https://github.com/vicalloy/dj-scaffold/tree/master/dj_scaffold/conf/prj/sites/settings
local_settings的弊病
为将项目的默认配置和本地配置区分开，最常用的做法是增加一个local_settings.py文件，并在settings文件的最后对该文件进行import。
try:
from local_settings import *
except:
pass
由此引发的问题是你不能对local_settings.py进行版本控制，部署环境的配置万一丢失将难以找回。
解决方案
针对该问题，建议的解决方案如下
合理的配置文件组织方式
|~settings/
| |-__init__.py
| |-base.py #默认配置信息
| |-dev.py #开发环境的配置
| |-local.sample #本地的扩展配置在dev和production的最后进行import
| |-pre.sample #设置当前使用的配置为生产环境还是开发环境
| `-production.py #生产环境的配置
使用方式
DJANGO_SETTINGS_MODULE
django的admin脚本提供了settings参数用于指定当前使用的配置文件
django-admin.py shell --settings=settings.dev
在wsgi脚本中则可直接设置需要使用的settings
deploy.wsgi
os.environ['DJANGO_SETTINGS_MODULE'] = settings.production
简化参数
当然，如果每次使用django-admin.py的时候都要带上settings参数还是非常恼人，所以推荐的做法是在pre.py中配置自己所需要使用的配置文件。
SETTINGS = 'production' #dev