Bài viết hay quá, ước được làm cùng team để được học hỏi thêm ạ

hay quá ạ, update thêm thôi nào tác giả ơi

Bài viết không có chiều sâu

Cách này cũng khá hay, tuy nhiên sẽ có vấn đề ở đây là với mỗi request như GET thì nó sẽ phải call ít nhất 2 lần. Do bất đồng bộ ở useSession mỗi lần F5:

• Ở request đầu tiên chắc chắn là nó sẽ không đợi thằng useSession fetch xong data của nó mà sẽ bay thẳng vào Api không có bất kì config nào từ interceptor.
• Khi useSession call xong thì sẽ tác động vào useEffect, từ lúc này các request sau đó mới được config gắn vào header hoặc xử lý error các thứ

cách đăng kí thi ở đâu vậy bạn ơi

Hi anh, em có thắc mắc là khi sử dụng ingress để send traffic đến các Pods trong Service. Nếu trường hợp số lượng replicas của pod lớn hơn 1, thì lúc đó traffic sẽ được gửi đến các pods như thế nào ạ ? Em cảm ơn

Nhiều nguồn tài liệu hiện nay thì vẫn khẳng định rằng batch norm có thể khắc phục được covariate shift. Trong bài báo "How Does Batch Normalization Help Optimization?" được nêu trên bài viết có đề cập đến vấn đề covariate shift không có sự kết nối với hiệu suất huấn luyện chứ bài báo không khẳng định rằng batch norm khắc phục covariate shift là sai. Mong tác giả xem xét lại chi tiết này và cho mình câu trả lời ạ, mình xin cảm ơn

Thế dường như mỗi ngôn ngữ, ứng dụng phải sử dụng một thư viện test khác nhau

hiển nhiên rồi e , mục đích của series này là tập trung vào Docker là chính, các ví dụ a lấy từ nhiều ngôn ngữ khác nhau, ko đi cụ thể vào từng ngôn ngữ có gì, e xem và áp dụng vào case của mình.

Python e có thể xem qua Pytest nhé

Hmm...Thế dường như mỗi ngôn ngữ, ứng dụng phải sử dụng một thư viện test khác nhau (jest chỉ dùng cho js,...), đối với python thì thường sử dụng những thư viện nào anh nhỉ?

Hay. Ngắn gọn xúc tích.

:v cảm ơn em nhé. chúc em năm mới sức khoẻ và thành công

đúng r, cảm ơn b nhé, code mà k chạy là bug ngày

diffusion là Khuếch tán, Khuyến tán chắc sai chính tả rồi

// initiate new ram and replace the current one var newRam = new Ram("Kingston", "64GB"); iPhone.printSpecification(); Đoạn này đang thiếu phần set lại ram mới cho smartPhone phải không chủ thớt

cám ơn a đã theo dõi

chúc e năm mới nhiều bình an và thành công

Chúc mừng anh ạ!! Chúc anh thật nhiều sức khỏe, thuận lợi trong công việc và luôn yêu đời. Đọc bài viết của anh giúp em có thêm động lực để phấn đấu hơn!! Cảm ơn anh đã chia sẻ♥️

Oh nice catch e ơi

Trước giờ a toàn chạy trên VPS Ubuntu nên chỉ cài docker engine, và khi deploy cũng vậy, lên k8s cũng thế

Nên behaviour nó khá là ổn định

Giờ thì a đã hiểu tại sao trên Mac (Docker desktop) của a nó cũng xêm xêm như trên ubuntu rồi

Cảm ơn bạn nhé. Cảm ơn bạn đã đặt câu hỏi. Mình xin giải thích bằng 2 ví dụ khác như sau:

DIP và OCP

Cả Nguyên Lý Đảo Ngược Phụ Thuộc (DIP) và Nguyên Lý Đóng/Mở (OCP) đều đóng vai trò quan trọng trong việc tạo ra mã nguồn linh hoạt và dễ bảo trì. Tuy nhiên, mỗi nguyên lý lại có điểm nhấn riêng biệt và cách thức áp dụng khác nhau.

Để làm rõ hơn sự khác biệt giữa Nguyên Lý Đóng/Mở (OCP) và Nguyên Lý Đảo Ngược Phụ Thuộc (DIP), chúng ta cùng xem xét kỹ hơn thông qua hai ví dụ cụ thể, mỗi nguyên lý một, trong bối cảnh phát triển ứng dụng với React.

1. Nguyên Lý Đóng/Mở (OCP)

OCP nhấn mạnh việc thiết kế components và modules sao cho chúng có thể dễ dàng mở rộng mà không cần sửa đổi code hiện tại.

Ví dụ về OCP:

Xét component Button ban đầu:

const Button = ({ type, onClick }) => {
  if (type === "save") {
    return <button className="save" onClick={onClick}>Save</button>;
  }
  if (type === "cancel") {
    return <button className="cancel" onClick={onClick}>Cancel</button>;
  }
  // Thêm nhiều điều kiện cho các loại button khác...
};

Component này không tuân thủ OCP vì mỗi khi bạn cần một loại nút mới, bạn phải sửa đổi Button để thêm một điều kiện mới.

Để tuân thủ OCP, bạn có thể tái cấu trúc như sau:

const Button = ({ className, onClick, children }) => (
  <button className={className} onClick={onClick}>
    {children}
  </button>
);

Sau đó, sử dụng Button để tạo các nút mở rộng mà không cần sửa đổi Button gốc:

const SaveButton = ({ onClick }) => <Button className="save" onClick={onClick}>Save</Button>;
const CancelButton = ({ onClick }) => <Button className="cancel" onClick={onClick}>Cancel</Button>;

Ở đây, Button được thiết kế để dễ dàng mở rộng (thêm SaveButton, CancelButton), mà không cần sửa đổi code của chính nó.

2. Nguyên Lý Đảo Ngược Phụ Thuộc (DIP)

DIP nhấn mạnh việc thiết kế các module sao cho module cấp cao không phụ thuộc trực tiếp vào module cấp thấp, mà cả hai đều phụ thuộc vào abstractions.

Ví dụ về DIP:

Giả sử bạn có một component form đơn giản:

// Component form không tuân thủ DIP
const UserForm = ({ saveUser }) => {
  const handleSubmit = (event) => {
    event.preventDefault();
    // Xử lý và gọi saveUser
  };

  return <form onSubmit={handleSubmit}>...</form>;
};

Ở đây, UserForm phụ thuộc trực tiếp vào hàm saveUser, một logic cụ thể. Điều này khiến UserForm khó tái sử dụng với các hành động khác.

Để áp dụng DIP, bạn có thể thiết kế lại như sau:

// Component form tuân thủ DIP
const UserForm = ({ onSubmit }) => {
  return <form onSubmit={onSubmit}>...</form>;
};

UserForm giờ đây chỉ phụ thuộc vào một abstraction (onSubmit), không còn phụ thuộc trực tiếp vào hành động cụ thể nào, giúp nó dễ dàng tái sử dụng với các hành động khác nhau:

<UserForm onSubmit={handleSaveUser} />
<UserForm onSubmit={handleUpdateUser} />

Chốt lại:

Hy vọng qua sự so sánh này, bạn có thể rõ ràng phân biệt được hai nguyên lý này và áp dụng chúng một cách hiệu quả trong dự án React của mình.

Chào a, chắc a cũng thấy avt e quen quen :V. Bài này trước đó thực ra e đã đọc rồi và có thực hành theo a nên cũng hiểu kha khá (vì lúc đó e cũng hơi non nên chưa ngấm được hết kiến thức của a viết ra :V). Nhung vì thời gian dài vừa rồi ko có động đến docker nên cũng ko có nhớ được chuẩn. Đợt này e có quay lại docker và như đã nói thì e đã chuyển sang docker-desktop để cho tiện việc học và thực hành hơn. Nhưng cuối cùng sau khá nhiều lần chạy thử thì e đã nhận ra là behaviour của docker engine và docker desktop đổi với owner của file hay directory là khác nhau. Cụ thể: Nếu như những ngày trước e có sử dụng docker engine hay vừa rồi e có switch docker context từ docker desktop về docker engine thì tất cả những điều a viết trong bài đều dúng. Còn nếu sử dụng docker desktop (đã tích hợp sẵn docker engine của nó và các service cần thiết khác nữa ) thì rất nhiều thứ khác như là:

• nếu sử dụng bind mount thì tất cả các file hoặc directory thuộc user hiện tại của host sau khi mount vào container đều có owner là root (dù cho user trong container hiện tại có là root hay www-data hay là ai đi nữa)
• nếu tạo file từ bên trong container (ví dự user trong container là root) thì file được tạo nếu xem từ trong container thì của root, nhưng nếu cùng thời điểm đó xem ở ngoài host thì lại là của user hiện tại
• nếu bên ngoài có 1 file thuộc root thì sau khi bind mount thì xem trong container thì owner lại chuyển thành nobody

Toàn bộ những gạch đầu dòng trên đều là do e tự thử nghiệm ko dưới 10 lần rồi tổng kết lại được vây Qua đây thì thấy được nhược điểm của docker desktop là không những sử dụng vm chứ ko được tối ưu như docker engine thì vấn đề với owner + permission cũng là thứ cần được đẵn đo để đánh đổi lấy ưu điểm là tiện lợi, dễ thao tác. Nhân đây cũng cảm ơn a về series docker này và vì đã trả lời nhiệt tình các thắc mắc của m.n