上下文

引言 又是一年寒冬季，只身前往沿海工作，也是我第一次感受到沿海城市冬天的寒冷。刚过完金九银十，经过一场惨烈的江湖厮杀后，相信有很多小伙伴儿已经找到了自己心仪的工作，也有的正在找工作的途中。考虑到年后必定又是一场不可避免的厮杀，这里提前记录一下自己平时遇到和总结的一些知识点，自己巩固复习加强基础的同时也希望能在你的江湖路上对你有所帮助。笔者在入职最近这家公司之前也曾有过长达3个月的闭关修炼期，期间查阅资料无数，阅读过很多文章，但总结下来真正让你印象深刻的，不是那些前沿充满神秘感的新技术，也不是为了提升代码逼格的奇淫巧技，而是那些我们经常由于项目周期紧而容易忽略的基础知识。 所谓万丈高楼平地起，只有你的地基打得足够牢固，你才有搭建万丈高楼的底气，你才能在你的前端人生路上越走越远 。 这篇主要是先总结一下CSS相关的知识点，可能某些部分不会涉及到太多具体的细节，主要是对知识点做一下汇总，如果有兴趣或者有疑惑的话可以自行百度查阅下相关资料或者在下方评论区留言讨论，后续文章再继续总结JS和其他方面相关的知识点，如有不对的地方还请指出。 1. CSS盒模型 CSS盒模型就是在网页设计中经常用到的CSS技术所使用的一种思维模型。CSS 假定所有的HTML 文档元素都生成了一个描述该元素在HTML文档布局中所占空间的矩形元素框，可以形象地将其看作是一个盒子。CSS 围绕这些盒子产生了一种“盒子模型

Dockerfile 定制镜像 从刚才的 docker commit 的学习中，我们可以了解到，镜像的定制实际上就是定制每一层所添加的配置、文件。如果我们可以把每一层修改、安装、构建、操作的命令都写入一个脚本，用这个脚本来构建、定制镜像，那么之前提及的无法重复的问题、镜像构建透明性的问题、体积的问题就都会解决。这个脚本就是 Dockerfile。 Dockerfile 是一个文本文件，其内包含了一条条的指令(Instruction)，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。 还以之前定制 nginx 镜像为例，这次我们使用 Dockerfile 来定制。 在一个空白目录中，建立一个文本文件，并命名为 Dockerfile： $ mkdir mynginx $ cd mynginx $ touch Dockerfile 其内容为： FROM nginx RUN echo ' Hello, Docker! ' > /usr/share/nginx/html/index.html 这个 Dockerfile 很简单，一共就两行。涉及到了两条指令，FROM 和 RUN。 FROM 指定基础镜像 所谓定制镜像，那一定是以一个镜像为基础，在其上进行定制。就像我们之前运行了一个 nginx 镜像的容器，再进行修改一样，基础镜像是必须指定的。而 FROM

壹 ❀ 引 我觉得每一位JavaScript工作者都无法避免与闭包打交道，就算在实际开发中不使用但面试中被问及也是常态了。就我而言对于闭包的理解仅止步于一些概念，看到相关代码我知道这是个闭包，但闭包能解决哪些问题场景我了解的并不多，这也是我想整理一篇闭包的原因。我们来看一段代码，很明显这是一个闭包，那么请问闭包指代的是下方代码中的哪一部分呢？本文开始。 function outer() { let name = '听风是风'; function insider() { console.log(`欢迎来到${name}的博客`); }; return insider; }; outer()(); //欢迎来到听风是风的博客 贰 ❀ 什么是闭包？ 如果在面试中被问及什么是闭包，大部分情况下得到的答复是（至少我以前是） A函数嵌套B函数，B函数使用了A函数的内部变量，且A函数返回B函数，这就是闭包 。 这段描述当然没问题，那么为了让下次面试回答的更为漂亮，就让我们从更专业的角度重新认识闭包。 1.闭包起源 闭包翻译自英文单词 closure ([ˈkloʊʒər] 倒闭，关闭，停业) ，闭包的概念最早出现在1964 年的学术期刊 《The Computer Journal》 上，由 P. J. Landin 在 《 The mechanical evaluation of

第十五章 使用Canvas绘图 HTML5添加的<canvas>元素负责在页面中设定一个区域，然后就可以通过JavaScript动态地在这个区域中绘制图形。 如：<canvas id="drawing" width=" 200" height="200">A drawing of something.</canvas> 在使用<canvas>元素之前，首先要检测getContext()方法是否存在，这一步非常重要。有些浏览器会为HTML规范之外的元素创建默认的HTML元素对象。在这种情况下，即使 drawing 变量中保存着一个有效的元素引用，也检测不到 getContext()方法。 一、使用2D上下文 使用2D绘图上下文提供的方法，可以绘制简单的2D图形，比如矩形、弧线和路径。2D上下文的坐标开始于<canvas>元素的左上角，原点坐标是(0,0)。所有坐标值都基于这个原点计算，x值越大表示越靠右，y值越大表示越靠下。默认情况下，width和height表示水平和垂直两个方向上可用的像素数目。 1、填充和描边 填充和描边两个操作取决于两个属性：fillStyle 和 strokeStyle。这两个属性的值可以是字符串、渐变对象或模式对象，而且它们的默认值都是"#000000"。 2、绘制矩形 与矩形有关的方法包括 fillRect()、 strokeRect()和

Flask上下文管理机制 可以从三个大的方面来探讨flask的两大上下文管理机制 方面一：请求进来时 方面二：视图函数 方面三：请求结束前 请求进来时 触发执行__call__方法，__call__方法的逻辑很简单，直接执行wsgi_app方法，将包含所有请求相关数据和一个响应函数传进去。2019-11-23 def application(environ, start_response): start_response('200 OK', [('Content-Type', 'text/html')]) return '<h1>Hello, web!</h1>' 上面的application()函数就是符合WSGI标准的一个HTTP处理函数，它接收两个参数： environ：一个包含所有HTTP请求信息的dict对象； start_response：一个发送HTTP响应的函数。 在application()函数中，调用： start_response('200 OK', [('Content-Type', 'text/html')]) 符合wsgi协议标准的函数 　　备注：__call__是一个符合wsgi标准的函数 执行wsgi_app方法 def wsgi_app(self, environ, start_response): ctx = self.request

上下文是算法的运行环境。 上下文是一个状态气泡，算法的每一步都从这个气泡中存取信息。 上下文的设计是变量和数据结构的设计。 上下文的分类： 1、全局上下文； 2、分步上下文：逻辑块或子函数上下文。 3、计算上下文； 算法的每一步，每一个逻辑都有上下文。 上下文包含：输入、输出、临时变量等。 上下文设计是算法设计的重要部分。 来源： https://www.cnblogs.com/feng9exe/p/11913467.html

上下文管理 文件IO操作可以对文件对象使用上下文管理，使用with……as语法。 with open("test") as f: pass 仿照上例写一个自己的类，实现上下文管理。 class Point: pass with Point() as p: pass 结果为： --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) <ipython-input-1-77f0ac1b02c7> in <module> 2 pass 3 ----> 4 with Point() as p: 5 pass AttributeError: __enter__ 提示属性错误，没有__exit__，看了需要这个属性。 上下文管理对象 当一个对象同时实现了 __enter__()和__exit__()方法，它就属于上下文管理对象。 __enter__()：进入于此相关的上下文。如果存在该方法，with语法会把该方法的返回值作为绑定到as子句中指定的变量上。 __exit__：退出与此对象相关的上下文。 class Point: def __init__(self): print("init") def _

例子一 首先来看一段代码： class Foo(object): def __init__(self): print('实例化一个对象') def __enter__(self): print('进入') def __exit__(self, exc_type, exc_val, exc_tb): print('退出') obj = Foo() with obj: print('正在执行') 上面代码执行结果为： 实例化一个对象 进入 正在执行 退出 结论1 我们知道，实例化Foo，得到obj对象，会执行Foo的__init__方法，也就是打印了第一句； 按照，程序从上至下执行，应该会打印“正在执行”才对，为什么会在它之前先打印了进入，在它之后打印了退出呢？ 因为我们在定义Foo时，定义了__enter__和__exit__方法，那么我们实例化的对象obj就是一个上下文管理器， 即**含有__enter__和__exit__方法的对象就是上下文管理器。** with 上下文管理器： 　语句体 当with遇到上下文管理器，就会在执行语句体之前，先执行上下文管理器的__enter__方法，然后再执行语句体，执行完语句体后，最后执行__exit__方法 这也就是为什么会出现文章开头的情况的原因。 例子二 再看看这段代码： class Foo(object): def __init__

古往今来最难的学的武功(javascript)算其一。 欲练此功必先自宫，愿少侠习的此功，笑傲江湖。 你将了解 执行栈（Execution stack） 执行上下文（Execution Context） 作用域链（scope chains） 变量提升（hoisting） 闭包（closures） this 绑定 执行栈 又叫调用栈，具有 LIFO（last in first out 后进先出）结构，用于存储在代码执行期间创建的所有执行上下文。 当 JavaScript 引擎首次读取你的脚本时，它会创建一个全局执行上下文并将其推入当前的执行栈。每当发生一个函数调用，引擎都会为该函数创建一个新的执行上下文并将其推到当前执行栈的顶端。 引擎会运行执行上下文在执行栈顶端的函数，当此函数运行完成后，其对应的执行上下文将会从执行栈中弹出，上下文控制权将移到当前执行栈的下一个执行上下文。 我们通过下面的示例来说明一下 function one() { console.log('one') two() } function two() { console.log('two') } one() 当程序（代码）开始执行时 javscript 引擎创建 GobalExecutionContext （全局执行上下文）推入当前的执行栈，此时 GobalExecutionContext

1.1 使用Spring简化Java开发 为了降低Java开发，Spring使用了一下4种关键策略： 基于POJO的轻量级和最小侵入性编程； 通过依赖注入和面向接口实现松耦合； 基于切面和管理进行声明式编程； 通过切面和模版减少样板式代码； 1.1.1 激发POJO的潜能 Spring竭力避免因自身的API而弄乱你的代码。不会强迫你去实现Spring规范的接口或继承Spring规范的类，相反，它的类通常没有任何痕迹表名你使用了Spring。最坏的场景是，一个类或许会使用Spring的注解，但它仍然是POJO。 1.1.2 依赖注入（DI） 任何一个有实际意义的应用都会由两个或者更多的类组合，这些类相互之间进行协作来完成特定的业务逻辑。按照传统做法，每个对象负责管理与自己互相协作的对象的引用，这将会导致高度耦合和难以测试的代码。 耦合具有两面性。一方面，紧密耦合的代码难以测试、难以复用、难以理解，并且典型地出现打地鼠式的bug特性。另一方面，一定程度的耦合又是必须的，完全没有耦合的代码什么也做不了。总而言之，耦合是必须的，但应当被小心谨慎的管理。 通过依赖倒置，对象的依赖关系将由系统中负责协调各对象的第三方组件在创建对象的时候进行设定。对象无需自行创建或管理它们的依赖关系，依赖系统将被自动侏儒到需要他们的对象中去。 1.1.3 应用切面（AOP）