@nghiand1010 Dạ vâng anh 🫡

@tmsangdev Ok thank em

Em cảm ơn đại ca :v Em dùng Camtasia với Canva đại ca ơi

Hay quá chú làm video bằng phần mềm gì thế!

Ớ Đồng học lớp Fresher Web 06 ở MISA trước à man?? Giờ join công ty nào rồi man? 🤘

Bài viết rất chất lượng ạ

hehe cảm ơn

Hay quá ad

hay qua a

bài đọc dễ hiểu

Luật 3 lần là một vấn đề tranh cãi. Đối với sản phẩm lâu năm, việc 1 đoạn code được sử dụng 2 lần ở 2 nơi có thể thành bug ẩn. Đúng là việc đi đến đâu refactor đến đấy là có vẻ tốn kém, rườm rà. Nhưng code được viết tốt thì ít phải refactor hơn. Để lại các đoạn legacy code có thể phải trả giá bất ngờ trong tương lai. Thiết kế lẫn code đều cần đạt được khả năng thích ứng với thay đổi trong tương lai và suy nghĩ dòng này sẽ chỉ được gọi 1, 2 lần không hơn là suy nghĩ nguy hiểm có thể đi ngược lại giá trị của code cũng như thiết kế, sản phẩm.

refactor đúng là có quy mô khác nhau, ở mức thiết kế hoặc ở mức dòng code. nhưng "refactor ở quy mô nhỏ" có thể là khó đong đếm, vì review code đã loại bỏ lỗi ở mức quy mô "nhỏ" khá nhiều.

refactor thì không hời hợt được và cần sự quyết tâm đáng kể. Nguồn lực cho refactor thường không được tính toán nghiêm túc trong các dự án và khiến việc refactor trở nên áp lực khi nó trở thành việc không tên, hay không được "tính tiền". Vì thế, nó không chỉ là việc của dev, mà ở mức quản lý dự án.

Bài viết rất hay. Mình muốn có lời khuyên cho case hiện tại đang gặp phải:

• Postgresql: 14
• TimescaleDB + pg_cron: Installed
• Table có tần suất ghi,đọc lớn (hiện check trong base/xxxx -> size đang là 190G) => Mình check config postgresql thì không thấy có enable autovacuum, mà size của disk càng ngày càng tăng Mình muốn hỏi xem có nên bật autovacumm và chạy VACUUM FULL ngay bây giờ để giải quyết tình trạng này không. Vì mình đã 2,3 lần nâng disk size lên rồi nhưng không giải quyết triệt để. Hi vọng nhận được lời khuyên từ bạn

mãi mới hiểu được cái translateZ all phải + 50px. Cho ai chậm tư duy thì ví dụ mặt front trục Ox sẽ bên phải, còn mặt back khi rotateY(180 độ) thì trục Ox của back sẽ hướng về bên trái nhé

mình thấy có vấn đề là, nếu có nhiều dòng cùng scan_dt, thì sẽ JOIN tất cả. bài toán yêu cầu JOIN 1 dòng, và scan_dt lớn nhất (

bài viết này đang đi khá sâu vào vấn đề build hệ thống chat, mà bỏ qua việc đó là hệ thống chat phục vụ 50 triệu người 1 ngày. Giật title quá.

Oke e ơi ♥️

nhìn từ gốc rễ thì nó liên quan đến cách cấp phát bộ nhớ. kiểu giá trị là các kiểu có kích cỡ bộ nhớ cố định, còn kiểu tham chiếu thì không. kiểu giá trị đc cấp phát vào stack, còn kiểu tham chiếu được cấp phát vào stack giá trị địa chỉ ô nhớ trong heap, còn giá trị của tham chiếu được cấp phát vào heap. ô nhớ trong stack có độ dài cố định nên truy xuất nhanh và đc copy thẳng vào cpu để tính toán, vì thế khi truyền vào hàm, giá trị của nó ko thay đổi khi hàm kết thúc (bị thay đổi là giá trị đc copy vào cpu). từ khoá ref để yêu cầu chương trình thực hiện thay đổi trên stack chứ không copy. vậy với kiểu tham chiếu cũng tương tự, từ khoá ref là trỏ tới giá trị địa chỉ ô nhớ trong stack mà đang trỏ đến heap. Nếu không truyền với từ khoá ref thì giá trị này cũng đc copy vào cpu, nếu thay đổi biến local này bằng new hoặc gán bằng object khác, biến gốc không ảnh hưởng. Nhưng thay đổi giá trị của thuộc tính con thì có hiệu quả cho cả biến gốc vì thay đổi bên heap chứ không phải bên stack.

hay quá anh ơi

@refacore Xin cảm ơn nhận xét chi tiết cả bạn! Mình chỉ giải thích thêm, hi vọng bạn có thể đồng cảm, vì bài viết của mình cũng hướng đến nhiều người, trong đó có nhiều bạn bè - những người không-thạo-tiếng-Anh, họ vẫn thoải mái khi dùng những thuật ngữ thuần việt như vậy, đôi khi họ còn dễ nhớ hơn. Mình giải thích thêm cho bạn hiểu phần "lắc giải pháp". Hoàn toàn không đúng theo ý bạn hỏi "Loại bỏ các giả định rồi lại giả định". Tóm tắt phần đó là khi bạn có nhiều giả định, thì hãy đặt câu hỏi (ví dụ, câu hỏi các công ty lớn họ sẽ làm gì?), khi bạn có đáp án thì sẽ không còn nhiều giả định nữa.

Code này dùng được với db nhỏ, nhưng với db lớn không biết có tối ưu không