Reprint

lazygit https://github.com/jesseduffield/lazygit go install github.com/jesseduffield/lazygit@latest

autoHotKey ^ ctrl shift ! alt ^!s:: {BS} backspace sleep 500 Send Hello{Enter} return //ctrl+alt+s

golang 方法, 接口, 继承 package main import "fmt" type Foo struct{ Field0 string Field1 string } type Bar struct{ Foo Field2 string Field3 string } func main(){ fmt.Println("hello") bar:=Bar{Field2: "f2",Field3: "f3"} bar.Field0="f0" fmt.Printf("%v",bar) } http://www.cnblogs.com/chenny7/p/4497969.html Go语言没有沿袭传统面向对象编程中的诸多概念，比如继承、虚函数、构造函数和析构函数、隐藏的 this 指针等。 go 方法 Go 语言中同时有函数和方法。方法就是一个包含了接收器 (receiver) 的函数，receiver 可以是内置类型或者结构体类型的一个值或者是一个指针。所有给定类型的方法属于该类型的方法集。 如下面的这个例子，定义了一个新类型Integer，它和int一样，只是为它内置的int类型增加了个新方法 Less() 接收器——方法作用的目标 接收器的格式如下： func (接收器变量 接收器类型) 方法名(参数列表) (返回参数) { 函数体 } type Integer int func (a Integer) Less(b Integer) bool { return a < b } func main() { var a Integer = 1 if a.Less(2) { fmt.Println("less then 2") } } 可以看出，Go语言在自定义类型的对象中没有 C++/Java 那种隐藏的 this指针，而是在定义成员方法时显式声明了其所属的对象。 ...

Filter FilterChain http://blog.csdn.net/zhaozheng7758/article/details/6105749 一、Filter的介绍及使用**** 什么是过滤器？ 与Servlet相似，过滤器是一些web应用程序组件，可以绑定到一个web应用程序中。但是与其他web应用程序组件不同的是，过滤器是"链"在容器的处理过程中的。这就意味着它们会在servlet处理器之前访问一个进入的请求，并且在外发响应信息返回到客户前访问这些响应信息。这种访问使得过滤器可以检查并修改请求和响应的内容。 过滤器适用于那些地方？ l 为一个web应用程序的新功能建立模型(可被添加到web应用程序中或者从web应用程序中删除而不需要重写基层应用程序代码)； l 向过去的代码添加新功能。 过滤器放在容器结构的什么位置？ 过滤器放在web资源之前，可以在请求抵达它所应用的web资源(可以是一个Servlet、一个Jsp页面，甚至是一个HTML页面)之前截获进入的请求，并且在它返回到客户之前截获输出请求。Filter: 用来拦截请求，处于客户端与被请求资源之间，目的是重用代码。Filter链，在web.xml中哪个先配置，哪个就先调用。在filter中也可以配置一些初始化参数。 Java中的Filter 并不是一个标准的Servlet ，它不能处理用户请求，也不能对客户端生成响应。 主要用于对HttpServletRequest 进行预处理，也可以对HttpServletResponse 进行后处理，是个典型的处理链。 Filter 有如下几个用处: l 在HttpServletRequest 到达Servlet 之前，拦截客户的HttpServletRequest 。 l 根据需要检查HttpServletRequest ，也可以修改HttpServletRequest 头和数据。 l 在HttpServletResponse 到达客户端之前，拦截HttpServletResponse 。 l 根据需要检查HttpServletResponse ，可以修改HttpServletResponse 头和数据。 Filter 有如下几个种类: l 用户授权的Filter: Filter 负责检查用户请求，根据请求过滤用户非法请求。 l 日志Filter: 详细记录某些特殊的用户请求。 l 负责解码的Filter: 包括对非标准编码的请求解码。 l 能改变XML 内容的XSLTFilter 等。 一个Filter 可负责拦截多个请求或响应:一个请求或响应也可被多个请求拦截。 创建一个Filter 只需两个步骤: (1)创建Filter 处理类: (2)在web.xml 文件中配置Filter 。 创建Filter 必须实现javax.servlet.Filter 接口，在该接口中定义了三个方法。 • void init(FilterConfig config): 用于完成Filter 的初始化。 ...

python调用shell命令 http://blog.chinaunix.net/uid-16362696-id-3067891.html python调用shell命令的方法有许多 1.1 os.system(command) 在一个子shell中运行command命令，并返回command命令执行完毕后的退出状态。这实际上是使用C标准库函数system()实现的。这个函数在执行command命令时需要重新打开一个终端，并且无法保存command命令的执行结果。 1.2 os.popen(command,mode) 打开一个与command进程之间的管道。这个函数的返回值是一个文件对象，可以读或者写(由mode决定，mode默认是’r’)。如果mode为’r’，可以使用此函数的返回值调用read()来获取command命令的执行结果。 1.3** **commands.getstatusoutput(command) 使用os.popen()函数执行command命令并返回一个元组(status,output)，分别表示command命令执行的返回状态和执行结果。对command的执行实际上是按照{command;} 2>&1的方式，所以output中包含控制台输出信息或者错误信息。output中不包含尾部的换行符。 2.1 subprocess.call([“some_command”,“some_argument”,“another_argument_or_path”]) subprocess.call(command,shell=True) 2.2 subprocess.Popen(command, shell=True) 如果 command 不是一个可执行文件，shell=True 不可省。 使用subprocess模块可以创建新的进程，可以与新建进程的输入/输出/错误管道连通，并可以获得新建进程执行的返回状态。使用subprocess模块的目的是替代os.system()、os.popen*()、commands.*等旧的函数或模块。 最简单的方法是使用class subprocess.Popen(command,shell=True)。Popen类有Popen.stdin，Popen.stdout，Popen.stderr三个有用的属性，可以实现与子进程的通信。 将调用shell的结果赋值给python变量 handle = subprocess.Popen(command, shell=True, stdout=subprocess.PIPE) print handle.communicate()[0] 如果想获取执行命令的状态值，也就是$?, 可以用os.system( cmd ) 如果想获取执行命令的print内容， 可以用os.popen( cmd ).read() 既想获取状态值，也想获取打印的内容？ import commands stat, content = commands.getstatusoutput( cmd ) stat is the exit code content is the content for printing

Lambda 表达式 “Lambda 表达式"是一个匿名函数,它可以包含表达式和语句,并且可用于创建委托或表达式目录树类型。 所有 Lambda 表达式都使用 Lambda 运算符 =>,该运算符读为"goes to”。该 Lambda 运算符的左边是输入参数 (如果有) ,右边包含表达式或语句块。Lambda 表达式 x => x * x 读作"x goes to x times x"。 函数式接口functional interface, @FunctionalInterface 函数式接口(Functional Interface)是Java 8对一类特殊类型的接口的称呼。 这类接口只定义了唯一的抽象方法的接口 (除了隐含的Object对象的公共方法) , 因此最开始也就做SAM类型的接口 (Single Abstract Method) 。 为什么会单单从接口中定义出此类接口呢？ 原因是在 Java Lambda 的实现中, 开发组不想再为Lambda表达式单独定义一种特殊的Structural函数类型,称之为箭头类型 (arrow type) , 依然想采用Java既有的类型系统(class, interface, method等), 原因是增加一个结构化的函数类型会增加函数类型的复杂性,破坏既有的Java类型,并对成千上万的Java类库造成严重的影响。 权衡利弊, 因此最终还是利用SAM 接口作为 Lambda表达式的目标类型。 JDK中已有的一些接口本身就是函数式接口,如Runnable。 JDK 8中又增加了java.util.function包, 提供了常用的函数式接口。 函数式接口代表的一种契约, 一种对某个特定函数类型的契约。 在它出现的地方,实际期望一个符合契约要求的函数。 Lambda表达式不能脱离上下文而存在,它必须要有一个明确的目标类型,而这个目标类型就是某个函数式接口。 方法引用 (method reference) 双冒号 “::” 是 Java 8 引入 Lambda 表达式后的一种用法,表示方法引用 (method reference) ,可以更加简洁的实例化接口 双冒号表达式返回的是一个 函数式接口对象 (用 @FunctionalInterface 注解的 interface 类型) 的实例,如下: ...

数据库索引 数据库索引好比是一本书前面的目录，能加快数据库的查询速度。 例如这样一个查询: select * from table1 where id=44。如果没有索引，必须遍历整个表，直到ID等于44的这一行被找到为止；有了索引之后(必须是在ID这一列上建立的索引)，直接在索引里面找44 (也就是在ID这一列找) ，就可以得知这一行的位置，也就是找到了这一行。可见，索引是用来定位的。 索引分为聚簇索引和非聚簇索引两种，聚簇索引 是按照数据存放的物理位置为顺序的，而非聚簇索引就不一样了；聚簇索引能提高多行检索的速度，而非聚簇索引对于单行的检索很快。为表设置索引要付出代价的: 一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。 详述 创建索引可以大大提高系统的性能。第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。 也许会有人要问: 增加索引有如此多的优点，为什么不对表中的每一个列创建一个索引呢？因为，增加索引也有许多不利的方面。第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。 索引是建立在数据库表中的某些列的上面。在创建索引的时候，应该考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列上创建索引: 在经常需要搜索的列上，可以加快搜索的速度； 在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构； 在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的； 在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间； 在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。 同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点: 第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。 第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。 第三，对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少,不利于使用索引。 第四，当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改操作远远多于检索操作时，不应该创建索引。可以基于数据库表中的单列或多列创建索引。多列索引可以区分其中一列可能有相同值的行。 如果经常同时搜索两列或多列或按两列或多列排序时，索引也很有帮助。例如，如果经常在同一查询中为姓和名两列设置判据，那么在这两列上创建多列索引将很有意义。 确定索引的有效性: 检查查询的WHERE和JOIN子句。在任一子句中包括的每一列都是索引可以选择的对象。 对新索引进行试验以检查它对运行查询性能的影响。 考虑已在表上创建的索引数量。最好避免在单个表上有很多索引。 检查已在表上创建的索引的定义。最好避免包含共享列的重叠索引。 检查某列中唯一数据值的数量，并将该数量与表中的行数进行比较。比较的结果就是该列的可选择性，这有助于确定该列是否适合建立索引，如果适合，确定索引的类型。根据数据库的功能，可以在数据库设计器中创建三种索引: 唯一索引、主键索引和聚集索引。有关数据库所支持的索引功能的详细信息，请参见数据库文档。 提示: 尽管唯一索引有助于定位信息，但为获得最佳性能结果，建议改用主键或唯一约束。 唯一索引 唯一索引是不允许其中任何两行具有相同索引值的索引。 当现有数据中存在重复的键值时，大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如，如果在employee表中职员的姓(lname)上创建了唯一索引，则任何两个员工都不能同姓。 主键索引 数据库表经常有一列或列组合，其值唯一标识表中的每一行。该列称为表的主键。 在数据库关系图中为表定义主键将自动创建主键索引，主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时，它还允许对数据的快速访问。 聚集索引 在聚集索引中，表中行的物理顺序与键值的逻辑 (索引) 顺序相同。一个表只能包含一个聚集索引。 如果某索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。 索引 uuid vs 自增 需要看你索引适应的形式，如果使用 b-tree 索引形式，有序 id 比无需 id 好，如果是 hash 索引，两个差别不大。主要原因是索引在磁盘上存储的形式，常用的 b-tree 索引如果 id 是连续的，那么数据存储在相邻的磁盘上，如果查询和写入操作的 id 连续，那么减少随机读写硬盘的几率，提升读写效率。所以看你的实际情况，如果你用的是 b-tree 索引，同时记录比较多，那么用有序 id 作为索引效率会高很多。 ...

MySQL 分页 一般MySQL最基本的分页方式: select * from content order by id desc limit 0, 10 在中小数据量的情况下，这样的SQL足够用了，唯一需要注意的问题就是确保使用了索引。随着数据量的增加，页数会越来越多，查看后几页的SQL就可能类似: select * from content order by id desc limit 10000, 10 一言以蔽之，就是越往后分页，LIMIT语句的偏移量就会越大，速度也会明显变慢。 此时，我们可以通过2种方式: 一，子查询的分页方式来提高分页效率，SQL语句如下: SELECT * FROM content WHERE id <= (SELECT id FROM content ORDER BY id desc LIMIT “.($page-1)*$pagesize.”, 1) ORDER BY id desc LIMIT $pagesize 为什么会这样呢？因为子查询是在索引上完成的，而普通的查询时在数据文件上完成的，通常来说，索引文件要比数据文件小得多，所以操作起来也会更有效率。 (via) 通过explain SQL语句发现: 子查询使用了索引！ id select_type table type possible_keys key key_len ref rows Extra 1 PRIMARY content range PRIMARY PRIMARY 4 NULL 6264 Using where ...

消息队列/message queue/MQ, CORBA, DCOM, RMI, RPC http://blog.csdn.net/mr_smile2014/article/details/47452281 消息队列是在消息的传输过程中保存消息的容器，消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。 一、 产生背景: 现今，越来越多的企业面临着各种各样的数据集成和系统整合，CORBA、DCOM、RMI 等RPC中间件技术也应运而生，但由于采用RPC同步处理技术，在性能、健壮性、可扩展性上都存在着诸多缺点。而基于消息的异步处理模型采用非阻塞的调用特性，发送者将消息发送给消息服务器，消息服务器在合适的时候再将消息转发给接收者；发送和接收是异步的，发送者无需等待，二者的生命周期也可以不必相同，而且发送者可以将消息间接传给多个接收者，大大提高了程序的性能、可扩展性及健壮性，这使得异步处理模型在分布式应用上比起同步处理模型更具有吸引力。 分布式对象调用，如CORBA，RMI 和DCOM，提供了一种通讯机制，透明地在异构的分布式计算环境中传递对象请求，这些对象可以位于本地或远程机器。它通过在对象与对象之间提供一种统一的接口，使对象之间的调用和数据共享不再关心对象的位置、实现语言及所驻留的操作系统。这个接口就是面向对象的中间件。 二、传统面向对象中间件的局限性 同步通信: 客户发出调用后，必须等待服务对象完成处理并返回结果后才能继续执行。 客户和服务对象的生命周期紧密耦合: 客户进程和服务对象进程都必须正常运行，如果由于服务对象崩溃或网络故障导致客户的请求不可达，客户会接收到异常。 三、面向消息的中间件的优越性 消息中间件作为一个中间层软件, 它为分布式系统中创建、发送、接收消息提供了一套可靠通用的方法，实现了分布式系统中可靠的、高效的、实时的跨平台数据传输。消息中间件减少了开发跨平台和网络协议软件的复杂性，它屏蔽了不同操作系统和网络协议的具体细节，面对规模和复杂度都越来越高的分布式系统。它与传统的面向对象中间件相比具有如下优点: 采用异步通信模式: 发送消息者可以在发送消息后进行其它的工作，不用等待接收者的回应，而接收者也不必在接到消息后立即对发送者的请求进行处理。 客户和服务对象生命周期的松耦合关系: 客户进程和服务对象进程不要求都正常运行，如果由于服务对象崩溃或者网络故障导致客户的请求不可达，客户不会接收到异常，消息中间件能保证消息不会丢失。 四、消息中间件的技术标准 消息中间件主要有JMS和AMQP两种技术标准； JMS Java关于消息服务的标准是JMS，JMS即Java消息服务 (Java Message Service) 应用程序接口是一个Java平台中关于面向消息中间件 (MOM) 的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，类似于JDBC，需要不同的提供商进行各自的实现。实现JMS标准的软件可以作为Java下的消息中间件服务器。JMS 使您能够通过消息收发服务 (有时称为消息中介程序或路由器) 从一个 JMS 客户机向另一个 JMS客户机发送消息。消息是 JMS中的一种类型对象，由两部分组成: 报头和消息主体。报头由路由信息以及有关该消息的元数据组成。消息主体则携带着应用程序的数据或有效负载。根据有效负载的类型来划分，可以将消息分为几种类型，它们分别携带: 简单文本(TextMessage)、可序列化的对象 (ObjectMessage)、属性集合 (MapMessage)、字节流 (BytesMessage)、原始值流 (StreamMessage)，还有无有效负载的消息 (Message)。 AMQP AMQP，即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。Erlang中的实现有 RabbitMQ等。

sql join 多个条件 SELECT a.* FROM product a LEFT JOIN product_details b ON a.id=b.id AND b.weight!=44 AND b.exist=0 WHERE b.id IS NULL; join inner join(等值连接) 只返回两个表中联结字段相等的行 left join (左联接) 返回包括左表中的所有记录和右表中联结字段相等的记录 right join(右联接) 返回包括右表中的所有记录和左表中联结字段相等的记录 INNER JOIN 语法: INNER JOIN 连接两个数据表的用法: SELECT * FROM 表1 INNER JOIN 表2 ON 表1.字段号=表2.字段号 INNER JOIN 连接三个数据表的用法: SELECT * FROM (表1 INNER JOIN 表2 ON 表1.字段号=表2.字段号) INNER JOIN 表3 ON 表1.字段号=表3.字段号 **INNER JOIN 连接四个数据表的用法: ** SELECT * FROM ((表1 INNER JOIN 表2 ON 表1.字段号=表2.字段号) INNER JOIN 表3 ON 表1.字段号=表3.字段号) INNER JOIN 表4 ON Member.字段号=表4.字段号 ...

jconsole http://jiajun.iteye.com/blog/810150 一、JConsole是什么 从Java 5开始 引入了 JConsole。JConsole 是一个内置 Java 性能分析器，可以从命令行或在 GUI shell 中运行。您可以轻松地使用 JConsole (或者，它更高端的 “近亲” VisualVM ) 来监控 Java 应用程序性能和跟踪 Java 中的代码。 二、如何启动JConsole 如果是从命令行启动，使 JDK 在 PATH 上，运行 jconsole 即可。 如果从 GUI shell 启动，找到 JDK 安装路径，打开 bin 文件夹，双击 jconsole 。 当分析工具弹出时 (取决于正在运行的 Java 版本以及正在运行的 Java 程序数量) ，可能会出现一个对话框，要求输入一个进程的 URL 来连接，也可能列出许多不同的本地 Java 进程 (有时包含 JConsole 进程本身) 来连接。如图所示: 想分析那个程序就双击那个进程。 三、如何设置JAVA程序运行时可以被JConsolse连接分析 本地程序 (相对于开启JConsole的计算机) ，无需设置任何参数就可以被本地开启的JConsole连接 (Java SE 6开始无需设置，之前还是需要设置运行时参数 -Dcom.sun.management.jmxremote ) 无认证连接 (下面的设置表示: 连接的端口为8999、无需认证就可以被连接) Java代码 收藏代码 -Dcom.sun.management.jmxremote.port=8999 \ ...

生产线节拍 流程的"节拍"(Cycle time)是指连续完成相同的两个产品(或两次服务，或两批产品)之间的间隔时间。换句话说，即指完成一个产品所需的平均时间。节拍通常只是用于定义一个流程中某一具体工序或环节的单位产出时间。如果产品必须是成批制作的，则节拍指两批产品之间的间隔时间。在流程设计中，如果预先给定了一个流程每天(或其它单位时间段)必须的产出，首先需要考虑的是流程的节拍。 在机械加工生产线的设计中，节拍是设计的一个很重要的因素。生产节拍的平衡很重要。生产节拍的公式为 t=60Tβ/N 式中t为生产节拍，T为一年基本工时，一般规定，按一班制工时为2360h/年，按两班制工时为4650h/年；β为复杂系数，一般取为0.65-0.85；N为生产线加工工件的年生产纲领。 机械加工生产线的主要分类有: 单一产品固定节拍生产线、单一产品非固定节拍生产线、成组产品可调节生产线、柔性制造生产线。

KubeKey sudo apt install socat conntrack ebtables ipset ipvsadm git clone https://github.com/kubesphere/kubekey.git cd kubekey ./build.sh -p cd output ./kk create cluster https://kubesphere.io/zh/docs/installing-on-linux/introduction/intro/

dstat dstat 是一个可以取代vmstat，iostat，netstat和ifstat这些命令的多功能产品。dstat克服了这些命令的局限并增加了一些另外的功能，增加了监控项，也变得更灵活了。dstat可以很方便监控系统运行状况并用于基准测试和排除故障。 dstat可以让你实时地看到所有系统资源，例如，你能够通过统计IDE控制器当前状态来比较磁盘利用率，或者直接通过网络带宽数值来比较磁盘的吞吐率（在相同的时间间隔内）。 dstat将以列表的形式为你提供选项信息并清晰地告诉你是在何种幅度和单位显示输出。这样更好地避免了信息混乱和误报。更重要的是，它可以让你更容易编写插件来收集你想要的数据信息，以从未有过的方式进行扩展。 Dstat的默认输出是专门为人们实时查看而设计的，不过你也可以将详细信息通过CSV输出到一个文件，并导入到Gnumeric或者Excel生成表格中。 https://linux.cn/article-3215-1.html pacman -S dstat

‘Linux 双显示器/多屏/扩展屏幕/xrandr’ Can’t open display :0 用 root 用户执行 xrandr 会报错 Can’t open display :0, 尝试用其它普通用户 https://www.reddit.com/r/linux4noobs/comments/lu1plx/hi_i_get_this_authorization_required_but_no/ 4k 显示器调整 dpi xrandr -display :0.0 --listmonitors xrandr -display :0 --listmonitors xrandr -display :0 --dpi 144 # 或者这样配置环境变量 export DISPLAY=:0 xrandr --listmonitors xrdb -query xdpyinfo|grep dots xdpyinfo | grep -B 2 resolution xrandr -verbose xrandr -output DVI-0 -left-of VGA-0 -auto 不带参数执行xrandr能够列出当前的显示设备和每个设备支持的模式。 edit xorg.conf add line Virtual 2560 1024 wiloon@debian:~$ xrandr Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 16384 x 16384 DFP1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0 + 1920x1080 60.0 1600x1200 60.0 1680x1050 60.0* 1400x1050 60.0 1600x900 60.0 1360x1024 60.0 1280x1024 60.0 1440x900 60.0 1280x960 60.0 1280x800 60.0 1280x768 60.0 1280x720 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 DFP2 disconnected (normal left inverted right x axis y axis) DFP3 disconnected (normal left inverted right x axis y axis) DFP4 disconnected (normal left inverted right x axis y axis) DFP5 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 408mm x 255mm 1680x1050 60.0*+ 1600x1200 60.0 1400x1050 60.0 1600x900 60.0 1360x1024 60.0 1280x1024 75.0 60.0 1440x900 59.9 1280x960 60.0 1280x800 60.0 1152x864 60.0 75.0 1280x768 60.0 1280x720 60.0 1024x768 75.0 70.1 60.0 800x600 72.2 75.0 60.3 56.2 640x480 75.0 72.8 66.6 59.9 CRT1 disconnected (normal left inverted right x axis y axis) wiloon@debian:~$ xrandr -output DFP1 -auto -left-of DFP5 xrandr -output DFP1 -mode 1920x1200 -left-of CRT2 -mode 1680x1050 wiloon@debian:~$ cvt 1680 1050 # 1680x1050 59.95 Hz (CVT 1.76MA) hsync: 65.29 kHz; pclk: 146.25 MHz Modeline "1680x1050_60.00" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync wiloon@debian:~$ xrandr -newmode "1680x1050" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync wiloon@debian:~$ xrandr -addmode VGA1 "1680x1050" wiloon@debian:~$ xrandr -output VGA1 -mode 1680x1050 设置显示分辨率及 xrandr 介绍 X Windows 中有一个显示分辨率的概念，在默认情况下，这个显示分辨率为 max*max ，max等于你的所有连接上的显示器中最大分辨率中的最大值。例如我的笔记本液晶屏最大分辨率为 1024*768，外接显示器最大分辨率为 1280*1024，则默认的显示分辨率为 1280*1280。如果我设置左右双屏且使用最大分辨率，那么总显示分辨率就会达到2304*1024，达到超出系统默认的大小。在这种情况下强行设置双屏幕，就会导致 X 进入超低分辨率，结果不得不手工重设 xrog.conf 来恢复。 为了更好检测这个问题，我们需要用到xrandr 这个软件，xrandr系统已经自带，如果没有请安装x11-xserver-utils: sudo apt-get install x11-xserver-utils 。 不带参数执行xrandr能够列出当前的显示设备和每个设备支持的模式。Screen代表了总显示区域，VGA代表显示器，LVDS代表笔记本液晶屏。 ...

JUDE,Astah 随着UML的扩大，UML建模工具也越来越庞大。不过，许多功能并不是用户所寻求的。因此，Astah Professional (原名JUDE) 听取用户心声，根据用户需要打造，按照使用习惯设计，轻便简单，友好易用，用户可以轻松使用它来高速建模，极大的提高了效率。 Astah Professional 功能强大，支持 UML1.4中所有图和主要的图形，元模 (Meta Model) 及属性，全面满足您建模所需，还集成了思维导图，工程合并，协作开发等十余项特色功能，以及许多方便用户的贴心实用的功能。 Astah Professional 是100% 纯 Java 应用程序，可以跨平台在各种主流操作系统中使用。支持 OMG XMI标准格式，可以与其它建模工具交互模型。为方便用户书写 Office 文档，软件支持以 Microsoft EMF 增强图元拷贝粘贴至 Microsoft Office，也可以将模型信息导出到 Office Excel。软件提供了内容丰富的使用手册，全面查看 Astah Professional 所有的功能。

基于REST的Web服务基础 代表性状态传输 (Representational State Transfer，REST) 在Web领域已经得到了广泛的接受，是基于SOAP和Web服务描述语言 (Web Services Description Language，WSDL) 的Web服务的更为简单的替代方法。接口设计方面这一转变的关键证据是主流Web 2.0服务提供者 (包括Yahoo、Google和Facebook) 对REST的采用，这些提供者弃用或放弃了基于SOAP和WSDL的接口，而采用了更易于使用、面向资源的模型来公开其服务。在本文中，Alex Rodriguez将向您介绍REST的基本原理。 基础 REST定义了一组体系架构原则，您可以根据这些原则设计以系统资源为中心的Web服务，包括使用不同语言编写的客户端如何通过HTTP处理和传输资源状态。如果考虑使用它的Web服务的数量，REST近年来已经成为最主要的Web服务设计模型。事实上，REST对Web的影响非常大，由于其使用相当方便，已经普遍地取代了基于SOAP和WSDL的接口设计。 REST这个概念于2000年由Roy Fielding在就读加州大学欧文分校期间在学术论文"Architectural Styles and the Design of Network-based Software Architectures"首次提出，他的论文中对使用Web服务作为分布式计算平台的一系列软件体系结构原则进行了分析，而其中提出的REST概念并没有获得现在这么多关注。多年以后的今天，REST的主要框架已经开始出现，但仍然在开发中，因为它已经被广泛接纳到各个平台中，例如通过JSR-311成为了Java? 6不可或缺的部分。 本文认为，对于今天正在吸引如此多注意力的最纯粹形式的REST Web服务，其具体实现应该遵循四个基本设计原则: ·显式地使用HTTP方法。 ·无状态。 ·公开目录结构式的URI。 ·传输XML、JavaScript Object Notation(JSON)，或同时传输这两者。 下面几个部分将详述这四个原则，并提供技术原理解释，说明为什么这些原则对REST Web服务设计人员非常重要。 显式地使用HTTP方法 基于REST的Web服务的主要特征之一是以遵循RFC 2616定义的协议的方式显式使用HTTP方法。例如，HTTP GET被定义为数据产生方法，旨在由客户端应用程序用于检索资源以从Web服务器获取数据，或者执行某个查询并预期Web服务器将查找某一组匹配资源然后使用该资源进行响应。 REST要求开发人员显式地使用HTTP方法，并且使用方式与协议定义一致。这个基本REST设计原则建立了创建、读取、更新和删除 (create, read, update, and delete，CRUD) 操作与HTTP方法之间的一对一映射。根据此映射: ·若要在服务器上创建资源，应该使用POST方法。 ·若要检索某个资源，应该使用GET方法。 ·若要更改资源状态或对其进行更新，应该使用PUT方法。 ·若要删除某个资源，应该使用DELETE方法。 许多Web API中所固有的一个令人遗憾的设计缺陷在于将HTTP方法用于非预期用途。例如，HTTP GET请求中的请求URI通常标识一个特定的资源。或者，请求URI中的查询字符串包括一组参数，这些参数定义服务器用于查找一组匹配资源的搜索条件。至少，HTTP/1.1 RFC是这样描述GET方法的。但是在许多情况下，不优雅的Web API使用HTTP GET来触发服务器上的事务性操作——例如，向数据库添加记录。在这些情况下，GET请求URI属于不正确使用，或者至少不是以基于REST的方式使用。如果Web API使用GET调用远程过程，则应该类似如下: GET /adduser?name=Robert HTTP/1.1 这不是非常优雅的设计，因为上面的Web方法支持通过HTTP GET进行状态更改操作。换句话说，该HTTP GET请求具有副作用。如果处理成功，则该请求的结果是向基础数据存储区添加一个新用户——在此例中为Robert。这里的问题主要在语义上。Web服务器旨在通过检索与请求URI中的路径 (或查询条件) 匹配的资源，并在响应中返回这些资源或其表示形式，从而响应HTTP GET请求，而不是向数据库添加记录。从该协议方法的预期用途的角度看，然后再从与HTTP/1.1兼容的Web服务器的角度看，以这种方式使用GET是不一致的。 除了语义之外，GET的其他问题在于，为了触发数据库中的记录的删除、修改或添加，或者以某种方式更改服务器端状态，它请求Web缓存工具 (爬网程序) 和搜索引擎简单地通过对某个链接进行爬网处理，从而意外地做出服务器端更改。克服此常见问题的简单方法是将请求URI上的参数名称和值转移到XML标记中。这样产生的标记是要创建的实体的XML表示形式，可以在HTTP POST的正文中进行发送，此HTTP POST的请求URI是该实体的预期父实体 (请参见清单1和2) : ...

Web 服务编程,REST 与 SOAP的比较 REST 简介 在开始我们的正式讨论之前,让我们简单看一下 REST 的定义。 REST (Representational State Transfer) 是 Roy Fielding 提出的一个描述互联系统架构风格的名词。为什么称为 REST？Web 本质上由各种各样的资源组成,资源由 URI 唯一标识。浏览器 (或者任何其它类似于浏览器的应用程序) 将展示出该资源的一种表现方式,或者一种表现状态。如果用户在该页面中定向到指向其它资源的链接,则将访问该资源,并表现出它的状态。这意味着客户端应用程序随着每个资源表现状态的不同而发生状态转移,也即所谓 REST。 关于 REST 本身,本文就不再这里过多地讨论,读者可以参考 developerWorks 上其它介绍 REST 的文章。本文的重点在于通过 REST 与 SOAP Web 服务的对比,帮助读者更深刻理解 REST 架构风格的特点,优势。 应用场景介绍 (在线用户管理) 本文将借助于一个应用场景,通过基于 REST 和 SOAP Web 服务的不同实现,来对两者进行对比。该应用场景的业务逻辑会尽量保持简单且易于理解,以有助于把我们的重心放在 REST 和 SOAP Web 服务技术特质对比上。 需求描述 这是一个在线的用户管理模块,负责用户信息的创建,修改,删除,查询。用户的信息主要包括: 用户名 (唯一标志在系统中的用户) 头衔 公司 EMAIL 描述 需求用例图如下: 图 1. 需求用例图 如图 1 所示,客户端 1 (Client1) 与客户端 2 (Client2) 对于信息的存取具有不同的权限,客户端 1 可以执行所有的操作,而客户端 2 只被允许执行用户查询 (Query User) 与用户列表查询 (Query User List) 。关于这一点,我们在对 REST Web 服务与 SOAP Web 服务安全控制对比时会具体谈到。下面我们将分别向您介绍如何使用 REST 和 SOAP 架构实现 Web 服务。 ...

REST是什么？ 概述 REST是英文Representational State Transfer的缩写，中文翻译: 表述性状态转移。 他是由Roy Thomas Fielding博士在他的论文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。 REST本身只是为分布式超媒体系统设计的一种架构风格，而不是标准。 基于Web的架构，实际上就是各种规范的集合，这些规范共同组成了Web架构。比如Http协议，比如客户端服务器模式，这些都是规范。每当我们在原有规范的基础上增加新的规范， 就会形成新的架构。而REST正是这样一种架构，他结合了一系列的规范，而形成了一种新的基于Web的架构风格。 传统的Web应用大都是B/S架构，它包括了如下一些规范: 客户－服务器 这种规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为了可能。 无状态性 无状态性是在客户－服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性 (无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前 request，而不必了解所有的request历史) ，可靠性 (无状态性减少了服务器从局部错误中恢复的任务量) ，可伸缩性 (无状态性使得服务器端可以很容易的释放资源，因为服务器端不必在多个request中保存状态) 。同时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上的共享上下文中，因此增加了在一系列request中发送重复数据的开销,严重的降低了效率。 3.缓存 为了改善无状态性带来的网络的低效性，我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户端缓存 response数据的功能，这样就可以为以后的request共用缓存的数据，部分或全部的消除一部分交互，增加了网络的效率。但是用于客户端缓存了信息，也就同时增加了客户端与服务器数据不一致的可能，从而降低了可靠性。 B/S架构的优点是其部署非常方便，但在用户体验方面却不是很理想。为了改善这种情况， 我们引入了REST。 REST在原有的架构上增加了三个新规范: 统一接口，分层系统和按需代码。 1.统一接口 REST 架构风格的核心特征就是强调组件之间有一个统一的接口，这表现在REST世界里，网络上所有的事物都被抽象为资源，而REST就是通过通用的链接器接口对资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性。并且REST针对Web的常见情况做了优化，使得REST接口被设计为可以高效的转移大粒度的超媒体数据，这也就导致了REST接口对其它的架构并不是最优的。 2.分层系统 分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，这也就提高了系统的可伸缩性。 3.按需代码 REST允许对客户端功能进行扩展。比如，通过下载并执行applet或脚本形式的代码，来扩展客户端功能。但这在改善系统可扩展性的同时，也降低了可见性。所以它只是REST的一个可选的约束。 REST的设计准则 REST架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则: 网络上的所有事物都被抽象为资源 (resource) ； 每个资源对应一个唯一的资源标识符 (resource identifier) ； 3.通过通用的连接器接口 (generic connector interface) 对资源进行操作； 对资源的各种操作不会改变资源标识符； 所有的操作都是无状态的 (stateless) 。 REST中的资源所指的不是数据，而是数据和表现形式的组合，比如"最新访问的10位会员"和"最活跃的10为会员"在数据上可能有重叠或者完全相同，而由于他们的表现形式不同，所以被归为不同的资源，这也就是为什么REST的全名是Representational State Transfer的原因。资源标识符就是URI(Uniform Resource Identifier)，不管是图片，Word还是视频文件，甚至只是一种虚拟的服务，也不管你是xml格式,txt文件格式还是其它文件格式，全部通过 URI对资源进行唯一的标识。 REST是基于Http协议的，任何对资源的操作行为都是通过Http协议来实现。以往的Web开发大多数用的都是Http协议中的GET和 POST方法，对其他方法很少使用，这实际上是因为对Http协议认识片面的理解造成的。Http不仅仅是一个简单的运载数据的协议，而是一个具有丰富内涵的网络软件的协议。他不仅仅能对互联网资源进行唯一定位，而且还能告诉我们如何对该资源进行操作。Http把对一个资源的操作限制在4个方法以内: GET, POST,PUT和DELETE，这正是对资源CRUD操作的实现。由于资源和URI是一一对应的，执行这些操作的时候URI是没有变化的，这和以往的 Web开发有很大的区别。正由于这一点，极大的简化了Web开发，也使得URI可以被设计成更为直观的反映资源的结构，这种URI的设计被称作 RESTful的URI。这位开发人员引入了一种新的思维方式: 通过URL来设计系统结构。当然了，这种设计方式对一些特定情况也是不适用的，也就是说不是所有的URI都可以RESTful的。 ...

REST Web Service带给我们什么 Web Service的协议最近几年一直在发生转变。Web Servcie的最大优势是能在一个操作系统不同的各个系统之间架起沟通的桥梁，早期的 Web Service一般都是以SOAP协议传输。仔细学习和研究过SOAP协议的同学知道，SOAP协议是一个很完备的自解释协议，对Service、Interface、Method和Parameter的描述都非常详细，甚至还制定了一个WSDL的XSD来，在VS中，只要导入Web Service的WSDL，VS就可以自动生成存根代理代码，你只需调用它便可以调用这些SOAP的Web Service了。 SOAP 的Web Service看起来是很完美的解决方案，但是往往看起来完美的东西，用起来并不完美。 SOAP就是如此，随着Web Service 应用在企业级软件的运用，SOAP的缺陷迅速开始暴露出来。 首先，SOAP协议是在是太复杂，很少有人能完全看懂根据SOAP协议生成的数据 (其实这本来设计，就是给机器看的，哪能照顾你大爷，呵呵哦！) 。我本人是很厌烦看SOAP的数据，一看头就大，特别是SOAP头和尾。 其次，太复杂还不是SOAP协议最大的缺陷。大不了我用下解释SOAP的工具，现在VS也提供此类工具用来查看SOAP类型的数据。但是恰恰是这个缺陷造就了SOAP另一个很致命的缺陷。由于SOAP为了是每个调用的参数和返回值都可以独立解释，为此，需要在每次调用中加入大量的XML复杂信息，来解释这些数据。例如为了解释一个XML的节点是STRING，于是<datatype=“string”>被按在了一个XML节点上，其实这是没有必要的。因为，往往程序员在消费这个service的时候，已经知道了返回的数据类型，比如你在调用GetAge的时候，返回的XML肯定是int型。所以，一般一个SOAP的调用，一个来回少则数K，多则数M的，甚至数G的数据，而在这些数据中，真正有效的数据很少，根据统计，有效数据仅占全部数据的5%，甚至更少。对于海量数据的企业应用来说，大量的用户对海量数据的存储，如果用SOAP来进行数据传输，那简直就是灾难！！！ 另外，调式SOAP的WEB SERVICE也是很费时费力的，SOAP数据的难阅读性，直接增加了调式的难度。 所以，在REST之前，很多的企业应用还是用DCOM，甚至是自定义XML来进行数据传输。 那有没有很好协议的Web Service呢！？。。。现在。。。有了，REST的Web Service就是。 REST的Web Service彻底摒弃了SOAP协议。它的数据格式简单，一般都直接采用对象XML序列化的数据作为返回结果。这样就极大的降低了数据传输量，提高了效率。而且这种XML数据可以直接用IE打开，很容易阅读理解。 随着WCF和VS 2008的发布，MS首次加入了对架构REST Web Service的支持，虽然还很不完全，但是有总比没有好！现在，你只需: 1，添加Data Contract 2，添加Interface并附给URL 3，设置CLASS 4，附加到IIS或者CONSOLE程序 你就可以创建一个REST Web Service。然后通过IE，在地址栏输入Interface的URL，就想访问网页一样调用你的Web Service，返回的数据就通过IE直接显示，这够直观了吧！？ 现在，很多大型公司的Public Web Service也都已经REST化，比如GOOGLE所有的Web Service都是REST的，MS也已经采用REST来优化他的public WebService。很多"云计算"的提供商，如AMASON，他的"云服务" (呵呵，暂且如此叫吧) ，也是REST的。国内很多知名公司在看到REST的巨大优势后也纷纷开始采用REST的Web Service来提高他们的效率，如上海深睿科技的销售管理软件易卖通采用REST WebService，极大的提高了系统的速度和效率，使得传统的供销村管理软件架构在网络和"云"内成为可能。 总之，REST带给我们的是，一种更好、更简单、更有效率的Web Service，同时，可能将来成为"云计算"的基础通讯协议。