Bản thân bài viết này có vẻ đáng ngờ về mặt dụng ý, nhưng đúng là khi dùng thực tế thì nó đang ngày càng trở nên phiền phức hơn.
Tôi thấy giờ trên thiết bị Galaxy họ còn làm cho cả các tính năng như chặn ứng dụng bị nghi là độc hại cũng không thể tắt đi được nữa. Dù vẫn có cách lách, nhưng họ đang ngày càng bổ sung thêm những kiểu hạn chế như vậy.
Với người dùng phổ thông, đây có thể là một tính năng tốt vì họ hầu như không dùng sideloading và có thể ngăn việc chạy mã độc, nhưng ít nhất cũng nên cho phép tắt nó đi chứ?
Tôi đã muốn Pixel được phân phối chính thức, nhưng nếu Google cũng làm điều tương tự thì...
Tôi là một người theo hướng generalist, nhưng điều tôi cảm nhận trong công việc thực tế là thế này.
Người hữu ích là generalist, nhưng những người thực sự được công nhận về "giá trị" lại là specialist.
Ngay cả khi học cùng trường đại học, có cùng điểm số, thì thực tế cuối cùng specialist vẫn nhận mức đãi ngộ cao hơn gấp 2~3 lần.
Việc mở và dùng một máy chủ web bên trong ứng dụng để xử lý các tính năng bắt buộc phải có tên miền, localStorage và những thứ tương tự nhìn chung là cách làm phổ biến.
Theo tôi, trong ứng dụng hybrid, cách giao tiếp thông thường giữa web và app là thông qua các API do hệ điều hành và phía trình duyệt cung cấp, còn gọi là bridge. Tôi cho rằng máy chủ web cục bộ không phải là thứ bắt buộc.
Lý do việc dùng máy chủ web cục bộ ở đó trở thành vấn đề, theo tôi, là vì nó có thể dẫn tới những lỗ hổng như việc truy cập vào cổng localhost từ Chrome ở chế độ ẩn danh để phá vỡ tính ẩn danh của người dùng. Nếu kỹ thuật này là bắt buộc trong ứng dụng hybrid thì... ứng dụng hybrid nên biến mất.
Đây đúng là một bài viết rất bổ ích. Không chỉ cần những công cụ mạnh mẽ mà còn phải sẵn sàng tự tạo ra những công cụ cần thiết khi cần. Vì vậy, nếu vận hành trơn tru thì lợi ích thu được cũng rất nhiều.
Có vẻ Hàn Quốc cũng trong tình cảnh tương tự. Tôi nghĩ thay vì chỉ học mỗi ngành đó, kiểu như sinh học + năng lực lập trình, thì học một chuyên ngành khác + lập trình sẽ có lợi hơn cho việc tìm việc. Khi đủ loại framework và đám mây phát triển, cùng với sự xuất hiện của các công cụ LLM khiến việc tiếp cận lập trình trở nên dễ hơn (giống như trước đây từ assembly -> C -> Python), thì có vẻ ngoài năng lực lập trình ra, bạn còn phải biết làm những việc khác nữa mới có thể bước vào thị trường tuyển dụng.
Khi viết một script đơn giản để dùng một lần thì rõ ràng là hữu ích. Tiết kiệm được rất nhiều thời gian
Cũng hữu ích trong những trường hợp cần giải quyết nhưng không thể đầu tư quá nhiều thời gian. Tuy vậy, hiện tại nhìn chung vẫn hữu ích nhưng chưa thể thay thế hoàn toàn con người. Không biết sau này sẽ phát triển đến mức nào, nhưng lúc này với vai trò trợ lý thì ở mức tạm ổn để dùng.
Hồi học cao học, giáo sư hướng dẫn từng đi ăn với một kỹ sư xuất thân từ Google rồi nghe kể về monorepo hay sao đó, nên đã đề xuất rằng từ nay phòng lab của chúng tôi cũng hãy quản lý bằng monorepo, và tôi đã khá vất vả để can ngăn...
Monorepo đúng là có nhiều điểm hay, nhưng do đặc thù của phòng lab chúng tôi là thường xuyên phải chia sẻ các kết quả đầu ra cho người bên ngoài, nên nếu đã quản lý thành quả bằng monorepo thì có lẽ ở khâu này sẽ đặc biệt vất vả. Nếu là multi-repo thì chỉ cần điều chỉnh phạm vi công khai theo từng thành quả là được.
Có vẻ như hầu hết những trường hợp khổ sở khi làm monorepo là do ngay từ đầu đã chia nhỏ dự án quá mức. Vốn dĩ chỉ cần một hai dự án thì lại tách thành hơn chục cái, rồi khi cố gộp chúng lại để quản lý bằng monorepo thì vừa phải dùng thêm công cụ quản lý monorepo, vừa làm độ phức tạp tăng lên. Tốt hơn là nên gộp chính các dự án lại còn một hai cái; ngay cả khi có từ hai dự án trở lên thì cũng đừng dùng công cụ quản lý riêng, mà cứ nghĩ đơn giản là chia thư mục ra rồi đặt chúng vào cùng một repository, như vậy sẽ quản lý nhẹ đầu hơn nhiều.
Bản thân bài viết này có vẻ đáng ngờ về mặt dụng ý, nhưng đúng là khi dùng thực tế thì nó đang ngày càng trở nên phiền phức hơn.
Tôi thấy giờ trên thiết bị Galaxy họ còn làm cho cả các tính năng như chặn ứng dụng bị nghi là độc hại cũng không thể tắt đi được nữa. Dù vẫn có cách lách, nhưng họ đang ngày càng bổ sung thêm những kiểu hạn chế như vậy.
Với người dùng phổ thông, đây có thể là một tính năng tốt vì họ hầu như không dùng sideloading và có thể ngăn việc chạy mã độc, nhưng ít nhất cũng nên cho phép tắt nó đi chứ?
Tôi đã muốn Pixel được phân phối chính thức, nhưng nếu Google cũng làm điều tương tự thì...
Tôi là một người theo hướng generalist, nhưng điều tôi cảm nhận trong công việc thực tế là thế này.
Người hữu ích là generalist, nhưng những người thực sự được công nhận về "giá trị" lại là specialist.
Ngay cả khi học cùng trường đại học, có cùng điểm số, thì thực tế cuối cùng specialist vẫn nhận mức đãi ngộ cao hơn gấp 2~3 lần.
Việc mở và dùng một máy chủ web bên trong ứng dụng để xử lý các tính năng bắt buộc phải có tên miền,
localStoragevà những thứ tương tự nhìn chung là cách làm phổ biến.C: Tôi cũng làm được DBA+BackEnd+Middle Ware+Linux Engineer+Cloud Architecture, vậy có thể đi theo hướng đó không!?
Tôi cũng không thể tin tưởng ứng dụng Meta nên không dùng, thay vào đó chỉ sử dụng bằng Chrome trong Thư mục bảo mật.
Khoảng đâu đó vào năm 2025..
A: Một người phải làm được Spring, React, Android, iOS
B: Ý là mỗi mảng một người, tổng cộng bốn người đúng không?
A: Tôi đã bảo là một người mà
B:
Con người thì biết gì chứ!
Việc kiếm việc đúng là khắc nghiệt. Nhưng nhìn theo góc khác thì đây cũng là lĩnh vực rất phù hợp để tự làm một dịch vụ cho riêng mình...
Làm ơn, làm ơn đừng làm vậy mà nói rồi thì kiểu gì cũng có 1 trong 10 đứa vẫn làm thế -_-
Cảm ơn bạn vì bài viết hay.
Tôi cũng muốn sống như một lập trình viên độc lập như thế này.
Theo tôi, trong ứng dụng hybrid, cách giao tiếp thông thường giữa web và app là thông qua các API do hệ điều hành và phía trình duyệt cung cấp, còn gọi là bridge. Tôi cho rằng máy chủ web cục bộ không phải là thứ bắt buộc.
Lý do việc dùng máy chủ web cục bộ ở đó trở thành vấn đề, theo tôi, là vì nó có thể dẫn tới những lỗ hổng như việc truy cập vào cổng localhost từ Chrome ở chế độ ẩn danh để phá vỡ tính ẩn danh của người dùng. Nếu kỹ thuật này là bắt buộc trong ứng dụng hybrid thì... ứng dụng hybrid nên biến mất.
Cảm ơn bạn đã phản hồi nhanh~
Đây đúng là một bài viết rất bổ ích. Không chỉ cần những công cụ mạnh mẽ mà còn phải sẵn sàng tự tạo ra những công cụ cần thiết khi cần. Vì vậy, nếu vận hành trơn tru thì lợi ích thu được cũng rất nhiều.
Có vẻ Hàn Quốc cũng trong tình cảnh tương tự. Tôi nghĩ thay vì chỉ học mỗi ngành đó, kiểu như sinh học + năng lực lập trình, thì học một chuyên ngành khác + lập trình sẽ có lợi hơn cho việc tìm việc. Khi đủ loại framework và đám mây phát triển, cùng với sự xuất hiện của các công cụ LLM khiến việc tiếp cận lập trình trở nên dễ hơn (giống như trước đây từ assembly -> C -> Python), thì có vẻ ngoài năng lực lập trình ra, bạn còn phải biết làm những việc khác nữa mới có thể bước vào thị trường tuyển dụng.
Xin gửi lời tán dương!
Khi viết một script đơn giản để dùng một lần thì rõ ràng là hữu ích. Tiết kiệm được rất nhiều thời gian
Cũng hữu ích trong những trường hợp cần giải quyết nhưng không thể đầu tư quá nhiều thời gian. Tuy vậy, hiện tại nhìn chung vẫn hữu ích nhưng chưa thể thay thế hoàn toàn con người. Không biết sau này sẽ phát triển đến mức nào, nhưng lúc này với vai trò trợ lý thì ở mức tạm ổn để dùng.
Hồi học cao học, giáo sư hướng dẫn từng đi ăn với một kỹ sư xuất thân từ Google rồi nghe kể về monorepo hay sao đó, nên đã đề xuất rằng từ nay phòng lab của chúng tôi cũng hãy quản lý bằng monorepo, và tôi đã khá vất vả để can ngăn...
Monorepo đúng là có nhiều điểm hay, nhưng do đặc thù của phòng lab chúng tôi là thường xuyên phải chia sẻ các kết quả đầu ra cho người bên ngoài, nên nếu đã quản lý thành quả bằng monorepo thì có lẽ ở khâu này sẽ đặc biệt vất vả. Nếu là multi-repo thì chỉ cần điều chỉnh phạm vi công khai theo từng thành quả là được.
Bài viết hay đấy ~
À, tôi đã giải quyết được bằng một cách khác rồi. Cảm ơn!
Có vẻ như hầu hết những trường hợp khổ sở khi làm monorepo là do ngay từ đầu đã chia nhỏ dự án quá mức. Vốn dĩ chỉ cần một hai dự án thì lại tách thành hơn chục cái, rồi khi cố gộp chúng lại để quản lý bằng monorepo thì vừa phải dùng thêm công cụ quản lý monorepo, vừa làm độ phức tạp tăng lên. Tốt hơn là nên gộp chính các dự án lại còn một hai cái; ngay cả khi có từ hai dự án trở lên thì cũng đừng dùng công cụ quản lý riêng, mà cứ nghĩ đơn giản là chia thư mục ra rồi đặt chúng vào cùng một repository, như vậy sẽ quản lý nhẹ đầu hơn nhiều.