Bug này idev

Bug này idev Contact information, map and directions, contact form, opening hours, services, ratings, photos, videos and announcements from Bug này idev, Educational Research Center, Ho Chi Minh City.

Đây là ngôi nhà chung của anh em iDev. Ở đây chúng ta không chỉ học code, mà còn học những kỹ năng mềm, và cùng nhau chia sẻ những câu chuyện dở khóc dở cười trong ngành.

VIỆT NAM VÔ ĐỊCH! 🇻🇳🏆Mỹ Đình bùng nổ. Cả đất nước vỡ òa!Đội tuyển Việt Nam đã chiến đấu đến cùng, giữ vững bản lĩnh và v...
26/08/2026

VIỆT NAM VÔ ĐỊCH! 🇻🇳🏆

Mỹ Đình bùng nổ. Cả đất nước vỡ òa!
Đội tuyển Việt Nam đã chiến đấu đến cùng, giữ vững bản lĩnh và viết tiếp một đêm không thể quên cho bóng đá nước nhà.

Hàng triệu con tim đã cùng hát, cùng tin, cùng cháy hết mình vì Việt Nam!

Tự hào Việt Nam 🇻🇳🇻🇳🇻🇳
Việt Nam vô địch 🏆🏆🏆

Biết Docker, Kubernetes và CI/CD chưa biến bạn thành DevOps Engineer. Nghề này bắt đầu khi hệ thống gặp sự cố và bạn phả...
25/08/2026

Biết Docker, Kubernetes và CI/CD chưa biến bạn thành DevOps Engineer. Nghề này bắt đầu khi hệ thống gặp sự cố và bạn phải biến tín hiệu hỗn loạn thành quyết định an toàn.

Câu trả lời ngắn: DevOps vừa là cách tổ chức công việc, vừa có thể là tên một vị trí. Tool chỉ là một phần của bức tranh.

Ở lớp phương pháp, DevOps nối Development và Operations trong cùng một vòng đời:
plan → code → build → test → deploy → monitor → feedback

Mục tiêu là team chịu trách nhiệm gần hơn với dịch vụ mình tạo ra, thay vì mỗi nhóm chỉ bàn giao một đoạn rồi chờ nhóm khác xử lý.

Ở lớp công cụ, Git giúp quản lý thay đổi, Docker đóng gói môi trường, CI/CD tự động hóa build/test/release, Terraform mô tả hạ tầng bằng code, Kubernetes điều phối container, monitoring/logging cho biết hệ thống đang hoạt động ra sao.

Biết từng tool là hữu ích. Ghép chúng thành flow có điểm kiểm soát mới là phần khó.

Etsy Engineering từng chia sẻ một chi tiết đáng chú ý: họ tự động ghi nhận mỗi lần deploy vào hệ thống monitoring để phân biệt vấn đề do code vừa thay đổi với lỗi từ hạ tầng hoặc bên thứ ba. Công cụ ở đây giúp team nhìn thấy mối liên hệ giữa thay đổi và hành vi của hệ thống, rồi phản ứng nhanh hơn.

Vì vậy, DevOps Engineer làm nhiều việc hơn dựng server. Tùy tổ chức, role này có thể nghiêng về CI/CD, cloud, infrastructure as code, observability, security, platform hoặc incident response.

Job title thay đổi; trách nhiệm cốt lõi vẫn xoay quanh delivery có kiểm soát và hệ thống đáng tin cậy.

Nếu đang học DevOps, đừng bắt đầu bằng câu hỏi “tool nào hot?”. Hãy vẽ một flow nhỏ:
commit → build/test → artifact → deploy/gate → monitor → feedback

Sau mỗi bước, hỏi: nó giải quyết vấn đề gì, tín hiệu nào cho biết đang ổn, và nếu thất bại thì điều gì giúp hệ thống quay lại an toàn?

DevOps có thể là một nghề. Nhưng trước khi là job title, nó là cách một team cùng xây, cùng vận hành và cùng chịu trách nhiệm với phần mềm.

Bạn đang ở đâu trong flow này: biết lệnh, hiểu hệ thống hay đã tự xử lý được một sự cố?

Bạn thích viết code, hay thật sự thích lần theo nguyên nhân khi mọi thứ không hoạt động?Có những ngày bạn sẽ viết code. ...
23/08/2026

Bạn thích viết code, hay thật sự thích lần theo nguyên nhân khi mọi thứ không hoạt động?

Có những ngày bạn sẽ viết code. Cũng có những ngày công việc là đọc tài liệu, lần theo log, sửa test, review code, hỏi lại yêu cầu hoặc giải thích vì sao mình chọn một cách làm. Phần khó thường không nằm ở việc nhớ thêm một cú pháp, mà ở chỗ hiểu vấn đề đủ rõ để biết mình đang giải quyết điều gì.

Sở thích ấy mới mở đầu cho việc khám phá. Bạn có thể tự kiểm tra bằng vài câu hỏi:
- Khi gặp bug, bạn muốn hiểu nguyên nhân hay chỉ tìm một đoạn code để dán vào?
- Bạn có chấp nhận học nền tảng và quay lại sửa cách hiểu của mình?
- Bạn có thể trao đổi với người khác khi yêu cầu chưa rõ hoặc giải pháp còn nhiều đánh đổi?
- Sau một lần làm sai, bạn còn muốn thử lại theo cách tốt hơn không?

Hãy thử một project nhỏ trong vài tuần: đọc docs, tự thiết kế một phần, debug một lỗi, nhận feedback rồi sửa lại. Quan sát điều khiến bạn tò mò, điều làm bạn nản và lý do bạn có muốn quay lại hay không.

Ở iDEV, chúng mình nhìn việc học CNTT từ câu hỏi WHY: hiểu bản chất, xây tư duy, thực hành và từng bước tự tìm con đường phù hợp. Mục tiêu là giúp bạn có đủ trải nghiệm để chọn tỉnh táo hơn. Bạn không cần chứng minh mình “sinh ra để code”.

Bạn đang thích code, hay thật sự thích quá trình giải quyết vấn đề phía sau code?

Chia sẻ câu trả lời của bạn ở phần bình luận.

API trả về 200 chưa có nghĩa là Backend Developer đã xong việc.Một ngày có thể bắt đầu bằng ticket chưa rõ, việc hỏi lại...
21/08/2026

API trả về 200 chưa có nghĩa là Backend Developer đã xong việc.

Một ngày có thể bắt đầu bằng ticket chưa rõ, việc hỏi lại business rule, đọc log sau deploy hoặc tìm lý do request chậm.

Trước khi viết endpoint, developer cần nghĩ:

- Dữ liệu đi qua những service nào?
- Request xử lý ra sao khi input sai, timeout hoặc dependency bị gián đoạn?
- Thay đổi ảnh hưởng tới database, API cũ và người dùng thế nào?
- Hệ thống phát hiện behavior bất thường bằng cách nào?

Sau đó mới tới những việc quen thuộc:

- viết endpoint và xử lý business logic;
- review code, viết test và debug bug không tái hiện ở local;
- trao đổi với Frontend, QA và Product để thống nhất behavior;
- theo dõi sau deploy và cân nhắc rollback khi cần.

Các case công khai cũng cho thấy phần việc phía sau chữ “deploy”.

Etsy Engineering từng mô tả mô hình “push train”: một nhóm engineers đưa thay đổi qua staging rồi production; ở mỗi checkpoint, họ test, xác nhận sẵn sàng và kiểm tra có gì bị hỏng không. Google SRE mô tả change chạy continuous test, release lấy từ revision đã pass, artifact đi qua system test và canary, rồi log kết quả từng bước.

Đây là quy trình của Etsy và Google, không phải trải nghiệm iDEV hay quy tắc bắt buộc cho mọi team. Điểm chung là engineer phải theo dõi behavior của hệ thống đến lúc release, thay vì dừng lại khi code đã chạy.

Nếu đang học Backend, đừng đo tiến bộ bằng số endpoint đã viết. Hãy thử hỏi:

- API được thiết kế như vậy vì sao?

- Khi lỗi xảy ra, hệ thống sẽ cho mình biết bằng cách nào?

- Thay đổi này tạo ra trade-off gì?

Đó là lúc bạn bắt đầu nhìn Backend như một hệ thống cần hiểu và vận hành, thay vì một danh sách API cần hoàn thành.

Trong workflow Backend, phần nào khó hơn với bạn: requirement, code, debug hay release?

Bạn cấu hình xong auto deploy, nhưng pipeline vẫn có thể dừng ở test hoặc chờ approval.Việc pipeline tạm dừng chính là t...
17/08/2026

Bạn cấu hình xong auto deploy, nhưng pipeline vẫn có thể dừng ở test hoặc chờ approval.

Việc pipeline tạm dừng chính là tín hiệu cho biết team cần kiểm tra những gì trước khi đưa thay đổi đi tiếp.

Nhiều bạn mới làm quen với DevOps bắt đầu bằng build image, push registry, deploy server. Phần khó hơn là hiểu Feedback Loop (vòng phản hồi): mỗi thay đổi code được kiểm chứng sớm trước release.

Flow có thể là:

commit → build → test → quality/security check → artifact → deploy/approve → monitor

Artifact là gói build lưu lại cho các môi trường. Quality gate là điều kiện phải đạt trước khi đi tiếp.

Google mô tả một quy trình rất cụ thể: mỗi change submit chạy continuous test; release lấy từ revision đã pass; artifact tiếp tục qua system test và canary; kết quả từng bước được log. Ở đây, deploy chỉ là một điểm trong chuỗi feedback và decision gate.

Điều này tạo ra ba giá trị:

- Phát hiện lỗi sớm hơn: thay đổi vừa tạo đã có tín hiệu từ build/test, giúp khoanh vùng nguyên nhân dễ hơn.

- Quy trình lặp lại: team giảm việc ghi nhớ và chạy thủ công một chuỗi lệnh khác nhau cho mỗi lần release.

- Release có kiểm soát: approval hoặc quality gate đóng vai trò như chiếc phanh an toàn — giữ Production ổn định trước khi các thay đổi được phép bước qua.

Ở iDEV, khi học một tool, hãy bắt đầu bằng câu hỏi: “Nó giải quyết vấn đề gì?” rồi mới hỏi “Gõ lệnh nào?”.

Hãy vẽ pipeline project của bạn:

Stage nào tạo feedback?
Stage nào là release gate?
Pipeline xanh đang chứng minh điều gì — và còn bỏ ngỏ điều gì?

Chia sẻ stage khiến bạn lấn cấn nhất nhé.

JAVA SPRING BOOT: CŨ NHƯNG KHÔNG BAO GIỜ CỔ?Spring Boot 1.0 GA ra mắt tháng 4/2014, tính đến nay đã hơn một thập kỷ.Nhưn...
14/08/2026

JAVA SPRING BOOT: CŨ NHƯNG KHÔNG BAO GIỜ CỔ?

Spring Boot 1.0 GA ra mắt tháng 4/2014, tính đến nay đã hơn một thập kỷ.

Nhưng tháng 6/2026 nhà phát hành vẫn ra bản 4.1.0 với Spring gRPC kèm theo loạt cập nhật security, observability. Thật sự một framework 10 năm tuổi còn được đầu tư vậy thì bài toán nó giải chưa hề cũ: quản lý dependency, config theo môi trường, transaction, bảo mật, theo dõi hệ thống lúc chạy production. Rõ ràng thị trường vẫn đang còn rất nhiều dự án vận hành hoặc đang phát triển bằng Spring Boot.

Cái hay của Spring Boot lại có nhược điểm là dễ làm người học lười suy nghĩ, đặc biệt là những bạn học nhảy cóc từ cơ bản lên thẳng framework. Spring Boot code rất ngắn khi bạn chỉ thêm vài annotation là app chạy ngay, nhanh đến mức không kịp hiểu vừa xảy ra chuyện gì. Tới lúc run app không được hoặc có những lỗi phát sinh thì không thể tự debug được. Hoặc là tìm mọi cách để gắn thêm annotation, thay đổi vị trí class,... miễn sao cho chạy được là thôi mà không đào sâu nguyên nhân gốc rễ.

Với những mentor kinh nghiệm thì họ sẽ bắt học viên chạy lại chính app đang lỗi với mode debug, mở conditions report ra đọc xem Spring tự chọn bean nào và dựa điều kiện gì. Làm vài lần thì hay không còn là "gắn cho hết lỗi" nữa, mà là một quyết định có lý do đứng sau.

Ranh giới giữa học Spring Boot kiểu thuộc annotation với học kiểu hiểu cơ chế nằm ở đó: hiểu IoC/DI quản object thế nào, transaction bắt đầu và commit ở đâu, auto-configuration dựa điều kiện gì để tạo bean. Framework nào cũng có lúc lỗi thời, nhưng cách hiểu đó thì đi được qua nhiều version, nhiều framework khác.

Nếu bỏ hết annotation quen thuộc đi, bạn có giải thích được vì sao Spring chọn đúng bean đó, thay vì bean còn lại không? Hãy cố gắng đào sâu hơn nữa xuống tầng thấp của framework để nắm thật vững nhé, khi đó chả còn sợ sự thay đổi của công nghệ đâu.

Database là gì? Vì sao mọi ứng dụng đều cần Database?📱Hồi mới học, mình từng làm một bài tập nhỏ quản lý danh sách công ...
07/08/2026

Database là gì? Vì sao mọi ứng dụng đều cần Database?

📱Hồi mới học, mình từng làm một bài tập nhỏ quản lý danh sách công việc, giao diện thêm xóa sửa chạy mượt, tự hào lắm. Đến lúc tắt trình duyệt rồi mở lại, cả danh sách trống trơn, công sức gõ nãy giờ bay sạch. Lúc đó mình mới ngớ người ra, hóa ra mình chỉ lưu dữ liệu vào một biến tạm trên trình duyệt, chưa hề chạm tới Database thật sự.

💾Database là chỗ giữ lại dữ liệu để dùng lại được bất cứ lúc nào, kể cả sau khi tắt máy, sập nguồn hay restart server. Tài khoản, đơn hàng, bài viết, lịch sử giao dịch, tất cả cần một nơi lưu trữ bền vững như vậy mới tồn tại lâu dài được.

Nghe có vẻ đơn giản, nhưng cái khó không nằm ở chỗ lưu được, mà ở chỗ lưu sao cho đúng khi có nhiều người cùng thao tác một lúc. Trước kia khi làm dự án tốt nghiệp, mình và team gặp một bug mà dở khóc dở cười. Lúc bảo vệ hội đồng yêu cầu demo tính năng đặt đơn cùng lúc. Và hệ thống bọn mình sau khi đặt đơn xong thì kiểm tra ra database bị lệch tồn kho, số hàng có trong kho bị trừ âm luôn.

💻 Thế nên các bạn học Database không nên dừng ở việc thuộc câu lệnh SQL để insert, update, select cho đúng cú pháp nhé. Cố gắng đào sâu vào những góc độ thiết kế, dữ liệu nên chia thành mấy bảng, các bảng liên kết với nhau ra sao, và quan trọng không kém là xử lý thế nào khi hai request cùng chạm vào một dòng dữ liệu trong cùng một thời điểm, kiểu hai người cùng đặt một ghế trên chuyến bay cuối cùng.

Sau này đi làm đụng tới các ứng dụng tài chính, ngân hàng thì bài toán này càng khắt khe hơn nữa, chỉ một lỗi nhỏ trong khâu ghi dữ liệu dẫn tới sai lệch là đền ốm đòn luôn.

💬Đừng xem thường kiến thức Database nha các dev tương lai, không có hiểu biết về nó thì web/app các bạn tạo ra sẽ không thể phát triển tốt được đâu.

Đời không như là mơ 🫩
01/08/2026

Đời không như là mơ 🫩

Mentor iDEV review code của học viên như thế nào?⁉️Có một điều khác biệt rõ giữa việc tự học và học có mentor: là có ngư...
30/07/2026

Mentor iDEV review code của học viên như thế nào?

⁉️Có một điều khác biệt rõ giữa việc tự học và học có mentor: là có người ngồi cạnh, chỉ thẳng vào dòng code của bạn và nói, chỗ này chưa ổn, vì sao chưa ổn.

🧑‍💻Nhiều bạn làm bài, chạy ra kết quả đúng là mừng, nghĩ vậy là xong. Nhưng đi làm rồi mới biết, không ai chỉ nhìn vào kết quả cuối cùng cả, người ta còn nhìn cách bạn nghĩ ra hướng giải, cách tổ chức code, và cả việc bạn có làm việc được với người khác hay không. Vì vậy ở iDEV, review code luôn là một phần bắt buộc trong mọi khóa học, không phải hoạt động thêm cho có.

💻Ngay trong buổi học, học viên sẽ live code cùng mentor theo từng task nhỏ. Mentor không đưa đáp án sẵn mà đặt câu hỏi ngược lại, kiểu như "vì sao em chọn cách này" hay "còn hướng nào khác không", để học viên tự tìm ra lời giải thay vì làm theo khuôn mẫu. Sau khi hoàn thành, mỗi bạn chia sẻ source code để cả lớp cùng xem và cùng phân tích.

Điều thú vị là hiếm khi hai người viết cùng một bài mà ra kết quả giống nhau. Có bạn tối ưu thuật toán, có bạn đặt tên biến rõ ràng đến mức đọc là hiểu ngay, cũng có bạn vô tình lặp logic hoặc nhồi một hàm ôm quá nhiều việc. Mentor không chỉ sửa lỗi mà giải thích vì sao cách này tốt hơn cách kia, từ đó giúp học viên hình thành tư duy viết code ngay từ đầu.

👉Với bài tập sau giờ học, quá trình review vẫn tiếp tục qua GitLab. Học viên upload code lên, mentor xem trực tiếp từng file, từng dòng và để lại comment kèm lý do rõ ràng, giúp học viên hiểu nguyên nhân và tránh lặp lại lỗi ở những bài sau.

Không chỉ dừng ở mentor và học viên, các bạn trong lớp còn đọc code của nhau, trao đổi và phản biện cách giải quyết vấn đề. Đây cũng là cách làm quen sớm với môi trường phát triển phần mềm thực tế, nơi review code diễn ra hằng ngày trong mọi team.

✅Sau mỗi lần review, điều học viên nhận được không chỉ là một đoạn code sạch hơn, mà còn là khả năng viết Clean Code, tư duy thiết kế, và kỹ năng tiếp nhận phản hồi, trao đổi chuyên môn với đồng đội, những thứ khó có được nếu chỉ học qua video hay tự làm bài một mình.

Ở iDEV, mentor không đơn thuần là người chấm bài, mà đồng hành cùng học viên suốt cả khóa học để mỗi lần review đều trở thành một cơ hội tiến bộ.

💬 Bạn nghĩ review code quan trọng đến mức nào với một Developer mới vào nghề?

Clean Code giúp gì ngoài việc "đẹp"?⁉️Hồi mới học code, mình cũng nghĩ chạy đúng là được rồi không quan tâm gì khác nữa....
28/07/2026

Clean Code giúp gì ngoài việc "đẹp"?

⁉️Hồi mới học code, mình cũng nghĩ chạy đúng là được rồi không quan tâm gì khác nữa. Nghe ai nhắc Clean Code là kiểu, chắc mấy ông này thích viết code cho đẹp mắt thôi.

💻Đến lúc đi làm mới vỡ ra. Có lần mở lại file code tự tay viết chưa đầy nửa năm mà ngồi đực mặt ra không hiểu nổi hàm này để làm gì, biến x với y là cái gì. Không phải trí nhớ dở, mà lúc viết mình chẳng để tâm gì đến chuyện sau này đọc lại.

Tên biến đặt có nghĩa một chút, mỗi hàm chỉ ôm một việc thôi, vậy là đọc lại nhanh hẳn, khỏi phải đoán mò như đọc chữ bác sĩ. Cấu trúc rõ ràng nữa thì càng đỡ.

Làm nhóm thì thấm rõ hơn nhiều. Không phải chỉ mình mình đụng vào code đâu, hôm nay bạn viết, mai người khác mở ra sửa, thêm tính năng, refactor lại. Code mà rối một tí, sửa chỗ này vỡ chỗ kia, review lâu, test cũng ngán.

🧑‍💻Hồi còn học, nghe giảng viên nhắc hoài chuyện này mà nhiều lúc thấy hơi cường điệu. Đi làm rồi mới hiểu tại sao công ty nào cũng để ý ai viết code sạch, ai viết code rối. Code sạch thì cả team đi nhanh hơn, đỡ tốn công bảo trì về sau, cần đổi tính năng cũng không phải run tay sợ sập chỗ khác.

👉Giờ mỗi lần viết code, mình hay tự hỏi: sáu tháng nữa mở lại, mình có ngồi đực mặt như lần đó không? Muốn tránh cảnh đó thì phải viết cho người đọc hiểu được, kể cả người đó chính là mình.

💬Bạn đã từng mở lại code cũ của chính mình mà không hiểu nổi mình từng viết gì chưa?

Address

Ho Chi Minh City

Opening Hours

Monday 08:00 - 22:00
Tuesday 08:00 - 22:00
Wednesday 08:00 - 22:00
Thursday 08:00 - 22:00
Friday 08:00 - 22:00
Saturday 08:00 - 22:00
Sunday 08:00 - 22:00

Website

Alerts

Be the first to know and let us send you an email when Bug này idev posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Shortcuts

Share

Category