HDMI version(s)

HDMI Forum

HDMI 2.0

  • Độ phân giải mở rộng: Mở rộng khả năng tương thích độ phân giải 4K (2160 px) của HDMI 1.4/1.4a để chấp nhận tốc độ khung hình 50 hoặc 60 hertz (tốc độ truyền tối đa 18Gbps với 8 bit màu).
  • Hỗ trợ định dạng âm thanh mở rộng: Có thể chấp nhận lên đến 32 kênh đồng thời, hỗ trợ các định dạng âm thanh vòm sống động, chẳng hạn như âm thanh Dolby AtmosDTS:X và Auro 3D.
  • Luồng video kép: Có thể gửi hai luồng video độc lập để xem trên cùng một màn hình.
  • 4 luồng âm thanh: Có thể gửi tối đa 4 luồng âm thanh riêng biệt cho nhiều người nghe.
  • Hỗ trợ tỷ lệ khung hình 21:9 (2,35:1).
  • Đồng bộ động các luồng video và âm thanh.
  • Mở rộng khả năng HDMI-CEC.
  • Nâng cao khả năng chống sao chép HDCP được gọi là HDCP 2.2.

Gatekeep server with Syslog-NG

Em gatekeep được hiểu như gác cổng của toàn bộ thiết bị sau đó, do đó nó cũng phải monitoring mọi thứ. Syslog-NG là một trong những services cần thiết

  • Router sẽ bắn syslog về
  • Core Switch cũng sẽ bắn syslog về
  • Cuối cùng là các AP cũng vậy
  • …. và bất kì thiết bị nào khác cũng sẽ tương tự

Sự khác biệt giữa syslog / syslog-ng & rsyslog

https://serverfault.com/questions/692309/what-is-the-difference-between-syslog-rsyslog-and-syslog-ng

Đầu tiên là phải enable UDP port 514 để nhận syslog từ ngoài vào. Mấy món này sẽ easily hơn với Webmin UI.

Vậy là SyslogNG đã ready. Tuy nhiên cần lưu ý kiểm port 514 UDP đã được enable ( most of case thì Webmin sẽ install luôn firewall và tất nhiên port này không được enabled )

Tuy nhiên log là thứ … write liên tục. Do đó giảm thiểu cái nào được ra khỏi SSD thì tốt bấy nhiêu.

  • Log sources : Các nguồn cung cấp logs . Ở đây mình đã thêm s_net
  • Log destination : Store logs vào đâu
  • Log filter : Lọc các logs
  • Và cuối cùng là kết hợp mọi thứ để tạo log : Log từ source nào – Filter thế nào & Save vào đâu

[Part 1] Ubuntu server for web hosting

Bài đầu tiên trong series là Setup 1 con Ubuntu server.

Mình có 1 con HP EliteDesk 800 G2 với

  • i5-6400
  • 32GB RAM – 2666Mhz
  • SSD NVme Gen3 x4 : 256GB
  • SSD Sata : 120GB

OS

Read more: [Part 1] Ubuntu server for web hosting

Oki sau khi installed OS xong. Ta có 1 vài thứ cơ bản

Update /etc/sudoers và thêm vào cuối file

$USER ALL=(ALL) NOPASSWD:ALL
  • Update LVM 100% Storage
  • Update NTP & Timezone
curl -L https://raw.githubusercontent.com/jooservices/bash/main/services/vm | bash

Oki để hosting ta sẽ dùng Virtualmin.

Virtualmin is the leading and most sophisticated web hosting control panel designed for Linux systems.

Virtualmin

By default Virtualmin không có đủ hết các PHP versions do đó ta sẽ install thêm

curl -L https://raw.githubusercontent.com/jooservices/bash/main/services/multi-php.sh | bash

Cơ bản 1 con web hosting như vậy là đủ. Một số packages bổ sung tùy chọn

By default Webmin / Virtualmin sẽ enable firewall. Do đó nếu cần access từ ngoài vào với các 3rd party services / ports thì cần update rules

Live site : https://selfhosted.jooservices.com

Để setup domain / Cloudflare trỏ về Virtualmin ta sẽ dùng HAProxy ở bài sau

Laravel – Code structure with UnitTest

Giả sử ta có một code structure như sau

Controller

  • Gọi Services để thực thi và respond

Services

  • Gọi Repository khi cần tương tác database
  • Trigger Event
  • Gọi các Services khác hoặc các code logic khác.

Vậy UnitTest sẽ cần những gì. Trong quan điểm mình là đi từ thấp nhất lên cao nhất

  • Repositories : Đảm bảo database được thực thi, assert các data như mong đợi.
    • Assert events đã dispatched.
    • Events : Dispatch events và assert data như mong đợi
  • Services
    • Nếu services có các events ẢNH HƯỞNG TRỰC TIẾP đến kết quả thì mình sẽ không fake event mà để event thực thi và assert kết quả
    • Nếu các events đó dùng cho 3rd thì mình assert để make sure events dispatched như mong đợi

Tất nhiên nếu service đó thuần túy gọi tới 3rd party thì mình chỉ việc mock và test respond từ 3rd party thôi.

Và sau cùng là assert controller trả về data như mong đợi

Template Method

Template Method là một design pattern trong đó một khuôn mẫu được định nghĩa, chứa một số bước cơ bản của một thuật toán, trong khi các bước cụ thể được định nghĩa bởi các lớp con. Khuôn mẫu này đảm bảo rằng các bước cơ bản của thuật toán được thực hiện theo cùng một cách, nhưng cách thức cụ thể của từng bước có thể được thay đổi bởi các lớp con.

abstract class Report {
    public function generate() {
        $this->setData();
        $this->formatData();
        $this->generateOutput();
    }
    
    abstract protected function setData();
    
    protected function formatData() {
        // default implementation
    }
    
    abstract protected function generateOutput();
}

class PdfReport extends Report {
    protected function setData() {
        // set data for pdf report
    }
    
    protected function generateOutput() {
        // generate pdf output
    }
}

class ExcelReport extends Report {
    protected function setData() {
        // set data for excel report
    }
    
    protected function generateOutput() {
        // generate excel output
    }
}

Trong đoạn code này, Report là một abstract class định nghĩa khuôn mẫu cho việc tạo ra báo cáo. Phương thức generate() định nghĩa các bước cơ bản trong việc tạo ra báo cáo, bao gồm setData(), formatData()generateOutput(). Trong đó, setData()generateOutput() là các phương thức trừu tượng và phải được định nghĩa bởi các lớp con. Trong khi đó, formatData() có một implementation mặc định, nhưng có thể được ghi đè bởi các lớp con nếu cần thiết.

Các lớp con, như PdfReportExcelReport, kế thừa từ Report và định nghĩa các phương thức trừu tượng để thực hiện các bước cụ thể trong việc tạo ra báo cáo. Ví dụ, PdfReport định nghĩa setData() để thiết lập dữ liệu cho báo cáo PDF, và generateOutput() để tạo ra đầu ra PDF. Tương tự, ExcelReport định nghĩa setData()generateOutput() để tạo ra báo cáo Excel.

Khi chúng ta muốn tạo ra một báo cáo, chúng ta có thể tạo một đối tượng của lớp con và gọi phương thức generate(). Phương thức này sẽ thực hiện các bước cơ bản của thuật toán và gọi các phương thức cụ thể của lớp con để thực hiện các bước cụ

SOLID

SOLID là một nguyên tắc lập trình hướng đối tượng được đặt tên theo chữ cái đầu của các từ trong các nguyên tắc này: Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), và Dependency Inversion Principle (DIP).

Các nguyên tắc SOLID đề cao việc thiết kế các lớp và đối tượng trong hệ thống phần mềm, nhằm tăng tính linh hoạt, dễ bảo trì, mở rộng và tái sử dụng của hệ thống.

Dưới đây là một số định nghĩa cho từng nguyên tắc SOLID:

  1. Single Responsibility Principle (SRP): Một lớp nên chỉ có một trách nhiệm duy nhất và không nên bị phân tán với nhiều trách nhiệm khác.
  2. Open/Closed Principle (OCP): Một lớp nên được thiết kế để dễ dàng mở rộng mà không cần sửa đổi mã nguồn hiện tại.
  3. Liskov Substitution Principle (LSP): Các lớp con phải có thể thay thế được cho các lớp cha của chúng mà không làm thay đổi tính năng của hệ thống.
  4. Interface Segregation Principle (ISP): Các giao diện nên được thiết kế theo những chức năng cụ thể và không nên yêu cầu các phương thức không cần thiết.
  5. Dependency Inversion Principle (DIP): Mã nguồn nên phụ thuộc vào các giao diện và không phải các lớp cụ thể, để tạo tính linh hoạt và dễ bảo trì.

1 chút mở rộng với Interface Segregation Principle

interface PaymentGatewayInterface {
    public function processPayment(float $amount, string $paymentMethod): bool;
    public function refundPayment(float $amount, string $paymentMethod): bool;
    public function savePaymentInfo(array $paymentInfo): bool;
}

Trong ví dụ này, PaymentGatewayInterface định nghĩa các phương thức không cần thiết như refundPayment() và savePaymentInfo(). Nếu PaymentGateway không sử dụng chúng, nó vẫn phải triển khai các phương thức này và sẽ phụ thuộc vào chúng. Việc này có thể dẫn đến các vấn đề về độ phức tạp và hiệu suất của ứng dụng, đồng thời cũng làm cho việc thay đổi PaymentGateway khó khăn hơn nếu chúng ta muốn loại bỏ các phương thức không cần thi

Còn đối với Dependency Inversion Principle (DIP) là một trong những nguyên tắc trong SOLID và nhấn mạnh rằng “Các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hai nên phụ thuộc vào abstraction”. Nguyên tắc này khuyến khích chúng ta thiết kế các module để chúng phụ thuộc vào abstraction chung hơn là phụ thuộc vào các chi tiết cụ thể.

DIP có thể được áp dụng bằng cách sử dụng các design pattern như Dependency Injection (DI), Inversion of Control (IoC) và Service Locator.

Ví dụ, giả sử bạn đang phát triển một ứng dụng quản lý đơn hàng. Trong ứng dụng của bạn, bạn có một lớp OrderService để xử lý các thao tác liên quan đến đơn hàng, ví dụ như tạo đơn hàng, cập nhật đơn hàng, hoàn tất đơn hàng, v.v.

Trong trường hợp này, nếu OrderService phụ thuộc vào các lớp cấp thấp như OrderRepository, ProductRepository và CustomerRepository, nó sẽ phải biết chi tiết cụ thể của các lớp này, gây ra sự phụ thuộc chặt chẽ và làm cho việc bảo trì, mở rộng và thay đổi khó khăn hơn.

Thay vào đó, nếu chúng ta áp dụng DIP, chúng ta sẽ tạo ra các abstraction (interface hoặc abstract class) để mô tả các chức năng của các lớp cấp thấp như OrderRepository, ProductRepository và CustomerRepository. Sau đó, chúng ta sẽ thiết kế OrderService để phụ thuộc vào các abstraction này thay vì các lớp cụ thể. Ví dụ:

interface OrderRepositoryInterface {
    public function createOrder(array $orderData): int;
    public function updateOrder(int $orderId, array $orderData): bool;
    public function completeOrder(int $orderId): bool;
}

interface ProductRepositoryInterface {
    public function getProductById(int $productId): array;
}

interface CustomerRepositoryInterface {
    public function getCustomerById(int $customerId): array;
}

class OrderService {
    private $orderRepository;
    private $productRepository;
    private $customerRepository;

    public function __construct(OrderRepositoryInterface $orderRepository, ProductRepositoryInterface $productRepository, CustomerRepositoryInterface $customerRepository) {
        $this->orderRepository = $orderRepository;
        $this->productRepository = $productRepository;
        $this->customerRepository = $customerRepository;
    }

    public function createOrder(array $orderData): int {
        // Use the injected order repository to create the order
        $orderId = $this->orderRepository->createOrder($orderData);

        // Use the injected product repository to get the product information
        $product = $this->productRepository->getProductById($orderData['product_id']);

        // Use the injected customer repository to get the customer information
        $customer = $this->customerRepository->getCustomer

Facade vs Helper trong Laravel

Facade

  • Là một tập hợp các static methods cung cấp cách gọi dễ dàng đến các đối tượng không phải là tĩnh (như các class của Service Container).
  • Facade cung cấp một cách tiếp cận rất thuận tiện cho các đối tượng Laravel, vì nó cho phép bạn gọi các phương thức như bạn đang gọi tới một static methods, mặc dù thực tế là các phương thức được đóng gói trong Service Container.
  • Ví dụ, khi bạn gọi phương thức DB::table('table_name')->get(), thực tế bạn đang gọi đến phương thức get() của đối tượng DB, được quản lý bởi Service Container.

Helper

  • Là một tập hợp các hàm toàn cục (global) được định nghĩa để thực hiện các tác vụ phổ biến, và được sử dụng trong toàn bộ ứng dụng Laravel.
  • Helper không liên quan đến Service Container, và không cung cấp các phương thức cho các đối tượng không phải là tĩnh.
  • Ví dụ, route() là một helper để tạo URL của một route được định nghĩa trong ứng dụng Laravel.

Bất cập của Facade

Giả sử bạn có một ứng dụng Laravel đơn giản, nơi bạn cần thực hiện một số thao tác với đối tượng Request của Laravel. Bạn muốn lấy giá trị của một tham số trong URL và hiển thị nó trên trang web.

Một cách để thực hiện điều này là sử dụng Facade của Laravel, đó là Illuminate\Support\Facades\Request. Bằng cách sử dụng Facade này, bạn có thể lấy giá trị của một tham số bằng cách gọi phương thức input() trên Facade, như sau:

$value = Request::input('parameter');

Tuy nhiên, điều gì sẽ xảy ra nếu Request không được đăng ký trong Service Container của Laravel hoặc không có đối tượng Request nào được trả về từ Service Container? Trong trường hợp này, việc gọi Request::input('parameter') sẽ dẫn đến lỗi runtime, vì Facade không thể truy cập đối tượng Request và sử dụng phương thức input().

Điều này có thể xảy ra nếu bạn đang thực hiện một chức năng đơn giản như hiển thị trang web, nhưng vấn đề sẽ trở nên nghiêm trọng hơn nếu bạn đang phát triển một ứng dụng lớn hơn với nhiều phương thức và đối tượng phức tạp. Việc sử dụng quá nhiều Facade trong trường hợp này có thể dẫn đến mã khó bảo trì và khó hiểu, đặc biệt là khi bạn phải theo dõi nhiều phương thức và đối tượng phức tạp.