Có vẻ hay đó bạn

Thank bạn, bài viết hay quá.

@khoaha2 em note lại các bài cần hint ra đây anh check thử nhé

Thanks

nó có test được scope không ạ ?

@vietnguyen148 Vâng, cảm ơn bạn đã bổ sung thiếu sót cho mình.

Bạn inbox email. Wilidn2021@gmail.com . mình có việc cần thuê bạn làm cái này tí.

Mình đồng ý với bạn rằng thiết kế đẹp ngay từ đầu là một điều không tưởng, bởi chúng ta đều biết mô hình thác nước không áp dụng được với các dự án phức tạp bây giờ. Tương tự, sự phức tạp trong một hệ thống cũng không thể tránh khỏi, nhưng cần hết sức giảm thiểu nó. Theo mình, 2 nguyên nhân đầu và nguyên nhân phụ bạn đưa ra thuộc dạng tư duy chiến thuật như đã nói ở phần 1. Mục tiêu quan trọng nhất của tác giả John Ousterhout là thay đổi cách tư duy của lập trình viên khi phát triển hệ thống. Còn về nguyên nhân thứ 3. Việc quản lý hệ thống không chỉ phụ thuộc vào cách chúng ta tổ chức code, mà còn có liên quan chặt chẽ đến cách quản lý đội ngũ lập trình viên. Hiện tại có thể kể đến mô hình microservices, các services được đảm bảo "loosely coupled" theo Data driven design, mỗi service được phụ trách bởi một team nhỏ. Ở các bài viết sau sẽ trình bày các kỹ thuật để tạo ra deep modules, giảm thiểu classitis. Bạn theo dõi tiếp nhé.

Cảm ơn góp ý từ bạn. Nội dung bài viết rất trừu tượng, bởi lẽ tựa đề của cuốn sách mà mình dựa theo là Triết lý của phát triển phần mềm. Ở bài viết sau mình sẽ trình bày về các kỹ thuật cụ thể hơn, tuy nhiên vẫn không thể cụ thể như cuốn Clean code được. Cá nhân mình thấy việc trừu tượng có cái hay, vì nó có thể áp dụng được nhiều công nghệ, nhiều ngôn ngữ lập trình khác nhau. Cuối series này chắc chắn sẽ có tổng kết các lời khuyên và các red flag. Mong bạn tiếp tục theo dõi và góp ý.

Noiceeeeee

Hóng phần 2, hay quá bác ơi🙆

Anh @vigov5 ơi anh xem xét thêm hint 1 số bài lâu không có thêm bạn giải đi ạ , bí quá .

Hội chứng classitis theo mình là điều không thể tránh khỏi. Nó đến từ 3 nguyên nhân:

• Thiết kế rất trong trẻo, nhưng thực tế code phải cụ thể hóa hơn rất nhiều. Hay nói cách khác, là thiết kế quá nông.
• Trong quá trình phát triển thì cực kì thiếu con người có khả năng review và update lại thiết kế. Code thì chỉ biết tuân theo thiết kế, có gì phát sinh là đẻ ra thêm class mới, function mới, easy mà chẳng đụng chạm đến ai. Mà thiết kế thì họ ko kiểm soát được việc code nảy nở ra thêm như thế nào.
• Dự án có thể chia cho nhiều người, hoặc cắt nhỏ thành nhiều team. Mỗi team sẽ viết thêm code để phục vụ mục đích cho bên mình mà ko cần thảo luận với bên kia. Do đó chắc chắn sẽ gặp rất nhiều code thừa, code lặp, hoặc ý tưởng thì giống nhau nhưng code của mỗi team lại thêm mắm thêm muối, ko dùng chung của nhau được.
• (cái này là phụ thôi, nhưng cũng khá nghiêm trọng) Tâm lí con người luôn muốn tránh đụng chạm và bản thân mình hay team mình về đích trước. Cha chung ko ai khóc mà. Thiết kế mà đẹp ngay từ đầu thật là một điều không tưởng.

Phải chăng tác giả đang chê triết lí thiết kế của Oracle Đúng vậy, lúc mình bắt đầu học sâu hơn về Java thì thực sự rối trí bởi nó có quá nhiều lớp, chả biết dùng như thế nào là chuẩn mực. Nếu chỉ dùng Java code web api thôi thì ít đụng chạm đến vấn đề này hơn. Chứ để làm app desktop hay làm game mà ko biết vận dụng các lớp nâng cao của Java thì chương trình rất kém về hiệu suất. Thực ra mình ko chuyên backend nên nếu nói có gì sai, anh em vặn lại giùm ạ

Sau không nghi nguồn tác giả vậy bạn?? console.aws.amazon.com/console/home

• Tùy vào các loại captcha khác nhau thì cũng sẽ có các bước xử lý khác nhau để loại bỏ nhiễu. Cái này nhìn vào dữ liệu thì mình mới có thể nói được.
• Còn câu hỏi "liệu có tổng quát hóa model cho mọi loại capcha được ko" thì mình nghĩ đây vẫn là thử thách vì phần Text Recognition nhạy cảm với các loại nhiễu. Kể cả bạn đã huấn luyện trên tập ảnh có nhiễu rồi nhưng gặp nhiễu mới thì vẫn khó đọc được. Và để loại bỏ được nhiễu thì lại gặp vấn đề nhiễu rất đa dạng như bạn đã đề cập bên trên

Bạn Minh thân. Cho hỏi code để lấy chỉ số index của một e trong list? Tks

Self-host hay IIS là bước deploy rồi, còn về cơ bản công cụ trong lúc develop là VS hay VSCode thì cũng có thay đổi được đâu.

@lozthiensu thanks bạn đã dành time để đọc qua bài chia sẻ. 4 điểm bạn nêu ở trên mình có chia sẻ trong phần 2 về multitasking bạn có thể tham khảo https://viblo.asia/p/process-may-tinh-va-nhung-dieu-co-the-chua-biet-phan-ii-multitasking-ByEZkaPx5Q0. Và mình cũng xin chia sẻ ý số 2 là 1 tiến trình bao gồm nhiều thread xử lý thì việc xử lý các thread trong 1 Core(CPU) là concurrent không phải parallel. Việc xử lý parallel sẽ xảy ra khi các thread được phân bổ ra nhiều Core và việc xử lý này không dùng chung resource giữa các thread và ngược lại. mình reference từ article này nhé http://tutorials.jenkov.com/java-concurrency/concurrency-vs-parallelism.html#:~:text=It is possible to have,CPUs are executed in parallel.

Nhiễu của loại captcha này đơn giản, do đó bạn áp được threshold để loại bỏ. Với captcha có nhiều nhiễu, loại bỏ là mất ký tự thì chúng ta không được loại bỏ nhiễu.

Khi đó bạn sẽ dùng mô hình nào, cần bao nhiêu mẫu đã gán nhãn...để bypass. Liệu có tổng quát hóa model được để bypass mọi loại captcha ko.