Có vẻ như bài viết đã bỏ qua khả năng rằng khi dịch vụ tăng trưởng và độ phức tạp tăng lên, việc tiếp tục áp dụng nguyên xi phương pháp ban đầu có thể không còn hiệu quả nữa.
Dĩ nhiên ở giai đoạn đầu, cách tiếp cận nhanh là dễ thực hiện và hữu hiệu, nhưng nếu không chấp nhận rằng nó có thể không còn hoạt động nữa, thì người ta có thể cảm thấy như nhân lực bổ sung đang bị đánh giá là kém hiệu quả và thiếu cống hiến.
Dù rồi cũng sẽ nhận ra muộn màng rằng chiến lược đó không còn phát huy tác dụng nữa.
Tôi tình cờ thấy bài này qua phần gợi ý của Google rồi vào đọc, nhưng đây là một bài viết được viết quá nhiều từ góc nhìn của dân Geek. Từ góc độ kinh doanh thì hoàn toàn không phải là câu chuyện đúng. Vì sao lại như vậy?
Những công cụ lớn mà Big Tech dùng thì dễ tìm chuyên gia hơn.
Có rất nhiều người học chúng để vào Big Tech, và cũng có nhiều người học chỉ vì Big Tech đã chọn dùng. Đương nhiên, sẽ dễ tìm người hiểu về chúng hơn, cũng dễ tuyển người có kinh nghiệm hay chuyên gia hơn. Nhưng nếu là một công cụ hoàn toàn xa lạ thì sao? Không phải là không có người đào sâu vào nó, nhưng để tìm được những người như vậy chắc chắn sẽ khó hơn nhiều so với chuyên gia về các công cụ của Big Tech.
Những công cụ lớn mà Big Tech sử dụng có rất nhiều tài liệu tham khảo
Những công cụ lớn được nhiều người dùng thì có rất nhiều tài liệu để giải quyết vấn đề, và kết quả tìm kiếm trên Google cũng phong phú. Phần lớn vấn đề thường là thứ người khác cũng từng gặp, nên chỉ với một tìm kiếm đơn giản là có thể dễ dàng xác định vấn đề. Nhưng với một công cụ xa lạ, rất khó tìm tài liệu tham khảo, và nếu xảy ra sự cố thì khả năng cao sẽ tốn khá nhiều thời gian để xác định nguyên nhân. Mà tất cả những thứ đó đều là tiền. Vấn đề này có thực sự là do công cụ nhỏ mới được đưa vào hay không? Hay là đang hiểu nhầm vấn đề từ phía khác?
Ngược lại, chính Big Tech mới là bên dễ chuyển đổi những thứ này hơn. Vì với quy mô xử lý dữ liệu khổng lồ, chỉ một chút lợi ích về I/O cũng có thể trở thành lợi ích rất lớn đối với họ. Và cũng có nhiều người sẵn sàng học chỉ vì Big Tech đã áp dụng. Nhưng với các công ty quy mô vừa và nhỏ, do quy mô dữ liệu tương đối nhỏ nên một chút lợi ích về I/O không hẳn là lợi ích lớn đến vậy, trong khi những vấn đề ở trên lại rất nghiêm trọng. Cũng có ít người muốn học các giải pháp mà doanh nghiệp vừa và nhỏ áp dụng hơn. Vì thế, nếu là chủ doanh nghiệp vừa và nhỏ, thì thay vì cân nhắc những thứ này theo kiểu Geek, nhiều trường hợp sẽ đi đến kết luận rằng làm theo các công cụ của Big Tech mới là lựa chọn kinh tế hơn.
Vì AI cũng có thứ gì đó tương tự như tri giác, nên nếu muốn cùng chung sống với AI thì sẽ cần xây dựng các thể chế và pháp luật dành cho AI. Với tư cách là một dạng sinh mệnh mới của thế kỷ 22, chúng ta không nên trêu chọc hay đối xử với nó như đồ chơi, và vì ở một khía cạnh nào đó nó cũng có thể nguy hiểm, nên không chỉ phát triển và sử dụng AI mà còn cần phải bảo đảm có thể sử dụng nó một cách an toàn.
Với lượng dữ liệu nhỏ và mức độ mã đơn giản như ví dụ ở trên thì tôi nghĩ nhìn cũng ổn, không có gì tệ.
Nhưng khi code dần được nhét thêm vào trong map() ... thì nó có xu hướng khiến mã ngày càng phình to hơn,
và tuy còn tùy ngôn ngữ hay thư viện triển khai mà mức độ ảnh hưởng khác nhau, nhưng khi lượng dữ liệu tăng lên thì so với cách đơn giản là chất dữ liệu vào cấu trúc dữ liệu hoặc vừa thao tác vừa xử lý, nó cũng có thể dễ dàng chậm hơn đến hàng nghìn lần.
Và rồi lại có thêm một lý do mới khiến tôi không còn thích nó nữa: khi xem bài này trên điện thoại, chiều rộng kiểu như trên PC vẫn bị giữ nguyên nên cỡ chữ bé tí như hạt bụi, thành ra đọc bài quá khó T.T
Về cơ bản tôi không thích nó, và cũng không cố tình nỗ lực để viết theo kiểu đó.
Có vẻ bạn vẫn chưa hiểu. Nếu game thú vị thì dù có lồng ghép tư tưởng vào cũng không sao. Mục đích của game là mang lại sự thú vị. Lý do game không thú vị có thể là do tuyên truyền. Vì nó sẽ ảnh hưởng đến cốt truyện, thiết kế, v.v. Giờ thì bạn đã hiểu hơn chưa?
À, về tiến độ thì trừ trường hợp thực sự không đủ thời gian vật lý, nếu bảo làm nhanh hơn thì đúng là vẫn có thể rút ngắn hết mức có thể để hoàn thành.
Nhưng chuyện đảm bảo chất lượng hay độ ổn định lại là một câu chuyện hoàn toàn khác.
Trong quá trình làm việc, việc bỏ bớt một hai bước kiểm tra để kịp tiến độ thì vẫn có thể làm được, và trong một vài tình huống đặc biệt khẩn cấp, việc bỏ qua như vậy một hai lần cũng có khả năng cao là sẽ không gây ra vấn đề gì.
Nhưng nếu điều này trở thành chuyện thường ngày, thì việc thiếu sót trong những quy trình kiểm tra đó sớm muộn cũng sẽ trở thành ngòi nổ tạo ra một vấn đề lớn mà thậm chí ta còn không kịp nhận ra.
Có vẻ như vì bạn cứ khẳng định và tiếp tục nói rằng việc ép buộc tuyên truyền tuyệt đối không thể được xem là một "yếu tố gây mất vui", nên có lẽ chúng ta sẽ mãi chỉ đi trên những đường thẳng song song. Tôi xin phép từ chối một cuộc đối thoại vô nghĩa. Chúc bạn vất vả rồi.
Điều này khá giống với những gì tôi vẫn thường nghĩ về văn hóa crunch. Thỉnh thoảng làm vậy thì có thể được, nhưng nếu trở thành mãn tính thì tôi nghĩ đó là vấn đề. Dù vậy, startup đúng là một ngành buộc phải tạo ra kết quả trong thời gian ngắn, nhưng tôi không chắc liệu điều đó có bền vững hay không.
Nghĩ lại thì elm cũng làm được.
Gleam cũng hỗ trợ cái này nên có thể viết code khá gọn gàng.
Mà không biết có phải vì trong bài có khối code không, mà trên di động nó cũng hiện theo bố cục desktop.
Có vẻ như bài viết đã bỏ qua khả năng rằng khi dịch vụ tăng trưởng và độ phức tạp tăng lên, việc tiếp tục áp dụng nguyên xi phương pháp ban đầu có thể không còn hiệu quả nữa.
Dĩ nhiên ở giai đoạn đầu, cách tiếp cận nhanh là dễ thực hiện và hữu hiệu, nhưng nếu không chấp nhận rằng nó có thể không còn hoạt động nữa, thì người ta có thể cảm thấy như nhân lực bổ sung đang bị đánh giá là kém hiệu quả và thiếu cống hiến.
Dù rồi cũng sẽ nhận ra muộn màng rằng chiến lược đó không còn phát huy tác dụng nữa.
Và tôi không nghĩ việc gọi một công ty không có hệ thống là "khả năng thực thi nhanh" lại là điều đáng để tự hào.
Trong khi cũng chẳng trả được đến mức như họ, nếu cứ ép vì cho rằng năng suất của họ không ra gì thì người làm việc giỏi sẽ bỏ đi thôi...
Tôi tình cờ thấy bài này qua phần gợi ý của Google rồi vào đọc, nhưng đây là một bài viết được viết quá nhiều từ góc nhìn của dân Geek. Từ góc độ kinh doanh thì hoàn toàn không phải là câu chuyện đúng. Vì sao lại như vậy?
Những công cụ lớn mà Big Tech dùng thì dễ tìm chuyên gia hơn.
Có rất nhiều người học chúng để vào Big Tech, và cũng có nhiều người học chỉ vì Big Tech đã chọn dùng. Đương nhiên, sẽ dễ tìm người hiểu về chúng hơn, cũng dễ tuyển người có kinh nghiệm hay chuyên gia hơn. Nhưng nếu là một công cụ hoàn toàn xa lạ thì sao? Không phải là không có người đào sâu vào nó, nhưng để tìm được những người như vậy chắc chắn sẽ khó hơn nhiều so với chuyên gia về các công cụ của Big Tech.
Những công cụ lớn mà Big Tech sử dụng có rất nhiều tài liệu tham khảo
Những công cụ lớn được nhiều người dùng thì có rất nhiều tài liệu để giải quyết vấn đề, và kết quả tìm kiếm trên Google cũng phong phú. Phần lớn vấn đề thường là thứ người khác cũng từng gặp, nên chỉ với một tìm kiếm đơn giản là có thể dễ dàng xác định vấn đề. Nhưng với một công cụ xa lạ, rất khó tìm tài liệu tham khảo, và nếu xảy ra sự cố thì khả năng cao sẽ tốn khá nhiều thời gian để xác định nguyên nhân. Mà tất cả những thứ đó đều là tiền. Vấn đề này có thực sự là do công cụ nhỏ mới được đưa vào hay không? Hay là đang hiểu nhầm vấn đề từ phía khác?
Ngược lại, chính Big Tech mới là bên dễ chuyển đổi những thứ này hơn. Vì với quy mô xử lý dữ liệu khổng lồ, chỉ một chút lợi ích về I/O cũng có thể trở thành lợi ích rất lớn đối với họ. Và cũng có nhiều người sẵn sàng học chỉ vì Big Tech đã áp dụng. Nhưng với các công ty quy mô vừa và nhỏ, do quy mô dữ liệu tương đối nhỏ nên một chút lợi ích về I/O không hẳn là lợi ích lớn đến vậy, trong khi những vấn đề ở trên lại rất nghiêm trọng. Cũng có ít người muốn học các giải pháp mà doanh nghiệp vừa và nhỏ áp dụng hơn. Vì thế, nếu là chủ doanh nghiệp vừa và nhỏ, thì thay vì cân nhắc những thứ này theo kiểu Geek, nhiều trường hợp sẽ đi đến kết luận rằng làm theo các công cụ của Big Tech mới là lựa chọn kinh tế hơn.
Rất đáng mong chờ bản tiếng Hàn!!
Có lẽ là để tránh dùng dữ liệu do AI tạo ra làm dữ liệu huấn luyện (model collapse) chăng.
Chắc như được kèm kiểu luyện gà đoán đề Hàn Quốc nên chỉ giỏi làm bài thi.
Đến lúc thực sự nói chuyện thì… ngơ ngơ.
“Nếu nghĩ là sẽ mất lâu thì sẽ mất lâu, còn nếu nghĩ là sẽ xong nhanh thì sẽ xong nhanh.” làm tôi nhớ đến định luật Parkinson.
Định luật Parkinson: thời gian cần để hoàn thành một công việc sẽ tăng lên theo lượng thời gian được giao cho nó.
Chẳng phải là chỉ muốn khai tử nó thôi sao?
Vì AI cũng có thứ gì đó tương tự như tri giác, nên nếu muốn cùng chung sống với AI thì sẽ cần xây dựng các thể chế và pháp luật dành cho AI. Với tư cách là một dạng sinh mệnh mới của thế kỷ 22, chúng ta không nên trêu chọc hay đối xử với nó như đồ chơi, và vì ở một khía cạnh nào đó nó cũng có thể nguy hiểm, nên không chỉ phát triển và sử dụng AI mà còn cần phải bảo đảm có thể sử dụng nó một cách an toàn.
Với lượng dữ liệu nhỏ và mức độ mã đơn giản như ví dụ ở trên thì tôi nghĩ nhìn cũng ổn, không có gì tệ.
Nhưng khi code dần được nhét thêm vào trong
map()... thì nó có xu hướng khiến mã ngày càng phình to hơn,và tuy còn tùy ngôn ngữ hay thư viện triển khai mà mức độ ảnh hưởng khác nhau, nhưng khi lượng dữ liệu tăng lên thì so với cách đơn giản là chất dữ liệu vào cấu trúc dữ liệu hoặc vừa thao tác vừa xử lý, nó cũng có thể dễ dàng chậm hơn đến hàng nghìn lần.
Và rồi lại có thêm một lý do mới khiến tôi không còn thích nó nữa: khi xem bài này trên điện thoại, chiều rộng kiểu như trên PC vẫn bị giữ nguyên nên cỡ chữ bé tí như hạt bụi, thành ra đọc bài quá khó T.T
Về cơ bản tôi không thích nó, và cũng không cố tình nỗ lực để viết theo kiểu đó.
MAUI ... hu hu
Có vẻ bạn vẫn chưa hiểu. Nếu game thú vị thì dù có lồng ghép tư tưởng vào cũng không sao. Mục đích của game là mang lại sự thú vị. Lý do game không thú vị có thể là do tuyên truyền. Vì nó sẽ ảnh hưởng đến cốt truyện, thiết kế, v.v. Giờ thì bạn đã hiểu hơn chưa?
Cho
jsnữa đi |> cúi đầu nài nỉÀ, về tiến độ thì trừ trường hợp thực sự không đủ thời gian vật lý, nếu bảo làm nhanh hơn thì đúng là vẫn có thể rút ngắn hết mức có thể để hoàn thành.
Nhưng chuyện đảm bảo chất lượng hay độ ổn định lại là một câu chuyện hoàn toàn khác.
Trong quá trình làm việc, việc bỏ bớt một hai bước kiểm tra để kịp tiến độ thì vẫn có thể làm được, và trong một vài tình huống đặc biệt khẩn cấp, việc bỏ qua như vậy một hai lần cũng có khả năng cao là sẽ không gây ra vấn đề gì.
Nhưng nếu điều này trở thành chuyện thường ngày, thì việc thiếu sót trong những quy trình kiểm tra đó sớm muộn cũng sẽ trở thành ngòi nổ tạo ra một vấn đề lớn mà thậm chí ta còn không kịp nhận ra.
Có vẻ như vì bạn cứ khẳng định và tiếp tục nói rằng việc ép buộc tuyên truyền tuyệt đối không thể được xem là một "yếu tố gây mất vui", nên có lẽ chúng ta sẽ mãi chỉ đi trên những đường thẳng song song. Tôi xin phép từ chối một cuộc đối thoại vô nghĩa. Chúc bạn vất vả rồi.
Điều này khá giống với những gì tôi vẫn thường nghĩ về văn hóa crunch. Thỉnh thoảng làm vậy thì có thể được, nhưng nếu trở thành mãn tính thì tôi nghĩ đó là vấn đề. Dù vậy, startup đúng là một ngành buộc phải tạo ra kết quả trong thời gian ngắn, nhưng tôi không chắc liệu điều đó có bền vững hay không.
|>quá đẹp