-
两种学习方法
昨天听一个讲座，挺有意思，怎么学习一个东西，有两种办法：一个是像学习母语一样，天天刺激你一点点的学习具体内容；一个是像学习英语一样，把知识梳理好归纳成语法规则和语言理论。明显第一种最好，自己去慢慢发现规律、总结规律，从内到外融合贯通，但是过程漫长。第二种办法高屋建瓴，快，但是不具体不牢固，你学了很久过去将来时态也搞不清楚一句具体的话怎么去说。 -
马拉松式学习与技术人员的成长性
你的朋友圈里总有一些人具有某种特殊的技能点。比如我的一位铁哥们波仔，就是这样的人。
波仔，江湖人送外号波哥，是我认识的程序员里面最能跑的。国内的马拉松赛事，他几乎一次不落地参加。只要哪个城市举办马拉松比赛，不管多远，他都一路飞奔过去。这不，前两天刚冒雨跑完了无锡的马拉松。虽然淋得跟落汤鸡似的，但感觉就一个字——爽！
波仔年轻的时候曾是专业运动员，有着令无数少女尖叫的健康体魄。后来做了程序员，虽然跑步从此成了业余爱好，但仍然威风不减当年，很随意地就跑能个半马，紧接着再跑个全马，都是小菜一碟。我们搞程序的，谁没经历过没日没夜加班的日子。常言道，身体是革命的本钱。这说起来，好的身体也是程序员的核心竞争力之一呢。
意大利「文艺复兴之父」彼特拉克曾经说过：「肉体和心智的能力必须大到足以满足文学活动和妻子两方面的需要。」如果换做程序员的角度，这句话应该修正一下：肉体和心智的能力必须大到足以满足熬夜写代码和女朋友两方面的需要。当然啦，这个说法也还远没有表达出生活真实的复杂性和严峻性。
所以，跑步是锻炼身体很好的手段。但是马拉松，除了锻炼身体，同时也是对人性的考验。一件接近身心极限的事情，你的身体能否承受，你的精神能否坚持下来。
波仔多次邀请我一起去跑个马拉松，都被我毫不犹豫地拒绝了。这身体条件，咱不能强求。没有准备的极限运动还是比较危险的。但是，对于有能力跑下来的朋友，我在精神上表示羡慕和支持。
有时候我会把学习比作跑步。对于类似程序员这样的职业，新技术更新换代的速度确实比较快，这需要你总是保持在学习的状态。
应该说，在一般情况下，程序员们对新知识进行学习的能力都还是比较强的。工作中碰到以前没做过的东西，只要能在网上找到对应的开发文档，仔细读一读，再看几个 Demo，就基本能解决问题了。这种规模的学习过程，一般几天就搞定了，可以看做是一次「短跑」。
当然，这种「短跑式」的学习过程，也只对于「一般性」的情况有效。而对于一些「专业性」的领域，我们就需要「马拉松式」的学习姿态了，做好充分的准备，并且长时间投入，半年，一年，甚至更长。
实际上，编程这门工作，门槛说低也不低，说高也不高。很多学历不高或者非科班毕业的同学，也都能把这份工作从事得很出色。但是按技术领域来区分的话，编程还是可以分为「一般性」和「专业性」两大类的。对于「一般性」的技术领域，你只要具备一点计算机基础，懂得一门编程语言，能理解业务逻辑，就能胜任了。但是「专业性」的技术领域就不一样了，除了计算机基础知识之外，你更需要掌握一整套知识体系，可能对数学知识还有特殊的要求。这样的领域有哪些呢？比如说，分布式系统，数据库理论，音视频处理，3D游戏引擎，操作系统和虚拟化技术，大数据处理，还有最近火爆的人工智能技术，等等。
对于「专业性」的这些知识，如果你打算涉足其中，就得需要拿出跑马拉松的精神了。据说马拉松跑到一半，很多人就会产生强烈的「想放弃」的想法，后半段就靠毅力支撑了。「马拉松式」的学习过程也是一样。可能一门「专业性」领域的知识，最开始吸引你的是兴趣，它非常有意思，可能听起来还很酷，但随着研究的深入，你就不可避免地遭遇很多沮丧时刻。你会发现，你学得越多，未知就越多。这时候你肯定会产生放弃的想法，甚至对自己是否适合做技术产生一丝怀疑，但是没有关系，每一个在某一领域走得足够远的人都会碰到这样的情况。只要你咬牙坚持下去，随后你得到的奖赏必然是恍然大悟或醍醐灌顶的感受。我相信 ，这与一场马拉松终于跑到终点的胜利喜悦是一样的。
有长跑经验的人都知道，真正能在马拉松上取得好成绩的人，基本上都是匀速跑者。开始跑得多快并不关键，关键在于「后劲」足不足。我们的职业生涯也是一样，不管是程序员还是其他职业，这个道理都适用。
我时常在想，不同技术人员之间的区别到底在哪。是在于工作经验，还是在于他们的聪明程度，或者是在于他们是否有名校的教育背景？为什么本来基础差不多的人，多年之后会产生巨大的差异？与此相关的一个很实际的问题是，我们在招聘新员工时，到底应该看重他们的哪些特点？我最后想到的答案是，决定不同技术人员之间的真正分野，在于「成长性」，也就是持续学习和提高自身的能力。换句话说，「后劲」足不足。一个人的成长过程，什么都可能随时变化，但成长性本身不应该有丝毫减弱。
设想一个稍微极端一点的情况，假设你要自己创业，现在要物色合伙人的角色。你会怎么选？你必须考虑他们的成长性。你放眼四周，也许你周围的很多朋友都能帮你解决当前的问题。但你物色的人选，他们能否随着公司一起成长？他们身上有没有自我超越的基因？都说找合伙人比找对象还难，的确如此。跟不上公司发展节奏的合伙人，注定将是一场灾难。
而创业公司的 CEO，作为掌舵人，他自身的成长性其实要求更高，因为这决定了公司和团队的未来，责任极其重大。Facebook 的 CEO 马克·扎克伯格，每周都坚持读一本新书，就是为了保持自己的成长性。有些自私的老板，他们忽略了这份责任，可能认为「我给你发工资你给我干活」是理所当然的事情。但是，确保团队成长的责任，和公司发展的责任，同样重要。
实际上，凡是带团队的人，都有这份责任。如果你自己混日子，不能一步步成长，那你的团队成员又怎能获得突破自己的机会呢？职位越高，责任越大。当你的 leader 或某个机遇把你推到那个位置的时候，你为进一步的成长做好准备了吗？估计很多人是想不到这一点的。还听说有些极端的团队 leader，甚至整日担心下属会超过自己，不但不给团队成员创造成长的机会，还打压下属。真是不理解这些人是怎么想的。所以，跟对人很重要。
投资人是否会投资一家公司，看重的是公司的成长性；我们买股票也是一样，都会选择成长性好的股票。甚至女孩子找老公，也希望找个「潜力股」。所有这些选择，都是在追求「成长性」带来的升值。
只要想明白这一点，我们就不再会为一些不必要的担忧而烦恼。比如，很多人担心年龄大了就再也做不好技术，或者担心年龄大了之后的职业发展问题。显然，年龄并不是决定成长性的关键因素，这顶多是一个心理因素。成长性更应该是一个人的本质特征，是他所具备的基因。人与人的不同究竟在哪里？具体技能总是会变化的，但基因是不变的，也不应该随着年龄的变化而变化。
人的可贵之处就在于学习和塑造能力，这是造物主赋予我们的可贵品质。
甚至现在的人工智能模型也要以学习的方式来训练，才能产生它需要的职能。一个复杂的模型，需要大规模的训练，喂给它很多数据和模式，才能让它获得新的知识，不断提高「智能」。
我们可以想象，人脑其实也是一个智能模型，只不过这个模型更庞大，参数更多，容量更大；训练它需要的数据更多，时间也更长。如果你想成为某方面的专家，就需要花费很多年的精力来进行专业训练。
一个人，要想在某方面获得睿智，唯一的办法就是持续地学习、调整、提高、成长。这个过程需要耐力和坚持，而最终你会收获成功和乐趣。
一句话，保持学习，保持「后劲」，保持成长。 -
进阶之路
那么，为了达到真正的突破，有哪些因素是我们需要重视的呢？
第一，根基。
在接触一门新技术或者一个新的技术领域时，良好的基础有利于我们快速突破，抵达下一个阶段。不同技术之间，基础却是相通的。比如，对于计算机软件学科的基础知识——数据结构和算法，处于熟手期的程序员可能多半会认为它们在工作中根本没有用。这是因为这个阶段的技术人员主要靠孤立的经验解决问题，一些基础的知识自然就用不上。但对于技术专家层次的人来说，数据结构和算法却是在系统设计的很多方面潜移默化地发挥作用。对于其它计算机基础学科，这个道理也同样适用。
再比如，现在人工智能和机器学习技术比较火，似乎全民都在学习。但要想学好这些技术，至少应该对于微积分、线性代数、概率论、统计学等数学知识有比较扎实的基础，才能走得更远。
第二，外因，一个不疾不徐的环境。
过于宽松的环境自然不利于人的进步，而盲目的紧张也不利于人的成长。
突破的过程需要付出巨大的精力，所以需要投入足够的时间去从容地完成。我们大概都经历过这样一种场景：新产品上线在即，但还有很多问题需要解决。如果距离预定上线时间还有数天，那么我们可以相对从容地用比较优雅的方式来解决这些问题，并做一些长远的打算；但如果我们碰到的情况是，两个小时以后就要上线了，那么我们多半会想一些歪点子来规避这些问题。
产品开发和技术优化，有时相辅相成，有时又互相矛盾。如果你所处的工作岗位，只是要求你不停地修改业务流程，盲目地试错，那么，可能公司根本没有给你留出技术突破的空间。试想，一个主旨不清，功能点做了新的就扔了旧的，而没有长远的目标，也不去持续优化体验，这样的一个产品，又怎能有持续的生命力呢？
第三，正确（正宗）的学习资料。
新手刚开始工作的时候，通常只要看一些入门教程（Tutorial），跑几个Demo，扫除了表面上的技术疑问点，再针对业务代码向老员工请教一番，基本就能开始工作了。然后一边编码，一边查阅所需要的API Reference，时间长了，经验和技巧足够多了，就自然变成熟手了。
而从熟手向专家的突破，则需要系统地去补习知识架构。技巧应该建立在对于普遍规则的理解之上。这里不得不提及Spec，它是涉及某项技术的完备的、系统的描述，包含该项技术涉及到的方方面面（具体参见我的另一篇文章《技术的正宗与野路子》）。在奔向技术专家的路上，阅读Spec，是不可逾越的一道功课。《射雕》中郭靖的武功突破，很大程度上就是因为他阅读了《九阴真经》这份大大的Spec。当然，除此之外，你可能还需要通读重要部分的API Reference以及Source Code。
技术专家必然将原始文献（官网Spec、论文等）作为知识的第一来源。相反，跟着某人的博客去系统地学习某方面的技术，是要冒有很大风险的，还需慎重选择。
最后，要想成为技术上的一代宗师，则需要更高的抽象，做出完全创造性的工作。这份工作不仅仅是阅读Spec，解决具体的问题了，而是创作Spec，开创全新的天地。
第四，独立思考，不要自我设限。
现在，很多人喜欢把技术好的人喊作“大神”。这自然是代表一种尊重，很多听的人也很受用。
但是，“神”的称呼暗含了一层意思：神是无法超越的，是普通人学不来的。这是人们在潜意识里划出的一道鸿沟。所以，我就不太喜欢类似这种称呼。
很多人碰到问题就喜欢找身边“大神”去问，但殊不知问再多问题，你仍然无法真正地有所提高。普通人和“大神”之间真正的鸿沟在于，能否独立思考和解决问题。
在追求技术成长的路上，不可能总是一帆风顺。我们不免有时沮丧，有时欣喜。
人生苦短，有人穷其一生，就是想要达到理想中的那个状态。但不管结果如何，当我们青春不再的时候，只求问心无愧。
- 从拖延到高效，我推荐这 7 本书
最近几个月一直在看一些非技术类书籍（大约50本左右），感觉收获非常大，从中选择出来比较经典的改变拖延、高效学习的书籍，希望给大家提供一些参考。
《拖延症心理学》
网络越来越成为了人们不愿意做事的罪魁祸首，这种趋势正在不断地蔓延。如今，信息已经铺天盖地、无所不在、太多的信息、太多的决定、太多的选择，让我们很多人陷入拖延的泥沼之中。
这本书对拖延症分析很到位，特别是前半部分在描写拖延症的时候，后半部分给出解决方案。
这本书能让你看清自己为什么会拖延，找到拖延的本质，给出解决方案让拖延之手从你的生活中松开！
《学习之道》
我们不仅必须善于等待，还要享受等待。因为等待不仅仅是等待，它还是生活。我们中的很多人生活着，却没有全心投入。当我们真实的生活开始时，却一味等待。
美国公认的高效学习经典书。世界冠军现身说法,揭秘从平凡到天才的成功之道。这是在任何领域都能成功的学习方法。这是任何人都适用的终身深入学习法。教你“以较小的努力赢得美好成就”。
这本书讲的学习方法，颠覆了大多数人对学习的认识。以及还讲解了遇到困境该如何高效学习。
《搞定Ⅰ:无压工作的艺术》
GTD是“Getting Things Done”的缩写，翻译过来就是“把任务完成”。是由作者戴维·艾伦开创的一套完整个人时间管理系统。
了解过时间管理的同学，应该都知道GTD。
GTD的五个核心原则是：收集、整理、组织、回顾、执行。
《番茄工作法图解》
番茄工作法是简单易行的时间管理方法，是由弗朗西斯科·西里洛于1992年创立的一种相对于GTD更微观的时间管理方法。
之前写过关于番茄文章
《时间管理之番茄工作法》和《番茄工作法的时间管理套路》
这本书有图片、步骤帮助你轻松学会番茄工作法精髓；至于坚持，用番茄工作法是会上瘾的，你只需要担心自己戒不掉。
目前我就是GTD组合番茄工作法，十分的高效。
《Google工作整理术》
不要花太多时间给信息归档，用的时候学会去搜索；
在数字信息文档中加上关键词，方便日后检索；
从前，知识就是力量,现在，共享知识才是力量；
把工作和生活融为一体，而不是力图在二者之间求平衡。
这些实用Tips都揭示了：信息整理才是高效工作的关键，信息整理已是现代人的工作必备技能！
这本书教你如何：过滤分类、各个击破、有效组织。
《凸法则》
一个对其他人发自内心感兴趣的人，在两个月里创造的沟通，要比一个总是试图让别人对自己感兴趣的人在两年内创造的沟通还要多。
高效表达自我的心理法则。
这本书提供了一系列可以快速吸引他人注意力的心法和方法。
《习惯的力量》
我们的生活在某种程度上有其固定形态，是习惯的集合体–有现实生活的习惯、感情生活的习惯，还有思维的习惯。这些习惯系统化地构成了我们的喜怒哀乐，让我们走向自己的命运。不管最终命运如何，我们都无法抗拒。
这是最后一本推荐的书籍了，这本书籍至关重要，因为上面的书教会了我们解决拖延，沟通，学习，工作，但最重要的还是要把好的行为养成一种习惯。
本书单适合从上往下一本一本看。
通过《拖延症心理学》和拖延症说：“拜拜”。
通过《学习之道》来提升自身学习能力。
通过《搞定Ⅰ:无压工作的艺术》来用GTD来规划任务。
通过《番茄工作法》来做细分任务用番茄钟计时执行。
通过《Google工作整理术》告别无序工作，学会利用数字工具为大脑减压,从而提高自身工作效率。
很多情况下效率不仅是我们本身的问题，还是协同的问题，通过《凸法则》提高我们的沟通能力，而从提高整体的团队效率。
通过《习惯的力量》把这些好的行为养成自己的习惯。
希望能够对大家有帮助。
- How to read source code
http://blog.codinghorror.com/learn-to-read-the-source-luke/
Most projects supply a documentation on the wiki/readme.
In the meantime, there are a few strategies:
Pick a feature you like, and try to find the source that implements it
Find the beginning point in the source and step through it, try to understand how it sets itself up
Start poking around aimlessly until you find something that makes you curious (i.e. that’s an interesting technique, why have they done that? etc)
One thing that helps me is to put myself in the author’s shoes. Why did they do things this way? Was it good/bad? For me, reading source code is about learning new strategies for solving problems. I usually look at a project and think how I would have done it, then I see how they do it and compare.
No matter what the documentation says, the source code is the ultimate truth, the best and most definitive and up-to-date documentation you’re likely to find.
When people report a problem with their stack, the first question I ask them is: “Well, did you read the source code?”
- 技术的正宗与野路子
黄衫女子的武功似乎与周芷若乃是一路，飘忽灵动，变幻无方，但举手抬足之间却是正而不邪，如说周芷若形似鬼魅，那黄衫女子便是态拟神仙。
这段描写出自《倚天屠龙记》第三十八回。
“九阴神抓”本是《九阴真经》中的上乘武功，但当初梅超风夫妇由于拿到的《九阴真经》不完整，学不到里面的内功心法，硬是把这门上乘武功练到了邪路上，于是就成了“九阴白骨爪”。周芷若为求速成，也练就了这门邪功。
但黄衫女子乃出身武林名门（相传是杨过和小龙女的后人），自然修炼的是正宗的《九阴真经》。虽然武功路数与周芷若本同属一脉，但更加“醇真深厚”，自然也更胜一筹。这是金庸武侠中“正宗”武功胜过“野路子”的一个典型案例。
那么，这是否能够说明，“正宗”一定强于“野路子”呢？
且慢！
喜欢金庸武侠的朋友，可还记得《越女剑》中的阿青？
阿青本是一名牧羊女，却在牧羊时巧遇一头会使竹棒的白猿。在与白猿的玩耍嬉闹中，她硬是悟得了高超的剑法，竟能以一人之力敌两千越甲！
就是这样一个从野路子练出来的柔弱女子，即使按广大金庸迷的保守估计，她也能在整个金庸武侠图谱中至少排名前五！
做技术，犹如修习一门武功。
历数我周围的技术牛人（牛不到一定程度的先不算），他们中既有名牌大学计算机科班毕业的，也有半路出家转行过来的。
但他们都有一个共同特点：他们在遇到问题后，思考片刻，总是能一下子切中要害，在表达上也往往一语中的。这也包括那些平常不善言辞的程序员。反观那些“更一般”的程序员（其中不乏科班毕业的），他们经常很难抓住问题的本质，表达起来也总是说不到点子上。
可见，“正宗”还是“野路子”，并不在出身。
写到这里，我终于自己长出了一口气。我出身一个极普通的农民家庭，既不是书香门第，也不是技匠世家。记得在大学一年级的上机编程课上，我才发现自己原来根本不会用键盘打字。相比那些初中高中就把计算机玩得很溜的同学，我算野路子吗？
好了，那“正宗”还是“野路子”，不在出身在什么呢？
在于学习和思考的方法。
据我观察，技术牛人的学习方法和思考方式，大体类似。
思考方式，是个很难说清的东西。所以，本文我们重点来讨论讨论学习的方法。
面对一项新技术的时候，我们怎样去学习才能循序渐进，最终理解得深刻？
让我们先把可供自学的资料列出来，分析一下：
Tutorial（入门教程）。由该项技术的官网提供。通常是英文的。这份资料是给初次接触该项技术的人看的，一般是一步一步地教你完成某些例子。当我们说某项技术对于新手不太友好的时候，一般也是因为这项技术的Tutorial部分做得不够好。
Specification，简称Spec。这是集中体现该项技术的设计思想的东西，是高度抽象的描述。这个一般也是一份完备的、系统的描述，包含该项技术涉及到的方方面面。这部分资料在不同的地方叫法不同，在相对简单的技术项目中，也可能没有；在另一些情况下，这部分资料混杂在其它文档资料之中；它还可能以论文（paper）的形式出现。
API Reference。大而全的API索引和文档，针对不同的语言接口可能提供多份。当我们使用这项技术进行编程的时候，API Reference自然是个离不开的、总是要不停去查询的一份资料。
别人写的技术博客。质量良莠不齐，到底有没有价值，我们要学会去分辨。
技术书籍。跟技术博客类似，质量有好有坏。稍后我们和技术博客放在一起来分析。
Source Code。如果我们要学习的技术是开源的，那么很幸运，我们能得到源代码。这是一份终极资料。
为了让这些概念表达无误，我接下来多举一些例子。
Java语言
从来没有接触过Java语言的人，要想开始自学Java，从哪里开始呢？可以从Oracle官方提供的Tutorial入手：
http://docs.oracle.com/javase/tutorial/
这份资料《The Java™ Tutorials 》，集中体现了Tutorial类型的资料的特点。它从最开始的编译和运行环境搭建说起，教你写出第一个Hello World，再用介绍的方式将Java各种语言特性（变量、类、泛型、Lambda表达式、JavaBeans，等等）进行讲解，同时还有对于JDK里常用API（集合类、多线程、IO等等）的介绍。
对初学者而言，需要的就是这样一份资料。即使你手头没有任何Java的入门书籍，读完这样的一份资料之后，一个新手基本就可以开始使用Java来编程了。
再看Spec：
http://docs.oracle.com/javase/specs/jls/se8/html/index.html
这份文档，叫做《The Java® Language Specification》。是一份很典型的Spec，完备而规范。
任何讲Java语法的资料，包括各种书籍和前面提到的Tutorial，都只能涉及部分。而这份Spec，如果你能读通的话，那么与Java语言特性有关的所有一切，你就再也不用求人了。
JDK 8的API Reference:
http://docs.oracle.com/javase/8/docs/api/index.html
用Java语言编程的时候，我们需要不断查阅的就是这份API Reference。我们平常一般是通过IDE来快速查看某个接口的文档说明。
Android开发
Android针对新手的Tutorial类型的资料，官网上称为Training：
https://developer.android.com/training/index.html
这份资料是典型的Tutorial。它教你制作第一个Android App，并针对若干个主题进行一步一步的教学。
下面这份资料在Android官网上被称为：API Guides。
https://developer.android.com/guide/index.html
它实际上是一份介于Tutorial和Spec之间的文档。它有很多Spec的特点，比如它介绍Android中的抽象的四大组件的概念，介绍资源尺寸的抽象（dp），介绍View层原理，等等。但是，跟前面看到的Java Spec相比，它没有那么规范和正式，描述也更随意一些，估计也算不上完备（但涉及到了Android技术的绝大部分）。
当我们对Android中某项具体技术存疑，或是有争论的时候，我们就需要来翻翻这份文档。因此，它基本可以归入Spec类型。
然后是Android SDK的API Reference：
https://developer.android.com/reference/packages.html
这份API Reference的质量并不高，描述上过于简略，甚至模糊不清，其可读性跟前面提到的JDK 8的API Reference完全不在一个水平上。这也是一些开源项目的通病，不重视接口文档。
iOS开发
苹果在iOS开发方面给出的文档是相当丰富的，这也是一个闭源系统做得好的地方。
iOS开发的文档，很难区分出Tutorial和Spec这两个层面。它由很多文档组成，每个文档描述系统的某一方面。通常是在一个文档中，既有教学的部分，又有完备描述的部分。
针对完全的新手入门的话，下面这个文档，算是真正的一个Tutorial：
Start Developing iOS Apps (Swift)(https://developer.apple.com/library/ios/referencelibrary/GettingStarted/DevelopiOSAppsSwift/index.html)
其它各个文档也是介于Tutorial和Spec之间，更偏向Spec。比如：
App Programming Guide for iOS(https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html)
View Controller Programming Guide for iOS(https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/index.html)
View Programming Guide for iOS(https://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/Introduction/Introduction.html)
Core Animation Programming Guide(https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreAnimation_guide/Introduction/Introduction.html)
Concurrency Programming Guide(https://developer.apple.com/library/ios/documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html)
然后是iOS的API Reference：
https://developer.apple.com/reference/
如前所述，这份API Reference的可读性非常高，比Android SDK的要强多了。很多前后相关的概念，在这份API Reference的描述中，都有体现。
当然，除了developer.apple.com之外，iOS的文档也都可以通过XCode取到。
Redis
Redis的Tutorial是我见过的最好的Tutorial，它对初学者非常友好，不仅能读，还能执行。
http://try.redis.io/
Redis的Spec举例:
Redis Protocol specification (http://redis.io/topics/protocol)
Redis Cluster Specification (http://redis.io/topics/cluster-spec)
Redis RDB Dump File Format (https://github.com/sripathikrishnan/redis-rdb-tools/wiki/Redis-RDB-Dump-File-Format)
Redis的Commands Reference:
http://redis.io/commands
TCP/HTTP
网络协议与前面的都不同，它不是一个实现，而是一种标准。
网络协议的Spec文档很明显，就是它们对应的RFC。如果你的工作经常涉及到使用某个网络协议，恐怕就需要找来RFC通读一遍了。
再来说一下技术博客和技术书籍。
现在网上的技术文章空前繁荣，想读都读不过来。胡峰同学在他的微信公众号“瞬息之间”上，发过一篇文章《技术干货的选择性问题》，讨论的就是技术人员在当前技术文章爆炸的情况下如何取舍的问题。
在这里，我们从另一个角度来讨论一下这个问题。如果一篇技术文章，仅仅是对于所涉及技术的官方文档（Tutorial或Spec）的复述，甚至只是个翻译，那么就价值不高。换句话说，如果我们能通过阅读官方文档学到同样的知识，那为什么要看你写的技术文章呢？官方文档自然更权威，直接阅读它能确保不会遗漏重要的东西。
那什么样的技术文章才有价值呢？大概可以说（未必那么准确），那些包涵了实践经验的，能将各个技术点综合起来产生思考，从而给人以启迪的。简单来说，就是有深度的。
当然，技术书籍也大体如此。
我们回过头来再看一下，各个学习资料之间的层次结构。
每当我们接触一项新的技术的时候，我们都要把手头的资料按照类似的这样一个金字塔结构进行分类。如果我们阅读了一些技术博客和技术书籍，那么也要清楚地知道它们涉及到的是金字塔中的哪些部分。
最开始，一般读完Tutorial之后，就基本能上手做一些开发工作了。然后一边开发，一边查阅API Reference。注意，从这时候起，你的老板就开始向你付工资了，因为你的工作已经能够产出成果了。
但是，工作一段时间之后，我们发现，似乎身边的技术牛人学东西都比较快，而且在很短的时间内就能对某项新技术达到很深的理解。这是为什么呢？
这并不是因为技术牛人阅读技术资料阅读得快，而是他们知道阅读正确的资料，从而很快能达到知识金字塔更高的一层。
我见过的很多技术牛人，他们如果不是把一项技术至少理解到Spec那个层次，他们是不敢随便写代码的。相反另一些人则从网上随意拷贝代码，并在自己不能完全理解的情况下用到项目中去。技术牛人们当然也参考网上的代码，但他们通常会确保它的每一部分都能安放在知识金字塔的某一部分，他们不容许那种不属于任何体系的知识孤岛的出现。
我们现在可以这样总结，技术的“野路子”，其实是知识结构的不完整和不系统造成的一种状态。只有当你冲破知识金字塔层层的障碍，迈向更高层次的时候，老板才开始向你付高价。
我们的大脑好比内存。
既然是内存，就装不下所有的知识。但应该能装下对于知识的索引，否则我们便没法工作了。
那么，这里就有一个选择性的问题：我们选择哪部分知识加载到“内存”里呢？
显然，应该优先选择重要的，对我们最有用的信息。
对于那些最核心的技术，我们应该做到：
通读Spec。读完就不再困惑。
重要部分的API Reference要通读。里面包含了很多跟实现有关的信息。
如果工作需要，还可能需要读到Source Code。特别是对于平常一直在使用的SDK，不一定从头到尾把源码读通，这样工作量太大且效率不高，但一定要把你的开发环境设置成一点击某个调用的方法就能跳转进源码实现。只有这样，你才能把平常开发的时间利用起来，随时随刻都点过去看源码。
对于剩下的知识里80%的部分，应该至少理解到Spec层次。只有这样，我们才能游刃有余地去使用它。
通读重要的Spec，在很多情况下，其实还是很有难度的。这需要毅力，和一点点英语基础。
按本文前面提到的例子，做Java的人有谁读过Java Spec？做Android的人有谁把developer.android.com上的API Guides都能通读下来？而做iOS的人，developer.apple.com上的各个Programming Guide又完整地读过几个？对于经常调用的SDK，你会有计划地去通读其中重要部分的API Reference吗？
能够把这一套做下来的，有可能不成为技术牛人吗？
到了文章最后了，总感觉还有些意犹未尽，脑海中似乎有些东西还是没有表达出来，也不确定本文描述的学习方式是不是适用于每位读者。仔细想想也难怪，学习本来就是一个复杂的问题，每个人并不是完全一样的套路。
但是，不管本文介绍的方法是“正宗”的路子，还是属于“野路子”，我在这里想要强调的一点是很明确的，那就是：要把知识梳理成系统的结构，要让头脑中的知识层次清楚，为此，我们需要阅读恰当的东西，需要不断地练习，需要克服种种困难。
成长没有捷径可走。需要的是一个一个坚实的突破。
- 如何让自己成为一个优秀的程序员
这个人真的知道他们正在做什么：
你的想法:编程能力和年龄是成正相关性的，希望编程到老，当然身体要好。
沟通方式
管理自己的方式
精湛技术水平编程演讲的方式
他们做调查研究
“三思而后行”，或者叫“谷歌一下”
优秀的程序员在解决问题之前知道通过GitHub图书馆、网络博客，或者通过与经验丰富的程序员交流等形式来做调查研究。
他们阅读错误信息（并按照它们行事）
这包括解析堆栈路径信息。
我知道的高效程序员是不会害怕深究问题的。
优秀的程序员发现问题马上就解决它。读错误信息对他们来说仅仅是个开始，他们渴望深究问题并查出问题的根源。他们不喜欢推卸责任，而是愿意查找解决问题的方案，问题在他们这里止步。
他们去看源代码
文档、测试、团队，这些都会说谎。尽管不是故意的，但是如果你想确切地知道事情是怎么回事，你必须自己亲自看源代码。
They just do it
优秀的程序员趋向于主动去做。他们的内心有着难以控制的冲动，当他们确定问题或者发现新的需求时他们立刻会实现解决方案，有时过早有时太过激进。但是他们对问题本能的反应是正面解决问题。
他们避免危机
他们善于沟通交流
说到底，编程是一种形式的沟通交流。写代码和写散文创作一样，能够简洁地表达你的想法很重要。我发现那些可以写简洁邮件，优雅的状态报告，或者甚至只是一个有效的备忘录的程序员也将会是优秀的程序员。
他们激情四射
我认为这可能是优秀的程序员最重要的方面（也许这点也适用于除计算机科学领域的其它领域）
如果你真的在乎你所做的事情，如果不把它当成工作，当作一个业余爱好、兴趣或一件很有吸引力的事情，那么在该领域你比其他人更有优势。优秀的程序员一直不断编程。普通程序员一天工作八小时，并且没有业余项目，也没兴趣回馈社区。他们不会不断地尝试新方法，而只是为了看看它们是如何运行而执着于编程语言。
当我看见一个程序员利用周末的时间做自己喜欢的项目时，参与创作他们每天能用到的工具时，执着于新的有意义的事情时：那个时候我确信我眼前的是一个令人惊奇的人。最后，优秀的程序员视他们的职业不仅仅是赚钱的途径，更是让生活变得有些不同的方法。我认为那就是成就最优秀程序员的真正原因。对于他们来说，编写代码是改变世界的一种方法，也是我非常尊敬崇拜他们的原因。
真正的错误是，当你知道应该如何去提高时仍然选择做一名初学者。
1.提交（签入）代码需要填写备注说明
2、每天汇报自己的工作情况
3、对一些公共库的修改一定要谨慎，并且测试再测试
4、需求要确认，切勿盲目编码
5、经常主动地去和别人进行 Code Review
6、要相信自己的工作在团队中是举足轻重的
7、不要盲目拷贝代码
8、及时记录工作日志
我司很多刚来的大学生在半年内都能把一些中间件系统摸的很明白，并不是说有多难，只是接触少，对未知的东西感到害怕疑惑而已。
大型网站技术架构-核心原理与案例分析。 @李智慧大牛的书
大型分布式网站架构-设计与实践。作者：陈康贤
大型网站系统与java中间件实践。作者： 曾宪杰（原淘宝技术，现在蘑菇街）
然后再推荐一个网站并发编程网 - ifeve.com。这个网站的知识绝对够你面试一个阿里P7，京东T3-2，腾讯T3-1。
其次掌握的技能树主要有三个方面：
第一个是基础。比如对集合类，并发包，IO/NIO，JVM，内存模型，泛型，异常，反射，等有深入了解，最好是看过源码了解底层的设计。比如一般面试都会问ConcurrentHashMap，CopyOnWrite，线程池，CAS，AQS，虚拟机优化等知识点，因为这些对互联网的企业是绝对重要的。而且一般人这关都过不了，还发闹骚说这些没什么用，为什么要面试。举一例子，在使用线程池时，因为使用了无界队列，在远程服务异常情况下导致内层飙升，怎么去解决？你要是连线程池都不清楚，你怎么去玩？再举一例，由于对ThreadLocal理解出错，使用它做线程安全的控制，导致没能实现真的线程安全，你怪我哦？所以作为一个拿两万的JAVA程序员这点基础是必须的。
第二你需要有全面的互联网技术相关知识。从底层说起，你起码得深入了解mysql，redis，mongodb，nginx，tomcat，rpc，jms等方面的知识。你要问需要了解到什么程度，我可以给你说个大慨。首先对于MySQL，你要知道常见的参数设置，存储引擎怎么去选择，还需要了解常见的索引引擎，知道怎么去选择。知道怎么去设计表，怎么优化sql，怎么根据执行计划去调优。高级的你需要去做分库分表的设计和优化，一般互联网企业的数据库都是读写分离，还会垂直与水平拆分，所以这个也有经验的成分在里面。然后redis，mongodb都是需要了解原理，需要会调整参数的，而nginx和tomcat几乎都是JAVA互联网方面必配，其实很阿里的技术栈选择有点关系。至于rpc相关的就多的去，必须各种网络协议，序列化技术，SOA等等，你要有一个深入的理解。现在应用比较广的rpc框架，在国内就是dubbo了，可以自行搜索。至于jms相关的起码得了解原理吧，一般情况下不是专门开发中间件系统和支撑系统的不需要了解太多细节，国内企业常用的主要是activeMQ和kafka。你能对我说的都研究的比较深入，阿里p6我觉得是没问题的，当然这个还需要看你的架构能力方面的面试表现了。
第三就是编程能力，编程思想，算法能力，架构能力的考量。首先2W程序员对算法的要求我觉得还是比较低，再高级也最多红黑树吧，但是排序和查询的基本算法得会。编程思想是必须的，问你个AOP和IOC你起码的清清楚楚，设计模式不说每种都用过，但是也能深入理解个十四五种。编程能力这个我觉得不好去评价，但是拿一个2000W用户根据姓名年龄排序这种题目也能信手拈来。最后就是架构能力，这种不是说要你设计个多牛逼多高并发的系统，起码让你做一个秒杀系统，防重请求的设计能快速搞定而没有坑吧。
- 从腾讯的职级系统 看清自己的职场宿命
我2011年把公司全资卖给腾讯。2012年过完春节，编辑部的员工辞职一半。
我就很想不通，现在变成了腾讯员工，运营腾讯旅游，听上去很不错，为什么要离开呢?
于是和每个申请离职的小MM都交流了一下。
之前我是创业，当然没能力找很多熟手，基本上是大学应届毕业生。到此时，大家毕业1年多。很此次提出离职，几乎原因一致：“离开北京，回家乡去。”
小姑娘提的问题很现实：“我在这里，每个月租房子要1500，而且租在很远的地方。每天眼睛一睁就去挤公交。晚上下班，再2个小时颠簸到住的地方，基本上一点力气都没有了。我的生活就是路上——上班——路上——睡觉。这样几年，我会成为一个什么样的人?我能不能在北京呆下来?我会有什么样的生活?”
我一时哑然。
然后问当时腾讯电商的HR老大刘琳。有没有被问过类似的问题。
刘琳吃惊地问：“啊?难道你第一次面对这个问题?我们可是10年累计花了1000多万设计了一套系统，来解决这个问题啊。……”
这就是腾讯的职级系统。看到它的一瞬间，我惊呆了。然后花了整整两周的时间仔细学习，受益匪浅。
腾讯的职级系统有26个职业通道，如果你是一个一张白纸只有素质没有任何职业能力的毕业生，可以从这个26个通道，比如行政、财务、设计、运维、开发、运营、产品…….的任何一个1-1级开始，修炼，打怪升级，直到千万年薪。如同一个完整的人生指引。
横轴是26个职业通道，专业技能各不相同，纵轴是4个大层级。
以下是按照我的理解来写了。(直接抄原文会被企鹅摔着打的)。
我觉得腾讯的职业四大层级，几乎就是人生发展的四大层级。
第一层是动作执行层、第二层是任务执行层、第三层是战略管理层、第四层是战略决策层。
先说动作执行层。一个企业最多的就是这个层面的员工。或者每个人初入职场，都是从练好一个动作开始。比如，画原型，写代码，写稿子……
而腾讯对动作执行层的要求是：按照品质要求，完成动作、优化效率。注意，没有品质要求的动作，毫无意义。用户体验的不是产品而是品质感。就像你去一个川餐馆吃鱼香肉丝，你感受到的是这家鱼香肉丝的品质。大厨的工作不单是保证把菜炒出来，更是要保证菜品在一个什么样的品质感里。所以麦当劳的桌子永远擦的干净，同样的人在另外一个餐馆未必达到这种清洁标准。因为麦当劳不是要求把桌子擦了，而是清晰地要求达到什么样的清洁品质。
达成品质要求之后，在谈完成动作与优化效率。
任务执行层。就是要把分配的任务及指标，拆解成动作。由不同人组合完成，或者一个团队次序完成。需要在整个过程中，控制人心，安排动作序列，并配置风险，保证完成任务，达成指标。几乎所有铁血创业者都是从这个层级冒出来的。
战略管理层。就是大家永远不理解的那批副总。带兄弟痛快淋漓干活的都是总监。而副总，心累。他们需要根据战略决策，确定任务优先级，配置资源，鼓舞士气。保证战略方向不偏差。
而最高的战略决策层，几乎就是个CEO的活。他需要有前瞻，推动相关资源方做出战略决策，并且获取战略资源。就像亮剑里的李云龙。在除了自己，什么都没有的情况，他可以沟通，说服。一个队伍打没了，马上再拉起一个队伍。只要他还要打下去。
四个层级的核心工作不同，对人的特性的核心需求也不同
在动作执行层，才气很重要。
在任务执行层，责任心，执行力的价值，远大于才气。甚至需要放弃自己的才气，把时间交给众多的兄弟，才能实现任务的完成。
而一个人能否达到战略管理层，核心要考核的是：心力。心力是什么?就是无止无尽操心的能力。资源永远有限，战略常常在变，兄弟都是亲的，永远没人满意。所以，一堆人拉我去当副总，我都谢谢了。因为自己清楚，心力真心不足啊～
战略决策层。愿力。其实我在《决策》那篇文章中谈过愿力的问题。没有愿景支撑的决策都是机会主义。一个人如果心中没有愿，那真是谁都帮不了他。看上去再大都是纸老虎。
所以，人会在哪个层级呆着，度过一生，其实都是因为吃不了其他层级的苦。其实发展个人才气，在动作层呆着，是人生最舒适的选择。
不过那些以才子自居的人，创业往往格外困难，因为在整个创业的战略确定到达成的过程里，最不值钱的，也就是才气。
又：
进入腾讯一年后，我和Free吴宵光吃饭，很认真地敬酒感谢他。这一年在腾讯学了很多东西。Free还反问我，是嘛，学到啥啦?我说我写篇学习心得交给你吧。2年后，还是交作业了。当然学到很多不止这些。。
腾讯还是一家非常强大的企业。动作人员动作到位，品质严格，没有任何偷懒取巧。任务负责人有高度集体荣誉感，连年会表演个节目都全情投入。中高层干部心力充足，能每天从早6:00到晚1:00持续无至尽地操心。所以，那些要挑战腾讯的企业，只要看一眼动作人员的动作到位度，和高管的心力，就可以自我掂量了。
-
中国式管理_最适合我们中国人自己的管理方式！
● 管理是修己安人的历程
● 搞清楚推、拖、拉的真正用意，合理应用以求圆通
● 以化解代替解决，务求尽量减少后遗症
● 寓人治于法治,更符合中国社会的实际情况
● 做人做事兼顾并重,透过好好做人来把事情做好
● 抱持既不赞成也不反对的心态来包容一切
● 发展事业本身并没有什么目的，必须在经营事业的过程中，完成修、齐、治、平的人生使命，立业才有价值。
● 计划的目的，在肯定今后几年，如何安人？
● 组织的功能，在聚合安人的力量，协同一致。
● 领导的意义，在发挥安人的潜力。
●控制的用意，在保证今后几年如何安人。
● 所有管理措施，无一不与安人密切相关。
● 只有组织成员各守其分，大家才能和合为一，产生强大组织力。
● 安人就是把部分和在一起，合成一个整体，并且促使整体大于部分，和透过已安和人安增进和谐的效果。
● 安人的历程，是由开心而交心，藉交心而共同关心，然后产生同心的一连串心与心的变化。
● 中国人擅长把二看成三，以二合一来代替二选一。
● 以不变应万变是管理的最高智慧，不要因误解而放弃。
● 持经达变是最有效的管理方式，有原则，却必须因人、因时、因事、因地而应变，以求制宜。
● 经是方的，规规矩矩，实实在在。权是变动的意思，要持经达权，合理应变，才能圆通而安人。
● 美国式管理的哲学基础是个人主义，日本式管理的哲学基础是集体主义，中国式管理则是我们常用的交互主义。
● 日本人拿中国的管理哲学，来运用西方的管理科学。
● 中国式管理具有三大主轴，那就是以人为主，因道结合，以及依理应变。
● 中国人相信事在人为，所有的事都是人做出来的，所以管理应该以人为主。
● 若非理念相同，很不容易做到以人为主而又能够密切配合，把工作做好。中国式管理首重道不同，不相为谋，力求因道结合，彼此志同道合，理念相同，更中能够同心协力。
● 志同道合的同仁，由于人心善变，不久之后，可能变成志不同，道不合。各种内外环境的变数，更是随时出现。中国式管理主张依理应变，凡事依据原则，则因人、因事、因时、因地而应变，以求合理。
● 只要合理，怎样变动都可以。
● 中国式管理，重视把人际或人群和伦理合在一起，建立一种差别性的关系，称为人伦关系。
● 中国式管理的交互主义，秉持二合一的态度，将个人主义和集体主义这两种极端的说法，合在一起，形成在集体中完成个人的合理主义。
● 人伦关系，便是以伦理的观点来建立合理的人际关系。
● 对上要有礼貌，但是不能够讨好。以下不宜太严，也不能够过份宽松。平行同事不必太拘束，也不应该过份熟不拘礼。
● 大同必须包容小异，世界大同并非世界一同。
● 凡事未定案之前，十分民主，一旦拍板定案，相当独裁。这种把民主和独裁合起来想，称为专制。
● 法是过去的产物，情是未来的埋伏，只有理才是现在的指标，中国式管理主张依理应变，按照现在的情势做出合理的调整。
● 中国式管理重视树状的组织精神，根部吸收水份，源源不断供应树干；树干也毫不保留地让枝叶予取予求。这种我支持你，你放手去做的精神，符合中国人你办事，我放心的心理需求。
● 上侵下职，妨害员工的学习、成长，更破坏上司与部属之间的合理关系。
● 决策者的大智，指具有相当的专业知识，大慧指有智慧也有德行，三者合一，才是大智大慧做决策。
● 决策以止定静安虑得为过程。
● 至诚可以前知，预测未来才能做好计划。
● 采取无为的执行过程，才能大有为。
● 全面无型的控制，把法律和良心合在一起。
● 考核的标准是错不可以而对并没有用。
● 抱持救人而非杀人的心态来考核。
● 沟通以不明言为基础。
● 有效地会而不议，议而不决、决而不行。
● 领导比管理更重要。
● 老板做好人，干部做坏人，才是良好的配合
● 劝合不劝分，表示站在合理的立场来分。
● 用情理法来领导，最为合理。
● 有本事来拿，拿不到怪自己，是激励的基本原则。
● 先求忠诚再求能力，更加安全。 -
学习top100站点
名称(站点名或人名) 国家 备注
1 Adam Bien 德国 Java EE相关
2 Antonio Goncalves 法国 Java EE相关（《Java EE 5》和《Java EE 7》的作者）
3 Henrik Warne 瑞典 编程过程中的一些思考
4 Billy Yarosh 美国 Java日常开发中的实用代码示例
5 Lars Vogel 德国 Java、Android 和Eclipse
6 Peter Verhas 匈牙利 纯粹的Java
7 Martin Fowler 美国 面向对象设计专家和咨询师
8 Bozhidar Bozhanov 保加利亚 Java EE相关
9 Richard Warburton 英国 Java 8 Lambdas
10 Bear Giles 美国 Java EE相关
11 Marginally Interesting 德国 机器学习
12 Pascal Alma 美国 Java EE相关
13 Dror Helper 美国 代码测试和代码质量
14 Juri Strumpflohner 意大利 JavaScript
15 Reza Rahman 美国 Java EE/Glassfish
16 Phil Whelan 加拿大 Web技术
17 Brett Porter 澳大利亚 Apache Maven 2的作者
18 Ben McCann 美国 一些实用的操作指南（Connectifier的联合创始人）
19 Java Posse 美国 Java相关的一些有用的链接
20 Mark Needham 英国 数据处理
21 Iris Shoor 以色列 调试技术、性能等
22 Yifan Peng 美国 Java开发、算法与数据结构等（一个本科毕业生的博客）
23 Nikita Salnikov Tarnovski 爱沙尼亚 内存泄露
24 Dustin Marx 美国 一些通用的开发技术以及Java、 JavaFX、Groovy等相关技术
25 Bart Bakker 荷兰 敏捷开发
26 Gunnar Peipman 美国 非Java（C#、.Net相关）
27 Dave Fecak 美国 程序员需要知道的工作技巧
28 JOOQ 瑞士 SQL
29 Petri Kainulainen 芬兰 Web技术
30 Informatech CR 哥斯达黎加 Java、Web、Mobile开发
31 Arun Gupta 美国 Java EE
32 Mechanical Sympathy 英国 性能（锁、垃圾回收、编译优化等）
33 Extreme Enthusiasm 意大利 敏捷开发
34 Steve Blank 美国 The Startup Owner’s Manual（创业者指南）的作者
35 Oliver Gierke 德国 SpringSource（现为VMware旗下部门，提供Java企业应用开发平台）
36 Nicolas Fränkel 瑞士 Java EE
37 Blaise Doughan 美国 XML和JSON相关
38 Vlad Mihalcea 罗马尼亚 软件集成
39 Kevin Lee 澳大利亚 Web技术
40 Mikhail Vorontsov 澳大利亚 性能（语言本身的性能研究）
41 Jakob Jenkov 丹麦 Java基础
42 Program Creek 美国 深入理解Java
778
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
