[email protected]:~$

  • 2017 书单总结

    写了些 2017 印象深刻的书,有些是重读,有些则是 2017 年才感悟深刻。 《毛泽东选集 一》 以前认为崇拜毛泽东的人不可理喻,读了这本书认识到他的思想和意志力的确让人佩服。毛泽东用精准的眼光去分析问题,直指本质,多年不动摇的坚持并证明。而其总结的方法论就是 “了解、研究,研究透彻自然有解决的办法”,让人感到理所当然,又感到恍然大悟,大道至简,知易行难啊,整本书用我们熟悉的历史来反反复复的描述这一方法论的实践。你可能熟悉历史但不熟悉其背后的时局战略,你可能熟悉时局战略但不知其因,你看了这书后就都懂了并且会很佩服毛泽东。在当今社会,真的很难相信一个人可以毫不怀疑的坚信理念这么多年,并直至成功。 《漫步华尔街》 在读这本书前根本搞不懂股票、基金、指数基金。这本书清晰明确的阐述让我相信定投指数基金,并且按照此方法定投一年获得了年利率 10% 以上的收益,所以推荐给其他不懂理财的人。 《自私的基因》 非常推荐,看完后对族群的竞争,基因的演化有了更好的理解。书中有大量对不同物种,不同种群,不同性别间竞争策略的阐述,用类似的方法分析如今的社会现象似乎也行得通。和《枪炮、病菌与钢铁》的作者风格很像,忘了是哪个作者在新几内亚群岛养鸟了.. 《高性能 MySQL》 后端程序员必读,浅入深出,明白了很多以前模糊的地方。 《被讨厌的勇气》 自我怀疑、抑郁、焦躁的话可以读一读,作者用阿德勒心理学一个个的击破病因。看起来像成功学(尤其是书腰),读完感觉还是有不错疗效的。 《火凤燎原》 隔了几年重读,仍然感觉惊奇。 一本讲三国的漫画,颠覆历史与演绎。你认识每个人物,但你又不熟悉每个人物。你知道故事的结局,但是永远也猜不到它是如何发生的。董卓入京到官渡之战大约十年,作者现实中也画了十年(现在已经画完赤壁了),可见用心。

  • 介绍下 IO loop 和 Ruby 并发网络库 LightIO

    说到脚本语言与高性能, Node.js 凭 benchmark 给人留下很深印象。 Node.js 的高性能来自于异步 IO。Node 本身提供了 IO loop 和大量的异步接口,而其臭名昭著的 callback hell 也是源于此。 IO loop,顾名思义就是一个循环,用来处理响应 IO 的代码。一般此类库的接口会允许注册一些 callback 用来处理 IO 结果。 类似的语言或库大同小异,用 Ruby 的 EventMachine 库做比方: # echo server 经过简化 class EchoServer < EM::Connection def receive_data(data) send_data(data) end end EventMachine.run do EventMachine.start_server("0.0.0.0", 10000, EchoServer) end 这个简单的示例注册了 EchoServer,并启动了 EventMachine。代码看起来非常简单,不愧是优雅的...

  • Sample Page

    Text can be bold, italic, strikethrough or keyword. Link to another page. There should be whitespace between paragraphs. There should be whitespace between paragraphs. We recommend including a README, or a file with information about your project. Header 1 This is a normal paragraph following a header. GitHub is a...

  • One More Sample Page

    Text can be bold, italic, strikethrough or keyword. Link to another page. There should be whitespace between paragraphs. There should be whitespace between paragraphs. We recommend including a README, or a file with information about your project. Header 1 This is a normal paragraph following a header. GitHub is a...

  • Another Sample Page

    Text can be bold, italic, strikethrough or keyword. Link to another page. There should be whitespace between paragraphs. There should be whitespace between paragraphs. We recommend including a README, or a file with information about your project. Header 1 This is a normal paragraph following a header. GitHub is a...

  • The Pragmatic Programmer 的两点感悟

    没想到 The Pragmatic Programmer 被翻译成了《程序员修炼之道》,副标题是“从小工到专家”,要不是原书强大的实力和名声估计很少会有人买中文版吧。 此书中印象最深的是对思考(书中 Think 魔咒)所举的例子: 一般程序员在开会时会想,这太浪费时间了!开会时间用来写代码可以提升很多效率。 而两位作者在想 为什么会有这个会议? 可否避免或更高效的完成会议? 两位作者在思考工作本身,他们在对工作编程! 这个例子很好的展示了两位作者几十年从业中坚持思考,把思考变为习惯(Think 魔咒),通过思考对工作与生活不断改善,使他们的思维和工作都达到了新的境界。 作为程序员不要局限于对计算机编程。把编程时用到的分析、设计、预估、架构 等能力应用到其他事物,对生活与工作编程,才能扩展新的境界。 其次在书中收获到的是一句话: 习惯和获得的结果同样重要 一是说明习惯的重要性,二是说明培养习惯的困难 以此两条感悟共勉

  • 如何用微服务制造问题

    如何使用微服务制造问题 微服务成本 理想的微服务平台 声称使用微服务架构的公司越来越多,一方面是云服务商的炒作,另一方面也的确是微服务带来好处的影响。 无论如何理解,在 twitter 上可以看到越来越多的程序员在吐槽微服务.. 一方面,理论上微服务通过大事化小分而治之,可以解决开发周期长,旧项目难以维护等一系列问题,看起来非常万能。 另一方面很多人忽略了微服务的隐含成本,在实际实施后反而感觉处处不便。 实行微服务所需要的额外工作大致如下几类: 部署困难:需要搭建如 K8s, CloudFoundry 等应用平台来解决 测试困难:需要搭建 Jenkins 等 CI 工具来完成单元测试/集成测试 运维困难:需要在应用平台上搭建监控和告警服务 Debug 困难:需要搭建日志服务接入平台,需要接入调用链分析工具 代码维护:微服务化后可能有些服务长期无人修改,对每个服务都需要建立良好的文档 可以看到,实行微服务需要优秀的运维团队支撑起应用平台(k8s)、监控告警工具、CI 服务、日志/调用链服务。需要开发团队做好文档化、自动化测试。 这些工作在单一应用架构时经常会被忽略掉,但是微服务中如果没有这些工具 debug、运维 等工作会非常痛苦,会浪费掉团队大量时间。 所以微服务的先决条件是团队需要拿出精力来维护以上基础服务。 很多小团队选择使用微服务架构,但后果往往是花费大量额外精力去支撑平台,或在基础服务不完善的情况下浪费大量时间 debug,实在不是一个好的选择。而大公司实行微服务带来的好处则相当明显,因为人数众多,维护平台的消耗几乎可以忽略不计。 有野心的公有云服务商应该将自身作为所有中小企业的微服务平台,提供微服务架构的所有基础服务,大量降低使用微服务的成本。这样微服务才会成为真正通用的架构模式。 从功能上来说 AWS(国外的那个..) 最接近理想形态。已经真正的可以让中小企业完全基于 AWS 基础服务来设计自己的后台架构。而其他服务商还多以 VPS + 数据库的形态出现。 如果以支撑微服务架构为目标的话,AWS 为首的公有云还都有一定的距离。 不知未来哪一家有野心的厂商可以提供真正实用的微服务公有平台。

  • 算法惨不忍睹-背包

    看了道 leetcode 题目 https://leetcode.com/problems/ones-and-zeroes/description/ 这其实是一道背包问题,使用背包的状态转移方程可以简单解决 轻轻松松试了下手,果断翻车了… 我发现并不是题目难,而是我一直没能真正理解背包算法为何会这样来设计? 每次看到解答都会感觉反直觉,无法将直觉思路联系到这种解法,而网上的解题过程也大多由结果出发,没有掌握到 why 看题目时我的直觉是对每一个字符串判断需不需要,然后利用递归计算,算法如下。 def find_max_form(strs, m, n) str = strs.first # 当前字符串 strs = strs[1..-1] # 剩余部分 m1 = str&.count('0') n1 = str&.count('1') if str.nil? 0 elsif m1 > m || n1 > n # 放弃不满足条件的当前字符串 find_max_form(strs, m, n) else # 选择构成当前的字符串时的数量 find_max_form(strs,...

  • CSRF 矛与盾

    CSRF(跨站请求伪造:Cross-site request forgery) 可谓老生长谈的话题,有无数的博客和文章都在讲 CSRF 攻击与防范。 近日感觉自己知识点之间存在着裂缝,无法做到了如指掌。于是弥补了下知识裂缝,并写成文章,贡献了 yet another CSRF 博文.. 摘要 CSRF 实践 POST 比 GET 安全? 为什么还要 CSRF protect token? 前后端分离和 CORS CSRF 实践 顾名思义,一句话概括跨站请求伪造(CSRF)就是:在用户浏览 A 站(恶意网站)时,伪造用户向 B 站(正常网站)发起请求。 我们用 ruby sinatra 简单的模拟下这个过程,从而更好的理解这种攻击手段。 用 a.rb, b.rb 两个脚本来模拟 A, B 站点,并修改 /etc/hosts 为两个站点提供不同的域名。 如果不明白可以先略过这两个脚本,之后回来再看。 # a.rb # testa:4000 #...

  • 细节与关键点

    查理芒格(《穷查理宝典》)多次提到微观经济学的重要性,重视多个“微观”因素引起的现象,印象比较深的例子是如何创造高回报率的“可口可乐”公司。 无独有偶,最近读过的很多书籍同样强调“微观”的重要性。讲述 Salesforce 故事的《云攻略》中也有着类似表达, Salesforce 很重视在设计中吸取用户的意见,但最初没有捕捉监控用户操作产品的系统,于是 Salesforce 会定期直接访问客户询问对产品的意见, 虽然只是从部分客户得到的反馈,但取得了非常好的效果。 第三本促使我反复想到微观效应的书是《特朗普传:The art of the deal》, 特朗普在工程和交易中做到细致入微,做生意前一定会对购买的地产足够了解,并且事先预估风险和盈利, 在工程实践中则是足够了解细节,做到把控工程所有环节一致赢得了按期完成的良好声誉。 这三个人都做到了坚持重视“微观”的思想,并且在成就某件事时极力促成多种“微观效应”共同发挥作用(这点芒格在书中极力强调其威力)。 虽然牛人的机会和财富不可复制,但是做事模式是可以借鉴的, 如此成功的三人都重视相同的模式,那么这种模式务必对其他人也有帮助,这也是我妄图通过总结来加深印象,最终融入到自己的行为模式的原因。 不过“微观”看起来粗糙偏颇,但的确可以起到不错的效果,至少在用户访问上尝试了一下的确得到得到很多宝贵意见,而在原计划中我们妄图通过完整的用户数据对着电脑和数据库分析出这种意见,现在想来是既低效又反人性的方式。 而通过和用户交谈了解了用户的核心担忧和预期,通过服务和产品来满足每个人的欲望,并且努力把这种服务推广到所有客户,从“微观”上看不会有人拒绝优秀的服务,既然如此必然具有推广到更多人身上的可行性。 往往看起来复杂的事情只要抓住几点细节的关键就可以很好的控制,我认为这也是查理芒格的“多种效应的共同效应”的另一种表达,正如特朗普谈生意会习惯性的给对手压力,并在与银行、卖家、媒体交流时注重细节保证每个关键点的万无一失,在极其细节的地方也会选择更好的方式和心理暗示来施加压力,保证自己的尽可能成功。正是这种做法导致找不出特朗普会失败的理由和可能性。 每当做一件事情时务必要立刻找出关键点,分析原因,并努力推进促使事情的成功。 通过对这三人故事的阅读,也可以看出他们都有着街头智慧,可以迅速的凭借自己的经验和知识找到关键点,直觉般的找出原因,并用异想天开的方法去解决问题(读一读 Marc 推广产品和 Trump 谈生意的故事,可以感觉到他们真的很了解人和社会的规律)。 想要一下子做到和这些成功人士一样或许有些天真,现实和成功学的学会“成功人士的十个小习惯”有着巨大鸿沟,但是多思考下别人的做事方式和成功过程或多或少对我们有着作用,对他们的了解与尊重促使我们不是停留在惧怕、疑惑、混乱的情绪,而是直接去面对去思考要做的事情,并且足够的了解深入,以致开始影响事情、掌控事情走向。 共勉