Phần giải thích Open/Close cũng nhầm lẫn giữa trách nhiệm và hành vi. Addition, Subtraction thì đều là hành vi của Calculator. Addition, Subtraction nên thừa kế từ interface Operator chứ không phải Calculator. Thiết kế cho Calculator sẽ giống thế này:

sessionStorage không phải là một phần của Javascript: https://262.ecma-international.org/11.0/

Phần giải thích Single Responsibility có thể gây nhầm lẫn thành mỗi class chỉ nên có một public method, có 2 public method trở lên thì phải tách ra.

Cần phải phần biệt giữa trách nhiệm và hành vi. Nếu nhầm lẫn thì Java đã sai ngay từ đầu khi cho đa thừa kế.

Một class có trách nhiệm duy nhất nhưng nó có thể có nhiều hành vi. Cùng xem một ví dụ của mẫu Facade:

public class AtmFacade 
{
  public WithdrawalFunction WithdrawalFunction { get; set; }

  public DepositFunction DepositFunction { get; set; }

  public BalanceFunction BalanceFunction { get; set; }
}

Có thể thấy AtmFacade có trách nhiệm duy nhất là gom các chức năng của cây ATM lại để dễ sử dụng (giảm sự phức tạp). Nếu coi các chức năng con trong đó là trách nhiệm của nó thì thiết kế này sai mất. Các chức năng con là các hành vi mà cây ATM này cung cấp.

Nhưng các chức năng con này cũng thể hiện trách nhiệm duy nhất như cách giải thích của bài viết:

public class WithdrawalFunction 
{
  public void Withdraw(decimal amount);
}

Single Responsibility là nguyên lý đơn giản nhưng rất linh động và thể hiện nhiều nhất sự khác biệt trong tư duy thiết kế cũng như trình độ của các kĩ sư. Không có công thức cho Single Responsibility. Có lẽ chỉ có một tiêu chí đánh giá xem mã nguồn có đơn nhiệm không: Khi không còn gì để nói về nó nữa.

Dependency Injection là Dependency Injection. Nó che giấu đi cách các concrete class được khởi tạo, chỉ việc gọi tên class, nên làm cho mình cảm tưởng đó là bỏ đi sự phụ thuộc. Dependency Injection hoàn toàn có thể đăng ký 1 concrete class và injection nó trong các class khác. Các thư viện DI thì chỉ nhận là DI chứ không nhận là IoC vì bản chất là khác nhau. DI giống như một thể hiện rõ ràng hơn của Dependency Inversion (hay IoC), giúp lập trình viên cảm nhận và hiểu nguyên lý của Dependency Inversion.

Sự phụ thuộc mà D.Injection và D.Inversion đề cập đến là khác nhau.

• D.Injection giải quyết sự phức tạp của constructor và lifetime của một class, hay một phụ thuộc trong class. Một class có thể phụ thuộc vào nhiều class khác, dẫn đến constructor của nó trở nên phức tạp, độ phức tạp còn tăng lên thêm khi nó là một phụ thuộc trong một class khác. Để giải quyết constructor thì ngày trước dùng công cụ thường gọi là ServiceLocator chứ không phải D.Injection (thường là đăng ký factory cho từng class cho ServiceLocator). Ngày nay D.Injection giải quyết constructor tự động, và vẫn cung cấp khả năng đăng ký factory nếu cần. Ngoài ra, D.Injection quản lý cả lifetime của một dependency, tức nó không quản lý 1 instance mà quản lý một chuỗi dependency, khởi tạo và giải phóng cùng nhau (theo lifetime).

• D.Inversion là khái niệm về thiết kế phần mềm. Khi chưa có D.Injection, ng ta vẫn thiết kế dùng D.Inversion để giúp mã nguồn mềm dẻo, dễ thích nghi. D.Inversion khuyến khích việc trừu tượng hóa vấn đề trước khi implement nó. Lý do thì đơn giản: các bản phác họa trừu tượng hóa thường thể hiện sự tương tác giữa các lớp trừu tượng chứ không có sự phụ thuộc - như các interface: chỉ thể hiện hành vi. Các phụ thuộc chỉ có khi implement các lớp trừu tượng, tức là chỉ có trong các concrete class. Khi các concrete class thay vì phụ thuộc vào các concrete class mà phụ thuộc vào các lớp trừu tượng thì rõ ràng nó loại bỏ được rất nhiều sự phụ thuộc phát sinh của các concrete class mà nếu nó phụ thuộc vào.

D.Injection là công cụ. Còn D.Inversion là nguyên lý thiết kế.

Cái Dependency Inversion cuối khá giống với DJ, IoC trong spring boot nhỉ , đảo ngược sự phụ thuộc, thay vì bắt buộc khởi tạo Class và phụ thuộc vào class trong hàm contractor, thì no sẽ tim các Interface vào , các Interface đó được thực thi bởi các class service.

Bạn ơi Django thì có làm SEO được ko

Hay bạn ơi

Trang chủ</a> </a> <script type="text/javascript"> // hàm callback xử lý sự kiện click vào phần tử "a" function parentEventHandler() { alert("Bạn nhấp vào phần tử a"); };

// đoạn mã jQuery đăng ký hàm callback để xử lý sự kiện click vào phần tử "p" $("p").click(function (event) { alert("Bạn đã nhấp vào phần tử p"); event.stopPropagation(); }); </script>

Bạn bỏ cái href vào thẻ <p> thì nó redirect qua trang web bằng gì ạ ?

cho mình hỏi trong suốt thời gian tạo link ngrok phải mở terminal chạy đúng k ạ ?.. Và nếu tắt thì có chạy ngầm trên máy không ?..Thanks

Bạn có thể giải thích kĩ hơn về phần độ trễ và băng thông mạng được không? Những con số này lấy ở đâu ra, và tại sao lại là con số đó mà không phải số khác? Mình chưa hiểu lắm, cảm ơn bạn

@Huyennv phải có yêu cầu đặc biệt thì mới phải làm căng thế. BT các hệ thống cũng chỉ persist xuống db nào đấy rồi cache lại thôi. Wordpress chẳng hạn. Hoặc youtube.

Dễ thấy nhất là view của youtube thường bị cache. Nó có mâu thuẫn thế này:

1. trang ít view, con số view nhỏ thì việc cập nhật số view thường xuyên có vẻ được để ý.
2. trang nhiều view, con số chính xác là không quan trọng, thường người ta hiển thị con số rút ngắn như 12K, 12M. Một con số chi tiết kiểu 12.345 là không ý nghĩa hơn 12K.

Việc kiểm soát số view theo thời gian thực có thể ví dụ trong ecommerce. Khi muốn sale sản phẩm, muốn show số người xem theo thời gian thực để thúc đẩy khách hàng. Ngoài push notification để update số view, khách cũng thường refresh trang liên tục. Thực tế thì có lẽ push notification là cũng đủ hiệu quả. Con số view chỉ là tương đối.

Cần làm rõ 2 vấn đề trong câu hỏi của bạn:

1. Redis không phải là DB duy nhất trong hệ thống, vẫn cần 1 db để lưu giữ số view lâu dài.
2. Clear Redis không phải xóa số view của trang. Hệ thống sẽ tải lại số view từ DB dài hạn (persistence storage, db sơ cấp).

Có 3 cách sử dụng Redis:

1. Đơn thuần là Cache. Khi có lượt view, hệ thống tăng số trong db dài hạn (db sơ cấp). Khi query, hệ thống lấy từ Redis (cache), không có sẽ query DB sơ cấp.
2. Chạy song song Redis và DB sơ cấp. Khi có lượt view, hệ thống increase số view cả Redis lẫn db sơ cấp. Khi Redis reset, load lại dữ liệu view này từ DB theo 2 cách:

• On demand, query đến đâu load từ db sơ cấp đến đó.
• Fetch-all - load tất cả từ db bằng Job hoặc trigger.

3. Cập nhật Redis trước, định kì cập nhật lại db sơ cấp. Khi có request, increase Redis count. Job chạy update lại db sau. Khi redis reset thì fetch-all từ db sơ cấp.

Kết luận:

• Chưa tìm ra ứng dụng thực tế của việc lưu số view vào Redis. Số view chỉ là con số tương đối, không cần sử dụng kĩ thuật phức tạp để xử lý.

Bài hay

3. Trong js, mở một ngoặc nhọn là tạo một scope, nên ko chỉ catch, sau cái ngoặc nhọ nào cũng thế. Mở 1 cái ngoặc nhọn không liên quan cũng cho kết quả tương tự.

const x = 'out';

{
  const x = 'in';

  console.log(x);
}

console.log(x);

Mình có 1 câu hỏi là làm sao qua mặt được việc phát hiện xài Fake GPS

sao chép y nguyên

Public nhầm bản nháp à bạn?

Cám ơn bạn nhiều nhé. Nhưng mà giả dụ leader của mình vẫn yêu cầu lưu vào redis, thì khi nào mình nên clear cho cái phần trước đó mình lưu(key: id bài viết, value : lượt view) nhỉ. vẫn câu hỏi cũ, trường hợp common nhất thì các hệ thống đang xử lý case này như nào nhỉ, 😃 😄 bạn có thể lấy ví dụ giúp mình được không

@Huyennv Thực tế thì cũng ko cần redis. Lưu sql cũng đc. Việc đếm lượt ko quá nặng và thường thì sql cũng đủ gánh. Lượt view thường cũng ko phải realtime nên sql cũng không chiu tải nhiều (cache được thời gian dài). Dùng Redis thì vẫn cần phải lưu lại lượt view vào đâu đó lâu dài, như chạy job cuối ngày lưu lại vào sql chẳng hạn.

Theo mình thì lưu sql và cache in memory cũng ok rồi (số lượng bài viết thường không nhiều, đặc biệt bài viết active đang có nhiều người đọc). Đơn giản, tin cậy.

Cũng chưa thấy ai reset lượt view sau 30 ngày, trừ game . Kể cả 30 ngày thì vẫn cần lưu dài hạn. Redis không đủ tin cậy để làm việc đó.

Trong trường hợp là monitoring hay telemetry thì có nhiều tool sẵn có, không chỉ đếm mà còn log luôn.

@refacore 😅 Quá chuẩn! Thông thường các "hacker đỉnh của chóp" sẽ kết hợp nhiều chiêu thức tấn công DDoS, tạo ra một "combo đa sát thương" cực kỳ phức tạp và đa vector. Ping flood cũng là một mảnh ghép trong bức tranh tấn công đó.

Theo ý kiến cá nhân mình thì:

Rõ ràng các hacker sẽ "múa may quay cuồng" với đủ loại chiêu thức để tối ưu hóa cuộc tấn công. Và Hacker thì cũng có hacker "this" hacker "that", web thì cũng có web "Nhà Giàu" web "Nhà Nghèo"... Mạng botnet thì cũng đa dạng từ "đội quân tí hon" vài nghìn bot đến "đại quân" hàng triệu bot như botnet Mariposa (2008) với hơn 12 triệu bot. Vì vậy, nếu một hacker "tay mơ" chỉ có vài ngàn bot và chỉ dùng mỗi chiêu Ping flood, với các gói tin ICMP có thể lên đến 65,507 byte ≈ 0.0625 Mb trong lý thuyết (nhưng thực tế qua mạng Ethernet với MTU thì chỉ khoảng 1500 byte ≈ 0.0015 Mb), thì việc không đánh sập được một trang web là hoàn toàn có thể. Nhưng câu hỏi đặt ra là: liệu có đáng để làm vậy không?

Có câu nói vui rằng: "Bạn không bị lừa không phải vì bạn quá thông minh, mà vì người ta chưa thèm lừa bạn". Không liên quan lắm nhưng mà các bạn thấy đó, thời sự VTV ngày nào cũng chiếu những vụ lừa đảo "khủng" hàng chục tỷ trong ngân hàng (rõ ràng những nạn nhân này không hề ngốc... ai mà kiếm được trên một tỷ đều phải "trầy vi tróc vảy" cả. Anh em cứ thử tự làm ra 500tr->1tỷ xem, đảm bảo "não ông nào cũng chứa toàn cục sạn to chà bá" ngay). Thế mà vẫn mất.... Cá lớn thì mồi thơm thôi

Cuối cùng, 🤣 Như mình đã nói ở trên, "rate limiting" tuy không phải là "thuốc chữa DDoS" nhưng vẫn có thể là một kỹ thuật nhỏ, và có lẽ nó sẽ có ích trong một số trường hợp nhất định.

Bạn cho mình hỏi trường hợp mình sử dụng redis để quản lý số lượng view.

Cụ thể là nếu yêu cầu của mình là mỗi khi người dùng vào một bài viết nào đó và muốn xem lượt view là bao nhiêu ?

1. Trong redis mình sẽ không bao h clear nó đi đúng không ạ,

2. Mình đang nghĩ là mình sẽ tính toán xem cái bài viết đó ví dụ 30 ngày sau không được user (người mà đăng bài ) xem lại thì mình sẽ clear cache đi

Thường thì các dự án họ đang làm như nào bạn nhỉ?