Re: 充电时不能玩手机? (转载)

发信人: mrredsnow (BirdFans_2), 信区: Joke标 题: Re: 充电时不能玩手机? (转载)发信站: 水木社区 (Wed Sep 28 13:05:51 2016), 站内

兄台这么捧场,那我就返个场,多说一个小段,还是这兄弟的事儿,还是他读硕士期间的事儿

硕士宿舍两张高低床,住三个人,第四个铺放行李,我这同学,同宿舍的两位,都是在职的,一直不住宿舍,因此,整个宿舍,三个铺位,但是只有他一个人住,有一天,有一个高中同学从外地过来玩儿,本地的几个同学也过来一起聚聚,一高兴就聊到半夜了,要不大家凑活一下,别走了,四个人,三个床铺,咋分

硕士同学提议,外地来的同学是客人,肯定单独一个床铺,剩下三个人手心手背,分出1:2,两个一样的睡一张床,结果我跟他俩不一样,硕士同学脑子聪明,立刻说,三局两胜,结果第二局,另一个同学赢了,第三局很关键,硕士同学动了小心眼了,他决定自己慢点出,看看我俩是啥,然后作个弊,我俩出来后,硕士同学愣住了,半天没伸出手来,我说,你可以选择跟我俩谁睡

【 在 vinbo (vinbo) 的大作中提到: 】: 这两个段子放回帖里可惜了,单列出来可以加精的吧。。。

※ 来源:·水木社区 http://newsmth.net·[FROM: 124.205.63.*]

使用余弦定理计算文本相似度

什么是余弦定理

学过向量代数的人都知道,向量实际上是多维空间中有方向的线段。如果两个向量的方向一致,即夹角接近零,那么这两个向量就相近。而要确定两个向量方向是否一致,这就要用到余弦定理计算向量的夹角了。

余弦定理对我们每个人都不陌生,它描述了三角形中任何一个夹角和三个边的关系,换句话说,给定三角形的三条边,我们可以用余弦定理求出三角形各个角的角度。假定三角形的三条边为 a, b 和 c,对应的三个角为 A, B 和 C,那么角 A 的余弦:

如果我们将三角形的两边 b 和 c 看成是两个向量,那么上述公式等价于:

其中分母表示两个向量 b 和 c 的长度,分子表示两个向量的内积。举一个具体的例子,假如文本X 和文本 Y 对应向量分别是

x1,x2,…,x64000 y1,y2,…,y64000

那么它们夹角的余弦等于:

当两个文本向量夹角的余弦等于1时,这两个文本完全重复;当夹角的余弦接近于一时,两条新闻相似;夹角的余弦越小,两条文本越不相关。

计算文本相似度的大致流程

假设有下面两个句子:

A:我喜欢看电视,不喜欢看电影。 B:我不喜欢看电视,也不喜欢看电影。

第一步:分词

A:我/喜欢/看/电视,不/喜欢/看/电影。 B:我/不/喜欢/看/电视,也/不/喜欢/看/电影。

第二步:列出所有的词、字

我,喜欢,看,电视,电影,不,也

第三步:计算词频

A:我 1,喜欢 2,看 2,电视 1,电影 1,不 1,也 0。 B:我 1,喜欢 2,看 2,电视 […]

使用Python对全角字符半角字符互转

在文本处理的时候,经常会遇到全角半角不一致的问题。于是需要程序能够快速的在两者之间互转。由于全角半角本身存在着映射关系,所以处理起来并不复杂。具体规则为:

全角字符unicode编码从65281~65374 (十六进制 0xFF01 ~ 0xFF5E) 半角字符unicode编码从33~126 (十六进制 0x21~ 0x7E) 空格比较特殊,全角为 12288(0x3000),半角为 32(0x20) 而且除空格外,全角/半角按unicode编码排序在顺序上是对应的(半角 + 65248 = 全角)

所以可以直接通过用+-法来处理非空格数据,对空格单独处理。

用到的一些函数

chr()函数用一个范围在range(256)内的(就是0~255)整数作参数,返回一个对应的字符。 unichr()跟它一样,只不过返回的是Unicode字符。 ord()函数是chr()函数或unichr()函数的配对函数,它以一个字符(长度为1的字符串)作为参数,返回对应的ASCII数值,或者Unicode数值。

先来打印下映射关系:

for i in xrange(33,127): print i,chr(i),i+65248,unichr(i+65248)

返回结果

33 ! 65281 ! 34 ” 65282 " 35 # 65283 # 36 $ 65284 $ 37 % 65285 % 38 & 65286 & […]

推荐系统、搜索引擎、自然语言处理常用指标

机器学习(ML)、自然语言处理(NLP)、信息检索(IR)等领域评估是一个必要的工作。

精确率(Precision)与召回率(Recall) 准确率 = 检索出的相关文档数/检索出的文档总数 = 查准率 召回率 = 检索出的相关文档数/文档库中所有相关文档数 = 查全率

假如某个班级有男生80人,女生20人,共计100人,目标是找出所有女生。现在某人挑选出50个人,其中20人是女生,另外还错误的把30个男生也当作女生挑选出来了。

准确率 = 20/50=40% 召回率 = 20/20=100%

我们希望检索结果Precision越高越好,同时Recall也越高越好,但事实上这两者在某些情况下有矛盾的。比如极端情况下,我们只搜索出了一个结果,且是准确的,那么Precision就是100%,但是Recall就很低;而如果我们把所有结果都返回,那么比如Recall是100%,但是Precision就会很低。因此在不同的场合中需要自己判断希望Precision比较高或是Recall比较高。

如果希望被检索到的内容越多越好,这是追求“召回率” 如果希望检索到的文档中,真正想要的、也就是相关的越多越好,不相关的越少越好,这是追求“准确率”

如果是做搜索,那就是保证召回的情况下提升准确率;如果做疾病监测、反垃圾,则是保准确率的条件下,提升召回。如果是做实验研究,可以绘制Precision-Recall曲线来帮助分析。

综合评价指标(F-Measure)

P和R指标有时候会出现的矛盾的情况,这样就需要综合考虑他们,最常见的方法就是F-Measure(又称为F-Score)。

F-Measure是Precision和Recall加权调和平均:

当参数α=1时,就是最常见的F1,即

还是上面的例子,F1=2*40%*100%/(40%+100%)=57.14%

E值

E值表示准确率P和召回率R的加权平均值,当其中一个为0时,E值为1,其计算公式:

b越大,表示准确率的权重越大。

mAP(mean Average Precision)

mAP是为解决P,R,F-measure的单点值局限性的。为了得到 一个能够反映全局性能的指标,可以看考察下图,其中两条曲线(方块点与圆点)分布对应了两个检索系统的准确率-召回率曲线。

 

可以看出,虽然两个系统的性能曲线有所交叠但是以圆点标示的系统的性能在绝大多数情况下要远好于用方块标示的系统。从中我们可以 发现一点,如果一个系统的性能较好,其曲线应当尽可能的向上突出。

更加具体的,曲线与坐标轴之间的面积应当越大。

最理想的系统, 其包含的面积应当是1,而所有系统的包含的面积都应当大于0。这就是用以评价信息检索系统的最常用性能指标,平均准确率mAP其规范的定义如下:(其中P,R分别为准确率与召回率,Q为检索次数)

参考链接:

https://en.wikipedia.org/wiki/Information_retrieval http://www.cnblogs.com/maybe2030/p/5375175.html

Related posts:

SQL Server中调用C#程序 百度索引库有多大 […]

细说中文分词

完整的中文自然语言处理过程一般包括以下五种中文处理核心技术:分词、词性标注、命名实体识别、依存句法分析、语义分析。其中,分词是中文自然语言处理的基础,搜素引擎、文本挖掘、机器翻译、关键词提取、自动摘要生成等等技术都会用到中文分词,包括最近在学习的聊天机器人、文本相似性等。可以说分词是自然语言大厦的地基,下面就让我们从它开始谈起。

什么是中文分词

中文分词就是将中文语句中的词汇按照使用时的含义切分出来的过程,也就是将一个汉字序列切分成一个个有单独含义的词语。自20世纪80年代以来,中文自动分词就一直是一个研究热点,由于中文语言的复杂性使之一直处于发展阶段。目前,分词主要包含细粒度分词和粗粒度分词两种,在不同的应用场景需要用到不同的粒度。细粒度分词是指将原始语句切分成最基本的词语,而粗粒度分词是指将原始语句中的多个基本词组合起来切成一个词,进而组成语义相对明确的实体。

原始串:浙江大学坐落在西湖旁边 细粒度:浙江/大学/坐落/在/西湖/旁边 粗粒度:浙江大学/坐落/在/西湖/旁边 为什么要中文分词

对于中文而言,词是承载语义的最小单元,由词构成语句,又由语句构成篇章。但是,中文文本是由连续的字序列构成,词与词之间是没有天然的分隔符。在自然语言处理领域,国外已经做出了很多卓有成效的研究,但是那些研究大多基于英文(存在天然的分隔符),也就是说是以正确切分出单词为前提的。于是,NLP对于中文而言要想取得较好的科研成果,就需要准确识别词与词之间的边界,也就是分词。

接下来我们就以搜索为例,具体的阐述一下分词的重要性与必要性。大家都知道,目前的搜素引擎是基于一种叫做倒排索引的结构,以什么作为索引的key值,直接影响到整个搜索引擎的准确度、召回率以及性能。

如果不使用中文分词,可以采用单个汉字索引方式。例如“标点符”,会先索引“标”字,再索引“点”字,再索引“符”字。搜索过程中,也是先寻找“标”字关联的所有文档,再寻找“点”字关联的所有文档,再寻找“符”字关联的所有文档,最后对所有被检索出的文档做“与”运算,同时“标点符”位置连续的文档才算符合要求。这种方式存在一个非常挑战性的问题,常用汉字总共3000左右,每次查询过程中进行“与”操作的计算量会相当大。对于大数据量的搜索引擎来讲,每天面临亿万级别的查询,这样的索引结构无疑是灾难性的。

为了优化上面提到的速度问题,还有另外一种索引结构也是可以避开中文分词的,那就是n元组合索引方式。用2元索引来说,“标点符”,会先索引“标点”,再索引“点符”。在搜索过程中,也是对“标点”和“点符”检索出的文章进行“与”运算。这样的搜索过程会大大减少在搜索过程中的计算量,但是仍会面临另外一个问题:准确度。有很多这样的例子,搜“北大”会检索出“东北大学”,搜“的士”会出现“不想当将军的士兵不是好士兵”。对于大数据量的搜索引擎系统来说,这样的用户体验是极差的。

中文分词面临的挑战

在知道分词的重要性之后,那么我们会面临一个新的问题,如何才能把一个字序列准确的切分成词序列,就像下面的例子会有不止一种的切分方式。

原始字符串:结婚的和尚未结婚的

切分一:结婚/的/和尚/未/结婚/的 切分二:结婚/的/和/尚未/结婚/的

还有更极端的例子,“中外科学名著”中,“中外”、“外科”、科学”、“学名”、“名著”都是合理的词语。类似的例子数不胜数,“提高产品质量”,“鞭炮声响彻夜空”。在中文分词的世界里,最主要的挑战有两个:歧义词识别,未登录词识别。

歧义词

上文提到的歧义词例子,有学者试图通过逆向匹配来解决。但是,碰到这句“结合成分子”时,采用逆向匹配,则会分成“结合/成分/子时”。一般当一个字可以同时作为两个词的组成部分,当这两个词按序同时出现时,就可能会出现歧义现象。目前的歧义一般分为三种:交叉歧义,组合歧义,真歧义。

交叉歧义(字符串AJB,AJ和JB都是一个汉语词汇,会存在多种切分交叉在一起):“你说的确实在理”,“的确”和“确实”就是交叉型歧义片段。 组合歧义(字符串AB是一个词汇,A和B同时也是词汇,会存在不同语义下切分不同):“这个人手上有颗痣”,“目前人手紧缺”。前者是“人”/“手”两个实体词,后者是“人手”一个实体词。 真歧义(怎么切分都合理):“乒乓球拍卖完了”,切分为以下两种情况都是合理的,“乒乓球拍/卖/完了”,“乒乓球/拍卖/完了”。 未登录词

所谓的未登录词是指在分词词典中没有收录,并且确实是大家公认的词语的那些词语,一般又叫做新词。最典型的未登录词就是人名词,“李胜利喜欢唱歌”中“李胜利”是个人名词,如果把“李胜利”这个基本词条收录到字典中去是能解决这个问题。但是,每时每刻都有新增的姓名,完整收录全部人名本身就是一个不现实的工程。中外人名、中国地名、机构组织名、事件名、货币名、缩略语、派生词、各种专业术语以及在不断发展和约定俗成的一些新词语。在当下的互联网时代,人们还会不断的创造出一些新词出来,比如:“神马”、“不明觉厉”等。未登录词辨别未登录词包括是种类繁多,形态组合各异,规模宏大的一个领域。对这些词语的自动辨识,是一件非常困难的事。

新词是中文分词算法在召回层面上最主要的难题,也是评价一个分词系统好坏的重要标志。如果一个新词无法被分词系统识别,会导致很多噪音数据被召回,进而会影响后面的句法分析和语义分析等相关处理。黄昌宁等在中文信息学报上的《中文分词十年回顾》一文指出:新词带来的分词问题是歧义的10倍~20倍,所以说新词发现是分词面临的最大挑战。

中文分词的技术分类

从上世纪80年代开始对中文自动分词进行研究,在过去的近40年中,中文分词的发展过程基本上可分为以下三个阶段,如下图所示:

我们讨论的分词算法可分为三大类:

基于词典:基于字典、词库匹配的分词方法;(字符串匹配、机械分词法) 基于统计:基于词频度统计的分词方法 基于规则:基于知识理解的分词方法 基于词典的分词

中文自动分词第一阶段,从80年代到90年代中,以基于词典和人工规则的方法为主,典型的方法有:正向最大匹配,逆向最大匹配,最少词切分法,双向匹配法。这种方法又叫做机械分词方法,它是按照一定的策略将待分析的汉字串与一个“充分大的”机器词典中的词条进行配,若在词典中找到某个字符串,则匹配成功(识别出一个词)。按照扫描方向的不同,串匹配分词方法可以分为正向匹配和逆向匹配;按照不同长度优先匹配的情况,可以分为最大(最长)匹配和最小(最短)匹配;常用的几种机械分词方法如下:

最大正向匹配法(MM, MaximumMatching Method,MM)

通常简称为MM法。其基本思想为:假定分词词典中的最长词有i个汉字字符,则用被处理文档的当前字串中的前i个字作为匹配字段,查找字典。若字典中存在这样的一个i字词,则匹配成功,匹配字段被作为一个词切分出来。如果词典中找不到这样的一个i字词,则匹配失败,将匹配字段中的最后一个字去掉,对剩下的字串重新进行匹配处理…… 如此进行下去,直到匹配成功,即切分出一个词或剩余字串的长度为零为止。这样就完成了一轮匹配,然后取下一个i字字串进行匹配处理,直到文档被扫描完为止。其算法描述如下:

从左向右取待切分汉语句的m个字符作为匹配字段,m为大机器词典中最长词条个数。 查找大机器词典并进行匹配。若匹配成功,则将这个匹配字段作为一个词切分出来。若匹配不成功,则将这个匹配字段的最后一个字去掉,剩下的字符串作为新的匹配字段,进行再次匹配,重复以上过程,直到切分出所有词为止。

举个例子:我们对“南京市长江大桥”这个句子进行分词,根据正向最大匹配的原则。先从句子中拿出前5个字符“南京市长江”,把这5个字符到词典中匹配,发现没有这个词,那就缩短取字个数,取前四个“南京市长”,发现词库有这个词,就把该词切下来;对剩余三个字“江大桥”再次进行正向最大匹配,会切成“江/大桥”;整个句子切分完成为:“京市长/江/大桥。”

逆向最大匹配法(ReverseMaximum Matching Method,RMM)

通常简称为RMM法。RMM法的基本原理与MM法相同 ,不同的是分词切分的方向与MM法相反,而且使用的分词辞典也不同。逆向最大匹配法从被处理文档的末端开始匹配扫描,每次取最末端的2i个字符(i字字串)作为匹配字段,若匹配失败,则去掉匹配字段最前面的一个字,继续匹配。相应地,它使用的分词词典是逆序词典,其中的每个词条都将按逆序方式存放。在实际处理时,先将文档进行倒排处理,生成逆序文档。然后,根据逆序词典,对逆序文档用正向最大匹配法处理即可。

还是那个例子:取出“南京市长江大桥”的后四个字“长江大桥”,发现词典中有匹配,切割下来;对剩余的“南京市”进行分词,整体结果为:“南京市/江大桥”

由于汉语中偏正结构较多,若从后向前匹配,可以适当提高精确度。所以,逆向最大匹配法比正向最大匹配法的误差要小。统计结果表明,单纯使用正向最大匹配的错误率为1/169,单纯使用逆向最大匹配的错误率为1/245。

例如切分字段“硕士研究生产”,正向最大匹配法的结果会是“硕士研究生/产”,而逆向最大匹配法利用逆向扫描,可得到正确的分词结果“硕士/研究/生产”。但这种精度还远远不能满足实际的需要。实际使用的分词系统,都是把机械分词作为一种初分手段,还需通过利用各种其它的语言信息来进一步提高切分的准确率。

双向最大匹配法(Bi-directction Matching method,BM)

双向最大匹配法是将正向最大匹配法得到的分词结果和逆向最大匹配法的到的结果进行比较,从而决定正确的分词方法。据SunM.S. […]

SegmentFault问答排序算法

SegmentFault 参考了Stack Overflow的热门算法设置了自己的排序算法,具体排序算法如下:

热门文章

对于热门文章,使用了如下公式:

其中

views:浏览量,对浏览量做了一次去对数处理,主要是为了防止某些浏览量较大的文章异军突起,待在榜单迟迟不动。 recommendScore/collectScore:文章的推荐数和收藏数,直接加和到分子中,作为文章热门程度的考虑因素。 articleComments:文章评论数,这个也作为一个影响文章热度的因素,不过为了降低其影响,对其作了一次取对数操作,主要是考虑到评论数量的影响力并没有上面两个的高。 (age/2 + update/2 + 1) ^ i:分母是对时间因子的考虑,宏观上来看,就是文章热度和创建时间成反比。细节上,做成了个指数函数,可以通过对 i 变量的调控来改变时间因子在对热度的影响。 age:内容发布时间 update:内容最后更新时间(所有时间值单位均为 h/3600) i:重力因子,取值的大小会直接决定热门排序(后面将介绍这点)

热门问答

对于热门问答,使用了如下公式:

热门问答的计算参考了 Stack Overflow 对于回答数量和问题得票数的处理。同时,结合我们的实际,将评论的得票数也做为一个因素加入计算。

Qanswers / Qscore:分别是问题的答案数量和问题的得票数 anwserScores / commentSocres:分别是该问题下所有答案的总得票数和所有评论的总得票数 update:该问题下答案的最新更新时间

其余的变量含义和文章算法相同。

日/周/月热门

首先要明确各类不同热门内容的目的。

日热门的主要目的就是突出最近一天内的热门内容,更方便于内容被大家看到,文章快速地形成讨论、受关注的问题尽快得到解决; 周热门的主要目的很明确,就是突出过去一周内的热门内容,同时,给新产生的优秀内容机会,让其有机会进入热门列表; 月热门同周热门目的一样,但更需要给新内容进入列表的机会,以让内容经常更新。

所以,该怎么做呢?

对于同一内容,上面的计算公式均可化简为:

可以看出,其热度和创建时间成反比,那么这个反比的值最终就由重力因子 i 来影响。

日热门为了突出新热内容、过滤时间过久的热门内容,需要增大重力因子,尽可能排除 24 小时之外的热门内容;周热门和月热门则需要按时间要求依次逐渐降小 i 值。

关于指数 […]

响应式设计实践手札

说到相应式设计,首先要提及的是其核心技术Media Queries。记得还是在我10年前上大学的时候,看着书本中描述响应式设计的愿景仿佛还如同昨日,如今随着Media Queries受到浏览器广泛支持而早已成为现实。我最早写的关于Media Queries的CSS3 Media Queries 详解一文,发布于2010-08-23,距今已然6年,并且Media Queries Lv3也已经在2012年成为W3C推荐标准——也正是2012年,算是响应式设计的爆发之年。

于是这些年来各种设计精巧的响应式页面便层出不穷,虽然国内老牌网站鲜见(业务和浏览器的各种因素),却在国外遍地开花。虽然使用的算不上多,但这些年的一些思考需要整理一下,本文就是我近年来对响应式设计的实践以及一些粗浅经验和建议,分别从设计和代码角度来看响应式页面。

响应式设计

响应式设计(Responsive web design,以下皆简称RWD)致力于提供跨设备的最佳体验。但说到底,RWD做的再好终究是无法同单一设备优化的页面相比的,RWD的优点并非是体验本身,而是基于一套代码的适应性的体验改良——从大多数意义上讲,实际是指尽可能减少相同的页面在移动端的缩放,平移和滚动。

因为覆盖面更广,RWD的设计里多出了许多额外需要权衡的取舍,这对设计和前端都有所要求,所以如果设计和前端是分开独立运行,那么务必需要更为紧密的沟通。很多时候为了寻求设计和实现的平衡点,分工过于明确的团队会额外消耗大量的沟通时间。

个人是赞同前端自己来设计RWD的,如果只一人操作RWD,那么还是加修设计的前端更合适一些,因为从设计出发常常妨碍RWD的初衷——设计的内容无法用一种结构来描述的话,RWD意义就不大了。如果是设计师主导设计页面结构,那么一个简单的原则,就是将内容切割分块然后像堆积木一样来倒序摆放。

适用范围

RWD并非万能,相反其适用面其实相当有限。广义的RWD是需要自适应到手机屏幕的,对于4-6寸巴掌大小的屏幕,信息承载能力自然有限。虽然从PC端自适应的过程中可以做减法,但页面核心内容还是被严格地限制着。所以复杂页面不可能适合RWD——一个简单的衡量标准是,页面上需要表达的点一般不超过10个。实际上互联网绝对多数的站点业务并不复杂,所以其实RWD还是很有市场,特别是对于展示类网站,RWD几乎都是首选。无奈国内小而美的战点相对较少,所以RWD也就相对要少很多。

移动web设计

这几年移动影响Web设计的趋势已经越发明显,简单列举一些常见的模式转变:

滚动加载替代分页,对应手机端的滑屏。 基于矢量的扁平化设计,高PPI屏幕清晰度和性能的需求 内容尺寸放大,开始以拇指触碰的精度设计交互组件 缩减hover的使用,使得移动端和PC端交互一致 更为明显的交互态,例如Button,受限于无法hover,那么人们必须第一眼就识别出交互组件的外观 汉堡图标和抽屉式页面,这些都是APP的标准交互形式,现在已经不仅仅出现在移动端页面里,甚至直接出现在PC端。

这些改变,使得我们渐渐一眼就能看出一个页面是否是RWD——大尺寸交互元素配上简单空旷的页面风格。

RWD模式

既然移动影响了相当多的PC端设计,那么也一定有相当多的固有套路,比如:

通栏:总是最有效的突出内容且易于RWD控制的形式。 抽屉:多种类型屏幕里,弹窗的伸缩性往往受到更多限制。 折叠:屏幕的变换会使得定位元素的定位管理变得麻烦,当我们需要一个more info,往往不是弹窗不是定位浮层,而是向下展开更多内容。 自然换行:和下面要讲的多语言更有关些。 多语言

RWD配上多语言,使得原本复杂的页面更显得麻烦。但是相比普通页面,RWD和多语言的相性却并不差。实际上宽松的页面结构加上原本就为不同屏幕设计自适应布局,多语言化的话反而要更为顺利一些,当然前提是设计之初就已经有了相当多的考虑。于是就会常常遇到“自然换行”,这种自然换行却恰恰也是需要设计的一部分,一个页面如果能保证大部分内容自然换行都不会影响页面整体的话,才是成功的RWD。

响应式代码

一般的认知是RWD因为一套结构的关系,所以比较节省开发资源。但实际节省下来的后端开发,与额外增加的前端工程以及设计上的制衡相互抵消。一个项目是否真的节省了资源最终还是要看项目本身的复杂度,不过从大的范围来看,相对节约资源是正确的,当然付出的代价就是一种平庸,因为融合而又要做到体验的极致是相当困难的。

Media Queries是RWD实现的基石,而宽度则又是RWD的核心维度(我们还是一如既往的不怎么关心高度~)。

设备

虽然我们常常为了某个设备制作RWD页面,但真正的RWD页面需要应对的并不是某某设备,而是页面内容本身——针对内容做响应式设计,而不是针对某个设备。当然实际情况,大多数人还是会偏向对编写针对设备断点的代码,比如下面这个是我以前为了一个团队分享所画的断点图示:

虽然已经是一年多以前的图,但近几年移动端变化已经减缓所以依旧可以看看。针对设备做优化的好处是直接有效,成本低可控制。如果当真对页面内容做RWD,单一语言还比较好控制,多语言总是会遇到各种奇葩问题,可能在各种妥协下页面的整体设计就一团糟了。

性能

就目前的流量和网络来说,RWD还是显得太笨重。之前我做过一些页面的简单对比,相同页面平均速度要差3-4倍,相当可观。分析原因主要还是因为PC的重量连带给RWD后,拖慢了整体页面的加载速度,无法与传统的单一优化的H5页面相比。这些问题等到未来网速加快会渐渐显得不能刺眼,不过当前还不能忽视。

代码特点

RWD的核心代码关键词是普通流(或称常规流,normal flow)。普通流是最能保证自适应的CSS定位机制,清晰的文档上下文秩序,在这个基础上运用浮动和有限的定位,是RWD的主流做法。在这过程中有一些常见的编码问题需要注意:

严格限制的position,z-index,overflow:hidden。虽然正常情况下这些CSS属性也是需要一定限制的,但在RWD中显得更为重要。 避免line-height垂直居中。由于无法确定在某种特定状况下发生换行而使得页面非常难看,除非能保证内容完全无折行可能,不然调整行高是毫无必要。 字体问题。传统PC有一些奇技淫巧,比如字符箭头,在RWD里容易出问题。曾经我们可能只需要考虑桌面环境(并且往往是windows为主),而现在需要面对的则是更为复杂的客户端环境。使用的字符比以往更容易受到系统和设置的影响而出现错位,应该尽力避免。 定宽的绝对定位。绝对定位常常用在宽度恒定的地方,比如icon。在多语言的情况下,如果能用定宽icon替代文本,那么应该优先考虑通用的图形。这让我想起来宜家家居的安装说明书——如果你仔细看过他们的说明书的话,就会发现安装说明只有图示没有任何文字出现。 […]

牛娇客(一四二)zz

发信人: newjoker (牛娇娇), 信区: Joke标 题: 牛娇客(一四二)zz发信站: 水木社区 (Fri Sep 23 23:40:43 2016), 站内

1.亚洲有五大巨头,韩国棒子,日本鬼子,越南猴子,印度阿三和中国喷子。其中中国喷子最屌,他们成群结队,按键伤人,攻击距离最远,速度最快,数秒内即可完成惊人内伤,并且常常莫名其妙发动攻击,令人感叹防不胜防!

2.大家不用太过于焦虑,现在不是只有你觉得日子难过,是几乎所有人都觉得日子难过,要想解决这个问题,最简单的方法就是:习惯了就好了。

3.同学聚会喝了点酒……到家后装醉,就躺沙发上。二货老公看见了走了过来,关心地问道:喝了多少?我装着醉呼呼的回答好多,心想着二货老公肯定心疼我。二货接着小声地问:银行卡密码多少?……

4.最近工作太忙总是加班到深夜,三天没回家了。这是我和女友相处两年以来第一次连续三天没见面。能看出来她十分想念我,期间给我发了60来条短信,全是银行卡扣款信息。

5.办公室一男对一女同事一直色心不死,今天他对女同事说:“那天我看你老公带个女孩去宾馆了。”女同事:“你认识那女的吗?”他:“不认识。”女同事:“你不认识的,就不用和我说了。如果我老公带的女的是你妹妹或者是你老婆,你告诉我,我给你主持公道。”

6.回到家一见面,老婆阴沉着脸质问我:“我听别人说,你上午跟一个女同事手挽手去买葡萄,是真的么?”我赶紧解释:“亲爱的你肯定是误会了,我们买的是提子。”

7.今天和老婆大人出去逛庙会,看到有个套圈的不错,老板是个中年大叔,蹲在那摆摊。十块钱弄了三个圈让她玩。老婆很开心,说要套个大娃娃回来,然后直接一个圈丢出去,直接套中了店主的秃头……店主大叔很幽怨地看了我一眼,然后对我老婆说,妹纸,有老公了就不要调戏大叔了好么……

8.有个萌萌哒的老婆是什么感觉?一天跟老婆吵架,老婆急了,拿起一瓶敌敌畏说:“你这么狠心,好!就让你知道失去我的滋味。”过了一分钟……“老公、拧不开。” 我:……于是我帮她拧开了。“老公,你尝尝过期没有…”

9.老妈在抱怨家里那套旧房子不好卖,高了没人要,低价又不想卖。突然眼前一亮:“闺女,你说如果我打个广告就说买一赠一咋样?”我纳闷:“怎么个赠法?”老妈高兴地说:“来买房子赠送你啊!”

牛娇客(一三九)zz

发信人: newjoker (牛娇娇), 信区: Joke标 题: 牛娇客(一三九)zz发信站: 水木社区 (Sun Sep 18 23:18:49 2016), 站内

1.我喜欢看柯南,一集死一个日本人。 我喜欢看死亡笔记,一集死一打日本人。 我喜欢看海贼王,一集死一船日本人。 我喜欢看火影,一集死一村日本人。 我喜欢看奥特曼,一集死一城日本人。 我喜欢看“世界末日”,30分钟没到,日本岛就没了。 九一八勿忘国耻!

2.人们常说,“十五的月亮十六圆”。但今年,月亮迟到的更多,要到农历十七才圆。是因为物价上涨了吗?十五的月亮都要17元了……

3.本人要买车了,现在工作稳定,为了提高生活质量欲求购二手车一辆,要求不高,车况良好,提速一定要快,质量要过关,本人不差钱,不差钱,就是不差钱,只有四点要求如下: 一.脚蹬子必须得好使!二.链盒子别TM哗啦哗啦老响!三.刹车必须给力,别老让我拿脚秃噜地!四.车座子必须要完整,不能刮裤裆!

4.伪化学解释:香蕉含大量的钾,而雪碧的碳酸含量较高,众所周知碳酸钾是草木灰的主要成分,一起吃香蕉喝雪碧就是吃灰……伪物理解释:香蕉软糯,雪碧含气,通过胃酸的搅拌将产生大量香蕉泡沫,引发涨肚,严重时可导致急性肠胃炎……伪中医解释:香蕉味甘性平,五行属土,祛燥热、清肾毒;雪碧味酸性寒,五行属木。肝木克脾土,同食要受苦。又雪碧色清而实滞,香蕉状凝而质松,混而抑清扬浊,乃是君臣失和,配伍不当之像……

5.突然觉得李世民好傻,如果当时他不让唐僧去取经而是直接把他吃了,那我们现在就一直是大唐盛世了,那我也不用减肥了,而且可以三妻四妾啦,我简直太机智了……

6.昨晚想跟老婆亲热。老婆:先别,儿子还没睡着呢。我:老早都睡了,肯定睡着了。老婆不信,于是我拿一个一块硬币在儿子眼前晃了晃。儿子一个闪身起来:“一块钱就想办这么大的事?!”我…………

7.一哥们烟瘾特大,他媳妇儿想尽办法要他戒烟都没有一点效果。一次聚会另一哥们媳妇儿支招,回家后要求哥们抽烟可以,抽一支烟晚上啪啪一次,每天老实交待, 如果不记得按三支算。就这样三个月过去了,再一次见到哥们已经是枯瘦的身板,发烟给他都连忙摆手说戒了……就这样,又一名烟民成功戒烟!!!

8.老王是出了名的妻管严,某夜烟瘾犯了,遂找老婆要钱,老婆挥了挥手指,一分钟一块钱,老王脸当场就黑了,怒气冲冲的说道,两块钱你让我上哪里去买烟。

Elasticsearch在Centos 7上的安装与配置

安装JDK

Elasticsearch官方建议使用 Oracle的JDK8,在暗转跟之前首先要确定下机器有没有安装JDK.

rpm -qa | grep -E ‘^open[jre|jdk]|j[re|dk]’

如果有,有可能是系统自带的openjdk,而非oracle的jdk。可以使用

rpm -qa | grep Java | xargs rpm -e –nodeps

 批量卸载所有带有Java的文件,然后进行重新安装。

命令行下载 JDK 有个麻烦的地方,必须先要接受 Oracle 的许可协议,不过可以通过设置 cookie 来解决。

wget –no-check-certificate –no-cookies \      –header “Cookie: oraclelicense=accept-securebackup-cookie” \      http://download.oracle.com/otn-pub/java/jdk/8u101-b13/jdk-8u101-linux-x64.tar.gz

直接解压

tar -zxvf jdk-8u101-linux-x64.tar.gz

 后。配置环境变量:

vi /etc/profile

添加如下内容,并保存:

# set java environment export JAVA_HOME=/usr/local/jdk1.8.0_101 export […]

Category

Archives