标签：anti 质量 模式 man 通话 学习方式 building 开始 rest api
在我成长初期，我制定了一些计划来实现下面的一些能力：
除了第一步，每一个步骤都花费了相当长的时间来学习，光在学习方面就差不多一年了。
虽然这看上去是一件很难的事，但是也不是一件很难的事。这也不依赖于你是否对某一个技术栈的理解，这只实际上只是学习能力的一种体现。
todo-example.png
在扯这些废话之前，先让我们来看看我们是如何实现一个功能、应用的。这也是在Growth里提到的Tasking：
以本文的写作为例，细分上面的过程就是：
而如果将其划分到一个编程任务，那么也是一样的：
所以，实际上这并不是考验你技术能力的点，而是考验你如何划分任务和学习能力的点。在我不断地实现一个个系统的时候，最后我才意识到了这一点——学习能力和Tasking才是最重要的。换句话说，你现在学会什么并不重要，重要的是你以后有没有学习的能力。
有了一直想着过安逸的生活，所以就会安乐的死去。不过反正人生在世，自己开心就行，不要管别人怎么说。随后，我发现大部分我想到的都可以实现。
那么问题来了：
这实际上就是：用更好的方法来实现功能。
对于这一步来说，有太多的东西值得去探索:
对于语言这一点上来说，Python和Ruby是两个不同的极端，不过看上Ruby是继承Perl的思想的基础上，就不多说了。Python，一个问题只有一个方法;Ruby，一个问题有几个方法。因而在这两个语言来，想要快感就用Ruby，还有近年来流行的Scala。想要便捷就是Python，不容易出现别的问题。
而这些只是我得到的结论，每个人都会得到不同听结论的。因而，探索是一件很有意思的事~~，如图：
civ5-worst.jpg
所以实际上，这一步是去探索一个更广阔的天空。我们需要知道不同的语言和技术栈的一些优势，了解并知道如何去应用即可。
如，以前我用的是Django的RESTful方案Tastypie管理来解决问题。后来，又发现了Django REST Framework，又用它实现了原来的逻辑。大四时，我发现PHP语言中的Laravel在RESTful这件事情上，似乎很有表现力，并且更容易“部署”——LNMP。接着实习时，发现Java在部署上更不错，它只需要一个Java包。而这个过程，只是出自于部署方面来考虑问题的。
即使现在我是一个使用Node.js的人，我还是觉得Java的打包就是优势。
在探索的过程中，我们就知道挖掘技术哪家强？
在实际编程的过程中，我们就会遇到很多代码问题。在这时，我们尽管有好的架构，然而并不能从根本上解决问题。只能保证从蓝图上看是对的，而不能导致质量问题。
better-architecture.jpg
代码的腐烂都是源自于平时的工作习惯问题，而在很多时候是需求导致的。这些看上去就是噩梦——加班，没有时间学习，效率低。没有时间学习，效率低，加班。
eff-worknight.png
而对于代码质量来说，也是如此的一种循环：
code-time.png
而在这时可以学的东西可多了，如Bad Smell，重构，设计模式，编写测试等等。
最后，我只得到了一个短句：
重构到设计模式
好的代码是重构出来的。
再往深层次之上就是架构，而架构往往是一种不容易得到的。尽管我看了一系列的书：
最后，我还是依据一本书的书名，才领悟了一本书的书名《浮现式设计》。也是同样的话：
好的架构是演进出来的。
而这些都依赖于我们的实践，听信别人说的话，并不能让我们学会什么。只有自己做了，才知道什么是好，什么是不好。
当我们有了一个好的Idea，一个好的架构以及一份良好的代码，并且我们还能将其执行下去。那么，我们还需要什么？
what-is-growth-hacking.jpg
这也是我现在正在尝试的领域，也是过去我想做的，但是却找不到一个好的方向。后来，想了想就有了Growth这个APP。毕竟从一个领域到一个新的领域，最好是通过现有的领域作为过渡。
自媒体正在最近几年内崛起，同时由于聚合网站的存在，信息在不断地爆炸。一个好的作品、文章要传播起来已经越来越越难了。
在现有的领域里，知乎、微博、公众号已经开始在垄断人们的碎片时间。一个东西可能在火了几天之后，你就很难得到他的信息了。
所以在适当的时候去推销，在适当的时候持续下去。
在那之前你需要明白的一点是，你要成为一个怎样的人？是行业的专家？还是领域的专家？等等！
cat-interest.jpg
我想的是一直可以做一些有趣的事，单纯深入一个垂直领域对我来说太枯燥了。对于我来说，我只会在造轮子的时候去研究一个轮子。而不是深入研究某个轮子，我会得到造某种轮子的方法。我只会在创造一些有意思的东西的时候，才会深入某个领域去学习。而不是为了深入某个领域，再去学习这个领域的知识 。。
每个人都可以用不同的方式成长，知道自己的喜欢的然后去计划。
过去曾经写过一系列的文章，试图去鼓励更多的人去写文章。从毕业前的《成为笔杆子》、《写作驱动学习》、《重新思考博客的意义》，到工作后的《如何提高影响力》，都在试图去向人们展示写博客的可以促进自己学习、提高自己的影响力。
等到工作以后，发现想写的人是没有时间，不想写的人不存在时间。人们陷入生活的怪圈，越是加班越没有时间学技术，越是没有时间学技术越是需要加班。
我尚不属于那些技术特别好的人——我只是广度特别广，从拿电烙铁到所谓的大数据。不过相比于所谓的大数据，我想我更擅长于焊电路板，笑~~。由于并非毕业于计算机专业，毕业前的实习过程中，我发现在某些特殊领域的技术比不上科班毕业的人，这意味着需要更多的学习。但是后来受益于工作近两年来从没有加班过，朝九晚六的生活带来了大量的学习时间。在这个漫长的追赶过程中，我发现开发博客相关的应用带来了很大的进步。
当你开发在网页上访问我的博客的时候，你可能会注意到上面的协议是HTTPS。
[blog-mobile][1]
但是并不会察觉到它是HTTP2.0。而这需要一个可以支持HTTP2.0的HTTP服务器，在不改变现在程序配置的情况下，你需要重新编译你的HTTP服务器。在这里，我的博客用的是Nginx，所以它在还只是试验版的时候，就已经被编译进去了。为了隐藏服务器的版本，还需要在编译的时候做了些手脚。除此，为了浏览器上的那个小绿锁，我们还需要一个HTTPS证书，并在Nginx上配置它。
在这时，我们还需要配置一个缓存服务器。过去，我在上面用过Varinsh、Nginx Cache。尽管对于个人博客来说，可能意义不是很大，但是总需要去尝试。于是用到了ngx_pagespeed，它会帮我们做很多事，从合并CSS、JS，到转图片转为webp格式等等。
Nginx对请求转发给了某个端口，就来到了WSGI。
接着，我们就来到了Web服务器网关接口——是为Python语言定义的Web服务器和Web应用程序或框架之间的一种简单而通用的接口。现在，你或许已经知道了这个博客是基于Python语言的框架。但是在我们揭晓这个答案之前，我们还需要介绍个小工具——New Relic。如果你在Chrome浏览器上使用Ghosty插件，你就会看到下面的东西。
[New Relic][2]
New Relic是一个网站监测工具，Google Analytics是一个分析工具。但是，不一样的是New Relic需要在我们启动的时候加进去：
nohup /PATH/bin/newrelic-admin run-program /PATH/bin/gunicorn --workers=2 MK_dream.wsgi -b 0.0.0.0:8080 --timeout=300& 现在这个请求总算来到了8080端口，接着到了Gunicorn的世界里，它是一个高效的Python WSGI Server。
过了上面几步这个请求终于交给了Django。
Django这个天生带Admin的Web框架，就是适合CMS和博客。这并不意味着它的工作范围只限于此，它还有这么多用户:
[Who Use Django][3]
请求先到了Django的URL层，这个请求接着交给了View层来处理，View层访问Model层以后，与Template层一起渲染出了HTML。Django是一个MTV框架(类似于MVC之于Spring MVC)。接着，HTML先给了浏览器，浏览器继续去请求前端的内容。
它也可以用Farbic部署哦~~。
这是一个现代浏览器的前端战争。最开始，博客的前端是Bootstrap框架主导的UI，而移动端是jQuery Mobile做的(PS: Mezzanine框架原先的结构)。
接着，在我遇到了Backbone后，响应了下Martin Folwer的编辑-发布分离模式。用Node.js与RESTify直接读取博客的数据库做了一个REST API。Backbone就负责了相应的Detail页和List页的处理。
尽管这样做的方式可以让用户访问的速度更快，但是我相信没有一个用户会一次性的把技术博客看完。而且我博客流量的主要来源是Google和百度。
然后，我试着用Angular去写一些比较特殊的页面，如全部文章。但是重写的过程并不是很顺畅，这意味着我需要重新考虑页面的渲染方式。
最后，出现了Material Design Lite，也就是现在这个丑丑的页面，还不兼容新IE（微信浏览器）。
作为一个技术博客，它也用到了HighLight.js的语法加亮。
在构建SPA的时候，做了一些API，然后就有了一个Auto Sugget的功能：
[Auto Suggest][4]
或者说，它是一个Auto Complete，可以直接借助于jQuery AutoComplete插件。
或许你已经猜到了，既然我们已经有博客详情页和列表页的API，并且我们也已经有了Auto Suggestion API。那么，我们就可以有一个APP了。
偶然间发现了Ionic框架，它等于 = Angluar + Cordova。于是，在测试Google Indexing的时候，花了一个晚上做了博客的APP。
[Blog App][5]
我们可以在上面做搜索，搜索的时候也会有Auto Suggestion。上面的注销意味着它有登录功能，而Hybird App的登录通常可以借用于JSON Web Token。即在第一次登录的时候生成一个Token，之后的请求，如发博客、创建事件，都可以用这个Token来进行，直到Token过期。如果你是第一次在手机上访问，也许你会遇到这个没有节操的广告：
[Install Phodal Blog App][6]
然并卵，作为我的第七个Hybird应用，它只发布在Google Play上——因为不需要审核。
随后，我意识到了我需要将我的博客推送给读者，但是需要一个渠道。
借助于Wechat-Python-SDK，花了一个下午做了一个基础的公众平台。除了可以查询最新的博客和搜索，它的主要作用就是让我发我的博客了。
[Phodal QRCode][7]
对了，如果你用Python写代码，可以试试PyCharm。除了WebStorm以外，我最喜欢的IDE。因为WebStorm一直在与时俱进。
So，在这个博客里会有三个用户来源，Web > 公众号 > App。
在网页上，每天大概会400个PV，其中大部分是来自Google、百度，接着就是偶尔推送的公众号，最后就是只有我一个人用的APP。。。
Web架构
服务器：
DevOps:
Web应用后台：
Web应用前台:
移动端:
微信端:
转变是一件很简单的事，当你觉得是时候时。
最近的几星期里，在集成一个第三方的 SDK 到我们的混合应用里。这就意味着：要继续和繁琐的 Java折腾，要开始编写 Objective-C，并和难用的 XCode 的作斗争。
大学的时候，因为参加一个硬件的比赛，还在用 Nokia 的我，买了一个古董 HTC G1 开始学习 Android 应用开发。等完成比赛后，几乎就不再编写相关的代码了。
影响力 => 可信度和信任
比起写业务代码更不幸的是，主要工作是修 Bug，bug，buG, bUg。
在一家大的公司里，不同的人总会有不同的运气：
我刚毕业那会儿，所在团队的主要工作是，维护一个『又老又旧』的系统。比起写业务代码更不幸的是，我们的主要工作是修 Bug，bug，buG, bUg。
那一年多里，尽管都是维护旧系统和少量的新需求，我们还是在飞速的成长~~。而来源主要是：
当你在有限的条件下，还能做出一定的成绩，到底还是相当有成就感的。
在这样的项目里：
有一天，业务人员来了一个新的需求。虽然只是加上一个新的导航，但是你总会小开心一会儿。
可你来到这样的项目时，你总会想着离开，向自己的 Buddy、PM 、Sponsor 诉说。可惜，你只是一个毕业生，太年轻了。对于你来说有挑战性的项目，不会考虑要你的。在你的感觉里，那种『自己是大公司的轮子』的感觉就特别强烈。多你一个不多，少你一个不少。你走了也不会影响这个项目，毕竟招一个人来修 bug，还是蛮轻松的。因此，这个项目走了一个又一个技术好的人，却也来不了一个技术好的人。
时间一久，每个人都充满了危机感。我们总是担心：当你换到另外一个项目的时候，别的项目 PM 会考虑你么——因为你是来自这个没有挑战性的项目。这个时候，你已经无路可走了，你必须去提高你自己。
当别人救不了你的时候，你只能自救。当别人救不了你们的时候，你们也只能自救。幸运的是，我们当时还有足够的时间，可以提高项目组的水平。于是，我们对组织了各种的组内技术分享、workshop、培训等等。
当你有强烈的改变意识的时候，那么事件就会变得很简单。真正可怕的是温水煮青蛙式的，而当你面对的是温水，你总会不断尝试去离开。
当你们项目无聊的时候，总会空余一些时间。上进一点，就会创造一些学习的条件。有了条件，那么剩下的就是靠人为了。
于是乎，我们在每周挑取了两个时间，做一些技术的事情。包含了下面的一些内容：
不同的活动都有不同的目的，有的可以提高演讲者的技术能力，有的则是可以一起提升能力。下面就让我们详细了解一下不同的活动。
想必大家都已经知道这个是什么了~~。当时的情况，大概是我们七个人里，每周会有两次技术分享。分享的主题会比较广泛：
你最近在玩的技术栈。当你们所用的项目技术栈，比较老旧的时候，就想不断地去尝试新的技术。在工作之外，便会去玩一些『新鲜』的技术栈（坑）。它就像是一股清流，即使不能帮你清除旧的污水，也能让人们看到一丝希望。而且除了能提升团队的视野，还可以将之视为替换现有架构的探索。
项目相关的技术及业务。在没有结对编程的项目里，共享知识对于团队来说是一个头疼的问题，而技术分享就是最简单的方式。不过，对于新人来说，让他们做相关的技术分享才是最好的方式。这也视作为我们对新人的考察：
在项目上，这几乎是每个新人都会经历的一个分享~~。
特定主题的技术分享。即，我们限定好一个大的主题，每个人挑选一个特定的主题来分享，它可以人为地提高整个组在某一领域的水平。当时我们做过 SOLID、设计模式、前端相关等特定主题的分享——每个人挑选设计模式中的一个模式，然后做相关的技术分享。当你做分享的时候，你对这模式就比较了解；而别人做分享的时候，也能引发你的思考。由于这些主题之间的相关性比较强，它可以加深对这一领域的印象。
其他杂七杂八的内容。过多的技术分享，可能会导致大家精疲力尽，因此就会有一些技术之外的分享。比如，你喜欢的各种动漫啊、知乎上流行的程序员女装啊等等。
而就效果来说，技术分享对于分享者的能力提升比较大，听众则是知道有这个东西，启发性一般都会比较少。如果是针对于提升能力来说，应该采用 workshop 等方式。
当项目上要采用一个新的技术栈时，仅仅中是一个技术分享是不能解决问题的，你还需要有 workshop 这样的东西。比如你们将在新的项目里引入 Next.js，那么这个时候就需要有一个 Next.js Workshop。由组织者来规划每一步的内容，第一步做什么，第二步做什么，等等。参与者则是单独或者结对的形式，按照组织者的步骤一步步往下来做相关的技术练习。比如在 workshop 开始前，先 clone 并搭建好基础代码（hello, world）。开始的时候，便是先实现一个简单的 header，然后是添加样式等等。
也因此在这样的 workshop 里，我们不仅可以听过相关技术栈的知识，也能掌握一些相关技术栈的具体实践。
一种编程练习方式，针对某个题目反复进行操练，达到熟能生巧的目的。简单的来说，就是你一直练习某一个特别的东西，直到你习惯了。比如，对于 TDD（测试驱动开发，先写测试，并由测试驱动出功能） 的练习。
在平时工作的时候，我们不会总是习惯于 TDD 的流程：测试 -> 实现 -> 重构。特别是，当你的卡就要被打包到新的 Release 包时，先实现总是会保证交付的。又或者是，当你对代码库特别熟悉的时候，你可能两三分钟就改完代码，然后去喝咖啡，再回来花个十几分钟写一个测试。而当你不熟悉 TDD 的时候，你更不会采用这种方式，你会的可能就是 Test First。为了将 TDD 的思维融入你的想法里， 你就需要大量的这种练习~~。
在这个时候，我们就需要严格的按照步骤，一步步往下执行。以便于在将来，我们可以严格的按照这些步骤来执行。
除此，还有一种方式可以做，只是我们没有在这个项目里实施。
dojo，（日语：道场）。在西方世界，dōjō 一词主要指的是一个专门针对日本武术的训练场所。在敏捷团队里，Dojo 的进行方式比较『诡异』，也比较有意思。
如果你了解过结对编程的话，可能就会对两个人的结对过程比较感兴趣。按我的理解，结对编程存在着三种不同的阶段：teaching（引入门），driver-navigator（有经验与新手），结对（有经验与有经验）。即在实现功能的时候，两个人会轮流写测试和实现功能——你先写测试，我实现功能，然后换角色。而 Dojo 就是一堆人在轮流写代码：
Dojo
即在有限的时间里，每个人上去实现同一功能的代码。
如，A 实现了测试，B 上去实现业务，C 上来重构。D 上来看了看，你们写的代码都是 xx，于是 Revert 之前写的代码。可惜 D 的时间也只有七分钟，所以 E 上来 Revert Revert。。。
Git revert revert
笑~~
限于之前已经有相当多的文章，介绍练习相关的技巧，如：
哈哈，如果你觉得你的项目技术栈老旧，那么你一定在脑子里使用了 N 种技术栈，对他们进行重构了。并且当你有一些时间可以分配到上面，如下班前的一个小时时间，又或者黑客马拉松等等。那么，你一定会开始去做这样的事。
与上面的技术活动相比，这是一个对于业务（我的意思是，对于公司来说）更有价值，并且更容易说服别人的方式。
由于我们与其他项目大组的业务是相似的，并且他们的团队规模差不多是我们的 10 倍。当某个新的应用完成后，我们要做的便是：fork from xx，将改吧改吧，应用到我们现有的模式上。这个时候就有问题了，一般这些新的项目都会采用最新的技术栈。在正式引入项目之前，我们都是要学习这些技能，并配合业务做一些修改。也因此，我习惯性的将这种项目视为修改 bug、bUg、Bug。
后来，我们突然有机会弯道超车了，我们可以先重构某一部分系统。『因为已经做好相关的技术积累，并没有遇上一些太大的问题』。只是我们实施一半的时候，就发生了一些意外。后来的后来，这个项目“到期结束”了
现在是 2017 年，当你的项目还在使用旧的 jQuery + Backbone，又或者是 Angular 1.x。并且你们觉得他们有一些问题，这些问题采用一些新的框架，如 Angular 2，又或者是 React 能解决这个问题的话。这个时候，我们就可以尝试去学习新的技术栈，并验证它的可行性。当有一天，你们需要去重构现有系统的时候，你拿出的直接是一个可行性的 Demo，而不仅仅是一个理论上的东西。
当时我们的项目想替换掉旧的搜索引擎，我们先是用 Solr 实现了一遍 DEMO，又用 ElasticSearch 做了一遍 DEMO。同时，我们也在计划替换应用部分的功能，我们先用 React 实现了一遍 DEMO，又尝试用生态纯静态的方式玩了一遍。。。生命可贵，可以多玩就多玩一些吧。
所以，你是因为加班呢，还是因为加班，才没有时间学习？？？
一年多以前，参加过公司的一个『Management 3.0』培训。遗憾的是，没学会怎么当管理者，倒是学会了怎么驱动自己去做更多的事。
人呐，主动做事的时候，总会有动机的。如果不挨冻、不挨饿，吃饭，睡觉这种事就不需要动机的。
这就是内在的驱动力，让自己朝着自己所期望的目标前进。如我过去的 GitHub，我就是要 365 天都在写代码。
它往往比多数的外部激励更加有效。工作多年的你，可能希望少涨一些工资，因此便少加一些班。因为少加一些，你就可以：
好了，应该醒醒了，看看现在的你：整天提不起精神，不想写代码，也不想加班，回家了也不知道干什么。这仿佛就是学生时候的写照啊，上课的时候想着放假，可以去哪里玩，可以从某个亲戚那里拿红包；放假的时候，想着回学校看哪个美女，和谁一起去玩。除此，你还会记得你做过什么吗？
学习的时候，不情愿的去上课；工作的时候，不情愿的去上班。
好在事情并没有那么糟糕。让我们想想，你什么时候会去主动地做一些事情：
在这个过程中，你会发现有一股无形的力量在驱动着你，只是它们都是一些外在的激励。也是我们在生活中常见的激励，『干得好给你多涨工资』、『准时打卡多点奖金』、『成绩好一点排名就靠前』等等。
外部激励是在集体中最容易实现的，也是最常见的。但是效果往往不会那么理想，只有你真正想成长的时候，你才会去成长。
而为了正确的激励你自己，你就需要识别出真正能影响你的内在驱动力因素。在《管理 3.0》一书中提到了十条，团队内部成员的十大需求。你需要从中选出你觉得最重要的因素，然后按顺序排好。在培训的时候，这些内容会被打印成卡片，然后两个成员一组，一个成员向另外一个成员（最好是不熟悉的两个人）解释原因。
这十条内容分别是：
即：
虽然这些内容都是被限定在团队范畴里的，但是我们也可以将这些内容应用到自己身上。现在，你可以从中选出最重要的三个原则，并按顺序排好。
我的顺序是：自由、好奇心、目标。
有意思的是，其中有一些可能有点相似，请注意~~。注意二：在不同的时期，上面的内容都会有一些变化的。
你的顺序会是怎样的？
如果你想要的是荣誉感，那么你应该多参加一些活动。
如果你想要的是地位，那么你应该设法去做更多的领导尝试。
如果你想要的是相关性，那么你应该多去与周围的人交流。
我又编不下去了。不过，我相信你应该能找到对你来说，最重要的点。
经常被问及为什么我可以做这么多的事，换句话来说也就是为什么效率这么高？过去我的答案里，要么是手快，要么是不加班。后来，我发现事情并没有这么简单，于是我便想着写几章文章整理整理。
在过去的两年里，保持了GitHub近两年的连击，存档了上百个项目，还凭借18k个star上榜“GitHub Star榜Top 100”。除此，审阅了两本物联网相关的书，编写了一本物联网相关的书，和基友一起翻译了一本硬件相关的书、一本物联网相关的书，在GitHub上写了开源的电子书。
保持高效的第一要点是，休息。问题是我们可以怎样休息呢？
这些都可以是休息。当我们讨论休息的时候，并不是指在睡觉。只要不是在忙与当前编码相关的事务，那么我们就是在休息。事实上，我们可以将“休息”这个词转变化恢复精力——这才是高效的第一要点。
先让我们来看看在一天里，我们有多少时间是在休息的？
让我们来计算一下，大致时间花费：
这样算下来，一天有一半的时间都可以是休息时间。如果真的可以这样的话，那么我想你不会遇到效率的问题了~~。
之前在西安时，我作息差不多是这样的：
熬夜，对于我来说基本是百害而无一益，很容易影响第二天的体能和思维。因此从某种程度上来说，可以保证我有足够的精力。
而到了深圳后，主要的变化就是下班后，变成了六点走回家——50分钟左右，主要目的就是改善体能。由于这个季节，深圳的温度比西安高，回到住的地方睡不着~~，还在培养中。
并且在晚上时，有了更多的改变：
毕竟，对于像我这样内向性格的人来说，独处才能恢复精力。对于外向性能的人来说，可能出去找几个朋友High一下就能恢复精力。
当你发现你养成习惯后，你就很容易进入状态。比如我在10点时，很容易就可以进入写作状态。当我按时11点半睡觉，我就可以很快进入状态，这些都是习惯造就的。
小时候，我们都是9点钟上传睡觉的，5，6点多起床。。。然后去叫叫隔壁的大哥哥，大姐姐出去玩。
长大了，我们都是11点钟上传睡觉的，然后7，8点起床。。。然后被隔壁的小屁孩叫醒。
从整体上来，熬夜会对身体和精神产生相对比较大的影响。如果你对星期一综合症或者假期综合症有所了解的话，那么你就会知道，只是因为你改变了习惯。
当然，如果你已经习惯了长期熬夜，并且没有负作用，那么你还是相当不错的~~。
这让我想到了猫，所以猫白天根本不理你了~~。
番茄工作法对于我来说，不是那么管用——天生喜欢多动，并且每天我的事务比较单一，就是编码。之所以会出现在这里，是因为它对健康有益。
我正式采用番茄工作法的原因是，在客户现场工作时，影响到颈椎了，加之我在改善尺神经卡压的影响。
这一点特别适合在工作上用，每工作25分钟，就可以休息5分钟。
所以，请使用番茄工作法作为合理的休息理由吧~~。对自己狠一点，就是对资本家好一点——除非你是资本家。
碎片时间就适合刷刷朋友圈、逛逛微博、看看美女，看书什么的一点都不适合。
碎片时间根本不适合学习！
碎片时间根本不适合学习！
碎片时间根本不适合学习！
学习需要有高度集中的时间，你才能集中精力学习。
对了，如果你没有女朋友的话，那么你应该趁这个时间找人多聊聊天天。
每天应该适当做点有氧运动，如果没有女朋友的话，那么你应该出去跑步、散步啊。
只所以强调适当是因为，大量地运动不仅需要占用了你相当多的运动时间，你仍然需要相当多的时间来恢复。
而有氧运动并不仅仅局限于传统意义上的运动：跑步、打球，还可以是拖拖地。
如我最近在家里练习羽毛球颠球——转移眼睛的注意力，也算是适当的有氧运动。遗憾的是，不能在工作的地方练习。
最近软件行来的的用人趋势是把人当成富士康工人用。
要成为一个大牛，就需要准备一场长期的战斗，培养自己的状态。而不是在华为干个十几年出来了，再用这十几年赚的钱去买健康，一不小心挂了怎么办？
要知道，你已经错过进入大公司最好的时机了——现在进去只能成为新一代的富士康工人。你对外所说的每一句话，每一张截图，将成为你被Fire的证据。
相信你已经从很大途径了解到了：“利用碎片化时间学习”是一个陷阱。这是一个非常有趣的事实，但是也不非可利用，比如说：聊天。那么，除了聊天我们还可以玩点什么？屏蔽朋友圈里你老板以外的咪蒙粉；到 GitHub 上给自己的开源项目点个赞；上知乎看看段子、发发广告；到微博看看前端娱乐圈。
除了利用碎片化时间是一个陷阱外，避免碎片化时间又是另外一个陷阱。
编程作为一个脑力工作，在工作了一段时间后，你会很容易发现：感觉身体被掏空了。然后，你的注意力就会越来越不集中，你会想着用喝咖啡的方式来提神，会强迫自己去集中注意力。但是，这一切都于事无补。
然后，你就这样开始了糟糕的后半段时间了。于是，你就觉得你度过了糟糕的一天。
到底是哪里不对劲？你以为你是个机器，实际上你是一个人——一直百分之百运行的 CPU，也是会减寿的。
你需要一个短暂的休息——这就是为什么番茄工作法这么受欢迎的原因：保持高效。
既使你有一定的工作经验，也是如此。而在这时，有一个东西会影响你的工作与休息的时间，即心流：
心流
当然，这是可遇不可求的，就好比是你和你的女神聊在一起了一样。
那么问题来了，我们如何来处理这些碎片化的时间。
当我们有515分钟的碎片时间，那么你想的当然是来提高自己，而在这时最合适的方式就是：收集一些感兴趣的内容——做一个简单的判断，然后将需要的内容进行归类。如你可以将你所需要的鸡汤放到一起，来一锅大的鸡汤~。碎片时间可以干很多事情：
在那之前，我们需要注意一些事项：
避免阅读。任何需要思考的内容都是不合适的，编程是一个脑力活。当然笑话除外：
小侄子早上打了个喷嚏，看他鼻子酸的要哭，我安慰他说，那是因为我在想他，他才会打喷嚏，， 下午带他出去玩，一个卖烧烤的小伙子打了两个喷嚏，这孩子冲上前去就跟人家说:“你知道吗？是我姑姑在想你呢！”
避免思考问题。如果有一个问题你一直无解的话，那么估计你需要一些额外的灵感，需要一些额外的知识汲入——这些知识可能与你现有的知识是无关的。
最适合碎片阅读的，莫过于 GitHub Trending。你可以在上面看到，最新的一些流行的开源项目， 如： HTTP 状态码451：基于法律上的原因，我不能向你展示网页内容。
GitHub Trending 在这方面做得特别好，有一个项目的名称和简介，只需要看一眼就够了：
Growth
能打开项目的，说明你是有兴趣的~~，加入你的 TodoLists 吧，如下：
如果你在 GitHub 为很多项目点亮过 Star，那么你很难找到你感兴趣的项目。这时候，最理想、最简单的方式就是，创建一个简单的 README 项目来放置自己感兴趣的内容。
它可以支持“云同步”、Diff 修改、PR，还可以骗来很多的 Star。
不过，我已经习惯使用我的 Ideas 来管理了~~。
微博上关注了几个新浪微博的员工，然后每天看他们发微博，要么吐槽“渣浪食堂”。
微博食堂
要么吐槽时间线。
这种人要是在阿里，那肯定是不正确的。
如果你看到一些好的文章，那么你应该用一个 TodoList 工具：
这样你就不会看着不阅读了，同时享受划掉一个 Todo 的快感~。
看来你又有一些碎片化的时间，不妨分享到朋友圈，让大家关注一下，哈哈。
为了更好的练习，我们可以做一些事情来提高练习的意愿：
有一句话很有意思——我们就差一个写代码的了。但是，我们经常说的是我们缺少一个idea。过去我也一直觉得我缺少一些Idea，今天发现并非如此，我们只是缺少记录的手段。
大概是在七个前，有一天我在Github上闲逛的时候，找到了一个代码库，然后习惯性的点开了作者的Profile。发现了一个名为ideas的repo，尽管里面只有简简单单地几个idea。但是这让我发现了一个新的大陆，在那之前我一直用OneNote记录我的idea（用的是Nokia Lumia 1020)。
而打开OneNote记录Idea，并不是很方便，有时候是代码，有时候是一篇博客的链接，有时候只是一段话。而且Idea出现的时候往往是在浏览一些网站的时候，Mac OS上的OneNote与Windows Phone的同步又有问题。
紧接着，我开始用Github的README.md和Issues来管理我的idea：https://github.com/phodal/ideas。
半年时间过去了，我的Issues列表里已经关闭17个Issues，大部分是已经完成的idea。而在Open的列表里还有着12个还没开始、或者只进行了一部分的ideas。稍微看了一下，每个Idea大概隔了七天，毕竟是可遇不可求的。
如我最近解决的一个问题是——项目技术栈趋势图。而这个Idea从出现到实现只花了一天的时间，或者这算不上一个真正的Idea。而这个Idea则是依赖于另外一个Idea——技术树。同样的例子还会有很多，这和技术的演进是差不多的，Idea也是一点点演进出来的。
Issues一直是一个神奇的存在，你可以用它当成博客，然后下面就可以有评论。Disqus也许可以和Github合作，这样他们就会有一个巨大的市场，当然这只会是一个玩笑。
Issues是一个非常不错的『工具』，因为它可以打上Tags，你就可以通过此为你不同的Idea进行一个分类。并且每每有一个idea完成的时候，就可以关闭这个Issue了。这就好像修复一个Bug的感觉。
对于每个Idea相关的一些内容，我们都可以以Comments的形式添加相应的内容。
README都会是一个项目的介绍，而且我们也可以在上面汇集我们的所有Idea。如在我的idea列表的README里已经有长长的一堆了。。
每个项目里，都会有一个简单的介绍，如EchoesWorks:
简介：Next-Generation Tech Blog/Presentation Framework
特性：
在一些项目里也会有一些长长的介绍，及截图。
作为一个程序员都有超越BIll Gates，又Linus Torvalds一样的梦想。当然也可能没有那么远大，但是也会有当上CTO这样的想法。
一直在考虑这样的问题很久，直到有一天有了一些新的想法——这也是可以练习的。我们都知道创业就是集齐一些条件，然后持之以恒地做下去。而要集齐条件是一件很难的事，但是要练习确是一件很容易的事。
如果你可以每天抽出时间做一件事，那么再好不过了。如果一直在加班，那么这件事对你来说一定是很困难的一件事。抽出这些时间，然后做一些有针对性地学习和练习，那么就会离这个目标又进一步。
所以，这其实是一篇在说怎么去练习创建一个成功的产品的文章。这些原则可以很容易运用到创建一些开源项目上，又或者是其他类似的事情。如果你看过之前那篇《程序员如何艺术的提升技术、影响力&赚钱》，那么我想这篇文章对于你去创建一个Side Project也是很有意思的。
过去我也一想在想这个问题，为什么我也没有一个好的Idea。后来，我发现只是我没有去记录，再后来我发现光有一个好的Idea也没啥用。
「只差程序员」是一个很值得思考的问题，但是也是一个很有意思的问题。作为一个程序员，我们很容易发现对方的Idea，实现上真的不怎么样。而且如果他们差的不只是一个程序员，他们需要的是一系列的程序员。还有更多的人员，他们只是觉得程序员是万能的。
这就回到了一个问题上，既然我们是一个程序员，那么我们就占据着这个世界上的人和了。如果天时是一个好的时机的话，那么就是值得去等待了。但是作为地利的Idea，却是可以练习出来的。
这可能是你听过最有意思的笑话了~。
在我看对刻意地练习进行了一番尝试之后，我发现这其有无限的可能性。
开始瞎说之前，让我们先看看英特尔?高级院士Gene Meieran对创新的三种类型定义：
现在，我们已经有三个可以练习的领域了。
等等，我们从哪个领域开始？
这是一个再简单不过地问题，自然是从我们擅长的领域开始——计算机。又好像是一个说了等于没说的答案，而这也是最容易练习的领域了。
在我们日常的编程工作中，我们会遇到各式各样的问题。有的人因此而创建了许多工具，有的人创建一些公司等等。只是因为这些是我们的痛点，而如果一个痛点是很多人的痛苦，那说明这是有希望的一个想法。因此，上面的三点也是三个可以练习的点。对于突破性创新来说，可能会比较难以在早期进行练习。但是对于渐进式创新来说，却是一件很容易的事。
创新是一个很有意思的话题，人们都在不断地鼓励创新。到底什么才算得上是创新？
作为一个企业想要有创新的目的莫过于：想活得更久。在多数的情况下，限制企业创新的主因便是企业本身的组织结构问题。如果一个在市场方面占有领先地方的公司做了很多创新，必然会更受尊重。Google在这方面做得不错，然而也饱受批评——毕竟，公司都是以营利为目的。如果一个产品本身达不到预期的营利要求，那么它必然会被关闭。
在很早很早以前，我们都用过jQuery。然而这个库太大了，在早期他根本就不适合用于移动领域。相信当时也有相当多的人对其叫苦连天，于是有一个人写了一个框架叫Zepto——一个兼容jQuery API的迷你版jQuery。
去除掉那些我们不需要的功能，我们就可以获得一个新的产品。毕竟，每个人的口味都是不同的。功能越多的东西并不意味着越好，好的设计应该是添加不了新的特性，也删除不了特性。
兼容旧的浏览器本身就不是一件令人愉快的事，如果我们可以像React一样抛弃旧有的浏览器，那么我们在开始的时候就能走得更快。
对于这一个点就更有意思了。就是找以前的人做过的Idea，重新做一遍。在旧有的技术下不能完成的Idea，在新的技术和环境下就有可能完成了。如出生得太早的Palm掌上电脑，如果在一个新的时机重新创造的话，那么我们就可以超越原来的产品
实现上，你也发现了上面我们说了一堆费话。因为没有行动的话，说太多也是没用的。
记得我们的上上次Hack Day的主题是慈善，我们想做一个O2O捐赠（ps: 当然这个项目是开源的，代码放在GitHub上：https://github.com/icharity）。对于我来说，这是一次彻底的自由技术选型。
我们平时的主要语言是Java、Ruby、JavaScript，我们还使用了个古董级别的搜索引擎。尽管应用现有的系统架构可以完成我们的功能——搜索引擎保存、搜索数据，用Java语言来实现业务代码。但是在这样一个“伟大的节日”，我们还是自由地去创新。
于是，我使用了Django作为主要框架，ElasticSearch作为数据持久化，使用Node-Wechat来处理用户输入。接着在这三天里，就Happy的去写代码了。Blabla，然后就可以欢快地和人们去ShowCase了。
而这便是一个很好的再运用式创新，而这也是一个很通俗的例子。现在我已经想到了一个更简单的例子了：以前当我们不懂得设计模式的时候，我们写的代码可能看上去可以重构，但是又找不到一个好的点。而有了设计模式之后，我们便可以在我们学到的新思维用到旧有的代码里。
对于上面的例子来说也是相似的，我们已经有了旧有的技术模式，只是现在我们有了新的业务。新的业务可以匹配到我们旧有的技术框架里，旧的技术框架可以得到复用。
渐进式创新是一件很有意思的事，他已经和我们上面提到的“减法”相矛盾了。但是这一点似乎就是很多软件的盈利点所在——通过添加新的功能来赚钱。这也是一个非常容易理解的点，你只需要添加一些新的特性即可。不过，我想这一点已经到处都用到了，没啥说的~~。
在一次Hackday里，我们（我当时是实时生，只是在打酱油~~）用WebRTC、Arduino、Android手机、四轮小车作了一个小机器人。我们搭建了一个WebRTC的Server，手机与四轴小车做了一个漫游者，然后你可以在网页上看到小车看到的东西，并且你还可以在通过WebSocket在网页上操作他。
而我们的新Idea，便是用Oculus替换掉浏览器——我们可以用Oculus来观看远程的画面，当然还应该可以移动。尽管改变看上去很少，但是还是充满了技术挑战。
而这也是多数产品的一种路线，而这是这种路线让一个又一个的程序员加班。因为Idea本身不一定可靠，没有人能保证他们的想法一定可行。但是如果程序员不是那个出Idea的人，那么就只能任人宰割了。渐进式创新是很保守的技术创新，在现有的产品的基础上加以改进——算是加法创新。
记得在那篇《如何去管理你的Idea》中，我们提到了用GitHub来管理Idea的想法。但是在上面记录的都是一些公开式的Idea，我们可以记录一些相似的问题。除此，我们还有一些更好的工具。
但是，养成记录问题和Idea的习惯很重要。 但是，养成记录问题和Idea的习惯很重要。 但是，养成记录问题和Idea的习惯很重要。
如我开始将各式各样的Idea，向我的GitHub Repo里放，如下图所示：
GitHub Issues
里面已经堆了一堆想法，有的是重复的造轮子，有的是造一些新的轮子。隔三差五地创建一个新的Issue，虽然不一定及时完成，但是可以放着看看。等老了，看看有哪些Idea已经被实现了。
除此，有一些比较隐私地Idea，会用【奇妙清单】来管理：
奇妙清单
想法先记下来，然后再说~~。
造轮子是一种快速的学习方式，而还有一种进阶则可以是从Github中生成轮子。
使用GitHub来生成轮子，简单来说就是：
查看很多Github项目的源码及提交历史
写胶水代码生成自己的框架
在这里分享之前造的几个轮子的过程：
两年多以前，当时我们项目用的技术栈是：Backbone + Mustache + jQuery。在我们当时的环境下，主要组成有：
所以，这就是我造的第一个轮子的重要组成部分。
接着，我就开始造轮子了：我称呼这个框架为Lettuce, GitHub - phodal/lettuce: Mobile Framework for Romantic. 简约的移动开发框架。
我参考了一本名为《Building A JavaScript Framework 》的电子书，以及《JavaScript框架设计》一书。因为没有任何框架的设计经验，所以只好试图按照书上的一点一滴来进行。在这个过程中，我开始深入JavaScript。
从 [https://github.com/munro/self) 这个库中，我开始创建了自己的类的用法。
接着，开始写Ajax，照例还是参考了jQuery和Zepto的代码。同样的还有Event、Promise等等的一些类。
然后就是Router，源码来自于：https://krasimirtsonev.com/blog/article/A-modern-JavaScript-router-in-100-lines-history-api-pushState-hash-url，又参考了早期的Backbone代码。
以及模板引擎，照例代码也不全是我写的，用的是http:////ejohn.org/blog/javascript-micro-templating/
最后就是一个简单的PageView:
var SimpleView = new Lettuce.prototype.Class({});
SimpleView.prototype.init = function () {};
SimpleView.prototype.render = function (template, elementId) {
document.getElementById(elementId).innerHTML = template;
};
var simpleView = {
SimpleView: SimpleView
};
Lettuce.prototype = Lettuce.extend(Lettuce.prototype, simpleView);这其中最复杂的部分就是结合别人的代码，换句话来说，就是写胶水代码。Blabla，最后我就有了一个SPA框架。
不过，这其中参考了几十个框架，这点对提升自己很重要。
八个多月前，当时的情形是我需要有一个可以定时放映地Slide框架，而当时大部分的框架都不能满足我的要求。
实际上我只需要一个定时的功能，而Impress的最新代码又太复杂了。
接着，我看了Github上的提交历史，我发现挺简单的，就自己创一个新的框架，称为GitHub - phodal/echoesworks: Next-Generation Tech Blog/Presentation/Slider Framework。
我需要下面的一些元素：
同样的，我在Github上搜索不同的组件，最后再把他们结合到一起。
相关文章：
接着，我又造了不同的几个框架：
随着造的轮子越来越多，写胶水代码的能力越来越强，我就开始创造一些更有意思的轮子。
Luffa是最近造的一个轮子，对于不写测试的人来说可能没有那么有意思。
我称其为基于Virtual DOM与Diff DOM的测试代码生成，GitHub - phodal/luffa: A Test Framework Helper for Fun
当时我们项目用的是Jasmine和Jasmine jQuery作为测试框架。在写测试的时候，觉得看起来太麻烦了，就想着写一个框架来Diff DOM的变化。
然后就是Virtual DOM那些东西了。
virtual-dom可以说由下面几部分组成的：
所以，我们可以很容易地创建出一个这样的框架来Diff测试中DOM元素的修改。
EchoWorks
创业练习
常听人说，在我司待上三年，你就该“毕业”了。
说工作多少年总是有种秀资历的感觉，一点儿也不好，下次让我们换个口味：你的年假有多少天。
简单的来一下流水线：
2016 的最后一批狗粮如预期一样，已经发放完了，请期待 2017 年的狗粮。
是时候进入正题了。
实习的时候的主要压力源是：同侪压力（或称同辈压力、朋辈压力，指的是同侪施加的的一种影响力，它可以鼓励一个人为了遵守团体社会规范而改变其态度、价值观、行为。）。同时进公司的同事大部分都是重点学校的研究生。这种事情落在一个二流学校的本科生身上，就是一种压力——和他们相比，你不知道究竟差了多少。即使是相差无已的，你也会觉得他们比你强。概况我又不是计算机专业的，而在大学之前我一直在为成为 Kernel Hacker 而努力着。
这种压力倒算是正向的，在为更强大的自己为努力着。然后，你就 Move Fast，也不得不 Move Fast。生怕有一天，你就落后于其他人。后来你就知道了，我开始刷 GitHub 来提高经验值、开始刷书提高理论值。那时还有一个时间段，我以每天一篇的文章在刷博客。
等毕业的时候，因为更具有挑战性，便想去尝试国内交付。通过 PM、Buddy、Sponsor 等去与上级讨论，遗憾的是都没有这样的机会。毕竟这些机会都是有限的，哪天已经长成的时候，它就会来找你，而你已经不想要了。
这段时间倒也成了成长最快的时候，没有工作上的压力，还有人指导你成长，还能在项目实战上成长。
开始正式工作之后，就进入了半年的试用期。虽然并不会因为有半年的适用期而影响，但是项目还是一个项目，多少就会变得有点无聊。
这时候的挑战变成了：Interview ++ 和 Coaching 新人。
度过试用期的标准是：愿意不愿意和 Ta 一起工作。但是当你在试用期的时候，就会遇到每个月的一次 Interview++。项目上的其他成员（已经过试用期）会对你进行一次组内考核，这种反馈是多方面的——不限于技术。如我在最初的时候，遇到的主要问题就是说话语速过快、普通话发音和英语问题。
后来，语速大家习惯了，胡建话大家也习惯了，英语提高了一点，大家也习惯了。再后来，我就去翻译书，还能愉快地用英语培训客户。
当你好不容易解决了一个反馈的时候，在下一次 Interview++ 的时候，你就会收到一个新的反馈，然后好好改正吧！少年。你就会一直在变得更好的路上，同时更加累。
入职的三星期后，七个人的团队里有四个新人（包括我）。由于我们采用结对编程的方式工作，这就不得不和其他新人结对，去 Coaching 新人。这种体验一点儿也不好，每天你都要提前做好准备，还有会遇到你的 Pair 问的各种问题。
在你也不是很熟悉快捷键的时候，还需要去教会你的 Pair 使用快捷键，你就不得不加倍去练习这些技能。当然这种成长也会更快、更累，顺便带你的小伙伴一起飞。
当然，事情并没有这样一帆风顺。有一次，写了一个大 Bug 进去，然后上线又下线了。因为采用的是一个迭代上线一次，所以事情不算太糟糕，就是回滚到上一个迭代的版本。
这个 Bug 起先是为了 SEO（搜索引擎优化），他成功的跳过了：需要运行一小时的功能测试、数量众多的功能测试、QA 们的测试，最后是由 Google Analytics 发现了这个 Bug。同时他也困扰了我一段时间，那是我在当时找到的方法，然后也没看出大问题，就愉快地修改了。对于这个十年左右的代码库，我终究还是太年轻了。
现在，这些代码仍然在线上运行着。不过，据说已经没人会去修改这些代码了。
团队里的大部分人都是从 TWU 里出来的，同时采用了标准的结对编程流程，因此我们一直自豪的宣称：中国区对文化和敏捷遵循最好的团队。可惜，现在已经不存在了。
我们遵循着制定下的一个个软件实践：保持提交信息一致，保持持续集成的最高可用性等等。当你的持续集成是红的时候，就会有人愉快地去帮你查看失败的原因，诸如 Check Style 失败的、红过夜的是要买酸奶的。不及时修复的、修复难度比较大的，会立马被 Revert。
当你犯错的时候，记得：Be Profressional！
后来，在工作上的挑战也就越来越少了。
有的人可以在三年里经历一系列的项目，刷下一堆经验值。有的人可以在三年里经历一个项目，留下一段篇章。
记得，在公司法中说：公司是指一般依法设立的，有独立的法人财产，以营利为目的的企业法人。当你工作的时候，一切都需要以营利为目的。如果公司营利多了，那么什么都好说。反之，你懂的。因此无论在哪，领导层都以公司的营利为核心。随后，才是公司文化，才是你的个人利益。再好的文化也会有变的一天，只有“利益是永恒”的。
因此，只要你把工作当成工作，公司当成公司，就会发现一切都很轻松。毕竟，技术好本身是没有价值的，有价值的是技术做好的事。
三年里只经历了两个项目，即算是一种不幸，也是一种幸运。不幸的是，从工作上能学习到的东西少之又少。幸运的是，可以有大量的时间去刷 GitHub、写博客、翻译书。
在这个时候，你总得去寻找你的下一个挑战点在哪。
我在寻找下一个挑战点，你呢？？
作为一枚程序员，我们天生就是来解决问题的。在你不知道你的问题之前，我帮不了你，Google 也不能帮你解决问题。
大概从去年开始吧，我在思考着提升软技能上的能力。对于问题来说，能力可以分为这么几种：
那么问题来了，当别人问你一个问题的时候，你会怎么去分析它呢？首先要对这个问题进行分类，因为很多问题是无解的。比如说，初学者问你：
很多时候，你只想要别人的肯定而已。
作为成长的一个方向，我开始去寻找一些咨询类的书籍，才了解咨询师可以分为好多种。比如说： 技术、解决方案咨询。我们需要有人来解决某个特定的问题，这个的问题是：已知的问题，但是找不到合适的解决方案。
常见的比如说，你需要一个团队转型方案，你需要有经验的人来帮你，以期降低相应的风险指数。
又比如说，我们知道我们遇到了问题，但是我们不清楚问题出自哪里。
还有一些就是，我们不知道我们不知道，我们想预测一下『黑天鹅』。
简单的来说，就是『约哈里之窗』。
最后，还有一种情况是：出于政治目的，我们需要你来证明 B 方案是比 A 方案更好的。事实上，这种问题在我们的生活中更常见。我在心里已经有了答案了，我咨询你只是为了得到一个肯定，然后就可以实施这个方案。即使，你不肯定这个方案，我也会实施的——这就是『灰犀牛』，我们早就看到却又视而不见的危险。
（PS：不可预测的黑天鹅，可预测、可感知、可预防的灰犀牛，他们都是两种奇葩。）
也因此，很多时候，被提问的你就是那个背锅的大头。
一旦一个问题被充分地描述了他的细节，那么解决方法也是显而易见的。
很多时候，我和别人描述了一遍问题的时候，我就已经达到了问题的答案。在这个时候，我希望你能这样去做，即橡皮鸭子解决问题法。所以，你只需要去问这只鸭子，你应该怎么办就好了。
duck_assisting_with_debugging.jpg
当程序员遇到一个问题时：
这些方案已经足够的清晰了。你也在很多地方看到了如何去解决问题了，我只是又重复了一遍了。当我们去询问别人如何来解决一个问题时，需要有这么一些步骤：
作为一个程序员，首先你需要尝试自己去解决这个问题。我经常在 QQ、微信群里看到一些问题，明明就是自己搜索一下就能解决的问题，却还要去问别人。比如说：
Value Error: unknown locale: UTF-8
你只需要简单的搜索一下：
Search Value Error: unknown locale: UTF-8
现在，你遇到一个请求的参数没有发到后台？你会怎么做？ 使用浏览器的 Network 工具，查看请求是否发出去了:
再进一步去看这个问题，那么你可能就解决了这个问题了。
当你已经尝试了多次，并失败了，那么你就可以寻找合适的人，合适的地方去提问，比如说：
向我们决定提问的时候，我们需要描述清楚我们的问题：即，我们需要在别人的脑子里能复现问题。我们需要描述一下当前遇到的问题：
如果是代码的话，请使用高亮、高亮、高亮的编辑器，或者截图。
总之，就是让被提问者有一个清晰的问题印象。
列出你所需要的解决方法，一一验证它。
绝大多数情况下，只有你才能解决你的问题。我只能教你方法，或者 Coach 你，才能帮你解决这个问题。
虽然在我的书架上有很多的技术书籍，但是这并不代表我对每本书都很了解——但是至少每本书我都过了一下目录，大部分的书都翻了一遍。在开始瞎扯之前，先让我们过一下目录：
买技术书籍的情形应该是下面的几种情况： - 工作上使用到一些“新的技术”。对于自己来说是新技术，不代表在行业上是新技术。 - 业余生活中想尝试某个新的技术。 - xxx推荐的某本书。虽然和应用无关，但是到底是xxx推荐的。这个xxx可以是某些大牛，这可以是亚马逊——我看到亚马逊的书有好多的star，我就会买。因为在亚马逊能给书评的都是真爱。 - 探索一个新的领域。在上大学的时候，这是我最喜欢干的事，动动就去看一个无关的领域。
上面的第一、二点都是因为我们需要，所以我们才去看——这也是我们日常买书的常见原因。
从出版行业来说，我最喜欢的就是动物园（O’Reilly出版社）的书，然后就是其他书籍了。但是O’Reilly出版社出的书都比较慢、慢，除此，与进到国内还需要经过翻译等等。说到翻译，不得不说图灵教育出版的翻译书籍挺不错的。
而这个行业里，最敏捷的就数Manning出版社的Manning Early Access Program，这是一个非常敏捷的出版流程。
In MEAP, you read a book chapter-by-chapter while it’s being written and get the final eBook as soon as it’s finished. If you pre-order the pBook, you’ll get it long before it’s available in stores.
简单地说，就是当作者完成一章的内容时，你就可以阅读这一章的内容。作者在不断写作的过程中，你就可以不停地收到相关的书籍。当作者写完这本书的时候，你就读完这本书了。
可惜如果你要等中文版的书籍，差不多要等一年。并且英文版的书籍，动不动就是几百的。
因此从流程上来说，国内的出版的书籍从流程上来说会更快一些。而国内的出版现状是，写书都是为了赚名气。对比于工作时间来说，写书基本上是亏钱的买卖。更不用说，我写的六书开源电子书，就是更亏钱的买卖了。因此，很多技术大牛都不愿意写书。他们本身就是大牛了，不差名气、也不差钱。
因此，如果我们需要某一个领域的技术书籍。从理论上来说，最看到的是 国内的 -> Manning > Packt > O’Reilly。
因此：
对了，如果你看的是盗版书籍，即电子版等等，你没有资格说这本书写得烂、翻译得烂。
开始之前，我们需要简单地知道几点内容： - 普通的书籍都是连续的、不可跳跃的，但是技术书籍都是可跳跃的。 - 技术书籍的内容都写在目录上，一眼看上去就知道发生什么了，如：第一回 宴桃园豪杰三结义，斩黄巾英雄首立功、第二回 张翼德怒鞭督邮，何国舅谋诛宦竖。 - 在以介绍某个框架、语言的书籍中，作者会不断地强调这个框架、语言的特点。
现在，我们是不是应该：
沐，濯发也。 浴，洒身也。 洗，洒足也。 澡，洒手也。
翻译过来就是：
古人读书，庄重之极，读书之前要沐浴焚香，清新敛欲，泡上一杯清茶，在茶香袅袅中，把情绪酝酿的极其饱满，然后端坐书室。
完了，我们就可以开始看书了。一般来说，书的主要内容要么写在前言里，要么写在第一章里，但是它一定是在目录里的，所以可以按照这个顺序： - 先阅读前言和第一章 - 然后看目录，找感兴趣的章节 - 最后放书籍上，装逼。 - 时不时地可以拿下来——放瓜子壳。
其实这个过程中，有一点很重要——对书的内容进行索引。换句来说，就是我们应该大概记得这本书在讲什么时候，相当于是，我们记住了这个框架、语言的一些基本属性。而正是这些构建了这些属性，我们就可以记住那些关键点，然后Google it。
如在那篇 索引 中所说：
人的大脑如同一间空空的小阁楼，对放置进去的家具要有选择。
“当然是要放在书籍上装逼了。”
最好的效果莫过于： - 讨论 - 实践 - 教授给他人——如写作
一般来说，我们都会推荐给别人去看官方文档，毕竟官方文档比较新什么的。然而有一点值得商榷的是，时间成本。阅读一本英语的原著书籍，至少能让可以读英语书籍的人读3~5本翻译书籍。
当你工作之后，你会发现这一点更不值：大部分情况下，我们需要花费几天的时间自己去探索一项新的技术，但是如果是一本书籍的话，可能就是一两个小时的事。
最近收到了很多要来面试的简历，发现你们的简历怎么都是这样的呢？要是我是面试官，你们肯定进入不了下一轮。
马上就要到一年一度，最适合找工作的时间段：金三银四。另外一个时间段是：金九银十。金三银四的大意是：最好的时间是三月，其次是四月。同理于金九银十，最好的时间是九月，其次是十月。反正我也是在几年前，道听途说过来的。一过完年，一交流总会多些想法，就有了金三银四。金九银十则是，一些公司在年中的时候，发去年的年终奖。
今年的行情虽然没有去年火热，但是你仍应该拾掇拾掇一下你的简历，万一机会来了呢？
作为一个技术人员，如果你满足以下条件中的任意一个，你应该去看看更多的机会：
以及
这不是马上就要到，传说中一年一度的狗粮节了么。回到正题，一份优秀的前端开发工程师简历是怎么样的？。
这个嘛，我觉得应该是这样的：
Phodal
然后呢，HR 只需要打开这个 PDF 中的 GitHub 链接即可：
Phodal’s GitHub
这才叫优秀嘛，你说是不是？
好了，写完段子了，让我们来看正文。
这些年来，我也多多少少了，看了一些简历。也稍微有一些经验，让我先罗列一下问题，再说说原因：
简历造假。任何造假的行为都是不能容忍的，这个问题容易出现在不自信的面试者身上。还容易出现在培训机构的学生上——我并没有任何歧视培训机构培训的学生，我只歧视培训机构及其行为。即使你能幸运的通过面试，在工作的时候，你也有可能被觉察出来。
不适当的文件名。当我收到一份简历，你可以是 xxx.pdf，可以是 xx公司_xx.pdf，但是不能是 all.pdf、resume.pdf 这样的文件名。我还需要帮你重新命名一下，然后存档么？在简历的文件名上，你要突出重点，谁，需要什么岗位，如：李小明_Android工程师_简历.pdf
使用 PDF 以外的格式，如PPT、DOCX、HTML。PDF 是我目前看到兼容性最好的格式，要知道 Windows 上写的 TXT 在 Mac OS 上打开都会有编码问题。DOCX 就更不用说了，我司标配的 Office 是 LibreOffice，打开的文件 100% 出问题。PPT 我就不说了，虽然很帅，但是我很累——要面试的人是你，不是我。
PPT Resume
呵呵~
语法问题。在平时的时候，你可以将一些技术栈的单词拼错。但是在简历上，请认真一点~，最好可以找基友帮你过一遍。该大写的时候就应该大写，如 HTML 不应该写成 html 或者 Html，Java 8 不应该写在 JAVA 8 或者 java 8， 乃至 J8。
排版问题。像审美风格这样就算是其次的，该换行的时候就要换行，该对齐的时候就应该对齐。好在大家都是用模板来完成的，这个问题不大。
没有项目经验或者无用的项目经验。只是罗列技术栈，没有写你做了什么。这种感觉就好像，我在 BAT 里都干过，只不过是我是在里面扫地的。作为一个美团外卖员工，天天进百度外卖大楼去送外卖——除了没被打死，你还有什么可以自豪的？。 写了一些无关紧要的废话。谁 TM 想知道你和你家大伯的女儿关系，以及你在中小学的时候去哪玩了。除此，你在大学的时候做的家教、兼职也不重要。你要来面试的是一份技术工作、技术工作、技术工作，不是销售，也不是大家老师。如果你是党员，你也不用突出你是有多爱党。毕竟，作为一个普通人，我们都拥互党的领导的。
罗列技术栈。不要在简历上，写上太多的无关技术栈。写到简历上的东西，都会成为你的呈堂证供。如我毕业的时候，准备了三种不同类型的简历，嵌入式工程师的、Web 工程师的、包含两者的。然后在专业技能上，我列举了我玩过的各个东西。在现在看来，简直是。。。
罗列技术栈
简直是作死。当年，我写在简历上的每一个内容，都被一一过问了一遍。
简历就是简单的介绍一下你自己有多 NB。所以，你需要介绍以下的内容：
然后把这些内容放到一个模子里，就可以了。
如果你并非设计师，或者想要相关的求职岗位，那么请不要在简历的样式上花时间。你应该将更多的时间花费在简历的内容上吧。作为一个技术岗位，面试官想看的是你能干什么，而不是漂亮不漂亮。你又不是要面试 鼓励师程序员 = 鼓励师 + 程序员。
然后推荐下我用的模板，LaTex 里的 modercv 模板。就是这样的效果：
LaTex简历模板
这个模板最大的优点是，写废话的地方很少。最大的缺点是：你需要学习 LaTex。你可以轻松地写上你的各种经历，并且排版出来的效果很不错。
这里有一个突出自己的，最好例子：
本人学识渊博、经验丰富，代码风骚、效率恐怖，c/c++、java、php无不精通，熟练掌握各种框架，深山苦练20余年，一天只睡4小时，千里之外定位问题，瞬息之间修复上线。身体强壮、健步如飞，可连续编程100小时不休息，讨论技术方案5小时不喝水，上至带项目、出方案，下至盗账号、威胁pm，啥都能干。泡面矿泉水已备好，学校不支持编程已辍学，家人不支持编程已断绝关系，老婆不支持编程已离婚，小孩不支持编程已送孤儿院，备用电源万兆光纤永不断电断网，门口已埋雷无人打扰
因此，你要保证 HR 可以轻松地打开你的简历，并且可以看到他们想要看的内容。如果你使用 GitHub Pages 和网页的时候，就要注意这个问题。并不是所有的 HR 都会FQ的，并不是所有公司访问外网都会很轻松的。
你刚毕业不久的时候，你应该突出你在学校的成果：
在校情况
工作的时候，便是突出你的公司，和 NB 的项目。
校招的时候，你可以把你在学校玩过的各种东西都写在上面，如下：
学校简历
就是要把你玩过的、觉得很 High 的东西都往上写。毕竟大部分人都是玩游戏过来的，然后你还玩过这么多东西，面试官对你的印象一定特定好。不过，还是那一点，不要造假——写到简历上的东西，都会成为你的呈堂证供。作为一个 Play for Fun 的程序员，谁的大家不是这么玩过来的。
除了这种玩可以为你加分之后，还有：
而，等你工作多年后，教育经历就变成无关经历了。这时候加分的内容就变成：
这个世界就会从看学校到看公司。所以，如果你毕业的时候遇到这样一个选择：大公司还是创业公司。请考虑上这一点因素，如果这家创业公司倒了，那么你的下家就不好找了。反之，你从大公司要进入小公司，则是轻轻松松地一件事。
（PS：我的干货就到这里结束了，以下是广告时间。）
当然了，简历再漂亮，能力不行的话，你也是进不了进一轮的。
提问：这是一个好问题
重复一遍问题
tree sl cURL
紧跟热门的技术是有风险的。往往你写完的时候，这本书可能已经更新了一个新版本。
那么旧的话题呢？换个思路即可，内容还可以是那些内容。
一个很好的例子，就是小说。大部分的电视剧、小说剧情上，都是你能猜到的。但是这个节目，总会有一些亮点可以吸引你，比如说主角的包子脸，俊俏的脸型，又或者是 34D 的好身材。
换个思路，重新去思考这个问题。
例子一：设计模式
GoF 的 23 个设计模式，有几个明显的问题：
所以，你可以用 Java、JavaScript 去写一遍，于是你可以看到市面上已经有很多这样的书了。
写得太复杂。如 Head First 设计模式、 设计模式与重构——重构除了有 Java 版，还有 Ruby 版。
又比如说，写 Python 上 Web 开发框架的书，可以是普通的网格，后者则可以结合潮流 如 《Python Web 开发 ：测试驱动开发 的方法》
将某个语言上的应用到其他的领域，如有一本《微服务设计》的书，这本书没有提到具体的语言。面向不同的开发者，就可以有相应的实践书籍，如 Python 微服务，Node.js 微服务，Java 微服务。他们讲的内容是差不多的，无非就是自动化测试、自动化运维、持续部署、拆分服务等等。
平时有技术的去写些文章，出版的时候就结合一下这些关键点。
可以变成电子书，再是出版后的书籍。
大 V 自然是有优势，出版社也更愿意出这一类的书——销量有保证。
如果你写的是一本冷门技术的书，又或者是国内用得比较少的书，那么出版的可能性就比较了。有一些小的出版社，出于销量的需求，就不会考虑了。
标签：anti 质量 模式 man 通话 学习方式 building 开始 rest api
原文地址：http://www.cnblogs.com/btdxqz/p/6760734.html
