Hai hình đầu các mũi tên sai hướng (mũi tên trỏ về phía Client). Hình đầu, sự xuất hiện của Service D, E là không cần thiết vì nó không liên quan tới Client. Liên kết giữa các service A, B, C cũng không cần vẽ trong hình. Hình 1 mô tả việc Client phải gọi đến nhiều service. Còn hình 2 Mediator giải quyết sự phức tạp đấy cho Client. Các chi tiết thừa khiến hình minh họa hơi khó hiểu.
Nhìn vào code có thể thấy request và requestHandler không biết nhau và không biết mediator. Vậy hình 2 các mũi tên là từ service hướng về Mediator, không phải mũi tên 2 chiều.
Ngoài ra có một ví dụ khá tự nhiên với mediator là chat room. Chat room là giải pháp mà ai cũng nghĩ ra được và nó cũng là một Mediator.
@kent_pro Refactoring không cần thiết phải dịch thành tái cấu trúc. Hay Automation tests cũng vậy. Cố gắng dịch sang tiếng Việt cũng tốt, nhưng sẽ khiến người đọc bị ngắt quãng. Đấy là từ vựng kĩ thuật, không cần quá cứng nhắc khi dịch.
Phần đơn giản hóa vấn đề và lắc giải pháp không phải là có mâu thuẫn sao? Loại bỏ các giả định rồi lại giả định? Lời diễn giải là chưa đủ chi tiết.
Cá nhân mình khi làm việc với UIKit thì vẫn ưa chuộng combo nhà Rx(RxSwift+RxCocoa+RxDataSource), còn với những dự án SwiftUI thì việc sử dụng Combine sẽ hợp lý hơn.
UNBOUNDED PRECEDING và UNBOUNDED FOLLOWING được sử dụng trong cùng một cửa sổ (window) cho LAST_VALUE để xác định rằng phạm vi (range) của LAST_VALUE bắt đầu từ hàng đầu tiên trong kết quả và kết thúc ở hàng cuối cùng. Trong trường hợp của FIRST_VALUE, chúng ta không cần sử dụng UNBOUNDED PRECEDING vì mặc định nó bắt đầu từ hàng đầu tiên, nên không cần xác định rõ ràng.
Chỗ Firt_value với Last_value ấy a, tại sao mình sử dụng UNBOUNDED PRECEDING và UNBOUNDED FOLLOWING trong cùng một cửa sổ (window) cho LAST_VALUE, nhưng không sử dụng chúng cho FIRST_VALUE?
Mong bạn có thể chia sẻ cách cải thiện hiệu suất truy vấn khi dùng PARTITION BY ở bài sau, đúng cái mình đang cần luôn( tính lũy tiến của từng người). xia xìa
Nếu bạn chính là người đã đưa ra khái niệm trên, giới thiệu với toàn thể thế giới, thì tôi sẽ xin lỗi bạn. Còn nếu không phải thì tôi ... vẫn xin lỗi bạn vì:
Cardinality bạn muốn dịch là lực lượng. OK. Nhưng khi nói về tập hợp, nó cũng cùng ý nghĩa với size of set. Nên tôi dịch là số lượng phần tử của tập hợp. Khi áp dụng vào các bài toán thì tôi với bạn vẫn giải quyết được vấn đề như nhau thôi.
Còn Universe hay Universal set? Bạn có thể search trên mạng, rất nhiều tài liệu đều dùng Universal set. Trên wikipedia - nơi có rất nhiều người chỉnh sửa và đóng góp để thống nhất về các kiến thức chung, cũng ghi nhận không gian mẫu là Universal set. Bản thân chữ set trong Universal set đã nghĩa là tập hợp rồi, mà bạn bảo nó không phải là tập hợp thì tôi cũng chịu. Vẫn như trên, bạn hình dung về Universe, tôi hình dung về Universal set, thì khi áp dụng vào các bài toán, cả tôi và bạn vẫn giải quyết được vấn đề như nhau thôi.
Thực ra bình thường sẽ chẳng có vấn đề gì, nhưng thấy bạn bảo trong bài lẫn lộn về 2 khái niệm này nên tôi cũng hơi ngứa mắt ))) Tôi xin lỗi bạn lần nữa, nhưng thấy cách bạn chia sẻ thì chắc hẳn bạn khá cứng nhắc trong việc sử dụng câu chữ, không biết có liên quan gì đến chuyên ngành của bạn, ví dụ bạn chuyên nghiên cứu học thuật hay gì đó không. Nên sau đoạn reply dài ngoằng này thì tôi cũng xin phép từ chối tranh cái về những khái niệm, câu chữ này. Tại viết xong tôi thấy mình rảnh ghê 😩
THẢO LUẬN
dùng join đi bro
Đáng lo là lark công ty chủ quản là của anh hàng xóm TQ
@dogsteven Cảm ơn bạn đã góp ý nhé. Tôi nghĩ chúng ta có thể dừng thảo luận về bản dịch và thuật ngữ ở đây. https://vi.wikipedia.org/wiki/Không_gian_mẫu
Em cảm ơn anh đã góp ý ạ! Chúc anh một buổi tối tốt lành!
Hai hình đầu các mũi tên sai hướng (mũi tên trỏ về phía Client). Hình đầu, sự xuất hiện của Service D, E là không cần thiết vì nó không liên quan tới Client. Liên kết giữa các service A, B, C cũng không cần vẽ trong hình. Hình 1 mô tả việc Client phải gọi đến nhiều service. Còn hình 2 Mediator giải quyết sự phức tạp đấy cho Client. Các chi tiết thừa khiến hình minh họa hơi khó hiểu.
Nhìn vào code có thể thấy request và requestHandler không biết nhau và không biết mediator. Vậy hình 2 các mũi tên là từ service hướng về Mediator, không phải mũi tên 2 chiều.
Ngoài ra có một ví dụ khá tự nhiên với mediator là chat room. Chat room là giải pháp mà ai cũng nghĩ ra được và nó cũng là một Mediator.
@kent_pro Refactoring không cần thiết phải dịch thành tái cấu trúc. Hay Automation tests cũng vậy. Cố gắng dịch sang tiếng Việt cũng tốt, nhưng sẽ khiến người đọc bị ngắt quãng. Đấy là từ vựng kĩ thuật, không cần quá cứng nhắc khi dịch. Phần đơn giản hóa vấn đề và lắc giải pháp không phải là có mâu thuẫn sao? Loại bỏ các giả định rồi lại giả định? Lời diễn giải là chưa đủ chi tiết.
@beobabo ♥️
@dovannam115 à đúng ha. em cảm ơn anh nhiều nha.😘
Cá nhân mình khi làm việc với UIKit thì vẫn ưa chuộng combo nhà Rx(RxSwift+RxCocoa+RxDataSource), còn với những dự án SwiftUI thì việc sử dụng Combine sẽ hợp lý hơn.
UNBOUNDED PRECEDING và UNBOUNDED FOLLOWING được sử dụng trong cùng một cửa sổ (window) cho LAST_VALUE để xác định rằng phạm vi (range) của LAST_VALUE bắt đầu từ hàng đầu tiên trong kết quả và kết thúc ở hàng cuối cùng. Trong trường hợp của FIRST_VALUE, chúng ta không cần sử dụng UNBOUNDED PRECEDING vì mặc định nó bắt đầu từ hàng đầu tiên, nên không cần xác định rõ ràng.
Chỗ Firt_value với Last_value ấy a, tại sao mình sử dụng UNBOUNDED PRECEDING và UNBOUNDED FOLLOWING trong cùng một cửa sổ (window) cho LAST_VALUE, nhưng không sử dụng chúng cho FIRST_VALUE?
@dovannam115 Thanks bạn.
thanks bạn. Mình sẽ viết về Query Optimization ở phần sau nha
Mong bạn có thể chia sẻ cách cải thiện hiệu suất truy vấn khi dùng PARTITION BY ở bài sau, đúng cái mình đang cần luôn( tính lũy tiến của từng người). xia xìa
mình ghi views không bị lỗi mà web báo 404 not found là không đúng đường dẫn à
Very informative, thanks for sharing. Ecommerce Website Designers in Chennai Website Designing Company in Chennai Ecommerce Website Designing Company in Chennai Web Development Company in Chennai Website Designers in Chennai Best Web Designing & Development Company in Chennai Web Application Development Company in Chennai SEO based Digital Marketing Company in Chennai Android Application Development Company in Chennai SEO Company in Chennai Digital Marketing Services in Chennai Digital Marketing Company in Chennai IOS Application Development Company in Chennai Ecommerce Website Designing & Development Company in Chennai Web Development Company in Chennai. Web design company India Web designing company Web design company in Chennai Website design company chennai Website design chennai Website designer chennai Creative web design company India Professional web design company Chennai Best web design company Chennai Top web design company Chennai Web hosting Chennai Ecommerce web design company Ecommerce website designing company in chennai Ecommerce website designer chennai Ecommerce website designer Ecommerce website designer India Website design India search engine optimization company Chennai Digital Marketing Services Chennai
Nếu bạn chính là người đã đưa ra khái niệm trên, giới thiệu với toàn thể thế giới, thì tôi sẽ xin lỗi bạn. Còn nếu không phải thì tôi ... vẫn xin lỗi bạn vì:
Thực ra bình thường sẽ chẳng có vấn đề gì, nhưng thấy bạn bảo trong bài lẫn lộn về 2 khái niệm này nên tôi cũng hơi ngứa mắt
))) Tôi xin lỗi bạn lần nữa, nhưng thấy cách bạn chia sẻ thì chắc hẳn bạn khá cứng nhắc trong việc sử dụng câu chữ, không biết có liên quan gì đến chuyên ngành của bạn, ví dụ bạn chuyên nghiên cứu học thuật hay gì đó không. Nên sau đoạn reply dài ngoằng này thì tôi cũng xin phép từ chối tranh cái về những khái niệm, câu chữ này. Tại viết xong tôi thấy mình rảnh ghê 😩
@nguyentuan239 e hiểu r 😁 cảm ơn bác ạ 😁
hay quá, cảm ơn tác giả
Nếu X đánh vào đó được 3 X liên tiếp -> điểm thủ của O sẽ là 2 X liên tiếp nếu đánh O vào vị trí đó