Thật sự những bài của anh giúp em học được nhiều thứ mà nhiều web nước ngoài em tìm vẫn không thấy được, rất cảm ơn anh. Em có thử viết repository pattern bằng prisma, nhưng nó khác và cảm giác là khó hơn rất nhiều ạ vì ở phần "protected constructor(private readonly model: Model<T>) { this.model = model; }" của BaseRepositoryAbstract em ko biết phải đổi "Model<T>" bằng type nào ạ, em cũng có thử tìm khắp gg về repository pattern bằng prisma nhưng vẫn ko có tài liệu ạ. Mong nhận được sự giúp đỡ của anh

@nguyenduong50 Thank bạn

Có ai tự host thành công llama2 chưa nhỉ

https://www.interconnects.ai/p/llama-2-from-meta 2 bài viết cùng 1 tác giả à 😂😂

Bài viết tâm huyết quá anh, em thấy hầu hết các LLM ko tập trung sâu về mặt mô hình, kiến trúc của các opensource LLM phổ biến hiện nay đều khá đơn giản, thứ làm cho LLM mạnh là data và các huấn luyện với đống data đó.

@phanngoc123 giờ mà làm Symfony thì chơi hẳn bản 6 chứ 4 thì cũ quá rồi

mình có sử dụng ckeditor cho phần bài viết làm sao để mình có thể thêm rating star này như kiểu 1 short_code đc nhỉ vd

và ra ngoài thì nó tự nhận và in ra 7 ngôi sao Ngoài ra thì mình cũng muốn chèn thêm gallery slider vào trong bài viết đó nữa nếu bạn có rành thì sp hỗ trợ mình với nhé ! cám ơn bạn zalo mình 0363129063

Khá thực tế và bổ ích ^^

@phhuy38 vẫn dùng bác ơi, cơ mà chủ yếu để tận dụng cấu trúc database của nó, còn lại thì custom là nhiều , symfony 4 cũng ngon phết mà

Cool bro, bài viết để intro vào fuzzy search rất hay.

Như trên đã nói. Một số bài toán sử dụng Tham Lam sẽ có thể đưa ra kết quả với độ chính xác ko quá cao. Còn nếu có cách khắc phục thì những thuật toán tính hết các nhánh hay rollback nó đã ko ra đời r :>😁

@nam90nh Dưới đây là 1 vi dụ mình có viết thử, các thành phần bao gồm:

• 1 ô input với id = "abc"
• 1 ô select box với id = "location" Action:
• bạn có thể nhập giá trị bất kỳ vào ô input hoặc giá trị bất kỳ vào ô select
• tuy nhiên với đoạn code dưới thì khi nào bạn nhập xong ở ô input thì giá trị của ô select box sẽ luôn là A01 Note: ví dụ này có thể không giống 100% nhưngx gì bạn cần nhưng mà mình nghĩ đi theo cách này có thể giải quyết được vấn đê bạn đang gặp phải

const haha = document.getElementById('abc');
haha.addEventListener("focusout", () => {
    const select = document.getElementById("location");
    select.value = "A01";
})

Rất cảm ơn bạn. Cùng nhau sẻ chia quà tặng cuộc sống.

Cảm ơn bạn đã góp ý, phần này lỗi do mình ùi 😢 ban đầu mình định dùng bcrypt cho đơn giản như quên mất vấn đề max length của nó. Phần này bạn có thể dùng package node:crypto ở trên để giải quyết. Mình sẽ note lại ở bài viết và thời gian tới khi có thời gian sẽ chỉnh sửa lại dùng crypto luôn 😂

Giờ thế giới vẫn dùng ECCUBE hả các bác?

cực kì hữu ích, cảm ơn vì tâm huyết của tác giả

@NamNhiNhanh

1. Đúng rồi, không fair là đúng, vì mục đích của mình là để so sánh 2 phương pháp.
2. Mình nói là chưa thấy ai làm vậy, mình cũng chưa làm nên không có kinh nghiệm để bàn luận thêm.
3. TPS liên tục thì con nào cũng chết cả, con nào chết trước con nào chết sau thôi. Cũng tùy trường hợp, max bạn xử lý tốt 10 connection, mà bạn fixed 8 conn, thì sẽ thua cái pool max size 10 conn, pool size vẫn flexible hơn, cần ít xài ít, cần nhiều keep nhiều.
4. Câu này mình thấy không giống câu hỏi, mà chắc bạn cũng biết rồi nên mình không trả lời.

@VIIGstar2 Thanks b 😊 những vấn đề này mình đã giải thích chi tiết ở comment phía trên hết rồi. Mình hoàn toàn đồng ý với 3 ý này của bạn nhé!

@Plumpboy Bạn đọc kĩ bình luận mình có giải thích vấn đề này cho bạn Kỵ Long ở trên rồi đó 😊

@nguyentuan239

1. Đã sử dụng multipart và chunk rồi thì thường ng ta hướng đến việc gửi nhiều phần cùng lúc -> ko nên await từng phần. Theo template multipart của s3 thì mình có thể gửi các phần của file kèm với index của nó theo thứ tự. Sau khi upload hết các chunk thì gửi tín hiệu complete để BE thực hiện ghép theo index
2. Chặt chẽ hơn thì trước khi upload, cần khai báo (gọi API) request multipart upload, có timeout để BE chủ động biết những file rác/chunk rác nào có thể được clean. Khai báo tổng số phần, kích thước mỗi phần, loại dữ liệu, data hash để so sánh sau khi ghép ... rất nhiều cách để khớp thông tin server /client
3. Nếu mà lquan đến ổ đĩa đầy, thì định lưu disk, sẽ cần phải tính đến trường hợp scale nhiều bản sao service ở máy ảo, container khác nhau, ko chung disk để ghép -> anh nghĩ lưu db hơi chậm nhưng phù hợp hơn khi muốn scale