NHibernate query analyzer

(Bài viết này dành cho những ai đã từng sử dụng NHibernate)

Để test những câu Hibernate query, mọi người thường sử dụng Unit test để kiểm tra hoặc viết một app đơn giản để thử nghiệm. Tuy nhiên, có một công cụ khá hữu hiệu để ta có thể làm việc này một cách dễ dàng: NHibernate Query Analyzer. Công cụ này được phát triển bởi Ayende Rahien.
Mọi người có thể download nó về tại đây: http://www.assembla.com/wiki/show/NHibernateQueryAnalyzer


Mình sử dụng NHibernate Query analyzer từ những ngày đầu tiên nó được phát triển (cách đây gần 2 năm). Qua một thời gian, tool này được upgrade lên khá nhiều và cập nhật với phiên bản của NHibernate mới (2.1).

Tool này khá hữu hiệu. Tuy nhiên hơi bị khó xài. Mà hình như tool nào do developer tự phát triển cũng đều khó xài (just funny). Đặc biệt là lúc config ở giai đoạn đầu dễ gặp nhiều vấn đề.

Dưới đây là một số step cơ bản mọi người có thể làm theo để chạy được nó:
1. Add vào assembly dll chứa các entity cần map.

 

2. Add file hibernate config vào. File này mặc định là: hibernate.cfg.xml chứa những tham số để thiết lập connection đến database và config cho việc query.

Dưới đây là một file config sample để mọi người tham khảo. Lưu ý là file này phải đặt tên có extension là cfg.xml thì sẽ giúp bạn add nó vào Hibernate Query Analyzer tool dễ dàng hơn.

Vì NHibernate Query Analyzer đã upgrade để tương thích với NHibernate 2.1 nên schema của file config cũng khác đi => dễ gặp báo lỗi invalid xml syntax. Tốt nhất bạn nên sử dụng sample dưới đây (sửa lại db connection string)

 
  True=1;False=0
  true
  NHibernate.Driver.SqlClientDriver
  NHibernate.Dialect.MsSql2005Dialect
  NHibernate.Connection.DriverConnectionProvider
  Data Source=TIGER\SQLEXPRESS;Database=TinyERP;User ID=sa;Password=1234;
 

3. Add các file mapping.
Lưu ý đặc biệt: nếu như bạn đã build mapping files như embeded resources trong các assembly, thì không cần làm bước này. NHibernate query analyzer sẽ tự detect trong các assembly. Nếu bạn vẫn add vào thì sẽ bị báo lỗi: duplicate entity declaration.

4. Build project.

5. Tạo query
Trong ví dụ này mình tạo 2 bảng: User và UserGroup. 1 User liên kết với 0-1 UserGroup.
Câu query mẫu để lấy thông tin user và sort theo group name:

select user from User user left outer join user.UserGroup order by user.UserGroup.Name

Có thể xem câu sql sinh ra do NHibernate ở bottom textbox.
Click F5 để run và xem kết quả:

Nếu bạn gặp vấn đề với cấu hình để chay NHibernate Query Analyzer thì có thể contact mình.


---------------------------------------
Đang chuẩn bị cho một khóa training về NHibernate. Có ai đặt hàng hông? :)

Lập trình ôm (pair programming)

High cohesion - Loose coupling và Xích Bích

Nhân xem phim Đại chiến Xích Bích, chợt nghĩ ra một sự liên hệ giữa nguyên nhân đại bại của Tào Tháo và nguyên lý High cohesion - Loose coupling(1).

Tào Tháo nghĩ rằng việc liên kết các chiến thuyền lại càng vững chắc thì sẽ làm tăng sức mạnh của thủy quân. Tuy nhiên, ông đã vi phạm một sai lầm nghiêm trọng.

1/ Mỗi chiến thuyền là một đơn vị thủy quân tương đối độc lập. Khi có một biến cố xảy ra, họ luôn nghĩ đến chính mình trước. Do đó, việc đầu tiên họ làm khi gặp biến cố là cố gắng tách mình ra khỏi sự ảnh hưởng từ các chiến thuyền khác. Vì liên kết giữa các chiến thuyền quá chặt, nên việc tách thuyền trở thành vô vọng. Quân lính vừa phải đối phó với liên minh Lưu - Tôn, vừa phải cố gắng tách mình ra khỏi sự ảnh hưởng xung quanh. Chỉ cần dùng một lực lượng nhỏ cũng đủ phá tan quân Tào. => Vi phạm tính chất loose coupling.

2/ Từng chiến thuyền của Tào Tháo về thực chất không mạnh. Quân Tào từ phía Bắc không thông thạo sông nước (Yếu tố con người). Thuyền không đủ vững chải (Yếu tố vật chất). Mỗi chiến thuyền không đủ mạnh thì rất dễ bị tác động bởi những biến đổi xung quanh. => Vi phạm tính chất high cohesion.


3/ Kết hợp 2 ảnh hưởng trên, quân Tào bị rối loạn, hoang mang về tâm lý. Cái hiệu ứng đám đông kinh khủng ấy làm cho quân Tào tự giẫm đạp lên nhau mà chết. Kẻ chết vì lửa thì ít, kẻ chết vì hỗn loạn thì nhiều vô kể.
------------------------------------

Nhân tiện, viết lại trận Xích Bích theo một góc nhìn khác từ phần mềm: (Mong tác giả La Quán Trung quá cố đừng chấp tại hạ)

Tào Tháo là con của một quan chức nhà nước. Tận dụng thế lực hùng hậu của cha mình, Tào đã lập ra một công ty lấy tên là Tào Gia, chuyên nhận những dự án nhà nước với kinh phí rất lớn. Nhờ đục khoét và khéo lo lót nên chẳng bao lâu đã trở thành công ty đứng đầu trong ngành phần mềm Việt Nam.

Cùng thời điểm đó, có 2 công ty cũng đang ăn nên làm ra. Một là công ty của Lưu Bị - làm outsourcing cho một số dự án vừa và nhỏ từ US và Châu Âu. Xuất thân của Lưu Bị nghèo hèn, đã từng có lúc phải nhận những dự án freelancer giá vài chục đến vài trăm USD để kiếm sống qua ngày. Nhờ lăn lộn nhiều nên Bị tụ tập được nhiều người giỏi trong làng phần mềm. Chẳng bao lâu, Bị khuếch trương được thanh thế và trở thành một công ty có tên tuổi ở Việt Nam

Công ty thứ hai là công ty của Tôn Quyền. Tôn Quyền là con nhà giàu có, thế phiệt. Cũng may không ăn chơi hút hít, mà lại hứng thú làm ăn. Quyền được cha cho học ngành CNTT rồi sau đó mở cho một công ty Trách nhiệm hữu hạn lấy tên là: Công ty TNHH giải pháp Tôn Hành Giả.

3 công ty của Tào, Lưu, Tôn đã trở thành 3 công ty phần mềm lớn nhất ở VN thời đó. Tuy nhiên, so về thế và lực, thì Lưu và Tôn còn kém xa so với Tào.

Một ngày nọ, hãng phần mềm Microsoft đến Việt Nam và đặt hàng làm một dự án về ERP lớn nhất chưa từng có - trị giá 35 tỳ USD. Đây là một hợp đồng rất béo bở. Trong cuộc đấu thầu có cả 3 công ty: Tào, Lưu, Tôn. Nhờ có quen biết và khéo léo làm PR, Tào nghiễm nhiên trở thành công ty nhận được 60% hợp đồng. Lưu và Tôn chỉ được nhận làm một số module của 40% còn lại.

Tào sau khi nhận dự án đã huy động một lực lượng gần 3000 nhân viên để xây dựng phần chính của sản phẩm. Ông được một Technical Architect quạt mo bày cho một thiết kế kiến trúc gần 300 system component. Technical Architect của Tào chưa có nhiều kinh nghiệm. Hắn tạo ra một bản vẽ kiến trúc với những mối liên hệ gắn kết chặt giữa rất nhiều component một cách vô tội vạ. Mỗi component được triển khai bởi một team gần 10 người.

Lưu và Tôn sau khi thất bại đấu thầu quyết tâm liên kết để đánh bại Tào. Những phần component còn lại của hệ thống không quá phức tạp nên Lưu và Tôn đã nhanh chóng hoàn thành với chất lượng rất tốt. Lưu Bị có một Project manager rất giỏi là Gia Cát Lượng. Ông này ngoài tài quản lý, kĩ thuật còn có khả năng tư vấn khách hàng rất tốt. Lượng nhờ có uy tín nên ít lâu sau đã được mời về làm ở bộ phận tư vấn cấp cao về tính năng sản phẩm ERP đang xây dựng.

Bằng sự khôn khéo và có chuẩn bị trước, Lượng đã đệ trình một danh sách gồm: những điểm yếu về tính năng cũ, danh sách những tính năng mới, thống kê về thói quen, nghiệp vụ của khách hàng cho Microsoft và yêu cầu thay đổi trên hệ thống đang phát triển hiện tại

Bản danh sách này nhanh chóng được Microsoft chấp thuận. Hậu quả của nó là: 90% thay đổi về yêu cầu nằm trên những system component mà Tào đang phát triển.

Vì các system component của Tào được xây dựng phụ thuộc nhau quá chặt chẽ. Một thay đổi nhỏ cũng ảnh hưởng dây chuyền đến hàng loạt những thành phần khác. Sự thay đổi yêu cầu này như một ngọn lửa bùng lên và lan đi khắp các bộ phận phát triển của công ty Tào Gia.

Mỗi nhóm thay vì tìm cách để thay đổi thiết kế cho thích hợp, lại chuyển sang tranh luận để làm cách nào cho module của mình không bị ảnh hưởng bởi những module khác - đẩy trách nhiệm thay đổi cho các nhóm khác. Họ cố gắng tách mình ra khỏi sự ảnh hưởng xung quanh.

Thêm vào đó, nhân viên của Tào tuy đông nhưng không giỏi. Điều đó dẫn đến mỗi component được thiết kế hết sức sai về những nguyên tắc hướng đối tượng. Các class trong mỗi component được không có tính liên kết chặt chẽ. Mỗi khi cần sửa thì phải thay đổi ở nhiều chỗ. Có những thay đổi buộc phải thay đổi cả interface giao tiếp với bên ngoài.

Sau 3 năm hì hục để sửa chữa và đáp ứng những yêu cầu mới mà vẫn không có kết quả. Microsoft tuyên bố cắt hợp đồng với Tào. Đồng thời buộc Tào phải bồi thường 20% giá trị hợp đồng. Những component của Tào đang xây dựng được chuyển qua outsource cho 2 công ty Lưu và Tôn.

Sau hợp đồng thất bại thảm hại, thanh thế của Tào sa sút. Cũng may nhờ một quỹ đầu tư mạo hiểm thấy Tào còn có tiềm năng nên đã bỏ tiền để vực dậy công ty Tào Gia. Từ đó, 3 công ty Tào, Lưu, Tôn dựng nên một thế chân vạc trong ngành phần mềm Việt Nam.

Nghe đâu sau đó tay Technical Architect quạt mo kia bị Tào Tháo sa thải. Về sau có người đồn rằng thấy hắn tham gia bid một vài project nho nhỏ trên rentacoder để kiếm sống qua ngày. Hư thật thế nào cũng không rõ.
Hết.

Ghi chú:
Hic, vừa post lên thì nhận được hơn 10 cái message hỏi Tào Tháo là công ty nào, dự án nào mà to thế, ... Xin đính chính lại: đây là sản phẩm của trí tưởng tượng của mình - chỉ muốn mượn hình ảnh của đại chiến Xích Bích mà nói về Loose coupling và High Cohension mà thôi.

Lần sau sẽ chú thích rõ ràng hơn. :)

(1) High cohesion - Loose coupling là một nguyên lý thiết kế hướng đối tượng, trong đó nói rằng:
Các class trong mỗi package phải có mối quan hệ chặt chẽ với nhau để tạo nên một thực thể bền vững (cohesion = tính cố kết). Các package trong hệ thống phải có mối quan hệ phụ thuộc (coupling) càng lỏng lẻo càng tốt để đảm bảo tính độc lập - ít bị ảnh hưởng khi có sự thay đổi

Highlight syntax với blogger

Là dân software, việc post bài trên blog có kèm theo những đoạn mã nguồn được highlight syntax là một nhu cầu rất thường gặp.

SyntaxHighligher là một thư viện javascript mã nguồn mở để hỗ trợ bạn làm việc này khá dễ dàng.
Bạn có thể vào link dưới đây để đọc thêm chi tiết

Trang chủ wiki của Syntax Highligher

Nếu bạn ko có host riêng thì có thể đọc bài viết này để setup trên blog của blogger hoặc các blog platform khác.

Cài đặt SyntaxHightlighter trên blogger

Dưới đây là đoạn code được highlight syntax demo sau khi setup.
Đoạn code này demo cho ý tưởng của một người bạn. Just funny!

bool stillAlive = true;
object knowledge = null;
object experience = null;
object idea = null;

double money = 0;
while(stillAlive && money < ONE_MILLION_DOLLAR) {
    idea = Thinking();
    knowledge = Research();
    double moneyFromWorking = 0;
    experience = Working(out moneyFromWorking);
    money += moneyFromWorking;
    IList investors = FindInvestors(idea);
    money += Invest(idea, knowledge, experience, investors, money);
}

Những câu hỏi về Extreme Progamming?

Xem tại Question of extreme programming

Sự năng động của tuổi trẻ và kinh nghiệm tuổi già trong ngành phần mềm

Trong một buổi training + open talk về kĩ thuật cho công ty của một người bạn, có một bạn trẻ đặt cho tôi 2 câu hỏi:
1/ Em thấy nhiều người cho rằng kinh nghiệm của những người đi làm lâu năm chiếm ưu thế hơn so với sự nhạy bén và sáng tạo của tuổi trẻ - theo anh, quan điểm này đúng hay sai? Em cảm thấy rằng, người trẻ thường nhanh nhạy trong việc giải quyết vấn đề. Và em nghĩ đây mới là điều quan trọng trong ngành phần mềm.

2/ Em nghĩ rằng tuổi thọ của ngành phần mềm chỉ dừng lại ở độ tuổi 40. Vì sau thời điểm đó, con người không còn đủ sự nhanh nhạy và sáng tạo nữa - mà sáng tạo chính là yếu tố sống còn đối với một người đi theo ngành này. Vậy điều này có đúng không? Nếu đúng, anh hãy cho em 1 lời khuyên: em nên làm gì khi ở tuổi 40?

Tôi nghĩ rằng đây là cũng là thắc mắc của khá nhiều người. Vì vậy tôi post 2 câu hỏi này lên đây để chúng ta cùng trao đổi.

Dưới đây là nguyên văn câu trả lời của tôi cho bạn trẻ đã nêu ra 2 câu hỏi trên:
1/ Anh đánh giá rất cao sự sáng tạo và nhạy bén của tuổi trẻ. Ngành phần mềm hay bất cứ ngành nào khác đều rất cần sự sáng tạo. Tuy nhiên, kinh nghiệm cũng là một yếu tố rất quan trọng. Kinh nghiệm giúp ta định hướng vấn đề đúng đắn hơn. Một cách dễ hình dung, có thể xem rằng:

Sự sáng tạo của người trẻ thường giúp trả lời nhanh cho câu hỏi: HOW, WHAT.
Kinh nghiệm của người già thường giúp trả lời nhanh câu hỏi WHY

Biết HOW, WHAT, mà không trả lời được WHY thì sẽ không định hướng được và không hiểu được bản chất vấn đề. Biết WHY, mà không trả lời được HOW, thì sẽ không hiện thực được bất cứ điều gì.

Tuy nhiên, WHY là câu hỏi được đánh giá quan trọng nhất trong cuộc sống. Nếu nhìn lại lịch sử của khoa học, tất cả mọi phát minh, tri thức của nhân loại phần lớn đều bắt đầu từ câu hỏi TẠI SAO. Chính vì vậy, kinh nghiệm được ưu tiên hơn một chút so với sáng tạo. Tuy nhiên, điều này không hẳn hoàn toàn đúng - vì nó còn phụ thuộc vào hoàn cảnh cụ thể.

Nên kết hợp cả hai yếu tố này để tối đa hóa sức mạnh sẵn có của chúng.

2/ Nếu nhìn lại những cây đại thụ trong ngành phần mềm: Robert C. Martin, Kent Beck, Martin Fowler... Phần lớn họ là những người đã vượt qua 40 tuổi. Tuy nhiên, ngày nay họ vẫn tiếp tục đóng góp rất nhiều cho ngành phần mềm và đạt được nhiều thành công trong cuộc sống.

Như anh đã đề cập ở trên, sáng tạo là cần thiết nhưng ko phải là tất cả. Khi có nhiều kinh nghiệm, em sẽ được sắp xếp ở vị trí để em phát huy tối đa sức mạnh đó - và thường là những vị trí quan trọng. Cũng không ai nói rằng người già thì không còn sáng tạo. Giá trị của những sáng tạo ở tuổi già thường đem lại những đóng góp vĩ đại vì nó được thai nghén và kết hợp với kinh nghiệm thực tiễn.

Do đó, đừng quá lo sợ. Điều đáng sợ nhất là: mình đã quá già nhưng không có kinh nghiệm mà cũng không có sự sáng tạo.


Anh không thể cho em lời khuyên ở tuổi 40, nhưng anh có thể cho em lời khuyên ở hiện tại: hãy cố gắng rèn luyện bản thân, nâng cao kinh nghiệm trong công việc, trau dồi kiến thức. Và điều cơ bản hơn cả là: hãy đam mê. Trong bất cứ ngành nghề nào, nếu leo đến đỉnh cao sự nghiệp cũng đều đem lại vinh quang như nhau.

Những câu hỏi trong một khóa đào tạo leadership

Công ty cho mình học một khóa đào tạo về leadership - management. Dưới đây là một số câu hỏi/ câu trả lời nghĩ ra trong đầu sau 2 buổi học đầu tiên. Có thể câu trả lời sẽ không giống với những gì tôi đã học. Tuy nhiên, đó là những gì tôi đã chiêm nghiệm.
Có một số câu hỏi tôi không muốn trả lời - tôi mong đợi ý kiến phản hồi của các bạn.



1/ Sự khác nhau giữa quản lý (management), quản lý dự án (project management), quản lý dự án phần mềm (software project management) là gì?
Trả lời:
a. Quản lý là một hoạt động bao gồm 4 chức năng: leading (lãnh đạo), controlling (điều khiển), tracking (theo dõi) và planning (lên kế hoạch)
b. Quản lý dự án là việc áp dụng 4 chức năng này vào những dự án cụ thể
c. Quản lý dự án phần mềm: giống với quản lý dự án nhưng dành cho đặc thù của lĩnh vực phần mềm

2/ Sự khác nhau giữa leading và management:
Trả lời:
Có 2 quan điểm chủ yếu:
Quan điểm 1 (theo kiến thức từ khóa học):
+ Management là việc quản lý con người nói chung. leading là thiên về quản lý NHÓM.
+ Leading hiểu theo nghĩa tiếng Việt là lãnh đạo - sẽ bao hàm việc định hướng - vạch ra chiến lược - điều khiển - kiểm soát một nhóm để đạt được mục tiêu chung. Management chỉ vạch ra mission và goal ở mức tổng thể - không bao hàm việc định hướng/ điều khiển nhóm để đạt được mục tiêu ở mức hiện thực chi tiết.
Quan điểm 2 (quan điểm từ bản thân và một số kiến thức trước đây):
+ Leading là một trong những chức năng của management.
+ Một người làm management thực ra luôn luôn thực hiện 4 chức năng: leading, controlling, tracking và planning. Tuy nhiên việc phân bổ trọng số cho 4 chức năng này sẽ khác nhau tùy vào vị trí của cấp quản lý.
+ Có 3 cấp quản lý chính: quản lý cấp thấp (thiên về controlling + tracking + leading), quản lý cấp điều hành ( thiên về leading), và quản lý cấp cao (thiên về planning).
3/ Dự án phần mềm có gì đặc thù so với những loại dự án khác? Quản lý dự án phần mềm khác gì so với quản lý dự án?
Trả lời:
Dự án phần mềm là loại dự án đặc thù gồm các đặc điểm:
+ Là kết tinh bởi chất xám và sự hợp tác giữa nhiều con người trong một nhóm. Do đó việc quản lý dự án phần mềm có xu hướng thiên về con người.
+ Việc đánh giá sự đóng góp của con người trong dự án phần mềm không có một độ đo cụ thể và chính xác so với những loại dự án khác.
+ Việc gia tăng số lượng người trong một nhóm sản xuất không tỉ lệ thuận với việc thúc đẩy tiến độ dự án. Do đó trong quản lý dự án phần mềm không thể áp dụng nguyên tắc dùng số đông để đẩy nhanh tiến độ.
+ Việc lãnh đạo một nhóm sản xuất phần mềm không chỉ đơn thuần là việc đưa ra phương hướng và bắt người khác đi theo như những loại dự án khác. Nó đòi hỏi việc truyền cảm hứng và tạo sự đồng thuận cho nhóm để bám sát và hoàn thành mục tiêu.
+ Quản lý dự án phần mềm đòi hỏi người quản lý phải có kiến thức tốt về phần mềm để đưa ra những quyết định, kế hoạch hợp lý.
Câu hỏi bổ sung: liệu một người đã từng làm tốt vị trí quản lý dự án nhưng ít kinh nghiệm quản lý dự án phần mềm có thể quản lý tốt một dự án phần mềm?
Trả lời: đợi ý kiến phản hồi

4/ Chọn ra những tính cách và kĩ năng quan trọng nhất của một người lãnh đạo giỏi?
Trả lời

Tôi không muốn lặp lại những điều đã học trong lớp - vì đây là một câu hỏi đã có câu trả lời trong buổi thảo luận. Tuy nhiên quan điểm của tôi là việc lựa chọn này tùy thuộc vào phong cách lãnh đạo phù hợp.
Mỗi người có thể lựa chọn cho mình một phong cách lãnh đạo khác nhau. Với mỗi phong cách sẽ có một tập những tính cách và kĩ năng cần trau dồi khác nhau.

Ở những hoàn cảnh/ môi trường/ tập thể con người cụ thể phải có một phong cách lãnh đạo khác nhau vì để lãnh đạo hiệu quả thì không thể áp dụng cùng một phong cách cho mọi hoàn cảnh.

5/ Đỉnh cao của nghệ thuật quản lý là gì?
Trả lời:
Quan điểm 1 (từ một người bạn): đỉnh cao của nghệ thuật quản lý là quản lý mà người được quản lý không có cảm giác đang bị quản lý.
Quan điểm 2 (quan điểm của tôi): đỉnh cao của nghệ thuật quản lý là định hướng và tạo ra những con người có thể tự quản lý chính mình và làm tốt những gì mình cần làm trong tổ chức.

Quan điểm n: đợi phản hồi của mọi người.