Độ chính xác trong ví dụ này chưa cao là vì phỏng đoán xác suất tiên nghiệm chưa đúng. Xác suất tiên nghiệm ở đây là p(tiểu_đường) = p(không_tiểu_đường) = 0.5. Có vẻ không ổn. Không thể nào trong một dân số mà số người bị tiểu đường bằng với số người không bị tiểu đường cả.

Để tôn trọng tác giả thì mình nghĩ bạn dịch bài của ai thì phải ghi nguồn dịch. https://hackernoon.com/understanding-map-filter-and-reduce-in-javascript-5df1c7eee464 Trong bài gốc trên, tác giả còn ghi ra cụ thể anh ấy tham khảo từ nguồn nào.

À, còn với việc thay đổi code trực tiếp ở trait cũng không nên. Ví dụ ở trait em có hàm send email, yêu cầu phải thay đổi bằng send sms ==> em update code ở trait thì các class sử dụng nó không phải thay đổi gì. Nhưng như vậy em ko versioning được trait. Nguyên tắc open-close cũng bị vi phạm nếu em edit trực tiếp ở trait

Khác chứ em: vấn đề là thế này, trait là cái cụ thể, khi sử dụng em phải sử dụng use trait_name đúng không? Giờ em có trait1 sử dụng ở 10 class. Em muốn thay trait1 bằng trait2 ==> em sẽ phải replace ở 10 chỗ của 10 class khác nhau, vì mình ko thể binding trait được Còn với cơ chế binding và inject của interface, việc thay thế là cực kỳ đơn giản, vì chỉ thay thế ở 1 chỗ thôi. Nói chung trait chỉ giúp em đỡ phải viết 1 số hàm thôi, nhưng nó vẫn là liên kết chặt (tightly coupled) với các class .

Anh em nào chấp nhận trả phí thì có thể dùng package này nhé https://codecanyon.net/item/rv-media-laravel-media-management/20257936?rel=botble

Em vẫn chưa hiểu lắm. Theo em hiểu cách của anh là : VD như để xử dụng 1 hàm A , của 1 class B nào đó, ta tạo ra interface C rồi bind nó với class B , rồi gọi hàm A bằng cách sử dụng interface C. Nhưng giờ có traits rồi ở đâu cần dùng thì em gọi hàm của trait ra, nếu sau này muốn sửa gì thì em cũng chỉ sửa mỗi trait thôi. Em thấy nó có khác gì đâu anh.

Về bản chất, trait là ép các class sử dụng các function có sẵn của trait, không tùy biến được còn interface là định nghĩa tên và tham số của function, chứ ko có định nghĩa body của function ==> Nên 2 cái được sinh ra cho 2 mục đích khác nhau, nó ko overlap cho nhau

Bạn có thể add fb mình để mình hướng dẫn dùng tool này nhé

oh, thank bạn nhé!

Data Access Object. Nó thuộc tầng Model đó bạn. Theo như MVC thì Model làm nghiệp vụ trực tiếp cuối cùng. Ở đây DAO làm nghiệp vụ trực tiếp với database, ví dụ như chạy các câu query!

Mình đã từng thử dùng cách đưa nội dung file .properties vào $roorScope nhưng có vẻ không hợp lý, của bạn có vẻ rất hay và mình đang thử, sẽ báo kết quả cho bạn. Rất cảm ơn bạn.

Mình đang tham khảo theo link của bạn và thấy nó rất hay. Cảm ơn!

Có lẽ bạn đang nhầm lẫn một chút về khái niệm IDE và Text Editor. Về cơ bản sublimetext không khải là IDE mà nó chỉ là một Text Editor. Bạn có thể tham khảo hai khái niệm này ở đây: IDE: http://searchsoftwarequality.techtarget.com/definition/integrated-development-environment Text Editor: https://en.wikipedia.org/wiki/Text_editor

thank bạn đã quan tâm

Chao ban.Ban co the share lai sample cho minh xin duoc khong.Thanks ban

DAO là viết tắt của từ gì thế, mình đọc nhưng không hiểu

Đồng ý vs ý kiến của bác. T cảm tưởng người viết bài này cố tình gây war hoặc là kinh nghiêm chưa lên tới Solution Architect.

Cái thằng đi code dạo thì có khác đéo gì thằng thợ xây đâu. Gặp bug thì stackoverflow, gặp cái khó ko làm được thì import những cái người ta build sẵn thằnh lib rồi, search tutorial, chép vài ba dòng rồi vỗ ngực "ta sử dụng công nghệ mới". Lại còn đòi chia môn phái nữa hay sao? Bao giờ thành Solution Architect rồi hãy dám chỉ trích cả một cộng đồng Dev như thế.

Product thuần Việt thì đc buff tinh thần nhiều hơn là buff tiền )))

Hay quá ạ, trên trường em đang bắt đầu học môn này. Hy vọng các bài viết sau của anh ra sớm và có use case cụ thể ạ