@tnanhpt hi bạn,

đây là demo project ở đó mình đã setup pipeline có cache cả node_modules và cả docker image: https://gitlab.com/maitrungduc1410/gitlab-ci-docker.

Bạn xem job build docker image gần nhất của mình ở đây: https://gitlab.com/maitrungduc1410/gitlab-ci-docker/-/jobs/1176509961, ở đó nó pull image về nếu trước đó đã build để làm cache, sau đó build image mới với --cache-from thì toàn bộ dùng cache hết.

(Job docker trước đó thì ko đc cache docker image nên nó phải build image từ đầu: https://gitlab.com/maitrungduc1410/gitlab-ci-docker/-/jobs/1176449579)

f8 người mới học dễ hiểu hơn, còn mấy kênh kia chủ yếu phải có ít kiến thức

Tất nhiên là có cho vào đẹp CV, giúp bạn qua vòng hồ sơ, còn chính vẫn là kiến thức lúc phỏng vấn

Những chứng chỉ trên Coursera có giúp ích nhiều trong việc tìm kiếm việc làm không bạn ?

cảm ơn anh đã chia sẻ

@phan.van.nhat em cam on anh nhieu a

Trường hợp mình test Sampler là HTTP Request và server name là localhost thì có cấu hình gì thêm không bạn? Mình chạy mà cứ trả về 404 Not Found. Nhưng link test chạy trên trình duyệt thì được.

Trường hợp mình test Sampler là HTTP Request và server name là localhost thì có cấu hình gì thêm không bạn? Mình chạy mà cứ trả về 404 Not Found. Nhưng link test chạy trên trình duyệt thì được.

A ơi tham số alpha có ý nghĩa j vậy ạ?

@hoangtq160798 Haiz, cái mình muốn nói là đánh giá khi chạy nhiều lần và đang bàn lượng dữ liệu như ví dụ. Khi chạy 1 lần cách tạo Set tốt hơn, mảng lớn thì Set cũng tốt hơn. Tại sao? Vì giai đoạn check key có hay chưa nó rất nhanh và nó bù lại cho khoảng thời gian tạo Set, thời gian cấp phát bộ nhớ. Vậy khi đánh giá lựa chọn một cách nào đó thì ta cần cân nhắc cái gì? Ý mình là tránh nhận xét cách tạo Set là hay nhất như trong bài viết, mà cần coi ngữ cảnh chạy nhiều hay ít, data nhiều không, cần tối ưu bộ nhớ hay cpu vì RAM và CPU thường phải đánh đổi... ứng với mỗi ngữ cảnh mà chọn cách phù hợp, tránh nhớ đúng một cách và làm một cách máy móc. Phần mình up là muốn nói tác dụng ngoài của Set khi chạy nhiều lần, chi phí tạo Set nó bị tăng nhanh theo số lần lặp và ăn luôn lợi thế check key, không câu nào mình bác bỏ nó. Như vậy mình có thể tóm tắt thế này:

• Chạy ít lần, data nhiều hoặc ít: nên dùng Set (chấp nhận tốn thêm RAM khi data nhiều, vì hàng triệu thì dùng loop có O(N2) là không khả thi)
• Chạy nhiều lần, data ít: nên dùng loop
• Chạy nhiều lần, data nhiều: chưa rõ nên dùng cái nào, có time thì nghiên cứu thêm thuật toán khác.

Good chóp

thấy F8 đầu tư bài bản nhất, hay và dễ hiểu

@npham đúng rồi. Bản chất của việc xác thực người dùng bằng JWT, chính là việc access token liên tục được gửi kèm theo mỗi request. Vậy nên mỗi request đều phải được kiểm tra để chắc chắn rằng người dùng gửi request đó vẫn còn khả năng truy cập.

Nhưng đúng, bạn có thể cho token auto renew trước khi thời gian hết hạn. Nghĩa là mỗi khi bạn gửi 1 request, bạn chấp nhận phải kiểm tra xem đã gần đến thời gian access token hết hạn chưa. Nếu chưa, thì không gửi refresh token, nếu gần đến thời gian hết hạn (cái này bạn tự định nghĩa) thì sẽ tự động gửi request nhận token mới, như vậy bạn có thể chủ động việc refesh token. Và người dùng không phải chờ đợi nếu token thật sự hết hạn. Nhưng người dùng vẫn phải chờ. Nếu bạn có sử dụng facebook token, mấy cái auto like hay auto comment, bạn sẽ biết rằng, facebook set hạn token là 4h. Bạn có thể test xem

@tran.thi.hong cám ơn bạn chia sẻ thông tin, những tóm tắt của bạn rất dễ hiểu. Có thể thì tiếp tục phần 2 bạn nhé!

@tinhtn89 )

4 năm rồi nhưng vẫn hóng, mong anh ra tiếp phần mới.

Mình thuộc trường phái clean code, nên viết cái nào cho rõ ràng, dễ hiểu nhất, ai đọc vào cũng hiểu code làm gì, performance thì từ từ tính sau Chứ code cho cao siêu vào, hoặc viết hằm bà lằng tỏ ra cao thủ, hoặc viết code cụt ngủn kèm 7x7 49 cái comment để người đọc khỏi wtf thì mình thấy cũng không được :v

@HuyDQ thanks bro !

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