海阔天空的云

我们在自己的世界里独自狂欢

0%

胡斐

写文章坚持原创

如果你看广州出版社版本的金庸小说集的话,你会发现《雪山飞狐》和《飞狐外传》其实是三本书,《雪山飞狐》是一本书,《飞狐外传》则是上下两本书,我为什么要纠结于这些呢?是想告诉那些没有读过书的朋友们,《飞狐外传》其实内容更加丰富,但是它内容虽然丰富,其实却未见得情节比《雪山飞狐》要紧凑。看过很多评论,《飞狐外传》厚厚的两大本书,就是一直在赶路,一直在打打杀杀。我听了会心一笑,竟然很有道理。按道理来说,既然是武侠小说,打打杀杀的情节在文字当中就在所难免,然而在这部小说中,又似乎总有一些打打杀杀的桥段,让人感觉太过啰嗦,并无推进情节的作用。相比那些打打杀杀的情节,我更关心的其实是胡斐、袁紫衣、程灵素之间的三角恋。好吧,我硬生生把一个金庸武侠小说,看成了琼瑶。

说起《飞狐外传》,很多朋友肯定会喜欢那个善良可人,聪明伶俐的程灵素,她做事处处都能想在前面,即便是自己已然在生死攸关之际,仍然不忘记报仇,利用七心海棠这种毒药报仇,手法也是极度得高明,让人叹为观止。相比之下,袁紫衣则是站在了她的对立面上,两人一个会武功,一个会用药。一个在明,一个在暗。一个性格活泼,一个性格柔弱内敛。一个长相甜美,一个貌不惊人。

金庸为我们设定了一个命题,是颜值更招人爱,还是聪明更招人爱。在这个问题上,胡斐选择了颜值。这个话题似乎也有问题,因为我们能够发现袁紫衣其实也并不算是傻白甜,她也很冰雪聪明,她也能够早早地算到福康安的所谓天下掌门人大会不怀好意,于是想要去破坏这个行动,她也凭借着她的聪明,练就了一身的武功,因此才能够在奔赴天下掌门人大会的途中,夺取好几家门派的掌门位子。胡斐并非单纯地选择了颜值,他是选了一个最优解,对他来讲,又漂亮,又聪明,又会武功的袁紫衣简直就是女神一般,相比之下,胡斐并没有那么喜欢程灵素,尤其是当他发现,程灵素工于心计,会用毒药,他为此不齿,觉得用毒药并非正道,当然不会有太好的印象

小说最后的结局是,围绕胡斐的两个女人,最后都离他而去。一个是爱着他的人,为了他甘愿牺牲,一个是他爱着的人,最后不得不跟他分别,继续当她的尼姑。这两个女人的离开,都出现在小说的最后一章,顺序则是程灵素先离开,袁紫衣后离开。我看书的时候,看程灵素离开,看得很心痛,很不舍,心想这么好个女孩子,年纪轻轻就去世了。看到袁紫衣离开,则是会想,既然你是尼姑,干嘛不从一开始就划清界限,赶紧走,走得远远的。我想很多人,也会和我一样的想法。两个女人的离开似乎也很合理,不然也很难解释《雪山飞狐》里单身的胡斐遇到了倾心已久的苗若兰,两人产生微妙的情感。

总体来看,《飞狐外传》肯定不算是金庸最好的小说,情节也没有太引人入胜,只是我们会更加喜欢那个程灵素,她太招读者喜欢了,可惜并不招胡斐喜欢。

主要情节。

由于疫情的影响,我刚刚将《飞狐外传》读过,更早之前,我将《雪山飞狐》读过了。

2020.03.10

近日有新闻:微信iOS版将支持暗黑模式。

这显然是一件好事,很多网友都发出了终于等到了的感叹。的确,微信是我们国人使用频度最高的社交应用,甚至可以去掉社交,就是国人使用频度最高的手机应用。微信好用不好用,直接关系到数亿人的使用体验。然而,我们却发现,有很多问题,是我们一直在吐槽,而微信死活不改的,其中一个比较突出的问题,就是微信不支持暗黑模式。

玩Android的朋友可能知道,在安卓手机上,可以通过安装一个叫做Xposed 的应用框架,然后再通过安装一些模块,就可以给一些应用程序添加一些更加有趣的功能。你们知道,这两年最火的模块是什么吗?是一个叫做WeXposed (微X模块)的应用,它可以给微信增加很多功能,就像是它的介绍里所说:

-防止微信撤回消息
-转发微信聊天里的图片和小视频到朋友圈
-转发聊天里的多张图片(最多9张)到朋友圈
-转发语音给朋友
-转发收藏内容
-转发朋友圈里的内容到自己的朋友圈
-分享图片和小视频
-屏蔽群聊成员
-自动查找僵尸粉
-批量删除好友
-批量删除僵尸粉
-自动回复
-自定义表情最高限额
-自动领取红包、转账

这个模块很火爆,而我需要指出的是,由于使用Xposed需要一定的技术门槛,也会给手机造成一些不稳定,事实上,如果人们不是喜欢折腾或者万不得已,其实也未见得会使用这些模块。我们其实也可以从上面列出来的微X模块的这些功能,侧面看出来微信需要的改进。

不过,话虽如此,如果你看过微信公开课,你一定会了解到,微信是一个非常克制的平台,它想努力提升用户的体验,便捷性,但是又不得不与微商做斗争,这个时候就需要权衡。我们还是继续看,上面的

-转发微信聊天里的图片和小视频到朋友圈
-转发聊天里的多张图片(最多9张)到朋友圈
-转发语音给朋友
-转发收藏内容
-转发朋友圈里的内容到自己的朋友圈
-分享图片和小视频
-自动回复

这几项功能,虽然方便了用户,但是一旦大规模的普通用户用上了,其中也就会混杂着大量的微商,微商的操作成本就更加低廉了,这也就会让我们看到更多的朋友圈广告,相似的逻辑,微信电脑版,从来也不支持发送朋友圈,也是同样的理由,微信在想方设法的约束微商。

然而,尽管如此,你们知道吗?我仍然无法理解,微信没有这些功能:

-自动查找僵尸粉
-批量删除好友
-批量删除僵尸粉

于是,我们就经常能够在微信上看到一些消息,要我们清理好友,理由是可以节省手机空间,这实在是让学计算机的我哭笑不得。

除了微X模块支持的这些功能之外,我自己也有一些问题,认为微信可以做的更好。首先,微信的消息不再提醒功能可以更好。现在的逻辑是如果我们在朋友圈给一个好友点了赞,只有其他人也给他点赞或者评论,我们收到了消息,才能通过长按消息,来设置不再提醒,而实际上,此时我们已经受到了打扰,我完全不关心其他人对这条朋友圈的任何动态,我也知道我和这个朋友圈发送者之间有很多共同好友,非常有可能会受到其他人打扰,可是我却只能在受到打扰之后,才能够设置不再提醒,这实在让我觉得很烦。如果能够在我点赞的时候,就设置不再提醒关于此条动态的任何消息,那就实在太好了。

另外,微信的聊天记录不能够云备份,微信自己的说法是保护用户隐私,聊天记录只会在用户本地,可是这个谁又说的准呢?再说,跟微信同门的QQ,不是都有云备份吗?为什么微信就不可以有呢?微信云备份显然有一些好处,一个比较突出的好处是,有了聊天记录云备份,我们可以放心大胆地在本地删除聊天记录,这真的可以节省用户的手机空间。

当然,我也发现,最近微信更新了一些很让人喜欢的功能,比如视频号,又比如原文转发,这些功能都很实用。我们一边在吐槽着微信,一边又不得不使用它,盼着它更好,这个国民应用不知道还会相伴我们多久,会火多久,又会又谁来代替它。让我们期待未来吧。

微博上有一条热搜

全国妇联宣传部部长刘亚玫介绍,特别关注到一线女医务人员的所急所需,紧急筹集了卫生巾、安全裤这些生理生活用品等资源,送到她们的手上。把这些生理卫生用品纳入到防疫保障用品的清单,帮她们来解决实际的困难。

我想这的确是一个很细心的关怀了,只是这个细心的关怀晚了一些,但毕竟还不算太晚,毕竟还有所表达。

昨天是三八妇女节,各个电商平台喜欢将这个节日叫做“女神节”,以此希望更多女性同胞们能够在自己的平台上多购物,多消费。线下的超时也采取了很多的优惠措施,来应对这个节日。昨天,我就和我老婆两个人,一起去了趟超市,甚至不是一家超市,而是两家超市。我老婆这几天一直惦记着要买生理用品,然而在电商平台上,看了一圈,总是对价格不满意,说是价格太高了。后来我们去到了第一家超市,在收银台旁边的一个促销展示区,整个区域都是卖生理卫生用品的,老婆在那里看了几分钟,终于挑选到一款价格够好,自己又常用的品牌,一次买了四包,我们就去结账了。后来老婆跟我讲,这几包,她可以用上半年。还吐槽这个超市,除了卫生用品之外,其他的都没有旁边另外一个超市要好。

我们在两个超市都转悠了转悠,发现有很多女性的购物车里都有生理用品,这让我有一点点意外。作为一个二十几年刚刚脱单的钢铁直男,我自己其实很难想象这样一件事情,也未曾考虑她们这方面的需求。我老婆会因为买到了合适的性价比超高的生理用品而欢呼雀跃,联想起之前看到的另外一个新闻,支援武汉的医护人员,由于身穿防护服,不能及时换卫生巾,尿液和血液夹在在一起,闷在防护服里面,感觉就有多糟心。

在我国,身居高位者大多是男性,所以或者是很难体会到女性的这样一种需求。但是索性通过媒体的报导,让更多身居高位者知道了女性医护人员在这个时刻正承担着另外一种痛苦,这种痛苦区别于抗疫防护,却又与抗疫防护紧密相连,如果这个生理卫生问题不好好处理,也是很让人痛心的。

我希望所有的医护人员,都能够像我老婆那样,拿到好用的生理生活用品,都能够开开心心。

健身这件事

又重了

由于新冠肺炎的影响,我腊月二十七回家,到了第二年的正月二十二才到达北京,而到达北京之后,又要进行为期两周的隔离,也就是说,我要有一个半月的时间,处在一种“宅”的状态之下。回到北京的当天,已经是晚上的十点半了,我回来之后的第一件事,是站在体重秤上称量体重,结果果不其然,重了好几斤。

我自己的体重曲线,蛮有意思。如果说有啥规律的话,大概就是只有回老家,就会长肉。而在北京,则几乎可以保证体重平稳,这已经是铁的规律了。比如我毕业之时只有140斤左右,而恰恰就是6月份回到家,在家呆了两三个月的时间,之间让我的体重飙升了20斤。后来,这二十斤肉,就开始反反复复,有时候减掉些,有时候又涨上去,可是一旦回家,那就只有涨上去的份了。所以,虽然我在北京还算节制,也还比较注意运动,也因为有小米秤在,可以时刻关注体重,总没有大的偏差,而一旦回家,家里没有秤,又无事可做,每天呆着不说,还一天三四顿饭管够,想不胖都不行啊。所以,这样想来,我似乎有必要在老家也放一个小米秤(嗯,我已经逐渐变身为一个miboy了,可详细看《我的小米往事
)。

曲折前行的体重

其实,这些年来,虽然体重一直曲折上升,但我也一直没太当回事,一直也是遵循着佛系减肥的思路。我在之前 某个今天(十) 这篇里面提到过,一年多以前我的生活状态是这样的:

七点四十下了公交车,其实是还需要走路十分钟才能达到办公地的,不过这时候我会选择在旁边的公园玩过体育器材。工作两年多以来,我总是在找机会来锻炼身体,虽然运动量都没有多高。夏天的时候,有那么两周,我还曾经尝试过骑共享单车上班,骑行一小时到达单位,也算是锻炼身体了。几乎每天下班之后,从班车上下来,也很少会选择直接坐地铁回家,而是会徒步行走两公里,目的也当然是为了身体。不过,虽然我变着花得玩,但是体重也没有减下去。不过一个结论是,如果没有这平均每天一万步的运动,体重只会更重,身体状况只会更差。

在家的时候,远远达不到一万步的目标,有时候才一两千步。而回到北京,由于工作地点的变化,每天步行的时间也被压缩了。冬天天气太冷,也很少能够骑车了。我于是为了应对这样的变化,还曾经节食过,早上在家吃饭,中午不吃饭,直到晚上再回到家里吃饭,这样的节食效果也并不明显,往往是节食的前两天,能够迅速地降低两三斤,之后就停滞了,稍不注意,就又涨上去了,如此往复。

疫情期间的健身

前不久,看到一个一直比较喜欢的技术博主分享了自己的减肥经验,当时觉得很是矫情,他大概的意思是说,每天可以去计算摄入的卡路里和消耗的卡路里,通过两者相减,来看是否能够减肥,心里面有数,也就能够更好地控制体重了。之所以觉得矫情,就是因为记录卡路里,如实地去记录每一样食物的卡路里,简直麻烦得不要不要的。然而,这次从老家回来之后,加上有隔离的原因,不能随便出门,如果再不注意体重,恐怕体重又会向上攀登了。记录卡路里这件事虽然蛮烦,但好在隔离期间,时间很多,可以充分利用起来。因此,昨天,就是我实践这一计划的第一天了。我是通过薄荷健康这个app来记录每天的卡路里情况,通过keep记录每天的运动情况,这两个配合起来,来进行运动。

我是相信科技能够让人们更好地把控自己的,我买小米秤之后,的确做到了心里有数。我也相信数字的力量,数字能够反映很多问题,这也是我想要实践卡路里减肥法的原因。当然,以后能不能坚持继续下去,可能还是个未知数,毕竟现在略微有些闲,以后会不会忙到没有实践记录这些矫情的东西并不得而知。

20200731

先下结论: 国际化(i18n)和可访问性(a11y) 都是大坑。

首先说一下背景,仍然是一个SAAS应用,它支持多国语言,因此也就需要支持国际化。

前两天也刚好看到一篇文章,讲这个。https://product.hubspot.com/blog/software-internationalization-101-how-to-go-global-without-slowing-down 。 这是公司里的一位资深大佬发过来的文章,看了之后,也的确觉得我们自己做的还有很多得不足。

当前的流程

当前的流程是这样的,首先开发者会根据设计图画前端UI,这个时候会将那些反映在设计图中的文案拿下来,放到我们的一个JSON文件中,例如我们有一个叫做‘copy’的文案,我们就会在这个JSON文件中添加一个key,就叫做’global.copy’,而对应的值就是‘copy’。这里的这个值,是在美国英语环境下的值。

之后,我们将以美国英语作为一个基准,将这个JSON文中中,还没有被翻译的key交到翻译人员手中,翻译人员的职责就是根据这些美国英语下的值,给出对应语言下各个key的值。开发人员将翻译人员给到的最终结果,导入到我们的代码库中,就完成了整个流程。

但是到此为止了吗?其实并没有。由于开发和翻译并不是同时进行的,所以,就会出现开发和测试已经完成,但是翻译的结果却还没有给出来这样的情况。这个时候,我们的做法是优先保证能够上线。这个时候,如果你去看生产环境的话,无论你切换到任何的一种语言,没有被翻译的部分,展示的内容都是你的基准语言,在这里就是美国英语。直到翻译的结果从翻译人员那里给到我们,我们对生产环境再做一次部署,翻译的结果才能够走到线上去。

流程标准化

那么这个流程能否再进一步优化呢?

这篇文章给到了一个很好的思路。可以依靠一个第三方平台去推动翻译工作,翻译不应该是阻塞的。

这篇文章提到可以先由人工智能去做翻译,这样的话,就不会遇到我上面提到的没有翻译的部分用基准语言代替这样的问题了。当然,当翻译结束之后,再将人类翻译的结果发送到生产环境,这也是非常顺滑的。

其他一些坑

翻译的配置是放在前端还是后端呢?

我们自己在实践当中,就发现,经常有一些系统配置级别的文字,出现了没有翻译的问题,而这些问题的产生,就是因为没有搞清楚翻译的配置是放在前端还是后端。 举个例子,我们有一个设置页面,这个页面要从一个下拉菜单中选择出一个需要的设置,而这个下拉菜单的各个选项,又该由前端给出呢?还是后端给出呢?

占位符的问题

一个典型的问题是,如果我们有一个模板,这个模板表示的某人做了某事.这里的某人和某事都是可能发生改变的.

这个时候我们的模板可能是

{0} eat {1}

其中{0}和{1}表示占位符.

我们需要注意的是,有可能在某些语言当中这个模板会被翻译成被动语态.

那么我们就需要确定,当我们在另外一种语言下,它被翻译成了:

{1} afjief {0}

{1} 是否就是我们刚才提到的something,.

我们之前遇到过一个问题,就是前端在处理国际化的时候,没有对颠倒占位符顺序这种情况做出处理.

这是一篇题目已经订好了,一直未曾动笔的文字。我一直想要来系统地记述一下我对于相声的喜爱,之所以未曾动笔,当然也可以说是太忙,也可以说是优先级并没有那么高。

经历

我最早接触相声是从小学一二年级开始的,那个时候,跟着奶奶一起住,奶奶的生活环境并不算好,也没有个电视机能够看电视,只有一个收音机作为娱乐工具,于是我们经常是吃完晚饭之后,躺在床上开始听收音机,我就是从那个时候开始,爱上了相声,当然,其实也会包括评书,那时候也会听评书《鹿鼎记》,《杨家将》等,评书的事情就暂时不提了。

听相声从那个时候开始,坦白说起来,我那个时候还是蛮幸运的,听电台相声,电台是天津电台,天津人在这一点上,不得不服,品味很高,他们会把那些经典的由老演员表演的传统相声拿出来放给听众们听,而不是跟后来某些电视台那样,放一些晚会相声。

但是后来我后来没有再继续跟着奶奶一起单独居住,我回去跟爸妈一块住了。我的身边终于有了一台十几寸的电视机,晚上看电视的时候,想要换台,甚至要光着屁股跑下去,跑到电视机前面,扭动电视机上的按钮,才能够换台。大部分时候,看电视,会比听广播更有意思,可以做出来的节目类型更加多元化了。电视里面也有传统相声,这还是要归功在天津电视台身上,我印象很深,那个时候,天津二套,后来也叫做文艺频道,每天的下午六点左右,都会有半个小时的时间播放相声节目,也都是传统节目,后来了解到,那些节目据说是90年代请一批相声名家录制的经典相声,非常有价值。说句题外话,我也是从那一档节目中,第一次知道了憨豆先生,因为这个节目还有大概两三分钟,会播放《憨豆先生》中的小片段。

不过其实说起来,我当时对于啥是传统相声,啥是新相声,并没有啥区分,只觉得好听就好,所以那个时候,我也会听很多晚会相声,但是其实很有趣,晚会相声往往并不禁听,往往听个几遍就不想再听了,但是传统相声,似乎有一种魔力,能够让你老活听不腻。当然,无论如何,其实在当时那样一个娱乐资源很匮乏的年代,有什么可以听可以看的节目,就饥不择食地去听去看了,其实也未曾真正地去研究过太多。

后来,就是郭德纲的出现,改变了我听相声的很多习惯。我时至今日,还记得那是05年的某一天,我在看电视的时候,看到了电视里面有一个人物访谈节目,访谈的对象就是郭德纲,其中大部分篇幅其实是在讲他的成长经历,他的走红之路,只是顺带手做了个访谈,访谈内容反倒没有多么深刻。我便是从那个时候,开始知道有这么个人。后来,终于郭德纲在06年的新年开办了天津省亲专场演出,天津电视台格外重视,录音录像都很到位,我至今都觉得那是郭德纲的巅峰时期。天津电视台将这些录音录像在电视上反复播放,我终于得以在电视上听到郭的相声。那个时候,对他的某些相声,还有点接受不能,比如《西征梦》,给人一种周星驰无厘头喜剧的感觉,但是慢慢地也觉得还不错,至于郭某人说的传统相声,我大都在那个时候已经听过,可因为他加了很多自己创编地料,而觉得焕然一新,这里面的典型代表是《文章会》和《大保镖》,《文章会》里面的大学问家换成了金庸,也算是与时俱进,暗指的行业工种也从人力车夫(马志明版)换成了摊煎饼的,每每听之,颇为有趣。所以,坦白来说,郭并不是给我听相声启蒙的人,但也的确让我对相声更着迷了。于是在后面的十几年,我听了很多郭的相声,也见识了很多郭的八卦和纠纷,总体来说,都给我的生活提供了很多的乐趣。当然,在后来,我也开始听到很多人,批判最近几年的郭某,没有新的作品,只是玩屎尿屁, 我也的确在最近几年听郭某听的少了,反倒是听德云社高峰的多了。

那些人和那些段子

刘宝瑞

从最早的时候听电台,我就知道刘宝瑞。听他的《连升三级》,《日遭三险》,《珍珠翡翠白玉汤》,《黄蛤蟆》,每一个都非常经典。《珍珠翡翠白玉汤》,《黄蛤蟆》等单口段子,我还曾经给身边的小伙伴讲过,只能说是故事的确是真好,我自己简单讲讲,就已经足够能够吸引他人了。

侯宝林

同样是艺术大师,早期在电台,后来在天津二套都听过很多。他的《关公战秦琼》,《卖布头》至今我都认为是最经典的,没有之一。当然大师毕竟是大师,艺术成就很高 ,也值得。

马三立,马志明

二马还是一起说比较好。马三立先生,小时候听录音其实并不太喜欢,后来随着年龄的增长,才越来越喜欢的。他的《八十一层楼》 ,《逗你玩》,《偏方》这些小段,后来我也给别人讲过。传统的《夸住宅》,至今也认为他老人家的版本应当是最经典的了。至于《卖猴》这种创编节目我印象也很深刻。到了马志明先生这里,则是非常好地继承了父亲地衣钵,我也这也是有马派相声的原因,时至今日,听过最经典的《报菜名》,《大保镖》,《太平歌词》也都是他老人家的版本了。这也难怪,知乎上会有一个问题:郭德纲从马志明那里扒了多少活啊 ,这个问题对错先不用管,至少能够证明马志明先生的确会的多,说得好。当然,抛出去马志明先生那些传统段子,他的《纠纷》,《江米条》也非常好玩,经典,《纠纷》能够在两个人物间随意切换,把握得恰到好处。《江米条》则能够看出来他也能够像他父亲那样,说一些非常好玩的小段。

其他老先生

至今听到最经典的《文章会》出自苏文茂老先生,他被誉为文根大师,老先生前两年作古了,但是作品定会长留人心。听过最经典的《八大吉祥》来自于尹笑声,犹记得当时一个人在收音机前听到这段《八大吉祥》时,充分被里面的情节所吸引,觉得这个事太好玩了。这位先生也是前两年刚刚去世,我也还发过朋友圈悼念之。

年轻演员

郭德纲前面已经提及,不再多说。总体而言,这两三年听他的段子其实很少了,因为他的作品本身也少了很多。但是如果时间轴拉长到十年,听他的段子应该还是非常多的。至今觉得他段子里最经典的还是早期《我要幸福》《西征梦》《打面茶》等描绘小人物生存面貌的作品,如今每每听之,还能会心一笑。

王玥波的相声其实听的并不多,只不过他的评书听的多,在他的评书里面,又总是能够听到很多相声梗,信手拈来,足见得相声功底十足,当初知道他,自然是因为他是郭的早期搭档,想来他应该也很有本事,后来才慢慢了解,喜爱上。高峰,德云社的总教习,擅长传统段子,但是在我看来,似乎也都很中规中矩,听个乐也可以,是奔着老艺术家去的,但是又赶不上老艺术家,偶尔能够听到几个数来宝,快板书,反倒觉得颇为好玩,惊艳到我。邱英俊,据说是当初郭德纲力邀加盟德云社,结果被他拒绝,后来郭某人就编排人家,他现在在体制内是广播电台,电视台的主持人,也很能干,各有所好,也无可厚非,演出的相声作品,对他和于丹表演的《羊上树》,《八大吉祥》印象颇为深刻,以至于一直对他这个人都颇有好感。

向前看

因为相声,我也接触到了很多的其他的艺术形式,比如说《京剧》,《河北梆子》,《评书》,并对他们有了些许的兴趣,以至于后来也能够听两段《空城计》,《四郎探母》,也能够听大段的评书,相声是我很多艺术的启蒙,我很高兴很早我就能够听到相声,让我有了一个快乐的童年,也很高兴,即便是现在参加工作了,仍然能够时不时听听相声,放轻松。作为一个喜欢相声的听众,我也很高兴能够有一个比较喜欢相声的妻子,我们能够一起听相声,乐呵乐呵。

缘起

最近的工作,接触了很多云计算相关的皮毛知识,虽然是皮毛,但也毕竟让我对此多了几分认识。于是就再整理整理思路,写下来吧。

发展历史

曾经有段时间,哪怕是一点都不了解互联网的人,也能够经常听到“云计算”,“大数据”这样的词汇,他们的热门程度,类似于较早之前的“AI”,”VR”,“人工智能”。不过作为一个搞计算机的,“AI”和“VR”其实我一直也从没有能够从技术上应用过他们,以至于一直觉得十分遥远。但”云计算“却随着了解地越来越多,觉得不再那么高山仰止了。

亚马逊应该是最早布局和应用云计算的。他从02年正式发布了AWS,之后这个业务也给他带来了很高的回报,股价一路飙升。后来微软和谷歌也紧随其后,开始布局云计算。国内云计算的发展稍晚了一下,但是也是很牛的。前一段时间,有篇《阿里云的这群疯子》的文章,讲了阿里云从初创到繁荣的历史转变,一时间也刷爆了朋友圈。阿里云诞生自09年,腾讯云诞生自10年,两个巨头也是你争我赶,虽然在我们外人看来已经很牛了吧,但毕竟亚马逊云计算发展的比较早,还是亚马逊的AWS更加给力一点。

发展历史终究只是浮云,对于开发者来说重要的是能够实际应用这些云计算技术,并为自己创造价值。

saas, paas, laas

关于这三者其实网上已经有很多人在科普了,比如我文章下面参考链接里的阮一峰大大。但是我还是想将我的理解表达出来,给自己一个回顾。

saas

按照我的理解,这三种服务面向的群体实际上并不是重合的。

什么是基础设施

我先说说我自己觉得最好理解的,laas,Infrastructure-as-a-service, 也就是基础设施即是服务。那么问题来了,什么是基础设施呢,我们试想假如你已经有了一个好点子,要建立一个面向全国范围内的电商网站,这个网站一旦投入使用,立刻就会成为行业前十,但是你没有太多的投资。这个时候你需要自己在万网或者狗爹(goaddy)买一个域名,如果是面向国内用户的站点,你要对你的域名进行备案,这些过程都还算简单。

接下来你需要买一台服务器,如果你自己有一些特别的需求,你还可以定制你的服务器。有了服务器,有了IP,你需要你所购买的域名能够指向你的IP,你又需要DNS服务

你要给服务器装上系统,装上合适的数据库,之后你的程序能够在你的服务器上面跑起来了。但是即便如此,可能还是会有很多问题,比如为了容灾的需要,你可能有不止一台服务器,比如3台,但是你只能把这3台服务器放在一起,于是面临的第一个问题,那就是你可能只能保证你服务器所在地的访问速度,而其他区域则保证不了访问速度。但是你只是个小的创业者,根本没有能力在全国范围内,搭建多个服务器来满足全国高效的需要。于是你陷入了苦恼,感慨原来创业并不只是”就缺一个程序员了”。

然后你姑且容忍了没有CDN的问题,你考虑到你的站点虽然面向全国,但是一半的用户来自北京,于是你把那几台服务器放到了北京的联通机房。除此之外,你还需要大量时间来做运维,来支持你的服务器的正常运转。我曾经见过公司从服务器选型到网站服务安全稳定运行的整个过程,的确是需要大量的时间成本以及很高的知识储备的。

解决方案

有了需求,接下来就要有人来做了。就拿亚马逊来说,他很早就做成了全美最大的电子商务平台,而他的站点规模,决定了他一定要使用上大规模的服务器,以及应用上CDN等技术。这个时候,亚马逊说,我想把我的空余的服务器租出去,注意,我不是像dell公司那样把服务器买给你再做做售后服务工作那么简单,我是把服务器租给你,如果你愿意的话,我还可以给你一整套的解决方案。也就是说,你服务器上安装的数据库也可以从我这里来租,数据库的配置我都可以预先给你配置好,保证是一个最佳实践,你无须再为此付出大量时间精力。

我也可以把我自己成熟的CDN技术分享给你,让你的网站也能够无论在哪里,都能够有一个很快速的访问速度。如果你的网站上有大量的多媒体资源(图片,视频等等),你也可以把这些多媒体资源存放在我这里。我保证,你的多媒体资源的访问速度,与我们亚马逊自己的多媒体资源访问速度相当。凡此种种,还有很多。由此,其实我们不难看出来,当今互联网以及计算机发展的一大潮流,就是从原来的购买转变为后来的租用,类似的情况,单就美国来说,还有租用影片的netflix, 以及微软的office虽然也在卖,但也有更多的用户选择了office365。

租用的好处与坏处

让我们暂时岔开一下话题,聊一聊究竟这种租用的方式能够带来哪些好处呢?为了不岔开得太远,我们还是以云计算服务为例,我们来算一笔帐,假设一家小公司初创,为了自己的网站能够安全稳定的上线,他需要服务器以及上面提到的一套解决方案,他为此要付出很大的成本,而又由于是初创企业,自己无法准确估计自己的需求,可能最后买到了合适的服务器,以及应用上了一套解决方案,一旦业务突飞猛进,他又要对此进行升级,相应地,又要花费大量的时间人力成本。而租用的方式,则是能够在一定规模内,实现付出最小,利益最大。当然,我也说到了是一定规模内,我们看到公司一旦达到了一定规模,租用的成本要远远大于直接买的方式,因此我们也看到像dropbox就离放弃了AWS转而自建基础设施和网路。

都有哪些基础设施

为了方便,我们这次把视线瞄准国内,看看阿里云是怎么做的。下图是阿里云的产品一览

阿里云产品一览

我们也可以看到,就我们刚才所说的例子来看,用到了弹性计算(云服务器)、存储服务(oss等)、CDN技术以及数据库这些基础设施。阿里云将这些服务拆分成一个个的产品进行出售,我们可以根据自己的需要进行量身定制。

感兴趣的同学,可以通过参考链接,进入阿里云的观望去瞅一瞅。

laas 的好处

所以回过头来再来看云计算中的laas,能够看到他是有很大的优势的。主要表现在:

  • 租用的方式能够让付出最少,收益最大。前面已经提到过
  • 快速完成基础设施的应用,专注业务核心
  • 运维成本降到最低

saas

软件即服务

这个其实按照我的理解,并没有laas复杂。想对于laas而言,我认为主要区别在于:

对于购买laas的使用者,他对于在基础设施之上所搭建起来的应用程序有非常高度的掌控权,毕竟laas只是提供了基础设施的服务,真正的应用程序,还是需要自己来开发。但是saas则并非如此,他聚焦在了更高的层次上,直接为你提供了应用程序,因此你对应用程序本身的掌控力非常差,如果让我举一个例子的话,我会说当今很流行的微商城服务,比如微盟,你通过购买他的这个微商城服务,然后再在自己的微信公众号后台进行一些简单的配置,可以快速地建立起一个微商城来,如果你有需要,当然也可以快速完成微信小程序的创建。相比laas而言, 这种方式更加高效了。只是,会更加受制于人。他有点像是曾经经常被讨论的自有商城和天猫店铺的区别,在这里就不再多做阐述了。

paas

paas,也就是“平台即服务”,我接触的比较少,也就简单说一下我的理解。我自己用过的是,2013年左右的GAE,当时通过一些简单的配置,完成了一个应用,也就是goagent的开发(相信经历过那个年代科学上网的朋友,对此定会不陌生)。为了写这篇文,我也找到了一篇2014年其他人的博文,介绍goagent的原理,感兴趣的朋友,可以通过参考链接过去看看。我用goagent 的时候,还对云计算这一块毫无所知,完全是根据网上的傻瓜教程来搭建服务的。现在会过头来看,就像是阮一峰博文中所述的那样,paas是正好介于laas与saas之间的一种服务

阮一峰博文图片

还就goagent所使用的GAE为例,他并不只是给你基础设施,他也给了你一个应用程序所必须的环境(在这里是python环境),他也不同于saas,他没有给你一个完整的软件服务,让你直接就能够使用,他还是要让你自己来写程序,来实现某些功能的。其实写到这里,我又想起了当年玩贴吧的时候,也有朋友基于百度的BAE(与GAE类似),实现了百度贴吧的自动签订功能,当时依然觉得有趣,也仍不知所言。只是照猫画虎,但这照猫画虎,却让我对计算机有了更深的兴趣。

综述

其实说起来,我最早用的云服务是个人服务,百度云。后来,又用了很多其他的个人云服务,我早在4年多以前,我就说过要构建一个个人云端信息库。我就表态过,自己对于“云”这件事很乐观。我想既然2c是这样的,2b也应该不无例外。包括前面我的许多分析,也都表明,我自己是支持云计算的,即便从社会分工的角度来说,让专业的人做专业的事,这件事,从来也没有错。

标题说的个人工作实践指所见到的公司从服务器选型到网站服务安全稳定运行的整个过程,准备上云计算的过程,使用微盟微商城的体验,使用goagent的体验等等。

参考链接

前面

作为一面全栈工程师(偏重前端),对待老大交代下来的后端任务也是需要认真完成的。前段时间,有个工作,要通过淘宝的OAUTH进行授权,进而获取到access_token,通过access_token来作为授权码,进行所有需要登录权限的API访问,这些API 包括但不限于用户,商品,交易,评价,物流等API.

过程

在这里也无须去科普OAUTH2.0协议到底是什么了,感兴趣的可以自己去查wiki.

我来说的仍然是我自己的理解,所以OAUTH到底做了什么呢?它是一直验证机制,这个机制实现了两步验证,仍然以淘宝API获取access_token为例,淘宝认为开发者访问用户的信息,是以应用为单位的,每一个应用需要一个app_id,app_secret,我们是先要通过app_id 来置换到一个叫做code的字段,这个字段只是作为一个过渡,我们能够通过code值,再调取一个api,才能够最终获取到access_token.

拿实际例子来说,

、授权操作步骤

    此处以正式环境获取acccess_token为例说明,如果是沙箱环境测试,需将请求入口地址等相关数据换成沙箱对应入口地址,操作流程则同正式环境一致。
    实际进行授权操作时,测试的数据 client_id、client_secret、redirect_uri 均需要根据自己创建的应用实际数据给予替换,不能拿示例中给出的值直接进行测试,以免影响实际测试效果。下图为Server-side flow 授权方式流程图,以下按流程图逐步说明。
授权步骤

1)拼接授权url
拼接用户授权需访问url ,示例及参数说明如下:
https://oauth.taobao.com/authorize?response_type=code&client_id=23075594&redirect_uri=http://www.oauth.net/2/&state=1212&view=web

参数说明
名称
client_id
response_type
redirect_uri
state
view

2)引导用户登录授权
引导用户通过浏览器访问以上授权url,将弹出如下登录页面。用户输入账号、密码点“登录”按钮,即可进入授权页面。
授权

3)获取code
上图页面,若用户点“授权”按钮后,TOP会将授权码code 返回到了回调地址上,应用可以获取并使用该code去换取access_token;
若用户未点授权而是点了“取消”按钮,则返回如下结果,其中error为错误码,error_description为错误描述。分别如下图所示:错误

4)换取access_token

方式1(推荐):

通过taobao.top.auth.token.create api接口获取access_token(授权令牌)。api服务地址参考http://open.taobao.com/docs/doc.htm?docType=1&articleId=101617&treeId=1

最后

说起来,我最早使用OAUTH进行登录或者授权操作,还是早些年在用微博的时候,如果OAUTH的应用已经非常广泛了,了解它对我们,无论前端开发还是后端开发都有很多好处.

参考链接

http://open.taobao.com/doc.htm?docId=102635&docType=1

http://open.taobao.com/api.htm?docId=285&docType=2

需求

##1希望能够让开发者写代码更轻松

以往没有引入postcss autoprefixer之前,我们为了css相关特性能够在各个浏览器上的兼容,引入了scss,利用它的mixins来实现prefix。但是每一个mixin 都有一个自己的语法。

比如以往,如果我们我们想要写一条

div {
    display: flex;
    align-items: center;
    justify-content: center;
}

为了各个相对早期浏览器的prefix,我们需要mixin,然后这样写

import 'common/flexbox';

div {
    @include flexbox;
    @flex(1);
    @justify-content(center);
}

然后按照这样的约定,来加上需要的prefix。

这当然是一个方法,但是对于开发者来讲,实际上增加了一些学习成本,而且相当于将标准放到了一边,去使用另外一套标准。

我们之前的mixin,由于已经有好几年的历史。当时为了兼容市面上那些还有很大市场份额的浏览器,prefix写的很全。比如下面这个mixin flexbox到代码:

@mixin flexbox {
    display: -webkit-box;
    display: -webkit-flex;
    display: -moz-flex;
    display: -ms-flexbox;
    display: flex;
}

为了写这篇博客,我又确认了一下,那个mixin flexbox的开源库来自于2013年,距离现在已经五年了,五年的时间,淘汰了很多过时的浏览器,五年前可能需要兼容到ie8,现在移动端开发甚至完全可以无需理睬IE的存在,所以这样的一套prefix就显得有些过时了。那位说了,我更新我的mixin不就好了,比如在2018年做移动端开发,也许我只需要将上面的代码改写成:

@mixin flexbox {
    display: -webkit-flex;
    display: flex;
}

但是我们也许需要想地更远一些,也许再过两年,我们甚至不需要对-webkit-的支持了。那时候,难道我们又要改一遍这个mixin吗?

postcss解决了这样一个痛点,可以直接书写标准的css(现在是css3,但是过几年也可能就是css4了),我们有了这样的工具,再指定一个浏览器兼容表,就能够实现自动prefix,而这相比于sass/scss mixin的方式,维护起来更加简单,应该是一个很好的实践。

2对用户更友好

这当然也是显而易见的,以前我们可能为了兼容更多浏览器,而写更多的prefix,可是随着时间的推移,很多prefix完全并不需要。我们通过postcss来处理,简单明了,缩小了生成的css文件的体积,最后反映到用户那里,会快上一丢丢!

步骤

1 安装postcss-loader ,postcss-preset-env

yarn add -D postcss-loader  postcss-preset-env

安装postcss-preset-env,无需再安装autoprefixer,由于postcss-preset-env已经内置了相关功能。

2 添加.browserlistrc 文件到项目根目录

1% in CN
android >= 4.4
ios >= 8
not ie <= 11

这个需要根据项目的世纪情况来自由选择,我是考虑我们的项目是移动端项目,且确实有用户在用Android4.4 或者ios8,但是再很难看到低于这些版本之下的系统了。

3配置postcss.config.js

module.exports = {
  loader: 'postcss-loader',  
  plugins: {
      'postcss-preset-env': {},
    }
}

4 配置webpack.config.js

{
test: /\.scss$/,
use:[ 
    MiniCssExtractPlugin.loader,
    {
        loader: 'css-loader',
            options: {
                root: 'static',
                minimize: true,
                importLoaders: 1
            }
    },
    'postcss-loader',
    'sass-loader',
]
},
{
test: /\.css$/,
use: [
    MiniCssExtractPlugin.loader,
    {
        loader: 'css-loader',
            options: {
                root: 'static',
                minimize: true,
                importLoaders: 1
            }
    },
    'postcss-loader'
]
}

由于我们的项目中使用了scss,因此需要sass-loader。这里需要注意各个loader的顺序,一开始我的顺序是MiniCssExtractPlugin.loader,css-loader,sass-loader, postcss-loader,结果发现并没有能够autoprefix,原因是如果想让postcss-loader认识并且处理,需要先用sass-loader进行处理,转化成postcss-loader可以认识的代码。

另外需要注意的是,我们这里还在使用css-loader v0.28,目前已经有了v1.0,版本改动很大,以至于我们暂时不能升级。

熟悉前端开发的朋友,应该对 Babel这个项目并不陌生,早在两年多以前,阮一峰大大就已经写过文章《Babel 入门教程》 对他进行了介绍,那个时候,其实Babel应该已经算得上是网红开源前端库了。这两年,Babel其实也一直在发展,我这里想说的是我看到的Babel的成长

babel-preset-env

首先是babel-preset-env,详细的介绍文档在这里:https://www.babeljs.cn/docs/plugins/preset-env/

我也并不会去介绍怎么去用这个,只是想谈谈自己的体会。我记得刚开始使用babel的时候,的确有时候会用上一些stage-2,stage-3 的特性,那时候还为了了解这些所谓的stage去看了ECMASCRIPT 新版本发布的流程,觉得也很有意思。但是虽然有意思,但是配置起来却的确繁琐,有时候,你的确需要为了配置这样一个Babel看好多相关文档,这无疑算是一个痛点了。现在好了,就如同文档里面所提到的:

在没有任何配置选项的情况下,babel-preset-env 与 babel-preset-latest(或者babel-preset-es2015,babel-preset-es2016和babel-preset-es2017一起)的行为完全相同。

babel-polyfill

为什么你这么大

我们都知道,Babel为了存心让我们配置起来更困难,故意将他的功能分拆成了两部分,其一是语法上的转化,这个默认情况下他自会帮我们处理。而另外一部分,就是新API的polyfill,需要我们引入babel-polyfill来完成。当然,我前面说,Babel是存心折腾开发者的确是开玩笑的,毕竟并不是所有的时候我们都需要polyfill的。这有点像是React项目也有两个核心包,ReactReactDOM类似。

    import React from 'react';  
    import ReactDOM from 'react-dom';

babel-polyfill是好东西,能够将新API作用在老的浏览器上,但是我们要注意不要滥用。比如我们随便在百度上搜索一篇文章,讲解如何使用 babel-polyfill的引用和使用,往往都会看到有这样的描述:

module.exports = {entry: ["babel-polyfill", "./app/js"]};

这样做,从功能实现上来看当然是没有错的。但是,如果我们原来的入口是

module.exports = {entry: ["./app/js"]};

那么很容易就能够发现由于入口处增加了babel-polyfill,导致webpack在处理之后,最终的到的入口核心js文件比原来增加了有100kb左右。对于这个问题,也已经有issue,不过很奇怪这位网友把issue提到了babel-loader这个项目下。

然后针对这个问题,有老外网友介绍到了transform-runtime等。但是经过我的测试,这也并不是一个很好的实践。

动态识别

为了polyfill 这件事情,其实是有两种思路可循的。第一个思路是根据浏览器缺失哪些特性来补全哪些特性,这个思路的代表是 polyfill-service,这个项目 。它能够根据浏览器的UA来判断当前浏览器缺失哪些特性,进而进行补强。但是经过我的调研,这个项目在天朝可能还存在水土不服的问题,一个很明显的事实是将安卓微信内置的QQ浏览器X5交给这个库来处理,它会认为当前的浏览器是safari,原因大概是因为UA上有safari这个字段。考虑到我们天朝还有类似微信这样很怪异的UA,我认为并不适合在当前这个时间来对此进行实践。(在这里多说两句,polyfill-service这个库和另外一个知名项目fastclick同属于英国金融时报,而最近我发现fastclick在现代浏览器上也有一些tricky的地方,在他们的issue区有能够找到一些吐槽,然而,这个库已经两年多没有人维护了)

把polyfill-service仍在一边,我们接下来说另一个思路。能不能根据我使用了多少新API,来决定我引入多少polyfill的内容呢?比如我只在我的项目中使用了ES6的set,没有使用其他新API。那么我引入polyfill的时候,能不能只引入set的polyfill呢?答案当然是可以的,这就是babel-7的新特性,没错,由于当前稳定版是babel-6,因此这个特性还处在测试阶段。但是根据我自己的测试,表现很多。

不过有趣的是,虽然还只是Beta版,Babel却将之写入了正式版的文档当中,结果当时我为了测试这个新特性,都已经测试到怀疑人生了。文档戳这里,感兴趣的同学可以去看看。总之,实际上只是对babel增加一项配置。

      "useBuiltIns": "usage"

不过由于涉及到升级Babel,当时我在测试的时候,还是有些不顺的。但是一旦迁移成功,应用上useBuiltIns的这项配置,的确能够让polyfill的体积大幅度减小。

browserlist

前面的动态polyfill,的确可以让webpack生成的js文件体积更小,但是能不能再小一些呢?毕竟我们前端开发的目的就是极致的用户体验,当然可以。这个时候browserlist能够帮到我们。

关于这个话题,网路上相关的文章非常多,我就不再多谈了。

感兴趣的同学,可以看看ant-design项目中使用的browserlist。

https://github.com/ant-design/antd-tools/blob/master/lib/getBabelCommonConfig.js