context

博客地址： http://www.moonxy.com 关于AD 域服务器搭建及其使用，请参阅： AD 域服务简介（一） - 基于 LDAP 的 AD 域服务器搭建及其使用 一、前言 先简单简单回顾上一篇博文中关于 AD 域和 LDAP目录访问协议的基本概念。 AD（Active Directory）活动目录，动态的建立整个域模式网络中的对象的数据库或索引，使用的协议为 LDAP，安装了AD 的服务器称为 DC 域控制器，存储整个域的对象的信息并周期性更新，其中的对象分为三大类：资源（如印表机）、服务（如电子邮件）、和用户（即帐户或用户，以及组）。 通常大家都会将 LDAP 与关系数据库相比，认为 LDAP 是另一种的存贮方式，然后在读性能上进行比较。实际上，这种对比的基础是不正确的。LDAP 和关系数据库是两种不同层次的概念，后者是存贮方式（同一层次如网络数据库，对象数据库），前者是存贮模式和访问协议。LDAP 是一个比关系数据库抽象层次更高的存贮概念，与关系数据库的查询语言 SQL 属同一级别。LDAP 最基本的形式是一个连接数据库的标准方式。该数据库为读查询作了优化。因此它可以很快地得到查询结果，不过在其它方面，例如更新，就慢得多。 二、Java 获取 AD 域用户 Java 获取 AD 域用户通常用于单点登录（Single Sign On，SSO）。 package com

首先，对于一个web应用，其部署在web容器中，web容器提供其一个全局的上下文环境，这个上下文就是ServletContext，其为后面的spring IoC容器提供宿主环境； 其次，在web.xml中会提供有contextLoaderListener。在web容器启动时，会触发容器初始化事件，此时contextLoaderListener会监听到这个事件，其contextInitialized方法会被调用，在这个方法中，spring会初始化一个启动上下文，这个上下文被称为根上下文，即WebApplicationContext，这是一个接口类，确切的说，其实际的实现类是XmlWebApplicationContext。这个就是spring的IoC容器，其对应的Bean定义的配置由web.xml中的context-param标签指定。在这个IoC容器初始化完毕后，spring以WebApplicationContext.ROOT WEB APPLICATION CONTEXT ATTRIBUTE为属性Key，将其存储到ServletContext中，便于获取； 再次，contextLoaderListener监听器初始化完毕后，开始初始化web.xml中配置的Servlet，这个servlet可以配置多个，以最常见的DispatcherServlet为例

1.service概念： Service是四大基础组件之一，它和Activity一样都是Context的子类，只不过它没有UI界面，是在后台运行的组件。 2.生命周期： Service对象不能自己启动，需要通过某个Activity、Service或者其他Context对象来启动。启动的方法有两种，Context.startService和Context.bindService()。两种方式的生命周期是不同的，具体如下所示。 Context.startService方式的生命周期： 启动时，startService –> onCreate() –> onStart() 停止时，stopService –> onDestroy() Context.bindService方式的生命周期： 绑定时,bindService -> onCreate() –> onBind() 解绑定时,unbindService –>onUnbind() –> onDestory() 3.service与intentService区别 Android中的Service是用于后台服务的，它是依赖于应用程序的主线程的，也就是说，在更多时候不建议在Service中编写耗时的逻辑和操作，否则会引起ANR。 那么我们当我们编写的耗时逻辑，不得不被service来管理的时候，就需要引入IntentService

Q2Day81 性能相关 在编写爬虫时，性能的消耗主要在IO请求中，当单进程单线程模式下请求URL时必然会引起等待，从而使得请求整体变慢。 import requests def fetch_async(url): response = requests.get(url) return response url_list = ['http://www.github.com', 'http://www.bing.com'] for url in url_list: fetch_async(url) 2.多线程执行 2.多线程+回调函数执行 3.多进程执行 3.多进程+回调函数执行 通过上述代码均可以完成对请求性能的提高，对于多线程和多进行的缺点是在IO阻塞时会造成了线程和进程的浪费，所以异步IO回事首选： 1.asyncio示例1 1.asyncio示例2 2.asyncio + aiohttp 3.asyncio + requests 4.gevent + requests 5.grequests 6.Twisted示例 7.Tornado from twisted.internet import reactor from twisted.web.client import getPage import urllib.parse def one_done(arg): print

引言 在我们React组件开发中，当一个父组件的想要往自己的子孙组件传值的时候，可以使用 props 属性，但是其每一个子组件，都要向下传递数据，这样造成的数据的耦合性，所以在 React 官方文档中 提供了 context 特性来解决，这个问题。 父子组件之间的通信 我们先看一下React中，父子组件通信的机制，父子组件的通信是通过props进行数据的传递： 父组件向子组件传递数据(状态)时，是在调用子组件的时候通过参数传递给子组件，子组件通过this.props进行接收； 子组件如果更改父组件的一些属性，则是通过父组件定义的方法来传递给子组件，子组件调用更改； 如果父组件想要更改子组件的一些状态时，通过ref进行标记，可以获取子组件的所有信息，从而调用子组件的方法和值； 但是，如果层级很多呢，是否需要多个props进行逐层的传递？答案是否定的，React的advanced(高级)中指出了context，优雅的解决这个问题。 好的，接下来我们来介绍一下这个特性 Context 我们知道，在JS中context指的是函数的执行上下文，函数被调用时，this指向谁，谁就是当前的执行上下文； react中的context是什么呢？官方文档给出： Context 通过组件树提供了一个传递数据的方法，从而避免了在每一个层级手动的传递 props 属性。

文件操作 文件路径 相对路径 文件/文件夹的上一层：../， 一个路径中可以写多个../ 相对路径是相对于当前文件的路径，../是按照从左往右的方向来执行，越往左和当前文件的就越近 f = open('../re_st/article/file.txt', # 当前程序文件在re_st中，../回到上一层文件夹，找到re_st文件夹，再往下找 # 相对路径的关键点在于找到两个文件的共同文件夹 mode='a', encoding='utf-8') f.write(' 功夫熊猫 ') f.close() 绝对路径 第一种：文件在本地磁盘中的绝对路径 第二种：互联网上的网页中的绝对路径 文件的读写模式 读写模式 'r+' with open('../re_st/article/file.txt', mode='r+', encoding='utf-8') as f: a = f.read() f.write('测试') print(a) f.close() ''' 注意：r+模式中光标默认是在文件的开头位置，如果直接先写后读会导致开头位置的内容直接被覆盖掉， 如果先读后写，那么光标读到文件末尾，再执行写的操作，就不会出现覆盖的问题，这一点必须注意。 ''' 写读模式 'w+' with open('../re_st/article/file.txt', mode='w+',

我是将unity工程导出为android工程,将定位脚本和需要的jar包依赖等加入,如下 LocationCustomDemo package com . baidu . map . demo . layers ; import android . app . Activity ; import android . content . Context ; import android . content . Intent ; import android . os . Bundle ; import android . util . Log ; import android . widget . Toast ; import com . baidu . location . BDAbstractLocationListener ; import com . baidu . location . BDLocation ; import com . baidu . location . LocationClient ; import com . baidu . location . LocationClientOption ; import com . baidu . map . R ; import com . baidu . map . UnityPlayerActivity ;

1、 对于一个web应用，其部署在web容器中，web容器提供一个其一个全局的上下文环境，这个上下文环境就是ServletContext，它为后面的spring IoC容器提供宿主环境； 2、 web.xml中有配置ContextLoaderListener，也可以自定义一个实现ServletContextListener接口的Listener方法，web.xml中的配置实例如下： <listener> <listener-class>com.manager.init.SystemInitListener</listener-class> </listener> <listener> 　　　　<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> Web容器启动时触发ServletContextEvent事件，被contextLoaderListener监听到，并调用contextInitialized方法： /** * Initialize the root web application context. */ public void contextInitialized(ServletContextEvent event) { this

　　记得去年初就开始关注Entity Framework，那时只是简单测试了一下，发现较之Nhibernate不太成熟。当时的EF主要表驱动方式开发，过度依赖edm文件，并且数据层耦合了模型层，让一些MVC分层用户痛苦不堪。微软从Oxite1项目发展到Oxite2也在这个DAL与MODEL的理不清的关系上做过徘徊，只好在 EDM的基础上直接实现BLL。由于EntityObject模型与ObjectContext耦合，在N层架构构中EntityObject直接提供给客户端使用的话，那ObjectContext在客户端也会被调用，因此这个时候只能通过DTO对象的方式解决，而毕竟大部分EntityObject是可以直接传递使用的，而不是一定通过DTO传递。 　　我们看看现在的EF4.0和EF4.1有哪些进步，先来解释一些名词 　　EDM文件 　　EDM是实体数据关系映射的XML文件，不同于Nhibernate每个对象单独映射了一个XML文件。EDM主要有三部分构成 CSDL，SSDL，MSL。CSDL表面的是实体数据模型结构，SSDL表示对应的数据存储的架构，CSDL实体与SSDL数据结构的关系通过MSL映射实现。EDM是通过ADO.NET 实体数据模型生成的 　　生成EDM文件的方式有两种，一种基于是数据库，一种是创建空EDM模型。前者就是后面要提到的DataBase First方式

前言 今天偶然发现在谷歌爸爸的仓库下出现了一个叫做flutter-provide的状态管理框架，2月8日才第一次提交，非常新鲜。在简单上手之后感觉就是一个字——爽！所以今天就跟大家分享一下这个新的状态管理框架。 Provider被设计为ScopedModel的替代品，并且允许我们更加灵活地处理数据类型和数据。但是首先呢还是先说说老生常谈的状态管理。 为什么需要状态管理 在我们一开始构建应用的时候，也许很简单。我们有一些状态，直接把他们映射成视图就可以了。这种简单应用可能并不需要状态管理。 但是随着功能的增加，你的应用程序将会有几十个甚至上百个状态。这个时候你的应用应该会是这样。 Wow，这是什么鬼。我们很难再清楚的测试维护我们的状态，因为它看上去实在是太复杂了！而且还会有多个页面共享同一个状态，例如当你进入一个文章点赞，退出到外部缩略展示的时候，外部也需要显示点赞数，这时候就需要同步这两个状态。 这时候，我们便迫切的需要一个架构来帮助我们理清这些关系，状态管理框架应运而生。 什么是Provide 和Scoped_model一样，Provide也是借助了InheritWidget，将共享状态放到顶层MaterialApp之上。底层部件通过Provier获取该状态，并通过混合ChangeNotifier通知依赖于该状态的组件刷新。 Provide还提供了Provide.stream