Cách trên lằng nhằng, tốn mất O(nlogn) thời gian xử lý, nếu có set thì tốn thêm O(n) nữa, n = len(string)

Mình có cách khác tối ưu hơn, mã Pseudocode

first, second = INT_MIN
if len(arr) < 2
  print "Not found max two"

for element in arr
  if element > first
    second = first
    first = element
  elseif element > second && element != first
    second = element

if second = INT_MIN
  print "There's no second largest element"
else
  print "The second largest element is", second

Hi ad, e đang sử dụng bulljs nên lưu các job trong redis và e có set ttl cho job là 7 ngày (lưu để monitor và debug). Mỗi ngày có 100k job chạy thì sau 7 ngày redis phải xoá gần 100k key hết hạn và ngày chồng ngày thì lượng key hết hạn càng tăng vậy có cách nào giúp redis xoá key hết hạn tốt k a.

Đúng rồi bạn, thứ nhất là họ không có release reward model, cái này tạo ra rất tốn kém và có ý nghĩa với họ. Thứ hai là bản thân RLHF cũng là một kĩ thuật mới và rất khó training, đòi hỏi nhiều chuyên gia của họ nên với người thường như chúng ta chỉ nên tiếp cận theo SFT hoặc Prompting thôi.

@Honganh https://colab.research.google.com/drive/1AAvSdaQax8fxNEQsiUn_zFV_1RpmwOB4?usp=sharing hay là bạn xem thử code giúp mình vs

SASS là thư viện CSS nó đâu liên quan gì tới Cloud và BigData đâu nhỉ

@monmen Dạ để em thử, em cám ơn bác nhé!

@AnhTuan92NA tách mỗi lần gọi api chỉ gọi 500 đến 1000 user thôi, xong query token ra call firebase lại tách batch 500 tiếp.

@monmen Dạ, nếu vậy thì " Còn bắn noti chủ động cho 1 tập hợp user thì làm cái api truyền list uid + noti để thằng noti tạo xong query token gửi thông báo thôi" nếu hệ thống sau có nhiều user và có query ra 1000 (uid) thì qua bên notification service phải query in 1000 uid này để lấy ra token thì có bất hợp lý không ạ. Hiện tại hệ thống của bên em đang làm chính là bằng django + postgres mà em đang tách notification service ra 1 con mới làm bằng django + mongo và trong con mongo này em có lưu bảng token store gồm: uid, token, os, os_name... và bảng notification gồm: key, type subjects, subject_count, di_object, in_object, pr_object theo bài hướng dẫn của bác (https://viblo.asia/p/bi-thuat-xu-ly-ngu-phap-notification-nhu-facebook-m2vJPwxo4eK) ạ. Mong bác hướng dẫn em thêm flow phần này ạ. Em cám ơn!

cách trên đúng nhưng không dùng được cho string nhe 😁

@tuelam0810 Mình sẽ hiểu vấn đề của b là setup phần ingress cho k8s, cái này sẽ tùy thuộc vào mô hình cluster của b, nếu nằm trên cloud như AWS thì sẽ setup ingress vs ALB or NLB. Còn ở on-premise, cluster nằm ở local đi network qua 2 gateway thì mình sẽ dùng mấy service proxy như HAproxy. Public argocd khá đơn giản, trong file helm của argocd b enable phần ingress đặt tên host với secretname là ssl domain của b là xog

đây bạn

Nếu em xài implement trên bài thì .SetActive(false), mà code này a implement idea thôi à, không nên xài cho production.

thích bài viết thì notification service lắng nghe event để tạo noti chứ không gọi api sang để bắn. Còn bắn noti chủ động cho 1 tập hợp user thì làm cái api truyền list uid + noti để thằng noti tạo xong query token gửi thông báo thôi

@TuannAnhh ý của em là k8s cluster có cài nginx ingress và argocd sẽ được public ra ngoài bằng nginx ingress ạ

@ThinhDA có thể do option --watch của nestjs bị lỗi, bạn thử xóa image build lại sau đó start lại xem sao

Bài viết chất lượng quá, bác Minh Momen cho em hỏi ở service nội bộ nếu phát sinh vd là thích bài viết thì sẽ bắn api sang bên service notification đúng không bác, đấy là trường hợp phát sinh một yêu cầu, còn giả sử trong admin có phần quản lý bắn thông báo đến 1 tập hợp nhiều user thì em đang nghĩ ra 2 kiểu:

• 1 là lặp và bắn từng api kèm theo thông tin user sang service notification
• 2 là bắn 1 tập hợp user sang service notification và sang đó thì query theo mảng user_id để lấy token thông báo và thực hiện gửi thông báo

Bác cho em hỏi là luồng chỗ này như thế nào để tối ưu ạ, em cám ơn!

@zeros lạ nhỉ mình test đều không sao

@Honganh đúng r ạ , mình nghĩ vấn đề ko phải do 2 tham số đấy , tại khi mình đổi nhiều tham số khác thì ảnh sau khi xử lý nó cũng bị tương tự như hình trên

Không liên quan lắm nhưng e đọc bài của anh Tuấn thấy dễ hiểu em cũng theo dõi anh này khá lâu thấy anh hay viết mấy cái đơn giản cho sv tụi em.

Về bình luận của anh @nqh.d3v thì e có nhiều chỗ không hiểu ví dụ như anh bảo là:

Nếu single-thread powerful đến vậy, vậy thì tại sao đến bây giờ vẫn còn nhiều trang web sử dụng multi-thread? .... Em thấy anh tuấn cũng có viết phần điểm yếu của nó t@nqh.d3v

Với mấy cái ví dụ hài hước thì e thấy giễ hiểu hơn thầy trên trường em cứ XXYY mệt có lúc ko hiểu... Mà anh T cũng có câu chú ý như bên dưới cho mọi người rồi mà:

@nqh.d3v E thấy comment của a có nhiều cái khá hay về Nodejs -> hóng bài viết của anh trong tương lai.

@zeros bạn dùng tham số ntn nhé MAX_FEATURES = 1500 GOOD_MATCH_PERCENT = 0.15. bạn set theo này à