Hiendt's Weblog

Đã 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 >>

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 >>

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 >>

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 >>

Đố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 >>

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 >>

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 >>

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 >>

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 >>

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ọ.


Đế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.

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ý.

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).

Đâ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 >>

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é.

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 >>

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 >>

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 >>

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 >>

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 >>

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 >>

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 >>

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 >>

Không biết giới báo chí đã tốn bao nhiêu “giấy mực” cho cái giá mới của 3G iPhone. Tính năng 3G và GPS đáng được quan tâm hơn, nhưng không phải vậy. Cái giá $199 mới được quan tâm hơn, và là lí do mà Apple đưa ra kết hoặch bán 10 triệu iPhones trong năm nay, và 22 triệu iPods/3 tháng. Nhưng thực tế, ai sẽ mua iPod và cả iPhone khi cả 2 đều có trong 1 iPhone?

199 USD?

Xét trên khía cạnh cái giá 199 USD thì đó không phải là cái giá thực tế. Bạn là một khách hàng, phải trả tiền dịch vụ hàng tháng của hãng viễn thông (có thể là nhà phân phối) trong 2 năm. Hiện giờ chỉ có một hãng đưa ra giá bán là O2 của Anh (AT&T chỉ nói rằng sẽ tăng gói dữ liệu không giới hạn từ 20 USD đến 30 USD mỗi tháng). Vì vậy, tại Anh, cái giá rẻ nhất mà bạn có thể mua là 99 Bảng (194 USD) cho phiên bản 8GB, cộng với bản hợp đồng sử dụng 18 tháng với giá 30 Bảng (59 USD), vị chi là 639 Bảng(1250 USD).
Nhưng người dường như không quan tâm. Họ chỉ nhìn vào cái giá niêm yết, và thấy rằng nó sẽ rẻ hơn so với iPod (bản 8GB iPod Touch có giá cao hơn 100 USD so với 8GB iPhone 3G -với GPS, camera và loa). Nếu bạn là họ, bạn sẽ mua iPhone cùng với chức năng điện thoại, tại sao lại phải mua cái kia? Và nhớ rằng , 199 USD là giá trị phải trả.
Trong lần ra mắt này, sản phẩm Apple sẽ có nhiều mức giá khác nhau. O2 cung cấp theo cách của họ, và bạn cần có một mức thu nhập hằng tháng kha khá.
Theo cái giá mà Jobs hứa, bản 8GB iPhone sẽ không hơn 199 USD ở mọi nơi trên thế giới. Hy vọng, đó sẽ là cái giá không kèm bản hợp đồng, một iPod tốt nhất mà Apple từng làm, sẽ có giá ở UK dưới 100 Bảng. Khu vực giá dành cho iPod Shuffle?!

Vậy họ sẽ thu lại từ đâu với cái giá này?

Theo một thông tin từ phía AT&T thì họ đã bỏ khả năng chia sẽ thu nhập hàng tháng của mình với Apple. Với số tiền ước tính mà Apple thu được từ AT&T là $336/hợp đồng dịch vụ/2 năm. Nhờ trợ giá của nhà phân phối mà điện thoại ngày nay ta mua có giá tương đối mềm. Nhà phân tích Piper Jaffray tính đến khả năng AT&T sẽ trả tiền chính thức luôn Apple để sở hữu iPhone 3G và đưa ra cái giá cho riêng mình. Có một vài con số được ước tính, hãng phân tích Munster cho rằng Apple đang bán thẳng bản 8GB iPhone cho AT&T với giá $400, và bản 16GB là $450. Theo Fortune, một nhà phân tích khác cho rằng cái giá của bản 16GB có thể lên đến $700.
Bỏ đi phương thức chia sẽ thu nhập sẽ đem đến cho Apple lợi nhuận khổng lồ từ hơn 70 nhà phân phối hiện nay. Và chắc chắng là thu nhập sẽ còn hơn phiên bản iPhone cũ. Còn AT&T thì đang vật lộn với số tiền bỏ ra cho thương vụ này. Đó có thể là lý do mà người ta cần ký hợp đồng khi mua iPhone.

Còn người dùng?

Có vẻ tréo ngoe làm sao khi một sản phẩm lớn nhất từ trước đến nay của Apple, lại không được đưa lên Apple Store. Tất cả những gì mà khách hàng cần làm là ký vào hợp đồng với dịch vụ của nhà phân phối để được sở hữu. Theo một tiết lộ mới đây trên Reuters, rằng các khách hàng đã mua iPhone và bẻ khoá sẽ phải “trả giá” cho hành động này.
Có vẻ như họ đang hướng về việc khoá dùng một dịch vụ cung cấp cho iPhone là iTunes. Chúng ta cần phải thanh toán cho dịch vụ này. Tạm biệt iPhone “chợ đen”.
Có lẽ sẽ chỉ còn lại những tiếng than thở từ phía khách hàng dùng dịch vụ chính thống mà tôi đã từng nghe: iPhone không đáng có cái giá đó khi chỉ là một chiếc "điện thoại nghe nhạc", hay "tôi đã có một cái iPod rồi (và tôi không cần thêm một cái nữa – CTH)", và “cái giá này cho cái phone đó là quá vô lý”...

Nguồn: wired

Đọc tiếp >>

280 Slides, một ứng dụng web dùng để tạo slideshow giống như các ứng dụng như Google Presentations, Sliderocket, Empressr hay Zoho. Điều đầu tiên có thể nhận thấy ở 280 Slides là có một giao diện khá thân thiện, tương tự như Apple Keynote.


Trong bài phát biểu của mình, 3 nhà sáng lập – trong đó có 2 là cựu nhân viên Apple, 1 trong iPhone, 1 trong iTune Store team - đã đưa ra 2 lý do họ đưa ra 280 Slides khi mà các ứng dụng tương tụ đang đi vào ngõ cụt.

Thứ nhất, họ xây dựng hệ thống bằng Javascript Framework mà họ viết ra là Cappuccino là một thành phần của Apple Cocoa framework, và sẽ mở nguồn trong tương lai. trong khi một số khác dùng Flash hay Flex.

Thứ hai, họ cho phép download theo định dạng PowerPoint, trong khi phần lớn các ứng dụng khác hạn chế. Ngoài ra nó còn có một số tính năng như khả năng tương tác với một số dịch vụ web khác như khả năng chia sẽ với Slideshare, hay thêm một media từ YouTube và Flickr, cùng với khả năng nhúng vào website khác.

Mặc dù, nó vẫn chưa thể thay thế được một ứng dụng desktop với rất nhiều các tính năng như biểu đồ, styling hay các hiệu ứng. Nhưng với những người dùng bình thường thì nó hoàn toàn có thể đáp ứng tốt với các tính năng mà tôi nêu trên.

Nguồn:84bytes, techcrunch

Đọc tiếp >>

Yahoocrosoft! có thể làm đổ vở thế độc quyền hiện nay của Google. Yahoo! Inc hôm nay cho hay đã cân nhắc đề xuất 44.6 triệu USD từ phía Microsoft Corp. Tuy nhiên, ban giám đốc Yahoo! xác nhận sẽ có lợi hơn cho cả hai bên nếu Yahoo! đứng vào thế mua Microsoft với giá 44.7 tỉ USD để trở thành Yahoocrosoft!


"Đầu tiên, lời đề nghị này có lẽ làm cho mọi người ngạc nhiên, với giá trị của Microsoft ước lượng khoảng 284 tỉ," Jerry Yang nói. "Nhưng có một lý do quan trọng, chúng tôi nhận thấy Microsoft và các cổ đông – có thể cả Google — sẽ có lợi từ đề nghị này."
Tại một cuộc họp cổ đông vào 12h chiều, thứ 6, ngày 1, tháng 2, Yang phác thảo một sức mạnh kinh khủng của Yahoocrosoft!.
Cơ cấu hiện tại của Microsoft đang phình to với nhiều sản phẩm và dịch vụ. Dưới thời Yahoocrosoft!, sẻ chỉ đơn giản có 4 phòng ban "Shopping," "Games," "Weather" và "Personals." All sub-departments sẽ được trang trí theo tông màu và đánh dấu với những logo dễ thương.
Yahoocrosoft! sẽ hợp lý hoá các chứng chỉ của Microsoft tránh xa sự hổn độn hiện thời với các tên như "Microsoft Certified Solution Developer." Dưới thời Yahoocrosoft! các chứng chỉ sẽ chỉ bao gồm "HotJobber!" và "DataBoss!".
Việc thu mua Microsoft chắc chắn sẽ không làm cho các văn phòng tư pháp quan tâm. Tuy nhiên, với Yahoocrosoft!, các đối thủ cạnh tranh chắc chắn sẽ lo lắng cho tương lai từ những ưu thế của chúng ta trên thị trường.
"Hỡi các cổ đông, hãy hỏi bản thân rằng," Yang nói lời cuối, "cái nào là quan trọng? Trở thành một công ty khổng lồ để vượt qua Google? Hay có một cái tên bị người ta thay đổi? Và tôi tin rằng, câu trả lời đã rất rổ ràng."

*Note: Đây chỉ là một entry vui, mang tính chất giải trí, được dịch từ một website không hề có uy tín (dĩ nhiên cả chuyện bản quyền :D)- CTH.

Đọc tiếp >>