时速云老是断,把网站搬到香港搬瓦工。

最近一段时间每天都能收到监控宝关于时速云的大量警告,也不知道是为什么,到底是误报还是时速云的问题。正巧也需要一台服务器跑点程序,弄了台香港搬瓦工,感受感受,目前来看很棒,用docker管理服务真的很惬意。…

让我们给业务做减法,给代码做减法。

最重要的写在开头:道术合一,知行合一 现在是讯息爆炸的时代,搜索引擎降低了学习的门槛,凡是都能从百度谷歌了解个一二。正因为这随手就来的一二,带来了想要的“结果”,让大家只掌握了术,但忽视了道。我认为“道术合一,知行合一”,术是千变万化的,但是道确实永远的,做减法就是我自己的代码之道。 可怕的观点:执行效率是第一 我经常听到一种观点,代码需要的是更快的执行效率。以及由这个观点产生的衍生观点,例如:设计模式并不重要等等,因为我们可以绕过框架或者现有的方法,用更“原生”的方式实现一样的结果,这样会运行的“更快”。这是一个可怕的观点,可怕就可怕在看上去没错。软件行业发展到现在已相当成熟,我们绝不能用单一指标衡量代码,如同我们不能用百公里加速来衡量一个车,如果这样想,无疑要选比亚迪,实际情况真的是这样么? 代码是一种业务的体现:全方位的评估才合理 代码是一种业务能力的体现,举个例子:小轿车是个人出行业务的体现,全方位评估软件工程带来的结果才更合理。尤其在国内,人天的成本大幅度的提高,技术团队每天的开支相比其他传统行业近乎天文数字,我们对于迭代周期要求非常的高,单个sprint产出的价值太重要,甚至于正版软件相较于人力成本也已经变得是一个合理的支出范围。…

最近互联网周边的体验

今天订阅号直奔主题,简单的说说一些周边体验,可能有些与实际已经不符,而且也仅仅是一家之言,如有冒犯请见谅。 开头题外话多说一句,为什么要用周边,我觉得艺术圈给我带来最大的理解之一就是艺术品的市场价值和艺术价值是不挂钩的,同理也适用在软件行业,代码的商业价值和技术价值是不挂钩的。切莫局限在技术的片面表现中,越走越细,举个例子,当你把关系型数据库看成一个服务的时候,不仅仅是简单的提供sql运行能力,还要有分布式,要有冷备份热备份,还有高可用,要有健康程度监控,要有审计,等等,当你完成了这整个服务方案的时候你发现你的业务还没开始。再举个例子,如果没有七牛这样的周边,可能一些图片APP团队还在自建分布式文件系统中,沉没在fastdfs的泥潭中。我们要最快的整合周边,把商业价值放大,这样才有闲置资源放大技术价值。 再中间插一句,很多很多小伙伴和好朋友问我现在去了哪里,借订阅号宝地说一句。老夫已经把天赋带到了空艺术,一个艺术平台。贯穿艺术领域各垂直和横向、国内和国际产业链,整合线上和线下资源,打破艺术领域与资本和非专业化消费受众壁垒间迅速发挥领军作用。(妈蛋,这个介绍是复制的,不是我写的。) 容器和持续集成篇 Daocloud:国内容器团队,他提供了一套容器管理面板和完整的CI功能,可以完成代码上传后的自动触发构建,测试,部署,监控。生产环境容器必须部署在自己的云上,…

想要成为PHP高手的十个建议

勇哥对我说,我写的都是道,但是大部分人需要的是术。我恍然大悟,想想这有道理,道理虽然是根本,但是术还是要有的。特别推出一针灵系列,顺手弄个耸动标题吸点粉,请轻喷。 PHP使用简单,上手特别的快,这导致使用者水平参差不齐。而且因为诞生时间太久,有很多冗余的东西,缺点堆堆的,这里不展开。有太多技巧可以提高水平,今天先说十个,有些可能非常颠覆你的想法,但请听听我的看法。 1。熟练使用SPL,这是基础 PHP本身是一门工具,SPL是工具中的工具。SPL的使用会大大简化你的设计,我发现N多程序员无法回答和SPL相关的问题,这是致命的。例如:SplSubject接口可以轻松帮助你做出一个观察者设计模式,SPL系列迭代器满足99%的使用场景,虽然你可能不写自动加载,但是spl_autoload干嘛的总要知道吧。 2。参数需要注入,不要和环境发生依赖关系 你写的代码承载的是你的业务,业务是可以工作在CGI或者CLI下的。看到太多的Sample中控制器会直接使用$_GET,$_POST之类的环境变量,这是致命的。如果你的模型层也有直接获得GPC,恭喜你,重构已经提上议事日程,因为你的业务根本无法再CLI下执行,请把环境变量和业务参数的绑定设计成注入的关系。…

编程感悟系列:本地方法和远程方法与可见性问题

数据库一不小心说了四节,自己觉得有点枯燥,那就开一个新系列讲关于编程感悟吧(多一个一级菜单真是一个不错的选择啊)。 我总是建议年轻的程序员(虽然我也很年轻)应该把项目复杂化,尝试各种手段让自己的项目充满过度设计的感觉。然后静下心来做‍减法,当你会用减法并且理解其中奥秘的时候,才能学到编程的精髓,才能学会用编程的方式思考问题! 而且你会惊讶的发现,解决问题的过程实在是令人着迷,倘若你的工作只是完成需求,那么根据契约精神你只能收获的是工资。罗伯特清崎在《穷爸爸和富爸爸》里写到,“老板发你的工资是保证你不会离职的下限”。我的理解是,在工作中不应该只获得工资,更多的是学习知识! 说到减法,举一个不恰当的例子,暴雪的最新游戏《守望先锋》就是一个做减法的典型,当国内游戏从业者一个劲的往产品叠加功能,例如:每日签到模块,抽奖模块等。《守望先锋》却大幅度精简系统,没有一丝的肉。是他没有能力做类似签到模块么?显然不是,是因为他的终极诉求是为了带来愉快,所以玩守望的每一分钟都没有被浪费的感觉。 为什么这次的题目是《本地方法和远程方法与可见性问题》呢?我发现问题都是连环相扣的,我要用代码可见性问题做引子,推出我的观点,代码本身就是最最好的注释。本地方法就是本地文件夹定义的function,通过本地引用方式调用定义的方法,缺点是调用者和实现者必须相同语言,…

关系型数据库使用中的误区系列:不要把业务放进数据库

任何东西都不是多多益善,帕累托法则在生活中处处体现,关系型数据库就是一个典型的例子,你会发现80%的业务跑在20%的功能之上。显然,我和帕累托一样,不相信均匀分布在真实生活中体现。 以下摘录自Andy Warfield的《The 80/20 rule… for storage systems.》,“80/20 法则通常被认为是源于意大利经济学家维尔弗雷多·帕累托。帕累托出生于1848年,他是(至少被认为是)占领运动的早期成员之一。他发现意大利国家财富的80%是掌握在几乎少于20%的人口手中的。由此发散开来看,80/20法则在其他方面的应用同样值得注意,也是很有趣的:因为帕累托观察发现他的园子里的80%的豌豆产自于20%的作物上(他似乎更喜欢数豌豆而不是其他豆子)。" 很多程序员在做到某个阶段的时候都会来问我,要不要用触发器?要不要用存储过程?等等一系列类似的问题,你也会发现从搜索引擎可以找到很多文章在围绕这个话题展开分析,介绍各种各样的技术等等,但我想申明我的观点,在OLTP的系统设计中,请不要把你的业务逻辑以触发器和存储过程形式放到数据库中!OLTP只能保存关系,也许有些feature一时帮了你的忙,但是后患无穷。…

关系型数据库使用中的误区系列:业务字段展示字段傻傻分不清楚

松本行弘在《代码的未来》中领悟道,这世界上没有java编程,没有ruby编程,更没有php编程,其实这世界上只有编程这两个字呀! 好喜欢这句话,我觉得数据库编程也是一样的道理,虽然我们在谈数据库,更多的探讨是如何拥有编程的思维去处理这些问题。当碰到跨语言,跨平台的编程时,我们会称之为架构,但其实本质还不是在编程么?最后你会看到,人的架构永远大于软件架构,编程技巧只是人类处理真实世界问题在代码中的体现!这是我的感悟。 作为系列的第三篇,我们谈谈关系型数据库常见的问题,也是初创型公司不能高速发展乃至转型的羁绊,业务字段展示字段傻傻分不清楚! 先从一个简单的例子开始说起,我们总会设计各种各样的管理系统,例如酒店管理系统,里面管理着所有的业务实体,酒店实体自然是酒店业务在代码中的映射。我们常常会接到一个类似的需求,需要为菜单中包含宫保鸡丁的酒店标识为上海味道,前台可以基于这个标识筛选出符合期望的酒店。 很糟糕,这是一个标准的死亡陷阱,程序员先做了第一件事情,为酒店增加了一个属性叫做上海味道,对应的关系表也多一个字段。第二件事,必然的会修改所有可以触发该字段变更的地方加入新逻辑,若这是一个复杂的系统,必然痛苦不已。 所有初创公司的研发团队都消耗在了一些无用的事情之上,很快产生边际效应,他们已经无法应付真正的新品类拓展,光是打补丁便已经停不下来。那么到底是哪里错了呢? 我要否定的就是这两件事,它们是不对的,首先第一点,我想先解释一个问题,什么是业务?…

关系型数据库使用中的误区系列:数据的价值

数据库这东西说起来真是一发不可收拾,其实本来只想写一篇文章总结,未曾想到写完第一节就超长了,也好,直接上一个系列吧! 正如前文所说ANSI SQL真是一种功能性极强的DSL,如同打架必备的折椅,睡觉需要的床,踢球要的足球一样,我认为他是当下最适合通过描述过程筛选数据的语言,但注意我说的是过程!例如:我要筛选库存红色的苹果,筛选价格从高到低的订单且只要100条,诸如此类。 但我们也常在反思对于过程的精确描述究竟是为了什么?这个查询的背后初衷是什么?我的观点是,我们描述了那么多的过程不就是为了得到预期的结果吗?我们为什么不能直接描述结果,让把其他的事情交给计算机来做呢? 每个小伙子在追GF的过程中包含了吃饭,看电影,打LOL等等过程,所有的这些,都是为了让对方成为你的女朋友这一结果,而且常常为了达到结果你会动态调整你的过程,痛并快乐着。万幸的是,在计算机的世界里不用大费周章,你没有痛,只要你能将结果准确的描述出来,那么程序便会为你实现结果。 试想一下,描述一句“我需要一个吃素菜的便宜的,而且我邀请朋友都喜欢的饭店”,计算机呈现的结果便会是你需要的那样,那岂不是更好。真心希望各位读者读到此处,从DSL角度,过程描述和结果描述角度,能带来你一点对于编程思想的畅想,我们频繁的使用SQL编程到底是为了什么?有没有可以让计算机学习之后,告诉我结果的技术呢?请带着想法关注本系列,关注budaoxing这个订阅号。 《关系型数据库使用中的误区系列:…

关系型数据库使用中的误区系列:最大误区

开了订阅号,看到序言的PV数往上跳过了自己的期望值,尤其看到订阅者中男女比例已经达到二比一时,小小的脸红之余有了一点小小的膨胀。SO笔耕不能停!虚心接受大家意见,调整了下段落布局,希望大家喜欢。 这次,我们来简单说说关系型数据库,我喜欢使用大量的引用和比喻来阐述观点,文章会很碎同时也会比较发散,希望能为以后和之前的文章承上启下。最后我也深信一点,能够百度到的“知识”不是“知识",所以我不是百度的搬运工。 写SQL肯定是一种编程,准确的说是DSL(领域特定语言)编程,ruby之父松本行弘在《代码的未来》一书中用了大量的文字描述这个话题,非常引起我的共鸣,因为我常反思未来是否在业务描述中会有一种DSL可以描述特定业务,那会有多动态,有多抽象,或者这是唯一正确的道路?我想在本文埋下一个伏笔,让大家牵挂着这个问题!这里我最想说的是,主流IT媒体有这样一种观点,“21世纪人人都要学会编程”,我很赞同,但我要补充的说,“21世纪人人都要学会领域特定语言编程”,而不是人人都在写JAVA。 关系型数据库RDBMS的使用往往陷入“误区”,我仔细分析了下,最大的误区在于场景选择!!你需要的是OLTP还是OLAP,这个误区在当下弥漫,99%的中国互联网企业做的架构有问题,那原因是什么呢?…

写在订阅号开篇

还有半个月,入职到喜啦就满3年,到喜啦让我学习到很多,为做一个纪念,老夫决定开个订阅号把自己工作中的感悟分享下,主要涉及代码设计模式,大数据处理,业务设计,软件工程,运维测试自动化,带团队笔记。把已分享的和还未分享的碎片整理下,系统的写出来,顺便给自己一个时间的总结。 如同每次做培训之前说的一样,我的文字是我的思想,是我的感悟,请亲手试过觉得好再转变成自己的想法!张鸣先生的《重读中国近代史读》的序中有这样一段,大意是A和B介绍A的思想,B并不认同,但在某些场合,B却会用A的思想去反驳C,因为B没有自己的思想,这是最要不得的!现在的IT行业有一个怪现象,喜欢聚众,好似人多力量大,一会一个座谈会,一会一个分享课,嘉宾各个抬头多多,浮躁的气氛仿佛看到了民间科学爱好者只凭胡思乱想和刷脸来处理问题,严肃的仪式化的东西只是外在,我们需要的是探究本质,请务必不要拿来主义,和碎片化学习! 首先,我认为这世界所有东西都是相通的,软件工程亦是如此,我时常举一个例子给想进入互联网的传统老板来解释为什么现在单个软件项目的造价是如此昂贵,而非想象中一个网站找个大学生几千块就能搞定。我用美食做例子,作为一个饕餮爱好者,中国的美食博大精深,好比我爱的全聚德,那好味道我不想再描述,但其本质是很难复制的,你无法在一夜之间开一百家全聚德,…