{ "version": "https://jsonfeed.org/version/1", "title": "Đào Anh Thành", "home_page_url": "https://daoanhthanh.vn/blog", "description": "Đào Anh Thành Blog", "items": [ { "id": "https://daoanhthanh.vn/blog/mot-cach-khac-de-su-dung-git-log", "content_html": "

Tôi rất thích sử dụng git cli cho công việc. Thứ nhất, GUI chỉ dành cho mấy tay gà mờ 🐧 đùa hoy =)), và thứ 2 việc sử dụng command line sẽ nhanh và \"thuận tự nhiên\" hơn cho các lập trình viên trong quá trình code.

\n\n

Chia sẻ một chút: tôi đã từng sử dụng rất nhiều Git GUI client như SourceTree, Git GUI, GitKraken, GitHub Desktop, Sublime Merge, cũng như các giao diện git tích hợp trong IDE. Tuy nhiên, thực tế là tôi chỉ dùng những tính năng hết sức cơ bản như pull, push, commit, cùng lắm thì là diff file, còn những thao tác nâng cao thì vẫn phải thực hiện thủ công. Không phải vì các ứng dụng trên không hỗ trợ, mà vì các thao tác nâng cao đòi hỏi nhiều thao tác chuột dài dòng trên màn hình.

\n

Sau khi trải nghiệm hầu hết các giao diện Git UI tiêu biểu trên thị trường, cả miễn phí lẫn trả phí, tôi nhận ra rằng: git CLI vẫn là lựa chọn tối ưu vì:

\n\n

Một nỗi lo thường trực khi làm việc với Git là phải nắm được \"bức tranh toàn cảnh\" của repo — có những thay đổi nào từ upstream trong lúc tôi đang làm việc trên nhánh của mình? Xung đột nào có thể xảy ra? Khi tôi push thì liệu có \"đạp chân\" ai không?

\n

Trước đây tôi thường dùng git client để nắm được điều này, vì tính năng đó của git - git log - trông khá là củ chuối

\n

\"alt\n

Fig 1: Nội dung này không có gì hữu ích lắm

\n

Git log mặc định là liệt kê các commit gần nhất, nhưng thứ tôi cần lại là:

\n\n

Sau khi tìm tòi google các kiểu, đây là câu lệnh mà tôi dùng hàng ngày:

\n
git log -9 --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all
\n

đây là kết quả:

\n

\"alt\n

Fig 2: Mọi thứ đã dễ nhìn hơn

\n

Mọi thứ đã được format gọn gàng và rất đầy đủ thông tin cho bạn.

\n

Nếu như bạn chỉ cần quan tâm đến một nhánh nhất định, ví dụ chỉ muốn xem nhánh hiện tại và develop thôi, bạn có thể chỉnh sửa một chút như sau:

\n
git log -6 --graph --abbrev-commit --decorate \\
  --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' \\
  develop HEAD # <== khác biệt chính nằm ở đây
\n

cùng xem kết quả

\n

\"alt\n

Fig 3: Khi bạn chỉ cần quan tâm một nhánh nhất định

\n

Giờ đây tôi đã biết được rằng nhánh của tôi (commit đầu tiên trong ảnh) đang ở sau một vài commit trong nhánh develop. Vì vậy tôi cần thực hiện rebase lại để cập nhật nhánh hiện tại trước khi tạo Merge Request.

\n
\n

Chà, bạn thông minh đã nhận ra, tôi đã sử dụng lg -9 và lg develop -6 thay vì gõ cả 2 câu dài ngoằng kể trên vào terminal như đã đề cập. Tôi đã viết một bài giải thích về điều này, bạn đọc có thể tham khảo ở đây Khai mở tiềm năng Command Alias.

\n
\n

Thường trước khi rebase hay merge nhánh, tôi sẽ kiểm tra trước xem liệu hai nhánh đó có conflict gì hay không. Một lần nữa, bạn không cần phải thao tác gì nhiều vì git log hoàn toàn có thể đáp ứng được.

\n
git log develop..HEAD --oneline --left-right --cherry-pick --color \\
  --pretty=format:'%C(yellow)%m%C(reset) %C(blue)%h%C(reset) %C(cyan)%an%C(reset) %C(green)%ar%C(reset) %s%n' \\
  | head -9
\n

Lệnh trên tiến hành lấy 9 conflict mới nhất của nhánh hiện tại và nhánh develop. Cùng xem kết của nó:

\n

\"alt\n

Fig 4: Ố ồ, vậy là có một conflict

\n

Hi vọng những chia sẻ trên sẽ khiến công việc của bạn được thuận tiện, và bạn sẽ trở nên năng suất hơn.

", "url": "https://daoanhthanh.vn/blog/mot-cach-khac-de-su-dung-git-log", "title": "Một cách khác để sử dụng git log", "summary": "Sử dụng git log một cách chuyên nghiệp", "date_modified": "2025-11-16T00:00:00.000Z", "author": { "name": "Đào Anh Thành", "url": "https://github.com/daoanhthanh" }, "tags": [ "git" ] }, { "id": "https://daoanhthanh.vn/blog/khai-mo-tiem-nang-command-alias", "content_html": "

Bài viết sẽ sẵn sàng sớm thôi. Hãy luôn cập nhật!

", "url": "https://daoanhthanh.vn/blog/khai-mo-tiem-nang-command-alias", "title": "Khai mở tiềm năng Command Alias", "summary": "Khai mở tiềm năng Command Alias", "date_modified": "2025-11-16T00:00:00.000Z", "author": { "name": "Đào Anh Thành", "url": "https://github.com/daoanhthanh" }, "tags": [ "cli", "linux" ] }, { "id": "https://daoanhthanh.vn/blog/use-merge-and-rebase-in-professional-way", "content_html": "

Tôi nhận ra một số lượng đáng kể đồng nghiệp của tôi có một sự hiểu khá mơ hồ về Merge và Rebase. Vì vậy tôi biên một bài vừa để giải thích, vừa để chia sẻ với ae cách một git guru làm việc.

\n\n

Có thể bạn sẽ nghĩ: lại một bài so sánh nữa, tại sao mình lại phải đọc nó nhỉ?

\n

Câu trả lời ngắn ngọn của tôi: Cách bạn xử lý lịch sử git sẽ lên một tầm cao mới.

\n

Chúng là gì​

\n

Trước tiên, tôi sẽ nói lại ý nghĩa của 2 tính năng này. Tôi tin rằng nhiều anh em tuy lập trình đã lâu nhưng chưa hiểu hết vai trò của chúng.

\n

Tôi cho rằng bạn đã hiểu cơ bản git là gì và dùng git để làm gì. Nếu bạn là người mới bắt đầu, hãy dành thời gian để tìm hiểu git trước khi đọc bài.

\n

Merge​

\n

Đơn giản như cái tên của nó: khi bạn muốn kết hợp code của mình vào chung code của người khác, bạn dùng merge. Hãy xem hình minh họa sau:

\n

\"interface\"

Fig 1: Nếu thời điểm commit code của bạn mới hơn, sau khi merge thì code của bạn sẽ\n
... ở vị trí mới hơn ¯\\_(ツ)_/¯

\n

Chiến lược merge trên người ta gọi là Fast Forward Merge. Thật là đơn giản đúng không? Tuy nhiên trong thực tế mọi thứ hiếm khi được \"vui vẻ\" như vậy!

\n

Khi làm việc nhóm và mọi người cùng phát triển song song, sẽ có lúc phần code của bạn được commit sau những thay đổi của người khác:

\n

\"interface\"

\n
\n

Bạn muốn kết hợp chúng vào với nhau thì đây sẽ là công việc được làm sau hậu trường: Git sẽ TỰ\nĐỘNG TẠO MỘT COMMIT MỚI VÀ GHI VÀO TIMELINE. Commit mới này GỘP commit của bạn với commit mới nhất\ncủa nhánh đích.

\n

Hình dưới đây minh hoạ hoạ lệnh git merge <nhánh-đích> được thực thi:

\n

\"interface\"

Fig 2: Commit mới được tạo để đánh dấu việc code được kết hợp, toàn bộ mọi thứ khác được giữ\nnguyên

\n

Ưu điểm của việc này là lịch sử phát triển của cả 2 nhánh được giữ nguyên vẹn. Bạn sẽ thấy được rất rõ rành mạch phát triển của từng nhánh, cùng với thời điểm chúng được kết hợp.

\n

\"interface\"

Fig 3: Thời điểm merge code, lịch sử phát triển của các nhánh được giữ nguyên vẹn

\n

Nhưng đôi khi việc này khiến lịch sử git bị rối, tăng rủi ro conflict trong quá trình merge sau này. Một trong những trường hợp kinh điển là khi bạn làm việc với nhiều nhánh feature nhỏ, liên tục cập nhật chúng với nhau (không phải với nhánh main). Git timeline của bạn có thể sẽ trông như thế này:

\n

\"alt\n

Fig 4: Nguy cơ conflict cao khi lịch sử git quá phức tạp

\n

Đây là lúc bạn nên nghĩ đến Rebase.

\n

Rebase​

\n

Rebase tạm dịch là \"tái cấu trúc\". Nó cũng là một cách để kết hợp code từ nhánh này sang nhánh khác, nhưng thay vì tạo một commit mới để ghi lại việc kết hợp, Rebase sẽ DI CHUYỂN TOÀN BỘ CÁC COMMIT CỦA BẠN LÊN TRÊN ĐẦU NHÁNH ĐÍCH.

\n

Dưới đây minh hoạ quá trình kết hợp code giữa 2 nhánh feature thành một sử dụng rebase:

\n
git checkout feature/abc # <== nhánh bạn đang làm việc
git rebase feature/xyz # <== nhánh bạn muốn kết hợp vào
\n

\"alt

Fig 5: Để ý rằng các commit của bạn đã được \"di chuyển\" lên trên cùng của nhánh đích

\n

Việc này có mặt lợi là làm cho lịch sử git của bạn trở nên thẳng hơn, dễ theo dõi hơn. Đồng thời giảm thiểu rủi ro conflict khi merge vào nhánh chính (main) sau này.

\n

\"alt

Fig 6: Lịch sử git trở nên thẳng và sạch hơn rất nhiều so với Fig 4

\n

NHƯNG NHƯNG NHƯNG ...

\n

Khi nào dùng Merge, khi nào dùng Rebase?​

\n

Không phải tự nhiên lại tồn tại 2 cách kết hợp code như vậy. Hiểu rõ về chúng sẽ giúp bạn làm việc dễ dàng hơn rất nhiều.

\n

Trước tiên nhớ kỹ điều này trong đầu, tôi sẽ giải thích sau:

\n
\n

\"Merge dùng cho KẾT HỢP nhánh, Rebase dùng cho CẬP NHẬT nhánh.\"

\n
\n

Dùng Merge khi kết hợp nhánh hoàn chỉnh​

\n

Để hiểu được lý do, hãy cùng so sánh lịch sử git sau khi dùng merge và rebase để kết hợp nhánh feature vào nhánh main.

\n

\"alt

Fig 7: Lịch sử gốc được bảo tồn khi dùng merge (trái),
\nbị xáo trộn khi khi dùng rebase (phải)

\n

Vì merge giữ nguyên trạng lịch sử phát triển của các nhánh - rebase thì không - nên nó rất phù hợp để sử dụng khi bạn muốn kết hợp một nhánh hoàn chỉnh vào nhánh chính (main/develop). Có 3 lý do chính tại sao lại như vậy:

\n
    \n
  1. Dễ dàng theo dõi: Giữ nguyên lịch sử phát triển giúp các thành viên trong nhóm dễ dàng theo dõi và hiểu các thay đổi đã được thực hiện.
    2. \n
  2. Giảm rủi ro xung đột: Khi kết hợp một nhánh hoàn chỉnh, việc giữ nguyên lịch sử phát triển giúp giảm rủi ro xung đột khi các thay đổi đã được kiểm thử và xác nhận.
    3. \n
  3. Dễ dàng khôi phục: Nếu cần khôi phục lại một phiên bản trước đó, việc giữ nguyên lịch sử phát triển giúp dễ dàng xác định và khôi phục các thay đổi đã được thực hiện.
    4. \n
\n

Dùng Rebase để cập nhật nhánh​

\n

Vì đặc điểm của rebase là di chuyển các commit của bạn lên trên cùng của nhánh đích và không tạo thêm commit mới, nên nó rất phù hợp để sử dụng khi bạn muốn cập nhật nhánh của mình với các thay đổi mới nhất từ nhánh chính (main/develop), hoặc từ các nhánh feature khác.

\n

Xem xét các ví dụ sau:

\n\n

Chúng đều là những trường hợp điển hình để sử dụng rebase. Đặc điểm chung là chúng không quá cần thiết phải giữ nguyên lịch sử phát triển của nhánh, mà quan trọng là cập nhật code mới nhất để làm việc hiệu quả.

\n

Làm sao để PRO?​

\n

PRO là khi bạn đã \"ăn hành\" đủ với merge và rebase, trải qua đủ các pha mất code, conflict, bị đồng đội cà khịa, rồi mới ngộ ra chân lý git! Dù không dám nhận là một git guru, nhưng dưới đây là vài chia sẻ của tôi sau khi đã lãnh đủ thứ conflict, mất code, mất thời gian, quở trách,... để bạn không phải trải qua những điều đó nữa.

\n

Cập nhật code đúng cách​

\n

Hãy dùng rebase để cập nhật code, dù nó có là từ nhánh chính hay từ nhánh feature khác đi chăng nữa. Trong quá trình này bạn rất có thể sẽ gặp conflict, hãy bình tĩnh giải quyết chúng từng bước một. Đây là cách tôi thường làm:

\n
git checkout feature/abc # <== nhánh bạn đang làm việc
git fetch origin main # <== lấy code mới nhất từ nhánh chính
git rebase origin/main # <== cập nhật nhánh của bạn với nhánh chính
\n

và voila, conflict:

\n
Auto-merging src/app.js
CONFLICT (content): Merge conflict in src/app.js
error: could not apply 1234abcd... Thêm chức năng đăng nhập
Resolve all conflicts manually, mark them as resolved with 'git add <file>', then run 'git rebase --continue'.
\n

=> mở IDE/editor của bạn lên, tìm file bị conflict, giải quyết chúng, sau đó:

\n
git add . # hoặc git add <tên_file>
git rebase --continue
\n

Lặp lại quá trình này cho đến khi rebase hoàn tất, hoặc dùng git rebase --abort để hủy nếu bạn thấy rối hoặc không chắc về điều mình đang làm.

\n

Đến đây thì 96,69% các trường hợp cập nhật code của bạn đã xong xuôi. Chỉ còn vài phần trăm còn lại là những trường hợp đặc biệt, ví dụ như bạn đang rebase mà phát hiện ra nhánh đích đã được squash (gộp commit) hoặc rebase rồi.

\n

Trong trường hợp này, bạn có thể làm theo các bước sau để xử lý:

\n
git fetch origin main # Lấy code mới nhất từ nhánh chính
git checkout feature/abc # Chuyển về nhánh của bạn
git rebase --onto origin/main <commit_hash_cũ> feature/abc
\n

Trong đó <commit_hash_cũ> là commit hash của commit cuối cùng trên nhánh feature/abc trước khi bạn bắt đầu rebase. Lệnh này sẽ giúp bạn di chuyển các commit của nhánh feature/abc lên trên cùng của nhánh main, bỏ qua các commit đã bị squash hoặc rebase. Tôi sẽ nói kỹ hơn về cách xử lý các trường hợp đặc biệt này trong một bài viết khác.

\n

Luôn kiểm tra lại với nhánh dev/main trước khi tạo Pull Request​

\n

Khi rebase trong trường hợp các nhánh đích đã được squash hoặc rebase mà tôi đề cập bên trên, hoàn toàn có thể xảy ra trường hợp bạn vô tình bỏ sót một số commit quan trọng. Hay nói một cách đơn giản là bạn đã làm mất code. Độ nghiêm trọng của việc này thì khỏi bàn. Nguy hiểm hơn là nó không để lại dấu vết gì trong lịch sử git cả, và bạn sẽ cực kỳ khó để phát hiện điều đó.

\n

Để tránh điều này, LUÔN LUÔN kiểm tra lại nhánh của bạn với nhánh dev/main trước khi tạo Pull Request. Cách đơn giản nhất là dùng lệnh:

\n
git diff origin/main...feature/abc
\n

hoặc dùng công cụ so sánh của IDE/editor bạn đang dùng.

\n

Nếu bạn phát hiện bị mất code, đừng hoảng loạn, hãy đọc bài viết này của tôi để xử lý like a pro: Cách khôi phục code đã mất trong Git

\n

Sử dụng Merge khi kết hợp nhánh hoàn chỉnh​

\n

Nếu bạn chịu trách nhiệm merge Pull Request, hãy sử dụng merge để kết hợp nhánh hoàn chỉnh vào nhánh chính (main/develop). Đó là lý do người ta gọi nó là \"Merge Pull Request\" chứ không phải \"Rebase Pull Request\".

\n

Lời kết​

\n

Tự hỏi bản thân trước thao tác cập nhật code: Bạn đang muốn kết hợp nhánh hoàn chỉnh, hay chỉ đơn giản là cập nhật nhánh của mình với những thay đổi mới nhất?

\n

Cái gì quan trọng thì phải nói lại lần nữa:

\n
\n

\"Merge dùng cho KẾT HỢP nhánh, Rebase dùng cho CẬP NHẬT nhánh.\"

\n
", "url": "https://daoanhthanh.vn/blog/use-merge-and-rebase-in-professional-way", "title": "Sử dụng Merge và Rebase một cách chuyên nghiệp", "summary": "Sử dụng Merge và Rebase trong Git một cách chuyên nghiệp", "date_modified": "2025-10-25T00:00:00.000Z", "author": { "name": "Đào Anh Thành", "url": "https://github.com/daoanhthanh" }, "tags": [ "git" ] }, { "id": "https://daoanhthanh.vn/blog/linux-file-permission", "content_html": "

Tìm hiểu về hệ thống quản lý, phân quyền cho file trong linux

\n\n

File permission​

\n

Trong linux, có 3 loại quyền cho file, đó là Read, Write và Execute.

\n\n
LettersDefinition
rCó quyền đọc nội dung file
wViết hoặc chỉnh sửa nội dung file
xThực thi file, nếu file đó có thể thực thi (*.sh, .v..v..)
\n

Permission Group​

\n

Ta có thể xem permission group của một file trong linux bằng lệnh sau:

\n
ls -l <file-name>
\n

ví dụ:

\n

\n

Hãy để ý 9 ký tự phần khoanh đỏ, đó chính là 'permission group' của file

\n

Đầu tiên, hãy nghĩ về chín ký tự nêu trên như là 3 tập hợp, mỗi tập hợp 3 ký tự. Mỗi tập hợp lần lượt định nghĩa quyền cho một đối tượng cụ thể, lần lượt như sau:

\n
rwxrw-r--
usergroupother
\n

Mỗi một tập hợp rwx định nghĩa những hành động khác nhau được phép làm với file tương ứng. Trong trường hợp với file sayHi.sh như ví dụ trên ảnh, ta có thể hiểu rằng:

\n
Nhóm quyềnĐối tượngCách hiểu
rwxuserNgười dùng (ở đây mang nghĩa 'owner') thanh_da - có toàn quyền đọc, sửa, và thực thi file.
rw-groupcác thành viên khác trong nhóm developers sẽ có quyền đọc và sửa file.
r--otherNhững người khác sẽ chỉ có quyền đọc
\n

Ví dụ:

\n

Nếu người đang đăng nhập là thanh_da, anh ấy có thể thực thi file như sau:

\n

\n

Giả sử trong nhóm developers có thêm một thành viên nữa:

\n

\"Hoặc Thì khi thực thi bằng normal_user, ta kỳ vọng hệ thống sẽ không cho phép vì ngoài thanh_da ra, không ai có quyền thực thi file. Cùng xem kết quả:

\n

\n

Vậy là ta đã thiết lập được kiến thức cơ bản về quyền của file trong linux.

\n

Chỉnh sửa file permission​

\n

Ta làm vậy bằng cách thêm hoặc bớt quyền cho một nhóm. Dưới đây là các phép toán hỗ trợ:

\n
OperatorsDefinition
+Thêm quyền
-Xóa quyền
=Gán quyền
\n

Thao tác như sau:

\n
    \n
  1. Đầu tiên gõ chmod <đối_tượng _muốn_chỉnh_sửa>. Ví dụ đối tượng ở đây là group:
    2. \n
\n
chmod g
\n
    \n
  1. Ta muốn đối tượng này được THÊM quyền execute:
    2. \n
\n
chmod g+x
\n
    \n
  1. Cuối cùng ta chỉ định file nào sẽ chịu tác động:
    2. \n
\n
chmod g+x ./sayHi.sh
\n

Sau thao tác trên, cùng xem lại thay đổi của nhóm quyền của file sayHi.sh

\n

--- TODO: chụp cái ảnh vào đây ---

\n

Ta có thể sửa nhiều nhóm quyền cùng lúc. Ví dụ, nếu bạn muốn xóa hết quyền cho toàn bộ mọi người, bạn làm như sau:

\n
chmod ugo-rwx ./sayHi.sh
\n

Lệnh bên trên sẽ lấy hết quyền đọc (r), ghi (w) và thực thi (x) từ tất cả người dùng (u), nhóm (g) và những người khác (o). Điều này áp dụng cho file sayHi.sh.

\n

Hoặc ta có thể gán nhiều nhóm với nhiều mức quyền khác nhau cùng lúc, ví dụ:

\n
chmod ug+rw,o-x abc.xyz
\n

Như trên là ta đang thêm quyền đọc (r), ghi (w) cho người dùng (u) và nhóm (g); cùng lúc xóa bỏ quyền thực thi (x) cho những người dùng khác (o).

\n

Lệnh sau:

\n
chmod ug=rw,o=x abc.d
\n

GÁN CHÍNH XÁC quyền đọc (r), ghi (w) cho người dùng (u) và nhóm (g); cùng lúc GÁN CHÍNH XÁC quyền thực thi (x) cho những người dùng khác (o).

\n

Điều này có nghĩa là bất kể trước đó user và group có những quyền gì, sau khi chạy lệnh trên sẽ chỉ còn quyền read và write. Tương tự với others, bất kể trước đó có quyền gì thì sau khi chạy lệnh, sẽ chỉ còn execute.

\n

Ví dụ như sau:

\n

--- TODO: thêm ảnh ---

\n

Octal notation​

\n

Một set quyền luôn là tập hợp rwx, do vậy ta có thể dùng hệ nhị phân 3-bit để biểu diễn chúng.

\n

Ví dụ:

\n
File permissionsBinary
rwx111
r-x101
r--100
\n

Và mỗi số nhị phân ta lại có thể biểu diễn bằng một số thập phân. Dưới đây là bảng chuyển đổi đầy đủ

\n
File ModeBinaryOctal
---0000
--x0011
-w-0102
-wx0113
r--1004
r-x1015
rw-1106
rwx1117
\n

Do vậy ta có thể thay thế operation bằng octal notation. Ví dụ, hai lệnh dưới đây là tương đương:

\n
chmod u=rwx,g=rx,o=r [file_name]
chmod 754 [file_name] # (owner: rwx(7), group: r-x(5), others: r–-(4)).
\n

hoặc

\n
chmod ugo+rwx [file_name] # thêm full quyền cho cả 3 nhóm
chmod 777 [file_name]     # tương đương lệnh phía trên
\n

hoặc thậm chí:

\n
chmod ug+rwx,o=rx [file_name]
chmod 775 [file_name]
\n

Việc phân quyền cho file cũng giống như phần quyền cho bất cứ hệ thống nào khác, cần tuân thủ [[Principle of Least Privilege PoLP]] - Nguyên tắc đặc quyền tối thiểu - để giảm tối đa rủi cho cho hệ thống khi có nhiều người cùng thao tác.

", "url": "https://daoanhthanh.vn/blog/linux-file-permission", "title": "Linux file permissions", "summary": "Linux file permissions", "date_modified": "2024-12-21T00:00:00.000Z", "author": { "name": "Đào Anh Thành", "url": "https://github.com/daoanhthanh" }, "tags": [ "linux" ] }, { "id": "https://daoanhthanh.vn/blog/chuyen-thu-nhap-va-zig", "content_html": "

Mơ ước của đa số sinh viên mới tốt nghiệp, đặc biệt trong lĩnh vực Công nghệ Thông tin, là tìm kiếm một công việc có mức lương hấp dẫn. Là một lập trình viên trẻ, tôi cũng không nằm ngoài xu thế này. Chính vì vậy, tôi nhận thấy vấn đề này vô cùng thú vị và đáng để thảo luận sâu sắc.

\n\n

Như một thói quen, mỗi đầu năm tôi đều lên kế hoạch lớn cho năm đó, gồm mục tiêu thu nhập, phát triển bản thân và gia đình. Một trong những thống kê tôi đọc là thu nhập của các lập trình viên khác trên thế giới.

\n

\"interface\"

Top 15 ngôn ngữ lập trình có mức lương cao nhất theo khảo sát của Stack Overflow. Chi tiết xem\ntại\nđây.

\n

Khảo khảo sát trên gồm gần 50.000 lập trình viên tham gia

", "url": "https://daoanhthanh.vn/blog/chuyen-thu-nhap-va-zig", "title": "Chuyện thu nhập và Zig", "summary": "Zig là một ngôn ngữ lập trình mới, nhưng lương của lập trình viên Zig lại cao hơn so với các ngôn ngữ khác. Bài viết này sẽ giải thích lý do tại sao lương lập trình viên Zig lại cao.", "date_modified": "2024-09-13T00:00:00.000Z", "author": { "name": "Đào Anh Thành", "url": "https://github.com/daoanhthanh" }, "tags": [ "zig" ] }, { "id": "https://daoanhthanh.vn/blog/ports-and-adapters-architecture-in-net-core", "content_html": "

Gần đây tôi có tiếp xúc với C#, cảm thấy ngôn ngữ này khá thú vị và mạnh mẽ. Điều đầu tiên tôi muốn làm khi học C# là tìm hiểu về thiết kế DDD và cách triển khai nó trong .NET Core. Trong bài viết này, tôi sẽ chia sẻ về kiến trúc Ports & Adapters - một cách implement DDD trong .NET Core.

\n\n

Trước khi bắt đầu​

\n

Bạn nên có kiến thức nền về c# và dotnet: cách làm việc với dotnet cli (hoặc có thể dùng Visual Studio), hiểu được các thuật ngữ (subproject, dependencies, reference) và trên hết là sự tò mò.

\n

Một kiến trúc nữa ư? Chẳng phải MVC đã là đủ rồi sao?​

\n

Trước hết hãy cùng nói về MVC. Chắc hẳn đây là kiến trúc đầu tiên mà mọi lập trình viên được tiếp xúc khi làm việc với web. Nó một kiến trúc phần mềm chia ứng dụng thành 3 phần độc lập với mục đích khác nhau: Model, View, Controler.

\n

\"MVC\"\n

Mô tả luồng đi của dữ liệu trong mô hình MVC

\n

Luồng đi của ứng dụng sẽ như sau:

\n
    \n
  1. Dựa vào URL, request sẽ được gửi đến Controller tương ứng để xử lý. Controller là nơi nhận và validate meta data của request (như quyền của người gửi, validate các trường trong request,..)
    2. \n
  2. Controller gửi yêu cầu xử lý data đến Model. Model là nơi xử lý mọi logic liên quan đến request bao gồm cả việc kết nối với DB. Controller không bao giờ nên kết nối trực tiếp với DB hay xử lý logic. Trong trường hợp xảy ra lỗi, Controller nên là thành phần xử lý lỗi đó để trả cho người dùng. Hay nói cách khác, tất cả logic liên quan đến tương tác người dùng đều được xử lý bởi Controller.
    3. \n
  3. Sau khi nhận lại dữ liệu từ Model, Controller sẽ kết nối đến View để render data trả cho người dùng. View chỉ có tác dụng render giao diện dựa trên data được trả bởi controller và không có xử lý gì thêm.
    4. \n
\n

Không thể phủ nhận MVC là một kiến trúc hiệu quả. Nhiệm vụ của MVC là phân tách View - Controller - Model, như tên gọi của nó, trong một ứng dụng web, khiến chúng độc lập và dễ bảo trì. Tuy nhiên đây là kiến trúc áp dụng khi source code bao gồm luôn 2 phần: back-end (do Controller và Model đảm nhiệm) và front-end (do View đảm nhiệm).

\n

Hơn nữa với những dự án lớn, việc logic xử lý chỉ được chia thành Controller và Model chắc chắn không thể đủ để đảm bảo dự án có thể dễ mở rộng và bảo trì.

\n

Do đó, trong trường hợp source code tách làm 2 phần BE và FE, ta cần một kiến trúc khác áp dụng cho từng phần. Trong giới hạn của bài viết này, tôi sẽ giới thiệu một kiến trúc thường được dùng cho phía BE: Ports & Adapters

\n

Ports & Adapters là gì?​

\n

Ports & Adapters - P&A - (hay còn được gọi là Hexagonal Architecture - thú thực tôi không thích cái tên này lắm) là một kiến trúc phần mềm tuân theo nguyên lý thiết kế tập trung vào chủ thể. Có thể bạn đã nghe qua cái tên DDD (Domain-Driven Design). Hiểu đơn giản, DDD là tập hợp các nguyên tắc, mẫu thiết kế hệ thống giúp team bạn phát triển phần mềm một cách dễ dàng và hiệu quả. Ports & Adapters là một trong những cách triển khai code base để tuân thủ những ý tưởng của DDD.

\n

\"DDD\n

DDD là ý tưởng/nguyên tắc, còn Ports & Adapters là một cách triển khai

\n

Triển khai kiến trúc Port & Adapter trong .NET Core​

\n

Thế cụ thể, ý tưởng của Ports & Adapters là gì?​

\n

Trước tiên hãy nói một chút về cách tiếp cận vấn đề của MVC. Một góc nào đó, kiến trúc này vẫn mang theo ý tưởng của DDD: bạn có model là những class mô tả tất cả những chủ thể mà ứng dụng làm việc với (vd: config, người dùng, hàng hoá, xe cộ,...). Bạn có service để xử lý mọi nghiệp vụ liên quan đến domain. Ta thường tách Service ra thành - tạm gọi - Service_Interface và Service_Implementation để tối đa trạng thái loosely coupling.

\n

Tuy nhiên, mô hình của MVC có một vấn đề: nó không có cơ chế hạn chế việc gọi lẫn nhau giữa bất kỳ thành phần nào. Hay nói cách khác, các thành phần không được hoàn toàn tách biệt do vậy một developer có thể thoải mái truy cập database từ controller. Điều này rất tệ trong dự án lớn vì nó có thể tạo tiền lệ và phá vỡ kiến trúc tổng thể. Ai mà biết được liệu anh ta có validate và serialize response chuẩn không cơ chứ.

\n

Do vậy một kiến trúc tốt cần có cơ chế tách biệt hẳn các thành phần trong luồng đi của dữ liệu đồng thời bắt buộc chúng phải nằm trong luồng đi đó. Nói một cách đơn giản: kiến trúc tốt phải khiến dev dù có muốn, họ cũng không thể nào:

\n
    \n
  1. Truy cập trực tiếp Service_Implementation từ Controller mà không thông qua Service_Interface
    2. \n
  2. Gọi thẳng Database từ Controller.
    3. \n
\n

\"Lazy\n

Người duy nhất ngăn điều này xảy ra là code reviewer

\n

Đây là lý do mà những kiến trúc như P&A tồn tại. Thứ nhất nó phân tách các thành phần trong source code để đảm bảo chúng loosely coupled. Thứ hai nó đảm bảo luồng đi của dữ liệu theo một cấu trúc đồng nhất, dễ đọc dễ bảo trì và dễ mở rộng.

\n

\"PowerPlant\"

\n
\n

Hãy hình dung P&A như một mô hình sản xuất điện. Bên yêu cầu là cái quạt, gửi yêu cầu bằng cách cắm phích vào ổ điện. Nhà máy điện là nơi cung cấp dịch vụ điện cho bạn và họ có thể lấy điện từ nhiều nguồn: thuỷ điện hoặc nhiệt điện chẳng hạn.

\n
\n

Tôi sẽ sử dụng Driving Adapters, Driving Ports để ám chỉ phía yêu cầu. Driven Adapter, Driven Ports để nói về bên thực hiện yêu cầu.

\n

\"PowerPlant2\"

\n

Với việc phân chia như trên, giờ luồng đi của dữ liệu đã rõ ràng hơn. Phích cắm không thể lấy điện bằng cách chọc thẳng vào motor phát điện - cũng giống như bạn không thể nào truy cập thẳng vào DB mà không thông qua Service. Đồng thời ta không thể bỏ qua bất kỳ interfaces nào do chúng đều là một mắt xích trong mạng lưới, do đó cấu trúc tổng thể của chương trình được đảm bảo. Hãy cùng xem ta có thể implement kiến trúc thú vị này như thế nào với .NET Core.

\n

Đó là lý thuyết, giờ hãy implement nó trong code​

\n

Chúng ta sẽ triển khai P&A qua một dự án CRM nhỏ. Tính năng cần có:

\n\n
\n

Tôi sẽ không tập trung vào logic xử lý trong bài viết này để tập trung nhấn mạnh vào kiến trúc. Hãy tham khảo source code ở phần cuối bài viết.

\n
\n

Cấu trúc thư mục là cách trực quan nhất để trình bày kiến trúc, do vậy hãy bắt đầu với nó.

\n

Tham khảo cấu trúc thư mục dưới đây:

\n
.
├── Adapter
│   ├── In
│   │   ├── APIs
│   │   │   ├── GraphQL
│   │   │   └── RestfulAPI
│   │   └── CLI
│   └── Out
│       ├── Databases
│       │   ├── Postgres
│       │   └── Redis
│       └── ThirdPartyLibs
└── Application
    ├── Domain
    │   ├── Domain.Core
    │   ├── Domain.Services
    │   └── Domain.Services.Tests
    └── Ports
        ├── In
        └── Out
\n

Hãy bắt đầu với Adapter, ta có 2 thư mục In và Out tương ứng với Driving Adapter và Driven Adapter (bên gửi - bên xử lý yêu cầu). Trong In ta nhận 2 dạng yêu cầu: qua command line, và qua http gồm hai giao thức: GraphQL và RestfulAPI. Tương tự như vậy với Out ta cần giao tiếp với 2 dạng hệ thống bên ngoài: Databases và các loại khác.

\n

Phần còn lại của kiến trúc được gộp trong thư mục Application. Đây là nơi chứa Domain và Ports - thứ chịu trách nhiệm giao tiếp với thế giới bên ngoài nên cũng cần 2 thư mục In/Out tương ứng.

\n

Khi bạn đã hiểu cấu trúc thư mục, sử dụng lệnh dưới đây để khởi tạo dự án:

\n
# Create solution
dotnet new sln -o Ports-and-Adapters-Demo && cd Ports-and-Adapters-Demo

# Create projects
dotnet new classlib -n Adapter.GraphQL -o Adapter/In/APIs/GraphQL
dotnet new classlib -n Adapter.RestfulAPI -o Adapter/In/APIs/RestfulAPI
dotnet new classlib -n Adapter.CLI -o Adapter/In/CLI

dotnet new classlib -n Adapter.Redis -o Adapter/Out/Databases/Redis
dotnet new classlib -n Adapter.Postgres -o Adapter/Out/Databases/Postgres
dotnet new classlib -n Adapter.ThirdPartyLibs -o Adapter/Out/ThirdPartyLibs

dotnet new classlib -n Domain.Core -o Application/Domain/Domain.Core
dotnet new classlib -n Domain.Services -o Application/Domain/Domain.Services
dotnet new xunit -n Domain.Services.Tests -o Application/Domain/Domain.Services.Tests

dotnet new classlib -n Ports.In -o Application/Ports/In
dotnet new classlib -n Ports.Out -o Application/Ports/Out

# Add all projects to solution
dotnet sln add **/*.csproj
\n

Để đảm ràng buộc phụ thuộc giữa các subproject với nhau cần thêm reference cho các project, sử dụng lệnh sau:

\n
# services depends on domain
dotnet add **/Domain.Services.csproj reference **/Domain.Core.csproj **/Ports.Out.csproj **/Ports.In.csproj
dotnet add **/Domain.Services.Tests.csproj reference **/Domain.Core.csproj **/Domain.Services.csproj

# adapters depends on domain and ports.
dotnet add **/Adapter.GraphQL.csproj reference **/Domain.Core.csproj **/Ports.In.csproj
dotnet add **/Adapter.RestfulAPI.csproj reference **/Domain.Core.csproj **/Ports.In.csproj
dotnet add **/Adapter.CLI.csproj reference **/Domain.Core.csproj **/Ports.In.csproj

dotnet add **/Adapter.Redis.csproj reference **/Domain.Core.csproj **/Ports.Out.csproj
dotnet add **/Adapter.Postgres.csproj reference **/Domain.Core.csproj **/Ports.Out.csproj
dotnet add **/Adapter.ThirdPartyLibs.csproj reference **/Domain.Core.csproj **/Ports.Out.csproj

#ports depend on domain
dotnet add **/Ports.In.csproj reference **/Domain.Core.csproj
dotnet add **/Ports.Out.csproj reference **/Domain.Core.csproj
\n
\n

Có một lưu ý nhỏ khi bạn đặt thư mục với tên Out (viết hoa chữ đầu) như ví dụ trên: nó khiến git nhầm lẫn tên với thư mục out. Khi bạn ignore thư mục out (đây là nơi chứa những file được runtime c# tạo ra trên máy bạn, và bạn nên ignore nó), git có thể lẫn với thư mục Out (viết hoa chữ đầu) dẫn đến code không được commit. Khắc phục như sau: bật case-sensitive trong config của git với lệnh sau git config core.ignorecase false và định nghĩa thư mục cần ignore với case sentitive. Ví dụ: **/[o]ut sẽ ignore tất cả các thư mục out (viết thường) và giữ lại Out.

\n
\n

Kinh nghiệm của tôi cho thấy rằng nếu sử dụng DDD nói chung và kiến trúc P&A nói riêng, ta nên có thêm một thành phần nữa để kiểm soát tất cả các thành phần còn lại. Đây sẽ là project chứa file main (hoặc Project.cs trong ngữ cảnh của .NET) - điểm khởi tạo của ứng dụng và là nơi chứa config cho toàn bộ dự án.

\n

Tôi sẽ gọi project đó là Src, bạn tham khảo lệnh dưới để tạo Src:

\n
dotnet new web -n Src
dotnet sln add Src/Src.csproj
dotnet add Src/Src.csproj reference **/*.csproj
dotnet remove Src/Src.csproj reference Src/Src.csproj # prevent circle loop
\n

Sau cùng ta sẽ có cây phụ thuộc như hình dưới:

\n

\"dev-tree\"

\n

Cách các thành phần liên kết với nhau​

\n

Để đơn giản, tôi sẽ demo một logic mà hệ thống nào cũng cần có: Đăng nhập. Cách triển khai chi tiết xin hãy xem repo đặt ở cuối bài.

\n

Luồng đi sẽ là:

\n
Người dùng => Gửi request => Controler (Adapter) => Port In => Domain Service => Port Out => Database (Adapter)
\n

Đầu tiên cần có controller:

\n
using Ports.In;
namespace Adapter.RestfulAPI;

[Route(\"api/v{version:apiVersion}\")]
public class LoginController(
    IAuthenticator authenticator,
) : RestfulControllerBase
{
    [HttpPost(\"login\")]
    public Task<IActionResult> Login([FromBody] LoginForm form)
    {
        // Handle login request
    }
}
\n

Kế tiếp cần tạo 1 driving port tương ứng cho controller này. Theo quy ước đặt tên của .Net, ta sẽ gọi đó là IAuthenticator:

\n
namespace Ports.In;

public interface IAuthenticator
{
    public Task<SessionUser> Login(string phoneOrEmail, string password);
}
\n

Ta cần service cho interface đó, tôi tạm gọi Authenticator. Class này sẽ nằm trong Domain.Services:

\n
using Ports.In;
namespace Domain.Services;

public class Authenticator(
    IUserRepository repo,
    IPassword pwdService,
    ICache cache
    ) : IAuthenticator
{
    public async Task<SessionUser> Login(string phoneOrEmail, string password)
    {
        // Thực hiện logic login
    }
}
\n

Ta đang thiếu các domain class đại diện cho đối tượng tham gia quá trình login. Hãy thêm nó trong Domain.Core

\n
namespace Domain.Core;

// SessionUser.cs
public class SessionUser
{
    // Định nghĩa Entity cần trả cho client khi đăng nhập thành công
}

// User.cs
[Table(\"Users\")]
public class User : EntityAudit
{
    // Định nghĩa entity user - thứ sẽ được lưu trong Db
}
\n

Ta cần một port out tham gia vào quá trình này. Service sẽ cần một bên chịu trách nhiệm lấy thông tin từ DB. Hãy tạo nó trong project Ports.Out:

\n
namespace Ports.Out;

public interface IUserRepository
{
    Task<User?> FindByPhoneOrEmail(string phoneOrEmail, bool includePassword = false);
}
\n

Component cuối cùng tham gia quá trình này là driven adapter. Trong luồng đi của dữ liệu, đây sẽ thành phần chịu trách nhiệm gửi yêu cầu ra hệ thống bên ngoài, trong trường hợp này là triển khai giao tiếp với DB.

\n
using Ports.Out;
namespace Adapter.Database.Postgres;

public class UserRepository(
    PostgresRootDbContext context
) : Repository<DomainModel.User>(context), IUserRepository
{
    public Task<DomainModel.User?> FindByPhoneOrEmail(string phoneOrEmail, bool includePassword)
    {
        // Kết nối với Db để query dữ liệu
    }
}
\n

Giản lược các phần không liên quan, đây là cây thư mục sau khi implement:

\n
.
├── Adapter
│   ├── In
│   │   ├── APIs
│   │       ├── GraphQL
│   │       └── RestfulAPI
│   │           └── LoginController.cs
│   └── Out
│       ├── Databases
│           ├── Postgres
│               └── UserRepository.cs
│
├── Application
    ├── Domain
    │   ├── Domain.Core
    │   │   ├── SessionUser.cs
    │   │   └── User.cs
    │   ├── Domain.Services
    │       └── Authenticator.cs
    │  
    └── Ports
        ├── In
        │   └── IAuthenticator.cs
        └── Out
            └── IUserRepository.cs
\n

Bạn đạt được 4 thứ khi áp dụng kiến trúc trên vào dự án:

\n
    \n
  1. Dễ đọc, dễ hình dung luồng đi của dữ liệu
    2. \n
  2. Có sự ràng buộc nhất định giữa các thành phần với nhau hình thành một luồng đi thống nhất. Bạn không thể bỏ qua bất kì bước nào để đi tắt và do đó, kiến trúc code sẽ đồng nhất. Lại thêm một lý do nữa cho việc dễ đọc.
    3. \n
  3. Dễ kiểm thử, bảo trì. Các thành phần được chia nhỏ theo chức vụ do vậy hạn chế tối đa side effects. Việc unit test giờ đây rất dễ dàng vì sự liên kết lỏng lẻo (Loose coupling) giữa các phần với nhau.
    4. \n
  4. DDD được thiết kế cho việc dễ mở rộng, điều này cũng đúng với kiến trúc Ports & Adapters. Như một lẽ tất nhiên, khi bạn dễ đọc code, dễ bảo trì thì code sẽ rất dễ dàng để mở rộng.
    5. \n
\n
\n

Đây là dự án mẫu tôi đã tạo ra để giúp bạn hiểu hơn về cách implement P&A trong .NET. Chúc bạn code vui 🥰🥰

\n
", "url": "https://daoanhthanh.vn/blog/ports-and-adapters-architecture-in-net-core", "title": "Kiến trúc 'Ports and Adapters' trong .NET Core", "summary": "Một cách implement DDD trong .NET Core sử dụng kiến trúc Port & Adapter.", "date_modified": "2024-08-20T00:00:00.000Z", "author": { "name": "Đào Anh Thành", "url": "https://github.com/daoanhthanh" }, "tags": [ ".NET", "architecture" ] }, { "id": "https://daoanhthanh.vn/blog/amber-rat-tien-dung-cho-cicd", "content_html": "

Tôi yêu bash, nó rất tiện dụng để viết những script nhỏ chạy tự động, đặc biệt là cho CI/CD. Tuy nhiên, thú thực không phải lúc nào tôi cũng nhớ hết syntax của bash, và tôi luôn mong muốn có một công cụ nào đó giúp tôi viết bash script một cách dễ dàng hơn. Cảm ơn trời, Amber đã xuất hiện. Trong bài viết này tôi muốn chia sẻ về Amber và cách nó đã khiến việc lập trình bash trở nên thú vị hơn.

\n\n

Amber là gì?​

\n

Chắc chắn không phải tên của vợ ông thuyền trưởng nào đó, Amber được giới thiệu là một ngôn ngữ biên dịch được viết bằng rust, giúp biên dịch code sang bash. Theo như giới thiệu trên trang chủ:

\n

Amber là ngôn ngữ lập trình được biên dịch thành Bash Script. Nó được thiết kế với cú pháp hiện\nđại, các tính năng an toàn, typesafe và các chức năng thiết thực mà Bash không thể cung cấp.\nAmber

\n

Tóm cái váy lại, Amber là một lớp bổ sung typesafe cho bash script. Nó giống như trường hợp của Typescript và Javascript vậy. Bạn có thể tìm hiểu kỹ hơn về syntax của Amber ở trang chủ.

\n

Cài đặt Amber​

\n\n

Sử dụng Amber​

\n

Trước tiên, nếu bạn sử dụng VsCode, hãy thêm extension này để làm việc với Amber dễ dàng hơn: Amber Language. Nếu bạn biết các công cụ nào hỗ trợ vim/Sublime/Zed, hãy chia sẻ với tôi nhé.

\n

Làm quen với Amber khá đơn giản do syntax được dựa trên ECMA script.

\n
// example.ab

let target = \"my friend\"

let message = \"Hello, {target}! Want some Shawarma?\"
let repeated_times = 3

// In ra câu chào
loop i in 0..repeated_times {
    echo message
}

let age = 10

// If-else
if age < 18 {
    echo \"\\nI want za spicy garlic!\\n\"
} else {
    echo \"\\nI want za regular garlic!\\n\"
}

// array loop
let fruits = [\"apple\", \"banana\", \"cherry\", \"date\"]
echo \"My favorite fruits are:\"
loop fruit in fruits {
    echo fruit
}
\n

Để chạy script trên, sử dụng lệnh sau:

\n
amber example.ab
\n

Nó sẽ biên dịch code sang bash và chạy nó. Kết quả sẽ như sau:

\n
Hello, my friend! Want some Shawarma?
Hello, my friend! Want some Shawarma?
Hello, my friend! Want some Shawarma?

I want za spicy garlic!

My favorite fruits are:
apple
banana
cherry
date
\n

Điều tuyệt vời ở đây là amber hỗ trợ compile file sang bash script. Bạn có thể sử dụng output của nó để chạy trên bất kỳ môi trường unix nào.

\n
amber input.ab output.sh
\n

Thử với file ví dụ bên trên (amber example.ab example.sh), đây là file bash script được tạo ra:

\n
__0_target=\"my friend\";
__1_message=\"Hello, ${__0_target}! Want some Shawarma?\";
__2_repeated_times=3;

for i in $(seq 0 $(echo ${__2_repeated_times} '-' 1 | bc -l | sed '/\\./ s/\\.\\{0,1\\}0\\{1,\\}$//'))
do
    echo \"${__1_message}\"
done;

__3_age=10;

if [ $(echo ${__3_age} '<' 18 | bc -l | sed '/\\./ s/\\.\\{0,1\\}0\\{1,\\}$//') != 0 ]; then
    echo \"
I want za spicy garlic!
\"
else
    echo \"
I want za regular garlic!
\"
fi;

__AMBER_ARRAY_0=(\"apple\" \"banana\" \"cherry\" \"date\");
__4_fruits=(\"${__AMBER_ARRAY_0[@]}\");

echo \"My favorite fruits are:\";

for fruit in \"${__4_fruits[@]}\"
do
    echo \"${fruit}\"
done
\n

Bạn có thể chạy trực tiếp file trên vì trong quá trình biên dịch Amber đã tự động gán quyền execute cho nó. Thật tuyệt 🎉🎉!

\n

Bỏ qua việc đặt tên biến, bạn có thể thấy cú pháp của Amber dễ đọc hiểu hơn so với bash rất nhiều. Điều này giúp bạn viết script nhanh hơn, dễ đọc hơn và dễ bảo trì hơn.

\n

Tuy nhiên nếu tinh ý bạn có thể thấy Amber xử lý logic loop chưa tốt ở thời điểm hiện tại. Như ví dụ phía trên, Amber đã sử dụng:

\n
if [ $(echo ${__3_age} '<' 18 | bc -l | sed '/\\./ s/\\.\\{0,1\\}0\\{1,\\}$//') != 0 ]; then
# execute logic
\n

Syntax trên cồng kềnh cộng thêm sử dụng thư viện ngoài (bc). Chắc chắn điều này sẽ chậm và khó đọc hơn so với cách loop truyền thống ở dưới:

\n
for ((i=0; i < repeated_times; i++)); do
   # execute logic
done
\n

Do vậy ở thời điểm hiện tại, nếu bạn sử dụng loop trong dự án của mình, bạn cần kiểm tra và viết lại bash script để cải thiện hiệu năng nếu cần thiết.

\n

Tính năng nổi bật​

\n

Hỗ trợ typesafe​

\n

Tôi từng viết một script khá dài để deploy microservices lên k8s, dẫn đến việc không kiểm tra type khi gán giá trị cho biến. Tôi đã gán string cho một biến đáng nhẽ là int và thực hiện tính toán, kết quả là chạy sai và tôi đã mất khá nhiều thời gian để debug xem lỗi nằm ở đoạn nào.

\n

Ở Amber, bạn không thể làm điều đó. Compiler sẽ báo lỗi khi bạn gán sai kiểu vào biến, ví dụ:

\n
// test.ab

let int = 5
let string = \"hi\"

let composed = int + string
echo composed
\n

Bạn sẽ gặp lỗi ngay thời điểm compile amber test.ab test.sh:

\n

\"amber\n

Lỗi xảy ra khi thực hiện cộng một số với string

\n

Điều này sẽ tránh cho bạn khỏi phiền phức về sau khi mà code base mở rộng. Với tất cả tính năng của typesafe, script của bạn sẽ dễ đọc và bảo trì hơn.

\n

Handle exception dễ dàng hơn​

\n

Hãy thử xem xét trường hợp sau, khi thực hiện một hàm bị trả về lỗi sẽ gọi một hàm khác để xử lý:

\n
#!/bin/bash

message=\"$(command_returns_error)\"

# 'set -e' nếu muốn dừng chương trình

if [ $? -ne 0 ]; then
    do_another_command
fi

# ...
\n

Thành thực mà nói, cú pháp trên hơi khó để hiểu cho người maintain. Nếu bạn không biết [ $? -ne 0 ] là gì thì thật khó để hiểu được luồng của script. Cùng xem liệu Amber có xử lý tốt hơn không:

\n
command_returns_error() failed {
    do_another_command()
}
\n

Gọn và dễ đọc hơn nhiều

", "url": "https://daoanhthanh.vn/blog/amber-rat-tien-dung-cho-cicd", "title": "Giới thiệu Amber - Rất tiện dụng cho CI/CD", "summary": "Giới thiệu về Amber - rất tiện dụng cho CI/CD", "date_modified": "2024-08-13T00:00:00.000Z", "author": { "name": "Đào Anh Thành", "url": "https://github.com/daoanhthanh" }, "tags": [ "amber-lang", "ci/cd" ] }, { "id": "https://daoanhthanh.vn/blog/cache-penetration-and-cache-invalidation", "content_html": "

Tôi yêu cache và các hệ thống lớn cũng vậy. Nó giảm tải workload cho server do đó tăng tốc quá trình xử lý, do vậy thời gian phản hồi sẽ nhanh hơn. Tuy nhiên điều gì cũng có hai mặt và với cache, đó là tính toàn vẹn dữ liệu. Hãy cùng phân tích nó qua hai vấn đề Cache Penetration (xâm nhập bộ đệm) và Cache invalidation (vô hiệu hoá bộ đệm)

", "url": "https://daoanhthanh.vn/blog/cache-penetration-and-cache-invalidation", "title": "Cache penetration và cache invalidation", "summary": "Cache penetration và cache invalidation là hai vấn đề mà bạn cần quan tâm khi sử dụng cache trong ứng dụng của mình.", "date_modified": "2024-05-20T00:00:00.000Z", "author": { "name": "Đào Anh Thành", "url": "https://github.com/daoanhthanh" }, "tags": [ "cache", "redis" ] } ] }