Hy vọng bạn đã có một kỳ nghỉ lễ nạp đầy năng lượng. Trong số newsletter khai xuân kỳ này, chúng ta sẽ cùng thảo luận về một chủ đề mang tính bước ngoặt trong lộ trình phát triển của một kỹ sư: “Tư duy chiến lược” (Strategic Thinking) thông qua bài chia sẻ của bạn N^4.

Tư duy chiến lược là gì?

Khi nhắc đến “chiến lược”, chúng ta thường hình dung đến các CEO trong phòng kính bàn về tầm nhìn thập kỷ hay những thương vụ triệu đô. Với một kỹ sư đang hằng ngày vật lộn với bug và deadline, khái niệm này nghe có vẻ “đao to búa lớn”.

Nhưng thực tế hoàn toàn ngược lại. Tư duy chiến lược chính là nền tảng để bạn đảm nhận những trọng trách lớn hơn. Dù bạn chọn con đường chuyên gia (IC) hay quản lý (Manager), khả năng nhìn ra “bức tranh lớn” là thước đo phân biệt giữa một người thực thi thuần túy và một kỹ sư có tầm vóc.

Chuyện về Kỹ sư A và Kỹ sư B

Hãy tưởng tượng hai kỹ sư cùng nhận nhiệm vụ: “Giảm số lượng cấu hình (config) rác trong hệ thống”.

• Kỹ sư A (Tập trung vào “How” - Cách làm): Ngay lập tức viết RFC để dọn dẹp. Bạn đề xuất xóa code thừa, gộp file, viết script automation để dọn dẹp nhanh hơn. Cách tiếp cận này giải quyết được phần ngọn của vấn đề.

• Kỹ sư B (Tập trung vào “Why” - Tại sao): Bạn dành thời gian đặt câu hỏi: “Tại sao hệ thống lại sinh ra nhiều config rác? Tại sao quy trình hiện tại không ngăn chặn được việc này? Điều gì xảy ra nếu chúng ta không dọn dẹp thường xuyên?”.

Kết quả: Kỹ sư B nhận ra vấn đề nằm ở việc thiếu cơ chế Monitoring và KPI cụ thể. Thay vì chỉ đi dọn rác, bạn thiết lập một hệ thống cảnh báo và biến nó thành chỉ số để toàn team tự theo dõi. Kỹ sư B đã chuyển bài toán từ “Đi dọn dẹp” sang “Xây dựng hệ thống tự vận hành”.

Bài học rút ra: Kỹ sư B không chỉ giải quyết task, bạn ấy giải quyết nguyên nhân gốc rễ. Đó chính là tư duy chiến lược.

Tư duy chiến lược trong tổ chức

Trong một tổ chức, sự thăng tiến tỷ lệ thuận với khả năng xử lý các câu hỏi phức tạp:

• Junior/Senior: Tập trung nhiều vào How (Làm thế nào để thực thi tốt nhất?).

• Staff/Principal/Manager: Phải trả lời được câu hỏi Why (Tại sao làm cái này mà không làm cái kia?) và What (Cái gì mang lại giá trị lớn nhất cho tổ chức?).

Việc rèn luyện khả năng trả lời câu hỏi “Why/What” càng nhiều, bạn sẽ hiểu rõ hơn tại sao các cấp bậc lãnh đạo của mình lại đưa ra chiến lược này, chiến lược kia. Khi bạn bắt đầu tự tạo ra được cái “Why” cho team của mình, đó là lúc bạn đã sẵn sàng bước lên những nấc thang cao hơn trong sự nghiệp.

Rèn luyện Tư duy Chiến lược

Một vài gợi ý dành cho các bạn nào đang muốn rèn luyện tư duy chiến lược:

1. Xác định tầm nhìn và lý do (Vision & Why): Nhìn xa về tương lai để biết team và tổ chức đang hướng về đâu. Bạn không chỉ làm task, bạn đang xây dựng một phần của hệ thống. Nếu không biết “tại sao” phải đi đến đó, bạn sẽ rất dễ tối ưu hóa những thứ không cần thiết.

2. Đừng “yêu” phương án đầu tiên: Luôn khảo sát nhiều kịch bản khác nhau để đạt được mục tiêu. Thay vì bám víu vào một công nghệ hay một pattern duy nhất, hãy đặt chúng lên bàn cân so sánh về chi phí, thời gian và nguồn lực.

3. Dự báo hệ quả (Second-order Thinking): Trước khi thực thi, hãy tự hỏi: “Và sau đó thì sao?”. Một thay đổi nhỏ hôm nay có thể mang lại “hiệu ứng cánh bướm” gây ra thảm họa vận hành sau 6 tháng. Tư duy về tác động tầng thứ hai giúp bạn bền bỉ hơn với các quyết định của mình.

Lời kết

Trong kỷ nguyên AI ngày nay, khi các Agent có thể viết code và thực thi các bài toán kỹ thuật với tốc độ chóng mặt, giá trị của một kỹ sư không còn nằm ở việc “viết script nhanh hơn”.

Điểm cạnh tranh cốt lõi của con người chính là khả năng xác định cái Why. Giống như Kỹ sư B, một khi bạn đã định vị đúng vấn đề và chiến lược, bạn hoàn toàn có thể sử dụng AI như một công cụ đắc lực để hiện thực hóa các kế hoạch.

Hãy bắt đầu năm mới bằng cách tự hỏi mình nhiều hơn câu hỏi “Tại sao” trước khi bắt tay vào gõ dòng code đầu tiên. Đó chính là khởi đầu của một năm đột phá!

Chúc các bạn một năm mới làm việc đầy cảm hứng và chiến lược!

Tech Trends 2026

Báo cáo từ Deloitte đề cập về xu hướng phát triển của công nghệ trong năm 2026 được dự đoán sẽ tập trung vào các xu hướng chính:

• Sự trỗi dậy của Robot có khả năng thích ứng: AI đang được tích hợp sâu vào các thiết bị vật lý, biến những robot truyền thống thành những cỗ máy có khả năng thích ứng cao. Chúng không chỉ vận hành mà còn tự học hỏi từ môi trường phức tạp để đạt được độ an toàn và chính xác vượt trội.

• Tái thiết kế quy trình cho Agentic AI: Việc vội vàng đưa Agentic AI vào các quy trình cũ vốn thiết kế cho con người đã dẫn đến nhiều thất bại đáng tiếc. Các tổ chức hàng đầu nhận ra rằng giá trị thực không nằm ở việc “lắp ghép” AI vào mô hình cũ, mà ở việc tái thiết kế toàn bộ hoạt động, xây dựng kiến trúc tương thích và thiết lập khung quản trị mới cho “nhân sự số”.

• Chiến lược hạ tầng điện toán linh hoạt: Khi AI đi vào thực tiễn, hạ tầng cũ bộc lộ nhiều bất cập. Vấn đề không chỉ là chi phí, mà còn là quyền sở hữu dữ liệu, độ trễ và bảo mật trí tuệ nhân tạo. Thay vì chọn lựa cực đoan giữa Cloud hay On-premise, doanh nghiệp cần một hệ sinh thái điện toán linh hoạt, tối ưu hóa cho từng loại tải công việc cụ thể.

• Tái cấu trúc bộ máy nhân sự công nghệ: AI đang định hình lại cách tổ chức và lãnh đạo các đội ngũ kỹ thuật. Mô hình tương lai sẽ tinh gọn và năng động hơn khi AI hiện diện trong mọi lớp vận hành - từ kiến trúc đến triển khai. Thách thức lớn nhất của các nhà lãnh đạo là tốc độ khai thác tiềm năng AI để biến tổ chức thành một cỗ máy tự học hỏi liên tục.

• Nghịch lý bảo mật trong kỷ nguyên AI: Việc triển khai AI quy mô lớn tạo ra một nghịch lý: AI giúp doanh nghiệp cạnh tranh hơn nhưng cũng mở ra những lỗ hổng mới. Các tổ chức phải đối mặt với rủi ro từ Shadow AI (AI tự phát không kiểm soát), các cuộc tấn công mạng do AI dẫn dắt và những rủi ro nội tại từ chính hệ thống thuật toán.

OpenAI bets big on audio as Silicon Valley declares war on screens

Năm 2026, Audio AI đang được kỳ vọng sẽ bùng nổ nhờ xu hướng lớn mang tên “War on Screens” ở Silicon Valley. Các công ty công nghệ lớn tin rằng tương lai tương tác với AI sẽ chủ yếu qua giọng nói, giảm phụ thuộc vào màn hình để tránh vấn đề nghiện thiết bị, mỏi mắt và tăng tính tiện lợi (ví dụ: khi lái xe, nấu ăn hay đi bộ).

Xu hướng Audio AI trong năm 2026 không chỉ là “nâng cấp giọng nói của ChatGPT” mà là bước ngoặt chuyển giao diện từ visual sang audio, mở ra kỷ nguyên mới khi AI sẽ đóng vai trò một “người bạn đồng hành” thực thụ.

Động thái này phản ánh hướng đi của toàn bộ ngành công nghệ - hướng tới một tương lai nơi màn hình trở thành “background noise” và âm thanh chiếm vị trí trung tâm. Sự bùng nổ của các thiết bị phụ kiện công nghệ tích hợp AI như kính thông minh, vòng tay thông minh hoặc nhẫn thông minh như một minh chứng cho sự định hình một cuộc dịch chuyển lớn trong phương thức giao tiếp và tương tác với AI và cả xu hướng phát triển các ứng dụng tương tác với người dùng trong tương lai.

AI Works, PRs Don’t: How AI is Breaking the SDLC and What to Do about it

Việc tích hợp trí tuệ nhân tạo vào quy trình phát triển phần mềm đang tạo ra một làn sóng bùng nổ về mã nguồn, nhưng cũng đi kèm với những thách thức mới về quản trị. Theo một nghiên cứu của Hao He từ Đại học Carnegie Mellon trên hơn 2.000 dự án mã nguồn mở, các công cụ như Cursor AI có thể thúc đẩy tốc độ phát triển và chất lượng mã lên gấp ba đến năm lần trong giai đoạn đầu. Tuy nhiên, sự tăng trưởng này chỉ mang tính tạm thời vì sau khoảng một tháng, các dự án bắt đầu đối mặt với tình trạng tích lũy nợ kỹ thuật kéo dài do lượng mã được tạo ra quá nhanh.

Trước thực trạng đó, Michael Webster từ CircleCI cho rằng cần phải cải tiến quy trình Tích hợp và Phân phối liên tục để thích ứng với tốc độ của AI. Ông đề xuất áp dụng kỹ thuật Phân tích Tác động Kiểm thử để chỉ tập trung kiểm tra những phần mã nguồn thực sự bị ảnh hưởng thay vì chạy lại toàn bộ hệ thống, từ đó tối ưu hóa chi phí và hiệu suất. Đồng thời, sức mạnh tính toán vượt trội của AI cho phép chúng ta kiểm tra vô số giả thuyết thay vì bị giới hạn bởi năng lực con người như phương pháp truyền thống. Điều này đòi hỏi các kỹ sư phải đơn giản hóa và điều chỉnh lại hệ thống đo lường cũng như các vòng lặp phản hồi. Cuối cùng, thông điệp cốt lõi là cộng đồng phát triển phần mềm cần thay đổi tư duy và xem xét lại các phương pháp cũ để xây dựng những quy trình mới phù hợp hơn với quy mô và tốc độ chưa từng có của kỷ nguyên AI.

6 Cybersecurity Predictions for the AI Economy in 2026

Sự xuất hiện của Agenetic AI, cùng sự thay đổi cả về hình thức làm việc từ tại văn phòng sang làm việc từ xa (remote), đã tạo nên những bước tiến to lớn về năng suất công việc. Những thay đổi về năng suất này cũng mở ra nhiều rủi ro mới kèm theo.

Một sự kiện thu hút sự quan tâm của giới bảo mật vào tháng 9 năm 2025, một chiến dịch do thám do AI tự vận hành đầu tiên trên thế giới đã được phát hiện bởi Công ty Anthropic, nhà phát triển chatbot AI Claude. Anthropic đã ngăn chặn kịp thời chiến dịch này, đồng thời họ cũng đã gửi đi thông tin cảnh báo cho khoảng 30 nạn nhân tiềm tàng bao gồm các công ty công nghệ, tổ chức tài chính và cơ quan chính phủ.

Bước sang năm 2026, dưới đây là 06 xu hướng dự báo về lĩnh vực bảo mật trong kỷ nguyên kinh tế AI lên ngôi.

Dự báo 01: Một kỷ nguyên với những hình thức lừa đảo mới ứng dụng các công nghệ AI hỗ trợ giả mạo danh tính. Trí tuệ nhân tạo tạo sinh (GenAI) đang đạt đến trạng thái sao chép thời gian thực hoàn hảo, khiến cho các nội dung deepfake ngày càng khó phân biệt với nội dung thực tế. Bên cạnh đó, sự trỗi dậy của các Agents tự động đã tạo ra lỗ hổng quan trọng: Một danh tính giả mạo giờ đây có thể kích hoạt một loạt các hành động tự động.

Dự báo 02: Các AI Agents có rủi ro bị lạm dụng trở thành các gián điệp ngầm trong tổ chức. Mặc dù AI Agent tự động là một nhân viên kỹ thuật số không biết mệt mỏi, nhưng nó cũng là một mối đe dọa nội bộ nguy hiểm. Một Agents luôn hoạt động, không bao giờ ngừng nghỉ; và nếu như được cấu hình không đúng cách, nó có thể truy cập vào các tài nguyên dữ liệu quan trọng của toàn bộ hệ thống – quyền truy cập đặc quyền vào các API, dữ liệu và hệ thống quan trọng – nơi nó được tin tưởng một cách ngầm định. Nếu các doanh nghiệp không chú trọng đến việc bảo mật các Agents này như cách họ triển khai chúng, họ đang tạo ra một lỗ hổng bảo mật tiềm tàng khó kiểm soát.

Dự báo 03: Kỷ nguyên tới sẽ có nhiều thách thức về độ tin cậy của dữ liệu, của tài nguyên được dùng để training cho các Model AI. Một hình thức tấn công mới đó chính là “đầu độc” dữ liệu: làm sai lệch có chủ đích một lượng dữ liệu khổng lồ được sử dụng để huấn luyện các mô hình AI cốt lõi chạy trên cơ sở hạ tầng điện toán đám mây phức tạp, vốn là nền tảng của trung tâm dữ liệu AI hiện đại. Chúng ta đơn giản là không thể bảo mật những gì chúng ta không thể nhìn thấy. Trong khi đó, các nhóm xử lý dữ liệu hiểu rõ dữ liệu có thể không được đào tạo để phát hiện ra những thao tác thao túng ẩn độc hại.

Dự báo 04: Cuộc đua giành lợi thế nhờ AI sẽ vấp phải các rào cản pháp lý. Vấn đề ai chịu trách nhiệm khi trí tuệ nhân tạo (AI) gặp sự cố sẽ chuyển từ cuộc tranh luận triết học sang vấn đề tiền lệ pháp lý, tạo ra một tiêu chuẩn mới về trách nhiệm pháp lý trực tiếp của các nhà điều hành trong việc quản lý doanh nghiệp trí tuệ nhân tạo.

Dự báo 05: Năm 2026 sẽ là giai đoạn châm ngòi cho cuộc chuyển đổi mật mã lớn nhất và phức tạp nhất trong lịch sử, khi các quốc gia đang thúc đẩy chuyển đổi cơ sở hạ tầng quan trọng và chuỗi cung ứng, bắt đầu hành trình hướng tới mật mã hậu lượng tử (PQC).

Dự báo 06: Trình duyệt đang phát triển từ một công cụ tổng hợp thông tin thành một nền tảng Agentic có khả năng thực thi các tác vụ phức tạp thay cho người dùng. Khi các tổ chức chạy đua để triển khai các trình duyệt này nhằm thúc đẩy năng suất thì họ cũng phải đối mặt với một tình thế khó xử: làm thế nào để tạo điều kiện cho sự chuyển đổi này trong khi vẫn đảm bảo an ninh cho toàn bộ doanh nghiệp.

Góc nhìn tác giả

Trong kỷ nguyên AI đang len lỏi vào mọi ngóc ngách của đời sống, chúng ta buộc phải thích nghi với những dịch chuyển về kỳ vọng cùng nỗi quan ngại về việc các mô hình trí tuệ nhân tạo sẽ thay thế con người. Khi máy móc đang dần tự tối ưu khả năng của chính mình, đây cũng là lúc chúng ta cần tập trung làm tốt những giá trị cốt lõi của con người.

Kỷ nguyên AI không chỉ mang đến thách thức mà còn mở ra những chuyển biến tích cực, tạo ra những phương thức mới giúp sự phối hợp giữa người và máy trở nên hiệu quả hơn. Hơn lúc nào hết, việc nắm vững kiến thức nền tảng, phát triển tư duy hệ thống và năng lực phản biện đã trở nên tối quan trọng. Bên cạnh đó, một chút hoài nghi lành mạnh cùng sự kiên nhẫn trong việc kiểm chứng thông tin dựa trên các nguyên tắc cốt lõi và kinh nghiệm thực tế sẽ là chìa khóa để ta tận dụng năng lực của AI một cách chính xác nhất.

Sau tất cả, AI có thể vượt trội trong những nhiệm vụ nhất định, nhưng có một điều nó không bao giờ có thể thay thế được: Đó chính là những giá trị riêng biệt tạo nên bản sắc con người bạn.

Trong số này, chúng mình mong muốn đưa thêm một góc nhìn xoay quanh việc ảnh hưởng cụ thể vào yếu tố nào và ảnh hưởng ra sao đối với những vai trò khác nhau trong giới công nghệ. Khi AI trở thành công cụ để khuếch đại khả năng của kĩ sư, đánh đổi là điều không tránh khỏi.

Cụ thể hơn, trong một báo cáo tổng hợp bởi AppKnox gần đây - AI and Developer Burnout Report 2025, báo cáo đề cập tới việc AI tái định hình (reshape) tính chất công việc, và cũng như cả định nghĩa về quá tải (burnout) kèm theo sự xuất hiện một dạng căng thẳng mới - cognitive and emotional burnout.

Từ việc được sở hữu công cụ mới, tốt hơn, nhanh hơn, đến việc xuất hiện dạng căng thẳng mới, liệu anh em kĩ sư đã có dịp nhìn lại yếu tố gì đang thay đổi thầm lặng như con sóng ngầm? Thay vì mải cố gắng theo đuổi để làm chủ/điều khiển công cụ mới này?

Theo góc nhìn của mình, sự kỳ vọng - sự kỳ vọng giữa stakeholders với kĩ sư, giữa sếp và team, cũng như giữa các thành viên trong team - là tác nhân chính, gốc rễ đang tái định hình ngành công nghiệp phần mềm, để dân công nghệ thích nghi và phát triển như đề cập ở các số trước. Dưới đây là một số bài viết và báo cáo có liên quan, để làm rõ kỳ vọng đã và đang dịch chuyển ra sao.

The Productivity Paradox of AI

1. Nghịch lý Jevons: Càng hiệu quả, càng... tốn kém

A look at how Jevons’ 19th-century paradox is playing out in modern code — where every leap in efficiency creates more developers, not fewer.

Bài viết vận dụng “Nghịch lý Jevons” để phản biện nỗi lo AI sẽ thay thế lập trình viên. Lịch sử cho thấy khi công nghệ giúp tăng năng suất và giảm chi phí (như động cơ hơi nước hay Cloud computing), nhu cầu tiêu thụ lại bùng nổ. Tương tự, khi AI giúp viết code nhanh và rẻ hơn, thế giới sẽ không cắt giảm nhân sự, mà sẽ xây dựng số lượng phần mềm khổng lồ hơn bao giờ hết.

2. Sự tiến hóa: Từ "Viết code" sang "Điều phối"

Atlassian’s internal data shows engineers spend only 16% of their week actually coding. The rest goes to coordination, debugging, testing, deployment, and documentation — areas now ripe for AI augmentation.

AI đang “dân chủ hóa” việc lập trình: nó hạ thấp rào cản gia nhập nhưng lại nâng cao tiêu chuẩn về sự xuất sắc. Sẽ không mất nhiều thời gian để một người mới gia nhập thị trường nhờ được hỗ trợ loại bỏ các “overhead” trong ngành (ví dụ kiến thức ngôn ngữ lập trình, vận hành hệ thống, deploy ứng dụng,…) nhưng sẽ cần làm quen với tư duy “nhạc trưởng” sớm hơn bao giờ hết.

3. Tương lai của tuyển dụng

According to LinkedIn’s 2025 Emerging Jobs Report, demand for AI-fluent software engineers has surged nearly 60% year-over-year, and Glassdoor data shows compensation premiums of 15–25% for developers proficient in AI frameworks and orchestration tools. The emergence of this new breed of engineer reflects a profound shift in leverage: the ability to command AI as an extension of one’s own reasoning.

Các bài phỏng vấn thuật toán truyền thống sẽ dần lỗi thời. Thay vào đó, thị trường sẽ tìm kiếm những kỹ sư biết cách tận dụng AI làm đòn bẩy để giải quyết bài toán thực tế hiệu quả. Về vấn đề này chúng mình cũng đã có đề cập chi tiết hơn tại đây.

Tóm lại, vẫn là điều anh em kĩ sư “động viên nhau”, AI đang mở ra một kỷ nguyên mới nơi tư duy hệ thống và khả năng thích ứng quan trọng hơn kỹ năng gõ code đơn thuần.

Where Architects Sit in the Era of AI

Bài viết đưa ra góc nhìn cụ thể hơn cho một vị trí, mà đối với cá nhân mình, tưởng chừng là người ít bị ảnh hưởng, thậm chí còn giá trị còn được tăng lên cao - Architects.

What does it mean to be an architect when architectural thinking can be automated?

Một câu hỏi nêu ra trong bài đã khiến mình “goosebumped”, điều chỉ 5-6 tháng trước còn là khoảng gap giữa senior engineers/architects với AI giờ đã được bắt kịp với các mô hình thinking mạnh mẽ từ các ông lớn công nghệ.

1. Sự chuyển dịch: tái định nghĩa như là một “Meta-designer”

Thay vì trực tiếp thiết kế mọi thứ như trước đây, thông qua các cuộc họp và buổi brainstorm cùng cộng sự, Architect sẽ chuyển sang vai trò điều phối các AI agents thông qua mô hình “3 Vòng lặp”:

• In the Loop: Cộng tác song song. AI đưa ra các phương án, con người ra quyết định cuối cùng.

• On the Loop: AI tự vận hành trong giới hạn cho phép. Architect đóng vai trò giám sát và can thiệp khi cần thiết.

• Out of the Loop: AI tự chủ hoàn toàn. Architect tập trung thiết kế các cơ chế quản trị và an toàn.

2. Những cái bẫy mới: Sự thui chột và Ảo giác

Quyền năng của AI đi kèm với những rủi ro chí mạng cho nghề nghiệp:

• Skill Atrophy: Quá phụ thuộc vào AI sẽ làm mòn “trực giác” và “kiến thức ngầm” – những kinh nghiệm xương máu không có trong sách vở, được tích luỹ bơi quá trình làm việc lâu năm từ những Architects dày dặn.

• Sự tự tin giả tạo: AI có thể đưa ra thiết kế sai lầm với giọng điệu vô cùng chắc chắn. Văn hóa làm việc cần chuyển từ “tin tưởng” sang “thẩm định” (verification).

Dù bài viết đề cập phần lớn đến level Architects, dưới góc nhìn là một kĩ sư Senior-level, mình thấy có một sự liên hệ mật thiết đến công việc hằng ngày, nơi đã có nhiều lúc trực giác phát huy hiệu quả ở những thời điểm mình nghi ngờ ý kiến của AI dù chưa đủ kinh nghiệm để chỉ mặt đặt tên sự nghi ngờ đó.

DORA Report 2024/2025 (Google Cloud)

Bên cạnh các thống kê về sự áp dụng (adoption) và hiệu suất làm việc (productivity), báo cáo đề cập tới 3 kiểu “kỳ vọng” mới:

1. AI cải thiện tốc độ (throughput) nhưng làm tăng sự bất ổn (instability)

So với báo cáo năm trước, AI đã bắt đầu giúp tăng tốc độ phân phối phần mềm, nhưng nó cũng đi kèm với việc gia tăng tỷ lệ lỗi hoặc sự cố khi triển khai, cho thấy các hệ thống cơ bản chưa kịp thích nghi.

AI adoption now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability. This suggests that while teams are adapting for speed, their underlying systems have not yet evolved to safely manage AI-accelerated development.

2. Cần đầu tư vào hệ thống tổ chức để gặt hái thành quả từ AI

Lợi nhuận từ đầu tư AI không đến từ bản thân công cụ, mà từ việc cải thiện hệ thống nền tảng, quy trình và sự liên kết của đội ngũ.

“The greatest returns on AI investment come not from the tools themselves, but from a strategic focus on the underlying organizational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams.”

3. AI chưa giúp giảm áp lực (Burnout) hay sự ma sát (Friction) trong công việc

Mặc dù AI tăng năng suất cá nhân, nhưng nó không (hoặc chưa) giúp giảm bớt sự kiệt sức hay những rào cản trong quy trình làm việc nếu văn hóa và hệ thống không thay đổi.

“Despite all the benefits, friction remains unaffected, burnout stays flat, and delivery instability rises—unless the surrounding system and culture changes.”

Góc nhìn tác giả

Từ những bài viết và thống kê, ta có thể thấy rằng việc thích nghi trong thời gian tới không chỉ về thích nghi với công nghệ, công cụ mới mà còn để thích nghi với kỳ vọng mới. Thích nghi là hiểu rằng “luật chơi” đã thay đổi. Sếp của bạn, khách hàng của bạn, và cả team của bạn đang âm thầm thay đổi tiêu chuẩn đánh giá về một việc làm “xong” (definition of done).

Kết hợp với quan sát cá nhân và vốn kinh nghiệm ít ỏi đang có, mình có thể gói gọn một số “luật chơi” đã và đang dịch chuyển đối với:

1. Interns/Junior

Trước đây, Junior được phép sai sót cú pháp, được phép chậm để nghiên cứu, để làm quen công cụ. Đó là những giá trị bề nổi (explicit) mà tổ chức từng chấp nhận trả phí để bạn học.

Nhưng nay, AI đã làm những việc đó tốt hơn, nhanh hơn và rẻ hơn bất kỳ Junior nào. AI có thể giúp triển khai một tính năng hay thậm chỉ cả một framework trong 30 phút, nhưng liệu những dòng code đó có chứa lỗ hổng logic nào không? Có dễ maintain hay không? Hay chúng đang trở thành tech debt từ khi vừa được commit?

Kỳ vọng của Seniors dành cho bạn đã thay đổi:

• Trước đây: “Em implement tính năng này chưa? Có khó khăn nào trong lúc triển khai không?”

• Bây giờ: “Em có hiểu tại sao AI lại chọn thư viện này thay vì thư viện kia không? “Em có tin nó không hallucinate hàm này không?” Hay: “Mình còn cách nào khác tốt hơn không?”

Mấu chốt nằm ở chỗ, Juniors thường vẫn sẽ không được kỳ vọng làm nhanh hơn, trước đây có 4 tiếng bao gồm 3 tiếng để code và 1 tiếng test - bây giờ vẫn 4 tiếng: 30 phút code, 30 phút test thì dùng 3 tiếng còn lại như thế nào, ngồi chơi hay tự phản biện?

2. Senior Engineers

Khi khoảng cách về tốc độ viết code giữa Senior và Junior đang thu hẹp lại, tại sao công ty vẫn cần trả lương cao cho Senior?

Senior không còn được trả lương để thể hiện kỹ năng giải thuật hay triển khai hệ thống phức tạp. Họ được kỳ vọng để nói "KHÔNG".

Nói không khi được yêu cầu một loạt thay đổi trong thời gian ngắn, vì họ cần biết họ có thể và không thể kiểm soát được những chuyện gì sẽ xảy ra.

Nói không khi có một thay đổi cần được xác nhận yếu tố lịch sử hay ngữ cảnh, vì khi AI đã có sức mạnh thu thập những thông tin bề nổi (explicit), thì ngữ cảnh lịch sử (implicit) là những thứ sẽ được Seniors nắm rõ nhất.

Hay, như ở bài viết về Architects ở trên, nói không khi trực giác của người làm trong ngành “mách bảo”.

Lưu ý: việc nói không một cách khéo léo không đơn giản, hi vọng chúng mình sẽ có dịp đề cập tới ở các số sau.

3. Managers

Có lẽ đây là phần khó nhất, khi những gì mình quan sát hay nghe và đọc được cũng vẫn chỉ là bề nổi, và cũng chưa đủ kinh nghiệm để đánh giá toàn bộ bức tranh hay phần tảng băng chìm. Do đó, có thể sẽ nghe khá chung chung và mình chấp nhận điều đó.

Đây là vị trí chịu áp lực gọng kìm, từ sự thay đổi chóng mặt về công nghệ, tốc độ deliver của đội ngũ, đến kỳ vọng về chất lượng và thời gian đến từ bên ngoài. Sự chuyển dịch về kỳ vọng kéo theo mối quan tâm không còn nhiều về tiến độ, mà về rủi ro đối với công nghệ và con người.

Kỳ vọng nền (baseline) về chất lượng sản phẩm của team được nâng lên, code được commit và deploy liên tục, AI có thể đưa ra quyết định về mặt kiến trúc, vậy làm sao để thiết lập các "Guardrails" (hàng rào bảo vệ) để đảm bảo team không biến thành những công nhân đi dọn rác cho AI về sau?

Khi kỳ vọng về work rate (lượng công việc của team trong đơn vị thời gian) cũng được nâng lên nhờ có AI hỗ trợ, lúc này liệu “đảm bảo kịp tiến độ” có còn tập trung chính của Manager? Hay giờ đây kỳ vọng lên người quản lý dịch chuyển thành người giữ nhịp độ, đảm bảo các mắt xích về con người vận hành bền bỉ, chính xác, không bị kiệt quệ?

(trước đây Grokking cũng đã có một bài viết về Một tuần làm việc của Engineering Manager, mình cũng tự hỏi liệu sau những biến động từ AI, câu chuyện đã khác hơn bao nhiêu phần trăm?)

Kết: có vẻ khi máy móc đang tự làm tốt dần khả năng của chính nó, chúng ta cũng cần làm tốt những gì mặt con người cần làm? cô đọng từ ví dụ trên: sự hoài nghi (junior), thấu hiểu ngữ cảnh (senior) và quản trị rủi ro (manager).

— sudo — ngồi nhìn SQL hằng ngày

Một bài viết dài cho số #270 để kết lại năm 2025, để có một góc nhìn trực diện về kỳ vọng đã thay đổi mà có thể hằng ngày mình vô tình chưa đề cập thẳng thắng với nhau.

Cảm ơn mọi người đã đọc đến đây.

Chúc mọi người có một kì nghỉ giáng sinh tĩnh lặng cho một năm mới sẵn sàng.

Dạo gần đây trong năm 2025, chúng ta đã chứng kiến được sự tiến bộ vượt trội của các mô hình ngôn ngữ lớn (LLM) - từ lập trình cho đến giải quyết các vấn đề khoa học - không còn đơn thuần là nhờ viết email hay tạo report nữa. Điều này dấy lên sự lo ngại của một bộ phận lập trình viên tin rằng sớm muộn gì AI sẽ thay thế được các developer - ít nhất là trong các tác vụ của junior dev. Đây không phải là sự lo ngại vô căn cứ, theo WJS, những đợt sa thải này được cho có đóng góp của AI:

Amazon sẽ cắt 14,000 corporate jobs. United Parcel Service (UPS) - công ty giao hàng ở Mỹ - đã giảm gần 14,000 vị trí trong lực lượng quản lý trong vòng 22 tháng vừa qua. Tập đoàn bán lẻ Target cũng sẽ cắt giảm 1800 nhân sự.

Các nhà kinh tế học từ ngân hàng dự trữ liên bang ở St. Louis cũng có bài nghiên cứu chỉ ra sự tương quan (chưa rõ ràng) giữa mức độ phơi nhiễm từ AI trong việc làm với mức độ đón nhận AI thực tế.

Biểu đồ tương quan giữa mức độ phơi nhiễm AI và mức thay đổi của tỉ lệ thất nghiệp từ 2022-2025

Các nhóm ngành nghề có mức độ phơi nhiễm AI cao như Engineering, Computers and Math (80%) có sự thay đổi cao trong tỉ lệ thất nghiệp.

Biểu đồ tương quan giữa mức độ đón nhận AI và mức thay đổi của tỉ lệ thất nghiệp từ 2022-2025

Một lần nữa các nhóm ngành Computers - nơi mà có sự đón nhận AI cao lại có mức tăng tỉ lệ thất nghiệp cao trong các nhóm ngành nghề.

Tuy nhiên thực tế có vẻ không đáng sợ như chúng ta thấy như từ những con số trên, ít nhất là những người bạn xung quanh mình (names here) vẫn còn đi làm bình thường. Liệu chúng ta có nên hoài nghi về nhận định AI chịu trách nhiệm cho những đợt sa thải gần đây?

Một bài nghiên cứu gần đây từ MIT Media Lab chỉ ra rằng

95% of generative AI pilot business project - tạm hiểu là những dự án lấy generative AI làm trọng điểm - đang thất bại (failing).

Khảo sát của Atlassian kết luận rằng

96% doanh nghiệp chưa thấy rõ sự cải thiện mạnh mẽ trong tổ chức hiệu quả (organizational efficiency), sự đổi mới hoặc chất lượng công việc.

Cũng có thêm nghiên cứu từ HBR cho thấy người dùng không hoàn toàn hài lòng với AI.

40% người dùng doanh nghiệp tham gia khảo sát nhận được “AI slop” (nội dung AI chất lượng thấp) trong công việc từ tháng trước và tốn trung bình gần 2 tiếng để sửa chữa cho mỗi slop. Thêm vào đó, họ không còn tin tưởng vào các đồng nghiệp hay trợ lý AI, không thực sự sáng tạo, thông minh và đủ khả năng.

Mình thấy các đồng nghiệp hoặc người dùng non-tech có sự kiên nhẫn không cao với AI. Điều này dấy lên một nghịch lí là chúng ta (developer) hay technical person có sự kiên nhẫn và tiếp xúc nhiều với AI nhất lại là nhóm người bị AI tác động nhiều nhất.

Thông qua các bài nghiên cứu và khảo sát ở trên: AI chưa thực sự làm được nhiều việc, thì AI không chắc là chịu trách nhiệm chính cho các cuộc sa thải gần đây. Vậy nguyên nhân có thể đến từ đâu?

Một nguyên nhân rõ ràng được nhắc nhiều là sự tuyển dụng quá mức trong và sau đại dịch khi mà cục dự trữ liên bang Mỹ đặt lãi suất cực thấp (gần 0), từ đó các công ty phải tái cấu trúc lại lực lượng lao động. Có nghĩa là các công ty cần tinh giảm lại chi phí vận hành. Nói tới đây thì ai cũng biết chi phí cho hạ tầng AI là cực kì to lớn.

Amazon đã tăng tổng chi phí vốn (CapEx) từ 54 tỉ USD trong năm 2023 lên $84 tỉ USD trong 2024, dự đoán là 118 tỉ USD trong 2025. Meta đang bảo đảm 1 hạn mức tín dụng (line of credit) 27 tỉ USD để tài trợ cho các trung tâm dữ liệu của hãng. Oracle lên kế hoạch vay tới 25 tỉ USD mỗi năm trong những năm tới để hoàn thành các hợp đồng về AI.

Đây là điều từng được thấy, khi mà các công ty trong giai đoạn căng thẳng tài chính, biện pháp tương đối đơn giản là chỉ cần sa thải bớt người lao động và kêu gọi những người khác làm việc chăm chỉ và nên biết ơn vì vẫn giữ được công việc hiện tại. AI chỉ đơn giản là một lời biện minh cho việc cắt giảm chi phí này.

Chúng ta có đại diện từ Amazon thú nhận với NBC rằng là AI không phải là nguyên nhân chính của hầu hết đợt cắt giảm biên chế. CEO của Amazon cũng xác nhận điều tương tự trong cuộc gọi nhà đầu tư.

Tăng trưởng chậm chạp từ doanh thu của mảng generative AI trong những năm gần đây không ủng hộ quan điểm các đợt sa thải gần đây là do AI. Chi phí cho hạ tầng AI có lẽ sẽ đạt 1 ngàn tỉ USD trong 2025 nhưng doanh thu lại chưa đến 30 tỉ. Ở đây có ai tin là với doanh thu nhỏ hơn nhiều so với chi phí, AI có đang thực sự hiệu quả đến mức để các công ty thay thế con người?

Trong khi đó, sinh viên mới ra trường đang gặp khó khăn khi tìm việc, rất nhiều bạn trẻ bị thuyết phục bởi câu chuyện công việc trong tương lai sẽ sớm bị thay thế bởi AI và Robot. Từ đó có người khuyên rằng sinh viên chuẩn bị kiếm việc làm trước khi tốt nghiệp là chuyện vô ích sau này. Trớ trêu thay, những ai đầu hàng vì nghe phải những lời khuyên như vậy là những người sẽ không kiếm được việc.

Vậy chúng ta có nên lo sợ AI? Quan điểm của mình, là một full stack developer đang phát triển các sản phẩm ứng dụng AI, mình khuyên các bạn trẻ đừng sợ AI cướp mất việc làm mà phải tìm cách thích nghi, sống chung và tận dụng AI để học và phát triển nhanh hơn.

Vậy làm sao để sống chung với AI? Câu hỏi này mình xin tham khảo ý kiến quý giá từ các bạn đọc.

-Boreal-

Programmers often ask: “When is coding the happiest?”

My answer is simple: before the product has users.

Before customers show up, you can just write code. No angry calls, no urgent tickets, no midnight firefights. Pure joy.

But products are for users. That happy time can’t last forever.

Tôi thấy nó hài vì nó khá là phù hợp với những gì tôi đã trải nghiệm những năm qua khi làm các dự án trong công ty. Một nỗi niềm mà tôi nghĩ những bạn coder khác có thể đều đã trải qua một lần.

— CuriousTien —

Ten Years, Starting Again: My Journey with TiDB

Bài viết này nói về hành trình của Liu Tang trong suốt 10 năm làm việc ở TiDB từ ngày dự án được sáng lập. Nhìn lại chặng đường đã qua, tác giả đã có gặp nhiều bất ngờ và thử thách để mà trưởng thành hơn trong con đường sự nghiệp của họ từ một người coder.

Từ tin nhắn Cá Tháng Tư của Max, người thành lập TiDB, cho đến ngày hôm nay khi mà TiDB trở thành một cơ sở dữ liệu phân tán mã nguồn mở được biết đến toàn cầu. Từ việc chạy theo sự hoàn hảo về kỹ thuật đến việc đặt thành công của khách hàng như cốt lõi. Từ một ước mơ khởi nghiệp đơn giản đến một sản phẩm mang tầm vóc toàn cầu trong kỷ nguyên điện toán đám mây. Hành trình này đã mang lại cho tác giả nhiều hơn những gì mà tác giả có thể tưởng tượng.

Mặc dù bài viết này được viết và thông dịch qua từ lời tác giả bằng ChatGPT-5, những trải nghiệm và phân tích của tác giả trong các tình huống và quyết định của TiDB để có được như ngày hôm nay khá là đáng suy nghĩ.

Apache Iceberg: An Architectural Look Under the Covers

Bài viết này của Dremio nói về Apache Iceberg và kiến trúc của định dạng bảng (table format) này như thế nào. Bài viết mở đầu nói về những giới hạn của định dạng bảng truyền thống như Hive table format và lý do tại sao Iceberg table format được ra đời.

Apache Iceberg được giới thiệu như một định dạng bảng mới, tối ưu cho môi trường data lake lớn, với kiến trúc gồm 3 phần chính là: catalog, metadata (gồm manifest và snapshot) và data. Phần catalog lưu trữ snapshot metadata hiện tại, còn phần metadata thì lưu trữ manifest list và manifest file để theo dõi data file của phần data. Khi thực hiện các thao tác như tạo bảng, ghi (insert), cập nhật (merge/upsert), hoặc truy vấn (select), Iceberg sẽ quản lý các snapshot này một cách atomic, đảm bảo tính nhất quán và khả năng mở rộng, đồng thời hỗ trợ tính năng partition ẩn (hidden partitioning) giúp truy vấn hiệu quả hơn.

Trong bài viết, tác giả cũng nêu rõ hơn những phần này hoạt động như thế nào, và uy điểm nhược điểm của định dạng bảng mới này so với các công nghệ cũ.

Introducing Zelos: A ZooKeeper API leveraging Delos

Meta trước đây chủ yếu dùng Apache ZooKeeper để quản lý các primitives phân tán như khóa (locks), semaphore, … Tuy nhiên, khi quy mô tăng lên, ZooKeeper ngày càng khó mở rộng và chỉnh sửa, đa phần là do cách Zookeeper tích hợp chặt chẽ giữa logic giao thức đồng thuận và logic ứng dụng. Điều này dẫn đến việc Meta quyết định tạo ra một phiên bản mô-đun, linh hoạt và hiệu suất cao hơn: Zelos, xây dựng lại API ZooKeeper trên nền tảng Delos nội bộ.

Bài viết này nói về cách Meta xây dựng hệ thống này và cách họ migrate từ ZooKeeper sang Zelos như thế nào để không gây downtime cho client nhiều nhất có thể. Đồng thời, tác giả cũng nêu lên những thử thách trong việc xây dựng Zelos để thay thế ZooKeeper hoàn toàn trong Meta như thế nào.

Chúng tôi bàn đủ thứ từ định hướng của công ty, làn sóng AI, đến câu chuyện phát triển sự nghiệp. Nhưng có một chủ đề khiến tôi nhớ mãi: “Như thế nào là một lãnh đạo tốt?”

Anh nói một câu rất đáng suy ngẫm:

“Một người lãnh đạo, hay một người sếp, không nhất thiết phải là một người tốt,
nhưng nên là một người công bằng.”

Câu nói đó khiến tôi suy nghĩ rất nhiều. Liệu mình đã là một người sếp “công bằng” hay chưa?

Khái niệm “tốt” của mỗi người vốn khác nhau. Nếu một người sếp hơi thiên vị ta một chút, ta có thể thấy họ “tốt” với ta. Nhưng điều đó chưa chắc đã tốt cho cả tập thể.

Có lẽ, cái khó nhất khi làm lãnh đạo không phải là làm người tốt, mà là đủ bản lĩnh để công bằng - để khen, phê bình, hay đưa ra quyết định mà vẫn giữ được sự cân bằng giữa cảm xúc và lý trí.

— LPV —

Thinking like a data engineer

Tác giả bắt đầu bài viết bằng một suy nghĩ rất thật: nhiều người cho rằng trở thành kỹ sư dữ liệu là phải thành thạo hàng loạt công cụ, từ Hadoop, Spark, tối ưu SQL cho đến xử lý phân tán.
Nhưng với anh, hành trình đó dần trở thành một điều khác: học cách tư duy.

Bài viết sau kể lại quá trình tác giả nhận ra rằng, thử thách lớn nhất trong nghề không nằm ở kỹ thuật, mà ở việc học cách nhìn thấy khuôn mẫu trong hỗn loạn, kết nối hệ thống với hành vi con người, và cân bằng giữa sự đơn giản và quy mô.

Điều thú vị là, anh không học được điều này qua khóa học hay chứng chỉ nào,
mà qua bốn người cố vấn, ở bốn giai đoạn khác nhau của cuộc đời - những người đã định hình cách anh tiếp cận kỹ thuật, lãnh đạo, và cả cuộc sống.

Đây không phải là một hướng dẫn kỹ thuật, mà là một bản đồ về tư duy, về cách con người và trải nghiệm có thể thay đổi cách ta nhìn về nghề dữ liệu.

Scaling Engineering Teams: Lessons from Google, Facebook, and Netflix

Trong bài viết sau là những bài học từ các Big Tech về cách làm thế nào để xây dựng một đội ngũ kỹ sư, từ 10, 100 cho tới hàng ngàn nhân viên. Những framework, metrics, công cụ phù hợp có thể giúp bạn nuôi dạy những đứa trẻ mà không cần lo bị chúng đốt nhà lúc 3h sáng.

Ví dụ Google OKR và quy tắc 70%. Nếu bạn đạt 100% OKR, có nghĩa là bạn chưa đủ tham vọng. Mức OKR lý tưởng là khoảng 70%. Thực hiện OKR hàng quý cho team, với khoảng 3-5 mục tiêu, mỗi mục tiêu có 2-4 key result có thể đo đạc được.

The Trap of Excessive AI Use

Trong bài viết này, tác giả chia sẻ một số quan điểm về việc lạm dụng AI quá mức. Trong bối cảnh các công cụ AI, vibe coding đang dần trở nên phổ biến đối với các kỹ sư phần mềm. Thì có lẽ chúng ta cũng cần nhìn lại một chút về cách thức sử dụng các công cụ này như thế nào. Có lẽ cách sử dụng AI như thế nào không khó, mà cái khó là biết khi nào thì nên sử dụng AI.

How Google, Amazon and CrowStrike broke millions of systems

Các công ty lớn như Google, Amazon đang control phần lớn internet. Và khi hệ thống xảy ra vấn đề, dù là 1 trục trặc nhỏ cũng khiến 1 phần thế giới bị ảnh hưởng.

Trong bài viết sau tác giả đã tóm tắt lại một số sự cố như thế, từ nguyên nhân xảy ra, và cách đội ngũ kỹ sư đã khắc phục như thế nào. Mời các bạn cùng đọc nhé.

Tech World With Milan Newsletter

How Google, Amazon, and CrowdStrike broke millions of systems

Three companies control most of the internet. When they break, millions of systems fail at once…

Read more

6 months ago · 16 likes · 1 comment · Dr Milan Milanović

Trong số tiếp theo, tôi xin phép dành một chút thời gian để chia sẻ với các bạn đọc về quá trình hơn 5 năm làm Newsletter. Quá trình này đã mang lại những thay đổi nào đối với cá nhân tôi, cũng như với nhiều thành viên khác của Grokking. Chúc các bạn một buổi tối cuối tuần vui vẻ nhé.

Grokking Newsletter đã trở lại, sau một khoảng thời gian tạm lắng để suy ngẫm và tìm kiếm định hướng nội dung mới. Trong các số newsletter sắp tới của Grokking, bạn sẽ thấy cấu trúc nội dung thay đổi nhiều. Nội dung của newsletter sẽ không phân mục quá rõ ràng hoặc chỉ có bài viết hay như trước đây, mà sẽ mang tính chất chia sẻ góc nhìn, thảo luận nhiều hơn.

Chúng tôi mong đây không chỉ là newsletter, mà là một cuộc trò chuyện - nơi bạn tìm thấy cảm hứng và những góc nhìn riêng cho hành trình của mình. Các bạn có nhu cầu thảo luận, hoặc muốn đóng góp ý kiến của mình đến bạn đọc Grokking Newsletter, có thể gửi nội dung đến cho bọn mình nhé.

Bàn chuyện System Design thời AI: Khi “biết tuốt” không bằng “hiểu sâu”

Dạo này lướt mạng, thấy các bạn khoe xài Copilot, ChatGPT generate code phà phà, thậm chí còn hỏi nó “design cho tao một cái hệ thống giống Twitter”. Nó trả lời vanh vách, nhìn có vẻ ngon lành. Nhưng đây chính là cái bẫy nguy hiểm nhất.

Theo quan sát của bọn mình, AI đang dần thay thế các task entry-level. Một bạn junior giờ có thể dùng AI để fix bug, viết unit test, hay viết một đoạn code CRUD đơn giản nhanh gấp mấy lần trước đây. Nhưng việc “design một hệ thống” lại là chuyện hoàn toàn khác.

Cái hệ thống mà AI “vẽ” ra cho bạn, bạn có thật sự hiểu các trade-offs đằng sau không? Vì sao chỗ này lại dùng message queue thay vì gọi API trực tiếp? Vì sao lại chọn Cassandra chứ không phải PostgreSQL? Khi bị hỏi vặn lại, liệu có im lặng rồi sấp mặt như mấy em sinh viên chạy model mà không biết vì sao không dùng XGBoost không?

Trước đây, để học về hệ thống lớn, các bạn phải cày cuốc, đọc cả chục cái paper, mò mẫm code của các bậc tiền bối. Giờ AI nó tóm tắt lại cho bạn trong 3 nốt nhạc. Nhưng sự tiện lợi này lại lấy đi cái cốt lõi: quá trình tư duy và đào sâu để hiểu tận gốc rễ vấn đề. AI nâng productivity của người có kinh nghiệm lên rất nhanh, nhưng nó cũng có thể tạo ra một thế hệ kỹ sư “học mẹo”, chỉ biết “xài” mà không “hiểu”.

Vậy các bạn trẻ (và cả không trẻ nhưng skillset vẫn entry-level) cần làm gì? Câu trả lời muôn thuở: quay về với kiến thức nền tảng. Phải hiểu “domain knowledge” của ngành mình thật chắc.

Một vài bài viết và paper ví dụ minh họa cho việc hiểu và đọc sâu:

• Một bài rất đáng đọc đến từ Uber: “Building Reliable Reprocessing for Critical Datasets at Scale”

  • Vì sao phải đọc? Hãy tưởng tượng chỉ một bug nhỏ cũng có thể khiến hàng terabyte dữ liệu bị tính sai - ảnh hưởng đến thanh toán cho tài xế, hay thậm chí cả báo cáo tài chính. Trong bài viết này, Uber chia sẻ cách họ xây dựng một hệ thống “sửa sai” tự động và đủ tin cậy để vận hành ở quy mô khổng lồ - mà không làm sập cả công ty. Đọc để thấy họ phải đánh đổi những gì, và vì sao đôi khi, những giải pháp có sẵn lại không thể “vá” được vấn đề thật sự.

• Từ thực tế của Netflix: “Scaling Time Series Data Storage at Netflix“

  • Vì sao phải đọc? Ai cũng biết Netflix có hệ thống observability kinh khủng để theo dõi sức khỏe hệ thống. Bài viết này đào sâu vào một góc nhỏ nhưng cực kỳ quan trọng: họ đã lưu trữ và xử lý dữ liệu dạng chuỗi thời gian (time series) như thế nào ở quy mô hàng petabyte. Nó là một case study thực tế về việc “build vs. buy” (tự xây hay mua), những giới hạn của các giải pháp hiện có và cách họ tự xây một hệ thống tên là Atlas Telemetry Platform để giải quyết bài toán của riêng mình. Đây là minh chứng cho việc ở quy mô lớn, không có giải pháp “một kích cỡ cho tất cả”.

• Kinh điển về Trade-offs: “CAP Theorem: Two Decades Later” của Eric Brewer

  • Vì sao phải đọc? Hầu hết các hệ thống phân tán đều phải đánh đổi giữa Consistency, Availability, và Partition Tolerance. Bài viết này, từ chính cha đẻ của định lý CAP, sẽ cho bạn thấy định lý này không phải là “chọn 2 trong 3” một cách cứng nhắc, mà là một chuỗi các trade-offs tinh vi hơn nhiều. Hiểu được nó, bạn sẽ có cái nhìn thực tế hơn khi thiết kế hệ thống.

• Kinh điển về NoSQL: “Amazon’s Dynamo: A Highly Available Key-value Store”

  • Vì sao phải đọc? Cái paper này là nền móng cho cả một thế hệ database NoSQL sau này, bao gồm cả DynamoDB của AWS. Đọc nó để hiểu về eventual consistency, sharding, a “gossip” protocol... Đây là kiến thức nền tảng giúp bạn không bị ngợp khi làm việc với các hệ thống cloud-native hiện đại.

Hay nói cách khác, để thích nghi với thời đại AI này, các bạn cần làm gì?

1. Đừng để AI làm thay bạn trong việc suy nghĩ. Hãy coi nó là một trợ lý siêu nhanh để xử mấy việc tay chân - còn phần quan trọng nhất: tư duy về kiến trúc, đánh đổi, và quyết định thiết kế - vẫn là việc của bạn.

2. Đầu tư vào nền tảng. Những khái niệm cốt lõi như định lý CAP, các kiểu dữ liệu, hay thuật toán đồng thuận không bao giờ lỗi thời. Công nghệ thay đổi, nhưng nguyên lý thì ở đó.

3. Học từ thực tế. Đọc engineering blog của các công ty lớn - ví dụ những case study như Uber hay Netflix - để thấy họ đã vấp ngã thế nào và làm sao đứng dậy. Những bài học đó giá trị hơn mọi “hack” ngắn hạn.

4. Luôn hỏi “Tại sao?”. Đừng chấp nhận một giải pháp chỉ vì AI gợi ý hay vì nó đang là trend. Đào sâu đủ để hiểu rõ cái giá phải trả (trade-offs) - trước khi bạn bấm deploy.

Thị trường lao động sẽ ngày càng khắc nghiệt. Những kỹ năng mà bạn có thể học trong 3 phút trên mạng sẽ nhanh chóng bị thay thế. Chỉ có kiến thức nền tảng và khả năng tư duy sâu mới giúp bạn đứng vững. Đừng để mình trở thành một kỹ sư “entry-level” dù đã đi làm nhiều năm.

P/S: bài viết này được tạo ra với sự hỗ trợ của AI, bạn nghĩ AI đóng góp cho bài viết trên bao nhiêu phần trăm? :)

Phỏng vấn thời AI

(chia sẻ bởi bạn đọc n^4)

Chủ đề có nên cho phép ứng viên sử dụng AI trong quá trình phỏng vấn hay không là một câu hỏi thường được đặt ra trong thời gian gần đây. Vừa rồi, trong quá trình phỏng vấn, bản thân mình cũng đã thử đổi cách tiếp cận một tí, cho phép ứng viên có thể dùng AI thoải mái trong quá trình phỏng vấn, đặc biệt là coding interview, xem kết quả như thế nào.

Dĩ nhiên, đề bài đặt ra cũng thay đổi một tí. Thay vì đặt ra một đề bài đóng, yêu cầu ứng viên hiện thực hóa một thuật toán hoặc một component cụ thể, mình đặt ra đề bài là yêu cầu ứng viên xây dựng một chương trình nhằm giúp minh họa/giả lập một vấn đề gì đó. Và ứng viên có thể toàn quyền sử dụng AI, lựa chọn công nghệ, hình thức triển khai, …

So sánh giữa hai ứng viên có cách tiếp cận khác nhau.

Ứng viên A cũng có đặt ra 1-2 câu hỏi để làm rõ chương trình, nhưng sau đó sẽ dùng ngay đề bài để prompt “Hãy xây dựng chương trình để minh họa xxx / yyy”, … Sau khi AI viết ra chương trình, bạn chạy thử rồi bắt đầu đọc code xem AI implement như thế nào. Tuy nhiên, code AI viết ra lại hơi phức tạp và bạn hoàn toàn không giải thích được xem thuật toán hoạt động như thế nào. Dĩ nhiên, việc thời gian bị giới hạn cùng áp lực phỏng vấn cũng là một nhân tố làm cho bạn không trả lời được. Tuy nhiên, cách tiếp cận này rõ ràng không phù hợp trong một buổi phỏng vấn coding.

Ứng viên B có cách tiếp cận khác. Bạn sẽ phân tích coi là nên minh họa vấn đề/thuật toán này thế nào, bạn sẽ hỏi có cần UI hay không, nên scope down thành vài trường hợp cụ thể hơn, … Sau đó, bạn bắt đầu phân tích về cấu trúc dữ liệu cần thiết để minh họa thuật toán này, tiếp theo là bạn bắt đầu mô tả cách tiếp cận. Cuối cùng, bạn sử dụng AI để yêu cầu implement thuật toán để giải quyết đề bài. Đối với ứng viên này, thuật toán chạy ra vẫn không hoàn toàn đúng, nhưng bạn có thể giải thích và debug xem từng bước thuật toán hoạt động như thế nào.

Nhìn chung, dựa vào trải nghiệm cá nhân thì phỏng vấn có hay không có AI vẫn không thay đổi quá nhiều như mình nghĩ ban đầu. Việc ứng viên có kiến thức nền tảng hoặc kỹ năng tốt vẫn sẽ được biểu hiện rõ. Nên thay vì cấm dùng AI khi phỏng vấn, thì việc cho phép và khuyến khích dùng có khi lại làm cho quá trình phỏng vấn được tốt hơn.

Share

Có lẽ điều tuyệt nhất khi làm kỹ sư không phải là viết ra dòng code hoàn hảo, mà là hiểu vì sao mình viết như thế.

Cảm ơn bạn đã đọc đến đây - mong rằng Grokking sẽ luôn là nơi bạn tìm thấy chút cảm hứng giữa những ngày đầy deadline và release.

You Are Not Google

(quangle80)

Là một kỹ sư phần mềm, chúng ta luôn mong muốn áp dụng những công nghệ tối tân, tốt nhất khi bắt tay vào xây dựng một hệ thống. Nhưng chậm lại một nhịp, liệu các công nghệ mà bạn dự định áp dụng (ví dụ như MapReduce, Kafka học từ các Big Tech Google, LinkedIn, v.v…) có thực sự phù hợp với use-case của bạn.

Với góc nhìn “don’t cargo cult” (không tôn sùng bất kì công nghệ nào), tác giả Oz Nova muốn chỉ ra các bước đánh giá UNPHAT để giúp bạn đọc đưa ra quyết định tốt hơn:

• Understand the problem: Hiểu vấn đề mà hệ thống đang gặp phải

• Numerate multiple candidate solutions: Đánh giá nhiều giải pháp chứ không chọn theo sở thích

• Read the Paper: sau khi chọn được giải pháp phù hợp, nghiên cứu thêm các paper, document của công nghệ, giải pháp đã chọn.

• Determine the Historical context: đánh giá công nghệ này sinh ra để giải quyết bài toán gì cho doanh nghiệp (Ví dụ LinkedIn xây dựng Kafka để giải quyết hàng tỷ events 1 ngày, chục triệu messages 1 giây, liệu doanh nghiệp của chúng ta có cần thiết phải áp dụng Kafka hay chỉ cần sử dụng công nghệ nào khác)

• Weigh Advantages against disadvantages: Cân nhắc ưu và nhược điểm của công nghệ

• Think!: cuối cùng tác giả vẫn lặp lại tiêu chí khuyên bạn đọc hãy tỉnh táo và suy ngẫm khách quan xem giải pháp này phù hợp với vấn đề mà bạn đang gặp phải như thế nào

Cùng với một loạt những phân tích cụ thể với các use-case tại Amazon, LinkedIn, mời bạn đọc cùng tham khảo chi tiết tại bài viết.

Protecting Reddit Users in Real Time at Scale

(Steven.do87)

Reddit là một cộng đồng mạng xã hội với hơn 57 triệu người dùng tương tác, đăng tải nội dung và trò chuyện với nhau mỗi ngày. Việc giữ cho nền tảng hoạt động an toàn, ổn định và vẫn có thể kiểm soát một lượng lớn nội dung đăng tải là một thách thức đối với đội ngũ kỹ sư tại Reddit nhằm ngăn chặn, phát hiện và hành động đối với nội dung đăng tải vi phạm chính sách theo thời gian thực.

Vào năm 2016, Reddit đã phát triển một bộ quy tắc (Rule-engine) với tên gọi , Rule-Executor-V1 (REV1), để hạn chế nội dung vi phạm chính sách đăng tải trên nền tảng Reddit theo thời gian thực. Ở cấp độ quản lý, REV1 cho phép nhóm điều hành Hoạt động An toàn của Reddit dễ dàng khởi chạy các quy tắc thực thi áp dụng cho các luồng sự kiện phát sinh trên Reddit, chẳng hạn như khi người dùng tạo bài đăng hoặc nhận xét. Với tiêu chí quan trọng nhất là phải loại bỏ sự phức tạp về kỹ thuật để người dùng cuối có thể tập trung vào việc xây dựng quy tắc. Mặc dù REV1 đã chứng minh hiệu quả trong một khoảng thời gian hoạt động, tuy nhiên theo thời gian dần phát sinh một vài vấn đề mà đội ngũ kỹ sư tại Reddit muốn cải thiện như:

• Chạy trên cơ sở hạ tầng kế thừa của các phiên bản EC2 raw thay vì Kubernetes (K8s) vốn đã được áp dụng triển khai làm nền tảng hoạt động cho các dịch vụ hiện tại của Reddit.

• Mỗi quy tắc chạy như một quy trình riêng biệt trong một node REV1, dẫn đến cần phải mở rộng theo chiều dọc (vertical scaling) khi nhiều quy tắc được đưa ra, điều này hóa ra là tốn kém và thiếu ổn định.

• Chạy trên Python 2.7, một phiên bản Python đã lỗi thời.

• Lịch sử thay đổi của một quy tắc rất khó hiển thị vì các quy tắc không được kiểm soát phiên bản.

• Thiếu môi trường thử nghiệm (staging) trong đó các quy tắc có thể được chạy thử nghiệm trên dữ liệu thực tế trên môi trường product mà không ảnh hưởng đến người dùng thực tế.

Năm 2021, các kỹ sư tại Reddit đã phát triển một cơ sở hạ tầng streaming mới, với tên gọi là Snooron, được xây dựng dựa trên Flink Stateful Functions để hiện đại hóa kiến trúc của REV1 cũng như hỗ trợ số lượng ngày càng tăng các nhu cầu đảm bảo đáp ứng yêu cầu xử lý luồng dữ liệu. Cùng tham khảo phương án kỹ thuật mà các kỹ sư tại Reddit đã áp dụng tại bài viết.

Designing & Building Metrics

(n^4)

Metric là một trong các khái niệm quan trọng Business Intelligent. Giống như con người có khỏe mạnh hay không có thể được phản ánh thông qua nhiều chỉ số như huyết áp, nhịp tim, đường huyết, oxy, ... Một công ty có phát triển tốt hay không cũng sẽ được thể hiện thông qua những chỉ số đo lường (metric).

Trong thời đại Big data ngày nay, việc tính toán và tổ chức metric cũng sẽ càng ngày càng phức tạp khi quy mô công ty và thị trường ngày càng lớn. Nhiều dữ liệu, nhiều chỉ số phát sinh, vậy thì nên tổ chức và thiết kế hệ thống metrics này như thế nào để giúp trả lời được những câu hỏi nền tảng xoay quanh hoạt động doanh nghiệp một cách nhanh chóng và hiệu quả?

Trong bài techtalk này, chúng ta sẽ cùng tìm hiểu cách các nhóm dữ liệu có thể hỗ trợ tốt nhất cho vòng đời của metrics từ đầu đến cuối:

1. Thiết kế các metrics hữu ích như một phần của cây metrics.

2. Phát triển các metrics này dựa trên hợp đồng dữ liệu tiêu chuẩn và ổn định.

3. Vận hành các metrics để thúc đẩy giá trị.

💭Góc bạn đọc- Một tuần làm việc của EM (p5)

Thứ năm - OKR và lối tư duy impact-oriented

Một hoạt động khác cũng hay diễn ra trong ngày thứ 5 là họp cross platform và OKR review.

Team mình đang phụ trách đang phát triển và vận hành một platform nội bộ. Trong công ty mình có khá nhiều platform như vậy, mỗi platform sẽ chịu trách nhiệm giải quyết một bài toán nào đó cho người dùng nội bộ như gửi message, tạo campaign, tạo data pipeline, ... Một số team platform có liên quan với nhau sẽ gom lại thành một tổ chức lớn hơn. Làm sao để các platform này planning tốt với nhau?

Đối với từng platform thì mỗi 6 tháng, platform đó sẽ phải tự review và đặt ra OKR cho platform của mình để định hình những thứ ưu tiên mà platform muốn xây dựng và đạt được trong 6 tháng tới. OKR là viết tắt cho Objective-Key Result. Việc lập kế hoạch sử dụng OKR thay vì “danh sách tính năng” sẽ giúp platform tập trung vào khía cạnh impact hơn là output của những thứ team platform làm trong 6 tháng tới. Một ví dụ về sự khác biệt này:

• Platform A, theo mô hình tính năng, sẽ plan là trong 6 tháng tới sẽ phát triển tính năng cho người dùng schedule những campaign A/B testing song song thay vì tuần tự.

• Nhưng khi plan bằng OKR, team platform A sẽ đặt ra mục tiêu là làm sao để tăng được lượng A/B testing campaign diễn ra trong 1 tháng từ 8 campaign lên đến 40 campaign. Key result lúc này là tỉ lệ campaign thực hiện tăng lên 500%. Và giải pháp là xây dựng tính năng như đã nói ở trên.

Việc planning theo OKR như thế này sẽ mang đến nhiều sự thay đổi về mặt tư duy:

• Team tập trung vào impact và problem statement hơn. Tránh tình trạng phát triển nhiều tính năng hay, nhưng hóa ra lại không giải quyết được vấn đề cần giải quyết.

• Công nghệ đóng vai trò công cụ. Nếu trong quá trình planning team tìm ra được giải pháp khác để đạt được cùng mục tiêu kể trên thì team sẽ cân nhắc thay đổi phương án thay vì bám vào solution ban đầu. Quan trọng là mục tiêu và problem ko đổi, solution có thể đổi. Giống ví dụ trên, nếu team thay đổi góc nhìn, thay vì xây dựng tính năng mới thì lại tìm cách điều chỉnh thiết kế để mỗi campaign A/B testing chạy ngắn hơn chẳng hạn.

Giữa các platform có thể có joint-OKR, gọi là mục tiêu chung cần sự cộng tác của nhiều team. Đặt ra joint-OKR này là một cách để các team commit thời gian và có sự thỏa hiệp tương ứng.

Thứ sáu - Growth day

Công việc hàng ngày của một bạn kỹ sư phần mềm có thể chia thành hai nhóm chính sau:

- Xây dựng phần mềm

- Vận hành phần mềm

Xây dựng phần mềm, bản chất là sử dụng kiến thức và kỹ năng lập trình để tạo ra những dòng mã giúp giải quyết một vấn đề nào đó có trong tổ chức. Vấn đề đó có thể là vấn đề thiên về hướng business ví dụ như xây dựng một tính năng trên app giúp định hướng người dùng, hoặc một vấn đề về vận hành hệ thống ví dụ như xây dựng thuật toán điều hướng background job để tăng throughput....

Để tạo ra được phần mềm đúng thì phải hiểu bản chất nhu cầu tại sao lại cần phần mềm đó để từ đó đưa ra được giải pháp phù hợp. Và để hiểu bản chất của vấn đề mà bản thân đang cần giải quyết, người kỹ sư cần có một lượng kiến thức nhất định trong lĩnh vực tương ứng. Từ đó sẽ phát sinh nhu cầu học hỏi thêm về lĩnh vực mà bản thân đang làm. Ví dụ như làm một hệ thống thiên về marketing thì cũng cần bổ sung kiến thức về marketing để có thể hiểu rõ hơn người dùng và xây phần mềm hữu ích hơn.

Vận hành phần mềm, là theo dõi, kiểm tra, giám sát phần mềm mà bản thân xây dựng để có những can thiệp cần thiết, đảm bảo hệ thống vận hành được thông suốt. Giống như một người kỹ sư điện có thể tham gia thiết kế hệ thống điện trong một tòa nhà, họ cũng có thể tham gia vào quá trình bảo trì, kiểm tra để đảm bảo không có sự cố điện xảy ra.

Công việc hàng ngày của software engineer là phải ra quyết định rất nhiều. Từ những quyết định cơ bản từ việc chọn cấu trúc dữ liệu nào, thiết kế model như thế nào, dùng while hay dùng for, … đến những quyết định dần lớn hơn như phải thiết kế hệ thống gồm những thành phần nào, phải triển khai thành phần nào trước nào sau, … cho đến những quyết định mang tính chiến lược hơn nữa như nên thay đổi những platform nào, những platform nào nên xóa bỏ, những platform nào cần xây mới, … Cấp bậc càng cao trong tổ chức, dù là IC hay manager thì việc ra quyết định càng khó và phức tạp. Tương ứng với việc đó là chi phí phải bỏ ra cho mỗi sai lầm cũng lớn hơn.

Tổng hợp cả ba tình huống trên lại, theo mình người kỹ sư cần không ngừng học hỏi về chuyên môn kỹ thuật, về kiến thức domain của lĩnh vực đang làm, kỹ năng mềm như ra quyết định, ... để hoàn thiện mình hơn. Và ngày thứ 6 sẽ tạm gọi là ngày growth day để bản thân và team có thể dành thêm thời gian để đọc tài liệu nội bộ, post mortem, wiki, product design docs, ...

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Rotate Image

Cho mảng 2 chiều n x n. Thực hiện xoay mảng này 90 độ theo chiều kim đồng hồ mà không sử dụng mảng phụ.

Ví dụ:

• Input: matrix = [[1,2,3],[4,5,6],[7,8,9]]

• Output: [[7,4,1],[8,5,2],[9,6,3]]

Lời giải tuần trước: Split Array Largest Sum

Gọi f(i,j) là giá trị tối ưu thỏa mãn đề bài khi chia mảng con từ vị trí `i` đến cuối mảng thành `j` phần.

Sử dụng đệ quy để tính toán các giá trị này bằng cách thử tất cả các khả năng chia mảng con, tìm giá trị tối ưu nhất sao cho tổng lớn nhất trong số các mảng con là nhỏ nhất khi chia mảng con bắt đầu từ i thành j phần.

Sau đó lưu trữ các giá trị tối ưu đã tính trước đó để tránh tính toán lặp lại trong các lần gọi đệ quy sau. (kỹ thuật này gọi là memoization, thường sử dụng để tối ưu một giải thuật đệ quy thành giải thuật quy hoạch động top down).

Giải thuật cụ thể mời bạn đọc tham khảo lời giải bằng bằng ngôn ngữ Java sau đây.

class Solution {
    public int splitArray(int[] nums, int m) {
        int n = nums.length;
        int[][] memo = new int[n][m + 1];

        for (int i = 0; i < n; i++) {
            Arrays.fill(memo[i], -1);
        }

        return splitArrayHelper(nums, 0, m, memo);
    }

    private int splitArrayHelper(int[] nums, int i, int j, int[][] memo) {
        if (j == 1) { // Nếu j = 1, trả về tổng của mảng con đó
            int sum = 0;
            for (int k = i; k < nums.length; k++) {
                sum += nums[k];
            }
            return sum;
        }

        if (memo[i][j] != -1) { // Trả về giá trị tối ưu đã tính toán trước đó
            return memo[i][j];
        }

        int minMaxSum = Integer.MAX_VALUE;

        int currentSum = 0;
        for (int k = i; k <= nums.length - j; k++) {
            // Tính toán giá trị currentSum cho cách chia hiện tại
            currentSum += nums[k];
            // Gọi đệ quy cho cách chia mảng tiếp theo
            int maxSumInPartition = Math.max(currentSum, splitArrayHelper(nums, k+1, j-1, memo));
            // Trả về giá trị tối ưu nhất (tổng lớn nhất trong số các mảng con là nhỏ nhất khi chia mảng con bắt đầu từ i thành j phần)
            minMaxSum = Math.min(minMaxSum, maxSumInPartition);
        }

        memo[i][j] = minMaxSum;
        return minMaxSum;
    }
}

Độ phức tạp thuật toán của lời giải trên là O(n^2 m)*, trong đó:

• n là số lượng phần tử trong mảng nums.

• m là số lượng phân đoạn cần tạo.

Trong hàm splitArrayHelper, chúng ta duyệt qua tất cả các vị trí có thể để chia mảng con và gọi đệ quy cho từng trường hợp. Do đó, chúng ta có O(n) lần lặp, và trong mỗi lần lặp, chúng ta thực hiện O(n) lần đệ quy (vì trong trường hợp xấu nhất, có thể phải chia mảng con từ i đến n). Ngoài ra, chúng ta cũng có O(m) mảng con cần tạo. Vì vậy, tổng độ phức tạp là O(n^2 * m).

Quotes

• Visual Studio for Mac Retirement Announcement

• Introducing ChatGPT Enterprise

• Introducing Code Llama, a state-of-the-art large language model for coding

📰Những bài viết hay

Why We Killed Our End-to-End Test Suite

(by lpv)

Trước đây, tại Nubank sử dụng End-to-End test để tìm ra những vấn đề trong một kiến trúc microservices trong môi trường staging. End-to-End test có nghĩa là kích hoạt một trong các đầu vào của hệ thống (bằng cách sử dụng HTTP request hoặc tạo một message asynchronous tới một topic). Khi đó, hệ thống thường sẽ thực hiện một vài tương tác giữa các thành phần thông qua Http request hoặc những message asynchronous khác v.v... Tính hợp lệ của các tương tác này có thể được kiểm tra bằng cách kiểm tra các kết quả đầu ra cụ thể.

Tuy nhiên cách làm này có rất nhiều nhược điểm mặc dù hầu hết các công ty vẫn tin rằng E2E Testing là cách tốt nhất để phát hiện lỗi, tuy nhiên lại khiến cho quá trình delivery diễn ra càng ngày càng chậm.

- Những thay đổi manually trên staging gây ảnh hưởng tới test data và việc phải maintain để đảm bảo môi trường clean trở thành 1 vấn đề.

- Chậm trễ trong việc delivery.

- Ít bug được phát hiện trên staging. Một thử nghiệm cho thấy với hơn 1000 lần chạy, chỉ có 42 lần chạy thất bại và 1 bug được phát hiện.

- Kém hiệu quả, bug vẫn thường xuyên được tìm thấy trên production.

Vậy nếu điều này tiếp tục diễn ra, chúng ta sẽ mất nhiều thời gian hơn trong quá trình CI/CD. Mọi người sẽ thực hiện các đợt commit với nhiều thay đổi hơn và mất nhiều thời gian hơn để triển khai, đồng thời vẫn có thể xảy ra lỗi trên production. Tình huống tương tự cũng xảy ra tại nhiều công ty khác trong quá trình thực hiện E2E Test.

Từ đó tại Nubank đã sử dụng Consumer Driven Contract (CDC) testing để thay thế E2E Test. CDC Testing cho phép mô tả sự tương tác giữa các dịch vụ thông qua những kỳ vọng input/output mà chúng đáp ứng. CDC cho phép các team có thể hoạt động một cách độc lập với nhau, đòi hỏi ít sự phối hợp cũng như cơ sở hạ tầng hơn.

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Split Array Largest Sum

Cho một mảng số nguyên không âm nums và một số nguyên dương k, hãy chia mảng nums thành k mảng con (không rỗng) sao cho ta thu được những mảng con với tổng lớn nhất trong số các mảng con là nhỏ nhất. Hãy trả lại tổng lớn nhất mà ta có thể thu được.

Ví dụ:

Input: nums = [7,2,5,10,8], k = 2

Output: 18

Giải thích: Ta có 4 cách để chia mảng nums thành 2 mảng con như sau:

Cách 1, ta có [7] và [2,5,10,8], với tổng lớn nhất trong số các mảng con là 25.

Cách 2, ta có [7,2] và [5,10,8], với tổng lớn nhất trong số các mảng con là 23.

Cách 3, ta có [7,2,5] và [10,8], với tổng lớn nhất trong số các mảng con là 18.

Cách 4, ta có [7,2,5,10] và [8], với tổng lớn nhất trong số các mảng con là 24.

Như vậy, cách chia tốt nhất là chia thành hai mảng con [7,2,5] và [10,8], với tổng lớn nhất là 18.

Ứng dụng của thuật toán này?

Hãy tưởng tượng bạn đang quản lý một đội xe giao hàng có nTrucks chiếc xe cho một công ty logistics. Bạn có một danh sách các đơn đặt hàng được biểu thị dưới dạng một mảng số nguyên orderWeights, trong đó mỗi phần tử đại diện cho trọng lượng của một đơn đặt hàng tính bằng kilogram. Mục tiêu của bạn là chia các đơn hàng này cho các xe trong đội giao hàng, sao cho trọng lượng tối đa mà bất kỳ xe giao hàng nào mang là tối thiểu. Trong tình huống này:

• orderWeights tương ứng với trọng lượng của các đơn đặt hàng khác nhau cần được giao hàng.

• nTrucks là số lượng xe bạn có trong đội giao hàng.

Nhiệm vụ của bạn là tìm cách phân công đơn đặt hàng vào các lộ trình một cách tối ưu, đảm bảo rằng không có xe nào bị quá tải và trọng lượng được mang bởi xe nặng nhất là thấp nhất có thể. Trọng lượng tối đa được giảm xuống trên bất kỳ xe nào đại diện cho hiệu suất của hoạt động giao hàng của bạn.

Lời giải tuần trước: Minimum Number of People to Teach

Do đề bài chỉ cho phép ta dạy một ngôn ngữ, nên ta có thể tìm ngôn ngữ thoả mãn điều kiện đề bài bằng cách thử dạy từng ngôn ngữ rồi chọn ngôn ngữ cần ít số người học nhất. Ta thực hiện giải thuật trên theo các bước như sau:

1. Tìm những cặp không thể giao tiếp với nhau

2. Thử dạy từng ngôn ngữ cho các cặp không thể giao tiếp với nhau để tìm ra số người học nhỏ nhất

‌Giải thuật được thực hiện như sau:

class Solution {
    public int minimumTeachings(int n, int[][] languages, int[][] friendships) {
        // map of user and speakable languages
        Map<Integer, Set<Integer>> userLanguages = new HashMap<>();
        for (int i = 0; i < languages.length; i++) {
            userLanguages.put(i + 1, new HashSet<>());
            for (int l : languages[i]) {
                userLanguages.get(i + 1).add(l);
            }
        }

        // find the friendships w/o common language
        boolean[] canCommunicate = new boolean[friendships.length];
        for (int l = 1; l <= n; l++) {
            for (int i = 0; i < friendships.length; i++) {
                if (userLanguages.get(friendships[i][0]).contains(l) &&
                    userLanguages.get(friendships[i][1]).contains(l)) {
                    canCommunicate[i] = true;
                }
            }
        }

        // find language that can be taught to min users
        int ans = 500; // maximum of number of users is 500
        for (int l = 1; l <= n; l++) {
            Set<Integer> countUsersToTeach = new HashSet<>();

            for (int i = 0; i < friendships.length; i++) {
                int u1 = friendships[i][0];
                int u2 = friendships[i][1];
                if (canCommunicate[i]) {
                    continue;
                }
                if (!userLanguages.get(u1).contains(l)) {
                    countUsersToTeach.add(u1);
                }
                if (!userLanguages.get(u2).contains(l)) {
                    countUsersToTeach.add(u2);
                }
            }
            ans = Math.min(ans, countUsersToTeach.size());
        }
        return ans;
    }
}

Độ phức tạp về thời gian (time complexity) của giải thuật là O(m*n), trong đó m là số người, n là số ngôn ngữ.

‌Ngoài cách tiếp cận trên, ta cũng có thể tìm ngôn ngữ thoả mãn điều kiện đề bài như sau:

1. Tìm những cặp không thể giao tiếp được với nhau

2. Tìm ngôn ngữ được nhiều người biết nhất, và dạy lại cho những người còn lại

Ngoài ra, còn một cách giải khác dùng binary search. Xin dành lại cho các bạn đọc cùng khám phá.

💭Góc bạn đọc- Một tuần làm việc của EM (p4)

Thứ năm - phỏng vấn và high-level org coordination

Dạo gần đây hay có phỏng vấn để mở rộng team. Bản thân mình sau gần 1 năm không tuyển người cũng bắt đầu làm quen lại với các quy trình từ viết JD, đăng tuyển, lọc CV, phỏng vấn, offer, … và phát hiện ra sau gần 1 năm quan điểm cũng ít nhiều thay đổi về quy trình này.

Viết JD. Sau một thời gian dài chỉ dùng những mẫu JD trên mạng hoặc viết những câu chung chung, mình bắt đầu phát hiện ra là để viết JD được tốt thì bản thân người manager phải thực sự hiểu nhu cầu của mình. Việc viết JD chi tiết và thực tế sẽ giúp cho ứng viên tự xác định bản thân có phù hợp không, hoặc các bạn talent acquisition, headhunter có thể dựa vào đó để sàng lọc người phù hợp. Chi tiết ở đây là cần mô tả:

• Giới thiệu tổng quan ngắn gọn về dự án và team đang tuyển

• Tổng quan về vai trò đang đăng tuyển

• Trách nhiệm cụ thể của vai trò này

• Yêu cầu

  • Kỹ năng mềm

  • Kinh nghiệm ở vị trí liên quan

  • Học vấn

Phỏng vấn. Khi đã hiểu nhu cầu của mình thì việc phỏng vấn cũng cần được sắp xếp dựa theo nhu cầu thực tế. Có một cuộc tranh luận lâu đời trong ngành là phỏng vấn developer/engineer thì có cần phỏng vấn thuật toán sâu hoặc hỏi xoáy đáp xoay kiểu “Google” hay không? Phỏng vấn thì sẽ cần bao nhiêu vòng là đủ, …

Khó có thể nói đâu là cách tốt nhất. Tuy nhiên gần đây team mình cũng bắt đầu bỏ các bài phỏng vấn theo hướng competitive programming, hoặc phỏng vấn những thứ sẽ không thực sự được dùng trong công việc hằng ngày ở công ty. Suy cho cùng, phỏng vấn là để tuyển người vào làm những công việc hàng ngày, nếu quá trình phỏng vấn tập trung quá nhiều vào competitive programming hoặc hỏi những thứ mà công việc hàng ngày không cần thì thứ nhất là người tuyển chưa chắc đã phù hợp mà có khi lại vượt quá yêu cầu, thứ hai là người phỏng vấn đậu sẽ có “expectation” sai về công việc họ phải làm hằng ngày. Phỏng vấn quá khó hoặc cao siêu mà công việc hàng ngày không cần có thể gây mất tinh thần về lâu về dài.

Offer. Phỏng vấn xong rồi, offer ai cũng là một vấn đề. Những câu hỏi cần phải trả lời khi chọn người để offer cũng như mức offer có thể bao gồm:

• Phỏng vấn đậu là offer ngay? Tùy vào tình hình thị trường và lượng ứng viên cũng như nhu cầu thực tế mà người manager có thể chọn offer ngay khi gặp ứng viên phù hợp hay sẽ chờ các ứng viên trong cùng batch phỏng vấn được phỏng vấn hết.

• Offer nên ở mức nào? Các công ty lớn thường sẽ có range lương và có policy về việc tăng lương định kỳ. Nhưng sẽ hiếm khi bạn offer ở mức tối đa ở range lương vì nếu làm vậy sẽ khó tăng lương định kỳ cho ứng viên nên thường mức offer sẽ ở mức vừa phải.

• Ứng viên này sẽ đóng góp cho team như thế nào? Tuỳ vào tình hình cụ thể của team mà có khi người manager sẽ cần người năng nổ để giao tiếp, hoặc người thiên về hạ tầng để xử lý các tasks hạ tầng, hoặc người có chuyên môn về AI để lái định hướng của team sang hướng AI, hoặc có khi cần một bạn trẻ nhưng năng nổ và học hỏi nhanh để đẩy nhanh tốc độ thử nghiệm công nghệ mới, …

Kinh nghiệm dành cho các bạn ứng viên:

• Project, team, quản lý của bạn rất quan trọng, đặc biệt là trong môi trường công ty lớn nơi có nhiều team và nhiều projects khác nhau. Hãy tìm hiểu về project bạn sẽ làm vì trong môi trường quy mô lớn, việc đổi project sẽ không dễ. Hãy hỏi những câu hỏi cụ thể như stack công nghệ là gì, bài toán hoặc project mà bạn đang phỏng vấn là gì, có những challenge gì, …

• Hãy đặt câu hỏi khôn ngoan để lựa chọn môi trường phù hợp. Phỏng vấn là một quá trình hai chiều trong đó công ty tìm người phù hợp và ở chiều ngược lại bạn cũng muốn tìm môi trường phù hợp cho mình. Hãy hỏi những câu hỏi dạng STAR với những tình huống cụ thể cho người phỏng vấn để khai thác thông tin tốt hơn. Ví dụ như:

  • Đừng hỏi: anh/chị có thể chia sẻ thêm về văn hoá công ty không?

  • Hãy hỏi: công ty có OT nhiều không? Công ty có những loại hình training nào? Một ngày làm việc điển hình của một bạn có vai trò tương tự trong team anh/chị?

• Quan trọng là hợp tính. Bạn không đậu phỏng vấn team này chưa chắc đã là do bạn kém mà có khi là do không hợp với team hoặc không hợp thời điểm, bạn vẫn có thể thử đề xuất phỏng vấn với team khác.

• Các loại benefit ngoài lương như thưởng, stock, … cũng rất quan trọng. Khi thương lượng nên cân nhắc tổng thu nhập năm thay vì chỉ ưu tiên lương cứng. Một số công ty có thể offer lương cứng thấp nhưng bù lại tổng thu nhập năm lại cao do các phần khác như stock và bonus nhiều. Có một số công ty thì ngược lại.

📜History

(by lpv)

Vào ngày 25/8/1991, Linus đã giới thiệu trong một group rằng ông đang xây dựng một hệ điều hành mở mà sau này đã được biết đến với cái tên Linux.

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them :-)

Linus (torv...@kruuna.helsinki.fi)

PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that's all I have :-(.

🛠️Code & Tools

• Novu: The open-source notification infrastructure with fully functional embedded notification center.

• Walk: Walk is a Terminal file manager with preview mode, icons support, and image preview.

• Python Debugging Cheat Sheet

  

Should I change job?

(by nhij)

“Ở bất cứ công việc nào, bạn nên hoặc có thể học hỏi được điều gì đó hoặc kiếm được tiền. Bất cứ điều nào cũng ổn. Tốt nhất là có cả hai. Nhưng nếu không có bất cứ điều nào, hãy nghỉ việc.”

Bài viết này xây dựng dựa trên ý tưởng của câu nói trên và giải thích mối liên hệ giữa học hỏi và kiếm tiền. Học hỏi sẽ giúp bạn gia tăng khả năng kiếm tiền trong tương lai bằng cách mở cánh cửa đưa bạn tới một vị trí cao hơn và cơ hội tốt hơn. Trong khi đó, kiếm được nhiều tiền hơn có thể giúp bạn đảm bảo được nguồn tài chính bền vững từ sớm, cho phép bạn có thể mạo hiểm chịu rủi ro tài chính để đổi lại cơ hội học hỏi, như chấp nhận giảm lương để làm ở một vị trí cao hơn tại một startup. Tác giả không thể giúp bạn trả lời câu hỏi trên tựa đề, mà chỉ có bạn có thể trả lời câu hỏi đó cho bản thân. Bạn đọc có thể đọc tại bài viết gốc để hiểu sâu hơn góc nhìn của tác giả về vấn đề này.

Building and operating a pretty big storage system called S3

(by nhij)

Bài viết đăng lại những chia sẻ của Andy Warfield, VP của Amazon S3, nhìn lại sự phức tạp và quy mô hoạt động lớn của hệ thống phần mềm lưu trữ của Amazon (Amazon’s Storage Software System). Andy bàn về sự quan trọng của việc nhận biết và giảm thiểu các vấn đề về quy mô tổ chức, tương đồng với việc tối ưu hóa hệ thống. Ông cũng bàn về cách tiếp cận của quản lý để thúc đẩy sự tự chủ của nhóm trong việc giải quyết vấn đề thay vì chỉ thực thi các giải pháp có sẵn, điều này đã đem lại những kết quả kỹ thuật hiệu quả hơn. Bạn đọc có thể đọc tại bài viết gốc để hiểu sâu hơn về những chia sẻ của Andy Warfield về những câu chuyện xung quanh S3.

Incident at DataDog: Infrastructure connectivity issue affecting multiple regions

(by n^4)

Vào ngày 8/3/2023, DataDog - một cloud service dùng để monitor và theo dõi độ ổn định của các hệ thống, gặp sự cố ở diện rộng khiến chất lượng dịch vụ ảnh hưởng nghiêm trọng trong khoảng thời gian từ 06:03 UTC đến 06:25 UTC 10/3/2023 mới chính thức hồi phục. Là một trong các nhà cung cấp dịch vụ monitoring lớn với hàng chục nghìn server (x0.000 servers) vận hành đồng thời, team DataDog đã có nhiều cơ chế để đảm bảo hệ thống vận hành thông suốt thông qua nhiều cơ chế như blue/green deployment, roll-over deployment cho tuần tự từng node, cluster, region, … nhưng vẫn đề vẫn phát sinh. Vậy nguyên nhân do đâu? Làm thế nào để ngăn chặn vấn đề tương tự trong tương lai?

Bạn có thể đọc bài viết để hiểu rõ thêm chi tiết về sự cố này cũng như cách team DataDog phân tích và giải quyết sự cố nhé.

💭Góc bạn đọc - Một tuần làm việc của EM (p3)

Thứ tư - ngày không họp hành

Qua hai ngày đầu tuần thì hẳn các bạn sẽ đặt dấu hỏi, ủa, vậy EM thấy họp suốt ngày vậy thì còn làm gì khác không? Thật ra thì cũng có đấy. Ngoài các khoảng nghỉ giữa các cuộc họp thì EM sẽ có những tasks của riêng mình, và những tasks này thường sẽ tận dụng các khoảng thời gian rảnh giữa các meeting, hoặc là tận dụng no-meeting day để hoàn thành.

(1) Làm các tasks liên quan đến engineering. Cụ thể là viết thinking document hoặc design document để nêu hoặc phân tích một vấn đề nào đó. Các vấn đề phân tích mà vai trò EM phụ trách thường sẽ mang tính tổng quan hoặc chiến lược hơn so với các bài toán vận hành hàng ngày. Ví dụ như một vài vấn đề mình sẽ phải viết gần đây:

• Chia sẻ quan điểm về vai trò của low-code platform trong tổ chức? Có nên dùng hay không? Nếu dùng thì nên dùng như thế nào?

• Bài toán workflow automation là bài toán của ai (trong tổ chức lớn hơn), nên được giao cho ai?

• Đề xuất cho một platform khác có liên quan đề platform của mình

(2) Thực hiện vai trò giám sát và coaching. Một trong những trách nhiệm lớn nhất của EM là phải giám sát và chịu trách nhiệm cho sự phát triển của team mình. Để thực hiện vai trò này thì bản thân cần liên tục theo dõi các kênh thông tin của team mình trên Slack để xem các thành viên đang trao đổi về vấn đề gì, có thể nhảy vào cùng trao đổi và tìm cách đưa cuộc thảo luận theo đúng hướng (nếu bản thân thấy chưa đúng hướng).

Ngoài ra cũng sẽ dùng các nội dung trao đổi này để mang ra thảo luận với từng cá nhân trong quá trình 1:1 để góp ý và chia sẻ quan điểm của mình. Sẽ có những tình huống bản thân thấy một thành viên A nào đó phản hồi chưa hợp lý, hoặc chưa trọn vẹn, ví dụ như bạn ấy đang giải thích về một vấn đề cho một người dùng non-tech nhưng lại dùng quá nhiều thuật ngữ kỹ thuật. Trong những tình huống như vậy thì mình sẽ cần ghi nhận và thảo luận với bạn ấy trong những buổi gặp mặt để bạn lưu ý hơn.

Bên cạnh đó, EM cũng sẽ cần phải giúp các thành viên phát triển thông qua việc thảo luận về career path, cũng như xác định độ ưu tiên cho các thành viên và cân bằng giữa nhu cầu phát triển bản thân và nhu cầu của công ty. Bên công ty mình thì trong thời gian gần đây có triển khai một hoạt động gọi là Plan & Priority, trong đó mỗi thành viên sẽ cần tự đặt ra các mục tiêu phát triển bản thân cũng như các ưu tiên trong sự nghiệp hiện tại. EM sẽ dựa vào nhu cầu của từng thành viên để từ đó có sự phân công các tasks phù hợp.

Ví dụ như nếu một bạn trong 6 tháng tới muốn đầu tư nhiều quanh hệ thống Data, vậy thì EM cần tìm cách để đưa bạn vào nhóm làm task liên quan đến Data nhiều hơn. Hoặc một bạn quan tâm đến DevOps thì EM cần tìm cách phân các tasks liên quan đến DevOps nhiều hơn cho bạn, …

(3) Thực hiện vai trò lên kế hoạch. Lập và thực thi kế hoạch là một trong những vai trò quan trọng mà EM cần phải đảm đương, đặc biệt là việc lên kế hoạch dài hạn với chu kỳ 3-6 tháng trở lên. Trong một tổ chức lớn như nơi bản thân đang làm việc, việc có những chiến lược và kế hoạch dài hạn 2-3 năm là cần thiết vì nhiều lý do. Nhiệm vụ của EM lúc này là phải hiểu được platform hoặc team mình đang phụ trách đang đứng ở đâu trong bức tranh toàn cảnh của công ty, phòng ban của mình để tự đó đưa ra được các kế hoạch phù hợp.

Trong vai trò này, bản thân sẽ cần phải tham gia chuẩn bị những thứ như

• Budget planning. Dự toán xem hạ tầng của team đang quản lý cần kinh phí bao nhiêu trong 6 tháng - 1 năm tới.

• OKR planning. Mỗi 6 tháng một lần, sẽ phải thống nhất OKR của team để review với các manager cùng các stakeholders liên quan.

• Vision and Strategy docs. 1 năm một lần sẽ cần phải review lại về chiến lược dài hơi của team, platform để coi team đang ở đâu và cần phát triển theo hướng nào.

• Execution plan. Tham gia vào soạn thảo các kế hoạch thực thi ở phía engineering từ một kế hoạch lớn ảnh hưởng đến nhiều bộ phận khác nhau.

(4) Các task khác lặt vặt không tên. Tùy vào quy mô và quy trình của tổ chức mà số lượng task lặt vặt có thể nhiều hoặc ít, nhưng sẽ có kha khá các tasks có thể kể tên như: review và approve request xin quyền từ team, support một bạn user của platform, xin budget engagement, …

(còn tiếp)

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Minimum Number of People to Teach

Trên một mạng xã hội có m người dùng, hai người dùng có thể giao tiếp với nhau nếu họ biết một ngôn ngữ chung.

Cho trước một số nguyên n, một mảng languages, và một mảng friendships, cụ thể là:

• Có n ngôn ngữ đánh số từ 1 đến n.

• languages[i] là tập các ngôn ngữ mà người dùng thứ i biết.

• friendships[i] = [u_i, v_i] biểu diễn một mối quan hệ bạn bè giữa người dùng u_i và v_i.

Bạn có thể chọn một ngôn ngữ và dạy nó cho một số người để từ đó tất cả mọi người có thể liên lạc với nhau. Trả về số người dùng ít nhất mà bạn phải dạy.

Lưu ý friendships không mang tính bắc cầu, tức là x là bạn của y, y là bạn của z không có nghĩa là x là bạn của z.

Ví dụ:

Input: n = 2, languages = [[1],[2],[1,2]], friendships = [[1,2],[1,3],[2,3]]

Output: 1

Giải thích: Bạn có thể chọn dạy người dùng 1 ngôn ngữ số 2, hoặc người dùng 2 ngôn ngữ số 1.

Lời giải tuần trước: Queue Reconstruction by Height

Đề bài

Cho một mảng people biểu diễn một hàng người, với people[i] = [hi, ki], trong đó người ở vị trí thứ i có chiều cao hi, và có chính xác ki người đứng phía trước với chiều cao bằng hoặc cao hơn hi.

Ví dụ: people[1] = [5, 2] nghĩa là người ở vị trí số 1 có chiều cao là 5, và có 2 người đứng phía trước.

Hiện nay các phần tử trong mảng people đang bị xáo trộn, bạn đọc hãy sắp xếp lại mảng people sao cho giá trị của các phần tử là đúng với yêu cầu trên.

Ví dụ:

Input: people = [[7,0],[4,4],[7,1],[5,0],[6,1],[5,2]]

Output: [[5,0],[7,0],[5,2],[6,1],[4,4],[7,1]]

Giải thích:

• Người ở vị trí số 0 có chiều cao 5, và có 0 người đứng trước có chiều cao >= 5.

• Người ở vị trí số 1 có chiều cao 7, và có 0 người đứng trước có chiều cao >= 7.

• Người ở vị trí số 2 có chiều cao 5, và có 2 người đứng trước có chiều cao >= 5.

• Người ở vị trí số 3 có chiều cao 6, và có 1 người đứng trước có chiều cao >= 6.

• Người ở vị trí số 4 có chiều cao 4, và có 4 người đứng trước có chiều cao >= 4.

• Người ở vị trí số 5 có chiều cao 7, và có 1 người đứng trước có chiều cao >= 7.

Lời giải

Đầu tiên ta xem xét cách sắp xếp cho trường hợp từng nhóm người có chiều cao bằng nhau. Dễ thấy rằng phải sắp xếp hai người có cùng chiều cao theo thứ tự giá trị k tăng dần.

Với ví dụ đề bài đã cho, ta có các nhóm: [5,0], [5,2]; [7,0], [7,1]; [4,4]; [6,1];

Tiếp theo cần tìm cách để gộp các nhóm trên lại với nhau thỏa mãn đề bài.

Ví dụ, với nhóm người cao nhất [7,0], [7,1], nhận thấy ta có thể chèn bất kì người nào vào vị trí giữa hai người này mà vẫn thỏa mãn đề bài. Tức là những người cao hơn sau khi đã được sắp xếp vào đúng vị trí thì không cần quan tâm đến họ nữa.

Từ đó ý tưởng giải quyết bài toán này là

+ Chọn từng người để sắp xếp, theo thứ tự chiều cao giảm dần, với hai người có cùng chiều cao thì ta chọn theo thứ tự tăng dần của k.

+ Đặt người đó vào vị trí có giá trị đúng bằng giá trị k của họ.

Với ví dụ đề bài cho:

• Sắp xếp danh sách các cặp (h_i, k_i) theo thứ tự giảm dần của h và tăng dần của k.

Ta có [[7,0], [7,1], [6,1], [5,0], [5,2], [4,4]]

• Duyệt qua mảng đã sắp xếp, lần lượt chèn từng người vào mảng mới (cũng là mảng kết quả) tại vị trí bằng giá trị k của người đó.

[7,0] -> Chèn vào vị trí 0 trong danh sách kết quả: [[7,0]]

[7,1] -> Chèn vào vị trí 1 trong danh sách kết quả: [[7,0], [7,1]]

[6,1] -> Chèn vào vị trí 1 trong danh sách kết quả: [[7,0], [6,1], [7,1]]

[5,0] -> Chèn vào vị trí 0 trong danh sách kết quả: [[5,0], [7,0], [6,1], [7,1]]

[5,2] -> Chèn vào vị trí 2 trong danh sách kết quả: [[5,0], [7,0], [5,2], [6,1], [7,1]]

[4,4] -> Chèn vào vị trí 4 trong danh sách kết quả: [[5,0], [7,0], [5,2], [6,1], [4,4], [7,1]]

class Solution {
  public int[][] reconstructQueue(int[][] people) {
    Arrays.sort(people, (o1, o2) -> o1[0] == o2[0] ? o1[1] - o2[1] : o2[0] - o1[0]);

    List<int[]> reconstructedQueue = new ArrayList<>();
    for(int[] p : people){
      reconstructedQueue.add(p[1], p);
    }

    return reconstructedQueue.toArray(new int[people.length][2]);
  }
}

Thuật toán sắp xếp có độ phức tạp O(NlogN), tuy nhiên vòng lặp for để chèn với hàm add có tổng độ phức tạp O(N^2) nên độ phức tạp thời gian của giải thuật là O(N^2), với N là độ dài mảng people đã cho trước.

Quotes

5 ways to review code without wasting everyone’s time

(by quangle)

Là một developer, chắc hẳn review code là công việc mà chúng ta sẽ gặp hằng ngày. Sau đây là 5 gợi ý mà tác giả - kỹ sư tại Volvo Cars đúc kết trong quá trình làm việc để có thể review code một cách hiệu quả:

• Kiểm tra pull requests có đáp ứng được các yêu cầu đặt ra của team (ví dụ: có unit tests chưa, có documentation chưa, v.v)

• Cung cấp thêm nhiều góc nhìn mới về pull request của người khác (ví dụ: các vấn đề về lỗi chính tả, đặt tên biến, khoanh vùng những context khó hiểu, v.v)

• Không ngại đặt câu hỏi và cung cấp feedbacks cho người được review code

• Nói “không” với những pull requests chưa rõ ràng (ví dụ: pull request có hơn 5,000 file changes, v.v)

• Viết comment code “nhẹ nhàng”, mang tính xây dựng và đóng góp để người được review code có thể cải thiện

Để tìm hiểu chi tiết hơn về từng key point, mời bạn đọc cùng tham khảo bài viết

Getting More from Your Team Health Checks

(by steven.do)

Tại Spotify việc theo dõi và kiểm tra tính hiệu quả (health-check) trong các đội nhóm đã được triển khai áp dụng trong một thời gian dài. Các team đội sẽ tạm dừng các hoạt động hàng ngày của để tiến hành việc đánh giá hiệu quả nhằm giúp các đội có cái nhìn bao quát hơn về cách các thành viên trong mỗi đội nhóm đang làm việc. Với mục đích cải thiện sự tự nhận thức của mỗi thành viên đồng thời cho phép họ nhìn thấy rõ hơn các cơ hội cải thiện, phát triển các kỹ năng cá nhân và phối hợp làm việc với đội nhóm hiệu quả và giải toả các mâu thuẫn bất đồng nảy sinh trong quá trình làm việc. Các kết quả tổng hợp từ các kiểm tra đánh giá tình trạng dội nhóm này cũng cung cấp cho trưởng bộ phận quản lý các đội một cách để theo dõi các mô hình và xu hướng phát triển trên nhiều đội nhóm theo thời gian để có thêm dữ liệu nhằm hỗ trợ các hoạt động của các đội nhóm kịp thời.

Nhìn chung, hoạt động đánh giá sức khỏe đội nhóm tại Spotify bao gồm các bước như sau:

• Khảo sát dựa trên một bảng câu hỏi về tech đội nhóm đang sử dụng, đánh giá tình hình hoạt động của đội nhóm, đánh giá tình trạng của sản phẩm của đội nhóm.

• Tổ chức buổi thảo luận về kết quả của bản khảo sát giữa các thành viên trong đội nhóm và thảo luận đưa ra hướng xử lý khắc phục.

• Tổng hợp kết quả các ý kiến đóng góp và khảo sát từ nhiều đội nhóm nhằm xác định các đặc trưng và điểm tương đồng giữa các vấn đề các đội nhóm đang gặp phải ở mức độ tổng quan.

Bài viết cũng cung cấp thêm nhiều thông tin và phương pháp giúp việc trao đổi và khuyến khích các thành viên trong mỗi đội nhóm nêu lên ý kiến và quan điểm nhận định cá nhân nhằm giúp cho các nhà quản lý nắm bắt được rõ ràng hơn về các vấn đề đang tồn tại và gây ảnh hưởng đến hiệu quả hoạt động của đội nhóm.

💭Góc bạn đọc

Nhóm biên tập có nhận được nội dung chia sẻ từ bạn đọc T đang làm việc ở một công ty công nghệ với quy mô trên 1000 nhân sự dưới vai trò Engineer Manager. Nhóm sẽ bắt đầu trích đăng nội dung chia sẻ của bạn viết về công việc hàng ngày của mình trong các số newsletter tới.

Ngoài ra, để nội dung thêm phong phú nhóm cũng hy vọng có dịp phỏng vấn các bạn đang làm việc ở các công ty công nghệ với các vai trò khác nhau như Software Engineer, QA, Manager, Product Owner, ML Ops, DevOps… chia sẻ thêm về công việc hằng ngày và những thách thức trong công việc của mình. Bạn nào sẵn lòng chia sẻ vui lòng reply email này, nhóm sẽ sắp xếp một buổi phỏng vấn để tìm hiểu về công việc của bạn để viết lại và gửi đến cho cộng đồng.

Một tuần làm việc của Engineer manager ra sao? (p2)

Thứ ba

Sáng thứ ba thường sẽ bắt đầu bằng họp stand-up online với team nhỏ đang trực tiếp phụ trách. Trong buổi stand up các thành viên sẽ mở tasks board ra, sau đó từng thành viên sẽ lần lượt điểm qua các việc đã làm ngày hôm trước cũng như nêu ra các vấn đề cần xử lý. Nếu có vấn đề cần thảo luận thì các thành viên có thể tự hẹn để thảo luận riêng sau đó. Trong hoạt động này thì với vai trò EM, bản thân chỉ tham gia để cập nhật thông tin là chủ yếu, hoặc thỉnh thoảng có thể đưa ra góp ý về hướng xử lý một ticket là thoả đáng hay chưa.

Phần còn lại của buổi sáng sẽ là họp Operational Excellent của toàn công ty. Trong buổi họp này, các team phụ trách về vận hàng sẽ điểm qua nhiều vấn đề như tình hình cost, các incidents, các vấn đề về security, các vấn đề về độ ổn định chung của toàn hệ thống theo các nhóm service khác nhau. Ngoài ra, các team nào có sự cố sẽ trình bày Post Mortem của team mình.

Nói thêm một tí về Post-Mortem (PM), cấu trúc thường có của một PM thường bao gồm:

• Giới thiệu tổng quan về sự cố

• Timestamp các sự kiện diễn ra trước, trong và sau khi sự cố

• Phân tích sâu về nguyên nhân gốc rễ dẫn đến sự cố

• Các hành động đã làm để phục hồi hệ thống cũng như giảm thiểu thiệt hại (mitigate)

• Bài học kinh nghiệm cần rút ra.

Đối với một tổ chức lớn vận hành nhiều service phức tạp thì các PM là một hoạt động rất quan trọng vì nó sẽ giúp chúng ta rút kinh nghiệm mỗi khi có sự cố xảy ra. Một PM tốt cần phân tích sâu và đến gốc rễ vấn đề (Root-cause) để từ đó có thể rút ra bài học cho các service khác có thể áp dụng. Quá trình phân tích cũng có thể áp dụng nhiều kỹ thuật nhưng phổ biến nhất là 5-whys: đặt liên tục 5+ câu hỏi tại sao cho đến khi có thể chạm đến gốc rễ.

Ví dụ về quá trình đặt câu hỏi 5-whys được đơn giản hoá để có thể dễ hình dung:

• Tại sao lại service A lại có gặp lỗi 500 liên tục trong khung thời gian 15 phút từ thời điểm 11:00am đến 11:15am? → Tại vì service A gọi đến service B, service B trả về kết quả với độ trễ p99=800ms trong khi yêu cầu từ service A là 150ms.

• Tại sao service B lại trả về kết quả với độ trễ p99=800ms trong khung thời gian đó? → Tại vì database service B đang dùng trả về kết quả cho endpoint XX với độ trễ p99=700ms, cao hơn thường lệ.

• Tại sao database service B đang dùng lại trả về kết quả có độ trễ cao p99=700ms và cao hơn thường lệ? → Tại vì một partition của database đang dùng bị overload dẫn đến các request đến partition này có độ trễ cao hơn.

• Tại sao partition lại bị overload? → Tại vì có một lượng request tăng đột biến đến từ service C cũng gọi qua service B, trong lượng request này có kèm một số lệnh update đến từ partition tương ứng dẫn đến overload partition này.

• Tại sao lại có một lượng request tăng đột biến đến từ service C? → Tại vì redis cluster của service C bị down dẫn đến một lượng lớn request vốn nên được cache bởi service C bị đẩy sang service B.

Trong thực tế, việc đặt câu hỏi có thể nhiều hơn hoặc ít hơn. Nhưng nhìn chung khi phân tích, đặt câu hỏi đúng thì sẽ dẫn đến các bài học kinh nghiệm phù hợp để từ đó ngăn chặn các vấn đề phát sinh trong tương lai.

Kết thúc buổi sáng thứ ba, buổi chiều thường sẽ bắt đầu bằng buổi họp Operational Excellent của platform đang phụ trách. Trong đó, các thành viên sẽ review các thông số vận hành như SLI, SLO, các vấn đề mới phát sinh cần đào sâu, … Nếu chỉ số nào không đạt SLO thì sẽ cần điều tra nguyên nhân. 

Tiếp đến sẽ là họp dành cho leader của platform đang phụ trách trong đó sẽ điểm qua các chủ đề tổng quan của platform như các use-case mới cần xử lý, thông tin từ các platform liên quan, chốt OKR, thảo luận milestone tiếp theo của các dự án đang triển khai, …

Phần còn lại của buổi chiều là xen kẽ 1:1 với leader hoặc coordinator cùng team, team khác để cập nhật tình hình lẫn nhau cũng như thảo luận về các dự án đang phụ trách của nhau. Đối với bản thân thì các buổi 1:1 là một hoạt động không thể thiếu đặc biệt là đối với các team liên quan để có thể tập trung thảo luận các chủ đề tổng quan về problem space của từng team, hoặc các vấn đề mang tính chất dài hạn hơn (3-6 tháng) thay vì các hoạt động hàng ngày vốn đã có quy trình tương ứng để xử lý.

(còn tiếp)

Quotes

Ngoài ra, để nội dung thêm phong phú nhóm cũng hy vọng có dịp phỏng vấn các bạn đang làm việc ở các công ty công nghệ với các vai trò khác nhau như Software Engineer, QA, Manager, Product Owner, ML Ops, DevOps… chia sẻ thêm về công việc hằng ngày và những thách thức trong công việc của mình. Bạn nào sẵn lòng chia sẻ vui lòng reply email này, nhóm sẽ sắp xếp một buổi phỏng vấn để tìm hiểu về công việc của bạn để viết lại và gửi đến cho cộng đồng.

📰Những bài viết hay

How LinkedIn Serves over 4.8 Million Member Profiles per Second

(by quangle80)

LinkedIn vừa giới thiệu một kỹ thuật có tên gọi Couchbase as a centralized caching tier (tận dụng Couchbase cho để làm tầng bộ nhớ cache tập trung) để giải quyết bài toán scaling cho tính năng đọc member profile, nhằm đáp ứng việc xử lý lưu lượng truy cập ngày càng tăng đến các cụm database cluster của hệ thống.

Nhiều năm qua, LinkedIn xây dựng tính năng member profiles bằng cách truy vấn trực tiếp vào Espresso document platform - một nền tảng được xây dựng trên MySQL, Apache Helix, Databus (LinkedIn’s change capture system) và sử dụng Avro để chuẩn hóa dữ liệu. Espresso routers sẽ điều phối các requests read/write đến đúng các cụm lưu trữ và sử dụng off-heap cache (OHC) cho các hot keys.

Thử thách đặt ra là vào lúc cao điểm, hệ thống phải xử lý hơn 4,8 triệu RPS, hệ thống Espresso thì đã đạt đến giới hạn về khả năng mở rộng. Thay vì làm lại các thành phần cốt lõi của nền tảng Espresso, nhóm đã chọn giải pháp xây dựng một tầng caching mới. Tầng caching mới này được tích hợp vào Espresso, kết hợp OHC hiện có và tận dụng các sức mạnh của Couchbase như khả năng chịu lỗi, cache data availability và ngăn chặn tình trạng data divergence. Lúc này, tất cả dữ liệu member profiles được lưu vào bộ nhớ cache ở mọi data-center và được cập nhật bởi các Apache Samza jobs. Các thay đổi về dữ liệu đến từ thao tác ghi được captured bởi các cụm Espresso Storage, hay các database snapshots định kỳ sẽ được Cơ chế Couchbase Compare-And-Swap (CAS) ghi nhận và đi update lại cache nếu cần.

Theo số liệu thống kê từ đội ngũ, giải pháp mới này đạt tỉ lệ thành công hơn 99%, cắt giảm hơn 60% độ trễ và tiết kiệm 10% chi phí hạ tầng hằng năm. Để tìm hiểu chi tiết hơn về bài viết cũng như lý do chọn Couchbase cho tầng Caching, mời bạn đọc tham khảo bài viết.

💭Góc bạn đọc

Thứ hai - ngày của planning

Sáng đầu tuần khởi động bằng hai cuộc họp sprint planning cho hai team đang phụ trách. Thường thứ hai sẽ được dùng cho sprint planning hoặc backlog grooming, xen kẽ mỗi tuần. Tuỳ vào lượng công việc mà có thể mình sẽ bỏ qua cuộc họp này mà chỉ theo dõi tình trạng backlog sau khi mọi người trong team đã họp xong.

Ở team mình, một sprint sẽ kéo dài hai tuần. Đầu sprint mọi người sẽ cùng duyệt qua backlog để chọn ra các task quan trọng cần phải hoàn thành trong sprint này. Sau đó mọi người cũng sẽ duyệt qua các project quan trọng và điều chỉnh lịch release dự kiến nếu cần thiết. Thông thường, backlog khá dài nên việc review các task và độ ưu tiên sẽ được làm trước trong các buổi backlog grooming của tuần trước đó để khi làm sprint planning thì sẽ không tốn thời gian review độ ưu tiên lại.

Chiều thứ hai thường sẽ có cuộc họp giao ban ngắn giữa oncall tuần trước và oncall tuần này. Ở công ty mình, tại một thời điểm sẽ luôn có người phụ trách trực cho một service hoặc một platform, người này sẽ được gọi là oncall. Tuỳ team mà ca trực oncall theo ngày hoặc theo tuần. Nhiệm vụ của oncall sẽ là theo dõi tình hình hệ thống, phản ứng khi có các cảnh báo sự cố hoặc vấn đề xảy ra, trả lời các câu hỏi của team khác liên quan đến các phần hệ thống của team mình. Trong buổi họp giao ban này, người phụ trách oncall tuần trước sẽ điểm qua những vấn đề phát sinh của tuần rồi và các điều cần lưu ý tiếp.

Trong chiều thứ hai này team mình có một buổi họp đột xuất để review một Post-mortem được viết bởi một bạn trong team, trình bày về nguyên nhân dẫn đến sự cố service bị nghẽn trong 2 ngày liên tục, mỗi lần nghẽn diễn ra trong 5 phút dẫn đến một loạt các service liên quan cũng bị nghẽn theo. Mọi người sẽ cùng review Post-mortem của bạn phụ trách và đưa ra góp ý, phản biện cũng như đặt các câu hỏi để làm rõ hơn về nguyên nhân sự cố.

Sự cố này thú vị vì sau khi điều tra cụ thể thì phát hiện ra mặt dù dấu hiệu ban đầu của việc bị nghẽn trong 2 ngày là giống nhau, nhưng nguyên nhân sâu xa gây ra lại hoàn toàn khác nhau. Ở ngày đầu tiên, service bị nghẽn vì một node trong cụm server không phục vụ được traffic cho các service khác dẫn đến mất cân bằng tải. Lý do là trong quá trình node này khởi động thì quá trình đăng ký node này vào danh mục service discovery bị lỗi, dẫn đến cụm server có 3 servers nhưng chỉ có 2 servers phục vụ được traffic thông qua service discovery. Điều này dẫn đến thuật toán auto-scaling của cụm server vốn dựa vào CPU trung bình không hoạt động đúng.

Ở ngày thứ hai, service bị nghẽn cũng vì một node trong cụm không phục vụ được traffic cho các service khác thông qua ELB nhưng do quá trình khởi tạo và đánh nhãn bị lỗi nên không bị thay thế kịp lúc. Quá trình này cũng dẫn đến mất cân bằng tải.

Thời gian còn lại của buổi chiều có thể xen kẽ các session 1:1 ngắn với các thành viên đang quản lý trực tiếp, gián tiếp hoặc đang mentor.

(còn tiếp)

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Queue Reconstruction by Height

Cho một mảng people biểu diễn một hàng người, với people[i] = [h_i, k_i], trong đó người ở vị trí thứ i có chiều cao h_i, và có chính xác k_i người đứng phía trước với chiều cao bằng hoặc cao hơn h_i.

Ví dụ: people[1] = [5, 2] nghĩa là người ở vị trí số 1 có chiều cao là 5, và có 2 người đứng phía trước.

Hiện nay các phần tử trong mảng people đang bị xáo trộn, hãy sắp xếp lại mảng people sao cho giá trị của các phần tử là đúng với yêu cầu trên.

Ví dụ:

• Input: people = [[7,0],[4,4],[7,1],[5,0],[6,1],[5,2]]

• Output: [[5,0],[7,0],[5,2],[6,1],[4,4],[7,1]]

Giải thích:

• Người ở vị trí số 0 có chiều cao 5, và có 0 người đứng trước có chiều cao >= 5.

• Người ở vị trí số 1 có chiều cao 7, và có 0 người đứng trước có chiều cao >= 7.

• Người ở vị trí số 2 có chiều cao 5, và có 2 người đứng trước có chiều cao >= 5.

• Người ở vị trí số 3 có chiều cao 6, và có 1 người đứng trước có chiều cao >= 6.

• Người ở vị trí số 4 có chiều cao 4, và có 4 người đứng trước có chiều cao >= 4.

• Người ở vị trí số 5 có chiều cao 7, và có 1 người đứng trước có chiều cao >= 7.

Lời giải tuần trước: Find the Divisibility Array of a String

Đề bài

Do sơ suất trong quá trình biên tập, nội dung đề bài được giới thiệu ở số newsletter kỳ trước chưa chính xác, các bạn có thể tham khảo lại đề bài đã được điều chỉnh lại ở đây (thay n số tự nhiên thành n chữ số)

Cho một chuỗi word bao gồm n chữ số và một số tự nhiên m.

Trả về kết quả là mảng div với tính chất như sau:

• div[i] = 1 nếu giá trị số học của chuỗi word[0…i] chia hết cho m

• div[i] = 0 nếu ngược lại.

Ví dụ:

• Input: word = "998244353", m = 3

• Output: [1,1,0,0,0,1,1,0,0]

• Giải thích: có 4 chuỗi con: "9", "99", "998244", and "9982443" thỏa mãn đề bài.

Lời giải

Đề bài yêu cầu kiểm tra tất cả các tiền tố xem có chia hết cho số m hay không, vì vậy ta cần tìm tất cả các tiền tố, tạm gọi là prefix trong chuỗi word, và lần lượt kiểm tra xem prefix có chia hết cho số m hay không bằng phép toán module: prefix mod m == 0.

Do độ dài của chuỗi word <= 10^5, chuỗi tiền tố sẽ vượt quá phạm vi biểu diễn của máy tính.

Mặc dù nhiều ngôn ngữ lập trình cung cấp thư viện để biểu diễn số nguyên lớn như BigInteger trong Java, việc khởi tạo và tính toán với số nguyên lớn đòi hỏi nhiều tài nguyên.

Để tối ưu bài này, ta có thể phân tích như sau:

Gọi số n là số chia, m là số bị chia, r là số dư. Như vậy n = k*m + r, với k là kết quả của phép chia lấy phần nguyên của n và m.

Ta muốn thêm chữ số d vào sau số n, và kiểm tra xem số mới có chia hết cho m hay không? Ta có:

Vì 10*k*m luôn luôn chia hết cho m, ta chỉ cần kiểm tra 10*r + d.

Ta thực hiện giải thuật như sau:

import java.math.BigInteger;

class Solution {
    public int[] divisibilityArray(String word, int m) {
        int n = word.length();
        int[] ans = new int[n];

        long rem = 0;
        for (int i = 0; i < n; i++) {
            rem = (rem * 10 + word.charAt(i) - '0') % m;
            if (rem == 0) {
                ans[i] = 1;
            }
        }
        return ans;
    }
}

Độ phức tạp về thời gian của giải thuật là O(n) với n là độ dài của chuỗi word.

Quotes

Optimizing batch writes to Redis using Pipelining

(by quangle80)

Tại Swiggy (một nền tảng food delivery lớn ở Ấn Độ), mỗi ngày hệ thống DSP (Data Science Platform - một trong những core platform) của họ sẽ có các scheduled ETL jobs cần chạy để xử lý các cập nhật dữ liệu từ danh sách cửa hàng. Riêng đối với những tác vụ yêu cầu độ trễ thấp, đội ngũ sẽ dùng AWS ElastiCache (Redis) để xử lý.

Song để đáp ứng kế hoạch về cắt giảm chi phí hạ tầng của công ty, đội ngũ bắt đầu phân tích và đặt ra mục tiêu đầu tiên của họ chính là cải thiện thời gian ghi dữ liệu vào Redis của các scheduled-jobs trên.

Redis hoạt động theo mô hình client-server (client gửi yêu cầu đến server, server xử lý và trả về kết quả) một cách tuần tự. Với cách tiếp cận đó, một request tốn 100ms để thực thi thì trong 1s có thể xử lý được 10 requests. Vì vậy, để có thể cải thiện hiệu suất xử lý, nhóm đã tận dụng kỹ thuật pipeline của Redis bằng cách gửi một batch requests cùng một lúc, không cần đợi phản hồi của từng request. Với Pipeline, họ có thể giải quyết bài toán về cải thiện throughput cho hệ thống, nhưng cần lưu ý vấn đề về batch size của requests. Sử dụng batch size pipeline càng lớn sẽ gây ra các blocker khác ở phía server cho đến khi request cuối cùng trong batch được thực thi xong vì về lý thuyết Redis là một single-thread server.

Để tìm hiểu chi tiết hơn về kỹ thuật pipeline cũng như kết quả benchmark được cải thiện như thế nào khi họ áp dụng pipeline cho các feature jobs, mời bạn đọc cùng tham khảo bài viết gốc.

How to make difficult technical decisions you and your team won't regret

(by nhij)

Công việc của một kỹ sư phần mềm đòi hỏi chúng ta phải đưa ra các lựa chọn về mặt kĩ thuật hàng ngày. Một số quyết định đơn giản và rõ ràng, nhưng cũng có những quyết định khó khăn, yêu cầu phải suy nghĩ và cân nhắc kỹ lưỡng. Trong bài viết này, tác giả chia sẻ một số kinh nghiệm trong quá trình đưa ra quyết định với các bước như sau:

• Liệt kê tất cả các lựa chọn có thể.

• Loại bỏ các lựa chọn không phù hợp và ghi chú lại.

• Đối với các lựa chọn còn lại, đưa ra các ưu và nhược điểm của mỗi lựa chọn và thảo luận với team.

Nếu bạn vẫn chưa chắc chắn với quyết định của mình, bạn có thể:

• Đặt mình vào vị trí của người dùng và đánh giá mỗi lựa chọn dựa trên góc nhìn của người dùng.

• Thảo luận riêng với đồng nghiệp ít kinh nghiệm hơn và đồng nghiệp nhiều kinh nghiệm hơn.

• Cân nhắc các yếu tố sau: khả năng điều chỉnh và thu hồi quyết định; giá phải trả nếu lựa chọn đó không phù hợp và khả năng mở rộng trong tương lai.

Lessons Learned: The Journey to Real-Time Machine Learning at Instacart

(by dinhnguyen)

Tại Instacart, việc áp dụng mô hình máy học (ML) đóng vai trò quan trọng trong việc nâng cao trải nghiệm người dùng trên nhiều bên liên quan, từ khách hàng, người bán hàng, nhà bán lẻ đến đối tác thương hiệu.

Trong bài viết này, tác giả đã chỉ ra:

• Một số hạn chế khi sử dụng batch-oriented ML.

• Một vài thách thức và những quyết định quan trọng khi chuyển từ batch đến real-time ML.

• Một số bài học từ việc chuyển đổi này.

Một số hạn chế trong các hệ thống batch-oriented ML:

• Stale Predictions: Việc dự đoán đã được tính toán trước gây ra trải nghiệm người dùng kém vì chúng cung cấp phản hồi lỗi thời dựa trên sự kiện quá khứ.

• Inefficient Resource Usage: Việc tạo dự báo cho tất cả khách hàng hàng ngày dẫn đến lãng phí tài nguyên, vì nhiều khách hàng không tương tác hàng ngày với nền tảng.

• Limited Coverage: Tính chất theo batch của quy trình hạn chế khả năng cung cấp dự đoán thời gian thực cho tất cả các tình huống.

• Response Lag: Các mô hình ít phản ứng hơn với những thay đổi gần đây do các tính năng thời gian thực

• Suboptimal: Chất lượng đầu ra mô hình bị ảnh hưởng bởi độ tươi (freshness) của dữ liệu.

Họ đã áp dụng 2 chuyển đổi quan trọng để kích hoạt real-time ML

• Real-time serving: chuyển đổi từ cơ chế tính toán trước kết quả dự đoán (precomputed prediction) sang cơ chế real-time để cải thiện phạm vi bao phủ, tối ưu hóa việc sử dụng tài nguyên cũng như giúp kết quả dự đoán ít bị lạc hậu.

• Real-time features: Từ các tính năng batch đến các tính năng real-time để đảm bảo dữ liệu luôn mới và cho phép các mô hình máy học đưa ra được các phán đoán dựa trên các dữ liệu được cập nhật mới nhất có thể.

Chuyển đổi thứ nhất: Từ việc phục vụ dự đoán được tính toán trước đến real-time

• Những thách thức bao gồm quản lý độ trễ, đảm bảo tính sẵn có của hệ thống và vượt qua Steep Learning Curve.

• Những quyết định quan trọng bao gồm áp dụng một giao diện thống nhất cho kiểm tra và triển khai, và sử dụng RPC framework để giao tiếp giữa các dịch vụ trong Instacart.

Chuyển đổi thứ hai: Phục vụ từ batch features đến real-time features

• Những thách thức bao gồm làm việc với các công nghệ streaming phân tán trong những tổ chức khác nhau, đảm bảo những events có tính chất nhất quán và chất lượng và xây dựng những pipeline phức tạp với quy trình phát triển mới.

• Những quyết định quan trọng bao gồm triển khai lưu trữ sự kiện tập trung bằng cách sử dụng Kafka và tách biệt event cho lưu trữ và tính toán để tuân thủ nguyên tắc phân tách mối quan tâm, thành lập 1 nhóm làm việc đến từ những team khác nhau.

Bài học từ việc chuyển đổi:

• Hạ tầng đóng vai trò quan trọng trong real-time ML.

• Việc cải tiến nên đạt được từng bước một.

• Áp dụng giải pháp tổng thể và chuyên biệt.

• Phát triển hạ tầng song song với phát triển sản phẩm.

Để có thêm thông tin chi tiết hơn, mời bạn đọc tham khảo thêm tại bài viết gốc.

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Find the Divisibility Array of a String

Cho một chuỗi word bao gồm n số tự nhiên và một số tự nhiên m.

Trả về kết quả là mảng div với tính chất như sau:

• div[i] = 1 nếu giá trị số học của chuỗi word[0...i] chia hết cho m.

• div[i] = 0 nếu ngược lại.

Ví dụ:

Input: word = "998244353", m = 3

Output: div = [1,1,0,0,0,1,1,0,0]

Giải thích: có 4 chuỗi con: "9", "99", "998244" và "9982443" thỏa mãn đề bài.

Lời giải tuần trước: Maximize Distance to Closest Person

Gọi K là khoảng cách giữa 2 ghế đã có người ngồi, ta thấy khoảng cách mà đề bài yêu cầu tìm đó là (K + 1) / 2.

Từ đó, ý tưởng để giải bài toán đó là duyệt mảng seats để tìm tất cả các khoảng K giữa các vị trí đã có người ngồi, tính toán các giá trị (K + 1) / 2 và trả về giá trị lớn nhất tìm được.

Sau đây là cài đặt tham khảo bằng ngôn ngữ Java.

public class Solution {
    public int maxDistToClosest(int[] seats) {
        int maxDistance = 0;
        int distance = 0;
        int n = seats.length;

        // Trường hợp từ đầu hàng đến ghế đầu tiên có người ngồi
        int i = 0;
        while (seats[i] == 0) {
            distance++;
            i++;
        }
        maxDistance = distance;

        // Tìm khoảng cách giữa các ghế trống
        while (i < n) {
            if (seats[i] == 0) {
                distance++;
            } else {
                maxDistance = Math.max(maxDistance, (distance + 1) / 2);
                distance = 0;
            }
            i++;
        }

        // Trường hợp từ ghế cuối có người ngồi đến cuối hàng
        maxDistance = Math.max(maxDistance, distance);

        return maxDistance;
    }
}

Độ phức tạp thuật toán của giải thuật là O(N), với N là độ dài hàng ghế đã cho.

Quotes

(by lpv)

Blackbird - search engine mới của Github

Blackbird là một search engine vừa mới được phát triển bởi Github. Bên cạnh việc cho phép tìm kiếm code một cách nhanh chóng (được cho là nhanh hơn gấp 2 so với công cụ cũ), Blackbird đồng thời cũng hỗ trợ nhiều tính năng hơn. Ngoài ra Blackbird được viết hoàn toàn bằng Rust.

When byte code bites: Who checks the contents of compiled Python files?

Nhóm nghiên cứu ReversingLabs đã xác định được một cuộc tấn công mới vào PyPI bằng cách sử dụng mã Python đã biên dịch để tránh bị phát hiện - đây có thể là cuộc tấn công đầu tiên lợi dụng việc thực thi trực tiếp file Python Byte Code. Trước đó, vào ngày 20/5, PyPI đã tạm ngưng việc đăng ký thành viên và dự án mới do sự gia tăng các gói phần mềm độc hại.

OpenAI Threatens Popular GitHub Project With Lawsuit Over API Use

Dự án GitHub có tên là GPT4free cho phép bạn truy cập miễn phí vào các mô hình GPT4 và GPT3.5 bằng cách chuyển các truy vấn đó qua các trang web như You.com , Quora và CoCalc và trả lại cho bạn câu trả lời. Tuy chỉ là một dự án mới nhưng đã nhanh chóng nhận được rất nhiều sự quan tâm.

Tuy nhiên theo Xtekky, OpenAI đã gửi một lá thư yêu cầu anh ta gỡ bỏ toàn bộ dự án trong vòng năm ngày nếu không sẽ phải đối mặt với một vụ kiện.

📰Những bài viết hay

Vectorized query engine for distributed database

(by vinhdp)

Các cơ sở dữ liệu quan hệ (CSDL) thường được implement theo Volcano model - từng data row sẽ được lần lượt xử lý - phù hợp với các OLTP query (hoặc tại thời điểm ngày xưa khi mà RAM và CPU còn nhỏ và khá đắt). Nhưng vì nhiều lý do, người sử dụng thường mong muốn thực thi cả những câu query thuộc dạng OLAP như join và aggregate khi xử lý transactional data, để làm được điều này, các CSDL thường tìm cách phân chia workload này trên nhiều CPU core để giảm số lượng data mà mỗi CPU cần xử lý, qua đó góp phần làm giảm response time của query. Nhưng với cách tiếp cận này vẫn chưa thể giải quyết triệt để vấn đề, khi có càng nhiều data đưa vào, càng nhiều CPU core cần thêm vào để xử lý.

Bên cạnh việc thêm nhiều CPU vào để xử lý, các CSDL hiện đại ngày nay còn đi theo một hướng tiếp cận khác là làm sao để cùng một CPU core nhưng có thể xử lý nhiều data cùng một lúc hơn, tận dụng được sức mạnh của SIMD instruction trong nhiều thế hệ CPU mới, đây gọi là Vectorized Engine đã được giới thiệu lần đầu vào năm 2005 bởi paper “MonetDB/X100: Hyper-Pipelining Query Execution”.

Vậy Vectorized Engine là gì? Tại sao nó lại nhanh? Mời các bạn tìm hiểu thông qua bài viết Implementing a Vectorized Engine in a Distributed Database của OceanBase nhé!

What Software Developers Can Do to Learn Effectively

(by quangle80)

Làm việc trong bất kỳ lĩnh vực nào, chúng ta phải luôn không ngừng học hỏi để cải thiện mình, dạo gần đây, cuộc cách mạng AI ngày càng trỗi dậy khiến cho các anh em kỹ sư phần mềm phải trăn trở về “chén cơm” của mình. Điều này vừa tạo ra những thách thức, vừa là những động lực khiến anh em phải suy nghĩ, tìm ra những chủ đề nào đáng dành thời gian để nghiên cứu, nâng cao bản thân mình.

Một loạt những câu hỏi được InfoQ đặt ra cho kỹ sư Tav Herzlich tại Hội nghị NDC Oslo 2023 (diễn ra từ 22-26/5 tại Oslo, Norway) như:

• Làm thế nào để một kỹ sư phần mềm có thể xác định mức độ hiểu biết của mình về một chủ đề hoặc công nghệ?

• Làm thế nào để tránh bị quá tải về khối lượng kiến thức công nghệ quá nhiều?

• Cách quản lý, phân bổ thời gian để tiếp cận, học tập một công nghệ mới?

Mời bạn đọc cùng đi tìm chi tiết câu trả lời qua bài viết

Ten years of AI in review

(by steven.do87)

Một thập kỷ vừa qua là một chặng đường sôi động và đầy ly kỳ đối với lĩnh vực AI, những phát kiến giúp khai phá các tiềm năng của Deep Learning đã tạo ra nhiều cơ hội phát triển bùng nổ trên nhiều lĩnh vực, đơn cử một vài ví dụ điển hình như, xe tự hành, hệ thống thương mại điện tử,...

Bài viết của tác giả Thomas A Dorfer, hiện là DS tại Microsoft sẽ đưa mọi người ngược lại dòng thời gian cùng quan sát về quá trình phát triển của các ứng dụng AI trong suốt 10 năm vừa qua, theo đó là những cái tên đại diện nổi bật cho mỗi giai đoạn như AlexNet(2013) cho đến ứng dụng chat GTP (2022) vẫn đang gây sốt trong cộng đồng công nghệ thời gian gần đây. Với mong muốn cung cấp cho độc giả một góc nhìn toàn cảnh về những tiến bộ vượt bậc trong lĩnh vực AI từ quá khứ sơ khai cho đến khi trở nên quen thuộc và đi vào cuộc sống hàng ngày hiện tại.

Thông qua bài viết tác giả sẽ cho chúng ta cảm nhận được sự thay đổi sâu sắc của các ứng dụng AI đến cuộc sống hiện đại và cách thức chúng ta sẽ làm việc và tương tác với nhau trong tương lai cùng với những quan ngại về việc lạm dụng và lệ thuộc vào AI khi mà các ứng dụng AI càng ngày càng trở nên thông minh hơn và chúng ta cần thận trọng hơn với chúng.

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Maximize Distance to Closest Person

Cho mảng seats biểu thị một dãy hàng ghế, mỗi phần tử trong mảng seats có 1 trong 2 giá trị như sau:

• seats[i] = 1 nghĩa là đã có người ngồi tại ghế thứ i.

• seats[i] = 0 nghĩa là ghế thứ i đang trống.

Lưu ý: vị trí của ghế bắt đầu từ 0

Và trên dãy hàng ghế, luôn luôn tồn tại ít nhất một ghế trống. Alex muốn chọn ghế sao cho khoảng cách tới người gần nhất là lớn nhất có thể. Hãy tìm khoảng cách lớn nhất đó.

Ví dụ:

• Input: seats = [1,0,0,0,1,0,1]

• Output: 2

Với ghế ở vị trí 2, khoảng cách từ Alex đến người gần nhất là 2.

Với các vị trí khác ngoài 2, khoảng cách từ Alex đến người gần nhất là 1.

Vì vậy, khoảng cách lớn nhất tới người gần Alex nhất là "2".

Lời giải tuần trước: Divide Intervals Into Minimum Number of Groups

Để bạn đọc dễ hình dung, ta có thể mô tả lại bài toán bằng việc sắp xếp phòng họp, trong đó mỗi cặp số tự nhiên [left, right] đại diện cho thời gian bắt đầu và kết thúc buổi họp. Ta sẽ đi tìm số phòng họp tối thiểu để tất cả các buổi họp có thể diễn ra.

Giả sử cuộc họp [1, 5] đang diễn ra, cuộc họp tiếp theo là [3, 6], ta nhận thấy rằng cần ít nhất 2 phòng họp bởi [1, 5] và [3, 6] trùng nhau ở khoảng [3, 5].

Giả sử cuộc họp [1, 5] và [3, 6] đang diễn ra, cuộc họp tiếp theo là [6, 8], ta cũng chỉ cần ít nhất 2 phòng họp, bởi tại mốc thời gian 6, cuộc họp [1, 5] đã kết thúc.

Ý tưởng ở đây là mỗi khi ta sắp xếp phòng cho cuộc họp tiếp theo, ta kiểm tra cuộc họp trước đó với thời gian kết thúc nhỏ nhất, ta gọi đây là minEndInterval.

Nếu minEndInterval nhỏ hơn thời gian bắt đầu của cuộc họp tiếp theo, ta tái sử dụng lại phòng họp trước đó. Nếu không, ta cần một phòng họp mới.

Ý tưởng trên được thực hiện với giải thuật như sau:

class Solution {
   public int minGroups(int[][] intervals) {
       // Sort the interval by start time
       Arrays.sort(intervals, Comparator.comparingInt(interval -> interval[0]));
       PriorityQueue<Integer> endTimes = new PriorityQueue<>();

       for (int[] interval : intervals) {
           // Remove the ended interval
           if (!endTimes.isEmpty() && endTimes.peek() < interval[0]) {
               endTimes.poll();
           }
           endTimes.offer(interval[1]);
       }

       return endTimes.size();
   }
}

Độ phức tạp về thời gian của giải thuật là O(nlogn), với n là độ dài của chuỗi đầu vào.

Quotes

(by lpv)

PostgreSQL 16 Beta 1 Released!

Phiên bản mới của PostgreSQL chứa các tính năng mới và cải tiến hiệu suất trong thực thi truy vấn, tăng khả năng xử lý song song cho các truy vấn FULL và RIGHT JOIN, tối ưu hóa cho windows query và nhiều cải tiến khác.

2023 State Of Data + AI

Những xu hướng về Data và AI được thực hiện bởi DataBrick.

📰Những bài viết hay

(by lpv)

Are clouds having their on-prem moment?

Mặc dù public cloud vẫn đang phát triển mạnh mẽ nhưng hiện cũng có một số công ty đang dần chuyển sang mô hình on-prem private clouds (nguồn). Mô hình này được triển khai dựa trên cơ sở hạ tầng của doanh nghiệp, cho phép các doanh nghiệp tự quản lý và vận hành các ứng dụng và dữ liệu của mình trên nền tảng đám mây của riêng mình. Qua đó giúp doanh nghiệp giảm thiểu chi phí và tăng tính linh hoạt trong việc quản lý ứng dụng và dữ liệu.

Trong bài viết này, tác giả đã giới thiệu về xu hướng dịch chuyển sang sử dụng on-prem private clouds của các công ty hiện nay và những lợi ích của việc triển khai mô hình này. Đồng thời Kubernetes cũng đóng vai trò quan trọng trong việc kiểm soát mô hình on-prem private clouds.

Sau hơn 1 thập kỷ xa rời những giá đỡ máy chủ, các công ty dần nhận thấy có những lợi thế nhất định khi triển khai hệ thống cơ sở hạ tầng cục bộ cho một số mục tiêu nhất định. Những gì cũ, lại trở nên mới, nhưng lúc này chúng ta đã có thêm nhiều hương vị để lựa chọn.

Mời các bạn đọc thêm bài viết tại đây.

Indexes in PostgreSQL

Bài viết này nhằm mục đích cung cấp cái nhìn sâu sắc về index trong PostgreSQL, những ưu điểm và nhược điểm của các loại index khác nhau. Bên cạnh đó, tác giả cũng giới thiệu một số cách tối ưu trên index như: Cách xác định những index không cần thiết, index trùng lặp, v.v…

Chi tiết bài viết tại đây.

How RocksDB Works

Trong nhiều năm qua, RocksDB đang được sử dụng rộng rãi tại nhiều nơi. RocksDB đang chạy trên production tại Meta, Microsoft, Netflix v.v… Tại Meta, RocksDB hoạt động như một storage engine cho MySQL. Ngoài ra, một số startup cũng được xây dựng từ RocksDB như PingCAP, Rockset, v.v…

Trong bài viết này, chúng ta cùng tìm hiểu về kiến trúc tổng qua của RocksDB. Phần cấu trúc dữ liệu cốt lõi của RocksDB là Log-structured merge-tree (LSM-Tree). Đây là 1 cây dữ liệu dạng cây được tổ chức theo nhiều cấp độ ( multiple levels), trong đó dữ liệu ở mỗi cấp sẽ được sắp xếp theo khoá (keys). Cấp cao nhất của cây LSM được gọi là MemTable. Đó là một bộ đệm (in-memory buffer) chứa các khóa và giá trị trước khi chúng được ghi vào đĩa. Tất cả các thao tác insert và update sẽ luôn đi qua memtable. Trong trường hợp xảy ra sự cố quy trình hoặc khởi động lại ứng dụng, dữ liệu được lưu trữ trong bộ nhớ sẽ bị mất. Để tránh mất dữ liệu, RocksDB ghi tất cả các bản cập nhật vào Write-ahead Log (WAL) trên disk. Bằng cách này, cơ sở dữ liệu có thể khôi phục trạng thái ban đầu của memtable khi khởi động.

Ngoài ra, còn nhiều kỹ thuật khác mà các bạn có thể đọc tại đây.

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Divide Intervals Into Minimum Number of Groups

Cho danh sách các đoạn intervals, mỗi đoạn biểu diễn bởi cặp số [left, right]. Tìm cách chia tối thiểu các đoạn trong danh sách thành các nhóm sao cho các nhóm không chứa các đoạn giao nhau.

Ví dụ:

Input: intervals = [[5,10],[6,8],[1,5],[2,3],[1,10]]

Output: 3

Giải thích:

• Nhóm 1: [1, 5], [6, 8].

• Nhóm 2: [2, 3], [5, 10].

• Nhóm 3: [1, 10].

Lời giải tuần trước: Remove All Occurrences of a Substring

Một hướng giải quyết đơn giản cho bài toán đó là lặp đi lặp lại việc tìm kiếm lần xuất hiện đầu tiên của chuỗi con part và xoá nó khỏi chuỗi ban đầu cho đến khi chuỗi con không còn xuất hiện nữa. Cài đặt tham khảo bằng ngôn ngữ Java như sau:

public class Solution {
   public String removeOccurrences(String s, String part) {
       StringBuilder sb = new StringBuilder(s);
       while (true) {
           int index = sb.indexOf(part);
           if (index == -1) {
               break;
           }
           sb.delete(index, index + part.length());
       }
       return sb.toString();
   }
}

Độ phức tạp của giải thuật là O(N^2) với N là độ dài chuỗi s.

📖Learning

(by lpv)

Rust là một ngôn ngữ đang bắt đầu nhận được sự quan tâm từ cộng đồng lập trình viên thời gian gần đây. Bạn đã có thể sử dụng Rust để xây dựng thư viện cho kernel Linux, hay viết một extension cho PostgreSQL. Và nếu bạn chưa biết bắt đầu từ đâu, thì Android Team vừa cho ra mắt một khóa học Rust trong … 3 ngày ;)

Trong khóa học này sẽ cover những nội dung cơ bản và cần thiết để bắt đầu lập trình như cú pháp, concurrency, error handling, v.v… Và tất nhiên là đi kèm một số nội dung liên quan tới Android.

Các bạn có thể thử dành vài ngày cuối tuần để trải nghiệm khóa học này tại: Comprehensive Rust.

🛠️Code & Tools

• How Much Memory Do You Need to Run 1 Million Concurrent Tasks?

• How Much Are GitHub Stars Worth to You?

Hãy reply email này (hoặc gửi câu trả lời đến newsletter@grokking.org) để chia sẻ ý kiến của mình nhé! Ban biên tập sẽ chọn ra những câu trả lời hay nhất để trao tặng phần quà là một quyển Dijkstra tập 2 (bản in).

Mong nhận được nhiều góp ý từ các bạn.

P/S: Các bạn nhớ gửi kèm theo thông tin liên hệ để Ban biên tập có thể tiện gửi quà nhé.

📻News

(by lpv)

Go Developer Survey 2023 Q1 Results

Một khảo sát được thực hiện trên gần 6000 lập trình viên về Golang. Kết quả này sẽ giúp Go team có thể tập trung hơn vào những phần quan trọng.

DataDog và sự cố 5 triệu $

Cùng tìm hiểu về sự cố xảy ra gần đây trên DataDog.

📰Những bài viết hay

The Part of PostgreSQL We Hate the Most

(by lpv)

Trong nhiều năm gần đây, PostgreSQL đang trở thành một DBMS được sử dụng khá rộng rãi. Tuy nhiên bên cạnh những ưu điểm của mình, PostgreSQL cũng có những nhược điểm kèm theo đó. Trong bài viết này, tác giả giải thích về MVCC (Multi Version Concurrency Control) trong Database hoạt động như thế nào, và so sánh cụ thể cách cài đặt giữa PostgreSQL và các DBMS khác.

Mục tiêu của MVCC trong DBMS là cho phép nhiều truy vấn đọc và ghi vào cơ sở dữ liệu đồng thời mà không can thiệp lẫn nhau khi có thể. Ý tưởng cơ bản của MVCC là DBMS không bao giờ ghi đè lên các hàng (row) hiện có. Thay vào đó, đối với mỗi hàng (logic), DBMS duy trì nhiều phiên bản (vật lý). Khi ứng dụng thực hiện một truy vấn, DBMS sẽ xác định phiên bản nào cần truy xuất để đáp ứng yêu cầu theo một số thứ tự phiên bản (ví dụ: timestamp). Lợi ích của phương pháp này là nhiều truy vấn có thể đọc các phiên bản cũ hơn của các hàng mà không bị chặn bởi một truy vấn khác đang cập nhật nó. Ngoài ra loại bỏ nhu cầu lock record, ngăn người đọc truy cập dữ liệu trong khi người viết sửa đổi cùng một item.

Một số vấn đề xảy ra đối với PostgreSQL MVCC được tác giải liệt kê và giải thích cụ thể như: Version Copying, Table Bloat, Secondary Index Maintenance, Vacuum Management. Mời các bạn cùng đọc và tìm hiểu chi tiết.

Example of PostgreSQL index maintenance operations with a non-HOT update

How to measure your technical debt

(by steven.do87)

Nợ kỹ thuật (technical debt) được hiểu như sự đánh đổi giữa việc rút ngắn thời gian phát triển và cho ra đời một chức năng mới một sản phẩm phần mềm mới với việc đảm bảo một hệ thống hoạt động ổn định và đáng tin cậy, và đây là một thành phần không thể thiếu trong quy trình phát triển phần mềm.
Ngày nay, các chỉ số technical debt ngày càng được các đơn vị và doanh nghiệp phát triển phần mềm quan tâm và càng phổ biến, chúng được thiết kế nhằm giúp cho các doanh nghiệp có thể hiểu và đánh giá được dữ liệu liên quan đến rủi ro về mặt kỹ thuật đối với các hệ thống phần mềm trước khi các vấn đề nghiêm trọng thực sự xuất hiện.
Technical debt có thể được phân làm 04 loại bao gồm: code debt (quan trọng nhất), quản lý tài liệu (documentation), bảo mật (security), và các công cụ hoặc công nghệ được sử dụng bởi đội ngũ phát triển (Engineering tooling).
Thông qua bài viết, tác giả Alex Omeyer tại stepsize đã gợi ý 08 chỉ số giúp đo lường và đánh giá được các mức độ rủi ro về technical debt như sau:
+ Tỷ lệ New Bugs vs Closed Bugs
+ Debt Index: tỷ lệ issues đã resolved trên tổng số issues
+ Code Quality: chất lượng mã nguồn
+ Cycle Time: thời gian xử lý vấn đề
+ Code Churn: số liệu đếm số lần một line code bị xoá, thay thế hoặc viết lại.
+ Code Coverage: độ bao phủ khi thực thi của mã nguồn.
+ Code Ownership: mức độ hiểu được mã nguồn
+ Technical Debt Ratio (TDR): tỷ lệ nợ kỹ thuật

Để có thể hiểu thêm về các chỉ số đo lường trên, các bạn có thể tham khảo thông tin chi tiết tại bài viết gốc.

Modern Approaches to Complex IT Development: Sorting Out Team Communications

(by steven.do87)

Trong bối cảnh ngành CNTT đang có những thay đổi nhanh chóng, các đội phát triển ngày càng đối mặt với các vấn đề khó khăn trong quá trình phát triển các dự án phần mềm, điển hình như vấn đề về ngân sách, thời gian cũng như giao tiếp trao đổi thông tin thiếu hiệu quả trong khi vẫn phải cố gắng bắt kịp tiến độ và các yêu cầu nghiệp vụ thay đổi liên tục.

Thông qua kinh nghiệm làm việc và tham gia các dự án phần mềm, và quá trình áp dụng các công cụ, công nghệ mới cho đến quá trình chuyển đổi cho doanh nghiệp, tác giả đã nhận định ra 03 vấn đề mà các nhóm phát triển phần mềm ngày nay thường xuyên gặp phải.

Trong số đó vấn đề thường xuyên vấp phải đầu tiên đó là việc giao tiếp và cộng tác thiếu hiệu quả giữa các bộ phận và thành viên trong mỗi bộ phận, và vấn đề này bắt nguồn từ sự thiếu minh bạch hoặc truyền đạt thông tin sai lệch do cơ cấu tổ chức chưa tối ưu.

Yếu tố tiếp theo tác giả xem xét đến đó là sự phức tạp ngày càng tăng của các quy trình phát triển phần mềm cũng như hạ tầng CNTT.

Cuối cùng đó là việc các mục tiêu và yêu cầu dự án không được cập nhật liên tục dẫn đến nhầm lẫn, thiếu sót và phát sinh thêm nhiều vấn đề gây ảnh hưởng đến tiến độ và kết quả của dự án.

Đây là bài viết khởi đầu cho loạt bài của tác giả Alex Lashkov về việc đề xuất một phương pháp tiếp cận mới phù hợp hơn với quy trình phát triển phần mềm phức tạp ngày nay.

Using CockroachDB to Reduce Feature Store Costs by 75%

(by steven.do87)

Trong quá trình xây dựng các nền tảng máy học Machine Learning, các kỹ sư tại DoorDash đã nhận định rằng việc sử dụng kết hợp nhiều cơ sở dữ liệu khác nhau có thể giúp đơn giản hóa quá trình vận hành cũng như đem lại hiệu quả đáng kể.

Với nỗ lực tìm kiếm một phương án hiệu quả hơn nhằm đáp ứng nhu cầu thực thi các tác vụ Machine Learning, các kỹ sư tại DoorDash đã quyết định thử nghiệm sử dụng một cơ sở dữ liệu khác để bổ sung cho Redis hiện tại đang đóng vai trò là lưu trữ các online feature phía backend và họ đã quyết định sử dụng CockroachDB làm kho lưu trữ các feature.

Sau khi thử nghiệm và đánh giá hiệu quả giúp giảm trung bình được 75% mức chi phí trên mỗi đơn vị lưu trữ nếu tổ chức lưu trữ trên các nền tảng Cloud, và vẫn đảm bảo được độ trễ tối thiểu.

Bài viết mô tả quá trình các kỹ sư DoorDash tiến hành thử nghiệm và các bài học đã được rút ra về cách thức vận hành các cluster Redis trên quy mô lớn và khi áp dụng Cockroach để hỗ trợ cho nền tảng serving online của DoorDash.

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Remove All Occurrences of a Substring

Cho 2 chuỗi "s" và "part", hãy thực hiện biến đổi chuỗi "s" cho tới khi sự xuất hiện của tất cả các chuỗi con trùng với "part" được loại bỏ.

Phép biến đổi được thực hiện như sau:

• Tìm chuỗi con trái nhất trong "s" trùng với "part" và loại bỏ khỏi "s"

• Lặp lại bước trên cho tới khi không còn sự xuất hiện của chuỗi con "part" trong "s"

Điều kiện của đầu vào:

• 1 <= s.length <= 1000

• 1 <= part.length <= 1000

• "s" và "part" chỉ chứa 26 ký tự chữ thường trong tiếng Anh

Ví dụ:

• Input: s = "daabcbaabcbc", part = "abc"

• Output: "dab"

• Giải thích:

  • s = "daabcbaabcbc", loại bỏ "abc" từ vị trí thứ 2, ta thu được s = "dabaabcbc".

  • s = "dabaabcbc", loại bỏ "abc" từ vị trí thứ 4, ta thu được s = "dababc".

  • s = "dababc", loại bỏ "abc" từ vị trí thứ 3, ta thu được s = "dab".

Lời giải tuần trước: Jump Game

Hướng tiếp cận 1: giải thuật quay lui

Bắt đầu từ vị trí xuất phát tại ô thứ 0, ta thực hiện như sau:

1. lần lượt nhảy đến những ô cho phép

2. tại mỗi ô đích ta lặp lại bước 1

Nếu ở một lần nhảy bất kỳ, ta tới được vị trí cuối cùng n - 1, với n là độ dài của mảng đầu vào, ta trả lại kết quả là true.

Giải thuật quay lui sẽ có độ phức tạp thời gian là O(2^n).

Hướng tiếp cận 2: quy hoạch động

Nếu ta biết tại vị trí A ta có thể nhảy tới ô cuối cùng, và tại vị trí B ta có thể nhảy tới vị trí A, ta có kết luận từ vị trí B ta có thể nhảy tới ô cuối cùng.

Dựa trên nhận xét này, ta chỉ cần duyệt mảng đầu vào và đánh dấu những ô có thể nhảy được tới vị trí cuối cùng bằng giải thuật như sau:

class Solution {
   public boolean canJump(int[] nums) {
       int n = nums.length;
       boolean[] memo = new boolean[n];

       // from n - 1 index, always can jump to n - 1
       memo[n - 1] = true;

       for (int i = n - 2; i >= 0; i--) {
           for (int s = 1; s <= nums[i]; s++) {
               if (i + s >= n - 1 || memo[i + s]) {
                   // can jump to n - 1 from index i
                   memo[i] = true;
                   break;
               }
           }
       }
       return memo[0];
   }
}

Độ phức tạp thời gian của giải thuật là O(n^2)

Hướng tiếp cận 3: tối ưu giải thuật quy hoạch động

Tương tự như giải thuật ở hướng tiếp cận quy hoạch động, nhưng thay vì sử dụng mảng memo để đánh dấu những vị trí có thể nhảy tới ô cuối cùng, ta thực ra chỉ cần biết vị trí bên trái nhất mà ta có thể nhảy tới vị trí cuối cùng, ta gọi đây là "leftmostReachToEndIndex".

Nếu ở vị trí hiện tại, ta có thể nhảy tới "leftmostReachToEndIndex", ta cũng có thể nhảy tới vị trí cuối cùng.

Giải thuật được thực hiện như sau:

class Solution {
   public boolean canJump(int[] nums) {
       // from n - 1 index, always can jump to n - 1
       int leftmostReachToEndIndex = nums.length - 1;
       for (int i = nums.length - 1; i >= 0; i--) {
           // if from i, we can jump to leftmostReachToEndIndex, we can reach to end from i
           // thus, update leftmostReachToEndIndex = i
           if (i + nums[i] >= leftmostReachToEndIndex) {
               leftmostReachToEndIndex = i;
           }
       }
       return leftmostReachToEndIndex == 0;
   }
}

Độ phức tạp thời gian của giải thuật là O(n), độ phức tạp về không gian là O(1).

💭Góc bạn đọc

Bạn đọc T.L chia sẻ câu trả lời cho câu hỏi “Theo bạn trong 3-4 năm nữa, một buổi phỏng vấn Software Engineer sẽ diễn ra như thế nào? Nó sẽ khác gì với cách chúng ta đang phỏng vấn hiện tại?”

Theo mình thấy nhiều công ty hay có quy trình phỏng vấn như sau:

• Screening test

• Bài assignment take home

• Phỏng vấn trực tiếp thì hay hỏi về thuật toán, kiến thức về các loại ngôn ngữ lập trình, …

Theo mình, với sự phát triển của các công cụ AI, Copilot như hiện tại thì các bài screening test dạng trắc nghiệm có khả năng sẽ bỏ. Hồi xưa mấy bài screening test tốt vì có thể hỏi một số câu mang tính nhận định, hoặc có giới hạn thời gian thì còn được, giờ thì câu hỏi nhận định cũng bị bot trả lời rồi nên cũng không còn hiệu quả nữa.

Phỏng vấn trực tiếp thì chắc sẽ là hình thức tốt nhất vì lúc đó ứng viên sẽ phản ứng dựa trên kiến thức thật của mình nên việc dựa vào bot nhiều cũng không hiệu quả. Tuy nhiên, mình thì thấy phỏng vấn tương lai chắc sẽ thiên về tình huống và xử lý vấn đề nhiều hơn, vì các thuật toán bây giờ ít quan trọng. Chỉ cần mô tả yêu cầu kèm theo input/output đúng là có khi các ứng dụng Copilot đã sinh ra code kèm test case cho mình luôn rồi.

Ngoài ra, bạn đọc Thịnh có gửi đến thắc mắc, mong các bạn có thể chia sẻ góp ý cho bạn ấy. Như thường lệ, các câu trả lời hay sẽ nhận được một phần quà là một quyển Dijkstra tập 2 bản in.

Công việc của Software Engineer liệu có phải chỉ có code không ạ? Em đang làm Software Engineer ở một công ty công nghệ cũng lớn, nhưng công việc hàng ngày của em thì lại xoay quanh cấu hình Kafka Connect, cấu hình github repo, nâng cấp các phiên bản phần mềm các team khác đang dùng, … và rất ít code. Nên em không biết là như vậy thì có gọi là software engineer không, và em có đang đi đúng hướng không?

Quotes

Ở kỳ trước, nhóm biên tập có đặt ra câu hỏi “Bạn nghĩ công việc của Software Engineer sẽ thay đổi như thế nào sau 3-4 năm nữa?“ và nhận được một số ý trả lời từ các bạn đọc. Các bạn có thể tham khảo ở mục Góc bạn đọc bên dưới. Xin cảm ơn các bạn đã nhiệt tình đóng góp ý tưởng.

Trong newsletter kỳ này, nhóm biên tập xin đặt ra câu hỏi khác: “Theo bạn trong 3-4 năm nữa, một buổi phỏng vấn Software Engineer sẽ diễn ra như thế nào? Nó sẽ khác gì với cách chúng ta đang phỏng vấn hiện tại?”

Hãy reply email này trước khi số newsletter tiếp theo được gửi đi (hoặc gửi câu trả lời đến newsletter@grokking.org) để chia sẻ ý kiến của mình nhé! Ban biên tập sẽ chọn ra những câu trả lời hay nhất để trao tặng phần quà là một quyển Dijkstra tập 2 (bản in). Mong nhận được nhiều góp ý từ các bạn.

P/S: Các bạn nhớ gửi kèm theo thông tin liên hệ để Ban biên tập có thể tiện gửi quà nhé.

📰Những bài viết hay

Data versioning at scale

(by Bing and n^4)

Einat Orr, một trong những thành viên sáng lập của Treeverse, đã có một bài thuyết trình mang tên “Data Versioning at Scale: Chaos and Chaos Management” tại QCon New York.

Trong bài thuyết trình này, Einat thảo luận về cách dữ liệu thay đổi theo thời gian do các yếu tố khác nhau, chẳng hạn như lỗi, cập nhật, ước tính và nguồn mới. Sự thay đổi này sẽ ảnh hưởng đến chất lượng, độ tin cậy và tính nhất quán của các quyết định dựa trên dữ liệu. Einat cũng giải thích các thách thức trong việc quản lý phiên bản dữ liệu (version control), chẳng hạn như sự hợp tác, kế thừa dữ liệu (lineage), khả năng tái sản xuất (reproducibility), tính nhất quán giữa các bảng (cross-collection consistency), và sự cần thiết phải có hạ tầng có thể xử lý được sự phức tạp và hỗn loạn của dữ liệu.

Bên cạnh đó, Einat xem xét một số giải pháp hiện có cung cấp version control và làm nổi bật các ưu nhược điểm của mỗi phương pháp.

• Git là giải pháp versioning phổ biến được sử dụng trong lĩnh vực phát triển phần mềm. Tuy nhiên, Git không được thiết kế để quản lý dữ liệu lớn và phân tán. Điều này có thể gây ra những vấn đề về hiệu suất và khả năng mở rộng khi sử dụng Git để quản lý dữ liệu lớn.

• Một giải pháp khác là DVC (Data Version Control), một công cụ versioning mã nguồn mở được thiết kế đặc biệt cho việc quản lý dữ liệu lớn và phân tán. DVC cung cấp các tính năng như versioning, lineage tracking và data sharing. Tuy nhiên, DVC không hỗ trợ các tính năng như merge và conflict resolution.

• Ngoài ra, LakeFS là một giải pháp versioning dữ liệu mới nhất được thiết kế để quản lý các data lake trên các hệ thống đám mây. LakeFS cung cấp các tính năng như versioning, lineage tracking và data sharing. Nó cũng hỗ trợ các tính năng như merge và conflict resolution.

Understand Linux namespace by creating a docker like engine

(by n^4)

Trong khảo sát StackOverflow năm 2022, Docker đã trở thành một công cụ quan trọng cho các nhà phát triển phần mềm và đã trở nên rất phổ biến. Đã có nhiều bài viết giới thiệu về cơ chế hoạt động của Docker rồi, nhưng trong bài viết này, một bạn kỹ sư ở Zalopay chia sẻ cách để hiểu cơ chế hoạt động thông qua quá trình tạo ra một hệ thống quản lý container mới. Hy vọng bài viết sẽ hữu ích cho các bạn mới bắt đầu làm quen với docker nói riêng và linux nói chung.

Technical leadership and gluework

(by Bing + n^4)

Bạn đã làm senior trong 4-5 năm, sắp tới bạn được thăng chức trở thành trưởng nhóm. Tuy nhiên, bạn nhận ra công việc trưởng nhóm không giống như bạn nghĩ vì hóa ra bạn phải làm những việc không tên tưởng chừng chẳng liên quan đến coding như tạo tài liệu quy trình, viết báo cáo, giới thiệu cho các thành viên mới trong nhóm…

Tuy nhiên, hóa ra những công việc ít liên quan này lại góp phần quan trọng trong việc thành bại của một dự án phần mềm, và cũng là đòi hỏi không thể thiếu của một người leader/manager. Thay vì né tránh, chúng ta sẽ cần phải học cách làm những công việc này một cách hiệu quả.

Bài thuyết trình này sẽ giúp bạn hiểu rõ hơn về những công việc mang bản chất giúp “kết dính” (glue work) và cách phân bổ công việc này một cách hợp lý để đảm bảo sự thành công của nhóm. Diễn giả là Tanya Reilly, một kỹ sư phần mềm chính tại Squarespace và từng làm việc tại Google trong 12 năm.

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Jump Game

Cho trước một mảng số nguyên nums. Bắt đầu từ vị trí đầu tiên, xác định xem có thể di chuyển đến vị trí cuối cùng hay không, biết tại mỗi vị trí i, khoảng cách xa nhất có thể di chuyển là nums[i]

Ví dụ:

• Input: nums = [2,3,1,1,4]

• Output: true

• Giải thích: Nhảy từ vị trí đầu tiên đến vị trí thứ hai (giá trị 3), sau đó nhảy từ vị trí thứ hai đến vị trí cuối cùng (giá trị 4).

Lời giải tuần trước: Find the duplicate number

Một cách tiếp cận đơn giản để giải quyết bài toán này là sử dụng một bảng đánh dấu để lưu lại việc xuất hiện của các số. Với ngôn ngữ Java thì ta có thể sử dụng Map hoặc Set. Tuy nhiên, giải pháp này yêu cầu sử dụng thêm O(n) không gian và không đáp ứng được yêu cầu của bài toán.

Thay vào đó, chúng ta có thể sử dụng thuật toán Floyd (hay còn gọi là thuật toán "thỏ và rùa") để giải quyết bài toán này.

Thuật toán Floyd là một thuật toán được sử dụng để tìm kiếm chu kỳ trong một danh sách liên kết, và nó cũng có thể được sử dụng để giải quyết bài toán này.

Các bước giải quyết bài toán "find-the-duplicate-number" bằng thuật toán Floyd như sau:

1. Khởi tạo hai biến "tortoise" và "hare" ban đầu trỏ đến phần tử đầu tiên trong mảng.

2. Với mỗi bước, "tortoise" đi một bước và "hare" đi hai bước.

3. Nếu "tortoise" và "hare" gặp nhau, chúng ta đã tìm thấy một chu kỳ trong mảng

4. Tiếp theo, ta sẽ khởi tạo một con trỏ "ptr" trỏ đến phần tử đầu tiên trong mảng và di chuyển con trỏ "tortoise" và "ptr" cùng một bước mỗi lần cho đến khi chúng gặp nhau.

Phần tử mà chúng ta gặp lại trong quá trình di chuyển "tortoise" và "ptr" chính là phần tử trùng lặp.

Độ phức tạp của thuật toán này là O(n), trong đó n là kích thước của mảng. Dưới đây là cài đặt tham khảo của bài toán này sử dụng thuật toán Floyd bằng ngôn ngữ Java.

class Solution {
    public int findDuplicate(int[] nums) {
        int tortoise = nums[0];
        int hare = nums[0];
        while (true) {
            tortoise = nums[tortoise];
            hare = nums[nums[hare]];
            if (tortoise == hare) {
                break;
            }
        }
        int ptr = nums[0];

        while (tortoise != ptr) {
            tortoise = nums[tortoise];
            ptr = nums[ptr];
        }
        return ptr;
    }
}

💭Góc bạn đọc

Góc bạn đọc kỳ này có một chia sẻ từ một bạn đọc gửi đến nhóm biên tập. Rất cảm ơn bạn Q.Hương đã đóng góp, mong nhận được nhiều sự đóng góp hơn từ phía bạn.

Bạn nghĩ công việc của Software Engineer sẽ thay đổi như thế nào sau 3-4 năm nữa?

Công việc của kỹ sư phần mềm sẽ tiếp tục thay đổi trong tương lai với sự phát triển của trí tuệ nhân tạo (AI) và các công nghệ liên quan. Một số thay đổi có thể bao gồm:
1/ Tăng cường sử dụng trí tuệ nhân tạo: Với sự ra đời của các công nghệ AI như chatbot, image recognition, và natural language processing, kỹ sư phần mềm sẽ cần phải trang bị kỹ năng và kiến thức mới để phát triển, triển khai và tối ưu hóa các ứng dụng sử dụng trí tuệ nhân tạo.
2/ Sự phát triển của các nền tảng phát triển low-code và no-code: Các công cụ này đang ngày càng trở nên phổ biến, giúp cho những người không có kinh nghiệm lập trình cũng có thể tạo ra các ứng dụng phần mềm. Điều này có thể ảnh hưởng đến việc cần thiết của kỹ sư phần mềm trong các công ty và tổ chức.
3/ Tăng cường quản lý dữ liệu: Sự phát triển của công nghệ đám mây và big data sẽ tạo ra nhiều cơ hội cho kỹ sư phần mềm phát triển các ứng dụng dựa trên dữ liệu. Tuy nhiên, đồng thời cũng đặt ra thách thức về quản lý, an toàn và bảo mật dữ liệu.
4/ Sự tăng cường về bảo mật và an ninh mạng: Khi các mối đe dọa mạng ngày càng phức tạp hơn, kỹ sư phần mềm sẽ phải trở thành chuyên gia về bảo mật và an ninh mạng. Các công nghệ bảo mật mới sẽ cần được phát triển và triển khai để bảo vệ các ứng dụng phần mềm.
Tổng thể, công việc của kỹ sư phần mềm sẽ tiếp tục thay đổi để đáp ứng với sự phát triển của công nghệ. Kỹ sư phần mềm cần phải tập trung vào các kỹ năng và kiến thức mới để trở thành người chủ chốt trong việc phát triển các ứng dụng phần mềm thông minh, an toàn và hiệu quả.

-Q.H-

Bên cạnh những ý bạn Hương đã nêu ra, một bạn đọc tên L cũng có bổ sung thêm một số ý tưởng sau:

1/ Nâng cao khả năng đặt câu hỏi và mô tả yêu cầu. Tôi tin vào quan điểm được nhiều người đề cập đó là đặt ra đúng câu hỏi sẽ khó hơn là tìm kiếm câu trả lời. Việc phổ biến của các LLM cùng các ứng dụng generation sẽ khiến cho công việc của kỹ sư phần mềm tập trung vào khía cạnh problem solving và đặt ra vấn đề nhiều hơn. Tôi tin là khi bạn đặt ra đúng câu hỏi, các hệ thống AI và assistant của tương lai sẽ giải quyết vấn đề giúp bạn một cách dễ dàng.

2/ Kiến thức nền tảng chuyên sâu và khả năng ra quyết định. Việc các hệ thống AI thông minh hơn sẽ khiến cho việc xây dựng phần mềm mới và vận hành ít tốn nhân lực hơn. Tuy nhiên, dựa trên kinh nghiệm bản thân làm oncall cho các hệ thống thì tôi thấy con người vẫn nên là những lúc ra quyết định lúc khẩn cấp. Ví dụ như khi một hệ thống quan trọng trong công ty bị lỗi nghiêm trọng dẫn đến thất thoát doanh thu, AI sẽ giúp chúng ta có được thông tin nhanh và kịp thời nhất. Nhưng làm sao để xử lý vấn đề trước mắt vẫn là thứ cần con người ra quyết định. Và trong những lúc khẩn cấp như thế này, bạn cần phải có kiến thức nền tảng và lượng kinh nghiệm sâu để hiểu rõ bản chất sự cố và ra quyết định càng nhanh càng tốt chứ không thể ngồi hỏi AI tới lui được.

Rất cảm ơn hai bạn đã đóng góp ý tưởng. Các bạn đọc khác có ý tưởng bổ sung vẫn cứ tham gia đóng góp nhé.

💡Quotes

💁🏻Đóng góp nội cho Grokking Newsletter

Bạn có thể gửi nội dung đóng góp đến nhóm biên tập newsletter thông qua email newsletter@grokking.org. Các nội dung các bạn có thể đóng góp:

• Nếu bạn có một bài viết muốn chia sẻ, bạn có thể gửi link bài viết kèm một đoạn giới thiệu ngắn bằng tiếng Việt.

• Nếu bạn có vài suy nghĩ muốn chia sẻ đến cộng đồng, bạn có thể gửi nội dung trực tiếp đến chuyên mục Góc dành cho bạn đọc.

• Nếu bạn có câu hỏi và muốn các bạn đọc của Grokking cùng tham gia góp ý, bạn cũng có thể gửi đến Grokking nhé. Câu hỏi của bạn có thể được đăng dưới dạng ẩn danh.

• Nếu công ty bạn có tổ chức sự kiện techtalk và muốn giới thiệu rộng rãi hơn đến cộng đồng, các bạn gửi link sự kiện cùng hình ảnh banner và nội dung chia sẻ. Nhóm sẽ giúp chia sẻ lên newsletter và fanpage nếu nội dung phù hợp.

Trong newsletter kỳ này, ban biên tập Grokking muốn đặt ra một câu hỏi: “Bạn nghĩ công việc của Software Engineer sẽ thay đổi như thế nào sau 3-4 năm nữa?”

Hãy reply email này (hoặc gửi câu trả lời đến newsletter@grokking.org) để chia sẻ ý kiến của mình nhé! Ban biên tập sẽ chọn ra những câu trả lời hay nhất để trao tặng phần quà là một quyển Dijkstra tập 2 (bản in).

Mong nhận được nhiều góp ý từ các bạn.

P/S: Các bạn nhớ gửi kèm theo thông tin liên hệ để Ban biên tập có thể tiện gửi quà nhé.

📰Những bài viết hay

Fixing duplicate stories in Medium’s For You feed

(by quangle)

Vài tháng trước, đội ngũ kỹ sư tại Medium nhận được nhiều báo cáo (3-4k lượt/ngày) liên quan đến vấn đề trùng lặp bài viết ở chuyên mục For You feed trên các thiết bị mobile apps bao gồm iOS và Android.

Giải thích ngắn gọn thì để truy xuất các bài viết ở For You feed, hệ thống sẽ chuyển tiếp các requests của users từ Medium’s GraphQL API đến rex service (recommendation - service được xây dựng bằng Go, đáp ứng việc tính toán, truy vấn các bài viết) và trả kết quả về cho users. Trong đó rex service có áp dụng một số kỹ thuật như phân trang, caching ở redis theo key `$userId:HOMEPAGE` với TTL 30 phút.

Qua quá trình rà soát, các kỹ sư phát hiện hai vấn đề dẫn đến lỗi trên và khắc phục như sau:

1- Khắc phục trình trạng context bị hủy trước khi dữ liệu được lưu vào cache

Khi user request feed, rex service tạo một bản feed cho người dùng (gọi là bản A) và lưu vào cache thông qua cơ chế background goroutine.. Nhưng việc sử dụng chung request context đã phát sinh vấn đề, ngay khi request được hoàn thành thì request context cũng sẽ bị hủy. 

Nếu tiến trình hủy context xảy ra trước tiến trình lưu vào cache sẽ khiến cho việc lưu bản feed vào cache không được hoàn thành, bản A sẽ không được lưu vào cache. Sau đó, nếu người dùng tiếp tục request feed, do bản feed trước đó không được lưu vào cache, nên rex service tiến hành tạo một bản feed mới (gọi là bản B) và gửi về cho người dùng. Do bản A và bản B có khả năng có bài trùng nhau nên người dùng sẽ thấy trùng lặp bài viết trên feed của họ.

2 - Đảm bảo dữ liệu cache được tái sử dụng

Nếu trước đây, khi user request một page từ For You feed, hệ thống sẽ nhận hai tham số: limit (bắt buộc) và cursor (không bắt buộc) và luôn trả về kết quả của current feed instance thì giờ đây, nhóm cải tiến bằng cách sử dụng thêm một tầng caching qua feedId với key  `$userId:HOMEPAGE:$feedId` và điều chỉnh TTL cho các cached key này. 

Điều chỉnh này giúp đảm bảo cặp giá trị feed InstanceID và feed value phải đi cùng nhau, nếu không thỏa phải generate feed instance mới để caching cùng feed value, hướng tiếp cận giúp giải quyết bài toán duplicate feed.

Để tìm hiểu chi tiết hơn về từng cách giải quyết bài toán cũng như những trade-off mà team Medium gặp phải, mời bạn đọc cùng tham khảo bài viết.

The Ultimate Deliberate Practice Guide

(by chatGPT + n^4)

Thực hành có chủ đích (deliberate practice) là cách để cải thiện mình ở mọi mặt trong cuộc sống bằng cách liên tục rèn luyện và nhận phản hồi. Các chuyên gia trong mọi lĩnh vực đều biết rõ điều này và sử dụng nó để xây dựng kiến thức chuyên môn của mình.

Bài báo này giải thích rằng thực hành có chủ đích đòi hỏi một mục tiêu cụ thể và phản hồi liên tục để bạn biết mình đang làm gì và đang tiến bộ như thế nào. Không chỉ làm việc một cách siêng năng mà còn cần tập trung vào những điểm yếu cần cải thiện. Đó là cách làm thông minh và hiệu quả hơn. Mời các bạn cùng tham khảo bài báo để hiểu thêm về Thực hành có chủ đích cũng như ứng dụng nó để học hỏi và rèn luyện kỹ năng hiệu quả hơn.

Attention is all you need

(by chatGPT + n^4)

Trong thế giới hiện đại của chúng ta, công nghệ trí tuệ nhân tạo nói chung và lĩnh vực ngôn ngữ tự nhiên (NLP) nói riêng đang phát triển với tốc độ nhanh chóng và nhiều cách tiếp cận mới liên tục được phát minh ra. Trong bài viết này, chúng ta sẽ tìm hiểu thêm một kiến trúc mới Transformer đang được ứng dụng ngày càng rộng rãi trong 4-5 năm trở lại đây. Kiến trúc này được giới thiệu trong bài báo "Attention Is All You Need" của nhóm tác giả tại Google Brain được xuất bản trên trang arXiv vào tháng 6 năm 2017.

Trong bài báo, các tác giả giới thiệu một mô hình NLP tái cấu trúc mới gọi là Transformer. Kiến trúc Transformer đã đạt được kết quả tốt hơn so với các phương pháp trước đây trong nhiều tác vụ NLP quan trọng như dịch máy và sinh văn bản.

Kiến trúc Transformer được thiết kế dựa trên cơ chế attention, một kỹ thuật trong NLP cho phép mô hình tập trung vào các phần quan trọng của câu để phân tích. Điểm đáng chú ý của Transformer là nó không sử dụng các lớp RNN (mạng nơ-ron tái cấu trúc) như các mô hình NLP trước đây, mà thay vào đó sử dụng các lớp attention để tập trung vào các phần quan trọng của dữ liệu đầu vào. Kiến trúc Transformer bao gồm hai phần chính: encoder và decoder. Mỗi phần sử dụng nhiều lớp attention và các lớp kết nối đầy đủ để học cách mã hóa và giải mã thông tin trong các tác vụ NLP.

Các mô hình dựa trên kiến trúc Transformer đã đạt được nhiều kết quả ấn tượng trong nhiều lĩnh vực. Một số mô hình nổi bật bao gồm: BERT của Google, GPT-4 của OpenAI, RoBERTa của Facebook.

Mời các bạn cùng đọc lại bài báo “Attention Is All You Need” để hiểu thêm về kiến trúc này.

P/S: Chữ GPT trong phần mềm ChatGPT phổ biến hiện này là viết tắt của Generative Pre-training Transformer.

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Find the Duplicate Number

Cho một mảng số nguyên "nums" có độ dài n + 1. Mảng "nums" chứa số nguyên dương trong khoảng [1, n]. Mảng "nums" chỉ tồn tại duy nhất 1 cặp số trùng nhau. Hãy tìm số bị trùng mà không thay đổi giá trị của mảng và giải thuật có độ phức tạp không gian là O(1).

Lời giải tuần trước: Lexicographical Numbers

Cách tiếp cận đầu tiên ta có thể dễ dàng nhận thấy là thực hiện chuyển đổi số sang chuỗi, sắp xếp danh sách chuỗi theo thứ tự từ điển, cuối cùng, ta chuyển đổi chuỗi về số nguyên. Độ phức tạp thời gian của giải thuật sẽ là O(n*logn), trong đó n là độ dài của mảng đầu vào, độ phức tạp không gian của giải thuật là O(n).

Dựa trên hướng tiếp cận trên, ta cũng có thể sử dụng cấu trúc dữ liệu Trie để tìm kiếm mảng đã được sắp xếp theo thứ tự từ điển bằng phương pháp duyệt cây theo chiều sâu (DFS).

Nếu bạn đọc vẽ cấu trúc dữ liệu Trie và thực hiện tìm kiếm theo chiều sâu, bạn đọc có thể nhận thấy: ở mỗi nút "current", ta có tìm nút tiếp theo "next" như sau:

Giả sử với n = 999

1. với current = 11, next = current * 10 = 110

2. với current = 110, next = current + 1 = 111

Ta tiếp tục bước 2 cho tới khi current = 119, lúc này next = current / 10 + 1 = 12.

Lưu ý, nếu số current có kết thúc với nhiều hơn một số 9, ví dụ 199, số tiếp theo là 2.

Bằng cách này, ta không thực sự cần phải sử dụng cấu trúc dữ liệu Trie mà có thể thực hiện như sau:

class Solution {
   public List<Integer> lexicalOrder(int n) {
       List<Integer> ans = new ArrayList<>(n);
       int curr = 1;

       for (int i = 1; i <= n; i++) {
           ans.add(curr);
           if (curr * 10 <= n) {
               curr *= 10;
           } else if (curr % 10 != 9 && curr + 1 <= n) {
               curr++;
           } else {
               while ((curr / 10) % 10 == 9) {
                   curr /= 10;
               }
               curr = curr / 10 + 1;
           }
       }
       return ans;
   }
}

Giải thuật trên có độ phức tạp thời gian là O(n), độ phức tạp không gian là O(1).

📅Góc sự kiện

Ngày 15/4 vừa qua, tại văn phòng KMS đã diễn ra sự kiện Grokking Techtalk #47 với sự chia sẻ của hai diễn giả là Trung Nguyễn (Principal Software Engineer @ KMS Healthcare) và Thái Tăng (Lead Machine Learning Engineer @ MoMo).

Các bạn có thể xem lại zoom record nội dung thuyết trình ở đây.

💭Góc bạn đọc

Góc bạn đọc kỳ này có một chia sẻ từ một bạn đọc gửi đến nhóm biên tập. Các bạn nào có kinh nghiệm hoặc thủ thuật gì hay cũng cứ chia sẻ đến với nhóm biên tập bạn nhé.

Chào các anh chị, em đã đọc newsletter của Grokking đã lâu và cũng đã tiếp cận nhiều bài viết hay. Tuy nhiên cho tới giờ em thấy Grokking chỉ chia sẻ nội dung về kỹ thuật chủ yếu mà ít thấy chia sẻ các bài viết hoặc nội dung liên quan đến Softskill. Em nghĩ Grokking cũng nên tổng hợp thêm các nội dung này vì Softskill emthấy cũng quan trọng không kém kỹ năng chuyên môn.

Gần đây em có được biết đó là kênh youtube của thầy Dũng, hiệu phó trường đại học Bách Khoa khá hay nói về tư duy phản biện và các vấn đề xã hội. Grokking có thể tham khảo: kênh youtube.

Quotes

Đóng góp nội cho Grokking Newsletter

Bạn có thể gửi nội dung đóng góp đến nhóm biên tập newsletter thông qua email newsletter@grokking.org. Các nội dung các bạn có thể đóng góp:

• Nếu bạn có một bài viết muốn chia sẻ, bạn có thể gửi link bài viết kèm một đoạn giới thiệu ngắn bằng tiếng Việt.

• Nếu bạn có vài suy nghĩ muốn chia sẻ đến cộng đồng, bạn có thể gửi nội dung trực tiếp đến chuyên mục Góc dành cho bạn đọc.

• Nếu bạn có câu hỏi và muốn các bạn đọc của Grokking cùng tham gia góp ý, bạn cũng có thể gửi đến Grokking nhé. Câu hỏi của bạn có thể được đăng dưới dạng ẩn danh.

• Nếu công ty bạn có tổ chức sự kiện techtalk và muốn giới thiệu rộng rãi hơn đến cộng đồng, các bạn gửi link sự kiện cùng hình ảnh banner và nội dung chia sẻ. Nhóm sẽ giúp chia sẻ lên newsletter và fanpage nếu nội dung phù hợp.

(by lpv)

Tình hình layoff mới nhất tại Meta và một số công ty khác

Meta đã thông báo cho nhân viên trong một bảng tin nội bộ rằng việc cắt giảm sẽ bắt đầu vào sáng thứ Tư, có thể ảnh hưởng đến khoảng 4.000 nhân viên, qua đó tổng số nhân sự bị cắt giảm của Meta kể từ tháng 11 có thể tăng lên tới 21.000.

The state of startup funding

Tác giả đã thu thập dữ liệu từ nhiều nguồn khác nhau để biết được xu hướng tài trợ cho các công ty khởi nghiệp đang diễn ra như thế nào. Cho đến nay, nó đi xuống. Điều này có ý nghĩa gì đối với công nghệ?

Angel and seed rounds have hit a 2.5-year low in the US. Source: PitchBook-NVCA Venture Monitor Q1 2023

GitHub Accelerator: our first cohort and what’s next

Gặp gỡ các dự án tạo nên nhóm GitHub Accelerator đầu tiên và tìm hiểu về cách GitHub đang giúp biến tầm nhìn của họ thành hiện thực.

📰Những bài viết hay

Load Balancing

(by nhij)

Thuật ngữ load balancing không còn xa lạ với các kỹ sư phần mềm, khi bạn triển khai ứng dụng trên nhiều hơn một server và cần phân phối các request tới các server đó. Trong bài viết này, tác giả giới thiệu về các thuật toán để phân phối request từ mức cơ bản đến nâng cao một cách dễ hiểu cùng các hình biểu diễn trực quan, mời bạn đọc tham khảo thêm tại bài viết gốc tại đây.

Real-time Messaging at Slack

(by nhij)

Mỗi ngày, Slack phải xử lý hàng triệu tin nhắn gửi qua  hàng triệu channel ở thời gian thực (channel trong Slack giống như group chat ở các ứng dụng khác). Để xử lý lưu lượng lớn như vậy một cách hiệu quả, họ đã xây dựng nhiều service khác nhau trong hệ thống messaging. Trong bài viết này, tác giả giới thiệu một số service chính:

• Channel Servers (CS) lưu trữ tin nhắn của các channel. Mỗi channel có một ID được hash và map tới một CS duy nhất. Slack sử dụng consistent hashing để gán channel vào các CS, nhờ đó mà việc thêm/bớt server trong hệ thống có thể thực hiện dễ dàng và tối ưu việc phải resharding.

• Gateway Servers (GS) đặt giữa Slack client (web/desktop/mobile client) và Channel Servers. Các server này là stateful server, lưu giữ thông tin người dùng đang theo dõi các channel nào. Người dùng sẽ kết nối với GS để đăng ký nhận tin nhắn từ các channel, vì lý do này mà các servers được deploy trên nhiều vùng khác nhau, từ đó người dùng có thể kết nối với gateway gần nhất với họ.

• Presence Servers (PS) lưu trữ trạng thái online của người dùng. Slack client có thể gửi query tới PS thông qua GS. Bằng cách này, client có thể lấy được thông tin trạng thái của người dùng và cập nhật trên giao diện.

Trong bài viết, tác giả giới thiệu cách các service kể trên hoạt động cùng nhau trong một số trường hợp như khi một slack client kết nối vào server, hay khi một người dùng gửi một tin nhắn trong một channel. Để hiểu rõ và chi tiết hơn, mời bạn đọc tham khảo bài viết gốc tại đây.

Junior to Senior: An action plan for engineering career success

(by nhij)

Để trở thành Senior Software Engineer sẽ có rất nhiều kỹ năng mà bạn cần trau dồi, bao gồm kỹ năng cứng và kỹ năng mềm. Trong bài viết này, tác giả chia sẻ một số lời khuyên cho các bạn Software Engineer trẻ về cách học tập và trau dồi năng lực trên hành trình phát triển chuyên môn, gồm một số ý chính như:

• Các năng lực kỹ thuật quan trọng mà cấp trên thường ghi nhận khi xét duyệt thăng chức.

• Các kỹ năng giao tiếp cần có của một senior developer.

• Tư duy phát triển phần mềm nhằm giải quyết được các yêu cầu của business đặt ra.

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Lexicographical Numbers

Cho một số nguyên n, trả về tất cả các số trong phạm vi [1, n] được sắp xếp theo thứ tự từ điển.

Bạn hãy cố gắng giải quyết bài toán với độ phức tạp O(n) về thời gian và sử dụng O(1) bộ nhớ dùng thêm.

Lời giải tuần trước: Course Schedule

Đề bài cho một danh sách các khóa học và danh sách các mối quan hệ giữa chúng. Nếu xem mỗi khóa học là một đỉnh của đồ thị và mối quan hệ giữa các khóa học là các cạnh của đồ thị, ta có thể đưa bài toán trở thành bài toán xác định xem đồ thị có chu trình hay không.

Một cách để giải quyết bài toán này là sử dụng thuật toán DFS (duyệt đồ thị theo chiều sâu). Trong quá trình duyệt, nếu chúng ta tìm thấy một đỉnh đã được duyệt trước đó và chưa được kết thúc, thì có nghĩa là chúng ta đã tìm thấy một chu trình.

Dưới đây là cài đặt tham khảo bằng ngôn ngữ Java cho giải thuật.

    public boolean canFinish(int numCourses, int[][] prerequisites) {
        List<Integer>[] g = new List[numCourses];
        for (int i = 0; i < numCourses; i++) {
            g[i] = new ArrayList<>();
        }
        for (int[] v : prerequisites) {
            g[v[0]].add(v[1]);
        }
        // Mảng visited dùng để đánh dấu dường đi ở mỗi vòng lặp
        boolean[] visited = new boolean[numCourses];

        // Mảng checked dùng để đánh dấu một đỉnh đã được duyệt qua ở các vòng lặp trước
        boolean[] checked = new boolean[numCourses];
        for (int i = 0; i < numCourses; i++) {
            if (dfs(g, visited, checked, i)) {
                return false;
            }
        }
        return true;
    }

    // Hàm DFS trả về true nếu đồ thị có chu trình
    private boolean dfs(List<Integer>[] g, boolean[] visited, boolean[] checked, int v) {
        if (checked[v]) {
            return false;
        }
        if (visited[v]) {
            return true;
        }
        if (g[v].size() == 0) {
            return false;
        }
        visited[v] = true;
        for (int v1 : g[v]) {
            if (dfs(g, visited, checked, v1)) {
                return true;
            }
        }
        visited[v] = false;
        checked[v] = true;
        return false;
    }

📆History

(by lpv)

Có bao giờ bạn tự hỏi, thứ đầu tiên được giao dịch trực tuyến là gì không?

Vào năm 1972, rất lâu trước eBay hay Amazon, các sinh viên từ Đại học Stanford ở California và MIT ở Massachusetts đã thực hiện giao dịch trực tuyến đầu tiên. Sử dụng tài khoản Arpanet tại phòng thí nghiệm trí tuệ nhân tạo của họ, các sinh viên Stanford đã bán cho đối tác của họ một lượng *** ** nhỏ. Các bạn có thể đọc bài viết để biết thứ đã được bán là gì nhé ;)

🛠️Code & Tools

• Tổng hợp một số playground trên web cho một số ngôn ngữ và công cụ, link.

Quotes

Unified Streaming And Batch Pipelines At LinkedIn

(by steven.do)

Trước đây, các kỹ sư tại LinkedIn đã áp dụng kiến trúc Lambda khi tiến hành xây dựng các luồng dữ liệu (data pipeline) xử lý theo dạng streaming và dạng khối (batch), và điều này dẫn đến vấn đề sẽ cần phải duy trì hai codebase khác nhau, với hai cách cài đặt code xử lý data khác nhau để read/write theo batch và streaming data, cũng như phải duy trì và nắm vững được cả 2 engines khác nhau trong quá trình duy trì hoạt động.

Để giải quyết được vấn đề này, các kỹ sư tại LinkedIn đã chuyển hướng sang áp dụng Apache Beam, với kỳ vọng có thể viết logic xử lý trên cùng 1 mã nguồn đáp ứng cho cả xử lý dạng batch và stream. Theo hướng tiếp cận này, họ sẽ tiết kiệm được hơn 94% thời gian xử lý.
Apache Beam là mô hình hợp nhất mã nguồn mở giúp xây dựng các tác vụ xử lý dữ liệu song song đáp ứng cho cả 2 hướng xử lý theo batch và streaming. Bằng cách sử dụng một trong số các open source Beam SDK, người dùng có thể xây dựng một luồng xử lý dữ liệu. Luồng xử lý dữ liệu này sau đó sẽ được thực thi bởi một trong số các back-end xử lý phân tán mà Beam hỗ trợ (Vd: Sazam, Spark, hoặc Apache Flink).
Tại LinkedIn, Sazam được sử dụng trong hàng ngàn ứng dụng xử lý streaming để xử lý hai triệu messages mỗi ngày với yêu cầu chịu tải lớn và khả năng kháng lỗi cao. Đối với các tác vụ xử lý batch, các kỹ sư tại LinkedIn đã sử dụng Spark để xử lý hàng petabyte dữ liệu trong các kho lưu trữ dữ liệu. Để có góc nhìn chi tiết và toàn cảnh hơn về cách thức các kỹ sư tại LinkedIn đã áp dụng Beam, các bạn có thể tham khảo chi tiết tại bài viết.

Scaling our customer review system for peak traffic

(by quangle)

Customer reviews là một trong những hệ thống cốt lõi có lượng truy cập cao tại Booking.com, mang đến những bài đánh giá có điểm số rating, hình ảnh, các feedbacks cần thiết cho khách hàng khi họ tìm kiếm và tiến hành đặt chỗ nghỉ.

Theo ước tính, hệ thống customer-reviews backend phải xử lý hàng chục nghìn requests per second, để đảm bảo tỷ lệ response time dưới 50 ms là 99% (p99 = 50ms) cùng với số lượng records lên đến 250 triệu reviews hiện có, nhóm kỹ sư đánh giá lựa chọn kỹ thuật sharding dữ liệu để chia nhỏ records theo chiến lược chia lấy dư (modulo) của

• ACCOMMODATION_ID % NUMBER_OF_SHARDS

• ACCOMMODATION_ID: Internal ID của khách sạn, nhà, ...

• NUMBER_OF_SHARDS: tổng số lượng shards hiện có trong system

Tuy nhiên, cách tiếp cận modulo sẽ gặp vấn đề khi cần thêm vào node server vật lý (do số lượng records vượt ngưỡng lưu trữ của single node) dẫn đến phải resharding toàn bộ dữ liệu. Lấy ví dụ: hệ thống ban đầu được chia thành 3 shards, khi đó review record có accommodation_id = 10124 sẽ được điều phối về shard = 2 (10124 % 3 = 0), khi thêm mới 1 node lúc này hệ thống sẽ có 4 shards, và review record id 10124 sẽ được điều phối lại vào shard = 0 (10124 % 4 = 0). Quá trình redistributed sẽ ảnh hưởng đến hệ thống hiện tại.

Vậy đội ngũ Booking.com đã giải quyết các bài toán hóc búa trên như thế nào? Mời bạn đọc cùng tham khảo chi tiết bài viết: link

LLMs will fundamentally change software engineering

(by n^4)

Sự phổ biến của ChatGPT cùng các mô hình ngôn ngữ lớn gần đây đã khiến cộng đồng software engineer nảy sinh ra câu hỏi: liệu những công nghệ này có thay thế công việc của Software Engineer (SE) hay không? Hay nó sẽ thay đổi ngành công nghệ phần mềm như thế nào?

Trong bài viết này, tác giả vốn là một lập trình viên hệ thống (System Programming) chia sẻ góc nhìn của mình về vấn đề này. Tác giả liệt kê những tình huống mà tác giả nghĩ LLM (Large Language Model) sẽ giúp software engineer trở nên hiệu quả hơn và cách mà tác giả nghĩ các lập trình viên nên tìm cách thích ứng.

What’s the differences between software engineering and computer science degrees

(by n^4)

Nhiều bạn hẳn đã từng đặt ra câu hỏi: tôi muốn làm Software Engineer, vậy tôi có phải đi học đại học hay không? Hoặc là nếu tôi không học Computer Science, vậy tôi có được tự gọi mình là Software Engineer hay không?

Đây là một chủ đề lớn và có nhiều tranh luận. Trong bài viết hay kỳ này mời bạn cùng tham khảo một góc nhìn được đăng ở StackOverflow: link.

👨‍💻Góc lập trình

(by ndaadn and phucnh)

Đề ra tuần này: Course Schedule

Có tổng cộng `numCourses` khóa học mà bạn có thể tham gia, được đánh số từ 0 đến numCourses - 1. Bạn được cung cấp một mảng `prerequisites` trong đó `prerequisites[i] = [ai, bi]` cho biết bạn phải tham gia khóa học `bi` trước nếu muốn tham gia `ai`.

Ví dụ: cặp [0, 1], cho biết rằng để học khóa học 0, trước tiên bạn phải học khóa học 1.

Đề bài yêu cầu trả về true nếu bạn có thể hoàn thành tất cả các khóa học. Nếu không, trả về false.

Ví dụ 1:

• Input: numCourses = 2, prerequisites = [[1,0]]

• Output: true

Ví dụ 2:

• Input: numCourses = 2, prerequisites = [[1,0],[0,1]]

• Output: false

Giải thích: Có 2 khóa học, để học khóa 1 cần hoàn thành khóa 0 trước, và để học khóa 0 cần hoàn thành khóa 1 trước. Chính vì vậy kết quả là false.

Lời giải tuần trước: Backspace String Compare

Sử dụng hai stack để lưu trữ xâu ký tự ban đầu.

Thực hiện duyệt qua từng ký tự trong xâu, nếu ký tự đó không phải là "#" thì đẩy vào stack, ngược lại thì lấy ra ký tự trên đỉnh của stack (nếu stack không rỗng).

Sau khi đã xử lý xong cả hai xâu, ta so sánh các phần tử trong hai stack để kiểm tra xem hai xâu có giống nhau hay không.

class Solution {
    public boolean backspaceCompare(String s, String t) {
        Stack<Character> stackS = new Stack<>();
        Stack<Character> stackT = new Stack<>();
        // Xử lý xâu s
        for (char c : s.toCharArray()) {
            if (c != '#') {
                stackS.push(c);
            } else if (!stackS.isEmpty()) {
                stackS.pop();
            }
        }
        // Xử lý xâu t
        for (char c : t.toCharArray()) {
            if (c != '#') {
                stackT.push(c);
            } else if (!stackT.isEmpty()) {
                stackT.pop();
            }
        }
        // So sánh hai stack
        while (!stackS.isEmpty() && !stackT.isEmpty()) {
            if (stackS.pop() != stackT.pop()) {
                return false;
            }
        }
        return stackS.isEmpty() && stackT.isEmpty();
    }
}

Độ phức tạp thuật toán của giải thuật là O(N+M) với N, M lần lượt là độ dài của chuỗi s và t.

🛠️Code & Tools

• filegpt.app: Trợ lý ảo trên nền tảng GPT giúp tóm tắt nội dung các file và text xoay quanh một chủ đề nào đó.

Quotes