突然的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不能同时运行多个，这个很不方便，不知道为什么要这样限制。
以前可以用imo.im来登陆，这几天imo宣布由于连不上skype服务器，无法提供skype服务了，而且小道消息说微软要推web skype了，估计是被屏蔽了。
找半天终于发现有个软件可以用于启动多个skype ttp://multi-skype-launcher.com/
下载安装后就可以登录多个了，但是这个安装包捆绑了两个其他软件，我的毛豆和小A都报警了，它虽然有个选项不安装其他软件，但是我及时设置了不安装还是给我安装了，有非常大的流氓嫌疑。不过它的文件其实就一个可执行文件，不需要安装，这里建议不要使用这个软件。
后来发现竟然有这么个办法：
从Skype版本4.0起，可以很方便的在一台计算机中运行多个Skype程序，登录不同的Skype帐户了。
方法很简单，只需在运行Skype时带参数“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
in java on performance
原文 http://www.infoq.com/articles/9_Fallacies_Java_Performance
翻译 http://www.oschina.net/translate/9_fallacies_java_performance [凑合]
看这篇文章，原文要看，评论也要看。文章总结了9点谬误：
提到了对比测试 web performance benchmarks ，
头两个都是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之后。
这个结果与直觉相比，似乎不是很靠谱得呢。
意思是说，其实java 虚拟机和即时编译器是有上下文来优化的，所以不要试图过早的优化。
意思是说没必要一开始就设计微基准测试（小范围基准测试？），当确实发现需要基准测试时，应该从系统整体和最关键部分考虑。
应该依靠经验和产品数据来找到引起性能问题的真正原因。要动手采集数据而不是凭空猜测。--算法往往不是问题
意思是说,往往重构更能简化系统提高性能,缓存作用有时不是很大.--作者认为重构比利用缓存更简单.
意思是说虽然STW问题确实存在，但是对于大部分程序来说，这个问题的影响可以忽略或忍受。
在决定是否需要考虑这个问题之前，首先利用GC日志分析，到底是否STW是根本原因。
意思是说对象池并不能很好地解决STW问题，它起作用，但是起不了很大的作用。反而使代码更复杂。
意思是说CMS也有弊端，只在Parallel Old机制确实无法忍受的情况下再来考虑CMS
这个是老生长谈，如果是程序问题，再大的内存也不管用
评论中还是有相当怀疑意见的：
有人认为C++还是比java要性能高，作者解释说从内联(intrinsics)和单态区分(monomorphic dispatch) 这两点上,JIT要比C++编译器强很多。
还有人需要作者指明很多java程序与c++一样快这句话缺少例子，我也这么认为，因为java里面太多这样类似的暗示却没有实证。
文章看过，没什么比较震撼的信息，仍不能解决我对java性能的保留意见，从实际来看，无论知名大应用还是商业小应用，例证最多的还是php。
而且，相比php,java出现性能问题的几率是多了无数倍，你需要花时间解决这个问题的花费也是无数倍,因为php是外面的框子限制了性能问题（启动->运行->终止）,而java则留了许多坑让你踩，一个不留神你就中招了。
不好意思，又这里黑java了，但是我用的最多的还是java,lol.
Continue reading 【链】关于 Java 性能方面的 9 个谬论
in 微博
准扁平化设计,很流行
36kr.com/p/200985.html
Continue reading Tweet 准扁平化设计,很流行 http://t.co/6khfuIcHxG
in Web前端 on angularjs, javascript, mvc
最近infoQ有文章上javascript mvc框架做了个介绍，http://www.infoq.com/research/top-javascript-mvc-frameworks 。
发现angularjs与backbone有的一拼，目前angularjs的支持者稍占多数。
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
backbone和angular再次引起比较，注意其中John Munsch的评价。
使用angular在大型项目中应该没问题，被采访的人中就有用到。
angular最大的缺点可能就是侵入性太强，合用其它框架较麻烦。
bootstrap虽然支持，但是问题不少。
参见:
http://freewind.me/blog/20121226/1167.html
http://www.zhihu.com/question/21170137
http://angular-ui.github.io/bootstrap/
https://groups.google.com/forum/#!topic/angular/DVDccsAWmj4
Continue reading angularjs 笔记
最早我用的是sqlserver2000,后来开始用mysql,现在再回去用sqlserver2005,我的个神，真坑爹的复杂。
转过一篇文章配置用户名密码: http://blog.ureshika.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。
当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连接
in Web
作者张红月编译
摘要：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）可以写整本书，就个人而言，我比较喜欢重用他人开发的内容类型，像 Atom、 Collection+JSON、 JSON 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可以阻止你用最简单的方式进行攻击，但这里还有其他更机智的攻击方式。例如 Slowloris、 Billion laughs、 ReDoS，它们都不会占用太多资源，但是它们可以让你的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.io、Mashery I/O Docs、 Swagger。
41.设计与客户：不要在真空中设计API，要与客户打交道或者一起来设计API，参考用户用例。
42.反馈：在设计API时，应提供一个通道供用户进行反馈，
43.自动化测试：API测试是最简单的事情。它最好是自动化的，毕竟，需要好好利用它。
上面提供的这份列表有趣吗？对你是否有帮助呢？欢迎与我们一起讨论。
来自： Mathieu Fenniak
Continue reading 【转】Web API核查表：设计、测试、发布API时需思考的43件事
现在喜欢上了git,还是不错的嘛，github现在国内也可以用了，速度很快。但是它的收费可就不便宜了，5个私人仓库要7美刀每月。组织用户起步价是25美刀每月。
这里介绍几个替代方案:
九美刀每月，就这一种价格
| PrivateFree | Micro$9/mo. | Compact$24/mo. | Corporate$49/mo. | Enterprise$99/mo. | |
|---|---|---|---|---|---|
| Storage | 512MB | 1GB | 3GB | 6GB | 20GB |
| Active Projects | 1 | 4 | 10 | 20 | 50 |
| Archived Projects | — | ∞ | ∞ | ∞ | ∞ |
| Collaborators | 2 | 10 | 20 | ∞ | ∞ |
| SSL Encryption | |||||
| File Attachments | |||||
| Time Tracking |
Unlimited Repositories
Unlimited Trac Projects
Unlimited Users
Custom Domains
Agile Workflows
SSL Secured
WebDAV Shared Drives
Scheduled Backups
2GB Storage
$1/GB Additional Storage
支持svn,git,hg 这个站似乎很简单，靠谱么？
这个是免费的(5个合作者)，之所以这么优惠的东东放在最后，是因为我之前用它还是蛮痛苦的，为什么呢，速度非常慢，提交个2k的东西要几分钟，甚至超时，连它的web界面也经常登陆不了。不过最近似乎有所改善，而且支持git,难道被github刺痛了？
这个还得保留观察一下。
Continue reading github 替代
这两天将一个项目转到了heroku上面，哎呀我的个神，真心不好用：
Java:
https://devcenter.heroku.com/articles/java-support
默认不支持mysql而是支持protress,但是可用addon--cleardb来集成mysql，cleardb也有免费的级别。
但是即使是免费级别，必须要通过身份验证，也就是验证你的信用卡,否则无法添加addon。
http://www.ibm.com/developerworks/cn/java/j-javadev2-21/
maven不是必需的,可以直接发布war包 https://devcenter.heroku.com/articles/war-deployment
eclipse插件安装:
https://devcenter.heroku.com/articles/getting-started-with-heroku-eclipse
这个安装总是报错，尝试几次才成功，要看人品了。有了这个才差不多，否则那个控制台工具真不好用。
不存在永久的文件系统
https://devcenter.heroku.com/articles/dynos#ephemeral-filesystem
http://stackoverflow.com/questions/12123050/no-permanent-filesystem-for-heroku
只能两个可写文件夹https://devcenter.heroku.com/articles/read-only-filesystem
./tmp ./log
servletContext.getRealPath();返回null问题，这是因为使用的webrunner跑的是未展开的war包。
解决办法是:
pom里面配置为展开war文件夹:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<phase>package</phase>
<goals><goal>exploded</goal></goals>
<configuration>
<webappDirectory>${build.directory}/webapp</webappDirectory>
</configuration>
</execution>
</executions>
</plugin>然后在Procfile里面指定webruner的目标（procfile是heroku添加参数的方法）:
web: java $JAVA_OPTS -Dspring.profiles.active=prod -Dmidware.path.conf="distributed" -jar target/dependency/webapp-runner.jar --port $PORT target/webapp
这其实就是配置webrunner跑文件夹。
注:procfile的注释也是#号。
这样就可以得到webapp运行目录了，而且，此目录下的文件也是可写的！
但是要注意保持这个概念，都是临时性的文件系统，你用的时候要考虑这一点。
这里面讲了大部分问题：
https://devcenter.heroku.com/articles/java-faq
是直接发布war包还是用maven+嵌入的容器?
后者更容易发布，修改代码后直接构建测试，和heroku环境更接近。
而且源码方式更容易改配置，对于开发来说，每次改一个文件要传半天是很麻烦的。
项目目录下有个Procfile文件，heroku会依据其来启动，你可以修改它来添加系统参数。
https://devcenter.heroku.com/articles/procfile#deploying-to-heroku
本地运行可参见项目下的readme.md
例如:$java -jar target/dependency/webapp-runner.jar target/*.war
这个使用的jsimone项目，可在eclipse里面调试:
https://github.com/jsimone/webapp-runner
添加引用:
Continue reading heroku使用笔记 in java on freemarker 几点实用的: 转义$的写法: 则最终输出为 安全判断是否为空 <#if (a.b.c.d)??>hi</#if> 这样即使a都不存在也不会报错。 Continue reading Freemarker 笔记 Freemarker 笔记
<div class="span${'$'}{span}"><div class="dashboard-item span${span}">
