SEOMONEY

Nhà siêu mỏng, siêu méo: các nước châu Á xử lý ra sao?

Unknown — Mon, 22 Jun 2026 00:00:00 +0000

Mỗi lần đi qua những tuyến đường mới mở ở Hà Nội, tôi lại bắt gặp những căn nhà chỉ rộng hơn một mét, mặt tiền vát chéo như một lát bánh, đứng chênh vênh sát mép vỉa hè. Người ta quen gọi đó là nhà "siêu mỏng, siêu méo". Nhìn thì lạ mắt, nhưng đằng sau nó là cả một bài toán quy hoạch đô thị mà không riêng gì Việt Nam phải đau đầu. Điều thú vị là nhiều quốc gia châu Á đã đi trước chúng ta vài chục năm trong việc xử lý vấn đề này, và cách họ làm cho thấy đây không phải chuyện "phạt cho tồn tại" hay vận động suông là giải quyết được.

Vì sao nhà siêu mỏng, siêu méo cứ sinh ra?</h2>
Trước khi bàn cách xử lý, cần hiểu gốc rễ. Loại nhà này gần như luôn là sản phẩm phụ của quá trình đô thị hóa nhanh cộng với việc mở đường. Khi nhà nước cắt một phần thửa đất để làm hạ tầng, phần còn lại của người dân thường rất nhỏ hoặc có hình dạng méo mó. Đáng lẽ những mảnh đất đó nên được gộp lại hoặc thu hồi nốt, nhưng vì giá bất động sản ở đô thị lớn quá cao, người dân vẫn cố giữ và cố xây.
Đây chính là điểm mấu chốt: khi từng mét vuông đất mặt phố có giá trị khổng lồ, người ta sẽ tìm mọi cách tận dụng, kể cả trên một mảnh đất chỉ vài mét vuông. Vậy nên giải pháp bền vững không nằm ở chỗ cấm đoán, mà nằm ở chỗ thiết kế lại luật chơi về đất đai ngay từ đầu. Ba nền kinh tế lớn của châu Á — Nhật Bản, Hàn Quốc và Trung Quốc — đã tiếp cận vấn đề theo những hướng có nhiều điểm để chúng ta suy ngẫm.

Nhật Bản: quản chặt điều kiện xây dựng và tái điều chỉnh đất đai</h2>
Nhật Bản là quốc gia có mật độ dân số rất cao, nên những căn nhà siêu nhỏ, siêu mỏng, méo mó là chuyện không hiếm. Điều đáng nói là nước này không chọn cách cấm hoàn toàn. Thay vào đó, họ dựng lên một bộ quy định chi tiết và chặt chẽ về việc xây nhà trên các mảnh đất nhỏ, hẹp, hình dáng bất thường.
Các quy định ấy không xoáy vào chuyện thẩm mỹ, mà tập trung vào những thứ thiết thực hơn: an toàn phòng cháy, khả năng tiếp cận khi có tình huống khẩn cấp, khả năng chống chịu động đất và bảo đảm sự thông thoáng cho những căn nhà lân cận. Nói cách khác, nếu thửa đất không đáp ứng được các điều kiện an toàn tối thiểu, chủ đất sẽ không được phép xây mới hay sửa lại nhà cũ. Đây là cách dùng tiêu chuẩn an toàn để gián tiếp loại bỏ những công trình bất hợp lý, thay vì chỉ phạt sau khi đã xây xong.
Bên cạnh đó, theo báo cáo của Tổ chức Hợp tác và Phát triển Kinh tế (OECD)</a> được trích trong nội dung tham khảo, "tái điều chỉnh đất đai" là công cụ được dùng rộng rãi trong quy hoạch đô thị Nhật Bản. Cơ chế này thu gom các mảnh đất liền kề thành một khu đất lớn, sau đó quy hoạch lại để dành không gian cho hạ tầng công cộng rồi chia lại đất cho các chủ cũ một cách công bằng nhất có thể.
Kết quả là người dân thường nhận lại mảnh đất nhỏ hơn ban đầu, nhưng vuông vắn hơn, còn phần đất dư ra được dùng cho đường sá, công viên, tiện ích chung. Để một dự án kiểu này được triển khai, nó cần sự đồng thuận của khoảng hai phần ba chủ đất. Trên lý thuyết, người dân tuy mất một phần diện tích nhưng đổi lại được sống trong khu vực quy hoạch khoa học hơn. Dĩ nhiên, mô hình này cũng vấp phản ứng trái chiều nếu người dân thấy việc chia lại đất chưa thực sự công bằng — và đó là điều bất kỳ nơi nào muốn áp dụng cũng phải tính tới.

Hàn Quốc: chặn từ gốc và buộc nhà nước mua lại đất dư</h2>
Câu chuyện ở Hàn Quốc bắt đầu từ những năm 1960, khi Seoul đô thị hóa với tốc độ chóng mặt. Nhà nước mở đường, thu hồi một phần đất, và phần còn lại của người dân trở nên nhỏ, méo. Đến nay, do giá bất động sản tại các đô thị lớn vẫn rất cao, những căn nhà mỏng và nhỏ vẫn tồn tại.
Cách Hàn Quốc xử lý đáng chú ý ở chỗ họ đánh vào cả hai đầu của vấn đề. Đầu thứ nhất là ngăn chia nhỏ đất: luật quy định không cho phép chia một thửa lớn thành những mảnh quá bé hoặc không vuông vắn, bởi chính việc chia cắt tùy tiện mới sinh ra nhà siêu mỏng. Với từng loại nhà, Hàn Quốc đặt ra diện tích đất tối thiểu cụ thể để được xây dựng.
Đầu thứ hai là xử lý phần đất dư sau khi mở đường. Nếu mảnh đất còn lại trở nên khó sử dụng cho mục đích ban đầu, chủ sở hữu có quyền yêu cầu cơ quan thực hiện dự án mua lại phần đất đó. Sau khi dự án được chấp thuận, họ thậm chí có thể yêu cầu hội đồng có thẩm quyền tiến hành trưng thu phần đất này. Tiêu chí xác định "đất dư" rất rõ: diện tích còn lại quá nhỏ, hoặc hình dạng quá méo khiến việc xây dựng là bất khả thi hoặc cực kỳ khó khăn. Nếu giá trị phần đất còn lại bị giảm do bị thu hồi một phần, chủ đất được bồi thường tương ứng.
Tôi cho rằng đây là điểm sáng nhất trong mô hình Hàn Quốc. Thay vì để người dân ôm một mảnh đất "không xây được mà bán cũng chẳng ai mua", luật trao cho họ một lối thoát hợp lý: được mua lại, được bồi thường. Nhờ vậy, động cơ cố xây một căn nhà méo mó trên mảnh đất vô dụng gần như bị triệt tiêu. Ngoài ra, Hàn Quốc cũng dùng cơ chế hợp thửa để tái định cư — thu hồi các mảnh nhỏ, méo, quy hoạch lại thành khu lớn có tiện ích rồi chia lại cho người dân.
Trung Quốc: trao quyền cho địa phương và khuyến khích gộp thửa</h2>
Các thành phố lớn của Trung Quốc cũng đối mặt với tình trạng tương tự khi mở đường, làm dự án khiến nhiều thửa đất bị cắt còn lại phần nhỏ, méo. Khác với Nhật và Hàn, Trung Quốc không có một luật riêng quy định về loại nhà này ở cấp quốc gia. Thay vào đó, từng địa phương tự đặt quy định về diện tích đất tối thiểu để được phép xây nhà và công trình, tùy theo mục đích sử dụng.
Với phần đất dư sau dự án, nếu diện tích quá nhỏ và hình dạng không đạt yêu cầu, người có quyền sử dụng đất có thể đàm phán để gộp với dự án liền kề cho đủ điều kiện xây dựng. Cơ chế này linh hoạt theo từng nơi. Cách làm của Trung Quốc cho thấy một hướng đi khác: thay vì một bộ luật cứng áp cho cả nước, họ giao quyền chủ động cho địa phương — vốn là nơi hiểu rõ giá đất và đặc thù từng khu phố nhất.
Người đọc rút ra được gì?</h2>
Nhìn lại ba mô hình, tôi thấy nổi lên ba nhóm công cụ rõ ràng mà đô thị Việt Nam hoàn toàn có thể tham khảo. Thứ nhất là quy định diện tích đất tối thiểu để được cấp phép xây dựng, chặn vấn đề ngay từ khâu chia thửa. Thứ hai là cơ chế buộc hoặc cho phép nhà nước mua lại, trưng thu phần đất dư quá nhỏ sau khi mở đường, kèm bồi thường thỏa đáng — để người dân không bị mắc kẹt với mảnh đất vô dụng. Thứ ba là mô hình tái điều chỉnh, hợp thửa đất đai dựa trên sự đồng thuận của đa số chủ đất.
Điểm chung của cả ba quốc gia là họ không coi nhà siêu mỏng là lỗi của người dân để rồi chỉ đi phạt. Họ coi đó là lỗi của thiết kế chính sách đất đai, và sửa từ gốc. Nếu bạn quan tâm tới những câu chuyện chính sách và thời sự khác, có thể xem thêm trong chuyên mục Báo chí</a> của blog.
Nhận định của tôi</h2>
Tôi nghĩ bài học lớn nhất không nằm ở một điều luật cụ thể nào, mà ở triết lý tiếp cận. Nhà siêu mỏng, siêu méo không tự nhiên mọc lên; nó là hệ quả của việc mở đường mà quên tính chuyện gì sẽ xảy ra với phần đất còn lại. Khi nào chúng ta còn xử lý nó như một vi phạm cá nhân để đi vận động từng hộ, thì khi đó vấn đề vẫn sẽ tái diễn ở mỗi tuyến đường mới. Ngược lại, nếu luật quy định ngay từ đầu rằng phần đất dư không đủ điều kiện xây dựng phải được mua lại hoặc gộp thửa, thì căn nhà méo mó sẽ không có cơ hội ra đời. Phòng bệnh, suy cho cùng, luôn rẻ và đẹp hơn chữa bệnh — kể cả trong quy hoạch đô thị.

Ngày của Cha ở Việt Nam là ngày nào?

Unknown — Mon, 22 Jun 2026 00:00:00 +0000

Rất nhiều người thắc mắc Ngày của Cha ở Việt Nam là ngày nào, bởi đất nước ta không có một mốc chính thức trong lịch. Trên thực tế, phần lớn người trẻ đang chọn Chủ Nhật thứ ba của tháng 6 để tri ân đấng sinh thành. Năm 2026, ngày này rơi vào 21/6.

Git commands đưa blog lên production: giải thích từng lệnh

Unknown — Mon, 22 Jun 2026 00:00:00 +0000

Bài này liệt kê và giải thích toàn bộ các lệnh Git đưa blog lên production mà tôi đã dùng để viết, kiểm tra và xuất bản một bài viết trên blog tĩnh Zola — đúng theo thứ tự thực tế trong terminal. Nếu bạn chưa đọc bối cảnh, hãy xem trước case study fix QA Gatekeeper GitHub Actions</a> để hiểu vì sao quy trình này lại quan trọng.

Mục tiêu của bài là beginner-friendly: với mỗi lệnh, tôi sẽ nói rõ nó làm gì, vì sao tôi dùng, và nó tránh được sai lầm nào. Đây không phải lý thuyết Git hàn lâm, mà là đúng những lệnh một người viết blog cần để đưa nội dung từ máy mình lên production an toàn.

Câu lệnh kiểm tra PR GitHub từ terminal: hướng dẫn

Unknown — Mon, 22 Jun 2026 00:00:00 +0000

Khi bạn làm việc trên một dự án có CI/CD tự động, việc dùng các câu lệnh kiểm tra PR GitHub trực tiếp từ terminal sẽ giúp bạn nhanh hơn và không phụ thuộc vào UI web. Thay vì click qua các tab, bạn có thể dùng GitHub CLI để check PR status, xem CI log, quản lý workflow — chỉ cần mở terminal.
Bài này liệt kê toàn bộ câu lệnh terminal kiểm tra PR GitHub mà bạn cần để check status, xem CI/deploy log, quản lý workflow từ local — giúp bạn tự chẩn đoán khi build fail hay deploy chậm mà không cần chờ UI load.

Fix QA Gatekeeper trong GitHub Actions: bài học từ một nút Countdown bị mất ở footer

Unknown — Mon, 22 Jun 2026 00:00:00 +0000

Khoảng 2:02 sáng ngày 22/06/2026, tôi ngồi ở The Coffee Bean & Tea Leaf, trước mặt là chiếc MacBook, một ly nước đã vơi dần và một pull request tưởng như chỉ còn “xử lý conflict cho xong”. Nhưng càng đi sâu, tôi càng nhận ra đây không chỉ là một lần sửa lỗi bình thường. Đó là lần đầu tôi tự xử lý một PR bị vướng nhiều lớp: merge conflict, stale branch, conflict marker còn sót, QA Gatekeeper fail, rồi cuối cùng nhìn GitHub Actions chạy hơn 10 phút và tự auto-merge vào main</code>.
Cảm giác lúc đó rất khó tả. Không phải vì bug quá lớn, mà vì lần đầu tiên tôi đi trọn một vòng debug bằng local terminal: đọc log, hiểu test đang la gì, sửa đúng nguyên nhân, chạy QA local, push lại và chờ hệ thống xác nhận. Một nút Countdown nhỏ ở footer đã dạy tôi nhiều hơn vài giờ đọc tài liệu CI/CD khô khan.

Khoảnh khắc 2:02 sáng: một PR đỏ, một ly nước, và bài học thực tế về CI/CD.
Bối cảnh: khi PR không chỉ đơn giản là conflict</h2> Case này bắt đầu từ một PR trên blog tĩnh Zola. Ban đầu, PR có nhiều thay đổi liên quan đến SEO/AdSense cleanup, một số chỉnh sửa nội dung, .gitignore</code> cho file Zola binary bị extract, cùng vài thay đổi nhỏ ở footer và contact. Nhìn qua thì đây là dạng PR “dọn dẹp” quen thuộc, nhưng nó đụng vào nhiều file đã thay đổi trên main</code>. GitHub báo trạng thái kiểu mergeable_state=dirty</code>, nghĩa là branch không thể merge sạch vào main</code>. Auto-merge bị hoãn. Preflight conflict cũng báo branch đang xung đột với base branch. Đây là tín hiệu rõ ràng: không nên cố bấm merge, không nên push linh tinh, mà phải đưa branch về trạng thái cập nhật với main</code>. Quy trình đúng lúc đó là: git fetch origin git checkout <branch-dang-lam> git merge origin/main</code></pre> Sau đó resolve conflict, kiểm tra marker, chạy QA local rồi mới push. Nghe thì đơn giản, nhưng khi main</code> đang chạy nhanh, tình huống stale-base race rất dễ xảy ra: mình vừa resolve xong, main</code> lại có commit mới; mình vừa push lại, bot lại báo branch tiếp tục lệch. Nếu không bình tĩnh, rất dễ tưởng hệ thống bị lỗi. Preflight xanh không có nghĩa QA đã xanh</h2> Một trong những bài học lớn nhất của lần này là: “No conflicts with base branch” chỉ nói rằng Git có thể merge branch vào main</code> ở cấp độ file. Nó không đảm bảo code chạy đúng, test đúng, UI không mất chức năng, hay production an toàn. Trong case này, sau vài vòng merge/rebase, preflight conflict đã xanh. GitHub không còn báo conflict với base branch. Về mặt Git, branch đã sạch. Nhưng QA Gatekeeper vẫn fail. Đây là điểm nhiều người dễ nhầm: thấy QA đỏ sau khi resolve conflict thì nghĩ conflict vẫn chưa hết. Thực tế, lỗi lúc này đã chuyển tầng. Nó không còn là lỗi Git nữa, mà là lỗi regression test. CI/CD có nhiều cổng. Preflight conflict chỉ là một cổng. QA Gatekeeper là cổng khác. Một PR muốn đi vào production an toàn phải qua cả hai. Cách đọc log: đừng nhìn cả biển output</h2> Khi GitHub Actions đỏ, log thường rất dài. Nếu nhìn toàn bộ output, mình sẽ thấy hàng trăm dòng chạy test, build, warning, status. Người mới rất dễ bị ngợp và sửa lung tung. Cách tôi rút ra là: hãy tìm test fail đầu tiên. Đừng đọc từ trên xuống như đọc truyện. Hãy tìm các từ khóa: FAIL ERROR AssertionError FAILED</code></pre> Trong case này, test quan trọng là test liên quan đến footer Countdown. Nội dung fail nói rõ hệ thống kỳ vọng trong templates/base.html</code> phải có đủ ba thứ: /admin-countdown/ ⏱ Countdown site-footer__author-mgmt</code></pre> Ban đầu, nhìn lỗi có thể tưởng chỉ thiếu link /admin-countdown/</code>. Nhưng nếu chỉ thêm link mà thiếu class site-footer__author-mgmt</code>, test vẫn fail. Đây là chỗ nhỏ nhưng rất đáng nhớ: regression test không chỉ kiểm tra route, nó kiểm tra đúng entrypoint quản trị trong footer. Một nút Countdown nhỏ nhưng là guard cho production</h2> Fix cuối cùng rất nhỏ: <a class="site-footer__author-mgmt" href="/admin-countdown/">⏱ Countdown</a></code></pre> Chỉ một dòng HTML, nhưng dòng này có ý nghĩa lớn. Nó là admin entrypoint cho công cụ Countdown. Tính năng Countdown vẫn hoạt động, nhưng nếu nút quản trị ở footer biến mất sau một lần refactor menu/footer, người vận hành sẽ không còn đường vào nhanh để chỉnh. Với blog tĩnh, nhiều công cụ nhỏ kiểu này không có dashboard phức tạp, nên một link quản trị đúng chỗ là rất quan trọng. Đó cũng là lý do regression test tồn tại. Test không làm khó mình. Test giữ lại những thứ dễ bị con người xóa nhầm. Sau khi thêm đúng link, bước tiếp theo không phải push ngay, mà là chạy test nhỏ trước: python3 -m unittest scripts.test_footer_countdown -v</code></pre> Khi test nhỏ xanh, mới chạy full QA: python3 qa_check.py</code></pre> Cách này tiết kiệm thời gian hơn nhiều so với chạy full QA liên tục. Nếu lỗi nằm ở một module nhỏ, hãy chạy đúng test nhỏ trước. Khi test nhỏ xanh, full QA xanh sẽ có xác suất cao hơn. Ly nước trên bàn trong lúc chờ GitHub Actions chạy QA và auto-merge PR. Empty commit không sửa được lỗi gốc</h2> Trong quá trình debug CI/CD, đôi khi mình dùng empty commit để retrigger workflow: git commit --allow-empty -m "chore: retrigger qa"</code></pre> Lệnh này có ích khi CI bị kẹt, job bị flaky, hoặc cần kích hoạt lại workflow sau khi local đã pass. Nhưng empty commit không phải thuốc chữa bug. Nếu test đang fail vì thiếu class, thiếu link, sai frontmatter hoặc broken link, empty commit chỉ làm hệ thống fail lại thêm một lần. Trong case này, retrigger QA chỉ có ý nghĩa sau khi lỗi thật đã được sửa. Trước đó, việc quan trọng hơn là đọc log và hiểu test muốn gì. Stale-base race: khi main chạy nhanh hơn mình nghĩ</h2> Một khó chịu khác là main</code> liên tục có commit mới. Khi mình đang resolve PR, các PR khác hoặc workflow tự động có thể merge vào main</code>. Điều đó làm branch của mình lại lệch. Đây là stale-base race. Dấu hiệu thường gặp là bot báo branch conflict với main</code>, auto-merge bị hoãn, hoặc mergeable_state=dirty</code>. Cách xử lý không phải đoán, mà là quay về quy trình: git fetch origin git merge origin/main</code></pre> Nếu có conflict, resolve đúng file. Nếu là generated data thì thường nên ưu tiên main</code> rồi regenerate theo rule của repo. Nếu là nội dung hoặc template thì phải đọc kỹ, không chọn bừa. Với blog tĩnh, đặc biệt là repo có nhiều data JSON, template, nội dung Markdown và QA checker, stale-base race rất thường gặp. Mình càng giữ scope nhỏ, khả năng conflict càng thấp. Checklist debug CI/CD cho static blog</h2> Sau lần này, tôi rút ra một checklist ngắn: 1. Xác định lỗi thuộc tầng nào</h3> Đầu tiên, hãy phân biệt: Git conflict</li> Build fail</li> Unit test fail</li> QA content fail</li> Broken link</li> SEO/frontmatter fail</li> Deploy fail</li> </ul> Mỗi tầng có cách sửa khác nhau. Đừng dùng một cách cho mọi lỗi. 2. Luôn fetch trước khi xử lý PR</h3> Trước khi sửa branch, nên chạy: git fetch origin git status -sb</code></pre> Việc này giúp mình biết branch có đang lệch main</code> không. 3. Tìm conflict marker còn sót</h3> Sau khi resolve conflict, chạy: grep -RIn -e '^<<<<<<<' -e '^=======$' -e '^>>>>>>>' .</code></pre> Một marker còn sót trong Markdown, HTML hoặc JSON cũng có thể làm QA đỏ. 4. Chạy test nhỏ trước</h3> Nếu log chỉ rõ test fail thuộc module nào, chạy test đó trước. Ví dụ: python3 -m unittest scripts.test_footer_countdown -v</code></pre> Đừng full QA liên tục nếu lỗi đang nằm trong một test cụ thể. 5. Sau cùng mới chạy full QA</h3> Khi test nhỏ xanh: python3 qa_check.py</code></pre> Full QA là cổng cuối trước khi push. Với blog tĩnh, QA không chỉ là code, mà còn là link, SEO, frontmatter, static assets và rule production-safe. 6. Không sửa lan man</h3> Một PR đang fix bài viết thì đừng sửa template. Một PR đang fix footer thì đừng dọn data. Một PR đang thêm ảnh thì đừng động workflow. Scope càng rộng, conflict càng dễ xảy ra. Vì sao một test nhỏ lại đáng giá</h2> Nhiều người nghĩ test chỉ cần cho backend hoặc app lớn. Nhưng với static blog, test còn quan trọng hơn ở những điểm rất đời thường: link quản trị, menu, footer, robots.txt, sitemap, frontmatter, ảnh thumbnail, internal link. Một nút quản trị Countdown bị mất không làm site sập. Người đọc có thể không thấy lỗi. Nhưng người vận hành sẽ bị mất lối vào tính năng. Nếu không có test, lỗi này có thể nằm im rất lâu. Regression test giống như một tờ giấy ghi chú cho tương lai: “Đừng xóa cái này nữa, lần trước xóa là đau rồi.” Khoảnh khắc auto-merge sau 12 phút</h2> Sau khi local QA xanh, tôi push branch lên GitHub. QA Gatekeeper bắt đầu chạy. Lần này không còn làm gì thêm, không empty commit, không sửa vội. Chỉ chờ. Khoảng 12 phút sau, PR được auto-merge vào main</code>. Đó là một khoảnh khắc nhỏ nhưng rất đã. Không phải vì tôi vừa làm điều gì quá lớn, mà vì lần đầu tôi thật sự hiểu pipeline đang nói gì. Từ một PR conflict nhiều lớp, tôi đã đi qua từng lớp: Git, preflight, QA, regression test, local terminal, push, auto-merge. Cảm giác vui mừng khôn siết lúc đó đến từ việc mình không còn chỉ “nhờ tool sửa hộ”, mà đã tự đọc, tự hiểu và tự đưa production về trạng thái xanh. Bài học cho solo maker và blogger kỹ thuật</h2> Nếu bạn đang vận hành một blog tĩnh, đừng xem CI/CD là thứ xa xỉ. Một blog nhỏ vẫn có thể có nhiều rule production-safe: không broken link, không lộ file riêng tư, không sai robots.txt, không mất menu, không mất footer admin entrypoint, không sai category, không ảnh chết. Điều quan trọng không phải là có pipeline phức tạp, mà là pipeline nói rõ điều gì đang sai. Khi test fail, nó nên chỉ ra đúng chỗ. Khi bot hoãn auto-merge, nó nên nói vì sao. Khi QA đỏ, log phải giúp người vận hành sửa đúng nguyên nhân. Và quan trọng hơn: người vận hành phải học cách đọc log. Kết luận</h2> Case “fix QA Gatekeeper GitHub Actions” lần này cho tôi một bài học rất thực tế: conflict chỉ là lớp đầu tiên. Sau khi conflict sạch, QA mới là nơi kiểm tra xem thay đổi có thật sự an toàn cho production không. Một dòng link Countdown ở footer tưởng nhỏ, nhưng nó là biểu tượng cho cách một hệ thống tốt bảo vệ những chi tiết dễ bị quên. Preflight giúp branch merge được. QA Gatekeeper giúp production sống khỏe. Auto-merge chỉ nên xảy ra khi cả hai cùng xanh. Nếu có một câu tôi muốn ghi lại sau đêm 2:02 sáng đó, thì đó là: đừng sợ QA đỏ. Hãy đọc đúng test fail đầu tiên, sửa đúng nguyên nhân, chạy local trước, rồi để automation làm phần còn lại.
Top 10 công cụ terminal cho Mac 2026: dev toolkit Unknown — Mon, 22 Jun 2026 00:00:00 +0000 Nếu bạn là dev trên Mac, terminal mặc định (bash</code>/zsh</code>) sẽ đủ để làm việc cơ bản — nhưng công cụ terminal cho Mac chuyên biệt sẽ giúp bạn: 🚀 Làm việc nhanh hơn 10 lần (autocomplete, search, preview).</li> 🎨 Đọc code, log, JSON dễ hơn (syntax highlight, format).</li> 📁 Navigate folder mượt mà (jump, search, history).</li> 🛠️ Debug, commit, deploy an toàn hơn (visual tool, confirmation).</li> </ul> Bài này giới thiệu top 10 công cụ terminal Mac mà mình đã dùng và recommend cho mọi dev — từ junior tới senior. Mỗi tool đều có mục đích rõ, có thể cài trong 2 phút, và giúp ích ngay.
Viết blog bằng local terminal khi AI hết credit

Unknown — Mon, 22 Jun 2026 00:00:00 +0000

Có những ngày trợ lý AI của bạn báo hết credit, hết lượt, hoặc đơn giản là đang bảo trì. Nếu cả quy trình xuất bản của bạn phụ thuộc vào AI, bạn sẽ kẹt. Bài này hướng dẫn cách viết blog bằng local terminal một cách trọn vẹn — từ tạo nhánh, soạn bài, kiểm tra QA, build sạch, tới mở Pull Request và chờ auto-merge — mà không cần một dòng trợ giúp nào từ AI.
Đây là phần ba của cụm bài. Nếu muốn hiểu vì sao quy trình kỷ luật lại quan trọng, hãy đọc case study fix QA Gatekeeper GitHub Actions</a>. Còn nếu muốn tra cứu ý nghĩa từng câu lệnh, bài giải thích các lệnh Git đưa blog lên production</a> là cẩm nang đi kèm.

VssID không hiển thị quá trình BHTN: đừng nhầm với bảo lưu

Unknown — Mon, 22 Jun 2026 00:00:00 +0000

Cập nhật lần cuối: 22/06/2026

Có một tình huống mà tôi thấy rất nhiều người lao động gặp phải: mở app VssID lên, vào xem quá trình bảo hiểm thất nghiệp thì chỉ thấy hiện hơn một năm, trong khi mình nhớ rõ đã đi làm và đóng bảo hiểm nhiều năm trời. Hiện tượng VssID không hiển thị quá trình BHTN đầy đủ khiến cảm giác đầu tiên gần như ai cũng giống nhau — hoang mang, lo lắng, tưởng như mình vừa đánh mất một phần quyền lợi đã tích góp suốt thời gian dài.
Bài viết này tôi chia sẻ từ góc nhìn kinh nghiệm cá nhân, qua một trường hợp đại diện đã được lược bỏ toàn bộ thông tin cá nhân. Dữ liệu gốc về quá trình tham gia luôn nằm ở cơ sở dữ liệu của Bảo hiểm xã hội Việt Nam</a>, còn app chỉ là một lớp hiển thị. Mục tiêu là giúp bạn đọc hiểu đúng bản chất khi VssID không hiển thị quá trình BHTN đầy đủ, và quan trọng hơn là biết cách phân biệt ba khái niệm rất dễ nhầm với nhau.
Tham khảo thêm: VssID không hiện quá trình đóng BHTN</a> · Tra cứu thời gian đóng BHTN trên VssID</a> · Nghỉ việc bao lâu được hưởng trợ cấp thất nghiệp</a>

Lưu ý: Bài viết chỉ là phân tích, chia sẻ kinh nghiệm tham khảo, không thay thế tư vấn pháp lý hay kết luận chính thức của cơ quan BHXH và Trung tâm Dịch vụ việc làm. Mọi con số trong case là dữ liệu đại diện, không phải hồ sơ thật của ai. </blockquote>

Khi VssID không hiển thị quá trình BHTN: con số trên app và trên giấy không khớp</h2>
Hình dung một người lao động — tạm gọi là anh A. Anh A từng làm việc tại Công ty X, một doanh nghiệp dịch vụ khách hàng, trong nhiều năm. Sau khi nghỉ việc, anh nộp hồ sơ và được duyệt hưởng trợ cấp thất nghiệp. Cụ thể, theo quyết định:

Tổng số tháng được hưởng trợ cấp thất nghiệp: 10 tháng.</li>
Số tháng đã thực nhận: 2 tháng.</li>
Lý do chấm dứt hưởng: đã có việc làm (anh đi làm lại tại Công ty Y, một doanh nghiệp sản xuất).</li>
Thời gian đóng BHTN được bảo lưu: 96 tháng.</li> </ul>
Thế nhưng khi mở VssID, ở tab bảo hiểm thất nghiệp, anh A chỉ thấy hiển thị khoảng 1 năm 4 tháng. Chưa hết, app còn có một tab tên là BHTNLĐ-BNN ghi tổng thời gian tham gia tới 11 năm 6 tháng. Ba con số — 96 tháng bảo lưu, 1 năm 4 tháng trên app, và 11 năm 6 tháng ở tab kia — đứng cạnh nhau khiến anh hoàn toàn rối, không biết đâu mới là quá trình BHTN thật của mình.
Đây chính là điểm mấu chốt: ba dữ liệu này nói về ba thứ khác nhau, và nếu gộp chung lại để so sánh thì kiểu gì cũng thấy mâu thuẫn.

Phân biệt ba khái niệm rất dễ nhầm</h2>
1. BHTN — bảo hiểm thất nghiệp</h3>
Đây là thứ bạn thực sự quan tâm khi nghỉ việc: chế độ giúp người lao động có một khoản trợ cấp trong thời gian tìm việc mới. Số tháng được hưởng trợ cấp thất nghiệp được tính dựa trên thời gian đã đóng BHTN. Tab BHTN trên VssID là nơi hiển thị quá trình đóng này.
2. BHTNLĐ-BNN — bảo hiểm tai nạn lao động, bệnh nghề nghiệp</h3>
Cái tên viết tắt dài và có chữ "TN" ở giữa khiến rất nhiều người tưởng đây cũng là bảo hiểm thất nghiệp. Hoàn toàn không phải. BHTNLĐ-BNN là chế độ bảo hiểm cho rủi ro tai nạn lao động và bệnh nghề nghiệp trong quá trình làm việc. Con số "11 năm 6 tháng" ở tab này phản ánh tổng thời gian anh A tham gia bảo hiểm tai nạn lao động — nó không dùng để tính trợ cấp thất nghiệp, và cũng không phải là quá trình BHTN bị "ẩn đi đâu mất".
Nói cách khác: thấy tab BHTNLĐ-BNN có số năm lớn thì đừng vội mừng là "BHTN của mình vẫn còn nhiều", mà cũng đừng lấy nó so với tab BHTN rồi hoảng vì lệch.
3. Thời gian bảo lưu trợ cấp thất nghiệp</h3>
Đây là khái niệm quan trọng nhất trong câu chuyện của anh A. Khi bạn được duyệt hưởng trợ cấp nhưng chưa nhận hết số tháng (vì tìm được việc và chấm dứt hưởng đúng quy định), phần thời gian đóng BHTN tương ứng chưa dùng tới có thể được bảo lưu để cộng nối cho lần hưởng sau này. Con số 96 tháng bảo lưu ghi trong quyết định chính là phần "để dành" đó.

Phân tích logic: quyền lợi của anh A đang ở đâu?</h2>
Khi đặt các dữ kiện cạnh nhau, ta có thể suy luận một cách thận trọng:
Thứ nhất, anh A đã được duyệt hưởng tới 10 tháng trợ cấp thất nghiệp. Theo cách tính phổ biến, để được duyệt số tháng hưởng ở mức này thì hệ thống phải từng ghi nhận quá trình đóng BHTN khá dài. Nếu dữ liệu đóng BHTN thật sự "biến mất", anh đã không thể được duyệt mức hưởng như vậy ngay từ đầu.
Thứ hai, anh mới nhận 2 trên 10 tháng rồi chấm dứt vì có việc làm. Trong trường hợp chấm dứt hưởng đúng quy định, phần thời gian đóng còn lại có thể được bảo lưu. Con số 96 tháng trong quyết định là một dấu hiệu rất mạnh cho thấy quyền lợi của anh chưa mất, mà đang được giữ lại trong hệ thống dưới dạng thời gian bảo lưu.
Thứ ba, vậy con số "1 năm 4 tháng" trên VssID là gì? Một khả năng hợp lý: đó là phần thời gian đóng BHTN mới kể từ khi anh đi làm lại tại Công ty Y, chưa được gộp/cộng nối hiển thị với phần 96 tháng bảo lưu trước đó. App đang cho thấy phần "mới phát sinh", còn phần bảo lưu nằm ở một bản ghi khác.
Tôi nhấn mạnh chữ "có thể" ở đây. Đây là phân tích để bạn không hoảng loạn, không phải kết luận chắc chắn. Việc dữ liệu cộng nối ra sao còn phụ thuộc điều kiện cụ thể của từng hồ sơ, và chỉ cơ quan chức năng mới xác nhận được chính xác. Cũng vì thế, tôi tránh nói "VssID bị lỗi" như một khẳng định tuyệt đối — chính xác hơn là có thể đang lệch hiển thị, chưa đồng bộ, hoặc cần đối chiếu.

Người lao động nên làm gì?</h2>
Nếu bạn rơi vào tình huống tương tự, đây là các bước thực tế tôi nghĩ nên làm theo thứ tự:

Lưu giữ giấy tờ gốc. Quan trọng nhất là quyết định hưởng và quyết định chấm dứt hưởng trợ cấp thất nghiệp — nơi ghi rõ số tháng đã hưởng và số tháng đóng BHTN được bảo lưu. Đây là bằng chứng pháp lý mạnh nhất.</li>
Chụp màn hình VssID. Chụp lại tab BHTN (và cả tab BHTNLĐ-BNN nếu cần) tại thời điểm kiểm tra, để có dữ liệu đối chiếu khi làm việc với cơ quan chức năng.</li>
Đặt đúng câu hỏi, ở đúng nơi. Đến cơ quan BHXH nơi bạn đang đóng hoặc Trung tâm Dịch vụ việc làm nơi đã giải quyết hồ sơ, và hỏi thẳng: "96 tháng đóng BHTN được bảo lưu đang nằm ở đâu trên hệ thống, và có được cộng nối với thời gian BHTN mới của tôi không?" Câu hỏi cụ thể như vậy giúp cán bộ tra cứu đúng phần bạn cần.</li>
Mang theo giấy tờ tùy thân và mã số BHXH để việc tra cứu, đối chiếu diễn ra nhanh và chắc chắn.</li> </ol>
Một lưu ý về an toàn: đừng vì sốt ruột mà tìm cách "lách" hay khai khác đi thông tin hồ sơ. Quyền lợi bảo lưu chỉ áp dụng khi bạn đủ điều kiện theo quy định — không phải ai chấm dứt hưởng cũng đương nhiên được bảo lưu toàn bộ. Cứ đối chiếu trung thực dựa trên giấy tờ là cách an toàn nhất.

Kết luận</h2>
Khi VssID không hiển thị quá trình BHTN đầy đủ, phản ứng đầu tiên thường là lo mất quyền lợi — nhưng đó hiếm khi là toàn bộ câu chuyện. Ba con số dễ làm bạn rối thực chất nói về ba thứ khác nhau: BHTN là bảo hiểm thất nghiệp, BHTNLĐ-BNN là bảo hiểm tai nạn lao động và bệnh nghề nghiệp, còn thời gian bảo lưu là phần đóng chưa dùng hết đang được giữ lại cho bạn.
Trong trường hợp của anh A, tờ quyết định ghi 96 tháng bảo lưu chính là điểm tựa quan trọng nhất: nó cho thấy quyền lợi nhiều khả năng vẫn còn đó, chỉ là đang nằm ở một bản ghi mà app chưa gộp hiển thị. Việc cần làm không phải là hoảng, mà là giữ giấy tờ, đối chiếu dữ liệu và hỏi đúng nơi. Con số trên màn hình có thể chưa khớp, nhưng giấy quyết định bảo lưu thì luôn là bằng chứng có giá trị.

Watermark cho blog: cách mình dùng dấu nhận diện để bảo vệ ảnh và giữ thương hiệu nhất quán

Unknown — Mon, 22 Jun 2026 00:00:00 +0000

Sau một thời gian viết blog kỹ thuật, mình nhận ra ảnh không chỉ là minh hoạ — nó là tài sản. Một tấm ảnh chụp màn hình terminal, một biểu đồ tự vẽ, hay một bức hình bàn làm việc lúc 2 giờ sáng đều tốn công tạo ra. Vì vậy mình quyết định làm watermark cho blog: gắn một dấu nhận diện tinh tế lên những ảnh mình thực sự sở hữu, vừa để giữ thương hiệu nhất quán, vừa giảm việc ảnh bị sao chép tuỳ tiện. Bài này chia sẻ cách mình tự động hoá việc đó một cách an toàn, không phá trải nghiệm đọc, và quan trọng nhất là không bao giờ đụng vào ảnh của bên thứ ba.

BIDV SmartBanking không vào được? Cách xử lý nhanh

Unknown — Sun, 21 Jun 2026 00:00:00 +0000

"BIDV SmartBanking không vào được" có lẽ là kiểu lỗi gây ức chế nhất với người dùng ngân hàng số: đúng lúc cần chuyển tiền gấp thì app cứ quay vòng, báo sai mật khẩu, hoặc văng ra màn hình trắng. Mình từng dính đúng cảnh đó giữa lúc thanh toán, nên bài này mình gom lại toàn bộ nguyên nhân thường gặp và cách xử lý theo thứ tự từ nhanh tới căn cơ, để bạn không phải mò mẫm trong lúc đang sốt ruột.

Auto Fixer Là Gì? GitHub Actions Tự Chữa Lỗi Blog

Unknown — Sun, 21 Jun 2026 00:00:00 +0000

🦠 Metaphor cơ khí: Blog/repo = cơ thể sống. QA/build/checks = xét nghiệm sức khoẻ. Vaccine Library = trí nhớ miễn dịch. Vaccine Hotfix = kháng thể/y tá tự động. Auto-merge = cổng kiểm soát. Report JSON = hồ sơ bệnh án. </blockquote>
Khi blog của bạn không còn là vài file tĩnh, mà là một hệ thống với ~70 trang, CI/CD workflow, QA gate, preview deploy — bạn không thể sửa lỗi thủ công liên tục. Auto Fixer là gì? Nó là một cơ chế tự động phát hiện, sửa lỗi CI lặp lại, và tính toán rủi ro, mà vẫn giữ an toàn cho nhánh chính. Bài này chia sẻ cách xây dựng hệ miễn dịch tự chữa lỗi này cho blog dùng GitHub Actions.

Auto Fixer Tự Sửa Lỗi CI/CD: Case Study Thực Chiến

Unknown — Sun, 21 Jun 2026 00:00:00 +0000

Khi bạn viết một bài blog về Auto Fixer tự chữa lỗi CI/CD, bạn không ngờ rằng chính bài viết đó sẽ cần được Auto Fixer cứu. Đó chính là chuyện xảy ra trong một phiên phát triển gần đây.
Một PR chứa bài viết về cách xây dựng self-healing pipeline được push lên. QA Gatekeeper chạy, phát hiện vấn đề. Required checks chặn lại PR. Thay vì người developer phải ngồi fix thủ công và re-push, Vaccine Hotfix tự động kích hoạt: phát hiện pattern lỗi, sửa delta nhỏ, chạy QA lại, tạo bản vá riêng biệt trên branch hotfix. Khi bản vá pass QA, auto-merge bot kích hoạt, PR được merge an toàn vào main.
Bài này là case study thực chiến về cách một hệ thống self-healing không phải là lý thuyết suông — nó xử lý lỗi thật, lúc sản phẩm thật, trên các công nghệ thật (GitHub Actions, QA Gatekeeper, Vaccine Hotfix, auto-merge). Chúng ta sẽ đi qua những gì xảy ra, tại sao nó lại tốt, và bài học khi thiết kế automation an toàn.

Cách gắn Cloudflare Turnstile vào blog tĩnh để chống spam

Unknown — Sun, 21 Jun 2026 00:00:00 +0000

Cách gắn Cloudflare Turnstile vào blog tĩnh để chống spam</h1>
Cloudflare Turnstile là một cách nhẹ nhàng để thêm lớp chống spam cho website mà không làm trải nghiệm đọc blog trở nên khó chịu. Với blog tĩnh như Zola, Hugo, Astro hoặc website HTML/CSS/JS thuần, cách làm đúng không chỉ là dán một đoạn widget vào giao diện. Muốn chống spam thật, ta cần thêm một bước xác minh token ở phía server hoặc Cloudflare Worker.
Bài này là ghi chú thực chiến sau khi mình tự setup Turnstile cho một blog tĩnh: có lỗi token, có lỗi sai account Cloudflare, có lúc build Zola lâu tưởng treo, và có cả bài học quan trọng là tuyệt đối không dán nhầm secret key vào source code.

Cách xoá sạch ứng dụng khỏi Mac bằng Terminal: ví dụ gỡ 84Key

Unknown — Sun, 21 Jun 2026 00:00:00 +0000

💡 Mẹo từ Mac người dùng lâu năm: Khi cài một ứng dụng Mac, đặc biệt là input method (bộ gõ) như 84Key, hệ thống không chỉ lưu file .app</code> chính. Các tệp cấu hình, cache, và preference sẽ nằm rải rác trong thư mục Library</code>. Xoá không sạch = còn "rác" làm máy chậm. Bài này hướng dẫn cách xoá từ A tới Z mà không bỏ sót. </blockquote>
Mac ngày nay có SSD nhanh nhưng dung lượng hạn chế, và tích tích những app cũ + cache → máy sẽ cảm thấy nặng. Thay vì xoá app bằng cách kéo vào Trash (để lại rác), bạn có thể dùng Terminal — công cụ dòng lệnh mạnh mẽ trên mọi Mac — để xoá hoàn toàn, kể cả những file ẩn.
Bài này dùng 84Key (bộ gõ tiếng Việt) làm ví dụ thực tế — nó có cây thư mục tiêu chuẩn và dễ kiểm chứng, nhưng quy trình cũng áp dụng cho hầu hết ứng dụng Mac khác.
Bước 1: Kiểm tra ứng dụng có đang chạy không</h2> Trước khi xoá, hãy dừng process của app (nếu đang chạy). Mở Terminal (⌘ + Space</code>, gõ "Terminal", Enter) và chạy:
ps aux | grep -iE "84[ -]?key|84key" | grep -v grep</code></pre> Lệnh này tìm kiếm process có tên chứa "84key" (không phân biệt hoa/thường) và hiển thị nếu có. Nếu thấy một dòng kết quả → app đang chạy. Nếu đang chạy, cách dừng: Bấm icon app trên menu bar (nếu có) → Quit, hoặc:
killall -9 "84Key" 2>/dev/null || true</code></pre> Lưu ý: 2>/dev/null</code> bỏ đi lỗi nếu process không tồn tại; || true</code> đảm bảo lệnh luôn thành công.
Bước 2: Tìm tất cả file liên quan tới 84Key trên Mac</h2> Ứng dụng Mac không chỉ nằm ở /Applications/</code>. Cache, preference, support file có thể nằm ở /Library</code>, ~/Library</code> (thư mục nhà), hoặc /var/</code>. Dùng mdfind</code> (Spotlight search qua dòng lệnh) để quét:
mdfind "84Key OR '84 Key' OR 84key" 2>/dev/null | head -20</code></pre> Ngoài ra, quét trực tiếp các thư mục thường:
find /Applications "$HOME/Applications" "$HOME/Downloads" "$HOME/Library" /Library -iname "*84*key*" 2>/dev/null</code></pre> Lệnh này tìm mọi file/thư mục có tên chứa "84" và "key" (case-insensitive). 2>/dev/null</code> ẩn cảnh báo "Permission denied" để output sạch hơn. Kết quả sẽ gồm: Ứng dụng chính: /Applications/84Key.app</code></li> File cài đặt: $HOME/Downloads/84Key-v0.1.0.dmg</code></li> Cache: $HOME/Library/Caches/com.nghialuong.key84</code></li> Preferences: $HOME/Library/Preferences/com.nghialuong.key84.plist</code></li> Support folder: $HOME/Library/Application Support/com.nghialuong.key84</code></li> </ul> Ghi chú những đường dẫn này lại — bạn sẽ cần chúng ở bước kế tiếp. Bước 3: Xoá ứng dụng chính trong /Applications</h2> Đây là phần dễ nhất. Ứng dụng chính thường nằm ở /Applications/</code>: sudo rm -rf "/Applications/84Key.app"</code></pre> Giải thích: sudo</code> = chạy lệnh với quyền admin (MacOS yêu cầu để xoá trong /Applications</code>)</li> rm</code> = remove (xoá)</li> -rf</code> = recursive (xoá thư mục + nội dung), force (không hỏi xác nhận)</li> "/Applications/84Key.app"</code> = đường dẫn đúng (lưu ý dấu nháy nếu tên có space)</li> </ul> Khi gõ sudo</code>, bạn sẽ được hỏi mật khẩu Mac. Khi nhập mật khẩu, ký tự sẽ KHÔNG hiển thị (đó là bình thường) — chỉ cần gõ đúng rồi nhấn Enter. Nếu muốn hủy lệnh khi đang gõ, nhấn Ctrl + C</code>. Bước 4: Xoá file cài đặt (.dmg) nếu có</h2> Nếu file cài đặt vẫn còn trong Downloads</code>: rm -f "$HOME/Downloads/84Key-v0.1.0.dmg"</code></pre> Hoặc tổng quát hơn (tất cả file .dmg</code> có "84Key"): rm -f "$HOME/Downloads"/*84Key*.dmg</code></pre>Bước 5: Xoá cache, preferences, và Application Support</h2> Đây là phần quan trọng — những folder ẩn này chứa setting, cache, và dữ liệu: Xoá cache: rm -rf "$HOME/Library/Caches/com.nghialuong.key84"</code></pre> Xoá preferences (.plist file): rm -f "$HOME/Library/Preferences/com.nghialuong.key84.plist"</code></pre> Xoá Application Support folder: rm -rf "$HOME/Library/Application Support/com.nghialuong.key84"</code></pre> Xoá Cookies (nếu app có web component): rm -f "$HOME/Library/Cookies/com.nghialuong.key84.binarycookies"</code></pre> Ghi chú: Bundle ID (com.nghialuong.key84</code>) không phải lúc nào cũng dễ đoán. Bạn có thể tìm trong /Applications/AppName.app/Contents/Info.plist</code>: cat "/Applications/84Key.app/Contents/Info.plist" | grep -i "bundle"</code></pre> Nếu đã xoá app, hãy dùng kết quả từ Bước 2 (tìm mdfind) để biết Bundle ID chính xác. Bước 6: Kiểm tra xoá thành công</h2> Chạy lại lệnh kiểm tra từ Bước 1: ps aux | grep -iE "84key" | grep -v grep</code></pre> Nếu không có output (hoặc chỉ có "grep" trong kết quả) → process xoá thành công. Kiểm tra ứng dụng không còn trong /Applications</code>: ls -la "/Applications/" | grep -i "84key"</code></pre> Nếu không có output → ứng dụng xoá thành công. Kiểm tra cache/preferences: ls -la "$HOME/Library/Caches/" | grep -i "84key" ls -la "$HOME/Library/Preferences/" | grep -i "84key"</code></pre> Cả hai không có output = xoá sạch. Bước 7: Làm sạch thêm (Tùy chọn)</h2> Nếu muốn tuyệt đối chắc chắn: Kiểm tra Input Sources (nếu là input method): defaults read com.apple.HIToolbox AppleEnabledInputSources | grep -i "84"</code></pre> Nếu 84Key được đăng ký làm input source, bạn có thể xoá nó qua System Settings → Keyboard → Input Sources (GUI). Hoặc dùng Terminal tùy chỉnh nâng cao nếu biết rõ. Restart hoặc Logout/Login: Nếu app từng tự khởi động khi Mac boot, hãy restart để làm sạch hết: sudo reboot # Để restart ngay</code></pre> Hoặc đơn giản hơn: Menu Apple → Restart. Những điều nên tránh</h2> ❌ Xoá file hệ thống Apple: Tránh xoá bất cứ file nào dụng tên "Apple" hoặc trong /System/Library</code> trừ khi chắc chắn.</li> ❌ Xoá toàn bộ ~/Library: Đây là folder chứa setting của toàn bộ ứng dụng, xoá cả folder làm mất hết cấu hình Mac.</li> ❌ Quên sudo</code>: Một số folder trong /Library</code> yêu cầu quyền admin; nhầm xoá không được sẽ không hỏi lại.</li> </ul> Tóm lại</h2> Xoá sạch app trên Mac bằng Terminal rất đơn giản nếu biết các bước: ✅ Kiểm tra app có chạy (ps aux)</li> ✅ Tìm tất cả file liên quan (mdfind, find)</li> ✅ Xoá /Applications/AppName.app</code></li> ✅ Xoá file .dmg cài đặt</li> ✅ Xoá cache, preferences, Application Support</li> ✅ Kiểm tra lại không còn process/file</li> ✅ Restart nếu cần</li> </ol> Với ví dụ 84Key, bạn cũng đã hiểu cơ chế Bundle ID và tên thư mục — áp dụng quy trình này cho bất kỳ app Mac nào. Mac của bạn sẽ nhẹ nhàng hơn — đó là lý do bạn nên làm sạch định kỳ! Bạn đã thử Terminal xoá app trên Mac chưa? Bình luận bên dưới nếu có câu hỏi hoặc muốn hỏi thêm về app khác. Đọc thêm: Git là gì? Version Control dành cho người mới</a></li> Cài đặt Git và cấu hình lần đầu</a></li> Bảo mật Best Practices cho Git & GitHub</a></li> </ul>
Git push bị reject? Cách xử lý an toàn trên Mac Unknown — Sun, 21 Jun 2026 00:00:00 +0000 🔧 Bài học từ thực tế: Lỗi "git push bị reject" thường xảy ra khi làm việc theo team — ai đó push commit, bạn không fetch kip, rồi bạn push code mà không biết có commit mới từ remote. Bài này hướng dẫn cách xử lý an toàn và cách tránh QA false positive ngoài ý muốn. Xem thêm hướng dẫn sync cơ bản push/pull/fetch</a> hoặc cách xử lý conflict</a>. </blockquote> Mỗi lập trình viên làm việc với team từng gặp tình huống này: bạn code xong, chạy git push origin main</code>, nhưng Git từ chối với dòng lỗi kiểu "rejected ... [non-fast-forward]". Điều gì xảy ra? Làm thế nào để sửa mà không mất code, mà không phải xoá branch và clone lại từ đầu? Bài viết này sẽ giải thích rõ ràng, cung cấp từng bước an toàn và cách tránh lỗi phổ biến mà nhiều người mắc phải. GitHub PR Conflict Pending Merge Checks UNSTABLE UNKNOWN Unknown — Sun, 21 Jun 2026 00:00:00 +0000 Một buổi chiều, một PR bị stuck: "No conflicts with base branch" — nhưng vẫn không merge được. CI status hiển thị UNSTABLE</code>, sau force-push nó thành UNKNOWN</code>. Đợi 15 phút rồi checks mới xanh. Đó là câu chuyện thực tế từ trường hợp PR #652 của tôi. Bài này chia sẻ kinh nghiệm xử lý GitHub PR conflict pending merge checks UNSTABLE UNKNOWN — hiểu đúng merge states, tại sao QA Gatekeeper chạy lâu, và khi nào an toàn merge PR. Nếu bạn đang gặp tình huống "pending checks" hay mergeStateStatus đang ở trạng thái UNSTABLE, UNKNOWN, hoặc BLOCKED, bài này sẽ giúp bạn tìm nguyên nhân và giải pháp. Tạo ảnh OG: gương mặt trên mạng xã hội của blog và tạp chí online Unknown — Sun, 21 Jun 2026 00:00:00 +0000 ![Tạo ảnh OG cho blog và tạp chí online] Có một sự thật hơi phũ về blog: rất nhiều người sẽ "đọc" bài viết của bạn mà không bao giờ bấm vào link. Họ chỉ lướt qua một tấm ảnh preview trên Facebook, Zalo hay X, đọc dòng tiêu đề trong hai giây, rồi quyết định có dừng lại hay không. Tấm ảnh preview đó chính là ảnh OG — và nó đang làm việc thay bạn, dù bạn có để ý tới nó hay không. V-Wealth của VietinBank: Tia sáng cho nhà đầu tư bình dân Unknown — Sun, 21 Jun 2026 00:00:00 +0000 Tóm tắt nhanh. VietinBank ra mắt V-Wealth phiên bản mới ngay trong ứng dụng iPay: đầu tư tự động đa kỳ hạn, danh mục rộng hơn (quỹ mở, digiGOLD, tiền gửi thông minh) và giao diện được thiết kế lại theo hướng cá nhân hoá. Bài viết chỉ mang tính tham khảo, không phải lời khuyên đầu tư. </blockquote> Mấy năm gần đây, chuyện "tiền để không cũng nên sinh lời" dần trở thành thói quen của nhiều người quanh mình. Và khi nhu cầu quản lý tài sản số ngày càng đa dạng, một cái app ngân hàng chỉ để chuyển khoản thôi là chưa đủ. Đó là lý do mình chú ý khi VietinBank công bố nâng cấp V-Wealth — nền tảng đầu tư và quản lý tài sản số nằm gọn trong ứng dụng VietinBank iPay. Không phải app mới, không phải tài khoản mới, mà là một lớp trải nghiệm được làm lại để người dùng phổ thông cũng có thể bắt đầu đầu tư mà không thấy ngợp. PR Sentinel — CI Radar Unknown — Sun, 21 Jun 2026 00:00:00 +0000 SEOMONEY · S-DNA Tools PR Sentinel — CI Radar</h1> Theo dõi toàn bộ Pull Request, trạng thái CI/CD, branch, author và tín hiệu cần xử lý trong một dashboard duy nhất. </div> Open PRs 0 </div> <div class="pr-sentinel-kpi"> Passing 0 </div> <div class="pr-sentinel-kpi"> Failing 0 </div> <div class="pr-sentinel-kpi"> Pending 0 </div> <div class="pr-sentinel-kpi"> Draft 0 </div></code></pre> </div>

SEOMONEY

Nhà siêu mỏng, siêu méo: các nước châu Á xử lý ra sao?

Ngày của Cha ở Việt Nam là ngày nào?

Git commands đưa blog lên production: giải thích từng lệnh

Câu lệnh kiểm tra PR GitHub từ terminal: hướng dẫn

Fix QA Gatekeeper trong GitHub Actions: bài học từ một nút Countdown bị mất ở footer

6. Không sửa lan man</h3> Một PR đang fix bài viết thì đừng sửa template. Một PR đang fix footer thì đừng dọn data. Một PR đang thêm ảnh thì đừng động workflow. Scope càng rộng, conflict càng dễ xảy ra.</p>

Top 10 công cụ terminal cho Mac 2026: dev toolkit

Viết blog bằng local terminal khi AI hết credit

VssID không hiển thị quá trình BHTN: đừng nhầm với bảo lưu

Phân biệt ba khái niệm rất dễ nhầm</h2>

Watermark cho blog: cách mình dùng dấu nhận diện để bảo vệ ảnh và giữ thương hiệu nhất quán

BIDV SmartBanking không vào được? Cách xử lý nhanh

Auto Fixer Là Gì? GitHub Actions Tự Chữa Lỗi Blog

Auto Fixer Tự Sửa Lỗi CI/CD: Case Study Thực Chiến

Cách gắn Cloudflare Turnstile vào blog tĩnh để chống spam

Cách xoá sạch ứng dụng khỏi Mac bằng Terminal: ví dụ gỡ 84Key

Git push bị reject? Cách xử lý an toàn trên Mac

GitHub PR Conflict Pending Merge Checks UNSTABLE UNKNOWN

Tạo ảnh OG: gương mặt trên mạng xã hội của blog và tạp chí online

V-Wealth của VietinBank: Tia sáng cho nhà đầu tư bình dân

PR Sentinel — CI Radar

6. Không sửa lan man</h3>
Một PR đang fix bài viết thì đừng sửa template. Một PR đang fix footer thì đừng dọn data. Một PR đang thêm ảnh thì đừng động workflow. Scope càng rộng, conflict càng dễ xảy ra.</p>