Mỗi năm đều được đăng vào tháng 11, nhưng năm nay tôi chia sẻ hơi muộn một chút.
Dự đoán công nghệ của CTO Amazon sau năm 2025
Dự đoán công nghệ của CTO Amazon sau năm 2024
Dự đoán công nghệ của CTO Amazon sau năm 2023
Dự đoán công nghệ của CTO Amazon sau năm 2022

Điều tôi muốn nói là bài này quá mang màu sắc AI và cũng không có tài liệu tham chiếu, nên tôi mong mọi người đừng chia sẻ những bài viết như thế này.

Tuyệt vời ^^

Cảm ơn bạn đã trả lời.

Tôi cũng đã nghĩ đến vấn đề chi phí, quả nhiên có vẻ chi phí thay đổi rất lớn tùy theo độ phân giải của ảnh đầu vào. Ngoài ra, tôi hoàn toàn chưa nghĩ đến mối quan hệ giữa kích thước ảnh đầu vào và tốc độ xử lý, thật thú vị. Hóa ra khi crop thì tốc độ xử lý cũng nhanh hơn.

Và mức cải thiện độ chính xác thật sự rất đáng ngạc nhiên!
Hiệu năng của VLM đã được cải thiện rất nhiều, nhưng dù vậy thì hiện tại vẫn chưa thể vượt qua hiệu năng của mô hình YOLO được huấn luyện cho một mục đích duy nhất sao?

Cảm ơn bạn đã ghi lại bằng bài viết những kinh nghiệm và bí quyết đúc kết từ tình huống thực tế.
Nếu sau này tôi gặp một vấn đề tương tự, nhất định tôi sẽ tham khảo những phương pháp bạn đã dùng.

Dạo này tôi cũng cảm nhận điều đó khá nhiều..
Tôi đoán là nhiều bài trên blog được viết dựa trên trải nghiệm của chính tác giả + có sự hỗ trợ của AI.
Vì các bài viết quá mạch lạc và được viết rất dễ đọc.

Ừm... có gì đó có vẻ kỳ kỳ
Hình như bài này được viết bằng AI.

1) Nghi ngờ độ đáng tin của bài viết: có mùi marketing/nội dung do AI tạo ra

Ý chính

• “Cái này được dựng quá khéo kiểu một vở kịch rút ra bài học” → dấy lên nghi ngờ đây là kiểu câu chữ được tối ưu cho một ‘moral play’ mà HN thích
• Trong bài gắn đầy liên kết tới tài liệu trả phí nên có luồng ý kiến mạnh rằng “rốt cuộc đây chẳng phải là bài bán hàng sao?”
• Cách viết lạm dụng danh sách/emoji bị chỉ ra là tín hiệu của “AI slop” (nội dung AI làm ẩu, sản xuất hàng loạt)

Trích dẫn chốt hạ sự thật (dịch)

“Có vẻ toàn bộ thứ này chỉ tồn tại để bán các tài nguyên trả phí được gắn link. Và nó cho cảm giác như AI slop với đống danh sách đó.”
(nguyên văn: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)

Đánh giá một dòng

• “Trước cả chuyện nội dung đúng hay sai, mùi bán hàng + mùi AI đã quá nồng” là phản ứng số 1.

2) Chỉ trích lãnh đạo/architect: vấn đề không phải công nghệ mà là ‘cấu trúc ra quyết định’

Ý chính

• Có nhiều phản ứng cho rằng ngay từ việc “đội 4 người mà có architect?” đã là lệch hướng rồi
• Đặc biệt, góc nhìn xem architect không viết code/vai trò DevOps tách rời là kiểu “nút thắt cổ chai + tối ưu CV” xuất hiện khá mạnh
• Giọng điệu chung là không phải microservices giết công ty, mà là “một cấu trúc nơi không ai thực sự chịu trách nhiệm cho việc deploy/vận hành/khắc phục sự cố” mới là thứ làm hỏng mọi chuyện

Trích dẫn đanh thép (dịch)

“Architect mà công việc là định ra ‘quy tắc’ với ‘pattern’ nhưng không trực tiếp triển khai thứ gì thì gần như lúc nào cũng là ý tưởng tệ. Cứ tập trung ship sản phẩm đi... Khi người không viết nổi 10 dòng code lại độc chiếm quyết định thì sẽ toang.”
(nguyên văn: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)

Đánh giá một dòng

• Ý kiến “MSA không phải vấn đề, mà vấn đề là thiết kế vai trò có quyền quyết định nhưng không có trách nhiệm” xuất hiện khá mạnh.

3) Góc nhìn kinh doanh: nguyên nhân startup thất bại thật sự có phải là MSA?

Ý chính

• Có những bình luận không tin vào chính cách đóng khung “sụp đổ vì kiến trúc”
• Luận điểm cốt lõi: nếu PMF/nhu cầu/độ gắn kết khách hàng yếu thì dùng stack nào cũng có thể thất bại
• Đặc biệt, các chi tiết như “khách hàng chỉ vì chậm hai ngày là bỏ đi ngay?” bị soi để hỏi ngược rằng có phải giá trị sản phẩm vốn đã yếu rồi không
• Và họ cũng chỉ ra mâu thuẫn ngay trong bài: nói “MSA đã giết startup”, nhưng kết luận lại là “đã sống sót?” → nghi ngờ câu chuyện bị cường điệu

Trích dẫn chốt hạ sự thật (dịch)

“Thứ giết startup là làm ra một sản phẩm mà chẳng ai muốn, chứ không phải kiến trúc MSA. Nói MSA giết startup cũng vô lý giống như nói Python hay Go đã giết startup vậy...”
(nguyên văn: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)

Đánh giá một dòng

• Có một góc nhìn rất rõ là: “kiến trúc chỉ là cái cớ, nguyên nhân thật có thể là thị trường/sản phẩm/dòng tiền.”

4) Góc nhìn kỹ thuật: lời khuyên dựa trên trải nghiệm về monolith vs MSA (phần thực sự hữu ích)

Ý chính

• “MSA có một loại thuế chi phí cố định (độ phức tạp vận hành)” → nhiều chia sẻ kinh nghiệm cho rằng điều này có thể chí mạng với đội nhỏ
• Từ khóa chính: Premature distribution (phân tán quá sớm), modular monolith/modulith, “hãy ‘kiếm được’ boundary”
• Các điều kiện khiến MSA thực sự cần thiết cũng được nêu ra khá thực tế: khi quy mô đội ngũ tăng lên và các vấn đề về xung đột/deploy/tổ chức thực sự bắt đầu bùng phát
• Ngược lại, cũng có lời khuyên rằng vấn đề hiệu năng/mở rộng thường không nên “giải bằng MSA” ngay, mà trước hết hãy xem thuật toán/nút thắt cổ chai/sharding/partitioning

Trích dẫn đanh thép (dịch)

“Thứ giết startup không phải là microservices mà là ‘phân tán quá sớm’. Họ tách ra trước khi boundary thực sự hình thành nên chỉ phải trả giá bằng latency và chi phí điều phối; hãy bắt đầu với modular monolith, kiếm được boundary rồi mới tách ra.”
(nguyên văn: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)

Đánh giá một dòng

• Bài học mà cộng đồng thực sự đồng cảm là:
  “Hãy bắt đầu bằng monolith, và chỉ tách service khi boundary xuất hiện một cách ‘tự nhiên’.”

Tổng kết cộng đồng trong một câu

Hầu hết đều đồng ý với câu “chúng ta không phải Netflix”, nhưng đồng thời cũng nghi ngờ mạnh rằng chính bài viết này có thể là một kiểu câu chuyện bán ‘căn bệnh thích bắt chước Netflix’ (= marketing/AI).

Dùng thì ổn hơn tưởng tượng, nhưng vì hỗ trợ bên thứ ba trên Mac vẫn tốt hơn nên cuối cùng lại không dùng.. haha

Cảm giác như đang chê chỉ để chê.

Đây là bài viết giải thích kiến trúc về cách một sản phẩm thực sự được cấu thành.
Nhân lúc đã ổn định ở phiên bản 1.0 và sắp xếp lại tài liệu, tôi cũng thử chỉnh lý lại bài viết.

Chuyển hẳn sang ngôn ngữ C3 cũng là một lựa chọn hay. Đây là một dự án giữ cú pháp của C với mức thay đổi tối thiểu, đồng thời bổ sung các tính năng hiện đại nên cũng dễ chuyển đổi.

Đây là bài giải thích cho Show GN: 자연어 명령을 Intent → Effect → Snapshot으로 실행하는 AI Task 데모 đã được đăng trên ShowGN.

Điểm khác giữa cuộc thảo luận đó với issue là gì? Issue không phải là “bug”. Dù là bug, đề xuất tính năng hay PR… nếu có điều gì đáng để thảo luận thì đó là issue.
Nếu không đáng để thảo luận thì cứ đóng lại là được.

Vì vậy nên tôi ghét quảng cáo..

Năm ngoái tôi đã cài lên laptop Galaxy Book, nhưng không biết có phải do vấn đề tương thích không mà cứ bị treo máy.

Rich - thư viện Python để định dạng terminal một cách đẹp mắt đúng là tốt nhất.

Nhưng nếu chỉ cần riêng tính năng bảng thì cũng có những lựa chọn như PrettyTable hoặc Tabulate.

Trông có vẻ tiện đấy, còn với Python thì có những gì nhỉ?

Wow, việc bắt đầu từ Nhật Bản cũng thật thú vị. Tôi cứ nghĩ những chuyện như thế này thì châu Âu hoặc Mỹ sẽ đi trước cơ.

Năm ngoái đã có rất nhiều cải thiện về HiDPI và HDR, giờ có vẻ như mức độ hỗ trợ còn tốt hơn cả Windows.

Tôi thật sự thắc mắc không hiểu vì sao giá của 4o mini lại như vậy, tôi nhớ là bản 4o thường còn rẻ hơn mà haha