Posts

Derby Apache Derby, an Apache DB subproject, is an open source relational database implemented entirely in Java and available under the Apache License, Version 2.0. Some key advantages include: Derby has a small footprint - about 2.6 megabytes for the base engine and embedded JDBC driver. Derby is based on the Java, JDBC, and SQL standards. Derby provides an embedded JDBC driver that lets you embed Derby in any Java-based solution. ...

奥卡姆剃刀, Occam’s Razor 奥卡姆剃刀原理 奥卡姆剃刀原理是在14世纪由一个叫做奥卡姆的威廉的天主教修士提出的，可以概括为: 如无必要，勿增实体。 http://www.guokr.com/post/46473/

chart library web chart library chartjs Simple yet flexible JavaScript charting https://www.chartjs.org/ Apache ECharts An Open Source JavaScript Visualization Library https://echarts.apache.org/en/index.html

设计模式 – Decorator Decorator设计模式是典型的结构型模式 装饰模式:Decorator常被翻译成"装饰",我觉得翻译成"油漆工"更形象点,油漆工(decorator)是用来刷油漆的,那么被刷油漆的对象我们称decoratee.这两种实体在Decorator模式中是必须的. Decorator定义: 动态给一个对象添加一些额外的职责,就象在墙上刷油漆.使用Decorator模式相比用生成子类方式达到功能的扩充显得更为灵活. 下面是GOF的《Element of reusable Object-Oriented Software》中对Decorator用意的概述: Decorator Pattern――Attaches additional responsibilities to an object dynamically . Decorators provide a flexible alternative to subclassing for extending functionality . 1 何时需要使用装饰器模式 GOF的那本Bible中关于装饰器模式列举的是一个文本组件与边框的例子 下面举一个"三明治"的例子！ 很多人都吃过三明治，都会知道三明治必不可少的是两块面包片，然后可以在夹层里加上蔬菜、沙拉、咸肉等等，外面可以涂上奶油之类的。假如现在你要为一个三明治小店构造一个程序，其中要设计各种三明治的对象。可能你已经创建了一个简单的Sandwich对象，现在要产生带蔬菜的就是继承原有的Sandwich添加一个蔬菜的成员变量，看起来很"正点"的做法，以后我还要带咸肉的、带奶油的、带蔬菜的又分为带青菜的、带芹菜的、生菜的……还是一个一个继承是吧！假如我们还需要即带蔬菜又带其它肉类，设置我们还要求这些添加成分的任意组合，那你就慢慢继承吧！ 读过几年书的会下面这个算术，我们有n种成分，在做三明治的时候任意搭配，那么有多少种方案呢？！算算吧！你会有惊人的发现。N种成分，什么都不要是Cn0种方案吧！要1种是Cn1吧！…..要n种是Cnn吧！加起来不就是吗？Cn0+Cn1+……+Cnn-1+Cnn还不会啊！牛顿莱布尼兹公式记得吧！ (可惜Word的公式编辑器安装不了) 总共2的n次方案。有可能前面10天写了K个类，老板让你再加一种成分你就得再干10天，下一次再加一种你可得干20天哦！同时你可以发现你的类库急剧地膨胀！ (老板可能会说你: XXX前K天你加了n个成分，怎么现在这么不上进呢？后K天只加了1个成分啊？！！可能你会拿个比给老板算算，老板那么忙会睬你吗？！有可能你的老板会说: 不管怎么样我就要你加，K天你还给我加n个成分！！呵呵，怎么办啊！跳槽啊!跳槽了也没人要你！！人家一看就知道你没学设计模式) 。下面我们就使用装饰器模式来设计这个库吧！ 下面是各个类的意义: Ingredient (成分) : 所有类的父类，包括它们共有的方法，一般为抽象类且方法都有默认的实现，也可以为接口。它有Bread和Decorator两个子类。这种实际不存在的，系统需要的抽象类仅仅表示一个概念，图中用红色表示。 Bread (面包) : 就是我们三明治中必须的两片面包。它是系统中最基本的元素，也是被装饰的元素，和IO中的媒质流 (原始流) 一个意义。在装饰器模式中属于一类角色，所以其颜色为紫色。 Decorator (装饰器) : 所有其它成分的父类，这些成分可以是猪肉、羊肉、青菜、芹菜。这也是一个实际不存在的类，仅仅表示一个概念，即具有装饰功能的所有对象的父类。图中用蓝色表示。 Pork (猪肉) : 具体的一个成分，不过它作为装饰成分和面包搭配。 Mutton (羊肉) : 同上。 Celery (芹菜) : 同上。 ...

Jena Jena is a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine. Jena is open source and grown out of work with the HP Labs Semantic Web Programme. The Jena Framework includes: A RDF API Reading and writing RDF in RDF/XML, N3 and N-Triples An OWL API In-memory and persistent storage SPARQL query engine

OWL OWL Web本体语言指南 W3C推荐标准 2004年02月10日 摘要 目前这种结构的万维网，很像一本地图做得很差的地理书，我们对于Web中可以使用的文档和服务的了解，都是基于关键字搜索的， 同时还需要灵活地使用文档的链接和使用模式。如果没有强有力的工具的支持，这么大规模的数据是很难管理的，为了能够给Web绘制出更为详实的地图，计算代理需要对于网络上可用资源的内容和能力做一个机器能够读得懂的描述。这些描述是人类能够读得懂的信息的扩展。 OWL，这种本体描述语言，可以用来描述Web文档和应用中内在的类和关系。 这篇文章解释了OWL语言的使用: 通过定义类以及类的属性来形式化某个领域； 定义个体并说明它们之间的属性； 在OWL语言的形式化语义允许的层次上，对类和个体进行推理。 本文的各章节间是按照类、属性、个体的集合的定义给出来的，从最简单的概念开始，逐渐过渡到更为复杂的概念。 本文档的状态 本文档已被W3C成员及其他相关方面审阅，并已被W3C总监 (W3C Director) 批准为W3C推荐标准 (W3C Recommendation) 。W3C制定推荐标准的任务是使之受到关注，并促使其被广泛应用。这将增强Web的功能性与互操作性。 本文档是W3C关于Web本体语言OWL的推荐标准的六个部分之一。 它已经被Web 本体工作小组(小组章程) 作为W3C语义Web行动 (行动声明) 的一部分于2004年2月10日发布。 本文档的早期版本中所描述的关于OWL的设计已被广泛评阅，并已满足工作小组的技术需求。工作小组充分考虑所有收到的意见，并做了必要的修改。本文档自从候选推荐标准版本以来的所有修改都在文后的变更日志中。 欢迎通过public-webont-comments@w3.org (历史存档)提出您的意见，也可以通过www-rdf-logic@w3.org (mailto:www-rdf-logic@w3.org)(历史存档) 参与相关技术的讨论。 可以访问到有关实现的一个列表。 W3C维护着一个与这些工作相关的专利声明的目录。 这节描述了本文档在发布时的状态。其他文档可能替代这文档。一份当前W3C的最新出版物的目录和这个技术报告的最新版本可以在 W3C技术报告索引http://www.w3.org/TR/ 上找到。 目录 引言 1.1. OWL的种类 1.2. 本文档的结构 本体的结构 2.1. 命名空间 2.2. 本体头部 2.3. 数据集成与隐私 基本元素 (Basic Elements) 3.1. 简单的类和个体 3.1.1. 简单的具名类 3.1.2. 个体 3.1.3. 使用方面的考虑 3.2. 简单属性 3.2.1. 定义属性 (Defining Properties) 3.2.2. 属性和数据类型 ...

RDF OWL http://blogger.org.cn/blog/more.asp?name=babyblue&id=21546 Ontology来源于哲学词汇: 存在论 (也有翻译成本体论) 。RDF是一种不错的本体描述方式，我们可以定义根据对现实世界的理解针对某个领域定义词汇来描述这个领域的知识。但RDF与RDF不能定义同义词、反义词以及描述词与词间的关系 (类与类之间的关系) ，比如说等价性、互补排斥性、限制个数、属性的对称性等。OWL弥补了RDF的不足，运用AI中的逻辑论 (逻辑论中，把人们的思维用式子来表述，并且证明这些式子的正确性) 来赋予网给以语义，形成SW。在SW的定义中，吸收了很多知识的优点，如OO，逻辑论、树结构等。 从HTML到XML HTML是我们最常用的文档标记语言，并且已广泛应用于WEB上。HTML可用来描述资源，但其的特点限制了其生成的文档只有人可以看得懂。HTML有两大不足限制其发展: 一是其结构不明显，很难被应用程序解析；二是描述的局限性，如无法描述某些科学符号。 为了让应用程序能够理解文档，就需要良好的结构，于是最简单但功能强大的树状结构就被采用了。用树状结构来描述数据就生成了XML。XML为在各种应用程序间以及meta数据的交换提供了一致的体系和解析器。但XML本身没有进行任何语义的定义 (或说弱语义定义) ，即其描述的数据的语义机器无法理解。 理解数据的首要条件是更准备地记录数据结构与类型。预定义的最基本的数据类型不能很好地满足大多数现实生活中数据要求。我们需要更清楚地描述数据类型，即更给出数据更严格的限制。XML Schema提供了在预定义的类型上自定义数据类型，而且这种数据类型可以被解析器解析。 XML Schema XML Schema (XML的定义机制) 提供了在XML中可以利用的基本的数据类型 (如date,string等，DTD中只提供了string) ，通过对已有的类型进行扩张或者进行制约，从而定义新的类型。和DTD文档类型不同，XML Schema不需要另外的解析器和编辑器。 但XML Schema只是对文档的结构进行了定义，仍然不能让应用程序理解数据的语义。为了实现让应用程序理解数据，就出现了RDF。 从XML到RDF RDF(Resource Description Framework)并不是一种语言，只是一种书写规范。RDF的基本构造为陈述(或声明，Statement)，表述了一个 (资源，资源所具有的属性，属性值) (即主体—属性—客体) 的三元组。RDF表现的是一个数据模型，简言之就是一个陈述就是一个什么事物 (资源) ，这个事物具有什么属性，这些属性应该有什么样的属性值。XML用来做为描述这种抽象的数据模型的具体书写方式 (不用XML，也可以用其他的构成来表现RDF) 。同样因为现实世界的超级复杂性，预定义的词汇根本不够用，我们就使用RDF Schema来自定义词汇。 RDF描述资源的特性是: 以属性为中心的思考方法。不是重在定义属性的值，而是通过定义拥有这个属性的主体 (资源) 的范围 (定义域) ，以及这个属性的取值范围 (值域) 。这样我们就可以比较精确地定义词汇，不是精确是因为我们不可能也没必要精确定义词汇，我们更关心的是词汇者的相互关系，即我们不能想让机器理解某个词汇，还是要让其理解词汇之间的相互关系，从而能为我们提供智能的服务。 RDF Schema RDFS翻译为资源描述框架的定义机制。其与RDF的关系不同于XML与XMLS间的关系。XMLS是用来对XML的结构 (构造) 进行定义，而RDFS是用来对RDF数据模型用到的词汇进行定义。 RDF+RDFS不能为我们提供描述词汇间的关系，导致OWL的出现。 OWL 是由DAML(DARPA Agent Markup Language)+OIL(Ontology Inference Layer)演变而来。 OWL是RDF的扩张，为我们提供了更广泛的定义RDFS词汇的功能，更广泛意指可以定义词汇之间的关系，类与类间的关系，属性与属性之间的关系等。 RDF是semantic web中MetaData层的资源表述框架，而 OWL应该是Ontology层的概念。 RDF着重于对数据的描述，而OWL则侧重于逻辑推理的准备。

XML RDF OWL XML, RDF, OWL 请先理解RDF和RDF Schema的知识再看这篇文章。不理解的话请参照RDF和RDF Schema在线手册的第一篇相关概念的文章。理解概念很重要，因为对大多数人来说都有编程的基础，可以直接看别的语言的代码。但语义网相关概念是比较新 的概念。所以建议把概念一定到搞懂。通过RDF Schema，我们可以自定义词汇了。但在我们的实际生活当中，我们用的词汇之间都是有联系的。最简单的反义词，同义词。又比如"足球队"这个词，我们每个人脑子都有一个概念，上场比赛需要11个队员。这都是我们在生活中积累的经验。我们想让机器也理解数据的话，最起码要和人一样，也可以定义反义词，同义词，或者词和词之间的一些关系。这些仅仅靠RDF和RDF Schema是不够的。为了达到这个要求，就有了OWL(Web Ontology Language)的出现，Ontolory本是哲学词汇-存在论的意思。大多数中文翻译为本论。其实用原本哲学的意思就很好理解。我们就是在定义词汇，或者词汇之间的关系，或者类之间的关系等等。我们定义了它们，它们就存在于我们的网络里了。我们看看有了它对我们到底有什么好处。比如说它可以定义类和类之间的关系，等价性，互补排斥性，限制个数，属性的对称性等等。似乎还比较模糊，那就举一个具体的例子，比如我们描述这样一个资源: 从北京到上海的距离是400公里。人们听到了这句话后就知道了，上海到北京也是400公里。因为我们知道起点北京到终点上海的距离，和起点上海到终点北京的距离是一样的，也就是我们懂距离，起点，终点这３个词的概念而且知道它们之间的关系，所以我们得出上面的结论。现在我们可以用RDF和RDF Schema来定义这３个词汇，然后我们需要定义的是一个关系，起点－终点的距离等于终点－起点的距离，这里运用到了等价性。这个关系不能用RDF和 RDF Schema来定义，但是可以通过OWL来定义。当然解决这个问题方法可以有许多定义，我只是在这里举个例子。大家应该大概知道OWL是做什么的吧。那么为什么它有这个功能呢？其实它运用了人工智能中的逻辑论，逻辑论把人们的思维用式子来表达，并且可以证明这个式子的正确。其实在语义网的定义中，吸收了很多知识的优点，面向对象，逻辑轮，树结构等等。所以大家学起来，有时会有似曾相识的感觉。下面把大家容易混淆的几个概念XML,XML Schema,RDF,RDF Schema,OWL直接的关系拿出来讲一下。 主要的理解思想就是在语义网的定义中遇到问题了，就会有新的事物被定义或者说是出现. 从HTML到XML HTML的记述是我们最常用的，本来它是用来描述资源的，但是它记录的只有人可以看懂。还有它第一结构不明显，很难被应用程序解析，第二，记述的 局限性，比如某些科学符号无法表达等等。为了让应用程序好理解，就需要有良好的结构。最简单但也是功能很强大的树状结构就被采用了。我们以树状结构来记录数据，这就是XML。XML: 是一种国际通用标记语言。它为在各种应用程序间的数据和meta数据的交换，提供了一致的体系和解析器 (parser) 。但是对于数据的意义没有进行定义，比如说对于某个标签<课程>,也就是本身没有意义，除了结构的不同，它和HTML一样，数据也只有人可以看懂。想让机器理解数据，首先本身的数据类型很重要，不然自己都不知道自己是谁，或者自己是干什么的，怎么可能让机器理解。为了更好的描述资源，也就是说为了更准确的纪录数据的类型。需要我们可以自定义类型，因为预定义的类型只有最基本的类型，不能定义大多数现实生活中的数据类型。对于数据发布人，需要他描述清楚数据类型，也就是说数据的限制等等。所以我们需要一个可以在预定义类型上可以自定义类型，而且它也必须能被解析器解析。所以，就出现了XML Schema。 XML Schema XML Schema: XML的定义机制。和DTD文档类型定义不同，不需要另外的解析器和编辑器。定义的是XML的构造，对已有的类型进行扩张或者进行制约，从而定义了新的类型。XML Schema提供了在XML可以利用的基本的数据类型 (日期，数值等，DTD中只提供了文字列) 。但是即便是这样，它只是对XML文档的构造进行了定义，还是不能让应用程序理解数据。所以为了实现应用程序理解数据，就出现了RDF。 从XML到RDF RDF有时我们会称它为语言，其实这是不对的，RDF是一种书写规范，正确的翻译为资源描述框架。RDF的基本构造为陈述 (或者叫做声明， statement) 了一个资源-资源具有的属性-属性值 (主体-属性-客体) 的三元组。它表现的是一个数据模型，通俗的说一个陈述就是一个什么事物 (资源) 具有什么属性 (属性) ，这个属性是怎样的属性 (属性值) 。我们为了描述抽象的数据模型，需要具体的书写，这就用到了XML，这样RDF就继承了XML的优点。但是不用XML的构成，利用其他的构成也可以表现RDF。所以对RDF而言，XML不是必要的(一般我们的文档格式为RDF/XML就是这个原 因，用XML表示的RDF)。我们终于可以定义一个让机器理解的词汇了，但是它也遇到了一个问题，就是预定义的词汇根本不够用。我们需要自定义一些词汇。为了可以自定义词汇，就出现了RDF Schema。 RDF Schema RDF Schema (RDFS) 翻译为资源描述框架的定义机制，大家也许会比较容易联想到XML和XML Schema的关系，认为它们是同样的。这个想法也是不对的，XML Schema是用来对XML的构造进行定义，而RDFS是用来对RDF数据模型用到的词汇进行定义。我们需要了解一个RDF的特征，它是以属性为中心的思考方法。不是具体定义属性的值，而是定义了拥有这个属性的主体(资源)的范围(定义域)，和这个属性可以取到的值的范围(值域)。这样就我们可以比较精确地定义词汇。为什么说比较精确，而不说精确，因为一个单独存在的词汇对我们毫无意义，即便机器可以理解它。我们语言中的词汇都是互相有关联的，正因为我们 只有知道了词汇的相互关系，我们才可以在生活中正常交流。同样我们一直说让应用程序理解词汇，其实是为了让应用程序理解词汇以及词汇之间的关系，从而自动地，智能地提供给我们服务。为了达到这个目的，描述词汇的关系至关重要。但是RDF和RDF Schema却不能提供给我们这样一个功能，所以也就出现了OWL。 OWL OWL是RDF的扩张，提供我们更广泛的由定义RDF Schema词汇。所谓更广泛就是指可以定义词汇之间的关系，类与类的关系，属性与属性之间的关系等等。具体请参照在线使用手册。 后记 其实每个概念都不难理解，理解的关键在于它们为了什么而出现。OWL的出现也没有能实现最终的目的。所以语义网结构上还有几层，这几层还没有推出规范，所以暂时不做它们的使用手册。

emacs format, 格式化 http://www.blogjava.net/killme2008/archive/2011/07/26/355041.html 格式化源码是很常见的需求，emacs有个indent-region函数用于格式化选定的代码，前提是你处在某个非text mode下，如c-mode或者java-mode之类。如果要格式化整个文件，你需要先选定整个文件(C-x-h)，然后调用indent-region (或者 C-M-\ )。两个命令总是麻烦，我们可以定义个函数搞定这一切，并绑定在一个特定键上，实现一键格式化: ;;格式化整个文件函数 (defun indent-whole () (interactive) (indent-region (point-min) (point-max)) (message "format successfully")) ;;绑定到F7键 (global-set-key [f7] 'indent-whole) 将这段代码添加到你的emacs配置文件 (~/.emacs)，重启emacs，以后格式化源码都可以用F7一键搞定。 整理整个文件 M-x mark-whole-buffer 或者 C-x h //选中整个文件 M-x indent-region 或者 C-M- //格式化选中 整理某个函数 M-x mark-defun 或者 C-M-h //选中函数 M-x indent-region 或者 C-M- //格式化

衬线字体 西方国家字母体系分为两类: serif以及sans serif。 serif是有衬线字体，意思是在字的笔画开始、结束的地方有额外的装饰，而且笔画的粗细会有所不同。相反的，sans serif就没有这些额外的装饰，而且笔画的粗细差不多。 serif字体容易识别，它强调了每个字母笔画的开始和结束，因此易读性比较高，sans serif则比较醒目。在走文阅读的情况下，适合适用serif字体进行排版，易于换行阅读的识别性，避免发生行间的阅读错误。 sans serif强调每一个字母，serif更强调于一个单词。 中文字体中的宋体就是一种最标准的serif字体，衬线的特征非常明显。字形结构也和手写的楷书一致。因此宋体一直被做为最适合的正文字体之一。不过由于强调横竖笔画的对比，在远处观看的时候横线就被弱化，导致识别性的下降 常用的serif (衬线字体) 字体为Time New Roman、Georgia、宋体 常用的sans serif (无衬线字体) 字体为Verdana、Arial、雅黑。 在传统的正文印刷中，普遍认为衬线体能带来更佳的可读性 (相比无衬线体) ，尤其是在大段落的文章中，衬线增加了阅读时对字母的视觉参照。而无衬线体往往被用在标题、较短的文字段落或者一些通俗读物中。相比严肃正经的衬线体，无衬线体给人一种休闲轻松的感觉。随着现代生活和流行趋势的变化，如今的人们越来越喜欢用无衬线体，因为他们看上去"更干净"。有调查显示，欧洲人对于无衬线体的接受度略高于北美，在书籍、报纸和杂志中大段落文字的排版，衬线体始终占据着压倒性的优势。 在文字足够大的情况下，无衬线字体也是同样可读的。而且因为无衬线字体通常有艺术性，因此在显示器上显示通常比较赏心悦目；而且无衬线字体种类比衬线字体多得多，因此选择余地也很大，在这里非衬线字体分类不做赘述。但是必须保证以下原则: 凡是使用无衬线字体的，必须保证其在正文内容中的可读性。否则，使用衬线字体。所以衬线字体在设计中占据很重要的位置；以下是衬线字体的具体分类。 线字体的分类有: 旧式衬线体 (Old style) : Adobe Jenson、Janson、Garamond、Bembo、Goudy Old Style 和 Palatino 过渡衬线体 (Transitional) 又称巴洛克体: Times Roman、Baskerville 现代衬线体 (Modern) : Didot、Bodoni 、Century、Computer Modern 粗衬线 (Slab Serif) 又称埃及体: Rockwell 、Courier、Clarendon

gorun, golang, shell 用 golang 语言编写脚本 install gorun go get github.com/erning/gorun 能用 “./” 执行的 golang代码 /// 2>/dev/null ; gorun "$0" "$@" ; exit $? package main import ( "os/exec" "fmt" "os" ) func main() { println("Hello world!") var whoami []byte var err error var cmd *exec.Cmd cmd = exec.Command("whoami") if whoami, err = cmd.Output(); err != nil { fmt.Println(err) os.Exit(1) } // 默认输出有一个换行 fmt.Println(string(whoami)) } ./hello.go golang shell, 在 golang 中调用 shell func shellExec(command string) string { log.Printf("exec: %s\n", command) cmd := exec.Command("/bin/sh", "-c", command) var out bytes.Buffer cmd.Stdout = &out err := cmd.Run() if err != nil { log.Printf("failed to exec: %s, err: %v", command, err) return "" } ourStr := out.String() log.Printf("exec response: \n%s", ourStr) return ourStr } func shellExecFmt(format string, params ...interface{}) string { return shellExec(fmt.Sprintf(format, params...)) } go 调用 shell https://blog.csdn.net/qq_36874881/article/details/78234005 ...

keyboard character english, 键盘上特殊符号的英文读法 ! 叹号 exclamation mark/bang ? 问号 question mark , 逗号 comma . 点号 dot/period/point : 冒号 colon ; 分号 semicolon " 双引号 quotation marks/double quote/double quotation marks ’ 单引号/撇号 apostrophe/single quote, single quotation mark ` 反引号，重音号 backquote/grave accent * 星号 asterisk/star + 加号 plus sign - 减号/横线 hyphen/dash/minus sign = 等号 equal sign / 斜杠/斜线 slash, forward slash \ 反斜杠/反斜线 backslash/escape | 竖线 bar/pipe/vertical bar _ 下划线 underline/underscore $ 美元符号 dollar sign @ at, at sign # 井号 crosshatch/sharp/hash mark, hash tag % 百分号 percent sign/mod & and/和/兼 and/ampersand ^ 折音号 caret/circumflex ~ 波浪号 tilde {} (左/右) 花括号/大括号 (left/right|open/close) braces [] (左/右) 方括号/中括号 (left/right|open/close) brackets () (左/右) 圆括号/小括号 (left/right|open/close) parentheses <> 尖括号 angle brackets < 大于号 less than > 小于号 greater than … ellipsis https://www.douban.com/group/topic/12410327/

通过java反射机制获取该类的所有属性类型、值 http://blog.csdn.net/sd4000784/article/details/7448221 方法使用了这俩个包下的 field 和method import Java.lang.reflect.Field; import java.lang.reflect.Method; public static void getObjectValue(Object object) throws Exception { //我们项目的所有实体类都继承BaseDomain (所有实体基类: 该类只是串行化一下) //不需要的自己去掉即可 if (object != null && object instanceof BaseDomain) {//if (object!=null ) --begin // 拿到该类 Class<?> clz = object.getClass(); // 获取实体类的所有属性，返回Field数组 Field[] fields = clz.getDeclaredFields(); for (Field field : fields) {// -for() begin System.out.println(field.getGenericType());//打印该类的所有属性类型 // 如果类型是String if (field.getGenericType().toString().equals( "class java.lang.String")) { // 如果type是类类型，则前面包含"class "，后面跟类名 // 拿到该属性的gettet方法 /** * 这里需要说明一下: 他是根据拼凑的字符来找你写的getter方法的 * 在Boolean值的时候是isXXX (默认使用ide生成getter的都是isXXX) * 如果出现NoSuchMethod异常 就说明它找不到那个gettet方法 需要做个规范 */ Method m = (Method) object.getClass().getMethod( "get" + getMethodName(field.getName())); String val = (String) m.invoke(object);// 调用getter方法获取属性值 if (val != null) { System.out.println("String type:" + val); } } // 如果类型是Integer if (field.getGenericType().toString().equals( "class java.lang.Integer")) { Method m = (Method) object.getClass().getMethod( "get" + getMethodName(field.getName())); Integer val = (Integer) m.invoke(object); if (val != null) { System.out.println("Integer type:" + val); } } // 如果类型是Double if (field.getGenericType().toString().equals( "class java.lang.Double")) { Method m = (Method) object.getClass().getMethod( "get" + getMethodName(field.getName())); Double val = (Double) m.invoke(object); if (val != null) { System.out.println("Double type:" + val); } } // 如果类型是Boolean 是封装类 if (field.getGenericType().toString().equals( "class java.lang.Boolean")) { Method m = (Method) object.getClass().getMethod( field.getName()); Boolean val = (Boolean) m.invoke(object); if (val != null) { System.out.println("Boolean type:" + val); } } // 如果类型是boolean 基本数据类型不一样 这里有点说名如果定义名是 isXXX的 那就全都是isXXX的 // 反射找不到getter的具体名 if (field.getGenericType().toString().equals("boolean")) { Method m = (Method) object.getClass().getMethod( field.getName()); Boolean val = (Boolean) m.invoke(object); if (val != null) { System.out.println("boolean type:" + val); } } // 如果类型是Date if (field.getGenericType().toString().equals( "class java.util.Date")) { Method m = (Method) object.getClass().getMethod( "get" + getMethodName(field.getName())); Date val = (Date) m.invoke(object); if (val != null) { System.out.println("Date type:" + val); } } // 如果类型是Short if (field.getGenericType().toString().equals( "class java.lang.Short")) { Method m = (Method) object.getClass().getMethod( "get" + getMethodName(field.getName())); Short val = (Short) m.invoke(object); if (val != null) { System.out.println("Short type:" + val); } } // 如果还需要其他的类型请自己做扩展 }//for() -end }//if (object!=null ) --end } // 把一个字符串的第一个字母大写、效率是最高的、 private static String getMethodName(String fildeName) throws Exception{ byte[] items = fildeName.getBytes(); items[0] = (byte) ((char) items[0] - 'a' + 'A'); return new String(items); }

STAR STAR is an acronym for Situation, Task, Action, Result 什么是STAR法则？ The STAR (Situation, Task, Action, Result) format is a job interview technique used by interviewers to gather all the relevant information about a specific capability that the job requires. This interview format is said to have a higher degree of predictability of future on-the-job performance than the traditional interview. STAR法则是情境 (situation）、任务 (task）、行动 (action）、结果 (result）四项的缩写。STAR法则是一种常常被面试官使用的工具，用来收集面试者与工作相关的具体信息和能力。STAR法则比起传统的面试手法来说，可以更精确地预测面试者未来的工作表现。 Situation: The interviewer wants you to present a recent challenge and situation in which you found yourself. 情境：面试官希望你能描述一个最近遇到的挑战或情况。 ...

Connection reset 在使用HttpClient调用后台resetful服务时，“Connection reset”是一个比较常见的问题，有同学跟我私信说被这个问题困扰很久了，今天就来分析下，希望能帮到大家。例如我们线上的网关日志就会抛该错误： 从日志中可以看到是Socket socket 在read数据时抛出了该错误。 导致“Connection reset”的原因是服务器端因为某种原因关闭了Connection，而客户端依然在读写数据，此时服务器会返回复位标志“RST”，然后此时客户端就会提示“java.net.SocketException: Connection reset”。 可能有同学对复位标志“RST”还不太了解，这里简单解释一下： TCP建立连接时需要三次握手，在释放连接需要四次挥手；例如三次握手的过程如下： 第一次握手：客户端发送syn包 (syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认； 第二次握手：服务器收到syn包，并会确认客户的SYN (ack=j+1），同时自己也发送一个SYN包 (syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED (TCP连接成功）状态，完成三次握手。 可以看到握手时会在客户端和服务器之间传递一些TCP头信息，比如ACK标志、SYN标志以及挥手时的FIN标志等。 除了以上这些常见的标志头信息，还有另外一些标志头信息，比如推标志PSH、复位标志RST等。其中复位标志RST的作用就是“复位相应的TCP连接”。 TCP连接和释放时还有许多细节，比如半连接状态、半关闭状态等。详情请参考这方面的巨著《TCP/IP详解》和《UNIX网络编程》。 前面说到出现“Connection reset”的原因是服务器关闭了Connection[调用了Socket.close()方法]。大家可能有疑问了：服务器关闭了Connection为什么会返回“RST”而不是返回“FIN”标志。原因在于Socket.close()方法的语义和TCP的“FIN”标志语义不一样：发送TCP的“FIN”标志表示我不再发送数据了，而Socket.close()表示我不在发送也不接受数据了。问题就出在“我不接受数据” 上，如果此时客户端还往服务器发送数据，服务器内核接收到数据，但是发现此时Socket已经close了，则会返回“RST”标志给客户端。当然，此时客户端就会提示：“Connection reset”。详细说明可以参考oracle的有关文档：http://docs.oracle.com/javase/1.5.0/docs/guide/net/articles/connection_release.html。 另一个可能导致的“Connection reset”的原因是服务器设置了Socket.setLinger (true, 0)。但我检查过线上的tomcat配置，是没有使用该设置的，而且线上的服务器都使用了nginx进行反向代理，所以并不是该原因导致的。关于该原因上面的oracle文档也谈到了并给出了解释。 此外啰嗦一下，另外还有一种比较常见的错误“Connection reset by peer”，该错误和“Connection reset”是有区别的： 服务器返回了“RST”时，如果此时客户端正在从Socket socket 的输出流中读数据则会提示Connection reset”； 服务器返回了“RST”时，如果此时客户端正在往Socket socket 的输入流中写数据则会提示“Connection reset by peer”。 “Connection reset by peer”如下图所示： 前面谈到了导致“Connection reset”的原因，而具体的解决方案有如下几种： 出错了重试； 客户端和服务器统一使用TCP长连接； 客户端和服务器统一使用TCP短连接。 首先是出错了重试：这种方案可以简单防止“Connection reset”错误，然后如果服务不是“幂等”的则不能使用该方法；比如提交订单操作就不是幂等的，如果使用重试则可能造成重复提单。 然后是客户端和服务器统一使用TCP长连接：客户端使用TCP长连接很容易配置 (直接设置HttpClient就好），而服务器配置长连接就比较麻烦了，就拿tomcat来说，需要设置tomcat的maxKeepAliveRequests、connectionTimeout等参数。另外如果使用了nginx进行反向代理或负载均衡，此时也需要配置nginx以支持长连接 (nginx默认是对客户端使用长连接，对服务器使用短连接）。 使用长连接可以避免每次建立TCP连接的三次握手而节约一定的时间，但是我这边由于是内网，客户端和服务器的3次握手很快，大约只需1ms。ping一下大约0.93ms (一次往返）；三次握手也是一次往返 (第三次握手不用返回）。根据80/20原理，1ms可以忽略不计；又考虑到长连接的扩展性不如短连接好、修改nginx和tomcat的配置代价很大 (所有后台服务都需要修改）；所以这里并没有使用长连接。ping服务器的时间如下图： 最后的解决方案是客户端和服务器统一使用TCP短连接：我这边正是这么干的，而使用短连接既不用改nginx配置，也不用改tomcat配置，只需在使用HttpClient时使用http1.0协议并增加http请求的header信息 (Connection: Close），源码如下： 最后再补充几句，虽然对于每次请求TCP长连接只能节约大约1ms的时间，但是具体是使用长连接还是短连接还是要衡量下，比如你的服务每天的pv是1亿，那么使用长连接节约的总时间为： 神奇的是，亿万级pv的服务使用长连接一天内节约的总时间为27.78小时 (竟然大于一天）。 ...

XHTML HTML5 http://www.wkeke.cn/archives/xhtml2-html5/ 下面这些迹象都一一表明: XHTML2夭亡，而HTML5则是集万千宠爱于一身，还未出现，早已博得满堂喝彩。W3C 日前宣布将从2009年底起终止同 XHTML 2 工作组的合约，并以此暗示曾经一度野心勃勃的 XHTML 2 的正式死亡。Web 设计界是否该因此而恐慌？毕竟 XHTML 1.x 是所有对 Web 标准验证有着某种情节的人的首选，然而事实并非如此，XHTML 2.0 偃旗息鼓已有时日，W3C 只是明确了它的死亡日期，并将主要精力倾注到他们的新宠儿，HTML 5 身上。 如何看待 Web 设计师们所钟爱的 XHTML？ 要弄明白 XHTML 如何获得人们的青睐，得从 HTML4 说起。HTML 4 是一种松散的语言，它拥有很多选项，囊括了太多人们对 Web 的试验性想法，一些是好的，一些是坏的，然而，要 HTML 4 为蹩脚的网页代码负责，好比要英语为低劣的小说负责。 HTML 4 也可以结构严谨并拥有合法的语义，只要设计师们知道该如何使用它。 而 XHTML 1.0 更严格，那些验证工具更容易指出其中的错误，如果你很懒，又想保证自己的代码结构严谨，XHTML 1.x 要容易检查得多。 然而问题是，XHTML 的使命并非单单如此，XHTML 的使命在于它名字中的那个 X，X 的存在不是为了耍酷，而是因为 XHTML 事实上属于 XML。象正在为 HTML 5 细则工作的 Henri Sivonen 指出的那样，XHTML 事实上有两个意义，一是技术上的，一是市场上的。 从技术的角度，XHTML 原本是要以 application/xhtml+xml MIME 类型输出纯粹的 XML 的，然而这种情形很少见，这并非说 XML 不重要，事实上未来的 XHTML 5 将对 HTML 5 提供序列化服务。而 XHTML 的大量使用更多是基于市场的角度，换句话说，那些采用 XHTML 语法的网页仍然被浏览器按 text/html MIME 类型渲染，因此，尽管这些文档属于 XML，但它们并没被当作真正的 XML，而是按 HTML 进行渲染。 ...

HTML XHTML 什么是XHTML？与HTML相比XHTML有什么特点？ http://www.wm23.com/resource/R01/Internet_1010.htm HTML是一种基本的WEB网页设计语言，XHTML是一个基于XML的置标语言，看起来与HTML有些相象，只有一些小的但重要的区别。本文简单介绍什么是XHTML，以及与HTML相比XHTML有什么特点。 什么是XHTML？ HTML是一种基本的WEB网页设计语言，XHTML是一个基于XML的置标语言，看起来与HTML有些相象，只有一些小的但重要的区别，XHTML就是一个扮演着类似HTML的角色的XML，所以，本质上说，XHTML是一个过渡技术，结合了XML (有几分) 的强大功能及HTML (大多数) 的简单特性。 2000年底，国际W3C(World Wide Web Consortium)组织公布发行了XHTML 1.0版本。XHTML 1.0是一种在HTML 4.0基础上优化和改进的的新语言，目的是基于XML应用。XHTML是一种增强了的HTML,它的可扩展性和灵活性将适应未来网络应用更多的需求。下面是W3C的HTML工作组主席Steven Pemberton回答的关于XHTML的常见基础问题。 问: 什么是XHTML? 答: XHTML是一种为适应XML而重新改造的HTML。当XML越来越成为一种趋势，就出现了这样一个问题: 如果我们有了XML，我们是否依然需要HTML?为了回答这个问题，1998年5月我们在旧金山开了两天的工作会议，会议的结论是: 需要。我们依然需要使用HTML。因为大量的人们已经习惯使用HTML来作为他们的设计语言，而且，已经有数以百万计的页面是采用HTML编写的。 问: 为什么XHTML 1.0相对HTML 4.0独立发展? 答: 并不是这样。XHTML恰恰就是HTML 4.0的重新组织，(确切的说它是HTML 4.01，是一个修正版本的HTML 4.0，只不过以XHTML 1.0命名发行。) 它们在XML里的解释会有一些必要的差别，但另一方面，它们依然非常相似，我们可以把XHTML的工作看作是HTML 4.0基础上的延续。 问: XHTML 1.0如何实现XML标准? 答: XHTML就是一种XML应用。它采用XML的DTD文件格式定义，并运行在支持XML的系统上。这里要感谢XML的Namespaces功能，浏览器制造商不需要再创造新的私有标签(tags)，他们只需要在XHTML代码里包含XML代码片段，或者XML代码里包含XHTML代码片段。 与HTML相比XHTML有什么特点？ (1) XHTML解决HTML语言所存在的严重制约其发展的问题。HTML发展到今天存在三个主要缺点: 不能适应现在越多的网络设备和应用的需要，比如手机、PDA、信息家电都不能直接显示HTML；由于HTML代码不规范、臃肿，浏览器需要足够智能和庞大才能够正确显示HTML；数据与表现混杂，这样你的页面要改变显示，就必须重新制作HTML。因此HTML需要发展才能解决这个问题，于是W3C又制定了XHTML，XHTML是HTML向XML过度的一个桥梁。 (2) XML是web发展的趋势，所以人们急切的希望加入XML的潮流中。XHTML是当前替代HTML4标记语言的标准，使用XHTML 1.0，只要你小心遵守一些简单规则，就可以设计出既适合XML系统，又适合当前大部分HTML浏览器的页面。这个意思就是说，你可以立刻设计使用XML，而不需要等到人们都使用支持XML的浏览器。这个指导方针可以使web平滑的过渡到XML。 (3) 使用XHTML的另一个优势是: 它非常严密。当前网络上的HTML的糟糕情况让人震惊，早期的浏览器接受私有的HTML标签，所以人们在页面设计完毕后必须使用各种浏览器来检测页面，看是否兼容，往往会有许多莫名其妙的差异，人们不得不修改设计以便适应不同的浏览器。 (4) XHTML是能与其它基于XML的标记语言、应用程序及协议进行良好的交互工作。 (5) XHTML是Web标准家族的一部分，能很好在无线设备等其它用户代理上。 (6) 在网站设计方面，XHTML可助你去掉表现层代码的恶习，帮助你养成标记校验来测试页面工作的习惯。 【说明】: 本文根据部分网站上的相关资料编辑，来源包括: http://www.pconline.com.cn/pcedu/sj/wz/other/0406/385830.html http://hedong.3322.org/newblog/archives/000044.html http://www.pconline.com.cn/pcedu/sj/wz/other/0410/469461.html

迭代规划 团队会在Sprint开始之初召开Sprint计划会议并制定目标，团队成员会在Scrum每日例会上分享工作进展。当Sprint快结束时，团队会在评审会议中将进展展示给项目干系人。紧接着评审会议之后是回顾会，会上总结当前Sprint中团队的合作情况并为后续Sprint寻找可改进的地方。 计划会 Sprint开始时，团队与项目负责人共同制定下个Sprint的计划，这需要两个会议：Sprint优先级会议和Sprint计划会议。其中优先级会议需要准备产品Backlog、用户故事，并识别潜在的Sprint目标，而计划会议需要构建当前Sprint的Backlog，以确实际开发任务。 优先级会议 Sprint优先级会议的目的是挑出产品Backlog上优先级高的条目，并选择潜在的Sprint目标。我们在产品需求池通过属性来配置任务的优先级。 (图：任务的优先级设置） 在排序之后，PO和团队便可以挑选出高优先级的需求功能作为Sprint的目标。如果高优先级功能实在太多，无法在一个Sprint中完成，这些功能就要分解成更小、更适宜在同一Sprint中完成的小功能，然后放入已创建好的Sprint中。 (图：一个Sprint中的需求功能） 计划会议 在确定当前Sprint的目标需求后，团队从每个需求中分解出任务条目以构成Sprint的Backlog，这是在Sprint计划会议上面进行的，这个会议的参与者包括PO、Scrum Master以及团队中的每个人，和可以帮团队更好预估工作量的各领域专家。 (图：构建一个Sprint Backlog流程） 大家需要在会上讨论每个需求的设计与实现，最好的预估工作量的方法是检查团队过去Sprint中的工作完成情况，比如团队在近期的几个Sprint中完成了平均400小时的工作量，他们就有把握承诺在下个Sprint中完成同样多的工作量。除此之外，一个Sprint是否包括节假日、是否有重要员工离职以及其他影响 (比如是否在开发需要试错的新模块）等等因素也需要考虑进来，最终形成一个可按时交付的Sprint Backlog。 https://ones-ai.gitbooks.io/ones-ai/content/31-si-ge-gai-nian/43-gui-hua-die-dai.html

path, absolute path, and canonical path http://www.avajava.com/tutorials/lessons/whats-the-difference-between-a-files-path-absolute-path-and-canonical-path.html What’s the difference between a file’s path, absolute path, and canonical path? Author: Deron Eriksson Description: This Java tutorial describes a file’s path, absolute path, and canonical path. Tutorial created using: Windows XP || JDK 1.5.0_09 || Eclipse Web Tools Platform 2.0 (Eclipse 3.3.0) This tutorial will examine the differences between a file’s path, absolute path, and canonical path. The FilePaths class will display data about several files and directories in the project. In JavaSW, a File object can represent a file or a directory. If a File object represents a directory, a call to its isDirectory() method returns true. Our project consists of the FilePaths class plus several files and directories. ...

URI, URL, URN http://www.ibm.com/developerworks/cn/xml/x-urlni.html http://www.wiloon.com/en/US/partners/index.html 是一个 URI 方案名: http 域名: www.wiloon.com 路径: /en/US/partners/index.html URI 按照 UNIX® 的惯例采用了正斜杠 (a/b/c)，因为在 20 世纪 80 年代后期设计 URI 的时候, 在 Internet 上， UNIX 文化比 PC 文化更流行。 URI 可以进一步分为定位器、名称，或者二者兼具。术语"Uniform Resource Locator" (URL) 涉及的是 URI 的子集，除识别资源外，它还通过描述其最初访问机制 (比如它的网络"位置") 来提供定位资源的方法。 术语"Uniform Resource Name" (URN) 在历史上曾用于引用"urn"方案 [RFC2141] 下的 URI，这个 URI 需要是全球惟一的，并且在资源不存在或不再可用时依然保持不变，对于其他任何拥有名称的一些属性的 URI，都需要使用这样的 URI。 对于单独的方案，没有必要将其分为仅仅是一个 “名称"或者是一个"定位器”。 来自任意特定方案的 URI 实例可能有名称或定位器的特征，或两者兼而有之， 这通常取决于标识符分配中的持久性和命名机构对其关注程度， 而不取决于其他方案的质量。未来的规范和相关的文档应当使用通用术语"URI"，而不是使用有更多限制的条目"URL"和"URN" [RFC3305]。