Review & Đánh giá một bài báo khoa học

Với tư cách là một referee, bạn cần đánh giá 1 bài báo theo các tiêu chí sau:

* Tính mới (novelty)
* Độ quan trọng (significance)
* Tính đúng (correctness)
* Cách trình bày (readability)

Các câu hỏi quan trọng khi đánh giá một bài báo:

1- Mục đích của bài báo là gì?

  + Vấn đề bài báo giải quyết là gì?
  + Tác giả có phát biểu vấn đề một cách rõ ràng hay không?
  + Tác giả có làm rõ các issues quan trọng hay không?
  + Tác giả có nêu rõ các contribution của mình hay không

2- Bài báo có phù hợp hay không?

Bài báo có phù hợp với hội nghị/journal không?

3- Mục tiêu (goal) của bài báo có quan trọng hay không?

  + Vấn đề đặt ra có thực hay không?
  + Ai quan tâm? (Who care)
  + Vấn đề có quá specific hay applied hay không?
  + Vấn đề, mục đích, kết quả có thực sự mới hay không?
      * Có bài báo nào đã làm giống như vậy không?
      * Vấn đề đã được giải quyết trước đó chưa?
      * Bài báo có phải chỉ là một biến thế hay mở rộng đơn giản của các kết quả trước đó?
      * Tác giả có trích dẫn các kết quả liên quan và phân biệt rõ đâu là kết quả của mình, đâu là kết quả đã được thực hiện trước đó hay không?

4- Phương pháp hay cách tiếp cận có đúng đắn hay không?

  + Liệu có chỗ nào trong cách tiếp cận không phù hợp (hoặc đối lập) với kết quả hay không?
  + Liệu có thể phát biểu bằng lời phương pháp của tác giả là gì hay không?
  + Giả thiết là gì (assumption)? Nó có thực tế hay không?
  + Nếu nó không thực tế, nó có ảnh hưởng gì tới kết quả? Kết quả có dễ bị ảnh hưởng bởi giả thiết hay không?
  + Cách tiếp cận có đầy đủ đối với mục đích hay không?
  + Nếu bài báo trình bày 1 ý tưởng mới, tác giả có thảo luận hay phân tích đầy đủ hay không?

5- Nghiên cứu/kết quả có đúng đắn hay không?

   + Các phương trình toán học, mô hình toán học có đúng đắn hay không?
   + Các chứng minh có thuyết phục không?
   + Các thống kê có đúng không?
   + Các phương pháp mô phỏng, làm thí nghiệm có thuyết phục bạn rằng kết quả đưa ra là đúng?
   + Đối với các nghiên cứu về thống kê, tác giả có đưa ra confidence interval hay không?
   + Kết quả có thống nhất với các giả thiết hoặc các quan sát (facts) và đo đạc không?
   + Các điều kiện biên có được kiểm tra hay không?
   + Kết quả có thể xảy ra hay không?
   + Tác giả có làm những gì họ claim hay không? Ví dụ, tác giả có mô phỏng hệ ban đầu bằng 1 mô hình hợp lý hay chỉ xấp xỉ bẳng các mô hình toán học?

6- Các kết luận đưa ra có đúng đắn/phù hợp với kết quả hay không?

   + Ứng dụng hoặc ngụ ý (implications) của kết quả là gì?
   + Tác giả có thảo luận một cách hợp lý tại sao anh ta lại thu được các kết quả đó hay không?

7- Bài báo có được trình bày tốt hay không?

   + Bài báo có được viết đủ tốt để bạn đánh giá các nội dung kỹ thuật hay không (technical content)
   + Một bài báo viết khó hiểu không đáng được publish.
   + Một bài báo cần phải sửa nhiều không đáng được đăng
   + Nếu bài báo đọc được, bạn cần đánh giá cả về trình bày lẫn nội dung của nó.
   + Phần tóm tắt có mô tả đúng nội dung bài báo hay không?
   + Phần introduction có mô tả đúng vấn đề và research framework hay không?
   + Các phần khác có clear và tuân thủ trình tự logic hay không?
   + Liệu có quá ít hay quá nhiều các chi tiết kỹ thuật hay không?
   + Ngữ pháp và cú pháp có đúng không?
   + Các bảng biểu, hình vẽ có được label đúng, phù hợp và có ý nghĩa hay không?
   + Có quá nhiều hay quá ít bảng biểu hình vẽ?
   + Các giải thích có poor hoặc nonsense hay không?
   + Tác giả viết quá dài dòng hoặc quá ngắn gọn?
   + Liệu bài báo có self-contained để người trong ngành có thể hiểu được hay không, hay độc giả cần các kiến thức chi tiết khác ở các kết quả, bài báo khác?
   + Nếu tác giả có refer người đọc tới các bài báo khác có các chi tiết quan trọng? Bạn có tin anh ta không hay cần phải check bài báo gốc?
   + Style của bài báo có quá suồng sã hay quá formal?
   + Liệu có quá nhiều lỗi typo hay không?
   + Paper có quá dài không?
   + Liệu paper có nên chia ra thành nhiều paper nhỏ mà không mất đi tính logic?
   + Liệu paper có quá nhiều lỗi chính tả, ngữ pháp hoặc dấu câu? Bạn cần chỉ ra các lỗi đó cho tác giả.

8- Bạn học được gì từ bài báo?

   + Bạn đã học được, hay độc giả có thể học được gì từ bài báo?
   + Nếu bạn không học được gì hoặc độc giả mà nó hướng tới không học được gì, bài báo không nên được đăng.
————–

What should be included in a review

Writing a one-page summary of the paper. You should use 10-point font and standard margins. Two-column format is acceptable. In this summary you should describe:

  • What problem is this paper trying to address? Why is the problem important?
  • What are the key ideas proposed in the paper, and why are they novel?
  • How are the ideas evaluated? Is the evaluation fair/appropriate?
  • Do you think the paper will have high impact? Did you like the paper?

The review should consist of:

  • Short para on any of the following points: What do you feel the main contribution of this paper is? What did you find interesting about this work? What’s the essential principle that the paper exploits?
  • One major strength of the paper (one sentence)
  • One weakness of this paper (one sentence)
  • One question or future work direction you think should be followed.

References

  1. The task of the referee: https://www.cs.utexas.edu/users/mckinley/notes/reviewing-smith.pdf
  2. How to Review a Scientific Paper: http://www.bcl.hamilton.ie/~barak/how-to-review.html

23 cách để chống lại sự trì hoãn

Trích từ cuốn sách ” Ngay bây giờ hoặc không bao giờ”, tác giả S.J.Scott

  1. Sử dụng quy tắc 80/20 để xác định những nhiệm vụ quan trọng
  2. Liên hệ mọi hành động đến mục tiêu S.M.A.R.T
  3. Nắm bắt ý tưởng mỗi khi chúng xuất hiện
  4. Tạo ra hệ thống 43 thư mục tại nhà bạn để xử lý công việc giấy tờ
  5. Tạo ra danh sách cho mọi dự án cần nhiều bước thực hiện
  6. Tạo ra danh sách những bước cần làm cho những công việc thực hiện hằng ngày
  7. Ghép những nhiệm vụ tương tự vào với nhau
  8. Thực hiện từng quy trình và từng dự án một
  9. Mỗi tuần hãy dành ra vài giờ làm đánh giá
  10. Hãy thực hiện đánh giá tháng để kiểm tra cặn kẽ các hoạt động của bạn
  11. Nói “không” với các hoạt động có mức độ ưu tiên thấp
  12. Theo dõi tiến độ và thành công của bạn
  13. Bắt đầu ngày mới với những công việc quan trọng nhất
  14. Chọn ưu tiên bằng phương pháp ABCDE
  15. Tạo ra một cảm giác về sự cần thiết bằng kỹ thuật khối thời gian
  16. Chịu trách nhiệm một cách công khai đối với các mục tiêu của bạn
  17. Bắt đầu một thói quen mới từ những việc vô cùng nhỏ
  18. Tưởng thưởng bản thân khi đạt đến một cột mốc nào đó
  19. Phát triển một kỹ năng dùng cho dự án
  20. Tạo động lực phụ bằng cách nghe các chương trình truyền cảm hứng (ví dụ trên TED Talks)
  21. Thực hiện kỹ thuật tưởng tượng khi bạn cảm thấy chán nản
  22. Hãy kiên nhẫn với quá trình cải thiện cuộc sống của bạn
  23. Tham gia thử thách 30 ngày để thay đổi từng thói quen một

Check-list vào cuối ngày/tuần/tháng

  1. Mình đã hoàn thành, đạt được những gì trong ngày làm việc?
  2. Những gì mình còn chưa hoàn thành trong kế hoạch đặt ra?
  3. Những ý tưởng hay nào mình đã nghĩ ra, thử suy nghĩ sâu sắc hơn xem sao?
  4. Những bài học/kinh nghiệm nào mình đã rút ra trong ngày?
  5. Mình đã học thêm được kiến thức/tri thức gì trong ngày/tuần/tháng?
  6. Sự kiện gì là quan trọng đối với mình trong ngày/tuần/tháng?
  7. Mình đã sử dụng thời gian như thế nào trong ngày? Sử dụng như vậy đã hợp lý chưa? Mình đã lãng phí thời gian ra sao? Có thể khắc phục được không?
  8. Những gì mình làm có quan trọng, giúp mình tới gần hơn GOAL đặt ra hay không?
  9. Review lại short-term và long-term GOAL.
  10. Check lại to-do list cho ngày hôm sau/thời gian tới? Timeline,…

Đứ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.”

Continue reading

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.

Để 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. Continue reading

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ệccá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. Continue reading