10/06/2009

拿了ZyWall USG-50 H

==相關產品==
Detail Information...

這是中華電信的贈品...XD
機能還蠻強的...
NVRAM和DRAM都具備256MB...
我沒看過裡面..
但我猜測應該是Intel的CPU...
Session可以吃到35000左右

(不過最新的資安艦隊2010..
新提供的機器機能更強..
還具備UTM..
Session可以吃到10萬..0_0)

這算是Geteway...
因為提供的功能已經遠超過OSI Layer3了
不過他的3.5G function好像是optional...

既然拿到了...
就要好好把玩了...XD

由於之前有玩過Zyxel的產品了...
Interface差不多就是那個死樣子..

Intel的I/OAT網路加速技術...

Source:
http://www.intel.com/network/connectivity/vtc_ioat.htm
最近有幸拿了一塊Supermicro的x58板子...


I/OAT已經說到第二版本了.
所以我又拿了Intel Xeon W3570來測試...
因為I/OAT中其中一個DCA技術必須要具備...
然後Mainboard必須要具備QuickData技術..
這是I/OAT的建立基礎....


結果試一試發現都開不起來...
從I/OAT Checker顯示的結果...
OS不符合要求XD...
他需要我去灌Windows 2k3/2k8阿阿阿..囧...
再來就是Intel 82574L的GbE晶片不完整支持I/OAT...
搞笑喔..
那幹嘛板子BIOS提供I/OAT的function...XD...

最近都在忙...

最近再用一些PC設備...
沒時間去更新blog...XD..
事實上好像很久沒更新了0_0

4/16/2009

豐富的裝飾者 - Decorator Pattern

咖啡太苦?恩..加糖..
沒有奶味?..那加奶精吧..

我要加甚麼就加甚麼...
Decorator模式使您個體多樣化...

Decorator提供多重物件的裝飾..
事實上,他是非常有用的Pattern..
應當好好學起來...!!
假定一個生活化的案例:
一家工廠製造一台車(Car)...
在製造的過程中...
其實是不斷的加工...
例如加上引擎..
加上輪框..
加上車胎等等...
而引擎也是一個不斷加工後所產生的一件元件....

Decorator Pattern就是像上述這樣的例子...
根據Decorator Pattern的正式定義如下:
Decorator Pattern可以動態將責任加諸在物件上,若要擴充模組,裝飾者提供了比繼承更有彈性的選擇

所謂從責任加諸在物件上..
意味著,責任就是傳遞需要使用的物件,裝飾在裝飾!
....待續一下..拖個稿..=.="

4/15/2009

UML設計 - Class Diagram的 "屬性" 介紹

我們根據Addison-Wesley的UML精華第三版內容來探討..
首先講幾個部分..
UML的最大目的在當初也是針對軟體工業而產生的..
從最初標準混亂的時代...
到UML出現終於有一個共通的標準
軟體發展才得以持續下去..
不過要先知道..


其意義不在圖的價值,而是他所表達出來的 商業效益 或著 內容..


廢話不多說...
基本上類別圖(ClassDiagram)是編程人員最常使用的一種圖形表示法..
他基本上可以表達三個部分...
  1. 類別性質(Property)

  2. 類別操作(Operation)

  3. 限制條件(Constraint)

而類別的特徵(Feature)正是包含了性質操作...
然而類別性質又分為: 屬性(Attribute)關聯(Relation)這邊部分要談的就是屬性這塊..
屬性通常可以表達物件的 狀態...

其 狀態包含有動態的(和程式語言中的static修飾詞沒有任何關係!)與靜態的...

在OOP上..
我們可以說屬性可以是基本型別(Primitive Type)的變數或著他代表一個物件(Object)..
在目前流行的程式語言(ex: C#、Java)上..
通常物件是參照(Reference)的表示形式...

我們來看看下圖對於屬性的圖形表示:

Grady Booch這個粗體字表示為類別(Class)的名稱...
其中,中間的內容為屬性(Attribute)的表示內容...

來看看屬性文字敘述的正式定義:
visibility name: type multiplicity = default {property-string}

visibilty 表示的是屬性的可見範圍,大多可以是Public、Private或著Protected
name 當然就是屬性的名稱
type 表示屬性的型態,例如:String(string)、Boolean(bool)、int(Integer)、byte等等...
multiplicity 表示為多重性,例如:一對一、一對多等等...
可以有

  1. 1:表示一對一
  2. *:表示無上限也無下限
  3. 0..1:最多至一種,也可能沒有半個
至於多重性的 術語 表示..
我們以後再來講...
default 當然就是表示當沒有值的時候,預設值為多少。這很簡單,不需做任何解釋!...
{property-string} 表示當其他表示法不夠表達時,可以用這段來補充額外的屬性..
但是property-string的表達方式有很多種,我們以後再來談!

最後,再從圖上來..
其中+-的符號表示為public和private的可見性修飾詞,而protected則是用#表示..
[ ]裡面數值表達多重性
最後=符號後面接的是預設值..

圖形表示的方式很簡單..
至於,我們對應其程式碼如下:
class GradyBooch{
public String name="Grady Booch";
public String birthday;
public String[] phone;
public bool sex;
private String father;
private String mother;

}//end GradyBooch
程式碼的表達大概就是這樣子..


以上差不多就是這樣!

ASP.NET Http Pipeline


這個是ASP.NET Http Pipeline架構..
重點是他乘載的是CLR Environment..
也就是Managed-Code...
在CLR之前都是透過一連串的COM-Level(Unmanaged Code)元件不斷的調用..
有時間..
會講講這塊流程..!!

4/14/2009

Defraggler 1.09.138

Official Site Link

Changelog:
- New search feature.
- Various tweaks to the drive list.
- Improvements to freespace calculation when moving large files.
- Improved handling of of sparse files.- Lots of minor UI tweaks.

第二命名規則:Pascal Case

從之前的Camel Case介紹可以得知,Pascal Case就是Upper Camel Case..

從wiki摘出來的說法是:
Upper Camel Case
每一個單字的首字母都採用大寫字母,例如:FirstName、LastName、CamelCase,也被稱為 Pascal 命名法

他不是很難,因為他跟Lower Camel Case的差異僅是Upper Camel Case的開頭第一個單字為大寫而已..!!

軟體設計層次(金字塔)


左圖是典型的軟體設計層次的金字塔模型,各位看看就好囉!!
以後再解釋幾個重要的成份..

4/13/2009

第一命名規則:Camel Case

中文就是駱駝命名法啦...!!
根據微軟的部分說法是這樣的:
識別項的第一個字母是小寫的,而每個隨後串聯文字的第一個字母是大寫的。例如:
backColor


根據Wiki的說法是:
Camel Case的詞語來自Perl語言普遍使用的大小寫混合格式...
而 Larry Wall 等人所著的暢銷書《Programming Perl》(O'Reilly 出版)的封面圖片正是一匹駱駝。」

Camel Case的限制條件,不得使用下列表式:

  1. 單字之間不得空格,ex:back Color
  2. 不可使用底線區隔,ex:back_Color
  3. 不能使用連接符號連接單字之間,ex: back-Color
Camel Case分成兩種格式:
Lower Camel Case
第一個單字以小寫字母開始;第二個單字的首字母大寫,例如:firstName、lastName
Upper Camel Case
每一個單字的首字母都採用大寫字母,例如:FirstName、LastName、CamelCase,也被稱為 Pascal 命名法

我個人對命名的看法:
  1. 盡量不要使用縮寫,最好能在兩個單字內搞定
  2. 非得需要縮寫的話,請表達語意清楚,或著附加註解..!
一些範例:(Pascal Case會另外拆另一篇文章講..)
Low Camel Case
==一個字以內:==
test、color、execute、observer、singleton、factory、measurements、time、connection、stop、start、run
==兩個字情況:==
getName、setProperty、executeReader、backColor、startRunning、nationalLanguage、dataBase、threadConnection、windowFrame、actionListener、windowAdapter
==三個字情況:==
getId、getSn、setNo、lastIndexOf、trimToSize、createSystemObject、removeArrayList
==四個字以上:==
全寫出來或著
setHRDepartment、addNewWorkProject、newProcessId、destroySid、rebuildNewThread

Gof的基本Designed Pattern意見..

Design Pattern總共分為三大類:

>>Creational Mode

>>Structural Mode

>>Behavioral Mode

按照Gof的Designed Pattern書籍..
對於新手應該從以下Pattern切入較為適當..

  1. Abstract Factory
  2. Composite
  3. Factory Method
  4. Strategy
  5. Adapter
  6. Decorator
  7. Observer
  8. Template Method
上述這幾個大多可以說是蹲馬步..
學習難度都不是很高..
當然如果覺得Gof的書本身就枯燥乏味、不是很好看(他確實是不好看..!)..
那麼O大師有趣的Designed Pattern書籍是不錯的選擇之一...

我對委由(delegate)的基本看法..!!

基本上就是透過delegate...
可以達到彈性化的行為呼叫....
而不必被綁得死死的...
我們可以擁一種簡單的部分代碼表示..
public abstract class Cpu{
protected CpuInstruction cpuInstruction;
protected String type;
//skip...
public void executeInstruction(){
cpuInstruction.execute();
}//end executeInstruction
//skip...
}//end Cpu
//-------------------------------------
public class AmdCpu extends Cpu{
public AmdCpu(string type){
cpuInstrcution=new X86Instruction();
this.type=type;
}//end constructor

public void printType(){
System.out.println("CPU Type: "+this.type);
}//end printType

}//end AmdCpu
由上可以看到executeInstruction()是一個委由(delegate)的方法..
而他的行為決定則是由次類別(AmdCpu)來決定..
因此並不會一開始就被綁死..
這樣做是極具彈性了..
不過上述程式碼的缺點就是"行為實踐"不夠彈性罷了!!

Adapter Pattern的轉接結構

Adapter Pattern對於不同介面之間可以提供相容的轉換..
這是一種非常有用的設計..
例如:
舊版的列舉器轉換成新的迭代裝置(Iterator)...
生活化一點..
例如美規接口透過一個轉接器(Adapter)轉換成歐規接口..
這樣的一種概念其實不難懂...
相對的,他的實作也是很容易...!!

來談談範例:
我們以建立一個匯流排結構PCI介面..
假設並沒有實際設計PCI的具象實踐(Instance)...
僅有一個PCIe的具象實踐..
客乎要求我們必須以PCIe架構建立在早期的PCI架構上..

1.首先我們建立一個介面以作為超型別(Super-Type)之應用..
public interface IPciInterface {
public void link();
public void read();
public void write();
}//end IPciInterface
2.我們得知有一個Pcie具象實踐可以使用,並且他是實作於IPcieInterface介面..
public class Pcie implements IPcieInterface{
public void link(){
System.out.println("Linking!");
}//end link
public void read(){
System.out.println("Reading!");
}//end read

public void write(){
System.out.println("Writing!");
}//end write

}//end Pcie
3.為了符合客戶的需求,我們建立一個PcieToPci的轉接器(Adapter)..
public class PcieToPci implements IPciInterface{

private Pcie pcie;
public PcieToPci(Pcie pcie){
this.pcie=pcie;
}//end constructor

public void link(){
pcie.link();
}//end link

public void read(){
pcie.read();
}//end read

public void write(){
pcie.write();
}//end write

}//end PcieToPci
4.建立好PciToPci轉接器後,再將剩下的Client部分處理..
public class Main{
public static void main(String args[]){
Pci pcie=new Pcie();//Pcie的具象實踐
PcieToPci pcieToPci=new PcieToPci(pcie);

//operations
pcieToPci.link();
pcieToPci.read();
pcieToPci.write();

}//end main

}//end Main

以上是一個非常簡單的Adapter Pattern應用..
他並不難..
學習起來也很快!!...
大概就這樣..

4/10/2009

Singleton Pattern概要..!!

Singleton Pattern目的用來創造獨一無二的資源...
這是非常有用的結構..
例如:
針對撰寫系統..
假設我們透過Factory Pattern來撰寫獨一無二的DataBaseFactory..
來進行對DataBase的統一存取...
這時透過Singleton Pattern便可以建立獨一無二的Factory..
可以看看簡單的代碼範例:
class Singleton{
private Singleton(){

}//end constructor

public static Singleton getInstance(){
return new Singleton();
}//end getInstance

}//end Singleton
由上可以看出幾個要點:
1.constructor必須private防止外部建立多個instance
2.一定要搭配static關鍵字
3.本身是可以返回自有的constructor

但是上述依然不夠完美..
我們把它改寫成如下:
class Singleton{
private static Singleton uniqueInstance;
private Singleton(){

}//end constructor

public static Singleton getInstance(){
if(uniqueInstance==null)
uniqueInstance=new Singleton();
return uniqueInstance;

}//end getInstance

}//end Singleton
可以看出這樣的方式可以做到對Singleton物件的唯一性..
但是如果想到Multi-Thread情況..
他依然還是有問題:
1.容易造成資源取得先後順序問題
2.容易造成資訊錯誤的災難

我們可以透過synchrnized關鍵字來建立critical section..
如下這樣:
class Singleton{
private static Singleton uniqueInstance;
private Singleton(){

}//end constructor

public static synchronized Singleton getInstance(){
if(uniqueInstance==null)
uniqueInstance=new Singleton();
return uniqueInstance;
}//end getInstance
}//end Singleton
但是要注意一點:
synchronized對於Mutli-Thread效能是有衝擊的..
因此必須要考量..!!

我們可以採用雙重鎖來盡量減少多次的同步化
如下做法:
class Singleton{
private volatile static Singleton uniqueInstance;//volatile關鍵字可以表是變數的同一存取
private Singleton(){

}//end constructor

public static Singleton getInstance(){
if(uniqueInstance==null){

synchronized(your_class_name.class){
if(uniqueInstance==null) uniqueInstance=new Singleton();
}//end synchronized

}//end if
return uniqueInstance;
}//end getInstance

}//end Singleton

以上便是很簡單的Singleton應用..!!

Java中的Deadlock情況!!

要知道deadlock的前提:
Thread A占用Resource B
Thread B占用Resource A

發生情況:
Thread A將Resource B鎖定(lock)住
;同時,
Thread B將Resource A鎖定(lock)住
Thread B要取用Resource B,結果Thead A仍未處理完,要等待!
Thread A要取用Resource A,結果Thread B仍未處理完,要等待!
最終,雙方同時等待造成Deadlock!

模擬Deadlock:
1.雙方同時sleep以致不會把lock object交還..
2.Thread A的sleep時間比Thread B長
(這樣做Thread B,會以為Thread A還在處理..!因為lock object沒交還..)
3.使用synchronized關鍵字來創造critical section..

代碼如下:
public class Main{
public static void main(string args[]){
Thread threadA=new Thread(new ThreadA());
Thread threadB=new Thread(new ThreadB());

threadA.start();
threadB.start();

}//end main
}//end Main
class ThreadA implements Runnable{
ResourceA resA=ResourceA.getInstance();
ResourceB resB=ResourceB.getInstance();

public void run(){
synchronized(resB){
System.out.println("ResourceB for ThreadA is starting!");
Thread.sleep(150);
synchronized(resA){
System.out.println("ResourceA for ThreadA is starting!");
}//end synchronized

}//end synchronized

}//end run

}//end ThreadA

class ThreadB implements Runnable{
ResourceA resA=ResourceA.getInstance();
ResourceB resB=ResourceB.getInstance();


public void run(){
synchronized(resA){
System.out.println("ResourceA for ThreadA is starting!");

Thread.sleep(50);
synchronized(resB){
System.out.println("ResourceB for ThreadA is starting!");
}//end synchronized


}//end synchronized


}//end run

}//end ThreadB
//------------------------------------------------------------------
//class Resource使用Singlaton Pattern來創造獨一無二的Resource

class ResourceA{
public volatile static ResourceA uniqueInstance;//控制統一鎖
private ResourceA(){

}//end constructor

public static ResourceA getInstance(){
if(uniqueInstance==null){
synchronized(your_class_for_ResourceA_name.class){
if(uniqueInstance==null)
uniqueInstance=new ResourceA();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance


}//end ResourceA

class ResourceB{
public volatile static ResourceB uniqueInstance;//控制統一鎖
private ResourceB(){

}//end constructor

public static ResourceB getInstance(){
if(uniqueInstance==null){
synchronized(your_class_for_ResourceB_name.class){
if(uniqueInstance==null)
uniqueInstance=new ResourceB();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance

}//end ResourceB
//------------------------------------------------------------------