分类
偷窥人间

偷窥人间:东汉王朝的崩溃

写在最开头

记录成文且能被流传的历史往往充满很多矛盾的东西,因为矛盾部分可能是故事与真实历史的混合物。这会导致阅读理解过去发生某件事情的时候感觉异常,这种异常来自于人性,基于设身处地的换位思考。吕思勉说设身处地这东西,只有当事人才有,大意是当事人能看到八个方面,你可能只看到三个方面,有五个面不知道,故觉得奇怪。

所以揣摩历史的好处是,读一遍不够,一个角度不够,一本书不够。要把所有的资料综合在一起,抽丝剥茧以后才能豁然开朗。如悬疑小说一般,一次次的反转,终于明白以前看到那些不合理的行为背后符合人性的一面。

选择写东汉的原因

因为三国的原因,登场人物的认知度是中国历史之冠,资料多,群众基础Max。认知度一高,讨论起来更方便,然每个事都是有自己理解的,我也只代表自己的见解,仅此而已。

需要被复盘的故事

这次复盘的故事是汉灵帝驾崩到董卓拿下洛阳这几个月发生的故事,我们在多个版本获得对这段历史的描述都是非常类似的,以受众较广的央视新三国来说。它描述的是汉灵帝驾崩,朝廷被十常仕为首的宦官控制。大将军何进号召群雄进京勤王,结果被十常仕反杀,随后十常仕被袁绍干掉。此时洛阳打乱,勤王的董卓发现异动违抗命令进入洛阳,碰到了汉献帝,控制了皇帝。同时贿赂吕布杀害同来勤王的丁原,兼并丁原的并州军,最终袁绍,曹操等逃离洛阳开始反董,东汉崩溃,从此拉开三国序幕。

何进 VS 蹇硕,皇权对外戚

实际发生了什么事情呢?灵帝一死第一件大事便是小黄门蹇硕计划谋杀何进,但因为手下司马潘隐向何透露计划,失败的代价是何进出手干掉了蹇硕。**这里我做第一个大胆的假设,杀何进是灵帝死前就已经部署好的方案。**先介绍下蹇硕,他是灵帝的心腹,很多书把他写成十常仕的一员,他虽是宦官但和张让,赵忠并不是一伙的,是一个有专业能力的宦官,深得灵帝信任。灵帝很清楚外戚的威胁,远一点王莽导致西汉灭亡不说,外戚窦武和陈蕃的兵变也没过去很久,外戚是权力交接时的不安定因素。

灵帝立了王美人的儿子刘辩做太子,其实就清楚在未来刘辩和刘协必有一争。近的来说,大将军何进还活着,是刘协的舅舅,何皇后的哥哥,身居国防部长要职,朝中向着何进的人不少。往远处说,刘辩长大了还是要干何家人的,因为自己老妈王美人就是被刘协老妈何皇后下毒杀死的。

所以从灵帝视角看上去,何进都得死,那为什么不早点死呢?西园八校尉的设立就是借农民军起义,武装了首都高门士族子弟用来对抗外戚大将军何进的一步棋,蹇硕作为西园军的首领,直接握有兵力,在首都比名义上国防部长的何进战力更高。这里介绍一个新的登场人物,灵帝老妈,董太后,他有个侄子叫董重也手握兵权。所以这里我粗略定义一个皇权派,董太后集团,宦官蹇硕的西园军,十常仕手里的部分宫内战斗力,而在另外一边就是何家外戚。为什么说粗略的分呢?因为每个人都心怀鬼胎。

灵帝想的很简单高效,我活着大家别闹,我死了之后,蹇硕你第一时间去把何家全部杀光了,刘辩当了皇帝,老妈董太后监国,兵权一部分交给董重一部分给蹇硕,宦官继续擦屁股干脏活累活对抗文官,这一切都很完美。可惜的是,皇权派严重低估了何进,最后导致送命。何进对整个政治环境的渗透,远远超过灵帝想象,很多人都表面上听刘家的其实是听何家的,于是乎,蹇硕被何进反杀。在这个过程中蹇硕呼吁内廷的张让,赵忠支持自己,但十常仕倒向了何进。是的没错,十常仕是支持何进的,但本质是向着何皇后和刘辩,这里重点指出一下,也是东汉灭亡悲剧的开始。

何家的情况比记载的复杂

得到内鬼通风报信,置死地而后生反杀蹇硕的何进,当时肯定是意气风发,前途是一片明朗。首都的武装力量几乎都归置在自己手里了,立了十四岁的侄子刘辩当了皇帝,皇帝年幼自己自然是独揽大权。这里介绍下何家的情况,历史中的何进因为是屠户出身,被描述成一个莽夫,何进的父母是再婚家庭,他有一个同父异母的妹妹就是刘辩生母何皇后。何皇后有一个同母异父的哥哥何苗。所以,何进和弟弟何苗其实没有任何血缘关系,是异父异母兄弟,稍微有点点搞。

何皇后能入得了荒淫的灵帝后宫,最后成为皇后自然是容貌了得,何进自然不会是一个丑八怪。且经过长时间的经营,何家集团势力如日中天。镇压黄巾军的时候立过点军工,老妹是皇后,而且愿意花钱结交各种有头有脸的权贵。而且最重要的是,何进拜了当时大族,杨修的祖父杨赐做老师,手下的智囊团也是T0级别,陈琳,袁绍都是他的跟班。所以我说,就算他是一个莽夫,整个智囊团也不是酒囊饭袋,何进不是一个简单的new money。但事情就是那么神奇,怪就怪在手握这样配置的何进,最后也栽了。

转折点:一个母亲的选择

大家都知道结局是董卓最后进了洛阳,但董卓为什么会进洛阳,后面我会提到袁绍,这家伙出的主意,那为什么会发生这一摊子事情呢?我要做第二个猜测,何皇后和何进不是一条心。首先在前面一节中介绍了何皇后和何进虽然有血缘关系,作为离异重组家庭,加之何皇后从小入宫,关系未必很亲。当何皇后看到哥哥何进顺利干掉蹇硕时,她的内心肯定是非常复杂的,他知道自己哥哥的野心,尤其是沾染了权力之后极速膨胀的野心,说何进没有当皇帝的心是假的。所以何皇后的想法很简单,我只要自己的儿子当皇帝,其他人不要碰,就算是我家里人也不行,在这点上十常仕是完全站在何皇后身边的,造成了十常仕在蹇硕之死上站队何进的假象。

这里插一句,灵帝宠爱的刘协生母王美人被何皇后毒死之后,灵帝大怒,但因为张让,赵忠的花钱打点加求情最终绕过了何皇后,也就是说十常仕的政治筹码多投资在刘辩这边,并没有变过。传统版本的外戚在这里产生了分裂,何进加文官集团加军权,对名义上的皇帝刘辩加十常仕加何皇后。这里插一句,另外一个老母亲灵帝老妈董太后在刘辩上位之后被何家人干掉了,侄子董重也一起超度了,灵帝如果知道肯定要气哭了,杀何进把自己老妈的命也搭进去了。

开启地狱之门的袁绍

袁绍是一个城府极深,且阴险的人,他的小九九其实算的很好。他很聪明的察觉到了何家的裂隙,他知道何太后的心思,更看出了何进想上位的野心,我在这里做的第三个猜测是,最想上位的是袁绍。首先利用四世三公的身份获得皇帝信任,成为西园军二号人物,背地里结交达官显贵,暗通何进,答应做何进的跟班卧底。等待何进杀掉西园军一把手蹇硕,自己成为西园军实际上的控制者。利用何家兄妹的间隙,挑起十常仕和何进火并,然后利用手里的西园军,以及当朝三公之一的叔父太傅袁隗在朝中积累多年的袁家人脉,待双方鹬蚌相争之后,渔翁得利,自己上位。

为了加速和制造何家的对立面,于是三国历史上最无耻的计谋出来了,袁绍献计何进说可以调集一些军队,围在首都附近摆出要兵谏的样子,你何太后一个弱女子,看到这个阵仗就会乖乖服软,除掉十常仕后内廷就是你何进的天下了,霍光,窦武都不算啥了,这是一个属于何进的时代。在众人的反对中,何进居然听了这个计策,我觉得此刻何进是太着急了,太想一步登天了,他不想等了。袁绍这个小算盘算的非常牛逼,他对双方心理非常了解,事实上很多地方都被他算对了,唯独董卓和董旻不在他计算之内。蒙在鼓里的反而是袁家人,袁家一直以为董卓是他们的人,认为袁隗提拔过董卓,董卓的一路升迁离不开袁家,董卓应该会报答他们,可惜too young,too simple。

胆大心细的董卓兄弟

董卓出生边地,是不是一个圆滚滚的大胖子不得而知,但他有一个好弟弟董旻,这个弟弟是董卓上位的最大功臣。快进到到何进接受袁绍计策,董卓带领了自己的一小队人马,约二千人,驻扎在洛阳城西的平乐观,顺手还上书弹劾张让,赵忠等人,这里看上去一切都很OK,可以得奥斯卡的水平。可没想到双方交火就是那么突然,十常仕看到勤王大军逼近,每天上朝各路弹劾不停,与此同时还有袁绍通过捉拿十常仕家属方式试压。被彻底逼急之后,直接把何进骗进宫来,把他脑袋砍了。何进退出历史舞台的速度就是那么突然,此刻袁绍自然是有准备的,立马回过头来进宫杀宦官,权力真空已经产生。

董旻时任奉车都尉,人在首都,目睹了全过程,他为董卓做了两个很重要的事情,一是通风报信,二是收集兵力。董旻及时的通风报信,才能让董卓及时进入洛阳城内,并且在出城的车队碰到SSS级宝贝,刘辩和刘协。顺便多说一句,日后挟天子令诸侯其实作用并不大,但在兵变洛阳的当日,天子的归属决定了董卓的成功。与此同时,董旻和吴匡被袁绍弟弟袁术告知,何进是被何苗杀死的,两人带兵攻击何苗,并且斩杀何苗。吴匡是何进部将,而且是重要幕僚之一,董旻极有可能已经判断出了袁家借刀杀人之意,吴匡只是暂时的棋子,事后袁家必会找机会杀人灭口,同时吴匡杀何苗也可以看出何家确实存在裂隙。杀掉何苗的吴匡冷静下来之后,在董旻的分析之下知道自己已经中了袁家的计谋,于是带领了何进曾经的武装力量投靠了董卓。董卓一不做二不休,利用身份与贿赂搞定吕布,杀掉丁原。于是,兼并了丁原并州军与何进部队的董卓在洛阳的兵力占据了绝对上峰,东汉毁灭的历史就此无法翻盘。可见,董卓的成功大部分的功劳在董旻的判断,顺势而为,和巧妙的时间节点把控,再后来的故事大家也就都知道了。

后记

皇帝,宗室,宦官,外戚,功臣集团,文臣集团,一直是政治中的元素,不同的时期无非是配方多少的问题,总离不开这些东东。回头看东汉的毁灭是不是可以规避呢?其实完全可以的,何进作为一个突然有了至高无上权力的普通人,在袁绍的蛊惑下,确实急了点。和自己妹妹的沟通也不够,其实普遍的解决思路就是,先给刘辩表中心,然后生一个女儿和刘辩和亲,最简单有效的延续何家的政治生命。东汉这意外的崩溃还少不了野心家袁绍,野心太大,还有董卓兄弟的神机妙算,这一连串奇怪的因素组合在一起,让人觉得东汉的崩溃太意外了。当然我认为东汉灭亡并不可惜,但如果东汉当时政局足够的稳定,解决掉内部矛盾,使用犁庭扫穴的策略对付外部蛮夷,是极大概率避免以后发生五胡乱华的惨剧。

分类
大杂烩

现阶段腾讯云的容器服务TKE是最好生产环境的 理由

# TKE和腾讯云的资源结合很好,和自己的云服务器CVM配合完美,如果有钱也可以用黑石服务器。

# 使用了TKE就不用关心Master节点了,因为完全被腾讯云托管了,换言之,不管你有几个node,你不用支付Master节点的费用。

# 随着TencentHub这个DevOps半成品被腾讯自己收购的coding取代,你会发现TKE的镜像特别好用,因为大部分走了容器这条路之后,大部分公司尤其初创企业他没有特别多的构建步骤,TKE的镜像纯BUILD是完全可以满足你的,如果你要走完成的持续集成也不难。

# TKE的日志服务也很方便,可以走kafka,ES,或者你自己的CLS服务,如果是小项目直接cls的控制台操作操作就很方便,开箱即用。

# TKE的K8S版本更新还是比较快的,尤其是Master节点被托管了,升级没有什么压力,如果node升级失败,移出集群重新加回来即可。

# 我自己用了2年TKE,看着他一点点增强,还是非常满意的,即使遇到问题,腾云客服的响应速度也是杠杠滴!

分类
大杂烩

Flutter真的很棒,Dart真香。

最早有文本,后来为了表述的结构化,有了标点符号。http的到来升级成了超文本,有了文档对象模型,这大大丰富的对于文本对象的描述,jquery能方便的操作dom感觉酷毙了!后来,react来了,他说,数据驱动一切,只要操作state剩下的他来搞定。那都数据驱动了,剩下dom有何用。所以用oop语言的高级特性来描述界面,没有比这个更棒了。

是的,flutter来了,彻底的革命性的移动ux/ui框架,包含了全套谷歌的最佳实践,只要你想得到的就能做到。

使用的dart语言也很棒,现代化语言的标志之一,是将设计模式语义化,有了within可以轻松的使用mixin(装饰器模式),有了factory构造工厂方法愈发简单,有了命名构造函数,静态阶段代码阅读性更好。

强烈推荐大家尝试使用flutter,即将彻底杀死原生ios和android开发。

18年国庆节到了

感觉日子过的真快,国庆就预示着18年就快过去了。9月10月是我最喜欢的日子,上海难得在这两个月空气温度都很舒服,不过这两天温度的突然下降还是要注意保暖,免得生病。

微信小程序上线之后非常理想,在没有宣传的情况下就有自然用户使用,让人觉得挺有意义。支付宝上架之后我发现,支付宝的自然流量比微信还大,不是支付宝做的多么好,而是腾讯的搜索入口做的不够好,昨天申请了服务直达顺利通过,看看这个入口的效果如何。百度小程序虽然上线,但是入口藏的太深,feed流还没放开,似乎只是用来收费的一个落地而已。

小程序什么都好,但是他最适合做的还是工具,功能的载体。做内容就是一个错误的方向,这个以后说。目前有大量的关键字红利再小程序浮现,到了19年应该就消失殆尽了。

分类
大杂烩

为了公益,为了狗狗,91xungou.com寻狗小程序上线了!

不太更blog,因为有太多工作上的事情,尤其zhouzhou.net的备案搞了半天终于弄完善了,终于我能回来了。

首先呢,我要推荐大家访问https://www.91xungou.com这是我最新制作的一个网站,其实它不仅仅是一个网站,起源自微信小程序“寻狗”(微信用户可以搜索“寻狗”两字就能找到我做的小程序)以及新浪微博账号“寻狗小程序”。

一看名字就知道,这是一个帮助主人找回失踪狗狗的工具,利用小程序的特性可以快速的录入垂直字段,通过分享机制(生成朋友圈分享图片,分享好友和群,同步推送到网站以及微博)快速的帮助狗狗主人传播失踪狗狗的讯息,方便快速的发布寻狗启事。同时,将散落在各处割裂的信息源合并放一个页面,这样方便狗主人汇总线索!

目前来看,工作效果非常好,用户数节节攀升,可以明显看到数据在提高。我会把产品,代码的心得不定时的分享出来,加深自己的体会。

分类
大杂烩

自己的docker基础镜像php-fpm+nginx+alpine+composer,专为symfony4优化。

https://github.com/nickzhuo/phpallinone

Nginx: 1.13.10
PHP: 7.2.3
Redis客户端: 4.0.0
Composer: 最新版
ALPINE: 3.7

也可以直接使用build完毕的镜像

daocloud.io/nickzhuo/phpallinone:latest

分类
大杂烩

Hello world!

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

分类
大杂烩

把证书从startssl换到了腾讯云免费的TrustAsia

有点后知后觉,发现startssl的根证书即将被浏览器移除了,当然老的已颁发证书不受影响。ps:好像国内的证书,沃通也被禁了。

SSL对网络非常重要,尤其做接口来说,例如你可以在你的客户端做ssl pinning,保证百分百的传送安全,当然SSL会加重服务器的消耗,但这又算得了什么呢。

查了一下,腾讯云提供免费的DV证书,真的很不错,另外表扬下,腾讯云的产品感觉和性能感觉已经超过阿里云很多。

分类
大杂烩

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

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

分类
大杂烩

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

最重要的写在开头:道术合一,知行合一

现在是讯息爆炸的时代,搜索引擎降低了学习的门槛,凡是都能从百度谷歌了解个一二。正因为这随手就来的一二,带来了想要的“结果”,让大家只掌握了术,但忽视了道。我认为“道术合一,知行合一”,术是千变万化的,但是道确实永远的,做减法就是我自己的代码之道。

可怕的观点:执行效率是第一

我经常听到一种观点,代码需要的是更快的执行效率。以及由这个观点产生的衍生观点,例如:设计模式并不重要等等,因为我们可以绕过框架或者现有的方法,用更“原生”的方式实现一样的结果,这样会运行的“更快”。这是一个可怕的观点,可怕就可怕在看上去没错。软件行业发展到现在已相当成熟,我们绝不能用单一指标衡量代码,如同我们不能用百公里加速来衡量一个车,如果这样想,无疑要选比亚迪,实际情况真的是这样么?

代码是一种业务的体现:全方位的评估才合理

代码是一种业务能力的体现,举个例子:小轿车是个人出行业务的体现,全方位评估软件工程带来的结果才更合理。尤其在国内,人天的成本大幅度的提高,技术团队每天的开支相比其他传统行业近乎天文数字,我们对于迭代周期要求非常的高,单个sprint产出的价值太重要,甚至于正版软件相较于人力成本也已经变得是一个合理的支出范围。所有,我更倾向于,在初期掌握一支小型化技术团队,把握住业务的核心,最大程度整合资源,打通外部内部数据,且团队要能不停的适应业务的变化。而且不光是技术团队,所有业务团队其实都应该如此。

业务好等于代码好:好业务是不停迭代出来的

很多人都告诉我,自己的代码写的多么多么的好,一次写完永久运行。但这样好么,我可以负责的说,这样的代码不值钱。互联网业务是不停的试错出来的,业务好不好对公司来说就是赚钱不赚钱,也就常常带来一个问题,需求肯定不停的变化。我以为业务的打磨是好事,因为没有人能一下找到赚钱的模式,再牛X的业务都是不停的迭代变化出来的。所以,要做到能快速的迭代,我们必须让代码能够快速的变化。可能有些负责通知或者工具类的运维小脚本,写完之后可以静静的躺着运行若干年,但不代表这个代码是好的,只是代表业务是死的。但唯有赚钱的业务才需要不停的修改不停的改变,所以我的观点就是代码是不停的在迭代改变的,同样的我很悲观,盖房子的还能看到楼房屹立100年,作为软件从业者,你的作品可能只能在世界上存活3个月,这是一个非常残酷的事实。

代码变化的本质:反应业务的变化

业务随着时间的推移,往往公司从一开始一个人管全部到后来的运营分工精细化,这背后涉及的是人员和部门的变化。所以当设计系统的时候必然会参考业务部分的划分,使用者划分,和场景的划分等来做设计。如果能在动手写代码之前闭上眼睛看到使用者工作的状态,线下业务转线上的整个过程,思考出每个节点,那就是一种正确的模式,因为你看到了业务,看到了代码的真正价值体现!

语言的进化:都是为了业务

面向过程编程之所以进化到了面向对象,是因为我们发现所有的业务都是存在现实世界中事物对照的,以及他们的关系。有了面向对象,抽象让我们可以更好概括真实世界,多态让代码中事物拥有同时对应多个现实世界事物的能力,继承让我们能够复用大量的代码。进化到了面向切面,我们发现业务不停的在做微调,所谓的微调无非是一些业务逻辑在场景中顺序的改变,有了AOP这样棒的工具,代码的组织变得更合理,当然阅读性会差点。所有的代码特性进化其实本质都是为了更好的表达业务,包括可以用trait来实现一些非通用的多继承,用生成器让函数的返回变得“动态”起来。

最后

业务是一组代码的集成,如同你开了一个面馆,没有必要非自己磨出面粉做出的面条才是最好的。站在一个更高的格局看系统,你需要的是有限的资源下,包装面馆,整合所有。把握最核心,例如浇头做核心,抓大放小。夸张的说,即使只开了一个小店,但是想着一个跨国企业规模。还是那句话,尽可能的在年轻的学习阶段过度设计自己的系统,然后不停的做减法,就能真正的感悟系统,最后你会特别理解罗斯科的作品,真的不用太复杂。

最最后

谨以此文,把自己的小小感悟献给刘锦,一个任劳任怨,每天认真工作学习的安庆少年,未来的安庆马克·罗斯科。

分类
大杂烩

最近互联网周边的体验

今天订阅号直奔主题,简单的说说一些周边体验,可能有些与实际已经不符,而且也仅仅是一家之言,如有冒犯请见谅。

开头题外话多说一句,为什么要用周边,我觉得艺术圈给我带来最大的理解之一就是艺术品的市场价值和艺术价值是不挂钩的,同理也适用在软件行业,代码的商业价值和技术价值是不挂钩的。切莫局限在技术的片面表现中,越走越细,举个例子,当你把关系型数据库看成一个服务的时候,不仅仅是简单的提供sql运行能力,还要有分布式,要有冷备份热备份,还有高可用,要有健康程度监控,要有审计,等等,当你完成了这整个服务方案的时候你发现你的业务还没开始。再举个例子,如果没有七牛这样的周边,可能一些图片APP团队还在自建分布式文件系统中,沉没在fastdfs的泥潭中。我们要最快的整合周边,把商业价值放大,这样才有闲置资源放大技术价值。

再中间插一句,很多很多小伙伴和好朋友问我现在去了哪里,借订阅号宝地说一句。老夫已经把天赋带到了空艺术,一个艺术平台。贯穿艺术领域各垂直和横向、国内和国际产业链,整合线上和线下资源,打破艺术领域与资本和非专业化消费受众壁垒间迅速发挥领军作用。(妈蛋,这个介绍是复制的,不是我写的。)

容器和持续集成篇

Daocloud:国内容器团队,他提供了一套容器管理面板和完整的CI功能,可以完成代码上传后的自动触发构建,测试,部署,监控。生产环境容器必须部署在自己的云上,本身提供的主机称为胶囊主机,只是作为调试用。他提供的SaaS服务包含数据库和缓存也只能用在测试环节,如果你已经有自己的托管主机或者有自己的IaaS供应商可以考虑使用它。但Daocloud有一个致命问题,不支持集群,它的集群是一个“假”集群,只是随机把服务放到某一台机器上而已。CI部分,Dao的优点在于他有国外主机用来build镜像,速度非常的快,因为我们的代码包大量依赖第三方源。可惜的是,对于junit的输出xml格式兼容性有点问题,嵌套多个testcase输出的结果无法兼容,可能要手工输出成dao需要的格式,或者等他们升级。Daocloud的服务很棒,上班时间客服反映迅速,我个人强烈推荐容器爱好者注册一个Dao,只要有一台自己的PC机,简单装上他们的agent,就能开启你的第一次容器之旅。对了,Daovoice也是一个很棒的功能,可以为你提供一个在线客服聊天,当然很简单很初级。最新他们也出了DCE可以部署在私有云上的管理套件,但还是那个问题,没有解决集群的话,他对企业的帮助不大。

数人云:他提供了一套开源的可以私有化部署的基于SwarmKit的管理面板,但我真想说这个公司就是完全来搞笑的,代码的完成度非常的低,开源并不是可以为质量不负责做借口的依据,使用过程中充满BUG,用了之后我整个人都不好了。

灵雀云:很干脆,基本就是一个镜像仓库加速和容器面板,没有数据库缓存之类的周边,这个是致命伤,CI做的也很一般,和Daocloud不能比。最讨厌的是客服也不友好,当你表达出没有付费意愿之后,就把你切成了免费账号,只有一个镜像功能,有点大牌哦。

网易蜂巢:迅速的成长中,每次登陆都可以发现大网易版本迭代很快的,而且投了百度的关键字竞价。但就从Build环节老失败说起,没有国外节点,很容易buld不过去。没有提供测试环节,所以就是镜像构建加部署等等,用起来的感觉很稚嫩,不过界面配色我挺喜欢的。

时速云:放在最后必然要重点介绍,如果你是一个创业公司刚起步,那么我觉得时速云是最棒的体验,他提供了创业团队需要的一切,我指的是一切。在保证自己代码团队已经完全容器化之后,你无须购买任何主机,只要push代码就能完成CI/CD,部署,监控等一条龙服务。他是基于k8s的架构,所以自然而然的天生能力强者,他提供的主机完全可以用在生产环境,关键是一个容器的最便宜收费才28.8人民刀一个月,简直太便宜了不是。他的团队也提供了分布式的Mysql和分布式Redis给你使用,当然Mongodb以及大数据的周边还没,但是对于创业公司来说这已足够,关键足够的便宜!缺点也有,没有外国的Build主机,我有超过1G的镜像会很容易build失败,界面追求炫酷,有些控件不实用,例如查看构建日志就容易把浏览器弄崩溃。还有一个很神奇的地方在于,帮助文档没有搜索,这挺诡异的。但我还是强烈推荐时速云,我觉得是国内目前容器提供商中最有潜力最有前途的一个。

IaaS篇

青云QingCloud:着重介绍下青云,目前我公司的业务都跑在上面。青云的最大优势在于技术上非常先进,尤其刚开的上海区,网络完全基于SDN/NFV,我一直认为光主机虚拟化是不解决任何问题的,网络必须虚拟化。这点青云目前国内做的最好,不像阿里云的经典网络被很多人吐槽,没办法,技术肯定是越新越好的。青云的后台及其的友好,产品经理应该是下了大工夫的。尤其是大数据部分,做的真的很全,Elasticsearch,Spark,Storm青云是目前最好的选择,有点爱不释手,我简单计算了下计算能力,同等计算能力下,费用是阿里云的8折。青云还有一个独门秘籍,因为支持SDN,所以可以让Docker直接用SDN代替Docker Overlay,简单到只要装一个他们的插件即可。推荐青云+Daocloud的组合,可以满足中大型互联网公司的基本95%的需求。

Ucloud:和青云的对决中已经处于下风,本来也是一个很新的IaaS,周边不全,可能聚焦的不是大数据的业务,听说服务游戏商比较多。

阿里云:有点老了,但是阿里云有自己的优势,ECS可以选择的机房多,例如我公司的SS服务器就放在阿里云香港节点,但时间跨度太久了,他真的老了,而且价格体系非常混乱,同配置的服务器测下来总感觉慢一点。如果你有机房地区的特殊要求,可以选择阿里云,但不推荐。

Azure:试用的流程有点繁琐,爱买不买的样子,放弃。

代码库

Github:私有库要收费,其他没缺点啊!

Coding.net:因为自己团队代码在上,体验比较深刻。有很多bug,例如:项目在团队和个人之见转移可能会出权限问题,感觉还不能商业化,最诡异的地方在于当你希望成为付费用户的时候,你会发现收费是基于项目而不是团队,对你来说收费的好处仅仅是可以让一个项目的开发者超过50个人,天哪,真有单项目那么庞大的开发团队吗,恩。除此之外,界面很丑,交互操作的感觉很糟糕。

测试

Swathub:简直让我大呼哇塞的一款产品,简单说就是SaaS化的selenium,非常非常有前途,使用难度非常低,通过向导式的表单可以很轻松的建立一个testcase,并且保存在云端供整个测试团队学习使用,说的通俗点他真的就是一段可以控制浏览器的代码,让你的测试团队不再是按键精灵,节约了很多鼠标。通过api触发配置在CI环节简直神器!能大大幅度的提高测试过程的效率!但是特殊的控件,例如:bootstrap的组件,由于DOM的多层嵌套或者布局的缘故需要自己手写对应的选择器。如果我有钱我会考虑收购这家公司,非常有前途。:D

分类
大杂烩

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

勇哥对我说,我写的都是道,但是大部分人需要的是术。我恍然大悟,想想这有道理,道理虽然是根本,但是术还是要有的。特别推出一针灵系列,顺手弄个耸动标题吸点粉,请轻喷。

PHP使用简单,上手特别的快,这导致使用者水平参差不齐。而且因为诞生时间太久,有很多冗余的东西,缺点堆堆的,这里不展开。有太多技巧可以提高水平,今天先说十个,有些可能非常颠覆你的想法,但请听听我的看法。

1。熟练使用SPL,这是基础

PHP本身是一门工具,SPL是工具中的工具。SPL的使用会大大简化你的设计,我发现N多程序员无法回答和SPL相关的问题,这是致命的。例如:SplSubject接口可以轻松帮助你做出一个观察者设计模式,SPL系列迭代器满足99%的使用场景,虽然你可能不写自动加载,但是spl_autoload干嘛的总要知道吧。

2。参数需要注入,不要和环境发生依赖关系

你写的代码承载的是你的业务,业务是可以工作在CGI或者CLI下的。看到太多的Sample中控制器会直接使用$_GET,$_POST之类的环境变量,这是致命的。如果你的模型层也有直接获得GPC,恭喜你,重构已经提上议事日程,因为你的业务根本无法再CLI下执行,请把环境变量和业务参数的绑定设计成注入的关系。

3。不用写任何一行注释,熟练运用PHPDoc

代码本身是不用注释的,难道你会在一个user变量中保存一个order讯息么?当然不会,因为他叫user呀,代码本身应该如同说话一般流畅,在写代码的同时最好打开一个词霸。而PHPDoc是你的备注,强化代码对使用者的帮助,让所有的“人”(例如:IDE)明白你的意思,静态代码检测是一切效率的基础。

4。任何模板引擎都是垃圾

这是我的个人观点,为什么要使用另外一种DSL去描述模板呢?除非你能将模板工作交给一个专门团队做,而且用的引擎应该是跨语言的。实际生产环境中,只要有静态页面,和JS的模板引擎足够了,除非你要为SEO做服务。额外说一下,大量的模板引擎把模板和缓存有绑定在一起,灾难加灾难等于毁灭。SO,我从不会面试提问任何Smarty的问题,因为那就是一坨屎。

5。使用PHP编写路由而不是依赖HTTP容器

这个问题和参数注入类似,很多代码中包含的.htaccess其实是很无厘头的,路由也是业务的一部分(除了锁定入口)。我只想问一句话,你的代码难道不想运行在nginx,IIS,lighthttpd上了么?还有很多http容器呢!如果你想把自己的代码商品化,切记把路由放在代码中。而且我想说.htaccess简单的语法,是无法和高级路由器相比的。

6。显示声明变量并且初始化

任何变量使用之前请初始化,如果你是一个合格的程序员。虽然PHP本身会很无厘头的包容你的这些做法,但是这很不职业,尤其extract函数配合GPC使用,导致的后果是致命的,可能覆盖任何关键变量。如果要我配置php.ini,第一个就把extract给disable掉。

7。优秀的代码必须使用Composer

代码是一种服务的载体,所以必须灵活部署,他需要有自己的包依赖管理和autoload管理。千万别在自己写autoload了,我相信你可以,Composer的出现解放了太多PHP程序员。而且请记得千万在本地部署一套本地Composer(Docker做很容易),因为你的CI(持续集成)用得到他。

8。只有视图才会用到Array

这一点很难做到,因为PHP的Array太变态好用。在我的理解中Array只是一具尸体(无法控制读写,无法控制公开程度,没有方法),在业务中所有的值必须以对象的形式传递,这样才能在每一层中做对应的约束等等。只有在视图中才会用到Array,当然前面说了如果没有SEO,也就没有PHP视图,那么其实你的代码中可能就没有Array了。好吧,我的言行有点过激了。

9。不要在代码中随意退出

我想举个例子,你去别人家做客,从大门走进去,走的时候为什么要从窗户跳出去呢?MVC中单一入口进入,其实还有后半句话,要从单一出口退出。如果代码不是你一个人写的,任何程序员无权在自己的辖区内中断代码,因为你根本不知道Runtime时候上下文关系,可能导致OB失效,导致HOOK失效,等等。如果你说这样节约性能,我只想建议别用百度。

10。优秀的PHP程序员必须关注死亡皇后岛订阅号

好吧,这才是这篇文章的目的,只有关注了死亡皇后岛,才能第一时间获得舟哥手写各种语言的心得。谢谢大家,关注之余不要忘记随手转发,万分感谢。

分类
大杂烩

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

    数据库一不小心说了四节,自己觉得有点枯燥,那就开一个新系列讲关于编程感悟吧(多一个一级菜单真是一个不错的选择啊)。

    我总是建议年轻的程序员(虽然我也很年轻)应该把项目复杂化,尝试各种手段让自己的项目充满过度设计的感觉。然后静下心来做‍减法,当你会用减法并且理解其中奥秘的时候,才能学到编程的精髓,才能学会用编程的方式思考问题!

    而且你会惊讶的发现,解决问题的过程实在是令人着迷,倘若你的工作只是完成需求,那么根据契约精神你只能收获的是工资。罗伯特清崎在《穷爸爸和富爸爸》里写到,“老板发你的工资是保证你不会离职的下限”。我的理解是,在工作中不应该只获得工资,更多的是学习知识!

    说到减法,举一个不恰当的例子,暴雪的最新游戏《守望先锋》就是一个做减法的典型,当国内游戏从业者一个劲的往产品叠加功能,例如:每日签到模块,抽奖模块等。《守望先锋》却大幅度精简系统,没有一丝的肉。是他没有能力做类似签到模块么?显然不是,是因为他的终极诉求是为了带来愉快,所以玩守望的每一分钟都没有被浪费的感觉。

    为什么这次的题目是《本地方法和远程方法与可见性问题》呢?我发现问题都是连环相扣的,我要用代码可见性问题做引子,推出我的观点,代码本身就是最最好的注释。本地方法就是本地文件夹定义的function,通过本地引用方式调用定义的方法,缺点是调用者和实现者必须相同语言,你无法用java调取ruby写的方法。本篇中我把跨语言的调用都称呼为远程方法,当然可能他不是真的在“远程”,同语言也可能是远程方式调用。

    为了进一步说明代码本身是最好的注释,我创造了三个名词,代码可见,文档可见和定义可见来帮助大家阅读。对每个人来说,本地方法使用起来非常便捷,常常得到一个软件包放到项目内就能跑起来,这其实就是代码可见。当你无法理解上下文的时候,只要进入代码里看一眼便能明白有什么问题。代码可见简单直观,只要你有源代码,你就明白他是干啥用的。

    远程方法使用起来很是麻烦,我们需要去找实现者写的定义文档,可能是一个json,可能是一个wiki,也可能是一个Markdown文档,里面的描述尽可能的详细,总之按照里面说的定义方法使用肯定没问题。但是糟糕的是,万一远程方法返回了“不该发生的东西”,这怎么办?这往往是因为文档的更新总是落后于代码造成的,也许我们在条件充足的情况下,会精心的制作文档。一旦hotfix来临,谁还会想起在深夜2,3点更新自己的文档呢?常常以来,文档成了第一行代码者的专利。

    文档可见看着很美丽,真正用起来,但也别着急否定它。我认为这是一个好东西,因为代码不光面对是的研发人员还有测试人员等。不要有了点缺点就否定它,我们要帮助它变好,只是需要大量的周边去维护,手工维护文档是不科学的!

    Github上充斥着大量的RPC框架,基本都是基于某个协议层,支持多语言的服务客户端实现等云云,最最关键的一点是会告诉你,一旦用了它速度提高N个级别等等。毫无疑问,这些性能指标肯定是真实存在的,但衡量服务调用难道就用一个性能指标就够了吗?到底我们需要什么样的框架呢?

    定义可见浮上水面,用SOAP举例子。经常听N多人说SOAP好慢呀,没有自己写的简单框架来得快,我永远不参与类似讨论,虽然我不是SOAP支持者,性能太过低下,但我们要理解为什么这样做。SOAP支持WSDL,这就是定义可见,我支持定义可见。支持WSDL的IDE,例如:Eclipse,只要基于WSDL实例化客户端,代码的使用如同本地方法!

    WSDL给了我们什么启示?原来定义可见多么的重要,我们的工作方式也会随之改变。先定义我们要的方法,基于定义产生文档,也基于定义实现客户端和服务端。这一切不就是TDD(Test-Driven Development)么?通过现代化的工具(例如:Swagger)帮助你完成“无脑”工作岂不是更好,所有围绕这个方法工作的人们,都能协作无偿提高效率,这就是定义之美。

    可见性就是为了让“人”更懂方法,这个人可能是真的人也有可能是电脑(IDE),也可能是以前的你和未来的你,一切的定义都必须显示,他真的能让效率提高。看到这里,你想说你的代码里没有那么多远程调用,但我想说的是,即便很多本地代码也定义含糊不清,静态代码分析在你的代码面前失了效,没有代码提示怎么让你的代码被传播,多利用注解Annotation等等技巧(请关注新的一针灵系列)让你的代码更容易被更多的人读懂吧。        

    当你调用远程方法和调用本地方法已经完全一样之后,那更抽象的理解方法到底是什么呢?方法是提供某个业务的能力,他需要分层,每一层既是调用者也是实现者更是定义者,到底该怎么分层?怎么描述结果,请支持关注本公众号,死亡皇后岛,老夫会为你做进一步解释。随手转发,关爱优质订阅号!
分类
大杂烩

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

    任何东西都不是多多益善,帕累托法则在生活中处处体现,关系型数据库就是一个典型的例子,你会发现80%的业务跑在20%的功能之上。显然,我和帕累托一样,不相信均匀分布在真实生活中体现。

    以下摘录自Andy Warfield的《The 80/20 rule… for storage systems.》,“80/20 法则通常被认为是源于意大利经济学家维尔弗雷多·帕累托。帕累托出生于1848年,他是(至少被认为是)占领运动的早期成员之一。他发现意大利国家财富的80%是掌握在几乎少于20%的人口手中的。由此发散开来看,80/20法则在其他方面的应用同样值得注意,也是很有趣的:因为帕累托观察发现他的园子里的80%的豌豆产自于20%的作物上(他似乎更喜欢数豌豆而不是其他豆子)。"

  很多程序员在做到某个阶段的时候都会来问我,要不要用触发器?要不要用存储过程?等等一系列类似的问题,你也会发现从搜索引擎可以找到很多文章在围绕这个话题展开分析,介绍各种各样的技术等等,但我想申明我的观点,在OLTP的系统设计中,请不要把你的业务逻辑以触发器和存储过程形式放到数据库中!OLTP只能保存关系,也许有些feature一时帮了你的忙,但是后患无穷。就好像你能在任何饭店轻易点到一块巧克力蛋糕,但味道永远不能和专门蛋糕店比。

   回顾一下历史,还记得10-15年前,B/S主流结构还是ASP。PHP的用户不对,这时候大C还没把cdb改成Discuz,VBB里的附件居然是存放在数据库的二进制里,Perl还很热,leobbs如日中天,每个空间商都会标注支持cgi-bin这样的可执行目录,表明这个空间不是静态的。也就在这个时代,关系库真的开始进化,程序员从文本库中解放了出来。

   有了新的工具大家自然要研究透彻,但是工具不是说要把他用足用透才是好的,每个工具都是有他最适合的场景的。DVBBS动网是ASP时代的一个经典产品,记得当时会把高级和普通版本划分成存储过程和非存储过程版本,这导致很多人眼里存储过程是一种高大上的东西,所有不是自己技能栈的东西就高大上,但真的是这样吗?同样的,去一家饭店非要吃遍所有菜才是好的么,我想如果你是帕累托,只会点其中的20%吧。

    我对软件工程的理解之一,业务描述语言必须单一化,面向结果!代码究竟是什么?代码本质是为了提供服务,如果存储过程被引入进来,你的代码中是否包含数据库DDL部分就是一个问题。CVS中推上去的TAG到底包含了DDL语句么?

    当然这对百度型人才来说也不是什么问题,你可以投机取巧一点把DDL放在代码目录下类似script目录,利用hook来实现和代码同步上线,但这合理么?今天不想说怎么自动化上线和我的方案,进一步说,当一个newbie程序员来到你的团队,在review现有代码的时候,是无法用大脑做静态代码分析(Code Static Analysis)的,他会百思不得其解上下文和结果,因为你的代码不连贯,更不语义化,因为SQL是面向过程的。

    触发器也提供了类似效果的诡异陷阱,程序员一遍遍的review代码,但无法找到发生DML的地方,原来一切都是触发器默默的在背后干着坏事。对于外键的使用我也持保留的态度,任何业务关系必须在代码中显式描述,物理数据库利用外键保持数据一致性我认为不合理,例如:物理级别的分表怎么办呢?

    对于数据库的认知是对编程认知的一小部分,看到这里你应该理解了我想表达的观点,业务关系请放在业务代码中描述清楚。不管你认可与否我的观点,这也越来越逼近我们探讨的本质,未来的代码中该怎么描述业务?怎么设计我的架构?设计模式怎么用?

    symfony book中有一句话我很喜欢,build app not build tools,我极其排斥重复造轮子,但是你要知道轮子是怎么造出来的,才能知道以后的轮子长什么样子。请持续关注本订阅号,您的转发是我的动力!
分类
大杂烩

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

    松本行弘在《代码的未来》中领悟道,这世界上没有java编程,没有ruby编程,更没有php编程,其实这世界上只有编程这两个字呀!

    好喜欢这句话,我觉得数据库编程也是一样的道理,虽然我们在谈数据库,更多的探讨是如何拥有编程的思维去处理这些问题。当碰到跨语言,跨平台的编程时,我们会称之为架构,但其实本质还不是在编程么?最后你会看到,人的架构永远大于软件架构,编程技巧只是人类处理真实世界问题在代码中的体现!这是我的感悟。

    作为系列的第三篇,我们谈谈关系型数据库常见的问题,也是初创型公司不能高速发展乃至转型的羁绊,业务字段展示字段傻傻分不清楚!

    先从一个简单的例子开始说起,我们总会设计各种各样的管理系统,例如酒店管理系统,里面管理着所有的业务实体,酒店实体自然是酒店业务在代码中的映射。我们常常会接到一个类似的需求,需要为菜单中包含宫保鸡丁的酒店标识为上海味道,前台可以基于这个标识筛选出符合期望的酒店。

    很糟糕,这是一个标准的死亡陷阱,程序员先做了第一件事情,为酒店增加了一个属性叫做上海味道,对应的关系表也多一个字段。第二件事,必然的会修改所有可以触发该字段变更的地方加入新逻辑,若这是一个复杂的系统,必然痛苦不已。
    
    所有初创公司的研发团队都消耗在了一些无用的事情之上,很快产生边际效应,他们已经无法应付真正的新品类拓展,光是打补丁便已经停不下来。那么到底是哪里错了呢?

  我要否定的就是这两件事,它们是不对的,首先第一点,我想先解释一个问题,什么是业务?我个人理解业务其实是一套流程,可以用UML工具绘制出来,业务绝对不是一套炫酷后台系统原型,更极端的说,是把真实生活中流程映射到计算机系统层面,他的每个环节对应了不同的部门,对应的产生了一系列的指标,有了指标自然也要有正确方式去使用工具驱动完成这些指标。在我的例子中,上海味道这个字段不是业务流程中驱动业务前进的字段,他的本质只是一个展示字段帮助提高用户格式化数据获得体验。

    这就牵出来第二个问题,业务字段和展示字段是同一个东西?他们都存放在关系型数据库中么?我的回答是否,初创型公司给C端用户体验的网站以及客户端往往都会从直接从数据库中读取数据,虽然很多公司表面上做成了微服务(多端发展导致不得不实施的结果),但他的数据源还是一个问题!试问一下,我能把含有酒店总经理联系方式的酒店实体表供前台网站读取么?即使前台程序员能控制用户的展示,那么前台的程序员真的需要知道这个字段么?万一被黑客攻破了网站难道你的数据就赤裸裸的暴露出来了么?

    终于,我们发现前台展示层最需要的持久层应该是一个文档化的,全文搜索的系统,关系对他只是可选的。他只是存放了业务字段的投影,也可以基于业务字段存放一些自己的复合字段。你根本不用增加一个表字段叫上海味道,也不用在菜单编辑保存的时候更新这个字段,他只是在重建前台index的时候被更新,至于前文的第二件事情,怎么更新呢?我们需要一篇新的文章,基于项目内和项目外的实时异步通讯,在这个文章之前我们还要探讨下本地代码方法和远程RPC到底有什么不同。

    这个问题和《关系型数据库使用中的误区系列:数据的价值》中导致犯错的原因有点类似,需求方的原始需求被错误的分层,业务字段和展示字段傻傻分不清楚!该前台程序员做的事情被扔到了后台来,你甚至可以很简单的理解,后台不用排序筛选的字段都不是业务字段,但具体的应用还要看公司业务的需要!

    后记,这个原则,是在到喜啦团队中反复强调遵守的原则,他真的可以帮你避免了很多无用的工时开销,更好的理解业务!安利时间又到了,在我们首席科学家botao带领下,我们选择solr为前台千万级的PV提供个位数毫秒的数据响应能力,恩。