Tôi đọc như thế nào?

Wednesday, December 30, 2009 2 phản hồi

Những ngày gần đây, tôi phát hiện ra nhiều điều thú vị từ thói quen đọc sách của chính mình và những điểm thiếu sót mà trước đây tôi từng vấp phải khi đọc. Tôi viết lại vài dòng để chia sẻ với các bạn. Tuy nhiên, tôi mong đợi nhiều hơn nữa là có thể truyền cho các bạn niềm đam mê khám phá những kiến thức từ sách. Vì vậy, tôi sẽ viết … nhiều hơn một chút so với thường lệ.

Lịch sử thói quen đọc sách của tôi – những câu chuyện cười ra nước mắt

Có thể nói đọc sách là một thói quen tôi được ba mẹ truyền cho từ thưở bé. Khi tôi còn chưa biết đọc, quyển sách đầu tiên ba mua cho tôi là “Sát thát” – một quyển truyện tranh viết về lịch sử thời Trần. Vì không biết đọc, nên tôi phải nhờ mẹ đọc từng dòng và chỉ hình, rồi giải thích cho tôi nghe. Có lẽ vì quyển truyện tranh ấy khá phù hợp với trí tưởng tượng của tôi lúc nhỏ (thích tưởng tượng mình cầm quân đánh trận), nên những chi tiết của nó đọng lại trong tôi thành một nỗi ám ảnh. Tôi vẽ những nét nguệch ngoạc theo trí nhớ về câu chuyện: nào là Trần Quốc Toản bóp nát quả cam, nào là Trần Khánh Dư cướp thuyền lương của giặc, Ô Mã Nhi bị bắt sống, … Tất nhiên là vẽ xấu hoắc, nhưng những nét vẽ ấy đã thắp cho tôi một niềm đam mê khám phá những chân trời mới từ sách.

Lớn lên một chút, ba mua cho tôi rất nhiều sách. Thời đó, các tác phẩm văn học Nga khá phổ biến. Năm tôi 7 - 8 tuổi, tôi được đọc “Vasca – người bạn nhỏ của tôi”, “Timua và đồng đội”, “Ông già Khốt-ta-bit”, “Cuộc phiêu lưu của Mít Đặc và các bạn”, … Những quyển sách ấy trở thành người bạn quen thuộc trong kí ức tuổi thơ tôi.

Có một điều tai hại mà sách mang đến cho tôi là làm cho tôi biết yêu quá sớm. Năm học lớp 2, tôi đọc quyển “Những cuộc phiêu lưu của Tom Sawyer” (quyển này ngoài bìa có ghi là “dành cho các bạn tuổi thiếu niên >=15 tuổi”). Tình yêu trẻ con và những cuộc phiêu lưu kì thú của cậu bé Tom Sawyer làm tôi bị ám ảnh và … “bắt chước”. Trong lớp có một cô bé rất xinh cứ làm tôi cứ tưởng tượng đến Becky – nhân vật “bạn gái” của Tom Sawyer. Tôi quyết định viết thư “tỏ tình” với nàng. Thật tình là trí tưởng tượng của tôi thời đó bị lai tạp từ rất nhiều quyển sách, kể cả chuyện cổ tích. Do đó, trong bức thư tôi viết có những đoạn đại loại như:
Mình muốn trở thành chàng hoàng tử bên cạnh bạn, cô công chúa xinh đẹp ạ.… (hic, giờ nghĩ lại thấy phát sốt với mình luôn).

Bức thư tỏ tình của tôi đã không đến được tay người đẹp. Nó rơi vào tay cô Kim (em họ của ba tôi sang ở nhà tôi để học may). Tất nhiên là cô đọc bức thư đó cho cả nhà cùng nghe. Xấu hổ đến mức muốn chui xuống đất. Đó là “tai nạn nghề nghiệp” đầu tiên đến với tôi từ sách.

Lúc học phổ thông tôi thích đọc truyện Nguyễn Nhật Ánh (ông này làm tôi chuyển hướng qua trường phái “yêu thầm” – có lẽ sẽ tiếp tục chủ đề này ở bài khác), tiểu thuyết văn học, đọc thơ, truyện ngắn,… Do đọc nhiều, nên cách tôi làm văn, cách tôi viết cũng “già” hơn so với bạn bè cùng trang lứa. Thầy dạy văn tôi năm lớp 9 sau khi chấm bài xong, phán một câu xanh rờn: “thầy đọc bài của em thấy có rất nhiều những ý tưởng, cách nghĩ mà ở lứa tuổi em không thể có được. Nếu bài kiểm tra này không phải ở trong lớp, có lẽ thầy đã nghĩ rằng em “đạo văn” từ sách rồi.”


Cái gì khiến tôi thích sách?

Lúc còn nhỏ, khi đọc một tác phẩm văn học, điều làm tôi thú vị nhất là khám phá được chính mình hoặc một thế giới khác từ nội dung câu chuyện. Nó kích thích trí tưởng tượng của tôi để lạc vào những cuộc phiêu lưu kì thú trong thế giới sách.

Lớn lên một chút, ba phát hiện tôi không hào hứng lắm với những giáo trình về lịch sử, khoa học trong lớp. Ba bảo tôi rằng: nếu con tập cho mình thói quen và niềm đam mê khám phá những tri thức mới (chứ không chỉ là những câu chuyện giải trí đơn thuần), con sẽ thấy sách hấp dẫn và bổ ích hơn nhiều. Và … tôi đã tập. Mỗi khi biết thêm một điều mới, khám phá một quan điểm hay cách nghĩ mới từ một quyển sách – tôi cảm thấy thực sự mình trưởng thành hơn một chút. Rồi từ đó, những quyển sách về lịch sử, xã hội, và cả những chủ đề khoa học cũng trở thành một sở thích của tôi: “Những điều kì thú quanh em”, “175 thí nghiệm khoa học dành cho trẻ em”, Việt Nam sử lược, … kể cả sách thuốc: Hải Thượng Y Tông Tâm Lĩnh, Những cây thuốc và vị thuốc Việt Nam, …

Năm tôi học lớp 7, tôi biết cách tạo ra những cánh hoa mười giờ với những màu sắc khác nhau kết hợp (trên cùng một cây) bằng cách tiêm nhựa từ thân của các loại hoa mười giờ khác màu vào thân chúng. Thí nghiệm đó chỉ ngẫu hứng từ một quyển sách viết về di truyền học và gen (giờ quên mất tựa rồi).
Những quyển sách, những câu chuyện đã trở thành một phần những ví dụ minh họa mỗi khi tôi truyền đạt vấn đề cho người khác. Chúng làm cho vấn đề truyền đạt có sức hút hơn, hấp dẫn hơn.

Bên cạnh đó, việc đọc làm cho khả năng viết của tôi tốt hơn. Những bài làm văn của tôi thưở bé không bao giờ ít hơn 3 trang, và không bao giờ < 7 điểm.
Ngoài ra đọc sách cũng là một trong những cách giúp tôi giảm stress và “mềm” đi sau những giờ làm việc mệt mỏi và căng thẳng. Có người bảo: dân IT khô khan như ngói. Ít ra đến thời điểm này, tôi không cảm thấy mình là một mảnh ngói như vậy.

Một lợi ích nữa của việc đọc sách (đặc biệt là các sách tiếng Anh) là giúp tôi mở rộng vốn từ trong giao tiếp đặc biệt là khả năng viết. Khi đọc nhiều, cách viết, cách vận dụng câu cú để diễn đạt đã nhập vào đầu một cách tự nhiên mà tôi không cần phải gắng sức suy nghĩ.

Điều quan trọng hơn nữa, tôi vận dụng những điều đã đọc vào công việc, cuộc sống. Nó đem lại cho tôi những kết quả bất ngờ ngoài sự mong đợi. Khi kiến thức được trải rộng ra nhiều mảng, tôi có thể dễ dàng vận dụng để giải quyết nhiều vấn đề, và tư duy nhanh để tiếp nhận những kiến thức mới.

Nếu bạn cảm thấy mình chưa thích sách, hãy thử và trải nghiệm xem. Biết đâu bạn có thể khám phá ra nhiều lợi ích khác nữa từ sách hơn tôi.

Những sai lầm của tôi (cũng có thể là của một số bạn khác) khi đọc sách

Những ngày đầu tiên đi làm, tôi vấp phải một sai lầm khi đọc những quyển sách về kĩ thuật. Tôi đọc chỉ để ứng dụng trong công việc, kiếm tiền. Đặc biệt trong lĩnh vực IT, tâm lý phổ biến của developer là thích đọc code nhiều hơn đọc nội dung sách. Cái trường phái tips-and-trick đó đã làm tôi bị hoang mang. Có thể “code” được, nhưng khi bị hỏi những câu hỏi sâu về kiến thức là mù tịt. Nó giống như luyện võ chỉ biết chiêu, mà không có nội công căn bản, múa được quyền rất đẹp, nhưng khi đụng đến là ngã – vì không có nội lực.

Một thằng bạn đồng nghiệp thời đó đã truyền cho tôi cảm hứng về việc đào sâu “bản chất vấn đề”. Thực sự trong những người tôi từng gặp trong đời, ít có ai có khả năng tư duy và kiến thức rộng về các mảng kĩ thuật như anh chàng này. Tôi đặt một câu hỏi lớn trong đầu mình: cùng một tuổi với mình, tại sao hắn có thể biết nhiều và sâu như vậy?

Dần dần tôi phát hiện ra rằng, trong thói quen đọc của hắn không những chỉ quan tâm “làm như thế nào” , mà còn chú trọng đến những câu hỏi về bản chất “Tại sao vấn đề được đặt ra?”, “Tại sao họ làm như vậy?”, “Những khái niệm cơ bản của vấn đề này là gì?”… Khi đã hiểu được bản chất của vấn đề thì hoàn toàn có thể lý giải và biết “cách để giải quyết nó”.

Sai lầm thứ hai của tôi là đi theo trường phái thực dụng. Khi đọc sách về kĩ thuật, tôi luôn đặt câu hỏi: tại sao mình nên đọc quyển sách này? Sau khi đọc mình ứng dụng được gì trong công việc hiện tại? Càng về sau này, tôi cảm nhận được rằng: thực sự ta không biết tương lai sẽ diễn ra như thế nào? Tuy nhiên, những gì ta biết ngày hôm nay sẽ là thuận lợi của ta vào ngày mai. Chỉ có trời mới biết được điều đó.
Ngoài ra còn một số điểm sai lầm khác khi đọc sách kĩ thuật rất thường thấy của dân IT Việt Nam :

- Ngại đọc nội dung chi tiết, vì lười tra từ tiếng Anh.

- Thích đọc code/ xem hình ảnh và chỉ focus vào code/ hình ảnh minh họa mà không quan tâm đến tính cốt lõi và tinh túy của vấn đề. Để biết mình có thuộc tuyp người này hay không, hãy thử lấy random một cuốn sách đã từng đọc, và dùng tối đa 3-5 câu để phát biểu về core value của quyển sách. Nếu bạn không thể trả lời được, có nghĩa là bạn đang mắc vào hội chứng này.

- Đọc chỉ đơn thuần là để hiểu mà không vận dụng vào thực tiễn.

- Bị ám ảnh bởi những thứ tưởng là mình biết, dẫn đến không thể tiếp thu được kiến thức mới từ sách. Khi xem phim 2012, tôi bị tác động bởi một chi tiết nhỏ mang tính triết lý trong bộ phim. Anh chàng học trò hỏi thầy (một nhà sư): “thế giới sắp diệt vong, liệu có cách nào cứu vãn không thầy?” Nhà sư chỉ im lặng rót trà vào tách. Đến khi tách trà tràn cả ra ngoài, ông vẫn cứ rót tiếp. Anh chàng học trò giục thầy: ơ kìa, sao thầy cứ rót mãi thế? Thầy không thấy trà tràn ra ngoài sao? Nhà sư chỉ lẳng lặng đáp: mọi thứ trên đời này giống như một tách trà. Khi nó đầy, nếu con không đổ bớt trà ra, thì con không sẽ không thể rót thêm trà vào tách.


Khi đọc sách cũng thế, những gì ta cho rằng ta biết sẽ là “quán niệm” (những ý niệm làm ta ì đi trước những quan điểm mới của sách). Nếu đầu bạn đã đầy ắp những quán niệm, bạn sẽ không tiếp thu được gì cả. Tôi thường biến mình thành một đứa trẻ ngây thơ khi đọc sách. Như vậy, mới có thể giúp tôi dễ dàng đón nhận những điều mới mẻ từ chúng.


Tôi đang đọc sách như thế nào?

Thật sự mỗi người đều có một cách riêng của mình khi đọc sách. Tôi cũng vậy. Những cách mà tôi đang practice thực sự là hiệu quả đối với tôi. Tôi hy vọng nó cũng có thể hiệu quả đối với bạn. Nhưng có thể bạn sẽ khám phá ra nhiều cách hơn. Mọi thứ trên đời để hiểu được đều cần sự trải nghiệm. Đúng không nào?

Thói quen 1: khi bắt gặp những câu nói, lý thuyết khó hiểu, tôi bắt đầu đi từ khái niệm. Khái niệm là những viên ngọc cấu thành của mọi vấn đề. Hiểu được nó, ta sẽ hiểu được lý thuyết. Đây chính là điểm làm cho nhiều người nghĩ rằng tôi quá “hàn lâm”. Tuy nhiên, nếu bạn gặp những vấn đề tương tự, hãy thử cách này xem.

Thói quen 2: cố gắng nắm bắt core values của một quyển sách. Đọc xong một quyển sách, nếu không trả lời được giá trị của nó là gì, thì những điều bạn đọc có thể trở thành vô nghĩa.

Thói quen 3: rũ bỏ hết chấp nê (“biến mình thành một kẻ khờ khạo”) để sẵn sàng đón nhận những tư tưởng mới.

Thói quen 4: luôn đặt ra những câu hỏi khi đọc sách và háo hức chờ đợi nó được trả lời trong nội dung sách (có thể là ở những chương kế tiếp).

Thói quen 5: phân tích cách đặt vấn đề của tác giả.

Thói quen 6: ghi chú lại những điều tâm đắc hoặc nội dung chính của quyển sách. Mỗi người có một cách khác nhau. Riêng tôi, mỗi khi đọc – tôi sử dụng XMind làm công cụ để ghi chú và cấu trúc hóa lại những gì đã đọc. Xmind phiên bản mới có một template khá chuẩn là Reading Journal. Nếu đọc xong sách mà bạn có thể fill hết nội dung vào file tạo ra từ template này, có nghĩa là bạn đang đọc “đúng hướng” (thanks anh Vinh đã phát hiện và giới thiệu).

Lời kết

Tôi thường nói với những người bạn một câu đã trở thành triết lý sống mà tôi đang theo đuổi:

Muốn thành công phải có sự đam mê và lòng kiên nhẫn.
Thật sự, cái khó nhất của một đời người là thắp cháy lên ngọn lửa đam mê cho chính mình. Hãy tập thắp cho mình đam mê từ những thói quen tốt nhỏ nhất. Chắc chắn bạn sẽ thành công. Trong đó, đọc sách là một thói quen tốt mà bạn nên thử. Nó cũng rèn luyện cho bạn cả đức tính kiên nhẫn để theo đuổi đến cùng một chân trời tri thức đang rộng mở.

Bản thân tôi (vì những lý do riêng) không thể dành nhiều thời gian để tận hưởng những giây phút hạnh phúc của riêng mình – sách với tôi đã trở thành những người bạn. Mỗi lần đọc sách, tôi tưởng tượng mình đang mài vũ khí của chính mình (vũ khí đó chính là tri thức) – để nó trở nên sắc bén hơn và giúp tôi đối mặt với những trận chiến mới trong cuộc sống.

Hỡi những người bạn lập trình viên trẻ, đừng để tuổi trẻ của mình trôi đi quá nhanh. Đến khi bạn nhận thấy mình đã già, mà gươm vẫn không sắc. Lúc đó đã quá muộn, sao có thể chiến đấu được nữa? Đúng không nào?

Cơ hội và thử thách cho lập trình viên iPhone ở Việt Nam

Sunday, December 20, 2009 1 phản hồi

Bài viết này xuất phát từ một câu hỏi của Tiến Khoa (một anh bạn đồng nghiệp) sau buổi seminar về iPhone programming của mobile group.

Lập trình trên iPhone là một mảng kĩ thuật khá mới mẻ và rất thú vị. Tuy nhiên, hẳn nhiều bạn sẽ rất băn khoăn:
1/ Liệu đây có phải là một lựa chọn đúng đắn cho tương lai của mình không?
2/ Tương lai của các lập trình viên iPhone ở Việt Nam sẽ như thế nào?
3/ Liệu ở Việt Nam, các ứng dụng trên iPhone có trở nên phổ biến và tôi có thể kiếm được tiền trên đó không?

Bài viết này sẽ lần lượt trả lời từng câu hỏi trên.

1/ Lập trình iPhone có phải là một lựa chọn đúng đắn cho tương lai của mình không?
Thật sự câu hỏi này chỉ duy nhất bạn mới có thể trả lời chính xác. Vì không ai quyết định được tương lai ngoài bạn được. Làm bất kì việc gì thành công cũng đều đòi hỏi phải có lòng đam mê. Nếu lòng đam mê của bạn đủ lớn, cộng thêm nhiệt huyết và sự kiên nhẫn, chắc chắn bạn sẽ thành công.

Hiện nay số lượng lập trình viên iPhone ở Việt Nam không nhiều. Điều này mở ra rất nhiều cơ hội nghề nghiệp cho các bạn lập trình viên trẻ. Tuy nhiên, yếu tố này chỉ mang tính chất tạm thời. Giống như .NET/Java, khi nó mới ra đời, thì đây là một job rất hot. Tuy nhiên, khi số lượng người biết lập trình trên các mảng kĩ thuật này tương đối nhiều, bạn phải nỗ lực nâng cao kĩ năng, kiến thức và tạo ra điểm khác biệt để thành công trên con đường bạn đã chọn.

2/ Tương lai của lập trình viên iPhone ở Việt Nam sẽ như thế nào?
Hiện nay các project về iPhone ở Việt Nam thường được outsource từ nước ngoài về. Lý do cơ bản vẫn là VN sở hữu một nguồn lập trình viên khá rẻ. Các dự án trên iPhone cũng thường đi với thời gian khá ngắn (thường từ vài tuần đến vài tháng) và phục vụ chủ yếu cho các mục đích về marketing, du lịch, ...

Tuy nhiên, hiện nay iPhone application đang là một trong những xu hướng phát triển trên thế giới (bên cạnh các mảng kĩ thuật về mobile khác). Trong tương lai (ít nhất 1-2 năm tới), lĩnh vực lập trình iPhone sẽ tiếp tục phát triển mạnh ở Việt Nam và được đầu tư nhiều hơn.

Các công ty lớn về outsource hiện nay ở Việt Nam như Global CyberSoft, CSC, Pyramid Consulting VietNam cũng đã xây dựng những nhóm research và phát triển các ứng dụng trên iPhone.
3/ Liệu ở Việt Nam, các ứng dụng trên iPhone có trở nên phổ biến và tôi có thể kiếm được tiền trên đó không?

Bạn khó kiếm được tiền từ end user ở Việt Nam. Vì thực tình mà nói, các ứng dụng trên iPhone ở VN đều được cài phần lớn qua con đường crack/hack. Tuy nhiên, trong tương lai nếu iPhone được sử dụng phổ biến ở VN, bạn có thể nghĩ ra các dịch vụ/ứng dụng mà bạn có thể kiếm tiền qua quảng cáo/ bán các gói dịch vụ/sản phẩm nâng cao,...

Bên cạnh đó, bạn vẫn có cơ hội kiếm tiền từ những user nước ngoài trên AppStore. Một application khi đưa lên bán trên AppStore, bạn sẽ được hưởng 70% doanh thu. Nếu bạn có một application hay, và có khoảng 1 triệu lượt download. Ái chà, sắp giàu rồi đấy!

Ngoài ra, kiếm tiền bằng cách làm freelancer developer cho các project iPhone cũng có thể giúp bạn kiếm được kha khá. Tôi có biết một ltv ở Hà Nội, có thể kiếm được 2000-3000$ một tháng nhờ tham gia các project outsource về iPhone.

Tôi chỉ muốn gợi lại một câu của Lỗ Tấn trong "AQ chính truyện":
"Thật ra trên đời này làm gì có đường, người ta đi mãi rồi thành đường đó thôi".

Tôi tin rằng các bạn - những lập trình viên trẻ nhiệt huyết, đam mê, và ham thích học hỏi - sẽ tự mở ra con đường của chính mình.

Nếu bạn có câu hỏi hoặc thắc mắc nào khác, bạn có thể comment trên bài viết này.

Không đề

Friday, December 18, 2009 3 phản hồi

Không đề

Không có ai đi cạnh cuộc đời
Giờ tôi đơn độc chỉ mình tôi
Tình yêu là lá bay theo gió
Bỏ lại cành khô đứng ngậm ngùi

Một thoáng cuộc đời ta có đôi
Phút vui đã lỡ mất đi rồi
Một mai em có theo duyên mới
Nhớ gửi tặng anh một nụ cười

Đời anh quả thật chẳng gì vui
Nên chỉ xin em một nụ cười
Để thấy lòng mình thêm ấm lại
Vững bước độc hành …
chỉ thế thôi


(Viết trong những ngày sắp Noel mà tôi mong rằng sẽ không bao giờ đến)

Viết cho Long Xuyên

1 phản hồi

Tình cờ đọc vài dòng về Long Xuyên trên một group facebook, tự nhiên thấy nhớ nhà quá. Tôi sinh ra không ở An Giang, nhưng hơn 15 năm ở mảnh đất này đã biến nó thành một phần quê hương trong máu thịt của tôi.

Ở nơi đó, có mối tình đầu của tôi. Một tình yêu thầm lặng suốt nhiều năm.Cái tình yêu trẻ con ngày ấy thật ngọt ngào, nhẹ nhàng như những cánh phượng hồng thời áo trắng. Mãi đến bây giờ, có lẽ người ấy cũng không biết đến tình cảm của tôi dành cho nàng.

Ở nơi đó, có một bờ hồ (mà lũ chúng tôi hay gọi hồ con Rùa) nho nhỏ. Mỗi chiều tan trường chúng tôi lại xách xe chạy lòng vòng quanh hồ, đón những cơn gió từ con sông Hậu thổi vào mát lạnh. Thỉnh thoảng chúng tôi lại đi ăn kem, bún cá ở dọc bờ hồ. Tiếng cười ngày ấy giòn tan và trong trẻo lắm.

Tôi cũng yêu ngôi trường của tôi. Mái trường Thoại Ngọc Hầu dấu yêu, nơi tôi đã học suốt 3 năm cấp ba. Ở đó, có những người bạn đã cùng tôi đi qua những khoảnh khắc đẹp nhất trong cuộc đời.

Một người bạn đã viết tặng tôi một bài thơ vào những ngày cuối cùng trong quyển lưu bút:

Ngày nào gặp chỉ lặng im.
Ba năm ngọn lửa cháy vào ước mơ.
Buổi chia tay nhớ buổi xưa.
Luyến lưu chợt nhớ thưở chưa dám gần.


Tôi nợ ai đó lời hứa về ngôi nhà chất đầy gấu bông nếu sau này tôi trở thành ... tỷ phú.
Tôi nợ ai đó những chú bướm xinh xếp bằng những cánh phượng rực rỡ đầu mùa hạ.
Tôi nợ ai đó những giây phút chạnh lòng ...
Tôi nợ cô bạn lớp trưởng của tôi một lời tỏ tình mà tôi ấp ủ ngày đêm chưa dám ngỏ.

Giờ đây, chúng tôi mỗi đứa đi một phương. Năm thì mười họa mới gặp lại nhau giữa cuộc đời tất bật. Có những lúc tôi mơ ước có một ngày chúng tôi được trở về mái trường xưa, được mặc áo trắng và ngồi vào lớp học cũ như thời chúng tôi còn đi học.

Thỉnh thoảng, tôi thích ngồi quán cafe, nhìn những tà áo trắng tung bay trước sân trường. Chỉ đơn giản để thấy mình được sống lại những khoảnh khắc hoài niệm về thời xa xưa.

Có ai đó nhớ Long Xuyên như tôi không?

Agile leader - anh là ai?

Wednesday, November 4, 2009 0 phản hồi

Agile leader - là một cụm từ tôi nghĩ ra trong những ngày gần đây. Tạm diễn đạt theo nghĩa tiếng Việt: người lãnh đạo theo trường phái Agile (chữ agile không muốn dịch - vì dịch ra có thể không hay).

Agile là một trường phái phát triển phần mềm được khởi xướng từ bản tuyên ngôn Agile do 17 bậc lão làng trong ngành phần mềm: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff SutherlandDave Thomas.

Bản tuyên ngôn này được phác thảo từ 11-13/02/2001 tại Snowbird/Uhtar.

Agile được hiện thực bởi nhiều phương pháp luận (Extreme Programming, Scrum, Crystal, Feature driven,...). Tuy nhiên bài viết này không đi vào một phương pháp luận cụ thể nào. Bạn có thể đọc về chúng trong rất nhiều sách và tài liệu trên Internet.

Tôi không thích sách vở suông. Sách vở chỉ là tờ giấy vứt đi nếu nó không được áp dụng vào thực tiễn và mang lại hiệu quả. Ở đây tôi viết về những practices để trở thành Agile leader dựa trên 2 phát biểu đầu tiên của tuyên ngôn Agile. Tôi không viết các practices cho 2 phát biểu kế tiếp vì một số lý do nhạy cảm. Tất nhiên, các practices này chỉ là do tôi đúc kết từ những kinh nghiệm chủ quan trong những dự án tôi tham gia.

Phát biểu 1: Individuals and interactions over processes and tools
(Cá nhân và giao tiếp được đánh giá cao hơn quy trình và công cụ)

- Tôi coi trọng việc giao tiếp với những thành viên trong nhóm đặc biệt qua hình thức nói chuyện mặt đối mặt. Tôi muốn nhìn thấy cảm xúc/ nghe giọng nói/ đọc những dòng code bạn tôi viết/ cảm nhận được khó khăn mà bạn tôi vấp phải. Thông qua cách này giúp tôi hiểu và chia sẻ được với đồng sự của tôi nhiều hơn việc sử dụng những công cụ vô cảm như email/skype/phone.
- Tôi không viết ra những tài liệu nếu nó không phục vụ cho mục đích giao tiếp/ truyền đạt. Nếu phải viết ra một thuật toán/ xử lý phức tạp, tôi sẽ trao đổi trực tiếp và nếu cần thiết sẽ cùng đồng sự của tôi code ra nó trên bàn của anh ta/ hoặc của tôi.
- Tôi không đưa cho ai bất kì một tài liệu mà không có giải thích trực tiếp để đảm bảo họ hiểu nhanh những gì tôi đã viết.
- Tôi sẵn sàng di chuyển để được ngồi và làm việc bên cạnh những đồng sự của tôi trong cùng một dự án.
- Nếu bạn tôi gặp khó khăn, tôi sẽ ngồi bên anh ta để cùng làm và giải quyết vấn đề.
- Tôi luôn muốn tạo điều kiện và phấn đấu để giúp cho đồng sự của tôi/ và cả tôi phát triển vì tôi tin rằng: chỉ có những con người giỏi mới tạo ra được phần mềm tốt. Không có công cụ/ quy trình nào có thể giúp sản xuất ra những phần mềm hoàn hảo với những con người yếu kém.

Phát biểu 2: Working software over comprehensive documentation
(Phần mềm chạy được được đánh giá cao hơn việc viết ra tài liệu dễ hiểu).
- Tôi đặt mong đợi ở chất lượng code và thiết kế hơn những xấp tài liệu system architecture dày cộm. Thiết kế hệ thống sẽ thay đổi theo thời gian. Vì vậy nếu cần bản thiết kế hoàn chỉnh, tôi sẽ viết ở những giai đoạn cuối dự án khi thiết kế đã hoàn chỉnh.
- Tôi chứng minh cho khách hàng nhìn thấy phần mềm chúng tôi viết chạy được bằng cách cho họ nhìn thấy càng sớm càng tốt và liên tục những gì chúng tôi đã làm được để có những phản hồi sớm nhất.
- Để có một phần mềm chạy được, tôi cập nhật/đánh giá/giải quyết những rủi ro kĩ thuật sớm nhất trong từng vòng lặp phát triển.

Trùng hợp

Saturday, October 24, 2009 1 phản hồi

Làm ở Pyramid Consulting được gần 2 năm, giờ mới phát hiện ra một sự trùng hợp ngẫu nhiên của những Technical Architect tại đây.

Tôi chưa có cơ hội để làm việc với các bậc tiền bối TA. Tuy nhiên huyền thoại  và cơ hội học hỏi từ các anh là một trong những yếu tố thúc đẩy để tôi bước chân vào công ty. Hôm qua đi uống cafe với bác Vinh, mới biết rằng mỗi nhân vật này đều có một biểu tượng về con vật đại diện. :)

anh An: monkey (con khỉ). Có lẽ là thể hiện cho sự nhanh nhẹn, thông minh và khéo léo.
anh  Vĩ: một con vật lai giữa rùa và thỏ (có lẽ thể hiện cho sự nhanh nhẹn + sâu sắc và vững chắc).
anh Vinh: con heo. Biết lý do vì sao, nhưng không nói được. Ha ha.
anh Phước: con hà mã. Chưa biết ý nghĩa của biểu tượng này cho lắm.
anh Trí: có nghe bác Vinh nói, nhưng hôm nay quên mất con vật đại diện. Update later.
Nguyễn Ngọc Trung: soddino - khủng long ăn cỏ => To xác nhưng hiền lành.

Tôi giật mình nhìn lại biểu tượng mà tôi đã chọn cho mình trước khi tham gia vào Pyco: KBird.  Sao lại trùng hợp vậy ta? Điều kì lạ hơn nữa là tất cả các con vật này đều "lành" - không tương sinh tương khắc.

Giải thích về cái biểu tượng KBird cho nó hay ho một chút: thật ra trước đây chọn con vật này vì mình thích phóng khoáng, bay bổng, ko muốn bị ràng buộc vì bất cứ lý do nào trong mọi suy nghĩ, hành động. Chơi CS trong công ty thì lấy alias biến tấu là coolbird. Vì chim lành quá nên cứ bị bắn chết hoài, chán thiệt.

Nhật ký dự án Car Racing - điều kì diệu

Thursday, September 3, 2009 5 phản hồi

David bảo chúng tôi phải tạo ra điều kì diệu. Yes, điều kì diệu là viết một game đua xe trên iPhone được estimate trong 6 tháng bởi một công ty chuyên làm game khá nổi tiếng - và chúng tôi sẽ phải làm trong 45 calendar days.

Chúng tôi bắt đầu từ những con số khá nghèo nàn.
1 Technical architect (Khoa) + 2 developer (Đạo, Chương). Trong 3 người chỉ có 2 người có kinh nghiệm lập trình trên iPhone trong 2-3 tháng.
Ngày thứ 1: chúng tôi bắt đầu từ những game engine 3D trên iPhone. Chúng tôi chọn SiO2 vì thấy có khá nhiều game sử dụng nó và cộng đồng LTV cũng khá đông đảo.

Ngày thứ 2: Chúng tôi thực hiện các thử nghiệm nhỏ: load mô hình 3D + thực hiện các chuyển động vật lý + đưa ra các mô hình điều khiển xe bằng việc tác động lực.

Ngày thứ 5: mọi chuyện có vẻ trở nên khó khăn. Đầu tiên là việc load xe và đặt vào terrain. Xe luôn bị rơi xuyên thủng mặt đất. Kế tiếp là việc load mô hình 3D sử dụng script Python chạy trên blender. SiO2 support mạnh cho blender, nhưng lại yếu đối với các 3D design tool khác. Mọi mô hình 3D phải được export ra định dạng sio2 trước khi được load vào game. Đội ngũ 3D design của chúng tôi không quen sử dụng công cụ này nên đây là một trở ngại rất lớn.

Ngày thứ 7: áp lực bắt đầu khá nặng nề. Chúng tôi đã load được mô hình xe đơn giản nhất - chỉ có 4 bánh - 1 thân và 2 trục, điều khiển xe chạy được trên iPhone. Tuy nhiên, còn quá nhiều câu hỏi hóc búa phải trăn trở: thắng xe như thế nào, tăng tốc ra sao, chuyển số cho xe như thế nào? Không có ai có kiến thức về xe ô tô, động lực học cơ bản cũng quên sạch.

Ngày thứ 8: tôi quyết định phải đọc lại những kiến thức vật lý cơ bản và bắt đầu từ 3 định luật Newton. Very stupid.

Buổi sáng ngày thứ 9: tôi nghĩ trong đầu: tại sao phải là SiO2. Sao không tìm thử một hướng mới. Tôi mò mẫm trong các search engine và vô tình tìm được một tutorial sample cho game đua xe ở Unity engine. Hura! có vẻ bắt đầu thuận lợi.
Chiều: phát hiện ra Unity3D có version cài trên Windows. Bắt đầu cài đặt và sau đó run thử tutorial. Cool! diễn tiến khá tốt đẹp - xe chạy smooth, có cả âm thanh, thắng và gài số tự động.

Ngày thứ 10: họp team và chia task. Công việc cần làm bao gồm:
+ Đọc hiểu script để điều khiển xe
+ Tìm hiểu cấu trúc 3D của xe trong game và yêu cầu nhóm design giúp chúng tôi để có 1 mô hình xe khác cho việc thử nghiệm
+ Tìm hiểu cách hiện thực GUI trên Unity để hiện thực một số màn hình

Ngày thứ 12: chúng tôi hiểu tương đối về cách điều khiển xe và giờ đây có thể thay đổi được cả terrain và mô hình xe. Một thành công vượt ngoài mong đợi.


Ngày thứ 14: chúng tôi gặp khó khăn khi đưa game chạy trên iPhone. Mô hình 3D khá nặng và code chưa được optimize nên chỉ cần vừa start game là bị crash. Mặc dù game chạy khá cool trên desktop và web.


Ngày thứ 15: bắt tay vào research các tips để optimize performance. Chúng tôi có may mắn quen với một người bạn đã từng làm game trên Unity (Hạo - cty Halovi). Bạn đã giúp chúng tôi khá nhiều trong việc tư vấn optimize performance cho game.

Ngày thứ 17: tôi collect lại tất cả các tips and tricks để optimize performance cho Unity iPhone và đưa vào một checklist. Chúng tôi bắt tay optimize từng điểm, từng điểm một. Ngay cả phép cộng, trừ, nhân, chia trên script cũng phải được cân nhắc và review từng dòng. Ví dụ: a / 2 sẽ chậm hơn a * 0.5, ...

Ngày thứ 19: game đã chạy được trên iPhone nhưng với FPS bằng 5, siêu giật và gần như không điều khiển được. Lại tiếp tục tìm trick optimize performance và optimize tiếp.

Ngày thứ 21: xe có thể chạy trên iPhone với FPS bằng 15. Điều khiển khá smooth. Nhưng tiếc thay, xe chỉ có thể chạy với 4 bánh và 2 trục, terrain thì gần như chỉ là một mặt phẳng.
Chúng tôi buộc phải nhờ cầu viện của bộ phận design. Mô hình phải được tối ưu hơn nữa. Càng ít polygon càng tốt, càng ít texture càng tốt. Chỉ có một câu phát biểu duy nhất trong lập trình game: phải cân bằng 2 yếu tố "đẹp" và "nhanh".

Ngày thứ 23: bắt đầu có những mâu thuẫn nhỏ. Mâu thuẫn lớn nhất xuất phát từ việc: các anh design cho rằng đã optimize hoàn toàn mô hình 3D, xe chỉ có 6K polygons. Tại sao khi load xe trong Unity lại có thể là 112K triangles?
Phải tìm cách giải quyết conflict và chỉ ra điểm cần optimize tiếp theo. Có vẻ sự sống của chúng tôi đang bi đát.

Ngày thứ 24: tôi đã giải thích được vì sao có sự khác biệt giữa số polygon trong Maya và trong Unity. Nguyên nhân xuất phát từ mô hình lý thuyết về texture mapping.
Lại họp nhóm - và lần này có cả 3D design group. Chúng tôi biết các anh cũng rất mệt vì đã support chúng tôi rất nhiều.
Cuộc họp giải quyết được khá nhiều vấn đề, và cơ bản chúng tôi biết cần optimize thêm những gì, làm sao để đo được kết quả số polygons thực tế trên game từ một mô hình 3D.

Ngày thứ 25: buộc phải release một bản demo trên web cho khách hàng review - vì version hiện tại chưa thể chạy được trên iPhone smooth.

Ngày thứ 27: chúng tôi đã có một version chạy với FPS = 15 trên iPhone với mô hình xe và terrain khá ổn. Tuy nhiên sau một vài thay đổi nhỏ, FPS lại rớt về 5. Very stupid.

Ngày thứ 28: phát hiện được một trick để optimize về physic của Unity. Đây là một bước tiến khá vượt bực. Chúng tôi giảm số frame vật lý xuống để làm tăng FPS và đã thành công. Tuy nhiên việc control xe có chút khó khăn vì frame vật lý không còn liên tục nữa.

Ngày thứ 29: optimize script để làm cho việc control xe smooth hơn bằng cách phân tách các hàm xử lý vào Update và FixedUpdate hợp lý.

Ngày thứ 30: bắt tay vào làm GUI cho các màn hình game. Hoàn thiện kịch bản.

Từ ngày thứ 31-34: chỉ hoàn tất kịch bản game và fix các bug về mô hình, control xe smooth hơn.

Ngày thứ 35: add thêm âm thanh cho game: tiếng xe chạy, tiếng va chạm vào tường.

Ngày thứ 36: phát hiện ra deployment guideline của mình thiếu đoạn jailbreak iPhone. Hì hục hết buổi sáng và nửa buổi chiều để jailbreak iPhone. Từ đó về sau, chúng tôi tự hào có thể jailbreak iPhone trong 5 phút.

Ngày thứ 37: chúng tôi không thể deploy cho khách hàng bằng cách sử dụng jailbreak iPhone. Họ bảo rằng cách này quá khó. Thật sự, Apple có support cách deploy AdHoc distribution cho beta user - sử dụng iTunes. Chỉ cần có UID của iPhone + provisioning profile (một dạng certificate để iTunes nhận dạng và install application).
Chiều: loay hoay mãi không deploy được mặc dù nghĩ rằng đã làm đúng tất cả các step. Stuck!

Đến gần 10h tối, thì cũng deploy thành công bằng AdHoc distribution. Viết mail thông báo cho onshore PM.

1 AM: bật mail công ty để check xem có tin gì mới. Problem: Onshore PM không deploy được theo kiểu AdHoc mặc dù mình đã đăng kí UID iPhone của họ với Apple và cung cấp đúng provisioning profile. Lúc chiều chính xác mình đã deploy thành công với iPhone 3G, 2G và 3GS. Wtf's happenning?

4 AM: search hoài nhưng vẫn stuck - vì thấy mình đã apply hết các trick tìm được rồi. Đi ngủ.

Ngày thứ 38: bị áp lực từ onshore và khách hàng. Với tất cả thông tin họ cung cấp, vẫn không tìm ra được vấn đề do đâu.
Lại một đêm ngồi làm đến 4 AM. Không dám check mail sợ bị áp lực không research tiếp được. Bật mail lên ghi vài dòng suggestion: "đề nghị backup solution hack iPhone và deploy bằng SSH. Onshore cần thử gấp cách này và cho chúng tôi kết quả, để xử lý những tình huống phát sinh khác"

Ngày thứ 39: vô vọng, kiệt sức. Vậy mà trước khi vô công ty phải refresh lại cái mặt để anh em nhìn vô không thấy nản. Chỉ có một câu nói còn ám ảnh mãi trong đầu: phải đốt cháy chính mình thì mới có thể truyền lửa cho người khác được. Lửa ơi trong tôi, xin đừng tắt.

Bật mail thì nghe tin Jeremy deploy thành công bằng cách jailbreak iPhone 3G và 3GS. Một chút hy vọng lóe lên. Dù sao thì cũng không phải cùng đường. Mặc dù vậy, khách hàng vẫn không happy.
Lại phải tìm tiếp. Thức đến 3 AM thì đuối. Có đọc được loáng thoáng 2 cách tạo application ID trên Apple là static và wildcard. Wildcard có nghĩa là dùng tên có * để đăng ký. Ví dụ: com.pyco.*, static là tên chính xác.
Đọc nhưng không remote vô được máy MAC ở công ty để làm.

Ngày thứ 40: buổi sáng, build cái app theo cách dùng wildcard app ID. Nhưng phải đợi onshore PM đến chiều, vì lệch múi giờ. Send app lúc 1 h chiều, ngồi đợi.
3h PM: Nicolas gõ qua MSN. Congratulation, it's working. You're the best.
Thở phào nhẹ nhỏm. Muốn hét lên Eureka, nhưng sợ bà con nói mình khùng.

CTO phải nhảy vào can thiệp vì project quá quan trọng. Nhưng lúc Gilbert vừa định kêu mình vào conference thì problem đã xử xong.
Buổi tối, ngồi support onshore deploy với bản build mới đến gần 11h mới về nhà. Oải, chỉ muốn ngủ.

Ngày thứ 41: âm thanh của xe bị chê. Hic, phải ngồi mở Youtube lên coi xe Ferrari chạy thế nào. Từ nhỏ tới lớn không coi đua xe, không biết nó gầm rú ra sao để làm cho chính xác.
Define solution + apply âm cho xe rú từ nhỏ đến to, từ to đến nhỏ. Làm hoài vẫn không giống. Nicolas chỉ nói: tao thấy mày làm hoài nó cũng chẵng khác biệt mấy.
Team ai cũng oải. Mặt mình lúc đó nhìn chắc cũng bi kịch lắm nên anh em nó mua cơm tối cho ăn mà cứ đòi cho free. Hic, quyết định của mình lúc đó: anh em về nhà relax đi, oải hết rồi. Mình ở lại confirm với Nicolas chút rồi về.

Sau một hồi discuss, quyết định phải code để cho onshore thấy hiệu ứng âm thanh như họ yêu cầu. Đến 11h thì xong task. Nicolas bảo: âm thanh vậy tao thấy được rối á. Về nhà.

Ngày thứ 42: fix thêm một số effects và chỉnh lại một chút về GUI cho hoàn hảo. Game coi như xong.

Ngày thứ 43: nghỉ lễ 2-9. Không dám về nhà vì ở quê không online được. Ngồi nhà nhưng tâm trạng thấp thỏm.

Ngày thứ 44: không có feedback mới. Khách hàng đã happy.

Ngày thứ 45: game được đem triễn lãm ở showroom.

Kết thúc! chúng tôi đã làm nên điều kì diệu như vậy đó. Cảm ơn rất nhiều nhé mọi người. Đặc biệt là Chương và Đạo - những người đã đóng góp rất lớn vào sự thành công của dự án. Anh em chúng ta đã trải qua những tháng ngày thử thách, nhưng cũng rất vui. OT mà đi nhậu thịt chó, uống rượu - thì còn gì bằng, đúng không nào?

Giang hồ

Saturday, August 1, 2009 1 phản hồi

Tình cờ lang thang đọc được bài thơ này.

Giang hồ

-Phạm Hữu Quang-

Tàu đi qua phố, tàu qua phố
Phố lạ mà quen, ta giang hồ
Chẳng lẽ suốt ngày bên bếp vợ
Chẻ củi, trèo thang với... giặt đồ?

Giang hồ đâu bận lo tiền túi
Ngày đi ta chỉ có tay không,
Vợ con chẳng kịp chào xin lỗi
Mây trắng trời xa, trắng cả lòng...

Giang hồ ta ghé nhờ cơm bạn
Đũa lệch mâm suông cũng gọi tình
Gối trang sách cũ nằm nghĩ bụng
Cười xưa Dương Lễ với Lưu Bình.

Giang hồ có bữa ta ngồi quán
Quán vắng mà ta chẳng chịu về
Cô chủ giả đò nghiêng ghế trống
Đếm thấy thừa ra một gốc si.

Giang hồ mấy bận say như chết
Rượu sáng chưa lưa đã rượu chiều
Chí cốt cầm ra chai rượu cốt
Ừ. Thôi. Trời đất cứ liêu xiêu...

Giang hồ ta chẳng thay áo rách
Sá gì chải lược với soi gương
Sáng nay mới hiểu mình tóc bạc
Chợt tiếng trẻ thưa ở bên đường.

Giang hồ ba bữa buồn một bữa,
Thấy núi thành sông biển hoá rừng
Chân sẵn dép giầy, trời sẵn gió
Ngựa về. Ta đứng. Bụi mù tung...

Giang hồ tay nải cầm chưa chắc
Hình như ta mới khóc hôm qua
Giang hồ ta chỉ giang hồ vặt
Nghe tiếng cơm sôi cũng nhớ nhà.

Thích nhất 4 câu cuối: "Giang hồ tay nải cầm chưa chắc. Hình như ta mới khóc hôm qua. Giang hồ ta chỉ giang hồ vặt. Nghe tiếng cơm sôi cũng nhớ nhà". Có chút gì đó giống với tứ thơ trong Tràng Giang của Huy Cận
"Lòng quê dợn dợn vời con nước
Không khói hoàng hôn cũng nhớ nhà."


Thôi thì bỏ qua những bình luận văn chương. Ngẫm lại, từ lúc ta xa quê hương cũng đã 9 năm rồi. Chiều nay, thèm lắm tiếng cơm sôi bên bếp lửa, tiếng mẹ gọi về ăn cơm. Thèm được ngửi mùi rạ cháy trên đồng, mùi mạ non mới chớm. Ta muốn nhìn thấy con sông Hậu và những dòng lục bình trôi giữa dòng phù sa đỏ quạch trong mùa nước đổ. Ba mẹ ơi, quê nhà ơi ... nhớ lắm.
Giang hồ ư? Ừ, ta cũng chỉ là một gã giang hồ vặt bên cuộc đời bé nhỏ này thôi.
Ta đi chẳng phải để xem sông núi rộng dài, chỉ để xem lòng mình dài rộng đến đâu...

Tướng giỏi - anh là ai?

Wednesday, July 22, 2009 1 phản hồi

Chiều nay, tôi tình cờ nghe một mẫu đối thoại giữa 2 người bạn làm tôi phải suy nghĩ khá nhiều:
A: anh làm ở vị trí nào trong công ty?
B: mình làm project manager - ở bộ phận quản lý.
A: chuyên môn của anh là gi?
B: ...
A: ở VN, ít có PM nào không xuất phát từ vị trí developer. Trước đây anh đã từng làm trên những domain nào?
B: mình vào làm ở vị trí quản lý trực tiếp. Chuyên môn của mình là quản lý dự án.
A: wow.
B: ở công ty mình, các department được chia ra theo nhóm chức năng để chuyên môn hóa. Vì vậy người quản lý chỉ tập trung vào quản lý dự án.

Tôi không có ý kiến về mẫu đối thoại ở trên, nhưng tôi thực sự muốn chia sẻ ở góc nhìn của một người thiên về kĩ thuật. Sau mẫu đối thoại đó, tôi tự chiêm nghiệm lại những gì mình đã từng trải qua khi đã từng là một người lính và đôi khi (cần) là một vị tướng. Câu hỏi lớn nhất trong đầu tôi suốt bao năm qua là: làm thế nào để trở thành tướng giỏi?

Trải qua nhiều năm chinh chiến, tôi rút ra được một số kinh nghiệm trận mạc. Vì vậy, tôi muốn truyền tải đến những người anh em đã, đang và sẽ cùng sát cánh bên tôi những đức tính mà tôi cho rằng một vị tướng giỏi bắt buộc phải có. Đó cũng chính là phương châm mà tôi áp dụng trong công việc hiện tại:

1. Gần như không có một vị tướng giỏi nào mà không từng chiến đấu như một người lính. Vì vậy hãy thấu hiểu và chia sẻ với đồng đội của bạn dù ở bất cứ cương vị nào như những người anh em trên cùng một chiến hào.

2. Một người lãnh đạo (leader) giỏi phải có khả năng định hướng cho tập thể. Vì vậy, nếu không có kinh nghiệm chuyên môn và nỗ lực hơn người khác, thì bạn không thể làm lãnh đạo. (không thể chấp nhận một người leader chỉ đơn thuần quản lý task, theo dõi tiến độ, và chỉ nói mà không biết làm).

3. Cho dù ở bất kì hoàn cảnh khắc nghiệt nào đi nữa, hãy hiểu rằng tâm trạng/ tinh thần của bạn chính là của cả tập thể. Bạn không được nản chí hoặc ít nhất không thể hiện điều đó ra trước mặt những người đồng sự. Phải động viên chính bản thân mình thì mới có thể động viên được người khác.

4. Đức hy sinh: trong mọi hoàn cảnh khắc nghiệt, hãy là người tiên phong gánh chịu trách nhiệm. Dù thành viên của bạn có phạm phải sai lầm chết người nào đi nữa thì đó cũng là lỗi của chính bạn. Vì một lãnh đạo giỏi sẽ không thể để thành viên của mình phạm sai lầm. Hãy nhường vinh dự và phần thưởng cao quý nhất cho những thành viên của bạn nếu đạt được thành quả - vì không có họ, bạn sẽ không là gì cả.

5. Dám công nhận khuyết điểm trước tập thể: nếu bạn phạm sai lầm, hãy thừa nhận rằng mình sai. Đừng cố gắng bao biện hoặc đỗ lỗi cho hoàn cảnh. Không nghiêm khắc với chính mình, thì không ai có thể phục bạn được.

6. Truyền lửa: hãy đốt cháy chính mình để lan tỏa ngọn lửa cho tập thể. Tôi không bao giờ làm bất kì điều gì mà không dồn hết sức với tất cả đam mê, nhiệt huyết. Chính điều đó sẽ giúp cho đồng đội của tôi sẽ cùng tôi thắp lên một ngọn lửa lớn để đốt cháy những khó khăn trước mặt.

Tôi tin rằng không có một người lãnh đạo giỏi nào không có đủ những đức tính ở trên. Tôi kỳ vọng những người đồng sự của tôi và tôi sẽ trở thành những người lãnh đạo giỏi trong tương lai.

Anh là một con cừu - Bùi Chí Vinh - KBird - Hoàng Hà

Thursday, July 16, 2009 0 phản hồi

Sáng tác (nguyên bản): Bùi Chí Vinh

Cướp hết tình yêu dành cho mẹ anh đi
Em cướp hết như một người chinh phục
Kể từ đây không còn ai thân thuộc
Anh mồ côi trong đôi mắt em rồi

Hãy an ủi anh bằng những nụ hôn môi
Hãy che chở anh bằng vòng tay con gái
Hãy dạy anh đánh vần và tập nói:
" Yêu, yêu, yêu ... " cho đến lúc lìa đời

Em đã trở thành một bà mẹ nhân đôi
Đi chăn dắt một con cừu thần thoại
Một con cừu chứ sao? Đầy vụng dại
Anh là con cừu tình nguyện được ... mồ côi

KBird:

Anh là con cừu tình nguyện được ... mồ côi
Dù muốn hay không ... cũng trót yêu rồi
Nếu chăn dắt xin em nhè nhẹ
Đừng để cừu này ... ngỏm mất toi.

Hoàng Hà:
@ Trandangkhoa:

Này cừu non,ngươi mau ngoan nhé.
Đây suối trong,kia đồng cỏ xanh tươi
Có gió,có hoa và nắng nhuộm
Xanh thẳm làn mây phía cuối đồi.

Dẫu tình yêu ta không thay thế
Như tình yêu người mẹ thứ hai
Nhưng nếu lỡ một mai dâu bể
Sẽ cùng ngươi đi hết đường dài.

Code for you

0 phản hồi

while(true) {
loveyou();
}

Chết

Friday, June 26, 2009 0 phản hồi

Sáng nay chat với Thanh, cô bạn cũ hồi phổ thông. Nghe tin mấy đứa bạn học cùng khóa lớp 12 vừa qua đời. Bỗng dưng giật mình: phải chăng con người ta có số. Tự nhiên nghĩ loáng thoáng lại bài viết về 1 anh chàng IT vừa chết ở eTown, đâm ra nghĩ vu vơ.

Ai cũng phải trải qua sinh, lão, bệnh, tử. Cuộc sống vô thường như cái lẽ tự nhiên của nó.
Bạn tôi ơi, rũ bỏ hết chấp nê đi. Dẫu sao ta cũng chỉ có một kiếp đời để sống cho trọn vẹn. Cố sống sao cho đừng thẹn với lòng.

Sợ

Wednesday, June 17, 2009 0 phản hồi

Ai cũng có một nỗi sợ hãi. Nhưng mỗi người có những cách khác nhau để đối diện với nó.

Có kẻ sợ quá hóa liều - có thể làm được những điều phi thường trong cơn thập tử nhất sinh. Có kẻ chết trước khi nỗi sợ hãi kịp đến hoặc chết cả vì một điều không đáng sợ. Có kẻ bình chân như vại để phó mặc cho số phận.


Sử xưa ghi lại rằng: tướng thì không thể sợ, nếu sợ thì không làm tướng.
Có một vị tướng nọ trong lúc bị bao vây nguy khốn thì thét lên rằng: "Chúng ta có thể chết - nhưng ta hãy chết như những người hùng. Tôi tự hào được chết cùng anh em trong trận chiến cuối cùng này". Ông lao thẳng ra phía trước và hô lệnh xung phong. Câu nói và hành động can đảm đó đã làm cho quân sĩ hết mình chiến đấu và giúp cho vị tướng nọ thoát khỏi vòng vây. Phục lắm thay.

Ngày nay, ngán ngẫm thay. Tướng quân thường ko như ta mong đợi. Chẳng lẽ tích xưa chỉ là huyền thoại thôi sao?
Có một người lính tự trấn an mình: dẫu ta không phải là tướng, ta vẫn nguyện chết như một người hùng bên cạnh những người anh em ta cùng kề vai sát cánh.

Dốc một bầu rượu uống cho thật say mà ngâm thơ Lý Bạch:

Bồ đào mỹ tữu dạ quang bôi
Dục ẩm tỳ bà mã thượng thôi
Túy ngọa sa trường quân mạc tiếu
Cổ lai chinh chiến kỉ nhân hồi.

(Viết cho tâm sự một người bạn trong một project biết chắc là chết)
Update:
Bài này viết sau một buổi đi uống cafe với thằng bạn làm ở công ty XYZ. Không phải tâm sự của tại hạ. Xin anh em đồng đạo đừng hiểu lầm.

Giận

Tuesday, June 16, 2009 0 phản hồi

Hôm nay bị stress và bực mình nhiều chuyện nên xem lại cái blog bên Yahoo cũ để relax và check coi lâu rồi có ai comment gì ko. Tình cờ đọc lại một bài thơ mình viết tặng một người - kỉ niệm một lần giận hờn. Nghĩ cũng vui vui, nên post lại đây. Chờ lần kế tiếp xài lại...

Giận

Đêm buồn ngắm sao rơi
Anh nhớ em quá trời
Anh làm thơ con cóc.
Chỉ để chọc em vui

Đừng giận anh nữa nhé
Hai đứa mình một đôi
Vui buồn cùng chia sẻ
Anh chỉ mong thế thôi

Buồn nào cũng qua hết
Ta yêu nhau đi thôi
Cuộc đời này ngắn lắm
Giận nhau làm chi trời?

T.D.K

Tri chi vị tri chi - bất tri vị bất tri - thị tri dã

Thursday, June 11, 2009 0 phản hồi

Tri chi vị tri chi, bất tri vị bất tri, thị tri dã
"Biết thì nói là biết, không biết thì nói là không biết. Thế mới thật là biết vậy"

Một câu nói đáng để ta phải suy ngẫm.
Dạo này ra đường hay gặp nhiều người làm ngược lại, nên đành tạm đảo lại câu này:

"Tri chi vị bất tri, bất tri vị tri, thị bất tri dã"
Tạm dịch: Kẻ biết thì bảo là không, kẻ không biết (hoặc biết ba mớ) thì huênh hoang rằng mình biết, hóa ra cũng là phường không biết như nhau cả mà thôi.

Sách có câu rằng: không có gì hại hơn là kẻ không biết gì mà nghĩ rằng mình giỏi. Hại lắm thay!

Hãy cho tôi một xô nước ...

Thursday, June 4, 2009 0 phản hồi

Hãy cho tôi một xô nước
Để dập tắt những đam mê ...
đang rừng rực cháy trong lòng
Nhưng trước khi tắt
hãy cho tôi một ngọn gió
Để thổi bùng lên ánh lửa.

Tôi muốn cháy hết mình
... đến lúc rạng đông.

Vũ khí mới - cuộc chiến mới

Sunday, May 31, 2009 0 phản hồi

Vũ khí mới

Trước khi xuống núi, tổ sư có dặn rằng:
Đỉnh cao của võ học cốt không phải ở binh khí - mà nằm ở công phu của người học võ.
Sự tinh diệu của tin học không phải nằm ở công cụ, mà ở nằm ở đẳng cấp của người lập trình. Khi đã đạt được cảnh giới thượng thừa, thì với notepad hay một tờ giấy lộn con cũng có thể tạo ra một phần mềm tuyệt hảo.

Sau khi xuống núi mấy năm - suy đi ngẫm lại thấy mình vẫn chưa đạt được cảnh giới thượng thừa của Tin học diệu pháp, Trần mỗ quyết định quay trở lại xài tool. Tất cả chỉ vì một chân lý đơn giản, võ công cao đến mấy - bị súng bắn cũng chết...Thôi thì quyết tâm mua một con laptop HP trang bị đầy đủ các tool cho cái nghiệp "nghiên cứu và phá hủy" (R&D). Kì vọng là nó đem lại cho mình nhiều lợi ích so với chi phí bỏ ra.

Cuộc chiến mới

Cái plan research năm nay có chút thay đổi. Tự dưng phát hiện một số hướng kĩ thuật mới và có xu hướng phát triển cực hot trong vài năm tới - nên quyết định đầu tư cho tương lai. Cuộc chiến này có vẻ cam go - vì có khả năng bị thiếu vốn. Thế nhưng không thử làm sao thắng.

Đường đi khó không phải vì ngăn sông cách núi - mà khó vì lòng người ngại núi e sông.

Relax cuối tuần ở công viên Tao Đàn và con ông hàng xóm

Tuesday, May 26, 2009 0 phản hồi



Giấc mơ phần mềm

Friday, May 22, 2009 0 phản hồi

Tôi thường hay mơ một ngày nào đó về đội ngũ phát triển phần mềm quanh mình:
+ Tất cả Project manager không chỉ biết hỏi team mình: làm đến đâu? khi nào xong? cái này làm bao lâu? mà phải am hiểu về kĩ thuật, thông cảm và chia sẻ được với những thành viên của dự án, giải quyết được những điểm gút mắc giữa khách hàng và nhóm phát triển.
+ Tất cả Team leader: ngoài khả năng định hướng cho team về kĩ thuật, giải quyết vấn đề tốt, họ có thể tư vấn cho khách hàng từ ý tưởng - kiến trúc - và công nghệ xây dựng sản phẩm. Và hơn thế nữa, họ có thể thắp cho team một ngọn lửa của niềm đam mê trong công việc.
+ Tất cả những thành viên của dự án ĐƯỢC tham gia với tư cách là một người chủ sản phẩm - chứ không phải chỉ là những anh thợ nề cần mẫn.

Tỉnh lại đi! đây chỉ mới là năm 2009 ở Việt Nam thôi.

Ngây thơ và láu cá

Saturday, April 25, 2009 0 phản hồi

Ngây thơ vô .. số tội.



Láu cá hông nè?


2 tấm hình chụp cách đây vài tháng trong một chuyến đi xả stress ở Bình Châu.

Thơ của thời sinh viên

Friday, April 24, 2009 2 phản hồi

Cách đây mấy hôm, tình cờ gặp một em gái quen từ những ngày sinh viên trên net. Em hỏi: dạo này anh còn làm thơ không? Tôi trả lời: dạo này anh bận quá, với lại cái nghiệp IT nó giết chết cái máu thơ trong anh rồi. Em nói thích một bài thơ về áo trắng của tôi. Em tìm trên blog của tôi mà không thấy. Tôi post lại bài thơ này trên blog để em đọc cho vui - và cũng để tôi có thể đọc lại chính tôi trong cái tuổi sinh viên mơ  mộng ấy.

Thật ra bài thơ này tên là Không đề 2 (nó nằm trong một chùm thơ tôi viết mà ko biết đặt tựa là gì)
Không đề 2

Anh gửi tặng em một cánh hồng
Mà em hờ hững cứ như không
Đời anh nghèo quá nên phải chịu
Áo rách bươm sao đủ sưởi ấm lòng

Em hỏi anh sao thích màu áo trắng
Anh trả lời: "không đủ áo để thay"
Tấm áo cũ của ba anh mặc lại
Chút tiền tiêu sao đắp đủ hình hài

Em hỏi anh vì sao lãng mạn
Thích thơ buồn và thích ngắm hòang hôn
Anh khẽ đáp : đời anh rách rưới
Phải muợn thơ lấp khỏang trống tâm hồn

Bài thơ hơi nhảm nhưng đằng sau nó là một lịch sử khá buồn cười.
Ngày còn đi học, thật tình tôi chỉ có mặc áo sơ mi trắng và quần tây. Nhà nghèo, áo toàn mặc lại của ba. Có cái áo sờn và rách hết cả cổ, nhưng vẫn mặc.
Có một lần, thằng bạn thân rủ đi uống cafe. Nó kể chuyện về một cô bạn gái nó vừa quen (cùng lớp, cùng khóa - tạm giấu tên. Kể ra chắc nó giết mình chết). Nó bảo: sau khi tao làm quen em thành công, có lần tao hỏi: người em thích đầu tiên trong đời là ai? mày biết nó trả lời thế nào ko?

Tôi hơi tò mò: là ai vậy mày?
Là mày đó. Nó dòm tôi.
Ặc, mày khùng hả - tôi tròn xoe mắt. Tao nghèo rớt mồng tơi. Xấu trai nữa, nó thích tao làm gì? mày đừng có ghen rồi phán bậy nha. Dễ mất lòng lắm đó.

Thiệt mà - nó thích mày đơn giản chỉ vì lý do là nó thấy cứ mặc áo trắng đi học hoài.
Nghe tới đó, tôi chới với rụng rời tay chân. Dù nó nói vậy, tôi vẫn cứ mặc áo trắng đi học. Tiền tiêu thời sinh viên ba cọc ba đồng. Mỗi lần xài tiền vào bất cứ việc gì, tôi cũng nghĩ về ba mẹ- những người đang vất vả lo cho tôi.


Bonus cho bài viết: ngày đó, tôi lãng đãng đến mức hơi điên điên. Có lần nghe thằng bạn kể về chuyện tình của nó và một cô bé chơi thân từ nhỏ, những suy nghĩ và cảm xúc trong ngày nó tiễn em ra phi trường(cô bé này sang US lấy chồng Việt Kiều). Tôi chạnh lòng sáng tác một bài thơ cho nó (cứ y chang như mình vừa bị em kia chia tay). Đến giờ vẫn ko thể nào hiểu nổi sao mình có thể có những cảm xúc như vậy.

Tiễn bạn

Tiễn em ra phi trường
Bước chân buồn vương vương
Chào em cô bạn nhỏ
Một thời ta thầm thương

Ngày xưa em còn bé
Tính hay dỗi hay hờn
Có chùm me nho nhỏ
Ta nhường em phần hơn

Giờ đây em người lớn
Tóc dài ngan ngát hương
Áo dài tha thướt trắng
Ai ngẩn ngơ cuối đường

Ta ôm tình mộng ảo
Tình mỏng manh như gương
Một ngày gương vỡ vụn
Tình ơi ! sao chán chường

Em lấy chồng xứ lạ
Giờ lìa xa quê hương
Chào em ! cô bạn nhỏ
Tiễn em một quãng đường

                   T.D.K

Dù sao đi nữa, những năm tháng sinh viên đã để lại cho tôi nhiều kỉ niệm đẹp

Cảm ơn những năm tháng sinh viên gian khó đã giúp tôi trưởng thành.
Cảm ơn mày - áo trắng.



Nghệ thuật ăn mày

Thursday, April 23, 2009 0 phản hồi

Đọc bài viết này thấy cũng hay và vui nên post lại lên đây để mọi người cùng xem.

(nguồn: blog Trang Hạ)


Tôi xách túi đồ nhãn hiệu Levi's ra khỏi Plaza rồi đứng lại ở cửa chờ bạn. Một tay ăn mày chuyên nghiệp phát hiện ra tôi, sán tới đứng trước mặt. Câu chuyện của tôi chỉ có thế thôi. Thế nhưng tay ăn mày đã dạy tôi một bài học kinh tế còn sâu sắc hơn một khoá học tại chức kinh tế ở trường. Tôi kể câu chuyện này chính bởi ý nguyện của tay ăn mày đó.


- Xin anh... cho tôi ít tiền đi! - Tôi đứng đó chả có việc gì nên tiện tay vứt cho hắn đồng tiền xu, rồi bắt chuyện cùng nhau.

Ăn mày rất thích kể lể.

- Tôi chỉ ăn mày quanh khu mua sắm này thôi, anh biết không? Tôi chỉ liếc một phát là thấy anh ngay. Đi mua Levi's ở Plaza chắc chắn nhiều tiền...

- Hả? Ông cũng hiểu đời phết nhỉ! - Tôi ngạc nhiên.

- Làm ăn mày, cũng phải ăn mày cho nó có khoa học. - Ông ta bắt đầu mở máy.

Tôi ngẫm nghĩ một lát, thấy thú vị bèn hỏi:

- Thế nào là ăn mày một cách khoa học?

Tôi nhìn kỹ ông ta, đầu tóc rối bù, quần áo rách nát, tay gầy giơ xương, nhưng lại sạch sẽ.

Ông ta giảng giải:

- Ai chẳng sợ và ghét ăn mày, nhưng tôi tin anh không ghét tôi, tôi đoan chắc điều đó. Đấy là điểm tôi khác biệt với những thằng ăn mày khác.

Tôi gật đầu đồng ý, đúng là tôi không ghét ông ta, nên tôi đang nói chuyện với ông ta đấy thôi.

- Tôi biết phân tích SWOT, những ưu thế, bất lợi, những cơ hội và nguy cơ. Đối mặt với những thằng ăn mày là đối thủ cạnh tranh của tôi, ưu thế (Strengths) của tôi là tôi không làm người ta phản cảm, lánh sợ. Cơ hội (Opportunities) và nguy cơ (Threats) thì chỉ là những yếu tố điều kiện bên ngoài thuộc về hoàn cảnh, có thể là dân số ở đây đông hay vắng, thành phố có quyết định chỉnh trang đô thị, dẹp hè phố chăng...

- Click the image to open in full size........?

- Tôi đã từng tính toán rất cụ tỉ (cụ thể và tỉ mỉ) rằng, khu vực thương mại này người qua lại đông, mỗi ngày khoảng mười nghìn người, nghèo thì nhiều lắm, nhưng người giàu còn nhiều hơn. Trên phương diện lý luận thì giả như mỗi ngày tôi xin được mỗi người một đồng xu một nghìn đồng, thì mỗi tháng thu nhập của tôi đã được ba trăm triệu đồng. Nhưng thực tế thì đâu phải ai cũng cho ăn mày tiền, mà một ngày làm sao tôi đi xin được mười nghìn lượt người. Vì thế, tôi phải phân tích, ai là khách hàng mục tiêu của tôi, đâu là khách hàng tiềm năng của tôi.

Ông ta lấy giọng nói tiếp:

- Ở khu Plaza này thì khách hàng mục tiêu của tôi chiếm khoảng 30% số lượng người mua sắm, tỉ lệ thành công khoảng 70%. Lượng khách hàng tiềm năng chiếm khoảng 20%, tỉ lệ thành công trên đối tượng này khoảng 50%. Còn lại 50% số người, tôi chọn cách là bỏ qua họ, bởi tôi không có đủ thời gian để tìm vận may của mình với họ, tức là xin tiền họ.

- Thế ông định nghĩa thế nào về khách hàng của ông? - Tôi căn vặn.

- Trước tiên, khách hàng mục tiêu nhé. Thì những nam thanh niên trẻ như anh đấy, có thu nhập, nên tiêu tiền không lưỡng lự. Ngoài ra các đôi tình nhân cũng nằm trong đối tượng khách hàng mục tiêu của tôi, họ không thể mất mặt trước bạn khác phái, vì thế đành phải ra tay hào phóng. Rồi tôi chọn các cô gái xinh đẹp đi một mình là khách hàng tiềm năng, bởi họ rất sợ bị lẽo đẽo theo, chắc chắn họ chọn cách bỏ tiền ra cho rảnh nợ. Hai đối tượng này đều thuộc tầm tuổi 20-30. Nếu tuổi khách hàng nhỏ quá, họ không có thu nhập, mà tuổi già hơn, thì họ có thể đã có gia đình, tiền bạc bị vợ cầm hết rồi. Những ông chồng đó biết đâu có khi đang âm thầm tiếc hận rằng không thể ngửa tay ra xin tiền của tôi ấy chứ!

- Thế thì mỗi ngày ông xin được bao nhiêu tiền?

- Thứ hai đến thứ sáu, sẽ kém một chút, khoảng hai trăm nghìn. Cuối tuần thậm chí có thể 4-500 nghìn.

- Hả? Nhiều vậy sao? Click the image to open in full size.

Thấy tôi nghi ngờ, ông ta tính cho tôi thấy:

- Tôi cũng khác gì anh, tôi cũng làm việc tám giờ vàng ngọc. Buổi sáng từ 11h đến tối 7h, cuối tuần vẫn đi làm như thường. Mỗi lần ăn mày một người tôi mất khoảng 5 giây, trừ đi thời gian tôi đi lại, di chuyển giữa các mục tiêu, thường một phút tôi xin được một lần được một đồng xu 1 nghìn, 8 tiếng tôi xin được 480 đồng một nghìn, rồi tính với tỉ lệ thành công 60% [(70%+50%)÷2] thì tôi được khoảng 300 nghìn.

Chiến lược ăn mày của tôi là dứt khoát không đeo bám khách chạy dọc phố. Nếu xin mà họ không cho, tôi dứt khoát không bám theo họ. Bởi nếu họ cho tiền thì đã cho ngay rồi, nếu họ cho vì bị đeo bám lâu, thì tỉ lệ thành công cũng nhỏ. Tôi không thể mang thời gian ăn mày có giới hạn của tôi để đi lãng phí trên những người khách này, trong khi tôi có thể xoay ngay sang mục tiêu bên cạnh.

Trời, tay ăn mày này có đầu óc quá đi, phân tích như thể giám đốc kinh doanh hoặc giám đốc tiếp thị vậy.

- Ông nói tiếp đi! - Tôi hào hứng.

- Có người bảo ăn mày có số may hay xui, tôi không nghĩ thế. Lấy ví dụ cho anh nhé, nếu có một thanh niên đẹp trai và một phụ nữ xinh đẹp đứng trước cửa shop đồ lót mỹ phẩm, thì anh sẽ chọn ai để ăn mày?

Tôi ngẫm nghĩ rồi bảo, tôi không biết.

- Anh nên đi đến xin tiền anh thanh niên kia. Vì đứng bên anh ta là một phụ nữ đẹp, anh ta chẳng lẽ lại không cho ăn mày tiền. Nhưng nếu anh đi xin cô gái đẹp, cô ta sẽ giả vờ là ghê sợ anh rồi lánh xa anh.

Thôi cho anh một ví dụ nữa: Hôm nọ đứng ở cửa siêu thị BigC có một cô gái trẻ tay cầm túi đồ vừa mua từ siêu thị, một đôi nam nữ yêu nhau đang đứng ăn kem, và một anh chàng đóng bộ công chức chỉnh tề, tay xách túi đựng máy tính xách tay. Tôi chỉ nhìn họ ba giây, sẽ không ngần ngừ bước thẳng tới mặt cô gái trẻ xin tiền, cô gái cho tôi hẳn hai đồng xu, nhưng ngạc nhiên hỏi tôi tại sao chỉ xin tiền có mỗi cô ta. Tôi trả lời rằng, cái đôi tình nhân kia đang ăn, họ không tiện rút ví ra cho tiền, anh kia trông có vẻ lắm tiền, trông như sếp nhưng vì thế trên người họ thường không có sẵn tiền lẻ. Còn cô vừa mua sắm ở siêu thị ra, cô tất còn ít tiền thừa, tiền lẻ.

Chí lý, tôi càng nghe tay ăn mày nói càng tỉnh cả người ra.

- Cho nên tôi bảo rồi, tri thức quyết định tất cả!

Tôi nghe sếp tôi nói bao lần câu này, nhưng đây là lần đầu tôi nghe một thằng ăn mày nói câu này.

- Ăn mày cũng phải mang tri thức ra mà ăn mày. Chứ ngày ngày nằm ệch ra ở xó chợ, cầu thang lên đường vượt giao lộ, xin ai cho được tiền? Những người đi qua giao lộ, chạy qua cổng chợ đều vội vàng hoặc cồng kềnh, ai ra đấy mà chơi bao giờ, ra đấy xin chỉ mệt người. Phải trang bị tri thức cho chính mình, học kiến thức mới làm người ta thông minh lên, những người thông minh sẽ không bao giờ ngừng học hỏi kiến thức mới. Thế kỷ 21 rồi, bây giờ người ta cần gì, có phải là cần nhân tài không?

Có lần, có một người cho tôi hẳn 50 nghìn, nhờ tôi đứng dưới cửa sổ gào: "Hồng ơi, anh yêu em", gào 100 lần. Tôi tính ra gọi một tiếng mất 5 giây, thời gian cũng tương tự như tôi đi ăn mày một lần, nhưng lợi nhuận đạt được chỉ 500 đồng, còn kém đi ăn mày, thế là tôi từ chối.

Ở đây, nói chung một tay ăn mày một tháng có thể đi xin được một nghìn hoặc tám trăm lần. Người nào may mắn thì cùng lắm đi xin được khoảng hai nghìn lần. Dân số ở đây khoảng ba triệu, ăn mày độ chục anh, tức là tôi cứ khoảng mười nghìn người dân mới ăn mày một người. Như thế thu nhập của tôi ổn định, về cơ bản là cho dù kinh tế thế giới đi lên hay đi xuống, tình hình xin tiền của tôi vẫn ổn định, không biến động nhiều.

Trời, tôi phục tay ăn mày này quá!

- Tôi thường nói tôi là một thằng ăn mày vui vẻ. Những thằng ăn mày khác thường vui vì xin được nhiều tiền. Tôi thường bảo chúng nó là, chúng mày nhầm rồi. Vì vui vẻ thì mới xin được nhiều tiền chứ.

Quá chuẩn!

- Ăn mày là nghề nghiệp của tôi, phải hiểu được niềm vui do công việc của mình mang lại. Lúc trời mưa ít người ra phố, những thằng ăn mày khác đều ủ rũ oán trách hoặc ngủ. Đừng nên như thế, hãy tranh thủ mà cảm nhận vẻ đẹp của thành phố. Tối về tôi dắt vợ và con đi chơi ngắm trời đêm, nhà ba người nói cười vui vẻ, có lúc đi đường gặp đồng nghiệp, tôi có khi cũng vứt cho họ một đồng xu, để thấy họ vui vẻ đi, nhìn họ như nhìn thấy chính mình.

- Ối ông cũng có vợ con?

- Vợ tôi ở nhà làm bà nội trợ, con tôi đi học. Tôi vay tiền ngân hàng mua một căn nhà nhỏ ở ngoại thành, trả nợ dần trong mười năm, vẫn còn sáu năm nữa mới trả hết. Tôi phải nỗ lực kiếm tiền, con tôi còn phải học lên đại học, tôi sẽ cho nó học Quản trị kinh doanh, Marketing, để con tôi có thể trở thành một thằng ăn mày xuất sắc hơn bố nó.

Tôi buột miệng:

- Ông ơi, ông có thu nhận tôi làm đệ tử không?

Tôi yêu em đến nay chừng có thể

Monday, April 20, 2009 0 phản hồi

Trước giờ chỉ biết bài thơ này của Puskin qua bản dịch tiếng Việt. Hôm nay mới tìm được một version tiếng Anh.

Tôi yêu em đến nay chừng có thể


Tôi yêu em đến nay chừng có thể.

Ngọn lửa tình chưa dễ đã tàn phai;

Nhưng không thể để em bận lòng thêm nữa,

Hay hồn em phải đượm bóng u hoài.

***

Tôi yêu em âm thầm không hy vọng,

Lúc rụt rè, khi hậm hực lòng ghen,

Tôi yêu em, yêu chân thành, đằm thắm,

Cầu cho em được người tình như tôi đã yêu em.


Version tiếng Anh:



I loved you, and I probably still do,

And for a while the feeling may remain

But let my love no longer trouble you,

I do not wish to cause you any pain.


I loved you and the hopelessness I knew,

The jealousy, the shyness though in vain

Made up a love so tender and so true

As may God grant you to be loved again

Dust in the wind

0 phản hồi

Mấy hôm nay bị stress, phải dành một ngày chủ nhật relax toàn phần để xả (ko code, ko làm cháo, ko research - chỉ có ăn, chơi, ngủ, nghe nhạc). Tình cờ được nghe bài hát này. Nó khiến mình suy nghĩ nhiều về cuộc đời, về những gì đã và đang làm:


Lyrics

I close my eyes, only for a moment, and the moment's gone

All my dreams, pass before my eyes, a curiosity

Dust in the wind, all they are is dust in the wind.

Same old song, just a drop of water in an endless sea

All we do, crumbles to the ground, though we refuse to see

Dust in the wind, all we are is dust in the wind

[Now] Don't hang on, nothing lasts forever but the earth and sky

It slips away, and all your money won't another minute buy.

Dust in the wind, all we are is dust in the wind

Dust in the wind, everything is dust in the wind.

Giọng hát trong trẻo của Sarah Brightman dìu dặt, nhẹ nhàng như một lời tâm sự. Nó làm cho ta phải thức tỉnh.

"Tất cả những gì chúng ta làm, rồi cũng sẽ vỡ vụn và trở về với đất - dù ta cố tình ko nhận ra
Chúng ta cũng chỉ là những hạt bụi trong gió.
Đừng cố bám víu. Ko có gì tồn tại bất diệt ngoài trời và đất.

...
Tiền bạc ko thể mua được những giây phút đang qua đi.

Bụi trong gió. Chúng ta chỉ là những hạt bụi trong gió."

Nghe xong bài hát, chợt liên tưởng đến bộ phim Benjamin Button. Càng thấm hơn cái triết lý đơn giản: thời gian sẽ xóa sạch tất cả. Mọi thứ rồi sẽ qua đi. Đó là cái lẽ vô thường của trời đất.

Bỗng dưng, tôi chợt nghĩ đến những người mình thương yêu và tự nhủ thầm với lòng:

Đúng, dù ta có là một hạt bụi trong gió, nhưng ko thể phủ nhận rằng ta đang tồn tại. Chúng ta đang sống ko phải chỉ vì chúng ta - mà còn cho những người ta thương yêu và dành cho ta tình yêu thương. Ta sẽ dành trọn kiếp sống hạt bụi này cho những người ta yêu quý.

Cố lên! hạt bụi nhỏ.

Xây dựng framework trong 5 ngày

Thursday, April 16, 2009 0 phản hồi

Mới nghe tưởng là task impossible, nhưng cuối cùng cũng làm xong.

Progress:
+ 1 ngày để suy nghĩ ra một kiến trúc plugin để đảm bảo có thể hot deploy những feature module mới khi ứng dụng đang chạy
+ 1 ngày để build cái framework dựa trên kiến trúc này.
+ 1 ngày để cân nhắc và đưa ra được kết luận: nhu cầu hot deploy là không có thật trong ngữ cảnh của ứng dụng
+ 1 ngày để xây lại kiến trúc.
+ 1 ngày để documentation.

Nếu lật ngược lại:
+ 1 ngày để suy nghĩ ra một kiến trúc plugin để đảm bảo có thể hot deploy những feature module mới khi ứng dụng đang chạy
+ 1 ngày để cân nhắc và đưa ra được kết luận: nhu cầu hot deploy là không có thật trong ngữ cảnh của ứng dụng
+ 1 ngày để xây kiến trúc.
+ 1 ngày để documentation.

thì đã giảm được 1/5 công sức.
Nhảm! Càng lúc càng ngấm thuốc. Vậy mới biết câu hỏi WHY quan trọng như thế nào.

Performance review

Wednesday, April 15, 2009 0 phản hồi

Hôm nay nhận được email thông báo từ HR sau đợt performance review về vị trí mới, dành một chút thời gian để tự review lại bản thân mình sau 6 tháng vừa qua.

Những thành quả đạt được:
+ Xây dựng được một team đi theo 1 hướng kĩ thuật mới (dù chưa đủ mạnh và vẫn còn phụ thuộc vào production khá nhiều). Tuy nhiên hy vọng đây sẽ là một tiền đề để giúp công ty mở rộng thị trường.

+ Cải thiện được khả năng communication đáng kể (Thanks a Vinh đã giúp đỡ). Ví dụ điển hình: dành thời gian để hiểu về đối phương nhiều hơn, kiềm chế được cảm xúc, khả năng giữ im lặng trong những lúc cần thiết, khả năng loppy để đạt được mục tiêu, ...)

+ Tham gia và build thành công nhiều Proof Of Concept với những kĩ thuật tương đối khó

+ Học được nhiều hơn về kinh nghiệm leading + management thông qua quan sát và trao đổi.

+ Đạt được một chút gì đó trong cái gọi là "đắc nhân tâm". Tạo được sự thân thiện, tin tưởng nhiều hơn với bạn đồng nghiệp.

Những điểm cần cải tiến:

+ English communication: giao tiếp hiện tại tạm ổn nhưng chưa nói và viết hay. Đọc một số bài viết PR và quảng bá cho công ty từ HR và onshore, thấy mình cần phải học nhiều hơn nữa.

+ Trang bị nhiều hơn kiến thức về architecture: cần phải đọc và nghiên cứu nhiều hơn về kiến trúc để xây dựng những hệ thống lớn, enterprise,... đây là niềm đam mê mình đang theo đuổi.

+ Kĩ năng đàm phán, thương thuyết: đây là kĩ năng quan trọng ở những vị trí cấp cao. Cái này phải trải nghiệm, thực hành nhiều thì mới nhuần nhuyễn được.

+ Cần học nhiều hơn về: phương pháp luận và quy trình phần mềm, kĩ năng quản lý trong phần mềm, ...

Trời ơi! biển học sao mênh mông đến vậy?

Làm tốt việc và làm đúng việc

Thursday, April 9, 2009 0 phản hồi

Tặng một người anh, một người bạn.

Nguyên văn của câu này là: do the thing right OR do the right thing.
Dưới đây là một câu chuyện ẩn dụ về câu nói này đã để lại nhiều ấn tượng cho tôi.

Nhà vua yêu cầu một vị tướng giỏi đi phát hoang một khu rừng tại một vùng rất xa kinh thành. Vị tướng dẫn theo một đoàn quân đi đến khu vực cần được khai hoang. Với kinh nghiệm sẵn có và tài chỉ huy xuất chúng, chỉ trong vòng 2 tuần, ông đã cùng quân lính mình phát hoang sạch cả khu rừng. Thở phào khoan khoái khi đã hoàn thành công việc, ông tự cho phép mình hưởng thụ bằng cách dẫn một nhóm quân leo lên một ngọn đồi gần đó để ngắm cảnh và nghỉ ngơi. Khi nhìn ra xung quanh từ ngọn đồi, bất giác ông phát hiện ra mình đã phá trụi một khu rừng không phải là khu rừng được nhà vua ra lệnh - mà là một khu rừng lân cận. Kết quả là ông phải mất thêm 2 tuần nữa để hoàn thành công việc mình được giao.

Câu chuyện là một minh chứng cho lập luận: làm đúng việc là tiền đề để tạo cho bạn làm tốt một công việc. Không xác định được công việc mình cần làm thì làm việc dù có tốt thế nào đi nữa cũng là vô nghĩa.

Nhưng có những lúc ta không thể làm đúng việc ... Bởi vì một điều đơn giản, đó là cuộc sống. Nếu cuộc đời lúc nào cũng như mong đợi, thì ...

Dù thế nào đi nữa, cứ cố gắng làm tốt nhất công việc mình cần/phải làm ...

Kĩ năng tìm kiếm thông tin

Wednesday, April 8, 2009 2 phản hồi

Tìm kiếm thông tin là một trong những kĩ năng rất quan trọng để thành công trong công việc. Trước đây thỉnh thoảng tôi thắc mắc tại sao mình có thể tìm được thông tin một cách nhanh và chính xác hơn mọi người. Việc tìm kiếm thông tin gần như đã trở thành một thói quen bản năng hàng ngày nên tôi chưa đúc kết ra được điều gì khác biệt giữa cách tìm kiếm của tôi và người khác. Về sau này có dịp quan sát cách tìm kiếm của mọi người xung quanh, tôi tìm ra một số điểm khác biệt. Bài viết này, tôi muốn hệ thống hóa lại một chút về kĩ năng này và chia sẻ với mọi người.

Các yếu tố quyết định sự thành công trong việc tìm kiếm thông tin

1. Kiến thức về lĩnh vực tìm kiếm: nếu đã có kiến thức cơ bản về vấn đề cần tìm, bạn sẽ dễ hình dung được các bước cần tìm, những trang nào cần đến. Để có được điều này, bạn cần phải làm việc qua một khoảng thời gian để có kinh nghiệm. Nếu bạn bắt tay vào tìm những vấn đề bạn chưa có kiến thức, hãy bắt đầu từ những khái niệm cơ bản để hiểu được vấn đề mình đang tìm.

2. Khả năng diễn đạt vấn đề: bạn có thể hiểu mình cần gì, nhưng nếu bạn không diễn đạt đươc thì không thể tìm kiếm chính xác được. Đặc biệt trong các ngành kĩ thuật, nghiên cứu, thì bạn cần diễn đạt được bằng tiếng Anh về vấn đề bạn cần tìm. Lời lẽ diễn đạt càng súc tích, càng chứa nhiều từ khóa liên quan thì càng tìm chính xác.

3. Khả năng giải quyết vấn đề: khi tìm kiếm những giải pháp, câu trả lời hóc búa - điều bạn cần làm là phải định ra được các bước để giải quyết vấn đề. Cố gắng chia vấn đề ra thành những bài toán nhỏ hơn, dễ tìm được câu trả lời hơn. Tôi nghĩ đây là một trong những kĩ năng mềm và phụ thuộc nhiều vào bản chất của mỗi người. Tuy nhiên nếu rèn luyện, bạn cũng có thể tạo được cho mình.

4. Lòng kiên trì: kiên trì là yếu tố rất quan trọng để quyết định việc tìm kiếm thành công. Đôi khi bạn chỉ cần click vào 1 trang kế tiếp của google là bạn có thể tới đích. Vì vậy, khi nào bạn còn nhìn thấy những từ khóa liên quan đến việc vấn đề cần tìm thì cứ tiếp tục ở những link kế tiếp.

Tôi tìm kiếm thông tin như thế nào?

Bước 1: tìm hiểu tất cả các khái niệm xung quanh vấn đề cần tìm.

Bước 2: Kiểm tra mình hiểu đúng vấn đề chưa và vạch ra các câu hỏi cần tìm cho vấn đề. Với những bài toán phức tạp, tôi định ra một số bộ giải pháp khung và đi tìm câu trả lời cho những điểm còn vướng mắc.

Bước 3: Xác định những nơi cần tìm cho miền vấn đê.
Với những vấn đề cơ bản => tìm trên google.
Với những vấn đề liên quan về khái niệm, học thuật => tìm trên wikipedia.
Với những vấn đề chuyên biệt cho một kĩ thuật => tìm trên những site community và home site của kĩ thuật đó.
Tìm những sách liên quan đến miền vấn đề và đọc lướt để tìm điểm liên quan.
Để tìm bài viết hay liên quan đến một vấn đề => tìm trên các social bookmark site. Phần lớn các link được bookmark trên những site này đều có giá trị và đáng đọc.
...
Bước 4: tìm. Khi gặp một danh sách kết quả phân trang, tôi không bao giờ dừng lại cho đến khi đi đến trang thứ 10. Đây là yếu tố giúp tôi ít khi bỏ sót những nơi có thể có giải pháp.

Lặp lại các bước (1) (2) (3) (4) đến khi không còn đi tiếp được nữa.

Hy vọng là những kinh nghiệm này có thể giúp cho các bạn.

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

Tuesday, April 7, 2009 0 phản hồi

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ở

Sunday, April 5, 2009 0 phản hồi

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.

Mục tiêu và hệ quả

0 phản hồi

Xét những câu dưới đây:
(1) Tôi muốn đạt đến đỉnh cao của nghề nghiệp mà tôi đang theo đuổi
(2) Tôi muốn đạt được doanh số ngày càng nhiều hơn
(3) Tôi muốn yêu và được yêu trọn vẹn.

(4) Tôi muốn trở thành người giàu có.
(5) Tôi muốn hạnh phúc.
(6) Tôi muốn trở thành người nổi tiếng.

(1) (2) (3) là mục tiêu. (4) (5) (6) là hệ quả. Thực sự, giàu có, hạnh phúc, nổi tiếng chẳng qua chỉ là kết quả từ việc đạt được những mục tiêu ta đặt ra trong cuộc sống.
Không có mục tiêu thì không thể có hệ quả.

Nếu nhận được câu hỏi: mục tiêu của anh là gì trong 10 năm nữa?
và câu trả lời của bạn là: tôi muốn trở thành người giàu có.

=> bạn chưa có mục tiêu thực sự nào cả.

Nội mất

Thursday, April 2, 2009 0 phản hồi

Nội qua đời. Một biến cố quá đột ngột với tôi. Cảm thấy hụt hẫng vô cùng. Đến tận thời điểm này, tôi vẫn không thể nào nghĩ rằng nội đã ra đi.

Ước gì tôi có thể được ở bên nội ở những giờ phút cuối cùng.

Relax với lập trình viên

Wednesday, March 25, 2009 0 phản hồi

Làm sao để sếp tức điên


Tại sao lập trình viên ko chịu refactor code?

TinyERP framework

1 phản hồi

Cách đây vài tuần, một người bạn nhờ tư vấn một framework để phát triển ứng dụng winform trên .NET (dùng C# để phát triển). Cái này làm mình nhớ đến một framework tương tự đã build trên Java để làm một số ứng dụng ERP ở Pissoft cách đây 3 năm.

Sau một số chọn lựa, cuối cùng cũng đã thiết kế được phần core và hoàn tất một số feature chính của framework.

Library nền tảng:
         + Spring .NET
         + NHibernate
Hướng tiếp cận:
         + Domain driven: thiết kế hệ thống từ domain entity (ko xuất phát từ RDBMS)

Những feature chính mà framework hỗ trợ:
         + Sinh tự động Database Access Layer, Business layer từ domain entity
         + Hỗ trợ sinh Hibernate mapping từ domain model (ở mức đơn giản và thông dụng nhất). Mô hình mapping và sinh code dựa trên những best practices mà mình đã làm trên những ứng dụng dựa trên NHibernate hơn 3 năm gần đây.

         + Sinh ra GUI cho các domain entity (chưa hỗ trợ cho các quan hệ nhiều nhiều).
         + Cơ chế Validation trên UI cho winform. Cái này bác Microsoft hỗ trợ chuối quá - nên buộc phải viết lại.
Vài screenshot giới thiệu đến mọi người:


                               Tool KGen để generate code

Kết quả sinh code cho lớp đối tượng User


Giao diện và chương trình chạy sau khi sinh code
Form Quản lý user
 
Form edit và tạo mới user:


Một số side-effect:
- Ban đầu định dùng KMyGeneration (K = Khoa :-), vì lúc trước có build một số template tương tự đụng đến nhu cầu phải customize lại tool MyGeneration). Tuy nhiên, template code của MyGeneration và UI của nó hơi khó customize và không tiện dụng cho người dùng. Cuối cùng, build lại 1 tool mới - đặt tên mới: KGen. KGen hỗ trợ viết GUI trên Visual Studio + template viết bằng NVelocity (sáng sủa, dễ đọc và dễ maintain hơn). Thời gian làm cái này mất khoảng 4h). 

- Không dự định dùng commercial UI library, nhưng cuối cùng thấy mất thời gian cho việc build những thứ linh tinh này. Suggest cho anh bạn xài Janus (thanks bác Vinh đã giới thiệu). Tuy nhiên có một bộ UI library khác là Krypton Library - có free một số component cũng khá cool (có thể xem xét).

Cái framework này chỉ viết chơi cho vui. Thời gian build tổng cộng gần 1 tuần. Vì đã có một số kinh nghiệm nên build cũng nhanh.

Sẽ viết một bài để trao đổi về kinh nghiệm build framework cho các ứng dụng ERP from scratch (dựa trên những năm tháng chiến đấu với các ERP app ở Pissoft). :-)

NHibernate query analyzer

0 phản hồi

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

Thursday, March 12, 2009 0 phản hồi

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

0 phản hồi

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