Trở lại…


2009, một năm đầy thất vọng. Tôi đã chứng kiến cảnh những người âm thầm cất bước ra đi, những lời la lối khi không thể chịu đựng, những sự bất công,…Nhưng nơi nào không thế nhỉ? Và trong lúc khó khăn ấy, có mấy người sếp nhận ra, mình đã mất đi một tài năng?



Trong lúc khó khăn ấy, cũng tình cờ tôi được chọn đi học, đó cũng là lúc có thể tránh đi một mớ bòng bong đang tồn tại. Và cũng vì tôi là một người mê học. 9 tháng trôi qua, cũng là sau đúng một năm khủng hoảng. Tôi trở lại với cty, với code, và dĩ nhiên không thể thiếu blog. Tôi sẽ không viết khô khan, không phải toàn code và kỹ thuật. Tôi sẽ viết nhiều, rất nhiều những vấn đề mà một dev có thể sẽ gặp phải. Chờ tôi, và đừng quên ủng hộ nhé.

Đọc tiếp >>

Cao Trong Hien

Xử lý Exceptions


Chương trình nào cũng có lỗi, khác nhau ở chổ ít hay nhiều. Để viết một chương trình có ít lỗi nhất đến cho người dùng là điều mà các LTV luôn mong muốn. Bài viết này cung cấp một số thông tin về Exception. Exception là gì? Tại sao ta lại cần quan tâm? Làm thế nào khi bạn lần đầu tiên đối mặt với java exception?

1. Giới thiệu


Một điều mà các LTV cần nắm được đó là: Lỗi xuất hiện trong chương trình.
Chúng ta cần biết điều này. Nhưng cái gì sẽ xảy ra tiếp theo khi lỗi xuất hiện. Nó sẽ được điều hướng như thế nào? Ai quản lý việc này? Và chương trình sẽ được khôi phục, hay sẽ bị ngưng?

2. Tại sao ta cần quan tâm?


Từ Exception là chữ viết tắt của cụm từ "exceptional event." Và được định nghĩa như sau:
Một exception là một event xảy ra trong quá trình thực thi của một chương trình khi quá trình thực hiện không theo đúng luồng đã được xây dựng.
Có nhiều loại lỗi có thể là lí do của Exception – bao gồm từ lỗi của phần cứng, như hỏng ổ cứng, đến những lỗi do lập trình, như là truy cập đến một phần tử ngoài giới hạn đã khai báo. Khi một lỗi xảy ra trong một phương thức trong Java, nó sẽ tạo ra một đối tượng Exception và chuyển đến “runtime system”. Đối tượng Exception này mang thông tin về lỗi bao gồm kiểu và trạng thái của chương trình khi sảy ra lỗi. Runtime system chịu trách nhiệm tìm kiếm đoạn code để xử lý cho lỗi này. Trong Java, tạo một đối tượng Exception và điều hướng nó đến runtime system gọi là “throw exception”.
Những đối tượng xử lý exception(gọi là exception handler) là danh sách các phương thức đã thực hiện trước khi có lỗi. Runtime system tìm đến nơi gọi, bắt đầu với phương thức nơi gặp lỗi, cho đến nơi mà nó tìm thấy một nơi xử lý cho exception. Một exception handler thích hợp khi kiểu của exception tung ta cùng kiểu với kiểu của exception trong exception handler. Quá trình lựa chọn exception handler gọi là “catch exception”.
Nếu runtime system không thể tìm thấy nơi xử lý exception trong tất cả các phương thức, thì runtime system sẽ hủy thực thi.
Bằng cách xử dụng exceptions để quản lý lỗi, ngôn ngữ Java cung cấp một chiến lược quản lý lỗi rất tốt.

3. Lợi thế của Java


Lợi thế 1: Tách riêng phần code điều khiển lỗi


Theo truyền thống, việc tìm ra lỗi, báo cáo lỗi, điều khiển code khi có lỗi đểu gom lại một nơi define trong code. Ví dụ, giả sử bạn có một chức năng đọc một file lưu vào trong memory. Viết theo mã giả, code của bạn sẽ thế này:

readFile {
open the file;
determine its size;
allocate that much memory;
read the file into memory;
close the file;
}

Ta nhận thấy một số lỗi tiềm ẩn sau:
• File sẽ có thể không mở được?
• Không xác định được chiều dài của file?
• Không đủ memory để lưu trữ?
• File không thể đọc được?
• File không thể đóng được?
Để thực hiện được các việc này, thì trong chức năng readFile, bạn cần thêm một số code để thực hiện công việc khi có lỗi, và điều hướng. Có thể nhìn thấy như sau:


errorCodeType readFile {
initialize errorCode = 0;
open the file;
if (theFileIsOpen) {
determine the length of the file;
if (gotTheFileLength) {
allocate that much memory;
if (gotEnoughMemory) {
read the file into memory;
if (readFailed) {
errorCode = -1;
}
} else {
errorCode = -2;
}
} else {
errorCode = -3;
}
close the file;
if (theFileDidntClose && errorCode == 0) {
errorCode = -4;
} else {
errorCode = errorCode and -4;
}
} else {
errorCode = -5;
}
return errorCode;
}

Với code xử lý lỗi, từ 7 dòng trở thành 29 dòng code – tỷ lệ là 400 %. Tệ hơn, trong đó có nhiều dòng chỉ để tìm ra lỗi, báo lỗi, trong 7 dòng code chính, làm cho ta khó đọc code, và vì vậy việc chỉnh sửa sau này sẽ rất khó khăn. Một vấn đề khác nữa là: Có chắc rằng file đã được đóng nếu memory không đủ để lưu file?
Exceptions cho phép bạn viết luồng chính của code, và ứng xử với lỗi trong một đoạn xử lý khác.
Do đó, code của bạn sẽ thế này:


readFile {
try {
open the file;
determine its size;
allocate that much memory;
read the file into memory;
close the file;
} catch (fileOpenFailed) {
doSomething;
} catch (sizeDeterminationFailed) {
doSomething;
} catch (memoryAllocationFailed) {
doSomething;
} catch (readFailed) {
doSomething;
} catch (fileCloseFailed) {
doSomething;
}
}

Lưu ý là exceptions không giúp bạn tìm ra lỗi, đưa ra thông tin lỗi, và xử lý lỗi. Những gì exceptions làm cho bạn là đưa ra một phương pháp để tách biệt tất cả các xử lý cho exception ra khỏi luồng chính của bạn.
Thêm nữa, nó còn làm cho tổng cộng code xử lý của bạn giảm đáng kế, chỉ còn 250% - so với 400% trong ví dụ trước.

Lợi thế 2: Tung lỗi chồng


Lợi thế thứ 2 của exception là khả năng truyền lỗi bằng phương pháp gọi chồng. Giả xử phương thức readFile là phương thức thứ 4 trong chuổi các phương thức trong luồng chính: phương thức 1 gọi phương thức 2, phương thức này lại gọi phương thức 3, và cuối cùng là gọi phương thức readFile.

method1 {
call method2;
} method2 {
call method3;
} method3 {
call readFile;
}

Giả xử rằng chỉ có method1 là quan tâm đến lỗi sảy ra trong readFile. Theo như cách truyền thống thì method2 và method3 chịu trách nhiệm truyền mã của error được trả về bởi readFile lên đến method1 – phương thức duy nhất quan tâm đến xử lý cho lổi này:

method1 {
errorCodeType error = call method2;
if (error)
doErrorProcessing;
else
proceed;
}

errorCodeType method2 {
errorCodeType error = call method3;
if (error)
return error;
else
proceed;
}
errorCodeType method3 {
errorCodeType error = call readFile;
if (error)
return error;
else
proceed;
}

Như đã biết ở trên, Java runtime sẽ tìm kiếm trong quá trình gọi, để tìm ra nơi xử lý cho lỗi nó bắt gặp. Một phương thức Java có thể tổng hợp xử lý nhiều exceptions được tung ra trong nó, theo cách đó, ta chỉ cần định nghĩa một phương thức để có thể xử lý cho các exception. Vì vậy chỉ phương thức có xử lý cho lỗi là ta quan tâm.

method1 {
try {
call method2;
} catch (exception) {
doErrorProcessing;
}
}
method2 throws exception {
call method3;
}
method3 throws exception {
call readFile;
}

Trong đoạn code giả trên, để nhúng một exception vào một phương thức trung gian thì ta cần chỉ nó ra trong phương thức đó. Do đó, khi định nghĩa một phương thức thì cần định nghĩa luôn những exeption có thể có xảy ra trong nó, họ sẽ có cách xử lý cho các exceptions này một cách tốt nhất.

Lợi thế 3: Gom nhóm và phân biệt lỗi


Thường thì exceptions đều thuộc về categories hay groups. Giả xử rằng ta có một group exceptions, mỗi một lỗi sẽ có một lý do khác nhau, lấy ví dụ như thao tác trên một array: khi giá trị truy xuất ra khỏi phạm vi của array, thành phần đã thêm vô array không đúng kiểu, hay thành phần tìm kiếm không thấy trong array. Cũng có thể gom nhóm to hơn bằng cách: chi làm 2 loại là Array exception, và một exceptions định sẵn cho trường hợp vượt ra ngoài phạm vi truy xuất.
Java exceptions phải là một hiện thực của Throwable hay Throwable. Cho các class khác, bạn có thể tạo một subclasses của Throwable. Mỗi "nhánh" class (một class không có subclasses) miêu tả một kiểu của exception và mỗi "nút" class (một class với một hoặc nhiều subclasses) miêu tả một group exceptions đã khai báo.
Ví dụ, trong diagram sau, ArrayException là subclass của Exception (một subclass của Throwable) và có 3 subclasses.

InvalidIndexException, ElementTypeException, và NoSuchElementException là các leaf classes. Mỗi class là một thể hiện của một lỗi có thể xuất hiện khi thao tác trên một array. Một cách để một phương thức có thể catch exceptions là chỉ catch những instances của một leaf class. Ví dụ, một exception handler điều khiển chỉ invalid index exceptions, phương thức đó sẽ như sau:


catch (InvalidIndexException e) {
. . .
}

ArrayException là một node class và thể hiện của các lỗi có thể xuất hiện khi tương tác với một array, bao gồm các errors đã được khai báo trong các subclasses của nó. Một phương thức có thể catch một exception trong một group hay cũng có thể catch nhiều exception con.
Ví dụ, để catch tất cả array exceptions mà không quan tâm đến kiểu được khai báo, một exception handler sẽ khai báo một ArrayException:


catch (ArrayException e) {
. . .
}


Đoạn handler trên sẽ catch tất cả array exceptions bao gồm InvalidIndexException, ElementTypeException, và NoSuchElementException. Bạn có thể tìm kiếm chính xác exception nào xuất hiện bằng cách tìm exception handler với tham số e. Bạn cũng có thể cài đặt một exception handler để handles tất cả exception với đoạn handler sau:


catch (Exception e) {
. . .
}

Exception handlers là quá chung chung, như ta thấy ở trên, bạn có thể làm cho code bạn hoàn toàn không có lỗi bằng cách catching và handling exceptions mà bạn không biết trước và không có một xử lý cụ thể cho exception. Tôi thì không khuyên dùng exception handlers như thế.
Như bạn đã thấy, bạn có thể tạo một groups exceptions và handle exceptions chung, hay có thể khai báo exception riêng rẽ.

Đọc tiếp >>

Cao Trong Hien

Happy new year 2009


Đã hơn 2 năm từ khi Hiendt's blog ra đời. Có những lúc tôi như muốn buông việc update cho blog, vì quá bận. Rất nhiều bạn đã động viên tôi, và cũng xin cảm ơn các bạn rất nhiều về điều đó.
Năm 2008 đã sắp qua đi, và ta cùng chào đón một năm mới. Tôi xin cầu chúc cho các bạn và gia đình luôn khỏe mạnh, và một năm mới thành công. Sau đây là một số thông tin thu thập của blog này.

Hiendt's blog - Top keyword



Hiendt's blog - Top pages view



Hiendt's blog - Top refering



Hiendt's blog - Top visitor



Đọc tiếp >>

Cao Trong Hien

,

Ca sĩ Phạm Quỳnh Anh: Bonjour Vietnam

Chúng ta đều biết đến ca sĩ người Bỉ gốc Việt này qua ca khúc “Bonjour Vietnam”. Nhân dịp cô ca sĩ rất Việt này về thăm quê, thân gởi đến các bạn một bài PV được sưu tầm trên blog của PQA.


Đọc tiếp >>

Cao Trong Hien

Tester xuất sắc, hắn là ai ?

Một người bạn gởi cho tôi. Tôi đã cố tìm kiếm nguồn chính xác trên internet, và có một số thông tin bên dưới, nhưng cũng chưa rỏ tác giả thực sự.

Tuy nhiên, nó sẽ đem đến cho bạn những kinh nghiệm khi test.

Nếu bạn hỏi tôi, tôi sẽ nói ả - một tester xuất sắc (đôi khi còn bị gọi là “Test dị nhân”) - là một người mà:

Lạng lách

Tester xuất sắc phải là tay chuyên “lạng lách”. “Lạng lách” là ở chỗ: ai cũng có thể làm theo danh sách dài dằng dặc những test cases có đầy rẫy trong các sách dạy testing, nhưng tester xuất sắc lại có thể đi xa hơn cả cái danh sách này, và với tới một seri bất tận những phương pháp xương xẩu để acttack một chương trình.
Tester xuất sắc thường được giới developers phán là “đáng ớn” và “chập cheng”!

Tò mò

Cái gì cũng có thể khiến một tester xuất sắc quan tâm. Mụ ta luôn muốn hiểu tại sao mọi thứ lại diễn ra theo cách mà nó đang diễn ra. Các bug tốt nhất (hay tệ nhất, tuỳ xem anh ở phe nào) là kết quả của sự tương tác giữa hai cái gì đó của phần mềm (ứng dụng, mô đun, component, hay bất cứ cái gì). Mụ biết rõ: việc hiểu cách mà cái gì đó hoạt động sẽ trực dẫn đến việc hiểu cách mà nó tương tác với một cái gì khác, và hiểu tương tác nào trực tiếp đưa đến bug. Mụ thường bộc lộ tính tò mò trong muôn mặt đời thường: thị trường hoạt động thế nào? Dàn giáo được xây dựng ra sao? Sao lại cho chất phụ gia vào bêtông? Bút chì màu được sản xuất thế nào? v.v.
Tính ham hiểu biết của một tester xuất sắc là không có giới hạn.

Phấn khích bởi bugs

Với một tester xuất sắc, bug là liều thuốc bổ. Mụ ló mặt vào bàn của developer, cười ngoác đến tận mang tai mà phô diễn cái lỗi kinh dị sắc bén nhất mới tìm ra. Mụ khoe khoang về bug của mình với các tester khác và háo hức đón nghe những thành tích chói lọi của đồng ... bọn :-)

Biết rằng luôn luôn còn lỗi

Một tester xuất sắc biết rõ: không có lúc nào mà một ứng dụng lại hoàn toàn không có lỗi. Mụ hiểu rằng một ứng dụng trông như không có lỗi lại chính là một ứng dụng đầy những lỗi chưa được tìm ra. Mụ luôn hăm hở tìm ra những kiểu bug mới. Mụ xem mỗi bug khách hàng tìm ra như một một dấu hiệu của một lớp bug mới mà mụ đã bỏ sót mất.
Vui duyên mới không quên nhiệm vụ (Stays on track)
Tester xuất sắc biết rằng phải làm việc tập trung mới có thể tìm ra và cô lập các bug để lần tới tận nguyên nhân gốc rễ. Mụ ta không bỏ qua những lỗi nhâm tiện tìm ra trên đường đi “truy sát” một bug nào đó, nhưng biết hoãn chỉ tay day mặt chúng cho tới khi cái bug hiện tại bị nắm chắc trong tay. (Và, dĩ nhiên là, sẽ háo hức nói lại với tay developer liên quan, rồi khoe khoang cả với các ả test khác)

Khoanh vùng thoả đáng (Scopes appropriately)

Tester xuất sắc hiểu rõ là không thể có đủ thời gian để thực hiện hết mọi test case muốn thực hiện. Mụ bèn phân mức ưu tiên và khoanh vùng việc test sao cho đảm bảo rằng những lỗi dễ ảnh hưởng tới khách hàng nhất sẽ được tìm ra trước tiên.

Bắt nhầm còn hơn bỏ sót (Investigates weird behavior)

Tester xuất sắc chủ động theo dõi những sự kiện lạ. Các icons không xuất hiện đúng vị trí? Các radio buttons không nằm cùng cụm? Đó chỉ là những lỗi lập trình rất đỗi phổ thông! Nhưng với tester xuất sắc thì: những sự lạ như vậy, tuy có thể xảy ra, nhưng mà là dấu hiệu của một loạt lỗi cẩu thả, không dung thứ được. Với mụ, không phải “Đời lúc nào chả lắm sự bất thường” mà “Á chà, tình hình lại ra nông nỗi này đây!”. Phải chặn ngay!

Tả lỗi chính xác

Tester xuất sắc cặm cụi chăm chỉ để mô tả một cách sáng sủa nhất, ít thao tác nhất cái tiến trình sinh ra một bug. Mụ test đi test lại để xem thực sự thì cái bug đó là gì. Lời mụ tả lỗi chỉ ra rành mạch và chính xác: đâu là sự thật đã được kiểm chứng và đâu là phần ước đoán của tester.

Đồng cảm với khách hàng

Tester xuất sắc khắc cốt ghi tâm cái sứ mệnh làm tầng rào chắn cuối cùng để bảo vệ khách hàng khỏi một sản phẩm không đáp ứng được nhu cầu. Tester xuất sắc hiểu mọi lĩnh vực của khách hàng. Hiểu khách hàng cần làm gì và hiểu khách hàng muốn sử dụng sản phẩm theo cách nào. Tester xuất sắc vượt lên trên cả nhu cầu của khách hàng để nhìn thấy khả năng một sản phẩm có thể cải tiến hoạt động của khách hàng ra sao. Tester xuất sắc truyền bá quan điểm của khách hàng qua suốt vòng đời của sản phẩm, từ vision ban đầu đến pha phân tích yêu cầu, xây dựng chức năng, thay đổi chức năng, chữa lỗi rồi phát hành sản phẩm và đi vào bảo trì. Tester xuất sắc giúp nhóm phát triển sản phẩm hiểu khách hàng như chính họ.

Ưu tiên đại cục

Tester xuất sắc thực sự thân thuộc với mọi chi tiết của mỗi tính năng. Và cũng hiểu mỗi tính năng phù hợp hay ảnh hưởng đến toàn bộ sản phẩm như thế nào? Tester xuất sắc sẵn sàng thay đổi hoặc thậm chí cắt bỏ một số tính năng để làm cho sản phẩm tốt hơn về tổng thể.

Bỏ con săn sắt bắt con cá rô (Picks their fights)

Tester xuất sắc thừa nhận rằng: fix tất cả các lỗi thường là việc quá tốn kém, so với các nguồn lực phải bỏ ra. Thế là mụ cân đo lỗi này so với lỗi khác, cho phép một số lỗi bị ỉm để các lỗi khác được fixed xong.

Giữ vững lập trường (Stands their ground)

Tester xuất sắc biết rõ đâu là những lỗi buộc phải fixed. Mụ sẵn sàng trở nên ngoan cố, bướng bỉnh, xù lông nhím khi cần thiết để đảm bảo rằng một lỗi cần fixed phải được fixed thực sự. Mụ bình tĩnh chỉ ra tại sao lỗi đó phải được fixed và thuyết phục đội phát triển rằng thực tình lỗi đó không thể để lờ đi.

Có thể hỏi developer rằng nhà vệ sinh ở đâu

Những người khách ngoại quốc thường được khuyên làm quen với ngôn ngữ và phong tục của người bản xứ, tới mức đủ để có thể gọi xe về khách sạn, hỏi đường tới nhà vệ sinh, và biết rằng hành động bắt tay ở nước sở tại là lịch thiệp hay bất nhã. Cũng như vậy, tester xuất sắc quen thuộc với ngôn ngữ và tập quán của developer. Tester xuất sắc biết UML đủ nhiều để hiểu được các biểu đồ, để vẽ một class hay vẽ một một biểu đồ tuần tự mà không khiến developer cười sằng sặc. Một tester xuất sắc cũng có thể viết code với trình độ ít nhất là bằng sinh viên năm thứ nhất. Và hiểu các thuật ngữ trong thiết kế ở mức đủ tốt để tham dự được các buổi thảo luận và review thiết kế (chứ không phải xin phép rời phòng họp).

Biết rằng tính khả test (testability) chỉ là một trong nhiều ràng buộc

Tester xuất sắc biết rõ cách duy nhất để thực sự test được một ứng dụng là đưa tính khả test vào mọi khía cạnh của sản phẩm. Mụ phân tích tính năng, thiết kế, kiến trúc phần mềm, và phát triển hàng loạt các ý tưởng để đảm bảo rằng sản phẩm có thể test. Tuy nhiên, mụ cũng biết tính khả test không phải là yếu tố duy nhất ảnh hưởng tới kiến trúc, thiết kế và tính năng. Mụ cân bằng tính khả test với các yếu tố khác và giúp đội phát triển tạo ra giải pháp dung hoà tốt nhất.

Biết khi nào cần sự hỗ trợ

Tester xuất sắc thích thử thách, thích húc đầu vào tường và từ từ đâm thủng nó. Tất nhiên, có một số bức tường dày hơn hẳn những bức khác, và đôi lúc cái lỗ thủng thử thách của nó khiến tester liên tục thất bại. Đó là lúc tester xuất sắc nhận ra cần có sự giúp đỡ và mạnh dạn đề nghị được giúp đỡ. Một tester xuất sắc biết chọn ai để nhờ giúp đỡ, và hiểu rõ không có gì phải xấu hổ khi kêu cầu sự giúp đỡ.

Dành thời gian học tập

Tester xuất sắc biết rõ cách duy nhất để tiếp tục trở thành một tester xuất sắc là không bao giờ ngừng học. Không giới hạn sự học của mình trong ngành test, mụ còn mày mò nghiên cứu về lập trình, về quản lý dự án, về marketing, và về bất cứ thứ gì khác, miễn là có mối quan hệ xa gần tới qui trình sản xuất phần mềm.

Không bao giờ dừng test

Tester xuất sắc vượt quá cả biên giới của những tính năng hiện có để liên tục test sản phẩm được giao. Test cả các sản phẩm khác. Test cả sách, cả tủ lạnh, cả đèn điện, cả cửa ra vào ..., test bất cứ thứ gì trong bất cứ lĩnh vực nào của cuộc sống, rồi phán “Thế là không đúng rồi!”

Đọc tiếp >>

Cao Trong Hien

Unit Testing: 12 lời khuyên khi dùng


Unit Testing là một trong các thành phần chính của Agile Software Development. Được giới thiệu đầu tiên bởi Kent Beck, unit testing đã trở thành một thành phần không thể thiếu trong các hệ thống của các tổ chứ lớn nhỏ. Unit tests giúp các kỹ sư giảm thiểu số lỗi, thời gian để debugging, góp phần làm tăng sự ổn định, bền vững.
Trong bài viết này, chúng tôi sẽ tìm hiểu các bước để các LTV dùng unit testing trong các hệ thống phần mềm, không liên quan đến ngôn ngữ lập trình hay môi trường phát triển.

1. Unit Test quản lý rủi ro của bạn


Với một newbie, có lẽ sẽ hỏi Tại sao tôi phải viết test? Suy nghĩ Unit test là một việc làm tẻ nhạt, những kỹ sư phần mềm muốn outsource để tránh nó đi. Đó là tâm lý mà không còn chỗ trong công nghệ phần mềm hiện đại. Mục đích của những nhóm phần mềm là sản xuất phần mềm có chất lượng cao nhất.
Khách hàng và những nhà doanh nghiệp luôn than phiền về những lỗi của các phần mềm trong những năm 80 và 90. Nhưng với sự phong phú của các thư viện, dịch vụ web và các môi trường phát triển cung cấp các tính năng như refactoring và unit testing, sẽ không cònn chỗ đứng cho phần mềm có sai sót.
Ý tưởng đằng sau của Unit Test là tạo ra một tập hợp những lớp test cho mỗi thành phần của phần mềm. Unit Test tạo điều kiện thuận lợi cho việc test phần mềm liên tục, không giống những tài liệu về test, sẽ ít tốn kém khi thực hiện chúng nhiều lần.
Unit test sẽ lớn lên theo hệ thống. Mỗi test là một hợp đồng bảo hiểm mà hệ thống làm việc. Việc dùng một tập hợp unit test, những kỹ sư có thể giảm bớt đáng kể số lượng lỗi và nguy cơ với code chưa được test.

2. Viết Test Case trên thành phần cơ bản


Khi bạn bắt đầu sử dụng unit testing, luôn luôn phải hỏi Test là cái gì mà tôi phải viết?
Có một suy nghĩ sai là viết cụm của các hàm test dùng để thăm dò chức năng nào đó trong hệ thống. Bạn phải suy nghĩ rằng: cần tạo một test case (tập hợp các test) cho mỗi thành phần cơ bản nhất.
Tiêu điểm của test là một thành phần tại một thời điểm. Bên trong mỗi thành phần, tìm kiếm một thành phần có thể tương tác – bao gồm các thuộc tính được truy xuất ra bên ngoài. Bạn cần phải viết ít nhất một test trên mỗi phương thức public.

3. Tạo Abstract Test Case và Test Utilities


Với bất kỳ đoạn code nào, ở đây sẽ có những thứ chung mà tất cả các test của bạn cần làm. Bắt đầu với việc tìm thấy unit testing cho ngôn ngữ của bạn. Ví dụ trong java, những kỹ sư dùng Junit - một framework đơn giản nhưng mạnh để viết test trong java. Framework có lớp TestCase, lớp căn bản cho tất cả các test. Thêm vào những phương thức tiện ích thích hợp với môi trường của bạn. Tất cả các trường hợp test đều có thể chia sẽ tài nguyên chung này.

4. Viết những lớp test khôn khéo


Test thì cần nhiều thời gian, vì thế cần đảm bảo là test của bạn hiệu quả. Một lớp test tốt sẽ thăm dò ứng sử chính của mỗi thành phần, nhưng làm việc đó với code ít nhất có thể. Ví dụ, bạn chẳng cần viết test cho phương thức getter và setter trong Java Bean, nhưng nó sẽ vẫn được test thông qua các test khác cần thiết hơn.
Thay vào đó, viết test tập trung vào các ứng xử của hệ thống. Bạn không cần viết một cách hoàn thiện, hãy tạo những test có ý nghĩa bây giờ, rồi để thêm về sau nữa.

5. Thiết lập môi trường trong sạch cho mỗi test


Người ta luôn quan tâm đến hiệu quả. Vì vậy khi nghe rằng test cần thiết lập môi trường riêng rẽ, họ thường lo lắng về cách thực hiện. Tuy thế thiết lập mỗi test chính xác và từ đầu là quan trọng. Đảm bảo rằng mỗi test được thiết lập đúng mức và không lo lắng về hiệu quả.
Trong trường hợp khi bạn có môi trường chung cho tất cả các test - không cần thay đổi khi chạy – bạn có thể thêm static vào lớp test căn bản của bạn

6. Dùng Mock object để test có hiệu quả


Thiết lập test thì ko đơn giản, và cái nhìn đầu tiên thỉnh thoảng dường như không thể đạt được. Ví dụ, nếu sử dụng Amazon Web Services trong code của bạn, bạn có thể mô phỏng nó như thế nào trong lớp test mà không có sự tác động hệ thống thật sự.
Có một số ít cách. Bạn có thể tạo ra dữ liệu giả và sử dụng nó trong những lớp test. Trong hệ thống mà có những người sử dụng, một tập hợp riêng biệt những tài khoản có thể được dùng riêng cho việc test, được gọi là những mẫu hay những Mock object.
Việc chạy test thường xuyên có thể ảnh hưởng đến hệ thống: nếu điều gì đó trục trặc và bạn xoá dữ liệu người dùng thực tế, giải pháp là dùng dữ liệu giả
Một đối tượng giả thi hành interface đặc biệt, nhưng trả về kết quả đựơc xác định trứơc. Ví dụ, bạn có thể tạo ra đối tượng giả cho Amazon S3 mà luôn luôn đọc đựơc file từ đĩa local của bạn. Đối tượng giả có ích khi test hệ thống phức tạp với nhiều thành phần. Trong Java, có vài framework giúp tạo những đối tượng giả, đáng chú ý là JMock

7. Refactor test khi bạn refactor code


Việc test chỉ đựơc trả tiền nếu bạn thật sự đầu tư vào nó. Không chỉ bạn cần viết test, bạn cũng cần đảm bảo chúng được cập nhật. Khi thêm một phương pháp mới vào một thành phần, bạn cần thêm một hoặc nhiều test tương ứng. Bạn phải làm sạch những code không dùng bên ngoài , đồng thời loại bỏ những test không còn thích hợp nữa.
Unit test đặc biệt có ích khi làm refactoring trên diện rộng. Refactoring tập trung vào việc duy trì tính ổn định của code để giúp nó giữ ở trạng thái đúng. Sau khi bạn chỉnh sửa test, chạy lại các test có liên quan để đảm bảo bạn không làm hỏng bất cứ thứ gì khi thay đổi hệ thống.

8. Viết test trước khi sửa lỗi


Unit test là vũ khí hiệu quả trong sự đấu tranh chống lại những sai sót. Khi bạn sơ hở một vấn đề trong code của bạn, viết test trình bày vấn đề này trước khi chỉnh code. Theo cách này, nếu lỗi lại xuất hiện, nó sẽ bị bắt bởi test.
Điều này là quan trọng vì bạn không thể luôn luôn viết test đúng hoàn toàn. Khi bạn thêm test một sai sót, thì bạn đang lấp đầy lỗ hỏng trong test của chính bạn.

9. Unit Tests đảm bảo tính thực thi


Chẳng nhửng đảm bảo tính chính xác của code, unit tests còn chắc rằng thự thi của code không có suy biến, giúp cải thiện tốc độ thực thi của hệ thống.
Để viết một performance tests, bạn cần implement chức năng start và stop trong test class. Khi thích hợp, bạn có thể dùng một phương thức bất kỳ có liên quan đến thời gian hay code ước lượng thời gian chạy.

10. Test tính đồng thời


Code đồng thời rất khó khăn và là điển hình của source có nhiều lỗi. Đó cũng là lý do mà test này là rất quan trọng. Cách để làm là sử dụng sleep và locks. Bạn có thể viết trong sleep gọi test của bạn nếu bạn cần đợi một trạng thái đặc biệt của hệ thống. Trong khi đây không là giải pháp đúng 100%, chỉ đúng trong một số trường hợp. Để mô phỏng sự đồng thời trong một kịch bản phức tạp hơn, bạn cần lock thành công các đối tượng mà bạn đang test. Vì vậy bạn chỉ có thể mô phỏng hệ thống đồng thời nhưng tuần tự.

11. Chạy Test liên tục


Điểm cần chú ý của test là chạy chúng liên tục, đặc biệt là trong những team lớn, có nhiều người phát triển trên một code căn bản. Bạn có thể thiết lập test để chạy sau vài giờ một lần, hay bạn có thể chạy chúng trên mỗi lần check-in code, hay mỗi ngày (có thể là hằng đêm). Hãy quyết định phưong thức thích hợp nhất cho dự án của bạn và làm những test chạy tự động và liên tục.

12. Vui với Test!


Quan trọng là bạn vui với nó. Lần đầu tiên tôi gặp unit testing, tôi luôn nghi ngờ và nghĩ nó là công việc phụ. Nhưng tôi đã thay đổi cách nghĩ, vì một người rất thông minh mà tôi luôn tin cậy nói với tôi rằng nó rất hữu ích.
Unit testing đặt trí tuệ của bạn vào trong trạng thái mà nó rất khác với trạng thái code. Nó kích thích suy nghĩ của bạn về một việc đơn giản là làm sao tập hợp các test cần thiết cho thành phần này.

Nguồn: ReadWriteWeb

Đọc tiếp >>

Cao Trong Hien

Ý tưởng của Mocking

Đối với những người chưa từng dùng unit testing, ý tưởng của mock objects có thể gây khó hiểu. Tôi cũng có một bài viết về mock object, nhưng về cơ bản thì cũng khá lan man. Trong bài viết này, tôi sẽ nói về mục đích cơ bản của mocking. Mock object là gì? Nó dùng để làm gì? Vì sao ta không thể mock cho object XYZ? Trả lời những câu hỏi này sẽ lý giải một cách dể hiểu về mock objects.

Code không chỉ chứa bản thân


Khi học lập trình, các objects mà ta tạo ra chỉ chứa những gì là của nó. Thường thì các helloworld không có sự phụ thuộc vào bên ngoài (trừ System.out nhé). Tuy nhiên, trên thực tế, phần mềm là có lệ thuộc. Tôi viết một action classes phải phụ thuộc vào services, services phụ thuộc vào data access objects (DAOs) và những cái khác nữa.
Ý tưởng của unit testing là để test code ta viết mà không có phụ thuộc. Là một bước để chắc rằng code bạn viết đúng mà không tính đến các phụ thuộc. Giả thiết rằng code tôi viết là đúng như thiết kế và các phụ thuộc cũng vậy, vì vậy khi tích hợp sẽ làm việc tốt theo thiết kế. Lấy ví dụ một đoạn code sau:


import java.util.ArrayList;

public class Counter {
public Counter() {
}

public int count(ArrayList items) {
int results = 0;

for(Object curItem : items) {
results ++;
}

return results;
}
}

Là một ví dụ quá đơn giản, nhưng nó có thể minh họa cho điều này. Nếu bạn muốn test phương thức count, bạn sẽ viết một test để minh chứng cho phương thức count làm việc. Bạn sẽ không phải test ArrayList vì chúng ta đều thừa nhận rằng nó đã được test và làm việc đúng. Bạn chỉ cần test cách bạn dùng ArrayList.
Hãy nhìn vào một đoạn code phức tạp hơn một chút, nó là một đoạn của một ứng dụng trong thực tế:

public class MichaelsAction extends ActionSupport {

private LookupService service;

private String key;

public void setKey(String curKey) {
key = curKey;
}

public String getKey() {
return key;
}

public void setService(LookupService curService) {
service = curService;
}

public String doLookup() {

if(StringUtils.isBlank(key)) {
return FAILURE;
}

List results = service.lookupByKey(key);

if(results.size() > 0) {
return SUCCESS;
}

return FAILURE;
}
}

Nếu ta muốn test phương thức doLookup, ta chỉ cấn viết test cho nó mà không cần viết cho phương thức lookupByKey. Nhưng làm sao test doLookup mà không cần chạy lookupByKey?

Dùng Mock Objects


Mock objects dùng khi ta muốn tạo một object và đặt nó tại vị trí của object thực. Nó chắc chắn sẽ chứa phương thức sẽ được gọi với các tham số và cách ứng xử nhất định, nó sẽ trả về kết quả được mong chờ. Dùng đoạn code trên như một ví dụ, giả sử rằng khi tôi gọi và gởi khóa 1234 đến service.lookupByKey được gọi, tôi sẽ có một List được trả về với 4 giá trị. Khi đó, mock object của ta mong chờ rằng khi lookupByKey sẽ được gọi với tham số "1234", nó sẽ trả về một List với 4 objects trong đó.

Mock Objects làm việc thế nào?


Có nhiều mocking frameworks khác nhau trong Java. Tôi sẽ không nó cụ thể về chúng ở đây. Tuy nhiên, tôi sẽ nói về cách nó làm việc và ý tưởng thiết kế mà bạn cần quan tâm khi hiện thực nó.
Về cơ bản thì có hai kiểu của mock object frameworks, một được hiện thực thông qua proxy (bạn có thể hiểu nó như một class ủy nhiệm) và một qua class remapping (map phụ thuộc trực tiếp trong file .class ).
Ta xét cách đầu tiên và là cách được dùng nhiều trong thực tế, proxy.
Một proxy object là một object được dùng thay thế cho object thực. Trong trường hợp của mock objects, một proxy object được dùng để mô phỏng object thực mà code của bạn phụ thuộc vào. Tạo một proxy object với mocking framework, và tiêm nó vào trong object dùng setter. Đây là một điểm cần có trong mocking dùng proxy objects, bạn cần cho phép (public) set phụ thuộc. Nói cách khác, khi bạn tạo một sự phụ thuộc bằng cách gọi new MyObject() thì sẽ không còn chổ cho mocking với một proxy object. Đó cũng là lý do Dependency Injection frameworks như Spring ra đời. Nó cho phép tiêm proxy objects mà không cần phải thay đổi code.
Kiểu thứ hai của mocking là remap file class trong class loader. Tôi chỉ biết duy nhất có jmockit làm việt theo cách này. Nó khai thác một khái niệm mới (có trong JDK 1.5) và được cung cấp trong java.lang.Insturment. Nó sẽ tương tác trực tiếp với class loader để remap sự phụ thuộc đến class file mà nó sẽ load. Giả sử bạn có class MyDependency với tên tương ứng .class là MyDependency.class và tôi muốn viết một mock cho nó dùng MyMock để thay thế cho một object được khai báo sẳn. Bằng cách dùng mock objects, bạn sẽ trực tiếp remap trong classloader với phụ thuộc từ MyDependency đến MyMock.class. Sau đó, mock objects có thể được tạo bằng cách gọi new. Dù cho phương pháp này mạnh hơn là dùng proxy object, nhưng nó khó hiểu và có thê gây bối rối, bạn cần có một kiến thức tốt về classloaders nếu muốn dùng hết các tính năng trong nó.

Kết luận


Mock objects có một giá trị lớn trong testing. Cho bạn khả năng test những gì bạn viết mà không liên quan đến sự phụ thuộc.

Nguồn: http://www.michaelminella.com/testing/the-concept-of-mocking.html

Đọc tiếp >>

Cao Trong Hien

,

10 cách để làm việc tốt hơn với sếp


Bạn không thể sống với họ, nhưng càng không thể sống thiếu họ. Thích hay không, hầu hết chúng ta phải đối phó với một ông sếp, và cách chúng ta làm không chỉ ảnh hưởng đến tiến bộ sự nghiệp của chúng ta và cả lương mà còn tốt cho tinh thần. Sau đây là một số mẹo vặt để đối xử tốt hơn với sếp của bạn.

1. Hãy nhớ rằng: sếp là người hiểu biết


Bạn nghĩ rằng sếp không có khả năng đó? Hãy nhớ lời nói của Mark Twain, ông ta nói rằng khi 14 tuổi, cha của ông là người ngớ ngẩn đến nổi anh ấy không chụi nổi. Rồi anh ấy lớn lên, khi 21 tuổi, ông đã hết sức ngạc nhiên về những kiến thức mà ông ấy học được từ cha chỉ trong 7 năm. Hãy nghĩ rằng sếp của bạn thông minh hơn bạn nghĩ, và có thể đã từng ở vị trí của bạn, bạn sẽ đánh giá đúng sự việc. Dù không, một ông chủ xấu vẫn có thể đưa ra lời khuyên tốt.
Tôi nhớ những gì mà sếp đã nói với tôi vài năm trước. Ông ấy nói rằng tôi cần năng nổ hơn và làm bất cứ điều gì có ích hơn là nghỉ ngơi sau khi làm việc và chờ phân công việc mới.
Bạn vẫn có thể học từ ông sếp tệ. Phân tích tại sao ông tệ và quyết tâm tránh xa những điều đó nếu bạn muốn trở thành ông chủ tốt.

2. Nhận biết mục tiêu của sếp


Những người phát triển phần mềm thường quan tâm đến “mục đích”. Yêu cầu cả hệ thống phần mềm phải trực tiếp hoặc gián tiếp được dùng. Hay nói một cách khác là tìm ý nghĩa của từng đoạn code, để loại bỏ dư thừa.
Việc gì cũng vậy, cần cố gắng để nhìn thấy bức tranh to lớn hơn. Bạn cần biết cái gì sếp mong chờ ở bạn. Và cần biết rằng làm sao để công việc của bạn giúp ích cho sếp. Hãy chắc rằng những điều bạn đang làm không chỉ phù hợp với mô tả chi tiết công việc của bạn mà còn giúp đỡ sếp hoàn tất mục tiêu của ông ấy.

3. Cần biết những điều mà sếp mong chờ ở bạn


Khi tôi còn trẻ, có một lần tôi phàn nàn mẹ rằng: Con không có việc gì để làm hết mẹ à! “Calvin”, bà ấy trả lời, “Tại sao con không chơi piano đi?” Và đó là lần cuối cùng tôi phàn nàn với bà ấy về chủ đề đó.
Bạn có thể không biết những ước mơ của cha mẹ bạn là tốt đẹp khi bạn là đứa trẻ, nhưng không biết những mong đợi của sếp có thể sẽ phá hỏng sự nghiệp của bạn. Làm sao bạn có thể có thành tích tốt nếu bạn không biết mục tiêu của nó? Và nếu bạn biết mục tiêu, bạn có xác định chúng được ko?
Thỉnh thoảng, hãy kiểm tra với sếp về việc bạn đang làm? Khi bạn đã hoàn thành cái gì đó và chắc rằng sếp của bạn cũng nghĩ vậy. Nếu sếp bạn đã đánh giá về thành tích của bạn, đều đó sẽ tốt cho cả hai, vì vậy bạn có thời gian để sửa đổi khi sai hướng.
Trong thế giới của sự hoàn hảo, không bất ngờ nào có thể xảy ra trong suốt quá trình làm việc của bạn. Và nếu xảy ra, có thể là do sếp của bạn không truyền đạt tư tưởng, hay bạn thất bại trong việc tìm hiểu chúng. Đừng để điều đó xảy ra với bạn.

4. Chậm sửa đổi


Đừng trở thành một “nhân viêc có vấn đề”, có một người sếp luôn luôn phải kiểm tra và theo sau. Để thay thế, cố gắng là một người mà sếp có thể tin tưởng. Điều đó có thể không thấy rõ ràng ngay lập tức, nhưng người sếp tốt sẽ thừa nhận và đánh giá cao điều đó.
Bạn có đang hoàn tất hoàn thành công việc của bạn? Dĩ nhiên là ko? Bạn hầu như mắc sai lầm và tạo ra vấn đề ít nhất 1 lần. Tuy nhiên, khi điều đó xảy ra, bạn hãy đi gặp sếp của bạn. Cố gắng không báo cáo những vấn đề. Hãy nghĩ ra vài giải pháp và chuẩn bị đưa ra đề nghị về kế hoạch của bạn đến sếp.

5. Đừng làm sếp ngạc nhiên


Đừng để sếp nghe được một điều xấu về bạn. Nói cách khác, nếu bạn đã gây ra vấn đề hay mắc phải sai lầm. Tốt hơn hãy trực tiếp nói với sếp – không phải từ khách hàng, từ đống nghiệp và càng không phải từ chính sếp của sếp bạn. Bạn có phủ nhận sự ảnh hưởng đó không? Ngay sau đó, hãy gọi cho sếp của bạn và yêu cầu lời chỉ dẫn tường tận.

6. Bày tỏ lòng biết ơn với sếp về sự thành công của bạn


Khi khoảnh khắc đó đến: Bạn là đại diện cho nhóm của bạn, tiếp nhận khen thưởng hay thừa nhận khác từ sếp hay sếp của sếp bạn. Việc thích hợp để làm tại thời điểm này là biết ơn những người đã làm cho nó được như vậy, đặc biết là sếp bạn. Cho biết rằng điều đó thật dễ dàng khi sếp bạn sẵn sàng giúp đỡ. Dù sếp bạn không làm được gì, hãy cố gắng nói một điều gì đó, nhưng đồng thời bạn chắc chắn điều đó phải đúng sự thật.
Hãy nhớ những gì chúng ta đã thảo luận ở trên – thậm chí một ông sếp tồi có thể đưa ra những lời khuyên tốt. Sếp của bạn làm bạn chán nản hay làm một điều gì đó khó khăn? Có lẻ, trong trường hợp này, bạn có thể cảm ơn sếp đã giúp đỡ bạn “giữ cho mọi thứ triển vọng” hay để “kiểm tra sự minh mẩn” hay giúp đỡ bạn “nhìn thấy vấn đề từ nhiều điểm”.

7. Đừng chỉ trích bản thân


Hầu hết chúng ta quá phức tạp với công việc của mình, rằng nó cứng nhắc và khó tách rời bản thân ra khỏi nó. Vì vậy khi một người nào đó phê bình công việc của chúng ta. Chúng ta quan niệm sự phê bình như là sự công kích cá nhân. Cách phản ứng đó có thể gây cản trở sự phát triển của và sự tiến bộ của chúng ta.
Khi sếp của bạn (hay người khác) phê bình công việc của bạn, cố gắng giả vờ như công việc đó được làm bởi một người khác. Và rồi, khảo sát nghiên cứu nó như là một người thứ ba có thể và kiểm tra giá trị của lời phê phán đó.
Một ông chủ thông minh sẽ thấy rõ sự thành công của bạn ràng buộc đến sự thành công của sếp ông ấy. Bởi vậy, cho nên sếp có sự quan tâm trong viêc làm của bạn. Hơn nữa, lời phê bình từ sếp có thể là một dấu hiệu mà sếp có những mông đợi cao hơn từ bạn.
Khi tôi bắt đầu làm việc, tôi đã bị lật đỗ bởi vì sếp của tôi giao cho tôi nhiệm vụ mà tôi suy nghĩ là quá khó khăn. Tôi bàn luận sự quan tâm của tôi với bạn của cha tôi, người đã từng làm việc trong lĩnh vực giống như tôi đang làm. Tôi vẫn nhớ lời khuyên của người bạn đó. “Cavin” ông ấy nói rằng: “[tên của sếp] đã giao cho bạn nhiệm vụ đó bởi vì ông ấy nghĩ rằng bạn có thể làm công việc đó tốt”.

8. Hãy nhớ rằng sếp của bạn cũng có sếp.


Chúng ta đã thảo luận trước đó sư quan trọng của việc biết những mục tiêu của sếp bạn. Trong tĩnh mạch như vậy, ý thức được rằng sếp của bạn có một ông sếp nữa. Bạn có thể sử dụng thực tế kia để xây dựng mối quan hệ cộng tác với sếp của mình, việc có mối quan hệ cộng tác kia đưa cho sếp bạn có ấn tượng tốt hơn về bạn và cho bạn cái nhìn rõ ràng về sếp của sếp bạn.

9. Đừng chỉ trích sếp


Việc chuyển chỉ trích sếp bạn có thể giới hạn sự nghiệp của bạn. Bởi vậy, cẩn thận việc chỉ trích sếp của bạn ở nơi công cộng, như người đã làm với cha tôi. Trong khi ông ta đang làm cộng sự cho một nhóm biểu diễn. Ông ta đã nói đến Viện Bách Khoa Worcester. Nhưng lại phát âm nó như “Woo-ster”. Người đó đã nói: “Wellington, bạn đã sai”. Nó là “Woo-ches-ter.” Thật may mắn, cha tôi đã nhanh trí làm lệch lời bình luận với câu trả lời sau đây: “Tôi lấy làm tiếc, xin tha lỗi cho tôi. Tiếng anh chỉ là ngôn ngữ thứ năm của tôi”. Sự khôi hài của cha tôi đã hủy bỏ hoàn cảnh đó.

10. Quản lý sếp của bạn khi cần thiết


Vươn lên trong sự nghiệp bằng cách hãy làm nhiều hơn là ngồi lại và chờ đợi những mệnh lệnh. Bạn phải có sáng kiến, tìm kiếm những cơ hội để giải quyết các vấn đề. Tận dụng bất kỳ tổ chức nào mà sếp của bạn có mối quan hệ. Giải thích với sếp về những kế hoạch của bạn và tại sao chúng quyết định cho doanh nghiệp thành đạt.
Yêu cầu sếp đấu tranh với bất kỳ cuộc chiến quan liêu nào có ảnh hưởng đến bạn. Hãy biết rằng, sếp là sếp, và bạn đang định hướng sếp, người đang có lợi thế mà bạn không có.

Nguồn: http://blogs.techrepublic.com.com/10things/?p=284

Đọc tiếp >>

Cao Trong Hien

,

Ứng dụng HelloWorld Spring Portlet MVC Framework

Cách tốt nhất để học một framework mới là viết một ứng dụng HelloWorld dùng nó. Tôi xin bắt đầu theo cách này, viết một HelloWorld portlet dùng Spring Portlet MVC Framework. Để đơn giản, ứng dụng HelloWorld của tôi chỉ có mode View. Bất cứ khi nào người dùng truy cập đến HelloWorld portlet, chúng ta chỉ hiển thị trang View.jsp.


portlet.xml


Hãy bắt đầu với file portlet.xml trong webapp/WEB-INF/ như sau:


<?xml version="1.0" encoding="UTF-8"?>
<portlet-app
xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd
http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd" >
<portlet>
<description>HelloWorld Portlet using Spring MVC</description>
<portlet-name>HelloSpringPortletMVC</portlet-name>
<display-name>Hello World Spring Portlet MVC Framework Portlet</display-name>
<portlet-class> org.springframework.web.portlet.DispatcherPortlet
</portlet-class>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>VIEW</portlet-mode>
</supports>

<supported-locale>en</supported-locale>
<portlet-info>
<title>
Hello World Spring Portlet MVC Framework Portlet
</title>
<short-title>
HelloWorldSpringPortletMVC
</short-title>
<keywords>
spring portlet
</keywords>
</portlet-info>
</portlet>
</portlet-app>

DispatcherPortlet chịu trách nhiệm điều khiển request từ người dùng. Khi nhận được một request, nó sẽ tìm Controller chịu trách nhiệm xử lý cho request này, sau đó gọi handleActionRequest() hay handleRenderRequest() tùy thuộc vào kiểu sử lý của request. Controller class thi hành phần business logic và trả lại một View để trả kết quả xử lý cho người dùng.

Như đã thấy, DispatcherPortlet là trung tâm xử lý trong Spring Portlet MVC Framework. Ngoài ra, DispatcherPortlet còn chịu trách nhiệm loading application context (file cấu hình của Spring). Đầu tiên, kiểm tra giá trị của configLocation. Nếu không được khai báo, nó sẽ đặt giá trị mặc định là <portlet-name>-portlet.xml, và tìm trong thư mục /WEB-INF. Trong file portlet.xml, chúng ta không khai báo configLocation, vậy ta cần tạo file HelloWorldPortletMVC-portlet.xml.

HelloSpringPortletMVC-portlet.xml


Tạo file HelloSpringPortletMVC-portlet.xml trong webapp/WEB-INF như sau:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
\"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<bean id="viewController"
class="com.bds.example.springmvc.ViewController"></bean>
<bean id="portletModeHandlerMapping" class=
"org.springframework.web.portlet.handler.PortletModeHandlerMapping">
<property name="portletModeMap">
<map>
<entry key="view">
<ref bean="viewController"/>
</entry>
</map>
</property>
</bean>
</beans>

Đây là file cấu hình của portlet HelloSpringPortletMVC. Có 2 beans được định nghĩa:
  • viewController. Chỉ đến class com.bds.example.springmvc.ViewController.java.
    portletModeHandlerMapping. Như ta đã biết, khi DispatcherPortlet nhận được một request, nó sẽ tìm Controller thích hợp để điều khiển request đó. PortletModeHandlerMapping là nơi điều khiển view.

  • PortletModeHandlerMapping là một class đơn giản hiện thực từ interface HandlerMapping và được DispatcherPortlet dùng để tìm Controller thích hợp cho mọi request. Class PortletModeHandlerMapping dùng mode của Portlet để tìm Controller.


  • ViewController.java


    Ta biết rằng viewController bean sẽ xử lý tất cả View mode requests. Bước tiếp theo là tạo ViewController.java như sau:



    package com.bds.example.springmvc;

    import javax.portlet.RenderRequest;
    import javax.portlet.RenderResponse;
    import org.springframework.web.portlet.ModelAndView;
    import org.springframework.web.portlet.mvc.AbstractController;

    public class ViewController extends AbstractController{
    protected ModelAndView handleRenderRequestInternal(RenderRequest request,
    RenderResponse response) throws Exception {
    ModelAndView modelAndView = new ModelAndView("View");
    return modelAndView;
    }
    }


    Chú ý: Nếu bạn đã từng dùng Struts Framework, thì Controller class cũng giống như một Action class trong Struts.
    Mọi controller class trong Spring Portlet MVC Framework phải trực tiếp hoặc gián tiếp implement interface org.springframework.web. portlet.mvc.Controller. Để đơn giản hơn, Spring Framework cung cấp AbstractController, và một số extends phục vụ một số action cơ bản. Ta cũng có thể tự implement Controller class, nhưng phải quan tâm đến một số vấn đề như: reuse, thread-safe, và khả năng điều khiển nhiều requests trong suốt vòng đời của portlet.
    Trong code trên, tôi tạo ViewController class bằng cách extend từ AbstractController. Vì ta chỉ cần xử lý cho mode view, nên ta chỉ cần override phương thức handleRenderRequest() từ AbstractController. Với controller trên, HelloWorldPortletMVC sẽ chỉ render trang View.jsp đến người dùng khi người dùng truy cập đến portlet này.

    web.xml


    Theo Portlet Specification 1.0, mọi ứng dụng portlet sẽ theo chuẩn của Servlet Specification 2.3, và cần một file miêu tả cho deployment(web.xml). Tạo web.xml trong thư mục /WEB-INF/ như sau:

    <?xml version="1.0" encoding="UTF-8"?>
    <web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation=
    "http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
    <display-name>
    Hello Spring Portlet MVC Framework Application
    </display-name>
    <servlet>
    <servlet-name>ViewRendererServlet</servlet-name>
    <servlet-class>
    org.springframework.web.servlet.ViewRendererServlet
    </servlet-class>
    </servlet>
    <servlet-mapping>
    <servlet-name>ViewRendererServlet</servlet-name>
    <url-pattern>/WEB-INF/servlet/view</url-pattern>
    </servlet-mapping>
    <listener>
    <listener-class>
    org.springframework.web.context.ContextLoaderListener
    </listener-class>
    </listener>
    </web-app>

    File web.xml khai báo 2 việc:
  • ViewRendererServlet. ViewRendererServlet là một cầu nối thể hiện servlet cho portlet. Trong quá trình render, DispatcherPortlet đặt PortletRequest trong ServletRequest và chuyển điều khiển cho ViewRendererServlet để render. Bước này cho phép Spring Portlet MVC Framework dùng lại các thành phần View như trong phiên bản cho servlet, là Spring Web MVC Framework.

  • ContextLoaderListener. ContextLoaderListener chịu trách nhiệm phần load file cấu hình Web Application context tại thời điểm ứng dụng bắt đầu chạy. Web application context được chia sẻ cho tất cả các portlet trong cùng ứng dụng portlet. Trường hợp có 1 bean được định nghĩa 2 lần, bean được định nghĩa trong portlet application context được ưu tiên hơn trong Web application context.


  • ContextLoader đọc giá trị của contextConfigLocation. Nếu contextConfigLocation không được khai báo, sẽ dùng giá trị mặc định là /WEB-INF/applicationContext.xml.

    applicationContext.xml


    Như đã nói ở trên, nếu giá trị của contextConfigLocation không được khai báo, ViewRendererServlet sẽ lấy giá trị mặc định là /WEB-INF/applicationContext.xml file. Tạo applicationContext.xml có nội dung sau:


    <?xml version="1.0" encoding="UTF-8"?>

    <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
    "http://www.springframework.org/dtd/spring-beans.dtd">
    <beans>
    <bean id="viewResolver" class=
    "org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="viewClass">
    <value>
    org.springframework.web.servlet.view.JstlView
    </value>
    </property>
    <property name="prefix">
    <value>/WEB-INF/jsp/</value>
    </property>
    <property name="suffix">
    <value>.jsp</value>
    </property>
    </bean>
    </beans>

    Trong code trên, file applicationContext.xml định nghĩa 1 bean là viewResolver. viewResolver được dùng để khai báo nơi chứa các file JSP.
    Ta khai báo 2 giá trị cho viewResolver bean:
  • Prefix – thư mục chứ file jsp /WEB-INF/jsp/

  • Suffix – đuôi của file phải là JSP

  • Lấy một ví dụ, khi đối tượng ModelAndView trả về với giá trị là View thì file được view ra là /WEB-INF/jsp/View.jsp.
    Và cuối cùng, tạo một file View.jsp đơn giản với thông điệp "Hello from Spring Portlet MVC Framework" trong thư mục /WEB-INF/jsp.

    Đọc tiếp >>

    Cao Trong Hien

    ,

    Trung tâm Java dành cho thanh - thiếu niên


    Với tư duy “lập trình không chỉ dành cho những người đã trưởng thành”. Sun đã chính thức cho ra đờ trung tâm java dành cho lứa tuổi thanh - thiếu niên. Cung cấp những tools và websites có cách trình bày dễ hiểu và phù hợp.Sun muốn nói rằng, Java là một ngôn ngữ lập trình dễ dùng.


    Còn chần chừ gì mà không chọn java là ngôn ngữ lập trình đầu tiên cho đứa con yêu.Chi tiết

    Đọc tiếp >>

    Cao Trong Hien

    ,

    5 Laptops dành cho Developers


    Biết rõ ràng rằng sự lựa chọn của cho lập trình web chắc chắn là một máy desktop 1 hoặc 2 nhân, màn hình độ phân giải cao. Nhưng có thể vì một lý do gì đó mà bạn cần cho mình một chiếc laptop, tại sao không nhỉ? Trong trường hợp này, bạn sẽ phải tậu cho mình một chiếc laptop đúng với yêu cầu về card màn hình. Dĩ nhiên, màn hình cũng phải có độ phân giải thích hợp. Danh sách sau đây là một vài ví dụ về những chiếc laptops phù hợp với công việc này, nó sẽ đem lại hiệu quả cao nhất.

    Sony Vaio VGN-AR590E



    Sony sở trường trong việc sản xuất ra những chiếc laptops rất đẹp từ những chất liệu tốt, nhưng có giá khá cao. Cái này cũng không ngoại lệ, nhưng có hình dáng nhìn rất ấn tượng. To và khá nặng, nhưng không mấy ngạc nhiên vì nó có màn hình 17-inch với độ phân giải tự nhiên 1920×1200. Card đồ hoạ 8600M GPU của Nvidia thì không chê vào đâu được. Cho dù cần hay không, bạn cũng có một ổ Blu-Ray, góp phần không nhỏ vào cái giá của chiếc máy tính này. Tại Việt Nam, Vaio VGN-AR590E có giá bán $3.050.

    Asus M70SA



    Asus phần lớn được biết đến với nhãn hiệu Eee PC với những mini-notebooks, nhưng là công ty sản xuất máy tính đủ cỡ và hình dáng. M70SA có màn hình 17-inch (phân giải 1920×1200) là một thành viên trong dòng máy “personal entertainment center”. Với mọi mục đích, nó đều có thể đáp ứng với CPU 2.5GHz “Penryn” (45nm) Core 2 Duo CPU và card đồ hoạ HD3650 GPU của ATI với 1GB. Một điểm đáng chú ý nhất là có 2 ổ cứng dung lượng 500GB mang đến cho bạn một không gian lưu trữ khổng. Hiện không có thông tin về giá tại VN.

    Apple MacBook Pro



    MacBook Pro có giá cao hơn tất cả các dòng máy khác có cùng cấu hình phần cứng. Tuy nhiên, nó có một kiểu dáng hoàn hảo mà không hãng nào có, không nói đến HDH OS X Leopard mới và Multi Touch touchpad của Apple. Bạn có thể chọn màn hình 15-inch 1440×900 hay 17-inch 1920×1200. Các dòng sau này đều có CPU Intel Core 2 Duo CPUs, và bạn có thể chọn dùng Windows XP hay Vista trên Mac thông qua Apple Boot Camp. MacBook Pro hiện có 2 phiên bản: giá 2.166 USD cho bộ xử lý 1,67 GHz, RAM 512 MB và ổ cứng 80 GB; phiên bản hi-end hơn với giá 2.693 USD với bộ xử lý 1,83 GHz, RAM 1 GB và ổ cứng 100 GB.

    Toshiba Qosmio G45



    Toàn bộ thiết kế của dòng Toshiba Qosmio đều có tính thẩm mỹ cao. Ngoài ra, cân nặng của nó làm người ta ngại khi dùng nó khi mang đi xa. Với cấu hình CPU 2.4GHz Core 2 Duo của Intel, màn hình 17-inch 1920×1200 với card 8600M GPU từ Nvidia,3GB RAM. Ngạc hiên hơn là được trang bị ổ ghi HD-DVD, nhưng kiểu địnhh dạng này đã không còn được Toshiba hỗ trợ. Chưa thấy cửa hàng nào tại HCM bán, tại HN thì có giá khoảng $3.290.

    Dell Inspiron 1525



    Dell Inspiron là dòng thường được lựa chọn khi tình hình tài chính eo hẹp. Chỉ dưới $600, bạn đã có thể tậu được một con Core 2 Duo với màn hình 15-inch 1680×1050. Bạn có thể hài lòng với màu sắc của chiếc máy mình sở hữu, với rất nhiều tông mà DELL xây dựng sẵn. Nhưng với card đồ hoạ được tích hợp sẽ không làm bạn hài lòng, bạn cũng không thể nâng cấp. Được bán với giá khoảng $815 tại VN.

    Đọc tiếp >>

    Cao Trong Hien

    Portlet và Spring Portlet MVC

    Và khi portal ra đời. Không theo chuẩn xây dựng website đang có, nó có thể thấy nhiều ứng dụng chỉ trong một trang portal. Không những thế, portal còn phục vụ cho sở thích, quyền hạn của người dùng. Nghĩa là mỗi người dùng sẽ có một phiên bản khác, được thiết kế cho riêng họ.

    Lịch sử hình thành Portlet


    “Thinks outsite the box” – Hãy suy nghĩ ra khỏi giới hạn

    Mặc cho lời khuyên này, chúng ta vẫn thường xuyên “suy nghĩ trong giới hạn”. Hollywood Square, bưu điện, niên giám của các trường đại học, game sodoku là những thứ mà ta có thể thấy được về vấn đề “suy nghĩ trong giới hạn”. Vậy chúng ta mong chờ gì về việc này khi mà chúng ta thường xuyên đối diện với các giới hạn này?

    Việc suy nghĩ này ta gặp thường xuyên nhất là với các hệ điều hành như Microsoft Windows hay Mac OS. Hãy nhớ lại những ngày mới ra MS-DOS, ta chỉ có thể chạy một ứng dụng tại một thời điểm. Nhưng các thế hệ của nó sau này, không những có thể chạy nhiều ứng dụng một lúc, mà ta còn có thể nhìn thấy chúng cùng lúc.

    Một ứng dụng web cũng như một ứng dụng chạy trên MS-DOS, chỉ có thể tương tác trên một ứng dụng tại một thời điểm. Nếu muốn muốn dùng một ứng dụng web khác, bạn phải dừng ứng dụng này, và truy cập đến ứng dụng đó, trên một cửa sổ mới(hay tab mới).

    Và khi portal ra đời. Không theo chuẩn xây dựng website đang có, nó có thể thấy nhiều ứng dụng chỉ trong một trang portal. Không những thế, portal còn phục vụ cho sở thích, quyền hạn của người dùng. Nghĩa là mỗi người dùng sẽ có một phiên bản khác, được thiết kế cho riêng họ.

    Hình H.1 : Ví dụ điển hình cho portal là iGoogle.

    Đến khi Sun công bố Java Portlet Specification (JSR 168), là lúc bắt đầu một xu hướng xây dựng portlet. Đó là một tiêu chuẩn dể xây dựng, và phát triển portlet với java. Nói một cách ngắn gọn, nó định nghĩa các quy ước giữa những portlet, và cách nó tương tác với portal server.

    Trong bài viết này, chúng ta sẽ có một cái nhìn đầu tiên về Spring Portlet MVC, một công cụ giúp ta xây dựng ứng dụng dựa trên chuẩn của Java Portlet API.

    Mặc dù Spring Portlet MVC là một thành phần riêng biệt với Spring MVC, nhưng chúng chia sẽ những tính năng tương tự nhau. Thực tế, khi làm việc với nó, bạn sẽ thấy rằng chúng có một sự tương đồng, và Spring Portlet MVC còn dùng lại một số class trong Spring MVC. Vì vậy, sẽ rất dễ dàng nếu như bạn có một kiến thức nhất định về Spring MVC.

    Bạn cần một kiến thức cơ bản về Java Portlet Specification và biết cách xây dựng một portlet đơn giản. Nếu bạn mới đến với Java Portlet , hay đơn giản là chỉ muốn tìm một cái gì mới, tôi nghĩ bạn nên đọc quyển Portlets and Apache Portals (Manning, 2005) hay Building Portals with the Java Portlet API (Apress, 2004).

    Suy nghĩ trong giới hạn


    Có nhiều điểm tương đồng giữa Portlet và Servlet. Ta có thể thấy ngay như sau:
    Một Servlet được viết bằng cách implements javax.servlet.Servlet hay thông dụng hơn là extends từ javax.servlet.http.HttpServlet. Tương tự, một portlet cũng được viết bằng cách implement javax.portlet.Portlet hay extends từ javax.portlet.GenericPortlet.
    Khi implement từ javax.servlet.Servlet , phương thức cần implement là service(). Khi implements từ javax.portlet.Portlet , có 2 phương thức cần implement là processAction() , và render().
    Nếu bạn chọn mở rộng từ javax.servlet.http.HttpServlet , bạn cần implement doGet(), doPost(), doPut(), hay doDelete() để xử lý request. Với javax.portlet.GenericPortlet bạn cần implement doView(), doEdit(), hay doHelp() để xử lý portlet request.

    Và cũng có nhiều điểm khác nhau :
    Servlet có đầu ra là một trang web, và chiếm hết diện tích của trình duyệt. Portlet thì ngược lại, nó phải chia sẽ trang với các portlet khác.
    Một portlet có thể có nhiều modes. Phần lớn những chức năng của portlet đều nằm trên view mode. Nhưng một portlet có thể cung cấp edit mode để cấu hình portlet, help mode cung cấp thông tin trợ giúp người dùng. Ngược lại, servlet không có khái niệm modes, mà chỉ có view mode.
    Vòng đời của portlet request phức tạp hơn servlet. Trong khi servlet chỉ xử lý một kiểu request, portlet xử lý cả ActionRequests và RenderRequests.

    Tại sao Portlet cần MVC?


    Dùng MVC Frameworks (Struts hay Spring MVC) cho ta một cách tương tác tốt khi phát triển một ứng dụng web với servlet, nhưng ta cũng có thể xây dựng mà không dùng chúng. Vì một ứng dụng servlet có thể dễ dàng chuyển trang, hay gọi một chức năng khác. Nhưng khi một ứng dụng chỉ muốn một servlet có thể điều khiển tất cả các tính năng, thì không thể xây dựng bằng servlet được.
    Một ứng dụng portlet thì khác. Nó có thể có nhiều portlet chỉ chứa trong 1 portal view. Nó chỉ có thể render trong space mà nó đang quản lý, còn việc dùng một portlet khác trong space của nó thì không thể.
    Nếu bạn đang xây dựng một portlet đơn giản, như dự báo thời tiết, RSS view hay một portlet chỉ có 1 đến 2 view, thì bạn chẳng cần một MVC.
    Nhưng nếu không dùng MVC, viết một ứng dụng hướng tính năng thì có thể làm bạn nản. Như bạn thấy trong hình H.2, phương thức processAction() và render() có thể trở thành một mớ những if/else để có thể điều hướng các thao tác trên portlet.
    Hình H.2: Không có MVC framework, một portlet sẽ gánh thêm trách nhiệm chuyển request.

    Khi có MVC, bạn có thể thấy trong hình H.3, một controller portlet có thể điều khiển các reequest đó, và gởi chúng đến một controller thích hợp để xử lý.
    Hình H. 3: Có MVC framework sẽ giúp ta điều hướng request dễ dàng.

    Một cách ngắn gọn, ứng dụng portlet cần MVC framework để điều khiển những tính năng phức tạp. Nhưng chúng ta tìm chúng ở đâu?

    Spring Portlet MVC


    Nhận thức được sự cần thiết của Portlet MVC Framework, Spring đã đưa Spring Portlet MVC (SPMVC) vào Spring 2. SPMVC được viết dựa trên Spring MVC Framework để xây dựng ứng dụng portlet. Dùng SPMVC, chúng ta có thể xây dựng một ứng dụng web hướng tính năng, chỉ chạy trên space của portlet mà portal cung cấp.

    Về vòng đời của portlet request trong SPMVC thì không khác gì so với Spring MVC. Như bạn thấy trong hình H.4, trạm dừng đầu tiên của một portlet request là DispatcherPortlet(1). DispatcherPortlet làm việc gần giống như DispatcherServlet, là chuyển quyền thực hiện đến controller.

    Handler Mapping(2) cho biết controller nào sẽ chịu trách nhiệm xử lý request này. Portlet Handler Mapping cũng tương tự như Spring MVC Handler Mapping, thay URL bằng Map Portlet Modes trong controller.

    Một controller thích hợp được chọn, DispatcherPortlet gởi request thẳng đến controller đó để xử lý (3).
    Hình H.4: DispatcherPortlet chuyển portlet request đến controller và view, dựa vào handler mapping và view resolver.

    Đây là nơi mà vòng đời của portlet request bắt đầu. Nhớ rằng có 2 kiểu của request là action request và render request. Nếu là 1 action request, vòng đời của nó được chuyển qua controller để xử lý. Nhưng nếu là render request, thì cần một số trạm xử lý khác.

    Để xử lý một render request, controller sẽ trả về một đối tượng(object) ModelAndView cho DispatcherPortlet. Nó sẽ dùng cùng một ModelAndView với Spring MVC controller. Nó sẽ chứa tên của view được trả về cùng với một số dữ liệu cần để view.

    Tại đây, DispatcherPortlet đã có tất cả những thứ cần để thể hiện lên portpet. Nhưng đầu tiên, nó cần tìm trang thể hiện bằng cách gọi đến view resolver(5).

    Bước cuối cùng cho một render request trang view(có thể là JSP). View sẽ dùng dữ liệu trong request để view trong portlet space, của portal page.

    Với những kiến thức trên, bạn đã có thể làm một ứng dụng portlet đầu tiên dùng SPMVC.

    Đọc tiếp >>

    Cao Trong Hien

    ,

    Khám phá Java: biến static trong inner class

    Hôm nay tình cờ đọc một bài về một lỗi khó hiểu của Java. Có thể nó sẽ làm bạn đau đầu đây, cùng tôi khám phá nhé.

    Click vô hình để phóng to


    Ta có thể nhìn thấy 2 biến được khai báo, nhưng khác kiểu. Theo bạn thì ta đang gặp vấn đề gì vậy

    Gợi ý nhé:
    1.Nó sẽ đúng khi ta khai báo Object là String, nhưng array thì không.
    2. Bạn sẽ bị báo lỗi sau khi dùng Eclipse:
    The field OBJECT_CONST cannot be declared static; static fields can only be declared in static or top level types

    Báo kiểu này chỉ làm ta rối mắt thêm thôi, vì biến integer dùng được mà.

    Comment nhé. :-)

    Đọc tiếp >>

    Cao Trong Hien

    Bill Gates ra đi: Chấm dứt một “đế chế” - p5


    Là một cây gai trong mắt nhiều người, nhưng Gates một sức mạnh có thể tấn công nhiều cái đầu trong giới công nghệ, và đem họ đến với Microsoft.


    Mộ nhân tài


    Tim Paterson, người tạo ra QDOS, đến với Microsoft; Dave Cutler đến từ Digital Equipment Corp. dẫn đầu nhóm phát triển Windows NT; Jim Allchin, một kiến trúc sư cho công nghệ ảo, người làm ra hệ điều hành Banyan VINES, đến với Microsoft dẫn đầu sự phát triển; và khi Gates đang tìm kiếm một người nối nghiệp giám đốc phát triển phần mềm, ông thuyết phục Ray Ozzie, người đầu não trong Lotus Notes, vào vị trí đó.

    Và trong khi Microsoft có rất nhiều địch thủ, chìa khóa thành công của công ty là một môi trường thân thiện cho nhân viên, và các chế độ khuyến khích nhân viên trong năm. Dường như sự giới hạn những thứ được cài đặt trong Windows đã đảm bảo các ứng dụng nhỏ, có thể lớn lên, và thu lợi nhuận, từ việc bán nó. Họ đã thu hút hơn 640,000 đối tác giải pháp toàn cầu, 4.3 triệu người có chứng chỉ công nghệ của Microsoft.

    Dù gì thì Gates cũng đã ra đi: một sự tích hợp chưa từng có giữa tư duy công nghệ và đầu óc kinh doanh.

    Nhưng đó là một công ty cần tìm một hướng đi mới, bất chấp sự dàn trải. Họ đang tìm đường để lấy lại thế cân bằng trong lĩnh vực Web 2.0 với Google –bằng việc thôn tính Yahoo – đã thất bại trước đó. Họ cũng đang hoàn thiện hệ điều hành tai tiếng Windows Vista, và đi đến cái mà họ gọi là Windows 7.

    Nhưng nếu người nối nghiệp Gates, Steve Ballmer, đã học mọi thứ từ các mối quan hệ của Bill, mang một tính cách kiên trì và mạo hiểm, mọi thứ sẽ khác chăng?

    Đọc tiếp >>

    Cao Trong Hien

    ,

    Bill Gates ra đi: Chấm dứt một “đế chế” - p4


    Internet bắt đầu chỉ là sự liên hệ giữa một máy desktop và hệ thống server, Gates đã phát hiện và ưu tiên số một cho hệ thống này trong chuỗi từ “Internet Tidal Wave”, đưa ra năm 1995, và yêu cầu nó phải đi sâu vào mọi hoạt động của công ty.


    Độc quyền


    Đi trên con đường mà Gates và Microsoft gần như đánh mất. Vì vậy, sự thi hành có vè không ổn, và nhiều lỗi. Và một lần nữa, Gates đi vào thị trường khi mà mình không phải là người tiên phong, chỉ phát triển vì thương hiệu, và tránh bị chi phối.

    Trong khi đó, Gates đang nắmg giữ cái mà Brynjolfsson gọi là “kinh tế thông tin” rất tốt mà sự độc quyền của Windows là một minh chứng, một cuộc điều tra bắt đầu.

    Không chỉ bán nhiều sản phẩm trong một gói, họ còn tích hợp cả các chương trình ứng dụng (IE) vào Windows, là một bước đánh vào công ty đi đầu trong lĩnh vực này là Netscape Navigator. Đó cũng là lúc cuộc điều tra độc quyền bắt đầu giữa những năm 1990.

    Kết quả là Microsoft bị kiềm chế trong suốt một năm.

    Gates đã nhanh chóng biến những chàng David trở thành một đối thủ xứng tầm của Goliath của IBM, tạo ra một danh sách dài các đối thủ, bao gồm IBM, Lotus, Novell và Sun. Điều hành của các công ty này là các tác nhân mà Gates có các hành động mang tính sống còn. Dẫn đến cuộc điều tra độc quyền, mà người thực hiện là Thomas Penfield Jackson, người đã yêu cầu Gates và công ty ông ta để đối chất về các cáo buộc. Nhưng trớ trêu thay, sự thật bị đảo lộn, và vụ kiện này không có kết quả. Rồi kể từ đó Microsoft liên tục dính vào các vụ kiện chống độc quyền với Time Warner, Sun Microsystems, RealNetworks và Be...

    "Các vụ xử độc quyền thường được giải quyết bằng hình phạt phân rã công ty.

    Năm 1911, Công ty dầu Standard Oil bị buộc tội độc quyền khi mua các đối thủ và ép các công ty hỏa xa mua dầu của mình.

    Ở thời điểm đó, Standard Oil của ông trùm John D. Rockefeller chiếm đến 90% thị phần Mỹ (gia sản Rockefeller năm 1911 là 900 triệu USD - hơn 2% GNP của Mỹ - trong khi ngân sách liên bang Mỹ năm đó chỉ có 750 triệu USD!).

    Cuối cùng, Standard Oil bị chia thành 34 công ty con mà những kẻ sống sót nay đã trở thành các công ty dầu lớn nhất thế giới như Exxon, Mobil, Chevron và Amoco.

    Năm 1911, Mỹ cũng xử tội độc quyền Công ty thuốc lá American Tobacco, chiếm 95% thị phần Mỹ.

    Kết quả, American Tobacco biến thành 16 công ty mà hai kẻ sống sót hiện nay đã nổi danh là R.J. Reynolds và British American Tobacco."
    Theo FIRST NEWS


    Bài cuối: Mộ nhân tài

    Đọc tiếp >>

    Cao Trong Hien

    Bill Gates ra đi: Chấm dứt một “đế chế”-p3


    Với Windows, Gates đề nghị dùng Microsoft Office, một gói ứng dụng bao gồm Word, Excel và PowerPoint. Với chiến lược đó, Brynjolfsson cho rằng, là chìa khoá thành công trong CNTT của Microsoft.

    Đưa ra phiên bản đầu tiên luôn khó khăn và tốn kém nhất, nhưng các phiên bản tiếp theo thì sẽ rất dể dàng. Một nhà cung cấp thường gia tăng lợi thế bằng cách cung cấp nhiều sản phẩm cùng nhau. Và chiến lược này chỉ làm việc tốt khi chúng có giao diện tương đồng,là một khối không thể tách rời, và đó là cách làm của các ứng dụng Microsoft.

    “Việc bán từng sản phẩm tách rời thường không đem về lợi nhuận lớn, nhưng gộp chúng lại sẽ làm người mua cảm thấy thích thú hơn,” Brynjolfsson nói. “Nó đem đến cho Gates một lợi nhuận khổng lồ. Mặc dù có một sản phẩm tốt hơn, nhưng phần lớn mọi người thích một gói đồng nhất, và đó là lý do họ mua Microsoft Office.”

    Cách làm này làm tăng thị phần một cách tốt nhất và đem lại lợi nhuận. “Giống như một bữa ăn của McDonald,” Brynjolfsson giải thích.

    Kết quả: “Giá của các sản phẩm Microsoft thường thấp hơn các đối thủ với cùng một tính năng,” ông ta nói. “Tôi nghĩ đóng góp lớn nhất của Bill Gates là những kiến thức về kinh tế. Điều mà phần lớn đối thủ không có.”

    Sự phát triển thần kỳ và lợi nhuận khổng lồ đã làm cho Microsoft trở thành một tổ chức có tài chính vững mạnh hơn tất cảc các đối thủ. Gates đấu tranh một cách tàn nhẩn, đảy nhiều công ty đến bờ phá sản.
    Nhưng Gates đã không thấy trên lĩnh vực Internet, xuất hiện đầu những năm 1990, có thể làm thay đổi cả một ngành công nghệ phần mềm.

    Bài 4: Độc quyền

    Đọc tiếp >>

    Cao Trong Hien

    Bill Gates ra đi: Chấm dứt một “đế chế”-p2


    Bước ngoặc lớn nhất của nhà tỉ phú Gates là năm 1986, chỉ sau 11 năm kết bạn với Paul Allen, Microsoft là kết quả của việc sáp nhập, đặt trụ sở tại Albuquerque, N.M., khi đó Gates mới 20.


    Windows hình thành



    Và sản phẩm đầu tiên dưới sự giám sát của ông ta – Windows – dường như có một sự khởi đầu không mấy sáng sủa, chỉ được chấp nhận sau vài phiên bản và sự thống trị thể hiện sau đó khá lâu. Và không phải là đến năm 1988, Microsoft đã vượt qua Lotus để trở thành công ty phần mềm lớn nhất thế giới.

    “Windows 1.0 không chạy được,” John Dodge nói, là một trong những nhà sáng lập PC Week năm 1983, giờ là eWEEK. “Nó hứa hẹn tiết kiệm phần cứng-- tăng cường tốc độ xử lý. Windows 3.0 mới chính là bản đầu tiên dùng được.”

    Windows 1.0 được công bố năm 1983 và ra đời năm 1985; Windows 3.0 trình diễn năm 1990 tại một hội nghị công bố tại New York với sự chủ trì của Gates. Và sau đó, phần lớn mọi người cho rằng, Windows đang chạy theo Apple Macintosh OS, được giới thiệu năm 1984, là một hệ điều hành có giao diện dành cho máy tính cá nhân.

    Đi sau chính là lý do mà người ta đánh giá không cao công nghệ của Microsoft và tài kinh doanh của Gates. Thời gian sau đó, Gates cũng chỉ phát triển theo hướng thăm dò thị trường, và để hiểu hết xu hướng.

    Chìa khoá thành công của Microsoft là mối quan hệ với IBM, nhưng nó đã có một kết thúc buồn.
    Nó bắt đầu khi hãng nghiêng cứu công nghệ Gary Kildall chậm chân trong việc thương thảo về bản quyền với IBM về hệ điều hành CP/M, Gates nói với gã khổng lồ IBM rằng ông ta có thể cung cấp. Sau đó ông ta mua QDOS (“Quick and Dirty Operating System,” một anh em song sinh của CP/M được viết bởi Tim Paterson) từ Seattle Computer Products và chuyển giao nó cho IBM đặt tên là MS-DOS. Nhưng quan trọng là Gates giữ bản quyền của HDH này và có thể bán nó cho một nhà cung cấp khác như Compaq, một hãng mà chỉ vài năm sau đó đã vượt qua IBM. Thủ đoạn thì cần đầu óc, và nó chính là Gates.

    Đối tác với gã khổng IBM trong một vài phiên bản DOS, mà đỉnh cao là thoả thuận xây dựng HDH OS/2 năm 1985.

    Phiên bản 1.1 của OS ra đời năm 1988. Trong khi IBM đang hướng đến thị trường PCs đắt tiền, Gates vẫn duy trì nhóm làm việc trên HĐH Windows, được đánh giá là tốt ngang với OS/2, với giá thấp, tiết kiệm phần cứng và thích hợp với phần lớn các nhà cung cấp PC.

    Bài 3: Chìa khoá thành công

    Đọc tiếp >>

    Cao Trong Hien

    Bill Gates ra đi: Chấm dứt một “đế chế”-p1


    Ngày mai, 27/06/2008. Là ngày mà nhà tỷ phú Bill Gates chính thức thôi chức chủ tịch Microsoft. Tôi sẽ có một loạt bài viết về ông ta (Mặc dù tôi chẳng thích ông cho lắm), nhưng dù sao thì ông ta cũng là người có đóng góp rất lớn đối với nền CNTT thế giới, nên ... Mời các bạn đón đọc.
    Làm thế nào mà nhà sáng lập Microsoft có thể thay đổi cả một ngành điện toán, thay đổi cách kinh doanh và cả cuộc sống của chúng ta. Ông có xứng đáng sánh vai cùng John D. Rockefeller. Henry Ford. Andrew Carnegie, trong danh sách nhà kinh doanh đã đi vào lịch sử?


    Bill Gates đi vào lịch sử?


    Có nhiều cuộc tranh luận về việc đưa Gates lên ngang hàng với những nhà kinh doanh đã đi vào lịch sử. Là một người có kiến thức sâu rộng về công nghệ, về chiến lượt kinh doanh và có một quyền lực khá lớn trong giới công nghệ.

    Gates ngài chủ tịch Microsoft, nhưng vào ngày 27 tháng 6, ông sẽ từng bước chuyển giao cho người kế nhiệm, trong khi Microsoft đang dẫn đầu trong lĩnh vực phần mềm, với ước tính hơn 84,000 nhân viên và thu nhập hàng năm hơn 68 tỉ USD. Thay vào đó, Gates sẽ dùng toàn bộ thời gian cho tổ chức từ thiện Bill & Melinda Gates.

    Bắt đầu viết chương trình máy tính từ gần 40 năm trước, Gates đã thay đổi ngành điện toán, thay đổi tư duy trong kinh doanh và thay đổi cuộc sống của chúng ta. Đến nay, ông dùng những gì mình có được để làm từ thiện.

    Nhưng Gates đã bỏ qua niềm đam mê lập trình – đã có ngay khi ông còn trẻ - đi theo hướng kinh doanh, và thành công với nó.

    Theo Erik Brynjolfsson, một giáo sư của trường đào tạo quản lý MIT Sloan và là giám đốc trung tâm Digital Business tại MIT, cho rằng “Gates có một trình độ kỹ thuật và kiến thức kinh doanh mà không ai có. Kiến thức về kỹ thuật của ông ta thật tuyệt, nhưng thành công của Microsoft là nhờ vào kiến thức kinh doanh, nhiều hơn là kỹ thuật chuyên môn. Ông đã phát huy nó, trở thành một học thuyết về kinh tế. Là người mở đường cho kinh doanh thực tiễn và luôn ở xung quanh các đối thủ của mình.”
    Và từ đó, một công ty cung cấp phần mềm khổng lồ ra đời, với một danh sách đồ sộ của các sản phẩm - từ games đến các hệ thống quản lý - hơn một tỉ người dùng khắp thế giới và đang '”cố gắng” thể hiện ưu thế trong lĩnh vực Web 2.0.

    Bài 2: Windows hình thành

    Đọc tiếp >>

    Cao Trong Hien

    ,

    Sếp có luôn đúng?

    Bạn có 2 lựa chọn:
    1: Sếp thì luôn luôn đúng.
    2: Nếu bạn nghĩ Sếp không đúng, xem điều 1.



    Sau khi xem bức tranh, hãy cho tôi biết bạn nghĩ sao về lựa chọn 1.

    Đọc tiếp >>

    Cao Trong Hien

    Đừng kết hôn với con gái IT!!

    Hôm nay, tôi tìm thấy một thông tin vô cùng hấp dẫn về việc kết hôn với nữ IT. Và rút ra rằng: đừng kết hôn với con gái có liên quan đến lĩnh vực phát triển phần mềm. Muốn biết tại sao à? cùng tôi tìm hiểu nhé.

    Đừng bao giờ kết hôn một nữ Testing vì cô ta luôn luôn nghi ngờ BẠN.

    Đừng bao giờ kết hôn một nữ DATABASE vì cô ta luôn muốn chồng mình trở thành một UNIQUE key.

    Đừng bao giờ kết hôn một nữ C bởi vì cô ta luôn có khuynh hướng BREAK mọi thứ và EXIT khỏi nhà.

    Đừng bao giờ kết hôn một nữ C++ vì bạn có thể chạm trán với rất nhiều vấn đề trong INHERITANCE.

    Đừng bao giờ kết hôn một nữ JAVA vì cô ta luôn luôn tung EXCEPTIONS.

    Đừng bao giờ kết hôn một nữ VB vì cô ta sẽ tách FORM ra khỏi mình.

    Đừng bao giờ kết hôn một nữ UNIX, cô ta luôn dump bạn như một core.

    Đừng bao giờ kết hôn một nữ PASCAL, cô ta sẽ mắng mỏ bạn như rascal.

    Đừng bao giờ kết hôn một nữ COBOL vì cô ra rất giỏi về lĩnh vực DIVISION gia đình.

    Đừng bao giờ kết hôn một nữ NETWORK vì có thể cô ta rất thành thạo vấn đề shooting troubles.

    Bạn có thấy vậy không ???



    Đọc tiếp >>

    Cao Trong Hien