在微博上被 @MarchLiu 老湿点名了冰书挑战，我正好可以仔细的想想这些对我影响大的书

• 晃晃悠悠，book.douban.com/subject/1047851/
• 大教堂和集市，book.douban.com/subject/25881855/
• Unix 编程艺术，book.douban.com/subject/1467587/
• 失控，book.douban.com/subject/5375620/
• The Lean Startup，book.douban.com/subject/6779576/
• Doom 启示录，book.douban.com/subject/1152971/
• 黑客与画家，book.douban.com/subject/6021440/
• 软件随想录，book.douban.com/subject/4163938/
• 激荡三十年，book.douban.com/subject/1970428/
• 异类，book.douban.com/subject/3688489/
• 理解媒介，book.douban.com/subject/6391212/

这11本书，都是在我阅读之后都好像打开了另一种思维方式的书。基本上是按照时间顺序排列的。

另外，还有一篇文章对我影响很大，就是《提问的智慧》

现在获取知识的主要途径是 Google，但是这都是定向的知识获取，而非定向的基本上只能是从跨界的人那里听来的书。

下一步想读的书主要集中在一些人文历史和典籍方面。

其实非常想有一个互联网产品，能够让我知道我欣赏的那些人，他们正在阅读什么，不仅仅是书。

To setup development environment is not easy.  Especially for server side, lots of dependency, same library in different version often act different. If you are just join into a new team and you have to use lots of libraries, frameworks, means you have to use lots of time to deal with them in detail stuffs. Using google, mail list, forum, ask others (and maybe them don’t know), cost you lots of time and make yourself upset, unhappy, angry.

I use vagrant to deal with this case.

What’s vagrant? OK, FINE, www.iwgtfy.com/?q=vagrant

Technically, vagrant is a virtual machine management tool, means vagrant can help you to build a environment from scratch, package and ship.

I will brief explain how I am using vagrant from scratch, cause it’s document is so nice.

1. Install a clean OS. Download a new vagrant clean box file from www.vagrantbox.es, using vagrant init to install. I choose Ubuntu Server 12.04 (LTS)
2. Log into vagrant to install basic libraries, for me install MySQL, Apache2, Django, django-plugins and so on
3. Prepare your code base
4. Logout vagrant, using vagrant package command to build your own library installed box file
5. Ship this file to new guys, let him use vagrant init and setup the new box in 10 minutes
6. Done, he’s already have the whole tool chain to hacking

In here, on step 3, I am not put code into vagrant managed virtual machine. I am using vagrant sync directory to make code base both available in virtual machine and local computer. The reason is VirtualBox’s IO performance is not good, hacking code (via git or some other tools) on local machine is easy and quick. Beside, I can make my vagrant box file holding on a public place (such as s3 or dropbox), and pull my private code into local machine, safe, security, fast, works well.

Till now, it works find. But still some issues. How to make every existing on vagrant environment upgrade libraries and dependencies?

I am not done with this, but I find the answer, using Puppet.

Making the whole thing together, I use git. Make a project, every configuration file, setup script all put here, then holding by Github. Every time upgrade for dev environment, just using git pull and vagrant provision is enough.

Things I can improve,

• Using Puppet to manage every libraries and configuration file, both using on vagrant and production server
• Using Fabric writing remote control script send command to vagrant and production server
• Using virtualenv to manage python code
• Improve vagrant automatic setup script, avoid wget command, cause Mac OS X doesn’t install this by default

It works so well, and I running this for a new guy, using 17 minutes, wonderful.

先给大家说一个真实的故事： 有一个少年（也许是中年吧）在10年就购置了全套的水果设备，信誓旦旦的说要进行爱疯开发。他也尝试着喊出了『你好世界』，也真的把这个口号部署在了机器上。
然后，然后就没有然后了。
虽然我们知道有很多的因素造成了到现在世界都没末日的时候他还没能拿出一款应用，但是其中一个不可忽略的因素就是对未知的知识领域的恐惧，这种恐惧让他始终也没能认真的跨出有效的第一步。

嗯，对，那个骚年就是我。我就是学习了三年的iOS开发，也没学会的那个白痴。
与其说没学会^[1]，倒不如说从来没真正的踏出那一步。我们知道，想跨进一个成体系的知识领域是比较困难的，尤其是第一步。如果我们无法保持对这个知识的足够频繁的接触，则知识无法沉积，不但不会学到新的内容，而且还容易把已经学过的很多内容遗忘。在接触中，也不能是眉毛胡子一把抓，否则涉猎的知识点太广切分散则毫无关联可言，也是意义不大的。我们要的是找到河对岸的一条路，而不是踩过岸边的所有碎石。

一般要跨入一个全新的领域，我觉得有两个方法。一个是找到足够多的时间，全面的去学习这个领域的点滴；另一个方法是使用这个领域的知识去完成某一个目标，在达成目标的同时学习领域知识。 第一种方法学的更加的扎实，而且在实践中会给出『对的』解决方案，坏处是时间长，而且在学习的过程中没有足够的阶段性的产出作为对自己的刺激，更适合在学校、实验室等地方进行。 第二种方式会不断的有阶段性产出，不断的刺激学习者让学习者能够持续的保持对领域的渴望。当然坏处也是很明显的，就是由于一路突进式的学习，导致很多的实现方式往往是『凑合』出来的一些解决方法，而且容易留下各种隐患（这种隐患完全因为对系统的『无知』而无法避免）。

其实我们几乎每次在这种时候都是按照第二种方式去进入一个全新的知识领域的，不管是学习一个新的技术，还是新加入一个公司/项目。我们都或主动或被动的要求在一个给定的时间点去完成什么目标，也就是我想说的『在构建中学习』。

我们应该如何跨出第一步，并且在构建中学习呢？

1. 给定一个目标，让自己去完成一个达到足够好（Good Enough）质量的任务。
   很多时候并没有走出第一步是因为我们还没有一个明确的目标，这个目标不用很大，但是要明确、可达、有监督。
   明确：意味着这个目标是没有歧义的去完成一个明确的任务，而且是可以度量的
   可达：意味着这个目标不能是高不可攀的，一定要在一个段时间内可以完成
   有监督：这个至少对我很重要，我经常是下定决心然后不了了之，其实就是找某种方法监督自己一定把这个任务完成比如我一直想要开始 Mac/iOS 的开发，但是一直没能展开下去。直到我参与了我的一个小兄弟 @lovekonakona 发起了一个Mac下番茄工作法的应用 TomaTodo 。在这期间，我们对目标进行了上述的分析
   明确：只做一个可以计时的功能，工作25分钟，休息5分钟，到时间给提醒，工作中可以选择是否有滴答声。
   可达：这个任务是可以实现的，因为总的工作量就三个大点，计时、Notification、播放声音
   有监督：我俩相互推荐开发，互为监督。
2. 利用已有的知识去推测可能隐藏的细节。
   虽然是进入一个新的知识体系，但是也会有一些方面和我们已经掌握的知识能够相互映射。我们可以利用自己的知识储备去快速的理解新的知识。在这过程中应该不断的去仔细体会一些细节的地方，去想为什么这些地方要这样设计，因为往往细节都是全局的延伸，而且是初期最容易接触到的。
   在这里要求我们就是敏感一些，多问一个为什么。在 TomaTodo 的开发过程中，遇到了 NSRunLoop、NSTimer、Notification Center 等 OS X SDK 的概念，也遇到了比如什么叫做 Target，怎么做一个应用的发布等基础概念。
   每个点想要『凑合』的完成并不难，但是明白了一些变化，为什么这样设计等问题工作量就会大好几倍甚至一个数量级。往往我们是被这些庞杂的概念吓倒或者干脆跳过去，但是想深入的研究 Mac OS X 开发，这些就必须下功夫仔细的研读相关文档。
3. 寻找最佳实践，并给定一个新目标，重复1
   在经过一些思考和熟悉之后，我们往往会发现之前的实现方式其实是比较麻烦、性价比低甚至是南辕北辙的一种方式。那么就去优化这个方案，让她更加的『合理』。同时一定会有新的需求等出现，让我们再重复1。这期间，我们对代码进行了多次小规模重构，其实都是因为之前对一些概念的理解偏差或者是实现的并不合理，当然就更别提什么『优雅』了。然后我们定了新的功能点，继续回到第一步开始边构建边学习。

如此往复，我们会在一段时间内推开新知识的一个门缝。不断的修炼自己，就能达到一个『术』的层面，可以开始利用新知识工作了。但是想要达到『道』的层面，还需要大量的实践和经验了。而且根据自己的情况，也可以给自己一些稍微挑战的任务，这样进步的也会快一些。

注： [1]，学会是指能够掌握这个领域的知识，并做到对一些问题的举一反三。而不仅仅是能够理解和看明白一些专业内的东西。

• 体重增加20斤，10斤为及格
• 在豆瓣做成一件事儿
• 在豆瓣外做成一件事儿
• 给自己买一辆车，至少是能跑高速的
• 运营好《背包电台》，目标是2013年度新播客
• 看25本书，平均每两周一本
  • 经济类
  • 历史类
  • 新闻传播类
• 看50部电影，平均每周一部
• 去一个以前没去过的地方
• 每周至少1小时德州
  • 目标从新浪打到PS
• 坚持体育锻炼，每周至少一次足球或者游泳
• 每两周坚持写一篇文章
• 生活有规律，让家里不像一个垃圾宿舍

具体的用法请自行google。

这里就说一句，lftp用mirror命令全部Clone ftp server，这个功能就牛爆了。

昨天写了多半年的第一篇Blog，为什么选择git作为版本管理工具 。从微博和blog上收到很多反馈，我在这里做一个统一的补充。以Q&A的形式出现。

Q：SVN为什么对并行开发支持不好？
A：因为下面这几个点导致的

• 不支持离线版本提交（最新版我不知道）
  • 每次提交都需要和服务器进行交互，只要有代码交换就有冲突的风险。这时候一旦出现冲突则必须解决，但是这个是被动的，不自愿的，他会使你从当前的任务中抽离出来去解决冲突。
  • 如果当前我没有可以联通服务器的网络环境，那么我就无法提交代码。这样对于一个稍大一些的功能，就必须一次性的开发完成才能提交，而无法在中途有几个关键节点的提交作为管理、存档。
• 不支持轻量级分支
  这就决定了创建、销毁分支的代价比较大。不是不可以，而是不如git那么自然。
• 分支合并的问题
  见下一个问题

Q：SVN的分支合并有问题？
A：有问题，而且问题很大。

SVN的分支模型是比较奇怪的一种方式。SVN的分支、Tag都是采用拷贝模式，也就是把现在的代码拷贝到一个叫做branches的目录（这是SVN推荐的目录模型）。而基于这种分支模型，他的合并模型自然选用了 diff-patch 模式，也就是从开出分支的分叉点作为基础，使用源分支的最新代码和基础点做diff生成patch文件，然后把patch文件作用在目标分支上。这样说起来可能有点乱，我们看下面的图。

这里是一条提交的记录，其中的数字是版本号。我们在版本1开出一条分支，现在绿色和红色两条分支一同并行开发。
在版本6的地方，需要从绿色分支到红色分支有一个合并，SVN是如何做的呢？

1. 找到两个分支上一个diff的点，这里是共同的祖先版本1
2. 对当前绿色分支的最新的版本4和版本1进行diff，生成patch
3. patch作用在版本5上，生成版本6

 
Morpheus:svn-repo yinwm$ svn merge --help
merge: Apply the differences between two sources to a working copy path.
usage: 1. merge sourceURL1[@N] sourceURL2[@M] [WCPATH]
       2. merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH]
       3. merge [-c M[,N...] | -r N:M ...] SOURCE[@REV] [WCPATH]

  1. In the first form, the source URLs are specified at revisions
     N and M.  These are the two sources to be compared.  The revisions
     default to HEAD if omitted.

  2. In the second form, the URLs corresponding to the source working
     copy paths define the sources to be compared.  The revisions must
     be specified.

  3. In the third form, SOURCE can be either a URL or a working copy
     path (in which case its corresponding URL is used).  SOURCE (in
     revision REV) is compared as it existed between revisions N and M
     for each revision range provided.  If REV is not specified, HEAD
     is assumed.  '-c M' is equivalent to '-r :M', and '-c -M'
     does the reverse: '-r M:'.  If no revision ranges are
     specified, the default range of 0:REV is used.  Multiple '-c'
     and/or '-r' options may be specified, and mixing of forward
     and reverse ranges is allowed.

看，上面是svn merge的帮助，当我看到还需要指定版本号的时候，我就退却了。

Q：那么git没有这些问题么？
A：没有

git的初衷是为了管理Linux内核，要知道那可是全世界维护的一个项目，所以对分支的创建、销毁、合并的支持是非常良好的。他可以创建轻量级分支，这样在本地临时切换到某个分支进行一些feature的开发是非常方便的。当开发完成后直接合并即可，而如果失败就直接废弃这个分支，没什么成本和污染的。

git的每次提交是把整个的项目做一个镜像存储的，这样任何两个版本的区别只要简单的diff出来就可以，而分支合并也归并为简单的两个版本的diff，然后根据diff合并。这样你可以打着滚儿的合并，而不怕沾一身屎。

具体的git存储可以看这里，Git 内部原理 – Git 对象（翻墙越翻越健康）

Q：git没有良好的权限管理
A：被你戳中了

git本身有一些权限的管理，但是基本上他的粒度是对整个的项目。你可以通过ssh、apache等方式进行读、写的控制。但是能否更加细粒度的控制，我个人就不知道了。

这点上SVN绝对是领先git的。SVN也更适合大团队，因为大团队会有代码的安全性的考虑，分层、分段的控制是非常必须的。但是我们的团队很小，而且我的团队哲学是任何人可以看到、修改任何东西，包括代码和文档（我们的文档用trac的wiki和GDocs管理）。

在这点上我没过多的考虑，但是有需求的童鞋们，你们要想清楚哦。

Q：git-flow 真的很好么
A：git-flow 真的很好，像 hg-flow 一样的好

XD

最后

给大家看点我们代码库的截图，看到这些你就能明白为什么我说git/git-flow对我们的并行开发有很大的帮助了。图中每条颜色的线都是一条分支。

使用git-flow前

使用git-flow后

SEARCH:

Related searches:
vagrant subject douban specified source

gipoco.com is neither affiliated with the authors of this page or responsible
for its contents. This is a safe-cache copy of the original web site.

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.