[email protected]:~$

  • 复利和杠杆率和scalable

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

  • gtd

    习惯通过“框架”(framework)管理自己的行为,才能更高效的处理事务。 过年期间读了《Getting things done》,第一次感到方法论带来的实用性。 写了几年代码,深知使用框架来实现工程的便捷性,省了下走弯路的时间提升工作效率,更重要的是了解目前的最佳实践思维避免被误导。 但脱离开编程领域,在日常行为中却一直没有意识到框架的重要性,虽然听过“番茄工作法”等框架,但营销者通常将其和成功学绑定,看起来很让人反感,当然也不会去实践。 阅读《GTD》后深深的信服于书中理论与详尽的设计,通过合理的工具和大约3周的实践,我确信“GTD(Getting things done)”工作法的确帮助我管理了日常/工作的事务。 原本杂乱的事情通过“GTD”流程被结构化的组织为一个体系,而且基于对Trello(我用来实践GTD的工具)的信任我可以确信数据不会丢失。 正如书中所述接受了这种工作法可以获得平静感,事情虽然还在,但是已经变成了可被管理的状态,等你打算开始工作时只需按照“GTD”流程运转你的大脑去执行下一条指令。 让大脑重回CPU的地位,事务则交给数据库来存储。 关于“GTD”的实践方式和原理在书中都有相近介绍,非常推荐面临一大堆事情感觉烦躁的人去看一看。

  • 2017 知识分享与人工智能

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

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

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

  • 从 PM 到 PM

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

  • 用社区公认最佳工具链完成python测试

    一名有经验的开发者应该明白测试的重要性。 当产品经理提出一个个新需求,老板一遍遍的催促着提高效率。 在欣赏凌晨四点美丽的夜景隔日,拖着疲惫的身心晃到公司门口,伴随着咖啡的振奋告诉自己今天也要努力工作,此时传来的一声 “怎么又出BUG了!!XXX过来看一下”,我相信着对于任何一个程序员都是崩溃的,尤其是当实现新功能时,正享受着解决者一个又一个问题的膨胀感,却突然被打断,面对着项目经理头顶的反光惭愧的低下头,今天剩下的时间很有可能就要花在修复bug上,更恐怖的是修复又带来新的bug,新功能怎么办?加班,于是又开始重复着日复一日的轮回.. 残酷的资产阶级不会体谅程序员的艰辛,只会一遍遍的榨压和责怪,身为弱势群体,我们唯有自己保护自己,而测试就是保护我们不受打断的工具! 笔者最近使用python,因为没能找到关于python测试较好的简介,我选择了几个github上的明星项目来学习它们的测试实践,对于所用的工具链,结果惊人的一致 pytest pytest 是一个兼容 unittest 和 nosetest 的测试框架,结果输出非常友好 在 assert a == b 语句中如果测试失败会在结果中打印 a 和 b 的值,并会标注字符串中哪些字符不同,列表中的第几项错误等等.. 并且提供了 fixture 等测试必备功能 https://github.com/pytest-dev/pytest pytest本身的测试非常完善,可以参考该项目的各种配置及测试方法 tox tox 是个为 python 准备不同运行环境的工具,通过不同配置可以使用不同的版本解释器来执行代码,很多项目利用 tox 和 travic-ci 来测试对不同版本 python 的支持 最佳实践请见 pytest https://testrun.org/tox/latest/ 笔者最近在开发一个自动生成测试的工具也是使用了上述两个库,测试虽然表面上花费了时间,但长远看是非常必要的,无论是对程序稳定性的保证,还是对未来重构工作的铺垫,有着完善的测试都是非常有利的 但如果某些程序员实在懒到了一行测试都不写,也是有解决方法的(毕竟程序员最讨厌的就是写测试和文档,其次讨厌别人不写测试不写文档) zerotest 推荐下前几日我做的测试工具 zerotest 这是个懒人用的 API 集成测试生成工具,如果适合您的需求的话欢迎使用(也很欢迎提issue)...

  • G的悲剧

    到公司后就被同事抓到,表示交付的软件有bug。我第一反应很惊讶,这不科学啊!昨天还是好的/在我机器上还是好的 ,怎么可能莫名奇妙的出现bug? 我考虑了下,前几天merge了下upstream,然后升级了开发环境,难道是merge的代码有问题?逐行对比下发现涉及到的代码没有任何merge,反复重试了几次还是有问题。因为这段代码会download到受限的客户端执行,所以很难debug。 这时想起了之前对开发环境做过快照,立刻恢复,重试。正常工作!再次把更新后的代码覆盖上,重试,出错! 已经能够重现错误!这就代表错误就在更新的代码中!对比了下代码….崩溃..没有变化… 没错..之前用到的代码根本没更新,代码是一样的..怎会出错? 没办法了..只能祭出法宝。 波若波若密!!恢复快照!! 这次是有备而来,apt-get install git 切换到项目目录, git init 覆盖更新的代码 没错!这次我打算用git来对比更新前后的代码,比肉眼靠谱得多,在这里我用了git的gui工具tig 用tig查看发现…代码看上去都一样!!但是git diff却显示不同.. 用cmp -b byte by byte试着比较了两个文件..发现换行符不同.. 结论就是windows下得换行符导致代码在受限客户端运行出错.. WTF!!?为什么之前的程序可以正常工作?我在windows下得开发环境没换过啊 这时看了眼sourceTree突然明白问题所在.. git有个autocrlf的选项,设置后git会把提交的代码的换行符从dos style转换为unix style所以之前的代码正常运行 但是我在更新代码时因为机器连不到git server,所以我在windows上直接打成tar包。这时造成打包的代码没有经过git,所以没有被转换,保留了\r\n的换行符,造成bug。 正确的做法是我应该找一台可以连接到git server的*nix机器,在上面clone 然后打包。 终于找到了bug原因,我眼角湿润,望着上海凌晨四点的街景(此处夸张!)感叹,老子这一天就被这么浪费了…. bug的原因因为git的crlf被掩盖,而我又用到了git来debug,真是成也git,败也git.. 遂效仿各大”悲剧”系列,以G的悲剧为题..

  • 通过Razor管理Virtual box虚拟机

    打算在mac上用虚拟机玩下云。之前工作中用到了Razor,于是萌生了用Razor来管理虚拟机的想法(顺便试验下最近很火的docker)。 为了让开发机尽量保持”干净”,决定用docker来做个razor-server的镜像(docker pull jjy0/razor 可以下载到) 制作镜像还算顺利,没想到在虚拟机的网络配置和IPXE boot上栽了跟头,记录在此引以为戒,同时期望能帮助到他人(没接触过PXE boot或Razor的朋友就此别过!) 用docker启动 razor-server非常简单 docker run -d -p 8080:8080 jjy0/razor start 在本地安装razor-clientgem install razor-client 已经完成了razor的安装! 接下来根据官方教程配置PXE boot VMware Fusion的坑 刚开始我使用的是Vmware Fusion,在一台虚拟机中设置好了razor和DHCP server,却无法被同网络其他机器探测到。 没能找到解决办法,之后使用Vmware自带的DHCP server redirect到razor,发现Vmware自导的dhcpd版本过低(2.x)不支持chain命令,只好作罢 Virtual Box的坑 转战到Virtual Box 我搜索了一番,发现已有前人尝试过比较简单的方法(把dhcp-server假设在host上)。决定使用这种方法 先按照上文链接中得做法建立host-only net 查看现有dhcp serverVBoxManage list dhcpservers 禁用相应网络的dhcp serverVBoxManage modify --netname HostInterfaceNetworking-vboxnet0 --disable 按链接中方法配置dhcp server...

  • 开发编辑器的过程中遇到的一些浏览器差异

    测试新编辑器时发现在firefox下会有很高几率出现一个神奇的bug。 当光标在block元素(blockquote, pre, etc..)中时,按‘下’或‘右’或‘回车’键后,光标会选中block元素中第一段文本。刚开始怀疑是在FF下rangy设置selection的bug,但在注释所有js中keydown的处理事件后,还是会有此bug。 之后百思不得其解,甚至想到用scribe重写编辑器… 在观察scribe的demo在FF下的表现后,终于找出了这个很愚蠢的bug… 在blockquote中我特地的把p标签转换成text + <br>,但实际上在html4中是要求blockquote等块状元素中需要存在p标签(这是来自stackoverflow的一个回答,我没有看html4标准..),所以我特地的去除p标签反而是画蛇添足之举。 在chrome, IE等浏览器下对于<blockquote>test<br></blockquote>这种html没有特殊限制,浏览器的默认行为完全可以正常工作。 但是在firefox下,当光标在test文本末端时,按下回车,本应换行,但是firefox会去寻找当前的p标签(这是html4规范,Firefox依赖了此规范,chrome等则没有),但是我错误的没有把文本放入p标签,所以造成浏览器默认行为出现bug。 正确的标签应该是<blockquote><p>test<br></p></blockquote>这样才符合html规范。 在开发编辑器的过程中,接触到了很多这种浏览器默认行为不一致的问题。 比如firefox下偶尔会对br标签加上type="_moz"的属性。 chrome和safari下拖拽block中元素浏览器会把拖拽的文本放入span并且自动添加很多style属性。 在webkit内核浏览器中block元素里按回车会在下一行自动添加同样的block元素,在FF中则是自动换行。 如果一行中有br,在IE下光标在br之后,其余的浏览器则是在br之前(偶然通过range对象观测到的,在block末尾时IE中的endoffset会多1) 浏览器的很多上层API加上跨平台库已经让人很少能感受到js编程的平台差异,但是在contenteditable中诸如此类html中并无规定的默认行为在不同浏览器上的表现却是千差万别。尤其是号称跨平台的selection库rangy实际上在不同平台上还是会有很多bug与不一致,举例来说最基本的获取range对象,在webkit浏览器上取得range,start和end会优先是textElement,但是在FF上则会得到ElementNode。 html规范毕竟不可能涵盖所有情况,各种标签的嵌套以及不同情况下用户的操作,这些规范之外的情况只能靠具体的实现来决定行为。 就像各种的markdown解析器,在规定之下会输出相同的结果,但若在规定之外,每个parser都会有些许的差别。 看来浏览器距离完美的平台还有不短的距离..

  • javascript学习笔记(二)

    1, 函数中this的四种情况 //1. 函数绑定到对象上时, this为对象 a = {func: function(){ console.log(this)}} a.func() // this是a //2. 没有绑定到对象时,this为全局对象 (function(){ console.log(this) })() //上面的this在浏览器中是window(全局对象) //3. 用new调用时this绑定到新构造的对象 //4. 函数对象的apply方法 (function(){console.log(this)}).apply("hello") //通过apply可以指定function的this值 2, 原型 //javaScript中的原型继承必须通过函数来完成 //function有一个很重要的prototype属性,默认值为{} (function(){}).prototype //=> Object {} //函数的prototype属性是javascript中原型的关键 //用new去调用function时,会以该函数的prototype为原型构建对象(常用此行为来模拟继承) a = {hello: function(){return "world"}} //现在来构建一个链接到a的对象,首先需要一个function A = function(){} A.prototype = a //用new调用A时会构建出以对象a为原型的对象 b =...