这两天在考虑给我们4个人的小团队使用什么好的知识共享软件？第一个进入我的视野就是大名鼎鼎的confluence，无论从哪个角度考虑，confluence都是首选，而且我也装了，不过由于云服务器配置实在是太差，做一个操作就要卡上半天(cpu跑满了)。因此无奈，confluence被我pass掉了！接下来我考虑了一下Doku，这是一个php开发的小型wiki系统，其实它很不错，各方面都不错，而且插件也比较丰富。但是它有自己的一套语法系统，使用插件的话可以支持Markdown，但是相对比较麻烦一些，主要还是内心对它并不是特别喜欢吧，也被我pass掉了。最后进入我的视野的gollum(咕噜),这gollum和指环王中的是同一个词，不知道当初起名时，是不是作者比较喜欢电影中的咕噜。gollum是ruby开发的一套wiki系统，它支持Markdown语法、轻量级、结构清晰，看起来是不错的选择。
Docker安装Gollum
首先这里假设你已经成功安装docker了，如果你还没有安装，可以自行搜索一下资料，还是很简单的，这里就不再叙说了。
Dockerfile文件
FROM ruby
RUN apt-get -y update && apt-get -y install libicu-dev cmake && rm -rf /var/lib/apt/lists/*
RUN gem install github-linguist
RUN gem install gollum-rugged_adapter
RUN gem install gollum
RUN gem install org-ruby # optional
WORKDIR /wiki
ENTRYPOINT ["gollum", "--port", "80", "--adapter", "rugged"]
EXPOSE 80
Docker-compose文件
version: "2"
services:
gamemodr_wiki:
build: ./gollum
volumes:
- /data/wiki/gamemodr:/wiki
expose:
- 80
ports:
- 8888:80
运行”docker-compose up -d “就可以让容器服务运行了，注意挂载的”/data/wiki/gamemod”目录需要是一个git初始化过的目录。
如果需要在线编辑，可以用nginx做一个反向代理，然后加一个http用户认证，当然权限部分就没办法了。如果不需要在线编辑，可以去掉gollum在线编辑功能，然后和类似jenkins集成工具整合，也是不错的选择。
前几天看到陈浩在手机微博上面回答“如何看待Linus‘从不认为阅读别人的代码是了解某个想法的一种有用的方法’言论？”.手机看东西不是很方便，所以也一直没有细看，今天在关注陈浩微博的时候又看到了他这个回答，忍不住点进去看了看！陈浩写的东西正如我过去说过的，还是营养成分很好的，让我从中很受启发的！下面的内容是从知乎copy过来的！
Jeff Atwood说过这么一句话：“Code Tells You How, Comments Tell You Why”.
其实，Jeff这句话并不准确，另外，我把其扩展一下——
代 码 => What, How & Details
文档/书 => What, How & Why
可见，代码并不会告诉你 Why，看代码只能靠猜测或推导来估计Why，是揣测，不准确，所以会有很多误解。而且，我们每个人都知道，Why 这个东西是让你一通百通的东西，也是让人醍醐灌顶的东西。（这也是楼主为什么喜欢看书的原因，我也是）
但是，代码会告诉你细节，这是书和文档不能给你的，细节是魔鬼，细节决定成败，这样的话我们不但听过很多了，我们做技术的也应该体会过很多了。当然，我们也要承认，这些代码细节给人带来的快感毕竟不如知道Why后的快感大（至少对我是这样的）
书和文档是人对人说的话，代码是人对机器说的话。
所以，
- 如果你想知道人为什么要这么搞，那么你应该去看书，看文档（就像Effective C++、Code Complete、Design Pattern、Thinking in Java等等这样的书）
- 如果你要知道让机器干了什么？那你应该看代码！(就像Linus去看zlib的代码来找性能问题)
因此，我认为都比较重要，关键看你的目的是什么了。
- 如果，你想要了解一种思想，一种方法，一种原理，一种思路，一种经验，恐怕，读书和读文档会更有效率一些，因为其中应该会有作者的思路的描述。比如像Effective C++之类的书，里面有很多对不同用法和设计的推敲，像TCP/IP详解里面也会对TCP算法的好坏的比较……这些思维方式能让你对技术的把握力更强。光看代码很难达到这种级别。（现在你知道什么样的书是好书了吧 ;-)）
- 如果，你想了解的就是具体细节，比如：某协程的实现，某个模块的性能，某个算法的实现。那么，你还是要去读代码的。因为代码中会有更具体的处理（尤其是对于edge case或是一些代码技巧的东西）
另外，看看下面的几个现像，你可以自己比较一下：
- 很多时候，我们去读代码，那是因为没有文档，或是文档写得太差。
- 很多时候，你在google, stackoverflow, github过后，你会发现，你掌握的知识就是一块一块的碎片，即不系统，也不结构化，更别说融汇贯通了。你会觉得你需要好好地读一本书，系统地掌握知识，这种感觉你一定很强烈吧。
- 很多时候，在你去读别人代码的时候，你会因为基础知识或是原理不懂，或是你不知道为什么的情况下，你要么完全读不懂代码，要么就是会误解代码。（比如：如果你没有C语言和TCP原理的基础，你根本读不懂linux下TCP的相关代码的。我们因为误解代码用意而去修改代码造成的故障还少吗？）
- 很多时候，看到一个算法时或是一个设计时，比如Paxos这样的，你是不是会有想去看一下这个算法的实现代码是什么样的？如何才能实现的好？（但是如果你没看过Paxos的算法思想，我不认为你光看代码实现，就能收获到Paxos的思想）
- 很多时候，当你写代码的时候，你能感觉得到自己写的代码有点别扭，怎么写都别扭，这个时候，你也会有想去看别人的代码是怎么实现的冲动。
- …… ……
从代码中收获得大，还是从书中收获的大，不同的场景不同的目的下会有不同的答案。
这里，谈一谈人的学习过程吧，从学习的过程中，我们来分析一下看代码和看书这两个活动。
人对新事物的学习过程基本都是从“感性认识” 到 “理性认识”的。
- 如果你是个新手，那应该多读代码，多动手写代码，因为你需要的是“感性认识”，这个时候“理性认识”对你来说你体会不到。一是因为，你没有切身的感受，告诉你Why你也体会不到，另一方面，这个阶段，你要的不是做漂亮，而是做出来。所以，在新手这个阶段，你会喜欢Github这样的东西。
- 如果你是个老手，那么你有多年的“感性认识”了，你的成长需要更多的“理性认识”，因为这个阶段，一方面，你会不满足于做出来，你会想去做更牛更漂亮的东西，另一方面，你知道的越多，你的问题也越多，你迫切地需要知道Why！这个时候，你就需要大量的找牛人交流（读牛人的书，是一种特殊的人与人的交流），所以，这个阶段，你会喜欢读好的书和文章的。
然而，对于计算机行业这个技术创新超强技术繁多的行业来说，我们每个人都既是新手，也是老手。
《========================================================================》
上面这些内容都是陈浩的回答，不难看出陈浩确实是读过不少书的，像我这种程序员，其实大部分还是处于多读代码多动手的阶段，当然也承认不如陈浩大叔这么爱看书，读过的书也不能相提并论。这里推荐一下陈浩的微博“左耳朵耗子”，还有他的个人博客“酷壳”。陈浩和惠新宸都是我比较关注的2个大牛吧，但是陈浩写的文章感觉针对各种层次的都有。当初我学C时，看了不少陈浩的文章，尤其是他写《跟我一起学Makefile》和他写的gdb调试程序！但是在惠新宸身上，我只能看到他作为php开发组专家这个耀眼的光环！
近期评论