#223 - Tổng hợp 1000 bài viết từ Grokking Newsletter
Chào các bạn độc giả của Grokking Newsletter.
Bắt đầu từ những số newsletter đầu tiên vào tháng 11/2017, tới nay Grokking Newsletter đã trải qua 1 chặng đường dài gần 5 năm. Trong mỗi số newsletter chúng tôi đều cố gắng giới thiệu từ 4-5 bài viết hay. Sau 222 số chúng ta đã có khoảng 1000 bài viết tất cả.
Một trong những khó khăn đối với các độc giả của Grokking Newsletter đó chính là tìm kiếm các bài viết cũ theo những chủ đề mà các bạn đang quan tâm. Vì thế chúng tôi đã khởi động 1 dự án nhằm migrate toàn bộ bài viết của newsletter lên 1 nền tảng mới, Knowledge Graph.
Sau nửa năm với sự tham gia của rất nhiều thành viên Grokking, nay chúng tôi xin chính thức giới thiệu với các bạn Grokking Knowledge Graph: https://knowledge.grokking.org/
Tại website này, chúng tôi đã tổng hợp toàn bộ 1000 bài viết của newsletter từ trước tới nay, ngoài ra các bài viết đều được phân loại, gán nhãn theo từng chủ đề quan trọng. Qua đó chúng tôi hy vọng các bạn có thể dễ dàng tìm kiếm được những bài viết mà mình quan tâm.
Trong tương lai, chúng tôi cũng sẽ tiếp tục bổ sung thêm nhiều nội dung thú vị khác. Rất mong tiếp tục nhận được sự ủng hộ của các bạn.
Mọi ý kiến đóng góp xin gửi về newsletter@grokking.org
Trong số này, chúng ta cùng tìm hiểu về:
Phát hiện ảnh tương đồng với Apache Flink tại Pinterest
Phát hiện hàng triệu hình ảnh tương tự nhau mỗi ngày bằng Apache Flink trong thời gian thực
Sử dụng Mono Repo hay Multi Repo đối với Terraform
Bài học từ việc trở thành CTO của một start-up nhỏ
Ngoài ra các bạn vẫn có thể tiếp tục đặt mua ấn phẩm Dijkstra tập 2 tại đây nhé.
Những bài viết hay
Detecting Image Similarity in (Near) Real-time Using Apache Flink
(by hungngph)
Với những công ty như Pintenrest thì visual platform là một trong những module nền tảng, việc đảm bảo chất lượng hình ảnh trong platform này là điều tối quan trọng. Số lượng ảnh trong platform là rất lớn vì vậy việc review bằng sức người là dường như không thể, để giải quyết điều này tại Pintenrest các kỹ sư đã thiết kế và triển khai luồng batch pipeline cho việc phát hiện các hình ảnh tương tự bằng máy học. Kết quả của việc này là nhằm phát triển các bài toán recommendation cho ra các hình ảnh tương tự từ ảnh gốc, hay là gỡ bỏ nội dung của spammers and abusers trên Pintenrest.
Tuy nhiên, đối với luồng batch pipeline, phải mất vài giờ thì kết quả của các hình ảnh mới được tính toán xong, việc này tốn quá nhiều thời gian và gây ra những vấn đề về chất lượng hình ảnh trong hệ thống. Vì vậy, các kỹ sư tại đây đã quyết định triển khai luồng streaming pipeline để giải quyết triệt để những vấn đề này. Với quy mô của hệ thống, việc xác định các hình ảnh trùng lặp đã khó và thực hiện nó trong thời gian thực còn khó hơn. Hơn nữa, mục tiêu của dự án là giảm độ trễ xuống còn vài giây mà mà vẫn đảm bảo được độ chính xác so với luồng batch pipeline.
Cụ thể, dự án đề xuất giải quyết hai vấn đề chính:
Với một hình ảnh, hãy tìm xem hình ảnh đó đã được sử dụng trên Pinterest trước đây hay chưa.
Đưa ra một hình ảnh, hãy tìm danh sách tất cả các hình ảnh tương tự được sử dụng trên Pinterest.
Trong bài viết này thì tác giả tập trung vào việc mô tả hệ thống được xây dựng xoay quanh Apache Flink. Kết quả được tính toán, xử lý và được phản hồi thông qua Kafka để có thể phát triển các bài toán liên quan. Ngoài ra, dự án này có thể được tổng quát hóa để xử lý bất kỳ loại dữ liệu nào tồn tại mối quan hệ trùng lặp, đây là một bài toán được đánh giá là rất thú vị và có thể có nhiều ứng dụng thực tế. Mời bạn đọc truy cập vào bài viết để biết thêm chi tiết.
Scaling the Walmart Inventory Reservations API for Peak Traffic
(by quangle)
Khả năng scale, tính ổn định và tốc độ phản hồi luôn là những tiêu chí được các đội ngũ kỹ sư quan tâm khi làm việc ở các hệ thống lớn. Đặc thù như các sàn thương mại điện tử, khi diễn ra chương trình khuyến mãi như Black Friday, Thanksgiving, v.v.. số lượng truy cập mua, đặt hàng tăng lên rất cao, vậy các kỹ sư sẽ tối ưu hệ thống của họ như thế nào để đảm bảo những tiêu chí trên?
Để giải quyết bài toán đó, các kỹ sư tại Walmart (một trong những công ty lớn nhất về ngành bán lẻ) đã áp dụng các kỹ thuật như scatter-gather API, in-memory concurrency, snapshots caching. Trước đó, để xử lý yêu cầu đặt đơn, họ tổ chức cụm Global Reservation API (GRA) với kiến trúc scale ngang nhiều instances, mỗi instance đảm bảo việc xử lý request, ghi nhận dưới dạng event collection. Cách tiếp cận này vẫn ổn cho đến khi vào lượng traffic tăng cao gây ra vấn đề nhiều instance tranh nhau ghi event vào chung partition key. Vì vậy, họ đã áp dụng scatter-gather tách cụm GRA thành Main Reserve API (MRA) và Line Reserve API (LRA), khi request đến, MRA sẽ chia nhỏ thành từng nhóm theo selling-id và đẩy vào LRA. Sự cải tiến giúp họ đảm bảo mỗi instance chỉ nhận request từ partition tương ứng mà không bị conflict như trên. Sau khi các request được routing tới, MailBoxProcessor (được xây dựng với ý tưởng in-memory concurrency) đảm bảo việc xử lý của một partition diễn ra trên cùng một thread. Trước khi các request đặt đơn được thực thi, hệ thống phải đảm bảo trạng thái cũng như các bản snapshot luôn được cập nhật mới, vì vậy để tối ưu chi phí đọc từ database, đội ngũ áp dụng kỹ thuật snapshots caching, xây dựng tiến trình chạy background giữ cho các bản snapshot luôn ở trạng thái mới nhất giống với database.
Terraform Mono Repo vs. Multi Repo: The Great Debate
(by MS)
Một trong những câu hỏi phổ biến nhất khi sử dựng Terraform đó là "Nên sử dụng một Git repo nguyên khối (Monolithic Source Repositories) hay nhiều Git repos khác nhau (Multiple Source Repositories)?" Không có một câu trả lời cụ thể cho vấn đề này nói nó phụ thuộc vào nhu cầu và cách tổ chức của mỗi organisation. Bài viết thảo luận về các sắc thái của từng cách tiếp cận và khi nào thì bạn nên chia một Terraform repo đơn thành nhiều repo.
Lợi ích của Mono Repo:
Mono repo trở thành Single source of Truth cho cấu hình của toàn bộ cơ sở hạ tầng
Nó hợp nhất cấu hình cơ sở hạ tầng để test và debug, điều này có thể quan trọng đối với database testing, queues, event streaming, hay data pipelines.
Bất lợi của việc sử dụng Mono Repo:
Tăng chi phí và thời gian khi bảo trì và cập nhật các modules
Hệ thống của bạn sẽ khó scale khi có nhiều subdirectories và các môi trường khác nhau
Kiểm soát truy cập được áp dụng cho toàn bộ repo theo mặc định.
Lợi ích của Multiple Repos:
Cho phép các team tự kiểm soát và phát triển dựa trên các modules được chia sẻ.
Các repos riêng biệt cho phép việc test các tính năng và bảo mật của modules một cách độc lập
Có thể sử dụng module versioning qua các release tags khác nhau
Dễ dàng và linh hoạt trong việc kiểm soát quyền truy cập các modules ở các repos khác nhau
Giới hạn và giảm thiểu phạm vi thay đổi
Bất lợi của việc sử dụng Multiple Repos:
Nếu cấu hình của bạn có quá nhiều remote modules, điều này có thể tốn thời gian để download. Chúng ta có thể cân nhắc sử dụng Git submodules để giải quyết vấn đề này
Không có câu trả lời đúng hay sai về việc sử dụng mono repo và multi repo. Bằng cách lùi lại một bước và quan sát các mô hình tổ chức khác nhau, chúng ta có thể xác định cấu trúc môi trường nào phù hợp nhất đối với mình.
Lessons learned from becoming CTO of a small startup
(by nghialuu)
Trong cuộc đời của mỗi kỹ sư phần mềm, sẽ có lúc cần quyết định về mong muốn theo đuổi sự nghiệp kỹ sư (engineering) hay là chuyển sang quản lý (management) . Cả hai lựa chọn đó đều có ưu và nhược điểm, và tất cả phụ thuộc vào tính cách của bạn như thế nào, bạn muốn gì trong cuộc sống và bạn có thể quản lý cân bằng công việc - cuộc sống (work-life balance) tốt như thế nào.
Bài viết được viết sau khi tác trở thành CTO cho một startup nhỏ (<40 người) được 1 năm, với khối lượng công việc lớn hơn bao giờ hết. Sau đây là một số trong những bài học trọng yếu mà tác giả ước rằng đã có thể biết sớm hơn:
1. Nếu bạn thăng chức từ 1 thành viên trong team trở thành quản lí của họ, trước tiên bạn cần đảm bảo rằng họ tôn trọng bạn với tư cách là một kĩ sư
2. Tình bạn với đồng nghiệp của bạn sẽ bị ảnh hưởng khi bạn trở thành sếp của họ
3. Những thói quen cần vứt bỏ:
Mong muốn tự mình làm mọi thứ.
Mong muốn là người biết tất cả
Mong muốn tự cô lập và làm việc một mình
Chỉ quan tâm đến phần việc của bạn.
4. Những thói quen cần cải thiện:
Giao tiếp
Quản lí áp lực
Ra quyết định
Khả năng học hỏi và thích ứng cái mới
Chấp nhận rằng mình sẽ sai
Trong bài viết, tác giả có đưa nhiều lập luận và giải thích cụ thể hơn. Bài viết còn là mở đầu cho series chia sẻ kinh nghiệm về technical manager. Mời các bạn cùng đọc và tìm hiểu nhé.
Góc Lập Trình
Đề ra tuần này: Next Permutation
Bài toán cho trước một mảng các số tự nhiên. Yêu cầu sinh ra một mảng số tự nhiên khác là hoán vị tiếp theo theo tứ tự từ điển của mảng ban đầu.
Ví dụ 1:
Input: [1,2,3]
Output: [1,3,2]
Ví dụ 2:
Input: [1,1,5]
Output: [1,5,1]
Lời giải đề bài tuần trước: Add Two Numbers II
(by ndaadn)
Đề bài cho 2 số nguyên được biểu diễn bằng Linked List, tính tổng của 2 số và trả lại kết quả cũng là Linked List.
Đề bài khá rõ ràng và không có các các trường hợp mẹo, vậy nên ý tưởng cho bài toán là thực hiện phép tính cộng từ phải qua trái tương tự như cách ta cộng 2 số thông thường. Ta thực hiện giải thuật như sau:
Đảo ngược 2 Linked List.
Thực hiện cộng từng số hạng một trong mỗi Linked List và lưu kết quả vào một Linked List mới.
Đảo ngược và trả về Linked List kết quả.
Độ phức tạp thuật toán là O(N) với N là độ dài lớn nhất của 2 Linked List đề cho.
Trong trường hợp đề bài không cho đảo ngược LinkedList, ta có thể sử dụng đệ quy để giải bài này như sau:
Code & Tools
fzf - a general-purpose command-line fuzzy finder.
ledger - a powerful, double-entry accounting system that is accessed from the UNIX command-line
Quotes
“The best programs are written so that computing machines can perform them quickly and so that human beings can understand them clearly. A programmer is ideally an essayist who works with traditional aesthetic and literary forms as well as mathematical concepts, to communicate the way that an algorithm works and to convince a reader that the results will be correct.”
― Donald E. Knuth, Selected Papers on Computer Science
Bạn đánh giá nội dung số newsletter này thế nào?
(1 = Rất tệ / 5 = Rất tốt)
(Việc đánh giá của các bạn là rất quan trọng, sẽ giúp chúng tôi liên tục cải thiện nội dung newsletter tốt hơn)