1. Vấn đề: Sự cồng kềnh của những câu Query thuần

Thông thường, khi cần tìm kiếm một từ khóa trên nhiều cột (ví dụ: name, email, address), chúng ta thường viết như sau:

$searchTerm = $request->input('q');

$users = User::where('name', 'LIKE', "%{$searchTerm}%")
             ->orWhere('email', 'LIKE', "%{$searchTerm}%")
             ->orWhere('address', 'LIKE', "%{$searchTerm}%")
             ->get();

Những rủi ro tiềm ẩn:

1. Lỗi logic AND/OR: Nếu bạn thêm một điều kiện where('status', 'active') vào sau cụm trên, SQL sẽ hiểu nhầm ý định của bạn. Thay vì tìm (A hoặc B hoặc C) VÀ phải Active, nó sẽ hiểu là (A) hoặc (B) hoặc (C và Active). Điều này dẫn đến kết quả tìm kiếm sai lệch hoàn toàn.
2. Vi phạm nguyên tắc DRY (Don’t Repeat Yourself): Nếu Model Post, Product, hay Order cũng cần tìm kiếm tương tự, bạn sẽ phải copy-paste đoạn code đó. Khi cần đổi LIKE thành Full-text search, bạn phải đi sửa ở… 20 file khác nhau.
3. Khó đọc: Controller của bạn sẽ bị lấp đầy bởi những chi tiết triển khai (implementation details) thay vì tập trung vào luồng nghiệp vụ chính.

2. Giải pháp: Tại sao không dùng Scope mà lại dùng Macro?

Nhiều người sẽ nghĩ đến Local Scope. Tuy nhiên, Scope có một giới hạn về kiến trúc:

• Scope: Được khai báo bên trong Model. Nó mang tính chất nghiệp vụ. Ví dụ: Order::isPaid() là logic chỉ dành cho Đơn hàng.
• Macro: Được khai báo toàn cục (Global). Nó mang tính chất tiện ích. Một hàm như whereLike() (tìm kiếm gần đúng) là nhu cầu chung của mọi bảng trong cơ sở dữ liệu.

Thay vì ép mọi Model phải kế thừa một Trait hoặc viết Scope riêng, chúng ta sử dụng Macro để “bơm” trực tiếp phương thức này vào Query Builder của Laravel.

3. Triển khai chi tiết Macro whereLike (Hỗ trợ cả Relationship)

Chúng ta sẽ tạo một MacroServiceProvider để quản lý. Macro này không chỉ giải quyết bài toán tìm kiếm cơ bản mà còn xử lý được cả các bảng liên quan (Relation) bằng dấu chấm (.).

namespace App\Providers;

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Support\Arr;
use Illuminate\Support\ServiceProvider;

class MacroServiceProvider extends ServiceProvider
{
    public function boot()
    {
        /**
         * Macro tìm kiếm đa cột và đa bảng
         * @param string|array $attributes Danh sách cột cần tìm (VD: 'name' hoặc ['name', 'category.title'])
         * @param string $searchTerm Từ khóa tìm kiếm
         */
        Builder::macro('whereLike', function ($attributes, string $searchTerm) {
            // Bao bọc toàn bộ logic trong một closure where() để cô lập điều kiện OR
            // Điều này tạo ra SQL dạng: WHERE ... AND (column1 LIKE %?% OR column2 LIKE %?%)
            this->where(function (Builder $query) use ($attributes, $searchTerm) {
                foreach (Arr::wrap($attributes) as $attribute) {
                    $query->orWhere(function (Builder $query) use ($attribute, $searchTerm) {
                        
                        // Kiểm tra nếu attribute có chứa dấu chấm (Tìm kiếm trên quan hệ)
                        if (str_contains($attribute, '.')) {
                            [$relationName, $relationAttribute] = explode('.', $attribute);

                            // Sử dụng orWhereHas để truy vấn sang bảng liên quan
                            $query->orWhereHas($relationName, function (Builder $query) use ($relationAttribute, $searchTerm) {
                                $query->where($relationAttribute, 'LIKE', "%{$searchTerm}%");
                            });
                        } else {
                            // Tìm kiếm trên bảng hiện tại
                            $query->where($attribute, 'LIKE', "%{$searchTerm}%");
                        }
                    });
                }
            });

            return $this; // Trả về Builder để tiếp tục chaining (ví dụ: ->orderBy())
        });
    }
}

4. Trải nghiệm thực tế sau khi áp dụng

Hãy xem cách code của bạn “lột xác” trong Controller. Giả sử bạn cần tìm kiếm bài viết theo tiêu đề, nội dung và cả tên tác giả (nằm ở bảng Users).

Cách cũ:

$posts = Post::where('title', 'like', "%$q%")
    ->orWhere('content', 'like', "%$q%")
    ->orWhereHas('author', function($query) use ($q) {
        $query->where('name', 'like', "%$q%");
    })
    ->where('is_published', true) // Dễ bị sai logic
    ->get();

Cách mới với Macro (Sạch hơn):

$posts = Post::whereLike(['title', 'content', 'author.name'], $q)
    ->where('is_published', true)
    ->latest()
    ->paginate(15);

Tại sao cách này tối ưu hơn?

• Tính đóng gói: Logic xử lý dấu chấm (relation) hay nhóm ngoặc đơn SQL đã được giấu kín bên trong Macro.
• Tính nhất quán: Mọi lập trình viên trong dự án đều dùng chung một cách gọi hàm, giúp việc bảo trì trở nên cực kỳ dễ dàng.
• Khả năng mở rộng: Nếu sau này bạn muốn đổi sang một bộ máy tìm kiếm khác (như Elasticsearch), bạn chỉ cần thay đổi logic tại một nơi duy nhất: MacroServiceProvider.

5. Mở rộng cho Collection

Không chỉ Query Builder, Collection cũng cực kỳ mạnh mẽ khi kết hợp với Macro. Ví dụ, bạn có một mảng dữ liệu phức tạp và muốn trích xuất nhanh để làm dữ liệu cho dropdown:

use Illuminate\Support\Collection;

Collection::macro('toOptions', function ($label = 'name', $value = 'id') {
    return $this->map(fn($item) => [
        'label' => data_get($item, $label),
        'value' => data_get($item, $value),
    ])->values();
});

// Sử dụng:
$userOptions = User::all()->toOptions('full_name', 'uuid');

Lời kết

Macroable là một “vũ khí bí mật” giúp bạn viết code Laravel một cách tinh tế hơn. Nó biến những thao tác lặp đi lặp lại thành những công cụ mạnh mẽ, giúp codebase của bạn luôn sạch sẽ và dễ hiểu.

Tuy nhiên, có một lưu ý nhỏ: Vì Macro là các phương thức được thêm vào khi chương trình đang chạy, IDE như VS Code hay PHPStorm sẽ không tự nhận diện được để gợi ý code. Bạn nên cài thêm package barryvdh/laravel-ide-helper để hỗ trợ việc viết code mượt mà hơn.

Bạn đã sẵn sàng để “Macro hóa” dự án của mình chưa? Hãy bắt đầu với những logic mà bạn thấy mình đang copy-paste nhiều nhất nhé!

Hy vọng bài viết này giúp ích cho lộ trình phát triển kỹ năng của bạn. Nếu có bất kỳ thắc mắc nào về cách triển khai nâng cao, đừng ngần ngại để lại bình luận!

The post Laravel Macros: Nghệ thuật tái sử dụng code cho Query Builder và Collection appeared first on Tomoshare.

1. Vì sao phải viết Cursor Rule?

1.1. Để AI hiểu đúng cách bạn muốn nó làm việc

Khi không có rule, AI đoán phong cách, chất lượng và mục tiêu theo thói quen chung → dễ sai, mơ hồ, hoặc không phù hợp với dự án.
Rule giúp cố định cách AI hành động, không bị lệch dù prompt thay đổi.

1.2. Để giữ chất lượng đầu ra ổn định

Khi làm team, nhiều người dùng AI cho chung một dự án. Không có rule → mỗi người cho ra một kiểu.
Có rule → kết quả ổn định, “giống một người viết”.

1.3. Để tiết kiệm thời gian

Không phải lặp lại các yêu cầu cố định như coding style, cấu trúc file, cấm/tắt tính năng…
Rule giúp giảm 50–80% thời gian bạn cần để “định hướng” AI.

1.4. Để chống lỗi và giảm rủi ro

AI không tự biết giới hạn của dự án.
Rule giúp chặn:

• Sai kiến trúc
• Viết sai chuẩn coding
• Phát sinh thư mục rác
• Tự ý tạo file không có trong dự án
• Sử dụng công nghệ dự án không hỗ trợ

2. Cấu trúc cần có của một Cursor Rule

2.1. Mục “alwaysApply”: để rule luôn được kích hoạt

alwaysApply: true

Nếu không bật, rule chỉ hoạt động khi bạn chọn thủ công → vô dụng. Bật lên để toàn bộ dự án luôn tuân theo một chuẩn.

2.2. Mục mô tả (description): để ghi rõ mục đích

description: |
  Quy tắc dùng khi làm việc với dự án X.

Đây là phần giúp AI hiểu bối cảnh tổng quát. Nếu không có, AI dễ “đi lạc” sang phong cách khác.

2.3. Danh sách rules (rules[]): để kiểm soát từng hành vi

Một rule có các thành phần cơ bản:

rules:
  - name: "Quy tắc đặt tên file"
    pattern: "*.js"
    description: |
      Tất cả file phải dùng camelCase.
    examples:
      good: ["userService.js"]
      bad: ["User_service.JS"]

Giải thích từng phần:

2.4. Mục cấm / hạn chế (do/dont)

Ví dụ:

intent:
  - "Không tự tạo file mới nếu người dùng không yêu cầu."

AI hay tự sinh file → gây rác → ảnh hưởng cấu trúc dự án → không kiểm soát được.
Rule này khóa hành vi đó.

2.5. Định nghĩa style coding (coding conventions)

  - name: "Code style"
    description: |
      Viết code theo chuẩn PSR-12.

Nếu không chốt style → mỗi lần AI tạo code là mỗi lần thay đổi format → khó review, khó merge.

3. Quy trình viết một Cursor Rule chuẩn

Bước 1 — Xác định mục tiêu dự án

Bạn phải trả lời: “Tôi muốn AI hỗ trợ cái gì?”

Không biết mục tiêu → rule lan man, dài, không hiệu quả → AI rối.

Bước 2 — Ghi rõ giới hạn dự án

Ví dụ:

• PHP version: 7.4
• Framework: Laravel 8
• Không dùng TypeScript
• Không tạo file migration mới

Giới hạn càng rõ → AI càng ít sai.
Không có giới hạn → AI rất hay dùng công nghệ mới, sai version, sai API.

Bước 3 — Xác định những hành vi AI hay sai nhất

Ví dụ:

• Tự sinh file linh tinh
• Viết import sai
• Sử dụng syntax của version mới
• Tạo code không phù hợp folder structure

Đây là những điểm tạo ra rule quan trọng nhất. Tập trung 20% rule để sửa 80% lỗi.

Bước 4 — Viết rule bằng ngôn ngữ đơn giản, không mơ hồ

Ví dụ sai: “Viết code sạch” → AI không hiểu.
Ví dụ đúng: “Không dùng biến một ký tự như i, j, k.”

AI không hiểu từ trừu tượng.
Muốn AI làm đúng → phải mô tả hành vi cụ thể.

Bước 5 — Bổ sung ví dụ tốt/xấu

Đây là phần cực quan trọng nhưng rất nhiều người bỏ qua.

AI học theo ví dụ mạnh hơn theo mô tả.
Chỉ 2–3 ví dụ tốt/xấu đã giúp giảm lỗi 60–70%.

Bước 6 — Test rule bằng một tác vụ thật

Ví dụ: “Tạo controller UserController.”

Rule chỉ có giá trị khi được test trong thực tế.
Không test → rule chỉ là lý thuyết.

4. Mẫu Cursor Rule đơn giản cho người mới

alwaysApply: true

description: |
  Quy tắc hỗ trợ viết mã PHP, Laravel 8 cho dự án cũ.

rules:
  - name: "Không dùng syntax Laravel mới"
    description: |
      Laravel trong dự án là bản 8. Không dùng các API của Laravel 9+.
    examples:
      bad: ["Route::controller(...)"]
      good: ["Route::get(...)", "Route::post(...)"]

  - name: "Không tự tạo file"
    description: |
      Chỉ tạo file khi người dùng yêu cầu.

  - name: "Style code"
    description: |
      Tất cả code phải tuân theo PSR-12.

Kết luận

Viết Cursor Rule không phải để “làm màu”, mà để:

• Giữ AI chạy đúng đường.
• Giảm lỗi.
• Tăng tốc độ phát triển.
• Chuẩn hóa output trong team.
• Tạo ra môi trường làm việc ổn định.

Muốn viết rule tốt → phải hiểu vấn đề, hiểu dự án, và hiểu AI dễ sai ở đâu.

The post Hướng dẫn viết Cursor Rule cho người mới bắt đầu appeared first on Tomoshare.

Đó là lúc tôi buộc phải lôi toàn bộ “đồ nghề” ra: từ metrics, redis-cli, bash script, đến việc ngồi soi từng pattern key một. Và những gì tôi học được trong hành trình đó, tôi muốn chia sẻ lại ở đây — để nếu bạn cũng dùng Redis giống tôi, bạn sẽ tránh được một ngày làm việc dở khóc dở cười.

1. Dấu hiệu ban đầu – khi slack báo động không ngừng

Sự cố được phát hiện qua lỗi sau trên slack:

OOM command not allowed when used memory > 'maxmemory'.
RedisException: OOM command not allowed when used memory > 'maxmemory'. in /var/www/app/vendor/laravel/framework/src/Illuminate/Redis/Connections/PhpRedisConnection.php:405

Nếu bạn đã từng gặp lỗi này, bạn biết nó nguy hiểm cỡ nào:

• Redis từ chối mọi lệnh ghi
• Queue dừng
• Horizon đứng hình
• Laravel không thể push thêm job
• Toàn bộ request liên quan Redis gần như fail đồng loạt

Điều đầu tiên tôi làm là mở AWS ElastiCache lên. Và cảnh tượng trước mắt:

• Memory đã 100%
• Biểu đồ tăng đều, gần như hoàn hảo theo dạng diagonal slope
• Không hề có eviction (vì đang dùng volatile-lru — mặc định của AWS ElastiCache)

Đây là dấu hiệu kinh điển của memory leak trong Redis.

Giờ thì không còn đường lui nữa: phải lội vào trong Redis để xem nó đang chứa cái gì.

2. Bắt đầu điều tra – mò mẫm từng dấu vết trong Redis

Tôi ssh vào ECS container chạy Laravel (Alpine), cài nhanh redis-cli:

apk add redis vim

Rồi truy cập Redis database mà Laravel đang dùng:

redis-cli -h <redis-host> -n 1 --scan

Mục tiêu của tôi:

Tìm ra nhóm keys nào đã ăn hết RAM của Redis.

Bởi Redis mà đầy RAM thì chỉ có 1 trong 2 nguyên nhân:

1. Key quá to
2. Too many keys

Và theo trực giác, tôi nghiêng về too many keys.

3. Nhận diện pattern lạ – cuộc điều tra bắt đầu có hy vọng

Trong dự án laravel_dev, tôi lướt qua các module có khả năng sinh nhiều keys.
Sau một hồi đọc log và grep source, tôi để ý đến pattern:

laravel_dev_cache_:App\\\\Jobs*

Đây là nhóm keys do một service lưu metadata job, kiểu dạng log hoặc tracking.

Tôi quyết định scan thử:

redis-cli -h <redis-host> -n 1 --scan --pattern "laravel_dev_cache_:App\\\\Jobs*" | wc -l

Redis trả về:

≈ 2.800.000 keys

Tôi ngồi im vài giây.

Đây chính là thủ phạm.

4. Đào sâu hơn – không chỉ nhiều keys mà còn “bất tử”

Tôi kiểm tra TTL của một vài key:

redis-cli -h <redis-host> -n 1 TTL "laravel_dev_cache_:App\\Jobs\\JobName:1234567890"

Kết quả:

-1

TTL = -1 nghĩa là:

Key không bao giờ tự hết hạn.

Vậy là rõ:
Code đang sinh keys mỗi ngày, mỗi giờ, mỗi phút → và không bao giờ xoá.
Một kiểu memory leak rất phổ biến khi dùng Redis sai mục đích.

5. Vấn đề khó nhằn: Xoá 2.8 triệu keys sao cho không làm Redis chết tiếp

Không thể dùng KEYS — vì:

• Nó block Redis
• Khi memory đang căng → khả năng treo Redis rất cao
• AWS ElastiCache có thể tự động failover

Chỉ có một cách an toàn: SCAN + DEL dần dần.

Tôi viết một đoạn bash loop:

while IFS= read -r key; do
  echo "Deleting key: '$key'"
  redis-cli -h <redis-host> -n 1 DEL "$key"
done < <(redis-cli -h <redis-host> -n 1 --scan --pattern "laravel_dev_cache_:App\\\\Jobs*")

Mất khoảng 30–40 phút, lượng keys giảm rõ rệt.
Biểu đồ memory từ 100% rớt xuống 10%.
Horizon hồi sinh. Queue bắt đầu đẩy job trở lại. Cache tiếp tục hoạt động

Nếu muốn chạy background mà không cần giữ terminal:

nohup sh -c '
while IFS= read -r key; do
  echo "Deleting key: '\''$key'\''"
  redis-cli -h <redis-host> -n 1 DEL "$key"
done < <(redis-cli -h <redis-host> -n 1 --scan --pattern "laravel_dev_cache_:App\\\\Jobs*")
' > /tmp/redis_delete.log 2>&1 &

Một cảm giác rất “đã” — giống như nới được một cái van áp lực.

6. Tìm hiểu nguyên nhân trong code – thủ phạm thực sự nằm ở logic

Tôi trace lại luồng xử lý và phát hiện:

• Mỗi job đều sinh ra 1 metadata key khi kết hợp với Laravel Scheduler chưa đúng cách/
• Key lưu dạng JSON với prefix laravel_dev_cache_:App\\Jobs:...
• Không có TTL
• Không có cơ chế cleanup
• Job chạy nhiều hơn dự kiến → số lượng keys tăng âm thầm một cách đều đặn hàng phút.

Đây là kiểu bug không gây lỗi ngay lập tức, nhưng sẽ phá hủy hệ thống sau vài tuần hoặc vài tháng — nên rất khó phát hiện nếu không quan sát metrics.

7. Fix triệt để – để sự cố này không bao giờ quay lại

Tôi áp dụng 3 thay đổi lớn.

7.1 Bắt buộc gán TTL cho mọi key

Trong Laravel:

Cache::put($key, $value, now()->addMinutes(60));

Trong Redis thuần:

Redis::setex($key, 3600, $value);

Nếu bạn để key tồn tại mãi mãi → bạn đang đặt bom hẹn giờ trong hệ thống.

7.2 Gom tất cả vào Hash thay vì tạo hàng triệu keys rời rạc

Từ:

laravel_dev_cache_:App\\Jobs:<jobId>

Chuyển sang:

HSET laravel_dev:jobs:<date> <jobId> <data>
EXPIRE laravel_dev:jobs:<date> 86400

Thay vì 1.8M keys → chỉ còn < 30 keys/ngày.

7.3 Giới hạn dung lượng log

Giữ 200 job gần nhất chẳng hạn:

Redis::ltrim('laravel_dev:jobs_log', -200, -1);

8. Bài học sau sự cố – những thứ tôi ước gì mình biết sớm hơn

Sau ca này, tôi rút ra những kinh nghiệm rất thực chiến:

8.1. Redis không phải database.

Dùng Redis để lưu dữ liệu dạng “log” là tự sát.

8.2. Mọi key phải có TTL — luôn luôn.

Không trừ trường hợp đặc biệt.

8.3. Số lượng keys cũng là chỉ số quan trọng như memory.

Rất ít đội monitor key-count, nhưng nên làm.

8.4. Cần có cơ chế alert sớm.

• Memory > 80%
• Key-count tăng nhanh
• Horizon queue lag

8.5. Khi Redis đầy, đừng hoảng — scan và xoá đúng cách là cứu được.

Không được dùng KEYS.

9. Kết luận – Một ca sự cố đáng nhớ, và bài học cho những lần sau

Sự cố Redis OOM trong dự án laravel_dev không chỉ là một lỗi kỹ thuật.
Nó nhắc tôi rằng:

• Hệ thống có thể chạy rất mượt trước khi đột ngột “bung lụa”.
• Metrics là thứ không bao giờ được xem nhẹ.
• Redis mạnh, nhưng dùng sai cách thì nguy hiểm như bất kỳ database nào.

Hy vọng hành trình này giúp bạn tránh được một ngày làm việc “chữa cháy” như tôi.

The post Hành Trình Debug Lỗi Redis OOM Trong Laravel: Tìm Ra Hơn 2.8 Triệu Keys Và Cách Khắc Phục Triệt Để appeared first on Tomoshare.

Xin chào, tiếp nối bài Sức mạnh của sự từ chối của chị Minh Ngô, hôm nay tôi sẽ giới thiệu cho các bạn một vài cách để nói “Không” ở bài viết này. Now let’s go!

Nói “Không” – kỹ năng khó nhưng cần thiết để bảo vệ giới hạn và tôn trọng nhu cầu bản thân

Trong cuộc sống, chúng ta thường xuyên phải đối mặt với những yêu cầu từ người khác. Đôi khi, chúng ta không muốn hoặc không thể đáp ứng những yêu cầu đó. Lúc này, biết cách nói “Không” là một kỹ năng quan trọng giúp chúng ta bảo vệ thời gian, năng lượng và sức khỏe của bản thân.

Đương nhiên, nói “Không” không phải lúc nào cũng dễ dàng. Chúng ta có thể cảm thấy ngại ngùng, xấu hổ hoặc lo lắng rằng người khác sẽ nghĩ gì về mình. Tuy nhiên, việc khéo léo từ chối một cách lịch sự có thể giúp xoa dịu tình hình và vẫn duy trì mối quan hệ tốt đẹp.
Điều quan trọng nhất là bạn phải kiên định với lập trường và tôn trọng giá trị của chính mình. Bạn cũng không nhất thiết phải có một lý do cụ thể để nói “Không”.

Để từ chối hiệu quả, bạn cần tuân thủ các nguyên tắc sau:

• Tự tin và thẳng thắn: Đừng vòng vo hoặc đưa ra những lý do không thuyết phục. Hãy nói rõ rằng bạn không muốn làm điều đó.
• Có lý do chính đáng và đề nghị phương án khác nếu có thể: Nếu có thể, hãy đưa ra lý do chính đáng cho việc từ chối của bạn. Điều này sẽ giúp bạn tự tin hơn và cũng giúp người khác hiểu được quyết định của bạn. Ngoài ra, bạn có thể gợi ý phương án khác để cho thấy bạn tôn trọng người khác và sẵn sàng tìm giải pháp chung.
• Tôn trọng người khác: Ngay cả khi bạn đang từ chối, hãy vẫn tôn trọng người khác. Hãy nhớ giữ thái độ lịch sự và nhã nhặn trong cách bạn từ chối.
• Luyện tập thường xuyên: Luyện tập nói “Không” thường xuyên sẽ giúp bạn trở nên tự tin hơn và từ chối hiệu quả hơn. Hãy bắt đầu bằng những việc nhỏ, chẳng hạn như từ chối lời mời tham dự một cuộc hẹn, một bữa tiệc mà bạn không muốn đi. Khi bạn đã cảm thấy thoải mái hơn với việc từ chối, bạn có thể bắt đầu từ chối những yêu cầu lớn hơn, chẳng hạn như từ chối một công việc mà bạn không muốn làm.

Dưới đây là một số ví dụ về cách nói “Không” hiệu quả:

• “Cảm ơn vì lời mời, nhưng tôi không thể tham dự vì đã có lịch từ trước.”
• “Tôi xin lỗi, hôm nay công việc của tôi đang rất bận và tôi không có thời gian để giúp bạn.”
• “Tôi biết bạn đang đề nghị một cơ hội tuyệt vời, nhưng có lẽ không phù hợp với tôi.”

Bạn cũng có thể tham khảo một số lời “từ chối” khéo léo hơn như sau:

• “Cảm ơn bạn đã nghĩ đến tôi. Tôi sẽ xem xét và cho bạn biết sau.”
• “Tôi không chắc mình có thể làm được không, nhưng chúng ta có thể thử cách khác.”
• “Tôi không thể tham dự cuộc họp hôm nay, nhưng tôi có thể gửi cho bạn tài liệu cần thiết.”

Một số lưu ý khi nói “Không”

• Đừng cảm thấy tội lỗi hoặc xấu hổ khi nói “Không”. Bạn có quyền từ chối bất cứ điều gì bạn không muốn làm khi điều đó không phù hợp với kỹ năng, chuyên môn hoặc sở thích của bản thân hoặc ảnh hưởng đến sức khỏe tâm lý, thể chất của bạn.
• Đừng sợ làm phật lòng người khác. Nếu ai đó không hài lòng vì bạn từ chối họ, đó không phải là lỗi của bạn.
• Hãy mạnh dạn nói “Không” với những yêu cầu quá đáng hoặc không hợp lý, đi ngược giá trị, niềm tin của bạn. Đừng để người khác lợi dụng bạn.

Tạm kết

Nói “Không” không phải là hành động ích kỷ, mà là một cách khẳng định bản thân và bảo vệ những điều quan trọng với bạn. Đôi khi, “Không” chính là câu trả lời duy nhất để bạn thoát khỏi những gánh nặng không cần thiết và ưu tiên hạnh phúc của mình.

Đây là nghệ thuật giao tiếp hết sức cần thiết trong cuộc sống và công việc hàng ngày, là một kỹ năng quan trọng cần mài giũa. Bằng cách luyện tập thường xuyên và áp dụng những nguyên tắc trên, biết nói “Không” một cách khéo léo và tinh tế sẽ giúp bạn tránh được phiền toái, tránh lãng phí thời gian và tập trung cho việc nâng cao giá trị của bản thân và sống cuộc sống như bản thân mong muốn.

P/s: Được rồi, cảm ơn các bạn đã đọc tới đây. 2023 sắp hết rồi, bạn nào chưa thực hành kỹ năng này thì hãy thử trong 2024 nhé. Chúc các bạn thành công ^^

The post Làm thế nào để nói “Không” hiệu quả appeared first on Tomoshare.

Apollo:

Theo tài liệu Apollo cung cấp, phương thức getDataFromTree sẽ tìm kiếm trong page tree của mình các component có sử dụng hook useQuery sau đó thực hiện truy vấn tất cả các query đó ở server

Nghe có vẻ ổn phết nhưng đội ngũ NextJS nói không. getDataFromTree được đánh giá là anti-pattern đối với NextJS vì getDataFromTree không được tích hợp vào các phương thức mà NextJS đã cung cấp cho việc fetch dữ liệu như getStaticProps và getServerSideProps. Việc getDataFromTree duyệt page tree một lần nữa để tìm kiếm các useQuery cũng ảnh hưởng đến hiệu suất render trang. Và cuối cùng là mình gặp lỗi tích hợp getDataFromTree vào version của NextJS hiện tại của dự án : D.

Thật may thì cuối cùng NextJS cũng đưa ra một phương án khác đối với Apollo vẫn tận dụng được các phương thức SSR của NextJS đó là tận dụng sức mạnh của Apollo cache.

Apollo cache

Apollo Client sử dụng một hệ thống cache để tối ưu hóa việc quản lý và truy cập dữ liệu trong ứng dụng của bạn. Cache trong Apollo Client là nơi lưu trữ tạm thời kết quả của các truy vấn GraphQL, cho phép ứng dụng của bạn tái sử dụng dữ liệu này mà không cần phải gửi lại truy vấn đến server. Nó giúp giảm thiểu số lượng yêu cầu mạng, giảm độ trễ và cải thiện hiệu suất ứng dụng.

Ý tưởng của mình sẽ là fetch data thông qua getServerSideProps. Sau khi đã fetch tất cả các dữ liệu FE server sẽ gen ra một file html đầy đủ và trả về thêm dữ liệu từ Apollo thông qua props cho client. Việc trả về thêm Apollo data giúp chúng ta tận dụng được các thuộc tính data, loading và các phương thức như refetch của Apollo client và đồng bộ dữ liệu giữa client và FE server lúc khởi tạo trang thông qua Apollo cache

Bắt đầu thôi

• Khởi đầu với tạo dự án NextJS

npx create-next-app

• Cài các package liên quan đến Apollo client. Ở đây mình cài thêm graphql-codegen để tự động gen các hook React từ các document và schema

npm i graphql @apollo/client @graphql-codegen/typescript-react-apollo @graphql-codegen/cli

• Cài vài package dùng để xử lí logic và tạo proxy ẩn danh

npm i http-proxy deepmerge lodash.isequal @types/lodash.isequal @types/http-proxy

• Tạo file .env để chứ API_URL

NEXT_PUBLIC_API_URL=https://beta.pokeapi.co/graphql/v1beta

• Tạo file index.ts trong thư mục src/api để tạo 1 http proxy

import httpProxy from 'http-proxy';
import type { NextApiRequest, NextApiResponse } from 'next';

// You can export a config variable from any API route in Next.js.
// We'll use this to disable the bodyParser, otherwise Next.js
// would read and parse the entire request body before we
// can forward the request to the API. By skipping the bodyParser,
// we can just stream all requests through to the actual API.
export const config = {
  api: {
    bodyParser: false,
  },
};

const proxy = httpProxy.createProxyServer();

export default async function handler(req: NextApiRequest, res: NextApiResponse<unknown>) {
  // Return a Promise to let Next.js know when we're done
  // processing the request:
  return new Promise(async (resolve, reject) => {
    // Rewrite the URL: strip out the leading '/api'.
    // For example, '/api/login' would become '/login'.
    // ️You might want to adjust this depending
    // on the base path of your API.
    req.url = req?.url?.replace(/^\/api/, '');

    // // Handle error
    proxy.once('error', () => {
      reject();
    });

    proxy.once('proxyRes', () => {
      resolve(true);
    });

    // Forward the request to the API
    proxy.web(req, res, {
      target: process.env.NEXT_PUBLIC_API_URL,
      autoRewrite: false,
      changeOrigin: true,
      selfHandleResponse: false,
    });
  });
}

• Config file codegen bằng lệnh npx graphql-code-generator init hoặc tạo file codegen.ts ở ngoài cùng thư mục dự án và copy paste đoạn config dưới này

import type { CodegenConfig } from '@graphql-codegen/cli';
import { loadEnvConfig } from '@next/env';

loadEnvConfig(process.cwd());

const config: CodegenConfig = {
  overwrite: true,
  schema: process.env.NEXT_PUBLIC_API_URL,
  documents: ['./src/graphql/**/*.{gql,graphql}'],
  ignoreNoDocuments: true, // for better experience with the watcher
  generates: {
    'src/__generated__/graphql.tsx': {
      plugins: ['typescript', 'typescript-operations', 'typescript-react-apollo'],
    },
  },
};

export default config;

• Định nghĩa một đối tượng Apollo client và hàm addApolloState ở file src/lib/apolloClient.ts

import {
  ApolloClient,
  InMemoryCache,
  type NormalizedCacheObject,
} from '@apollo/client';
import merge from 'deepmerge';
import isEqual from 'lodash.isequal';


const COUNTRIES_API = 'https://countries.trevorblades.com';

export const APOLLO_STATE_PROP_NAME = '__APOLLO_STATE__';

let apolloClient: ApolloClient<NormalizedCacheObject> | null;

function createApolloClient() {   
  return new ApolloClient({
    ssrMode: typeof window === 'undefined', 
    uri: typeof window === 'undefined' ? `${process.env.NEXT_PUBLIC_API_URL}` : '/api',
    cache: new InMemoryCache(),
  });
}

export function initApolloClient(initialState?: any) {
  const _apolloClient = apolloClient ?? createApolloClient();

  if (initialState) {
    const existingCache = _apolloClient.cache.extract();

    const data = merge(initialState, existingCache, {
      arrayMerge: (destinationArray, sourceArray) => [
        ...sourceArray,
        ...destinationArray.filter((d) =>
          sourceArray.every((s) => !isEqual(d, s))
        ),
      ],
    });
    _apolloClient.cache.restore(data);
  }

  if (typeof window === 'undefined') {
    return _apolloClient;
  }

  if (!apolloClient) {
    apolloClient = _apolloClient;
  }

  return _apolloClient;
}

export function addApolloState(
  client: ApolloClient<NormalizedCacheObject>,
  pageProps: any
) {
  if (pageProps?.props) {
    pageProps.props[APOLLO_STATE_PROP_NAME] = client.cache.extract();
  }

  return pageProps;
}

Hàm createApolloClient trả về một đối tượng Apollo client: tham số uri định nghĩa API_URL. Khi ở server side call API sẽ gọi trực tiếp đến API_URL của BE, còn phía client side sẽ gọi thông qua proxy mình đã tạo ở trên để tăng tính bảo mật cho API_URL

Hàm initApolloClient đảm bảo trong suốt phiên làm việc của web chỉ có duy nhất 1 đối tượng Apollo client được khởi tạo

Hàm addApolloState sẽ đẩy data đã được fetch từ server side vào 1 prop có tên là __APOLLO_STATE__ sau đó sẽ được gửi đến client side thông qua pageProps là giá trị mặc định trả về của hàm getServerSideProps

• Tiếp theo ta sẽ tạo một hook useApollo ở file src/hooks/useApollo.ts. Hook này sẽ theo dõi sự thay đổi của prop __APOLLO_STATE__ và sẽ quyết định tạo mới một đối tượng Apollo client nếu chưa có hoặc ngược lại sẽ trả về đối tượng Apollo client đã tồn tại

import { APOLLO_STATE_PROP_NAME, initApolloClient } from '@/lib/apolloClient';
import { useMemo } from 'react';

function useApollo(pageProps: any) {
  const state = pageProps[APOLLO_STATE_PROP_NAME];
  const client = useMemo(() => initApolloClient(state), [state]);

  return client;
}

export default useApollo;

Đến đây mọi thứ đã gần như hoàn thiện rồi việc cuối cùng là tạo một query ví dụ và kiểm tra xem SSR có hoạt động đúng như mong đợi của chúng ta hay không thôi

Thử nghiệm

• Tạo một query document ở file src/graphql/queries/getPokemons.query.gql. Ở đây mình muốn lấy danh sách tất cả tên các Pokemon nên là câu query sẽ dạng như thế này:

query getPokemons {
  pokemon_v2_pokemonspecies {
    id
    name
  }
}

• Chạy lệnh npm run codegen để graphql-codegen đọc file schema và các file document để tạo ra các đối tượng document và hook và NextJS có thể đọc được nhé
• File src/pages/index.tsx mình sửa lại để call hook useGetPokemonsQuery và render data nhé.

import { GetPokemonsDocument, useGetPokemonsQuery } from '@/__generated__/graphql'
import { addApolloState, initApolloClient } from '@/lib/apolloClient'

export default function Home() {
  const { data } = useGetPokemonsQuery()

  return (
    <main
      className={`flex min-h-screen flex-col items-center justify-between p-24`}
    >
      <div className="z-10 max-w-5xl w-full items-center justify-between font-mono text-sm flex flex-col">
        {data?.pokemon_v2_pokemonspecies.map((pokemon) => (
          <div key={pokemon.id}>{pokemon.name}</div>
        ))}
      </div>
    </main>
  )
}

Code thì đã chạy ổn đã fetch được data từ Graphql nhưng vẫn chưa đúng với mục tiêu của blog đưa ra là trang này phải chạy ở mode SSR. Vậy thì thêm tiếp dòng code dưới ở src/pages/index.tsx nhé.

export const getServerSideProps = async () => {
  const client = initApolloClient();
  await client.query({ query: GetPokemonsDocument});

  return addApolloState(client, {
    props: {},
  });
};

Đây là kết quả cuối cùng. Ở tab network ta sẽ không còn thấy request /api với payload getPokemons nữa và khi ta bật tab view page source nên sẽ thấy file html gen đầy đủ các thẻ div chứa các tên pokemon

Khi mọi người đọc code sẽ thấy query được gọi 2 lần.

1 lần ở getServerSideProps: await client.query({ query: GetPokemonsDocument});
Và 1 lần nữa ở function component: const { data } = useGetPokemonsQuery(). Sẽ tự hỏi liệu việc gọi lại này có phải sẽ tạo 2 request đến BE không thì câu trả lời là không nhé. Vì gọi lại này nhằm mục đích tận dụng các thuộc tính data, các phương thức refresh do Apollo cung cấp, dễ quản lý dữ liệu ở function component hơn và data lấy từ function component là data được trả về thông qua pageProps mình đã giải thích ở trên nên không ảnh hưởng đến hiệu suất của trang web.

Mn có thể tham khảo code đầy đủ hơn ở: https://github.com/long-la-tomosia/nextjs-ssr-apollo/tree/main

Bài viết dựa trên việc nghiên cứu của 1 cá nhân nên có thể sẽ có 1 vài sai sót mong mọi người góp ý và chia sẻ để hoàn thiện hơn. Cảm ơn mọi người đã theo dõi bài viết : D

The post Khởi tạo dự án với Apollo và NextJS SSR appeared first on Tomoshare.

rails db:create # Creates the database from DATABASE_URL or config/database.yml for the current RAILS_...
rails db:drop # Drops the database from DATABASE_URL or config/database.yml for the current RAILS_EN...
rails db:encryption:init  # Generate a set of keys for configuring Active Record encryption in a given environment
rails db:environment:set  # Set the environment value for the database
rails db:fixtures:load  # Loads fixtures into the current environment's database
rails db:migrate  # Migrate the database (options: VERSION=x, VERBOSE=false, SCOPE=blog)
rails db:migrate:down # Runs the "down" for a given migration VERSION
rails db:migrate:redo # Rolls back the database one migration and re-migrates up (options: STEP=x, VERSION=x)
rails db:migrate:status # Display status of migrations
rails db:migrate:up # Runs the "up" for a given migration VERSION
rails db:prepare # Runs setup if database does not exist, or runs migrations if it does
rails db:reset # Drops and recreates all databases from their schema for the current environment and ...
rails db:rollback # Rolls the schema back to the previous version (specify steps w/ STEP=n)
rails db:schema:cache:clear # Clears a db/schema_cache.yml file
rails db:schema:cache:dump  # Creates a db/schema_cache.yml file
rails db:schema:dump  # Creates a database schema file (either db/schema.rb or db/structure.sql, depending on...
rails db:schema:load  # Loads a database schema file (either db/schema.rb or db/structure.sql, depending on ...
rails db:seed # Loads the seed data from db/seeds.rb
rails db:seed:replant # Truncates tables of each database for current environment and loads the seeds
rails db:setup  # Creates all databases, loads all schemas, and initializes with the seed data (use db...
rails db:version  # Retrieves the current schema version number
rails test:db # Run tests quickly, but also reset db

Thay vì phải nhớ hết như vậy thì ta nên thiết lập alias cho đơn giản.

Thiết lập alias tại: vi ~/.bashrc

alias br='bin/rails'
alias be='bundle exec'
alias brdm='bin/rails db:migrate RAILS_ENV=development && bin/rails db:migrate RAILS_ENV=test'
alias brdrol='bin/rails db:rollback STEP=1 && bin/rails db:rollback STEP=1 RAILS_ENV=test'
alias bi='bundle install'
alias ees="export EDITOR='subl -w'"
alias bd="./bin/dev"
alias brdcm="br db:drop db:create db:migrate"
alias brdcms="br db:drop db:create db:migrate db:seed"
alias rcr="bin/rails cypress:run"
alias rco="bin/rails cypress:open"
alias resetdbtest='bin/rails db:drop db:create db:migrate RAILS_ENV=test'
alias resetdbdev='bin/rails db:drop db:create db:migrate RAILS_ENV=development'
alias brg='bin/rails generate'
alias brt='bin/rails test'
alias fd="foreman start -f Procfile.dev"

Happy Coding!

The post Rails console command made easier 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.

Đây là 1 bài post được nghe và viết lại, hy vọng sẽ là 1 bài post hữu ích cho nhiều người và chúc cho những ai đang tự giam cầm, đắm chìm bản thân vào những nỗi đau, thì có thể mở lòng, bỏ qua chuyện cũ và bước tiếp về tương lai.  

                                        MOVE ON – Khép lại chuyện cũ và bước tiếp 

Một điều rất rõ ràng, việc bỏ qua những chuyện cũ, những tổn thương và nỗi đau đến từ nhiều khía cạnh khác nhau trong cuộc sống để bước tiếp về tương lai là điều không hề dễ dàng. Bất kì nỗi đau nào đã đến với mình, đều là những vết thương sưng tấy và rỉ máu bất chấp thời gian. Nó làm cho mình cảm thấy tổn thương và buồn bã mỗi khi nghĩ tới, đó là những nỗi đau không tên và có thể đi theo suốt cuộc đời của mình, khiến cho mình mắc kẹt ngay tại đó và không cách nào thoát ra được để có thể tiếp tục bước tiếp về phía trước.

Trong cuộc đời của 1 con người chắc chắn sẽ có rất nhiều vết thương như vậy, và cũng có rất nhiều người đau quá mà gục ngã không thể đứng lên, vì giận quá mà kẹt luôn ở trong đó không thoát ra được, chán nản và tuyệt vọng quá mà đầu hàng, bỏ cuộc với tương lai. Thực tế trong cuộc sống hiện đại ngày nay đã có những trường hợp vì quá chán nản tuyệt vọng mà đi đến những cái kết không mong muốn. 

Câu hỏi cần hỏi ở đây là: “Mình có cần phải như vậy hay không?”, “Có cần phải hy sinh cả cuộc đời còn lại để trả giá cho 1 lần vấp ngã hay tổn thương không? “, “Nó có phải là 1 cái giá quá đắt nếu làm như vậy không?" và “Có đáng phải quằn quại trong trong nỗi đau đó hay không?" trong khi người khác, dù họ vô tình hay cố ý gây ra tổn thương cho bạn, có khi vẫn đang vui vẻ, nhởn nhơ và cười trên nỗi đau của bạn ấy chứ. Vậy có đáng không khi bạn đang tự gánh chịu nỗi đau 1 mình, vật lộn mỗi ngày với nó?

Có 1 số sự thật mà bản thân bạn cần phải chấp nhận để có thể move on, và việc chấp nhận được sự thật là 1 điểm tựa để mà bạn có thể bỏ lại quá khứ và hướng về 1 tương lai tốt hơn. 

1. Bạn đau cỡ nào không ai quan tâm

• Đừng nghĩ rằng bạn đau, bạn nói về nó, la làng lên cho tất cả mọi người biết thì sẽ có nhiều người quan tâm. Sự thật là KHÔNG. Người ta chỉ là hỏi thăm vậy thôi và rồi cuối cùng chỉ có 1 mình bản thân bạn, ở đây để đối mặt với mọi thứ.
• Bạn nghĩ chuyện xảy ra thật khủng khiếp và quá sức, khiến bạn gục ngã và sống quằn quại trong đó. Nhưng sự thật là người gây tổn thương cho bạn, họ không quan tâm, đôi khi họ còn không biết rằng đã gây ra sự tổn thương đó, họ không hối hận và không 1 lần nhìn lại xem bạn tổn thương như thế nào. Họ có cuộc đời riêng với nhiều vấn đề khác nhau và họ bận bịu với nó. Thế nên họ không nhớ đến câu chuyện của bạn đâu.
• Bản chất của mỗi con người luôn tồn tại sự ích kỉ, người ta chỉ quan tâm chuyện của bản thân và không có mấy ai đi lo chuyện bao đồng, quan tâm đến người khác đâu. Cho nên bạn cũng không cần diễn lại để có được sự tội nghiệp, chú ý hay sự quan tâm của người ta.
• Và cũng đừng chờ đợi hay mong mỏi có ai đó hiện ra như ông bụt và xoa dịu nỗi đau giúp bạn. Điều đó chỉ có trong chuyện có tích thôi, nó không có ở đời thực. Ông bụt chính là Nội lực, Động lực và là Bản lĩnh của chính bạn. Khi hiểu ra được, đời này chỉ có bạn cứu được chính mình, thì bạn sẽ tự đứng lên, dũng cảm bước ra và bắt đầu 1 hành trình mới.

2. Bỏ cuộc là điều họ muốn

• Có người đã nói thế này “Cái người hả hê nhất khi bạn đau đớn, giận dữ, gục ngã chính là kẻ gây ra nỗi đau đó cho bạn vì người ta biết rằng điều người ta nói, làm và hành xử sẽ khiến bạn đau đớn." Vậy nên khi họ tổn thương bạn, người hả hê nhất khi thấy bạn bị kẹt trong đó không cách nào thoát ra được chính là họ. Thế thì tại sao bạn lại để họ điều khiển bản thân nhỉ? Tại sao bạn lại phải khổ sở đúng như họ mong muốn? Đây là 1 sự thật rất chua chát nhưng bạn phải chấp nhận sự thực rằng cảm xúc của bạn đang bị điều khiển bởi người khác.
• Khi bạn tuyên bố bỏ cuộc, bạn nghĩ thế giới sẽ xúm vào đau lòng ư? Hoang tưởng!! =))) Người muốn bạn bỏ cuộc đang vui vẻ vì điều đó. Người quen bạn sẽ buồn bã lắc đầu và rồi cũng sẽ bỏ đi để lo chuyện của họ. Đám đông còn lại, họ cần được giải trí, cho nên chuyện của bạn càng nghiệt ngã thì họ càng thích thú, càng drama thì họ càng hào hứng vì có nhiều đề tài để bàn tán và tranh cãi. Như vậy nghĩa là bạn đang tự mang nỗi đau của mình ra cho đời giải trí. Không ai quan tâm đến bạn, họ chỉ muốn giải trí trên câu chuyện của bạn. Người ta sẽ xem bạn diễn, sau đó cười cợt cho đã và bỏ đi, không 1 chút bận tâm. Vậy thì bạn lăn ra đó đau khổ để làm gì?

3. Lớn lên & bao dung với nỗi đau cũ

• Bạn phải sống cuộc đời của bạn, bởi vì đây chính là cuộc đời, niềm vui, hạnh phúc của cá nhân bạn, và nó không hề liên quan tới bất kì ai cả. Nếu bạn không tự đứng dậy, không tự thoát ra để bước tiếp thì sẽ không có ai khác làm chuyện đó cho bạn cả. 

• ”Người ta đối xử như vậy thì mình phải trả thù” :D Có cần thiết như vậy không? Khi bạn lớn lên, lớn hơn cả vấn đề và nỗi đau, bao dung được với cả những con người như vậy thì cuộc đời của bạn sẽ tích cực hơn, vui vẻ hơn, thành công hơn, đầy màu sắc lung linh hơn. Như vậy sẽ hay hơn so với việc suốt ngày nghĩ cách trả thù và loay hoay trong mớ lòng bong suốt đời, phải không?
• Khi bạn bao dung được cả nỗi đau, thì sẽ không có ai đau đớn ở đây cả, ngược lại chính nỗi đau đó là điểm tựa để bạn lớn hơn và hạnh phúc hơn. Và rồi chuyện cũ sẽ thành chuyện nhỏ, có khi bạn sẽ thấy thương người đó, vì sự hẹp hòi và nhỏ nhen của họ. Có khi người ta tổn thương bạn chỉ vì chính họ cũng đang bị tổn thương. Như vậy thì đó chính là vấn đề của người ta, nó không phải vấn đề của bạn. Thế nên bạn không việc gì phải lăn ra đau khổ vì sự tổn thương của một ai khác cả.
• Và rồi bạn nhận ra chuyện tự lăn ra đau khổ thật là vô lí và rất phí thời gian, năng lượng, tuổi thanh xuân và cơ hội của bạn. Thế nên bạn đứng lên, khép lại quá khứ và move on để tiếp tục hành trình, 1 hành trình hay ho và đầy hào hứng.

Cuối cùng, mong cho những ai đang bị mắc kẹt, không thể bước tiếp, vì bất kì lí do  nào, sau khi biết đến những chia sẻ này thì có thể nhìn nhận lại các vấn đề, chấp nhận sự thật và tìm được động lực để move on và tận hưởng 1 hành trình mới vui vẻ hơn trong tương lai.

The post MOVE ON appeared first on Tomoshare.

Trong quá trình coding thì chúng ta sẽ không thể tránh khỏi những trường hợp lỗi không mong muốn và nếu như chúng ta throw ra lỗi đó qua phía client thì có thể dẫn đến lỗi bảo mật hay trải nghiệm người dùng không tốt.

Để khắc phục tình trạng này thì NestJS có một Exception Layer. Layer này sẽ catch tất cả unhandled error và xử lý nó trước khi trả về Controller. Và tất nhiên chúng ta cũng có thể custom response hay handle lại error này trước khi nó được trả về.

Default Response

{
  "statusCode": 500,
  "message": "Internal server error"
}

Xử lý Error với Exception Filters

Để có thể handle sao cho phù hợp với từng loại Error thì chúng ta có thể Catch những Error mà ta mong muốn

@Catch(HttpException) // Http Error

@Catch(PrismaException) // Database Error

@Catch(CustomErrorInstance) // Custom Error

Sau khi đã Catch được Error mà mình mong muốn thì chúng ta sẽ phải implement lại class ExceptionFilter của NestJS và handle Error.

@Catch()
export class InternalExceptionFilter implements ExceptionFilter {
  async catch(exception: HttpException, context: GqlExecutionContext) {
    if (exception instanceof HttpException) {
      if (exception.getStatus() !== 500) return exception;
    }
    //Handle Error on production environment
    if (process.env.NODE_ENV !== "development") {
      const ctx = GqlExecutionContext.create(context).getContext();
      const req: Request & { user: Partial<User> | null } = ctx.req;
      const { query, operationName, variables } = req.body;
      const authorization = {
        laboId: req.header("labo-id"),
        userId: req.user?.databaseId,
      };

      const errorParams: ErrorTemplateParams = {
        hostname: req.hostname,
        query,
        payload: JSON.stringify({ operationName, variables }, null, 2),
        stack: exception.stack,
        errorName: exception.name,
        authorization: JSON.stringify(authorization, null, 2),
      };

      const slack = new SlackService();
      slack.sendMessage(errorParams);
      // Return default error response
      return new InternalServerErrorException("Internal_Error");
    }
    // return error + stacktrace
    return exception;
  }
}

Thì ở đây mình đã Catch tất cả Error bao gồm Http Error và Database Error chỉ ngoại trừ những lỗi 4xx đã throw ra.

Ở đây chúng ta có 2 tham số đó làm exception và context thì nó là cái gì?

exception ở đây nó là lỗi nguyên bản nó thuộc về instance của Error. Thì trong exception nó sẽ bao gồm: stacktrace, message, errorName và error.

context này nó được coi là host, chúng ta có thể sử dụng context này để có thể tham chiếu đến Request và Response và có thể custom lại Error chi tiết hơn để có thể tracking bug dễ dàng hơn.

Custom Response

Và cuối cùng để NestJS có thể nhận được Exception Filter này thì t cần phải binding nó vào để có thể sử dụng như một global Filter.

// Handle Internal Error
  if (process.env.NODE_ENV !== "development") {
    app.useGlobalFilters(new InternalExceptionFilter());
  }

Kết bài:

NestJS là framework hỗ trợ mạnh mẽ với nhiều tính năng và Exception Filters là một trong số đó. Thì ở bài này chúng ta đã tìm hiểu qua ExceptionFilter là gì và Handle những Unhandled Error như thế nào.

Hẹn gặp lại mọi người trong bài viết tìm hiểu về NestJS khác.

The post Exception Filters là gì? Xử lý Unhandled Error trong NestJS appeared first on Tomoshare.

Tạo Hosted Zone

Đầu tiên khi mình đã mua được domain thì cần login vào AWS và tìm kiếm ‘Route 53’. Chọn vào mục Host zone ở side menu. Mình khởi tạo hosted zones bằng cách click vào Create Host Zone.

Sau đó mình nhập domain đã mua ở tenten, để trống mục comment và chọn Public Host Zone cho mục Type. Mình click Create hosted zone và đợi một vài giây để Host Zone mới được tạo ra.

Sau khi tạo thành công cùng với đó sẽ có một tập các Name Server (NS) record được tạo ra. Các NS server này sẽ được sử dụng để trỏ domain từ tenten về Route53(AWS).

Cấu Hình NS về Route53(AWS)

Đăng nhập vào quản lý domain của tenten, mình chọn mục ‘Quản lý dịch vụ tên miền’.

Mình chọn vào ‘thao tác’ chọn mục ‘cài đặt NS’ domain mình muốn chuyển về Route53 (AWS), cập nhập và tạo các record NS dựa vào các giá trị record được tạo ra khi tạo mới hosted zone Route53 (bước ở trên).

Sau khi cập nhập chúng ta sẽ phải đợi một thời gian để tenten cấu hình trỏ về Route53.

Kiểm tra domain đã được cấu hình thành công chưa

Ta chỉ cần mở terminal và gỏ lệnh dưới để kiểm tra, trong đó domain.com là domain của mình.

nslookup -type=ns domain.com

Nếu cấu hình thành công, kết quả sẽ hiển thị ra theo dạng như sau:

erver:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
domain.com	nameserver = ns-xxxx.awsdns-09.org.
domain.com	nameserver = ns-xxxx.awsdns-09.org.
domain.com	nameserver = ns-xxxx.awsdns-09.org.
domain.com	nameserver = ns-xxxx.awsdns-09.org.

The post Cấu hình domain provider về Route53 (AWS) appeared first on Tomoshare.