Bạn có đang “đau đầu” vì một câu query SQL, dù rất đơn giản, lại chạy mãi không xong trên một bảng dữ liệu ngày càng “béo phì”? Bạn là dev đang săn lùng từng mili giây hiệu suất, là tester đang vật lộn với những bài test performance, hay đơn giản là người mới tò mò về thế giới dữ liệu?

Nếu câu trả lời là “có”, thì đây chính là “liều thuốc” bạn cần.

Hãy quên đi những định nghĩa khô khan. Hôm nay, chúng ta sẽ khám phá SQL Partitioning – một kỹ thuật “chia để trị” đầy quyền năng – qua những ví dụ đời thường và những bí kíp thực chiến mà bạn sẽ không tìm thấy trong sách vở.

1. SQL Partitioning Là Gì?

Trước hết, Hãy tưởng tượng database của bạn là một cái nhà kho khổng lồ, chứa hàng triệu món đồ (dữ liệu). Khi cần tìm một món đồ, bạn phải chạy khắp cái nhà kho đó. Rất mất thời gian!

Tuy nhiên, nếu bạn chia nhà kho thành các gian nhỏ có nhãn rõ ràng, mọi thứ sẽ khác.

SQL Partitioning chính là việc bạn thông minh sắp xếp nhà kho đó thành các gian hàng nhỏ hơn, được dán nhãn rõ ràng (gọi là các partition – phân vùng):

• Gian hàng “Hóa đơn năm 2023”
• Gian hàng “Hóa đơn năm 2024”
• Gian hàng “Hóa đơn năm 2025”

CREATE TABLE invoice (
    invoice_id INT,
    invoice_date DATE,
    amount DECIMAL(10,2)
)
PARTITION BY RANGE (YEAR(invoice_date)) (
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

Khi sếp yêu cầu bạn tìm hóa đơn tháng 12/2024, bạn chỉ việc đi thẳng đến gian hàng “Hóa đơn năm 2024” để tìm. Nhanh hơn gấp bội!

Quan trọng hơn, dù dữ liệu được chia nhỏ ra bên dưới, đối với ứng dụng của bạn nó vẫn là một bảng duy nhất. Đó chính là sự “thần kỳ” của partition.

Lợi ích VÀNG của Partitioning:

• Tăng tốc độ truy vấn “tên lửa”: Khi bạn lọc dữ liệu theo “nhãn” của gian hàng (ví dụ: WHERE OrderDate BETWEEN '2024-01-01' AND '2024-12-31'), hệ thống sẽ chỉ quét gian hàng “2024”, bỏ qua toàn bộ các gian hàng khác. Đây gọi là kỹ thuật Partition Pruning (cắt tỉa phân vùng).
• Quản lý dữ liệu dễ như trở bàn tay: Muốn xóa toàn bộ dữ liệu năm 2020? Thay vì chạy lệnh DELETE hàng triệu dòng và chờ “dài cổ”, bạn chỉ cần “dỡ” cả gian hàng 2020 đi. Xong!
• Bảo trì nhẹ nhàng hơn: Việc bảo trì (như rebuild index) trên một gian hàng nhỏ sẽ nhanh và ít ảnh hưởng đến hệ thống hơn là làm trên cả cái nhà kho.

2. Các “Loại Vũ Khí” Phân Vùng Phổ Biến: Chọn Đúng, Thắng To

Có 3 loại partitioning chính. Việc chọn đúng loại sẽ quyết định sự thành bại của bạn.

RANGE Partitioning (Phân vùng theo Khoảng)

• Ý tưởng: Chia dữ liệu theo một khoảng giá trị liên tục.
• Ví dụ Kinh điển: Phân vùng bảng Sales theo cột OrderDate. Mỗi phân vùng chứa dữ liệu của một tháng hoặc một quý.
• Khi nào dùng: Cực kỳ hoàn hảo cho dữ liệu chuỗi thời gian (time-series) như logs, giao dịch, dữ liệu cảm biến IoT.

LIST Partitioning (Phân vùng theo Danh sách)

• Ý tưởng: Chia dữ liệu theo một danh sách các giá trị cụ thể.
• Ví dụ Kinh điển: Phân vùng bảng Customers theo cột Region (Vùng miền). Một phân vùng cho ‘Miền Bắc’, một cho ‘Miền Trung’, một cho ‘Miền Nam’.
• Khi nào dùng: Phù hợp khi cột phân vùng có một tập hợp các giá trị hữu hạn và rõ ràng (như Tỉnh/Thành, Trạng thái, Loại sản phẩm).

HASH Partitioning (Phân vùng theo Hàm băm)

• Ý tưởng: Tự động phân bổ đều dữ liệu vào một số lượng phân vùng đã định trước.
• Ví dụ Kinh điển: Phân vùng bảng Users theo user_id. Hệ thống sẽ dùng một thuật toán để đảm bảo dữ liệu người dùng được chia đều vào các phân vùng.
• Khi nào dùng: Dùng khi bạn không có cột nào phù hợp cho RANGE hay LIST, và mục tiêu chính là phân tán đều dữ liệu để tránh “điểm nóng”.

3. Bí Kíp Thực Chiến & Những “Cú Lừa” Cần Tránh

Lý thuyết màu hồng, nhưng thực tế thì… không phải lúc nào cũng vậy. Đây là những kinh nghiệm xương máu giúp bạn tránh đi vào “vết xe đổ”.

Hỏi & Đáp Nhanh: Các Lỗi Sai Kinh Điển Khi Dùng Partitioning

Câu hỏi: Tôi đã phân vùng rồi mà query vẫn chậm như rùa. Tôi đã làm sai ở đâu?

Trả lời: Rất có thể bạn đã mắc phải một trong những lỗi sau:

• Chọn sai “Chìa Khóa” (Partition Key): Đây là sai lầm chết người nhất. Nếu các query của bạn không lọc theo cột mà bạn dùng để phân vùng (partition key), thì việc phân vùng hoàn toàn vô dụng. Hệ thống vẫn phải quét tất cả các “gian hàng”.
• “Tham Lam” Chia Quá Nhiều Phân Vùng: Chia nhỏ quá không tốt! Quá nhiều phân vùng sẽ làm tăng gánh nặng quản lý cho database, khiến việc lên kế hoạch truy vấn chậm đi. Vài chục đến vài trăm phân vùng thường là con số hợp lý.
• Dữ Liệu Phân Bổ Không Đều: Nếu 90% dữ liệu của bạn bị dồn vào chỉ một phân vùng, thì lợi ích gần như bằng không. Hãy phân tích dữ liệu trước khi chọn cột phân vùng.
• “Bỏ quên” Index: Partitioning và Indexing là “cặp bài trùng” chứ không phải kẻ thù. Phân vùng giúp giới hạn số lượng dữ liệu cần quét, còn index giúp tìm kiếm nhanh chóng bên trong phân vùng đó.
• Đừng chia quá nhỏ (Over-partitioning)
  Đừng chia mỗi ngày 1 partition nếu bạn có dữ liệu 10 năm (sẽ ra 3650 partitions). Khi partitions quá nhiều:
  • Hệ điều hành quá tải vì mở quá nhiều file.
  • Database tốn tài nguyên để quản lý metadata.
  • Query có thể chậm hơn cả không partition.
  • Lời khuyên: Giữ số lượng partition ở mức hợp lý (dưới 100 thường là con số an toàn cho MySQL, Oracle thì có thể nhiều hơn).
• Cẩn thận với Primary Key: Hầu hết các DB engine (như MySQL) yêu cầu cột dùng để Partition phải nằm trong Primary Key. Điều này có nghĩa là PK của bạn sẽ phải đổi từ (id) sang (id, order_date). Dev team cần lưu ý chỗ này kẻo code logic bị sai.

Kết Luận: Partitioning Là Một Tư Duy, Không Chỉ Là Công Cụ

SQL Partitioning không phải là viên đạn bạc cho mọi vấn đề. Nó là một công cụ quản lý dữ liệu cực kỳ mạnh mẽ ở quy mô lớn, với “tác dụng phụ” tuyệt vời là cải thiện hiệu suất.

Lời khuyên cuối cùng: Đừng vội vàng phân vùng mọi bảng bạn có. Hãy luôn bắt đầu bằng việc tối ưu query và index. Chỉ khi bảng dữ liệu đã thực sự phình to (hàng trăm triệu dòng) và các phương pháp khác đã “bó tay”, đó mới là lúc bạn rút “thanh bảo kiếm” Partitioning ra.

Chúc bạn thành công trên con đường chinh phục dữ liệu!

The post SQL Partitioning: “Chia Để Trị” Dữ Liệu Khổng Lồ appeared first on Tomoshare.

Mở đầu: Nỗi đau của Developer

Bạn đang phát triển một ứng dụng local, mọi thứ chạy mượt mà ở localhost:3000. Nhưng vấn đề nảy sinh khi:

• Bạn cần test Webhook từ các dịch vụ bên ngoài như ZaloPay, Stripe, Telegram (các bên này bắt buộc phải có HTTPS).
• Khách hàng muốn xem demo ngay lập tức, nhưng bạn chưa kịp deploy lên server.
• Bạn chán ngấy cảnh dùng Ngrok bản free vì tên miền bị đổi liên tục sau mỗi lần restart.

Giải pháp tối ưu nhất hiện nay chính là Cloudflare Tunnel.

1. Cloudflare Tunnel là gì?

Cloudflare Tunnel (trước đây là Argo Tunnel) là công cụ giúp bạn kết nối máy chủ local (hoặc máy ảo) ra internet mà không cần mở port (port forwarding) trên router.

Thay vì cho phép người lạ truy cập trực tiếp vào IP của bạn (rất rủi ro), Tunnel tạo một đường hầm bảo mật (outbound connection) từ máy bạn đến mạng lưới Cloudflare Edge. Từ đó, Cloudflare sẽ “public” ứng dụng của bạn ra ngoài bằng một tên miền HTTPS xịn xò.

Tại sao nên dùng Cloudflare Tunnel thay vì Ngrok?

2. Mô hình hoạt động

Hãy tưởng tượng luồng dữ liệu sẽ đi như sau:

User Browser -> Cloudflare Edge (HTTPS) -> Cloudflared (trên máy bạn) -> Localhost (3000, 8080…)

Bạn có thể chạy nhiều dịch vụ cùng lúc qua một đường hầm duy nhất:

• api.domain.com -> trỏ về localhost:3000
• admin.domain.com -> trỏ về localhost:8080

3. Chuẩn bị “đồ nghề”

Trước khi bắt đầu, bạn cần:

1. Tài khoản Cloudflare (đăng ký miễn phí).
2. Một tên miền (Domain) đã thêm vào Cloudflare.
   • Lưu ý: Freenom hiện tại không ổn định. Bạn nên mua các domain giá rẻ như .xyz, .dev, .click (chỉ khoảng 1-2$/năm) tại Namecheap hoặc Hostinger để dùng lâu dài.
3. Máy tính (Linux/Mac/Windows) để chạy tool.

4. Hướng dẫn triển khai chi tiết (Step-by-step)

Bước 1: Cài đặt cloudflared

Công cụ cloudflared là cầu nối giữa máy bạn và Cloudflare.

Trên Linux (Ubuntu/Debian):codeBash

curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb -o cloudflared.deb
sudo dpkg -i cloudflared.deb

Trên Windows:
Tải file .msi mới nhất từ GitHub chính chủ: Cloudflare Downloads
(Mở PowerShell dưới quyền Administrator để chạy các lệnh sau này).

Bước 2: Đăng nhập Cloudflare

Chạy lệnh sau để xác thực:codeBash

cloudflared tunnel login

Trình duyệt sẽ bật lên, bạn hãy chọn tên miền muốn sử dụng và bấm Authorize.

Bước 3: Tạo Tunnel

Đặt tên cho tunnel của bạn (ví dụ: my-local-server):codeBash

cloudflared tunnel create my-local-server

Sau khi tạo xong, Cloudflare sẽ sinh ra một Tunnel ID và file credentials (thường nằm ở ~/.cloudflared/).

Bước 4: Cấu hình định tuyến (Routing)

Đây là bước quan trọng nhất để map domain về localhost.
Tạo file config.yml trong thư mục ~/.cloudflared/ (hoặc cùng thư mục chạy tool) với nội dung:codeYaml

tunnel: <TUNNEL-NAME-HOẶC-ID>
credentials-file: /duong/dan/den/file/json/credentials.json

ingress:
  # Service 1: API Backend
  - hostname: api.namdevlabs.com
    service: http://localhost:3000

  # Service 2: Webhook test (ZaloPay, Stripe)
  - hostname: hook.namdevlabs.com
    service: http://localhost:5678

  # Service 3: Dashboard Admin
  - hostname: admin.namdevlabs.com
    service: http://localhost:8080

  # Rule cuối cùng bắt buộc: Trả về 404 nếu không khớp domain nào
  - service: http_status:404

Bước 5: Gắn DNS cho Subdomain

Bạn cần báo cho Cloudflare biết subdomain nào sẽ đi vào tunnel này.codeBash

# Cú pháp: cloudflared tunnel route dns <TUNNEL_NAME> <SUBDOMAIN>
cloudflared tunnel route dns my-local-server api.namdevlabs.com
cloudflared tunnel route dns my-local-server hook.namdevlabs.com

Lệnh này sẽ tự động tạo bản ghi CNAME trên Cloudflare Dashboard.

Bước 6: Kích hoạt Tunnel

Chạy tunnel với file config vừa tạo:codeBash

cloudflared tunnel run my-local-server

Mẹo: Nếu file config không nằm ở vị trí mặc định, dùng flag –config:
cloudflared tunnel –config /path/to/config.yml run

 Xong! Bây giờ bạn có thể truy cập https://api.namdevlabs.com và thấy nó trỏ thẳng về localhost:3000 của bạn với HTTPS xanh mượt.

5. Mẹo nâng cao cho Pro Developer

• Chạy ngầm (Service Mode): Để tunnel tự chạy khi khởi động máy (dành cho server home lab):codeBashsudo cloudflared service install sudo systemctl start cloudflared
• Bảo mật Zero Trust: Bạn sợ người lạ vào link demo? Vào Cloudflare Dashboard -> Zero Trust, bật tính năng yêu cầu đăng nhập bằng Email/Google trước khi truy cập vào domain.
• Debug lỗi: Nếu không truy cập được, hãy thêm flag –loglevel debug khi chạy để xem log chi tiết.

6. Tổng kết

Cloudflare Tunnel thực sự là một vũ khí lợi hại trong bộ công cụ của developer. Nó giúp bạn:

1. Tiết kiệm tiền: Không tốn phí server staging.
2. Tiết kiệm thời gian: Không cần deploy để demo.
3. An toàn: Không mở port, hạn chế tấn công DDoS.

Hy vọng bài viết giúp bạn giải quyết được bài toán đau đầu về Webhook và Demo. Chúc bạn code vui!

The post Đưa Localhost lên Internet miễn phí với Cloudflare Tunnel: Giải pháp thay thế Ngrok để Test Webhook & Demo App appeared first on Tomoshare.

Daily report là bản báo cáo nội dung, kết quả công việc hàng ngày của mỗi người. 

Từ bản báo cáo này, PM, khách hàng có thể nắm được tiến độ, khó khăn, kết quả, kế hoạch từng ngày của mỗi người. 

Tầm quan trọng của daily report ?

• Với PM, khách hàng : nắm được tiến độ, kết quả công việc từng ngày, từ đó điều chỉnh kế hoạch và có những thay đổi cho phù hợp. 
• Ngoài ra, PM cũng nắm được khó khăn của mỗi người, từ đó có sự hỗ trợ kịp thời. 
• Với cả team, việc chia sẻ và đọc daily report của nhau giúp mọi người nắm được tiến độ tổng thể, học từ kinh nghiệm từ người khác, hoặc giúp đỡ nhau khi gặp khó khăn. 
• Với từng cá nhân, daily report giúp mỗi người nắm được tiến độ, kết quả công việc của mình, từ đó gia tăng sự thỏa mãn, hài lòng khi nhìn lại những giá trị mình tạo ra. Nó cũng giúp ta chấn chỉnh lại tiến độ, sự tập trung khi kết quả chưa đạt như mong muốn. 

Thế nào là 1 daily report tốt ? 

1. Đầy đủ nhưng ngắn gọn. Đầy đủ những công việc mình đã làm, nhưng viết ngắn gọn thôi. Tốt nhất là viết thành mỗi công việc thành 1 gạch đầu dòng. 
2. Mỗi công việc (gạch đầu dòng) phải có quá trình và kết quả. 
3. Mỗi công việc cần phải có thời gian thực hiện đi kèm. 
4. Phải có evidence đi kèm với mỗi công việc. 
5. Phải có kế hoạch cho ngày tiếp theo ( dựa theo kết quả của ngày hôm nay ). 

Cách viết daily report 

1. Nên vừa làm, vừa có 1 bản note đi ghi chép lại, nếu không mình sẽ bị quên. 
2. Note theo format của daily report là tốt nhất, đỡ mất công sửa lại. 
3. Nên có plan đến từng giờ trong ngày và cố gắng thực hiện theo. 
4. Mọi người phải có ý thức review daily report của nhau như là review code. 
5. Sau khi viết về công việc trong ngày, cần đánh giá lại và lên kế hoạch cho ngày hôm sau. 

The post Cách viết 1 daily report tốt appeared first on Tomoshare.

Trong mọi hoàn cảnh hãy thử đặt mình vào vị trí người khác chúng sẽ dễ có cách giải quyết đúng đắn và thuyết phục, dưới đây là một vài lời khuyên “không cụ thể”.

1. Đưa ra góp ý xây dựng:

• Tập trung vào vấn đề: Chú ý vào các phần của code hoặc logic cần cải thiện hoặc có vấn đề.
• Đề xuất cải thiện: Đưa ra ý kiến xây dựng, gợi ý cách để cải thiện mã nguồn, thay vì chỉ nhấn mạnh vấn đề.
• Đánh nhãn nếu có thể: Hãy tập trung vào những điểm High cần phải thay đổi, Middle nên thay đổi, Low thay đổi càng tốt

2. Sử dụng ngôn ngữ tích cực và tôn trọng:

• Lời khuyên thay vì chỉ trích: Sử dụng ngôn ngữ tích cực để gợi ý cách sửa đổi hoặc cải thiện.
• Tôn trọng ý kiến: Đề xuất ý kiến của bạn một cách lịch sự và tôn trọng, tránh ngôn từ hoặc cách diễn đạt có thể bị hiểu là chỉ trích.

3. Giải thích rõ ràng và minh bạch:

• Minh bạch: Giải thích tại sao bạn đề xuất thay đổi hoặc cần sửa đổi để người khác hiểu rõ lý do.
• Ví dụ cụ thể (nếu có thể): Nếu có thể, cung cấp ví dụ cụ thể để minh họa vấn đề hoặc cải thiện đề xuất của bạn.

4. Tránh mâu thuẫn và xung đột:

• Hỏi trước khi giả định: Nếu có điều gì không rõ ràng, hãy hỏi trước khi đưa ra giả định hoặc nhận xét.
• Tránh tranh cãi: Tránh tranh cãi không cần thiết và tập trung vào giải quyết vấn đề.

5. Đề xuất giải pháp:

• Đề xuất sửa đổi cụ thể: Nếu có thể, đề xuất cách thức cụ thể để sửa đổi vấn đề đã được xác định.
• Hỗ trợ người gửi PR: Nếu bạn có kiến thức hoặc kinh nghiệm để giúp người gửi PR hoàn thiện mã nguồn, hãy chia sẻ.

6. Theo dõi và phản hồi:

• Theo dõi và phản hồi: Theo dõi sự phản hồi từ người gửi PR và trả lời các câu hỏi hoặc bất kỳ yêu cầu giải thích nào.
• Hiểu và thấu hiểu: Đôi khi, người gửi PR có lý do riêng cho cách họ viết mã nguồn. Hiểu và cân nhắc trước khi yêu cầu thay đổi, có câu hiểu người khác là khôn ngoan, hiểu được chính mình là giác ngộ!!!

Cám ơn mọi người đã vào và đọc được dòng chữ này!!!!

The post Review Code: Một số tips để đạt được hiệu quả. appeared first on Tomoshare.

• Lượng Truy Cập (Traffic): Ước lượng số lượt truy cập trang web hàng ngày, hàng giờ, hoặc trong khoảng thời gian nào đó.
• Loại Website: Loại website của bạn ảnh hưởng đến lượng tài nguyên cần thiết. Ví dụ, một trang web dạng blog có thể yêu cầu ít tài nguyên hơn so với một trang web thương mại điện tử phức tạp.
• Nội Dung Động: Nếu trang web của bạn chứa nhiều nội dung động, ví dụ như video, hình ảnh động, hay tính năng tương tác cao, sẽ đòi hỏi nhiều tài nguyên hơn so với trang web tĩnh.
• Cơ Sở Dữ Liệu: Kích thước cơ sở dữ liệu và số lượng truy vấn đối với cơ sở dữ liệu cũng quan trọng. Một trang web sử dụng cơ sở dữ liệu lớn và phức tạp sẽ đòi hỏi nhiều tài nguyên hơn.
• Cache và Tối Ưu Hóa: Sử dụng kỹ thuật tối ưu hóa và cache có thể giảm áp lực lên tài nguyên server.
• Dịch Vụ Bên Ngoài: Nếu bạn sử dụng các dịch vụ bên ngoài như CDN (Content Delivery Network) hoặc các dịch vụ quản lý nội dung, có thể giảm áp lực lên server của bạn.
• Đánh Giá Hiệu Năng Hệ Thống: Đánh giá hiệu năng của server hiện tại để xem xét việc nâng cấp.
• Dự Đoán Mở Rộng:Nếu bạn dự định mở rộng website trong tương lai, hãy xem xét các yếu tố mở rộng và dự đoán nhu cầu tài nguyên tương lai.
• Thử Nghiệm và Đo Lường: Thử nghiệm tải và đo lường hiệu suất có thể cung cấp thông tin quan trọng về cách website của bạn phản ứng dưới áp lực.
• Chính Sách và Yêu Cầu Kỹ Thuật: Xác định các chính sách và yêu cầu kỹ thuật cụ thể của bạn, chẳng hạn như thời gian phản hồi tối đa.
• …

Vậy cấu hình phần cứng bao nhiêu là phù hợp?

Trước tiên cần xác định số lượng người truy cập trong một ngày cũng như số lượng người online đồng thời trung bình. Bạn có thể sử dụng Google Analytics để thống kê và phân tích dữ liệu người dùng khi truy cập website của bạn.
Đối với các loại website load nhẹ chỉ có bài viết, tin tức, hình ảnh vừa phải và có traffic dưới 2000 visit mỗi ngày hoặc website load nặng nhiều bài viết, hình ảnh và có traffic dưới 1000 visit mỗi ngày thì bạn có thể cấu hình tầm 512MB RAM và 1core CPU.
Dưới đây là bảng cấu hình tham khảo dành cho bạn dựa theo lượt truy cập.

Nên chọn CPU có nhiều nhân (core) cho máy chủ. Số lượng nhân CPU càng nhiều thì nó sẽ càng có lợi cho người sử dụng. CPU nhanh hơn thì máy chủ nhanh hơn, nó giúp cho quá trình sử lý dữ liệu diễn ra nhanh gấp nhiều lần. Hãy luôn ưu tiên CPU nhiều nhân, một CPU có ít nhân nhưng có xung nhịp cao sẽ không tốt bằng một CPU có nhiều nhân với xung nhịp thấp hơn.
Đầu tư tối đa RAM cho cấu hình máy chủ. Cấu hình server với bộ nhớ RAM cao giúp sử lý được nhiều dữ liệu cùng một lúc, tránh tình trạng máy tính bị đơ hay treo máy.

Đối với những website phát triển nhanh, số lượng dữ liệu lưu trữ ngày càng nhiều dẫn đến database ngày càng tăng. Bạn cần thường xuyên theo dõi mức độ sử dụng tài nguyên RAM, và có kế hoạch nâng cấp khi lượng RAM gần hết vì database càng lớn thì nhu cầu sử dụng RAM càng nhiều.

Tổng kết

Một máy chủ có thể có cấu hình tối ưu với khoảng 4-8 GB RAM và 2-4 CPU core cho một website với lượng truy cập trung bình. Tuy nhiên, điều này chỉ là một ước lượng tổng quát và bạn nên thử nghiệm trên môi trường thực tế, và dự theo sự thay đổi của các yếu tố mình đã chia sẽ ở trên mà cập nhật lại để đảm bảo website đáp ứng đúng với yêu cầu cụ thể của bạn.

Cảm ơn các bạn đã đọc bài viết của mình, chúc mọi người có thêm nhiều kiến thức hay để phục vụ cho dự án!

The post Ước tính RAM / CPU cần sử dụng cho một website appeared first on Tomoshare.

Ngày nay khi mà cuộc sống nhộn nhịp hơn thì sẽ đi kèm với nhiều sự căng thẳng, nỗi lo và nhiều áp lực hơn đến từ nhiều khía cạnh khác nhau trong cuộc sống, sự quay cuồng đó đôi khi khiến cho chúng ta bị thiếu vắng đi tiếng cười.

Nhưng bạn biết không, như 1 loại thuốc giảm đau, nụ cười mang đến cho chúng ta rất nhiều lời ích về sức khỏe và tinh thần. Rất nhiều thông tin bài viết đề cập đến vấn đề này và đây là 4 lợi ích được tổng hợp lại trong blog của NPV mà mình muốn chia sẻ đến mọi người.

Cười mang lại nhiều lợi ích đáng ngạc nhiên, vì vậy

CỨ CƯỜI THẬT TO – RẤT CÓ LỢI

1. Improved short-term memory – Tăng trí nhớ ngắn hạn: nghiên cứu cho thấy cười làm giảm hormone gây stress trong cơ thể, và vì vậy giúp tăng trí nhớ ngắn hạn. Ai hay quên thì cười nhiều vào nhé.

2. Enhanced group performance – Giúp tăng cường hiệu quả làm việc nhóm: một nghiên cứu tâm lý cho thấy tính hài hước và những câu chuyện gây cười kích thích sự giao tiếp tích cực trong đội nhóm, làm mọi người bớt căng thẳng với qui trình, qui định, và kích thích những giải pháp mới, sáng tạo. Cười do đó là cách tiếp cận rất hiệu quả giúp môi trường làm việc sáng tạo hơn. Cười kết nối đội ngũ lại với nhau, giúp họ giao tiếp và hỗ trợ nhau tốt hơn.

3. New friendship – Mở ra những quan hệ bạn bè mới: khi cười, chúng ta trở nên ít phòng thủ hơn, chia sẻ những phút giây cá nhân hơn với người đối diện. Nghiên cứu cho thấy khi chúng ta chia sẻ những thông tin cá nhân, riêng tư, chúng ta đang xây dựng nền tảng quan hệ cá nhân với người đối diện.

4. Increased pain resistance – Tăng khả năng chịu đựng: theo nghiên cứu, khi cười, ngưỡng chịu đựng đau đớn, khó khăn của con người tăng lên thêm 10% so với bình thường. Đó là lý do vì sao người hay cười thì lạc quan và dễ dàng vượt qua mọi khó khăn thử thách trong đời.

LOL! Chúc các bạn luôn luôn có những giây phút cười thật to trong ngày, luôn có tinh thần thật vui vẻ và tận hưởng cuộc sống hết mình. Cuộc đời sẽ dễ dàng hơn rất nhiều nếu chúng ta cứ là mình, và cứ cười vang.

The post LOL – LAUGH OUT LOUD appeared first on Tomoshare.

Tạo SSH key

ls -al ~/.ssh

Đầu tiên, chúng ta có thể kiểm tra xem liệu chúng ta có bất kỳ SSH key nào hiện có hay không.

Nếu đã có, ta có thể dùng các key đó, còn nếu chưa có key nào cả thì có thể tạo bằng lệnh dưới.

ssh-keygen -t rsa -C "email_cua_ban@work-mail.com" -f "ssh_file_name"

Ví dụ:

ssh-keygen -t rsa -C "bao.van@tomosia.com" -f "id_rsa_work"

Đoạn mã trên sẽ tạo các SSH key và lưu public key có tag bao.van@tomosia.com vào ~/.ssh/id_rsa_work.pub.

Khi được yêu cầu vị trí lưu SSH key, hãy chấp nhận vị trí mặc định bằng cách nhấn enter. Key private và key public ~/.ssh/id_rsa_work.pub sẽ được tạo tại vị trí ssh mặc định ~/.ssh/. Chúng ta đã tạo được ssh key cho account phục vụ công việc, tương tự cho email phục vụ mục đích cá nhân. Tôi đặt tên cho ssh key cá nhân là id_rsa_personal. Sau khi tạo xong chúng ta sẽ có 2 key dưới:

~/.ssh/id_rsa_personal
~/.ssh/id_rsa_work

Thêm SSH key mới vào tài khoản GitHub tương ứng

Chúng ta đã có SSH public key và chúng ta sẽ thêm chúng tài khoản GitHub của mình.

Sao chép public key pbcopy < ~/.ssh/id_rsa_personal.pub rồi đăng nhập vào tài khoản GitHub cá nhân của bạn:

• Đi tới Setting
• Chọn SSH Key and GPG từ menu bên trái.
• Nhấp vào New SSH Key, cung cấp tiêu đề phù hợp và dán nội dung của SSH key vào editor bên dưới
• Nhấp vào Add Key – Done!

Đối với tài khoản công việc, hãy sử dụng public key tương ứng (pbcopy < ~/.ssh/id_rsa_work.pub) và lặp lại các bước trên trong tài khoản công việc GitHub của bạn.

Đăng ký SSH Key với SSH Agent

Để sử dụng các key, phải đăng ký chúng với ssh agent trên máy của mình. Đảm bảo ssh-agent đang chạy bằng lệnh eval "$(ssh-agent -s)".

Thêm private key vào ssh-agent như sau:

ssh-add ~/.ssh/id_rsa_personal
ssh-add ~/.ssh/id_rsa_work

Sau đó, làm cho ssh-agent sử dụng các SSH Keys tương ứng cho các SSH Hosts khác nhau bằng cách sử dụng file config cấu hình cho SSH.

Tạo tệp cấu hình SSH

Tệp cấu hình SSH sẽ có tại ~/.ssh/config. Chỉnh sửa nó nếu nó tồn tại, nếu không chúng ta có thể tạo nó.

cd ~/.ssh/
touch config           // Creates the file if not exists
nano config            // edit file

Tạo các mục cấu hình cho các tài khoản GitHub có liên quan tương tự như mục bên dưới trong tệp ~/.ssh/config của bạn:

# Personal account
Host github.com
   HostName github.com
   User git
   IdentityFile ~/.ssh/id_rsa_personal
   
# Work account
Host github.com-work
   HostName github.com
   User git
   IdentityFile ~/.ssh/id_rsa_work

work là id người dùng GitHub cho tài khoản công việc.

github.com-work là ký hiệu được sử dụng để phân biệt nhiều tài khoản Git. Đảm bảo bạn nhất quán với ký hiệu tên máy chủ mà bạn sử dụng. Điều này có liên quan khi ta clone một repository hoặc set the remote origin cho repository ở local

Cấu hình trên yêu cầu ssh-agent:

Sử dụng key id_rsa_personal cho bất kỳ URL Git nào sử dụng @github.com

Sử dụng key id_rsa_work cho bất kỳ URL Git nào sử dụng @github.com-work

Như vậy là ta đã hoàn thành xong việc config để sử dụng 2 tài khoản Github. Thử clone một repository hoặc làm việc với một repo ở local nhé.

Clone Repository

Khi các cấu hình đã ổn, chúng ta có thể tiếp tục và clone các repository tương ứng. Khi clone, ta chỉ cần sử dụng các Host là github.com cho account personal và github.com-work cho account work. Ví dụ như dưới.

Với account cho công việc:

git clone git@github.com-work:TOMOSIA-VIETNAM/tomogpt.git

Và account cá nhân:

git clone git@github.com:BaoVanPhu/django-learning.git

Thay đổi này được thực hiện tùy thuộc vào Host được xác định trong tệp config SSH. Giữa @ và : phải khớp với những gì ta đã cung cấp trong tệp config SSH.

Local Repository

Với repository đã được cloned trước đó:

Ta chỉ cần update lại remote-url như lệnh dưới

Với account công việc:

git remote set-url origin git@github.com-work:yamatabitabi/ytb-ec-site.git

Tương tự cho account cá nhân 😀

Nếu tạo một repository mới ở local:

Khởi tạo Git trong thư mục dự án git init.

Tạo một repo mới trong tài khoản GitHub rồi add Git remote vào repo ở local

git remote add origin git@github.com-work:TOMOSIA-VIETNAM/new_repo.git 

Sau đó add file và commit rồi push code lên thôi.

Account cá nhân thì như bình thường rồi, không có gì phải bàn =))

Done!

Conclusion

Đây là những kinh nghiệm mình đã được đọc và config ở laptop của mình. Hi vọng sẽ có ích cho mọi người.

Cảm ơn mọi người đã dành thời gian để đọc. 😀

Nguồn: Freecodecamp

The post Cách sử dụng nhiều tài khoản GitHub trên một thiết bị bằng SSH Key appeared first on Tomoshare.

Chắc hẳn khá nhiều bạn đã từng nghe về cuốn sách “Nine Things Successful People Do Differently” rồi nhỉ? Đây là tác phẩm nổi tiếng của tiến sĩ tâm lý Heidi Grant Halvorson. Nội dung cuốn sách chia sẻ về 9 điều người thành công thường làm – những chiến lược giúp họ có thể xây dựng mục tiêu và đạt được thành công.

Cá nhân mình nghĩ với những ai lười đọc thể loại sách kĩ năng thì chắc chắn đây sẽ là cuốn sách đỡ “ngán” nhất, bởi vì nó được viết ngắn gọn và rất dễ đọc. Trong quyển sách này mỗi chương sách viết về một chiến lược, và cả 9 chiến lược đều dựa trên các nghiên cứu khoa học liên quan. Hiện tại sách vẫn chưa có bản dịch tiếng Việt, nếu mọi người có hứng thú thì có thể tìm đọc ở link dưới:
 https://hbr.org/2011/02/nine-things-successful-people

Quay trở lại chủ đề chính, hôm nay mình muốn chia sẻ về 2 trong số 9 chiến lược được đề cập trong sách “Nine Things Successful People Do Differently” mà mình đã từng áp dụng để thay đổi một vài thói quen xấu.

1. Phương pháp “Nếu-Thì” – If-Then (Seize The Moment To Act On Your Goals)

Phương pháp này hẳn không còn xa lạ với mọi người. Cấu trúc thông thường sẽ là: “NẾU X diễn ra THÌ tôi sẽ làm việc Y” (If X happens, then I will do Y).

Tip khi sử dùng phương pháp này là hãy xác định rõ thời điểm và địa điểm cần thực hiện hành động, viết cụ thể ra một tờ giấy hoặc sổ tay. Bạn cũng hoàn toàn có thể chèn thêm một hoặc hai hành động khác để tạo thành chuỗi thói quen.

Ví dụ:

Nếu tôi dậy sớm lúc 6 giờ, thì tôi sẽ trải thảm yoga trong phòng để tập 30p.

Nếu tôi hoàn thành xong việc tập yoga sau khi dậy, thì tôi sẽ dọn dẹp phòng rồi xuống nhà ăn sáng.

2. Tập trung vào điều cần làm, thay vì nghĩ về điều không làm được (Focus On What You Will Do, Not What You Won’t Do)

Nghiên cứu chỉ ra rằng chúng ta luôn có xu hướng làm những điều bị cấm đoán. Vì thế, thay vì phớt lờ suy nghĩ muốn làm A, hoặc thúc đẩy bản thân đừng làm A, hãy nghĩ theo hướng “Nên làm B để thay thế A” (What will I do instead?)

Hãy cố gắng hạn chế suy nghĩ “KHÔNG ĐƯỢC…” – “không được ăn đồ ngọt”, “không được đi ngủ muộn”, và tìm cho mình những hành động thay thế phù hợp –“nên ăn trái cây nhiều”, “nên đi ngủ ngay sau khi skin care mỗi tối”.

Tóm lại, kết hợp 2 chiến lược trên thì các bước đơn giản có thể giúp thay đổi thói quen chính là:

• Bước 1: Thay vì đặt ra mục tiêu “dừng làm điều gì đó”, thì hãy tập trung nghĩ về điều thay thế “mình sẽ làm điều gì khác”.

• Bước 2: Sử dụng mệnh đề Nếu-Thì (If-then) ghi ra cụ thể lúc nào mình cần làm gì và làm ở đâu.

Ví dụ:
▪　Khi muốn ăn uống healthy ^^
Thay vì “Không được phép ăn đồ ngọt”, “Không được ăn vặt” thì sẽ nghĩ là:
 “Nếu như mình cảm thấy thèm đồ ngọt thì mình sẽ mở tủ lạnh lấy trái cây ra ăn”.

“Nếu như cảm thấy “buồn miệng” thì mình sẽ ăn sữa chua cùng các loại hạt Granola”

▪ Khi muốn tập ngủ sớm dậy sớm “lành mạnh”　

 Thay thế “Không được xem youtube trước khi ngủ” bằng:

“Nếu như muốn xem hoặc nghe gì đó trước khi ngủ thì mình sẽ bật podcast và úp mặt điện thoại xuống dưới”

“Nếu như đã 11h rồi mà vẫn còn chưa muốn ngủ thì mình sẽ bật nhạc nhẹ và đọc một vài trang sách (gây buồn ngủ)” :)))

Mọi người thường nói rằng Tôi đã quen làm “abc” thì rất khó để thay đổi thành “xyz”. 

Đúng là “nói thì dễ hơn làm”, tuy nhiên việc thay đổi không nhất thiết phải mất thời gian dài, nếu bạn đang có “bad habits” muốn sửa đổi mà chưa thực hiện được, có thể thử 2 bước trên xem sao. Mình nghĩ là dù có thành công với mục tiêu đã đặt ra hay không thì hình ảnh bản thân mỗi ngày đều nỗ lực để trở thành phiên bản tốt hơn đã rất đẹp rồi.

Fighting!

The post Thay đổi thói quen appeared first on Tomoshare.

Hoặc có người bạn thân thất tình rủ đi cà phê chiều cuối tuần. Cùng lúc hội nhóm nào khác có buổi tiệc tối họp mặt cần tham gia. Bỏ cái nào cũng ngại, bỏ bên nhóm thì sợ người ta sau này không rủ mình nữa, nên bạn nhận lời hết. Kết quả ngồi cà phê với bạn thân cứ loay hoay nhắn tin với hội nhóm về bữa tiệc. Bạn thân vẫn còn buồn sầu muốn đi ăn để tâm sự tiếp thì mình lại phải về để đi tiếp “kèo” sau.

Chúng ta có xu hướng đồng ý làm nhiều việc, cố gắng làm hài lòng tất cả mọi người. Cuối cùng lại áy náy vì đã không thể làm tốt nhất có thể để đối phương hài lòng. Đó là lý do mà Từ Chối là một kỹ năng cần thiết và tôi nghĩ sẽ cần rất nhiều dũng khí để thực hiện.

Đôi khi chúng ta ngại từ chối vì sợ sẽ làm mất một mối quan hệ xã hội, hoặc sợ đánh mất cơ hội. Nhưng thật ra điều đó chưa chắc đúng. Nhìn kỹ lại hai ví dụ trên, trong công việc càng ôm đồm nhiều việc thì càng khó thực hiện tốt được hết tất cả, dẫn đến có thể làm giảm chất lượng output. Trong khi chỉ cần mình giữ vững giá trị và uy tín thì kể cả có bỏ qua cơ hội này, cơ hội khác vẫn sẽ đến.

Còn trong cuộc sống, có thể mình lựa chọn bạn thân (hoặc hội nhóm) trước tùy vào mức độ quan trọng của sự kiện. Có thể bên còn lại sẽ thất vọng xíu, nhưng mình trình bày lý do và có thể sắp xếp lại vào một buổi khác, thì thiết nghĩ cũng không ai trách thêm. Và chúng ta sẽ được tập trung hơn, khoảng thời gian dành ra cho sự lựa chọn đó cũng được trọn vẹn.

Lời nói “Không” của chúng ta sẽ phải đối mặt với rất nhiều thách thức. Quan trọng nhất là bạn biết điều gì là quan trọng ở hiện tại để có thể từ chối những điều ít có ý nghĩa với bản thân, hoặc những điều mình không có tự tin sẽ làm tốt.

Còn nếu bạn là người bị từ chối. Đừng quạo, hít thở sâu và lắng nghe lý do của đối phương. Biết đâu đấy, bạn sẽ bị họ thuyết phục:))) Đùa thôi, có thể họ say NO là vì cảm thấy hiện tại nếu nhận lời thì sẽ không thể nào toàn tâm toàn ý tham gia được, và họ muốn đảm bảo sự tập trung và chất lượng cho những sự lựa chọn của mình. Hãy hiểu và chờ đợi thời điểm thích hợp hơn.

Bài viết không đưa ra phương pháp hay tips để từ chối, vì tôi nghĩ mỗi người đều có cách riêng phù hợp với phong cách giao tiếp cá nhân và dẫu sao chính bạn mới là người biết đâu là cách tốt nhất trong tình huống của bạn. Anw, dù là người từ chối hay người bị từ chối, thì cũng đều rất cần bản lĩnh để thuyết phục đối phương/tiếp nhận từ chối.

Mạnh mẽ lên, Fighting!

The post Sức mạnh của sự từ chối appeared first on Tomoshare.

Chúng cũng giúp dễ dàng tạo mã có thể đọc và kiểm tra được mà chúng ta có thể cùng nhau làm việc ở mọi nơi và mọi lúc cũng như giúp bạn biết cách viết mã tốt nhất

SOLID là từ viết tắt đại diện cho năm nguyên tắc thiết kế của thiết kế lớp Hướng đối tượng. Những nguyên tắc này là:

• S – Single-responsibility Principle
• O – Open-closed Principle
• L – Liskov Substitution Principle
• I – Interface Segregation Principle
• D – Dependency Inversion Principle

Mỗi nguyên tắc đóng vai trò là kim chỉ nam để thúc đẩy các phương pháp thiết kế tốt và giúp đảm bảo rằng mã có thể mở rộng, bảo trì và dễ hiểu. Trong bài viết này, chúng ta sẽ khám phá sâu từng nguyên tắc SOLID và cách chúng có thể được áp dụng cho Laravel.

Single-responsibility Principle

Nguyên tắc trách nhiệm duy nhất, hay SRP, tuyên bố rằng một lớp chỉ có một lý do để thay đổi. Nói cách khác, một lớp chỉ nên có một trách nhiệm và tập trung làm tốt một việc. Nguyên tắc này giúp giảm độ phức tạp của mã và giúp bảo trì dễ dàng hơn.

Trong Laravel, SRP có thể được áp dụng bằng cách tạo các lớp nhỏ hơn, tập trung hơn để xử lý các tác vụ cụ thể. Ví dụ, thay vì có một lớp duy nhất xử lý đăng ký và đăng nhập của người dùng, sẽ tốt hơn nếu có các lớp riêng biệt để làm từng việc này.

class User
{
	public function register($data) {
    // Register user logic
  }

  public function login($data) {
    // Login logic
  }
}

Thay vào đó, mỗi lớp sẽ có một nhiệm vụ riêng biệt.

class UserRegistration {
  public function register($data) {
    // Register user logic
  }
}

class UserLogin {
  public function login($data) {
    // Login logic
  }
}

Open/Closed Principle (OCP)

Nguyên tắc đóng mở có thể gây nhầm lẫn vì nó là nguyên tắc hai chiều. Theo định nghĩa của Bertrand Meyer trên Wikipedia, nguyên tắc đóng mở (OCP) nói rằng các thực thể phần mềm (lớp, mô-đun, chức năng, v.v.) phải mở để mở rộng nhưng đóng để sửa đổi.

Định nghĩa này có thể gây nhầm lẫn, nhưng một ví dụ và sự làm rõ thêm sẽ giúp bạn hiểu rõ hơn.

Có hai thuộc tính chính trong OCP:

• Nó có thể open – Điều này có nghĩa là bạn có thể mở rộng những gì mô-đun có thể thực hiện.

• Nó closed để sửa đổi — Điều này có nghĩa là bạn không thể thay đổi mã nguồn, mặc dù bạn có thể mở rộng hoạt động của một mô-đun hoặc thực thể.

OCP có nghĩa là một lớp, mô-đun, hàm và các thực thể khác có thể mở rộng hành vi của chúng mà không cần sửa đổi mã nguồn. Nói cách khác, một thực thể có thể được mở rộng mà không cần sửa đổi chính thực thể đó.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách sử dụng các interface và các abstract class. Bằng cách xác định interface cho một tác vụ cụ thể, có thể tạo ra nhiều triển khai thực hiện tác vụ đó, mỗi tác vụ có chức năng riêng.

class PaymentMethod {
  public function processPayment($amount) {
    // Payment processing logic
  }
}

Thay vào đó:

interface PaymentMethodInterface {
  public function processPayment($amount);
}

Chúng ta có thể implement để sử dụng và không ảnh hưởng gì đến mã nguồn:

class CreditCardPayment implements PaymentMethodInterface {
  public function processPayment($amount) {
    // Credit card payment processing logic
  }
}

class BankTransferPayment implements PaymentMethodInterface {
  public function processPayment($amount) {
    // Bank transfer payment processing logic
  }
}

Liskov Substitution Principle (LSP)

LSP tuyên bố rằng các đối tượng của siêu lớp có thể được thay thế bằng các đối tượng của lớp con mà không ảnh hưởng đến tính chính xác của chương trình. Nói cách khác, một lớp con phải thay thế cho lớp cha của nó.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách sử dụng tính kế thừa và đa hình. Bằng cách tạo một lớp cơ sở xác định chức năng chung cho một tập hợp các lớp, có thể tạo các lớp con kế thừa từ lớp cơ sở và thêm chức năng độc đáo của riêng chúng.

Một ví dụ rất phổ biến là kịch bản hình chữ nhật, hình vuông. Rõ ràng là tất cả các hình vuông đều là hình chữ nhật vì chúng là tứ giác có bốn góc đều là góc vuông. Nhưng không phải hình chữ nhật nào cũng là hình vuông. Để là hình vuông thì các cạnh của nó phải có cùng độ dài.

Hãy ghi nhớ điều này, giả sử bạn có một lớp hình chữ nhật để tính diện tích hình chữ nhật và thực hiện các thao tác khác như set màu sắc cho nó

class Rectangle {
    public function setWidth($width)
		{
        $this->width = $width;
    }

    public function setHeight($height) 
		{
				$this->height = $height;
    }

    public function setColor($color)
		{
				// set color processing logic
    }

    public function getArea() 
		{
        return $this->width * $this->height;
    }
}

Biết rõ rằng tất cả các hình vuông đều là hình chữ nhật, bạn có thể kế thừa các đặc tính của hình chữ nhật. Vì chiều rộng và chiều cao phải giống nhau nên bạn có thể điều chỉnh nó:

class Square extends Rectangle {
    public function setWidth($width)
		{
        $this->width = $width;
        $this->height = $width;
    }
		public function setHeight($height)
		{
        $this->width = $height;
        $this->height = $height;
    }
}

Nhìn vào ví dụ, nó sẽ hoạt động bình thường:

$rectangle = new Rectangle();
$rectangle->setWidth(10);
$rectangle->setHeight(5);
$area = $rectangle->getArea());
echo $area; // 50

Ở phần trên, bạn sẽ nhận thấy rằng một hình chữ nhật được tạo và chiều rộng và chiều cao được đặt. Sau đó, bạn có thể tính toán diện tích chính xác.

Nhưng theo LSP, bạn muốn các đối tượng của lớp con của bạn hoạt động giống như các đối tượng của lớp cha của bạn. Có nghĩa là nếu bạn thay thế Hình chữ nhật bằng Hình vuông, mọi thứ vẫn hoạt động tốt:

$square = new Square();
$square->setWidth(10);
$square->setHeight(5);

Bạn sẽ nhận được 100, vì setWidth(10) được cho là đặt cả chiều rộng và chiều cao thành 10. Nhưng vì setHeight(5), giá trị này sẽ trả về 25.

$square = new Square();
$square->setWidth(10);
$square->setHeight(5);
$area = $square->getArea());
echo $area; // 25

Điều này phá vỡ LSP. Đối tượng hình vuông lớp con không thể thay thế đối tượng hình chữ nhật siêu lớp để tính diện tích. Để khắc phục điều này, cần có một lớp chung cho tất cả các hình dạng sẽ chứa tất cả các phương thức chung mà bạn muốn các đối tượng của lớp con của mình có quyền truy cập. Sau đó, đối với các phương thức riêng lẻ, bạn tạo một lớp riêng cho hình chữ nhật và hình vuông

class Shape {
    public function setColor($color)
		{
        $this->color = $color;
    }
    public function getColor()
		{
        return $this->color;
    }
}

class Rectangle extends Shape {
    public function setWidth($width)
		{
        $this->width = $width;
    }
    public function setHeight($height) {
        $this->height = $height;
    }
    public function getArea() {
        return $this->width * $this->height;
    }
}

class Square extends Shape {
    public function setSide($side) {
        $this->side = $side;
    }
    public function getArea() {
        return $this->side * $this->side;
    }
}

Bằng cách này, bạn có thể đặt màu và lấy màu bằng cách sử dụng siêu lớp hoặc lớp con:

// superclass
$shape = new Shape();
$shape->setColor('red');
$color = $shape->getColor());
echo $color; // red

// subclass
$rectangle = new Rectangle();
$rectangle->setColor('green');
$rectangleColor = $rectangle->getColor());
echo $rectangleColor; // green

// subclass
$square = new Square();
$square->setColor('blue');
$squareColor = $square->getColor());
echo $squareColor; // blue

Interface Segregation Principle (ISP)

ISP tuyên bố rằng các lớp không nên bị buộc phải triển khai các giao diện mà chúng không sử dụng. Nguyên tắc này giúp giảm độ phức tạp của mã và giúp bảo trì dễ dàng hơn.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách tạo các giao diện nhỏ hơn, tập trung hơn để xác định các nhiệm vụ cụ thể.

Ví dụ: giả sử bạn có một giao diện xác định các phương thức để vẽ các hình dạng cụ thể.

interface ShapeInterface {
    public function calculateArea();
    public function calculateVolume();
}

Khi bất kỳ lớp nào triển khai giao diện này, tất cả các phương thức phải được xác định ngay cả khi bạn không sử dụng chúng hoặc nếu chúng không áp dụng cho lớp đó.

class Square implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }  
}

class Cuboid implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }    
}

class Rectangle implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }   
}

Nhận thấy rằng chúng ta không thể tính thể tích của hình vuông hoặc hình chữ nhật. Vì lớp này triển khai giao diện nên bạn cần xác định tất cả các phương thức, ngay cả những phương thức bạn không sử dụng hoặc không cần.

Thay vào đó, ta nên tách nhỏ interface ra:

interface ShapeInterface {
    public function calculateArea();
}

interface ThreeDimensionalShapeInterface {
    public function calculateArea();
    public function calculateVolume();
}

Bây giờ bạn có thể triển khai giao diện cụ thể hoạt động với từng lớp.

class Square implements ShapeInterface {
    public function calculateArea()
		{
        //...
    } 
}

class Cuboid implements ThreeDimensionalShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }    
}

class Rectangle implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }  
}

Dependency Inversion Principle (DIP)

DIP nêu rõ rằng các mô-đun cấp cao không nên phụ thuộc vào các mô-đun cấp thấp, mà cả hai đều phải phụ thuộc vào sự trừu tượng hóa. Nguyên tắc này giúp giảm sự ghép nối giữa các mô-đun và giúp việc duy trì và mở rộng mã dễ dàng hơn.

Theo Wikipedia, nguyên tắc này nêu rõ rằng:

• Các mô-đun cấp cao không được nhập bất cứ thứ gì từ các mô-đun cấp thấp. Cả hai nên phụ thuộc vào sự trừu tượng (ví dụ: giao diện).
• Sự trừu tượng phải độc lập với các chi tiết. Chi tiết (triển khai cụ thể) sẽ phụ thuộc vào sự trừu tượng.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách sử dụng dependency injection. Bằng cách xác định các phần phụ thuộc dưới dạng trừu tượng thay vì triển khai cụ thể, có thể thay đổi cách triển khai phần phụ thuộc mà không ảnh hưởng đến mã phụ thuộc vào nó.

Thay vì ta triển khai cụ thể:

class UserController {
  public function showProfile(int|string $id) {
    $userRepository = new UserRepository;
    $user = $userRepository->getUser($id);

    return view('user.profile', ['user' => $user]);
  }
}

Thì ta có thể xác định phần phụ thuộc dưới dạng trừu tượng:

class UserController {
  protected $userRepository;

  public function __construct(UserRepositoryInterface $userRepository) {
    $this->userRepository = $userRepository;
  }

  public function showProfile(int|string $id) {
    $user = $this->userRepository->getUser($id);

    return view('user.profile', ['user' => $user]);
  }
}

Advantages of SOLID

Sử dụng các nguyên tắc SOLID trong phát triển phần mềm có một số lợi ích:

• Tăng khả năng bảo trì: Các nguyên tắc SOLID giúp tạo mã dễ bảo trì và sửa đổi hơn theo thời gian. Khi mỗi lớp hoặc mô-đun có một trách nhiệm duy nhất và tuân theo Nguyên tắc Mở/Đóng, các thay đổi có thể được thực hiện mà không ảnh hưởng đến các phần khác của mã.
• Tăng khả năng kiểm tra: Nguyên tắc SOLID cũng giúp kiểm tra mã dễ dàng hơn. Mã tuân theo Nguyên tắc trách nhiệm duy nhất thường dễ kiểm tra hơn vì có ít sự phụ thuộc hơn và ít tác dụng phụ có thể xảy ra hơn.
• Tăng tính linh hoạt: Bằng cách tuân thủ Nguyên tắc Mở/Đóng, bạn có thể tạo mã linh hoạt và có khả năng mở rộng hơn. Khi cần thêm chức năng mới, bạn có thể làm như vậy bằng cách thêm các lớp hoặc giao diện mới thay vì sửa đổi mã hiện có.
• Tổ chức mã tốt hơn: Bằng cách tuân theo các nguyên tắc SOLID, bạn có thể tổ chức mã của mình tốt hơn và làm cho các nhà phát triển khác dễ hiểu hơn. Mã được tổ chức tốt và tuân theo các mẫu thiết kế rõ ràng sẽ dễ bảo trì và mở rộng hơn.

Conclusion

SOLID là một tập hợp các nguyên tắc thiết kế giúp thúc đẩy các phương pháp thiết kế tốt và đảm bảo rằng mã có thể mở rộng, bảo trì và dễ hiểu. Bằng cách áp dụng những nguyên tắc này trong Laravel, các nhà phát triển có thể tạo mã mạnh mẽ, có thể bảo trì và dễ mở rộng quy mô.

Cảm ơn mọi người đã dành thời gian để đọc 🙏

The post SOLID Principles appeared first on Tomoshare.