Hi bạn, mình có một câu hỏi phản biện: Liệu có làm phức tạp lên không nhỉ, mình nghĩ dựa trên rating bằng sao(star) là có thể giải quyết được vấn đề rồi (Vì thực chất rating và comment gần như là tương đương).

https://pm2.keymetrics.io/docs/usage/startup/#saving-current-process-list

@KhoaNguyen e đang thực tập laravel ở cssoft a ạ. A vẫn làm ở chỗ cũ à a?

Cảm ơn bạn đã góp ý.

• Về nhận định này : "Facade tồn tại, không phải Mục đích của việc này giúp ta có thể sử dụng trong project của mình dưới cái tên ngắn gọn, thay vì phải viết đầy đủ namespace của chúng". Mình nghĩ mình không hề nhận định sai vì trong docs có một ghi rất rõ "Laravel facades serve as "static proxies" to underlying classes in the service container, providing the benefit of a terse, expressive syntax while maintaining more testability and flexibility than traditional static methods."

• Service Provider đúng là nơi đăng ký các binding, tuy nhiên mình không nghĩ nó là một Design Pattern và được liệt kê ngang hàng như kia, dễ gây hiểu nhầm thay vào đó có thể giới thiệu singleton chẳng hạn, như thế hợp lý hơn

• Facade tồn tại, không phải Mục đích của việc này giúp ta có thể sử dụng trong project của mình dưới cái tên ngắn gọn, thay vì phải viết đầy đủ namespace của chúng. Nhận định này hoàn toàn sai lầm. Cái đoạn bạn đang ví dụ là alias của Facade chứ ko phải bản chất Facade. Mình hoàn toàn có thể dùng \Illuminate\Support\Facades\Cache::get('key') và nói rằng mình đang dùng Facade. Vậy nó thực chất là gì? Facade là một lớp proxy giúp chúng ta có thể sử dụng các feature của Laravel như một static function mặc dù đoạn code gốc có thể chỉ là một function bình thường 😁😁 Đọc thêm về Facade tại đây nhé https://laravel.com/docs/8.x/facades#introduction

mình không hiểu câu 1 khóa phụ của bạn viết nghĩa là gì. theo mình đc biết trong sql của 2 loại khóa chính , khóa ngoại và cả 2 đều có thể có nhiều khóa.

hay quá idol (tym)

Bài viết rất hay cảm ơn chủ thead

thanks a (len)

(dance9) (deptrai2) ok a

Em chào anh! Anh cho em hỏi xíu ạ. Nếu em tạo chatbot bằng Pycharm thì sau khi tạo xong làm sao để tích hợp nó vào website của em ạ? Em không phải dân công nghệ nhưng em muốn tìm hiểu thêm, mong anh chỉ giúp em với ạ. Em xin cảm ơn.

Mình đang đau khổ khi sử dụng GatsbyJs là content ngày càng nhiều, việc đợi build là một cực hình đối với mình, nên NextJS có lẽ là một lựa chọn tiếp theo đối với mình, cảm ơn tác giả về bài viết, dễ hình dung hẵn.

Thay hết sang TypeORM đã mới có cái so sánh

tiếp tục màn bóc phốt sequelize nào (clap)

@DiepThu Ok bạn nhé

@vuongthai95 ok e làm đk r

Lấy API viết extension để down nhạc 320kbps cho dân xài chùa xài

Mình chia sẻ góc nhìn của mình như sau:

1. Các bạn PM để xảy ra chia rẽ trong nội bộ team sâu sắc kiểu phân phe nhóm thì nói thẳng ra các bạn quản lý kém rồi. Hôm nào chán muốn nghỉ việc thì bạn ad cứ nói thẳng câu này rồi nghỉ nhé. )
2. Ở những công ty tui từng làm, việc như vậy là rất hiếm. Tất nhiên đồng ý Dev thì có dev this dev that. Một PM tốt sẽ xây dựng được một team có văn hóa chấp nhận và văn hóa phản biệt. Tức là khi có vấn đề cần trao đổi, giả dụ là bug. Việc đầu tiên cần làm của 2 bên là verify thật kĩ xem có phải là bug ko, sau đó bằng lý luận để phản biện lại. Tất nhiên sẽ có những vấn đề do dev sai, QA/QC sai hoặc do BA/PO không đề cập đến trong ticket dẫn đến Bug/feature này. Khi đó văn hóa chấp nhận là cần thiết. Teammate phải tự nhìn nhận và đánh giá, nếu là sai thì "shut the fuck up and clean it". Việc ra mặt can thiệp của PM là cần thiết trong tình huống cả 2 không tìm được tiếng nói chung lúc đó cần người có kinh nghiệm, lắng nghe và phân giải.
3. Thành công của 1 dự án được đánh giá không chỉ ở tốc độ delivery 1 product tới người dùng mà còn bởi chất lượng của sản phẩm đó. Nên đội QA/QC sẽ cực kì cần thiết. Tui nhớ hồi trước từng làm ở một cty, dự án đang trên đà fail do BA handle dự án non kinh nghiệm, 2 bạn QC thì lười và hầu như thái độ làm việc như không join vào dự án. Sau đó may mắn là công ty tìm được một anh QC mới vào nghề. Tuy mới vào nghề, nhưng anh tỏ ra mình là người rất năng nổ, chăm chỉ, cực kì khiêm tốn nhưng đủ dai dẳng để theo đuổi bug mà do chính anh raise. Cuối dự án, mn đi nhậu. Sau đó 1 bạn dev trong dự án thừa nhận thành công của dự án là nhờ công của anh QC đó. Các bạn thấy đó, con người ta không cần có title để tạo sức ảnh hưởng. Và lời đánh giá đó được xuất phát từ 1 bạn dev.
4. Một góp ý nữa là đối với mình, nếu xui lỡ va phải team có văn hóa máu chó rồi thì ko nên tốn thời gian làm gì. Chẳng mấy ai đủ kiên nhẫn ngồi chờ họ thay đổi đâu. Trong khi thế giới thì rộng lớn, bạn mở trang tìm việc lên có mấy chục option cho bạn chọn. Ai cũng có quyền được lựa chọn hết.
5. QC cũng cần phải train cho mình kĩ năng giao tiếp thật tốt với dev. Vì vốn dĩ việc các bạn ấy đang làm tiếp xúc nhiều với màn hình, logic và những thứ nhức đầu khác. Tài năng của QC không phải chỉ đơn giản là tìm ra thật nhiều bug mà là tìm ra được bug, chứng minh nó là bug mà khiến dev tâm phục và vui vẻ giải quyết vấn đề. Đây là 1 bộ kĩ năng của QC theo mình là vậy. Chút góp ý mong cải thiện mối quan hệ giữa 2 role cực kì quan trọng là người xây dựng và người kiểm tra. Đôi dòng tâm sự từ PO/PM/QC.

Bài viết quá hay, tác giả dịch có tâm. Trước giờ mình không hề thích đọc tài liệu nhưng giờ mình đã bị nghiện rồi