Kiến thức thú vị từ Sydexa

Trong lập trình frontend, "làm mới trang" trông có vẻ là một thao tác đơn giản, nhưng ẩn sau đó là một luồng phối hợp phức tạp giữa giao tiếp mạng (network communication), chiến lược cache (caching strategy) và engine render (rendering engine). Đặc biệt là khi nhấn F5, nó không phải là "tải lại hoàn toàn", cũng không phải là "dùng trực tiếp cache ở local", mà là một cơ chế xác thực thông minh nằm giữa hai trạng thái này. Để thực sự làm chủ các kỹ năng tối ưu hóa hiệu năng và debug frontend, bạn

Trong các dự án mà Backend và Frontend được phát triển hoàn toàn tách biệt, chắc hẳn không ít lần chúng ta phải đau đầu với câu hỏi: "Dữ liệu server trả về thì nên xài luôn hay phải xào nấu lại?". Nếu dạo quanh các diễn đàn công nghệ hay đọc các bài thảo luận trên mạng, bạn sẽ thấy cuộc tranh luận về cách xử lý dữ liệu từ API này dường như chưa bao giờ có hồi kết. Cốt lõi của vấn đề luôn xoay quanh hai luồng quan điểm cực kỳ quen thuộc: "Dữ liệu backend trả về sao thì cứ tận dụng nguyên xi như

useMemo là một React Hook giúp chúng ta ghi nhớ kết quả tính toán giữa các lần render để tối ưu hiệu năng trong một số trường hợp. Tuy nhiên, có một thực trạng đang diễn ra: người không biết thì chẳng bao giờ dùng, còn người đã biết thì lại lạm dụng nó ở mọi lúc, mọi nơi. Bài viết này sẽ giúp bạn hiểu rõ thực sự thì trong những trường hợp nào chúng ta mới nên sử dụng useMemo. Cú pháp tổng quát: useMemo hoạt động như thế nào? Ở lần render đầu tiên, useMemo sẽ thực thi hàm calculateValue (khôn

Nếu ví thế giới Database như ngành công nghiệp ô tô, thì MySQL chính là Toyota: Phổ biến, dễ sửa chữa, phụ tùng thay thế ở khắp nơi và cực kỳ thực dụng. Trong khi đó, PostgreSQL (hay Postgres) giống như Mercedes-Benz: Kỹ thuật cơ khí chính xác, nhiều tính năng cao cấp, an toàn tuyệt đối nhưng đòi hỏi người lái phải có kiến thức. Câu hỏi "Nên dùng MySQL hay PostgreSQL?" có lẽ là câu hỏi gây tranh cãi nhiều nhất trong các buổi phỏng vấn System Design. Nhiều người hiện nay có xu hướng mặc định chọ

Hãy quay lại thời điểm bạn là CTO của một sàn thương mại điện tử đang tăng trưởng nóng (giống như Shopee hay Lazada giai đoạn đầu). Ban đầu, bạn dùng một con MySQL duy nhất. Mọi thứ thật tuyệt vời. Nhưng rồi ngày "Black Friday" đến. Dữ liệu đơn hàng tăng vọt lên 5TB. Con server MySQL bắt đầu "thở dốc", CPU 100%, ổ cứng đỏ lòm. Bạn quyết định làm điều mà mọi kỹ sư đều sợ: Sharding (Chia cắt dữ liệu). Bạn chia dữ liệu ra 10 con server MySQL khác nhau: Khách hàng A ở Server 1, Khách hàng B ở Serv

Trong lập trình, các nguyên tắc SOLID là năm nguyên tắc thiết kế hướng đối tượng quan trọng, giúp nhà phát triển viết mã dễ bảo trì, mở rộng và dễ hiểu. Năm nguyên tắc này lần lượt là: * Single responsibility priciple (SRP): Một lớp chỉ nên chịu trách nhiệm về một nhiệm vụ cụ thể. * Open/Closed principle (OCP): Không được sửa đổi một class có sẵn, nhưng có thể mở rộng bằng kế thừa * Liskov substitution principe (LSP): Các đối tượng kiểu class con cần có khả năng thay thế lớp cha mà không gây

Hãy thử tưởng tượng bạn là Kỹ sư Vận hành (Operations Engineer) tại CERN (Tổ chức Nghiên cứu Hạt nhân Châu Âu). Bạn đang chịu trách nhiệm giám sát Máy gia tốc hạt lớn (LHC). Hệ thống này không ngủ: hơn 100.000 cảm biến liên tục gửi về các chỉ số nhiệt độ, áp suất, từ trường... với tần suất 100 mili-giây một lần. Đột nhiên, một cảnh báo đỏ xuất hiện: Nhiệt độ tại nam châm siêu dẫn số 4 tăng bất thường. Để ngăn chặn một vụ nổ trị giá hàng tỷ đô la, bạn cần ngay lập tức vẽ biểu đồ biến động nhiệt

Hãy thử tưởng tượng bạn là kỹ sư tại GitHub vào những năm 2013. Bạn đang lưu trữ hàng tỷ dòng mã nguồn (source code) từ hàng triệu kho chứa (repository) khác nhau. Một người dùng gõ vào thanh tìm kiếm từ khóa function login(). Nhiệm vụ của bạn là phải tìm chính xác đoạn code đó trong vài mili-giây. Nếu bạn dùng câu lệnh SQL LIKE %login()% trên MySQL, hệ thống sẽ sập ngay lập tức vì phải quét toàn bộ bảng (full table scan). GitHub cần một giải pháp không chỉ "lưu" dữ liệu, mà phải "hiểu" và "đán

Nếu bạn quay ngược thời gian về năm 2010, Facebook đang đối mặt với một bài toán kỹ thuật "đau đầu". Họ muốn hợp nhất Chat, SMS và Email vào một hộp thư duy nhất (Facebook Messages). Hệ thống MySQL sharding cũ kỹ của họ bắt đầu "hụt hơi" trước lượng dữ liệu khổng lồ tăng lên từng giây. Họ cần một thứ gì đó có khả năng ghi cực nhanh (write-heavy), mở rộng không giới hạn và không bao giờ được phép sập. Câu trả lời của họ lúc đó chính là Apache HBase. Dù sau này Facebook đã chuyển sang MyRocks để

Trong quá trình phát triển phần mềm, có bao giờ bạn từng gặp một vấn đề kỳ lạ: đôi khi dùng localhost:3000 có thể truy cập project bình thường, nhưng khi đổi thành 127.0.0.1:3000 lại không thể truy cập. Có lúc lại ngược lại, localhost không được nhưng 127.0.0.1 lại dùng được. Khi làm theo tutorial để cấu hình kết nối database, có tutorial ghi localhost, có tutorial ghi 127.0.0.1, trông có vẻ đều trỏ về máy tính của bạn, nhưng tại sao lại có hai cách viết? Rốt cuộc chúng khác nhau như thế nào?

Sau khi tối ưu hóa CSS selector để giải quyết vấn đề render trang chậm, tôi nhận ra rằng trong quá trình phát triển trước đây, chúng ta thường vô thức bỏ qua các vấn đề về hiệu suất của CSS selector. Sau một thời gian quan sát trang web, tôi phát hiện khi trang web ngày càng phức tập, các selector kém hiệu quả có thể làm tăng thời gian tính toán bố cục khoảng 20%, thậm chí xuất hiện hiện tượng layout thrashing (rung bố cục) ngoài ý muốn. Nguyên nhân gốc rễ nằm ở ba đặc tính cốt lõi của cơ chế r