Thế giới sẽ xem phim như thế nào 10 năm nữa

Đã từ lâu rồi, công việc và những suy nghĩ mệt mỏi làm cho trí tưởng tượng của tôi không còn hoạt động tốt. Cuối tuần, dành vài giờ ra công viên ở q7 để thư giãn. Chạy về ngang qua rạp chiếu phim ở Cao Thắng, trong tôi bỗng lóe lên một câu hỏi: trong 5 đến 10 năm nữa nhân loại sẽ xem phim như thế nào? Tôi cứ đắm chìm trong những suy nghĩ điên rồ và mơ mộng ấy mãi cho đến lúc về đến nhà.

Tôi vẽ lại viễn cảnh ấy trong tương lai để chia sẻ cho bạn – người đang đọc bài viết này. Mục đích của tôi rất đơn giản: những ý tưởng khó thực hiện cần được chia sẻ và truyền tải cảm hứng đến cho nhiều người để xác suất hiện thực của nó tăng lên. Bạn cũng có thể cho rằng tôi là một kẻ điên rồ. Tuy nhiên, tôi vẫn kì vọng những ý tưởng điên rồ có thể làm nên những cuộc cách mạng.

Ý tưởng 1: K-Film

K-Film là khái niệm do tôi tạm nghĩ ra để mô tả về một thể loại phim có cốt truyện được phát triển theo nhiều nhánh. Nếu bạn đi từ nút gốc đến nhánh lá cuối cùng, bạn sẽ có một câu chuyện với nội dung hoàn chỉnh. (Khôi hài một chút: K là chữ cái bắt đầu tên tôi, nhưng nhìn kĩ lại bạn sẽ thấy nó giống một cành cây có 2 nhánh chỉa ra ngoài)

Trong giấc mơ của tôi vào 10 năm nữa, bạn sẽ thấy câu chuyện sau đây:
Hôm nay, rạp sẽ khởi chiếu bộ phim "Bạch Tuyết và 7 chú lùn". Có một chàng trai dẫn bạn gái mình vào rạp xem phim. Hai người sẽ được phát cho một thiết bị gắn vào trán để xem phim cùng nhau. Thiết bị này hiện nay gọi là Head mounted display (HMS) - đã được phát triển từ rất lâu trong công nghệ thực tế ảo. Tuy nhiên, tôi cố tình thêm chức năng cho nó. :)

Đến đoạn mụ phù thủy đem chiếc lược đến để bán cho công chúa, màn hình trước mắt họ sẽ hiện ra câu hỏi:
Bạn muốn xem tiếp nhánh phim nào?
a. Công chúa ngỏm vì chiếc lược nhưng được 7 chú lùn cứu sống.
b. Công chúa thấy mụ có vẻ gian quá, nên không cho mụ vào nhà và đuổi đi.


Anh chàng bảo cô gái: cốt truyện theo (a) đọc trong chuyện cổ tích thì ai cũng biết hết rồi. Anh với em xem nhánh (b) nghen?
Cô gái trả lời: uhm, được á.
...
Đoạn kế tiếp ko cần kể. :) Tuy nhiên, tôi kì vọng khái niệm K-Film này sẽ đem đến cho khán giả một trải nghiệm hoàn toàn mới. Có thể có hàng trăm, hàng ngàn người xem phim, nhưng mỗi người sẽ được thưởng thức một câu chuyện hoàn toàn khác biệt.

Ý tưởng này không có gì thách thức về kĩ thuật, mà chỉ là thách thức về yếu tố kinh tế (chi phí làm phim sẽ rất cao). Để hiện thực nó, có lẽ cần một nhà làm phim nào đó đi tiên phong để tạo thành một phong trào.

Ý tưởng 2: Y-Film

Y - Film (You - film): là thể loại phim trong đó người xem sẽ khám phá và trải nghiệm chính bản thân họ trong bộ phim. Có nhiều mức để hiện thực hóa khái niệm này:

Mức 1: người xem sẽ được quét hình ảnh khuôn mặt họ trước khi xem. Hình ảnh này sẽ được gắn vào nhân vật họ đã chọn. Điều này giúp họ hòa mình vào chính bộ phim đang thưởng thức.

Mức 2: người xem sẽ được đưa vào một căn phòng rộng, và khám giá một thế giới 3D thực tế ảo trong bối cảnh phim (tất nhiên là chỉ ngồi một chỗ). Họ có thể xem, nghe, nếm, ngửi để trải nghiệm mạnh mẽ hơn bối cảnh trong phim.

Mức 3: người xem sẽ được tham gia vào một bối cảnh hành động của phim. Ví dụ: có thể tham gia một trận đấu kiếm, cưỡi ngựa bắn súng, ... Cách thức tham gia vẫn sử dụng công nghệ thực tế ảo, bằng cách đeo thiết bị HMS như ý tưởng (1) nhưng có thể cần thiết bị phụ trợ.


Thật sự, 3 mức ý tưởng này đã được hiện thực và đưa vào cuộc sống rải rác trên thế giới.
+ Bạn có thể đã từng xem phim 4-D ở Đầm Sen, Suối Tiên, ... (mức 2).
+ Ở Disney Land, cách đây 10 năm đã từng có những trò chơi thực tế ảo - cho phép bạn tham gia hành động thật - chứ không thao tác trên máy tính hay máy playstation (mức 3).
+ Tôi đã từng tham gia vào một dự án kĩ thuật cho phép hiện thực hóa mức 1 của ý tưởng này.
Tuy nhiên, chưa từng có một bộ phim nào đình đám trong làng giải trí áp dụng chúng để tạo nên một cuộc cách mạng trong nghệ thuật thứ 7 (có thể yếu tố kinh phí đã tác động khá lớn).

Leonardo Da Vinci đã từng ôm ấp những giấc mơ đến tận cuối đời. Ông có rất nhiều phát kiến, nhưng không đủ khả năng để hiện thực. Trong những bản thảo của ông tìm thấy sau này, người ta thấy ông vẽ gương mặt mình và những đường nguệch ngoạc khi bế tắc cách hiện thực.

Tôi không kì vọng được vĩ đại như ông, nhưng tôi có cái may mắn hơn là được sinh ra vào thời có Internet. Thay vì vẽ gương mặt mình và những nét loằng ngoằng bế tắc, tôi truyền cảm hứng của tôi cho những người có khả năng qua bài viết này trên blog ...

Biết đâu nhỉ, chờ 10 năm nữa nào.

ASP.NET MVC + kiến trúc plugin

Trước đây, tôi xây dựng một CMS framework trên ASP.NET lấy ý tưởng từ Joomla. Tôi đã sửa đổi một vài điểm yếu của kiến trúc trong Joomla từ cơ chế phân quyền, cơ chế đóng gói component, ... Vì không có nhiều thời gian nên tôi chưa phát triển hoàn chỉnh framework này. Tuy nhiên, điều tôi rất thích trong Joomla là kiến trúc plugin. Gần đây, khi ASP.NET MVC xuất hiện, câu hỏi đầu tiên trong đầu tôi là: làm sao để có thể phát triển kiến trúc plugin với ASP.NET MVC.

Thực ra vấn đề khó khăn để triển khai kiến trúc plugin cho ASP.NET MVC là: làm sao để đóng gói tất cả Model, View, Controller của một component vào một dll. Nếu giải quyết được bài toán này thì phần còn lại chỉ là tạo ra một cơ chế để load component dll và chạy plugin lúc runtime (vấn đề này thì quá đơn giản).

Vì ko có nhiều thời gian, nên chưa kịp đi tìm câu trả lời. Hôm qua, đọc một article liên quan đến vấn đề này. Đây chính là câu trả lời cho bài toán tôi đặt ra.

http://www.wynia.org/wordpress/2008/12/05/aspnet-mvc-plugins/

Tuyệt vời.
Thanks J Wynia vì đã chia sẻ bài viết này.

Những cân nhắc khi xây dựng một phần mềm nguồn mở

Phần mềm nguồn mở đang là một xu hướng phát triển trong những thập niên gần đây. Tuy nhiên việc xây dựng phần mềm nguồn mở có nhiều khó khăn đòi hỏi bạn phải suy nghĩ thật kĩ trước khi bắt tay vào hiện thực. Trước đây, tôi có cơ hội làm việc với một số nhóm phát triền mã nguồn mở (phần lớn là do tôi tự thành lập hoặc tham gia part time như một thành viên phát triển). Có một vài kinh nghiệm tôi muốn chia sẻ với các bạn.

Trong bài viết này, tôi liệt kê những điều bạn cần cân nhắc trong bước đầu tiên xây dựng phần mềm nguồn mở:
(Từ phần mềm trong bài này để chỉ chung các sản phẩm/ thư viện/ tiện ích)

Mục tiêu của phần mềm

Sự ra đời của một phần mềm phải giải quyết được bài toán/ vấn đề trong thực tế. Hãy xem xét đánh giá những giải pháp tồn tại trên thị trường để xác định lý do tồn tại phần mềm của bạn. Nếu không xác định chính xác mục tiêu, phần mềm của bạn rất dễ bị "đào thải" trong quá trình phát triển. Dưới đây là một số mục tiêu mà tôi cho rằng dễ làm bạn bị thất bại:

1. Trên thị trường đã có phần mềm tương tự, tuy nhiên nó không "mở" để cho tôi phát triển tiếp. => Cẩn thận, để chiến thắng được đối thủ - bạn phải làm tốt hơn họ. Nếu chọn mục tiêu này, bạn phải chạy đua với đối thủ đã vượt qua mặt bạn khá xa - nếu bạn phải xây lại từ đầu.

2. Tôi muốn xây dựng một giải pháp của riêng tôi để không bị phụ thuộc vào những phần mềm khác. => Nhu cầu nghiệp vụ của bạn có đủ lớn về giá trị kinh tế để phải suy nghĩ về mục tiêu này? Google có thể bỏ ra 5-10 triệu USD xây dựng lại cái bánh xe để đáp ứng được mục tiêu kinh doanh. Tuy nhiên, bạn có lớn như google? Hãy thử so sánh chi phí giữa việc xây dựng từ đầu và mua phần mềm xem nó có sự chênh lệch quá lớn hay không trước khi đi tiếp.

3. Tôi xây dựng phần mềm này để cống hiến cho cộng đồng => Ít ai có thể sống được bằng niềm tin và đam mê. Liệu đội ngũ phát triển của bạn có thể đi tiếp nếu họ không có đủ "thực" để vực được "đạo".

...

Lợi nhuận từ phần mềm

Không ai có thể phủ nhận được kinh tế là điều cốt lõi của cuộc sống. Phát triển phần mềm không thể tồn tại nếu không có nguồn đầu tư và lợi nhuận.
Hãy đặt cho mình 2 câu hỏi lớn cho cân nhắc này:
1/ Ai sẽ đầu tư cho phần mềm?
2/ Những cách để kiếm tiền từ phần mềm?

Giấy phép bản quyền

Trong cộng đồng nguồn mở, giấy phép bản quyền (license) là một yếu tố rất quan trọng. Nó chính là giấy thông hành để giúp bạn phân phối, kinh doanh, tìm kiếm cộng đồng đóng góp cho phần mềm.

Bạn cũng có thể tạo ra một license của riêng bạn. Tuy nhiên nên tham khảo một số license phổ biến trước khi quyết định.

Đây là link liệt kê các license mã nguồn mở mà bạn có thể tham khảo.

Những license phổ biến 1
Những license phổ biến 2
So sánh đặc điểm của một số license phổ biến

Những thư viện cần sử dụng

Ngày nay, không ai đi xây một căn nhà bắt đầu từ việc sản xuất xi măng, gạch và vữa. Phần mềm cũng vậy. Hãy lựa chọn những thư viện, công nghệ cần thiết cho phần mềm của bạn để giảm đi chi phí phát triển.

Một điều lưu ý là: nếu thư viện bạn dùng là mã nguồn mở - hãy xem xét xem license của nó có mâu thuẫn với license mà bạn đang chọn hay không? Trước đây khi làm một dự án với một trong những hãng viễn thông hàng đầu của Nhật, tôi ngạc nhiên khi thấy họ lựa chọn rất cẩn thận những thư viện trong quá trình phát triển. Tôi và một người bạn đồng nghiệp phải viết lại từ đầu một thư viện taglib gần giống như DisplayTag (một thư viện rất nổi tiếng để hiển thị lưới dữ liệu trên web của Java) - chỉ vì một lý do đơn giản: license của nó là GPL. Đây là license không phù hợp với tôn chỉ của họ.

Đường hướng phát triển của phần mềm (Roadmap)

Đường hướng phát triển là một trong những yếu tố quan trọng để bạn định hướng cho phần mềm. Nó giúp bạn:
+ Giữ cho phần mềm của mình không đi lệch mục tiêu so với ban đầu.
+ Giúp cho đội ngũ phát triển biết được mình cần làm gì để đạt được mục tiêu.
+ Đối tượng sử dụng phần mềm đánh giá đúng để lựa chọn sản phẩm
+ Tạo ra niềm tin và kì vọng cho đối tượng sử dụng phần mềm
Đường hướng phát triển của phần mềm không nên được ấn định cứng nhắc ngay từ thời điểm ban đầu. Nó nên được cập nhật sau mỗi phiên bản phát hành từ những ý kiến và đóng góp của cộng đồng.

Đội ngũ phát triển

Có 3 nhóm đối tượng chính của đội ngũ phát triển phần mềm nguồn mở

1/ Nhóm phát triển chính: là những người đóng góp chính cho phần mềm
2/ Lập trình viên tự do: là những người tham gia đóng góp những sửa đổi nhỏ, không thường xuyên qua các dạng phản hồi hoặc các tiện ích liên quan.
3/ Người dùng phần mềm: người dùng phần mềm cũng được xem là đối tượng của đội ngũ phát triển. Họ đóng góp cho phần mềm thông qua những phản hồi, báo lỗi, yêu cầu cải tiến, ...

Một phần mềm nguồn mở nên được phát triển bởi một đội ngũ phát triển chính có tâm huyết và cùng chí hướng. Vì vậy, người trưởng nhóm cần lựa chọn cẩn thận những thành viên phù hợp trước khi bắt tay xây dựng.

Công cụ và môi trường phát triển

Dưới đây là một số yếu tố liên quan đến công cụ và môi trường phát triển cần được cân nhắc trong quá trình phát triền phần mềm nguồn mở:

+ Công cụ quản lý phiên bản (SVN và CVS là 2 công cụ được ưa chuộng nhất hiện này)
+ Forum để trao đổi, thảo luận giữa nhóm phát triển và cộng đồng, hoặc giữa các thành viên của nhóm
+ Wiki: được dùng như nơi để ghi nhận các khái niệm, hướng dẫn sử dụng, tài liệu kĩ thuật được công bố.
+ Bug/issue tracker: công cụ để quản lý các bug/issue diễn ra trong quá trình phát triển. Yêu cầu/ phản hồi/ task cũng được xem xét như là một issue trên công cụ này.

Phương pháp luận và quy trình phát triển

Đây là yếu tố quy định linh hồn của việc phát triển phần mềm. Mỗi nhóm phát triển có thể chọn cho mình một phương pháp luận riêng. Tuy nhiên các phương pháp luận trong trường phái Agile rất được ưa chuộng trong giới phát triển nguồn mở.
2 best practice trong Agile thường được áp dụng là

1/ Tích hợp liên tục
2/ Test first

Tôi sẽ chia sẻ với các bạn nhiều hơn về phần mềm nguồn mở trong những bài viết sau.

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? :)

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

Kiến trúc sư phần mềm - anh là ai?

Là dân IT hẳn mọi người không còn xa lạ với cụm từ Software Architect (SA) - ở đây tôi tạm dịch là kiến trúc sư phần mềm. Tuy nhiên không phải ai cũng hiểu được vai trò, trách nhiệm, công việc thực sự và con đường sự nghiệp của một SA. Đây là những câu hỏi mà tôi đã từng đặt ra khi bước vào những nấc thang đầu tiên của vị trí này. Tôi tự đi tìm lời giải đáp cho mình.

Phân loại kiến trúc sư phần mềm

Thật ra có nhiều cách để phân loại kiến trúc sư phần mềm. Tuy nhiên, ở đây tôi sử dụng cách phân loại của Microsoft.  Đây cũng là một cách thức phân chia khá phổ biến trong ngành phần mềm hiện nay.

Tên	Mô tả
Kiến trúc sư nghiệp vụ (enterprise architect)	Là cầu nối giữa chủ sở hữu sản phẩm và đội ngũ kĩ thuật. Họ  là những người có kinh nghiệm chiều sâu trong lĩnh vực mà sản phẩm đang xây dựng. Chịu trách nhiệm trong việc xây dựng và phát triển yêu cầu - thiết lập viễn cảnh, bộ khung của môi trường IT trong sản phẩm.
Kiến trúc sư hạ tầng (infrastructure architect)	Là người chịu trách nhiệm trong việc thiết lập, xây dựng giải pháp về cơ sở hạ tầng IT (ví dụ: mạng, các vấn đề bảo mật, thiết bị/ phương thức lưu trữ, ..) trong sản phẩm để đáp ứng nhu cầu của doanh nghiệp.
Kiến trúc sư giải pháp (solution architect)	Là người chịu trách nhiệm trong việc thiết kế, xây dựng giải pháp cho những yêu cầu của sản phẩm.
Kiến trúc sư kĩ thuật (Technology-specific architect)	Là người chịu trách nhiệm về một hoặc một số lĩnh vực kĩ thuật cụ thể.

Trong một số công ty hiện tại ở Việt Nam, có một vị trí gọi là Technical Architect (kiến trúc sư kĩ thuật) trong tổ chức. Vị trí này chịu trách nhiệm cho việc phân tích, đánh giá giải pháp, xây dựng kiến trúc hệ thống. Nếu ánh xạ với cách phân loại trên thì TA chính là Solution Architect.

Những tính cách cần thiết của một kiến trúc sư phần mềm giỏi

Cho dù bạn có là kiến trúc sư phần mềm nào, thì dưới đây là những tính cách bắt buộc phải có để đạt được đỉnh cao của nghề này:

1. Nhạy bén về kinh tế: mọi kiến trúc sư khi đưa ra giải pháp cho bất cứ bài toán nào cũng đều phải cân nhắc chi phí, lợi ích tương quan của doanh nghiệp. Đây là yếu tố then chốt đánh giá hiệu quả của một giải pháp.
2. Có tầm nhìn xa: khi tham gia vào một dự án, kiến trúc sư phải cân nhắc những giải pháp, công nghệ sắp xuất hiện, xem xét những thay đổi gần đây trong lĩnh vực công nghiệp đang phát triển... và làm cách nào để tận dụng tối đa giải pháp hiện tại trong tương lai.
3. Nghiên cứu kĩ thuật mới: một kiến trúc sư phải luôn luôn nghiên cứu những hướng kĩ thuật mới, từ kiến trúc IT cho đến những ứng dụng và xu hướng phát triển ứng dụng
4. Hiểu và có khả năng ứng dụng những framework,kiến trúc hệ thống, phương pháp luận trong quá trình phát triển phần mềm
6. Có thể làm việc trên những thông tin còn chưa rõ ràng.
7. Khả năng truyền đạt và giao tiếp

Làm sao để tôi có thể trở thành một kiến trúc sư phần mềm

Kiến trúc sư phần mềm là đỉnh cao của thang nghề nghiệp khi bạn chọn đi theo con đường kĩ thuật. Để trở thành một kiến trúc sư phần mềm, bạn nên theo những bước sau:
1. Định hướng rõ ràng về loại kiến trúc sư phần mềm bạn muốn trở thành
2. Xác định và xây dựng những kĩ năng cần thiết. Liên tục bổ sung kiến thức phù hợp cho loại hình kiến trúc sư mà bạn chọn
3. Không ngừng phấn đấu và khẳng định vai trò của một kiến trúc sư trong chính những dự án mà bạn đang tham gia.
4. Cố gắng rèn luyện và lấy những chứng chỉ quốc tế về kiến trúc sư kĩ thuật của những tập đoàn công nghệ lớn (Microsoft hoặc Sun). Microsoft bạn cần lấy được MCA (Microsoft Certificate Architect). Đối với Sun, bạn cần lấy được chứng chỉ: SCEA (Sun Certificate Enterprise Architect)

Con đường để trở thành một kiến trúc sư phần mềm đỉnh cao và chuyên nghiệp vẫn còn ở rất xa. Và có một điều tôi luôn tâm niệm là: dù ở bất kì ngành nghề nào, vị trí nào - việc phấn đấu để đạt được đỉnh cao trong sự nghiệp cũng đều đem lại những lợi ích như nhau so với những vị trí hoặc ngành nghề khác.

Cố gắng hơn nữa!

Request đi từ Windows live writer preview mode - tìm ra rồi

Vừa ăn Tết xong đã bị khách hàng dzí vì một issue trên plugin viết cho Windows Live Writer. Issue đơn giản như thế này:

Module mình vừa release là một plugin viết cho Windows Live Writer (một công cụ soạn thảo blog của Microsoft có thể tích hợp với nhiều blogging platform). Chức năng chính của module là cho phép tìm kiếm một số thông tin đặc biệt và nhúng nội dung tìm được vào cửa sổ blog editor của Windows Live Writer. Khách hàng mong đợi ở chế độ preview của editor này có thể nhìn thấy nội dung hiển thị như khi xem trên blog thật. Tuy nhiên, vì một số hạn chế kĩ thuật dưới đây nên ở preview mode, html content bị vỡ layout và không show được một số phần content liên quan đến business của khách hàng.
1. Windows Live Writer sử dụng một browser engine khác trong preview mode và chặn một số script đặc biệt
2. Cơ chế render nội dung của browser engine này xử lý không tốt cho CSS 2.0 => vỡ layout.

Chính vì những hạn chế này, product manager của khách hàng yêu cầu: chỉ render ra một nội dung HTML đơn giản (chỉ show image tag) ở chế độ preview mode.

Sau khi suy nghĩ về solution trong vài ngày đầu - mình hoàn toàn bị tắc nghẽn. Vì để làm được điều này ta cần biết được request nào đi từ Windows Live Writer và request nào đi từ browser mà user đang duyệt web bình thường. Biết được điều đó ta có thể chặn và render ra những đoạn javascript để sinh ra HTML đúng như mong đợi.

Dưới đây là những phương pháp tôi đã thử:
1. Phân tích http request header khi đi từ Windows Live Writer và request đi từ các browser khác.
Kết quả: hoàn toàn giống nhau. WLW sử dụng một browser engine build từ một version trước của Internet Explorer.
2. Kiểm tra URL referer ở phía client trên WLW và các browser khác:
Kết quả: đều bằng null. Điều này chứng tỏ: WLW preview page được render trực tiếp mà không đi qua trang trung gian nào

Đã trao đổi với technical team của khách hàng để họ hiểu được issue. Critical bug này được chuyển sang cho một developer của team họ để giải quyết. Kết quả: Họ cũng không có solution sau hơn 3 tuần mò mẫm.
Tuyệt vọng!!!

Ngày đầu năm, bị sếp dzí và cho biết khách hàng đang complain. Sếp yêu cầu viết mail cho Microsoft nhờ support. Lên trao đổi với anh T - production manager để giúp anh hiểu vấn đề về những khó khăn hiện tại.
Bước ra khỏi thang máy với cái đầu hoang mang trăm chuyện. Quyết định: uống một ly cafe cho sáng suốt. Đúng là cafe có tác dụng cho những hoàn cảnh như thế này. Uống xong bỗng lóe lên một hy vọng.
Phát hiện ra là mình chưa kiểm tra URL referer khi WLW request về phía server (lúc trước chỉ kiểm tra toàn http header).
Và dưới đây là kết quả:
Đứng từ WLW ở preview mode khi request về server thì URL Referer luôn bằng null. Thông thường, khi ta include một file javascript vào một trang - nếu chặn ở server ta sẽ thấy URL referer của request đến nó chính là URL của trang đang chứa đoạn script include này. Riêng với WLW, nó lại là NULL. Đây chính là tín hiệu giúp ta phân biệt được đâu là request từ Windows Live Writer và đâu là request đi từ browser bình thường.

Xong!

Tuyển dịch - Core J2EE patterns best practices and design strategies

Core J2EE patterns - best practices and design strategies là một trong những quyển sách hay dành cho lập trình viên - được biên soạn bởi Deepak Alur, John Crupi, Dan Malks. Cho dù bạn có là tín đồ của .NET, PHP, Ruby, ... tôi khuyên bạn vẫn nên đọc qua nó - nếu bạn muốn mình có thể đạt đến một trình độ kĩ thuật cao hơn (ở mức độ thiết kế và xây dựng kiến trúc hệ thống phần mềm).

Tôi sẽ lựa chọn một số chương mà tôi tâm đắc để dịch và giới thiệu đến mọi người.
Tuy nhiên tôi sẽ không dịch sát nghĩa trên nội dung mà sẽ viết lại theo cảm nhận và cách hiểu của mình. Nội dung dịch sẽ bám sát theo tư tưởng: phân tích và giải thích vấn đề không bị phụ thuộc vào ngôn ngữ. Do đó nếu bạn muốn hiểu sâu về chi tiết và cách hiện thực trên J2EE thì nên đọc từ ebook tiếng Anh.

Một quyển sách khác mà tôi cũng khuyên bạn nên đọc là: Enterprise Solution patterns Using Microsoft.NET. Đây là quyển dành cho lập trình viên .NET. Tuy nhiên xét về nội dung thì các pattern này cũng gần như tương tự nhau - chỉ khác nhau về cách hiện thực chi tiết trên mỗi platform.

Mục đích của việc dịch và giới thiệu quyển sách này là muốn chia sẻ với mọi người
Nếu các bạn thấy có những đoạn dịch chưa chuẩn hoặc làm mọi người hiểu sai ý nghĩa xin vui lòng đóng góp và gửi mail cho mình: tran.dang.khoa.khtn@gmail.com

Danh sách những chương sách đã dịch sẽ được cập nhật qua bài viết này
(hiện tại chỉ mới dịch xong chương 1)

Chương 1: Giới thiệu

Đọc "Refactoring" của Martin Fowler

Refactoring là một trong những quyển sách đáng đọc cho lập trình viên. Sách được viết và biên soạn bởi những cây đại thụ trong làng kĩ nghệ phần mềm: Martin Fowler, Kent Beck, John Brant, William Opdyke và don Roberts




"Refactoring" không phải là một quyển sách mới. Quyển mà tôi đọc được ấn hành vào năm 2002 (có ghi một dòng: Another stupid release 2002
For all the people which doesn’t have money to buy a good book - dành cho những kẻ ko có tiền mua sách :-). Có lẽ tác giả cũng khá vui tính). Trước đây tôi chỉ đọc lướt qua, chủ yếu là học chiêu. Giống như bọn giang hồ chỉ thích học lóm chiêu pháp của người khác mà không luyện qua những chiêu thức căn bản. Đến sau này có thời gian đọc lại, tôi mới thấu hiểu những tinh hoa nằm sau nội dung sách.

Một chương trình, xét cho cùng cũng chỉ là một tập những dòng mã. Do đó giá trị của một chương trình ngoài những giá trị về chức năng - kinh tế nó cung cấp cho khách hàng, còn một yếu tố quan trọng nữa là: chất lượng mã nguồn. Mã nguồn được đánh giá là tốt khi nó thỏa mãn các yếu tố:
1. Có giá trị cao về mặt kinh tế
2. Độ bao phủ test gần 100%
3. Có tính đơn giản
4. Không trùng lặp
5. Có sức biểu đạt cao.
(Trích từ phát biểu của Robert C.Martin về "thế nào là mã nguồn tốt")

Refactoring - tạm dịch là tinh chỉnh mã nguồn - là hoạt động giúp ta đạt được 3 yếu tố (3) (4) (5). Trong đó yếu tố số 5 được xem là yếu tố then chốt cần đạt được trong refactoring.
Dưới đây tôi giới thiệu tổng quan một số chương sách để giúp bạn có một góc nhìn ban đầu.

Chương 1 của quyển sách đưa ra một ví dụ đầu tiên về refactoring thông qua một đoạn mã nguồn cụ thể và áp dụng refactoring để làm cho mã nguồn trở nên dễ đọc hơn.

Chương 2 nói về những nguyên tắc của refactoring. Đây là chương chưa đựng nhiều giá trị đáng đọc. Nó trả lời giúp tôi những câu hỏi thú vị: tại sao cần refactoring? tôi phải nói với sếp điều gì khi tôi muốn refactor mã nguồn của tôi? Mối quan hệ giữa refactoring và design? Mối quan hệ giữa refactoring và hiệu suất chương trình.

Chương 3: Giúp bạn phát hiện mã xấu. Đây cũng là một chương rất quan trọng vì nó giúp bạn hình thành nên ý niệm giữa cái tốt và xấu trong mã nguồn

Chương 4: Giúp bạn ý thức về việc viết Unit test để đảm bảo mã nguồn của bạn chạy đúng. Các unit test cũng giúp bạn phát hiện sai lầm trong quá trình refactoring.

Từ chương 5 đến chương 13 là những chương dạy cho bạn chiêu pháp để tinh chỉnh mã nguồn.
Chương 14 bàn thêm về những công cụ hỗ trợ refactoring

Tôi đánh giá rất cao 4 chương đầu tiên của quyển sách. Chúng được xem là những chiêu thức căn bản và tạo nên tinh hoa của quyển sách này.

Về các chiêu thức để refactoring (HOW), tôi tạm chia chúng ra làm 4 cấp bậc:

Cấp 1: các chiêu thức sử dụng để refactor những đoạn mã nguồn nhỏ (các quy tắc đặt biến, biểu thức điều kiện, loại bỏ parameter thừa, ...)
Cấp 2: Cấp độ phương thức (method)
Cấp 3: Cấp độ class
Cấp 4: Cấp độ thuật toán và thiết kế hệ thống


Thực chất, không cần phải nhớ hết tất cả những chiêu thức trong sách. Để đọc quyển sách này một cách hiệu quả, tôi làm như sau:
- Ghi nhớ tinh thần và các ý niệm của 4 chương đầu tiên.
- Mở lại những đoạn mã nguồn cũ - tìm ra những đoạn mã xấu.
- Xác định các module cần refactor
- Viết Unit test cho những hàm mà module cung cấp ra ngoài. (vì trước đây tôi ít viết Unit test cho những đoạn mã nguồn cũ)
- Đọc tiếp các chiêu thức còn lại. Sau mỗi chương, tôi thực hành ngay trên những module tôi xác định muốn refactor.
Đó là cách mà tôi đọc và thực hành trên quyển sách này. Còn bạn?

Agile và XP - đâu là điểm khác biệt?

Hôm trước đi uống cafe với anh Vinh có trao đổi về XP và Agile. Chợt nhận ra một điều là mình chưa phân biệt được 2 khái niệm này. Trước đây cũng từng đọc về XP - hiểu và cảm nhận được nó ở mức độ trung bình. Tuy nhiên sau câu hỏi đột ngột này, mình cảm giác đang bị mất căn bản trầm trọng.

Giờ mới hiểu được bản chất:
http://en.wikipedia.org/wiki/Agile_software_development
Câu trả lời: Agile là một nhóm những phương pháp luận để đạt được những nguyên lý và mục tiêu xác định. XP chỉ là một phương pháp luận cụ thể.

Có nhiều phương pháp luận trong Agile:

• Agile Modeling
• Agile Unified Process (AUP)
• Agile Data Method
• DSDM
• Essential Unified Process (EssUP)
• Extreme programming (XP)
• Feature Driven Development (FDD)
• Getting Real
• Open Unified Process (OpenUP)
• Scrum

Tuy nhiên do XP khá nổi tiếng, nên ta nghe đến tên nó nhiều hơn những phương pháp luận còn lại. Ngoài XP, Scrum cũng là một phương pháp luận được nhắc đến nhiều trong Agile