Các nguyên lý lập trình hướng đối tượng

Nguyên lý Open-Closed
(The Open-Closed Principle)

Phát biểu

Các thực thể phần mềm (hàm, đơn thể, đối tượng, …) nên được xây dựng theo hướng mở cho việc mở rộng (be opened for extension) nhưng đóng đối với việc sửa đổi (be closed for modification).

Nội dung

Các thực thể trong một phần mềm không đứng riêng lẻ mà có sự gắn kết chặt chẽ với nhau. Chúng phối hợp hoạt động để cùng nhau thực hiện các chức năng của phần mềm. Do đó, việc nâng cấp, mở rộng một thực thể nào đó sẽ ảnh hưởng đến những thực thể liên quan. Điều này có thể dẫn đến việc phải nâng cấp, mở rộng cả những thực thể liên quan đó. Và trong thời đại đầy biến động hiện nay, việc phải thường xuyên nâng cấp, mở rộng các thực thể trong phần mềm là điều khó tránh khỏi.
Để làm cho quá trình bảo trì, nâng cấp, mở rộng phần mềm diễn ra dễ dàng và hiệu quả hơn, các
thực thể phần mềm nên được xây dựng tuân theo nguyên lý Open-Closed. Điều này có nghĩa là các thực thể phần mềm nên được xây dựng sao cho việc nâng cấp, mở rộng đồng nghĩa với việc thêm vào những cái mới chứ không phải là thay đổi những cái hiện có, từ đó tránh được việc phải thay đổi các thực thể liên quan.

Xét ví dụ một đoạn chương trình vẽ đường thẳng và hình chữ nhật bằng C#.

public enum ShapeType
{
LINE,
RECTANGLE
}
public abstract class Shape
{
public abstract ShapeType getType(); 
}
public class Line: Shape
{
public override ShapeType getType()
{
return ShapeType.LINE;
}
public void drawLine()
{
// Draws the line...
}
}
public class Rectangle: Shape
{
public override ShapeType getType() 
{
return ShapeType.RECTANGLE;
}
public void drawRectangle()
{
// Draws the rectangle...
}
}
public void draw(ArrayList shapeList)
{
Line line;
Rectangle rectangle;
foreach (Shape s in shapeList) 
switch (s.getType())
{
case ShapeType.LINE:
line = (Line)s;
line.drawLine();
break;
case ShapeType.RECTANGLE:
rectangle = (Rectangle)s;
rectangle.drawRectangle();
break;
}
}

Đoạn chương trình trên hoạt động rất tốt cho đến khi có sự nâng cấp, mở rộng. Giả sử chúng ta cần nâng cấp, mở rộng đoạn chương trình trên để nó có thể vẽ thêm được hình tròn. Lúc bấy giờ ta phải chỉnh sửa lại hàm "draw", thêm vào một trường hợp vẽ hình tròn. Và trong nhiều tình huống, việc chỉnh sửa hàm "draw" sẽ dẫn đến việc chỉnh sửa những hàm khác liên quan. Hàm "draw" được viết theo cách này được nói là không tuân thủ nguyên lý Open-Closed.
Để đoạn chương trình trên tuân thủ nguyên lý Open-Closed, chúng ta sử dụng tính đa hình của lập trình hướng đối tượng.

public abstract class Shape
{
public abstract void draw(); 
}
public class Line: Shape
{
public override void draw()
{
// Draws the line...
}
}
public class Rectangle: Shape
{
public override void draw()
{
// Draws the rectangle...
}
} 
class Circle: Shape
{
public override void draw()
{
// Draws the circle...
}
}
public void draw(ArrayList shapeList)
{
foreach (Shape s in shapeList)
s.draw();
}

Với đoạn chương trình trên, khi thêm một hình mới vào, chúng ta chỉ việc thêm lớp đối tượng cho hình đó (kế thừa từ Shape) mà không cần phải chỉnh sửa lại hàm "draw". Nó vẫn hoạt động tốt với những hình mới thêm vào.

Ghi chú

i) Không phải lúc nào tất cả các thực thể trong phần mềm đều có thể tuân thủ nguyên lý Open-Closed. Nhưng mục tiêu của phân tích thiết kế hướng đối tượng là phải làm sao cho số lượng các thực thể tuân thủ nguyên lý là lớn nhất, trong đó ưu tiên các thực thể thường xuyên phải nâng cấp, mở rộng thỏa nguyên lý.

ii) Việc tuân thủ nguyên lý Open-Closed của một thực thể phần mềm chỉ mang tính tương đối, phụ thuộc vào ngữ cảnh. Có thể trong ngữ cảnh này, thực thể thỏa nguyên lý, nhưng trong một ngữ cảnh khác, thực thể này không còn tuân thủ nguyên lý nữa. Mục tiêu của phân tích thiết kế hướng đối tượng là phải làm sao cho có nhiều thực thể phần mềm nhất tuân thủ nguyên lý trong ngữ cảnh thường xảy ra nhất của phần mềm, trong đó ưu tiên các thực thể thường xuyên phải nâng cấp, mở rộng thỏa nguyên lý.

Ví dụ trường hợp hàm "draw" như trong đoạn chương trình vẽ hình trên.

public void draw(ArrayList shapeList)
{
foreach (Shape s in shapeList)
s.draw();
}

Hàm "draw" chỉ thỏa nguyên lý trong ngữ cảnh nâng cấp mở rộng là "thêm hình mới". Nếu chúng ta cần nâng cấp, mở rộng theo hướng thay đổi thứ tự vẽ các hình thì hàm "draw" như trên là không thể đáp ứng được. Khi đó nó không còn tuân thủ nguyên lý nữa.

iii) Một tính chất quan trọng trong lập trình hướng đối tượng giúp cho các thực thể phần mềm tăng khả năng tuân thủ nguyên lý Open-Closed là tính đóng gói (encapsulation). Đối tượng nắm giữ thông tin và chịu trách nhiệm trên thông tin mình nắm giữ. Điều này giúp hạn chế sự kết dính (coupling) giữa các lớp đối tượng với nhau. Trường hợp lý tưởng là tất cả thuộc tính của đối tượng được đặt tầm vực private. việc thay đổi trên thuộc tính chỉ có thể được thực hiên thông qua những xử lý của phương thức. Những phương thức của đối tượng khác, kể cả đối tượng kế thừa không thể truy xuất được đến những thuộc tính này.

iv) Việc hạn chế sử dụng ép kiểu động (runtime type-casting) trong các thực thể phần mềm cũng sẽ giúp làm tăng khả năng tuân thủ nguyên lý Open-Closed của chúng. Vì bản chất của việc ép kiểu động là làm việc với một kiểu dữ liệu cụ thể. Khi muốn nâng cấp, mở rộng thực thể để nó có thể làm việc với những kiểu dữ liệu khác, đoạn chương trình sử dụng ép kiểu động phải được thay đổi để có thể làm việc được với các kiểu dữ liệu khác này.

public void doSomething(Vehicle vehicle)
{
Car car = (Car)vehicle;
car.run();
car.stop();
}

Khi cần nâng cấp, mở rộng để đoạn chương trình trên có thể làm việc được với các lớp đối tượng khác kế thừa từ "Vehicle", chúng ta phải chỉnh sửa lại nó.
Ý nghĩa
Nguyên lý Open-Closed là nguyên lý cốt lõi và là một trong bốn nguyên lý cơ bản làm nền tảng cho phân tích thiết kế hướng đối tượng. Nó giúp cho phần mềm dễ bảo trì, nâng cấp và mở rộng.


Nguyên lý Nghịch đảo phụ thuộc
(The Dependency Inversion Principle)

Phát biểu

Các thành phần trong phần mềm không nên phụ thuộc vào những cái riêng, cụ thể (details) mà ngược lại nên phụ thuộc vào những cái chung, tổng quát (abstractions) của những cái riêng, cụ thể đó.
Những cái chung, tổng quát (abstractions) không nên phụ vào những cái riêng, cụ thể (details). Sự phụ thuộc này nên được đảo ngược lại.

Nội dung

Những cái chung, tổng quát là tập hợp của những đặc tính chung nhất từ những cái riêng, cụ thể. Những cái riêng, cụ thể dù khác nhau thế nào đi nữa cũng đều tuân theo các quy tắc chung mà cái chung, tổng quát của nó đã định nghĩa. Những cái chung, tổng quát là những cái ít thay đổi và ít biến động. Trong khi đó, sự thay đổi lại thường xuyên xảy ra ở những cái riêng, cụ thể. Việc phụ thuộc vào những cái chung, tổng quát sẽ giúp cho các thành phần trong phần mềm trở nên linh động (flexible) và thích ứng tốt với sự thay đổi thường xuyên diễn ra ở những cái riêng, cụ thể. Khi phụ thuộc vào những cái chung, tổng quát, các thành phần trong phần mềm vẫn có thể hoạt động tốt mà không cần phải sửa đổi một khi cái riêng, cụ thể được thay thế bằng một cái riêng, cụ thể khác cùng loại.

Lấy ví dụ đoạn chương trình đọc dữ liệu từ bàn phím và xuất ra máy in.

public void copy()
{
Keyboard keyboard = new Keyboard();
Printer printer = new Printer();
char c;
while ((c =  keyboard.read()) != 'q')
printer.write(c);
}

Khi nâng cấp, mở rộng đoạn chương trình trên để nó có thể xuất dữ liệu ra máy in hoặc tập tin thì chúng ta phải chỉnh sửa lại đoạn chương trình trên như sau.

public void copy(OutputType type)
{
Keyboard keyboard = new Keyboard();
Printer printer = new Printer();
File file = new File();
char c;
while ((c = keyboard.read()) != 'q')
if (type ==  OutputType.PRINTER)
printer.write(c);
else if (type == OutputType.FILE)
file.write(c);
}

Rõ ràng hàm "copy" như trên đã vi phạm nguyên lý Open-Closed do khi mỗi lần cần thêm một thiết bị đọc ghi mới vào, chúng ta phải chỉnh sửa lại nó. Nguyên nhân làm cho hàm "copy" vi phạm nguyên lý Open-Closed là do nó làm việc với từng thiết bị đọc ghi cụ thể. Khi thêm một thiết bị đọc ghi mới, chúng ta phải thêm vào hàm "copy" đoạn lệnh để làm việc với thiết bị đọc ghi mới. Khi đó chúng ta nói hàm "copy" vi phạm nguyên lý Nghịch đảo phụ thuộc.
Để đoạn chương trình trên tuân thủ Nguyên lý Nghịch đảo phụ thuộc, từ đó tuân thủ Nguyên lý Open-Closed, chúng ta phải cho nó làm việc với thiết bị đọc ghi tổng quát.

public void copy(Reader reader, Writer writer)
{
char c;
while ((c = reader.read()) != 'q')
writer.write(c);
}

Hàm "copy" như trên có thể làm việc tốt với bất kỳ thiết bị đọc ghi nào tuân thủ interface của Reader và Writer. Khi cần thêm thiết bị đọc ghi mới, chúng ta chỉ việc thêm lớp đối tượng kế thừa từ Reader hoặc Writer mà không phải chỉnh sửa lại hàm "copy".
Trích lời Allen Holub: "The more abstraction you add, the greater the flexibility. In today's business environment, where requirements regularly change as program develops, this flexibility is essential.".

Chú ý

i) Nguyên lý Nghịch đảo phụ thuộc có mối liên hệ mật thiết với nguyên lý Open-Closed. Một khi nguyên lý Nghịch đảo phụ thuộc bị vi phạm, có nghĩa là những thành phần trong phần mềm phụ thuộc vào những cái riêng, cụ thể, việc nâng cấp, mở rộng ở những cái riêng, cụ thể (điều này rất thường xảy ra) buộc những thành phần phụ thuộc vào nó bị thay đổi theo. Điều này dẫn đến vi phạm nguyên lý Open-Closed.

ii) Sự nghịch đảo được đề cập đến ở đây nhằm nhấn mạnh đến việc cần phải thay đổi quan điểm trong phân tích thiết kế phần mềm. Theo lối suy nghĩ "chia để trị" của lập trình hướng cấu trúc, những công việc lớn, phức tạp, mang tính trừu tượng cao thường được phân ra thành những công việc nhỏ, đơn giản và cụ thể hơn. Khi đó, cấu trúc phần mềm có xu hướng theo dạng những thành phần lớn (trừu tượng) gọi đến những thành phần nhỏ (cụ thể) hơn để yêu cầu chúng thực hiện công việc. Điều này thường làm cho những thành phần trong phần mềm phụ thuộc vào những cái riêng, cụ thể. Trong phân tích thiết kế hướng đối tượng, sự phụ thuộc này nên được đảo ngược lại.

iii) Một thành phần trong phần mềm vi phạm nguyên lý Nghịch đảo phụ thuộc sẽ có tính tái sử dụng (reusability) không cao. Việc mang những thành phần này sử dụng vào một ngữ cảnh khác với những cái riêng, cụ thể khác là khó có thể thực hiện được nếu như không thực hiện việc chỉnh sửa nào trên chúng.

iv) Một quy ước trong lập trình hướng đối tượng giúp cho các thành phần trong phần mềm tăng khả năng tuân thủ nguyên lý Nghịch đảo phụ thuộc là thực hiện việc truy xuất đến các đối tượng thông qua interface của chúng. Điều này sẽ làm cho các thành phần bên trong phần mềm có tính linh động (flexibility) cao, không phải sửa đổi khi thay thế các đối tượng được truy xuất đến bằng đối tượng khác cùng loại.

public void doSomething(Car car)
{
car.run();
car.stop();
}
public void doSomething(Vehicle vehicle)
{
vehicle.run();
vehicle.stop();
}

Trong hai đoạn chương trình trên, đoạn chương trình thứ hai vẫn làm việc tốt khi chúng ta thêm vào các đối tượng khác cùng loại với "Car" mà kế thừa từ "Vehicle".

Ý nghĩa

Nguyên lý Nghịch đảo phụ thuộc có mối liên hệ mật thiết với nguyên lý Open-Closed và là một trong bốn nguyên lý cơ bản làm nền tảng cho phân tích thiết kế hướng đối tượng. Nó giúp cho phần mềm có tính tái sử dụng cao, linh động và bền vững (robustness) trước những sự thay đổi.


Nguyên lý Thay thế Liskov
(The Liskov Substitution Principle)

Phát biểu

Lớp B chỉ nên kế thừa từ lớp A khi và chỉ khi với mọi hàm F thao tác trên các đối tượng của A, cách cư xử (behaviors) của F không thay đổi khi ta thay thế (substitute) các đối tượng của A bằng các đối tượng của B.

Nội dung

Kế thừa (inheritance) là một trong những tính chất cơ bản của lập trình hướng đối tượng. Đó là khả năng định nghĩa một lớp đối tượng dựa trên các lớp đối tượng đã được định nghĩa trước đó. Các đối tượng của lớp kế thừa có khả năng cư xử (behave) như các đối tượng của lớp cơ sở. Điều này có nghĩa là các đối tượng của lớp kế thừa hoàn toàn có thể thay thế các đối tượng của lớp cơ sở trong những hàm thao tác trên các đối tượng của lớp cơ sở.
Chính vì tính chất này mà chúng ta không thể sử dụng kế thừa một cách tùy tiện. Giả sử ta có lớp A và hàm F thao tác trên các đối tượng của A. Để nâng cấp, mở rộng phần mềm, ta cần thêm vào lớp B kế thừa từ A. Nhưng việc thay thế các đối tượng của A bằng các đối tượng của B lại làm cho F cư xử sai lệch so với trước khi thực hiện việc thay thế. Lúc này, để F có thể cư xử không đổi so với trước, ta phải chỉnh sửa lại F. Điều này làm cho F vi phạm nguyên lý Open-Closed.

Đoạn chương trình sau cho thấy việc kế thừa tùy tiện chỉ với mục đích tái sử dụng nguy hiểm như thế nào.

public class Stack
{
private ArrayList data; 
// More data members of stack.
public virtual void push(int n)
{
// Pushes n to stack...
}
public virtual int pop()
{
// Pops value from stack...
}
}
public class Queue: Stack
{
// Data members of Queue. 
public override void push(int n)
{
// Pushes n to queue...
}
public override int pop()
{
// Pops value from queue...
}
}
public int func(Stack p)
{
p.push(5);
p.push(6);
p.push(7); 
int a = p.pop();
int b = p.pop();
if (a == 7 && b == 6)
return a * b;
throw new ArgumentException();
}

Với mục đích tái sử dụng là một số thuộc tính và phương thức trong "Stack", chúng ta cho "Queue" kế thừa từ Stack. Xét hàm "func" thao tác trên đối tượng của "Stack", do "Queue" kế thừa từ "Stack" nên chúng ta hoàn toàn có thể truyền đối tượng của "Queue" vào hàm này. Nhưng cách cư xử của hàm "func" khi thao tác trên các đối tượng của "Stack" và "Queue" là khác nhau. Với các đối tượng của "Stack" hàm func luôn trả về chính xác tích của hai số 7 và 6. Nhưng với các đối tượng của "Queue" hàm func lại luôn gây ra một exception. Để hàm "func" có thể cư xử trên các đối tượng của "Stack" và "Queue" như nhau, chúng ta phải viết lại nó. Điều này làm cho hàm "func" vi phạm nguyên lý Open-Closed. Khi đó ta nói hàm "func" vi phạm nguyên lý Thay thế Liskov.

Chú ý

i) Nguyên lý Thay thế Liskov có mối liên hệ mật thiết với Nguyên lý Open-Closed. Sự vi phạm nguyên lý Thay thế Liskov sẽ dẫn đến sự vi phạm nguyên lý Open-Closed. Một thực thể phần mềm vi phạm nguyên lý Thay thế Liskov sẽ cư xử khác nhau trên các đối tượng của lớp cơ sở và lớp kế thừa. Để thực thể phần mềm này vẫn có thể làm việc tốt trên các đối tượng của cả lớp cơ sở và lớp kế thừa, chúng ta phải chỉnh sửa lại nó. Điều này dẫn đến vi phạm nguyên lý Open-Closed.

ii) Không phải lúc nào tất cả các thực thể trong phần mềm đều có thể tuân thủ nguyên lý Thay thế Liskov. Nhưng mục tiêu của phân tích thiết kế hướng đối tượng là phải làm sao cho số lượng các thực thể tuân thủ nguyên lý là lớn nhất, trong đó ưu tiên các thực thể thường xuyên phải nâng cấp, mở rộng thỏa nguyên lý.

iii) Việc tuân thủ nguyên lý Thay thế Liskov của một thực thể phần mềm chỉ mang tính tương đối, phụ thuộc vào ngữ cảnh. Có thể trong ngữ cảnh này, thực thể thỏa nguyên lý, nhưng trong một ngữ cảnh khác, thực thể này không còn tuân thủ nguyên lý nữa. Mục tiêu của phân tích thiết kế hướng đối tượng là phải làm sao cho có nhiều thực thể phần mềm nhất tuân thủ nguyên lý trong ngữ cảnh thường xảy ra nhất của phần mềm, trong đó ưu tiên các thực thể thường xuyên phải nâng cấp, mở rộng thỏa nguyên lý.

iv) Quan hệ "IS-A" thường được dùng để phát hiện kế thừa. Khi lớp đối tượng B về mặt ngữ nghĩa là một trường hợp đặc biệt của lớp đối tượng A thì ta có thể cho B kế thừa từ A. Nhưng thực tế cho thấy, trong một số ngữ cảnh của phần mềm, một lớp đối tượng có quan hệ "IS-A" với những lớp đối tượng khác nhưng việc để nó kế thừa những lớp đối tượng này sẽ dẫn đến việc vi phạm nguyên lý Thay thế Liskov.

Xét đoạn chương trình sau.

public class Rectangle
{
// Data members of rectangle...
// Member functions of rectangle...
}
public class Square: Rectangle
{
// Data members of square... 
// Member functions of square...
}
public double doSomething(Rectangle obj)
{
obj.setWidth(5);
obj.setHeight(6);
if (obj.Area == 30)
return obj.Area;
throw new ArgumentException();
}

Ở đoạn chương trình trên, mặc dù về mặt ngữ nghĩa, hình vuông là một trường hợp của hình chữ nhật. Điều này hoàn toàn đúng!!! Nhưng trong ngữ cảnh này, việc để "Square" kế thừa "Rectangle" là không phù hợp. Lúc này hàm "doSomething" cư xử khác nhau trên các đối tượng của "Rectangle" và "Square". Như vậy hàm "doSomething" đã vi phạm nguyên lý Thay thế Liskov. Để hàm "doSomething" có thể làm việc được trên cả "Rectangle" và "Square" chúng ta phải chỉnh sửa lại nó. Như vậy việc vi phạm nguyên lý Thay thế Liskov đã làm cho hàm "doSomething" vi phạm nguyên lý Open-Closed.

v) Nguyên lý Thay thế Liskov có mối liên hệ mật thiết với kỹ thuật "Design by Contract" được đề cập bởi Bertrand Meyers. Kỹ thuật này chỉ ra rằng: mỗi phương thức trong một lớp đối tượng, khi được định nghĩa, đã hàm chứa trong nó tiền điều kiện (pre-condition) và hậu điều kiện (post-condition). Tiền điều kiện là những điều kiện cần để phương thức có thể thực hiện được. Hậu điều kiện là những ràng buộc phát sinh sau khi thực hiện phương thức. Khi thực hiện việc kế thừa, phương thức được định nghĩa lại trong lớp kế thừa phải có tiền điều kiện lỏng lẻo hơn (weaker) và hậu điều kiện chặt chẽ hơn (stronger). Điều này có nghĩa là trước khi thực hiện, phương thức được định nghĩa lại trong lớp kế thừa không được đòi hỏi nhiều hơn như khi nó được định nghĩa trong lớp cơ sở. Và sau khi thực hiện, phương thức được định nghĩa lại trong lớp kế thừa phải đảm bảo tất cả những ràng buộc phát sinh như khi nó được định nghĩa trong lớp cơ sở. Chỉ khi nào những điều trên được đáp ứng cho mọi phương thức trong lớp kế thừa thì lớp kế thừa mới được xem là cư xử như lớp cơ sở. Và khi đó, việc để nó kế thừa từ lớp cơ sở mới là đúng đắn trong ngữ cảnh phần mềm đang xét.

vi) Nguyên lý Thay thế Liskov và kỹ thuật "Design by Contract" vô tình làm cho việc kế thừa trở nên rất khó thực hiện. Khi cần thêm vào một lớp kế thừa, chúng ta phải xem xét rất kỹ lưỡng lại tất cả hàm có thao tác trên lớp cơ sở xem chúng có vi phạm nguyên lý Thay thế Liskov hay không. Chúng ta cũng cần phải xem xét tất cả các phương thức của lớp kế thừa xem chúng có vi phạm những quy định của kỹ thuật "Design by Contract" hay không. Tất cả những điều này là do lớp kế thừa có một mối liên hệ mật thiết với lớp cơ sở. Lớp kế thừa bị kết dính (coupling) chặt chẽ với lớp cơ sở. Sự kết dính này rõ ràng làm cho phần mềm kém linh động (flexibility) một khi có sự thay đổi xảy ra. Do đó, để hạn chế sự kết dính này mà vẫn đảm bảo được tính tái sử dụng, chúng ta chỉ nên kế thừa interface và sử dụng composition thay cho việc kế thừa.

Ý nghĩa

Nguyên lý Thay thế Liskov có mối liên hệ mật thiết với nguyên lý Open-Closed và là một trong bốn nguyên lý cơ bản làm nền tảng cho phân tích thiết kế hướng đối tượng. Nó giúp nâng cao tính tái sử dụng và bền vững của phần mềm trước những sự thay đổi.


Nguyên lý Phân tách interface
(The Interface Segregation)

Phát biểu

Không nên buộc các thực thể phần mềm phụ thuộc vào những interface mà chúng không sử dụng đến.
Nội dung
Khi xây dựng một lớp đối tượng, đặc biệt là những lớp trừu tượng (abstract class), nhiều người thường có xu hướng để cho lớp đối tượng thực hiện càng nghiều chức năng càng tốt, đưa thật nhiều thuộc tính và phương thức vào lớp đối tượng đó. Những lớp đối tượng như vậy được gọi là những lớp đối tượng có interface bị "ô nhiễm" (fat interface or polluted interface).
Khi một lớp đối tượng có interface bị "ô nhiễm", nó sẽ trở nên cồng kềnh. Một thực thể phần mềm nào đó chỉ cần thực hiện một công việc đơn giản mà lớp đối tượng này hỗ trợ buộc phải làm việc với toàn bộ interface của lớp đối tượng đó. Việc phải truyền đi truyền lại nhiều lần những đối tượng có interface bị "ô nhiễm" sẽ làm giảm hiệu năng của phần mềm.
Đặc biệt đối với lớp trừu tượng có interface bị "ô nhiễm", một số lớp kế thừa chỉ quan tâm đến một phần interface của lớp cơ sở nhưng bị buộc phải thực hiện việc cài đặt cho cả phần interface không hề có ý nghĩa đối với chúng. Điều này dẫn đến sự dư thừa không cần thiết trong các thực thể phần mềm. Quan trọng hơn nữa, việc buộc các lớp kế thừa phụ thuộc vào phần interface mà chúng không sử dụng đến sẽ làm tăng sự kết dính (coupling) giữa các thực thể phần mềm. Một khi sự nâng cấp, mở rộng diễn ra, đòi hỏi phần interface đó phải thay đổi, các lớp kế thừa này bị buộc phải chỉnh sửa theo. Điều này làm cho chúng vi phạm nguyên lý Open-Closed.
Hình bên dươi là sơ đồ lớp cho đoạn chương trình tính điện trở mạch điện. "Resistor" và "Lamp" là những mạch điện đơn giản với điện trở là một thuộc tính của mạch. Trong khi "SeriesCircuit" và "ParallelCircuit" là những mạch điện phức hợp với điện trở của mạch được tính từ các mạch điện con. Để có thể cư xử như nhau trên các loại mạch điện này hay nói cách khác là truy xuất đến chúng một cách "trong suốt" (transparency), chúng ta có "Circuit" là lớp trừu tượng chung đại diện cho các mạch điện khác nhau.
Lớp "Circuit" được thiết kế như trên được gọi là có interface bị "ô nhiễm". "Resistor" và "Lamp" bị buộc phải thực hiện việc cài đặt cho các phương thức "add" và "remove" hoàn toàn chẳng có ý nghĩa gì với chúng. Điều này gây ra sự dư thừa code không cần thiết cũng như gây "khó chịu" cho những thực thể phần mềm khác sử dụng "Resistor" và "Lamp".
Nhưng vấn đề chỉ thật sự xảy ra khi chúng ta nâng cấp, mở rộng đoạn chương trình trên. Giả sử chúng ta cần thêm vào phương thức "removeAt" để hỗ trợ việc xóa mạch điện con tại vị trí nào đó trong mạch điện phức hợp. Lúc này, chúng ta phải thực hiện việc chỉnh sửa trên tất cả các lớp đối tượng kế thừa từ "Circuit". Việc chỉnh sửa trên "SeriesCircuit" và "ParallelCircuit" xem ra còn có thể chấp nhận được. Nhưng việc phải chỉnh sửa trên "Resistor" và "Lamp" là không thể chấp nhận được vì phương thức "removeAt" chẳng hề có ý nghĩa gì đối với chúng. Điều này rõ ràng làm cho "Resistor" và "Lamp" vi phạm nguyên lý Open-Closed một cách "không chính đáng".

Chú ý

i) Nguyên lý Phân tách interface có mối liên hệ với nguyên lý Open-Closed. Sự vi phạm nguyên lý Phân tách interface có khả năng dẫn đến sự vi phạm nguyên lý Open-Closed (xem phân tích ở trên).

ii) Để tránh vi phạm nguyên lý Phân tách Inteface, chúng ta nên giữ cho interface của lớp đối tượng đơn giản và gọn nhẹ, nên làm theo tiêu chí "a class should do one thing and do it well". Chúng ta không nên để cho lớp đối tượng đảm nhận quá nhiều trách nhiệm vì điều này dễ làm cho interface của nó bị "ô nhiễm".

iii) Interface bị "ô nhiễm" của lớp đối tượng nên được phân tách ngay khi có thể để tránh khả năng dẫn đến sự vi phạm nguyên lý Open-Closed. Việc phân tách interface bị "ô nhiễm" của một lớp cơ sở có thể được thực hiện thông qua việc tăng thêm mức độ trừu tượng trong cây kế thừa của nó. Lớp cơ sở ban đầu chỉ nên có interface đơn giản mà mọi lớp kế thừa của nó đều cần phải có. Sau đó, phần interface chung của một bộ phận lớp kế thừa được tổng hợp lại trong một lớp cơ sở. Và lớp cơ sở này lại kế thừa từ lớp cơ sở ban đầu. Như vậy những lớp kế thừa thuộc nhánh khác không bị phụ thuộc vào phần interface mà chúng không sử dụng đến của bộ phận lớp kế thừa kia.
Với trường hợp đoạn chương trình tính điện trở mạch điện, để giải quyết vấn đề interface của "Circuit" bị "ô nhiễm", chúng ta tăng thêm một mức độ trừu tượng trong cây kế thừa của nó. Khi đó, "Circuit" đóng vai trò là lớp trừu tượng cho các mạch điện khác nhau. Nó chỉ chứa phần interface chung nhất của tất cả các mạch điện này. Và trong ngữ cảnh bài toán tính điện trở đơn giản thì nó chỉ chứa phương thức "calcResistance".
Chúng ta sẽ có lớp "SingleCircuit" đại diện cho các mạch điện đơn giản và "ComplexCircuit" đại diện cho cách mạch điện phức hợp. "SingleCircuit" chứa phần interface chung của các mạch điện đơn giản như "Resistor" và "Lamp" trong khi "ComplexCircuit" chứa phần interface chung của các mạch điện phức hợp. Chúng ta sẽ có được cây kế thừa như hình bên dưới.
Lúc này, khi cần thêm vào phương thức "removeAt" chúng ta chỉ việc nâng cấp phần interface của "ComplexCircuit", nhánh kế thừa bên "SingleCircuit" sẽ không bị ảnh hưởng.

iv) Trong một số trường hợp, sau khi phân tách interface, một số lớp kế thừa mới thêm vào muốn sử dụng những phần interface đã phân tách, chúng có thể thực hiện việc đa kế thừa từ những lớp đối tượng hỗ trợ những phần interface này hoặc cũng có thể kế thừa từ một lớp đối tượng hỗ trợ một phần interface chúng cần và thực hiện composition đối với những đối tượng hỗ trợ phần interface còn lại.

Ý nghĩa

Nguyên lý Phân tách interface có mối liên hệ với nguyên lý Open-Closed và là một trong bốn nguyên lý cơ bản làm nền tảng cho phân tích thiết kế hướng đối tượng. Nó giúp giảm sự cồng kềnh, dư thừa không cần thiết cho phần mềm và quan trọng hơn là giảm sự kết dính (copuling) làm hạn chế tính linh động (flexibility) của phần mềm.

Source: http://my.opera.com/Downz/blog/show.dml/375993

web 2.0 không chỉ là công nghệ

Được xem là một cuộc cách mạng trên thế giới mạng, thế hệ web mới có những thay đổi quan trọng không chỉ ở nền tảng công nghệ mà còn cả ở cách thức sử dụng - hình thành nên môi trường cộng đồng, ở đó mọi người cùng tham gia đóng góp cho xã hội "ảo" chứ không chỉ "duyệt và xem".

Web 2.0 là gì? Làm sao phân biệt đâu là Web 1.0 đâu là Web 2.0? Thuật ngữ "Web 2.0" đang trở nên thịnh hành và có phần được lăng xê quá mức. Thực chất, Web 2.0 có nghĩa là sử dụng web đúng với bản chất và khả năng của nó!

Mục tiêu đầu tiên của những người tiên phong xây dựng Internet là nhằm kết nối các nhà nghiên cứu và các máy tính của họ với nhau để có thể chia sẻ thông tin hiệu quả. Khi bổ sung World Wide Web (năm 1990), Tim Berners-Lee cũng nhằm mục tiêu tạo phương tiện cho phép người dùng tự do đưa thông tin lên Internet và dễ dàng chia sẻ với mọi người (trình duyệt web đầu tiên do Berners-Lee viết bao gồm cả công cụ soạn thảo trang web). Tuy nhiên, sau đó web đã phát triển theo hướng hơi khác mục tiêu ban đầu.

Tuy có một số ngoại lệ nhưng thế giới Web 1.0 (thế hệ web trước Web 2.0) chủ yếu gồm các website "đóng" của các hãng thông tấn hay các công ty nhằm mục đích tiếp cận độc giả hay khách hàng hiệu quả hơn. Nó là phương tiện phát tin hơn là phương tiện chia sẻ thông tin. Chỉ đến gần đây, với sự xuất hiện của nhiều kỹ thuật mới như blog (hay weblog), wiki... web mới trở nên có tính cộng đồng (và cộng tác) hơn và trở nên gần hơn với sự kỳ vọng và khả năng thực sự của nó.

KHÁI NIỆM

Khái niệm Web 2.0 đầu tiên được Dale Dougherty, phó chủ tịch của OReilly Media, đưa ra tại hội thảo Web 2.0 lần thứ nhất do OReilly Media và MediaLive International tổ chức vào tháng 10/2004. Dougherty không đưa ra định nghĩa mà chỉ dùng các ví dụ so sánh phân biệt Web 1.0 và Web 2.0: "DoubleClick là Web 1.0; Google AdSense là Web 2.0. Ofoto là Web 1.0; Flickr là Web 2.0. Britannica Online là Web 1.0; Wikipedia là Web 2.0. v.v...". Sau đó Tim OReilly, chủ tịch kiêm giám đốc điều hành OReilly Media, đã đúc kết lại 7 đặc tính của Web 2.0:

1. Web có vai trò nền tảng, có thể chạy mọi ứng dụng

2. Tập hợp trí tuệ cộng đồng

3. Dữ liệu có vai trò then chốt

5. Phần mềm được cung cấp ở dạng dịch vụ web và được cập nhật không ngừng

4. Phát triển ứng dụng dễ dàng và nhanh chóng

6. Phần mềm có thể chạy trên nhiều thiết bị

7. Giao diện ứng dụng phong phú

Thoạt đầu, Web 2.0 được chú trọng tới yếu tố công nghệ, nhấn mạnh tới vai trò nền tảng ứng dụng. Nhưng đến hội thảo Web 2.0 lần 2 tổ chức vào tháng 10/2005, Web 2.0 được nhấn mạnh đến tính chất sâu xa hơn – yếu tố cộng đồng.

CÔNG NGHỆ

Thực tế, ứng dụng trên web là thành phần rất quan trọng của Web 2.0. Hàng loạt công nghệ mới được phát triển nhằm làm cho ứng dụng trên web "mạnh" hơn, nhanh hơn và dễ sử dụng hơn, được xem là nền tảng của Web 2.0.

Kiến trúc công nghệ của Web 2.0 hiện vẫn đang phát triển nhưng cơ bản bao gồm: phần mềm máy chủ, cơ chế cung cấp nội dung, giao thức truyền thông, trình duyệt và ứng dụng.

Cung cấp nội dung

Bước phát triển đầu tiên và quan trọng nhất hướng đến Web 2.0 đó là cơ chế cung cấp nội dung, sử dụng các giao thức chuẩn hoá để cho phép người dùng sử dụng thông tin theo cách của mình (nghĩa là có khả năng tùy biến thông tin). Có nhiều giao thức được phát triển để cung cấp nội dung như RSS, RDF và Atom, tất cả đều dựa trên XML. Ngoài ra còn có các giao thức đặc biệt như FOAF và XFN dùng để mở rộng tính năng của website hay cho phép người dùng tương tác.

Dịch vụ web

Các giao thức truyền thông 2 chiều là một trong những thành phần then chốt của kiến trúc Web 2.0. Có hai loại giao thức chính là REST và SOAP. REST (Representation State Transfer) là dạng yêu cầu dịch vụ web mà máy khách truyền đi trạng thái của tất cả giao dịch; còn SOAP (Simple Object Access Protocol) thì phụ thuộc máy chủ trong việc duy trì thông tin trạng thái. Với cả hai loại, dịch vụ web đều được gọi qua API. Ngôn ngữ chung của dịch vụ web là XML, nhưng có thể có ngoại lệ.

Một ví dụ điển hình của giao thức truyền thông thế hệ mới là Object Properties Broadcasting Protocol do Chris Dockree phát triển. Giao thức này cho phép các đối tượng ảo (tồn tại trên web) tự biết chúng "là gì và có thể làm gì", nhờ vậy có thể tự liên lạc với nhau khi cần.

Phần mềm máy chủ

Web 2.0 được xây dựng trên kiến trúc web thế hệ trước nhưng chú trọng hơn đến phần mềm làm việc ở "hậu trường". Cơ chế cung cấp nội dung chỉ khác phương thức cấp phát nội dung động (của Web 1.0) về danh nghĩa, tuy nhiên dịch vụ web yêu cầu tiến trình làm việc và dữ liệu chặt chẽ hơn.

Các giải pháp phát triển theo hướng Web 2.0 hiện nay có thể phân làm 2 loại: hoặc xây dựng hầu hết tính năng trên một nền tảng máy chủ duy nhất; hoặc xây dựng ứng dụng "gắn thêm" cho máy chủ web, có sử dụng giao tiếp API.

CỘNG ĐỒNG

Công nghệ chỉ là "bề nổi" của Web 2.0, chính cộng đồng người dùng mới là yếu tố nền tảng tạo nên thế hệ web mới. Việc chuyển từ "duyệt và xem" sang "tham gia" là cuộc cách mạng thực sự, dĩ nhiên nhờ có sự phát triển công nghệ giúp hiện thực khả năng này nhưng ở đây muốn nhấn mạnh đến hành vi của người dùng đối với web.

Hiện trạng phổ biến của các website thế hệ 1.0 đó là chứa nhiều thứ phiền toái và làm việc chậm chạp, dường như luôn muốn gửi đến người dùng thông điệp: đây là website của chúng tôi chứ không phải của bạn. Căn nguyên của vấn đề có thể là do chủ sở hữu các website cảm thấy họ "cho không" cái gì đó. Đôi khi chủ sở hữu website cho rằng càng làm khó người dùng thì họ càng được lợi! Điển hình như một số site cho bạn đọc đoạn đầu của bài viết rồi yêu cầu bạn phải đăng ký (có phí hay không) để đọc nốt phần còn lại.

		NHỮNG VẤN ĐỀ CỦA WEB 2.0
		• Quá kỳ vọng: Nhiều người cho rằng Web 2.0 sẽ đặt dấu chấm hết cho ứng dụng cài đặt trên máy tính (ứng dụng desktop) và là giải pháp cho mọi vấn đề trong lĩnh vực phần mềm. Các ứng dụng Web 2.0 yêu cầu kết nối Internet ổn định và nhanh để làm việc. Trừ khi kết nối băng rộng được phủ khắp, còn không thì Web 2.0 chỉ là một bổ sung cho cách thức chúng ta làm việc (bên cạnh ứng dụng desktop). • Quá đơn giản: Web 2.0=Ajax! Cũng như Web 2.0, Ajax được kỳ vọng quá nhiều, thậm chí nhiều người còn đánh đồng Ajax với Web 2.0. Thực chất, Ajax chỉ là một trong số nhiều công nghệ nền tảng của Web 2.0 và Ajax còn có những hạn chế. • Quá chú trọng công nghệ: RSS, SOA, Ajax... hàng loạt công nghệ nổi đình nổi đám gần đây được gắn liền với Web 2.0. Người ta hăm hở áp dụng các công nghệ mới mà không quan tâm đến các tính chất quan trọng hơn: truyền thông, cộng tác, trí tuệ cộng đồng.

Dĩ nhiên, với sự phổ biến của các phần mềm máy chủ, trong đó có cả phần mềm miễn phí như Apache thì người dùng có thể đưa lên web bất kỳ thông tin gì. Tuy nhiên có nhiều yếu tố cản trở: kỹ năng tạo website, hạn chế của nhà cung cấp dịch vụ Internet, việc bảo mật và kiểm duyệt...

Về cơ bản, Web 2.0 trao quyền nhiều hơn cho người dùng và tạo nên môi trường liên kết chặt chẽ các cá nhân với nhau. Giờ đây có nhiều ví dụ cho thấy cộng đồng người dùng có thể đóng góp thông tin giá trị khi họ có phương tiện thích hợp. Wikipedia có lẽ là ví dụ nổi tiếng nhất. Tuy có nhiều học giả không đánh giá cao Wikipedia, nhưng họ quên một điều quan trọng: nó đủ tốt, miễn phí và nhiều người có thể đọc. Ngoài ra còn có những ví dụ khác như các site Reddit và Digg để cho người dùng quyết định thông tin gì là quan trọng, hay del.icio.us cho phép mọi người chia sẻ những địa chỉ web hay.

Web 2.0 cho phép mọi người có thể đưa lên mạng bất cứ thông tin gì. Với số lượng người tham gia rất lớn, đến mức độ nào đó, qua quá trình sàng lọc, thông tin sẽ trở nên vô cùng giá trị. Ở đây có sự tương đồng với thuyết chọn lọc tự nhiên.

KẾT LUẬN

Thật sự, Web 2.0 không phải là cái gì đó hoàn toàn mới mà là sự phát triển từ web hiện tại. Nó vẫn là web như chúng ta dùng lâu nay, chỉ có điều giờ đây chúng ta làm việc với web theo cách khác. Các website không còn là những "ốc đảo" mà trở thành những nguồn thông tin và chức năng, hình thành nên môi trường điện toán phục vụ các ứng dụng web và người dùng.

Không phải là viễn cảnh, Web 2.0 đã hiện hữu quanh chúng ta với hàng loạt website thế hệ mới. Xu hướng chuyển đổi sang Web 2.0 đang diễn ra mạnh mẽ và là xu thế tất yếu.

Source: http://viendongco.com/vn/content.asp?active_page_id=126

Cẩm nang cưa gái dành cho nerd và dân kỹ thuật

Tác giả: Wasabi

.......... PREFACE ......................

Thấy các bác ở đây hì hà hì hục với máy tính suốt ngày em thấy cũng lo cho tương lai con em của chúng ta. Cu Nghĩa gì đó cũng suốt ngày lo hì hụi dịch thuật các thứ cắp tráp theo hầu anh cu Hacao đi làm cái linux để tưởng nhớ người yêu đã bỏ anh đi (lý do rất có thể vì anh đã không được đọc cẩm nang này khi ấy) - thì tương lai cũng đen sì như anh hacao thật là đáng thương xót xiết bao.

Các bác phải biết là vì sao người viết bài này lo, không phải vì các bác đã donate thời gian tiền bạc và công sức của các bác dành cho linux bsd solaris các kiểu (theo Wasabi thì linux bsd các thứ thực sự nâng cao trí thông minh cho các bác và các thế hệ con cháu sau này), mà là vấn đề nếu các bác cứ suốt ngày chúi mũi vào OSS, thì thời gian đâu để cưa gái, mà thói đời trồng cây mà không chăm bón, thì làm sao mà thu được quả ngọt? Có người như Crank của chúng ta sẽ lí luận là anh cần mẹ gì gái đẹp, anh chỉ cần cái domain đẹp là được. Thật là đáng thương biết bao! Có thể Crank không cần gái đẹp vợ đẹp nhưng mà Crank cũng rất muốn thế hệ con cháu của Crank (gọi là Crank con) cũng đẹp trai, cũng tài ba như Crank, mà Crank lại đi lấy một cô vợ (cứ giả thiết) phải coi Thị Nở bằng cụ, thì lấy đâu ra mà con cái sau này đẹp trai tài ba cơ chứ? Thế nên việc lấy được một cô vợ đẹp, mà tiền thân là cưa được một gái thông minh xinh xẻo nhí nhảnh dễ thương, cũng vẫn là một nhu cầu vô cùng cấp thiết của dân kỹ thuật chúng ta.

Khó khăn đặt ra, là việc chúng ta có máy tính, có một tình yêu rồi, nên trái tim tươi đỏ vốn có phần thiếu máu của chúng ta sẽ phải chia thêm một phần nữa (bên cạnh $$$ và OSS) - thì sẽ thật là vất vả biết bao. Thế nên việc tồn tại một cuốn cưa-gái-handbook là rất có ý nghĩa, để tránh lãng phí thời gian và công sức cho các bác, để dành thời gian cho các việc mà vẫn đạt được hiệu quả cao nhất cho việc cưa gái, để các bác tiện vào tham khảo, cứ như là database vậy, vào chỉ cần oánh Ctrl+F tìm đánh xoẹt một cái là ra, thật là vô cùng dễ dàng và tiện lợi. Lại hay cu Nghĩa lăng xăng đến khi nào công trình hoàn thành có thể đưa thành PDF rồi bán kèm CD Linux làm phụ bản tra lấy tiền làm donor cho VnOSS thì có còn mừng nào quá mừng này nữa chăng?

(...)

Edited: Để viết cuốn cẩm nang này, tôi xin được tỏ lòng biết ơn tới cố Hải đăng Anh Vũ, Người đã khai thông nguồn trí tuệ cho tôi trong những ngày đầu tiên non nớt.

GEEK NERD INTERNET VÀ NHỮNG LỢI THẾ CỦA CHÚNG TA

"Biết người biết ta, trăm trận trăm thắng", đó là các cụ chúng ta đã dạy thế. Xông vào trận mạc mà không biết ta có gì mạnh thì rõ ràng đã cầm chắc phần thua trong tay. Vậy nên cẩm nang này sẽ được dùng để trình bày các lợi thế của chúng ta mà không phải xxx con trai nào cũng có được, chúng ta phải học thuộc từng điều để khi xông vào chiến trường thật mà ta cứ giở những ngón võ ấy ra, thì bảo làm sao mà gái không đổ ngang đổ ngửa cho được?

Vốn đã là gái, thì thường là chúng thích những kẻ hào nhoáng đẹp trai và giỏi văn thơ để chép tặng gái vào những dịp trọng đại như valentine trong những chiếc bao thư thơm thơm, nhưng bản thân gái không có một nền tảng lý luận vững chắc để có thể đứng vững trước quá nhiều cám dỗ mà cuộc sống và quan hệ của gái đem lại - nên thoạt nhìn thì việc chúng ta không hào nhoáng là một bất lợi, mà nhìn kỹ suy đi tính lại giờ lâu thì đâu chắc ta đã kém vì chúng ta đều có những phẩm chất vô cùng quý giá mà chắc chắn những tay hào nhoáng, những tay con nhà giàu, những tay nhà thơ nhà văn không thể có được. Mà gái, thì là nổi tiếng nhiều thời gian để đắn đo suy nghĩ trong lúc đi thẩm mĩ viện để bắn cái mụn con con, trong lúc chờ keo móng tay khô, trong lúc tỉa tót mái tóc, trong lúc trang điểm hàng ngày vân vân và vân vân... Chúng sẽ có rất nhiều thời gian để suy tính xem chọn ai chọn ai có thể làm chúng tin tưởng yêu thương, càng tính gái sẽ càng thấy chúng ta có lợi.

Điều đầu tiên, là chúng ta rất thẳng thắn và chính xác. Chúng ta ra lệnh cho cái máy, cứ đánh đúng password là sẽ được login, cứ 1+1 nhất định phải ra 10. Theo phép liên tưởng mà gái có được, chúng sẽ nghĩ chúng ta phục vụ gái cũng như máy tính đã phục vụ chúng ta. Chúng sẽ nghĩ: Chúng ta nói chúng ta sẽ gọi điện cho gái vào 9 giờ, thì đúng 9 giờ chúng ta gọi điện. Chứ còn những kẻ kia, chúng làm gì có giờ giấc ổn định, giờ cao su là chuyện như cơm bữa. Chúng ta từ khi tiếp xúc với máy tính đã quen với những ứng dụng đòi hỏi độ đáp ứng đến mức realtime, chính xác đến từng nanosecond như những đồng hồ nguyên tử ở nist.gov thì thiết tưởng, cái chuyện chính xác tới một phút đối với gái (đối với đa số gái đây là khoảng thời gian ngắn nhất mà chúng có thể ước lượng) rõ ràng không phải là việc quá khó - khác nào đã điều khiển một hệ thống solaris hàng ngàn server load-balancing bây giờ phải cấu hình một chiếc PC con con, thật là không còn gì dễ dàng bằng.

Nhân đây tôi cũng xin được đề đạt với các anh em hay làm khuya, là nên bớt chút thời gian làm việc cho điều độ, ngủ sớm dậy sớm ấy mới chính là con người OSS chân chính, chứ cứ giờ giấc lung tung chỉ thể hiện tính amateur rất chi là nông nghiệp cổ hủ.


Không chỉ thế, chúng ta còn ăn điểm ở chỗ chúng ta luôn được việc. Chúng ta không chỉ được việc trong những việc máy tính những chuyện phần mềm phần cứng sẽ giảm chi phí đáng kể cho gái để chúng và chúng ta có được một ngân sách khá lớn để làm nọ làm kia, mà thậm chí bạn của gái, bạn của bạn của gái... cũng sẽ rất cần chúng ta. Những kiểu quan hệ tầng tầng lớp lớp ấy, nhìn thoáng có vẻ không ảnh hưởng nhiều, mà nếu nhìn kỹ thì nó chẳng mạnh mẽ kém gì những mối quan hệ referal mà bọn kinh doanh trên Internet vẫn làm. Gái mỗi lần đi với bạn chỉ cần chúng có một câu khen chúng ta, thì cứ tưởng tượng mà xem chúng sẽ sung sướng tự hào như thế nào, "được lời như cởi tấm lòng" thật không còn gì diễn tả chính xác hơn. Cũng nên lưu ý chúng sẽ không tự hào về chúng ta, mà chúng sẽ tự hào về việc chúng đã thông minh trong việc lựa chọn bạn trai như thế nào - công việc đòi hỏi rất nhiều năng lực xử lý và phân tích lưu trữ trong chúng.

Với lại, đa số dân geek, nerd đều không chỉ biết riêng máy tính mà chúng ta còn khéo le'o trong vô vàn việc khác dính đến điện, nào là cái giắc này cắm vào ổ thế nào, nào là cái quạt tại sao kêu to, nào là cái đèn tại sao lại không sáng, thậm chí đến những cái tối tân mà gái không bao giờ nghĩ là hiểu được, như cái đồng hồ chạy chậm, như cái máy nghe nhạc tại sao lại không hay, cái máy ảnh kỹ thuật số tại sao lại chụp ảnh nhỏ tý đen xì... Thật ra chỉ cần một bàn tay ma thuật thay cái cụ pin con con, chỉnh cái equalizer cho nó tăng hết bass và tăng hết treble, hay vặn cái máy ảnh số cho nó chuyển thành chế độ chụp tự động, là xong béng tất.

Gái bây giờ thấy bạn bè chúng đứa nào cũng material vật chất thực dụng y như bọn Mỹ tham lam, thì hẳn cũng không khỏi xao xuyến mà nảy lòng sân si, kiếm một chân vừa làm bạn lại vừa có thể giúp những cái việc ma thuật như thế khi cần. Và xin đảm bảo với tất cả mọi người đang đọc bài này của tôi, tôi dám chắc chúng sẽ đủ thông minh để nhận ra rằng, chúng ta chính là sự lựa chọn tốt hơn bọn chụp ảnh, bọn làm thơ và tất cả những bọn làm bàn giấy, những bọn đi phiên dịch và những bọn đi vẽ nhà khác.


Lại một chuyện khác, đối với đa số gái hiện nay, nhất là gái mà chúng ta đã ướm, thì net và chat không phải là cái gì đó quá ma thuật nữa.

Một chuyện khác, đối với đa số gái hiện nay, nhất là gái mà chúng ta đã ướm, thì net và chat không phải là cái gì đó quá ma thuật nữa.
Lại thấy, bây giờ có lắm đứa bạn dùng Yahoo 360 gì đó thì ắt hẳn là gái sẽ sinh lòng ghen. Ghen quá đi chứ lị! Nó có blog, nó có album ảnh trời ơi là tức. Đoán xem gái sẽ muốn có gì: gái muốn nào là trang web có trái tim rơi xuống này, nào là những lời lẽ ngọt ngào vì sao chỉ có gái mới là người yêu duy nhất của chúng ta này, nào là những bức ảnh xinh xinh một thời xa xưa lắm gái đã từng có này... Nhưng đã là gái, thì CPU hạn chế là một điều cố hữu: Gái đâu có thể tự làm được việc đó! Thật ra có những trường hợp đặc biệt, nhưng mà đó là thiểu số, có cộng trừ nhân chia khai căn luỹ thừa kiểu gì cũng chỉ đếm trên đầu ngón tay. Việc upload video, ảnh nhạc và vô vàn thứ hầm bà lằng khác, việc có một trang web làm theo ý gái toàn những thứ gái thích, thì hẳn là món quà không còn gì tuyệt vời hơn đối với chúng.

Hoa thì đẹp đấy nhưng lại không bền lâu, hơn nữa hoa giống nhau là chuyện thường. Còn đã là trang web của một chuyên gia bảo mật, hay xoàng ra cũng là một webmaster chuyên nghiệp, thì có mà mưa nắng bão bùng sấm chớp DDOS muôn vàn sóng gió cũng chẳng sập, mà lại chỉ riêng mình gái có. Với lại hoa thì chỉ mình gái ngắm, còn trang web thì gái có thể dùng để khoe được... cứ làm website cho gái sẽ biết, gái sẽ tìm cách phát tán nhanh hơn bất cứ một tay spammer thực thụ nào, bằng cách tận dụng các nguồn lực sẵn có là mồm (cái này khỏi phải nói), và tay chúng có thể làm hàng trăm động tác copy paste gửi IM mà không biết mệt cùng với các phương tiện như SMS và thông tin đại chúng kiểu shoutbox hoặc là set status trên Yahoo messenger (đối với những bạn chỉ dùng irc thì tôi có thể định nghĩa ngắn gọn Yahoo Messenger là chỗ mà những tay amateur trong lãnh vực IT, những đứa vô công rồi nghề và gái cùng nhau vào chat chit không ngừng nghỉ bất kể thời gian nào). Tại sao gái có thể làm hàng trăm hàng ngàn động tác lặp lại mà không biết chán? Đó là bởi vì nguồn gốc xa xưa của con người khi gái luôn phải ở nhà để đan lát và dệt vải, công việc vốn đòi hỏi một sự kiên nhẫn vô bờ bến.

Tóm lại, biết sâu hiểu sâu về web, đó lại là một lợi thế rất độc đáo của dân IT chúng ta.


..................................
Nhân viết đến đây tôi nhớ đến bài hát Миллион алых роз (Million of Scarlet Roses - Triệu đóa hồng đỏ thắm) mà trước kia gái nào cũng thích, cảm ơn nhà thơ, nhạc sỹ Андре́й Андре́евич Вознесе́нский (Andrey Andreyevich Voznesensky) và ca sỹ А́лла Бори́совна Пугачёва (Alla Borisovna Pugachyova) đã giúp cho tôi tưởng tượng ra một thời của quá khứ đầy oanh liệt của những tay ca sỹ, những tay cầu thủ và những tay lái xe,... Một quá khứ của thế kỷ 20. Gái bây giờ thích Million Dollars Homepage hơn. Hay ít ra là cái gì tương tự thế, gần gũi như là trường hợp của Phạm Quỳnh Anh nổi tiếng với đoạn flash "Bonjour Vietnam" mà một chàng nerd Mỹ gốc Việt đã làm cho cô để nâng tầm ca khúc lên đến đỉnh cao của tình yêu! Thế mới là hào hoa chứ.

Tạm biệt hoa hồng, xin chào blog...................................

Xin bác Hacao bỏ chút thời gian quý báu theo dõi tiếp cuốn cẩm nang này sẽ thấy may mắn không đóng một vai trò gì hết, nhân định thắng thiên thôi bác ạ. May mắn = Chuẩn bị + Cơ hội. Cơ hội thì chúng ta không thể kiểm soát, và có thể bất ngờ chứ may mắn thì không phải là cái gì bất ngờ đâu!

................................................

Trong số các quy luật tự nhiên, thì có một quy luật mà bất cứ một tay học hay không học vật lý nào cũng biết là thứ ngược hẳn với nhau luôn tiến lại gần nhau. Thế cho nên mới có chuyện nam châm cực nam thì hút cực bắc, gái chân chính đoan trang thì hẹn hò với giai anh hùng hào kiệt. Cũng chính vì quy luật ấy, mà gái sinh ra đã có mặc cảm là năng lực xử lý của chúng, tức là CPU đã yếu lại còn chậm -- thì xu hướng của chúng chắc chắn sẽ là kiếm những kẻ có chút đầu óc để bù đặp phần thiếu thốn đó của chúng.

Nếu như việc yêu quý Linux hay là TeX hoặc Ruby (on rails) như daothanhngoc không bao giờ kiếm được điểm với gái (điều này tôi sẽ giải thích về sau trong cuốn cẩm nang này) thì đầu óc lại là chuyện khác. Gái hay bạn của gái, hay thậm chí nhạc phụ nhạc mẫu tương lai của ta luôn luôn coi trọng trí tuệ của chúng ta. Xin nhớ rõ, trong bất kỳ hoàn cảnh nào thời đại nào thì thông minh luôn là một trong những yếu tố ít ỏi để gái lựa chọn giai, vì gái thường có những bí kíp truyền khẩu được bảo tồn hết đời này qua đời khác để chúng lựa chọn giai sao cho đơn giản và dễ dàng nhất vì như đã nói ở trên năng lực xử lý và lưu trữ của chúng có hạn, vì thế nếu ta tỏ ra nổi trội ở những điểm gái sẽ cân nhắc ấy, thì có nghĩa là phần thắng đã ở trong tay chúng ta.

Chúng ta cũng có thể vận dụng một cách linh hoạt và sáng tạo sự thông minh của chúng ta trong nhiều trường hợp để kiếm điểm với gái. Ví như các dịp Valentine, sinh nhật gái, chúng ta nghĩ mãi mà không thể làm được một bài thơ? Không vấn đề gì, bởi vì bọn rỗi hơi tay bắt chuồn chuồn chân đá ống bơ luôn thừa thời gian sáng tác đủ mọi loại thơ buồn có vui có mà vừa buồn vừa vui cũng có và post đầy lên khắp các forum trong nam ngoài bắc.

Chúng ta lại có câu nói rất nổi tiếng của các vị tiền bối, là kim chỉ nam của những vị đạt giải cao của cuộc thi Trâu Thịt Vịt Ngan "Không nên phát minh lại cái bánh xe", hay nói cách khác, "Hãy google và biến cái của người khác thành của mình". Đôi khi thì không nên khắt khe quá, các giấy phép bản quyền (cc) và GNU/BSD gì đó cứ tạm dẹp sang một bên, hãy làm tất cả vì con em chúng ta - cái bọn làm thơ chúng cứ tương đại cái Copyright copyleft này nọ nhưng thực ra chúng có hiểu thế nào là (c) với (r) với (cc) các kiểu đâu, với lại chúng ta đâu có mang thơ của chúng ta đi dự thi ẵm giải đâu, cứ chôm thoải mái! Hãy học hỏi Kòm tiên sinh bên TNXM.net, người đã có sáng kiến là Google những đoạn thơ đó rồi cải biên chút ít thành của mình, và đừng để lại dấu vết.

Gái có đầu óc một chút sẽ tìm cách google ngược lại những gì chúng ta đã viết cho chúng, và nếu chúng tìm ra thì thật là ê mặt lắm thay! Cơ mà chúng ta lại biết, gái hơi có đầu óc biết google thì lại không có trình độ cảm thơ, mà gái biết cảm thơ thì lại không biết google, lúc ấy chỉ cần vận dụng sáng tạo vào trong từng hoàn cảnh cụ thể, thì ắt là nắm lấy phần thắng trong tay.
Đối với gái không biết google, thì ta có thể thay tất cả các từ Em bằng từ Lê, Đào, Mận, Táo gì đó, rồi mông má cho phù hợp. Công việc này mất có lẽ chẳng đến một phút đối với những người sành sỏi Perl thậm chí có thể viết được cả một script chuyên môn thay như thế.
Đối với những gái biết Google, thì đối phó với chúng cũng đơn giản không kém, sau khi thay tên đổi họ như trên rồi, ta chỉ việc chép ngược bài thơ lại đảm bảo đọc lên vẫn lâm li tình cảm mà lại không thể google được. Nhân tiện đây cũng mách nước với những bạn đang có gái yêu nhạc Trịnh, hay là thơ Nguyễn Thế Hoàng Linh, là công ty Tinh Vân có sáng tạo ra được một công cụ vô cùng tuyệt vời, đó là script perl có tên Em tập làm thơ, rất hữu dụng cho chúng ta, nhờ công nghệ tân tiến máy có thể làm những bài thơ không đầu không đít dài hàng chục trang mà đảm bảo đọc lên vẫn như đi vào chốn u mê rừng thẳm. Hẳn mang những cái bài thơ ấy chép tay (lưu ý là chép tay, mặc dù tôi nghĩ công việc đó khá ngu ngốc và đau khổ) tặng gái, bỏ vào trong những phong bao thơm phưng phức, thì thử hỏi dù ta có không biết làm thơ, thì cũng có gái nào mà chịu cho được, để mà không mê chúng ta như điếu đổ? Thấy chưa, dù có không biết làm thơ, nhưng sau khi đọc cuốn cẩm nang này thì chắc là ai trong số chúng ta cũng có thể tự hào mà nói rằng "Thơ ư? - Chuyện nhỏ!"

Lại tiếp tục nói về chuyện đầu óc, ta cũng nên có một số chuẩn bị phù hợp. Ngoài các công cụ google Google, Em tập làm thơ Tinh Vân mà tôi đã đề cập ở phần trước, tôi xin lưu ý ba công cụ khác cũng không kém phần mạnh mẽ không thể thiếu để chứng tỏ trí tuệ của ta với gái và tuyệt đối không thể để cho chúng biết là Bách khoa toàn thư của wikipedia.org, Babelfish của Altavista, và Calendar của Google. Nói chung các công cụ này hoạt động hiệu quả hơn khi mà chúng không biết chúng ta đang làm cái gì, ví dụ như chat với chúng chẳng hạn.

Như mọi người đã biết, Wikipedia là nguồn tri thức vô tận của nhân loại. Mà gái thì thường rất ngạc nhiên và nể phục những kẻ có đầu óc. Vấn đề đặt ra là, trong quá trình quan hệ với gái, khi chúng ta đã hiểu biết được đến những tầm triết học về nhân sinh, về vũ trụ, về nguyên tử và về những supercomputer, thì gái chỉ mới đi những bước chập chững để khám phá thế giới mới mẻ quanh mình, chính vì thế mà đôi khi chúng đôi khi sẽ có những câu hỏi đặc biệt ngớ ngẩn từ gái, ví dụ như "Lỗ rốn con gà nằm ở đâu?" hoặc "The Sims chơi như thế nào?". Đến lúc phải đối mặt với những thứ quái vật như thế, chúng ta cũng phải chấp nhận một thực tế rằng không phải cái gì ta cũng biết, cái gì ta cũng trả lời cho được - đặc biệt với những câu hỏi dở hơi trì độn đến mức như vậy. Nếu tự đi google hoặc vào các forum hỏi thì sẽ mất rất nhiều thời gian cả tìm kiếm và chờ đợi, vì thế tôi thường đặt một cái scriptlet trên trình duyệt Firefox của mình như sau:

Mã:

javascript:var s=prompt('Lookup what?');document.location.href=' http://en.wikipedia.org/wiki/'+s;

Một dòng mã thật là trí tuệ! Chúng ta chỉ việc click vào đó và nhập từ thế là tất cả hiểu biết của nhân loại đã nằm trong lòng bàn tay. Ví dụ như chúng ta nhập The_Sims thì tất cả các thông tin về The Sims sẽ hiện ra trong vòng 1 giây - có cái để trả lời ngay cho gái chả khác gì 1080! Và thế là gái sẽ xuýt xoa về tài uyên bác của chúng ta, cứ như là bộ từ điển bách khoa toàn thư vậy. Để tiện đường theo dõi, cái đoạn tôi viết trước kia về bài "Million scarlet roses" thực ra là tôi đâu có biết chút Nga văn hay là đọc văn học Nga gì đâu, nhìn tất cả những thứ xuất quỷ nhập thần như vậy cũng chỉ là do wikipedia mà nên. Mà gái nhìn thấy những thứ ngoại ngữ lằng nhằng, tuy rằng chúng không hiểu nhưng chúng sẽ thấy người mà chúng chọn thật là tài cao uyên bác, đến tiếng Hoa tiếng Tàu tiếng Nhật tiếng Nga đều biết thì hẳn là không thể không kìm được lòng mình mà phải nói lên tiếng yêu thương. (...)

Chính vì sự hiểu biết toàn diện của chúng ta khiến cho gái vô cùng nể phục, nên đôi khi chúng ta cũng tự đẩy chúng ta vào những hoàn cảnh tréo ngoe mà nếu là những kẻ dịch thuật, những kẻ nghiên cứu thông thường sẽ phải thúc thủ. Cứ thử tưởng tượng, trong những lúc buôn chuyện gái sẽ kể với bạn mình rằng anh ấy biết vi tính này, anh ấy biết Võ lâm truyền kỳ này, anh ấy biết cả tiếng Esperanto, anh ấy biết cả cổ ngữ Ai Cập - mà thực ra những thứ ấy tuyền là những thứ chúng ta copy paste từ Wikipedia về. Thế thì một ngày nào đó gái sẽ paste thẳng vào mặt ta một đoạn tiếng Pháp, tiếng Ý, hoặc tiếng Trung giản lược nhờ chúng ta dịch hộ bạn bè của chúng ở công ty nọ công ty kia để tham khảo việc nọ việc kia. Tình hình đúng là ngàn cân treo sợi tóc, nhận là không biết chả bằng là tự đeo thòng lọng vào cổ rồi ư?

Đừng lo! Giờ đây đã có Babelfish! Chỉ cần gõ: http://babelfish.altavista.com và xác định lờ mờ xem cái ngôn ngữ của cái đoạn văn bản đó là gì, ấn và chờ chỉ trong tích tắc là bạn đã có một văn bản tiếng Anh tương ứng! Đến lúc ấy, thì cứ gọi là tha hồ mà bốc đến tận giời gái cũng nghe, vì gái đã được một phen giúp bạn bè, điều mà chúng lấy làm vinh dự vô cùng vì chúng tưởng đã thay đổi được quan niệm của toàn xã hội về chúng, về những kẻ chỉ biết khư khư có mỗi mình. Lại một phen vận dụng sáng tạo nữa, chúng ta cũng có thể dùng tiếng Anh để dịch ngược lại sang các thứ tiếng khác, ví dụ như tiếng Nhật hoặc tiếng Hàn để lấy làm status trong Yahoo Messenger MSN hoặc Google Talk (tôi nghĩ Yahoo Messenger là sự lựa chọn thích hợp nhất cho những bạn đang có ý định cưa cẩm, vì nó màu mè và khá dễ hiểu đối với gái) - Hẳn gái nhìn thấy những status tiếng nước ngoài như thế sẽ tự hỏi, có phải anh ấy đang nói với toàn thế giới là anh ấy đang yêu mình không? Mặc dù chúng ta đâu có cài bộ phông chữ Asian làm cho tất cả các ký tự đó đối với chúng ta chỉ là những ô vuông vô nghĩa.


Calendar của Google (vâng, lại Google) - cũng là một thứ vũ khí vô cùng sắc bén (...)

Calendar của Google (vâng, lại Google) - cũng là một thứ vũ khí vô cùng sắc bén. Gái một phần coi trọng chúng ta là vì chúng ta rất đúng hẹn mới cả chúng ta là một cái máy nhớ, nhưng liệu ta có chắc rằng ta nhớ được tất cả các ngày vĩ đại trong đời gái hay không khi mà càng ngày càng nhiều các thứ vấn vương trong đầu óc của ta?

"Chuyện hôm qua như dòng nước chảy về đông mãi xa ta không sao giữ được,
Hôm nay lại có bao chuyện ưu phiền làm rối cả lòng ta."

Lời cổ nhân dạy bao giờ cũng chí lý. Nhưng cổ nhân thì làm gì có google calendar, còn ta thì có. Nắm được cách dùng google calendar ấy là đã nắm được cả một nguồn tài nguyên vô cùng rộng lớn: Ta không chỉ nhớ được ngày ta hẹn với gái, sinh nhật gái, mà thậm chí nó còn nhắc cho ta nhớ ngày trước kia gái mọc răng, ngày gái được điểm 10 lần đầu tiên, hoặc vô số thứ hữu ích có thể chúc mừng làm cho lòng gái xao xuyến. Cũng có thể dùng Google Calendar để add các ngày âm quan trọng ví dụ như là ngày Tết nguyên Tiêu, ngày xá tội vong nhân,... để những ngày gần đấy lỡ mà có hẹn với gái, chúng ta sẽ hỏi gái kiểu em có biết 2 ngày nữa là ngày gì không - tất nhiên với đầu óc của chúng sẽ trả lời là không biết hoặc chỉ biết tên ngãy lễ đó, từ đó mà ta giải thích ngọn ngành truyền thống như chuyện ông Khuất Nguyên vì giận vua Tàu mà phải trầm mình tự tử thế nào hoặc ngày đàn quạ bắc cầu Ô Thước cho Ngưu Lang Chức Nữ ra sao cứ thế mà thủ thỉ nhỏ to thì ôi thôi có trái tim của gỗ đá cũng phải tan chảy, chứ nói gì đến trái tim gái đã long lay chòng chày lại bị điều khiển bởi một bộ não đa phần kém phát triển của chúng.

Nhưng để làm được việc này thì chúng ta nên cẩn thận vì vốn hiểu biết các truyền thống dân tộc phải nhiều và cũng phải tham khảo thêm nhiều sách biết mười nói một kẻo lại bị mang tiếng là con người ba hoa, cả khi bị vặn thì còn có cái để lái đi chứ cứ bi ba bi bô biết gì nói đấy thì lại hoá ra là tồ. Nguồn tài liệu thì có thể google nhưng có vẻ cũng không hiệu quả lắm, tốt nhất là nên mua sách càng dày càng tốt để đọc vừa là để biết thêm, lại vừa có thể làm cho gái kính nể vì chúng ta có thể đọc những quyển sách mà ngay cả việc sờ vào thôi cũng khiến chúng rùng mình kinh sợ. Tôi cũng xin mách một số feed các ngày lễ mà tôi có biết được, có thể dùng để add vào Google Calendar một cách dễ dàng:

Ngày lễ Việt Nam
http://www.google.com/calendar/ical/vie … /basic.ics

Lịch sử thế giới
http://www.audiolicious.com/webcal/pubc … istory.ics

Sự kiện thế giới
http://icalx.com/public/sschristense/iW … lender.ics

Ngày lễ bên Mỹ
http://www.google.com/calendar/ical/usa … /basic.ics

Không chỉ coi trọng bộ não, gái nào cũng sẽ thấy một đặc điểm khác rất chi tuyệt vời của những con người geeky chúng ta là chúng ta rất là dễ dãi trong khoản ăn uống. Trên thực tế, với một mẩu bánh mì và một cốc nước chúng ta có thể làm việc được cả buổi bên máy tính mà không hề kêu ca phàn nàn.

Bây giờ gái tuyền những dạng vụng đắng vụng cay cả đời cũng chỉ biết làm có mỗi món mì gói và trứng rán hơi tý là tớn lên đi ăn hàng, còn đâu những cô gái Hà thành thắt đáy lưng ong tần tảo chăm lo cho người yêu từng miếng cơm hớp nước như nhà văn Vũ Bằng đã từng miêu tả trong cuốn tuyệt phẩm "Mười hai thương nhớ"? Thế nên chúng rất sợ yêu phải những người quá sành khâu ăn uống. Mà đã là dân kỹ thuật, thì ai ngu dốt đến mức nào mà chả biết đối với chúng ta dù là chán như mì tôm mà nhanh thì cũng chiến được hết - miễn là đừng có phải chế biến ì xèo và cứ phải ngồi đúng cái bàn ăn để ăn. Gái cũng sẽ thừa biết điều đó và coi đây là một trong những yếu tố quan trọng để gái yêu ta, tin ta. Nắm được tâm lý này của gái, ta cũng nên tỏ ra dễ dãi trong khâu ăn uống cho gái thấy: món gì gái làm cũng khen ngon đi ăn đâu cũng thấy tuyệt vời, dù gái chê thì cũng đừng vì thế mà chê theo gái - chắc chắn sẽ mất điểm vì về nhà gái sẽ nghĩ, người đâu mà khó tính thế.


Đã là gái, thì đa phần chúng muốn cả đời cũng chỉ có một bạn tình thôi chứ thật ra không gái nào muốn nhiều bạn tình cả, tự nhiên nó thế. Gái yêu dân kỹ thuật chúng ta cũng được cái yên tâm. Như ban đầu giới thiệu, chúng ta không chỉ có riêng một niềm ham thích là gái thế nên chúng sẽ nghĩ có một gái bên cạnh thế đã là đủ đối với chúng ta. Tóm lại là chúng nghĩ chúng ta chung thuỷ. Nếu như bọn văn nghệ sỹ thay người yêu như thay áo vừa để thay đổi hương vị lại vừa để đánh bóng tên tuổi thì đối với chúng ta một hậu phương ổn định và vững chắc lại là yếu tố quyết định để làm nên nghiệp lớn. Với cả tôi cũng tin vào con mắt của các bác sau khi đọc xong cuốn cẩm nang này, nhất định là sẽ chọn được một người yêu hoàn hảo đã chọn là đinh đóng cột luôn không phải lăn tăn suy nghĩ gì. Tóm lại là ta tin gái, mà gái cũng tin ta - hai bên cùng tin tưởng chan chứa vào một định mệnh sắp đặt sẵn thời quá khứ trong trẻo thời hiện tại vững bền và thời tương lai hạnh phúc.

Ai mà thích nhạc cũ thì hẳn là biết bài Sad Movies. Tôi xin mạn phép để bản tiếng Anh và bản dịch tạm của tôi:

Sad Movies.

Sad Movies always make me cryyy.. Cryyy(Deep Voice)
Said he had to work so I went to the show alone
They turned down the lights and turned the projector on
And just as the news of the world started to begin
I saw my darling and my best friend walk in

So I was sitting where they didn't see
And so they sat right down infront of me
And when he kissed her lips I almost died
and in the middle of the color cartoon I started to cry

OOO.......
Sad movies always make my cry
OOO.......
Sad movies always make me cry

And so i got up and slowly walked on home
My momma saw the tears and asked what's wrong
And so to keep form telling her a lie
I just said sad movie always make me cry

OOO.......
Sad movies always make me cry
OOO.......
Sad movies always make me cry ryy......ryy.....!

Chuyển sang tiếng Việt là

Những cuốn phim buồn

Mỗi cuốn phim buồn... đều làm em khóc rất lâu.
Người ấy có chút vướng bận làm em đến rạp chiếu cô đơn.
Đèn đóm tắt hết đi, máy đã chiếu cuộn phim rồi.
Và đúng lúc khi câu chuyện mới bước qua được đôi lời
Thì em thấy anh cùng bạn em bước vào, kề sát vai.

Em đã nép vào đúng hàng ghế anh không hay,
Mà anh vì thế cứ ghế trên vô tư ngồi,
Khi nhìn thấy môi kề môi em đã muốn được chết luôn rồi,
Và tới lúc khi tình tiết đang sôi động em đã bật khóc giữa cuốn phim.

Uh... huh huh...
Mỗi cuốn phim buồn... đều làm em khóc rất lâu.

Uh... huh huh...
Mỗi cuốn phim buồn... đều làm em khóc rất lâu.

[...]

Câu chuyện thì chắc là sau khi đọc xong tình tiết mọi người đều hiểu, tức là đại khái gái kia đã yêu phải một tay con giai nào đấy, đại loại là quá tin vào tay tình nhân làm cho cậu này thịt luôn cô bạn thân lúc nào không biết. Gái dù là tinh ranh ma mãnh đến đâu cũng rất sợ bị lừa như thế, chúng có thể tỏ ra là cứng rắn ngổ ngáo thì cũng ẩn chứa bên trong một tâm hồn cực kỳ mong manh dễ vỡ. Quay trở lại chuyện geek chúng ta, thì liệu gái có nghĩ về chúng ta là dạng bắt cá hai tay như thế không? Xin được thưa rằng đó lại là một mặt mạnh khác. Chúng ta bảo với gái chúng ta xin lỗi không đến là chúng ta đang miệt mài bên computer để thảo chương ra những phần mềm mạnh mẽ nhất để giúp đời, giúp người - gái luôn biết điều đó. Nhân tiện cũng nhắc luôn những gái nào lỡ đọc bài này của tôi, nếu lỡ yêu tay geek nào mà nó không thể đến được buổi hẹn thì đừng mất thời gian hờn dỗi vu vơ, hãy đến bên người yêu của mình mà đắp lên người chàng một manh áo mỏng và tắt điện phòng chàng đi vì chắc chắn chàng đang kiệt sức mà ngủ gục bên chiếc máy PC và bảng mạch điều khiển đang hàn dở của mình.

Trung thực thật là một đức tính vô cùng đáng mến của dân kỹ thuật chúng ta vậy.

Chính vì tâm hồn mỏng manh dễ vỡ của tâm hồn gái mà gái luôn cần có bạn bè, nói chung lối sống bầy đàn vẫn còn là một phương pháp đấu tranh sinh tồn mà rất nhiều gái đang có. Chúng không thể chịu nổi cuộc sống cô đơn, và vì không có chính kiến rõ ràng nên chúng chỉ dám dựa vào những kiểu ca dao tục ngữ của các cụ từ đời nảo đời nào để đánh giá con người ta, ví dụ như là "Gần mực thì đen, gần đèn thì rạng". Thế lại là một cái may mắn nữa cho chúng ta. Bởi bạn bè chúng ta cũng thường sống trong những môi trường thiếu tình cảm và thừa máy móc, nên có gái, thì dù có mà xấu ma chê quỷ hờn đến dâu đi chăng nữa thì gái ít nhiều cũng mang đến một làn gió mới đối với đời sống tinh thần của anh em, và không ai lại tiếc cái gì với gái của bạn. Điều này là không thể có được trong những môi trường khác ví dụ như môi trường bàn giấy, môi trường sư phạm và đa phần tất cả các môi trường khác khi mà lượng gái xúc rác đổ đi không hết - gái sẽ dễ bị trêu chọc dễ bị coi rẻ - điều mà chả đứa nào trong số chúng muốn cả. Bạn bè như thế, thì liệu thử hỏi là có thể còn gái nào, dù chậm hiểu như gái cũng phải nhận ra rằng, dân IT chúng ta thực sự có những người bạn tốt nhất mà không ngành nào sánh được.

Tuy là không nên kỳ vọng nhiều vào khả năng của gái, nhưng chúng ta cũng không nên coi tất cả lũ gái là trì độn, thế là cá mè một lứa, thế là Ста́лин (Stalin, Xít-ta-lin) chủ nghĩa, thế là phân biệt giới tính không thể nào mà chấp nhận được. Tuy rằng gái không biết điều đó, nhưng mà chính những lúc gái làm cho chúng ta bất ngờ thì người hạnh phúc không phải là ta khi nhận ra "Ô, hoá ra là gái ta cũng giỏi phết nhỉ?" mà chính là gái, chúng nhận ra là hoá ra chúng cũng thật sự là đỉnh cao trí tuệ, là ngôi sao sáng trên bầu trời. Chúng ta mạnh cả ở chỗ, lúc nào chúng ta khen là lúc ấy gái giỏi thật, chứ không phải là lời khen xã giao chiếm cảm tình một cách ngu ngốc. Ví dụ như, khi chúng ta nói 1+1=10, gái mặt vẫn tỉnh bơ, thế là gái giỏi, phỏng ạ? Khi đó thì nên khen. Hay như ta nói DnD - gái biết điều mà không Buzz ta, không call ta, thì hôm sau ta nên bù đắp bằng một cái gì đó cho gái. Chứ như cái ngữ bọn ca sỹ, thì cứ phải nói hết đất thì chúng nhận xét được những thứ bề nổi, kiểu "cái áo em mua ở đâu rẻ thế, em thật khéo chọn" sẽ không thể nào vừa tai được những gái có chút đầu óc. Nói chung, ta nên tận dụng một phần trí thông minh của ta để nhận ra những điểm thông minh của gái có thế thì gái mới vừa yêu mến vừa kính phục ta được.

Gái thì sến, gái cũng nhiều lúc thích sến, nhưng không phải cái dạng sến chảy nước kiểu ít học đại loại như cách nói "Em nèo mà cái mẹt sinh vật! Thick vật!". Hoặc ít ra, tôi tin rằng anh em chúng ta không đến nối phải say như điếu đổ một loại gái thích những thứ vớ va vớ vẩn thế. Đấy cũng là một lợi thế khác, gái có học sẽ rất thích những người có thể cắt nghĩa cho chúng những câu thành ngữ tục ngữ, những từ nguyên lắt lé,o nhất. Vì đã là geek thì đa phần chúng ta tôn trọng ngôn ngữ và hầu như không bao giờ sai chính tả. Chúng ta hiểu "chè" khác chè như thế nào. Nên gái làm bạn với ta, cũng chẳng phải lo chuyện đi nhậu nhẹt đàn đúm - đó cũng là một nền tảng cho cuộc sống hoà hợp, tương lai tươi sáng hiện ra trong đầu chúng.

Điều cuối cùng tôi muốn gửi gắm đến với những người đang đọc cuốn cẩm nang này của tôi, đó là mặt mạnh nhất mà gái nhận ra ở con người chúng ta, và chúng ta phải bằng mọi giá chứng minh chân lý này: Chúng ta thực sự yêu gái.

Nếu như ở trên đã nói, gái ngu gái xấu gái vụng không biết làm món ăn gì gái là sinh vật sống bầy đàn, thì cũng phải nhận định rằng ta cũng đâu có biết nhiều thứ. Thế giới đâu phải có dễ người dám chia sẻ với ta tình yêu đâu có phải ai cũng chấp nhận "trái tim anh chia làm ba phần tươi đỏ, anh dành cho Đản,g phần nhiều, phần cho nix và phần để em yêu". Gái cũng như bao loài sinh vật khác, đâu có muốn chia sẻ tình yêu với người khác. Với dân ngoài ngành, gái chỉ là gái. Với dân geek, gái không chỉ đóng vai trò là gái, đôi khi gái còn phải đóng nhiều vai như bảo mẫu, như chị gái và lắm khi còn là vệ sỹ. Thế nên, dành bao nhiêu thời gian cho gái, là nghệ thuật từng người đều phải học chứ đâu có phải đọc vài post là hiểu được. Và làm sao cho gái hiểu, bạn yêu gái sao thì cũng là một bí kíp mà không ai giống ai vậy.

Xin lỗi gái, tôi biết gái đọc mấy dòng trên này thì nhiều bạn sẽ dị ứng nổi mề đay khắp người đêm không ngủ được, nhưng nếu bạn đã chấp nhận là bạn của một tay sâu máy tính, thì cuộc sống của bạn sẽ không được đơn giản lắm đâu. Bạn sẽ phải mọc trăm tay ngàn mắt để ngăn cản những sự cố vô cùng kỳ khôi và quái đản, ví dụ như... điện giật, mắt mờ, người này ngủ người kia thức, hay hàng ngàn hàng vạn lý do khác mà bạn không thể chịu nổi.

Đó là chuyện thường tình thôi!

Như tình yêu vậy.