Xin chào, giờ tôi mới thấy có nhiều bình luận như vậy nên để lại đôi lời chia sẻ.
Trên blog, tôi chủ yếu đăng nội dung về việc chuyển từ native sang Flutter; không biết sau này có viết lại thành một bài riêng hay không, nhưng xin chia sẻ ngắn gọn như sau.
Trong khoảng 3 ngày, đã có tổng cộng hơn 3.000 người xem trang hơn 50.000 lần.
Có một câu chuyện buồn đằng sau việc tôi công khai dự án này.
Gần đây, nơi tôi đang làm việc đã phát sinh một số vấn đề tái cơ cấu. Tôi vẫn ở lại, nhưng một số đồng nghiệp làm việc cùng tôi đã rơi vào tình huống phải chuyển việc, và tôi cũng muốn giới thiệu đến các công ty khác đang sử dụng Flutter những nội dung mà các thành viên trong nhóm chúng tôi có thể xử lý thành thạo. Tất nhiên, tôi có thể nói rằng những người trong nhóm chúng tôi đang chuẩn bị chuyển việc hoàn toàn có thể làm được đến mức này.
Nền tảng của nội dung được xây dựng dựa trên các hướng dẫn mà tôi và các thành viên trong nhóm đã viết nội bộ trong công ty, cùng với những kỹ thuật đã dùng trong các dự án của công ty. Ban đầu tôi muốn biến nó thành tài liệu hướng dẫn onboarding cho thành viên mới, nhưng hiện tại nội bộ không còn dịp sử dụng nữa nên tôi đã công khai toàn bộ.
Vẫn còn nhiều chỗ thiếu sót và cũng còn nhiều nội dung chưa thể đề cập, nhưng cảm ơn mọi người đã đón nhận 🙇🏻♂️
Ngoài ra, tôi cũng đang thực hiện khảo sát để cải thiện trang, nên nếu có thời gian tham gia thì tôi sẽ thực sự biết ơn.
Ngay cả khi đều hỗ trợ cả thanh toán web lẫn thanh toán trong ứng dụng, tôi cũng khá hay chọn thanh toán trong ứng dụng. Việc có thể quản lý mọi khoản thanh toán ở một nơi là một ưu điểm khá lớn, và đặc biệt với những sản phẩm chỉ định thử một hai lần, có vẻ cũng có phần cảm thấy yên tâm hơn khi thanh toán qua Apple.
Tôi cũng đồng ý với điểm này. Khi logic được thêm vào HTML bằng một cú pháp riêng thay vì vanilla, đó là một rào cản khá lớn. Việc triển khai UI đơn giản thì không có vấn đề gì, nhưng khi logic trở nên phức tạp, sẽ có sự khác biệt về độ linh hoạt trong phát triển và cũng không thể xem nhẹ đường cong học tập.
Tôi thật sự rất đồng cảm.
Từ góc độ người phụ trách triển khai giải pháp trong doanh nghiệp, khi thấy một công nghệ mới có vẻ hấp dẫn thì rất dễ chỉ tập trung vào chính phần đó, nhưng đây là một bài viết thực sự chạm tới điểm cốt lõi rằng trên thực tế cũng cần cân nhắc cả những khó khăn và thời gian thích nghi đi kèm với việc thay đổi cách làm việc đã quen thuộc.
Nghe giống như câu chuyện về lý do Julia ra đời. Dù phải học các thư viện, nhưng vì nó giải quyết được nhiều vấn đề của NumPy nên có vẻ là một lựa chọn thật sự rất hấp dẫn.
Có vẻ mỗi người sẽ có gu khác nhau, nhưng cá nhân tôi thích kiểu .map((item) => <li>) của JSX được xử lý bằng vanilla JS hơn so với <li for> của Angular, Vue v.v. (bao gồm cả thư viện? markup?).
https://tech.kakao.com/posts/700 Tôi đã thấy đây là một ví dụ hay về Vibe Coding khi đọc bài viết này, và có vẻ bối cảnh cũng tương tự. Tôi cũng đồng cảm với nội dung bạn đã viết.
Mình nghĩ rằng nếu độ tin cậy của những cảnh báo mang tính đe dọa bị suy giảm, thì ngay cả khi một cảnh báo thực sự quan trọng xuất hiện, người ta cũng có thể bỏ qua và lướt qua luôn. Những vấn đề phát sinh do độ tin cậy của cảnh báo giảm sút rốt cuộc có lẽ chỉ làm thiệt hại cho người tiêu dùng tăng thêm.
Ồ, làm rất tốt đấy. Tôi vẫn còn chưa thành thạo nên xử lý menu lồng nhau chưa giỏi, nhưng starlight làm việc đó thật sự rất tốt.
Xin chào, giờ tôi mới thấy có nhiều bình luận như vậy nên để lại đôi lời chia sẻ.
Trên blog, tôi chủ yếu đăng nội dung về việc chuyển từ native sang Flutter; không biết sau này có viết lại thành một bài riêng hay không, nhưng xin chia sẻ ngắn gọn như sau.
Trong khoảng 3 ngày, đã có tổng cộng hơn 3.000 người xem trang hơn 50.000 lần.
Có một câu chuyện buồn đằng sau việc tôi công khai dự án này.
Gần đây, nơi tôi đang làm việc đã phát sinh một số vấn đề tái cơ cấu. Tôi vẫn ở lại, nhưng một số đồng nghiệp làm việc cùng tôi đã rơi vào tình huống phải chuyển việc, và tôi cũng muốn giới thiệu đến các công ty khác đang sử dụng Flutter những nội dung mà các thành viên trong nhóm chúng tôi có thể xử lý thành thạo. Tất nhiên, tôi có thể nói rằng những người trong nhóm chúng tôi đang chuẩn bị chuyển việc hoàn toàn có thể làm được đến mức này.
Nền tảng của nội dung được xây dựng dựa trên các hướng dẫn mà tôi và các thành viên trong nhóm đã viết nội bộ trong công ty, cùng với những kỹ thuật đã dùng trong các dự án của công ty. Ban đầu tôi muốn biến nó thành tài liệu hướng dẫn onboarding cho thành viên mới, nhưng hiện tại nội bộ không còn dịp sử dụng nữa nên tôi đã công khai toàn bộ.
Vẫn còn nhiều chỗ thiếu sót và cũng còn nhiều nội dung chưa thể đề cập, nhưng cảm ơn mọi người đã đón nhận 🙇🏻♂️
Ngoài ra, tôi cũng đang thực hiện khảo sát để cải thiện trang, nên nếu có thời gian tham gia thì tôi sẽ thực sự biết ơn.
https://tally.so/r/w559Vv
Ngay cả khi đều hỗ trợ cả thanh toán web lẫn thanh toán trong ứng dụng, tôi cũng khá hay chọn thanh toán trong ứng dụng. Việc có thể quản lý mọi khoản thanh toán ở một nơi là một ưu điểm khá lớn, và đặc biệt với những sản phẩm chỉ định thử một hai lần, có vẻ cũng có phần cảm thấy yên tâm hơn khi thanh toán qua Apple.
Xin lưu ý, "Desire paths" thực ra là "Desire paths".
Tôi cũng đồng ý với điểm này. Khi logic được thêm vào HTML bằng một cú pháp riêng thay vì vanilla, đó là một rào cản khá lớn. Việc triển khai UI đơn giản thì không có vấn đề gì, nhưng khi logic trở nên phức tạp, sẽ có sự khác biệt về độ linh hoạt trong phát triển và cũng không thể xem nhẹ đường cong học tập.
Nhờ vậy mà tôi đã đọc được một bài viết thú vị! Cảm ơn bạn.
Tôi thật sự rất đồng cảm.
Từ góc độ người phụ trách triển khai giải pháp trong doanh nghiệp, khi thấy một công nghệ mới có vẻ hấp dẫn thì rất dễ chỉ tập trung vào chính phần đó, nhưng đây là một bài viết thực sự chạm tới điểm cốt lõi rằng trên thực tế cũng cần cân nhắc cả những khó khăn và thời gian thích nghi đi kèm với việc thay đổi cách làm việc đã quen thuộc.
Nghe giống như câu chuyện về lý do Julia ra đời. Dù phải học các thư viện, nhưng vì nó giải quyết được nhiều vấn đề của NumPy nên có vẻ là một lựa chọn thật sự rất hấp dẫn.
numpy nếu không tận dụng tốt vectorization thì hiệu năng sẽ tệ hẳn. Viết có tính đến mấy thứ đó vừa căng thẳng vừa khó.
Thật kỳ diệu
https://sdmntprwestus2.oaiusercontent.com/files/…
Có vẻ mỗi người sẽ có gu khác nhau, nhưng cá nhân tôi thích kiểu
.map((item) => <li>)của JSX được xử lý bằng vanilla JS hơn so với<li for>của Angular, Vue v.v. (bao gồm cả thư viện? markup?).https://tech.kakao.com/posts/700 Tôi đã thấy đây là một ví dụ hay về Vibe Coding khi đọc bài viết này, và có vẻ bối cảnh cũng tương tự. Tôi cũng đồng cảm với nội dung bạn đã viết.
Mấy thư viện Python hơi cũ có vẻ đều gặp những vấn đề khá giống nhau.
Vậy còn 3 thì sao? -> Đó là câu chuyện về hỗ trợ tài nguyên.
Ở trên tôi đã đánh số 1, 2, 4, 5 nhưng trong Markdown nó tự động đổi thành 1234.
Next.js vs TanStack – Giới hạn của Next.js và ưu điểm của TanStack
Chúng ta đã từng chơi trò này rồi!
^ Bài học bị dẫn dụ bấm “Có” vô thức của ActiveX
Mình nghĩ rằng nếu độ tin cậy của những cảnh báo mang tính đe dọa bị suy giảm, thì ngay cả khi một cảnh báo thực sự quan trọng xuất hiện, người ta cũng có thể bỏ qua và lướt qua luôn. Những vấn đề phát sinh do độ tin cậy của cảnh báo giảm sút rốt cuộc có lẽ chỉ làm thiệt hại cho người tiêu dùng tăng thêm.
Apple đúng là xấu xí đến cùng luôn ha ha ha
Tôi không mấy thích xu hướng vận hành diễn đàn trên Discord, nơi không thể tìm kiếm bằng công cụ tìm kiếm.