Đức hạnh của Benjamin Franklin

Nguồn: Wikipedia

Franklin đã hoàn thiện nhân cách bằng một kế hoạch gồm mười ba đức tính, mà ông đã khởi đầu theo đuổi từ tuổi 20 (năm 1726) và vẫn tiếp tục theo đuổi tới tận cuối cuộc đời. Trong tự truyện của mình (xem phần tham khảo dưới đây) ông đã liệt kê mười ba đức tính:

1. “Chừng mực. Ăn không tới chán; uống không quá nhiều.”
2. “Yên lặng. Chỉ nói những điều mang lại lợi ích cho bạn và người khác; tránh những cuộc cà kê mất thì giờ.”
3. “Trật tự. Hãy để mọi thứ của bạn đều có vị trí của chúng; hãy để mỗi phần công việc của bạn đều được thu xếp một khoảng thời gian.”
4. “Kiên định. Quyết tâm làm điều bạn phải làm; làm bằng được điều bạn quyết tâm.”
5. “Tiết kiệm. Không chi gì ngoài những thứ tốt cho bạn và người khác; ví dụ, không nên lãng phí thứ gì.”
6. “Siêng năng. Không nên bỏ phí thời gian; luôn sử dụng chúng một cách hiệu quả; bỏ mọi hành động không cần thiết.”
7. “Chân thật. Không nên lừa dối; hãy suy nghĩ một cách ngay thẳng và thành thật, và, nếu bạn nói, hãy nói điều bạn biết.”
8. “Công bằng chính trực. Không làm hại người khác, giúp đỡ người khác là bổn phận của bản thân.”
9. “Điều độ. Tránh những sự thái quá; cố chịu đựng tới mức bạn cho là đủ.”
10. “Sạch sẽ. Không nên để sự không sạch sẽ hiện diện trên thân thể, quần áo hay nơi ở của bạn.”
11. “Yên bình. Không nên quan tâm tới những điều vặt vãnh, hay những rủi ro thông thường hoặc không tránh được.”
12. “Trinh tiết. Điều tiết sinh dục, đừng để làm tổn hại thân thể của mình hoặc an ninh hay danh dự của người khác.”
13. “Khiêm tốn. Học theo Jesus và Socrates.”

Mastering Programming

Dịch từ bài viết “Mastering Programming” của tác giả Kent Beck.

Qua nhiều năm quan sát những lập trình viên bậc thầy, tôi đã nhận thấy những mô thức chung trong quy trình làm việc của họ. Qua nhiều năm huấn luyện những lập trình viên ở mức thạo nghề, tôi đã nhận thấy sự thiếu vắng những mô thức đó. Tôi đã thấy sự khác biệt (mà) khởi đầu cho những mô thức đó, có thể tạo ra.

Đây là những cách thức mà những lập trình thu được hiệu quả tốt nhất có thể từ hơn 3 tỉ giây quý báu của họ ở trên trái đất này (ý nói là thời gian trong 1 năm – lời người dịch).

Bài luận này sẽ làm bạn sáng tỏ hơn về những điều đó. Một “công nhân thạo nghề” học cách giải quyết những vấn đề lớn hơn bằng cách cùng một lúc giải quyết nhiều vấn đề hơn. Một bậc thầy học cách giải quyết những vấn đề còn lớn hơn thế bằng cách giải quyết ít vấn đề hơn cùng một lúc. Các phần của lời khuyên này sẽ được chia nhỏ sao cho việc tích hợp những giải pháp riêng biệt sẽ là một vấn đề nhỏ hơn việc chỉ giải quyết chúng đồng thời.

Thời gian

• Phân chia. Lấy một dự án lớn, cắt nó thành các phần nhỏ, và sắp xếp lại các phần sao cho phù hợp với hoàn cảnh. Tôi luôn có thể phân chia các dự án nhỏ hơn và luôn tìm thấy những cách thay đổi trật tự của các phần mà phù hợp với các nhu cầu khác nhau.
• Một việc tại một thời điểm. Chúng ta tập trung vào tính hiệu quả đến mức chúng ta giảm số lượng số vòng phản hồi (feedback cycles) trong một nỗ lực để giảm tổng chi phí. Điều này dẫn đến những tình trạng gỡ lỗi phức tạp mà chi phí của nó có thể còn lớn hơn tổng phí về số vòng phản hồi mà chúng ta đã tránh.
• Viết chương trình chạy được, chạy đúng, và chạy nhanh (Make it run, make it right, make it fast). (Ví dụ của một việc tại một thời điểm, phân chia công việc, và dễ dàng sửa đổi).
• Những sửa đổi dễ dàng. Khi bạn phải đối mặt với một sự thay đổi phức tạp, đầu tiên hãy làm cho nó dễ đi (tôi cảnh báo rằng điều này có khó), sau đó thực hiện việc sửa đổi dễ (ví dụ: phân chia công việc, làm một việc tại một thời điểm, tập trung, và sự cô lập. Đây là một ví dụ của việc phân chia công việc.
• Sự tập trung. Nếu bạn cần thay đổi một vài thành phần, đầu tiên hãy sắp xếp lại mã chương trình sao cho sự thay đổi chỉ cần xảy ra trong một thành phần.
• Sự cô lập. Nếu bạn chỉ cần thay đổi một phần của một thành tố, hãy trích xuất thành tố đó ra để thay đổi trên toàn bộ thành tố con đó.
• Quản lý các hệ thống cơ sở. Bắt đầu các dự án bằng việc so sánh với những hệ thống đã có. Điều này có thể chống lại thiên hướng muốn bắt đầu sửa chữa mọi thứ của chúng ta, nhưng khi bạn xem xét các hệ thống cơ sở, bạn sẽ thực sự biết liệu có đúng là bạn đang làm công việc sửa chữa những thứ hiện có không.

Học tập

• Trước khi thực thi chương trình, dự đoán chính xác điều gì sẽ xảy ra.
• Các giả thuyết cụ thể. Khi chương trình hoạt động không đúng, hãy minh định những gì bạn cho là sai trong chương trình trước khi thực hiện sự thay đổi. Nếu bạn có hai hay nhiều hơn các giả thuyết, hãy phân tích sự khác biệt giữa các giả thuyết đó.
• Loại bỏ chi tiết không liên quan. Khi báo cáo một lỗi, hãy tìm những bước ngắn nhất để sinh lại lỗi đó. Khi cô lập một lỗi, hãy tìm những ví dụ (test case) ngắn nhất. Khi sử dụng một API mới, bắt đầu từ những ví dụ đơn giản nhất. “Tất cả những thứ này không thành vấn đề” là một giả thuyết quá mạnh và có khi là sai lầm.
  • Ví dụ, hãy xem một lỗi trên mobile, sinh lại nó với chương trình curl.
• Đa quy mô. Di chuyển tự do giữa các quy mô (ví dụ khi thực thi trên dữ liệu nhỏ sang thực thi trên dữ liệu lớn — cách hiểu của người dịch). Có thể đây là một vấn đề thiết kế, không phải là vấn đề kiểm thử. Có thể vấn đề này liên quan đến con người chứ không phải là một vấn đề công nghệ [Lừa đảo, điều này luôn đúng].

Những thứ vượt trên cả logic

• Tính đối xứng. Những thứ gần như nhau có thể phân chia chia thành những phần giống hệt nhau và những phần khác biệt rõ ràng.
• Tính thẩm mỹ.
• Nhịp điệu. Chờ đợi cho đến thời điểm đúng bảo toàn năng lượng và tránh sự lộn xộn.
• Cân bằng (tradeoffs). Tất cả những quyết định là chủ đề của việc tradeoff. Quan trọng hơn là biết quyết định phụ thuộc vào cái gì hơn là biết câu trả lời bạn lựa chọn hôm nay (hoặc câu trả lời này bạn đã lựa chọn hôm qua).
• Danh sách niềm vui (Fun list). Khi các ý tưởng không thứ tự đến, hãy ghi chép chúng và quay trở lại làm việc nhanh chóng. Xem lại danh sách khi bạn tạm dừng.
• Chăm sóc các ý tưởng. Các ý tưởng giống như là những chú chim nhỏ dễ sợ hại. Nếu bạn doạ chúng đi, chúng sẽ dừng việc đến với bạn. Khi bạn có một ý tưởng, hãy chăm chút nó một chút. Kiểm chứng để loại bỏ chúng nhanh nhất có thể, nhưng từ dữ liệu chứ không phải là từ sự thiếu sự say mê.
• Nguyên tắc 80/15/5. Sử dụng 80% thời gian của bạn cho những công việc nguy cơ thấp hoặc những công việc được trả lương vừa phải. Sử dụng 15% thời gian của bạn cho các việc nguy cơ cao/trả lương cao có liên quan. Sử dụng 5% thời gian của bạn cho những việc làm cho bạn thích thú, không quan tâm tới kết quả. Hãy dạy những người tiếp nối bạn làm 80% công việc của bạn. Vào thời gian ai đó sẵn sàng để đảm nhận công việc, một trong số 15% thí nghiệm của bạn (hoặc ít thường xuyên hơn, một trong số 5% thí nghiệm) sẽ cho kết quả và trở thành phần 80% của bạn. Lặp lại điều đó.

Kết luận

Dòng chảy trong trong bản phác thảo này dường như bắt đầu từ việc giảm nguy cơ bằng việc quản lý thời gian đến việc chấp nhận mạo hiểm một cách có ý thức bằng cách sử dụng toàn bộ não bộ và nhanh chóng quyết định độ ưu tiên của các ý tưởng.

Thiết lập môi trường làm việc cơ bản trên Mac OS X

Mình chủ yếu làm việc trên môi trường Mac OS X. Hệ điều hành hiện tài trên máy Macbook Pro của mình là El Capitan 10.11.6. Các tác vụ cơ bản là lập trình với các ngôn ngữ mã nguồn mở như Python, Perl, Ruby, R, etc, soạn thảo trên emacs, chạy các chương trình trên Terminal, soạn thảo tài liệu với LaTeX. Bài viết này sẽ tóm tắt lại các thiết lập cơ bản để làm việc trên môi trường này các yêu cầu nêu trên.

1- Thiết lập tên máy tính

sudo scutil --set HostName logos

Tham khảo: http://bit.ly/2aoUSF5

Thay đổi tên local để tránh hiện tượng emacs khởi động chậm.

sudo scutil --set HostName logos.local

2- Thiết lập con trỏ trên Terminal

Thêm dòng sau đây vào file .bashrc

PS1='[\u@\h \w]\n$ '

Thêm dòng sau vào file .bash_profile

if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

3- Thiết lập các alias cho các lệnh hay dùng

# Xoá màn hình với lệnh cls
alias cls=clear

4- Cài đặt Git

Để cài đặt Git trên máy Mac, chỉ cần gõ lệnh git trên terminal và một hộp thoại hiện lên sẽ hướng dẫn bạn cách cài đặt (http://bit.ly/1WQ50nb)

5- Cài đặt Homebrew

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Tham khảo: http://brew.sh/

6- Cài đặt môi trường làm việc Python (với anaconda)

https://www.continuum.io/downloads

Xem thêm thiết lập môi trường Python với conda tại đây

7- Đổi lại phím tắt Ctrl-Space trên Mac OS X El Capitan

Mình hay dùng phím tắt Ctrl-Space để đánh dấu khi soạn thảo với emacs nhưng trong OS X 10.11 (El Capitan), phím tắt này được dùng để thay đổi input sources. Để đổi lại bạn vào System Preferences – Keyboard – Shortcuts; vào Spotlight, bỏ chọn Show Spotlight Search, sau đó vào lại Input sources để đổi phím tắt thành command-Space.

Tham khảo: http://stackoverflow.com/questions/32932036/change-input-source-shorcut-for-mac-os-el-capitan

Chú ý khi thay chọn mục cần thay đổi, ấn phím tab sau đó ấn tổ hợp phím muốn thay đổi.

8- Remap Ctrl-a trong GNU Screen thành Ctrl-o

Mình hay dùng emacs để soạn và Ctrl-a trong emacs được dùng để di chuyển con trỏ đến đầu mỗi dòng. Trong GNU Screen, Ctrl-a được dùng như tổ hợp phím điều khiển.

Để thay đổi, thêm dòng sau vào file ~/.screenrc

espace ^oo

Tham khảo: http://www.vineetmanohar.com/2012/02/2-ways-to-change-key-binding-in-screen/

9- Cài đặt Texmaker cho Mac OS X

Mình hay sử dụng Texmaker để soạn thảo LaTeX trên Mac OS X.

Download và cài đặt Texmaker tại đây.

10- Cài đặt môi trường soạn thảo LaTeX

Xem tại đây: http://www.howtotex.com/howto/installing-latex-on-mac-os-x/

11- Dùng phím Option (Alt) như Meta key khi dùng terminal

Mục đích: Để các key-binding trong các trình soạn thảo như Emacs/Vim hoạt động chính xác. Vào Preference/Keyboard của Terminal và chọn mục “Use Option as Meta Key”.

Cơ bản về tranh luận

Về cơ bản, trong mọi lĩnh vực của cuộc sống, con người luôn có những cách nhìn khác nhau (view point) về cùng một vấn đề. Các cuộc tranh luận thường xảy ra khi khi các quan điểm, cách nhìn rất khác nhau, thậm chí đối lập. Bài Note này nhằm mục đích tóm tắt lại những gì mình học được trên Internet về các kiến thức cơ bản về “Tranh luận”. (Debate)

1- Thế nào là tranh luận (Debate)

Về cơ bản, tranh luận là việc 2 người hoặc 2 nhóm người (có thể nhiều, nhưng thường là hai) dùng các lập luận, dẫn chứng để bảo vệ một quan điểm, cách nhìn (trong 1 vấn đề cụ thể) mà mình tin là đúng. Quan điểm, cách nhìn của hai bên thường là đối lập. Ví dụ, một bên ủng hộ cho đốt pháo trở lại, bên kia thì phản đối.

Cần phân biệt “tranh luận” với “cãi vã”. Trong cãi vã, người ta hay dùng các thủ đoạn như “chỉ trích cá nhân”, “nói to”, thậm chí “văng tục chửi bậy” thay vì đưa ra lý lẽ.

Cũng nên phân biệt giữa “tranh luận” với “thảo luận”. Một cuộc thảo luận có thể có những cuộc tranh luận nhỏ, nhưng mục đích của thảo luận thường là để hướng tới một giải pháp, ý tưởng tốt hơn. Tranh luận thì ngược lại, mục đích chính là chiến thắng, để thuyết phục người nghe (đọc) rằng quan điểm của mình là đúng, hợp lý hoặc phủ định quan điểm của đối phương.

2- Chủ đề tranh luận

Một cuộc tranh luận thường xoay quanh một quan điểm nhất định. Các chủ đề thường gặp nhất là các vấn đề xã hội. Các chủ đề tranh luận thường hay có cụm từ “có nên” (should), “A tốt hơn B”, “A hợp lý hơn B”. Trong quá trình tranh luận, có thể các chủ đề nhỏ hơn liên quan, nhưng nội dung chính của tranh luận nhất thiết phải là topic được chọn ban đầu.

Chủ đề được chọn để tranh luận nên phù hợp với độ tuổi và giáo dục của những người tham gia. Ví dụ không nên tranh luận chủ đề “Có nên hợp pháp hoá mại dâm” với trẻ em (mặc dù có ngoại lệ với một số trẻ em hiểu biết trước tuổi).

Có hai nhóm khác (sides) khác nhau với một quan điểm, chính sách: nhóm ủng hộ (AFFIRMATIVE hoặc “Chính phủ” trong các cuộc họp quốc hội), nhóm phản đối (NEGATIVE, hoặc “Đối lập”).

3- Định nghĩa chủ đề tranh luận

Trước khi tranh luận về một quan điểm nào đó, hai nhóm tham gia cần phải thống nhất với nhau về định nghĩa của các khái niệm trong chủ đề tranh luận. Định nghĩa ở đây không chỉ mang nghĩa là định nghĩa của các từ riêng lẻ trong chủ đề mà còn là toàn bộ chủ đề. Ví dụ chủ đề “Có nên cho đốt pháo trở lại” là có ý nghĩa nhưng chủ đề “Cải bắp tốt hơn hoa hồng” lại không có chút ý nghĩa gì.

Nếu hai nhóm chưa thống nhất được định nghĩa của các khái niệm trong chủ đề tranh luận, nhóm phản đối cần đưa ra ý kiến để nhóm ủng hộ làm rõ hơn để đi tới thống nhất.

4- Lập luận (argument)

• Các lập luận được đưa ra nhằm hỗ trợ cho quan điểm mà mình ủng hộ.
• Các lập luận phải có dẫn chứng và các dẫn chứng cần chính xác và có thể kiểm chứng tính chính xác một cách trực tiếp hoặc gián tiếp.

5- Cần tránh trong tranh luận

• Đả kích cá nhân/tập thể người tham gia tranh luận: Người tranh luận quá xấu xí, béo, gầy, đời tư không liên quan đến chủ đề tranh luận. Đưa ra đả kích cá nhân sẽ làm mất điểm của mình/nhóm mình trong tranh luận. Xem một số sự kiện, có thể thấy ví dụ của việc đả kích cá nhân như khai thác đời tư, quan hệ họ hàng, làng xóm, etc để hạ thấp đối tượng và làm cho người nghe/xem xao lãng chủ đề chính.
• Thiếu dẫn chứng hoặc dẫn chứng thiếu thuyết phục: Một lý lẽ đưa ra là thiếu thuyết phục nếu thiếu đi các dẫn chứng phù hợp, chính xác.
• Chỉ dựa lập luận của đối phương để đối đáp. Dẫn chứng từng lời nói của đối phương để phản đối, hoặc dựa chủ yếu vào các lập luận của đối phương là không đủ và không tốt đối với một cuộc tranh luận. Người tranh luận cần phải đưa ra được các lập luận của riêng mình để bảo vệ cho quan điểm của mình.
• Đánh tráo khái niệm: Đối phương dùng một định nghĩa khác cho khái niệm được đưa ra trong chủ đề tranh luận nhằm giành lợi thế. Gặp tình huống như thế này, cần đặt câu hỏi để làm rõ định nghĩa của khái niệm mà đối phương đề cập.
• Nhét chữ vào mồm: Đối phương gán cho mình những điều mình không nói/đề cập tới trong các lập luận của mình và dựa vào đó để phản bác.

6- Một số phương pháp tranh luận

(Mới tìm hiểu được 1 phương pháp)

Phương pháp Socrates (Socratic Method)

Sử dụng chuỗi các câu hỏi khác nhau nhằm khiến người tranh luận đồng ý với một quan điểm đối lập với quan điểm ban đầu của họ, qua đó chứng tỏ quan điểm của đối phương là sai hoặc ít nhất là thiếu chính xác. Nghệ thuật của phương pháp nằm ở trong cách đặt câu hỏi cho đối phương, tấn công vào các giả sử (assumption) mà đối phương sử dụng khi đưa ra câu trả lời, đưa ra phản ví dụ.

Tham khảo:

1. http://www.wikihow.com/Argue-Using-the-Socratic-Method
2. http://www.niu.edu/~jdye/method.html

Để công việc nghiên cứu tiến triển, điều gì là quan trọng nhất?

Dịch từ bài viết “研究を前にすすめるためには「何」が最も重要か？” đăng trên trang blog của Nakahara Lab.

Đây là câu chuyện mới xảy ra cách đây không lâu. Một sinh viên sau đại học đang bế tắc trong nghiên cứu và đã đến tham khảo ý kiến tôi. Đây là một điều khá bất ngờ với tôi, nên chủ đề câu chuyện đã phát triển như sau đây.

“Vậy thì, thưa giáo sư, để làm nghiên cứu tốt thì điều gì là quan trọng?”

“Uhm… Cái gì nhỉ (cười). Thầy cũng đang muốn được nghe đây…
Cho đến bây giờ, với người chưa từng thực sự cảm thấy cái gọi là “nghiên cứu tốt” như thầy thì cũng khó trả lời cho câu hỏi của em đấy (cười).”

Nhưng ở đây, nếu thay đổi câu hỏi đi một chút, tôi sẽ nói với các bạn còn đang băn khoăn như sau. “Nếu bạn hỏi, “để sinh viên sau đại học đạt được tiến triển trong việc nghiên cứu, điều gì là quan trọng?, thì tôi sẽ trả lời được.”

Trong các nghiên cứu ở các bậc thạc sĩ hay tiến sĩ, hơn thế nữa, trong những nghiên cứu liên quan đến lĩnh vực của tôi, nếu bạn hỏi “Để có tiến triển trong nghiên cứu, điều gì là quan trọng?” thì tôi với khoảng 10 năm kinh nghiệm hướng dẫn sinh viên ở bậc sau đại học có thể nhanh chóng đưa ra câu trả lời của riêng mình.

Trong địa hạt học thuật, tất cả đều bình đẳng, quyền lực chính trị cũng không thể chi phối

Trong địa hạt học thuật, tất cả đều bình đẳng, quyền lực chính trị cũng không thể chi phối.

Đây là điều mình rút ra sau khi đọc một bài báo trên báo Sankei (tin cũ từ năm 2015). Có lẽ đây là một phương châm hơi bị lý tưởng hoá, nhưng mình nghĩ cần hướng tới.

—————————

Nội dung của tin xoay quanh sự kiện luận văn thạc sỹ của thị trưởng thành phố Shimonoseki (tỉnh Yamaguchi) bị hội đồng giáo sư của khoa kinh tế của trường đại học “Shimonoseki City University” đánh trượt. (trường ĐH này do thành phố lập ra).

Ông thị trưởng không đồng ý với kết luận của hội đồng giáo sư và đòi công khai thông tin về quá trình đánh giá luận văn, trong khi hiệu trưởng của trường ĐH nói rằng họ chỉ làm theo quy định của trường.

Đề tài luận văn thạc sỹ của ông thị trưởng là về sự phân quyền ở địa phương. Luận văn của ông dài 550 trang A4 (quá khủng khiếp đối với một luận văn thạc sỹ), trong đó ông viết cả về kinh nghiệm làm việc thực tiễn và nhân sinh quan của ông.

Thị trưởng rất tự tin về luận văn của mình nhưng khi luận văn được đưa ra hội đồng giáo sư (gồm 33 người), luận văn đã bị đánh trượt vì không được tối thiểu 2/3 số thành viên trong hội đồng thông qua.

Thị trưởng rất bực bội vì ông cho rằng luận văn của ông bị đánh trượt chủ yếu vì lối viết của nó quá khác biệt so với các luận văn thông thường chứ không phải vì nội dung của nó.

Hiệu trưởng ĐH Shimonoseki mặc dù rất bối rối vì bị người đứng đầu của thành phố chỉ trích nhưng vẫn kiên quyết giữ lập trường của mình.

http://www.sankei.com/politics/news/150310/plt1503100036-n1.html

Cách trình bày báo cáo khoa học

Dịch từ bài viết “Giving a technical presentation (giving a scientific talk)” của giáo sư Michael Ernst, khoa khoa học máy tính, đại học Washington.

Mở đầu

(Bạn có thể đọc thêm các lời khuyên của tôi về thuyết trình khi ứng tuyển công việc và cách làm poster).

Có rất nhiều tài liệu tham khảo tốt liên quan đến cách thuyết trình hiệu quả. Ở đây, thuyết trình mang ý nghĩa là một bài thuyết trình về kết quả nghiên cứu khoa học, có thể là ở một hội nghị, cho nhóm nghiên cứu của bạn, hoặc thuyết trình với tư cách diễn giả khách mời ở trường đại học hay lab nghiên cứu khác. Bài viết này không thể thay thế những tài liệu tham khảo đó, nhưng nó sẽ ghi lại vắn tắt một vài vấn đề tôi rất thường xuyên nhìn thấy ở các buổi thuyết trình.