"I was browsing through Rails source code and here’s what I’ve come up with:" mà dịch thành "từ đó viết được đoạn code mô phỏng lại quá trình mã hóa này:" dịch tào lao vậy anh? là xem mã nguồn rails chứ không phải là viết được ra cái mã đó. the best rồi :v best of translater
"Để kiểm tra current_user đang logged in hay không, một developer đã viết đoạn code truy xuất thông tin dựa trên session như sau"
=> đoạn code đó là để trả về user đang login nếu có mà bạn, chứ có phải để kiểm tra current_user đang login hay chưa đâu?
Bài viết rất trực quan - thú vị, Nhưng mình có một số quan điểm như sau:
Mình sẽ luôn ghi log khi chương trình vào catch theo cú pháp logger.error("class_name - method_name: ", e);
Mặc dù như bạn nói vừa throw với vừa ghi log thì nó sẽ khiến thông báo lỗi bị lặp lại nhiều lần.
Nhưng logging dc tạo ra với mục đích là "GHI CHÉP" lại các vấn đề trong quá trình ứng dụng hoạt động. Nên nếu loại bỏ việc ghi log chẳng khác gì khai tử việc tracking chương trình cả (nguong)
Ngoài ra, tất nhiên, mình nghĩ không phải lúc nào cứ vào catch là phải throw e.
Nó tùy thuộc vào việc người phía sau có cần thiết phải nhận exception đó không.
Như vấn đề Transaction trong chương trình, vì lý do là Transaction chỉ rollback data khi và chỉ khi có exception xảy ra, nên đối với việc modifier data thì mới cần throw e, còn như select data thì mình cứ mặc định return về object hoặc collection empty...
Nên mình nghĩ, việc người lái xe nhận cục đá và cân nhắc là có cần quẳng cho thèn ngồi sau giải quyết không, hay là tự mình giải quyết cũng là việc cân nhắc đầu tiên - đó mới chính là code có trách nhiệm.
Mình nghĩ là hạn chế throw exception nếu như nó không cần thiết.
Như nhà mình hết gạo, mình biết và đi mượn gạo từ hàng xóm, hay nói với mẹ mình và mẹ mình chạy đi mượn gạo từ hàng xóm thì mình nghĩ là mình chủ động đi mượn sẽ đỡ tốn giai đoạn thông báo, vì 2 việc điều sẽ dẫn đến kết quả là phải có ng đi mượn gao thôi (yaoming)
Đó là ý kiến cá nhân của mình, đúng như bạn nói, tùy thuộc vào từng tình huống mà mình sẽ giải quyết exception hay throw exception cho ng sau. (ahihi)
Việc xây dựng kịch bản và chương trinh team building rất quan trọng, nhưng chưa thấy phần ý nghĩa của chương trình team building này. Vì mỗi công ty có những tình huống, vướng mắc khác nhau trong quá trình làm việc. Team building có thể giải quyết được những vấn đề này.
Via : https://saigonteambuilding.net
có nhiều cách bảo mật cookie: hide from javascript, enscript, set flag secure. Không hẳn là tuyệt đối, nhưng để ăn cắp và sử dụng cookie được bảo vệ bới bộ ba trên thì cũng khốn khổ đó
THẢO LUẬN
"I was browsing through Rails source code and here’s what I’ve come up with:" mà dịch thành "từ đó viết được đoạn code mô phỏng lại quá trình mã hóa này:" dịch tào lao vậy anh? là xem mã nguồn rails chứ không phải là viết được ra cái mã đó.
the best rồi :v best of translater
"Để kiểm tra current_user đang logged in hay không, một developer đã viết đoạn code truy xuất thông tin dựa trên session như sau" => đoạn code đó là để trả về user đang login nếu có mà bạn, chứ có phải để kiểm tra current_user đang login hay chưa đâu?
Mình mail cho Bạn. Bạn check mail và hy vọng có buổi off với Bạn. Cám ơn Bạn rất nhiều
Lần sau bạn để code cho anh em dễ copy nha
Anh có thể giải thích ý nghĩa của những khai báo trong file dbmanager.h và .m được không ah!!!
Bài viết rất trực quan - thú vị, Nhưng mình có một số quan điểm như sau:
Mình sẽ luôn ghi log khi chương trình vào catch theo cú pháp logger.error("class_name - method_name: ", e); Mặc dù như bạn nói vừa throw với vừa ghi log thì nó sẽ khiến thông báo lỗi bị lặp lại nhiều lần. Nhưng logging dc tạo ra với mục đích là "GHI CHÉP" lại các vấn đề trong quá trình ứng dụng hoạt động. Nên nếu loại bỏ việc ghi log chẳng khác gì khai tử việc tracking chương trình cả (nguong)
Ngoài ra, tất nhiên, mình nghĩ không phải lúc nào cứ vào catch là phải throw e. Nó tùy thuộc vào việc người phía sau có cần thiết phải nhận exception đó không.
Như vấn đề Transaction trong chương trình, vì lý do là Transaction chỉ rollback data khi và chỉ khi có exception xảy ra, nên đối với việc modifier data thì mới cần throw e, còn như select data thì mình cứ mặc định return về object hoặc collection empty...
Nên mình nghĩ, việc người lái xe nhận cục đá và cân nhắc là có cần quẳng cho thèn ngồi sau giải quyết không, hay là tự mình giải quyết cũng là việc cân nhắc đầu tiên - đó mới chính là code có trách nhiệm. Mình nghĩ là hạn chế throw exception nếu như nó không cần thiết.
Như nhà mình hết gạo, mình biết và đi mượn gạo từ hàng xóm, hay nói với mẹ mình và mẹ mình chạy đi mượn gạo từ hàng xóm thì mình nghĩ là mình chủ động đi mượn sẽ đỡ tốn giai đoạn thông báo, vì 2 việc điều sẽ dẫn đến kết quả là phải có ng đi mượn gao thôi (yaoming)
Đó là ý kiến cá nhân của mình, đúng như bạn nói, tùy thuộc vào từng tình huống mà mình sẽ giải quyết exception hay throw exception cho ng sau. (ahihi)
Việc xây dựng kịch bản và chương trinh team building rất quan trọng, nhưng chưa thấy phần ý nghĩa của chương trình team building này. Vì mỗi công ty có những tình huống, vướng mắc khác nhau trong quá trình làm việc. Team building có thể giải quyết được những vấn đề này. Via : https://saigonteambuilding.net
Cảm ơn bạn:)
Bài viết của bạn rất hay.
Hay quá. Cảm ơn bạn
Cảm ơn bạn
Test
Test
có nhiều cách bảo mật cookie: hide from javascript, enscript, set flag secure. Không hẳn là tuyệt đối, nhưng để ăn cắp và sử dụng cookie được bảo vệ bới bộ ba trên thì cũng khốn khổ đó
Thank you very much
Thank a lot!
It is really helpful
Hóng phần tiếp theo :3
=)))) có tiền đâu. viết làm gì