小站会根据您的关注，为您发现更多，
看到喜欢的小站就马上关注吧！
下一站，你会遇见谁的梦想？
It's&my&Life.
暴力英语学习法 + 严格的目标管理 = 成功快速靠谱的学好英语
updated: 非常开心看到这么多的同行有这么高的学英语的热情，晚上回家会把资料传到百度网盘，祝你们都能学好英语！
　　园子里时不时就吹起一阵学英语的浪潮，不少同鞋表示一直想学，或者一直在学，就是效果不明显（你躺枪了么？）相信自己或者身边的人都或多或少吃了英语弱的当（你懂的，我们重点在说薪水的问题:)。而各种英语成功学，方法论，版本是一个接一个层出不穷。今天我们不说为什么要学好英语，好处太多而且已经广为流传了，我们主要结合目标管理来讨论一下如何坚定不移的，快速的学好英语。以我自己的亲身经历作样板，以下情况全部属实，绝无虚构。
　　先说说我在开始学英语之前的情况：
时间：2012年2月，已工作4.5年
词汇量：小于1500，（初中英语成绩特别好，高中以后全部打混，再加上工作时间完全不接触英语，所以最后基本上就剩下1500不到的词汇量）
其它英语能力：总之就是不能听，不能读，不能写，当然，更不能说，连最基本的8种时态都记不怎么清了。
　　再说说现在的情况：
截止时间：2013年6月，持续学习时间15个月（现在并没有停止英语的学习，只是没有以前强度那么大了）
词汇量：8000+
其它英语能力
读：能够无障碍浏览英文网站（包括技术论坛，新闻科技网站），不用借助词典阅读原版技术书籍（CLR via c#一类的）
写：平时工作上邮件，开发文档，技术文档，需求文档都是用英文写
说：每周主持2次以上和美国同事开会，有问题随时呼叫他们
听：80%理解VOA常速，NPR，CNN新闻，Channel9 Videos，以及印度口音（印度人的发音不好，可是不能阻止别人英语很好!)
其它：今年6月份因公出差，到西雅图工作一个月
　　之所以列出上面的对比，是希望可以让你知道，我这样的基础都能学好英语，你又何尝不可呢？不是要谈目标管理吗？我不是标题党，接下来我们就结合这个例子来看看怎样做是好的目标管理，我会把我学习英语的方法总结出来，这是一个模子，可以套到任何地方。不管你是打算学英语，还是写博客，还是换工作，或者找对象:)。
　　本文包括一套完全的英语学习方法（听，说，读，写）以及本人学习过程中的经验，心态的分享。
　　上列表列的非常清楚非常适合阅读训练，很容易找到自己级别对应的图书，但是美中不足的是有一些书可以在网上找到，有一些真的完全找不到。不过找到自己级别的整本读完也是一个不错的挑战，对于英语学习者来说能把整本英文原著读完的人，真的不多。
　　另外我电脑中有1000本英文名著的电子版，如果大家想要也可以分享给大家。
　　要说我看了多少本，真的记不清了，大概花了两个月左右的时间，每天3个小时，强迫自己去阅读。从最开始的短篇小说，到后来的长篇小说，像《简爱》《傲慢与偏见》之类的。到最后就直接看新闻，网易学堂的双语阅读是个不错的选择，都是一些时事新闻，看着也不会枯燥。最重要的是在阅读完之后它会给出你的每分钟阅读词汇量，是个不错的可以量化的检测方法。
　　到最后，也就是我们的终极目标，直接看原版的技术书藉。
　　当然硬着头皮半个小时啃一页，那不是我们的终极目标，我们的目标是1分钟左右一页。只有这样才有可能真正像看中文一样的去看英文资料。阅读能力的提升没有捷径，只能靠不断的阅读来提升。但是大量的阅读带来的好处远远不止阅读速度的提升，也是为我们的写作和口语打下基础，只有脑子里有货了我们才能得心应手，脱手/口而出。所以在2个月的专项阅读训练之后，就轮到对于写作的突击了。
　　比较适合初学者，因为发音非常清晰而且慢，是讲故事的那种方式，并且会一个句子一个句子的讲解，所以不用担心听不懂。所以如果你觉得听英语很无趣的话，试试这个。（我有这几本书的电子版和MP3文件，已打包！）
　　听力部分3 沪江听力酷 听故事
　　沪江听力酷是一个手机APP，可以将这些音频下载的手机上离线收听。
　　可以设置A-B两点复读，而且基本上都提供中文翻译。　　分集收听，每集都是在1分钟左右。　　最重要的是，所有材料都是分级别的，所以非常容易找到自己对应的级别。还是那句话，不看字幕听不懂的就不要去碰了，咋没必要去找那个打击，找至少能听懂70%的材料去听，这样才会有信心持续的听下去，也只有这样才能提高听力的水平。
　　中级的标准美音就是VOA常速的标准，TED演讲是我个人最喜欢听的一个项目，你还可以从网易公开课上找到它，TED也是自己的Android App下载视频也是非常的便利，不仅可以学英语，还可以见识到各个领域（科技，艺术，民主，文化等）的意见领袖。很多TED的演讲都具体着非常深远的意义，说它能改变你的一生也不夸张。
　　听到中高级阶段，基本上和外国人沟通听力部份就不存在太大的问题了（不包含印度这种外国人哦）。如果你能把上面列出来的材料全部认真听完，我敢保证，你的听力绝对不会差。&
　　口语部分1
　　口语锻炼的部分就不用找材料了，因为我们上面已经列出来了。没错，上面所有的材料不光是全部都要认真的听（脱稿），而且还要认真，大声的读。读的时候一定要读出声音来，你自己可以听到自己的声音，只有读出声来才能知道自己到底说的好不好，发音标不标准，同时也能够模拟真实的对话场景。刚开始的时候没什么，就是读，读的多了你自然就会说了。
　　口语部分2
　　我们要来真的了，不能总是自己一个人躲在家里读了。那些有对象英语特别好的人，你们真是太幸运了，可以免费找一个陪练。当然，如果你实在找不到人陪练也没有问题，那就花点钱吧，给大家推荐我用过的51Talk，好不好的话我不敢明确的说，因为说实话学英语这件事主要还是靠个人努力的，你付出了多少，回报就有多少。所以那些说学了好久英语但是没有太大效果的人，问问自己真正花了多少时间来学英语。
　　　我在去年11月份的时候，花了4千多，购买了220次次卡，每次课是25分钟左右，如果上面的材料都认真读过的话可以直接和老师进行Free Talk。这种模拟对于口语的帮助还是非常有效的。刚开始几个月周一到周五每天都上1个小时的课，到后面就可以慢慢减少了。英语水平薄弱的时候比较容易丢，如果水平上来了，反而不容易丢，就算丢了也比较容易捡回来，所以前期一下要高强度，后面可以适当放松。
来帮我们记录。
选择课程：包括四六级，新概念全四册，以及托福雅思等等，总之库很全。
将你想学习的课程下载到本地。
之所以从学习课程开始，是因为对于我们已经知道的单词我们没有必要去背，直接忽略就可以了。
通过第3和第4个按钮，我们就可以把我们准备要背的单词加入一个生词本，只需要背这个生词本里面的意思就可以了。
复习的时候选&浏览&模式，默认的开始复杂是使用的什么曲线法，不适合我们这种快速背单词的模式。
我们可以在这里面，选择&忘记&将单词的复杂度+1，或者删除该单词，以后就不需要复习了。
是我最爱的模式，会重复的读该组下的所有单词，这样的话，在你走路的时候，地铁里的时候就可以用这种模式去复习了。
　　背单词的应用有很多，包括最近比较火的百词斩也不错，但是如果要想暴力背单词的话，还是用云词结合上面的方法比较好。另外的话是因为云词有比较清晰的语音库大概1G左右，可以下载到手机上，这样我们在路上听的时候就不用耗流量了。
&　　文中提到的所有材料已全部打包上传，如果想要的朋友可以留下邮箱，我晚上抽空统一发给你们。希望我学英语的过程也能够激起你对英语学习的兴趣和决心，也希望我的方法能够为大家指一些方法，这样我就满足了。如果觉得本文对学习英语有帮助的话，请帮忙推荐一下，让更多的人看到。　　
　　updated: 非常开心看到这么多的同行有这么高的学英语的热情，晚上回家会把资料传到百度网盘，祝你们都能学好英语！
作者：Jesse&出处：
[翻译]Bob大叔:反思极限编程
译者注: Bob大叔14年后再次谈论极限编程。极限编程经历了14年的风风雨雨后，Bob大叔将会给它怎么样的定义那？在我手中拿着的一本白皮薄书，在14年前彻底的改变了软件世界。这本书的标题是解析极限编程，副标题是拥抱变化。作者是Kent Beck,出版时间为1999年。这本书很薄，不到200页。排版很宽，间隔很远。写作风格即自由散漫又平易近人。章节不多，概念简单。但是其影响却像地震一样，甚至至今震动仍未平息下来。起始于第53页的章节10，列出了12项实践，引爆了行业内的大辩论。并催生了一场革命，改变了我们编写软件的所有方式。这些实践是:
计划游戏：当今被成为SCRUM。此观点认为软件应该按照任务列表中的优先级循序渐进的开发。
小版本：应当频繁和渐进式地部署软件。
隐喻：该概念最终在Eric Evans编写的《领域驱动设计》一书中明确化。系统结构应当建立在针对问题域的简单的智力模型之上。
简单设计：任何时候都要保证系统尽可能的简单，不用考虑对未来的担心。
测试：程序员和客户一起编写自动化测试来验证产品代码的行为与预期一致。当今我们称之为测试驱动开发（TDD）及验收测试驱动开发(ATDD)。
重构：软件内部结构能够并且应当被持续改进。
结对编程：如果团队成员各自单独工作，那么这称不上一个团队。真正的团队需要经常通过键盘进行合作。这样可以相互充分的分享知识, 正是团队成员的义务。
集体所有权：代码归属于整个团队，而不是某个个体。
每周工作40小时：经常加班的团队是失败的团队。
现场客户：在团队中加入一名真正的客户，用于对需求负责，开发团队能够始终轻易的接触到他。
编码标准：团队应当使用一致的编码风格保证代码整洁，易于沟通。
争议？很奇怪是不是？是不是并不是所有实践都有争议？但是14年前引起了疯狂争议。确实，整本书出版时，人们争议书中的描述不可能应用于实践，争议所有拥护者是如何的必躬屈膝，不听劝解，甚至是一行代码没写过的傻子&&呃，我不应当让这些过去的感受压倒我。因为，毕竟它们早已消失不再，而我们依然存在。看看这12项实践，你没有践行其中哪项？我温柔的读者中的大多数可能长期的践行大多数实践。如果说它们已经被普及肯定稍显夸张，但是更不夸张的说，它们现在已经成为主流。更重要的是，还未践行这些实践的团队至少在尝试它们。这些实践已经可以被完美的落地实施，而不再是一个被唾骂的异端。崛起过去的14年已经变得陌生。极限编程论战催生出来的敏捷运动，飞速成功，随后被项目经理接受，但是将程序员排斥在外。我们已经看到了确定性的、疯狂的成功，以及相应的（可预见的）无力的认证。我们看到了只采用了计划游戏（例如SCRUM)而忽略其他11个实践的策略失败了。这种策略被Martin Fowler称为无力的Scrum。我们已经经历了咨询师和作者分离的持续的推动，以及看板、精益及每一个新的项目管理方法的竞争。我们已经看到了软件工艺运动的发展，以及敏捷基因被慢慢的退化和稀释。在所有的炒作和翻腾中，这12项实践依然留存，只是其中一些名字有稍微改变。一周工作40小时变成了可持续增长率。测试变成了TDD。隐喻变成了DDD。小版本变成了持续集成和持续部署。但是尽管名称改变，但是这些实践依然和14年前描述的差不多。我们也看到极限编程这个名称几乎完全不用了。极少数人现在还使用这个词。一些人仍然使用XP这个缩写，但名称的大部分都已经消失。如果听到一个团队描述他们正在做的是极限编程，甚至正在践行所描述的这12项实践，我会觉得非常罕见。名称变了，但是实践未变。这些实践是持久的。 在翻腾，炒作，争议的咆哮和胡言乱语中，在人类争夺一个又一个位置的风雨中，在人类的贪婪，激情和骄傲的杂乱中，在所有的政治中，这些实践依然留存。稳定的价值观我相信这些实践这么持久是因为他们基于稳定的价值观这个坚实的基础。Kent Beck在他的书中第7章第29页描述了这样的价值观：
我可以尝试论证为什么这些价值观是正确的，但是我他们自身已经论证了这些。软件工匠能够拒绝这些价值观中的任何一个吗？软件工匠能够不努力争取在工作中保证这些价值观的展现吗？这些价值观正是软件工艺的价值观。我可以尝试辩论书中这12项实践拥抱和体现了这些价值观，但是这些实践的持久性足够证明,尽管围绕这些实践的名词和运动已经消散。成功极限编程已经成功了！它成功的超越了其支持者的最疯狂的梦想。它的成功是因为从诞生时的争议中幸存下来，在不可避免的倡导者的流失中幸存下来。它成功了是因为它活的比自己的名字更久！极限编程的成功正像结构化编程的成功。甚至没人再会考虑结构化编程，因为他们一直在使用结构化编程。我们正在尝试达到没人再会考虑极限编程的目标。这就是成功！一个想法从这场运动诞生一直存活到成为我们日常生活的一部分，这就是成功！回顾所以现在，2013年的最后几个星期，我花了些时间回顾1999年。那个时间Kent Beck写了一个突破性的书。这本书改变了一切。回顾并谨记:极限编程。简单的说，请承认它是:
优秀的软件实践的核心原文出处:&, 作者Uncle Bob Martin。
微软CEO鲍尔默谈Longhorn以及其他遗憾
投递人&&发布于
09:07&&有343人阅读&&&&&&&
　　 12 月 12 日消息，据外国媒体报道，史蒂夫&鲍尔默接受了著名 IT 作者玛丽&乔&弗利(Mary Jo Foley)的采访，谈及 Longhorn 以及在职期间的其他遗憾。
　　以下为采访文章的主要内容：
　　今年八月微软 CEO 史蒂夫&鲍尔默(Steve Ballmer)宣布在 12 个月内退休。当被问及在十三年任职期间最大的遗憾是什么，他简短地答道，&Longhorn&。Longhorn 这一操作系统的发布频频推迟，最终更名为 Windows Vista，于 2007 年 1 月推出。
　　在微软任 CEO 期间对鲍尔默意义最重大的事件是：Longhorn、某些法律事务的解决、公司重组（微软于 2013 年 7 月又进行了一次新的企业重整）、比尔&盖茨担任首席软件设计师(Chief Software Architect)后两人工作关系的重新调整和定位。
　　鲍尔默在 2013 年 11 月底接受采访时谈到，&&Longhorn 变成了 Vista&，这不仅仅是我任 CEO 期间，也是我这辈子最大的遗憾，这是我犯下的最大的错误。原因是，最终推出的产品并不出色，而且还花费了五六年的时间推其上市。后来我们用 Windows 7 来取代这一失败的产品。&
　　他承认，&过去有七八年间，微软的精英团队被困其中，没有取得应有的成果。这些优秀人才本可以将时间投入到其他方面，如手机。&鲍尔默表示对此他承担一切责任。
　　鲍尔默还说，&这一错误并非执行阶段的错误，而是技术战略的错误。我们曾尝试着修正它。在这一行业，最重要的是要找准对的方向，而实施过程还得不断做调整。人们认为这一行业的变化如此迅猛，每三秒钟就该改变策略。&
　　鲍尔默表示，一些公司所下的大赌注确实带来了回报，如苹果主攻触屏和低功率设备的举措是成功的。谷歌在搜索上下大力气。而微软倚重 PC、软件以及最近的 Windows Azure 云计算数据中心。
　　当被问及对 2008 年未收购雅虎是否表示遗憾，鲍尔默表示从整体战略层面来说，收购或不收购雅虎对微软的命运都不太重要。
　　他说，&我们正在机器学习和研究等方面努力，从这一角度来说，收购雅虎有很大的意义。但现在回顾过去，当时没买下雅虎或许是明智之举，因为这一市场崩溃了。&
　　另外，鲍尔默对 Xbox 迟迟才能盈利表示遗憾。微软于 2001 年推出第一款 Xbox，2005 年推出第二款 Xbox360。但直到 2010 年左右，Xbox 的销售方面都是亏损。
　　他相信微软研发 Xbox 是正确的举动，他给予了研发团队许多自由。
　　他说，&盈利要看长远，不能短视。Xbox 是个重要的产品。&
道哥：理想很美好？
投递人&&发布于
22:52&&有1221人阅读&&&&&&&
　　有好些朋友看了昨天的文章后发消息来表示好。
　　这是不明真相的群众。就像今天周教主发了个微博说数字公司员工除夕放假一天一样，好多人在后面围观说好人性化的公司啊，却不知道数字公司内部的压力之大和加班之狠在整个互联网都是罕见的，一将功成万骨枯。尼玛现在连高富帅都知道要勤奋了，让屌丝们怎么混啊。
　　真相是，我昨天提到的那名工程师后来离职创业了，我想他是伤心着离开的。同样伤心离开阿里云的大牛里还有一个叫 Andy 的网络专家，中文名是「厉建宇」。我想「大牛」这个词也许已经不足以描述他了，用「巨牛」可能更合适一点，他是中国互联网骨干设施的先期建设者。
　　Andy 当年来阿里云的梦想是去中国西部的高海拔地区建设风力发电站，建成像 Google 的数据中心那样绿色环保的「数据中心」。要在高海拔地区建数据中心是因为气温低，可以省很多空调钱，而且建在发电站附近的话电费会很便宜，而云计算中心动辄几万台服务器，消耗的电能是很可怕的。
　　当时 Andy 给我们讲这个绿色能源的理想时让所有人都为之动容和陶醉。不过最后马云应该没有头脑发热真跑去建设发电站了，所以 Andy 的梦想在很长一段时间内都只能 YY 一下。于是他后来转做云计算的定制服务器，就像 Google 做的那样。
　　最开始是定制云计算的交换机，真不愧是网络牛人，交换机都要自己做一个。当年他定制的交换机型号叫 S13 交换机，为这个名字我们笑了好久，并总是拿这个名字和交换机领域里的另一个笑话相媲美：「24 口交换机」要改名成「24 嘴交换机」。这个 S13 交换机到最后好像也没有用上。
　　直到某一天，Andy 突然在内网写个帖子「王坚，你为什么要放弃？」，后来愤而离开了阿里云。至今在网上仍然能搜到这篇文章。
　　在这封信里他写到：
　　「思科让我回去做主管 EC3（企业级云计算），华为让我进入 CTO 办公室主管云计算业务，我都没同意，它们的薪水可都是高出阿里巴巴三倍的薪水！我想留下来，就是马总的一句&国有&企业 & 一个真正意义的公用事业！另外，是谁鼓励土豆，优酷建设自己的 FLV 基础设施呢？我怎么可能跟这些砸了我的事业的人再继续合作呢？这些设备厂商唯一想的事情就是让你多买一些，至于你能不能高效应用这些设备，它们才不关心呢！地球明天会不会因为 Global warming 而变得风雨无常，你的公司会不会因为低效而面临经营的困难都不是它们考虑的问题，因为他们只关心自己的荷包是不是够满，是不是够钱能够买一部 Audi R8 Spyder，明天会不会因为业绩不佳而被裁员&&」
　　「我为什么不愿再继续写代码 & 这几个月为了提升服务器的性能，我每天工作到半夜，连续了三四个月，在代码的世界里，我很快地就找到了自己，很快地就能够有一些成就感，特别是捡起 15 年没有再读过的 TCP 内核代码，我很快乐我能够找出它在 LFN（高性能，高延迟（缓存））的不足，但是，做这个工作我只能带动几位工程师，做绿色数据中心， 我却能够带动整个中国的互联网基础设施工业，这就是我为什么不愿意再继续写写代码，而是希望能够去改变一个产业。」
　　Andy 是另外一个不是为了钱，而是为理想奋斗的人。虽然这样的人最后在阿里云几乎都伤透了心而离去，但我也永远无法忘记阿里云的这段岁月和这些人。你可以嘲笑这样的人，但永远也无法否定这些人的存在。因为他们真的就在那里，在用那样的方式傻傻的坚持着。
　　我很喜欢和工程师们待在一起，因为在工程师里，像 Andy 这么可爱的人总是会多一些。
　　附：Andy2011 年写的：&王坚，你为什么要放弃&
　　厉建宇是美籍华人，好多观念上跟我们有很大的不同。下文就是他之前要离开阿里巴巴留下的离职信。回顾了他在蓝讯和阿里巴巴的路程。本文也展现了他的一些工作理念，应该说跟着这样的领导还是跟对人的。也许这就是 google 之所以伟大的原因中的一点：简单。
　　中文不佳，全用英文写又无法让更多的同学了解我的心路旅程，所以请各位原谅我蹩脚的中文。
　　*一个简单的道理：一块 2TB 桌面级硬盘今天的价格约为 700 元，相同大小的企业级硬盘一块今天的要价仍然超过1,500 元，这两个硬盘最大的差别是 RVI 震动率的设置（因此，桌面级硬盘在震动率稍大的时候，依然能够正常工作，企业级硬盘为了提升可靠性，所以当震动略大的时候，会停止工作，保护磁盘），两者连螺丝的位置都相同（不是用于固定硬盘的螺丝，是用于固定磁盘内部机构的螺丝），我们假设硬盘仍然坚守摩尔定律（每 18 个月容量增加一倍），一年半后就算我们需要更换所有的桌面级硬盘（注），我们还可以做到用相同的成本，获取两倍的存储容量！四年半后，我们将以同样的价格拥有四倍的存储！加上半导体制程的进步，当固态硬盘开始取代机械硬盘（约计在 2015 年前后发生），我们服务器的性能和效率能将再上一个台阶（每块 SSD 可以提供 250MB/s 吞吐量，而且只有 2.5 英寸（SFF），一台 2RU 的服务器可以配置 24 个 SFF 的服务器，也就是 6GB 的吞吐量，这也就不难解释为什么 2012 年开始销售的服务器会配置两个万兆以太网端口了）！
　　*成本！成本！成本！：我为什么放弃在 ChinaCache 的股权，回到美国求职呢？那是因为作为 CTO，我没有阻挡我的 CEO 快速扩张视频分享下载（FLV）这条业务线，结果，到 2008 年中，当土豆在投资者（VC）的降低成本的要求下，自建 CDN 设施的时候，Chinacache 的业务一下子下降了 60%，几个月前刚刚购买的交换机和服务器都必须折价出售，最糟糕的是还找不到买家，IT 设备的价格是天天掉价的！倘若当初 CEO 拒绝 10% 股权赎回的诱惑（VC 要求业绩必须连续两年出现 100% 增长），将发展 FLV 业务的经费投资在集群效率的优化，那么 ChinaCache 就可能可以用更低的成本提供 FLV 下载的业务，加上时段复卖及规模效应，就可以将 FLV 下载业务的销售价格低于土豆（自建 CDN）的成本价，土豆，优酷等视频分享业者也就不会在 VC 的压力下建设自己的 FLV 下载基础设施。两个月发不出薪水给普通员工啊！你们一定能够体会那种痛苦，我堂堂一个中国互联网骨干设施的先期建设者，居然要靠砸锅卖铁来等待 VC 的 bridge loan 来渡过那艰难的三个月，所以我把股权给了留下来的同事（不知道 CEO 有没有执行这个意愿），自己回到美国求职。相同的道理，阿里巴巴在过去十年，凭借优秀的商务模式，占据 80% 的电子商务市场，但是，业务模式创新的速度已不如前十年，同质竞争的压力又不断地增加&&&一种似曾相识的感觉涌上心头：2000 年之后，思科分别在两个阶段受到来自 Juniper 和华为的追赶，ChinaCache 只不过将类似的问题集中在一年之内爆发，所以，当这样的问题来临是，无论你请什么人来，都救不了这样的企业。
　　*新商业文明 & 谈厂商和用户之间的关系 （扭曲化的结果就是贿赂，无意义的折扣），电子商务在解决供需的问题，我们也应该用相同的概念来解决我们基础设施的问题。讲实在话，阿里巴巴和国有电信运营商采购的腐败就只有一步之远！如果厂商在我们团建时提供一桌四千元的晚餐，我们这些月薪一万元的 SA 工程师，怎么能够不嘴软呢？如果团建经费再多一点，如果厂商招待费放开一点，我们的工程师需要厂商那一点点小恩小惠吗？
　　*思科让我回去做主管 EC3（企业级云计算），华为让我进入 CTO 办公室主管云计算业务，我都没同意，它们的薪水可都是高出阿里巴巴三倍的薪水！我想留下来，就是马总的一句&国有&企业 & 一个真正意义的公用事业！另外，是谁鼓励土豆，优酷建设自己的 FLV 基础设施呢？我怎么可能跟这些砸了我的事业的人再继续合作呢？这些设备厂商唯一想的事情就是让你多买一些，至于你能不能高效应用这些设备，它们才不关心呢！地球明天会不会因为 Global warming 而变得风雨无常，你的公司会不会因为低效而面临经营的困难都不是它们考虑的问题，因为他们只关系自己的荷包是不是够满，是不是够钱能够买一部 Audi R8 Spyder，明天会不会因为业绩不佳而被裁员&&&&
　　我愿意和 Intel 合作，是因为它总是能告诉我产业发展的方向，我原因和英业达，富士康，广达，锐捷合作，因为它们总是能够非常快速的反映我们的需求（直接帮助提升我们服务器的效率），我们甚至做到让这些厂商提供原材料的价格（BoM cost），让它们自己提它们认为合理的利润，借此建立一种可持续发展的合作关系。可是，每一次一到采购，我们这些策略就执行不下去（总是买 Dell，Huawei 品牌的商用服务器），我也没脸再跟 ODM 厂商要求开发新的机种（一个原因是厂商没有因为前期研发的付出而获利，另一个原因是 2011 年项目没有获得支持，所以研发经费为0）。
　　就算在中国电信，也知道采购部门必须和需求部门分离，就这样还不能阻挡腐败的发生，我们阿里云却把运行维护，计划建设，采购放在同一个 VP 下，虽然这么做有助于解决（小）部门 KPI 被过份放大的问题，但是这三个部门合在一起，许多 Check & Balance 就消失了，结果当然不是以阿里巴巴的利益为优先，更不要提公用事业这个伟大的理想了！
　　*我为什么不愿再继续写代码 & 这几个月为了提升服务器的性能，我每天工作到半夜，连续了三四个月，在代码的世界里，我很快地就找到了自己，很快地就能够有一些成就感，特别是捡起 15 年没有再读过的 TCP 内核代码，我很快乐我能够找出它在 LFN（高性能，高延迟（缓存））的不足，但是，做这个工作我只能带动几位工程师，做绿色数据中心，我却能够带动整个中国的互联网基础设施工业，这就是我为什么不愿意再继续写写代码，而是希望能够去改变一个产业。
　　注：厂商提供的桌面级硬盘的质保也是三年，而根据 Google 提供的数据，硬盘的年损坏率略低于4%，生命周期内损坏率约为 8.6%，也就是说 90% 硬盘都能够工作三年，而不是一年半，那么一块硬盘差 800 元，12 块硬盘就是 10,000 元，11,000 台 12 盘的服务器三年的成本就节省一亿元人民币，这一亿元人民币难道不够让我们请 10 个高级系统工程师（三万元一个月也就是一亿元的 10%），，将我们硬盘跟换的流程优化，所以他们就不必每次跟换硬盘的时候都必须工作到半夜 12 点？
　　（今日题图：the ants dream，作者：Rakesh Rocky）
　　==== 道哥的黑板报 ====
　　走在创业道路上的文艺白帽子。
　　微博、知乎：aullik5
　　http://taosay.net
　　微信公号：道哥的黑板报，微信 ID：taosay
对得起自己的薪水
投递人&&发布于
22:48&&有877人阅读&&&&&&&
　　有些朋友回复昨天的文章，关于「坚持做自己认为对的事情」，提到的前提是自己必须是对的。其实那篇博客后面的一句话我没摘过来，作者是这么写的：
　　「这需要对自己的判断有信心，去树立威信，去承担责任，去做决策，去冒风险 & 换句话说，去做你被雇来该做的事！」
　　这让我想起了过去，有时候我会批评一些不努力的员工：公司花这么多薪水雇你来，是解决这些问题的，不是让你们整天来打酱油的。
　　你自问对得起自己的薪水吗？
　　这些年来，主动要求降薪的员工我只见过一个。那是在阿里云刚成立的时候，一次年会上，一名非常资深的工程师跑到台上讲他做的东西。讲着讲着就潸然泪下，他说他觉得自己做的东西还不够好，觉得自己拿的薪水太高了，不应该这么高，希望能够降薪一半。
　　我们台下的这些小伙伴们当时就震惊了！然后都暗自揣测他到底拿了多少薪水啊。。。当时这个人对理想的执着深深的震撼了我，竟然还有这样的人！而且就在我眼前，朝夕共事！
　　有时候我会回想起来，在我刚工作的头几年，我的一位老上司曾对我说过的话：
　　「让你的薪水跟随你，而不要去追逐薪水。」
　　我一直认为这句话很有道理，当你个人能力成长后，做出的贡献变大了，薪水也会水涨船高。奖励优秀的员工，这是任何一家健康的公司都会做的事情。反而是一直追逐薪水的人，可能迟迟无法得到满足，最后能力没锻炼出来，只学会「混」江湖了。
　　所以我一直以来都不是特别看重薪水，而是认真做好我想做的事情，我认为一家公正的公司会给予我相匹配的薪水。结果是虽然我从没有提出过加薪的要求，但是薪水反而每年都涨，每年都能超出期望。当然这也和我遇上了一家好公司，遇上了几个好老板有关。
　　直到有一年，我发现我的业绩不好，但是也涨薪发奖金了，我开始变得不安。我认为事情不应该是这样子，涨薪只是因为公司希望我留在这里，而不是因为我业绩好。那么肯定是某些地方出了问题，对我来说是好事，对公司来说却未必是好事，长远看对我也不是好事了。于是，后来我换了家公司。
　　现在，我的团队里也有不看重薪水的员工，我对此感到似曾相识，似乎看到了当年的自己。
　　总有那么一些东西，会比钱更重要。
　　（今日题图：the chase，作者：Jure Gubanc）
　　==== 道哥的黑板报 ====
　　走在创业道路上的文艺白帽子。
　　微博、知乎：aullik5
　　http://taosay.net
　　微信公号：道哥的黑板报，微信 ID：taosay
杂谈---2013年，总结？吐槽？灌水？
　　最近看到不少猿友都纷纷总结起自己的2013年，LZ也赶赶热潮，对自己一年的收获与失去来个大阅兵，这确实有助于自己来年的规划。如果各位猿友不喜欢写博客，也应该以其它的方式对自己进行总结，相信总是有好处的。至于LZ，已经习惯了博客，因此就暂且采取这种方式了。不过LZ也只是让手指在键盘上随心而动，所以难免是水文一篇，各位猿友尽可一笑而过。
　　既然是一个技术人员的年度总结，那么技术方面的总结自然是不可或缺的，这也算是本文唯一不算太水的一部分吧。LZ这一年来，技术方面的书着实看了不少，认真看过的大约有四五本，粗略看过的就数不过来了，包括无数篇技术文章、英文文档以及相当多数量的源码，可谓是大大的丰收。
　　说起这些书，LZ是一直不愿意吐露书名的，因为LZ一直坚信每个人适合的书都不一样。不过这一次是LZ自己的总结，并非是选书建议这一类的文章，因此还是要好好规整下自己看过的书籍。况且，如果让LZ一下子说出来看过哪几本书，还真想不出来，这就说明真的需要停下来总结一下了，否则就真的成了书虫了，只会吃书不会读书。
　　准确的说，LZ看的书几乎都是这一年以内看的，更准确的说，是去年10月份加入到现在的公司之后开始看的。到现在的公司之前，工作当中加班非常频繁，因此几乎都没怎么看，每天都沉浸在疯狂的编码当中，就算是回家学习，也大多是看看一些技术文章而已。直到来到现在的公司后，LZ看书的道路才一发不可收拾，至今为止差不多刚好整整一年多一点。
　　接下来这些是LZ一年里买的所有的书，共17本实体书，其中有1本LZ精读的电子书，总共18本书。
　　《Java编程思想》【5星】【完毕】：这本书就不说了吧，Java的经典，经典中的经典，LZ从去年10月份开始读，大约花了三个月读完。
　　《深入理解Java虚拟机》【5星】【完毕】：这本书也是经典中的经典，LZ读的时间好像并不长，但是收获巨大！
　　《重构：改善既有的代码设计》【4星】【完毕】：这本书将LZ带进了重构的世界，LZ看的也非常快，但说实话，里面的技巧目前还真没什么施展的余地。
　　《大话设计模式》【电子版】【5星】【完毕】：大话这本书是LZ进入设计模式世界的引导者，也正因为它，有了LZ的设计模式博文系列，也因此有人找LZ写书。不过LZ最近的生活和工作都有些改变（这点后面再说），所以写书一事暂且放下了，不知是好是坏，个人觉得多沉淀一下其实也好，但不得不说，写书真的是一件绝对靠毅力的事，这与写博客完全是两码事。
　　《编译原理》【5星】【后续补上】：这本书就不需要LZ评价了，不过LZ目前还没看完，当时看了大约两章暂且放下了。这本书是LZ以后必读之书。
　　《设计模式：可复用面向对象软件的基础》【4星】【进行中】：GOF的名著，之所以给4星，是因为难度太高。LZ现在看起来还有难度，原因是因为里面的smalltalk，实在是骨灰级语言。入手这本书的原因，原本是为了写书而准备的，不过由于写书的进度被拉下来了，所以这本书就没有急于攻破。
　　《Java并发编程实战》【5星】【完毕】：好书中的好书，它也算当时解了LZ的燃眉之急。通过它，LZ才算进入了并发的世界，而且并发系列也将因它而出现，目前LZ其实正在写并发系列的第二篇文章，还未发表。
　　《Effective Java》【4星】【进行中】：这本书LZ已经读了一半多，这类书给LZ的感觉是，看的时候会产生极强的共鸣，但是看过之后却记不住什么。不知道这是否是在潜在的影响LZ的编程手法。
　　《代码整洁之道》【5星】【重点进行中】：这一本书与《重构：改善既有的代码设计》、《Effective Java》十分类似，都是在讲如何编写优秀的代码，只是这本书给LZ的感觉更实用。
　　《深入理解计算机系统》【5星】【重点进行中】：这本书实在是难啃，但是LZ看的过程中收获巨大。这种书的价值体现，并不是最直观的收获，而是潜意识的影响。
　　《算法导论》【未开始】：经典之作，不过LZ一直没有时间去啃下这本巨大的著作。里面的内容相信一定是非常精彩的，LZ期待着开启的那一天。
　　《数据结构与算法分析》【后续补上】：这本书是LZ为Java准备的算法书，之前看了一些，没有继续观摩，之后也是要补上的。
　　《代码大全》【未开始】：又是一本巨厚的著作，这本书号称也是经典之作，同样是LZ十分期待的一本书，期待着开启。
　　《Maven实战》【未开始】：当初买这本是因为项目当中用到了maven，所以准备大致了解一下，结果翻了几页发现兴趣不大。悲哀，僵尸书了。
　　《linux私房菜》【未开始】：这本书是给自己准备的linux工具书，买的时候就没打算仔细看，结果买过来以后发现真没仔细看。
　　《分布式系统原理与范型》【未开始】：买它是为了了解一下分布式系统的原理，这本书LZ还是有兴趣的，只是一直没机会开启。
　　《云计算》【后续补上】：这本书是当时LZ要回家一趟，所以买了一本带在火车上看，当时也看了不少，属于一本消遣的书，算是开阔下视野吧。
　　《云计算与SOA》【未开始】：这本书与《云计算》是一起买的，因为还是想与工作联系起来，所以看到SOA就拿过来了，后续有时间可以拿来消遣，不打算细看。
　　以上便是LZ这一年内染指的书籍，其中LZ翻过的书都有相应的星级评价，不过LZ还是要强调一下，这些评价都带有LZ强烈的主观意识，因此各位猿友若是哪位没看过上面的这些书，在看过此文后准备入手的话，请慎重选择。
　　总的来说，LZ这一年在技术方面的进步还是十分明显的，看书只是一方面，甚至可以说是很小的一方面。LZ个人觉得，进步最大的原因还是对大量源码的钻研，对各种协议和规范的研究，以及对C/C++、shell、perl等多种语言的涉足。
　　说起工作，LZ至今已经毕业四年多，接触编程工作两年多。由于LZ在21岁便已经大学毕业，也算较早的一列，所以玩心未退的LZ将这早毕业的一年果断的浪费了，又因为是数学专业转向编程，所以花了半年进行编程的培训，这一下几乎两年的时间就没有了。每每想起，悔恨不已。今年算是LZ工作中转折最大的一年（有点废话了，一共也就两年多），之前的一年，由于身处小公司，尽管得到了不小的锻炼，但却因为加班浪费了不少宝贵时间。
　　这一年内，公司技术部从一年前的300多人（包含约100外包同事），发展成了现在的将近600人（包含约200外包同事），而LZ所在的项目组也算是跌宕起伏，走的人不少，来的人也不少。当时LZ来的时候项目组共有4个开发，算上LZ一共5个，现在之前的4位同事已经只剩下1位女士了，不过组里接连又来了8个开发（含4个外包），而我们的项目经理，在技术部格局调整后，已经荣升为部门经理，不过还仍然兼着我们的项目经理一职。很显然，从组里的人员流动就能看出，LZ这个刚来公司一年多一点的新人，忽然变成了老人了。
　　以前LZ的任务就是写代码，是的，没错，就是每天闷头写代码，这本来也是程序猿的主要任务。可是最近变了，这些变化让LZ有些欢喜，也有些忧。不客气的说，LZ现在所做的事，其实就是项目经理做的事，这其中很大一部分原因，是因为LZ项目的项目经理实在太忙了，毕竟部门经理是要管很多事的。尽管LZ现在还挂着个名不副实的中级工程师头衔，也没有实质上的项目经理的权利，但这种变化太明显，已经容不得LZ推脱了。
　　记得以前和别人讨论的时候，LZ说过，就算是给个项目经理的职位，自己也可能会拒绝的，总觉得自己偏向于研发经理一职。现在想想，真是可笑之极。现在还没有这个职位呢，还拿着程序猿的工资，同时干着项目经理的活，这种工资、职位都与责任不符合的情况下，LZ都毫不犹豫的接下了，要是给职位的话，LZ真不敢说会拒绝。
　　不得不承认，自从担任了这个虚幻的&项目经理&之后，LZ的能力得到了极大的锻炼。这里面技术只是一方面，在技术上来说，以前作为程序猿接触不到的问题，作为虚幻的&项目经理&，还是要处理一下的，比如系统架构，部署架构，高并发等问题。不过更多的，还是沟通能力的锻炼，每天需要应付的同事各种各样，开发、测试、业务、运维、DBA、上层领导、虚幻的&下属&、其它组的项目经理等等，基本上所有的人都得见过来一遍，因为他们早晚会来找你的。
　　这之后，工作上最大的改变，就是代码量明显骤降，目前已经几乎为0。LZ已经很久没写代码了，为数不多的几次时间也都是非常短的，因为是比较核心的代码，所以LZ只能挤着时间写，如果不这样的话，很容易被人打断。也正因为如此，所以LZ回来看书的动力更大了，生怕因此而拉下了技术。毕竟，在LZ项目组的近10个开发当中，除却一个211的应届生以外，全是三年以上经验的人。LZ作为工作经验倒数第二的人，压力还是蛮大的，如果不是LZ早来公司一步，相信也不可能是现在的情势。作为程序猿的LZ深知，要征服程序猿最简单有效的办法还是技术，因为LZ本身就是只服技术比自己强的人的一类（嘴上功夫的就不算了吧），尽管这并不绝对。
　　其实这一切现状，看似都是非常好的，是LZ以前梦寐以求的情况，也就是希望能有个&项目经理&的锻炼机会。不过这也意味着，LZ早早的就与程序猿绝缘了，两年，LZ真的始料未及。LZ个人觉得，如果升的太快，其实并不一定好事。如果尚且没有深刻体会一线，就已经早早的退居一线，看似高升了却不一定有益。更何况LZ还没有真正升上去，只是悬在半空而已，万一不小心摔下来，估计不会太轻吧。
　　说起来，这一过程中还是有不少郁闷事的。最典型的一点，就是名不正言不顺的问题。有些事情，需要组员配合，但是LZ并没有权利命令别人，尽管现在大部分情况下，组员们都会配合，毕竟大家都不傻，也都知道LZ其实也是为了项目的事，但往往有时候还是需要一些强制手段的，毕竟也不是所有事所有人都能理解的。有的时候，你管的话，属于自找苦吃，别人不一定配合你，还搞得自己好像管的太宽了。不管的话，这责任又在你身上，实在是进退两难。或许是LZ还没有找到更好的办法吧。
　　貌似说到工作这里，还是十分凌乱的，LZ自己也感觉到了，目前的工作是有点凌乱。或许是LZ还没有找到现在的节奏，以前那种没任务就看看技术文章，有任务就听着音乐码代码的节奏已经完全被打乱了。
　　总的来说，对于工作方面，还是确实有进步的，不过很明显，LZ还需要寻找自己的节奏。
　　生活方面其实变化最小，不过说小的话，其实也不小。日，LZ的女友正式来北京与LZ一起奋斗，LZ美其名曰&&北京爱情故事的开始。日，LZ的女友正式成为LZ的未婚妻。
　　自从某个欢乐的90后来到LZ的世界里，LZ的生活也产生了不小的变化。最明显的，就是LZ摆脱了一切生活琐事，可以专心的写博客、看书、写代码。90后开始还是有点意见的，不过被LZ以&一切都是为了你&的理由摆平了。自此，LZ便过上了平凡而又幸福的日子，尽管北京是个幸福指数偏低的城市。
　　千言万语一句话，感谢90后的悉心照顾，如果LZ以后有幸成功了，那么至少有一大半功劳都应该是你的。
　　本文越写越水了，感觉已经与总结关系不大了，对于2014，LZ没什么打算。因为LZ一直信奉一句话，只要大方向不错，任何弯路都是有意义的。所以LZ不打算给自己的2014铺上一堆计划，个人感觉还是没有太大必要，而且每天想着计划会有压力，若是实现了还好，若是实现不了，还可能会打消自己的积极性，有点得不偿失。如果非要说计划的话，LZ目前能想到的，就是找到自己新的节奏。
　　无怨无悔的2013，走一步算一步的2014。
如何写一篇好的技术博客
投递人&&发布于
09:37&&有300人阅读&&&&&&&
　　在工作过程中，发现对很多东西都一知半解，不是很透澈，到头来很容易模糊，如果有一篇好的技术博客予以总结，一来即使忘记了，回国头来再看，仍然能够从自己的思路中恢复；二来总结一下，还会发现一些潜在问题；三来，有利于大家交流技术。很多大公司都有自己的内部技术博客平台，写好自己的技术博客，对一个技术人员来说，也有一定的成就感。
　　在网上查阅资料，经常可以看到一些技术博客，要么废话连篇、排版紊乱，要么代码占了篇幅的 60%，有些甚至是错的，会让人产生误解。因此，在这总结一下一篇好的技术博客应该是怎样的，同时也规整自己的不良习惯。本篇博客纯属个人的一点想法，是个原则性的东西，切忌逐条对号入座啊。
　　本篇博客耗时 2 小时。
　　一、带着明确的目的写博客
　　经常看到这种博客，为了写博客而写博客。比如一篇介绍 socket 接口的使用方法的博客，罗列了一堆代码，凑上几句话：&首先&，其次&.，最后&&，就算 OK。如果你的目的是&练习如何使用写博客的软件&，或者&罗列接口&，甚至&练习写作的方法&，那么可能达到了目的。但是我想，写一篇技术博客，首先是要明确该博客的目的，通常是学习一项技术、解决一个技术问题什么的，比如&学习 Linux 内存管理机制&，&解决 kernel pannic 的问题&，&打发时间&等。
　　不是所有的的事情都要写一篇博客来记录，要有自己的判断什么东西值的写，什么东西不值的写。
　　二、写自己的博客
　　网上相互转载的帖子很多，一篇写的不错的博客经常会被转载，建议不要轻易转载别人的帖子，要写自己的博客。同样一个知识点，或者同样一个问题，你的理解和别人的理解的程度很可能是不一样的，如果轻易的看过以后转载了别人的博客，可能意味着一次自我学习或体会的机会的放弃。可能有人会说：&同样一个 GFS 的架构图，我画也是这样，他画也是这样，因为 GFS 就是这样设计的&，这里并不是要求任何一个细节都自己去做，而是要有自己的想法、自己的理解，比如 GFS 分层的原则是什么？为什么这样分层，分层的好出？如果我要是去做的话，我会怎么搞？
　　写自己的博客可不是意味着不转载别人的，比如说我看了一篇博客，并且经过实验，却是与博客里面写的完全一致，不多也不少，如果要是自己的写的话，也会写的基本一样，那就没必要再花费时间自己写了。另外，以及纯粹记录性的博客，可以转载，比如&C语言运算符的优先级&，当然转载还是原创都不重要了。
　　另外，把别人的好的博客作为自己的原创，不但没品，而且自欺欺人。
　　如果在博客中参考了别人的博客，可以在参考资料里面提及，如果是完全转载，也应注明转载出处。
　　三、博客是总结，不是过程
　　写博客有的时候是一个解决问题的过程。为了解决一个问题，今天采用了a方法，发现不行，明天采用了b方法，发现也不行，后天采用c方法，发现行了， 那么最终的博客应该是在c方法解决问题后，开始写的。当然，前面的a，b方法，是需要做记录的，但只是博客的原始材料，而不是博客本身。
　　在刚开始写博客时，我经常出现这种情况：对一个技术不清楚，想了解一下，就开一篇技术博客，边查资料边填写博客，结果基本上就是读、复制、粘贴、 读、复制、粘贴&的过程。最后落到自己手里也是空空如也，想起一句谚语：&狗熊掰梆子&&掰一个丢一个&，在懊恼自己的缓存为什么这么少的同时，我也想是否是方法不对？后来我想过，要想掌握一项技术、知识，大概需要这样一个过程：实践遇到问题&&理论学习问题&&实践解决问题&&理论总结问题。我想很多情况我是缺少了其中的三个部分，只有&理论学习问题&的过程。
　　后来，我就改成按下列步骤写博客了：
碰到了问题，如果解决不了，而又比较有价值的话，就先记录下来，作为一篇博客的开篇。
首先，先自己分析问题，基于已有的现象，思考，在笔记本上记录问题与可能的思路。
其次，从外界获取经验或者知识，比如请教别人，google 等，学习他们，在笔记本上记录关键点。
然后，在实际中用学来的方法去解决问题，笔记本做好记录，要像水流过水渠一样流淌前面记录的思路。
最后，拿过笔记本，将以上过程再总结成一篇博客。
　　当然，并不是所有博客都能够先从&实践遇到问题&开始，因为很多情况下都是先从书本理论开始学习的（这也就产生了一定的局限性，有时候你学的很好， 反而陷入了固有的框架；有时你学的不好，显得自己更加无知）。这种情况，问题是需要自己总结出来的，比如 ULK 上会介绍中断和异常的处理机制，这包括中断的过程、CPU 的工作、内核的工作、软中断的处理、tasklet 等等，我们学习中断，不仅仅是一旦发生中断，Linux 内核是按照什么流程去处理，而是要找到这么处理的原因，也就是解决了什么问题。有时，实践验证的成本过高，在有条件的前提下做吧。
　　知识开始学习的时候，经常是只见树木，不见森林。俗话说：&孤木不成林&，弄上三五棵树，才会有&森林&的感觉。
　　四、尽量拒绝三手技术
　　在实际学习或者工作中，一个问题不明白，那么就需要请教别人。如果能够从周围的高手、牛人那得到简单、直接的答复，那是最好的。如果不能，就需要自己在网上查找资料，可能一个问题，林林总总的在网上能搜出很多，选择看哪些就是个问题。尽量去选择原发性的材料，如果你在查 gcc 的一个编译选项是什么意思，可以使用 man 手册，如果还不清楚，就去 gnu 的官方站点去查，最好不要随便从某个转载的技术博客上获取。如果你要找 x86 平台 CPU 访问内存的方式，应该从 Intel 的官方站点去找 CPU 的资料，最好不要随便在网上找篇博客看了拉到（起码应该先看官方材料）。
　　别人的博客自然带有别人的理解，而这种理解可能带有一定的主观性，有时甚至是错误的，应该养成从原产地采购的习惯。如果哪天能够发明一项技术，那么这算一手技术；如果你在学习一项成熟的技术，那么该技术就属于二手技术了，如果你再从一个非源发性的地方去学习，那么很可能就是&三手技术&。当然，需要考虑实践成本，有时实在找不到源发性的材料，也不要太勉强自己了。另外，英文文章的水平整体高于国人的文章水平，应该尽量看英文文章。
　　五、分清主次、落脚关键点
　　世界万事万物都有联系，凡是和本篇博客的主题有联系的问题，都在本篇博客中描述，是不现实的，也是没必要的。个人认为，一篇技术博客应该不超过两个主题，如果超过了，就应该拆分。但是次要问题可能会有不少，这些次要问题不一定都要解决掉，但一定要分清除优先级，和主题关系比较大的，应首先解决，关系小的，应其次解决，甚至并不在本篇博客中解决。对于没有解决的问题，可以列在&遗留问题&中，对于在其他博客中讨论的问题，给予链接。
　　根据自己的能力，耕耘到合适的层次。我将掌握一项技术划分为如下层次，在博客中通常应该达到第三个层次：
听说过该技术，了解该技术解决什么问题；
使用过该技术，熟悉该技术的使用方法；
解构过该技术，熟悉该技术的架构、原理；
贯通过该技术，将该技术与自己的以有知识完全融合，可以利用该技术架构或解决其他问题。
　　六、技术博客的风格
技术博客不是论文，技术博客由其实用性。当然，也有将论文发在博客上的，比如技术博客的作者大部分应该是工程师，而不是学院派。一篇技术博客可以是小到的一个编程技巧，可以写该技巧的原理、实现方法、好处，但不要写前 500 后 300 年的历史介绍和展望未来。技术博客通常关心技术的实用性，而非技术背后理论的复杂性。技术博客也不应该过分求全责备，把文章写的大而全，而应该追求小而精。
技术博客应以陈述语气，个人感情色彩应该过滤掉，技术不是生活的全部。有人写技术博客，常喜欢加入自己的心情，&xxx 让我好烦啊&、&xxx 很难，我一直持续搞了两天没睡觉&，我个人拒绝这种&呻吟&的风格。
忌罗列代码。代码是实现的过程，而不是原理，列代码是为了看清流程，而非为了列代码而列代码。我个人的习惯是尽量少列代码，如果能够使用校小的篇幅就能说明原理，绝不使用大篇幅的代码。但是如果简单的罗列代码能够一目了然，也绝不浪费过多的笔墨去描述过程。
图片胜过文字。图片配文字比单纯的文字更加方便理解，甚至一张图就可以省略文字了，多画图，少写字是个原则。
考虑时间成本。博客基本上是以时间换知识，因此需要越来越快，记录时间也很必要。
列出时间遗留问题，以备以后解决。
提前来的2013年总
一眨眼就要工作两年了，回想当年上大学的时候，还很惊奇地问老师，那么复杂的系统，类结构是怎么想出来的&&这一年，OODP又啃一遍，还整了个部门培训，UML不是问题了，PoEAA和DDD也基本拿下了，搭个架构应该不是问题。老实说，啃这些东西占用了我太多的精力！社区也有不少关于这方面的口水战，看腻了，不过我觉得，投入了就一定有收获~Spring.Net是好东西，不过可惜的是如果架构不牛逼的话几乎很难发挥出它的力量，嘛，借鉴思路吧。现在设计模块第一件事就是要造IoC，啥调用都巴不得用代理或者命令模式，总之，思维已经完全OO了。同时也承担了比较复杂的模块设计工作，写代码70%以上的时间在重构重构再重构。不过过度设计是病，得治~我觉得OO啥的也该放放了，至少等做到设计师/架构师再说吧，瓶颈了。个人感觉现在再啃这个的收益，肯定没啃产品设计或者经济学要高。&年初啃了啃WCF，也算了解了咋搞一个分布式系统，不过可惜那个分布式项目没交给我来做，但是也不算是什么损失，蒋金楠的书真心不错，即便不搞WCF，仔细读他的书对一个学框架设计的新手也是大有益处的~&然后就是那本传说中的CLR，据说是.Net程序员必读经典，于是整了一本看了看，讲的还算比较清楚的，不过，平心而论，我觉得这东西做个了解就行了，平时写业务逻辑倒很少真用得到，除非搞框架。看这东西的感觉其实就是&&哦~原来C#慢就是这个原因啊&&哦~难怪很慢&&&说到前端js嘛，这一年几乎没怎么写过UI效果，专攻后台了，工作当中也一样。相比某些几乎总是在做界面的同事，这一点就差一些了。不过话说回来我本来就对网页前端没啥兴趣，艺术细胞欠缺&&对移动端倒是有些兴趣&&不过倒是抽空看了看js的OO机制，于是觉得函数式挺有意思，也啃了啃C#的委托和linq，其实C/OC/C++当中也有函数指针和代码块的，好东西啊~但是到java当中就真心蛋疼了！&现在年底被要求做安卓项目，于是拿视频速成了一把，目前还算顺利~还真应了老师那句话，学通一门，转啥都快，就是OC这种异端，一两周拿下也不是问题~但是如果连一门都不精的话，转啥都没戏！所以，搞.net想转安卓的，拿传智那个8天速成教程看看就ok了，java基础都不用看了，剩下的找本书过一遍然后不会的百度就是了。写java代码仿佛回到了.Net2.0时代&&没有lambda，没有传地址，没有&&简直是shit啊！！！其实我从骨子里就不太喜欢java，太土了，但是没辙，人家就是牛逼，开源大多java的，好书也都是java的。不过既然连OC这种异端语言都能让应届生上万，那就不是舒服不舒服的问题了。所以还是要抛弃所谓的技术信仰的。&写了一堆，总之技术上来讲目前倒是足以对付工作了。当初让我很好奇的类组织，现在也觉得不足为奇了。现在嘛，真应了部门经理当时跟我说的，应届生有应届生的瓶颈，两年的有两年的瓶颈（技术？），四年的有四年的瓶颈（升职？）。现在真心到两年瓶颈了，来年嘛，看看底层吧，C、操作系统、图形算法什么的，换换平台，换换方向，找找突破口。干嘛非把自己框在.net系统应用的小圈子里呢？同时也不想太逼着自己前进了，希望能每周安排至少一天彻彻底底的休息~多锻锻炼，看看动画啥的。暴食要改~书，再不多买了，够了，如今还抱着大同小异的书啃吗？找合适的人卖了吧。&现在算是网站前后台都能搞，移动端也能搞了，也有了基本的架构能力，基本成型了。下一步是迈向所谓的&中级程序员&~明年一定要做出自己的产品！内容，保密！&突然想起来，有的人说，不要太杂，还是专精一门好，恩，的确，有的人搞了10年的ORM。但是我个人认为，人家搞10年ORM的基础还不是之前把各种数据库、架构设计啥的都搞下来了吗？这种人我不也敢说他就真不懂php或者ruby。个人认为，成为专家，是有了多年经验和阅历之后的事了，知识面太窄，是专不了一门的。&其实对一个程序员来说，技术神马的都好说，学习能力应该不是问题，即便是笨也能用时间来弥补，但是有些东西，比如沟通技巧，这个只能说&&真得练！还不是光练就行了，像我这种不太擅长交际的人，啃心理学的确有必要。啥人都有，有的人讲一百遍都不明白还不照办，有的人一句话就能说明白问题。总之，他就那样，你急又能怎样？你急了，你就输了。这方面吃亏了，就该注意了~为啥呢？DISC把人分成16种，MBTI也分16种，九型人格9种。一个人的方式，并不能适合所有人，所以就有摩擦。所以沟通上就得学着&量体裁衣&，把握受众的需求很重要~&看似很单调的一年，其实各种闲书电视剧也看了不少，买了3DS刷了不少游戏，基本每个周末都各种应酬吃喝出去玩，充实的很~恩，差不多就是这样，就写到这，这一年收获还算不少，来年调整方向稳步加油~
Dropbox CEO Drew Houston：如何在第一次创业就旗开得胜
投递人&&发布于
10:01&&有137人阅读&&&&&&&
　　英文原文：
　　本文刊登在&&上，讲述了&&CEO&&创立 Dropbox 的一些前期经历，以及他作为一个第一次创业者，在 Dropbox 的经历让他学到了一些什么需要注意的地方，值得年轻创业者细读。文末我们也贴上了 Dorm Room Fund 近期对 Houston 的采访视频。
　　2007 年的时候，Drew Houston 去了旧金山，他想要为 Dropbox 寻找一位联合创始人。当时的 Dropbox 就只有他一个人，没有投资人，没有团队。Houston 听从了一个朋友的建议，未经邀请便直接走进了 Y Combinator 的办公室，找 Paul Graham 咨询关于如何找到合适的联合创始人，但这并不顺利。Houston 在最近 Dorm Room Fund 的采访中告诉学生们：
那不是什么好建议，在未经邀请就擅自进入 YC 办公室。YC 就像是一所顶尖大学一样，所以这就好像你直接去找招生办公室主任，而最后他们都觉得你是个混蛋。我当时在回去的路上可谓更糟，不仅没有联合创始人，估计以后进入 YC 都成问题了。我很慌张。
　　但好消息，早期的联合创始人如此重要，以至于 Houston 最后在 MIT 校友中找到了 Arash Ferdowsi 并通过 Dropbox 的美好愿景而进入了 YC。现在 Dropbox 已经是有 2 亿用户并在高速增长的公司了。这虽然不容易，Houston 在这给大家推荐了六个关于第一次创业的策略。
　　1）从一个值得解决的问题入手
　　创业者就是为了解决问题而出现的。当 Houston 还在大学的时候，他有一次注册了一个线上游戏的测试版本，当时他很无聊，于是就开始到处找这个游戏的漏洞，被他发现了很多安全上的隐患。当他开始告诉游戏开发者游戏中各处的漏洞时，开发者就直接邀请他加入他们，这也称了 Houston 第一个工程师的经历。Dropbox 的出现其实也有点异曲同工之妙，当他开始为了自己的储存容量不够而烦躁的时候，他就像解决这个问题。
　　但并不是所有的想法都意味着好想法，有些并不值得你花时间去做。但这还是有一定规律的，特别是从一些很成功的创始人身上，Houston 总结出一些如何分辨想法好坏的要点：
　　你总是放不下你的想法，一直想要把它实现。这其实是最基本的，但也要注意区分你的想法到底是不是在真正解决一个问题。&有时候你突然会想自己是不是走火入魔了，根本停不下一直在思考它，这其实就是最基本的，因为这种兴奋的&蜜月期&总会过去，你会发现当你把&创始人&印在名片上之后，要做的事简直多到不可想象&。
　　你觉得你的想法大有可为。Dropbox 现在已经有 2 亿用户，并朝着 10 亿的目标迈进，Houston 表示：&对于类似 Dropbox 的想法，就好像&wow，这东西只要能上网的人就可以用&，每个人都需要这样的服务，只是他们还没有意识到。我们的世界观告诉我们需要理智，所以在你开始疯狂之前，一定要清楚未来的路该怎么走，至少得对未来的潜在机会有个概念&。
　　你的想法能让你学到很多。最聪明的人总是会去能学到最多东西的地方，就像你加入一家世界级的公司，里面到处都是人才，这才是最快的学习方法。但同样的，你也能从创业的各种错误中收获很多，这时你应该问问自己：&去实现我的想法到底能不能让我学到很多？&
　　2）你是初学者？不，你是创始人
　　据 Malcolm Gladwell 的书中所讲，一个人真正成为某一方面的专家需要花费约 1 万个小时，鉴于创立公司所面临的各种挑战，一般人可能会觉得创始人最好需要是一个经验丰富的人。但 Houston 并不这么认为，他举了很多具有说服力的例子：Google、苹果、戴尔和 Facebook，这些巨头全都是由初学者或是第一次失败了的人创立的。Houston 表示：
有时候不知道所有的事情是好事，当你在自己的职业道理上进步时，你会更加了解这个世界，以及任何事情的可能性，而当你脑中有了这些定性的时候，你就会越来越觉得受限制。
　　Houston 举了一个例子，一个以前外界对 Dropbox 的评价：
　　&幸运的是，Dropbox 的创始人们都太笨了以至于不知道人们早就准备好想要使用他们的产品。&
　　Houston 说道：&其实很多变革性的创新都来自于不可能，只不过那些创始人并不知道或是在意他们做的事本来是不可能的。&低估你自己对世界的认识很重要，在你开始之前或许很多东西对你来说都不满意，但当你真正了解到那些伟大公司出现的背后并不是来自于魔法，而是一些人做了别人认为不可能的事。
　　3）什么都不知道 & 先发劣势
　　当 Houston 有了 Dropbox 这个想法时，当时人们觉得他想要解决的问题并不存在，人们已经有了 Email 附件和 U 盘，更别说容量大的移动硬盘了。那人们还想要什么呢？即使是当时一些有远见的人，也觉得这方面的解决方案，最后会来自于 Google 和微软。Houston 表示：
人们一般为在自己所拥有的基础上做出一些假设。但你必须要问自己，未来 5 年里人们真正的会满足于这些东西么？如果现在有一个魔法文件夹，可以让人们把所有东西放在里面并在任何时候任何地方查看使用呢？
　　很多创业者心中既存的假设就是，他们需要在某一领域做第一个吃螃蟹的人，以此才能赢得优势。但看看 Google 身边的巨头公司呢？雅虎、Alta Vista、Ask Jeeves 和其他大大小小 100 多个搜索引擎公司不都是受了 Google 的启发么？Facebook 不正是在进入社交网络市场后挤掉了 MySpace 和 Friendster 才壮大到今天的规模么？
　　做第一个吃螃蟹的人会面临的问题是，当你做了，你开创了一个新的市场，并且也为后来者打开了一扇门，而如果一旦你做不好离开了，那总会有在这个门里成功的后来者。所以我觉得一个市场里的先后并不重要，重要的是你能够打动用户的心。
　　当 Dropbox 在 2007 年开始时，市场上已经有上百个小型线上储存公司，所以在当时并不是什么新鲜事物，就像现在的照片分享产品一样。不过重要的是，你不能去在意其他人正在做的事，而需要专注于你想要解决的问题，这就够了。
　　即使到了现在，Houston 也一直在强调 Dropbox 的 400 个员工一直在和拥有 4000 人的 Google 对抗，这有时会让他感到害怕，但他不能将这种害怕表现出来。而到了最后，技术才是关键，用户数量或员工数量并不能说明什么。
小的团队能够和大公司相抗衡是因为它们的高专注度和反应速度，这也是创业的乐趣所在。
　　这样的挑战在一些人眼里好像是一个赌注很大的赌局，成功的几率似乎很小，但 Houston 尽了他最大的努力来降低任何风险：
人们总是假设或者是误解加入一个创业公司或自己创业就意味着高风险，但在我看来其实这很可笑。即使到最后没有成功，创业的经历仍然是你得到的最有价值的东西，而最坏的结果就是你最后说&好吧，算是被我搞砸了，现在先在随便一家公司找个年薪 5 位数的工作吧&，风险早已经是过去式的概念，你的父母或许会不能理解，但你应该知道，承担这些所谓的风险并没有任何的坏处。
　　4）打造一个知识机器
　　对于 Houston 来说，学习新事物已经让他上了瘾，他甚至将这种学习系统化了。
　　&我之前居住在波士顿的一家创业公司工作，借住在一个朋友家里。但每周末我都会拿着折叠椅到楼顶上去，并带上我在亚马逊买的书，我会坐在楼顶把它们全部读完。整个周末我就一直在读书读书读书。&
　　他的学习过程并不复杂，但在 Houston 脑里是有一些他一直关注的主题：&就好像，恩，我觉得我不懂销售，所以我就在亚马逊上搜索相关的书，把排名前三的都买回来读。不仅是销售，marketing、财务、工程等等，如果当时有什么东西对于我很重要的话，那就是每个楼顶的周末。&
　　如果你还没有创过业，或者还未在一家创业公司工作过，你现在的工作会让你进入一种垂直的学习曲线，你不可能在一开始就知道所有的事，你需要 a）尽快的学习，尽快的吸收，或者是 b）将未来的学习计划规划好。你需要准备好不停地接受挑战。
你必须养成一种思维定势：&ok，接下来三个月我必须搞清楚 XXX，六个月后...&你需要不停地更新自己，把眼光时刻放在那些最前沿的东西身上。
　　这其实一些你不可能在一个晚上就养成的技巧或习惯，你不可能一夜之间就成为一个出色的经理，亦或是不可能一夜之间就能搞清楚如何融资，这些是需要你越早去学习才能越发吸收的知识。
　　作为一个创始人，这适用于你自己和你的员工。这将益于你招揽那些有才华的员工，比如 Houston 有一次就找到了一个才华不被他之前公司赏识的人：
Dropbox 有内部创业的项目，我们会花很多钱在上面，这个人当时被我指认为负责人，而对于一个 20 刚出头的人才来说，在有 2 万名员工的 Google 很难发挥自己的长处，他甚至有一次说道 Dropbox 让他做了一些他甚至还未准备好的事。
　　5）聪明点，反应快点
　　Houston 可能在一开始的确气了一把 YC，但他后来却能够改变这种局面，他说道：
当时离 YC 申请的截止日期只有几个星期了，我就意识到了紧迫感，立即开始申请。但问题是我只有一个人，而 YC 比较倾向于多于一个创始人的团队，但我想的是管他呢，申请了再说，于是我当时拍了一个视频。
　　那个视频现在却成为了 Dropbox 的神话故事，不仅是因为它在 Hacker News 和 Reddit 上备受关注，它同时也引起了 YC 合伙人 Trevor Blackwell 的注意。而关键还在于 Houston 知道他的观众到底是谁，他知道如何让观看视频的潜在用户对 Dropbox 感兴趣，虽然是 Houston 在自己卧室凌晨 3 点的时候拍摄的，但他知道该说什么，并且最后也奏效了，他收到了 Paul Graham 的邮件，但他仍然还需要一个联合创始人。
　　同样地，在找合伙人上 Houston 一样知道自己想要什么样的人，之后的节奏就和申请 YC 没什么两样，虽然 Houston 表示：
这就像要我找一个两周以后的结婚对象一样。
　　但幸运的是，当他去和一个朋友的朋友哦&& Arash Ferdowsi 见面时， Ferdowsi 已经看过了 Houston 的视频，这位 Dropbox 未来的 CTO 表示了自己很感兴趣。
我们去了学生中心的咖啡厅，因为当时我看上去就像是个聪明一点的学生，我们谈了两个小时，最后他说&好的，我下周就退学&。
　　6）不要迷失方向
　　公司总会不可避免的扩张，但 Houston 深知保持高专注度的价值。这对于现在的 Dropbox 来说非常重要，因为它才招入了上百个新员工，并且开始像企业级软件领域进发。
　　很多成功的创业公司都会说他们的公司文化是在有组织地发展，比如像等到 100 到 300 人的公司规模后才会进军国际市场。但 Dropbox 不是这样，Houston 主张尽早地国际化：
当你在学习并为了一个工程学学位努力时，像任务和价值等因素不是你的考虑范围。但其实你必须要从用代码打造一个系统的角色转化到打造一个人的系统，就像是更新你的操作系统。你需要尽快地适应。为了将这种文化持续下去，我们必须把愿景放在高于钱或产品本身上，而是专注于为用户创造的价值。我们要帮助大大小小公司的员工更加有效率地工作，缩小 IT 部门和其他部门的隔阂，这些才是我们想要呈递的价值。
　　Dropbox 并不只是在软件服务上的更新，他们想要朝着打造一个全人类共同记忆这样的愿景而努力：
我们常常受到人们的邮件，很多让我们非常的自豪。他们会告诉我们&我刚用 Dropbox 举办了一个音乐会&或是&我做一个电影&或是&我终于打造了自己的公司&等等。人们不停地告诉我们 Dropbox 是如何改变他们的工作方式，我想这才是最有价值的地方。
　　附采访视频：
刑法第133条的规定
&根据刑法第133条的规定，对交通肇事罪规定了三个不同的刑级（量刑档次）：　　1．违反交通运输管理法规，因而发生重大事故，致人重伤、死亡或者使公私财产遭受重大损失的，处3年以下有期徒刑或者拘役。　　此处所谓&发生重大事故&，根据《解释》第2条第1款规定，是指具有以下情形之一的：　　（1）死亡一人或者重伤三人以上，负事故全部或者主要责任的；　　（2）死亡三人以上，负事故同等责任的；　　（3）造成公共财产或者他人财产直接损失，负事故全部或者主要责任，无能力赔偿数额在三十万元以上的。圣骑士(じ☆ve)&&10:52:26《解释》第2条第2款规定：交通肇事致一人以上重伤，负事故全部或者主要责任，并具有下列情形之一的，以交通肇事罪定罪处罚：（1）酒后、吸食毒品后驾驶机动车辆的；　　（2）无驾驶资格驾驶机动车辆的；　　（3）明知是安全装置不全或者安全机件失灵的机动车辆而驾驶的；（4）明知是无牌证或者已报废的机动车辆而驾驶的；　　（5）严重超载驾驶的；　　（6）为逃避法律追究逃离事故现场的。其他特别恶劣情节，是指具有下列情形之一：（1）死亡2人以上或者重伤5人以上，负故全部或者主要责任；(2)死亡6人以上，负事故同等责任的；(3)造成公共财产或者他人财产直接损失，负事故全部或主要责任，无能力赔偿数额在60万元以上的。圣骑士(じ☆ve)&&10:54:17根据刑法第133条的规定，犯交通肇事罪的，处3年以下有期徒刑或者拘役；交通运输肇事后逃逸或者有其他特别恶劣情节的，处3年以上7年以下有期徒刑；　　因逃逸致人死亡的，处7年以上有期徒刑。　　第六条行为人在交通肇事后为逃避法律追究，将被害人带离事故现场后隐藏或者遗弃，致使被害人无法得到救助而死亡或者严重残疾的，应当分别依照刑法第二百三十二条、第二百三十四条第二款的规定，以故意杀人罪或者故意伤害罪定罪处罚。圣骑士(じ☆ve)&&10:55:25撞死人要赔钱的，这个是定下来了，但是判刑是看事故责任认定的，一般只要不是肇事逃逸或者无证等一些严重情况是不会被判刑，最多也就拘留几天，而且通常赔钱了就算肇事逃逸也不会被判刑，当然要看情节，情节过重弄的电视台都知道了，那迫于压力那公安局就要开刀了，也要看人品，如果人品不好，死人的家属势力比较大闹到网上，本来你有理的也可能变成没理，网上一传一炒作，事态扩大，那就倒霉了，曾经有个公安局长撞死人，的确是酒后不小心，但是后来被当做故意杀人判了死刑，所以尽量避免发生此类事情，如果发生了，钱要赔足了，然后活动一下，尽量不要让自己进班房，当然进不进班房不是说没钱赔就要进的，二者没有什么关联，有关系的话，该进去的可能钱赔到位了就不要进了，关键是把死者家属稳住。&
前Google人谈团队管理
投递人&&发布于
12:26&&有870人阅读&&&&&&&
　　本文作者 Tomasz Tunguz 是 Redpoint Ventures 的风险投资人，曾在 Google 担任产品经理并参与过 AdSense 项目。
　　我有一个朋友，他创立了一家很成功的公司，而且还在迅速发展。在最近的一次聊天中，我向他询问过去几年最大的收获是什么。他说，在创业之前，他把管理看成&创可贴&，用来弥补组织设计上和公司正常运营上的错误。但随着时间推移，他渐渐意识到，管理是公司建设的唯一途径。而他接下来所说的，更令我久久无法忘怀。
　　&公司管理也有软件工程领域所说的设计模式（Design Pattern）&。在工程领域，同一个问题总是有无数个解决方法。一般来说，工程师们利用设计模式来提升工作质量，通过标准化的做事方式来促进团队沟通，从而加速公司发展。
　　管理团队的方法有无数种，但有些方法在影响力，激励作用等方面显然更优。和工程师们一样，经理们也创造了一系列设计模式，从中发现最佳方法（best practice）。
　　对于工程师出身的人来说，学习管理方面知识的机会很少。我也是在 Google 担任助理产品经理时，由于每两周都要向上层汇报才第一次有所耳闻。这些最佳方法可以给管理者一个很好的思维模型，让他们一点点变得更好。以下便是我总结的两个创业公司管理方法。
　　创业公司管理最佳方法1：情境管理法
　　我首先要谈的，是从我的妻子，同时也是 Google 一名出色的经理那里学到的，叫做情境管理法（Situational Management）。
　　在创业公司中，管理者最重要的作用就是激励员工去完成公司的目标。每位员工工作的动力会随着时间变化，这意味着管理者的做事风格和制定的目标需要对这些变化有所回应。同一种管理风格不一定对每位员工或某位员工的不同的职业阶段都适用。换句话说，不同的情境下有效管理的含义也不同。情境主要有四种：如图所示，横轴表示员工技能水平，竖轴表示员工工作动力，离原点越远表示越高，每一个圆表示一种情境。
　　动力低，水平低：这个情境很简单。它表示员工没有处在合适的岗位上，或者不知道如何在公司里起到有效的作用。这时公司和员工差不多就该分道扬镳了。
　　动力高，水平低：这是员工被聘用或者升职之后最常见的情境。这时他们往往充满激情，但却不了解公司情况，公司文化或者不清楚具体的工作内容。这种情境下最佳的管理方法是微观管理（Micromanagement），将员工的动力转化为技能，从而使员工的工作更加高效并感到被重视。具体来说，这时管理者需要时常关心员工的工作进度，不断取得他们的反馈。如此，员工学习周期变短，了解自己每天工作的效果。几周之内，他们就会学到很多，变得更加高效。
　　动力低，水平高。换句话说，快被榨干了。员工已经为公司尽心尽力工作了很久，而管理者这时最大的风险是员工跳槽。面对这样&累感不爱&的员工，管理者最好是给他们几周的时间&透透气&，允许他们自己喜欢或独立负责的项目，找回原来的激情和动力。
　　动力高，水平高。这无疑是员工最好的状态，而此时最好的管理方法就是无为而治。
　　情境管理法提供了一种简化的框架，帮助管理者确定每位员工所处的状态，并用正确的方法发挥他们的潜能。
　　创业公司管理最佳方法2：合理的团队规模
　　在创业公司的核心，它的一大优势是专注带来的速度。组织良好的团队可以完成伟大的事情。创造良好的沟通交流环境是创业公司管理的重要组成部分。而创始人需要平衡的，是控制范围（span of control）与管理职责范围（span of managerial responsibility）之间的关系。
　　但在《纽约客》的中，Amazon 的杰夫&贝索斯关于交流这一点却发表了大相径庭的观点：交流是低效的表现。它意味着员工没有紧密地、有机地工作在一起。所以，我们应该减少交流而不是增加交流。
　　贝索斯利用&两个披萨的团队理论&来减少沟通。即如果两个披萨不能让一个队伍吃饱，说明这个队伍太大了。梅特卡夫定律（Metcalfe's Law）指出，一个网络的价值等于该网络内的节点数的平方，而且该网络的价值与联网的用户数的平方成正比。套用此定律，一个团队里的人际关系的数量会随团队的人数增加而指数型增长。所以很多人认为，团队越小，所需的沟通越少，则团队会更加专注，产出更多。
　　如何管理这么多小团队？一个经理管得来吗？在 Google，我估算过不同项目里产品经理和工程师的比例。而这个比例更一般的意义就是&控制范围&。根据我的估算，Google 的平均比例是 1:7，但不同项目的偏差很大。工程师较多的搜索团队，产品经理和工程师的比例的 1:20 甚至更高。而一些新产品的比例可能是 1 个产品经理配 2 到 4 个工程师。
　　为什么偏差这么大？我发现最佳的解释就是 Peter Drucker 所提出的&管理职责范围&，即团队&所需的指导和协助的程度&。换句话说，一些资深的工程师团队，如 Google 的搜索质量团队，不需要很多指导与协助，因为他们已经有足够的经验。这些队伍即使超过 15 人，也能保持卓越。而对产品或新领域不熟悉的初级团队，需要给他们更多的职责，意味着更小的团队规模。
　　有些公司如&和&&采取扁平化的结构，让员工进行自我管理。这些管理结构可能很有效，但前提是队伍不需要很多指导与协助。而，团队规模没有最好，只有更好。而更好的团队规模一定很好地平衡了&控制范围&与&管理职责范围&的关系。
　　本文参考以下来源：,&,&
关于程序员去大公司还是留在小公司的思考
&&转眼间已经工作近四年了，每年都有新的目标无论是薪资还是技术体系的不断完善。最近这几天&是不是该去大公司待几年&的想法总是不断的涌现在我的脑海中，这个想法从开始参加工作就已经产生了，下面说一下这个由来已久的计划：&刚开始工作的这几年 一是积累技术，因为 不是专业出身，二是积累金钱解决生活以及家庭问题。待到这两个问题都解决之后，去大公司待几年学习更为先进的全面的技术，开拓眼界，做出一些对人们影响更深的一些产品，二是为自己贴上一个光鲜的标签，算是一个资历吧，然后再去小公司去带领团队，将自己的思想和公司业务融合在一起，去干出一些更有意义的事情。&，这就是四年前开始参加工作时的职业规划。& & & & 现在可能感觉时机已经成熟了吧，所以这个久违的想法开始出现了。& & & & 结合朋友、同事、领导的建议 综合自己的思考，决定继续留在小公司发展，放弃原先计划中的&去大公司&的计划。& & & & 我觉得这个问题对于广大的技术同胞来说应该是有所涉及的，所以下面说一下我个人思考的几个方面，希望能对大家在这个问题的思考上起到一些参考作用。& & & & 1.薪资-我们的生存基础& & & & &如果你说刚开始就说钱，太现实太势利，那请你离开。薪资是我们生存在这个世界上，用来交换我们一切生活资料，保证家庭幸福的资源，除非你还有另外的获取钱的渠道，但是对于目前我们这些以上班为生的人来讲 这是我们获取生存资源的唯一途径。& & & & &如果你从小公司跳槽到大公司，那说明你的经验以及技能方面还是不错的，其实也是正因为如此，你在小公司拿到的待遇应该比大公司高才对，这里略去其他因素只考虑我们可以掌握把控的东西，就是我们自己的技能和经验。如果你不能顺利完成由小跳大的过程，那就继续努力学习吧。& & & & &所以，作为在一个小公司有着可以去大公司的技能和经验的人，薪资待遇应该是不错的，当然是正常情况下。& & & & &也就是说从薪资方面，就不应该跳槽。& & & & 2.前途-个人发展& & & & &其实在我们可以生存的不错的情况下，也就是说上述第一个方面对你的生活家庭影响不大的情况下，那么我们的个人发展就是最重要的。& & & & &说一下我认为的在大公司的情况：可以见识以及学习到很多，因为大公司强大业务的需要而自主研发的新技术新产品，可以对我们的技术体系起到一个提高的作用，我们开发的产品也会有很多的人使用，经过自己的努力，几年的时间可以做到一块业务的领头人。当然 以后还可能有更高的发展，但是我们目前讨论的是我们在公司普通员工的这个层面这个阶段所考虑的问题，未来谁都无法预测，我们讨论的只是眼下的两三年的预测。或许以后开始创业或者去小公司，以现有的资历和技术去带领一个团队，开始征战在互联网这个领域中。& & & & &下面再说一下在下公司的情况：作为一个在小公司有着完善的技术体系和经验的人，对于整个技术团队有着领头羊的作用。对于公司上层来讲，你是核心，是团队的核心，是项目的核心，有领导以及团队人员的信任与赏识，在这个环境中去发展。随着小公司的业务发展，由小变大，那些在大公司可以见识学习到的问题也会在不久的将来遇到。换一个角度，如果你对技术很是饥渴，没必要一定去大公司，通过周围在大公司朋友就可以了解学习到的。在小公司不断发展的过程中，我们会面临着不同的问题 不同的挑战，这些在已经成熟了的大公司是无法遇到的，这样的机会也就只能在这里有。而你个人在公司的位置或影响也会是不断的提高。无论是在公司继续还是创业，这个经历过程中学到的东西将是无比珍贵的。& & & &&那些前辈们在我年少的时候曾经告诉过我一句话"在一个公司至少要待上四年以上"，现在想想确实很有道理。其实这句话所表达的重点不是几年，要表达的是我们需要在一个公司一个地方经历一个过程，这个过程中我们会积累很多东西，领导的信任与赏识、项目的积累和贡献、团队中的位置和影响、公司的业务发展、还有自身的定位 等等，这些东西都是我们需要花很多时间才能积累到才能察觉到的。如果我们像流水一样，不停的在流过新的地方，我们是无法得到这些用时间才能积累到的东西。& & & &刚开始工作的前两年由于年少浮躁以及迫于生活压力以及对自身定位不是很明确，换了几家公司。现在在这家公司待了两年多了，着实的感觉到积累了很多东西，对自己的职业规划也越来越明确了。所以决定在这个公司在现有的基础上去努力的奋斗吧，有些东西还是用时间去经历，会给你一些你意想不到的东西。& & & &至于去大公司还是小公司，还是都依据自己的情况来量体裁衣吧。大公司有着成熟的体制和业务，小公司充满了机遇和挑战，选择什么就看你自己想要什么了。& & & &不过说实话，现在大公司对于我现在没有什么吸引力了，因为在大公司的那些东西我通过自己和周围的朋友就能了解到学习到。我想在现在的小公司，在现在积累的资源上（已经干了两年了）继续努力的奋斗下去，未来不知如何，但我会用不断和学习和努力去面对。也许再过两年，我会积累一些新的东西。
明年形势大好？三成开发者将考虑 Windows Phone 8
投递人&&发布于
08:11&&有2549人阅读&&&&&&&
　　对于应用种类依旧稀缺的 Windows Phone 来说，争取开发者支持当然是关键。根据分析机构 Strategy Analytics 的调查，明年对于 Windows Phone 似乎会很不错。
　　Strategy Analytics 的调查数据显示，2014 年预计会有 32% 的开发者愿意进入 Windows Phone 的生态系统中，与今年的 16% 相比增长了整整一倍。
　　分析师认为，除了 iOS 和 Android 这两个本身就拥有庞大用户基础的操作系统之外，其他手机系统要想获得开发者的青睐就必须要有良好的 HTML5 支持。就目前来看，也就只有 Windows Phone 能够提供这样优秀的环境了。
　　最近一段时间对于 Windows Phone Store 来说是一个值得纪念的时段，Vine、Instagram、Waze 等重要应用先后发布标志着 Joe Belfiore 所谓&应用空白&开始被填补。不久前微软声称 Windows Phone Store 累积下载量已经突破 30 亿，前景可谓让人期待。
开会那点事儿：互联网会议之怪现状
投递人&&发布于
14:02&&有767人阅读&&&&&&&
　　转眼又到年末，互联网行业里各类名目的年度会议又纷至沓来。说起来，互联网行业真是三百六十行里最爱开会的行业，几乎每天都有会议发生，一般都还场场爆满。这真是奇了个怪了。洒家在互联网圈里混了七八年，大大小小的会议参与过不少，目睹行业会议之怪状，不吐不快。
　　互联网行业大致都有哪些会：
　　1、垂直媒体搞的行业会议
　　这类会议的主办方的意图很明确，就是捞金，是最没节操的会议。一般通常就是几个环节，主题演讲、高峰对话和颁奖。一般原则就是谁给钱安排谁上去演讲，谁给的多让谁先讲，至于所谓的颁奖更是谁掏钱给你谁发奖，反正就是没节操无下限，甭管你服务多差劲，只要你出钱，就敢给你一个最佳服务奖。只要你给钱就别发愁拿不到奖，什么最佳，最具，最有，只有你想不到，没有你拿不到。
　　2、XX 组织搞的国际会议
　　这类会跟媒体们搞的行业会议差不多，就是打着 XX 组织期号，在 XX 政府机构的指导下，以行业交流的名义来捞钱。捞钱的方式有种种，比如展台、演讲、奖项等等。这类会议走的通常都是高大上的路线，国内国外的巨头大佬们总会邀请几位，会议地点必须选在国家会议中心这样的高大上的场所，各种肤色的盲流老外混杂其中，立马感觉会议很有档次。大佬在台上讲的激情四射，台下屌丝跟随大佬描绘的光辉前景意淫不止。
　　3、厂商搞的新品发布会
　　相比来说，厂商搞的发布会还算是有节操的。目的也很明确，就是搞会议营销，通过一个酷炫的发布会吸引下媒体的关注，然后再给脑残粉们洗洗脑，回头一准产品大卖。
　　前几年这种会并不多。自从雷布斯搞了小米，复制乔布斯发布苹果新品那一套成功后，手机和 PC 厂商发布新品时都时兴搞一个发布会。曾有一个星期，几大手机厂商争先恐后的发布新品，可把媒体圈的朋友累的够呛，在朋友圈里一直抱怨这周会太多，天天熬夜做专题。不过累是累了一点，车马费不是也挣得多了不是。
　　4、巨头公司搞的开放会
　　最近一两年又多了一类会议，不知道那个巨头先起的头，阿里巴巴、腾讯、百度等互联网巨头开始大搞开放会。这种会议完全是挂羊头卖狗肉，醉温之意不在酒。说是的开放会，其实就是怕别人说自己是垄断。说白了，开放其实是为了更好的垄断，把苦逼的中小开发者连哄带骗的招致麾下，把他们关在自己造的笼子里，表面上是帮助开发者，其实是为了更好的构造自身完整的生态链，让天下都成为自己的生意。
　　那类群体跑会最积极：
　　1、媒体记者
　　记者肯定是最积极的，积极的原因大家都清楚，被邀请的记者是有车马费的。一般也就是两三百，虽然不多，大小也是钱是不。所以一般会议里最不缺的就是各类媒体记者，鱼贯其中。当然也有不少记者是冲着新闻去的，希望能采访到一两位行业大拿出出稿子。还有一类记者跟会虫无异，到场领到车马费，去会场扫一眼，屁股还没热，直接就走人了。回头按照主办方的新闻通稿，发一篇稿子也算是对得起主办方了。
　　2、搞商务合作的
　　互联网行业里最活跃的一份子当然是各类商务合作人员了。这类群体的称呼有很多，BD 经理，商务经理，推广经理，市场经理等等，基本上干的事儿都一样，吃饭的家伙就是刷脸。行业会议每每聚集一两千人，正是刷脸的好机会，当然会热情参与了。通常把自己收拾的人模狗样的，准备下几百张名片，到会场见人就交换之，时不时还要交流一下，你家是什么产品啊，需要合作吗？甭管懂不懂，就是跟人家一顿乱聊。几小时下来，换得百八十张名片，搞定收工。
　　3、草根创业者
　　这类参会者基本上是奔着参会嘉宾去的。一般会议组织者为了吸引参会者，都会竭力邀请行业内