请注意， 本插件的配置文件中包含秘钥， 请您妥善管理好您的博客源码。
您可以把源码保存在本地。
如果要托管在git仓库里，请选择私有仓库，博主本人选择的是免费的gitlab
某些主机，比如Github，禁止百度爬虫访问博客，导致博客无法被百度收录。多亏百度提供了主动提交的接口，这才有了个补救的方法。
除此之外， 使用主动推送还会达到如下功效：
作为一个热情洋溢的程序员，不谈技术，为什么要谈助人？从三个最近的体验谈起。
年初，参加了一个培训，主题是非暴力沟通。参加它，是因为一次和同事讨论，互不妥协，挣的面红耳赤。培训完，我牢记了一句话，”连接在先，方案在后”。互相倾听，互相挖掘对方需求，而后讨论解决方案。接连的好，其实就有了一半的解决方案。培训后，一向信仰技术的我，开始思考人的重要性。
上个月，在三番的JavaOne里，接触到了很多时髦技术，还参加了一个经验交流会。会里，业界的顶级人才分享了影响他们职业生涯最关键的事情。其中Edson Yanaga分享了他的转折点，“和人们建立连接，做一些改变人们生活的事情。由衷的感激，全心的帮助人们”。这段话，对于开始思考人重要性的我来说，就像遇到了知己。
这两天在Hackernews上读到了一篇超过2000分的文章，Be Kind。这么多年几乎没见过超2000的。作者分享了他的故事，说是，有次，他做错了事，准备好被炒。结果老板不但没训他，还友善的问他学到了什么，之后还鼓励他，相信他会做的更好。作者受到触动，如今带新人，他时刻提醒自己要友善助人，看到他人的潜力。看完这个故事之后，我又产生了一次共鸣。
作为程序员的我，往往被对技术的执着和信仰蒙蔽了的双眼。看到了屏幕上的代码，却没有看到电话的那头，有一个止步不前，需要帮助的人；没看到邮件的那边，有一个想得到回复，早点回去接孩子的父亲；没有看到身边的新人，刚起步，渴望点拨。
把出发点放到人上，接电话，回邮件，带新人都是快乐的事情，因为助人。
越来越多的人在谈极限开发，结对编程，测试驱动。人们以今天的标准，审视着往日的代码，嗤之以鼻。然而，当今的规范并非横空出世，它是经历了计算机科学，互联网技术发展的不同阶段，而逐渐演变成如今的样子。一个时期的代码，有着那个时期的历史局限性，不是人们不想写单元测试，而是根本不知道什么是单元测试。
一天，我和一特别执着的程序员聊工匠精神，说他执着，是因为头发都白了，他还在写代码。话不到两句，就开始抱怨代码中的种种不是。因为他开始的早，我好奇的问，你刚开始写代码的时候知道单元测试吗？他说，谁去管单元测试，内存那么丁点，先把代码写进去，能运行再说。
虽然我的问题略显愚钝，我却突然想通了一件事。因为我身边的这位执着的程序员，不是他不懂得工匠精神，也不是不知道单元测试，而是那时候，它们根本不存在。我们不能因为今天有高铁，就看不起当初的小推车。所处的历史环境不同，满足的需求不同，实现的方式当然也就不同。因此我们得去学会体谅这些历史局限性。
然而，懂得体谅并不意味着忽视问题。小推车被高铁取代了，而没有单元测试的代码，却依然充斥在我们的软件中，阻碍着我们前进的步伐。而谁又能确定，我们如今所崇尚的编程方式，设计原则，不会成为明天大家的笑谈？我们是不是也活在我们的局限性里？文字到这，我只看到了四个字，与时俱进！
我在同一个部门一做就是五年，从毕业的小毛孩子做到了现在的高级软件工程师，很多人都认为，五年可以了，可以换一换工作了，可我又发现了新的乐趣。与其说是乐趣，到不如说是遇到了新的困难。克服这些困难反倒成为了乐趣，一种学习的乐趣。我深信，不论是知识的提升，还是为人处世能力的提升，都需要通过克服困难来达到。
在一个地方做的不开心，我们有两种解决方案，一是良禽择木而栖，去寻找更好的地方。二是克服困难把一个不开心的地方变成一个欢乐的地方。两种方案，孰优孰劣？答案是看情况。如果运气不好，遇到了一个志不同，道不和，不足与谋的老板，最好赶紧走人。但如果老板理解你的追求，支持你的工作，给你足够的信任，那么对于一个不轻言放弃的人来说，最好去克服困难，努力把大家的生活变得更美好。
在将近工作了五年之后，不尽如人意的地方越来越多，比如说缺乏长远目标，战线过多造成的工作效率低下，以及缺少实现核心价值的机会。之前的几年，我一直很被动，一是我没有意识到诸多的问题，二是过于天真的相信明天会更好。
现如今，与其是把希望寄托于他人，我决定用自己的双手和智慧主动打造理想的工作环境。在我把我的想法和老板谈完之后，他不仅没有反对我，反而希望我能付诸实践，帮助他一道把团队做的更好。如此一来，我又从新点燃了战斗的激情，抛开最终结果不谈，开启这段经历本身就是一笔宝贵的财富。
这种思维的转变，已经有两周了，体会到的最大不同，就是具有了主人翁的意识。之前工作，是把工作当成任务，被动的去完成。有了主人翁的意识之后，目的不再是单纯的完成任务，而是如何通过完成任务来理清我们的长远目标，找到有力的指导思想，提升工作效率，为自己创造更加具有挑战性更加蕴藏机遇的工作环境。
短短的两周时间，抱着克服困难的心里，以主人翁的心态，我给自己的工作又注入了新的活力。你如果有类似的疑惑，不妨试试我的方法。
最近发生的两件事，让我很欣慰，它们让我看到了积累的效果，给了我继续积累下去的信心。
第一件事，法国最佳程序员竞赛。在近千人的比赛中，我取得了初赛第一，决赛第十四的成绩。赢了一个免费去荷兰度周末的机会。
最终得到通知是比赛开始的三天前。因为之前报名晚了，被放在了等待列表里。因此，我并没有对这次比赛进行针对性的训练。然而，我还是有所准备。从2015的Google Hashcode的比赛失利受到激发后，我就开始锻炼算法的基本功，看算法书，上算法课，参加公司的coding dojo。
初赛，一共三题，45分钟。前两道，基本功扎实的选手都可以解出来，只有第三道，突然增加了难度。看完题之后，我认出来了，这是一道基于动态规划的经典题目的变形，word distance的加强版，这个模型见过。面对这个经典问题，我没多犹豫，直接在网上搜出了解决方案，word distance with swap。提交，通过！这时离比赛结束还有十分钟。
比赛哨声吹响了，裁判开始宣布结果，说只有一个人做满了三题。在他喊出我名字之前，我已经开始澎湃了，因为我知道肯定是我。在众人面前脱颖而出是一种很奇妙的感觉，几个其他参赛选手向我走来，百思不得其解的问我，你怎么可能在这么短的时间里做满了三题。
决赛的第一题，有经验的人很快可以看出来是minimum spanning tree的问题。第二题，难度更大了(据我推断，是一道balanced graph partition的模型)，没有一定功力的人是解不出来的，其实所有的参赛者中只有一人攻破了它，他成了最终的冠军。
平日的积累，一点一滴的，很难看到效果，但到了一定阶段，到骨子里之后，在一些不经意的时刻，它们的功效就会显现出来。就像一个习武的人，突然有一天他发现，它好不经意的躲过了别人的进攻，好不经意的发现可以跳的很高，练成了轻功。
第二件事，我给公司的另外一个组和一些主管做了关于spark和storm的报告。
有一天，公司里的一个大boss给我打电话，问我有没有空。我当时很惊讶，因为他的级别比我高很多，并且工作没有交集。我以为他要挖人给我升级呢。后来，他带我到了他办公室，想让我给他讲讲spark。我说为什么是我呀，他说，因为我写的内部博客他看到了，很感兴趣。他问我有没有时间给他讲一下，我就必须有时间的给他讲了一遍。他感觉很好，没过两天，我就把这些东西给他手下的一个组外加其他组的几个管理者，讲了一遍。
其实，对spark和storm的研究是一年前的事了，当时只给一小部分人做了汇报。可即使是一小部分人，我也是很认真的做了幻灯片，没放松报告的质量。讲完之后，我延续了写作的习惯，写成博客给大家分享了。没想到，后来还真有人看上。这件事，一方面证实了写作的各种好处，第二就是说明事情不论大小，不论受众面有多大，只要认认真真的做好，就可能会有惊喜。
平时看到一些杰出的人把一些事做到了完美与极致，很崇拜他们，也很向往成为他们那样的人。这两件事，虽然不是什么可以值得吹嘘的大事，但毕竟给我带来了一些成就感，也更加坚定了我的信念，任何能把事情做到极致的人，肯定不仅仅因为幸运，他们平日里默默的积累，给了他们抓住机会的实力。
之前类似这种题目的文章很少去读，可最近这种想法经常闯进我的思考范围。可能是人马上要三十，到了要想这个问题的年龄了。和其他关于衰老的话题一样，谈起来难免有些淡淡的忧伤。可认真的琢磨之后，发现未雨绸缪是件好事，能看到忧伤背后的从容和坦然。
程序员也是人，所以有人的共性。十几二十的时候，很少会想到老。一是忙着学习考试，没时间。即便有点时间，搞搞对象，打打游戏，也不会轮到它。说白了，还是因为年轻，可塑性强，没什么好怕的。到了快三十的时候，就不一样了。工作之余，时间有了。人闲了，就容易琢磨事儿，还老爱自己吓自己。其次，三十岁的人，慢慢意识到老为何物，爷爷奶奶听不清看不明了甚至走了，爸爸妈妈白发多了。最后，想再折腾的时候，发现已经到了生育培养下一代的年龄，担的责任越来越重，不敢再冒险了。在这种情形下，如果还找到良方来从容应对年月带来的冲击，就会有危机感，害怕老无所用。
一个人随着年龄的增长，经验会更丰富，同时，精力也会减少。所以上了年纪后，要学会利用积累的经验去创造价值，而不是单纯的用精力去和年轻人拼。
明白了这一点，就应该注重经验的积累。如何积累呢？首先，得从自身找出路。做同样的一件事，有的人爱观察，爱思考，可以了解事物的本质和内在联系。也有的人，只注重事物的表面，不加深究，只获取看得见，摸得着的果实。日积月累，前者的经验当然会越来越多。其次，要借助外力。有的环境利于经验的摄取，而有的环境只会单纯的让人变老。一个充满挑战需要开拓创新的环境，和一个整日复制粘贴的环境，它们所蕴含的经验有天壤之别。
所以，作为程序员的我们，要勤于观察，善于思考，特别是在这个各种框架、语言、技术日新月异的年代。拿大数据这个炙手可热的新名词来讲，从之前的Hadoop和到之后的Spark框架，技术革新速度是令人无法想象的。然而，爱思考的程序员们会发现，有些东西，的确变了，而有的东西是没有变的。比如说基于图的数据结构和算法，分布式系统的扩展性和可靠性问题，以及系统性能的测试和优化方法，这些基础通用的懂事是没有变的。Spark的核心思想RDD是一个创新，不求甚解的人只会学习如何使用它，爱思考的人会摸清它的来龙去脉，知晓它的优势和局限。这样一来，牢固的基础和丰富的经验可以帮助很快的掌握新的技术。
谈完思考的重要性，再看看环境，上面说到的开拓创新的环境，是很好，可没有怎么办？答案是看你想不想要。环境是可以争取的，甚至可以自己创造的。
我在现在的公司，在同一个职位干了快有五年了。干了三年后，工作开始漫漫变得重复乏味起来。大部分的时间是我帮别人解决问题，而不是我去请教别人，输出大于输入。为了能创造一个更加开拓创新的环境，我曾经“威胁”老板说，如果再找不到具有挑战性的项目，我就要走人了。后来，在我的推动下，终于找到了让我满意的项目和环境，争取到了和公司架构师们一起做项目，向他们学习的机会。除此之外，我还去参加编程比赛，程序员见面会，主动做演讲。这些都是为了创造互相交流学习的环境。
说了这么多关于经验积累方面的见解，我想简单的谈一下精力。精力会随着人的衰老而减少，这是无法阻挡的自然进程。我们能做的，就是放慢它的脚步。唯一方案，就是运动。相信大家都明白生命在于运动的道理，我就不多说了。
上面说那么多关于经验的事，只是想从职业竞争的方面说明，老并不可怕，只要方法得当，经验可以转化为不可或缺的优势。加上运动的好了，可以老将出马，一个顶俩。
接下来，说说潜心治学的态度。很多人程序员做了两三年，就想着转行，转产品，转客户，转管理，就好像那些行业不需要养老一样。如果是对编程失去了热情，那么如此做便是无可厚非。但如果仍热情饱满，却因为担心程序员的未来，而转行，那么就没有必要了。
首先，从专家程序员的市场价值来说，他们能够解决别人解决不了的问题，他们能够看到别人看不到的深度。再某些难题面前，一个专家，不能被十个初学者换掉。因为这不是一个搬砖的过程，而是一个修行达没达到深度的问题。除此之外，潜心治学，可以满足人们对知识上的追求，有的快乐并不是金钱所能买得到的，刻苦钻研，攻克难关本身就是一个可以给人以巨大成就感的事情。
潜心治学，成为大家，并非易事，也正因为如此，它是一条可以让人实现巨大自我价值的道路。这样的人，从小的来讲，可以是某些项目的带头人，可以是专利的获得者，可以是书的作者，可以是一个讲师。往大的讲可以是图灵奖的获得者，可以是改变整个世界的人。
哗哗啦啦用了好几天的时间讲了这么多，一是想告诉自己，要沉下心来，做自己喜欢做的事，并且享受这个过程。其次，是要记录下，处在三十岁的这个关口，我对程序员人生的看法。也分享给其他的程序员朋友，共勉。
我是热情洋溢的程序员，王辉。
我们约好的是十二点见面，后来被推迟了，因为他要见客户。中午饭没能在一起吃，下午两点和他见着了，在分别了三年之后。
我们是老乡，都生在河南商丘。也是在法国求学时的校友，他读博士，我攻工程师。他自己动手作过馒头，从和面，发面，揉馒头，到下蒸锅，确实有一手。后来他学成回国了，带回去了一个媳妇，在法国认识的北京妞。走的时候，他把蒸锅留给了我。我学完直接留在法国工作了。
后来，从朋友圈里得知他创业了。我又找到了他。因为我也有一颗不安的心，即使工作三年之后的我已经过上了小康生活。
两点多见着他的时候，他的面庞依旧是那么的棱角分明。此刻的棱角分明，已不是青春小说里俊美男生式的棱角分明，而是经历过风雨雕琢后的分明。略高的颧骨，加上头上冒出的几撮白发，不禁让我想到沙漠中经受风蚀的石头，几分凉意侵入心中。他的穿着很朴素，要不是知道，我万万不会把他和电视里光鲜亮丽的CEO联想在一起。
他把我们带到了大厦后的星巴克咖啡馆里。我要了杯咖啡，他只点了一杯白水。三年，可以发生很多事情在一个人身上，也可以只简简单单的让他老三岁。不知不觉聊了三个小时，听完他创业的故事，我觉得他的白开水比咖啡浓。
后来，到了大厦的十五楼，他们的办公室，地方不大，四五十平米的样子，摆满了办公桌。进门的时候，大家纷纷把目光投向了我，我看到的是一群年轻并且富有朝气的面孔。一一握手后，我给他们讲了一些我工作中学到的知识和总结的经验。他们听的很认真，不少人拿着小本做着笔记。可以感受到他们学习的积极性。
讲完，大家所有人到楼下吃了西少爷，来自西安的快餐，豆花加肉夹馍。吃完饭，七点了，他们又陆陆续续回到了办公室，赶任务。
我又和他聊了许久，他讲到了他遇到的困难，高高的股份，低低的工资，家人对他的不解，商场的黑暗，技术上的困惑，招人留人的烦恼，管理上的摸索，国外国内的落差。但他很坚定，千难万苦，不曾动摇。
这就是我看到的一个创业者，一个可敬的创业者。
工作了四年以后，我升职为高级软件工程师。这里的升职不是管理上的提升，其实我现在只需要管好我自己，而是对一个软件工程师成熟度的认可。一个高级工程师，较之一个刚毕业的新手而言，他应该能够独立的推进一个项目，从技术，到和其他组的交流协作，都能够独当一面。我最近遇到的一个难题，就是如何和产品经理有效的协作来保证项目的进度。后来学习到一个秘诀，就是要别人的承诺。
具体的故事，是这样发生的。我和项目经理，一起制定使用者剧本(user story)，会议结束的时候，我们分了工。我的项目经理，要先在这些剧本里，加入验收测试，然后，我再预估它们的复杂度。换句话说，我的任务依赖着他的，他做不完，我就起不了步。
当天下午，大家很高心的散会了。第二天，我问他测试写明白了吗。他说他明天给我，我说好吧。可第三天，依旧没写好。我问他，他又说再等一天。三天过去了，剧本没写好，没测试，我没开工。
后来我的上司看到了，略有不爽，他说，怎么都第四天了，还没有开工。我当时想辩解，说不是我的错，因为我得等别人的活完了才能开始自己的，我是被别人耽误了。后来想辩解也没有意义，特别是这种推卸责任的辩解更没有意义。我的产品经理，当时也意识到自己确实没做好，在第四天，他写了测试。
后来，我找到了老板，高级高级工程师，问他我在这种情况下，应该怎么办？他给我讲了一下他作为新手时犯的错误，也给我说了一个解决办法。
在他是新手的时候，如果他依赖的人太慢，我老板就自己替他人把活做了。这样进度会有，但不是长久之计。首先，替他人把活做了，僭越了不说，到时候万一你做的并不是人家的本意，之后还得重头再来，特别是这种产品经理写验收测试的活，程序员一定要让他们从产品，从用户的角度来写测试，不能以程序员对产品的理解去写。其次，即便替人做的好，可自己的精力毕竟有限，不能作为长久的打算。
所以不可取，那么什么可取呢？回到我的经历中来，第一天，大家高兴散会的时候，不能就那么散了，而要问清楚，你什么时候能给我一个满意的答复，我们需要对方的一个承诺。承诺的远近并不是问题。远了，说明他有优先级更高的事情要做，要么，我不能干等，要么，我们把问题上传给决策者来重新讨论优先级。近了，更好。承诺的重要性在于明确各方的责任点和责任段，是为了更有效的交流，不至于把时间用在等待里。
技术负债，指的是为了实现客户的某个需求，而做出的一种短期见效快，长期有伤害的，在技术层面的决定。更通俗的讲，就是坐在代码面前，只顾现在，不管将来。代码满足了客户的需求，却写的很糟很乱，为以后进一步开发新功能，做了一个坑人的铺垫。
上面讲的是技术负债的大概意思，下面讲以一个亲身经历的故事，想说明的是，技术负债，如果你当时不还的话，一旦错过了那个村，以后就很难再找到那个店，想还就难了。
出于不能透露公司秘密的目的，我就只笼统的说一下，（其实和模拟金融产品的收益与亏损有关，;p）。那是一个规模挺大的开发，引入了不少新功能，用了基本一年的时间。出于模块复用的原则，也就是不再造车轮的原则，我们最大限度的重用了原有的模块。由于原有模块的使用情景和新功能的情景大有差别，在重用之前，我们先改了原有的，使它从不可以被重用改善到可以用。说实话，改的有点牵强。
新功能实现了之后，客户很开心。可我们，总感觉有些地方不太对，略加分析，发现，两个不同情景下的模块有不少共同之处，其实当初应该再往前走一步，把共同的部分隔离出来，写一个更加抽象的模块。把确实存在差异的部分放在不同的模块里。
我现在说的听起来容易，其实做抽象没那么显而易见。这要求你，从更深次的角度去分析两个不同的问题，融会贯通，找到它们的共同点。抽象，在编程的各种能力中，处于一个很靠前的地位。
问题发现了，可我们却作难了。为什么？因为新功能已经交付了，客户也很满意。你现在非得给客户说，能不能再给我两万块钱，让我好好抽象一下。哈哈，你不是在搞笑吧？给你钱让你抽象？！你抽不抽的好是一方面，万一把原有的东西也破坏了，你这不是让人家客户抽搐吗。
其实我们的客户不是那种不懂开发油盐不进的客户，他们也知道，现如今不抽，以后再开发新功能的时候可能就会更难。可是既然新功能好用，他们又有很多其他方面还没实现的想法要做，他们更倾向于立即着手于其他的项目，等以后有时间了，也有闲钱了，再让我们搞那些很抽象的工作。
可你仔细想想，谁会有时间，谁会有闲钱？所以技术负债，就像打尖住店一样，过了那个村，就没那个店了。
真的就没有解决方法了吗？我思来想去，结论是没有什么神奇的方法可以解决所有的问题。
你可能会说，留在那个村，别走，解决完问题，再走不就行了吗。我同意这个观点，留在那里不走可以，前提是你给客户预先说好，你需要多少时间，多少预算，才能把问题解决的好。可实际情况呢，很多潜在的问题，在项目初期很难被发现，很多问题都是在实践的过程中发现的。敏捷开发，有利于解决类似的问题。但是越是到后期，和技术负债相关的请求，就会越难被接受，因为的他们的投入产出比小，风险大。更糟糕的情况是，有一些东西，是需要事后的消化，后知后觉的，就像我上面遇到的情况一样。
设计重要，前期周全的设计更是重中之重。小的负债一定要在它的萌芽阶段就消灭掉，越早越容易说服别人。
谢谢您逗留阅读，我是热情洋溢的程序员，王辉。
用Jekyll管理博客，单纯写文章很便捷，但是它的扩展性，灵活性和对配置的支持都相对局限，这是我转向Hexo最重要的原因。
扩展性，指的是Jekyll框架内，更换主题，增添插件的功能。开发新Jekyll主题，很容易上手，从Jekyll主题的数量上便可见一斑。可它的问题出现在，更换主题的难度上。在我的Jekyll博客里，我必须把老的主题删了，然后把新的主题加进来。更不友好的是，一个主题可以包含很多文件，而这些文件分布在不同的文件夹里，删除一个主题，意味着先辨认出这些文件，而不是删除单一的一个文件夹。
在Hexo里，有两层配置。一是博客的整体配置，比如博客的名字，作者，链接的形式，最重要的，是对主题的选择。第二层配置，是主题的自定义，比如是否激活评论插件，是否使用某个配件。
而这两层配置正是Jekyll里所缺少的，导致切换主题的时候，我们找不到博客和主题之间的桥梁。