[email protected]:~$

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

    Tags: Ruby IO

    说到脚本语言与高性能, 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。代码看起来非常简单,不愧是优雅的...

  • The Pragmatic Programmer 的两点感悟

    Tags: 读书

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

  • 如何用微服务制造问题

    Tags: 微服务

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

  • 算法惨不忍睹-背包

    Tags: 算法

    看了道 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 矛与盾

    Tags: 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 #...

  • 细节与关键点

    Tags: 想法

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

  • 复利和杠杆率和scalable

    Tags: 想法

    “High output management”(《格鲁夫给经理人的第一课》)中一直提到要多做“高杠杆率”的工作,虽然从书中收获颇多,但之前一直没能理解如何判断哪个工作是“高杠杆率”? 直到看了一篇写 Growth Hacker 的文章,其中描述最重要的任务就是不断试错来寻找 scalable 的增长方式,然后对这种方式大笔投入就可获得数量成长。 最近重读格鲁夫著作,终于理解杠杆率和 Growth Hacker 的 “scalable” 一脉相承。 格鲁夫不断强调招聘、培训和激励的重要性。 拿招聘来打个比方,经理最重要的任务是招聘更优秀的人才,因为更优秀的人才才会带给公司价值,并且优秀的人才和更有价值的公司才可招聘到更加优秀的人。(最近看了 Valve 的员工手册也是同样强调招聘最重要)。 理想中这种正循环对公司带来的价值是一条指数增长曲线,正如眼熟的 Saas 产品用户增长曲线。 今天在《穷查理宝典》第三次看到了“杠杆率”,理解复利的魔力和获得它的困难是理解许多事情的核心和灵魂,正如格鲁夫使用“杠杆率”来管理公司,芒格使用“复利”来获取财富。 通过不断的阅读和整理渐渐的获取了知识,积累了本篇的三个知识片段后“复利模式”或许就会在我思维中生根,锻炼以“复利模式”来思考事物在寻找“复利”获取爆发的过程中也在不断增加模式本身的成熟度。(这个过程本身又是不断的复利模式..) 这种模式可以套在很多事物上,比如前一阵报名健身,没有练习多久就因为加班疲劳等因素拖延,于是身体状况没有改变。但是当时坚持下去的人因为持续的锻炼会刺激其体内雄性激素分泌,反过来激素也会刺激肌肉使锻炼的过程更加顺利。“只要坚持下去就好!”,这句话就算是“复利模式”的低配版表达吧 了解这种模式还是很有作用的,或许对它的深信可以让我坚持健身成功,可以在工作中取得更好的结果,也可以在学习中获得不断深邃的知识与思考。或许这就是成功人士之所以成功的秘密呢? 理解复利的魔力和获得它的困难是理解许多事情的核心和灵魂 共勉

  • 2017 知识分享与人工智能

    Tags: 想法

    以人整合知识 互联网上信息的获取可以以专业性和聚合性两个维度衡量。Coursera 与 微博 正好代表两个端点。 Coursera 代表了知识的专业性与高度整合性。微博代表了知识的非专业性与碎片化。 两种平台分别位于知识获取的顶端与底端。Coursera的专项课程推出与微博的营销号泛滥更加的印证了这一点。 现今的人工智能、区块链、共享经济等新热点。已经非常的专业化,难以用碎片化的信息填补。 大家越来越发现看了十几篇的公众号仍然无法理解区块链的原理与前景。面对着热点与本身知识的断层给人们带来了内心不断的焦虑感,解决或利用这种焦虑感是知识创业者们的重点目标。 互联网知识创业者看到了这之间的断层,并不断的尝试填补、拉近、融合两者。 以大V为载体,通过知识分享来解决碎片化与知识获取门槛过高的问题。 各种碎片化的知识会不断的整合与重组,我们将会得到大量带有“个人看法”的信息。 知识的传递方式将再次螺旋式上升,不在是以主题类别碎片化的分散,而是以人为核心将知识聚集,经过精心加工,以古老的口口相传形式在互联网上传递。 知识的传递将更加贴近现实中的样子。 基于个人的知识分享使得知识不再像wiki上那样保持中立,同时也附加了一个新的纬度。 当我们追逐一个热点时同时也希望得到别人的看法,所以我们写书评,和朋友分享电影。我们需要知晓不同的观点,同时也在寻求着共鸣。 带有个人看法的信息会把人与人的交互、信任、交流模式带入互联网世界!这才是真正创新点! 以人为中心来整合信息看起来是对“人工”智能的讽刺,理想的情况如科幻电影中人工智能高度的整合、处理信息,并像人与人交谈一样来进行IO。 目前的人 + 互动形式正是人的需求超越了技术的发展所催生的中间形态。 经过互联网信息的轰炸,人们认识到需要处理过、过滤过的信息,科技却尚未跟的上脚步。 乐观来看个人化知识共享的发展既是作为人工智能处理知识时模仿的对象,也是为AI提供了新的整合过的知识库。 对大量个人知识讲座与互动问答的标签化,以目前的AI技术应当也可以把这些做为检索结果,并在个人之上再次的以主题来整合,减少了我们获取整体化信息的成本。 当科技更进一步时,AI以这些信息为中心来学习、搜索。未来将由AI来做为我们的主讲人与互动对象.. 人工智能取代搜索引擎 搜索引擎已经落后,我们需要是输入“共享经济”便可以查看到我需要的信息,而不是粗糙的 page rank。 在 2016 年搜索共享经济居然得到的还是一堆网页,还是需要手工去寻找。 若我是一个中国的企业家或投资人,做为新科技代表的搜索引擎无法告诉我魔拜与ofo的融资情况与占有率。需要我手动取过滤虚假信息,从一个个网页中挑选信息。 这种效率让人深感对科技进步的绝望。 人人共享知识的时代应该使得我们可以获得带有“个人看法”的知识,从多个维度获取信息。 拿区块链举例,我可以问 Siri 给我介绍一下区块链。 而我得到的不应是一堆网页,Siri应当先向我展示简介,进一步的将各“知识平台”的优秀回答告知我(比如人性化的挑选我认识的某大V的优秀回答,基于个人关系我可以根据其性格判断如何解读信息), 则我获取到的也不仅仅是冷冰冰的wiki,而是带有“个人化看法”的信息, 进一步我可以让Siri帮我订阅Coursera上的专业课程,或是持续追踪这个热点,也可以询问“知识平台”上的大V或咨询师的看法。 未来的信息需要一个统一的集成搜索接口,需要高度的整合与处理,目前看来人工智能助手是最理想的入口。 基于人工智能助手的入口,与各大“知识平台”采用订阅付费获取信息的形式来集合,看起来是比较可行的方式。 希望未来会有伟大的产品来取代 google search 技术帮助人专注于创新 打开今天的搜索引擎,我得到的是一大堆网页与广告,带来是分心而不是专注。 未来应当更加趋向于基于语音交互,这样可以大大的减少分心与输入成本。...

  • 从《失控》中进化的scrum方法论

    Tags: 想法

    智能系统大致可以理解为 输入 -> 处理 -> 评估改进 -> 输出 这样流程的重复迭代 这里的系统可以指一个人或团队,公司,以较为熟悉的IT业作为比方。 对产品的管理需要不断的接收用户反馈,调整产品定位与体验,并且持续改进,再次的输入给用户。 对于项目开发,以scrum为例,在每次sprint(迭代周期)都会进行评估改善, 并且按需调整下一次的输入(sprint目标),而scrum的理论则可以陈述为提升迭代速度从而提升整个系统的反应与灵活性。 简单而言可以把这种流程套入到任何的工作方式(和scrum不谋而合,或许只是相同概念的另一种陈述),所有的智能系统都有相同的工作方式。 在阅读过一些scrum概念后,联想到了《失控》中的“分布”概念,二者实在是有很多异曲同工之处。 在我理解的scrum是把不同的team(为了陈述方便全以开发为例)作为一个自组织的智能系统, 并且在单个系统进行这种迭代时鼓励不同team开发者互相交流, 外部的参与使得单一系统输入和评估的部分得到了增强(更为可观,多样化), 并且在一个大的组织内部,这种互相交流的模式也很大的提升了系统输出的利用率(可以作为另外系统的输入)。 甚至可以采用更佳灵活的方式,管理者可以组织各种虚拟团队来解决特定问题, 通过划分出更多的“独立”系统,每个小型系统可以更快的改变/迭代, 而通过人员交流和重组(重组成另外的虚拟团队)使得交换信息更佳畅通,把经验和技术(甚至迭代本身的改进)的价值变得最大化。 跨team的虚拟团队与重组看似混乱,但小的团队往往容易维护,易于沟通,分工明确,并且更好的达成改进的共识。 还有一个好处正是敏捷原则所鼓励的团队成员需多交流, 在不同的虚拟团队,大家通过跨团队的重组来吸收经验。 同时因为虚拟团队的时效性,与现在的团员交流也有助于以后的跨虚拟团队交流。

  • 从 PM 到 PM

    Tags: 想法

    打开这份四年前开始的博客,回忆起了在不安与浮躁中追求着上进的自己。 几年过去内心已经成长了不少,周末不会因担心未来守在电脑旁疯狂的学习,逐渐的摆脱迷茫认清对自己重要的事,了解了社会组织的运作方式从而知道如何参与其中。 人的成长是螺旋式的,在迷茫和坚定之间来回摇摆。 可能现在看来成熟的思考在明天就会被新的认知打破,而在迷茫中的一点点积累却又是形成坚定意志的原料。 这种成长方式使得我们在迷茫时变得不再恐慌,在坚定时也会不断的审视自己。 之前的一个月因为自认对产品的洞察力而主动请缨 Product Manager 的位置。 一是认为公司的成长过程中的确到了需要这样一个角色的时候, 二是认为自己有胜任的能力, 三则是总干一样的工作有些厌倦 想要换个角色体验下。 刚开始的工作的确很顺利,之前欠缺的 Road Map, Product Plan, Product Design 进展的非常好,而且也受到大家认同。 在愉快的新工作中我却感觉被渐渐的拖入泥潭 我发现了在之前位置没有发现的事情 团队的执行能力不足! 每日疲于应对客服与企业需求,无法做到对于功能的改进与新产品的投入 这种情况令我非常苦恼,大家聚在一起讨论未来远景时总是信心满满 迸发无数的idea 但是在执行时却有严重的问题, 大量的工作由手动完成,程序没有健全的自动化监控和纠错 导致在本可自动化的事情上投入大量人工 阻碍了开发效率 这使我认清了一个事实,无伦设想或潜力有多好,现实的执行才是最重要的! 现在已经有了 Road Map,我需要转交用户反馈收集,文档撰写,可用性测试等 Product Manager 的周期性工作 投入全身心在 Project Manager 角色上工作,毕竟吹牛很容易,做出实事的人却很少(这让我理解了 idea 不重要那句话!)。 对于技术型公司,相比产品周期性调查,对开发团队能力的提升和对开发架构的改进更为重要,技术与创新上的领先才是技术型公司的优势。 拿起了以前不屑的 敏捷 与 Scrum 的书籍,认识到了团队和个人作战的巨大差异,理解了团队管理与运作的理论。羞愧于经常讲段子嘲笑敏捷开发...