2008年3月19日

搭建过程备注:
1. 虚拟机软件Vmware 8.0 Workstation,Windows 2008 Enterprise Server, Sql Server 2008 R2。
2. 俩个节点平台版本必须一致,都为企业版。
3. 与构建Windows 2003群集不同,不能使用vmware的共享磁盘机制。Windows 2008集群对存储要求很高,不支持SCSI硬盘做集群。
    本次使用starwind 5.4代替vmware的共享磁盘实现群集存储。
4. 搭建Windows集群需要3台虚拟机:2个节点+1台存储。
5. 搭建SqlServer 2008集群需要4替虚拟机:2个节点+1台DC+1台存储。

搭建顺序:
1. 安装DC+DNS服务器。
2. 安装集群节点, 配置双网卡,域登录。
3. 安装群集磁盘服务器
4. 在集群节点上配置iSCSI发起。
5. 在集群节点上安装“故障转移群集”功能。
6. 进行故障转移群集验证和创建。
7. 至此,Windows集群环境安装完毕。
8. 在集群节点上按群集方式安装SqlServer 2008。
9. SqlServer 2008集群环境构建完毕。

参考文档:
Windows Server 2008的故障转移群集入门: http://os.51cto.com/art/201007/210286.htm
windows server2008虚拟机+群集: http://wenku.baidu.com/view/5e5b2be8e009581b6bd9eb1a.html
Windows2008+sqlserver2008集群安装:http://wenku.baidu.com/view/601dc74d2b160b4e767fcf46.html

posted @ 2012-06-21 09:23 bluoy 阅读(3918) | 评论 (0)编辑 收藏

神一样的软件,膜拜ing...
连我这天生kernel iptable有缺陷的都能用。

当前版本:2.04.
还是个Open Source的,改天一定要好好观摩一番的。

posted @ 2011-09-28 15:55 bluoy 阅读(293) | 评论 (0)编辑 收藏

If you meet following errors below when you try to build your source code:

 

Checking build tools versions...

build/core/main.mk:72:

************************************************************

build/core/main.mk:73: You are attempting to build on a 32-bit system.

build/core/main.mk:74: Only 64-bit build environments are supported beyond froyo/2.2.

build/core/main.mk:75:

************************************************************

Don’t panic, just change the code:

build/core/main.mk

ifeq ($(BUILD_OS),linux)

build_arch := $(shell uname -m) 

---ifneq (64,$(findstring 64,$(build_arch))) 

+++ifneq (i686,$(findstring i686,$(build_arch)))

 

and change the code in four mk files below from “+=-m64” to “+=-m32”


external/clearsilver/cgi/Android.mk

external/clearsilver/java-jni/Android.mk

external/clearsilver/util/Android.mk

external/clearsilver/cs/Android.mk


LOCAL_CFLAGS += -m32

LOCAL_LDFLAGS += -m32

end.

posted @ 2011-01-07 10:54 bluoy 阅读(348) | 评论 (0)编辑 收藏

I got this idea when i was surfing the web in search of a tool similar to the Nokia Pc Suite for my Linux

This How-To  works with many NOKIA Mobile Phone, especially for Nokia 3230, 6670, 6680, 6682 e 7610, 6120, Sony Ericsson Z1010, LG U8110/8120.

First of all, we have to grant access for Mobile Phone to “dialout” group.

sudo gedit /etc/udev/rules.d/40-permissions.rules

Now we have to add to the end of file:

# NOKIA 6120
BUS==”usb”, SYSFS{idVendor}==”0421″, SYSFS{idProduct}==”002f”, GROUP=”dialout”

where 0421 and 002f could be different depending on your Mobile Phone.
To check your idVendor and idProduct, we have to type on terminal

lsusb
Bus 003 Device 009: ID 0421:002f Nokia Mobile Phones

Now, we have to reload udev permission file:

sudo /etc/init.d/udev restart

We have to add our username on group “dialout”

gpasswd -a username dialout

All basics configurations for USB Data Cable are completed. We can start installation of obexftp and obextool GUI. Obextool GUI is written for tk graphic library, so GUI not have a good design as GTK.

sudo apt-get install openobex-apps libopenobex1 obexftp obextool

If you want start obextool from terminal we have to type for the first time:

export OBEXCMD=”obexftp -t /dev/ttyACM0 -u 1″
obextool

or, we can start it simply by typing:

obextool –obexcmd “obexftp -t /dev/ttyACM0 -u 1″

When we start Obextool we can see this error message:

It seems, that your device does not support the memory status feature.
Memory status will be disabled

To solve this problem we have to set some values on obextool.cfg:

sudo gedit /etc/obextool.cfg

set ObexConfig(config,memstatus) 0
set ObexConfig(config,filemove) 0

Another error message that we can see is:

FIle ‘/FileName/’ could not be uploaded to ‘E:/Path’!
Please check your file permissions.

To solve it:

sudo gedit /etc/obextool.cfg

set ObexConfig(config,dir_slash) 1

Good Job! Now your Mobile Phone works well in Ubuntu Gutsy with ObexTool.
If we want add it as Desktop Entry:

sudo gedit /usr/share/applications/obextool.desktop

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Exec=/usr/bin/obextool –obexcmd “obexftp -t /dev/ttyACM0 -u 1″
Icon=/usr/share/icons/gnome/scalable/devices/phone.svg
Terminal=false
Name=Obextool
GenericName=
Comment=Browser your Mobile Phone
Categories=Application;Utility;

So, you can find it in your Gnome Panel over: “Applications” -> “Accessories” -> Obextool

posted @ 2009-04-23 16:30 bluoy 阅读(365) | 评论 (0)编辑 收藏

下面的例子实现把一个整数的各个位上的数字相加,通过这个例子我们再次理解 connect by.

create or replace function f_digit_add(innum integer) return number
is
outnum integer;
begin
if innum<0 then
return 0;
end if;
select sum(nm) into outnum from(
select substr(innum,rownum,1) nm from dual connect by
rownum<length(innum)
);
return outnum;
end f_digit_add;
/

select f_digit_add(123456) from dual;

posted @ 2009-04-01 17:02 bluoy 阅读(810) | 评论 (1)编辑 收藏

终于搞明白了困惑很久的问题,罪魁祸首还是jdk啊。天杀的。
以下内容转自网络:

测试环境:Win2K Pro日文版,SUN J2SDK 1.5.0-beta2

经过测试,发现Shift_JIS和MS932编码的全角波浪线(“~”)的编码都是 0x8160(16进制,两个字节,高位在前)。通过sun.io.ByteToCharMS932转换后得到Unicode字符'\uFF5E',而通过sun.io.ByteToCharSJIS转换后则得到Unicode字符'\u301C'。

反之,Unicode字符'\uFF5E'通过sun.io.CharToByteMS932转换后会得到MS932编码的本地字符0x8160(16进制,两个字节,高位在前),而Unicode字符'\u301C'通过 sun.io.CharToByteSJIS转换后也会得到Shift_JIS编码的本地字符0x8160(16进制,两个字节,高位在前),两者的转换结果相同。

结论:在WinNT/2K/XP上,MS932和Shift_JIS这两种本地字符集完全相同,只是分别采用JDK的sun.io.ByteToCharMS932和sun.io.ByteToCharSJIS对个别特殊的本地字符进行转换后所得到的 Unicode字符并不一样。实际上,MS932就是WinNT/2K/XP上的Shift_JIS,只是与标准版的Shift_JIS字符集相比,MS932收录了更多的字符,比如NEC和IBM对Shift_JIS的扩展(如日文中的“㊤㊥㊦㊧㊨①..⑳...”等等);然而,JDK中的 ByteToCharSJIS及CharToByteSJIS却使用了标准的Shift_JIS字符集,所以部分扩展字符在从byte转换成char或是从char转换成byte时会出现乱码,这的确是JDK让人非常迷惑的一处。

参考资料1(日文):http://www.asahi-net.or.jp/~ez3k-msym/charsets/jis2ucs.htm

posted @ 2009-02-03 16:52 bluoy 阅读(1356) | 评论 (0)编辑 收藏

1. 函数的overwrite实现时,函数参数类型必须严格一致。与overload不同,并不遵守参数优先匹配的原则。
所以,不能用子类,或这接口的实现类来妄图得到overwrite的目的。
2. 使用反射手法时,getMethod()的调用,参数类型必须与要得到的函数类型严格一致。与overload不同,并不遵守参数优先匹配的原则。
3内部类,要实例化时必须首先实例化包含类。可以理解为内部类只是包含类的数据成员
4非public类,非javabean规范的Bean,内部类BeanUtil类无法进行操作,比如clone()等等。

posted @ 2008-12-28 10:54 bluoy 阅读(174) | 评论 (0)编辑 收藏

虽然java没有提供函数指针的操作,而是必须通过对象来曲线救国。
不过延伸一下这个思路,其实也未必不是件好事。从某种意义上来说,整个java系统,或者对象系统,其实就是不计其数的钩子组成的系统。因为,参数传递的过程中完全依赖着对象,一种行为和数据的结合体。这里,关键词是参数传递和对象的行为,当然离不开多态。
        改变既有代码的行为步骤:
        1. 派生参数类得到新的子类。
        2. 在子类中覆写(overwrite)父类既有方法。
        3. 将子类的实例作为参数传递。
        这样,就得到了改变父类行为的目的。
 对于既有框架自作主张的封装,阻碍自己的目的的时候,这个做法往往能独辟蹊径。

posted @ 2008-12-28 10:40 bluoy 阅读(177) | 评论 (0)编辑 收藏

Spring Framework 的理解以及可维护性是否得以改善的思考

Spring的特性:
1. 提供了一种管理对象的方法,可以把中间层对象有效地组织起来。一个完美的框架“黏合剂”。
2. 采用了分层结构,可以增量引入到项目中。
3. 有利于面向接口编程习惯的养成。
4. 目的之一是为了写出易于测试的代码。
5. 非侵入性,应用程序对Spring API的依赖可以减至最小限度。
6. 一致的数据访问介面。
6. 一个轻量级的架构解决方案。

对Spring的理解
Spring致力于使用POJOs来构建应用程序。由框架提供应用程序的基础设施,将只含有业务逻辑的POJOs作为组件来管理。从而在应用程序中形成两条相对独立发展的平行线,并且在各自的抽象层面上延长了各自的生命周期。

Spring的工作基础是Ioc。Ioc将创建对象的职责从应用程序代码剥离到了框架中,通常2中注入方式:setter 和 ctor参数。
每个Bean定义被当作一个POJO(通过类名和JavaBean的初始属性或构造方法参数两种方式定义的Bean)。
Spring的核心在org.springframework.beans,更高抽象层面是BeanFactory. BeanFactory是一个非常轻量级的容器。

关于可维护性的思考
Spring之类的技术确实带来了应用系统的可维护性的提高吗?
Ioc, AOP之类的技术,本质上都是将原本位于应用程序代码中"硬编码"逻辑,剥离出来放到了配置文件中(或者其他形式)。主流声音都是认为提高了应用程序的可维护性。

但如果从以下方面观察,结合项目实际经验,个人感觉这些技术的应用大大降低了应用程序的可维护性,尤其是面对一个陌生的系统,或者项目人员变动频繁的时候。
1. 中断了应用程序的逻辑,使代码变得不完整,不直观。此时单从Source无法完全把握应用的所有行为。
2. 将原本应该代码化的逻辑配置化,增加了出错的机会以及额外的负担。
3. 时光倒退,失去了IDE的支持。在目前IDE功能日益强大的时代,以往代码重构等让人头痛的举动越来越容易。而且IDE还提供了诸多强大的辅助功能,使得编程的门槛降低很多。通常来说,维护代码要比维护配置文件,或者配置文件+代码的混合体要容易的多。
4. 调试阶段不直观,后期的bug对应阶段,不容易判断问题所在。
5. 性能问题。虽说硬件性能日新月异,但是性能也是在不经意间一点一点地流失的。从汇编到高级语言,到面向对象,到虚拟机,一直处于这样的发展趋势。

posted @ 2008-07-06 10:21 bluoy 阅读(1990) | 评论 (3)编辑 收藏

项目中组员偶然写了一段垃圾的sql语句,不想却误打误撞的发现了一个jdbc的bug,包括Oracle 10g附带的版本。

详细描述可以参考如下代码:
   public static void testSetTimestampBug() throws Exception{
        Calendar calendar = new GregorianCalendar();
        Date d = calendar.getTime();
        
        String sql = "select 1+1 from dual where ?-sysdate<1";         //error sql
        String sql1 = "select ?-sysdate from dual";                          //no error sql
        String sql2 = "select 1+1 from dual where ?-1<sysdate";       //no error sql
        PreparedStatement pst = cn.prepareStatement(sql);
        //pst.setDate(1, new java.sql.Date(d.getTime()));                 //no  error
        pst.setTimestamp(1, new java.sql.Timestamp(d.getTime()));   //bug!!!, throw SQLException: ORA-00932
    }
三种sql的写法中,第一种写法在使用setTimestamp()时会出错,其他俩种却不会有问题。
即正常调用PreparedStatement.setTimestamp()方法,遇到某些特殊写法的sql语句却会出错。
本例中,抛出如下例外:
java.sql.SQLException: ORA-00932: inconsistent datatypes: expected NUMBER got INTERVAL.
然而,如果使用setDate()方法,则一切正常,三种写法都没有问题。

因为有这个问题,如果在持久层使用了其他的中间件,则这个问题可能变的更加隐蔽,比如iBatis中的处理是这样的:
java.util.Date ---> ibatis.DateTypeHandler----->PreparedStatement.setTimestamp() 
java.sql.Date ---> ibatis.SqlDateTypeHandler----->PreparedStatement.setDate()
如果不注意输入参数类型的话,就会遇到上述问题。我就因此费了不少周折。
对于iBatis的使用建议,保证入口参数类型始终为java.sql.Date即可。

posted @ 2008-03-26 17:17 bluoy 阅读(1771) | 评论 (0)编辑 收藏

Web架构特性及REST架构风格(部分内容摘自网络)

良好的Web架构风格:
    1. 客户/服务器模式:  实现了UI与数据的分离。
    2. 服务端无状态性: 可见性,可靠性,可伸缩性等方面的改善。
     可见性-无状态性使得服务器不必要维护海量的上下文(Context)。
     可靠性-无状态性减少了服务器从局部错误中恢复的任务量。
     可伸缩性-无状态性使得服务器可以很容易的释放资源。
    3. 缓存: 减少服务端不必要的处理。
    4. 可伸缩性: 便于分布式和集群部署。
     上面的2,3点也是影响4的主要因素。而随着系统用户规模的指数上升,可伸缩性将变的至关重要。

现在大多数应用程序都忽略或者违反了上述2, 3的风格。当然也肯定失去了4带来的好处。
比如Java Servlet中HttpSession的应用,使服务器端保存了客户端的状态。
时下流行的动态页面的做法也使得资源缓存变得困难或者不可能。
这些都直接影响了应用的可伸缩性。

改善现状的思路是,把服务端的处理和状态前移,由客户端来实现。使服务端回归到无状态的特性。
以采用ajax技术的应用系统为例:因为不需要完全刷新就可以与服务器进行交互,使得有状态客户机成为可用选择。基于浏览器的应用程序代码可以在必要时获取新的服务器数据,并把这些数据织入当前页面。
将处理和状态前移到每个客户机上后,实现了无状态的服务端;同时缓存服务器可以缓存ajax引擎(比如dojo, prototype etc.),以及状态无关的数据。
个人理解,多种浏览器的plug-in技术(Sun的applet, MS的ActiveX等等),都应该是这种思路的不同技术实现。

经过以上分析整理,实际上已经涉及到了时下流行的一个概念-REST.

REST(Representational State Transfer)来源于Dr. Roy Thomas Fielding,  <Architectural Styles and the Design of Network-based Software Architectures>
当浏览器浏览访问一个url资源时,返回的页面即为该url资源的representation,这个representation给浏览器一个state,当
浏览器访问下一个url资源时,浏览器的state就transfer了。
REST其本身只是为分布式超媒体系统(distributed hypermedia systems)设计的一种架构风格,而不是某个标准,框架。

REST的设计准则
    1.网络上的所有事物都被抽象为资源(resource);
    2.每个资源对应一个唯一的资源标识符(resource identifier);
    3.通过通用的连接器接口(generic connector interface)对资源进行操作;
    4.对资源的各种操作不会改变资源标识符;
    5.所有的操作都是无状态的(stateless)。

REST中的资源所指的不是数据,而是数据和表现形式的组合。
REST是基于Http协议的,任何对资源的操作行为都是通过Http协议来实现。以往的Web开发大多数用的都是Http协议中的GET和POST方法,对其他方法很少使用,这实际上是因为对Http协议认识片面的理解造成的。Http不仅仅是一个简单的运载数据的协议,而是一个具有丰富内涵的网络软件的协议。他不仅仅能对互联网资源进行唯一定位,而且还能告诉我们如何对该资源进行操作。Http把对一个资源的操作限制在4个方法以内:GET, POST,PUT和DELETE,这正是对资源CRUD操作的实现。由于资源和URI是一一对应的,执行这些操作的时候URI是没有变化的,这和以往的 Web开发有很大的区别。正由于这一点,极大的简化了Web开发,也使得URI可以被设计成更为直观的反映资源的结构,这种URI的设计被称作 RESTful的URI。这位开发人员引入了一种新的思维方式:通过URL来设计系统结构。当然了,这种设计方式对一些特定情况也是不适用的,也就是说不是所有的URI都可以RESTful的。
REST 之所以可以提高系统的可伸缩性,就是因为它要求所有的操作都是无状态的。由于没有了上下文(Context)的约束,做分布式和集群的时候就更为简单,也可以让系统更为有效的利用缓冲池(Pool)。并且由于服务器端不需要记录客户端的一系列访问,也减少了服务器端的性能。

posted @ 2008-03-24 16:35 bluoy 阅读(388) | 评论 (0)编辑 收藏

       Java语言编程中更新XML文档的四种方法。第一种方法是直接读写XML文件。第二种方法是使用Apache Crimson的XmlDocument类,这种方法极为简单,使用方便,如果你选用Apache Crimson作为XML解析器,那么不妨使用这种方法,不过这种方法似乎效率不高(源于效率低下的Apache Crimson),另外,高版本的JAXP或者是Java XML Pack、JWSDP不直接支持Apache Crimson,亦即这种方法不通用。第三种方法是使用JAXP的XSLT引擎(Transformer类)来输出XML文档,这种方法也许是标准的方法 了,使用起来十分灵活,特别是可以自如控制输出格式,我们推荐采用这种方法。第四种方法是第三种方法的变种,采用了Xalan XML Serializer,引入了串行化操作,对于大量文档的修改/输出有优越性,可惜的是要重复设置XSLT引擎的属性和XML Serializer的输出属性,比较麻烦,而且依赖于Apache Xalan和Apache Xerces技术,通用性略显不足。除此之外,实际上应用别的API(比如dom4j、JDOM、Castor、XML4J、Oracle XML Parser V2)也有很多办法可以更新XML文档。

概念介绍
        Xerces/Crimson是XML解析器,Xalan是XSLT处理器,xml-apis.jar实际上是JAXP。
        Apache Crimson的前身是Sun Project X Parser, 至今Apache Crimson的很多代码都是从X Parser中直接移植过来的。早期的JAXP是和X Parser捆绑在一起的。后来的 JAXP和Apache Crimson捆绑在一起,比如JAXP 1.1。最新的JAXP 1.2 EA(Early Access)改弦更张,采用性能更好的Apache Xalan和Apache Xerces分别作为XSLT处理器和XML解析器,不能直接支持Apache Crimson了。
        dom4j(dom4j.jar)是一个Java的XML API,类似于jdom,用来读写XML文件的。dom4j是一个非常非常优秀的Java XML API,具有性能优异、功能强大和极端易用使用的特点,同时它也是一个开放源代码的软件,可以在SourceForge上找到它。在IBM developerWorks上面可以找到一篇文章,对主流的Java XML API进行的性能、功能和易用性的评测,dom4j无论在那个方面都是非常出色的。

posted @ 2008-03-19 10:27 bluoy 阅读(1974) | 评论 (0)编辑 收藏