Topics and highlights
- Team check-ins & workflow: Kicked off with roll-call vibes, planning speed-run topics, and assigning tasks to Hải, Cường, and Tom. Encouraged quick 10-minute concept pitches.
- Frontend updates: Hải’s January report covered React 19 and Next.js 15.1, spotlighting the View Transition API for smoother stage animations and Deno Deploy’s new server-side rendering support.
- Tooling & libraries: Explored Transformer for running Python models in JS, Neon’s switch from Webpack to a lighter setup with better hot reloads, and HTMX’s rise with logic-in-HTML simplicity.
- Database design practices: Cường recapped scaling databases with business growth, emphasizing DBA roles, migrations, CI systems, and versioning for managing schema changes and avoiding API breaks.
- AI-driven development: Tom showcased a full-cycle approach, leveraging AI for rapid planning, task breakdowns, and proposals.
- Skillset spotlight: Highlighted team strengths, security/performance (Thành), user/data flow (Tom), and how to align them with proposals, from MVP to real-time app concepts.
- Process optimization: Detailed Tom’s AI-assisted workflow: extracting insights, crafting prompts, validating concepts, and scaling tasks with 90% accuracy, plus burning questions for client rapport.
- Q&A & next steps: Wrapped with open questions, a nod to future Tom-led sessions, and a promise to refine skills like real-time handling and proposal structuring.
Vietnamese transcript
[00:00] Bắt đầu thôi nào. Chào mấy anh em, cảm ơn đã đợi. Thành với Cường đâu rồi? Cường có lên phòng chưa? Thấy đăng ký thứ Sáu mà giờ lên đây rồi, đúng không? Tuần này Thành đâu rồi? À, lên rồi, đứng đây nè. Tuấn, Tom lên stage luôn nha.
[04:51] Đang xem mấy cái bài, tự nhiên cái link này Tom ơi, đẹp chưa? Để anh sửa lại. Ngày hôm nay 186 giao dịch, 1 user, 30 ICY member như cũ, 5 cái inactive, 1482 giả mạo. Hai channel chat nhiều nhất, ba channel chat nhiều nhất, mấy người chat nhiều nhất là ai? Ờ, tiêu rồi! Còn ai nữa không? Hôm nay thiếu ai không? Có hai chủ đề cũ: một cái là "run and report". Sáng nay anh post link lên rồi, chắc vậy, để kiểm tra lại. Cái thứ hai là bài design của Cường, anh chưa biết nội dung.
[06:03] Bài này là cái gì vậy, ngồi nghe mà chẳng hiểu gì luôn. Bài số ba là nối tiếp cái series hôm trước, mấy anh em viết xong, làm xong, giờ nó thành hình cụ thể rồi. Qua 3 tháng thì team cũng có vài cập nhật mới, hướng đi này rõ ràng hơn chút. Hệ thống thấy cũ rồi, tí anh forward link cho mọi người đọc trước qua email.
[07:10] Đăng ký dùng thử đi, tí nữa vào xem. Plan là vậy. Chắc ship bài của Hải trước, rồi tới bài của Cường, rồi tới bài của Tom, mấy phần Tom làm đó. Nội dung hôm nay chắc vậy. Anh em xem thử còn thiếu ai không, hay thấy ngắn quá, có gì liên quan nữa không? Ai thiếu vậy? Thành lên chưa? Ờ, đệ Thành đỉnh quá, hết việc để làm rồi. Anh cũng nghĩ vậy.
[08:55] Đợi chút nha, đợi đủ người rồi tụi mình speed-run mấy chủ đề này. Chủ đề cũng đơn giản thôi. Anh em cố gắng tóm gọn bài của mình, nói concept, idea trong 10 phút thôi, đừng dài quá, để dành thời gian cho buổi kia. Nếu cần hơn 10 phút thì nói dài hơn chút, vậy nha. Tuần sau có lịch lên văn phòng, tuần này check-in bình thường thôi.
[09:57] Tuần sau dựa trên danh sách đăng ký, anh sẽ đề xuất với Huy Nguyễn làm trò điểm danh cho đủ mặt. Thành policy luôn rồi. Tuần sau làm điểm danh cho đông đủ. Đoạn tiếp theo thì mấy dự án cũ giờ gần xong hết rồi. Giờ dep blockchain với AI là vua của mọi nghề, anh em nào muốn làm trực tiếp thì phải lên kế hoạch cái đó. Có ai trùng gì không, hay còn ý gì nữa không?
[10:58] Chắc bắt đầu với bài của Hải trước nha. Hải ơi, mời em trình bày. Dạ, mọi người thấy hình của em rồi đúng không? Em tóm tắt Frontend report tháng 1. Tháng 12 năm ngoái, React 19 release đi kèm với nó là thằng Next.JS 15.1 cũng tung ra một phiên bản mới.
[12:07] Để hỗ trợ cả thằng Next.JS lẫn thằng React 19 luôn. Bên Reactthì em thấy nó đang làm một cái API khá hay, gọi là View Transition. Browser giờ đã có API View Transition này rồi, nhưng trước đây thì React chưa hỗ trợ. Một số thư viện đã viết và dùng cái API của bên kia, nhưng khi đưa lên React thì gặp vài vấn đề về performance. Ờ, tụi nó đang đợi API này từ React để hỗ trợ tốt hơn, giúp giải quyết vấn đề performance rõ ràng hơn.
[12:48] API này dùng để làm animation khi chuyển giữa hai stage của trang web. Ví dụ như anh kéo xuống dưới đây, nó sẽ như ví dụ bên dưới này, cái stage đầu tiên là box nằm trên, stage thứ hai thì box nằm dưới. Thay vì chuyển stage mà nó nhảy thẳng xuống luôn, thì View Transition này hỗ trợ mình tạo hiệu ứng animation, nhảy qua nhảy lại các kiểu. Tương tự, với mấy cái như hình ảnh, nó cũng tạo hiệu ứng animation.
[13:28] Khi chuyển đổi hình ảnh, thay vì chỉ nhảy sang hình khác ngay lập tức. Dạ, cái API này vẫn đang trong giai đoạn thử nghiệm thôi. Phải dùng phiên bản thử nghiệm thì mình mới xài được. Nhưng nó hứa hẹn sẽ tăng performance khi sử dụng. Vì trước đây, thằng Motion cũng đã hỗ trợ rồi, nhưng chỉ trong môi trường thuần thôi. Còn nếu lên thì nó gặp vài vấn đề performance, tại vì nó phải xử lý cả trước và sau khi set.
[14:07] Cho cái phần này, bên SCS thì có mấy thứ như thằng Deno Deploy. Lúc trước nó chỉ hỗ trợ deploy static site thôi, nhưng giờ nó đã hỗ trợ hoàn toàn để deploy cả thằng Next.JS luôn, kể cả server-side rendering. Giờ mình có thể dùng Deno thay thế, hòa chung được, để deploy một ứng dụng NS. Dạ, cái này vẫn chưa có gì để nói hết. Còn cái thư viện Transformer Z này cũng khá hay. Bản chất của nó là đang biến mấy cái model.
[15:03] Bản chất của nó là đang biến mấy cái model viết bằng Python lên thành JS, để mình có thể chạy trực tiếp mấy cái model này trên trình duyệt luôn, không cần qua API hay ngôn ngữ Python gì hết. Như trong bài này, nó chạy được cái sentiment testing. Ví dụ như positive hay negative, hoặc là object detection, như phát hiện con mèo. Bản chất thì em nghĩ mấy model khác, mấy cái pipeline khác, vẫn chạy được, miễn là nó được hỗ trợ bởi thư viện này.
[18:33] Bọn em buộc phải hỗ trợ kiểu dù có mạng hay không, data vẫn phải lưu được hết. Sau đó chọn cách lưu xuống IndexedDB, rồi khi có kết nối trở lại, mới đẩy data lên server. Kiểu như vậy. Ở dưới đây nó có hướng dẫn step-by-step để xử lý. Làm vậy thì sẽ gặp vài vấn đề, như list data bị fail khi sync chẳng hạn. Nó chỉ ra một số cách để giải quyết mấy vấn đề đó.
[19:22] Kiểu như vậy. An mới post link gì đó à? Zero là con gì? An mới bảo gì kìa, có liên quan không? Bữa trước thấy Lập, cũng bảo cái vụ "local first", chắc giống vậy đúng không? Mọi người chung bài toán, thi nhau đi giải. Tiếp theo, bên Win thì có nhắc. Bài này có update chút, giờ nó support thằng đó luôn rồi. Lúc trước Node.js thì phải có command line để combine thằng Typescript ra js mới chạy được. Còn giờ nó chạy trực tiếp luôn.
[20:01] Như nó chạy bằng cái command line, load file luôn. Theo em thấy, còn một bài nữa về anh dec này, kể về chuyện các dependency ở bên MBM. Nó cứ ra version mới hoài, kiểu mỗi version lại kèm theo mấy cái breaking change. Ổng nói làm vậy khá cực, muốn update version nhưng sợ app không theo kịp. Không phải lúc nào cũng có thời gian để xử lý hết. Nên ổng không thích thằng React lắm, chọn hướng khác. Ổng bảo thằng này sẽ ổn định hơn, ít bị thay đổi như vậy. Ổng ưu tiên thằng này hơn. Thằng HTMX thì cũng nổi lên đang đứng top 1.
[21:07] Dạ, còn một bài cuối nhanh về thằng Neon. Thằng này cung cấp dịch vụ về database. Nó vừa chuyển từ Webpack sang cái khác. Trong quá trình đó, nó gặp vài vấn đề, nhận ra một số hạn chế của Webpack. Như là nó không support tốt, có một danh sách dài những khó khăn ngay đây. Nhưng kết quả cuối cùng sau khi chuyển thì nó cảm thấy cái mới ổn hơn Webpack. Thứ nhất, nó ít lỗi hơn, reliable hơn thằng Webpack. Thứ hai, config của nó đơn giản hơn. Như nó nói, chỉ cần mười mấy, hai mươi cái plugin của Webpack là làm cho nó nhẹ hơn nhiều. Em cũng không biết tại sao nó để vậy.
[22:03] Nhưng mà cái kết quả cuối cùng sau khi chuyển thì nó cảm thấy cái hot reload của nó ok hơn thằng Webpack. Nó ít kiểm khi bị full reload hơn thằng Webpack. Thứ hai là config của nó, nó simple hơn. Như nó nói là nó cỡ mười mấy, hai mươi cái plugin của Webpack gì đó, nó làm cho cái của nó nhẹ hơn nhiều.
[23:01] Bài này nó chủ yếu là nói về những cái khó khăn và những cái kết quả cuối cùng khi mà nó chuyển từ Webpack sang cái kia. Dạ, vậy là cái của mấy anh em đang thay đổi à? Đang chuyển qua từ cái Webpack chuyển qua cái con kia là một đúng không? Cái React ở trên kia thì sao?
[23:50] Chuyển qua HTMX hả? Là hai rồi, còn gì khác nữa không? Xài con Deno à? Với lại TP hả? TP thành main framework hả? Ừ, dạ, cho nó rồi. Còn mấy bài khác thì mọi người có thể đọc thêm trong cái này. Dạ, cái gì nhờ Hải post lại cái link nhé? Cảm ơn Hải, cảm ơn mấy anh em đã cho cái reply. HTMX nó là cái gì mà tại sao lại được chọn vậy? HTML nhưng mà có logic trong đó hả? Kiểu nó sẽ thêm một số thằng trực tiếp vô cái HTML, rồi dùng để trực tiếp ông lại chê nhau thôi. Cái trò này từ thời Backbone.js với lại Knockout.js.
[25:06] Đây cả chục năm, giờ mới làm y chang vậy mà. Anh em có câu hỏi gì không? Cho một phút comment thêm. Có gì cần update thêm không? Có gì nhờ Hải post link vô, cho vô ngoài random hay vô group chat nhé. Mời bạn tiếp theo. Mời Cường đi nhanh qua chủ đề về database design. Dạ, bắt đầu luôn. Tiết học lịch sử hả? Cái này, cái bài mấy cái practice này là có từ 2017 rồi.
[26:17] Em chỉ recap lại thôi à? Tổng kết hả? Tổng kết cái kỹ năng thiết kế dữ liệu, tip entity hả? Dạ, không, không hẳn là quản lý dữ liệu. Kiểu mấy cái practice để mà mình handle mấy cái kiến thức trong quá trình mình phát triển, mình grow cái database của mình lên. Dạ, em xin vô luôn. Database với lại cái hệ thống mà mình phát triển thì lúc nào cũng đi đôi với nhau. Khi mà phần mềm của mình scale up để bắt kịp cái business demand, thì mình bắt buộc phải scale up cái database của mình lên để quản lý số lượng lớn các.
[26:51] Dữ liệu trải qua từng năm. Ví dụ như từ 2015, Amazon mới có khoảng 50 triệu dữ liệu, thì bắt đầu tới 2020 đã phát triển lên tới mức phải handle 200 triệu dữ liệu. Vậy tại sao cần phải có những cái practice này? Khi mà cái database của mình có tới cả trăm hoặc cả ngàn schema, thì cái management system như SQL Server hay mấy cái hệ thống quản lý dữ liệu khác, mình nhìn vào sơ đồ schema, table hay data thì không thể biết hết được tất cả.
[27:27] Các cái context. Tại sao những cái change này đã được apply vào trong hệ thống? Để đúc kết ra được thì sẽ có một vài practice. Bắt buộc phải có sự kết hợp giữa con người và hệ thống để quản lý các kiến thức này. Tất cả những cái này chỉ là practice, không bao gồm việc lựa chọn hệ thống quản lý database hay thiết kế database schema. Nó bao gồm cách mà mình chia sẻ kiến thức database, lưu trữ những kiến thức này. Và khi những cái database change được boost lên thì sẽ có một hệ thống riêng để quản lý mấy cái change này, như continuous integration và những cái tương tự.
[28:02] Đó là những cái change này sẽ bắt buộc phải follow một vài refactoring rules. Về no-sharing thì bình thường trong tổ chức của mình sẽ có một người gọi là DBA. Người này sẽ quản lý cũng như phải chia sẻ tất cả kiến thức và các sự thay đổi của database được apply vào hệ thống. Ví dụ, nếu mình có nhiều team dev, dev 1 khi phát triển phần mềm A, dev 2 quản lý phần mềm B, thì cả hai khi push change lên database của hệ thống sẽ phải hỏi qua người DBA. DBA này sẽ verify từng change xem nó có tác dụng gì, để quyết định cái change đó có make sense với database chính hay không.
[28:34] Khi từng dev push cái database của mình lên, thì dev này sẽ verify với hệ thống chính để xem các API gọi đến database có bị ảnh hưởng gì không. Sau đó sẽ đánh giá cái change này có cần thiết không. Nếu cái change này ảnh hưởng quá lớn đến hệ thống, thì người DBA có thể reject cái change đó, bắt người dev phải update, refactor hoặc chỉnh sửa lại cho hợp lý. Khi cái change đã được approve, thì người DBA sẽ phải document lại rằng cái change này có ý nghĩa gì, tại sao cần cái change đó, rồi post một cái migration lên cho database master bắt đầu cập nhật.
[29:14] Những cái dữ liệu này còn phải được lưu trữ ở một chỗ nào đó mà tất cả mọi người đều dễ dàng truy cập và tìm kiếm để biết tại sao những thay đổi này cần thiết. Tất cả những thay đổi này sẽ được bỏ vào một cái repository, giống như một coding project. Cái repository này chứa tất cả database artifact, bao gồm script chạy database, credential login, configuration, và mức độ dung lượng tối đa mà các instance này có thể quản lý, cũng như các documentation của hệ thống. Cái repository này cũng tương tự như một coding project, sẽ được quản lý bởi một version control.
[29:51] Cũng như là tìm kiếm để biết được là tại sao những cái thay đổi này cần thiết. Tất cả những thay đổi này sẽ được bỏ vào trong một cái repository giống như một coding project vậy. Mọi người có gì hỏi thêm không?
[30:39] Để mọi người có thể check, cũng như kiểm tra các cái change, context và history của những thay đổi này trong hệ thống, thì mỗi lần thay đổi, người push cái migration này sẽ tạo một cái pull request và thêm description. Description này giải thích tại sao cần cái change này, nó cần thiết ra sao, và những hệ thống nào sẽ bị ảnh hưởng bởi cái change đó. Người review, đa số là các dev của những API mà cái change này tác động trực tiếp tới, sẽ vào xem xét.
[31:14] Sau khi những thay đổi này được merge vào nhánh master, sẽ có versioning để mình có thể rollback hoặc deploy các version này vào từng hệ thống để dev, testing, và cuối cùng là đưa lên production. Khi mà mình có nhiều dev instance giữa các version, thì lúc dev từng hệ thống riêng, mình sẽ phải checkout ra từ một instance của master database để sử dụng cho việc development. Như vậy, khi thay đổi gì đó hoặc migration một cái mới, mình không ảnh hưởng trực tiếp tới cái database chính.
[31:52] Khi đó, mình cần có một hệ thống CI. Mỗi khi thay đổi gì trong instance mà mình dev, mình có thể dễ dàng verify xem cái change này có break master database hay không. Đồng thời, khi ai đó push một cái change mới lên master database, mình sẽ được thông báo về schema thay đổi hoặc resource conflict trước khi làm chậm tiến độ dev. Khi boost một thay đổi trên database, những thay đổi này bao gồm mấy bước như sau: thay đổi một cái database schema.
[32:25] Khi push một thay đổi, mình phải tạo một migration script lên database đó. Sau khi script này được merge, mình phải đổi database access code để API có thể dùng cái change mới đó. Đối với những database change như thêm một column mới, thì có thể không nhất thiết phải thay đổi access layer của API khi change này được push lên. Vì một số API không cần dùng tới cột mới đó. Ví dụ, mình có bảng user với name và address, một service mới cần thêm field birthday vào bảng user, thì các service cũ như service gom nhóm user theo address không cần thay đổi gì trong API để tích hợp cái change mới này.
[33:07] Đối với những change ảnh hưởng lớn, như giới thiệu một non-null value hay tách bảng, thì tất cả service phụ thuộc vào nó cần phải đổi data access layer để tránh lỗi. Ví dụ như bảng user vừa nãy, nếu tách bảng user ra, thì service nào dùng bảng đó phải thay đổi toàn bộ access layer để không bị lỗi. Ngoài ra, có thể dùng một cái gọi là transition interface để dần dần apply các thay đổi mới, rồi boost cái change đó mà không làm crash API cũ.
[33:45] Sau khi đã refactor và apply change lên master database, mình còn phải notify tất cả các service dùng database này để tránh break mấy cái API đó. Đồng thời, mọi người có thể contact nhau để resolve config khi thay đổi master database. Về phần recap, trong quá trình develop một software, khi phần mềm phát triển thì bắt buộc database của mình cũng phải phát triển theo. Để mọi người đều nắm được thông tin và context của từng cái change trong database này, cần vận dụng tất cả kiến thức để chia sẻ và sắp xếp kiến thức của mình.
[34:32] Đồng thời là tất cả những cái change này đều phải release tường tận để mà tránh các cái conflict thời gian, mọi người resource conflict giữa các cái database change. Bài này thấy nó có giá trị ở chỗ góc nhìn. Chắc là giống như góc nhìn dev, nhưng mà nó đứng góc nhìn về chuyện là thay đổi đối tượng làm việc chính.
[35:21] Thông tin và cũng như context của những từng cái change bên trong database này thì cần phải vận dụng tất cả những kiến thức để mà know sharing cũng như là sắp xếp các cái kiến thức của mình và đồng thời là tất cả những cái change này đều phải release tường tận để mà tránh các cái conflict thời gian mọi người resource conflict giữa các cái database change. Hết rồi. Mọi người có gì hỏi thêm không?
[35:58] Là không phải codebase mà là cái database đúng không? Theo hướng đó nhiều. Cứ nghe tới đoạn này thấy hơi meta quá, kiểu hệ thống lớn chắc mới quan tâm, còn hệ thống như hiện tại thì hơi khó áp dụng hả? Khoảng hệ thống cỡ 20 table là thấy hơi lâu lâu, nhìn vô cũng hơi chóng mặt rồi. Đúng rồi. Vậy cái này liên quan tới chuyện documentation, quản lý versioning, với cả làm monitoring. Không phải version monitoring, mà là notification cho mấy cái team khác đúng không? Dạ, vậy nó còn ít lắm, nhưng mà đúng rồi. Mấy cái này đưa vô thì hợp lý, vì có góc nhìn.
[36:50] Quản trị data trước tới mấy cái kia. Logic thì logic ở đây, mai mốt data chạy rồi. Anh em có hỏi gì Cường không? Không thì sẽ kết thúc ở đây. Bài này có giá trị về góc nhìn. Nghĩ mấy anh em khi làm backend mà muốn làm giàu thì sẽ phải theo dự án suốt đời. Dự án càng lâu thì nghĩa là dự án càng có tiền. Thấy vậy, đi được với dự án càng lâu thì về bản chất nó sẽ ok. Nhưng mà thường dev thì nó sẽ lười. Dev thấy cái gì mà làm lâu quá thì bị chán, hành vi rất là lạ.
[37:40] Trước khi qua bài tiếp theo, để đóng góp cho buổi hôm nay, một cái keyword của tuần này, trong quá trình đi ngồi đọng lại, có một keyword mới, mới học được. Từ mới dành cho những bạn chưa biết, giống như anh chưa biết. Đây là kiểu hôm nay lên, có một trường phái tên là Luddism. Luddism là một cái chữ xuất thân từ thế kỷ 19, khi cuộc cách mạng công nghiệp diễn ra. Ngành những ngành liên quan tới dệt may được tự động hóa, thì cái đó tức là những người theo có cửa, họ tên là Luddites sao á, mới đi đốt mấy cái máy đó.
[38:34] Mấy cái máy đó cướp việc của mình, cướp chén cơm của mình, nên họ đi phá mấy máy đó. Thành ra cái này trở thành một trường phái Luddism. Tức là tầng lớp working class đi chống lại xu hướng hiện đại hóa. Rồi chữ khóa tiếp theo đi sâu tiếp thì sẽ ra Neo-Luddism, với lại cái thằng Luddism ngay đây. Cái gì anh em đọc thêm nhé, thấy khá là relevant với mình sắp tới. Theo những dự đoán mà hôm trước.
[39:18] Mình ngồi nói với nhau á, thì sắp tới chắc sẽ nhiều người dậy lắm. Ở trên Reddit thì nó có một cái bài cách đây 2 năm, có cái làn sóng Neo-Luddism mới sẽ xuất hiện. Giờ lên thấy cũng nhiều lắm ha. Thì cố gắng, góc nhìn anh thì cố gắng, anh em không nên, không nên theo trường phái này. Hồi phát triển sẽ đi tiếp, không nên chống lại bánh xe lịch sử. Rồi có luôn cái subreddit tên là Luddism luôn, nói từ Luddism luôn. Không chỉ nói về automation, mà nói về đủ thứ trả lại công nghệ trên đời. Cảm giác lạc lỏng, cảm giác thế này thế kia. Đây là keyword khá là thú vị, ha, anh em.
[40:08] Không bị dính vào đây ha. Rồi cái số hai nữa là có cái liên quan đến cái này. Thằng vừa rồi mới ngồi, mới ngồi tìm ra này, đó là U.S. geopolitical. Có một góc nhìn về chuyện nước Mỹ phát triển như thế nào. Anh nghiên cứu về thị trường vốn, có cái dòng tiền đầu tư nó chảy đâu, nên vô tình lọt vô cái chủ đề này. Đây là chủ đề thứ hai, thấy cũng khá thú vị. Maybe anh em sẽ quan tâm. Chủ đề này liên quan tới macro economy. Thì ra nó được, từ cái trị nó chuyển qua thành macro economy.
[40:56] Nước Mỹ sẽ có xu hướng có hai phái thôi. Một là isolationism, tức là cô lập hóa. Một chữ khác thể dùng cái đó, tính làm đây ha. Thì trong cái movement này, nó nói gì? Nước Mỹ sẽ có xu thế là nó co mình lại, không deploy mấy cái resource đi khắp nơi để giao thương nữa, mà gom cái đó về, đứng đó phòng thủ. Đây là cái cụm thứ nhất. Hiện tại, tất cả những tin tức mình thấy được á, thì nó đang trong cái đó, protectionism hoặc là isolationism. Cụm này, hướng thứ hai mình thấy là globalization.
[41:41] Globalization thì những cái sáng chế, những cái công việc sẽ tập trung vào chuyện trading với nhau nhiều hơn, giao thương nhiều hơn. Nước này nước nọ quăng những cái đó đi khắp nơi. Mỹ sẽ có xu hướng là out ra ngoài, những anh chị em theo cái phái đó. Những cái nước theo cái phái đó cũng sẽ có xu hướng cởi mở hơn, chạy khắp nơi. Thì nó là cái tình trạng trong trạng thái mà nó diễn ra từ report, từ năm 45 tới gần đây, thì đã đi thành những cái cụm nhỏ.
[42:20] Trong giai đoạn sau chiến tranh với Nhật, đi nút cho Nhật hai cú xong rồi, thì giúp Nhật với Đức sau Chiến tranh. Nó sẽ giúp tái thiết lại, thì bắt đầu nó deploy, nó globalization theo hướng đó. Đó là cái phase ban đầu. Nó bắt cái đoạn đó, đến khi mà Nhật mạnh quá rồi phải không, thì bắt đầu sẽ bị nerf lại bằng một số sự kiện nhất định. Ở đây có sự kiện này, với cả sự kiện tên là VIA này, ra thông tin hơn. Nhưng cơ bản là vậy. Thì idea chính là gì? Idea chính là đang có cái xu hướng học từ lịch sử trước đây.
[43:09] Từ cái Great Depression năm 1930 cho tới giờ, hiện nay 2020, có một cái nước Mỹ đang trở lại với trường phái protectionism. Sẽ dẫn đến tất cả những nước khác cũng sẽ đi theo cái này. Ai cũng sẽ là dân tộc mình là cái chính. Thì cái chuyện mà mình nhảy khắp nơi sẽ ít lại hơn, so với giai đoạn này. Đường đỏ là đường Trung Quốc nè, đường màu này là đường của Nga nè. Nga sau năm 91 cũng được buff xong rồi, nó đi, nó quất Crimea, cái bị nerf lại. Hiện đang tới Trung Quốc.
[43:54] Mà cái này sẽ ảnh hưởng gì? Tới thế sẽ ảnh hưởng là thị trường thì nó sẽ khó khăn. Theo cái hướng nó sẽ favor một số nước nhất định. Không biết Việt Nam, Việt Nam hiện nay trong top 4 mấy cái nước có delta import-export với Mỹ vẫn cao, nhưng mà vẫn được buff. Không biết có được ăn nhậu gì không, nhưng về cơ bản thì mọi người sẽ chạy chậm với tiền mình hơn. Thì hai cái hướng chính nè. Một hướng là công nghệ nó ra, nó replay liên tục để trường hợp mà cái cụm từ này lại được gọi tên lần nữa.
[44:35] Với cả cái xu thế về kinh tế toàn cầu đang dày, anh đáng là nó sẽ đi kèm với cái gì mình từng nói với nhau. Thị trường càng ngày càng khó tính, được proven qua cái này ha. Dễ dàng thấy với mình thì mình sẽ phải behave như thế nào. Mời Tom lên show hàng những kỹ năng của Tom. Anh nghĩ là mấy anh em trong team sẽ cần đấy. Anh em trong team mình sẽ cần những kỹ năng mà Tom nó được từ cái làm việc với ai ha.
[45:31] Trong team mình hiện tại á, có một số cái mình không nói về hướng phát triển của software nữa nha. Cái đó thì nói với nhau suốt rồi. Nhưng mà trong quá trình làm việc với Tôm, anh nhận ra Tôm có một kỹ năng rất hay. Đó là gần như nguyên cái life cycle của chuyện làm phần mềm, một mình Tôm gần như dùng khả năng viết code, tự động hóa bằng tool, tự mình viết agent luôn. Thì gần như cả quá trìn h từ dev ban đầu, capture cái insight dự án, xong rồi lên planning.
[46:07] Cả các thứ, Tom xử lý rất OK. Nên hiện tại anh muốn em show một tí [âm nhạc] về cái approach của em trong quá trình làm việc. Khi em nhận được đề bài cho tới lúc em đến cái planning của em, nó như thế nào, em đã làm ra sao? À, OK, chắc để em share screen. Hy vọng không có gì nhạy cảm. Anh nghĩ là mình lấy luôn cái đề bài mà tí nữa mình sẽ đi sâu, sẵn đó. Ô, đề bài chơi cái đó luôn đó. Mình đang không biết là cái gì đó, mình cũng chưa đi sâu luôn. Thì giờ cái phong hợp nhất đang gần như là zero.
[46:55] Nó có một cái ví dụ về đề bài thôi đấy, cho tới lúc mà em đến cái kia như nào. OK, để em share screen, tìm lại cái chỗ đó, đúng không? OK, thông thường, logic phía em là như thế nào? Mình có data, mình muốn gỡ ra những ý của cái data này. Nếu mình có mấy cái ảnh này, thì ví dụ em sẽ cởi hết chỗ này, sau đó extract ra. Cái app này nó có những cái gì mình sẽ phải để ý. OK, sau đó là những direction mình muốn cho nó, giải thích cho mình. Vì luôn luôn là có thể mọi người xem cái app này.
[47:59] Có thể là Airbnb, hoặc là dạng app cho personal trainer và lifestyle trainer. Thì ví dụ ở đây, em muốn tìm kiếm kiểu "What the hell", thì trước tiên em sẽ sắp xếp một cái prompt. Một là, nếu context là bây giờ em just about to have a meeting with client that asks us to improve their user experience. Sau đó là ý context của bên ngoài, rồi context của bên mình là "I have some idea of what they may want". Câu hỏi là có cần input luôn cả cái brief của cái đưa mình không? Ở đây không có. Sau đó là, this chính là cái này.
[49:08] Nó sẽ là objective, adjective, context. This is the email they sent to us. Sau đó, em muốn cái vision chính là "What is the vision, goals, and objectives for them asking us to help improve?". Từ cái này, em sẽ sinh ra một số context em dùng để gửi lại cho bên phía AI. Thực tế thì cái này nó chắc em làm rồi chứ? Ờ, cái đứng ra là model nào cũng được, nhưng thinking model sẽ giúp mình kéo ra những góc nhìn mà mình không phát hiện ra. Những thinking model rất là siêu về mấy cái đấy.
[50:15] Thì cũng hơi functional, user app-centric. Từ cái context này, em sẽ biết app nó là gì, sau đó hình dung cái vision họ đang muốn cần là cái gì. À, chính là có cái gì chi tiết hơn về user, user experience. Thì như vậy, em sẽ hỏi câu hỏi là "What images, what bọn này muốn?". Bọn này không muốn gì đâu, bọn này đang muốn là sẽ clone cái app này, chứ không phải là improve cái app này đâu. Cái app đã có sẵn rồi, và giờ nó muốn clone lại, mirroring đúng không?
[51:07] Cái này là một cái đã có sẵn, lại mình làm. Với cái chuyển trường hợp này thì sẽ sinh ra một số câu hỏi như "Are there ways their app is extending to? What are your thoughts?". Sau đó, dần dần em xây dựng một cái picture. Từ cái picture này, sẽ sinh ra một cái prompt model cuối cùng để gửi cho bên phía làm cho mình. Ví dụ là tiếp tục về một cái dự án đã proven model shortcomings. Như vậy mình sẽ có một số cái mình phải chú ý. Chú ý bên phía mình sẽ phải thử bằng tay những cái gì nhỉ?
[52:15] Chi tiết về concept validation này. Chính là cái gì nó work rồi dùng cái đó thôi. Concept như vậy thì em sẽ làm một cái prompt là "Give me a proposal to pass on what I learned about this client, their vision, goals, and objectives, and help me consolidate a direction to create a proposal. This proposal ideally isolates and connects dots: what the story is đằng sau họ đang muốn cái gì, and what they want us to consult, develop?".
[53:23] Về cái chuyện proposal này nó sẽ ra dạng như thế nào, sau đó từ cái này, vì mỗi thứ mình dùng với AI nó sẽ có reference sẵn rồi, em sẽ copy một cái reference mình có sẵn. Là cái proposal đã làm sẵn, ví dụ trước là cái này. Sau đó là mình sẽ copy cái proposal của bên phía chẳng hạn đi, nhân đi, đi này đi nhỉ. Hình như là hình như internet đâu á? À, chắc copy nhầm này. Đúng ra là mọi người có thể ra cái này, hoặc là download. Use reference to create the proposal, or just in case, don’t take elements.
[55:16] From but do follow the proposal format để adapt to what we learned and what they wanting to meet the trust. Sau đó, luôn luôn là mình sẽ expect cái proposal này nó không ổn định. Nó sẽ ổn định lúc mình bỏ thêm những idea, những idea mình thấy là mình có thể involve bản thân mình vào. Vì do mình đang xem khía cạnh của họ là dạng như thế này, thì bên phía mình sẽ làm được cái gì? Ví dụ skillset bên phía em khuyến khích là giỏi về user experience, user flow, data flow. Trong này mình có Mirror được cái app và optimize cái data flow, user flow chẳng hạn.
[56:10] Hoặc là bên phía anh Thành là optimize về security và performance. Làm như thế nào để apply đúng cái project proposal này? Thêm về mấy cái kiểu good-to-have: performance và security. Nếu là dạng MVP thì mấy cái này sẽ không consider mấy chuyện hack. Là những cái design liên quan với data. Ví dụ bên phía em thì hay thiết kế data dạng là temporal state, event store, hoặc là thiết kế uniform.
[56:51] Như thế nào để apply đúng kỹ năng của mình trên computer science về cái này? Cho nó không phải đơn giản quá, nhưng sẽ simplify, maintain cho cái chuyện cái app này nó đưa ra. Nếu mà trên đây với cái tham khảo này đi, bây giờ sẽ tới kiểu anh sẽ cần mấy cái để chốt được cái deal đúng không? Mình sẽ phải cần những câu hỏi để hỏi xem với bọn đó như thế nào. Giống như con open deal, mình open book á. Mà mình nói đi thì phải cần mấy câu hỏi đấy nữa, kèm với chuyện gần như phải suggest được cái lịch làm việc, cái milestone làm việc tiếp theo giữa mình với bọn đó.
[57:28] Cần mấy câu hỏi đấy nữa, kèm với chuyện là gần như phải. Em làm như nào? Building rapport, sau đó là xem về burning questions chúng nó. Thì nếu mình có chuyên về nghề của mình, thì mình sẽ suy ra mấy cái câu hỏi cũng không khó lắm. Nhưng nếu mình thấy là mình hơi bị stuck, mình có cái block gì đó, thì mình sẽ nhờ AI cho hỏi mấy cái question.
[58:14] "So we haven’t met with this partner yet, with this client yet, but we want to make a deal with them. What should I do to help build rapport and meet the three burning questions I need to get this deal off the ground and solve any technical concerns?". Thì cái này là good start, mình sẽ dùng cái này cho bên phía AI suy ra một số câu cho mình. Sau đó mình sẽ dựa trên cái này suy ra thêm. Nếu mình có suy ra thêm thì mình sẽ bổ sung thêm ở trên proposal và add thêm cũng realistic thôi. Không phải riêng bên phía Gemini, nhưng có một số app như Claude hoặc là ChatGPT, mình sẽ phải làm như thế nào.
[59:12] Những cái due diligence mình sẽ phải làm như thế nào? Những cái burning question, ví dụ ở trên này mình không có context của trước, thì dùng đi. Nó kiểu như thế ngoài đó. Mình muốn đặt mấy cái goal như vậy, đứng ra là ở trên cái proposal đầu tiên, mình đang hơi nghi ngờ là mirroring là tại sao họ mirror? Nó sẽ hở ra ở trong cái intent của cái proposal đầu tiên mình xây dựng cho họ. Nên là nó sẽ liên quan với cái này. Lúc mình có thêm không nhất thiết.
[59:50] Sẽ dùng luôn cái này, nhưng từ cái này em sẽ suy ra là, à, maybe góc nhìn về handling real-time thì sao? Maybe bên phía họ thì không phải real-time, nó sẽ kiểu như booking appointment app. Và nếu mình ghi về dạng real-time, họ có muốn đi hướng vision đó không? Để đem ra consult xem là họ muốn cái app nó kiểu đẹp hơn, ổn hơn, hay là họ muốn cái mới hơn, hoặc kiểu risky hơn? Nó sẽ là mấy cái step mình hỏi, mình chém, để xem họ reply như thế nào thôi. Và nó không có hại.
[01:00:34] Vì nó cũng là câu hỏi hợp lý mà. Rồi, ví dụ như bước tiếp theo dev này nó hit đi, thì sau đó cái đoạn mà lên to-do rồi, kể mọi thứ thì như nào? Dạ, dạ, nó cứ hình dung. Em có một số cái cứ hình dung là cái điều này đã OK rồi. Sau đó em bỏ sung cái technical direction mình đồng ý để đi tiếp theo với họ. Ví dụ là real-time đi, "We think they want something like this, but are open to the idea of a more real-time something like Grab, Uber for the personal trainer". Trước tiên em sẽ xây dựng cái Technical proposal.
[01:01:33] Như chắc không cần đâu, thông thường em sẽ xây dựng cái đó để làm rõ góc nhìn. Nhưng từ khía cạnh này, thì ví dụ là "Help me create tasks for frontend, backend". Tại vì cái đoạn giữa mà Tôm em sẽ figure out ra tất cả mấy cái diagram, flow, rồi tất cả mọi thứ. Phải chốt cái đấy trước, mới base cái đấy bắt đầu làm cái breakdown đúng không? Nên để đơn giản hóa hôm nay mình sẽ nhờ bên phía AI suy ra luôn.
[01:02:11] Cái này nó là một cái góc sơ sơ, nhưng mình sẽ bổ sung thêm là "We are planning to use Timescale and RxJS to do the sync and part real-time features of the app. We are most comfortable with React for frontend, and our house mostly uses all this in mind. Create and format tasks with description, user story, and acceptance criteria". Mình sẽ nhờ bên phía AI viết giúp mình cái này luôn. Sau đó, nếu mình dùng thì mình sẽ copy cái copy epic là cái gì, copy story là cái gì, copy cái story, sau đó bỏ xuống cái criteria.
[01:03:44] Cái này thì bên phía em thì làm thêm cho về cũng là cho bản thân. Vì ở đây đang là story, giải thích cái story, xử lý cái story. Lúc mình đến technical, technical nó chỉ cần confirm là nó có đạt đúng tiêu chí của story không. Vì nếu story đó nó tồn tại chung với cái vision của họ, coi như mình làm thành công bên phía họ rồi phải? Nhưng mà dự như cái sườn này là bắt đầu scale lên được một cái chất.
[01:04:23] Chờ cho tất cả những cái liên quan cho backend. Thông thường trong technical proposal hoặc là cái context, em sẽ bỏ xuống thêm boilerplate, những cái code mình đã dùng rồi, những cái concept mình muốn apply ở trên cái app này. Với goal chính là goal của mình dựa trên goal của họ. Copy bên phía họ thì nếu có cái lúc có cái đấy xong, sau đó xây dựng mấy cái test này, thì sẽ có đầy đủ để mình breakdown đúng cái task mình cần thiết nhất. Ờ, đúng là nó sẽ độ chính xác tầm 90 phần trăm, nhưng 10 phần trăm còn lại nó sẽ bị thừa.
[01:05:02] Nhưng mà đỡ hơn là mình bắt đầu ở chỗ kiểu zero đúng không? Rồi, chắc tới đây thôi. Giờ Tom anh bắt đầu có con, với lại khách hàng thật rồi. Tí nữa giao hết cho Tom nhé. Nay chốt tới đây thôi bạn ơi. Đây là nghĩa là bước đầu tiên để show được quá trình làm phần mềm á. Nếu mà mình có một kỹ năng mềm tốt, với lại capture được cái domain và tất cả quá trình làm việc á, có thể leverage AI rất là nhiều để mà quá trình làm ra một.
[01:05:39] Người ban đầu lúc trước, một cái quá trình như vậy sẽ tốn khoảng 2 ngày, 3 ngày, 4 ngày gì đấy. Giờ quá trình làm xong, soạn rồi, vẽ diagram rồi, present cái idea, những hệ thống kiểu cũ á, nó nhanh rất là nhiều ha. Nên khi xong là đây là một cái skill trong team mình, Tom đang ở mức độ này. Ờ, mà Tôm đang tự tin là nó đang khoảng bao nhiêu phần trăm hả anh? Anh không rõ lắm. Mà anh nghĩ chắc đâu đó, chắc sẽ trên 50 phần trăm ha, trên 50 bé hơn 90. Hy vọng là những cái bước về sau thì sẽ có những buổi sau.
[01:06:21] Mình lại làm thêm vài buổi với Tom. Còn giờ chắc là tạm thời dừng ở đây. Các câu hỏi có liên quan thì anh em sẽ hỏi sau. Giờ anh đây. Bye bye, hẹn gặp lại mấy anh em nhé.
English transcript
[00:00] Let’s get started. Hey everyone, thanks for waiting. Where are Thành and Cường? Has Cường joined the room yet? I saw he registered for Friday, but he’s up here now, right? Where’s Thành this week? Oh, he’s here, standing right there. Tuấn, Tom, hop on stage now.
[04:51] We’re going through some articles, and suddenly this link, Tom, isn’t it great? Let me fix it. Today’s stats: 186 transactions, 1 user, 30 ICY members as usual, 5 inactive, 1482 fakes. Which are the top two most active chat channels? The top three? Who’s chatting the most? Oh, we’re in trouble! Anyone else around? Are we missing someone today? There are two old topics: one is “run and report”, I posted the link this morning, I think, let me double-check. The second is Cường’s design piece; I don’t know the details yet.
[06:03] What’s this one about? I’m sitting here listening and totally lost. The third piece follows up on the series from before you guys wrote it, worked on it, and now it’s taken solid shape. After three months, the team’s got some small updates, and this direction’s getting a bit clearer. The system feels outdated, though; I’ll forward a link later for everyone to review via email.
[07:10] Sign up and try it out, we’ll dive in later. That’s the plan. We’ll probably ship Hải’s piece first, then Cường’s, then Tom’s the parts Tom worked on. That’s today’s content, I think. Guys, check if anyone’s missing or if it feels too short. Anything else related we should add? Who’s not here? Has Thành joined yet? Oh, bro Thành’s on fire out of work to do. I think so too.
[08:55] Hold on a sec, let’s wait till everyone’s here, then we’ll speed-run these topics. They’re pretty straightforward. Try to sum up your piece of concept, idea, n 10 minutes max. Don’t go overboard so we can save time for the other session. If you need more than 10, stretch it a bit, alright? Next week’s the office schedule; this week’s just regular check-in.
[09:57] Next week, based on the sign-up list, I’ll suggest to Huy Nguyễn we do a roll-call game to get everyone in. It’s basically policy now, full attendance next week. The next part: those old projects are nearly wrapped up. Now it’s all about deploying blockchain and AI, they’re the kings of the game. Anyone wanting to work on them directly needs to plan it out. Any duplicates? Any more ideas?
[10:58] Guess we’ll start with Hải’s piece first. Hải, go ahead and present! Uh, everyone can see my visuals, right? I’ll summarize the frontend report for January. Last December, React 19 dropped, and alongside it, Next.js 15.1 rolled out a new version too.
[12:07]
To support both Next.js and React 19. On the React side, I see they’re working on a pretty cool API called View Transition. Browsers already have this View Transition API, but React didn’t support it before. Some libraries have built on that external API, but when integrated into React, they hit a few performance snags. Yeah, they’re waiting for React’s version of this API to improve support and tackle those performance issues more cleanly.
[12:48] This API’s for animating transitions between two stages of a webpage. Like, if you scroll down here, it’s like this example below. The first stage has the box up top, the second stage has it below. Instead of the stage just jumping straight down, View Transition helps us create an animation effect, sliding back and forth smoothly. Same deal with images, it adds animation effects too.
[13:28] When switching images, instead of instantly jumping to the next one. Yeah, this API’s still in the experimental phase. You’ve got to use the experimental version to try it out. But it promises a performance boost when implemented. Before, Motion supported this, but only in a vanilla environment. When scaled up, it ran into some performance hiccups because it had to handle pre- and post-set states.
[14:07] On this front, over at SCS, there’s stuff like Deno Deploy. It used to only support static site deployment, but now it fully supports deploying Next.js too, including server-side rendering. Now we can use Deno as a replacement, blending it in to deploy an NS app. Yeah, nothing much to say on that yet. Then there’s this Transformer Z library, pretty neat. At its core, it’s about converting models.
[15:03] At its core, it’s about converting models written in Python into JavaScript, so we can run these models directly in the browser without needing APIs or Python itself. Like in this article, it can handle sentiment testing say, positive or negative or object detection, like spotting a cat. Essentially, I think other models or pipelines can work too, as long as they’re supported by this library.
[18:33] We had to support a setup where, network or not, all data still gets saved. So we chose to store it in IndexedDB, then push it to the server once the connection’s back. That’s the gist of it. Down here, it’s got step-by-step instructions for handling it. Doing it this way runs into a few issues, like data lists failing during sync, for example. It points out some ways to tackle those problems.
[19:22] Something like that. Did An just post a link or something? What’s Zero? What did An just say related or not? The other day, I saw Lập mention this “local first” thing probably the same deal, right? Everyone’s tackling the same problem, racing to solve it. Next up, there’s a mention from the Win side. This one’s got an update, it supports that thing now. Before, with Node.js, you had to use a command line to compile TypeScript into JS to run it. Now it runs directly.
[20:01] Like, it runs straight from the command line, loading the file as-is. From what I see, there’s another piece about this dev guy, talking about dependencies at MBM. They keep dropping new versions, and each one comes with breaking changes. He says it’s a pain, wants to update versions but worries the app can’t keep up. There’s not always time to fix everything. So he’s not big on React, went a different route. He says this one’s more stable, less prone to constant shifts. He prefers it over the others. Meanwhile, HTMX is popping off, sitting at number one.
[21:07] Yeah, one last quick bit about Neon. This one’s a database service provider. They just switched from Webpack to something else. During the process, they hit some snags and realized Webpack’s got limitations. Like, it doesn’t support things well, there’s a long list of issues right here. But the end result after switching? They feel the new setup beats Webpack. First, it’s got fewer bugs, more reliable than Webpack. Second, its config is simpler. They say with just a dozen or two Webpack plugins, it makes their setup way lighter. I’m not sure why they went with that.
[22:03] But the final outcome after the switch is they think its hot reload is better than Webpack’s. It triggers fewer checks during full reloads compared to Webpack. Second, its config is simpler. Like they said, with about a dozen or twenty Webpack plugins or so, it keeps their setup much lighter.
[23:01] This piece mostly covers the challenges and the final results of switching from Webpack to that other thing. So, does that mean what we’re working on is shifting too? Are we moving from Webpack to this new one as well? What about that React stuff up there?
[23:50] Switching to HTMX, huh? That’s two now., what else is there? Using Deno? And TP, is that the main framework now? Yeah, alright, it’s in. For the other articles, you guys can check them out in here. Uh, what was it—Hải, can you repost that link? Thanks, Hải, and thanks, everyone, for the replies. What’s HTMX, and why’d it get picked? HTML with logic baked in? Like, it injects some stuff straight into the HTML and uses it to handle things directly, no fuss. This trick goes back to Backbone.js and Knockout.js days.
[25:06] A decade ago, and now they’re doing it the same way again. Any questions, guys? One minute for extra comments. Anything need updating? If there’s something, Hải, toss the link in random channel or group chat, whatever. Next up. Let’s move quick to Cường’s topic on database design. Alright, starting now. History lesson, huh? This stuff, these practices, they’ve been around since 2017.
[26:17] Just a recap, right? Summing it up? Summing up data design skills, entity tips? Nah, not exactly data management. More like practices for handling the knowledge as we build and scale up our database. Alright, I’ll dive in. The database and the system we’re developing always go hand in hand. When our software scales up to meet business demands, we’ve got no choice but to scale the database too, to manage a huge amount of data over the years.
[26:51] Take Amazon: in 2015, they had about 50 million data points, then by 2020, it grew to needing to handle 200 million. So why do we need these practices? When your database hits hundreds or thousands of schemas, management systems like SQL Server or other data management tools, you look at the schema diagrams, tables, or data, and you can’t possibly grasp it all.
[27:27]
The context why were these changes applied to the system? To boil it down, there are a few practices. It’s gotta be a combo of people and systems to manage this knowledge. All of this is just practices not about picking a database management system or designing the schema itself. It’s about how we share database knowledge, store that knowledge. And when database changes get rolled out, there’s a separate system to manage those changes like continuous integration and stuff like that.
[28:02] Those changes have to follow a few refactoring rules. Regarding no-sharing, we usually have someone called a DBA in our organization. This person manages and shares all the knowledge and changes applied to the database within the system. For example, if we’ve got multiple dev teams, say Dev 1 working on Software A and Dev 2 on Software B, both need to check with the DBA when pushing changes to the system’s database. The DBA verifies each change to see what it does and decides if it makes sense for the main database.
[28:34] When a dev pushes their database changes, they verify with the main system to check if the APIs calling the database are affected. Then they assess whether the change is necessary. If it impacts the system too heavily, the DBA might reject it and ask the dev to update, refactor, or adjust it to fit better. Once the change is approved, the DBA documents what it means, why it’s needed, and posts a migration for the master database to start updating.
[29:14] That data also needs to be stored somewhere everyone can easily access and search, so they understand why these changes matter. All these changes go into a repository, much like a coding project. This repository holds all the database artifacts, including scripts to run the database, login credentials, configurations, and the maximum capacity these instances can handle, plus system documentation. It’s similar to a coding project and gets managed with version control.
[29:51] And searchable, so we know why these changes are necessary. All those changes get stored in a repository, just like a coding project. Any questions, guys?
[30:39] So everyone can check and review the changes, their context, and history in the system, each time a change happens, the person pushing the migration creates a pull request with a description. This description explains why the change is needed, how essential it is, and which systems it’ll affect. The reviewers, mostly devs from the APIs directly impacted by this change, step in to take a look.
[31:14] After those changes get merged into the master branch, there’s versioning so we can rollback or deploy these versions to individual systems for development, testing, and finally production. When we’ve got multiple dev instances across versions, and we’re working on separate systems, we have to check out from an instance of the master database for development use. That way, when we tweak something or add a new migration, it doesn’t directly mess with the main database.
[31:52] At that point, we need a CI system. Whenever we change something in the instance we’re developing on, we can easily verify if the change breaks the master database. Plus, when someone pushes a new change to the master database, we get notified about schema updates or resource conflicts before it slows down our dev progress. When rolling out a database change, it involves a few steps, like modifying a database schema.
[32:25] When pushing a change, we have to create a migration script for that database. Once the script’s merged, we update the database access code so the API can use the new change. For database changes like adding a new column, it might not always require tweaking the API’s access layer when the change goes live, since some APIs don’t need to touch that new column. For instance, if we’ve got a user table with name and address, and a new service needs to add a birthday field to the user table, older services, like one grouping users by address, don’t need API changes to integrate this new update.
[33:07] For changes with big impacts, like introducing a non-null value or splitting a table, all dependent services need to update their data access layer to avoid errors. Take that user table from earlier, for example. If we split the user table, every service using it has to overhaul its access layer to prevent bugs. Alternatively, we could use something called a transition interface to gradually apply the new changes and roll them out without crashing the old APIs.
[33:45] After refactoring and applying the change to the master database, we still need to notify all services using this database to prevent breaking those APIs. At the same time, folks can coordinate to resolve config issues when the master database changes. For a recap, during software development, as the software grows, the database has to grow too. To keep everyone in the loop about the info and context of each database change, we need to leverage all our knowledge to share and organize it effectively.
[34:32] Also, all these changes have to be released thoroughly to avoid timing conflicts or resource clashes between database updates. This piece has value in its perspective. It’s probably like a dev’s viewpoint, but it focuses on shifting the main object of work.
[35:21] The info and context of each change within this database require us to use all our knowledge for knowledge sharing and to organize it well. Plus, all these changes must be released thoroughly to avoid timing conflicts or resource clashes among database updates. That’s it. Any questions, guys?
[35:58] It’s not about the codebase but the database, right? Leaning heavily that way. Hearing this part feels a bit meta, like it’s more relevant to big systems. For systems like ours now, it’s kinda tough to apply, huh? A system with about 20 tables already feels a bit sluggish, and looking at it gets overwhelming. Exactly. So this ties into documentation, managing versioning, and monitoring. Not version monitoring, but notifications for other teams, right? Yeah, it’s still limited, but spot on. Bringing this in makes sense because of the perspective.
[36:50] Data management comes before the other stuff. The logic’s here, and tomorrow the data will run. Any questions for Cường, guys? If not, we’ll wrap up here. This piece has value in its perspective. Thinking about it, for backend devs wanting to strike it rich, you’ve got to stick with projects long-term. The longer the project, the more money it’s got. That’s how it seems. Sticking with a long-running project is solid at its core, but devs usually get lazy. When something drags on too long, they get bored, and their behavior turns weird.
[37:40] Before moving to the next piece, to contribute to today’s session, here’s a keyword of the week. While reflecting on stuff, I picked up a new one, a fresh term for those who don’t know yet, like me. Today I came across this school of thought called Luddism. Luddism’s a word from the 19th century, tied to the Industrial Revolution. Industries like textiles got automated, and that ticked off some folks, called Luddites or something, who went and smashed those machines.
[38:34] Those machines stole their jobs, their livelihoods, so they wrecked them. That turned into a movement called Luddism, where the working class pushed back against modernization trends. The next keyword digging deeper is Neo-Luddism, alongside this Luddism stuff right here. Check it out if you want, guys. It feels pretty relevant to what’s coming up for us, based on predictions from the other day.
[39:18] When we were chatting, we figured there’d be a lot of pushback soon. On Reddit, there’s a post from two years back about a new Neo-Luddism wave popping up. Now it’s everywhere up there, huh? So, from my angle, I’d say we shouldn’t jump on this bandwagon. Progress keeps moving forward, and we shouldn’t fight the wheel of history. There’s even a subreddit called Luddism, diving straight into it. Not just about automation, but all sorts of tech pushback, feelings of being lost or out of place. Pretty interesting keyword, right, guys?
[40:08] Not getting stuck in that, huh? Then there’s a second thing tied to this. I just sat down and dug into it recently, and it’s U.S. geopolitics. There’s a perspective on how the U.S. is evolving. I was researching capital markets, tracking where investment money flows, and stumbled into this topic. It’s the second theme, pretty interesting. Maybe you guys will care about it. This ties into macroeconomics. Turns out it stems from that angle and shifts into macroeconomics.
[40:56] The U.S. is trending toward just two camps. One is isolationism, meaning pulling back. There’s another word we could use for it, figuring that out here. So, in this movement, what’s it saying? The U.S. will likely shrink inward, stop spreading resources everywhere for trade, and gather them up to hunker down defensively. That’s the first cluster. Right now, from all the news I’m seeing, it’s leaning that way, protectionism or isolationism. This cluster aside, the second direction I see is globalization.
[41:41] With globalization, innovations and jobs focus more on trading with each other, boosting cross-border commerce. Nations toss stuff all over the place. The U.S. would trend outward, along with allies in that camp. Countries following that path would also open up more, moving freely everywhere. That’s the state of things, based on reports from 1945 up to recently, breaking into smaller phases.
[42:20] In the post-war phase with Japan, after hitting them hard twice, they helped Japan and Germany rebuild after the war. That kicked off globalization in that direction. It’s the initial phase. It started there, and when Japan got too strong, right? It got dialed back by certain events. There’s this event here, plus one called VIA, with more details out there. But that’s the basics. So what’s the main idea? The core idea is there’s a trend we’re learning from history.
[43:09] From the Great Depression in 1930 up to now, 2020, there’s a sense the U.S. is swinging back to protectionism. That’ll pull other countries along too. Everyone’s putting their own nation first. So, hopping around everywhere will slow down compared to this phase. The red line’s China, this colored line’s Russia. Russia got a boost after ’91, went for Crimea, then got dialed back. Now it’s China’s turn.
[43:54] So how’ll this affect things? Globally, it’ll mean tougher markets. It’ll favor certain countries in that direction. Not sure about Vietnam. Vietnam’s in the top four for import-export delta with the U.S., still getting a boost. Not sure if we’ll cash in big, but generally, folks will move slower with their money. Two main paths here. One is tech keeps pumping out stuff, replaying constantly, so this term might pop up again.
[44:35] Plus, the global economic trend’s getting thick. I reckon it ties into what we’ve talked about. Markets are getting pickier, proven by this, huh? Easy to see how we’ll need to adapt. Let’s get Tom up to showcase some skills. I think the team could use them. Our crew needs the skills Tom’s picked up from working with whoever.
[45:31] In our team right now, there’s some stuff I won’t dive into about software dev trends. We’ve hashed that out plenty. But working with Tom, I noticed he’s got a slick skill. Almost the whole software dev life cycle, Tom handles solo, using coding chops and automating with tools, even writing his own agents. From initial dev to capturing project insights, then planning it out.
[46:07] Everything, Tom nails it. So I want him to show a bit [music] about his approach during work. From getting the brief to reaching your planning stage, how’s it go, what’ve you done? Oh, cool, I’ll share my screen then. Hope there’s nothing sensitive. I figure we’ll grab the brief we’ll dive into soon, right there. Yeah, let’s roll with that one. We don’t even know what it is yet, haven’t dug in. So the starting point’s basically zero.
[46:55] It’s just got a sample brief, up to when I get to that part. Alright, I’ll share my screen, find that spot, yeah? Cool, so usually my logic’s like this. We’ve got data, and I want to unpack its key points. If we’ve got these images, say, I’ll strip it all down, then extract stuff. What’s this app got that we need to watch? Okay, then it’s the directions I want it to take, explaining it for me. Cause it’s always possible folks see this app—
[47:59] As maybe Airbnb, or some personal trainer and lifestyle trainer app. So here, I’m trying to figure out “What the hell,” right? First, I’d set up a prompt. Say the context is I’m about to meet a client asking us to improve their user experience. Then there’s their external context, and ours is “I’ve got some guesses on what they might want.” Question is, do we need to input our whole brief too? Not here. Then it’s this, the main bit.
[49:08] It’s objective, adjective, context. This is the email they sent us. Then I want the core vision, “What’s the vision, goals, and objectives for them asking us to help improve?” From that, I’ll generate some context to send back to the AI side. In reality, I’ve probably done this already, huh? Yeah, any model works, but a thinking model helps pull out perspectives we miss. Those thinking models are ace at that stuff.
[50:15] So it’s kinda functional, user app-centric. From this context, I’ll figure out what the app is, then picture the vision they’re after. Oh, it’s really about something more detailed on users, user experience. So I’d ask, “What images, what do these guys want?” They don’t want much, they’re looking to clone this app, not improve it. The app’s already there, and now they want to mirror it, right?
[51:07] It’s an existing thing we’re redoing. With this shift, it sparks questions like, “Are there ways their app’s extending? What’re your thoughts?” Then I gradually build a picture. From that picture, I’ll craft a final prompt model to send to our side’s team. Like, moving forward on a proven model’s shortcomings. That way, we’ve got stuff to watch out for. We’ll need to manually test what, exactly?
[52:15] Details on this concept validation. It’s just using what already works. With that concept, I’d make a prompt like, “Give me a proposal to pass on what I’ve learned about this client, their vision, goals, and objectives, and help me consolidate a direction to create a proposal. This proposal ideally isolates and connects dots: what’s the story behind what they want, and what they want us to consult, develop?”
[53:23] On how this proposal will shape up, after that, since each AI tool we use has ready references, I’ll copy an existing one we’ve got. A pre-made proposal, say from before, like this. Then we’d copy a proposal from their side, maybe, duplicate it, tweak it here and there. Wait, internet’s out? Oh, probably copied the wrong thing. Should be, you guys can pull this up or download it. Use the reference to create the proposal, or just in case, don’t lift elements.
[55:16] From it, but follow the proposal format to adapt to what we’ve learned and what they’re aiming for to build trust. After that, we always expect this proposal won’t be stable. It’ll firm up once we toss in ideas, ideas I think we can bring ourselves into. Since we’re seeing their angle like this, what can our side deliver? For example, my skillset leans toward excelling at user experience, user flow, data flow. Here, we can mirror the app and optimize its data flow, user flow, stuff like that.
[56:10] Or, from anh Thành’s side, it’s optimizing for security and performance. How do we apply this correctly to the project proposal? Adding in some good-to-have stuff like performance and security. If it’s an MVP, we wouldn’t consider hacking concerns much. It’s more about designs tied to data. For example, my side often designs data with temporal state, event store, or uniform patterns.
[56:51] How do we apply our computer science skills to this properly? Not overly simple, but simplifying and maintaining what this app delivers. If we go with this and the reference here, now it’s like anh needs some stuff to lock in the deal, right? We’ll need questions to figure out how it works with them. Like an open deal, all cards on the table. To get there, we need those questions, plus we’ve got to suggest a work schedule and next milestones between us and them.
[57:28] Need those questions, along with the fact we’ve pretty much got to do it. How do I handle it? Building rapport, then digging into their burning questions. If we’re sharp in our craft, coming up with questions isn’t too hard. But if I feel stuck, hitting some block, I’d ask AI for question ideas.
[58:14] “So we haven’t met with this partner yet, this client yet, but we want to make a deal with them. What should I do to help build rapport and find the three burning questions I need to kick this deal off and address any technical concerns?” That’s a solid start. I’d use it to have the AI spit out some questions for us. Then I’d build on that. If I come up with more, I’d add them to the proposal, keeping it realistic. Not just Gemini, but apps like Claude or ChatGPT, how do we approach it?
[59:12] How do we handle the due diligence? For burning questions, say we’ve got no prior context up here, just use it. It’s like that out there. I want to set goals like that, starting with the first proposal. I’m a bit skeptical about mirroring, why do they want to mirror? It’ll show in the intent of the initial proposal we built for them. So it ties into this. When we’ve got more, it’s not always set.
[59:50] I’d use this as is, but from here I’d figure, maybe a real-time handling angle? Perhaps their side isn’t real-time, more like a booking appointment app. If we pitch real-time, do they want that vision? To consult on whether they want the app prettier, stabler, or newer, riskier even? It’s steps where we ask, throw stuff out, see how they reply. No harm in it.
[01:00:34] Cause it’s a fair question anyway. Say this dev step lands, then what’s next with the to-do list and laying it all out? Yeah, yeah, it’s like picturing it. I’ve got some stuff I picture as already sorted. Then I flesh out the technical direction we agree on to move forward with them. Like real-time, “We think they want something like this, but are open to a more real-time thing, like Grab or Uber for personal trainers.” First, I’d draft the technical proposal.
[01:01:33] Probably not needed though, usually I’d build that to clarify the angle. But from this view, it’s like, “Help me create tasks for frontend, backend.” Cause in that middle stretch, Tôm here figures out all the diagrams, flows, everything. Gotta lock that down first, then base the breakdown on it, right? So to simplify today, we’ll have AI churn it out.
[01:02:11] It’s a rough angle, but we’ll add, “We’re plannin
