Showing posts with label Chia sẻ. Show all posts
Showing posts with label Chia sẻ. Show all posts

Robot chat thông minh

Tuesday, January 26, 2010 3 phản hồi

Có những ý tưởng ra đời từ sự điên rồ pha lẫn chút lãng mạn.

Có đôi lúc, tôi tự hỏi mình: khi buồn, vui mình sẽ nói với ai. Dù là người bạn thân nhất cũng không thể hiểu được hết chính mình. Tôi muốn tạo cho mình một người bạn - có thể giúp tôi trong công việc, cũng như có thể cho tôi những điều thú vị những lúc tôi cần.

Ngày cuối tuần lang thang, tôi nhớ lại những năm tháng sinh viên. Ngày đó, một người bạn gợi cho tôi cảm hứng viết một chú robot chat từ học kì thứ 3 ĐH. Chúng tôi loay hoay gần 3h đồng hồ để release một sản phẩm robot chat biết học và trả lời những câu hỏi - viết bằng C++. Cả phòng kí túc xá đông nghẹt những khán giả muốn thử "trí thông minh" của con robot này. Chương trình chỉ dựa trên sự so khớp độ chính xác giữa câu hỏi input và những dữ liệu có sẵn rồi đưa ra câu trả lời tương ứng. Sau đó, chúng tôi bỏ đi uống cafe và để lại con robot cho mọi người tha hồ thử nghiệm. Khi trở về, tôi thử chat lại với con robot thì ... than ôi, mỗi câu hỏi của tôi đều bị nó trả lời bằng những câu chửi hết sức bậy bạ (vì đã được train sau gần 2 tiếng đồng hồ). Chúng tôi bật cười và xem như đây là 1 thử nghiệm thất bại. Sau đó vì bận học, nên chúng tôi cũng dần quên đi ý tưởng này.


Đêm cuối tuần, tôi research một số lý thuyết về xử lý ngôn ngữ và những hướng tiếp cận của robot chat. AIML (ngôn ngữ đặc tả trí thông minh nhân tạo) là hướng tiếp cận phổ biến nhất hiện tại trên TG. Có một số hướng khác để hỗ trợ phân tích ngữ nghĩa cuộc thoại, máy học được bổ trợ để làm cho robot chat thông minh hơn. Tuy nhiên các cách tiếp cận này vẫn còn đang được nghiên cứu.

Tôi download được một bộ AIML parser viết trên C# và bắt tay vào những dòng code đầu tiên. Tôi release version 0.1 của robotchat với các tính năng để xử lý một cuộc thoại cơ bản chỉ có chào hỏi. Robot có thể nói với người về những đặc điểm riêng của chủ nó.

Ngày thứ hai, tôi phát hiện AIML vẫn thiếu những syntax mà tôi cần để phát triển ý tưởng. Tôi bắt tay customize AIML parser và hỗ trợ thêm một số tag cần thiết.

...
Dưới đây là các version tôi đã release internal sau 2 ngày coding:
v0.2: robot có thể tìm kiến thức trên wiki/google để trả lời cho người hỏi về những lĩnh vực nó không biết.









v0.3: nếu chủ nó buồn, hoặc vui (tùy theo tâm trạng lúc chat), robot có thể tìm ngẫu nhiên các bài hát, video vui nhộn để play giúp chủ nó relax.


Sản phẩm này sẽ open source vì tôi tin rằng còn có nhiều người điên rồ hơn có thể giúp tôi phát triển thành công sản phẩm này. Và hơn tất cả, tôi luôn tin rằng sự chia sẻ có thể đem lại những giá trị hữu ích cho con người.
Thời điểm công bố bản public release sẽ được thông báo sau. :)

Suy nghĩ tích cực làm thay đổi cuộc đời

Tuesday, January 19, 2010 3 phản hồi

Có nhiều bạn từng tâm sự với tôi:
"Tại sao em làm ở công ty X lâu quá mà em chưa được lên chức? Lương thì bèo bọt. Em thấy em biết nhiều kiến thức, làm cũng tương đối được việc mà sếp ko đả động gì đến. Chán quá."

Đây có lẽ là một câu hỏi chung của rất nhiều bạn, mà cũng có thể là của rất nhiều bạn đồng nghiệp của tôi. Vì vậy, tôi muốn chia sẻ với các bạn những ý kiến dưới góc độ của một người trong cuộc qua bài viết này.

Thoát khỏi bế tắc từ suy nghĩ


Cách đây 5 năm, tôi luôn bị ám ảnh bởi suy nghĩ: làm sao để thành đạt, làm sao kiếm được nhiều tiền? Tôi làm project outsource liên tục, thay đổi công ty liên tục. Trung bình một ngày chỉ ngủ 4-5 giờ vì phần còn lại tôi dành cho công việc và cập nhật những kiến thức cho công việc. Mỗi lần thay đổi công ty tất nhiên mức lương mới sẽ cao hơn ở công ty cũ. Trong hơn 5 năm đi làm, tôi đi qua liên tục 5 công ty, làm những vị trí, vai trò khác nhau. Có một điều sau này tôi nhận ra rằng: mình vẫn ko thoát khỏi sự bế tắc trong cuộc sống. Mỗi khi qua công ty mới, mọi thứ phải setup lại từ đầu. Không tên tuổi, không thương hiệu. Thanh gươm kiến thức trong tay cũng đã mòn vì không đi chuyên sâu vào bất cứ lĩnh vực nào.

Có một lúc tôi chợt tỉnh giấc và hiểu ra rằng: nếu mình ko thay đổi suy nghĩ, thì mãi mãi vẫn chỉ sống trong cái vòng lẩn quẩn này. Đến một lúc nào đó, sức cùng lực kiệt - liệu có thể phiêu lưu mãi nữa hay không?

Kể từ đó, tôi rũ bỏ đi bớt những suy tính cá nhân, lao vào trau dồi những kiến thức nền tảng để củng cố lại mình. Tôi chấp nhận một mức lương thấp hơn nhiều so với công ty cũ. Mỗi giờ làm việc ở công ty, tôi dồn tất cả sự đam mê và tâm huyết. Tôi mở lòng mình ra để chia sẻ với mọi người những gì tôi biết và mong muốn cả tập thể cùng tiến bộ. Càng lúc tôi càng hiểu ra rằng: càng suy nghĩ đến tiền, danh vọng sẽ không đem lại cho mình ích lợi gì cả. Vì về bản chất, tiền bạc và danh vọng chỉ là hệ quả của sự nỗ lực cho một mục tiêu. Ở đời, không có gì nguy hiểm bằng việc không biết mục tiêu của mình là gì.

Thật ra tôi chỉ đạt được một phần của mục tiêu mà tôi đang theo đuổi. Tuy nhiên, tôi cảm nhận rằng chính từ sự thay đổi cách suy nghĩ đã giúp tôi thoát khỏi những bế tắc trong cuộc sống.

Những căn bệnh về suy nghĩ làm cho bạn không thể thành đạt trong công việc


Căn bệnh 1: nhầm tưởng rằng có nhiều kiến thức là có thể thành đạt.
Thật sự đây chỉ là một điều kiện cần, chứ không phải là điều kiện đủ. Không có công ty nào trả lương cho bạn vì những gì bạn biết, mà là vì những gì bạn đóng góp. Nếu có nhiều kiến thức, nhưng bạn không đóng góp nhiều cho công ty, thì kiến thức của bạn đối với họ chỉ là con số 0.

Tôi không phản đối việc bạn phải học thêm kiến thức, nhưng tôi muốn nói đến yếu tố: nên học cái gì?
Có nhiều bạn từng hỏi tôi rằng: lĩnh vực kĩ thuật quá rộng, làm sao em học hết để đáp ứng nhu cầu công việc.


Trả lời: 
Kiến thức về cơ bản có thể phân tách thành: nguyên lý (principles), ứng dụng (practices), và giá trị mà nó đem lại (values).  Nguyên lý thì thay đổi chậm theo thời gian và thật sự chỉ thay đổi khi có sự đột phá từ những cuộc cách mạng về công nghệ/ nghiên cứu lý thuyết. Ứng dụng và giá trị thì thay đổi liên tục và nhiều vô tận.

Nói ví dụ cho dễ hiểu trong phần mềm:

+ Kiến thức về OOP, Design pattern, các phương pháp luận làm phần mềm, các nguyên lý thiết kế hệ thống, .. được xem là những principle.
+ Các ngôn ngữ lập trình, các framework phát triển ứng dụng, cách xài các thư viện hỗ trợ phát triển, .... là những practice và cũng cung cấp cho bạn những value khác nhau tùy vào lĩnh vực.

Trau dồi principle là cách giúp bạn có nền tảng và nhanh chóng nắm bắt tất cả các practices trong nhiều mảng khác nhau. Nhiều bạn đã quan tâm quá nhiều đến "chiêu" (practice) mà bỏ quên nền tảng sẽ dễ dàng bị fail trong các kì phỏng vấn, và thậm chí không được đánh giá cao trong tổ chức.

Bên cạnh đó, bạn cũng cần phải quan tâm đến những mảng kiến thức mà công ty đang cần. Suy nghĩ nhiều hơn về cách để đón đầu những cơ hội sắp tới và trau dồi kiến thức cần thiết cho mục tiêu của bạn.

Căn bệnh 2: quá chú trọng vào cá nhân mà không nghĩ đến tập thể
Ví dụ 1: Khi viết code, có người nghĩ: chỉ cần viết cho xong, chạy đúng. Code mình, mình hiểu. Cần gì viết cho ai hiểu.

Phân tích: Sai rồi bạn ạ. Thời của những lập trình viên anh hùng đã đi qua. Ở thời đại này, bạn không thể làm được gì nếu không làm việc cùng đồng đội (teamwork). Thứ hai, chất lượng code đánh giá chất lượng một lập trình viên. Bạn không muốn hoàn thiện sản phẩm mình làm ra, thì liệu bạn có được tổ chức đánh giá cao không nhỉ?

Ví dụ 2: tôi thích mọi người phải theo ý tôi cơ. Tôi luôn đúng và phải chứng tỏ cho mọi người thấy điều đó. Tôi phải luôn thắng trong mọi cuộc thảo luận.

Phân tích: áp đặt ý kiến là một điều không tốt. Hơn nữa, bạn không thể là thánh, nên không thể tránh khỏi sai sót. Khi một người đồng nghiệp phát biểu một ý không đúng với những gì tôi nghĩ. Tôi luôn đặt ra 2 trường hợp:

+ Tôi và anh ta đang nhìn ở 2 góc nhìn khác nhau trên cùng một vấn đề. Có thể đây là một góc nhìn mới mà tôi chưa nhận ra. Tôi ghi nhận và vẽ nó ra trên bảng để chúng tôi cùng xem xét.

+ Có thể một trong 2 chúng tôi đang nhìn về một sự vật, nhưng mỗi bên có một suy nghĩ méo mó khác nhau. Có thể có người sai. Nhưng theo thuyết tương đối mà nói: luôn có khả năng để điều sai trở thành đúng trong một tình huống đặc biệt.

Tôi luôn khuyến khích mọi người trình bày về quan điểm của mình, và nếu cần thì nhờ họ đưa ra những chứng minh và hành động để phân tích một cách cụ thể.

Một điểm quan trọng nữa: mục tiêu của thảo luận là để tìm giải pháp cho vấn đề, chứ không phải là một buổi trình diễn âm nhạc. Thảo luận sẽ trở thành vô nghĩa nếu nó đi quá xa mục tiêu ban đầu của nó.

Căn bệnh 3: không thích chia sẻ

Ví dụ 1: tớ biết cái này hay lắm, nhưng bí mật. Chỉ mình tớ biết thôi đấy nhé. Thấy tớ có hay không?

Phân tích: Đây là căn bệnh trầm kha của dân IT Việt Nam. Bạn làm được nhiều điều rất hay, bạn có nhiều kinh nghiệm quý báu. Bạn giữ nó làm gì cho riêng bạn? Thế giới Internet phát triển quá xa rồi, bạn có chắc rằng điều bạn đang giữ thực sự là một bí mật về công nghệ. Chia sẻ để cùng nhau phát triển và nhận được nhiều hơn, đó là trách nhiệm và quyền lợi của mỗi cá nhân trong tổ chức.

Ví dụ 2: mình mới làm xong một product/ hoặc có idea khá hay. Nhưng mà nhát quá, nói ra thấy ngại ngại sao á. Có cần nói cho sếp ko nhỉ? Thôi khỏi, chắc chắn ổng biết mình giỏi rồi.

Phân tích: không ai biết bạn đã làm được gì nếu bạn không nói. Âm thầm đóng góp là một điều tốt, tuy nhiên sẽ thiệt thòi nếu không ai công nhận. Mạnh dạn lên bạn nhé. Hơn 20 rồi đấy, nhát thế thì làm sao ... tán được gái nhỉ?

Căn bệnh 4: thiếu thái độ nhiệt huyết và chủ động trong công việc

Ví dụ 1: sếp giao cho 1 task. Nhưng chưa biết làm có được không nữa, chừng nào biết chắc chắn làm được hoặc làm xong thì báo luôn thể.

Phân tích: có biết rằng sếp đang run lắm khi chờ đợi bạn trả lời ko nhỉ? Ít ra bạn phải chủ động báo cáo tiến độ định kì. Nếu sau vài lần như vậy, có lẽ bạn sẽ không nhận được task quan trọng hay cơ hội nào nữa đâu.

Ví dụ 2: cái task này khó quá, mà cũng chả bổ ích gì đối với mình hết. Thôi, không làm đâu.

Phân tích: không ai trả lương cho bạn để bạn làm cái bạn thích cả, họ trả tiền cho công việc mà họ cần. Từ chối một thử thách chính là từ chối đi cơ hội của chính bạn. Hãy tập vượt qua thử thách, đó chính là những kinh nghiệm bổ ích cho cuộc đời bạn.

Ví dụ 3: chán quá, chán quá, chả có việc gì làm hết.

Phân tích: chán là một biểu hiện tâm lý của việc không còn đam mê trong công việc. Không có đam mê = failed. Những người thành đạt luôn tao ra task cho chính mình để cải tiến bản thân hoặc tổ chức, cơ bản vì họ luôn có đam mê và khát khao. Đó là yếu tố giúp họ thành công.


Lời kết

Viết mệt quá, còn nhiều bệnh nữa. Nhưng chắc để update sau đi. Hôm nay vầy đủ rồi.

Lập trình game và 3D trên iPhone

Tuesday, January 5, 2010 0 phản hồi

Gần đây tôi nhận được nhiều email của các bạn hứng thú với lập trình 3D/ game trên iPhone. Các bạn hỏi tôi khá nhiều câu hỏi rất thú vị - đặc biệt là về tài liệu và cách tiếp cận. Tôi sẽ cố gắng giải đáp thắc mắc của các bạn trong nội dung bài viết này.

Phân biệt 2 khái niệm: game engine và 3D engine

Về bản chất, đây là 2 khái niệm khác biệt. Tuy nhiên đôi lúc cũng có chút nhập nhằng.
3D engine: là những thư viện giả lập môi trường 3D trên máy tính. Trong đó đặc thù bao gồm:
+ Mô phỏng/định nghĩa các thực thể 3D.
+ Ánh sáng, đổ bóng.
+ Phủ vật liệu.
+ Giả lập camera.
+ Hiện thực quá trình render ảnh từ môi trường 3D để thành kết quả cuối cùng và hiển thị lên màn hình.

Game engine: là những thư viện hỗ trợ cho quá trình lập trình game. Thông thường một game engine thường bao gồm:
+ 3D/2D engine hỗ trợ cho việc lập trình trên môi trường 3D hoặc 2D.
+ AI (Artificial Intelligence) engine: hỗ trợ cho việc lập trình các yếu tố liên quan đến AI trên game.
+ Physic engine: hỗ trợ việc giả lập các yếu tố vật lý trong môi trường game.
+ Tool hỗ trợ cho việc tạo ra/import các "vật liệu" sử dụng trong game. Ví dụ: tạo terrain (địa hình), tool convert hoặc import các file mô hình, ...

Những thư viện lập trình game/3D trên iPhone

Các bạn có thể tham khảo bài viết này (liệt kê tương đối đầy đủ):
http://www.neverreadpassively.com/2009/03/review-of-iphone-3d-engines.html

Tôi muốn trở thành một expert về lập trình game (đặc biệt là trên iPhone). Cần tiếp cận như thế nào?

Tôi sẽ không trả lời câu hỏi này một cách trực tiếp vì nó khá nhiều cho phạm vi một bài viết. Tuy nhiên, tôi sẽ gợi một số câu hỏi để các bạn tự tìm lời giải đáp.

1. Những kiến thức nào một lập trình viên game cần trang bị? Những vấn đề nào được gọi là nan giải về kĩ thuật trong việc lập trình game?
2. Ngành công nghiệp game của thế giới đang phát triển như thế nào? Quy trình làm một game ra sao (từ ý tưởng đến hiện thực)? Có những role nào trong một game project?
3. Phân tích xu hướng hiện tại và tương lai của thị trường game (và game trên iPhone)?
4. Vòng đời của một sản phẩm game?
5. Các mô hình mà những nhà phát triển game đang tiến hành để thu lợi nhuận?
6. Phân chia các thể loại game và những đặc trưng kĩ thuật/ý tưởng liên quan?
7. Lập trình game trên iPhone có gì khác biệt so với các môi trường khác?
8. Các engine và công cụ nào hỗ trợ lập trình game (nói chung) và trên iPhone (nói riêng)

Tôi muốn trở thành một expert về lập trình 3D trên iPhone. Cần tiếp cận như thế nào?

Tương tự, tôi cũng sẽ đặt một vài câu hỏi để các bạn tự tìm lời giải cho mình.
1. Lập trình 3D (nói chưng) và trên iPhone (nói riêng) được ứng dụng như thế nào?
2. Những kiến thức nào về lập trình 3D cần được chuẩn bị?
3. Những điểm khó khăn/ thuận lợi trong việc lập trình 3D trên iPhone?

Tài liệu tham khảo

Tôi liệt kê một vài quyển sách được gọi là khá hay cho lập trình 3D/game (nói chung) và cả trên iPhone. Các bạn có thể tìm thấy những quyển sách này trên trang: http://gigapedia.com/ (cần đăng kí thành viên trước khi search)

+ AI for Game Developers
+ AI game wisdom
+ 3D Math Primer for Graphics and Game development
+ Game creation and career
+ Game Development and Production
+ Physic for game programmer.
+ iPhone game project
+ Unity Game Development Essentials

Thân.

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?

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.

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

Saturday, February 7, 2009 1 phản hồi

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.
Microsoft Software Architect

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!

Napoleon Hill và Cách nghĩ để thành công

Tuesday, January 27, 2009 0 phản hồi

Có nhiều quyển sách để lại ấn tượng trong tôi, nhưng ít có quyển sách nào để lại trong tôi những "ám ảnh" sâu sắc đến thế.

Cách nghĩ để thành công là quyển sách đầu tiên đưa ra triết lý của sự thành đạt - được viết ra từ vô số những câu chuyện có thật của những người vĩ đại như Edison, Henry Ford,... những con người phần lớn đi lên từ 2 bàn tay trắng và đôi khi còn bị xem là thất học. Tuy nhiên họ đã để lại những dấu ấn thành công rực rỡ và những đóng góp vĩ đại cho nhân loại. Tác giả Napoleon Hill đã dành cả cuộc đời mình để phỏng vấn những con người như thế và đã đúc kết những nguyên lý dẫn đến thành công trong một quyển sách - mà theo tôi là kim chỉ nam cho những con người luôn đặt câu hỏi cho mình: tại sao tôi chưa thành công?

Dưới đây là một số trải nghiệm của tôi từ quyển sách này
1. Biết rõ các mục tiêu trong đời đã là đi được một nữa chặng đường đến sự thành công"
2. Hãy biến mục tiêu của bạn thành nỗi ám ảnh và sự khát khao tột bực. Nỗi ám ảnh đó sẽ chi phối đến tư duy, tiềm thức của bạn để chỉ cho bạn con đường đến thành công.
3. Đừng bao giờ từ bỏ mục tiêu, bởi vì: kẻ chiến thắng không bao giờ từ bỏ. Kẻ từ bỏ sẽ không bao giờ chiến thắng
4. Đừng bao giờ lo lắng rằng khó khăn sẽ đến với mình và dù đó có là sự thật hiển nhiên thì cũng không được phép nản lòng.
5. Không người nào đạt đến những thành công vĩ đại mà không chấp nhận hy sinh
6. Để thành công cần phải có sự liên kết với những con người nhiệt huyết, có khả năng và có cùng chí hướng
7. Bạn không nhất thiết phải trở thành người xuất sắc nhất trong mọi lĩnh vực. Sức mạnh trí tuệ mà bạn có chính là kiến thức của những con người mà bạn liên kết được.
8. Kiến thức không phải là những gì bạn nên biết mà là những gì bạn cần áp dụng để đạt được mục tiêu.

Rất khó để diễn đạt những ám ảnh của tôi sau khi đọc xong "Cách nghĩ để thành công". Có thể bạn sẽ có những trải nghiệm khác với những gì tôi đã rút ra. Hãy đọc thử xem!

Đọc "Refactoring" của Martin Fowler

Tuesday, January 20, 2009 0 phản hồi

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: Improving the Design of Existing Code (Addison-Wesley Object Technology Series)


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

Tổ chức thông tin

Monday, January 19, 2009 0 phản hồi

Tôi là một người hay quên. Vì vậy tôi cố gắng tổ chức thông tin sao cho thật hiệu quả để tìm kiếm mà không cần phải nhớ quá nhiều. Có một tiêu chí tôi tự đặt ra cho mình: đối với mỗi vấn đề tôi đã từng gặp qua - khi cần thiết chỉ cần bỏ ra tối đa 5 phút để tìm lại.

Tôi chia sẻ với các bạn những công cụ mà tôi đã sử dụng (hy vọng là nó cũng hữu ích đối với các bạn)

1. Tổ chức thư mục hợp lý.

Máy tính là công cụ mà tôi sử dụng thường xuyên. Do đó tôi cố gắng tổ chức cấu trúc thư mục sao cho rõ ràng và dễ nhớ. Một cấu trúc thư mục ví dụ mà tôi đang dùng
+ Ebooks
(Phan loai ebook theo danh muc)
+ Projects
(Moi du an duoc to chuc thanh mot thu muc rieng)
+ R&D
(Nhung task research lien quan)
+ Personal
Notes (Ghi chu ca nhan)
Documents (Nhung tai lieu tu viet)
CV (CV ca nhan)
...

2. Tổ chức email cá nhân

Mỗi ngày tôi nhận được có khi gần 50 emails. Với số lượng email như vậy nếu không tổ chức/phân loại hợp lý tôi sẽ không thể nào quản lý thông tin một cách hiệu quả. Có một số cách tôi khuyên bạn nên dùng:
+ Filter những email ko cần thiết bằng cách tạo filter trên email client (Outlook, ThunderBird, ...)
+ Group email theo nhóm hoặc tổ chức thư mục để lưu trữ email. Mỗi khi đọc xong một email, tôi có thói quen kéo nó vào thư mục thích hợp (chỉ tốn maximum 5 s) nhưng khi cần tìm kiếm bạn có thể tiết kiệm được hàng phút hoặc có khi hàng giờ.

3. Tập thói quen ghi chú những thông tin quan trọng

Đối với những thông tin quan trọng như mật khẩu, tài khoản, thông tin về khách hàng, ... tôi không bao giờ lưu trữ chúng trên email hoặc archived messages. Tôi sử dụng những công cụ online dưới đây:
Google Docs: tạo những document để ghi chú những thông tin quan trọng và bảo mật. Tôi nghĩ rằng khả năng Google Docs bị sập hoặc Google phá sản thấp hơn rất nhiều so với khả năng máy tính tôi đang sử dụng bị crash.
Google Notebook: sử dụng cho các tình huống cần ghi chú nhanh.
Delicious: bookmark những link quan trọng cần nhớ + đánh tag rõ ràng để dễ tìm kiếm.
Mind map: (tôi đang dùng XMind - bạn có thể download từ xmind.net). Đây là công cụ tôi dùng để ghi chú những ý tưởng, những thông tin phức tạp về nội dung.

4. Đừng bao giờ bỏ phí bất kì lần tìm kiếm nào:

Mỗi lần tìm kiếm về một vấn đề là một lần mất thời gian. Tôi ghi nhận lại những thông tin tìm kiếm (những kết quả tốt nhất tìm được) vào một nơi. Trước đây tôi sử dụng chương trình KeyNote (chương trình này cho phép bạn lưu trữ ghi chú theo cấu trúc cây - rất hữu ích). Hiện tại đang chuyển sang dùng Google Notebook.
Mỗi lần search sẽ ghi lại các thông tin:
+ Chủ đề cần tìm kiếm
+ Những kết quả tìm được tốt nhất
+ Các hướng tìm kiếm dừng lại cuối cùng

5. Lập lịch nhắc nhở

Khi có những công việc quan trọng - tôi lập lịch biểu để nhắc nhở. Có thể sử dụng nhiều chương trình: Outlook, RemindTasks,...

Hôm trước có lần hỏi một em gái đồng nghiệp: em gửi lại cho anh danh sách những yêu cầu của Onshore PM cho đợt release này, em suy nghĩ một hồi rồi mở message archived của Yahoo để tìm lại. Buồn quá!
Hy vọng em đọc được bài viết này của anh nhé. Một chút chia sẻ hy vọng sẽ có ích cho những người bạn đồng nghiệp.

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

Saturday, January 17, 2009 0 phản hồi

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:

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