上下文 | 易学教程

Web Worker

阅读更多关于 Web Worker

Web Worker 1.特征长时间运行，理想的运行启动性能，以及理想的内存消耗。用于支持多线程编程，它在web程序中可并发执行多个脚本，彼此间相互独立。分为两种线程 Dedicated Worker专用线程，Shared Worker共享线程。 2.简单示例 a.html <html> </html> worker.js <script> </script> 3.worker常用api worker.postMessage a.html: var worker=new Worker('worker.js); } worker.js } 4.worker执行上下文 worker有个自己单独的上下文，名叫WorkerGlobalScope；与window不同，因此不能访问 window及window相关api，比如dom；常用api： self：相当于this close()：关闭当前线程相当于terminate importScripts('*.js'):加载其他js文件 XMLHttpRequest，setTimeout/setInterval以及addEventListener/postMessage 文章来源: Web Worker

with与上下文管理器

阅读更多关于 with与上下文管理器

with open ( 'output.txt' , 'w' ) as f: f. write ( 'Hello World' ) 上面的代码往output文件写入了Hello world字符串，with语句会在执行完代码块后自动关闭文件。这里无论写文件的操作成功与否，是否有异常抛出，with语句都会保证文件被关闭。如果不用with，我们可能要用下面的代码实现类似的功能： try : f = open ( 'output.txt' , 'w' ) f. write ( "Hello World" ) except Exception as e: pass finally : f. close () 可以看到使用了with的代码比上面的代码简洁许多。上面的with代码背后发生了些什么？我们来看下它的执行流程首先执行open(‘output’, ‘w’)，返回一个文件对象调用这个文件对象的 enter 方法，并将 enter 方法的返回值赋值给变量f 执行with语句体，即with语句包裹起来的代码块不管执行过程中是否发生了异常，执行文件对象的 exit 方法，在 exit 方法中关闭文件。这里的关键在于open返回的文件对象实现了 enter 和 exit 方法。一个实现了 _enter_ 和 _exit_ 方法的对象就称之为上下文管理器。上下文管理器定义执行

httpRunner源码解读（1）

阅读更多关于 httpRunner源码解读（1）

代码结构如下： httprunner文件夹：核心模块 reports文件夹：报告 tests：测试用例重点关注 httprunner文件夹，有以下文件： templates：报告模板文件夹 built_in.py：用于yaml、json文件的内建函数 cli.py：命令行参数处理 client.py: HttpSession处理 context.py：上下文处理类，用于将yml、json文件里的信息生成上下文信息 locusts.py：性能测试类 logger.py：日志类 report.py：报告生成类 response.py： http响应处理类 runner.py：用例执行器 task.py：任务管理类 testcase.py：用例类 utils.py：工具类文章来源: httpRunner源码解读（1）

elasticsearch 查询与过滤

阅读更多关于 elasticsearch 查询与过滤

查询和过滤器上下文查询子句的行为取决于它是在查询上下文中使用还是在过滤器上下文中使用：查询上下文查询上下文中使用的查询子句回答了“这个文档与这个查询子句的匹配程度如何?”，除了决定文档是否匹配之外，查询子句还计算一个表示文档匹配程度的 _score ，相对于其他文档。当查询子句被传递给 query 参数时，查询上下文就生效，例如 search API中的 query 参数。过滤器上下文在过滤器上下文中，查询子句回答了“这个文档与这个查询子句匹配吗?”，答案很简单，是或者不是 - 没有计算分数，过滤器上下文主要用于过滤结构化数据，例如：这个 timestamp 属于2015年到2016年的范围吗? status 字段是否设置为 "published" ? 频繁使用的过滤器将自动通过Elasticsearch缓存，以提高性能。当查询子句被传递给 filter 参数时，过滤器上下文就生效，例如 bool 查询中的 filter 或 must_not 参数， constant_score 查询中的 filter 参数或 filter 聚合。下面是一个查询子句示例，用于search API中的查询和过滤器上下文，此查询将匹配满足以下所有条件的文档： title 字段包含单词 search 。 content 字段包含单词 elasticsearch 。 status

WinDbg常用命令系列---异常相关操作

阅读更多关于 WinDbg常用命令系列---异常相关操作

.exr (Display Exception Record) .exr命令显示异常记录的内容。 . exr Address . exr - 1 参数： Address 指定异常记录的地址。如果指定-1作为地址，调试器将显示最新的异常。环境： ģʽ 用户模式下，内核模式目标实时、崩溃转储 ƽ̨ 全部 .exr命令显示与调试器在目标计算机上遇到的异常相关的信息。显示的信息包括异常地址、异常代码、异常标志和异常参数的变量列表。通常可以通过使用!pcr扩展命令获取地址。下面的例子是在dmp文件里的演示这个是一个具体异常记录地址 0 : 000 > . exr 010fd1c8 ExceptionAddress : 694c4b4c ( nvoglv32 ! DrvPresentBuffers + 0x000c19fc ) ExceptionCode : c0000005 ( Access violation ) ExceptionFlags : 00000000 NumberParameters : 2 Parameter [ 0 ]: 00000000 Parameter [ 1 ]: 4592e000 Attempt to read from address 4592e000 这个地址用-1的结果 0 : 000 > . exr - 1 *** ERROR :

转载：微服务拆分

阅读更多关于转载：微服务拆分

这篇文章讲的太好了，生怕以后被删掉。转到我博文列表里把-。- 正文：开发者在刚开始尝试实现自己的微服务架构时往往会产生一系列问题：微服务到底应该怎么划分？一个典型的微服务到底应该有多微？如果做了微服务设计，最后真的会有好处吗？回答上面的问题需要首先了解微服务设计的逻辑，科学的架构设计应该通过一些输入并逐步推导出结果，架构师要避免凭空设计和“拍脑门”的做法。解耦的单体应用和微服务系统在逻辑上是一样的。对于服务拆分的逻辑来说，先设计高内聚低耦合的领域模型，再实现相应的分布式系统是一种比较合适的方式。服务的划分有一些基本的方法和原则，通过这些方法能让微服务划分更有操作性。最终在微服务落地实施时也能按图索骥，无论是对遗留系统改造还是全新系统的架构都能游刃有余。微服务拆分的几个阶段在开始划分微服务之前，架构师需要在大脑中有一个重要的认识：微服务只是手段，不是目的。微服务架构是为了让系统变得更容易拓展、更富有弹性。在把单体应用变成靠谱的微服务架构之前，单体系统的各个模块应该是合理、清晰地。也就是说，从逻辑上单体系统和微服务没有区别，某种理想情况下微服务只是把单体系统的各个模块分开部署了而已（最近流行的monorepo把多个服务的代码仓库以模块的形式组织到了一起，证明了这一点）。大量的实践教训告诉我们，混沌的微服务架构，比解耦良好的单体应用会带来更多麻烦。

什么是BFC？

阅读更多关于什么是BFC？

本文总结自饥人谷―方方老师：CSS深入浅出什么是BFC？为什么这个概念一直被提起？？为什么每一个人都解释不清BFC？？？什么是BFC？ BFC 全称为块格式化上下文 (Block Formatting Context) 。从这个概念里你能看出来什么吗？这个名字给我们的信息只有 “块” “格式化” “上下文” 。我们大概可以了解到这个东西是对上下文起作用的。那里的上下文？？ HTML文档！它大概的作用，貌似是格式化上下文？？可能不是我们通常意义中的格式化。我们没有从这个名字中得到太多有用的信息，仅仅知道它是一种功能，针对于 HTML文档起作用。那我们去看看官方是怎么解释的。 MDN：一个块格式化上下文（block formatting context）是Web页面的可视化CSS渲染出的一部分。它是块级盒布局出现的区域，也是浮动层元素进行交互的区域。一个块格式化上下文由以下之一创建：根元素或其它包含它的元素浮动元素 (元素的 float 不是 none) 绝对定位元素 (元素具有 position 为 absolute 或 fixed) 内联块 (元素具有 display: inline-block) 表格单元格 (元素具有 display: table-cell，HTML表格单元格默认属性) 表格标题 (元素具有 display: table

KnockoutJS-自定义属性绑定

阅读更多关于 KnockoutJS-自定义属性绑定

　　在knockoutjs中，已有的绑定功能已经十分强大，基本上可以不需要再去考虑扩展了，但是，也有例外的场景，面对这种场景，还是得去完成，knockoutJS提供了自定义绑定来扩展绑定功能。一、新建绑定　　新建一个js文件来尝试绑定功能，按照给定的格式ko.bindingHandlers.xxx来扩展一个绑定。 ko . bindingHandlers . yourBindingName = { init : function ( element , valueAccessor , allBindingsAccessor , viewModel ) { // This will be called when the binding is first applied to an element // Set up any initial state, event handlers, etc. here }, update : function ( element , valueAccessor , allBindingsAccessor , viewModel ) { // This will be called once when the binding is first applied to an element, // and again whenever the

Flask笔记：上下文

阅读更多关于 Flask笔记：上下文

线程隔离Thread Local：如果一个对象具有线程隔离的特性，就可以称之为“Thread Local”，线程隔离是指该对象在不同的线程中都是独立的，在一个线程中对该对象的操作不会影响另一个线程对该对象操作，比如在线程A中修改了该对象的某个属性值，但是在线程B中该对象的这个属性值并没有被修改。 Flask线程隔离对象：在Flask中，线程隔离对象包括request、session、g、current_app等，在项目中这些对象都可以直接导入使用，而不用担心运行时不同的地方同时使用这些对象时会出问题。比如有多个不同的请求同时进来，它们都会使用到request对象，但因为request是线程隔离的，而每一个请求都有自己的线程，所以request对象使用各自线程的数据。应用上下文和请求上下文：应用上下文和请求上下文都有各自的上下文context对象和LocalStack栈对象，在视图函数中使用上下文操作时（current_app对象、url_for函数等），会自动创建对应的上下文context对象并将其push到对应的LocalStack栈的顶端，进行上下文操作时，会自动到这个LocalStack栈的顶端获取context对象。所以在视图函数中是可以直接使用上下文操作的。如果想要在视图函数外面使用上下文操作

js执行上下文

阅读更多关于 js执行上下文

在讲执行上下文之前我们先将下变量提升和函数提升变量提升：使用var关键字声明的变量，会在所有代码执行之前被声明（但不会赋值）例如：cosole.log(a); var a=; 这里会打印输出undefined 函数提升：使用函数声明形式创建的函数function(){}他会在所有代码之行前被创建。先执行变量提升，在执行函数提升，最后在进行赋值操作。执行上下文分为：全局执行上下文和函数执行上下文全局执行上下文：在执行全局代码之前将window确定为全局执行上下文；对全局数据进行预处理； var定义的变量==》undefined ，添加为window的属性； function声明的全局函数==》fn，添加为window的属性； this==>赋值为window；开始执行全局代码；函数执行上下文：再调用函数体之前，创建对应的函数执行上下文对象，对局部函数进行预处理。形参变量==》赋值（实参）==》添加为函数执行上下文属性； arguments==》赋值（实参列表）==》添加为函数执行上下文属性；（伪数组） function声明的汉书==》赋值（fun）==》添加为函数执行上下文属性； this==>赋值（调用函数的对象）；开始执行函数体代码；执行上下文栈： 1.在全局代码执行前，js引擎就会创建出一个栈来存储管理所有的执行上下文对象。 2.在全局执行上下文

订阅上下文