#234 - Kỹ thuật bypass Cloudflare
Trong số này, chúng ta cùng tìm hiểu về:
Design Patterns of Event-driven Architecture
The Difficult Life of the Data Lead
Cách bypass Cloudflare
Lời giải bài Find Two Non-overlapping Sub-arrays Each With Target Sum.
Tech Talk: “𝑨𝒑𝒑𝒍𝒊𝒄𝒂𝒕𝒊𝒐𝒏 𝒐𝒇 𝒑𝒓𝒐𝒃𝒂𝒃𝒊𝒍𝒊𝒔𝒕𝒊𝒄 𝒅𝒂𝒕𝒂 𝒔𝒕𝒓𝒖𝒄𝒕𝒖𝒓𝒆𝒔 𝒂𝒏𝒅 𝒂𝒍𝒈𝒐𝒓𝒊𝒕𝒉𝒎𝒔 𝒊𝒏 𝒎𝒐𝒅𝒆𝒓𝒏 𝒅𝒂𝒕𝒂 𝒔𝒚𝒔𝒕𝒆𝒎𝒔”
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.
News
Linux luminaries discuss efforts to bring Rust to the kernel
Gần nhất, Linus đã có những phát biểu thảo luận về việc chấp nhận các module Rust trong Linux kernel. Phiên bản kế tiếp của Linux là 6.0, và có thể từ 6.1, chúng ta sẽ có thể lập trình linux driver bằng Rust.
15-Year-Old Python Flaw Slithers into Software Worldwide
Một lỗ hổng chưa được vá xuất hiện trong hơn 350k repository!
YouTube’s ‘dislike’ and ‘not interested’ buttons barely work, study finds
Một nghiên cứu của Mozilla cho thấy các nút phản hồi “not interested,” “dislike,” “stop recommending channel,” và “remove from watch history” hầu như không hiệu quả trong việc ngăn chặn các video YouTube tương tự được đề xuất.
Tech Talk
𝑨𝒑𝒑𝒍𝒊𝒄𝒂𝒕𝒊𝒐𝒏 𝒐𝒇 𝒑𝒓𝒐𝒃𝒂𝒃𝒊𝒍𝒊𝒔𝒕𝒊𝒄 𝒅𝒂𝒕𝒂 𝒔𝒕𝒓𝒖𝒄𝒕𝒖𝒓𝒆𝒔 𝒂𝒏𝒅 𝒂𝒍𝒈𝒐𝒓𝒊𝒕𝒉𝒎𝒔 𝒊𝒏 𝒎𝒐𝒅𝒆𝒓𝒏 𝒅𝒂𝒕𝒂 𝒔𝒚𝒔𝒕𝒆𝒎𝒔
Speaker: Tony Vo - Senior Engineering Manager - Segmentation Platform at Grab
Nội dung: Tìm hiểu thêm về cách các cấu trúc dữ liệu và thuật toán này được thiết kế và phát triển theo thời gian. Có ý tưởng tại sao các thuật toán và cấu trúc dữ liệu cơ bản vẫn quan trọng đối với các kỹ sư phần mềm để giải quyết các vấn đề dữ liệu lớn.
Các bạn có thể xem thông tin về thời gian, địa điểm tổ chức cũng như cách đăng ký tại đây
Những bài viết hay
Design Patterns of Event-driven Architecture
(by steven.do)
Event-Driven Architecture (Kiến trúc hướng sự kiện) là một trong những kĩ thuật thiết kế hiệu quả để xây dựng các kiến trúc ứng dụng có hiệu suất cao, có thể mở rộng, kết hợp linh động (low coupling). Tuy nhiên, việc xây dựng được một hệ thống theo kiến trúc hướng sự kiện tốt là một việc khá thử thách.
Thông qua bài viết tác giả giới thiệu về các mẫu kiến trúc (architecture patterns) theo kiến trúc hướng sự kiện như:
Channel monitoring pattern: pattern này quy định một role được gọi là channel monitoring dùng để theo dõi việc sử dụng main queue. Channel monitoring sẽ giám sát một vài chỉ số như số lượng message đang chờ được xử lý, số lượng consumer và consumer rate. Thông qua các chỉ số này, giúp hiểu được workload và tình trạng hệ thống. Hơn nữa, các thông tin này có thể hỗ trợ hệ thống có thể tự phục hồi (self-healing) bằng cách tự điều chỉnh lại số lượng consumer và điều tiết producer cho phù hợp.
Consumer supervisor pattern: pattern này sẽ điều chỉnh số lượng consumer bằng việc listen trên channel để giám sát và xác định xem hiện tại các consumer đang hoạt động và xử lý các event hay không. Nếu như throughput của consumer bị quá tải, thì sẽ bổ sung thêm consumer và ngược lại.
Producer control flow pattern: ngược lại với pattern vừa nêu trên, khi vấn đề chi phí là vấn đề cần được quan tâm thì việc sử dụng nhiều consumer rõ ràng sẽ là không phù hợp. Do vậy cách tiếp cận của pattern này đó là kiểm soát producer, khi tỷ lệ consumer rate không đáp ứng kịp với producing rate, bộ kiểm soát sẽ gửi một signal đến producer để giảm quá trình generate event. Sau khi các pending event đã xử lý xong, producer có thể khôi phục lại trạng thái bình thường.
Thread delegate pattern: Đây là một pattern hữu ích không chỉ áp dụng trong thiết kế hướng sự kiện mà còn sử dụng trong các kiểu thiết kế hệ thống khác. Pattern này có 02 mục đích đó là giữ nguyên thứ tự messages, và theo dõi số liệu của quá trình xử lý event.
Workflow event pattern: Khi event consumer gặp lỗi trong quá trình xử lý, và không thể khắc phục được, lúc này consumer sẽ gửi event này sang queue khác để workflow processor xử lý. Processor sẽ sửa event hoặc lưu event lại trong storage. Ngoài ra processor có thể hiển thị event lên dashboard để thông báo cho người vận hành sẽ tiếp tục xử lý và gửi lại event này vào queue.
Request-response Model: đây là một pattern rất cổ điển, được áp dụng trong các RESTful API. Giả sử phía server là một server HTTP truyền thống với một số API Restful được đồng bộ hóa và client sẽ gửi request đến server như bình thường. Tuy nhiên, server sẽ không trực tiếp xử lý request này mà thay vào đó sẽ ủy thác công việc này cho event worker xử lý và chờ nhận response tại một nơi đã thỏa thuận là một queue khác. Với việc sử dụng pattern này, chúng ta có không chỉ có thể đạt được những lợi ích của kiến trúc hướng sự kiện mà việc trao đổi giữa các client và server sẽ đơn giản hơn.
Ambulance Pattern: pattern được sử dụng trong trường hợp các message có mức độ ưu tiên cần xử lý. Hướng tiếp cận của pattern này là luôn đặt các message có độ ưu tiên cao lên đầu của queue, và các worker sẽ xử lý các message đó ngay lập tức. Hướng tiếp cận này có một số hạn chế, đó là các event có mức độ ưu tiên thấp sẽ hoàn toàn không được xử lý nếu có các event khẩn cấp xảy ra liên tục.
Xu hướng áp dụng kiến trúc hướng sự kiện đã dần trở nên phổ biến. Tuy nhiên, vẫn chưa có một giải pháp chung nào có thể đáp ứng cho mọi nhu cầu. Do vậy, chúng ta cần phải tìm một giải pháp tương ứng tùy vào những tình huống khác nhau. Hy vọng bài viết này sẽ cung cấp những thông tin hữu ích cho các bạn.
The Difficult Life of the Data Lead
(by MS)
Làm việc trong ngành Data chưa bao giờ dễ dàng cả. Data stack ngày càng trở nên phức tạp, trong khi kỳ vọng thường tăng lên đáng kể khi business phát triển và dữ liệu thu thập được nhiều hơn. Những điều này gây vô vàn khó khăn đối với một kĩ sư nắm vai trò Data Lead.
Nếu bạn là một IC - Individual Contributor (người đóng góp cá nhân), công việc của bạn có thể có nhiều thách thức nhưng bạn hoàn toàn có thể tập trung vào nó. Chất lượng công việc của bạn được thể hiện qua việc xây dựng các phân tích dữ liệu chất lượng cao, đồng thời làm việc với các bên liên quan (stakeholders) để đảm bảo công việc của bạn có tác động tích cực đến business của họ.
Nếu bạn là Head of Data, tức là bạn làm việc ở cấp quản lý chiến lược. Vai trò của bạn là khó nhưng trọng tâm của bạn cũng rõ ràng, đó là xây dựng một đội ngũ tuyệt vời xung quanh bạn và đảm bảo rằng đội ngũ đó đang làm việc theo các ưu tiên phù hợp và đi đúng hướng trong chiến lược được đề ra.
Đối với một Data Lead, dường như bạn phải liên đới tới tất cả những điều kể trên. Với tư cách là Data Lead, bạn phải quản lý nhóm trực tiếp của mình. Điều này bao gồm giải quyết các vấn đề về quản lý hiệu suất, đảm bảo tạo ra môi trường thử thách đối với các top performers trong team và tuyển dụng đúng người, ... Bạn cũng phải quản lý các stakeholders từ các business khác nhau. Những business này phụ thuộc vào việc phân tích dữ liệu được xây dựng bởi team của bạn. Và tất nhiên bạn cũng luôn cần phải code, xây dựng cơ sở hạ tầng, pipelines, dashboard hoặc cung cấp phân tích đặt tiêu chuẩn cao.
Tác giả chỉ ra rằng, một trong những vấn đề đối với các Data teams đó chính là quản lý các stakeholders. Trong các công ty có tốc độ phát triển cao, data teams thường có nhiều stakeholders với background khác nhau. Các stakeholders có thể mong đợi Data team hoạt động giống như một service với mục tiêu là phản hồi tất cả các ad-hoc data requests của họ. Điều này gây không ít khó khăn với trở ngại cho các Data Lead.
Khi các Data teams ngày càng lớn hơn, nhu cầu về các vị trí quản lý cấp trung sẽ tăng lên và việc tìm ra mô hình hoạt động tốt nhất là điều vô cùng quan trọng. Các bạn hãy đọc bài viết để tìm hiểu rõ hơn về các khó khăn trong việc quản lý một Data team và những chia sẻ của tác giả để giải quyết những vấn đề đó một cách hiệu quả.
How to Bypass Cloudflare: A Comprehensive Guide
Các nghiên cứu ước tính rằng hơn 40% lưu lượng truy cập internet bắt nguồn từ bot, từ đó đã có sự gia tăng nhu cầu phát triển các phần mềm có khả năng phân biệt giữa hoạt động của con người với hoạt động của bot. Một ví dụ điển hình về điều này là Giải pháp quản lý Bot của Cloudflare.
Trong bài viết này tác giả đã đề cập đến các nội dung sau:
Cloudflare Bot Management là gì.
Cách Cloudflare phát hiện Bots.
Reverse engineer và bypass Cloudflare.
Góc Lập Trình
Đề ra tuần này: Last Stone Weight II
(by ndaadn)
Cho một mảng các số nguyên dương stones, với stones[i] là trọng lượng của viên đá thứ i.
Ta chọn hai hòn đá bất kỳ, có trọng lượng lần lượt là x, y và đập hai hòn đá vào nhau. Giả sử x <= y, kết quả của việc đập là:
Nếu x == y, cả hai hòn đá đều nát vụn
Nếu x < y, ta thu được một hòn đá nhỏ hơn có trọng lượng mới là (y - x)
Ta cứ đập như vậy cho tới khi ta chỉ còn nhiều nhất một hòn đá.
Hãy trả lại trọng lượng nhỏ nhất có thể của hòn đá cuối cùng. Nếu không còn hòn đá nào, trả lại 0.
Ví dụ:
Input: arr = [7,3,4,7], target = 7
Output: 2
Giải thích: các mảng con thỏa mãn là ([7], [3,4] và[7]), tuy nhiên ta sẽ chọn mảng con thứ nhất và thứ 3 vì chúng có tổng số phần tử ít nhất.
Lời giải đề bài tuần trước: Find Two Non-overlapping Sub-arrays Each With Target Sum
(by phucnh)
Để tìm mảng con có tổng bằng một số cho trước, ta có hai cách tiếp cận i) sử dụng tổng tiền tố (prefix sum) hoặc ii) cửa số trượt (sliding window) nếu mảng chỉ chứa số dương. Trên thực tế, ta có thể giải bài này bằng cả 2 cách tiếp cận, xin giới thiệu tới bạn đọc phương pháp dựa trên cách tiếp cận tổng tiền tố.
Để tìm mảng con có tổng bằng một số target cho trước bằng tổng tiền tố, ta thực hiện theo các bước như sau:
1. Duyệt mảng và tính tổng tiền tố, lưu vào bảng băm prefixSums chứa cặp <key=prefixSum, value=index>
2. Duyệt mảng lần thứ hai, nếu ta đã gặp tổng tiền tố bằng (prefixSum - target), ta tìm thấy mảng con cần tìm là nums[index - prefixSums.get(prefixSum at index - target)...index]
Bạn đọc có thể tham khảo ví dụ sau:
index. -1 0 1 2 3 4
nums. n/a 2 1 2 2 1
psum. 0 2 3 5 7 8
Các mảng con có tổng bằng 3 được bôi đỏ, và ta có
- psum[1] - 3 = 3 - 3 = 0, bằng psum[-1]
- psum[4] - 3 = 8 - 3 = 5, bằng psum[2]
Trong bài này, do tất các các số đều là số dương (>= 1), nên tổng tiền tố là duy nhất. Áp dụng cách làm trên, ta có thể tìm thấy mảng con kết thúc tại vị trí index. Tương tự, ta cũng đồng thời tìm được mảng con bắt đầu tại vị trí index bằng cách kiểm tra tổng tiền tố (prefixSum + target) trong bảng băm.
Ta có giải thuật như sau:
Độ phức tạp về thời gian và không gian của giải thuật đều là O(n), với n là độ dài của mảng đầu vào.
Code & Tools
Data Studio - BI tool giúp xây dựng các Dashboards và Reports trực quan và miễn phí của Google
Wasmtime: A fast and secure runtime for WebAssembly
Seaborn: a library for making statistical graphics in Python
Feedback
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)
Grokking mang lại cho các bạn những kiến thức mới mẻ và hữu ích thông qua:
Tech Talk: Là một hoạt động thường xuyên của Grokking từ những ngày đầu thành lập. Tại đây các diễn giả chia sẻ kiến thức xoay quanh Computer Science và Software Engineer. Các buổi Tech Talk đều được record và upload lên kênh youtube của Grokking.
Grokking Knowledge Graph: Tập hợp những nguồn kiến thức phong phú với hơn 1000 bài viết chọn lọc, các đầu sách, khóa học, v.v… Các bài viết đều được gán nhãn để giúp bạn đọc dễ dàng tìm kiếm.
Webinar: Là chương trình kết nối các kỹ sư Việt Nam và các kỹ sư đang làm việc tại các công ty công nghệ hàng đầu thế giới.
Dijkstra: Một ấn phẩm được xuất bản bởi các thành viên của Grokking. Với những bài viết đào sâu vào kỹ thuật và kiến thức khoa học máy tính.
Kipalog: Nền tảng chia sẻ kiến thức dành cho các lập trình viên.
Newsletter: Những bài viết hay về công nghệ sẽ được gửi tới bạn hàng tuần qua email.
Chúc các bạn sẽ tìm được nhiều điều mới mẻ khi đến với Grokking và xin hẹn gặp lại các bạn vào tuần sau.
Quotes
“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”
― Linus Torvalds