bootstrap的dialog

一个常用的dialog,在botstrap里面就特别别扭了,它本身带的只有模式对话框,而且有bug,

http://stackoverflow.com/questions/13649459/twitter-bootstrap-multiple-modal-error

当使用多个modal方法时,就会出现此问题,火狐直接是假死,chrome还好报了个错,这个问题搅了我一下午,让人火大。

 

那个替代的plugin也不是很好用,只是没报错,这些都是模式对话框,不能拖动,这就是boottrap的风格,你奈它何?

 

默认的是,当用户点击任意除模式dialog上按钮的其他地方,对话框就会消失,不触发按钮事件,这让我觉得设计者是不是脑子被驴踢了?要修改这样的默认方式需要:

$(e).modal({
					backdrop: 'static',
  					keyboard: false
				}).modal('show');

这样就会出现动画提示用户点击按钮,但是如果你想去掉后面的那个黑色遮罩,backdrop必须是false,这怎么解决呢,多次尝试后发现解决方法:

.modal-backdrop.fade.in{
	z-index: -20000 !important;
}

这个样式将遮罩层放到最低层,就看不到了。

注意不能用display:none,这个方法在chrome下面有问题。

 

反正是不好用,你想使用jqueryui的dialog,对不起,bootstrap的样式将其整的惨不忍睹,用不了……

Continue reading bootstrap的dialog

outlook 与 pop3,imap设置

imap的特点是所有操作都与服务器同步,因此你本地的改动例如已读邮件,文件夹等都在所有imap客户端同步了,但是对于outlook又有个问题,imap你无法指定数据文件夹,它默认都是放在c盘下面,无法改。所以基于这一点我还是用pop。

 

这里讲的比较详细:

http://blog.csdn.net/dududu01/article/details/6175662

Continue reading outlook 与 pop3,imap设置

微波炉做盐水花生

好吃佬我今天成功用微波炉做出了盐水花生,以后这个零食就不用愁了哈哈。

 

做法:

1:将花生米用流水洗干净。

2:放在碗里加入水,水不要太多,刚没过花生米即可。

3:依据自己的喜好加入盐(要多放点),花椒粉,辣椒,大蒜(蒜香花生,大蒜少量即可,切碎末),搅拌

4:放置八个小时以上,一般头天晚上拌好,第二天再加工

5:放置八个小时以上后,去掉水,将花生摊平放在盘子里,或直接放在微波炉的转盘上,中火2分半后拿出来搅拌一下,再摊平再中火2分半。

6:将花生放置一段时间让其自然冷却,这样就做好了。

 

味道不错哦。

Continue reading 微波炉做盐水花生

Failed to create the Java Virtual Machine.问题

突然的eclipse(indigo)启动报错

Failed to create the Java Virtual Machine.
 
网上搜了一下:
http://www.thecarneyeffect.co.uk/eclipse-and-failed-create-java-virtual-machine
http://www.eclipsezone.com/eclipse/forums/t61618.html
 
需要从eclipse.ini里面找配置原因,我的问题是

-XX:PermSize=64M
-XX:MaxPermSize=512M

把这两句删掉就没问题了,但是之前都是运行得好好的,我的4G内存还不够?

 

这个问题还不知道实际原因。

Continue reading Failed to create the Java Virtual Machine.问题

如何启动多个skype

skype不能同时运行多个,这个很不方便,不知道为什么要这样限制。

 

以前可以用imo.im来登陆,这几天imo宣布由于连不上skype服务器,无法提供skype服务了,而且小道消息说微软要推web skype了,估计是被屏蔽了。

 

找半天终于发现有个软件可以用于启动多个skype ttp://multi-skype-launcher.com/

 

下载安装后就可以登录多个了,但是这个安装包捆绑了两个其他软件,我的毛豆和小A都报警了,它虽然有个选项不安装其他软件,但是我及时设置了不安装还是给我安装了,有非常大的流氓嫌疑。不过它的文件其实就一个可执行文件,不需要安装,这里建议不要使用这个软件。

 

后来发现竟然有这么个办法:

 

从Skype版本4.0起,可以很方便的在一台计算机中运行多个Skype程序,登录不同的Skype帐户了。
方法很简单,只需在运行Skype时带参数“secondary”即可。操作如下:

  1. 点击计算机左下角“开始”--“运行”
  2. 在输入框中输入:
    "C:\Program Files\Skype\Phone\skype.exe" /secondary (双引号不能少)

你也可以把上面的内容做成“快捷方式”放到桌面,想运行多个Skype时双击一次运行一个。
注意:不同的计算机机可能文件路径不同,只要找到“skype.exe”所在位置就可以了。

 

简便的方法就是,把你的skype快捷方式修改为 "C:\Program Files\Skype\Phone\skype.exe" /secondary

 

Mac下 sudo /Applications/Skype.app/Contents/MacOS/Skype /secondary

 

测试通过,我的神呀,咋不早说呢!

Continue reading 如何启动多个skype

【链】关于 Java 性能方面的 9 个谬论

原文 http://www.infoq.com/articles/9_Fallacies_Java_Performance

翻译 http://www.oschina.net/translate/9_fallacies_java_performance  [凑合]

 

 

看这篇文章,原文要看,评论也要看。文章总结了9点谬误:

1: Java运行慢

提到了对比测试 web performance benchmarks

Snap1

头两个都是netty相关,netty是基于java的,去看了一下,基于nio,与mina是同一个作者(韩国李)。

这里也扯一下netty和mina, http://stackoverflow.com/questions/1637752/netty-vs-apache-mina

上面链接看看韩国李的评论,netty就是为了解决mina开发中出现的问题而重新设计的,它的文档更好,构建速度更快,去掉了可能不是用的很多的东西从而简单化,提高性能。mina3将会是完全的重构,意味着api兼容性将会破坏(说到这你也懂韩国李自己都在黑mina了。) 只是对于UDP,mina提供更高层的抽象(稳定连接),而netty更接近UDP本意。

里面还有人拿netty和ngix做测试对比,竟然etty表现和ngix不相上下甚至更好……

 

 

 

之所以说是框架而不是服务器,是因为它是嵌入到程序里面作为服务端框架,就像嵌入的tomcat或jetty,而不是一个web容器。

回到上面提到的性能比较表,php竟然比spring还慢。php完全排在java平台之后了。nodejs还在tapestry之后。

这个结果与直觉相比,似乎不是很靠谱得呢。

 

2. A single line of Java means anything in isolation 一行代码是孤立处理的

意思是说,其实java 虚拟机和即时编译器是有上下文来优化的,所以不要试图过早的优化。

 

 

3. A microbenchmark means what you think it does

意思是说没必要一开始就设计微基准测试(小范围基准测试?),当确实发现需要基准测试时,应该从系统整体和最关键部分考虑。

 

4.算法慢是性能问题的最普遍原因

应该依靠经验和产品数据来找到引起性能问题的真正原因。要动手采集数据而不是凭空猜测。--算法往往不是问题

 

5.缓存能解决一切问题

意思是说,往往重构更能简化系统提高性能,缓存作用有时不是很大.--作者认为重构比利用缓存更简单.

 

6. All apps need to be concerned about Stop-The-World 所有的程序都要注意jvm的Stop-The-World问题

意思是说虽然STW问题确实存在,但是对于大部分程序来说,这个问题的影响可以忽略或忍受。

在决定是否需要考虑这个问题之前,首先利用GC日志分析,到底是否STW是根本原因。

 

7. Hand-rolled Object Pooling is appropriate for a wide range of apps

 

意思是说对象池并不能很好地解决STW问题,它起作用,但是起不了很大的作用。反而使代码更复杂。

 

8. CMS is always a better choice of GC than Parallel Old -- CMS机制总是比Parallel Old机制好

 

意思是说CMS也有弊端,只在Parallel Old机制确实无法忍受的情况下再来考虑CMS

 

9. 增加堆内存会解决你内存溢出的问题

这个是老生长谈,如果是程序问题,再大的内存也不管用

 

 

评论中还是有相当怀疑意见的:

有人认为C++还是比java要性能高,作者解释说从内联(intrinsics)和单态区分(monomorphic dispatch) 这两点上,JIT要比C++编译器强很多。

 

还有人需要作者指明很多java程序与c++一样快这句话缺少例子,我也这么认为,因为java里面太多这样类似的暗示却没有实证。

 

 

文章看过,没什么比较震撼的信息,仍不能解决我对java性能的保留意见,从实际来看,无论知名大应用还是商业小应用,例证最多的还是php。

 

而且,相比php,java出现性能问题的几率是多了无数倍,你需要花时间解决这个问题的花费也是无数倍,因为php是外面的框子限制了性能问题(启动->运行->终止),而java则留了许多坑让你踩,一个不留神你就中招了。

 

不好意思,又这里黑java了,但是我用的最多的还是java,lol.

Continue reading 【链】关于 Java 性能方面的 9 个谬论

angularjs 笔记

最近infoQ有文章上javascript mvc框架做了个介绍,http://www.infoq.com/research/top-javascript-mvc-frameworks

发现angularjs与backbone有的一拼,目前angularjs的支持者稍占多数。

 

主页 http://angularjs.org/

 

下载 http://code.angularjs.org/

 

github上下载源码zip有12M。

 

其文档需要服务端配合,所以还是官方站点看比较靠谱(与extjs一样)。

 

对IE支持不重视,http://docs.angularjs.org/guide/ie

对于ie8以上还要另外处理,ie9也不是支持的很好,从评论来看,对IE不重视。

 

目前我认为最大的问题是页面代码增多,许多逻辑转移到了页面指令上,我觉得这个与美工配合起来很麻烦。

 

对于第三方jquery插件,还不能像之前那样直接,还要写指令(directive),这点就够呛了。某种意义上说,这个是要改变使用js+html的习惯,出现这种情况,我不认为它有足够的推动力能像jquery那样流行起来。这个不由得让我想起Tapestry,那也是改换思路的创新,其现状如何?

 

网上搜了一下,发现大部分还是支持angular, http://stackoverflow.com/questions/6548826/angular-js-vs-backbone-js 这里说从backbone转向angular后,js脚本从5千行减少到750行,但是我不知为什么不从js文件大小上比较,也没比较html是增多了还是减少了?

 

 

另外我觉得使用它有首次卡顿现象,不知是否是页面编译时出现的。

 

上述几点让我打消了使用angularjs的念头。还是backbone靠谱。

=======

http://www.infoq.com/articles/real-world-javascript-mvc-frameworks

backboneangular再次引起比较,注意其中John Munsch的评价。

 

 

使用angular在大型项目中应该没问题,被采访的人中就有用到。

 

angular最大的缺点可能就是侵入性太强,合用其它框架较麻烦。

bootstrap虽然支持,但是问题不少。

 

参见:

http://freewind.me/blog/20121226/1167.html

http://www.zhihu.com/question/21170137

http://stackoverflow.com/questions/16327846/bootstrap-3-compatible-with-current-angularjs-bootstrap-directives

http://angular-ui.github.io/bootstrap/

https://groups.google.com/forum/#!topic/angular/DVDccsAWmj4

Continue reading angularjs 笔记

sqlserver 2005配置jdbc连接

最早我用的是sqlserver2000,后来开始用mysql,现在再回去用sqlserver2005,我的个神,真坑爹的复杂。

 

转过一篇文章配置用户名密码: http://kazge.com/archives/939.html

 

这次用java连又折腾了半天,主要是jdbc连不上的问题。

 

这里总结一下:

首先要配置好sa用户名,然后在SQL Server配置管理器里面

sqlserver网络配置/sqlexpress的协议中要启用tcp/cp协议。

上面提到的tcp/ip属/IP Address中最下面IPALL中/TCP Port要配置好端口。

然后将上面列出的ip地址中想要打开的设置为enable Yes,注意如果(Protocal)的Lisen All如果是Yes的话,里面(IP Address)所有ip都会监听。如果是No的话,则只会监听(IP Address)里面Enalbe - Yes的ip。

 

Snap1

 

当Listen All为No时,对于每个开启的ip,TCP 动态端口和TCP端口都要需要填写正确的值。

 

如果遇到This driver is not configured for integrated authentication.异常,则检查url里面不要包含IntegratedSecurity=true;这一参数。

 

 

参见:

http://blog.csdn.net/libenqing/article/details/6025616

Continue reading sqlserver 2005配置jdbc连接

【转】Web API核查表:设计、测试、发布API时需思考的43件事

转自csdn: http://www.csdn.net/article/2013-04-22/2814983-43-Things-To-Think-About-When-Designing-Testing-and-Releasing-your-API

 

作者张红月编译

Web APIAPI开放平台开发经验

摘要:API设计并非易事,从设计到测试以至最终的发布需要经历一个漫长的过程,本文将主要探讨Web API从设计到最终发布,开发者可能忽略或者应该注意的事情,希望对你有所帮助。

当设计、测试或发布一个新的Web API时,你是在一个原有的复杂系统上构建新的系统。那么至少,你也要建立在HTTP上,而HTTP则是基于TCP/IP创建的、TCP/IP建立在一系列的管道上。当然,你也需要考虑Web服务器、应用程序框架或者是API框架。

API从设计到测试以至最终的发布需要经历一个漫长的过程,本文将主要探讨Web API从设计到最终发布,开发者可能忽略或者应该注意的东西。

HTTP篇

HTTP 1.1规范 RFC2616是一个非常大的文档,下面我们节选了一些可能会对API产生影响的内容分享给大家:

1.Idempotent方法:GET、HEAD、PUT、DELETE、OPTIONS以及TRACE都属于idempotent操作;也就是说,“the side-effects of N > 0 identical requests is the same as for a single request.” (RFC2616 §9.1.2

2.验证:用户访问API需要进行识别和验证,HTTP所提供的Authorization头文件就是出于此目的(RFC2616 §14.8 )。 RFC2617则指定了具体的验证计划,包括了最常见的HTTP基本验证。

3.201 Created:使用“201 Created”响应代码表示请求成功,并且创建了一个新资源。201响应可以包含本地头文件中的新资源URI。( RFC2616 §10.2.2

4.202 Accepted:使用“202 Accepted”响应代码表示该请求是有效的,将会被处理,但还未完成。一般情况下是用在服务器后台队列可能出现的地方。( RFC2616 §10.2.3

5.4XX和5XX状态代码:4XX状态代码与5XX状态代码有一个非常重要的区别:4XX代码旨在表明客户端错误,而5XX则是表明服务端错误。( RFC2616 §6.1.1

6.410 Gone:“410 Gone”响应代码是一个很少使用的响应式代码,其主要是通知客户端资源出现在URL中,但实际上并没有。这个用在API里可以指明被删除、存档或过期的项目。( RFC2616 §10.4.11

7.Expect::100-continue:如果API客户端打算发送一个大型的实体请求,像POST、PUT或PATCH,它可以发送“Expect: 100-continue”到HTTP头文件里,在发送实体之前等待“100 continue”响应。这就允许API在返回错误响应信息之前,可以验证那些合理的请求(例如401或者403)。使用它可以提高API的响应能力以及在某些情景下减少宽带。( RFC2616 §8.2.3

8.保持连接畅通:与API服务器保持连接,对于多API请求是个非常大的性能提升。如果配置正确,每个Web服务器应该支持keep-alive连接。

9.HTTP压缩:HTTP压缩可以同时用于响应体(Accept-Encoding: gzip)和请求体(Content-Encoding: gzip),用来提升HTTP API的网络性能。

10.HTTP缓存:在API响应时提供一个Cache-Control头文件。( RFC2616 §14.9

11.缓存验证:如果你有缓存API,那么在响应时,你应该提供Last-Modified或Etag头文件,然后支持IF-Modified-Since或者If-None-Match请求头文件用于有条件的请求。这将允许客户端检查它们的缓存副本是否仍然有效,并且当没有请求时,阻止一个完整的资源下载。如果实现得当,那么条件请求要比普通请求更有效。( RFC2616 §13.3

12.条件修改:ETag头文件也可以用于条件修改资源。( RFC2616 §14.24

13.绝对重定向:这是一个鲜为人知的HTTP/1.1要求,重定向(如。201、301、302、303、307响应代码)应该包含一个绝对URI本地响应头文件。许多客户端在本地支持相对URI,但是如果你想让API兼容更多客户端,你应该在重定向时使用绝对URI。( RFC2616 §14.30

14.链接响应头文件:在RESTful API中,经常需要提供转向其他资源的链接,甚至响应的内容类型无法提供一种自然方式链接(例如,PDF或图像)。 RFC5988在响应头文件中指定了一个链接提供方法。

15.规范URL:对于多资源URL,RFC6596定义了统一的方法来规范网址链接。

16.块传输编码:如果响应内容太大,传输编码:分块(Chunked)是一种很好的流响应到客户端方式,它将会减少服务器和中间服务器的内存使用需求(尤其是对实现HTTP压缩),并且提供更快的首字节响应。

17.块传输编码里的错误处理:在实现块传输编码之前,弄清如何处理发生在中间请求时产生的错误是非常重要的。一旦对响应进行流处理,就无法改变HTTP的状态代码。

18. X-HTTP-Method-Override:有些HTTP客户端不支持任何GET和POST,但你可以通过POST开通其他HTTP方法,使用约定成俗的标准X-HTTP-Method-Overrider头文件去定义“真正”的HTTP方法。

19.URL长度:如果API支持复杂或任意的过滤项作为GET参数,那么记住,无论是客户端还是服务器端都可能会因为超过2000字节的URL长度带来兼容性问题。

API设计篇

20.无状态:没有人希望API能够存储状态,即使是在你的应用程序服务器端。保持应用程序服务器状态自由,可以做到很轻易和很轻松地扩展。

21.内容协商:让你的资源支持多种表现方式,你可以使用内容协商(content negotiation,例如Accept头文件),或者使用不同的URL(例如……?format=json),或者可以让你的内容协商重定向到具体的格式。

22.URI模板: URI模板是一个定义良好的机制,用来提供URI组合能力到客户端,或者定义URL访问终端用户模式。

23.Design for Intent:不要仅通过API来暴露内部业务对象,设计API语义意味着要与用户案例相匹配。更好地介绍,你可以阅读Darrel Miller写的 API Craft

24.版本:理论上讲,一个设计良好的API是无需创建兼容的。而对于实用主义者,它们会把版本放入到API的URL中(例如:a/v1/path),所以,除非是处在一个安全的网络状态下,否则API可能不会按照预期那样工作。

25.授权:记住,当设计API时,并不是所有的用户都可以访问里面的任何对象。

26.批量操作:发送较少的请求来获取或修改更多的数据,最好的方法就是在你的API里使用批量操作。

27.标记页数:API中使用分页服务主要有两大目的:一个是减少不必要的数据传送到客户端;一个是减少应用服务器端不必要的操作。

28.统一的字符编码:在设计和测试API时,Web服务需要支持更多的英文字符。如果你在URL中把Unicode字节作为自然键使用,它将会非常有趣(例如:/users/jimbob/ becomes /users/싸이/)。

29.错误日志:在设计API时,创建错误日志也是非常重要的。实践时最好创建两种日志记录,一个是服务器端,一个是客户端。

内容篇

30.内容类型:关于内容类型(Content Type)可以写整本书,就个人而言,我比较喜欢重用他人开发的内容类型,像 AtomCollection+JSONJSON HAL或者XHTML。定义一套属于自己的内容类型会比你期望的更好。

31.HATEOAS:超媒体作为应用程序状态引擎是一个REST约束,简单点说就是你的内容应该通知客户端下面要做的事情,可以通过链接或表单来通知。

32.日期/时间:当你在API里提供日期/时间值时,应该使用一种格式,包括时区信息。 RFC3339是ISO8601的一个子集,是最简单的日期时间格式。

安全篇

33.SSL:无论你的API是否支持HTTP或HTTPS,你都应该考虑HTTPS这种访问方式,它的增长趋势日益明显。

34.跨站请求伪造(CSRF):如果使用API的交互式用户与普通用户都使用相同的验证,那么你的API很有可能会遭受CSRF攻击。

35.Throttling:如果一个API用户的请求数超过了规定,那么你应该提供一个带Retry-After header的503响应。

36.婉转的拒绝服务:Throttling可以阻止你用最简单的方式进行攻击,但这里还有其他更机智的攻击方式。例如 SlowlorisBillion laughsReDoS,它们都不会占用太多资源,但是它们可以让你的API在瞬间耗尽所有资源。

客户端

无论你是否给用户提供测试代码或者是SDK开发包,都应该给他们提供一个客户端,并且遵循下面这几个步骤:

37.保持连接畅通:一些HTTP客户端需要做一些额外的工作来保持连接持久,持久的连接对感知API性能有着非常重要的影响。

38.授权之前的401:HTTP的另一个怪癖是,它们会在解决一个授权问题之前发出“401 Unauthorized”响应。这样就会延长API的请求时间。

39.Expect: 100-continue:至少有一个API客户端默认使用“Expect: 100-continue”,如果它没有接受“100 Continue”响应,在3秒的超时后会继续发送请求。如果API不支持“100 Continue”,或许会产生另一个性能缺陷,导致客户端禁用。

其它

40.文档:编写API文档是令人厌烦的,但是手写的API文档通常是最好的。编写时一定要包含这些内容:一些可运行的代码或者curl命令行,方便查阅。你也可以参考一些文档工具,例如: apiary.ioMashery I/O DocsSwagger

41.设计与客户:不要在真空中设计API,要与客户打交道或者一起来设计API,参考用户用例。

42.反馈:在设计API时,应提供一个通道供用户进行反馈,

43.自动化测试:API测试是最简单的事情。它最好是自动化的,毕竟,需要好好利用它。

上面提供的这份列表有趣吗?对你是否有帮助呢?欢迎与我们一起讨论。

来自: Mathieu Fenniak

Continue reading 【转】Web API核查表:设计、测试、发布API时需思考的43件事

Pagination


Total views.

© 2013 - 2019. All rights reserved.

Powered by Hydejack v6.6.1