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

quá tuyệt vời

Tks bạn

@chinn học tập nha bạn )))

Tuyệt vời anh ơi

(thankyou)

Yeah mong bạn viết bài chia sẻ vào các moudle trong source vào cấu trúc dự án. Thanks bạn nhé

hay quá , cảm ơn anh đã chia sẻ bài viết . Hy vọng anh sẽ thường xuyên ra những bài viết chi tiết như này

Bài viết hữu ích. +1 like cho bác

cảm ơn em nhá, công việc dạo này vẫn ổn chứ em ơi

@nhantam bạn xem function JSON_CONTAINS nhé