分享:serialVersionUID for NetBeans 7.0.1
Netbeans 最近从7.0升级到了7.0.1,常用的serialVersionUID插件不可用,于是找官网,发现已经更新了。
地址:http://kenai.com/projects/nb-svuid-generator/downloads/directory/nbms/nb7.0.1
Notes: glassfish 出现__admingui/common/index.jsp not found 的问题处理
日期:2011年08月09日 分类:Linux服务器相关, 技术, 编程相关, 网站运营相关
这几天出现了一个奇怪的现象,glassfish的管理端“无缘无故”的登录不了了,查看server.log见以下错误:
File "%2Fopt%2Fglassfish3%2Fglassfish%2Flib%2Finstall%2Fapplications%2F__admingui%2Fcommon%2Findex.jsp" not found|#]
整理下:
File "/opt/glassfish3/glassfish/lib/install/applications/__admingui/common/index.jsp" not found|#]
这个是管理端的首页,更换了好几个全新的glassfish版本在服务器上的现象依旧,本地跑却一点儿事情没有,实在是不明白原因。
最后在这里:http://www.java.net/node/699754 得到了提示,一个叫 dcam 的家伙说:
推荐阅读:正确使用 Volatile 变量
日期:2011年08月02日 分类:编程相关
地址:“Java 理论与实践: 正确使用 Volatile 变量”
摘要:
锁提供了两种主要特性:互斥(mutual exclusion) 和可见性(visibility)。
互斥即一次只允许一个线程持有某个特定的锁,因此可使用该特性实现对共享数据的协调访问协议,这样,一次就只有一个线程能够使用该共享数据。
可见性要更加复杂一些,它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的 —— 如果没有同步机制提供的这种可见性保证,线程看到的共享变量可能是修改前的值或不一致的值,这将引发许多严重问题。
Volatile 变量具有 synchronized 的可见性特性,但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。
Volatile 变量可用于提供线程安全,但是只能应用于非常有限的一组用例:多个变量之间或者某个变量的当前值与修改后值之间没有约束。
正确使用 volatile 的模式:
模式 #1:状态标志
模式 #2:一次性安全发布(one-time safe publication)
模式 #3:独立观察(independent observation)
模式 #4:“volatile bean” 模式
模式 #5:开销较低的读-写锁策略
Notes: 更改glassfish的日志轮转数量
日期:2011年08月01日 分类:Linux服务器相关, 技术, 编程相关, 网站运营相关
最近升级到glassfishv3.1.1之后,发现日志的数量始终保持在10个,判断是日志轮转数量有默认限制,查了官方文档,设置如下:
./bin/asadmin set-log-attributes com.sun.enterprise.server.logging.GFFileHandler.maxHistoryFiles=50
如果glassfish的默认管理端口变了,则需要指定管理端口号,如:
今天头七了
日期:2011年07月30日 分类:随记
2011年7月23日20时27分 – 甬温线特别重大铁路交通事故
今天头七了,今天全国也被禁声了,连纪念哀悼也不允许。
在此悼念那些无辜的生命,下一个或许就是你,我,他/她。
转:被自己拖死的人们
日期:2011年07月30日 分类:随记
今天无意中看到李笑来老师的一篇文章,分享一下:
这是个很常见的现象:创业团队常常被外包公司拖死。可是,外包公司的本意可不是想害死谁——谁会从一开始就想干死自己的衣食父母呢?
陷阱在于:参与协作的双方目标并不一致。
外包公司的目的只有一个:按时定量完成被给予的任务,然后拿钱走人,做下一个项目。
可创业团队的困境在于,他们的“主意”并不确定,方向也好,目标也罢,很可能始终处于调整状态——事实上,任何一个“无中生有”的过程都是这样的:需要一定量的时间与实践才能从一个“主意”演化为“可实现的计划”,最终还要拥有很强的执行力才能将计划变成现实。
外包公司可没有这个耐心,他们想快速完成任何一个项目。他们会不由自主地告诉对方:“这个是不可行的……”,“那个是没必要的……”,“还有这些和那些是可以下一期再说的……”——外包公司在说这些的时候,甚至可能自己都没意识到得出这种结论的根本原因其实只不过是他们没能力完成而已。
这并不罕见,只不过因为最终已经失败了所以知道的人少而已:很多创业团队就这样被外包公司拖垮了。(注意:以上并不是再说“千万不能找外包公司”,这是另外一回事儿。)
很多公司最终步履艰难,其根本原因在于公司内部绝大多数员工都成了“外包公司”。
员工的目标并非“急公司所急,想公司所想”,而是“努力完成上司下达的任务”而已。一旦上司的任务指定不清楚,或者方向有误,那么公司就会出大问题——但责任并非在于那些“外包公司”性质的雇员。
很多人也一样,他们缺乏长期目标,甚至连想都没有想过自己的长期目标是什么。
于是,一不小心就把自己变成了赚自己时间精力和金钱的外包公司。
下场当然很惨:一步一步把自己拖死——可是,死期不是马上来临的,很可能在三年、五年之后。等死期来临之际,又如何想明白自己究竟是怎样一步一步走到这个地步的呢!
于是,很多在缓慢走向灭亡的过程中毫无知觉。生不由己,死因不详。
原文出处:http://www.lixiaolai.com/index.php/archives/10704.html
Notes: 通过 label 标签改进鼠标用户的可用性
先看看 label 标签的使用说明:
HTML <label> 标签
定义和用法
<label> 标签为 input 元素定义标注(标记)。
label 元素不会向用户呈现任何特殊效果。不过,它为鼠标用户改进了可用性。如果您在 label 元素内点击文本,就会触发此控件。就是说,当用户选择该标签时,浏览器就会自动将焦点转到和标签相关的表单控件上。
<label> 标签的 for 属性应当与相关元素的 id 属性相同。
案例
<div> <input type="checkbox" name="rememberme" id="rememberme"> 记住我 </div>
深入理解JVM
带着问题去学习,jvm分析
[root@localhost ~]# jstat -gcutil 3461 2000 S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 0.00 23.72 6.21 53.61 9 1.302 3 5.263 6.564 0.00 0.00 23.72 6.21 53.61 9 1.302 3 5.263 6.564 0.00 0.00 23.72 6.21 53.61 9 1.302 3 5.263 6.564 0.00 0.00 23.72 6.21 53.61 9 1.302 3 5.263 6.564 0.00 0.00 23.72 6.21 53.61 9 1.302 3 5.263 6.564
上面是一段通过JVM内建的指令jstat对一个Java应用程序的资源和性能进行实时监控的记录,“3461”是Java应用程序的进程ID,“2000”是指每隔2秒钟采集一次监控数据。
各个数据的含义:
7×24小时不间断服务
对于互联网服务而言,大部分都要求尽可能地做到 7X24 小时不间断的运行,你可能经常会看到一些大网站给出的 99.9% 或者 99.99% 可用 这样的内容,下面的表给出了从 99% 到 99.999% 的不可用时间的计算方式,差别真的很大,想做到真的很难很难:
| 可用性指标 | 计算方式 | 不可用时间(分钟) |
|---|---|---|
| 99% | 1% x 365 x 24 x 60 | 5256 |
| 99.9% | 0.1% x 365 x 24 x 60 | 525.6 |
| 99.99% | 0.01% x 365 x 24 x 60 | 52.56 |
| 99.999% | 0.001% x 365 x 24 x 60 | 5.256 |



