0%

简介

之前读了《创新者》一书,作者是著名的传记作家艾萨克森。这本书通过描绘数字时代大气磅礴的创新图景,阐释了互联网的核心精神,让我们能够好地理解这个互联互通的美丽新世界。这些拥有不羁创意的先锋者、黑客、天才、企业家们,并不是孤立的存在,他们甚至通过跨越世代的合作,不断创造出科技与人文融合的奇迹——这正是数字时代的气质。

这篇文章谈谈读后的感受,原文在两年前写完,整理在这里。

创新者

亚当斯密在其《国富论》中开篇就有如下论述:“劳动生产力上最大的增进,以及运用劳动时所表现的更大的熟练、技巧和判断力,似乎都是分工的结果”。分工的动机,源于人类互通有无,物物交换,互相交易的倾向。从传统的制造业到时下前沿的计算机硬件、互联网行业,都离不开分工带来的高效率,高产出以及持续不断的创新。这让我体会到创新不仅仅是有好的idea这么简单,个人的才能与团队的合作都会显著影响创新的进程。读了《创新者》一书的前几章,这种体会愈发深刻。

这本书以计算机产业的发展为主线,阐述了每一阶段的科学家和工程师们是如何提出并实现他们天才的创新点的。无论是哪一项发明,都少不了聪明绝顶和天赋异禀的个人,但作者认为,在肯定这些人的贡献的同时,我们不应该忽略团队分工与合作所起到的关键作用。提出想法只是一个创新的开始,接下来往往需要一个专业的团队通力合作,才能使停留在理论空中的创新思想落地,发挥它巨大的价值。以晶体管的发明为例,这个过程需要能够敏锐洞察量子现象的理论家,擅长提取大批纯净硅晶体的材料科学家,以及心灵手巧的实验家,工业化学家,制造专家和熟练的工匠。想要集这些本领于一身是基本不可能的,即便有这样的天才,也未必有这么多精力。我想这也是为什么现在软件开发项目通常是一个团队,创新不分大小,实现目标的方法论是类似的。

阅读全文 »

引言

本文是《持续交付》一书学习总结的第四篇。主要内容涉及部署发布和基础架构管理的实践。

持续交付

部署和发布(一)

这次我们来看看软件持续交付的最后一个步骤:部署和发布。

在项目开始的时候,我们就要想好软件最终发布时要面临的问题,以此制定发布计划和策略。要考虑的问题包括但不限于:

  1. 确定部署需要的技术。比如基于Azure平台的应用,部署时就需要微软的Powershell脚本来实现自动化。
  2. 如何实现部署流水线。
  3. 监控应用程序的技术和策略。有了这些信息可以帮助我们掌握API等服务的实时状态。
  4. 与外界系统的集成。应用程序可能访问第三方的外部系统,这些在部署时需要考虑得当。
  5. 灾难恢复计划。一旦应用程序出现宕机等灾难情况,要有应急的计划。
  6. 问题修复和补丁的策略。
  7. 软件的升级和更新策略。
  8. 如何回退到某个历史版本。
  9. 如何对部署的环境进行冒烟测试。
阅读全文 »

引言

本文是《持续交付》一书学习总结的第三篇。主要内容涉及部署流线和部署脚本的设计实践。

持续交付

部署流水线(一)

要实现持续交付,一般会定义一条部署流水线(deployment pipeline)。我们之前讨论过的持续集成过程,就是这个流水线的一部分。总的来说,部署流水线就是一套将代码从版本控制工具最终交付到用户手中的自动化流程。我们在前面看到了自动化的持续集成,以及验收测试。除此之外,部署流水线还包含在流程各个阶段(开发、测试、发布等)对软件的部署以及发布流程的管理。可以说,《持续交付》整本书都在围绕部署流水线进行讨论。

部署流水线的第一个好处我们多次提到过,就是基于自动化的快速反馈,如下图。在部署流水线的每一个阶段都能形成及时的反馈,让团队合作解决问题。经过多次反馈,到发布阶段时的软件质量是很高的。

反馈

阅读全文 »

引言

本文是《持续交付》一书学习总结的第二篇。主要内容涉及持续集成以及持续交付中的测试实践。

持续交付

持续集成(一)

关于持续集成(CI),我想程序员朋友都很熟悉了,现在很少有项目不采用持续集成了。我们来看一下其中的原则和实践。

持续集成要达到的目的是,每当有开发者提交了改动,整个应用程序需要重新构建,并运行足够广泛的测试来保证质量,以使得应用程序始终处于能够正常工作的状态。一个典型的CI过程如图所示。

持续集成

要想达到目标,需要几个前提条件。首先就是代码的版本控制,这一点已经不止一次被作者提到。版本控制的好处在前面已经分享过,没有版本控制,持续集成就很难顺利进行。然后就是自动化构建,这里的自动化指的是利用专业CI工具,将持续集成的过程自动化,而不要试图自己实现。常见的持续集成工具有开源的Jenkins,和付费的TeamCity等。最后就是整个团队要CI的意识,比如代码要及时提交,CI过程发现错误,要及时修正,不能把CI的过程当作摆设。

下面分享一些持续集成实践的关键点。

阅读全文 »

引言

最近一段时间阅读了《持续交付》这本书,打算用几篇文章的篇幅总结一下阅读的收获。此为第一篇。我看的是英文原版的,书名是 Continuous Delivery,作者是 Jez Humble,由人民邮电出版社出版。

持续交付

概念:持续交付

软件交付,就是软件从源代码形态到最终形成可交付的软件产品,并发布给用户的过程。那持续交付(Continuous Delivery)是什么意思呢?你可能听过持续集成(CI, Continuous Integration)和持续部署(Continuous Deployment) 等概念,这些概念和流程已经在业界广泛使用。以我的理解,这里的“持续”是一种结果,我们为了达到某种目的而“持续”,满足了某些条件的软件交付操作和行为,就是持续交付。那么为了达到什么目的呢?这就是:

以有效的、快速的和可靠的方式交付高质量、有价值的软件产品

这是《持续集成》这本书中总结的目标,简单的一句话内涵比较丰富,可以说整本书都是围绕如何达到这个目标而展开。

那如何到达上述目标呢?只要做好两点:1. 自动化 2. 频繁发布

阅读全文 »

标题:Angular Service 变更检测探究

作者:jtzcode

上次更新:2019年11月05日


引言

使用过现代JavaScript框架的开发者,都应该熟悉绑定(binding)的概念。绑定通常有两个方向。一是由用户交互驱动,在浏览器的页面上发生了输入、点击操作,导致应用程序的状态发生改变,这些改变需要反映到程序中特定变量上。另一个方向是,JavaScript代码的业务逻辑中改变了程序的状态,比如通过API请求拿到新的数据,而这些状态也需要反映的页面的控件上。很多框架如AngularJS就实现了双向绑定机制。

下面我们来看上述第二种绑定,即程序状态从业务代码到前端页面的传递过程。如果沃恩自己去实现应该怎么做呢?最直观的想法是:在恰当的时候对程序中的变量表达式进行求值,看看它是否与原来的值相同。如果不同,则把新的值写入与页面渲染相关的对象中。这里面检查变量表达式的值是否变化的过程就是所谓的变更检测(change detection)。Angular就是采用变更检测实现绑定的。下面我们具体来看。

基本原理

程序状态变化的来源有以下几种,首先是响应用户在UI上的操作,比如用户点击了一个按钮,改变了某个变量的值。然后是浏览器的异步事件,比如setTimeout的回调函数,改变了某个变量。最后是应用程序中的异步事件,比如API返回的Promise或者Observable对象在Resolve时,改变了变量的值。那么Angular是如何知道这些状态的改变呢?

阅读全文 »

标题:Angular Service 单例问题探究

作者:jtzcode

上次更新:2019年10月12日


引言

Angular Service是一种实现代码抽象的方式。它可以帮助我们将业务逻辑从页面的呈现逻辑中分离出来,以保持Component功能的纯净,以及某些常见功能的重用。一些开发者认为Component应该只处理页面呈现以及用户交互方面的逻辑,其他的都应该抽象到service中,即所谓的Lean Angular Component思想。

我们在使用Angular Service时会有这种场景:有一个变量的状态是全局有效的,在不同的Component中都可能修改这个状态值,并且每个Component中都可以拿到这个Service中该状态变量的最新值。为了实现这个场景,一个最关键的点就是,Service必须是单例的。因为一旦有多个实例,那么每个Component看到的状态变量的值就不一致了。这篇文章就来试图探讨一下,什么情况下Angular Service会产生多个实例,以及如何解决这个问题。

Angular的官方文档关于单例Service的话题有不错的讨论。除了这篇文章,本文还参考了其他讨论类似话题的文章,再结合了自己的理解。欢迎批评和讨论。

什么时候会有多个实例?

总的来说在两种情况下,Angular会生成多实例的Service:

  • 声明Service的共享Module被多个其他Module导入

  • 声明Service的共享Module被其他lazy-load的Module导入

这两种情况看起来比较类似,但其实背后的原理有些不同,我们分别来看。

阅读全文 »

本文原载于https://jrsinclair.com/articles/2019/what-is-a-higher-order-function-and-why-should-anyone-care/
作者:James Sinclare
原文标题: What Are Higher-Order Functions, and Why Should You Care?

James Sinclare写于2019年7月2日


高阶函数(high-order function)是一个被人们反复提及却经常被误用的概念,但是人们从未放弃过解释它的含义。也许你已经知道什么是高阶函数了,但我们如何在现实场景中使用它呢?有没有一些实际的例子能说明如何以及何时该使用高阶函数?我们能使用它操作DOM吗?或者,那些使用高阶函数的人只是在炫耀?他们有没有为此给代码引入不必要的复杂性?

我认为高阶函数是很有用的。事实上,我觉得它是JavaScript这门语言最重要的特性之一。但我们在解释它为何重要之前,先来看看什么是高阶函数。为了解释这个概念,我们从函数变量(functions as variables)开始。

作为一等公民的函数

在JavaScript中,我们至少有三种方式定义一个函数(注释1)。首先我们可以写一个函数声明(function declaration),例如:

1
2
3
4
5
6
// Take a DOM element and wrap it in a list item element.
function itemise(el) {
const li = document.createElement('li');
li.appendChild(el);
return li;
}

我希望你已经熟悉这种写法了,但你很可能还知道函数表达式(function expression)的写法,就像这样:

1
2
3
4
5
const itemise = function(el) {
const li = document.createElement('li');
li.appendChild(el);
return li;
}

还有另外一种写法就是箭头函数(arrow function)了:

1
2
3
4
5
const itemise = (el) => {
const li = document.createElement('li');
li.appendChild(el);
return li;
}

对我们来说,这三种写法本质上是相同的(注释2)。但是请注意,在后两个例子中函数被赋值给了变量,看起来是件小事,为什么不这么做呢?而事实上,这至关重要。

阅读全文 »

本文原载于: https://www.robinwieruch.de/web-components-tutorial/
作者:Robin Wieruch
原文标题:Web Components Tutorial for Beginners [2019]


前言

译者注:Web Component可以译为Web组件,不过也可以不翻译,从业者都能看懂,故后面译文都保留原词。

在这个教程中你能够学到,如何构建第一个Web Component,以及如何将其运用在你的Web应用中。在我们开始前,先花点时间总体上了解下Web Component。近年来,Web Components,也称为自定义元素(Custom Elements),已经成为一些浏览器的标准API(参考这里),它让开发者能仅仅使用HTML,CSS,和JavaScript实现可重用的组件,而不需要依赖主流的前端框架如React,Angular和Vue。具体来说,自定义元素将页面的结构(HTML),样式(CSS)以及行为(JavaScript)封装为一个自定义HTML元素。例如,下面代码片段是一个HTML下拉列表组件的例子:

1
2
3
4
5
<my-dropdown
label="Dropdown"
option="option2"
options='{ "option1": { "label": "Option 1" }, "option2": { "label": "Option 2" } }'
></my-dropdown>

在本教程中,我们将使用Web Component从头实现一个下拉列表组件。然后你可以在自己的应用或者其他地方重用这个组件,甚至可以在一些框架中使用,比如React(参考这里)。

为什么需要Web Components?

这里通过一个个人案例来解释Web Components的益处:不同职能的开发团队需要基于一个样式指南(Style Guide)创建一个UI库,但是有两个团队在实现组件时候采用了各自不同的框架:React和Angular。尽管两种实现都遵循样式指南,且组件的结构(HTML)和样式(CSS)上基本相同,但是组件的行为(比如,打开/收起下拉列表,选择列表的一项)是依据各自框架下的JavaScript的逻辑实现的。另外,一旦样式指南中有关于组件样式或行为的错误,每个团队会独立地修复这些问题,且并不一定能保证向后兼容。很快,两个团队的UI库就会在外观和行为上产生分歧。

阅读全文 »

文章计划

这个博客主要有两个主题,一个是技术,另一个是思考。前者是日常工作和学习的开发经验总结;后者是日常读书和思考的收获总结。敬请关注。

《Angular Service单例问题探究》

《Angular变更检测探究》

《Angular启动机制探究》

《Angular依赖注入探究》

《认知的缺陷(上)》

《认知的缺陷(中)》

《认知的缺陷(下)》

《认知的规律》

《创新者的启示》

《生命3.0》读后

《王阳明——一切心法》读后

《5分钟理解期货》

《持续交付学习笔记(一)》

《持续交付学习笔记(二)》

《持续交付学习笔记(三)》

《持续交付学习笔记(四)》

《持续交付学习笔记(五)》

《持续交付学习笔记——总结》