:-Dzinh on tech

...

2010-08-05T09:58:00.000+07:00

Agile product design

2009-03-26T01:21:00.006+07:00

Bữa nay buồn buồn đi lang thang, vô tình mình đọc được các bài viết / presentation về phân tích theo hướng Agile, sử dụng User Story phải nói là ... quá hay :-D (đang buồn ngủ mà đọc xong là ... tỉnh ngủ luôn)

User story mapping (download here)
User story to user interface (download here)
Embraced uncertainly (download here)
User experience distilled (download here)
..............

Cám ơn Jeff Patton đã chia sẽ kiến thức một cách cô đọng và dễ hiểu, một cây đại thụ của Agile.

NHibernate FAQ

2009-03-26T01:15:00.003+07:00

Block này viết về NHibernate khá hay, không chỉ đơn thuần là NHibernate mà còn là các thức phát triển phần mềm nữa (test driven, domain driven, seperate of concern, etc.)

http://blogs.hibernatingrhinos.com/nhibernate/Default.aspx

Ngoài ra nó dùng domain driven, đúng hướng mapping hơn so với template của Codesmith ở bài trước.

NHibernate template

2009-03-15T14:04:00.003+07:00

Download codesmith 5.0 professional (trial version) at codesmithtools. The template is included there.

Or download it here: http://codesmith.googlecode.com/svn/trunk/Templates/Frameworks/NHibernate/

Watch the tutorial video here.

Install TestDriven here. (one plug in for UnitTest in VS 2008)

3D nhập môn

2009-03-13T00:42:00.003+07:00

Quy trình hiển thị 3D bao gồm các bước:

Modeling Transformation: biến đổi từ hệ tọa độ đối tượng sang hệ tọa độ thế giới thực.
Trivial rejection: loại bỏ các đối tượng không nhìn thấy được.
Illumination: chiếu sáng đối tượng.
Viewing transformation: chuyển ừ world space sang eye space.
Clipping: loại bỏ phần nằm ngoài viewing frustum (góc nhìn hình chóp cụt).
Projection: chiếu từ eye space xuống screen space.
Rasterization: chuyển từ đối tượng sang dạng pixel.
Display: hiển thị đối tượng.

Code đẹp và code dễ đọc

2009-03-13T00:31:00.005+07:00

(dịch từ Beautiful code vs Readable Code, có sự hỗ trợ của google translator :-D)

Trong nhiều năm - thực sự nhiều thập kỷ qua - Tôi là một fan hâm mộ lớn của code đẹp. Tôi đọc gần như tất cả mọi thứ của Brian Kernighan, Jon Bentley, và P. J. Plauger. Niềm đam mê này là một cố gắng tạo lại sự hăm hở (rush) khi tôi đọc được đầu tiên dòng code:

*x++ = *y++

Trong ngôn ngữ lập trình. Tôi chưa bao giờ nhìn thấy bất cứ đoạn code nào cô đọng đẹp đến vậy. Nó đã được phát minh! Nhưng nhiều năm qua, tôi đọc rất nhiều các thuật toán thông minh, rất nhiều tối ưu hóa ấn tượng, rất nhiều thủ thuật nhỏ. Và tôi đã nhận ra càng ngày càng ít hơn những gì thu được (charge) trong những khám phá đó. Lý do là, khá thẳng thắn, là chúng gần như luôn luôn rơi vào một trong hai loại: một số cách thể hiện rất tao nhã trong một ngôn ngữ mới (Ruby được chuyển từ Java là một minh chứng) hoặc một kỹ thuật mà tôi không bao giờ có khả năng để sử dụng. Nói cách khác, tôi đang theo đuổi những món đồ chơi rẻ tiền. Theo thời gian, khiếu thẩm mỹ của tôi chuyển thành việc code một cách sáng sủa vì sự dễ chịu của nó.

Bây giờ, nếu tôi có thể chọn ra một đoạn code phức tạp, đọc nó lướt qua, và hiểu một cách chính xác những gì nó làm, thì tôi cảm thấy hăm hở trở lại. Tôi thường có cảm giác này khi đọc các đoạn code từ những lập trình viên giỏi, hoặc không hàng lâm. Nói một cách trung thực, khi miệt mài trong khoảnh khắc như vậy, tôi thường xuyên nhận thức rằng đoạn code của tôi không giống như họ. Thậm chí đoạn code hay nhất của tôi hoàn toàn không giống với họ một chút nào. Và tôi đã tự hỏi tôi có thể làm gì để cải thiện tính rõ ràng (clarity) trong đoạn code của tôi.

Cuốn sách mới của Kent Beck, Implementation Pattern là một cuốn sách tóm tắt ngắn về code rõ ràng. Tôi đã đọc nhiều về nó và tôi đã nhận ra rằng một số thói quen xấu của tôi đã làm phá hoại đi tính đọc được của đoạn code. Beck cơ bản chỉ nhìn vào các đoạn code có vấn đề và tư vấn những lời khuyên khôn ngoan.

Điều này có nghĩa là vài lời khuyên là thích hợp nhất cho người mới bắt đầu, trong khi chúng chỉ đủ là các lời gợi ý tế nhị để giữ sự chú ý của một người kỳ cựu, người quan tâm đến sự rõ ràng.
Ví dụ, một trong những thói quen xấu là tôi thường code mà không không cần suy nghĩ nhiều về sự pha trộn của các mức độ trừu tượng hóa trong cùng một method. Vì vậy, ví dụ (sử dụng ví dụ của Beck):


void process() {
   input();
   count++;
   output();
}

Dòng code thứ hai rõ ràng ở một mức độ trừu tượng khác với hai cái kia, và làm cho đoạn code khó đọc một cách nhanh chóng. Beck đề nghị giải pháp sau đây, mà tôi đồng ý là rõ ràng hơn.


void process() {
   input();
   tally();
   output();
}

Có nhiều thói quen xấu khác của tôi mà cuốn sách này đã soi sáng. Và trong nửa tá thay đổi sẽ mang đến cho phong cách của tôi, tôi nghĩ rằng tôi đã thu được nhiều lợi ích hơn so với trong tất cả các bài luận tôi đã đọc về chủ đề beautiful code.

Tuy nhiên trước khi kết thúc, tôi nên đưa ra hai lời cảnh báo: Tài liệu cho người mới bắt đầu đến trung cấp đang tràn lan, vì vậy bạn sẽ cần phải lươm lặt trên phần lớn đống chữ nghĩa đó để rút trích ra các thông tin có giá trị. (Tuy nhiên, khía cạnh này tạo món quà cho các lập trình viên junior ở vị trí của bạn.) Điểm thứ hai là cuốn sách này thiếu chỉnh sửa tốt. Một cuốn sách về clarity code thì nên trong sáng; cuốn này thì không. (Xem xét việc sử dụng các từ ‘mẫu từ,' nó rất dể gây hiểu lầm cao. Và không phải tất các mẫu từ đều như vậy.) Nhưng những vấn đề này có thể chấp nhận được.

Test syntax highlighter

2009-03-12T12:42:00.001+07:00


while (relax() == true)
{
  destroy();
}

Extjs

2009-01-06T17:35:00.003+07:00

Cứ nghĩ khi dùng ExtJs để viết GUI thì quanh đi quẩn laị cũng có nhiêu đó, nhưng thật bất ngờ khi thấy có những site viết GUI trên đó khá cool

Con đường của Semantic Web

2008-12-21T22:56:00.003+07:00

Semantic web là gì?

Theo định nghĩa của wikipedia, Semantic Web là một dự án dự định tạo ra một thiết bị (phương tiện) toàn cầu dùng cho việc trao đổi thông tin bằng cách đặt các văn bản cùng với ý nghĩa được xử lý bởi máy tính (ngữ nghĩa) trong World Wide Web. Ý tưởng chính là tạo ra một meta data dùng để miêu tả data, cho phép các máy tính xử lý ý nghĩa của chúng. Một khi các máy tính được trang bị với các khả năng hiểu được ngữ nghĩa, nó sẽ có khả năng giải quyết các vấn đề tối ưu hóa ngữ nghĩa phức tạp. Ví dụ, như John Markoff miêu tả trong bài viết của mình, một máy tính sẽ có thể trả ra kết quả tức thời nếu bạn nói với nó tìm một chỗ nghỉ với giá tiền khoảng 3K. Ngoài khả năng trên, thông tin trên web cần được giải thích với các miêu tả và các quan hệ. Ví dụ cơ bản của semantices bao gồm việc phân loại đối tượng và thuộc tính của nó. Ví dụ các cuốn sách nằm trong một danh mục sách thì có các thuộc tính như là tác giả, số trang, ngày xuất bản. Ví dụ về mối quan hệ đến từ các mạng xã hội khác nhau. Trong một mạng lưới quan hệ có thể là "một người bạn của", hoặc "một thành viên của gia đình.." hoặc là "làm việc với".

RDF, OWL và cách tiếp cận mang tính toán học để chú thích

Có hàng tỉ trang web không có cấu trúc HTML không chứa meta data và annotations (lời chú giải). Câu hỏi cơ bản là làm cách nào chúng ta có thể đi từ web không có cấu trúc hiện nay đến một thứ giàu thông tin ngữ nghĩa hơn. Tổ chức W3C đã xuất bản các đặc tả cho RDF (Resource Description Framework) và OWL (Web Ontology Languages) cố gắng cho phép việc thu thập và mô tả thông tin theo tập hợp, cùng với bản chất học (ontology) và các mối quan hệ với các mảng thông tin khác, một cách chính xác và toán học.

RDF là một ngôn ngữ dựa trên XML cho phép miệu tả mối quan hệ thông qua các vị từ (predicates). Wikipedia giải thích: Subject dùng để chỉ về resoruce, và vị từ chỉ về các nét chính (traits) hay các khía cạnh của resource và diễn tả mối quan hệ giữa subject và object. Ví dụ, một cách để diễn tả "The sky has the color blue" trong RDF là câu gồm có 3 phần: một chủ ngữ chỉ về "the sky", một vị từ chỉ về "has the color" và một object chỉ về "blue".

OWL là một ngôn ngữ dựa trên XML khác dùng để miêu tả và giải thích các bản chất vấn đề (ontologies - bản thể học). Một cách tóm gọn, OWL tận dụng các mô tả ngữ nghĩa chẳng hạn như con chó nó một con vật, hoặc con chó có 4 chân. Có 3 dạng OWL: OWL Lite, OWL DL, và OWL full - mỗi loại có những khía cạnh khác nhau và có sự trả giá lẫn nhau giữa việc diễn tả và khả năng tính toán để hiểu được nó. Framework RDF/OWL này dễ hiểu, nhưng khó cho người nò không có nền tảng toán hoc và khoa học máy tính. Cho rằng có một cách tiếp cận từ dưới lên, rõ ràng rằng để thành công, cần phải tồn tại một cơ chế lấy các nội dung html đã tồn tại và chuyển nó về RDF hoặc OWL meta data. Tuy nhiên, việc này là một vấn đề giống như quả trứng với con gà cái nào có trước (chicken-egg problem). Chúng ta có thể mường tượng ra các tool thực hiện khoảng 80% công việc tự động và sau đó tương tác với con người để thực hiện 20% công việc còn lại.

Microformats

Nhận ra tính phức tạp của RDF và OWL, một nhóm người đang cố gắng thực hiện một cách tiếp cận khác gọi là Microformats. Mục tiêu của microformats là nhúng các sematics cơ bản vào trong ngay các trang HTML. Cách này diễn đạt không bằng RDF và OWL, nhưng nó rất cô động và sử dụng các xHTML để thêm vào ngữ nghĩa cho trang. Ví dụ có một microformat dùng để miêu ta các thông tin về contact, gọi là hCard. Sử dụng hCard để chú thích vào trong HTML để các browser nào "biết được" microformat hoặc một search engine có thể suy luận / rút trích ra thông tin về người, chẳng hạn như first và last name, tên công ty và phone number. Có một trong những microformat sau này tên là hCalendar cho phép các tác giả của trang miêu tả các events. Nhiều các event site thông dụng như Facebook, và Yahoo! local sử dụng event này để chú thích các event trong trang HTML của họ.

Bỏ đi nét đẹp của việc diễn tả sang một bên (aesthetics), tiếp cận theo microformat rõ ràng đơn giản hơn là RDF và OWL. Và ngay cả khi nó ít mạnh hơn, nó cũng trở nên rất thông dụng. Nhiều tác giả của trang web đã bắt đầu nhúng microformat và trong html page của họ. Chúng ta cũng đang tìm kiếm các ví dụ ban đầu của search engine dựa trên microformat, giống như trang này từ Technorati. Việc đơn giản sử dụng microformat và làm công việc tìm kiếm này đang bỏ đi sự tối nghĩa, nhập nhằng (ambiguity). Nói cách khác, nó tương tự như search theo chiều dọc, trong đó biết chiều nào mà bạn đang tìm kiếm. Với microformat bên trong trang, data không còn tối nghĩa nữa, và kết quả tìm kiếm sẽ được chính xác hơn.

Tuy nhiên, vẫn còn vài vấn đề với microformats. Đầu tiên nó giống như ví dụ từ dưới lên ở trên - người ta phải làm việc để ghi chú lại web site. Tin mới nhất là vì format này đơn giản hơn - ngày càng có nhiều trang được làm xong thông qua reverse engineering và automation. Vấn đề thứ hai là tập hợp các microformat hiện tại không bao phủ hết các nhiều thứ chúng ta gặp online. Ví dụ, chúng ta không quan tâm đến format nào giúp chúng ta diễn tả sách hay movie. Nên có nhiều format cần phải được tạo ra hơn nữa trước khi chúng thật sự "cover" được thế giới web.

Semantic Web là web cá nhân (personalize web)

Vấn đề ghi chú dữ ileu65 rất phức tạp và còn rất xa để nó có thể được giải quyết một cách hoàn toàn. Nhưng chúng ta hãy để nó sang một bên và nghĩ về những thứ mà chúng ta có thể làm một khi tất cả các data đều được ghi chú. Hứa chắc rằng, khi đó chúng ta sẽ làm ít hơn những gì chúng ta đang làm bây giờ -đó là sàn lọc thông qua một đống các thông tin có liên quan. Cho trước một lượng thông tin nào đó đang gia tăng với cấp số mũ và sức chịu đựng của chúng ta thì càng ngày càng ít lại. Đó là một lời tuyên bố thật hấp dẫn. Nếu máy tính có thể trả về các kết quả tìm kiếm ngay lập tức, chúng ta có thể tiết kiếm hàng đống thời gian.

Nhưng có một ngữ nghĩa và biết được tất cả các mối quan hệ giữa các dữ liệu vẫn không đủ để làm việc đó. Lấy một ví dụ đơn giản của một travel agency. Khi bạn xuất hiện (hay tìm kiếm) lần đầu, agent không biết gì để offer cho bạn, ngay cả khi cô ấy biêt semantics của các chuyến du lịch đi nữa, hoặc mối quan hệ giữa các thứ và giá của mọi thứ. Để có hiệu quả, có ấy cần phải biết bạn đã ở đâu rồi, và bạn muốn đến đâu. Do đó cô ta hỏi bạn vài câu hỏi. Tất cả các dịch vụ mà chúng ta nhận được sẽ làm việc theo cách này và kết quả sẽ tốt hơn và hiệu quả hơn theo thời gian, vì người làm dịch vụ sẽ có thời gian để học được bạn thích gì.

Do đó thành phần quan trọng thứ hai của Semantic Web, là cái mà bạn sẽ nâng cao hiệu suất, là một tập cả preference về thông tin cá nhân. Một khi máy tính biết preferences của bạn và có một representation semantic online, nó sau đó có thể chạy một giải thuật để mang lại cho bạn một kết quả chính xác, và mang tính cá nhân hơn. Để làm chó nó khác đi, tham khảo cá nhân của bạn là một filter cần thiết để được áp dụng vào kết quảtìm kiếm của bạn "Tìm một chỗ nghĩ dưới 3K". Khi điều này xảy ra, sau đó ta có thể tuyên bố Semantic Web đã thành công.

Kết luận

Vậy web 3.0 có phải là semantic web? có thể. Và chúng ta chưa ở đó?. Không phải hoàn toàn. Nó sẽ tốn thời gian để chú thích thông tin của thế giới và sau đó lấy thông tin của cá nhân một các đúng đắn, để bắt đầu cho các dạng ứng dụng mà chúng ta đã đề cập. Chúng ta nhất định sẽ đi gần đến đích và sẽ rất thích thú để thấy mọi thứ sẽ được mở ra như thế nào sau vài năm tiếp theo.

Tiếp Nhận Trách Nhiệm (Accepted Responsibility)

2008-12-19T11:53:00.001+07:00

Trách nhiệm không thể được gán cho ai đó; nó chỉ có thể được tiếp nhận bởi người nào đó. Nếu ai đó cố gắng trao trách nhiệm cho bạn, thì bạn là người duy nhất quyết định có nhận trách nhiệm đó hay không.

Các practice phản ánh principle tiếp nhận trách nhiệm theo nhiều cách. Lấy ví dụ, bất kỳ ai nhận làm một việc, họ sẽ ước lượng nó. Tương tự, ai chịu trách nhiệm cài đặt câu chuyện sẽ là người chịu trách nhiệm sau cùng về thiết kế, cài đặt và kiểm thử câu chuyện đó.

Trách nhiệm đi liền với quyền hạn. Sự bất cân đối giữa trách nhiệm và quyền hạn bóp méo truyền thông của nhóm. Khi một chuyên gia qui trình nói cho tôi cách làm việc, nhưng không chia sẻ gì về công việc đó hoặc hậu quả hay kết quả của công việc đó, thì quyền lực và trách nhiệm là không cân xứng. Với tư cách là những trí thức, không một ai trong chúng ta có thể nhìn thấy hay sử dùng các phản hồi để có thể cải tiến. Sự mất cân xứng còn làm tổn thất về cảm xúc cuộc sống.

(thanks Vi for your sharing - reference here)

Refactoring

2008-11-27T11:51:00.001+07:00

(copy từ bài viết mình để trong C8 :-D)

Rất vui khi có người nào đó quan tâm đến chủ đề Refactor. Nếu đã từng là một lập trình viên, một team leader, ... bạn không thể nào tránh được việc này. Ai càng suy nghĩ nhiều về nó, chứng tỏ người đó càng quan tâm nhiều đến chất lượng code, và về mặt logic họ sẽ develop ra được nhiều good code hơn những người khác. (thật ra chủ đề về code quality rộng hơn refactoring)

Refactoring phản ánh tự nhiên của cuộc sống - tôi không phải là siêu nhân mà bắt buộc phải làm tốt tất cả ngay từ đầu. Chỉ đến khi nào cảm thấy cần phải cải tiến nó, tôi cải tiến. Đôi khi tôi ép mình hơn nữa bằng những suy nghĩ như - liệu nó có còn tốt hơn được nữa - và nếu được, tôi lại tiếp tục cải tiến. Ngoài ra, việc tiếp cần một cách tự nhiên này, giúp cho ta thoát khỏi một lỗi lầm hay thường gặp: Premature optimize is the root of all evil

Design patterns là kết quả của một quá trình refactoring (tôi nghĩ vậy :-)). Có điều tác giả không muốn cho chúng ta lại phải giải quyết lại những gì mà họ đã giải quyết, nên xây dựng sẵn, đặt tên cho nó, và làm mẫu để cho chúng ta nhận diện. Cách thức nhận diện design pattern để áp dụng người ta gọi là heuristic. Có điều nếu các bạn muốn thật sự hiểu rõ design pattern, các bạn phải hiểu được quá trình refactoring của nó để ra được hình mẫu đó, hơn là dừng lại ở việc nhận dạng pattern và áp dụng nó. Cũng giống như đánh võ vậy - lúc ra trận thì ai biến hóa được nhiều nhất, linh hoạt nhất thì sẽ thắng, và lúc đó chưa chắc tất cả các chiêu thuộc về một bài quyền đâu, hehe :-D

Có một câu hỏi đặt ra là - có khi nào bạn không thể làm tốt hơn được trong thời điểm đó? Điều mà tác giả bài viết trước gọi nôm na là Ngụy Biện. Thật ra trong thực tế điều này xảy ra rất nhiều, vd như:

Khách hàng kêu giao code liền, copy paste hay làm cái gì để produce liền cho sếp coi là nhanh nhất :-D
QC báo bug muốn fix liền, mình đang làm cái khác nên nhảy vô edit vài chỗ cho nó chạy liền, hơi đâu mà refactor chi cho mệt.
Cái code cũ này thằng nào viết chuối quá, mà biết gì đâu mà sửa, thôi ngồi change vài cái thôi.
....

Nếu người nào cố tình phớt lờ những vấn đề trên, và mong muốn phải refactor mọi lúc mọi nơi, hoặc làm tốt ngay từ đầu thì người đó mới là.... :-)

Martin Fowler có một khái niệm gọi là Technical Debt, tức là cho bản thân mình (hoặc người khác) nợ về một đoạn code nào đó chưa thật sự là tốt nhất trong thời điểm đó. Khi nào có thể tôi sẽ quay lại làm tốt nó. Người lập trình viên sẽ tạo ra một danh sách nợ đó và quản lý nó, cố gắng trả nợ càng sớm càng tốt vì có thể nó sẽ sinh ra lãi :-D (để càng lâu thì bug càng dễ phát sinh hoặc càng khó improve sau này vì có thể có nhiều class khác phụ thuộc vào nó). Như vậy vấn đề không phải ở chỗ anh viết code tốt hay xấu ở thời điểm đó. Vấn đề là anh phải ý thức được rằng, anh đang mắc nợ, hoặc anh có muốn bị mắc nợ hay không. Và nếu muốn chê bai hay chỉ trích một đoạn code nào đó, cứ xem thử anh developer đang viết có biết được mình đang ... chuối chỗ nào không? Nếu code đã chuối, mà mình cũng ko biết mình chuối, thì công nhận là... chuối thiệt :-D

MVP (2)

2008-08-10T13:21:00.007+07:00

Theo quan điểm của mình thì MVP chỉ là một hình thức khác của MVC. Presenter cũng là một dạng của Controller, chỉ nhấn mạnh ở một số điểm:

Mối quan hệ giữa view và controller: Presenter không bắt buộc phải handle các sự kiện của view mà chính view sẽ làm việc đó. View chỉ thông báo các sự kiện mà nó muốn cho Presenter mà thôi. Và việc Presenter chỉ quan tâm đến View như là một interface làm tăng tính độc lập của cả hai và tính test được nữa.
Mối quan hệ giữa view và model: trong một số trường hợp cần thiết, mô hình cho phép View tương tác trực tiếp với model, nhưng thật sư ở đây mình thấy nếu thông qua Presenter thì chính thống hơn và chả khác gì cả.

Martin Fowler chia MVP ra làm hai dạng: Passive View và SuperVising Conroller.

Để hiểu rõ hơn ta hãy xem MVP Quickstart của WebClient Software Factory như sau:

Setting PropertyBehavior with RhinoMock

2008-08-10T02:03:00.009+07:00

Ví dụ trên cho thấy ta không cần tạo một stub object để test, implement từ interface IAnimal. Thay vào đó, RMock sẽ tự động tạo cho ta. PropertyBehavior mục tiêu dùng để generate ra property Legs cho chúng ta sử dụng (dựa trên get/set của interface)

Sự khác biệt giữa Mocks và Stubs

2008-08-10T00:31:00.009+07:00

Khi được giới thiệu ban đầu, nhiều người dễ dàng lầm lẫn các mock object với các testing sử dụng sử dụng stubs. Xem hai dạng testing tôi sử dụng trong ví dụ bên dưới, cái đầu tiên sử dụng warehouse object thật sự, và cái thứ hai sử dụng một mock warehouse - và nó không phải là một warehouse object thật sự. Sử dụng mocks là một cách không sử dụng object thật sự khi test, nhưng cũng có những dạng khác sử dụng object giả giống như vậy.

Có một số từ rất dễ làm cho chúng ta rối, nó là: sub, mock, fake, dummy. Trong bài viết này tôi tham khảo trong cuốn sách của Gerard Meszaros. Meszaros dùng thuật ngữ Test Double như là một thuật ngữ chung, áp chỉ đến bất dạng object giả nào dùng để thay thế cho một object thiệt cho mục đích test. Tên của nó lấy từ khái niệm (notion) của Stunt Double trong phim. Meszaros sử dụng bốn dạng double riêng biệt:

Dummy objects là những object được dùng đến để làm cho pass một cái gì đó, nhưng không bao giờ được sử dụng, ví dụ như ta dùng nó để fill các parameter list.
Fake objects thật sự được sử dụng trong implementation, nhưng do nó được làm một cách vắn tất nên thường không thích hợp trong production (InMemoryTest database là một ví dụ).
Stubs cung cấp các câu trả lời được đóng sẵn (canned) đến các lời gọi hàm tạo ra trong suốt quá trình test, thông thường nó không trả ra kết quả chút nào ngoài những gì được lập trình để test. Stub cũng được dùng để lưu lại thông tin về những lời gọi, chẳng hạn như một email gateway stub có thể nhớ những message mà nó đã gởi, hoặc đã gởi bao nhiêu cái.
Mocks: là những objects được lập trình trước với mong muốn hình thành một đặc tả của những lời gọi hàm mà chúng mong muốn được nhận.

Trong những dạng double này, chỉ có mock khăng khăng dựa trên việc xác nhận behavior. Các double khác có thể, và thường là dùng xác nhân thông qua trạng thái (state). Mock thông thường hành xử như các double khác, chỉ khác trong giai đoạn setup và verification.

Xem ví dụ sau:

Chúng ta có thể sử dụng state verification trên stub như sau:

Sử dụng mock object để test thì hoàn toàn khác

Trong cả hai trường hợp, tôi đã dùng test double để test thay vì mail service thật sự. Sự khác biệt ở đây là stub sử dụng state verification trong khi mock sử dụng behavior verification. Để sử dụng state verification trong stub, tôi cần phải tạo thêm các method thêm vào để hỗ trợ việc test.

(tham khảo từ martin folwer)

MVP

2008-08-07T00:26:00.006+07:00

The Model
This is the data upon which the user interface will operate. It is typically a domain object and the intention is that such objects should have no knowledge of the user interface. Here the M in VP differs from the M in MVC. As mentioned above, the latter is actually an Application Model, which holds onto aspects of the domain data but also implements the user interface to manipulate it. In MVP, the model is purely a domain object and there is no expectation of (or link to) the user interface at all.

The View
The behaviour of a view in MVP is much the same as in MVC. It is the view's responsibility to displaythe contents of a model. The model is expected to trigger appropriate change notifications whenever its data is modified and these allow the view to "hang off" the model following the standard Observer pattern. In the same way as MVC does, this allows multiple views to be connected to a single model. One significant difference in MVP is the removal of the controller. Instead, the view is expected to handle the raw user interface events generated by the operating system (in Windows these come in as WM_xxxx messages) and this way of working fits more naturally into the style of most modern operating systems. In some cases, such as a TextView, the user input is handled directly by the view and used to make changes to the model data. However, in most cases the user input events are actually routed via the presenter and it is this which becomes responsible for how the model gets changed.

The Presenter
While it is the view’s responsibility to display model data it is the presenter that governs how he model can be manipulated and changed by the user interface. This is where the heart of an application's behaviour resides. In many ways, a MVP presenter is equivalent to the application model in MVC; most of the code dealing with how a user interface works is built into a presenter class. The main difference is that a presenter is directly linked to its associated view so that the two can closely collaborate in their roles of supplying the user interface for a particular model.

Why not MVC?

In MVC, most of the application functionality must be built into a model class known as an Application Model (see figure 1). It is the responsibility of the application model to be the mediator between the true domain objects and the views and their controllers. The views, of course, are responsible for displaying the domain data while the controllers handle the raw user gestures that will eventually perform actions on this data. So the application model typically has methods to perform menu command actions, push buttons actions and general validation on the data that it manages. Nearly all of the application logic will reside in the application model classes. However, because the application model’s role is that of a go-between, it is at times necessary for it to gain access to the user interface directly but, because of the Observer relationship between it and the view/controller, this sort of access is discouraged.

For example, let's say one wants to explicitly change the colour of one or more views dependent on some conditions in the application model. The correct way to do this in MVC would be to trigger some sort of event, passing the colour along with it. Behaviour would then have to be coded in the view to "hang off" this event and to apply the colour change whenever the event was triggered. This is a rather circuitous route to achieving this simple functionality and typically it would be avoided by taking a shortcut and using #componentAt: to look up a particular named view from the application model and to apply the colour change to the view directly. However, any direct access of a view like this breaks the MVC dictum that the model should know nothing about the views to which it is connected. If nothing else, this sort of activity surely breaks the possibility of allowing multiple views onto a model, which must be the reason behind using the Observer pattern in MVC in the first place.

Another irritating feature of MVC, at least with respect to Dolphin, was that the idea of a controller did not fit neatly into the Windows environment. Microsoft Windows, like most modern graphical operating systems, provides a set of native widgets from which user interfaces can be constructed. These "windows" already include most of the controller functionality embodied as part of the underlying operating system control. We found that, in order to create a sensible controller hierarchy, it was necessary to "break out" this inherent functionality and route it to various Controller subclasses. Even having done so, the ability to plug and play with these controller classes was severely limited by what the Windows OS would actually allow.
Eventually, we decided that this approach was not appropriate so we stripped these controller classes away leaving us with a mainly vestigial Controller hierarchy.

Benefits of MVP
So the effect of this "twist" is that the presenter, where the data manipulation part of a user interface is handled, is also allowed direct access to the view, where the data display is implemented. This can be very handy at times and is one of the most obvious benefits over MVC where the application model only has an indirect link to its associated view. The Dolphin implementation of MVP also manages to dispense with the idea of a controller, which seems to make the framework "fit" better with the underlying Windows operating system.

Compared with our original widget framework, MVP offers a much greater separation between the visual presentation of an interface and the code required to implement the interface functionality. The latter resides in one or more presenter classes that are coded as normal using a standard class browser. The window layouts for most applications are created using a tool known as the View Composer which is used to create an instance of the view required . These view instances are held in an internal binary form by a Resource Manager. Normally, one or more view instances can be associated with any presenter class and a presenter can specify which particular view is required when it is launched. Hence it is easy for an MVP application to have one or more "skins" that can be selected as required.

For example, the Dolphin development environment has three versions of the standard Class Hierarchy Browser which are all driven by the same ClassBrowserShell presenter class. We have the standard browser view, a simplified version for beginners (offering fewer options) and an alternative version where the class hierarchy is represented as a diagram rather than a standard tree view. This level of flexibility would not be possible with a framework based solely on widgets.

(reference from here)

TPS

2008-08-05T00:02:00.002+07:00

...

Taiichi Ohno, nhà lãnh đạo tinh thần của TPS, cho rằng hao phí lớn nhất là hao phí về sản xuất thừa. Nếu bạn làm ra một thứ mà bạn không thể bán được, thì công sức bạn bỏ ra sẽ mất đi. Nếu bạn làm ra một thứ dùng nội bộ trong dây chuyền mà không sử dụng chúng ngay lập tức, thì giá trị thông tin của chúng sẽ bốc hơi. Và bạn cũng tốn chi phí lưu trữ chúng: chuyển chúng vào nhà kho; theo dõi kho; lau chùi rỉ sét khi đem ra dùng lại; và sẽ gặp rủi ro nếu bạn không bao giờ dùng đến chúng nữa; trong trường hợp đó, bạn lại tốn chi phí để đem hủy bỏ chúng.

Có vô vàn hao phí về sản xuất thừa trong phát triển phần mềm: bộ tài liệu yêu cầu đồ sộ nhanh chóng bị lỗi thời; các kiến trúc phức tạp không bao giờ được dùng; các đoạn mã hàng tháng trời không được tích hợp, kiểm thử và chạy trên môi trường thực; và các tài liệu không ai muốn đọc cho tới khi chúng không còn thích hợp hay mất tác dụng. Bởi vì tất cả những hoạt động này đều quan trọng với phát triển phần mềm, chúng ta cần sử dụng đầu ra của chúng ngay lập tức; để nhận được các phản hồi cần thiết nhằm loại trừ hao phí.

Lấy ví dụ về việc thu thập yêu cầu. Nó sẽ không được cải tiến bởi một tá các qui trình thu thập yêu cầu phức tạp. Nó sẽ được cải tiến bằng cách rút ngắn đoạn đường giữa “việc tạo ra các yêu cầu chi tiết” và “việc triển khai các phiên bản phần mềm”. Sử dụng ngay lập tức yêu cầu chi tiết ngầm ý rằng thu thập yêu cầu không phải là một giai đoạn mà kết quả là một thứ tài liệu tĩnh; thu thập yêu cầu là hoạt động diễn ra suốt quá trình phát triển, nó sản xuất ra các chi tiết vừa ngay khi chúng được cần đến.

Có rất nhiều mặt của TPS tương đồng với phát triển phần mềm; những ý tưởng hữu ích chẳng hạn như: huấn luyện chéo giữa các công nhân, tổ chức nhà máy thành nhiều ô4, và lập các hợp đồng chia sẻ thành quả5 giữa khách hàng và nhà cung cấp. Nếu bạn có hứng thú, tôi khuyên bạn nên đọc quyển Toyota Production System của Ohno.

...
(copy to blog của Vĩ, Chapter 19. Toyota Production System)

TDD on Three Index Card

2008-06-25T18:24:00.005+07:00

Tim Ottinge trên Object Mentor có viết một bài về TDD khá thú vị, tên là TDD on Three Index Card

Card 1 - Uncle Bob’s Three Laws (Object Mentor)

Card 2 - FIRST Principles (Brett and Tim at Object Mentor)

Card 3 - Flow (using the famous three-node circle diagram) – origin unknown.

(reference http://blog.briandicroce.com/2008/03/14/three-index-cards-to-easily-remember-the-essence-of-test-driven-development/)

Agile design

2008-04-29T11:45:00.003+07:00

After reviewing the software development life cycle as I understood it, I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings.

Jack Reeves

Như vậy phát biểu của tác giả là gì? Code chính là design (không phải UML diagram)

Agile design là một quá trình, không phải là một sự kiện (event). Nó là việc áp dụng các nguyên tắc, pattern và practices liên tục để cải tiến cấu trúc và tính khả đọc (readability) của phần mềm. Nó là một sự cống hiến để giữ cho thiết kế của hệ thống càng sạch, đơn giãn và dễ hiểu (expressive) càng nhiều càng tốt trong tất cả các thời điểm.

Trong chương trước các bạn đã thấy, agile developer không áp dụng những nguyên tắc và pattern này cho design ngay từ ban đầu. Họ chỉ áp dụng nó từ iteration này đến iteration khác để bảo vệ các nguyên tắc ở trên ở thời điểm đó.

Design smells

Rigidity: cứng nhắc
Fragility: dễ vỡ, mỏng manh
Immobility: bất động, không đổi
Viscosity: nhớt, dính
Needless complexity: phức tạp không cần thiết
Needless repetition: lặp lại không cần thiết
Opacity: tối nghĩa

Why software Rots

2008-04-29T10:09:00.005+07:00

Tại sao phần mềm trở nên mục nát? (rot)
Trong một môi trường không agile (nonagile), thiết kế dần giảm giá trị theo thời gian khi requirements thay đổi không đúng với thiết kế ban đầu. Thường thường, các thay đổi này bị buộc làm một cách nhanh chóng và có thể được thực hiện bởi các developer không rành về lịch sử của các thiết kế ban đầu ấy.

Tuy nhiên, chúng ta không thể đổ lỗi cho sự thay đổi requirement là nguyên nhân dẫn đến việc giảm giá trị của thiết kế ban đầu. Chúng ta, là những lập trình viên phần mềm, biết rõ rằng những requirement đó thay đổi. Thật sự, hầu hết chúng ta đều nhận ra rằng chúng là các thay phần bất ổn định nhất trong dự án. Nếu thiết kế của chúng ta là gánh nặng cho các cơn mưa ”change request” ấy thì thiết kết và practices của chúng ta đã thất bại (xem phần phân biệt practices và principles trong eXtreme programming của Vĩ :-D). Chúng ta phải có một cách nào đó làm cho thiết kế trở nên linh động, đáp ứng đựoc những thay đổi đó và sử dụng các practices để bảo vệ chúng khỏi sự mục nát.

Một agile team phát triển dựa trên sự thay đổi. Team đầu tư không quá nhiều công sức ban đầu và không đặt hết gánh nặng cho thiết kế ban đầu. Hơn nữa, team sẽ giữ cho thiết kế của hệ thống càng trong sạch (clean) và đơn giản càng nhiều càng tốt, và “back up” với rất nhiều unit tests và acceptance tests. Việc này giúp cho thiết kết trở nên linh động và dễ thay đổi. Team tận dụng sự linh động đó để tiếp tục cải tiến design. Do đó, kết thúc mỗi interation thì thiết kế của hệt thống sẽ thích hợp với yêu cầu của iteration ở thời điểm đó.

Chương trình copy – Một ví dụ điển hình
Giả sử sếp đến gặp bạn vào buổi sáng sớm thứ hai, và yêu cầu viết một chương trình copy các ký tự từ keyboard đến máy in. Làm một vài bài động não trong đầu, bạn kết luận nó chỉ tốn ít hơn mười dòng code. Thiết kế và code chỉ tốn ít hơn 1 giờ. Công thêm các cuộc hợp về tính năng của chương trình, kiểm tra chất lượng, group process hằng ngày, và các thứ linh tinh khác nữa. Nó có thể làm cho bạn tốt khoảng một tuần để hoàn tất. Tuy nhiên, cuối cùng bạn luôn nhân các estimate này lên ba lần.

“Ba tuần”, bạn trả lời với sếp như vậy
Thiết kế ban đầu

Có ba module (hoặc gọi là chương trình con) trong ứng dụng. Copy module gọi hai module kia. Copy sẽ lấy các ký tự từ ReadKeyboard module và route chúng đến WritePrinter module.
Bạn nhìn vào design và cảm thấy chúng đủ tốt. Bạn mĩm cười và rời khỏi văn phòng.

Vào ngày thứ ba, bạn đến sớm hơn một chút để có thể hoàn tất chương trình Copy. Thật không may là bạn phải hỗ trợ debug một vấn đề cho đến 3 giờ chiều. Cuối cùng bạn quyết định ngồi code luôn chương trình Copy. Bạn nhận ra rằng mình đã trễ cho buổi họp quality theo kế hoạch, nói về tầm quan trọng của “zero defects”.

Chương trình Copy được viết như sau:

Vào ngày thứ tư, bạn đến sớm lần này và mọi thứ có vẽ không có gì sai nữa. Bạn lấy source code và biên dịch lần đầu không error. Đây là một tín hiệu tốt vì sếp bạn gọi vào họp đột xuất vì có nhu cầu giữ tone của máy in laser.

Vào ngày thứ năm, sau khi tốn 4 giờ trên gọi điện cho gã kỹ thuật ở Rocky Mount, miền nam Carolina, bàn luận về chương trình remote debugging và các lệnh logging, là một trong những component tối nghĩa trong hệ thống, bạn quyết định test chương trình copy. Nó chạy trong lần đầu tiên. Thật là tốt. Tên sinh viên làm chung vừa mới xóa source code trong thư mục trên server, và bạn phải tìm backup sau cùng và restore nó.

Thứ sáu là ngày hoàn toàn không dự tính trước. Bạn phải tốn cả ngày để load nó vào trong source control system.

Dĩ nhiên, chương trình của bạn đã thành công vang dọi và được deploy khắp công ty. Tên tuổi của bạn, một developer xuất sắc một lần nữa được khẳng định, và bạn đang đắm mình trong ánh hào quang vừa đạt được. Nếu bạn may mắn, bạn có thể chỉ code 30 dòng code như vậy trong năm nay!

Requirements - nó đang thay đổi
Vài tháng sau đó, sếp của bạn đi đến và nói rằng chương trình Copy nên đọc từ một thiết bị nữa là paper tape reader. Bạn nghiến răng và trừng mắt. Bạn tự hỏi tại sao người ta luôn luôn thay đổi requirements. Chương trình của bạn không được thiết kế cho một paper tape reader! Bạn cảnh báo cho sếp của bạn rằng các thay đổi như vậy đang phá hủy nét đẹp (elegance) của design. Tuy nhiên, sếp của bạn là người rất cứng rắn, cho rằng khách hàng thật sự cần làm việc đó.

Bạn thở dài và lên kế hoạch cho sự thay đổi. Bạn định thêm vào một argument Boolean đến hàm Copy. Nếu True, bạn đọc từ paper tape, nếu False, bạn đọc từ Keyboard. Không may là có quá nhiều chương trình khác đang sử dụng chương trình Copy bây giờ nên bạn không thể thay đổi interface được. Thay đổi interface có thể làm cho tốn từ tuần này đến tuần khác để compiling và retesting. Tester có thể sẽ hành hình bạn, không chỉ là 7 người trong nhóm configuration.

Không, thay đổi interface không được. Nhưng sau đó làm cách nào bạn có thể để chương trình Copy biết nó phải đọc từ đâu? Dĩ nhiên bạn sẽ dùng một biến toàn cục! Bạn dùng operator ?: như đoạn code sau:

Chương trình gọi chương trình Copy sẽ truyền ptFlag = true trước khi gọi từ nếu muốn đọc từ paper tape reader. Sau khi hàm Copy trả về, caller phải reset ptFlag; nếu không lần gọi tiếp theo có thể đọc sai từ paper tape reader hơn là keyboard. Nhớ rằng programmer phải có nhiệm vụ reset biến này, bạn phải thêm vào comment thích hợp cho họ. Một lần nữa, bạn release chương trình và được đánh giá rất cao. Hơn cả thành công trước kia nữa, và đám lập trình viên hớn hở đó đang đợi sử dụng nó. Cuộc sống thật tốt đẹp.

Thêm một chút nữa (give 'em an inch)
Vài tuần sau, sếp bạn nói rằng khách hàng đôi khi muốn chương trình Copy xuất ra "paper tape punch". Lại là khách hàng!. Họ luôn phá hủy thiết kế của bạn. Viết phần mềm sẽ dễ hơn nhiều nếu không có khách hàng. Bạn nói với sếp bạn rằng những thay đổi liên tục như vậy có ảnh hưởng xấu đến vẽ đẹp của thiết kế, và cảnh báo rằng nếu thay đổi liên tục ở nhịp độ kinh khủng như vậy, software sẽ không thể nào bảo trì được trước cuối năm. Sếp bạn gật đầu một cách có hiểu biết, nhưng dù sao vẫn bắt bạn thay đổi.

Thiết kế này được thay đổi giống như thay đổi của lần trước. Thêm một biến global và một operator ?: nữa.

Bạn đặc biệt tự hào vì mình vẫn nhớ để thay đổi comment. Tuy nhiên bạn vẫn lo lắng về cấu trúc của chương trình bắt đầu trở nên lung lay. Bất kỳ một thay đổi nào nữa của thiết bị input chắc chắn sẽ làm cho bạn thay đổi toàn bộ của trúc của vòng lặp while. Có lẽ đây là thời điểm thích hợp cho bạn phủi bụi resume, chuẩn bị để đi phỏng vấn.

Mong đợi sự thay đổi
Tôi để lại vấn đề trên cho bạn quyết định về mức độ châm biếm được cường điệu hóa ở trên. Điểm mấu chốt của câu truyện cho thấy làm cách nào design của chương trình dần dần giảm chất lượng khi có sự hiện hữu của thay đổi. Thiết kế ban đầu của chương trình Copy khá đơn giản và nhẹ nhàng (elegant). Nhưng chỉ sau 2 lần thay đổi, nó đã bắt đầu biểu lộ các dấu hiệu của sự cứng nhắc (rigidity), mỏng manh (fragility), bất động (immobility), phức tạp (complexity), thừa thãi (redundancy) và tối nghĩa (opacity). Xu hướng này có khả năng tiếp tục, và chương trình trở thành một đống hỗn độn (mess).

Chúng ta có thể ngồi lại và trách cứ những thay đổi này. Chúng ta có thể than phiền rằng các chương trình đã được thiết kế tốt cho specification ban đầu và các thay đổi tiếp theo của spec làm cho design bị giảm chất lượng. Tuy nhiên, chúng ta đã bỏ qua một trong những đặc trưng nỗi trội của phát triển phần mềm: Requirements luôn thay đổi.

Hãy nhớ rằng, một trong những thứ thay đổi trong software projects là requirements. Đây là một sự thật mà chúng ta, các developer phải chấp nhận. Chúng ta đang sống trong một thế giới thay đổi requirement, và nhiệm vụ của chúng ta là đảm bảo phần mềm của mình có thể tồn tại trước những thay đổi đó. Nếu thiết kế phần mềm của chúng ta giảm khi requirement thay đổi, chúng ta không agile.

Agile design của chương trình Copy
Một agile development team có thể bắt đầu theo cùng một cách, như đoạn code ở trên ban đầu. Khi sếp yêu cầu làm cho chương trình đọc từ paper tape reader, developer phải đáp ứng bằng cách thay đổi design để nó có thể co giãn (resilient) với những dạng thay đổi đó.

Thay vì cố gắng chắp vá thiết kế ban đầu để cho requirement mới chạy, team chộp cơ hội này để cải tiến design sao cho nó có thể đáp ứng được những dạng thay đổi này trong tương lai. Từ giờ trở đi, khi nào sếp bạn hỏi về một dạng thiết bị input mới, team sẽ có khả năng đáp ứng theo cách mà nó làm giảm chất lượng của chương trình Copy.

Design lại ở trên cho thấy team đã áp dụng nguyên tắc Open/Closed (OCP), được miêu tả ở chương 9 trong sách. Nguyên tắc này hướng dẫn chúng ta thiết kế module để nó có thể được mở rộng mà không cần phải sửa code cũ đang chạy. Mỗi một thiết bị input mới mà sếp yêu cầu hỗ trợ sẽ được cung cấp mà không cần phải sửa lại chương trình Copy.

Cần phải chú ý rằng, trong thiết kế ban đầu của module, team không có gắng đoán trước được chương trình sẽ thay đổi như thế nào. Thay vào đó, team đã viết module theo cách đơn giản nhất có thể. Chỉ khi nào requirement thay đổi thì team sẽ thay đổi design của module theo cách linh động theo dạng của thay đổi đó.

Chúng ta có thể tranh cãi rằng team chỉ làm mới có một nữa công việc. Trong khi developer đang bảo vệ chương trình khỏi các thiết bị input khác nhau, họ cũng có thể làm tương tự với các thiết bị output. Tuy nhiên team thật sự không có ý kiến về việc các thiết bị output có bị thay đổi hay không. Và cách thêm vào design cho output không phục vụ cho mục tiêu hiện tại nên nó không phải là lý do thật sự để chúng ta thêm vào nó bây giờ.

Tuân theo các agile practices
Agile developers trong ví dụ trên đã xây dựng một abstract class để ngăn chặn chúng khỏi sự thay đổi của các thiết bị input. Làm cách nào họ biết làm như vậy. Câu trả lời nằm trong một trong các nguyên lý cơ bản của thiêt kế hướng đối tượng.

Thiết kế ban đầu của chương trình Copy linh động vì hướng phụ thuộc các dependencies của nó. Figure design ban đầu ta thấy Copy module phụ thuộc trực tiếp vào KeyboardReader và PrinterWriter. Copy module là một module ở cấp cao trong ứng dụng này. Nó thiết lập các policy của ứng dụng. Nó biết làm cách nào để copy các ký tự. Không may là nó cũng phụ thuộc vào chi tiết của component ở mức thấp là keyboard và printer. Vì vậy, khi low-level thay đổi, high-level policy cũng bị ảnh hưởng.

Một khi sự không linh động xuất hiện, agile developer biết rằng sự phụ thuộc từ Copy module từ thiết bị input cần phải được đảo lại, sử dụng Dependency Inversion (DIP) trong chương 11, để cho Copy module không còn phụ thuộc vào thiết bị input nữa. Sau đó họ có thể dùng STRATEGY pattern, để tạo ra inversion mong muốn.

Túm lại, agile developer biết cách làm gì bởi vì họ tuân theo các bước sau:

Phát hiện ra các vấn đề bằng cách tuân theo các agile practices
Phân tích (diagnosed) vấn đề bằng cách áp dụng các design principles
Giải quyết vấn đề bằng cách áp dụng các design pattern thích hợp

Giữ cho thiết kế tốt nhất có thể
Agile developer phải luôn giữ design ban đầu thích hợp (approriate) và sạch sẽ tốt nhất có thể. Đây không phải là một lời cam kết ngập ngừng và bừa bãi. Agile developer không "clean up" design mỗi tuần. Hơn thế nữa, họ giữ cho software càng sạch, đơn giản và có nghĩa (expressive) như nó tốt nhất có thể trong mỗi ngày, mỗi giờ và mỗi phút. Họ không bao giờ nó "Chúng ta sẽ về nhà và fix nó sau". Họ không bao giờ để cho sự mục nát có cơ hội bắt đầu.

Quan điểm của agile developer hướng về design của software cùng với quan điểm mà các bác sĩ phẫu thuật hướng về quá trình vô trùng (sterile procedure). Quá trình vô trùng để cho cuộc giải phẩu xảy ra. Không có việc vô trùng, rủi rõ của việc nhiễm trùng sẽ lên cao. Agile developer có cảm giác tương tự về thiết kế của họ. Rủi ro của việc để cho một sự mục nát nào đó dù nhỏ nhất sẽ làm cho sự gánh chịu nhiều hơn về sau.

Thiết kế phải sạch (clean). Và vì source code là diễn tả quan trọng nhất của design, nó phải sạch. Các nhà chuyên nghiệp chỉ ra rằng, chúng ta, là các software developer, không thể chịu đựng code của mình bị mục nát (rot).

Scope chain and [[scope]]

2008-04-15T13:43:00.006+07:00

(tiếp theo bài trước)

Scope chain của một execution context cho một lời gọi hàm được xây dựng bằng cách thêm object Activation vào trước chain của property [[scope]] của function object.

Trong ECMAScript, function là các object. Chúng được tạo ra trong suốt quá trình khởi tạo biến trong khai báo hàm hoặc trong evaluation của function expression hoặc gọi Function constructor.

Function object được tạo ra bởi constructor luôn có một [[scope]] property trỏ đến scope chain chỉ có một global object. Function object đựoc tạo ra bởi khai báo hàm hoặc function expression có một scope chain của execution context trong đó chúng được tạo ra gắn với [[scope]] property bên trong của chúng.

function exampleFunction(formalParameter) {
// function body code
}

Ví dụ này cho thấy function object tương ứng sẽ đựoc tạo ra trong suốt quá trình khởi tạo biến cho global execution context. Global execution context sẽ có một property tên là "exampleFunction" và trỏ đến một object gọi là function object. Function object này có một property bên trong là [[scope]] trong đó trỏ đến một scope chain chỉ có một global object.

var exampleFunctionRef = function() {
// ....
}
trong trường hợp này, một property của global object được tạo ra nhưng function object chưa được tạo, và một tham khảo đến nó được gán đến property này của global object cho đến khi quá trình assignment expression được thực thi. Nhưng quá trình tạo function object vẫn diễn ra bên trong global execution context nên [[scope]] property của function object này chỉ trỏ đến global object.

function exampleOuterFuction(formalParameter) {
function exampleInnerFunctionDec() {
//
}
}
exampleOuterFunction(5);

Function object của outer function được tạo ra trong quá trình khởi tạo biến của global object, và trong global context nên scope chain của nó chỉ chứa global object. Khi global code gọi hàm exampleOuterFunction, một execution context mới được tạo ra cùng với một Activation/Variable object. Scope cho context này bao gồm Activation object mới đó, theo sau là chuỗi các object của [[scope]] property của outer function.

Để dễ hiểu hơn, ta xem một số minh họa sau:

(từ Scott Allen)
Trong hình trên, vùng ngoặc vuông màu đỏ diễn tả cho scope, vòng tròn màu đỏ diễn tả cho Activation object, còn mũi tên xanh diễn tả scope chain.

Hoặc một diagram khác

(theo http://www.jibbering.com/faq/faq_notes/closures.html)

Javascript execution context

2008-04-15T12:59:00.001+07:00

The Execution Context

Execution context là một khái niệm trừu tượng, được đặc tả bởi ECMSScript specification (ECMA 262 3rd edition). Nó có thể được xem như là các objects cùng với những properties (nhưng không phải là public properties).

Tất cả các javascript code được executed trong một execution context. Global code (code được execute inline, hoặc trong JS file, hoặc HTML page...) được execute trong global execution context và mỗi một lời gọi hàm sẽ có một conetxt object đi kèm với nó. Code được execute bằng hàm eval cũng có một execution context riêng, nhưng vì eval không thường được sử dụng bởi javascript programmer nên nó sẽ không được discuss ở đây. (các bạn có thể xem đặc tả của nó trong section 10.2 của ECMA 262)

Khi một javascript function được gọi, nó bước vào một execution context. Nếu một function khác được gọi (hoặc gọi lại chính nó theo cách gọi đệ quy) thì một execution context mới sẽ được tạo ra và lời gọi hàm sẽ enter vào context đó cho đến khi nó trả ra kết quả. Việc này dẫn đến javascript code hình thành nên một stack các execution context trong quá trình gọi.

Khi một execution context được tạo ra, một số việc sẽ xảy ra theo một thứ tự được định nghĩa trước. Đầu tiên, trong execution context của một function, một "Activation" object được tạo ra. Activation object này là một cơ chế đặc tả khác. Nó có thể được xem như là một object vì nó có các properties có thể truy xuất được. Nhưng nó không phải là một object bình thường vì nó không có prototype và không thể được reference trực tiếp bằng javascript code.

Bước tiếp theo của việc tạo ra execution context cho một lời gọi hàm là việc tạo ra argument object, là một object giống như array với các index là các số interger tương ứng với thứ tự của các parameter được truyền vào. Nó cũng có length và callee property. Một property của Activation object được tạo ra với tên là "arguments" và trỏ đến object này.

Bước tiếp theo execution context được gán vào một scope. Scope bao gồm một danh sách (hoặc một dây - chain) các objects. Mỗi function object có một property bên trong tên là [[scope]] và nó cũng chứa một danh sách các object. Scope gán cho execution context cho một function là một danh sách được tham khảo bởi [[scope]] property của function object đó với một chút thay đổi là Activation object sẽ được thêm vào đầu tiên của danh sách.

Quá trình khởi tạo các variables diễn ra bằng cách sử dụng một object gọi là "Variable" object (tham khảo ECMA 262 phần khởi tạo biến 10.1.3). Thật sự, Activation object và Variable object là một (!!!). Các properties được đặt tên cho Variable object được tạo ra cho mỗi parameters của function, và nếu các arguments của lời gọi hàm tương ứng với các các parameters này, giá trị của chúng sẽ được gán cho các properties của Variable object (các giá trị default sẽ là undefined). Các inner function được định nghĩa bên trong sẽ tạo ra các function objects và được gán thành các properties của Variable object với tên tương ứng là tên của các inner function. Bước cuối cùng trong quá trình khởi tạo biến là tạo ra các properties với tên tương ứng với các local variables được khai báo bên trong function.

Các properties được tạo trên Variable object tương ứng với các biến cục bộ được khai báo bên trong hàm ban đầu sẽ được gán giá trị là undefined, sau đó việc khởi tạo thật sự sẽ diễn ra trong quá trình evaluation của assignment expression bên trong thân hàm.

Sự kiện Activation object - cùng với property arguments của nó - và Variable object - cùng với các properties có tên tương ứng các local variables - cùng chỉ đến một object cho phép arguments được đối xử như là biến local của function.

Cuối cùng, nếu một giá trị được gán đang tham khảo đến một object mà sau đó các tác vụ truy xuất property có prefix là keyword this, thì nó sẽ dùng giá trị của object đó. Nếu không có từ khóa this hoặc giá trị được gán là null (tức là không nằm trong một object nào đó), nó sẽ refer đến global object.

Global execution context có một vài khác biệt nhỏ vì nó không có arguments nên nó không cần phải có một Activation object tham khảo đến nó. Global execution context thật sự cần một scope và scope chain của nó chỉ chứa một object, đó là global object. Trong quá trình duyệt để khởi tạo biến của global object, nó sẽ được dùng như một Variable object, do đó các biến toàn cục (hoặc các hàm top-level function) sẽ được tạo thành các properties với cùng tên, giống như mô tả ở trên.

Why UML?

2008-04-11T17:20:00.002+07:00

(copied from blog của Vĩ)
(from chapter2 - UML for java programmer)

Tại sao phải Mô Hình
Tại sao các kỹ sư làm mô hình? Tại sao các kỹ sư hàng không tạo mô hình máy bay? Tại sao kỹ sư cầu đường làm mô hình cây cầu? Mục đích của những mô hình này là gì?

Kỹ sư làm mô hình để xác định xem liệu thiết kế của họ có hoạt động chính xác không? Kỹ sư hàng không làm mô hình máy bay và đưa chúng vào các ống gió (wind tunnel) để xem chúng có bay được không. Kỹ sư cầu đường tạo mô hình cây cầu để xem chúng có đứng vững hay không. Kiến trúc sư xây dựng mô hình các tòa nhà để xem khách hàng có thích kiểu dáng như thế không. Mô hình được tạo để xác định xem một vật nào đó có hoạt động không.

Điều này ẩn chứa ý rằng mô hình có thể kiểm thử được. Thật là vô nghĩa khi tạo mô hình mà bạn không có cách nào để thực hiện các phép kiểm thử trên nó. Nếu bạn không định lượng được mô hình, thì mô hình đó không có giá trị.

Tại sao kỹ sư hàng không không chế tạo ra máy bay và lái thử nó? Tạo sao kỹ sư cầu đường không cho xây cây cầu rồi mới xem chúng có đứng vững không? Bởi vì máy bay và cây cầu đắt hơn rất nhiều so với mô hình. Chúng ta nghiên cứu các thiết kế bằng cách làm mô hình nếu như việc làm mô hình rẻ hơn nhiều lần so với việc chúng ta tạo ra vật thể thực.

Tại sao tạo mô hình phần mềm?
Liệu có thể kiểm thử các lược đồ UML? Liệu tạo các lược đồ UML có rẻ hơn và dễ kiểm thử hơn cái phần mềm mà nó biểu diễn? Trong cả hai tình huống, câu trả lời không bao giờ rõ ràng như lĩnh vực hàng không và cầu đường. Không có phương pháp chắc chắn nào để kiểm thử các lược đồ UML. Chúng ta có thể nhìn chúng, định lượng chúng, áp dụng các nguyên tắc thiết kế và các mẫu thiết kế lên chúng, nhưng kết quả của việc đánh giá chúng vẫn rất chủ quan. Vẽ lược đồ UML thì dễ hơn là viết phần mềm, nhưng với hệ số không lớn. Thật vậy, thay đổi mã nguồn dễ hơn rất rất nhiều lần so với việc thay đổi một lược đồ. Như vậy dùng UML liệu có hợp lý không?

Tôi đã không viết một quyển sách về UML nếu như dùng nó là không hợp lý. Tuy nhiên, những lập luận trên nhằm giải thích rằng UML rất dễ bị dùng sai mục đích. Chúng ta sử dụng UML khi chúng ta có một thứ gì đó mà chúng ta dứt khoát phải kiểm thử nó, và khi dùng UML để kiểm thử thì rẻ hơn là dùng mã nguồn để kiểm thử nó.

Ví dụ, nói rằng tôi có một ý tưởng cho một thiết kế nào đó. Tôi muốn kiểm tra rằng liệu những thành viên trong nhóm của tôi có cho rằng đấy là một ý tưởng đúng đắn. không. Vì vậy tôi vẽ lược đồ UML lên bảng và hỏi thành viên trong nhóm để nhận phản hồi.

Tại sao chúng ta tạo các thiết kế đầy đủ trước khi lập trình?
Kiến trúc sư, kỹ sư hàng không, kỹ sư cầu đường luôn vẽ các bản vẽ thiết kế (blueprint)? Tại sao? Bởi vì một người có thể vẽ bản thiết kế cho một ngôi nhà mà để xây nó cần đến năm người hoặc hơn. Khoảng một chục kỹ sư hàng không có thể vẽ bản thiết kế cho chiếc máy bay mà để chế tạo nó phải cần hơn cả ngàn người. Có thể vẽ bản thiết kế mà không cần phải đào móng, không cần phải trộn bê tông hay lắp cửa sổ.... Nói ngắn gọn, lập một kế hoạch xây dựng trước sẽ rẻ hơn nhiều so với việc xây dựng mà không có kế hoạch nào. Và nó sẽ không tốn nhiều chi phí khi bỏ đi những bản vẽ tồi, nhưng sẽ tốn rất nhiều nếu giựt sập một tòa nhà.

Một lần nữa, điều này lại không rõ ràng khi áp dụng cho phần mềm. Vẽ các lược đồ UML không thực sự rẻ hơn là viết mã nguồn. Thật vậy rất nhiều nhóm đã tiêu tốn nhiều thời gian trên lược đồ hơn là ngồi làm việc thực sự trên mã nguồn. Và việc ném bỏ các lược đồ không thực sự rẻ hơn là ném bỏ những đoạn mã. Vì vậy việc tạo một bộ đầy đủ các lược đồ UML trước khi viết code không thực sự là chọn lựa hiệu quả về chi phí.

Aspect#

2008-04-06T00:48:00.013+07:00

Một ví dụ

Giả sử bạn đang làm một dự án nào đó. Bạn đang tạo ra một CMS mang tính cách mạng và sắp hoàn tất với một mô hình object model đẹp và đơn giản. Các component quan trọng implement interface IContentProvider và IView. IContentProvider chịu trách nhiệm thu thập thông tin từ các nguồn như database, xml, rss, excels. IView chịu trách nhiệm hiển thị thông tin theo một cách nào đó cho một kênh thông tin riêng biệt nào đó.

Mọi thứ đang tốt đẹp và hầu hết đã làm xong với cả ngàn ContentProviders và Views, cover tất cả các communication channels. Bất ngờ, the sale guy - luôn luôn là họ :-) - đến, với quan điểm của anh ta, và với một requirement không quan trọng. Anh ta cần security checking cho các provider và view, và anh ta đã bán nó cho một khách hàng quan trọng, vd như BBC. Tương lai của công ty bạn phụ thuộc vào việc nó có hoàn tất vào cuối ngày hôm nay hay không.

Các giải pháp có sẵn

Bạn cần phải expose các object ra như là một securable resource cho security framework. Để làm nhẹ đi gánh nặng phải thay đổi mỗi ContentProvider và View, bạn nghĩ đến một số giải pháp có thể sau đây:

Tạo ra một property trên IContentProvider và IView, để show thông tin của IResource
Tạo ra một 'IResourceable' và làm cho IContentProvider và IView mở rộng từ nó. Sau đó sửa chữa base class của chúng, mặc dù bạn không chắc một base class như vậy có tồn tại hay không.
Bạn đang ở tầng 9, vì vậy nhảy ra khỏi cửa sổ có thể giải quyết vấn đề trong chốc lát...

Vấn đề với những giải pháp trên là nó sẽ làm rối mô hình object đẹp và sạch sẽ của bạn. Trong khái niệm security của bạn, không có cái gì phải làm với content providers và view. Do đó, dễ hiểu nhất là bạn thích dùng một ISecurityResource interface và implement nó.

Coi nào, bạn chỉ có một vài giờ. Hãy bắt đầu modify những component này. Không cần phải gấp lắm, hãy dùng AOP để giải quyết nó.

Giải pháp kết hợp (mixin solution)

Đầu tiên, bạn sẽ làm cho tất cả các ContentProvider trong một namespace nào đó phải bao gồm một interface implement ISecurityResource, ví dụ:


public class SecurityResourceImpl : ISecurityResource
 {
       public SecurityResourceImpl()
       {
       }

       public String ResourceName
       {
             get { return "Content"; }
       }
 }

Chúng ta sử dụng một build-in language (giống Ruby) để cấu hình aspect đó. Chúng ta giữ cấu hình này trong một config file, hoặc trong code (not recommended). Ví dụ


import YourCompany.CMS.ContentProviders in YourCompanyAssembly
 aspect SecurityAspect for RSSContentProvider
     include Mixins.SecurityResourceImpl in MyMixinsAssembly
 end

Ví dụ trên làm cho RSSContentProvider sẽ có một ISecurityResource interface được implement bởi SecurityResourceImpl

Thay vì chỉ định một class, ta có thể chỉ định tất cả các class trong một namespace cho trước.


import YourCompany.CMS.ContentProviders in YourCompanyAssembly
 aspect SecurityAspect for [ YourCompany.CMS.ContentProviders ]
   include Mixins.SecurityResourceImpl in MyMixinsAssembly
 end

Aspect# engine sẽ làm việc này:


StreamReader reader = new StreamReader( configfile );
AspectEngineBuilder builder = new AspectLanguageEngineBuilder(reader);

AspectEngine engine = builder.Build();
RSSContentProvider provider = engine.Wrap( new RSSContentProvider() );

Chuyện gì xảy ra nếu security resource cần phải truy xuất một vài thứ từ content provider hoặc từ view? Ta phải implement thêm interface IProxyAware


public class SecurityResourceImpl : ISecurityResource, IProxyAware
 {
        private String _name;
 
        public SecurityResourceImpl()  
        {  
        }
 
        public void SetProxy(object proxy)  
        {  
                if (proxy is IContentProvider)  
                {  
                        Name = (proxy as IContentProvider).Name;  
                }  
                else if (proxy is IView)  
                {  
                        Name = (proxy as IView).Name;  
                }  
        }
 
        public String Name  
        {  
                get { return _name; }  
                set { _name = value; }  
        }
 
        public String ResourceName  
        {  
                get { return Name; }  
        }  
  }

Intercepting Invocation

Làm cách nào để khi gọi hàm RetrieveContent trên interface IContentProvider, nó gọi ISecurityResource.Demand() để thực hiện security check.

Đầu tiên ta cần một pointcut để chọn các method và property. Bên trong một pointcut, ta có thể chọn các advice và thực hiện một vài action trên joinpoints. Có một số thuật ngữ mới như sau:

Pointcut: chọn các method và|hoặc property bên trong một kiểu
Joinpoints: method hoặc property match pointcut
Advice: đoạn code sẽ được thực hiện trước|sau khi joinpoint

Ví dụ trên được cấu hình như sau:


import YourCompany.CMS.ContentProviders in YourCompanyAssembly
import YourCompany.CMS.Aop.Interceptors
 
 aspect SecurityAspect for RSSContentProvider
      include Mixins.SecurityResourceImpl in MyMixinsAssembly
 
      pointcut method(* RetrieveContent(*))
            advice(SecurityCheckInterceptor)
      end
 end

pointcut ở trên cho thấy "nó không quan tâm đến kết quả trả về, cũng như parameter của hàm RetrieveContent". SecurityCheckInterceptor được implement như sau:


public class SecurityCheckInterceptor : IMethodInterceptor
 {
    public object Invoke(IMethodInvocation invocation)
    {
        ISecurityResource target = invocation.GetThis() as ISecurityResource;
        target.Demand(); // Can throw a SecurityException
 
        return invocation.Proceed(); // All right, get on with it
    }
 }

(from http://www.castleproject.org/AspectSharp/documentation/trunk/tutorial/basic.html)

yield

2008-04-02T23:50:00.004+07:00

WF questions

2008-03-08T00:26:00.002+07:00

10 câu hỏi về workflow được tổng hợp và trả lời khá thú vị của Scott Allen

1/ Thuận lợi và khó khăn khi chỉ sử dụng XAML để build workflow
2/ So sánh ExternalDataExchange service với sử dụng trực tiếp WorkflowQueueingService
3/ Khi nào dependency property hữu ích trong lập trình wf
4/ Behavior mặc định của scheduling service là gì
5/ Tại sao ta phải sử dụng database transaction cùng với một workflow instance
6/ Tại sao ta phải sử dụng tracking service
7/ Nêu một scenario khi cần phải cancel một executing activity
8/ Nêu một scenario khi ta cần phải sinh ra một executing context mới
9/ Tại sao ta phải sử dụng một compensation handler
10/ Mô tả các activity sau: Replicator, Parallel, Policy

(reference here)

VS 2008 Training Kit

2008-03-08T00:23:00.002+07:00

Nếu ai là dân dốt nát thì không thể bỏ qua cái này. Download here: http://go.microsoft.com/?linkid=7602397

Deconstructing WF (2)

2008-02-13T01:19:00.001+07:00

tiếp theo bài trước

Trở lại chương trình HelloWorld ở bài trước, thay vì tạo BookMark tên Read, ta refactoring lại để nó tạo một ProgramStatement thực hiện việc Read (đúng bản chất động từ hơn là danh từ)

ProgramStatement là một abstract class mà các activity phải implement

Quan sát hai class Read và OpenSesame đều implement ProgramStatement, ta thấy có một sự tương đối trong việc định nghĩa activity. Một activity có thể duy nhất hoặc bao gồm các activity khác. Từ đó xuất hiện khái niệm ProgramStatementBlock (sau này gọi là CompositeActivity)

ProgamStatementBlock có thể được thực hiện từ tuần tự (Sequence), hoặc đồng thời (Interleave) hoặc thực hiện theo một số điều kiện nào đó (Control flow: IfElse, While, ...) tùy theo chúng ta phát triển.

Tương tự như vậy ta viết tiếp ProgramStatement cho PrintKey, PrintGreeting. Chú ý là các class này không cần phải add vào bookMarkManager vì nó không cần chờ đợi user input data, ví dụ:

Môi trường chạy bây giờ như sau:

Deconstructing WF

2008-02-06T14:45:00.000+07:00

from chapter 1 - Essential Windows Workflow Foundation

Một cuốn sách viết khá hay của tác giả Dharma Shukla, về bản chất bên trong của WF.

Xuất phát từ một ví dụ cơ bản

tác giả dẫn dắt và mở rộng ra thành một workflow framework rất thú vị.

Sample code ban đầu như sau:

Ứng dụng gồm có ba bước:

In ra màn hình một key random
Chờ đợi user input một key (được viết tối ưu bằng cách đưa nó ra một thread riêng)
Nếu user input key bằng với key của bước 1, sẽ in ra câu hello world, nếu không sẽ exit, kết thúc flow

Chúng ta nhận thấy rằng ở bước hai có thể kéo dài rất lâu, hàng tuần nên nó cần được lưu lại ở một data storage nào đó. Khi nhận được user input, nó sẽ activate lại và chạy tiếp bước thứ ba.

Hàm ContinueAt ở trên có thể xem là một BookMark (delegate được đặt tên) cần được lưu lại, và quản lý bởi BookMarkManager

Đoạn code trên cho thấy việc chờ đợi userInput trong hàm Readline() không còn là nhiệm vụ của nó nữa. Bằng cách nào đó BookMarkManager hoặc môi trường ngoài phải có nhiệm vụ nhận user input và gọi lài hàm ContinueAt đã đăng ký ở trên.

Từ đây cũng manh nha ý tưởng về một hoạt động cơ bản nhất của một chương trình (sau này gọi là Activity trong workflow)

Môi trường chạy sẽ chờ nhận input, biết được input đó thuộc chương trình nào và resume chương trình đó lên để chạy tiếp các bước sau

Develop custom controls with complex properties

2008-01-13T16:28:00.001+07:00

(from chapter 7 - Prof. Asp.Net Server controls)

Chương này tác giả đề cập đến các custom controls phức tạp, có thể gây khó khăn cho việc maintain trạng thái và apply style cho các control con.

Bài viết về state management khá hay. Sau đây là một số trích dẫn:

Lưu trữ trạng thái của các object là một vấn đề trong web application, vì một user session có thể chứa nhiều hơn một request. Do đặc điểm của HTTP, nên object sẽ bị disposed vào cuối mỗi request, cho dù session vẫn cần object đó.

ASP.Net view state cho phép ta lưu trạng thái của object vào cuối mỗi request và load lên trở lại vào đầu của request sau. Request tiếp theo sẽ làm như sau:

Tạo ra object mới có cùng kiểu như là object đã bị displosed vào thời điểm cuối của request trước đó.
Load trạng thái của object cũ vào object mới.

Cơ chế hoạt động của asp.net như sau: Mỗi server control thừa kế 3 method là TrackViewState, SaveViewState và LoadViewState từ class Control base. Vào cuối mỗi request:

Page tự động gọi hàm SaveViewState method của các control trong Controls collection.
SaveViewState của mỗi control sẽ save trạng thái của control và của các control con của nó, sau đó trả về object.
Page thu thập các object được trả về từ SaveViewState method của các controls và tạo ra một tree các object gọi là object graph.
Page framework convert các object thành từng string và kết hợp với nhau thành một string duy nhất để diễn tả toàn bộ object graph.
Page framework lưu trữ string này trong một hidden field, gọi là __VIEWSTATE

Khi page được post back về server:

Page framework nhận string từ __VIEWSTATE và extract ra các string diễn tả mỗi object, sau đó tạo lại object từ string đó.
Page framework gọi hàm LoadViewState cho mỗi control trong Controls collection, và truyền các object tương ứng được tạo ở trên vào.
Hàm LoadViewState của mỗi control sẽ load content của control của lần request trước đó vào trong nó. Như vậy là nó đã có cùng trạng thái với request trước đó.
Page framework gọi hàm TrackViewState của mỗi control để chỉ rằng nó đang tracking trang thái. Từ thời điểm này trở đi, mọi thay đổi trạng thái của object sẽ được make dirty và nó sẽ được save vào ở cuối của request.

Colour Schemas

2008-01-09T09:12:00.000+07:00

from Design for Web developers

Basic terms

Hue: màu nguyên chất (undiluted color, true color)

Saturation: độ sáng của một màu (intensity or purity), diễn tả mức độ nguyên chất của màu đó. Nếu ta pha thêm một chút đen hoặc trắng sẽ làm thay đổi độ nguyên chất ấy.

Value: độ sáng và tối của một màu

Tint: màu xuất hiện với sự hiện diện của màu trắng, làm cho màu sáng hơn (vd: pink là tint of red)

Shade: màu xuất hiện với sự pha trộn của màu đen, làm cho nó tối hơn

(add white to blue - tint)

(add black to blue -shade)

Monochromatic schema
Là tất cả các màu được mở rộng từ một màu đơn bằng cách thay đổi yếu tố tints và shades của nó (hoặc là black and white)

Hình bên dưới cho thấy sự thay đổi màu sắc khi thay đổi các thành phần black (shades, bên trái) và white (tints, bên phải).

Trong photoshop, ta có thể thay đổi schema bằng các giá trị S (saturation) và B (brightness) trong màu HSB.

Hello world module in DNN

2007-12-30T12:34:00.000+07:00

Cuối cùng cũng có thời gian rảnh ngồi viết cái thử cái module HelloWorld trên DNN.

Logic của module như sau:
- Anonymous vào sẽ hiện ra câu message default: Hello World
- Registered user sẽ thấy câu chào: Hello $userName + bên dưới có một button để customize câu welcome message.

Do source code của DNN viết bằng VB.Net (đặc biệt là trong App_Code folder) nên muốn viết bằng C# ta phải tạo một project riêng (dạng class library) và được reference vào từ portal (nếu muốn import module trong đó).

Cấu trúc của project

Message class tương ứng với data sẽ persistent xuống database (chú ý property trong object phải giống với field name trong table của database). Đối với mỗi message được customize, thông tin tối thiểu nhất cần phải có là: moduleId (dùng để phân biệt giữa các module), userId (kiểu int) và welcomeMessage.

HelloWorld service

Bây giờ tạo GUI cho module. Open source code của DNN. Trong folder DesktopModules tạo một folder tên HelloWorld, sau đó add vào 2 user controls là ViewHelloWorld.ascx (dùng để welcome user) và EditHelloWorld.ascx (dùng để customize message).

Trang ViewHelloWorld sẽ kiểm ra user xem đã sign in hay chưa, nếu đã sign in rồi thì lấy custom message ra để show, nếu không thì dùng default message.

"helloWorld2" là key của trang EditHelloWorld khi add control vào trong module

Developing custom templated control

2007-12-04T00:12:00.000+07:00

(from chapter 6 - Prof ASP.NET Server Controls)

Chương này hướng dẫn cách tạo sử dụng template trong control và data binding trong template đó.

Để expose một template, ta public một property có kiểu là ITemplate, và trong hàm CreateChildControls(), gọi hàm InstantiateIn trên property đó nếu nó tồn tại.

Ta viết một ví dụ template control hello-world như sau: nó là một place holder cho phép người dùng đặt bất kỳ template nào bên trong.

Như đoạn code ở trên, ta thấy data binding vào một property thật ra là gọi giá trị của property trên container template. Khi gọi hàm InstantiateIn, ASP.NET framework thực hiện các bước sau:

Tự động tạo ra một component hoặc class thừa kế interface ITemplate vàimplement hàm InstantiateIn của interface đó.
Tự động compile class này và assign instance của nó đến property template tương ứng của control.

Ví dụ nếu có template như sau:

thì class được generate tự động:

do đó, sau khi hàm InstantiateIn được gọi xong, thì container đã chứa control được generate bởi asp.net

YetAnotherForum in DNN

2007-11-17T10:46:00.000+07:00

Lò mò 1 ngày cũng cái được cái YetAnotherForum thành một module của DNN.

Đọc gần hết cuốn sách mà thấy DNN vẫn chưa có gì hấp dẫn, ghet VB :-(

Hibernate: Hello World

2007-11-13T00:34:00.000+07:00

(from chapter 2 - Java persistent with Hibernate)

Chương này hướng dẫn cách integrate Hibernate vào trong java application (nhưng ta sẽ test nó trên .net). Bắt đầu bằng ví dụ kinh điển: "Hello World".

Có lẽ đây là ví dụ Hello World khó chịu nhất mà mình từng viết. Tuy đã từng viết 1 cái sample trên asp.net lâu rồi mà bây giờ ngồi viết vẫn gặp khó khăn.

configuration file

mapping file

Cái hay của lần viết này là hibernate sẽ dựa vào mapping file trên persistent object để export ra schema cần thiết của database (tạo table trong database luôn). Đây là một cách tiếp cận đúng chuẩn và lý tưởng nhất cho một developer.

Ví dụ này tạo một message "hello world" và lưu nó xuống database. Persistent class Message bao gồm: Id, Text và một reference đến một message khác (conferToMessage)

Ta thấy các attribute của Message được diển tả bằng các property trong class Message. Constructor no-argument là một yêu cầu bắt buộc đối với Hibernate vì nó sử dụng reflection với constructor này để khởi tạo object.

Message không cần phải implement một interface nào của Hibernate nên ta có thể dùng nó như các entity class khác, ví dụ:


Message message = new Message("Hello world");
Console.Writeline(message.Text);

Đây là một tính năng quan trọng của Hibernate, giúp nó khác biệt với các persistent solutions khác: đó là persistent class có thể được dùng trong bất kỳ execution context nào, không cần một container đặc biệt nào khác.

Thông thường, developer đầu tiên sẽ phân tích business domain dưới góc nhìn object-oriented và thường chịu ảnh hưởng nhiều của một mô hình cơ sở dữ liệu quan hệ có sẵn: là một legacy database hoặc một schema được design bởi một data modeler. Một số câu hỏi cần phải trả lời:

Ta có thể start từ một clean design, từ legacy data hoặc từ legacy application code?
Có phần code nào có thể được generate một cách tự động từ phần đã có sẵn (ví dụ java source được generate từ một database schema). Hoặc database schema được generate từ java code và Hibernate mapping metadata?
Công cụ nào hỗ trợ cho việc trên?

Roadmap:

Chọn một mô hình phát triển (development process)
Tạo ra project infrastructure (cơ sở hạ tầng của project)
Viết application code và mappings
Configure và start Hibernate
Chạy ứng dụng.

Development process

Topdown
Bottom up
Middle out
Meet in the middle

Understanding object/relational persistence

2007-11-13T00:33:00.000+07:00

from chapter 1 - Java Persistence with Hibernate (Manning)

Chương này đề cập đến các vấn đề persistence mismatch giữa object-oriented software development và relational database.

Persistence được đề cập mang ý nghĩa:

Lưu trữ, phân loại và truy xuất dữ liệu có cấu trúc
Đồng bộ và toàn vẹn dữ liệu
Data sharing

Một số mismatch được liệt kê như sau:
1/ Quan hệ một - nhiều

Một User có nhiều BillingDetails.

Trong object-oriented ta khai báo 2 class User và BillingDetails, trong đó User chứa một tập các billingDetails (list, set), còn BillingDetails reference đến User owner của nó.

Trong relational database thì ta sẽ dùng khóa ngoại, trong đó BillingDetails sẽ chứa userID - là khóa ngoại chỉ đến bảng User.

2/ Subtype problem (granularity)
Relational database không hỗ trợ thừa kế như hướng đối tượng. Ví dụ BillingDetails sẽ bao gồm hai loại là CreditCard và BankAccount

3/ Identity problem
Object trong hướng đối tượng có 2 kiểu bằng nhau:

Giống nhau hoàn toàn, ngay cả bộ nhớ cấp phát (a == b)
Giống nhau do implement hàm equals() (gọi là equality by value)

Trong relational database thì 2 row bằng nhau khi có khóa chính bằng nhau

4/ Association problem
Quan hệ giữa hai table trong relational database có quan tâm đến hướng. Trong khi nhìn reference giữa 2 object ta không cách nào biết được.

Quan hệ nhiều nhiều giữa 2 table được diễn tả bằng một table thứ ba trong relational database. Trong khi ở object-oriented ta không cần thêm một object nào nữa.

5/ Data navigation problem
Trong object-oriented, ta có thể truy xuất thông tin của billing information như sau:
aUser.getBillingDetails().getAccountNumber()

Trong relational database, ta phải thực hiện n câu query để thực hiện việc đó.

Prototypes and Inheritance (2)

2007-11-12T23:48:00.000+07:00

tiếp theo bài trước

Khi ta đọc property p của object o, javascript đầu tiên sẽ kiểm tra xem o có property tên p chưa. Nếu chưa có, nó sẽ kiếm tiếp trong prototype của object o và cứ như vậy. Quá trình này gọi là prototype-based inheritance.

Tuy nhiên prototype inheritance không xuất hiện khi write property. Nếu ta set property p trong object o, javascript sẽ định nghĩa ngay lập tức property này trong o mà không quan tâm là có hoặc có nên set trong prototype hay không. Từ đó trở đi, nếu ta truy xuất property này có nghĩa là ta chỉ truy xuất property của chính object đó.

Lật ngược vấn đề lại nếu chúng ta cho phép ghi property lên prototype của nó, thì property này sẽ có thể bị truy xuất và thay đổi bởi các object. Đó là điều nhập nhằng mà js không mong muốn. Vd minh họa như sau:


function Foo()
{
    this.foo = "hello world!";
}

Foo.prototype.fooPro = "i am prototype";

var theFoo = new Foo();
alert(theFoo.fooPro); // alert: i am prototype

var theFoo2 = new Foo();
theFoo.fooPro = "i am child";
alert(theFoo.fooPro); // alert: i am prototype
alert(theFoo2.fooPro); // alert: i am prototype

Ví dụ trên cho thấy, sau khi set fooPro property trong prototype, các object của Foo đều truy xuất được (prototype-based inheritance). Khi ta set property trên một object nào đó, chỉ có mình nó là thay đổi, các object khác vẫn không bị ảnh hưởng.

Cuối cùng là một số khái niệm ta cần phải nắm rõ về property/method trên instance/class:


//Instance property
function Circle(radius) {
  this.r = radius; // r là instance property
}
//Instance method
Circle.prototype.area = function() {...}
//Class property
Circle.PI = 3.14;
//Class method
Circle.max= function() { ... };

Prototypes and Inheritance

2007-11-09T17:30:00.000+07:00

from Javascript - The Definitive Guide, 5th edition (Oreilly)

Method là một function được invoke như là property của một object (tức là phải được gọi trên một đối tượng nào đó). Nếu ta gọi hàm:


function calculateAreaOfRectangle(r) { return r.width * r.height }

thì không object-oriented

Mong muốn của chúng ta:


var r = new Rectangle(10, 5); // width, height
var result = r.area();

hiện thực:


function Rectangle(w, h) {
 this.width = w;
 this.height = h;
 this.area = function {
   return this.width * this.height;
 }
}

Mọi thứ có vẻ ok trừ 1 vấn đề sau: mỗi rectangle đều có width và height riêng, nhưng đâu nhất thiết các instance của Rectangle đều reference đến cùng một function area. Có cách nào có thể share function area cho mọi instance?

Mọi javascript object đều chứa một reference (internal) đến một object khác, thông qua prototype property. Các property của object được prototype chỉ đến đều trở thành property của chính object đó. Nói cách khác javascript object thừa kế các property từ prototype của nó.

Trong bài trước, ta biết toán tử new tạo ra một object mới empty và invoke constructor function như là method của object đó.

Note: một function được design để dùng với toán tử new gọi là constructor function hay là constructor

Sau khi tạo ra object, toán tử new thiết lập prototype cho object đó. Prototype của một object là property của constructor function của object đó. Tất cả các function đều có một property prototype, được tự động tạo khi function được định nghĩa. Giá trị khởi đầu của property prototype này là một object với một property duy nhất, tên là constructor (trỏ ngược lại chính function đó, chắc điên quá!!!). Mô hình hóa phát biểu trên như sau: (tham khảo từ site http://www.mollypages.org/misc/js.mp)

Ta nhận thấy rằng việc thừa kế xuất hiện một cách tự động trong quá trình tìm kiếm một property value. Các properties không được copy từ prototype object vào trong các object mới, chỉ đơn thuần xuất hiện như là property của chính object đó mà thôi. Có 2 hệ quả quan trọng:

Việc sử dụng prototype có thể làm giảm đi bộ nhớ cần thiết cho một object vì nó có thể thừa kế được các property.
Một object có thể thừa kế được property ngay cả khi chúng được add vào prototype object sau khi object đó đã được tạo ra.

Javascript cung cấp phương thức để kiểm tra property có thuộc trực tiếp của một object hay không, đó là: hasOwnProperty().


Rectangle.prototype.area = function() { return this.width * this.height; }

var r = new Rectangle(2,3);
r.hasOwnProperty("width"); // true: vì width là property  trực tiếp của r
r.hasOwnProperty("area"); // false: vì area là một property được thừa kế của r

(còn tiếp)

Object-Oriented Javascript (2)

2007-11-07T17:58:00.000+07:00

tiếp theo bài trước

Closures
Phần closure tác giả viết không hay như trong cuốn Asp.net Ajax in Action (chương 3 - javascript for ajax developers).

Closures là cách thức một inner function có thể tham khảo đến các biến trong một function cha, ngay cả khi function cha đó đã bị terminated. Xem ví dụ sau

function parent(arg) {
  var parentVar = "I am a variable of parent";

  function child() {
   alert(arg + parentVar);
  }

  child();
}

parent("hello, "); // alert message hello, I am a variable of parent

Hàm child trong ví dụ trên gọi là nested function, được khai báo bên trong hàm cha. Ta thấy nó có thể truy xuất các biết định nghĩa bên ngoài function body của nó. Vấn đề này bình thường. Chuyện gì xảy ra nếu ta thay đổi như sau:


function parent2(arg) {
  var parentVar = "I am a variable of parent";

  function child() {
    alert(arg + parentVar);
  }

  return child;
}

var theChild = parent2("yes, ");
theChild(); // alert message - yes, I am a variable of parent

Ta thấy rõ ràng sau khi hàm parent2 của nó được gọi và terminated, các variables của nó vẫn còn tồn tại và có thể được truy xuất bởi inner function. Đây gọi là closure.

Context
Là object vùng code mà object đang hoạt động bên trong. Biến this luôn reference đến object này (trong global context, biến this chỉ đến window object). Xem ví dụ sau:

var obj = {
  yes: function() {
       // this == obj
    this.value = true;
  },
  no: function() {
    this.val = false;
  }
}

alert(obj.val == null); // ban đầu chưa gọi hàm nên biến val chưa tồn tại

obj.yes();
alert(obj.val == true);

// ta trỏ hàm no của object window vô hàm no của object obj
window.no = obj.no;
window.no(); // hàm no sẽ được execute trong context của window object

alert(obj.val == true); // do đó val của obj không bị thay đổi
alert(window.val == false); // hiển nhiên

Javascript cung cấp một cách set context vào trong function khi gọi hàm, thông qua hàm call. Ví dụ:

function changeColor(color) {
 this.style.color = color;
}

var main = document.getElementById("main");
changeColor.call(main, "black"); // this bây giờ trỏ vô biến main

Object Creation
Phần này thấy đơn giản nhưng cũng có nhiều điều thú vị. Trong javascript, không có khái niệm class (nên không thể tạo object với một kiểu class nào đó), chỉ có object. Object này có thể tạo ra object kia và thừa kế từ các object khác (gọi là prototypal inheritance)

Để tạo một object có 1 kiểu nào đó, javascript cung cấp phương pháp khởi tạo function như là một object. Xem ví dụ sau:


function User(name) {
 this.name = name;
}

var me = new User("my name"); // khởi tạo object của function đó qua toán tử new  (constructor)
alert(me.name == "my name"); // name bây giờ trở thành property của object me, this pointer trỏ vào me
alert(me.constructor == User); // property constructor của me bây giờ chính là User

Ví dụ này chứng tỏ:

Mỗi object đều có constructor property
Constructor property trỏ vào function nào đã tạo ra nó.

Object-Oriented Javascript

2007-11-06T23:50:00.000+07:00

from chapter 2 of Prof Javascript Techniques (Apress)

Không thể nào bỏ xuống được khi đọc. Cuốn sách này làm thay đổi quan điểm của mình về Apress - một nhà sách viết bởi mấy tác giả củ chuối của Ấn Độ, toàn là mấy cái dễ và ko có gì sâu cả :-D.

Chương này tác giả đánh giá là chương quan trọng nhất trong cuốn sách, bàn về references, scope, closure, context.

Thuật ngữ object-oriented javascript có vẽ thừa thải vì javascript language toàn bộ là object, có cái nào khác object đâu. Nhưng tác giả muốn nhấn mạnh ở đây vì đa số cách sử dụng toàn là functionally, hiểu sai khái niệm và mơ hồ trong việc sử dụng object của hầu hết các developer.

References
Reference là 1 pointer trỏ đến location thật của object. Nếu 2 object cùng 1 reference thì sửa cái này cái kia cũng bị thay đổi theo (cái này bình thường). Tuy nhiên, một số cái ta có thể không để ý:

Javascript không có khái niệm reference đến 1 reference (Perl có), mà object khi reference sẽ reference đến một object thật sự. Do đó nếu object ban đầu trỏ đến một đối tượng khác thì các object kia reference đến nó sẽ không bị ảnh hưởng.

var items = new Array("one", "two", "three");
// itemsRef reference to item
var itemsRef = items;

// set items to equal a new object
items = new Array("four", "five");

alert(items != itemsRef);

Chú ý một số tác vụ modify object có thể sinh ra một object mới (như concatenate string trong js)

var item = "test";
var itemRef = item;
item += "ing";
// do tác vụ cộng chuỗi làm cho object item trỏ đến một đối tượng khác, không còn là "test" nữa
alert(item != itemRef);

Scope
Scope được tính bên trong function, không phải bên trong block (vd while, if, for). Trong js, mỗi function được execute như là một method của một object.

Nếu ta khai báo biến và function khơi khơi, không chỉ định 1 scope nào hết thì nó thuộc về global scope, thật ra là thuộc về scope của object window. Xem ví dụ sau:

var foo = "test";

function test() {
  var foo = "tele";
}

test();
alert(foo == "tele"); // return false;

do biến foo bên trong hàm test chỉ thuộc scope của hàm test nên nó không làm ảnh hưởng đến biến toàn cục foo bên ngoài.

(be continue...)

Default transaction scope in ms sql storeproc

2007-11-06T23:16:00.000+07:00

Mới thua độ ly cafe cho bác Duy. Câu hỏi được đặt ra như sau: nếu không khai báo tường minh begin/end trans trong sql store procedure thì default transaction scope từ đâu đến đâu.

Mình nhớ là đã đọc ở đâu đó rồi là M$ default tạo ra 1 transaction từ đầu đến đuôi khi execute storeproc nên trả lời như vậy. Bác Duy thì reject (vì ổng đã troubleshoot trong thực tế một lần rồi). Giao cho DuyN kiểm chứng, kết quả như sau:

Viết 1 storeproc in ra giá trị transaction count trong hai trường hợp, có khai báo và không khai báo begin tran


ALTER PROCEDURE TestTrans
AS

BEGIN tran
PRINT @@TRANCOUNT
COMMIT tran

EXEC TestTrans

Kết quả rất đau buồn, nó in ra số 1 khi có khai báo và 0 khi bỏ đi. Không cam tâm mình tra lại cuốn SQL Bible 2005 để xem hồi trước đọc ý này ở đâu thì thấy như sau:

M$ quan điểm một sql statement là một transaction, đây là đơn vị transaction nhỏ nhất được ms tự hiểu mà ko cần khai báo.
Đối với trường hợp batch statement, buộc phải khai báo tường minh begin/end tran (oracle tự động set transaction khi execute một batch các statement)
M$ cung cấp một option để setting ở mức server là SET IMPLICIT_TRANSACTIONS {On | Off} cho phép tự động start một transaction khi execute một số statement và không đang ở trong một transaction khác.

Kêu DuyN kiểm chứng lại 1 lần nữa thì đúng, do M$ default set nó về Off, developer phải set tường minh. Đây là một hậu quả của việc đọc nhiều nhưng nhớ không chính xác, không chịu kiểm chứng trong thực tế thì ... không đọc gì còn tốt hơn :-D

Lock and Isolation level

2007-10-31T00:28:00.000+07:00

from chapter 51 - SQL Server 2005 Bible

Có gì đó nhập nhằng giữa lock và isolation level của sql server nên phải xem lại. Kết luận:

Lock mang ý nghĩa rộng hơn isolation level, nó là cơ chế lock một resource không cho 2 transaction cùng truy xuất đồng thời để đảm bảo toàn vẹn dữ liệu.
Isolation level là một chiến thuật lock, diễn tả mức độ isolation của một transaction, nó là một khái niệm được đặt ra và được implement bởi lock.

Isolation level bao gồm:

Read Uncommitted
Read Committed
Repeatable Read
Serializable
Snapshot
Read Committed Isolation

Lock có 3 đặc điểm:

Granularity: size of lock (row, page, extent = 8 pages, table, database, key)
Mode: type of lock (intent shared, shared, update, intent exclusive, exclusive, shared with intent exclusive)
Duration: được quyết định bởi isolation mode. Ví dụ share-lock với mode read committed sẽ lock trong khi transaction đọc data, còn exclusive-lock sẽ giữ cho đến khi transaction committed.

Locking Hints

Một khái niệm mới khá thú vị. Cũng là 1 chiến thuật lock nhưng nó không ảnh hưởng lên toàn bộ connection như isolation level. Nó chỉ riêng biệt cho một table bên trong một query. Cách viết được đặt sau tên table sau from, cú pháp with (locking hint). Ví dụ:

select messageID from MTs with (RowReadPast)

Một số locking hint:

ReadPast: bỏ qua các row bị lock thay vì phải đợi (cool)
RowLock: lock trên row
PagLock: page lock
TabLock: tự động tăng dần đến các level lock, từ row, page, extent đến table lock
...

Story of DNN

2007-10-19T16:42:00.001+07:00

from chapter 1 of Professional DDN (Wrox)

Không ngờ lịch sử phát triển của DNN lại dài dòng và phức tạp như vậy. Đọc nó mới hiểu thêm vấn đề là việc phát triển một open source product cũng không đơn giản. Sau đây là một số mốc chính

1/ Version đầu tiên có tên là IBuySpy Workshop, là bản mở rộng của IBuySpy Portal của M$. IBuySpy có license là EULA của M$ (ko giới hạn cách sử dụng, giống open source). Version này được cộng đồng trong forum asp.net sử dụng rộng rãi và được M$ support bằng cách để cái link và reference đến nó.

2/ Tác giả quyết định charge tiền cho những ai muốn download latest source code. Đây là một bước lùi và sau đó tác giả phải viết một lá thư xin lỗi cộng động vì đã đi sai đường so với định hướng ban đầu, đồng thời trả lại tiền cho những ai đăng ký. (hình thức sau này là donation)

3/ M$ quyết định tài trợ cho IBuySpy Workshop và yêu cầu đổi tên product vì bây giờ nó đã phát triển khá xa so với IBuySpy. Tác giả quyết định lấy tên là DotNetNuke vào 2/2003

4/License Microsoft EULA có vẻ không phù hợp vì nó không bắt buộc include bất kỳ license nào giống vậy trong các nhánh, cũng như copyright của owner. Tác giả vừa muốn commercial và non-commercial product nên chọn BSD license (yêu cầu giữ lại copyright của nhánh gốc trên tất cả các nhánh phát triển)

5/ Sự va chạm giữa các nhánh về vấn đề sharing source code. Một nhánh khác tên là DotNetNuke XXL ra đời với quảng cáo là mạnh hơn, và user có thể download latest source code vào bất kỳ lúc nào. Tác giả quyết định phủ nhận nó trong forum community của DNN.

6/ Một số thông tin về quá trình hình thành core team, định hướng phát triển và ý tưởng thay đổi version của DNN.

Arguments:

DNN có phải là 1 sản phẩm open source thuần túy? Nó được phát triển trên SQL Server, VS.Net và chỉ có mã nguồn là mở. Đó là lý do tại sao M$ tài trợ cho DNN vì nếu user sử dụng DNN để triển khai thì buộc phải mua sản phẩm của M$
Thế nào là một mã nguồn mở thuần túy? Rõ ràng ý tưởng kinh doanh trên mã nguồn mở đã có ngay từ lúc đầu nên tác giả mới chọn BSD license. Sự phát triển của DNN làm phát triển hay thụt lùi ý nghĩa open source trong cộng đồng!
Không hiểu sao tác giả vẫn chọn VB.Net để phát triển đến giờ, botay.com :-D

Oops, I refactored it again...

2007-10-17T23:15:00.000+07:00

continue from last previous post - workflows

Trong đoạn draft implementation của bài trước, bác Phước remind là tên class có suffix là Command mặc dù khi re-design mình bỏ hoàn toàn tư tưởng của Command pattern. Để thử tìm kiếm 1 cái tên nào khác cho phù hợp.

Cách đặt tên trong windows workflow foundation như sau:

Nguyên cái tree (tên đúng là workflow) được đặt tên có dạng vd như là OrderProcessingWorkflow, xxxWorkflow. Trong WF (workflow foundation), để tạo workflow ta phải tạo ra 1 class thừa kế từ một class base của workflow, trong đó cơ bản nhất có 2 dạng: SequentialWorkflowActivity, hoặc StateMachineWorkflowActivity (do bản chất của workflow được M$ chia ra làm 2 loại Ordered workflow và Event-Driven workflow). Còn trong mô hình của mình viết thì nó chỉ là một cái node gốc, không hơn kém, nhưng ta vẫn có thể đặt tên như vậy nếu muốn.
Các node trong tree được đặt tên là chính cái activity đó (động từ), và không có suffix, prefix gì hết. Ví dụ như là: GetProductData, UpdateOrder... Trong WF, các class này buộc phải thừa kế từ 1 class cơ bản tên là Activity. Nhân tiện ta review cái base class này xem sao:

Giải thích cho sự phức tạp này là yêu cầu cần thiết cho một workflow đúng nghĩa là:

Có khả năng cho biết trạng thái hiện tại của nó, vd đang được execute ở node nào, trạng thái là gì...
Nó có thể bị save và reload, vì workflow có thể chạy trong 1 thời gian dài, nhiều ngày hoặc nhiều tháng.
Support multiple thread
....

Vĩ có đưa ra một mô hình dựa trên FlowChart khá thú vị, trong đó có các khái niệm:

Process
Decision (or conditional)
Start, end, input/output: (cái này không cần lắm)

Từ đó ta có thể build các process, decision và liên kết chúng lại với nhau. Process chạy xong sẽ chạy tiếp decision để ra quyết định, còn decision sẽ quyết định tiếp chạy process nào. Khả năng INJECT của mô hình này có vẻ tốt hơn, tuy nhiên chúng ta vẫn phải giải quyết vấn đề interface giữa chúng với nhau (giống như hàm IsValid mà node cha gọi node code để quyết định chạy node con nào trong bài trước). Mình sẽ suy nghĩ tiếp về mô hình này, nhưng bây giờ mà change nữa là bị tụi nó giết chết :-D

Một câu hỏi cuối cùng là workflow và flowchart khác nhau như thế nào?
Tra định nghĩa trong vài cuốn sách, thì workflow:

là một sự sắp xếp, tập hợp các hoạt động được thực thi để đạt mục đích cuối. Nó có thể bao gồm cả human process (vd reviewing, approving documents) và automated process (vd tự động truy xuất data và execute một tập các logic dựa trên data có được). Workflow có thể kéo dài vài giờ, vài ngày hoặc vài tháng (chứ không chỉ chạy một cái là xong liền trong vài giây).
trong wiki định nghĩa trừu tượng hơn, và còn phân biệt workflow với process, planning và scheduling

Còn flowchart theo wiki là một sự diễn tả sơ đồ của một process hoặc một giải thuật. Như vậy thì bản chất của hai cái này không giống nhau nên không thể so sánh với nhau được.

Real Implementation
// chưa có thời gian post tiếp :-D

Workflows

2007-10-16T23:32:00.000+07:00

continue to previous post - Command Patterns

Có gì đó không ổn với việc refactor đoạn code trong bài viết trước:

Làm sao để xác định command nào cần execute cho mỗi incoming - tức là invoker thật sự cần phải biết về command mà nó thực hiện. Mặc dù ta cố gắng che dấu nó bằng việc implement trong CommandFactory.
Đoạn code trong hàm execute( ): thực chất là 1 chuỗi các command được thực hiện bên trong và có một đặc điểm quan trọng là các command có quan hệ với nhau. Command nào được excute tiếp theo tùy thuộc vào giá trị trả về của việc execute command trước đó.

--> áp dụng pattern này không phù hợp.

Refactor with workflow

Hình ảnh trong đầu là 1 tree các node (gọi là task, hoặc command) nhiều chiều (graph), trong đó mỗi node sẽ chứa được các node con của mình. Sau khi execute, node dựa vào kết quả trả về để duyệt các node con và quyết định node nào được thực thi tiếp. Cứ như thế đệ quy cho đến node lá.

Developer chỉ cần build tree này trước, và execute node root cho mỗi incoming.

Draft Implementation


public abstract class NodeCommand
{
  public NodeCommand NodeCommandChilds;
  public abstract void Execute(Incoming incoming);
  public bool IsValid(object validObject);
  ....
}

public class ACommand : NodeCommand
{
  ...
  public bool IsValid(object validObject)
  {
     ACommandValidObject aValidObj = validObject as ACommandValidObject;
     if (aValidObj.ResponseCode == '001') return true;
     return false;
  }

  public void Execute(Incoming incoming)
  {
     response = bp.MoneyTransfer();
     foreach(NodeCommand node in NodeCommandChilds)
     {
        if (node.IsValid(response)) node.Execute(incoming);
     }
  }
}

public class TestProgram
{
  public void Test()
  {
     Incoming incoming = GetIncomingFromQueue();
     NodeCommand node = BuildNodeCommandTree();
     node.Execute(incoming);
  }
}

Mô hình code này đã decouple được business flow của ứng dụng và việc execute business của ứng dụng đó. Nó có thể đáp ứng dễ dàng các thay đổi cũng như áp dụng MOCK OBJECT pattern trong việc test, một hiệu ứng lề khá thú vị :-)

Command Pattern

2007-10-15T20:13:00.000+07:00

from chapter 6 - Design Patterns (Head First)

Đang có nhu cầu refactoring đoạn code trong cty và muốn dùng Command Pattern nên đọc lại nó một chút. Ngoài cuốn sách của GoF kinh điển thì cuốn Head First - Design Patterns của nhà xuất bản O'reilly khá hay, nó lấy ví dụ trong cuộc sống và cách trình bày làm cho người đọc cảm thấy ít khô khan hơn.

Issue được đưa ra từ ví dụ sau: có một cái remote control có nhiều khe (slot), mỗi khe có thể được lập trình để điều khiển các thiết bị khác nhau. Có hai nút cho mỗi khe là On/Off, một nút Undo dùng chung cho tất cả các khe (xem hình)

Có nhiều thiết bị khác nhau, như quạt, đèn, TV, máy nước nóng (hottub)... Ta phải lập trình sau cho remote control có khả năng bật tắt trên các thiết bị đó, tùy vào ngữ cảnh user nạp thiết bị vào trong slot nào.

Ý nghĩ đầu tiên về cách lập trình:

if (slot1 == light) light.on();
else if (slot1 == hottub) hottub.on();
else....

--> chuối bưởi quá :-D

Có cách nào tách rời giữa remote control và các vendor class, nó không cần biết phải bật/tắt trên class nào, chỉ đơn giản là execute một command, không quan tâm bên trong command đó làm việc gì (bản thân command tự biết). Đây gọi là decouple requester của một action và object thực hiện action đó.

Command pattern thực hiện như sau:

Tạo ra một command object encapsulate một request làm một action nào đó (giống như turn on a light) và trên một đối tượng nào đó (vd trên đối tượng bóng đèn).
Store command object đó. Invoker khi có nhu cầu sẽ gọi execute trên command đó (giống như load các command trên mỗi button, khi user nhấn nút thì gọi command execute, không quan tâm đến nó làm cái gì)

Implementation
Tạo ra 1 interface chung Command

public interface Command {
 public void execute(); // cu phap java :-D
 }

 public class LightOnCommand implements Command {
   Light light;
   public LightOnCommand(Light light) {
   this.light = light;
 }
 public void execute() {
   light.on();
 }
}

public class TestRemoteControl {
 public void Test() {
   RemoteControl remoteControl = new RemoteControl(); // class remoteControl tu viet
   Light light = new Light();
   LightOnCommand lightCommand = new LightOnCommand(light);

   remoteControl.setCommandOnSlot(1, lightCommand); // set lightCommand on slot 1
   remoteControl.pressButton(1); // simulate press button 1
 }
}

Trở lại đoạn code cần refactor ở cty, có khá nhiều use cases trong business flow, làm thế nào để code vừa áp dụng được pattern trên vừa thể hiện rõ business mà nó đang chạy nhất (theo như ý tưởng mà mình ngộ ra từ Craftman và bác Vĩ cũng có đề cập: code cũng chính là comment :-))

Review document ta thấy có 4 dạng business chính, wrapper lại thành 4 command chính là MoneyTransferCommand, MobileRechargeCommand...

Các command này thực hiện action trên 2,3 đối tượng là YP, BP (banking Pichincha), Commerce (third party), ... (trong command pattern, đối tượng này gọi là Receiver)

Code được viết như sau:

public class MoneyTransferCommand : Command
{
 YP yp;
 BP bp;
 // .......
 public void Execute()
 {
   transActionStatus = yp.ValidateTransaction(incoming);
   swith(transactionStatus)
   {
     case SUCCESS:
       bp.MoneyTransfer();
       break;
        //......
   }
 }
}

CommandFactory thực hiện việc tạo ra các command từ incoming rồi bỏ vào trong queue. Các thread sẽ thực hiện command trong queue

Developing Custom Controls that Raise Events (2)

2007-10-14T16:11:00.000+07:00

(from chapter 4 - Prof ASP.NET Server Controls)

Trong phần trước của chương 4, ta đã biết làm cách nào để raise 1 event cho client handle khi postback về server. Phần 2 chúng ta sẽ đề cập đến Postback Data.

Ví dụ ta có 1 dropdownlist, khi user select 1 giá trị khác trong dropdownlist, ta phải có cách để biết được sự thay đổi này và raise 1 event (vd OnDropdownlistChanged)

ASP.NET cung cấp IPostBackDataHandler interface để làm việc này, bao gồm 2 method:

LostPostData(string postDataKey, NameValueCollection values): chứa giá trị của tất cả các value được postback theo dạng name/value, cho phép developer lấy được giá trị của các element trong form postback. Nếu hàm này trả về true có nghĩa là đã có sự thay đổi data, do đó hàm RaisePostDataChangedEvent bên dưới sẽ được gọi.
RaisePostDataChangedEvent( ): developer implement để biết raise event.

VDropdownList được viết như sau:

Developing Custom Controls that Raise Events

2007-10-14T15:55:00.000+07:00

(from chapter 4 - Prof ASP.NET Server Controls)

Chương này hướng dẫn cách thức develop một custom control có khả năng raise events, giống như sự kiện OnClick của asp:Button.

Đầu chương là phần discuss về Event, EventDelegate, EventData. Ta thử viết một custom control VButton giống như asp:Button.

Đầu tiên ta dự định tạo một EventData, tên là VButtonEventArgs, thừa kế từ EventArgs, nhưng do không có gì trong đó nên ta không tạo. Sau đó tạo delegate, event handler.

public delegate void VButtonClickEventHandler (object sender, EventArgs e);
....
public event VButtonClickEventHandler vButtonClickEventHandler;
....

Vấn đề bây giờ là làm sao notify được event này cho dù client có đăng ký và postback về server đi nữa. Quay lại trường hợp click trên button Submit để postback về server của asp.net, khi đó containing page sẽ:

Tìm kiếm xem html element nào thực hiện việc post back bằng cách duyệt các tag trong form khi submit.
Tìm kiếm trong control tree (thông qua name của element trong form đã thực hiện việc postback) để xem control đó có implement interface IPostBackEventHandler hay không. Nếu control đó có implement interface này, nó sẽ gọi hàm RaisePostBackEvent của control đó (đây là hàm của interface IPostBackEventHandler được control implement).

Do đó có 2 nguyên nhân khiến cho VButton không notify được sự kiện là:

Attribute name không phải là UniqueID của control, do đó containing page dựa vào đó sẽ không tìm ra được control nào thực hiện việc postback.
VButton không implement interface IPostBackEventHandler

Code được sửa lại như sau:

Bây giờ button name và UniqueID trùng nhau, và control đã implement interface RaisePostBackEvent nên developer đã có thể đăng ký sự kiện và raise event khi button này được click (postback về server)

Overview of Extreme Programming

2007-10-14T15:44:00.000+07:00

(from chapter 2 - Agile Principles, Patterns, and Practices in C# - Martin C.Robert)

Agile Practices

2007-10-14T15:40:00.000+07:00

from chapter 1 - Agile Principles, Patterns and Practices in C# - Martin C.Robert

Chương này nói về Manifesto của Agile Alliance

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

1/ Individuals and interactions over processes and tools
Con người là nhân tố quan trọng nhất trong việc thành công. Một process tốt không cứu được project khỏi thất bại nếu team không có member giỏi (strong player), và process không tốt sẽ làm cho member làm việc không hiệu quả. Ngay cả một group các member giỏi vẫn có thể bị failed nếu họ không làm việc như là một nhóm.

Một member giỏi không nhất thiết phải là một người có nhiều kỹ năng. Có thể chỉ là một programmer trung bình nhưng biết cách làm việc tốt với các member khác. Khả năng communication và interaction quan trọng hơn nhiều so với một tài năng lập trình nhưng mới vào nghề. Một team với các lập trình viên trung bình nhưng giao tiếp tốt sẽ thành công hơn một team bao gồm các ngôi sao nhưng không hoạt động như 1 nhóm.

Sử dụng đúng tool rất quan trọng trong việc thành công. Compiler, IDEs, source control system ... đều rất cần cho nhóm developers. Tuy nhiên tool có thể bị xem trọng quá mức. Sử dụng thừa thải, tràn lan các tool cũng gây ra hậu quả xấu tương tự như thiếu các tool vậy.

Lời khuyên là hãy bắt đầu với ít công cụ thôi. Đừng cho rằng bạn phải mở rộng các công cụ nếu như bạn không sử dụng nó và tìm thấy rằng nó cần phải thay đổi. Thay vì mua một đống các source control system mắc tiền, hãy tìm một hệ thống miễn phí và sử dụng nó đến khi bạn cảm thấy phải phát triển hơn nữa. Thay vì mua license cho CASE tools, bạn hãy sử dụng bảng trắng và graph paper cho đến khi bạn thấy phải cần nhiều hơn nữa.

Cần phải nhớ rằng, xây dựng một team quan trọng hơn nhiều xây dựng môi trường phát triển. Nhiều team và manager đã sai lầm trong việc xây dựng môi trương trước và mong chờ sẽ tự động có được một team. Thay vào đó, hãy làm việc để tạo ra team trước, sau đó để team configure môi trường làm việc dựa trên các yêu cầu cơ bản.

2/ Working software over comprehensive documentation
Làm phần mềm mà không có documentation là một tai họa. Code không phải là một phương tiện lý tưởng cho việc giao tiếp cơ bản và xây dựng cấu trúc của hệ thống. Ngoài ra, team còn cần phải xuất ra các tài liệu mà con người đọc được để miêu tả hệ thống và ý tưởng cơ bản cho việc design.

Tuy nhiên, quá nhiều document cũng tai hại như là quá ít. Một đống các software document sẽ tốn một đống thời gian để viết và ngay cả thời gian để làm cho nó đồng bộ với code.

Ý tưởng tốt là viết và maitain document trong một cấu trúc cơ bản nổi bật, ngắn. Ngắn có nghĩa là tối đa chỉ một hoặc hai tá giấy (dozen pages). Nổi bật (salient) có nghĩa là nó nên mô tả toàn bộ thiết kế một cách cơ bản và chỉ là cấu trúc ở mức cao nhất trong hệ thống.

Làm cách nào để trainining một member mới về hệ thống. Chúng ta làm việc gần gũi với họ. Transfer kiến thức bằng cách ngồi kế bên và giúp họ. Chúng ta làm cho họ trở thành một phần của team thông qua các giao tiếp và training gần gũi đó.

Hai tài liệu tốt nhất chính là team và code. Code bản thân nó không thể nói dối. Có thể khó khăn trong việc tìm hiểu nhân tố cơ bản và mục đích của đoạn code, nhưng bởi vì nó không phải là nguồn thông tin. Team sẽ nắm giữ các thông tin về thay đổi, roadmap của hệ thống trong đầu các member và cách nhanh nhất và hiệu quả nhất là đem nó ra giấy và transfer nó thông qua human-to-human interaction.

Có nhiều team khá tốn thời gian trong việc document thay vì làm phần mềm. Có một luật đơn giản ngăn chặn việc đó:

Produce no document unless its need is immediate and significant.
(martin's first law of documentation)

3/ Customer collaboration over contract negotiation
Software không thể được ordered như món hàng. Bạn không thể viết một mô tả cho phần mềm bạn muốn và sau đó nhờ một ai đó phát triển nó theo một schedule cố định và theo một giá cố định được. Ngày qua ngày, mọi cố gắng phát triển dự án theo cách này đã thất bại.

Các manager trong công ty rất mong muốn khi nói với đội ngũ phát triển những gì họ cần và sau đó mong chờ nhân viên chạy đi đâu đó trong một lúc rồi đem về một hệ thống thỏa mãn các nhu cầu đó. Nhưng cách thức hoạt động này thường dẫn đến chất lượng thấp và thất bại.

Những dự án thành công đòi hỏi sự feedback của khách hàng thường xuyên và đều đặn hơn là phụ thuộc vào contract, hoặc cam kết làm việc nào đó, khách hàng của phần mềm thường làm việc gần gũi với development team, cung cấp các feedback thường xuyên trên những cố gắng của team.

4/ Responding to change over following a plan
Khả năng đáp ứng thay đổi thường quyết định khả năng thành công hay thất bại của dự án. Khi xây dựng các kế hoạch, chúng ta cần phải đảm bảo được sự linh động và đáp ứng được các thay đổi về mặt business và công nghệ.

Tiến trình của dự án không thể được plan quá xa trong tương lai. Lý do đầu tiên là do môi trường kinh doanh thường thay đổi, làm cho các yêu cầu phải đổi theo. Kế đến là một khi hệ thống bắt đầu chạy, khách hàng thường có khuynh hướng thay đổi requirement. Cuối cùng ngay cả chúng ta nếu biết rằng yêu cầu là gì và chắc rằng nó không đổi, thì chúng ta cũng không ước tính được chính xác hoàn toàn thời gian cần thiết để develop là bao lâu.

Các manager mới tập sự thường có sở thích và tham vọng là tạo và ghi nhận một cái PERT hoặc Gantt chart cho toàn bộ project. Họ cảm thấy rằng sơ đồ này cho họ khả năng control trên toàn bộ dự án. Họ có thể track được các task của từng cá nhân, đánh dấu trên chart khi nó hoàn tất. Họ có thể so sánh được giữa ngày thật sự và ngay planning trên chart và đáp ứng sự khác nhau đó.

Nhưng những gì thật sự xảy ra là cấu trúc của chart ngày càng bị giảm sút (degrade - giảm giá trị). Khi team có được kiến thức về toàn bộ hệ thống và khách hàng biết được về những nhu cầu của team thì một số task nào đó trên chart trở nên không còn cần thiết. Một số task khác sẽ được thêm vào. Tóm lại, plan sẽ bị thay đổi về hình thức, không còn được cập nhật (in dates).

Một chiến thuật planning tốt hơn là chỉ làm plan chi tiết cho tuần sau, các plan cơ bản cho 3 tháng tới và để các plan thô thiển khác cho thời gian sau nữa (crude plans). Chúng ta chỉ nên biết rằng các task riêng lẽ nào sẽ được làm việc trong tuần sau. Hoặc các requirement cơ bản mà chúng ta sẽ làm việc trong 3 tháng tới. Và chi có 1 ý tưởng mơ hồ (vague idea) về những gì mà hệ thống sẽ làm sau 1 năm.

Việc làm giảm tính ràng buộc (resolution) của kế hoạch có nghĩa là chúng ta chỉ thực hiện kiểm tra một cách chi tiết cho những task ngay trước mắt. Một khi plan chi tiết được thiết lập, rất khó để thay đổi, vì team đang có nhiều quán tính và cam kết trong công việc. Tuy nhiên phần còn lại của plan sẽ vẫn được linh động vì chúng ta chỉ có plan chi tiết trong 1 tuần.

Developing Custom Composite Controls

2007-10-07T00:42:00.003+07:00

(from Prof ASP.NET Server Controls - Wrox - chapter 5)

Composite control tận dụng các control có sẵn để tạo control mới. Qua 3 chương đầu ta thấy chi phí cho việc tạo ra các thẻ html, dùng viewstate, hoặc handle event là khá nhiều và lặp đi lặp lại trong khi các control cơ bản đã có sẵn.

Chương này tác giả viết khá dài, nhưng không hay và không đi vào trọng tâm của vấn đề. Reference tiếp trong Build Composite Controls trong msdn giúp ta hiểu rõ hơn nhiều.

Cách thức tạo composite control như sau:

Inherit base class CompositeControl (optional). Tuy không nhất thiết phải thừa kế lại lớp này nhưng ta nên làm vì nó hỗ trợ khi sử dụng control ở design view (recommend from M$ :-D )
Override method CreateChildControls của base class Control, khởi tạo và add các control vào trong Controls Collection của class cha.
Override các property và method khác (optional) như TagKey, CreateControlStyle, RenderContents...

Xem xét một ví dụ tạo 1 composite control bao gồm 1 label, 1 text, 1 submit button như sau:

Ta gọi hàm Controls.Clear() đầu tiên để đảm bảo không control nào được add nhiều lần, cuối cùng ta bật property ChildControlsCreated = true để thông báo các control đã được create xong.

Property của composite control được public trực tiếp thông qua property của child control như sau:

Hàm EnsureChildControls được gọi trước để đảm bảo tất cả các control đã được khởi tạo xong.
Html render:

Nếu muốn control được chứa trong 1 table, label, input text và button nằm trong cùng 1 row và ở 3 column của table đó thì ta có thể làm như sau:

Override lại TagKey, trả ra tag Table để cho container của control là table
Add label, textBox, button vào trong control TableCell trước khi add vào Controls collection của class cha (trong hàm CreateChildControls. (nhớ đầu tiên phải đưa tất cả nằm trong một table Row trước)

Event Bubbling
Làm cách nào để composite control bắt được sự kiện của các control con và raise tiếp sự kiện của nó lên control cha?

Để raise sự kiện lên control cha:

Composite control phải public một event để cho phép control sử dụng đăng ký (thông thường là CommandEventHandler)
Implement method RaisePostBackEvent trong interface IPostBackEventHandler để gọi các event handler đã đăng ký, cuối cùng gọi hàm RaiseBubbleEvent để bubble events ra ngoài.

Để catch các event của control con:

Composite control phải override lại method OnBubbleEvent để catch Command event được raised và bubble từ control con.
Để biết chính xác control nào raise event, ta phải kiểm tra command name trong hàm này.

(chú ý là khi add control button trong hàm CreateChildControls, nhớ là gán thêm command name cho nó là buttonSubmit như đoạn code ở trên)

Vấn đề sau cùng là control con được tạo khi nào trong control tree. Lần đầu tiên, CreateChildControls sẽ được gọi trong pre-rendering phase, sau khi postback về server lần thứ 2 trở đi, nó được gọi trong giai đoạn processing posted data (BeginProcessPostData). Nguyên nhân là trong giai đoạn process posted data, asp.net sẽ tìm các control nào có ID match trong control tree (thông qua hàm FindControl). Trong method FindControl, trước khi trả về control phải đảm bảo cây control phải được build xong (EnsureChildControls) nên nó được build trong giai đoạn đó.

Developing Custom-Styled Controls

2007-10-07T00:42:00.001+07:00

(from chapter 3 - Prof ASP.NET Server Controls)

Chương này miêu tả các methods và properties của WebControl base class và hướng dẫn cách thức để implement một custom control. Sau đó là cách implement của một custom Style class và cách sử dụng của một custom control với nó.

WebControl kế thừa từ Control, sử dụng thêm một instance class Style của ASP.NET để hỗ trợ các property style tốt hơn. Ví dụ:

public class VcustomStyledTextBox : WebControl
{

protected override void Render(HtmlTextWriter writer) { .... }

}

So với Control, WebControl tách bạch hơn trong việc Render(..) vì Control không quan tâm gì đến containing HTML element. WebControl delegate ra các method khác nhau để developer override như:

AddAttributeToRender: gắn các attribute của containing element.
RenderBeginTag: render opening tag của containing element.
RenderContent: render html content giữa open tag và close tag của containing element.
RenderEndTag: render end tag

Containing element là gì? Ví dụ control của ta render ra HTLM bao gồm label và textbox trong 1 table như sau:

thì tag table là containing element của control, và property của nó (border) được xem là attribute của containg element.

WebControl default sẽ implement hàm Render() như sau:

Do đó ta không nhất thiết phải override lại toàn bộ hàm Render(..) của WebControl, mà chỉ cần override hàm RenderContent() để render nội dung bên trong, và RenderBeginTag() để render containing element.

Bên trong hàm RenderBeginTag(…), WebControl thật ra tìm kiếm thẻ HTML được khai báo trong TagKey property để render, nên ta cũng không cần override hàm RenderBeginTag mà chỉ cần override property TagKey là đủ. Ví dụ:

protected virtual HtmlTextWriterTag TagKey
{ get {return HtmlTextWriterTag.Table;} }

Về attribute của containing element, hàm AddAttributeToRender thực hiện 2 việc cơ bản sau:

Tự động thêm vào các non-styled attribute vào. Non-styled attribute bao gồm: ClientID, AccessKey, Enabled, Tabindex, and ToolTip.
Thêm vào một số attribute khác, định nghĩa trong collection attribute của ControlStyle

Quan sát trong collection này, ta thấy nó gọi hàm CreateControlStyle(..) nên ta chỉ cần override hàm này là đủ. Ví dụ:

protected override Style CreateControlStyle()
{
return new TableStyle(this.ViewState);
}

Do containing element của ta trong vd này là tag table nên ta return 1 instance TableStyle. Chú ý các instance này phải share cùng một ViewState của control.

Cuối chương này tác giả còn hướng dẫn cách tạo ra một custom style class (style do developer định nghĩa). Cái này ít dùng và đơn giản nên không cần phải đề cập nhiều.

Class VTextBoxCustomStyled cuối cùng được viết như sau:

Developing Simple Custom Controls and User Controls

2007-10-03T15:05:00.000+07:00

(from chapter 2 - Prof ASP.NET Server Controls)

Chương này giới thiệu cách implement cơ bản của custom control và user control (giống như vd Hello World trong chương đầu tiên của mỗi cuốn sách).

Để viết một custom control, ta phải thừa kế từ base class Control và override method Render()

Ví dụ giả sử viết lại 1 custom control giống asp:TextBox của MS.

Ở thời điểm runtime, containing page sẽ tạo ra 1 instance của HtmlTextWriter và truyền instance này cho các control con (recursive) để mỗi control thực hiện việc Render()

Việc khai báo property cho phép page developer customize của thuộc tính cần thiết của control. Các cách gắn property vào control lúc design time:

Property level attribute: [BrowsableAttribute], [DescriptionAttribute], [DefaultValueAttribute], [CategoryAttribute] (edit property trong toolbox property-design).
Class level attribute: cho phép set các default value cho property khi kéo thả control vào web
[ToolboxData("<{0}:VTextBox textValue='vinh test'>")]
public class VTextBox : Control { … }
Assembly level attribute: cho phép thay đổi tagPrefix default của control khi kéo thả

Phần thú vị nhất của chương này là State Management, để cho control lưu được trạng thái sau mỗi lần postback, ta nên lưu giữ các giá trị được set vào trong ViewState.

Mọi việc đều ok giống như hướng dẫn trong sách, tuy nhiên nếu tò mò liên tưởng đến asp:TextBox của M$, nếu bạn disable ViewState của asp:TextBox thì sau mỗi lần postback, nó vẫn load lại được giá trị như thường!!!. Điều đó gợi cho chúng ta câu hỏi:

Ta có thể có dùng một cách khác không phải ViewState để thực hiện việc này (giống như asp:TextBox)
Vậy ViewState thật sự được dùng khi nào

Hai câu trả lời này có trong article Understanding ASP.NET ViewState (http://msdn2.microsoft.com/en-us/library/ms972976.aspx) ViewState dùng để lưu lại trạng thái của các lần postbacks. Và lý do mà asp:TextBox có thể load lại value khi disable ViewState là do nó implement 1 interface IPostBackDataHandler, dùng để load data khi nó được post back về server.

Giai đoạn Load Postback Data của một Page life cycle là giai đoạn thứ 3, (sau Initialize và Load View State), chỉ được gọi khi page được post back. Page class sẽ tìm các server control được post back, sau đó kiếm tra xem control nào implement interface IPostBackDataHandler để gọi hàm LoadPostData( ) của control đó. Asp:TextBox không quan tâm đến giá trị đã lưu trước đó, mà chỉ cần lấy giá trị mới nhất lúc post back, set trở lại vào trong control.

Điều này không có nghĩa là ta không cần viewstate và chỉ cần implement interface này là đủ. Tùy trường hợp ví dụ như asp:DropdownBox, nếu ta không lưu lại giá trị trước đó và so với giá trị mới khi post back thì không thể nào biết được sự kiện OnDropdownlistChange được.

Phần cuối chươngchương nói về cách implement một user control. Nó cũng đơn giản như viết 1 trang web (trừ ext .ascx, không có thẻ html, body, form) nên cũng không có gì để nói :-)

Lời mở đầu

2007-09-29T17:00:00.001+07:00

Ý tưởng này xuất phát từ cái blog của David Hayden, thấy phần book review của ổng hay, đơn giản chỉ là comment lại những gì mình đã đọc.

Còn cái blog title thì chôm từ blog của Joe on Software

Để xem cuốn nào cần comment trước đây :-D, các cuốn mình đang review là:

Hibernate in Action.
Lucene in Action.
ASP.NET 2005 Server Control and Development.
Agile Principles and Practices (C.Robert Martin)

Nói chung cuốn nào cũng hay và cực kỳ căn bản, đọc lại lần nào cũng có cái hay riêng :-D